Tre kärnprocesser

Det finns många processer inom förvaltningsramverk. När folk skapar processramverk börjar de med de viktigaste processerna. Sedan lägger de på fler och fler tills de ser att allt som krävs är på plats. Problemet uppstår för folk som sedan ska börja tillämpa ramverken. Hur ska de kunna identifiera kärnprocesserna? Kunna skilja det viktiga från det oviktiga?

Det finns tre processer som är särskilt centrala i tjänsteförvaltningen, eftersom de direkt styr över hur tjänsten ser ut:

1. Förändringshantering (Change Management) - hur vi ska förändra tjänsten.
2. Incidenthantering (Incident Management) - hur vi hanterar avbrott och störningar i tjänsten.
3. Problemhantering (Problem Management) - hur vi hanterar de bakomliggande orsakerna till avbrotten och störningarna.

Dessa tre hänger intimt samman. Det är förändringarna som vi genomfört som ger upphov till incidenterna, och de bakomliggande problemen behöver en förändring för att kunna lösas. Samtidigt är bandbredden i utvecklings- och förvaltningsorganisationen ofta stabil och ändrar sig inte så ofta, så vi måste hela tiden bestämma oss för om vi ska använda tiden till grundligt problemlösningsarbete eller till att täcka över bristerna med snabba fixar under tiden vi försöker fokusera på en större förändring som förhoppningsvis får incidenterna att sluta.

I organisationer där man försöker separera dessa tre processer får man problem. Separationen är ett sätt att dölja den starka kopplingen. Vill man istället behålla förvaltningen agil kan man centralisera besluten till en och samma gruppering som prioriterar det som behöver göras genom att bestömma över behovslistan och vara de som ytterst godkänner det sätt som den operativa personalen hanterar och värderar incidenter på.

[En liten observation från ITIL: Den förändringshanering (Change management) jag pratar om här är större än CM-processen i ITIL. Den innefattar hela förändringens livscykel från förslag till driftsättning. Tänk också på att ITIL på oklara grunder har förlagt Application Development till transitionsfasen istället för att se det som en del av tjänstedesignen. Om vi tänker på transitionen enbart som utrullning av implementerade förändringar och låter designfasen innefatta allt som har att göra med utvecklingen av dem, så blir det mer logiskt givet hur utveckling fungerar (utveckling är design) och mer kompatibelt med de agila arbetssättens prövande iterativa metoder.]