FAQ: Veränderung Management

Zielgruppe: Die supply chain- und/oder Planungsabteilungen.

Zuletzt geändert: 19. Dezember 2023

Überblick über das Veränderungsmanagement

die Quantitative Supply Chain (QSC), wie sie von Lokad initiiert und propagiert wurde, weicht erheblich von der traditionellen Perspektive ab. Die Unterschiede sind sowohl wesentlich als auch die Hauptgründe, warum Lokad solche drastischen supply chain Verbesserungen erzielen kann. Das Change Management, das mit der Implementierung einer Initiative der Quantitative Supply Chain einhergeht, ist jedoch einfacher, als unsere Kunden üblicherweise denken.

Beispielsweise eliminiert Lokad viele unnötige Schnittstellen und Prozesse, anstatt lediglich Verschwendung durch andere Verschwendung zu ersetzen. Somit ist der zu managende Wandel in der Regel zweigeteilt: erstens, die Anpassung an die Tatsache, dass alltägliche, sich wiederholende supply chain Entscheidungen nun automatisiert getroffen werden; zweitens, die Akzeptanz, dass die Qualität dieser automatisierten Entscheidungen die der Mitarbeiter übertrifft, die früher mit alternativen Werkzeugen (Altsystemen, Tabellenkalkulationen und häufig einer Mischung aus beidem) erzielt wurden.

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

Der erfolgreiche Einsatz von Lokad (in der Produktion) liefert typischerweise zwei bemerkenswerte Ergebnisse: erhebliche Einsparungen durch bessere supply chain Entscheidungen und erhebliche Produktivitätseinsparungen durch weitgehend automatisierte supply chain Entscheidungen.

Hinsichtlich des Change Managements stellen supply chain Einsparungen in der Regel kein Problem dar. Das Unternehmen könnte letztlich entscheiden, das freigewordene Betriebskapital anderweitig zu investieren, jedoch übersteigt eine solche Entscheidung normalerweise den Rahmen der Lokad-Initiative. Die erheblichen Produktivitätseinsparungen, die durch Lokad erzielt werden, werden hingegen typischerweise in andere Aufgaben reinvestiert, die für das Kundenunternehmen einen viel höheren Mehrwert bieten als der Altprozess.

Kurz gesagt, vor Lokad sind die Aktivitäten der supply chain Praktiker im Kundenunternehmen nahezu ausschließlich nach innen gerichtet: eine Prognose erstellen, die Prognose in einen Plan umwandeln, Mindest-/Maximallagerbestände für SKUs anpassen, Bestellungen/Produktionsaufträge/Lagerbewegungen zusammenstellen usw.

Sobald Lokad in der Produktion eingesetzt wird, richten sich die meisten Aktivitäten nach außen: ermitteln, was Kunden als Servicequalität wahrnehmen, herausfinden, was Lieferanten als Hindernis für weitere Preissenkungen ansehen, identifizieren, welche Ursachen die Unzuverlässigkeit von Transportunternehmen begründen, usw.

Diese Erkenntnisse werden dann kontinuierlich in Lokads Lösung integriert durch die fortlaufende Unterstützung der SCSs.

Für supply chain Führungskräfte besteht die größte Veränderung in der (weitgehend) Beseitigung des ständigen Feuerlöschens. Lokads Lösung liefert automatisierte Entscheidungen, die darauf ausgelegt sind, lästige Ausnahmefälle zu behandeln, und reduziert somit erheblich den Aufwand, den Führungskräfte für das Verarbeiten unvorhersehbaren Marktverhaltens aufwenden müssen. Dadurch haben supply chain Führungskräfte die Freiheit, supply chain Ziele und Projekte strategisch zu planen, anstatt die fortlaufenden Konsequenzen suboptimaler Entscheidungen im Detail zu überwachen.

Häufig gestellte Fragen (FAQ)

1. Projektimplementierung & Management

1.1 Bieten Sie Implementierungs-Projektmanagement-Dienstleistungen an?

Ja. Diese Dienstleistungen werden von Lokad’s Supply Chain Scientists (SCSs) erbracht. Diese Experten managen nicht nur die Implementierung, sondern führen auch die Initiative im Kundenunternehmen an. Dies umfasst viele Aufgaben, wie etwa die quantitative Absicherung des supply chain Managements, um die Validität von Lokads numerischen Rezepten vor ihrer Implementierung zu demonstrieren. SCSs stellen zudem Schulungsmaterialien zur Verfügung, um die Einführung von Lokads empfohlenen Praktiken und Prozessen im Kundenunternehmen zu unterstützen.

Darüber hinaus engagieren sich diese Experten langfristig für den Erfolg der Initiative über die anfängliche Implementierung hinaus und bieten fortlaufende Unterstützung, während die Initiative in die Phase der ‘kontinuierlichen Verbesserung’ übergeht.

Siehe Lokads Vorträge über den Supply Chain Scientist und “Ein Tag im Leben eines Supply Chain Scientist” für weitere Informationen über die Rolle der SCS im Optimierungsprozess.

1.2 Wie sieht Ihr Implementierungszeitplan aus und welche Schritte bzw. Phasen sind darin enthalten?

Von Anfang bis Ende dauert die Implementierung in der Regel etwa 6 Monate. Lokad unterscheidet dabei 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) automatisiert getroffen werden.

Aufschlüsselung des Zeitplans

Die Onboarding-Phase dauert in der Regel 6 Monate und kann in drei Unterphasen von je 2 Monaten unterteilt werden:

• Monate 1-2: Data Pipeline Setup - Die erste Unterphase ist der Aufbau der Data Pipeline. Das Ziel ist es, eine vollständig automatisierte Pipeline zur Extraktion der Kundendaten zu Lokad zu erstellen. Die beiden anspruchsvollsten Aspekte der Data Pipeline sind die Festlegung der ‘Semantik’ der Daten und die nahezu perfekte Zuverlässigkeit des Pipeline-Prozesses.

• Monate 3-4: Numerical Recipe Design - Die zweite Unterphase ist die Gestaltung des einzigartigen numerischen Rezepts bzw. der numerischen Rezepte des Kunden – also die Softwarelogik, die die supply chain Entscheidungen antreibt. Ziel ist es, Rezepte zu entwickeln, die konsistent, zuverlässig und unkompliziert sind. Das Entwerfen der initialen numerischen Rezepte erfolgt zügig und dauert in der Regel nicht länger als ein bis zwei Wochen.

• Monate 5-6: Dual Run - Die dritte Unterphase ist der Dual Run. Das numerische Rezept produziert keine unsinnigen Ergebnisse mehr, und die wirtschaftlichen Treiber, die die Optimierung steuern, wurden vereinbart. Das Rezept wird parallel zum Altprozess ausgeführt. Durch mehrere Wochen des Dual Run wird das Vertrauen gewonnen, um mit dem Produktions-Rollout fortzufahren.

Am Ende der Onboarding-Phase – und sofern alle Schritte erfüllt wurden – beginnt der Produktions-Rollout. Dieser Rollout besteht darin, die Automatisierung den Altprozess übernehmen zu lassen.

1.3 Dokumentiert und veröffentlicht Lokad einen Projektmanagement-Plan?

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

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

Lokad vertritt die Auffassung, dass viele (wenn nicht sogar die meisten) Unternehmensinitiativen durch die Erstellung wenig hilfreicher Dokumente behindert werden, die in der Praxis unmöglich zu lesen sind (d.h. sie sind langweilig oder undurchdringlich technisch). Solche Dokumente erfüllen keinen Zweck, außer theoretisch Häkchen zu setzen. Darüber hinaus neigen viele Dritte (z.B. Integratoren, Berater und sogar die hausinterne Bürokratie) dazu, bei der Projektdokumentation Menge über Qualität zu stellen.

Im Gegensatz dazu sollen Lokads JPMs sowohl lesbar als auch tatsächlich gelesen werden. JPMs sind Werkzeuge, die von den SCSs selbst zur Verwaltung der Initiative verwendet werden. Obwohl wir umfangreiche Richtlinien dazu haben, was in einem JPM zu erwarten ist, liegt es letztlich an den SCSs, fundierte Entscheidungen darüber zu treffen, worauf angesichts der Besonderheiten der Initiative am meisten Wert gelegt werden muss.

Siehe den Vortrag “Writing for Supply Chains” für weitere Informationen über Lokads Dokumentationsethos.

1.4 Ist Lokad dafür verantwortlich, den Projektmanagement-Plan zu pflegen und zu aktualisieren, vorbehaltlich der Genehmigung(en) durch das Projektlenkungsausschuss? Sollten Abweichungen vom Plan auftreten, werden Sie diese klar kommunizieren und gleichzeitig Minderungsoptionen aufzeigen?

Ja. Die aufgeführten Verantwortlichkeiten werden von Lokad’s Supply Chain Scientists (SCSs) übernommen. Die Details der Kommunikationsverwaltung mit dem Kundenunternehmen hängen in der Regel von den vertraglichen Bedingungen der Initiative ab und werden darin festgelegt.

