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 Transaktionssystemen (ERP, WMS, CRM usw.) betrieben wird. 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) bereitgestellt werden, reduzieren fast vollständig die Notwendigkeit technischer Unterstützung durch die IT-Abteilung selbst für diesen Bereich. Der einzige wesentliche Beitrag, der von der IT-Abteilung erwartet wird, ist die Einrichtung eines Daten-Pipelines, die Flachdateien (per SFTP oder FTPS) an Lokad sendet und möglicherweise die generierten Ergebnisse wieder integriert.

Zielgruppe: Die IT-Abteilung
Zuletzt geändert am: 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 Flachdateien (bis zu 100 GB pro Datei) ausgerichtet und verfügt über eine Datenversionierung (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 Kernnumerischen Analysen durchzuführen (einschließlich Machine-Learning-Algorithmen, 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 wird in der Regel unter 5 Minuten gehalten. Lokad übernimmt alle Versionierungsprobleme vollständig.

Von der IT-Abteilung wird nicht erwartet, dass sie jemals eine spezifische Kompetenz mit dem Lokad-Stack erwirbt. Wenn Sie jedoch neugierig sind, gibt es eine vollständige technische Dokumentation.

Beitrag der IT-Abteilung im Überblick

Wir erwarten von der IT-Abteilung, dass sie eine Datenpipeline einrichtet, die eine kurze Reihe relevanter Flachdateiextraktionen per SFTP oder FTPS an Lokad sendet. Die Extraktionen werden über die Transaktionssysteme durchgeführt (z. B. ERP). Wir haben eine starke Präferenz für Rohdatenextraktionen (kein Filter, kein Join, keine Transformation), was minimalen Aufwand erfordert. Aus ETL-Sicht benötigen wir nur den ‘E’ (Extrakt)-Teil in seiner einfachsten Form (einfache Kopie). Formatmäßig ist Lokad mit jeder vernünftig tabellarischen Flachdatei kompatibel.

Es wird erwartet, dass die Datenpipeline mindestens täglich ausgeführt wird und vollständig automatisiert ist. Der Arbeitsaufwand für die IT-Abteilung hängt vom Umfang der Datenextraktion ab (welche Systeme? welche Tabellen?). Allerdings erfordert die Einrichtung der Datenpipeline in der Regel etwa 15 bis 45 Mann-Tagen, selbst für große Unternehmen. Sobald die Datenpipeline eingerichtet ist, erfordert Lokad in der Regel nur minimales Monitoring von der IT-Abteilung, das in der Regel mit 1 oder 2 Mann-Tagen pro Monat durchgeführt wird.

Sicherheitsüberblick

Die App wird in Rechenzentren von Microsoft Azure in der EU gehostet. Wir verarbeiten keine personenbezogenen Daten, da wir solche Daten nicht benötigen, um zu arbeiten. Bei der Festlegung des Datenextraktionsumfangs schließen wir jede Spalte oder jedes Feld aus, das personenbezogene Daten enthalten würde.

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. Dies beseitigt alle mit Passwörtern verbundenen Probleme.

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

Weitere Details finden Sie unter Sicherheit bei Lokad.

Zeitplanüberblick

Die Quantitative Supply Chain ist eher eine Reise als ein Selbstzweck. Gleichzeitig benötigt die Supply Chain-Führung, die ihr Unternehmen in die Durchführung einer Initiative zur Quantitativen Supply Chain einbezieht, Transparenz hinsichtlich des Projektzeitplans. 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 zu entfalten. Im folgenden Abschnitt geben wir einen Überblick über einen typischen Zeitplan, der mit einer Initiative zur Quantitativen Supply Chain für ein mittelständisches Unternehmen verbunden ist. Bei großen Unternehmen sollten doppelt so lange Zeitpläne erwartet werden.

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

Datenanforderungen: Kurz nach dem Kickoff-Meeting erstellt der Supply Chain Scientist die für die Umsetzung des Projekts erforderlichen Datenanforderungen. Diese Anforderungen werden zusammen 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 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 Datenspezifikation zu erzielen.

Validierung der Daten: Der Supply Chain Scientist führt eine eingehende Untersuchung des Datensatzinhalts des Kunden durch. Insbesondere werden Überprüfungen eingeführt, um die Qualität der Daten gemäß mehrerer 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 kohärent und ausreichend vollständig für Optimierungszwecke der Supply Chain ist.

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

Audit in der Mitte des Projekts: 6 Wochen nach dem ersten Kickoff wird ein Treffen vereinbart, um den Status der Projektabschluss 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 Scientist und dem Kunden, basierend auf einer Checkliste, die dem Kunden unmittelbar nach dem Kickoff-Meeting vom Supply Chain Scientist ü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 Seiten von Lokad die Datenqualitätslogik - mit ihren mehrfachen Überprüfungen - geplant, um nach jedem Upload aktualisiert zu werden.

Optimierung einrichten: Ab diesem Zeitpunkt verfügt der Supply Chain Scientist über alle notwendigen Zutaten, um die Optimierung der Entscheidungen umzusetzen, die zuvor mit dem Kunden vereinbart wurden. 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 Dashboard-Form visualisiert werden. Zu diesem Zeitpunkt 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, eine Art Änderung vorzunehmen oder die verschiedenen Ausgaben “anzupassen”, führen in der Regel zu einer Feinabstimmung der Skripte, die vom Supply Chain Scientist geschrieben wurden. Es gibt viele Parameter und Methoden, die angenommen 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 Scientist diskutiert.

Produktion: Nach mehreren Runden der Feinabstimmung und Überarbeitung erreicht der Kunde einen Punkt, an dem er dem vom Supply Chain Scientist implementierten Logik vertraut. Zu diesem Zeitpunkt kann der Kunde den Service in der Produktion verwenden, das heißt, er kann die Supply-Chain-Entscheidungen direkt ausführen, wie sie ursprünglich von der Software berechnet wurden. Wenn der Kunde validiert, dass die Lösung produktionsbereit ist, liefert der Supply Chain Scientist eine Dokumentation, die die Wartbarkeit der Lösung gewährleistet.

Support & Wartung: Die Lösung ist betriebsbereit und wird vom Kunden verwendet, während der Supply Chain Scientist die reibungslose tägliche Ausführung des Daten-Pipelines überwacht. Regelmäßige Anrufe werden zwischen dem Kunden und dem Supply Chain Scientist organisiert, um zu überprüfen, ob die Optimierung den erwarteten Grad der Leistung der Supply Chain 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 Scientist schlägt geeignete Änderungen vor, um diese verschiedenen Änderungen zu berücksichtigen. Checkpoint-Anrufe sind mit einer vereinbarten Frequenz geplant, in der Regel monatlich.

Häufig gestellte Fragen (FAQ)

1. Release-Management

1.1 Wie funktionieren Releases für Lokad?

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

Lokads Releases sind sehr granular, und das Design ermöglicht es dem Kunden in der Regel, sich von einem bestimmten technischen Element eines Gesamt-Releases abzumelden. Daher kann, wenn wir die Implementierung eines Elements verschieben müssen - für das unser Kunde noch nicht bereit ist - 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, werden wir die Lösung durch unsere üblichen automatisierten Mittel neu implementieren.

1.5 Wie lange dauert es, bis ein wichtiges Release angewendet wird?

Der automatisierte Prozess dauert etwa 1 Stunde. Es erfolgt eine schrittweise Einführung (Maschine für Maschine), da wir beabsichtigen, die Betriebsfähigkeit und Zugänglichkeit der Lokad-Plattform während des Releases aufrechtzuerhalten. Die Betriebsfähigkeit während einer Einführung wird in Release Management 1.7 erörtert.

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

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

1.7 Gibt es eine Ausfallzeit während des Releases?

Meistens nicht, aber beachten Sie, dass die Lösung von Lokad ein verteiltes System für groß angelegte Berechnungen ist. Als solches unterscheidet sich der Einfluss eines Releases zwischen den Front- und Back-End-Systemen. Kundengerichtete Teilsysteme wie die Dashboards sind auf eine Ausfallzeit von Null ausgelegt. 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 Strategie für ein Release?

Lokad nutzt automatisierte Prozesse, die dem Testen und der Sicherstellung der Korrektheit eines bevorstehenden Releases gewidmet sind. Diese Prozesse umfassen umfangreiche Suiten von automatisierten Tests (gemessen in Tausenden); Unit-Tests, Funktionstests, Leistungstests usw. Wir haben auch spezielle Tools entwickelt, die es uns ermöglichen, ganze Sequenzen vergangener Jobausführungen innerhalb der Lokad-Plattform zu reproduzieren. Mit diesen Tools können wir überprüfen, ob Envision-Skripte vor/nach einem bevorstehenden Release das genau gleiche Verhalten aufweisen. Darüber hinaus können wir überprüfen, ob die Leistungsprofile bestehender Skripte den zeitlichen Erwartungen 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 gedacht. Neben der Produktionsumgebung und den vorübergehenden Entwicklungsumgebungen haben wir eine ’evergreen’-Umgebung, die der letzten stabilen Version unseres Codebasis entspricht. Dies validiert einen spezifischen Teil unserer automatisierten Testprozesse. Unsere Kunden können Zugang zu unserer ’evergreen’-Umgebung erhalten, um zu validieren, dass 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, (parallel) mehrere Varianten von Envision-Skripten ausführen zu können, kann ein Lokad-Konto in mehrere “Umgebungen” unterteilt werden. Wenn das Ziel darin besteht, jegliche Art von Tests 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 einzigartige Version ausführt. Lokad hat jedoch die Kapazität, so viele verschiedene Versionen zu betreiben, wie vom Kunden gewünscht.

1.11 Kann ein Kunde sich von einem Release abmelden?

Da Lokad ein Multi-Tenant-SaaS ist, das für alle Kunden dieselbe einzigartige Version ausführt, 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 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 geteilt (mit unseren Teams von Supply Chain Scientists). Wenn dies ausdrücklich 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 nur für Personen von Interesse, die mit Envision-Code arbeiten.

1.13 Wie ist der Prozess für einen Kunden, eine Weiterentwicklung der Lösung anzufordern?

Die meisten unserer Kunden profitieren von einem “Software + Experten”-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. Außerdem profitieren die meisten Kunden 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 nimmt die Form von Envision-Skripten an - Envision ist die von Lokad entwickelte DSL (Domain-spezifische Sprache) für die prädiktive Optimierung der Supply Chain.

Somit ist in gewisser Weise jede einzelne Parameterkonfiguration verfügbar, indem Envision-Skripte innerhalb des Kontos genutzt werden.

2. Leistung

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

Ja. Das SLA ist Bestandteil unserer standardmäßigen Vertragsvereinbarung. Die Betriebszeit in einem verteilten Computersystem - das der prädiktiven Optimierung von Supply Chains gewidmet ist - ist jedoch komplex. Betrachten Sie die folgenden Szenarien: - Lokad erhält die Kundendaten (täglicher Schritt) 2 Stunden verspätet. Dies kann die ordnungsgemäße Effizienz unserer Ressourcenallokationsheuristiken beeinträchtigen. Dies kann wiederum die Zeit verlängern, die für die Ausführung von Lokad-Batch-Jobs benötigt wird (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 pünktlich, aber die Daten zeigen einen erheblichen Lagerbestandsrückgang. 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 sieht, 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 korrupt waren und zu einem großen Lagerabschreibung geführt hätten. Einige mögen dies als 24-stündige Ausfallzeit betrachten, aber das scheint in diesem Zusammenhang praktisch abwegig.

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

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

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

Wir haben so etwas wie “Konstantzeit-Dashboards” entworfen. Unter der Haube erfordert die Anzeige eines Dashboards eine einzige Anfrage über das Netzwerk, und in unserem Backend kollokieren wir alle Dashboard-Daten, um die Anzahl der Netzwerkanfragen niedrig zu halten (normalerweise in einstelligen Zahlen gemessen). Diese Gestaltung trägt wesentlich dazu bei, die geringe Latenzzeit 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 Gesamtnutzererfahrung verlangsamt.

In Bezug auf die Dauer von Batch-Jobs können wir durch Envision Garantien - zur Kompilierzeit - dafür geben, dass ein Batch-Job abgeschlossen wird. 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 - was bestimmte Klassen von statischen Analysen überhaupt erst möglich macht. Dieser Ansatz hat Grenzen, ist aber weitaus überlegen gegenüber Designs, die überhaupt keine Garantien bieten.

Die End-to-End-Latenz liegt jedoch nicht vollständig in unserer Hand. Wir kontrollieren beispielsweise nicht die Qualität der Internetverbindung, die von unseren Kunden verwendet wird. Eine große Tabelle von Lokad wird Zeit benötigen, um über ein Netzwerk mit geringer Bandbreite heruntergeladen zu werden.

2.3 Haben Sie Systemleistungsprüfungsprotokolle?

Ja. Wir sammeln sehr granulare Leistungsprotokolle für alle beteiligten Rechenressourcen: CPU, Speicher, Speicherplatz, Bandbreite usw. Diese Leistungsprotokolle werden unter anderem verwendet, um sicherzustellen, dass eine neue, bisher unveröffentlichte Version der Plattform unseren Leistungserwartungen entspricht. Dies testen wir, 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 Staus 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 größtenteils 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 des Leistungsmonitorings für unsere Kunden nicht direkt zugänglich (da es die Leistung der Plattform als Ganzes betrifft). Wie zu erwarten ist, überwachen die Lokad-Teams kontinuierlich die Leistung unserer Plattform.

2.5 Haben Sie Lastenausgleichsgeräte?

Ja. Die Lastenausgleichsgeräte von Lokad sind hauptsächlich für die Zuverlässigkeit und nicht für Leistungszwecke gedacht. Der Lastenausgleich auf Netzwerkebene erfolgt über die Netzwerkschicht der von uns verwendeten Cloud-Computing-Plattform (Microsoft Azure). Die Verteilung der internen Datenverarbeitungsworkloads, die von der Lokad-Plattform gehandhabt werden, erfolgt jedoch nicht über Lastenausgleichsgeräte, sondern über einen hauseigenen 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 den Begriff der automatischen parallelisierten Ausführung herum konzipiert. Die Lokad-Plattform nutzt aktiv die 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 die parallele Verarbeitung ein Kernaspekt des Designs von Envision ist, profitieren nahezu alle Workloads, die auf der Lokad-Plattform ausgeführt werden, standardmäßig von umfangreicher Parallelisierung, ohne spezifische Anstrengungen für unsere Kunden oder unsere Supply Chain Scientists.

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

Ja. Das Zwischenspeichern wird jedoch häufig als Workaround eingeführt, um mit den Leistungseinschränkungen von transaktionalen Datenbanken umzugehen. Da die Lokad-Plattform keine transaktionalen Datenbanken enthält, verwenden wir das Zwischenspeichern nicht zu diesem 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 von 3 Faktoren vorliegt.

1. Eine Antwort wird komprimiert.

2. Eine Antwort enthält ein Geheimnis.

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

Um sich gegen BREACH zu verteidigen, deaktiviert Lokad die Kompression bei allen Antworten, bei denen die dritte Bedingung zutrifft. Wir komprimieren Daten auch aus Gründen jenseits der Reduzierung des Netzwerkverkehrs; erstens, um die Kosten für die Datenspeicherung zu reduzieren; und zweitens, um die Rechenverzö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 bevorstehenden Version im Vergleich zur mit derzeit bereitgestellten Version zu bewerten. Dieses Tool ermöglicht es uns, die gleichen Workloads zu reproduzieren, wie sie in der Produktion beobachtet werden, und die resultierende Leistung zu überwachen; nicht nur in Echtzeit, 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 Äquivalent sind die Ausführungen von Envision-Skripten. Für diese Skripte überwachen wir die Leistung auf einer sehr granularen Ebene, die grob analog zur Überwachung des Feindrucks der Abfrageplan-Ausführung ist (aus der Perspektive einer transaktionalen Datenbank).

Siehe Autorisierung 3.6 und Protokollierung und Überwachung 5.3 in unserer Sicherheits-Dokumentation für weitere Informationen zu “Transaktionen” in der Lokad-Lösung.

2.12 Was ist der Leistungseinfluss von gleichzeitigen Benutzern auf die Lösung?

Fast keiner. Das Design von Lokad gewährleistet, 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 Kontrast 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 eine sekundäre Überlegung, wenn es um die Leistung der Lösung geht. Was die prädiktive Optimierung der Lieferkette betrifft, so machen die Stapeljobs, die zur Durchführung der interessierenden Analysen verwendet werden, mehr als 99% der Arbeitslast aus. Der Rest von weniger als 1% ist der Bedienung von Benutzeranfragen gewidmet.

2.13 Ist das System darauf ausgelegt, vertikal und horizontal zu skalieren?

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

2.14 Skaliert sich Compute und Speicher automatisch nach Bedarf?

Ja. Die Lokad-Plattform ist mandantenfähig. Durch Mandantenfähigkeit führen wir groß angelegte, latenzarme Zuweisungen von Rechenressourcen durch. Das bedeutet, dass das von Lokad bereitgestellte Compute-Auto-Scaling um Größenordnungen schneller ist als das Bereitstellen großer VMs (virtueller Maschinen) von einem Cloud-Computing-Anbieter. Das Storage-Auto-Scaling wird größtenteils durch die Nutzung der Auto-Scaling-Eigenschaften des persistenten Key-Value-Stores durchgeführt, wie sie von der zugrunde liegenden Cloud-Computing-Plattform bereitgestellt werden (Microsoft Azure).

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

Die Lokad-Plattform wurde speziell für die Verarbeitung von “Big Data” entwickelt. Stand Januar 2023 verwaltet die gesamte Lokad-Plattform etwa 1 Petabyte Daten in unserer gesamten Kundenbasis. Unsere Plattform kann einzelne Dateien von bis zu 100 GB verarbeiten, und wir verarbeiten routinemäßig Tabellen mit zig Milliarden Zeilen. Gehe zu 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 zur Gestaltung 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 Bandbreite als auch Latenz). Diese Bedenken werden hauptsächlich durch grundlegende technologische Designentscheidungen adressiert. Diese architektonischen Designentscheidungen unterscheiden Lokad auch von der Mainstream. Bedenken hinsichtlich der Bandbreite werden auf zwei Arten angegangen. Erstens sind wir sparsam, wenn es um JavaScript-Drittanbieterkomponenten geht. Wir haben weniger als 1 MB an Assets, die zu Beginn abgerufen werden müssen. Zweitens bietet die Plattform vollständige Kontrolle darüber, wie viele Daten in ein einzelnes Dashboard aufgenommen werden sollen. Daher ist es bei schlechter Konnektivität möglich, das Dashboard entsprechend “leicht” zu gestalten. In Bezug auf Latenzbedenken wurden unsere Dashboards so konzipiert, dass alle relevanten Dashboard-Daten in einer einzigen HTTP-Anfrage verpackt sind. Dies minimiert die Reibung, die bei Endbenutzern mit geringer Latenz auftritt.

2.17 Was sind die durchschnittlichen und Spitzen-Durchsatzkapazitäten der Lösung im Vergleich zu einem Benchmark von 1 (Low-End) und 5 (High-End) Nachrichten pro Sekunde?

Die Lokad-Plattform arbeitet nicht mit Nachrichten. Ebenso werden Interaktionen mit der Lokad-Plattform nicht über Nachrichten durchgeführt. Der Durchsatz ist jedoch wichtig, um große Datensätze transaktionaler Daten schnell zu verarbeiten. Die Lokad-Plattform verwaltet insgesamt über 1 Petabyte Daten. Wir verarbeiten routinemäßig über 1 Terabyte pro Minute für große Berechnungschargen.

Ein sehr hoher Durchsatz ist wichtig, um Verzögerungen im Betrieb zu vermeiden, wenn sehr große Datensätze (zig Terabyte) mit komplexen Berechnungen verarbeitet werden, die Schritte des maschinellen Lernens und der mathematischen Optimierung enthalten.

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 “Flachdateien”. Diese Flachdateien 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 Ticketsystem an?

Ja. Lokad nutzt ein Ticketsystem 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, unter der Voraussetzung einer dedizierten vertraglichen Vereinbarung.

Im Kontext der prognostizierten Optimierung der Lieferkette 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”. Vielmehr wären tatsächliche Besonderheiten in der Lieferkette - die möglicherweise Probleme mit in das Kundenkonto implementierten Envision-Skripten widerspiegeln oder auch nicht - bessere Kandidaten. 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 früh (ca. 2010) zum Vorreiter bei Cloud-Computing-Plattformen, um eine höhere Verfügbarkeit sicherzustellen. Neben der Redundanz der Infrastruktur (siehe Vorfälle 3.5) betont das Design von Lokads Lösung stark die 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 aufrechtzuerhalten (die sich über mehrere Zeitzonen erstrecken).

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

Ja. Unsere kritischen Systeme sind redundant, genau 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 Veröffentlichungen genutzt, um die Betriebszeit während des Rollouts zu gewährleisten.

3.6 Wie erholen Sie sich von Hardwarefehlern?

Die Wiederherstellung von den meisten Hardwarefehlern wird transparent von der Cloud-Computing-Plattform durchgeführt, die Lokad verwendet. Die eingebaute Redundanz der Lokad-Plattform stellt sicher, dass vorübergehende Hardwarefehler die Betriebszeit nicht beeinträchtigen, während die Cloud-Computing-Plattform eine neue nicht defekte Ressource zuweist. Für persistente Datenspeicherung nutzt Lokad nur Dienste (d. h. Schlüssel-Wert-Speicher), die selbst gegen Hardwarefehler geschützt sind durch ihre eigenen Redundanzschichten.

3.7 Haben Sie ein Backup?

Ja. Wir haben eine Backup-Umgebung, die für schwere Katastrophenszenarien (über einen Ausfall auf Rechenzentrumsebene hinaus) vorgesehen ist. Diese Backup-Umgebung ist vollständig isoliert von der Produktionsumgebung. Die Backup-Umgebung kann aus der Produktionsumgebung lesen (aber nicht schreiben), während die Produktionsumgebung weder aus der Backup-Umgebung lesen noch in sie 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 umfassend die automatisierten Prozesse, die wir für unsere wöchentlichen Veröffentlichungen implementiert haben. Auf geschäftlicher Ebene beinhaltet der Notfallwiederherstellungsplan die Kontaktaufnahme mit jedem Kunden, den wir haben, in der Regel gemäß einem mit jedem vereinbarten Prozess. Für die meisten unserer Kunden fungieren die ernannten Supply Chain Scientists als primäre Ansprechpartner für die Dauer der Wiederherstellung.

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

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

Wir haben ein RPO von 1 Minute für Katastrophen auf Rechenzentrumsebene - wenn die Daten nicht kompromittiert sind. Dies erreichen wir durch die Nutzung geografisch redundanter Schreibvorgänge unseres persistenten Schlüssel-Wert-Speichers. Wenn der Schlüssel-Wert-Speicher kompromittiert ist, stellt Lokad von seinem Backup-Speicher wieder her (der so isoliert wie möglich von unseren Produktionssystemen gehalten wird), der ebenfalls an einem anderen geografischen Standort gehostet wird. In diesem Fall haben wir ein RPO von 12 Stunden.

3.10 Kann die Lösung Integritätsverletzungsalarme generieren? Hat die Lösung die Möglichkeit, Integritätsprüfungen hinzuzufügen oder zu erweitern, je nach Anforderungen?

Ja, obwohl diese Art von 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 Ereignisquellen-Design anstelle eines relationalen Designs. Dies bedeutet nicht, dass die Durchsetzung der Datenintegrität nicht erforderlich ist, aber diese Bedenken werden auf alternative Weise angegangen.

Wenn es um die Verarbeitung von Kundendaten geht, verfügt Envision (Lokads DSL) über umfangreiche Funktionen zur Überprüfung ihrer Qualität. Durch Envision ist es möglich, die Integrität zu überprüfen und Warnungen zu generieren. Diese Logik kann auf jede vom Kunden als angemessen erachtete Weise erweitert oder geändert werden.

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

Ja. Das Ereignisquellen-Design von Lokad in Verbindung mit seinem inhaltsadressierbaren Speicher macht es viel einfacher, die Funktionalität von Backup und Datenwiederherstellung zu testen als bei den meisten Mainstream-Designs, die relationale Datenbanken nutzen (wie SQL).

Siehe auch Vorfälle 3.7.

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

Ja. Die Bereitstellungsstrategie von Lokad nutzt durchgängig automatisierte Skripte und setzt bewusst sehr wenige menschliche Eingriffe ein - eine bemerkenswerte Ausnahme bildet die Möglichkeit, eine vollständige Produktionsneubereitstellung auszulösen. Dieser stark automatisierte Ansatz erleichtert die Testung der Funktionalität der Notfallwiederherstellung.

Siehe Vorfälle 3.8.

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

Ja. Unsere interne Toolunterstützung ermöglicht die Wiederherstellung eines ausgewählten Kundenkontos (einschließlich der Wiederherstellung des Kontos/der Umgebung zu einem bestimmten Zeitpunkt). Da die Lokad-Plattform selbst jedoch über umfangreiche Versionierungsfunktionen verfügt (z. B. sind Envision-Skripte versioniert, und frühere Versionen sind innerhalb der App zugänglich), wird diese Funktion selten genutzt.

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

Ja. Das Recovery Time Objective (RTO) bezieht sich hier auf die Zeit, die die Lokad-Plattform theoretisch ausfallen könnte, ohne dem Kunden erheblichen Schaden zuzufügen, sowie die Zeit, die für die Wiederherstellung der Plattform und ihrer Daten benötigt wird, damit sie nach einem erheblichen Vorfall den normalen Betrieb wieder aufnehmen kann.

Das RTO hängt sehr stark von den spezifischen Prozessen ab, die von Lokad unterstützt/bereitgestellt werden. Zum Beispiel könnte ein Kunde, der sich auf Lokad verlässt, um monatliche Übersee-Einkaufsaufträge zu planen, ein RTO von 1 Woche haben. Im Gegensatz dazu könnte ein Kunde, der sich auf Lokad verlässt, um die tägliche Lagerauslieferung von einem Lager an mehrere Geschäfte zu optimieren, ein RTO von 1 Stunde haben.

In der Praxis können verschiedene technische Notfallmaßnahmen ergriffen 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 die absolut aktuellsten Daten nutzen würden.

Für unsere betreuten Konten ist es die Aufgabe des Supply Chain Scientist bei Lokad, gemeinsam mit den operativen Teams des Kunden einen Prozess zu entwickeln, der ein hohes RTO gewährleistet, aber auch sicherstellt, dass im Falle eines tatsächlichen Vorfalls minimale Geschäftsauswirkungen entstehen. 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 Fehler in der Testumgebung nicht reproduzierbar ist, kann Lokad überprüfen, dass der Fehler aus Protokollen und unterstützenden Daten aufgetreten ist, und sicherstellen, dass der Fehler gemäß der Service Level Agreement (SLA) behoben wird?

Ja, Fehler 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), genau um dieses Problem anzugehen.

Es sei darauf hingewiesen, dass Protokolle effektiver für die Fehlersuche bei trivialen Problemen wie Serverausfällen sind. Wenn es jedoch um die Fehlersuche bei komplexen Problemen und Defekten in einer Datenumgebung im großen Maßstab geht, bei der Terabyte an Daten beteiligt sind, sind Protokolle oft unzureichend.

Daher, obwohl Lokad Protokolle pflegt und konsultiert, verlassen wir uns nicht auf Protokolle, um Fehler zu beheben oder zu überprüfen, ob Fehler gemäß den Vereinbarungen des Service Level Agreements behoben wurden. Stattdessen nutzen wir hauptsächlich überlegene Designentscheidungen, um mehr Einblick, Nachvollziehbarkeit und Reproduzierbarkeit zu bieten.

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

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

3.16 Werden alle Serviceanfragen und Serviceanrufe (einschließlich der Kategorie jedes Anrufs), die vom Kundenunternehmen getätigt werden, protokolliert? 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 Lokads quantitative Supply-Chain-Philosophie (QSC) darin besteht, den finanziell vorteilhaftesten Kompromiss zu finden, wenn ein Problem auftritt. QSC ist technisch gesehen kein “Problembehebungsansatz”, 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 Serverausfälle) auf einfache Weise schnell zu lösen. Wenn es um größere, bedeutendere 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 den Kunden darüber, welche Kompromisse ihren Return on Investment maximieren.

