Konfigurationskontrolle – lassen Sie die Handschellen los!

Die zunehmend komplexe, globale Natur aller Unternehmen in allen Branchen und vertikalen Sektoren, gepaart mit Schnellfeuer-, “Internet-Zeit” -Geschäftsmodellen, treibt neue Schwerpunkte im Change Management. Die Fähigkeit, Veränderungen effektiv zu managen, entwickelt sich zu einem differenzierenden Schlüssel unter den Wettbewerbern, der es Unternehmen ermöglicht, Geschäftsmodelle und Produktlinien weiterzuentwickeln und schnell genug zu wechseln, um den Chancen der aktuellen Wirtschaft gerecht zu werden – vor der Konkurrenz.

Da Unternehmen Schwierigkeiten haben, Projekte in dieser Umgebung zu verwalten, ist das Konfigurationsmanagement (CM) zu einer zunehmend kritischen Komponente geworden und bietet einen Rahmen für das Management von Änderungen.

Die Disziplin CM besteht aus sechs Fachgebieten im Sinne von EIA-649 (ANSI, 2004))

• CM Planung und Management (CMPM),
• Konfiguration Identifikation (CI),
• Konfiguration Ändern Management (CCM),
• Konfiguration Status Accounting (CSA),
• Konfiguration Überprüfung & Audits (CVA), und
• CM von Digitalen Daten.

ISO 10007 (ISO, 2003) gruppiert CM jedoch in vier Klassifikationen:

• CI,
• Konfigurationskontrolle (CC),
• CSA und
• Konfigurationsprüfungen und -audits (R&A).

( CCM und CC sind für alle praktischen Zwecke identisch, ebenso wie CVA und R&A.)

Beachten Sie, dass die Konfigurationssteuerung in diesem Artikel beschrieben wird. Configuration Change Management und Change Control sind auch Begriffe, die verwendet werden, um den gleichen Prozess zu beschreiben.

Viele Projektmanager empfinden die Konfigurationskontrolle als Einschränkung und Beschränkung – Systeme, die die Produktentwicklung behindern sollen und sich normalerweise negativ auf den Zeitplan des Projekts auswirken. Leider werden zu oft generische CC-Prozesse, die für große, komplexe Programme wie die Entwicklung von Waffen oder medizinischen Systemen entwickelt wurden, anderen Arten von Projekten auferlegt. Diese Prozesse sind nicht auf die Bedürfnisse beispielsweise einer Webentwicklung oder eines Rollouts neuer Produkte zugeschnitten. Dies führt letztendlich zu intensiver Frustration mit dem CC–Prozess und dem “Handschellen” -Effekt – wo Prozesse, die nicht auf die Bedürfnisse des Programms zugeschnitten sind, den Fortschritt negativ beeinflussen.

Projektmanager implementieren die Konfigurationskontrolle, um Änderungen zu steuern und zu verfolgen. Die Prozesse sollen sicherstellen, dass die entsprechende Ebene zur Genehmigung von Änderungen verwendet wird und dass diese Änderungen auf den besten verfügbaren Informationen basieren. Die Prozesse bieten einen Rahmen für die Überprüfung von Änderungen. Auf diese Weise kann das Team beurteilen, ob die Implementierung der Änderung akzeptabel ist, und potenzielle Probleme rechtzeitig erkennen. Diese Prozesse ermöglichen eine Kalibrierung und gegebenenfalls eine weitere Revision.

Die eigentliche Frage ist nicht, ob die Konfigurationssteuerung implementiert werden soll, sondern welche Ebene der Konfigurationssteuerung implementiert werden soll. Eine Organisation kann für alle Projekte ein Konfigurationskontrollpaket “Unternehmensstandard” benötigen. Diese Art von System wird Projektteams häufig aufgrund mangelnder Konfigurationskontrolle und der daraus resultierenden finanziellen Auswirkungen auferlegt. Projektmanager, die erkennen, dass ein “One-Size-fits-all” -Ansatz nicht funktioniert, müssen nachweisen, dass geeignete Kontrollen vorhanden sind, um Fehler der Vergangenheit nicht zu wiederholen.

Konfigurationskontrolle in Aktion

Das typische Entwicklungsprojekt erfordert keinen Konfigurationskontrollprozess auf der Ebene eines großen Waffensystems. Es ist wichtig, das Team mit dem entsprechenden Maß an Flexibilität zu stärken und gleichzeitig sicherzustellen, dass ein System der gegenseitigen Kontrolle vorhanden ist. Der Schlüssel zu jedem System ist der Aufwand, der für die Dokumentation des Prozesses erforderlich ist, zusammen mit der Dokumentation, die für den Prozess erforderlich ist. Der unten beschriebene Beispiel-CC-Prozess wurde entwickelt, um die Anforderungen eines kleinen bis mittelgroßen Anwendungsentwicklungsprojekts zu erfüllen.

