FAQ: Change Management

Eine Initiative mit Lokad zielt darauf ab, die supply chain des Kunden mit überlegenen, automatisierten Entscheidungsfindungen zu optimieren – typischerweise indem mühsame tägliche Aufgaben wie Bestellaufträge und Lagerzuweisungsentscheidungen ersetzt werden. Diese Seite behandelt Fragen und Bedenken bezüglich der Veränderung, die diese Initiative mit sich bringt, und wie man sie effektiv managen kann. Lokads Experten stehen jederzeit zur Verfügung, um Kunden durch den Prozess zu führen.

Zielgruppe: Die supply chain- und/oder Planungsabteilungen.
Zuletzt geändert: 19. Dezember 2023

Überblick über das Change Management

die Quantitative Supply Chain (QSC), wie sie von Lokad vorangetrieben und beworben wurde, weicht erheblich von der traditionellen Perspektive ab. Die Unterschiede sind sowohl wesentlich als auch der Kerngrund, warum Lokad derart drastische Verbesserungen in der supply chain erzielen kann. Dennoch ist das Change Management, das mit der Implementierung einer QSC-Initiative einhergeht, einfacher als unsere Kunden in der Regel denken.

Zum Beispiel beseitigt Lokad viele unnötige Berührungspunkte und Prozesse, anstatt nur das eine Verschwendung durch eine andere zu ersetzen. Somit ist die zu managende Veränderung in der Regel zweifach: erstens, die Anpassung an die Tatsache, dass banale, sich wiederholende supply chain Entscheidungen nun automatisiert getroffen werden; zweitens, die Akzeptanz, dass die Qualität dieser automatisierten Entscheidungen über das hinausgeht, was Mitarbeiter mit alternativen Werkzeugen (Legacy-Systeme, Tabellenkalkulationen und häufig eine Mischung aus beidem) zu erreichen vermochten.

Eine QSC-Initiative wird von Lokads Supply Chain Scientists angeführt. Diese Experten bündeln viele Rollen, die in ähnlichen Initiativen bei anderen Softwareanbietern typischerweise von mehreren Personen übernommen würden. Ein Supply Chain Scientist fungiert als Systemintegrator, Data Engineer, Business Analyst, Data Scientist, supply chain Experte und Projektmanager (neben weiteren Rollen). Die Supply Chain Scientists (SCSs) bieten jegliches notwendige Coaching, Schulungen, Anleitung und Unterstützung, damit Kunden Lokads die Quantitative Supply Chain Herangehensweise annehmen können.

Der erfolgreiche Einsatz von Lokad (in Production) führt in der Regel zu zwei bemerkenswerten Ergebnissen: erheblichen Einsparungen durch bessere supply chain Entscheidungen sowie erheblichen Produktivitätseinsparungen durch (weitgehend) automatisierte supply chain Entscheidungen.

Im Hinblick auf das Change Management sind Einsparungen in der supply chain in der Regel kein Problem. Das Unternehmen könnte letztendlich entscheiden, das freigesetzte Working Capital in einem anderen Bereich zu reinvestieren, doch diese Art von Entscheidung liegt normalerweise außerhalb des Umfangs der Lokad-Initiative. Die beträchtlichen Produktivitätseinsparungen, die durch Lokad erzielt werden, werden jedoch typischerweise in andere Aufgaben reinvestiert, die dem Kundenunternehmen einen wesentlich höheren Mehrwert bieten als der bisherige Prozess.

Kurz gesagt, vor Lokad waren die Tätigkeiten der supply chain Praktiker innerhalb des Kundenunternehmens nahezu ausschließlich intern ausgerichtet: eine Prognose erstellen, die Prognose in einen Plan umsetzen, Mindest-/Maximallagerbestände für SKUs anpassen, Bestellaufträge/Produktionsaufträge/Lagerbewegungen zusammenstellen usw.

Sobald Lokad im Einsatz ist, sind die meisten Aktivitäten extern ausgerichtet: herausfinden, was Kunden als Servicequalität wahrnehmen, feststellen, was Lieferanten als Hindernis ansehen, um den Preis weiter zu senken, ermitteln, was Transportunternehmen als Hauptursachen für ihre Unzuverlässigkeit betrachten, usw.

Diese Erkenntnisse werden anschließend kontinuierlich in Lokads Lösung integriert, unterstützt durch das laufende Engagement der SCSs.

Für supply chain Führungskräfte besteht die größte Veränderung darin, dass das ständige Löschen von Bränden (grob gesagt) weitgehend entfällt. Lokads Lösung liefert automatisierte Entscheidungen, die darauf ausgelegt sind, lästige Grenzfälle zu bewältigen, wodurch der Spielraum, den Führungskräfte aufwenden müssen, um unregelmäßiges Marktverhalten zu analysieren, erheblich reduziert wird. Dies ermöglicht es den supply chain Führungskräften, sich auf die Strategie der supply chain Ziele und Projekte zu konzentrieren, anstatt die fortlaufenden Konsequenzen suboptimaler Entscheidungen mikromanagen zu müssen.

Häufig gestellte Fragen (FAQ)

1. Projektimplementierung & Management

1.1 Bieten Sie Projektmanagement-Dienstleistungen für die Implementierung an?

Ja. Diese Dienstleistungen werden von Lokads Supply Chain Scientists (SCSs) erbracht. Diese Experten managen nicht nur die Implementierung, sondern leiten auch die Initiative im Kundenunternehmen. Dies umfasst viele Aufgaben, wie z. B. die quantitative Absicherung des supply chain Managements, um die Gültigkeit von Lokads numerischen Rezepten vor ihrer Umsetzung zu demonstrieren. SCSs stellen zudem Schulungsmaterialien bereit, um die Einführung der von Lokad empfohlenen Praktiken und Prozesse im Kundenunternehmen zu unterstützen.

Darüber hinaus bleiben diese Experten dem langfristigen Erfolg der Initiative auch nach der anfänglichen Implementierung verpflichtet und bieten kontinuierliche Unterstützung, während die Initiative in ihre Phase der ‘kontinuierlichen Verbesserung’ übergeht.

Weitere Informationen zur Rolle der SCS im Optimierungsprozess finden Sie in Lokads Vorträgen über the Supply Chain Scientist und A day in the life of a Supply Chain Scientist.

1.2 Wie sieht Ihr Implementierungszeitplan aus und welche Schritte oder Phasen sind in diesem Zeitplan enthalten? Was sind die Ziele jeder Phase (beginnend mit dem Projektimplementierungs-Kick-off bis hin zum Go-Live)?

Von Anfang bis Ende dauert die Implementierung in der Regel etwa 6 Monate. Lokad unterscheidet zwischen der Onboarding-Phase und der Produktionsphase. Ziel der Onboarding-Phase ist es, Lokads numerisches Rezept in die Produktion zu überführen. Bis zum Ende der Onboarding-Phase sollten die relevanten supply chain Entscheidungen (wie in Zusammenarbeit mit dem Kunden definiert) robotisiert sein. Die Automatisierung stellt jedoch in der Regel nur einen Nebeneffekt (wenn auch einen sehr sichtbaren) des eigentlichen Ziels dar: die Leistung der supply chain zu verbessern. Ziel der ‘Produktions’-Phase ist es, die numerischen Rezepte, die die Automatisierung überhaupt erst ermöglichen, kontinuierlich zu verfeinern, zu verbessern und neu auszurichten.

Aufschlüsselung des Zeitplans

Die Onboarding-Phase dauert in der Regel 6 Monate und kann in drei Teilphasen zu je 2 Monaten unterteilt werden.

• Die erste Teilphase ist die Einrichtung der Data Pipeline. Das Ziel besteht darin, eine vollständig automatisierte Pipeline für die Extraktion von Kundendaten zu Lokad zu schaffen. Die beiden anspruchsvollsten Aspekte der Data Pipeline sind die Etablierung der ‘Semantik’ der Daten und die nahezu perfekte Zuverlässigkeit des Pipeline-Prozesses. Eine Data Pipeline, im Gegensatz zu einer einmaligen Datenauslesung, ist grundlegend dafür, dass die supply chain Empfehlungen, die Lokad generiert, für die aktuellen Geschäftsbelange des Kunden relevant bleiben.

• Die zweite Teilphase ist die Gestaltung der einzigartigen numerischen Rezepte des Kunden – also die Softwarelogik, die die supply chain Entscheidungen steuert. Ziel ist es, Rezepte zu erreichen, die konsistent, zuverlässig und pragmatisch sind. Das Entwerfen der ersten numerischen Rezepte erfolgt zügig und dauert in der Regel nicht länger als ein bis zwei Wochen. Diese Entwürfe dienen jedoch nur als Ausgangspunkt und werden in nachfolgenden Iterationen von den für das jeweilige Konto verantwortlichen Supply Chain Scientist(s) rasch verbessert. Dadurch werden lästige Grenzfälle, die in den ersten Entwürfen vorhanden waren, schnell beseitigt.

• Die dritte Teilphase ist der Dual Run. Das numerische Rezept produziert keine Unsinn mehr, und die wirtschaftlichen Treiber, die die Optimierung steuern, wurden vereinbart. Allerdings ist das Rezept noch nicht produktionsreif. Um voranzukommen, wird ein Dual Run durchgeführt. Das numerische Rezept wird parallel zum Legacy-Prozess ausgeführt. Da das Rezept automatisiert ist, ist der organisatorische Mehraufwand gering. Täglich können supply chain Praktiker die Entscheidungen vergleichen und beobachten, wie sich Muster (z. B. Saisonalität) entfalten. Über mehrere Wochen des Dual Runs wird das Vertrauen aufgebaut, um mit dem Produktionsrollout fortzufahren.

Am Ende der Onboarding-Phase – und sofern alle Schritte erfüllt wurden – beginnt der Produktionsrollout. Dieser Rollout besteht darin, die Automatisierung den Legacy-Prozess übernehmen zu lassen. Diese Übernahme kann auch stufenweise erfolgen, abhängig von der Fähigkeit des Kunden, das notwendige Change Management zu überwachen.

Weitere Details zu jedem Schritt des Optimierungsprozesses finden Sie in der Übersicht zum Zeitplan.

1.3 Dokumentiert und veröffentlicht Lokad einen Projektmanagementplan, der den Projektumfang, den Zeitplan, kritische Meilensteine, Ressourcen, Deliverables, Verantwortlichkeiten, Kostenmanagementplan, Qualitätsmanagementplan, Risikomanagementplan sowie einen Plan für Stakeholder-Management und Kommunikation detailliert beschreibt?

Ja. All diese Elemente und mehr werden in einem einzigartigen Joint Procedure Manual (JPM) für die Initiative zusammengeführt. Die Supply Chain Scientists (SCSs) sind dafür verantwortlich, das JPM für die gesamte Dauer der Initiative zu initiieren und aufrechtzuerhalten.

Lokads JPM konzentriert sich auf die ‚Warum?‘-Fragen. JPMs sind gut formuliert und sollen auch für weniger technische und/oder nicht-spezialisierte Zielgruppen weitgehend zugänglich sein. Das JPM fasst das Wesen der Intention hinter der Initiative zusammen und vereint grundlegende Erkenntnisse, sobald diese im Laufe der Initiative gewonnen werden.

Lokad vertritt die Ansicht, dass viele (wenn nicht die meisten) Unternehmensinitiativen durch die Erstellung unbrauchbarer Dokumente behindert werden, die in der Praxis unmöglich zu lesen sind (d.h. sie sind langweilig oder undurchsichtig technisch). Solche Dokumente dienen keinem Zweck außer dem Abhaken erfundener Kästchen. Darüber hinaus neigen viele Drittparteien (z. B. Integratoren, Berater und sogar die interne Bürokratie) dazu, Quantität über Qualität zu stellen, wenn es um die Dokumentation des Projekts geht.

Im Gegensatz dazu sollen Lokads JPMs sowohl lesbar als auch gelesen werden. JPMs sind Werkzeuge, die von den SCSs selbst zur Steuerung der Initiative genutzt werden. Obwohl wir umfangreiche Richtlinien dafür haben, was in einem JPM zu finden sein sollte, liegt es letztendlich an den SCSs, fundierte Entscheidungen darüber zu treffen, was angesichts der Besonderheiten der Initiative die meiste Aufmerksamkeit und Mühe erfordert.

