Del 4 – Så här lyckas ni med ert Affärssystemprojekt – Den bäst förberedda kunden
25 mar 21
Vi har kommit fram till plats 1 – 5 i vår serie om den ”Bäst förberedda kunden” när det kommer till ett Affärssystemprojekt. I fyra delar har vi listat och rangordnat de 20 viktigaste faktorerna som kunden kan påverka för att implementationsprojektet. Vi började baklänges med plats 20 och när vi nu är framme på de översta platserna, bygger den här rangordningen på HerbertNathan & Co erfarenheter efter att tillsammans med våra kunder genomfört över 400 affärssystemprojekt. Det är självklart så att prioritering och rangordning kan se olika ut i det enskilda projektet beroende på projektets unika förutsättningar, men sammantaget har vi landat i denna rangordning:
Plats 5: Tester av systemet sker i för liten omfattning och utan struktur
Kunden måste från början inse att ansvaret för ett lyckade tester ligger i huvudsak på kunden själv. Det finns en självklar gång och uppdelning där leverantören ansvarar för funktionstester och där kunden genomför acceptanstester av olika slag. Vi skiljer på systemtester (som bör utföras av leverantören själv som egenkontroll under implementeringen) och acceptanstest som åligger kunden inför att godkänna systemet.
De vanligaste är tester av processer, tester av integrationer och prestandatester. Leverantören erbjuder sig oftast att bistå med mallar för testerna, men den springande punkten är att det är bara kunden och skall vara kunden som ansvarar för acceptanstester. Testerna kan bara genomföras med kunskap om de egna processerna och regelverk. Här måste därför kunden avsätta personal i tillräcklig omfattning och personalen måste också vara så utbildad på systemet att testerna kan genomföras på ett effektivt sätt. Även om kunden har det slutliga ansvaret för att genomföra testerna, hindrar det inte att leverantören är med och är aktiv som stöd under testerna. Tvärtom är detta oftast en förutsättning för att testerna skall kunna genomföras på ett rimligt sätt och inom planerade tidsramar. Betydelsen av väl genomarbetade testscenarion och testprotokoll för att ska struktur under arbetet skall inte underskattas
Plats 4: För få personer med verksamhetskompetens medverkar i projektet
För att på bästa sätt ”sätta upp” systemet, krävs det att personer med verksamhetskunskap tillsammans med applikationskonsulter från leverantören deltar i den omfattning som krävs för att beskriva flöden och testa flöden så att det blir så väl anpassat till kundensverksamhet som möjligt. Detta område hör ihop med punkt 2 nedan och ibland ser vi att kunden använder sig av så kallade referensgrupper. Det kan fungera men ännu bättre är att involvera verksamhetens resurser direkt in varje delprojekt så att man följer och bidrar genom hela projektet med sin verksamhetskunskap. Processägare och nyckelpersoner bör medverka med en plan på att dessa personer också får ett långsiktigt ansvar för utveckling av processerna över tid. Detta för att undvika att man fastnar i en stel lösning och/eller ett konsultberoende. En aktiv och utvecklande kund är bästa garantin för en långsiktig och framtidssäker lösning.
Plats 3: Underskattning av internt resursbehov till projektet
Ett implementationsprojekt av den storlek det innebär att implementera ett Affärssystem innebär en utmaning att genomföra vid sidan av ordinarie arbetsuppgifter. Det måste finnas utrymme att frigöra ordinarie arbetsuppgifter till den personal som skall delta i projektet och detta gäller särskilt de som skall arbeta mycket i projektet såsom kundens egna projektledare, lösningsansvarig, testledare med flera. En enkel tumregel brukar vara att kunden måste minst sätta till dubbelt så många timmar som leverantören gör och många gånger ännu mer. Det kan vara värt att ta in extra arbetskraft för att utföra delar av de ordinarie arbetsuppgifterna. Det är en investering som återbetalar sig i ett bättre system och mer kompetent personal.
När resurserna behövs som mest varierar över projektets genomförande och något förenklat kan man säga att under faserna Design, Test och Driftsstart behövs det som mest resurser i projektet. Finns det möjlighet och utrymme redan inför projektstart att beräkna när dessa 3 aktiviteter inträffar under året, så kan också större hänsyn tas till semesterperioder, perioder med hög arbetsbelastning i linjen på grund av kundbeteende och liknande interna påverkande faktorer. De kunder som går igenom roller och resurser och faktiskt bestämmer deltagande i procent på individnivå har störst möjlighet att lyckas med resurstilldelning till projektet.
Plats 2: Begränsad anpassning av befintliga arbetsflöden
Denna punkt tangerar den punkt som vi satt som nummer 1 i denna ranking. Det tillägg vi vill göra här är att kunden skall ställa krav på leverantören redan under designfasen att inte utgå från ett vitt papper utan att hela tiden jobba agilt och integrerat i systemet utifrån de standardprocesser som finns tillgängliga i systemet. Då blir det rätt fokus från början och man minskar risken för ”önskelistor” från kunden om hur systemet borde sättas upp, snarare än att se på hur systemet kan sättas upp utifrån standard. För att detta skall fungera krävs också att leverantören ”vågar stå för en åsikt” och inte slentrianmässigt köper kundens önskemål. Här noterar vi att det finns 2 risker;
- Kunden förväntar sig att leverantörens konsulter skall kunna så mycket om både systemet och processen det gäller att kunden skall bli guidad till bäst lösning, vilket tyvärr inte alltid är fallet.
- Konsulten lyssnar för mycket på kunden och dess önskemål om hur processen skall sättas upp viket kan landa i att man går ifrån standard i systemet.
Då ovanstående diskussioner och arbete sker ute i delprojekten, så är det synnerligen viktigt att rollen Lösningsarktitekt är involverad i dessa diskussioner. Projektet måste hitta formerna för detta för att undvika onödig byråkrati men ändå ha kontroll på problemet som kan uppkomma här.
Plats 1: Undvik specialanpassningar och avsteg från standardlösningen
Numera brukar kunden vara bra på att använda de standardprocesser som finns i systemet från början och inte med automatik kräva specialanpassningar av standardsystemet. Det har tidigare varit vanligt och då ofta med motivet att ”det är så här vi arbetar i nuvarande system och då vill vi göra det i det nya också”. Vi ser allt oftare en mer nykter syn på detta nu och att man i dialog med leverantören kommer fram till att slutresultatet av en viss systemprocess blir lika bra som tidigare, bara att vägen dit kan se lite annorlunda ut i det nya systemet.
Samtidigt ser vi ofta att det finns några processer eller funktioner i organisationen som behöver ett IT-stöd som inte standardsystemet som skall implementeras klarar av fullt ut. I det läget kan det självklart vara motiverat att ge sig in på någon form av kundunik anpassning. Då är det dock synnerligen viktigt att ta höjd för att både budget och tidplan med största sannolikhet kommer att spricka. Involvera Styrgruppen tidigt i diskussionen ha dess stöd för vilket vägval projektet gör. Med detta sagt, så fundera på vad som är helt nödvändig funktionalitet vid driftsstart och vad som kan vänta till en fas 2 i projektet. Synsättet ”att börja gå innan man försöker springa” fungerar i detta sammanhang. Det kan ibland/ofta vara rätt strategi att börja i begränsad skala innan man drar i gång alla moduler och funktioner.
Tidplanen i många av de implementationsprojekt vi är involverade i styrs delvis av att det gamla systemet skall fasas ut vid en viss tidpunkt som är kopplat till avtal med nuvarande leverantör. Genom att då säkerställa nuvarande funktionalitet i dagens system, kan projektet hitta en miniminivå som absolut måste vara klar till driftsstart. Resterande kan sedan läggas ut under senare faser i projektet.