Methoden zur Verschwendungsvermeidung (Teil 2)

Hat man eine Verschwendung in einer Organisation erkannt und möchte diese beseitigen, kann man hierfür die A3 Methode verwenden, die eine empirische Herangehensweise an ein Problem sehr einfach ermöglicht.

Wie bei vielen Methoden zu Agil und Lean kommt diese auch aus dem Lean Management und wurde im Toyota Produktionssystem entwickelt. Es haben sich auch hier bereits andere Leute schon gute Gedanken gemacht und diese niedergeschrieben, auf die ich hier verweisen möchte:

http://www.ksimons.de/2014/06/hindernisse-dauerhaft-loesen-durch-impediment-management-mit-a3-denken/

Advertisements

Methoden zur Verschwendungsvermeidung (Teil 1)

Einer der Grundpfeiler des agilen Rahmenwerk Scrum und ein essentieller Bestandteil schlanker Organisationen ist Transparenz. Aber was genau ist Transparenz und vor allem wie genau erreicht man eine angemesse Transparenz?

Man kann sicherlich so transparent wie möglich sein, nur sehen dann die Leute den Wald vor lauter Bäumen vielleicht nicht mehr? Ist Transparenz eine Hol- oder eine Bringschuld? Reicht es Informationen in irgendeinem Wiki oder Fileserver abzulegen um dann am Ende sagen zu können „Die Informationen waren ja da, ihr hätte sie euch einfach nur holen müssen“ oder andersherum „Wir wussten von nichts, uns hat niemand informiert“.

Haben Menschen keine oder zu wenig Informationen um Dinge zu entscheiden, die sie  ihren Zielen näher bringt, entsteht Verschwendung. So viel steht auf jeden Fall mal fest. Informationen richtig abzulegen und für jeden übersichtlich zu machen schafft schon mal einen großen Vorteil diese Verschwendung zumindest zu verringern.

Eine bekannte Methode aus dem Lean-Management, Produktionsprozesse zu verbessern, ist das 5S-Prinzip. Dieses Prinzip könnte man wie folgt auch auf das „Lagern“ von Informationen anwenden, z.B. von Projekt- oder Feature-Backlogs.

  • Seiri: Sortiere Benötigtes und Unbenötigtes.
  • Seiton: Ordne ordentlich was übrig geblieben ist.
  • Seiso: Säubere.
  • Seiketsu: Ständige Wiederholung der ersten drei Schritte.
  • Shitsuke: Disziplin die ersten vier Schritte durchzuführen.

Im folgenden möchte ich euch die Umsetzung des 5 S Prinzip anhand eines E-Mail-Postfaches erläutern. Hier geht es dann erst mal um die individuelle Transparenz. Man könnte diese Regeln aber auch organisationsweit einführen.

Sortiere Benötigtes und Unbenötigtes.

Im Idealfall würde man nun alle unbedeutenden E-Mails löschen um Platz zu schaffen. Will man herauszufinden was noch benötigt wird und was nicht, müsste man theoretisch alle E-Mails noch mal durchgehen und diese ordnen. Dazu hat vermutlich aber keiner Lust noch die Zeit. In der heutigen Zeit haben E-Mail-Postfächer auch so viel Speicherplatz, dass man theoretisch auch nichts löschen braucht. In manchen Unternehmen ist es aus Compliance-Gründen auch verboten E-Mails zu löschen.

Für den Rest der E-Mails erstellen wir ein Ablagesystem aus 3 Kategorien:

  1. Arbeit
  2. Referenz
  3. Archiv

Ordne ordentlich was übrig geblieben ist

Alles was alt und nutzlos ist sollte in das Archiv einsortiert werden. Zum Beispiel Einladungen vergangener Meetings, E-Mails zu abgeschlossenen Projekten, Mails von Kollegen, die bereits die Firma verlassen haben und und und.

Mails, die man gelegentlich benötigt um Informationen nachzulesen, wie Usernamen oder die man als Referenz bzw. Template für andere E-Mails benutzt, (z.B. Urlaubsantrag) kommen in den Ordner 2. Referenz.

In den Ordner Arbeit stecken wir alle E-Mails, die wir noch bearbeiten müssen oder die wir regelmäßig benutzen, wie z.B. die Agenda von wiederkehrenden Meetings.

