Lokad aus der IT-Perspektive

Lokads App ist eine Webanwendung, die als Saas (Software as a Service) angeboten wird. Das Ziel Lokads besteht darin, prädiktive Analysen zur Optimierung der Supply-Chain (bessere Bestandszahlen, bessere Preise, usw.) zu liefern. Lokads App ist als analytische Ebene gedacht, die parallel zu den Transaktionssystemen (ERP, LVS, CRM, etc.) läuft. Angeboten wird sie als monatliches Abo für einen Pauschalbetrag, der App und professionelle Dienstleistungen umfasst. Diese Dienstleistungen werden von Lokads Ingenieuren (Supply-Chain-Scientists) ausgeführt und decken praktisch den gesamten Bedarf an technischen Support ab, der in der IT-Abteilung in diesem Zusammenhang aufkommen kann. Der Hauptbeitrag, der von der IT-Abteilung erwartet wird, ist die Einrichtung einer Daten-Pipeline und die Übersendung der Flatfiles (per SFTP oder FTPS) an Lokad, sowie ggf. die Wiedereinbindung der erzeugten Ergebnisse.

Zielpublikum: Die IT-Abteilung
Zuletzt geändert: 27. Januar 2023

Technischer Überblick

Lokads Anwendung ist mandantenfähig. Jeder Mandant (also jedes Kundenkonto) hat sein eigenes dediziertes Dateisystem und sein eigenes Repository für die Codebasis. Das Dateisystem ist über FTPS, SFTP und eine Webschnittstelle zugänglich. Dieses Dateisystem ist auf große Flatfiles (bis zu 100 GB pro Datei) ausgerichtet und bietet Versionisierung an (wie Git). Das Repository für die Codebasis wird für das Hosting der Envision-Skripte genutzt. Envision ist eine von Lokad entwickelte proprietäre DSL (domänenspezifische Sprachen Programmiersprache). Diese DSL ist besonders auf die prädiktive Optimierung spezialisiert. Envision-Skripte werden zur Ausführung numerischer Analysen (auch für maschinelles Lernen, Algorithmen, Löser, etc.) und zur Erstellung datenreicher Dashboards genutzt.

Die App wird jeden Dienstag zwischen 10:00 und 14:00 Uhr (MEZ) erneut bereitgestellt. Die Betriebsunterbrechung liegt gewöhnlich bei unter 5 Minuten. Lokad kümmert sich um alles rund um die Versionisierung.

Es wird nicht erwartet, dass sich die IT-Abteilung besondere Kompetenzen im Bezug zu Lokads Stack aneignet. Doch, wenn Sie neugierig sind, steht Ihnen auch eine komplette technische Dokumentation zur Verfügung.

Beitrag der IT im Überblick

Von der IT-Abteilung erwarten wir lediglich, dass sie eine Daten-Pipeline einrichtet und ein paar Flatfile extrahiert, die sie Lokad per SFTP bzw. FTPS zukommen lässt. Die Exporte werden über die transaktionalen Systeme durchgeführt (z. B.: ERP). Hierbei bevorzugen wir reine Tabellenextraktionen (ohne Filter, Zusammenführung oder Transformation), die sehr wenig Aufwand bedürfen. Aus der ETL-Perspektive wird das „E“ (extract) in seiner einfachsten Form (einfache Kopie) benötigt. Was die Formatierung betrifft, ist Lokad mit jedem gängigen Tabellen Flatfile-Format kompatibel.

Die Datenpipeline sollte mindestens täglich laufen und komplett automatisiert sein. Das Arbeitsvolumen der IT-Abteilung hängt daher vom Umfang der Datenextraktion (Systeme, Tabellen) ab. Als Faustregel gilt, dass die Einrichtung der Datenpipeline gewöhnlich sogar bei großen Unternehmen 15-45 Personentage in Anspruch nimmt. Sobald die Datenpipeline funktioniert, benötigt Lokad von der IT-Abteilung nur noch ein Mindestmaß an Monitoring, das auf 1 bis 2 Personentage im Monat beziffert wird.

Sicherheit im Überblick

Die App wird in Rechenzentren von Microsoft Azure in der EU gehostet. Wir bearbeiten keine personenbezogenen Daten, da wir sie für unseren Betrieb nicht benötigen. Bei der Festlegung des Umfangs der Datenextraktion schließen wir jegliche Spalten und Felder aus, die personenbezogene Daten enthalten könnten.

Für die Authentifizierung bevorzugen wir SAML. Wir empfehlen den Zugriff der Nutzer auf Lokad über federated identities, wie etwa ein Azure Active Directory, Office 365 oder Google Workspace. Dies beugt auch Probleme im Zusammenhang mit Passwörtern vor.

Auf Anfrage können unsere Kunden Sicherheitsaudits und Penetrationstests durchführen. Die Details hängen von der ausgehandelten Vereinbarung ab.

Mehr Information finden Sie unter Sicherheit bei Lokad.

Zeitplan im Überblick

Die Quantitative Supply-Chain ist eher als Weg statt als Ziel für sich zu betrachten. Gleichzeitig benötigen die Verantwortlichen für die Lieferkette, die im Unternehmen die Durchführung eines Projekts zur quantitativen Supply-Chain anstoßen, Sichtbarkeit, wenn es um den Zeitplan des Projekts geht. Während positive Renditen innerhalb weniger Monate erzielt werden können, kann es häufig bis zu zwei Jahre dauern, das volle Potenzial der quantitativen Supply-Chain zu schöpfen. Im Folgenden geben wir Ihnen einen Überblick über einen üblichen Zeitplan eines Projekts zur quantitativen Supply-Chain in einem mittelständischen Unternehmen. Bei großen Unternehmen sollte von einem doppelt so langen Zeitplan ausgegangen werden.




Kick-off des Projekts: Vertreter beider Parteien stellen sich gegenseitig vor und vereinbaren wöchentliche Treffen. Diese wöchentlichen Treffen werden gehalten, bis die Produktionsphase erreicht ist. Der Supply-Chain-Scientist stellt die verschiedenen Implementierungsphasen und Ergebnisse vor, die der Kunde erwarten kann. Der Rest des Gesprächs ist der Überprüfung verschiedener Details der Lieferkette und IT-Merkmale der Integration gewidmet. Nach dem Telefonat wird eine Zusammenfassung erstellt, in der die organisatorischen Aspekte des Projekts dokumentiert werden. Diese wird dem Kunden zugeschickt.

Datenspezifikationen: Kurz nach dem Kickoff-Meeting erstellt der Supply-Chain-Scientist die für die Umsetzung des Projekts erforderlichen Datenspezifikationen. Diese werden zusammen mit dem Kunden überprüft und validiert. In diesem Dokument werden insbesondere die Daten definiert, die aus den IT-Systemen des Kunden extrahiert werden sollen. Als Faustregel gilt, dass sich die Extraktion so nah wie möglich an den Originaldaten orientieren soll, wie sie in den IT-Systemen des Kunden vorliegen.

