Konfigurationsmanagement

Agiles Änderungsmanagement reduziert Kosten und beschleunigt Verbesserungen

Änderungen beschleunigen, Korrekturkosten reduzieren. Auf diesen kurzen Nenner bringt Guido Weischedel das Prinzip eines professionellen Änderungsmanagements und stellt dessen beiden Kernbestandteile vor: Acht Regeln für klare, unmissverständliche Requirements und ein standardisierter Änderungsprozess. Mit dem CMII/IPE-Standard präsentiert der Autor ein agiles Änderungsverfahren, das mit seinen beiden Entscheidungswegen Änderungsanträge flexibel und effizient steuert.

Konfigurationsmanagement

Agiles Änderungsmanagement reduziert Kosten und beschleunigt Verbesserungen

Änderungen beschleunigen, Korrekturkosten reduzieren. Auf diesen kurzen Nenner bringt Guido Weischedel das Prinzip eines professionellen Änderungsmanagements und stellt dessen beiden Kernbestandteile vor: Acht Regeln für klare, unmissverständliche Requirements und ein standardisierter Änderungsprozess. Mit dem CMII/IPE-Standard präsentiert der Autor ein agiles Änderungsverfahren, das mit seinen beiden Entscheidungswegen Änderungsanträge flexibel und effizient steuert.

"Nur ein schlechter Plan erlaubt keine Änderung."
Publilius Syrus (1. Jhd. v. Chr., röm. Schriftsteller)

"Nichts ist so beständig wie der Wandel."
Heraklit (ca. 520 bis 460 v. Chr., griechischer Philosoph)

Es gibt zwei Arten von Änderungen an einem Produkt: Mängelbeseitigungen und Produktverbesserungen. Leider ist die Abgrenzung in der Praxis oft unscharf. In meiner langjährigen Tätigkeit als Trainer und Berater für Änderungsmanagement habe ich nur wenige Unternehmen gesehen, die konsequent zwischen Korrekturen und echten Verbesserungen unterscheiden. Die meisten werfen alles in den Topf "Änderungen" oder verwechseln das eine mit dem anderen.

Bei einem Unternehmen wurden z.B. Fehlerbeseitigungen intern als Verbesserungen gehandhabt mit dem Argument, der Kunde bekäme ja endlich das, was er von Anfang an hätte bekommen sollen: etwas Besseres. Viele Produktverantwortliche sehen es in der Natur der Sache, dass Fehler entstehen, die beseitigt werden müssen. Sie nehmen dies als unvermeidlich hin mit dem Argument, dass die Welt eben nicht perfekt sei und die Wettbewerber dieselben Probleme hätten. Dabei ignorieren sie, dass Fehlerbeseitigungen Kosten verursachen und Ressourcen binden, so dass weniger Freiraum für echte Produktverbesserungen bleibt. Es gilt also, Fehler zu vermeiden. Dies trifft umso mehr auf Projekte zu, bei denen Fehlerbeseitigungen das ohnehin schon knappe Budget zusätzlich belasten.

Ganz anders sieht dies bei Verbesserungen aus: Während Korrekturen Geld kosten, können Produkthersteller mit Verbesserungen Geld verdienen, da sie diese als Update oder als neues Produkt verkaufen können. In Projekten wiederum wird der Projektmanager eine Verbesserung nur dann durchführen, wenn der Auftraggeber das Budget um den dafür notwendigen Mehraufwand erhöht bzw. den entsprechenden Betrag aus dem Änderungsbudget freigibt. Es gibt somit sowohl für Produktmanager als auch für Projektmanager einen sehr wesentlichen Grund, bei Änderungen sauber zwischen Korrekturen und Verbesserungen zu unterscheiden: Korrekturen kosten Geld, Verbesserungen erhöhen Umsatz bzw. Budget.

Daraus ergeben sich drei Fragen:

  • Wie unterscheiden sich Korrekturen und Verbesserungen?
  • Wie kann ich Korrekturen vermeiden?
  • Wie kann ich Verbesserungen effizient managen?

