MIL-HDBK-61A: Konfigurationskontroll

< föregående / innehåll / nästa >

6.1 Konfigurationskontrollaktivitet

Konfigurationskontroll är kanske det mest synliga elementet i konfigurationshantering. Det är den process som används av entreprenörer och statliga programkontor för att hantera förberedelser, motivering, utvärdering, samordning, disposition och genomförande av föreslagna tekniska förändringar och avvikelser till effected Configuration Items (CIs) och baslinjekonfigurationsdokumentation.

det primära målet med konfigurationskontroll är att upprätta och upprätthålla en systematisk förändringshanteringsprocess som reglerar livscykelkostnader, och:

• möjliggör optimal design och utveckling latitud med lämplig grad, och djupet av konfigurationsändringskontrollprocedurer under livscykeln för ett system/CI.

• ger effektiv bearbetning och implementering av konfigurationsändringar som upprätthåller eller förbättrar operativ beredskap, stödbarhet, utbytbarhet och interoperabilitet

• säkerställer fullständiga, korrekta och aktuella ändringar av konfigurationsdokumentationen som underhålls under lämplig konfigurationskontrollmyndighet

• eliminerar onödig förändring spridning

spännvidden för Konfigurationskontroll börjar för regeringen när det första konfigurationsdokumentet är godkänt och baslinjeformat. Detta inträffar normalt när baslinjen för funktionell konfiguration (kallad kravbaslinjen i MKB/IS-649) fastställs för ett system eller konfigurationsobjekt. Vid den tidpunkten används kompletterande rutiner för hantering av myndighets-och entreprenörsbyten för att systematiskt utvärdera varje föreslagen teknisk förändring eller begärd avvikelse till grunddokumentation, för att bedöma den totala förändringseffekten (inklusive kostnader) genom samordning med berörda funktionella aktiviteter, för att disponera ändringen eller avvikelsen och ge snabb godkännande eller ogillande och för att säkerställa att godkända ändringar genomförs i tid av båda parter. Konfigurationskontroll är en viktig disciplin under hela programmets livscykel. Figur 6-1 illustrerar en aktivitetsmodell på toppnivå för konfigurationskontrollprocessen. Den visar konfigurationskontrollprocessen uppdelad i tre segment, som beskrivs i figurerna 6-2, 6-3 respektive 6-4.

det första segmentet, Regeringskonfigurationskontroll-initiering, återspeglar den del av processen före regeringens begäran om ett contractor Engineering Change Proposal (ECP). Denna aktivitet sker:

• när behovet av en förändring har sitt ursprung i en statlig verksamhet (inklusive fält-och verksamhetsaktiviteter)

• som ett resultat av input från entreprenören att en klass I-ändring till en Regeringskontrollerad baslinje behövs

• efter konfigurationsdokumentation som kommer att påverkas av den föreslagna ändringen har godkänts och ingår i den nuvarande baslinjen som kontrolleras av regeringen

förändringar kan behövas av olika skäl, till exempel för att motverka nytt hot, Infoga ny teknik och svara på tekniska och operativa tester och utvärderingar, eller korrigera problem. Som visas i Figur 6-2 bekräftar den statliga verksamheten som ansvarar för konfigurationskontroll behovet av förändring, sätter tröskelvärden för prestanda, kostnad och schema för den föreslagna ändringen, fastställer att ändringen är tekniskt uppnåelig och överkomlig (baserat på aktuell information och kontraktsinterface, i förekommande fall) och förbereder en begäran för entreprenören / entreprenörerna att förbereda en ECP. En av de viktigaste bidragsgivarna till konfigurationskontroll effektivitet och effektivitet är tydlig och koncis kommunikation mellan regeringen och entreprenören före den formella begäran om ECP. Helst sker detta i en integrerad produktgruppsmiljö.

