Einblicke in die technologische Entwicklung von Lokad

Joannes Vermorel

Die Technologie von Lokad hat sich so stark weiterentwickelt, dass Personen, die vor nur zwei Jahren die Möglichkeit hatten, Lokad auszuprobieren, die App heute kaum wiedererkennen würden.

Das “alte” Lokad war vollständig auf unsere Prognose-Engine ausgerichtet - d.h. auf das, was Sie heute als ein Prognoseprojekt in Ihrem Lokad-Konto sehen können. Als Ergebnis erhielt unsere Prognose-Engine nach und nach viele Funktionen, die nicht einmal entfernt mit Statistik zusammenhängen. Vor etwa zwei Jahren war unsere Prognose-Engine zu einem Alleskönner geworden, der für fast alles verantwortlich war:

• Datenverarbeitung mit der Möglichkeit, eine große Vielfalt von Datenformaten anzupassen
• Berichtsanalyse mit einem etwas komplexen und flexiblen Excel-Prognosebericht
• Geplante Ausführung über eine Webcron-Integration oder über die API

In den letzten zwei Jahren haben wir dann nach und nach eigenständige Ersatzlösungen für diese Funktionen eingeführt, die nun außerhalb unserer Prognose-Engine existieren. Es wäre jedoch unfair, diese neuen Funktionen einfach nur als Ersatz zu bezeichnen, denn diese Ersatzlösungen sind weitaus leistungsfähiger als ihre ursprünglichen Gegenstücke.

• Wir können jetzt sehr unterschiedliche Dateien verarbeiten, die in Größe, Komplexität und sogar Datenformat variieren. Außerdem haben wir viele Datenverbindungen.
• Die Möglichkeiten unseres alten Excel-Prognoseberichts werden von den neueren Berichtsfunktionen von Envision bei weitem übertroffen.
• Planung und Orchestrierung sind nun erstklassige Funktionen, die auch die Datenabfrage aus anderen Apps umfassen.

Da diese neuen Funktionen eindeutig überlegen sind, schaffen wir nach und nach den Ballast ab, d.h. wir schaffen alle nicht mit der Prognose zusammenhängenden Dinge, die immer noch in unserer Prognose-Engine vorhanden sind, ab.

Um den Übergang reibungslos zu gestalten, migrieren wir all unsere Kunden nach und nach - aber aktiv - vom alten Lokad zum neuen Lokad. Wenn eine alte Funktion nicht mehr verwendet wird, entfernen wir sie vollständig.

Der alte Excel-Prognosebericht ist für uns ein schwieriger Fall. Die Herausforderung besteht nicht nur darin, den Bericht selbst in Envision zu duplizieren (das allein ist überhaupt nicht schwer) - die Herausforderung besteht darin, dass das zugrunde liegende Denken, das in diesen Bericht eingeflossen ist, jetzt ziemlich veraltet ist. Tatsächlich hat Lokad im Laufe der Jahre bessere Prognosetechnologien eingeführt - die neueste Version sind probabilistische Prognosen, die nicht in diesen Bericht integriert werden können. Dieser Bericht ist aufgrund seines veralteten Ansatzes für die Prognose leider nicht besonders gut für die Bestandsoptimierung geeignet.

Im Gegensatz dazu erfordert die Kombination von probabilistischen Prognosen mit wirtschaftlichen Treibern sowohl auf Seiten von Lokad als auch auf Seiten des Kunden mehr Aufwand, aber die Geschäftsergebnisse sind einfach nicht vergleichbar. Ersteres optimiert Prozentfehler, während letzteres Dollarfehler optimiert. Es ist nicht überraschend, dass unsere Kunden, sobald sie erkennen, wie viel Geld sie verlieren, wenn sie nicht letzteres tun, nie wieder zu ersterem zurückkehren.

Auch unsere Datenintegrationen durchlaufen derzeit eine ähnliche und nicht weniger radikale Transformation. Als wir damit begannen, Datenverbindungen zu entwickeln, haben wir versucht, alle von uns abgerufenen Daten in das von unserer Prognose-Engine festgelegte Framework zu integrieren. Das führte zur Erstellung von Dateien wie Lokad_Items.tsv, Lokad_Orders.tsv, usw. Dieser Ansatz war anfangs attraktiv, da er eine Normalisierung der von Lokad abgerufenen und verarbeiteten Daten erzwang.

Leider ist diese Abstraktion - wie alle Abstraktionen - undicht. Nicht alle Apps sind sich einig, was genau ein Produkt oder eine Bestellung ist; es gibt viele subtile Unterschiede, die berücksichtigt werden müssen, und es war einfach nicht möglich, alle geschäftlichen Feinheiten durch eine Art Datennormalisierung zu berücksichtigen.

Daher haben wir begonnen, die Herausforderung der Datenintegration aus einem anderen Blickwinkel anzugehen: Wir rufen die App-Daten ab und erhalten dabei so weit wie möglich die ursprünglichen Strukturen und Konzepte. Der Hauptnachteil dieses Ansatzes besteht darin, dass zunächst mehr Aufwand erforderlich ist, um Ergebnisse zu erzielen, da die Daten nicht im Voraus transformiert werden, um mit allen Standarderwartungen von Lokad kompatibel zu sein.

Allerdings bedeutet dies auch, dass die Daten keine fehlerhaften Transformationen durchlaufen und Lokad somit nicht in der Lage ist, geschäftliche Feinheiten aufgrund von Inkompatibilitäten mit dem Framework zu berücksichtigen. Mit etwas programmatischem Klebstoff können wir den geschäftlichen Anforderungen bis ins kleinste Detail gerecht werden.

Ähnlich wie bei unserem alten Excel-Bericht folgt der Übergang zu nativen Daten - im Gegensatz zu normalisierten Daten - unserer Erfahrung, die zeigt, dass es sich lohnt, etwas mehr in die Ausrichtung der Zahlen auf das Geschäft zu investieren, um viel mehr Ergebnisse zu erzielen.