MES (Manufactoring Execution System)

Wie auch in den vorangegangenen Phasen hat sich auch hier die Zusammenarbeit von Unternehmensmitgliedern mit IT-Verantwortlichen, Prozessberatern, IT-Dienstleistern und Vertretern der Hochschulen, die die Einführung begleiten bzw. durchführen sollen, als positiv erwiesen. Die Vielzahl an Personen stellte sich insbesondere bei der Terminfindung aber auch als herausfordernd und zeitaufwändig heraus.

Ein wichtiges und teilweise unterschätztes Abstimmungsthema ganz zu Beginn der Moonrise MES Einzelmaßnahme war das Finden einer gemeinsamen Sprache und die Klärung und Abstimmung von Begrifflichkeiten und Definitionen (z.B. die unterschiedliche Verwendung von Prozessschritt vs. Arbeitsgang vs. Auftragsposition). Wird dieser Punkt vernachlässigt, kann es im weiteren Verlauf zu erheblichen Verständnisproblemen und Missverständnissen kommen.

MES (auf Mobilen Endgeräten)

Anforderungen aufnehmen

Zunächst müssen die Anforderungen an das neue System grob aufgenommen werden (gemeinsam mit verschiedenen Nutzergruppen wie z.B. Anwender, Abteilungsleiter, IT). Anforderungen können z.B. unterschiedliche Auftragsarten/-positionen (Fertigung, Instandhaltung, Gemeinkosten etc.), eingeschränkte Selektionsmöglichkeiten (nur Aufträge bestimmter Maschinengruppen sollen angezeigt werden etc.), Kommentarfunktion o.ä. sein. Wichtig zu wissen ist, dass Unternehmen selten in der Lage sind ihre Anforderungen zu Projektbeginn systematisch zu artikulieren. Ein iteratives Vorgehen mit Tests von Prototypen oder ersten Anpassungen der Standardsoftware ist unabdingbar. Es sollte auch nicht unterschätzt werden, wie schwer sich viele Personen damit tun, Dinge, die sie für einen Anwendungsfall gesehen haben, auf ihre eigene Situation gedanklich zu übertragen. Daher sind Demonstratoren mit unternehmensspezifischen Daten essenziell. Ein erster Anhaltspunkt für eigene Anforderungen kann auch die Marktübersicht sein (siehe unten). Welche der Module, die MES Hersteller anbieten brauche ich überhaupt? Will ich nur BDE (Betriebsdatenerfassung), geht es primär um das digitale Liefern der nötigen Informationen zur Maschine, soll auch Lagerhaltung und Materialwirtschaft mit angebunden werden, und so weiter.

Hilfreich bei der Aufnahme der Anforderungen waren allgemein verfügbare Online-Checklisten sowie gezielte Nachfragen durch das erfahrene Projektteam. Die gesammelten Punkte mussten dann sinnvoll priorisiert werden, um für die Entscheidungsfindung zur Verfügung zu stehen. Neben der Sammlung von Anforderungen in Listenform wurden auch User Stories als Dokumentationsform verwendet.

ERP-Umfang prüfen

Wenn bereits ein ERP-System im Unternehmen vorhanden ist, sollte zunächst durch die Verantwortlichen aus dem Produktionsbereich und aus der internen IT, ggf. auch in Zusammenarbeit mit dem ERP-Anbieter, geprüft werden, ob ein Produktionsmodul verfügbar und ausreichend sowie sinnvoll nutzbar ist (ist das Modul bereits enthalten oder muss es zusätzlich installiert / freigeschaltet werden). Auch die zusätzlichen Kosten sind dabei zu prüfen. Fällt die Analyse positiv aus, kann mit der Erweiterung des ERP begonnen werden, wobei ggf. Anpassungen (Stammdaten, Customizing, Programmierungen etc.) vorgenommen werden müssen. Auch die Nutzung bereits vorhandener Funktionen muss geprüft werden. In vielen Fällen wurden die ERP-Systeme bei den Unternehmen nicht vollumfänglich genutzt, oder sogar nur als „bessere Schreibmaschine“ für Rechnungsstellung verwendet. Auch die Frage, was geeignete Übergabepunkte zwischen ERP und MES sein können, muss beantwortet werden. Wird mit dem ERP System schon eine Zusammenfassung oder Aufsplittung der Auftragspositionen von Kundenaufträgen in sinnvolle Fertigungsaufträge gemacht, oder soll dies im MES passieren? Wird schon eine Reihenfolgeplanung und Priorisierung vorgenommen, oder muss das MES das tun? Welche Stammdaten sind im ERP vorhanden, die das MES benötigt und über welche Schnittstellen können diese ausgelesen werden? All diese Fragen müssen geklärt werden. Ohne umfangreiche Nutzung von ERP-Systemen sind nachgelagerte MES-Aktivitäten kaum sinnvoll möglich.

Bei der Analyse der bereits beim Anwendungspartner bereits vorhandenen (ERP-)Systeme, ob, wie und in welchem Umfang dort schon Produktionslösungen integriert sind, musste häufig mit externen IT-Dienstleistern (externe Systembetreuer, ERP-Anbieter) kommuniziert werden. Dies gestaltete sich oft nicht einfach, da die Bereitschaft zur un-entgeltlichen Zusammenarbeit meist fehlte (Informationen nur gegen Beauftragung). Aus verschiedenen Gründen (z.B. zu wenig Flexibilität, zu wenig Zusatzinformationen, zu hohe Kosten eines Zusatzmoduls bereits bekannt) wurden bei den meisten Anwendungspartnern keine Produk-tionslösungen/-module der bestehenden Systeme erweitert. Lediglich bei einem Unternehmen wurde das Produktionsmodul im Rahmen einer ohnehin stattfindenden ERP-Einführung gleich mit integriert (geringer Funktionsumfang, aber ausreichend). Bei einem weiteren Anwendungs-partner war HiCuMES bereits in der Moonrise-Projektdefinition festgelegt, so dass dort der Auswahlprozess entfiel