Gelegentlich sind auf Kundenseite erheblich mehr Mitarbeiter in das Projekt involviert als auf Lokad-Seite. Um die Produktivität der SCSs, die das Konto betreuen, zu steigern, ernennen viele unserer Kunden einen einzigen Ansprechpartner für die Initiative. Diese Person – oder ein kleines Team – ist dafür zuständig, relevante Informationen an alle auf Kundenseite beteiligten Parteien weiterzuleiten und entsprechendes Feedback einzuholen. Für eine besonders komplexe Initiative richtet Lokad einen dedizierten Lenkungsausschuss ein, der aus Schlüsselmitgliedern sowohl von Lokad als auch vom Kundenunternehmen besteht. Obwohl dieses Treffen als Mechanismus zur formalen Genehmigung dient, findet der Großteil der inhaltlichen Arbeit außerhalb des Ausschusses statt. Die SCSs stehen in täglichem Austausch mit verschiedenen Teams auf Kundenseite. Diese Teams werden kontinuierlich über etwaige Abweichungen vom Plan informiert und stellen sicher, dass die gesamte Initiative auf Kurs bleibt. Diese täglichen Interaktionen sind eine weitaus effektivere Methode, um technische Probleme zu besprechen und zu überwinden, als zu versuchen, große Problemansammlungen während einer Lenkungsausschusssitzung zu untersuchen. Daher fungiert der Lenkungsausschuss als überwachendes Gremium und nicht als Denkfabrik für die Initiative.

Hinweis: Quantitative supply chain Initiativen sind dafür bekannt, häufig „positive Abweichungen“ zu erleben. Dabei handelt es sich um vorteilhafte Überraschungen im Rezept, die sich während der fortlaufenden Wartung der Initiative offenbaren. Im Wesentlichen sind dies Chancen, die zu gut sind, um sie ungenutzt zu lassen. Daher besteht ein wesentlicher Vorteil von Lokads Ansatz in der Kommunikation darin, diese positiven Abweichungen umgehend und effizient an den Kunden weiterzuleiten, wodurch der Einfluss und die Agilität der Initiative erheblich gesteigert werden.

1.5 Werden Sie den Kommunikationsplan dokumentieren, der tägliche Stand-ups, wöchentliche Statusberichte und Überprüfungssitzungen der Arbeitsgruppe sowie monatliche Lenkungsausschussberichte und -überprüfungen umfasst? Werden Sie die Eskalationskriterien darlegen und eine gegenseitige Vereinbarung zwischen dem Kundenunternehmen und Lokad zu diesen Details sicherstellen?

Ja. Lokad’s Supply Chain Scientists (SCSs) sind für diese Aufgaben verantwortlich. Die Details der Kommunikationsverwaltung im Kundenunternehmen hängen in der Regel von den vertraglichen Bedingungen der Initiative ab.

Lokad beteiligt sich gerne an täglichen Stand-ups, wenn es vor Ort im Hauptsitz des Kundenunternehmens ist. 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 enthält die Notizen aller Arbeitssitzungen, einschließlich Berichte des Lenkungsausschusses (sofern zutreffend).

Obwohl Lokad die Eskalationskriterien und -richtlinien klarstellt, ist es wichtig zu betonen, dass von einem Senior SCS bei Lokad erwartet wird, alle Fragen oder Bedenken bezüglich der Initiative zu klären. In Bezug auf Eskalationen wird ein problematischer Vorfall in der Regel von einem Junior SCS an einen Senior SCS weitergeleitet. Dies hat sich in der Vergangenheit als ausreichend erwiesen, wobei nur sehr wenige Situationen eine weitere Eskalation erforderten.

Lokad betrachtet alle Probleme – so unwesentlich sie auch erscheinen mögen – als einer eingehenden Analyse würdig. Obwohl ihre Auswirkungen leicht zu beheben sind, können kleinere Probleme zukünftig zu Schwierigkeiten führen, wenn die Ursachen nicht verstanden und behoben werden. Dies verhindert, dass ein kleines Problem zu einem wiederkehrenden wird. Daher zieht es Lokad vor, hochqualifizierte Personen an vorderster Front einzusetzen, die in der Lage sind, sowohl das unmittelbare Problem anzugehen als auch die zugrunde liegenden Ursachen zu identifizieren. Dieser Ansatz ist vorzuziehen gegenüber der Abhängigkeit von ungeschultem Support-Personal, das ständig dieselben Probleme behandelt – ein Muster, das von vielen Unternehmenssoftwareanbietern allzu häufig angenommen wird.

Daher ist der prägnante Eskalationsprozess von Lokad beabsichtigt und stellt schnelle sowie nachhaltige Lösungen sicher.

1.6 Werden Sie sicherstellen, dass der Projektmanagement-Plan von allen Stakeholdern im Rahmen der Projektinitiierungsphase abgezeichnet wird?

Ja. Allgemein folgen Lokad’s Supply Chain Scientists (SCSs) dem Prozess, der mit jedem Kunden verhandelt und vereinbart wurde – gemäß den formellen vertraglichen Bedingungen. Dieses Prinzip bleibt während der gesamten Initiative von Anfang bis Ende bestehen. Die Projektinitiierung ist sicherlich wichtig, aber da Lokad von Anfang an keine langfristige Verpflichtung verlangt, ist diese Angelegenheit weniger von Bedeutung – insbesondere im Vergleich zu unseren Mitbewerbern.

Es sei darauf hingewiesen, dass wir noch nie beobachtet haben, dass eine supply chain aufgrund eines Mangels an Bürokratie und anderen unnützen Prozessen schlecht abschneidet. Im Gegenteil, unnötige Bürokratien und unsinnige Prozesse sind die häufigsten Probleme in modernen supply chains – selbst in Unternehmen, die ansonsten leistungsstarke supply chains zu haben scheinen.

1.7 Werden Sie einen dedizierten Projektmanager von Lokad bereitstellen, der im Hauptsitz des Kundenunternehmens stationiert ist, begleitet von Produktexperten, Business Analysts und technischen Schnittstellenexperten?

Ja, sofern solche Bestimmungen Teil der vereinbarten vertraglichen Bedingungen für die Initiative sind. Obwohl Lokad nichts dagegen hat, Mitarbeiter im Hauptsitz des Kundenunternehmens vor Ort einzusetzen, erhöht dies naturgemäß die Kosten der Initiative. Die meisten unserer Initiativen werden remote durchgeführt und durch monatliche oder vierteljährliche Besuche unterstützt, abhängig vom Umfang der Initiative. Es sei angemerkt, dass, selbst wenn Lokad zustimmt, ein festes Team im Hauptsitz des Kunden bereitzustellen, die Mitarbeiter im Laufe der Zeit rotieren werden.

Solche Praktiken kommen allen Beteiligten zugute, da Lokads Supply Chain Scientists (SCSs) einem kontinuierlichen Trainingsprogramm unterliegen. Dieses Programm ist entscheidend, um sicherzustellen, dass unsere Mitarbeiter, unabhängig von Erfahrung oder Dienstalter, weiterhin neue Fähigkeiten erwerben oder bestehende verfeinern. Während wir beobachten, dass viele Anbieter von Unternehmenssoftware ihren Mitarbeitern erlauben, monatelang – wenn nicht jahrelang – an entfernten Kundenstandorten zu arbeiten, ist Lokad davon überzeugt, dass diese Praxis nicht mit der zuverlässigen und effizienten Bereitstellung hochwertiger Trainingsprogramme vereinbar ist.

Insbesondere zählt zu den größten Stärken von Lokads Supply Chain Scientists (SCSs) ihre außergewöhnlich vielfältigen und breiten Fähigkeiten. Jeder SCS wird darauf geschult, in verschiedenen Rollen zu agieren, wie zum Beispiel: Fachexperte, Geschäftsanalyst, technischer Schnittstellenspezialist, Data Scientist und supply chain consultant. Diese Funktionen würden normalerweise von mehreren Mitarbeitern erfüllt werden und zu einer signifikanten Kostensteigerung für den Kunden führen. Bei Lokad erbringt jeder SCS all diese Dienstleistungen.

Infolgedessen sind SCSs in der Regel weitaus produktiver (weniger Personen bedeuten tendenziell weniger Kommunikationsprobleme) und erzielen höhere Leistungsniveaus. In der Realität hängen supply chains entscheidend von einer End-to-End-Konsistenz ab, was mit einer geringen Mitarbeiterzahl viel einfacher zu erreichen ist.

1.8 Während der Implementierungsphase, welche Organisation schlagen Sie vor? Wo sollten Ressourcen zugewiesen werden?

Für eine typische Initiative bei Lokad empfehlen wir, dass das Kundenunternehmen einen erfahrenen supply chain practitioner als Koordinator der Initiative ernennt und außerdem einen supply chain executive als Aufseher der Initiative bestimmt. Der Koordinator fungiert 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 übermitteln. Parallel dazu arbeiten Lokads SCSs mit den numerischen Rezepten, die darauf abzielen, die interessierenden supply chain Entscheidungen zu generieren.

Wir empfehlen wöchentliche Meetings, um den Fortschritt der Initiative zu überprüfen, bis die Onboarding-Phase abgeschlossen ist. An diesem Meeting nehmen systematisch der Koordinator, der Aufseher und der primäre Supply Chain Scientist (SCS) des Kontos von Lokad teil. Andere Teilnehmer können bei Bedarf hinzukommen, jedoch ist ihre durchgehende Anwesenheit in der Regel während der Implementierungs-/Onboarding-Phase nicht erforderlich.

Einige IT-Ressourcen müssen zu Beginn der Initiative für den Aufbau der Datenpipeline bereitgestellt werden. In dieser Hinsicht ist Lokad effizienter als die meisten seiner Mitbewerber. Zum Beispiel extrahieren wir automatisch und direkt die Transaktionsdaten des Kunden, ohne dass eine Bereinigung oder Vorbereitung auf Kundenseite erforderlich ist. Sofern das Kundenunternehmen nicht in eine vendor lock-in Situation gerät, erfordert dieser technische Aufbau weniger als 4 Wochen Arbeit eines einzelnen Mitwirkenden – und manchmal deutlich weniger, wenn bereits ein Data Lake vorhanden ist.

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

