Follow my new blog

Sonntag, 20. März 2011

Flow-Orientation für´s Unternehmen - Teil 1, Theory of Constraints

Bei der Softwareentwicklung geht es immer um Geld. Das mag unschön klingen, ist aber nicht zu ändern. Jeder, der sein Geld mit der Entwicklung von Software verdient, muss mit seiner Software dazu beitragen, dass dieses Geld auch reinkommt. Alles, was wir in der Softwareentwicklung tun, muss sich deshalb die Frage gefallen lassen, ob es dem Ziel des Geldverdienens nützt.

Oberstes Ziel eines for-profit Unternehmens ist es, Geld heute zu verdienen und in der Zukunft.

Wenn ich an der Softwareentwicklung etwas verändern will durch Einführung der Methode ABC oder der Technologie XYZ, dann muss ich mir die Frage gefallen lassen, “Bringt das denn etwas?” D.h. ich muss zeigen, dass ABC oder XYZ einen positiven Einfluss auf das Geld hat.

Wie ich nicht nur mit den Prinzipien und Praktien der Clean Code Developer Initiative feststellen durfte, ist das nicht einfach. Entwickler finden die CCD-Bausteine meist wertvoll – das Management hingegen ist nicht so leicht zu überzeugen. “Was bringt es denn, so zu entwickeln?”

Tja… was bringt es denn? Meine persönliche Überzeugung mag noch so groß sein, ein positives Gefühl reicht nicht, um grünes Licht vom Management zu bekommen. Wer verkaufen will, der muss das also im Rahmen der Logik des Käufers tun. Ich muss mir also Gedanken darüber machen, wie es dazu kommt, dass Geld mit Software verdient wird. Erst wenn dich das verstehe, habe ich einen Ansatzpunkt für ein vernünftiges Gespräch mit einem Entscheider.

Leider habe ich kein BWL studiert. Ich bin kein MBA, kein Buchhalter, kein Controller. Meine Annäherung an die “Gelddenke” erfolgt daher aus anderer Richtung. Weil ich bei der Softwareentwicklung gerade den Hammer Flow-Orientation gefunden habe, schaue ich einfach mal, ob das Thema Geld auch ein Nagel ist, den ich damit einschlagen kann – ohne mir auf die Finger zu hauen ;-) Erstmal ein Werkzeug nehmen, das ich schon habe, bevor ich mich nach anderen umschauen, die ich noch lernen muss.

Flüssig Geld verdienen

Es geht also ums Geld verdienen. Wie hängt denn das mit Software zusammen? Ich sage mal ganz naiv, das sieht grundsätzlich so aus:

image

Softwareentwicklung stellt Software in Form von Releases her – und der Vertrieb verkauft die als “Packerl”.

Geld mit Software wird also in einem einem Fluss, einem Prozess verdient. Der hat mindestens und aus großer Flughöhe zwei Schritte. Und solange ich nicht den zweiten Schritt in den Blick nehme, kann ich eigentlich mit keinem Entscheider sprechen.

Das Problem jedes Technikers, der mit einem Manager spricht, wird an diesem Diagramm deutlich. Techniker und Manager haben unterschiedliche Perspektiven:

image

Und ich würde sogar noch weitergehen und sagen, die beiden haben nicht einmal dieselbe Vorstellung vom Gesamtsystem:

image

Und so können sie nicht zueinander kommen. Oder nur schwer. Ist doch eigentlich verständlich, oder?

Wenn ich also in einer Organisation etwas verändern will, dann tue ich gut daran…

  1. …alle Stakeholder an einen Tisch zu bringen; für CCD wären das zum Beispiel mindestens Entwickler und Entscheider.
  2. …sicherzustellen, dass die Stakeholder ein gemeinsames Bild von der Organisation haben.
  3. …dass das gemeinsame Bild in irgendeiner Form an das Ziel gekoppelt ist.

Mit einer flow-orientierten Sicht, einem möglichst vollständigen Bild des Prozesses, bei dem am Ende Geld verdient wird, scheint mir das am einfachsten möglich. Ein Flow macht klar, welche Schritte zu tun sind hin auf das Geld und wie die Zusammenhänge sind.

