IT Service Management har vært et kjent og kjært begrep i mange år, og er uløselig knyttet til ITIL og et stort regime av prosesser. ITSM-prosjekter har vært gjennomført i mange organisasjoner, og i de fleste av dem flere ganger. Mange er i dag på sin 3. eller 4. generasjon av ITSM-løsning. Men har prosjektene levert som forventet?
Som leverandør og konsulent innen ITSM-markedet har jeg både observert våre egne leveranser, konkurrentenes leveranser og hva kundene selv gjør – og sier. Altfor ofte hører man om de mislykkede prosjektene, om alt som gikk galt. Skylden legges på verktøyet, evt. leverandøren, og kunden kjører en ny anskaffelsesrunde for å få det «riktige» verktøyet. Når så dette feiler etter 3-5 år, starter neste runde.
Hva er det egentlig som går galt? Er det umulig å få en ITSM-løsning til å virke? Er alle produktene på markedet (og dem er det mange av!) elendige?
La oss se på en typisk ITSM anskaffelse, fra unnfangelse til fullskala anvendelse. Mange prosjekter ser først på to ting: Prosessene og verktøyet. Ofte leies det inn en ITIL prosesskonsulent (hvis man ikke har en «ITIL guru» eller to i egen organisasjon) som skal designe de ultimate prosessene for organisasjonen. Og nå som ITIL er blitt så omfattende, betyr det i hvert fall et tyvetalls prosesser! Dermed blir prosessjobben stor (og kostbar). Så lager man en kravspesifikasjon med tekniske krav i tillegg til prosessene. (Noen forenkler denne jobben ved å skaffe seg en ferdiglaget spesifikasjon, som gjerne kan være noen år gammel, og følgelig teknisk utdatert!).
Forespørselen som sendes ut i markedet (her er det store forskjeller mellom private og offentlige virksomheter) og man mottar tilbud. Disse omfatter gjerne et standardprodukt (for installasjon hos kunden eller som en SaaS-basert skyløsning) en rekke, ofte omfattende, tilpasninger (for å støtte de beskrevne prosessene) og noe opplæring.
Dette kan virke tilforlatelig, men når man analyserer hvor pengene brukes i slike prosjekter, så er det veldig mye (om ikke det meste!) som går med til prosessdesign i forkant og tilpasning av verktøy til disse prosessene i etterkant. Dette skjer til tross for at de aller fleste verktøy i markedet bygger på ITILs prosessverden, både i terminologi og struktur. Hvorfor skal man da egentlig tilpasse så mye?
De fleste ITSM-prosjekter jeg har sett som feiler, skyldes enten innfløkte prosesser, omfattende tilpasning eller fullstendig bom i utarbeidelsen av forespørselen. Vi har mottatt anbudsinnbydelser hvor vi kjenner igjen tekniske kravspesifikasjoner fra andre kunder – som anskaffet en løsning fem år tidligere! Hvor mye har ikke IT (ikke minst programvare!) endret seg på fem år? Senest i forrige uke sa vi «nei takk» til å besvare en kravspesifikasjon, som vi sikkert ville besvart for tre år siden. Men vi vil ikke levere gårsdagens løsning i dag.
Stephen Mann, som bl.a. skriver for ITSM.tools, har skrevet en kort, men god, gjennomgang av typiske utfordringer med etablerte ITSM verktøy: The Key Issues with Legacy ITSM Tools.
Moderne ITSM-løsninger bygger på teknologi som gjør løsningen tilgjengelig overalt, på alle plattformer. De er fokusert på brukeropplevelsen, og er like enkle å bruke som IT-løsningene man benytter som konsument. Emner som kunnskapshåndtering, analyse og automatisering av oppgaver gjennomsyrer løsningene, og det er fokus på at sluttbrukeren kan hjelpe seg selv – og sine kolleger – uten å måtte kontakte en servicedesk. Og funksjonaliteten oppdateres kontinuerlig, ikke gjennom 3-5 års «product roadmaps».
Oppsummert: ITSM-prosjekter feiler fordi man er mer fokusert på spesifikasjoner enn løsning, på prosessdetaljer heller enn brukervennlighet.
