Warum MES in großem Maßstab scheitert (und was man dagegen tun kann)

Meistens werden die Misserfolge MES den Menschen angelastet. Das Einführungsteam macht die Schulung dafür verantwortlich, der Produktionsleiter die Akzeptanz seitens der Bediener. Keine dieser Sichtweisen ist zwangsläufig falsch, doch beide sind unvollständig.

Wenn die Einführung eines Systems an mehreren Standorten und in verschiedenen Abteilungen ins Stocken gerät, liegt die Ursache für diese Lücke meist in der Systemarchitektur. Das System kann sich nicht mit der Geschwindigkeit und Detailgenauigkeit anpassen, die die Arbeit erfordert, sodass sich die Mitarbeiter stattdessen an das System anpassen müssen.

McKinsey berichtet, dass mindestens 70 % der Hersteller im „Pilot-Fegefeuer“ feststecken und nicht in der Lage sind, digitale Initiativen über die anfängliche Implementierungsphase hinaus auszuweiten. Trotz Verbesserungen in der Art und Weise, wie Unternehmen change management betrachten und angehen, ist dieser Anteil relativ konstant geblieben.

In diesem Beitrag werden wir die häufigsten Bereiche beleuchten, in denen MES bei standortübergreifenden Implementierungen scheitert, erläutern, warum die Ursache dafür fast immer in der Architektur (und nicht im Nutzerverhalten) liegt, und zeigen, wie eine erfolgreiche Einführung aussieht, wenn das System so konzipiert ist, dass es sich an die bestehenden Arbeitsabläufe anpasst.

Am Ende verfügen Sie über das nötige Vokabular, um Ihrem Lenkungsausschuss zu erklären, warum die nächste Einführung an derselben Stelle ins Stocken geraten könnte wie die letzte, sowie über eine Checkliste mit architektonischen Fragen, die Sie in Ihre nächste Ausschreibung für Anbieter aufnehmen können.

Wenn Sie bereits an MES beteiligt waren, wissen Sie wahrscheinlich, wie der übliche Implementierungsansatz aussieht. Die meisten Anbieter und Integratoren verfolgen ein ähnliches Vorgehen, und die change management konzentrieren sich auf dieselben Empfehlungen: klare Ziele definieren, die Einführung in Phasen durchführen, in rollenspezifische Schulungen investieren, die Änderung kommunizieren, die Unterstützung der Führungskräfte sichern und relevante Teams und Stakeholder frühzeitig in die Planungsgespräche einbeziehen.

Branchenübergreifend ist die Wahrscheinlichkeit, dass Projekte mit soliden change management termingerecht abgeschlossen werden, etwa fünfmal höher als bei Projekten ohne solche Programme, und bereits eine klare Kommunikation allein führt nachweislich zu einer messbaren Steigerung der Erfolgsquote. Schulungen, Kommunikation, Unterstützung durch Führungskräfte und die Einbindung funktionsübergreifender Teams tragen ebenfalls dazu bei.

Was in diesem Leitfaden jedoch außer Acht gelassen wird, ist die vorgelagerte Phase. Er betrachtet die Akzeptanz als eine nachgelagerte Auswirkung der Art und Weise, wie die Einführung gesteuert wird, obwohl die Akzeptanz auch davon abhängt, wie das System aufgebaut ist.

Wenn man dasselbe change management bei zwei verschiedenen MES anwendet, können die Ergebnisse sehr unterschiedlich ausfallen. Das eine Unternehmen dehnt die Einführung auf zehn Werke aus, während das andere Mühe hat, über das erste hinauszukommen.

Diese Lücke lässt sich in der Regel damit erklären, ob die Architektur flexibel genug ist, um die Schwankungen zu bewältigen, die in realen Produktionsumgebungen tagtäglich auftreten. Wenn wir gemeinsam mit Führungskräften aus dem operativen Bereich eine ins Stocken geratene Bereitstellung analysieren, lassen sich die von ihnen beschriebenen Herausforderungen selten auf Probleme zurückführen, die durch einen besseren change management hätten behoben werden können. Vielmehr liegen die Ursachen dort, wo das System mit der Arbeitslast nicht Schritt halten konnte.