MES-Marktüberblick

Ist das ERP keine Option, sollte man sich einen ersten MES-Marktüberblick verschaffen, z.B. über Anbieterübersichten im Internet. Für den Abgleich der Anforderungen mit den angebotenen Systemen können weitere Kriterien wie z.B. Eignung für kleine Unternehmen oder spezielle Branchen, Cloud-Lösung/lokale Installation etc. berücksichtigt werden.

Zu klären sind auch die Details der verschiedenen Kostenmodelle, wie z.B. einmalige Lizenzkosten oder laufende monatliche Gebühren oder Anzahl der Lizenzen/User. Diese Details sind in der Regel nicht auf den Homepages ersichtlich und müssen individuell bei den Anbietern erfragt werden. Auch die Einführungskosten (System + Beratungsleistungen), interne Kosten/Aufwände (Anpassung der Schnittstellen etc.) sowie Folgekosten (Support, Wartung, Anpassungen etc.) dürfen nicht vernachlässigt werden und sind mit zu berücksichtigen. Insb. bei Cloud-Lösungen sollten erste Abschätzungen der Anbieter zur Integration zu bestehenden eigenen Systemen der Kunden nicht für bare Münze genommen werden. Erfahrungsgemäß wird dieser Teil deutlich komplexer als zunächst gedacht. Auch bei der Lizensierung ist genau zu hinterfragen, wer alles als Benutzer zählt.

Das Verschaffen eines ersten Marktüberblicks stellte sich als gar nicht so einfach und schnell erkenntnisbringend heraus. Hilfreich waren neben den Online-Vergleichsübersichten eher die Erfahrungen der Dienstleister mit dem einen oder anderen System und der Austausch darüber. Viele Anbieter konnten aufgrund der eingeschränkten Eignung für bestimmte Branchen oder Unternehmensgrößen bereits im Vorfeld ausgeschlossen werden. Die Kosten als weiterer wichtiger Punkt mussten individuell erfragt werden und waren oft sehr ambitioniert, was das Feld weiter einschränkte. Wurden dann Favoriten gefunden, wurde in der Regel in einem ersten Gespräch zwischen Prozessberater und Anbieter die Eignung nochmals genauer abgeklärt und ggf. ein Termin für eine Systemvorführung vereinbart.

Systemdemos

Sind dann erste Anbieter-Favoriten gefunden, sollten Systemdemos angefordert werden, um sowohl die Abläufe und die Oberfläche direkt zu sehen als auch spezielle Fragen stellen zu können. Bei diesen Veranstaltungen (vor Ort, remote) ist es sinnvoll, dass neben den Verantwortlichen aus dem Produktionsbereich und der Geschäftsleitung auch IT-Verantwortliche teilnehmen, um möglichst viele Blickwinkel abbilden zu können.

Diese Systemdemos waren für das Verständnis sehr hilfreich (‚nicht nur darüber reden, sondern etwas Konkretes sehen‘). Zum einen wurde deutlich, wie einfach oder kompliziert die Abläufe gestaltet sind oder auch ob das Design übersichtlich und ansprechend ist. Als Hürde wurde die Verwendung von allgemeinen Demoprozessen mit Beispieldaten identifiziert. Die Übertragbarkeit auf das eigene Unternehmen und die individuellen Prozesse war für einige Teilnehmer in der Kürze der Demos nicht einfach. Idealerweise zeigt der Anbieter nicht nur die eigene Demofirma, sondern investiert ein paar Stunden in Customizing der Prozesse und Daten, so dass sich der Kunde besser wiedererkennt. Zur Not sollte das bezahlt werden, statt hier Geld sparen zu wollen.

Abgleich Anforderungen und Systemwahl

Im letzten Schritt sind die Anforderungen mit den angebotenen Systemen abzugleichen und ggf. durch weitere Rückfragen beim Anbieter genauer abzustimmen. Der Entscheidungsprozess ist dann unternehmensindividuell (welche Kriterien werden wie relevant eingeschätzt, Budget, individuelle Präferenzen Anbieter/Lösung/optisches Design etc.). Wichtig ist auch zu überlegen, was notwendiges Customizing der Standardsoftware für zukünftige Updates bedeutet. Häufig macht kundenspezifischer Code Updates deutlich komplexer oder kann sie sogar komplett verhindern. Damit tut sich ein Unternehmen langfristig keinen Gefallen. Umgekehrt ist es auch nicht sinnvoll eigene, gute Arbeitsweisen aufzugeben, nur weil das System sie so nicht unterstützt. Einen guten Kompromiss zwischen diesen beiden Extremen zu finden ist wesentlich.

Die ursprünglichen Anforderungen mussten vom Projektteam mit den angebotenen Lösungen abgeglichen werden, ggf. Rückfragen gestellt und Details überdacht werden. Einige Systeme wären inhaltlich sehr attraktiv und passend gewesen, aber leider für die kleineren Anwendungspartner finanziell nicht leistbar.

Bereits zu diesem Zeitpunkt zeigten sich einige Vorteile von HiCuMES, wie z.B. die Eignung für KMU, Branchenunabhängigkeit, Flexibilität bei der Anpassung an die Unternehmensprozesse, sehr gute Anbindungsmöglichkeit verschiedenster vor-/nachgelagerter Systeme inkl. CAQ, Waagen etc., keine Lizenzkosten. Auch wurden einfache, anwendungspartnerspezifische Prozesse und Daten gezeigt, was das Verständnis bei den Unternehmensvertretern förderte.

Die endgültige Entscheidung, welches System eingeführt werden soll, lag dann bei der Geschäftsleitung der Anwendungspartner. Viele Anwendungspartner entschieden sich aufgrund der oben genannten Vorteile für eine Einführung von HiCuMES.

Planung der Einführung