In allen Ordner können natürlich bei Bedarf  Unterordner erstellt werden. Es macht durchaus Sinn in den Ordner Arbeit Unterordner, wie  ToDo, Doing, Done, Parkplatz (Dinge die auf etwas warten) usw. anzulegen.

Dieser Schritt, falls er doch ein wenig Zeit beansprucht, muss auch nicht am Stück ausgeführt werden. Vielleicht 20 Minuten täglich zwischendurch, bis alles sortiert ist.

Am Ende sollten dann max. 20% der E-Mails im Arbeit Ordner abgelegt sein.

Säubere

Dies ist die Aufgabe des IT Suports, die sicherstellen müssen, dass die E-Mail-Server z.B. Exchange sauber laufen und Daten gesichert werden.

Ständige Wiederholung der ersten drei Schritte und Disziplin die ersten vier Schritte durchzuführen.

Um der Entropie entgegenzuwirken sollte man sich am besten pro Tag, Woche oder Monat regelmäßig Zeit nehmen, vielleicht durch einen fest eingestellten Termin (Inbox Refinement), sein Postfach aufzuräumen und E-Mails umzusortieren, zum Beispiel von Arbeit nach Archiv. Diese Zeit sollte man sich auf jeden Fall nehmen, da man dadurch sehr viel mehr Zeit am Ende einsparen kann.

Ein weiterer Effekt der sich dabei einstellt ist ein Zufriedenheitsgefühl über das aufgeräumte Postfach und den besseren Fokus.

Bei einem Produkt-Backlog sind die Effekte der Zeitersparnis und Zufriedenheit noch viel viel größer, weil hier auch viel mehr Leute betroffen sind. Ist allerdings auch eine wirklich harte Nuss, die es sich aber lohnt zu knacken.

Verschwendung – Mura, Muri und Muda

Verschwendung (im japanischen Muda), bzw. Arbeit die keinen wirklichen Wert schafft, ist oft nicht ganz offensichtlich. Gerade in einem Entwicklungsprozess oder einer Firmenorganisation die über Jahre gewachsen ist und man schon etwas betriebsblind geworden ist, ist Verschwendung nur schwer aufzudecken. Denn wer gibt schon gerne zu, dass man die Arbeit, die man täglich verrichtet, nicht effektiv ist. Dies wurde damals auch schon im Toyota-Produktions-System entdeckt und aufgegriffen.

Im Toyota Produktionssystem (TPS) wurde Muda in 7 Arten unterteilt:

  1. Transportation (Materialbewegung)
  2. Inventory (Inventar)
  3. Motion (Bewegeung)
  4. Waiting (Warten)
  5. Over Processing (Über-Entwicklung)
  6. Over Production (Überprduktion)
  7. Defects (Fehler, Nacharbeiten)

In einigen Quellen wird zusätzlich noch eine achte Art hinzugefügt:

8. Latent Skill (Ungenutzte Talente)

Für die Softwareentwicklung sind diese Arten der Verschwendung nur teilweise übertragbar wie z.B. Warten oder Defects.
Die Poppendieks haben diese 7 Arten der Verschwendung in ihrem Buch „Lean Software Development, An Agile Toolkit“ für die Erstellung von Software übersetzt:

  1. Task Switching (Aufgabenwechsel, Multi-Tasking)
  2. Partially Done Work (Halbfertige Arbeiten)
  3. Motion (Bewegung)
  4. Waiting (Warten)
  5. Extra Processes (Zusätzliche Prozesse)
  6. Extra Features (Zusätzliche Features)
  7. Defects (Bugs, Fehler)

Diese 7 Verschwendungsarten machen es etwas einfacher Muda im Software-Entwicklungsprozess aufzudecken. Sie sind aus meiner Sicht aber, vielleicht auch aus Übersetzungsgründen, teilweise immer noch etwas schwer zu greifen. Deshalb würde ich persönlich folgende Verschwendungsarten wählen:

  1. Aufgabenwechsel
  2. Unnötige fachliche und/oder technische Komplexität
  3. Fehlende Information / Ressourcen
  4. Ineffiziente, unnütze Prozesse
  5. (Noch) ungenutze Features
  6. Warten
  7. Fehler und Nacharbeiten

