Del 1 – Så här lyckas ni med ert Affärssystemprojekt – Den bäst förberedda kunden
8 feb 21
Alla organisationer som ger sig på ett projekt att implementera ett Affärssystem – eller för den delen ett HR-system eller annan typ av verksamhetssystem – sätter upp mål med projektet, både i form av Effektmål på längre sikt (nytta med projektet) och mer Operativa projektmål. Projektmålen definieras ofta som, något förenklat, att driva projektet på rätt Tid, med rätt Kvalitet och hålla Budget.
”Lättare sagt än gjort” konstaterar många när projektet är färdigt och dags att granska hur det verkligen gick med tidplanen, budgeten och resultatet i form av funktionell kvalitet och användbarhet för IT-systemet. Har man varit med hela vägen i ett större IT-projekt, har man lärt sig mycket på sina egna misstag och fått kunskap om hur man borde ha gjort om man fick göra om det.
Har man som vi på HerbertNathan & Co erfarenhet från cirka 500 olika IT-projekt, så har vi lärt oss att det finns några saker som kraftigt ökar möjligheterna till ett lyckat projekt som håller tidplanen, budgeten och uppnår förväntad kvalitet. När vi satte oss ner och sammanställde dessa framgångsfaktorer kom vi fram till 20 punkter. Det finns självklart fler, men de här 20 anser vi som de mest relevanta med störst påverkan på projektets resultat. Idag listar vi nummer 16 – 20 och vi går nerifrån och upp:
Prestandatester är ofta något som förbises och orsaken är många gånger att de anses svåra att genomföra på ett realistiskt sätt. Vi rekommenderar alltid att man tidigt i projektet börjar planera för hur och när tester skall göras och tillsammans med leverantören blir överens om hur prestandatester skall genomföras. Leverantören har ofta programvara som kan simulera ett större antal användare och detta kan användas i kombination med att man låter många ur kundens personal genomföra en viss åtgärd i systemet samtidigt som man lägger olika typer av körningar i bakgrunden och parallellt med övriga tester.
Det kan vara en fördel att låta någon person som i övrigt inte deltar i projektet, eller extern konsult, några gånger under projektet göra en granskning hur projektet drivs framåt och på så sätt bidra till en hög kvalitet i projektet. Det finns alltid en risk att de bägge projektledarna ”drunknar” i det vardagliga och att då använda någon som lite mer med ett övergripande perspektiv tittar på hur projektet drivs kan vara ett bra komplement och ett stöd både för projektledarna och styrgruppen. För uppgiften finns ett antal dimensioner att granska exempelvis Risk, Nytta, Effektivitet och Delaktighet i projektet.
Med blanketter menas här exempelvis fakturalayouter och andra dokument i systemet som i någon mån skall anpassas till kundensförutsättningar. Viktigt att tänka på här är vad som är absolut nödvändigt att det finns framme vid driftsstart och vad man kan vänta. Vår erfarenhet är att man både från kund och leverantör tidigt tar för lätt på detta och har inställningen att leverantörens standardblanketter för exempelvis fakturalayouter är tillräckligt bra, men att man längre fram i projektet upptäcker att man måste göra mindre anpassningar och att detta då tar längre tid än beräknat.
Konverteringsarbetet i sig brukar aldrig rent teknisk vara några problem att genomföra, men man måste vara medveten om att det kan komma att behöva göras flera loopar av och det är mycket arbete som tillkommer mellan konverteringarna i form av rättningar och tillägg. Det är oftast detta som tar tid och som gör att aktiviteten tar längre tid än vad som från början var beräknat. Konverteringsarbetet har även kopplingar till Master Data Management (MDM) och där är vår erfarenhet att översyn och kvalitetssäkring av master data är en väsentlig grund för en framgångsrik konvertering av data.
Begreppet förändringsledning kan tyckas ”säga allt och inget” och det är vår erfarenhet att många kunder säger nej tack till detta och tycker att det behöver vi inte. Om man i begreppet ”förändringsledning” lägger information och utbildning, så är det oftast många fler som inser värdet av aktiviteten. Det är ett faktum att ett nytt system många gånger också innebär helt eller delvis nya sätt att utföra arbetsuppgifter på och då måste projektet ta ansvar för att detta kommuniceras, förankras och i slutändan utbildas kring i verksamheten. Denna inställning och förståelse för behovet av ”förändringsledning” är synnerligen viktigt att ha med sig under hela projektet men också efter driftstart. Denna punkt kan man även se som en grund för att få igång ett mer kontinuerligt och långsiktigt arbete med att ”underhålla och utveckla sina processer”. Det blir då lättare efter projektavslut att roller och rutiner rullar vidare i en aktiv förvaltning.