Att använda Azure DevOps som projektstyrning i en ERP implementering

Azure DevOps (ADO) är ett väldigt bra verktyg för att stödja en ERP-implementering, helst redan från start. Exempelvis redan vid risk hantering och identifiering av applikationer för utfasning i och med systembytet. ADO benämns i generella termer som ett kvalitetssäkringsverktyg och stödjer användare där de kan verka i en strukturerad och fördefinierad miljö men med goda möjligheter till anpassning.

På så vis är ADO ett agilt verktyg och klarar av att hantera många olika behov från ett projekt team. Vi skulle vilja påstå att verktyget är rustat för att under hela livscykeln av en global ERP-implementering med ett projektteam på ca 30 personer exklusive systemleverantörens konsulter, kan stödja användare i att styra och driva projektets allra viktigaste delar.

I verktyget är det vanligt att man vill bygga upp en hierarki, för att säkerställa beroenden mellan olika så kallade "items" eller på svenska, "objekt", men även för att få en tydlig struktur. Här är ett exempel på hur man i ADO kan bygga upp en nivåstruktur som kan beskriver relationer mellan olika items. I denna artikel kommer definitionen objekt ersätta begreppet "items".

Baserat på tidigare erfarenheter av en global ERP-implementering kan vi därigenom understryka att många delar som behövs för projektstyrning går att hantera i ADO. Dessa är endast några exempel på de delar som vi har använt verktyget till:

• Risk/bristhantering (innan, under och efter projektet).

• ÄTOR

• Release management (Ny funktionalitet som rullas ut av systemleverantör, från ÄTA till deployment).

• Loggning av beroenden samt analys

• Test scenarios (End-to-end)

• Testfall, vi hade ca 500 test cases i ADO (1 test scenario kan innehålla flera testfall)

• Lista över alla lokala applikationer för utfasning

• Utveckling och utrullning av fakturalayouter

• Buggrapportering

• Ärendehantering (efter go-live) som integreras mot externt källsystem, t.ex.Tieto.

• Team board för veckovis uppföljning för varje team i projektet

• Dashboards för uppföljning av buggrapportering i realtid

• Dashboards för uppföljning av testfall i realtid

För att illustrera hur vi arbetade med objekt i ADO tog vi med ett verkligt exempel på hur ett objekt kan se ut i ADO på detaljnivå. I detta fall är det en ovanligt tom ÄTA som har identifierats och om den godkänns så ska denna ÄTA utvecklas och sedan paketeras så att den ingår i kommande utrullningspaket av ny funktionalitet. Vad för information kan då användaren se i denna vy?

1. Unikt ID som är sökbart vart som helst i ADO, här kan användaren även tilldela en ägare till objektet.

2. En beskrivning av objektet och dess omfattning, ingen märkbar begränsning i textmängd.

3. Forum för att diskutera aktuella delar för det specifika objektet, här går det även att tagga personer. När en användare taggar en annan person i diskussionsforumet så får den taggade personen ett mail.

4. Ytterligare fält som går att anpassa själv utifrån vilka informationsbehov man har. Det går även här att fördefiniera vilka värden som går att välja per fält.

5. Relaterade objekt går att finna under "Related Work". Detta kan vara en av de viktigaste delarna i ADO då det är i denna kolumn allting hänger ihop. Om vi säger att detta objekt skulle ha en task som säger "Godkänd för utveckling" så kan man koppla det beslutet till detta objekt, vilket ger en spårbarhet på objektsnivå. Under vår ERP-implementering har denna del av ADO varit väldigt värdefull.

Utöver den information som kan hittas via ett objekt så finns det även en meny till vänster i verktyget. Här kan användaren lätt navigera till verktygets olika delar. "Queries" är en central funktion i som ger användaren möjlighet att själv skriva egna frågor/anrop för att få fram information som kan vara värdefullt för just denne persons behov, vilket är mycket användbart.