Diese Einteilung kann neben der Schaffung eines Bewusstseins für Verschwendung im Unternehmen auch sehr hilfreich für einen Scrum Master sein. Denn Impediments zu beseitigen ist nichts anderes als Verschwendung aufzudecken und abzuschalten.

Konzentration auf die Vermeidung von Verschwendung  und Minimierung wertloser Arbeit klingt erst mal nach dem heiligen Gral zur Erhöhung der Effizienz und Produktivität. Tatsächlich ist es das auch. Dort hinzukommen ist allerdings sehr schwierig. Oft ist die Vermeidung von Verschwendung auch der erste Weg, den man einschlägt um effizienter zu werden. Logisch.

Es könnte allerdings hilfreich sein, sich zunächst auf andere Dinge zu konzentrieren und zwar solche, die Verschwendung hervorrufen oder begünstigen.
Muri, die Überlastung von Mitarbeiter und Maschinen und Mura, die unregelmäßigen Abläufe bzw. Prozesse (z.B. am Ende einer Berichtssaison oder Projektende) hindern Menschen oft daran Ihre Abläufe zu verbessern und Verschwendung aufzudecken und zu eliminieren. Eine Metapher dazu beschreibt folgendes Bild:

are-you-too-busy-to-improve2.png

Durch Muri und Mura ensteht Verschwendung. Wenn Menschen überlastet sind machen sie Fehler und oder werden krank.

Dazu denken die meisten Menschen natürlich, dass sie schon effizient und effektiv genug sind und sich nicht verbessern müssen. Vielleicht stimmt das manchmal sogar, kann sich aber durchaus auch wieder ändern, z.B. wenn neue Technologien verfügbar sind, die einen noch besser unterstützen können. Diese müssen dann aber natürlich im Auge behalten werden.

In einem weiteren Blogartikel möchte ich einige dieser Technologien und auch  Methodiken vorstellen Verschwendung aufzudecken und zu vermeiden.

Lean Prinzip 5: Perfektion anstreben

Der Duden definiert „Perfektion“ wie folgt: „…höchste Vollendung in der [technischen] Beherrschung, Ausführung von etwas; vollkommene Meisterschaft“. Dieses „etwas“ ist bei Lean die Schaffung eines vollkommenen Wertes für den Kunden ohne jegliche Verschwendung. Dies ist sicherlich eine Vision, die man nie erreichen wird und deshalb sagt dieses Prinzip, dass man zumindest danach streben sollte.

Das Modell zur Kompetenzstufenentwicklung¹ erläutert wie man diese Perfektion erreichen kann. Dieses Modell beschreibt vier Stufen der Kompetenzentwicklung. Diese vier Stufen sind kurz zusammengefast:

  1. Unbewusste Inkompetenz
    Man erkennt seine eigene Inkompetenz nicht. Wenn man beispielsweise noch nie etwas von agiler Softwareentwicklung gehört hat, vielleicht auch weil es sie noch nicht gab, weiß man auch nicht, dass man hier Defizite hat.
  2. Bewusste Inkompetenz
    Man hat von etwas gehört und weiß, dass man es nicht kann und wie es erreicht wird. Man hatte also mal von Agilität gehört, weiß aber, dass man es mit dem vorhandenen Nichtwissen nicht umsetzten kann.
  3. Bewusste Kompetenz
    Man weiß, dass man es kann, man muss sich aber sehr konzentrieren und hohen Aufwand und Energie reinstecken. Man hat also mal eine Scrum Master Zertifizierung gemacht und einige Sprints agil gearbeitet oder z.B. den Führerschein gerade erworben.
    Viele hören dann auf dieser Stufe mit dem Lernen auf. Man hat es grundsätzlich verstanden, aber zum Können fehlt dann noch der letzte Schritt. Im schlimmsten Fall entsteht dann der Duning-Kruger-Effekt bei dem Personen unter anderem dazu neigen, ihre eigenen Fähigkeiten zu überschätzen.²
  4. Unbewusste Kompetenz
    Man hat auf dieser Stufe so viel praktische Erfahrung gesammelt, dass es einem keine Mühe bereitet und die Handlungen unbewusst aus einem heraus kommen. Man handelt quasi automatisch ohne nachzudenken, wie wenn man schon jahrelang Auto oder auch Fahrrad fäht.

