MIL-HDBK – 61A: configuratie controle

< vorige / inhoud / volgende >

6.1 configuratie controle activiteit

configuratie controle is misschien wel het meest zichtbare element van configuratie beheer. Het is het proces dat wordt gebruikt door aannemers en overheidsinstellingen voor programma ‘ s om de voorbereiding, rechtvaardiging, evaluatie, coördinatie, dispositie en implementatie van voorgestelde technische wijzigingen en afwijkingen van uitgevoerde Configuratieitems (CIs) en basisconfiguratiedocumentatie te beheren.

het primaire doel van Configuratiebeheer is het opzetten en in stand houden van een systematisch veranderingsmanagementproces dat de levenscycluskosten reguleert, en:

• maakt optimale ontwerp-en ontwikkelingsvrijheid met de juiste mate, en diepte van configuratie verandering controle procedures tijdens de levenscyclus van een systeem/CI.

• biedt efficiënte verwerking en implementatie van configuratiewijzigingen die operationele paraatheid, ondersteuning, uitwisselbaarheid en interoperabiliteit behouden of verbeteren

• zorgt voor volledige, nauwkeurige en tijdige wijzigingen in de configuratiedocumentatie die worden onderhouden onder de juiste configuratiecontroleautoriteit

• elimineert onnodige verandering proliferatie

de span van configuratie controle begint voor de overheid zodra het eerste configuratie document is goedgekeurd en baselined. Dit gebeurt gewoonlijk wanneer de baseline voor functionele configuratie (de baseline voor vereisten in EIA/is-649 genoemd) wordt vastgesteld voor een systeem-of configuratieitem. Op dat moment worden complementaire overheids-en contractant change management procedures gebruikt om systematisch elke voorgestelde technische verandering of gevraagde afwijking in basisdocumentatie te evalueren, om de totale impact van verandering (inclusief kosten) te beoordelen door coördinatie met de betrokken functionele activiteiten, om de verandering of afwijking te verwijderen en tijdige goedkeuring of afkeuring te bieden, en om tijdige implementatie van goedgekeurde wijzigingen door beide partijen te verzekeren. Configuratie controle is een essentiële discipline gedurende de gehele levenscyclus van het programma. Figuur 6-1 illustreert een activiteitsmodel op het hoogste niveau van het configuratieproces. Het toont de configuratie controle proces verdeeld in drie segmenten, die worden gedetailleerd in de figuren 6-2, 6-3 en 6-4, respectievelijk.

het eerste segment, Government Configuration Control-Initiation, weerspiegelt het deel van het proces voorafgaand aan het verzoek van de overheid voor een contractant Engineering Change Proposal (ECP). Deze activiteit vindt plaats:

• Wanneer de noodzaak van een verandering is ontstaan door een Overheid activiteit (met inbegrip van het veld en activiteiten)

• Als gevolg van de inbreng van de aannemer die een Klasse I Wijziging van een door de Overheid gecontroleerde baseline is nodig

• Na de configuratie documentatie zal worden beïnvloed door de voorgestelde wijziging is goedgekeurd en is opgenomen in de huidige baseline gecontroleerd door de Overheid

Wijzigingen kunnen worden die nodig zijn voor een verscheidenheid van redenen, zoals om tegen de nieuwe dreiging, het invoegen van nieuwe technologie, en reageren op technische en operationele tests en evaluaties, of problemen oplossen. Zoals blijkt uit figuur 6-2, bevestigt de Overheidsactiviteit die verantwoordelijk is voor de configuratie controle de noodzaak van verandering, stelt zij drempels voor prestaties, kosten en tijdschema ‘ s voor de voorgestelde wijziging vast, stelt zij vast dat de wijziging technisch haalbaar en betaalbaar is (op basis van actuele informatie en contractorinterface, indien van toepassing), en stelt zij een verzoek op aan de contractant(s) om een ECP voor te bereiden. Een van de belangrijkste bijdragen aan de efficiëntie en effectiviteit van configuratie controle is duidelijke en beknopte communicatie tussen de overheid en de contractant voorafgaand aan de formele aanvraag voor ECP. Idealiter gebeurt dit in een geïntegreerde product team omgeving.