figur 6-3, vilket återspeglar det andra segmentet av figur 6-1, modeller entreprenörens konfigurationskontrollprocess. Contractor configuration control åberopas som entreprenören släpper varje post i konfigurationsdokumentation. I slutändan tillämpas contractor configuration control på den kompletta uppsättningen konfigurationsdokumentation inklusive Regeringsbaserad konfigurationsdokumentation på prestanda eller detaljerad specifikationsnivå, beroende på vad som är tillämpligt, och designlösningen som ingår i tekniska modeller och ritningar. Entreprenören svarar på regeringens ECP-förfrågningar och på internt genererade förfrågningar om designändringar eller avvikelser (RFD). Entreprenören utvärderar varje föreslagen ändrings-eller avvikelsebegäran och dokumenterar dess inverkan på CI: s utveckling och stödbarhet, bestämmer tillämplig nivå för granskning och godkännande som krävs och säkerställer att ett specifikt beslut om förändringens lönsamhet fattas av den tillämpliga konfigurationskontrollmyndigheten innan den genomförs. ECPs och RFDs som kräver statlig granskning och / eller godkännande vidarebefordras i enlighet med avtalskrav. Beslutet om ändring av godkännande fattas av regeringen när:

• ändringen är ett krav på en baslinje prestandanivå konfigurationsdokument kontrolleras av regeringen, eller

• en ändring av ett konfigurationsdokument som kontrolleras av entreprenören påverkar specificerad prestanda, stödbarhet och andra avtalsenliga specificerade krav som gäller CI och dokumentation som kontrolleras av regeringen.

entreprenören fattar beslutet när ändringen gäller objekt / konfigurationsdokumentation för vilken det är konfigurationskontrollmyndigheten, förutsatt att dessa ändringar inte påverkar regeringens baslinjer.

figur 6-4 modeller det tredje segmentet av figur 6-1, som täcker den del av processen som berörs av regeringens granskning och disposition av entreprenör inlämnade ECP och RFD. Det illustrerar lokala myndigheters granskning och överensstämmelse med klass II-ändringar och mindre avvikelser (där sådan åtgärd krävs enligt avtal) och dess godkännande (eller icke-godkännande) av klass I-ändringar och större/kritiska avvikelser. Regeringens konfigurationskontrollaktivitet (vanligtvis ett sekretariat) förbereder sig för konfigurationskontrollstyrelsen genom att samordna den föreslagna ändringen med alla berörda parter, ta emot teknisk samstämmighet och kostnads-och schemaläggningsåtaganden och genom att placera ändringen/avvikelsen i CCB-kalendern (i samförstånd med dess beredskap och hur brådskande ändringen är). CCB granskar sedan förslaget och genomförandeåtagandena och godkänner eller avvisar dem i enlighet med upphandlingsverksamhetens policy. Som ett resultat av CCB-beslutet ges genomföranderiktning, vanligtvis i form av ett CCB-direktiv. Åtgärder som styrs av CCB inkluderar både avtalsåtgärder och uppdragsorder för statlig verksamhet, beroende på vad som är tillämpligt. Som svar på ett CCB-direktiv förbereder och förhandlar regeringen en Kontraktsändring för att bemyndiga entreprenören att fortsätta med genomförandet av den godkända klass i ECP eller större/kritisk avvikelse.

en effektiv, väldefinierad konfigurationskontroll process försäkrar regeringen programkontoret att alla ändringar av statligt styrda baslinjer, oavsett hur liten eller till synes obetydlig, granskas av den tillämpliga konfigurationskontrollmyndigheten. Utan en effektiv konfigurationskontrollprocess löper programkontoret risken att leverera CIs med konfigurationer som:

• är tekniskt otillräckliga och uppfyller inte angivna prestandakrav

• är inte logistiskt stödbara

• kan vara osäkert

• resulterar i bortkastade resurser, och

• ge inte en korrekt historisk rekord som grund för framtida förändringar.