Wir haben festgestellt, dass ins Stocken geratene MES in der Regel auf ähnliche Weise scheitern. Wir haben mit Herstellern mit mehreren Standorten in einer Vielzahl komplexer Branchen zusammengearbeitet, und die folgenden vier Probleme tauchen in fast jeder Nachbetrachtung auf, die wir sehen. Sie alle lassen sich auf dasselbe architektonische Problem zurückführen: Die Plattform kann sich nicht so schnell anpassen, wie sich die Arbeitsabläufe ändern, sodass das Team vor Ort gezwungen ist, Umgehungslösungen zu entwickeln.

Aus der Perspektive des Projektplans erscheinen diese Notlösungen zunächst wie Versäumnisse in der Schulung oder kulturelle Probleme. Bei genauerer Betrachtung sind sie jedoch die rationale Reaktion auf ein System, das den Bedürfnissen des Teams nicht gerecht wird.

Veraltete Schnittstellen und die neue Belegschaft

MES meisten älteren MES wurden in einer Zeit entwickelt, in der die Mitarbeiter in der Fertigung jahrelang in ihrer Position blieben und sich fundierte Kenntnisse im Umgang mit den Menüs aneigneten. Die Benutzeroberfläche war umständlich, doch die Bediener lernten den Umgang damit, und es gab nicht unbedingt eine bessere Alternative.

Deloitte und das Manufacturing Institute gehen davon aus, dass die US-Fertigungsindustrie zwischen 2024 und 2033 netto 3,8 Millionen neue Arbeitskräfte benötigen könnte, wobei bis zu 1,9 Millionen Stellen möglicherweise unbesetzt bleiben. Die neue Generation, die in die Fertigung eintritt, erwartet eine Benutzererfahrung, die eher der von Verbraucher-Apps ähnelt: übersichtlich, touch-orientiert und sofort erlernbar. Herkömmliche MES ihnen menügesteuerte Unternehmensbildschirme, die buchstäblich vor einer Generation entworfen wurden.

Diese Diskrepanz äußert sich an jedem Standort in längeren Einarbeitungszeiten. Die Zeit bis zum Erreichen der erforderlichen Kompetenz dauert bei MES älterer MES Wochen statt Tage, und die Werke gleichen diese Lücke durch vermehrte Überstunden erfahrener Bediener oder Produktivitätsverluste während der Anlaufphase aus. Mit steigender Fluktuation summieren sich beide Kostenfaktoren.

Die „Workaround-Wirtschaft“ und die Kosten des Wandels

Die Arbeitsabläufe in der Produktion ändern sich im Laufe der Zeit. Nehmen wir beispielsweise ein Qualitätsteam, das auf ein neues Muster von Abweichungen stößt, das das bestehende Formular zur Abwicklung nicht erfasst. In einem älteren MES bedeutet eine Änderung des Formulars ein IT-Ticket, die Einbindung eines Lieferanten und einen Freigabezyklus. Nach einigen Runden mit der Aussage „Wir kümmern uns im nächsten Quartal darum“ hört das Qualitätsteam auf, nachzufragen, und beginnt, das System zu umgehen.

Sechs Monate nach der Inbetriebnahme kann man in der Regel in ein Werk gehen und dort das beobachten, was wir als „Workaround-Wirtschaft“ bezeichnen: eine Reihe paralleler Tabellenkalkulationen und auf „Stammeswissen“ basierender Prozesse, die rund um das MES entstanden sind, MES das offizielle System nicht mithalten konnte.

Das Qualitätsteam führt ein Protokoll für Abweichungen in Excel, die Instandhaltungsabteilung verfügt über ein eigenes Tool für Arbeitsaufträge, und andere Abteilungen nutzen ihre eigenen Varianten davon. Das MES zwar technisch implementiert, doch die eigentliche Arbeit findet in den parallelen Systemen statt, die jedes Team selbst entwickelt hat.

Solange die Kosten für eine Umstellung des offiziellen Systems höher sind als die Kosten für die Umgehungslösung, werden sich die Teams jedes Mal für die Umgehungslösung entscheiden. Eine strengere Durchsetzung der Nutzung des offiziellen Systems wird daran nichts ändern.

Standortübergreifende Konsistenz

