Lean Prinzip 4: Das Pull-Prinzip einführen

„Pull“, zu Deutsch „ziehen“, bedeutet im Sinne von Lean, dass Aufgaben in einem wertschöpfenden Prozess von einem Schritt in den nächsten gezogen werden. Das heißt ein nachgelagerter Schritt zieht sich die Aufgaben/Materialien/Informationen aus dem vorherigen.
Im Gegensatz dazu werden beim „Push“-Prinzip Aufgaben durch Planungsvorgaben in den Prozess hineingedrückt.

Das Pull-Prinzip orientiert sich somit vielmehr an einem „Outcome“ als an einem „Output“. Diese zwei Wörter hören sich sehr ähnlich an, meinen aber was ganz unterschiedliches.
„Output“, die „Ausbringung“, richtet sich auf die erbrachte Leistung und misst das Projekt rein an den Dingen, die in das Projekt eingebracht wurden. Dies sind meist Ressourcen, Zeit und Budget.
„Outcome“, also „Ergebnis“, misst demgegenüber den direkten Nutzen des Produktes bzw. Projektergebnisses und befasst sich nicht primär mit der Steigerung der Produktivität, noch werden hier Ressourcen bis ins Kleinste geplant.
Das heißt das Push-Prinzip fordert eine 100% Auslastung der Maschinen bzw. Menschen. Das Pull-Prinzip fordert einen ganzheitlichen Nutzen des Ergebnisses bzw. des hergestellten Produktes. Hier muss man seinen Blick also einmal um 180 Grad drehen und von hinten auf den Prozess schauen.

Des Weiteren lehnt sich das Pull-Prinzip vor allem bei agilen Methoden an der Theorie Y an und das Push Prinzip an der Theorie X. Diese Theorien wurden in den 60er Jahren von Douglas McGregor formuliert.¹
Bei der Theroy X wird davon ausgegangen, dass Menschen versuchen Arbeit aus dem Weg zu gehen und alles tun um sie zu vermeiden und dazu keine Verantwortung übernehmen wollen. Die meisten Führungskräfte reagieren darauf mit einem autoritären Führungsstil im Command-and-Control-Modus. In dieser Theorie kann man Menschen eigentlich nur mit finanziellen Anreizen motivieren, z.B. Boni. Dies führt meist im Umkehrschluss dazu, dass Leute unmotiviert sind und keine Verantwortung übernehmen wollen, was die Theorie X weiter bestätigt.
Die Theorie Y geht genau den anderen Weg. Hier werden Menschen als arbeitsam angesehen, für die Arbeit etwas Grundsätzliches ist und darin aufgehen wollen und können. Sie übernehmen dazu Verantwortung für ihr Handeln und wollen kreativ arbeiten. Anerkennung und Selbstverwirklichung sind hier die Motivatoren.
Hier gilt es also auch, einmal komplett anderes herum auf die Dinge zu schauen.
Diese Beschreibung ist natürlich eine vereinfachte Welt in schwarz-weiß. Oft liegt die Wahrheit wohl genau dazwischen. Trotzdem zeigt es die unterschiedliche Weltanschauung verschiedenster Managementmethoden sehr gut auf.

Mit welchen Methoden schafft man es das Pull-Prinzip einzuführen? Neben Mitteln wie Kanban Boards und Work-in-Progress-Limits, bzw. einiger anderer agiler Methodiken, ist hier das Management gefragt. Es sollte ein Arbeitsumfeld herrschen, in dem Respekt, Kollaboration, Lernkultur, Fokus auf Wertschaffung, Anpassung auf Veränderung und Verantwortungsübernahme gelebt werden.
Ein guter Führungsansatz ist der Facilitative Leadership Approach. Dieser beinhaltet sehr kurz gefasst folgende Eckelemente, um eine wirkliche Selbstorganisation zu etablieren, die essentiell für eine agile und leane Arbeitsweise ist:

  • Eine Vision als Richtung vorgeben
  • Werte als Rahmen stecken
  • Moderierend führen
  • Rolle eines Mentors einnehmen
  • Demotivatoren beseitigen, z.B. langsame Computer und Internetleitung, sinnlose Meetings abschaffen usw.
  • Freien Zugang zu Informationen und Materialien

