CSI als strategisch hulpmiddel

Behendig werken aan continue serviceverbetering

Het leveren van IT-services is voorwaar geen sinecure. De hedendaagse complexiteit van informatiesystemen, de gevraagde flexibiliteit (agility), de mate van beweeglijkheid (mobility), de verwachte duurzaamheid (sustainability) en allerlei risico’s, beperkingen (constraints) en onzekerheden (uncertainties) waarmee organisaties te kampen hebben, maken het lastig voor de IT om dit te volgen. Ook bestaat er nog steeds een afstemmingsproblematiek tussen de business (de demandorganisatie) en de IT (de supplyorganisatie).

In de publicatie van CIONet “Key European IT Management Trends for 2016” blijkt het grootste zorgpunt voor de meeste IT-managers nog steeds te liggen bij “Alignment of IT and Business”; en dat al sinds 2000! Dit is en blijft dan ook een hardnekkig doel voor veel organisaties, ook in 2018.

IT zorgt als integrale enabler en vliegwiel voor efficiëntie en effectiviteit in willekeurig welke organisatie. In het bijzonder de noodzaak om IT als een hefboomwerking te laten dienen voor het genereren van specifieke organisatie-initiatieven. In veel organisaties geldt dat zowel de IT- alsook de bedrijfsprocessen relatief volwassen zijn, maar wel op zichzelf. De sleutel ligt in de juiste afstemming (alignment) waarmee organisaties vooruitkomen. Het gaat zelfs een stap verder. Noodzaak is een resultaatgerichte definitie van IT-services, wat een organisatie voorbij het aspect “Business-IT Alignment” brengt richting “Business-IT Integration”.

Wat is er nodig om te komen tot afstemming en/of integratie met de klant/business?

In ieder geval is het belangrijk dat de juiste dialoog en discussie wordt gevoerd over de betekenis van de verwachte IT-serviceverlening. Ook is het definiëren van de klantresultaten (outcomes), in plaats van alleen het definiëren van IT-service resultaten (output), belangrijk. Alleen het verzamelen van de IT-servicevereisten is in ieder geval niet voldoende. Deze eisen zijn wel nodig maar duidelijk dient te zijn welke klantresultaten hiermee bereikt dienen te worden. Eisen worden dan ook gegenereerd voor de coördinatie en de mate van controle, pas nadat de klantresultaten goed worden begrepen (relationship management).

Een ander belangrijk aspect is klanttevredenheid. Deze tevredenheid betreft het niveau van dienstverlening hoe de IT-service wordt geleverd, inclusief de wijze waarop het groeipad van de IT-service in gezamenlijkheid is uitgezet en door de IT-serviceverlener wordt gerealiseerd. Dit vraagt vertrouwen in het vermogen (capability) van de IT-serviceverlener dat geleverd wordt wat is afgesproken en dat dit in tijd gezien wordt aangevuld en verbeterd. De moeilijkheid is dat de verwachtingen van de klant aanhoudend verschuiven (expectation management), en een IT-serviceverlener die dit niet kan volgen zal al snel de grip verliezen.

Op basis van het bovenstaande kan worden geconcludeerd dat er een aantal specifieke aandachtsgebieden zijn om hieraan invulling te geven:

  • Definiëren van klantresultaten
  • Verzamelen van IT-servicevereisten
  • Managen van klanttevredenheid (inclusief perceptie en voorkeuren)
  • Uitzetten van een IT-service groeipad, parallel aan de bedrijfsontwikkeling(en)
  • Realiseren van IT-services
  • Continu verbeteren van IT-services

Er wordt een IT-strategie ontwikkeld en uitgezet op basis van geplande bedrijfsontwikkelingen. Deze IT-strategie is gedefinieerd in doelen en doelstellingen en op basis van de kritieke succesfactoren en (belangrijke) prestatie indicatoren wordt gemeten of de activiteiten die worden uitgevoerd tot de juiste resultaten leiden.