Änderungen beschleunigen und Korrekturkosten reduzieren

Antworten auf alle mit Produktänderungen verbundenen Fragen liefert uns das Konfigurationsmanagement Konfigurationsmanagement als Teildisziplin des Qualitätsmanagements. Ein zentraler Bestandteil des Konfigurationsmanagements ist der Änderungsprozess. Dieser Prozess beschreibt, wie in einem Unternehmen oder einem Projekt über Änderungen aller Art entschieden wird und wie sie verwaltet werden. Ein international anerkannter Standard für den Änderungsprozess ist der vom US-amerikanischen CMII Research Institute gepflegte CMII-Prozess (Guess, 2013, siehe Info-Kasten). Auf Basis dieses Standards beschreibe ich in diesem Beitrag die zentralen Regeln, die ein professionelles Konfigurationsmanagement ermöglichen und stelle in einem kurzen Überblick den CMII-Prozess vor.

CMII/IPE

Das US-amerikanische CMII Research Institute (gegründet 1986 unter dem Namen Institute of Configuration Management) entwickelt und pflegt den CMII/IPE-Standard für Konfigurations- und Änderungsmanagement (Guess, 2013). Dabei steht "CM" für Configuration Management, "II" für die Zahl 2 und "IPE" für Integrated Process Excellence. Zentraler Inhalt von CMII/IPE ist ein agiles Verfahren für das Management von Änderungen. Sowohl Organisationen als auch Personen können sich nach CMII/IPE zertifizieren lassen. Weitere Informationen über CMII/IPE sind auf den Websites der autorisierten Trainingsprovider unter www.icmhq.com und www.gfkm.de erhältlich.

So unterscheiden Sie Korrekturen und Verbesserungen

Gemäß Duden sind die Begriffe "Korrektur" und "Verbesserung" allerdings synonym – "etwas korrigieren" ist gleichbedeutend mit "etwas verbessern". Dies hilft uns bei Produktmanagement und -entwicklung leider nicht weiter. Eine interpretationsfreie Definition zur Unterscheidung zwischen Korrekturen und Verbesserungen liefert uns der in Bild 1 dargestellte Entscheidungsbaum. Er führt uns durch vier einfache Entscheidungsfragen zur klaren Aussage, ob die betrachtete Änderung eine Korrektur oder eine Verbesserung ist. Es kann aber auch sein, dass es sich überhaupt nicht um eine Änderung im Sinne des Änderungsmanagements handelt – dies ist immer dann der Fall, wenn keine verbindlichen und dokumentierten Requirements für den betrachteten Gegenstand vorliegen.

Entscheidungsbaum

Bild 1: Entscheidungsbaum "Korrektur oder Verbesserung?".
Bild vergrößern

Bereits die erste Frage des Entscheidungsbaums: "Gibt es ein Ergebnis (z.B. Bauteil, Baugruppe, Software), welches mit dokumentierten Requirements übereinstimmen muss?" macht deutlich, dass es ohne verbindliche und dokumentierte Requirements gar keine Änderungen geben kann – es fehlt schlicht die Referenz. Erst danach ist die zweite Frage überhaupt sinnvoll, ob das betrachtete Ergebnis mit den Requirements übereinstimmt.

Wenn z.B. bei einem Haus der Grundriss vom genehmigten Bauplan abweicht oder wenn z.B. eine Software für Netzplantechnik den durch Normen definierten kritischen Weg falsch berechnet, dann führt uns der Entscheidungsbaum sofort dazu, dass hier ein Fehler vorliegt und eine Korrektur erforderlich ist. Diese Beurteilung ist sinnvoll, denn je später solche Mängel entdeckt werden, desto höher ist der Aufwand ihrer Behebung. Rückrufaktionen sind hierfür ein typisches, negatives Beispiel.

Die dritte und vierte Frage befassen sich mit Änderungen an den Requirements. Die weit verbreitete Meinung,…

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 8
Alle anzeigen