Das Projektteam sollte zunächst die geeignete Rolle der Konfigurationssteuerung für das Projekt analysieren. Dies würde zumindest bei einem Softwareprojekt das Thema der internen Dokumentation aller Codedateien und eine Art externer Dokumentation mit sich bringen. Weitere Bereiche, die abgedeckt werden müssen, sind Änderungsgenehmigungs- und Änderungsdokumentationsprozesse. Ein einfacher Konsens der Beteiligten sollte ausreichen. Natürlich ist ein strukturierter Vorstand, der regelmäßig einberufen wird, besser.

Lassen Sie uns nun auf die verschiedenen Aspekte des einfachen Konfigurationskontrollprozesses eingehen.

Dokumente

Der Configuration Management Plan (CMP) definiert den CC-Prozess. In einigen Anwendungen, in denen der CC-Prozess ziemlich detailliert ist, wird ein Konfigurationskontrollplan (CCP) entwickelt. In beiden Fällen werden alle Prozesse und Prozeduren abgedeckt, um die Konfigurationskontrolle durchzuführen.

Die Änderungsdokumentation selbst (später detailliert) muss genügend Informationen enthalten, die selbsterklärend sind, sodass keine zusätzlichen Informationen vom Urheber erforderlich sind. Dies ist erforderlich, da der Urheber möglicherweise zum Zeitpunkt der Implementierung der Änderung nicht verfügbar ist.

Prozess

Der CC-Prozess ist einfach (Abbildung 1). Eine Person hat eine Idee oder findet einen Fehler im aktuellen System. Diese Person sollte ihre Ergebnisse in einem Enterprise Change Request (ECR) dokumentieren, einem Formular, mit dem alle Fehler, Änderungen oder Verbesserungen für das jeweilige Projekt protokolliert werden. Die Änderungsanforderung wird zur Überprüfung an Peers und Supervisoren weitergeleitet und dann genehmigt und implementiert.

Abbildung 1 – Einfacher Konfigurationskontrollprozess

Änderungsdokumentation

Die Dokumentation von Änderungen ist der kritischste Teil eines Konfigurationskontrollsystems. Die Details der Dokumentation sind nicht so wichtig wie die zu dokumentierenden Informationen. Die dokumentierten Informationen müssen jedoch die Änderung beschreiben und mindestens die folgenden Informationen enthalten. Mindestanforderungen an die Dokumentation sind:

Je mehr Informationen in der Dokumentation enthalten sind, desto einfacher ist es natürlich, sie neu zu erstellen, wiederherzustellen, zu analysieren und zu korrigieren. Darüber hinaus hilft dies bei der endgültigen Dokumentation der Produktlieferung.

Wenn eine Person einen Fehler oder eine Anforderung im aktuellen Projekt entdeckt, dokumentiert sie die erforderliche Änderung. Eine Änderungsanforderung enthält Informationen zur Anforderung und beschreibt das Szenario, in dem der Fehler entdeckt wurde, wer ihn entdeckt hat, wann er entdeckt wurde, und empfohlene Korrekturen. Die Anforderung sollte nach Möglichkeit auch die betroffenen Konfigurationselemente identifizieren und einen Schweregrad- oder Prioritätscode angeben, um zu identifizieren, wann diese Änderung, falls genehmigt, erfolgen soll.

Änderungsgenehmigung

Änderungsgenehmigung sollte von einem designierten Projektleiter mit der “Big Picture” -Ansicht der Änderungsauswirkungen kommen. Ein Peer Review ist ein hochwirksames Mittel, um alle Facetten der Änderung zu überprüfen und sicherzustellen, dass alle von der Änderung betroffenen Bereiche angesprochen werden. Wenn der Kunde der Änderung zustimmt, wäre dies für Verbesserungen von Vorteil. In kleinen Entwicklungsprojekten sind die meisten Änderungen jedoch vom Typ “Bugfix” und der Kunde würde die Auswirkungen der Änderung nicht sehen.

Datenerfassung