Het meten van de IT-service prestatie is cruciaal.

Maar vandaag de dag wordt verwacht dat er Agile wordt gewerkt, oftewel een vorm van adaptiviteit; het vermogen om flexibel op veranderingen in te kunnen spelen. Agility betreft een lerende organisatie als een werkomgeving waar mensen continu hun mogelijkheden ontwikkelen om de complexiteit te begrijpen, een gedeeld begrip ontwikkelen en waar het systeemdenken wordt aangemoedigd. Dit betreft zowel het snel en behendig ontwikkelen van IT-services alsook het snel en behendig en op feiten gebaseerd leren (continue verbetering).

Het is in ieder geval een misvatting om te denken dat bij Agile-werken er geen sprake is van kaders en richtlijnen, in de zin van bijvoorbeeld architectuur, governance en compliancy. Deze kaders zijn en blijven belangrijke factoren binnen een organisatie. Het is tevens een misvatting om te denken dat Agile-werken zich alleen richt op ontwikkelingswerkzaamheden. Agile-werken heeft namelijk te maken met de wijze waarop de werkzaamheden worden uitgevoerd, in de zin van het snel en behendig bewegen en heeft betrekking op onderhoudswerkzaamheden (in stand houden), continue verbeteringswerkzaamheden (dagelijkse verbeteringen) en innovatieve werkzaamheden (drastische verbeteringen). Het gaat om de aandacht op de principes en condities waaronder wordt gewerkt.

Een gedegen wijze van meting van de IT-service als fundament!

Het afdoende meten van de IT-service weerspiegelt de prestaties en resultaten ervan, vanaf het punt van herkomst (de klantbehoefte) tot en met het punt van gebruik. De metingen dienen gericht te zijn op de klantresultaten (outcomes) of in ieder geval op de resultaten van het leveren van de IT-service en niet op de prestaties van individuele servicecomponenten.

Het leveren van IT-services dient de Agile-waarden te weerspiegelen. De parallelle processen zijn met ‘net genoeg’ controle en structuur ontworpen om de IT-services effectief en efficiënt te leveren ter ondersteuning van de bedrijfsresultaten, op het moment en op een wijze waarop ze nodig zijn.

  • Agile wordt gebruikt voor het verhogen van de snelheid van levering.
  • Lean IT wordt gebruikt voor het minimaliseren van verspilling.

Lean IT helpt om organisaties het grote plaatje te laten zien (system thinking). Het is gericht op het maximaliseren van waarde voor de klant door het minimaliseren van verspilling (waste), dat wil zeggen: werk dat geen waarde toevoegt. De belangrijkste focus is het bereiken van operational excellence door verbeterde wendbaarheid, kwaliteit van dienstverlening en efficiëntie van processen. Hiermee wordt een onafgebroken stroom van IT-services verzekert.

Lean IT gaat verder dan Agile: klik hier

Continue verbetering is de vijfde stap om tot een Lean- organisatie te komen. Het voortdurend verbeteren dient te leiden tot de ‘perfecte’ waarde wordt gecreëerd, zonder verspilling. Perfectie is misschien niet volledig haalbaar, maar steeds dichterbij komen is dat wel!

Het loslaten van ITIL-kaders en het adopteren van Agile-kaders!

Met het huidige ‘geweld’ van Agile development lijkt het er in veel organisaties op dat de aandacht alleen gericht is op de ontwikkeling van nieuwe bedrijfsoplossingen (nieuwe features), veelal in de vorm van ondersteunende informatievoorziening. Natuurlijk moet snel en adequaat ingespeeld worden op veranderende bedrijfsbehoeften, maar dat wil nog niet zeggen dat er geen aandacht meer nodig is voor de wijze waarop bijvoorbeeld het operationele beheer en de dagelijkse ondersteuning plaatsvindt. 

Binnen organisaties is als gevolg van het voorgaande een strijd gaande tussen het loslaten van de ITIL-kaders en het adopteren van de Agile-kaders.

