Freitag, 22. August 2025
Deine Muda: Den Schuldigen suchen
Zwölfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Suchen nach einem Schuldigen.
Dass immer dann, wenn irgendetwas schief gelaufen ist, zuerst nach einem Schuldigen gesucht wird, ist ein verbreitetes Phänomen. Wie konnte das passieren? Wer hat da nicht aufgepasst? Wessen Aufgabe wäre es gewesen das zu verhindern? Wer wäre verantwortlich gewesen für einen Prozess der das verhindert? Solche und ähnliche Fragen sind absolute Klassiker, wenn es um die Aufarbeitung geht, und sie alle haben eines gemeinsam: sie sind nicht besonders zielführend.
Zunächst führen sie immer wieder zu einem erstaunlichen Forschungs- und Exegese-Aufwand, um rückwirkend aus irgendeiner Vorschrift oder Abmachung ableiten zu können, wer sich theoretisch oder nach "gesundem Menschenverstand" hätte verantwortlich fühlen müssen, oder wer irgendwann mal eine Zusage gemacht oder eine Aufgabe übernommen hat, aus der sich die Verantwortung für das mittlerweile eingetretene Missgeschick ableiten liesse.
Umgekehrt ergeben sich aus ihnen ähnlich grosse Aufwände, mit denen alle, die für die Schuld in Frage kommen, belegen wollen, dass sie selbst in keinem Fall verantwortlich sind. Auch von ihnen werden alle möglichen Vorschriften, Abmachungen, Protokolle, Pläne, Zuständigkeitsbeschreibungen und sonstigen Dokumente gewälzt werden um mit deren Hilfe nachweisen zu können, zum jeweiligen Zeitpunkt nicht informiert, verfügbar oder zuständig gewesen zu sein.
Und damit endet es nicht. Sind einer oder mehrere Schuldige gefunden worden, werden sie erfahrungsgemäss erhebliche weitere Aufwände in Distanzierungen, Absicherungen und ähnliche Tätigkeiten stecken, um beim nächsten mal nicht mehr Schuld zu sein. Und sollte die Schuldzuordnung unklar gewesen sein, fliessen häufig erhebliche weitere Aufwände inzusätzliche Regeln, Dokumentations-Pflichten und weitere Massnahmen, um das nächste mal die Schuld klarer zuweisen zu können.
Nichts davon erzeugt einen Mehrwert, alles davon verbraucht Zeit und Energie. Es ist Muda in Reinform.
Um eine Alternative aufzuzeigen: statt den Schuldigen zu suchen könnte man überlegen, wie man Prozesse sicherer oder unbürokratischer gestaltet, Kommunikation einfacher und direkter möglich macht, Qualitätssicherungs-Massnahmen einführt die nicht nur aus Dokumentations-Pflichten bestehen und vieles mehr. Das wären Schritte, die zwar auch Aufwand verursachen, aber einen der sich auszahlt und nicht bloss alle Beteiligten frustriert.
Donnerstag, 8. Mai 2025
Deine Muda: Inspect ohne Adapt
 |
| Bild: Unsplash / Glenn Carstens-Peters - Lizenz |
Elfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: Inspect ohne Adapt.
In gewisserweise handelt es sich bei dieser speziellen Ausprägung um eine (wenn nicht sogar die) "agile Muda", da sie vor allem im Umfeld von (schlecht laufender) agiler Produktentwicklung anzutreffen ist. Sie liegt vor, wenn zwar regelmässig nach Verbesserungspotentialen oder Dysfunktionen gesucht wird, ein Auffinden einer solchen aber keine Schritte zur Folge hat, die den Zustand verbessern sollen. Ein klassisches Beispiel dafür wären Retrospektiven ohne Action Items.
Der Verschwendungs-Charakter dieses (Nicht-)Vorgehens ist offensichtlich: für das Suchen, Identifizieren, Beschreiben und Besprechen schlecht laufender Dinge ist Arbeitszeit nötig, und Zeit ist im Unternehmenskontext gleich Geld. Das ist in gewisser Weise gleich doppelt fällig - zum einen für die gerade genannten Tätigkeiten, zum anderen für das Nachholen anderer Aktivitäten, die wegen der so bereits vergebenen Arbeitskapazitäten in die Zukunft verschoben werden mussten.
Ein weniger offensichtlicher aber in seinen Auswirkungen nicht zu unterschätzender Effekt ist der in diesem Rahmen eintretende Motivationsverlust der Mitarbeiter, die erkennen, dass ihnen mit ihren Problemen nicht geholfen wird. Zum einen kann die daraus entstehende Frustration zu nachlassender Arbeitsleistung führen, zum anderen dazu, dass neu auftretende Probleme gar nicht mehr addressiert und bearbeitet werden, da mit ihrer Lösung gar nicht mehr gerechnet wird.
Im schlimmsten Fall entsteht zusätzlich zu diesen Effekten nochmal ein weiterer Verwaltungsaufwand, nämlich dadurch, dass die identifizierten aber nicht gelösten Verbesserungspotentiale und Dysfunktionen ggf. aufbewahrt und aktuell gehalten werden müssen. Die damit verbundenen Untersuchungs-, Informations-, Aktualisierungs- und Repriorisierungs-Aufwände überfrachten das ohnehin schon sinnlose Inspect ohne Adapt nochmal mit einer weiteren Muda, der Lagerhaltung.
Ein derartiges Verhalten abzustellen sollte aus diesen Gründen für jedes agile Team (aber auch für jedes andere Team bei dem es auftritt) eine hohe Priorität haben. Notwendig dafür ist es allerdings, den Teufelskreis einmal initial zu durchbrechen und dem Inspect auch ein tatsächliches Adapt folgen zu lassen, in diesem Fall eine Verhaltensänderung. Ist das aber einmal gelungen, kann in dem so gestarteten Verbesserungszyklus kontinuierlich an Fortschritten gearbeitet werden.
Donnerstag, 23. Mai 2024
Deine Muda: Overthinking
 |
