FAQ: Informationstechnologie (IT)

Die Lokad-App ist eine Web-App, die als SaaS (Software as a Service) bereitgestellt wird. Der Zweck von Lokad besteht darin, prädiktive Analysen bereitzustellen, um die Supply Chain zu optimieren (bessere Bestände, bessere Preise usw.). Die Lokad-App ist als analytische Ebene konzipiert, die neben transaktionalen Systemen (ERP, WMS, CRM usw.) arbeitet. Sie wird mit einer monatlichen Abonnementpauschale geliefert, die in der Regel die App selbst mit professionellen Dienstleistungen bündelt. Diese professionellen Dienstleistungen, die von den Ingenieuren von Lokad (Supply Chain Scientists) erbracht werden, verringern nahezu vollständig den Bedarf an technischem Support seitens der IT-Abteilung für diesen Bereich. Der einzige wesentliche Beitrag, der von der IT-Abteilung erwartet wird, besteht darin, eine Datenpipeline einzurichten, die Flatfiles (per SFTP oder FTPS) an Lokad sendet und möglicherweise die generierten Ergebnisse wieder integriert.

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

Technischer Überblick

Die Lokad-App ist mandantenfähig. Jeder Mandant (d. h. Kundenkonto) verfügt über sein eigenes dediziertes Dateisystem und sein eigenes dediziertes Code-Repository. Das Dateisystem ist über FTPS, SFTP und eine Web-Schnittstelle zugänglich. Dieses Dateisystem ist auf große Flatfiles (bis zu 100 GB pro Datei) ausgerichtet und verfügt über eine Datenversionsverwaltung (wie Git). Das Code-Repository wird verwendet, um Envision-Skripte zu hosten. Envision ist eine proprietäre DSL (Domain Specific Programming Language), die von Lokad entwickelt wurde. Diese DSL ist stark auf prädiktive Optimierungsfälle spezialisiert. Envision-Skripte werden verwendet, um die Kernnumerikanalysen durchzuführen (einschließlich maschineller Lernalgorithmen, Solver usw.) und datenreiche Dashboards zu generieren.

Die App wird jeden Dienstag zwischen 10:00 und 14:00 Uhr (Pariser Zeit) vollständig neu bereitgestellt. Die Ausfallzeit beträgt in der Regel weniger als 5 Minuten. Lokad übernimmt die vollständige Verantwortung für alle Versionsprobleme.

Von der IT-Abteilung wird nicht erwartet, dass sie jemals über spezifische Kompetenzen im Bereich des Lokad-Stacks verfügt. Wenn Sie jedoch neugierig sind, gibt es eine vollständige technische Dokumentation.

Beitrag der IT-Abteilung

Wir erwarten von der IT-Abteilung, dass sie eine Datenpipeline einrichtet, die eine kurze Reihe relevanter Flatfile-Extraktionen per SFTP oder FTPS nach Lokad sendet. Die Extraktionen werden über die Transaktionssysteme (z. B. ERP) durchgeführt. Wir haben eine starke Präferenz für Rohdaten-Tabellenextraktionen (kein Filter, kein Join, keine Transformation), was einen minimalen Aufwand erfordert. Aus ETL-Sicht benötigen wir nur den “E” (Extrakt)-Teil in seiner einfachsten Form (einfache Kopie). In Bezug auf das Format ist Lokad mit jedem vernünftig tabellarischen Flatfile kompatibel.

Die Datenpipeline soll mindestens täglich und vollständig automatisiert ausgeführt werden. Der Arbeitsaufwand für die IT-Abteilung hängt vom Umfang der Datenextraktion ab (welche Systeme? welche Tabellen?). Als Faustregel gilt jedoch, dass die Einrichtung der Datenpipeline in der Regel etwa 15 bis 45 Mann-Tagen 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 in der Regel mit 1 oder 2 Mann-Tagen pro Monat erledigt wird.

Sicherheitsüberblick

Die App wird in Microsoft Azure-Rechenzentren in der EU gehostet. Wir verarbeiten keine personenbezogenen Daten, da wir solche Daten nicht zur Durchführung benötigen. Bei der Festlegung des Umfangs der Datenextraktion schließen wir alle Spalten oder Felder aus, die personenbezogene Daten enthalten würden.

Bei der Authentifizierung bevorzugen wir SAML. Wir empfehlen dringend, dass Benutzer auf Lokad über eine föderierte Identität wie Azure Active Directory, Office 365 oder Google Workspace zugreifen. Dadurch werden alle mit Passwörtern verbundenen Probleme beseitigt.

Auf Anfrage können Sicherheitsaudits und Penetrationstests von unseren Kunden durchgeführt werden. Die Details hängen von den vereinbarten Vereinbarungen ab.

Weitere Informationen finden Sie unter Sicherheit bei Lokad.

Zeitplanüberblick

Die Quantitative Supply Chain ist eher eine Reise als ein Selbstzweck. Gleichzeitig erfordert die Supply Chain-Führung, die ihr Unternehmen in eine Quantitative Supply Chain-Initiative einbezieht, Transparenz in Bezug auf den Projektzeitplan. Während positive Ergebnisse in ein paar Monaten erzielt werden können, dauert es häufig bis zu zwei Jahre, um das volle Potenzial der Quantitativen Supply Chain freizusetzen. Im folgenden Abschnitt geben wir einen Überblick über einen typischen Zeitplan, der mit einer Quantitativen Supply Chain-Initiative für ein mittelständisches Unternehmen verbunden ist. Bei großen Unternehmen sollte mit doppelt so langen Zeitplänen gerechnet werden.

Projektstart: Vertreter beider Parteien stellen sich einander vor und vereinbaren wöchentliche Meetings. Diese wöchentlichen Meetings dauern bis zur Erreichung der Produktionsphase an. Der Supply Chain-Wissenschaftler stellt die verschiedenen Phasen der Implementierung und die verschiedenen Liefergegenstände vor, die vom Kunden erwartet werden können. Der Rest des Anrufs dient der Überprüfung verschiedener Supply Chain-Details und IT-Charakteristika der Integration. Nach dem Anruf wird eine Zusammenfassung erstellt, in der die organisatorischen Aspekte des Projekts dokumentiert sind, und an den Kunden gesendet.

Datenanforderungen: Kurz nach dem Kickoff-Meeting erstellt der Supply Chain-Wissenschaftler die für die Umsetzung des Projekts erforderlichen Datenanforderungen. Diese Anforderungen werden gemeinsam mit dem Kunden überprüft und validiert. Insbesondere soll dieses Dokument die aus den IT-Systemen des Kunden zu extrahierenden Daten definieren. Als Faustregel sollte die Extraktion so nah wie möglich an den Originaldaten bleiben, wie sie in den IT-Systemen des Kunden vorhanden sind.

1. Datenupload: Nach Validierung der Spezifikationen lädt der Kunde den ersten Datensatz auf die Server von Lokad hoch. In der Regel erfolgt der Upload zu diesem Zeitpunkt noch nicht über einen automatisierten Prozess, da in der Regel mehrere Versuche erforderlich sind, um einen Konsens über die Feinheiten der Datenanforderungen zu erzielen.

Validierung der Daten: Der Supply Chain-Wissenschaftler führt eine gründliche Untersuchung des Datensatzinhalts des Kunden durch. Insbesondere werden Plausibilitätsprüfungen eingeführt, um die Qualität der Daten nach mehreren Metriken zu überwachen. Ziel ist es 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 für die Zwecke der Supply Chain-Optimierung kohärent und ausreichend vollständig ist.

In Bezug auf die Liefergegenstände stellt der Supply Chain-Wissenschaftler dem Kunden während dieser Phase verschiedene Dashboards zur Verfügung, die die Gesundheit der Daten bewerten. Diese Dashboards können vom Kunden sogar für Zwecke verwendet werden, die über die Quantitative Supply Chain-Initiative selbst hinausgehen - beispielsweise als Teil ihres internen Prozesses zur Gewährleistung der Datenqualität.