„If you are going to do TPS you must do it all the way. You also need to change the way you think. You need to change how you look at things.“ ~Taiichi Ohno (Erfinder des Toyota Productions System (TPS), dem Vorreiter von Lean)


  1. X-Y-Theorie: https://de.wikipedia.org/wiki/X-Y-Theorie 

 

Advertisements

Lean Prinzip 3: Das Fluss-Prinzip umsetzen

In den beiden vorherigen Blogbeiträgen zur Identifizierung des Wertstroms (Teil 1 und Teil 2) habe ich versucht aufzuzeigen, wie man den Strom der wertschöpfenden Arbeit in einer Organisation identifizieren kann. Wie man quasi eine Landschaftskarte rund um einen Fluß, der sich durch die organisatorische Landschaft schlängelt, aufzeichnet.

Nun geht es darum die Landschaft so anzupassen, dass der Fluß möglichst schnell fließt. Dies ist oft eine schwierige und mühselige Aufgabe, aber wie schon Konfuzius sagte „Der Mann, der den Berg abtrug, war derselbe, der anfing, kleine Steine wegzutragen.“ Nur so wird es gelingen.
Ich möchte euch in diesem Blogbeitrag einige Hilfsmittel aufzeigen, wie diese Steine, Kurven und Wasserfälle im Flussverlauf abzutragen sind.

Batch / Inkrement-Größe

Zunächst gilt es wie bei dem Berg, Arbeitspakete, Projekte, Produktteile und so weiter, so klein wie möglich einzuteilen und dabei möglichst gleich große Einheiten zu bekommen. Ein Scrum Team z.B. wird irgendwann ein Gefühl dafür entwickeln, wann eine User Story/Anforderung zu groß ist und kann dies in ihre Definition of Ready aufnehmen. Dies kann z.B. der Fall sein, wenn eine Story mehr als 8 Story Points hat.

Stories kleiner zu schneiden ist für Scrum Team gerade am Anfang oft nicht sehr einfach. Ich möchte euch hier einige Links zu Methoden zur Verfügung stellen, von Kollegen, die sich dazu bereits gute Gedanken gemacht haben.

  • Dimensional Planning
  • Eine andere Art der Dimension, die ich persönlich besser finde ist folgendes Schaubild:

MVPDas „zerschneiden“ der Anforderung vom Auto hin zum Skateboard könnte man auch gut als eigenen Schitt auf einem Scrum oder Kanban Board einbauen.

Fazit: Das Ziel sollte sein, Arbeitspakete möglichst klein zu bekommen, da diese schneller fließen. Dies macht man aber natürlich auch mit dem Hintergrund, Komplextät rauszunehmen.

Es existieren auch Berechnungsmethoden, ab wann eine Anfoderung klein genug ist, mit Werten wie Transactional Cost, Total Coasts usw. Ich empfehle hier aber das kollektive Bauchgefühl und Menschenverstand. Irgendwann sagt sich ein Team, dass die Anforderungen zu klein sind und der Aufwand sie klein zu kriegen, viel zu groß ist, als dass es ein Gewinn wäre.

Wissensinseln

Ein weiterer wichtiger Schritt den Fluß zu beschleunigen sind Wissensinseln bzw. Kompetenzzentren, die oft bei nur einer Person liegen, aufzulösen. Ist diese Person z.B. gerade nicht da, staut sich der Fluß und man wartet bis es weiter geht.

Wissensinsel aufzudecken und zu beseitigen kann man mit einem „Market of Skills“. Mehr dazu unter: https://blog.crisp.se/2012/11/06/anderslaestadius/team-liftoff-with-market-of-skills-and-competence-matrix
Desweiteren lassen sich in einem Software-Entwicklungsteam durch Pair oder Mob Programming Wissensinsel abbauen und Wissen verteilen. Dazu ergeben sich noch viele weitere Vorteile, mit denen sich Verschwendungen vermeiden lassen. Zum Beispiel werden weniger Fehler gemacht und Bugs produziert.

WIP-Limits

