Einblicke in die Entwicklung der Lokad-Technologie

Joannes Vermorel

Die Technologie von Lokad hat sich so sehr entwickelt, dass diejenigen, die Lokad bereits vor zwei Jahren testen konnten, die App in ihrer heutigen Form kaum wiedererkennen würden.

Die “alte” Lokad war vollständig um unsere Prognose-Engine zentriert – also das, was Sie heute als ein Forecasting project in Ihrem Lokad-Konto sehen können. Infolgedessen hat unsere Prognose-Engine nach und nach eine Vielzahl von Funktionen erhalten, die nicht einmal ansatzweise mit Statistik zu tun haben. Vor etwa zwei Jahren war unsere Prognose-Engine zu einem Alleskönner geworden, der fast alles verantwortete:

• Datenaufbereitung mit der Möglichkeit, eine große Vielfalt an Datenformaten aufzunehmen
• Reporting-Analytics mit einem etwas komplexen und etwas flexiblen Excel-Forecasting-Report
• Geplante Ausführung durch eine Webcron-Integration oder über die API

Dann haben wir in den letzten zwei Jahren schrittweise eigenständige Ersatzlösungen für jene Funktionen eingeführt, die nun außerhalb unserer Prognose-Engine existieren. Allerdings ist es unfair, diese neuen Funktionen lediglich als Ersatzlösungen zu bezeichnen, da sie bei weitem leistungsfähiger sind als ihre ursprünglichen Gegenstücke.

• Wir können nun sehr unterschiedliche Dateien verarbeiten, die in Größe, Komplexität und sogar in Datenformaten variieren. Zudem haben wir auch viele Datenkonnektoren.
• Die Möglichkeiten unseres alten Excel-Forecasting-Reports werden von den neueren Reporting-Fähigkeiten von Envision in den Schatten gestellt.
• Planung und Orchestrierung sind nun erstklassige Elemente, die auch die Datenabfrage aus anderen Apps umfassen.

Da diese neuen Funktionen den alten schlicht überlegen sind, bauen wir allmählich den Ballast ab, also alle nicht prognosebezogenen Elemente, die noch in unserer Prognose-Engine existieren.

Um den Prozess reibungslos zu gestalten, migrieren wir allmählich – aber aktiv – alle unsere Kunden von der alten Lokad zur neuen Lokad; und wenn eine alte Funktion nicht mehr genutzt wird, entfernen wir sie vollständig.

Der alte Excel-Forecasting-Report ist für uns ein schwieriger Fall. Die Herausforderung besteht nicht darin, den Report innerhalb von Envision einfach zu duplizieren (das allein ist überhaupt nicht schwer) – die Herausforderung besteht darin, dass das zugrunde liegende Denken, das in diesen Report eingeflossen ist, nun ziemlich veraltet ist. Tatsächlich hat Lokad im Laufe der Jahre Technologien für besseres Forecasting eingeführt – die neueste Iteration sind probabilistische Prognosen \– die sich nicht in diesen Report integrieren lassen. Durch das Design ist dieser eine Report an einen Legacy-Ansatz der Prognose gebunden, der leider nicht so gut zur Optimierung des Inventars passt.

Im Gegensatz dazu erfordert die Kombination von probabilistischen Prognosen mit Wirtschaftstreibern zwar einen höheren Aufwand sowohl auf Seiten von Lokad als auch auf Kundenseite, aber die Geschäftsergebnisse sind einfach nicht vergleichbar. Ersteres zielt darauf ab, Prozentfehler zu optimieren, während Letzteres Dollarfehler optimiert. Nicht überraschend, dass sobald unsere Kunden realisieren, wie viel Geld sie mit dem Verzicht auf Letzteres auf dem Tisch liegen lassen, sie niemals in Erwägung ziehen, zum Ersteren zurückzukehren.

Dann unterziehen sich unsere Datenintegrationen derzeit einer ähnlichen und keineswegs weniger radikalen Transformation. Als wir anfingen, Datenkonnektoren zu entwickeln, versuchten wir, alle abgerufenen Daten in das von unserer Prognose-Engine etablierte Rahmenwerk zu integrieren; das heißt, Dateien wie Lokad_Items.tsv, Lokad_Orders.tsv usw. zu erzeugen. Dieser Ansatz war anfangs ansprechend, weil er eine Normalisierung der von Lokad abgerufenen und verarbeiteten Daten erzwang.

Leider ist diese Abstraktion – wie alle Abstraktionen – undicht. Nicht alle Apps stimmen überein, was genau ein Produkt oder eine Bestellung ist; es gibt eine Menge feiner Unterschiede, die berücksichtigt werden müssen, und es war schlichtweg nicht möglich, alle geschäftlichen Feinheiten durch irgendeine Art von Daten-Normalisierung unterzubringen.

Daher haben wir begonnen, die Herausforderung der Datenintegration aus einem anderen Blickwinkel anzugehen: die App-Daten abzurufen, während wir so viel wie möglich die ursprünglichen Strukturen und Konzepte bewahren. Der Hauptnachteil dieses Ansatzes besteht darin, dass er anfänglich mehr Aufwand erfordert, um Ergebnisse zu erzielen, da die Daten nicht vorab transformiert werden, um mit allen Standard-Erwartungen von Lokad kompatibel zu sein.

Allerdings führt die Tatsache, dass die Daten keinen fehlgeleiteten Transformationen unterzogen werden, auch dazu, dass Lokad nicht daran scheitert, geschäftliche Feinheiten zu berücksichtigen, weil sie nicht in das Rahmenwerk passen. Mit etwas programmatischem Klebstoff berücksichtigen wir die geschäftlichen Anforderungen bis ins kleinste Detail.

Ähnlich wie bei unserem alten Excel-Report folgt der Übergang zu nativen Daten - im Gegensatz zu normalisierten Daten - unseren Erfahrungen, die zeigen, dass eine etwas stärkere Investition, um die Zahlen mit dem Geschäft in Einklang zu bringen, viel mehr Ergebnisse liefert.