Die Theory of Constraints erklärt || DevOps Series – Episode 8

In diesem Artikel erklären wir dir alles rund um die Theory of Constraints von Goldratt. Also was ist ein Bottleneck (Flaschenhals) bzw. ein Constraint (Einschränkung), was die Schritte dieser Methode sind und wir werden natürlich auch ein Beispiel für die Theory of Constraint geben.

In der letzten Folge haben wir dir erklärt was ein effektives und gutes Scrum- bzw. DevOps Team ausmacht. Wir sind dabei unter anderem auf die perfekte Größe des Teams, die Rollen im Team und die richtige Teamstruktur eingegangen.

Schau also unbedingt hier vorbei, falls darüber noch mehr wissen willst 😉

Was ist der Unterschied zwischen einem Bottleneck und einem Constraint?

Im Sprachgebrauch der Theory of Constraints (ToC) gibt es einen kleinen aber feinen Unterschied zwischen den Begriffen Bottleneck (Flaschenhals) und Constraint (Einschränkung). Die Definition für einen Flaschenhals könnte man so schreiben:

Ein Flaschenhals ist eine Ressource/Quelle mit einer Kapazität kleiner oder gleich der Nachfrage, der diese Ressource/Quelle unterliegt.

Die Definition einer Einschränkung hingegen würde eher so aussehen:

Eine Einschränkung ist der limitierende Faktor für die Performance des Unternehmens und hindert das Unternehmen daran seine Ziele zu erreichen.

Das bedeutet, dass eine Einschränkung zwar immer ein Flaschenhals ist, aber ein Flaschenhals nicht immer eine Einschränkung!

Um das verständlicher zu machen haben wir mal ein Beispiel aufgezeichnet. In der nachstehenden Grafik sieht man klar, dass sowohl der erste Trichter (ganz links) als auch der dritte Trichter einen Flaschenhals im Gesamtsystem bilden, allerdings ist der Gesamtdurchsatz des Systems nur durch den dritten Trichter limitiert und daher wird auch nur dieser Trichter als Einschränkung bezeichnet.

Flaschenhals vs Constraint

Hier ist nun ganz wichtig zu verstehen, dass es zwar wichtig ist den ersten Flaschenhals des Systems zu beseitigen, allerdings wird man erst, wenn man den zweiten Flaschenhals (3. Trichter) vergrößert einen spürbaren Vorteil im Gesamtsystem merken.

Das Stichwort hier ist globale Optimierung vs lokale Optimierung. Das heißt wir dürfen nicht in Silos denken und diese lokal optimieren, sondern müssen immer das Gesamtsystem im Blick haben und schauen, ob es Downstream oder Upstream von uns andere Probleme/Einschränkungen gibt, die viel größer sind als die eigenen.

Die Theory of Constraints (ToC)

Nun da wir die grundlegenden Unterschiede zwischen einem Flaschenhals und einer Einschränkung erklärt haben, können wir uns auf die Theory of Constraints an sich stürzen und uns die 5 Schritte dieser Methode genauer anschauen.

Aber zu allererst wollen wir natürlich den Erfinder der Theory of Constraints und seinen Bestseller nicht unerwähnt lassen. Es handelt sich dabei um das Buch „The Goal“ von Eliyahu M. Goldratt.

Jetzt kommen wir aber direkt zu den Schritten der Theory of Constraints. Diese 5 Schritte sind in der untenstehenden Grafik veranschaulicht.

Die 5 Schritte der Theory of Constraints

Es ist ganz wichtig, dass es sich hierbei um einen Zyklus handelt, der immer wieder durchlaufen wird und nicht nur einmal. Das liegt daran, dass man nachdem man eine Einschränkung beseitigt hat, sich zwangsläufig eine weitere Einschränkung auftun wird. Das ist wieder sehr gut im ersten Bild zu sehen. Hat man es nämlich geschafft den dritten Trichter auf die Größe des zweiten Trichters zu vergrößern, so wird auf einmal der erste Trichter vom Flaschenhals zur Einschränkung und muss nur vergrößert werden.