Ist die Entscheidung für einen Anbieter dann gefallen, muss die Einführung geplant werden (Zeitraum, Meilensteine, Projektteam etc.). Um dabei die Komplexität gering zu halten, muss zu Beginn festgelegt werden, ob die Implementierung für das gesamte Unternehmen, ggf. für einen von mehreren Standorten oder vielleicht auch nur für einen von mehreren Bereichen erfolgen soll und ob dann weitere Bereiche folgen sollen. Auswahlkriterien sind z.B. einfache Prozessabläufe, technikaffine und Neuerungen gegenüber aufgeschlossene Mitarbeiter.

Die zeitliche Grob-Planung im Projekt Moonrise wurde mithilfe von OpenProject teilprojektindividuell und ggf. über mehrere Einzelmaßnahmen durchgeführt. Für die Planung der einzelmaßnahmenindividuellen Umsetzungsphase wurde dann die Scrum-Methodik mit regelmäßigen Scrum-Meetings und die Nutzung von Kanbanboards (nextcloud) genutzt. Nach längeren Tests und Diskussionen wurde sich meist für die bestehende nextcloud-Lösung und die dortigen Boards entschieden (u.a. kostenfrei, bereits im Projekt vorhanden, Betrieb durch die Hochschule, Screenshots können hinzugefügt bzw. Dokumente verlinkt werden, weitere Nutzer konnten einfach & mit eingeschränkten Rechten hinzugefügt werden).

Spätestens hier erfolgte auch die Abstimmung, mit welchem Bereich (im Falle mehrerer Standorte, Abteilungen etc.) gestartet werden soll. Empfehlenswert ist ein Bereich mit einfachen Prozessen und für Neuerungen aufgeschlossene Mitarbeiter. Dabei wurden ab jetzt verstärkt die Verantwortlichen aus der Produktion (Abteilungsleiterebene) eingebunden, da sie in der Regel die Wissensträger der genauen Prozesse/Abläufe etc. sind.

Verantwortlichkeiten

Sehr unternehmensindividuell ist die Frage zu handhaben, wann welche Mitarbeiter(gruppen) wie am besten einzubeziehen (Geschäftsleitung, Abteilungsleiter, Key User, End User usw.) sind. Einflussfaktoren sind z.B. die Unternehmensgröße, der Führungsstil oder auch die Technikaffinität und Eigeninitiative der Mitarbeiter.

Als positiv herausgestellt hat sich die generelle Einbindung der Produktionsleitung (Wissen, Entscheidungsfähigkeit), das partielle Einbinden der Geschäftsleitung (für wichtige Entscheidungen) sowie das schrittweise Einbinden weiterer Mitarbeiter in den jeweiligen Abteilungen (erst die Abteilungsleiter, die dann wiederum ihr Wissen an die Enduser weitergegeben haben) – vorausgesetzt es gibt so viele verschiedene Hierarchiestufen und geeignete Mitarbeiter (technikaffin, prozesskompetent, zeitlich machbar). Hilfreich ist es, sich in den betroffenen Abteilungen „Verbündete“ zu suchen, die aufgeschlossen sind und Probleme offen ansprechen. Aber auch kritische Stimmen sollten nicht ausgeschlossen, sondern frühzeitig gehört werden, so dass auch diese Mitarbeitenden sich „mitgenommen“ und ernstgenommen fühlen. Es hilft nicht lange Zeit nur mit den ohnehin Veränderungen aufgeschlossenen Personen zu arbeiten, um dann gegen Ende sich von Gegenstimmen überraschen zu lassen.

IT-Basischeck

Im Rahmen eines IT-Basischecks sollte die grundlegende Systeminfrastruktur im Unternehmen bereits durch die IT-Dienstleister und Unternehmens-IT (intern/extern) erfasst worden sein. Generell wird eine 3 geteilte Systemlandschaft (Entwicklungs-, Test- und Produktivsystem) empfohlen. Es ist zu prüfen, ob die Systeme bereits vorhanden sind und regelmäßig aktualisiert werden.

Für die Einführung des MES ist hier nochmals genauer zu klären, ob die Serverkapazitäten/Performance etc. ausreichen und die Aspekte der Cybersicherheit berücksichtigt und getestet sind (Firewall etc.). Auch die WLAN-Verfügbarkeit innerhalb der Produktionshallen muss getestet und ggf. erweitert bzw. verstärkt werden. Darüber hinaus sollte bereits hier an die notwendige Hardware (Endgeräte, Scanner etc.) gedacht und erste Überlegungen zu Anzahl, Anforderungen und Budget angestellt werden.

Die IT-Dienstleister waren im Vorfeld zusammen mit der internen IT bzw. den externen Systembetreuern bereits für einen Basis-Check der Infrastruktur zuständig, was jetzt aber mit der konkreten Zielstellung ‚Einführung eines MES‘ nochmal genauer überprüft werden musste. Bei den meisten Anwendungspartnern fanden sich keine bzw. keine aktuellen Testsysteme sowie optimierungsfähige Server- und Security-Themen, die vorab durch die IT-Dienstleister in Zusammenarbeit mit der Unternehmens-IT erledigt werden mussten. Auch die WLAN-Verfügbarkeit in der Produktion wurde getestet und bei den meisten Partnern optimiert. Die Beschaffung der Endgeräte (Anzahl, Art, Geeignetheit für besondere Umgebungsbedingungen/Bedienung, Zubehör etc.) wurde analysiert und in die Wege geleitet. In vielen Fällen können mobile Endgeräte für den Consumer-Bereich, die um Schutzhüllen für raue Umgebungen ergänzt werden eingesetzt werden und man spart damit Kosten gegenüber Speziallösungen für den industriellen Einsatz. Das ist aber nicht immer der Fall und sollte je nach Umgebungsbedingungen und Anforderungen an die Arbeitssicherheit geprüft werden. Größere Bildschirme (mind. 12 Zoll, besser 14 Zoll) haben sich im Projekt als ergonomischer herausgestellt im Gegensatz zu Standardgeräten mit 10 Zoll oder weniger. Der Mehrpreis rechnet sich meist.