| Bild: Pexels / Thirdman - Lizenz |
Zehnter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann, kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Overthinking.
Zuerst ein Übersetzungsversuch. Für den Begriff Overthinking gibt es keine exkte Entsprechung in der deutschen Sprache, eine sinngemässe Übersetzung wäre "länger über etwas nachdenken als sinnvoll ist" oder "unverhältnismässig lange über etwas grübeln". In beiden Übersetzungs-Varianten ist die Muda-Natur bereits offensichtlich enthalten, bei näherer Betrachtung lassen sich aber ausserdem noch verschiedene Problem-Dimensionen erkennen.
Zum einen kostet ein unnötig langes Nachdenken die Beteiligten (Arbeits-)Zeit und damit ihr Unternehmen auch Geld. Das führt entweder dazu, dass sie nicht mehr für andere Tätigkeiten verfügbar sind (dazu gleich mehr) oder es hat zur Folge, dass zur Kompensation dieser Ausfälle weitere Menschen eingestellt werden müssen. Der zweite Fall wird nochmal schwerwiegender dadurch, dass diese Einstellungen (plus Koordination, Bezahlung etc.) weitere Verwaltungsaufwände erzeugen.
Zum anderen kann es zum Phänomen der Verzögerungskosten (Cost of Delay) kommen. Wird die durch das Overthinking entstehende Mehrarbeit nicht durch zusätzliches Personal kompensiert, schieben sich andere Tätigkeiten zwangsläufig nach hinten, wodurch sich Einnahmen verzögern (und dadurch kleiner ausfallen) können, Geschäfts-Chancen verschwinden können oder zusätzliche Zinsen auf alte oder neue Kredite anfallen können, die zur Kompensation ausfallender Einnahmen nötig werden.
Angesichts dieser Nachteile stellt sich die Frage, warum das Overthinking in vielen (vor allem grossen) Organisationen so weit verbreitet ist. Die Antwort kann natürlich je nach Einzelfall eine andere sein, häufige Gründe sind meiner Erfahrung nach aber Perfektionismus, Machbarkeits- und Steuerbarkeits-Illusionen, Risiko-Aversion (häufig verbunden mit knappen Budgets, deren Verwendung man unter Kontrolle halten will) und fehlende Systemsicht.
Um die nicht gewinnbringende, aber ressourcenverbrauchende Muda des Overthinking in den Griff zu bekommen, ist es daher erfolgsversprechend, zu untersuchen ob eine diese zugrundeliegenden Ursachen gegeben ist, um diese zu thematisieren und möglichst zu beseitigen. Selbst dann wenn das nicht gelingt, kann aber alleine die Erkenntnis der problematischen Effekte ausreichend sein, um ein Zurückfahren der Grübel-Aufwände auf ein sinnvolles Mass zu verursachen.
Donnerstag, 26. September 2019
Deine Muda: Langfristige Detailplanung
 |