Audit in der Mitte des Projekts: 6 Wochen nach dem ersten Kickoff wird ein Treffen vereinbart, um den Status der Projektfertigstellung zu bewerten. Ziel dieses “Audits” ist es, Probleme, die während der Implementierung auftreten können, insbesondere solche, die die Produktionsphase verzögern könnten, so früh wie möglich anzugehen. Bei Lokad besteht dieses “Audit” aus einem Austausch zwischen dem Supply Chain-Wissenschaftler und dem Kunden, basierend auf einer Checkliste, die dem Kunden vom Supply Chain-Wissenschaftler unmittelbar nach dem Kickoff-Meeting übermittelt wird.

Automatisierung des Uploads: Sobald beide Parteien die Gesamtqualität des bisher hochgeladenen Datensatzes validieren, implementiert der Kunde einen automatisierten Prozess, der ihren Datensatz regelmäßig - idealerweise täglich - an Lokad überträgt. Gleichzeitig wird auf der Seite von Lokad die Datenqualitätslogik - mit ihren mehrfachen Überprüfungen - geplant, um nach jedem Upload aktualisiert zu werden.

Einrichtung der Optimierung: Ab diesem Zeitpunkt verfügt der Supply Chain-Wissenschaftler über alle notwendigen Voraussetzungen, um die Optimierung der zuvor mit dem Kunden vereinbarten Entscheidungen umzusetzen. Daher implementiert er Skripte, um verschiedene quantitative Ausgaben zu generieren: operative Einkaufsvorschläge, Versandvorschläge usw. 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 Ausgaben in irgendeiner Weise zu ändern oder anzupassen, führen in der Regel zu einer Feinabstimmung der Skripte, die vom Supply Chain-Wissenschaftler geschrieben wurden. Es gibt viele Parameter und Methoden, die übernommen werden können, um die Merkmale der optimierten Supply Chain angemessen an die Optimierungslogik anzupassen. Wenn die Methodik selbst für den Kunden von strategischer Bedeutung ist, wird dies explizit zwischen dem Kunden und dem Supply Chain-Wissenschaftler besprochen.

Produktion: Nach mehreren Runden der Feinabstimmung und Überarbeitung erreicht der Kunde einen Punkt, an dem er dem von dem Supply Chain-Wissenschaftler implementierten Logik vertraut. Zu diesem Zeitpunkt kann der Kunde den Service in der Produktion nutzen, d.h. er kann die ursprünglich von der Software berechneten Supply Chain-Entscheidungen direkt ausführen. Wenn der Kunde bestätigt, dass die Lösung produktionsbereit ist, liefert der Supply Chain-Wissenschaftler eine Dokumentation, die die Wartbarkeit der Lösung gewährleistet.

Support & Wartung: Die Lösung ist betriebsbereit und wird vom Kunden genutzt, während der Supply Chain-Wissenschaftler die reibungslose tägliche Ausführung der Datenpipeline überwacht. Regelmäßig werden Anrufe zwischen dem Kunden und dem Supply Chain-Wissenschaftler organisiert, um sicherzustellen, dass die Optimierung den erwarteten Grad an Supply Chain-Leistung liefert. Darüber hinaus sind Supply Chains nicht statisch, daher müssen Geschäfts- oder IT-Änderungen, klein oder groß, überprüft werden: ein neues Lager, Verschiebung des Marktes, neuer Prozess usw. Der Supply Chain-Wissenschaftler schlägt geeignete Änderungen vor, um diese verschiedenen Änderungen anzupassen. Checkpoint-Anrufe werden mit einer vereinbarten Frequenz geplant, in der Regel monatlich.

Häufig gestellte Fragen (FAQ)

1. Release-Management

1.1 Wie funktionieren Releases bei Lokad?

Lokad kümmert sich intern um alle Releases, um eine vollständige Transparenz für Kunden zu gewährleisten. Alle Releases, die sich auf einen Kunden auswirken könnten, werden im Voraus mit ihnen - über die technischen Teams des Kunden - koordiniert. Im Allgemeinen verfolgt Lokad einen vorsichtigen Ansatz bei Releases: Wenn ein geplantes Release nicht ausreichend Vorbereitungszeit für einen Kunden bietet, wird das Release vorübergehend verschoben.

Lokads Releases sind sehr granular, und das Design ermöglicht es dem Kunden in der Regel, ein bestimmtes technisches Element eines Gesamt-Releases abzulehnen. Wenn wir also die Implementierung eines Elements verschieben müssen, für das unser Kunde noch nicht bereit ist, kann das Gesamt-Release dennoch stattfinden (und die anderen nicht betroffenen Elemente implementieren).

1.2 Wie häufig sind die Releases?

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

1.3 Bieten Sie einen Plan der bevorstehenden Releases an?

Ja, siehe Release Management 1.2.

1.4 Erfordert eine Versionsänderung eine Neuinstallation oder nur einen Patch?

Lokad implementiert seine eigene Lösung durch automatisierte Mittel (Skripte) neu. Wir patchen keine Systeme in der Produktion. Wenn wir einen “Sicherheitspatch” bereitstellen müssen, implementieren wir die Lösung durch unsere üblichen automatisierten Mittel neu.

1.5 Wie lange dauert es, ein größeres Release anzuwenden?

Der automatisierte Prozess dauert etwa 1 Stunde. Es gibt eine schrittweise Einführung (Maschine für Maschine), da wir beabsichtigen, die Plattform von Lokad während des Releases betriebsbereit und zugänglich zu halten. Die Betriebsfähigkeit während einer Einführung 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 während des Releases eine Ausfallzeit?

Meistens nicht, aber bedenken Sie, dass Lokads Lösung ein verteiltes System ist, das für Berechnungen im großen Maßstab entwickelt wurde. Daher unterscheidet sich der Einfluss eines Releases zwischen den Front- und Back-End-Systemen. Subsysteme, die dem Kunden zugewandt sind, wie die Dashboards, sind für eine unterbrechungsfreie Nutzung konzipiert. Back-End-Systeme, wie diejenigen, die für die Ausführung von Stapelaufträgen zuständig sind, können für einige Minuten angehalten werden (zumindest für einige Aufträge). Diese Stapelaufträge können jedoch geplant werden, sodass eine proaktive Planung die Fertigstellung der Stapelaufträge außerhalb des Release-Zeitrahmens ermöglichen sollte.

1.8 Was ist Ihr Testprozess oder Ihre Teststrategie für ein Release?

Lokad verwendet automatisierte Prozesse, die dem Testen und der Sicherstellung der Korrektheit eines bevorstehenden Releases gewidmet sind. Diese Prozesse umfassen umfangreiche Suites von automatisierten Tests (gemessen in Tausenden); Unit-Tests, Funktionstests, Leistungstests, usw. Wir haben auch spezielle Tools entwickelt, mit denen wir ganze Sequenzen vergangener Jobausführungen innerhalb der Lokad-Plattform reproduzieren können. Mit diesen Tools können wir überprüfen, ob Envision-Skripte vor/nach einem bevorstehenden Release das gleiche Verhalten aufweisen. Darüber hinaus können wir überprüfen, ob die Leistungsprofile vorhandener Skripte den Erwartungen des Zeitplans entsprechen, wie sie von unseren Kunden definiert wurden.

1.9 Haben Sie mehrere Umgebungen?