Die Mitwirkung des Aufsehers ist sowohl wichtig, um Lokad mit der vom Unternehmen verfolgten übergeordneten Strategie in Einklang zu bringen, 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 zu modellieren, die mit der mangelnden Servicequalität verbunden sind. Wir können die Vor- und Nachteile dieser Optionen in nicht-technischen Begriffen erläutern, aber letztlich müssen einige strategische Entscheidungen getroffen werden.

Natürlich 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 stellt Lokad mehrere Vorträge zur erfolgreichen supply chain Optimierung bereit.

2. Ressourcenmanagement & Anforderungen

2.1 Was sind die Personalbedarfe für die Projektimplementierung im Kundenunternehmen?

Eine typische Lokad-Initiative erfordert etwa 0,5 bis 2 FTE (Full-Time Equivalent) an Mitarbeiterressourcen vom Kundenunternehmen während der ersten 6 Monate – also der Onboarding-Phase. Sobald die Initiative in die Produktionsphase übergeht, geht man vernünftigerweise davon aus, dass das Projekt weiterhin mindestens 0,25 FTE benötigt.

Bezüglich der in jeder Phase einer “typischen” Initiative benötigten Ressourcen, haben wir in der Onboarding-Phase:

• Monate 1 und 2: Der Aufbau der Datenpipeline erfordert 4 Wochen Vollzeiteinsatz eines Data Officer, der typischerweise von der IT des Kundenunternehmens beschäftigt wird. Der Data Officer sollte mit der applikativen Landschaft des Kundenunternehmens gut vertraut sein.

• Monate 3 und 4: Die Gestaltung des numerischen Rezepts erfordert 2 bis 3 Tage pro Woche vom Koordinator (auf Kundenseite) der Initiative, mindestens 10 Stunden pro Woche von verschiedenen supply chain practitioners zur Bereitstellung von High-Level-Einblicken und später zur Rückmeldung zu den von Lokad erstellten Zahlen.

• Monate 5 und 6: Die Anforderungen sind im Wesentlichen dieselben wie in der vorangegangenen Phase, jedoch ändert sich der Schwerpunkt. Der Koordinator verbringt nun die meiste Zeit mit der Vorbereitung des richtigen Roll-outs und der Kommunikation mit allen betroffenen supply chain practitioners.

Siehe auch Project Implementation & Management 1.2.

2.2 Sorgen Sie dafür, dass ausreichend Personal für die Unterstützung der Produktübergabe geplant wird?

Ja. Als Faustregel empfiehlt Lokad, während des Übergangs von der Onboarding-Phase in die Produktionsphase die gleiche Menge an Ressourcen (z. B. die gleichen Supply Chain Scientists) beizubehalten. Der potenzielle Return on Investment einer gut gepflegten und kontinuierlich verbesserten Lösung ist erheblich.

Es sei darauf hingewiesen, dass, da Lokad supply chain Entscheidungen automatisiert, keine strikte Dringlichkeit besteht, alle supply chain practitioners des Kunden mit einem neuen Prozess umzutrainieren, um den Betrieb in Gang zu halten – die Automatisierung selbst ist darauf ausgelegt, dies zu gewährleisten.

Dieser schlanke Ansatz steht in starkem Gegensatz zu den großen – und kostspieligen – “Task Forces”, die häufig von Anbietern von Unternehmenssoftware benötigt werden, um live zu gehen.

2.3 Können Sie garantieren, dass vor Ort im Hauptsitz des Kundenunternehmens ausreichend Personal und Knowledge Product (KP)-Ressourcen zur Unterstützung der Produktübergabe zur Verfügung stehen?

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

Siehe auch Project Implementation & Management 1.7.

Siehe auch Resource Management & Requirements 2.2.

2.4 Führen Sie Anforderungsüberprüfungen mit den Business Product Owners durch, um Anforderungen zu ermitteln und zu dokumentieren?

Ja. Eines der ersten Ziele des Supply Chain Scientist ist es, 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. Wir bemühen uns auch, vorhandene Dokumente (sofern verfügbar) sorgfältig zu prüfen, um das Beste aus diesen Interviews herauszuholen.

Allerdings liegt Lokads Hauptaugenmerk darauf, das untersuchte “Problem” zu verstehen, was nicht immer durch das Auflisten von “Anforderungen” erreicht wird. Wenn ein Kunde beispielsweise erwähnt, dass eine besondere Behandlung von “slow movers” erforderlich ist, verstehen wir, dass ein geringes Volumen ein zu adressierendes Problem darstellt. Die Sonderbehandlung dieser SKUs ist jedoch 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 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 die Problemlösung oft erleichtert.

Daher erfasst und dokumentiert Lokad zwar alle Kundenanforderungen, jedoch liegt unser Ansatz darin, die wahre Natur des Problems zu entdecken, statt den aktuellen Zustand der supply chain des Kunden hinnehmbar zu akzeptieren.

Siehe “Fall in Love with the Problem, Not the Solution” für weitere Informationen zur Problem-Lösungs-Dichotomie.

2.5 Geben Sie Schätzungen für Aufwand, Kosten und Zeitpläne für Funktionen ab, die Anpassungen 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 ersten kommerziellen Angebot enthalten. Falls ein Workshop zur Vorbereitung der Initiative organisiert wird, nutzen wir die Informationen aus dem Workshop, um unser Angebot weiter zu verfeinern.

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

Im Gegensatz zu den meisten Unternehmenssoftwaresystemen ist die Programmierbarkeit ein Kernelement von Lokad. Die oben erwähnten Envision-Skripte stellen keine “Anpassung” der Lokad-Lösung im herkömmlichen Sinne dar. Auch bedeutet das Vorhandensein dieser Skripte keinen Abzug von der Hauptentwicklungslinie der Lokad-Lösung. Vielmehr ist die umfangreiche Programmierbarkeit von Lokad der angestrebte Implementierungspfad.

Infolgedessen ist mit unseren Schätzungen (Kosten, Zeitplan usw.) eine außerordentlich hohe Sicherheit verbunden. Die überwiegende Mehrheit der Projekte bleibt innerhalb der Schätzungen/ursprünglichen Budgets (in jeglicher Hinsicht). Dies steht im Gegensatz zu mehreren Mitbewerbern von Lokad, bei denen kostspielige Verzögerungen und Neuformulierungen der Bedingungen üblich sind.

Siehe Fallstudie über Lidls 500-Millionen-Euro-SAP-Debakel für weitere Informationen zu diesem Punkt.

2.6 Werden Sie eine angemessene Bindungsstrategie implementieren und aufrechterhalten, die darauf ausgelegt ist, Schlüsselpersonal, das die Dienstleistungen während der Vertragslaufzeit erbringt, zu halten? Werden Sie auch aktive Nachfolgepläne für jede der Schlüsselpositionen bei Lokad aufrechterhalten?

Ja. Wir binden Mitarbeiter durchschnittlich 3,5 Jahre, was fast doppelt so lang ist wie die durchschnittliche Betriebszugehörigkeit vergleichbarer Gruppen (talentierte Ingenieure im IT-Bereich oder in IT-nahen Bereichen) in ähnlichen Märkten (Nordamerika und Westeuropa). Dieses Segment des Arbeitsmarktes ist äußerst wettbewerbsintensiv und, obwohl immer Verbesserungspotenzial besteht, positioniert sich Lokad damit weit über den meisten unserer Mitbewerber. Infolgedessen profitieren die meisten Initiativen von Lokad davon, dass Jahr für Jahr dieselben Supply Chain Scientists (SCSs) im Einsatz sind.

Diese Mitarbeiterbindung ist auf wettbewerbsfähige Gehälter und Lokads kontinuierliche Investitionen in die Schulung seiner Teams zurückzuführen. Insbesondere die supply chain Inhalte, die von Lokad auf der eigenen Website veröffentlicht werden – insbesondere unsere Vortragsreihe zu supply chain – können als Nebenprodukt von Lokads Fokus auf die Schulung der eigenen Mitarbeiter gesehen werden. Im Allgemeinen verfügen Anbieter von Unternehmenssoftware, die keine öffentlichen Schulungsmaterialien haben, fast nie über eigene private Schulungsmaterialien (auch wenn sie stets das Gegenteil behaupten).

Was Nachfolgepläne betrifft, verfolgen wir zwei wichtige Praktiken. Erstens wird jede Lokad-Initiative mit einem Joint Procedure Manual (JPM) versehen. Das JPM ist das Hauptdokument, das ein neuer SCS verwendet, um sich schnell mit allen relevanten Erkenntnissen und technischen Details der Initiative vertraut zu machen. Zweitens hat jede Initiative – zu jeder Zeit – sowohl einen primären als auch einen sekundären SCS. Selbst wenn der sekundäre SCS nicht direkt zur Initiative beiträgt, stellt Lokad ausreichend Zeit zur Verfügung, um sicherzustellen, dass diese Person bereit ist, die Initiative zu übernehmen, falls dies erforderlich sein sollte. Diese Praxis mildert weitgehend Komplikationen im Zusammenhang mit ungeplanten Abwesenheiten oder Fluktuation.

3. Rollen, Verantwortlichkeiten & Stakeholder-Management

3.1 Welches Kooperationsniveau haben Sie mit dem Kundenunternehmen?

Das Kooperationsniveau, das wir mit unseren Kunden pflegen, variiert, ist aber insgesamt wesentlich höher als das, was von einem Anbieter von Unternehmenssoftware üblicherweise erwartet wird. supply chain Belange sind nicht für alle Unternehmen gleichermaßen wichtig, weshalb die Zusammenarbeit tendenziell bei Unternehmen stärker ausgeprägt ist, in denen die supply chain das (anerkannte) Rückgrat ihrer Aktivitäten darstellt.