Installation/Einrichtung

Wenn diese Punkte geklärt sind, kann die ‚Rohversion‘ des neuen Systems für die weitere Einführung und Anpassung installiert werden.

In Moonrise erfolgte die Installation des neuen Systems beim Anwendungspartner durch den verantwortlichen IT-Dienstleister in Zusammenarbeit mit der dortigen IT.

Prozessaufnahme detailliert

Die ursprünglich grob aufgenommenen Produktionsprozesse müssen spätestens jetzt nochmal detaillierter erfasst werden. Neben dem Standardablauf sind auch Abweichungen und Spezialfälle zu berücksichtigen.

Zusammen mit dem gesamten Projektteam, aber federführend durch die Prozessberater, wurden die Produktionsprozesse nochmal detaillierter aufgenommen. Speziell für HiCuMES empfiehlt sich dabei die Verwendung von BPMN, z.B. mit dem Camunda Modeler, um Mehraufwand bzw. eine doppelte Erfassung zu vermeiden. Generell sind zwar auch Visio, Miro oder ähnliche Systeme möglich, jedoch können diese Übersichten nicht direkt weiterverarbeitet werden. Eine Schulung der beteiligten Mitarbeiter zu Beginn kann die Einstiegshürde senken und später Zeit und Arbeit sparen.

Als Anhaltspunkt und Grundlage für die folgenden Schritte sollte ein Papierauftrag eines gängigen und oft verwendeten Produktes verwendet werden, der inhaltlich einen Großteil der Prozesse/Abläufe abdeckt, aber kein Sonderfall ist.

Die aufgenommenen Prozesse müssen mit den Abläufen im zukünftigen System abgeglichen werden. Dabei ist zu klären, was zusätzlich zu den Standardabläufen im MES abgebildet wird bzw. was außerhalb des MES über Workarounds oder Prozessänderungen gelöst werden muss. In diesem Zusammenhang können auch die jetzigen Abläufe durch das Projektteam kritisch hinterfragt werden (‚Blick von außen‘). Sollten sich hier offensichtliche Prozessoptimierungsfälle ergeben, sollten diese vorab geklärt werden.

Bei der Erfassung von Standardabläufen und Abweichungen davon bzw. Sonderprozessen musste explizit immer wieder durch die Berater nachgefragt werden. Oftmals waren den Verantwortlichen die Abweichungen und Ausnahmen gar nicht bewusst. Angeboten hat sich hierbei auch ein erneuter Gang durch die Produktion und das genaue Vorort-Analysieren der Prozesse (welcher Mitarbeiter macht an welcher Maschine mit welchem Material/Produkt basierend auf welcher Information was). Dokumentiert wurden diese Informationen in der Regel in Protokollen, bevor sie dann strukturiert mit Camunda aufgenommen wurden. Auch ein grobes Modellieren in Camunda direkt während der Besprechungen und ein technisches Nachschärfen später in Einzelarbeit haben sich bewährt.

Parallel musste bereits hier die Umsetzbarkeit überlegt werden. Zu den Spezialfällen gehören z.B. die Abwicklung von Teil- oder Sammelaufträgen (soll es überhaupt möglich sein und umgesetzt werden, gibt es Einschränkungen etc.) oder auch die Berücksichtigung ‚besonderer Buchungszeiten‘ wie Wartungsarbeiten, Personalversammlung etc.

Besonders der Blick durch die ‚externe Brille‘ sieht hier oft zusätzliche Details. Bei manchen Punkten konnte den Unternehmen somit ein Hinweis oder Lösungsvorschlag für Prozessänderungen/-optimierungen gegeben werden, auch wenn diese nicht Fokus von Moonrise standen.

Schnittstellen

Da ein MES keine Insellösung sein sollte, müssen auch die Schnittstellen zu vor- und nachgelagerten Systemen durch die IT-Dienstleister und Unternehmens-IT analysiert und konfiguriert werden. Auftragsdaten oder Stammdaten über Maschinen kommen z.B. aus einem ERP-System, weitere Schnittstellen betreffen Waagen, CAQ-Systeme und die Rückmeldung der Daten an das ERP.

Insbesondere auch die Schnittstellenanalyse und Klärung der Anbindung angegliederter Systeme (ERP, CAQ, Waagen o.ä.) sollte sehr sorgfältig durchgeführt werden. Stolpersteine fanden sich u.a. bei fehlenden oder schlechten Schnittstellendokumentationen und damit verbunden langwierigen Analysen, unklaren Verantwortlichkeiten und fehlendem Wissen (wer ist intern/extern bei Detailfragen auskunftsfähig und verantwortlich) sowie unkooperativen Partnern/Herstellern.

Daten

Für jeden Prozessschritt müssen die erforderlichen Daten (Stammdaten, Bewegungsdaten) bestimmt werden, woher sie kommen und ob sie vollständig und in ausreichender Qualität vorhanden sind. Dabei muss für jeden Prozessschritt festgelegt werden, was ‚hineingeht‘ und was ‚herauskommt‘.

Gegebenenfalls ist es bereits zu diesem Zeitpunkt sinnvoll, die Daten im Altsystem zu prüfen und ggf. erst einmal zu bereinigen (Dubletten, nicht mehr benötigte Daten, fehlende Einträge etc.). In manchen Fällen kann es auch sinnvoll sein, benötigte Daten vorab zusätzlich im ERP zu erfassen, um sie später im MES weiterverarbeiten zu können. Abgestimmt werden muss das zwischen interner IT und den Prozessverantwortlichen des Anwendungspartners.

Für jeden erfassten Prozessschritt wurden die zugehörigen Daten (Stammdaten, Bewegungsdaten) analysiert und in Camunda zugeordnet. Besonders bei den sehr branchenspezifischen ERP-Systemen war die Analyse zur Herkunft der Daten sehr aufwendig (unklare Strukturen/Abläufe, fehlende Dokumentation, schlechte Kooperation der Hersteller usw.). Allein durch diese Vorarbeit aber konnte für die Anwendungspartner bereits mehr Klarheit und dadurch ein Mehrwert geschaffen werden (z.B. durch Dokumentation der Datenbanken für ggf. späteren ERP-Wechsel).

