Servicewaardesysteem en waardeketen

Een servicewaardesysteem (SVS) beschrijft hoe de componenten en activiteiten van een organisatie samenwerken om waardecreatie mogelijk te maken. ITIL 4 gebruikt deze naam; ITIL Version 5 noemt het het ITIL-waardesysteem. Version 5 werd geïntroduceerd in januari 2026; de Foundation-syllabus dateert van februari 2026.

Input en output

Vraag is de behoefte of wens van afnemers aan producten en services. Medewerkers die om veilige toegang op afstand vragen, uiten een vraag. Een kans is een mogelijkheid om waarde toe te voegen of de organisatie te verbeteren, zoals een ongebruikte cloudfunctie die kosten kan verlagen. De organisatie beslist welke kansen ze benut.

De output van het systeem is waarde: de baten, bruikbaarheid en het belang die belanghebbenden ervaren. Een voltooide declaratieapp is een product van werk. Dat managers declaraties in twee minuten in plaats van twee dagen goedkeuren, is een resultaat dat de app bruikbaar maakt. Het voltooien van de software alleen toont niet aan dat mensen er baat bij hebben.

Waarde ontstaat door cocreatie. De leverancier draagt technologie en ondersteuning bij; afnemers dragen kennis, beslissingen en gebruik bij. Een duidelijke storingsmelding met een schermafbeelding kan een medewerker helpen de service sneller te herstellen.

Vijf samenwerkende componenten

Version 5 gebruikt waardeketen en managementpractices voor de overeenkomstige componenten. Deze componenten werken samen terwijl een activiteit plaatsvindt. Het zijn geen vijf fasen die je op volgorde doorloopt.

De zeven leidende principes blijven: richt je op waarde; begin waar je bent; werk iteratief met feedback; werk samen en bevorder zichtbaarheid; denk en werk holistisch; houd het eenvoudig en praktisch; optimaliseer en automatiseer. Ze geven vorm aan keuzes in het hele systeem. Zo betekent “begin waar je bent” dat je een bestaand proces voor het opnieuw instellen van wachtwoorden onderzoekt voordat je het vervangt.

Volg een verbetering van het opnieuw instellen van wachtwoorden

Een bank met 40 vestigingen ontvangt meldingen van telefonische wachttijden van 20 minuten voor het opnieuw instellen van wachtwoorden. Dat is vraag. Het identiteitsplatform heeft een ongebruikte zelfservicefunctie om wachtwoorden opnieuw in te stellen: een kans.

De besturing toetst het idee aan het beveiligingsbeleid. Waardeketenactiviteiten verzamelen de behoeften van medewerkers, ontwerpen en bouwen de stroom voor het opnieuw instellen van wachtwoorden en nemen die in gebruik. De practices servicedesk, informatiebeveiligingsmanagement en wijzigingsbeheer leveren mensen, kennis en hulpmiddelen. Voortdurende verbetering controleert later of de wachttijd is gedaald. Dat medewerkers binnen enkele minuten weer aan het werk kunnen, is de waarde die zij ervaren.

Bekijk het hele systeem

Een organisatiesilo ontstaat wanneer teams geïsoleerd werken en weinig informatie delen. Afzonderlijke teamdoelen kunnen dubbel werk of informatieverlies bij overdrachten aan het zicht onttrekken. Een gezamenlijk beeld van het pad naar waarde helpt teams hun werk af te stemmen en het systeem laat verschillende routes toe wanneer de vraag verandert.

De vier dimensies zijn perspectieven om het hele systeem te onderzoeken: organisaties en mensen, informatie en technologie, partners en leveranciers, en waardestromen en processen. Ze verschillen van de vijf componenten. Het SVS kan een hele organisatie of een deel ervan beschrijven, in elke sector en op elke schaal.

Besturing geeft richting aan een organisatie en houdt er toezicht op. Besturing zorgt dat het werk aansluit op het doel, de strategie en het beleid van de organisatie. Een bestuursorgaan is de persoon of groep met de hoogste eindverantwoordelijkheid voor prestaties en naleving: een bestuur, toezichthouders of de eigenaar van een klein bedrijf. Een commissie kan een beslissing voorbereiden, maar het bestuursorgaan behoudt de eindverantwoordelijkheid.

Evalueren, richting geven en toezicht houden

Om een handeling in te delen, vraag je wat de beslissing bereikt. Een mogelijke richting beoordelen is evalueren; richting en verantwoordelijkheid vaststellen is richting geven; prestaties daaraan toetsen is toezicht houden. Alleen de naam van het document is niet genoeg: een rapport kan informatie bieden voor een evaluatie of voor een beslissing in het kader van toezicht.

Vertaal richting naar dagelijkse beslissingen

Een beleid legt verwachtingen en bedoelingen die richting geven aan beslissingen en activiteiten formeel vast. Bijvoorbeeld: “Persoonsgegevens van klanten moeten worden opgeslagen in goedgekeurde datacenters binnen de regio van de klant.” Het management kiest en configureert vervolgens datacenters die aan het beleid voldoen. Het beleid biedt een gezamenlijke regel zonder elke technische handeling voor te schrijven.

Besturing en management hebben verschillende taken. Besturing bepaalt de richting, keurt beleid goed en houdt toezicht op resultaten. Management plant, organiseert en voert het werk binnen die richting uit en rapporteert daarna terug.

Stel dat een bestuur bepaalt dat een webwinkel een beschikbaarheid van 99,9% moet halen. Het IT-management beslist hoe de winkel wordt ontworpen, onderhouden en ondersteund. Het meet de beschikbaarheid en rapporteert de resultaten aan het bestuur. Het bestuur toetst die resultaten aan de uitgezette richting; het hoeft niet elke serverinstelling te kiezen.

Beheersmaatregelen kunnen sneller werken mogelijk maken