Einer der wichtigsten Booster für die Verkürzung der Durchlaufzeit ist ein Limit der angefangen Arbeit, kurz WIP Limit (WIP = Work in progress). Die Kanban Methode beinhaltet diese bereits als Kernpraktik. Bei Scrum wird diese Methode häufig genutzt, ist aber kein grundsätzlicher Bestandteil.

Oft fehlt es den Beteiligten an Verständnis, warum einen Limitierung der angefangenen Arbeit zu schnelleren Ergebnissen führt, da es einseitig betrachtet, ineffizient wirkt. Als Beispiel nenne ich oft das Verschicken von Rechnungen auf Papier. Als Student habe ich selbst in einem Team mehrere Tausend Rechnugen für ein Unternehmen manuell eingetütet, mit Briefmarken versehen und verschickt.
Hier empfiehlt sich wider Erwarten der Single-Piece-Flow. D.h. eine Rechnung nach der anderen. Sprich, eine Rechnung falten, in einen Briefumschlag stecken, zukleben, wiegen und mit der richtigen Briefmarke versehen.
Eine andere Methode wäre: Erst alle fallten, dann in eine Briefumschlag stecken und so weiter, da man ja unter anderem bei jedem Schritt, wenn man in ständig hintereinander ausführt, effizienter wird. Dies ist ein Fallstrick, da Fehler oft nicht bercksichtigt werden. Zudem könnte jede fertige Rechnung schon rausgeschickt und bezahlt werden. Nicht aber, wenn erst alle Rechnungen gefaltet werden.
Ein Video was dies verdeutlich ist auf Youtube zu finden: https://www.youtube.com/watch?v=Dr67i5SdXi

Single Piece Flow, also z.B. eine User Story nach der nächsten, ist natürlich eher eine Vision und ausser beim Mob Programming kaum zu erreichen. Es macht auch oft keinen Sinn. Man sollte aber trotzdem versuchen sein WIP Limit immer weiter zu minimieren. Ein weitere Grund dafür ist auch die Vermeidung von Task Switching, was zu Verschwendung führt.

Vermeidung von Verschwendung ist ein weiterer sehr wichtiger Punkt das Fluss Prinzip umzusetzen. Bei der Software Entwicklung existieren 7 Verschwendungsarten, wobei Task Switching explizit eine eigene ist. Dieser Sache möchte ich einen seperaten Blogartikel widmen, da dieser Teil sehr umfänglich ist.

Große Skepsis gegenüber WIP-Limits kommt auch oft von Projektleitern und Managern. Die Ursache ist, dass man oft noch versucht auf einen Auslastung von 100% zu optimieren. Menschen kann man aber nicht wie Maschinen behandeln. Menschlichkeit ist bei agilen Methoden ein zentraler Aspekt.

Gehen wir mal von dem Fall aus, dass ein WIP-Limt erreicht ist und Team-Mitglieder nun blockiert sind. Was passiert jetzt. Im Gegensatz zu den Verfechtern der Theory X die jetzt davon ausgehen würden, dass Leute nur noch Youtube-Videos schauen oder Nickerchen machen, gibt es Menschen und ich bin der Meinung, dass das die Mehrheit ist, die sich nun darum kümmern das Problem, welches für den aufgetretenen Arbeitsstau verantwortlich ist, zu lösen. Des weiteren können sie sich fortbilden, ihre Arbeit ggf. durch Automatisierungen optimieren, mal mit anderen Menschen ausserhalb des Teams sprechen, sich mit dem Kunden beschäftigen und und und. So viele Sachen die einen Wert schaffen können. Dieses „über den Tellerand hinausschauen“ würde mit einer 100%-Auslastung nicht passieren.

Automatisierung

Jegliche wiederkehrende, manuelle Arbeit gilt es bei Lean zu automatisieren. Automatiserung beschleunigt den wertschöpfenden Prozess ungemein. Ein Nebeneffekt dabei, den man nicht vernachlässigen sollte, ist die Erhöhung der Qualität. Je weniger menschlicher Einfluss vorhanden ist, desto höher die Qualität. Menschen machen nun mal Fehler.

Automatisierung, auch von kleinen Dingen, wirkt kurzfristig erst mal langsam und klingt nach mehr Aufwand. Langfristig gesehen ist dies der Raketentreibstoff jeglicher Produktentwicklung.

