ITIL staat voor Information Technology Infrastructure Library. Het is de heilige graal voor IT dienstverleners. Er zijn IT-leveranciers die beweren volledig volgens ITIL te werken, maar dat druist juist tegen ITIL in. Het is een referentiekader, geen standaard. Het staat iedereen vrij er wat anders uit te pikken. Doe ermee wat bij jouw organisatie past.
ITIL is daarom hoogstens ‘een soort van Bijbel’. Bovendien eentje mét updates om met de tijd mee te gaan. In de laatste versie van ITIL is de serviceketen geïntroduceerd. De serviceketen heeft zijn Bijbelse equivalent in de leefregel ‘Wat gij niet wilt dat u geschiedt, doe dat ook een ander niet.’
De meeste mensen zullen ITIL overigens niet met de Bijbel verbinden. Mij viel dat ‘Bijbelse equivalent’ toevallig van de week in. Ik realiseerde me dat een puntje van kritiek dat ik had op één van mijn leveranciers eigenlijk net zozeer voor mij gold. Wat ik miste bij die leverancier dat misten ‘mijn eigen klanten’ misschien ook wel bij mij. Als ik iets van mijn leverancier verlang dan wil ik daar naar mijn eigen klanten ook in voorzien, dacht ik.
De serviceketen wijst organisaties erop dat ze een schakeltje zijn in een veel groter geheel. Iedere serviceverlener is zowel aanbieder als afnemer is. Hij is aanbieder in relatie tot zijn eigen klanten en hij is afnemer in relatie tot zijn eigen leveranciers.
Verantwoordelijkheid en afhankelijkheid werken beide kanten op. Serviceverleners moeten hun klanten managen, maar ook hun leveranciers. Zeker in de IT waarin de afhankelijkheden zich tot een web hebben verweven en steeds verder uit het oog zijn geraakt. Valt er ergens in de keten iets om dan kan dat jou raken. En dat lijken we tegenwoordig steeds vaker te zien.
De relatie met je leverancier is anders dan de relatie met je klanten. Daarom kun je in de ene relatie dingen constateren waar je in de andere relatie blind voor blijft. Dat is wat ik me van de week realiseerde.
De ondersteuning van mijn leverancier verloopt vrijwel uitsluitend via het customer portal. Dat is hét communicatiekanaal. Als ik een vraag of verzoek heb dan maak ik daar een ticket aan. Vaak volgt de oplossing in dat ticket. Gaat het echter om iets wat niet meteen kan worden opgelost, zoals een bug of een ontwikkelwens, dan plaatst de leverancier dat op een backlog. Het ticket wordt afgesloten met de tekst dat bug of wens op het backlog is geplaatst. Alleen dat backlog kan ik niet inzien. Ik heb geen idee wat erop staat. Al maak ik me er wel een voorstelling van als een zwart gat. Een eindeloze lijst die nooit gaat worden afgewerkt, maar alleen maar langer wordt.
Het is logisch dat tickets worden afgesloten, anders zouden ze eindeloos open blijven staan. Daarmee is het ook logisch dat het verzoek of de wens op een andere ‘werkvoorraad’ komt te staan. Alleen is die andere werkvoorraad niet transparant. Als klant weet je niet wat er op het backlog staat.
En dat was dus wat ik me van de week realiseerde: ik hou net zo’n ondoorzichtig backlog bij. Ik weet wat er op de roadmap staat, wat er op het eindeloze backlog staat. Maar mijn klanten weten dat niet.
In mijn geval is het backlog een ogenschijnlijk zootje. Ik weet wat er staat, maar het leent zich niet om gedeeld te worden. Ook weer logisch. Het heet niet voor niets een backlog. En toch is het superbelangrijk om transparantie te bieden. Het levert heel wat op. Daardoor hou je mensen betrokken en kweek je begrip voor de prioritering. Je voorkomt dat ze jou en je backlog zien als een zwart gat waarin alles verdwijnt, zoals ik het zie bij mijn leverancier. En zoals ik vrees dat anderen het bij mij zouden kunnen zien. Dus dat moet anders. Het backlog mag op het backlog. Niet onderaan de lijst, maar met hoge prioriteit.