Duidelijke risicogrenzen laten teams met vertrouwen routinebeslissingen nemen. Beleid kan toestaan dat standaardwijzigingen met een laag risico vooraf worden goedgekeurd, terwijl wijzigingen met een hoger risico een afzonderlijke beoordeling krijgen. Teams weten dan wanneer ze kunnen handelen en wanneer ze een wijzigingsautoriteit moeten betrekken.

Een wijzigingsautoriteit beslist over afzonderlijke wijzigingen als onderdeel van het management. Een wijzigingsautoriteit is niet het bestuursorgaan enkel omdat ze werk goedkeurt. Als voor elke wijziging goedkeuring van een commissie wordt toegevoegd, kan dat de levering van waarde vertragen zonder de beheersing te verbeteren. Beoordeel of elke beheersmaatregel een nuttig doel heeft en pas daarbij “houd het eenvoudig en praktisch” toe.

Pas dezelfde logica toe op AI

AI-besturing omvat toezicht, beleid en verantwoordingsplicht voor veilig, rechtmatig en transparant AI-gebruik dat organisatiedoelen ondersteunt. Een bestuursorgaan evalueert een voorgestelde AI-service en de risico’s ervan, bepaalt wie verantwoordelijk is en welk beleid geldt, en houdt toezicht op prestaties en naleving. Het management implementeert en beheert de service binnen die grenzen.

Ook besturing heeft voortdurende verbetering nodig. Het bestuursorgaan beoordeelt of de beheersmaatregelen nuttig blijven als de organisatie, technologie en risico’s veranderen. Beleid dat ooit goede beslissingen ondersteunde, moet mogelijk worden herzien wanneer het werk gaat vertragen zonder een actueel risico aan te pakken.

De servicewaardeketen is een operationeel model voor het creëren, leveren en voortdurend verbeteren van services. Een operationeel model beschrijft hoe een organisatie samen met anderen waarde creëert en hoe ze zichzelf bestuurt en beheert. ITIL 4 noemt zes onderling verbonden activiteiten. Elke activiteit zet input om in output en die output kan input worden voor andere activiteiten.

Wat elke activiteit bijdraagt

Herken werk aan het doel

Beslissen om volgend jaar e-mail in de cloud te financieren is plannen. Een klacht van een gebruiker ontvangen of de bedrijfsbehoeften van volgend jaar bespreken is betrekken, het belangrijkste contactpunt met afnemers en andere externe partijen. Dalende tevredenheid analyseren en een verbetering afspreken is verbeteren.

Voor een online boekingsservice stelt ontwerpen en in productie nemen kwaliteits- en gebruikerseisen vast en regelt de ingebruikname. Verwerven/bouwen maakt en test software of verkrijgt componenten van een leverancier. De service dagelijks beheren en na een storing herstellen is leveren en ondersteunen.

Een bruikbare indeling volgt wat het werk bereikt. Door 200 laptops te kopen, maak je componenten beschikbaar; dat hoort dus bij verwerven/bouwen. Feedback van medewerkers over die laptops verzamelen hoort bij betrekken. Dezelfde mensen kunnen bij beide activiteiten helpen.

Output verbindt de activiteiten

Een verzoek dat via betrekken is vastgelegd, kan input worden voor ontwerpen en in productie nemen. Een component die via verwerven/bouwen is geleverd, kan via ontwerpen en in productie nemen in gebruik worden genomen. Prestatie-informatie van leveren en ondersteunen kan verbeteren laten zien waar resultaten achterblijven en plannen helpen prioriteiten te stellen.

Deze verbanden schrijven geen vaste volgorde voor. Een klein verzoek kan alleen de activiteiten gebruiken die nodig zijn. Bij een nieuwe service kan ontwerpen en in productie nemen opnieuw nodig zijn nadat feedback een ontbrekende eis aan het licht brengt. Verbeteren kan aan een bestaande service werken terwijl verwerven/bouwen een nieuwe component ontwikkelt.

Activiteiten zijn breder dan practices of teams

Elke activiteit maakt gebruik van meerdere practices en een practice kan meerdere activiteiten ondersteunen. Serviceniveaubeheer helpt betrekken om streefwaarden met klanten af te spreken, helpt leveren en ondersteunen om resultaten te beoordelen en helpt verbeteren om vast te stellen welke streefwaarden niet zijn gehaald. Leveren en ondersteunen kan daarom niet worden gelijkgesteld aan de servicedesk.

Als je de zes activiteiten als een vaste projectvolgorde ziet, blijft deze flexibiliteit verborgen. Het model biedt verbonden soorten werk; een waardestroom kiest er een route doorheen voor de vraag die wordt behandeld.

Een waardestroom is een reeks stappen om producten en services voor afnemers te creëren en te leveren. Het is een praktische route door waardeketenactiviteiten. Elke stap steunt ook op practices die vaardigheden, informatie, hulpmiddelen en processen leveren.

Houd drie niveaus uit elkaar

Een proces werkt vaak binnen een practice en draagt bij aan een deel van een stroom. Een lijst met afdelingen vertelt wie deelnemen, maar legt niet uit wat er gebeurt tussen de aanleiding en het bruikbare resultaat.

Maak een waardestroomkaart

1. Noem de aanleiding: de vraag of kans die het werk start.
2. Zet de werkelijke stappen op een rij totdat de afnemer waarde ontvangt.
3. Wijs elke stap toe aan de waardeketenactiviteit die erin wordt uitgevoerd.
4. Voeg de belangrijkste benodigde practices toe.
5. Controleer het eindresultaat met de afnemer en gebruik de resultaten voor verbetering.

Volg een herstel

Een gebruiker meldt een fout in de verkoopapp. De servicedesk registreert en beoordeelt de melding: betrekken, ondersteund door servicedesk en incidentbeheer. Ondersteuning past een bekende tijdelijke oplossing toe zodat de verkoop kan worden hervat: leveren en ondersteunen, met incidentbeheer en kennis over de tijdelijke oplossing.