Bei der Einführung an mehreren Standorten tritt ein anderes Problem auf. Jedes Werk funktioniert anders als die anderen: unterschiedliche Produkte, unterschiedliche Anlagen, unterschiedliche regulatorische Anforderungen, unterschiedliche Betriebskulturen, unterschiedliche digitale Reifegrade. Eine einzige MES kann dieser Bandbreite an Unterschieden in der Regel nicht auf einmal gerecht werden, doch viele ältere Vorlagen basieren auf der Annahme, dass dies möglich sei.

Als Faustregel für standortübergreifende Rollouts gilt, dass eine globale Vorlage in der Regel 70 bis 80 % der Bereitstellung abdeckt, während die verbleibenden 20 bis 30 % für standortspezifische Faktoren reserviert sind. Wenn die Standardisierung über diese Grenze hinausgeht, muss der Standort entweder einen Arbeitsablauf akzeptieren, der nicht mit den Abläufen im Werk übereinstimmt, oder die Vorlage in eine Sonderkonfiguration aufteilen, die das zentrale Team separat pflegen muss.

Modulare Architekturen lösen diesen Zielkonflikt, indem sie es jedem Standort ermöglichen, die Lösungen an seine betrieblichen Gegebenheiten anzupassen, während gleichzeitig das Datenmodell, die Governance und die Compliance-Vorgaben, die unternehmensweit einheitlich sein müssen, gemeinsam genutzt werden.

Ein weiterer erschwerender Faktor ist der Zeitplan für die Implementierung. MES älteren MES dauert es in der Regel 18 bis 36 Monate bis zur Inbetriebnahme am ersten Standort, wobei sich die Einführung an mehreren Standorten noch um Jahre darüber hinaus erstreckt. Wenn die Einführung den dritten oder vierten Standort erreicht, entspricht die ursprüngliche Implementierung bereits nicht mehr den aktuellen Betriebsabläufen am ersten Standort.

Warum die Echtzeit-Transparenz nicht bis in die Produktion vordringt

Herkömmliche MES als zentrale Datenspeicher konzipiert. Die Daten, die der Bediener bei jedem Schritt eingibt, werden erfasst, in Berichte zusammengefasst und an die übergeordneten Ebenen weitergeleitet – an den Vorgesetzten, den Werksleiter und die Dashboards der Geschäftsleitung. Die Compliance-Abteilung erhält die benötigten Informationen, Kennzahlen werden berechnet und ein Prüfpfad erstellt.

Was jedoch nicht immer der Fall ist, ist der umgekehrte Informationsfluss. Viele MES sind nicht darauf ausgelegt, kontextbezogene Echtzeitinformationen an die Fertigungsebene zurückzuspielen. Ein Bediener, der wissen möchte, ob seine Linie gerade im Zeitplan liegt, muss möglicherweise auf eine Tafel zurückgreifen, die der Fertigungsleiter einmal pro Schicht aktualisiert.

Die gleiche Lücke zeigt sich auf der Führungsebene, wo Entscheidungen auf der Grundlage von Informationen getroffen werden, die bereits mehrere Stunden alt sind, sowie in der Prozessentwicklung, wo die Ursachenanalyse anhand von Batch-Exporten statt anhand von Echtzeitdaten erfolgt.

Die zugrunde liegende architektonische Entscheidung betrifft das „System of Record“. Herkömmliche MES darauf ausgelegt, Geschehnisse zu protokollieren, nicht aber, die nächste Entscheidung zu unterstützen. Ein „System of Engagement“ schließt diese Lücke, indem es genau jene Daten, die das System erfasst, den Mitarbeitern vor Ort zur Verfügung stellt, die sie dort nutzen können. Echtzeit-Transparenz ist dann nicht mehr nur ein Schlagwort, das in der Unternehmensführung im Zusammenhang mit der Berichterstattung verwendet wird, sondern wird zu einer Realität, die die Mitarbeiter in der Produktion unmittelbar erleben.

Alle vier Probleme lassen sich auf die Systemarchitektur zurückführen. Ältere MES für eine Welt konzipiert, in der die Mitarbeiter ihre Aufgabenbereiche beibehielten, sich die Arbeitsabläufe kaum änderten, der Betriebsablauf von Werk zu Werk ähnlich war und Daten nur in einer Richtung nach oben fließen mussten. Keine dieser Annahmen trifft heute noch auf die meisten Hersteller zu, und diese älteren Systeme wurden nicht dafür entwickelt, sich an die Betriebsabläufe heutiger Werke anzupassen.

