Wijzigingsbeheer en releasebeheer in IT-servicemanagement

Een serverlijst vertelt je welke apparatuur bestaat. Om te beoordelen wat er gebeurt als een server verandert, moet je ook weten wat erop draait en wie ervan afhankelijk is. Serviceconfiguratiebeheer maakt betrouwbare informatie over serviceconfiguraties beschikbaar waar en wanneer teams die nodig hebben.

Bepaal wat onder configuratiebeheer moet vallen

Een configuratie-item (CI) is een onderdeel dat moet worden beheerd om een IT-service te leveren. CI’s kunnen fysieke apparatuur, virtuele machines, databases, applicaties, cloudservices, documenten of services zelf zijn. De organisatie kiest welke onderdelen dit beheer nodig hebben. Een serviceniveauovereenkomst kan een CI zijn omdat de overeengekomen inhoud van belang is voor de serviceverlening; een goedkoop reservetoetsenbord heeft meestal geen configuratieregistratie nodig.

Een configuratieregistratie beschrijft één CI. Nuttige velden zijn onder meer de identificatiecode, het type, de versie, de eigenaar, de locatie, de status en de relaties. De identificatiecode voorkomt dat twee vergelijkbare servers worden verward. Met de versie kan een uitrolteam controleren of een geplande update een doel al heeft bereikt.

Volg afhankelijkheden om de impact te beoordelen

Relaties zoals “draait op”, “gebruikt” en “is afhankelijk van” maken van registraties een servicekaart. Let goed op hun richting: een applicatie die een database gebruikt, is afhankelijk van de beschikbaarheid van die database.

Neem de bestelapplicatie WEB-ORD. Die draait op virtuele servers VS-01 en VS-02 en gebruikt DB-ORD. Die database draait op cluster CL-02. Ook de maandelijkse verkooprapportage gebruikt DB-ORD.

Om een upgrade van CL-02 te beoordelen:

1. Zoek de database die op het cluster draait: DB-ORD.
2. Volg de services die die database gebruiken: bestellen en verkooprapportage.
3. Raadpleeg beide service-eigenaren over de impact en kies een tijdstip buiten de drukke besteluren.

Als je alleen de eigenaar van CL-02 raadpleegt, mis je de bovenliggende bedrijfsservices. Dezelfde kaart helpt ondersteuningsmedewerkers een fout op te sporen en beveiligingsmedewerkers systemen te vinden die een patch nodig hebben. Release- en uitrolteams gebruiken configuratieversies om te controleren wat in elke omgeving is geïnstalleerd.

Verbind registraties met het daadwerkelijke werk

Werk betrokken registraties bij als onderdeel van goedgekeurde wijzigingen en uitrol. Anders wordt een correcte servicekaart na de volgende upgrade misleidend. Verificatie en audits vergelijken registraties met de werkelijke omgeving; geautomatiseerde detectie kan helpen verschillen te vinden. Onderzoek een afwijking om te bepalen of de registratie onjuist is of een wijziging zonder goedkeuring is uitgevoerd.

Een configuratiebaseline is een overeengekomen en beoordeelde momentopname van CI’s die als referentie dient voor latere wijzigingen. Die helpt teams een bekende toestand met de huidige toestand te vergelijken.

Verzamel de details die nodig zijn voor echte beslissingen. Elk kenmerk van elk apparaat registreren levert werk op dat mogelijk niet wordt bijgehouden. Een bruikbare verzameling registraties ondersteunt impactcontroles, diagnose en naleving, met duidelijke verantwoordelijkheid voor updates. Een inventaris alleen kan die afhankelijkheden niet tonen.

IT-assets hebben financiële waarde en kunnen bijdragen aan de levering van een IT-product of -service. Het zijn onder meer apparatuur, softwarelicenties en cloudabonnementen. IT-assetmanagement beheert hun volledige levenscyclus om waarde te verkrijgen, kosten en risico’s te beheersen en aan contractuele en wettelijke eisen te voldoen.

Volg de asset gedurende de hele levenscyclus

De levenscyclus begint vóór de aankoop en gaat door nadat de asset niet meer wordt gebruikt:

1. Plannen: stel de behoefte vast en kijk wat al beschikbaar is.
2. Verwerven: koop, lease of sluit een abonnement af.
3. Ontvangen en registreren: leg het item en de eigendom of voorwaarden vast.
4. Uitrollen: wijs het toe aan een gebruiker of locatie.
5. Gebruiken en onderhouden: repareer, verplaats, wijs opnieuw toe of verleng.
6. Buiten gebruik stellen: haal het uit actief gebruik.
7. Afvoeren: wis gegevens of vernietig gegevensdragers en recycle of retourneer apparatuur waar van toepassing.

Werk de registratie bij elke gebeurtenis bij. Een jaarlijkse telling kan die updates controleren, maar niet vervangen. Als een laptop tussen twee tellingen twee keer van gebruiker wisselt, moet de organisatie nog steeds weten wie die nu heeft.

Een assetregister legt informatie vast zoals assetlabel, model, serienummer, eigenaar of gebruiker, locatie, aankoopdatum en kosten, einddatum van garantie of lease, licentievoorwaarden en status. De status onderscheidt een item “op voorraad” van een item “in gebruik” of “buiten gebruik gesteld”.

Stem softwarerechten af op gebruik