Perfektion geht dann noch einen weiteren Schritt über die vierte Stufe hinaus. Man ist quasi das Wissen. Man ist Meister seines Faches. Man hat u.U. sein eigens agiles Framework erschaffen oder wie Bruce Lee seinen eigenen Kampfkunststil.

Das Durchlaufen dieser 4 Stufen ist schon für Individuen beim Thema Agilität nicht gerade einfach. Umso schwerer ist dies bei einer Organisation, die meist mehr ist als die Summe ihrer Individuen.
Hier empfiehlt es sich nach dem PDCA Zyklus (Plan-Do-Check-Act) nach Deming vorzugehen um eine Lernkultur im Unternehmen zu etablieren. Das heißt eine Inkompetenz wird aufgedeckt und ein Vorgehen erarbeitet. Das Vorgehen wird dann überprüft und geschaut ob weitere Schritte nötig sind eine Kompetenzstufe höher zu kommen.

Hat die Organisation mit allen Individuen dann irgendwann die 4. Stufe hinsichtlich lean und agil erreicht, sollte sich eine Lösungskultur (Kaizen Kultur) einstellen, in der, wenn ein Fehler von jemandem entdeckt wird, dieser Fehler direkt gelöst oder zumindest adressiert wird ohne groß nachzudenken.


  1. Komptenzstufenentwicklung: https://de.wikipedia.org/wiki/Kompetenzstufenentwicklung
  2. Dunning-Kruger-Effekt: https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt

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 

 

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

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.

 

 

 

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.

Lean Prinzip 1: Den Wert aus Sicht des Kunden definieren

Nach dem ich in dem Blogartikel „Nur wer schlank ist, ist auch schnell und wendig und damit fit für die Zukunft.“ einen kurzer Überblick darüber gegeben habe was „Lean“ bedeutet, möchte ich nun in den nächsten Wochen die dahinterstehenden Prinzipien näher erläutern (so wie ich sie verstehe).

„Wert aus Sicht des Kunden definieren“ – dieses erste Prinzip von „LEAN“ klingt eigentlich erst mal einfach. Es stellt aber tatsächlich oft eine größere Herausforderung dar. Im Grunde geht es darum herauszufinden was ein Problem löst, das irgendjemand zu einer gewissen Zeit an einem gewissen Ort hat. Für den einen ist dies etwas leichter für die meisten jedoch etwas schwerer. Am Ende ist es dann oft „nur“ eine Frage der Mittel die man hat und Perspektiven die man einnimmt.

Die eigentlichen Kunden eines Produktes können teilweise selbst nicht einmal sagen was ihnen einen Wert verschafft, wenn man sie fragen würden. Henry Ford sagte einmal: „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde.“ Wenn er das tatsächlich gefragt hätte, hätte er seine ganze Energie darauf verwenden können, Pferde tatsächlich schneller zu machen, z.B. mit einer neuen Hufeisentechnologie, Züchtungen von Super-Pferden, innovativstes Kraftfutter und und und. Schließlich haben die Leute ja gesagt, was sie wollen. Was er aber wahrscheinlich gemacht hat, ist sich in den Kunden hineinzuversetzen. Er sagte nämlich auch „Das Geheimnis des Erfolges ist, den Standpunkt des Anderen zu verstehen.“ Dies war vielleicht in diesem Fall sehr einfach für ihn, weil er selbst von diesem Problem betroffen war. Man weiß es nicht! Tut aber auch nichts zur Sache. Er hat sich zumindest zu dem Kern des Problems der Leute hervorgearbeitet und verstanden, dass sie möglichst schnell von A nach B kommen wollen und das möglichst bequem. Egal wie. Wie er dies gemacht hat wissen wir nicht. Manche Menschen haben auch einfach diese gewisse Gabe dies einfach so zu verstehen wie Steve Jobs, Thomas Edison, Elon Musk und einige wenige andere. Viele andere müssen sich jedoch einiger Hilfsmittel bedienen, die ich hier erläutern möchte.