figuur 6-3, dat het tweede segment van figuur 6-1 weergeeft, modelleert het configuratiebeheerproces van de aannemer. Contractant configuration control wordt aangeroepen als de contractant elk item van de configuratie documentatie vrijmaakt. Uiteindelijk wordt de configuratie van de aannemer gecontroleerd op de volledige set configuratiedocumentatie, inclusief Basisconfiguratiedocumentatie van de overheid op het niveau van de prestaties of gedetailleerde specificatie, naargelang van toepassing, en de ontwerpoplossing die is belichaamd in technische modellen en tekeningen. De contractant reageert op ECP-verzoeken van de overheid en op intern gegenereerde aanvragen voor ontwerpwijzigingen of-afwijkingen (RFD). De contractant evalueert elke voorgestelde wijziging of afwijkingsaanvraag en documenteert het effect ervan op de ontwikkeling en de ondersteuning van de CI, bepaalt het vereiste niveau van toetsing en goedkeuring en zorgt ervoor dat de toepasselijke configuratiecontrolerende instantie een specifiek besluit neemt over de levensvatbaarheid van de wijziging voordat deze wordt uitgevoerd. ECP ‘s en RFD’ s die door de overheid moeten worden beoordeeld en/of goedgekeurd, worden doorgestuurd in overeenstemming met de contractuele vereisten. Het besluit tot goedkeuring van de wijziging wordt genomen door de overheid wanneer:

• de wijziging betrekking heeft op een vereiste van een basisdocument voor de configuratie van het prestatieniveau dat door de overheid wordt gecontroleerd, of

• een wijziging van een door de contractant gecontroleerd configuratiedocument heeft gevolgen voor gespecificeerde prestaties, ondersteunbaarheid en andere contractueel gespecificeerde vereisten met betrekking tot de CI en documentatie die door de overheid wordt gecontroleerd.

de contractant neemt de beslissing wanneer de wijziging betrekking heeft op items/configuratiedocumentatie waarvoor hij de configuratiecontrolerende autoriteit is, op voorwaarde dat deze wijzigingen geen invloed hebben op de basislijnen van de overheid.

figuur 6-4 modelleert het derde segment van figuur 6-1, dat het deel van het proces bestrijkt dat betrekking heeft op de beoordeling door de overheid en de beschikbaarheid van door de contractant ingediende ECP ‘s en RFD’ s. Het illustreert de beoordeling door vertegenwoordigers van de lokale overheid en de overeenstemming met wijzigingen van klasse II en kleine afwijkingen (wanneer een dergelijke actie contractueel vereist is) en de goedkeuring (of niet-goedkeuring) van wijzigingen van klasse I en belangrijke/kritieke afwijkingen. De overheidsconfiguratiecontroleactiviteit (meestal een secretariaat) bereidt zich voor op de configuratiecontrolecommissie door de voorgestelde wijziging te coördineren met alle betrokken partijen, door technische overeenstemming en kosten-en planningsverplichtingen te ontvangen en door de wijziging/afwijking op de kalender van de CCB te plaatsen (in overeenstemming met de bereidheid en de urgentie van de wijziging). De CCB evalueert vervolgens het voorstel en de uitvoeringsverbintenissen en keurt ze goed of keurt ze af in overeenstemming met het beleid van de aanbestedingsactiviteit. Als gevolg van het CCB-besluit wordt uitvoeringsrichting gegeven, meestal in de vorm van een CCB-richtlijn. De door de CCB gerichte acties omvatten zowel contractuele acties als opdrachten voor overheidsactiviteiten, voor zover van toepassing. Naar aanleiding van een CCB-Richtlijn bereidt het overheidsdienst voor overheidsopdrachten een wijziging van het contract voor en onderhandelt daarover om de contractant toestemming te geven om door te gaan met de implementatie van het goedgekeurde ECP van klasse I of belangrijke/kritische afwijking.