Softwareassetmanagement vergelijkt gebruiksrechten met daadwerkelijke installatie of daadwerkelijk gebruik. Te weinig licenties kopen levert een risico op dat de organisatie niet aan de voorwaarden voldoet; ongebruikte licenties behouden verspilt geld. Controleer de licentievoorwaarden voordat je abonnementen opnieuw toewijst of vermindert.

Een bedrijf betaalt voor 500 abonnementen op een kantoorpakket € 120 per gebruiker per jaar. Het heeft er 430 toegewezen, zodat er 70 ongebruikt blijven. Hun jaarlijkse kosten in euro’s zijn:

Veertig nieuwe medewerkers hebben het pakket nodig. Door 40 ongebruikte abonnementen opnieuw toe te wijzen, hoeft het bedrijf er geen 40 bij te kopen en voorkomt het € 4.800 aan extra jaarlijkse uitgaven. Dertig blijven ongebruikt; die bij verlenging beëindigen bespaart € 3.600 per jaar. Dit zijn verschillende baten: voorkomen dat nieuwe uitgaven ontstaan en bestaande uitgaven verminderen.

Cloudaccounts horen in hetzelfde financiële overzicht. Een niet-gemeld abonnement van een afdeling kan zowel aan controle op verlenging als aan beveiligingsbeoordeling ontsnappen. Deze schaduw-IT moet zichtbaar zijn, ook al is er geen fysiek apparaat om te tellen.

Onderscheid financiële vragen van configuratievragen

Dezelfde tool kan beide registraties bevatten, maar de doelen verschillen. De doorverkoopwaarde is niet het criterium voor een IT-asset: een cloudabonnement kan financiële waarde hebben zonder te worden doorverkocht.

Buitengebruikstelling is niet hetzelfde als volledige afvoer. Wis gegevens veilig of vernietig de gegevensdrager voordat apparatuur de organisatie verlaat en registreer de handeling. Stuur elektronisch afval naar erkende recyclers en geef geleasete apparaten terug aan de leasemaatschappij. De assetregistratie moet laten zien wat er met het item is gebeurd en wanneer.

Een ondersteuningsprocedure wijzigen kan net zo goed invloed hebben op een service als een server wijzigen. Een wijziging is een toevoeging, aanpassing of verwijdering van iets dat direct of indirect invloed kan hebben op services. Daaronder vallen apparatuur, applicaties, documenten, processen en leveranciersafspraken binnen de door de organisatie gekozen reikwijdte.

Maak nuttige wijzigingen mogelijk

Wijzigingsbeheer heeft als doel het aantal succesvolle wijzigingen van services en producten te maximaliseren. Het doet dit via drie samenhangende verantwoordelijkheden:

• Beoordeel de risico’s goed.
• Geef toestemming om wijzigingen uit te voeren.
• Beheer de wijzigingskalender.

Het doel is een succesvolle wijziging, met bescherming die past bij het risico. Gebruikers hebben verbeteringen en oplossingen snel nodig. Ze hebben ook nodig dat bestaande services blijven werken. Een trage goedkeuringsroute voor elke kleine taak verspilt tijd en kan teams ertoe aanzetten die te omzeilen. Als elk team zonder afstemming gedeelde systemen mag wijzigen, worden gebruikers blootgesteld aan vermijdbare storingen.

Een applicatie vervangen kan bijvoorbeeld nieuwe functies opleveren, maar ook bestaand werk onderbreken. Een oude database verwijderen is ook een wijziging: een andere service gebruikt de gegevens mogelijk nog. Zelfs een documentaanpassing valt binnen de reikwijdte als die verandert hoe medewerkers ondersteuning leveren. De relevante vraag is welk effect er op services mogelijk is, niet of iemand nieuwe code schrijft.

Beoordeel succes aan de hand van het resultaat

Een succesvolle wijziging wordt volgens plan geïmplementeerd, levert het beoogde resultaat op en veroorzaakt geen ongeplande schade zoals incidenten. “De installatie is voltooid” voldoet maar aan een deel van die toets. Gebruikers kunnen mogelijk nog steeds niet de taak uitvoeren die de wijziging moest verbeteren.

Stel dat in een kwartaal 240 wijzigingen zijn geïmplementeerd en dat er 12 zijn mislukt of teruggedraaid. Het aantal succesvolle wijzigingen is 228. Bereken het percentage met alle geïmplementeerde wijzigingen als noemer:

Het faalpercentage van 5% is het complement van het succespercentage van 95%. Door zowel het aantal als het percentage bij te houden, ziet een team de omvang van het werk. Een hoog succespercentage moet worden bekeken naast de snelheid waarmee waardevolle wijzigingen gebruikers bereiken; door nuttig werk tegen te houden kunnen er weinig mislukkingen zijn, terwijl aan weinig behoeften wordt voldaan.

Herken namen en bronnen van wijzigingen

ITIL 4 gebruikt change enablement, net als ITIL (Version 5). Eerder materiaal kan “change control” of “change management” gebruiken. Organisatieverandermanagement is een afzonderlijke practice die zich bezighoudt met het overnemen van nieuwe werkwijzen door mensen, waaronder communicatie en training.

Wijzigingsverzoeken kunnen beginnen bij oplossingen voor problemen, urgente incidenten, beveiligingsupdates, leveranciersupdates, nieuwe functies of verbeterideeën. Hun oorsprong neemt de noodzaak om ze te beoordelen, goed te keuren en af te stemmen niet weg. Ook een patch van een leverancier heeft een passende wijzigingsroute nodig; ook bij een kleine procesverbetering verdient het effect op gebruikers aandacht.