1. Daten-Upload: Nach der Validierung der Spezifikationen wird der erste Datensatz vom Kunden auf Lokads Server hochgeladen. In der Regel erfolgt der Upload in diesem Stadium noch nicht über einen automatisierten Prozess. Gewöhnlich sind mehrere Anläufe erforderlich, um einen Konsens über die Details der Datenspezifikation zu erreichen.

Validierung der Daten: Der Supply-Chain-Scientist untersucht den Inhalts des Datensatzes des Kunden ausführlich. Insbesondere werden Sanity Checks eingeführt, um die Qualität der Daten anhand mehrerer Metriken zu überwachen. Ziel ist es, sicherzustellen, dass: 1. der Datensatz durch den Upload-Prozess richtig aktualisiert wird, 2. der Datensatz die Realität des Unternehmens korrekt widerspiegelt und 3. der Datensatz kohärent und vollständig genug für die Optimierung der Lieferkette ist.

In dieser Phase stellt der Supply-Chain-Scientist dem Kunden verschiedene Dashboards zur Verfügung, die den Zustand der Daten bewerten. Diese Dashboards können vom Kunden auch für weiterführende Zwecke, abgesehen von dem Projekt zur quantitativen Supply-Chain, etwa als Teil der internen Qualitätssicherung der Daten.

Audit zur Projekthalbzeit: 6 Wochen nach Kick-off wird ein Treffen anberaumt, um den Stand des Projekts zu bewerten. Ziel dieses Audits ist es, so früh wie möglich Probleme anzugehen, die während der Implementierung auftreten können, insbesondere solche, die zur Verzögerung der Produktionsphase führen könnten. Bei Lokad umfasst dieses Audit einen Austausch zwischen dem Supply-Chain-Scientist und dem Kunden auf der Grundlage einer Checkliste, die der Supply-Chain-Scientist dem Kunden direkt nach dem Kick-off-Meeting zukommen lässt.

Automatisierung des Uploads: Sobald beide Parteien die Gesamtqualität des bisher hochgeladenen Datensatzes validiert haben, implementiert der Kunde einen automatisierten Prozess, über den seine Datensätze regelmäßig, idealerweise täglich, an Lokad übertragen werden. Gleichzeitig wird bei Lokad die Logik für den Zustand der Daten, mit ihren zahlreichen Prüfungen, nach jedem Upload aktualisiert.

Einrichten der Optimierung: Ab diesem Zeitpunkt verfügt der Supply-Chain-Scientist über alle notwendigen Bestandteile, um die Optimierung von Entscheidungen, die zuvor mit dem Kunden vereinbart wurden, umzusetzen. Daher implementiert er Skripte, um verschiedene quantitative Ausgaben zu generieren: operative Vorschläge für den Einkauf, für den Versand usw. Die von diesen Skripten erzeugten Zahlen können in Form eines Dashboards visualisiert werden. Zu diesem Zeitpunkt stellen die Dashboards nur eine vorläufige Version der endgültigen Dashboards dar und müssen zusammen mit dem Kunden geprüft werden.

Feedback & Feinabstimmung: Die Wünsche des Kunden, die verschiedenen Ergebnisse auf eine gewisse Weise anzupassen oder zu optimieren, führen in der Regel zur Feinabstimmung der vom Supply-Chain-Scientist geschriebenen Skripte. Dabei können viele Parameter und Methoden eingesetzt werden, um die Eigenschaften der zu optimierenden Lieferkette mit der Optimierungslogik in Einklang zu bringen. Ist die Methodik selbst von strategischer Bedeutung für den Kunden, wird diese ausdrücklich zwischen dem Kunden und dem Supply-Chain-Scientist besprochen.

Produktion: Nach mehreren Durchläufen zwecks Feinabstimmung und Überarbeitung gelangt der Kunde an einem Punkt, an dem er der vom Supply-Chain-Scientist implementierten Logik vertrauen kann. Ab diesem Zeitpunkt kann der Kunde den Dienst produktiv nutzen, d. h. er kann die von der Software berechneten Entscheidungen zur Lieferkette direkt ausführen. Wenn der Kunde bestätigt, dass die Lösung produktionsreif ist, liefert der Supply-Chain-Scientist eine Dokumentation, mit der die Wartbarkeit der Lösung gewährleistet wird.

Support & Wartung: Die Lösung ist betriebsbereit und wird vom Kunden genutzt, während der Supply-Chain-Scientist die reibungslose tägliche Ausführung der Datenpipeline überwacht. Es finden regelmäßig Telefonate zwischen dem Kunden und dem Supply-Chain-Scientist statt, um zu überprüfen, ob durch die Optimierung die erwartete Supply-Chain-Performance erreicht wird. Außerdem sind Lieferketten nicht statisch, so dass kleine oder große geschäftliche oder IT-technische Änderungen überprüft werden müssen, wie etwa ein neues Lager, eine Marktveränderung, ein neuer Prozess usw. Der Supply-Chain-Scientist schlägt geeignete Anpassungen vor, um die verschiedenen Veränderungen zu berücksichtigen. Es werden Anrufe zur Kontrolle sowie deren Rhythmus, in der Regel monatlich, vereinbart und durchgeführt.

Häufig gestellte Fragen (FAQ)

