Masterclass: Pureservice klassifisering

Dette innlegget tar for seg eksempler for en IT-organisasjon/avdeling. Ønsker du å vite mer om hvordan klassifisering i Pureservice passer for deres virksomhet, ta kontakt med deres Customer Success Manager.

Med korrekt bruk av klassifisering i Pureservice kan dere oppnå et ekstremt høyt nivå av kontroll på alle henvendelser. All klassifisering bestemmes av deres behov og situasjon. Hva trenger dere å se, og hva trenger dere å kunne rapportere på for et beslutningsgrunnlag til senere?

Trenger dere å se hvor mange rapporteringer om feil eller hendelser dere får på hvert område dere støtter, slik at dere kan vurdere hvor dere skal legge fokus på forbedringer?

Skulle dere ønske å vite hvor mange spørsmål om hjelp dere får på officepakken, slik at dere kan vurdere å lage gode FAQ’er for å få antallet ned?

Har dere en kunde som krever å få se rapport over alle sine tjenesteforespørsler hvor avtalt SLA er brutt de siste 3 månedene?

Ønsker dere grunnlag for å finne ut hvor lang tid andrelinje i snitt bruker på å løse enkle bestillingssaker, slik at dere kan lage en plan for å levere dette til førstelinje?

Dersom noe av dette høres interessant ut, så må vi ha god og solid klassifisering. Heldigvis er dette ganske enkelt. Klassifisering består hovedsakelig av følgende i Pureservice:

• Kilde
• Sakstype
• Kategori
• Prioritet
• Egendefinerte felter

Klassifiseringen gjør det mulig å bygge et datagrunnlag for fremtidige avgjørelser, samt å være kriterier for egendefinerte arbeidsflyter.

Kilde

Kilde brukes for å definere hvor saken kom fra. Som standard kommer Pureservice med tre kilder:

• Telefon
• Self-service
• E-post

Disse tre er lagt inn med noen regler som kobler de på standard kilde ved direkte opprettelse av sak i grensesnitt, på saker som kommer inn via e-post, og når saker opprettes fra selvbetjeningsportalen. Disse tre er allerede ganske solide kilder og vil dekke behovet for de fleste. Med disse kildene kan dere “out of the box” få en del kontroll på hvor sakene deres kommer fra.

Andre kilder kan for eksempel være “Direkte Oppmøte”, “Leverandør”, “Faktureringsystem”. Hvis dere ønsker å ta inn alarmer i Pureservice kan dere legge inn en generell “Monitoring” kilde eller til og med granulere dette ned til for eksempel “SCOM”, “Icinga”, “Appdynamics” for å senere filtrere sakslistene på hvilket system som har generert alarmene. Ved bruk av API’et kan dere sette korrekt kilde ved oppretting av sak, ellers så er det mulig å automatisk definere kilde ved bruk av en arbeidsflytregel som trigger basert på avsender eller innhold.

Hvilke kilder dere velger å ha i Pureservice er etter behov. Har dere kun inntak via selvbetjeningsportalen eller telefon, så er det ikke hensiktsmessig å legge til flere. Skulle det være behov på et senere tidspunkt er det fritt til å legge til så mange dere vil.

Sakstype

Sakstype brukes for å definere hvilken prosess eller praksis som brukes for denne saken.

Dette kan være for eksempel:

• Bestilling – Noe skal bestilles.
• Supporthenvendelse – Det er noen som trenger råd, hjelp eller støtte.
• Hendelse – Noe er feil og må fikses.

Hvis du er en ITIL entusiast og aktivt bruker terminologien i organisasjonen, så vil sakstype være relativt enkelt å definere basert på hvilke praksiser dere skal kjøre i Pureservice.

• Incident
• Service Request
• Problem
• Event (med passende kilde)

Alle disse vil være gode utgangspunkt for sakstyper så lenge behovet er der.