Ja, jedoch sind die alternativen Umgebungen (auf Plattformebene, neben der Produktionsumgebung) in der Regel nicht für unsere Kunden vorgesehen. Neben der Produktionsumgebung und den vorübergehenden Entwicklungsumgebungen haben wir eine “evergreen” Umgebung, die der letzten stabilen Version unseres Codebases entspricht. Dies validiert einen bestimmten Teil unserer automatisierten Testprozesse. Unsere Kunden können Zugang zu unserer “evergreen” Umgebung erhalten, um zu überprüfen, ob ein bestimmtes bevorstehendes Release wie erwartet funktioniert. Diese Situation kann auftreten, wenn es eine IT-Integration zwischen Lokad und dem Kunden gibt. In der Praxis ist diese Situation selten.

Wenn das Ziel darin besteht, mehrere Varianten von Envision-Skripten nebeneinander ausführen zu können, kann ein Lokad-Konto in mehrere “Umgebungen” unterteilt werden. Wenn das Ziel darin besteht, jede Art von Test durchzuführen, kann ein zweites Lokad-Konto für vorübergehende Testzwecke bereitgestellt werden. Dieser zweite Ansatz hält das primäre Kundenkonto (für die Produktion verwendet) von diesen Tests isoliert.

1.10 Wie viele verschiedene Versionen können nebeneinander existieren?

Lokad ist ein Multi-Tenant-SaaS, das für alle seine Kunden dieselbe eindeutige Version ausführt. Lokad hat jedoch die Möglichkeit, so viele verschiedene Versionen zu betreiben, wie vom Kunden gewünscht.

1.11 Kann ein Kunde ein Release ablehnen?

Da Lokad ein Multi-Tenant-SaaS ist, das für alle Kunden dieselbe eindeutige Version ausführt, ist es nicht möglich, ein Release abzulehnen. 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 Situationen, in denen ein Release vorübergehend verschoben werden kann, siehe Release Management 1.1.

1.12 Haben Sie Release-Notizen? Stellen Sie sie Ihren Kunden zur Verfügung?

Ja. Diese Notizen werden intern (mit unseren Supply Chain Scientist-Teams) geteilt. Wenn dies explizit als Teil eines Vertrags vereinbart wurde, können diese Release-Notizen einem Kunden zugänglich gemacht werden. In der Praxis sind die Release-Notizen der Lokad-Plattform jedoch nur für Personen von Interesse, die mit Envision-Code arbeiten.

1.13 Wie kann ein Kunde eine Weiterentwicklung der Lösung anfordern?

Die meisten unserer Kunden profitieren von einem “Software + Expert” -Angebot, bei dem ein Team von Supply Chain Scientists von Lokad für die Implementierung und Wartung der Supply Chain-Lösung eines Kunden verantwortlich ist. Diese Situationen werden als “Supply Chain as a Service” bezeichnet. In diesen Vereinbarungen interagiert der Kunde regelmäßig mit einem oder mehreren Supply Chain Scientists. Die meisten Kunden profitieren auch von einem wöchentlichen oder monatlichen Lenkungsausschuss, um den aktuellen Stand der Lösung und gewünschte Weiterentwicklungen zu besprechen. Lokad verwendet diese Methode, um alle Weiterentwicklungsanfragen zu sammeln und einen Fahrplan für die Implementierung von Änderungen vorzuschlagen.

1.14 Ist es möglich, den Anwendungs-Webdienst zu verwalten und seine Parameter zu konfigurieren?

Ja, in dem Sinne, dass die Lokad-Plattform von Natur aus programmatisch ist. Die “analytische” Logik von Lokad erfolgt in Form von Envision-Skripten - Envision ist die von Lokad entwickelte DSL (Domänenspezifische Sprache) für die prädiktive Optimierung der Supply Chain.

Somit ist in gewisser Weise jede einzelne Parameterkonfiguration verfügbar, indem Envision-Skripte im Konto genutzt werden.

2. Leistung

2.1 Deckt Ihre SLA (Service Level Agreement) eine Verfügbarkeit von 99.xy% ab?

Ja. Die SLA ist Teil unserer standardmäßigen Vertragsvereinbarung. Die Vorstellung von Verfügbarkeit im Kontext eines verteilten Computersystems, das der prädiktiven Optimierung von Supply Chains gewidmet ist, ist jedoch komplex. Betrachten Sie die folgenden Szenarien: - Lokad erhält Kundendaten (einen täglichen Schritt) 2 Stunden später als geplant. Dies kann die ordnungsgemäße Effizienz unserer Ressourcenzuweisungsheuristiken beeinträchtigen. Dadurch kann die Zeit, die für die Ausführung von Lokads Batch-Jobs benötigt wird, verlängert werden (z. B. 75 Minuten anstelle der üblichen 60). Einige mögen dies als 15-minütige Ausfallzeit betrachten, aber das liegt außerhalb unserer Kontrolle.

• Lokad erhält die gleichen Kundendaten rechtzeitig, aber die Daten weisen einen erheblichen Rückgang der Lagerbestände auf. Dies würde eine Unterbrechung der Batch-Jobs (auf Seiten von Lokad) auslösen und einen Supply Chain Scientist alarmieren, um das Problem zu untersuchen. Der Supply Chain Scientist stellt fest, dass eine automatisierte Nachbestellung ungewöhnlich groß ist. Der Supply Chain Scientist entscheidet, dass eine direkte Bewertung durch den Kunden erforderlich ist. Am nächsten Tag bestätigt der Kunde, dass die Lagerdaten beschädigt waren und zu einem großen Lagerverlust geführt hätten. Einige mögen dies als 24-stündige Ausfallzeit betrachten, aber das scheint in diesem Kontext praktisch unsinnig.

Die größte Gefahr für eine Supply Chain-Optimierungslösung besteht nicht darin, ein wenig zu spät zu sein, sondern darin, sehr falsch zu sein. Sobald eine Supply Chain-Entscheidung getroffen wurde, wie z. B. das (falsche) Auslösen einer Produktionscharge, kann deren Rückgängigmachung äußerst kostspielig sein. Wir ermutigen unsere Kunden, sich nicht willkürlich an Indikatoren in Isolation zu binden, da diese Einstellung dazu führen kann, dass Menschen insgesamt minderwertige Arbeit leisten, solange sie einen KPI (wie x.y% Verfügbarkeit) zu erfüllen scheint.

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

Ja, unter 500 ms, aber mit Einschränkungen.

Wir haben das, was im Wesentlichen “Konstantzeit-Dashboards” entspricht, entworfen. Unter der Haube erfordert die Anzeige eines Dashboards eine einzige Anfrage über das Netzwerk, und in unserem Backend kollidieren wir alle Dashboard-Daten, um die Anzahl der Netzwerkanfragen niedrig zu halten (normalerweise im einstelligen Bereich gemessen). Diese Designentscheidung trägt wesentlich dazu bei, die geringe Latenz der typischen Benutzeranfrage bei der Anzeige eines Dashboards “zu garantieren”. Diese Designentscheidung verhindert auch, dass das Dashboard mit Kacheln überfüllt wird - von denen jede Netzwerkanfragen erfordern würde - und die gesamte Benutzererfahrung verlangsamt.

In Bezug auf die Dauer von Batch-Jobs können wir über Envision Garantien - zur Kompilierzeit - für den Abschluss eines Batch-Jobs geben. Wir können auch weitgehend reproduzierbare Abschlusszeiten für unsere Batch-Jobs garantieren. Diese Garantien werden durch statische Analyse und sorgfältiges Design der Envision-Sprache erzielt - die bestimmte Klassen von statischen Analysen überhaupt erst möglich macht. Dieser Ansatz hat Grenzen, ist aber weitaus besser als Designs, die überhaupt keine Garantien bieten.

Die End-to-End-Latenz liegt jedoch nicht vollständig in unserer Hand. Wir haben zum Beispiel keine Kontrolle über die Qualität der Internetverbindung, die von unseren Kunden verwendet wird. Eine große Tabelle von Lokad dauert lange, um über ein Netzwerk mit geringer Bandbreite heruntergeladen zu werden.

2.3 Haben Sie Systemleistungsüberwachungsprotokolle?