Organisaties bepalen de reikwijdte en beslisroutes die bij hun services passen. Een bruikbare route maakt zichtbaar wie de beslissing neemt, geeft mensen genoeg informatie om risico’s te beoordelen en laat het team het werk op een geschikt moment uitvoeren.

De route van een wijziging hangt af van hoe die wordt beoordeeld en goedgekeurd. De technische omvang alleen bepaalt niet of de wijziging standaard, normaal of spoed is. Een routeraanpassing van één regel kan een groter risico meebrengen dan een grote, beproefde software-installatie.

Kies de passende route

Het risico van een standaardprocedure wordt beoordeeld wanneer die wordt opgesteld en wanneer die wordt aangepast. De vooraf verleende goedkeuring geldt voor die overeengekomen procedure. Een team kan een onbekende taak niet standaard noemen alleen omdat het verwacht dat die eenvoudig is.

Normaal betekent niet een gemiddeld risico. Een normale wijziging met een laag risico vereist mogelijk alleen een snelle goedkeuring door een collega of geautomatiseerde controles. Een grote normale wijziging kan goedkeuring van het hoger management vereisen. Wijzigingsmodellen bepalen deze routes, zodat teams weten welke informatie en autoriteit elk soort wijziging nodig heeft.

Schrijf een bruikbaar wijzigingsverzoek

Een normale wijziging begint meestal met een wijzigingsverzoek, ook wel RFC genoemd. Geef de beslisser de informatie die nodig is om het verzoek te beoordelen:

• Wat er verandert, waarom en wat de verwachte baten zijn.
• Betrokken services en CI’s, met risico en impact.
• Implementatie- en testplannen.
• Een herstelplan om de service te herstellen als de wijziging mislukt.
• Voorgestelde datum en tijd.

Bij een databaseverplaatsing verklaart “de nieuwe opslag is sneller” een verwachte baat, maar kan de autoriteit niet beoordelen wie kan worden getroffen of hoe het team zou herstellen.

Ga om met echte urgentie zonder de controle te verliezen

Beoordeling en goedkeuring bij spoed verlopen sneller, vaak via een kleinere autoriteit. Test zo volledig als de tijd toelaat. Sommige documentatie kan achteraf worden afgerond, maar door de urgentie wordt het werk geen wijziging zonder goedkeuring. Een niet-geteste reparatie kan een nieuw incident veroorzaken.

Als een manager vandaag een functie wil, maakt dat het verzoek nog geen spoedwijziging. Directe bedreigingen voor een service of de beveiliging rechtvaardigen de versnelde route. In een kwartaal met 18 spoedwijzigingen op 240 wijzigingen is het aandeel:

Volg dit over langere tijd. Regelmatig urgent werk kan planningsproblemen blootleggen die verbetering verdienen.

Een herhaalde normale wijziging kan standaard worden nadat het team de beproefde procedure heeft gedocumenteerd, het risico heeft beoordeeld en goedkeuring heeft verkregen. Maandelijkse patches voor niet-kritieke testservers kunnen hiervoor in aanmerking komen. Herhaling alleen levert ervaring op, geen voorafgaande goedkeuring. Een firewallaanpassing voor een nieuwe partner blijft normaal, tenzij een goedgekeurde standaardprocedure precies dat soort aanpassing dekt.

Een goedkeuring is nuttig als de persoon die goedkeuring verleent het risico begrijpt en tijdig een beslissing kan nemen. Een wijzigingsautoriteit is de persoon of groep die een wijziging goedkeurt. Wijs de autoriteit toe op basis van het soort werk en het risico, en houd routinebeslissingen dicht bij de mensen die het werk uitvoeren.

Beoordeel kans en impact afzonderlijk

Kans gaat over de faalkans: complexiteit, tests en de ervaring van het team zijn van belang. Impact gaat over de gevolgen: getroffen services en gebruikers, gegevensverlies, ernst en hersteltijd. Gebruik configuratierelaties om services te vinden die afhankelijk zijn van het gewijzigde onderdeel.

Een organisatie kan impact en kans, elk beoordeeld van 1 tot 5, vermenigvuldigen. In dit voorbeeld koppelt ze scores 1–5 aan goedkeuring door een collega, 6–12 aan een wijzigingsmanager en 13–25 aan een autoriteit op hoog niveau of CAB. Dit zijn lokale drempelwaarden.

Een wijzigingsadviescommissie (CAB) adviseert over belangrijke wijzigingen. Die hoeft niet elke wijziging goed te keuren. Beoordeling door collega’s en geautomatiseerde controles kunnen goedgekeurde routes bieden voor geschikt werk met een laag risico.

Plan herstel vóór implementatie

Elke normale wijziging heeft een herstelplan nodig dat aangeeft hoe de service wordt hersteld en wanneer het herstel begint. Terugdraaien, ook wel terugzetten genoemd, brengt de situatie terug naar de vorige toestand. Een gecorrigeerde wijziging doorvoeren verhelpt het probleem; een andere mogelijkheid is overschakelen op een alternatieve service.

Een geteste herstelroute kan de gevolgen van falen beperken. Een wijziging zonder getest herstel brengt meer risico mee en verdient een beslissing op hoger niveau. Alleen “terugdraaien indien nodig” opschrijven laat het team achter zonder een aanleiding, verantwoordelijke of praktische volgorde.

Stem de wijzigingskalender af

