Verandermanagement (ITIL)

Achtergrond

Een hoge mate van kostbare verstoring van de IT-service kan vaak worden teruggevoerd op slecht gecoördineerde of onderbeheersde wijzigingen in het IT-servicelandschap. Deze verstoringen kunnen enorme kosten met zich meebrengen vanwege de huidige afhankelijkheid van bedrijfsprocessen op IT. Dit rechtvaardigt investeren in IT-processen, waarbij elke verandering in vraag en voordelen, evenals mogelijke negatieve effecten, wordt onderzocht en de verstoring tot een aanvaardbaar minimum wordt teruggebracht door passende maatregelen.

Het is daarom de taak van verandermanagement om ervoor te zorgen dat gestandaardiseerde methoden en procedures voor het uitvoeren van wijzigingen bestaan ​​en dat deze ook efficiënt en consistent worden gebruikt.

Wijzig managementtaken

Verandermanagement is verantwoordelijk voor het maken en beheren van het veranderingsproces. Het proces omvat capture, documentatie, goedkeuring en monitoring, waardoor wijzigingen worden gepland, efficiënt, kosteneffectief en met minimaal risico.

Om het risico van elke wijziging te beoordelen, hebt u gedetailleerde informatie nodig over de afzonderlijke CI’s (configuratie-items) en hun relaties met elkaar. De componenten van de IT-infrastructuur, zogenaamde configuratie-items, worden beheerd als onderdeel van het configuratiebeheer met een Configuration Management Database (CMDB). Verandermanagement omvat meestal:

• Wijzigingen initiëren, documenteren en autoriseren
• Beoordeel de impact, kosten, voordelen en risico’s van de wijzigingen die worden overwogen
• Rechtvaardiging en goedkeuring van wijzigingen
• Plan en coördineer de implementatie van veranderingen ~ Monitoring en rapportage over de implementatie
• Beoordeling en afronding van Request for Changes (RfC’s)

Het is belangrijk dat wijzigingen worden gepland met voldoende doorlooptijd. Alleen geplande en tijdige wijzigingen kunnen effectief worden gecontroleerd, omdat dit ervoor zorgt dat er voldoende tijd is om bij te houden wat gepland is en wat er nog meer moet worden gedaan.

Communicatie is de sleutel tot een succesvol veranderingsproces. Te weinig communicatie is vaak de reden dat wijzigingen niet correct worden uitgevoerd en dat er zich incidenten voordoen. Hoe meer werknemers worden geïnformeerd, hoe groter de kans dat de verandering adequaat wordt geanalyseerd en bewaakt, zodat de implementatie foutloos is. Daarom is een communicatiestructuur (bijv. De CAB, Change Advisory Board) noodzakelijk. Ook belangrijk zijn rapporten. Deze helpen om de veranderingen zelf aan te kondigen, evenals de manier waarop ze worden uitgevoerd.

Mission Statement

Binnen de strategische missieverklaring heeft de term “geautoriseerde veranderingen” een zeer sterke betekenis en is deze goed gedefinieerd. Maar goede werkwijzen voor verandermanagement doen recht aan de kleine dagelijkse veranderingen en de veranderingen die nodig zijn om een ​​kritieke service onmiddellijk te herstellen of een groot aantal klanten te beïnvloeden. Als een gebruiker bijvoorbeeld zijn wachtwoord wil wijzigen, is een volledig wijzigingsverzoek inclusief daaropvolgende bespreking van de wijzigingsadviesraad niet geschikt voor goedkeuring. Ook moet een wijziging die onmiddellijk moet worden aangebracht om een ​​kritieke service te herstellen een sneller verwerkingsproces doorlopen dan normale wijzigingen.

Sommigen zien extra bureaucratie bij het implementeren van uitgebreide cross-functionele verandermanagementprocessen met formele documentatie, vergaderingen en goedkeuringen, Op het eerste gezicht zou je kunnen denken dat dit allesomvattende proces van verandermanagement diegenen die de veranderingen moeten aanbrengen zal hinderen om de IT-omgeving draaiende te houden. In feite zouden echter geschikte processen voor het beheer van wijzigingenbeheer (en configuratiebeheer) de noodzaak van constante ad-hocwijzigingen die worden gevonden in omgevingen die onvoldoende of niet voldoende wijzigingen en configuratiemanagementpraktijken hebben, verminderen. Een goed doordacht wijzigings- en configuratiebeheerproces moet de vereiste wijzigingen snel verwerken en goedkeuren. Deze goedgekeurde wijzigingen worden ondersteund door IT-beheer en geanalyseerd op risico, kosten en impact.