| Grafik: Pxhere / Mohamed Hassan - CC0 1.0 |
Neunter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: die langfristige Detailplanung.
Warum langfristige Detailplanung eine Muda ist, ist einfach zu erklären: überall dort wo Arbeit in einer komplexen Umgebung stattfindet (→ dort wo sich Menschen uns Systeme unvorhersehbar verhalten und auf unvorhersehbare Art und Weise mit einander interagieren1) wird die Realität früher oder später zwangsläufig von der Planung abweichen. Sobald das geschieht müssen die Pläne an die geänderte Realität angepasst werden, wodurch die bisherige Planung automatisch obsolet wird.2 Die bereits in sie investierten Aufwände waren umsonst.
Die Alternative zu diesem Vorgehen kommt ebenfalls aus dem Toyota Production System: Just in Time Delivery, oder für diesen Verwendungszweck abgewandelt: Just in Time Planning. Detailplanung sollte nur in überschaubarem zeitlichen Abstand zur Umsetzung stattfinden, da proportional zum diesem kürzer werdendem Abstand die Wahrscheinlichkeit sich ändernder Rahmenbedingungen abnimmt. Das Risiko für die Tonne zu arbeiten lässt sich so minimeren (um Missverständnissen vorzubeugen: das bedeutet keine Planlosigkeit, aber an die Stelle der Detailplanung tritt eine Vision).
Das Problem bei der Abschaffung der langfristigen Detailplanung: viele grosse Organisationen haben ihre gesamte Planungs- und Reportingstruktur auf sie ausgerichtet. Noch immer herrscht in ihnen der Glaube vor, dass man nur gut genug vorausdenken müsste um alle Eventualitäten zu berücksichtigen, und ein Abweichen von diesen Glaubenssätzen wird ignoriert oder sanktioniert (siehe auch die Antipattern der scheinbaren Imitation und der scheinbar umfassenden Planung). Für eine Verhaltensänderung ist also viel Überzeugungsarbeit nötig.
Einen Ausweg aus dieser Situation bietet - Ironie der Geschichte - ausgerechnet das meistens mit langfristiger Detailplanung einhergehende langfristige Detailreporting. Überall dort wo jeder einzelne Konzeptions-, Umsetzungs- und Testaufwand erfasst, festgehalten und mit einer Buchungsnummer versehen ist kann man problemlos aufzeigen wie viel Arbeitszeit (und damit Geld) sinnlos ausgegeben wurde, weil die Realität nicht mehr zum Plan passt. Die Muda wird damit sichtbar und messbar - und so zu einem gewichtigen Argument um an Veränderungen zu arbeiten.
1Es gibt natürlich auch nicht-komplexe Umgebungen, aber um die soll es hier nicht gehen.
2In manchen Organisationen wird stattdessen versucht die Realität an die Planung anzupassen. Ein Thema für sich.
Montag, 15. Juli 2019
Deine Muda: Defects
 |
| Bild: Pixabay / EME - Lizenz |
Für jeden nachvollziehbar ist die versehentliche Erzeugung: dort wo Menschem am Werk sind werden Fehler gemacht und manchmal haben diese Fehler zur Folge, dass nicht (oder nur eingeschränkt) funktionierende Produkte erzeugt werden. Sobald das auffällt müssen Nacharbeiten stattfinden, was an sich schon ärgerlich ist. Wenn die Fehler es ausserdem noch unentdeckt durch die Qualitätskontrolle geschafft haben kommt noch der Image-Schaden dazu.
Weniger nachvollziehbar aber häufiger als man denkt ist die bewusste Produktion fehlerhafter Ergebnisse. Sei es, dass die Fertigung nicht funktioniert wie sie soll oder dass einzubauende Komponenten nur in minderer Qualität vorliegen - dort wo Quoten oder Deadlines eingehalten werden müssen ist die Verlockung gross das Problem nach hinten zu verschieben und zu reparieren "sobald Zeit dafür da ist" (was schlimmstenfalls nie der Fall sein wird).
Die offensichtlichste Folge von fehlerhaft erzeugten Produkten sind zusätzliche Kosten. Sowohl die Reparaturaufgaben als auch die nachgelagerte Qualitätssicherung kosten Arbeitszeit (und damit auch Geld), dazu kommen noch weitere Faktoren: die Verlängerung der Zeit in der Fertigung oder Reparatur verzögert auch den den Zeitpunkt des Verkaufs (→ totes Kapital, Cost of delay), schlimmstenfalls kommen Vertragsstrafen oder Materialkosten dazu.
Weniger offensichtlich aber von ähnlich schweren Auswirkungen ist die Störung des Arbeitsflusses. Immer wieder müssen bereits begonnene Arbeiten unterbrochen werden um Reparaturen vorzunehmen oder die Qualität zu überprüfen, im schlimmsten Fall müssen Dokumentationen ergänzt, Warnhinweise angebracht oder Kundenservice-Aufgaben übernommen werden. Sowohl die dadurch verursachten Konzentrationsstörungen als auch die ständigen Kontextwechsel verlangsamen die Abläufe und können weitere Fehler verursachen.
Die Massnahme zur Vermeidung fehlerhafter Produktion gehört zu den Elementen die das Toyota Production System berühmt gemacht haben: sobald ein Fehler entdeckt wird, wird die gesamte Produktion angehalten und der Produktionsprozess einschliesslich aller vor- und nachgelagerter Schritte wird repariert und verbessert. Das Besondere daran: die Berechtigung zum Anhalten der Produktion hat nicht nur das Management sondern jeder einzelne Angestellte. Nur so lässt sich der Reparatur-Prozess so schnell beginnen, dass möglichst wenig fehlerhafter Ausstoss entsteht.
Montag, 15. April 2019
Deine Muda: Overprocessing
 |