Technischer Überblick    Beitrag der IT im Überblick    Sicherheit im Überblick    Zeitplan im Überblick    Häufig gestellte Fragen (FAQ)     1. Release-Management       1.1 Wie funktionieren Releases bei Lokad?       1.2 Wie häufig finden Releases statt?       1.3 Besteht ein Plan für die kommenden Releases?       1.4 Geht eine Versionsänderung mit einer Neuinstallation einher oder nur mit einem Patch?       1.5 Wie viel Zeit braucht die Umsetzung einer Hauptversion?       1.6 Wer ist für die korrekte Durchführung des Releases verantwortlich?       1.7 Gibt es während des Releases eine Ausfallzeit?       1.8 Wie sieht Ihr Testprozess oder Ihre Teststrategie für ein Release aus?       1.9 Haben Sie mehrere Umgebungen?       1.10 Wie viele verschiedene Versionen können nebeneinander existieren?       1.11 Kann ein Kunde einen Release ablehnen?       1.12 Haben Sie Versionshinweise? Stellen Sie sie Ihren Kunden zur Verfügung?       1.13 Wie kann ein Kunde eine Weiterentwicklung der Lösung beantragen?     2. Performanz       2.1 Enthält Ihre Dienstleistungsvereinbarung eine Verfügbarkeit von 99,xy %?       2.2 Garantieren Sie eine Antwortzeit für Benutzeranfragen innerhalb von X Sekunden?       2.3 Haben Sie Protokolle zu den Performance-Audits?       2.4 Können langsame Antworten oder Überlastungen überwacht werden?       2.5 Verfügen Sie über Leistungsverteiler?       2.6 Poolen Sie Ressourcen wie DB-Verbindungen, Sitzungen usw.?       2.7 Unterstützen Sie die Parallelverarbeitung?       2.8 Unterstützen Sie die Zwischenspeicherung von Daten, auf die häufig zugegriffen wird?       2.9 Komprimieren Sie Daten, um den Netzwerkverkehr zu reduzieren?       2.10 Führen Sie Leistungstests durch?       2.11 Überwachen Sie die Leistung auf Transaktionsebene?       2.12 Wie wirkt sich die gleichzeitige Nutzung der Lösung durch mehrere Benutzer auf die Leistung aus?       2.13 Ist das System so konzipiert, dass es vertikal und horizontal skaliert werden kann?       2.14 Skalieren Sie Rechenleistung und Speicherplatz automatisch nach Bedarf?       2.15 Wie verwaltet Ihre Anwendung die Anforderungen von Big Data ?       2.16 Kann Lokads Cloud-basierte Lösung unter Berücksichtigung straffer (kundenseitiger) Bedingungen zu Bandbreite und Latenz konfiguriert werden? Zum Beispiel: Bandbreite = 3 Mbps (Download) / 1Mbps (Upload), Latenz = 600-800 ms     3. Vorfälle       3.1 Wie kann ein Kunde einen Vorfall melden?       3.2 Bieten Sie ein Ticketsystem an?       3.3 Unterstützen Sie die Meldung von Vorfällen an Tools von Drittanbietern?       3.4 Wie stellen Sie eine hohe Verfügbarkeit sicher?       3.5 Verfügen Sie über eine redundante Infrastruktur (wenn ja, in welcher Hinsicht)? Vermeiden Sie einzelne Fehlerquellen?       3.6 Wie erholen Sie sich von Hardwarefehlern?       3.7 Haben Sie ein Backup?       3.8 Verfügen Sie über einen Plan zur Notfallwiederherstellung?       3.9 Unterstützt die Lösung Point-in-Time-Wiederherstellung (PITR) für Datenbanken und Daten außerhalb der Datenbank? Was ist das Recovery Point Objective (RPO) der Lösung?       3.10 Ist die Lösung in der Lage, Warnungen bei Integritätsverletzungen zu erzeugen? Können Integritätsprüfungen je nach Bedarf in der Lösung hinzufügt oder erweitert werden?     4. Architektur       4.1 Welche Programmiersprachen verwenden Sie?       4.2 Welche Development Suite verwenden Sie?       4.3 Welche Betriebssysteme unterstützen Sie?       4.4 Welches Datenbanksystem verwenden bzw. unterstützen Sie?       4.5 Welches Caching-System verwenden Sie?       4.6 Wie geht die Lösung mit Zertifikaten um?       4.7 Was sind die technischen Voraussetzungen für die Nutzung der Lösung?       4.8 Führen Sie alle zusätzlichen Lizenzen von Drittanbietern auf, die für den Betrieb von Lokads Lösung erforderlich sind (z. B. Betriebssystem, SQL, etc.).       4.9 Benötigt der Dienst Browser-Plugins oder besondere Software?       4.10 Welche ein- und ausgehenden Schnittstellen hat die Anwendung?       4.11 Wie wird sichergestellt, dass es zu keinen Datenlecks zwischen den Mandanten kommt?       4.12 Kann die Lösung containerisiert werden?       4.13 Können die GUI-Komponenten vom Backend entkoppelt werden?       4.14 Unterstützt Lokads Anwendung Lokalisierungsfunktionen (wie z. B. die Änderung der Sprache)?       4.15 Können Endnutzer nach der Lieferung von nachbearbeiteten Daten von Lokad neue Übersetzungen erstellen oder aktualisieren?       4.16 Verfügt Ihr System über eine eingebaute Hilfe ? Wenn ja, in welcher/welchen Sprache/n?       4.17 Ist die Webanwendung responsive?       4.18 Wenn Ihr System eine Webanwendung ist, welche Browser und Versionen unterstützen Sie? Was ist der Mindeststandard für den Internetbrowser?       4.19 Welche Betriebssysteme (und Versionen) werden von Lokad für mobile und Tablet-Anwendungen unterstützt?       4.20 Kann Lokads Webanwendung Benachrichtigungen für Endbenutzer bereitstellen? Wenn ja, über welche Technologie/welches Protokoll?

1. Release-Management

1.1 Wie funktionieren Releases bei Lokad?

Lokad wickelt alle Releases intern ab, was den Kunden komplette Transparenz bietet. Alle Releases, die sich auf einen Kunden auswirken könnten, werden mit diesem über die Technik-Teams des Kunden, lange im Voraus abgestimmt. Im Allgemeinen geht Lokad bei Releases mit Vorsicht vor: Sollte ein geplantes Release dem Kunden nicht genügend Vorlauf bieten, wird es vorübergehend verschoben.

Lokads Releases sind sehr granular sie erlauben normalerweise Kunden vom Design her, ein bestimmtes technisches Element eine kompletten Releases zu überspringen. So können wir das allgemeine Release bereits umsetzen, auch wenn die Umsetzung eines Elements verschoben werden muss, bis unser Kunde bereit ist (und die anderen Elemente implementieren, die keine Schwierigkeiten bereiten).

1.2 Wie häufig finden Releases statt?

Lokad veröffentlicht jeden Dienstag eine neue Version, gewöhnlich gegen 11 Uhr (MEZ).

1.3 Besteht ein Plan für die kommenden Releases?

Ja, siehe Release-Management 1.2.

1.4 Geht eine Versionsänderung mit einer Neuinstallation einher oder nur mit einem Patch?

Lokad führt automatisiert (durch Skripte) ein neues Deployment seiner eigenen Lösung durch. Wir patchen keine produktiven Systeme. Sofern wir einen „Sicherheits-Patch“ bereitstellen müssen, bieten wir ein erneutes Deployment der Lösung wie gewöhnlich automatisiert.

1.5 Wie viel Zeit braucht die Umsetzung einer Hauptversion?

Der automatisierte Prozess dauert etwa 1 Stunde. Das Rollout erfolgt schrittweise (Maschine für Maschine), da wir unsere Plattform während der Einführung operativ und zugänglich halten möchten. Die Funktionsfähigkeit während eines Rollouts wird unter Release-Management 1.7 besprochen.

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

Lokads 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 bitte, dass Lokads Lösung ein verteiltes System ist, das für große Berechnungen bestimmt ist. Daher sind die Auswirkungen eines Releases auf Front- und Back-End-Systeme unterschiedlich. Kundenseitige Untersysteme, wie z. B. Dashboards, sind so konzipiert, dass es keine Ausfallzeiten gibt. Backend-Systeme, die etwa für die Ausführung von Batch-Aufgaben zuständig sind, werden möglicherweise für ein paar Minuten angehalten (zumindest für einige Aufgaben). Diese Batch-Aufgaben können jedoch eingeplant werden, so dass eine proaktive Planung die Fertigstellung von Batch-Aufgaben außerhalb des Zeitfensters für den Release ermöglichen sollte.

1.8 Wie sieht Ihr Testprozess oder Ihre Teststrategie für ein Release aus?

