Konfiguration kontrol-Slip håndjern!

den stadig mere komplekse, globale karakter af alle virksomheder på tværs af brancher og vertikale sektorer kombineret med hurtigbrand, “Internet Time” forretningsmodeller, driver ny vægt på forandringsledelse. Evnen til effektivt at styre forandring fremstår som en differentierende nøgle blandt konkurrenter – der gør det muligt for organisationer at udvikle forretningsmodeller og produktlinjer og skifte gear hurtigt nok til at imødekomme mulighederne i den nuværende økonomi – forud for konkurrencen.

da organisationer kæmper for at styre projekter i dette miljø, er konfigurationsstyring (CM) blevet en stadig mere kritisk komponent, der tilbyder en ramme for styring af ændringer.

cm ‘ s disciplin består af seks ekspertiseområder som defineret af VVM – 649 (ANSI, 2004))

• CM planlægning og styring (CMPM),
• Konfigurationsidentifikation (CI),
• Konfigurationsændringsstyring (CCM),
• Konfigurationsstatus regnskab (CSA),
• Konfigurationsverifikation & revisioner (CVA) og
• CM af digitale Data.

ISO 10007 (ISO, 2003) grupperer dog CM i fire klassifikationer:

• CI,
• Configuration Control (CC),
• CSA og
• Configuration gennemgange og Audits (R & A).

(CCM og CC er til alle praktiske formål identiske, ligesom CVA og R&A.)

Bemærk, at konfigurationskontrol diskuteres i denne artikel. Konfigurationsændringsstyring og ændringskontrol er også udtryk, der bruges til at beskrive den samme proces.

mange projektledere opfatter konfigurationskontrol som begrænsende og begrænsende systemer designet til at stunt produktudvikling, og det påvirker normalt projektets tidsplan på en negativ måde. Desværre pålægges for ofte generiske CC-processer designet til store, komplekse programmer som våben eller udvikling af medicinske systemer andre typer projekter. Disse processer er ikke skræddersyet til at imødekomme behovene i f.eks. en Netudviklingsindsats eller en ny produktudrulning. Dette fører i sidste ende til intens frustration med CC – processen og “håndjern” – effekten-hvor processer, der ikke er designet til at imødekomme programmets behov, påvirker fremskridt negativt.

projektledere implementerer konfigurationskontrol for at kontrollere og spore ændringer. Processerne er designet til at sikre, at det passende niveau bruges til at godkende ændringer, og at disse ændringer er baseret på bedst tilgængelig information. Processerne giver en ramme for ændring gennemgang. Dette gør det muligt for teamet at vurdere, om implementering af ændringen er acceptabel og identificere potentielle problemer rettidigt. Disse processer muliggør kalibrering og om nødvendigt yderligere revision.

det virkelige spørgsmål er ikke, om konfigurationskontrol skal implementeres, men hvilket niveau af konfigurationskontrol der skal implementeres. En organisation kan kræve en” virksomhedsstandard ” konfigurationsstyringspakke på alle projekter. Denne type system pålægges ofte projektteams på grund af en historie med manglende konfigurationskontrol og den deraf følgende økonomiske indvirkning. Projektledere, der erkender, at en “En-størrelse-passer-alle” tilgang ikke fungerer, skal demonstrere, at passende kontroller er på plads for at undgå at gentage tidligere fejl.

Konfigurationskontrol i aktion

det typiske udviklingsprojekt kræver ikke en konfigurationsstyringsproces på niveauet for et større våbensystem. Det er vigtigt at styrke teamet med det passende niveau af fleksibilitet og samtidig sikre, at et system med kontrol og balance er på plads. Nøglen til ethvert system er den krævede indsats for at dokumentere processen sammen med den dokumentation, der kræves af processen. Prøve CC-processen beskrevet nedenfor er designet til at imødekomme kravene i et lille til mellemstort applikationsudviklingsprojekt.

projektteamet skal først analysere den passende rolle konfigurationskontrol på projektet. Dette, som minimum på et program projekt, ville medføre et tema for at dokumentere alle kodefiler internt og en form for ekstern dokumentation. Yderligere områder, der skal dækkes, inkluderer ændringsgodkendelsesprocesser og ændringsdokumentationsprocesser. Enkel konsensus fra de involverede deltagere bør være tilstrækkelig. Selvfølgelig er et struktureret bestyrelse, der indkaldes regelmæssigt, bedre.

lad os nu komme ind på de forskellige aspekter af den enkle Konfigurationsstyringsproces.

dokumenter

Konfigurationsstyringsplanen (CMP) definerer CC-processen. I nogle applikationer, hvor CC-processen er ret detaljeret, udvikles en Konfigurationsstyringsplan (CCP). I begge tilfælde er alle processer og procedurer dækket for at udføre konfigurationskontrol.

Skift dokumentation selv (detaljeret senere) skal give tilstrækkelig information, der er selvforklarende til det punkt, at der ikke kræves yderligere oplysninger fra ophavsmanden. Dette er påkrævet på grund af muligheden for, at ophavsmanden muligvis ikke er tilgængelig på det tidspunkt, hvor ændringen implementeres.

proces

CC-processen er enkel (udstilling 1). En person har en ide eller finder en fejl i det nuværende system. Denne person skal dokumentere deres resultater på en Virksomhedsændringsanmodning (ECR), en formular, der bruges til at logge alle fejl, ændringer eller forbedringer for det givne projekt. Ændringsanmodningen dirigeres til jævnaldrende og vejledere til gennemgang og godkendes og implementeres derefter.