Ontwikkelaars onderzoeken de oorzaak en schrijven en testen een structurele oplossing: verwerven/bouwen, met inzet van probleembeheer en softwareontwikkeling. De oplossing beoordelen, goedkeuren en in gebruik nemen draagt bij aan ontwerpen en in productie nemen, met wijzigingsbeheer en uitrolbeheer.

Het team informeert de gebruiker en controleert of de app werkt: betrekken, gevolgd door bevestiging van leveren en ondersteunen. De ontwikkeling van vergelijkbare incidenten beoordelen is verbeteren. De waarde voor de afnemer is weer kunnen verkopen. Herstel kan die waarde leveren voordat de structurele oplossing klaar is.

Routes kunnen activiteiten herhalen

Een functie om declaraties mobiel goed te keuren volgt een andere route: betrekken legt de behoefte vast; plannen bepaalt prioriteit en budget; ontwerpen en in productie nemen stelt de eisen vast; verwerven/bouwen maakt de functie; ontwerpen en in productie nemen neemt die in gebruik; leveren en ondersteunen stelt die beschikbaar; betrekken verzamelt feedback; verbeteren plant wijzigingen. Betrekken of ontwerpen en in productie nemen herhalen is normaal. De route volgt de behoeften van het werk.

Primaire en ondersteunende stromen

In Version 5 levert een primaire waardestroom waarde aan externe afnemers op de manier die het operationele model beoogt, bijvoorbeeld door klantbestellingen af te handelen. Een ondersteunende waardestroom bedient interne afnemers en ondersteunt primaire stromen, bijvoorbeeld door medewerkers of leveranciers aan te sluiten. Beide gebruiken dezelfde activiteiten. “Ondersteunend” beschrijft wie de stroom bedient en wat die ondersteunt; het betekent niet dat het werk geen waarde heeft.

Door een stroom in kaart te brengen, maak je de dimensie waardestromen en processen zichtbaar. Je past “denk en werk holistisch” toe door de hele route te tonen, inclusief overdrachten tussen teams die mogelijk elk maar één deel zien.

Waardestroomanalyse onderzoekt en toont hoe werk doorstroomt, zodat teams zien hoe waarde ontstaat en waar verbetering mogelijk is. Waardestroommanagement is het voortdurende werk om die stroom te beheren en te verbeteren.

Maak vertragingen zichtbaar

Een waardestroomkaart van de huidige situatie legt vast hoe het werk werkelijk verloopt. Neem stappen, mensen, informatie en werkproducten die worden overgedragen, bewerkingstijd en wachttijd op. Een waardestroomkaart van de gewenste situatie toont de verbeterde stroom die het team wil bereiken. Als je alleen de officiële procedure vastlegt, kun je de wachtrijen en herhaalde gegevensinvoer missen die de wachttijd van een afnemer verklaren.

Doorlooptijd is de verstreken tijd van de aanleiding tot de geleverde waarde. Bewerkingstijd is de tijd die wordt besteed aan het werken aan het item. Voor een opeenvolgende stroom met niet-overlappende perioden van bewerking en wachten geldt:

Gebruik dezelfde tijdseenheid in teller en noemer.

Werk een laptopaanvraag uit

De bewerkingstijd is 4 h. De wachttijd is 48 h, wat een doorlooptijd van 52 h oplevert. De stroomefficiëntie is ongeveer 7,7%, omdat slechts 4 van de 52 verstreken uren aan het item wordt gewerkt.

Door de standaardlaptop vooraf goed te keuren, daalt de wachttijd voor goedkeuring van 16 h naar 1 h. De bewerkingstijd blijft 4 h; de wachttijd wordt 33 h. De doorlooptijd is nu 37 h en de stroomefficiëntie ongeveer 10,8%. De resterende wachtrij van 24 h voor het inrichtteam komt als volgende in aanmerking voor onderzoek.

Halvering van de configuratietaak van 2 h bespaart slechts 1 h op de oorspronkelijke 52 h: ongeveer 1,9%. Het verkorten van de wachttijd voor goedkeuring bespaarde 15 h. Controleer na een wijziging de hele stroom; als je werk sneller naar een andere wachtrij stuurt, kan de totale doorlooptijd gelijk blijven.

Stem de verbetering af op het soort werk

Complexiteitsdenken helpt bij het kiezen van een werkwijze.

• Geordend werk is voorspelbaar. Standaardaanvragen voor laptops kunnen afgesproken stappen en automatisering gebruiken.
• Bij complex werk worden oorzaak en gevolg pas achteraf duidelijk. De ontwikkeling van een onbekend digitaal product vraagt om kleine experimenten en snelle feedback.
• Chaotische situaties moeten eerst worden gestabiliseerd. Herstel bij een grote storing met onbekende oorzaak voldoende beheersing om daarna zinvol te kunnen analyseren.

Als je onzeker werk als een volledig bekende procedure behandelt, kun je een slechte oplossing vastleggen. Als je elk routineverzoek als een experiment behandelt, verspil je inspanning. Kies een aanpak die bij de situatie past en gebruik vervolgens waargenomen resultaten om die aan te passen.

Waardestroommanagement gebruikt de kaart en maatstaven om de practices achter de stroom te verbeteren, onnodige goedkeuringen en herhaalde invoer weg te nemen en de route opnieuw te beoordelen als de vraag verandert. Bij elke voorgestelde wijziging kun je het model voor voortdurende verbetering gebruiken om een nulmeting vast te stellen, te handelen en resultaten te controleren.

Digitaal product- en servicemanagement beheert producten en services die afhankelijk zijn van digitale technologie, van idee tot uitfasering. Een digitaal product is hoofdzakelijk opgebouwd uit software, gegevens en digitale infrastructuur, zoals een app voor mobiel bankieren. Een digitale service geeft afnemers toegang tot de mogelijkheden van producten, zoals online betalen.