De kalender ondersteunt planning, communicatie, conflictcontroles en toewijzing van middelen. Ook helpt die incident- en probleemteams recente wijzigingen te zien die een fout kunnen verklaren. Organisaties kunnen perioden vaststellen waarin wijzigingen zijn bevroren, zoals tijdens een facturatieronde, met uitzonderingen voor spoed.

Stel dat een switchvervanging en een applicatie-upgrade allebei gepland staan op zaterdag van 22.00 tot 02.00 uur. De servers van de applicatie zijn afhankelijk van de switch. Door de uitval kan de applicatie niet worden getest en zijn storingen moeilijk op te sporen. Verplaats de applicatie-upgrade naar zondag 22.00 uur en vertel de servicedesk over beide tijdvakken.

Evalueer wat er werkelijk is gebeurd

Controleer na implementatie het doel, incidenten en onbedoelde effecten voordat je de registratie afsluit. Evalueer mislukkingen om ervan te leren. Nuttige maatstaven zijn onder meer het succespercentage, wijzigingen die incidenten veroorzaken, het aandeel spoedwijzigingen en de tijd van verzoek tot implementatie.

Een functie kan in productie zijn geïnstalleerd terwijl gebruikers er nog geen toegang toe hebben. Releasebeheer stelt nieuwe en gewijzigde services en functies beschikbaar voor gebruik. Het plant de gereedheid en communicatie en bepaalt ook het moment waarop gebruikers toegang krijgen.

Bepaal wat de release bevat

Een release is een versie van een service of ander CI, of een verzameling CI’s, die voor gebruik beschikbaar wordt gesteld. Een release kan applicatiecode, infrastructuur, documentatie, bijgewerkte procedures, training en kennisartikelen bevatten. Als ondersteuningsmedewerkers gebruikers niet met de functie kunnen helpen, is technische gereedheid alleen onvoldoende.

De releaseplanning bepaalt de reikwijdte, timing en gereedheidscriteria. Eis bijvoorbeeld dat tests slagen, ondersteuningsmedewerkers zijn geïnformeerd, de gebruikershandleiding is bijgewerkt en het terugdraaien is getest. Aan de hand van deze criteria kan het team op basis van bewijs bepalen of alles gereed is voordat de toegang wordt uitgebreid.

Versieaanduidingen onderscheiden wat beschikbaar is. In een gangbaar schema met hoofdversie, minorversie en patchversie duidt de overgang van 4.2.0 naar 4.3.0 op een kleinere functierelease; 5.0.0 duidt op een grote. Teams spreken hun nummeringsconventie af zodat releaseopmerkingen, ondersteuningsregistraties en geïnstalleerde versies naar hetzelfde verwijzen.

Scheid uitrol van toegang

Uitrol brengt componenten naar een omgeving. Een release stelt ze beschikbaar voor gebruik. Een functieschakelaar kan uitgerolde code inactief laten en daarna voor geselecteerde gebruikers inschakelen.

Neem een bankapp die pdf-afschriften toevoegt:

1. Rol op dinsdag versie 3.4 uit naar de productieservers met de functie uitgeschakeld. De code is aanwezig, maar klanten kunnen de nieuwe functie niet gebruiken.
2. Geef de functie op donderdag vrij voor 10% van de gebruikers. Bewaak het percentage sessies waarin de app vastloopt aan de hand van de teamgrens van 0,5%.
3. Het percentage blijft onder die grens, dus geef de functie op maandag vrij voor alle gebruikers.

De uitrolgrens hoort bij het releaseplan van dit team. Het is geen universele releasedrempel. Beheerste toegang levert feedback op voordat de functie alle gebruikers bereikt.

Stem de planning af op het opleverritme

Frequente oplevering verandert hoe het werk is georganiseerd. Regels en geautomatiseerde controles kunnen snelle beslissingen ondersteunen, terwijl een team nog steeds bepaalt wie welke functie wanneer krijgt.

Releaseopmerkingen leggen in duidelijke woorden uit wat is veranderd, wat is opgelost en welke bekende problemen er zijn. Voor de bankapp: “Je kunt maandoverzichten als pdf downloaden. Overzichten ouder dan 24 maanden zijn nog niet beschikbaar.” Geef de servicedesk deze informatie voordat gebruikers er vragen over gaan stellen.

Verzamel na de release gebruikersfeedback, incidenten en prestatiegegevens. Gebruik de lessen voor voortdurende verbetering. Op een uitrolknop drukken voert dit werk rond gereedheid, toegang, communicatie en evaluatie niet uit.

Uitrolbeheer brengt nieuwe of gewijzigde componenten naar productieomgevingen en kan ze ook naar andere omgevingen brengen om te testen. Componenten zijn onder meer hardware, software, documenten en processen. De practice beheerst wat elke doelomgeving bereikt en controleert of het daar werkt.

Weet waar de component naartoe gaat

Een geslaagde test in de voorproductieomgeving levert bewijs voor de overgang naar productie. Na de overgang controleren snelle functionele tests en monitoring het daadwerkelijke resultaat in productie. Werk configuratieregistraties bij zodat ze de geïnstalleerde versie en gewijzigde relaties tonen.

Kies een aanpak die bij de service past

Gefaseerde uitrol brengt componenten steeds naar één deel van de productieomgeving. Dat beperkt de eerste blootstelling en levert feedback op vóór de volgende ronde. Een team dat 2.000 laptops bijwerkt, kiest vier rondes van 500 en begint met IT-medewerkers die problemen duidelijk kunnen melden.

