MBSE-Modelle in der Entwicklung und Semantic Data im Serienbetrieb: Wie ein gemeinsames Rückgrat schnellere Inbetriebnahme und dauerhafte Optimierung auf der Kammlinie ermöglicht
Der Proof of Concept war ein Erfolg. Der Rollout leider nicht. Wer in Produktionsumgebungen mit Digitalisierungsprojekten arbeitet, kennt dieses Muster: Digital Twin, Predictive Maintenance, KI-Optimierer, Condition Monitoring sind im Pilotbetrieb überzeugend, aber in der Skalierung ausgebremst. Die Ursache liegt selten in der Technologie einzelner Bausteine, sondern in einer fehlenden Integrationsschicht zwischen Engineering und Betrieb.
MBSE-Modelle in der Entwicklung, die durch semantische Datenmodelle im Serienbetrieb weitergedacht werden, schließen genau diese Lücke. Sie liefern das gemeinsame fachliche Rückgrat, an das alle Digitalisierungs-Bausteine andocken können. Das Ergebnis: Anlagen optimieren ihre Kammlinie im Serienanlauf schneller und halten sie dauerhaft.
Ventum Consulting zeigt, warum das gelingt, welche Konzepte dahinterstehen, wie MBSE über das Engineering hinauswirkt und wie fachlich geschnittene Datenverantwortung im Betrieb funktioniert.
Zusammenfassung – Warum Engineering-Struktur und Betriebsdaten zusammengehören
- PoC-Erfolge skalieren nicht durch mehr Bausteine: Digital Twin, Predictive Maintenance und KI-Optimierer haben ein gemeinsames Struktur-Problem und keines lässt sich isoliert lösen.
- Kammlinie definiert den Business Case: Der schmale Bereich zwischen technischem und wirtschaftlichem Optimum ist der eigentliche Werthebel. Ihn zu erreichen ist eine Sache, ihn zu halten die eigentliche Herausforderung.
- MBSE ist mehr als Engineering-Methodik: Die fachlichen Strukturen aus der Entwicklung sind das Rückgrat, das im Serienbetrieb weiterlebt, wenn man sie nicht am Engineering-Ende belässt.
- Semantische Datenmodelle machen Rohdaten bedeutsam und interpretationsfähig: Hunderte anonyme Sensor-Tags werden in die Sprache des Prozesses übersetzt – aus Datenpunkten werden fachliche Einflussgrößen und aus Rauschen werden Antworten.
- Datenverantwortung gehört fachlich, nicht system-geschnitten: Datenanfragen und -management gehen nicht mehr an die IT, sondern an den fachlich verantwortlichen Bereich.
- KI skaliert nur auf strukturierten und fachlich-beschriebenen Daten: Fachlich klassifizierte Daten sind für Mensch und Maschine gleichermaßen nutzbar – die Voraussetzung für skalierbare KI in der Produktion.
Auf der Kammlinie fahren: Der Serienanlauf endet. Das Problem beginnt.
Den Serienanlauf zu schaffen ist eine Leistung. Aber sie zählt wenig, wenn die Anlage kurz danach wieder unter ihr Optimum fällt. In der Praxis gibt es Peaks und Einbrüche und dazwischen liegt Potenzial, das systematisch verloren geht. Oft beginnt das Problem früher als gedacht: Wer im Werk fragt, wo die Kammlinie eigentlich liegt, bekommt selten eine einheitliche Antwort. Produktionsleitung, Qualitätssicherung und Controlling rechnen mit unterschiedlichen Kennzahlen, stützen sich auf unterschiedliche Berechnungsgrundlagen und ziehen unterschiedliche Datenquellen heran. Nicht weil niemand optimieren will, sondern weil die gemeinsame Grundlage fehlt.
Warum viele Digitalisierungs-Bausteine im PoC überzeugen, aber nicht skalieren
Seit Jahren verspricht Digitalisierung Abhilfe für eine stabilere Kammlinie im Serienbetrieb. Die Realität in vielen Werken ist jedoch nicht ein Mangel an Digitalisierungsinitiativen, sondern deren fehlende Skalierung: PoCs zeigen Wirkung im begrenzten Ausschnitt, verlieren aber an Durchschlagkraft, sobald sie in heterogene Anlagenlandschaften, gewachsene Datenstrukturen und reale Verantwortungsgrenzen übertragen werden.
Vier strukturelle Ursachen
Silo-Scope
PoCs sind so klein geschnitten, dass sie im Werk keine Relevanz entfalten. Die Übertragung auf reale Anlagenumgebungen scheitert an fehlender Anschlussfähigkeit und Durchschlagkraft.
Manuelle Datenqualifizierung
Datenaufbereitung im Pilotmaßstab funktioniert – im Serienbetrieb ist sie nicht wirtschaftlich abbildbar. Ohne strukturierte, automatisierte Datenpflege bleibt jeder Rollout Handarbeit.
Verteilte Datentöpfe
Verknüpfungen zwischen Systemen sind nur durch Experten möglich. Was skalieren müsste, hängt an einzelnen Personen und ist nicht organisatorisch bzw. systematisch abgesichert. Das ist ein Engpass, der jede Skalierung ausbremst.
Kultur-Clash zwischen Digital und Manufacturing
Digitalisierungsteams und Produktionsverantwortliche sprechen unterschiedliche Sprachen, verfolgen unterschiedliche Ziele und arbeiten mit unterschiedlichen Erfolgskriterien.
Die Lösung: MBSE als Fachstruktur, Semantic Data als Übersetzung
Zwei Konzepte greifen ineinander und schaffen das gemeinsame Rückgrat: MBSE-Modelle in der Entwicklung und semantische Datenmodelle im Serienbetrieb.
MBSE liefert die Fachstruktur
Model-Based Systems Engineering (MBSE) entsteht ohnehin in der Entwicklung: Funktionen, Komponenten, Wirkzusammenhänge werden systematisch modelliert als Sprache des Produkts. Diese Struktur beschreibt, wie das Produkt aufgebaut ist und wie seine Bestandteile zusammenwirken.
Der zentrale Punkt: Diese Fachstruktur wird nicht am Engineering-Ende weggeworfen. Sie ist die Integrationsschicht, die auch im Serienbetrieb tragfähig bleibt, wenn man sie systematisch weiterführt.
Semantische Informationsmodelle führen die Fachstruktur in Produktion und Feld weiter
Semantic Data im Serienbetrieb bedeutet: Die Sensordaten aus MES, Historian und Betriebssystemen werden nicht als anonyme Tags, sondern in der Sprache des Prozesses strukturiert. Aus zum Beispiel „TAG_0417, TAG_0418, TAG_0419″ wird eine hierarchische, semantisch angereicherte Struktur:
- Modul: Abfüller
- Funktion: Füllstandsregelung
- Parameter: Zielfüllmenge
- Messwert: Ist-Füllmenge
- Zustand: Abweichung / OK
Aus beispielsweise 100 Tags werden die fünf Einflussgrößen für die konkrete Frage. Das ist der Unterschied zwischen „wir haben die Daten irgendwo“ und „wir können die Frage beantworten“.
Fachlich geschnittene Datenverantwortung
Der dritte, oft unterschätzte Baustein: Datenverantwortung wird nicht mehr entlang von Systemen (IT, MES, ERP) geschnitten, sondern entlang fachlicher bzw. funktionaler Bereiche. Datenanfragen gehen dann nicht mehr an die IT, sondern an den fachlich verantwortlichen Bereich, wo das Verständnis für Wirkzusammenhänge sitzt.
Das ist keine neue Abteilung, sondern eine neue Zuordnung von Verantwortung. Funktional geschnitten, nicht system-geschnitten.
Vom Rückgrat zur Wirkung – drei Erfolgsfaktoren
- Fokus statt Breite: Ein Fokus-Modul sauber aufbauen statt überall halbherzig. Wer versucht, alles gleichzeitig zu integrieren, wird an keiner Stelle wirksam.
- Menschen zusammenbringen: Menschen mit Daten und Modellen aus Engineering, Produktion und Feld, die den Ansatz aktiv treiben. Ohne diese Koalition bleibt jede Methodik theoretisch.
- Fachliche Verantwortung: Datenverantwortung liegt bei denen, die die Wirkzusammenhänge kennen. Nicht bei der IT. Alles andere ist Methodik, um dorthin zu kommen.
Aus der Praxis: Ein Rückgrat – viele Anwendungen. Wie ein Anlagenbauer den methodischen Durchstich schafft
Ausgangslage
Branche: Anlagenbau
Fachliche Datenstrukturen historisch gewachsen, system-getrieben. Kein durchgängiger Zusammenhang zwischen Engineering-Struktur und Betriebsdaten.
Was im PoC entstand
Der PoC konzentrierte sich auf ein einzelnes Fokus-Modul. Drei Schritte prägten den Durchstich:
Schritt 1 – Fachliche Struktur aus MBSE ableiten
Der Engineering-Teil wurde strukturell aus dem MBSE-Modell übernommen. Von Customer Requirement über Machine Feature bis zu Machine Configuration entstand eine durchgängige, fachlich beschriftete Struktur.
Schritt 2 – Datenverantwortung funktional schneiden
Die betriebsseitige Instanziierung erfolgte entlang fachlicher Bereiche: Production Asset, Functional Zone und Measurement Record wurden nicht IT-Systemen, sondern funktionalen Verantwortlichkeiten zugeordnet.
Schritt 3 – Semantisches Informationsmodell aufbauen
Das Fokus-Modul Erhitzen wurde vom Sensor-Tag bis zur Anforderung durchgängig modelliert, als erster End-to-End-Nachweis der Methodik.
Ergebnisse des PoC
Durchstich validiert: Die Ende-zu-Ende-Kette funktioniert methodisch.
Organisationsschnitt validiert: Fachbereich statt IT als Datenverantwortlicher.
Unternehmensweites Data Governance Office etabliert, Rollout läuft.
Was im Rollout darauf aufsetzt
Auf demselben methodischen Fundament werden jetzt mehrere Anwendungen parallel umgesetzt:
- Digital Twin
- Prozess-Simulationen
- Digitales Produkt für Shopfloor
- Paketierungs-Layouts
- Fertigungsdaten im 3D-Modell
- Integration Prozess und Konstruktion
Ihre Experten
Die Vorteile: Was das für vier typische Perspektiven bedeutet
MBSE-Modelle und semantische Datenmodelle wirken je nach Rolle unterschiedlich. Vier Perspektiven aus der Praxis.
Lead Engineering – Produktion als Beifahrer
Für Systems Engineers und Entwicklungsleitungen bedeutet der Ansatz: Das MBSE-Modell wird nicht am Engineering-Ende abgeschlossen, sondern als Integrationsschicht bis in den Serienbetrieb gedacht. Die Investition ins Modell zahlt sich über den gesamten Lifecycle mehrfach aus.
Lead Produktion & Logistik – Engineering als Beifahrer
Für Werksleitungen und Head of Digital/IT-OT bedeutet der Ansatz: Betriebsdaten werden fachlich strukturiert, nicht system-getrieben. Datenanfragen werden schneller und präziser beantwortet, ohne Engpass IT.
Reine Produktion &
Logistik
Für Produktionsleitungen, Prozessingenieure und Instandhaltungsleitungen bedeutet der Ansatz: Kammlinie wird einheitlich definiert und dauerhaft haltbar. Optimierungsfenster werden systematisch genutzt statt anekdotisch bearbeitet.
Lead After
Sales
Für Service- und After-Sales-Leitungen bedeutet der Ansatz: Felddaten fließen in dieselbe Struktur zurück als Grundlage für Predictive Services, datenbasierte Vertragsmodelle und produktbezogene Wartungsoptimierung.
Lead Engineering – Produktion als Beifahrer
Lead Produktion & Logistik – Engineering als Beifahrer
Reine Produktion &
Logistik
Lead After
Sales
- Direkt mit Fachexpert:innen sprechen, kein Sales‑Team
- Kostenlose Situations‑ und Anforderungseinschätzung
Unsere Beratungsleistungen rund um MBSE und semantische Datenmodelle
Ventum Consulting begleitet Unternehmen entlang des gesamten Wertschöpfungspfads: von der Engineering-Methodik bis zur produktiven Kammlinie-Optimierung.
MBSE Consulting
Einführung, Skalierung und Weiterführung von Model-Based Systems Engineering – nicht als Engineering-Insel, sondern als durchgängige Fachstruktur über den gesamten Produktlifecycle. Wir schaffen die Voraussetzungen, dass MBSE-Modelle als Integrationsschicht bis in Produktion und Feld tragfähig sind.
Semantische Datenmodelle und Data Governance
Konzeption und Umsetzung semantischer Informationsmodelle für den Serienbetrieb inklusive Ontologie-Aufbau, fachlicher Datenklassifizierung und Governance-Strukturen, die den Übergang von system- zu fachlicher Datenverantwortung ermöglichen.
KI in der Produktion und Fertigung
Produktionsnahe KI- und Optimierungsmodelle für Durchsatz, Qualität und Stabilität. Kombination aus KI und mathematischer Optimierung – von der Analyse über den PoC bis zur Closed-Loop-Steuerung im laufenden Betrieb.
Datenstrategie und Enterprise Data Governance
Aufbau einer unternehmensweiten Datenstrategie mit fachlich geschnittener Datenverantwortung, klaren Rollen und Governance-Modell. Data Governance Office-Etablierung inklusive.
Digital Engineering und PLM
Durchgängige Verknüpfung von Engineering-Daten, PLM-Strukturen und Produktionsdaten als Grundlage für skalierbare Digitalisierungs-Bausteine wie Digital Twin, Predictive Maintenance oder KI-Optimierer.
Change Management und Enablement
Kulturelle Verankerung fachlicher Datenverantwortung, Aufbau einer Community und Schulung von Fach- und Produktionsteams für den neuen Umgang mit Daten.
Reifegradmodell: Wo steht Ihre Organisation zwischen Sensor-Tag und semantischer Antwort?
Viele Unternehmen wissen, dass sie Daten haben. Deutlich weniger wissen, was sie damit beantworten können. Noch weniger haben eine klare Vorstellung davon, wo genau sie auf dem Weg vom rohen Sensor-Tag zur fachlichen Antwort stehen.
Stufe 1 – Daten vorhanden, Kontext fehlt
Produktionsdaten werden erfasst und gespeichert. Historian, MES und ERP laufen. Doch die Daten liegen in Silos, Tags haben keine fachliche Bedeutung und Auswertungen entstehen manuell durch Einzelpersonen mit Sonderwissen.
Typisches Erkennungszeichen: „Wir haben alle Daten, wir wissen nur nicht, wo.“
Was fehlt: Einheitliche Datenstruktur, klare Verantwortlichkeiten, fachliche Klassifizierung.
Stufe 2 – Erste Dashboards, aber keine Skalierung
Es gibt Dashboards und erste Auswertungen. Einzelne Pilotprojekte zeigen Potenzial. Aber jede neue Frage erfordert erneuten Aufwand, weil Datenmodelle nicht wiederverwendbar sind und die IT als Engpass fungiert.
Typisches Erkennungszeichen: „Wir haben einen PoC, der gut funktioniert, aber nicht skaliert.“
Was fehlt: Semantisches Datenmodell, durchgängige Strukturen, fachliche Datenverantwortung.
Stufe 3 – Fachliche Struktur entsteht, aber bleibt im Engineering
MBSE wird eingesetzt. Engineering-Modelle sind vorhanden und strukturiert. Doch die fachliche Struktur bleibt am Engineering-Ende. Inbetriebnahme und Serienbetrieb haben eigene, nicht angebundene Strukturen. Der Werksmitarbeiter sieht Sensornummern, keine Funktionen.
Typisches Erkennungszeichen: „Wir machen MBSE, aber in der Produktion kommt davon nichts an.“
Was fehlt: Übersetzung der MBSE-Struktur in semantische Betriebsmodelle, Lifecycle-Durchgängigkeit.
Stufe 4 – Semantisches Rückgrat im Aufbau
Ein Fokus-Modul wurde semantisch modelliert. Fachliche Datenverantwortung wird pilotiert. Erste Datenanfragen gehen nicht mehr an die IT, sondern an den fachlich verantwortlichen Bereich. Die Methodik ist validiert, der Rollout beginnt.
Typisches Erkennungszeichen: „Wir haben den Durchstich geschafft, jetzt kommt die Skalierung.“
Was fehlt: Unternehmensweites Governance-Office, skalierbare Prozesse, vollständige Lifecycle-Integration.
Stufe 5 – Fachlich strukturierte, KI-taugliche Organisation
MBSE-Struktur, semantische Informationsmodelle und fachliche Datenverantwortung greifen durchgängig ineinander. Datenanfragen werden fachlich beantwortet. KI-Anwendungen skalieren, weil sie auf einem gemeinsamen Rückgrat aufsetzen. Die Kammlinie ist definiert, messbar und wird systematisch gehalten.
Typisches Erkennungszeichen: „Wir können jede Optimierungsfrage mit Daten beantworten und neue Use Cases schnell aufsetzen.“
Was folgt: Kontinuierliche Weiterentwicklung, Ausweitung auf Feld und After Sales, Vorbereitung auf agentische KI.
Aus der Beratungspraxis bei Ventum Consulting
Zukunftsperspektive – warum das Rückgrat jetzt gebaut werden sollte
Drei Entwicklungen machen den Aufbau des gemeinsamen fachlichen Rückgrats aus MBSE und semantischen Datenmodellen zum strategischen Wettbewerbsfaktor.
KI-Adoption skaliert nur auf strukturierten Daten
KI-Anwendungen skalieren in Produktionsumgebungen deutlich besser, wenn die zugrunde liegenden Daten fachlich klassifiziert, qualitätsgesichert und wiederverwendbar beschrieben sind. Semantische Strukturen ersetzen dabei nicht Datenqualität, Modellvalidierung oder MLOps, schaffen aber die Voraussetzung, damit Use Cases nicht bei jeder neuen Fragestellung wieder bei der manuellen Dateninterpretation beginnen.
Regulatorische Anforderungen steigen
Nachweispflichten, Audit-Fähigkeit und Compliance-Anforderungen aus EU AI Act, ESG-Regulatorik und branchenspezifischen Vorgaben verlangen zunehmend strukturierte, nachvollziehbare Produktions- und Engineering-Daten. Wer sein Rückgrat aufgebaut hat, ersetzt zwar keine Compliance-Prüfung, erleichtert aber Transparenz, Datenherkunft, Verantwortlichkeiten und Wiederverwendbarkeit von Nachweisen.
Wettbewerbsdifferenzierung durch Umgang, nicht durch Tools
PLM- und KI-Tools allein schaffen noch keinen Wettbewerbsvorteil. Differenzierung entsteht dort, wo Organisationen ihre Modelle, Daten, Verantwortlichkeiten und Entscheidungsprozesse besser miteinander verbinden als der Wettbewerb. Wer MBSE-Weiterführung und fachliches Datenmanagement heute aufbaut, investiert deshalb nicht in ein weiteres Tooling-Thema, sondern in die Fähigkeit, digitale Bausteine dauerhaft wirksam zu kombinieren.
Jetzt Rückgrat für Ihre Digitalisierungs-Bausteine bauen
- Vom PoC zur Kammlinie: Wir helfen, aus isolierten Piloten skalierbare Lösungen zu machen
- MBSE als Integrationsschicht: Engineering-Struktur wird zum durchgängigen Rückgrat
- Semantic Data im Betrieb: Aus Sensor-Tags werden fachliche Antworten
- Fachliche Datenverantwortung: Der eigentliche Kern – wir zeigen, wie es funktioniert
- Über 20 Jahre Erfahrung: In Engineering, Produktion und digitaler Transformation
TISAX und ISO-Zertifizierung nur für den Standort in München
Ihre Nachricht
FAQ – Häufig gestellte Fragen zu MBSE und semantischen Datenmodellen
MBSE beschreibt die fachliche Struktur eines Produkts – Funktionen, Komponenten, Wirkzusammenhänge – in der Entwicklung. Semantische Datenmodelle führen dieses Vokabular im Serienbetrieb weiter und ordnen Sensordaten den fachlichen Strukturen zu. MBSE ist die Sprache, semantische Modelle sind die Übersetzung ins Werk.
Nein, aber es ist ein starker Beschleuniger. Wer bereits MBSE einsetzt, hat das Fachvokabular bereits. Wer nicht, kann semantische Datenmodelle auch aus Prozessdokumentationen und Fachwissen aufbauen. Die Wirkung ist dieselbe, der Weg etwas länger.
Nein. Mittelständische Anlagenbauer und Prozessindustrien profitieren gleichermaßen. Entscheidend ist die Bereitschaft, Datenverantwortung fachlich zu schneiden und mit einem Fokus-Modul zu starten und nicht die Unternehmensgröße.
Ein fokussierter Durchstich – ein Modul, eine Anlage, ein Fokus-Prozess – lässt sich typischerweise in wenigen Monaten realisieren. Die Kunst liegt in der Auswahl des Fokus-Moduls und der Koalition der Willigen.
Der PoC validiert Methodik und Organisationsschnitt. Danach folgt der Rollout auf weitere Module, Anlagen oder Werke und parallel setzen konkrete Anwendungen (Digital Twin, Predictive Maintenance, KI-Optimierer) auf demselben Rückgrat auf.
Der Aufwand hängt vom Fokus-Modul und der Ausgangsbasis ab. In der Regel ist der methodische Aufbau überschaubarer als klassische Datenintegrationsprojekte und amortisiert sich schneller, weil auf dem Rückgrat viele Anwendungen aufsetzen.
Die IT liefert die Plattform, Werkzeuge und technische Infrastruktur. Die fachliche Semantik und Datenverantwortung liegen im Fachbereich – Engineering und Produktion. Das ist der zentrale Paradigmenwechsel gegenüber klassischen Datenprojekten.
Mit einem strukturierten Erstgespräch: Ausgangslage, Fokus-Modul-Vorschlag, Business Case und methodisches Vorgehen. In der Regel innerhalb weniger Wochen zu einem klaren Startpunkt für den ersten Durchstich.