API, Exit-Strategie und Datenhoheit: was Sie vor der MES-Einführung klären sollten
Ein Manufacturing Execution System (MES, nach IEC 62264 / ISA-95 die Softwareebene zwischen ERP und Maschinensteuerung) sammelt über Jahre die vollständige Fertigungshistorie eines Betriebs: Auftragsdaten, Maschinenzustände, Prüfergebnisse, Chargen- und Rückverfolgbarkeitsdaten. Wie leicht diese Daten später wieder herauskommen und wie offen die Schnittstellen des Systems sind, entscheidet sich nicht beim Wechsel, sondern beim Vertragsschluss. Laut einer VDMA-Studie zur Interoperabilität im Maschinenbau sehen 84 Prozent der befragten Unternehmen 2025 einen konkreten Bedarf an interoperablen, offenen Schnittstellen (VDMA, November 2025). Diese Seite ordnet ein, worauf es bei API-Offenheit, Datenhoheit und einer vertraglich abgesicherten Exit-Strategie für Fertigungsunternehmen im DACH-Raum ankommt, bevor die Unterschrift unter dem MES-Vertrag steht.
Zwei Fragen,
die dieselbe Antwort verlangen
Eine Application Programming Interface, kurz API, ist die definierte Schnittstelle, über die andere Systeme lesend oder schreibend auf Daten und Funktionen eines MES zugreifen können. Datenhoheit beschreibt, wer vertraglich und technisch über die im MES erzeugten Daten verfügen kann, unabhängig davon, wo diese Daten physisch gespeichert sind.
Beide Fragen laufen in der Praxis auf dasselbe Kriterium hinaus: Kann das Fertigungsunternehmen jederzeit, auch ohne aktive Mitwirkung des Herstellers, an die eigenen Daten und an die eigene Systemlandschaft heran? Ein MES mit dokumentierter, offener API erlaubt es, Auswertungen, ERP-Anbindungen und spätere Migrationen selbst zu bauen oder von Dritten bauen zu lassen. Ein MES ohne offene Schnittstellen zwingt dazu, für jede Integration und jeden Export auf den Hersteller angewiesen zu sein, auch dann noch, wenn der Vertrag längst gekündigt ist. Wer dieses Kriterium erst beim geplanten Wechsel prüft, siehe auch MES wechseln, Migration und Kosten, prüft es in der Regel zu spät, weil sich API-Umfang und Exportfunktionen nach Vertragsschluss kaum noch nachverhandeln lassen.
Der Gesetzgeber verstärkt diesen Trend zusätzlich: Die EU-Verordnung 2023/2854, bekannt als Data Act, ist seit dem 12. September 2025 anwendbar und regelt erstmals branchenübergreifend, welche Zugriffsrechte Nutzer vernetzter Geräte auf die dabei erzeugten Daten haben (Amt für Veröffentlichungen der Europäischen Union, EUR-Lex, 2024). Für Fertigungsunternehmen bedeutet das: Offene Schnittstellen und dokumentierte Datenhoheit sind kein Komfortmerkmal mehr, sondern zunehmend auch regulatorisch erwartete Praxis, siehe dazu auch unsere Einordnung zu Composable MES und Microservices als architektonische Antwort auf dieselbe Fragestellung.
Woran Sie eine wirklich
offene API erkennen
„Offene API" ist im MES-Markt kein geschützter Begriff. Vier Prüfpunkte trennen eine dokumentierte, nutzbare Schnittstelle von einer, die auf dem Papier existiert, aber in der Praxis kaum verwendbar ist.
| Prüfpunkt | Worauf achten | Warnsignal |
|---|---|---|
| Schnittstellentyp | REST-API (Representational State Transfer, Architekturstil für zustandslose HTTP-Schnittstellen) oder OData (Open Data Protocol, standardisiert als ISO/IEC 20802 durch OASIS und ISO/IEC JTC 1) als weit verbreitete, gut dokumentierbare Standards | Ausschließlich proprietäres Binärprotokoll oder Datenbankzugriff ohne API-Schicht |
| Dokumentationsstandard | Maschinenlesbare Beschreibung nach OpenAPI-Spezifikation (vormals Swagger), mit Beispielaufrufen und Antwortschemata, frei zugänglich vor Vertragsschluss | Dokumentation nur auf Anfrage, nur als PDF ohne Beispiele, oder erst nach Kauf einsehbar |
| Rate Limits | Klar benannte Obergrenze für Anfragen pro Zeiteinheit, dokumentiert und für den geplanten Anwendungsfall, etwa Anbindung mehrerer Linien, ausreichend dimensioniert | Rate Limits unbekannt oder erst im Störungsfall sichtbar, keine Eskalationsmöglichkeit bei Bedarf |
| Authentifizierung | Etablierte Verfahren wie OAuth 2.0 (Autorisierungs-Framework nach RFC 6749 der Internet Engineering Task Force) oder API-Schlüssel mit rollenbasierter Rechtevergabe | Ein einziger geteilter API-Schlüssel für alle Funktionen, keine Trennung nach Lese- und Schreibrechten |
Die OPC Foundation, das internationale Normungsgremium hinter dem in der Fertigung verbreiteten OPC-UA-Standard (IEC 62541), hat diesen Trend im April 2023 selbst nachvollzogen und OPC UA um eine standardisierte REST-Schnittstelle erweitert, damit IT-Anwendungen ohne spezialisierte OPC-UA-Clients auf Fertigungsdaten zugreifen können (OPC Foundation, Pressemitteilung, 17. April 2023). Laut der bereits zitierten VDMA-Studie setzen 57 Prozent der befragten Unternehmen OPC UA bereits produktiv in der Fertigung ein, 71 Prozent bewerten den Standard als hochrelevant für die eigene Digitalisierungsstrategie (VDMA, November 2025). Bei der Einordnung von MES, ERP, SCADA und MOM lohnt sich deshalb ein gesonderter Blick darauf, über welche Schnittstellenebene die Systeme tatsächlich verbunden werden sollen.
Rechtlich Ihre Daten,
technisch oft nicht
Die vertragliche und die technische Ebene der Datenhoheit fallen bei vielen MES-Verträgen auseinander. Beide müssen für eine belastbare Exit-Strategie separat geprüft werden.
Vertraglich regelt der Lizenz- oder SaaS-Vertrag, wem die im MES erzeugten Produktionsdaten gehören und wer sie zu welchen Bedingungen nutzen darf. In den meisten am Markt üblichen Verträgen bleibt das Nutzungsrecht an den eigenen Betriebsdaten beim Kunden, während der Anbieter ein Recht zur Verarbeitung im Rahmen der vereinbarten Leistung erhält. Diese Zusicherung ist jedoch nur so viel wert wie ihre technische Umsetzung: Technisch entscheidet allein die Frage, ob und in welchem Format die Daten tatsächlich exportierbar sind, ob dieses Recht bereits vertraglich vollständig durchsetzbar ist. Ein Vertrag, der Datenhoheit zusichert, aber keinen dokumentierten Exportweg nennt, verschiebt das Risiko faktisch auf den Ernstfall.
Der EU Data Act (Verordnung (EU) 2023/2854, anwendbar seit 12. September 2025) verschiebt diese Balance zusätzlich zugunsten der Nutzer vernetzter Geräte und Systeme: Er verpflichtet Hersteller vernetzter Produkte, Nutzern und von ihnen benannten Dritten Zugang zu den dabei erzeugten Daten zu gewähren, in der Regel unentgeltlich und in einem strukturierten, gängigen, maschinenlesbaren Format (Amt für Veröffentlichungen der Europäischen Union, EUR-Lex, Verordnung (EU) 2023/2854, 2024). Für ein MES als datengenerierendes System in der Fertigung ist relevant, ob der eigene Anbieter diese Anforderung bereits proaktiv erfüllt oder ob sie erst im Streitfall eingefordert werden müsste. Eine strukturierte Anforderungsaufnahme dazu gehört in ein MES-Lastenheft ebenso wie in den RFI-Fragebogen für MES-Anbieter.
Hinweis: Verbindlich ist allein Ihr Vertrag. Die genannten Fristen und Rechtsgrundlagen sind der öffentlich dokumentierte Stand.
Warum das kein
theoretisches Risiko ist
Vendor-Lock-in bezeichnet die Situation, in der ein Wechsel des Anbieters wirtschaftlich oder technisch so aufwendig wird, dass er faktisch nicht mehr frei entschieden werden kann. Bei einem MES entsteht dieses Risiko selten plötzlich, sondern über Jahre, durch fehlende Exportfunktionen, proprietäre Datenformate und tief individualisierte Anpassungen ohne Dokumentation.
Ein öffentlich dokumentiertes Beispiel für eine geplante, langfristig angekündigte Auslauf-Situation ist die Produktlinie SAP ME und SAP MII (Manufacturing Execution respektive Manufacturing Integration and Intelligence). Laut der von SAP selbst gepflegten Wartungsübersicht (SAP-Hinweis 2894103, „Maintenance for SAP Manufacturing Integration and Intelligence Maintenance Term", sowie die SAP Product Availability Matrix) ist für SAP MII 15.5 aktuell kein Release über Ende 2027 hinaus geplant, eine mögliche Verlängerung des Wartungsfensters bis 2030 wird laut SAP-Angaben geprüft. Diese Angabe wird hier ohne Wertung wiedergegeben, sie zeigt lediglich, dass auch etablierte, marktführende MES-Plattformen planbare Auslaufdaten haben können, auf die sich Fertigungsunternehmen frühzeitig einstellen sollten, siehe dazu ausführlich SAP ME und SAP MII im Überblick und allgemein Anbieter insolvent oder Support-Ende.
Die Konsequenz für die Auswahl eines neuen Systems ist unabhängig vom konkreten Anbieter dieselbe: Je offener die API und je klarer die Datenhoheit vertraglich und technisch geregelt ist, desto planbarer wird ein späterer Wechsel, geplant oder ungeplant. Eine Bitkom-Studie zur digitalen Souveränität deutscher Unternehmen zeigt die Größenordnung der grundsätzlichen Abhängigkeit von externen Technologieanbietern: 96 Prozent der befragten Unternehmen ab 20 Beschäftigten importieren digitale Technologien und Services von außen, nur 25 Prozent treten selbst als Anbieter für andere Unternehmen auf (Bitkom, Studienbericht „Digitale Souveränität 2025", 28. Februar 2025, 603 befragte Unternehmen). Das MES ist in vielen Fertigungsbetrieben eine der am tiefsten integrierten dieser importierten Technologien, siehe auch MES wechseln, Migration und Kosten für die praktischen Aufwände eines Wechsels.
Offene APIs lösen nicht
jedes Problem, sie schaffen auch neue
API-Offenheit ist eine notwendige, aber keine hinreichende Eigenschaft. Eine geöffnete Schnittstelle vergrößert zugleich die Angriffsfläche eines MES und bringt einen Performance-Kompromiss mit sich, der vor der Entscheidung eingeplant werden sollte.
Sicherheit: Jeder zusätzliche, dokumentierte Zugriffsweg ist zugleich ein zusätzlicher potenzieller Angriffspunkt auf die Fertigungsdaten und, bei schreibenden Rechten, auf die Produktionssteuerung selbst. Die internationale Normenreihe IEC 62443 zur Sicherheit industrieller Automatisierungs- und Steuerungssysteme adressiert genau diesen Zielkonflikt zwischen Vernetzung und Angriffsfläche und verlangt unter anderem eine strikte Trennung von Netzwerkzonen sowie eine rollenbasierte Zugriffskontrolle, wie sie auch in Abschnitt 4 dieser Seite als Prüfpunkt für die API-Authentifizierung beschrieben ist. Eine offene API ohne die dort genannten Mindeststandards, etwa OAuth 2.0 und getrennte Lese-/Schreibrechte, verschiebt das Risiko von einem geschlossenen, aber unpraktischen System auf ein offenes, aber schlecht abgesichertes System, was in der Praxis kein Fortschritt ist.
Performance: HTTP-basierte Schnittstellen wie REST und OData sind für den Datenaustausch mit IT-Systemen konzipiert, nicht für zeitkritische Steuerungskommunikation auf der Feldebene. Die OPC Foundation hat die REST-Erweiterung von OPC UA 2023 ausdrücklich als Ergänzung für IT-Anwendungen eingeführt, die ohne spezialisierte OPC-UA-Clients auf Daten zugreifen wollen, während zeitkritische Kommunikation zwischen Steuerung und Feldgeräten weiterhin über das binäre OPC-UA-Protokoll läuft (OPC Foundation, Pressemitteilung, 17. April 2023). Für ein MES bedeutet das: Eine offene REST-API eignet sich für Auswertungen, ERP-Anbindungen und Reporting, aber nicht als Ersatz für die harte Echtzeitanbindung von Maschinensteuerungen, die über andere Protokollebenen läuft, siehe dazu auch die Einordnung von MES, ERP, SCADA und MOM.
Rechtliche Grenze: Auch der EU Data Act gewährt keinen unbegrenzten Zugriff. Die Verordnung (EU) 2023/2854 erlaubt es Herstellern, die Herausgabe von Daten einzuschränken, soweit diese als Geschäftsgeheimnis gelten und besondere Schutzmaßnahmen vereinbart werden, bevor sie offengelegt werden (Amt für Veröffentlichungen der Europäischen Union, EUR-Lex, Verordnung (EU) 2023/2854, 2024). Für Fertigungsunternehmen heißt das, dass „gesetzlicher Datenzugang" kein Freifahrtschein auf jede Information ist, sondern selbst wieder Verhandlungssache zwischen Nutzungsrecht und Geheimnisschutz des Herstellers bleiben kann.
Fünf Bausteine,
die vor der Unterschrift geklärt gehören
Eine Exit-Strategie ist keine Absichtserklärung, sondern eine Liste konkreter, vertraglich verankerter Punkte. Am wirkungsvollsten lassen sich diese Punkte vor Vertragsschluss verhandeln, danach sinkt die Verhandlungsposition des Kunden erfahrungsgemäß deutlich.
Datenexport vor Vertragsschluss klären
Nicht erst im Vertrag zusichern lassen, sondern vor der Unterschrift testweise durchführen: Welche Datenobjekte, in welchem Format, mit welchem Aufwand exportierbar sind, gehört als Nachweis in die Anbieterauswahl.
Exportformate vertraglich festschreiben
Offene, dokumentierte Formate wie CSV, XML oder ein vollständiger Datenbankexport statt eines proprietären Binärformats, inklusive Metadaten, Zeitstempeln und Verknüpfungen zwischen Datensätzen.
Übergangsfristen definieren
Eine klar befristete Frist nach Vertragsende, in der der Anbieter weiter Lesezugriff, Fehlerbehebung und begrenzten Support liefert, mit Preisbindung für diese Übergangsleistung.
Know-how-Transfer vereinbaren
Dokumentation aller kundenspezifischen Anpassungen, Schnittstellenkonfigurationen und Konfigurationsstände als eigenständige, prüfbare Vertragsleistung, nicht als vage Zusage im Kleingedruckten.
Zwischenspeicherung einplanen
Eine eigene, vom Anbieter unabhängige Umgebung für exportierte Daten während eines Wechsels, damit die Datenhoheit auch während der Übergangsphase technisch, nicht nur vertraglich, gesichert bleibt.
Diese fünf Bausteine ersetzen keine juristische Prüfung des Einzelvertrags, sie strukturieren aber, welche Fragen in einem RFI-Fragebogen für MES-Anbieter und im späteren Vertragsentwurf konkret adressiert werden sollten. Wer bereits mitten im Betrieb steht und einen Wechsel prüft, findet die praktischen Abläufe dazu unter MES wechseln, Migration und Kosten.
Von der Checkliste
zur Klausel im Vertragstext
Die fünf Bausteine aus dem vorherigen Abschnitt lassen sich in konkrete Klausel-Bausteine übersetzen. Die folgende Tabelle zeigt, welche Regelungsrichtung je Baustein sinnvoll ist und warum, als Vorlage für das eigene Vertrags- oder RFI-Dokument, nicht als Rechtsberatung.
| Klausel-Baustein | Sinnvolle Regelungsrichtung | Warum wichtig |
|---|---|---|
| Exportformat | Benennung konkreter, offener Formate (z. B. CSV, XML, strukturierter Datenbankexport) statt „marktüblicher Formate" | Vage Formulierungen lassen dem Anbieter Spielraum, ein kaum nutzbares Format zu liefern |
| Exportumfang | Ausdrücklich inklusive Metadaten, Zeitstempeln, Verknüpfungen zwischen Datensätzen und historischen Daten, nicht nur aktueller Bestand | Ohne diese Präzisierung drohen isolierte Rohdaten ohne Kontext |
| Verfügbarkeit | Export als jederzeit abrufbare Leistung während der Vertragslaufzeit, nicht nur als Zusage für den Kündigungsfall | Ermöglicht einen Test der Exportqualität lange vor einem tatsächlichen Wechsel |
| Kosten | Klare Regelung, ob und in welcher Höhe der Export bepreist ist, mit Deckelung für den Kündigungsfall | Verhindert eine kurzfristige Verhandlung unter Zeitdruck bei Vertragsende |
| Frist und Löschung | Konkrete Herausgabefrist nach Kündigung sowie eine erst danach greifende Löschfrist beim Anbieter | Ohne Reihenfolge droht Datenverlust vor vollständigem Export |
Der praktische Unterschied ist erheblich: Nach Erfahrungswerten aus Sectorlens-Auswahl- und Wechselprojekten seit 2022 lässt sich ein vollständiger Datenexport bei einem MES mit dokumentierter, offener Exportschnittstelle in der Regel innerhalb weniger Tage durchführen und prüfen. Fehlt eine solche Schnittstelle und muss der Export erst manuell aus Datenbanktabellen oder proprietären Berichten rekonstruiert werden, verlängert sich dieser Aufwand nach denselben Erfahrungswerten häufig auf mehrere Wochen zusätzlicher Arbeit, zumeist gebunden an externe Dienstleistung durch den bisherigen Anbieter selbst. Diese Differenz ist der eigentliche wirtschaftliche Kern von Vendor-Lock-in, siehe dazu auch MES wechseln, Migration und Kosten.
Zehn Fragen
für das nächste Anbietergespräch
Diese Fragen lassen sich direkt in ein Anbietergespräch oder eine RFI-Runde übernehmen. Sie zielen bewusst auf überprüfbare, dokumentierte Antworten statt auf allgemeine Zusicherungen.
| Nr. | Frage an den Anbieter | Worauf die Antwort hindeuten sollte |
|---|---|---|
| 1 | Ist die API-Dokumentation vor Vertragsschluss frei einsehbar? | Ja, ohne NDA, im OpenAPI-Format |
| 2 | Welcher Schnittstellenstandard wird unterstützt, REST, OData, beides? | Konkrete, benannte Standards statt „individuell nach Bedarf" |
| 3 | Wie hoch sind die Rate Limits pro Zeiteinheit, und sind sie erweiterbar? | Konkrete Zahl, dokumentiert, mit Eskalationsweg |
| 4 | Welches Authentifizierungsverfahren kommt zum Einsatz? | OAuth 2.0 oder vergleichbar, mit rollenbasierten Rechten |
| 5 | In welchen Formaten kann ich alle meine Daten jederzeit exportieren? | Offene Formate, nicht nur auf Kündigung beschränkt |
| 6 | Kann ich den vollständigen Export vor Vertragsschluss testen? | Ja, im Rahmen eines Proof of Concept |
| 7 | Wie lange ist die vertragliche Übergangsfrist nach Kündigung? | Konkrete Monatsangabe, nicht „nach Absprache" |
| 8 | Wer trägt die Kosten für Support während der Übergangsfrist? | Klar geregelt, idealerweise preisgebunden |
| 9 | Wie wird kundenspezifische Konfiguration dokumentiert? | Laufend gepflegtes Dokument, kein einmaliges Übergabeprotokoll |
| 10 | Was passiert vertraglich mit meinen Daten, wenn der Vertrag endet? | Explizite Löschfristen und vorherige Herausgabepflicht |
Antworten, die ausweichend bleiben oder erst nach Vertragsschluss konkretisiert werden sollen, sind selbst ein Signal. Eine strukturierte Fit-Analyse zu diesen zehn Fragen lässt sich auf Basis der öffentlich verfügbaren Informationen eines Anbieters vorbereiten, bevor das Gespräch überhaupt stattfindet.
API, Exit-Strategie und Datenhoheit:
20 Fragen aus der Praxis
Antworten, die auch ohne den Rest dieser Seite verständlich sind.
Was bedeutet Datenhoheit bei einem MES konkret?
Datenhoheit beschreibt die Fähigkeit, jederzeit vollständig und in nutzbarer Form auf die im MES erzeugten Daten zugreifen zu können, unabhängig davon, ob der Vertrag mit dem Anbieter noch läuft. Sie hat eine vertragliche Ebene, wer laut Lizenz- oder SaaS-Vertrag über die Daten verfügen darf, und eine technische Ebene, ob diese Daten tatsächlich exportierbar und in ein anderes System überführbar sind. Beide Ebenen müssen zusammenpassen, denn eine vertragliche Zusicherung ohne technischen Exportweg ist im Ernstfall wenig wert. Für Fertigungsunternehmen betrifft das insbesondere Auftragsdaten, Maschinenzustände, Prüfergebnisse und Rückverfolgbarkeitsdaten, die oft über Jahre im MES gesammelt werden.
Wem gehören die im MES erzeugten Produktionsdaten rechtlich?
In den meisten marktüblichen MES-Verträgen bleibt das Nutzungsrecht an den eigenen Betriebsdaten beim Kunden, während der Anbieter ein Recht zur Verarbeitung im Rahmen der vereinbarten Leistung erhält. Verbindlich ist dabei allein der jeweils geschlossene Vertrag, allgemeine Aussagen können eine juristische Prüfung des Einzelfalls nicht ersetzen. Zusätzlich verpflichtet der EU Data Act (Verordnung (EU) 2023/2854, anwendbar seit 12. September 2025) Hersteller vernetzter Produkte und Systeme, Nutzern Zugang zu den dabei erzeugten Daten zu gewähren. Für ein MES als datengenerierendes System bedeutet das eine zusätzliche gesetzliche Grundlage neben der vertraglichen Regelung, deren praktische Umsetzung je nach Anbieter unterschiedlich weit fortgeschritten ist.
Was ist eine offene API bei einem MES, und warum ist das ein Auswahlkriterium?
Eine Application Programming Interface, kurz API, ist die definierte Schnittstelle, über die andere Systeme lesend oder schreibend auf Daten und Funktionen eines MES zugreifen können. Offen ist eine API, wenn sie auf verbreiteten Standards wie REST oder OData basiert, öffentlich dokumentiert ist und nicht auf ein einziges, herstellereigenes Format beschränkt bleibt. Als Auswahlkriterium ist sie relevant, weil sie bestimmt, wie einfach sich ERP-Anbindungen, Auswertungen und spätere Migrationen umsetzen lassen, mit oder ohne den ursprünglichen Anbieter. Ohne offene API ist ein Fertigungsunternehmen für jede Integration und jeden Datenexport dauerhaft auf den Hersteller angewiesen.
Was unterscheidet REST und OData als Schnittstellenstandard?
REST, Representational State Transfer, ist ein Architekturstil für zustandslose Schnittstellen über HTTP, bei dem jede Ressource über eine eigene, klar benannte Adresse angesprochen wird. OData, Open Data Protocol, baut auf REST auf und standardisiert zusätzlich, wie Daten abgefragt, gefiltert und in Beziehung gesetzt werden können, es ist als ISO/IEC 20802 durch OASIS und ISO/IEC JTC 1 international genormt. Für ein MES bedeutet ein OData-Anschluss meist, dass komplexe Abfragen, etwa nach Chargen über mehrere Prüfschritte hinweg, ohne individuelle Zusatzentwicklung möglich sind. Beide Standards sind weit verbreitet und gut dokumentierbar, welcher besser passt, hängt vom konkreten Integrationsbedarf ab, insbesondere bei einer Anbindung an SAP-Systeme.
Worauf sollte ich bei der API-Dokumentation eines MES-Anbieters achten?
Wichtig ist, dass die Dokumentation vor Vertragsschluss frei zugänglich ist, im Idealfall maschinenlesbar nach der OpenAPI-Spezifikation, mit konkreten Beispielaufrufen und Antwortschemata statt nur einer Beschreibung in Fließtext. Eine Dokumentation, die erst nach Kauf oder nur auf gesonderte Anfrage einsehbar ist, lässt sich vor Vertragsschluss nicht prüfen und erschwert eine belastbare technische Bewertung. Sinnvoll ist außerdem, in einem Proof of Concept zu testen, ob die dokumentierten Endpunkte tatsächlich so funktionieren wie beschrieben, da Dokumentation und Implementierung in der Praxis auseinanderfallen können. Fehlt eine öffentlich einsehbare Dokumentation vollständig, ist das selbst bereits ein Warnsignal für den Reifegrad der Schnittstelle.
Was sind Rate Limits, und warum können sie zum Problem werden?
Rate Limits sind vom Anbieter festgelegte Obergrenzen dafür, wie viele Anfragen eine API in einem bestimmten Zeitraum verarbeitet, etwa pro Minute oder Stunde. Sie schützen das System vor Überlastung, können aber zum Problem werden, wenn mehrere Fertigungslinien, Dashboards oder ein ERP-System gleichzeitig auf dieselbe Schnittstelle zugreifen und die Grenze unbekannt oder zu niedrig dimensioniert ist. Besonders kritisch wird es, wenn Rate Limits erst im laufenden Betrieb durch Fehlermeldungen sichtbar werden, statt vorab dokumentiert zu sein. Vor Vertragsschluss sollte deshalb konkret erfragt werden, wie hoch die Limits für den geplanten Anwendungsfall sind und ob sie bei Bedarf erweiterbar sind.
Welche Authentifizierungsverfahren sind bei MES-APIs üblich?
Verbreitet sind OAuth 2.0, ein Autorisierungs-Framework, das von der Internet Engineering Task Force in RFC 6749 spezifiziert wurde, sowie API-Schlüssel in Kombination mit rollenbasierter Rechtevergabe. Wichtig ist, dass sich Lese- und Schreibrechte getrennt vergeben lassen, damit nicht jede angebundene Anwendung automatisch vollen Zugriff auf alle Daten und Funktionen erhält. Ein einziger, geteilter API-Schlüssel für alle Zugriffe ohne Rechteabstufung gilt als unzureichend, sowohl aus Sicherheits- als auch aus Governance-Sicht. Bei sicherheitskritischen oder regulierten Fertigungsumgebungen sollte zusätzlich geprüft werden, ob sich Zugriffe protokollieren und nachträglich auswerten lassen.
Was bedeutet Vendor-Lock-in bei einem MES konkret?
Vendor-Lock-in bezeichnet die Situation, in der ein Wechsel des Anbieters wirtschaftlich oder technisch so aufwendig wird, dass er faktisch nicht mehr frei entschieden werden kann. Bei einem MES entsteht dieses Risiko meist schrittweise, durch fehlende Exportfunktionen, proprietäre Datenformate ohne dokumentierte Struktur und tief individualisierte Anpassungen, die nirgendwo außerhalb des Systems dokumentiert sind. Ein hoher Individualisierungsgrad ist dabei nicht per se problematisch, entscheidend ist, ob diese Anpassungen dokumentiert und übertragbar sind. Vendor-Lock-in lässt sich nicht vollständig vermeiden, aber durch offene Schnittstellen, klare Exportformate und vertragliche Exit-Regelungen deutlich reduzieren.
Was hat der EU Data Act mit meinem MES zu tun?
Der EU Data Act, Verordnung (EU) 2023/2854, ist seit dem 12. September 2025 anwendbar und regelt erstmals branchenübergreifend, welche Zugriffsrechte Nutzer vernetzter Geräte und Systeme auf die dabei erzeugten Daten haben. Für ein MES ist relevant, dass es als datenerzeugendes System in der Fertigung grundsätzlich in den Anwendungsbereich fallen kann, insbesondere wenn es an vernetzte Maschinen und Sensoren angebunden ist. Die Verordnung verpflichtet Hersteller, Nutzern in der Regel unentgeltlichen Zugang zu den erzeugten Daten in einem strukturierten, maschinenlesbaren Format zu gewähren. Ob und in welchem Umfang der eigene MES-Anbieter diese Anforderung bereits umsetzt, ist eine Frage, die sich direkt im Anbietergespräch klären lässt.
Welche Datenexportformate sollte ein MES-Anbieter vertraglich zusichern?
Sinnvoll sind offene, dokumentierte Formate wie CSV, XML oder ein vollständiger Datenbankexport, statt eines proprietären Binärformats, das nur die eigene Software lesen kann. Für Fertigungs-, Qualitäts- und Rückverfolgbarkeitsdaten sollte der Export auch zugehörige Metadaten, Zeitstempel und Verknüpfungen zwischen Datensätzen umfassen, nicht nur isolierte Rohwerte. Wichtig ist außerdem, den Export vertraglich als jederzeit verfügbare Leistung zu definieren, nicht nur als Zusage für den Kündigungsfall, damit sich die Praxistauglichkeit bereits vor dem Ernstfall testen lässt. Ohne eine solche Testmöglichkeit zeigt sich häufig erst im Wechselfall, dass ein zugesagtes Format in der Praxis unvollständig oder aufwendig nachzubearbeiten ist.
Was zeigt das Beispiel SAP ME/MII für die Exit-Planung?
Laut der von SAP selbst gepflegten Wartungsübersicht ist für SAP MII 15.5 aktuell kein Release über Ende 2027 hinaus geplant, eine mögliche Verlängerung wird laut öffentlich zugänglichen SAP-Angaben geprüft. Das Beispiel wird hier ohne Wertung des Produkts genannt, es zeigt lediglich, dass auch etablierte, marktführende MES-Plattformen planbare Auslaufdaten für einzelne Produktlinien haben können. Für Fertigungsunternehmen folgt daraus die Konsequenz, Wartungsfristen der eigenen Systemlandschaft regelmäßig zu prüfen, unabhängig vom konkret eingesetzten Anbieter. Verbindlich für den eigenen Fall sind stets die individuellen Vertragsunterlagen und die aktuelle Produktkommunikation des jeweiligen Herstellers.
Was gehört in eine Exit-Strategie-Checkliste vor Vertragsschluss?
Fünf Bausteine bilden das Grundgerüst: eine vor Vertragsschluss getestete Klärung des Datenexports, vertraglich festgeschriebene offene Exportformate, eine klar befristete Übergangsfrist mit Preisbindung, eine vertraglich verankerte Pflicht zum Know-how-Transfer sowie eine geplante, vom Anbieter unabhängige Zwischenspeicherung für den Übergangszeitraum. Diese Punkte lassen sich am wirkungsvollsten vor der Unterschrift verhandeln, weil sich die Verhandlungsposition des Kunden nach der Einführung erfahrungsgemäß deutlich verschlechtert. Eine strukturierte Erfassung dieser Punkte gehört sowohl in ein MES-Lastenheft als auch in den RFI-Fragebogen an potenzielle Anbieter. Ohne diese Vorabklärung zeigt sich der tatsächliche Aufwand eines Wechsels häufig erst dann, wenn er bereits unter Zeitdruck stattfinden muss.
Wie lange sollte eine Übergangsfrist bei Vertragsende mindestens sein?
Eine pauschale Mindestdauer lässt sich seriös nicht nennen, da sie von Systemgröße, Datenvolumen und Komplexität der Integrationen abhängt. Als Orientierung gilt, dass ein geplanter MES-Wechsel von der Entscheidung bis zur Abschaltung des Altsystems nach Erfahrungswerten aus Sectorlens-Auswahlprojekten typischerweise mehrere Monate bis über ein Jahr dauert, eine Übergangsfrist sollte diesen Zeitraum realistisch abdecken, nicht nur symbolisch wenige Wochen umfassen. Wichtiger als eine feste Zahl ist, dass die Frist überhaupt vertraglich fixiert und mit einer Preisbindung für die Übergangsleistung verknüpft ist, damit der Anbieter keinen wirtschaftlichen Anreiz hat, den Ausstieg zu verzögern oder zu verteuern. Verbindlich ist stets die im Einzelvertrag vereinbarte Frist.
Was ist Know-how-Transfer im Kontext eines MES-Wechsels?
Know-how-Transfer bezeichnet die strukturierte Übergabe von Wissen über kundenspezifische Anpassungen, Schnittstellenkonfigurationen und Konfigurationsstände, das über die reinen Rohdaten hinausgeht. Ohne diesen Transfer bleibt selbst ein vollständiger Datenexport nur bedingt nutzbar, weil unklar ist, welche Individualisierungen wie zustande gekommen sind und warum bestimmte Einstellungen so gewählt wurden. In der Praxis wird dieser Transfer am wirkungsvollsten als eigenständige, prüfbare Vertragsleistung vereinbart, etwa als jährlich aktualisierte Dokumentation, statt als vage Zusage im Kleingedruckten. Fehlt Know-how-Transfer, verlängert sich die Zeit bis zu einer stabilen Übergangslösung im Wechselfall erheblich, weil Wissen erst mühsam rekonstruiert werden muss.
Wie prüfe ich die Offenheit einer API praktisch, vor Vertragsschluss?
Am belastbarsten ist ein Proof of Concept, bei dem ein konkreter Anwendungsfall, etwa der Export eines definierten Datensatzes oder die Anbindung eines Testsystems, tatsächlich über die dokumentierte API durchgeführt wird, statt sich auf mündliche Zusagen zu verlassen. Ergänzend lohnt sich ein Blick in die öffentlich zugängliche API-Dokumentation, um zu prüfen, ob sie vollständig, aktuell und mit Beispielen versehen ist. Die zehn Fragen aus dem Praxisabschnitt dieser Seite, etwa zu Schnittstellenstandard, Rate Limits und Authentifizierung, lassen sich direkt als Grundlage für ein solches Gespräch nutzen. Anbieter, die auf konkrete technische Fragen ausweichend antworten oder auf eine spätere Klärung nach Vertragsschluss verweisen, sollten diese Antwort selbst als Signal werten.
Ist ein MES mit offener API automatisch teurer?
Nicht zwangsläufig. Der Preis eines MES hängt von vielen Faktoren ab, etwa Funktionsumfang, Anzahl der Arbeitsplätze und Implementierungsaufwand, API-Offenheit ist dabei nur ein Kriterium unter mehreren und keine automatische Preistreiber-Eigenschaft. In manchen Fällen kann eine offene, standardbasierte Schnittstelle sogar Integrationskosten senken, weil weniger individuelle Zusatzentwicklung nötig ist, um das MES an ERP-System oder Maschinenpark anzubinden. Ein direkter Preisvergleich zwischen mehreren Anbietern unter Berücksichtigung des jeweiligen API-Umfangs liefert deshalb belastbarere Aussagen als eine pauschale Annahme zu Mehrkosten. Details zu Kostenstrukturen im MES-Markt finden sich in der gesonderten Übersicht zu MES-Kosten.
Welche Sicherheitsrisiken bringt eine offene API bei einem MES mit sich?
Jeder zusätzliche, dokumentierte Zugriffsweg vergrößert zugleich die potenzielle Angriffsfläche des Systems, insbesondere wenn die API auch schreibende Rechte auf Produktionsdaten oder Steuerungsparameter erlaubt. Die internationale Normenreihe IEC 62443 zur Sicherheit industrieller Automatisierungs- und Steuerungssysteme adressiert diesen Zielkonflikt zwischen Vernetzung und Angriffsfläche und verlangt unter anderem eine strikte Netzwerksegmentierung sowie rollenbasierte Zugriffskontrolle. Praktisch bedeutet das, dass eine offene API ohne Mindeststandards wie OAuth 2.0, getrennte Lese- und Schreibrechte sowie Protokollierung von Zugriffen ein eigenständiges Risiko darstellt, unabhängig davon, wie gut sie technisch dokumentiert ist. API-Offenheit und IT-Sicherheit sind deshalb kein Gegensatz, sondern müssen als zusammengehöriges Prüfpaar bewertet werden.
Ist eine REST- oder OData-Schnittstelle für zeitkritische Steuerungsprozesse im MES geeignet?
Grundsätzlich nicht in vollem Umfang. HTTP-basierte Schnittstellen wie REST und OData sind für den Datenaustausch mit IT-Systemen, etwa Reporting, ERP-Anbindung oder Auswertungen, konzipiert, nicht für harte Echtzeitanforderungen auf der Feldebene. Die OPC Foundation hat ihre REST-Erweiterung von OPC UA 2023 ausdrücklich als IT-nahe Ergänzung eingeführt, während zeitkritische Kommunikation zwischen Steuerung und Feldgeräten weiterhin über das binäre OPC-UA-Protokoll läuft. Für die Auswahl eines MES bedeutet das, bei der Anbindung von Maschinensteuerungen genau zu unterscheiden, welche Schnittstellenebene für welchen Zweck tatsächlich zum Einsatz kommt, statt „offene API" pauschal mit Echtzeitfähigkeit gleichzusetzen.
Muss ein MES-Anbieter laut EU Data Act auch Geschäftsgeheimnisse offenlegen?
Nein, nicht uneingeschränkt. Der EU Data Act, Verordnung (EU) 2023/2854, verpflichtet Hersteller vernetzter Produkte grundsätzlich zur Herausgabe der erzeugten Daten, erlaubt es ihnen aber, die Offenlegung von Informationen einzuschränken, die als Geschäftsgeheimnis gelten, sofern vorher besondere Schutzmaßnahmen vereinbart werden. Für Fertigungsunternehmen bedeutet das, dass der gesetzliche Datenzugang kein automatischer Anspruch auf jede vom MES verarbeitete Information ist, sondern selbst wieder Verhandlungsgegenstand zwischen Nutzungsrecht und Geheimnisschutz des Herstellers sein kann. In der Praxis lohnt sich deshalb dieselbe vertragliche Sorgfalt wie bei jeder anderen Exit-Klausel, unabhängig davon, was der Data Act ohnehin vorschreibt.
Wie sollte eine Vertragsklausel zum Datenexport konkret formuliert sein?
Belastbar ist eine Klausel, die mindestens fünf Punkte konkret benennt: das Exportformat, den vollständigen Umfang inklusive Metadaten und Zeitstempeln, die jederzeitige Verfügbarkeit während der Vertragslaufzeit, eine klare Kostenregelung mit Deckelung für den Kündigungsfall sowie die Reihenfolge von Herausgabe- und Löschfrist. Vage Formulierungen wie „marktübliche Formate" oder „auf Anfrage" lassen dem Anbieter erheblichen Spielraum und sind im Streitfall schwer durchsetzbar. Nach Erfahrungswerten aus Sectorlens-Projekten lässt sich ein Export bei einem so vertraglich abgesicherten, dokumentierten Vorgehen meist innerhalb weniger Tage durchführen, während ein unzureichend geregelter Export häufig mehrere Wochen zusätzlicher Abstimmung mit dem bisherigen Anbieter bindet. Verbindlich bleibt in jedem Fall die im Einzelvertrag tatsächlich vereinbarte Formulierung.
API-Offenheit und Datenhoheit prüfen.
Unsicher, wie gut Sie abgesichert sind?
Diese Seite zeigt die Kriterien, an denen sich API-Offenheit und Datenhoheit erkennen lassen. Für die konkrete Bewertung eines Angebots oder eines bestehenden Vertrags braucht es einen Blick auf Ihren Einzelfall.
Erste Einschätzung passender Anbieter
URL eingeben, die KI analysiert Ihre Fertigung und Systemlandschaft anhand öffentlicher Daten und gleicht sie gegen über 80 Merkmale mit dem aktuellen MES-Anbietermarkt ab, inklusive Hinweisen zu API-Offenheit je Anbieterprofil.
- Shortlist passender Anbieter mit Match-Score
- Basis für eine vertiefte Schnittstellen-Prüfung
- Kein Formular, keine Registrierung
Lastenheft mit API- und Exit-Anforderungen
Anforderungs-Workshop und Lastenheft aus über 150 Anforderungen, das API-Standards, Datenexportformate und Exit-Klauseln als feste Anforderungsblöcke enthält und im Anbieter-Dialog direkt einsetzbar ist.
- Entscheidungsmatrix mit Schnittstellen-Kriterien
- Moderierter Dialog mit ausgewählten Anbietern
- Basis für den späteren Vertragsentwurf
Zweitmeinung zu Exit-Klauseln im Angebot
Gemeinsame Einordnung, welche Exit- und Datenexport-Regelungen in einem vorliegenden Anbieterangebot bereits enthalten sind und wo Lücken bestehen, auf Basis von über 50 Projekten seit 2022, herstellerneutral und ohne Provision.
- Einschätzung Ihrer aktuellen Vertragsentwürfe
- Priorisierung, was vor Unterschrift nachverhandelt werden sollte
- 30 Minuten Erstgespräch kostenlos und unverbindlich
API-Offenheit und Datenhoheit.
Prüfen Sie jetzt, welche Anbieter passen.
Geben Sie Ihre Unternehmens-URL ein. Die Analyse zeigt Ihnen in wenigen Minuten, welche MES-Anbieter zu Ihrer Fertigung passen, inklusive einer Einordnung zu Schnittstellenoffenheit und Datenexport je Anbieterprofil.
