Ein Lifecycle sagt mehr als tausend Prozessbeschreibungen – Teil 1

Erinnern Sie sich noch an Ihren letzten Restaurantbesuch und an den Kellner, der Sie bediente? Wenn Sie seine Tätigkeit beschreiben sollten, dann können Sie es mit der herkömmlichen Geschäftsprozessmodellierung versuchen, also einer ablauforientierten Methode. Ein mögliches Ergebnis zeigt Abbildung 1.

Abbildung 1: Was tut ein Kellner?

Diese Beispiellösung beschreibt die einzelnen Arbeitsabläufe chronologisch. Jeder Kellner kann seine Arbeit entsprechend organisieren. Seine Aktivitäten sind stets gleich. Es gibt nur wenige Randbedingungen, die eine Änderung dieses Ablaufs erfordern – beispielsweise, wenn sich Gäste übrig gebliebene Speisen zum Mitnehmen einpacken lassen. Wie sieht es dagegen mit dem Arbeitsablauf des Kochs aus? Mit der ablauforientierten Methode kommen wir zu einer Lösung, wie sie in Abbildung 2 dargestellt ist.

Abbildung 2: Was tut ein Koch?

Im Unterschied zu Abbildung 1 stellt dieses Schaubild nicht wie beim Kellner den genauen chronologischen Arbeitsablauf dar. Vielmehr verbergen sich hinter den einzelnen Schritten vielschichtige Tätigkeiten: Vom Abmessen der Zutaten Abmessen, Mischen über das Kochen, Braten, Backen, Würzen und Abschmecken bis hin zu den letzten Finessen beim Anrichten der Speisen. Schon die Zahl und die Beschaffenheit der verwendeten Utensilien beeindruckt.

Die genaue Abfolge der Zubereitung richtet sich nach der Reihenfolge der Bestellungen durch die Gäste. Dadurch entstehen für die Arbeitsschritte der einzelnen Rezepte verschiedene Synergien. Zum Beispiel werden – je nach Bestelleingang – bestimmte Zutaten für mehrere Rezepte auf einmal geschnitten, gekocht, gebraten usw. Der Workflow des Kochs ergibt sich damit aus einer optimierten Abfolge von Arbeitsschritten für gleichzeitig zubereitete Speisen. Die Optimierung kann erst erfolgen, nachdem die Bestellungen eingegangen sind. Zusätzlich sollen die Gerichte für jeden Tisch möglichst gleichzeitig fertig sein. Je nach Bestelleingang – und damit mehrmals im Laufe eines Tages bzw. Abends – ändert der Koch die Reihenfolge und Organisation seiner Tätigkeiten. Welche Bestellungen wann eingehen, lässt sich nicht vorhersagen, und damit erübrigt sich eine allgemeingültige Beschreibung der chronologischen Arbeitsabläufe. Dennoch ist eine konkrete Prozessbeschreibung nützlich, um etwa Schnittstellen zu benachbarten Teilprozessen festzulegen. Bevor wir auf passende Methoden eingehen, greifen wir nochmal das Beispiel des Kellners im betriebswirtschaftlichen Umfeld auf. Im Rechnungswesen finden wir stabile, durch Buchführungsvorschriften weitgehend geregelte Workflows. Hier eine typische Sequenz:

• Rechnungseingang,
• Kontierung als Verbindlichkeit
• Auslösen des Zahlungsvorgangs
• Buchung als Zahlungsausgang
• Kontierung auf Kostenstelle

Die Abarbeitungsreihenfolge ist fix, es gibt keinen Spielraum für eine Parallelisierung. Für solche Vorgänge eignen sich ablauforientierte Beschreibungsmethoden wie Ereignisgesteuerte Prozessketten (EPK). Das Beispiel des Kochs lässt sich im technischen Bereich auf die Entwicklung von Software übertragen. Hier stoßen wir auf hochgradig vernetzte Tätigkeiten, die durch komplexe Abhängigkeiten und Nebenläufigkeiten geprägt sind. Dazu kommen vielschichtige und variable Rahmenbedingungen, wie beispielsweise:

• Erfahrungen und Kompetenzen des Projektteams
• Entwicklungsumgebung und IT-Infrastruktur
• Änderungen im Zeitplan und der verfügbaren Ressourcen
• Neuer Anforderungen während der Projektlaufzeit

Die Wertschöpfung im Projektalltag wird durch die Abläufe und den Automatisierungsgrad im Application Lifecycle Management (ALM) geprägt. Bisher fehlte die Methodik, solche semi-strukturierten Geschäftsprozesse für Wissensarbeiter angemessen darzustellen. Häufig beschränkt sich die Prozessmodellierung auf eine Abfolge grobgranularer Produktionsschritte nach dem EVA-Muster (Eingabe, Verarbeitung, Ausgabe). ALM-Umgebungen, wie z. B. „Microsoft Team Foundation Server” oder „IBM Rational Team Concert” – bilden aber viel feiner aufgelöste Workflows ab, bei denen sämtliche fachlichen Abhängigkeiten berücksichtigt werden müssen.

Ziele für die Optimierung von Entwicklungsprojekten

Im zweiten Teil des Blogs werde ich an Hand folgender Ziele eine Lösung ableiten.

1. Die Wertschöpfung durch Entwicklungsprojekte muss transparent und nachvollziehbar sein.
2. Gestaltungsprinzipien für Entwicklungsabläufe müssen allgemeingültig sein.
3. Kreative Arbeitsabläufe von Wissensarbeitern müssen gewährleistet werden.
4. Verbesserungsmaßnahmen müssen eine Wertschöpfung der Entwickler mit weniger eingesetzten Mitteln möglich machen.
5. Verbesserungen im Arbeitsmodell müssen unmittelbar nachgewiesen werden können.

Auch wenn die Liste der Ziele oben noch nicht vollständig ist, kann mit den schon ableitbaren Anforderungen ein Rahmen skizziert werden, in dem eine erfolgsversprechende Optimierung erfolgt. Seien Sie auf die nächste Folge gespannt! Vielleicht haben Sie auch Ideen, welche Erfolgsrezepte hier greifen können? Dann würde ich mich über Ihren Input sehr freuen.

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.