Procesimplementatie

In de hedendaagse bedrijfswereld vereist de afhankelijkheid van IT-systemen en technologie dat het management genoeg tijd besteedt aan het schatten van het belang van bedrijfsverandering voor IT en de impact van IT-verandering op het bedrijf. Het beheer van wijzigingen is een voltijdse taak geworden. Als wijzigingen worden beheerd om het risico, de ernst van de impact en mogelijke verstoring te maximaliseren en als de wijzigingen bij de eerste poging succesvol zijn, is het essentieel voor de organisatie om dit proces snel te implementeren.

Terminologie

De definities van de voorwaarden zijn:

Wijzig

Wijziging of uitbreiding van een bestaande specificatie, product of dienst. Deze omvatten het toevoegen, wijzigen of verwijderen van goedgekeurde, ondersteunde of bevroren hardware, netwerkcomponenten, software, applicaties, omgevingscomponenten, systemen, desktop-builds, elke noodzakelijke of gerelateerde configuratie of gerelateerde documentatie.

Request for Change (RfC)

Een wijzigingsverzoek of de bijbehorende formulier (papier of onlineformulier) dat wordt gebruikt om details vast te leggen van een wijzigingsverzoek dat betrekking heeft op een CI ( configuratie-item ) binnen de infrastructuur of aan infrastructuur gerelateerde procedures of apparaten.

Wijzigingsschema doorsturen (FSC)

Schema met details van de goedgekeurde wijzigingen voor uitvoering en de beoogde implementatiedatum.

Verandermanagementproces

Het basisproces is onafhankelijk van of het een kleine wijziging betreft, zoals het uitbreiden van het geheugen van een server of een project met een aanzienlijke impact op de bestaande bewerking. De urgentie heeft ook geen invloed op het proces zelf, maar de processnelheden en prioriteiten zijn anders. Bepalende blokken in het proces voor verandermanagement zijn:

Verzoek om wijziging

RfC – naar Duits amendement. Met de formele registratie van de applicatie begint de levenscyclus van een verandering. De RfC is het eigenlijke logboek, dus de verzameling van alle activiteiten van deze levenscyclus. Alle activiteiten, discussies, beschrijvingen, analyses, documentatie en beslissingen met betrekking tot een verandering worden vastgelegd.

Registratie en classificatie

Verzamel de informatie die u nodig hebt om beslissingen te nemen over wat moet worden gewijzigd, in welke categorie de wijziging valt en welke impact dit heeft om de goedkeuring correct uit te voeren. Een prioriteit en categorie worden toegewezen aan de wijziging op basis van de impact. Risicobeoordeling is in dit stadium van cruciaal belang.

Monitoring en planning

Alle wijzigingen worden gepland onder de verantwoordelijkheid van Change Management en indien nodig voor een optimale controle van de verandering (en), wordt een volledige tijdlijn (met FSC-mijlpalen) verstrekt.

Goedkeuring

Bepaal of de wijziging is doorgevoerd of niet.

Ontwikkeling en het testen

Goedgekeurde wijzigingen worden ter voorbereiding doorgestuurd naar de relevante technische groepen. Wijzigingsbeheer, met behulp van releasemanagement en normaal lijnbeheer, beheert de coördinatie om ervoor te zorgen dat de activiteiten zowel de vereiste resources als de tijdige uitvoering ervan ontvangen. Om te voorkomen dat de wijzigingen een serieuze impact hebben op de servicekwaliteit, is het raadzaam om de wijzigingen grondig door te nemen vóór de implementatie en back-outplannen op te stellen.

Release van de implementatie [ edit | Bewerken ]

Na een geschikte test en het controleren of alle noodzakelijke acties zijn uitgevoerd, bijvoorbeeld het controleren op de aanwezigheid van een back-outplan, kan de wijziging worden vrijgegeven voor uitvoering.

Implementatie

