Configuratie controle — laat de handboeien los!

het steeds complexere, mondiale karakter van alle activiteiten in alle sectoren en verticale sectoren, in combinatie met snelstartende bedrijfsmodellen voor “internettijd”, zorgt voor een nieuwe nadruk op veranderingsmanagement. Het vermogen om verandering effectief te beheersen is een onderscheidende sleutel tussen concurrenten – waardoor organisaties bedrijfsmodellen en productlijnen kunnen ontwikkelen en snel genoeg kunnen schakelen om de kansen van de huidige economie te benutten – voor de concurrentie.

naarmate organisaties moeite hebben om projecten in deze omgeving te beheren, is Configuration Management (CM) een steeds kritischer component geworden, die een kader biedt voor het beheren van veranderingen.

de discipline van CM bestaat uit zes expertisegebieden zoals gedefinieerd in MEB-649 (ANSI)., 2004))

• CM Planning and Management (CMPM),
• Configuration Identification (CI),
• Configuration Change Management (CCM),
• Configuration Status Accounting (CSA),
• Configuration Verification & Audits (CVA), en
• CM digitale gegevens.

echter, ISO 10007 (ISO, 2003) groepeert CM in vier classificaties:

• CI,
• Configuration Control (CC),
• CSA, en
• Configuration Reviews and Audits (R&A).

(CCM en CC zijn voor alle praktische doeleinden identiek, net als CVA en R& A.)

merk op dat Configuratiebeheer in dit artikel wordt besproken. Configuratiebeheer en change control zijn ook termen die worden gebruikt om hetzelfde proces te beschrijven.

veel projectmanagers zien configuratiecontrole als beperkend en beperkend – systemen ontworpen om productontwikkeling te stunten en dat heeft meestal een negatieve invloed op het projectschema. Helaas worden generieke CC-processen die zijn ontworpen voor grote, complexe programma ‘ s zoals wapens of de ontwikkeling van medische systemen, maar al te vaak opgelegd aan andere soorten projecten. Deze processen zijn niet afgestemd op de behoeften van bijvoorbeeld een web development inspanning of een nieuwe product roll-out. Dit leidt uiteindelijk tot intense frustratie met het CC-proces en het” handboeien ” – effect – waarbij processen die niet zijn ontworpen om aan de behoeften van het programma te voldoen, de vooruitgang negatief beïnvloeden.

projectmanagers implementeren Configuratiebeheer om wijzigingen te controleren en te volgen. De processen zijn zo ontworpen dat het juiste niveau wordt gebruikt om wijzigingen goed te keuren en dat deze wijzigingen gebaseerd zijn op de beste beschikbare informatie. De processen bieden een kader voor de herziening van de veranderingen. Dit stelt het team in staat om te beoordelen of de implementatie van de verandering aanvaardbaar is en om potentiële problemen tijdig te identificeren. Deze processen maken kalibratie en indien nodig verdere revisie mogelijk.

de echte vraag is niet of Configuratiebeheer moet worden geïmplementeerd, maar welk niveau van Configuratiebeheer moet worden geïmplementeerd. Een organisatie kan een “company standard” configuratie controle pakket op alle projecten vereisen. Dit type systeem wordt vaak opgelegd aan projectteams als gevolg van een geschiedenis van gebrek aan configuratie controle, en de daaruit voortvloeiende financiële gevolgen. Projectmanagers, die erkennen dat een” one-size-fits-all ” aanpak niet zal werken, moeten aantonen dat er adequate controles zijn om herhaling van fouten uit het verleden te voorkomen.

configuratie controle in Actie

het typische ontwikkelingsproject vereist geen configuratie controle proces op het niveau van een belangrijk wapensysteem. Het is belangrijk om het team de nodige flexibiliteit te bieden en tegelijkertijd te zorgen voor een systeem van checks and balances. De sleutel tot elk systeem is de inspanning die nodig is bij het documenteren van het proces, samen met de documentatie die nodig is door het proces. Het voorbeeld CC proces hieronder beschreven is ontworpen om te voldoen aan de eisen van een kleine tot middelgrote applicatie ontwikkeling project.

het projectteam dient eerst de juiste rol van configuratie controle op het project te analyseren. Dit, op zijn minst op een software project, zou een thema van het documenteren van alle code bestanden intern en een soort van externe documentatie. Andere te behandelen gebieden zijn onder meer goedkeuring van wijzigingen en documentatieprocessen wijzigen. Een eenvoudige consensus door de betrokken deelnemers zou moeten volstaan. Natuurlijk is een gestructureerd bestuur dat regelmatig bijeen komt beter.

laten we nu ingaan op de verschillende aspecten van het eenvoudige Configuratiebeheerproces.

documenten

het Configuratiebeheerplan (CMP) definieert het CC-proces. In sommige toepassingen waar het CC-proces vrij gedetailleerd is, wordt een Configuration Control Plan (CCP) ontwikkeld. In beide gevallen worden alle processen en procedures behandeld om Configuratiebeheer uit te voeren.

de documentatie zelf wijzigen (later gedetailleerd) moet voldoende informatie bevatten die voor zichzelf spreekt, zodat geen aanvullende informatie van de opsteller vereist is. Dit is vereist omdat de initiator mogelijk niet beschikbaar is op het moment dat de wijziging wordt geïmplementeerd.

proces

het CC-proces is eenvoudig (Bijlage 1). Een individu heeft een idee of vindt een fout in het huidige systeem. Dit individu moet hun bevindingen documenteren op een Enterprise Change Request (ECR), een formulier dat wordt gebruikt om alle bugs, wijzigingen of verbeteringen voor het gegeven project in te loggen. Het wijzigingsverzoek wordt ter beoordeling doorgestuurd naar peers en toezichthouders en vervolgens goedgekeurd en geïmplementeerd.

