DWC Insight 302 · Executive Decision Guide
Vom Kundenversprechen zur installierten Maschine
Wie eine Vision-Inspektion als Kundenkonfiguration, technische Baseline, Fertigungsstruktur und servicefähiger As-built-Stand entsteht.
Der Beitrag folgt einer Kamera in einer modularen Verpackungsmaschine durch Vertrieb, Engineering, Produktion und Service. Er zeigt, warum dasselbe reale Objekt je Verantwortungsbereich einen anderen verbindlichen Stand benötigt – und wie diese Stände kontrolliert verbunden bleiben.
Executive Summary
Die Kamera wechselt nicht nur das System – sie wechselt ihren fachlichen Status.
- Der Vertrieb verkauft ein Prüfergebnis, keine Kamera. Der spätere Service muss dennoch wissen, welche Kamera, welcher Softwarestand und welcher Parametersatz tatsächlich ausgeliefert wurden.
- Die Kamera wird in vier Verantwortungsbereichen unterschiedlich betrachtet: als Teil eines Kundenversprechens, als freigegebene technische Lösung, als beschafftes und eingebautes Objekt sowie als servicefähiger Bestandteil der installierten Maschine.
- Die Maximal- beziehungsweise Variantenstruktur beschreibt den wiederverwendbaren Lösungsraum. Sie ist kein auftragsbezogenes Zwischenergebnis, das als 150-Prozent-Auftrag durch das Unternehmen wandert.
- Der Freeze ist kein Änderungsverbot. Er markiert den Wechsel von kontrollierter Fortschreibung zu einer ausdrücklich zu entscheidenden und nachzuweisenden Änderung.
- Durchgängigkeit entsteht nicht durch eine universelle Stückliste, sondern durch kontrollierte Übergänge zwischen den vier Bereichen. Ein belastbarer Pilot muss deshalb auch Änderungen, Engineering-Deltas, Ersatzverwendungen und Ist-Rückmeldungen beherrschen.
Leitthese: Durchgängigkeit beweist sich an der beherrschten Änderung – nicht an der ersten erfolgreichen Übertragung.
Der Vertrieb verkauft eine geprüfte Packung – keine Kamera
Ein Hersteller bietet eine modulare Sekundärverpackungslinie an. Der Auftrag umfasst zwei Packungsformate, eine definierte Durchsatzklasse, eine Vision-Inspektion mit kontrollierter Ausschleusung, die Anbindung an eine vorhandene Linie sowie einen regionalen Sicherheits-, Dokumentations- und Serviceumfang.
Aus Kundensicht zählt das Ergebnis: Nicht konforme Packungen sollen erkannt und kontrolliert ausgeschleust werden. Aus technischer Sicht entsteht daraus ein Lösungsmodul mit Kamera, Optik und Beleuchtung, Halterung, Triggersensorik, Verkabelung, Steuerungsanbindung, Softwarefunktion und Parametersatz. Produktion benötigt konkrete Materialien und Arbeitsgänge; Service benötigt später Identität, Softwarestand, Ersatzteilkompatibilität und den Bezug zum ausgelieferten Stand.
Die zentrale Aufgabe digitaler Durchgängigkeit liegt zwischen diesen Perspektiven. Ein Angebot, eine eBOM, eine mBOM und ein As-built-Datensatz dürfen nicht zu einer vermeintlich universellen Produktwahrheit verschmolzen werden. Sie müssen als zweckgebundene, miteinander verbundene Sichten entstehen.
Zwei Ebenen statt einer linearen Stücklistenkette
Produktoberfläche und konkrete Ausprägung
Der Lösungsraum liegt über der Auftrags- und Lebenszykluskette.
Produktfamilie und Module · Merkmale und Regeln · Maximal- beziehungsweise Variantenstruktur · freigegebene technische Lösungsbausteine · zulässige Kamera-, Beleuchtungs-, Software- und Schnittstellenvarianten
Die Maximalstruktur wandert nicht als 150-Prozent-Auftrag durch das Unternehmen. Sie beschreibt den freigegebenen Lösungsraum, aus dem eine konkrete Ausprägung abgeleitet wird.
Ebene 2 · Konkrete Auftrags- und Lebenszykluskette
Prüfleistung · Formate · Durchsatz · Ausschleusung · Dokumentation · Service · Preis- und Angebotsbezug
Vision-Modul · Kamera · Beleuchtung · Halterung · Trigger · Steuerung · Software · Engineering-Delta
Auftragsspezifisch vollständig bestimmter Zielstand; Begriff bewusst als nicht universell normiert verwendet
Werk · Material · Lieferant · Montage · Verkabelung · Parametrierung · Inbetriebnahme · Prüfung
Tatsächliche Komponenten · genehmigte Alternativen · Identität · Firmware · Parameter · Prüfstand
Assetbezug · Dokumentation · Wartung · Ersatzteilfähigkeit · Diagnose · Retrofit · tatsächliche Änderungen
Leselogik: Die Sales-BOM ist eine bestell- und kalkulierbare Kundensicht. Die technische Baseline und konkrete eBOM beschreiben die freigegebene technische Ausprägung. Die 100-%-Sollstruktur beschreibt den für diesen Auftrag vollständig bestimmten Zielstand. mBOM und Bill of Process machen ihn werk- und ausführungsfähig. As-built, As-delivered und Installed Base halten fest, was tatsächlich realisiert und später verändert wurde.
Die Kamera durchläuft die vier Bereiche aus Insight 301
Die vier Bereiche beschreiben keine nacheinander geschalteten Softwarepakete. Sie markieren unterschiedliche fachliche Verantwortungen. Dasselbe reale Objekt – hier die Kamera des Vision-Moduls – erhält deshalb je Bereich einen anderen Kontext, einen anderen verbindlichen Stand und andere Verbraucher.
Interaktiver Objektpfad
Ein reales Objekt – vier fachliche Zustände
Wählen Sie einen Verantwortungsbereich. Ohne JavaScript bleiben alle vier Erläuterungen vollständig sichtbar.
1. Markt und Vertrieb: Prüfleistung als Kundenversprechen
Der Kunde bestellt keine Kamerabaureihe, sondern eine nachweisbare Prüfleistung: definierte Packungsmerkmale erkennen, fehlerhafte Einheiten ausschleusen, vereinbarten Durchsatz erreichen und die Prüfung dokumentieren. CRM hält Kunden-, Opportunity- und Linienkontext. CPQ übersetzt den Bedarf in eine gültige Konfiguration, Sales-BOM, Preis- und Angebotsposition. PIM stellt freigegebene Leistungsbeschreibungen und Dokumente bereit.
Die konkrete Kamera kann in diesem Bereich bewusst offenbleiben. Verbindlich ist das versionierte Kundenversprechen mit seinen Gültigkeiten und Abnahmekriterien.
Ergebnisobjekt: freigegebene Kundenkonfiguration einschließlich Sales-BOM und Angebotsbezug.
2. Entwicklung und Engineering: Aus Prüfleistung wird ein freigegebenes Vision-Modul
Engineering löst das Kundenversprechen technisch auf. PLM führt die technische Baseline und eBOM. MCAD bestimmt Sichtfeld, Arbeitsabstand, Halterung, Schutz und Einbauraum; ECAD beschreibt Versorgung, Signal- und Netzwerkanschlüsse sowie Verkabelung. Automatisierungs- und Softwareentwicklung ergänzen Triggerlogik, Bildauswertung, Schnittstellen, Softwarestand, Parametersatz und Testnachweis.
Jetzt wird die Kamera als Bestandteil eines freigegebenen Lösungsmoduls konkret. Standardkern und Engineering-Delta bleiben getrennt.
Ergebnisobjekt: freigegebene technische Baseline mit konkreter eBOM, Software-/Parameterbezug und nachvollziehbarer Herkunft aus der Kundenanforderung.
3. Auftrag und Produktion: Aus der Soll-Kamera wird die tatsächlich eingebaute Kamera
ERP übernimmt den freigegebenen Auftragsstand und ergänzt den operativen Auftrags-, Werk-, Material-, Beschaffungs- und Fertigungsbezug. Im hier dargestellten integrierten Zielbild erfolgt auch die auftragsspezifische Auflösung weitgehend ERP-nah. In einer differenzierten Architektur kann die technische 100-%-Ausprägung bereits in CPQ oder PLM entstehen; ERP bleibt dennoch führend für Auftrag, Disposition, Beschaffung, operative Fertigungsstruktur und Produktionsauftrag. MES beziehungsweise geeignete Ausführungsrückmeldungen bestätigen, welche Kamera tatsächlich entnommen, montiert, parametriert und geprüft wurde. Die Anforderungen an Version, Gültigkeit und Rückverfolgbarkeit bleiben in beiden Zielbildern gleich.
Die tatsächliche Kameraidentität, Firmware, der gültige Parametersatz und das Prüfergebnis entstehen nicht aus der Erwartung des Produktmodells, sondern aus der bestätigten Ausführung.
Ergebnisobjekte: auftragsspezifische 100-%-Sollstruktur, mBOM und Bill of Process sowie daraus bestätigtes As-built und As-delivered.
4. Service und Lifecycle: Die Kamera wird Teil der installierten Basis
Nach der Auslieferung verbindet die installierte Basis Maschinen- und Standortidentität mit Vision-Modul, tatsächlich verbauter Kamera, Software-/Firmwarestand, Parametersatz, Dokumentation und genehmigten Änderungen. Service- oder Asset-Management nutzt diesen Stand für Diagnose, Ersatz, Update, Wartung und Retrofit.
Eine spätere Ersatzkamera erzeugt einen neuen As-maintained-Stand; sie darf den historischen As-built-Nachweis nicht überschreiben. Rückmeldungen können Produktentwicklung und Ersatzteilstrategie verbessern, bleiben aber von der Dokumentation des konkreten Assets getrennt.
Fällt die Kamera nach mehreren Betriebsjahren aus, ist ein aktuelles Nachfolgemodell erst dann ein zulässiger Ersatz, wenn mechanische, elektrische, softwareseitige und prüftechnische Kompatibilität für genau diesen installierten Stand nachgewiesen sind. Der Produktname allein beantwortet diese Frage nicht.
Ergebnisobjekt: servicefähige Installed Base mit nachvollziehbarer Verbindung zum Kundenversprechen und zur freigegebenen technischen Baseline.
Vier Kontrollen an jeder Übergabe
Der fachliche Übergabevertrag ist die konkrete Ausprägung des in der Architektur angelegten Verantwortungswechsels. Er muss nicht als zusätzliches Dokument entstehen; die vier Fragen müssen jedoch technisch und organisatorisch beantwortet sein.
Ausgangsobjekt und Stand
Welches freigegebene Objekt gilt und aus welcher Quelle stammt es?
Gültigkeit
Für welchen Auftrag, Markt, Termin, Produktstand oder welches Werk gilt das Ergebnis?
Transformation
Was wird direkt übernommen, regelbasiert aufgelöst oder durch einen benannten Owner ergänzt?
Zielobjekt und Rückverweis
Welches Ergebnis darf der nächste Prozess übernehmen und wie bleibt die Herkunft nachvollziehbar?
Zwei Belastungsproben über die vier Bereiche
Ein Idealauftrag beweist, dass eine Schnittstelle Daten übertragen kann. Ob die Architektur trägt, zeigt sich erst dann, wenn Leistungsversprechen, technische Lösung, Auftragsstand oder tatsächlich verwendete Komponente geändert werden.
Vor dem Freeze: Aus Anwesenheitskontrolle wird Codeprüfung
Zunächst soll die Vision-Inspektion nur prüfen, ob ein definiertes Merkmal vorhanden ist. Noch vor dem technischen Freeze erweitert der Kunde die Aufgabe: Ein aufgedruckter Code soll gelesen und mit Auftragsdaten abgeglichen werden. Das ist kein bloßer Tausch der Kamera. Das Leistungsversprechen verändert sich.
Markt und Vertrieb versionieren Kundenkonfiguration, Angebot und Abnahmekriterium. Entwicklung und Engineering prüfen anschließend, ob das freigegebene Standardmodul die zusätzliche Aufgabe erfüllt. Reichen Standardkamera, Beleuchtung und Softwarefunktion aus, kann die neue technische Baseline aus dem bestehenden Lösungsraum erzeugt werden. Reichen sie nicht aus, entsteht ein begrenztes Engineering-Delta – beispielsweise für Optik, Beleuchtung, Schutz, Schnittstelle oder Parametrierung.
Erst nach Prüfung und Freigabe darf Auftrag und Produktion den aktualisierten Sollstand übernehmen. Preis, Lieferzeit, Dokumentation und Abnahmekriterien können sich ebenfalls verändern; Service und Lifecycle benötigen bereits jetzt den vorgesehenen Dokumentations- und Prüfbezug. Vor dem Freeze darf die Lösung weiterentwickelt werden – ein neuer Kundenwunsch darf dennoch keinen bereits referenzierten Stand still überschreiben.
Vom Standardkern zur ausführbaren Struktur
Nicht jede Information wird auf dieselbe Weise überführt. Im Praxisfall treten vier Transformationsmuster nebeneinander auf:
Auftrags-, Markt-, Format- und vereinbarter Dokumentationsbezug
Kontrollpunkt: Stand und Gültigkeit bleiben identisch referenziert.
Kamera, Beleuchtung, Softwarefunktion und Standardzubehör aus freigegebenem Lösungsraum
Kontrollpunkt: Regel- und Modellstand sind reproduzierbar.
Werk, Material, Lieferant, Kabellänge, Montage-, Parametrier- und Prüfschritte
Kontrollpunkt: Owner und Zielobjekt sind benannt; Ergänzung ist keine verdeckte Neuinterpretation.
Kundenspezifische Linienanbindung, Schutz, Signalübergabe oder mechanische Aufnahme
Kontrollpunkt: Delta, Prüfung, Freigabe und Rückführung in Standard oder Projekt bleiben getrennt.
Nach dem Freeze: Die freigegebene Kamera wird abgekündigt
Nach dem Freeze ist die freigegebene Kamera nicht mehr lieferbar. Auftrag und Produktion lösen damit den konkreten Änderungsbedarf aus; Entwicklung und Engineering müssen das Nachfolgemodell technisch qualifizieren. Ein vermeintlich gleichwertiges Modell darf nicht nur als Materialersatz behandelt werden. Betroffen sein können Halterung und Einbauraum, Stecker und Kabel, Steuerungskommunikation, Treiber, Firmware, Parametersatz, Prüf- und Abnahmevorgang, Dokumentation sowie Ersatzteil- und Servicekompatibilität.
Markt und Vertrieb werden einbezogen, sobald Preis, Termin oder zugesagte Leistung betroffen sind. Service und Lifecycle prüfen Ersatzteilfähigkeit, Dokumentation und spätere Kompatibilität. Jetzt sind zwei Änderungswege ausdrücklich zu trennen:
Eingefrorener Auftrag
Genehmigter Änderungsvorgang für den konkreten Auftrag · Bewertung bereits ausgelöster Beschaffung oder Montage · geprüftes technisches Delta · aktualisierte Soll-Baseline · dokumentierte Auswirkung auf Termin, Preis, Prüfung und Service
Zukünftiger Produktstandard
Änderung des wiederverwendbaren Produktmodells · neue Kamera- oder Schnittstellenvariante · Anpassung von Regeln und Freigaben · Regression betroffener Varianten · neue Gültigkeit für erst danach erzeugte Aufträge
As-built entsteht aus bestätigter Ausführung
Die aktualisierte Sollstruktur sagt, was nach der genehmigten Änderung gebaut werden soll. Ob dieser Stand tatsächlich realisiert wurde, ergibt sich erst aus der Ausführung. Deshalb müssen Materialentnahme, Montage, Inbetriebnahme, Ersatzverwendung, Prüfung und Nacharbeit in geeigneter Tiefe zurückgemeldet werden.
Für die Kamera bedeutet das: tatsächliche Identität, kompatibler Software-/Firmwarestand, gültiges Prüfprogramm, Parametersatz und Bezug zur genehmigten Änderung. As-built entsteht nicht aus dem erwarteten Soll, sondern aus bestätigten Ausführungsereignissen.
Der Service erhält dadurch keine isolierte Ersatzteilliste, sondern einen Rückweg: installierte Maschine → tatsächlich verbaute Kamera → genehmigter Änderungsstand → technische Baseline → ursprüngliche Prüfanforderung. Erst diese Herkunftskette macht spätere Diagnose, Ersatz und Retrofit belastbar.
Rückwärts nachvollziehbar
Service benötigt den Weg vom Asset zurück zum Kundenversprechen.
Was ein belastbarer Pilot zeigen muss
Ein Pilot sollte die Architektur nicht nur am reproduzierbaren Idealauftrag demonstrieren. Er muss mindestens folgende Situationen sichtbar beherrschen:
einen standardnahen Auftrag mit reproduzierbarer Konfiguration und Strukturauflösung,
eine Kundenänderung vor dem Freeze mit neuem Leistungs- und Konfigurationsstand,
ein begrenztes Engineering-Delta mit klarer Freigabe,
eine Komponentenänderung nach dem Freeze, getrennt für laufenden Auftrag und zukünftigen Standard,
die bewusste Behandlung bereits ausgelöster Beschaffung, Montage oder Prüfung,
den Soll-Ist-Abgleich bis As-built beziehungsweise As-delivered,
eine servicebezogene Rückwärtssuche vom Asset bis zum Kundenversprechen.
Fazit für Entscheider
Durchgängigkeit beweist sich an der beherrschten Änderung.
Die Verpackungsmaschine zeigt: Digitale Durchgängigkeit entsteht nicht durch eine gemeinsame Stückliste. Kundenversprechen, Produktdefinition, Sollstruktur und gebaute Maschine werden durch klare Gültigkeiten und nachvollziehbare Ableitungen verbunden.
Der Belastungstest beginnt bei der Änderung. Ein Kundenwunsch vor dem Freeze und eine Kameraabkündigung danach verlangen verschiedene Wege; ein eingefrorener Auftrag darf weder per Materialtausch noch per Neugenerierung mit dem neuesten Produktmodell überschrieben werden.
As-built und Installed Base schließen die Kette. Erst wenn der ausgelieferte Stand zur Konfiguration und zum genehmigten Änderungsweg zurückführt, ist belastbare Produkt- und Auftragsdurchgängigkeit erreicht.
Durchgängigkeit beweist sich an der beherrschten Änderung – nicht an der ersten erfolgreichen Übertragung.
English Executive Summary
From Customer Promise to the Installed Machine
A customer buying a modular packaging line does not primarily order a specific camera model. The commercial commitment concerns inspection performance, throughput, controlled rejection, documentation and acceptance criteria. Engineering must translate that promise into an approved vision module, while operations must identify what was actually procured, installed, parameterised and tested.
The same camera therefore has four different binding contexts: part of a customer configuration and Sales BOM, part of an approved technical baseline and eBOM, part of an executable manufacturing structure and confirmed as-built record, and finally part of the installed base used for service, replacement and retrofit decisions. These views must remain connected without being collapsed into one supposedly universal bill of material.
The decisive test is change. A broader inspection requirement before the technical freeze and a discontinued camera after the freeze require different approval and transformation paths. A frozen order must not be silently regenerated from a later product model, and an as-built record must be based on confirmed execution rather than the expected target structure.
End-to-end continuity is achieved when every result has a clear source, validity, owner and target object – and when the installed machine can be traced back through the approved technical baseline to the original customer promise.