De levenscyclus van Version 5

De ITIL-product- en servicelevenscyclus noemt acht activiteiten: verkennen, ontwerpen, verwerven, bouwen, in productie nemen, beheren, leveren en ondersteunen. De eerste vier creëren en wijzigen vooral producten; de laatste vier houden vooral producten operationeel en leveren daarmee services. In productie nemen brengt nieuwe of gewijzigde producten in gebruik.

Vanuit het perspectief van de organisatie vormen deze activiteiten de waardeketen van Version 5. Een waardestroom combineert ze met managementpractices voor een bepaalde soort vraag. De levenscyclus beschrijft het werk dat tijdens het bestaan van een product nodig is; een stroom beschrijft een bepaalde route door dat werk.

Het waardesysteem blijft het overkoepelende systeem met vijf componenten. De levenscyclus vervangt besturing, leidende principes, practices of voortdurende verbetering niet.

Gebruik activiteiten samen

De levenscyclus bestaat niet uit één lineaire reeks. Verkennen kan doorgaan terwijl ontwikkelaars een release bouwen. Feedback uit ondersteuning kan rechtstreeks tot ontwerpen leiden. Een product dat elke twee weken wordt uitgebracht, kan opnieuw ontwerpen, bouwen en in productie nemen doorlopen terwijl de bestaande service blijft draaien en gebruikers blijft bedienen.

Een gemeente lanceert een app om kapotte straatverlichting te melden. Ondersteuning merkt dat meldingen zonder locatie binnenkomen. Verkennen onderzoekt waarom, ontwerpen voegt een automatische kaartmarkering toe en bouwen en in productie nemen realiseren die en nemen die in gebruik. Beheren en leveren houden de bestaande app tijdens dit werk beschikbaar. Het product is tegelijk bij meerdere activiteiten betrokken.

Breng Version 5 in verband met ITIL 4

Hieronder staat een globale vergelijking van het werk, geen exacte gelijkstelling van activiteiten.

De versies delen werk verschillend in. Daarom moet je bij een werkelijke stroom de activiteiten beoordelen op hun eigen doel. Beheren houdt technologie in goede staat; leveren biedt de service en voorziet in gewone gebruikersbehoeften. Ze dragen met verschillend werk bij aan hetzelfde resultaat.

Meet de resultaten van activiteiten

Bruikbare voorbeelden van maatstaven zijn de getoetste behoefte van afnemers achter onderdelen van de routekaart voor verkennen, het slagingspercentage van geautomatiseerde tests voor bouwen en wijzigingen die zonder incidenten zijn uitgerold voor in productie nemen. Beheren kan de beschikbaarheid volgen, leveren de afhandeltijd van verzoeken en de gebruikerstevredenheid, en ondersteunen de hersteltijd.

Deze maatstaven helpen zwakke punten in een stroom te vinden. Een hoog slagingspercentage bij bouwtests kan samengaan met trage verzoekafhandeling: succes in één activiteit laat niet zien of de afnemer op tijd een bruikbare service ontvangt.

Om een bruikbaar digitaal product te creëren, moet je een behoefte begrijpen, een oplossing vormgeven, middelen verkrijgen en de oplossing laten werken. Version 5 noemt dit werk verkennen, ontwerpen, verwerven en bouwen. Feedback kan werk tussen deze activiteiten laten bewegen voordat een volledig product bestaat.

Verken een behoefte waarin je wilt voorzien

Verkennen onderzoekt behoeften van afnemers, kansen in technologie en op de markt, en de strategie van de organisatie. Het helpt beslissen welke producten en services worden aangeboden of gewijzigd en houdt de routekaart afgestemd op die behoeften en kansen. Een routekaart geeft richting aan geplande productontwikkeling en moet worden herzien als nieuwe inzichten daar aanleiding toe geven.

Onderzoek bij een kliniek laat zien dat patiënten online afspraken willen maken. De kliniek voegt online boeken toe aan haar routekaart. Het bruikbare inzicht is de behoefte van de patiënt en de service die daarin kan voorzien, niet alleen dat een nieuwe applicatie kan worden gebouwd.

Ontwerp de hele oplossing

Ontwerpen zet behoeften om in specificaties en prototypes. Een productspecificatie beschrijft de vereiste functies, kwaliteitsniveaus en beperkingen. Een prototype is een vroege, vereenvoudigde versie waarmee een idee bij gebruikers wordt getest voordat het volledig wordt gebouwd.

De specificatie van de kliniek vereist dat patiënten binnen drie schermen een afspraak kunnen maken, verplaatsen of annuleren, het systeem buiten kantooruren kunnen gebruiken en 24 uur voor een bezoek herinneringen ontvangen. Elke eis beschrijft gedrag of kwaliteit waaraan de uiteindelijke oplossing kan worden getoetst.

Tien patiënten proberen een aanklikbaar prototype. Vier kunnen de annuleerknop niet vinden. Het team verandert het ontwerp voordat het de volledige software schrijft. Een prototype dient om te leren en kan worden weggegooid nadat het antwoord op de vraag heeft gegeven. Als een team het prototype als bijna voltooide software ziet, kan het een zwak ontwerp behouden alleen omdat er al iets bestaat.

Ontwerpen omvat ook hoe het product wordt beheerd en ondersteund. Monitoring, back-ups en hulp aan gebruikers hebben een plaats nodig in de oplossing. Als die behoeften pas na de lancering worden ontdekt, kunnen duurdere wijzigingen nodig zijn. Zo pas je “denk en werk holistisch” toe op de hele levenscyclus van het product.

Verwerf middelen

Verwerven verkrijgt of wijst de middelen toe die de oplossing nodig heeft. Daaronder vallen cloudcapaciteit, licenties, apparaten, gegevens en mensen met geschikte vaardigheden. Middelen kunnen van leveranciers of uit de eigen organisatie komen. Een bestaande component hergebruiken of een interne specialist toewijzen is ook werk dat bij verwerven hoort.