Weitere Informationen zu Lokads Dokumentationsethos finden Sie im Vortrag Writing for Supply Chains.

1.4 Ist Lokad dafür verantwortlich, den Projektmanagementplan zu pflegen und als Grundlage zu verwenden, vorbehaltlich der Genehmigung/en des Projektsteuerungsausschusses? Falls Abweichungen vom Plan auftreten, werden Sie diese klar kommunizieren und passende Gegenmaßnahmen vorschlagen?

Ja. Die genannten Verantwortlichkeiten werden von Lokads Supply Chain Scientists (SCSs) übernommen. Die Details der Kommunikationssteuerung mit dem Kundenunternehmen hängen in der Regel von den vertraglichen Bestimmungen der Initiative ab und werden darin festgelegt.

Gelegentlich sind auf Kundenseite deutlich mehr Mitarbeiter in das Projekt eingebunden als auf Lokad-Seite. Um die Produktivität der SCSs, die das Konto betreuen, zu verbessern, bestimmt daher oft ein Kunde einen einzigen Ansprechpartner für die Initiative. Diese Person – oder ein kleines Team – ist dafür zuständig, alle relevanten Informationen an alle an der Initiative beteiligten Parteien auf Kundenseite weiterzuleiten und entsprechendes Feedback einzuholen.

Bei einer besonders komplexen Initiative richtet Lokad einen speziellen Steuerungsausschuss ein, der aus wichtigen Mitgliedern sowohl von Lokad als auch vom Kundenunternehmen besteht. Obwohl diese Sitzung als Mechanismus zur formellen Genehmigung dient, findet der Großteil der inhaltlichen Arbeit außerhalb des Ausschusses statt. Die SCSs treten in der Regel in täglichen Interaktionen mit verschiedenen Kundenteams in Kontakt. Diese Teams werden kontinuierlich über jegliche Abweichungen vom Plan informiert und stellen sicher, dass die gesamte Initiative auf Kurs bleibt. Diese täglichen Interaktionen sind ein weitaus effektiverer Weg, technische Probleme zu besprechen und zu überwinden, als große Mengen an Problemen in einer Sitzung des Steuerungsausschusses zu erörtern. Daher fungiert der Steuerungsausschuss als überwachendes Gremium und nicht als Denkfabrik für die Initiative.

Hinweis: Quantitative supply chain Initiativen weisen bekanntermaßen häufig „positive Abweichungen“ auf. Dabei handelt es sich um erfreuliche Überraschungen im Rezept, die sich im Laufe der kontinuierlichen Wartung der Initiative zeigen. Im Wesentlichen sind es Chancen, die zu gut sind, um sie ungenutzt zu lassen. Ein wesentlicher Vorteil von Lokads Kommunikationsansatz besteht darin, diese positiven Abweichungen sobald sie auftreten schnell und effizient an den Kunden weiterzuleiten, wodurch die Wirkung und Agilität der Initiative deutlich gesteigert wird.

1.5 Werden Sie den Kommunikationsplan dokumentieren, der tägliche Stand-ups, wöchentliche Statusberichte und Review-Sitzungen der Arbeitsgruppen sowie monatliche Berichte und Review-Sitzungen des Steuerungsausschusses umfasst? Werden Sie die Eskalationskriterien darlegen und eine einvernehmliche Vereinbarung zwischen dem Kundenunternehmen und Lokad zu diesen Details sicherstellen?

Ja. Lokads Supply Chain Scientists (SCSs) sind für diese Aufgaben verantwortlich. Die Details des Kommunikationsmanagements innerhalb des Kundenunternehmens hängen in der Regel von den vertraglichen Bedingungen der Initiative ab.

Lokad nimmt gerne an täglichen Stand-ups teil, wenn sie vor Ort in der Zentrale des Kundenunternehmens stattfinden. In der Regel arbeiten unsere SCSs jedoch in den Lokad-Büros.

Wir fassen alle Dokumentationen der Initiative in einem Joint Procedure Manual (JPM) zusammen, das effektiv als umfassender Leitfaden für das gesamte Projekt dient. Das JPM umfasst die Protokolle aller Arbeitssitzungen, einschließlich der Berichte des Steuerungsausschusses (sofern zutreffend).

Obwohl Lokad die Eskalationskriterien und -richtlinien klar definiert, sei darauf hingewiesen, dass von einem Senior SCS bei Lokad erwartet wird, alle Fragen oder Bedenken bezüglich der Initiative zu bearbeiten. In Bezug auf Eskalationen wird die Lösung eines problematischen Falls in der Regel von einem Junior SCS an einen Senior SCS weitergegeben. Dies hat sich historisch als ausreichend erwiesen, wobei nur sehr wenige Situationen eine weitere Eskalation erforderten.

Lokad betrachtet alle Probleme – so unbedeutend sie auch erscheinen mögen – als einer eingehenden Analyse würdig. Obwohl ihre Auswirkungen leicht zu beheben sind, können kleine Probleme zukünftig zu Herausforderungen werden, wenn die Ursachen nicht verstanden und behoben werden. Dies verhindert, dass ein kleines Problem zu einem wiederkehrenden wird. Daher bevorzugt Lokad, hochqualifizierte Personen an vorderster Front einzusetzen, die in der Lage sind, sowohl das unmittelbare Problem zu lösen als auch die zugrunde liegenden Ursachen zu identifizieren. Dieser Ansatz ist vorzuziehen gegenüber der Abhängigkeit von ungeschultem Supportpersonal, das ständig dieselben Probleme bearbeitet – ein Muster, das von vielen Anbietern von Unternehmenssoftware allzu häufig praktiziert wird.

Daher ist Lokads prägnanter Eskalationsprozess absichtlich so gestaltet, um schnelle und dauerhafte Lösungen zu gewährleisten.

1.6 Werden Sie sicherstellen, dass der Projektmanagementplan im Rahmen der Projektinitiierungsphase von allen Stakeholdern abgenommen wird?

Ja. Allgemein folgen Lokads Supply Chain Scientists (SCSs) dem Prozess, der mit jedem Kunden verhandelt und vereinbart wurde – gemäß den formellen vertraglichen Bedingungen. Dieses Prinzip gilt während der gesamten Initiative, von Anfang bis Ende. Die Initiierung des Projekts ist zwar wichtig, doch da Lokad nicht von Anfang an eine langfristige Verpflichtung verlangt, ist diese Angelegenheit weniger bedenklich – besonders im Vergleich zu unseren Mitbewerbern.

Es sollte beachtet werden, dass wir noch nie beobachtet haben, dass eine supply chain aufgrund eines Mangels an Bürokratie und anderen belanglosen Prozessen schlecht funktioniert. Im Gegenteil, unnötige Bürokratien und absurde Prozesse sind die häufigsten Probleme, die in modernen supply chains vorkommen – selbst in Unternehmen, die ansonsten leistungsstarke supply chains zu haben scheinen.

1.7 Werden Sie einen dedizierten Projektmanager von Lokad einsetzen, der seinen Sitz in der Zentrale des Kundenunternehmens hat, begleitet von Fachexperten für das Produkt, Business-Analysten und technischen Schnittstellenexperten?

Ja, sofern solche Bestimmungen Teil der vereinbarten vertraglichen Bedingungen für die Initiative sind. Obwohl Lokad nichts dagegen hat, Mitarbeiter direkt im Hauptsitz des Kundenunternehmens einzusetzen, erhöht dies naturgemäß die Kosten der Initiative. Die meisten unserer Initiativen werden remote durchgeführt und durch monatliche oder vierteljährliche Besuche, je nach Umfang der Initiative, unterstützt. Diese Praxis wird von allen Beteiligten in der Regel als effizienter wahrgenommen, als Lokad-Mitarbeiter dauerhaft in den Büros des Kunden zu stationieren. Es sollte beachtet werden, dass, selbst wenn Lokad zustimmt, ein festes Team im Hauptsitz des Kundenunternehmens zu stationieren, die Mitarbeiter im Laufe der Zeit rotieren werden.

Solche Praktiken kommen allen Beteiligten zugute, da Lokads Supply Chain Scientists (SCSs) einem kontinuierlichen Schulungsprogramm unterliegen. Dieses Programm ist entscheidend, um sicherzustellen, dass unsere Mitarbeiter kontinuierlich neue Fähigkeiten erwerben oder bestehende verfeinern – unabhängig von Erfahrung oder Dienstalter. Während wir beobachten, dass viele Anbieter von Unternehmenssoftware ihren Mitarbeitern erlauben, Monate, wenn nicht Jahre, bei Kunden vor Ort zu arbeiten, ist Lokad überzeugt, dass diese Praxis nicht mit der zuverlässigen und effizienten Bereitstellung hochwertiger Schulungsprogramme vereinbar ist.

Insbesondere eine der größten Stärken von Lokads SCSs ist ihr außergewöhnlich vielfältiger und breiter Kompetenzbereich. Jeder SCS wird darauf geschult, in verschiedenen Rollen zu agieren, wie z. B. als Fachexperte, Business-Analyst, technischer Schnittstellenexperte, Data Scientist und supply chain Berater. Diese Funktionen würden normalerweise von mehreren Mitarbeitern erfüllt werden und zu einer erheblichen Kostensteigerung für den Kunden führen. Bei Lokad erbringt jedoch jeder SCS all diese Dienstleistungen.

Infolgedessen neigen SCSs dazu, deutlich produktiver zu sein (weniger Personen bedeuten in der Regel weniger Kommunikationsprobleme) und höhere Leistungsniveaus zu erzielen. In Wirklichkeit sind supply chains entscheidend von einer lückenlosen Konsistenz abhängig, was mit einer geringen Mitarbeiterzahl viel einfacher zu erreichen ist.

1.8 Welche Organisationsstruktur schlagen Sie während der Umsetzungsphase vor? Wo sollten die Ressourcen eingesetzt werden?

Für eine typische Initiative bei Lokad empfehlen wir, dass das Kundenunternehmen einen erfahrenen supply chain Praktiker als Koordinator der Initiative benennt und zudem einen supply chain Manager als Aufsichtsperson der Initiative einsetzt. Der Koordinator dient als Ansprechpartner zwischen Lokads Team von Supply Chain Scientists (SCSs) und dem Kundenunternehmen. Zunächst wird der Koordinator die Anfragen nach Informationen weiterleiten und später die Anfragen nach Feedback vermitteln. Gleichzeitig arbeiten Lokads SCSs mit den numerischen Rezepten, die darauf abzielen, die relevanten supply chain Entscheidungen zu erzeugen.

Wir empfehlen ein wöchentliches Treffen, um den Fortschritt der Initiative zu überprüfen, bis die Onboarding-Phase abgeschlossen ist. An diesen Treffen nehmen systematisch der Koordinator, der Aufsichtsleiter und der primäre SCS des Kontos von Lokad teil. Andere Teilnehmer können bei Bedarf hinzukommen, doch ist ihre kontinuierliche Anwesenheit in der Regel während der gesamten Implementierungs-/Onboarding-Phase nicht erforderlich.

Einige IT-Ressourcen müssen gleich zu Beginn der Initiative für den Aufbau der Datenpipeline eingeplant werden. In dieser Hinsicht ist Lokad effizienter als die meisten Mitbewerber. Zum Beispiel extrahieren wir automatisch und direkt die Transaktionsdaten des Kunden, ohne dass eine clientseitige Bereinigung oder Vorbereitung erforderlich ist. Sofern das Kundenunternehmen nicht unter einem Vendor-Lock-in leidet, erfordert dieser technische Aufbau weniger als 4 Wochen Arbeit für einen einzelnen Mitarbeiter – und manchmal noch viel weniger, wenn bereits ein Data Lake vorhanden ist.

Anschließend müssen die SCSs qualitative Einblicke in die bestehenden Prozesse sowie in alle supply chain Prioritäten und Einschränkungen sammeln. Eine Reihe von Interviews, die von den Koordinatoren moderiert werden, findet in der Regel statt, um diesen Prozess zu unterstützen. Später, sobald die SCSs die numerischen Rezepte entwickelt haben, erfolgt eine weitere Reihe von Interviews, um die von diesen Rezepten erzeugten Zahlen zu überprüfen und den SCSs die Möglichkeit zu geben, diese zu verfeinern und zu verbessern.

