DWC Insight 303 · Executive Decision Guide

Wie viel Software-Ökosystem braucht ein variantenreicher Maschinenbauer?

Wann Analyse-, Modularisierungs-, Pflege- und Automatisierungswerkzeuge echte Lücken schließen – und wann sie neue Dauerlast erzeugen.

Zusatzwerkzeuge können Portfolioanalyse, Modularisierung, Migration, Engineering-Automatisierung und Qualitätssicherung erheblich verbessern. Der Projektnutzen allein entscheidet jedoch nicht über ihre dauerhafte Rolle. Maßgeblich ist, ob sie über einen vollständigen Änderungszyklus mehr Komplexität beseitigen, als sie durch zusätzliche Modelle, Schnittstellen, Tests, Releases, Kompetenzen und Exit-Pflichten neu erzeugen.

Executive Summary

Nicht jede fachliche Lücke braucht eine dauerhafte Plattform.

• Variantenreiche Maschinenbauer ergänzen CRM, PIM, PLM, CPQ und ERP häufig um spezialisierte Werkzeuge für Portfolioanalyse, Modularisierung, Modellpflege, Migration, Engineering-Automatisierung oder Qualitätssicherung.
• Viele dieser Werkzeuge schließen eine reale Lücke. Daraus folgt noch nicht, dass sie eine dauerhafte Rolle in der Zielarchitektur benötigen.
• Zu unterscheiden sind drei Betriebsmodelle: Aufgabe im Kernsystemverbund, zeitlich begrenztes Projektwerkzeug oder dauerhaft verantwortete Spezialplattform.
• Maßgeblich sind die wiederkehrende Aufgabe, das verbindliche Objekt und die Gesamtwirkung über einen vollständigen Änderungszyklus – nicht die Attraktivität einer Demonstration.
• KI und Low-Code erweitern die Realisierungsoptionen. Sie ändern nicht die Anforderungen an Verantwortung, Test, Security, Dokumentation, Betrieb und Exit.

Leitthese: Eine Zusatzrolle ist erst begründet, wenn ihre Entlastung die neue Dauerlast aus Modellen, Schnittstellen, Tests, Releases, Kompetenzen, Kosten und Exit übersteigt.

Der Werkzeugzoo ist selten geplant

Zusatzwerkzeuge entstehen meist aus berechtigten Einzelentscheidungen. Eine Produktfamilie soll analysiert, ein Baukasten entwickelt, ein Konfigurationsmodell migriert, eine Massenpflege beschleunigt, CAD automatisiert, eine Vertriebsvisualisierung erzeugt oder ein komplexer Release getestet werden. Für jede Aufgabe gibt es spezialisierte Lösungen – und häufig einen überzeugenden Projektstart.

Problematisch wird nicht die einzelne Entscheidung, sondern ihre Verstetigung. Ein temporäres Analysemodell wird zur dauerhaften Produktquelle. Ein Projektwerkzeug erhält Schnittstellen zu PLM, CPQ und ERP. Eine zweite Regelbasis entsteht. Releases müssen abgestimmt, Kompetenzen aufgebaut und externe Abhängigkeiten finanziert werden. Am Ende existieren neben den Kernsystemen mehrere parallele Produktbilder, obwohl die ursprüngliche Aufgabe längst abgeschlossen ist.

Die richtige Gegenfrage lautet deshalb nicht: Ist das Werkzeug leistungsfähig? Sondern: Welche wiederkehrende Aufgabe und welches verbindliche Objekt rechtfertigen seinen dauerhaften Betrieb – und welche Komplexität entfällt dadurch tatsächlich?

Die Entscheidungseinheit ist Aufgabe × Objekt × Betriebsmodell

Produktvergleiche greifen zu kurz, weil dieselbe Software sehr unterschiedliche Rollen übernehmen kann. Für die Architekturentscheidung sind drei Elemente gemeinsam zu betrachten:

Eine Funktion ohne verbindliches Objekt ist oft Projekthilfe. Ein verbindliches Objekt ohne dauerhaften Owner ist ein Betriebsrisiko. Eine dauerhafte Plattform ohne wiederkehrenden Nutzen ist zusätzliche Architektur- und Kostenlast.

Projekthilfe oder Unternehmenssystem?

Der kritische Übergang liegt nicht beim Kaufvertrag, sondern dort, wo ein Werkzeug Teil des operativen Änderungs- und Freigabeprozesses wird. Fünf Fragen markieren diese Schwelle:

Vom Projektwerkzeug zur Plattform – oft ohne bewusste Entscheidung