Der Begriff „Partner“ wurde so weit verwässert, dass selbst Anbieter trivialer Softwareprodukte (wie Zeiterfassungstools) letztlich 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. Bei Lokad gibt es vertraute Gesichter, die sich ihr Vertrauen verdient haben und infolgedessen – typischerweise Supply Chain Scientists (SCSs) – bestens mit ihrem Geschäft vertraut sind. Außerdem werden unsere Ergebnisse häufig als so bemerkenswert erachtet, dass sie persönlich dem CEO und/oder dem Vorstand des Unternehmens präsentiert werden, selbst bei großen Unternehmen.

Die laufende Zusammenarbeit mit Lokad ermöglicht es unseren Kunden, ihre gesamte supply chain Praxis positiv neu zu gestalten. Letztendlich wird die gesamte Kette überarbeitet, was sich sowohl bei Kunden als auch Lieferanten positiv auswirkt. Es sei darauf hingewiesen, dass Lokad nicht beabsichtigt, die kritische strategische Expertise, die im Kundenunternehmen vorhanden ist, zu ersetzen. Stattdessen möchte Lokad den alltäglichsten und sich wiederholendsten Aspekt der Entscheidungsprozesse der supply chain automatisieren. Dieser Ansatz befreit anschließend erhebliche – und oft knappe – Kundenressourcen, 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 Lokads Initiativen im Bereich der Quantitative Supply Chain beteiligt sind.

• The Supply Chain Leader: Diese Rolle betont die Bedeutung der Einbindung des Top-Managements in die Initiative der Quantitative Supply Chain. 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 sicherzustellen, fungiert diese Person als Brücke zwischen verschiedenen internen Teams. Ihre Hauptaufgabe besteht darin, Feedback zu sammeln, mit Stakeholdern zu kommunizieren und Prozesse sowie Entscheidungen zu bestätigen beziehungsweise zu klären. Sie stellt sicher, dass die Initiative mit den bestehenden Unternehmensabläufen übereinstimmt, und bleibt gleichzeitig offen gegenüber möglichen zukünftigen Anpassungen der Arbeitsabläufe.

• The Data Officer: Daten bilden das Rückgrat der Initiative der Quantitative Supply Chain, und diese Person gewährleistet deren Zugänglichkeit und Zuverlässigkeit. Beauftragt mit der Extraktion umfassender Datensätze (wie Verkaufs- und Einkaufsverläufe), 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 vereint die Erkenntnisse des Supply Chain Coordinators mit den Daten des Data Officer, um Entscheidungsprozesse zu automatisieren. Beginnend mit der Datenaufbereitung arbeitet der Supply Chain Scientist eng mit dem Coordinator zusammen, um eventuelle Unklarheiten in den Daten zu klären. Anschließend formalisiert er Strategien in umsetzbare Entscheidungen, wie zum Beispiel Nachbestellmengen, und implementiert Dashboards und KPIs für Transparenz und Kontrolle.

Siehe project roles für weitere Informationen zu den verschiedenen Bezeichnungen innerhalb einer Initiative der Quantitative Supply Chain.

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

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

Noch wichtiger ist, dass die Supply Chain Scientists (SCSs) derartige Matrizen verinnerlichen, um geeignete und schnelle Entscheidungen zu treffen, während die Initiative fortschreitet. Was Optimierungsfragen der supply chain betrifft, so besteht der Kern darin, den besten Weg zu finden, das Problem zu rahmen. Danach verlagert sich der Fokus darauf, zu identifizieren, wer im Unternehmen am besten positioniert ist, um das Problem anzugehen. Entscheidend ist, dass all diese Analysen schnell durchgeführt werden, um den Schwung der Initiative aufrechtzuerhalten.

Zu diesem Zweck werden Lokads SCSs dazu bestimmt, die Initiative anzuführen und die Verantwortung für die Qualität des von Lokad generierten Outputs der numerischen Rezepte zu übernehmen.

Demnach ist es ein kleiner Kern hochqualifizierter Spezialisten, die für die supply chain Entscheidungen, die Lokad generiert, verantwortlich sind – und nicht ein aufwändiges „System“ oder „Prozess“, bei dem Verantwortungsteile an eine große Gruppe von Stakeholdern delegiert werden. Lokad ist der Ansicht, dass solche Systeme dazu neigen, Verantwortung zu verwässern, anstatt sie zu verfestigen. Unsere SCSs werden daher darauf trainiert, diese Verantwortung zu übernehmen und damit sicherzustellen, dass die relevanten Stakeholder im Kundenunternehmen konsultiert und vollständig über die Initiative informiert werden.

3.4 Werden Sie Rollen und Verantwortlichkeiten mithilfe einer RACI (Responsibility, Accountability, Consulted, and Informed)-Matrix für alle Projektbeteiligten dokumentieren? Werden Sie sicherstellen, dass dieses Dokument von allen beteiligten Parteien besprochen und vereinbart wird?

Ja. All diese Elemente (und mehr) werden im Joint Procedure Manual (JPM) zusammengetragen und dokumentiert. Das JPM wird von Lokads Supply Chain Scientists (SCSs) erstellt (mit direkt aus dem Kundenunternehmen gesammelten Erkenntnissen). In diesem Dokument sind die Parameter der jeweiligen Rolle und Verantwortung jeder Person detailliert aufgeführt.

Das JPM dient auch als fortlaufende Ressource für die Initiative und wird von den SCSs, die dem Kundenunternehmen zugeteilt sind, verfasst. Die Erstellung dieses Dokuments in ihren eigenen Worten zeigt, dass die SCSs beträchtliche Zeit darauf verwendet haben, die supply chain des Kunden und die übergeordnete Lösung zu untersuchen, zu diagnostizieren und zu analysieren (ohne einfach die bereits bestehende Literatur des Kunden zu wiederholen).

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

In diesem Zusammenhang zeigt unsere Erfahrung, dass Meinungsverschiedenheiten in der Regel ein organisatorisches Problem widerspiegeln, das im Kundenunternehmen gelöst werden muss. Aus diesem Grund empfehlen wir, dass das Kundenunternehmen einen Supply Chain Executive ernennt, der die Initiative überwacht. Eine ihrer wesentlichen Aufgaben besteht darin, in solchen Fällen als Vermittler zu fungieren.

3.5 Werden Sie sicherstellen, dass die Projektarbeitsgruppe und die Steuerungsgruppen mit benannten Ressourcen der Projektstakeholder gebildet werden? Werden Sie dafür sorgen, dass der Betriebsrhythmus von allen beteiligten Parteien vereinbart wird?

Ja. Als allgemeines Prinzip folgen wir jedem Prozess, der vom Kundenunternehmen als notwendig erachtet und formell vereinbart wird. Die vereinbarten Elemente (und alle Änderungen, die im Laufe der Initiative vorgenommen werden) sind im Joint Procedure Manual (JPM) dokumentiert, das Details zur Projektarbeitsgruppe und zu den Steuerungsgruppen enthält. Durch Lokads Supply Chain Scientists (SCSs) verfügen wir über die notwendigen Ressourcen, um diese Prozesse zu implementieren und zu überwachen.

Anekdotisch ist einer von Lokads am häufigsten geschätzten Beiträgen unsere Fähigkeit, Prozesse zu vereinfachen – seien es Prozesse der supply chain oder bürokratische Prozesse. Im Laufe der Zeit arbeiten wir aktiv daran, unnötige bürokratische Ebenen in 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’ geht – 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 sogar noch weiter verkürzen. Umgekehrt verlängert sich diese Phase in der Regel um 1 bis 3 Monate, wenn die Software- oder Systemumgebung des Kunden unverhältnismäß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 dieser im vorgesehenen Zeitrahmen realisierbar ist. Unsere Erfahrung zeigt, dass Onboarding-Phasen, die länger als 6 Monate dauern, die Initiative dem Risiko der Stagnation aussetzen. Daher gestalten wir den Umfang aktiv so, dass dieses Risiko minimiert wird.

Solche Verzögerungen haben wenig mit dem technischen Setup von Lokad selbst zu tun. Insgesamt dient der vorgeschlagene Zeitplan nicht nur technischen Zwecken (wie der Automatisierung der Datenauszüge, dem Testen numerischer Rezepte usw.), sondern ermöglicht auch, dass Lokads Supply Chain Scientists (SCSs) sich vollständig mit den spezifischen Gegebenheiten des Kundenunternehmens vertraut machen und die supply chain Teams Lokads Ansatz „verdauen“ – etwas, das 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 als Teil der spezifischen vertraglichen Bedingungen mit dem Kundenunternehmen verhandelt, wobei darauf hingewiesen werden muss, dass Reisekosten die von Lokad berechneten Gebühren beeinflussen können. Daher ist die Einbeziehung von Vor-Ort-Besuchen letztendlich eine Entscheidung des Kundenunternehmens, und Lokad wird die gewünschte Frequenz berücksichtigen.

Wenn es das Ziel des Kundenunternehmens ist, 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 100M USD) und für Unternehmen, die im Allgemeinen mit Remote-Mitarbeitern zufrieden sind (wie große eCommerce-Unternehmen). Etwa die Hälfte der von Lokad durchgeführten Initiativen fällt in diese Kategorie.

