“There are no problems, only solutions” – John Lennon
Auf der dritten Reifestufe des CMMI ist es soweit: Ein übergreifendes Prozessmodell muss definiert werden. Diese Herausforderung hat interessante Aspekte, zum Beispiel: Wie sieht ein „definierter“ Prozess eigentlich aus? Das CMMI-Modell lässt hierbei einige Fragen offen.
„A process”, so CMMI – Glossary, “used in the CMMI Product Suite, consists of activities that can be recognized as implementations of practices in a CMMI model. These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal.” (“Ein Prozess – wie der Begriff im CMMI-Kontext verwendet wird – besteht aus Aktivitäten, die als Implementierungen des CMMI-Modells angesehen werden können. Diese Aktivitäten können mehrere CMMI-Praktiken abdecken. Dieses (Prozess-)Modell kann für Prozessverbesserung und Prozessbewertung genutzt werden.“)
Auffällig ist dabei eine gewisse (Über-)Betonung von Prozessaktivitäten. Dies ist ein von uns in der Praxis häufig beobachtetes Phänomen. Verfolgt man als Prozessdesigner diesen Denkansatz weiter und versucht, die Standardpraktiken in Tätigkeiten umzusetzen, so erzeugt man eine Verkettung von Prozessschritten, etwa wie im folgenden Beispiel:
Anforderungen entwickeln -> Abstimmen und Freigeben -> Architektur umsetzen -> Design umsetzen -> Implementieren -> Testen -> Ausliefern
Das sieht schon recht plausibel aus, es fehlen aber noch die relevanten Rollen und vor allem die mindestens genauso wichtigen Arbeitsergebnisse. Bei letzteren handelt es sich um Objekte im weitesten Sinne, die im Laufe des Arbeitsprozesses erzeugt, geändert und weitergereicht werden. Werden diese Objekte identifiziert und mit den entsprechenden Aktivitäten kombiniert, wird das daraus resultierende Prozessdiagramm schnell unübersichtlich. Rasch steht man vor dem Dilemma: Worauf könnten wir in diesem riesigen Prozessdiagramm verzichten? Welche Arbeitsergebnisse und Prozessschritte müssen unbedingt sichtbar bleiben, während andere entfernt werden können? Abstrakt betrachtet stellt sich hier latent die Frage: Was ist eigentlich wichtiger: Aktivitäten oder Ergebnisse? Sollte man im Zweifel lieber sämtliche Aktivitäten oder alle Ergebnisse visualisieren?
Die gute Nachricht lautet: Es gibt eine Lösung. Dazu möchten wir einen kleinen Denkanstoß aus der Motivationsforschung präsentieren: Wer jeden Tag über Probleme nachdenkt, wird am Ende eine Menge Probleme haben. Wer sich dagegen auf Lösungen konzentriert, dem eröffnet sich die Sichtweise, dass es für jedes Problem auch eine passende Lösung gibt. Eine andere Erkenntnis aus der Verhaltensforschung zeigt: Wenn man beim Autofahren in einer scharfen Kurve ins Schleudern gerät und dabei den entgegenkommenden Baum ansieht (dies kann sogar unbewusst geschehen), ist die Wahrscheinlichkeit einer Kollision höher, als wenn man an dem Baum vorbeischauen würde. Materie folgt dem Geist, könnte man kurz konstatieren. Übertragen auf unser „Ergebnisse vs. Aktivitäten“ – Dilemma leiteten wir aus den obigen Überlegungen die folgende These ab:
Konzentriert man sich bei der Prozessdefinition auf erforderliche Arbeitsaktivitäten, werden damit eine Menge Arbeitsvorgaben erzeugt. Legt man den Schwerpunkt primär auf Ergebnisse, so führt dies zu einer zielgerichteten Vorgehensdefinition.
Definiert man also viel an Arbeit, bekommt man viel Arbeit, definiert man Ziele, erhält man Ergebnisse. Das erscheint plausibel: die meisten von uns wollen lieber Ergebnisse als eine Menge Arbeit haben. Dieses Prinzip ist nicht neu und ähnelt dem aus der Management-Lehre bekannten MBO-Prinzip, „Management by Objectives“. Bei MBO herrscht die Erkenntnis vor, dass eine vollständige Definition detaillierter Arbeitsvorgaben ein unmögliches (und nicht zielführendes) Unterfangen darstellt. Dem ist erfahrungsgemäß zuzustimmen, und trotz seiner Schwächen wird MBO in der Organisationslehre als ein erfolgreicher Ansatz gewürdigt. D. h. in der Praxis: Werden qualifizierten Mitarbeitern klare Ziele vorgegeben, dann wird der richtige Weg ohne Detailvorgaben gefunden, sofern im Vorfeld klare Qualitätsvorgaben festgelegt sind. Wäre es also nicht sinnvoller, ergebnisorientiert zu verfahren anstatt umfangreiche Verkettungen detaillierter Arbeitsvorgänge vorzugeben? Warum nicht Prozesse über Ergebnisse definieren? Der Weg ist zweitrangig, das Ziel ist wichtig. Natürlich werden in der Praxis Hilfestellungen benötigen, z. B. in Form von Handbüchern oder Schulungen, damit sich insbesondere neue Mitarbeiter im Arbeitsprozess schnell zurechtfinden können. Für erfahrene Mitarbeiter reichen dagegen klare Zielvorgaben (Ergebnisvorgaben) aus.
Bezogen auf unser vorangegangenes Beispiel würde das Ergebnis einer zielorientierten Prozessanalyse wie folgt aussehen:
Anforderungskatalog -> Anforderungsfreigabe -> Architekturdokument -> Designdokument -> Ausführbares Programm -> Teststatistik/Bugs/Freigabe -> verpacktes Endprodukt
Testen Sie selbst, was Ihnen akzeptabler erscheint: Das eingangs angeführte Beispiel der Verkettung von Tätigkeiten oder die hier dargestellte Verkettung der Ergebnisse.
FAZIT
Mit dieser Erkenntnis war unsere Idee des „Process by Objectives“ (PBO) geboren. PBO haben wir in unserer Beraterpraxis bereits mit großem Erfolg für unsere Kunden umgesetzt. Dabei wird mit groben Meilensteinen, dann mit Ergebnissen, und erst ganz zum Schluss mit der vollständigen Prozessdefinition inklusive aller Aktivitäten vorgegangen. Es zeigt sich, dass dieser Ansatz die Akzeptanz neuer Prozessmodelle deutlich steigert. Einer detaillierten Vorgehensvorgabe begegnet man nicht selten mit der größten Skepsis, aber selbst die hartnäckigsten „Prozessmuffel“ akzeptieren klare Zielvorgaben.
Hinterlasse jetzt einen Kommentar