TL;DR
Wer 2026 Teamcenter, Windchill und Aras parallel betreibt, bekommt von keinem Vendor-AI eine vollständige Antwort. Teamcenter AI Chat sieht nur Teamcenter, Windchill AI sieht nur Windchill. Cross-PLM-RAG ist die vendor-neutrale Brücke über die Multi-PLM-Realität — mit Identity-Mapping, Connector-Pattern und konsolidierter Engineer-Suche. Pexon baut das in 8 Wochen für 75-150k EUR Festpreis.
Die Multi-PLM-Realität im Mittelstand und Konzern 2026
Sie haben in den letzten zehn bis zwanzig Jahren zugekauft. Nicht spektakulär, sondern normal: zwei mittelständische Wettbewerber, einen Spezialisten für Elektronik, ein Werk in Polen. Jede dieser Akquisitionen kam mit eigenem PLM-System. Die Mutter sitzt auf Siemens Teamcenter, das gekaufte Maschinenbau-Tochterunternehmen hatte PTC Windchill, der Elektronik-Spezialist nutzt Aras Innovator, und in einem Werk läuft noch ein altes PDM-System aus den 2010er Jahren, das niemand abzuschalten traut.
In unserer Erfahrung ist das nicht die Ausnahme. Das ist der Normalfall in deutschen Industriekonzernen ab 1.500 Mitarbeitern. Drei PLM-Stacks parallel, gewachsen über drei M&A-Wellen, jede Konsolidierungsinitiative seit fünf Jahren auf Eis. Der Grund ist trivial: eine echte PLM-Migration kostet einen mittleren zweistelligen Millionenbetrag und blockiert das Engineering für zwölf bis achtzehn Monate. Niemand drückt diesen Knopf freiwillig.
Der Engineer in der Konstruktion zahlt den Preis täglich. Er sucht eine Welle, von der er weiss, dass eine baugleiche Version schon einmal konstruiert wurde — aber er weiss nicht mehr, in welchem Werk und damit in welchem PLM. Er sucht dreimal: einmal in Teamcenter, einmal in Windchill, einmal in Aras. Drei Logins, drei UIs, drei Suchsprachen, drei Stammdaten-Konventionen. In einem Industriegüter-Hersteller mit Multi-Site-Engineering nach drei M&A-Wellen haben wir gemessen, dass Senior-Konstrukteure im Schnitt 6,5 Stunden pro Woche mit Cross-System-Suche verbringen. Davon sind 4 Stunden vermeidbar — wenn die Systeme nur miteinander reden würden.
Was Vendor-AI 2026 anbietet — und was nicht
2026 ist das Jahr, in dem alle drei grossen PLM-Vendor ihre AI-Chats ausrollen. Das klingt nach Lösung, ist aber strukturell die Verschärfung des Problems. Hier die Ist-Lage:
Das Geschäftsmodell der Vendor verbietet die Cross-PLM-Integration. Siemens wird nie ernsthaft daran arbeiten, dass Teamcenter AI Chat auch Windchill-Daten holt — denn dann wäre das Argument für eine Migration auf Teamcenter weg. PTC verhält sich symmetrisch. Aras ist als Open-Source-Player flexibler, aber baut keine Connectors gegen die Konkurrenz, weil das Engineering nicht skaliert.
In unserer Erfahrung mit drei Multi-PLM-Setups in den letzten zwölf Monaten haben wir folgendes Muster beobachtet: Die Engineering-Leitung kauft Teamcenter AI Chat, weil Teamcenter das grösste System ist. Engineers nutzen es, bekommen plausibel klingende Antworten — und übersehen, dass die Treffer aus Windchill und Aras komplett fehlen. Das ist gefährlicher als gar kein Tool, weil es Falsch-Vertrauen erzeugt. „Ich habe gesucht, da war nichts“ — obwohl in Windchill drei passende Konstruktionen liegen.
Empfehlung: Wenn Sie nur ein PLM haben, nehmen Sie das Vendor-Tool. Wenn Sie zwei oder mehr PLMs haben, ist jedes Vendor-Tool eine Sackgasse. Sie brauchen Cross-PLM-RAG.
Pexon Cross-PLM-RAG Pattern — die Architektur
Die Lösung ist konzeptionell simpel: Ein Orchestrierungs-Layer fragt parallel alle vorhandenen PLM-Systeme, mappt identische Bauteile über Systemgrenzen hinweg und liefert eine konsolidierte Antwort mit Multi-PLM-Citations. Der Teufel sitzt im Identity-Mapping und im Connector-Engineering.
Die drei Bausteine:
- Connector-Layer — pro PLM ein Adapter mit einheitlicher Search-Schnittstelle. Teamcenter über Active Workspace REST API, Windchill über Info*Engine REST Services, Aras über das eingebaute OData/REST. Legacy-PDMs über direkte DB-Reads, wenn keine API existiert.
- Identity-Resolver — ein Layer, der entscheidet, ob „WL-XY-44“ aus Teamcenter, „Shaft_XY_44_Rev3“ aus Windchill und „PN-12849“ aus Aras das gleiche Bauteil sind. Halb regelbasiert, halb ML.
- RAG-Orchestrierung — LangGraph oder ähnliches, das die parallele Suche steuert, Identity-Mapping anwendet, gegen die Original-Query re-rankt und die Antwort mit Citations zusammenbaut.
from abc import ABC, abstractmethod
from typing import List, Dict
class PLMConnector(ABC):
@abstractmethod
async def search(self, query: str, top_k: int = 10) -> List[Dict]: ...
@abstractmethod
async def get_item(self, item_id: str) -> Dict: ...
class TeamcenterConnector(PLMConnector):
def __init__(self, base_url: str, token: str):
self.base_url = base_url
self.token = token
async def search(self, query: str, top_k: int = 10):
# Teamcenter Active Workspace REST API
# POST /tc/JsonRestServices/Core-2014-10-Session/login
# POST /tc/JsonRestServices/Internal-AWS2-2023-06-Finder/performSearchViewModel4
...
class WindchillConnector(PLMConnector):
async def search(self, query: str, top_k: int = 10):
# PTC Windchill REST Services (Info*Engine)
# GET /Windchill/servlet/odata/ProdMgmt/Parts?$filter=...
...
class ArasConnector(PLMConnector):
async def search(self, query: str, top_k: int = 10):
# Aras Innovator OData/REST
# POST /InnovatorServer/Server/odata/Part?$filter=...
...
connectors = [
TeamcenterConnector(TC_URL, TC_TOKEN),
WindchillConnector(WC_URL, WC_TOKEN),
ArasConnector(AR_URL, AR_TOKEN),
]Das Pattern ist deshalb so wichtig, weil es die PLM-Spezifika kapselt. Die Orchestrierung darüber kennt nur die abstrakte PLMConnector-Schnittstelle. Wenn morgen ein viertes PLM dazukommt — was bei der nächsten Akquisition garantiert passiert — schreiben Sie einen Connector und sind fertig. Wenn Sie irgendwann Aras abschalten, entfernen Sie den Connector. Die Logik darüber bleibt stabil.
Identity-Mapping als Kern-Pattern
Das Identity-Mapping ist die Stelle, an der jedes naive Cross-PLM-Projekt scheitert. Gleiches Bauteil hat in jedem System eine andere ID, oft auch eine andere Bezeichnung, manchmal abweichende Stammdaten. Eine deutsche Welle, die in Teamcenter als „WL-XY-44 Rev.7“ geführt wird, kann in Windchill als „Shaft_XY_44_Rev3“ liegen (weil das akquirierte Werk historisch englisch dokumentiert hat) und in Aras als „PN-12849“ (weil dort die ERP-Materialnummer als Master genutzt wird).
In unserer Erfahrung gibt es drei Stufen, in denen Identity-Mapping in der Praxis funktioniert:
Stufe 1 — Cross-Reference-Tabelle aus dem ERP. Wenn SAP oder ein anderes ERP als Master für Materialnummern fungiert und alle PLMs die ERP-Materialnummer als Attribut führen, ist das Mapping deterministisch. Funktioniert in etwa 40 Prozent der Multi-PLM-Setups, die wir gesehen haben — aber nur für aktiv genutzte Bauteile, nicht für historische.
Stufe 2 — Regelbasiertes Mapping über Bezeichnung und Geometrie. Wenn die ERP-Brücke fehlt, baut man Mapping-Regeln: Tokenisierung der Bezeichnung, Normalisierung (Bindestriche, Unterstriche, Sprachvarianten), Cosine-Similarity der Stammdaten-Vektoren, Geometrie-Hashes wenn STEP-Files vorhanden. Liefert 70-85 Prozent Precision bei akzeptablem Recall.
Stufe 3 — ML-basiertes Matching mit Engineer-Feedback-Loop. Embeddings über Bezeichnung, Beschreibung, Klassifikation und Stammdaten; ein Cross-Encoder-Reranker mit aktivem Lernen. Engineers korrigieren falsche Matches im UI, das Modell lernt nach. Nach drei bis sechs Monaten erreichen wir typischerweise über 90 Prozent Precision.
Empfehlung: Starten Sie mit Stufe 1 für die 30 Prozent der Bauteile, die in laufenden Konstruktionen sind. Stufe 2 für die nächsten 50 Prozent. Stufe 3 nur dann ausbauen, wenn das Volumen es rechtfertigt — was bei Multi-PLM-Konzernen ab 500 Engineers fast immer der Fall ist.
Code — Cross-PLM-Query mit Identity-Mapping
import asyncio
from langgraph.graph import StateGraph
async def cross_plm_search(query: str, connectors: list):
# Parallel über alle PLMs suchen
results = await asyncio.gather(*[c.search(query) for c in connectors])
# Identity-Mapping anwenden — gleiches Bauteil in mehreren PLMs zusammenführen
mapped = identity_resolver.resolve(results)
# Re-Ranking gegen Original-Query (Cross-Encoder)
ranked = reranker.score_and_sort(query, mapped)
# Stammdaten aus Master-System anreichern (z.B. ERP)
enriched = master_data.enrich(ranked)
return enriched
# Beispiel-Antwort des Systems:
# "Welle XY-44 existiert in 3 PLMs:
# - Teamcenter: WL-XY-44 Rev.7 (aktuelle Master-Version)
# - Windchill: Shaft_XY_44_Rev3 (Tochterunternehmen, letzte Änderung 2023)
# - Aras: PN-12849 (Elektronik-Site, nur Stammdaten, kein CAD)
# Verwendet in 14 Konstruktionen: 8 in Teamcenter,
# 4 in Windchill, 2 in Aras."Der entscheidende Punkt ist die letzte Zeile: Der Engineer bekommt eine Antwort, die alle Quellen abdeckt — mit Quellen-Angabe pro Treffer. Er kann entscheiden, welche Version die Master-Version ist, und vermeidet die Doppelkonstruktion, die heute Standard ist.
VLM-Eskalation für CAD-Vorschauen
Ein zweiter Use-Case, der in unserer Erfahrung 2026 stark zieht: Der Engineer hat ein physisches Bauteil in der Hand oder einen Screenshot von einer alten Zeichnung und möchte wissen, ob das in irgendeinem PLM existiert. Hier eskalieren wir auf ein Vision-Language-Model.
# Engineer fragt "wo wird diese Welle verbaut?" + Foto vom Bauteil
response = vlm.chat(
image=foto_b64,
text="Identifiziere das Bauteil anhand der Geometrie und sichtbarer "
"Beschriftungen. Liefere Hypothesen für Bauteil-Typ und mögliche "
"Pexon-Bezeichnungs-Konventionen.",
)
# VLM-Antwort: "Wahrscheinlich Antriebswelle, Durchmesser ca. 40mm,
# Bezeichnung am Bauteil: WL-XY-44 oder ähnlich"
# → Cross-PLM-Search mit erweiterten Suchbegriffen
hits = await cross_plm_search(
query=f"{response.bauteil_typ} {response.bezeichnung_kandidaten}",
connectors=connectors,
)Das ist kein Marketing-Demo. In einem Tier-1-Engineering-Konzern mit gewachsener PLM-Landschaft haben wir diesen Flow für die Wartung im Service-Aussendienst gebaut. Techniker fotografiert das Bauteil beim Kunden, bekommt innerhalb von 30 Sekunden die Verwendungs-Stellen über alle drei PLMs. Vorher: zwei Tage Recherche durch die Konstruktion, weil niemand wusste, in welchem System das Teil ursprünglich konstruiert wurde.
M&A-Integration als Killer-Use-Case
Der wirtschaftlich grösste Hebel von Cross-PLM-RAG ist nicht die tägliche Sucharbeit, sondern die M&A-Integration. Wenn Sie heute ein Unternehmen kaufen, dauert die PLM-Konsolidierung fünf bis zehn Jahre. In dieser Zeit ist die Engineering-Integration faktisch blockiert: gemeinsame Plattform-Strategien, Gleichteile-Konzepte, Modul-Baukästen — alles auf Eis, weil die Daten in getrennten Systemen liegen.
Die Cross-System-Suche ist die Brücke. Statt fünf bis zehn Jahre auf die PLM-Konsolidierung zu warten, schalten Sie sie in acht Wochen scharf. Engineers können ab Tag eins der Integration auf Bauteile, Konstruktionen und Doku der gekauften Einheit zugreifen. Gleichteile-Analysen werden möglich — der Klassiker, wo eine Akquisition 30-40 Prozent Bauteil-Überlapp mit dem Mutterunternehmen hat und keiner es sieht, weil die Systeme getrennt sind.
In einem deutschen Maschinenbauer mit drei Werken nach Akquisitions-Geschichte haben wir auf dieser Basis eine Gleichteile-Analyse über alle drei PLMs durchgeführt. Ergebnis: 4.700 Bauteile, die in mindestens zwei der drei Werke separat konstruiert worden waren. Konservativ geschätzte Einsparung über fünf Jahre durch Vermeidung von Doppelkonstruktionen und Konsolidierung der Lieferantenbasis: 2,3 Millionen Euro. Das hat den Sprint refinanziert, bevor er produktiv war.
Anti-Patterns
Was wir in den letzten zwölf Monaten an Cross-PLM-Projekten gesehen haben, das nicht funktioniert hat:
Empfehlung: Wenn Sie eines dieser Patterns aktuell im Projekt haben, stoppen Sie den Sprint und re-scopen. Wir haben drei Cross-PLM-Initiativen gesehen, die nach sechs Monaten abgebrochen wurden, weil eines dieser Anti-Patterns nicht früh erkannt wurde.
ROI — was das Pattern wirklich bringt
Konservative Rechnung für einen Multi-PLM-Konzern mit 200 Engineers:
- Zeitersparnis Suche: 4 Stunden/Woche × 200 Engineers × 46 Wochen = 36.800 Stunden/Jahr
- Bei Vollkosten 120k EUR/Engineer/Jahr = 75 EUR/Stunde → 2,76 Mio EUR pro Jahr
- Vermeidung Doppelkonstruktionen: 50-150 Bauteile/Jahr × 8-15k EUR Konstruktions- und Validierungskosten → 0,5-2 Mio EUR
- M&A-Integration: einmaliger Wert, je nach Deal 1-5 Mio EUR Gleichteile-Synergien
Investition: Pexon-Sprint (8 Wochen) — 75-150k EUR Festpreis, je nach Anzahl PLMs und Identity-Mapping-Komplexität. Payback typischerweise in unter sechs Monaten.
FAQ
1. Was ist Cross-PLM-RAG und wann brauche ich es?
Cross-PLM-RAG ist eine vendor-neutrale RAG-Architektur, die parallel über mehrere PLM-Systeme sucht und Bauteile über Systemgrenzen hinweg identifiziert. Sie brauchen es, sobald Sie zwei oder mehr PLMs parallel betreiben — typischerweise nach M&A-Wellen oder bei dezentralen Engineering-Standorten mit unterschiedlichen Historien.
2. Teamcenter AI Chat oder Cross-PLM-RAG — was nehmen wir?
Wenn Sie nur Teamcenter haben: Teamcenter AI Chat. Wenn Sie Teamcenter plus Windchill plus Aras haben: die vendor-neutrale Variante. Teamcenter AI Chat sieht definitionsgemäss nur Teamcenter-Daten — Engineers bekommen unvollständige Antworten und merken es nicht. Das ist schlechter als gar kein Tool, weil es Falsch-Vertrauen erzeugt.
3. Wie funktioniert Identity-Mapping über mehrere PLMs?
In drei Stufen. Stufe 1: deterministisches Mapping über ERP-Materialnummer, wenn alle PLMs die ERP-ID als Attribut führen. Stufe 2: regelbasiertes Mapping über Bezeichnung, Stammdaten und Geometrie-Hashes. Stufe 3: ML-basierter Cross-Encoder mit aktivem Engineer-Feedback. In der Praxis kombinieren wir alle drei, je nach Datenqualität pro Bauteil-Klasse.
4. Wie lange dauert der Sprint?
Acht Wochen für zwei bis drei PLM-Connectors, Identity-Resolver auf Stufe 1+2, RAG-Orchestrierung und ein produktives Engineer-UI. Vier zusätzliche Wochen, wenn VLM-Eskalation für CAD-Vorschauen dazukommt. Festpreis 75-150k EUR, je nach Anzahl PLMs und Komplexität der Cross-Reference.
5. Was kostet das gegenüber einer PLM-Konsolidierung?
Eine echte PLM-Migration von Windchill auf Teamcenter (oder umgekehrt) kostet in unserer Erfahrung 8-25 Mio EUR und blockiert das Engineering für 12-18 Monate. Die Cross-System-Lösung kostet unter 200k EUR und ist in zwei Monaten produktiv. Sie ersetzt die Migration nicht — sie macht sie aufschiebbar. In den meisten Konzernen ist die Migration nach Einführung der Brücke ohnehin nicht mehr Top-Priorität, weil der Schmerz wegfällt.
Nächster Schritt
Wenn Sie heute zwei oder mehr PLMs im Konzern haben und sich fragen, ob Sie auf Teamcenter AI Chat oder Windchill AI warten sollen: tun Sie das nicht. Beide Tools werden Ihr Multi-PLM-Problem nicht lösen, weil es ihrem Geschäftsmodell widerspricht.
Cross-PLM-RAG Architektur-Sparring — 90 Minuten zu Multi-PLM-Realität
In den 90 Minuten gehen wir Ihre konkrete PLM-Landschaft durch, schätzen Identity-Mapping-Komplexität, definieren den minimalen Scope für einen 8-Wochen-Sprint und sagen Ihnen ehrlich, ob das Pattern bei Ihnen den Aufwand wert ist oder ob Ihre Situation eine andere Lösung verlangt.