Ja. Wir sammeln sehr detaillierte Leistungsprotokolle für alle beteiligten Rechenressourcen: CPU, Speicher, Speicherplatz, Bandbreite usw. Diese Leistungsprotokolle werden unter anderem verwendet, um sicherzustellen, dass eine neue, noch nicht veröffentlichte Version der Plattform unseren Erwartungen in Bezug auf Leistung entspricht. Wir testen dies, indem wir die Leistung der neuen Version mit der Leistung früherer Versionen vergleichen, wie sie in diesen Protokollen dokumentiert ist.

2.4 Ist es möglich, langsame Antworten oder Überlastungen zu überwachen?

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

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

2.5 Haben Sie Lastenausgleicher?

Ja. Die Lastenausgleicher von Lokad sind in erster Linie für die Zuverlässigkeit und nicht für die Leistung gedacht. Das Lastenausgleich auf Netzwerkebene erfolgt über die Netzwerkschicht der von uns verwendeten Cloud-Computing-Plattform (Microsoft Azure). Die Verteilung der internen Datenverarbeitungsworkload, die von der Lokad-Plattform gehandhabt wird, erfolgt jedoch nicht über Lastenausgleicher, sondern über einen firmeninternen Orchestrator, der mit unserem Compiler-Stack verbunden ist.

2.6 Poolen Sie Ressourcen wie DB-Verbindungen, Sitzungen usw.?

Ja. Die Lokad-Plattform verlässt sich jedoch nicht auf eine transaktionale Datenbank, um zu funktionieren. Daher gibt es keine DB-Verbindungen, die gepoolt werden müssen. Dennoch poolen wir viele andere Ressourcen, wann immer es aus Leistungssicht sinnvoll ist.

2.7 Unterstützen Sie parallele Verarbeitung?

Ja. Envision (unsere DSL) ist um das Konzept der automatischen parallelisierten Ausführung herum konzipiert. Die Lokad-Plattform nutzt aktiv Parallelisierung auf mehreren Ebenen: auf der CPU-Kernebene durch SIMD (Single Instruction/Multiple Data)-Operationen; auf der CPU-Ebene durch mehrfädige Ausführungen; und auf der Cluster-Ebene durch verteiltes Computing. Da parallele Verarbeitung ein grundlegendes Designmerkmal von Envision ist, profitieren nahezu alle Workloads, die auf der Lokad-Plattform ausgeführt werden, standardmäßig und ohne besondere Anstrengungen für unsere Kunden oder unsere Supply Chain Scientists von umfangreicher Parallelisierung.

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

Ja. Das Caching wird jedoch häufig als Workaround eingeführt, um mit den Leistungseinschränkungen transaktionaler Datenbanken umzugehen. Da die Lokad-Plattform keine transaktionalen Datenbanken enthält, verwenden wir kein Caching für diesen Zweck.

2.9 Komprimieren Sie Daten, um den Netzwerkverkehr zu reduzieren?

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

1. Eine Antwort wird komprimiert.

2. Eine Antwort enthält ein Geheimnis.

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

Um sich gegen BREACH zu verteidigen, deaktiviert Lokad die Komprimierung bei allen Antworten, bei denen die dritte Bedingung zutrifft. Wir komprimieren Daten auch aus Gründen, die über die Reduzierung des Netzwerkverkehrs hinausgehen: erstens, um die Kosten für die Datenspeicherung zu reduzieren, und zweitens, um die Berechnungsverzögerungen zu verringern.

2.10 Führen Sie Leistungstests durch?

Ja. Lokad verfügt über eine umfangreiche automatisierte leistungsorientierte Instrumentierungsschicht. Diese Reihe von Tools ermöglicht es uns, vor jeder Veröffentlichung die Leistungsänderung der kommenden Version im Vergleich zur mit derzeit bereitgestellten Version zu bewerten. Mit diesem Tool können wir dieselben Workloads reproduzieren, wie sie in der Produktion beobachtet werden, und die resultierende Leistung überwachen; nicht nur in der Wanduhrzeit, sondern unter Berücksichtigung aller relevanten Rechenressourcen (Speicher, Bandbreite, E/A, CPU usw.).

2.11 Überwachen Sie die Leistung auf Transaktionsebene?

Ja. Da die Lokad-Plattform jedoch keine transaktionale Datenbank verwendet, gibt es keine “Transaktionen”, die überwacht werden müssen (im herkömmlichen Sinne). Das nächstgelegene Äquivalent ist die Ausführung von Envision-Skripten. Für diese Skripte überwachen wir die Leistung auf einer sehr granularen Ebene, die in etwa dem Überwachen des Kleingedruckten der Abfrageplan-Ausführung (aus Sicht einer transaktionalen Datenbank) entspricht.

Weitere Informationen zu “Transaktionen” in der Lokad-Lösung finden Sie in unserer Sicherheitsdokumentation unter Autorisierung 3.6 und Protokollierung und Überwachung 5.3.

2.12 Welche Auswirkungen hat die gleichzeitige Nutzung durch Benutzer auf die Leistung der Lösung?

Nahezu keine. Das Design von Lokad stellt sicher, dass Dashboards auch für eine große Anzahl von Benutzern (nach B2B-Standards) in konstanter Zeit bedient werden können. Dieser Ansatz steht im starken Gegensatz zu vielen alternativen Architekturen, insbesondere transaktionalen Datenbanken und Business Intelligence Cubes.

Da jedoch jeder einzelne Benutzer (bei Vorhandensein entsprechender Systemrechte) beliebig große Workloads auslösen könnte, ist die Anzahl der gleichzeitigen Benutzer höchstens von sekundärer Bedeutung für die Leistung der Lösung. Was die vorhersagbare Optimierung der Supply Chain betrifft, so machen die Batch-Jobs, die zur Durchführung der interessierenden Analysen verwendet werden, mehr als 99% der Workload aus. Die weniger als 1% Rest entfallen auf die Bedienung von Benutzeranfragen.

2.13 Ist das System für vertikale und horizontale Skalierung ausgelegt?

Ja. Aus unserer Sicht ergänzen sich vertikale und horizontale Skalierung, und das Design der Lokad-Plattform nutzt beides. Der interne Orchestrator - der für die Parallelisierung zuständig ist - beginnt in der Regel mit der vertikalen Skalierung, da die vertikale Skalierung die Datenkollokation weitgehend erleichtert. Anschließend nutzt der Orchestrator die horizontale Skalierung, wenn der Workload groß genug ist, um von der Ausführung auf mehreren Maschinen zu profitieren.

2.14 Skalieren sich Compute- und Speicherressourcen automatisch bei Bedarf?

Ja. Die Lokad-Plattform ist mandantenfähig. Durch die Mandantenfähigkeit führen wir skalierbare Zuweisungen von Compute-Ressourcen in großem Maßstab und mit geringer Latenz durch. Das bedeutet, dass das von Lokad bereitgestellte Compute-Auto-Scaling um Größenordnungen schneller ist als das Starten großer VMs (Virtual Machines) bei einem Cloud-Computing-Anbieter. Das Auto-Scaling des Speichers wird weitgehend durch die Nutzung der Auto-Scaling-Eigenschaften des persistenten Key-Value-Stores durchgeführt, wie sie von der zugrunde liegenden Cloud-Computing-Plattform (Microsoft Azure) bereitgestellt werden.

2.15 Wie erfüllt Ihre Anwendung die Anforderungen an “Big Data”?

Die Lokad-Plattform wurde speziell für die Verarbeitung von “Big Data” entwickelt. Stand Januar 2023 verwaltet die gesamte Lokad-Plattform etwa 1 Petabyte an Daten in unserer gesamten Kundenbasis. Unsere Plattform kann einzelne Dateien von bis zu 100 GB verarbeiten, und wir verarbeiten routinemäßig Tabellen mit mehreren Milliarden Zeilen. Weitere Informationen zur Sicherheit von Lokad 4.10

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

