PLM-Migration mit KI-Agent: Schema-Mapping in Wochen statt Monaten

Pexon Consulting | 13 Min. Lesezeit | 02.06.2026

TL;DR

PLM-Migrationen von SAP DMS zu Teamcenter oder Aras Innovator dauern typisch 12 bis 24 Monate. Etwa die Hälfte davon ist Schema-Mapping, Metadaten-Extraktion und Validierung — also genau die Aufgaben, die ein gut gebauter KI-Agent in Wochen erledigt. Pexon Consulting begleitet die Migration als Architektur-Partner mit eigenem Agenten-Stack auf Azure, nicht als Tool-Verkäufer.

Warum 50% des Projekts für Schema-Mapping draufgehen

Wenn ein Maschinenbauer entscheidet, von SAP DMS auf Teamcenter oder Aras Innovator zu wechseln, ist die Software-Lizenz das billigste am Projekt. Die teure Arbeit ist die Datenmigration — und davon ist nach unserer Projekt-Erfahrung über die Hälfte reine Schema-Übersetzung und Metadaten-Anreicherung.

Konkret: ein typisches mittelständisches Engineering-Unternehmen hat in SAP DMS 200.000 bis 800.000 Document Info Records (DIR), 30 bis 80 verschiedene Dokumenttypen, BOM-Verknüpfungen auf 50.000+ Materialien, und eine über 15 Jahre gewachsene Klassifikationsstruktur. Jeder DIR muss auf das Ziel-Schema gemappt werden — Teamcenter mit Item, ItemRevision, Dataset, Lifecycle States, oder Aras mit ItemTypes, Properties, RelationshipTypes. Plus jede Datei muss neu klassifiziert, neu versioniert, gegen Workflow-States validiert werden.

Ein Architekturkollege bei einem süddeutschen Werkzeugmaschinenbauer hat es uns so beschrieben: „Wir haben 14 Monate gebraucht, nur um zu entscheiden, wie unsere alten DOK-Typen aus SAP auf die Teamcenter-Klassen abgebildet werden. Davon waren drei Monate Workshops, vier Monate Excel-Listen, sieben Monate Excel-Listen korrigieren.“

Genau dort setzt ein gut gebauter PLM-Migration-Agent an — nicht als Ersatz für die PLM-Architekt:innen, sondern als beschleunigender Hebel.

Was der Agent macht — und was bewusst nicht

Drei Komponenten, sauber getrennt:

┌─────────────────────────────────────────────────────────────┐
│ 1. SCHEMA-DISCOVERY-AGENT                                   │
│    - liest SAP-DMS-Metadaten (DIR-Typen, Status, Felder)   │
│    - liest Teamcenter/Aras BMIDE bzw. ItemType-Definition  │
│    - generiert Mapping-Vorschlag pro Source-Typ            │
│    - markiert Unsicherheiten (Confidence < 80%)            │
├─────────────────────────────────────────────────────────────┤
│ 2. METADATEN-EXTRAKTOR (Document Intelligence)              │
│    - parst PDF/DOCX/CAD-Anhänge aus SAP DMS                │
│    - extrahiert: Zeichnungsnummer, Revision, Status,       │
│      Werkstoff, Toleranz, Klassifikation, freigegeben_von  │
│    - schreibt strukturierte Properties ins Target-PLM      │
├─────────────────────────────────────────────────────────────┤
│ 3. VALIDIERUNGS-LAYER (deterministisch, kein LLM)           │
│    - checkt: Pflichtfelder, Datentyp, Lifecycle-Konsistenz │
│    - checkt: BOM-Integrität (Eltern-Kind-Beziehungen)      │
│    - checkt: Cross-References Material-Dokument            │
│    - flaggt Conflicts ans manuelle Review                  │
└─────────────────────────────────────────────────────────────┘

Was der Agent nicht macht: er entscheidet nicht autonom, wie ein neuer Dokumenttyp im Zielsystem auszusehen hat. Diese Entscheidung gehört zur Governance — sie liegt bei der PLM-Architektur und der Fachseite. Der Agent macht den Vorschlag, die Architektin entscheidet, der Agent setzt den Beschluss konsistent auf 800.000 Records um.

Wir haben das bewusst so getrennt, weil sonst genau das passiert, wovor erfahrene PLM-Berater seit zwei Jahren warnen: KI-generierte Schema-Entscheidungen, die niemand mehr nachvollziehen kann, weil sie in zwölf verschiedenen Excel-Tabs aus drei verschiedenen GPT-Sessions liegen.

Konkretes Beispiel: SAP DMS DIR-Typ „ZNL“ auf Teamcenter