Allem voran, egal welche Methode, Technik usw. man benutzt, ist es wichtig nicht schon in Lösungen für Menschen zu denken, sondern den Menschen, seinen Kunden, Respekt zu zeugen und ihn ernst zu nehmen. Viele Unternehmen tun dies nicht bzw. haben es über die Jahre vergessen. Manche Unternehmen schauen schon gar nicht mehr auf Ihre Kunden, sondern nur auf die Konkurrenz. Jeff Bezos sagte mal „If we can keep competitors focused on us while we stay focused on customers, we’ll turn out all right.“ auf Deutsch: „Wenn wir unsere Konkurrenz damit beschäftigen auf uns zu schauen und wir uns um unsere Kunden kümmern können, wird das gut für uns ausgehen.“ Genau deswegen ist Amazon so erfolgreich und sie haben es noch nicht mal sonderlich schwer damit besser zu sein als andere. Tesla funktioniert ebenfalls genau so.

Um dies noch weiter zu verdeutlichen möchte ich noch einen Auszug aus dem jährlichen Brief von Jeff Bezos an seine Shareholder (April 2017) im Original zitieren: „There are many advantages to a customer-centric approach, but here’s the big one: customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to inventon their behalf. No customer ever asked Amazon to create the Prime membership program, but it sure turns out they wanted it, and I could give you many such examples.“

Viele Probleme der Konsumenten entstehen dazu auch erst durch falsch entwickelte Produkte, die wieder neue Produkte benötigen um Lösungen bereitzustellen für Probleme, die so nicht hätten sein müssen. Ganze Branchen werden sogar um diese Probleme gebildet, in die viele viele Menschen Lebenszeit hineinstecken, die sie auch hätten sinnvoller verbringen können. Sobald es z.B. nötig ist einen Berater für ein Produkt zu engagieren, ist dies der Fall. Microsoft und manch anderer hat dies in den letzten Jahren verstanden und die Kurve gekriegt. Viele alteingesessene Branchen wie Banken, Versicherungen, Automobilindustrie, Lebensmittelindustrie haben ihren Kunden zum Teil wesentlich aus den Augen verloren. Viele von Ihnen müssen dafür auch sehr hohe Strafen zahlen. Jetzt schweife ich aber etwas ab. Wenn man dies mal im Hinterkopf behält, stößt man leider sehr oft über solche Beispiele von Unternehmen und Produkten.

Hier nun eine (unpriorisierte) Liste von Methoden/Werkzeugen die im Sinne von Lean dabei helfen können den Kunden bzw. ein Problem besser zu verstehen.

Lean startup

Eignet sich besonders für komplett neue Produkte und Business Modelle (Blue Ocean Projekte). Hier wird etwas schnell, inkrementell gebaut, getestet und ausgewertet. Dann wird dieses Vorgehen wiederholt bis man sich dem nähert was der Kunden möchte. Die Schritte sollten so klein und schnell wie möglich sein. Das Produkt was am Anfang dabei rauskommt nennt sich Minimum Viable Product, das kleinste auslieferbare Produkt. Der Fokus liegt vor allem auch darauf nicht nur Ergebnisse einfach auszuwerten, sondern mit dem Kunden in Kontakt zu treten und ihn zu verstehen. Dies ist eine wirklich knappe Zusammenfassung. Mehr dazu findet Ihr in dem Buch Lean Startup von Eric Ries

Minimum loveable/testable Product

Dies ist eine Alternative zum Minimum Viable Product aus der Lean Startup Methode.  Manchmal ist es dann doch zu wenig Produkt für Kunden um Gefallen daran zu finden. Der Minimum-Viable-Product-Gedanke kann teilweise soweit gehen, dass man zunächst nur Online-Werbung schaltet, für ein Produkt, was es noch nicht gibt, um die Resonanz am Markt zu testen. Das kann allerdings dazu führen, dass Kunden verärgert sind. Das kleinste auslieferbare Produkt wird beim Minimum Loveable Product zum Maximum an Zuneigung der ersten Kunden, die mit geringstem möglichem Aufwand, erreicht werden kann. Glückliche Kunden sind dann meist auch die beste Werbung um ein Produkt groß zu bekommen.

Eine Übersetzung des Originalartikels mit Beispiel von Laurence McCahill ist zu finden auf der-innovationsblog.de

Jobs to be Done / Customer interview

