FAQ: Informationstechnologie (IT)

The Lokad app is a webapp provided as SaaS (Software as a Service). The purpose of Lokad is to deliver predictive analytics in order to optimize the supply chain (better stocks, better prices, etc.). The Lokad app is intended as an analytical layer that operates alongside transactional systems (ERP, WMS, CRM, etc.). It comes with a monthly subscription flat fee that typically bundles the app itself with professional services. Those professional services, provided by Lokad’s engineers (Supply Chain Scientists), alleviate almost entirely the need for technical support from the IT department itself for this scope. The one key contribution expected from the IT department is the setup of a data pipeline pushing flat files (by SFTP or FTPS) to Lokad, and potentially reintegrating the results generated.

Zielgruppe: Die IT-Abteilung
Zuletzt geändert: 30. November 2023

Technische Übersicht

Die Lokad-App ist mandantenfähig. Jeder Mandant (d.h. Kundenkonto) verfügt über ein eigenes dediziertes Dateisystem und ein eigenes dediziertes Codebase-Repository. Das Dateisystem ist über FTPS, SFTP und eine Web-Oberfläche zugänglich. Dieses Dateisystem ist auf große Flachdateien (bis zu 100 GB pro Datei) ausgerichtet und bietet Datenversionierung (wie Git). Das Codebase-Repository wird verwendet, um Envision-Skripte zu hosten. Envision ist eine proprietäre DSL (Domain Specific programming Language) entwickelt von Lokad. Diese DSL ist stark auf prädiktive Optimierungsanwendungen spezialisiert. Envision-Skripte werden eingesetzt, um die zentralen numerischen Analysen (einschließlich Machine-Learning-Algorithmen, Solver, …) durchzuführen und datenreiche Dashboards zu erstellen.

Die App wird jeden Dienstag zwischen 10:00 und 14:00 Uhr (Pariser Zeit) vollständig neu bereitgestellt. Die Ausfallzeiten werden in der Regel unter 5 Minuten gehalten. Lokad übernimmt die volle Verantwortung für alle Versionsverwaltungsbelange.

Von der IT-Abteilung wird nicht erwartet, dass sie spezifische Kenntnisse im Lokad’s Stack erwirbt. Falls Sie jedoch neugierig sind, steht eine vollständige technische Dokumentation zur Verfügung.

Überblick über den IT-Beitrag

Wir erwarten von der IT-Abteilung, dass sie eine Datenpipeline einrichtet, die eine kurze Serie relevanter Flachdatei-Extraktionen über SFTP oder FTPS zu Lokad überträgt. Die Extraktionen werden aus den transaktionalen Systemen (z.B. ERP) durchgeführt. Wir bevorzugen Rohtabellen-Extraktionen (kein Filter, kein Join, keine Transformation), die minimalen Aufwand erfordern. Aus ETL-Sicht benötigen wir nur den “E” (extract) Teil in seiner einfachsten Form (reine Kopie). Formattechnisch ist Lokad mit jeder vernünftigerweise tabellarischen Flachdatei kompatibel.

Es wird erwartet, dass die Datenpipeline mindestens täglich läuft und vollständig automatisiert ist. Der Arbeitsaufwand für die IT-Abteilung hängt vom Umfang der Datenauszüge ab (welche Systeme? welche Tabellen?). Als Faustregel gilt jedoch, dass der Aufbau der Datenpipeline typischerweise etwa 15 bis 45 Manntage erfordert, selbst für große Unternehmen. Sobald die Datenpipeline eingerichtet ist, erfordert Lokad in der Regel nur eine minimale Überwachung durch die IT-Abteilung, die üblicherweise mit 1 oder 2 Manntagen pro Monat erfolgt.

Sicherheitsübersicht

Die App wird in Microsoft Azure-Rechenzentren innerhalb der EU gehostet. Wir verarbeiten keine personenbezogenen Daten, da solche Daten für den Betrieb nicht erforderlich sind. Bei der Festlegung des Umfangs der Datenauszüge schließen wir alle Spalten oder Felder aus, die personenbezogene Daten enthalten könnten.

Für die Authentifizierung bevorzugen wir SAML. Wir empfehlen dringend, dass Benutzer über eine föderierte Identität wie Azure Active Directory, Office 365 oder Google Workspace auf Lokad zugreifen. Dadurch werden alle passwortbezogenen Probleme eliminiert.

Auf Anfrage können Sicherheitsüberprüfungen und Penetrationstests von unseren Kunden durchgeführt werden. Die Details hängen von den ausgehandelten Vereinbarungen ab.

Weitere Details finden Sie unter Sicherheit bei Lokad.

Zeitplanübersicht

Die die Quantitative Supply Chain ist eher eine Reise als ein Selbstzweck. Gleichzeitig erfordert die Führung im supply chain, die ihr Unternehmen dazu bewegt, eine die Quantitative Supply Chain-Initiative durchzuführen, Transparenz in Bezug auf den Projektzeitplan. Während positive Erträge in wenigen Monaten erzielt werden können, dauert es häufig bis zu zwei Jahre, bis das volle Potenzial der die Quantitative Supply Chain ausgeschöpft ist. Im Folgenden geben wir einen Überblick über einen typischen Zeitplan, der mit einer die Quantitative Supply Chain-Initiative für ein mittelständisches Unternehmen verbunden ist. Bei großen Unternehmen sollten die Zeitpläne erwartungsgemäß doppelt so lang sein.

Projektstart: Vertreter beider Parteien stellen sich gegenseitig vor und planen wöchentliche Meetings. Diese wöchentlichen Meetings dauern an, bis die Produktionsphase erreicht ist. Der Supply Chain Scientist präsentiert die verschiedenen Implementierungsphasen und die unterschiedlichen Ergebnisse, die der Kunde erwarten kann. Der Rest des Gesprächs ist der Überprüfung verschiedener supply chain Details und IT-Merkmale der Integration gewidmet. Nach dem Gespräch wird eine Zusammenfassung, die die organisatorischen Aspekte des Projekts dokumentiert, erstellt und an den Kunden gesendet.

Daten-Spezifikationen: Kurz nach dem Projektstart erstellt der Supply Chain Scientist die Datenspezifikationen, die für die Umsetzung des Projekts erforderlich sind. Diese Spezifikationen werden gemeinsam mit dem Kunden überprüft und validiert. Insbesondere soll dieses Dokument die Daten definieren, die aus den IT-Systemen des Kunden extrahiert werden sollen. Als Faustregel gilt, dass die Extraktion so nah wie möglich an den Originaldaten bleiben sollte, wie sie in den IT-Systemen des Kunden vorhanden sind.

Erster Datenupload: Nach der Validierung der Spezifikationen wird der erste Datensatz vom Kunden auf Lokad’s Server hochgeladen. In der Regel erfolgt der Upload in diesem Stadium noch nicht automatisiert, da mehrere Versuche erforderlich sind, um einen Konsens über die Feinheiten der Datenspezifikation zu erzielen.

Validierung der Daten: Der Supply Chain Scientist führt eine detaillierte Untersuchung des Inhalts des Kundendatensatzes durch. Insbesondere werden Plausibilitätsprüfungen eingeführt, um die Qualität der Daten anhand mehrerer Kennzahlen zu überwachen. Das Ziel ist sicherzustellen, dass 1) der Datensatz durch den Upload-Prozess ordnungsgemäß aktualisiert wird, 2) der Datensatz die Realität des Geschäfts korrekt widerspiegelt und 3) der Datensatz kohärent und vollständig genug für Zwecke der supply chain Optimierung ist.

Bezüglich der Ergebnisse stellt der Supply Chain Scientist dem Kunden in dieser Phase verschiedene Dashboards zur Verfügung, die den Gesundheitszustand der Daten bewerten. Diese Dashboards können vom Kunden auch für Zwecke verwendet werden, die über die die Quantitative Supply Chain-Initiative hinausgehen – beispielsweise als Teil ihres internen Prozesses zur Datensicherheitsüberprüfung.

Zwischenprojekt-Audit: Sechs Wochen nach dem initialen Projektstart wird ein Meeting angesetzt, um den Fortschritt des Projekts zu evaluieren. Ziel dieses „Audits“ ist es, so früh wie möglich Probleme anzugehen, die während der Umsetzung auftreten könnten, insbesondere solche, die die Produktionsphase verzögern könnten. Bei Lokad besteht dieses „Audit“ aus einem Austausch zwischen dem Supply Chain Scientist und dem Kunden, basierend auf einer Checkliste, die unmittelbar nach dem Projektstart vom Supply Chain Scientist im Voraus an den Kunden kommuniziert wird.