| Bild: Pixabay / Geisteskerker - Lizenz |
Die meisten Angestellten kennen es - ein Grossteil ihres Arbeitstages besteht aus Tätigkeiten die nicht zur Wertschöpfung beitragen sondern die Befolgung von Dokumentations-, Beantragungs- oder Arbeitsvorschriften sind. Sind die Empfänger einer Mail nach Hierarchie geordnet? Wurde für den Antrag das vorgeschriebene gelbe Formular verwendet und nicht das blaue? Waren alle Mitarbeiter in der Anwendungsunterweisung für die neuen Bürostühle?
Die offensichtlichte Folge einer derartigen Überregulierung sind steigende Kosten. Die für die Befolgung und Umsetzung der Vorschriften nötige Zeit ist Arbeitszeit die dann an anderer Stelle fehlt. Die ursprüngliche Intention kann sich so in ihr Gegenteil verkehren. Statt alles effizienter und billiger zu machen (das ist nämlich die Absicht der meisten Prozesse) wird alles langsamer und damit teurer. Und auch das lässt sich noch steigern: wenn ganze Stellen geschaffen werden die nichts anderes machen als Prozesseinhaltung zu überwachen. Auch die kosten Geld.
Ein weiterer Effekt von Überregulierung kann sein, dass nicht nur Zusatzaufwand entsteht sondern bestehende Prozesse sich verschlechtern, etwa wenn durch den Versuch Menschen besser auszulasten Staus entstehen. Hinter diesem Phänomen steckt meistens das Gesetz der Penetranz der negativen Reste: um die letzten Effizienzreserven zu heben werden Regulierungen eingeführt die für diesen Zweck unverhältnismässig kompliziert sind - und statt zu Verbesserungen kommt es zu Verschlechterungen.
Weitgehend unberücksichtigt kommt noch ein dritter Faktor dazu: eine starke Regulierung des Arbeitsalltags kann schnell dazu führen, dass nicht mehr offensichtlich ist an welche Vorschriften man sich jetzt halten muss. Ist bei der Beantwortung einer Beschwerde nur der Leitfaden für Kundenkontakt zu beachten oder auch der für lösungszentrierte Kommunikation und der für revisionssichere Fach-Dokumentation? Derartige Unklarkeiten führen schnell in Regel-Aversion und informelle Strukturen, beides mit Effektivitätsverlusten als Folge.
Aus diesen Gründen ist es empfehlenswert die vorgegebenen Prozesse und Regulierungen möglichst gering zu halten und regelmässig zu überprüfen ob die bestehenden sich nicht abschaffen lassen. Im letzten Fall wichtig: abschaffen, nicht durch andere ersetzen. Sonst ist nicht viel gewonnen.
Donnerstag, 14. März 2019
Deine Muda: Overproduction
 |