De kliniek sluit een contract met een sms-dienstverlener voor herinneringen. Ze wijst ook interne medewerkers toe om het boekingssysteem te ondersteunen. Kopen is één manier om middelen te verwerven; het omvat niet de volledige betekenis van de activiteit.

Bouw en controleer de werkende oplossing

Bouwen ontwikkelt, integreert en test componenten om het ontwerp om te zetten in een werkende oplossing. Een test controleert of een component of product aan de eisen voldoet en zich volgens verwachting gedraagt. Bij het testen van de herinneringsfunctie controleer je ook het voorgeschreven tijdstip, niet alleen of een bericht kan worden verstuurd.

Bij continue integratie voegen ontwikkelaars wijzigingen regelmatig samen in een gedeelde codebasis en controleren geautomatiseerde bouwprocessen en tests die wijzigingen. Dit geeft vroeg feedback over integratiefouten en gebreken die de tests kunnen opsporen. Als die tests slagen, betekent dat niet dat elk gebrek is gevonden; het resultaat hangt af van wat is getest.

De kliniek kan het ontwerp na een prototypetest herzien, een ander middel verwerven na een bouwtest of een nieuwe behoefte ontdekken terwijl het product wordt gebouwd.

Een werkend digitaal product moet in gebruik worden genomen, in goede staat blijven en een bruikbare service bieden. Gebruikers hebben ook hulp nodig als de service uitvalt. Version 5 verdeelt dit werk in in productie nemen, beheren, leveren en ondersteunen.

Neem in productie

In productie nemen introduceert nieuwe of gewijzigde producten en services, inclusief release, uitrol en het aansluiten of afmelden van leveranciers. Uitrol brengt componenten naar een omgeving. Een release stelt een versie of verzameling componenten beschikbaar voor gebruik. Software kan in productie worden geïnstalleerd terwijl een functie is uitgeschakeld, dus uitrol en release hoeven niet tegelijk plaats te vinden.

Continue levering houdt geteste wijzigingen gereed voor uitrol, waarbij een persoon beslist wanneer dat gebeurt. Continue uitrol brengt elke wijziging die de geautomatiseerde tests doorstaat zonder handmatige beslissing naar de productieomgeving. Geen van beide termen betekent dat gebruikers noodzakelijkerwijs een nieuwe functie krijgen telkens wanneer componenten worden overgebracht.

Beheer betrouwbare technologie

Beheren laat producten draaien, onderhoudt en monitort ze volgens de afgesproken prestaties en betrouwbaarheid. Betrouwbaarheid is het vermogen om vereiste functies gedurende een bepaalde tijd volgens verwachting uit te voeren. Waarneembaarheid betekent dat je de interne toestand van een systeem begrijpt op basis van output zoals logboeken, maatstaven en traces. Site reliability engineering (SRE) past software-engineering toe op beheer, waaronder automatisering en meetbare betrouwbaarheidsdoelen.

Een gebeurtenis is een toestandsverandering die van belang is voor het beheer van een service of configuratie-item. De voltooiing van een back-up is een gebeurtenis; een schijfgebruik dat 90% bereikt ook. Veel gebeurtenissen hoeven alleen te worden geregistreerd. Andere waarschuwen dat ingrijpen een incident kan voorkomen.

Voor een boekingsservice die 99,9% van een hele maand van 30 dagen beschikbaar is, bedraagt de totale tijd 43.200 minuten. De toegestane uitvaltijd is daarvan 0,1%: 43,2 minuten. Bij 43 minuten uitval is de beschikbaarheid ongeveer 99,90%, waarmee de streefwaarde net wordt gehaald. Vergelijk niet-afgeronde waarden voordat je beslist of een resultaat dicht bij de grens aan een streefwaarde voldoet.

Lever gewone servicehandelingen

Leveren biedt dagelijks services, sluit gebruikers aan en meldt ze af, handelt verzoeken af en verzamelt feedback. Een serviceverzoek vraagt om een afgesproken normale servicehandeling, zoals toegang tot een gedeelde map of een nieuwe laptop. De bevoegde gebruiker of vertegenwoordiger dient het verzoek in.

Ondersteun als de service problemen geeft

Ondersteunen herstelt de normale werking en vermindert toekomstige uitval door incidenten op te lossen, van calamiteiten te herstellen en problemen te beheren. Een incident is een ongeplande onderbreking of kwaliteitsvermindering. Een calamiteit veroorzaakt ernstig verlies of ernstige schade, zoals een brand die een datacenter verwoest.

Een probleem is een werkelijke of mogelijke oorzaak van incidenten. Een fout is een gebrek of kwetsbaarheid die incidenten kan veroorzaken. Een bekende fout is een geanalyseerd probleem dat nog niet is opgelost.

Stel dat 30 mensen niet kunnen printen na een gebrekkige update van een stuurprogramma. Hun service-uitval bestaat uit incidenten. De gebrekkige update is het probleem; zodra het is geanalyseerd maar nog niet verholpen, is het een bekende fout. Door het stuurprogramma terug te draaien, kan printen worden hersteld terwijl de structurele oplossing nog op zich laat wachten. Herstel betekent dus niet dat de oorzaak is weggenomen.

“Ik heb toegang nodig tot de verkoopmap” is een verzoek. “De verkoopmap gaat niet open” meldt een incident. Bepaal of de gebruiker een normale handeling vraagt of herstel van iets dat is uitgevallen.

Een practice is een geheel van organisatorische middelen dat is ingericht om werk uit te voeren of een doel te bereiken. Version 5 noemt dit een managementpractice. Een practice bestrijkt alle vier de dimensies, waaronder mensen en vaardigheden, informatie en technologie, partners en leveranciers, en waardestromen en processen.