Upload-Automatisierung: Sobald beide Parteien die Gesamtqualität des bisher hochgeladenen Datensatzes validieren, implementiert der Kunde einen automatisierten Prozess, der seinen Datensatz regelmäßig – idealerweise täglich – zu Lokad überträgt. Gleichzeitig wird auf Seiten von Lokad die Logik zur Datenqualität – mit ihren mehrfachen Prüfungen – so geplant, dass sie nach jedem Upload aktualisiert wird.

Einrichtung der Optimierung: Ab diesem Punkt verfügt der Supply Chain Scientist über alle notwendigen Zutaten, um die Optimierung der zuvor mit dem Kunden vereinbarten Entscheidungen umzusetzen. Daher implementiert er Skripte, um verschiedene quantitative Ergebnisse zu generieren: operative Einkaufsvorschläge, Versandvorschläge, etc. Die von diesen Skripten erzeugten Zahlen können in Form von Dashboards visualisiert werden. In diesem Stadium stellen diese Dashboards nur eine vorläufige Version der endgültigen Dashboards dar und müssen gemeinsam mit dem Kunden überarbeitet werden.

Feedback & Feinabstimmung: Die Anfragen des Kunden, die verschiedenen Ergebnisse zu verändern oder anzupassen, führen in der Regel zu einer Feinabstimmung der vom Supply Chain Scientist erstellten Skripte. Es gibt viele Parameter und Methoden, die eingesetzt werden können, um die Eigenschaften des zu optimierenden supply chain angemessen mit der Optimierungslogik in Einklang zu bringen. Wenn die Methodik selbst von strategischer Bedeutung für den Kunden ist, wird dies ausdrücklich zwischen dem Kunden und dem Supply Chain Scientist besprochen.

Produktion: Nach mehreren Runden der Feinabstimmung und Überarbeitung gelangt der Kunde an einen Punkt, an dem er der vom Supply Chain Scientist implementierten Logik vertraut. An diesem Punkt kann der Kunde beginnen, den Service in der Produktion zu nutzen, d.h. er kann die supply chain Entscheidungen, wie ursprünglich von der Software berechnet, direkt umsetzen. Sobald der Kunde bestätigt, dass die Lösung produktionsreif ist, liefert der Supply Chain Scientist eine Dokumentation, die die Wartbarkeit der Lösung gewährleistet.

Support & Wartung: Die Lösung ist in Betrieb und wird vom Kunden verwendet, während der Supply Chain Scientist die reibungslose tägliche Ausführung der Datenpipeline überwacht. Regelmäßig werden Gespräche zwischen dem Kunden und dem Supply Chain Scientist organisiert, um zu überprüfen, ob die Optimierung den erwarteten Grad an supply chain Leistung erbringt. Darüber hinaus sind supply chain nicht statisch, weshalb sich Geschäfts- oder IT-Veränderungen, ob klein oder groß, überprüfen lassen müssen: ein neues Lager, Marktveränderungen, neue Prozesse, etc. Der Supply Chain Scientist schlägt passende Änderungen vor, um diese unterschiedlichen Veränderungen zu berücksichtigen. Kontrollgespräche werden in einem vereinbarten Rhythmus, in der Regel monatlich, geplant.

Häufig gestellte Fragen (FAQ)

1. Release Management

1.1 Wie funktionieren Releases bei Lokad?

Lokad verwaltet alle Releases intern, was dazu beiträgt, vollständige Transparenz für die Kunden zu gewährleisten. Jegliche Releases, die einen Kunden betreffen könnten, werden – über die technischen Teams des Kunden – rechtzeitig mit diesem abgestimmt. Allgemein verfolgt Lokad einen vorsichtigen Ansatz bei Releases: Sollte ein geplanter Release nicht genügend Vorbereitungszeit für einen Kunden bieten, wird der Release vorübergehend verschoben.

Die Releases von Lokad sind sehr granular, und das Design ermöglicht es dem Kunden in der Regel, sich von einem bestimmten technischen Element eines Gesamt-Releases abzumelden. Wenn wir also die Implementierung eines Elements – für das unser Kunde noch nicht bereit ist – verschieben müssen, kann der Gesamt-Release dennoch stattfinden (und die anderen, nicht betroffenen Elemente umsetzen).

1.2 Wie häufig sind die Releases?

Lokad veröffentlicht jeden Dienstag eine neue Version, in der Regel gegen 11 Uhr (MEZ).

1.3 Stellen Sie einen Plan der bevorstehenden Releases bereit?

Ja, siehe Release Management 1.2.

1.4 Beinhaltet ein Versionswechsel eine Neuinstallation oder lediglich einen Patch?

Lokad stellt seine eigene Lösung mittels automatisierter Prozesse (Skripte) neu bereit. Wir patchen Systeme in der Produktion nicht. Falls wir einen “Sicherheits-Patch” einspielen müssen, werden wir die Lösung über unsere üblichen automatisierten Mittel erneut bereitstellen.

1.5 Wie lange dauert es, einen Major Release anzuwenden?

Der automatisierte Prozess dauert etwa 1 Stunde. Es erfolgt ein gestaffelter Rollout (Maschine für Maschine), da wir beabsichtigen, Lokad’s Plattform während des Releases betriebsbereit und zugänglich zu halten. Die Betriebssicherheit während eines Rollouts wird in Release Management 1.7 erläutert.

1.6 Wer ist für die korrekte Durchführung des Releases verantwortlich?

Das Lokad-Team übernimmt die volle Verantwortung für die korrekte Durchführung des Releases.

1.7 Gibt es Ausfallzeiten während des Releases?

Meistens nicht, aber bedenken Sie, dass Lokad’s Lösung ein verteiltes System ist, das für groß angelegte Berechnungen ausgelegt ist. Dementsprechend unterscheidet sich die Auswirkung eines Releases zwischen den Front- und Back-End-Systemen. Kundenorientierte Subsysteme, wie die Dashboards, sind auf null Ausfallzeiten ausgelegt. Back-End-Systeme, die beispielsweise für die Ausführung von Batch-Jobs verantwortlich sind, könnten für einige Minuten pausiert werden (zumindest für einige Jobs). Diese Batch-Jobs können jedoch geplant werden, sodass eine proaktive Planung die Fertigstellung der Batch-Jobs außerhalb des Release-Zeitrahmens ermöglichen sollte.

1.8 Wie sieht Ihr Testprozess bzw. Ihre Strategie für einen Release aus?

Lokad setzt auf automatisierte Prozesse, die dem Testen und der Gewährleistung der Korrektheit eines bevorstehenden Releases gewidmet sind. Diese Prozesse beinhalten umfangreiche Suiten automatisierter Tests (im Tausenderbereich); Unit-Tests, Funktionstests, Leistungstests, etc. Wir haben außerdem spezielle Tools entwickelt, die es uns ermöglichen, gesamte Abläufe vergangener Job-Ausführungen innerhalb der Lokad-Plattform nachzustellen. Diese Tools erlauben es uns zu überprüfen, dass Envision-Skripte vor und nach einem Release exakt dasselbe Verhalten aufweisen. Darüber hinaus können wir sicherstellen, dass die Leistungsprofile bestehender Skripte mit den von unseren Kunden vorgegebenen Zeitplanzielen im Einklang bleiben.

1.9 Haben Sie mehrere Umgebungen?

Ja, allerdings sind die alternativen Umgebungen (auf Plattformebene, neben der Produktionsumgebung) üblicherweise nicht für unsere Kunden gedacht. Neben der Produktionsumgebung und den temporären Entwicklungsumgebungen verfügen wir über eine “evergreen” Umgebung, die der letzten stabilen Version unseres Codebase entspricht. Diese validiert einen spezifischen Teil unserer automatisierten Testprozesse. Unsere Kunden können Zugriff auf unsere “evergreen” Umgebung erhalten, um zu überprüfen, ob ein bestimmter bevorstehender Release wie erwartet funktioniert. In der Praxis tritt diese Situation selten auf.

Wenn das Ziel darin besteht, mehrere Varianten von Envision-Skripten (nebeneinander) ausführen zu können, dann kann ein Lokad-Konto in mehrere “environments” aufgeteilt werden. Wenn das Ziel darin besteht, jegliche Art von Tests durchführen zu können, dann kann ein zweites Lokad-Konto für kurzfristige Testzwecke bereitgestellt werden. Dieser zweite Ansatz hält das primäre Kundenkonto (in der Produktion verwendet) von diesen Tests isoliert.