Der Input des Aufsichtsleiters ist sowohl wichtig, um Lokad an der von dem Unternehmen verfolgten übergeordneten Strategie auszurichten, als auch um zu verhindern, dass die Initiative aufgrund von Unentschlossenheit ins Stocken gerät. Zum Beispiel kann Lokad verschiedene Optionen vorschlagen, um die Kosten, die mit mangelnder Servicequalität verbunden sind, zu modellieren. Wir können die Vor- und Nachteile dieser Optionen in nicht-technischen Begriffen erläutern, aber letztlich müssen einige strategische Entscheidungen getroffen werden.

Selbstverständlich hängt all das von den spezifischen Bedürfnissen der Initiative ab. Wir sind offen für andere organisatorische Ansätze, wenn diese besser zum spezifischen Kontext und den Zielen des Kundenunternehmens passen.

Für weitere Informationen bietet Lokad mehrere Vorträge an, die der taktischen und strategischen Umsetzung einer erfolgreichen supply chain Optimierung gewidmet sind.

2. Ressourcenmanagement & Anforderungen

2.1 Was sind die Personalbedarfe für die Projektdurchführung im Kundenunternehmen, insbesondere hinsichtlich der Anzahl der Ressourcen und ihres Kompetenzniveaus? Können Sie die Anzahl der Ressourcen für jede Phase und Unterphase des Projekts genau definieren?

Eine typische Lokad-Initiative erfordert im Kundenunternehmen während der ersten 6 Monate – der sogenannten Onboarding-Phase – etwa 0,5 bis 2 FTE (Full-Time Equivalent) an Mitarbeiterressourcen. Sobald die Initiative in Produktion geht, wird schätzungsweise weiterhin mindestens 0,25 FTE benötigt. Natürlich variieren diese Schätzungen erheblich, abhängig von der Größe und Komplexität des Kundenunternehmens sowie dessen spezifischen supply chain Bedürfnissen.

Hinsichtlich der in jeder Phase einer “typischen” Initiative benötigten Ressourcen haben wir während der Onboarding-Phase:

• Monate 1 und 2: Der Aufbau der Datenpipeline erfordert 4 Wochen Vollzeiteinsatz eines Data Officer, der typischerweise in der IT des Kunden beschäftigt ist. Der Data Officer sollte mit der Anwendungslandschaft des Kundenunternehmens bestens vertraut sein. Dieser Bedarf kann reduziert werden, wenn bereits ein Data Lake vorhanden ist, wird jedoch erhöht, wenn die Datenpipeline mit mehreren Geschäftssystemen (z. B. 1 ERP pro Land) zurechtkommen muss. Sobald die Datenpipeline läuft, sollte deren Wartung nicht mehr als wenige Stunden pro Monat des Data Officers in Anspruch nehmen.

• Monate 3 und 4: Das Entwerfen des numerischen Rezepts erfordert 2 bis 3 Tage pro Woche des Koordinators (auf Kundenseite) der Initiative, mindestens 10 Stunden pro Woche von verschiedenen supply chain Praktikern zur Bereitstellung von strategischen Einblicken und später zur Rückmeldung zu den von Lokad erstellten Zahlen. Es wird erwartet, dass der Koordinator mit dem Unternehmen und dessen supply chain vertraut ist und sich mit analytischer Arbeit wohlfühlt. Diese Position erfordert jedoch keine spezialisierten IT- oder spezifischen Data-Science-Kenntnisse. Die wöchentliche Überprüfung der Initiative erfordert einen halben Tag pro Woche eines supply chain Executives.

• Monate 5 und 6: Die Anforderungen entsprechen im Wesentlichen der vorherigen Phase, allerdings ändert sich der Fokus. Der Koordinator verbringt nun die meiste Zeit damit, den richtigen Roll-out vorzubereiten und mit allen betroffenen supply chain Praktikern zu kommunizieren. Ebenso überwacht der supply chain Executive das interne Change Management in Bezug auf die neuen Prozesse, die aus Lokads Initiative hervorgehen.

Siehe auch Projektumsetzung & -management 1.2.

2.2 Stellen Sie sicher, dass ausreichend Personal für die Unterstützung des Produktübergangs eingeplant ist?

Ja. Als Faustregel empfiehlt Lokad, während des Übergangs von der Onboarding-Phase zur Produktionsphase die gleiche Anzahl an Ressourcen (z. B. die gleichen Supply Chain Scientists) beizubehalten. Der potenzielle Return on Investment einer gut gewarteten und kontinuierlich verbesserten Lösung ist erheblich. Es ist ein Fehler, die Bewältigung solcher Herausforderungen mit einem Set-and-Forget-Ansatz anzugehen, da jede technische Lösung, wenn sie nicht richtig überwacht und gewartet wird, zwangsläufig – und kontinuierlich – in Richtung Irrelevanz und Veralterung driftet.

Es ist erwähnenswert, dass, da Lokad supply chain Entscheidungen automatisiert, keine unmittelbare Dringlichkeit besteht, alle supply chain Praktiker des Kundenunternehmens mit einem neuen Prozess umzuschulen, um den Betrieb am Laufen zu halten – die Automatisierung selbst ist dafür vorgesehen. Infolgedessen ist es nicht ungewöhnlich, dass der vollständige Umbau der supply chain Organisation des Kundenunternehmens – ausgelöst durch Lokads Initiative – schon wenige Monate nach dem Projektstart abgeschlossen wird.

Dieser schlanke Ansatz steht in starkem Kontrast zu den großen – und kostspieligen – “Task Forces”, die häufig von Anbietern von Unternehmenssoftware für den Produktionsstart benötigt werden.

2.3 Können Sie garantieren, dass vor Ort in der Zentrale des Kundenunternehmens ausreichend Personal und Knowledge Product (KP) Ressourcen zur Unterstützung des Produktübergangs verfügbar sind?

Ja, solche Bestimmungen und Anforderungen sind durch die spezifischen, einvernehmlich vereinbarten vertraglichen Bedingungen der Initiative abgedeckt.

Siehe auch Projektumsetzung & -management 1.7.

Siehe auch Ressourcenmanagement & Anforderungen 2.2.

2.4 Organisieren Sie Requirements-Review-Sitzungen mit den Business Product Owners, um Anforderungen zu ermitteln und zu dokumentieren?

Ja. Eines der ersten Ziele des Supply Chain Scientist besteht darin, alle notwendigen Einblicke in die supply chain des Kunden zu gewinnen. Dieser Prozess wird typischerweise durch Interviews mit relevanten Stakeholdern, einschließlich der Business Product Owners, durchgeführt. Zudem versuchen wir, vorhandene Dokumente (falls vorhanden) sorgfältig zu prüfen, um den größtmöglichen Nutzen aus diesen Interviews zu ziehen.

Lokads Hauptanliegen besteht jedoch darin, das untersuchte “Problem” zu verstehen, was nicht immer durch das Auflisten von “Anforderungen” unterstützt wird. Wenn ein Kunde beispielsweise erwähnt, dass er eine spezielle Behandlung von “slow movers” benötigt, verstehen wir, dass ein geringes Volumen ein zu lösendes Problem darstellt. Allerdings ist die Sonderbehandlung dieser SKUs nur eine von vielen Optionen, die uns zur Verfügung stehen, um dieses Problem anzugehen.

In diesem Beispiel würden wir es vorziehen, die wahre Natur der “slow movers” zu ermitteln. Tatsächlich kann es nach der Untersuchung der pain points in der supply chain des Kunden der Fall sein, dass “slow movers” SKUs sind, die falsch bepreist, gebündelt und/oder zugeordnet wurden. Sobald das Problem (slow movers) besser verstanden wird, ändert sich die Interventionsstrategie vollständig – was oft die Lösung erleichtert.

Daher erfasst und dokumentiert Lokad zwar alle Kundenanforderungen, jedoch legt unser Ansatz den Schwerpunkt darauf, die wahre Natur des Problems zu entdecken, anstatt den aktuellen Zustand der supply chain des Kunden einfach hinzunehmen.

Weitere Informationen zur Problem-Lösungs-Dichotomie finden Sie unter Fall in Love with the Problem, Not the Solution.

2.5 Geben Sie Schätzungen für Aufwand, Kosten und Zeitpläne für Funktionen an, die eine Anpassung erfordern, einschließlich System-Schnittstellen, und teilen Sie diese nach dem Fit-Gap-Analyse-Workshop mit?

Ja. Diese Schätzungen sind in der Regel in unserem anfänglichen kommerziellen Angebot enthalten. Falls ein Workshop zur Vorbereitung der Initiative organisiert wird, nutzen wir die im Workshop gewonnenen Informationen, um unser Angebot weiter zu verfeinern.

Die Lokad-Plattform ist programmatisch. Daher soll die Implementierung durch Skripte unterstützt werden, die in Envision, unserer DSL (domänenspezifischen Programmiersprache) für die prädiktive Optimierung von supply chains, geschrieben sind. Infolgedessen ist Lokad besonders gut geeignet, maßgeschneiderte Funktionen und Schnittstellen bereitzustellen, unabhängig davon, ob diese für Menschen oder für die Geschäftssysteme des Kundenunternehmens bestimmt sind.

Im Gegensatz zu den meisten Unternehmenssoftwares ist Programmierbarkeit ein zentrales Merkmal von Lokad. Die oben genannten Envision-Skripte sind keine “Anpassung” der Lokad-Lösung im üblichen Sinne. Ebenso wenig stellt das Vorhandensein dieser Skripte eine Abweichung vom Hauptentwicklungszweig der Lokad-Lösung dar. Vielmehr ist die umfangreiche Programmierbarkeit von Lokad der beabsichtigte Implementierungsweg.

Daher ist unsere Schätzung (Kosten, Zeitplan etc.) mit einer außerordentlich hohen Zuverlässigkeit verbunden. Der überwiegende Teil der Projekte bleibt im Rahmen der Schätzungen/des anfänglichen Budgets (in jeder Hinsicht). Dies steht im Gegensatz zu mehreren Wettbewerbern von Lokad, bei denen kostspielige Verzögerungen und Neufestlegungen der Bedingungen üblich sind.

Weitere Informationen zu diesem Thema finden Sie in der Fallstudie zum 500-Millionen-Euro-SAP-Debakel von Lidl.

2.6 Werden Sie eine angemessene Bindungsstrategie implementieren und aufrechterhalten, die darauf ausgelegt ist, Schlüsselpersonal für die Dauer der Vereinbarung zu halten? Werden Sie auch aktive Nachfolgepläne für jede der Schlüsselpositionen bei Lokad pflegen?

Ja. Bei unseren Mitarbeitern liegt die durchschnittliche Verweildauer bei 3,5 Jahren, was fast doppelt so lang ist wie die Beschäftigungsdauer ähnlicher Gruppen (talentierter Ingenieure in der IT oder IT-naher Bereiche) in vergleichbaren Märkten (Nordamerika und Westeuropa). Infolgedessen profitieren die meisten Lokad’s Initiativen davon, dass von Jahr zu Jahr dieselben Supply Chain Scientists (SCSs) beteiligt sind.

Diese Mitarbeiterbindung ist auf wettbewerbsfähige Gehälter und Lokads kontinuierliche Investitionen in die Weiterbildung seiner Teams zurückzuführen. Insbesondere der supply chain Inhalt, den Lokad auf seiner eigenen Website veröffentlicht – insbesondere unsere Reihe von supply chain Vorträgen – kann als Nebenprodukt von Lokads Fokus auf die Schulung des eigenen Personals angesehen werden. Generell haben Anbieter von Unternehmenssoftware, die keine öffentlichen Schulungsmaterialien bereitstellen, fast niemals auch private Schulungsmaterialien (auch wenn sie unweigerlich das Gegenteil behaupten).

