Podcast: Modellierung am Eingang

Statt nur in "Arbeit" und "Ungeplantes" zu differenzieren, sollte der Eingang nach den angebotenen Dienstleistungen strukturiert sein. Und technologisch oder nach benötigten technischen Ressourcen können wir weiter hinten im Workflow unterscheiden.

Ich freue mich über Likes und Kommentare bei Instagram: https://www.instagram.com/kanbanin7minuten/ 

Und Twitter: @KanbanIn7Min

Oder auch einfach über E-Mails! Fragen und Anregungen bitte an post@florianeisenberg.de

Happy Easter und Happy Kanban!

Lieber zuhören? Hier ist der Podcast:

Heute sprechen wir mal über die eingehenden Aufträge und wie wir die in unserem Kanban-System abbilden.

Viele modellieren das Ganze so, dass sie einfach eine gemeinsame Art von Aufträgen nehmen und da alles reinstopfen. Das heißt dann "Arbeit". Oder man nimmt noch einen zweiten dazu, dass sind dann "Arbeit" und "ungeplante Arbeit."

Das kann man so machen... aber dann erzielt man vielleicht nicht die ganz großen Vorteile bei der Anwendung. Erinnern wir uns noch mal dran: Im Betrieb der Dienstleistung unterstützt die Kanban-Methode die Bearbeitung der Aufträge, in dem wir den Eingang regulieren, für Koordination und Allokation sorgen und akute Risiken adressieren. Im Verbesserungsteil verwenden wir Daten, die unser System generiert, um tiefergehende Probleme zu identifizieren und dann Veränderungen zu beschließen. Wenn die einzige Information ist, dass zu viel "Arbeit" ankommt und sie ab und zu stockt, dann ist uns damit noch nicht so viel geholfen. Das ist übrigens ein ganz typischer Fall, dass da nicht gezielt genug geguckt wird. Wenn man die Information, dass mehr Arbeit ankommt als abgearbeitet wird, vorher nicht hatte, alles prima – dann ist das vielleicht der erste Schritt, um weitere Teile der Methode zu implementieren.

Mir fällt auf, ich sollte mal eine Folge über den impliziten Verbesserungszyklus machen, der sinnvollerweise mit der Methode verwendet wird. Er ist leider nicht explizit enthalten, aber man kann sich ja Dinge hinzudichten.

Wie also, wenn nicht einfach "Arbeit" und "ungeplante Arbeit"? Wie war der Claim noch mal? "Betrieb und Verbesserung von Dienstleistungen"! Es ist eine schlaue Idee, diese unterschiedlichen Dienstleistungen auseinander zu dröseln. Welche Dienste bieten wir an? Die sind direkt mit den Aufträgen verknüpft. Wenn wir also unterschiedliche Arten von Aufträgen identifizieren können, haben wir unterschiedliche Dienstleistungen. Das funktioniert natürlich auch in die andere Richtung: Bieten wir unterschiedliche Dienstleistungen an, haben wir mit hoher Wahrscheinlichkeit auch irgendwo schon mal einen Auftrag zu jeder Dienstleistung erledigt.

Wenn wir die unterschiedlichen Dienstleistungen identifiziert haben, können wir viel detaillierter auf Probleme und Risiken eingehen. Zu einer Dienstleistung gibt es nur einen einzigen Mitarbeitenden und wenn er oder sie krank ist, schießt uns die Durchlaufzeit durch die Decke? Gegebenenfalls sollten wir am Wissenstransfer der für diese notwendigen Skills auf mindestens eine weitere Person arbeiten. Und warum? Weil es ein Risiko für die umgebende Organisation ist! Das ist in den meisten Unternehmen viel, viel einfacher zu argumentieren und plausibilisieren als wenn wir den Eingang des Arbeitssystems nach Mitarbeitern aufgliedern und dann möglicherweise das Problem haben, das einer oder mehrere überlastet sind. Auch die Motivation des Wissenstransfers ist sonst fast nur ideologisch zu begründet – so a la "Macht man halt so, wenn man schlau ist." Die Aufgliederung nach Dienstleistung hilft und ungemein, Hebel für Veränderungen zu schaffen oder zu finden. Denn wer die Dienstleistung in Anspruch nimmt, hat ja ein Interesse an der Verbesserung. Man würde sich wünschen, dass das auch so wäre, wenn es um die einzelnen Menschen ginge, aber so funktioniert es wohl leider in vielen Fällen einfach nicht.