4. Architektur

4.1 Welche Programmiersprachen verwenden Sie?

Die Lokad-Plattform ist 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 Welches Entwicklungssuite verwenden Sie?

Lokads Softwareentwicklungsteams verwenden Microsoft Visual Studio. Die Supply-Chain-Wissenschaftler-Teams verwenden die Lokad-Plattform selbst, die über eine eigene Entwicklungssuite 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 haben (z. B. Firefox). 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 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 Abfassung dieses Textes (Januar 2023) verwenden wir Blob Storage, wie es von Microsoft Azure bereitgestellt wird.

4.5 Welches Cachingsystem verwenden Sie?

Lokad hat eigene Caching-Subsysteme in C#/.NET entwickelt. Diese Subsysteme 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 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 einer Person verfolgt. Darüber hinaus ist es hilfreich, wenn der Kunde etwas Erfahrung mit dem Extrahieren von Daten (als flache Dateien) aus seinen Transaktionssystemen hat, aber dies ist sicherlich keine Voraussetzung.

4.8 Listen Sie alle zusätzlichen Drittanbieterlizenzen auf, die zur Nutzung der Lokad-Lösung erforderlich sind (z. B. OS, SQL,…).

Nicht zutreffend. Lokad benötigt keine Drittanbieterlizenz(en) zur Nutzung. 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 Dienst Browser-Plug-Ins oder spezielle Software?

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