Het team pauzeert als uitrolgerelateerde incidenten meer dan 2% van de laptops in een ronde treffen. In de eerste ronde treffen incidenten 25 verschillende laptops:

Vijf procent overschrijdt de grens van het team. Daarom pauzeert het team, onderzoekt en verhelpt het de oorzaak en test het opnieuw vóór ronde 2. De noemer is de uitgerolde ronde, niet alle 2.000 laptops. Tel getroffen apparaten, want meerdere incidentmeldingen kunnen over hetzelfde apparaat gaan.

Integrale uitrol brengt componenten tegelijk naar alle bestemmingen. Die aanpak past bij één duidelijke omschakeling wanneer oude en nieuwe versies niet naast elkaar kunnen bestaan. Zo krijgen alle 120 winkels in dezelfde nacht nieuwe kassasoftware omdat beide versies het centrale systeem niet kunnen delen. Een storing kan elke winkel treffen, dus test grondig en oefen het herstel.

Uitrol op initiatief van de gebruiker plaatst goedgekeurde software in een beheerde opslagplaats, zodat gebruikers die kunnen installeren wanneer ze willen. Een organisatie kan een update voor videobellen in haar softwareportaal publiceren en een uiterste datum vaststellen voordat de oude versie niet meer werkt.

Continue levering integreert, test en rolt componenten uit wanneer dat nodig is en ondersteunt regelmatige feedback. Ook bij geautomatiseerd overbrengen zijn beheerde bronnen, goedkeuring, validatie en actuele registraties nodig.

Beheers de bron en het herstel

Bewaar componenten die klaar zijn voor uitrol op veilige, beheerde locaties, zoals een definitieve bibliotheek of een opslagplaats voor bouwresultaten. Teams moeten steeds de goedgekeurde, geteste versie ophalen in plaats van op een niet-geverifieerde lokale kopie te vertrouwen.

Voer uitrol uit onder een goedgekeurde wijziging. Zorg dat een herstelplan gereed is voordat je componenten overbrengt. Controleer het resultaat direct en onderneem actie als controles mislukken. Een geïnstalleerde versie kan inactief blijven totdat releasebeheer de functie voor gebruikers beschikbaar maakt; een afgeronde uitrol betekent niet automatisch dat de release heeft plaatsgevonden.

Eén oplevering doet een beroep op verschillende practices omdat elke practice een ander probleem oplost. Door ze op elkaar af te stemmen voorkom je een kloof tussen een goedgekeurde technische taak en een functie die mensen met succes kunnen gebruiken.

Stel de vraag die elke practice beantwoordt

Deze verantwoordelijkheden kunnen door hetzelfde team worden uitgevoerd. Ze vereisen nog steeds afzonderlijke beslissingen en registraties. Een agile team kan beoordeling door collega’s, geautomatiseerde controles en vastgelegde beslissingen combineren zonder elke oplevering naar een vergadering te sturen.

Volg een portaalfunctie tijdens de oplevering

Via een HR-portaal kunnen medewerkers straks declaratiebewijzen uploaden. Het wijzigingsverzoek beschrijft de baten, betrokken CI’s, implementatie, tests en herstel. Volgens het risicomodel van de organisatie leveren impact 3 en kans 2 een score van 6 op. De wijzigingsmanager keurt een normale wijziging goed voor woensdag van 20.00 tot 22.00 uur, na controle op conflicten rond het portaal.

Het team test versie 2.8 in de voorproductieomgeving en rolt die tijdens dat tijdvak uit naar de productieservers. De uploadfunctie blijft uitgeschakeld. Configuratieregistraties tonen nu versie 2.8. Toegevoegde abonnementen of apparatuur hebben ook assetregistraties en een verantwoordelijke voor hun levenscyclus nodig.

Op vrijdag stelt releasebeheer de functie beschikbaar aan 150 medewerkers van de financiële afdeling. De servicedesk heeft vooraf releaseopmerkingen en een korte handleiding ontvangen. Een week later wordt de toegang uitgebreid naar alle 2.400 medewerkers. Installatie en beschikbaarheid voor gebruikers vinden op verschillende datums plaats. Een vraag of de functie “in productie” is, vereist dus een precies antwoord over welke gebeurtenis wordt bedoeld.

Evalueer resultaten en geef lessen door

Tijdens de eerste week vragen drie mensen hoe ze de uploadfunctie gebruiken. De service werkt normaal: dit zijn adviesverzoeken, geen incidenten. De evaluatie controleert of declaratiebewijzen zoals bedoeld kunnen worden geüpload en stelt vast dat er geen onderbreking of verslechtering is. De wijziging kan als succesvol worden afgesloten, met het verbeteridee om een tip in de app toe te voegen.

Eén release kan meerdere uitrolmomenten vereisen, zoals rondes naar verschillende bestemmingen. Eén uitrol kan meerdere functies bevatten die met functieschakelaars op verschillende momenten worden vrijgegeven. Er is geen verplichte één-op-éénrelatie tussen een wijziging, een uitrol en een release.

Verbind het werk met waardelevering

In ITIL 4 dragen deze practices vooral bij aan de activiteiten ontwerpen en in productie nemen, verwerven/bouwen en leveren en ondersteunen. ITIL (Version 5) beschrijft acht activiteiten in de product- en servicelevenscyclus: verkennen, ontwerpen, verwerven, bouwen, in productie nemen, beheren, leveren en ondersteunen. Bouwen en in productie nemen staan centraal bij het voorbereiden en invoeren van gewijzigde componenten. Bij de oplevering is nog steeds bewijs nodig dat het beoogde serviceresultaat de gebruikers heeft bereikt.