Lokad nutzt automatisierte Prozesse, um die Richtigkeit einer neuen Version zu testen und sicherzustellen. Diese Prozesse umfassen umfangreiche automatisierte Tests (die in die Tausende gehen), wie Modultests, Funktionstests, Leistungstests, usw. Außerdem haben wir auch dezidierte Tools entwickelt, mit denen wir ganze Sequenzen durchgeführter Aufgaben innerhalb der Lokad Plattform reproduzieren können. Mit diesen Tools können wir überprüfen, ob das Verhalten der Envision-Skripte vor und nach einer neuen Version gleich bleibt. Außerdem können wir kontrollieren, ob die Leistungsprofile bestehender Skripte weiterhin die von unseren Kunden definierten Erwartungen bzgl. des Zeitplans erfüllen.

1.9 Haben Sie mehrere Umgebungen?

Ja, die alternativen Umgebungen (auf Plattformebene, neben der Produktionsumgebung) sind jedoch in der Regel nicht für unsere Kunden bestimmt. Neben der Produktionsumgebung und den vorübergehenden Entwicklungsumgebungen haben wir eine „Evergreen-Umgebung“, die der letzten stabilen Version unserer Codebasis entspricht. Damit wird eine bestimmte Teilmenge unserer automatisierten Testverfahren validiert. Unsere Kunden können Zugang auf unsere „Evergreen-Umgebung“ erhalten, um zu überprüfen, ob sich eine bestimmte neue Version wie erwartet verhält. Dazu kann es kommen, wenn eine IT-Integration zwischen Lokad und dem Kunden ansteht. In der Praxis kommt dies jedoch nur selten vor.

Sollen mehrere Varianten von Envision-Skripten (parallel) ausgeführt werde, dann kann ein Lokad-Konto in mehrere „Umgebungen“ aufgeteilt werden. Sollen jedoch Tests durchgeführt werden, kann ein zweites Lokad-Konto für vorübergehende Testzwecke bereitgestellt werden. Bei dem zweiten Ansatz bleibt das primäre (produktiv verwendete) Kundenkonto von diesen Tests isoliert.

1.10 Wie viele verschiedene Versionen können nebeneinander existieren?

Lokad ist ein mandantenfähiges SaaS, das für alle Kunden dieselbe Version bereitstellt. Lokad bietet jedoch die Möglichkeit, so viele eindeutige Versionen bereitzustellen, wie vom Kunden gewünscht.

1.11 Kann ein Kunde einen Release ablehnen?

Da es sich bei Lokad um ein mandantenfähiges SaaS handelt, das für alle Kunden dieselbe Version verwendet, ist es nicht möglich, eine Version abzulehnen. Aus geschäftlicher Sicht ist dies jedoch irrelevant, da jede „Änderung“ durch die Ausführung von Envision-Skripten innerhalb der Lokad Lösung umgesetzt wird.

Siehe Release-Management 1.1 zu Fällen, in denen ein Release vorübergehend verschoben werden kann.

1.12 Haben Sie Versionshinweise? Stellen Sie sie Ihren Kunden zur Verfügung?

Ja. Diese Hinweise werden intern geteilt (mit unseren Team von Supply-Chain-Scientists). Wenn im Rahmen eines Vertrags ausdrücklich vereinbart, kann dem Kunden Zugang auf diese Versionshinweise gewährt werden. In der Praxis sind die Versionshinweise der Lokad Plattform nur interessant, wenn man mit dem Envision-Code arbeitet.

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

Die meisten unserer Kunden profitieren von unserem „Software + Experten“ Angebot, bei dem ein Team von Lokads Supply-Chain-Scientists für die Implementierung und Wartung der Supply-Chain-Lösung eines Kunden verantwortlich ist. Dies nennt sich „Supply-Chain as a Service“. Bei diesem Angebot ist der Kunde routinemäßig mit einem Supply-Chain-Scientist (bzw. mit mehreren) im Kontakt. Außerdem profitieren die meisten Kunden von einem wöchentlichen oder monatlichen Lenkungsausschuss, in dem der aktuelle Stand der Lösung und alle gewünschten Entwicklungen besprochen werden. Lokad setzt diese Methode ein, um alle Anfragen zu sammeln und einen Fahrplan für die Umsetzung der Änderungen vorzuschlagen.

2. Performanz

2.1 Enthält Ihre Dienstleistungsvereinbarung eine Verfügbarkeit von 99,xy %?

Ja. Die Dienstleistungsvereinbarung ist Teil unserer Standardvertragsvereinbarung. Der Begriff der Verfügbarkeit im Zusammenhang mit einem verteilten Computersystem, das der prädiktiven Optimierung von Supply-Chains dient, ist jedoch komplex. Betrachten Sie folgende Szenarien: - Lokad erhält die Kundendaten (ein täglicher Schritt) 2 Stunden später als geplant. Dies kann die gewöhnliche Effizienz unserer Heuristiken für die Ressourcenallokation sehr wohl stören. Dies wiederum kann die Zeit verlängern, die für die Ausführung von Lokads Batch-Aufgaben benötigt wird (z. B. 75 Minuten statt der üblichen 60). Manche mögen dies als 15-minütige Ausfallzeit betrachten, das entzieht sich jedoch unserer Kontrolle.

- Lokad erhält dieselben Kundendaten pünktlich, aber die Daten weisen einen erheblichen Rückgang der Lagerbestände auf. Dies würde eine Unterbrechung der (Lokad-seitigen) Batch-Aufgaben auslösen und einen Supply-Chain-Scientist dazu führen, das Problem zu untersuchen. Der Supply-Chain-Scientist sieht, dass ein automatischer Nachschubauftrag so groß wie nie zuvor ist. Der Supply-Chain-Scientist entscheidet, dass eine direkte Prüfung durch den Kunden erforderlich ist. Am nächsten Tag bestätigt der Kunde , dass die Bestandsdaten beschädigt waren und zu einer großen Bestandsabschreibung geführt hätten. Manche mögen dies als 24-stündige Ausfallzeit betrachten, aber das erscheint in diesem Zusammenhang schwer verständlich.

Die größte Gefahr für eine Lösung zur Optimierung der Lieferkette besteht nicht darin, ein bisschen zu spät dran zu sein, sondern ganz daneben zu liegen. Sobald eine Entscheidung in der Lieferkette getroffen wurde, wie zum Beispiel die (irrtümliche) Auslösung einer Produktionscharge, kann es äußerst kostspielig sein, diese wieder rückgängig zu machen. Deshalb empfehlen wir unseren Kunden, sich nicht willkürlich an isolierten Indikatoren zu orientieren, da diese Haltung die Mitarbeiter zu minderwertigeren Ergebnissen verleiten kann, solange diese scheinbar einen KPI (wie x,y % Betriebszeit) erfüllt.

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

Ja, unter 500 ms, aber mit Vorbehalt.

Wir haben etwas entwickelt, das in etwa auf „konstante Dashboards “ hinausläuft. Im Hintergrund erfordert die Anzeige eines Dashboards eine einzige Anfrage über das Netzwerk. In unserem Backend legen wir alle Dashboard-Daten zusammen, um die Anzahl an Netzwerkanfragen niedrig zu halten (normalerweise im einstelligen Bereich). Dieses Design trägt wesentlich dazu bei, eine geringe Latenzzeit für typische Benutzeranfragen zwecks Anzeige eines Dashboards zu „garantieren“. Somit wird auch verhindert, dass das Dashboard mit Kacheln überfüllt wird, die jeweils einzelne Netzwerkanfragen erfordern würden, und die Benutzererfahrung insgesamt verlangsamt wird.