Geld wird mit Software verdient durch die Kooperation von Rollen. Vertrieb allein nützt nichts, Entwicklung allein nützt auch nichts. Kooperation ist nötig. Und ein Verständnis dafür, wie Produktion in solchen Prozesse auf ein Ziel hin optimiert werden kann.

Produktionsprozesse optimieren

Bevor ich meine Sicht des Softwareproduktionsprozesses konkretisiere ein kurzer Ausflug ins Allgemeine; meine Erklärung basiert dabei auf der Theory of Constraints von Eliyahu M. Goldratts, so wie ich sie derzeit verstehe.

Wie kriege ich also eigentlich aus einem Prozess das meiste raus? Wie kann ich mit einem Prozess am meisten Geld verdienen?

Hier ein allgemeiner Prozess, der in 3 Schritten etwas herstellt und an den Kunden bringt:

image

Erst wenn das “Packerl” über den Tisch zum Kunden gewandert ist, fließt Geld. “Material” [1] in Form eines Produktes fließt aus dem Prozess in den Markt und Geld fließt zurück in den Prozess bzw. die Organisation, in der er fließt. Das Geld des Marktes hält den Prozess am Leben.

Es ist ein Transformationskreislauf. “Material” wird zu Geld wird zu “Material” wird zu Geld usw. usf.

Jetzt zum Grundsatz #1 solcher Geldverdienprozesse: Geld ist erst verdient, wenn der Kunde gekauft hat.

Hört sich trivial an, wird in Diskussionen aber schnell vergessen. Der Börsenspekulant weiß: Nicht realisierte Gewinne sind keine Gewinne. Soll heißten: Von günstigen Gelegenheiten zu reden, bringt nichts. Wer sie nicht wahrnimmt, hat nichts davon. Erfolgreich ist nur, wer sie nutzt.

Auf den Geldverdienprozess angewandt bedeutet das: Ein “Packerl” nützt nichts, solange es nicht verkauft ist. Jedes “Packerl” auf Lager ist gebundenes Kapital. Dito jedes X und Y: Zwischenprodukte sind gebundenes Kapital. Geld, das in den Prozess geflossen ist, wurde umgewandelt in “Material”. Damit ist das Geld weg – und solange kein “Packerl” verkauft wurde, kommt dafür kein Geld zurück.

Es heißt also verkaufen, verkaufen, verkaufen. Dann kommt mehr Geld rein. Und das bedeutet, produzieren, produzieren, produzieren. Oder?

Grundsatz #2: Man kann nur soviel verkaufen, wie der Markt bereit ist abzunehmen.

Am Markt herrscht für “Packerl” ein bestimmter Bedarf. Alle Hersteller von “Packerln” können zusammen nur soviel verkaufen, bis die Nachfrage befriedigt ist. Wer mehr produziert als nachgefragt (oder absetzbar) ist, der hat überproduziert und damit Geld in unverkauftem/unverkäuflichem “Material” gebunden.

Eine der vornehmsten Aufgaben jedes Managers muss es daher sein, die Produktion so zu steuern, dass keine Überproduktion entsteht. Das bedeutet, die Produktionsleistung wird vom Markt bestimmt. Der Markt zieht sozusagen an der Produktion. Oder der Markt kann als ein Unterdruck angesehen werden, der “Packerl” ansaugt.

Die Steuerung eines Produktionsschritts n geht mithin vom ihm folgenden Schritt n+1 aus! Wenn der Markt pro Monat 10 “Packerl” braucht, dann sollten auch nur 10 produziert werden. Werden mehr produziert, ist das Geldverschwendung, weil ab dem 11. “Packerl” nicht mehr verkauft werden kann, aber Geld in der Herstellung geflossen ist. Geld wird also verbrannt. Werden weniger produziert, ist das Geldverschenkung, weil existierende Gelegenheiten zum Geldverdienen nicht genutzt werden.

image

Natürlich ist es eine rechte Kunst, den Bedarf abzuschätzen und die Produktion darauf einzustellen. Das ist nicht leicht. Aber darum geht es mir hier nicht. Diese Kunst zu lernen lohnt nämlich erst, wenn man die Implikationen verstanden hat.

