CONTROLLER Magazin 1/2020

33 zu verstehen, dass die ganze Nachfragekette betrachtet wird, nicht nur das direkte Umfeld oder gar der unmittelbare Nachfolgeprozess. In vielen Fällen ist Letzteres sogar unmöglich: „You cannot grow an orange tree overnight to provide a pulled orange drink.“ Vorausschau- ende Planung ist demnach nicht generell abzu- lehnen, es ergibt sich jedoch die Konsequenz, dass der Planungs- und Produktionszyklus sich dem Nachfragezyklus anpassen sollte. Wenn täglich verkauft wird, sollte täglich pro- duziert werden. So postulieren beispielsweise auch aktuelle Entwicklungen im IT-Bereich, dass ein fließender und möglichst laufender Übergang zwischen Entwicklung und Produkti- on gewährleitest werden sollte (DevOps). Hier gilt die Devise „Develop in Cadance – Deliver on Demand“, d. h. entwickle im festen Rhyth- mus und setze produktiv nach den Anforderun- gen des Geschäfts. Dieser Rhythmus muss sich demnach nach den Anforderungen aus- richten, also in der Regel möglichst kurze und zeitnahe Zyklen beinhalten. Doch kommen wir zu der Übertragung auf das Projektwesen. Was bedeutet das Pull-Prinzip für die PV-Ebene? Auf der Ebene der fachlich-progressiven Pro- jektarbeit bedeutet Pull ... Rückwärtsterminierung Bei der Rückwärtsterminierung wird der ter- minlich-logische Projektablauf von seinem ter- minlich gewünschten Ende ausgehend geplant. Analog zur Produktions- und Materialplanung erfolgt damit die zeitgerechte Ermittlung des (fachlichen) Ergebnisbedarfs – unter Gewähr- leistung der spätmöglichsten Termine, sodass keine unnötigen Lücken entstehen. Im Sinne des Pull-Prinzips reduziert sich somit die Zeit, in der Ergebnisse potentiell obsolet oder unpas- send werden können (vgl. Abbildung 3). ten der sekundären Wertschöpfung stattfinden (Planung, Berichtswesen, Änderungsbearbei- tung etc.). Fluss zu gewährleisten heißt hier, zeitnah zum Bedarf Ergebnisse bereitzustellen (der Plan muss aktuell sein), schnell Entschei- dungen herbeizuführen (ansonsten wartet das Projekt) oder auch Projektsynchronisations- punkte wie Meilensteine und Quality Gates oder Reviews (Scrum) aktiv zu managen, sodass kei- ne vermeidbaren und wenig zielführenden War- tezeiten entstehen. Besonders die Meilensteine zeigen bereits den Konflikt auf, denn die Alter- native sollte nicht sein, auf Synchronisations- elemente zu verzichten, weil sonst im weiteren Verlauf des Projekts ggf. Doppelarbeiten ent- stehen können. Die Ableitung für die Gestaltung des Flusses im PM kann daher wie folgt identifiziert werden: · kurze Entscheidungswege etablieren, ggf. unter Nutzung eines (temporären) Beipasses, · Kommunikation der Mitarbeiter fördern, s.d. bei Zeitverzug schnell Klärung herbeigeführt werden kann, · klare, saubere, zeitnahe Taktung im Projektberichtswesen, bestehend aus Statusberichten und Jours Fixes, · zeitnahe Rückmeldung und Maßnahmenab- leitung gemäß Erfordernis des Projektstatus (-berichts), · zeitnahe Ressourcenbereitstellung · Projektplanung gemäß den Prinzipien des Flusses in der PV-Ebene (s.o.). Pull in Projekten Das Pull-Prinzip besagt, dass der Wertstrom primär durch den Bedarf bzw. die Nachfrage des Kunden in Gang gesetzt wird. Es wird demnach nur dann produziert, wenn die Leis- tungen gebraucht werden. Dies ist jedoch so Fluss in der fachlich-progressiven Projektbearbeitung Auf der PV-Ebene wird in Projekten die primäre Wertschöpfung des Projekts erarbeitet. Die ope- rativen Einheiten der Erarbeitung sind klassi- scherweise Arbeitspakete (PMBoK Guide, PM3, PRINCE2), die im Detail die Abarbeitung spezifi- scher Aufgaben (Tasks) verlangen. (Dabei lassen sich auch die Strukturen agiler Vorgehensweisen wie Scrum, gekennzeichnet durch Arbeitseinhei- ten wie Sprint, User Stories und Tasks hier sub- summieren.) Abgebildet wird der Fluss der Erar- beitung in Projektablaufplänen der Phasen oder Sprints des Projekts. Insofern gilt es, im Lean PM diese Abläufe ohne signifikante und insbesonde- re unnötige Unterbrechung zu gestalten. Projekte ermöglichen im Allgemeinen keinen „One Piece Flow“, anhand dessen der Fluss ausgerichtet werden kann, sondern sind per Definition durch eine gewisse Komplexität cha- rakterisiert, also eine Vielzahl zu koordinieren- der Aktivitäten, Abhängigkeiten, Lieferobjekte und Beteiligter. Mit Stalk und Houts Goldener Regel („Never delay a value adding step by a non value adding (although temporarily neces- sary) step.“), Goldratts Engpasstheorie und Parkinsons Gesetz („Work expands so as to fill the time available for its completion.“) lässt sich aber eine heuristische Regel ableiten, wie sie auch im Critical Chain Project Management- Ansatz (CCPM) angewendet wird. Die Optimie- rung der Bearbeitungsabläufe im Projekt sollte sich nach den folgenden Kriterien richten: · Engpassressourcen beheben (z. B. der einzig verbliebene Entwickler, der noch die uralte Programmiersprache beherrscht), · (ursächlich) kritischen Pfad betrachten, · Einplanung von Sicherheitspuffern in den Arbeitspaketen vermeiden, · Aktivitäten parallelisieren ist dabei nur sinnvoll, wenn auf schädliches Multitasking der Ressourcen verzichtet wird, · Aktivitäten des PV (also primär wert­ schöpfende) gegenüber denen des PM im Konflikt- oder Enpassfall priorisieren. Fluss in den Projektmanagement-Prozessen Die PM-Prozesse stellen den Bereich des Pro- jekts dar, in dem die wiederkehrenden Aktivitä- Abb. 3: Zeitliche Platzierung von Arbeitspaketen CM Januar / Februar 2020