Att implementera CRM-system

Ni vill alltså införa ett IT-stöd för ert CRM-arbete!?

Då bör ni börja med att tydligt svara på frågan VARFÖR?

Förändringsarbete tar tid och resurser och kräver motivation för att ge resultat.

Utan ett tydligt svar på DÄRFÖR vill ni förändra riskerar ni att inte orka hela vägen.

Changes2
iStockPhoto.com

Hur ser ert CRM-arbete ut? Hur skulle ni vilja att det såg ut?

Det är i denna inledande delen av arbetet ni har en chans att jobba igenom er arbetsmetodik om ni inte redan har gjort det. Det handlar om att konkretisera det ni redan gör och skapa samsyn om vart ni vill.

Bra initiala frågor är

  • Vilka anknytningspunkter har ni med era kunder?
  • Vilka vanliga scenarion går era anställda igenom?

Med detta systematiserar och dokumenterar ni ert arbete. Detta kommer sedan vara utgångsläget för det fortsatta implementeringsarbetet.

Enkelt och snabbt

Jag träffar ofta personer som är ansvariga för att upphandla och implementera ett nytt CRM-system. Jag möter ibland frustration över att det som först verkat vara ett ganska enkelt projekt har blivit väldigt komplicerat.

  • Krav och förväntningar har tornat upp sig och tornet riskerar att rasa

Det är viktigt att begränsa, prioritera och dela upp och på så sätt göra projektet lättare. Det gäller att fråga sig hur viktig varje funktion är och avgöra vad man kan stryka eller avvakta med att införa.

Fördelarna med att dela upp arbetet och få korta cykler och ledtider är många. Den investerade tiden i pågående arbete blir mindre. Flexibiliteten ökar och risken minskar i projektet.

För att man verkligen ska få korta ledtider och jobba agilt måste man ställa krav och planera enligt samma metodik. Man behöver t.ex. inte ha bestämt hur man ska integrera och automatisera när man drar igång projektet utan kan nöja sig med att veta att det går att gör det. Om man planerar hela projektet från början jobbar man inte agilt oavsett hur arbetet sedan utförs.

Innehåll och struktur före automation!

Det finns en prioritetsordning för vilka funktioner som användarna och verksamheten har störst nytta av. Utöver det finns det vissa tekniska begränsningar i vad som  bör göras och i vilken ordning. Utmaningen blir nu att identifiera en snabb och bra release där vi kan skapa ett tydligt värde för användarna.

I de flesta projekt jag har jobbat i har detta inneburit att vi först har definierat innehåll och struktur i systemet. I praktiken innebär det; konfigurera upp miljön utan någon automatik, så att vi har ett fungerade system med alla processer men där allt göras manuellt, både arbetsflöden och integrationen med andra system.

När man är nöjd med systemet börjar man automatisera alla integrationer och arbetsflöden, de mest kritiska först. På så sätt minimerar man både risk och implementationstid och man har alternativet att produktionssätta i flera steg.

Användarrvänligt

Mycket av det jag har nämnt tidigare går hand i hand med användarvänlighet. I ett system med begränsad funktionalitet är överblickbarheten bättre och den funktionalitet som finns lättare att förstå. För IT-ovana användare finns inget “nice to have” bara “need to have”. Prioriterar man delarna av systemet och implementerar dom seriellet blir varje release mindre och lättare för användrana att ta till sig.

Utbildningen utgår från hur ni i er organisation vill jobba, inte hur systemet fungerar.

Det blir mer pedagogiskt och intressantare. Ett stort behov av utbildning i själva IT-systemet är ett dåligt tecken. Slutanvändaren kanske inte var tillräckligt i fokus under utformandet av systemet?

Det är lätt hänt att de användare som är med i utvecklingen av system blir fartblinda.

De har ofta högre kunnande i ämnet från början och kommer under projektet att bli mer och mer hemma i det system de är med och tar fram. Om dessa personer likställs med de användare som inte deltar i utvecklingsarbetet kan steget in för övriga användare bli onödigt högt.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *