MIL-HDBK-61A: Konfigurationskontrolle

< Zurück /Inhalt /Weiter >

6.1 Konfigurationskontrollaktivität

Die Konfigurationskontrolle ist vielleicht das sichtbarste Element des Konfigurationsmanagements. Es ist der Prozess, der von Auftragnehmern und Regierungsprogrammbüros verwendet wird, um die Vorbereitung, Begründung, Bewertung, Koordination, Disposition und Implementierung vorgeschlagener technischer Änderungen und Abweichungen von den Configuration Items (CIs) und der Basisdokumentation zu verwalten.

Das primäre Ziel der Konfigurationskontrolle besteht darin, einen systematischen Änderungsmanagementprozess zu etablieren und aufrechtzuerhalten, der die Lebenszykluskosten reguliert, und:

• Ermöglicht einen optimalen Design- und Entwicklungsspielraum mit dem entsprechenden Grad und der Tiefe der Konfigurationsänderungssteuerungsverfahren während des Lebenszyklus eines Systems / CI.

• Bietet eine effiziente Verarbeitung und Implementierung von Konfigurationsänderungen, die die Betriebsbereitschaft, Unterstützung, Austauschbarkeit und Interoperabilität aufrechterhalten oder verbessern

• Gewährleistet vollständige, genaue und zeitnahe Änderungen der Konfigurationsdokumentation, die unter der entsprechenden Konfigurationskontrollbehörde verwaltet werden

• Eliminiert unnötige Änderungen.

Der Zeitraum der Konfigurationskontrolle beginnt für die Regierung, sobald das erste Konfigurationsdokument genehmigt und als Basis festgelegt wurde. Dies tritt normalerweise auf, wenn die funktionale Konfigurationsbasislinie (in EIA / IS-649 als Anforderungsbasislinie bezeichnet) für ein System oder ein Konfigurationselement festgelegt wird. Zu diesem Zeitpunkt werden ergänzende Verfahren für das Änderungsmanagement von Behörden und Auftragnehmern eingesetzt, um jede vorgeschlagene technische Änderung oder angeforderte Abweichung von der Basisdokumentation systematisch zu bewerten, die Gesamtauswirkungen der Änderung (einschließlich der Kosten) durch Abstimmung mit den betroffenen funktionalen Aktivitäten zu bewerten, die Änderung oder Abweichung zu bewerten und rechtzeitig zu genehmigen oder abzulehnen und die rechtzeitige Umsetzung genehmigter Änderungen durch beide Parteien sicherzustellen. Konfigurationskontrolle ist eine wesentliche Disziplin während des gesamten Programmlebenszyklus. Abbildung 6-1 zeigt ein Aktivitätsmodell der obersten Ebene des Konfigurationskontrollprozesses. Es zeigt den Konfigurationskontrollprozess, der in drei Segmente unterteilt ist, die in den Abbildungen 6-2, 6-3 und 6-4 beschrieben sind.

Das erste Segment, Government Configuration Control-Initiation, spiegelt den Teil des Prozesses wider, der der Regierungsanfrage nach einem Contractor Engineering Change Proposal (ECP) vorausgeht. Diese Aktivität tritt auf:

• Wenn die Notwendigkeit einer Änderung durch eine Regierungstätigkeit (einschließlich Feld- und Betriebsaktivitäten) verursacht wird)

• Aufgrund der Eingabe des Auftragnehmers ist eine Änderung der Klasse I zu einer von der Regierung kontrollierten Basislinie erforderlich

• Nachdem die Konfigurationsdokumentation, die von der vorgeschlagenen Änderung betroffen sein wird, genehmigt wurde und in die von der Regierung kontrollierte aktuelle Baseline aufgenommen wurde

Änderungen können aus verschiedenen Gründen erforderlich sein, z. B. um neuen Bedrohungen entgegenzuwirken, neue Technologien einzufügen und reagieren Sie auf technische und betriebliche Tests und Bewertungen oder beheben Sie Probleme. Wie in Abbildung 6-2 dargestellt, bestätigt die für die Konfigurationskontrolle zuständige Regierungsbehörde die Notwendigkeit von Änderungen, legt Schwellenwerte für Leistung, Kosten und Zeitplan für die vorgeschlagene Änderung fest, stellt fest, dass die Änderung technisch erreichbar und erschwinglich ist (gegebenenfalls auf der Grundlage aktueller Informationen und der Schnittstelle des Auftragnehmers), und bereitet eine Aufforderung an den Auftragnehmer vor, ein ECP vorzubereiten. Einer der wichtigsten Faktoren für die Effizienz und Effektivität der Konfigurationskontrolle ist die klare und präzise Kommunikation zwischen der Regierung und dem Auftragnehmer vor der formellen Anfrage nach ECP. Idealerweise geschieht dies in einer integrierten Produktteam-Umgebung.

Abbildung 6-3, die das zweite Segment von Abbildung 6-1 widerspiegelt, modelliert den Konfigurationskontrollprozess des Auftragnehmers. Die Konfigurationskontrolle des Auftragnehmers wird aufgerufen, wenn der Auftragnehmer jedes Element der Konfigurationsdokumentation freigibt. Letztendlich wird die Konfigurationskontrolle des Auftragnehmers auf den vollständigen Satz der Konfigurationsdokumentation angewendet, einschließlich der Basisdokumentation der Konfiguration auf der Leistungs- oder Detailspezifikationsebene, wie zutreffend, und der Konstruktionslösung, die in Konstruktionsmodellen und Zeichnungen verkörpert ist. Der Auftragnehmer reagiert auf behördliche ECP-Anfragen und auf intern generierte Anfragen nach Konstruktionsänderungen oder -abweichungen (RFD). Der Auftragnehmer bewertet jede vorgeschlagene Änderungs- oder Abweichungsanforderung und dokumentiert deren Auswirkungen auf die Entwicklung und Unterstützbarkeit des CI, bestimmt den erforderlichen Überprüfungs- und Genehmigungsgrad und stellt sicher, dass eine spezifische Entscheidung über die Durchführbarkeit der Änderung von der zuständigen Konfigurationskontrollbehörde getroffen wird, bevor sie implementiert wird. ECPs und RFDs, die einer staatlichen Überprüfung und / oder Genehmigung bedürfen, werden gemäß den vertraglichen Anforderungen weitergeleitet. Die Entscheidung über die Änderung wird von der Regierung getroffen, wenn:

• Die Änderung eine Anforderung eines von der Regierung kontrollierten Baselined Performance Level Configuration Document betrifft, oder

• Eine Änderung eines vom Auftragnehmer kontrollierten Konfigurationsdokuments hat Auswirkungen auf die spezifizierte Leistung, Unterstützbarkeit und andere vertraglich festgelegte Anforderungen an das CI und die Dokumentation, die von der Regierung kontrolliert werden.

Der Auftragnehmer trifft die Entscheidung, wann die Änderung an Artikeln / Konfigurationsdokumentationen vorgenommen wird, für die er die Konfigurationskontrollbehörde ist, sofern sich diese Änderungen nicht auf die Baselines der Regierung auswirken.

Abbildung 6-4 modelliert das dritte Segment von Abbildung 6-1, das den Teil des Prozesses abdeckt, der sich mit der Überprüfung und Disposition von vom Auftragnehmer eingereichten ECPs und RFDs durch die Regierung befasst. Es veranschaulicht die Überprüfung und Übereinstimmung lokaler Regierungsvertreter mit Änderungen und geringfügigen Abweichungen der Klasse II (sofern eine solche Maßnahme vertraglich erforderlich ist) und die Billigung (oder Nicht-Billigung) von Änderungen und wesentlichen / kritischen Abweichungen der Klasse I. Die Regierungskonfigurationskontrollaktivität (in der Regel ein Sekretariat) bereitet sich auf das Konfigurationskontrollgremium vor, indem sie die vorgeschlagene Änderung mit allen betroffenen Parteien koordiniert, technische Übereinstimmung sowie Kosten- und Zeitplanverpflichtungen erhält und die Änderung / Abweichung in den CCB-Kalender aufnimmt (in Übereinstimmung mit seiner Bereitschaft und der Dringlichkeit der Änderung). Der CCB überprüft dann den Vorschlag und die Umsetzungsverpflichtungen und genehmigt oder lehnt sie gemäß den Richtlinien der Beschaffungstätigkeit ab. Als Ergebnis der CCB-Entscheidung wird die Durchführungsrichtung angegeben, typischerweise in Form einer CCB-Richtlinie. Zu den vom CCB geleiteten Maßnahmen gehören sowohl vertragliche Maßnahmen als auch Aufträge für staatliche Aktivitäten, wie anwendbar. Als Reaktion auf eine CCB-Richtlinie bereitet das Government Contracting Office eine Vertragsänderung vor und verhandelt diese, um den Auftragnehmer zu ermächtigen, mit der Implementierung der genehmigten ECP-Klasse I oder der größeren / kritischen Abweichung fortzufahren.

Ein effektiver, klar definierter Konfigurationskontrollprozess gewährleistet dem Government Program Office, dass alle Änderungen an von der Regierung kontrollierten Baselines, egal wie klein oder scheinbar unbedeutend, von der zuständigen Konfigurationskontrollbehörde überprüft werden. Ohne einen effektiven Konfigurationskontrollprozess läuft das Programmbüro Gefahr, CIs mit Konfigurationen zu liefern, die:

• Technisch unzureichend sind und die festgelegten Leistungsanforderungen nicht erfüllen

• Logistisch nicht tragbar

• Kann unsicher sein

• Verschwendung von Ressourcen und

• Geben Sie keine genauen historischen Aufzeichnungen als Grundlage für zukünftige Änderungen an.

Wie in 6 beschrieben.1, Konfigurationskontrolle der Baselined Konfigurationsdokumentation ist ein integrierter Change-Management-Prozess, der sowohl die Durchführung von Aktivitäten (im Allgemeinen ein Auftragnehmer) als auch die Tasking-Aktivitäten (im Allgemeinen die Regierung) für die Vorbereitung, Begründung, Bewertung, Koordination, Disposition und Implementierung von Änderungen umfasst. Durch den Konfigurationskontrollprozess werden die vollen Auswirkungen der vorgeschlagenen technischen Änderungen und Abweichungen identifiziert und bei ihrer Implementierung berücksichtigt.

Der Konfigurationskontrollprozess entwickelt sich von einem weniger formalen Prozess in den frühen Phasen eines Programms zu einem sehr disziplinierten und formalen Prozess während der Systementwicklung und -demonstration, der Produktion und Bereitstellung sowie der Betriebs- und Supportphasen . In der Konzepterforschungsphase wird der Konfigurationskontrollprozess zur Unterstützung des Systems Engineering eingesetzt, um sicherzustellen, dass die korrekte Version von Dokumenten, die technische Entscheidungen oder die Definition relevanter Studienparameter kommunizieren, von allen Mitarbeitern verbreitet und verwendet wird. Darüber hinaus macht der Prozess betroffene Parteien darauf aufmerksam, dass eine Änderung entwickelt wird, und ermöglicht es ihnen, relevante Beiträge zu leisten.

In der Konzept- und Technologieentwicklungsphase (falls zutreffend), wenn die Programmdefinitionsdokumente entwickelt werden, ist der Konfigurationskontrollprozess auch weniger formal. Als Teil des Systems Engineering Control-Prozesses in dieser Phase können mehrere Anforderungsdefinitionsbasislinien festgelegt werden, um sicherzustellen, dass alle Programmteilnehmer “auf derselben Seite” sind.” Ein Konfigurationskontrollverfahren ist in dieser Phase hilfreich, um Änderungen an den sich entwickelnden Spezifikationen auf Systemebene zu überprüfen und zu koordinieren. Es kann auch dazu dienen, den Informationsaustausch zwischen Regierung und Auftragnehmer effizient und überschaubar zu halten, indem es Folgendes bereitstellt:

• Identifizierung, Dokumentation, Verbreitung und Überprüfung von Änderungen

• Angemessene Versionierung von Dateien und Überarbeitung von Dokumenten

• Ein Freigabeprozess, um sicherzustellen, dass jede Revision / Version die geltenden Änderungen widerspiegelt

Während der Phasen der Systementwicklung und -demonstration, der Produktion und Bereitstellung sowie des Betriebs und Supports ist ein formaler Konfigurationskontrollprozess unerlässlich. Die informelle Dokumentenänderungskontrolle, die während der Konzepterkundung praktiziert wurde, reicht für die Systemerfassung und -aufrechterhaltung nicht aus. Während der Entwicklung und Produktion des Produkts konzentriert sich die Konfigurationskontrolle auf die Dokumentation, die die Leistung, die physikalischen und funktionalen Eigenschaften und die Konfiguration des Produkts definiert. Die Konfigurationskontrolle ist ein Managementprozess, bei dem vertragliche (staatliche) und interne (Auftragnehmer-) Konfigurationsbasislinien als Referenzen für das Änderungsmanagement verwendet werden. In diesem Zusammenhang gibt es jedoch mehrere Komplexitätsstufen der Konfigurationssteuerung. Auf der Makroebene betrachtet, die durch die Aktivitätsmodelle (Abbildungen 6-1 bis 6-4) beschrieben wird, ist der Prozess:

• Adressiert die Baseline-Dokumentation

• Bestimmt, welche Dokumente betroffen sind

• Schlägt eine Änderung vor, die die Auswirkungen auf alle betroffenen Elemente abdeckt, und

• Gibt an, wann, wo und von wem die Dokumentation aktualisiert und die Änderung in das Produkt und alle unterstützenden Elemente aufgenommen wird.

Während diese Makroansicht auf oberster Ebene einfach und unkompliziert erscheint, kann eine Ansicht auf Mikroebene des Konfigurationskontrollprozesses erheblich komplexer sein. Die Mikroansicht zeigt die Prozessschicht, die sich mit dem befasst, was getan werden muss, um jedes betroffene Element zu ändern, und somit mit einer Vielzahl von Überlegungen wie Datenrechten; Genehmigungsbehörde, Dokumentenverwalter; Design-, Freigabe-, Produktions-, Installations- und Testorganisationen; Vertrags- und Schnittstellenbeziehungen.

Um Änderungen an einem Produkt vorzunehmen, ist der erste Schritt die Überarbeitung der Dokumente, die das Produkt definieren. Die unten diskutierten Konzepte erleichtern die Durchführung dieses Schritts mithilfe automatisierter Tools wie einem CM-AIS. Dieses Handbuch betrachtet diese Konzepte sowohl aus der Sicht des Programmmanagements (Makro) als auch aus der Sicht der Dokumentensteuerung (Mikro).

6.1.1.1 Aktuelle Autorität.

Wenn sich ein ECP, der eine Änderung an einem Produkt vorschlägt, auf mehrere Dokumente auswirkt, müssen der Änderungsvorschlag, die Bewertung und die Implementierung auf der Mikroebene berücksichtigt werden:

• Wer ist die Vertragsbehörde, um ein ECP zu genehmigen? Dies ist die produkt konfiguration control authority

• Wer hat das Recht, die Überarbeitung jedes von einem ECP betroffenen Dokuments zu genehmigen? Dies ist die aktuelle Dokumentänderungsberechtigung.

• Ist eine zugehörige ECP von einer Dokumentänderungsberechtigungsorganisation erforderlich, bevor die Konfigurationskontrollbehörde für das Produkt eine ECP für das Produkt genehmigen kann?

• Gibt es andere staatliche oder industrielle Aktivitäten, weil das Produkt mehrere Benutzer hat? Dies sind Anwendungsaktivitäten. Ist eine der Hauptanwendungsaktivitäten festgelegt?

a. Konfigurationskontrollbehörde.

Die vertragliche Konfigurationskontrollbehörde, die die Implementierung einer Änderung an einem Produkt (System / CI) genehmigt, kann zunächst bei einem Auftragnehmer oder bei der Regierung ansässig sein. Es kann vom Auftragnehmer an die Regierung übertragen werden, oder kann während des gesamten Lebenszyklus des CI weiterhin beim Auftragnehmer wohnen. Diese Behörde ist technisch verantwortlich für die Leistung des Produkts sowie steuerlich verantwortlich für die Finanzierung von Änderungen am Produkt.

Die Ebene der Regierungskonfigurationskontrolle wird im Allgemeinen als Teil der CI-Auswahl bestimmt. Während eines Akquisitionsprogramms sind es die Ebenen, auf denen die Regierung die einzelnen Komponenten eines Systems oder CIs festlegt, beauftragt, akzeptiert und plant, sie logistisch zu unterstützen. Die Konfigurationskontrolle der Regierung befasst sich immer mit der funktionalen Baseline und den zugewiesenen Baselines, die für CIs der unteren Ebene festgelegt wurden, deren Spezifikationen von der Regierung herausgegeben oder genehmigt wurden . Ähnliche und verwandte Praktiken zur Kontrolle der Auftragnehmerkonfiguration gelten auch für CIs und Komponenten unterhalb der Ebene der staatlichen Konfigurationskontrolle.

Die contractual Configuration Control Authority adressiert den gesamten Satz von Dokumenten, die für das von dieser Behörde kontrollierte Produkt für einen bestimmten Vertrag zugrunde gelegt werden. Diese Behörde kann die aktuelle Dokumentänderungsbehörde (CDCA) sein, die in b. unten beschrieben ist, für einzelne Dokumente, die eine Änderung erfordern (z. B. eine System- oder CI-Leistungsspezifikation). Wenn es sich nicht um die CDCA für ein bestimmtes Dokument handelt, ist es nicht befugt, eine vorgeschlagene Änderung an diesem Dokument zu genehmigen, und muss daher die ECP-Genehmigung der zuständigen CDCA einholen oder ein alternatives Design auswählen.