Wenn das Ziel des Kundenunternehmens darin besteht, die Chancen auf ein erfolgreiches Change-Management zu maximieren, sind wir mit monatlichen Besuchen einverstanden – gegebenenfalls auch häufiger, falls notwendig. Für große Unternehmen (Jahresumsatz über 1B 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) als Workshops statt, während wir bei unseren Kunden außerhalb Westeuropas eher mehr Workshops (in der Regel von mehreren Tagen Dauer) als Vor-Ort-Besuche durchführen. Dieser Unterschied hängt einfach mit den damit verbundenen Reisekosten und der Logistik zusammen.

4.3 Was ist ein ideales Gleichgewicht zwischen Remote- und Vor-Ort-Meetings?

Für eine Initiative der Quantitative Supply Chain sollten die meisten Meetings remote stattfinden. Die meisten Meetings sind kurz (30 Minuten oder kürzer) und involvieren nur zwei Teilnehmer: einen Supply Chain Scientist von Lokad und einen supply chain Praktiker aus dem Kundenunternehmen. Darüber hinaus sind Remote-Meetings für bestimmte technische Aufgaben von Vorteil, da alle Teilnehmer Zugang zu ihrer eigenen Computerumgebung haben, einschließlich großer Monitore. Dies ist besonders nützlich, wenn die Teilnehmer komplexe Berichte untersuchen müssen.

Lokad unterschätzt jedoch nicht den Wert von Vor-Ort-Meetings mit Kunden. Vor-Ort-Meetings erleichtern oft die Vermittlung komplexer Ideen, das Diskutieren von Perspektiven und/oder das Anpassen von Erwartungen zwischen den Parteien. Daher empfehlen wir, einen regelmäßigen Rhythmus für Vor-Ort-Meetings einzuführen (z.B. wöchentlich/monatlich/vierteljährlich…). Lokad betrachtet solche Vor-Ort-Treffen 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 eines Qualitätstests der Produktionsumgebung, um die Bereitschaft für den Go-Live zu beurteilen, einschließlich der Einrichtung von Schnittstellen?

Ja. Tatsächlich geht Lokad über die bloße Unterstützung des Kundenunternehmens bei der Beurteilung seiner Go-Live-Bereitschaft hinaus. Eine der Hauptverantwortlichkeiten von Lokads Supply Chain Scientists (SCSs) besteht darin, die Verantwortung für die End-to-End-Lösung zu übernehmen, die dem Kundenunternehmen bereitgestellt wird. Mit anderen Worten: Obwohl ein mechanisiertes System (eine Flotte von Maschinen) die Ergebnisse generiert, übernimmt immer eine Person die persönliche Verantwortung für das System. Sie gewährleisten die Genauigkeit, Relevanz und Angemessenheit der End-to-End-Datenverarbeitungskette – und berücksichtigen dabei auch die übergeordneten geschäftlichen Belange des Kunden.

Angesichts ihrer fehleranfälligen Natur verdienen Software-Schnittstellen besondere Aufmerksamkeit, und der SCS ist gut darauf vorbereitet, bei der Beurteilung ihrer Integrität zu helfen. Lokad bewertet diese Integrität sowohl auf der Eingangsseite (wenn Lokad historische Daten vom Kundenunternehmen erhält) als auch auf der Ausgangsseite (wenn Lokad supply chain Entscheidungen an das Kundenunternehmen zurückgibt). Für diese Aufgabe nutzt Lokad spezifische Methoden und Technologien.

Bitte beachten Sie die programming paradigms for supply chain, um besser zu verstehen, welche Art von Technologien Lokad einsetzt, um die Go-Live-Bereitschaft 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 managen?

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

Außerdem ist Lokads Dual-Run-Ansatz einzigartig dafür geeignet, einen reibungslosen Übergang vom Legacy-Prozess zur neuen Lösung sicherzustellen. „Dual-run“ bezeichnet in diesem Zusammenhang die Praxis, bei der Lokad parallel zum bestehenden Entscheidungsprozess über den gesamten Umfang der Initiative läuft. Diese Praxis wird erst durch die robotisierte Natur des bestehenden Entscheidungsprozesses von Lokad möglich, wodurch sichergestellt wird, dass die numerischen Rezepte, die von den SCSs von Lokad implementiert wurden, über den gesamten Umfang hinweg über Wochen hinweg unter exakten Produktionsbedingungen zufriedenstellend laufen, bevor der tatsächliche Go-Live erfolgt, bei dem Lokads Entscheidungen den Legacy-Prozess ersetzen.

Es muss beachtet werden, dass ein solcher Dual-Run in der Regel mit alternativen Technologien und Methoden, wie sie von unseren Wettbewerbern vorgeschlagen werden, nicht möglich ist. Da sie die supply chain Entscheidungen nicht robotisieren, sind die mit einem Dual-Run verbundenen Overheads erheblich. Infolgedessen wird der Dual-Run bestenfalls über einen kleinen Umfang durchgeführt, der die Produktionsbedingungen nicht wirklich widerspiegelt. Folglich führt die späte Erweiterung des Umfangs immer wieder zu Produktionsvorfällen, die mit einem vollumfänglichen Dual-Run völlig vermeidbar gewesen wären.

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

Ja. Der Umfang ist stets im vertraglichen Abkommen zwischen Lokad und dem Kundenunternehmen detailliert festgelegt. Er nimmt in der Regel die Form einer bestimmten Art von supply chain Entscheidung an (z.B. Bestandsauffüllung oder Lagerzuweisung) über einen Satz von Standorten und/oder über einen Satz von Geschäftssystemen an.

Der Zeitrahmen liegt typischerweise unter 6 Monaten (vom Kick-off bis zur Produktion). Während ein prognostizierter Zeitrahmen stets in unserem kommerziellen Angebot enthalten ist, muss er möglicherweise nicht im Vertragsabkommen festgelegt werden. Der verbindliche Zeitrahmen stellt ein beidseitiges Engagement dar, und das Tempo der Lokad-Initiative hängt von der fristgerechten Durchführung bestimmter Schritte durch das Kundenunternehmen ab, insbesondere dem Aufbau einer Datenpipeline zu Lokad.

Hinsichtlich der Erfolgskriterien wird die Entscheidung immer einseitig vom Kundenunternehmen getroffen. Obwohl wir die Leitprinzipien, die diese Entscheidung unterstützen sollten, dokumentieren können, wäre eine nicht einseitige Entscheidung ungewöhnlich. Einfach ausgedrückt: Ein Anbieter sollte nicht in der Position sein zu entscheiden, dass der Pilotversuch erfolgreich war, wenn der Kunde anderer Meinung ist.

Siehe auch Project Implementation & Management 1.2.

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

4.7 Werden Sie die Durchführung von Pilotläufen organisieren, um a) die Datenangemessenheit, b) die Systemkonfiguration und Anwendungsbereitschaft, c) die Prozess-/Systemkonformität sowie d) die generelle Zweckmäßigkeit sicherzustellen?

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

Das Team von Lokad’s 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 existiert, das erfasst, was gekauft, produziert, eingelagert 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. Veränderungs- & Risikomanagement

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

Alle Kunden genießen das uneingeschränkte Engagement von Lokad’s Supply Chain Scientists (SCSs), die alle darin geschult sind, die technischen und nicht-technischen Anforderungen einer supply chain-Optimierungsinitiative zu erfüllen. Die SCSs unterstützen den Änderungsmanagementprozess in vielerlei Hinsicht, unter anderem durch:

• Verbesserungsvorschläge für bestehende Prozesse der supply chain practitioners im Kundenunternehmen unterbreiten.
• Schulungsmaterialien erstellen, um die Mitglieder/Teams des Kundenunternehmens einzuarbeiten.
• Unterstützung des supply chain managements, indem der Einfluss der vorgenommenen Änderungen an der supply chain in Dollar oder Euro (oder in der vom Kunden gewählten Währung) quantifiziert wird.

Es sei darauf hingewiesen, dass Änderungsmanagement einen erheblichen Zeitaufwand für einen SCS darstellen kann. Obwohl jeder SCS über individuell geeignete Fähigkeiten und Erfahrungen in der Unterstützung der supply chain-Führung im Änderungsmanagement verfügt, konkurriert diese Aufgabe mit all ihren anderen Pflichten.

Daher legen die zwischen Lokad und jedem Kunden ausgehandelten Vertragsbedingungen die Menge an Ressourcen – d.h. die Größe des SCS-Teams – fest, die zur Unterstützung der Initiative zur Verfügung stehen wird. Unsere kommerziellen Angebote gehen in der Regel davon aus, dass SCSs einen gewissen Support im Änderungsmanagement leisten. Allerdings spiegeln unsere Angebote üblicherweise keine Art von „umfassender“ Unterstützung im Änderungsmanagement wider – es sei denn, dies wird explizit vom Kunden angefordert.

5.2 Während der Produktionsphase: Wie stellen Sie sich das Änderungsmanagement vor? Was sind die Hauptmeilensteine? Wie sieht die neue Organisation nach der erfolgreichen Implementierung der neuen Lösung aus?

Sobald Lokad in Produktion ist, wird eine ganze Klasse von supply chain-Entscheidungen automatisiert. Das Ziel besteht darin, die supply chain-Praxis in ein kapitalistisches Vorhaben zu verwandeln. Jede Stunde, die ein supply chain practitioner aufwendet, 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 noch einen weiteren Tag am Laufen zu halten. Natürlich verläuft der Übergang zu dieser wertschöpfenden Form der supply chain allmählich.