2.16 Kann die cloudbasierte Lösung von Lokad angesichts enger Bandbreiten- und Latenzbeschränkungen (auf der Client-Seite) konfiguriert werden? Zum Beispiel: Bandbreite = 3 Mbps (Download) / 1 Mbps (Upload), Latenz = 600-800 ms

Ja, die von Lokad entwickelte Webanwendung wurde so konzipiert, dass sie Szenarien unterstützen kann, in denen die Konnektivität “schlecht” ist (sowohl in Bezug auf die Bandbreite als auch auf die Latenz). Diese Anliegen werden hauptsächlich durch grundlegende technologische Designentscheidungen angegangen. Diese architektonischen Designentscheidungen unterscheiden Lokad auch von der Mainstream-Konkurrenz. Bandbreitenprobleme werden auf zwei Arten angegangen. Erstens sind wir sparsam, wenn es um JavaScript-Komponenten von Drittanbietern geht. Wir haben weniger als 1 MB an Assets, die zu Beginn abgerufen werden müssen. Zweitens bietet die Plattform vollständige Kontrolle über die Menge der Daten, die in ein einzelnes Dashboard aufgenommen werden sollen. Wenn die Konnektivität schlecht ist, ist es möglich, das Dashboard entsprechend “leicht” zu gestalten. In Bezug auf Latenzprobleme wurden unsere Dashboards so entwickelt, dass alle relevanten Dashboard-Daten in einer einzigen HTTP-Anfrage verpackt sind. Dadurch wird die Reibung für Endbenutzer mit geringer Latenz minimiert.

2.17 Wie hoch sind die durchschnittlichen und Spitzen-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 werden Interaktionen mit der Lokad-Plattform nicht über Nachrichten durchgeführt. Die Durchsatzrate ist jedoch wichtig, um umfangreiche Datensätze mit Transaktionsdaten schnell 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 Berechnungsbatches.

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

2.18 Welche Größe von Nachrichten kann die Lösung verarbeiten? Bitte geben Sie Details zu den minimalen, maximalen und durchschnittlichen Werten an.

Die Lokad-Plattform arbeitet nicht mit Nachrichten. Das Ähnlichste wären “Flatfiles”. Diese Flatfiles können an Lokad gesendet und von dort abgerufen werden. Die Lokad-Plattform kann Dateien verarbeiten, die einzeln bis zu 100 GB groß sind. Dies ist jedoch keine empfohlene Praxis, da es in der Regel etwas umständlich ist (nicht für Lokad, sondern für die Kunden, die sich mit externen Tools vertraut machen müssen, um die großen Dateien zu erstellen und zu verarbeiten).

3. Vorfälle

3.1 Wie meldet ein Kunde einen Vorfall?

Die meisten unserer Kunden profitieren von einem Paket, das den Zugang zu unserem Team von Supply Chain Scientists beinhaltet. Diese Supply Chain Scientists sind der erste Ansprechpartner für die Meldung von Vorfällen. Im Falle eines Vorfalls empfehlen wir den Kunden entweder, ihren Supply Chain Scientist direkt anzurufen - wenn das Problem dringend ist - oder eine E-Mail zu senden. Die Supply Chain Scientists kümmern sich um das Incident Management, einschließlich etwaiger Eskalationen innerhalb der Organisation von Lokad.

3.2 Bieten Sie ein Ticketing-System an?

Ja. Lokad nutzt ein Ticketing-System von Drittanbietern. Ab Januar 2023 haben wir jedoch begonnen, eine interne Lösung zu entwickeln, die eine enge Integration mit dem Rest unserer Plattform bietet.

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

Ja, im Rahmen einer dedizierten vertraglichen Vereinbarung.

Im Kontext der vorhersagenden Supply Chain-Optimierung können “Vorfälle” variieren und schwer zu definieren sein. Im Allgemeinen betrachten unsere Kunden geringfügige Ereignisse auf Plattformebene (wie kurze Ausfallzeiten) nicht als “Vorfälle”. Bessere Kandidaten wären tatsächliche Besonderheiten in der Supply Chain, die möglicherweise Probleme mit in den Kundenaccount implementierten Envision-Skripten widerspiegeln oder auch nicht. Externe IT-Abteilungen sind selten in die Lösung dieser Vorfälle involviert.

3.4 Wie stellen Sie eine hohe Verfügbarkeit sicher?

Lokad wurde bereits 2010 zum Vorreiter bei Cloud-Computing-Plattformen, um eine höhere Verfügbarkeit zu gewährleisten. Neben der Redundanz der Infrastruktur (siehe Incidents 3.5) legt das Design von Lokads Lösung großen Wert auf Einfachheit. Im Gegensatz zu vergleichbaren Unternehmenssoftwarelösungen haben wir deutlich weniger komplexe Abhängigkeiten (um fast eine Größenordnung). Eine enorme Komplexitätsschicht, die in unserer Lösung fehlt, ist eine transaktionale Datenbank. Durch weniger bewegliche Teile haben wir weit weniger Ausfallmodi, was uns hilft, eine hohe Verfügbarkeit für unsere Kunden (die sich über mehrere Zeitzonen erstrecken) aufrechtzuerhalten.

3.5 Haben Sie eine redundante Infrastruktur (falls ja, wie)? Vermeiden Sie Single Points of Failure?

Ja. Unsere kritischen Systeme sind redundant, um Single Points of Failure zu vermeiden. Redundante Systeme umfassen 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 Verfügbarkeit während des Rollouts zu gewährleisten.

3.6 Wie stellen Sie die Wiederherstellung nach Hardwareausfällen sicher?

Die Wiederherstellung nach den meisten Hardwareausfällen wird transparent von der Cloud-Computing-Plattform durchgeführt, die Lokad verwendet. Die eingebaute Redundanz der Lokad-Plattform stellt sicher, dass vorübergehende Hardwareausfälle die Verfügbarkeit nicht beeinträchtigen, während die Cloud-Computing-Plattform eine neue fehlerfreie Ressource zuteilt. Für die persistente Datenspeicherung nutzt Lokad nur Dienste (d. h. Key-Value-Stores), die selbst durch ihre eigenen Redundanzschichten vor Hardwareausfällen geschützt sind.

3.7 Haben Sie ein Backup?

Ja. Wir haben eine Backup-Umgebung, die für schwerwiegende Szenarien zur Wiederherstellung nach einem Desaster (über einen Ausfall auf Rechenzentrumsebene 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 aus der Backup-Umgebung lesen noch in diese schreiben kann.

3.8 Haben Sie einen Notfallwiederherstellungsplan?

Ja. Auf technischer Ebene umfasst der Notfallwiederherstellungsplan die vollständige Neuerstellung der Lokad-Plattform. Dieser Teil nutzt umfangreich die automatisierten Prozesse, die wir für unsere wöchentlichen Releases implementiert haben. Auf geschäftlicher Ebene beinhaltet der Notfallwiederherstellungsplan die Kontaktaufnahme mit jedem unserer Kunden, in der Regel gemäß einem mit jedem Kunden vereinbarten Prozess. Für die meisten unserer Kunden fungieren die ernannten Supply Chain Scientists als Hauptansprechpartner während der Wiederherstellung.

3.9 Unterstützt die Lösung die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) über die Datenbank und Daten außerhalb der Datenbank hinweg? Was ist das Recovery Point Objective (RPO) der Lösung?

Die Lösung von Lokad verfügt über ein kontinuierliches Datensicherungskonzept durch das Live-Incremental-Backup sowohl des Ereignisspeichers als auch der Inhaltsquelle. Daher können wir PITR für jeden beliebigen Moment (bis auf die Minute genau) durchführen.