1.10 Wie viele verschiedene Versionen können koexistieren?

Lokad ist eine Multi-Tenant-SaaS, die für alle ihre Kunden dieselbe eindeutige Version betreibt, jedoch hat Lokad die Fähigkeit, so viele unterschiedliche Versionen zu betreiben, wie der Kunde wünscht.

1.11 Kann ein Kunde sich von einem Release abmelden?

Da Lokad eine Multi-Tenant-SaaS ist, die für alle Kunden dieselbe eindeutige Version betreibt, ist es nicht möglich, sich von einem Release abzumelden. Aus geschäftlicher Sicht ist dies jedoch irrelevant, da jede “Änderung” durch die Ausführung von Envision-Skripten innerhalb der Lokad-Lösung implementiert wird.

Für Fälle, in denen ein Release vorübergehend verschoben werden kann, siehe Release Management 1.1.

1.12 Haben Sie Release Notes? Stellen Sie diese Ihren Kunden zur Verfügung?

Ja. Diese Notizen werden intern (mit unseren Supply Chain Scientist Teams) geteilt. Wenn es explizit als Teil eines Vertrags vereinbart wurde, können diese Release Notes einem Kunden zugänglich gemacht werden. In der Praxis interessieren sich an den Release Notes der Lokad-Plattform hauptsächlich diejenigen, die mit Envision-Code arbeiten.

1.13 Wie ist der Prozess, wenn ein Kunde eine Weiterentwicklung der Lösung anfordert?

Die meisten unserer Kunden profitieren von einem “software + expert”-Angebot, bei dem ein Team von Lokad’s Supply Chain Scientists für die Implementierung und Wartung der supply chain solution eines Kunden verantwortlich ist. Diese Situationen sind als “supply chain as a service” bekannt. In diesen Vereinbarungen interagiert der Kunde routinemäßig mit einem (oder mehreren) Supply Chain Scientists. Zudem profitieren die meisten Kunden von einem wöchentlichen oder monatlichen Lenkungsausschuss, um den aktuellen Stand der Lösung und gewünschte Weiterentwicklungen zu besprechen. Diese Methode verwendet Lokad, um alle Evolutionsanfragen zu sammeln und eine Roadmap für die Umsetzung der Änderungen vorzuschlagen.

1.14 Ist es möglich, den Anwendungs-Webservice zu administrieren und dessen Parameter zu konfigurieren?

Ja, insofern als die Lokad-Plattform von Natur aus programmatisch ist. Die “analytische” Logik von Lokad nimmt die Form von Envision-Skripten an – Envision ist die DSL (Domain-Specific Language), die von Lokad für die prädiktive Optimierung der supply chain entwickelt wurde.

Somit ist in gewissem Sinne jede einzelne Parameterkonfiguration verfügbar, indem man Envision-Skripte innerhalb des Kontos nutzt.

2. Performance

2.1 Deckt Ihr SLA (Service Level Agreement) eine Betriebszeit von 99.xy% ab?

Ja. Das SLA ist Bestandteil unserer standardmäßigen vertraglichen Vereinbarung. Allerdings ist der Begriff der Betriebszeit im Kontext eines verteilten Computersystems – das der prädiktiven Optimierung von supply chains gewidmet ist – komplex. Betrachten Sie die folgenden Szenarien: - Lokad erhält Kundendaten (ein täglicher Schritt) 2 Stunden verspätet. Dies kann durchaus die übliche Effizienz unserer Heuristiken zur Ressourcenallokation stören. Dies wiederum kann die Zeit, die benötigt wird, um Lokad’s Batch-Jobs auszuführen (z. B. 75 Minuten anstelle der üblichen 60), verlängern. Einige mögen dies als einen 15-minütigen Ausfall betrachten, aber das liegt außerhalb unserer Kontrolle.

• Lokad erhält dieselben Kundendaten pünktlich, aber die Daten weisen einen erheblichen Rückgang der Lagerbestände auf. Dies würde eine Unterbrechung der Batch-Jobs (auf der Lokad-Seite) auslösen und einen Supply Chain Scientist alarmieren, um das Problem zu untersuchen. Der Supply Chain Scientist stellt fest, dass eine automatisierte Nachbestellung beispiellos hoch ist. Der Supply Chain Scientist entscheidet, dass eine direkte Rückmeldung vom Kunden notwendig ist. Am nächsten Tag bestätigt der Kunde, dass die Lagerbestandsdaten korrumpiert waren und zu einem großen Lagerabschreibung geführt hätten. Einige mögen dies als einen 24-stündigen Ausfall betrachten, aber das erscheint im Kontext praktisch unvernünftig.

Die größte Gefahr für eine supply chain optimization Lösung besteht nicht darin, ein wenig zu spät zu sein; sie besteht darin, sehr falsch zu liegen. Sobald eine supply chain Entscheidung getroffen wurde, wie (fälschlicherweise) das Auslösen eines Produktionsloses, kann das Rückgängigmachen äußerst kostspielig sein. Wir ermutigen unsere Kunden, sich nicht willkürlich an isolierte Indikatoren zu klammern, da diese Haltung Menschen dazu anreizen kann, insgesamt minderwertige Arbeit zu leisten, solange es den Anschein hat, eine KPI (wie z. B. x.y% Betriebszeit) zu erfüllen.

2.2 Garantieren Sie eine Antwortzeit für Benutzeranfragen innerhalb von X Sekunden?

Ja, unter 500 ms, jedoch mit Vorbehalten.

Wir haben im Wesentlichen “konstante Zeit Dashboards” entwickelt. Unter der Haube erfordert die Anzeige eines Dashboards eine einzige Anfrage über das Netzwerk, und in unserem Back End bündeln wir alle Dashboard-Daten, um die Anzahl der Netzwerk-Anfragen gering zu halten (in der Regel einstellige Zahlen). Dieses Design trägt erheblich dazu bei, die niedrige Latenz der typischen Benutzeranfrage bei der Anzeige eines Dashboards “zu garantieren”. Diese Design-Entscheidung verhindert zudem, dass das Dashboard mit Kacheln überfrachtet wird – von denen jede Netzwerk-Anfragen erfordern würde – und damit die gesamte Benutzererfahrung verlangsamt.

Bezüglich der Dauer von Batch-Jobs können wir durch Envision Garantien – zur Compile-Zeit – dafür bieten, dass ein Batch-Job abgeschlossen wird. Wir können auch weitgehend reproduzierbare Abschlusszeiten für unsere Batch-Jobs garantieren. Diese Garantien werden durch statische Analysen und ein sorgfältiges Design der Envision-Sprache erreicht – was bestimmte Klassen von statischen Analysen erst ermöglicht. Dieser Ansatz hat seine Grenzen, ist aber den Designs, die keinerlei Garantien bieten, weit überlegen.

Die End-to-End-Latenz liegt jedoch nicht vollständig in unserer Hand. Zum Beispiel kontrollieren wir nicht die Qualität der Internetverbindung, die von unseren Kunden genutzt wird. Eine große Tabelle von Lokad wird über ein Netzwerk mit niedriger Bandbreite Zeit zum Herunterladen benötigen.

2.3 Haben Sie Audit-Logs zur Systemleistung?

Ja. Wir sammeln sehr detaillierte Performance-Logs für alle beteiligten Rechenressourcen: CPU, Speicher, Storage, Bandbreite, etc. Diese Performance-Logs werden unter anderem dazu verwendet, sicherzustellen, dass eine neue, bislang unveröffentlichte Version der Plattform unsere Erwartungen in Bezug auf die Leistung erfüllt. Wir testen dies, indem wir die Leistung der neuen Version mit der Leistung früherer Versionen vergleichen, wie es diese Logs belegen.

2.4 Ist es möglich, langsame Antworten oder Engpässe zu überwachen?

Ja. Die Lokad-Plattform verfügt über einen internen Scheduler, der die termingerechte Ausführung von Batch-Jobs überwachen kann. Das Design von Lokad gewährleistet weitgehend eine konstante Antwortzeit für alle Anfragen – abgesehen von lang laufenden Operationen, die als Batch-Jobs behandelt werden.

Da Lokad eine Multi-Tenant-Plattform ist, ist ein großer Teil der Performance-Überwachung nicht direkt für unsere Kunden zugänglich (da sie die Performance der Plattform als Ganzes abdeckt). Wie zu erwarten überwachen die Lokad-Teams kontinuierlich die Performance unserer Plattform.

