"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.

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.

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.