Den här artikeln handlar inte om varför man ska jobba med ärendetyper som incident, problem, change request, etc. Den handlar om varför man bör separera ärenden i olika typer till att börja med. Stöd för de olika ärendetyperna implementeras i ett ärendehanteringssystem.
Ibland tycker jag att det kan vara svårt att hitta argumenten för varför något ska göras eller implementeras. De känns självklart men när jag ska börja argumentera varför så finns inte argumenten till hands alltid. Istället dyker de upp efter ett tag, när diskussionen är slut. Jag har fundera på att skriva något om varför man ska göra olika saker i en ITSM-verksamhet. I huvudsak för min egen referens skull för att ha när jag kommer till nya kunder. Det här kan vara början på det...
I mitt nuvarande uppdrag ansåg jag att verksamheten skulle dra fördel av att dela upp sina aktiviteter i olika ärendetyper. Jag tog fram ett underlag till ledningen för att stödja mitt case. Denna verksamhet är en HR-organisation, vilket i praktiken är en supportverksamhet som också administrerar HR-system. HR-processer är också mycket viktiga i en sån här verksamhet och är uppsatta som Configuration Items i CMDB och ändringshanteras i processen för Change Management. Innehållet i den här artikeln går även att applicera på IT-verksamheter.
Nedan kan du se hur jag argumenterade (med mindre förändringar från det faktiska materialet):
Behov/Effekt
Tydlig separation av olika typer av aktiviteter.
Motivation
- Svårt att skilja mellan olika typer av aktiviteter som change (RFC), incidenter, problem, service requests, etc. när de hanteras som en och samma typ i verksamheten och verktyget.
- Svårt att skriva och följa upp SLA om olika aktiviteter registreras som en och samma typ i ärendehanteringsverktyget.
- Svårt att veta vad man ska gör om man inte kan skilja på, exempelvis, incidenter och problem i ärendehanteringsverktyget (bara se till att användaren kommer vidare eller fixa root cause?).
Behov/Effekt
Möjlighet att prioritera olika aktiviteter korrekt
Motivation
- När olika typer av aktiviteter, som incidenter, problem, change request, service requests, hanteras som en och samma typ i ärendehanteringsverktyget kan det vara svårt att urskilja incidenterna som i sin natur har högst prioritet.
Behov/Effekt
Analysera hur system eller processer mår
Motivation
- Antal incidenter och problem som registreras på ett system eller process kan var en god grund för att ta reda på hur systemet eller processen mår. System eller process med flest incidenter och problem behöver kanske mer resurser för att stabiliseras. Detta kräver så klart att man väljer Configuration Item (Ex. applikation, server, nätverkskomponent, process, tjänst, etc.) i alla ärenden så man kan få ut korrekt statistik.
Behov/Effek
Analysera trender för olika typer av aktiviteter
Motivation
- Analyser av trender för olika ärendetyper kan användas som underlag när man planerar bemanning eller andra åtgärder för att bemöte trenderna.
- Om ett system har en uppåtgående trend av incidenter kan man vidta åtgärd innan allvarliga problem, eller total systemhaverier, uppstår.
- Analysera trender för att fokusera resurser till mest behövande ställe
Självklart kan man alltid analysera ärenden, om man inte separerar dessa i något verktyg, för att få reda på vad det är för aktivitet. Detta är dock mycket ineffektivt och det är inte lätt att implementera olika arbetsflöden för olika aktiviteter, vilket enligt mig är ett krav. Du kan inte följa upp SLA och skapa användbara rapporter om du inte separera olika typer av aktiviteter i ärendehanteringssystemet.