Hinsichtlich der Nachfolgeplanung verfolgen wir zwei wichtige Vorgehensweisen. Erstens wird jede Lokad-Initiative mit einem Joint Procedure Manual (JPM) ausgestattet. Das JPM ist das primäre Dokument, das ein neuer SCS verwendet, um sich schnell mit allen relevanten Erkenntnissen und technischen Details der Initiative vertraut zu machen. Zweitens verfügt jede Initiative – zu jeder Zeit – sowohl über einen primären als auch über einen sekundären SCS. Selbst wenn der sekundäre SCS nicht direkt zur Initiative beiträgt, stellt Lokad sicher, dass dieser ausreichend Zeit hat, um bei Bedarf die Initiative zu übernehmen. Diese Praxis mildert weitgehend Komplikationen, die mit ungeplanten Abwesenheiten/Betriebswechseln einhergehen.

3. Rollen, Verantwortlichkeiten & Stakeholder-Management

3.1 Wie intensiv ist die Zusammenarbeit mit dem Kundenunternehmen?

Das Ausmaß der Zusammenarbeit mit unseren Kunden variiert, insgesamt ist es jedoch deutlich höher als das, was üblicherweise von einem Anbieter von Unternehmenssoftware erwartet wird. supply chain Belange sind nicht für alle Unternehmen gleichermaßen wichtig, daher ist die Zusammenarbeit intensiver in Unternehmen, in denen die supply chain das (anerkannt) Rückgrat ihrer Aktivitäten bildet.

Der Begriff „Partner“ wurde so weit verwässert, dass sogar Anbieter trivialer Softwareprodukte (wie Zeiterfassungssoftware) als „Partner“ bezeichnet werden. Nach ein oder zwei Jahren bezeichnen jedoch die meisten unserer Kunden ihre Beziehung zu Lokad als eine „echte“ Partnerschaft – im wahrsten Sinne des Wortes. Sie haben bekannte Gesichter bei Lokad, die ihr Vertrauen gewonnen haben und folglich – typischerweise Supply Chain Scientists (SCSs) – das Geschäft im Detail kennen. Zudem werden unsere Ergebnisse häufig als so bemerkenswert erachtet, dass sie persönlich dem CEO und/oder dem Vorstand präsentiert werden, selbst in großen Unternehmen.

Die fortlaufende Zusammenarbeit mit Lokad ermöglicht es unseren Kunden, ihre gesamte supply chain Praxis positiv umzugestalten. Letztlich wird die ganze Kette überarbeitet, was sich positiv auf sowohl Kunden als auch Lieferanten auswirkt. Es sei darauf hingewiesen, dass Lokad nicht die kritische strategische Expertise ersetzen möchte, die im Kundenunternehmen vorhanden ist. Vielmehr will Lokad den alltäglichsten und repetitiven Aspekt(e) der Entscheidungsprozesse der supply chain automatisieren. Dieser Ansatz befreit anschließend bedeutende – und oft knappe – Ressourcen der Kunden, die besser genutzt werden können.

3.2 Welche Rollen und Verantwortlichkeiten erwarten Sie sowohl im Kundenunternehmen als auch bei Lokad, um die Effektivität der Lösung zu maximieren?

Es gibt 4 typische Rollen, die an Lokad’s quantitative supply chain Initiativen beteiligt sind.

• The Supply Chain Leader: Diese Rolle betont die Bedeutung der Einbindung des Top-Managements in die quantitative supply chain Initiative. Obwohl nicht erwartet wird, dass diese Person sich in die technischen Details vertieft, muss sie die strategischen Erkenntnisse der Initiative verstehen und kommunizieren. Ihre Aufgabe besteht nicht darin, Kennzahlen und KPIs zu erstellen, sondern diese kritisch zu bewerten und in Frage zu stellen, um die Übereinstimmung mit der übergeordneten Strategie sicherzustellen.

• The Supply Chain Coordinator: Wesentlich, um den reibungslosen Ablauf der Initiative zu gewährleisten, fungiert diese Person als Brücke zwischen den verschiedenen internen Teams. Ihre Hauptaufgabe besteht darin, Feedback zu sammeln, mit den Stakeholdern zu kommunizieren und Prozesse sowie Entscheidungen zu bestätigen/zu klären. Sie stellt sicher, dass die Initiative mit den bestehenden Unternehmensabläufen übereinstimmt, während sie gleichzeitig offen für mögliche zukünftige Anpassungen der Abläufe bleibt.

• The Data Officer: Daten bilden das Rückgrat der quantitativen supply chain Initiative, und diese Person stellt deren Zugänglichkeit und Zuverlässigkeit sicher. Beauftragt mit der Extraktion umfassender Datensätze (wie Verkaufs- und Einkaufshistorien), ist sie verantwortlich für die Automatisierung und Planung der Datenauszüge. Obwohl ihre Rolle zu Beginn der Initiative am intensivsten ist, ist ihr Beitrag entscheidend für den Erfolg.

• The Supply Chain Scientist: Diese Rolle verbindet die Erkenntnisse des Supply Chain Coordinators mit den Daten des Data Officer, um Entscheidungsprozesse zu automatisieren. Ausgehend von der Datenaufbereitung arbeitet der Supply Chain Scientist eng mit dem Coordinator zusammen, um etwaige Datenunklarheiten zu klären. Anschließend formalisieren sie Strategien in umsetzbare Entscheidungen, wie z. B. Nachbestellmengen, und implementieren Dashboards sowie KPIs zur Transparenz und Kontrolle.

Siehe Projektrollen für weitere Informationen zu den verschiedenen Bezeichnungen innerhalb einer quantitativen supply chain Initiative.

3.3 Verfügen Sie über eine vollständige RACI-Tabelle (Responsible / Accountable / Consulted / Informed) für die Implementierungsphase und für die Produktionsphase?

Ja. Diese Informationen können gegebenenfalls in Form einer RACI-Tabelle explizit dargestellt werden, wenn dies vom Kundenunternehmen als wichtig erachtet wird.

Was noch wichtiger ist: Die Supply Chain Scientists (SCSs) verinnerlichen eine derartige Matrix, um im Verlauf der Initiative angemessene und schnelle Entscheidungen treffen zu können. Was die Optimierung einer supply chain betrifft, besteht der Kern darin, die beste Art und Weise zu finden, das Problem darzustellen. Anschließend verschiebt sich der Fokus darauf, herauszufinden, wer innerhalb der Organisation am besten geeignet ist, das Problem zu lösen. Entscheidend ist, dass all diese Analysen zügig durchgeführt werden, um den Schwung der Initiative aufrechtzuerhalten.

Zu diesem Zweck sind Lokad’s SCSs dazu bestimmt, die Initiative anzuführen und die Verantwortung für die Qualität der von Lokad’s numerischer Rezeptur generierten Ergebnisse zu übernehmen.

Demnach ist es ein kleiner Kern hochqualifizierter Spezialisten, die für die supply chain Entscheidungen verantwortlich sind, die Lokad trifft – anstatt für ein ausgeklügeltes „System“ oder einen „Prozess“, bei dem Teile der Verantwortung zwischen einer großen Gruppe von Stakeholdern delegiert werden. Lokad vertritt die Auffassung, dass solche Systeme dazu neigen, die Verantwortung zu verwässern, anstatt sie zu verfestigen. Unsere SCSs werden daher dahingehend geschult, diese Verantwortung zu übernehmen und zu handhaben, was auch beinhaltet, sicherzustellen, dass die relevanten Stakeholder im Kundenunternehmen konsultiert und vollumfänglich über die Initiative informiert werden.

3.4 Werden Sie die Rollen und Verantwortlichkeiten aller am Projekt beteiligten Stakeholder mithilfe einer RACI-Matrix (Responsibility, Accountability, Consulted und Informed) dokumentieren? Werden Sie sicherstellen, dass dieses Dokument von allen beteiligten Parteien diskutiert und vereinbart wird?

Ja. Alle diese Elemente (und mehr) werden im Joint Procedure Manual (JPM) zusammengetragen und dokumentiert. Das JPM wird von Lokad’s Supply Chain Scientists (SCSs) erstellt (mit direkt vom Kundenunternehmen gewonnenen Erkenntnissen). In diesem Dokument werden die Parameter der jeweiligen Rolle und Verantwortung jeder Person detailliert beschrieben.

Das JPM dient zudem als fortlaufende Ressource für die Initiative und wird von den den Kundenunternehmen zugeordneten SCSs verfasst. Die Erstellung dieses Dokuments in ihren eigenen Worten zeigt, dass die SCSs sich erheblich Zeit genommen haben, um die supply chain des Kunden und die übergeordnete Lösung zu untersuchen, zu diagnostizieren und zu analysieren (ohne einfach die bereits vorhandene Literatur des Kunden wiederzugeben).

Etwaige Überarbeitungen des JPM werden mit dem Kundenunternehmen geteilt. Das JPM selbst wird routinemäßig in Arbeitssitzungen zwischen Lokad und dem Kundenunternehmen besprochen.

In diesem Zusammenhang zeigt unsere Erfahrung, dass im Falle von Meinungsverschiedenheiten diese in der Regel ein organisatorisches Problem widerspiegeln, das im Kundenunternehmen gelöst werden muss. Deshalb empfehlen wir, dass das Kundenunternehmen einen Supply Chain Executive ernennt, der die Initiative überwacht. Eine seiner zentralen Aufgaben ist es, als Vermittler zu agieren, wenn solche Fälle auftreten.

3.5 Werden Sie sicherstellen, dass die Projektarbeitsgruppe und die Lenkungsausschüsse mit benannten Ressourcen der Projekt-Stakeholder gebildet werden? Werden Sie sicherstellen, dass der operative Rhythmus von allen beteiligten Parteien vereinbart wird?

Ja. Im Allgemeinen befolgen wir jeden Prozess, der vom Kundenunternehmen als notwendig erachtet und formell vereinbart wurde. Die vereinbarten Elemente (und alle Änderungen, die im Verlauf der Initiative vorgenommen werden) werden im Joint Procedure Manual (JPM) dokumentiert, das Details zur Projektarbeitsgruppe und zu den Lenkungsausschüssen enthält. Durch Lokad’s Supply Chain Scientists (SCSs) verfügen wir über die notwendigen Ressourcen, um diese Prozesse zu implementieren und zu überwachen.

Anekdotisch wird eine der am häufigsten geschätzten Beiträge von Lokad darin gesehen, dass wir in der Lage sind, Prozesse zu vereinfachen – sei es im Bereich supply chain oder bürokratisch. Im Laufe der Zeit arbeiten wir aktiv daran, unnötige bürokratische Ebenen aus den supply chains unserer Kunden zu entfernen.

4. Systemübergang & Go-Live

4.1 Wie lange dauert der Übergang vom Kick-off bis zum Go-Live?

Die typische Dauer der Onboarding-Phase beträgt 6 Monate. Diese Phase beginnt mit dem Kick-off und endet, wenn Lokad ‚in Produktion‘ ist – das heißt, wenn unsere automatisierten supply chain Empfehlungen den gewünschten Entscheidungsprozess des Kunden effektiv steuern.

Diese Dauer kann um 1 Monat verkürzt werden, wenn bereits ein data lake vorhanden ist – ein gut aufgebauter und dokumentierter data lake kann die Onboarding-Phase noch weiter verkürzen. Umgekehrt verlängert sich diese Phase typischerweise um 1 bis 3 Monate, wenn die Software- oder Systemumgebung des Kunden übermäßig komplex oder veraltet ist.

Interessanterweise ist die Komplexität der supply chain selbst nicht so ausschlaggebend, wie es scheinen mag, da Lokad bestrebt ist, einen so präzisen Umfang zu definieren, dass er innerhalb des vorgesehenen Zeitrahmens realisierbar ist. Unsere Erfahrung zeigt, dass Onboarding-Phasen, die länger als 6 Monate dauern, die Initiative in Gefahr bringen, zu stagnieren. Daher gestalten wir den Umfang aktiv, um dieses Risiko zu mindern.

Solche Verzögerungen haben wenig mit der technischen Einrichtung von Lokad selbst zu tun. Insgesamt dient der vorgeschlagene Zeitplan nicht nur technischen Zwecken (Automatisierung der Datenauszüge, Testen numerischer Rezepte usw.), sondern ermöglicht auch, dass Lokad’s Supply Chain Scientists (SCSs) sich vollumfänglich mit allen Besonderheiten des Kundenunternehmens vertraut machen und dass die supply chain Teams Lokad’s Ansatz „verinnerlichen“ – was in der Regel einen Bruch mit dem bisherigen Prozess des Kunden darstellt.