b. Aktuelle Dokumentänderungsberechtigung.

Das Konzept der Current Document Change Authority (CDCA) ist Ausdruck einer Beziehung, die schon immer existiert hat. Vor der Notwendigkeit, die Konfigurationsdokumentation mit einem automatisierten Informationssystem zu verwalten, war dieses Konzept nicht klar formuliert, sondern wurde in den Begriffen “Ursprüngliche Entwurfsaktivität” und “Aktuelle Entwurfsaktivität” verkörpert.” Die Definition dieser Begriffe bezieht sich jedoch speziell auf Konstruktionsdokumente, z. B. Konstruktionszeichnungen, im Gegensatz zu allen Dokumentationen, und sie umfassen auch die Verwahrung sowie die Konstruktionsverantwortung.

Der CDCA hingegen bezieht sich auf Spezifikationen oder andere Arten von Dokumenten und ist unabhängig von der Organisation, die das Dokument physisch verwaltet und speichert. Die CDCA ist die Organisation, die die Entscheidungsbefugnis über den Inhalt des Dokuments hat und die Eigentums- oder Datenrechte an den Informationen widerspiegelt, die das Dokument enthält. Die CDCA kann eine staatliche Tätigkeit oder ein Auftragnehmer sein, und die Behörde kann übertragen werden. Es gibt jedoch jeweils nur einen CDCA für ein Dokument.

Die Szenarien in der Box veranschaulichen die Logik der CDCA-Bezeichnung:

c. Anwendung Aktivität.

Es kann mehrere Konfigurationskontrollbehörden für ein Produkt mit mehr als einem Benutzer geben; jede ist eine Konfigurationskontrollbehörde für einen bestimmten Vertrag. Wenn die Konfigurationskontrollbehörde für einen Vertrag die CDCA für die System- / CI-Leistungsspezifikation für das Produkt ist, gelten die anderen Konfigurationskontrollbehörden als Anwendungstätigkeiten, da sich ihre Befugnisse nur auf die Verwendung des Produkts und seiner Dokumentation erstrecken. Sie können Änderungen an beiden nicht autorisieren, können jedoch am Änderungssteuerungsprozess teilnehmen, wenn sie entweder von der Konfigurationskontrollbehörde, der CDCA, oder von der von der Regierung geleiteten Anwendungsaktivität zur Eingabe aufgefordert werden.

Es war für den Auftragnehmer immer wünschenswert, dass ein Gegenstand über eine einzige Regierungsstelle zur Koordinierung von Änderungen behandelt wurde. Oft war dies nicht der Fall. Jede Regierungstätigkeit betrachtete ihre Autorität in der Regel als vorrangig und erkannte nicht immer an, dass es mehrere Antragsbehörden gab. Da die Mehrfachnutzung von Gegenständen weiter zunimmt, muss es eine einfache logische Methode geben, um die Kontrollbehörde von der Nutzungsbehörde zu unterscheiden und Änderungen zu kommunizieren und zu koordinieren, die Auswirkungen auf die Mehrfachnutzung haben können. Zu diesem Zweck werden die folgenden Bezeichnungen für die Anwendungsaktivität verwendet:

• Anwendungsaktivität (AA) – ein Benutzer eines Dokuments, der nicht dessen CDCA ist

• Government Lead Application Authority (GLAA) – die staatliche Akquisitionsaktivität, die als Lead für den Erwerb des Artikels bestimmt wurde. Bei der Übernahme dieser Rolle konsolidiert die GLAA Empfehlungen aus allen Regierungsanwendungsaktivitäten und ist die zentrale Anlaufstelle innerhalb der Regierung für die Koordination mit der Regierung / dem Auftragnehmer CDCA.

6.1.1.2. Klassifizierung ändern.