een effectief, goed gedefinieerd configuratiebeheerproces verzekert het government program office dat alle wijzigingen in door de overheid gecontroleerde basislijnen, ongeacht hoe klein of schijnbaar onbeduidend, worden beoordeeld door de toepasselijke configuratiecontrolerende Autoriteit. Zonder een effectief configuratiebeheerproces loopt het programmabureau het risico CIs te leveren met configuraties die:

• technisch ontoereikend zijn en niet voldoen aan gespecificeerde prestatie-eisen

• niet Logistiek ondersteunbaar zijn

• kan onveilig zijn

• leiden tot verspilling van middelen, en

• geef geen accurate historische gegevens als basis voor toekomstige veranderingen.

zoals beschreven onder 6.1, configuration control of baselined configuration documentation is een geïntegreerd veranderingsmanagementproces dat zowel het uitvoeren van activiteiten (over het algemeen een contractant) als het belasten van activiteiten (over het algemeen de overheid) verantwoordelijkheden voor de voorbereiding, rechtvaardiging, evaluatie, coördinatie, dispositie en implementatie van veranderingen omvat. Via het configuratiecontroleproces wordt de volledige impact van voorgestelde technische veranderingen en afwijkingen geïdentificeerd en in aanmerking genomen bij de implementatie ervan.

het configuratiebesturingsproces evolueert van een minder formeel proces in de vroege fasen van een programma naar een zeer gedisciplineerd en formeel proces tijdens de systeemontwikkelings-en demonstratie -, productie-en implementatiefase, en exploitatie-en ondersteuningsfase . In de conceptverkenningsfase wordt het configuratiecontroleproces gebruikt ter ondersteuning van de systeemengineering om ervoor te zorgen dat de juiste versie van documenten, die technische beslissingen of de definitie van relevante studieparameters communiceren, door al het personeel wordt verspreid en gebruikt. Bovendien maakt het proces de betrokken partijen ervan bewust dat er een verandering wordt ontwikkeld en stelt het hen in staat relevante input te leveren.

in de Concept-en Technologieontwikkelingsfase (indien van toepassing), wanneer de programmadefinitiedocumenten worden ontwikkeld, is het configuratiebeheerproces ook minder formeel. Als onderdeel van het systeem engineering controle proces in deze fase, kunnen er verschillende eisen definitie basislijnen vastgesteld voor het gemak om ervoor te zorgen dat alle deelnemers aan het programma zijn “op dezelfde pagina.”Een configuratiecontroleprocedure is nuttig in deze fase voor de herziening en coördinatie van wijzigingen in de zich ontwikkelende specificaties op systeemniveau. Het kan ook dienen om de overheid/contractant informatie-uitwisseling efficiënt en beheersbaar te houden door het verstrekken van:

• identificatie, documentatie, verspreiding en evaluatie van wijzigingen

• passende versiebeheer van bestanden en herziening van documenten

• een vrijgaveproces om ervoor te zorgen dat elke revisie / versie de toepasselijke wijzigingen weergeeft

tijdens de ontwikkelings-en demonstratie -, productie-en implementatiefase en de exploitatie-en ondersteuningsfase van het systeem is een formeel configuratieproces essentieel. De informele document Change control die werd uitgeoefend tijdens concept exploraties is onvoldoende voor het verwerven en ondersteunen van systemen. Terwijl het product wordt ontwikkeld en geproduceerd, richt configuration control zich op de documentatie die de prestaties, fysieke en functionele kenmerken en de configuratie van het product definieert. Configuration control is een managementproces met behulp van contractuele (overheid) en interne (contractant) configuratie basislijnen als referenties voor het beheren van veranderingen. Binnen deze context zijn er echter verschillende configuratiebesturingscomplexiteitsniveaus. Wanneer ze worden bekeken op het macro-niveau, zoals beschreven door de activiteit modellen (Cijfers 6-1 via 6-4), het proces:

• de Adressen van de baseline documentatie

• Bepaalt welke documenten worden beïnvloed

