Die meisten mittelständischen Fertigungsbetriebe nutzen drei bis fünf verschiedene Software-Tools, um eine eigentlich einheitliche, vernetzte operative Intelligenzfunktion zu verwalten.
Ein OEE-Überwachungstool, das die Produktionsleistung verfolgt.
Ein CMMS zur Verwaltung von Wartungsaufträgen.
Sehen Sie, wie Fabrico OEE und Instandhaltung in einer Plattform vereint.
Demo buchenEin digitales Inspektionstool zur Verwaltung von Konformitätsdokumenten.
Eine Tabellenkalkulationsebene verbindet die drei – denn keines der Systeme kommuniziert nativ miteinander.
Der Integrationsaufwand dieser fragmentierten Systemarchitektur – Lizenzkosten, Zeitaufwand für den Datenabgleich, doppelte Dateneingabe und die mangelnde Abstimmung zwischen den Systemen – ist durchweg höher als die Kosten einer einheitlichen Plattform, die all dies ersetzen würde.
Dieser Leitfaden richtet sich an Hersteller, die bereits zu dem Schluss gekommen sind, dass eine Konsolidierung sinnvoll ist und einen praktischen Rahmen für deren Umsetzung benötigen.
Bevor man plant, wie man den fragmentierten Stack ersetzen kann, ist es wichtig zu verstehen, wie dieser aufgebaut wurde.
Fast niemand hat sich bewusst für eine Drei-Werkzeug-Architektur entschieden.
Es hat sich weiterentwickelt.
Das OEE-Tool kam zuerst – weil ein Produktionsleiter Transparenz in der Produktionslinie benötigte und ein schnelles, kostengünstiges Überwachungstool fand, das das unmittelbare Problem löste.
Das CMMS kam an zweiter Stelle – weil ein Instandhaltungsleiter eine Arbeitsauftragsstruktur benötigte und eine Plattform fand, die dieses unmittelbare Problem löste, unabhängig von dem OEE-Tool, das das Produktionsteam bereits verwendete.
Das Inspektionsinstrument landete an dritter Stelle – weil eine Qualitäts- oder Konformitätsanforderung hinzukam, die mit den vorhandenen Instrumenten nicht erfüllt werden konnte.
Jedes Werkzeug war eine rationale Antwort auf ein bestimmtes Problem zu einem bestimmten Zeitpunkt.
Das kumulative Ergebnis – drei Tools ohne native Verbindung, drei Lizenzkosten, drei Lieferantenbeziehungen und drei Datenumgebungen, die drei unterschiedliche, unvollständige Geschichten über dieselbe Produktionshalle erzählen – war nie die Absicht.
Es war das Ergebnis einer sequenziellen Problemlösung ohne eine einheitliche Architekturvision.
Diese Erkenntnis ist wichtig, denn sie bedeutet, dass es bei der Konsolidierung nicht darum geht, einzugestehen, dass die vorherigen Entscheidungen falsch waren.
Es geht darum zu erkennen, dass die Summe individuell rationaler Entscheidungen eine kollektiv irrationale Architektur hervorgebracht hat – und diese mit dem Vorteil der nachträglichen Erkenntnis zu korrigieren.
Bevor Sie eine Ersatzplattform in Betracht ziehen, sollten Sie ehrlich prüfen, welche Kosten die aktuelle Systemarchitektur tatsächlich verursacht.
Dieses Audit besteht aus vier Komponenten.
Listen Sie alle Software-Tools auf, die derzeit für die Überwachung der Produktionsleistung, das Wartungsmanagement, die Dokumentation der Einhaltung von Vorschriften und die dazugehörige Berichtsinfrastruktur verwendet werden.
Berücksichtigen Sie die jährlichen Lizenzkosten, die Kosten pro Benutzer und alle Zusatzmodule.
Berücksichtigen Sie die Kosten für Tabellenkalkulations- und BI-Tools, falls dedizierte Lizenzen für die Berichtsschicht existieren, die die primären Tools verbindet.
Die meisten Hersteller sind überrascht, wie groß diese Zahl ist, wenn alle Komponenten zusammen aufgeführt werden, anstatt sie als separate Positionen in separaten Abteilungsbudgets zu bewerten.
Schätzen Sie die jährlichen Kosten für die Aufrechterhaltung der Verbindungen zwischen den Tools im aktuellen Stack.
Dies umfasst den IT-Zeitaufwand für die Wartung von API-Integrationen, Datenexport- und -importroutinen sowie Synchronisierungsprozessen zwischen Systemen.
Dazu gehört auch der Zeitaufwand des Wartungsteams für die doppelte Dateneingabe – die Eingabe derselben Fehlerinformationen sowohl in das OEE-Tool als auch in das CMMS, da keines der Systeme die Daten automatisch mit dem anderen austauscht.
Dazu gehört auch der Zeitaufwand des Managements für die Erstellung manueller, systemübergreifender Berichte, da kein einzelnes System die von der Führungsebene benötigte konsolidierte Sichtweise liefert.
Für die meisten mittelständischen Hersteller entsprechen diese Integrations- und Wartungskosten – die in Budgets selten als separater Posten aufgeführt werden – bei vollständiger Kostenrechnung 30 bis 60 % der gesamten direkten Lizenzkosten.
Dies ist die am schwierigsten zu quantifizierende Komponente, aber in der Regel die größte.
Die Reaktionslücke ist die Zeitspanne zwischen der Erkennung eines Produktionsleistungsereignisses im OEE-Tool und der Generierung einer strukturierten Wartungsreaktion im CMMS.
In einem fragmentierten Stack wird diese Lücke durch menschliche Koordination geschlossen – ein Vorgesetzter bemerkt eine Warnung im OEE-Tool, entscheidet, dass eine Wartungsmaßnahme erforderlich ist, teilt diese Entscheidung dem Wartungsteam mit und wartet darauf, dass ein Arbeitsauftrag im CMMS erstellt wird.
Dieser Prozess dauert je nach Schwere des Alarms und den Kommunikationspraktiken der Einrichtung zwischen 15 Minuten und mehreren Stunden.
Schätzen Sie die Kosten der Handlungslücke mithilfe dieser Formel:
Durchschnittliche Aktionslückendauer in Minuten × Durchschnittlicher Produktionswert pro Minute × Anzahl der Produktionsereignisse pro Monat, die eine Wartungsreaktion auslösen sollten.
Für einen Hersteller, der monatlich 40 bedeutende Produktionsereignisse mit einer durchschnittlichen Aktionslücke von 30 Minuten auf einer Produktionslinie mit einem Stundensatz von 300 US-Dollar verzeichnet:
40 × 30 Minuten × (300 $ ÷ 60 Minuten) = 6.000 $ pro Monat an wiederherstellbarem Produktionswert, der allein durch die Handlungslücke verloren geht.
Fragmentierte Stacks erzeugen fragmentierte Daten.
Die Produktionsleistungsdatensätze des OEE-Tools und die Wartungsdatensätze des CMMS verwenden keine gemeinsamen Anlagenkennungen, Zeitstempelformate oder Verlustkategorisierungsrahmen – was bedeutet, dass für eine systemübergreifende Analyse ein manueller Abgleich erforderlich ist.
Die Inspektionsaufzeichnungen des Compliance-Dokumentationstools sind nicht mit den Wartungsaufträgen des CMMS verknüpft – das bedeutet, dass der Nachweis des Zusammenhangs zwischen einem Inspektionsergebnis und der entsprechenden Korrekturmaßnahme eine manuelle Zusammenstellung erfordert.
Schätzen Sie die Kosten für die Datenqualität, indem Sie die wöchentlichen Stunden, die Ihr Team für die Erstellung systemübergreifender Berichte und Compliance-Dokumentationspakete aufwendet, mit den gesamten Stundensätzen der Mitarbeiter multiplizieren, die diese Arbeit ausführen.
Für einen Wartungsmanager, der 4 Stunden pro Woche mit der manuellen systemübergreifenden Berichterstellung zu einem Stundensatz von 45 US-Dollar (Volllast) beschäftigt ist, belaufen sich die jährlichen Kosten für die Datenqualität auf 9.360 US-Dollar – für eine Person und eine wiederkehrende Aufgabe.
| Kostenkomponente | Ihr Kostenvoranschlag |
|---|---|
| Direkte Lizenzkosten (alle Tools zusammen) | $ |
| Integrationswartung (IT + manuelle Dateneingabe) | $ |
| Kosten der Handlungslücke (Produktionswertverlust durch Koordinationsverzögerung) | $ |
| Kosten der Datenqualität (manuelle Berichterstellung und Zusammenstellung von Compliance-Vorgaben) | $ |
| Jährliche Gesamtkosten für den Stapel | $ |
Diese Gesamtsumme – nicht die einzelnen Lizenzgebühren – ist die Zahl, die mit den Gesamtbetriebskosten einer einheitlichen Plattform verglichen werden muss.
Der Vergleich führt fast immer zu einem anderen Ergebnis als der reine Vergleich der Lizenzgebühren.
Nicht jedes Werkzeug im aktuellen Technologie-Stack muss durch die Konsolidierungsplattform ersetzt werden.
Manche Tools lösen Probleme, für deren Bewältigung eine einheitliche Fertigungsplattform eigentlich nicht ausgelegt ist – z. B. Druck-MIS-Systeme, ERP-Finanzmodule, dedizierte Kalibrierungsmanagementplattformen.
Die Definition dessen, was die Konsolidierungsplattform leisten muss – und was im Stack verbleibt, weil es eine Funktion außerhalb des Konsolidierungsbereichs erfüllt – verhindert den häufigen Fehler, alles konsolidieren zu wollen und am Ende eine Plattform zu erhalten, die nichts besonders gut kann.
Der Konsolidierungsbereich für die meisten mittelständischen Hersteller umfasst vier Funktionen:
Echtzeit-Produktionsleistungsüberwachung – OEE-Tracking im Rahmen der sechs größten Verlustfaktoren, basierend auf Maschinensignalen und nicht abhängig von der Beobachtung durch den Bediener.
Management der Instandhaltungsausführung – Arbeitsaufträge, PM-Planung, Ersatzteilmanagement und Compliance-Audit-Trail, bereitgestellt über eine mobile Außendienstumgebung.
Konformitätsdokumentation – automatisierte Aufzeichnung jeder Wartungsmaßnahme mit Benutzerzuordnung, Zeitstempel, SOP-Version und Checklisten-Abarbeitung – ausreichend, um die Anforderungen von ISO 9001, IATF 16949, GMP oder Lebensmittelsicherheitsaudits ohne manuelle Zusammenstellung zu erfüllen.
Integration von Produktions- und Wartungsplanung – eine Planungsumgebung, in der Wartungsbeschränkungen zusammen mit den Produktionsauftragsanforderungen sichtbar sind, sodass Konflikte gelöst werden, bevor sie in der Produktion auftreten.
Was typischerweise außerhalb des Konsolidierungsbereichs bleibt:
ERP-Finanzmodule – Beschaffung, Kreditorenbuchhaltung, Finanzberichterstattung.
Spezialisierte Qualitätsmanagementsysteme für das CAPA-Management und die Dokumentenkontrolle, die über die Einhaltung der Wartungsvorschriften hinausgehen.
Speziell entwickelte Tools für das Turnaround- und Shutdown-Management bei großen geplanten Stillstandsprogrammen.
Spezielle Kalibrierungsmanagementsysteme für Betriebe mit großen Flotten kalibrierter Instrumente.
Die explizite Definition dieses Umfangs – bevor eine Plattform evaluiert wird – verhindert eine Ausweitung des Umfangs während der Evaluierung und beugt Enttäuschungen vor, wenn die konsolidierte Plattform etwas nicht ersetzt, was sie nie ersetzen sollte.
Die Bewertungskriterien für eine Konsolidierungsplattform unterscheiden sich von den Kriterien für den Ersatz einer Punktlösung.
Eine punktuelle Ersatzlösung muss eine Sache besser können als das Werkzeug, das sie ersetzt.
Eine Konsolidierungsplattform muss vier Dinge angemessen leisten – und idealerweise sollten diese besser miteinander vernetzt sein als die vier einzelnen Werkzeuge, die einzeln angewendet werden.
Die Konsolidierungsbewertung stellt eine andere Frage als die Punktlösungsbewertung.
Nicht „Welches OEE-Tool ist das beste?“ oder „Welches CMMS ist das beste?“
Aber welche Plattform bietet OEE-Überwachung, CMMS-Ausführung, Compliance-Dokumentation und Terminplanungsintegration so gut, dass die native Verbindung zwischen ihnen einen größeren operativen Nutzen bietet als vier separate Best-of-Breed-Tools?
Die Antwort auf diese Frage hängt von zwei Dingen ab.
Erstens: Welcher Anteil des Mehrwerts im aktuellen Stack resultiert aus der herausragenden Expertise der einzelnen Tools im Vergleich zur Vernetzung der Tools untereinander?
Wenn der Hauptnutzen des aktuellen OEE-Tools in der Tiefe der CNC-spezifischen Spindelanalysen liegt – und diese Tiefe für das Verbesserungsprogramm des Betriebs von entscheidender Bedeutung ist –, muss die Konsolidierungsplattform diese Tiefe erreichen, andernfalls wird die Konsolidierungsfähigkeit gegen Konnektivität eingetauscht.
Wenn der Hauptnutzen des aktuellen OEE-Tools in der grundlegenden Linientransparenz liegt, die jede maschinenverbundene Plattform bietet, muss die Konsolidierungsplattform einer zugänglichen Basislinie entsprechen und nicht einer spezialisierten Tiefe – und der Wert der nativen Konnektivität zum CMMS ist mit ziemlicher Sicherheit größer als der Tiefenvorteil des eigenständigen OEE-Tools.
Zweitens: Wie ist die realistische Integrationsqualität des aktuellen Stacks im Vergleich zur nativen Verbindungsqualität der Konsolidierungsplattform?
API-Integrationen zwischen separaten Tools sind nie so nahtlos wie die native Integration innerhalb einer einzigen Plattform.
Datenlatenz, Synchronisationsfehler und der Wartungsaufwand für die Integration sind strukturelle Gegebenheiten des fragmentierten Stacks – keine Fehler, die behoben werden müssen.
Bewerten Sie die native Konnektivität der Konsolidierungsplattform anhand der realistischen Integrationsqualität des aktuellen Stacks – und nicht anhand einer theoretischen idealen Integration, die in der Praxis nicht existiert.
Sobald eine Konsolidierungsplattform ausgewählt ist, sollte die Migration in Phasen erfolgen, die Betriebsunterbrechungen minimieren und gleichzeitig die frühzeitige Wertschöpfung maximieren.
Phase 1: Pilotstandort, Anlagen mit höchster Priorität (Monat 1)
Wählen Sie einen Standort aus – idealerweise denjenigen mit den höchsten ungeplanten Ausfallkosten oder dem gravierendsten Problem der Handlungslücke.
Verbinden Sie innerhalb dieses Standorts die 5 bis 10 Produktionsanlagen mit der höchsten Kritikalität mit der neuen Plattform.
Die alten Tools werden für diese Website 30 Tage lang parallel betrieben – so wird der Wartungsbetrieb während der Umstellung nicht unterbrochen.
Messen Sie am Ende von Phase 1 drei Kennzahlen: Zuverlässigkeit der Maschinenverbindung, Akzeptanzrate der Techniker und mindestens einen bestätigten zustandsbasierten PM-Trigger, der durch ein Maschinensignal ausgelöst wurde.
Wenn alle drei Punkte bestätigt sind, beginnt Phase 2. Andernfalls werden die offenen Fragen geklärt, bevor der Umfang erweitert wird.
Phase 2: Vollständige Abdeckung des Geländes (Monate 2-4)
Erweitern Sie die Maschinenvernetzung auf alle Produktionsanlagen am Pilotstandort – einschließlich älterer Anlagen über ein IoT-Gateway und manueller Stationen über Computer Vision, wo dies angebracht ist.
Die PM-Pläne sollten aus dem aktuellen CMMS migriert werden – validiert anhand der tatsächlichen Ausfallhistorie und nicht unkritisch aus kalenderbasierten Intervallen migriert werden.
Konfigurieren Sie die Workflows zur Dokumentation der Einhaltung von Vorschriften so, dass sie die spezifischen, für die Einrichtung geltenden Audit-Rahmenbedingungen erfüllen.
Sobald die neue Plattform betriebsbereit ist, werden die alten OEE-Tools, CMMS und Inspektionstools für diesen Standort außer Betrieb genommen.
Phase 3: Zusätzliche Standorte (ab Monat 4)
Jeder weitere Standort folgt der gleichen Abfolge wie der Pilotstandort – jedoch schneller, da die Konnektivitätsmethodik, der Ansatz zur Validierung des PM-Zeitplans und die Compliance-Konfiguration bereits aus Phase 1 und 2 festgelegt wurden.
Die Implementierungszeit pro Standort verringert sich typischerweise mit jedem weiteren Standort, da die Vertrautheit des Implementierungsteams mit der Methodik zunimmt.
Definieren Sie die Erfolgskennzahlen, bevor die Konsolidierung beginnt – nicht erst, nachdem die Ergebnisse bekannt sind.
Die Kennzahlen, die den Konsolidierungswert am direktesten widerspiegeln, sind:
Reduzierung der Reaktionslücke – die durchschnittliche Zeitspanne zwischen einem Produktionsereignis und einer strukturierten Wartungsreaktion. Messen Sie diesen Wert vor und nach der Konsolidierung.
Eine signifikante Reduzierung bestätigt, dass die native Konnektivität ihren versprochenen Nutzen erbringt.
Zeitaufwand für die systemübergreifende Berichtserstellung – die wöchentliche Stundenzahl, die bisher für die manuelle Erstellung systemübergreifender Berichte aufgewendet wurde. Nach der Konsolidierung sollte sich dieser Aufwand für die von der konsolidierten Plattform nativ generierten Berichte auf nahezu null reduzieren.
Zeitaufwand für die Zusammenstellung der Compliance-Dokumentation – die Stunden, die für die Vorbereitung von Wartungsaufzeichnungen für Audits aufgewendet werden. Nach der Konsolidierung sollte die bedarfsgesteuerte Berichtserstellung die manuelle Zusammenstellung ersetzen.
Nutzungsrate der Techniker – der Prozentsatz der Wartungstechniker, die die mobile App innerhalb von 30 Tagen nach der Inbetriebnahme aktiv nutzen. Ein Wert unter 70 % deutet auf ein Nutzungsproblem hin, das vor der Ausweitung auf weitere Standorte behoben werden muss.
Reduzierung der Lizenz- und Integrationskosten – die direkte Kostendifferenz zwischen den gesamten jährlichen Kosten des fragmentierten Stacks und den gesamten jährlichen Kosten der konsolidierten Plattform.
Nutzen Sie diese Checkliste, um zu bestätigen, dass die Konsolidierungsentscheidung zum Abschluss bereit ist.
Audit abgeschlossen: Die gesamten Stack-Kosten – Lizenzen, Integrationswartung, Aktionslücken, Datenqualität – wurden berechnet und mit den Gesamtbetriebskosten der konsolidierten Plattform verglichen.
Definition des Umfangs: Die vier Funktionen, die die Konsolidierungsplattform erfüllen muss, wurden vereinbart. Die Tools, die nicht zum Konsolidierungsumfang gehören, wurden identifiziert.
Die Plattform wurde anhand von Konsolidierungskriterien bewertet: Bei der Bewertung wurde geprüft, ob eine native Konnektivität zwischen OEE-, CMMS- und Compliance-Funktionen einen größeren Mehrwert bietet als der derzeit fragmentierte Stack – und nicht nur, ob eine einzelne Funktion mit der aktuellen Punktlösung mithalten kann.
Pilotstandort und Erfolgskennzahlen definiert: Der Pilotstandort wird ausgewählt. Die Go-Live-Kriterien – Zuverlässigkeit der Verbindung, Akzeptanzrate, bedingungsbasierte Triggerbestätigung – werden vor Beginn der Implementierung definiert.
Es existiert ein Plan zur Stilllegung der Altsysteme: Die Reihenfolge und der Zeitpunkt der Stilllegung jedes Altsystems – einschließlich vertraglicher Kündigungsfristen und Anforderungen an den Datenexport – werden vor Beginn des Konsolidierungsprojekts dokumentiert.
Wie lange dauert eine vollständige Konsolidierung der Produktionsanlagen an einem einzelnen Fertigungsstandort?
Ein 30-tägiges Pilotprojekt bis zur ersten Inbetriebnahme und 3-4 Monate bis zur vollständigen Implementierung an einem einzigen Standort – einschließlich Maschinenvernetzung für den gesamten Anlagenpark, Stilllegung veralteter Werkzeuge und Konfiguration der Einhaltung von Vorschriften.
Was geschieht mit unseren historischen Daten aus den alten Systemen?
Die wirklich nützlichen historischen Daten – Anlagenhierarchien, Wartungspläne, hochwertige Arbeitsauftragsdatensätze – werden während der Konfigurationsphase auf die neue Plattform migriert.
Historische Datensätze von geringer Qualität – also minimale, aber nicht aussagekräftige Einträge ohne analytischen Wert – werden in der Regel nach einer Datenqualitätsprüfung ausgeschlossen.
Können wir die Konsolidierung schrittweise angehen, anstatt alles auf einmal?
Ja. Der in diesem Leitfaden beschriebene stufenweise Ansatz ist bewusst auf eine schrittweise Konsolidierung ausgelegt – zuerst ein Pilotstandort, dann ein vollständiger Standort und anschließend weitere Standorte.
Der Versuch einer gleichzeitigen Konsolidierung aller Standorte erhöht das Risiko, ohne die Wertschöpfung nennenswert zu beschleunigen.
Was passiert, wenn eines unserer älteren Tools Funktionen besitzt, die die Konsolidierungsplattform nicht vollständig abdeckt?
Dies ist die wichtigste Frage bei der Bewertung der Konsolidierung.
Wenn die Fähigkeitslücke in einer Funktion liegt, die für den Konsolidierungsumfang von zentraler Bedeutung ist – OEE-Überwachungstiefe, CMMS-Anlagenverwaltungshierarchie, Compliance-Audit-Trail –, muss die Lücke vor dem Fortfahren der Konsolidierung geschlossen werden.
Wenn die Fähigkeitslücke in einer Funktion außerhalb des Konsolidierungsbereichs liegt – z. B. im spezialisierten Kalibrierungsmanagement oder in der Tiefe der Turnaround-Planung –, kann dieses Tool berechtigterweise im Stack neben der konsolidierten Plattform verbleiben.
Wenn Ihre aktuelle Systemanalyse deutlich höhere Gesamtkosten als erwartet ergibt und die Bewertung der Konsolidierungsplattform bestätigt, dass native Konnektivität einen höheren Mehrwert bietet als Ihre derzeitige Integrationsarchitektur, ist der nächste sinnvolle Schritt eine Machbarkeitsstudie zur Konnektivität der Anlagen an Ihrem Pilotstandort. Diese Studie klärt, ob die Maschinenkonnektivität realisierbar ist, bevor eine vollständige Investition getätigt wird.
Erleben Sie OEE & CMMS live in 15 Minuten.
Demo buchen
Anmeldung
Blog