Wir können das Ganze auch noch nach benötigter Technologie oder technischen Ressourcen machen. Also sowas wie "jeder Auftrag, der nen Akku-Schrauber braucht" oder für den ein spezielles Wissen notwendig ist. Das kann durchaus hilfreich rein. Das schauen wir uns zuerst an. Wir können nämlich dann beurteilen, wie hoch der Bedarf für die einzelnen Sparten ist und dann unsere, sagen wir mal Planung für die Zukunft ableiten. Wenn also viele Aufträge reinkommen, die einen Akkuschrauber benötigen, dann können wir unter Umständen antizipieren, dass da auch in Zukunft noch mehr kommen könnte. Wir könnten also überlegen, ob es nicht sinnvoll wäre, in einen weiteren Akkuschrauber zu investieren. Oder in den Wissenstransfer bei einer bestimmten Fähigkeit.

Generell ist diese Aufspaltung – zumindest gleich bei Auftragsannahme – aber aus zwei Gründen blöd. Erstens sprechen wir dann wieder über die Limitierung des einzelnen, notwendigen "Dings" und über dessen Auslastung. Da haben wir dann erstmal nicht im Blick, welche Konsequenzen das dann für unsere Kunden hat. Zweitens, und das ist vielleicht noch wichtiger, müssen wir vor Auftragsannahme detailliert abklären, was benötigt wird, um den Auftrag zu bearbeiten. Das bedeutet, wir müssen Arbeit und damit Zeit und Geld investieren, um den Auftrag sehr detailliert kennen zu lernen. Das erzeugt dann sehr aufwändige Backlog-Refinement-Treffen, wie sie meist genannt werden. Das wiederum ist meist suboptimal, weil wir ja in noch nicht zugesagte Aufträge, also Optionen, nur so wenig Aufwand wie möglich stecken wollen – sonst können wir nicht schnell sehr viele verschiedene Optionen begutachten und machen dann sowas wie ein Pre-Commitment. Und wenn wir über Agilität des Geschäfts sprechen, ist das ganz sicher nicht der Weg, den wir einschlagen wollen.

Wir können die Vorteile des einen mit den Vorteilen des anderen einigermaßen kombinieren. Wir müssen dann in der Aussage über die Durchlaufzeit nur eventuell mit einer geringeren Vorhersagbarkeit rechnen. Wir gliedern also unseren Eingang wie vorhin schon besprochen nach den wirklichen Dienstleistungen auf. Wenn wir Engpässe bei Spezialwissen oder technischen Ressourcen wie dem Akkuschrauber vermuten, spalten wir den Workflow an der Stelle auf, wo der Engpass auftreten würde. Wir werden dann – wenn wir diese Stelle ganz bewusst beobachten – sehen, wie der Durchfluss hier ist. Wenn mehr Aufgaben in die Dienstleistung kommen, die speziell behandelt werden müssen, als durch den Engpass durchpassen, staut sich das dann an dieser Stelle sogar bis zum Eingang der Dienstleistung zurück. Wir können also sehen, dass der Engpass eine Auswirkung auf die Leistungsfähigkeit der Dienstleistung und damit auf die Kunden hat. Wir sind also gut beraten, hier etwas zu verändern.

Zusammenfassend: Wir gliedern am Zusagepunkt den Eingang nach den angebotenen Dienstleistungen auf. Damit können wir beurteilen, wie viel wovon eigentlich benötigt wird. Daraus folgt, was wir verbreitern und was wir vielleicht stilllegen sollten. Wenn wir durch Spezialwissen oder bestimmte technische Ressourcen in unserem Arbeitsfluss limitiert sind, sollten wir diese Aufgliederung so spät wie möglich im Workflow modellieren. So sparen wir uns eine zu frühe Beurteilung der einzelnen Aufträge und eine Ausrichtung unseres Geschäfts an dem, was wir haben statt an den Erwartungen und Bedürfnissen der Kunden. Aus einer Dissonanz zwischen der Erwartungen und unseren Fähigkeiten lässt sich dann sehr leicht eine Veränderung motivieren.