Grundsatz #3: Downstream Bedarf bestimmt upstream Produktion in allen Teilen eines Prozesses.

Dass man gegenüber dem Markt nicht überproduzieren sollte, leuchtet schnell ein. Aber es ist wichtig zu verstehen, dass das nicht nur für das Verhältnis Produktion:Markt gilt, sondern für jede Folge von Prozessschritten.

Ein Folgeschritt n+1 hat pro Zeiteinheit immer eine bestimmte Kapazität, mit der er “Material” vom vorhergehenden Schritt n aufnehmen kann. Beim Markt heißt diese Kapazität Bedarf. Es gibt sie jedoch nicht nur dort, sondern bei jedem Prozessschritt.

Das bedeutet, dass sich die Produktionsleistung eines Prozesses auf jeder Ebene und in jedem Schritt immer am Bedarf ausrichtet, am Bedarf des Marktes bzw. an der Kapazität von Folgeschritten. Oder anders und radikal ausgedrückt:

Produktionsschritte produzieren nicht soviel sie können pro Zeiteinheit, sondern nur soviel wie vom Folgeschritt abgenommen werden kann.

Das widerspricht weithin gepflegter Denkungsart. Die fordert nämlich, dass jeder Schritt immer möglichst nahe an seiner Kapazitätsgrenze läuft. Eine stillstehende Maschine, ein Zeitung lesender Entwickler… das darf nicht sein! Jedes und jeder sollte möglichst immer mit “Materialverarbeitung” bzw. “Materialproduktion” beschäftigt sein.

Aber das ist falsch, weil es zu Kapitalbindung in Zwischenerzeugnissen führt. Wenn Produktionsschritt n mehr in einer Zeiteinheit herstellt als Schritt n+1 weiterverarbeiten kann, dann entsteht eine Halde vor n+1.

n ist dann zwar fein raus, weil dort die Kapazität ausgeschöpft wird. n+1 ist ebenfalls fein raus, weil auch dort an der Kapazitätsgrenze gefahren wird. Der lokale, enge Blick auf die Prozessschritt und ihre Kapazitätsauslastung sieht also ein gutes Ergebnis.

Aber was ist mit der Halde zwischen n und n+1? Nicht nur in Anschaffung und Betrieb von n und n+1 steckt Geld; Geld steckt auch in der Überproduktion, die zwischen Schritten auf Halde liegt.

image

Consumer, d.h. downstream Produktionsschritte steuern also den Output von Producern, d.h. upstream Produktionsschritten.

Wenn denn alle Produktionsschritte die gleiche Kapazität hätten, dann würde sich die Produktion ganz einfach in allen Teilen nach dem Markt richten. Der Markt würde mit seinem Bedarf M ziehen/ansaugen und der letzte Produktionsschritt m würde mit seiner Kapazität Km darauf eingestellt. Das würde dann zur Folge haben, dass sich m-1 in seinem Ausstoß Am-1 (und also auch früher oder später in seiner Kapazität Km-1) nach m richtete. Das würde dann zur Folge haben, dass sich m-2 nach m-1 richtet usw. usf.

Am Ende würde schönste Eintracht herrschen, weil M=Ki und Ai=Ki+1 gälten. Alles wäre im Gleichgewicht, nein, alles wäre gleich: Bedarf, Kapazitäten und Ausstöße.

Aber so ist die Welt leider nicht. Kapazitäten lassen sich nicht gleichmachen. Und der Markt bewegt sich dauernd. Das bedeutet, es gibt Kapazitätsunterschiede bei den Schritten im Geldverdienprozess.

Daraus folgt nach Grundsatz #3, dass nicht alle Produktionsschritte ihre Kapazität ausschöpfen sollten. Sonst läuft das Gesamtsystem Gefahr, Geld durch Überproduktion zu verschwenden. Es gilt vielmehr:

Grundsatz #4: Der Ausstoß eines Prozesses richtet sich nach dem Prozessschritt mit der geringsten Kapazität. Dieser Schritt ist der Engpass des Prozesses.

Wieviel “Packerl” kann der folgende Prozess pro Zeiteinheit an den Markt bringen?