Het is de taak van verandermanagement om ervoor te zorgen dat de wijzigingen worden geïmplementeerd binnen het beoogde tijdsbestek. Dit zal echter vooral de coördinatie van de verandering betekenen, aangezien de daadwerkelijke uitvoering de verantwoordelijkheid is van anderen (bijv. Hardwarewijzigingen worden door technici aangebracht).

Evaluatie

Wijzigingsbeheer moet alle wijzigingen evalueren die na een gedefinieerde periode zijn gemaakt. Dit gebeurt via een Post Implementation Review (PIR).

Het doel is om de efficiëntie van de genomen maatregelen en het bijbehorende proces te onderzoeken. Zowel de aangebrachte wijzigingen als de gebruikte methoden en processen moeten worden onderworpen aan een daadwerkelijke doelanalyse. Voor grotere veranderingen spelen kosten-batenvergelijkingen, de return on investment (ROI) berekening en het meten van het bereiken van doelen vanuit een zakelijk perspectief ook een rol. Een algemeen geldige evaluatiecatalogus van de PIR maakt het mogelijk een objectieve evaluatie en, kort gezegd, in relatie tot een langere tijdsperiode, ook een trendverklaring te geven over de vraag of de gebruikte fondsen efficiënt bijdragen aan het oplossen van problemen.

De evaluatiecatalogus bevat vragen zoals:

• Zijn doelen gesteld binnen vooraf gedefinieerde limieten?
• Komt het resultaat overeen met de vorige verwachting?
• Zijn de overeengekomen projecttijden (mijlpalen) gehaald?
• Is het proces uitgevoerd met het opgegeven budget en middelen?
• Zijn er onvoorziene problemen opgetreden?

Afhankelijk van de reikwijdte van de oorspronkelijke wijziging, kan dit proces de deelname van CAB-, MB- en / of EG-leden en geschikte counselors vereisen. Het verandermanagement bepaalt de data en de agenda en vraagt ​​om ondersteuning. Het verandermanagement moet ook de overeengekomen evaluaties uitvoeren en passende maatregelen nemen om eventuele tekortkomingen in het proces voor veranderingsbeheer op te heffen, zelfs als gevolg van niet-effectieve wijzigingen.

Reikwijdte van Request for Change (RfC) [ Edit | Bewerken ]

Het verzoek om wijziging is een verzoek of een opdracht om het beheer te wijzigen om een ​​wijziging of uitbreiding in de IT-omgeving aan te brengen. Complete services en CI’s worden toegevoegd of bestaande services en CI’s aangepast. Verzoeken om verandering worden door veel verschillende aanvragers ingediend om veel verschillende redenen. Dit is het begin van de levenscyclus van een verandering. RfC’s kunnen verwijzen naar elk onderdeel van de infrastructuur en naar elke dienst of activiteit. RfC’s kunnen op papier of, zoals steeds vaker, elektronisch worden bewaard, bijvoorbeeld op het intranet van het bedrijf. Alle RfC’s moeten worden vastgelegd en duidelijk herkenbaar door een nummer toe te wijzen.

De volgende velden moeten worden opgenomen in een RfC-formulier, ongeacht de papieren of elektronische uitvoering:

• RfC-nummer (bovendien een kruisverwijzing naar het probleemnummer, indien nodig)
• Beschrijving en identiteit van de elementen die moeten worden gewijzigd (inclusief CI-identificatie bij gebruik van een configuratiebeheersysteem)
• Reden voor de verandering
• Gevolgen als de wijziging niet wordt doorgevoerd
• Versie van het item dat moet worden gewijzigd
• Naam, kantoor en telefoonnummer van de persoon die de wijziging heeft voorgesteld
• Datum waarop de wijziging is voorgesteld
• Prioriteit van de verandering
• Schatting van de impact en benodigde middelen (die indien nodig ook op een apart formulier kunnen worden vermeld)
• Indien van toepassing, CAB-aanbevelingen (die ook afzonderlijk kunnen worden vermeld indien nodig, waarbij de benodigde impact en middelen worden geschat)
• Handtekening voor goedkeuring (kan ook elektronisch zijn)
• Datum en tijdstip van goedkeuring
• Implementatieschema (release-identificatie en / of datum / tijd)
• Opslaglocatie van het release / implementatieplan
• Details van de Change Worker / Implementer
• Back-out plan
• Huidige datum en tijd van implementatie
• review Date
• Reviewresultaten (inclusief kruisverwijzing naar nieuwe RfC indien nodig)
• Risicoanalyse en -beheer
• Invloed op ongevallen- en rampenplannen van het bedrijf
• Status van de RfC – z. Bijvoorbeeld ‘opgenomen’, ‘geschat’, ‘afgewezen’, ‘goedgekeurd’, ‘wachtend’