4.2 Wie viele Vor-Ort-Besuche planen Sie? Wie viele Workshops vor Ort planen Sie?

Die Anzahl der Vor-Ort-Besuche und Workshops wird im Rahmen der spezifischen vertraglichen Vereinbarungen mit dem Kundenunternehmen verhandelt, wobei zu beachten ist, dass Reisekosten die von Lokad berechneten Gebühren beeinflussen können. Somit ist die Einbeziehung von Vor-Ort-Besuchen letztlich eine Entscheidung, die vom Kundenunternehmen getroffen wird, und Lokad wird die gewünschte Frequenz berücksichtigen.

Wenn das Ziel des Kundenunternehmens darin besteht, die Initiative so schlank wie möglich zu halten, sind wir mit einer vollständig remote durchgeführten Initiative einverstanden, d. h. ohne Vor-Ort-Besuche. Wir empfehlen diesen Ansatz für kleinere Unternehmen (Jahresumsatz unter 100 M USD) sowie für Unternehmen, die generell mit Remote-Mitarbeitern vertraut sind (wie große eCommerce-Unternehmen). Etwa die Hälfte der von Lokad durchgeführten Initiativen gehört zu dieser Kategorie.

Wenn das Ziel des Kundenunternehmens darin besteht, die Chancen auf ein erfolgreiches Change Management zu maximieren, sind wir mit monatlichen Vor-Ort-Besuchen – und gegebenenfalls sogar häufiger – einverstanden. Für große Unternehmen (Jahresumsatz über 1 Mrd. USD) empfehlen wir mindestens einen vierteljährlichen Vor-Ort-Besuch/Workshop. Dieser Ansatz trägt dazu bei, eine unternehmensweite Abstimmung zu entwickeln, insbesondere wenn umfangreiche Teams beteiligt sind.

Bei unseren Kunden in Westeuropa finden tendenziell mehr Vor-Ort-Besuche (in der Regel von einem Tag Dauer) statt als Workshops, während bei unseren Kunden außerhalb Westeuropas in der Regel mehr Workshops (typischerweise über mehrere Tage) als Besuche durchgeführt werden. Dieser Unterschied ist lediglich auf die damit verbundenen Reisekosten und logistischen Gegebenheiten zurückzuführen.

4.3 Was ist das ideale Verhältnis zwischen Remote- und Vor-Ort-Meetings?

Bei einer quantitativen supply chain Initiative sollten die meisten Meetings remote stattfinden. Die meisten Meetings sind kurz (30 Minuten oder kürzer) und haben nur zwei Teilnehmer: einen Supply Chain Scientist von Lokad und einen supply chain Praktiker vom Kundenunternehmen. Darüber hinaus sind Remote-Meetings für spezifische technische Aufgaben von Vorteil, da alle Teilnehmer Zugriff auf ihren eigenen Computer inklusive großer Monitore haben. Dies ist besonders nützlich, wenn die Teilnehmer komplexe Berichte untersuchen müssen.

Lokad unterschätzt jedoch den Wert von Vor-Ort-Meetings mit Kunden nicht. Vor-Ort-Meetings erleichtern es oft, komplexe Ideen zu vermitteln, Perspektiven zu diskutieren und/oder Erwartungen zwischen den Parteien anzupassen. Deshalb empfehlen wir, einen regelmäßigen Rhythmus für Vor-Ort-Meetings einzuführen (z. B. wöchentlich/monatlich/vierteljährlich…). Lokad behandelt solche Vor-Ort-Meetings als bedeutende Ereignisse, insbesondere wenn Lokad den Kunden empfängt.

Dieser Ansatz ermöglicht es beiden Parteien, Remote-Meetings unaufdringlich, bequem und so häufig wie nötig abzuhalten.

4.4 Unterstützen Sie das Kundenunternehmen bei der Durchführung einer Qualitätsprüfung der Produktionsumgebung, um die Bereitschaft für den Go-Live zu bewerten, einschließlich der Einrichtung von Schnittstellen?

Ja. Tatsächlich geht Lokad über die reine Unterstützung des Kundenunternehmens bei der Bewertung der Go-Live-Bereitschaft hinaus. Eine der Hauptaufgaben von Lokad’s Supply Chain Scientists (SCSs) besteht darin, die Verantwortung für die End-to-End-Lösung zu übernehmen, die dem Kundenunternehmen geliefert wird. Mit anderen Worten, auch wenn ein mechanisiertes System (eine Flotte von Maschinen) die Ergebnisse erzeugt, ist es dennoch eine Person, die die persönliche Verantwortung für das System übernimmt. Sie stellen die Genauigkeit, Relevanz und Angemessenheit der End-to-End-Datenverarbeitungskette sicher – und berücksichtigen dabei auch die übergeordneten Geschäftsbelange des Kunden.

Angesichts ihrer fehleranfälligen Natur verdienen Software-Schnittstellen besondere Aufmerksamkeit, und die SCS sind gut ausgestattet, um bei der Bewertung ihrer Integrität zu unterstützen. Lokad bewertet diese Integrität auf der ingress-Seite (wenn Lokad historische Daten vom Kundenunternehmen erhält) und auf der egress-Seite (wenn Lokad supply chain decisions an das Kundenunternehmen zurückgibt). Für diese Aufgabe nutzt Lokad spezifische Methoden und Technologien.

Bitte lesen Sie programming paradigms for supply chain, um besser zu verstehen, welche Art von Technologien Lokad einsetzt, um die Einsatzbereitschaft sicherzustellen.

4.5 Bereiten Sie das Dokument zur Produktionsübergangs- und Migrationsstrategie vor, um den nahtlosen Übergang der Geschäftsabläufe (von der bestehenden Geschäftsapplikation zur neuen Geschäftsapplikation) für das Kundenunternehmen zu steuern?

Ja. Der Übergang wird in unserem Joint Procedure Manual (JPM) dokumentiert. Diese umfangreiche Dokumentation, erstellt von Lokad’s Supply Chain Scientists (SCSs), stellt sicher, dass sowohl supply chain practitioners als auch supply chain executives Zugang zu gut formulierten Materialien haben, die den Prozess verständlich erklären. Die SCSs unternehmen besondere Anstrengungen, um sicherzustellen, dass dieses Dokument auch für ein nicht-technisches Publikum zugänglich ist (obwohl einige Anlagen recht technisch sein können).

Außerdem ist Lokads Dual-run-Ansatz einzigartig geeignet, um einen reibungslosen Übergang vom legacy Prozess zur neuen Lösung zu gewährleisten. „Dual-run“ bezeichnet in diesem Zusammenhang die Praxis, bei der Lokad parallel zum legacy Entscheidungsprozess über den gesamten Umfang der Initiative läuft. Diese Praxis wird ausschließlich durch die robotisierte Natur des legacy Entscheidungsprozesses von Lokad ermöglicht, was sicherstellt, dass die numerischen Rezepte, die von Lokad’s SCSs implementiert wurden, über den gesamten Umfang über Wochen hinweg unter exakten Produktionsbedingungen zufriedenstellend liefen, bevor der tatsächliche go-live erfolgt, bei dem Lokad’s Entscheidungen den legacy Prozess ablösen.

Es muss darauf hingewiesen werden, dass ein solcher dual-run typischerweise mit alternativen Technologien und Methoden, wie sie von unseren Wettbewerbern vorgeschlagen werden, nicht möglich ist. In der Tat, da sie die supply chain decisions nicht robotisieren, sind die Overheads, die mit einem dual-run verbunden sind, erheblich. Infolgedessen wird der dual-run bestenfalls in einem kleinen Umfang durchgeführt, der die Produktionsbedingungen nicht wirklich widerspiegelt. Daher führt, wenn ein solcher Ansatz übernommen wird, die späte Erweiterung des Umfangs unvermeidlich zu Produktionsvorfällen, die mit einem full-scope dual-run vollständig vermeidbar gewesen wären.

4.6 Stellen Sie den Umfang, Zeitpläne und Erfolgskriterien für den Pilotlauf zur Überprüfung und Freigabe durch das Kundenunternehmen bereit?

Ja. Der Umfang ist immer im vertraglichen Abkommen zwischen Lokad und dem Kundenunternehmen detailliert festgehalten. Er nimmt üblicherweise die Form einer bestimmten Art von supply chain decision (z. B. Bestandsauffüllung oder Lagerzuweisung) über einen festgelegten Satz von Standorten und/oder über ein Set von Geschäftssystemen an.

Der Zeitplan liegt typischerweise unter 6 Monaten (vom Kick-off bis zur Produktion). Während in unserem kommerziellen Angebot stets ein voraussichtlicher Zeitplan enthalten ist, wird er möglicherweise nicht im vertraglichen Abkommen festgeschrieben. Der verbindliche Zeitplan stellt ein beiderseitiges Engagement dar, und das Tempo der Lokad-Initiative hängt von der rechtzeitigen Ausführung bestimmter Schritte durch das Kundenunternehmen ab, insbesondere vom Aufbau einer Datenpipeline zu Lokad.

Hinsichtlich der Erfolgskriterien wird die Entscheidung stets einseitig vom Kundenunternehmen getroffen. Zwar können wir die Leitprinzipien dokumentieren, die diese Entscheidung untermauern sollten, jedoch wäre eine nicht einseitige Entscheidung ungewöhnlich. Einfach ausgedrückt, sollte ein Anbieter nicht in der Position sein zu entscheiden, dass der Pilot erfolgreich war, wenn das Kundenunternehmen eine andere Meinung hat.

Siehe auch Project Implementation & Management 1.2.

Bitte konsultieren Sie Assessing the Success of a die Quantitative Supply Chain Initiative für weitere Details zu diesem differenzierten Punkt.

4.7 Organisieren Sie die Durchführung von Pilotläufen, um a) die Datenangemessenheit, b) die Systemkonfiguration und Anwendungsbereitschaft, c) die Einhaltung von Prozessen/Systemen und d) die generelle Zweckmäßigkeit sicherzustellen?

Ja. In der Regel behandeln wir einen Pilotlauf – der supply chain optimization liefern soll – genau so, wie wir eine „echte“ Initiative behandeln würden, die in die Produktion überführt werden soll. Im Grunde genommen ist, was die supply chain optimization betrifft, ein adäquater Pilotlauf nicht von einer Vorproduktionsumgebung zu unterscheiden, die für den Produktionseinsatz freigegeben wurde.

Lokads Team von Supply Chain Scientists (SCSs) ist für all das oben Genannte verantwortlich. Nach unserer Erfahrung ist die Datenangemessenheit in Unternehmen, die bereits vor vielen Jahren (wenn nicht Jahrzehnten) digitalisiert wurden, selten ein Problem. Solange ein Geschäftssystem vorhanden ist, das erfasst, was gekauft, produziert, gelagert und verkauft wird, ist die Initiative nahezu garantiert, über ausreichende Daten zu verfügen. Die Herausforderung besteht darin, die Daten zu interpretieren, die ursprünglich nicht zur Unterstützung der Optimierung der supply chain erhoben wurden.

Siehe bad data für weitere Informationen zu diesem Punkt.

5. Change- und Risikomanagement

5.1 Welche Unterstützung können Sie dem Kundenunternehmen anbieten, um das Change Management im Zusammenhang mit der Implementierung der Initiative zu bewältigen?

Alle Kunden genießen die volle Unterstützung von Lokad’s Supply Chain Scientists (SCSs), die alle darin geschult sind, die technischen und nicht-technischen Anforderungen einer supply chain optimization Initiative zu bewältigen. Die SCSs unterstützen den Change Management-Prozess in vielerlei Hinsicht, unter anderem durch:

• Vorschläge zur Verbesserung bestehender Prozesse für die supply chain practitioners des Kundenunternehmens.

• Erstellung von Schulungsmaterialien, um Mitglieder/Teams des Kundenunternehmens einzuarbeiten.

• Unterstützung des supply chain Managements, indem der Einfluss der Änderungen auf die supply chain in Dollar oder Euro (oder in der Währung der Wahl des Kunden) quantifiziert wird.

Es muss angemerkt werden, dass Change Management einen erheblichen Zeitaufwand für einen SCS darstellen kann. Während jeder SCS über individuell geeignete Fähigkeiten und Erfahrungen verfügt, um die supply chain Führung in Sachen Change Management zu unterstützen, konkurriert diese Aufgabe mit all seinen anderen Pflichten.