• Der erste Meilenstein besteht darin, die supply chain practitioners dazu zu bringen, anzuerkennen, dass Lokad ihnen ermöglicht, den Großteil des veralteten Prozesses außer Acht zu lassen. Zum Beispiel ist es sinnvoll, die täglichen Auffüllmengen 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 ein Anteil von 0% an Unsinn in den von Lokad generierten Zahlen das wichtigste Kriterium für den Produktionsstart. Das Vertrauen, das die supply chain practitioners in Lokads Zahlen setzen können, verschafft naturgemäß viel zusätzliche Zeit, die sinnvoller genutzt werden kann.

• Der zweite Meilenstein besteht darin, einige „Early Adopters“ unter den supply chain practitioners zu gewinnen. Dabei handelt es sich typischerweise um Personen, die es schnell schaffen, sich vom nicht wertschöpfenden Legacy-Prozess – z.B. der manuellen Überprüfung von Zahlen – zu lösen, um sich auf die kontinuierliche Verbesserung der supply chain mittels ihrer numerischen Rezepte zu konzentrieren. Sie können damit beginnen, zahlreiche wichtige Fragen anzugehen, die über rein technische Aspekte hinausgehen (zum Beispiel: Betrachtet das Kundenunternehmen seine Servicequalität aus der richtigen Perspektive?).

• Der dritte Meilenstein besteht darin, dass der Großteil der supply chain practitioners nach außen blickt (Kunden und Lieferanten) statt nach innen. Letztlich muss die supply chain eine Abstimmung bewirken, die über die Grenzen des Kundenunternehmens hinausgeht. Dadurch wird der Pool der gesammelten Erkenntnisse erweitert und die numerischen Rezepte können weiter verfeinert werden.

Die neue Organisation ist einer Softwarefirma weitaus ähnlicher. Es gibt nur wenige repetitive supply chain-Aufgaben, die manuell ausgeführt werden – da wiederkehrende Aufgaben inzwischen automatisiert sind. Auch gibt es deutlich weniger Notfälle (ebenfalls aufgrund der Automatisierung). Die Reduzierung routinemäßiger Aufgaben geht einher mit einer größeren Aufgabenvielfalt für den supply chain practitioner. Typischerweise führt dies dazu, dass weniger Zeit und Aufwand für die Steuerung der supply chain aufgewendet wird, während von der Führung erwartet wird, Mitarbeiter weiterzubilden, damit sie den zusätzlichen freien Spielraum sinnvoll nutzen können.

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

5.3 Wie gehen Sie mit Änderungen im Workflow für Endanwender um? Erstens im Rahmen des Lokad-Onboardings, zweitens im Zuge der eigenen Weiterentwicklung von Lokad.

Per Design erfordern die von Lokad generierten supply chain-Entscheidungen keine Workflows. Tatsächlich ist die Automatisierung aller Schritte, die zur Erstellung der supply chain-Entscheidungen führen, die angestrebte Lösung.

Sollte der Kunde jedoch explizit darum bitten, ist Lokad in der Lage, einen „Workflow“ einzuführen, der dem Legacy-Workflow entspricht. Dies dient, wie zu verstehen ist, ausschließlich der Erleichterung des Änderungsmanagements und stellt keinesfalls eine Voraussetzung für den Erfolg des numerischen Rezepts dar. Mit zunehmender Vertrautheit und steigendem Vertrauen der Kundenmitarbeiter in die von Lokad generierten Entscheidungen kann der „Workflow“ schrittweise vereinfacht werden, bis er schließlich ganz entfällt.

Bezüglich der Weiterentwicklung von Lokad: Unsere Plattform ist programmatisch und wird von Envision (unserer domänenspezifischen Programmiersprache) gesteuert. Alle Änderungen/Updates an Envision erfolgen durch automatisierte Skripte, und dieser Prozess ist so programmiert, dass die von Lokad gehosteten supply chain-Initiativen unberührt bleiben.

5.4 Können Sie ein Issues & Risk Register führen, das einen Maßnahmenplan, Aufgaben, Verantwortlichkeiten, Zeitpläne und Status (nicht begonnen, in Bearbeitung, abgeschlossen, pausiert) umfasst? Wird der Project Manager von Lokad dafür verantwortlich sein, alle Issues & Risks zu verfolgen und eine zeitgerechte Lösung sicherzustellen oder Eskalationen bei Bedarf zu managen?

Ja. Lokads Plattform verfügt über einen eigenen internen 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 etc. Darüber hinaus 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. Lokad’s Supply Chain Scientists (SCSs) sind für die Überwachung des Task-Managers verantwortlich. Sie stellen sicher, dass Probleme und Bedenken umgehend behandelt werden.

Eskalationen sind möglich, aber selten. Derselbe SCS, der die Aufgaben verwaltet bzw. überprüft, wird diese 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 problemlos kontaktieren zu können, 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 eventueller Probleme zu überwachen, anstatt mehrere Ebenen der Bürokratie durchlaufen zu müssen, um – hoffentlich – mit jemandem zu sprechen, der ihm helfen kann.

Falls ein Problem auftritt, das Fähigkeiten erfordert, die über das Fachwissen eines SCS hinausgehen (z. B. ein technisches Problem mit der Architektur der Plattform), überwachen sie dennoch die zeitgerechte Lösung des Problems und fungieren als erster Ansprechpartner für den entsprechenden Kunden.

5.5 Bieten Sie Beratungsleistungen im organisatorischen Änderungsmanagement an, um die Einführung und Anpassung von Geschäftsprozessen sowie die Stilllegung bestehender Prozesse zu begleiten?

Ja, sofern das Kundenunternehmen wünscht, dass ihre Partnerschaft mit Lokad auch Beratungsleistungen im Änderungsmanagement umfasst. Es sei darauf hingewiesen, dass Lokads primäre Expertise in der prädiktiven Optimierung der supply chain liegt und nicht im Änderungsmanagement. Unser Ansatz im Änderungsmanagement ist zudem konventioneller als unsere supply chain-Praktiken. Dieser Ansatz würde – wenn er umgesetzt wird – die Zahl der am Projekt beteiligten Drittparteien begrenzen.

Alternativ, falls das Kundenunternehmen es vorzieht, die Dienste eines Änderungsmanagement-Spezialisten zusätzlich zu Lokad in Anspruch zu nehmen, werden wir es unterstützen, indem wir so viel teilen, wie das Kundenunternehmen für angebracht hält.

6. Anpassung & Systemfunktionalität

6.1 Organisieren Sie Sitzungen, um Anpassungsanforderungen zu priorisieren, sodass ein Verständnis der geschäftlichen Auswirkungen aufgrund von Produktlücken gewährleistet wird und eine gegenseitige Übereinkunft über die Priorität der Freigabe von Anpassungen erreicht wird?

Ja. Die Supply Chain Scientists (SCSs) von Lokad sind für diesen Prozess verantwortlich. Tatsächlich sticht Lokad in Bezug auf diese Priorisierung in zweierlei Hinsicht hervor. Erstens ist ein SCS in der Lage, die Anpassung eigenständig umzusetzen und kann somit klare Einblicke darüber geben, was in Bezug auf Ressourcen und Zeitrahmen auf dem Spiel steht.

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

Zweitens betont “die Quantitative Supply Chain” – Lokads übergeordnete Philosophie – eine rein finanzielle Perspektive. Folglich unterstützt der SCS das Kundenunternehmen dabei, quantitative Schätzungen (in Dollar oder Euro) über die Auswirkungen einer potenziellen Änderung an der Lösung zu liefern. Diese Strategie verfeinert die Initiative, indem der traditionelle Engpass der Debatte darüber, was priorisiert werden sollte, vermieden wird. Stattdessen strafft Lokad diesen Prozess, indem Probleme priorisiert werden, die den größten finanziellen Einfluss haben.

6.2 Können Sie eine Fit-Gap-Analyse aller Geschäftsprozesse durchführen, um Automatisierungsmöglichkeiten zu identifizieren, die gewünschten 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 identifiziert werden?

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

Was die Optimierung der supply chain betrifft, so sind Lücken selten eine Frage der „Funktionalität“, sondern vielmehr eine Frage 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 SCSs mit der Identifizierung und Behebung von „Performance-Lücken“, die manchmal zusätzliche Funktionalität oder eine Umgestaltung der Lösung erfordern. Dies kann das Hinzufügen oder Entfernen von Funktionen beinhalten, um die Gesamtleistung zu optimieren.

In diesem Zusammenhang ist Lokads Plattform programmatisch aufgebaut. Somit können jegliche wahrgenommenen „Funktionalitätslücken“ durch das Hinzufügen (oder Anpassen) einiger Zeilen Envision-Code behoben werden. Diese Programmierbarkeit ermöglicht es Lokad gerade, maßgeschneiderte Lösungen für jeden Kunden bereitzustellen.

6.3 Können Sie eine detaillierte Agenda für die Workshops zur Fit-Gap-Analyse des Prozesses bereitstellen, einschließlich der Erwartungen der SMEs (Subject Matter Experts) auf Kundenseite, mindestens eine Woche vor Beginn der Workshops?

Ja. Die Supply Chain Scientists (SCSs) von Lokad stellen für jeden Workshop eine Agenda bereit. Wir stellen sicher, dass die Agenda mindestens eine Woche vor der Veranstaltung kommuniziert wird. Wenn das Kundenunternehmen explizite Anweisungen gibt, wie beispielsweise einen Zeitrahmen für die Bereitstellung der Agenda(n), werden wir diesen folgen. In Abwesenheit von Anweisungen strukturieren wir die Workshops (einschließlich Zeitplan und aller notwendigen Kundenschritte) auf intelligente und professionelle Weise.

6.4 Stellen Sie sicher, dass die Anforderungsdokumente für die Produktanpassung gemeinsam geprüft und vom Kundenunternehmen genehmigt werden?

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