Änderungsklassifizierung ist eine Kurzform zur Angabe der Änderungsbearbeitungs- und/oder Genehmigungsmethode. ECPs, die der Regierung vorgelegt werden müssen, werden entweder als Klasse I oder Klasse II eingestuft. Ein ECP der Klasse I wird vom Configuration Control Board der Regierung genehmigt und mit einer Vertragsänderung autorisiert. Eine Änderung der Klasse II hingegen wird in der Regel vom Vertreter der lokalen Regierung auf Übereinstimmung bei der Klassifizierung überprüft, sofern im Vertrag nichts anderes angegeben ist. Sofern im Vertrag kein Regierungsvertreter angegeben ist (normalerweise eine Person aus der Beschaffungstätigkeit), ist der Auftragnehmer (oder der ECP-Urheber) für die Zuordnung der Änderungsklassifizierung verantwortlich. Ähnliche Kriterien für die Änderungsklassifizierung sind in ANSI / EIA-649 enthalten, wo die Änderungsklassifizierungen als “wesentliche” und “geringfügige” Änderungen bezeichnet werden..

In Performance based Acquisition wurde die Definition von Klasse-I- und Klasse-II-Änderungen dahingehend geändert, dass sie nur auf Änderungen angewendet werden, die sich auf die von der Regierung genehmigte (Basis-) Konfigurationsdokumentation auswirken. Änderungen an der Basisdokumentation des Auftragnehmers müssen alle vom Auftragnehmer überprüft werden, um festzustellen, ob sie sich auch auf die staatlichen Leistungsanforderungen und Supportaktivitäten auswirken.

Die Klassifizierungsfaktoren gelten nur für technische Änderungen, die in der genehmigten Konfigurationsdokumentation vorgeschlagen werden. Obwohl das Hinzufügen einer Arbeitsanweisung (z. B. einer Umweltverträglichkeitsanalyse) möglicherweise eine Vertragsänderung erfordert und zu höheren Kosten für die Regierung führen kann, wird dies nicht als technische Änderung der Klasse I angesehen, da weder das Design noch die Konfigurationsdokumentation betroffen sind.

Bei der Klassifizierung einer Änderung müssen nicht nur Form, Passform, Funktion oder Schnittstellenmerkmale des CI selbst berücksichtigt werden. Alle ECP-Klassifizierungsfaktoren müssen vor der Klassifizierung eines ECP berücksichtigt werden. Die Faktoren umfassen viele Support-, Betriebs- und Schulungsüberlegungen. Wenn der Auftragnehmer beispielsweise CDCA für die Dokumentation der Karte ist, wäre eine vorgeschlagene Entwurfsänderung an einer elektronischen Schaltungskarte keine Änderung der Klasse I an sich.. Wenn die Neugestaltung jedoch eine Änderung an automatischen Testgeräten oder Support-Software erfordert, für die die Regierung verantwortlich ist, muss die Änderung als ECP der Klasse I eingestuft und entsprechend verarbeitet werden. Es ist zu beachten, dass Änderungen der Klasse I dieser Art, die fälschlicherweise als Klasse II eingestuft werden oder in die Verantwortung des Auftragnehmers fallen, zu erheblichen Problemen bei der Betriebsnutzung und / oder logistischen Unterstützung und erhöhten Kosten für die Regierung führen können.

Bei der Klassifizierung einer Änderung müssen alle Anwendungen des betroffenen CI berücksichtigt werden, z. B. ECPs, die gegen ein CI eingeleitet werden, das von mehr als einem Auftragnehmer hergestellt wird, ein CI, das mehrere Anwendungen hat oder von mehr als einer Tasking- (Anwendungs-) Aktivität verwendet wird. Die Klassifizierungskriterien müssen auf alle CI-Anwendungen angewendet werden, indem die betroffenen Aktivitäten koordiniert werden.

6.1.1.3 Konfiguration Control Board (CCB).