4.10 Was sind die Ein- und Ausgangsschnittstellen der Anwendung?

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

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

Die Lösung von Lokad 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 fordern wir Sicherheitsforscher (Personen, die Pentests durchführen) explizit auf, die Möglichkeit von Datenlecks zu untersuchen. Wir geben ihnen Zugriff auf mehrere 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 keinen Nutzen für die Containerisierung der Lokad-Plattform. Containerisierung bringt dann einen Mehrwert, wenn komplexe Abhängigkeiten vorhanden sind (z. B. eine Transaktionsdatenbank, ein isoliertes Cachingsystem usw.). Wir verwenden keine Container in der Produktion oder Entwicklung, was unsere Sicherheit verbessert, indem ganze Klassen von Schwachstellen eliminiert werden. Stattdessen halten wir die Lösung einfach genug, damit Bereitstellungen sogar mit kleinen Shell-Skripts durchgeführt werden können.

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 dazu bei, eine höhere Verfügbarkeit zu erreichen. Endbenutzer können auf ihre Lokad-Kontodashboards zugreifen, auch wenn ein plötzlicher Ausfall eines der anderen Subsysteme auftritt.

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

Ja, die Anwendung unterstützt Lokalisierungsfunktionen. Alle von der Lokad-Plattform erstellten Benutzeroberflächen können in jeder Sprache lokalisiert werden. Insbesondere verwendet der gesamte technologische Stack UTF-8, um alle Zeichencodierungen jenseits der lateinischen aufnehmen zu können. Insbesondere kann jede von der Lokad-Plattform erstellte Benutzeroberfläche - nach der Bereitstellung - in eine andere Sprache umgelokalisiert werden.

