Pull vs. Push: Pull-Systeme machen Sie effizienter!

Nehmen wir ein Praxisbeispiel eines Push-Systems: Sämtliche Arbeitsplatzrechner des Unternehmen sollen regelmäßig einen aktualisierten Softwarestand erhalten. Zu einem solchen Release gehören Betriebssystemupdates, Gerätetreiber, Securitypatches und das Set an Anwendungssoftware, welches allen Usern zur Verfügung stehen soll.

Es wird Anwendungssoftware selbst entwickelt oder fertige Software von Drittherstellern eingesammelt, Installationsroutinen für die diversen Zielrechnersysteme gebaut, alles erst einzeln, dann im Verbund getestet und schließlich ausgerollt.

Aufgrund der Vielzahl der Aktivitäten und der beteiligten Instanzen und Personen hat das Releasemanagement den ganzen Ablauf in Form von Phasen und Meilensteinen über viele Monate im Voraus geplant und an alle Beteiligten kommuniziert. Wenn „das Release“ dann endlich startet werden alle Aktivitäten vom Releasemanagement koordiniert, d.h. jeder Schritt wird separat beauftragt und kontrolliert.

Das oben beschriebene Beispiel zeigt ein typisches planungsgesteuertes Push-System.

Durch den termingetriebenen Ansatz entstehen Wartezeiten, in denen halbfertige Produkte auf Ihre Weiterverarbeitung warten. Sehr typisch ist die entstehende Hektik im Team, wenn ein Meilenstein erreicht ist, aber nicht alle Zulieferungen wie geplant erbracht wurden. Ich habe erlebt, das Teams nach einem solchen Meilenstein eine echte Erholungsphase benötigen, in der die Leistungsfähigkeit deutlich herabgesetzt ist.

In einem Pull-System hingegen würde sich einiges anders darstellen: Wenn ein Update für eine der Releasekomponenten vorliegt, kann sich der Softwareintegrator die Software nehmen und ein Installationspaket daraus bauen. Wenn alle Installationspakete für eine Zielplattform vorliegen, kann der Releaseintegrator selbst seine Arbeit starten, ohne auf eine Beauftragung des Releasekoordinators warten zu müssen. Und so fort. So entsteht im Idealfall ein kontinuierlicher Arbeitsfluss. Der Releasekoordinator kann sich nun auf das Monitoring und – vor allem – die kontinuierlichen Optimierung des Prozesses konzentrieren.

Inwieweit es gelingt, die Prozesse fliessend zu gestalten, hängt zunächst wesentlich von zwei Dingen ab:

1) Visualisierung des Workflows
Zunächst muss überhaupt transparent sein, welche (Zwischen-) Produkte sich wo im Prozess befinden. Eine reibungslose Kommunikation wird eher nicht durch den Versand von haufenweisen Mails und Excel-Tabellen entstehen, sondern durch ein visuelles System, das den Workflow auf den ersten Blick verstehbar macht, auf das alle Beteiligten Zugriff haben und das den Flow der Arbeit „live“ darstellt. Statusabfragen sind in einem solchen System überflüssig. Jeder Beteiligte sieht die Veränderungen, sie werden evtl. im Daily Standup des Teams erwähnt und gezeigt. So läuft auch die Kommunikation bedarfsgerecht und ohne Informationsüberfluss.
Verwenden Sie ein Kanban-Board zur Visualisierung Ihres Workflows! Beispiel eines Kanban-Boards
Wenn das Team örtlich nah zusammen arbeitet kann man dies mit Whiteboard und Haftnotizen mit minimalem Aufwand realisieren. Für verteilte Teams ist ein elektronisches Tool wie z.B. LeanKit zu empfehlen, das u.a. auch die komplette Historie zu jedem Vorgang für jeden Benutzer transparent macht.

2) Explizite Prozessregeln
Jedem muss bewusst sein, wann ein Produkt reif für die Weiterverarbeitung ist. Wann muss ich wissen, welche Voraussetzungen die Software benötigt? Welche Tests müssen passed sein, bevor sie in die Integrationsumgebung migriert werden darf? Etc.
Aber es geht hierbei nicht nur um Soll-Prozessschritte, sondern auch um Dinge, die die Art der Zusammenarbeit im Team oder mit Prozesspartnern beschreiben.
Machen Sie sich die Regeln bewusst nach denen sie arbeiten und schreiben Sie sie sehr konkret an die entsprechende Swimlane in das Kanban-Board! In Scrum verwendet man – gerade bei unerfahrenen Teams – eine „Definition of Ready“ (DoR). Diese verhindert die Arbeit an Themen, die noch nicht reif sind und oft im weiteren Ablauf zu Unterbrechungen des Flow und zu Zusatzarbeit führen. Eine solche DoR bietet dem Team auch eine gute Argumentationsbasis, wenn eine vermeintlich wichtige Instanz etwas besonders Dringendes durchdrücken will.

Analog zu der DoR gibt es sicher auch in Ihrem Unternehmen eine „Definition of Done“ (DoD), die beschreibt, wann ein „Produkt“ entweder fertig ist für die Produktion oder bereit für die Weitergabe an den nächsten Prozesspartner in der Wertschöpfungskette. Ist Ihre DoD explizit beschrieben oder existiert sie nur in den Köpfen der Mitarbeiter? Meint jeder das selbe? Stimmen Sie Ihre DoD im Team ab und schreiben Sie sie in Ihr Kanban- bzw. Scrum-Board.

Visualisierung des Workflow und Transparenz über die Regeln, dies sind wesentliche erste Schritte auf Ihrem Weg zu einer erfolgreichen Verschlankung und bieten bereits deutliches Potenzial für Effizienzsteigerungen sowie – nicht zuletzt – eine Reduzierung des Stresspotenzials Ihres Teams.

Zu weiteren Elementen des Lean Managements werde ich an dieser Stelle schreiben.

Kommentare sind geschlossen.