Naarmate de wijziging in de levenscyclus doorgaat, moet de aanvraag voor wijziging worden bijgewerkt, zodat de persoon die de wijziging heeft gestart, op de hoogte wordt gesteld van de status. De gebruikte huidige bronnen en geaccumuleerde kosten moeten als onderdeel van het record worden ingevoerd.

Prioritization [ edit | Bewerken ]

Zodra de wijziging is geaccepteerd, worden prioriteit en categorie toegekend. De prioriteit toont de betekenis van de verandering en bestaat uit de impact van het probleem en de urgentie van de remedie. De probleemmanager heeft mogelijk al een prioriteit, maar de uiteindelijke prioriteit voor de wijziging zal worden gelegd in verandermanagement, waarbij alle andere RfC’s in de discussie worden overwogen. De categorie wordt toegewezen door Change Manager. Deze classificatie bepaalt hoe de zaak verder wordt verwerkt en wordt daarom bepaald door de “ernst” van de aanpassing.

Voorbeelden van prioriteitsgradaties zijn:

Urgent

Hoogste prioriteit; de RfC betreft een probleem dat een enorme verstoring van het gebruik van essentiële diensten veroorzaakt, of het heeft een dringende behoefte om IT aan te passen (bijvoorbeeld nieuwe functionaliteiten vanwege zakelijke overwegingen of nieuwe wettelijke richtlijnen). Dringende wijzigingen verschillen van de normale, omdat de benodigde bronnen voor dat type onmiddellijk beschikbaar moeten zijn. Een spoedvergadering van de CAB (CAB / EC) of de IT-regellus kan vereist zijn. Alle andere geplande activiteiten kunnen tijdelijk worden opgeschort.

Hoog

Lost ernstige technische problemen op voor een grote groep of een groot aantal gebruikers of behandelt andere belangrijke situaties. Deze verandering heeft de hoogste prioriteit bij de toewijzing van middelen voor ontwikkeling, testen en implementatie van de verandering.

Medium

Normale prioriteit: geen grote urgentie of hoge impact, maar de wijziging kan niet worden uitgesteld tot het volgende geplande release- of onderhoudsvenster . De wijziging krijgt een gemiddelde prioriteit bij het toewijzen van bronnen.

Laag

Een gerechtvaardigde en noodzakelijke verandering, maar deze kan worden uitgesteld tot een geschikter tijdstip. Bijvoorbeeld tot het volgende release- of geplande onderhoudsvenster. Middelen worden toegewezen op basis van de tijd.

Categorisatie

Onderverdeling van de categorie.
Categorieën worden toegewezen door de Change Manager, indien nodig in samenwerking met de CAB. De categorieën geven een indicatie van de impact van de verandering op de organisatie en de belasting van de IT-organisatie. Hieronder ziet u een voorbeeld van een onderverdeling van categorieën:

Standaard

Standaard infrastructuurwijzigingen waarvoor nauwkeurige procedures bestaan ​​en die vooraf zijn goedgekeurd door de change manager. Deze procedures zorgen ervoor dat risico’s kunnen worden verwaarloosd of goed worden beheerd. De wijziging kan worden uitgevoerd zonder opnieuw contact op te nemen met een change manager.

Normaal

Categorie 1

Laag risico voor doorlopende bedrijfsprocessen. Een verandering die niet veel werk vereist. De change manager kan dit type verandering delen zonder het met de CAB te bespreken.

Categorie 2

Aanzienlijk risico voor de huidige bedrijfsprocessen. Veranderingen die meer inspanning vergen en een grotere impact hebben op de services. Dergelijke wijzigingen zullen in de volgende geplande CAB-discussie worden besproken om de inspanning en de potentiële gevolgen die nodig zijn te voorspellen. Vóór de vergadering zullen sommige vereiste documenten worden verzonden naar CAB-leden en mogelijk naar enkele specialisten en ontwikkelaars. Voor wijzigingen met de prioriteit “urgent” is de CAB / EC dienovereenkomstig verantwoordelijk.

