Ein Unternehmen ist ein Produkt. Und jeder schlechte Prozess ist seine technische Schuld.

Die meisten Unternehmen wurden nie entworfen. Sie sind gewachsen. Am Anfang standen ein Gründer und eine Tabelle, dann kam ein Vertriebler mit eigener Kontaktliste, eine Buchhalterin mit eigener Software, eine Fertigung mit eigener Planung. Jede dieser Entscheidungen war damals vertretbar, ihre Summe ergibt nach zehn Jahren fast nie einen Sinn.

Nützlicher ist ein anderes Modell: Das Unternehmen ist ein einziges Produkt. Es hat Nutzer, Schnittstellen, Flüsse, Datenbanken, Legacy, Fehler und eine Nutzererfahrung. Und genau wie ein Softwareprodukt trägt es technische Schulden, auf die Zinsen anfallen, auch wenn kein Kontenrahmen sie ausweist.

Das ist keine Metapher um des Effekts willen, sondern ein Arbeitsmodell, das den Ort verändert, an dem Sie das Problem suchen. Wenn das Unternehmen ein Produkt ist, dann ist eine langsame Fakturierung kein Versagen einer Abteilung, sondern ein Defekt im Fluss. Und ein Defekt wird nicht mit Schulungen repariert, sondern indem man den Fluss neu zeichnet.

Das Unternehmen entstand nicht auf einmal, es wuchs Schicht für Schicht

Abteilungen entstehen als Antwort auf Schmerz. Etwas schafft eine Person allein nicht mehr, also stellt man zwei ein, mit eigenem Werkzeug und eigener Kennzahl. Von diesem Moment an optimiert jede Abteilung genau das, woran sie gemessen wird: der Vertrieb die Zahl der Abschlüsse, die Fertigung die Kapazitätsauslastung, die Finanzabteilung die Forderungslaufzeit, der Support die Zeit bis zur ersten Antwort. Jede dieser Kennzahlen ist für sich genommen vernünftig.

Das lokale Optimum einer Schicht erzeugt jedoch fast immer Mehrarbeit in der Schicht daneben. Ein Musterbeispiel: Ein Vertriebler vereinbart ein Zahlungsziel außerhalb des Standards, weil er an der Zahl der Verträge gemessen wird. Die Finanzabteilung legt daraufhin eine manuelle Ausnahme an, die Fertigung bekommt einen Termin, mit dem niemand gerechnet hat, und der Support erklärt, warum die Rechnung nicht zum Angebot passt. Niemand hat einen Fehler gemacht, schlecht entworfen ist das System.

Aus Sicht des Kunden existiert nur ein einziges Unternehmen

Der Kunde weiß nicht, wo der Vertrieb endet und die Fakturierung beginnt. Er sieht eine einzige Kette von Berührungspunkten und nimmt sie als ein einziges Erlebnis wahr. Customer Experience, also die Erfahrung des Kunden über die gesamte Beziehung zum Unternehmen hinweg, ist nicht der Durchschnitt dieser Berührungspunkte. Sie liegt näher am schwächsten Glied der Kette: Ein Fehlschlag bleibt besser in Erinnerung als ein reibungsloser Ablauf, und danach bewertet der Mensch die gesamte Beziehung.

Deshalb wird ein Prozess über seine ganze Länge gemessen und nicht nach Abteilungen. Die Frage lautet nicht, wie schnell das Lager arbeitet, sondern wie viele Stunden von der Bestellung bis zur Zustellung vergehen und wo die Sendung nur liegt.

Drei Nutzergruppen desselben Produkts

Jede Gruppe nutzt einen anderen Teil.

• Der Kunde nutzt die öffentliche Schnittstelle: Website, Angebot, Bestellung, Rechnung, Support.
• Der Mitarbeiter nutzt die interne Schnittstelle: Systeme, Formulare, Freigaben und Tabellen, die niemand für ihn entworfen hat, die sich nur angesammelt haben.
• Das Management nutzt die Daten- und Reportingschicht, auf deren Basis es entscheidet.

Die Budgets bilden das in der Regel nicht ab. Die öffentliche Schnittstelle hat einen Eigentümer und eine Kennzahl, die interne meist weder noch, also wird in sie erst investiert, wenn es brennt. Dabei schlägt die Employee Experience, also die Erfahrung der Mitarbeitenden mit den Werkzeugen und Regeln des eigenen Unternehmens, auf die Leistung durch. Laut einer Untersuchung des MIT Center for Information Systems Research aus dem Jahr 2017 an einer Stichprobe von 281 Führungskräften waren Unternehmen im obersten Quartil der Employee Experience doppelt so innovativ wie Unternehmen im untersten Quartil, gemessen am Umsatzanteil neuer Produkte und Dienstleistungen, und wiesen einen um 25 Prozent höheren Wert bei der branchenüblichen Rentabilitätskennzahl aus. Es handelt sich um Korrelationen aus der Selbsteinschätzung des Managements, nicht um eine nachgewiesene Ursache. Zeit, die für das Umgehen des eigenen Systems draufgeht, schafft dennoch für niemanden Wert.