Automatisierung, vor allem Continuous Delivery/Deployment, ist ein weiteres umfassendes Thema zu dem es viele Bücher und Meinungen gibt. Ich möchte es hier erst mal dabei belassen, dass es ein wichtiger Teil ist lean und agil zu werden.

Poka Yoke

Der japanische Ausdruck Poka Yoke (jap. ポカヨケ, dt. „unglückliche Fehler vermeiden“) bezeichnet ein aus mehreren Elementen bestehendes Prinzip, welches technische Vorkehrungen bzw. Einrichtungen zur sofortigen Fehleraufdeckung und -verhinderung umfasst.1

Für Poka Yoke muss man sicherlich schon wirklich ein sehr tiefes Verständnis von Lean besitzen. Eine Umsetzung bei Software Entwicklung könnte ich mir in den folgenden Berichen vorstellen:

  • Das Produkt selbst schon so designen, dass der Kunde möglichst wenig Fehler machen kann. Beispiel Bankautomat: Hier muss man erst die Karte rausziehen, bevor das Geld ausgegeben wird.
  • Einsatz von Sonar Qube um Flüchtigkeitsfehler im Code zu vermeiden
  • Unittests
  • Automatisierte (Regressions-)Tests

Queues und Backlogs verkleinern

Wo immer sich Informationen aufstauen und nicht fließen sollte man sofort Maßnahmen ergreifen diese zu lösen. Nehmen wir das Beispiel E-Mail Inbox. In manchen Firmen gilt die Anzahl der E-Mails, die man während seines Urlaubs bekommt, schon als eine Art Statussymbol. Eigentlich sollte dies genau anders rum sein.

Ich bin nicht unbedingt ein Fan der InboxZero Methode, finde aber, dass es in die richtige Richtung geht. Mit dem richtigen Mailprogramm kann man dazu sehr viel automatisieren.

Für firmeninterne Kommunikation sollte man eher andere Tools benutzen wie Slack, welches ich sehr empfehlen kann (slack.com).

Geht man in den Urlaub, kann man in seiner Abwesenheitsmail auch einfach reinschreiben, dass man die E-Mails nicht beantworten wird und in dringenden Notfällen einen Kollegen informiert oder nach dem Urlaub noch mal schreiben sollte, da die E-Mails ungelesen verschoben werden. Wenn man dies freundlich schreibt, haben bestimmt die meisten Verständnis, da sie es selber kennen und man glaubt nicht, wie viel sich tatsächlich dann selbst erledigt.

Backlog von Features sollte man regelmäßig pflegen und aufräumen. Dies kann man auch automatisieren. Man schließt z.B. alle Tickets, die länger als 6 Monate nicht angefast wurden. Seien wir mal ehrlich: Alles was so alt geworden ist, hatte niemals eine hohe Wichtigkeit und Dringlichkeit und wird diese vermutlich auch nie bekommen. Falls doch, sollte ein neues Ticket erstellt werden. Meist sind die Informationen in dem ursprünglichen Tickets sowieso veraltet. Am Anfang ist das natürlich nicht einfach, gerade für diejeniegen, die diese Tickets geschrieben und viel Zeit drauf verwendet haben. Aber es wird sich einspielen, wenn man die positiven Erfolge sieht, dass andere Aufgaben viel besser durch den Wertschöpfungsprozess fließen.

Verschwendung minimieren

Muri, Mura und Muda sind 3 (japanische) Begriffe aus dem Toyota-Produktions-System die sich dem Thema Verschwendung und Verursachung von Verschwendung widmen. Dieses Thema ist durchaus ein wichtiges Thema um den Fluss zu beschleunigen und Ich schreibe deshalb, wie schon erwähnt ,seprarat in einem zukünfitgen Blogpost darüber.

 


  1. https://de.wikipedia.org/wiki/Poka_Yoke

Cynefin-Framework – Mit Komplexität im Projektmanagement umgehen

Pflanzt man einen Baum und versucht vorherzusehen und aufzuzeichnen wo jeder Ast und jedes Blatt wachsen wird, wird man scheitern.

