OEE-Software + Infor-Integration (2026): Architektur, Stolperfallen und funktionierendes Playbook

Infor-Versionen, Integrations-Schnittstellen und was "integriert" wirklich heißt

Erste Stolperstelle: die Version. Drei Ausprägungen in Europa, jede mit eigenen Schnittstellen.

Infor CloudSuite Industrial (CSI), früher SyteLine. Mittelstands-Cloud für diskrete Fertigung. Shopfloor dreht sich um Shop Orders, Work Centers, Operationen. ION mit BODs, ProcessShopOrderOperation, AcknowledgeShopOrderOperation, SyncWorkCenter, SyncItemMaster. ION API Gateway legt REST darüber.

Infor M3. Stark in Skandinavien, Lebensmittel, Mode, leichter Diskret. Production Orders und Reporting Points. ION dominiert. Häufige BODs: ProcessProductionOrder, AcknowledgeProductionOrder, SyncBillOfMaterial. Älterer MEC- / M3-API-Layer über H5 wird teilweise noch genutzt.

Infor LN (früher Baan). Process und Diskret mit langer Automotive/Aerospace-Historie. ION-nativ, aber on-prem üblich. Direkte DB-Reads an älteren Standorten, nicht unterstützt, bricht beim Upgrade.

Wenn ein Anbieter sagt "wir integrieren Infor", drei Fragen:

1. Welches Modul? CSI, M3 oder LN.
2. Welches ION-Muster? Pulse, API Gateway oder beides.
3. Was wird zurückgeschrieben? Operationsmeldungen, Ausschuss, Stillstandsgründe, hier lohnt sich Integration.

Was "integriert" 2026 bedeuten soll:

• Jeder Stillstand vom CV-OEE oder Sensor landet binnen 60 Sekunden auf einer offenen Infor-Order.
• Ausschuss vom OEE-Tablet schreibt zurück als zurückgewiesene Menge.
• Geplanter Stillstand (Rüsten, CMMS-PMs) erscheint auf OEE-Timeline vor dem Ereignis.
• Work-Center-Statuswechsel fließen ins OEE; Dashboard lügt nicht.
• Bediener sehen offene Shop Order, Norm-Zykluszeit, Takt, aus Infor, am OEE-Bildschirm.

Ein Anbieter, der nicht jeden Fluss einer BOD oder API zuordnen kann, ist nicht integriert.

Vertiefende Lektüre: OEE + Epicor Integration · Auswahlprozess · Versteckte Kosten · Kreis schließen.

Nach ~40 europäischen Integrationen 2022-2026 dominieren drei Muster.

Muster 1, Shop-Order-eventbasiert über ION Pulse (Standard für CSI und M3).

Infor publiziert bei jedem Statuswechsel einen BOD. OEE abonniert, hört zu, aktualisiert nahezu Echtzeit. Latenz 1-5 Sekunden. Vorteile: Echtzeit. Nachteile: Pulse zickt bei hohem Volumen, Dead-Letter-Queue Pflicht.

Muster 2, Produktionsplan-Pull über ION API Gateway (für LN und konservative IT).

OEE pollt API Gateway alle 1-2 Minuten. Latenz 60-120 Sekunden. Vorteile: leichter debugbar, IT-Change-Control-freundlich. Nachteile: 60-Sekunden-Blindstellen, Lastspitzen bei Schichtbeginn.

Muster 3, Historian-Pull mit nachträglicher ERP-Abstimmung (alte M3, on-prem LN, ohne aktives ION).

OEE erfasst autonom gegen Work Centers, Nachtjob gleicht Intervalle mit Shop Orders ab. ERP-Latenz Stunden bis Tag, OEE bleibt Echtzeit. Vorteile: null Risiko, kein ION-Lizenz, 2 Wochen Go-live. Nachteile: "nicht zugeordneter" Stillstand live, kein Rückschreiben, Pareto am nächsten Tag.

Entscheidungsfrage: muss der Bediener während der Schicht die offene Infor-Order am OEE-Bildschirm sehen, oder reicht tagesaktuelle Auswertung? Werkleiter mit Echtzeit-Anspruch: Muster 1. Reliability mit Monats-Pareto: Muster 3. Enterprise IT: Muster 2.

Was kostet Infor + OEE wirklich? Ein Standort, ein Modul, 3-5 Work Centers: 15-75 T€ Implementierung + 30-120 interne Stunden. ION-Lizenz meist in Infor-Abo enthalten, Pulse/API-Gateway-Tiers prüfen.