Een practice is breder dan een proces of afdeling. Incidentbeheer kan processen voor registratie en diagnose bevatten, een kennisbank, monitoringhulpmiddelen en mensen van een servicedesk, netwerkteam en leverancier. Die middelen vormen samen het vermogen om de service te herstellen.

Twee manieren om de 34 practices in te delen

Version 5 behoudt de 34 namen van de practices. Uitrolbeheer, infrastructuur- en platformmanagement en softwareontwikkeling en -beheer gaan van de technische groep naar product- en servicemanagement. Informatiebeveiligingsmanagement en financieel servicemanagement komen ook in die groep terecht en verlaten de groep algemeen management.

Algemene managementpractices in Version 5

De 12 practices zijn architectuurmanagement; voortdurende verbetering; kennismanagement; meting en rapportage; organisatieverandermanagement; portfoliomanagement; projectmanagement; relatiebeheer; risicomanagement; strategiemanagement; leveranciersmanagement; en personeels- en talentmanagement.

Deze vermogens ondersteunen de manier waarop de organisatie wordt beheerd. Meting en rapportage levert bijvoorbeeld betrouwbare informatie voor beslissingen over verbetering. Voortdurende verbetering helpt practices en services afgestemd te houden op veranderende behoeften.

Practices voor product- en servicemanagement in Version 5

De 22 zijn beschikbaarheidsbeheer; bedrijfsanalyse; capaciteits- en prestatiebeheer; wijzigingsbeheer; uitrolbeheer; incidentbeheer; informatiebeveiligingsmanagement; infrastructuur- en platformmanagement; IT-assetmanagement; monitoring en gebeurtenisbeheer; probleembeheer; releasebeheer; servicecatalogusbeheer; serviceconfiguratiebeheer; servicecontinuïteitsbeheer; serviceontwerp; servicedesk; financieel servicemanagement; serviceniveaubeheer; serviceverzoekbeheer; servicevalidatie en testen; en softwareontwikkeling en -beheer.

Verbind vermogens met een stroom

Een laptopaanvraag gebruikt serviceverzoekbeheer om de afgesproken handeling af te handelen, IT-assetmanagement om het apparaat te volgen, uitrolbeheer om software te installeren en de servicedesk om contact op te nemen met de gebruiker. Eén waardeketenactiviteit kan al deze practices nodig hebben. De servicedesk kan ook aan meerdere activiteiten bijdragen door vraag te ontvangen, gebruikers op de hoogte te houden en feedback te verzamelen.

Maak niet standaard van elke practice een afzonderlijk team. Organisaties nemen over en passen aan wat ze nodig hebben, combineren middelen waar dat nuttig is en bouwen vermogens geleidelijk op. Een kleine organisatie kan voor meerdere practices op dezelfde mensen steunen en tegelijk elk doel duidelijk houden.

Gebruik practicehandleidingen als uitgangspunt

Officiële practicehandleidingen beschrijven de practices. ITIL 4-handleidingen behandelen het doel, kernbegrippen, de reikwijdte, succesfactoren en de vier dimensies, inclusief processen en waardestromen waaraan de practice bijdraagt. Ze bieden een gemeenschappelijke taal en een uitgangspunt om aan te passen. “Begin waar je bent” en “houd het eenvoudig en praktisch” volgen betekent dat je die richtlijnen laat aansluiten op het werkelijke werk van de organisatie.

Wanneer gebruikers contact opnemen met een leverancier, kunnen meerdere practices bijdragen. Hun doelen helpen onderscheid te maken tussen contact, gewone verzoeken, herstel, onderzoek en afspraken over servicekwaliteit.

Contact, herstel en oorzaken

De servicedesk kan telefoon, chat, een portaal, e-mail of contact op locatie gebruiken. De servicedesk is het aanspreekpunt, terwijl incidentbeheer het vermogen voor herstel is. Andere technische teams en leveranciers kunnen een groot deel van dat herstel uitvoeren.

Incidentbeheer kan de service met een tijdelijke oplossing herstellen voordat de oorzaak bekend is. Probleembeheer kan na herstel doorgaan of een zwakke plek onderzoeken voordat zich een incident voordoet. Herhaalde incidenten zijn nuttig bewijsmateriaal, maar herhaling is niet nodig om van een probleem te spreken.

Een vooraf gedefinieerd verzoek om via een portaal een wachtwoord opnieuw in te stellen is een serviceverzoek. Als een gebruiker onverwacht geen toegang krijgt tot een werkende service, kan dat een incident zijn. Kijk naar de behoefte en de afgesproken servicehandeling, niet alleen naar het woord “wachtwoord”.

Spreek kwaliteit af en onderhoud relaties

Serviceniveaubeheer stelt duidelijke, op de bedrijfsbehoeften gebaseerde servicestreefwaarden vast en beoordeelt, monitort en beheert de levering aan de hand daarvan. Een serviceniveauovereenkomst (SLA) legt de vereiste services en het verwachte serviceniveau vast die leverancier en klant zijn overeengekomen. Een streefwaarde voor de reactietijd is nuttig wanneer die weerspiegelt wat het werk van de klant nodig heeft.

Relatiebeheer ontwikkelt relaties met belanghebbenden op strategisch en tactisch niveau. Het helpt behoeften en bedrijfsimpact te begrijpen die verder gaan dan één contact over één storing. Het effect van een slechte service met een afdelingsdirecteur bespreken kan informatie geven voor toekomstige prioriteiten.

Monitoring en gebeurtenisbeheer observeert services en componenten en registreert en rapporteert geselecteerde belangrijke toestandsveranderingen. Een waarschuwing bij een drempelwaarde levert informatie die onderzoek of actie kan starten; de practice vervangt niet het werk om een uitgevallen service te herstellen.

Volg een vertraging in de salarisadministratie