MES meisten herkömmlichen MES sind als Monolithen aufgebaut, wobei jede Funktion fest mit jeder anderen Funktion innerhalb eines einzigen Systems verknüpft ist. Das Hinzufügen eines einzigen Datenfelds zu einer Qualitätsprüfung hat Auswirkungen auf den gesamten Code, weshalb selbst kleine Anpassungen wochenlange Entwicklungs-, Validierungs- und koordinierte Einführungsphasen erfordern können. Dieselbe Verknüpfung, die für interne Konsistenz und Governance sorgt, ist auch der Grund dafür, dass Änderungen am System strukturell aufwendig sind.

Ein modulares MES ist anders aufgebaut. Es setzt sich aus einem Ökosystem von Apps und Diensten zusammen und nicht aus einem einzigen Block, was bedeutet, dass Arbeitsabläufe unabhängig voneinander hinzugefügt, geändert oder entfernt werden können. Eine Änderung an einem Qualitäts-Workflow erfordert keine erneute Validierung eines davon unabhängigen Wartungs-Workflows. Die Betriebsteams können die Apps anpassen, die für ihre Arbeit am relevantesten sind, ohne den gesamten Stack einem koordinierten Release-Zyklus unterziehen zu müssen.

Der architektonische Unterschied zeigt sich in den Kosten für Änderungen. Ältere MES verwenden MES proprietäre Programmiersprachen und komplexe zugrunde liegende Datenschemata, was Hersteller dazu zwingt, selbst bei geringfügigen Anpassungen auf externe Systemintegratoren angewiesen zu sein. Die meisten Teams bezeichnen dies als „Integrator-Gebühr“, und die meisten unterschätzen diese Kosten bei der Berechnung der Gesamtbetriebskosten. Jede Änderung am Arbeitsablauf ist mit tatsächlichen finanziellen Kosten und einem zeitlichen Aufwand verbunden. Aus diesem Grund neigen Hersteller dazu, Systemänderungen gänzlich zu vermeiden und stattdessen auf Workarounds zurückzugreifen.

Eine komponierbare Systemarchitektur garantiert nicht zwangsläufig die Akzeptanz. Schlecht umgesetzte komponierbare Plattformen scheitern dennoch, meist dann, wenn das Team die Plattform als unbeschriebenes Blatt betrachtet und darauf hofft, dass sich die Akzeptanz von selbst einstellt.

Eine modulare Architektur erleichtert jedoch die Einführung. Ob sie sich bewährt, hängt von dem Betriebsmodell ab, das das Team auf der Plattform aufbaut.

Wir stellen fest, dass Unternehmen, die bei der abteilungs- und standortübergreifenden Skalierung digitaler Abläufe am erfolgreichsten sind, in der Regel drei Entscheidungen hinsichtlich der Architektur und des Betriebsmodells getroffen haben, die in herkömmlichen Leitfäden meist übersehen werden. Jede dieser Entscheidungen geht direkt auf die oben beschriebenen Herausforderungen ein, und zusammen verdeutlichen sie, was wir meinen, wenn wir von einem System sprechen, das von Grund auf für die breite Akzeptanz konzipiert wurde.

Standardisierung bei gleichzeitiger lokaler Flexibilität

Was bei den meisten Rollouts scheitert, ist die Standardisierung der falschen Aspekte. Bei den Rollouts, deren Skalierung wir beobachtet haben, lautet die Lösung das, was wir oft als „globale Standardisierung mit lokaler Flexibilität“ bezeichnen: eine strenge Standardisierung bei Datenmodellen, Sicherheitsprotokollen, Prüfpfaden und der Governance auf Plattformebene, gepaart mit einer Konfigurierbarkeit auf Workflow-Ebene, die es jedem Standort ermöglicht, die Anwendungen an seine Produkte, Anlagen, Altsysteme und die Kultur der Mitarbeiter anzupassen.

Dies erfordert in der Regel ein föderales Governance-Modell. Ein Center of Excellence (COE) ist für die Aspekte zuständig, die werksübergreifend einheitlich sein müssen. Die Standortteams sind für die Aspekte zuständig, die unterschiedlich sein müssen. Durch diese Aufteilung kann das globale Team die Anforderungen von Audits und Sicherheit gewährleisten, ohne jeden Standort zu zwingen, denselben Workflow anzuwenden, der der betrieblichen Realität vor Ort widerspricht.