Viele zusätzliche Plattformen gelangen nicht über einen klassischen Auswahlprozess in die Unternehmensarchitektur. Sie wachsen aus einer fachlich berechtigten Projektaufgabe heraus. Der Übergang ist nicht grundsätzlich falsch. Kritisch ist, wenn er ohne eigenständige Architektur-, Betriebs- und Investitionsentscheidung erfolgt.

Visualisierung · Schleichende Plattformisierung

Aus einer Projekthilfe wird in fünf Schritten ein Unternehmenssystem

Die Visualisierung beschreibt keinen Automatismus. Sie markiert die Punkte, an denen eine separate Systementscheidung erforderlich wird.

Methodische Aufgabe

Analyse, Modularisierung, Migration oder Bereinigung starten als begrenztes Projekt.

Gemeinsames Arbeitsmodell

Das Werkzeug schafft Transparenz und wird zum zentralen Kommunikations- und Entscheidungsraum.

Operative Nutzung

Ergebnisse werden regelmäßig aktualisiert, geprüft oder von Folgeprozessen konsumiert.

Integration und Betrieb

Schnittstellen, Rollen, Lizenzen, Support und Releasepflichten werden ergänzt.

Faktische Bindung

Das Modell ist so wichtig, dass Abschaltung oder Wechsel einer Neuimplementierung gleichkommen.

Entscheidungstor: Sobald ein Projektergebnis nach Projektende regelmäßig verändert, freigegeben oder operativ konsumiert wird, muss seine dauerhafte Systemrolle separat entschieden werden – einschließlich Owner, Zielobjekt, Integration, Lebenszykluskosten und Exit.

Werkzeugtypen statt Anbieterkarte

Zum erweiterten Software-Ökosystem zählen Werkzeuge für Portfolio- und Modularisierungsanalysen, Varianten- und Beziehungswissen, Produktdatenanalyse und -anreicherung, Modellpflege, Visualisierung sowie Low-Code- oder KI-gestützte Anwendungen. Ob daraus eine dauerhaft benötigte Systemrolle entsteht, entscheidet sich nicht am Produktnamen, sondern an Aufgabe, führendem Objekt, Integration, Governance, Betriebsaufwand und Exit-Fähigkeit.

Die Aufgaben können durch Spezialsoftware, Funktionen bestehender Kernsysteme oder unternehmensspezifische Anwendungen abgedeckt werden. Der Beitrag bewertet deshalb bewusst keine einzelnen Produkte. Für eine neutrale Entscheidung ist eine Aufgabenkarte hilfreicher als eine Herstellerliste:

Vier typische Entstehungspfade – und die Entscheidung dahinter

Die Frage nach der dauerhaften Systemrolle wird greifbarer, wenn sie nicht abstrakt, sondern am Entstehungspfad des Werkzeugs geprüft wird. Die folgenden verdichteten Praxismuster sind keine Produktbewertungen. Sie zeigen, an welchem Punkt aus einer sinnvollen Projekthilfe ein dauerhaft zu verantwortendes Unternehmenssystem werden kann.

Drei legitime Betriebsmodelle

Eine schmale Eigenentwicklung, KI- oder Low-Code-Lösung ist kein viertes Betriebsmodell. Sie kann im Kernsystemverbund, als temporäres Werkzeug oder als dauerhafte Spezialrolle umgesetzt werden und muss nach denselben Kriterien bewertet werden.

Was die Projektkalkulation häufig ausblendet

Lizenz und Einführung sind sichtbar, aber selten die vollständige Komplexitätsbilanz. Vier Kosten- und Abhängigkeitsklassen sollten getrennt betrachtet werden:

Diese Klassen müssen nicht in eine scheinbar exakte Punktzahl überführt werden. Sie zwingen jedoch dazu, den Projektvorteil gegen die gesamte Dauerwirkung zu stellen.

Die symmetrische Komplexitätsbilanz

Abhängigkeit ist eine Architekturgröße – kein Vorwurf

Vendor-Lock-in wird häufig auf Vertragslaufzeit oder Exportfunktion reduziert. Für Produkt- und Konfigurationsmodelle ist die Abhängigkeit breiter. Dabei sind zwei Ebenen zu unterscheiden:

Vendor-Lock-in entsteht durch proprietäre Formate, APIs, Laufzeiten, Lizenzmodelle, Cloud-Betrieb oder spezifische Partnerkompetenz. Architektur-Lock-in entsteht, wenn Geschäftslogik, Prozesse und Verantwortungen so eng an eine Lösung gekoppelt sind, dass selbst ein technisch vollständiger Export keinen praktikablen Wechsel ermöglicht.