Wir haben ein RPO von 1 Minute für Desaster auf Rechenzentrumsebene - sofern die Daten nicht beeinträchtigt sind. Dies wird durch die geografisch redundante Schreibweise unseres persistenten Key-Value-Stores erreicht. Wenn der Key-Value-Store beeinträchtigt ist, stellt Lokad aus seinem Backup-Speicher wieder her (der so isoliert wie möglich von unseren Produktionssystemen gehalten wird) und der sich an einem anderen geografischen Standort befindet. In diesem Fall haben wir ein RPO von 12 Stunden.

3.10 Kann die Lösung Integritätsverletzungsalarme generieren? Verfügt die Lösung über die Möglichkeit, Integritätsprüfungen hinzuzufügen oder zu erweitern, wie es die Anforderungen erfordern?

Ja, obwohl dieses Problem hauptsächlich auf einem Software-Design basiert, das auf einer transaktionalen Datenbank beruht. Die Plattform von Lokad arbeitet jedoch nicht mit einer transaktionalen Datenbank, sondern mit einem Ereignisspeicher und verwendet ein Event-Sourcing-Design anstelle eines relationalen Designs. Dies bedeutet nicht, dass die Durchsetzung der Datenintegrität nicht erforderlich ist, sondern dass diese Bedenken auf alternative Weise angegangen werden.

Wenn es um die Verarbeitung von Kundendaten geht, verfügt Envision (Lokads DSL) über umfangreiche Funktionen zur Überprüfung der Datenqualität. Über Envision ist es möglich, die Integrität zu überprüfen und Alarme zu generieren. Diese Logik kann vom Kunden auf die gewünschte Weise erweitert oder geändert werden.

3.11 Werden Backups regelmäßig auf ihre ordnungsgemäße Datenwiederherstellungsfunktionalität getestet?

Ja. Das Event-Sourcing-Design von Lokad in Verbindung mit seinem inhaltsadressierbaren Speicher erleichtert den Test der Backup- und Datenwiederherstellungsfunktionalität erheblich im Vergleich zu den meisten gängigen Designs, die relationale Datenbanken (wie SQL) verwenden.

Siehe auch Vorfälle 3.7.

3.12 Werden die Notfallwiederherstellungspläne regelmäßig auf ihre ordnungsgemäße Funktionalität getestet?

Ja. Die Bereitstellungsstrategie von Lokad nutzt weitgehend automatisierte Skripte, wobei sehr wenige menschliche Eingriffe vorgesehen sind - eine bemerkenswerte Ausnahme ist die Möglichkeit, eine vollständige Produktionsneubereitstellung auszulösen. Dieser stark automatisierte Ansatz erleichtert den Test der Notfallwiederherstellungsfunktionalität.

Siehe Vorfälle 3.8.

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

Ja. Unsere interne Toolchain unterstützt die Möglichkeit, das Konto eines ausgewählten Kunden wiederherzustellen (einschließlich der Wiederherstellung des Kontos/der Umgebung zu einem bestimmten Zeitpunkt). Da die Lokad-Plattform selbst jedoch umfangreiche Versionierungsfunktionen bietet (z. B. sind Envision-Skripte versioniert und frühere Versionen können innerhalb der App abgerufen werden), wird diese Funktion selten verwendet.

3.14 Erfüllen die Backup- und Notfallwiederherstellungspläne die RTO (Recovery Time Objective), RPO (Recovery Point Objective) und die Anforderungen an Notfallszenarien (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 ausgefallen sein könnte, ohne dem Kunden erheblichen Schaden zuzufügen, sowie die Zeit, die für die Wiederherstellung der Plattform und ihrer Daten aufgewendet wird, damit sie den normalen Betrieb nach einem erheblichen Vorfall wieder aufnehmen kann.

Das RTO hängt sehr stark von den spezifischen von Lokad unterstützten/bereitgestellten Prozessen ab. Zum Beispiel kann ein Kunde, der sich auf Lokad verlässt, um monatliche Überseeeinkaufsaufträge zu planen, ein RTO von 1 Woche haben. Im Gegensatz dazu kann ein Kunde, der sich auf Lokad verlässt, um den täglichen Lagerbestand 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 verringern). Zum Beispiel können Failover-Entscheidungen im Voraus berechnet werden. Diese Entscheidungen können verwendet werden, falls die Lokad-Plattform nicht verfügbar ist. Im Vergleich zu “regulären” optimierten Entscheidungen können Failover-Entscheidungen eine leicht beeinträchtigte Lieferleistung aufweisen, da sie (per Definition) nicht auf den absolut neuesten Daten basieren würden.

Für unsere verwalteten Konten liegt es in der Verantwortung des Supply Chain Scientists bei Lokad, gemeinsam mit den betrieblichen Teams des Kunden einen Prozess zu entwickeln, der ein hohes RTO bietet, aber auch sicherstellt, dass bei tatsächlichen Vorfällen minimale Auswirkungen auf das Geschäft auftreten. Aus unserer Sicht handelt es sich bei dieser Herausforderung in erster Linie um ein Supply-Chain-Problem und nicht um ein IT-Problem.

Siehe auch Vorfälle 3.9.

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

Ja, Defekte können in unseren Umgebungen reproduziert werden. Die strikte Reproduzierbarkeit aller Datenzustände und Berechnungen ist ein grundlegendes Designprinzip der Lokad-Plattform und -Architektur. Zum Beispiel ist das Dateisystem innerhalb der Lokad-Plattform vollständig versioniert (wie Git), um dieses Problem zu lösen.

Es sollte beachtet werden, dass Protokolle effektiver zur Fehlerbehebung bei trivialen Problemen wie Serverausfall sind. Wenn es jedoch um die Fehlerbehebung bei komplexen Problemen und Defekten in einer datenintensiven Umgebung im großen Maßstab geht, bei der Terabyte an Daten beteiligt sind, sind Protokolle oft unzureichend.

Daher verlassen wir uns bei Lokad zwar auf Protokolle, um bei Bedarf darauf zurückzugreifen, aber nicht darauf, um Defekte zu beheben oder zu überprüfen, ob Defekte behoben wurden. Stattdessen nutzen wir hauptsächlich überlegte Designentscheidungen, um eine größere Einsicht, Rückverfolgbarkeit und Reproduzierbarkeit zu gewährleisten.

Diese bewussten Designentscheidungen ermöglichen es uns, Defekte zu identifizieren, zu reproduzieren und zu beheben, auf eine Weise, die rein auf Protokollen basierend nicht möglich wäre.

Bitte lesen Sie Architecture of Lokad für eine detaillierte Aufschlüsselung der verschiedenen Schlüsselentscheidungen, die wir treffen, um ganze Klassen von häufigen Softwareproblemen zu vermeiden.

3.16 Halten Sie Aufzeichnungen über alle Serviceanfragen und -aufrufe (einschließlich der Kategorie jedes Anrufs), die vom Kundenunternehmen gestellt werden? Enthalten die Aufzeichnungen: die Identität der anrufenden Person und der angerufenen Person; die Art des gemeldeten Fehlers, Problems oder Vorfalls; die Reaktionszeit von Lokad; die Behandlung des Serviceanrufs; die Lösung; die Lösungszeiten; und die Systemverfügbarkeit?

Ja, die Plattform von Lokad verfügt über Funktionen zur Aufgaben-/Ticket-/Problemverwaltung, die die aufgeführten Details bereitstellen.

In Bezug auf “Lösungen” ist es erwähnenswert, dass die quantitative Supply Chain-Philosophie (QSC) von Lokad darin besteht, den finanziell vorteilhaftesten Kompromiss zu finden, wenn ein Problem auftritt. QSC ist technisch gesehen kein “Problembehebungs”-Ansatz, da Supply Chain-Probleme nicht “behoben” werden, sondern durch finanziell fundierte Kompromisse abgeschwächt werden.