In dieser von Clayton Christensen und anderen entwickelten Methode geht man davon aus, dass Kunden ein Produkt quasi „einstellen“ damit es einen gewissen Job erledigt. Tut es diesen gut wird es noch mal eingesetzt. Wenn nicht, wird es „gefeuert“.

Gerade im Zeitalter von Big Data versuchen Firmen ihre Kunden durch möglichst viele Zahlen zu verstehen und Korrelationen daraus abzuleiten, die oft falsch sind oder falsch verstanden werden und das tiefe Bedürfnis des Kunden nicht aufdecken. Dies ist ein fataler Fehler, der erst sehr spät bemerkt wird.

Um einen Job herauszufinden, der für jemanden erledigt werden soll, kann man sich dagegen auch folgender 5 Fragen bedienen.

  1. Hast Du selbst einen Job der erledigt werden sollte?
    Viele Innovationen kamen von Leuten die selbst vor einem Job standen der erledigt werden musste. So vielleicht auch Henry Ford.
  2. Wo siehst Du Nicht-Kunden?
    Man kann genauso viel von Leuten lernen, die ein Produkt nicht konsumieren, wie von Leuten, die es tun.
  3. Welche Workarounds nutzen die Leute?
    Wenn man so etwas entdeckt ist dies eine große Chance für neue Produkte. Falls schon Produkte in diesem Fall zur Verfügung stehen sind die Kunden wohl sehr unglücklich über die bereitgestellte Lösung und man sollte sie sehr aufmerksam beobachten.
  4. Welche Aufgaben versuchen Leute zu vermeiden?
    Es gibt die Jobs, die erledigt werden müssen. Menschen versuchen aber diese zu vermeiden. Diese Jobs nennen Christensen und Co. „Negative Jobs“.
  5. Gib es Produkte die für Jobs benutzt werden für die sie gar nicht gedacht waren?
    Manchmal wird ein Produkt oder nur ein kleiner Teil eines Produktes zweckentfremdet genutzt und erledigt einen Job für den es gar nicht vorgesehen war.

Jobs werden zudem in zwei Typen eingeteilt:

  1. Hauptjob: Beschreibt die Aufgabe die erledigt werden soll.
  2. Nebenjob/Zugehörige Jobs: Aufgaben die im Zuge mit erledigt werden.

Jeder dieser Typen besteht aus zwei Seiten:

  1. Funktionale Seite:  Die objektive und praktische Anforderung an das Produkt.
  2. Emotionale Seite: Die subjektiven Anforderungen hinsichtlich Gefühle und Erwartungen

Die Emotionale Seite wird dann letztendlich noch in 2 Dimensionen dargestellt:

  1. Persönlich: Persönliche Wahrnehmung der bereitgestellten Lösung.
  2. Sozial: Wie wird man von anderen wahrgenommen wenn man diese Lösung benutzt.

Am besten entwickelt man dann ein Interview welches einem die genannten Antworten und Informationen direkt vom Kunden liefert.

Quelle: Havard Business Review „Know Your Customers’ “Jobs to Be Done” von Clayton M. Christensen, Taddy Hall, Karen Dillon und David S. Duncan

Kano Model

Das Kano Model wird häufig als Priorisierungsmethode für Backlogs eingesetzt. Mit dieser Methode wird aber auch die Erwartung der Kunden an das Produkt aufgedeckt bzw. versucht zu verstehen. Zumindest mehr als bei anderen Priorisierungstechniken. Oft kommt man mit dieser Methode allerdings dazu sich mit der Konkurrenz zu vergleichen, z.B. welche Begeisterungsmerkmale sie hat und verliert somit den Kunden aus dem Auge. Trotzdem eine empfehlenswerte Methode.

Mehr zu diesem Modell unter https://de.wikipedia.org/wiki/Kano-Modell

Lean consumption

Hier schaut man auf den Prozess den ein Kunden bei dem Konsum des Produktes durchläuft und versucht diesen durch Veränderung möglichst schlank zu halten. Es gilt die Beachtung folgender 6 Prinzipien um den Kunden höchsten Respekt zu zeugen und vor allem dessen Zeit und Nerven zu schonen:

  1. Löse das Kundenproblem komplett indem Du sicherstellst dass alle Waren und Services funktionieren und auch zusammen funktionieren.
  2. Verschwende nicht die Zeit des Kunden.
  3. Stelle dem Kunden genau das was er will zur Verfügung.
  4. Stelle das richtige am richtigen Ort zur Verfügung.
  5. Stelle das richtige am richtigen Ort zur richtigen Zeit zur Verfügung.
  6. Finde ständig neue Lösungen um dem Kunden mehr Zeit und Ärger zu ersparen.