Zijn de processen zoals binnen ITIL gedefinieerd overbodig? Mijns inziens niet. Er dient nog steeds nagedacht te worden welke minimaal noodzakelijke processen uitgevoerd dienen te worden en vervolgens dient gezorgd te worden voor duurzame verbetering (continual improvement). De processen dienen een zo min mogelijke overhead te hebben, oftewel een minimaal levensvatbaar proces respectievelijk een minimaal werkbaar proces dat ‘net voldoende’ gedefinieerd is met ‘net genoeg’ controle en structuur (minimum viable process).

Bij het iteratief en incrementeel ontwikkelen (de kern van Agile development) blijft het nog steeds van belang om aandacht te geven aan allerlei factoren die team-overstijgend zijn, al dan niet als gevolg van compliance- of governance-regels en -structuren, en allerlei geldende security-regels.

Op welke wijze een willekeurig ontwikkelteam (of een aantal teams) gevolg geeft aan bepaalde regels, naast de uitvoerende ontwikkelwerkzaamheden zelf, vraagt de nodige aandacht.

Ter illustratie positioneert ITIL ‘de controle op de ontwikkelwerkzaamheden’ binnen de levenscyclusfase service design. Dit werkt over de hele service-lifecycle heen, inclusief diverse feedback-loops en lessons learned for improvement. Service design gaat over ‘de controle’ op software engineering (development) en niet over de uitvoerende ontwikkelwerkzaamheden zelf. Service design ondersteunt bijvoorbeeld de samenwerking om te komen tot de ‘bouwen of kopen’ beslissingen. Als de beslissing is de oplossing te bouwen, werken de verschillende service-activa (middelen en/of artifacten), met inbegrip van de mensen, samen als leden van het ‘service design’-team. Het doel is de inspanningen te coördineren en een service design package (SDP) of een plan met de servicevereisten. De vorm en omvang is aan het development-team zelf, zolang alle aspecten van de IT-service en de vereisten ervan maar duidelijk zijn (minimum viable design).

Een SDP definieert alle relevante aspecten van een IT-service. Het omvat onder andere applicatie-gerelateerde uitkomsten (outcomes) en natuurlijk de bedrijfsrelevantie, evenals alle onderliggende activiteiten en capaciteiten die nodig zijn voor beheer en ondersteuning.

Een SDP is een groeipad-beschrijving (op hoofdlijnen), mogelijk in de vorm van epics (grote user-stories, vaak in de vorm van een complete workflow) en/of user-stories (een korte beschrijving wat de klant en/of gebruiker wil) of themes (samengestelde user-stories). Het verzamelen, definiëren en prioriteren van servicelevel vereisten (service level requirements) wordt onderdeel van het opstellen van een (user) story. Het geldt ook voor de servicelevel doelen (service level targets), de verplichting waaraan de IT-service moet voldoen om te zorgen dat de service ondersteunend is aan de bedrijfsdoelstellingen. Een SDP geeft de basis voor het iteratief en incrementeel ontwikkelen.

De noodzaak voor het opstellen van een servicelevel overeenkomst (service level agreement) komt deels te vervallen. De nieuwe wijze van werken ‘garandeert’ op zich al dat wat wordt geleverd (het increment) aan de vereisten voldoet. Dit is, als onderdeel van de Agile-werkwijze, gedefinieerd met de Definition of Done. Het opstellen van SLA’s blijft evenwel voor veel organisaties nog steeds belangrijk. Het vastleggen van afspraken tussen de IT-serviceprovider en de Business en het definiëren wat de verantwoordelijkheid is van de IT-serviceprovider, is en blijft houvast geven in de reguliere (en vaak complexe) interne en externe communicatie.

Het ITIL-kader, ondanks dat dit sinds de 2011-release zeer omvangrijk is, geeft nog steeds de nodige handvatten, kaders, checklist en wat dies meer zij, waarmee een organisatie haar wijzigingen in de bedrijfsprocessen kan afstemmen op de rol van IT en waarmee de nieuwe IT-services afgestemd kunnen worden op de bedrijfsvereisten.