Ettersom Service Request dekker en del forskjellig, så kan dere erstatte denne sakstypen med flere typer som for eksempel følgende: “Bestilling”, “Supporthenvendelse” eller “Feedback” for å kunne rapportere grundigere.

Til syvende og sist så er det deres egne behov og prosesser som bestemmer hvilke sakstyper dere vil benytte dere av. Det er enkelt å implementere nye sakstyper på et senere tidspunkt og etter deres behov i Pureservice.

Sakstyper og fallgruver

Det er et par fallgruver som kan gå igjen for sakstyper:

1. Kun én sakstype eller for få sakstyper som ikke dekker behovet
I de tilfellene hvor behovet er å kunne ha mer granulær oversikt over sine prosesser, så er det naturlig å ha flere sakstyper. Sakstyper som «Bestilling» og «Hendelse» vil ikke dekke dersom dere eksempelvis ønsker å se se antall saker som omhandler brukerstøtte. Istedenfor å prøve å ta igjen dette ved bruk av en kategori og skyve problemet over til et annet klassifiseringssteg igjen, så vil vi heller opprette en egen sakstype for behovet.

2. For mange sakstyper som dekker et behov man egentlig ikke har
Det er ikke nødvendig med x antall sakstyper for alle mulige nivåer av hver enkelt prosess om det ikke eksisterer et reelt behov for oversikt eller for å lage rapporter. I beste tilfelle vil man ha et veldig granulært datagrunnlag som ikke brukes, og i verste tilfelle vil man gjøre manuell klassifisering et lite mareritt og datagrunnlaget vil ikke være til å stole på som et resultat av feilvalgt sakstype.

3. Ingen informasjon og trening i sakstyper for saksbehandlere
Det er fort gjort å sette opp et perfekt system for sakstyper, men all den tenkingen og tiden brukt kan kjapt være forgjeves dersom ingen vet når, hvordan og hvorfor de skal brukes. Det er derfor viktig å informere og trene deres saksbehandlere i hvilke sakstyper som skal brukes til ulike formål, samt sørge for å korrigere saker som blir klassifisert feil i dette steget.

Kategori

Kategori brukes for å definere hva saken rører ved eller hva saken er “på”. Kategoriene skal i teorien brukes på tvers av alle sakstyper og må derfor være generelle.

Det er lett å gå seg vill med kategorier, så vi begynner enkelt.

Hver sone har sitt eget kategoritre som har en dybde på 3 nivåer. Dere velger selv hvor mange av disse nivåene som skal brukes og til hvilket formål.

Dersom vi tar utgangspunkt i en IT organisasjon som driver drift, så vil vi kanskje starte med noen enkle kategorier som vi allerede vet det kommer henvendelser på:

Så lenge vi forventer å få inn saker omhandler dette, så er det et godt utgangspunkt. Det viktigste med kategoriene er at de er gjeldende, konkrete og kommer til å bli brukt.

Men ettersom vi har 3 nivåer kan vi for eksempel bruke toppnivå for kategorisering for å organisere områdene i kategoriene.

Nå ser det allerede litt ryddigere ut, og vi har et tredje nivå til overs hvis vi ønsker enda dypere granularitet i kategoriene sine. Skulle vi da ta i bruk tredjenivå kan dette for eksempel være slik:

Med dette så har vi 3 nivåer å gå på, samt at det er organisert og enkelt å finne frem. Vi kan alltids kategorisere på første og andrenivå selv om vi har etablert et tredje nivå også. Kategoriene er generelle og kan i teorien bli brukt av alle sakstypene en bestemmer seg for å ha.

Jobber deres område egentlig ikke med stort annet enn software eller infrastruktur, så vil det kanskje ikke være hensiktsmessig å bruke førstenivå for organisering, og dere kan da bevege kategoritreet ett nivå opp og spare tredjenivået hvis dere ønsker å ta i bruk dette senere.