Was die Dauer von Batch-Aufträge betrifft, können wir mit Envision zur Kompilierungszeit garantieren, dass ein Batch-Auftrag abgeschlossen wird. Außerdem können wir auch für unsere Batch-Aufträge weitgehend reproduzierbare Fertigstellungszeiten garantieren. Diese Garantien können durch statische Analysen und ein sorgfältiges Design der Envision-Sprache erreicht werden, die bestimmte Arten statischer Analysen überhaupt erst ermöglichen. Dieser Ansatz hat zwar seine Grenzen, ist jedoch Designs, die keinerlei Garantien bieten, weit überlegen.

Die End-to-End-Latenz liegt jedoch nicht ganz in unserer Hand. So haben wir beispielsweise keine Kontrolle über die Qualität der von unseren Kunden verwendeten Internetverbindung. Das Herunterladen einer großen Kalkulationstabelle von Lokad über ein Netzwerk mit geringer Bandbreite nimmt einige Zeit in Anspruch.

2.3 Haben Sie Protokolle zu den Performance-Audits?

Ja. Wir sammeln sehr detaillierte Leistungsprotokolle für alle betroffenen Rechenressourcen: CPU, Arbeitsspeicher, Speicherplatz, Bandbreite, usw. Diese Leistungsprotokolle werden unter anderem dafür verwendet, um sicherzustellen, dass eine neue, noch nicht veröffentlichte Version der Plattform den Erwartungen in Bezug auf die Leistung entspricht. Dies testen wir, indem wir die Leistung der neuen Version mit der Leistung früherer Versionen aus diesen Protokollen vergleichen.

2.4 Können langsame Antworten oder Überlastungen überwacht werden?

Ja. Lokads Plattform verfügt über einen internen Scheduler, der die rechtzeitige Ausführung von Batch-Aufträgen verfolgen kann. Lokads Design gewährleistet weitgehend eine konstante Antwortzeit für alle Anfragen, mit Ausnahme der lang laufenden Vorgänge, die als Batch-Aufträge behandelt werden.

Da es sich bei Lokad um eine mandantenfähige Plattform handelt, ist ein Großteil der Leistungsüberwachung für unsere Kunden nicht direkt zugänglich (da die Leistung der Plattform als Ganzes abdeckt wird). Wie zu erwarten, wird die Leistung unserer Plattform kontinuierlich von Lokads Teams überwacht.

2.5 Verfügen Sie über Leistungsverteiler?

Ja. Lokads Leistungsverteiler sind in erster Linie mehr für die Zuverlässigkeit als für die Leistung gedacht. Die Leistungsverteilung auf Netzwerkebene erfolgt über die Netzwerkschicht der von uns verwendeten Cloud-Computing-Plattform (Microsoft Azure). Die Verteilung der internen Datenverarbeitungslast, wie sie von Lokads Plattform gehandhabt wird, wird jedoch nicht über Leistungsverteiler verwaltet, sondern über einen internen Orchestrator, der mit unserem Compiler-Stack verbunden ist.

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

Ja. Die Funktionsfähigkeit von Lokads Plattform ist jedoch nicht auf eine Transaktionsdatenbank angewiesen. Deshalb bestehen keine DB-Verbindungen zum Poolen. Nichtsdestotrotz poolen wir viele andere Ressourcen, wenn es aus Sicht der Leistung sinnvoll ist.

2.7 Unterstützen Sie die Parallelverarbeitung?

Ja. Envision, unsere DSL, wurde um das Konzept der automatischen parallelen Ausführung herum entwickelt. Lokads Plattform nutzt auf mehreren Ebenen aktiv Parallelisierung: auf der Ebene des CPU-Kerns durch SIMD-Operationen (Single Instruction/Multiple Data), auf CPU-Ebene durch Multi-Thread-Ausführungen und auf der Clusterebene durch verteiltes Rechnen. Da die Parallelverarbeitung ein zentraler Aspekt von Envisions Design ist, profitiert praktisch die Gesamtheit der auf Lokads Plattform ausgeführten Workloads von einer umfassenden Parallelisierung, und zwar standardmäßig, ohne besonderen Aufwand für unsere Kunden oder unsere Supply-Chain-Scientists.

2.8 Unterstützen Sie die Zwischenspeicherung von Daten, auf die häufig zugegriffen wird?

Ja. Die Zwischenspeicherung wird jedoch häufig als Workaround für die Leistungseinschränkungen transaktionaler Datenbanken eingeführt. Da Lokads Plattform keine transaktionalen Datenbanken umfasst, verwenden wir Caching nicht zu diesem Zweck.

2.9 Komprimieren Sie Daten, um den Netzwerkverkehr zu reduzieren?

Ja, wir komprimieren einen Großteil des Netzwerkverkehrs. Wir können jedoch nicht alles komprimieren, da dies eine Sicherheitslücke darstellen würde, die als BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) bekannt ist. Ein BREACH liegt vor, wenn folgende 3 Faktoren gegeben sind:

1. Eine Antwort wird komprimiert.

2. Eine Antwort enthält ein Geheimnis.

3. Eine Antwort enthält eine Zeichenfolge, die von dem Angreifer, der die Anfrage erstellt hat, aufgenommen werden kann.

Um sich gegen BREACH zu schützen, deaktiviert Lokad die Komprimierung bei allen Antworten, bei denen die dritte Bedingung erfüllt ist. Zudem werden Daten auch aus anderen Gründen als zur Reduzierung des Netzwerkverkehrs komprimiert: erstens, um die Kosten für die Datenspeicherung zu senken, und zweitens, um Verzögerungen bei den Berechnungen zu verringern.

2.10 Führen Sie Leistungstests durch?

Ja. Lokad verfügt über eine umfangreiche automatisierte leistungsorientierte Schicht für die Instrumentierung. Mit diesen Tools können wir vor jeder Veröffentlichung das Leistungsdelta der kommenden Version im Vergleich zu der aktuell eingesetzten Version bewerten. Damit können wir dieselben Workloads, wie sie in der Produktion zu beobachten sind, reproduzieren und die daraus resultierende Leistung überwachen. Und zwar nicht nur nach klassischer Zeit, wie sie von einer Uhr gemessen wird, sondern unter Berücksichtigung aller relevanten Rechenressourcen (Speicher, Bandbreite, Eingabe/Ausgabe, CPU, usw.).

2.11 Überwachen Sie die Leistung auf Transaktionsebene?

Ja. Da Lokads Plattform jedoch keine Transaktionsdatenbank verwendet, gibt es keine „Transaktionen“, die, im herkömmlichen Sinne, überwacht werden müssen. Das ähnlichste Äquivalent ist die Ausführung von Envision-Skripten. Bei diesen Skripten überwachen wir die Leistung auf einer sehr detaillierten Ebene. Das entspricht in etwa der Überwachung des Kleingedruckten zur Ausführung eines Auswertungsplans (aus der Perspektive einer transaktionalen Datenbank).

Siehe Autorisierung 3.6 und Protokollierung und Überwachung 5.3 für weitere Informationen zu „Transaktionen“ in Lokads Lösung.

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

Kaum. Das Design von Lokad sorgt dafür, dass Dashboards auch bei einer großen Anzahl von Benutzern (im B2B-Bereich) in konstanter Zeit bereitgestellt werden können. Dieser Ansatz stellt einen starken Gegensatz zu vielen alternativen Architekturen, vor allem transaktionalen Datenbanken und Business Intelligence Cube, dar.

Da jedoch jeder einzelne Benutzer (wenn er über entsprechende Systemrechte verfügt) beliebig große Workloads auslösen kann, ist die Anzahl der gleichzeitigen Benutzer bestenfalls zweitrangig, wenn es um die Leistung der Lösung geht. Was die prädiktive Optimierung der Lieferkette betrifft, so machen die Batch-Aufträge, die zur Durchführung der gewünschten Analysen eingesetzt werden, über 99 % des Workloads aus. Der Rest, weniger als 1 %, ist für die Bearbeitung von Benutzeranfragen bestimmt.

2.13 Ist das System so konzipiert, dass es vertikal und horizontal skaliert werden kann?

Ja. Aus unserer Sicht sind vertikale und horizontale Skalierung eine Ergänzung und das Design der Lokad Plattform macht sich beide zunutze. Der interne Orchestrator – der für die Parallelisierung zuständig ist – beginnt in der Regel mit der vertikalen Skalierung, da diese Art der Skalierung die Colocation von Daten 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 Sie Rechenleistung und Speicherplatz automatisch nach Bedarf?

Ja. Lokads Plattform ist mandantenfähig. Durch die Mandantenfähigkeit werden groß angelegte Zuweisungen von Rechenressourcen mit niedriger Latenz durchgeführt. Das bedeutet, dass die automatische Rechenskalierung von Lokad bei weitem schneller ist als das Starten großer VMs (virtuelle Maschinen) eines Cloud-Computing-Anbieter. Die automatische Skalierung des Speichers erfolgt größtenteils über die automatischen Skalierungseigenschaften des persistenten Key-Value-Speichers, der von der zugrundeliegenden Cloud-Computing-Plattform (Microsoft Azure) bereitgestellt wird.

2.15 Wie verwaltet Ihre Anwendung die Anforderungen von Big Data?

Lokads Plattform wurde speziell für die Verarbeitung von Big Data entwickelt. Seit Januar 2023 verwaltet die gesamte Plattform Lokads etwa 1 Petabyte an Daten über den gesamten Kundenstamm. Unsere Plattform kann einzelne Dateien mit einer Größe von bis zu 100 GB verarbeiten und wir verarbeiten regelmäßig Tabellen mit mehreren Milliarden Zeilen. Siehe Sicherheit bei Lokad 4.10

Dieser Punkt ist besonders technisch und würde den Rahmen dieses Dokuments sprengen. Für eine ausführliche Erklärung empfehlen wir die 4-teilige Serie von Victor Nicollet über das Design der Virtuellen Maschine Envision.

2.16 Kann Lokads Cloud-basierte Lösung unter Berücksichtigung straffer (kundenseitiger) Bedingungen zu Bandbreite und Latenz konfiguriert werden? Zum Beispiel: Bandbreite = 3 Mbps (Download) / 1Mbps (Upload), Latenz = 600-800 ms

Ja, die von Lokad entwickelte Webapplikation wurde so konzipiert, dass sie auch in Szenarien mit schlechter Konnektivität (was Bandbreite und Latenz betrifft) eingesetzt werden kann. Diese Bedenken werden in erster Linie durch Grundsatzentscheidungen beim Design der Technologie aus dem Weg geräumt. Diese Entscheidungen zum Architekturdesign heben Lokad auch von der breiten Masse ab.

Bedenken hinsichtlich der Bandbreite werden auf zwei Arten behandelt. Erstens sind wir sparsam, wenn es um JavaScript-Komponenten von Drittanbietern geht. Wir haben weniger als 1 MB an Assets, die anfänglich abgerufen werden müssen. Zweitens bietet die Plattform vollständige Kontrolle über die Datenmenge, die ein einzelnes Dashboard enthalten soll. So kann das Dashboard bei schlechter Verbindung entsprechend leicht gestaltet werden.

Was die Latenz betrifft, wurden unsere Dashboards so entwickelt, dass alle relevanten Dashboard-Daten in einer einzigen HTTP-Anfrage zusammengefasst werden. Dadurch werden die Reibungsverluste für Endbenutzer mit niedriger Latenzzeit minimiert.

3. Vorfälle

3.1 Wie kann ein Kunde einen Vorfall melden?

Die meisten unserer Kunden profitieren von einem Paket, in dem der Zugang zu unserem Team von Supply-Chain-Scientists enthalten ist. Diese Supply-Chain-Scientists sind die erste Anlaufstelle für die Meldung von Vorfällen. Im Falle eines Vorfalls empfehlen wir unseren Kunden, entweder direkt mit ihrem Supply-Chain-Scientist zu telefonieren, wenn ein dringendes Problem vorliegt, oder eine E-Mail zu schicken. Die Supply-Chain-Scientists managen die Vorfälle und kümmern sich auch um etwaige interne Eskalationen bei Lokad.

3.2 Bieten Sie ein Ticketsystem an?

Ja. Lokad nutzt ein Ticketsystem eines Drittanbieters. Seit Januar 2023 arbeiten wir jedoch an der Entwicklung einer internen Lösung, 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 spezifischer vertraglicher Vereinbarung.

Im Zusammenhang mit der prädiktiven Optimierung der Lieferkette kann der Begriff Vorfälle variieren und schwer definierbar sein. Im Allgemeinen betrachten unsere Kunden geringfügige Ereignisse auf Plattformebene (wie z. B. Minuten Ausfallzeiten) nicht als „Vorfälle“. Vielmehr geht es um tatsächliche eigenartige Vorkommnisse in der Lieferkette, die ggf. Probleme mit den im Kundenkonto implementierten Envision-Skripten widerspiegeln. Externe IT-Abteilungen sind nur selten an der Lösung solcher Vorfälle beteiligt.

3.4 Wie stellen Sie eine hohe Verfügbarkeit sicher?

Lokad hat sich schon früh (ca. 2010) für Cloud-Computing-Plattformen entschieden, gerade um eine höhere Verfügbarkeit zu gewährleisten. Abgesehen davon, dass somit die Infrastruktur überflüssig wird (siehe Vorfälle 3.5), legt Lokad beim Design seiner Lösung großen Wert auf Einfachheit. Im Gegensatz zu vergleichbaren Softwarelösungen für Unternehmen haben wir deutlich weniger komplexe Abhängigkeiten (um fast eine ganze Größenordnung). Eine enorme Komplexitätsebene, die unsere Lösung nicht enthält, ist eine transaktionale Datenbank. Durch weniger bewegliche Komponenten, gibt es deutlich weniger Fehlerarten, wodurch wir unseren Kunden – die über mehrere Zeitzonen verteilt sind – eine hohe Verfügbarkeit bieten können.

3.5 Verfügen Sie über eine redundante Infrastruktur (wenn ja, in welcher Hinsicht)? Vermeiden Sie einzelne Fehlerquellen?

Ja. Unsere kritischen Systeme sind redundant, gerade um einzelne Fehlerquellen zu vermeiden. Zu den redundanten Systemen gehören die Subsysteme, die zustandsbehaftete Protokolle wie SFTP unterstützen. Außerdem ist die Datenspeicherung nicht nur redundant, sondern auch geografisch redundant. Diese Redundanz wird bei unseren Releases genutzt, um die Betriebszeit während des Rollouts aufrechtzuerhalten.

3.6 Wie erholen Sie sich von Hardwarefehlern?

Die Wiederherstellung wird nach den meisten Hardwareausfällen transparent von der Cloud-Computing-Plattform durchgeführt, die Lokad einsetzt. Die eingebaute Redundanz in Lokads Plattform stellt sicher, dass sich vorübergehende Hardwareausfälle nicht auf die Betriebszeit auswirken, während die Cloud-Computing-Plattform eine neue, nicht defekte Ressource zuweist. Für die dauerhafte Datenspeicherung nutzt Lokad nur Dienste (d. h. Key-Value-Stores), die selbst durch eigene Redundanzebenen gegen Hardwareausfälle geschützt sind.

3.7 Haben Sie ein Backup?

Ja. Wir verfügen über eine Backup-Umgebung für schwerwiegende Notfallwiederherstellungen (bei Szenarien, die über die Ausfallzeit eines Rechenzentrums hinausgehen). Diese Backup-Umgebung ist von der Produktionsumgebung komplett isoliert. Von der Backup-Umgebung aus kann man auf der Produktionsumgebung lesen (aber nicht in diese schreiben), während man von der Produktionsumgebung aus auf der Backup-Umgebung weder lesen noch schreiben kann.

3.8 Verfügen Sie über einen Plan zur Notfallwiederherstellung?

Ja. Auf technischer Ebene umfasst der Notfallplan die vollständige Neuinstallation von Lokads Plattform. Hierfür werden weitgehend die automatisierten Prozesse, die für unsere wöchentlichen Releases eingerichtet wurden, eigesetzt. Auf Unternehmensebene umfasst der Notfallplan die Kontaktaufnahme mit jedem unserer Kunden. In der Regel wird dann ein mit jedem Kunden vereinbarter Prozess eingehalten. Während der Wiederherstellung sind die jeweiligen Supply-Chain-Scientist Hauptansprechpartner unserer Kunden.

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

Lokads Lösung bietet einen kontinuierlichen Schutz der Daten durch inkrementelle Live-Backups des Ereignisspeichers sowie der Inhaltsquelle. Daher sind wir in der Lage, PITR auf jeden beliebigen Zeitpunkt (bis auf die Minutenebene) durchführen.

Das RPO beträgt 1 Minute für Katastrophen auf Ebene des Rechenzentrums – sofern die Daten nicht kompromittiert sind. Dies erreichen wir, indem geografisch redundante Schreibvorgänge in unserem persistenten Key-Value-Speicher nutzen. Sollte der Key-Value-Speicher kompromittiert sein, greift Lokad auf den Backup-Speicher zurück, der so weit wie möglich von unseren Produktionssystemen isoliert ist und sich auch an einem anderen geografischen Standort befindet. In diesem Fall haben wir einen RPO von 12 Stunden.

3.10 Ist die Lösung in der Lage, Warnungen bei Integritätsverletzungen zu erzeugen? Können Integritätsprüfungen je nach Bedarf in der Lösung hinzufügt oder erweitert werden?

Ja, diese Art von Problem ist jedoch in erster Linie auf ein Softwaredesign zurückzuführen, das auf einer Transaktionsdatenbank basiert. Lokads Plattform arbeitet nicht mit einer Transaktionsdatenbank, sondern mit einem Ereignisspeicher, der nicht relational, sondern ereignisorientiert aufgebaut ist. Damit entfällt zwar nicht die Notwendigkeit, die Datenintegrität zu erhalten, der Ansatz ist jedoch anders.

Was die Verarbeitung von Kundendaten betrifft, verfügt Envision (Lokads DSL) über umfangreiche Funktionen zur Überprüfung deren Qualität. Mit Envision ist es möglich, die Integrität zu prüfen und Warnmeldungen zu generieren. Diese Logik kann vom Kunden beliebig erweitert oder angepasst werden.

4. Architektur

4.1 Welche Programmiersprachen verwenden Sie?

Lokads Plattform wird in C#, F# und TypeScript entwickelt. Die Plattform bietet auch Envision (Lokads DSL), das zur Implementierung kundenspezifischer Lösungen für Supply-Chain eingesetzt wird.

4.2 Welche Development Suite verwenden Sie?

Lokads Softwareentwickler verwenden Microsoft Visual Studio. Die Teams der Supply-Chain-Scientists verwenden die Lokad Plattform selbst, die über eine eigene Development Suite verfügt.

4.3 Welche Betriebssysteme unterstützen Sie?

Lokad ist eine webbasierte Plattform und wir unterstützen alle Betriebssysteme, die Zugang zu einem modernen Webbrowser haben (z. B.: Firefox). Intern ist Lokads Plattform sowohl mit Linux als auch mit Microsoft Windows kompatibel, obwohl die Gesamtheit unserer Produktionssysteme mit Linux (Ubuntu) bereitgestellt werden.

4.4 Welches Datenbanksystem verwenden bzw. unterstützen Sie?

Lokad unterstützt alle Datenbanksysteme, die Flat File Exporte generieren können. Dazu gehören praktisch alle Datenbanksysteme auf dem Markt, einschließlich älterer Modelle. Intern verwendet Lokad kein Datenbanksystem, sondern einen Key-Value-Speicher. Zum Zeitpunkt der Erstellung dieses Dokuments (Januar 2023) setzen wir Blob Storage ein, wie von Microsoft Azure bereitgestellt.

4.5 Welches Caching-System verwenden Sie?

Lokad hat seine eigenen Subsysteme für Caching in C#/.NET entwickelt. Diese Subsysteme sind eng mit dem Rest der Lösung integriert und spiegeln nicht die traditionellen Caching-Systeme wider, die hauptsächlich dazu gedacht sind, Leistungsprobleme bei einer relationalen Datenbank (über die Lokad nicht verfügt) abzufedern.

4.6 Wie geht die Lösung mit Zertifikaten um?

Lokad nutzt Let's Encrypt durch automatische Zertifikatserneuerungen.

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

Die wichtigste technische Voraussetzung ist ein Transaktionssystem, das den Überblick über den eigenen Bestand behält. Außerdem ist es hilfreich, wenn der Kunde Erfahrung mit der Extraktion von Daten (als Flat Files) aus seinen Transaktionssystemen mitbringt. Dies ist jedoch keine Voraussetzung.

4.8 Führen Sie alle zusätzlichen Lizenzen von Drittanbietern auf, die für den Betrieb von Lokads Lösung erforderlich sind (z. B. Betriebssystem, SQL, etc.).

Das trifft nicht zu. Lokad benötigt keine Lizenz(en) von Drittanbietern für den Betrieb. Es gibt eine Vielzahl von Open-Source-Tools, welche die Integration von Lokad unterstützen (d. h. Flat File, die über FTPS oder SFTP übertragen werden). Daher ist keine Lizenz von Drittanbietern erforderlich – auch nicht indirekt, um von Lokads Plattform zu profitieren.

4.9 Benötigt der Dienst Browser-Plugins oder besondere Software?

Lokad ist eine Webanwendung. Es sind keine Browser-Plug-Ins oder besondere Software erforderlich.

4.10 Welche ein- und ausgehenden Schnittstellen hat die Anwendung?

Lokads Lösung bietet eine Webschnittstelle, zugänglich über HTTPS, und die Dateiprotokolle SFTP und FTPS.

4.11 Wie wird sichergestellt, dass es zu keinen Datenlecks zwischen den Mandanten kommt?

Lokads Lösung trennt die Daten der Mandanten bereits von Design aus. So wird sichergestellt, dass es, auch nicht versehentlich, zu Datenlecks kommen kann. Darüber hinaus wird der gesamte Code, der an die Produktion geliefert wird, von Fachkollegen geprüft, was einen zusätzlichen Schutz darstellt. Schließlich weisen wir Sicherheitsforscher (Personen, die Penetrationstests durchführen) an, gezielt die Möglichkeit von Datenlecks zu untersuchen. Wir geben ihnen Zugang auf mehreren Lokad-Konten – in einer dedizierten und vollständig isolierten Umgebung, welche die Produktionsumgebung widerspiegelt – damit sie diese Eigenschaft unserer Plattform intensiv überprüfen können.

4.12 Kann die Lösung containerisiert werden?

Ja, die Containerisierung bietet jedoch wenig bis keinen Nutzen für Lokads Plattform. Die Containerisierung ist von Vorteil, wenn komplexe Abhängigkeiten vorliegen (z. B. eine transaktionale Datenbank, ein isoliertes Caching-System usw.). Wir verwenden weder in der Produktion noch in der Entwicklung Container, was unsere Sicherheit verbessert, da ganze Arten von Schwachstellen eliminiert werden. Stattdessen halten wir die Lösung so einfach, dass die Bereitstellung sogar mit kleinen Shell-Skripten erfolgen kann.

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

Ja, GUI-Komponenten (in diesem Fall Webschnittstellen) sind eigenständig. Dieses Design trägt zu einer höheren Verfügbarkeit bei. So können Endbenutzer auf die Dashboards ihres Lokad-Kontos zugreifen, selbst wenn eines der anderen Subsysteme von einem plötzlichen Ausfall betroffen ist.

4.14 Unterstützt Lokads Anwendung Lokalisierungsfunktionen (wie z. B. die Änderung der Sprache)?

Ja, die Anwendung unterstützt Lokalisierungsfunktionen. Alle von Lokads Plattform produzierten Benutzeroberflächen können in jede beliebige Sprache lokalisiert werden. Hierfür verwendet der gesamte Technologie-Stack UTF-8, sodass außer dem lateinischen auch alle anderen Zeichensätze unterstützt werde können. So kann jede von Lokads Plattform erstellte Benutzeroberfläche nach der Auslieferung in eine andere Sprache erneut lokalisiert werden.

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

Ja, siehe 4.14 oben.

4.16 Verfügt Ihr System über eine eingebaute Hilfe? Wenn ja, in welcher/welchen Sprache/n?

Ja, Lokad wird mit einer sehr umfangreichen öffentlichen Dokumentation (auf Englisch) geliefert. Für die Verwendung von Lokads Plattform werden jedoch maßgeschneiderte Benutzeroberflächen erstellt und unser regulärer Prozess umfasst mindestens zwei Formen von Dokumentation oder Hilfestellungen.

Erstens sind die in Lokads Lösung erstellten Dashboards dazu konzipiert, kontextbezogen dokumentiert zu werden – direkt vom Dashboard aus. Wir haben sogar eine Markdown-Kachel, die der Rich-Text-Dokumentation gewidmet ist. Zweitens ist unser Ergebnis ein „Joint Procedure Manual“ (Gemeinsames Projekthandbuch). Das Handbuch eine detaillierte Analyse nicht nur der Mechanik der Lösung, sondern auch der Gründe zur Auswahl der einzelnen Elemente (und wie sie die spezifischen Anforderungen des Kunden an die Lieferkette erfüllt).

4.17 Ist die Webanwendung responsive?

Lokads Webanwendung und die unterstützenden Unterlagen (wie die technische Dokumentation) wurden mit einem responsiven Design konzipiert. Einige fortgeschrittene Funktionen, wie z. B. die Bearbeitung von Code, sind jedoch für mobile Geräte und/oder Tablets unpraktisch. Das Design zielt also darauf ab, eine responsive Nutzung für die zu erwartenden Aktivitäten auf PCs bzw. kleineren Geräten zu maximieren.

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

Lokad ist eine Webanwendung und wir unterstützen die wichtigsten „altbewährten“ Webbrowser wie Chrome, Firefox und Safari. Aus Sicherheitsgründen versuchen wir nicht, ältere Browser zu unterstützen, da die Unterstützung dieser Browser implizit eine Gefahr für unsere Kunden darstellt. Einfach dargestellt, kann ein anfälliger Browser von einem bösartig Handelnden genutzt werden, um Daten zu exfiltrieren. Allerdings sind wir auch bei neuen Browserfunktionen recht konservativ. Als Faustregel gilt, dass wir keine Browserfunktionen unterstützen, die nicht seit mindestens 1 Jahr von allen wichtigen Webbrowsern übernommen wurden.

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

Das trifft nicht zu. Da es sich bei Lokad um eine Webanwendung handelt, die als SaaS angeboten wird, müssen sich unsere Kunden nicht um die Unterstützung des Betriebssystems kümmern. Intern wird Lokad in Windows entwickelt, während unsere gesamte in der Cloud gehostete Produktionsumgebung auf Linux läuft. Daher gehen wir von einer breiten Übertragbarkeit von Lokads Lösung aus. Obwohl wir aktuell keine Notwendigkeit sehen, dieses System zu ändern, werden wir es entsprechend anpassen, sofern sich konkrete Nachweise dafür ergeben.

4.20 Kann Lokads Webanwendung Benachrichtigungen für Endbenutzer bereitstellen? Wenn ja, über welche Technologie/welches Protokoll?

Ja, Lokad ist in der Lage, Benachrichtigungen über programmierbare Webhook-Benachrichtigungen zu senden. Diese Hooks können dazu genutzt werden, ein System eines Drittanbieters zu verwenden, das häufig bereits im Unternehmen des Kunden vorhanden ist, um eine E-Mail-Benachrichtigung oder eine andere Art von Benachrichtigung zu senden. Die Hooks werden normalerweise auch verwendet, um die Verfügbarkeit von Daten zu signalisieren, die über SFTP oder FTPS von Lokads Plattform abgerufen werden sollen.