Der ein oder andere hat beim Lesen dieser Liste wahrscheinlich schon einige Unternehmen im Kopf, die das nicht beherzigen. Amazon hingegen betreibt Lean Consumption ziemlich gut. Es wird z.B. das Zahlungsausfallrisiko eingegangen um es Kunden zu ersparen ihre CVV/CVC einzugeben oder die immer kürzeren Lieferzeiten die bis hin zur Lieferung am gleichen Tag gehen. Man benötigt sehr wenige Klicks um etwas auf Amazon zu kaufen oder in den Apps einen Film auszuwählen, Amazons Test mit Supermärkten ohne Kassen und und und. Das alles zeigt wie sehr sie diese Prinzipien beherzigen.

Der Artikel „Lean consumption“ von James P. Womack und Daniel T. Jones erschien 2005 in der Havard Business Review

Elements of value

Mit zusammen 30 Jahren Erfahrung in Markt- und Konsumforschung haben Eric Almquist, John Senior und Nicolas Bloch 30 Elemente, die Wert schaffen, identifiziert.

Diese Elemente werden 4 Kategorien zugeordnet, welche in einer Pyramide angeordnet werden und die Maslowsche Bedürfnis-Pyramide erweitern. Hier vom Fundament bis zur Spitze aufgelistet:

  1. Funktional: Spart Zeit, Vereinfacht, Bringt Geld, Reduziert Risiko, Organisiert, Integriert, Verbindet, Reduziert Mühe, Vermeidet Ärger, Reduziert Kosten, Qualität, Vielfalt, Sinnesreiz, Informiert
  2. Emotional: Reduziert Angst, Belohnung, Nostalgie, Design/Ästhetik, Auszeichnung, Wellness, Therapeutischer Wert, Spaß/Entertainment, Attraktivität, Zugang
  3. Lebensverändernd: Stiftet Hoffnung, Selbstverwirklichung, Motivation, Erbstück (für zukünftige Generationen), Zugehörigkeit
  4. Sozialer Einfluss: Selbstüberschreitung (Man tut z.B. was Gutes für andere mit dem Kauf eines Produktes)

Je nach Industrie, Kultur oder Demographie sind andere Elemente mehr oder weniger wichtig. Je mehr Elemente und Kategorien ein Produkt bedient, desto erfolgreicher ist es. Apple deckt z.B. mit seinen Produkten überdurchschnittlich viele Elemente ab.

Mehr dazu auch in der Havard Busines Review unter: https://hbr.org/2016/09/the-elements-of-value

#NoProjects

Möchte man ein Unternehmen mehr bzw. vollständig auf das Schaffen von Kundenwert ausrichten, ist es fast unerlässlich von Projektdenken wegzukommen und ein Mindset rund um Produkteentwicklung aufzubauen.

Der Erfolg eines Projektes wird oft daran gemessen ob es die geplante Zeit, Budget und Scope eingehalten hat. Am besten alle drei auf einmal. Danach widmet man sich dann dem nächsten Projekt, wenn nicht allzuviel Nacharbeiten notwendig sind, da man unter Umständen die Testphase verkürzt hat, weil der Puffer schon aufgebraucht war, weil man unbedingt die Deadline einhalten wollte 😉

Bei einem Produkt-Mindset wird der Erfolg eher an User-Retention, Marktanteil, Kundenzufriedenheit usw. gemessen.

Ein weiterer Vorteil einer Ausrichtung auf Produkte ist die Etablierung von Produktteams die ständig zusammen das gleiche Produkt entwickeln und erweitern und sich nicht nach einem Projekt auflösen. Solche Teams sind oft viel effektiver, da sie sich besser mit dem Produkt identifizieren können und vor allem effizienter arbeiten über die Zeit.

Mehr dazu auch auf Twitter unter #NoProjects

Das Produkt, falls es schon existiert, selber benutzen…

