Anfang dieses Jahres wurde mir bei einem Treffen mit einem bekannten Experten für Supply-Chain-Modellierung eine Frage gestellt, die ich so noch nie gehört hatte:
Ich sah diese Zahl zum ersten Mal und fand sie beeindruckend. Er nicht. Tatsächlich sagte er mir, dass seiner Erfahrung nach alles unter 4.000–5.000 Feldern „nicht robust genug“ sei.
Als ich aus diesem Meeting herauskam, wurde mir klar: Hier ging es nicht wirklich um die Größe der Datenbank – es ging um zwei sehr unterschiedliche Philosophien. Die eine geht davon aus, dass mehr Details automatisch bessere Ergebnisse bedeuten, die andere erkennt die Realität abnehmender Erträge an.
Jede Detailebene und jedes zusätzliche Feld mag zwar einen Mehrwert bieten – aber es erhöht auch die Komplexität, den Pflegeaufwand für die Daten und den Zeitaufwand, den man aufwenden muss, um das Tool dazu zu bringen, Ergebnisse zu liefern. Ab einem bestimmten Punkt untergräbt die zusätzliche „Robustheit“ genau das Ziel des Tools: zeitnahe, nützliche Entscheidungen.
Und wenn die Zeit abläuft, spielt kein Modell mehr eine Rolle. Das galt schon vor 30 Jahren – und es gilt auch heute noch.
Einige Jahre, nachdem Jobs und Wozniak in jener mittlerweile berühmten Garage zu tüfteln begonnen hatten, veränderten PCs die Entscheidungsfindung in Unternehmen grundlegend. Manager hatten plötzlich Zugang zu menügesteuerten, visuellen Anwendungen, mit denen sie in Echtzeit interagieren konnten.
Dieser Wandel von der batchorientierten, IT-vermittelten Datenverarbeitung hin zu interaktiven, benutzergesteuerten Anwendungen demokratisierte die Entscheidungsunterstützung – und ermöglichte es Einzelpersonen, Entscheidungen sofort zu treffen, anstatt auf statische Berichte zu warten, die oft schon veraltet waren, wenn sie endlich eintrafen.
Für diejenigen von uns, die an Planungs- und Optimierungslösungen im Bereich der Lieferkette arbeiteten, waren dies aufregende Zeiten. Endlich konnten wir damit beginnen, Operations-Research-Modelle (OR) mit der neuen Welt interaktiver, menügesteuerter Anwendungen zu verknüpfen.
Mit dem Aufkommen kommerzieller Solver begannen wir, Werkzeuge für die visuelle Netzwerkplanung und taktische Planung zu entwickeln, die Manager direkt nutzen konnten. Doch schon bald wurde die Zeit zu einem großen Engpass – nicht nur die Zeit für die Erstellung von Szenarien und die Auswertung der Ergebnisse, sondern vor allem die Rechenleistung, die für deren Ausführung erforderlich war.
Mehr als alles andere bestimmte die Rechengeschwindigkeit die praktischen Grenzen des Machbaren.
Um erschwingliche Lösungen mit einer vernünftigen Erfolgschance zu liefern, hatten wir keine andere Wahl, als Modelle so zu entwerfen – oder genauer gesagt, so anzupassen –, dass sie zu den uns zur Verfügung stehenden Rechnern passten. Optimalität im Lehrbuch Sinne war in der Regel keine Option.
Bis heute bleibt das Ziel dasselbe: Lösungen, die in angemessener Zeit und zu erschwinglichen Kosten konsistent qualitativ hochwertige Ergebnisse liefern können.
Man könnte es als „Pareto trifft OR“ bezeichnen.
Die Tatsache, dass viele dieser Lösungen weit länger Bestand hatten als branchenüblich – eines der frühesten Supply-Chain-Planungssysteme feierte kürzlich seinen 32. Geburtstag –, ist ein deutlicher Hinweis darauf, dass dieser Ansatz funktioniert: den Umfang des Modells richtig festlegen, gute Ergebnisse anstreben und die Dinge nicht unnötig komplizieren.
Als dieser Experte also meinte, unsere Datenbank sei für eine robuste Lösung nicht groß genug, habe ich seine Sichtweise zwar verstanden – aber ich werde meine Meinung nicht ändern.
Einige Apps zur Modellierung von Lieferketten zielen darauf ab, komplexere Probleme zu bewältigen. Dazu sind sie mit zahlreichen Features und Funktionen ausgestattet, um diese Komplexität zu unterstützen – was unweigerlich auf Kosten der Benutzerfreundlichkeit, Geschwindigkeit und Akzeptanz geht.
Bei Factible Tools haben wir einen anderen Weg eingeschlagen: Wir haben uns zum Ziel gesetzt, ein Tool für das Design von Lieferkettennetzwerken und die taktische Planung zu entwickeln, das genau das bietet, was die überwiegende Mehrheit der Unternehmen tatsächlich benötigt.
Wir fügen Komplexität nur dort hinzu, wo sie der breiteren Nutzergemeinschaft zugutekommt. Unsere Lösung wird nicht in jedem Fall die richtige Wahl sein, und das ist in Ordnung. Aber für die vielen, die schnell gute Antworten wollen, ohne sich durch endlose Konfigurationsmasken kämpfen zu müssen, ist „weniger“ nicht nur mehr – es ist genau richtig.
Nachdem ich über 30 Jahre lang beobachtet habe, wie einfachere Lösungen komplexere überdauern, werde ich weiterhin die Kennzahl im Blick behalten, auf die es am meisten ankommt: Nutzen die Menschen das, was wir entwickeln, tatsächlich, um bessere Entscheidungen zu treffen?
Denn letztendlich ist das das deutlichste Zeichen dafür, dass wir auf dem richtigen Weg waren – und es immer noch sind.