| Bild: Flickr / Jordi Bernabeu Farrús - CC BY 2.0 |
In Bezug auf die Gemeinsamkeiten von Hardware- und Softwareproduktion gibt es zunächst eine große Überschneidung mit der gerade erwähnten Lagerhaltung. Zuviel produzierte Güter können nicht schnell genug verkauft werden und müssen gelagert werden. Da die Produktion bereits bezahlt ist, die Verkaufserlöse aber noch nicht eingegangen sind, binden die Produkte in diesem Zustand Geld, sind also totes Kapital.
Gleichzeitig bindet die Überproduktion Menschen und Maschinen die an anderer Stelle fehlen, wodurch sich dort die Arbeitsfortschritte verzögern. Im schlimmsten Fall kommt es sogar zu zusätzlichen (und eigentlich unnötigen) Neueinstellungen und Neuanschaffungen, durch die es zu einer dauerhaften Zunahme von Lohn- und Instandhaltungskosten kommt, ohne dass diese durch Gewinne refinanziert werden.
Zusätzlich zu diesen Faktoren kommt es zu Verschleisserscheinungen, und zwar sowohl bei Maschinen als auch bei Menschen. Während die ersten sich durch Gebrauch abnutzen tritt bei den Mitarbeiter nicht nur physischer sondern auch psychischer Verschleiss auf. Die Erkenntnis am Markt vorbeizuproduzieren kann deprimmierend sein und sich negativ auf Arbeitsmoral, Engagement und Sorgfalt auswirken.
Softwarespezifisch kommt ein weiterer Faktor dazu, nämlich die unnötige Aufblähung der Code Base und des Funktionsumfangs. Diese sorgen zunächst für gesteigerte Kosten bei Wartung und Instandhaltung, langfristig aber auch für erhebliche Mehraufwände in der Weiterentwicklung, da mit dem Umfang auch die Menge der nötigen Integrations- und Regressionstests, des Bugfixings und des Refactorings steigt.
Zur Behebung dieser Misstände reicht es daher in der Software (anders als im Fall der Hardware) nicht aus einfach die Produktion zu drosseln. Darüber hinaus ist auch ein Rückbau der bereits implementierten Feature-Überproduktion nötig um die negativen Effekte abzustellen. Man zahlt also doppelt, einmal für die Überproduktion selbst, einmal für den Rückbau. Ein Grund mehr, damit gar nicht erst anzufangen.
Montag, 22. Oktober 2018
Deine Muda: Warten
 |
| Bild: Wikimedia Commons / Siyuwj - CC BY-SA 3.0 |
Ähnlich wie in vielen anderen Zusammenhängen ist auch das Warten aus mehr als einem Grund problematisch. Zum einen weil es dazu führt, dass bestimmte Arbeiten später fertig werden, zum anderen wegen der Tätigkeiten die währdenddessen durchgeführt werden. Denn Nichtstun bedeutet in diesem Kontext nicht etwa völlige Untätigkeit, sondern lediglich die Untätigkeit in Bezug auf eine bestimmte Arbeit.
Zunächst aber zu den Verspätungen. Man kann es ohne grosse Erläuterungen verstehen: wenn ein Produktionsprozess immer wieder so lange angehalten werden muss, bis bestimmte Vor- oder Zuarbeiten erledigt sind, dann verlängert sich dadurch die Produktionsdauer. Wie im Fall fast aller anderen Mudas wird das Produktionsmaterial dadurch zeitweise dem Wirtschaftskreislauf entzogen. Es entsteht totes Kapital. Aber das ist noch nicht alles.
Als zweiter Effekt kommt es zu dem so genannten Cost of Delay, bzw. zu Verspätungskosten. Wäre der Produktionsprozess schon früher beendet gewesen, hätte man mit seinem Ergebnis bereits Geld verdienen können. Die Summe die einer Firma dadurch entgeht, dass das nicht möglich ist, ist mit dem Begriff des Cost of Delay gemeint.
Auch damit sind aber noch nicht alle negativen Effekte erwähnt. Was noch fehlt sind die weiter oben genannten Tätigkeiten die währdenddessen durchgeführt werden. Mit dem Warten ist nämlich das Warten des Produkts auf seine Fertigstellung gemeint, nicht etwa das Warten eines Angestellten auf Beschäftigung. Der beginnt in der Regel währenddessen bereits mit dem nächsten Arbeitspaket.
In der Praxis sieht das so aus, dass sobald an einer Arbeit kein Fortschritt mehr möglich ist eine zweite begonnen wird, sobald es auch an der nicht mehr weitergeht eine dritte, etc. Sobald die für das Weiterarbeiten an der ersten Aufgabe notwendige Zulieferung erfolgt ist werden die später begonnenen unterbrochen, es geht mit der ersten weiter, nach deren Abschluss wieder mit den späteren.
Wird auf diese Art und Weise vorgegangen treten aber zwangsläufig Probleme auf: zum einen das Multitasking mit seinen üblichen Begleiterscheinungen von Konzentrationsverlust und Umgewöhnungsaufwand, zum anderen Priorisierungskonflikte. Was ist jetzt wichtiger, die Wiederaufnahme der schon länger wartenden ersten Aufgabe oder das störungsfreie Weiterarbeiten an einer späteren? Auch diese Konflikte kosten Zeit und Geld.
In Summe sind die genannten Folgen von Wartephasen im Produktionsprozess so kostspielig, dass nach Möglichkeit versucht werden sollte sie zu vermeiden. Die einfachste Möglichkeit dazu ist die Bildung eines Crossfunktionales Teams. Wenn alle Tätigkeiten selbst erledigt werden können verschwindet mit der Abhängigkeit von anderen Gruppen die häufigste Ursache des Wartens.
Auch andere Ansätze sind möglich, etwa die bessere Abstimmung von Teams untereinander (Just in Time-Delivery) oder das Anhäufen von Vorarbeiten in einem ausreichenden Ausmass um später nicht in Leerlauf zu geraten (ein durchaus sinnvolles, aber häufig auf andere Art problematisches Vorgehen, das man sich gut überlegen sollte).
Was auf jeden Fall bewusst sein sollte: Bemühungen zur Vermeidung von Wartezeiten führen häufig zu anderen nicht gewinnbringenden Tätigkeiten (Transport, Lagerhaltung, etc.), deren Optimierung möglicherweise wieder zu neuen Wartezeiten führt. Der so entstehende Verbesserungsprozess ist dadurch nie abgeschlossen - was auch absolut Sinn macht.
Montag, 27. August 2018
Deine Muda: Motion
 |