Informatiebeveiligingsmanagement beschermt de informatie die een organisatie nodig heeft voor haar werk door risico’s te begrijpen en te beheersen. Het geldt voor de mensen, procedures, leveranciers en technologie die met die informatie omgaan. Het beveiligingsteam coördineert specialistisch werk, maar iedereen heeft een rol.

Bepaal wat bescherming nodig heeft

De eerste drie worden vaak samen aangeduid als CIA. Een service kan vertrouwelijkheid beschermen maar tekortschieten in beschikbaarheid als gebruikers de service niet kunnen bereiken. Authenticatie controleert wie iemand is; die controle bepaalt op zichzelf niet waartoe die persoon toegang mag hebben. Onweerlegbaarheid gaat over bewijs van een handeling, los van het inloggen.

Breng preventie, detectie en correctie in balans

Preventie verkleint de kans op incidenten. Voorbeelden zijn patches installeren, toegangscontroles, firewalls en bewustwordingstraining. Detectie vindt incidenten die toch plaatsvinden, met monitoring, waarschuwingen en controle van logboeken. Correctie beperkt schade en herstelt de normale werking met isolatie, herstel en oplossingen.

Bij ransomware werkt een evenwichtige aanpak in deze fasen:

1. Installeer tijdig patches, filter schadelijke e-mail, verplicht inloggen met meerdere factoren en geef accounts alleen de toegang die nodig is.
2. Geef een waarschuwing als software onverwacht veel bestanden begint te versleutelen.
3. Isoleer besmette computers, herstel vanuit offline back-ups en zoek en verhelp de toegangsroute.

Back-ups ondersteunen herstel; ze vervangen geen maatregelen die aanvallen voorkomen of vroegtijdig detecteren. Kies maatregelen in verhouding tot de waarde van informatie, bedreigingen en kwetsbaarheden. Maatregelen die gewoon werk onnodig moeilijk maken, kunnen onofficiële tijdelijke oplossingen aanmoedigen.

Neem beveiliging op in dagelijkse practices

Een beveiligingsbeleid, vastgelegde rollen en regelmatige training sturen het dagelijkse gedrag. Trek de toegang van een vertrekkende medewerker op de laatste werkdag in. ISO/IEC 27001 stelt eisen aan een managementsysteem voor informatiebeveiliging; organisaties kunnen zich volgens deze norm laten certificeren.

Configuratie-informatie helpt getroffen systemen vinden: een kwetsbare bibliotheek op 37 van de 400 servers geeft aan waar de patch nodig is. Routinepatches volgen standaard- of normale wijzigingsroutes. Een actieve dreiging die onmiddellijke actie vereist, krijgt een spoedbeoordeling en -goedkeuring. Assetmanagement beveiligt gegevens vóór afvoer, terwijl leveranciersmanagement beveiligingseisen stelt en de toegang van leveranciers beheerst.

Het werk van een leverancier wordt onderdeel van de service die klanten ervaren. Leveranciersmanagement beheert leveranciers, relaties, afspraken en prestaties, zodat kwaliteitsproducten en -services soepel op elkaar aansluiten. Leveranciers kunnen externe bedrijven of interne afdelingen zijn.

Kies hoe je het werk laat uitvoeren

Deze strategieën beschrijven verschillende aspecten van sourcing: een organisatie kan uitbesteden aan één partner of aan meerdere leveranciers. Kies op basis van cultuur, schaarste aan vaardigheden, expertise, totale kosten, externe beperkingen en voorspelbaarheid van de vraag. Achter de laagste offerteprijs kunnen afstemmingswerk of een gebrekkige servicekwaliteit schuilgaan.

Maak verwachtingen meetbaar

Houd zicht op leveranciers, strategie, beleid en contractinformatie. Spreek servicestreefwaarden, reactietijden, beveiligings- en gegevenseisen, rapportage, prijzen en compensaties zoals servicevergoedingen af. Neem ook afspraken op over geschillen en beëindiging, vooral over de teruggave van gegevens.

Contracten vormen het begin van doorlopend beheer. Volg prestaties, evalueer relaties en plan verlengingen en beëindigingen. Een strategische cloudleverancier heeft gezamenlijke planning en regelmatige evaluaties nodig; een kabelleverancier kan meestal via standaardinkoopvoorwaarden worden beheerd.

Controleer prestaties aan de hand van de overeenkomst

Stel dat een hostingcontract 99,9% beschikbaarheid belooft over een volledige maand van 30 dagen. De meetperiode bevat:

De toegestane uitval is 0,1% van die periode, ofwel 43,2 minuten. De werkelijke uitval is 95 minuten. De beschikbaarheid is:

De streefwaarde is niet gehaald. Pas de servicevergoeding uit het contract toe en spreek tijdens de leveranciersevaluatie een verbeterplan af. Een klein ogend verschil tussen percentages kan toch een aanzienlijke extra uitval betekenen. Gebruik bij de beoordeling van prestaties de afgesproken meetperiode en contractregels.

Behoud verantwoordelijkheid en beheers afhankelijkheid

De organisatie blijft tegenover haar eigen klanten eindverantwoordelijk, ook als een leverancier een deel van de service levert. Een leveranciersvergoeding volgt uit een afspraak; die herstelt het onderbroken werk van een klant niet. Teams hebben ook een afgestemde reactie en verbeteracties nodig.