• Stelt een wijziging van de dekking van de gevolgen voor alle betrokken elementen, en

• Staten, wanneer, waar, en door wie de documentatie zal worden bijgewerkt en de wijziging zal worden opgenomen in het product en in alle ondersteunende elementen.

hoewel deze macroweergave op het hoogste niveau eenvoudig en eenvoudig lijkt, kan een weergave op microniveau van het configuratieproces aanzienlijk complexer zijn. De micro view onthult de proceslaag die handelt over wat er moet worden gedaan om elk betrokken element te veranderen, en dus met een breed scala aan overwegingen zoals gegevensrechten; goedkeuringsinstantie, document bewaarders; ontwerp -, release -, productie -, installatie-en testorganisaties; contractuele en interfacerelaties.

om een product te veranderen, is de eerste stap de herziening van de documenten die het product definiëren. De concepten die hieronder worden besproken vergemakkelijken de verwezenlijking van deze stap, met behulp van geautomatiseerde tools zoals een CM AIS. Dit handboek bekijkt deze concepten vanuit zowel programmamanagement (macro) als documentbeheer (micro) oogpunt.

6.1.1.1 Huidige Autoriteit.

op microniveau moeten, indien een ECP die een wijziging van een product voorstelt gevolgen heeft voor verschillende documenten, het wijzigingsvoorstel, de evaluatie en de uitvoering in overweging worden genomen.:

• Wie is de contractuele autoriteit om een ECP goed te keuren? Dit is de controleautoriteit voor de productconfiguratie

• Wie heeft het recht goedkeuring te verlenen voor de herziening van elk document waarop een ECP betrekking heeft? Dit is de huidige autoriteit voor het wijzigen van documenten.

• Is een gerelateerd ECP vereist van een document change authority organisatie voordat de configuratie control authority voor het product een ECP voor het product kan goedkeuren?

• zijn er andere overheids-of industriële activiteiten betrokken omdat het product meerdere gebruikers heeft? Dit zijn toepassingsactiviteiten. Is een aangewezen de lead applicatie activiteit?

a. controleautoriteit voor de configuratie.

de controlerende instantie voor contractuele configuratie die de uitvoering van een wijziging van een product (systeem/CI) goedkeurt, kan in eerste instantie bij een contractant of bij de overheid wonen. Zij kan van de contractant naar de overheid overgaan of gedurende de gehele levenscyclus van de CI bij de contractant blijven wonen. Deze autoriteit is technisch verantwoordelijk voor de prestaties van het product en fiscaal verantwoordelijk voor de financiering van wijzigingen aan het product.

het niveau van overheidsconfiguratiecontrole wordt over het algemeen bepaald als onderdeel van CI-selectie. Tijdens een acquisitie programma, het is de niveaus waarop de overheid specificeert, contracten voor, accepteert en plannen om logistieke ondersteuning van de afzonderlijke componenten van een systeem of CIs. Overheidsconfiguratiecontrole heeft altijd betrekking op de functionele basislijn en de toegewezen basislijnen die zijn vastgesteld voor CIs op lager niveau waarvan de specificaties zijn afgegeven door of goedgekeurd door de overheid . Soortgelijke en daarmee verband houdende procedures voor de controle van de configuratie van opdrachtgevers gelden ook voor CIs ‘ s en onderdelen die onder het niveau van de controle van de configuratie van de overheid liggen.

de controleautoriteit voor de configuratie van het contract heeft betrekking op de totale reeks documenten die zijn gebaseerd op het product dat door die autoriteit voor een specifiek contract wordt gecontroleerd. Deze autoriteit kan de huidige Document Change Authority (CDCA) zijn, beschreven onder b. hieronder, voor individuele documenten die wijziging vereisen (bijvoorbeeld een systeem of CI performance specification). Als het niet de CDCA voor een bepaald document is, heeft het niet de bevoegdheid om een voorgestelde wijziging van dat document goed te keuren, en moet het daarom ECP-goedkeuring vragen bij de toepasselijke CDCA, of een alternatief ontwerp selecteren.