Download het ITIL-kader als totaaloverzicht (PDF-formaat): ITIL Detailed Overview

ITIL detailed overview as checklist

The ITIL framework, despite the fact that it is very extensive since the last version, still provides the necessary tools, frameworks, checklist and so on, with which an organization can adapt its changes in the business processes to the role of IT and with which the new IT services can be tailored to the business requirements.

Download the PDF overview here: MCS – ITIL v3 2011 v1.0.2

De integratie van Agile Scrum en IT-servicemanagement (ITIL)

De ontwikkeling van hét ‘model’; ‘het ei van Columbus!?’

Om direct maar aan te geven, ITIL en Agile Scrum kunnen uitstekend naast elkaar bestaan, sterker nog ze zijn absoluut niet met elkaar in tegenspraak en er is geen sprake van onverenigbaarheid. En in combinatie met Lean IT is het plaatje echt compleet; de organisatiecultuur en de mens binnen de IT-omgeving zijn hierbij twee belangrijke factoren.

Domeindoelen

Scrum is een specifieke manier om resultaten te leveren. Het is een iteratieve, adaptieve en incrementele aanpak en een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Het is voor elke vorm van levering geschikt, ook buiten de IT, en is uitgegroeid tot veruit de meeste populaire Agile-aanpak.

ITIL gaat over de best practice IT-servicemanagement. Het is een holistische verzameling ideeën en processen over hoe IT-services te definiëren, ontwerpen, in productie nemen en operationeel runnen, en met name het continu verbeteren van de IT-serviceverlening als geheel. Dit is bekend als de servicelevenscyclus.

Het operationele oogpunt is binnen ITIL belangrijk, in aanmerking nemend dat de klantwaarde wordt geleverd tijdens de fase serviceproductie (service operation). De operationele eisen dienen vroegtijdig weerspiegeld te worden in de fase serviceontwerp (service design) en worden tijdens de fase servicetransitie (service transition) geconcretiseerd.

Een projectmatige aanpak is onontbeerlijk. ITIL en Scrum zijn dan ook eerder complementair dan tegenstrijdig. De uitdaging is hoe de twee met elkaar omgaan. Een belangrijk ondersteunende aanpak betreft Lean IT als het gaat om continue verbetering en respect voor mensen. Zie de blog: Lean IT gaat verder dan Agile.

De aansluiting

ITIL en Scrum passen uitstekend samen, zelfs op een hoog niveau. Vanuit ITIL-perspectief start Scrum met serviceontwerp en eindigt met het leveren van een IT-service. Eigenlijk begint het steeds weer opnieuw, zeker ook omdat een IT-services zich steeds verder ontwikkeld aan de wensen en eisen van de klant/gebruiker. Dit is waar Lean IT een belangrijke rol speelt; een continue verbetercyclus en een integrale ketenbenadering (met als doel ketenintegratie) en in lijn daarmee een alomvattende aanpak over alle lagen van de organisatie heen (systeemdenken). Zie de blog: Er is altijd wel iets te verbeteren.

Tijdens de ITIL-fase serviceontwerp wordt op basis van een goedgekeurde business case (vanuit ITIL-servicestrategie) de eisen verzameld in de vorm van user stories en geprioriteerd. Het resultaat is de geprioriteerde Product Backlog.

Tijdens de ITIL-fase servicetransitie worden de Product Backlog items (user stories) afgehandeld door timeboxed Sprints van één maand of minder. Iedere Sprint begint met een Sprint Planning waarin de user stories zijn opgenomen voor de volgende Sprint (de Sprint Backlog is een subset van de Product Backlog). De Dagelijkse Scrum (een timeboxed bijeenkomst van maximaal 15 minuten) helpt om de voortgang te volgen en om blokkades (impediments) op te verhelpen en op te heffen. De Sprint eindigt met een Sprint Review (een timeboxed bijeenkomst van maximaal vier uur) waarin de nieuwe/veranderende IT-service formeel wordt aanvaard, gevolgd door een Sprint Retrospective (een timeboxed bijeenkomst van maximaal drie uur) die resulteert in de geleerde lessen voor de volgende Sprint.

