Wie levert nu de avocado?

Naast het vastleggen van afspraken over de gewenste dienstverlening is de beleving en/of de verwachting toch anders. De watermeloen en avocado zijn gebruikt om dit verschil uit te werken. Beiden een lekkere vrucht met een hele andere smaak en beleving.

Wat is een Service (Delivery) Manager?

De Service (Delivery) Manager (SDM) beheert klantvragen en zorgt voor de levering van producten en diensten. Afhankelijk van de positie van de SDM binnen de organisatie varieert het takenpakket. Aan de service- c.q. klantzijde zorgt de SDM voor het opbouwen van een stabiele klantrelatie en het verkrijgen van duidelijkheid over de vereisten voor de doorontwikkeling van de producten en diensten. Aan de delivery- c.q. leverancierszijde ligt het zwaartepunt vooral op het leveren volgens afspraak: functioneel, technisch en binnen de diverse afgesproken kaders van continuïteit en stabiliteit tot aan de verplichting voor informatiebeveiliging.

Vroeger werden verschillende taken uitgevoerd door verschillende functionarissen, zoals een business / relationship manager, service improvement manageren contract of delivery manager. In de ‘digitale’ periode zijn deze functionarissen qua naamgeving vervangen door Product Manager / Owner, Scrum Master, Agile Project Manager, Agile / Digital Service Manager. Het gebruik van deze nieuwe functienamen is vloeken in de kerk voor zowel de ITIL- als de Agile-puristen. Hierdoor zijn de niet-theoretisch gefundeerde functies als Operational of Technical Lead ontstaan. De functie geeft niet duidelijk aan wat hun verantwoordelijkheid en bijdrage is aan het behalen van het gewenste resultaat voor de klant.

Digital Service Manager

In de huidige digitale wereld vliegen termen als Agile, DevOps (of varianten als BusDevSecOps), Scrum en Digitale Transformatie in het rond. Daarbij ook de bijbehorende nieuwe methodieken, frameworks en tooling. Hierin lijkt waterval en ITIL steeds minder een plek te krijgen. Desondanks is er nu de functie ‘Digital Service Manager’.

Het lijkt een zoektocht van organisaties, die geprobeerd hebben over te stappen of al zijn overgegaan van waterval, c.q. traditioneel naar Agile, DevOps en SAFe maar niet volledig worden bediend. Hierdoor is de functie van Service Manager nieuw leven ingeblazen. Echter door de digitale wereld moest dit met de toevoeging ‘digital’. Voornamelijk om aan te geven, dat deze Service Manager bekend is met het gedachtengoed van Agile, Scrum en DevOps.

Waar gaat het de klant precies om?

Elke klant wil eigenlijk maar één ding: een dienstverlening die beschikbaar is wanneer die nodig is voor de ondersteuning van de primaire bedrijfsprocessen. Bij het ontwerpen en ontwikkelen van het product en de dienst begint al een afweging tussen de elementen uit de driehoek; de noodzakelijke functionaliteit, de benodigde resources (geld, tijd, mensen) en gewenste kwaliteit.

Ondanks het streven om deze aspecten in balans te houden en te borgen in een contractuele afspraak met de leverancier(s), mag de klant verwachten dat de dienstverlening beschikbaar is volgens de overeengekomen afspraken, het ‘service window’. In het verschil tussen contractuele afspraak en verwachting is waar het zaadje voor de watermeloen gepland wordt.

Wat betekent de 'service mindset' precies?

Het kennen van je klant en weten wanneer de dienstverlening cruciaal is voor hun bedrijfsproces, is de belangrijkste taak van een (Digitale) Service Manager. Zorgen dat de dienstverlening op de cruciale momenten sowieso beschikbaar is, ook als de effort buiten contractuele afspraak valt, heet ‘service mindset’.

“Een service mindset is een fundamentele werkhouding die ervoor zorgt dat de klant krijgt wat op dat moment nodig is, ook wanneer er werk uitgevoerd moet worden als de contractuele (werk)afspraak daarvoor afwezig is.”

Voldeed de dienstverlening volledig aan de contractuele afspraken (groene buitenkant van de watermeloen), maar is de klant ontevreden of over de kwaliteit of over de tijdigheid van de dienstverlening, dan is het gevoel niet positief (rode score en de kern van de watermeloen).

