Att anamma ett agilt arbetssätt vid ERP implementationer verkar vara på allas läppar. Det är egentligen inte så konstigt. Förändringstakten går allt snabbare i de flesta branscher i kombination med att mjukvaruföretagen släpper uppdateringar i en allt högre takt. Det gör det praktiskt taget omöjligt att förutse en verksamhets behov långt i förväg. Detta gäller inte minst Microsoft och Dynamics 365 där nya releaser numera släpps månadsvis.

Superentreprenören Gary Vaynerchuck (@garyvee) har en gång sagt:

”Its all about adjusting along the way… not making the perfect call. Life is about half time adjustments, not making the perfect game plan”. 

Utöver entreprenörskap är denna inställning definitivt applicerbar även på komplexa förändringsprojekt så som ERP implementationer. Efter att ha jobbat med ERP implementationer i över 10 års tid ser jag en tydlig trend mot att ”time to market” blir allt viktigare bland våra kunder. Man vill snarare go-live tidigt med begränsad funktionalitet för att därefter fortsätta affärsutvecklingen parallellt med utvecklingen av det nya systemet. Ofta används begreppet ”MVP” – Minimum Viable Product för att beskriva minsta gemensamma nämnare för att kunna gå i drift med en lösning som ändå skapar värde för verksamheten.

Agilt, men hur?

Det publiceras dagligen inlägg på temat ”Att jobba agilt” men väldigt sällan får läsaren konkreta tips på vad man bör tänka på vid planering och genomförande av sprintar. Nedan listas sex konkreta tips baserat på min erfarenhet:

Antal sprintar

Optimalt antal sprinter skiljer sig givetvis per projekt och är i hög grad beroende av bland annat omfattning och tidplan. Färre sprintar minskar graden av flexibilitet medans fler sprintar riskerar att bygga overhead. En gyllene medelväg när man pratar ERP implementationer och en första release är enligt min erfarenhet att hålla sig till ca 3-5 sprintar.

Sprintplanering

Krav från verksamheten dokumenteras löpande i en backlog. Områdesansvariga säkerställer prioritering och att kraven beskrivs på ett så utförligt sätt så möjligt. Projektet jobbar nära verksamheten för att på bästa sätt förstå behovet, rekommendera och tidsuppskatta föreslagen lösning samt vid behov utmana önskemål på anpassning eller arbetssätt till förmån för standard. Under pågående sprint så planeras och låses innehållet för nästkommande sprint. Viktigt lärdom är att IT ej skall ses som en bromskloss för affärsutvecklingen utan snarare som en möjliggörare där samtliga krav fångas in, dokumenteras och slutligen prioriteras utifrån verksamhetens behov.

Sprintinnehåll

Målsättningen bör vara att varje sprint innehåller exempel på följande:

  • Nya krav – Hämtas från backloggen och har konkretiserats och prioriterats av projektet.
  • Buggrättningar – Buggrättningar baserat på tester från föregående sprint.
  • Stabilisering – Stabiliserande åtgärder för att i slutändan realisera en bättre användarupplevelse, både för den interna användaren men även för externa aktörer så som kunder och leverantörer.

Viktigt att man lämnar varje sprint men en bättre produkt än vad man började med. Kvalité måste alltid vara ledordet. Dvs man bör vara extremt noga med att inte bygga ”teknisk skuld” som man tar med sig till framtida sprintar. Då är man extremt farligt ute.

Verktyg

Det finns ett flertal verktyg ute på marknaden för att just administrera sprintplanering och genomförande. Om valet faller på Jira, VSTS eller annat verktyg är sekundärt, viktigast att tänka på här är att man väljer ett system som verksamheten och projektet känner sig bekväm med och som främjar ett enkelt och effektivt användande

MVP

Minimum Viable Product. Jag kommer tillbaka till det här begreppet igen eftersom jag tycker det är extremt viktigt. Att kombinera att agilt arbetssätt med ett MVP fokus är extremt effektiv om ”time-to-market” är centralt i projektetstrategin.

Go-live endast ett delmål

Slutligen, go-live är inte slutet på resan utan snarare ett delmål. Planera projektet på ett sätt som gör att det finns ett driv och en ork inom organisationen att fortsätt utveckla processer och system även efter go-live. För en sak är säker, omgivningen kommer att fortsätta att utvecklas och nya funktioner kommer släppas i en allt högre takt, inte minst av aktörer som Microsoft och plattformar som Dynamics 365 så bli inte alltför bekväm, då riskerar ni att bli omkörda av konkurrenterna.

Vad är era bästa tips när det kommer till att arbeta med sprintar vid en ERP implementation? Dela gärna med er av synpunkter och kommentarer.

Mer om Dynamics 365 hittar du på Acandos webbplats.

/Tobias Lång

D365 Chief Solution Architect @Acando