Ein Prozess ist ein User Flow, nur hat ihn niemand gezeichnet

Im Produktdesign ist ein User Flow die Abfolge der Schritte, die ein Nutzer bis zu seinem Ziel durchläuft. Jeder überflüssige Schritt kostet Zeit und erhöht die Fehlerwahrscheinlichkeit. Ein Unternehmensprozess ist dasselbe, nur hat ihn niemand getestet.

Reibung lässt sich mit einer Formel beziffern, die wir Cost of Friction nennen: Dauer eines Durchlaufs mal Häufigkeit mal Zahl der beteiligten Personen mal Stundensatz. Ein Schritt, der nur einen Moment dauert, aber täglich von einer ganzen Abteilung ausgeführt wird, ist meist teurer als ein Projekt, das einmal im Jahr ansteht. Ohne diese Rechnung richten sich die Prioritäten danach, wer am lautesten ruft. Warum Design ein Werkzeug zur Einsparung von Zeit und Geld ist, haben wir im Text Gutes Design ist keine Dekoration behandelt.

Interne Systeme sind die Schnittstelle des Unternehmens, die Marke ist nur deren Titelseite

In unserem Modell hat ein Unternehmen fünf Schichten: Brand, Experience, Systems, Automation, Intelligence. Die Marke ist die externe Schnittstelle, also das Versprechen. Die internen Systeme sind die Schnittstelle, über die jemand dieses Versprechen tatsächlich einlöst. Klaffen beide auseinander, verliert immer das Versprechen: Ein Unternehmen kann ein ausgefeiltes Erscheinungsbild haben und die Bestellbestätigung trotzdem aus dem privaten Postfach des Lageristen verschicken.

Das gilt auch umgekehrt: Ein internes System, das niemand nutzen will, ist kein Problem der Disziplin, sondern des Designs. Menschen umgehen Firmenwerkzeuge aus demselben Grund, aus dem Kunden einen schlechten Warenkorb verlassen: Der Weg ist länger, als er sein müsste.

Daten sind Infrastruktur, kein Reporting

Wenn derselbe Kunde in fünf Systemen in fünf unterschiedlichen Versionen existiert, hat das Unternehmen keinen Kunden. Es hat fünf Vermutungen. Die Datenarchitektur, also die Vereinbarung darüber, wo die Wahrheit über Kunde, Bestellung und Preis entsteht, ist Infrastruktur wie Strom. Man sieht sie nicht, bis sie ausfällt.

Deshalb lassen sich die Schichten Automation und Intelligence nicht vor der Schicht Systems bauen. Automatisierung auf inkonsistenten Daten macht ein Unternehmen nicht schneller, sie vervielfältigt den Fehler nur schneller. Beschrieben haben wir das im Artikel KI rettet keinen schlechten Prozess.

Ein Legacy-Prozess ist technische Schuld, und auf sie fallen Zinsen an

Die Metapher der technischen Schulden führte Ward Cunningham im Jahr 1992 ein, und ihre ursprüngliche Bedeutung ist präziser, als sie heute üblicherweise zitiert wird: Schuld ist kein Synonym für schlechte Arbeit, sondern eine bewusste vorübergehende Vereinfachung, die die Arbeit beschleunigt, sofern sie bald durch ein Umschreiben zurückgezahlt wird. Gefährlich ist nicht die Anleihe, gefährlich ist das Nichtzurückzahlen. Jede Minute, die man mit nicht ganz richtigem Code verbringt, ist laut Cunningham Zins.

Übersetzt auf das Unternehmen: Ein Legacy-Prozess ist ein Ablauf, der seinen eigenen Grund überlebt hat. Der Report geht jeden Montag raus, weil ihn vor Jahren ein Manager angefordert hat, der längst nicht mehr im Unternehmen arbeitet. Niemand hat ihn gestoppt, weil er niemandem laut genug wehtut.

