Så lyckas ni med en stegvis utrullning av HaloITSM

Om man ändå ska byta plattform vill man gärna samtidigt få ordning på portal, ärendehantering, kunskapsdatabas, integrationer, automation, asset management och rapportering. Det är lätt att förstå.

Men i praktiken är det ofta just kombinationen av alla dessa delar som gör projektet tyngre än nödvändigt. En stegvis modell gör det lättare att fokusera, testa och få användarna med sig från början.

Varför stegvis utrullning ofta ger bättre resultat

Den största fördelen med en stegvis utrullning är att ni kan fokusera på det som skapar värde först. Istället för att bygga en stor och komplex lösning direkt kan ni börja med kärnprocesserna, få dem att fungera bra i praktiken och sedan bygga vidare utifrån verkliga behov och erfarenheter.

Det ger ofta flera positiva effekter:

• Snabbare väg till nytta.
• Lägre projekt- och implementationsrisk.
• Enklare testning.
• Bättre användaradoption.
• Större möjlighet att justera upplägget efter verklig användning.

Det här är särskilt relevant i HaloITSM, eftersom plattformen är flexibel och går att bygga ut över tid. Just därför finns det också en risk att vilja göra för mycket på en gång.

En stegvis utrullning är inte ett tecken på låg ambition. Det är ofta ett tecken på att implementationen är genomtänkt.

Börja inte med allt

Ett vanligt misstag är att försöka lansera hela målbilden i första fasen. Det kan innebära att man samtidigt vill få på plats flera ITIL-processer, avancerade workflows, full portalstruktur, kunskapsdatabas, CMDB eller asset management, flera integrationer, rapportpaket och automatisering i stor skala.

Problemet är inte att dessa delar är oviktiga. Problemet är att kombinationen snabbt ökar komplexiteten. När för mycket ska in i första releasen blir det svårare att prioritera, svårare att testa och svårare att få en stabil start.

• Definiera vad som verkligen måste fungera från dag ett.
• Skilj på målbild och första release.
• Bygg en roadmap istället för att stoppa in allt i fas 1.

Vad bör ingå i fas 1?

Det varierar mellan organisationer, men för många är det klokt att börja med de delar som direkt påverkar den dagliga leveransen. Fas 1 innehåller ofta incidenthantering, service requests, grundläggande self-service-portal, enklare kategorisering och routing, tydliga team- och ansvarsfördelningar, grundläggande SLA-struktur och ett begränsat antal prioriterade integrationer.

Målet i fas 1 bör inte vara att bygga allt. Målet bör vara att skapa en stabil, begriplig och användbar grund. Det är ofta bättre att lansera en enklare lösning som fungerar väl än en mer avancerad lösning som blir svår att använda eller förvalta.

• Välj det som påverkar leveransen här och nu.
• Prioritera stabilitet och begriplighet framför omfattning.
• Se fas 1 som grunden, inte som hela målbilden.

Vad kan vänta till fas 2 och 3?

När grunden fungerar blir det mycket enklare att bygga vidare. Fas 2 och 3 kan ofta innehålla mer avancerad automation, fördjupad portalstruktur, utökad kunskapsdatabas, fler integrationer, asset management eller CMDB-funktioner, dashboards och rapportering, ytterligare processer som change eller problem management och mer detaljerade godkännandeflöden.

Det viktiga är att inte se det som att något “saknas” bara för att det inte ingår i första lanseringen. Tvärtom är det ofta ett tecken på att implementationen är genomtänkt.

• Planera nästa steg tidigt, men bygg dem inte för tidigt.
• Låt verklig användning påverka vad som prioriteras härnäst.
• Skapa struktur för vidareutveckling istället för att pressa in allt från början.

En stegvis utrullning gör testning enklare

Testning blir nästan alltid bättre när lösningen införs stegvis. Om första fasen har tydligt avgränsad funktionalitet går det också att testa mer noggrant. Ni kan följa verkliga scenarier, identifiera flaskhalsar, upptäcka oklarheter i processerna och justera innan plattformen byggs ut ytterligare.

Det skapar en stabilare grund för nästa steg. När för mycket lanseras samtidigt blir testningen ofta bred men ytlig. Då upptäcks många problem först efter go-live.