2.5 Haben Sie Load Balancers?

Ja. Die Load Balancers von Lokad sind in erster Linie auf Zuverlässigkeit und nicht auf Performance ausgerichtet. Das Load Balancing auf Netzwerkebene wird durch die Netzwerkschicht der von uns genutzten Cloud-Computing-Plattform (Microsoft Azure) durchgeführt. Die Verteilung der internen Datenverarbeitungs-Last, wie sie von der Lokad-Plattform gehandhabt wird, wird jedoch nicht über Load Balancers, sondern über einen hausinternen Orchestrator, der mit unserem Compiler-Stack verbunden ist, gesteuert.

2.6 Poolen Sie Ressourcen wie DB-Verbindungen, Sessions, etc.?

Ja. Allerdings basiert die Lokad-Plattform nicht auf einer transaktionalen Datenbank. Daher gibt es keine DB-Verbindungen zum Poolen. Nichtsdestotrotz poolen wir viele andere Ressourcen, wann immer es aus Performance-Sicht sinnvoll ist.

2.7 Unterstützen Sie parallele Verarbeitung?

Ja. Envision (unsere DSL) ist um das Konzept der automatisierten parallelisierten Ausführung herum konzipiert. Die Lokad-Plattform nutzt Parallelisierung aktiv auf mehreren Ebenen: auf CPU-Kernebene durch SIMD (Single Instruction/Multiple Data)-Operationen; auf CPU-Ebene durch mehrfädige Ausführungen; und auf Cluster-Ebene durch verteiltes Computing. Da parallele Verarbeitung ein zentrales Designelement von Envision ist, profitiert quasi die Gesamtheit der auf der Lokad-Plattform ausgeführten Workloads standardmäßig von einer umfangreichen Parallelisierung, ohne dass unsere Kunden oder unsere Supply Chain Scientists einen speziellen Aufwand betreiben müssen.

2.8 Unterstützen Sie das Caching von häufig abgerufenen Daten?

Ja. Caching wird jedoch häufig als Lösung genutzt, um die Performance-Einschränkungen von transaktionalen Datenbanken zu umgehen. Da die Lokad-Plattform transaktionale Datenbanken nicht umfasst, verwenden wir Caching für diesen Zweck nicht.

2.9 Komprimieren Sie Daten, um den Netzwerkverkehr zu reduzieren?

Ja, wir komprimieren den Großteil des Netzwerkverkehrs. Allerdings können wir nicht alles komprimieren, da dies eine Sicherheitslücke darstellen würde, die als BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) bekannt ist. BREACH tritt auf, wenn eine Kombination von 3 Faktoren vorliegt.

1. Eine Antwort wird komprimiert.

2. Eine Antwort enthält ein Geheimnis.

3. Eine Antwort enthält einen String, der vom Angreifer, der die Anfrage erstellt, gesammelt werden kann.

Um sich gegen BREACH zu schützen, deaktiviert Lokad die Komprimierung bei allen Antworten, bei denen die dritte Bedingung erfüllt ist. Wir komprimieren Daten außerdem nicht nur, um den Netzwerkverkehr zu reduzieren, sondern auch, um erstens die Datenspeicherkosten zu senken und zweitens die Berechnungsverzögerungen zu verringern.

2.10 Führen Sie Performance-Tests durch?

Ja. Lokad verfügt über eine umfangreiche, automatisierte, performance-orientierte Instrumentierungsschicht. Diese Reihe von Werkzeugen ermöglicht es uns, vor jedem Release die Leistungsdifferenz der kommenden Version im Vergleich zur aktuell eingesetzten Version zu bewerten. Mit diesem Tool können wir die gleichen Workloads, wie sie in der Produktion beobachtet werden, reproduzieren und die daraus resultierende Performance überwachen – nicht nur in Echtzeit, sondern unter Berücksichtigung aller relevanten Rechenressourcen (Speicher, Bandbreite, I/O, CPU, etc.).

2.11 Überwachen Sie die Performance auf Transaktionsebene?

Ja. Da die Lokad-Plattform jedoch keine transaktionale Datenbank verwendet, gibt es keine “Transaktionen” im herkömmlichen Sinne zu überwachen. Das nächstliegende Äquivalent ist die Ausführung von Envision-Skripten. Für diese Skripte überwachen wir die Performance auf einer sehr granularen Ebene, was grob dem Überwachen der Details des Abfrageplans (aus der Perspektive einer transaktionalen Datenbank) entspricht.

Siehe Authorization 3.6 und Logging and Monitoring 5.3 in unserer Security-Dokumentation für weitere Informationen zu “Transaktionen” in der Lokad-Lösung.

2.12 Wie wirkt sich die gleichzeitige Nutzung durch mehrere Benutzer auf die Performance der Lösung aus?

Fast keiner. Das Design von Lokad stellt sicher, dass Dashboards auch bei einer großen Anzahl von Benutzern (nach B2B-Standard) in konstanter Zeit bedient werden können. Dieser Ansatz steht in starkem Kontrast zu vielen alternativen Architekturen, insbesondere zu transaktionalen Datenbanken und Business-Intelligence-Cubes.

Allerdings, da jeder einzelne Benutzer (bei entsprechendem Systemrecht) theoretisch beliebig große Arbeitslasten auslösen könnte, ist die Anzahl der gleichzeitigen Benutzer bestenfalls ein sekundärer Aspekt hinsichtlich der Performance der Lösung. Soweit es um die supply chain predictive optimization geht, machen die Batch-Jobs, die zur Durchführung der relevanten Analysen verwendet werden, mehr als 99% der Arbeitslast aus. Der Rest, weniger als 1%, ist der Bearbeitung von Benutzeranfragen gewidmet.

2.13 Ist das System dafür ausgelegt, vertikal und horizontal zu skalieren?

Ja. Aus unserer Sicht sind vertikale und horizontale Skalierung komplementär, und das Design der Lokad-Plattform nutzt beides. Der interne Orchestrator – der für die Parallelisierung zuständig ist – beginnt typischerweise mit der vertikalen Skalierung, da diese die Datenkolokation erheblich erleichtert. Anschließend nutzt der Orchestrator die horizontale Skalierung, wenn die Arbeitslast groß genug ist, um von einer Multi-Maschinen-Ausführung zu profitieren.

2.14 Skalieren Sie Rechenleistung und Speicher automatisch nach Bedarf?

Ja. Die Lokad-Plattform ist Multi-Tenant. Durch die Multi-Tenancy führen wir groß angelegte, latenzarme Zuweisungen von Rechenressourcen durch. Dies bedeutet, dass das von Lokad bereitgestellte automatische Skalieren der Rechenleistung um Größenordnungen schneller erfolgt als das Hochfahren großer VMs (Virtual Machines) von einem Cloud-Computing-Anbieter. Das automatische Skalieren des Speichers wird weitgehend durch die Nutzung der Auto-Scaling-Eigenschaften des persistenten Key-Value Stores, wie sie von der zugrundeliegenden Cloud-Computing-Plattform (Microsoft Azure) bereitgestellt werden, realisiert.

2.15 Wie geht Ihre Anwendung mit “Big Data”-Anforderungen um?

Die Lokad-Plattform wurde speziell für die Verarbeitung von “Big Data” konzipiert. Stand Januar 2023 verwaltet die gesamte Lokad-Plattform etwa 1 Petabyte an Daten über unsere gesamte Kundenbasis hinweg. Unsere Plattform kann einzelne Dateien von bis zu 100GB verarbeiten, und wir verarbeiten routinemäßig Tabellen mit zig Milliarden Zeilen. Gehe zu Security of Lokad 4.10

Dieser Punkt ist besonders technisch und geht über den Umfang dieses Dokuments hinaus. Für eine ausführliche Erklärung empfehlen wir die vierteilige Serie von Victor Nicollet über das Design der Envision Virtual Machine.

2.16 Kann die cloudbasierte Lösung von Lokad im Hinblick auf enge Bandbreiten- und Latenzvorgaben (clientseitig) konfiguriert werden? Zum Beispiel: Bandbreite = 3Mbps (Download) / 1Mbps (Upload), Latenz = 600-800ms

