Migrera inte ett flöde ni inte gillar

Ett systembyte är det enda tillfälle då en organisation utan protester accepterar att arbetssättet ses över. Använd det.

Den vanligaste missen är att bygga upp det gamla systemet igen i det nya, inklusive kategoristrukturen med sextio val som ingen fyller i korrekt och de åtta prioritetsnivåerna där bara tre används.

Att rätta det kostar ungefär lika mycket som att flytta det. Skillnaden är att ni sedan slipper leva med det i fem år till.

Vad som bör ses över på vägen

Kategoristrukturen. Titta på statistiken: vilka kategorier används faktiskt? Resten kan försvinna.

Prioritetsmodellen. Sätts prioritet efter påverkan och brådska, eller efter vem som ringer? Se ITSM för hur modellen bör se ut.

Tjänstekatalogen. Börja med de tio vanligaste beställningarna i stället för att flytta över allt.

SLA. Efterlevs de nuvarande nivåerna? Är svaret nej bör ni antingen ändra dem eller ändra bemanningen – att flytta med ett löfte ni inte håller hjälper ingen.

Förändringsprocessen. Om alla förändringar i dag är akuta är det ett tecken på att processen kringgås. Bygg den lättare den här gången.

Vad som flyttas

Ärenden och kontakter. Öppna ärenden i sin helhet, avslutad historik i den omfattning ni väljer. Två till tre år räcker för de flesta.

Tillgångar och konfigurationsdata. Hårdvara, licenser, garantier och beroenden – se CMDB och tillgångshantering. Är registret inaktuellt är det bättre att bygga om det än att flytta med felen.

Kunskapsartiklar. Ofta det största rensningsbehovet. Artiklar som inte öppnats på två år beskriver sannolikt system ni inte längre har.

Tjänstekatalog och SLA. Definitioner, godkännandeflöden och svarstider.

Så går det till

1. Kartläggning. Nuläget: processer, flöden, integrationer och vad som fungerar respektive skaver.

2. Konfiguration. Processer, tjänstekatalog, SLA, portal och integrationer mot Microsoft 365, Entra ID och övervakning.

3. Testmigrering. Data flyttas till en testmiljö först.

4. Verifiering. Ni testar mot verkliga fall. Hittar teknikerna rätt, fungerar eskaleringen, blir rapporterna användbara?

5. Utbildning. Tekniker och administratörer före övergången. Informera slutanvändarna om den nya portalen i god tid.

6. Skarp övergång. Normalt över en helg, med den gamla ingången kvar som hänvisning en period.

Var det brukar gå fel

Slutanvändarna glöms. Teknikerna utbildas, men de hundratals personer som ska använda portalen får veta det på måndagen. Det ger en onödig ärendetopp.

Allt ska med. Tio års historik och en kunskapsbas ingen rensat gör migreringen dyr och systemet trögt.

För många processer på en gång. Börja med incident och request. Förändring, problem och full CMDB kan komma i steg två.

Ingen ägare hos er. Någon måste kunna besluta om kategorier och SLA. Utan den personen står projektet stilla.

Varför vi

Inom ITSM är vi Nordens mest erfarna och största distributör och implementationspartner av HaloITSM. Vi arbetar på svenska, norska, danska och engelska i er tidszon.

HaloITSM kan driftas inom EU, i egen molnmiljö eller helt on-premise, vilket är avgörande för offentlig sektor och reglerad verksamhet.