Bitte beachten Sie, dass Lokads Plattform-Design-Entscheidungen den Bedarf an „Anpassung“ weitgehend überflüssig machen – zumindest in der im unternehmerischen Softwarebereich üblichen Bedeutung dieses Begriffs. Lokads Plattform ist programmatisch aufgebaut und verwendet Envision – unsere DSL (domänenspezifische Programmiersprache), die der prädiktiven Optimierung der supply chain gewidmet ist.

Somit sind Lokads Lösungen immer „kundenspezifisch“ im Sinne, dass sie vollständig auf die spezifischen Bedürfnisse des Kundenunternehmens zugeschnitten sind. Allerdings wird diese Anpassung so umgesetzt, dass die Lösung weiterhin Teil von Lokads Hauptproduktlinie bleibt. Dies ist Lokads bevorzugter (und bewusst konzipierter) Ansatz und bringt keine Wartbarkeitsprobleme mit sich.

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

Ja. Lokads Supply Chain Scientists (SCSs) unterstützen bei der Einrichtung, dem Testen, der Validierung und der Dokumentation der Schnittstellen zwischen den vom Kundenunternehmen betriebenen Systemen und Lokad. Die Supply Chain Scientists können bei sehr tiefgreifenden technischen Aspekten, wie z. B. Netzwerk- oder Sicherheitsprotokollen, durch interne IT-Ressourcen bei Lokad ergänzt werden.

Die Schnittstellen der Systeme werden in der Regel nicht von einer unabhängigen Zertifizierungsstelle zertifiziert. Sie werden durch technische Spezifikationen, die zwischen der IT-Abteilung des Kundenunternehmens und Lokad gemeinsam vereinbart werden, „formal festgelegt“. Diese technischen Spezifikationen unterstützen die gegenseitigen Verpflichtungen der Unternehmen: Kurz gesagt, das Kundenunternehmen verpflichtet sich, Lokad die erforderlichen Daten rechtzeitig bereitzustellen; Lokad wiederum verpflichtet sich, die Ergebnisse ebenfalls pünktlich zurückzugeben.

6.6 Stellen Sie während der Workshops Schnittstellenspezifikationsdokumente zur Verfügung, einschließlich Beispielsnachrichten?

Ja, Lokad stellt während der Workshops Schnittstellenspezifikationen zur Verfügung. Beispielsnachrichten können auf Wunsch des Kundenunternehmens mit einbezogen werden.

Aufgrund der Natur von Lokads Dienstleistung werden die „Beispielsnachrichten“ jedoch sehr wahrscheinlich in Form von Tabellen auftreten – da diese den von Lokad für das Kundenunternehmen generierten Output genauer wiedergeben. Zum Vergleich: Der überwiegende Teil der technischen Spezifikationen für die Schnittstellen konzentriert sich auf Tabellen und deren Format(e), sowie auf Tabellenauszugsmuster und Übertragungspläne.

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

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

Erstens werden Änderungen, die speziell für Kunden vorgenommen werden, von den Supply Chain Scientists selbst implementiert. Diese Änderungen erfolgen häufig, oft mehrmals am Tag, insbesondere während der Onboarding-Phase. Solche Änderungen erfolgen als direkte Antwort auf die Bedürfnisse des Kundenunternehmens und erfordern einen intensiven Austausch zwischen beiden Parteien.

Zweitens aktualisieren wir Lokads Plattform, typischerweise durch Updates von Envision – unserer DSL (domänenspezifischen Programmiersprache) für die prädiktive Optimierung von supply chain. Diese Änderungen sind so gestaltet, dass sie für die Kundenunternehmen transparent sind. Falls gewünscht, können Details zu diesen Updates bereitgestellt werden, und ein Großteil dieser Informationen wird öffentlich zugänglich gemacht.

Weitere Informationen zur Entwicklung von Lokads Plattform finden Sie unter Envision VM Environment and General Architecture.

7. Benutzerakzeptanztests (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 hierfür einzigartige methodische und technische Innovationen an.

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

Technologisch wurde Lokads Plattform speziell so entwickelt, dass sie mehrere Umgebungen gleichzeitig für jede Initiative unterstützt. Diese Umgebungen sind ein natives Merkmal unserer Multi-Tenant-SaaS-Plattform und können daher mit minimalem Mehraufwand eingeführt werden, sowohl hinsichtlich der Rechenressourcen als auch der Systemadministrationszeit.

Siehe auch User Acceptance Testing 7.3.

7.2 Konfigurieren Sie die UAT (User Acceptance Testing)-Umgebungen für Pre-Production, Production und Training gemäß den definierten ToBe-Prozessen?

Ja. Aufgrund der umfangreichen Programmierbarkeit von Lokads Plattform können wir die vollständige Kontrolle über Konfigurationen ausüben. Dies wird durch Envision ermöglicht – unsere DSL (domänenspezifische Programmiersprache) für die prädiktive Optimierung von supply chain.

Dieser Ansatz ermöglicht es, dass verschiedene Umgebungen dieselbe Konfiguration für alle nicht änderbaren Teile verwenden – indem möglichst überall derselbe Code genutzt wird. Dies reduziert zufällige Unterschiede zwischen den Umgebungen erheblich, die Benutzer verwirren und die Integrität des UAT-Prozesses beeinträchtigen können.

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

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

Ja. Lokads Plattform wurde speziell so entwickelt, dass sie mehrere Umgebungen gleichzeitig für jede Initiative unterstützt. Diese Umgebungen sind ein natives Merkmal unserer Multi-Tenant-SaaS-Plattform und können daher mit minimalem Mehraufwand eingeführt werden, sowohl hinsichtlich der Rechenressourcen als auch der Systemadministrationszeit.

Bei Lokad erfolgt die Duplizierung der gesamten Produktionsumgebung, einschließlich aller Produktionsdaten, ohne dass sich der Speicherplatzbedarf verdoppelt. Intern werden Daten, die zwischen den beiden Umgebungen identisch sind, gemeinsam genutzt. Darüber hinaus stellt unser konstantzeitliches Design sicher, dass die Arbeitslast einer Umgebung die Leistung einer anderen Umgebung nicht negativ beeinträchtigt.

Die meisten Anbieter von Unternehmenssoftware umgehen das Problem dagegen, indem sie einfach die Hauptkonfiguration „klonen“. Klonen – oder reine Duplizierung – ist zwar einfach, aber verschwenderisch. Klonen bedeutet, dass der Ressourcenbedarf (Personal und Maschinen) mit der Anzahl der Umgebungen linear steigt – z. B. verdreifachen drei Umgebungen die ursprünglichen Kosten. Bei jeder umfangreichen supply chain führt dies zu erheblichen Kosten.

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

Ja, sofern sich die Parteien auf nuancierte Definitionen von „Lösung“ und „Mangel“ einigen können. Insgesamt sind Lokads Supply Chain Scientists (SCSs) dafür verantwortlich, alle Probleme zu beheben, die das Hauptziel der Initiative – die Steigerung der Kapitalrendite – untergraben. In einem typischen Szenario schlägt der SCS eine geeignete Maßnahme und einen entsprechenden Zeitrahmen vor, den das Kundenunternehmen nach eigenem Ermessen validiert oder anpasst.

Es ist wichtig zu betonen, dass es in einer supply chain keine perfekten Lösungen gibt, sondern nur bessere und schlechtere Kompromisse. Mit anderen Worten, ein Problem, bei dem zwei oder mehr Werte in völliger Gegensätzlichkeit stehen, kann nicht tatsächlich gelöst werden.

Beispielsweise ist abgelaufener verderblicher Lagerbestand verschwenderisch, aber beim Umgang mit verderblichen Produkten kann eine solche Verschwendung nicht vollständig eliminiert werden, ohne ein damit verbundenes Problem bei der Servicequalität zu verursachen. Es muss ein Gleichgewicht zwischen Überbeständen und Fehlbeständen gefunden werden. Dennoch sind sowohl „Überbestände“ als auch „Fehlbestände“ gewissermaßen Mängel.

Kurz gesagt können SCSs „alltägliche“ Probleme beheben, sobald sie auftreten, wie zum Beispiel das Beheben eines Parsing-Fehlers beim Auslesen einer Datei (ein Softwarefehler). Das übergeordnete Ziel einer Quantitative Supply Chain-Lösung ist jedoch nicht, Probleme zu „lösen“, sondern die Kapitalrendite (in Dollar oder Euro) zu steigern. Lokad erreicht diese Art der „Lösung“ durch einen intelligenten, finanziell getriebenen Ansatz zu supply chain Kompromissen.

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 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 umfangreich sein wie die Produktionsumgebung, um eine End-to-End-supply chain Perspektive widerzuspiegeln. Diese Anforderung hat nichts mit Lokad zu tun; sie ist einfach der Natur von supply chain zuzuschreiben.

7.6 Garantieren Sie vor Ort Unterstützung an der Zentrale des Kundenunternehmens während der UAT (User Acceptance Testing)-Phase?

Ja. Die Vor-Ort-Unterstützung wird durch die vertragliche Vereinbarung zwischen Lokad und dem Kundenunternehmen geregelt. Dieser Aspekt wird immer individuell pro Kunde verhandelt.

Es sei darauf hingewiesen, dass eine Quantitative Supply Chain-Initiative mit Lokad kontinuierliche supply chain Verbesserungen mit sich bringt, weshalb es keinen festen UAT-Zeitraum gibt. Die Tests beginnen in der Regel Ende des zweiten Monats, erreichen im vierten Monat ihren Höhepunkt und stabilisieren sich ab dem sechsten Monat.

Indem Lokad kontinuierliche Ressourcen der Verfeinerung unserer numerischen Rezepte (Algorithmen, die der Optimierung von supply chain gewidmet sind) widmet, stellt es sicher, dass jedes Kundenunternehmen über eine aktuelle Initiative verfügt.

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 Bereichen Technik, IT und Einkauf des Kundenunternehmens zugewiesen und bis zum Abschluss verfolgt werden?

Ja. Lokads Supply Chain Scientists (SCSs) erstellen und pflegen für jede Initiative ein Joint Procedure Manual (JPM). Es umfasst alle relevanten Erkenntnisse der 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 sehr technisch sind).