• Avgränsad funktionalitet gör testningen skarpare.
• Det blir lättare att justera innan nästa fas.
• Färre delar i första releasen minskar risken för överraskningar efter go-live.

Användaradoption blir bättre när förändringen är begriplig

En ny ITSM-plattform är inte bara ett tekniskt byte. Det är också en förändring i hur människor arbetar. Om användarna möts av en lösning som är för omfattande eller för komplex från start ökar risken för motstånd, osäkerhet och låg användning.

Med en stegvis utrullning blir förändringen mer begriplig. Användarna får lättare att förstå vad som är nytt, vad de förväntas göra och hur plattformen hjälper dem i vardagen. Det gäller både slutanvändare, servicedesk och andra interna team.

• Gör förändringen lättare att ta till sig.
• Skapa snabb nytta för användarna tidigt.
• Bygg vidare när arbetssätt och förståelse börjar sätta sig.

En realistisk roadmap skapar bättre styrning

En stegvis utrullning kräver att ni tänker roadmap från början. Det betyder att ni redan tidigt behöver veta vad som ska in i fas 1, vad som prioriteras senare, vilka beroenden som finns, vilka resurser som krävs i nästa steg och hur ni ska följa upp effekt och användning efter varje fas.

Det ger ett bättre beslutsunderlag och gör det lättare att hålla ihop implementationen över tid. Istället för att projektet växer okontrollerat får ni en tydligare riktning och en mer hållbar prioritering.

• Roadmapen ger struktur åt det som inte byggs nu.
• Ni får bättre kontroll på beroenden och beslut.
• Det blir lättare att hålla ihop implementationen över tid.

Vanliga misstag i stegvis utrullning

Det räcker inte att säga att utrullningen ska vara stegvis. Upplägget behöver också göras rätt. Vanliga misstag är att fas 1 ändå blir för stor, att roadmapen för senare faser är för otydlig, att organisationen tror att “stegvis” betyder långsam eller ofärdig, att ägarskapet efter go-live är oklart och att förbättringar inte prioriteras strukturerat efter första lanseringen.

En bra stegvis modell är inte ett sätt att skjuta upp beslut. Det är ett sätt att fatta bättre beslut i rätt ordning.

• Undvik att kalla något stegvis om fas 1 ändå innehåller allt.
• Var tydliga med varför senare faser kommer senare.
• Säkerställ att förvaltning och ägarskap finns efter första lanseringen.

Hur ni vet att fas 1 är rätt avgränsad

En bra kontrollfråga är om er första release går att beskriva enkelt. Om ni tydligt kan svara på vilka processer som ingår, vilka användargrupper som påverkas, vilka integrationer som måste fungera, vad som är affärskritiskt vid go-live och vad som väntar till nästa steg, då är ni ofta på rätt väg.

Om svaret däremot blir långt, otydligt eller fullt av undantag är det ofta ett tecken på att scope fortfarande är för stort.

• Kan ni beskriva fas 1 enkelt är ni ofta rätt ute.
• Blir beskrivningen för lång är scope ofta för stor.
• En tydlig första release gör också kommunikationen enklare internt.

Vår rekommendation: bygg en stabil grund först

De mest lyckade HaloITSM-implementationerna är sällan de som försöker göra mest från början. De lyckas oftare för att de börjar med rätt scope, prioriterar tydligt, testar ordentligt, skapar tidig nytta och bygger vidare i takt med att organisationen blir mogen.

Det gör inte implementationen mindre ambitiös. Det gör den mer realistisk och mer hållbar. Vill ni läsa mer om hur Zitac arbetar med HaloITSM kan ni besöka vår partner-sida för HaloITSM.

Vill ni planera en stegvis och trygg utrullning av HaloITSM?

Zitac hjälper organisationer att definiera rätt scope, bygga en hållbar roadmap och få rätt delar på plats i rätt ordning, så att plattformen fungerar i vardagen och går att bygga vidare på.

Prata med en specialist Kontakta Zitac

Officiell HaloITSM-partner i Norden

Vanliga frågor om stegvis utrullning av HaloITSM