Die Faktoren die man kennt oder auch noch nicht kennt, die dazu führen wie der Baum wächst, sind einfach zu komplex um sie zu verstehen. Erst im Nachhinein kann man vielleicht den ein oder anderen Rückschluss ziehen. Pflanzt man aber eine gleiche Art Baum, wird dieser aber wieder anderes wachsen und die Rückschlusse, die man gezogen hat, sind unbrauchbar.

Und so verhält sich das auch mit vielen Projekten, vor allem im IT-Bereich. Aber nicht nur dort. Viele Bereiche im heutigen Leben werden immer komplexer.

Ein Framework und weitere Tools die dabei helfen sich können sich in komplexen Projekten zurecht zu finden, findet ihr in der folgenden Präsentation von mir, die ihr gerne weiter verwenden dürft.

https://prezi.com/view/tg7nFMT5Eo1PfeKKd9KS/embed

Lean Prinzip 2: Den Wertstrom identifizieren (Teil 2)

Wie im letzten Blogpost Lean Prinzip 2: Den Wertstrom identifizieren (Teil 1) angekündigt, möchte ich mich nun dem Spaghetti Digramm widmen. Dieses Diagramm stammt wie auch das Value-Stream-Mapping / Wertstromanalyse aus dem Produktionsbereich. Es dient auch der Visualisierung des Prozesses / Arbeitsablaufes, nur aus einem anderen Blickwinkel. Hier geht es nicht darum, welches Schritte, mit welchen Zeiten durchlaufen werden, um Informationen bzw. Produkte anzufertigen, zu veredeln und auszuliefern. Es geht darum wohin diese transportiert werden und wie oft.

Ich möchte dies wieder an dem Beispiel Urlaubsantrag verdeutlichen. Wir werfen nochmal eine Blick auf den finalen Wertstrom vom letzten mal:

IMG_20170526_114748

Hier habe ich extra unterschiedliche Post-it-Farben für die unterschiedlichen Bearbeiter verwendet. Dies sind 4 verschiedene (Kann man auf dem Bild leider nicht so gut erkennen). Ich nehme nun die gleichen Farben und schreibe jeweils das Team / Abteilung / Person usw. drauf. Diese sind:

  • Die Person die Urlaub beantragen möcht
  • Die Team-Kollegen
  • Der Vorgesetzte
  • Die Personalabteilung

Diese Post-its klebe ich wieder auf ein Whiteboard. Dies kann man im Idealfall so machen, wie die Abteilungen auch räumlich verteilt sind. Weiter entfernte Abteilungen/Kollegen klebe ich auch etwas weiter auf. Dann zeichne ich für jede Interaktion zwischen den Beteiligten einen Strich. Dies sieht dann wie folgt aus:

IMG_20170623_150316

Die Interaktion zwischen der Urlaub nehmenden Person und den Teamkollegen beinhaltet z.B. mehrere Striche, da hier mehrere Kollegen befragt werden, ob sie als Vertretung in Frage kommen können.

Das Spaghetti Diagramm entfaltet seine ganze Kraft aber eher bei komplexen Vorgängen mit z.B. mehreren Abnahmerunden, Delegationen, mehrere Standorte/Länder usw. Es ist also ein mächtiges Werkzeug um den Fluß von Informationen und Gütern zu verbessern. Dies könnte dann so ausehen:

IMG_20170623_150501.jpg

Dies ähnelt dann schon mehr einem Teller Spaghetti.

Wie man nun diese Ergebisse der beiden Blogposts zum Theme Identifizierung des Wertstroms nutzen kann, um Arbeit zu minimieren, die keinen Wert für den Kunden schafft, werde ich in einem zukünftigen Blogpost zum 3. Prinzip von Lean „Das Fluss-Prinzip umsetzen“ erläutern.

D.h. wir wollen versuchen die 57 Minuten aus der 3-57 Regel wesentlich zu minimieren (siehe Lean Prinzip 2: Den Wertstrom identifizieren (Teil 1)). Hier gilt die Faustformel: Für alle 15 Minuten die wir die nicht wertschöpfende Arbeit von einer Stunde minimieren, verdoppelt sich die Produktivität und dies führt zu 20% Steigerung der Gewinnmarge  (15-2-20 Regel).