Groß angelegte Maßnahmen werden im JPM dokumentiert. Kleinere Maßnahmen werden jedoch in der Regel mit dem Task-Manager auf Lokads Plattform verwaltet. Diese kleineren Punkte sind kurzlebig, und der Task-Manager ermöglicht ein effizienteres Nachverfolgen und Abschließen als das JPM.

8.2 Können Sie sicherstellen, dass ausreichende Qualitäts- und Compliance-Berichte zur Überwachung der Nutzung und Akzeptanz des Systems vorliegen?

Ja. Lokads Supply Chain Scientists (SCSs) implementieren in der Regel spezielle Instrumentierungen für diesen Zweck in der Endphase des Onboardings, kurz vor dem offiziellen Kick-off.

Zusätzlich kann Lokad die Übereinstimmung zwischen den supply chain Entscheidungen, die es generiert, und den tatsächlich in der supply chain getroffenen Entscheidungen nachverfolgen. Dies geschieht, um potenzielle Ursachen für Abweichungen zu identifizieren, wie beispielsweise 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 Feedback zur Verbesserung der Nutzung und Endnutzerakzeptanz des Systems, um die Kapitalrendite (ROI) schneller zu realisieren?

Ja, ein jährliches Audit der gesamten Lösung (End-to-End) ist Standardprozedur. Allerdings auditieren Lokads Supply Chain Scientists (SCSs) in der Regel die gesamte Lösung mehrmals im Jahr. Das jährliche Audit führt in der Regel zu einer detaillierten Roadmap-Präsentation für die Führungsebene des Kunden. Dies entspricht unserem Ansatz der kontinuierlichen Verbesserung jeder Initiative.

Hinsichtlich der Nutzung implementieren SCSs in der Praxis frühzeitig proaktiv spezielle Tools, um die Nutzung, Akzeptanz und Einhaltung der supply chain Entscheidungen, die Lokad generiert, zu überwachen. Während ein jährliches Audit eine hervorragende Gelegenheit bietet, notwendige Anpassungen vorzunehmen, sind unsere SCSs bei der Umsetzung von Lokads supply chain Empfehlungen sehr proaktiv. Diese Angelegenheit wird in unseren wöchentlichen Arbeitssitzungen besprochen, da die Umsetzung von Lokads Empfehlungen der Haupttreiber für eine gesteigerte Kapitalrendite in einer Quantitative Supply Chain-Initiative ist.

8.4 Können Sie sicherstellen, dass das dedizierte Produktsupport-Team, das vor Ort bei der Zentrale des Kundenunternehmens sitzt, das Produkt mindestens 6 Monate nach dem Go-Live weiterhin unterstützt?

Ja. Lokads Team von Supply Chain Scientists (SCSs) übernimmt 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 Vor-Ort-Präsenz der SCSs wird vertraglich mit dem Kunden vereinbart und geklärt, falls der Kunde dies wünscht.

In diesem Zusammenhang empfiehlt Lokad nachdrücklich, ein aktives, fortlaufendes Engagement für die Verbesserung der Lösung, insbesondere auf Kundenseite, aufrechtzuerhalten. Unseren Erfahrungen zufolge schwächen das Einstellen von kontinuierlichen Verbesserungsbemühungen die Stärke der Initiative. Jegliche Änderungen auf Kundenseite, einschließlich kleiner Anpassungen in der Applikationslandschaft oder bei den Rahmenbedingungen, können die Qualität der von Lokad generierten Entscheidungen beeinträchtigen; daher wird aktive Wachsamkeit und kontinuierliche Verbesserung angeraten.

Siehe auch Project Implementation & Management 1.7.

9. Vorfalls- und Fehlermanagement

9.1 Können Sie sicherstellen, dass alle unbedingt zu behebenden Mängel und Änderungsanforderungen (kritische und hochprioritäre Punkte) vorrangig bearbeitet und umgesetzt werden, um Verzögerungen im Go-Live-Zeitplan des Kundenunternehmens zu vermeiden?

Ja. Lokads Supply Chain Scientists (SCSs) sind für diesen Prozess verantwortlich. Unsere Plattform ist so konzipiert, dass sie es ihnen ermöglicht, Mängel und Änderungsanforderungen zügig und eigenständig zu bearbeiten.

Lokads Plattform ist programmatisch, was durch Envision – unsere DSL (domänenspezifische Programmiersprache) für die prädiktive Optimierung von supply chain – ermöglicht wird. Diese Programmierbarkeit bedeutet, dass die Supply Chain Scientists umgehend Fehler beheben und angeforderte Änderungen an der Initiative umsetzen können, und zwar mit einer Präzision, wie sie in Unternehmenssoftware üblicherweise nicht anzutreffen ist.

Jenseits der Technologie sind Lokads SCSs darauf geschult, eine Reihe von Schlüsselrollen zu erfüllen, die naturgemäß die Anzahl der Personen reduziert, die benötigt werden, um Defekte und Änderungsanfragen zu bearbeiten. Diese Rollen umfassen supply chain expert, business analyst, data scientist, data engineer und systemintegrator. Sie sind somit gut ausgebildet, um 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 Defekt-Überwachungsmechanismus implementieren, um die rechtzeitige Schließung aller Defekte und Usability-Probleme sicherzustellen?

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 präzise nachzuverfolgen. Diese Lösungen werden von den Teams der Supply Chain Scientists (SCSs) von Lokad betreut.

Allerdings ist es wichtig, „Defekte“ und „Usability-Probleme“ nicht zusammenzufassen. Zum Beispiel stellt eine ungenaue Nachfrageprognose einen „Defekt“ dar, der sich negativ auf die supply chain auswirkt. Je nach den Marktbedingungen, unter denen das Kundenunternehmen operiert, kann es jedoch sein, dass dieser „Defekt“ nie vollständig behoben, sondern nur gemindert wird. Bei der prädiktiven Optimierung von supply chains handelt es sich stets um einen Kompromiss: Ein Defekt wird behoben, während ein anderer – hoffentlich kleinerer – entsteht.

Im Gegensatz dazu lassen sich Usability-Probleme in der Regel unkompliziert beheben. Daher sind wir bei dieser Art von Problemen bereit und verpflichtet, eine zeitnahe Lösung sicherzustellen, da die Behebung des Problems typischerweise keine weiteren Probleme verursacht.

9.3 Können Sie sicherstellen, dass Defekte, die während der Testphase von Releases (vor der Produktion) festgestellt werden, zeitnah bearbeitet und behoben werden, sodass sie den Zeitplan des Kundenunternehmens für das Go-live des Releases nicht beeinträchtigen?

Ja. Wenn die festgestellten Defekte den kundenspezifischen Code (in Envision geschrieben) betreffen, werden diese von Lokads Supply Chain Scientists (SCSs) behoben. Betreffen die festgestellten Defekte hingegen die Lokad-Plattform, so werden sie von Lokads Softwareentwicklungsteams behoben.

In jedem Fall umfasst Lokads Release-Prozess umfangreiche Tests, um sicherzustellen, dass Defekte vor dem Release (Go-live) identifiziert und behoben werden.

9.4 Wie werden Sie Vorfälle behandeln, 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 größter Ernsthaftigkeit. Die vertragliche Vereinbarung zwischen Lokad und dem Kundenunternehmen legt fest, wie viele SCSs dem Projekt zugewiesen werden und wie viele Stunden pro Woche direkter Support zur Verfügung stehen.

Die Lösung eines typischen Vorfalls beginnt damit, dass ein SCS einen neuen Eintrag im Aufgaben-/Ticket-/Issue-Manager erstellt. Dadurch wird die Rückverfolgbarkeit des Vorfalls sichergestellt.

Anschließend diagnostiziert der SCS das Problem. Falls eine Behebung auf Lokads Seite erforderlich ist, mobilisiert der SCS sofort die notwendigen Ressourcen zur Problemlösung – typischerweise der SCS selbst.

Schließlich wird, sobald das Problem behoben ist, der SCS die tatsächliche Ursache des gemeldeten Problems bewerten, selbst wenn sich herausstellt, dass der Bericht letztlich kein Problem darstellte. In der Regel gibt es ein zugrunde liegendes Problem, das angegangen werden muss. Indem Lokad die tiefer liegende Ursache beseitigt, werden ähnliche Probleme in Zukunft proaktiv vermieden.

9.5 Wenn ein Defekt außerhalb des Incident Management Tools – beispielsweise per E-Mail – gemeldet wird, registrieren Sie den Defekt dann umgehend im Tool, um eine ordnungsgemäße Nachverfolgung und Compliance zu gewährleisten?

Ja. Es ist gängige Praxis, einen entsprechenden Eintrag innerhalb der Lokad-Plattform zu erstellen, wenn wir eine Meldung über einen anderen Kanal als den Aufgaben-/Ticket-/Issue-Manager erhalten. Dieses Vorgehen erleichtert eine umfassende Nachverfolgung und Compliance.