udstilling 1 – Enkel Konfigurationsstyringsproces

Skift dokumentation

dokumentation af ændring er den mest kritiske del af et konfigurationsstyringssystem. Dokumentationens detaljer er ikke så vigtige som de oplysninger, der dokumenteres. De dokumenterede oplysninger skal dog beskrive ændringen og som minimum indeholde følgende oplysninger. Minimale krav til dokumentation er:

jo flere oplysninger der er indeholdt i dokumentationen, jo lettere er det naturligvis at genskabe, gendanne, analysere og rette. Derudover vil dette hjælpe med endelig dokumentation for produktlevering.

når en person opdager en fejl eller et krav i det aktuelle projekt, dokumenterer han eller hun den nødvendige ændring. En ændringsanmodning indeholder oplysninger om anmodningen og beskriver scenariet, der opdagede fejlen, hvem der opdagede den, hvornår den blev opdaget, og anbefalede rettelser. Anmodningen skal også identificere de berørte konfigurationselementer, hvis det er muligt, og placere en slags sværhedsgrad eller prioritetskode for at identificere, hvornår denne ændring, hvis godkendt, skulle forekomme.

Ændringsgodkendelse

Ændringsgodkendelse skal komme fra en udpeget projektleder med visningen “stort billede” af ændringspåvirkning. En peerevaluering er et yderst effektivt middel til at kontrollere alle aspekter af ændringen og sikre, at alle områder, der berøres af ændringen, behandles. At have kunden enig i ændringen ville være gavnligt for forbedringer. Men i små udviklingsprojekter er de fleste ændringer af en “fejlrettelse” – type, og kunden vil ikke se virkningen af ændringen.

dataindsamling

dataindsamling er afgørende for at gendanne oplysninger om lignende emner og opdage tendenser og tendenser. Disse oplysninger skal opholde sig elektronisk, hvilket giver mulighed for nem gendannelse af data og datamanipulation til statusregnskab og metrics. Oplysningerne kan bruges til at udarbejde en “lessons learned” – rapport, som distribueres i en organisation til teknisk forbedring.

Ændring Implementering.

når alle relevante godkendelser er modtaget, begynder implementeringsopgaven. Test på hvert trin i implementeringen verificerer, at virkningerne på andre aspekter af programmet er minimale. Alle test er afsluttet, og ændringen gennemføres i hele programmet.

lukket Kredsløbsproces

en lukket kredsløbsproces, hvor ændringens ophavsmand kender det endelige resultat af ændringen, før den vises i det endelige produkt, er en nøglekomponent for succes. Dette gælder for alle typer af industrier, fra byggeri til fremstilling til programmel.

denne lukkede kredsløbsproces opretter kontrolkort med forskellige roller i ændringsprocessen (udstilling 2). Hvert bestyrelse har pligt til at gennemgå en ændring i den fulde sammenhæng med sit charter og til at træffe en endelig beslutning for hver ændring. Bestyrelsen kan naturligvis kræve yderligere oplysninger, før den kan træffe denne beslutning, men dette bør være minimalt.

Institut for konfigurationsstyring underviser i CMII (CMIIU)-metoden til konfigurationsstyring og har udviklet denne opfattelse af en lukket kredsløbsændringsproces. Denne proces begynder og slutter med slutelementet. Bemærk, at konfigurationsændringsadministration vises på tre forskellige niveauer i sløjfen. Hvert område er defineret forskelligt og har specifikke roller og ansvar.

• teknisk gennemgang-sikrer, at alle detaljerede evalueringer og gennemførlighedsanalyser er komplette.
• Change anmeldelse Board (CRB) – evaluerer forretningsvirkningen af ændringen. Er denne ændring gyldig for vores forretningsmiljø? Opfylder det et af vores strategiske mål? Passer det ind i Vores vision? Med en godkendt ændring kan CRB muligvis angive en tidsramme for ændringen, afhængig af konkurrencedygtig prognose og forretningsrisiko.
• Change Implementation Board (CIB) – tildeler den nødvendige finansiering og bestemmer tidsrammer for ændringsimplementering. Dette inkluderer også tildeling af effektivitet for ændringen, som angiver, hvornår ændringen er effektiv. Effektiviteten kan vedrøre en dato, bygge, serienummer, eller lotnummer. Dette afhænger af slutproduktet.

Fast Track-indstillingen for sløjfen er, hvor al smerte ved CC frigives, og ejerne kan få en ændret godkendt på få minutter versus dage. Nøglen til dette er naturligvis en ordentlig dokumentation træ for hvert produkt. Hvert dokument skal have en skaber og bruger tildelt dem. Hvis ændringerne kun påvirker dokumentationen på lavt niveau, er Fast Track i orden, og ændringen skriger gennem CC-processen.

oversigt

nøglen til enhver vellykket Konfigurationsstyringsproces er buy-in fra hele projektteamet. Teammedlemmer bør ikke anmodes om at opgive sund dømmekraft og kontrol af hensyn til en ledelsesinfrastruktur, der ikke er designet til at opfylde kravene i det aktuelle projekt. Konfigurationsstyringsprocesser er designet til at reducere risikoen for fiasko og sikre, at leverancer opfyldes til tiden og på budgettet. Hvis projektteamet deltager i etableringen af den oprindelige Konfigurationsstyringsramme – accelereres deltagelse og accept på tværs af projektteamet, og den etablerede infrastruktur understøtter forretningsmålene.