In diesem Zusammenhang musste auch geprüft werden, ob die Daten bereits vollständig und in ausreichender Qualität vorhanden sind. Dieser Punkt wurde teilweise unterschätzt und nahm einige Zeit in Anspruch. Vor allem ging es dabei um die Bereinigung des Altsystems (Identifizieren nicht mehr verwendeter Einträge, wie z.B. stillgelegte Maschinen etc.; Check von Mengeneinheiten etc.).

Mapping

Im Rahmen des Mappings erfolgt dann die Zuordnung der Daten aus dem alten System zu den Daten im neuen System und wieder zurück.

In HiCuMES wird dazu der Schema-Mapper verwendet. Dabei waren im Vorfeld unternehmensindividuell Erweiterungen und Anpassungen notwendig.

Anpassungen System vs. Ablauf

Da in den seltensten Fällen ein MES-Neusystem die bestehenden Prozesse exakt abbildet, ist zu überlegen, ob und wie das neue System angepasst werden kann bzw. ob die Prozesse an das neue System angepasst werden müssen. Die Anpassungen können von einfachen Systemeinstellungen (Customizing) bis hin zu aufwändigen Zusatzprogrammierungen reichen (Performance und Updatefähigkeit beachten).

Auch sollte geklärt werden, ob und welche Fehler-/ Warnmeldungen auftauchen sollen und ob es prinzipielle Einschränkungen (generell nicht möglich, nur durch den Vorgesetzten o.ä.) geben soll (z.B. nachträgliche Änderungen der Menge usw.)?

Durch den Abgleich der bisherigen Abläufe mit den Abläufen im neu einzuführenden System wurde es notwendig, die ‚realen‘ Prozessabläufe anzupassen bzw. Systemanpassungen (kleinere Erweiterungen um Datenfelder bis hin zu größeren Erweiterungen durch Programmierungen) vorzunehmen. Die Entscheidung darüber muss das Projektteam gemeinsam fällen, es sollte aber das Verhältnis von Kosten und Nutzen nicht aus den Augen verlieren.

Dokumente

Eines der Ziele der Einführung eines MES kann es sein, weniger oder keine Papierdokumente mehr in der Fertigung zu verwenden. Daher kann es für bestimmte Prozessschritte notwendig sein, Anleitungen, Zeichnungen oder Bilder/Videos digital anzuzeigen. In diesem Fall müssen sowohl die Darstellungsmöglichkeiten als auch die Voraussetzungen (liegen diese bereits digital, im richtigen Format, mit der richtigen Benennung etc. vor, so dass sie automatisch den Produkten oder Maschinen zugeordnet werden können) geprüft und in das neue System integriert werden. Falls dies nicht möglich oder gewünscht ist, muss geprüft werden, wann (aus welchem System, für welchen Prozessschritt) und wo (physisch) entsprechende Ausdrucke (Begleitscheine, Etiketten, Prüfberichte etc.) mit welchen Inhalten erstellt werden.

Bei der Aufnahme des Status Quo und dem erneuten Rundgang durch die Produktion wurden die Papierdokumente zwar bereits aufgenommen und grob, aber inhaltlich noch nicht bis ins kleinste Detail, analysiert. Hier musste nun genau überprüft werden, welche Informationen zukünftig in welcher Form benötigt werden. Im Falle von speziellen Anweisungen, Bilder/Zeichnungen, Videos o.ä. gibt es in HiCuMES die Möglichkeit, diese direkt beim jeweiligen Prozessschritt anzeigen zu lassen. Dazu mussten die Anweisungen etc. digital und im richtigen Format (z.B. PDF) gesammelt und über Ordnerstruktur und Dateinamen dem richtigen Produkt im richtigen Auftrag zugeordnet werden.

Die Prozesse werden zwar zukünftig digital gebucht und lösen damit z.B. die händische Erfassung auf Papier und den anschließenden Übertrag ins System ab, die ursprünglichen Auftragszettel als ‚Begleitzettel‘ entfallen jedoch erstmal nicht, sondern es erfolgt eine Art Parallelbetrieb. Ein großer Unterschied ist, dass die Buchungen in Echtzeit erfolgen und damit sofort nachzuverfolgen sind, durch die ‚Begleitzettel‘ bleiben die Produkte aber bei ihrem Weg durch die Fertigung einfach identifizierbar.

UI

Bei der Darstellung kann je nach System die Möglichkeit bestehen, die Benutzeroberfläche mehr oder weniger anzupassen bzw. zu individualisieren (Felder ein-/ausblenden, Farbgestaltung etc.). Zu beachten ist auch, ob es systemseitige Einschränkungen gibt (nur bestimmte Browser, Größenanforderungen mobiler Endgeräte etc.).

Die Benutzeroberfläche in HiCuMES kann anwendungspartnerindividuell angepasst werde (anzuzeigende Felder, Vorbelegungen, Muss-/Kann-Eingaben etc.), über die Filterfunktionen können weitere Individualisierungen durchgeführt werden.

Useraccounts

Für sämtliche Nutzer, die auf das MES zugreifen sollen, müssen systemseitig Useraccounts angelegt werden. Dabei kann es je nach Unternehmen auch spezielle Berechtigungen/Einschränkungen notwendig sein (z.B. darf Mitarbeiter nur Aufträge seiner Maschine(ngruppe) sehen, der Abteilungsleiter aber alle). Überlegt werden muss auch, wie die An-/Abmeldung erfolgen soll (bestehende Personalzeiterfassung (PZE) o.ä.; Single Sign-On (SSO) zu bestehenden Systeme), automatisches Ausloggen bei Inaktivität usw.