| Bild: Wikimedia Commons / Roger & Renate Rössing - CC BY-SA 3.0 |
Dass diese Personenbewegung als nicht gewinnbringende Tätigkeit gesehen wird liegt daran, dass eine Person während sie sich bewegt nicht in der Lage ist an wertschöpfenden Tätigkeiten teilzunehmen. Wer zu Fuss, mit dem Fahrrad, dem Motorrad, der Strassenbahn oder dem Auto unterwegs ist kann währenddessen nicht arbeiten - wenn er im Auftrag der Firma reist kostet er aber Geld (Zeit/Gehalt). Bis zu einem gewissen Grad kann das in einigen Fällen ausgeglichen werden (z.B. ist arbeiten im Zug eher möglich, zumindest am Computer), auch hier geht aber Zeit durch Planung, Umsteigen, etc. verloren.
Sogar innerhalb eines Gebäudes kann dieses Problem auftreten, besonders dann wenn es sich um Hochhäuser oder weitläufige Anlagen handelt. Ein Scrum Team bei dem die Entwickler im Erdgeschoss sitzen, der PO aber im 10. Stock wäre ein solcher Fall. Ein Team das seinen Arbeitsbereich im Flügel G hat, seinen Meetingraum aber im Flügel B ein anderer. Beides sind real existierende Beispiele aus deutschen Konzernen und in beiden Fällen werden erstaunliche Zeitmengen in Fluren, in Treppenhäusern und in Fahrstühlen verbracht.
Die Besonderheit der Motion-Muda ist, dass für ihre Beseitigung zwei Ansätze möglich sind: man kann die Mitglieder eines Teams oder einer Wertschöpfungskette in einen Raum setzen (oder zumindest auf einen Flur) oder man kann versuchen sie durch digitale Lösungen zu vernetzen, etwa durch Chatprogramme, Videotelefonie und Ticket-Tools. Aus Sicht eines Agile- oder Lean-Coaches wäre Ansatz eins zu bevorzugen, da er einfachere und direkte Kommunikation ermöglicht, in den meisten grossen Organisationen findet man eher Ansatz zwei, da er mit den ohnehin an jedem Arbeitsplatz stehenden Computern einfacher umzusetzen ist.
Dort wo ernsthaft an der Reduzierung von Personenbewegung gearbeitet wird tritt übrigens ein interessanter Seiteneffekt auf: in den meisten Fällen führen diese Bemühungen dazu, dass Teams kleiner, autarker und crossfunktionaler werden. Nur dann lässt sich die Anzahl der für die tägliche Arbeit nötigen Meetings herunterfahren. Der Grossteil aller Personenbewegungen hat nämlich das gleiche Ziel: einen Meeting-Raum.
Donnerstag, 26. Juli 2018
Deine Muda: Inventory
 |