Kurz gesagt, Lokad verfügt über die Tools und Prozesse, um “einfache Probleme” (wie Serverausfall) auf einfache Weise schnell zu lösen. Wenn es um größere, folgenreichere Supply Chain-Probleme geht (wie die Zuweisung von Einzelhandelsbeständen oder Probleme bei der Bestandsauffüllung), handelt es sich in der Regel um offene und fortlaufende Diskussionen mit Kunden darüber, welche Kompromisse ihren Return on Investment maximieren.

4. Architektur

4.1 Welche Programmiersprachen verwenden Sie?

Die Lokad-Plattform wird in C#, F# und TypeScript entwickelt. Die Plattform umfasst auch Envision (Lokads DSL), das zur Implementierung der kundenspezifischen Supply Chain-Lösungen verwendet wird.

4.2 Welche Entwicklungsumgebung verwenden Sie?

Die Softwareentwicklungsteams von Lokad verwenden Microsoft Visual Studio. Die Supply Chain Scientist-Teams verwenden 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 (z. B. Firefox) haben. Intern ist Lokads Plattform sowohl mit Linux als auch mit Microsoft Windows kompatibel, obwohl alle unsere Produktionssysteme unter Linux (Ubuntu) bereitgestellt werden.

4.4 Welches Datenbanksystem verwenden Sie oder unterstützen Sie?

Lokad unterstützt alle Datenbanksysteme, die flache Dateiexports erstellen können. Dies umfasst praktisch alle Datenbanksysteme auf dem Markt, einschließlich älterer Modelle. Intern verwendet Lokad kein Datenbanksystem, sondern einen Key-Value-Store. Zum Zeitpunkt der Erstellung (Januar 2023) verwenden wir Blob Storage, wie es von Microsoft Azure bereitgestellt wird.

4.5 Welches Cachingsystem verwenden Sie?

Lokad hat sein eigenes Cachingsystem in C#/.NET entwickelt. Diese Systeme sind eng mit dem Rest der Lösung integriert und spiegeln nicht die traditionellen Cachingsysteme wider, die hauptsächlich zur Behebung von Leistungsproblemen mit einer relationalen Datenbank gedacht sind (die Lokad nicht hat).

4.6 Wie geht die Lösung mit Zertifikaten um?

Lokad nutzt Let’s Encrypt für automatisierte Zertifikatverlängerungen.

4.7 Welche technischen Voraussetzungen sind erforderlich, um die Lösung zu nutzen?

Die wichtigste technische Voraussetzung ist ein Transaktionssystem, das den Lagerbestand verfolgt. Es ist auch hilfreich, wenn der Kunde Erfahrung darin hat, Daten (als flache Dateien) aus seinen Transaktionssystemen zu extrahieren, aber dies ist sicherlich keine Voraussetzung.

4.8 Nennen Sie alle zusätzlichen Drittanbieterlizenzen, die zur Nutzung von Lokads Lösung erforderlich sind (z. B. OS, SQL,…).

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

4.9 Benötigt der Service Browser-Plug-Ins oder spezielle Software?

Lokad ist eine Webanwendung. Es erfordert keine Browser-Plug-Ins oder spezielle Software.

4.10 Welche Ein- und Ausgangsschnittstellen hat die Anwendung?

Lokads Lösung bietet eine Web-Schnittstelle - erreichbar über HTTPS - und Dateiprotokolle, nämlich SFTP und FTPS.

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

Lokads Lösung trennt Mandantendaten durch ihr eigenes Design, was sicherstellt, dass Datenlecks (auch versehentliche) nicht auftreten. Darüber hinaus wird der gesamte Code, der in die Produktion übernommen wird, von Kollegen überprüft, was eine zusätzliche Schutzschicht bietet. Schließlich weisen wir Sicherheitsforscher (Personen, die Pentests durchführen) explizit darauf hin, die Möglichkeit von Datenlecks zu untersuchen. Wir geben ihnen Zugang zu mehreren Lokad-Konten - in einer dedizierten und vollständig isolierten Umgebung, die der Produktionsumgebung entspricht - damit sie diese Eigenschaft unserer Plattform aggressiv überprüfen können.

4.12 Kann die Lösung containerisiert werden?

Ja, aber es gibt wenig bis gar keinen Nutzen, die Lokad-Plattform zu containerisieren. Containerisierung bringt dann einen Mehrwert, wenn es komplexe Abhängigkeiten gibt (z. B. eine transaktionale Datenbank, ein isoliertes Cachingsystem usw.). Wir verwenden keine Container in Produktion oder Entwicklung, was unsere Sicherheit verbessert, indem ganze Klassen von Schwachstellen eliminiert werden. Stattdessen halten wir die Lösung einfach genug, damit die Bereitstellung sogar 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 Web-Schnittstellen) sind eigenständig. Dieses Design trägt zur höheren Verfügbarkeit bei. Endbenutzer können auf ihre Lokad-Kontodashboards zugreifen, auch wenn eine plötzliche Ausfallzeit eines der anderen Subsysteme auftritt.

4.14 Unterstützt die Lokad-Anwendung Lokalisierungsfunktionen (wie Sprachänderung)?

Ja, die Anwendung unterstützt Lokalisierungsfunktionen. Alle von Lokads Plattform erstellten Benutzeroberflächen können in jeder Sprache lokalisiert werden. Insbesondere verwendet der gesamte technologische Stack UTF-8, um alle Zeichensätze zu unterstützen, die über den lateinischen Zeichensatz hinaus existieren. Insbesondere kann jede von Lokads Plattform erstellte Benutzeroberfläche - nach der Auslieferung - in eine andere Sprache umgelokalisiert werden.

4.15 Können Endbenutzer nach der Auslieferung von nachbearbeiteten Daten von Lokad Aktualisierungen vornehmen oder neue Übersetzungen erstellen?

Ja, siehe 4.14 oben.

4.16 Hat Ihr System eine integrierte Hilfe? Wenn ja, in welcher(n) Sprache(n)?

Ja, Lokad wird mit sehr umfangreicher öffentlicher Dokumentation (in Englisch) geliefert. Die Verwendung der Lokad-Plattform beinhaltet jedoch die Erstellung maßgeschneiderter Benutzeroberflächen, und unser regulärer Prozess umfasst mindestens zwei Formen von Dokumentation oder Hilfe.

Erstens sind die innerhalb der Lokad-Lösung erstellten Dashboards dazu gedacht, kontextbezogen dokumentiert zu werden - direkt im Dashboard selbst. Insbesondere haben wir sogar eine Markdown-Kachel, die der Rich-Text-Dokumentation gewidmet ist. Zweitens umfassen unsere Lieferungen ein “Gemeinsames Verfahrenshandbuch”. Insgesamt bietet das Handbuch eine detaillierte Analyse nicht nur der Mechanik der Lösung, sondern auch warum jedes Element ausgewählt wurde (und wie es den spezifischen Bedürfnissen der Lieferkette des Kunden gerecht wird).

4.17 Ist die Webanwendung responsiv?

Die Lokad-Webanwendung sowie die unterstützenden Materialien (wie die technische Dokumentation) wurden so konzipiert, dass sie responsiv sind. Einige erweiterte Funktionen wie das Bearbeiten von Code sind jedoch für mobile und/oder Tablet-Geräte nicht praktikabel. Das Design zielt daher darauf ab, die Reaktionsfähigkeit für die erwarteten Aktivitäten auf PCs und kleineren Geräten zu maximieren.

4.18 Wenn Ihr System eine Webanwendung ist, welche Browser und Versionen unterstützen Sie? Was ist Ihr Mindeststandard für Internetbrowser?