Die Zinsen sind messbar. Laut einer Längsschnittstudie von Besker, Martini und Bosch, in der 43 Entwickler sieben Wochen lang ihre Arbeit protokollierten, verlieren Entwickler im Durchschnitt 23 Prozent ihrer Zeit durch technische Schulden. Es handelt sich um Selbsteinschätzungen der Teilnehmenden, nicht um eine objektive Messung. Die Studie zeigt noch eine zweite Eigenschaft der Schuld: In etwa einem Viertel der Situationen, in denen Entwickler auf Schulden stoßen, sind sie gezwungen, weitere aufzunehmen. Schuld reproduziert sich selbst, genau wie ein Prozess, in dem eine Ausnahme mit der nächsten Ausnahme gelöst wird.

Das Konsortium CISQ schätzt die aufgelaufenen technischen Schulden in Software in den Vereinigten Staaten auf rund 1,52 Billionen US-Dollar. Der Bericht selbst räumt ein, dass es sich um die inflationsbereinigte Fortschreibung einer älteren Schätzung handelt und dass eine belastbare Schätzung der Zinsen bislang fehlt. Lehrreicher ist die Folge: Technische Schulden sind zum größten Hindernis für Änderungen an bestehendem Code geworden. Im Unternehmen klingt derselbe Satz schlicht: „Bei uns lässt sich das nicht ändern.“

Silos sind kein Kulturproblem, sie sind ein Integrationsproblem

Im Jahr 1968 formulierte Melvin Conway eine Beobachtung, die wir als Conways Gesetz kennen: Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe hervorzubringen, die ihre eigenen Kommunikationsstrukturen abbilden. Ein Bruch in der Organisation schlägt sich seiner Auffassung nach in der Struktur des Systems nieder. Es war keine empirische Studie, sondern ein Essay aus der Praxis.

Die Bestätigung kam später. Forscher von Microsoft Research und der University of Maryland analysierten die Entwicklung von Windows Vista, konkret 3.404 Binärdateien und mehr als 50 Millionen Codezeilen. Kennzahlen der Organisationsstruktur sagten fehleranfällige Systemteile mit einer Präzision von 86,2 Prozent und einer Vollständigkeit von 84,0 Prozent voraus und übertrafen damit den Umfang der Codeänderungen, die Komplexität und die Testabdeckung. Die Autoren weisen darauf hin, dass es um ein Unternehmen und ein Produkt geht, doch die Aufstellung der Menschen sagte Fehler besser voraus als die Eigenschaften des Codes. Die Studie von MacCormack, Rusnak und Baldwin ergänzt den Spiegeleffekt: Bei Finanzsoftware konnte die Änderung einer einzigen Datei im Durchschnitt 7,74 Prozent des Systems betreffen, wenn die Organisation lose gekoppelt war, gegenüber 47,14 Prozent bei enger Kopplung.

Daraus ergeben sich zwei Dinge. Wenn zwei Abteilungen einander die Arbeit per E-Mail zuschicken, wird Ihre Datenintegration genauso aussehen. Und es lässt sich umkehren: Das Vorgehen, das als Inverse Conway Maneuver bezeichnet wird, verändert die Struktur der Teams gezielt so, dass daraus die gewünschte Architektur entsteht. Laut dem DORA-Bericht aus dem Jahr 2022 war bei leistungsstarken Teams, die ihre Zuverlässigkeitsziele erreichen, die Wahrscheinlichkeit um 40 Prozent höher, dass sie auf einer lose gekoppelten Architektur aufsetzen, also einer, in der ein Team eine große Änderung bewältigt, ohne auf andere Teams zu warten. Es handelt sich um eine Korrelation aus einer Selbsteinschätzungsumfrage unter mehr als 1.350 Fachleuten.

Das Redesign eines Unternehmens läuft wie das Redesign eines Produkts

Die Abfolge ist dieselbe wie beim Produkt und lässt sich nicht überspringen.

1. Recherche. Gespräche mit den Menschen, die die Arbeit tatsächlich tun, nicht mit ihren Vorgesetzten. Uns interessiert die Wirklichkeit, nicht die Richtlinie.
2. Mapping. Ein Prozess von Anfang bis Ende, mit allen Wartezeiten, Übertragungen und Ausnahmen.
3. Priorisierung. Cost of Friction plus die Frage, wo eine kleine Änderung große Wirkung entfaltet. Donella Meadows nennt solche Stellen Hebelpunkte und führt den Konzern direkt als Beispiel eines komplexen Systems an. Sie zitiert dabei Jay Forrester: Menschen finden den Hebel meist richtig, drücken ihn nur in die falsche Richtung.
4. Prototyp. Das neue Vorgehen in einem einzelnen Team, mit Messung, kein unternehmensweiter Rollout.
5. Umsetzung. Erst hier kommt das Werkzeug. Technologie ist die letzte Entscheidung, nicht die erste.
6. Messung. Dieselbe Kennzahl vorher und nachher. Ohne das bleibt es eine Meinung.