Ja, die von Lokad entwickelte Webapp ist so konzipiert, dass sie Szenarien unterstützen kann, in denen die Konnektivität “schlecht” ist (sowohl in Bezug auf Bandbreite als auch Latenz). Diese Bedenken werden hauptsächlich durch grundlegende technologische Designentscheidungen adressiert. Diese architektonischen Designentscheidungen heben Lokad auch vom Mainstream ab. Bedenken hinsichtlich der Bandbreite werden auf zwei Arten angegangen. Erstens sind wir sparsam im Umgang mit JavaScript-Drittanbieterkomponenten. Wir haben weniger als 1MB an Assets, die initial abgerufen werden müssen. Zweitens bietet die Plattform vollständige Kontrolle über die Menge der in ein einzelnes Dashboard einzubindenden Daten. So ist es bei schlechter Konnektivität möglich, das Dashboard entsprechend “leicht” zu gestalten. Was die Latenz betrifft, so sind unsere Dashboards so entwickelt, dass sie alle relevanten Dashboard-Daten in einer einzigen HTTP-Anfrage verpacken. Dies minimiert die Reibungsverluste, die Endbenutzer mit niedriger Latenz erleiden.

2.17 Wie hoch sind die durchschnittlichen und maximalen Daten-Durchsatzkapazitäten der Lösung im Vergleich zu einem Benchmark von 1 (niedrig) und 5 (hoch) Nachrichten pro Sekunde?

Die Lokad-Plattform arbeitet nicht mit Nachrichten. Ebenso erfolgen Interaktionen mit der Lokad-Plattform nicht über Nachrichten. Trotzdem spielt der Durchsatz eine Rolle, um umfangreiche Datensätze von Transaktionsdaten zügig zu verarbeiten. Die Lokad-Plattform verwaltet insgesamt über 1 Petabyte an Daten. Wir verarbeiten routinemäßig über 1 Terabyte pro Minute für große Berechnungsläufe.

Ein extrem hoher Durchsatz ist wichtig, um betriebliche Verzögerungen bei der Verarbeitung sehr großer Datensätze (Dutzende Terabytes) mit komplexen Berechnungen, die maschinelles Lernen und mathematische Optimierungsschritte beinhalten, zu vermeiden.

2.18 Welche Größe von Nachrichten kann die Lösung verarbeiten? Bitte geben Sie Details zu Mindest-, Höchst- und Durchschnittswerten an.

Die Lokad-Plattform arbeitet nicht mit Nachrichten. Das Nächstliegende wären “flat files”. Diese flat files können an Lokad gesendet und von Lokad abgerufen werden. Die Lokad-Plattform kann Dateien verarbeiten, die jeweils bis zu 100GB groß sind. Dies wird jedoch nicht empfohlen, da es in der Regel etwas unhandlich ist (nicht für Lokad, sondern für die Kunden, die sich mit externen Werkzeugen vertraut machen müssen, um die großen Dateien zu erzeugen und zu konsumieren).

3. Incidents

3.1 Wie meldet ein Kunde einen Vorfall?

Die meisten unserer Kunden profitieren von einem Paket, das Zugang zu unserem Team von Supply Chain Scientists beinhaltet. Diese Supply Chain Scientists sind der erste Ansprechpartner, wenn es darum geht, Vorfälle zu melden. Im Falle eines Vorfalls empfehlen wir den Kunden, entweder ihren Supply Chain Scientist direkt anzurufen – falls das Problem dringend ist – oder eine E-Mail zu senden. Die Supply Chain Scientists kümmern sich um das Incident Management, einschließlich aller Eskalationen innerhalb von Lokads Organisation.

3.2 Bieten Sie ein Ticketsystem an?

Ja. Lokad nutzt ein Ticketsystem eines Drittanbieters. Allerdings haben wir ab Januar 2023 mit der Entwicklung einer internen Lösung begonnen, die eine enge Integration mit dem Rest unserer Plattform bietet.

3.3 Unterstützen Sie die Meldung von Vorfällen an Drittanbieter-Tools?

Ja, unter Vereinbarung eines speziellen Vertrags.

Im Kontext der prädiktiven Supply Chain Optimierung können “Vorfälle” variieren und schwer zu definieren sein. Generell betrachten unsere Kunden geringfügige Ereignisse auf Plattformebene (wie minimale Ausfallzeiten) nicht als “Vorfälle”. Stattdessen wären tatsächliche Supply Chain Anomalien – die möglicherweise auf Probleme mit in den Kundenkonten implementierten Envision-Skripten hinweisen oder auch nicht – bessere Kandidaten. Externe IT-Abteilungen sind selten in die Behebung dieser Vorfälle eingebunden.

3.4 Wie stellen Sie eine hohe Verfügbarkeit sicher?

Lokad wurde (ca. 2010) ein Vorreiter in der Nutzung von Cloud-Computing-Plattformen, gerade um eine höhere Verfügbarkeit zu gewährleisten. Neben der Redundanz der Infrastruktur (siehe Vorfälle 3.5) legt das Design von Lokads Lösung großen Wert auf Einfachheit. Im Vergleich zu vergleichbaren Enterprise-Softwarelösungen verfügen wir über deutlich weniger komplexe Abhängigkeiten (um fast eine Größenordnung weniger). Eine enorme Komplexitätsschicht, die in unserer Lösung fehlt, ist eine transaktionale Datenbank. Da wir über weniger bewegliche Teile verfügen, gibt es auch weitaus weniger Ausfallmodi, was uns hilft, für unsere Kunden (die über mehrere Zeitzonen verteilt sind) eine hohe Verfügbarkeit aufrechtzuerhalten.

3.5 Verfügen Sie über eine redundante Infrastruktur (falls ja, wie)? Vermeiden Sie einzelne Ausfallpunkte?

Ja. Unsere kritischen Systeme sind redundant, um gezielt einzelne Ausfallpunkte zu vermeiden. Zu den redundanten Systemen gehören auch die Subsysteme, die zustandsbehaftete Protokolle wie SFTP unterstützen. Darüber hinaus ist die Datenspeicherung nicht nur redundant, sondern auch geografisch redundant. Diese Redundanz wird während unserer Releases genutzt, um die Betriebszeit während des Rollouts aufrechtzuerhalten.

3.6 Wie erholen Sie sich von Hardwareausfällen?

Die Wiederherstellung bei den meisten Hardwareausfällen wird transparent von der von Lokad genutzten Cloud-Computing-Plattform durchgeführt. Die eingebaute Redundanz der Lokad-Plattform stellt sicher, dass vorübergehende Hardwareausfälle die Betriebszeit nicht beeinträchtigen, während die Cloud-Computing-Plattform eine neue, fehlerfreie Ressource zuweist. Für die persistente Datenspeicherung nutzt Lokad ausschließlich Dienste (z. B. Key-Value Stores), die durch ihre eigenen Redundanzschichten vor Hardwareausfällen geschützt sind.

3.7 Verfügen Sie über ein Backup?

Ja. Wir verfügen über eine Backup-Umgebung, die speziell für schwerwiegende Disaster-Recovery-Szenarien (über Rechenzentrumsausfälle hinaus) vorgesehen ist. Diese Backup-Umgebung ist vollständig von der Produktionsumgebung isoliert. Die Backup-Umgebung kann aus der Produktionsumgebung lesen (aber nicht schreiben), während die Produktionsumgebung weder lesen noch in die Backup-Umgebung schreiben kann.

3.8 Haben Sie einen Disaster-Recovery-Plan?

Ja. Auf technischer Ebene deckt der Disaster-Recovery-Plan die vollständige Neuaufsetzung der Lokad-Plattform ab. Dieser Teil nutzt umfassend die automatisierten Prozesse, die wir für unsere wöchentlichen Releases etabliert haben. Auf Geschäftsebene beinhaltet der Disaster-Recovery-Plan, jeden unserer Kunden zu kontaktieren, üblicherweise nach einem mit jedem vereinbarten Verfahren. Für die meisten unserer Kunden fungieren die zugewiesenen Supply Chain Scientists während der Wiederherstellung als primäre Ansprechpartner.

3.9 Unterstützt die Lösung Point-in-time Recovery (PITR) sowohl für Datenbanken als auch für Daten außerhalb von Datenbanken? Was ist das Recovery Point Objective (RPO) der Lösung?

Die Lösung von Lokad zeichnet sich durch ein kontinuierliches Datenschutz-Design aus, bei dem sowohl der Event Store als auch die Content Source live inkrementell gesichert werden. Daher können wir PITR für jeden beliebigen Moment durchführen (bis auf Minutenebene).

Wir haben ein RPO von 1 Minute für Notfälle auf Rechenzentrumsebene – sofern die Daten nicht beeinträchtigt sind. Dies erreichen wir durch den Einsatz geografisch redundanter Schreibvorgänge in unserem persistenten Key-Value Store. Sollte der Key-Value Store kompromittiert werden, stellt Lokad die Daten aus dem Backup-Speicher wieder her (der so isoliert wie möglich von unseren Produktionssystemen gehalten wird), welcher ebenfalls in einer anderen geografischen Region gehostet wird. In diesem Fall beträgt das RPO 12 Stunden.