Uiteindelijk werken de betrokken partijen samen om een dienstverlening te bieden die voldoet aan de contractuele afspraken maar bovendien zorgt voor een tevreden klant. Als de klant tevreden is over de dienstverlening en dus de service mindset, levert dit de gewenste situatie namelijk een klant die geniet van het nuttigen van een avocado.

Welke methode, framework of model is het best?

De klant maakt het in de regel niet uit hoe de werkzaamheden worden uitgevoerd, maar vooral wat en wanneer er geleverd zal worden.

In het geval van een storing (oftewel een onderbreking van de afgesproken dienstverlening), zou de bijpassende werkhouding moeten zijn: ‘fix first, discuss agreements/contracts later’.

Snelle en duidelijke informatie helpt bij het adequaat herstellen van de service. Vasthouden aan de formele contractuele afspraken zorgt potentieel alleen maar voor vertraging. Samenwerken in het belang van de klant helpt de impact van onbeschikbaarheid te verminderen.

Maakt het uit hoe we onze functies noemen?

Nee, zeker niet. Het maakt niet uit welke functie/rol uiteindelijk de waarde voor de klant levert. Bij digitale transformatie moeten verschillende organisaties, teams en mensen samenwerken en verschillende werkwijzen, methoden en technieken combineren.

Voor een effectieve en efficiënte afstemming tussen klant en leverende partij(en) wil de klant wel graag één contactpersoon. Daarbij maakt het ook niet uit wat de functienaam is, maar het is vaak de Service (Delivery) Manager die hierbij instapt. Met andere woorden: een ervaren professional met een functienaam, waarbij de functienaam bij zowel de ITIL- als de Agile/Scrum-aanhangers voor niet al te veel opschudding zorgt. Je zou het zelfs een Service Integrator kunnen noemen

Deze uitdaging blijft: ‘de flexibele schil’

Dit is bij vrijwel alle bedrijven de actuele vraag, die een oplossing vereist. Veel organisaties werken namelijk op één of andere manier met kleine teams. Afhankelijk van het soort team is er wel of  geen capaciteit beschikbaar om onverwachte of ongeplande taken op te kunnen pakken.

“Een flexibele schil is niet alleen zorgen voor ruimte qua capaciteit om ongeplande taken toch tijdig af te kunnen maken. Het is ook zorgen voor het op het juiste niveau beleggen van mandaat en verantwoordelijkheid zodat teams beschikbaar zijn als ze nodig zijn en ook autonoom kunnen handelen.”

Agile/Scrumteams zijn gericht op (door)ontwikkeling en geven bij elke sprint ‘commitment’ af voor wat ze precies zullen gaan opleveren. Vanuit  traditioneel beheer (of beheerteams) blijft de  behoefte om capaciteit van Agile/Scrumteams te reserveren. Voornamelijk wanneer deze teams vanuit de operatie worden gevraagd om als 3^e-lijn support bij te springen bij het oplossen van een issue in productie. Dit resourcemanagementconcept gaat in tegen de principes van Agile/Scrum, waarbij flexibiliteit en het vermogen om als team aan te passen aan veranderende omstandigheden centraal staan (zie het Agile Manifesto op www.agilemanifesto.org).

Dev(Sec)Ops-teams hebben al verschillende disciplines in zich. Ze zijn dus niet alleen voor de (door)ontwikkeling, maar ook voor de dagelijkse operationele dienstverlening verantwoordelijk. Aangezien de levering uit zowel gepland als ongepland werk bestaat, zou er al een ‘flexibele schil’ c.q. capaciteit aanwezig moeten zijn.

Echter lopen die teams dan veelal tegen een volgend issue aan: de klant kent nog geen digitale goedkeuring/vrijgave voordat een release in productie mag worden genomen. Het volledig gebruiken en vertrouwen op geautomatiseerde processen bij de business c.q. de klant is een groot verschil in de werkwijze binnen de voorbrengings­keten. Het team behoudt nog steeds de gewenste flexibiliteit, hoewel een deel van de capaciteit is gereserveerd voor onbekende taken of taken die binnen een sprint moeten worden uitgevoerd. De benodigde flexibiliteit stelt dus ook eisen aan een aangepaste c.q. doorontwikkelde werkwijze van de klant.