Var redo!
Project Readiness går precis som det låter ut på att göra sig redo för ett projekt. Var redo, alltid redo, säger scouterna. För en IT-konsult är det vad som görs – eller borde göras – innan implementationsprojektet startar för att ge det förutsättningar att bli framgångsrikt. Det handlar om att klargöra processer, resurser och ansvar, projektmål och – ack så viktigt – kvaliteten på masterdatan. Att göra rätt från början, helt enkelt.
Men det är inte riktigt så trivialt som det låter.
Snabbare och säkrare implementation
Alla konsultbolag har sitt sätt att sälja in och förbereda en implementation. De flesta nöjer sig med att implementera systemet eller den applikationen som kunderna har valt. Ofta börjar man först en eller två veckor före start genom att skriva ett projektdirektiv av något slag.
Men har man för bråttom att komma igång kan det undergräva hela projektet och få oönskade konsekvenser för hela implementationen. I värsta fall också för kundens verksamhet.
För vad händer om masterdatan visar sig ha så dålig kvalitet att den måste tvättas under testfasen? Eller om det visar sig att två avdelningar är oense om projektmålen? Eller om en process är oklar och måste definieras när allt är igång? Lämnar du sådana saker åt slumpen kan du räkna med det kommer surt efter och ställer till projektet på något sätt.
Under implementationen är det kanske 5-6 konsulter igång och 10+ personer från kunden som är uppbokade och kostar pengar varje dag. Något som hade kunnat lösas av några få personer i förberedelsefasen påverkar plötsligt hela projektorganisationen och äter upp projektets tid och resurser med god aptit. Vips blir det mindre tid än beräknat över till tester eller till andra mer värdeskapade uppgifter. Medarbetarna måste rycka in och göra oplanerade saker under stress och utnyttjas därför inte på bästa sätt.
Är det här något du känner igen?
En timme i project readinessfasen sparar fem timmar i projektet.
Ett project readinessprojekt snabbar på besluten under implementationen och minskar riskerna för att det ska uppstå problem. Vi brukar säga att en timme i project readinessfasen sparar fem timmar i projektet. På Implema vill vi ha ”framtunga” projekt där mycket händer i början.
Project readiness minskar alltså projektrisken, sparar tid och pengar och gör det lättare att komma igång snabbt med implementationen. Det blir extra värdefullt om man som Implema väljer standard, guidar kunden till beslut och arbetar i små, snabba inkrement.
Sist men inte minst kan det göra att kunden får ut ett större affärsvärde av systemet eller applikationen – med betydligt lägre risk.
Från projektmål till core definition
Project readinessfasen ska helst gå igång ett par månader före projektets go-live-datum, framför allt för att ge kundens organisation tillräckligt med tid.
Vi delar upp project readinessfasen i ett antal steg där varje steg bygger på de föregående.
1. Projektmål
I början brukar vi brainstorma fram idéer kring vad som skulle möjliggöra effektivare arbetssätt och realiserade affärsmöjligheter. Vi rankar idéerna utifrån betydelse – till exempel affärsvärde eller nyttan för användarna – och svårighet – till exempel utvecklingskostnad och hur mycket support som skulle krävas. Det gör det lättare att sen sätta målen, som givetvis ska förankras väl inom kundens organisation.
2. Omfattning
Definiera målbilden både på längre sikt och för vad projektet ska göra (scope). Tänk på att få med en kommunikationsplan och en plan för förankring av projektet. För att lyckas gäller det att ha ett tydligt svar på frågan ”Varför gör vi det här?”
3. Processer
Jag tror att det finns ett glapp mellan ”ren implementation” på funktionsnivå och nivån en strategikonsult brukar röra sig på. Ett glapp IT-konsulten skulle kunna fylla. Ofta räcker det med en överflygning där man identifierar och beskriver företagets huvudprocesser, t ex purchase to pay eller order to cash.
4. Testfall
Definiera de affärskritiska processerna och fundera på hur de ska testas. Definiera scenarios för regressionstester. Det är en viktig input till projektplaneringen och minskar risken för missförstånd.
5. Masterdata
Masterdatan är A och O.
Här tar du beslut om vilken masterdata som ska föras över och hur. När har den senaste transaktionen skett? Hur aktuell är datan? Vilken ambitionsnivå ska ni ha?
Vilken kvalitet håller din data? Ett mått på kvalitet är hur kontaktuppgifterna för kunder och leverantörer stämmer. Behöver datan tvättas före projektet? Det kan räcka med ett enkelt men vanligt fel som att samma artikel har flera produktnummer. Tänk också på hur masterdatan ska förvaltas för att undvika dubbletter i framtiden. Företag som flyttat affärssystemet till molnet går ofta igenom en större förändring flera gånger per år, jämfört med tidigare när det kanske hände var sjätte eller sjunde år. Det gör det ännu viktigare att företaget ”committar sig” till en förvaltningsmodell för data i systemet.
6. Go-live-strategi
Hur ska systemet sättas i skarp drift: big bang, site för site eller en kombination av dessa? En big bang-strategi kräver en go live-simulering. Om ni väljer en site för site-strategi, bestäm vilken site som är lämplig som pilotsite. Ofta är det en mindre site som använder många gemensamma processer.
Tänk också igenom vilken bemanning utrullning kräver.
7. Core definition
Till sist, men verkligen inte minst, definieras projektets kritiska komponenter: masterdata, processbeskrivningar, arbetsinstruktioner och mallar.
Viktigt är också att få med en kommunikationsplan och en plan för change management – hur man ska jobba med sina processer. Att glömma att förankra projektet med användarna är ett vanligt misstag som kan leda till ett förändringsmotstånd redan under testperioden. Det kan visa sig genom att medarbetarna lägger sin energi på att försöka lista ut hur de ska kunna arbeta som de alltid har gjort.
Försök få organisationen att se bortom dagens begränsningar och identifiera ”to-be-läget” – hur de vill jobba – och vilka smärtpunkterna är som ska tas bort.
Kom igång
För att sammanfatta: det finns mycket att vinna på att ett projekt före projektet, där man förebygger onödiga riskmoment och gör grundjobbet i en ”sandboxmiljö” innan projektresurserna är uppbundna och projektets budget och tidplan står på spel.
I nästa steg startas implementationsprojektet där vi använder oss av Implemas unika implementationsmodell Implema Way. Med Implema Way utvecklar du ditt affärsstöd stegvis – snabbt, tryggt och kostnadseffektivt.
Bild: Implema Way är motorn i vårt värdeskapande för en trygg och hållbar resa mot framtidens affärssystem. Snabbt, tryggt och kostnadseffektivt.
Vår egen ”kreativa drivbänk”Implemas Inspire Labs kan hjälpa till i project readiness-fasen. Inspire Labs bygger på best practise i form av beprövade koncept som Design Thinking i kombination med erfarenhet och lärdomar från andra liknande ”labs”.