B. autoriteit voor het wijzigen van documenten.

het concept van de huidige document change authority (CDCA is een uitdrukking van een relatie die altijd heeft bestaan. Vóór de noodzaak om configuratiedocumentatie te beheren met een geautomatiseerd informatiesysteem was dit concept niet duidelijk geformuleerd, maar belichaamd in de termen “oorspronkelijke ontwerpactiviteit” en “huidige ontwerpactiviteit.”Echter, de definitie van deze termen verwijzen specifiek naar ontwerpdocumenten, bijvoorbeeld engineering tekeningen, in tegenstelling tot alle documentatie, en ze omvatten ook bewaarder en ontwerp verantwoordelijkheid.

de CDCA daarentegen heeft betrekking op SPECIFICATIES of enig ander type document en is onafhankelijk van de organisatie die het document fysiek onderhoudt en opslaat. De CDCA is de organisatie die de beslissingsbevoegdheid heeft over de inhoud van het document, waarin eigendomsrechten of gegevensrechten op de informatie die het document bevat worden weergegeven. De CDCA kan een Overheidsactiviteit of een contractant zijn en de autoriteit kan worden overgedragen. Er is echter maar één CDCA voor een document per keer.

de scenario ‘ s in het kader illustreren de logica van CDCA-aanwijzing:

C. Toepassingsactiviteit.

voor een product met meer dan één gebruiker kunnen meerdere configuratiecontrole-instanties bestaan; elk van deze instanties is een configuratiecontrole-instantie voor een bepaald contract. Als de configuratiecontrolerende instantie voor één contract de CDCA is voor de systeem / CI-Prestatiespecificatie voor het product, worden de andere configuratiecontrolerende instanties beschouwd als toepassingsactiviteiten omdat hun bevoegdheid zich alleen uitstrekt tot het gebruik van het product en de documentatie ervan. Ze kunnen GEEN wijziging in een van beide toestaan, maar ze kunnen wel deelnemen aan het veranderingsbeheer als om input wordt gevraagd door de configuratiecontroleautoriteit die de CDCA is, of door de hoofdactiviteit van de overheid.

het is altijd wenselijk geweest dat de contractant een item via één enkel overheidsorgaan voor de coördinatie van wijzigingen afhandelt. Dit is vaak niet het geval geweest. Elke Overheidsactiviteit beschouwde hun autoriteit doorgaans als het belangrijkste en erkende niet altijd dat er meerdere applicatieautoriteiten waren. Aangezien meervoudig gebruik van items blijft toenemen, moet er een eenvoudige logische methode zijn om de controleautoriteit te onderscheiden van de gebruiksautoriteit, en om veranderingen die gevolgen kunnen hebben voor meervoudig gebruik te communiceren en te coördineren. Voor dit doel worden de volgende applicatie-Activiteitaanduidingen gebruikt:

• Application activity (AA) – een gebruiker van een document die niet zijn CDCA is

• overheid lead application authority (GLAA) – de overheid acquisitie activiteit die is aangewezen als de lead voor de overname van het item. Bij het aannemen van deze rol consolideert de GLAA aanbevelingen van alle applicatieactiviteiten van de overheid en is het enige aanspreekpunt binnen de overheid voor coördinatie met de overheid/contractant CDCA.

6.1.1.2. Wijzig De Classificatie.

de classificatie van wijzigingen is een afkorting voor de verwerking en/of goedkeuring van wijzigingen. ECP ‘ s die bij de overheid moeten worden ingediend, worden geclassificeerd als klasse I of klasse II. Een klasse I ECP is goedgekeurd door de Configuration Control Board van de overheid en goedgekeurd met een contractwijziging. Een klasse II-wijziging daarentegen wordt doorgaans herzien om de classificatie samen te vatten door de vertegenwoordiger van de lokale overheid, tenzij anders bepaald in het contract. Tenzij in het contract een overheidsvertegenwoordiger is vermeld (gewoonlijk een persoon van de aanbestedingsactiviteit), is de contractant (of ECP-opdrachtgever) verantwoordelijk voor het toekennen van de classificatie van wijzigingen. Soortgelijke criteria voor de classificatie van wijzigingen zijn opgenomen in ANSI/EIA-649, waar naar de classificaties van wijzigingen wordt verwezen als “belangrijke” en “kleine” wijzigingen..

bij prestatiegebaseerde acquisitie is de definitie van zowel klasse I als klasse II wijzigingen aangepast om alleen toepassing weer te geven voor wijzigingen die van invloed zijn op door de overheid goedgekeurde (basis) configuratiedocumentatie. Wijzigingen in de basisdocumentatie van de contractant moeten allemaal door de contractant worden beoordeeld om te bepalen of zij ook van invloed zijn op prestatie-eisen van de overheid en ondersteunende activiteiten.

de classificatiefactoren zijn alleen van toepassing op technische wijzigingen die worden voorgesteld in goedgekeurde configuratiedocumentatie. Hoewel het toevoegen van een werkstatement (zoals een milieu-effectanalyse) een wijziging van het contract kan vereisen en kan leiden tot hogere kosten voor de overheid, wordt dit niet beschouwd als een klasse I technische verandering omdat noch het ontwerp noch de configuratie documentatie wordt beïnvloed.

bij het classificeren van een wijziging moet rekening worden gehouden met meer dan de vorm -, pasvorm -, functie-of interfacekenmerken van de CI zelf. Alle ECP-classificatiefactoren MOETEN in aanmerking worden genomen voordat een ECP wordt geclassificeerd. De factoren omvatten veel ondersteuning, operationele, en opleiding overwegingen. Als de aannemer bijvoorbeeld CDCA is voor de documentatie van de kaart, zou een voorgestelde ontwerpwijziging van een elektronische circuitkaart op zichzelf geen klasse I-wijziging zijn.. Maar als het herontwerp een wijziging van automatische testapparatuur of ondersteuningssoftware vereist waarvoor de overheid verantwoordelijk is, moet de wijziging worden geclassificeerd als klasse I ECP en dienovereenkomstig worden verwerkt. Er zij op gewezen dat dit soort wijzigingen van klasse I die ten onrechte als klasse II worden geclassificeerd of onder de verantwoordelijkheid van de contractant worden beschouwd, kunnen leiden tot aanzienlijke operationele problemen en/of logistieke ondersteuningsproblemen en hogere kosten voor de overheid.

alle toepassingen van de betrokken CI MOETEN in aanmerking worden genomen bij het classificeren van een wijziging, bijvoorbeeld ECP ‘ s die zijn gestart tegen een CI die wordt vervaardigd door meer dan één contractant, een CI die meerdere toepassingen heeft of wordt gebruikt door meer dan één tasking (application) activiteiten. De classificatiecriteria moeten op alle CI-toepassingen worden toegepast via coördinatie tussen de betrokken activiteiten.

6.1.1.3 Configuration Control Board (CCB).

CCB ‘s van de overheid worden opgericht voor belangrijke acquisitieprogramma’ s. (Contractanten gebruiken ook een soortgelijk proces voor hun interne configuratie controle.) CCB ‘s bestaan gewoonlijk uit het gezamenlijke commando-of Agentschap dat is gecharterd om op te treden ten aanzien van klasse I ECP’ s en verzoeken om belangrijke of kritieke afwijkingen. De programmabeheerder is normaal gesproken de voorzitter van de CCB en neemt de beslissingen over alle wijzigingen die aan de CCB worden voorgelegd. De CCB is een programmabeheerproces dat door de programmabeheerder wordt gebruikt om alle voordelen en effecten van de wijziging vast te stellen voordat de beslissing wordt genomen. Wanneer een besluit wordt genomen, keurt de CCB-voorzitter een CCB-richtlijn of een gelijkwaardige brief/nota goed, waarin de nodige uitvoeringsmaatregelen worden vastgesteld.

a. CCB-Autoriteit.

elke CCB heeft een beperkte bevoegdheid om wijzigingen goed te keuren op basis van de volgende factoren::

• de autoriteit kan worden beperkt door een CCB op hoger niveau, wanneer er een hiërarchie van CCB ‘ s bestaat voor een complex project.

• een CCB binnen een organisatie die niet de CDCA voor een document is, heeft niet de bevoegdheid om een wijziging van dat document goed te keuren.

• als de CDCA de organisatie is die de wijziging aan de CCB heeft voorgesteld, keurt de CCB de financiering en integratie van de wijziging aan het product goed, terwijl de CDCA de wijziging aan het document goedkeurt. * Als een organisatie die niet de CDCA voor een document is een wijziging voorstelt aan een CCB-organisatie die ook niet de CDCA voor het document is (d.w.z. een AA CCB), heeft de AA CCB niet de bevoegdheid om de wijziging goed te keuren.

• AA-CCB ‘ s kunnen voorgestelde wijzigingen beoordelen en aanbevelingen doen aan de CDCA. De AA-CCB kan alleen besluiten een door de CDCA goedgekeurde wijziging goed te keuren (of niet goed te keuren).

• de CCB-goedkeuring van een ECP moet soms worden geweigerd in afwachting van de goedkeuring van specifieke documentwijzigingen door de CDCAs voor die documenten.

• de goedkeuring van de CCB kan soms worden geweigerd in afwachting van de ontvangst van gebruikersposities van alle overheden als indicatie dat zij de wijziging zullen aannemen. Zoals vermeld in 6.1.1.1.c, meerdere AA-posities moeten worden gecoördineerd door een GLAA.

b. CCB-lidmaatschap.

het lidmaatschap van de CCB bestaat gewoonlijk uit de belangrijkste functionele of thematische deskundigen van de overheidsorganisatie, bijv. Geïntegreerd programma Team (IPT). De leden zijn verantwoordelijk voor het adviseren van de voorzitter van de CCB. Ander functioneel personeel kan worden opgenomen, zoals kan worden gedicteerd door de verandering en / of programma eisen met inbegrip van vertegenwoordigers van andere DoD diensten (voor gezamenlijke service programma ‘s) en andere landen (voor multinationale programma’ s). Het CCB-lidmaatschap moet bestaan uit, maar niet beperkt zijn tot, vertegenwoordigers van logistiek, opleiding, engineering, productiebeheer, contracting, Configuratiebeheer en andere programmagerelateerde functionele disciplines. Het CCB-lidmaatschap wordt gehandhaafd door het CCB-Handvest.

c. CCB-Charter.

CCB-charters worden gewoonlijk goedgekeurd via de officiële administratieve kanalen van de overheidsaanbestedingsactiviteit. Alle CCB-leden moeten aanwezig zijn op elke CCB-vergadering en moeten vanuit hun functionele perspectief op de hoogte zijn van de wijzigingen die worden overwogen. CCB-leden zijn verplicht hun standpunt(en) bekend te maken aan de voorzitter; en uiteindelijk de CCB-richtlijn/ – beschikking goed te keuren (indien nodig), waarbij zij er nota van nemen dat zij het eens zijn met of het niet eens zijn met het besluit. Om de CCB-richtlijn goed te keuren, moet een persoon het primaire (of plaatsvervangende) CCB-lid zijn dat door het CCB-Handvest is aangewezen.

d. CCB-operationele procedures.

het CM-kantoor van de aanbestedingsactiviteit dient procedures voor de werking van de CCB te publiceren, zodat alle leden het belang ervan voor het aankoopproces begrijpen. Een secretariaat van de CCB plant vergaderingen, verspreidt agenda ‘ s, registreert besluiten van de CCB en distribueert notulen en richtlijnen aan partijen aan wie uitvoeringshandeling(en) is toegewezen of die dit moeten weten. In de operationele procedures van de CCB moeten ook streefverwerkingstijden voor ECP ‘ s worden vastgesteld om te zorgen voor tijdige personeelsbezetting, goedkeuring en implementatie.

6.1.1.4 effectiviteit.

de effectiviteit van een ECP identificeert de hoeveelheid of het bereik van KI ‘s die moeten worden gewijzigd, met inbegrip van zowel de opname in de productie als de retrofit van geleverde Ki’ s. De instelling van ECP-effectiviteit vereist dat de aanbestedingsactiviteit rekening houdt met factoren als de volgende::

• dringende correctie van een tekortkoming in verband met de veiligheid van het personeel kan significant genoeg zijn om alle andere overwegingen, zelfs gelijktijdige ondersteuning, te overstijgen. Als er operationele beperkingen worden gesteld aan apparatuur in afwachting van een oplossing van een veiligheidskwestie, kan de operationele effectiviteit streng worden beperkt

• inventaris – onderdelen en materialen die voorhanden zijn, moeten worden overwogen; er moet een besluit worden genomen op basis van kosten en operationele compromissen, hetzij om bestaande materialen te gebruiken om uitputting, hetzij om de huidige inventaris te schrappen. Dit geldt zowel voor de inventaris van opdrachtgevers als voor Reserve – en reparatieonderdelen

• configuraties-een van de belangrijkste doelstellingen van het Configuratiebeheer is het minimaliseren van het aantal verschillende CI-configuraties dat gelijktijdig moet worden ondersteund, met name als voor de verschillende CI-configuraties andere of bijgewerkte operationele software, ondersteuningsapparatuur, ondersteuningssoftware, reserveonderdelen, opleiding of publicaties nodig zijn. Aangezien alle bestaande CI-configuraties niet vaak gelijktijdig kunnen worden bijgewerkt, moet zorgvuldig worden overwogen om de integratie van de verandering uit te stellen of te versnellen om het effect te minimaliseren. Het instellen van effectiviteit op een toekomstig gedefinieerd blok van het CIs kan een oplossing zijn. Het combineren of verpakken van een aantal software veranderingen in de volgende versie kan een andere, enz.

• doorlooptijd – er zijn veel doorlooptijden te overwegen bij het identificeren van de effectiviteit voor een verandering. Er moet rekening worden gehouden met de productie-/inkooptijden die nodig zijn om eenmalige ontwerpinspanningen te voltooien, onderdelen en materialen aan te schaffen en de verandering zowel in productie als/of retrofit op te nemen. Ook de administratieve aanlooptijd die nodig is voor de verwerking van de wijziging ter goedkeuring is van het grootste belang. De overheid en de contractant dragen de verantwoordelijkheid om vertraging in de verwerking van wijzigingen te voorkomen, met name wanneer grote hoeveelheden van de CI in productie zijn en in de operationele inventaris die moeten worden aangepast. De kosten van het uitstellen van een beslissing kunnen ertoe leiden dat er extra achterhaalde configuraties worden geleverd die achteraf moeten worden geïnstalleerd. Vaak zijn de terugkerende kosten van het vervangen van onderdelen in de productie slechts de vervanging van een assemblage van gelijke of lagere kosten door een andere; terwijl de aanpassing van dezelfde verandering de kosten van beide assemblages, evenals de extra kosten van demontage en vervanging meebrengt.

• Timing – de effectiviteit moet mogelijk worden geselecteerd zodat een bepaalde operationele capaciteit beschikbaar is op een bepaald moment of voor een specifieke gebeurtenis, zoals een geplande inzet van troepen of een trainingsoefening.

tabel 6-1 geeft een activiteitsgids voor de evaluatie van een configuratiecontroleproces.

tabel 6-1. Gids Voor Activiteiten: Checklist voor de evaluatie van configuratiebeheerprocessen

klasse II-Mededingingsautoriteit is in veel gevallen gedelegeerd aan contractanten als gevolg van voorstellen voor single process initiative (SPI). Goedkeuringsinstantie van klasse II kan echter alleen aan contractanten worden gedelegeerd voor documenten waarvoor zij de CDCA

zijn voor een correcte toepassing van deze informatie, zie de opmerking op de inhoudsopgave