De grote uitdagingen

Een van de problemen met het pure gebruik van Scrum is dat er geen directe zorg is voor serviceproductie en de focus sterk gericht is op de utility (het nut); de geschiktheid voor het doel (de functionaliteit die de IT-service biedt om aan een bepaalde behoefte te voldoen). IT-serviceoplossingen worden maar al te vaak ‘over de muur gegooid’ en vooral garantie-aspecten (warranty) van een IT-service (capaciteit, beschikbaarheid, veiligheid en continuïteit) worden buiten beschouwing gelaten en aan het einde van de keten wordt de IT-service nog steeds geleverd zonder de noodzakelijke toegevoegde waarde.

Een van de grote bijdragen van ITIL is dat de operationele aspecten al zijn opgenomen in een vroegtijdig stadium tijdens de fase serviceontwerp, althans zo zou het moeten zijn! Toegepast op Scrum betekent het in ieder geval dat tijdens het opstellen van de user stories en de Product Backlog ook de operationele eisen worden verzameld. Tijdens de Sprint houdt het Scrum Team vervolgens rekening met alle operationele aspecten (bijvoorbeeld infrastructurele, monitoring, incidentafhandeling et cetera). Lean IT ondersteund vervolgens met een aanpak omde klantwaarde te maximaliseren door het minimaliseren van verspilling in de processen en activiteiten.

Change Management & Release Planning

Vanuit operationeel oogpunt fungeert wijzigingenbeheer als de beschermer van de productieomgeving door het (laten) identificeren van risico’s van iedere wijziging en het voorkomen van negatieve gevolgen. Algemeen gesteld valt iedere wijziging op een configuratie-item onder wijzigingenbeheer (bijvoorbeeld de Product Backlog die tijdens de fase serviceontwerp wordt gemaakt). De lastige vraag is in welke mate? Aan de ene kant zal het meer stabiliteit geven en aan de andere kant wordt meer administratie gecreëerd en wordt ingeboet op flexibiliteit.

Het is dus een wisselwerking. Wijzigingenbeheer is ook een belangrijk onderwerp binnen Scrum. Iedere Sprint eindigt bijvoorbeeld met de Sprint Review waarin de Product Owner de Sprint beoordeeld en goedkeurt. Tijdens serviceontwerp fungeert de Product Owner dan ook als poortwachter voor iedere user story (wijzigingenbeheer boven vereisten). Er zijn veel voorbeelden van wijzigingenbeheer, een aantal RFC-plaatsen zijn weergegeven in onderstaande schema.

agile-scrum-versus-itil

Om het juiste evenwicht tussen flexibiliteit en stabiliteit te bereiken is het belangrijk om te beslissen wat wel of niet onder wijzigingenbeheer valt en daarenboven dienen de juiste vertegenwoordigingsmodellen toegepast te worden (in verband met governance-regels).

Een aantal voorbeelden:

  • Wijzigingenbeheer over de Product Backlog is gedelegeerd aan de Product Owner. Ondanks dat dienen serviceproductieteams ook betrokken te worden om de operationele garantievereisten (warranty) zeker te stellen in de vorm van user stories.
  • Wijzigingenbeheer over de Sprint resultaten is gedelegeerd aan de Product Owner en in het geval dat de Sprint wordt opgenomen in een toekomstige release fungeert de reguliere operationele CAB ook als goedkeuring.
  • Wijzigingenbeheer over de Sprint Backlog is gedelegeerd aan het Scrum Team; de Product Owner, de Scrum Master en het reguliere Ontwikkelteam.

Geautomatiseerd testen