Staatliche CCBs werden für große Akquisitionsprogramme eingerichtet. (Auftragnehmer wenden auch einen ähnlichen Prozess für ihre interne Konfigurationskontrolle an. CCBs bestehen in der Regel aus dem Joint Command oder der Agentur, die gechartert wurde, um auf ECPs der Klasse I und Anfragen nach größeren oder kritischen Abweichungen zu reagieren. Der Programmmanager ist normalerweise der Vorsitzende des CCB und trifft die Entscheidungen über alle Änderungen, die dem CCB vorgelegt werden. Der CCB ist ein Programmverwaltungsprozess, der vom Programmmanager verwendet wird, um alle Vorteile und Auswirkungen der Änderung zu ermitteln, bevor die Entscheidung getroffen wird. Wenn eine Entscheidung getroffen wird, genehmigt der CCB-Vorsitzende eine CCB-Richtlinie oder ein gleichwertiges Schreiben / Memorandum, in dem die entsprechenden Durchführungsmaßnahmen angeordnet werden.

a. CCB-Behörde.

Jeder CCB hat eine begrenzte Befugnis, Änderungen basierend auf den folgenden Faktoren zu genehmigen:

• Die Befugnis kann durch ein übergeordnetes CCB eingeschränkt sein, bei dem es eine Hierarchie von CCBs für ein komplexes Projekt gibt

• Ein CCB innerhalb einer Organisation, die nicht die CDCA für ein Dokument ist, ist nicht befugt, eine Änderung an diesem Dokument zu genehmigen.

• Wenn es sich bei der CDCA um die Organisation handelt, die die Änderung des CCB vorgeschlagen hat, genehmigt der CCB die Finanzierung und Aufnahme der Änderung in das Produkt, während die CDCA die Änderung des Dokuments genehmigt. * Wenn eine Organisation, die nicht der CDCA für ein Dokument ist, eine Änderung an eine CCB-Organisation vorschlägt, die auch nicht der CDCA für das Dokument ist (d. h. ein AA CCB), ist der AA CCB nicht befugt, die Änderung zu genehmigen.

• AA CCBs können vorgeschlagene Änderungen überprüfen und Empfehlungen an die CDCA richten. Der AA CCB kann nur beschließen, eine von der CDCA genehmigte Änderung anzunehmen (oder nicht anzunehmen).

• Die CCB-Genehmigung eines ECP muss manchmal bis zur Genehmigung bestimmter Dokumentänderungen durch die CDCAs für diese Dokumente zurückgehalten werden

• Die CCB-Genehmigung kann manchmal bis zum Erhalt der Benutzerpositionen von allen Behörden zurückgehalten werden, um anzuzeigen, dass sie die Änderung übernehmen werden. Wie in 6.1.1.1 angegeben.c, mehrere AA-Positionen sollten von einer GLAA koordiniert werden.

b. CCB-Mitgliedschaft.

Die Mitglieder des CCB setzen sich in der Regel aus den wichtigsten funktionalen oder fachlichen Experten der Regierungsorganisation zusammen, z. Integriertes Programmteam (IPT). Die Mitglieder sind für die Beratung des CCB-Vorsitzenden verantwortlich. Anderes funktionales Personal kann einbezogen werden, wie es durch die Änderung und / oder die Programmanforderungen vorgegeben wird, einschließlich Vertretern anderer DoD-Dienste (für gemeinsame Serviceprogramme) und anderer Länder (für multinationale Programme). Die CCB-Mitgliedschaft sollte aus Vertretern der Logistik, der Ausbildung, des Ingenieurwesens, des Produktionsmanagements, des Vertragswesens, des Konfigurationsmanagements und anderer programmbezogener Funktionsdisziplinen bestehen, ist jedoch nicht darauf beschränkt. Die CCB-Mitgliedschaft wird durch die CCB-Charta aufrechterhalten.

c. CCB-Charta.

CCB-Urkunden werden normalerweise über die offiziellen Verwaltungswege der Beschaffungstätigkeit der Regierung genehmigt. Alle CCB-Mitglieder müssen bei jeder CCB-Sitzung anwesend sein und sollten aus ihrer funktionalen Perspektive mit den in Betracht gezogenen Änderungen vertraut sein. CCB-Mitglieder sind verpflichtet, ihre Position (en) dem Vorsitzenden bekannt zu geben; und letztendlich die CCB-Richtlinie / -Anordnung (falls erforderlich) zu genehmigen, wobei sie ihre Zustimmung oder Nichtübereinstimmung mit der Entscheidung zur Kenntnis nehmen. Um die CCB-Richtlinie (CCBD) zu genehmigen, muss eine Person das primäre (oder alternative) CCB-Mitglied sein, das von der CCB-Charta benannt wurde.

d. CCB Betriebsverfahren.

Das CM-Büro der Beschaffungstätigkeit sollte Verfahren für den CCB-Betrieb veröffentlichen, damit alle Mitglieder dessen Bedeutung für den Akquisitionsprozess verstehen. Ein CCB-Sekretariat plant Sitzungen, verteilt Tagesordnungen, zeichnet CCB-Entscheidungen auf und verteilt Protokolle und Richtlinien an Parteien, denen Durchführungsmaßnahmen zugewiesen sind oder die dies wissen müssen. Die CCB-Betriebsverfahren sollten auch Zielbearbeitungszeiten für ECPs festlegen, um eine rechtzeitige Besetzung, Genehmigung und Umsetzung zu gewährleisten.

6.1.1.4 Wirksamkeit.

Die Wirksamkeit eines ECP gibt die Menge oder den Bereich der CIs an, die geändert werden sollen, einschließlich der Produktionseingliederung und der Nachrüstung der gelieferten CIs. Die Feststellung der ECP-Wirksamkeit erfordert, dass die Beschaffungstätigkeit folgende Faktoren berücksichtigt:

* Dringlichkeit – Die Behebung eines Mangels, der die Sicherheit des Personals betrifft, kann erheblich genug sein, um alle anderen Überlegungen außer Kraft zu setzen, auch die gleichzeitige Unterstützung. Wenn Geräte bis zur Behebung eines Sicherheitsproblems Betriebseinschränkungen unterliegen, kann die betriebliche Wirksamkeit stark eingeschränkt sein

* Inventar – Teile und Materialien müssen berücksichtigt werden. Dies gilt sowohl für den Auftragnehmerbestand als auch für von der Regierung gelagerte Ersatz- und Reparaturteile

• Konfigurationen – Eines der wichtigsten Ziele des Konfigurationsmanagements besteht darin, die Anzahl der verschiedenen CI-Konfigurationen zu minimieren, die gleichzeitig unterstützt werden müssen, insbesondere wenn die verschiedenen CI-Konfigurationen unterschiedliche oder aktualisierte Betriebssoftware, Support-Ausrüstung, Support-Software, Ersatzteile, Schulungen oder Veröffentlichungen erfordern. Da häufig nicht alle vorhandenen CI-Konfigurationen gleichzeitig aktualisiert werden können, muss sorgfältig überlegt werden, ob die Aufnahme der Änderung verzögert oder beschleunigt werden soll, um die Auswirkungen zu minimieren. Das Festlegen der Wirksamkeit auf einen zukünftigen definierten Block des CIs kann eine Lösung sein. Das Kombinieren oder Verpacken einer Reihe von Softwareänderungen in die nächste Version kann eine andere usw. sein.

• Vorlaufzeit – Es gibt viele Vorlaufzeiten, die bei der Ermittlung der Wirksamkeit einer Änderung zu berücksichtigen sind. Die Fertigungs- / Beschaffungsvorlaufzeiten, die erforderlich sind, um den einmaligen Konstruktionsaufwand abzuschließen, Teile und Materialien zu beschaffen und die Änderung sowohl in die Produktion als auch in die Nachrüstung einzubeziehen, müssen berücksichtigt werden. Die administrative Vorlaufzeit, die für die Bearbeitung der Änderung zur Genehmigung erforderlich ist, ist ebenfalls von größter Bedeutung. Die Regierung und der Auftragnehmer tragen die Verantwortung, Verzögerungen bei der Änderungsabwicklung zu vermeiden, insbesondere wenn sich große Mengen des CI in der Produktion und im Betriebsinventar befinden, die nachgerüstet werden müssen. Die Kosten für die Verzögerung einer Entscheidung können dazu führen, dass zusätzliche veraltete Konfigurationen geliefert werden, die nachgerüstet werden müssen. Häufig sind die wiederkehrenden Kosten für den Austausch von Komponenten in der Produktion lediglich der Ersatz einer Baugruppe mit gleichen oder niedrigeren Kosten für eine andere; während die Nachrüstung derselben Baugruppe die Kosten beider Baugruppen sowie die zusätzlichen Kosten für die Demontage und den Austausch mit sich bringt.

• Timing – Die Effektivität muss möglicherweise so gewählt werden, dass eine bestimmte Einsatzfähigkeit zu einem bestimmten Zeitpunkt oder für ein bestimmtes Ereignis wie einen geplanten Einsatz von Streitkräften oder eine Trainingsübung verfügbar ist.

Tabelle 6-1 enthält einen Aktivitätsleitfaden für die Bewertung eines Konfigurationskontrollprozesses.

Tabelle 6-1. Aktivitätenführer: Checkliste zur Bewertung des Konfigurationskontrollprozesses

Die Concurrence Authority der Klasse II wurde in vielen Fällen als Ergebnis von Vorschlägen der Single Process Initiative (SPI) an Auftragnehmer delegiert. Die Genehmigungsbehörde der Klasse II kann jedoch nur an Auftragnehmer für Dokumente delegiert werden, für die sie die CDCA sind

Zur korrekten Anwendung dieser Informationen siehe HINWEIS auf der Inhaltsseite