Op betaaldag geeft monitoring een waarschuwing dat de reactietijd van de salarisadministratie de drempelwaarde heeft overschreden. De servicedesk ontvangt telefoontjes van gebruikers. Incidentbeheer voegt servercapaciteit toe om de normale snelheid te herstellen. Probleembeheer identificeert later een gebrekkige database-index als oorzaak.

Serviceniveaubeheer rapporteert aan de klant dat de streefwaarde voor de reactietijd is overschreden. Relatiebeheer bespreekt de bedrijfsimpact met de financieel directeur. Elke bijdrage heeft een ander doel, ook als dezelfde manager aan meerdere gesprekken deelneemt.

Als gebruikers weer kunnen werken nadat capaciteit is toegevoegd, kan het incident eindigen terwijl het probleem open blijft staan. Door dat onderscheid zichtbaar te houden, voorkom je dat succesvol herstel onopgeloste oorzaken verbergt die de volgende betaaldag kunnen beïnvloeden.

Een nieuwe servicefunctie vraagt meer dan installatie. Risico’s moeten worden beoordeeld, gebruikers hebben op het juiste moment toegang nodig en de organisatie heeft betrouwbare informatie over componenten, kosten en leveranciers nodig. Deze bijdragen komen van verschillende practices.

Voer succesvolle wijzigingen door

Wijzigingsbeheer streeft naar een zo groot mogelijk aantal succesvolle product- en servicewijzigingen door risico’s te beoordelen, goedkeuring te verlenen en de wijzigingskalender te beheren. Een wijziging voegt iets toe, past iets aan of verwijdert iets dat direct of indirect effect kan hebben op services. Het oorspronkelijke ITIL 4 Foundation-boek noemde deze practice change control.

Het doel is succesvolle wijzigingen, niet een zo groot mogelijk aantal goedkeuringsvergaderingen. Standaardwijzigingen met een laag risico kunnen vooraf worden goedgekeurd. De bevoegdheid en beoordeling passen bij het risico en de context van de wijziging.

Een functie kan worden uitgerold terwijl de schakelaar uit staat. Een latere release stelt de functie beschikbaar aan gebruikers. Dit onderscheid verklaart waarom “succesvol geïnstalleerd” niet altijd betekent dat “gebruikers het kunnen gebruiken”.

Ken de componenten en hun waarde

Serviceconfiguratiebeheer levert nauwkeurige, betrouwbare informatie over services en de configuratie-items die ze ondersteunen, waar en wanneer die nodig is. Een configuratie-item (CI) is een component die moet worden beheerd om een IT-service te leveren. Configuratie-informatie omvat instellingen en relaties, zoals welke applicatie van welke database afhankelijk is.

IT-assetmanagement plant en beheert de volledige levenscyclus van financieel waardevolle IT-componenten. Het ondersteunt waarde, kosten, risico’s, aankoop, hergebruik, afvoer en wettelijke of contractuele eisen. Een IT-asset kan een laptop of softwarelicentie zijn.

Eén laptop kan zowel een asset als een CI zijn. Vanuit het assetperspectief vraag je naar waarde en levenscyclus; vanuit het configuratieperspectief vraag je hoe de laptop is ingericht en verbonden om een service te leveren. Als je één registratie nauwkeurig bijhoudt, blijft het andere perspectief nodig.

Bescherm informatie en leveranciersprestaties

Informatiebeveiligingsmanagement beschermt de informatie die nodig is voor de bedrijfsvoering. Vertrouwelijkheid beperkt de toegang tot bevoegde mensen; integriteit houdt informatie juist en volledig; beschikbaarheid houdt de informatie bruikbaar wanneer dat nodig is.

Leveranciersmanagement beheert leveranciers en hun prestaties zodat ze een soepele levering van kwaliteitsproducten en -services ondersteunen. Voortdurende verbetering stemt producten, services, practices en andere beheerelementen af op veranderende bedrijfsbehoeften door voortdurende verbetering.

Rol een toepassing voor toegang op afstand uit

Voor 1.500 medewerkers beoordeelt wijzigingsbeheer het risico en plant de uitrol. Uitrolbeheer installeert de toepassing op testapparaten en daarna op laptops van medewerkers. Releasebeheer maakt gebruik gefaseerd mogelijk.

Serviceconfiguratiebeheer registreert apparaatversies en relaties. IT-assetmanagement volgt licenties. Informatiebeveiligingsmanagement controleert versleutelingsinstellingen en leveranciersmanagement houdt de leverancier aan het ondersteuningscontract. Voortdurende verbetering kan de uitrolresultaten gebruiken om de volgende wijziging te verbeteren. De stroom slaagt door deze gecombineerde vermogens; geen enkele practice levert elke bijdrage.

Voortdurende verbetering is terugkerend werk op elk niveau om prestaties aan de verwachtingen van belanghebbenden te laten blijven voldoen. Het is een component van het waardesysteem, een waardeketenactiviteit in ITIL 4 die verbeteren heet en een practice. Iedereen deelt de verantwoordelijkheid om verbeteringen te herkennen en te ondersteunen.

Het model voor voortdurende verbetering biedt zeven samenhangende stappen. Het kan richting geven aan een kleine verandering in een team, één waardestroom of een organisatiebrede transformatie. Een grote verandering heeft meestal meerdere kleinere iteraties nodig.

Wat je bij elke stap doet

Version 5 behoudt zeven stappen maar noemt stap 6 “Zijn we op weg om het te bereiken?” en stap 7 “Hoe houden we de verbeteringen relevant?” De formulering benadrukt voortdurende voortgang en blijvende bruikbaarheid.

Volg een verbetering van de servicedesk

Visie: medewerkers moeten zonder lange onderbrekingen kunnen werken. Huidige situatie: de servicedesk lost 1.392 van de 2.400 maandelijkse contacten bij het eerste contact op. Het aantal oplossingen gedeeld door het aantal contacten geeft een nulmeting van 58%.