Hvis dere jobber med levering av egne tjenester, så kan dere også sy sammen et kategoritre som gjenspeiler applikasjonene og tjenestene dere dekker. Dette kan da for eksempel se slik ut:

På denne måten er kategoritreet tjenestefokusert, men vil ikke gjenspeile infrastrukturen under. Dersom dere ønsker å kunne rapportere på begge deler, så kan dere benytte dere av et egendefinert felt.

Kategorier og fallgruver

I arbeidet med kategorier finnes det fallgruver som er lette å falle i. De største og mest vanlige er:

1. Kategoriene vedlikeholdes ikke
Organisasjoner vokser, krymper eller endres over tid. Systemer, tjenester, områder og behov fjernes, endres eller innføres. Det betyr også at kategoritreet må vannes og trimmes. Det er anbefalt at med kontinuerlig gjennomgang av behov, og at kategorier per sone vedlikeholdes. Et tips er å bruke sakslister for å finne ut om det er kategorier som ikke er i bruk eller som brukes feil. Deretter kan dere avgjøre om dere skal skru kategoriene av før de eventuelt fjernes helt.

2. Kategorier som overlapper hverandre
Kategorier som representerer noe forskjellig, men som har samme navn og ligger hverandre nært gjør det vanskelig for saksbehandlerne deres å velge riktige kategori i manuell klassifisering.

3. Saker kategoriseres ikke
Et stort symptom på fallgruvene over. Man vil muligens være fristet til å påtvinge kategorisering. Med mindre kategoritreet er godt designet og vedlikeholdt, så vil det ta oss med til neste fallgruve.

4. Saker som kategoriseres feil
Et symptom på dårlige kategorier og påtvingelse gjør det frustrerende for saksbehandlerne deres. Et resultat kan være at de velger noe de er usikker på eller vet at er feil for å «få det unna». Dette vil uheldigvis lede til forurensning av datagrunnlaget på sikt.

5. Kategoriene Annet, Diverse og Generelt
Samlekategorier er effektivt et sort hull i datagrunnlaget. Det betyr at vi ikke vet noe om sakene med disse kategoriene. Dette kombinert med andre fallgruver som dårlig vedlikehold av kategoritreet og påtvingelse av kategori ved opprettelse eller lukking kan føre til at dere mister synlighet på henvendelsene deres.

Dersom dere likevel ønsker å ha en samlekategori, så anbefales det at dere har en saksliste stående som følger med på alle saker som får den aktuelle kategorien og at dere utfører gjennomgang av de jevnlig. Beste praksis er å gå igjennom og vurdere behovet for nye kategorier og/eller intern opplæring av saksbehandlerne.

6. Kategorier forveksles med sakstyper
En gjenganger er kategorier som heter «Feil på datamaskin» eller «Bestilling av ny tilgang». Dette er eksempler på kategorier som egentlig er en sakstype (prosess/praksis) og en kategori. I beste fall gjør det kategori eller sakstype overflødig, og i verste fall invaliderer man en av klassifiseringspunktene.

For kategorien «Bestilling av tilgang» må vi bruke et egendefinert felt i tillegg til sakstype og kategori for å kunne finne ut hvilken tilgang som er bestilt i en rapport. Det er anbefalt i henhold til beste praksis å bruke sakstype dimensjonen for å definere prosessen til saken, og kategori for å definere hva prosessen til saken omhandler.

Kategorien «Feil på datamaskin» bør dermed heller oversettes til Sakstype: Hendelse/Incident/Feil og Kategori: Datamaskin. Som resultat er det med en gang lettere å bruke sakslister for å ha gode rapporter, definere mer spesifikke SLA’er og egendefinerte arbeidsflytregler.

Prioritet

Prioritet definerer hvilket omfang og deretter hvilken hastegrad saken bør få. Det er spesielt viktig med prioritet i hendelseshåndtering for å kunne representere omfanget av en hendelse slik at dere enkelt kan respondere og rapportere på alle grader av hendelser. Det kan også være at noen bestillinger eller supporthenvendelser skal behandles raskere enn andre, men alt avhenger av behov.