Eine typische Engineering-Klasse aus SAP DMS:

Der Agent erkennt das Pattern automatisch, schlägt das Mapping vor, und — entscheidend — kann das gleiche Mapping auf alle 47.000 ZNL-Datensätze konsistent anwenden, inklusive der Edge-Cases (Dokumente mit drei Original-Anhängen, Dokumente ohne Klassifikation, Dokumente mit veralteten Object-Links zu archivierten Materialien).

Das Excel-basierte Vorgehen wäre: vier Workshops, sechs Wochen Mapping-Liste, vier Wochen Korrektur, ETL-Skript schreiben, Test-Migration, weitere Korrektur. Der Agent macht den Mapping-Vorschlag in 20 Minuten und die deterministische Validierung in 90 Minuten — die Workshops bleiben, weil die Architektin entscheidet, aber sie diskutiert nicht mehr über Spalten in einer Excel.

Eine unbequeme Position: Big-Bang-Migrationen sind 2026 ein Anti-Pattern

Wir raten Kunden inzwischen klar von Big-Bang-Migrationen ab — also dem Versuch, an einem Wochenende alle 800.000 DIRs auf Teamcenter zu schieben und am Montag den alten SAP-DMS-Server abzuschalten.

Der Grund ist nicht technisch, sondern organisatorisch: Die Engineering-Abteilung hat im selben Zeitraum nicht 8 Wochen Stillstand für „Migration testen“. Die Konstrukteure arbeiten weiter, neue DIRs entstehen jeden Tag, BOMs ändern sich, neue Klassifikationen kommen dazu.

Was funktioniert: wellen-basierte Migration mit Agent-gestützter Coexistenz. Phase 1 historische Daten (alles vor 2018) in einer Welle, Phase 2 aktive Projekte fließend, Phase 3 Live-Cutover. Das verlängert das Projekt nominell, halbiert aber das Risiko und erlaubt den Engineers, parallel produktiv zu bleiben. Ein guter Agent beherrscht beide Welten und synchronisiert bis zum Cutover.

Wer Ihnen ein „12-Monats-Big-Bang“-Versprechen verkauft, hat entweder noch nie eine echte Migration durchgezogen oder unterschätzt die Kollateralschäden.

Wo Pexon einsteigt — und wo nicht

Pexon ist nicht Razorleaf, nicht PROSTEP, nicht ITI Global. Wir sind nicht der Migrations-Generalunternehmer, der das Projekt komplett übernimmt. Was wir machen:

• PLM-Architektur-Begleitung an der Seite Ihres Lead-Architekten. Wir sind das technische Sparring + die Hands-on-Truppe für den Agenten-Stack.
• Schema-Mapping-Agent im eigenen Azure-Tenant. Nicht als verkauftes Produkt, sondern als Custom-Build auf Ihre Source/Target-Schemata.
• Metadaten-Extraktion für die CAD-Anhänge, Zeichnungen, Spezifikationen — hier kommt unser Document-Intelligence-Stack (PexonParse) ins Spiel.
• Validierungs-Schicht mit deterministischen Regeln plus LLM-basiertem Plausibilitäts-Check.

Was wir bewusst nicht machen: Teamcenter-Customizing, Aras-AML-Programmierung, SAP-DMS-Konfiguration. Da haben Sie spezialisierte PLM-Häuser — wir arbeiten daneben oder darunter, nicht gegen sie.

Das ist eine Premium-Beratungs-Rolle, nicht ein Lizenz-Sale. Wir kosten Geld, weil wir genau zwei bis vier Personen pro Engagement stellen, die seit Jahren mit Azure Document Intelligence, RAG-Layern und industriellen Metadaten-Pipelines arbeiten — nicht dreißig junge Berater:innen mit PowerPoint.

Realistischer Zeit- und Kostenrahmen

Wir engagieren uns typisch in einem 9- bis 12-monatigen Begleit-Modus, parallel zum laufenden PLM-Hauptprojekt:

Einstiegs-Engagement ab 50.000 EUR (Phase 1 isoliert), typischer Gesamtumfang 200.000 bis 300.000 EUR über 9–12 Monate, bei großen Tier-1-Maschinenbauern auch deutlich darüber. Das wirkt teuer — gemessen am Gesamtprojekt einer typischen 1,5- bis 3-Millionen-Euro-PLM-Migration sind das 7 bis 15%, die nach unserer Erfahrung 30 bis 50% der Datenschicht-Laufzeit einsparen.