3.10 Kann die Lösung Integritätsverletzungsalarme erzeugen? Verfügt die Lösung über die Möglichkeit, Integritätsprüfungen nach Bedarf hinzuzufügen oder zu erweitern?

Ja, jedoch spiegelt diese Art von Problem in erster Linie ein Softwaredesign wider, das auf einer transaktionalen Datenbank basiert. Die Lokad-Plattform arbeitet nicht mit einer transaktionalen Datenbank, sondern mit einem Event Store und verwendet ein Event-Sourcing-Design anstelle eines relationalen Ansatzes. Das nimmt nicht die Notwendigkeit weg, die Datenintegrität sicherzustellen, aber diese Aspekte werden auf alternative Weise adressiert.

Wenn es um die Verarbeitung von Kundendaten geht, verfügt Envision (Lokads DSL) über umfangreiche Möglichkeiten zur Qualitätsprüfung. Über Envision ist es möglich, die Integrität zu überprüfen und Alarme zu generieren. Diese Logik kann in jeder vom Kunden als angemessen erachteten Weise erweitert oder abgeändert werden.

3.11 Werden Backups regelmäßig auf eine ordnungsgemäße Datenwiederherstellungsfunktion getestet?

Ja. Das Event-Sourcing-Design von Lokad, kombiniert mit seinem content-addressable Store, macht das Testen der Backup- und Datenwiederherstellungsfunktion wesentlich einfacher als bei den meisten Mainstream-Designs, die relationale Datenbanken (wie SQL) verwenden.

Siehe auch Vorfälle 3.7.

3.12 Werden die Disaster-Recovery-Pläne regelmäßig auf eine ordnungsgemäße Notfallwiederherstellungsfunktion getestet?

Ja. Die Deployment-Strategie von Lokad nutzt durchgängige automatisierte Skripte und hält bewusst menschliche Eingriffe auf ein Minimum – eine bemerkenswerte Ausnahme ist die Möglichkeit, eine vollständige Produktions-Neuimplementierung auszulösen. Dieser stark automatisierte Ansatz erleichtert das Testen der Notfallwiederherstellungsfunktion.

Siehe Vorfälle 3.8.

3.13 Kann die Wiederherstellung für einzelne Kunden und/oder Kundenumgebungen durchgeführt werden?

Ja. Unsere internen Tools unterstützen die Möglichkeit, das Konto eines ausgewählten Kunden wiederherzustellen (einschließlich der Wiederherstellung des Kontos bzw. der Umgebung zu einem bestimmten Zeitpunkt). Angesichts der Tatsache, dass die Lokad-Plattform selbst umfangreiche Versionierungsmöglichkeiten bietet (z. B. werden Envision-Skripte versioniert und frühere Versionen sind innerhalb der App zugänglich), wird diese Funktionalität jedoch selten genutzt.

3.14 Erfüllen die Backup- und Disaster-Recovery-Pläne die RTO (Recovery Time Objective), RPO (Recovery Point Objective) und die Anforderungen an Notfallszenarien der Kunden (wie von den jeweiligen Kunden definiert und vereinbart)?

Ja. Das Recovery Time Objective (RTO) bezieht sich hier auf die Zeitspanne, in der die Lokad-Plattform theoretisch ausfallen könnte, ohne dass dem Kunden erheblicher Schaden entsteht, sowie auf die Zeit, die für die Wiederherstellung der Plattform und ihrer Daten benötigt wird, damit der normale Betrieb nach einem bedeutenden Vorfall wieder aufgenommen werden kann.

Das RTO hängt stark von den Details der spezifischen Prozesse ab, die von Lokad unterstützt bzw. bereitgestellt werden. Beispielsweise kann ein Kunde, der Lokad für die Planung monatlicher Übersee-Bestellungen nutzt, ein RTO von 1 Woche haben. Im Gegensatz dazu könnte ein Kunde, der auf Lokad setzt, um seinen täglichen Lagerbestandstransport von einem Lager zu mehreren Geschäften zu optimieren, ein RTO von 1 Stunde haben.

In der Praxis können verschiedene technische Vorkehrungen getroffen werden, um das RTO erheblich zu verbessern (d. h. eine theoretische Ausfallzeit zu verkürzen). Beispielsweise können Failover-Entscheidungen im Voraus berechnet werden. Diese Entscheidungen können genutzt werden, falls die Lokad-Plattform nicht verfügbar ist. Im Vergleich zu “regulären” optimierten Entscheidungen können Failover-Entscheidungen eine leicht schlechtere Versorgungseffizienz aufweisen, da sie definitionsgemäß nicht auf die absolut neuesten Daten zugreifen.

Für unsere verwalteten Konten liegt es in der Verantwortung des Supply Chain Scientist bei Lokad, gemeinsam mit den operativen Teams des Kunden einen Prozess zu entwickeln – einen Prozess, der ein hohes RTO bietet, aber auch dafür sorgt, dass im Falle eines tatsächlichen Vorfalls nur minimale geschäftliche Auswirkungen entstehen. Aus unserer Sicht ist diese Herausforderung in erster Linie ein Supply Chain-Problem und kein IT-Problem.

Siehe auch Vorfälle 3.9.

3.15 Falls ein Defekt in der Testumgebung nicht reproduzierbar ist, kann Lokad anhand von Logs und unterstützenden Daten überprüfen, dass der Defekt aufgetreten ist, und sicherstellen, dass der Defekt gemäß dem Service Level Agreement (SLA) behoben wird?

Ja, Defekte können in unseren Umgebungen reproduziert werden. Die strikte Reproduzierbarkeit aller Datenzustände und Berechnungen ist ein zentrales Gestaltungsprinzip der Lokad-Plattform und -Architektur. So ist beispielsweise das Dateisystem innerhalb der Lokad-Plattform vollständig versioniert (wie Git), um dieses Anliegen zu adressieren.

Es sei darauf hingewiesen, dass Logs bei der Fehlersuche bei trivialen Problemen, wie etwa Serverausfällen, effektiver sind. Bei der Fehlersuche in komplexen Problemen und Defekten in einer groß angelegten Datenumgebung – in der Terabytes an Daten verarbeitet werden – sind Logs oft unzureichend.

Daher ziehen wir zwar Logs bei Bedarf zu Rate, verlassen uns aber nicht ausschließlich auf diese, um Defekte zu beheben oder deren Behebung zu verifizieren. Stattdessen setzen wir in erster Linie auf überlegene Designentscheidungen, die mehr Einblick, Nachvollziehbarkeit und Reproduzierbarkeit ermöglichen.

Diese bewussten Designentscheidungen ermöglichen es uns, Defekte zu identifizieren, zu reproduzieren und zu beheben – etwas, das sich allein durch das Vertrauen auf Logs nicht erreichen ließe.

Bitte lesen Sie Architecture of Lokad für eine detaillierte Aufschlüsselung der verschiedenen zentralen Designentscheidungen, die wir treffen, um ganze Klassen gängiger Softwareprobleme zu vermeiden.

3.16 Führen Sie Aufzeichnungen über alle Serviceanfragen und Serviceanrufe (einschließlich der Kategorie jedes Anrufs) der Kundenfirma? Umfassen die Aufzeichnungen: die Identität des Anrufers und des Angerufenen; die Art des gemeldeten Fehlers, Problems oder Vorfalls; die Reaktionszeit von Lokad; die Abwicklung des Serviceanrufs; die Lösung; die Lösungszeiten; und die Systemverfügbarkeit?

Ja, die Plattform von Lokad verfügt über Funktionen zum Aufgaben-/Ticket-/Issue-Management, die die aufgeführten Details liefern.

Bezüglich “resolutions” sei darauf hingewiesen, dass Lokads Quantitative Supply Chain Philosophie (QSC) darauf abzielt, den finanziell vorteilhaftesten Interessenausgleich bei einem Problem zu finden. QSC ist technisch gesehen kein Ansatz zur “Problemlösung”, da Supply Chain Probleme nicht “behoben” werden, sondern durch finanziell fundierte Abwägungen abgeschwächt werden.