Prioritering har et sterkt forhold knyttet til SLA/tjenestemål der det kan være forskjellig telling basert på prioritet. Med prioritet vil dere slippe å ha en sakstype for hver grad av viktighet og klassifiseringen vil bli ryddig.

Har deres organisasjon en klar matrise og definering av hva som er viktig og hva som er ikke, vil denne delen av klassifiseringen bli enkel. Alt kommer an på deres egen organisasjon og hva som er viktig for dere.

Eksempel på en prioriteringsmatrise for hendelser:

Hvordan dette kan gjenspeiles i Pureservice:

Prioriteter og fallgruver

1. Prioriteter som ikke har et formål eller ikke skal brukes
Dersom alle deres saker blir behandlet med lik prioritet og hastegrad, så er det heller ikke mye poeng i å designe flere forskjellige prioriteter. Det vil introdusere en dimensjon til av klassifisering som er åpen for feiltolkning hvis det utføres manuelt.

2. Prioritet brukes ikke der det er behov
Om det foreligger et behov for å kunne behandle saker forskjellig på omfang og hastegrad, så er prioritet desidert det beste klassifiseringspunktet å ta i bruk. Prioritet og SLA går også hånd i hånd, noe som gjør det enkelt å skille ad løsningstider basert på hva som blir satt som prioritet på en sak.

Egendefinerte felter

Egendefinerte felter er en morsom del av klassifiseringen ettersom det er helt valgfritt å benytte seg av, men det lar dere legge til enda flere kriterier for rapportering og arbeidsflyt.

Om dere fortsatt trenger å rapportere på noe som ikke vil dekkes av resten av klassifiseringen, så har vi i Pureservice tre egendefinerte felter som kan legges til på saksbehandling. Dere får valg om tekst, nummer, dato.

Dere kan navngi disse feltene etter behov, som for eksempel:

• Referansenummer i annet saksystem
• Ordrenummer
• Nedetid startet
• CSAT

Egendefinerte felter og fallgruver

1. Egendefinerte felter som kompenserer for mangelfulle sakstyper eller kategorier
Med mangelfulle sakstyper kan det raskt lede til å et forsøk på å kompensere med en dårlig kategori, og man må da igjen kompensere med et egendefinert felt. Ettersom det er tilgjengelig med tre typer i form av enten tall, dato eller fritekst, så kan dette åpne opp for at man bruker opp alle feltene på klassifisering som egentlig skal dekkes av de andre punktene. Det er heller anbefalt å rydde opp i resten av klassifiseringen, og etter dette vurdere om dere har behov for egendefinerte felter på en sak.

2. Egendefinerte felter som enten ikke brukes eller ingen vet hvordan fungerer
Ettersom egendefinerte felter på sak er globale, så er de synlige for alle saksbehandlerne på alle saker. Bruker dere ikke et egendefinert felt er det bedre å skjule det. Dersom det er i bruk, men igjen vet hvordan de fungerer, så er det viktig å informere deres saksbehandlere om hvordan de fungerer og hva de skal brukes til.

Ønsker du å vite mer?

Med god og konsistent klassifisering får dere et sikkert datagrunnlag av kvalitet. Det betyr at når vi lager sakslister kan vi stole på informasjonen den viser. Kriterier for arbeidsflyt blir mer pålitelig, og håndteringen av saker vil gå ekstra smidig for alle involverte.

Det er andre ting som også kan brukes til å filtrere sakslister, som blant annet SLA, sone/avdeling, team, tidsregistrering, opprettet/lukket, innen/før og mer.

Ønsker du å se nærmere på hva Pureservice kan gjøre for å støtte deres behov? Ta kontakt med deres Customer Success Manager for en hyggelig klassifiseringsprat.

Marius Eldor Børseth.

Customer Success Manager.