In Moonrise wurden für alle Nutzer einzelne Useraccounts angelegt, bzw. aus dem bestehenden Active Directory Benutzername und Passwort wiederverwendet. Bei manchen Partnern wurden Berechtigungen eher pragmatisch gehandhabt. Zum Teil wurden Benutzerkomfort und einfache Handhabung einer strikten Überprüfung der Identität des Benutzers vorgezogen, was kein Problem ist, wenn entsprechende Kontrollen schon am Eingang an der Maschinenhalle stattfinden.

Auswertungen

Um die Daten nicht nur zu erfassen, sondern auch auswerten zu können, muss es die Möglichkeit geben, Auswertungen zu erstellen. Überprüft werden muss, was standardmäßig bereits vorhanden oder über einfach Customizing-Einstellungen konfigurierbar bzw. was eine Spezialanforderungen ist, die zusätzlich programmiert werden muss.

Spezielle Anforderungen an Auswertungen müssen nicht zwingend im MES oder ERP System direkt integriert sein, sondern können auch über spezialisierte Datenanalyse-Werkzeuge nachgerüstet werden. Das war  ein Thema der Einzelmaßnahme ‚Datenanalyse‘. 

Endgeräte

Für die Endgeräte/Scanner etc. ist zu klären, ob und falls ja welche speziellen Anforderungen (Größe, Leistung, Produktionsumgebung, Hülle, Handschuhe, Befestigung/Wagen etc.) notwendig sind. Insbesondere bei erhöhten Anforderungen an die Robustheit, z.B. Staub, können spezielle Industriegeräte eingesetzt werden. In vielen Fällen sind aber auch Consumergeräte mit speziellen Schutzhüllen ausreichend. Diese sind deutlich günstiger und gleichzeitig von der Rechenleistung her meist besser als die Industriegeräte. Der Einsatz von Handscannern kann einige Prozesse deutlich beschleunigen (Codes schon vorhanden oder nicht, ausgewählte Bereiche/überall etc.). Wenn die Hände nicht frei sind, können am Handschuh montierte Geräte eventuell Abhilfe schaffen. Auch Spracherkennung kann eine Lösung darstellen, wenn die Umgebungsgeräusche das zulassen, oder spezielle Headsets genutzt werden, die Hintergrundgeräusche schon ausfiltern.

Die IT-Partner recherchierten zusammen mit den Hochschulen geeignete und finanziell leistbare Endgeräte. Auf Testgeräten konnten dann direkt durch die Anwendungspartner Tests sowohl bezüglich Inhalt, Performance als auch UI durchgeführt werden.

Tests & Schulungen

Sind alle Details geklärt und die ‚Rohversion‘ des Systems grob angepasst (getestet durch die Dienstleister), können erste Anwendertests, vorzugsweise durch die Prozessverantwortlichen mit Unterstützung der Dienstleister, beginnen. Für den Einstieg eignen sich einfache Testprozesse/-aufträge ggf. auch mit Beispieldaten/manuellen Datenextrakten, um sich mit dem System vertraut zu machen. Im Idealfall sollten dann aber zeitnah ‚echte Aufträge‘ (insbesondere auch Sonderfälle) parallel zum analogen Prozess in digitaler Form durchgespielt werden. Auch die Anbindung der vor- und nachgelagerten Systeme muss zeitnah erfolgen, um reale Daten in die Tests einbeziehen zu können. Werden Probleme oder Fehler identifiziert, empfiehlt sich der Einsatz von Kanban-Boards zur Dokumentation und Behebung durch die Dienstleister. So kann das System iterativ angepasst, verbessert und verfeinert werden. Laufen die Prozesse dann stabil, können die Tests auf weitere Nutzer (z.B. Abteilungsleiter, angeleitet durch die Mitarbeiter,

die bereits Erfahrung damit haben) ausgeweitet werden. Hierbei sollten auf jeden Fall Echtdaten verwendet (Akzeptanzsteigerung) und ‚Massentests‘ (z.B. nicht nur 1 User an 1 Gerät mit 1 Auftrag mit 1 Produkt) durchgeführt werden. Spätestens hier sollte auch die Performance des Systems überprüft werden. Dies kann auch helfen etwaige Performance-Engpässe frühzeitig zu entdecken.

Im Rahmen von Schulungen sollen die Anwender mit dem System vertraut gemacht werden. Die direkt an der Umsetzung beteiligten Personen werden wie bereits beschrieben im Rahmen der Einführung/Tests etc. durch die Dienstleister und eigene Versuche ‚geschult‘. Je nach Unternehmensstruktur schulen diese Mitarbeiter dann die nächste Gruppe (z.B. Abteilungsleiter), die dann wiederum ihr Wissen an die restlichen (End-)User (Mitarbeitende ‚an der Maschine‘) weitergibt. Unterstützend können Schulungsunterlagen (Anleitungen, Screenshots, Klickanleitungen etc.) zur Verfügung gestellt werden.

Die Abteilungsleiter/Meister wurden unterstützt durch die Berater und Hochschulen im Rahmen von begleiteten Tests mit ausgewählten Testdaten und einfachen Prozessen an das System herangeführt. Über weitere, dann immer eigenständigere Tests und ggf. mit Hilfe von ‚Klickanleitungen‘ wurden die Tests auf Sonderfälle und schließlich Massentests mit Echtdaten ausgeweitet. Wichtig für die Akzeptanz des neuen Systems dabei war der richtige Zeitpunkt: das Testsystem musste möglichst fehlerfrei, stabil und performant funktionieren, aber noch nicht zu endgültig ohne weitere Änderungsmöglichkeit sein. Die Abteilungsleiter drängten darauf, etwas zu sehen und selbst auszuprobieren. Außerdem wurden möglichst realitätsnahe Testdaten/-aufträge zwecks Wiedererkennungseffekt und damit besserer Akzeptanz genutzt. Verwendet wurden dabei die neu beschafften Endgeräte. Ein ‚hands-on‘ Vorgehen hat sich dabei eher bewährt als ein ‚zu akademisiertes‘ Schulen der Mitarbeiter. Insb. eine enge zeitliche Koppelung zwischen Schulung und Nutzung des Systems in produktionsnahen Tests war essenziell.