4.15 Können Endbenutzer nach der Bereitstellung 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 welchen Sprachen?

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.

Zunächst sind die in der Lokad-Lösung erstellten Dashboards dazu gedacht, kontextbezogen dokumentiert zu werden - direkt vom Dashboard aus. 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 Web-App responsiv?

Die Lokad-Web-App 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 unpraktisch. Das Design ist daher darauf ausgelegt, die Reaktionsfähigkeit für die geplanten Aktivitäten auf PCs und kleineren Geräten zu maximieren.

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

Lokad ist eine Web-App 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 implizit unsere(n) Kunden gefährdet. Kurz gesagt, ein anfälliger Browser kann von einem bösartigen Akteur genutzt werden, um Daten abzufangen. Trotzdem sind wir auch ziemlich konservativ, wenn es um neue Browserfunktionen geht. Als Faustregel vermeiden wir die Unterstützung von Browserfunktionen, die von allen wichtigen Webbrowsern nicht mindestens 1 Jahr lang übernommen wurden.

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

N/A. Da Lokad eine als SaaS bereitgestellte Web-App ist, sind unsere Kunden nicht auf die Betriebssystemunterstützung angewiesen. Intern wird Lokad unter Windows entwickelt, während unsere gesamte Produktions-Cloud-Umgebung unter Linux läuft. Daher sind wir ziemlich zuversichtlich in Bezug auf die breite Portabilität der Lokad-Lösung. Obwohl wir keinen gegenwärtigen Bedarf sehen, dieses Setup zu ändern, werden wir uns entsprechend anpassen, sollte sich gültiger Nachweis ergeben.

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