Kurz gesagt, Lokad verfügt über die Werkzeuge und Prozesse, um “einfache Probleme” (wie Serverausfälle) umgehend und unkompliziert zu beheben. Bei den größeren, folgenreicheren Supply Chain Problemen (wie der Zuweisung von Einzelhandelsbeständen oder Problemen bei der Lagerauffüllung) handelt es sich in der Regel um offene und fortlaufende Diskussionen mit den Kunden, in denen abgewogen wird, welche Kompromisse den maximalen Return on Investment erzielen.

4. Architecture

4.1 Welche Programmiersprachen verwenden Sie?

Die Lokad-Plattform wird in C#, F# und TypeScript entwickelt. Zudem verfügt die Plattform über Envision (Lokads DSL), das zur Implementierung der kundenspezifischen Supply Chain Lösungen genutzt wird.

4.2 Welche Entwicklungsumgebung verwenden Sie?

Die Softwareentwicklungsteams von Lokad nutzen Microsoft Visual Studio. Die Supply Chain Scientist Teams nutzen die Lokad-Plattform selbst, die über eine eigene Entwicklungsumgebung verfügt.

4.3 Welches Betriebssystem unterstützen Sie?

Lokad ist eine webbasierte Plattform und wir unterstützen alle Betriebssysteme, die Zugriff auf einen modernen Webbrowser bieten (z. B. Firefox). Intern ist die Lokad-Plattform sowohl mit Linux als auch mit Microsoft Windows kompatibel, wobei alle unsere Produktionssysteme unter Linux (Ubuntu) bereitgestellt werden.

4.4 Welches Datenbanksystem verwenden oder unterstützen Sie?

Lokad unterstützt alle Datenbanksysteme, die flat file Exporte erzeugen können. Dies umfasst praktisch alle Datenbanksysteme des Marktes, einschließlich älterer Modelle. Intern verwendet Lokad kein Datenbanksystem, sondern einen Key-Value Store. Zum Zeitpunkt dieses Schreibens (Januar 2023) nutzen wir Blob Storage, wie es von Microsoft Azure bereitgestellt wird.

4.5 Welches Caching-System verwenden Sie?

Lokad hat eigene Caching-Subsysteme in C#/.NET entwickelt. Diese Subsysteme sind eng in den Rest der Lösung integriert und entsprechen nicht den herkömmlichen Caching-Systemen, die in erster Linie dafür gedacht sind, Leistungsprobleme bei einer relationalen Datenbank abzumildern (die Lokad nicht besitzt).

4.6 Wie geht die Lösung mit Zertifikaten um?

Lokad nutzt Let’s Encrypt durch automatisierte Zertifikatserneuerungen.

4.7 Was sind die technischen Voraussetzungen für die Nutzung der Lösung?

Die wichtigste technische Voraussetzung ist ein Transaktionssystem, das den Bestand verfolgt. Zusätzlich ist es hilfreich, wenn der Kunde bereits Erfahrung mit der Extraktion von Daten (als Flachdateien) aus seinen Transaktionssystemen hat, dies ist jedoch keinesfalls eine Voraussetzung.

4.8 Listen Sie alle zusätzlichen Drittanbieter-Lizenzen auf, die für den Betrieb der Lokad-Lösung erforderlich sind (z.B. OS, SQL,…).

N/A. Lokad benötigt keine Drittanbieterlizenz(en) für den Betrieb. Es gibt eine breite Palette von Open-Source-Tools, die die Integration von Lokad unterstützen (d.h. Flachdateien, die über FTPS oder SFTP übertragen werden); daher ist auch indirekt keine Drittanbieterlizenz erforderlich, um von der Lokad-Plattform zu profitieren.

4.9 Erfordert der Service Browser-Plugins oder spezielle Software?

Lokad ist eine Webanwendung. Es werden keine Browser-Plugins oder spezielle Software benötigt.

4.10 Was sind die Ein- und Ausgabeschnittstellen der Anwendung?

Die Lösung von Lokad bietet eine Webschnittstelle – über HTTPS zugänglich – sowie Dateiprotokolle, nämlich SFTP und FTPS.

4.11 Wie stellen Sie sicher, dass es keine Datenlecks zwischen Mandanten gibt?

Die Lösung von Lokad trennt Mandantendaten bereits im Design, was sicherstellt, dass keine Datenlecks (nicht einmal versehentlich) auftreten. Darüber hinaus wird aller in Produktion überführte Code peer-reviewed, was eine zusätzliche Schutzebene bietet. Schließlich fordern wir Sicherheitsexperten (Personen, die Penetrationstests durchführen) dazu auf, die Möglichkeit von Datenlecks gezielt zu untersuchen. Wir gewähren ihnen Zugang zu mehreren Lokad-Konten – in einer dedizierten und vollständig isolierten Umgebung, die die Produktionsumgebung nachbildet – sodass sie diese Eigenschaft unserer Plattform gründlich prüfen können.

4.12 Kann die Lösung containerisiert werden?

Ja, allerdings bringt die Containerisierung der Lokad-Plattform kaum bis gar keinen Nutzen. Containerisierung ist dann von Vorteil, wenn komplexe Abhängigkeiten bestehen (z.B. eine transaktionale Datenbank, ein isoliertes Caching-System etc.). Wir verwenden Container weder in der Produktion noch in der Entwicklung, was unsere Sicherheit verbessert, indem ganze Klassen von Schwachstellen ausgeschlossen werden. Stattdessen halten wir die Lösung so einfach, dass die Bereitstellung auch mit kleinen Shell-Skripten durchgeführt werden kann.

4.13 Können die GUI-Komponenten vom Backend entkoppelt werden?

Ja, GUI-Komponenten (in diesem Fall Webschnittstellen) sind eigenständig. Dieses Design trägt zu einer höheren Verfügbarkeit bei. Endnutzer können auf ihre Lokad-Konto-Dashboards zugreifen, selbst wenn ein plötzlicher Ausfall eines der anderen Subsysteme auftritt.

4.14 Unterstützt die Lokad-Anwendung Lokalisierungsfunktionen (wie z.B. den Sprachwechsel)?

Ja, die Anwendung unterstützt Lokalisierungsfunktionen. Alle von der Lokad-Plattform erstellten Benutzeroberflächen können in jede Sprache lokalisiert werden. Insbesondere verwendet der gesamte technologische Stack UTF-8, um alle Zeichensätze, die über den lateinischen hinausgehen, zu unterstützen. Insbesondere kann jede von der Lokad-Plattform erstellte Benutzeroberfläche – nach der Bereitstellung – in eine andere Sprache re-localisiert werden.

4.15 Können Endnutzer nach der Bereitstellung der nachbearbeiteten Daten von Lokad neue Übersetzungen aktualisieren oder erstellen?

Ja, siehe 4.14 oben.

4.16 Verfügt Ihr System über eine integrierte Hilfe? Falls ja, in welcher Sprache(n)?

Ja, Lokad wird mit einer sehr umfangreichen öffentlichen Dokumentation (auf Englisch) geliefert. Allerdings erfordert die Nutzung der Lokad-Plattform die Erstellung maßgeschneiderter Benutzeroberflächen, und unser regulärer Prozess umfasst mindestens zwei Formen der Dokumentation bzw. Hilfe.

Erstens sind die innerhalb der Lokad-Lösung erstellten Dashboards als kontextuell dokumentiert vorgesehen – direkt über dem Dashboard selbst. Insbesondere haben wir sogar ein Markdown-Feld, das der Rich-Text-Dokumentation gewidmet ist. Zweitens beinhalten unsere Lieferungen ein “Joint Procedure Manual”. Insgesamt bietet das Handbuch eine detaillierte Analyse nicht nur der Mechanik der Lösung, sondern auch der Gründe, warum jedes Element ausgewählt wurde (und wie es die spezifischen supply chain Bedürfnisse des Kunden erfüllt).

4.17 Ist die Lokad-Webanwendung responsiv?

Die Lokad-Webanwendung sowie die zugehörigen Materialien (wie die technische Dokumentation) wurden so gestaltet, dass sie responsiv sind. Allerdings sind einige erweiterte Funktionen, wie das Bearbeiten von Code, für mobile und/oder Tablet-Geräte unpraktisch. Daher ist das Design darauf ausgelegt, die Reaktionsfähigkeit für die erwarteten Aktivitäten auf PCs bzw. kleineren Geräten zu maximieren.

4.18 Wenn Ihr System eine Webanwendung ist, welche Browser und Versionen unterstützen Sie? Was ist Ihr minimaler Internetbrowser-Standard?