Categorie 3

Aanzienlijk risico voor de huidige bedrijfsprocessen. Een verandering die veel inspanning en middelen vereist om uit te voeren. Bij een verandering van deze aard vereist de verandermanager de goedkeuring van IT-beheer, een IT-stuurgroep of management (MB) en moet deze dan bespreken met de CAB.

Noodsituatie – Noodgeval

Een speciaal geval van de Verandering, dat niet het gebruikelijke proces doorloopt, maar onmiddellijk wordt uitgevoerd, indien nodig, zelfs met aanzienlijk risico en zonder verdere goedkeuring van belanghebbenden, meestal om grote schade te voorkomen. Bij een dergelijke wijziging heeft de change manager alleen goedkeuring nodig van de Emergency Committee (EC). Prioriteit hier is om te kunnen reageren op een noodsituatie, overeenkomstige verdere goedkeuringen en tests worden pas na de wijziging uitgevoerd.

De meeste wijzigingen kunnen worden toegewezen aan de eerste twee categorieën.

De Change Advisory Board (CAB)

Change Advisory Board is een ITIL- rol. Sommigen begrijpen de term “bord” als zeer formele, regelmatige vergaderingen van dezelfde groep topfunctionarissen. Een CAB-vergadering kan zowel formeel als informeel zijn. In de hedendaagse bedrijfswereld zou de term ‘team’ de typische vorm van een CAB nauwkeuriger kunnen beschrijven. Het CAB-team kan regelmatig bijeenkomen, volgens de ITIL-aanbeveling, ten minste om de 20 dagen. De CAB-vergaderingen kunnen ook meerdere keren per week plaatsvinden, met speciale vergaderingen op elk moment. Sommige CAB-leden zullen waarschijnlijk regelmatig CAB-vergaderingen bijwonen; anderen kunnen daarentegen worden uitgenodigd om individuele vergaderingen bij te wonen om input te leveren voor een specifiek verzoek tot wijziging dat wordt besproken.

De CAB ondersteunt de verandermanager bij het beoordelen en prioriteren van veranderingen in de bedrijfsimpact. Wanneer een CAB wordt bijeengeroepen, moeten de geselecteerde leden de wijziging kunnen beoordelen, zowel vanuit het oogpunt van het bedrijf als vanuit technisch oogpunt. Om deze mix te bereiken, moet de CAB personen omvatten met een duidelijk begrip van de zakelijke behoeften van de klant, evenals gebruikers en vertegenwoordigers van de technische ontwikkelings- en ondersteuningsgebieden.

Leden van de CAB kunnen naast de change manager zijn: klanten, gebruikers op managementniveau, gebruikersvertegenwoordigers, applicatie-ontwikkelaars of supervisors (indien van toepassing), deskundigen / technische consultants, servicemedewerkers (indien nodig), personeel van domotica ( als veranderingen van invloed zijn op de kantoorinstallaties en omgekeerd), vertegenwoordigers van onderaannemers en andere fabrikanten (indien nodig, bijvoorbeeld in procedures voor uitbesteding).

Het is belangrijk om te benadrukken dat de CAB

• Bestaat uit vaste leden (verandermanager) en tijdelijke leden
• Het is samengesteld volgens de wijzigingen die moeten worden verwerkt
• De samenstelling kan ook aanzienlijk verschillen binnen een enkele vergadering
• Moet overleggen met leveranciers, als dat nuttig is
• Zowel het standpunt van de gebruiker als de klant moet worden bekeken
• Op zijn minst tijdelijk moeten de manager probleemmanagement / serviceniveau en het personeel voor klantrelaties raadplegen