som beskrivs i 6.1, konfigurationskontroll av baslinjekonfigurationsdokumentation är en integrerad förändringshanteringsprocess inklusive både utförande av aktivitet (i allmänhet en entreprenör) och uppgift (i allmänhet regeringen) ansvar för förändringsförberedelse, motivering, utvärdering, samordning, disposition och implementering. Genom konfigurationskontrollprocessen identifieras och redovisas den fulla effekten av föreslagna tekniska förändringar och avvikelser i deras implementering.

konfigurationskontrollprocessen utvecklas från en mindre formell process i de tidiga faserna av ett program till en mycket disciplinerad och formell process under systemutveckling och Demonstration, produktion och distribution samt drift-och Supportfaser . I konceptutforskningsfasen används konfigurationskontrollprocessen till stöd för systemteknik för att säkerställa att rätt version av dokument, som kommunicerar tekniska beslut eller definition av relevanta studieparametrar, sprids och används av all personal. Dessutom gör processen berörda parter medvetna om att en förändring utvecklas och gör det möjligt för dem att ge relevant input.

i koncept-och Teknikutvecklingsfasen (om tillämpligt), när programdefinitionsdokumenten utvecklas, är konfigurationskontrollprocessen också mindre formell. Som en del av systemteknik styrprocessen i denna fas, det kan finnas flera krav definition baslinjer som fastställts för att underlätta att säkerställa att alla programdeltagare är “på samma sida.”Ett konfigurationskontrollförfarande är till hjälp i denna fas för granskning och samordning av förändringar i de utvecklande systemnivåspecifikationerna. Det kan också tjäna till att upprätthålla regeringen / entreprenör informationsutbyte effektiv och hanterbar genom att tillhandahålla:

• identifiering, dokumentation, spridning och översyn av förändringar

• lämplig versionshantering av filer och revidering av dokument

• en release process för att säkerställa att varje revision / version återspeglar tillämpliga ändringar

under systemutveckling och Demonstration, produktion och distribution samt drift-och Supportfaser är en formell konfigurationskontrollprocess nödvändig. Den informella dokumentändringskontrollen som praktiserades under konceptutforskningar är otillräcklig för systemförvärv och upprätthållande. När produkten utvecklas och produceras fokuserar konfigurationskontrollen på dokumentationen som definierar prestanda, fysiska och funktionella egenskaper och produktens konfiguration. Konfigurationskontroll är en hanteringsprocess som använder kontraktsmässiga (statliga) och interna (entreprenör) konfigurationsbaslinjer som referenser för hantering av förändringar. Inom detta sammanhang finns det dock flera konfigurationskontrollkomplexitetsnivåer. När den ses på makronivå, som beskrivs av aktivitetsmodellerna (figurerna 6-1 till 6-4), processen:

• adresserar baslinjedokumentationen

• avgör vilka dokument som påverkas

• föreslår en förändring som täcker effekterna för alla berörda element, och

• anger när, var och av vem dokumentationen kommer att uppdateras och ändringen kommer att införlivas i produkten och i alla stödjande element.

medan denna makrovy på toppnivå verkar enkel och rakt framåt kan en mikronivåvy av konfigurationskontrollprocessen vara betydligt mer komplex. Mikrovyn avslöjar processskiktet som handlar om vad som måste göras för att ändra varje påverkat element, och därmed med en mängd olika överväganden som datarättigheter; godkännandemyndighet, dokumenthållare; design, release, produktion, installation och testorganisationer; avtals-och gränssnittsrelationer.

för att åstadkomma ändring av en produkt är det första steget att revidera de dokument som definierar produkten. Koncepten som diskuteras nedan underlättar genomförandet av detta steg med hjälp av automatiserade verktyg som en CM AIS. Denna handbok visar dessa begrepp från både programhantering (Makro) synvinkel och dokumentkontroll (mikro) synvinkel.

6.1.1.1 Nuvarande Myndighet.

på mikronivå, om en ECP som föreslår en ändring av en produkt påverkar flera dokument, måste ändringsförslaget, utvärderingen och genomförandet överväga:

