[ARCHIVED CANNIBAL DUPE — DO NOT PUBLISH] OEE-Software-Integration mit SAP S/4HANA: Datenflüsse, Einrichtung und worauf zu achten ist

SAP S/4HANA ist das ERP-Rückgrat vieler mittelständischer und großer Hersteller und verwaltet Produktionsaufträge, Materialbewegungen, Anlageninstandhaltungsaufträge und Finanzberichterstattung. OEE-Software arbeitet auf der Fertigungsebene und erfasst Echtzeit-Maschinenzustände, Zykluszählungen und Qualitätsereignisse, die das Produktionsdatenmodell von SAP nicht nativ abbilden kann. Die Integration zwischen diesen beiden Systemen schafft einen bidirektionalen Datenfluss, der die Lücke zwischen dem geplanten Produktionsbild des ERP und der tatsächlichen Realität auf dem Shopfloor schließt.

Die primären Datenflüsse von OEE zu SAP S/4HANA umfassen: tatsächlich produzierte Mengen, die gegen Produktionsaufträge (Modul PP) bestätigt werden, Stillstandsereignisse, die die Erstellung von PM-Meldungen in der Instandhaltung auslösen, und Qualitätsausschussmengen, die in QM-Prüflose einfließen.

In umgekehrter Richtung sendet SAP Produktionsaufträge und Zeitpläne an die OEE-Plattform und liefert damit den geplanten Produktionskontext, den OEE-Software benötigt, um die Leistung genau zu berechnen, wobei die tatsächliche Produktion mit der geplanten Rate verglichen wird statt mit einer generischen Maschinenkapazität.

Für Hersteller, die SAP ME (Manufacturing Execution) oder SAP MII (Manufacturing Integration and Intelligence) neben S/4HANA betreiben, verbindet sich die OEE-Integration typischerweise mit diesen Mittelschichtsystemen statt direkt mit S/4HANA. Diese Architektur reduziert die Anzahl direkter Verbindungen zum ERP und ermöglicht der Manufacturing-Execution-Schicht, die Datenumwandlung zwischen der Granularität des Shopfloors und der Produktionsauftragsbestätigung auf ERP-Ebene zu übernehmen.

OEE, SAP-Integrationen werden typischerweise über SAPs Standard-Integrationstools implementiert, SAP Integration Suite, IDocs oder BAPI-Aufrufe, abhängig von der S/4HANA-Bereitstellung (Cloud, Private Cloud oder On-Premise) und den verfügbaren Konnektoren der OEE-Plattform. Die meisten Enterprise-OEE-Anbieter bieten vorgefertigte SAP-Konnektoren an, die die Abbildung zwischen OEE-Datenstrukturen und SAP-Formaten für Produktionsauftragsbestätigungen übernehmen und die Integrationsentwicklungszeit im Vergleich zur Entwicklung individueller APIs deutlich verkürzen.

Der Integrationsaufbau umfasst vier Hauptschritte: Festlegen, welche SAP-Fertigungsaufträge an das OEE-System fließen und welche OEE-Linien in den Geltungsbereich fallen; Zuordnung der OEE-Ausfallkategorien zu SAP PM‑Meldungsarten und Auftragsvorgängen; Konfiguration des Bestätigungstriggers (Echtzeit, Schichtende oder Batch); und Testen der Daten-Rundreise mit tatsächlichen Fertigungsaufträgen, um zu bestätigen, dass Mengen, Zeitstempel und Ausschusscodes korrekt übertragen werden.

Die Testphase ist der Abschnitt, in dem die meisten Integrationsprojekte auf Probleme stoßen, typischerweise bei der Zeitstempelverarbeitung, der Materialnummernübereinstimmung oder der Arbeitsplatzzuordnung, und sie sollte mindestens 4, 6 Wochen parallelen Betriebs vor der vollständigen Umstellung eingeplant werden.

Für S/4HANA Cloud (Public Edition) sind die Integrationsmöglichkeiten stärker eingeschränkt als bei On-Premise-Bereitstellungen. SAP Cloud Integration (Teil der Business Technology Platform) ist die Standard-Middleware für Cloud-Integrationen, und OEE-Anbieter, die S/4HANA Cloud unterstützen, haben typischerweise zertifizierte Integrationspakete im SAP Integration Marketplace verfügbar. Hersteller, die OEE-Software für eine Cloud-S/4HANA-Umgebung evaluieren, sollten die Anbieter gezielt nach ihrem BTP-Integrationspaket und nach Referenzkunden fragen, die dieselbe S/4HANA-Edition betreiben.

Der am häufigsten auftretende Fehlermodus bei OEE, SAP-Integrationsprojekten ist die Nichtübereinstimmung der Datenmodelle, das OEE-System und SAP haben unterschiedliche Vorstellungen davon, was einen „Produktionsauftrag“, einen „Arbeitsplatz“ oder eine „Schicht“ ausmacht, und die Abstimmung dieser Unterschiede erfordert mehr Designaufwand, als die meisten Teams erwarten.

SAP-Produktionsaufträge erstrecken sich oft über mehrere Schichten oder Produktionstage, während OEE-Software typischerweise die Leistung auf Schichtebene berechnet. Zu entscheiden, wie mit Teilbestätigungen von Produktionsaufträgen innerhalb einer Schicht umgegangen wird, erfordert früh im Projekt explizite Designentscheidungen. Ein zweites häufiges Problem ist die Zuordnung von Stillstandsursachencodes.

OEE-Plattformen haben typischerweise detaillierte, maschinenspezifische Taxonomien für Ausfallursachen (50, 100 Ursachencodes), während SAP-PM-Meldungen eine höherstufige Struktur von Ursachencodes verwenden, die an Instandhaltungs-Workflows ausgerichtet ist. Wird die Zuordnung naiv vorgenommen, zu viele OEE-Codes in zu wenige SAP-Codes zusammengeführt, verliert das Wartungsteam die nötige Granularität, um fundierte Reparaturentscheidungen zu treffen.

Der richtige Ansatz besteht darin, eine zweistufige Taxonomie zu entwerfen: detaillierte OEE-Codes für die Produktionsanalyse und je OEE-Kategorie ein abgebildeter SAP-Code, der die PM-Meldung in der entsprechenden SAP-Klassifikation erzeugt. Die dritte Fallstrick ist, die Integration als einmaliges technisches Projekt statt als fortlaufende Aufgabe der Daten-Governance zu betrachten.

OEE, SAP-Integrationen brechen, wenn sich SAP-Stammdaten ändern, neue Arbeitsplätze angelegt werden, Materialnummern geändert oder Auftragstypen aktualisiert werden, und die OEE-Zuordnung nicht parallel angepasst wird. Die Benennung eines Verantwortlichen für Daten-Governance, der OEE, SAP-Zuordnungsänderungen im Rahmen der SAP-Change-Management-Prozesse überprüft, verhindert die stillen Datenqualitätsprobleme, die nach dem Go-live den Wert der Integration untergraben.