Wanneer zich wijzigingen van categorie 2 voordoen die in een korte tijd moeten worden geëvalueerd ( urgente prioriteit ), is het noodzakelijk om een ​​kleinere organisatie op te richten die de bevoegdheid heeft om dringende beslissingen te nemen. Een dergelijk orgaan wordt genoemd in de ITIL CAB Emergency Committee (CAB / EC) . Wijzigingsprocedures moeten bepalen hoe de samenstelling van de CAB en CAB / EC zal worden bepaald, op basis van de bovenstaande criteria en eventuele andere criteria die belangrijk zijn voor het bedrijf. Dit zal er ook voor zorgen dat de samenstelling van de CBI de mogelijkheid biedt om de juiste beslissingen te nemen in alle mogelijke gevallen van onvoorziene omstandigheden, zowel vanuit zakelijk oogpunt als vanuit technisch oogpunt.

Relaties met andere ITIL-processen

Configuratiebeheer

Verandering en configuratiebeheer zijn twee zeer nauw met elkaar verbonden processen. Configuratiemanagement kan niet bestaan ​​zonder verandermanagement omdat het afhankelijk is van actuele informatie over de IT-infrastructuur via wijzigingsbeheer. Omgekeerd heeft wijzigingsbeheer zonder configuratiebeheer geen enkele mogelijkheid om de impact van een wijziging op de rest van de IT-infrastructuur, IT-services en bedrijven te beoordelen. Als de Configuration Manager – na controle – CI’s ( Configuration Item ) heeft gevonden in de configuratie die niet in de database staat, zijn er twee mogelijkheden:

1. de database is niet up-to-date, wat erop kan wijzen dat Configuration Management niet op de hoogte was van een wijziging
2. iemand heeft een illegale – ongeautoriseerde – wijziging aangebracht

Analysis, risico’s en de impact

Het belangrijkste gebied waarop de processen zijn aangesloten, is de analyse van de impact en het risico van een verandering. Het grootste deel hiervan moet worden gedaan met de steun van de CMDB. Na ontvangst van een RfC is een van de eerste activiteiten die moet worden uitgevoerd, te achterhalen welke CI of welke CI’s moeten worden gewijzigd en wat de impact op de bestaande infrastructuur is. Verandermanagement moet ook bepalen of deze ene RfC in verschillende RfC’s resulteert, omdat als gevolg van de RfC verschillende CI’s moeten worden gewijzigd. Ook moet worden bepaald of deze wijziging van invloed is op een of meer gebruikers, een of meer organisaties of een of meer services om het juiste impactniveau toe te wijzen. Op basis hiervan kan de change manager beslissen of de CAB moet worden opgeroepen,

Capaciteitsbeheer

Capaciteitsbeheer moet de impact van veranderingen op de bestaande capaciteit beoordelen en vaststellen welke aanvullende capaciteit nodig is. Aanvullende capaciteitsvereisten moeten worden opgenomen in het capaciteitsplan en ook als RfC’s worden behandeld.

Release Management

Releasebeheer is het proces dat verantwoordelijk is voor het plannen en beheren van de overgang van releases naar test- en live-omgevingen. Het primaire doel van releasemanagement is ervoor te zorgen dat de integriteit van de liveomgeving wordt behouden en dat de juiste componenten worden opgenomen in de release. Releasebeheer maakt deel uit van het beheerproces voor release en deployment .

Samenvatting van RfC’s

Het combineren van gekoppelde RfC’s helpt niet alleen om de impact realistischer te beoordelen, maar vermindert ook de bureaucratische last van verandermanagement.

Samenvatting

Request for Change (RfC)

Een wijziging is elke wijziging in een of meer CI’s. Het kan variëren van ernstig (zoals het vervangen van een besturingsserver) en eenvoudig (het vervangen van een printerstuurprogramma) en kan van invloed zijn op alle componenten in de CMDB. Om de aanpassingen uit te voeren, kunnen zowel klanten als probleembeheer een wijzigingsverzoek (Request for Change, RfC) indienen bij de change manager. Interne IT-vereisten (serviceplanning, ontwikkeling, enz.) Kunnen ook resulteren in een RFC.

De wijzigingsmanager

De verandermanager is verantwoordelijk voor een systematische verandering, na afweging van de bekende risico’s. Hij houdt ook toezicht op de voortgang van de verandering. De Change Manager beoordeelt de Request for Change (RfC) samen met de Change Advisory Board (CAB). Deze commissie bestaat uit ervaren medewerkers van de betrokken disciplines.

Het proces