Lokad ist eine Webanwendung und wir unterstützen die wichtigsten “evergreen” Webbrowser wie Chrome, Firefox und Safari. Wir versuchen nicht, ältere Browser aus Sicherheitsgründen zu unterstützen, da die Unterstützung dieser Browser unsere Kund(en) implizit gefährden würde. Einfach ausgedrückt kann ein anfälliger Browser von einem böswilligen Akteur ausgenutzt werden, um Daten zu exfiltrieren. Das heißt aber auch, dass wir bei neuen Browserfunktionen recht konservativ sind. Als Faustregel vermeiden wir es, Browserfunktionen zu unterstützen, die nicht von allen großen Webbrowsern seit mindestens 1 Jahr übernommen wurden.

4.19 Für mobile und Tablet-Anwendungen, welches Betriebssystem (und Versionen) unterstützt Lokad?

N/A. Da Lokad eine als SaaS bereitgestellte Webanwendung ist, sind unsere Kunden nicht an der Betriebssystemunterstützung interessiert. Intern wird Lokad unter Windows entwickelt, während unsere gesamte produktive Cloud-Hosting-Umgebung unter Linux betrieben wird. Daher sind wir von der umfassenden Portabilität der Lokad-Lösung überzeugt. Auch wenn wir derzeit keinen Änderungsbedarf in dieser Konfiguration sehen, werden wir uns anpassen, sollte stichhaltiger Anlass entstehen.

4.20 Kann die Lokad-Webanwendung Benachrichtigungen für Endnutzer bereitstellen? Falls ja, welche Technologie/Protokoll wird genutzt?

Ja, Lokad verfügt über die Möglichkeit, Benachrichtigungen über programmierbare HTTP-Hook-Benachrichtigungen zu versenden. Diese Hooks können genutzt werden, um ein Drittanbietersystem einzubinden, das häufig bereits im Kundenunternehmen vorhanden ist, um eine E-Mail-Benachrichtigung oder eine alternative Art von Benachrichtigungen zu versenden, die als angemessen erachtet werden. Die Hooks werden typischerweise auch verwendet, um die Verfügbarkeit von Daten anzuzeigen, die über SFTP oder FTPS von der Lokad-Plattform abgerufen werden können.

4.21 Gibt es gemeinsame Elemente in der Lösung, die allen Kunden gemeinsam sind (wie z.B. Monitoring-Funktionen, Backup- oder Patch-Management-Lösungen, etc.)?

Ja, da Lokad eine Multi-Tenant-Anwendung ist, werden die infrastrukturellen Fähigkeiten zwischen den Mandanten, d.h. Kundenkonten, geteilt. Dazu gehören das Monitoring der Betriebszeit, Leistung und aus Sicherheitsgründen auch Backup, Patch-Management, Upgrades usw.

4.22 Ermöglicht die Lösung eine Messaging-Funktionalität mit mehreren Empfängern (d.h. die Möglichkeit, eine Nachricht an mehr als einen Empfänger oder eine Anwendung zu senden)?

Die Lokad-Plattform arbeitet nicht mit Nachrichten. Allerdings bieten wir HTTP-Hook-Funktionalitäten, die genutzt werden können, um beliebig komplexe Nachrichtenbenachrichtigungen zu erzeugen, typischerweise über kostengünstige Drittanbietersysteme. Diese Benachrichtigungen werden manchmal von supply chain Teams verwendet, um den fristgerechten Abschluss von geschäftskritischen Berechnungsbatches mit der Lokad-Plattform zu überwachen.

4.23 Nutzen alle kritischen Systeme und Komponenten dieselbe Zeitquelle (NTP) oder synchronisieren sie ihre Uhren auf eine andere zuverlässige Weise?

Ja. Lokad verwendet den standardmäßigen NTP-Dienst, der mit Ubuntu geliefert wird – ntp.ubuntu.com. Genauer gesagt, wird ntpd als Zeitsynchronisationsdienst ausgeführt, der sich mit einer externen NTP-Zeitquelle synchronisiert, die über das Netzwerk erreichbar ist.

4.24 Gibt es eine Vermögensbestandsliste oder eine Konfigurationsmanagement-Datenbank (CMDB)?

Ja, wir verfügen über eine IT-Asset-Management-Software zur Unterstützung unserer Prozesse. Diese Plattform hilft uns, eine umfassende Vermögensbestandsliste zu führen und fungiert als unsere Konfigurationsmanagement-Datenbank (CMDB). Mit diesem System können wir Hardware- und Software-Assets innerhalb der Organisation effizient verfolgen, verwalten und zuweisen. Unsere Teams haben die Möglichkeit, den Status, den Standort und die Konfiguration jedes Assets schnell zu identifizieren, wodurch wir zügig auf Änderungen, Aktualisierungen oder potenzielle Probleme reagieren können.

Darüber hinaus bietet unser Tool Funktionalitäten, die ein detailliertes Lifecycle-Management ermöglichen, sodass Assets von der Beschaffung bis zum End-of-Life exakt katalogisiert werden. Automatisierte Prüfungsfunktionen, kombiniert mit detaillierten Berichtsfunktionen, gewährleisten, dass wir vollständige Transparenz und Kontrolle über unsere IT-Umgebung behalten, was die Einhaltung von Vorschriften und eine effiziente Ressourcenzuweisung erleichtert.

4.25 Wird jede Verbindung zu einem externen Netzwerk an einer Firewall beendet (z.B. dem Internet, Partnernetzwerke)?

Nein, wir beenden nicht jede Verbindung zu einem externen Netzwerk an einer Firewall, sei es das Internet oder Partnernetzwerke. Unsere Entscheidung beruht auf praxisbezogenen Bedenken hinsichtlich der Effektivität und Konsequenzen solcher Maßnahmen.

Aus unserer Sicht, obwohl Firewalls typischerweise als erste Verteidigungslinie angesehen werden, können sie ironischerweise die Angriffsfläche vergrößern. Je mehr Komponenten und Systeme wir integrieren, desto mehr potenzielle Schwachstellen entstehen. Aufgrund ihrer Natur laufen Firewalls als Prozesse mit hohen Privilegien, was bedeutet, dass sie Hauptziele für Cyberangriffe werden, und wenn sie kompromittiert werden, können die Folgen verheerend sein. Ein illustratives Beispiel ist der SolarWinds-Angriff, bei dem genau die Systeme, die eigentlich zum Schutz der Informationen dienen sollten, ausgenutzt wurden, was zu erheblichen Verstößen führte.

Zudem kann die Präsenz strenger Firewalls in der Praxis kontraproduktiv sein. Unsere Erfahrungen haben gezeigt, dass solche Systeme Mitarbeiter häufig dazu anregen, alternative Wege zu suchen, um auf Informationen zuzugreifen und diese zu teilen. Dies beinhaltet in der Regel, das Firmennetzwerk vollständig zu umgehen (und damit jegliches Monitoring zu verhindern) und persönliche 4G- oder 5G-Verbindungen von ihren eigenen Geräten zu nutzen. Solche Praktiken erhöhen unbeabsichtigt das Risiko von Sicherheitsverletzungen und Datenlecks.

Daher, obwohl wir uns der Sicherheit tief verpflichtet fühlen, ist unser Ansatz ganzheitlich und wird von praktischen Überlegungen geleitet, anstatt sich ausschließlich auf traditionelle Maßnahmen zu verlassen.

4.26 Verfügt das Netzwerk über eine DMZ-Umgebung, die kritische Systeme (wie Webserver, DNS, Verzeichnisdienste und Fernzugriff) sowie Kundendaten überträgt, verarbeitet oder speichert?

Nein, Lokad verwendet innerhalb unseres Netzwerks keine traditionelle DMZ-Umgebung zum Übertragen, Verarbeiten oder Speichern kritischer Systeme und Kundendaten. Stattdessen haben wir einen Zero-Trust-Ansatz für die Netzwerksicherheit eingeführt.

Dieses Modell beruht nicht auf DMZs, sondern folgt dem Prinzip “Nie vertrauen, immer überprüfen.” Jeder Zugriffsanfrage wird validiert und authentifiziert, unabhängig von deren Herkunft, sei es innerhalb oder außerhalb der Organisation.

Dies gewährleistet eine robustere und ganzheitlichere Sicherheitsstrategie, da sie nicht von Perimeter-Abwehrmechanismen wie einer DMZ abhängig ist, sondern sich darauf konzentriert, jeden einzelnen Zugangspunkt und jede Datenübertragung abzusichern. Wir sind der Ansicht, dass der Zero-Trust-Ansatz einen überlegenen Schutz für unsere kritischen Systeme und Kundendaten bietet.