Exhibit 1-Simple Configuration Control Process

Change Documentation

het documenteren van wijzigingen is het meest kritische onderdeel van een configuration control system. De details van de documentatie zijn niet zo belangrijk als de informatie die wordt gedocumenteerd. De gedocumenteerde informatie moet echter de wijziging beschrijven en ten minste de volgende informatie bevatten. Minimale vereisten voor documentatie zijn:

natuurlijk, de meer informatie in de documentatie, hoe makkelijker het is om te recreëren, te herstellen, te analyseren en te corrigeren. Bovendien zal dit helpen bij de definitieve documentatie voor de levering van het product.

wanneer een individu een fout of vereiste in het lopende project ontdekt, documenteert hij of zij de vereiste wijziging. Een wijzigingsverzoek bevat informatie over het verzoek en beschrijft het scenario dat de fout ontdekte, wie het ontdekte, wanneer het werd ontdekt, en aanbevolen oplossingen. Het verzoek moet ook de betrokken configuratieitems identificeren, indien mogelijk, en een soort van ernst of prioriteitscode plaatsen om te bepalen wanneer deze wijziging, indien goedgekeurd, moet plaatsvinden.

Change Approval

Change approval moet komen van een aangewezen projectleider met de “big picture” view of change impact. Een peer review is een zeer effectief middel om alle facetten van de verandering te controleren en ervoor te zorgen dat alle gebieden waarop de verandering betrekking heeft, worden aangepakt. Als de klant akkoord gaat met de verandering zou dat gunstig zijn voor verbeteringen. Echter in kleine ontwikkelingen projecten, de meeste veranderingen zijn van een” bug fix ” type en de klant zou niet de impact van de verandering te zien.

gegevensverzameling

gegevensverzameling is van vitaal belang voor het terugvinden van informatie over soortgelijke items en het ontdekken van trends en tendensen. Deze informatie moet elektronisch aanwezig zijn, waardoor gegevens gemakkelijk kunnen worden hersteld en gegevensmanipulatie voor statusboekhouding en statistieken mogelijk is. De informatie kan worden gebruikt om een “lessons learned” rapport samen te stellen, dat wordt verspreid over een organisatie voor technische verbetering.

Implementatie Wijzigen.

zodra alle passende goedkeuringen zijn ontvangen, begint de implementatietaak. Testen bij elke stap van de implementatie verifieert dat de impact op andere aspecten van het programma minimaal is. Alle testen zijn voltooid en de wijziging wordt geïmplementeerd in het hele programma.

Closed-Loop Process

een closed-loop proces waarbij de initiator van de verandering het eindresultaat van de verandering zal kennen voordat deze in het eindproduct verschijnt, is een belangrijke component voor succes. Dit geldt voor alle soorten industrieën, van bouw tot productie tot software.

dit closed-loop-proces zet controleborden op met verschillende rollen in het veranderingsproces (Exhibit 2). Elke Raad heeft de verplichting om een wijziging in de volledige context van zijn handvest te herzien en voor elke wijziging een definitief besluit te nemen. Natuurlijk kan het bestuur aanvullende informatie nodig hebben voordat het die beslissing kan nemen, maar dit moet minimaal zijn.

het Instituut voor Configuratiebeheer (ICMHQ) doceert de CMII (CMIIU) methodologie voor Configuratiebeheer en heeft deze visie ontwikkeld op een proces van closed-loop change. Dit proces begint en eindigt met het einditem. Merk op dat het beheer van configuratiewijzigingen op drie verschillende niveaus binnen de lus verschijnt. Elk gebied is anders gedefinieerd en heeft specifieke rollen en verantwoordelijkheden.

• technisch overzicht — zorgt ervoor dat alle gedetailleerde evaluaties en haalbaarheidsanalyses volledig zijn.
• de Change Review Board (CRB) – evalueert de zakelijke impact van de verandering. Is deze wijziging geldig voor ons bedrijfsklimaat? Voldoet het aan een van onze strategische doelen? Past het in onze visie? Bij een goedgekeurde wijziging kan de CRB al dan niet een tijdschema voor de wijziging aangeven, afhankelijk van concurrentievoorspellingen en bedrijfsrisico ‘ s.
• de Change Implementation Board (CIB) – wijst de benodigde financiering toe en bepaalt de implementatietermijnen. Dit omvat ook het toewijzen van effectiviteit voor de verandering, die aangeeft wanneer de verandering effectief is. De effectiviteit kan betrekking hebben op een datum, bouwen, serienummer, of lotnummer. Dit is afhankelijk van het einditem.

de Fast Track optie van de lus is waar alle pijn van CC wordt vrijgegeven en de eigenaren kunnen een veranderd goedgekeurd in minuten versus dagen. De sleutel hiervoor is natuurlijk een goede documentatie boom voor elk product. Elk document moet een maker en gebruiker hebben toegewezen aan hen. Als de wijzigingen alleen van invloed zijn op de documentatie op laag niveau, dan is Fast Track in orde en de verandering schreeuwt door het CC-proces.

samenvatting

de sleutel tot een succesvol Configuratiebeheerproces is de buy-in van het gehele projectteam. Teamleden mogen niet worden gevraagd af te zien van een gedegen oordeel en controle omwille van een beheersinfrastructuur die niet is ontworpen om te voldoen aan de eisen van het project in kwestie. Configuratiebeheerprocessen zijn ontworpen om het risico op storingen te verminderen en ervoor te zorgen dat de te leveren producten op tijd en binnen het budget worden voldaan. Als het projectteam deelneemt aan het opzetten van het initiële Configuratiecontroleraamwerk – wordt de deelname en acceptatie in het hele projectteam versneld en zal de infrastructuur de bedrijfsdoelstellingen ondersteunen.