"Boards" kan används på många olika sätt, som det mesta i ADO. Styrkorna med en board är att det är användarvänligt med drag and drop-funktioner. En board används på bästa sätt enligt vår erfarenhet, när ett team i projektet själva får konstruera upp en board med deras egna kolumner utifrån deras behov. Ett bra sätt att arbeta med en board är att ha veckovis möten där man följer upp, hanterar och prioriterar interna teamaktiviteter som sedan kommuniceras ut till hela projektteamet.

Nedan får ni ett exempel på hur en board kan se ut. Målsättningen med en board oavsett objekt eller team är att man ska få en överblick. I och med överblicken över aktuella objekt får teamet möjligheten till att kunna följa objektets resa från att det adderas i kolumnen längst till vänster och sedan stängs när objektet har lösts eller hanterats.

En av de mest kritiska delarna efter en go-live av en ERP-implementering handlar om att kunna bedriva release management på ett sätt där projektteamet med enkelhet kan rulla ut ny funktionalitet till slutanvändarna. Utöver utrullning av ny funktionalitet är det viktigt att även kunna hantera eventuella så kallade "emergency releases". Emergency releases kan till exempel vara när en användare har identifierat en kritisk bug i systemet. Som projektteamet och systemleverantören behöver mititgera och lösa inom kort för att exempelvis säkerställa användaracceptansen i tidigt skede. ADO har flera olika bra funktioner för att få korrekt styrning på release management. Bilden nedan visualiserar en dashboard där användare kan på ett tydligt sätt se vilka items som ingår i en specifik release. Denna dashboard ägs rimligtvis av den person som är utsedd till release manager i projektet, vilket är den person som driver/planerar upp när ny funktionalitet ska och kan rullas ut.

1. En föreslagen paketerad release med ett namn som överenstämmer med den övergripande utrullningsplanen gjord av release manager.

2. En prioritering är gjord på enskild ny funktionalitet som ska rullas ut. Prioriteringen görs rimligtvis av den person som är "assigned to" i samarbete med systemleverantör och utrullningsteam för att säkerställa att den funktionalitet som rullas ut helst möter ett rådande behov från slutanvändaren i den befintliga lösningen.

3. I dashboarden kan du som användare även se vem som äger vilket item, vem den är skapad av och vilket datum.

4. Godkända items, paketerade och i detta skede redo för utveckling. I detta exempel har vi i punkt 1, 24 stycken föreslagna items som kan tänkas ingå i kommande utrullning. Av dessa 24, utifrån den prioritering som gjorts och diskussion med systemleverantörens utvecklingskapacitet kan projektteamet paketera den slutgiltiga listan innehållande endast 6 items (i detta fall lösningar på buggar) som kan ingå i nästkommande release.

Efter att vi har använt Azure DevOps under en längre period i en stor ERP-implementering har vi samlat på oss några erfarenheter som till stor del baseras på det som redan nämnts i inlägget. Men i sammanfattande form hoppas vi att ni får en ytterligare inblick i verktygets funktionalitet och kapacitet.

Några positiva erfarenheter:

• ADO är skapat för att centralisera information - en bild av verkligheten till alla intressenter i projektet

• Kan användas för att bedriva en strukturerad release management

• Kan hantera nämnda delar i en ERP-implementering för över 10 000 användare

• Tydlig hierarkisk struktur med överordnade objekt som kan ha flera subobjekt

• Detaljerade beroenden på objektsnivå som ger ovanligt god insikt

• Det finns goda möjligheter till att skapa team boards för att bedriva daglig/veckovis uppföljning

• Ingår i en vanlig Enterprise O365 licens

Några mindre positiva erfarenheter:

• Eftersom att ADO är ett agilt och anpassningsbart verktyg finns risken att användare anpassar "sönder" verktyget. Detta kan leda till extra handpåläggning och förvirring för alla användare.

• Verktyget är så pass djupt i sin funktionalitet att det krävs utbildning för nya användare att sätta sig in i både standardlösning samt de eventuella anpassningar som gjorts för att bedriva projektstyrningen på bästa möjliga sätt.

Om du och ditt företag funderar på att byta affärssystem och behöver extern kompetens för att driva och styra en ERP-implementering får ni gärna kontakta oss på ERP & Friends här.