image

Der Markt hat einen Bedarf M=4, die Kapazitäten sind Ka=3, Kb=2, Kc=4. An C soll es also nicht liegen, wenn der Markt nicht befriedigt wird; C kann mit der Nachfragte mithalten.

Aber C kann pro Zeiteinheit nur 2 Y von Produktionsschritt B bekommen. Egal wie C sich auch anstrengen mag, es bekommt nicht genügend Input, um seine Kapazität auszuspielen. B hungerte C gewissermaßen aus.

B auf der anderen Seite könnte von A 3 X pro Zeiteinheit bekommen – also 1 X mehr als es verarbeiten kann. B würde von A überschwemmt, vor B entstünde eine Halde mit gebundenem Kapital.

Es hilft also nichts: Der Bedarf kann sein, wie er will, es können nicht mehr “Packerl” hergestellt werden, als die, zu denen Produktionsschritt B pro Zeiteinheit seinen Beitrag leisten kann. Und das sind 2 X, die am Ende zu 2 “Packerl” werden.

Der Ausstoß eines Prozesses richtet sich nach der Kapazität des Engpasses: A=Ke. Auf den Engpass folgende Produktionsschritte werden unterfordert, vor ihm liegende müssen gedrosselt werden. Andere Produktionseinschritte als den Engpass oberhalb dessen Kapazität zu fahren, bringt einfach nichts. Das würde nur geschäftig aussehen, aber nicht zum Betriebsergebnis beitragen. Im Gegenteil: Vorgelagerte Schritte würden eine Kapitalbindung durch Haldenbildung erzeugen. Das wäre Geldverschwendung.

Das bedeutet im Umkehrschluss:

Grundsatz #5: Investionen sind nur lohnend, wenn sie sich auf die Beseitigung des Engpasses konzentrieren.

Solange der Markt mehr Bedarf hat, als die Produktion hergibt, liegt der Engpass im Prozess. Wer den Ausstoß vergrößern will, um mehr vom Bedarfskuchen zu bekommen, der muss sich auf die Erweiterung des Engapsses konzentrieren. Investionen in A oder C im vorigen Diagramm lohnen nicht. Ihre Kapazität, die ja ohnehin schon größer ist als die von B, zu erhöhen, wäre Geldverschwendung.

Leider gehen viele Unternehmen jedoch diesen Weg. Sie haben einen engen Blick, der jeden Produktionsschritt nur für sich sieht. Und sie denken, mehr Kapazität und Kapazitätsauslastung wären per se wünschenswert. Leider gilt für abhängige Prozessschritte jedoch nicht, dass optimale Einzelsschritte zu einem optimalen Gesamtergebnis führen.

Abteilungsdenken, Budgetdenken und Managementhierarchien leisten solchem Denken allerdings Vorschub. Und so ist es kein Wunder, dass viele Unternehmen Geld in unnützen Optimierungen versenken. Es wird zwar getan und gemacht… aber es bringt nichts, weil es nicht am Engpass ansetzt.

Am Engpass anzusetzen ist natürlich auch schwer, wenn man keine rechte Vorstellung vom Produktionsprozess hat. Wer keinen Fluss zeichnet, auf dem seine Produkte von der Idee bis zum “Packerl” beim Kunden schippern, der kann sich nicht fragen, wo ein Flaschenhals sitzt. Der reagiert vielmehr immer nur erratisch auf Symptome die sie hier oder dort zeigen. Ein gezielter, systematischer Eingriff zur Optimierung des Gesamtsystems ist nicht möglich. Denn das Gesamtsystem liegt ja im Dunkeln.