Daher legen die zwischen Lokad und jedem Kunden ausgehandelten vertraglichen Bedingungen den Ressourceneinsatz – d. h. die Größe des SCS-Teams – fest, der zur Unterstützung der Initiative zur Verfügung steht. Unsere kommerziellen Angebote gehen in der Regel davon aus, dass die SCSs eine gewisse Unterstützung im Change Management bieten. Allerdings spiegeln unsere Angebote normalerweise keine Art von „groß angelegter“ Unterstützung im Change Management wider – es sei denn, dies wird ausdrücklich vom Kunden angefordert.

5.2 Wie stellen Sie sich das Change Management während der Produktionsphase vor? Was sind die Hauptmeilensteine? Wie sieht die neue Organisation nach erfolgreicher Implementierung der neuen Lösung aus?

Sobald Lokad in Produktion ist, wird eine gesamte Klasse von supply chain decisions automatisiert. Ziel ist es dann, die supply chain Praxis in ein kapitalistisches Unterfangen zu verwandeln. Jede Stunde, die ein supply chain practitioner investiert, sollte zur kontinuierlichen Verbesserung der numerischen Rezepte beitragen. Dies stellt einen Bruch mit der „Mainstream“-supply chain Praxis dar, in der der Großteil der täglichen Anstrengungen darauf verwendet wird, das Unternehmen für einen weiteren Tag am Laufen zu halten. Natürlich erfolgt der Übergang zu dieser wertschöpfenden Form der supply chain allmählich.

• Der erste Meilenstein besteht darin, dass die supply chain practitioners anerkennen, dass Lokad ihnen ermöglicht, den Großteil des legacy Prozesses zu verwerfen. Zum Beispiel macht es Sinn, die täglichen Bestandsauffüllungsmengen zu überprüfen, wenn diese Mengen häufig fehlerhaft sind. Allerdings sind Lokads Mengen per Design bereits verlässlich und bedürfen keiner weiteren Überprüfung. Tatsächlich ist 0% Unsinn in den von Lokad generierten Zahlen das Hauptkriterium für einen Produktions-go-live. Das Vertrauen, das supply chain practitioners in Lokad’s Zahlen setzen, schafft naturgemäß viel Zeit, die sinnvoller genutzt werden kann.

• Der zweite Meilenstein besteht darin, einige „Early Adopters“ unter den supply chain practitioners zu haben. Dabei handelt es sich typischerweise um Personen, die es schnell schaffen, sich vom nicht wertschöpfenden legacy Prozess zu lösen – z. B. das manuelle Überprüfen von Zahlen – um sich auf die kontinuierliche Verbesserung der supply chain durch ihre numerischen Rezepte zu konzentrieren. Sie können beginnen, zahlreiche wichtige Fragen zu bearbeiten, die über rein technische Aspekte hinausgehen (beispielsweise, ob das Kundenunternehmen seine Servicequalität aus der richtigen Perspektive betrachtet).

• Der dritte Meilenstein besteht darin, dass der Großteil der supply chain practitioners den Blick nach außen richtet (auf Kunden und Lieferanten) anstatt nur nach innen. Letztlich muss die supply chain eine Abstimmung erreichen, die über die Grenzen des Kundenunternehmens hinausgeht. Dies erweitert den Pool der gewonnenen Erkenntnisse und hilft, die numerischen Rezepte weiter zu verfeinern.

Die neue Organisation entspricht eher einem Softwareunternehmen. Es gibt nur wenige repetitive supply chain Aufgaben, die manuell bearbeitet werden – da repetitive Aufgaben nun automatisiert sind. Ebenso gibt es viel weniger Notfälle (ebenfalls aufgrund der Automatisierung). Die Reduktion routinemäßiger Aufgaben führt zu einer größeren Vielfalt an Aufgaben für den supply chain practitioner. In der Regel bedeutet dies, dass weniger Zeit und Mühe auf die Kontrolle der supply chain verwendet wird, jedoch wird von der Geschäftsführung erwartet, dass sie die Mitarbeiter weiterqualifiziert, damit diese die gewonnenen zusätzlichen Kapazitäten optimal nutzen können.

Siehe (Software) Product-oriented Delivery for Supply Chain für weitere Informationen zu diesem Übergang.

5.3 Wie gehen Sie mit der Änderung von Arbeitsabläufen für Endnutzer um? Zunächst beim Lokad-Onboarding, zweitens mit der eigenen Weiterentwicklung von Lokad.

Per Design erfordern die von Lokad generierten supply chain decisions keine Arbeitsabläufe. Tatsächlich ist es der angestrebte Zustand, alle Schritte, die bei der Generierung der supply chain decisions anfallen, zu automatisieren.

Wenn jedoch ausdrücklich vom Kunden gewünscht, ist Lokad in der Lage, einen „workflow“ einzuführen, der den legacy Prozess widerspiegelt. Dies, so ist zu verstehen, dient ausschließlich der Erleichterung des Change Managements und ist in keiner Weise eine Voraussetzung für den Erfolg des numerischen Rezepts. Sobald die Mitarbeiter des Kunden mit den von Lokad generierten Entscheidungen vertrauter werden und mehr Vertrauen in sie entwickeln, kann der „workflow“ schrittweise vereinfacht werden, bis er vollständig entfernt ist.

Hinsichtlich Lokads Weiterentwicklung ist unsere Plattform programmatisch und wird von Envision (unserer domänenspezifischen Programmiersprache) gesteuert. Jegliche Änderungen/Updates an Envision erfolgen über automatisierte Skripte, und dieser Prozess ist so programmiert, dass die supply chain initiatives, die von Lokad gehostet werden, unberührt bleiben.

5.4 Können Sie ein Register für Issues & Risks führen, das einen Minderungsplan, Aufgaben, Verantwortlichkeiten, Zeitpläne und den Status (nicht begonnen, in Bearbeitung, abgeschlossen, pausiert) umfasst? Wird der Projektmanager von Lokad dafür verantwortlich sein, alle Issues & Risks zu verfolgen und eine rechtzeitige Lösung oder bei Bedarf das Eskalationsmanagement sicherzustellen?

Ja. Lokads Plattform verfügt über ein eigenes internes Issue-/Ticket-/Task-Manager. Diese Funktion bietet alle üblichen Möglichkeiten, die man von einem solchen Tool erwartet, wie das Verwalten von Status, Prioritäten, Zuweisungen, Benachrichtigungen usw. Zudem führen wir separat ein Joint Procedure Manual (JPM), das eine umfassende und gut strukturierte Darstellung der Initiative mit allen relevanten übergeordneten Zeitplänen liefert. Lokads Supply Chain Scientists (SCSs) sind für die Überwachung des Task-Managers verantwortlich. Sie stellen sicher, dass Probleme und Bedenken umgehend adressiert werden.

Eskalationen sind möglich, aber selten. Derselbe SCS, der die Aufgaben verwaltet/prüft, wird sie auch lösen. Senior SCSs bei Lokad erfüllen eine Vielzahl von Rollen: supply chain expert, data engineer, data integrator, business analyst, data scientist, project manager, change consultant usw.

Die Möglichkeit, SCSs unkompliziert zu kontaktieren, wird von unseren Kunden routinemäßig als großer Vorteil genannt. Der Kunde kann sofort mit der Person interagieren, deren Aufgabe es ist, die zufriedenstellende Lösung von Problemen zu überwachen, anstatt mehrere Ebenen der Bürokratie durchlaufen zu müssen, um – hoffentlich – mit jemandem zu sprechen, der in der Lage ist, ihm zu helfen.

Falls ein Problem auftritt, das Fähigkeiten erfordert, die außerhalb der Expertise eines SCS liegen (z. B. ein technisches Problem mit der Architektur der Plattform), überwacht er dennoch die zeitnahe Lösung des Problems und fungiert als erster Ansprechpartner für den jeweiligen Kunden.

5.5 Bieten Sie Beratung im Bereich organisatorisches Change Management an, um die Einführung und Änderung von Geschäftsprozessen sowie die Stilllegung bestehender Prozesse anzugehen?

Ja, sofern das Kundenunternehmen wünscht, dass seine Partnerschaft mit Lokad auch Beratungsdienstleistungen im Change Management umfasst. Es sei darauf hingewiesen, dass Lokads primäre Expertise in der prädiktiven Optimierung der supply chain liegt und nicht im Change Management. Unser Ansatz im Change Management ist zudem konventioneller als unsere supply chain Praktiken. Dieser Ansatz würde – sofern umgesetzt – die Anzahl der am Projekt beteiligten Dritten begrenzen.

Andernfalls, falls das Kundenunternehmen es vorzieht, die Dienste eines Change Management-Spezialisten zusätzlich zu Lokad in Anspruch zu nehmen, unterstützen wir es, indem wir so viel teilen, wie das Kundenunternehmen für angemessen hält.

6. Customization & System Functionality

6.1 Organisieren Sie Sitzungen, um die Anforderungen an Anpassungen zu priorisieren, und stellen dabei sicher, dass die geschäftlichen Auswirkungen aufgrund von Produktlücken verstanden und eine gemeinsame Übereinkunft bezüglich der Priorisierung von Anpassungsfreigaben erzielt werden?

Ja. Lokad’s Supply Chain Scientists (SCSs) sind für diesen Prozess verantwortlich. Tatsächlich zeichnet sich Lokad in Bezug auf diese Priorisierung in zweierlei Hinsicht aus. Erstens ist ein SCS in der Lage, die Anpassung eigenständig umzusetzen und kann somit klare Einblicke in die in Bezug auf Ressourcen und Zeitplan anstehende Problematik geben.

Dies verbessert die Qualität der Priorisierung erheblich, da das Kundenunternehmen von einem Experten profitiert, der die Vorteile einer beliebigen supply chain Veränderung stets mit den damit verbundenen Kosten abwägen kann.

Zweitens betont ‘die Quantitative Supply Chain’ – Lokad’s übergreifende Philosophie – eine rein finanzielle Perspektive. Daher unterstützt der SCS das Kundenunternehmen dabei, quantitative Schätzungen (in Dollar oder Euro) über die Auswirkungen einer potenziellen Veränderung an der Lösung zu liefern. Diese Strategie verfeinert die Initiative, indem sie den traditionellen Engpass vermeidet, in dem diskutiert wird, was priorisiert werden sollte. Stattdessen strafft Lokad diesen Prozess, indem es Themen priorisiert, die den größten finanziellen Einfluss haben.

6.2 Können Sie eine Fit-Gap-Analyse aller Geschäftsprozesse durchführen, um Automatisierungspotenziale zu identifizieren, die angestrebten zukünftigen Prozesse zu dokumentieren und Lücken in der Produktfunktionalität zu ermitteln? Können Sie akzeptable Workarounds vorschlagen, wenn Lücken in der Produktfunktionalität festgestellt werden?

Ja. Lokads Supply Chain Scientists (SCSs) sind für diesen Prozess verantwortlich. Während zu Beginn der Initiative eine erste Studie durchgeführt wird, läuft dieser Prozess während der gesamten Produktionsphase weiter. Es ist Teil unseres Ansatzes, kontinuierliche Verbesserungen der Lösung anzustreben.

Soweit die supply chain Optimierung betrifft, sind Lücken selten eine Frage der ‚Funktionalität‘, sondern vielmehr der ‚Performance‘. Zum Beispiel besteht die Herausforderung nicht nur darin, Auffüllmengen zu generieren (Funktionalität), sondern sicherzustellen, dass die generierten Mengen die profitabelsten sind (Performance).

Daher befassen sich die SCSs mit der Identifizierung und Behebung von ‚Performance-Lücken‘, die manchmal zusätzliche Funktionalitäten oder eine Neuerfindung der Lösung erfordern. Dies kann bedeuten, dass Funktionen hinzugefügt oder entfernt werden, um die Gesamtleistung zu optimieren.

In diesem Zusammenhang ist Lokads Plattform programmatisch. Daher können wahrgenommene ‚Funktionalitätslücken‘ durch das Einführen (oder Anpassen) weniger Zeilen Envision-Code behoben werden. Diese Programmierbarkeit ist genau das, was es Lokad ermöglicht, maßgeschneiderte Lösungen für jeden Kunden bereitzustellen.