Die Datenerfassung ist von entscheidender Bedeutung, um Informationen über ähnliche Elemente wiederherzustellen und Trends und Tendenzen zu entdecken. Diese Informationen sollten elektronisch gespeichert werden, was eine einfache Wiederherstellung von Daten und Datenmanipulation für Statusabrechnungen und Metriken ermöglicht. Die Informationen können verwendet werden, um einen “Lessons Learned” -Bericht zu erstellen, der zur technischen Verbesserung in einer Organisation verteilt wird.

Implementierung ändern.

Sobald alle entsprechenden Genehmigungen eingegangen sind, beginnt die Aufgabe der Implementierung. Tests in jedem Schritt der Implementierung stellen sicher, dass die Auswirkungen auf andere Aspekte des Programms minimal sind. Alle Tests sind abgeschlossen und die Änderung wird in das gesamte Programm implementiert.

Closed-Loop-Prozess

Ein Closed-Loop-Prozess, bei dem der Änderungsgeber das Endergebnis der Änderung kennt, bevor sie im Endprodukt angezeigt wird, ist eine Schlüsselkomponente für den Erfolg. Dies gilt für alle Arten von Branchen, von der Konstruktion über die Fertigung bis hin zur Software.

Bei diesem geschlossenen Prozess werden Steuerplatinen mit unterschiedlichen Rollen im Änderungsprozess eingerichtet (Abbildung 2). Jeder Vorstand ist verpflichtet, eine Änderung im vollen Kontext seiner Satzung zu überprüfen und für jede Änderung eine endgültige Entscheidung zu treffen. Natürlich kann der Vorstand zusätzliche Informationen benötigen, bevor er diese Entscheidung treffen kann, aber dies sollte minimal sein.

Das Institut für Konfigurationsmanagement (ICMHQ) lehrt die CMII (CMIIU) Methodik für das Konfigurationsmanagement und hat diese Sichtweise eines geschlossenen Veränderungsprozesses entwickelt. Dieser Vorgang beginnt und endet mit dem Endpunkt. Beachten Sie, dass die Verwaltung von Konfigurationsänderungen auf drei verschiedenen Ebenen innerhalb der Schleife angezeigt wird. Jeder Bereich ist anders definiert und hat spezifische Rollen und Verantwortlichkeiten.

• Technische Überprüfung – Stellt sicher, dass alle Detailbewertungen und Machbarkeitsanalysen vollständig sind.
• Das Change Review Board (CRB) – Bewertet die geschäftlichen Auswirkungen der Änderung. Gilt diese Änderung für unser Geschäftsumfeld? Erfüllt es eines unserer strategischen Ziele? Passt das in unsere Vision? Bei einer genehmigten Änderung kann der CRB einen Zeitrahmen für die Änderung angeben oder nicht, abhängig von Wettbewerbsprognosen und Geschäftsrisiken.
• Das Change Implementation Board (CIB) – Vergibt die erforderlichen Mittel und legt den Zeitrahmen für die Umsetzung von Änderungen fest. Dazu gehört auch die Zuweisung der Wirksamkeit für die Änderung, die angibt, wann die Änderung wirksam ist. Die Gültigkeit kann sich auf ein Datum beziehen, bauen, Seriennummer, oder Chargennummer. Dies hängt vom Endpunkt ab.

Die Fast-Track-Option der Schleife ist, wo der ganze Schmerz von CC freigegeben wird und die Besitzer können eine Änderung in Minuten im Vergleich zu Tagen genehmigt bekommen. Der Schlüssel dazu ist natürlich ein richtiger Dokumentationsbaum für jedes Produkt. Jedem Dokument muss ein Ersteller und Benutzer zugewiesen sein. Wenn sich die Änderungen nur auf die Low-Level-Dokumentation auswirken, ist Fast Track in Ordnung und die Änderung durchläuft den CC-Prozess.

Zusammenfassung

Der Schlüssel zu einem erfolgreichen Konfigurationskontrollprozess ist die Zustimmung des gesamten Projektteams. Die Teammitglieder sollten nicht aufgefordert werden, ihr fundiertes Urteilsvermögen und ihre Kontrolle zugunsten einer Managementinfrastruktur aufzugeben, die nicht den Anforderungen des jeweiligen Projekts entspricht. Konfigurationskontrollprozesse wurden entwickelt, um das Ausfallrisiko zu verringern und sicherzustellen, dass die Ergebnisse pünktlich und im Rahmen des Budgets erreicht werden. Wenn das Projektteam an der Einrichtung des ersten Konfigurationskontrollrahmens beteiligt ist, wird die Teilnahme und Akzeptanz im gesamten Projektteam beschleunigt und die etablierte Infrastruktur unterstützt die Geschäftsziele.