1. Schritt: Die Einschränkung identifizieren

Der erste Schritt ist natürlich, die Schwachstelle in der Kette ausfindig zu machen. Das klingt häufig leichter als es wirklich ist, da das System, dass wir untersuchen in der Regel deutlich komplexer sein wird, als das Bild, das wir oben aufgezeichnet haben.

Erschwerend kommt hinzu, dass es meistens, aber nicht immer, einfach oder möglich ist Zeiten an die einzelnen Schritte des Prozesses zu schreiben, um dann z.B. mit Value Stream Management (siehe unten bzw. in einem späteren Artikel 😉 ) die größte Einschränkung des Systems ausfindig zu machen. Das liegt daran, dass diese Einschränkung nicht immer physisch ist (vor allem in der IT), sondern z.B. in der CI/CD-Pipeline ist oder sogar eine Richtlinie ist. Z.B. könnte aber auch das Skillset eines Teams eine Constraint sein, wenn diese für bestimmte Tests/Schritte auf eine andere sehr beschäftigte Person in einem anderen Team warten müssen.

Hierbei sollte man auch immer daran denken, welche dieser potentiellen Einschränkungen außerhalb oder innerhalb meiner Kontrolle ist.

2. Schritt: Die Einschränkung so weit es geht ausnutzen

In diesem Schritt geht es darum, zu untersuchen, ob die identifizierte Einschränkung einfach nur daran liegt, dass die zur Verfügung stehenden Ressourcen oder Mitarbeiter nicht voll genutzt werden und falls ja diese auch voll zu nutzen.

Hier ist uns ganz wichtig, dass Mitarbeiter keine Ressourcen sind, sondern Menschen. Das heißt, dass dieser Schritt NICHT bedeutet von seinen Mitarbeitern einfach mehr zu verlangen, z.B. im Beispiel aus Schritt eins von der eh schon viel beschäftigten Person zu verlangen, dass sie noch mehr arbeitet. Es geht viel mehr darum festzustellen, ob z.B. Hardware-Ressourcen optimal genutzt werden oder noch optimiert werden können. Hier kommen z.B. Orchestrierungstools für CI/CD-Pipelines wie z.B. Kubernetes ins Spiel.

Ziel in diesem Schritt ist es einfach und schnell Verbesserungen der Einschränkung zu erzielen, mit den gegebenen Ressourcen.

3. Schritt: Alles wird dieser Einschränkung untergeordnet

Hierbei wird die Einschränkung klar kommuniziert und zur Nummer 1 auf der Prioritätenliste gemacht. Das heißt, dass alle anderen Verbesserungen nachrangig sind, da die Verbesserung dieser Einschränkung den größten Mehrwert liefert.

In unserem Beispiel heißt das, dass wir festgestellt haben, dass diese Person die größte Engstelle im System ist, das klar aber angemessen kommuniziert wird und man sich jetzt vor allem darauf konzentriert dieser Person mehr Zeit für die wichtigsten Aufgaben zu schaffen oder mehr Kapazität für diese Aufgabe(n) zu bekommen. Das bedeutet auch, dass eine andere Verbesserung, die, wenn man alles richtig analysiert hat, nur geringere Vorteile hätte, mit einer geringeren Priorität bearbeitet wird.

Vorsicht: Hier wird in unserer Erfahrung leider zu gerne nach „einfach“ vs „kompliziert“ priorisiert statt wirklich nach Mehrwert der Verbesserung.

4. Schritt: Die Einschränkung verbessern

In diesem Schritte geht es nun konkret darum die Einschränkung zu verbessern. Ganz aufheben wird meistens nicht gehen, da z.B. in obigem Bild immer einer der Trichter die Engstelle bleiben wird, außer alle sind genau gleich groß (was in einem komplexen System kaum möglich ist. Zumindest haben wir das noch nie erlebt). Aber wie kann dieser Person aus unserem Beispiel nun geholfen werden? Naja z.B. durch WIP Limits, Priorisierung der Aufgaben (eventuell muss diese Person auch noch andere Aufgaben erledigen, die auch jemand anderes machen könnte, oder nicht dringend sind) oder gegebenenfalls dadurch, dass eine weitere Person eingestellt wird, die diese Aufgabe oder andere Aufgaben der Person übernehmen kann.