Wer das Gesamtsystem jedoch kennt, der kann systematisch vorgehen:

  1. Engpass identifizieren
  2. Engpass ausreizen (Grundsatz #5)
  3. Nicht-Engpass Prozessschritte am Engpass ausrichten (Grundsatz #3)
  4. Enpass erweitern (Grundsatz #5)
  5. Zurück zu 1.

Nach Identifikation von B als Engpass oben, müsste zuerst sichergestellt werden, dass B auch wirklich seiner Kapazität gemäß pro Zeiteinheit Ausstoß produziert; es ist zu erreichen: Ab=Kb.

Dann müsste Aa=Kb eingestellt werden. An C kann man nicht viel tun, ohne die Kapazität zu verringern.

Und schließlich wäre zu prüfen, wie die Kapazität von B erhöht werden könnte. Würden mehr Personal oder mehr Maschinen helfen? Oder eine Maßnahme, um die Produktivität der vorhandenen Ressourcen zu erhöhen?

Zwischenstand

Wenn ich der Softwareentwicklung ein Angebot machen will, dann funktioniert das letztlich nur, wenn Entwickler, Entscheider und ich ein gemeinsames Verständnis vom Gesamtsystem haben, in dem die Softwareentwicklung eine Rolle spielt. Die Frage ist zu klären, wie die Softwareentwicklung zum Geldverdienen beiträgt.

Wie aber sieht so ein Gesamtsystem aus? Ich finde eine Beschreibung mit Flüssen genauso einfach wie hilfreich. Und die Theory of Constraints (TOC) zeigt mir, wie solche Produktionsflüsse auf das Ziel “Geld verdienen heute und in der Zukunft” hin optimiert werden können.

Hier konnte ich die TOC nur anreißen. Es ging mir darum, eine Grundlage für weitere Erklärungen zu legen, die sich konkreter auf die Softwareproduktion beziehen. Ausgelassen habe ich z.B. die Themen Puffer und Maßzahlen. Aber wer mehr erfahren will, der kann viel darüber lesen. Ich finde z.B. diese Beschreibung online von Yougman sehr gut lesbar. Leider gibt es dazu kein handliches eBook, so dass die 500+ Seiten im Browser gelesen werden müssen. Wer es lieber kürzer und in Prosa haben möchte – um es z.B. auch dem Chef zu schenken –, der tut sich etwas Gutes mit dem Roman “Das Ziel” vom Erfinder persönlich.

Im nächsten Teil zur Flow-Orientation für´s Unternehmen baue ich auf der TOC auf und beschreibe meine Vorstellung eines grundsätzlichen Softwareproduktionsprozesses. Und danach unterhalten wir uns über Engpässe…

 

[1] “Material” schreibe ich in Anführungsstrichen, weil ich damit nicht nur Handfestes wie Stahl oder Holz meine, sondern auch Wissen und Software. “Material” ist etwas, aus dem man etwas herstellen kann, wofür Kunden bereit sind, Geld zu bezahlen.

Kommentare:

Anonym hat gesagt…

Ein handliches Buch:
Goldratt und die Theory of Constraints - Uwe Techt

christian hat gesagt…

Meiner Meinung nach lässt sich der Inhalt von "Das Ergebnis" viel eher auf Software(industrie) anwenden, denn darin wird das Ziel hinter TOC ... zumindestens für mich ... viel klarer als in "Das Ziel": Lediglich "meinen" Produktionsprozess zu optimieren ist nicht annähernd aussreichend. Ich muss verstehen wie der Kunde mit meiner Software bilanzierbar Geld verdienen kann. Mir war vorher nie klar wie wertlos die hingerechneten Rentabilitäts- oder ROI - Rechnungen für Software sind.

Vieleicht magst Du das ja auch noch lesen, es ist wirklich nochmal anders ... ich könnte mir auch vorstellen Du fühlst Dich ein wenig seelenverwandt mit dem Hauptdarsteller Scott Duncan:)

Christian

Ralf Westphal - One Man Think Tank hat gesagt…

@Christian: Klar, am Ende geht es um Wertschöpfung beim Kunden. Erst wenn die eintritt, ist wirklich Geld verdient.

Aber wo heute nicht mal breit eine Vorstellung vom Prozess und seinen Gesetzen in den eigenen 4 Wänden existiert, da möchte ich den Einstieg in mehr Bewusstheit simpel halten.

Außerdem scheint mir die Unternehmensgrenze eine sinnige Schnittstelle, an der mit einer Prozessbetrachtung mal geendet werden kann. Dort wird ja Geld verdient. Da geht es also schon ums "höchste Ziel" :)

SMoni hat gesagt…

Sehr Kanban...

Danke für den Post :thumbsup: