Binnen het vakgebied IT-servicemanagement woedt een al jarenlange discussie wat het verschil is in diverse rollen. Neem de rol van Service Manager, of de diverse rollen zoals Incident Manager, Availability Manager, Capacity Manager, Change Manager et cetera. Een belangrijk reden om deze rollen in een organisatie te introduceren ligt in het feit dat er een behoefte is vanuit afdeling overschrijdend belang of over verschillende IT-services heen, afzonderlijk van andere rollen.
De rol van bijvoorbeeld Service Manager wordt op veel verschillende manieren gebruikt. Van een generieke term voor iedere manager bij een IT-serviceprovider tot een manager die verantwoordelijk is voor het beheer van de end-to-end levenscyclus van een of meer IT-services. De inhoud van deze rol is erg organisatieafhankelijk. Als het om een IT-serviceorganisatie gaat die diensten aan externe klanten verkoopt lijkt de rol van Service Manager veel op de rol van Product Manager. Dit werkt prima in situaties van grootschalige toepassingen of hosting-diensten.
In het ‘vergelijk’ tussen IT-servicemanagement en het populaire gebruik van Agile Scrum gebruik ik de rol van Product Owner binnen Agile Scrum als uitgangspunt. De Product Owner is degene met mandaat, degenen die de acceptatiecriteria definieert en verifieert of hieraan wordt voldaan, het is degene die enerzijds samenwerkt met het uitvoerende ontwikkelteam en anderzijds samenwerkt met de stakeholders in de organisatie. Kortom, de Product Owner zorgt voor het maximaliseren van de waarde van hetgeen geleverd dient te worden en vertegenwoordigt hiermee de stem van de klant (voice of the customer).
IT-service ontwikkeling
Binnen IT-servicemanagement gaat het primair om het ontwikkelen van een IT-service (los van het feit of het om een nieuwe IT-service of een gewijzigde IT-service gaat) die aansluit op de wensen en eisen van de organisatie. Dit is per definitie een groeipad. Het is een utopie te denken dat een IT-service ‘in een keer goed’ is. Het ontwerpen en ontwikkelen van een IT-service zal zich dan ook altijd in de loop van de tijd verder ontwikkelen. Aansluitend is het belangrijk dat er, nadat een IT-service is geoperationaliseerd, er voortdurende verbeterslagen worden uitgevoerd. Deze context heb ik beschreven in de blog: De opmaat naar Agile Service Management.
De rol van Service Owner
De Service Owner, in lijn met de Product Owner, speelt een belangrijke rol in de ontwikkeling van de servicestrategie en is verantwoordelijk voor de inhoud van de serviceportfolio. De Service Owner vertaalt de organisatievereisten en de producteisen aan bepaalde IT-componenten en draagt zorg voor de levering en exploitatie. Dit kan de Service Owner vanzelfsprekend niet allemaal zelfstandig. Hier komen een of meerdere ontwikkelteams, zoals binnen Agile Scrum gedefinieerd, om de hoek kijken. De Service Owner vertegenwoordigt diverse stakeholders binnen de organisatie, begrijpt de verschillende service-componenten en neemt volgens de standaard definitie deel aan de onderhandelingen of is belanghebbende in diverse onderliggende processen.
Wat betekent dit nou voor de praktische werking voor IT-servicemanagement en de parallelle processen.
De praktische werking
Het verzamelen van de servicelevel vereisten van de klant of het onderhandelen en onderhouden van de SLA’s met de klant is een secundaire rol van de Service Owner. Vervolgens is veelal de servicelevel manager de uitvoerende rol die hier invulling aan geeft. Vanuit de optiek van Agile Scrum ligt de primaire rol bij de Service Owner; de servicelevels dienen namelijk te evolueren en maken integraal onderdeel uit van de Backlog van de betreffende IT-service. Dit geldt ook voor het reviewen van de SLA’s. De Service Owner heeft hierin een primaire rol, los van wie een eventuele SLA-reviewmeeting heeft met de klant.
De verantwoordelijkheid
Vanuit Agile Scrum optiek is de Sprint Review het moment dat er een nieuw IT-service Increment wordt geleverd en het resultaat wordt geïnspecteerd. Directe vervolgacties worden op de Backlog van de IT-service opgenomen. Het kenmerk van een IT-service is dat het gebruik ervan in de loop van de tijd aangeeft of er wel of niet aan de vereisten wordt voldaan. Dit wordt veelal zichtbaar op basis van de diverse verstoringen die zich voordoen, met als gevolg een indicator van (potentiële) kwaliteitsvermindering aan een IT-service.
De vervolgactie(s), nadat er een grondige analyse heeft plaatsgevonden, zullen op de Backlog van de IT-service worden vermeld. In feite ontstaat er een Backlog met verbeterinitiatieven, naast de strategische initiatieven en mogelijk zelfs procesinitiatieven. Een gevolg kan zijn dat er ook drie basistypen Sprints ontstaan: een strategische sprint, een procesactiviteit sprint en een verbetersprint en vanzelfsprekend kunnen hier combinaties in worden gemaakt.
De verantwoordelijkheid van de Service Owner heeft waarschijnlijk ook betrekking op zorgen voor en onderhandelen over de onderliggende contracten en overeenkomsten op operationeel niveau. Zeker in de eerste periode van de ontwikkeling van een IT-service zal de Service Owner zich richten op werkzaamheden die normaliter worden uitgevoerd door (proces)managers die zich richten op beschikbaarheid, capaciteit, configuratie of wijziging.
Hoe verder een IT-service zich zal ontwikkelen en zich een mate van stabiliteit ontwikkeld zal de Service Owner meer en meer slechts gebruik maken van de cijfers die voortvloeien uit het gebruik van de IT-service en ze niet zelf genereren of het eigenlijke werk doen. Het enige wat door de Service Owner vaak dan nog wordt gedaan is in veel situaties beslissen over wijzigingen en de assets & configuraties, of is in ieder geval verantwoordelijk voor het maken of verkrijgen van de noodzakelijke beslissingen.
Dit betekent dat de Service Owner consensus dient te bereiken (als belangrijke stakeholder) met de vaak verschillende Product Owners.
Het vergelijk
De Service Owner heeft in veel opzichten een match met hetgeen de Product Owner doet, in termen van IT-vereisten die betrekking hebben op de exploitatie en het leveren van de IT-service, met een focus op technologische infrastructuur en de operationele procedures. De Service Owner acteert en functioneert tussen de service-unit, business units en product ontwikkeling, met een focus op het vertalen van de bedrijfsvereisten en de producteisen naar acties binnen de IT-serviceorganisatie.
Het is zeer aannemelijk dat de rol van Service Owner en die van Product Owner, zeker als het over bestaande IT-services gaat, is opgenomen in een en dezelfde persoon. Beide rollen fungeren als een ‘stem van de klant’ en kennen de ‘eisenkant’.
Het is aan de organisatie zelf om een keuze te maken hoe de rol van Service Owner wordt gepositioneerd. De Service Owner kan ofwel een fulltime rol/functie zijn, of mogelijk een ervaren systeembeheerder met de juiste kennis over het product of de IT-service, maar altijd wel iemand met uitstekende vaardigheden ten aanzien van de mensen en de business.
Ik ben benieuwd naar hoe jij de combinatie legt tussen de diverse rollen. Ik lees dan ook graag jouw reactie.
Ik zou zeggen beschouw (managed) services als product en vervang product owner door service owner. Andere mindset / agile mind 🙂 .
Volgens mij blijft het hele gebouw rond Agile en scrum en alle eisen die de werkmethode daaraan stelt dan intact. Is al lastig genoeg voor de meeste organisaties.
Op zich zou een service als product kunnen worden beschouwd. Echter is de context van een service in de praktijk vaak veel breder dan sec één product. De service (release) is vaak opgebouwd uit nieuwe en/of gewijzigde infrastructuur, software en/of documentatie e.d. De product owner is vaak alleen verantwoordelijk voor de ‘functionaliteit’ (het applicatiegedeelte) en niet voor de overkoepelende service-onderdelen w.o. het infrastructurele. Het zou mooi zijn als inderdaad de service owner ook de rol van product owner van de verschillende service-onderdelen vervult. Kortom, de praktijk is nogal weerbarstig.
Leuk om te lezen. Beter kun je stellen dat producten onderdeel zijn van een service. Kan 1-op-1 maar ook n-n en alle varianten betreffen. Er licht nog nuance in de gelaagdheid van diensten en verticale (technische) ketens versus horizontale (waarde) ketens. Blijf trouw aan een goed operating model met capabilities die uitgewerkt zijn in taken, rollen en verantwoordelijkheden en volg daarbij best practices. De one-size-fits all bestaat niet. Het is ook de volwassenheid van de organisatie en de werking van mandaat, sturing en verantwoording. Keep it simple is een stabiel advies. J