Exit-Test

Ein Export ist Voraussetzung – aber noch kein Exit-Nachweis.

Übertragbarkeit ist erst belegt, wenn ein repräsentativer Ausschnitt außerhalb der bisherigen Lösung fachlich verstanden, verändert, geprüft und wieder betrieben werden kann. Übertragene Werte ohne Semantik, Regeln, Historie und Betriebswissen sind noch kein Exit.

Ausschnitt wählen

Repräsentative Objekte, Beziehungen, Gültigkeiten, Regeln, Historie und mindestens einen Ausnahmefall einbeziehen.

Übergabepaket erzeugen

Daten, Semantik, Regelbeschreibung, Testfälle, Freigabestand und technische Dokumentation zusammenführen.

Unabhängig verstehen

Ein anderes Team rekonstruiert den Ausschnitt ohne implizites Wissen des bisherigen Werkzeugs oder Partners.

Reale Änderung ausführen

Komponente ersetzen, Gültigkeit ändern oder Regel ergänzen und erwartete Ergebnisobjekte neu erzeugen.

Betrieb nachweisen

Änderung, Test, Freigabe und Veröffentlichung müssen außerhalb der bisherigen Lösung reproduzierbar funktionieren.

Die Bewertung muss unabhängig von Bezugsform und Eigeninteresse symmetrisch bleiben. Ein spezialisiertes Softwarepaket, eine intern bevorzugte Eigenentwicklung und der Ausbau vorhandener PLM-, CPQ- oder ERP-Funktionen sind an denselben Kriterien zu messen. Sind Problembeschreibung, Zielbild, Auswahl und Umsetzung organisatorisch oder wirtschaftlich eng gekoppelt, sollte die dauerhafte Systemrolle in einem separaten Architektur- und Investitionsentscheid freigegeben werden. Neutralität zeigt sich an dokumentierten Alternativen, vollständigen Betriebskosten und einer realistischen Exit-Gegenprobe.

KI und Low-Code verändern die Option – nicht die Grundregel

Neue Realisierungsoptionen

KI senkt die Entwicklungsschwelle – nicht die Betriebsschwelle.

KI-gestützte Entwicklung und Low-Code können schmale, unternehmensspezifische Werkzeuge wirtschaftlicher machen: Datenanalyse, Mapping, Prüfungen, Autorenunterstützung, Dokumentenvergleich oder kleine Workflows lassen sich näher am konkreten Produkt und Prozess gestalten. Dadurch wird eine Eigenlösung in Fällen realistisch, in denen früher nur ein umfangreiches Paket wirtschaftlich erschien.

Sobald eine Lösung technisch oder geschäftlich relevante Entscheidungen erzeugt, gelten Anforderungen an Datenzugriff, Security, Dokumentation, Test, Freigabe, Monitoring, Modell- und Promptänderung, Support und Exit. Eine schnell erzeugte Anwendung kann sinnvoll sein – sie ist nicht automatisch eine wartbare Unternehmensrolle.

Gut begrenzbare Assistenz

• Varianten- und Strukturanalyse
• Dubletten- und Inkonsistenzhinweise
• Mapping- und Migrationsvorschläge
• Vorbereitung von Testfällen
• Dokumentations- und Navigationshilfen

Nur mit deterministischer Absicherung

• technische Zulässigkeit
• Preis- und Margenentscheidungen
• sicherheits- oder compliance-relevante Freigaben
• produktive Stücklisten- und Arbeitsplanerzeugung
• versionierte Modell- und Promptlogik

Die Praxisprobe: ein vollständiger Produktwechsel

Verdichtetes Praxisbild · Vision-Modul

Die Kamera wird abgekündigt. Jetzt zeigt sich die wirkliche Systemrolle.

Der Fall aus Insight 302 eignet sich unmittelbar als Praxisprobe: Die freigegebene Kamera des Vision-Moduls wird abgekündigt. Zu prüfen ist dann nicht, wie gut ein Werkzeug diese Änderung darstellt, sondern an wie vielen Stellen sie nachgezogen werden muss – Konfigurationsmodell, technische Baseline, CAD-Ableitung, Materialstamm, Prüfplan, Dokumentation und Servicekatalog.

