Syv grep for å lykkes med IT-tjenestekatalogen

Etter år i rådgivningsoppdrag ser jeg at flere virksomheter og interne IT-enheter ikke har funnet den gode tilnærmingen til bruk og vedlikehold av sin IT-tjenestekatalog. Om det kan være til trøst har jeg også sett at det ofte ikke skal så mye til for å forbedre situasjonen. 

Mange IT-enheter i virksomheter har ofte ikke etablert en tjenestekatalog i det hele tatt, og flere sliter med å avklare forventninger til sine leveranser.  Dette kan imidlertid være et symptom på dypereliggende organisatoriske og avtale-relaterte problemer som ikke er tema for dette innlegget.  Her skal vi fokusere på frukter som henger litt lavere.

En god tjenestekatalog bidrar til klarhet kundedialog og brukerdialog, og kan være et godt forretningsmessig fortrinn. Her er syv konkrete grep du kan ta for lykkes med den:

1: Hold orden på de tilgjengelige og på de avtalte abonnementene i tilpassede visninger

Tjenestekataloger kan ha en del ulikheter avhengig av virksomhetskontekst.  En kommersiell aktør bør ha strukturert katalogen sin slik at den har ulike visninger.  Eksisterende og potensielle kunder bør enkelt kunne finne ut av hvilke tjenester som er tilgjengelige (som det kan abonneres på).  Leverandørens driftspersonell og kundens brukere har samtidig også bruk for den samme strukturerte informasjonen om hvilke opsjoner og hvilket tjenestenivå som gjelder for leveransen.  En virksomhetsintern leverandør kan tone ned «salgsvisningen» av katalogen til fordel for en visning av de gjeldende avtalte tjeneste-abonnementene. Uansett visning kan alle ha behov for en struktur som kategoriserer tjenestene i funksjonelle områder.

2: Skill på tjenestekatalog og bestillingskatalog

ITIL-rammeverket skiller med god grunn på begrepene Service Catalog og Service Request Catalog. Likevel ser vi at flere leverandører av ITSM-saksbehandlingsverktøy roter til begrepene i sin verktøystruktur.  Det gjør det lett for de som ikke har lest seg opp på forskjellen å bli villedet.

Tjenestekatalogen viser tjenestene med definerte tjenestenivåer (SLA), aktuelle opsjoner, kritikalitet, kontaktinformasjon og liknende attributter som hører til abonnementet. Bestillingskatalogen derimot er en oversikt over varer, tilganger og tidsavgrensede ytelser som kundens brukere kan be om.  Enten «gratis» eller mot betaling avhengig av hvordan dette er merkantilt avklart.

Så blir det litt mer komplekst: Alle bestillinger bør knyttes til en tjeneste.  Det gjør det blant annet lettere å holde oversikt over leverte volum og trender. For eksempel: Har en bruker bestilt og fått installert Adobe Photoshop, kan hun senere ha behov for brukerstøtte.  En slik tjeneste kan omfatte en større portefølje av applikasjoner og for eksempel hete «Desktop brukerstøtte».

3: Ikke gå i applikasjonsfella

Enhver applikasjon som er tilgjengelig for brukerne bør ikke være selvstendige tjenester.  Der tjenestekatalogen er bygget slik, er det gjerne et symptom på at man har forsøkt å gjøre den også til et register som fungerer for styring av applikasjonsporteføljen.  Hvorfor det over tid går dårlig er tema for en annen gjennomgang, så det utsetter vi inntil videre. Helt overordnet vil jeg imidlertid peke på at behov og krav til verktøy for en tjenestekatalog sammenliknet med et register for styring av en applikasjonsportefølje, er ulike. Settet av attributter man trenger vil være ulike.

4: Ikke gå i forvaltningsfella

Dette er applikasjonsfellas nære slektning.  Jo mer granulert tjenestekatalogen er, jo flere tjenestebeskrivelser, definerte roller, HUKI/RACI-diagrammer, detaljerte avtaler og detaljert kundedialog kan bli forventet. Det er lett å gå skoene av seg uten noensinne å bli á jour!

Her gjelder det å finne ut av hva som er «godt nok» og vurdere hvilke applikasjoner som kan leveres på samme måte, med samme kritikalitet og øvrige opsjoner, slik at de kan grupperes til større leveranse-enheter.

5: Gå for standardiserte attributter der det er mulig

Det enkle er som kjent ofte det beste: Hvordan tjenester leveres bør kunne uttrykkes på en standardisert måte.  Tjenestenivå kan eksempelvis kategoriseres som «gull, sølv, bronse» og forvaltningsomfang som for eksempel «lite, medium, stort».  Slike verdier må selvsagt også defineres og publiseres på en måte som er tilgjengelig for interessentene.

Uten standardisering blir det lett slik at de må beskrives i detalj for hvert objekt i katalogen.  Enten gjør det katalogen veldig tung å lese, eller så må den inneholde en rekke pekere til mer informasjon.  Ingen av delene er gunstig for katalogens posisjon som autoritativ informasjonskilde.

Liten grad av standardisering fører fort til stor grad av uønsket variasjon fra leverandørens ståsted.  Men uønsket variasjon for leverandøren er også oppskriften på mer tungdrevne tjenester og lavere kundetilfredshet.

6: Gjør tjenestekatalogen til ryggraden i IT-saksbehandling

Alle henvendelser fra kunders brukere om ønskede endringer, feilretting, forespørsler og andre hendelser må kunne hektes på en tjeneste.  Påstand: Uten en slik logging får man rett og slett ikke kontroll på egen effektivitet.

Forutsetningen for å få til dette er naturligvis at tjenestekatalogen og dens attributter er oppdatert i det saksbehandlingsverktøyet som brukes for IKT-henvendelser.  For de fleste virksomheter vil det innebære at saksbehandlingsverktøyet er den autoritative datakilden for kataloginformasjon, og der denne skal oppdateres .  Tjenesteleverandøren må bygge opp sine rutiner og prosesser for tjenesteinformasjon tilsvarende.

7: Søk hjelp i tide

Uansett hvor langt din virksomhet er kommet på veien mot en fungerende tjenestekatalog, er det dessverre mulig å møte hindringer som sperrer for suksess.  Trøsten er at det er andre som har vært der før, og at det finnes rådgivere som kan hjelpe dere videre.

Les også: Valg av ITSM-verktøy: Seks konkrete tips

Legg igjen en kommentar