Holimization: Warum Optimierung nicht genug ist
Während meiner gesamten Karriere wurde mir oft gesagt, dass „Optimierung“ die Antwort sei. Wenn wir nur das richtige Modell formulieren, es mit genügend Daten füttern und einen leistungsstarken Solver freilassen könnten, würde die Maschine ruhig die bestmöglichen Entscheidungen treffen.
Doch in echten supply chains wird dieses Versprechen selten eingelöst. Unternehmen setzen ausgeklügelte Software ein, justieren unzählige Parameter und sehen sich dennoch mit Lagerausfällen, überschüssigen Beständen und nervösen Planern konfrontiert, die dem System nicht mehr vertrauen. Die Mathematik in der Black Box mag schön sein; die Entscheidungen im Lager sind es oft nicht.
In Introduction to Supply Chain, besonders in den Kapiteln, die sich den Entscheidungen und numerischen Rezepten widmen, argumentierte ich, dass der wahre Engpass nicht im Mangel an Solvern liegt, sondern im Mangel an einem adäquaten Rahmen um die Optimierung selbst. In diesem Essay möchte ich diese Idee einen Schritt weiterführen und ihr einen Namen geben: holimization, und sein Verb, to holimize, gebildet durch die Verschmelzung von „holistischer Optimierung“.
Wenn Optimierung um die falsche Frage herum gerahmt wird
Die klassische Optimierung beginnt in ihrer einfachsten Form mit einer sehr verlockenden Ausgangshaltung:
“Sag mir, was du maximieren oder minimieren möchtest, liste die Einschränkungen auf, und ich werde die bestmögliche Entscheidung finden.”
Auf einem Whiteboard klingt das völlig vernünftig. In einer supply chain verbirgt es fast alles, was wirklich zählt.
Was genau maximieren wir? Den Gewinn in diesem Monat? Über ein Jahr? Wachstum über mehrere Jahre? Kundenzufriedenheit in einem kaum messbaren Sinne? Resilienz gegenüber Störungen? Eine Mischung aus all dem?
Was genau sind die Einschränkungen? Die formalen, wie Kapazität und Lieferzeiten, oder auch die nicht dokumentierten, wie “dieses Lagerteam kann realistischerweise nicht mehr als 5.000 eingehende Kartons pro Tag bewältigen” oder “diese Maschine kann nicht zweimal in derselben Woche zurückgesetzt werden”?
Und wie sollen wir Schaden messen? Ist ein Lagerausfall schlimmer als ein Ausverkauf? Wie viel schlimmer, in monetären Werten, und für welche Produkte?
Wenn wir eine klassische Optimierungs-Engine in einer supply chain einsetzen, sind wir gezwungen, diese Fragen zu beantworten, indem wir sie – explizit oder implizit – in eine Zielfunktion und eine Sammlung von Einschränkungen kodieren. Sobald wir das getan haben, wird der Solver tatsächlich “optimale” Entscheidungen in Bezug auf diese Kodierung finden. Leider, wenn die Kodierung auch nur geringfügig von der Realität abweicht, erhalten wir einfach schneller falsche Entscheidungen.
Ich habe viele Variationen dieser Geschichte gesehen. Ein Einzelhändler führt ein neues Nachschubsystem ein, das stolz das “service level” maximiert, unter Berücksichtigung von Bestands- und Logistikkosten. Lagerausfälle nehmen auf dem Papier ab, aber die Geschäfte führen nun zu viele langsam drehende Größen und Farben, die die Kunden nicht wollen. Ein Hersteller installiert ein fortgeschrittenes Planungssystem, das Produktionspläne anhand eines vereinfachten Kapazitätsmodells optimiert; der resultierende Plan sieht in der Benutzeroberfläche elegant aus, aber das Werk verbringt seine Zeit damit, improvisierte Lösungen zu finden, weil das Modell nie kritische Engpässe auf dem Shop Floor erfasst hat.
In jedem dieser Fälle funktioniert die Optimierung an sich. Der Computer tut genau das, was wir von ihm verlangt haben. Das Problem ist, dass wir die falsche Frage gestellt haben.
Benennung der fehlenden Disziplin
Das Konzept, das ich einführen möchte, lautet:
Holimization (n.) – Die Disziplin der ganzheitlichen Optimierung für komplexe, sich entwickelnde Systeme, bei der der primäre Designgegenstand der Optimierungsrahmen selbst ist: die Ziele, Einschränkungen, Datensemantik und Entscheidungsgrammatik. Holimization behandelt Optimierung als einen iterativen, experimentellen Prozess, in dem sich die Zielfunktion, das Modell und die Instrumentierung unter realem Feedback gemeinsam entwickeln.
To holimize (v.) – Einen solchen Prozess orchestrieren: das Entscheidungssystem wiederholt rahmen, instrumentieren, optimieren und refaktorisieren, sodass es im Einklang mit der wirtschaftlichen Realität und den organisatorischen Absichten bleibt.
Optimierung, im engen Sinne, konzentriert sich auf die innere Schleife: Angenommen, ein festes Ziel und eine feste Darstellung der Welt – finde Entscheidungen, die dieses Ziel extremisieren. Holimization konzentriert sich auf die äußere Schleife: wie wir dieses Ziel gestalten, wie wir die Welt darstellen, wie wir das System instrumentieren und wie sich all dies im Laufe der Zeit verändert.
Mit anderen Worten, die Optimierung beantwortet: “Was ist am besten, wenn die Welt so aussieht?” Holimization fragt: “Betrachten wir die Welt in einer Weise, die es überhaupt ermöglicht, dass ‘beste’ Sinn ergibt?”
Dies ist kein abstrakter philosophischer Punkt. In einer chaotischen, sich entwickelnden Umgebung wie einer supply chain ändert sich die Frage, die wir optimieren, ständig unter unseren Füßen. Märkte verschieben sich, Sortimente verändern sich, Kanäle tauchen auf und verschwinden, Vorschriften entwickeln sich weiter und interne Prioritäten ändern sich. Wenn unser Optimierungsrahmen fest bleibt, während sich die Welt drumherum wandelt, wächst die Divergenz zwischen dem, was auf dem Bildschirm “optimal” ist, und dem, was in der Realität sinnvoll ist, stetig über die Zeit.
Holimization ist der Name, den ich für die Disziplin vorschlage, den Rahmen selbst als primäres Arbeitsobjekt zu behandeln.
Was es bedeutet, eine supply chain zu holimize
Lassen Sie mich dies anhand von supply chain-Beispielen konkretisieren, da ich hier den Großteil meiner Zeit verbracht habe.
Stellen Sie sich einen Modeeinzelhändler vor, der den Service in den Geschäften verbessern möchte. Wenn wir Optimierung im engeren Sinne betrachten, könnten wir beginnen, den Service als die Wahrscheinlichkeit zu definieren, dass ein Kunde nicht auf einen Lagerausfall stößt, und ein Ziel wie “95% service level” festlegen. Wir würden dann Lagerausfälle als Kosten und Überbestände als weitere Kosten kodieren und eine Optimierungs-Engine die beiden gegeneinander abwägen lassen.
Dies führt zu Entscheidungen, die numerisch ordentlich, aber ästhetisch merkwürdig sind. Die Geschäfte verfügen über eine technisch ausreichende Anzahl von Einheiten, doch die meisten sind in den falschen Größen oder ausschließlich in denselben, sicheren Farben vorhanden. Aus Sicht des Modells ist alles in Ordnung: Das Serviceziel wird erreicht und die Kosten liegen im Rahmen. Aus der Perspektive des Kunden, der den Laden betritt, wirkt die Kollektion leblos.
Wenn wir stattdessen holimizen, akzeptieren wir, dass der “Service” noch nicht richtig formuliert ist. Wir machen aus der Implementierung des Entscheidungssystems ein Experiment an unseren eigenen Annahmen.
Wir beginnen damit, ein reales Entscheidungsrezept einzuführen, das von Daten und Optimierung angetrieben wird, und umgeben es mit Instrumentierung, die darauf ausgelegt ist, “verrückte” Entscheidungen aufzudecken: Sortimente, die jeder menschliche Einkäufer sofort als schädlich beurteilen würde, selbst wenn das System noch nicht erklären kann, warum. Wir überwachen Geschäfte, in denen das Modell darauf besteht, eine unplausible Mischung aus Größen und Edelsteinen von Abverkaufsartikeln zu versenden. Wir hören aufmerksam auf Planer, die sich darüber beschweren, dass das System bestimmten Geschäften ständig Vielfalt vorenthält.
Jedes Mal, wenn wir auf solchen Wahnsinn stoßen, gehen wir dessen Ursachen nach. Vielleicht hat unsere Zielfunktion keine Möglichkeit, Sortimentsvielfalt zu belohnen, sondern nur die Verfügbarkeit der Einheiten. Vielleicht haben wir das praktische Limit, wie oft ein Geschäft neu aufgefüllt werden kann, nie erfasst. Vielleicht verbergen unsere historischen Daten Substitutionseffekte, die bestimmte Lagerausfälle viel weniger schädlich machen als andere.
Dann ändern wir den Rahmen. Wir führen ein quantifiziertes Konzept der Vielfalt in das Ziel ein, an das ein finanzieller Wert gekoppelt ist. Wir ersetzen eine starre Einschränkung durch eine Kostenkomponente – oder umgekehrt. Wir fügen dem Rezept eine neue Entscheidungs-Kategorie hinzu, wie zum Beispiel wann eine Anzeige aktualisiert werden soll oder wie Lieferungen für fragile Geschäfte gestaffelt werden. Wir erweitern die Instrumentierung, um diese neuen Aspekte zu visualisieren, sodass die nächste Runde des Wahnsinns, falls sie auftritt, leichter zu diagnostizieren ist.
Wir haben die Situation holimiziert: Anstatt den Solver zu beschuldigen oder das System zu ignorieren, haben wir die Fehlentscheidungen selbst als Hinweise genutzt, dass unser Rahmen unvollständig ist und sich weiterentwickeln muss.
Eine ähnliche Geschichte spielt sich in Wartungs- und Reparaturabläufen ab. Angenommen, Sie verwalten Ersatzteile für Flugzeugtriebwerke. Der naive Optimierungsansatz besteht darin, jedes Teil einzeln zu behandeln: Schätzen, wie oft es benötigt wird, Lagerausfälle und Bestandskosten zuzuordnen, und die Maschine den besten Nachbestellpunkt finden zu lassen.
In der Praxis werden Triebwerke nicht so repariert. Der tatsächliche Schaden entsteht, wenn eine Reparatur verzögert wird, weil ein kritisches Teil fehlt, selbst wenn Sie in einem Überfluss von Dutzenden anderer Teile zu ersticken drohen. Die Kosten sind kein Lagerausfall in einer Tabellenkalkulation; es sind Tage an Ausfallzeit für ein Flugzeug.
Holimization zwingt uns, das Ziel an etwas näher an der Realität auszurichten – etwa die Reduzierung der erwarteten Verzögerungstage pro Triebwerk und pro Budgeteinheit. Es fordert uns auf, den Prozess mit Ansichten zu instrumentieren, die deutlich machen, welche Teile wiederholt Reparaturen blockieren. Wenn das System vorschlägt, eine große Menge eines Teils zu bevorraten, das Reparaturen nie tatsächlich behindert, ist das ein Wahnsinns-Signal. Wenn es hingegen ein Teil unterversorgt, das mehrfach Triebwerke verzögert, ist das ein weiteres.
Wir betrachten diese Fehlentscheidungen nicht als peinliche Bugs, die es zu verstecken gilt. Wir werten sie als unsere beste Informationsquelle dafür, wo unser Rahmen falsch liegt. Dann passen wir an, wie wir Schaden messen, wie Ereignisse mit Kosten verknüpft werden und wie wir Entscheidungen strukturieren, sodass zukünftige Optimierungen in einem realitätsnäheren Raum durchgeführt werden.
Holimization geht also nicht darum, die Optimierung zu verbannen. Es geht darum, die Optimierung mit einer disziplinierten Praxis zu umgeben, aus ihren Fehlern zu lernen.
Die verborgene Arbeit rund um die Optimierungs-Engine
Wenn Sie ein großes Unternehmen betreten, das “Optimierung betreibt”, werden Sie feststellen, dass der größte Teil der Anstrengungen nicht in der Entwicklung von Algorithmen liegt. Es geht darum, Daten zu verstehen, mit Ausnahmen umzugehen und das, was das System sagt, mit dem in Einklang zu bringen, was die Realität zulässt.
Holimization macht diese verborgene Arbeit explizit und strukturiert.
Ein Großteil der Schwierigkeit liegt in der Datensemantik. Operative Systeme enthalten eine verwirrende Anzahl von Feldern, Codes und historischen Eigenheiten. Wenn eine Optimierungs-Engine diese Daten so nimmt, wie sie sind, interpretiert sie unweigerlich einen Teil davon falsch. Ein einst bedeutungsvolles Limit könnte obsolet geworden sein. Ein Feld, das als “Lieferzeit” erscheint, ist in Wirklichkeit vielleicht eine Mischung aus Transit- und Verwaltung Verzögerungen. Ein Indikator, der wie “im Angebot” aussieht, könnte regionsübergreifend inkonsistent verwendet werden.
Ohne eine holimization-Mentalität werden diese Probleme zufällig entdeckt, oft nachdem bereits Schaden entstanden ist. Mit Holimization gehen wir von Anfang an davon aus, dass unsere Interpretation der Daten vorläufig ist. Wir bauen Tests, Vergleiche und Plausibilitätsprüfungen ein, die versuchen, unsere Auslegung der Daten zu widerlegen. Wenn das System eine Entscheidung vorschlägt, die einen Dock überlasten würde, schreiben wir das nicht dem “Pech” zu; wir sehen es als Hinweis darauf, dass eine Einschränkung in unserem Weltbild fehlt.
Ein weiterer großer Bestandteil ist die Instrumentierung. Eine Optimierungs-Engine allein ist blind: Sie nimmt Daten auf, gibt Entscheidungen aus und hat keine Meinung darüber, ob diese Entscheidungen sinnvoll sind. Holimization erfordert eine Ebene der Sichtbarkeit, die nicht nur wichtige Leistungskennzahlen nachverfolgt, sondern auch hervorhebt, wo sich das System auf eine Weise verhält, die Menschen absurd finden.
Dies kann viele Formen annehmen: Zeitreise-Ansichten, die es uns ermöglichen, Entscheidungen anhand vergangener Daten abzuspielen; Mikroskope für ein einzelnes Produkt oder einen Standort, die zeigen, wie sich die Entscheidung im Laufe der Zeit entwickelt hat; Dashboards, die Ausreißer statt Durchschnittswerte hervorheben. Das Ziel ist stets dasselbe: “verrückte” Variablen in einen strukturierten Feedback-Kanal zu überführen und nicht in eine Quelle der Frustration.
Schließlich geht es um die Geschwindigkeit und Sicherheit der Iteration. Holimization ist von Natur aus experimentell. Wir müssen neue Rahmenbedingungen und überarbeitete Ziele ausprobieren, ohne dabei jedes Mal das gesamte Geschäft zu gefährden. Das setzt technische Möglichkeiten voraus – wie das Versionieren von Entscheidungsrezepten, kontrollierte Rollouts, Shadow Modes – aber auch organisatorische: klare Verantwortlichkeiten, eine Kultur, die Experimente als notwendig ansieht, und ein Management, das den Unterschied zwischen einer stabilen Produktionsregel und einem experimentellen Test versteht.
All dies ist Arbeit. Es ist jedoch Arbeit, die wir bereits informell leisten, wann immer wir uns darüber beschweren, dass “das System es nicht versteht.” Holimization ist der Versuch, dieser Arbeit einen passenden Namen und eine entsprechende Methode zu geben.
Warum ein neues Wort von Bedeutung ist
Man könnte zu Recht fragen: Warum überhaupt einen neuen Begriff prägen? Warum nicht einfach von “guter Optimierungspraxis” oder “experimenteller Modellierung” sprechen?
Meiner Erfahrung nach wird ohne einen klaren Namen die äußere Schleife von der inneren verschluckt. Sobald das Wort “Optimierung” auf dem Tisch liegt, richtet sich die Aufmerksamkeit auf Algorithmen, Solver und Leistungsbenchmarks. Das Gespräch verlagert sich darauf, ob eine bestimmte Methode schneller konvergiert oder besser skaliert, und entfernt sich von der unangenehmeren Frage, ob wir überhaupt das Richtige optimieren.
Im Gegensatz dazu trägt “holimization” in seiner Konstruktion die Erinnerung, dass Optimierung nur eine Zutat in einer breiteren Disziplin ist. Es besagt, dass uns der gesamte Bogen von der Realität über Daten zur Entscheidung und wieder zurück zur Realität wichtig ist. Es legt nahe, dass unser primäres Artefakt nicht der Solver, sondern der sich entwickelnde Rahmen ist, in dem der Solver arbeitet.
Für mein eigenes Unternehmen, Lokad, verdeutlicht diese Bezeichnung auch, was wir aufzubauen versuchen. Wir sind im Kern kein Anbieter von noch einer Optimierungs-Engine. Wir wollen eine Plattform bereitstellen, auf der Unternehmen ihre supply chains holimize können: ein Ort, an dem Daten umgestaltet werden können, an dem Ziele in finanziellen Begriffen ausgedrückt werden, an dem Entscheidungen automatisiert, aber dennoch nachvollziehbar bleiben, und an dem jeder Ausfall des Systems als wertvolle Lerngelegenheit dafür behandelt wird, wie sich der Rahmen entwickeln sollte.
Das Wort ist neu, aber das Bedürfnis, das es erfasst, ist es nicht. Supply chains und viele andere komplexe Systeme haben sich über Jahre hinweg still und leise durch Versuch und Irrtum, Tabellenkalkulations-Lösungen und endlose Meetings selbst holimiziert. Meine Hoffnung ist, dass wir, indem wir diesem Prozess einen Namen und eine klarere Form geben, ihn gezielter, rigoroser und letztlich effektiver gestalten können.
Optimierung, wie die Mathematik, wird nicht verschwinden; wenn überhaupt, wird sie sich ständig verbessern. Holimization ist die Einladung, eine Ebene höher zu gehen, um unsere Modelle, Ziele und Einschränkungen nicht als heilig zu behandeln, sondern als Hypothesen, die der Welt gegenüber getestet werden. Erst dann kann „optimal“ aufhören, ein formales Label in einem Bericht zu sein und anfangen, den Entscheidungen zu ähneln, die wir tatsächlich vor Ort umsetzen wollen.
