Die Ghostbusters durften NIE* die Laserströme kreuzen. Aber wie ist das, wenn zwei unabhängige Wertströme eine gemeinsame Dienstleistung teilen? Ob man dann die Wertströme kreuzen darf oder ob man sie lieber trennen sollte, steht in diesem Blogpost
*Wie so häufig ist ein NIE selten ein wirkliches NIE. Zumindest, wenn man mal eine totale protonische Umkehrung benötigt.
Neulich bekam ich eine E-Mail mit dieser Frage:
"Wir haben zwei Aufgabentypen, die weitestgehend unabhängig voneinander laufen. Da haben wir zwei Workflows. Die könnten wir auf zwei Kanban-Board abbilden, auch wenn sie von einem (organisatorischen) Team erledigt werden. Allerdings gibt es da noch die Qualitätssicherung, die von zwei Kollegen für alle Aufträge erfüllt wird. Die sollen ja nicht ständig von Board zu Board rennen. Wie machen wir das?"
Die Autorin hat die Kernpunkte komplett richtig erfasst:
- Das Team ist eine Organisationseinheit, die zwei größtenteils unabhängige Dienstleistungen zur Verfügung stellt. Ob man das dann Team nennen kann, sei dahingestellt, weil die gegenseitigen Abhängigkeiten fehlen.
- Zwei Workflows gehören typischerweise auf zwei Kanban-Boards – oder auf ein Whiteboard, aber untereinander. Man sollte die Workflows möglichst nicht direkt vermischen. Und insbesondere auch nicht beide so abstrahieren, dass irgendwie ein kleinster gemeinsamer Teiler herauskommt.
- Die Qualitätssicherung ist eine Unterdienstleistung, die beide Flüsse in Anspruch nehmen. Probleme im Fluss müssen sich dort widerspiegeln: In beiden abhängigen Dienstleistungen!
Visualisiert sieht das in etwa so aus:
Wie modelliert man das am besten?
Dem menschlich Indifferenten würde jetzt womöglich einfallen, jeweils einen der Mitarbeitenden in der Qualitätssicherung auf die Workflows zu verteilen. Das ist aber Quatsch. Zum einen ist das fragiler bezüglich schwankenden Bedarfs, zum anderen führt es zu einer "einseitigen Belastung". Die Mitarbeiter arbeiten also nur noch an einem Workflow, wo sie früher den Wechsel zwischen den Arbeitstypen hatten. Das fördert die Betriebsblindheit. Und statt gemeinsam an zwei Themen zu arbeiten sind die beiden Mitarbeitenden auf einmal getrennt. Das kann auf das Zugehörigkeitsgefühl und die soziale Identität massive Auswirkungen haben.
Andere Optionen
Lassen wir die beiden also lieber weiter gemeinsam arbeiten und sehen uns an, welche anderen Optionen wir haben.
- Zwei Workflows, die sich einfach nur eine gemeinsame Spalte habe, um deren Kapazitäten konkurrieren.
- Zwei wirklich unabhängige Workflows, die eine feste, eingeplante Kapazität bei einer quasi unabhängigen Dienstleistung haben – der Qualitätssicherung. In dieser Dienstleistung wird dann über Swimlanes und Kapazitätsallokation für die notwendige Balance gesorgt.
Ich empfehle Option 2, da sie zu mehr Verlässlichkeit und Vorhersagbarkeit führt.
Option 1 hat sicherlich auch ihren Charme, hier kann beispielsweise spontan darauf reagiert werden, wenn gerade mehr von Workflow 1 kommt als Workflow 2. Problematisch an dieser Modellierung ist, dass es dazu kommen kann, dass zwei Workflows blockiert werden, weil ein Problem die Dienstleistung verstopft.
Allerdings ist Option 1 wiederum menschlich nicht ganz einfach. Denn die Entscheidung, welches Ticket aus welchem Workflow bearbeitet wird, obliegt im Normalfall erst einmal den Mitarbeitenden dort. Die bekommen dann ständig Ärger mit den Verantwortlichen aus den beiden Workflows, weil sie nicht immer in deren Sinne gehandelt haben.
Option 2 hat den positiven Effekt, dass wir schon am Eingang der jeweiligen, abhängigen Dienstleistungen mit der vorhersagbaren Geschwindigkeit und Kapazität rechnen können. Natürlich muss die Qualitätssicherung als geteilte Dienstleistungen Daten über Geschwindigkeit, Durchsatz usw. sammeln, damit dann entsprechend damit gerechnet werden kann.
Sollte ein Problem auftreten, was nicht qualitätssicherungsbedingt ist, sondern die Ursache in einem der beiden ursprünglichen Workflows hat, schlägt sich dieses Problem nur auf die verursachende Dienstleistung zurück. Die andere Schwimmbahn bleibt frei und kann weiter Aufträge annehmen und bearbeiten.
Organisatorisches Boilerplating
Wir benötigen für diese Option allerdings alles, was wir für eine Dienstleistung benötigen, vermutlich aber deutlich kleiner:
- Commitment-Punkt und Commitment-Meeting/Replenishment
- Service Delivery Review
- Kanban-Meeting, gegebenenfalls gemeinsam mit den anderen
- Risk-Review, am besten mit den beiden anderen Dienstleistungen gemeinsam
- Service-Klassen, die wir aus den anderen Dienstleistungen ableiten
Doch ein gemeinsames Board?
Wir können die geteilte Dienstleistung trotzdem als eine geteilte Spalte auf einem gemeinsamen Board darstellen. Wir müssen nur einen klaren Commitment-Punkt für diese Dienstleistung festlegen. Das kann dann beispielsweise so aussehen:
So könnten wir immer noch unbürokratisch darüber beraten, ob ggf. Notwendigkeit für kurzfristige Kapazitätsverteilungen besteht. Meistens ist eine gute Vorhersagbarkeit aber mehr wert als das kurzfristige Ausmerzen von Planungsfehlern.
Wie ist Deine Erfahrung mit geteilten Dienstleistungen?
Kommentar schreiben