Im weiteren Verlauf wurden dann sukzessiv weitere Systeme (nicht nur das ERP, auch CAQ, Maschinen, etc.) angebunden und mussten insbesondere bezüglich Datenqualität und Performance getestet werden. Als letzter Schritt erfolgte der ‚Rückweg‘ der Buchungen ins ERP und das Überprüfen der Ergebnisse dort.   

Bei den Tests aufgetretene Fehler konnten über Screenshots und Karten im Kanbanboard dokumentiert werden. Die Berater und Hochschulen kümmerten sich dann um die systemseitige Behebung und die damit kontinuierliche Weiterentwicklung des Systems. Um Prozessanpassungen außerhalb des Systems kümmerten sich die Verantwortlichen der Anwendungsunternehmen. 

Bei einigen Anwendungspartnern konnten dann sogar im Rahmen von halbtägigen Scrum-Meetings und ganz-/mehrtägigen Coding Days kompakt, schnell und zielführend aufgetretene Fehler behoben und Systemverbesserungen durchgeführt werden, da das Nachstellen von Grenzsituationen in den Entwicklungssystemen nicht immer gelang. Diese Form der Zusammenarbeit hat sich als äußerst effektiv herausgestellt.  

Nach bzw. im Rahmen dieser Tests wurden auch Anpassungen an der UI vorgenommen und die Masken entsprechend den Wünschen der Anwendungspartner (soweit möglich, sinnvoll und mit angemessenem Aufwand machbar) iterativ verbessert. Besonders beachtet werden musste die Verwendung verschiedener Endgeräte und Browser.

Nach den Tests der Abteilungsleiter und den Anpassungen des Systems, wurde der Kreis der Tester auf die Endanwender ausgeweitet (je nach Unternehmensgröße und Mitarbeiteranzahl entfielen ggf. auch Tests durch verschiedene Hierarchiestufen). Die Anwender wurden hierbei durch die Abteilungsleiter, wiederum unterstützt von den Beratern und Hochschulen, im Rahmen der Tests geschult. Hierbei war es besonders wichtig, dass den Anwendern die Vorteile des Systems vermittelt und eventuelle Abweichungen vom alten Prozess oder Mehraufwände durch die digitale Erfassung verständlich begründet werden konnten. Auch sie konnten für die Erfassung von Fehlermeldungen das Kanban-Board nutzen.

Tests & Schulungen

Sind alle Details geklärt und die ‚Rohversion‘ des Systems grob angepasst (getestet durch die Dienstleister), können erste Anwendertests, vorzugsweise durch die Prozessverantwortlichen mit Unterstützung der Dienstleister, beginnen. Für den Einstieg eignen sich einfache Testprozesse/-aufträge ggf. auch mit Beispieldaten/manuellen Datenextrakten, um sich mit dem System vertraut zu machen. Im Idealfall sollten dann aber zeitnah ‚echte Aufträge‘ (insbesondere auch Sonderfälle) parallel zum analogen Prozess in digitaler Form durchgespielt werden. Auch die Anbindung der vor- und nachgelagerten Systeme muss zeitnah erfolgen, um reale Daten in die Tests einbeziehen zu können. Werden Probleme oder Fehler identifiziert, empfiehlt sich der Einsatz von Kanban-Boards zur Dokumentation und Behebung durch die Dienstleister. So kann das System iterativ angepasst, verbessert und verfeinert werden. Laufen die Prozesse dann stabil, können die Tests auf weitere Nutzer (z.B. Abteilungsleiter, angeleitet durch die Mitarbeiter,

die bereits Erfahrung damit haben) ausgeweitet werden. Hierbei sollten auf jeden Fall Echtdaten verwendet (Akzeptanzsteigerung) und ‚Massentests‘ (z.B. nicht nur 1 User an 1 Gerät mit 1 Auftrag mit 1 Produkt) durchgeführt werden. Spätestens hier sollte auch die Performance des Systems überprüft werden. Dies kann auch helfen etwaige Performance-Engpässe frühzeitig zu entdecken.

Im Rahmen von Schulungen sollen die Anwender mit dem System vertraut gemacht werden. Die direkt an der Umsetzung beteiligten Personen werden wie bereits beschrieben im Rahmen der Einführung/Tests etc. durch die Dienstleister und eigene Versuche ‚geschult‘. Je nach Unternehmensstruktur schulen diese Mitarbeiter dann die nächste Gruppe (z.B. Abteilungsleiter), die dann wiederum ihr Wissen an die restlichen (End-)User (Mitarbeitende ‚an der Maschine‘) weitergibt. Unterstützend können Schulungsunterlagen (Anleitungen, Screenshots, Klickanleitungen etc.) zur Verfügung gestellt werden.

Die Abteilungsleiter/Meister wurden unterstützt durch die Berater und Hochschulen im Rahmen von begleiteten Tests mit ausgewählten Testdaten und einfachen Prozessen an das System herangeführt. Über weitere, dann immer eigenständigere Tests und ggf. mit Hilfe von ‚Klickanleitungen‘ wurden die Tests auf Sonderfälle und schließlich Massentests mit Echtdaten ausgeweitet. Wichtig für die Akzeptanz des neuen Systems dabei war der richtige Zeitpunkt: das Testsystem musste möglichst fehlerfrei, stabil und performant funktionieren, aber noch nicht zu endgültig ohne weitere Änderungsmöglichkeit sein. Die Abteilungsleiter drängten darauf, etwas zu sehen und selbst auszuprobieren. Außerdem wurden möglichst realitätsnahe Testdaten/-aufträge zwecks Wiedererkennungseffekt und damit besserer Akzeptanz genutzt. Verwendet wurden dabei die neu beschafften Endgeräte. Ein ‚hands-on‘ Vorgehen hat sich dabei eher bewährt als ein ‚zu akademisiertes‘ Schulen der Mitarbeiter. Insb. eine enge zeitliche Koppelung zwischen Schulung und Nutzung des Systems in produktionsnahen Tests war essenziell.