| Bild: Flickr/GOVBA - CC-BY-2.0 |
Zunächst zum Grundsätzlichen: warum ist Lagerhaltung ein Problem? Weil Güter die gerade gelagert werden gebundenes und nicht nutzbares Geld darstellen. In ihren Einkauf oder ihre Herstellung musste bereits investiert werden, so lange sie irgendwo gestapelt liegen kann mit ihnen aber kein Gewinn erwirtschaftet werden. Man spricht in diesem Zusammenhang auch von totem Kapital. Lagerhaltung zu vermeiden erhöht demnach die Liquidität und spart nebenbei noch die Kosten für die Anlagen in denen die Lagerung stattfindet.
Auch in der Softwareentwicklung gibt es das Phänomen, dass "auf Halde" produziert und dadurch totes Kapital angehäuft wird. Es tritt da auf wo Deployment- und Rollout-Prozesse so schwerfällig, bürokratisch und arbeitsaufwändig sind, dass ein Go Live neuer Features nur alle paar Monate möglich ist, im schlimmsten Fall nur ein- oder zweimal pro Jahr. Auch hier liegt zwischen dem Ausgeben von Geld für Lizenzen und Gehälter und dem Erwirtschaften der ersten Gewinne des neuen Produkts ein langer Zeitraum. Wirtschaftlich vernünftig ist das nicht.
Was spezifisch in der Software-Industrie dazukommt ist das Risiko, dass mit veraltenden Anwendungsteilen einhergeht - und veraltet ist Software mitunter schon nach mehreren Monaten "Lagerzeit". Wenn über längere Zeit hinweg Features zwar produziert aber nicht integriert werden (oder nicht mit echten Produktionsdaten laufen, oder keine echte Schnittstellenanbindung haben, etc.), dann steigt die Wahrscheinlichkeit, dass der Go Live Ausfälle, Hotfixes und übereilte Anpassungen nach sich zieht. Das kostet dann wieder Zeit und Geld.
Um eine derartige Folgen von Lagerhaltung fertiger Features zu vermeiden ist es nötig, dass die für einen Go Live nötigen Prozesse und Arbeitsschritte verschlankt, beschleunigt, digitalisiert und automatisiert werden. Erst wenn es möglich ist mindestens monatlich auf Produktion zu deployen können totes Kapital und ausufernde Integrations- und Bugfixing-Phasen vermieden werden. Das ist zwar nicht einfach, es ist aber machbar. Und es ist ein Business-Case.
Montag, 25. Juni 2018
Deine Muda: Transportation
 |
| Bild: Pixabay / Skitterphoto - Lizenz |
Kurz zum Hintergrund: solange Güter von A nach B transportiert werden, können sie nicht weitergegeben oder weiterverarbeitet werden, sie bilden also totes Kapital. Zusätzlich dazu verbraucht der Transportvorgang weitere Ressourcen, von der Arbeitszeit des Fahrers über das verbrannte Benzin bis hin zum Verschleiss des Fahrzeugs. Aus diesen Gründen gilt Transport als Muda.
Der irritierende Punkt - in vielen Firmen in denen ich gearbeitet habe sind Transporte noch ein Alltagsphänomen, und das obwohl es sich fast ausschliesslich um Branchen der IT- und Wissensarbeit handelt, in denen die Digitalisierung eigentlich dafür gesorgt haben müsste, dass alles zentral abgelegt oder per Mausklick um den Globus geschickt werden kann. Allein - oft ist dem nicht so. Überall wird noch Papier befördert.
Zwar seltener werdend aber noch immer zu finden sind die Laufmappen in denen die Hauspost Briefe und Formulare durch die Gegend fährt, häufig anzutreffen sind Lieferungen gedruckter (und schnell veraltender) Anleitungen, Anforderungen und Dokumentationen sowie Prospekte, Kataloge und Mitarbeiterzeitschriften. Einige besonders skurrile Sonderfälle bilden die Transporte digitaler Datenträger, etwa von Disketten und CDs.
Das all das auch gegenwärtig noch stattfindet lässt sich in der Regel mit zwei Ursachen erklären. Zum einen hängen gerade ältere Mitarbeiter noch an der haptischen Erfahrung von Papier und fordern diese immer wieder ein, zum anderen wird die Digitalisierung von Prozessen oft nicht mehr vorangetrieben, sei es weil man sie für abgeschlossen hält oder sei es weil gerade andere Vorhaben wichtiger sind.
Selbst wenn man es kaum glauben mag - auch heute sind in der IT- und Wissensarbeit die fehlende Digitalisierung und der damit verbundene Transportaufwand grosse Probleme. Diese anzugehen bietet noch immer ein grosses Potential für mehr Effektivität und weniger Transportation-Muda.
Montag, 6. März 2017
Deine Muda (ist gar keine)
 |
