Den erwarteten Zielzustand festlegen
Beginnen Sie mit dem Geschäftsvorgang, den die Integration unterstützen soll. Wird ein Artikel angelegt, eine Stückliste geändert oder ein Dokument für die Produktion bereitgestellt? Legen Sie gemeinsam mit Engineering, ERP-Verantwortlichen und Betrieb fest, welche Daten im Zielsystem erscheinen müssen. Dazu gehören die betroffene Produktkennung, die freigegebene Revision, die relevanten Attribute und gegebenenfalls der Gültigkeitszeitpunkt. Ein erfolgreich übertragener Datensatz ist erst dann ein fachlicher Erfolg, wenn der vereinbarte Zielzustand nachweisbar erreicht wurde. Diese Definition gehört vor der technischen Umsetzung in den Projektumfang.
Versand, Verarbeitung und fachliche Freigabe unterscheiden
Eine Transportbestätigung beantwortet zunächst eine technische Frage: Hat der nächste Verarbeitungsschritt die Nachricht erhalten? Sie belegt nicht automatisch, dass alle fachlichen Prüfungen im ERP bestanden wurden oder die Änderung dort bereits verwendet werden darf. Beschreiben Sie deshalb die für Ihren Prozess relevanten Zustände ausdrücklich. Ein einfaches Modell kann zwischen bereitgestellt, in Verarbeitung, übernommen und abgelehnt unterscheiden. Welche Zustände tatsächlich benötigt werden, hängt von der Architektur und den Freigabeprozessen ab. Entscheidend ist, dass Fachbereich und IT dieselbe Bedeutung mit einem Status verbinden.
Mit einer konkreten Revision prüfen
Ein fiktives Beispiel macht die Abnahme greifbar: Im PLM wird Revision C einer Baugruppe freigegeben. Im ERP liegt bisher Revision B vor. Der Test protokolliert zunächst die Ausgangslage in beiden Systemen. Anschließend wird genau die vorgesehene Änderung übertragen. Die Gegenprüfung erfolgt im ERP anhand von Produktkennung, Revision und den vereinbarten Stücklistenpositionen. Falls eine Änderung erst später wirksam werden soll, wird auch dieser Zeitpunkt geprüft. Eine grüne Meldung im Integrationsdienst ersetzt den Blick auf das fachliche Ergebnis nicht. Das Beispiel beschreibt eine Prüfmethode und keinen Kundenfall.
Eine Ablehnung bewusst auslösen
Zum Abnahmetest gehört ein geplanter Fehlerfall. Verwenden Sie dafür eine freigegebene Testumgebung und einen Testdatensatz, der eine bekannte Zielprüfung verletzt, etwa einen fehlenden Pflichtwert. Dokumentieren Sie vorab das erwartete Verhalten. Bleibt der bisher gültige ERP-Stand erhalten? Ist die Ablehnung dem richtigen Produkt und Übertragungsvorgang zugeordnet? Kann die verantwortliche Rolle den Grund verstehen und die weitere Bearbeitung übernehmen? Ein technischer Logeintrag allein hilft dem Fachbereich wenig, wenn er weder auffindbar ist noch eine klare Zuständigkeit auslöst.
Wiederholungen ohne doppelte Wirkung planen
Nach einer Korrektur oder einer Unterbrechung wird ein Vorgang möglicherweise erneut gesendet. Testen Sie deshalb, wie die Schnittstelle dieselbe Änderung ein zweites Mal behandelt. Ziel ist ein vereinbartes, nachvollziehbares Verhalten: Der zweite Versuch darf beispielsweise nicht unbemerkt eine zweite Stücklistenposition erzeugen. Dafür müssen Projektteams festlegen, wie ein Vorgang wiedererkannt wird und welche Änderungen erneut verarbeitet werden dürfen. Die konkrete technische Lösung hängt von beiden Systemen ab. Automatische Wiederholung ist kein Ersatz für diese fachliche Festlegung und gehört mit ihren Grenzen in die Abnahme.
Die Reihenfolge von Änderungen berücksichtigen
Besonders aufschlussreich ist ein Test mit zwei aufeinanderfolgenden Revisionen. Wird Revision D bereits verarbeitet, während ein älterer Versuch für Revision C noch offen ist, darf dessen spätere Wiederholung nicht unbemerkt den neueren Stand überschreiben. Vereinbaren Sie, ob solche Vorgänge verworfen, angehalten oder zur manuellen Klärung gegeben werden. Prüfen Sie außerdem zusammengehörige Daten: Eine Stückliste kann von Artikeln, Einheiten oder Dokumenten abhängen, die im Zielsystem bereits vorhanden sein müssen. Reihenfolge und Abhängigkeiten sollten im Testfall sichtbar sein, statt nur im Wissen einzelner Entwickler zu liegen.
Eine kleine gemeinsame Abnahmeakte führen
Für einen ersten Durchlauf genügen wenige repräsentative Fälle: eine gültige Änderung, eine gezielte Ablehnung, die Wiederholung nach Korrektur und zwei Änderungen mit überlappender Verarbeitung. Halten Sie pro Fall Ausgangsstand, erwarteten Zielstand, Vorgangskennung, Zeitpunkte, tatsächliches Ergebnis und offene Abweichungen fest. Ergänzen Sie eine verantwortliche Rolle für die fachliche Abnahme. Verwenden Sie dafür nur die notwendigen Testdaten und vermeiden Sie vertrauliche Produktionsinformationen in frei zugänglichen Protokollen. So können Fachbereich, Entwicklung und Betrieb dieselbe Beobachtung prüfen und den Freigabestand gemeinsam nachvollziehen.
Den Betrieb schon bei der Abnahme mitdenken
Vor dem Go-Live sollte feststehen, wer offene Übertragungen prüft, wer fehlerhafte Quelldaten korrigiert und wer eine erneute Verarbeitung freigibt. Auch der Umgang mit Teilfehlern und längeren Unterbrechungen braucht eine Entscheidung. Ein regelmäßiger Abgleich wichtiger Datenstände kann dabei helfen, unbemerkte Abweichungen zu erkennen. Umfang, Häufigkeit und Zuständigkeit sind projektspezifisch zu vereinbaren. Ebenso gehört ein Rücknahmeweg dazu: Bereits im ERP entstandene Änderungen müssen berücksichtigt werden, bevor ein älterer Softwarestand wieder eingesetzt wird. Ein technisches Rollback allein stellt nicht zwingend den ursprünglichen Datenzustand her.
PLM- und Integrationsumfang zusammen eingrenzen
Aras beschreibt die Verbindung von PLM und ERP als Grundlage für abgestimmte Engineering- und Fertigungsinformationen. mediatec.net adressiert diese Systemgrenze mit ARAS-Entwicklung und Cloud Enterprise Integrations. Für ein konkretes Vorhaben müssen Datenobjekte, führende Systeme, Freigaben, Schnittstellen und Abnahmekriterien gemeinsam eingegrenzt werden. Die hier beschriebenen Prüfungen sind ein Arbeitsvorschlag für diese Abstimmung; sie sind keine Zusage bereits vorhandener Funktionen in jeder Installation. Bringen Sie zum Erstgespräch einen beispielhaften Änderungsablauf und die beteiligten Systeme mit. Daraus lässt sich ein überschaubarer erster Integrations- und Testumfang ableiten.
Fragen zur PLM-ERP-Abnahme
Reicht eine erfolgreiche Versandmeldung als Abnahme?
Sie belegt nur den jeweils gemeldeten technischen Schritt. Die Abnahme sollte zusätzlich den vereinbarten fachlichen Zustand im Zielsystem prüfen.
Welche Fehlerfälle sind für einen ersten Test sinnvoll?
Eine gezielte fachliche Ablehnung, eine erneute Übertragung nach Korrektur und zwei aufeinanderfolgende Änderungen zeigen wichtige Verarbeitungs- und Zuständigkeitsfragen.
Sind diese Prüfungen automatisch Bestandteil jeder CEI-Installation?
Nein. Der Artikel beschreibt eine Vorgehensweise. Funktionen, Überwachung, Zuständigkeiten und Testumfang müssen für das jeweilige Projekt ausdrücklich vereinbart werden.
Quellen geprüft am 12. Oktober 2026. Die Abnahmeschritte und das Revisionsbeispiel sind ein redaktioneller Arbeitsvorschlag, kein Kundenfall und keine pauschale Funktions- oder Ergebniszusage.