Regulierte Bürgerbeteiligung

Der Zielkonflikt zwischen „Agilität und Kontrolle“ tritt am deutlichsten zutage, wenn Governance auf Projektebene durchgesetzt wird. Jede Änderung am Arbeitsablauf muss eine Prüfung, Genehmigung, Validierung und Einführung durchlaufen, was bedeutet, dass das Tempo der Veränderungen durch die Geschwindigkeit begrenzt ist, mit der das zentrale Team Änderungsanfragen bearbeiten kann. Dieser Zielkonflikt verschwindet, wenn die Governance in die Plattform selbst integriert wird.

Die „Governed Citizen Development“ ist ein Betriebsmodell, bei dem die Fachleute, die am nächsten am Geschehen sind (Ingenieure und Betreiber), produktionsreife Fertigungsanwendungen direkt erstellen und anpassen, wobei Governance auf Plattformebene, Zugriffskontrollen, Genehmigungsworkflows und Prüfpfade die von der IT-Abteilung und der Compliance-Abteilung festgelegten Grenzen durchsetzen. Die Veränderung erfolgt im Tempo der Arbeit, da die Person, die die Arbeit ausführt, auch diejenige ist, die die Lösungen entwickelt und weiterentwickelt, und die Grenzen bleiben gewahrt, da sie als Plattformfunktionen durchgesetzt werden, anstatt projektweise ausgehandelt zu werden.

IT-Teams bringen gegenüber diesem Modell einen berechtigten Einwand vor, der Beachtung verdient. Citizen Development kann schnell zu Schatten-IT werden, wenn die Plattform keine echte Governance integriert hat. Generische Low-Code-Tools ohne Fertigungskontext, ohne Genehmigungsworkflows, ohne Prüfpfad und ohne klare Berechtigungsregeln führen tatsächlich zu diesem Ergebnis, und wir haben in der Vergangenheit erlebt, wie IT-Teams dadurch in Schwierigkeiten geraten sind.

Tulip direkt Tulip diese Bedenken Tulip . Die Governance ist in das Berechtigungsmodell, die Versionskontrolle, den Workflow zur Genehmigungsabwicklung und den Prüfpfad der Plattform integriert, was bedeutet, dass ein Entwickler, der einen Workflow erstellt, standardmäßig innerhalb eines genehmigten Rahmens arbeitet.

Dieses Modell eignet sich für die Einführung, da die Arbeitsabläufe von denjenigen gestaltet werden, die die Arbeit verstehen. Unserer Erfahrung nach kommen Einführungen oft ins Stocken, wenn sie von Personen konzipiert wurden, die zwei Schritte vom operativen Geschehen entfernt sind, während sich diejenigen erfolgreich skalieren lassen, bei denen das Feedback der Teammitglieder, die die Arbeit tatsächlich ausführen, direkt einfließt.

Ein System zur Kundenbindung, nicht nur ein System zur Datenerfassung

Die Datenschicht ist das dritte Element. In einem Interaktionssystem fließen Daten in beide Richtungen. Der Bediener generiert Daten im Rahmen des Arbeitsablaufs und erhält gleichzeitig Daten vom System zurück, um die nächste Entscheidung zu treffen. Die Unternehmenszentrale hat weiterhin Zugriff auf die Daten und den Prüfpfad auf der vorgelagerten Ebene, doch der Bediener, der Vorgesetzte und der Prozessingenieur erhalten die nötige Transparenz, um in Echtzeit Entscheidungen an der Produktionslinie zu treffen.

Die Daten werden passiv als Nebeneffekt der eigentlichen Arbeit erfasst – über Sensorwerte, Maschinensignale und Bestätigungen des Bedieners, die in den Arbeitsschritt integriert sind, den der Bediener ohnehin ausführt. Es muss kein separates Formular ausgefüllt werden, und es ist kein zusätzlicher Schritt zu beachten.

Bei den meisten Rollouts stehen die Architektur und das Betriebsmodell bereits zu Beginn fest. Was noch zu klären ist, betrifft taktische Aspekte, und auf diese fünf Bereiche konzentrieren wir uns zu Beginn aller von uns durchgeführten Implementierungen. Die daraus resultierenden Erkenntnisse wirken sich auf den weiteren Verlauf der Einführung aus.