• Vem är avtalsmyndigheten att godkänna en ECP? Detta är den produktkonfigurationskontrollmyndighet

• Vem har rätt att godkänna revidering av varje dokument som påverkas av en ECP? Detta är den nuvarande myndigheten för dokumentändring.

• krävs en relaterad ECP från en organisation för dokumentändringsmyndighet innan konfigurationskontrollmyndigheten för produkten kan godkänna en ECP för produkten?

• finns det andra statliga eller industriella aktiviteter involverade eftersom produkten har flera användare? Det här är applikationsaktiviteter. Är en utsedd lead application aktivitet?

en. Konfigurationskontrollmyndighet.

den avtalsenliga konfigurationskontrollmyndigheten som godkänner genomförandet av en ändring av en produkt (system/CI) kan initialt bo hos en entreprenör eller hos regeringen. Det kan överföra från entreprenören till regeringen, eller kan fortsätta att bo hos entreprenören under hela livscykeln för CI. Denna myndighet är tekniskt ansvarig för produktens prestanda samt skattemässigt ansvarig för finansieringsändringar av produkten.

nivån på Regeringskonfigurationskontroll bestäms vanligtvis som en del av CI-valet. Under ett förvärvsprogram är det de nivåer där regeringen specificerar, kontrakterar, accepterar och planerar att logistiskt stödja de enskilda komponenterna i ett system eller CIs. Regeringskonfigurationskontroll adresserar alltid den funktionella baslinjen och de tilldelade baslinjerna som fastställts för CIs på lägre nivå vars specifikationer har utfärdats av eller godkänts av regeringen . Liknande och relaterade contractor configuration control practices gäller även för CIs och komponenter under nivån för statlig konfigurationskontroll.

den avtalsenliga konfigurationskontrollmyndigheten tar upp den totala uppsättning dokument som baserar sig på den produkt som kontrolleras av den myndigheten för ett visst kontrakt. Denna myndighet kan vara den aktuella Myndigheten för Dokumentändring (CDCA), som beskrivs i b. nedan, för enskilda dokument som kräver ändring (t.ex. ett system eller CI-prestandaspecifikation). Om det inte är CDCA för ett visst dokument har det inte befogenhet att godkänna en föreslagen ändring av det dokumentet och måste därför begära ECP-godkännande från tillämplig CDCA eller välja en alternativ design.

b. aktuell Dokumentändringsmyndighet.