6.3 Können Sie eine detaillierte Agenda für die Prozess-Fit-Gap-Analyse-Workshops bereitstellen, einschließlich der Erwartungen der Fachexperten (SMEs) auf Kundenseite, und dies mindestens eine Woche vor Beginn der Workshops?

Ja. Lokads Supply Chain Scientists (SCSs) stellen für jeden Workshop eine Agenda bereit. Wir stellen sicher, dass die Agenda mindestens eine Woche vor der Veranstaltung kommuniziert wird. Werden vom Kundenunternehmen explizite Anweisungen, wie beispielsweise ein Zeitrahmen zur Bereitstellung der Agenda(s), gegeben, dann befolgen wir diese. Fehlen solche Anweisungen, strukturieren wir die Workshops (einschließlich Zeitplan und der notwendigen Schritte auf Kundenseite) auf intelligente und professionelle Weise.

6.4 Stellen Sie sicher, dass die Anforderungsdokumente zur Produktanpassung gemeinsam überprüft und vom Kundenunternehmen genehmigt werden?

Ja, diese Dokumente werden dem Kundenunternehmen zur Verfügung gestellt und anschließend von ihm genehmigt.

Bitte beachten Sie, dass die Designentscheidungen der Lokad-Plattform den Bedarf an ‚Anpassung‘ weitgehend überflüssig machen – zumindest in der Weise, wie dieser Begriff üblicherweise in der Unternehmenssoftware verstanden wird. Lokads Plattform ist programmatisch und nutzt Envision – unsere DSL (domänenspezifische Programmiersprache), die der prädiktiven Optimierung von supply chain gewidmet ist.

Somit sind Lokads Lösungen immer ‚kundenspezifisch‘, insofern als sie vollständig auf die spezifischen Bedürfnisse des Kundenunternehmens zugeschnitten sind. Diese Anpassung erfolgt jedoch in einer Weise, die die Lösung als Teil von Lokads Hauptproduktlinie belässt. Dies ist Lokads bevorzugter (und bewusst entworfener) Ansatz und führt zu keinen Wartungsproblemen.

6.5 Unterstützen Sie das Kundenunternehmen beim Einrichten der Schnittstellenanbindung an externe Systeme sowie beim Testen und Zertifizieren der Schnittstellen?

Ja. Lokads Supply Chain Scientists (SCSs) unterstützen dabei, die Schnittstellen zwischen den vom Kundenunternehmen betriebenen Systemen und Lokad einzurichten, zu testen, zu validieren und zu dokumentieren. Für sehr technische Aspekte auf niedriger Ebene, wie Netzwerke oder Sicherheitsprotokolle, können die SCSs durch interne IT-Ressourcen bei Lokad ergänzt werden.

Die Systemschnittstellen werden in der Regel nicht von einer externen Zertifizierungsstelle zertifiziert. Die Schnittstellen werden durch technische Spezifikationen, die zwischen der IT-Abteilung des Kundenunternehmens und Lokad gemeinsam vereinbart wurden, ‚formell festgelegt‘. Diese technischen Spezifikationen unterstützen die gegenseitigen Verpflichtungen der Unternehmen: Kurz gesagt, verpflichtet sich das Kundenunternehmen, Lokad die erforderlichen Daten rechtzeitig zur Verfügung zu stellen; Lokad wiederum verpflichtet sich, die Ergebnisse ebenfalls rechtzeitig zu liefern.

6.6 Stellen Sie während der Workshops Dokumente zu den Schnittstellenspezifikationen zur Verfügung, einschließlich Beispieldaten (sample messages)?

Ja, Lokad stellt während der Workshops Schnittstellenspezifikationen bereit. Beispieldaten können auf Wunsch des Kundenunternehmens eingebunden werden.

Aufgrund der Natur von Lokads Service werden die „Beispieldaten“ jedoch sehr wahrscheinlich in Form von Tabellen dargestellt – da dies die von Lokad für den Kunden generierten Ergebnisse genauer widerspiegelt. Zur Orientierung: Der Großteil der technischen Spezifikationen der Schnittstellen konzentriert sich auf Tabellen und deren Formate sowie auf Tabellenextraktionsmuster und Übertragungspläne.

6.7 Teilen Sie die Prozesse für Änderungsanfragen und Release-Management?

Ja. Lokads Supply Chain Scientists (SCSs) sind für diesen Prozess verantwortlich. Es ist wichtig zu beachten, dass Lokad über zwei Ebenen von Änderungen und Releases verfügt, was sich von typischer Unternehmenssoftware unterscheidet.

Erstens werden Änderungen, die speziell für Kunden vorgenommen werden, von den SCSs selbst implementiert. Diese Änderungen treten häufig auf, oft mehrmals am Tag, insbesondere während der Onboarding-Phase. Solche Änderungen erfolgen als direkte Reaktion auf die Bedürfnisse des Kundenunternehmens und beinhalten umfangreiche Kommunikation zwischen beiden Parteien.

Zweitens nehmen wir Aktualisierungen an Lokads Plattform vor, in der Regel durch Updates an Envision – unserer DSL (domänenspezifische Programmiersprache), die der prädiktiven Optimierung von supply chain gewidmet ist. Diese Änderungen sind so gestaltet, dass sie für die Kundenunternehmen transparent sind. Falls gewünscht, können die Details zu diesen Updates bereitgestellt werden, und ein Großteil dieser Informationen wird öffentlich zugänglich gemacht.

Siehe Envision VM Environment and General Architecture für weitere Informationen zur Entwicklung von Lokads Plattform.

7. User Acceptance Testing (UAT)

7.1 Unterstützen Sie das Kundenunternehmen beim Einrichten der UAT (User Acceptance Testing)-Testumgebung mit kontextspezifischen Daten und Systemkonfigurationen?

Ja. Lokads Supply Chain Scientists (SCSs) sind für diesen Prozess verantwortlich. Lokad bietet einzigartige methodische und technische Innovationen zur Unterstützung dieses Vorhabens.

Methodisch bevorzugen wir die Erstellung von priorisierten Listen, in denen die Elemente nach abnehmendem Return on Investment (ROI) für das Unternehmen geordnet werden. Dieser Aspekt ist entscheidend, um sicherzustellen, dass die Zeit der Endnutzer nicht mit der Durchsicht großer Mengen weitgehend irrelevanter Daten verschwendet wird.

Technologisch ist Lokads Plattform speziell darauf ausgelegt, für jede Initiative mehrere Umgebungen gleichzeitig zu unterstützen. Diese Umgebungen sind ein natives Merkmal unserer Multi-Tenant SaaS-Plattform und können daher mit minimalem Overhead sowohl in Bezug auf Rechenressourcen als auch auf die Systemadministrationszeit eingeführt werden.

Siehe auch User Acceptance Testing 7.3.

7.2 Konfigurieren Sie die UAT (User Acceptance Testing)-Vorproduktions-, Produktions- und Schulungsumgebungen gemäß den definierten ToBe-Prozessen?

Ja. Aufgrund der umfangreichen Programmierbarkeit von Lokads Plattform können wir die Konfigurationen vollständig steuern. Dies wird durch Envision – unsere DSL (domänenspezifische Programmiersprache), die der prädiktiven Optimierung von supply chains gewidmet ist – ermöglicht.

Dieser Ansatz ermöglicht es, dass verschiedene Umgebungen dieselbe Konfiguration für alle unveränderlichen Teile verwenden – indem möglichst derselbe Code verwendet wird. Dies reduziert versehentliche Unterschiede zwischen den Umgebungen erheblich, die Nutzer verwirren und die Integrität des UAT-Prozesses gefährden können.

Darüber hinaus ist es mit unserem Design unkompliziert, eine Einrichtung von einer Stufe zur nächsten zu überführen. Die Verwendung einer Codebasis für Konfigurationsänderungen ist effizienter als herkömmliche Methoden über eine Benutzeroberfläche.

7.3 Stellen Sie dem Kundenunternehmen und externen Systemen separate UAT (User Acceptance Testing)-, Datenmigrations-, Produktionsphase (Pre-Prod)-, Produktions- und Schulungsumgebungen für das Produkt (einschließlich der erforderlichen Schnittstellen) zur Verfügung?

Ja. Lokads Plattform ist speziell darauf ausgelegt, für jede Initiative mehrere Umgebungen gleichzeitig zu unterstützen. Diese Umgebungen sind ein natives Merkmal unserer Multi-Tenant-SaaS-Plattform und können daher mit minimalem Overhead sowohl in Bezug auf Rechenressourcen als auch auf die Systemadministrationszeit eingeführt werden.

Bei Lokad erfolgt die Duplizierung der gesamten Produktionsumgebung, einschließlich aller Produktionsdaten, ohne dass der Speicherbedarf verdoppelt wird. Intern werden identische Daten zwischen den beiden Umgebungen gemeinsam genutzt. Darüber hinaus stellt unser Constant-Time-Design sicher, dass die Arbeitslast einer Umgebung die Leistung einer anderen Umgebung nicht negativ beeinflusst.

Die meisten Anbieter von Unternehmenssoftware umgehen das ganze Problem jedoch, indem sie einfach die Hauptkonfiguration ‚klonen‘. Klonen – also eine direkte Duplizierung – ist einfach, aber verschwenderisch. Klonen bedeutet, dass die Ressourcen (Menschen und Maschinen) mit der Anzahl der Umgebungen linear zunehmen – beispielsweise verdreifachen drei Umgebungen die ursprünglichen Kosten. Für jede umfangreiche supply chain resultiert dies in beträchtlichen Kosten.

7.4 Garantieren Sie die rechtzeitige Behebung aller Mängel, um sicherzustellen, dass das UAT (User Acceptance Testing) innerhalb der einvernehmlich festgelegten Zeitrahmen abgeschlossen wird?

Ja, sofern differenzierte Definitionen von ‚Lösung‘ und ‚Mangel‘ vereinbart werden können. Insgesamt sind Lokads Supply Chain Scientists (SCSs) dafür verantwortlich, alle Probleme zu beheben, die das Kernziel der Initiative untergraben: die Steigerung des Return on Investment. In einem typischen Szenario schlägt der SCS eine geeignete Maßnahme und einen entsprechenden Zeitrahmen vor, den das Kundenunternehmen validiert oder nach eigenem Ermessen anpasst.

Es ist wichtig hervorzuheben, dass es in Bezug auf supply chain keine perfekten Lösungen gibt, sondern nur bessere und schlechtere Abwägungen. Anders ausgedrückt, ein Problem, bei dem zwei oder mehr Werte völlig im Widerspruch zueinander stehen, kann nicht wirklich gelöst werden.

Beispielsweise ist abgelaufener verderblicher Lagerbestand verschwenderisch, aber beim Umgang mit verderblichen Produkten kann dieser Abfall nicht vollständig vermieden werden, ohne ein entsprechendes Qualitätsproblem zu verursachen. Es muss ein Gleichgewicht zwischen veraltetem Lagerbestand und Fehlbeständen gefunden werden. Dennoch sind sowohl ‚veralteter Lagerbestand‘ als auch ‚Fehlbestände‘ in gewisser Weise als Mängel zu betrachten.

Kurz gesagt, können SCSs ‚alltägliche‘ Probleme lösen, sobald sie auftreten, wie zum Beispiel das Beheben eines Parsing-Fehlers beim Einlesen einer Datei (ein Softwarefehler). Das übergeordnete Ziel einer quantitativen supply chain-Lösung besteht jedoch nicht darin, „Probleme zu lösen“, sondern den Return on Investment (in Dollar oder Euro) zu steigern. Lokad erreicht diese Art der „Lösung“ durch einen intelligenten, finanzgetriebenen Ansatz zur Abwägung von supply chain-Entscheidungen.

7.5 Unterstützen Sie das Kundenunternehmen bei der Überprüfung der UAT (User Acceptance Testing)-Szenarien, Testfälle und Testdaten?

Ja. Lokads Supply Chain Scientists (SCSs) sind für diesen Prozess verantwortlich.