Über der gesamten Abfolge steht eine harte Reihenfolge der Eingriffe: streichen, vereinfachen, automatisieren, erweitern. Streichen Sie zuerst, was nicht nötig ist, vereinfachen Sie dann, was übrig bleibt, automatisieren Sie erst danach und erweitern Sie zuletzt die menschlichen Fähigkeiten durch Werkzeuge, KI eingeschlossen. Wer beim dritten Schritt beginnt, kauft sich die teurere Version des ursprünglichen Problems. Wie ein Unternehmen aussähe, würde es von null aufgebaut, haben wir im Text über ein Unternehmen, das keine Armee von Verwaltungskräften braucht, ausgeführt.

Was Sie ohne Verständnis für die Menschen niemals automatisieren sollten

Automatisieren Sie keinen Prozess, den Sie nicht bis ins Detail verstehen, der voller Ausnahmen steckt oder den Sie noch nie live haben ablaufen sehen. Automatisierung ist Beton: Sie gießt genau die Form aus, die Sie ihr geben, samt allen Verformungen.

Undokumentierte Umgehungen sind eine Information, keine Sabotage. Sie markieren genau die Stelle, an der das System schlecht ist. W. Edwards Deming schätzte, dass rund 94 Prozent der Probleme zum System gehören und in der Verantwortung des Managements liegen, während die übrigen 6 Prozent auf spezielle Ursachen entfallen. Er formulierte das als persönliche Schätzung aus Erfahrung, nicht als gemessene Größe. Dennoch trifft es genau, warum ein Austausch von Menschen selten hilft. Laut den Notizen eines Teilnehmers seines Seminars aus dem Jahr 1993 sagte er es noch härter: Ein schlechtes System schlägt einen guten Menschen jedes Mal.

Und noch etwas, das man in unserer Branche selten hört: Nicht jedes Problem braucht eigene Software. Ein Teil der Prozesse repariert sich, indem man einen Report abschafft, ein gemeinsames Formular einführt oder ein Standardwerkzeug für ein paar Dutzend Euro im Monat einsetzt. Eine Eigenentwicklung lohnt sich erst dort, wo der Prozess wirklich spezifisch ist und seine Reibung die Kosten für Entwicklung und Wartung übersteigt. Wer Entwicklung anbietet, bevor er den Prozess verstanden hat, verkauft ein Werkzeug und keine Lösung.

Ein Unternehmen ist keine Ansammlung von Abteilungen. Es ist ein System

Systemdenken bedeutet eine einzige Disziplin: das Verhalten des Ganzen bewerten, nicht die Leistung der Teile. Ein Unternehmen mit fünf hervorragenden Abteilungen und fünf schlechten Übergängen dazwischen ist langsam. Verzögerungen und Fehler entstehen nämlich nicht in den Abteilungen, sondern in den Übergängen zwischen ihnen, wo der Prozess keinen Eigentümer hat.

Wenn Sie akzeptieren, dass das Unternehmen ein Produkt ist, ändern sich auch die Fragen. Statt „wer hat das verbockt“ kommt „wo im Fluss entsteht das“, statt „kaufen wir ein System“ kommt „welcher Schritt muss hier überhaupt sein“. Und statt der großen Transformation kommt eine Reihe kleiner Eingriffe an den Stellen mit dem größten Hebel. Der erste Schritt ist weder ein Einkauf noch eine Reorganisation, sondern die ehrliche Diagnose eines konkreten Flusses.

Was Sie mitnehmen

• Wählen Sie einen Prozess, der den Kunden berührt, und kartieren Sie ihn vom ersten Kontakt bis zur bezahlten Rechnung, Wartezeiten eingeschlossen.
• Rechnen Sie die Cost of Friction aus: Dauer mal Häufigkeit mal Zahl der Personen mal Stundensatz. Erst danach entscheiden Sie über die Reihenfolge der Änderungen.
• Erstellen Sie eine Liste der Legacy-Prozesse mit einer einzigen Frage ans Team: Was tun wir nur deshalb, weil es immer schon so gemacht wurde? Alles ohne gültigen Grund ist fällige Schuld.
• Halten Sie die Reihenfolge streichen, vereinfachen, automatisieren, erweitern ein. Die Automatisierung eines schlechten Prozesses ist nur die teurere Version desselben Problems.
• Beantworten Sie vor dem Kauf eines Werkzeugs, welcher Schritt damit entfällt. Wenn keiner, kaufen Sie keine Lösung, sondern eine weitere Schicht.