begreppet aktuell dokumentändringsmyndighet (CDCA är ett uttryck för en relation som alltid har funnits. Innan behovet av att hantera konfigurationsdokumentation med ett automatiserat informationssystem var detta koncept inte tydligt formulerat men förkroppsligades i termerna “Ursprungsdesignaktivitet” och “aktuell Designaktivitet.”Definitionen av dessa termer hänvisar emellertid specifikt till designdokument, t.ex. tekniska ritningar, i motsats till all dokumentation, och de inkluderar även frihetsberövande och designansvar.

CDCA avser å andra sidan specifikationer eller någon annan typ av dokument och är oberoende av den organisation som fysiskt underhåller och lagrar dokumentet. CDCA är den organisation som har beslutsmyndigheten över innehållet i dokumentet, vilket återspeglar äganderätt eller datarättigheter till den information som dokumentet innehåller. CDCA kan vara en statlig verksamhet eller en entreprenör, och myndigheten kan överföras. Det finns dock bara en CDCA för ett dokument åt gången.

scenarierna i rutan illustrerar logiken för CDCA-beteckning:

c. ansökan aktivitet.

det kan finnas flera konfigurationskontrollmyndigheter för en produkt med mer än en användare; var och en är en konfigurationskontrollmyndighet för ett visst kontrakt. Om konfigurationskontrollmyndigheten för ett kontrakt är CDCA för system / CI-Prestandaspecifikationen för produkten, betraktas de andra konfigurationskontrollmyndigheterna som applikationsaktiviteter eftersom deras auktoritet endast omfattar användningen av produkten och dess dokumentation. De kan inte tillåta ändring till antingen, men de kan delta i förändringskontrollprocessen om de begärs inmatning av antingen konfigurationskontrollmyndigheten som är CDCA eller av Regeringsledningsapplikationsaktiviteten.

det har alltid varit önskvärt för entreprenören att en artikel ska hanteras genom en enda regeringspunkt för samordning av förändringar. Ofta har detta inte varit fallet. Varje Regeringsaktivitet ansåg vanligtvis sin auktoritet avgörande och erkände inte alltid att det fanns flera ansökningsmyndigheter. Eftersom multipel användning av objekt fortsätter att spridas måste det finnas en enkel logisk metod för att skilja kontrollmyndighet från användningsmyndighet och att kommunicera och samordna förändringar som kan ha flera användningseffekter. Följande Applikationsaktivitetsbeteckningar används för detta ändamål:

• Application activity (AA) – en användare av ett dokument som inte är dess CDCA

• Government lead application authority (GLAA) – den statliga förvärvsaktiviteten som har utsetts till ledningen för förvärvet av objektet. När GLAA antar denna roll konsoliderar GLAA rekommendationer från alla statliga ansökningsaktiviteter och är den enda kontaktpunkten inom regeringen för samordning med regeringen/entreprenören CDCA.

6.1.1.2. Ändra Klassificering.

ändra klassificering är en stenografi metod för att indikera ändringen bearbetning och / eller godkännande metod. ECPs som krävs för att lämnas in till regeringen klassificeras som antingen klass i eller klass II. En klass i ECP är godkänd av regeringens Configuration Control Board och auktoriserad med en Kontraktsändring. En klass II-ändring, å andra sidan, granskas vanligtvis för samstämmighet vid klassificering av kommunrepresentanten, om inte annat anges i kontraktet. Om inte en regeringsrepresentant identifieras i kontraktet (normalt en person från upphandlingsverksamheten) är entreprenören (eller ECP-upphovsmannen) ansvarig för att tilldela ändringsklassificering. Liknande kriterier för ändringsklassificering finns i ANSI / EIA-649 där ändringsklassificeringarna kallas “större” och “mindre” förändringar..

i prestationsbaserat förvärv har definitionen av både klass i-och klass II-ändringar ändrats för att endast återspegla tillämpning på ändringar som påverkar myndighetsgodkänd (baslinje) konfigurationsdokumentation. Ändringar av entreprenörens grunddokumentation måste alla granskas av entreprenören för att avgöra om de också påverkar regeringens prestandakrav och stödaktiviteter.

klassificeringsfaktorerna gäller endast tekniska ändringar som föreslås för godkänd konfigurationsdokumentation. Även om att lägga till en redogörelse för arbetsuppgift (t.ex. en miljökonsekvensanalys) kan kräva en Kontraktsändring och kan leda till ökade kostnader för regeringen, anses det inte vara en klass i-teknisk förändring eftersom varken designen eller konfigurationsdokumentationen påverkas.

vid klassificering av en förändring måste hänsyn tas till mer än CI: s form, passform, funktion eller gränssnittsegenskaper. Alla ECP-klassificeringsfaktorer måste beaktas innan en ECP klassificeras. Faktorerna inkluderar många stöd -, operativa och utbildningshänsyn. Till exempel, om entreprenören är CDCA för kortets dokumentation, skulle en föreslagen designändring till ett elektroniskt kretskort inte vara en klass i-förändring av sig själv.. Men om redesignen kräver en ändring av automatisk testutrustning eller supportprogramvara som regeringen ansvarar för, måste ändringen klassificeras som en klass i ECP och behandlas i enlighet därmed. Det bör noteras att Klass I-förändringar av denna typ som felaktigt klassificeras som klass II eller anses inom entreprenörens CDCA-ansvar, kan leda till betydande operativa användnings-och/eller logistiska stödproblem och ökade kostnader för regeringen.

alla tillämpningar av det berörda ki måste beaktas vid klassificering av en förändring, t.ex. ECPs initierade mot en KI som tillverkas av mer än en entreprenör, en KI som har flera applikationer eller används av mer än en tasking (application) aktiviteter. Klassificeringskriterierna måste tillämpas på alla GEMENSKAPSINSTITUTS ansökningar genom samordning mellan de berörda verksamheterna.

6.1.1.3 konfiguration styrkort (CCB).

Statliga CCB är etablerade för större förvärvsprogram. (Entreprenörer använder också en liknande process för sin interna konfigurationskontroll.) CCB: er består vanligtvis av det gemensamma kommandot eller byråorganet som är chartrat för att agera på Klass I ECP: er och Begäran om större eller kritiska avvikelser. Programchefen är normalt ordförande för CCB och fattar beslut om alla ändringar som ställs inför CCB. CCB är en programhanteringsprocess som används av programchefen för att fastställa alla fördelar och effekter av förändringen innan beslutet fattas. När ett beslut fattas godkänner CCB: s ordförande ett CCB-direktiv, eller motsvarande brev/memorandum, med angivande av lämpliga genomförandeåtgärder som ska slutföras.

en. CCB myndighet.

varje CCB har en begränsad behörighet att godkänna ändringar baserat på följande faktorer:

• myndigheten kan begränsas av en högre nivå CCB, där det finns en hierarki av CCB på ett komplext projekt

• en CCB, inom en organisation som inte är CDCA för ett dokument, har inte befogenhet att godkänna en ändring av det dokumentet.

• om CDCA är den organisation som föreslog ändringen av CCB, godkänner CCB finansieringen och införlivandet av ändringen av produkten, medan CDCA godkänner ändringen av dokumentet. * Om en organisation som inte är CDCA för ett dokument föreslår en ändring av en CCB-organisation som inte heller är CDCA för dokumentet (dvs. en AA CCB), har AA CCB inte befogenhet att godkänna ändringen.

• AA CCB kan granska föreslagna ändringar och ge rekommendationer till CDCA. AA CCB kan bara besluta att anta (eller inte anta) en ändring som godkänts av CDCA.

• CCB-godkännande av en ECP måste ibland hållas kvar i avvaktan på godkännande av specifika dokumentändringar av Cdca: erna för dessa dokument

• CCB-godkännande kan ibland hållas kvar i väntan på mottagande av användarpositioner från alla myndigheter som indikerar att de kommer att anta ändringen. Som anges i 6.1.1.1.c, flera AA-positioner bör samordnas av en GLAA.

B. CCB-medlemskap.

medlemskapet i CCB består normalt av Nyckelfunktionella eller ämnesexperter från den statliga organisationen, t. ex. Integrerat Programteam (ipt). Medlemmarna är ansvariga för att ge råd till CCB-ordföranden. Annan funktionell personal kan inkluderas, vilket kan dikteras av förändrings-och/eller programkraven inklusive representanter från andra DoD-tjänster (för gemensamma serviceprogram) och andra länder (för multinationella program). CCB-medlemskap bör bestå av, men inte begränsas till representanter från logistik, utbildning, teknik, produktionshantering, kontrakt, konfigurationshantering och andra programrelaterade funktionella discipliner. CCB-medlemskap upprätthålls av CCB charter.

c. CCB Charter.

CCB-charter godkänns normalt genom regeringens upphandlande verksamhet officiella administrativa kanaler. Alla CCB-medlemmar måste vara närvarande vid varje CCB-möte och bör vara bekanta, ur sitt funktionella perspektiv, med de förändringar som övervägs. CCB-medlemmar är skyldiga att göra sina ståndpunkter kända för ordföranden och slutligen godkänna CCB-direktivet/beslutet(vid behov) och notera deras överenskommelse eller oenighet med beslutet. För att godkänna CCB-direktivet (CCBD) måste en person vara den primära (eller alternativa) CCB-medlemmen som utsetts av CCB-stadgan.

d. CCB operativa förfaranden.

UPPHANDLINGSVERKSAMHETENS CM-kontor bör publicera rutiner för CCB-drift så att alla medlemmar förstår dess betydelse för förvärvsprocessen. Ett CCB-sekretariat schemalägger möten, distribuerar dagordningar, registrerar CCB-beslut och distribuerar protokoll och direktiv till parter som tilldelas genomförandeåtgärder eller behöver veta. CCB: s operativa förfaranden bör också fastställa måltidstider för ECPs för att säkerställa personal, godkännande och genomförande i tid.

6.1.1.4 effektivitet.

effektiviteten hos en ECP identifierar kvantiteten eller intervallet av CIs som ska ändras, inklusive både produktionsintroduktion och eftermontering av levererade CIs. Inrättandet av ECP-effektivitet kräver att upphandlingsverksamheten beaktar sådana faktorer som följande:

• brådskande-korrigera en brist som involverar personalsäkerhet kan vara tillräckligt stor för att åsidosätta alla andra överväganden, även samtidigt stöd. Om driftsbegränsningar läggs på utrustning i avvaktan på en säkerhetsfråga kan operativ effektivitet begränsas kraftigt

• lager – delar och material till hands måste övervägas; ett beslut baserat på kostnader och operativa avvägningar måste göras antingen för att använda befintliga material till uttömning eller för att skrota nuvarande lager. Detta gäller både entreprenörens inventering samt statliga lager reservdelar och reservdelar

• konfigurationer – ett av de viktigaste konfigurationshanteringsmålen är att minimera antalet olika CI-konfigurationer som måste stödjas samtidigt, särskilt om de olika CI-konfigurationerna kräver annan eller uppdaterad operativ programvara, suppordutrustning, supportprogramvara, reservdelar, utbildning eller publikationer. Eftersom alla befintliga CI-konfigurationer inte ofta kan uppdateras samtidigt måste man noggrant överväga att antingen fördröja eller påskynda införlivandet av förändringen för att minimera påverkan. Att ställa in effektivitet för ett framtida definierat block av CIs kan vara en lösning. Kombinera eller förpacka ett antal programändringar i nästa version kan vara en annan, etc.

• ledtid – det finns många ledtider att tänka på när man identifierar effektiviteten för en förändring. De ledtider för tillverkning/upphandling som krävs för att slutföra engångskonstruktion, anskaffa delar och material och införliva förändringen både i produktion och / eller eftermontering måste beaktas. Den administrativa ledtiden som krävs för att behandla ändringen för godkännande är också av största vikt. Regeringen och entreprenören har ett ansvar för att undvika förseningar i förändringsbehandlingen, särskilt när det finns stora mängder av KI i produktion och i den operativa inventeringen som måste eftermonteras. Kostnaden för att fördröja ett beslut kan leda till att ytterligare föråldrade konfigurationer levereras som måste eftermonteras. Ofta är den återkommande kostnaden för att ersätta komponenter i produktionen bara att ersätta en enhet med lika eller lägre kostnad för en annan; medan eftermontering av samma förändring innebär kostnaden för båda enheterna, liksom extrakostnaden för demontering och utbyte.

• Timing-effektiviteten kan behöva väljas så att en viss operativ förmåga kommer att finnas tillgänglig vid en given tidpunkt eller för en specifik händelse, såsom en planerad utplacering av styrkor eller en övning.

tabell 6-1 ger en aktivitetsguide för utvärdering av en konfigurationskontrollprocess.

tabell 6-1. Aktivitetsguide: Configuration Control process Evaluation Checklist

klass II concurrence authority har delegerats till entreprenörer i många fall som ett resultat av single process initiative (SPI) förslag. Klass II-godkännandemyndigheten kan dock endast delegeras till entreprenörer för dokument för vilka de är CDCA

för korrekt tillämpning av denna information, se anmärkning på innehållssidan