Goede relaties ondersteunen eerlijke rapportage en gezamenlijke resultaten. Beheers leveranciersafhankelijkheid, de moeilijkheid om bij één leverancier weg te gaan, met overdraagbare gegevens en een getest uitstapplan. Maak bij meerdere leveranciers verantwoordelijkheden en overdrachten duidelijk, zodat een fout binnen de hele service wordt opgelost in plaats van tussen contracten te worden doorgeschoven.

Servicebehoeften veranderen als gebruikers, technologie en organisaties veranderen. Voortdurende verbetering houdt services en practices afgestemd op die behoeften door producten, services, practices en het beheer ervan doorlopend te verbeteren. Een duidelijker formulier kan voor één team evenveel betekenen als een nieuw platform voor de organisatie.

Geef dagelijkse ideeën een route naar actie

Iedereen is verantwoordelijk voor verbetering. Een toegewijd team kan het werk coördineren, mensen coachen en resultaten volgen. Leidinggevenden zorgen voor tijd en budget. Medewerkers die het werk uitvoeren, signaleren moeilijkheden en testen betere manieren om daarmee om te gaan.

Verbeteractiviteiten omvatten mogelijkheden vinden, registreren, beoordelen en prioriteren, zakelijke onderbouwingen opstellen, acties plannen en uitvoeren en resultaten evalueren. Afstemming helpt teams concurrerende inspanningen of wijzigingen te voorkomen die een probleem elders veroorzaken.

Ideeën kunnen komen uit trends in incidenten en problemen, klantfeedback, tevredenheidsonderzoeken, suggesties van medewerkers, audits, nieuwe technologie, leveranciersevaluaties en evaluaties van wijzigingen of releases. Een ondersteuningsteam dat na releases herhaaldelijk verwarring opmerkt, heeft bruikbaar bewijs voor verbetering, ook als er geen grote uitval is geweest.

Houd een register voor voortdurende verbetering bij

Een register voor voortdurende verbetering (CIR) is een gestructureerd document of een database waarin ideeën vanaf identificatie tot en met de uiteindelijke actie worden gevolgd. Leg het idee, de bron, verwachte baten, geschatte inspanning, prioriteit, verantwoordelijke en status vast. Een verantwoordelijke zorgt ervoor dat iemand verantwoordelijk is voor de volgende beslissing over een bruikbaar idee.

Een organisatie kan registers bijhouden op team- en organisatieniveau. Het belangrijkste werk is ideeën door beoordeling en actie heen beheren. Een lange lijst zonder verantwoordelijken of statusupdates helpt weinig bij de keuze wat er daarna gebeurt.

Vergelijk baten en inspanning

Een team scoort baten en inspanning van 1 tot 10 en gebruikt baten per eenheid inspanning als hulpmiddel bij de prioritering:

Begin volgens deze maatstaf met C, dan A en dan B. De hoogste totale baten zijn niet hetzelfde als de hoogste baten per eenheid inspanning. Houd B in het register zodat de waarde en benodigde middelen opnieuw kunnen worden bekeken. Een verhouding helpt werk te vergelijken; bij prioritering blijft aandacht nodig voor doelen en beperkingen van de organisatie.

Verbind verbetering met het servicesysteem

ITIL 4 plaatst voortdurende verbetering in het servicewaardesysteem, in de activiteit “verbeteren” van de waardeketen en bij de managementpractices. ITIL (Version 5) behoudt voortdurende verbetering als onderdeel van het ITIL-waardesysteem en als practice.

Verbetering brengt “Begin waar je bent”, “Richt je op waarde” en “Werk iteratief met feedback” in het dagelijkse werk. Begin met bewijs van het huidige probleem, kies een actie met een nuttig resultaat en gebruik feedback om de volgende actie te bepalen. Kleine, regelmatige stappen van de mensen die het werk uitvoeren horen hier naast grotere initiatieven.

Een hulpmiddel kopen of een procedure herschrijven is een actie. Om verbetering vast te stellen, verbind je die actie met een gewenst resultaat en meet je wat er is veranderd. Het model voor voortdurende verbetering biedt zeven stappen voor dit werk op elke schaal.

Bepaal de richting en begrijp het uitgangspunt

1. Wat is de visie? Verbind het werk met organisatiedoelen en leg uit welke baten belanghebbenden nodig hebben.
2. Waar staan we nu? Beoordeel de huidige situatie objectief en maak een nulmeting voor vergelijking.
3. Waar willen we zijn? Vergelijk de huidige en gewenste situatie en stel specifieke, meetbare en tijdgebonden streefwaarden vast.

Een visie zoals “gebruikers kunnen snel weer aan het werk” geeft richting. Een streefwaarde zoals “bereik binnen zes maanden 70% oplossingen bij het eerste contact” maakt een deel van die richting meetbaar. “Snellere ondersteuning” alleen geeft geen vastgesteld resultaat of deadline.

Een nulmeting legt de uitgangssituatie vast. Gebruik een duidelijke meetdefinitie zodat het latere resultaat zinvol kan worden vergeleken. Als je in de twee perioden verschillende soorten contacten telt, kan een schijnbare verandering moeilijk te duiden zijn.

Plan, handel, controleer en houd vast