und versuchen es zu lieben. Klingt abwegig. Viele machen es aber nicht. Dabei ist dies tatsächlich die einfachste Methode um herauszufinden welchen Wert ein Produkt schafft bzw. was dazu noch fehlt. Man muss allerdings auf seine Betriebsblindheit achten und vor allem nicht aus Sicht anderer drauf schauen!

 

Es gibt sicherlich noch viele weitere Methoden, Werkzeuge oder Blickwinkel die man hier aufzählen könnte. Ich habe die ausgewählt, die für mich am sinnvollsten klingen (momentan) oder mit dene ich selber gute Erfahrung gesammelt habe. Wenn euch noch Sachen fehlen, die ihr gerne teilen möchtet, dann bitte gerne in den Kommentaren. Stoße ich persönlich noch auf Methoden die genannt werden sollten werde ich dies in einem weiteren Blogartikel machen den ich hier dann selbstverständlich verlinke.

 

Nur wer schlank ist, ist auch schnell und wendig und damit fit für die Zukunft.

Auf Organisationen angewendet beudetet dieser Satz dass nur eine „lean“ gemanagte Organisation eine wirklich agile Organisation werden kann, die auf Dauer überlebensfähig ist.

Um zu verstehen wie ich diesen Satz meine, möchte ich zunächst die beiden Begriffe „lean“ und „agil“ näher erläutern. Das gemeinsame Verständnis dieser Begriffe ist, nebenbei gesagt, nicht nur bei einer Einführung agiler Methoden besonders wichtig, sondern auch wenn man schon länger mit diesen unterwegs ist.

Lean

Der Duden sagt hier folgendes: wohlproportioniert groß und zugleich schmal gewachsen, geformt.

Nach Womack und Jones* sind die Kernelemente von Lean Management die Befolgung von fünf Kernprinzipien. Ganz ganz kurz zusammengefasst sind dies:

  1. Den Wert aus Sicht des Kunden definieren
    Fokus des gesamten Unternehmens auf den Kunden. Frage dazu: Wie machen wir die richtigen Dinge?
  2. Den Wertstrom identifizieren
    Vermeidung von Verschwendung im wertschöpfenden Prozess
  3. Das Fluss-Prinzip umsetzen
    Fokus auf Effizienz. Frage: Wie machen wir die Dinge richtig?
  4. Das Pull-Prinzip einführen
    „Beim Pull-Prinzip (→ Kanban) zieht man (engl. to pull) vom Kunden aus gesehen die Produkte durch die Produktion, anstatt sie durch Planungsvorgaben in die Produktion zu drücken“
  5. Perfektion anstreben
    Etablierung einer lernenden Kultur in der Organisation

Agil

Der Duden sagt hier: von großer Beweglichkeit zeugend; regsam und wendig

Auf Organisationen gerichtet, bedeutet dies schnell und wirksam auf den Markt zu reagieren um Wettbewerbsvorteile zu haben. Agile Softwareentwicklung richtet sich dabei auf das Agile Manifest. Nicht mehr, aber vor allem auch nicht weniger!

Prinzipien die hier zum tragen kommen sind zusammengefasst: Transparenz, Überprüfung und Anpassung

Werte die dabei wichtig sind werden unter anderem bei der Methode Scrum im Scrum Guide beschrieben sind aber bei anderen agilen Methoden wie z.B. Kanaban genauso wichtig:

  1. Selbstverpflichtung / Commitment
  2. Mut
  3. Fokus
  4. Offenheit
  5. Respekt

Fazit

Alles in allem geht es eigentlich darum ein Mindset rund um die leanen (lean thinking) und agilen Prinzipien zu bekommen und dies dann ins tägliche handeln einfließen zu lasssen. Diese Veränderung dauert meist und ist selten ganz abgeschlossen. Ganz nach dem Shu-ha-ri Konzept.

Dieser Blog beschäftigt sich mit Methoden, Fallstricken und Wegpunkten auf der Reise Organisationen schlanker und beweglicher zu bekommen und dabei hoffentlich einen dauernden Beitrag zur Veränderung der Arbeitswelt zu leisten. Denn auf dauer kann eine Organisation nur fit sein und ein entsprechendes Mindeset haben, wenn die Menschen auch Spaß daran haben.


*https://www.lean.org/WhatsLean/Principles.cfm