Når man arbejder i en Service Organisation med IT - som jeg gør som deltids IT Service Manager hos Netic, har man en vis interesse i at følge de standarder der sættes på dagsordenen.
Hos min arbejdsgiver Netic "bekender" vi os primært til ITIL med en meget pragmatisk tilgang - ud fra en devise om at vores ITIL implementeringer aldrig skal være for ITIL skyld, men fordi der er benefit (værdi) - først og fremmest for kunden (som vi jo leverer en service til) - derefter for Netic . Det er nok også mit personlige syn på ITIL, TOGAF etc etc - der skal være fornuft i sagerne og man må aldrig forvente at teknikken eller div. frameworks løser ret meget i sig selv, det er mennesker der skal forvalte og bruge dem i dagligdagen
To af faldgrupperne ved at implementere ITIL er:
Man skal kunne kravle før man kan gå - Det er fristende at springe ud i ITIL og stile direkte mod ITIL Heaven - men ITIL er et enormt framework, og netop KUN et framework (Eller som Barbossa fra Pirates siger: "And thirdly, the code is more what you'd call "guidelines" than actual rules"). Udvælg 1 eller 2 områder at starte med, tag dem der enten giver mest værdi, eller hvor lavthængende frugter kan høstes. Ved indførsel af et ITSM system som f.eks ServiceNow, OTRS eller HP ServiceDesk får man ofte en større pakke med mange funktioner.
Intern forcering - Man skal regne med 3-12 måneder for at køre en process rimeligt ind på rygraden af medarbejderne, både for 1) at omvende gamle vaner, 2) arbejde med de kræfter der uunværligt forsøger at trække den anden vej og 3) introducere nye procedurer én af gangen - så det hjælper ikke at fortælle at nu skal vi køre Change Management, Incident Management, Problem Management og Service Request i løbet af kort tid)
Som IT Service Manager plejer jeg en del "hellige køer" som jeg ser som en del af essensen i at lave god drift, nemmerlige:
5S princippet
De 5 S'er plejer jeg lidt sporadisk og formanende, specielt når nogle ikke standardiserer eller praktiserer almen praksis.
Se mere på 5S Kirken
Log og dokumenter
Flest mulige sager (med fornuft) skal logges i det relevante sagsstyringsystem, erfaringer viser (desværre) at går der politik i tingene kan der efterfølgende komme et "blame game" og så er det vigtigt at have udmeldinger og tidslinier på plads.
Se en liste over systemer på IT Service Management systemer
Cookbook
Et kogebogsprincip for Changes og for at lave SOP'er (Standard Operational Procedures)
Se mere på Kogebogsprincippet for Changes og SOPs
En par eksempler på Cookbooks kan ses på JIRA Install Cookbook og Confluence Install Cookbook
Brug af SOPs
For at facilitere ting hurtigere, bedre og uden at belaste organisationen (og CM'en) mere end højst nødvendigt, kan man med fornuft indføre SOPs (Standard Operational Procedures) - og en SOP skal naturligvis tilpasses den Change procedure som man har implementeret.
Et muligt udkast til et SOP kunne være som i Template for en SOP
For hver SOP kan man evt. specificere, og den kan gennemføres uden om CM eller om der skal godkendelse til. I ITIL frameworkes angives at Operations funktionen kan gennemføre disse (hvilket jeg tolker som "Uden CM")
Den gode mod den dårlige beskrivelse
Det kunne vi kalde dokumentation med fornuft eller dokumentation med scope.
The Good vs bad Description (Der er ikke en dansk version endnu)