Gewenste situatie: bereik 70% binnen zes maanden. Bij het aantal contacten van de nulmeting zou dit betekenen dat 1.680 contacten bij het eerste contact worden opgelost. De streefwaarde is het aandeel, dus het benodigde aantal verandert als het totale aantal verandert.

Plan: bouw in maandelijkse iteraties een kennisbank voor de 20 meest voorkomende oplossingen. Actie: publiceer de artikelen en train medewerkers om ze te gebruiken.

Controle: na zes maanden worden 1.620 van de 2.500 contacten bij het eerste contact opgelost. Het resultaat is 64,8%: boven 58%, onder 70%. De servicedesk is verbeterd maar heeft de streefwaarde niet gehaald. Bij het nieuwe aantal contacten zou 70% vragen om 1.750 oplossingen bij het eerste contact.

Ga verder: deel de resultaten, houd de artikelen actueel en onderzoek het resterende verschil. Feedback kan het team terugbrengen naar stap 4 om het plan te wijzigen, of naar stap 3 als de streefwaarde moet worden herzien. Een niet-gehaalde streefwaarde geeft informatie voor de volgende beslissing.

Houd het uitgangspunt zichtbaar

Als je de nulmeting overslaat, ontbreekt de vergelijking die nodig is om verandering te beoordelen. Een resultaat van 64,8% toont hier vooruitgang omdat het team vóór de actie 58% heeft gemeten. Beginnen met “koop een nieuw hulpmiddel” loopt ook vooruit: je kiest een oplossing voordat het resultaat en de streefwaarde zijn afgesproken.

De leidende principes ondersteunen de stappen. “Richt je op waarde” geeft richting aan de visie; “begin waar je bent” aan de nulmeting; “werk iteratief met feedback” aan plannen, handelen en controleren. “Werk samen en bevorder zichtbaarheid” betrekt de mensen die gevolgen ondervinden en maakt de voortgang overal zichtbaar.

Een maatstaf is een meting of berekening die wordt gevolgd of gerapporteerd voor beheer en verbetering. Een kritieke prestatie-indicator (KPI) is een belangrijke maatstaf waarmee je de voortgang richting een doelstelling beoordeelt. Een kritieke succesfactor (CSF) geeft aan wat waar moet zijn om de beoogde resultaten te bereiken.

Verbind de doelstelling met gegevens

Begin met de doelstelling, bepaal de CSF’s die nodig zijn om die te bereiken en kies vervolgens voor elke CSF twee of drie betrouwbare KPI’s. Leg vóór de actie een nulmeting vast, stel voor elke KPI een streefwaarde en datum vast en rapporteer resultaten aan de mensen die beslissen wat er verder gebeurt.

Voor de CSF “gebruikers kunnen veelvoorkomende problemen oplossen zonder op een medewerker te wachten” zijn bruikbare KPI’s onder meer het aandeel veelvoorkomende problemen dat via zelfservice wordt opgelost en het aandeel wachtwoorden dat via zelfservice opnieuw wordt ingesteld. Het oplossingspercentage bij het eerste contact meet niet hetzelfde: een medewerker kan een contact oplossen, dus laat dit niet zien of gebruikers zelfstandig een oplossing vinden.

Een maatstaf wordt een KPI door de koppeling met de doelstelling. Niet elk beschikbaar aantal verdient evenveel aandacht. Meting en rapportage, een algemene managementpractice, levert betrouwbare gegevens ter ondersteuning van deze beslissingen.

Kies de juiste noemer

Het aantal oplossingen bij het eerste contact van de servicedesk steeg van 1.392 naar 1.620, een toename van 228. Het aantal contacten steeg echter ook van 2.400 naar 2.500. De aandelen zijn:

De verandering is 6,8 procentpunt. Door zowel het aantal als het percentage te rapporteren, maak je onderscheid tussen de werkdruk en het aandeel dat bij het eerste contact met succes is afgehandeld. Om bij het nieuwe aantal contacten 70% te bereiken, zijn 1.750 oplossingen nodig.

Gebruik een percentage wanneer de doelstelling over een aandeel gaat. Aantallen, tijdsduren en kosten zijn ook geldige KPI-vormen wanneer de doelstelling daarover gaat. Een doelstelling om een wachttijd te verkorten heeft bijvoorbeeld een tijdmaatstaf nodig.

Meet resultaten en onbedoelde effecten

“Aantal gepubliceerde kennisartikelen” meet output. Het aandeel contacten dat bij het eerste contact wordt opgelost en gebruikerstevredenheid staan dichter bij het resultaat dat mensen waarderen. Als je 200 artikelen publiceert die niemand gebruikt, haal je een productieaantal zonder gebruikers te helpen.

Combineer resultaat- of waardemaatstaven met maatstaven voor snelheid en kosten. Eén streefwaarde kan gedrag aanmoedigen dat het cijfer verbetert maar de service schaadt. Als medewerkers alleen worden beoordeeld op het oplossingspercentage bij het eerste contact, sluiten ze contacten mogelijk te vroeg af. Door het aandeel incidenten te volgen dat binnen zeven dagen opnieuw wordt geopend, kun je dat effect zichtbaar maken.

Houd ideeën en verantwoordelijkheid zichtbaar

Een register voor voortdurende verbetering (CIR) is een gestructureerd document of een database die verbeterideeën volgt tot ze zijn afgerond of afgewezen. Registraties bevatten een beschrijving, verantwoordelijke, prioriteit, verwachte baten en status. Een gedeeld register voorkomt dubbel werk en helpt mogelijke baten te vergelijken bij de beslissing wat eerst wordt gedaan.

De besturing houdt toezicht op de prestaties ten opzichte van de strategie. Managers zijn verantwoordelijk voor verbeteringen aan practices en waardestromen. Elk teamlid kan een idee aandragen in het register. Door een verantwoordelijke aan te wijzen blijft duidelijk wie verantwoordelijk is, terwijl ideeën overal uit de organisatie kunnen komen.