Beginnen Sie mit einem Mitarbeiter, einem Arbeitsplatz und einer Aufgabe

Der zuverlässigste erste Einsatz bei jeder von uns durchgeführten Einführung ist eine einzelne, modular aufgebaute App, die für einen einzelnen Mitarbeiter an einem einzelnen Arbeitsplatz entwickelt wurde. Wählen Sie eine konkrete Aufgabe aus, die der Mitarbeiter in jeder Schicht ausführt – idealerweise eine, bei der es bisher zu Schwierigkeiten kam, die das Team bisher mit Papier umgangen hat. Entwickeln Sie einen Arbeitsablauf, der ihm hilft, diesen Schritt besser auszuführen, stellen Sie ihn bereit und lassen Sie den Mitarbeiter und den Vorgesetzten beurteilen, ob sich der Einsatz lohnt, bevor Sie auf weitere Apps, weitere Arbeitsplätze oder weitere Standorte ausweiten.

Der Bottom-up-Ansatz ist hilfreich, da über die Einführung jeweils für jeden einzelnen Betreiber entschieden wird. Sobald sich eine einzelne App an einem Standort etabliert hat, verfügt das Team über die nötige Glaubwürdigkeit, um die nächste App einzuführen. Sobald sich einige Apps in einer Abteilung etabliert haben, verfügt das Team über die erforderliche Grundlage, um die Einführung auf den gesamten Standort auszuweiten.

Wählen Sie einen Pilotstandort aus, der für die Einführung repräsentativ ist

Die einfachste Anlage ist in der Regel die schlechteste für die Pilotenausbildung. Die Schwierigkeiten, denen die Piloten später begegnen werden, sind genau jene, die der Pilot bewältigen lernen soll, und eine Ausbildung an der einfachsten Anlage führt zu Ergebnissen, die sich nicht auf andere Situationen übertragen lassen.

Ein sinnvoller Pilotstandort ist ein Standort, der die Herausforderungen aufzeigt, denen die Einführung später begegnen wird: ein Werk, in dem MES ein älteres MES im Einsatz ist, oder eine regulierte Produktionsumgebung mit eigenem Auditzyklus. Die Aufgabe des Pilotprojekts besteht darin, die Schwachstellen aufzudecken, bevor sie in Werk drei oder vier mit höheren Kosten zutage treten.

Übertragen Sie den Abteilungen die Verantwortung für ihre Arbeitsabläufe

Häufig werden Arbeitsabläufe zwischen den Abteilungen nicht miteinander abgestimmt. Die Logik der Qualitätsabteilung zur Bearbeitung von Nichtkonformitäten lässt sich nicht wirklich auf die Produktionsplanung übertragen, und der vorbeugende Wartungszyklus der Instandhaltungsabteilung folgt einer eigenen Logik hinsichtlich Arbeitsaufwand und Ersatzteilen, die die Qualitätsabteilung nicht benötigt. Der Versuch, die Arbeitsabläufe vor Ort auf eine einheitliche Formularstruktur zu standardisieren, passt in der Regel gut zu einer Abteilung, den anderen jedoch nur unzureichend.

Modulare Apps bieten hier eine Lösung. Jede Abteilung kann die von ihr genutzte App im Rahmen der zuvor beschriebenen plattformweiten Steuerung anpassen. Es ist kein Anpassungsantrag für jede Änderung am Arbeitsablauf erforderlich, da die Änderung innerhalb der Grenzen erfolgt, die die Plattform bereits vorgibt. Das Team erhält ein System, das genau den Anforderungen seiner Arbeit entspricht, und das zentrale Team verfügt weiterhin über den erforderlichen Prüfpfad und die erforderliche Sicherheitslage.

Betrachten Sie die Trainingszeit als einen architektonischen KPI

Wie lange ein neuer Bediener benötigt, um die Arbeit zu beherrschen, gibt Aufschluss darüber, wie gut das System auf die jeweilige Aufgabe abgestimmt ist. Wenn neue Bediener drei Wochen an einem Arbeitsplatz benötigen, bevor sie diesen ohne Aufsicht bedienen können, überlässt das System dem Gedächtnis des Bedieners Aufgaben, die die Benutzeroberfläche für ihn übernehmen könnte. Verkürzt wird diese Einarbeitungszeit durch geführte digitale Arbeitsabläufe, die den nächsten Schritt direkt auf dem Bildschirm des Bedieners anzeigen. Mehr Schulungen im Vorfeld reichen selten aus, um diese Lücke allein zu schließen.

