Proofs of Concept sind eine der häufigsten Anfragen, die wir von potenziellen Kunden erhalten, die unseren Supply Chain Optimization Service ausprobieren möchten. Dennoch lehnen wir solche Anfragen häufig ab. Erstens, weil sie dem Unternehmen des Kunden selbst schaden, und zweitens, weil sie auch Lokad schaden. Da POCs - oder Proof-of-Concepts - in der B2B-Software so weit verbreitet sind, ist es in der Regel schwer zu verstehen, warum sie im speziellen Fall der quantitativen Lieferkettenoptimierung so schädlich sein können (1). In diesem Beitrag fassen wir unsere Erkenntnisse zu POCs zusammen und betrachten sie als ein Lieferketten-“Anti-Pattern”.

POCs sind nicht kostengünstiger

Eine grundlegende Annahme hinter der POC-Methodik ist, dass POCs weniger kosten als das eigentliche Projekt. Leider ist diese Annahme fast immer falsch.

Erstens bewegt die Festlegung eines kleinen Umfangs innerhalb eines gesamten Lieferkettennetzwerks die Nadel kaum. In der Vergangenheit hatten Softwareanbieter mit Skalierbarkeitsproblemen zu kämpfen, und tatsächliche Großimplementierungen erforderten in der Regel umfangreiche Vorabinvestitionen in Hardware, möglicherweise zusammen mit Softwarelizenzen wie Datenbanken. Ohne diese Investitionen war es nicht einmal möglich, Daten zu verarbeiten. In der heutigen Zeit des Cloud Computing existiert diese Einschränkung jedoch nicht mehr, und wenn eine App richtig konzipiert ist, ist nichts Zusätzliches erforderlich, um mit der Datenverarbeitung zu beginnen. Die Rechnung für das Cloud Computing wird nur geringfügig steigen, wenn weitere Kunden hinzukommen, aber insgesamt sind diese Kosten im Vergleich zu den Kosten, die bei der Kontaktaufnahme mit dem potenziellen Kunden entstehen, vernachlässigbar. Zweitens besteht der Großteil der anfänglichen Bemühungen darin, Daten zu qualifizieren, gefolgt von einer ordnungsgemäßen Identifizierung bei der Etablierung einer kommerziellen B2B-Beziehung mit dem Kunden.

Noch schlimmer ist, dass mehr Daten in der Regel die Dinge einfacher machen, nicht schwieriger, wenn es um statistische Prognosen geht. Daher machen POCs die Dinge tendenziell schwieriger und daher kostspieliger im Vergleich zur Bearbeitung des vollen Umfangs der Herausforderungen. Unsere Erfahrung zeigt, dass selbst wenn sich POCs nur auf 5% des gesamten Lieferkettennetzwerks konzentrieren, diese 5% in der Regel fast die gesamte Komplexität des Netzwerks als Ganzes umfassen. Tatsächlich ist es gerade weil POCs fast die gesamte Komplexität eines Großprojekts beinhalten, dass POCs im ersten Schritt sinnvoll wären.

Die Komplexität zu ignorieren ist in der Tat keine Option. Wenn Ihr Liefernetzwerk Containerlieferungen umfasst und Sie mit unzuverlässigen Lieferanten zusammenarbeiten, wie könnte ein POC überzeugend sein, wenn diese Elemente nicht in die Initiative einbezogen werden? Wenn eine bestimmte Einschränkung ignoriert wird, wie z.B. MOQs (Mindestbestellmengen), sind die numerischen Ergebnisse unbrauchbar.

Die Kosten jenseits des POCs werden durch die Anstrengungen auf beiden Seiten, sowohl von Lokad als auch von seinem Kunden, bei der Bewältigung der vollen Komplexität der Lieferkette bestimmt. Diese Kosten werden durch die Besonderheiten des betrachteten Geschäfts bestimmt, wobei die Skalierung nur einen marginalen Einfluss auf die Kosten hat.

POCs erhöhen die Wahrscheinlichkeit des Scheiterns