Mahlzeit! und bis zum nächsten mal.

 

 

 

Schlaue Zitate #3

„Wir haben nicht zu wenig Zeit, wir verschwenden zu viel davon. Auch zur Vollbringung der größten Dinge ist das Leben lang genug, wenn es nur gut angewendet wird.“

~ Seneca

 

„Wer den schlechtesten Gebrauch von seiner Zeit macht,
jammert am meisten, dass sie so knapp ist.“

~ Jean de la Bruyère

 

Lean Prinzip 2: Den Wertstrom identifizieren (Teil 1)

Heute möchte ich mich dem zweiten leanen Prinzip widmen, nachdem ich im letzten Blog-Post über „Den Wert aus Sicht des Kunden definieren“ geschrieben habe.

Anders ausgedrückt bedeutet „den Wertstrom zu identifizieren“ herauszufinden, wie etwas in eine Organisation reinkommt und am Ende etwas mit Wert für den Kunden entsteht.
Bei einem Sägewerk zum Beispiel ist dies relativ einfach. Vorne kommt ein Baumstamm rein, es wird gesägt und am Ende kommt ein Brett raus. Vielleicht schaut man sich noch den Prozess an, wie der Baum aus dem Wald in das Sägewerk und das Brett aus dem Sägewerk zum Kunden kommt, der es verbaut.
Ganz so einfach ist das bei Dienstleistungen, Softwareentwicklung bzw. von der Art her komplexen Produkten nicht. Hier geht es meist um imaginäre Produkte, die vom Wort her schon schwer zu greifen sind.

Um den Wertstrom bei Softwareentwicklung zu identifizieren sollte man sich anschauen wie Informationen fließen, verarbeitet werden, Software entwickelt und dem Kunden ausgeliefert wird. Dabei schaut man sich wie bei einem Baumstamm an, wie Informationen gelagert und verarbeitet werden, wo Engpässe entstehen usw. An der ein oder anderen Stelle wird vielleicht zu viel absägt und ein Stille-Post-Effekt tritt ein.

Wo fängt man jetzt aber an? Was ist mein Baumstamm?
Am besten man fängt in dem Teil an, in dem man seinen Teil der Wertschöpfung beiträgt, da man diesen Part einfach auch am besten kennt. Bist Du Softwareentwickler fang bei Projektaufträgen, Change-Requests, Bug-Reports usw. an. Bist Du Produktmanager, schau Dir an wo deine Informationen herkommen, die Du während deiner Arbeitszeit verarbeitest. Kundenwünsche, interne Anfragen, Fragen zum Produkt. Wie lagerst Du diese Informationen? Wie verarbeitest Du sie? Wie veredelst Du sie? Wie übergibst Du sie an den nachgelagerten Schritt?
Für den Anfang reicht es aus einen kleinen Teil aus der Wertschöpfung oder einen kleinen abgeschlossenen Prozess innerhalb der Organisation zu wählen.
Die finale Identifikation des Wertstroms sollte dann aber nicht aufhören. Es ist ratsam das Ganze im Auge zu behalten und den Wertstrom erst als vollständig zu betrachten, wenn vorne ein richtiger Kunde steht und am Ende. Mit richtiger Kunde meine ich denjenigen der das Produkt konsumiert oder dessen Problem wir versuchen zu lösen, also derjenige der in den meisten Fällen Geld dafür bezahlt. Ich sage extra in den meisten Fällen, da dies bei Non-Profit-Unternehmen oder z.B. Ämtern andere sind, die am Ende das Gehalt bezahlen.

Wenn Du jetzt weißt wo Du anfängst, fehlt nur noch das „Wie“? Wie zeichne ich den Wertstrom auf?

Alles was man im Grunde braucht, sind ein paar verschiedenfarbige Post-its, Whiteboard-Stifte (auch mehrere Farben empfohlen) und ein Whiteboard. Dann fängt man mit dem ersten Schritt an, wie Information initial ankommen, schreibt dies auf ein Post-it und klebt es an das Board. Die nächsten Schritte sind dann, wie die Information verarbeitet wird, bis ein Ergebnis/Outcome da ist. Die Schritte, die tatsächlich in einer Organisation ausgeführt werden finden sich oft in Dokumentationen oder Prozesscharts.