Nehmen wir zum Beispiel die Implantatabteilung Dentsply. Mit einem Tulip System, das für über eine Milliarde Konfigurationskombinationen ausgelegt ist, konnte das Team die Einarbeitungszeit für neue Mitarbeiter im Vergleich zum bisherigen Arbeitsablauf um 75 Prozent verkürzen. Diese Verbesserung ist darauf zurückzuführen, dass das System nun einen Großteil der Aufgaben übernimmt, die zuvor im Gedächtnis der Mitarbeiter gespeichert waren. Die ganze Geschichte über die Einführung von Tulip Dentsply können Siehier nachlesen.

Planen Sie die Einführung an mehreren Standorten so, dass Abweichungen vom ersten Tag an berücksichtigt werden

Der häufigste Fehler bei der Einführung an mehreren Standorten ist der Klon des zweiten Standorts. Der erste Standort verläuft reibungslos, das Team nutzt die Bereitstellung am ersten Standort als Vorlage, und der zweite Standort übernimmt einen Arbeitsablauf, der nicht passt. Das Rollout-Team verbringt das nächste Jahr damit, den ersten Standort nachträglich anzupassen, um die Probleme zu beheben, die am zweiten Standort aufgetreten sind.

In der Praxis bedeutet die Planung für Variationen, den globalen Kern klein zu halten und die Konfigurationsebene auf Standortebene flexibel zu gestalten. Je weniger Elemente über alle Werke hinweg identisch sein müssen, desto einfacher ist es, jeden neuen Standort in Betrieb zu nehmen, und desto weniger muss das Rollout-Team nachrüsten, wenn am Standort zwei etwas zutage tritt, was am Standort eins implizit bereits umgesetzt wurde.

Stanley Black & Decker hierfür ein hervorragendes Beispiel. Das Unternehmen nutzt Tulip 2018, und das Stanley Production System (SPX) hat sich von einer Initiative an einem einzigen Standort zu einem globalen Rahmenwerk entwickelt, das mehr als 50 Werke und über 1.000 Anwendungen miteinander verbindet.

Im Laufe der Jahre, in denen das Stanley-Team seine Tulip ausbaute und weiterentwickelte, konnte es eine Bestandsreduzierung von über 2 Milliarden US-Dollar, eine Steigerung des Service-Levels um 15 Punkte sowie nachhaltige Verbesserungen bei Qualität und Sicherheit verzeichnen. Der Schlüssel zur Förderung der Akzeptanz an allen Standorten lag darin, den globalen Kern klein zu halten und gleichzeitig den lokalen Standorten Flexibilität zu gewähren, um die vielfältigen Umgebungen, Produkte und Prozesse zu unterstützen, aus denen sich das Portfolio von Stanley zusammensetzt.

Erfolgreiche MES weisen in der Regel eine gemeinsame architektonische Struktur auf: modular aufgebaute Anwendungen, die das Team ohne IT-Ticket ändern kann, einen kleinen globalen Kern, den jeder Standort individuell konfigurieren kann, ohne die Vorlage abzuzweigen, sowie eine Datenschicht, die den Mitarbeitern vor Ort dieselbe Echtzeit-Transparenz bietet, die auch den Vorgesetzten zur Verfügung steht.

Die meisten Probleme bei der Einführung, die im Zuge der Skalierung einer Lösung auftreten, lassen sich auf architektonische Entscheidungen zurückführen, die bereits zu Beginn getroffen wurden. Eine sinnvollere Frage, die Sie in das nächste Gespräch mit dem Anbieter einbringen sollten, lautet: Was wird die Architektur sechs Monate nach der Inbetriebnahme vereinfachen, und was wird sie erschweren?

Wenn Sie gerade dabei sind, zu prüfen, wie Sie ein MES bewerten oder einführen können, MES Bedienern, Abteilungen und Standorten genutzt werden soll,wenden Sie sich bitte an ein Mitglied des Tulip . Wir arbeiten mit Herstellern mit mehreren Standorten genau bei dieser Art von Entscheidungen zusammen.