5. Schritt: Nicht aufhören!

Jetzt da wir die aktuell größte Einschränkung beseitigt haben heißt es weitermachen und von vorne Anfangen. Es gilt nun die nächste Einschränkung zu finden. In unserem Bild von oben ist nun nicht mehr der dritte Trichter die größte Einschränkung, sondern der erste Trichter.

Es gilt hier vor allem nicht durch „Trägheit“ oder Bequemlichkeit nach der ersten Verbesserung aufzuhören, sondern weiter zu suchen, was nun am Dringendsten verbessert werden muss. Es geht also um kontinuierliche Verbesserung, um nicht in Selbstgefälligkeit zu schwelgen und sich nicht weiter zu verbessern. Das sollte dir aus DevOps oder Agile bekannt vorkommen 😉 . Falls nicht schau unbedingt hier bei unseren Trainings vorbei.

Verschiedene Arten von Einschränkungen:

Wie bereits angesprochen gibt es verschiedene Arten von Einschränkungen. In unserem Beispiel war es eine Einschränkung der Fähigkeiten eines Teams und der Kapazität einer bestimmten Person. Es gibt aber auch noch weitere Arten von Einschränkungen:

• Regulatorische Einschränkungen
• Technologische Einschränkungen
• Entscheidungseinschränkungen
• Physische Einschränkungen
• Prozesseinschränkungen
• Finanzielle Einschränkungen
• …

Diese Liste ist sicher nicht vollständig, beinhaltet aber die wichtigsten Arten von Einschränkungen 😉 .

Sollten wir doch noch eine wichtige Art vergessen haben, schreib uns gerne einen Kommentar 🙂 .

Das Ziel der Theory of Constraints:

Das Ziel der Theory of Constraints ist es, anstatt hunderte von KPIs zu messen und dutzende von Verbesserungsinitiativen zu starten, fokussiert man sich viel mehr auf die wichtigste Verbesserung/Einschränkung und behebt eine nach der anderen.

Dies verhindert auch, dass sich sogenannte „Change Fatigue“ (aus DevOps) bei den Mitarbeitern einstellt, weil man die dritte oder vierte Reorganisation innerhalb weniger Monate hinter sich hat und sich nie wirklich was verbessert hat.

Die Theory of Constraints und DevOps

Die Theory of Constraints ist nicht ohne Grund eines der Kernprinzipien von DevOps und Teil der DevOps Trainings und Zertifikate des DevOps Institutes, denn um das ersten Prinzip von DevOps zu meistern ist ein gutes Verständnis der Theory of Constraints unbedingt nötig. Es geht dabei um den Fluss der Arbeit von den Entwicklern zu den Operations-Teams und darum diesen zu optimieren. In den Trainings wird nochmal darauf eingegangen, dass jedes System und jeder Prozess mindestens eine Einschränkung bzw. Flaschenhals hat und dass dies der limitierende Faktor für das Gesamtsystem ist.

„Improving constraints is the fastest and most efficient way to improve the entire process or system.“ – DevOps Foundation Training

Auch wird in den Trainings nochmal spezifisch auf Arten von Einschränkungen eingegangen, die im DevOps Umfeld auftreten können und wie diese z.B. mit Hilfe von Value Stream Management aufgedeckt und weiteren Techniken behoben werden können. Zu Value Stream Management werden wir natürlich auch bald einen Artikel veröffentlichen, also unbedingt den Newsletter abonnieren 😉 .

Aber nicht nur das erste Prinzip von DevOps, sondern auch das dritte Prinzip von DevOps „Continuous Experimentation and Learning“ findet sich in der Theory of Constraints wieder, nämlich im 5. und letzten Schritt, da es hierbei darum geht aus Fehlern und Problemen zu lernen und nie aufzuhören sich zu verbessern. Dieser „Continuous Improvement“-Gedanke wiederum kommt ebenfalls auch in agilen Frameworks, wie Scrum oder Kanban vor.