Gemessen wird, welche Arbeit das Zusatzwerkzeug tatsächlich eliminiert und welche neuen Schritte nur wegen seiner Existenz erforderlich werden. Entscheidend ist, ob es die Änderung über diese Stationen nachweisbar vereinfacht oder lediglich eine weitere Repräsentation erzeugt, die zusätzlich synchronisiert, getestet und freigegeben werden muss.

A · Kernsystemverbund

Technische Freigabe und Nachfolgerbeziehung werden in den führenden Kernobjekten gepflegt. Konfigurations-, Auftrags- und Servicewirkungen fließen in den bestehenden Test- und Releaseweg. Die Gegenprobe lautet: Reichen diese Rollen aus oder entstehen manuelle Workarounds, weil eine spezialisierte Autoren- oder Prüffunktion fehlt?

B · Temporäres Projektwerkzeug

Das Werkzeug analysiert betroffene Varianten, unterstützt Mapping oder Datenbereinigung und liefert geprüfte Überführungsobjekte. Danach bleiben keine produktiven Regeln oder Freigaben ausschließlich darin zurück. Die Gegenprobe lautet: Kann dieselbe Änderung nach Projektende ohne das Werkzeug wiederholt werden?

C · Dauerhafte Spezialplattform

Die Plattform übernimmt eine wiederkehrende, abgegrenzte Aufgabe – etwa Autorenunterstützung, übergreifende Regression oder Engineering-Automatisierung – und erzeugt ein versioniertes Ergebnis. Die Gegenprobe lautet: Beseitigt diese Rolle über viele Änderungen hinweg mehr Aufwand, als sie neu erzeugt?

Für stabile, häufig wiederholte CTO-Aufgaben kann eine dauerhafte Spezialrolle wirtschaftlich sein. Bei hohen ETO-Anteilen, einmaligen Analysen oder stark wechselnden Lösungsräumen kann ein temporäres Werkzeug oder eine bewusst schmale Eigenlösung besser passen. Das ist keine Branchenregel, sondern eine Gegenprobe auf Wiederholgrad, Stabilität und Betriebsfähigkeit.

Sechs Schritte zur begründeten Zusatzrolle

Fazit für Entscheider

Ein Projektvorteil begründet noch keinen Dauerbetrieb.

Entscheidend sind die wiederkehrende Aufgabe, das verbindliche Objekt und ein dauerhaft beherrschbarer Betrieb. Die Lösung kann im Kernsystemverbund, in einem befristeten Werkzeug, in einer begrenzten Spezialrolle oder in einer bewusst schmalen Eigenlösung liegen. Keine Option ist grundsätzlich überlegen.

Eine Zusatzrolle ist erst belastbar, wenn fachlicher und technischer Owner, ein Nutzenbeleg über einen vollständigen Änderungszyklus und ein praktisch geprüfter Exit feststehen.

Das Ziel ist nicht möglichst wenig Software. Das Ziel ist eine Landschaft, in der jedes dauerhaft betriebene Werkzeug mehr Komplexität beseitigt, als es neu erzeugt.

English Executive Summary

How Much Software Ecosystem Does a High-Variety Machinery Business Need?

Specialised tools can create substantial value in portfolio analysis, modularisation, configuration-model maintenance, migration, engineering automation, visualisation and cross-system testing. A successful project, however, does not by itself justify turning the project tool into a permanent enterprise platform.

The decision should be based on three elements: the recurring task, the authoritative object created or changed, and the operating model. The task may remain in the core-system landscape, be supported by a temporary project tool, or require a permanently governed specialist platform. A narrow AI, low-code or custom application is not a fourth model; it must pass the same ownership, testing, security, lifecycle and exit requirements.

The relevant measure is the net effect across a complete change cycle. A tool must remove more manual work, delay, error and coordination than it adds through duplicate models, mappings, interfaces, regression, releases, specialised skills, operating cost and exit effort. A data export alone does not prove portability. A representative model must be understood, changed, tested and operated outside the original solution.

The target is neither the smallest possible tool landscape nor maximum platform coverage. It is an architecture in which every permanent system role has a clearly bounded responsibility and removes more complexity than it creates.

Weiterführende Insights

Position: Säule 3 · Produktstrukturen und Systemdurchgängigkeit · Beitrag 3 von 3

• Insight 301 – Der digitale Produkt-Backbone im Maschinenbau
• Insight 302 – Vom Kundenversprechen zur installierten Maschine
• Insight 207 – S/4HANA-Migration und CPQ-Zielarchitektur

Vorheriger Beitrag: Insight 302 – Vom Kundenversprechen zur installierten Maschine

Nächster Beitrag: — Abschluss der Säule

Zur Übersicht aller Executive Insights