Ja, Lokad hat die Möglichkeit, Benachrichtigungen über programmierbare HTTP-Hook-Benachrichtigungen zu senden. Diese Hooks können genutzt werden, um ein E-Mail-Benachrichtigungssystem eines Drittanbieters, das häufig bereits im Unternehmen des Kunden vorhanden ist, zu verwenden, um eine E-Mail-Benachrichtigung oder einen beliebigen anderen Typ von Benachrichtigungen zu senden, die als angemessen erachtet werden. Die Hooks werden auch typischerweise verwendet, um die Verfügbarkeit von Daten zu signalisieren, die von der Lokad-Plattform über SFTP oder FTPS abgerufen werden können.

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

Ja, da Lokad eine Multi-Tenant-App ist, werden die Infrastruktur-Level-Fähigkeiten zwischen/über Mandanten, d.h. 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 eine Mehrziel-Messaging-Funktionalität (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. Wir bieten jedoch HTTP-Hook-Fähigkeiten, die verwendet werden können, um beliebig komplexe Nachrichtenbenachrichtigungen zu generieren, in der Regel über kostengünstige Systeme von Drittanbietern. Diese Benachrichtigungen werden manchmal von Lieferketten-Teams genutzt, um die rechtzeitige Fertigstellung von geschäftskritischen Berechnungschargen 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 Standard-NTP-Dienst, der mit Ubuntu geliefert wird - ntp.ubuntu.com. Genauer gesagt wird ntpd als Zeit-Synchronisationsdienst ausgeführt, der gegen eine externe NTP-Zeitquelle synchronisiert wird, die über das Netzwerk erreicht wird.

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

Ja, wir haben eine IT-Vermögensverwaltungssoftware, um unsere Prozesse zu unterstützen. Diese Plattform hilft uns dabei, eine umfassende Vermögensinventarliste zu führen und fungiert als unsere Konfigurationsverwaltungsdatenbank (CMDB). Durch dieses System können wir Hardware- und Softwarevermögenswerte effizient verfolgen, verwalten und zuweisen. Unsere Teams haben die Möglichkeit, den Status, den Standort und die Konfiguration eines Vermögenswerts schnell zu identifizieren, um schnelle Reaktionen auf Änderungen, Updates oder potenzielle Probleme zu gewährleisten.

Darüber hinaus bietet unser Tool Funktionen, die eine detaillierte Lebenszyklusverwaltung ermöglichen, um sicherzustellen, dass Vermögenswerte von der Beschaffung bis zum Ende ihres Lebenszyklus genau katalogisiert sind. Automatisierte Prüffähigkeiten in Verbindung mit detaillierten Berichtsfunktionen gewährleisten, dass wir die volle Sichtbarkeit und Kontrolle über unsere IT-Umgebung aufrechterhalten, was die Einhaltung und eine effiziente Ressourcenzuweisung erleichtert.

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 Frontlinienschutz angesehen werden, ironischerweise die Angriffsfläche erweitern. Je mehr Komponenten und Systeme wir integrieren, desto mehr potenzielle Schwachstellen führen wir ein. Firewalls, aufgrund ihrer Natur, arbeiten als Prozesse mit hohen Privilegien. Das bedeutet, dass sie Hauptziele für Cyberangriffe werden und wenn sie kompromittiert sind, können die Ergebnisse verheerend sein. Ein anschauliches Beispiel ist der SolarWinds-Angriff, bei dem die Systeme, die dazu gedacht waren, Informationen zu schützen, ausgenutzt wurden, was zu erheblichen Sicherheitsverletzungen führte.

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

Daher ist unser Ansatz zur Sicherheit zwar tiefgreifend, aber ganzheitlich und 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 Remotezugriff) sowie Kundendaten überträgt, verarbeitet oder speichert?

Nein, Lokad verwendet keine traditionelle DMZ-Umgebung in unserem Netzwerk, um kritische Systeme und Kundendaten zu übertragen, zu verarbeiten oder zu speichern. Stattdessen haben wir einen Zero-Trust-Ansatz zur Netzwerksicherheit übernommen.

Dieses Modell verlässt sich nicht auf DMZs, sondern basiert 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 auf Perimeterschutz wie einer DMZ beruht, sondern sich stattdessen auf die Sicherung jedes einzelnen Zugriffspunkts und Datenverkehrs konzentriert. Wir glauben, dass der Zero-Trust-Ansatz einen überlegenen Schutz für unsere kritischen Systeme und Kundendaten bietet.