Gebruik maken van Agile Scrum betekent (meer) frequente releases. Testen is evenwel vaak een echt pijnpunt. Dit betreft veel minder het testen van nieuwe functionaliteiten (hier ligt vaak al voldoende aandacht tijdens de Sprint) maar eerder de regressietesten (controleren of bestaande functionaliteit nog steeds werkt).

Het automatiseren van regressietesten is de sleutel. Teams die werken volgens het zogenoemde ‘test fabriek-’model dienen vroegtijdig betrokken te worden en op basis van de Product Backlog dienen testgevallen te worden ontwikkeld en te worden geautomatiseerd. Veelal zijn dergelijke teams gepositioneerd als een chapter (volgens het Spotify-model); samengebrachte vaardigheden die binnen eenzelfde algemeen competentiegebied werken en worden ingezet over Scrum Teams heen.

De rollen

Scrum kent slechts drie belangrijke rollen: De Product Owner (de ‘stem van de klant’), de Scrum Master (de facilitator) en het Ontwikkelteam (de professionals). ITIL kent vele rollen, in de context van Scrum zijn de rollen Service Owner, Change Manager, CAB en CSI Manager de meest relevante.

De rol van Service Owner versus de Product Owner heb ik in een eerdere blog uitgebreid besproken. Samengevat is het logisch, zeker als het gaat om bestaande IT-services, dat de rollen Service Owner (ITIL) en Product Owner (Scrum) in een en dezelfde persoon is opgenomen. Beide rollen fungeren als ‘stem van de klant’ en kennen de eisen-kant. Zie de blog: Service Owner versus Product Owner.

Kijkend naar wijzigingenbeheer zal de Scrum Master en de Product Owner onderdeel dienen te zijn van de CAB wanneer het gaat om de release van een Sprint. De Product Owner, vanuit het oogpunt van de Sprint Backlog, treedt op als CAB-goedkeurder.

Binnen Scrum is het continu leren een integraal concept. In een Sprint Retrospective worden procesverbeteringen geïdentificeerd en in de Dagelijkse Scrum worden belemmeringen op succes opgeheven. Dit is een verantwoordelijkheid van de Scrum Master. Structurele verbetering van het Scrum-proces dient te worden beschouwd vanuit organisatorisch ontwikkelperspectief en dient onderdeel te zijn van het CSI-register. De Scrum Masters en de CSI Manager dienen op een regelmatige basis contact te onderhouden. Zie de blog: De opmaat voor Agile Service Management.

Als iemand eenmaal heeft laten zien hoe het gedaan moet worden, weet iedereen hoe het moet.

Conclusie

Het gaat om een viertal specifieke onderwerpen om tot integratie te komen van de servicemanagementprocessen (ITIL) met de Agile-aanpak (Scrum), zeker als het om bestaande IT-services gaat, en met de Lean IT-aanpak als het gaat om continue verbetering en respect voor mensen.

Scrum is niet alleen voor ontwikkeling van nieuwe producten in een geïsoleerde wereld. Het is uitgegroeid tot een belangrijke stroming voor twee belangrijke ITIL-aanpakken: serviceontwerp en servicetransitie, zeker als het gaat om bestaande IT-services. Historisch gezien praten deze werelden niet of onvoldoende met elkaar, in ieder geval wordt niet op dezelfde golflengte gepraat. Aan de ene kant de ontwikkelaars en aan de andere kant de operationeel IT-professionals. Dit is de reden voor een geïntegreerde en praktische aanpak over hoe ze bij elkaar te brengen om een wederzijds begrip te creëren hoe beide werelden werken.

Het betreft een totaalvisie op de gehele keten, van het starten van het ontwikkelproces tot en met het in productie gaan van softwarecomponenten en het operationele beheer ervan.

Kortom, we hebben het over DevOps; een aanpak waarbij de communicatie, samenwerking en integratie tussen ontwikkelaars en de operationeel IT-professionals wordt benadrukt maar zich hiertoe zeker niet beperkt.