| Bild: Wikimedia Commons - Public Domain |
In der Initiierungsphase von Scrum- oder Kanban-Implementationen sitzen aufgrunddessen oft Stakeholder mit am Tisch für die erstmal alles Neue dem Verdacht unterliegt Verschwendung zu sein2. Plannings alle zwei Wochen? Verschwendung! Retrospektiven? Verschwendung! Backlog Refinements? Verschwendung! Reviews? Verschwendung! Und so weiter. Schließlich wird in dieser Zeit ja nichts produziert. Die Ironie der Geschichte: in anderen Kontexten könnten sie sogar recht haben, beispielsweise bei der Produktion von seriell gefertigter Hardware, oder beim Betrieb eines Callcenters. Dort wo Software entwickelt wird ist es jedoch grundlegend anders.
Anders als im Fall der beiden gerade genannten Beispiele besteht Software-Entwicklung nicht aus der Wiederholung immer gleicher Arbeitsschritte, die so effizient gestaltet sind, dass man von ihnen nicht abweichen sollte. Die kann es nur dort geben wo ein standardisiertes Produkt in hoher Stückzahl auf standardisierte Weise erstellt wird. Bei Software wäre eben das die Verschwendung - warum sollte man den Erstellungsprozess permanent wiederholen, wenn es doch ausreicht den Code einfach mit Copy & Paste zu duplizieren? Dementsprechend macht das auch niemand. Was in Software-Projekten erstellt wird sind Prototypen: noch nie zuvor hat jemand für dieses Problem und mit dieser Technologie eine Lösung gebaut. Bestenfalls gibt es ähnliche Probleme, deren Lösungen man "nur noch" anpassen muss - auch das ist dann aber wieder prototypisch.
Aber heisst das nicht, dass es Lean Management in der IT gar nicht geben kann? Keineswegs! Es sieht hier nur anders aus. Da im Entwicklungsprozess permanent und an allen Enden neue, bis dahin noch nicht voraussagbare Probleme auftauchen benötigt man permanente Analyse- und Lösungs-Prozesse. Diese durch verschiedene Hierarchie- oder Eskalations-Ebenen zu schicken würde zu Overhead führen: entweder wären die oben sitzenden Entscheider permenent überlastet oder es würden so viele von ihnen benötigt, dass sie sich koordinieren müssten, mit Bürokratie als Folge. Das kann also nicht der Weg sein.
Lean in diesem Kontext kann nur bedeuten: permanent auftauchende neuartige und einzigartige Probleme müssen möglichst weit unten in der Hierarchie gefunden, analysiert und behoben werden, und zwar mit möglichst individuellen Lösungen. Das ist dann aber nichts Anderes als regelmässiges inspect & adapt in Form von Plannings, Retrospektiven, Refinements und Reviews. Mit anderen Worten: in der IT ist Lean von Agil nicht zu trennen. Siehe oben.
Bleibt nur noch eine Frage: was soll die Überschrift dieses Artikels? Die ist ist ein Wortspiel. Sorry, aber manchmal muss das sein.
1Die Diskussion ob Agile eine Methode ich spare ich mir an dieser Stelle
2Ja, mir sind tatsächlich Leute begegnet, die Lean Management und Kanban für unvereinbar gehalten haben
Montag, 21. März 2016
Deine Muda: Under-Utilization
Durch Zufall bin ich auf dieses Video gestossen. Es zeigt die verschiedenen Arten von Verschwendung aus dem Toyota-Produktionssystem, grafisch aufbereitet und mit Beispielen angereichert. Nett anzusehen.Erst auf den zweiten Blick fällt auf, dass die Liste erweitert wurde. Laut Toyota existieren im Lean Management nämlich lediglich sieben Arten der Verschwendung:
- Transportation
Güter werden weit transportiert und sind in dieser Zeit nicht für Wertschöpfungen nutzbar - Inventory
Güter werden in unnötig großen Mengen gelagert und binden dadurch Kapital - Motion
Personen müssen weite Wege gehen und können in dieser Zeit nicht produktiv tätig sein - Waiting
Güter oder Personen müssen darauf warten, dass vorgelagerte Prozessschritte beendet werden - Over-Processing
Komplizierte oder redundante Prozesse binden die Kapazitäten der Mitarbeiter - Over-Production
Güter werden erzeugt obwohl sie nicht oder noch nicht benötigt werden - Defects
Güter werden fehlerhaft erzeugt und müssen nachträglich repariert werden
- Under-utilized People
Das Potential und die Fähigkeiten der Mitarbeiter werden nicht genutzt