Welche OEE-Anbieter unterstützen Infor wirklich?

• TrakSYS, starker Infor-Track-Record bei großen Diskreten, volle ION-BOD-Unterstützung, teure Lizenz.
• FORCAM FORCE, verbreitet in DACH Automotive/Aerospace auf M3/LN, ION-nativ, lange Zyklen.
• AVEVA System Platform, eng mit Historian, ungemütliche Lizenz über 10 Linien.
• Fabrico, CSI, M3, LN via ION-BOD + API Gateway, CV-OEE obendrauf, Festpreis unter 30 T€.
• Viele kleinere Cloud-OEE-Tools behaupten Infor-Support, liefern CSV-Importer. Vor Vertragsabschluss Live-ION-Call verlangen.

Sechs-Test-Checkliste:

1. BOD-Subscriber empfängt Live-ProcessShopOrderOperation binnen 5 Sekunden.
2. Work-Center-Kontext am OEE-Board = Infor.
3. Stillstand binnen 60 Sekunden der aktiven Shop Order zugeordnet.
4. Ausschuss vom OEE-Tablet erscheint binnen 2 Minuten in Infor.
5. Plan-Ist-Abweichung gleicht sich auf 1 % ab.
6. OAuth-Refresh im Pilot bricht das Abo nicht.

Und Infor EAM auf der CMMS-Seite? Selbes ION-Muster. Wartungsaufträge fließen als geplanter Stillstand ins OEE. Vom Bediener gemeldete Störungen lösen via SyncWorkOrder eine EAM-Anforderung aus. Die meisten Werke fahren Fabrico natives CMMS auf OEE und gleichen täglich auf Asset-Ebene mit Infor EAM ab.

Fazit

Infor + OEE funktioniert als echtes Integrationsprojekt. Richtiges Muster (Pulse für CSI/M3, API Gateway für LN, Historian-Pull ohne aktives ION), BODs einmal sauber gemappt, sechs Wochen für eine Linie, Live-ION-Call vor Vertragsabschluss. Skip = ein Jahr lang erklären, warum Dashboard und ERP nicht übereinstimmen.

Sehen, wie eine fertige Infor + OEE-Integration aussieht? Fabrico fährt aktive ION-BOD-Abos und API-Gateway-Aufrufe gegen Live-Sandboxes von CSI, M3, LN. 25 Minuten Demo buchen.

Der 6-Wochen-Plan für Infor + OEE

Sechs Wochen für eine Linie, ein Modul, eine ION-Instanz. Krabbeln, gehen, rennen.

Wochen 1-2, Scoping, BOD-Mapping, Authentifizierung.

• Modul (CSI / M3 / LN), Version, ION-Produktivstatus bestätigen.
• BOD-Abos und API-Endpunkte inventarisieren.
• ION-Service-Account, OAuth-Credentials, API-Gateway-Berechtigung.
• Reason-Codes auf OEE-Tree mappen.
• Pilot-Work-Center wählen, höchstes Volumen.

Woche 3, Subscriber-Endpunkte und Event-Handler.

• BOD-Subscriber (Muster 1) oder Polling-Job (Muster 2) aufsetzen.
• Ersten Live-ProcessShopOrderOperation parsen, Operation, Work Center, Menge prüfen.
• Synthetisches Acknowledge zurück über ION schreiben, Beweis für Rückschreiben.
• Dead-Letter-Queue, Retry, BOD-Fehlerkatalog.

Woche 4, Pilot an einer Linie. Bediener sehen offene Infor-Order am OEE. Ausschuss vom Tablet landet binnen Minute in Infor. Sechs-Test-Checkliste.

Woche 5, Skalieren. 3-5 weitere Work Centers. Subscriber wiederverwenden. Schichtführer schulen.

Woche 6, Cutover, Altprozess abschalten, Dokumentation. Manuelle Stillstandsprotokolle abschalten. BOD-Monitoring in Observability-Stack. Runbook (BOD-Katalog, API-Liste, OAuth-Refresh). 30-Tage-Review terminieren.

Zwei Warnungen: OAuth-Token sind kurzlebig (Ausfall Nr. 1, Refresh-Logik in Woche 3 einbauen). Service-Pack-Upgrades verändern BOD-Payloads (Release-Notes abonnieren, Sandbox-Test vor jedem Prod-Upgrade).