Lokad ist eine Webanwendung und wir unterstützen die gängigen “evergreen” Webbrowser wie Chrome, Firefox und Safari. Aus Sicherheitsgründen versuchen wir nicht, ältere Browser zu unterstützen, da die Unterstützung dieser Browser implizit unsere Kunden gefährdet. Einfach ausgedrückt kann ein anfälliger Browser von einem bösartigen Akteur genutzt werden, um Daten zu exfiltrieren. Das heißt, wir sind auch sehr konservativ, wenn es um neue Browserfunktionen geht. Als Faustregel vermeiden wir die Unterstützung von Browserfunktionen, die von allen gängigen Webbrowsern nicht mindestens 1 Jahr lang übernommen wurden.

4.19 Welche Betriebssysteme (und Versionen) unterstützt Lokad für mobile und Tablet-Anwendungen?

N/A. Da Lokad eine als SaaS bereitgestellte Webanwendung ist, sind unsere Kunden nicht auf die Unterstützung von Betriebssystemen angewiesen. Intern wird Lokad unter Windows entwickelt, während unsere Produktionsumgebung in der Cloud unter Linux läuft. Daher sind wir ziemlich zuversichtlich in Bezug auf die breite Portabilität der Lokad-Lösung. Obwohl wir derzeit keinen Bedarf sehen, diese Konfiguration zu ändern, werden wir uns entsprechend anpassen, wenn sich valide Beweise ergeben.

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

Ja, Lokad verfügt über die Möglichkeit, Benachrichtigungen über programmierbare HTTP-Hooks zu senden. Diese Hooks können genutzt werden, um ein bereits im Unternehmen des Kunden vorhandenes System von Drittanbietern zu verwenden, um eine E-Mail-Benachrichtigung oder einen anderen geeigneten Benachrichtigungstyp zu senden. Die Hooks werden auch typischerweise verwendet, um die Verfügbarkeit von Daten anzuzeigen, die von der Lokad-Plattform über SFTP oder FTPS abgerufen werden können.

4.21 Gibt es gemeinsame Elemente in der Lösung, die für alle Kunden gleich sind (wie Überwachungsfunktionen, Backup- oder Patch-Management-Lösungen usw.)?

Ja, da Lokad eine Multi-Tenant-App ist, werden die Infrastruktur-Level-Funktionen zwischen den Mandanten bzw. Kundenkonten geteilt. Dazu gehören Überwachung der Betriebszeit, Leistung und aus Sicherheitsgründen Backup, Patch-Management, Upgrade usw.

4.22 Ermöglicht die Lösung die Funktion für Mehrziel-Nachrichten (d.h. die Möglichkeit, eine Nachricht an mehrere Empfänger oder Anwendungen zu senden)?

Die Lokad-Plattform arbeitet nicht mit Nachrichten. Wir bieten jedoch HTTP-Hook-Funktionen an, die verwendet werden können, um beliebig komplexe Benachrichtigungen zu generieren, normalerweise über kostengünstige Systeme von Drittanbietern. Diese Benachrichtigungen werden manchmal von Lieferkettenteams verwendet, um die rechtzeitige Fertigstellung von geschäftskritischen Berechnungsbatches mit der Lokad-Plattform zu überwachen.

4.23 Verwenden alle kritischen Systeme und Komponenten dieselbe Zeitquelle (NTP) oder synchronisieren sie ihre Uhren auf 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 Zeit-Synchronisierungsdienst ausgeführt, der sich mit einer externen NTP-Zeitquelle synchronisiert, die über das Netzwerk erreicht wird.

4.24 Gibt es eine Vermögensinventarliste oder eine Konfigurationsverwaltungsdatenbank (CMDB)?

Ja, wir haben eine IT-Asset-Management-Software, um unsere Prozesse zu unterstützen. Diese Plattform hilft uns dabei, eine umfassende Vermögensinventarliste zu führen und dient als unsere Konfigurationsverwaltungsdatenbank (CMDB). Über dieses System können wir Hardware- und Software-Assets effizient verfolgen, verwalten und zuweisen. Unsere Teams haben die Möglichkeit, den Status, den Standort und die Konfiguration eines Assets schnell zu identifizieren, um schnell auf Änderungen, Updates oder potenzielle Probleme reagieren zu können.

Darüber hinaus bietet unser Tool Funktionen zur detaillierten Lebenszyklusverwaltung, um sicherzustellen, dass Assets von der Beschaffung bis zum Ende ihres Lebenszyklus genau erfasst werden. Automatisierte Prüfungsfunktionen in Verbindung mit detaillierten Berichtsfunktionen gewährleisten, dass wir die volle Sichtbarkeit und Kontrolle über unsere IT-Umgebung aufrechterhalten und die Einhaltung von Vorschriften sowie eine effiziente Ressourcenzuweisung erleichtern.

4.25 Wird jede Verbindung zu einem externen Netzwerk an einer Firewall beendet (z. B. das Internet, Partner-Netzwerke)?

Nein, wir beenden nicht jede Verbindung zu einem externen Netzwerk an einer Firewall, sei es das Internet oder Partner-Netzwerke. Unsere Entscheidung basiert auf realen Bedenken hinsichtlich der Wirksamkeit und Auswirkungen solcher Maßnahmen.

Aus unserer Sicht können Firewalls, obwohl sie typischerweise als erste Verteidigungslinie angesehen werden, paradoxerweise die Angriffsfläche erweitern. Je mehr Komponenten und Systeme wir integrieren, desto mehr potenzielle Schwachstellen führen wir ein. Firewalls arbeiten aufgrund ihrer Natur als Prozesse mit hohen Privilegien. Das bedeutet, dass sie Hauptziele für Cyberangriffe werden und wenn sie kompromittiert werden, können die Folgen verheerend sein. Ein anschauliches Beispiel ist der SolarWinds-Angriff, bei dem die Systeme, die Informationen schützen sollten, ausgenutzt wurden und zu erheblichen Sicherheitsverletzungen führten.

Darüber hinaus kann die strikte Verwendung von Firewalls in praktischer Hinsicht kontraproduktiv sein. Unsere Erfahrung hat gezeigt, dass solche Systeme Mitarbeiter oft dazu anregen, alternative Möglichkeiten zur Zugriffs- und Informationsfreigabe zu suchen. Dies beinhaltet in der Regel das Umgehen des Firmennetzwerks (und damit die Verhinderung jeglicher Überwachung) durch die Verwendung persönlicher 4G- oder 5G-Verbindungen von eigenen Geräten. Solche Praktiken erhöhen unbeabsichtigt das Risiko von Sicherheitsverletzungen und Datenlecks.

Daher basiert unser Sicherheitsansatz zwar auf einem tiefen Engagement für Sicherheit, ist jedoch ganzheitlich und von praktischen Überlegungen geprägt, anstatt sich ausschließlich auf traditionelle Maßnahmen zu verlassen.

4.26 Verfügt das Netzwerk über eine DMZ-Umgebung, in der kritische Systeme (wie Webserver, DNS, Verzeichnisdienste und Remotezugriff) sowie Kundendaten übertragen, verarbeitet oder gespeichert werden?

Nein, Lokad verwendet in unserem Netzwerk keine traditionelle DMZ-Umgebung zum Übertragen, Verarbeiten oder Speichern von kritischen Systemen und Kundendaten. Stattdessen haben wir einen Zero-Trust-Ansatz für die Netzwerksicherheit gewählt.

Dieses Modell stützt sich nicht auf DMZs, sondern basiert vielmehr auf dem Prinzip “niemals vertrauen, immer überprüfen”. Jede Zugriffsanfrage wird validiert und authentifiziert, unabhängig von ihrer Herkunft, sei es von innerhalb oder außerhalb der Organisation.

Dies gewährleistet eine robustere und ganzheitlichere Sicherheitsposition, da es nicht von Perimeterschutz wie einer DMZ abhängt, sondern sich stattdessen auf die Sicherung jedes einzelnen Zugriffspunkts und jeder Datenübertragung konzentriert. Wir sind der Meinung, dass der Zero-Trust-Ansatz einen überlegenen Schutz für unsere kritischen Systeme und Kundendaten bietet.