ROI-Rechnung für ein Migrations-Projekt mit 50.000 EUR/Monat Brennrate: 6 Monate gesparte Laufzeit = 300.000 EUR direkte Einsparung, plus die Engineering-Stunden, die nicht in Excel-Mapping fließen. Das amortisiert eine 200k-Begleitung in der Regel im ersten Halbjahr.

Was Sie bei der Auswahl checken sollten

Wenn Sie das mit einem anderen Partner machen oder erst evaluieren, hier die Punkte, die wir uns selbst zu Beginn jedes Engagements als Checkliste vornehmen:

• Liest der Agent das Source-Schema (z.B. SAP DMS Customizing) automatisch oder ist das eine reine Excel-Übung?
• Kann der Agent das Target-Schema (Teamcenter BMIDE oder Aras ItemType-Definition) versioniert nachhalten?
• Werden Mapping-Entscheidungen versioniert und reproduzierbar gespeichert, oder verschwinden sie in einer Chat-Session?
• Wie geht der Validation-Layer mit BOM-Integrität um? Ein nicht-aufgelöster Eltern-Kind-Bezug ist im Engineering ein Show-Stopper.
• Wie sieht der Audit-Trail für die Compliance aus? Wer kann nachweisen, dass DIR 4711 mit welchem Mapping-Regelwerk migriert wurde?
• Wer trägt das Risiko bei Datenverlust? Das gehört in den Vertrag, nicht in die Kick-off-Folien.

Punkt 4 (BOM-Integrität) ist der häufigste blinde Fleck in PLM-Migrations-Projekten. Wir prüfen das deterministisch, bevor irgendetwas in Teamcenter landet.

Häufig gestellte Fragen

Wie unterscheidet sich Pexon von Razorleaf, PROSTEP oder ITI Global?

Diese Häuser sind Migrations-Generalunternehmer mit eigenen Tools (OpenPDM, PRO.FILE etc.). Pexon ist Architektur- und KI-Partner, der parallel arbeitet. Wenn Sie schon einen Generalunternehmer haben und der Schema-Mapping-Layer hängt, kommen wir als spezialisierte Verstärkung dazu. Wenn Sie noch keinen haben, können wir die Wahl mit Ihnen evaluieren — wir sind herstellerneutral.

Was kostet ein PLM-Migrations-Begleit-Engagement?

Einstieg ab 50.000 EUR für die Discovery-Phase, typische Gesamtkosten 200.000 bis 300.000 EUR über 9 bis 12 Monate. Bei Großprojekten in der Größenordnung 500.000 EUR+. Wir machen Festpreise pro Phase, keine Tagessätze ohne Deckel.

Funktioniert das auch für andere Migrationen, z.B. Windchill auf Aras?

Ja. Der Agent ist schema-agnostisch — wir bauen die Source/Target-Adapter pro Engagement. Bisher gesehen: SAP DMS → Teamcenter, SAP DMS → Aras, Windchill → Aras, Teamcenter Enterprise → Teamcenter Active Workspace, Agile PLM → Teamcenter. Jede Konstellation hat eigene Macken — am komplexesten waren bisher die historischen Teamcenter-Enterprise-Migrationen mit selbst-gestrickten Lifecycle-States.

Wo läuft der Agent — bei uns oder bei Pexon?

Im Regelfall in Ihrem Azure-Tenant. Wir nutzen Azure Document Intelligence, Azure OpenAI mit europäischer DataZone und Azure AI Search. Wenn Sie strengere Datenresidenz-Anforderungen haben (z.B. wegen Rüstung oder Patenten), können wir auch komplett on-prem mit Open-Source-Modellen aufsetzen — wirtschaftlich aber meist nicht sinnvoll.

Bleibt der Agent nach der Migration nutzbar?

Ja, und das ist eine der unterschätzten Wertschöpfungen: nach der Migration läuft der Schema-Validator als Daily-Watchdog weiter und meldet Inkonsistenzen, sobald neue Daten im Zielsystem landen. Aus dem Migrations-Tool wird ein Quality-Gate. Das ist kein extra Modul — wir bauen es so, dass die Pipeline sauber weiterläuft.

Nächster Schritt

Wenn Sie eine PLM-Migration in den nächsten 12 Monaten geplant haben oder mitten in einer steckenbleibenden Migration sind, ist der erste Schritt ein 90-minütiger Architektur-Workshop mit Ihrem PLM-Lead und unserem Architekten. Ergebnis: ehrlicher Reality-Check, wo Sie heute stehen, was ein Agenten-Stack realistisch beschleunigen kann, und ob Pexon der richtige Partner für Ihre Konstellation ist. Kostet nichts.

Verwandte Themen