4. Hoe komen we daar? Kies een plan en gebruik iteraties als de beste route onzeker is.
5. Onderneem actie. Voer het plan uit en let daarbij op risico’s en neveneffecten.
6. Zijn we daar gekomen? Meet opnieuw en vergelijk het resultaat met zowel de nulmeting als de streefwaarde. Pas eerdere stappen zo nodig aan.
7. Hoe houden we het momentum vast? Deel resultaten, veranker de betere werkwijze en ga door met verbeteren.

Deze vragen ondersteunen een kringloop. Je hoeft niet te wachten tot een groot project is afgerond om van feedback te leren. Een mislukte iteratie kan laten zien wat je vervolgens moet veranderen.

Werk een verbetering van de servicedesk uit

Een servicedesk lost 696 van de 1.200 maandelijkse contacten bij het eerste contact op. De nulmeting is:

Het team stelt als streefwaarde 70% binnen zes maanden. Het plant betere kennisartikelen en hulpmiddelen voor toegang op afstand en voert die vervolgens in. Na drie maanden worden 736 van de 1.150 contacten bij het eerste contact opgelost:

Vergelijk percentages omdat het totale aantal contacten is veranderd. Vierenzestig procent ligt boven de nulmeting maar onder de streefwaarde. Ga terug naar de planning, onderzoek welke contactsoorten nog worden doorgezet en voeg gerichte training toe. Er is vooruitgang, maar het team kan niet melden dat de streefwaarde is bereikt.

Behoud na het bereiken van een nuttig resultaat de verantwoordelijkheid voor artikelen, train nieuwe medewerkers en deel bewijs van het resultaat. Zo voorkom je dat de service terugvalt wanneer het oorspronkelijke verbeterteam verdergaat.

Herken de formulering van Version 5

ITIL (Version 5) behoudt zeven stappen. Stap 6 vraagt “Komen we er?” en stap 7 vraagt “Hoe houden we de verbeteringen relevant?” De formulering benadrukt doorlopende controles van de voortgang en blijvende relevantie. De nulmeting, streefwaarde, actie en feedback blijven essentieel voor het gebruik van het model.

Een bruikbare maatstaf laat zien of de service iets bereikt wat mensen nodig hebben. Alleen activiteiten tellen kan een druk team succesvol doen lijken terwijl gebruikers ontevreden blijven. Kies maatstaven die het werk verbinden met beoogde resultaten.

Verbind succesvoorwaarden met indicatoren

Een kritieke succesfactor (CSF) is een voorwaarde waaraan moet worden voldaan om het beoogde resultaat te bereiken. Een kritieke prestatie-indicator (KPI) meet of aan een CSF wordt voldaan. Voor de CSF “gebruikers krijgen hun problemen snel opgelost” zijn mogelijke KPI’s het oplossingspercentage bij het eerste contact en de gemiddelde oplostijd van incidenten.

Breng indicatoren in balans zodat één streefwaarde geen schadelijk gedrag beloont. Als medewerkers alleen op oplostijd worden beoordeeld, laat het te vroeg afsluiten van meldingen de cijfers beter lijken. Combineer die maatstaf met het percentage heropende meldingen en gebruikersfeedback om te controleren of de problemen echt zijn opgelost.

Wanneer technische rapportages groen zijn maar gebruikers een slechte ervaring hebben, wordt die discrepantie soms het watermeloeneffect genoemd. Maatstaven voor tevredenheid en klachten helpen zichtbaar te maken wat technische indicatoren missen.

Vergelijk percentages nauwkeurig

Een stijging van 58% naar 64% is 6 procentpunten. De relatieve stijging vergelijkt dat verschil met het uitgangspercentage:

Geef aan welke vergelijking je bedoelt. Als je voor deze verandering “6% verbetering” rapporteert, haal je het verschil in procentpunten en de relatieve verandering door elkaar. Gebruik consistente populaties, meetdefinities en perioden wanneer je resultaten vergelijkt.

Tel bij het combineren van groepen de aantallen successen en de totale aantallen op voordat je het totale percentage berekent. Een webkanaal lost 90 van de 150 contacten op en een telefoonkanaal 20 van de 50. Samen lossen ze 110 van de 200 op, ofwel 55%. Als je hun percentages van 60% en 40% even zwaar zou middelen, krijg je 50%, maar de webgroep heeft drie keer zoveel contacten.

Kies een techniek bij de vraag

Een volwassenheidsschaal kan lopen van 1, initieel, tot 5, geoptimaliseerd; gebruik de schaal die de beoordeling vaststelt. Een hogere beoordeling van een practice en een beter klantresultaat zijn verschillende maatstaven en vereisen elk eigen bewijs.

Een normale wijziging duurt 6 dagen van verzoek tot implementatie. Vijf dagen worden besteed aan wachten op een wekelijkse goedkeuringsvergadering. Wachten vormt:

Lean vestigt de aandacht op die wachttijd. Een passende route voor goedkeuring door collega’s bij werk met een laag risico kan de vertraging verminderen en tegelijk de goedkeuring behouden. Als je een korte implementatietaak versnelt, blijft het grootste deel van de doorlooptijd onaangeroerd.

Agile ondersteunt kleine stappen en regelmatige feedback. DevOps verbindt ontwikkeling en operationeel beheer met automatisering voor snelle, veilige oplevering. Beide passen bij iteratieve verbetering. Als een verbetering een service, hulpmiddel of proces verandert, laat je die via wijzigingsbeheer en waar nodig via uitrol en release lopen. Meet het effect ten opzichte van de nulmeting.