Ich möchte euch dies am besten an einem Beispiel verdeutlichen. Wir nehmen hier mal den Klassiker, den jeder kennt und Ihr der „Kunde“ seid: Urlaubsantrag. Ich habe dafür einen Prozess gewählt wie er standardmäßig in Unternehmen vorkommen kann.

  1. Die erste Aktivität von der ich ausgehe, ist zunächst die Recherche nach der Anzahl der Resturlaubstage, wenn diese nicht direkt parat sind. Ich schreibe diesen Schritt auf ein Post-it. Manche Unternehmen haben dafür Tools oder man findet es auf der letzten Gehaltsabrechnung. Ich gehe dabei mal pauschal von 5 Minuten aus, die man dafür benötigt und schreibe sie unter das Post-it.
    Ich wähle 5 Minuten mal als die kleinste Einheit in diesem Beispiel.
    IMG_20170526_111927
  2. Danach schaue ich in den Kalender um die genauen Tage meines Urlaubs rauszufinden und wie viele Tage Urlaub ich in Anspruch nehmen möchte. Auch hier sage ich mal, braucht man grob 5 Minuten. Weil dieser Schritt von der gleichen Person gemacht wird, nehme ich die gleiche Post-it-Farbe und verbinde die Post-its mit einem Pfeil.
    IMG_20170526_112226
  3. Hat man den passenden Zeitraum gefunden, in dem man seinen verdienten Urlaub legen möchte, regelt man mit seinen Kollegen wer in diesem Zeitraum als Vertretung in Frage kommen kann (wird in vielen Firmen oft verlangt). Da ich nun andere Personen anspreche nehme ich dafür eine andere Farbe für das Post-it, schreibe den Schritt darauf und die Zeit, die dafür benötigt wird darunter. Ich würde mal sagen man spricht mit 2-3 Kollegen und braucht dafür von allen 5-10 Minuten ihrer Zeit.
    IMG_20170526_112401
  4. Nun füllt man den Urlaubsantrag aus, schreibt eine E-Mail als Antrag oder was auch immer der Prozess vorsieht, um seinen Vorgesetzten zu informieren und schickt den Antrag zu ihm. Sollte auch nicht länger als ca. 5-10 Minuten dauern sollte.
    IMG_20170526_112604
  5. Der Vorgesetzte prüft dann irgendwann den Urlaubsantrag und checkt ggf. ob andere Mitarbeiter Urlaub zu dem Zeitpunkt haben und ob es mit der Geschäfts-/Projektplanung oder sonstigen Sachen zusammenpasst. Ich gehe mal davon aus, dass es nicht direkt abrufbar ist und 10 Minuten dauern wird. Ich wähle dafür wieder eine andere Farbe für das Post-it.
    IMG_20170526_112803
  6. Im nächsten Schritt informiert der Vorgesetzte den Mitarbeiter ob der Antrag genehmigt oder abgelehnt wurde, was ca. 5 Minuten dauern kann. Ich nehme hier wieder die Farbe des Vorgesetzten und klebe das Post-it aus Platzgründen unter den letzten Schritt und lasse extra etwas frei bis zum Pfeil.
    IMG_20170526_112948
  7. In diesem Beispiel geh ich mal davon aus, dass der Urlaub genehmigt wurde (Yay!). Nun wird in diesem Beispielprozess noch die Personalabteilung vom Vorgesetzten informiert. Wieder 5 Minuten Arbeit.
    IMG_20170526_113152
  8. So, fast geschafft! Die Personalabteilung (wieder neue Farbe für Post-it) trägt den Urlaub in das entsprechende Tool ein und aktualisiert somit das Urlaubskonto. Der Prozess ist nun beendet und der „Kunden“-wunsch erfüllt.
    IMG_20170526_113851