Im weiteren Verlauf wurden dann sukzessiv weitere Systeme (nicht nur das ERP, auch CAQ, Maschinen, etc.) angebunden und mussten insbesondere bezüglich Datenqualität und Performance getestet werden. Als letzter Schritt erfolgte der ‚Rückweg‘ der Buchungen ins ERP und das Überprüfen der Ergebnisse dort.   

Bei den Tests aufgetretene Fehler konnten über Screenshots und Karten im Kanbanboard dokumentiert werden. Die Berater und Hochschulen kümmerten sich dann um die systemseitige Behebung und die damit kontinuierliche Weiterentwicklung des Systems. Um Prozessanpassungen außerhalb des Systems kümmerten sich die Verantwortlichen der Anwendungsunternehmen. 

Bei einigen Anwendungspartnern konnten dann sogar im Rahmen von halbtägigen Scrum-Meetings und ganz-/mehrtägigen Coding Days kompakt, schnell und zielführend aufgetretene Fehler behoben und Systemverbesserungen durchgeführt werden, da das Nachstellen von Grenzsituationen in den Entwicklungssystemen nicht immer gelang. Diese Form der Zusammenarbeit hat sich als äußerst effektiv herausgestellt.  

Nach bzw. im Rahmen dieser Tests wurden auch Anpassungen an der UI vorgenommen und die Masken entsprechend den Wünschen der Anwendungspartner (soweit möglich, sinnvoll und mit angemessenem Aufwand machbar) iterativ verbessert. Besonders beachtet werden musste die Verwendung verschiedener Endgeräte und Browser.

Nach den Tests der Abteilungsleiter und den Anpassungen des Systems, wurde der Kreis der Tester auf die Endanwender ausgeweitet (je nach Unternehmensgröße und Mitarbeiteranzahl entfielen ggf. auch Tests durch verschiedene Hierarchiestufen). Die Anwender wurden hierbei durch die Abteilungsleiter, wiederum unterstützt von den Beratern und Hochschulen, im Rahmen der Tests geschult. Hierbei war es besonders wichtig, dass den Anwendern die Vorteile des Systems vermittelt und eventuelle Abweichungen vom alten Prozess oder Mehraufwände durch die digitale Erfassung verständlich begründet werden konnten. Auch sie konnten für die Erfassung von Fehlermeldungen das Kanban-Board nutzen.

GoLive

Ist das System dann in diesem Bereich/dieser Abteilung stabil, kann es live gehen. Gerade in der Anfangszeit ist es vorteilhaft, wenn die Dienstleister vor Ort Unterstützung leisten und eventuell noch auftretende Probleme schnell beheben. Trotz umfassender Vorab-Tests sollte der Go-Live schrittweise pro Abteilung erfolgen und nicht im ganzen Unternehmen zur selben Zeit, da die Kapazitäten der Personen, die den Rollout unterstützen ggfs. nicht ausreichen. 

Waren alle offensichtlichen und kritischen Mängel behoben, konnte der Go-Live erfolgen. In den ersten Tagen erfolgte ein permanenter Support vor Ort durch die Berater und Hochschulen. Sehr zeitnah wurden Lessons Learned (allgemein beim Ablauf; Dinge, die man vorab hätte klären sollen; technische Schwierigkeiten, die unerwartet aufgetaucht sind etc.) aufgenommen, um eventuell aufgetretenen Herausforderungen beim nächsten Mal einfacher entgegenzutreten oder Probleme beim weiteren Rollout zu vermeiden.

Rollout

Wenn ein Bereich dann zufriedenstellend läuft, kann der Rollout auf weitere Abteilungen/Standorte erfolgen. Dabei ist zunächst zu klären, ob die Prozesse identisch sind oder ob Anpassungen im System notwendig sind.

Im Falle mehrerer Standorte, Unternehmensbereiche oder Abteilungen konnte nach dem erfolgreichen Go-Live dann der Rollout auf die nächsten Bereiche erfolgen. Als hilfreich erwiesen hat sich dabei, dort Neuerungen und der Technik aufgeschlossene Mitarbeiter als ‚Verbündete‘ für die Einführung einzubinden.

Im neuen Bereich musste wiederum mit der Prozessaufnahme in Camunda begonnen werden. Unter Umständen konnten dabei die Prozesse der anderen Abteilungen als ‚Vorlage‘ verwendet werden, um den Aufwand geringer zu halten. Alle weiteren Schritte erfolgten ebenso wie oben beschrieben. Zum Teil kann das entsprechend parallelisiert werden, um insgesamt schneller zum Ziel zu kommen. Das erfordert aber ausreichende Personalkapazitäten, die häufig nicht gegeben sind.

Verbesserungsprozess

Läuft das System dann in allen gewünschten Bereichen, bedeutet es nicht, dass es sich nicht mehr weiterentwickeln kann. Fehler in bestimmten Ausnahmefällen können nach wie vor auftreten und müssen zeitnah behoben werden. Es ist aber auch sinnvoll, regelmäßig Termine zur Optimierung des Systems einzuplanen (kontinuierlicher Verbesserungsprozess). 

In Moonrise wurde das HiCuMES-System auch nach den einzelnen „Bereichs-/Abteilungs-GoLives kontinuierlich weiterentwickelt, die Optimierungspunkte wurden innerhalb der regelmäßigen Scrum-Meetings diskutiert. Neben Fehlerbehebungen wurden dabei auch weiterhin kleinere Verbesserungen (Performance, UI etc.) vorgenommen. Für die Zukunft sollte ein kontinuierlicher Verbesserungsprozess etabliert werden. Insb. die Verknüpfung zu den anderen Einzelmaßnahmen ist hier zu betrachten.