Download het artikel: Inbedden van DevOps in de organisatie

De Product Owner versus de Service Owner

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.

service-team-samenstelling

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.

De ‘management zin’ van continue verbetering!

Continue verbetering is een veranderingsvorm, gericht op het vergroten van de effectiviteit en/of de efficiëntie van de organisatie ter ondersteuning van het beleid en de (strategische) doelstellingen. Het is daarmee niet beperkt tot alleen kwaliteitsinitiatieven. Verbetering van de bedrijfsstrategie, bedrijfsresultaten en de relaties tussen klanten, werknemers en leveranciers zijn het onderwerp van continue verbeteringsactiviteiten. Simpel gezegd: ‘steeds beter worden’.

Wat kan er beter?

Continue verbetering dient zich te richten op zogenoemde enablers zoals leiderschap, communicatie, middelen, (organisatie)architectuur, mensen en processen – met andere woorden, alles in de organisatie, binnen alle functies en op alle niveaus.

Continue verbetering dient te leiden tot betere resultaten, zoals de prijs, de kosten, de productiviteit, de time to market, de levering, de responsiviteit, de winst en klant- en medewerkerstevredenheid. Er is een tendens dat verbeteringsactiviteiten zich richten op een niveau (afdeling, proces, component e.d.) die de overall bedrijfsresultaten niet verbeteren. Dit leidt tot het verplaatsen van beperkingen of problemen naar ergens anders in de procesketen.

Wanneer kan het beter?

Verbetering gaat niet over het gebruik van een set van tools en technieken. Verbetering gaat ook zeker niet alleen over organisatiebewegingen, het organiseren van verbeterteams en het opleiden van mensen.

‘Verbetering is een gevolg’

Er is sprake van verbetering na een gunstige verandering in organisatieprestaties. Indien de gunstige verandering uitblijft, dan dienen er activiteiten uitgevoerd te worden, op welk vlak dan ook, om de gunstige verandering alsnog te bereiken. De grote vraag is, zijn dit verbeteringsactiviteiten of herstelactiviteiten? Zie hiervoor de blog: Er is altijd wel iets te verbeteren

Waarom kan het beter?

Alle managementactiviteit zijn gericht op controle of op verbetering. Managers wijden ofwel hun inspanningen aan het handhaven van de prestaties, het voorkomen van grote verandering of het creëren van verandering; als doorbraak of als verbetering. Wanneer een bedrijf stil blijft staan, verliezen zij hun concurrentiepositie, dus dienen er verbeteringen plaats te vinden om gelijke tred te houden in de vaak complexe bedrijfsomgevingen.

Geen zin? Dan maak je maar zin!

practice what you preach

Hoe kan het beter?

Elk systeem, programma of project dient te voorzien in een verbeteringscyclus. Daarom dienen, als een doelstelling is bereikt, de activiteiten gericht te zijn op het identificeren van manieren om het werk (nog) beter te doen.

Continue verbetering wordt uitgevoerd door teams die problemen opsporen, naar oplossingen zoeken of veranderingen doorvoeren. Deze teams kunnen afdelingsgericht of afdeling-overstijgend werken. Voorwaarde is dat het beleid en de (strategische) doelstellingen wordt ondersteund. Dit vraagt een adequaat sturingsmechanisme die de teams naar hun doel leidt, en er vooral voor zorgt dat de omgeving succesvol is!

Conclusie

Continue verbetering heeft betrekking op de gehele organisatie en alles wat het doet. Het dient de hoogste prioriteit te zijn van het uitvoerend management en het succes hangt af van betrokkenheid van de top. Deze toezegging dient duidelijk zichtbaar te zijn. Het is niet genoeg om alleen beleidskaders af te kondigen. Als uitvoerend management haar betrokkenheid niet toont door te doen wat het zegt, kan niet worden verwacht dat anderen zich committeren aan het beleid.

practice-what-you-preach