Allerdings sind im Hinblick auf die supply chain Optimierung Datensätze, die kleiner als die gesamte Produktionsumgebung sind, in der Regel nicht ausreichend. In der Praxis müssen Szenarien, Testfälle und Testdaten (nahezu) so groß wie die Produktionsumgebung sein, um eine End-to-End-Perspektive der supply chain abzubilden. Diese Anforderung hat nichts mit Lokad zu tun; sie ist einfach eine Eigenschaft der supply chain.

7.6 Garantieren Sie Vor-Ort-Support in der Zentrale des Kundenunternehmens während der UAT (User Acceptance Testing)-Phase?

Ja. Der Vor-Ort-Support unterliegt der vertraglichen Vereinbarung zwischen Lokad und dem Kundenunternehmen. Dieser Aspekt wird stets individuell pro Kunde verhandelt.

Es ist anzumerken, dass eine quantitative supply chain-Initiative mit Lokad eine kontinuierliche supply chain-Verbesserung vorsieht, sodass es keinen festen UAT-Zeitraum gibt. Die Tests beginnen typischerweise Ende des zweiten Monats, erreichen ihren Höhepunkt im vierten Monat und stabilisieren sich ab dem sechsten Monat.

Durch die fortlaufende Bereitstellung von Ressourcen zur Verfeinerung unserer numerischen Rezepte (Algorithmen, die der Optimierung der supply chain gewidmet sind) stellt Lokad sicher, dass jeder Kunde eine aktuelle Initiative hat.

Siehe auch Project Implementation & Management 1.7.

8. Post-Implementation Support & Auditing

8.1 Können Sie sicherstellen, dass die Beobachtungen aus den Pilotläufen dokumentiert werden und alle Maßnahmen den zuständigen Stakeholdern in den technischen, IT- und Lieferantenabteilungen des Kundenunternehmens zugewiesen und bis zum Abschluss verfolgt werden?

Ja. Lokads Supply Chain Scientists (SCSs) erstellen und pflegen ein Joint Procedure Manual (JPM) für jede Initiative. Es enthält alle relevanten Erkenntnisse für die Initiative. Wichtig ist, dass das JPM so gestaltet ist, dass es auch für nicht-technische Zielgruppen zugänglich ist (obwohl einige Abschnitte und Anhänge recht technisch sind).

Hochrangige Maßnahmen werden im JPM dokumentiert. Kleinere Maßnahmen werden jedoch in der Regel über den Task Manager auf Lokads Plattform abgewickelt. Diese kleineren Aufgaben sind kurzfristig und der Task Manager ermöglicht ein effizienteres Nachverfolgen und Abschließen als das JPM.

8.2 Können Sie sicherstellen, dass ausreichend Qualitäts- und Compliance-Berichte zur Überwachung der Nutzung und Akzeptanz des Systems verfügbar sind?

Ja. Lokads Supply Chain Scientists (SCSs) implementieren in der Regel dedizierte Instrumente für diesen Zweck in der abschließenden Phase des Onboardings, kurz vor dem offiziellen Kick-off.

Zusätzlich kann Lokad die Übereinstimmung zwischen den von ihm generierten supply chain-Entscheidungen und den tatsächlichen Entscheidungen in der supply chain verfolgen. Dies erfolgt, um potenzielle Ursachen für Abweichungen zu identifizieren, wie z.B. Fehler oder Störungen in den Systemen des Kunden, die die Umsetzung von Lokads Empfehlungen beeinträchtigen könnten.

8.3 Führen Sie ein jährliches Audit der Anwendung durch und geben Sie Rückmeldung zur Verbesserung der Nutzung und der Endnutzerakzeptanz des Systems, um den ROI (Return on Investment) schneller zu realisieren?

Ja, ein jährliches Audit der gesamten Lösung (End-to-End) ist Standardprozedur. Allerdings führen Lokads Supply Chain Scientists (SCSs) in der Regel mehrere Audits der gesamten Lösung im Laufe des Jahres durch. Das jährliche Audit mündet in der Regel in eine detaillierte Roadmap-Präsentation für die Führungsebene des Kunden. Dies steht im Einklang mit unserem Ansatz der kontinuierlichen Verbesserung für jede Initiative.

Bezüglich der Nutzung implementieren SCSs in der Praxis proaktiv dedizierte Tools schon früh, um die Nutzung, Akzeptanz und Einhaltung der supply chain Entscheidungen, die Lokad generiert, zu überwachen. Während ein jährlicher Audit eine ausgezeichnete Gelegenheit bietet, notwendige Anpassungen vorzunehmen, sind unsere SCSs sehr proaktiv, wenn es um die Übernahme der Lokad’s supply chain Empfehlungen geht. Dieses Thema wird in unseren wöchentlichen Arbeitssitzungen besprochen, da die Übernahme der Lokad’s Empfehlungen der primäre Treiber für einen erhöhten ROI in einer Initiative der Quantitative Supply Chain ist.

8.4 Können Sie sicherstellen, dass das dedizierte Produktsupport-Team, das am Hauptsitz des Kundenunternehmens angesiedelt ist, das Produkt mindestens 6 Monate nach dem Go-live weiterhin unterstützt?

Ja. Das Team von Lokad’s Supply Chain Scientists (SCSs) kümmert sich um diese Aufgabe. Unsere SCSs sind umfassend geschult, um sowohl die Initiative kontinuierlich zu verbessern als auch dem Kunden fortlaufend Unterstützung zu bieten. Die kontinuierliche Präsenz der SCSs vor Ort wird im vertraglichen Abkommen mit dem Kunden ausgehandelt und festgelegt, falls der Kunde dies in Erwägung zieht.

Außerdem empfiehlt Lokad nachdrücklich, ein aktives, fortlaufendes Engagement zur Verbesserung der Lösung – insbesondere auf Kundenseite – aufrechtzuerhalten. Das Einstellen kontinuierlicher Verbesserungsbemühungen führt unserer Erfahrung nach zu einer Schwächung der Initiative. Jegliche Änderungen auf Kundenseite, einschließlich geringfügiger Anpassungen in der Anwendungslandschaft oder bei den Rahmenbedingungen, können die Qualität der von Lokad generierten Entscheidungen beeinflussen; daher wird aktive Wachsamkeit und kontinuierliche Verbesserung empfohlen.

Siehe auch Project Implementation & Management 1.7.

9. Incident- & Fehlermanagement

9.1 Können Sie sicherstellen, dass alle unverzichtbaren Fehler und Änderungsanfragen (kritische und hochprioritäre Punkte) vorrangig bearbeitet und geliefert werden, um Verzögerungen im Go-live-Zeitplan des Kundenunternehmens zu vermeiden?

Ja. Lokad’s Supply Chain Scientists (SCSs) sind für diesen Prozess verantwortlich. Unsere Plattform ist so konzipiert, dass sie es ihnen ermöglicht, Fehler und Änderungsanfragen zügig und autonom zu bearbeiten.

Lokad’s Plattform ist programmierbar, was durch Envision ermöglicht wird – unsere DSL (domänenspezifische Programmiersprache), die der prädiktiven Optimierung von supply chains gewidmet ist. Diese Programmierbarkeit bedeutet, dass SCSs schnell Fehlerbehebungen liefern und angeforderte Änderungen an der Initiative umsetzen können – und das mit einer Präzision, die in Unternehmenssoftware selten zu finden ist.

Abgesehen von der Technologie sind Lokad’s SCSs darauf geschult, eine Reihe von Schlüsselrollen zu übernehmen, was naturgemäß die Anzahl der zur Behebung von Fehlern und Änderungsanfragen benötigten Personen reduziert. Zu diesen Rollen gehören supply chain expert, Business Analyst, Data Scientist, Data Engineer und Systemintegrator. Sie sind somit gut darauf vorbereitet, Fehlerbehebungen und Updates bereitzustellen, während sie gleichzeitig die Hauptprioritäten des Kunden im Blick behalten.

Siehe auch Customization & System Functionality 6.2.

9.2 Können Sie einen Mechanismus zur Überwachung von Fehlern implementieren, um einen rechtzeitigen Abschluss aller Fehler und Usability-Probleme zu gewährleisten?

Ja, die Lokad Plattform verfügt über ein eigenes Aufgaben-/Ticket-/Issue-Management-System. Diese Funktionen ermöglichen es uns, die fristgerechte Lösung der Probleme genau zu verfolgen. Diese Lösungen werden von den bei Lokad beschäftigten Teams der Supply Chain Scientists (SCSs) übernommen.

Es ist jedoch wichtig, „Fehler“ und „Usability-Probleme“ nicht zusammenzufassen. Zum Beispiel ist eine ungenaue Nachfrageprognose ein „Fehler“. Sie wirkt sich negativ auf die supply chain aus. Abhängig von den Marktbedingungen, unter denen das Kundenunternehmen operiert, könnte dieser „Fehler“ allerdings niemals vollständig behoben, sondern nur abgeschwächt werden. Bei der prädiktiven Optimierung von supply chains stellt eine Lösung stets einen Kompromiss dar, bei dem die Behebung eines Fehlers häufig einen anderen Fehler erzeugt (hoffentlich einen kleineren).

Im Gegensatz dazu sind Usability-Probleme in der Regel unkompliziert zu beheben. Daher sind wir bereit und verpflichtet, für diese Problematik eine zeitnahe Lösung sicherzustellen, da ihre Behebung normalerweise keine weiteren Probleme nach sich zieht.

9.3 Können Sie sicherstellen, dass während des Testens von Releases (vor der Produktion) festgestellte Fehler zeitnah bearbeitet und behoben werden, sodass sie den Go-live-Zeitplan des Kundenunternehmens nicht beeinträchtigen?

Ja. Wenn die identifizierten Fehler den kundenspezifischen Codebestand (geschrieben in Envision) betreffen, werden sie von Lokad’s Supply Chain Scientists (SCSs) behoben. Wenn die identifizierten Fehler die Lokad Plattform betreffen, werden sie von den Software-Engineering-Teams von Lokad behoben.

In beiden Fällen sieht Lokad’s Release-Prozess umfangreiche Tests vor, um sicherzustellen, dass Fehler vor dem Release (Go-live) identifiziert und behoben werden.

9.4 Wie werden Sie Vorfälle bearbeiten, die vom Kundenunternehmen über einen der folgenden Kanäle gemeldet werden: Telefon, E-Mail, Office Communicator und/oder direkte Eingabe in das Incident Management Tool?

Supply Chain Scientists (SCSs) behandeln alle Vorfallmeldungen – unabhängig davon, wie sie eingehen – mit höchster Ernsthaftigkeit. Der vertragliche Rahmen zwischen Lokad und dem Kundenunternehmen legt fest, wie viele SCSs dem Projekt zugewiesen werden und wie viele Stunden pro Woche direkter Support für den Kunden zur Verfügung stehen.

Die Lösung eines typischen Vorfalls beginnt damit, dass ein SCS einen neuen Eintrag im Aufgaben-/Ticket-/Issue-Manager erstellt. Dies gewährleistet eine Rückverfolgbarkeit des Vorfalls.

Anschließend diagnostiziert der SCS das Problem. Falls das Problem eine Behebung auf Lokad’s Seite erfordert, wird der SCS sofort die notwendigen Ressourcen mobilisieren, um das Problem zu lösen – in der Regel der SCS selbst.

Abschließend, nachdem das Problem behoben wurde, ermittelt der SCS die tatsächliche Grundursache des gemeldeten Problems, selbst wenn der Bericht letztlich als unbedeutend diagnostiziert wurde. In der Regel gibt es irgendwo ein zugrunde liegendes Problem, das angegangen werden muss. Indem Lokad die tiefere Ursache behebt, werden ähnliche Probleme in Zukunft proaktiv vermieden.

9.5 Wenn ein Fehler außerhalb des Incident Management Tools – über einen anderen Kanal wie E-Mail – gemeldet wird, registrieren Sie den Fehler dann sofort im Tool, um eine ordnungsgemäße Nachverfolgung und Einhaltung zu gewährleisten?

Ja. Es ist gängige Praxis, einen entsprechenden Eintrag innerhalb der Lokad Plattform zu erstellen, sobald wir über einen anderen Kanal als das Aufgaben-/Ticket-/Issue-Management einen Bericht erhalten. Diese Vorgehensweise erleichtert eine umfassende Nachverfolgung und Einhaltung.