Beispiel für die Theory of Constraints

Hier wollen wir nun noch kurz ein weiteres Beispiel für den Nutzen der Theory of Constraints im Zusammenhang mit DevOps und speziell einer CI/CD-Pipeline darstellen. Wenn man sich nämlich z.B. die nachstehende CI/CD-Pipeline anschaut, so können sich hier verschiedene Constraints an verschiedenen Stellen ergeben.

Theory of Constraints und DevOps – Beispiel

So können hier z.B. Einschränkungen entstehen, während man die verschiedenen Umgebungen (Testing, staging, production,…) aufsetzt, beim Deployment des neuesten Release-Kandidats, bei der Entwicklung an sich (z.B. auf Grund einer sehr eng verknüpften Architektur) und und und …

Du siehst also wie wichtig es ist über die Theory of Constraints gut Bescheid zu wissen und einen guten Überblick über das gesamte System zu haben.

Die Vorteile

Wenn man es schafft sich wirklich nacheinander auf die jeweils wichtigsten Einschränkungen zu konzentrieren und diese konsequent verbessert (kein Hot-Fix, nur weil wieder keine Zeit ist 😉 ) und sich dann weiter darauf konzentriert die nächste Einschränkung zu verbessern, so ergibt sich ein extremer Vorteil gegenüber anderen Unternehmen, aber auch für die Mitarbeiter. Diese Vorteile sind unter anderem:

• Deutlich erhöhte Produktivität
• Verbesserung der Qualität der Produkte, da man nun auch die Zeit hat darauf zu achten
• Einfachere Prozesse und weniger Wartezeiten für die Mitarbeiter
• Weniger Frust und mehr Spaß an der Arbeit für die Mitarbeiter 🙂

Es lohnt sich also für alle Beteiligten.

Die nachfolgenden Bücher* sind unserer Meinung nach die beste Bücher zum Thema Theory of Constraints bzw. DevOps:

Einfach auf das Bild klicken und direkt bestellen. Alle Bücher werden kostenlos versandt innerhalb Deutschlands (ohne Mindestbestellwert) 😉 .

Fazit

Die Theory of Constraints ist ein sehr wichtiges Konzept, um sich nicht im Wald der möglichen Verbesserungen zu verlaufen, sondern sich auf die wichtigste Verbesserung zu konzentrieren und somit auch den größten Mehrwert für das Unternehmen und die Mitarbeiter zu schaffen.

Das ist auf keinen Fall einfach, da das auch bedeuten kann, dass man sich mit sehr grundlegenden Problemen eines Unternehmens beschäftigen muss und diese eventuell nicht einfach zu verändern sind (z.B. bestimmte Richtlinien oder Abläufe im Unternehmen).

Du brauchst Unterstützung von erfahrenen Coaches bei der Umsetzung bzw. Einführung dieser Konzepte?

Dann melde dich einfach direkt bei uns: Coaching/Training buchen!

Du willst noch mehr wissen und hast noch Fragen oder bist anderer Meinung?

Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!

Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Framework gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:

Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.

Und auch der ist komplett kostenlos. Du findest den Glossar hier:

Ausblick

In der nächsten Folge erklären wir dir, was es alles für Herausforderungen geben kann in einem agilen Umfeld bzw. bei der Transformation hin zu einem agilen Unternehmen.

Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:

Unser Podcast

Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:

Podcast RSS-Feed

Unser YouTube-Channel

Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.

Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.

Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.

Wir freuen uns auf dich in der nächsten Folge.

Deine Agile Coach Academy Gründer Ben und Alex

Mit * markierte Links sind Affiliate-Links mit denen du uns unterstützt dir weiterhin so guten Content zu liefern.

Vielen Dank für deinen Support 🙂

Note: Wir gehen keine Affiliates mit Amazon ein (auch wenn es hier mehr Möglichkeiten gäbe für uns), da die Mitarbeiter hier nicht fair behandelt werden und wir das nicht unterstützen!