Bei der Entscheidung für einen POC versuchen Unternehmen häufig, ihre Lieferkette zu verbessern. In diesem speziellen Fall möchte ich jedoch Yoda zitieren: Tu es. Oder tu es nicht. Es gibt kein Versuchen. Trotz der Behauptungen von Softwareanbietern ist die Optimierung der Lieferkette schwierig. Das Problem bei POCs ist, dass sie den Parteien zu viel Spielraum für das Scheitern geben.

  • Die Extraktion des Verkaufshistorie ist höllisch kompliziert. Leider gibt es sowieso keine Alternative: Man wird nie erfolgreich die Lieferkette optimieren, ohne Daten zu haben, die die Nachfrage repräsentieren.
  • Elektronische Bestandsniveaus sind ungenau. Technologie kann helfen, die offensichtlichsten Abweichungen automatisch zu erkennen und Neuzählungen zu priorisieren. Es ist jedoch nicht ungewöhnlich, dass Supply Chain Manager auch mit Phantombeständen umgehen müssen.
  • Prognosen bleiben ungenau, egal was man tut. Unternehmen sollten lernen, eine unsichere Zukunft zu akzeptieren, anstatt diese Unsicherheit zu verdrängen. Probabilistische Prognosen sind besonders gut darin, zukünftige Unsicherheiten zu erfassen.

Komplikationen sind viele Ausreden, um den Ball fallen zu lassen.

Es gibt Situationen, in denen Lösungen einfach und ereignislos erwartet werden: zum Beispiel das Erstellen eines neuen E-Mail-Kontos für einen neuen Mitarbeiter. Die Optimierung der Lieferkette ist jedoch fast immer schwierig: Wenn das Unternehmen seit mehr als ein paar Jahren besteht, wurde der “einfache” Teil der Lieferkettenoptimierung bereits vor Jahren erledigt. Der “schwierige” Teil ist das, was übrig bleibt.

Unsere Erfahrung zeigt, dass die meisten POCs in den Anfangsstadien des Projekts scheitern, wenn die Teams immer noch mit Datenproblemen kämpfen. Das sagt jedoch nichts über die Inventaroptimierungslösung selbst aus, da die Lösung nie getestet wird.

POCs lenken Lieferkettenoptimierungsinitiativen ab

POCs betonen einen Blickwinkel, der nicht genau der Produktions -Blickwinkel ist. Führungskräfte suchen nach Benchmarks oder KPIs, die festgelegt werden sollen. Was ist jedoch, wenn ein bestimmter KPI schwieriger zu berechnen ist als die Optimierung selbst? Was ist, wenn der KPI selbst, obwohl instruktiv, keine handhabbaren Optionen zur Verbesserung bietet?

Unsere Erfahrung zeigt, dass POCs routinemäßig von Überlegungen abgelenkt werden, die aus produktionstechnischer Sicht einfach nicht erforderlich sind. Der Versuch, diese Anforderungen zu erfüllen, vergiftet in der Regel den POC, weil der POC plötzlich eine noch größere Herausforderung als die Produktion selbst wird.

Außerdem leiden die meisten POCs, da der Hauptzweck eines POCs darin besteht, Sicherheit zu suchen, unter Goldplating-Anti-Patterns, bei denen das Kundenunternehmen den Anbieter unter Druck setzt, jeden einzelnen Aspekt seines Geschäfts zu erfassen, selbst auf Kosten der Gesamtzuverlässigkeit der Lösung. Die resultierende Lösung ist oft zu spröde, um aus produktionstechnischer Sicht von Nutzen zu sein.

Wir haben viele POCs an “imaginären” Problemen scheitern sehen. Wenn zum Beispiel das beste Prognosemodell, das empirisch über Tausende von SKUs getestet wurde, nicht saisonal ist und alle anderen verfügbaren saisonalen Modelle übertrifft, sollte dies als Problem betrachtet werden? Es besteht kein Zweifel daran, ob das betreffende Geschäft saisonal ist: das ist es. Aber was ist, wenn der beste bekannte Weg, die zukünftige Nachfrage vorherzusagen, in diesem Fall einfach darin besteht, Saisonalität zu ignorieren? Sollte dies als Problem betrachtet werden? Unsere Erfahrung zeigt, dass dieses eine “Problem” für viele POCs als blockierendes Problem angesehen wurde, während die Supply Chain-Praktiker selbst zugaben, dass die vorgeschlagenen Mengen für die endgültigen Bestellungen sinnvoll waren.

Gehen Sie in die Produktion und überarbeiten Sie das Projekt bei Bedarf

