Halva projektet handlar om människor

Ett ITSM-system kan konfigureras på några veckor. Att få en organisation att sluta mejla teknikern de brukar mejla tar längre tid.

De implementationer vi sett misslyckas har nästan aldrig fallit på tekniken. De har fallit på att processen upplevdes som ett hinder, och då kringgås den. En kringgången process ger sämre spårbarhet än ingen process alls.

Planera därför in kommunikation och förankring som en del av projektet, inte som något som sker efteråt.

Börja med två processer

Den vanligaste missen är att införa hela ITIL på en gång.

Incidenthantering först. Störst volym, tydligast nytta och enklast att få med sig folk på. Registrering, kategorisering, prioritering och tilldelning.

Därefter request. Beställningar via tjänstekatalog med godkännandeflöden. Börja med de tio vanligaste – inte med en katalog på sextio poster.

När de två fungerar och statistiken börjar bli användbar är det dags för förändringshantering, problemhantering och CMDB. Då finns dessutom underlag för att bygga dem rätt.

Vad ni bör förbereda

En bild av nuläget. Hur många ärenden kommer in, hur, och vad handlar de om? Har ni ingen statistik är det i sig ett av skälen att införa systemet.

En utsedd systemägare. Någon med mandat att besluta om kategorier, prioriteringsregler och SLA. Utan den personen står projektet stilla mellan mötena.

Vilka tjänster ni faktiskt levererar. Svårare än det låter, och grunden för både tjänstekatalog och SLA.

Kravbilden ni måste uppfylla. Revision, ISO-certifiering eller NIS2 påverkar hur förändringshantering och loggning ska byggas. Ta med det från början i stället för att bättra på efteråt.

Faserna

Kartläggning. Nuläge, tjänster, flöden, integrationer och målbild.

Grundkonfiguration. Ärendetyper, kategorier, prioritetsmodell, SLA, behörigheter och köer.

Portal och tjänstekatalog. Självservice för de vanligaste beställningarna, med godkännandeflöden där de behövs.

Integrationer. Microsoft 365 och Entra ID först, därefter övervakning och dokumentation.

Automatisering. Tilldelning, eskalering och kontohantering vid on- och offboarding – se automation.

Utbildning och lansering. Tekniker och administratörer först, sedan information till slutanvändarna innan portalen öppnas.

Uppföljning. Efter några veckor i drift justerar vi kategorier, SLA och flöden mot hur det faktiskt används.

Portalen avgör hur projektet upplevs

För de flesta i organisationen är självserviceportalen hela ITSM-projektet. Det är den enda delen de ser.

Den måste därför vara snabbare än att mejla. Ett fåtal tydliga val, förutsägbar återkoppling och inga formulär med tjugo obligatoriska fält. En portal som upplevs som krånglig förlorar mot den delade mejlkorgen varje gång, oavsett vad ledningen beslutat.

Var det brukar gå fel

För många kategorier. En struktur med sextio val fylls i slarvigt och blir därmed värdelös som underlag.

SLA som inte hålls. Sätt nivåer ni klarar med nuvarande bemanning. Ett löfte ni bryter varje vecka är sämre än inget löfte.

Förändringsprocessen byggs för tung. Om allt kräver godkännande blir allt akut i stället. Börja lättare än ni tror att ni behöver.

Slutanvändarna informeras för sent. Portalen öppnar på måndagen och ingen vet varför. Det ger en onödig ärendetopp och dåligt första intryck.

Varför vi

Inom ITSM är vi Nordens mest erfarna och största distributör och implementationspartner av HaloITSM, och vi levererar även Freshservice. Vi kan därför utgå från vad ni behöver i stället för från vad vi har att sälja.

Ska ni byta från ett befintligt system, se migrering till HaloITSM.