Jetzt hat man die Vorarbeit für den nächsten, aus meiner Sicht, wichtigsten Schritt geleistet den Wertstrom (engl.: Value-Stream) aufzuzeichnen. Ich ziehe dafür einen Strich unter die Zeiten die ich aufgeschrieben habe und schreibe „Value“ über den Strich und „Waste“ unter den Strich. Jetzt wisst ihr auch warum ich etwas Platz zwischen der oberen und unteren Pos-it Reihe gelassen habe.

IMG_20170526_114012

Jetzt gilt es die Zeiten aufzuschreiben die verstreicht (meist mit Warten) wenn Dinge, in unserem Fall Informationen, von einem Schritt in den nächsten fließen.

  • Für den ersten Schritt gehe ich von Null aus, da diese Aufgabe direkt danach erledigt wird (Recherche Resturlaub und Suche im Kalender).
  • Um die 2-3 Kollegen zu erwischen die vertreten könnten, vergehen geschätzt 2 Stunden, da einer vielleicht gerade im Meeting oder Telefonat ist und auf Ihn gewartet werden muss.
  • Ist eine Vertretung gefunden dauert es vielleicht 10 Minuten, bis man am Rechner sitzt und die E-Mail oder was auch immer als Antrag an den Chef schreibt.
  • Nun liegt es beim Chef. Bis dieser dazu kommt, weil die E-Mail u.U. in seinem Postfach durch andere Mails weiter nach unten gerutscht ist, in Meetings war oder wie auch immer, vergeht durchaus ein Arbeitstag (á 8 Stunden), den ich mit 480 Minuten festhalte.
  • Von der Prüfung bis zur Genehmigung vergehen noch mal 5 Minuten.
  • Bis zur E-Mail an die Personalabteilung vergehen durch ein z.B. dazwischen gekommenes Telefon (Kommt ja immer was dazwischen) noch mal 15 Minuten.
  • Bei der Personalabteilung liegt der Antrag dann noch mal 1,5  Arbeitstage (720 Minuten), weil sie viel zu tun haben, bis er schließlich eingetragen wird.
    IMG_20170526_114748

Nun addiere ich jeweils die Zeiten von „Value“ (über der Linie) und „Waste“ (unter der Linie) und schreibe sie am Ende dazu.

IMG_20170526_115036

Das heißt, dass für den Urlaubsantrag letztendlich 45-55 Minuten tatsächlich was getan wurde. 22,5 h Stunden befand sich der Antrag irgendwo und wurde nicht bearbeitet. Wenn Wartezeiten oder wertschöpfende Arbeit pro Schritt sehr unterschiedlich ausfallen, kann man auch durchaus mit Durchschnittswerten arbeiten. Als Faustformel bei der Produktentwicklung gibt es die 3-57 Regel, die besagt: Für jede 60 Minuten Arbeitszeit an einem Produkt in einem Prozess passiert 3 Minuten tatsächlich wertschöpfende Arbeit. 57 Minuten sind nicht-wertschöpfende Tätigkeiten, wie Wartezeiten im Prozess. Kommt bei dem genannten Beispiel auch ungefähr hin.

In dem letzten Schritt, der Identifizierung Nicht-wertschöpfender-Arbeit (Waste), sollte man besonderes Augenmerk auf folgende Dinge richten, wo sich der Wertstrom oft staut:

  • Backlog und Queues
  • Abnahmen
  • Entscheidungsrunden

Schon bei der Aufdeckung der wertschöpfenden Kette an Aktivitäten fallen so manche Dinge auf, die gar keinen wirklichen Wert für den Kunden, den man zuvor identifiziert hat, schaffen. Wie man diese Schritte aufdeckt und eliminiert kommt in einem der nächsten Blogbeiträge zum Thema „Das Fluss-Prinzip umsetzen“, dem 3. Prinzip von Lean.

Im nächsten, zweiten Teil zu „Lean Prinzip 2: Den Wertstrom identifizieren“ möchte ich euch das so genannte „Spaghetti Diagramm“ am gleiche Prozess aufzeigen, welches zusätzlich den Wertstrom aus anderer Sicht aufzeigt. Dann wird auch klar, warum verschiedene Farben von Post-its benutzt wurden.

Über Kommentare freue ich mich übrigens sehr.

Schlaues Zitat #2

A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right...It’s always worth asking, do we own the process or does the process own us?“

~ Jeff Bezos