De IT Smart Factory gebruikt concepten uit de fabriekswereld om IT-projecten op te zetten als een fabriek. Hoe gaat die fabriek om met issues? Of komen die niet meer voor in de perfecte IT-fabriekswereld?
Vaak wordt de IT-fabriek verward met simpele werkzaamheden aan een lopende band. Geen problemen, volle vaart vooruit. En als er iets van die band afvalt los je dat even op met veger en blik.
Niet dus.
In de IT-fabriek werken we met complexe items. Deze complexiteit verlagen we door het gebruik van de Pareto analyse, door het inzetten van draaiboeken met standaard stappenplannen, en door tijdig een change af te breken (door op de rode knop te drukken indien men te veel tijd kwijt is met problemsolving (de geplande takt-tijd overschrijdt).
In de praktijk ben je meer dan 50% van je tijd bezig met achter problemen aanrennen, met issues oplossen. Denken als een fabriek betekent: anticiperen op die issues, voorkomen dat je de rode knop nodig hebt. Je laat je er niet door verrassen, want je wilt je optimale fabrieksflow niet door issues laten vertragen.
Hoe anticipeer je op issues? Ofwel: hoe “plan” je je issues?
1) Inplannen van een change (een slot) ondanks issues.
In een IT-fabriek gaan we niet eerst alle issues oplossen alvorens een change in te plannen. Via een technische assessment weet je al welke issues er zijn (op je server, op je applicatie) en schat je in hoeveel tijd het gaat kosten deze op te lossen. Deze tijd tel je op bij de reguliere fabriekstijd. En dat geeft je de eerst mogelijke slot datum (go-live datum) die je met je functioneel eigenaar kunt inplannen. Deze plan je eerst tentative in (pre-firm), en X weken voor de geplande change weet je meer over het aantal opgeloste issues en kun je samen de slot datum vastleggen (firm maken).
2) Zet een separaat “brandblus-team” op issues.
Laat het fabrieksteam aan de standaard sequence werken, terwijl een ander team werkt aan de issues. Claim de tijd van het issue-team op basis van een verwacht aantal issues. Komen er issues, dan staat dat team klaar om “de branden te blussen”. Komen er geen issues, dan geef je de geplande tijd vrij voor andere werkzaamheden.
Maak het issue team ook verantwoordelijk voor de “fabrieks-firm-periode”. Hoe meer issues zij oplossen, hoe meer slots je van pre-firm naar firm kunt plannen, en hoe zekerder je planning is. Dat moet hun uitdaging zijn.
3) Zorg voor voldoende “wisselgeld” in je changes.
Wanneer er echt onoverkomelijke problemen zijn en de issue-oplostijd langer duurt dan gepland, zorg dan dat je changes kunt wisselen. Hierdoor blijf je je throughtput (x aantal changes per week) vasthouden.
4) Bespreek dagelijks je issues in de control room.
In een fabriek start men elke ochtend met een control room meeting. Iedereen alle koppen bij elkaar steken en de issues oppakken. Hetzelfde doen we in de IT-fabriek.
Hoe werkt een control room in de IT-fabriek?
Eerst kijken we naar de changes die op de planning staan voor de komende drie weken. Welke zaken moeten daarvoor nog worden opgelost? Wie gaat dat doen? Daarna inventariseren we de issues die vanuit de intake gesprekken naar voren zijn gekomen. Wat denkt een functionele beheerder ervan? Moeten we langs bij de leverancier?
Tot slot bekijken we de resultaten van de technische assessments. Elk systeem dat een change ondergaat wordt volgens een checklist gecontroleerd op technische complicaties. Hangt het systeem netjes in de back-up? Is het systeem virtueel bereikbaar zonder dat je fysiek naar een datacenter toe moet? Kunnen we inloggen? Alle checkpunten zonder vinkje worden op de issuelijst geplaatst en worden toegewezen aan leden van het issue-team.
Samenvattend:
Een fabriek zonder issues is utopie, dat moet je niet willen nastreven. Wat je in je fabriek wel moet nastreven is de planbaarheid van issues. Plan dus aparte issue-teams in, bespreek in de control room dagelijks zowel de reguliere fabrieksplanning als de issueplanning, en geef management inzicht in aantallen en status van issues.
Marianne Faro, Cas Schalkx, Itility Smart factory consultants.