POCs werden in der Regel und zu Recht von Praktikern als Ablenkung wahrgenommen, die das Geschäft am Laufen halten müssen, während die Next-Gen-Lösung kommt. Unsere Erfahrung zeigt, dass es billiger und weniger riskant ist, direkt in die Produktion zu gehen. Dies sollte jedoch mit der richtigen Methodik erfolgen.

Zunächst ist das Scheitern aufgrund der “Logistik der Daten” keine Option. Sie können nicht optimieren, was Sie nicht messen. Wenn Daten bedeutungslos sind, werden auch alle Optimierungsversuche bedeutungslos sein. Erfolg ist eine Voraussetzung, da das Unternehmen sonst in einigen Jahren möglicherweise nicht mehr existiert. Es kommt häufig vor, dass der überwiegende Teil der zu investierenden Anstrengungen mit dieser Datenlogistik verbunden ist und diese Investition nahezu vollständig von der für die Produktion in Betracht gezogenen Lösung getrennt werden kann. Und das ist eine gute Sache! Wenn die Optimierungslösung aus irgendeinem Grund nicht ausreichte, ist die Investition nicht verloren und muss lediglich auf eine bessere alternative Lösung umgeleitet werden.

Zweitens bedeutet das Ziel, direkt in die Produktion zu gehen, nicht, dass Zahlen nicht in Frage gestellt werden. Im Gegenteil, der alte und der neue Prozess sollten nebeneinander existieren und so viele einfache Erfolge wie möglich aus dem alten Prozess erzielen, während der neue Prozess optimiert wird.

Dann treten in der Regel Dutzende von Problemen auf. Es ist wichtig, sie zu sortieren:

  • Probleme, die bereits den alten Prozess beeinflussten, wenn auch auf eine leisere Weise. Gute Prozesse und gute Technologien machen Probleme offensichtlich; dies ist kein Defekt, sondern eine Tugend.
  • Probleme, die nicht durch die bereitgestellte Software behoben werden können. Wenn die SKU-Auswahl im Lager unzuverlässig ist, erwarten Sie nicht, dass das Nachfrageprognosemodul es vertrauenswürdig macht.
  • Diskrepanz zwischen realen Problemen und Erwartungen. Statistische Prognosen sind tief gegenintuitiv; lassen Sie Ihre Erwartungen nicht das übersteigen, was quantitative Messungen Ihnen sagen.
  • Designprobleme, die ohne eine wesentliche Neugestaltung der Lösung nicht gelöst werden können, was normalerweise dann der Fall ist, wenn die Software nicht den richtigen Ansatz hat, um die Herausforderung anzugehen.

Der letzte Punkt erfordert eine andere Lösung. Wie oben erwähnt, sollte dies jedoch nicht das Ende der Initiative sein, sondern lediglich der Beginn einer Zusammenarbeit mit einem anderen Anbieter.

Die Idee eines POC aufzugeben bedeutet in der Regel, den gesamten Schwung zu verlieren, der in die Initiative investiert wurde. Darüber hinaus scheitern die meisten POCs aus den falschen Gründen, was bedeutet, dass die Erfolgsaussichten zukünftiger Versuche kaum verbessert werden, da die eigentlichen Herausforderungen größtenteils unberührt bleiben.

Direkt in die Produktion zu gehen ist tatsächlich weniger riskant, als es sich anhört. Es hilft, eine ganze Klasse von Fehlern zu verhindern, die bei POCs tendenziell ignoriert werden, obwohl sie es nicht sollten. Es zwingt die Initiative dazu, sich auf das zu konzentrieren, was tatsächlich benötigt wird, um Verbesserungen zu erzielen, und Wunschdenken beiseite zu legen. Wenn ein ernsthafter Anbieterfehler auftritt, kann ein Unternehmen dennoch von seinem internen Schwung profitieren und zu einem anderen Anbieter wechseln, ohne den genannten Schwung zu verlieren, wie es bei POCs in der Regel der Fall ist.

(1) Es gibt viele Möglichkeiten, die Supply Chain zu optimieren: bessere Prozesse, bessere Lieferanten, bessere Transportunternehmen, bessere Einstellungen … Dieser Beitrag konzentriert sich auf die quantitative Optimierung: Supply Chain-Herausforderungen, die durch statistische Prognosen und/oder numerische Solver angegangen werden können.

(2) Die Behebung von Phantombeständen ist für alle Bestandsoptimierungsprozesse von Vorteil. Das Gleiche gilt für die Überprüfung und Verbesserung der Bestandsbewertungen.