De verandermanager ontvangt het verzoek tot wijziging (RfC), controleert het op volledigheid, neemt het op en classificeert het op basis van de geschatte risico’s. Als de wijziging in principe is goedgekeurd, worden de consequenties in termen van capaciteit meegenomen. Beschikbaarheid en kosten worden geanalyseerd in het serviceplanningsproces. Het voorstel kan vervolgens worden gedeeld met de ontwikkelingsafdeling voor ontwerp, ontwikkeling en testen nadat het is goedgekeurd door verandermanagement.

De Change Manager, indien nodig geadviseerd door de CAB, beslist over het tijdschema van de release op basis van de testresultaten en een goed voorbereid back-outplan. Het back-outplan zorgt ervoor dat de organisatie altijd naar de vorige situatie kan terugkeren als onvoorziene problemen zich voordoen. Alleen dan is de releasemanager bevoegd om de implementatie uit te voeren. Als het een “softwarerelease” is, wordt de release gevolgd door een productietest via het releasebeheerproces voordat de software op proefbasis voor distributie wordt gedistribueerd. Bovendien moet een postimplementatiebeoordeling (PIR) altijd de verandering en de manier waarop het is geïmplementeerd volgen.

Managementrapporten

Verandermanagement moet (idealiter samen met bedrijfsmanagement) maatstaven bepalen die een specifieke betekenis hebben. Het is relatief eenvoudig om incidenten te tellen waaruit problemen voortvloeien en waarvan op zijn beurt veranderingen optreden. Het is echter veel belangrijker om naar de onderliggende oorzaken te kijken en trends te identificeren. Het is het beste om de impact van wijzigingsbeheer te meten en in de loop van de tijd minder verstoringen aan te tonen door de introductie van wijzigingsbeheer, evenals de snelheid en effectiviteit te meten waarmee de IT-infrastructuur op veranderende bedrijfsbehoeften reageert. Gebruikte meeteenheden moeten waar mogelijk worden gekoppeld aan bedrijfsdoelen – en met kosten, diensten, beschikbaarheid en betrouwbaarheid. Alle voorspellingen moeten worden vergeleken met feitelijke metingen.

Regelmatige samenvattingen van wijzigingen moeten beschikbaar worden gemaakt voor servicemanagement, klanten en gebruikersbeheer. Verschillende managementniveaus vereisen meestal verschillende soorten informatie. Dit varieert van de servicemanager, die mogelijk een gedetailleerd wekelijks rapport nodig heeft, tot hogere managementcomités, die doorgaans slechts op kwartaalbasis een managementsamenvatting vereisen. De volgende feiten en statistieken moeten worden overwogen in de beheersverslagen:

• Het aantal wijzigingen in een periode in totaal en volgens CI, configuratietype, service etc.
• Een uitsplitsing van de redenen voor wijzigingen (gebruikersorders, uitbreidingen, zakelijke vereisten, serviceoproep / incident / probleemoplossingen, procedures / trainingsverbeteringen, enz.)
• Het aantal succesvolle wijzigingen
• Het aantal ongedaan gemaakte wijzigingen (back-out) samen met de redenen (slechte schatting, slechte build)
• Het aantal incidenten dat kan worden toegeschreven aan wijzigingen (uitgesplitst naar ernst van het probleem) en de redenen (bijvoorbeeld verkeerde beoordeling, slechte build)
• Het aantal RfC’s (en trends in toekomstige nummers)
• Het aantal voltooide wijzigingen dat is beoordeeld en het aantal openstaande beoordelingen (opgesplitst naar tijd)
• Hoog aantal RfC’s gerelateerd aan een enkele CI (deze CI’s zijn het bekijken waard) inclusief redenen (bijvoorbeeld het wijzigen van gebruikersvereisten, onstabiele componenten, slechte build)
• Nummers uit vorige perioden (laatste periode, vorig jaar) ter vergelijking
• Het aantal afgewezen RfC’s
• De verhouding tussen de aangebrachte wijzigingen en de mislukte wijzigingen (totaal en uitgesplitst per CI)
• Openstaande wijzigingen, opgesplitst per CI en het niveau in het proces voor wijzigingsbeheer

Bron

HP, ITIL-basisprincipes van IT-servicebeheer, studentenwerkboek, versie D.00_EN-1