„Part-Centric“-Datenkonzept zur beschleunigten Produktdatenrecherche

Anforderungen an eine moderne, serviceorientierte Datenverwaltung

Ziel von Serviceanbietern für Investitionsgüter ist es, den Kunden – den Betreibern der Investitionsgüter – effektive Serviceleistungen zeitnah und zu wettbewerbsfähigen Konditionen anzubieten [1], um dadurch beim Kunden eine hohe Verfügbarkeit und geringe Stillstandszeiten der installierten Investitionsgüter zu gewährleisten. Mangelnde Effektivität, lange Implementierungszeiten und hohe Aufwände bei der Erbringung der Serviceleistungen werden häufig durch eine mangelnde Verfügbarkeit technischer Daten verursacht, die im Laufe des Produktlebenszyklus entstehen, wie z. B. Messdaten aus der Teilefertigung, Chargeninformationen oder Produkt- und Produktionsinformationen. Um das Auffinden von Daten zu verbessern, werden in der Praxis Datensätze z. B. mit Metadaten und Klassifizierungen versehen. Mit dem „Part-Centric“-Ansatz und seinen eindeutigen Suchkriterien [2] kann eine deutliche Zeiteinsparung bei der Suche bauteilbezogener Daten erzielt werden.

Allerdings erschweren heterogene IT-Systemlandschaften, wie sie in den meisten Unternehmen bestehen, die Suche nach bauteilbezogenen Daten, die allein auf Metadaten oder einer Klassifizierung basiert. Grund dafür sind unterschiedliche Datenstrukturen und –modelle ohne Verknüpfung der Daten in den einzelnen IT-Systemen, was vor allem durch die zunehmende Anzahl an Expertensystemen verursacht wird. In diesem Fall können nicht alle notwendigen Daten mit Bezug zu einem Bauteil oder einer Baugruppe im Rahme eines Suchvorgangs ermittelt werden, sondern die Suche muss in jedem einzelnen IT-System getrennt und gemäß der IT-Systeme und deren Datenmodell spezifischen Suchlogik durchgeführt werden (siehe gestrichelte Pfeile in Bild 1(a)). Das heißt, dass die mangelnde Verknüpfung der Datenstrukturen und –modelle zwischen den einzelnen IT-Systemen zu einem hohen Aufwand bei der Suche und Nutzung aller bauteil- oder baugruppenbezogenen Daten führt. Dies kann signifikante Kosten zur Folge haben, die z. B. aus ungelösten Qualitätsproblemen im Produktionsprozess resultieren. [3]

Der „Part-Centric“-Ansatz ermöglicht eine integrierte und effiziente Suche über alle relevanten Daten eines Bauteils oder einer Baugruppe, ohne dass die Suche in jedem einzelnen IT-System separat durchgeführt werden muss. Bestehende, meist lokale Lösungsansätze in einzelnen Abteilungen werden so in eine neue Komplettlösung integriert ohne Redundanzen der Daten zu schaffen.

Außerdem führen zwischen den IT-Systemen entkoppelte Datenstrukturen und –modelle häufig zu einem IT-System-spezifischen Änderungsmanagement für Produktdaten wie der geometrischen Produktdefinition (3D-CAD-Modell, 2D-Zeichnung) und der zugehörigen Artikelstammsätze im PDM-/PLM-System. Ein Änderungsmanagement, das separat für jedes lokale IT-System durchgeführt wird, führt zu Unsicherheiten bezüglich der Aktualität der Produktdaten. Diese Unsicherheit wiederum führt zu langen Such- und Bearbeitungszeiten, was die Qualität und damit die Gesamtzufriedenheit beim Anwender mindert.[4] [5].

Mittels des „Part-Centric“-Ansatzes kann ein einheitliches und konsistentes Änderungsmanagement umgesetzt werden, das die Unsicherheiten hinsichtlich der Verlässlichkeit und Aktualität der Beschreibungsdaten eliminiert. Der „Part-Centric“-Ansatz ermöglicht durch seine durchgängige Verknüpfung aller bauteil- und baugruppenrelevanten Daten/Dokumente mit den virtuellen Repräsentanten des betreffenden Bauteils eine signifikante Aufwandssenkung für deren Suche und Nutzung [6]. Hierbei dienen die virtuellen Repräsentanten eines Bauteils bzw. einer Baugruppe als digitale „Sammler“ für alle dazu anfallenden Daten, die mithilfe von Datenstrukturen verknüpft werden (Bild 1 (b)).

Damit ermöglichen die, auf logischen Verknüpfungen basierenden „Part-Centric“-Datenstrukturen vom Functional- über das Manufacturing- bis zum Physical-Part eine effiziente Umsetzung von Instandhaltungs- und Servicemaßnahmen und tragen somit zu einer hohen Verfügbarkeit und zu geringen Stillstandszeiten von Investitionsgütern bei. Diese wiederum fördern eine hohe Kundenzufriedenheit [7] und den Erwerb anderer Produkte (Cross-Selling) sowie die positive Kommunikation am Markt [8].

Zudem verbessert die Artikel zentrierte („Part-Centric“) Datenverwaltung die Prozesssicherheit bei der Transformation von der 2D-Zeichnung basierten Arbeitsweise hin zu einer 3D-CAD-Modell basierten Arbeitsweise [9], da durch die Integration mithilfe von relationalen Datenstrukturen Datenredundanzen auf ein Minimum reduziert werden können. Bestehende Strukturen in der Dokumentenverwaltung werden zum „Functional-Part“ verknüpft und so integriert.

In Bezug auf die Konzepte des Digitalen Zwillings, des Digitalen Abbildes und des Digitalen Masters [10] kann der „Part-Centric“-Ansatz als eine integrale Methode zur Strukturierung und Organisation von Daten verstanden werden. Der Ansatz basiert darauf, dass Daten nicht nur auf Produkt- oder Systemebene gesammelt und analysiert werden, sondern auch auf Teile- oder Komponentenebene und zusätzlich miteinander verknüpft werden, was eine genauere Modellierung und Vorhersage des Systemverhaltens ermöglicht. Das „Part-Centric“-Konzept ist somit eine Methode zur Datenorganisation oder zur Datenmodellierung innerhalb der größeren Struktur eines Digitalen Zwillings, Digitalen Abbildes oder Digitalen Masters. Diese „Bauteil-zentrierten“ Daten können so in den Daten-Strukturierungs-Modellen verknüpft verwendet werden, um eine genauere Darstellung und Analyse des Gesamtdatensystems zu ermöglichen.

Es sei an dieser Stelle erwähnt, dass aktuelle Ansätze zur Datenstrukturierung durchaus existieren. Diese traditionellen Methoden konzentrieren sich jedoch überwiegend auf die Organisation von Daten auf Produkt- oder Systemebene. Sie bieten nicht die tiefe granulare Ebene der Datenverknüpfung und Modellierung, die der „Part-Centric“-Ansatz ermöglicht. Zudem sind viele dieser bestehenden Ansätze aufgrund ihrer linearen und segmentierten Strukturen oft weniger flexibel und adaptierbar, insbesondere in heterogenen IT-Umgebungen. Dies kann zu suboptimalen Suchergebnissen und ineffizienten Datenverarbeitungsmechanismen führen. Daher lässt sich postulieren, dass gegenwärtige Ansätze zur Datenstrukturierung für moderne Anforderungen, insbesondere im Kontext von Serviceorientierung, unzureichend sind. Dieser Mangel an Effizienz und Granularität in traditionellen Methoden unterstreicht die Bedeutung und Notwendigkeit des „Part-Centric“-Ansatzes.“

Bisher singulär existierende Datenablagen/Strukturen in PDM-/PLM-, ERP- oder MES-Systemen werden zum jeweiligen Entwicklungsstand der Bauteile/Baugruppen miteinander verknüpft und die Daten damit integriert.

Aufbau einer Part Logik zur beschleunigten Datenrecherche und einfacheren Fehlerursachenanalyse

Während in der Entwicklung von Produkten der Fokus auf den funktionalen Eigenschaften und Zusammenhängen liegt, liegt in der Produktionsplanung das Augenmerk auf den fertigungs- oder montagetechnischen Aspekten. Im Service oder in der Kundenbetreuung betrachten Anwender meist ein physisch gefertigtes Bauteil/Produkt, das sich einem Kunden zuordnen lässt und das im Laufe seiner Nutzung z. B. beschädigt werden kann. Außerdem können Bauteile, die die gleichen funktionalen Anforderungen erfüllen, in verschiedenen Ausprägungen realisiert werden, z. B. bei einer standortspezifischen Ausprägung des Fertigungsprozesses. Damit besteht eine 1:n-Beziehung zwischen den funktionalen Anforderungen an ein Bauteil und den Fertigungsprozessen zur Herstellung des Bauteils (z. B. Arbeitsplan) sowie den schließlich gefertigten physischen Bauteilen (Bild 2).

Als „Functional Part“ (FP) wird ein Objekt innerhalb eines PDM-/PLM-Systems bezeichnet, an welchem sämtliche funktionalen Informationen definiert werden. Die Daten, die mit einem FP verknüpft werden, fallen hauptsächlich im Produktentwicklungsprozesses an. Hierzu zählen u. a. Patente, Marktanalysen und daraus abgeleitete funktionale Anforderungen in Form von 3D-CAD-Definitionen oder den davon abgeleiteten 2D-Zeichnugnen sowie Stücklisten. Es können unterschiedliche Ausprägungen der Fertigungsprozesse für ein FP gewählt werden, z. B. immer aber eine standortspezifische Gestaltung des Fertigungsprozesses, daher besitzt ein FP ein oder mehrere „Manufacturable Parts“ (im Folgenden: MP). Es existiert somit eine 1:n-Beziehung zwischen FP und MP. Das MP wird seinerseits mit sämtlichen konstruktions- und produktionsrelevanten Daten wie Arbeitsvorgangs-CAD-, CAE- und CAM-Modellen, Arbeitsplänen oder digitale Mockups verknüpft. Die Bauteile erhalten im Zuge ihrer Fertigung konkrete, physische Repräsentanten mit eigenen Serialnummern und individuellen „Lebensläufen“. Für die vollständige Umsetzung des „Part“-Konzeptes ist eine Zuordnung dieser konkreten, physischen Bauteile zu einem eigenen virtuellen Part, dem „Physical Part“ (im Folgenden: PP), erforderlich. Dies erfolgt heute meist in MES-Systemen. Dabei bekommt jedes dieser PP zur Identifikation eine individuelle Serialnummer (ID). Die Nutzung der Serialnummer ermöglicht den Aufbau einer „Patientenakte“ für jedes Bauteil. Durch die 1:n-Beziehungen zwischen den Parts FP, MP und PP wird eine lückenlose Identifikation aller definierenden Daten ermöglicht. Dadurch gibt es keine Datenredundanzen (wie z. B. durch Datenmigrationen von einem IT-System zum nächsten) und der Verwaltungsaufwand wird drastisch reduziert. (siehe Bild 2) [11].

Der „Part-Centric“-Ansatz ermöglicht eine integrierte und effiziente Suche über alle relevanten Daten eines Bauteils oder einer Baugruppe, ohne dass die Suche in jedem einzelnen IT-System separat durchgeführt werden muss. Dadurch wird das Wissen über die beschreibenden Daten von den „Köpfen“ der Mitarbeiter in die Verknüpfungen zu den FP-, MP- und PP-Objekten verlagert. (siehe Bild 1)

Datenanalyse

Im Rahmen einer Datenanalyse zu den ausgelieferten Produkten eines Unternehmens, deren Fokus auf dem Servicegeschäft der Industrieprodukte liegt, werden Datenfelder und die zugehörigen wichtigsten Datenentitäten und Dokumente gesichtet (siehe Bild 3). Horizontal sind die Datenfelder den drei Part-Instanzen FP, MP und PP zugeordnet. Vertikal werden in Bild 3 die Informationen nach ihrer unmittelbaren Relevanz für den Service gegliedert. Die Bewertung der unmittelbaren Servicerelevanz basiert hierbei auf einer Befragung von Servicemitarbeitern. Die Anwendung der drei Part-Instanzen FP, MP und PP (siehe Bild 3) wird im Folgenden mithilfe von zwei Anwendungsbeispielen beschrieben.

Beispiel 1: Wartungs- und Instandhaltungsanleitungen

Wartungs- und Instandhaltungsanleitungen werden meist nicht kundenspezifisch verfasst. Diese Informationen können dementsprechend für mehrere PP gültig sein und sind mit dem zugrundeliegenden MP verknüpft. Serviceanleitungen bzw. -anweisungen, die speziell für Kundenkonfigurationen eines Produktes gelten, werden direkt dem einzelnen PP zugeordnet.

Beispiel 2: Qualitätsdaten aus Fertigung und Montage

Qualitätsdokumente wie Prüfpläne, die im Rahmen einer Fehler- Möglichkeits- und Einfluss-Analyse (FMEA) oder Q-Prüfung genutzt werden, beziehen sich auf das MP, während sich z. B. Prüfstanddaten oder einzelne Messwerte konkret auf ein PP beziehen. So werden z. B. im Falle einer 100 %-Prüfung der Oberflächenhärte die einzelnen Messwerte dem jeweiligen PP zugeordnet.

Zur Zuordnung der Dokument- und Datenklassen zu den einzelnen Parts (FP, MP, PP) wird ein mehrstufiges, methodisches Vorgehen angewendet. Dabei werden zunächst die vorhandenen (oft schon z. B. in Dateiordnern strukturierten) Daten und Dokumente in einer umfassenden Bestandsaufnahme erfasst und kategorisiert. Darauf schließt sich eine Analyse zur Ermittlung der direkten und indirekten Beziehungen zwischen den einzelnen Daten und Dokumenten sowie den neuen Parts an. Dieses Wissen ist meist nur in den Köpfen der Experten gespeichert und daher wird diese Analyse mittels qualitativen Interviews mit verschiedenen Fachexperten aus den Bereichen Service, Produktion und Entwicklung sowie einer tiefgreifenden Untersuchung der Dokumentation der jeweiligen Produktlebenszyklen durchgeführt. Anschließend werden die ermittelten Beziehungen in einer Matrix abgebildet, um eine visuelle Darstellung der Zusammenhänge zu erhalten. Basierend auf dieser Matrix können schließlich die jeweiligen Daten und Dokumentenklassen den Parts (FP, MP und PP) zugeordnet werden. Zur Sicherstellung der Genauigkeit und generalisierten Anwendbarkeit dieses Modells werden die Befragungen in mehreren Iterationsschleifen wiederholt, verfeinert und die Ergebnisse validiert.

Die Implementierung der „Part-Centric“ Logik in einer PDM-/ERP-/MES-Architektur oder in einer IT-System-übergreifenden „Middleware“ stellt eine effiziente Lösung für die Datenintegration in heterogenen IT-Systemlandschaften dar. Während die Verknüpfung auf der PDM-/ERP-/MES-Ebene bestehende IT-Lösungen integriert arbeiten „Middleware-Ansätze“ auf Basis der Propagation von Informationen aus diesen Systemen in eine Übergeordnete IT-Ebene. Beide Vorgehen ermöglichen es, die Daten aus unterschiedlichen IT-Systemen auf Part-Ebene zu organisieren und verfügbar zu machen. In der Praxis bedeutet dies, dass die IT-Architektur die Funktion eines „Datenhubs“ übernimmt, indem sie Informationen aus den verknüpften IT-Systemen abruft und diese in der beschriebenen Part-Logik als FP, MP und PP aggregiert. Im Kontext von Product-Service-Systemen wird oftmals die Rolle von übergeordneten Systemen diskutiert, die häufig als Ontologien charakterisiert werden. Ontologien bieten eine formale Darstellung von Wissen durch Konzepte für Objektverknüpfungen in einem spezifischen Bereich und skizzieren die Beziehungen zwischen diesen Objekten. Der in diesem Paper vorgestellte PDM-/ERP-/MES-, bzw. Middleware-Ansatz unterscheidet sich grundlegend von solchen ontologischen Modellen. Während Ontologien darauf abzielen, Wissen und Beziehungen zwischen Objekten zu repräsentieren, dienen die hier beschriebenen Ansätze primär der Kommunikation und Datenübertragung zwischen verschiedenen IT-Systemen und den darin verwalteten Objekten. Insbesondere die hier beschriebene „Middleware“ bezieht sich auf eine IT-System-übergreifende Schicht, die Daten aus unterschiedlichen Systemen konsolidiert und in der definierten Part-Logik organisiert. Somit repräsentiert die Middleware nicht eine Ontologie im traditionellen Sinne, sondern eine technische Implementierung zur Datenintegration.

Anwendungsspezifische Dokumentenklassifizierungen

Ein konventionelles Klassifizierungssystem gliedert betriebliche Objekte in sogenannte Objektklassen [12]. Dadurch ist jedoch keine Klassifizierung der zu einem Part zugehörigen Dokumente gegeben. Um ein einfaches und schnelles Wiederauffinden von Daten z. B. für den Servicefall zu gewährleisten, muss zusätzlich eine Dokumentenklassifizierung, die die zu einem Part zugehörigen Dokumente anwendungsgerecht gliedert, vorhanden sein. Im folgenden Abschnitt werden, auf Basis der Datenanalyse (siehe Abs. 2), anwendungsspezifische Dokumentenklassifizierungen entwickelt und beschrieben.

Daten- und Dokumentenklassen des Functional Part

In Bild 4 sind die Daten- und Dokumentenklassen eines FP abgebildet. Handelt es sich bei dem FP um eine Baugruppe, so existiert eine 150 % Konstruktionsstückliste, die sogenannten 150 % EBOM (siehe Bild 4 (A)). Die 150 % EBOM ist die funktional gegliederte Stückliste der Baugruppe bzw. des Produkts und bildet sämtliche Varianten der Baugruppe bzw. des Produkts ab. Aus ihr lassen sich konkrete Ausprägungen in Form von einer 100 % EBOM ableiten (siehe Bild 4 (B)).

Außerdem ist die geometrische Spezifikation in Form eines 3D-CAD-Modells und ggf. ergänzenden Zeichnungen mit dem Funktional Part verknüpft (siehe Bild 4 (C)). „Funktionale Spezifikation“ (siehe Bild 4 (D)) beinhaltet grundlegende Informationen, die zu Beginn einer Produktentwicklung auf Basis der Anforderungen und einer ggf. vorliegenden Marktanalyse entstehen. Veränderungen aus der Marktsituation oder aus dem Kundenfeedback führen dazu, dass die funktionalen Anforderungen des Produkts überarbeitet werden müssen, was eine Revision des FP zur Folge hat. Diese Revision beeinflusst dann die MPs und PPs, die auf der Grundlage des überarbeiteten FP erstellt werden. „Anforderungen“ (siehe Bild 4 (E)) enthalten Informationen über die erforderlichen Fähigkeiten bzw. Funktionen des Parts (Produkts). Als Sammelpunkt für sämtliche Erfindungsmeldungen und Patente wird die Daten- und Dokumentenklasse „Patente“ am FP eingeführt. Innerhalb der Daten- und Dokumentenklasse „Basisforschung“ (siehe Bild 4 (H)) finden sich grundlegende Forschungsergebnisse wie z. B. Werkstoffuntersuchungen oder -prüfungen. Die damit einhergehenden Simulationen befinden sich in der Klasse „Simulationsdaten“.

Daten- und Dokumentenklassen des Manufacturable Part

Ein Ergebnis der Datenanalyse (siehe Abs. 2) besteht darin, dass die Vermischung von Daten aus unterschiedlichen Anwendungsbereichen ein maßgeblicher Faktor für den hohen Zeitaufwand während der Produktdatenrecherche ist. Daher werden auf Basis der ermittelten Datenfelder (siehe Bild 3) drei anwendungsbezogene Sichten auf die Daten- und Dokumentenklassen für das MP entwickelt (siehe Bild 5).

Übergeordnet ist vom MP eine Verlinkung zum zugehörigen FP vorhanden (siehe Bild 5 (A)). Darunter befindet sich eine Verlinkung zu jeglichen vom MP abgeleiteten PP (siehe Bild 5 (B)).

Die Service-Sicht (siehe Bild 5 (C-D)) enthält Daten und Dokumente, die zur Erbringung von direkten Serviceleistungen erforderlich sind und sich nicht auf individuelle PPs beziehen. Dies sind z. B. Daten, die Informationen zum Vorgehen bei Wartungen, Reparaturen und Instandhaltungsmaßnahmen beinhalten.

In der Produktions- und Qualitäts-Sicht auf das MP (Bild 5 (E-J)) werden Produktionsdaten dokumentiert und kommentiert. Diese Produktionsdaten beeinflussen und optimieren die Produktionsprozesse. Die Sicht des Produktions- bzw. Montageplaners auf die Stückliste ist in der Fertigungsstückliste abgebildet.

Diese leitet sich von der 100 %-EBOM (FP) ab und besteht aus denselben Bestandteilen, aber in einer anderen Struktur. Sie ist nach Gesichtspunkten der Montage gegliedert und bildet den Ausgangspunkt zur Ableitung von agilen Montageplänen. Da die Methode auf Grundlage einer PDM-/PLM-zentrische Datenverwaltung entwickelt wird, liegt an dieser Stelle ein Datenübertrag zum verwendeten ERP-System vor, wo notwendige betriebswirtschaftlichen Prozesse abgebildet sind. Die Daten- und Dokumentenklasse „Arbeitsplan“ beinhaltet sämtliche Arbeitsschritte und zugehörige alternativen Schritte zur Fertigung bzw. der Montage des MP. „Produktionsdaten“ sind spezifische Daten wie z. B. Steuerungsdaten, Fertigungshilfsmittel und CAM-Modelle. Die Daten- und Dokumentenklasse „Qualitätsdaten“ liegt sowohl im MP als auch im PP vor. Die Qualitätsdaten des MP beinhalten z. B. Ergebnisse einer FMEA oder universell geltende Qualitätsspezifikationen wie z. B. Prüfpläne für die Montage oder Fertigung. Dagegen werden die Qualitätsdaten (Messdaten), die sich z. B. als Ergebnisse aus einer 100 %-Prüfung der Oberflächenhärte der konkreten physischen Teile ergeben, dem jeweiligen PP zugeordnet. „Lieferantendaten“ beinhalten detaillierte Informationen der einzelnen Lieferanten. Darunter fallen auch lieferantenspezifische Qualitätsprotokolle, Zertifizierungsnachweise sowie Informationen zum Zahlungsablauf. Die Klasse „Testdaten“ dient der Verwaltung jeglicher Testdaten während der Produktion und ist inhaltlich eng mit der Klasse „Qualitätsdaten“ verbunden.

Die Änderungsmanagement-Sicht auf das MP (Bild 5 (K-M)) ermöglicht die Dokumentation eines transparenten Änderungsverlaufs mit detaillierten Angaben über technische Änderungen, Änderungszeiten sowie Informationen über Vorgänger- und Nachfolgebauteile bzw. -produkte sowie den Bezug aus dem Manufacturing-Change-Management zum Engineering-Change-Management des FP.

Daten- und Dokumentenklassen des Physical Part

Bild 6 zeigt die Daten- und Dokumentenklassifizierung für ein PP. Das PP ist der Ausgangspunkt für eine Produktdatenrecherche zu einer bestimmten Serial-Nr. eines Bauteils/einer Baugruppe im Servicefall. Die entwickelten Daten- und Dokumentenklassen verfolgen das Ziel, möglichst schnell relevante Servicedaten verfügbar zu machen.

Übergeordnet ist vom PP eine Verlinkung zum zugehörigen MP vorhanden (siehe Bild 6 (A)). Die „wie gebaut“ Stückliste gibt die Struktur des PP wieder. Die „wie geartet“ Stückliste beinhaltet die Historie der montierten Komponenten und die aktuelle Produktstruktur im Feld. Dies ist für den Service von elementarer Bedeutung, da eindeutig reproduzierbar sein muss, welcher bauliche Zustand im Feld vorliegt. Die Daten- und Dokumentenklasse „Servicehistorie“ (siehe Bild 6 (D)) beinhaltet eine transparente Darstellung der Historie aller Serviceeinsätze (deren Dokumentationen) im Feld. Darunter fallen sämtliche Fehlermeldungen inklusive deren technische Lösungen, die bisher im Feld umgesetzt sind. In der Daten- und Dokumentenklasse „Qualitätsdaten“ (siehe Bild 6 (E)) finden sich sämtliche Qualitätsdaten, die konkret für das jeweilige serialisierte Bauteil gelten. Werden in der Fertigung nicht nur Chargenprüfungen durchgeführt, sondern auch einzelnen Bauteile und -gruppen geprüft, können so serialisierten Bauteilen und -gruppen konkrete Qualitätsinformationen wie z. B. Prüfstanddaten, Befunde, Schweißaufzeichnungen oder Härteprüfungen zugeordnet werden.

Die Datenklassen „Felddaten“ und „Kundendaten“ (siehe Bild 6 (F-G)) finden primär bei PPs von kompletten Produkten Anwendung, da sie Daten beinhalten, die aus deren Betrieb (z. B. Einstelldaten oder Verbrauchsdaten) entstehen.

Fazit

Zur Digitalisierung des oft auf einzelne Experten verteile Wissen über die Beschreibung der Bauteile und Baugruppe in der Entwicklung, Produktionsplanung und physikalischen Fertigung bzw. Montage wird in diesem Artikel konzeptionell eine Part-Logik vorgestellt. Diese Part-Logik optimiert die Datenverwaltung, indem sie eine integrative Verknüpfung aller Bauteil-/bzw. Baugruppen bezogenen Daten ermöglicht. Dabei werden drei unterschiedliche virtuelle Repräsentanten eines Bauteils oder Produkts, die als anwendungsbezogene, datentechnische Sichten fungieren definiert. Durch ihre Verknüpfung in einem PDM-/PLM-Ansatz bzw. in einer übergeordneten „IT-Middelware“ wird eine effiziente „Bauteilgenealogie“ (d. h. Historie des Objekts) geschaffen. Diese stellt sicher, dass sämtliche Daten über den Produktlebenszyklus hinweg in verknüpfter Form abrufbar sind und sich somit Zustände bis zur Entwicklung der Bauteile bzw. Produkte zurückverfolgen lassen. Die identifizierten und davon betroffenen Repräsentanten im Feld werden gezielt über ihre Serialnummer identifiziert. Zudem werden anwendungsorientiert Daten- und Dokumentenklassifizierungen für die verschiedenen „Parts“ festgelegt, um eine schnelle Dokumentenrecherche für Mitarbeiter unterschiedlicher Fachdisziplinen zu ermöglichen. Diese verknüpften Daten tragen wesentlich zur Vereinfachung der Rückverfolgbarkeit von Fehlern bei und steigern durch die effektive Instandhaltung und Serviceleistungen die Kundenzufriedenheit und -bindung. Es zeigt sich, dass das Part-Centric-Konzept eine effektive Lösung zur Verbesserung der Prozesssicherheit und des Datenmanagements darstellt. 

 

Literatur

1. Reichheld, S.: Zero-Migration: Dienstleister im Sog der Qualitätsrevolution 1991.
2. Vajna, S.; Weber, C.; Zeman, K. et al.: Cax für Ingenieure, 3rd 3., Vollst. Neu Bearb. Aufl. 2 ed. Berlin 2018.
3. Jahn, M.: Ein Weg zu Industrie 4.0. Geschäftsmodell für Produktion und After Sales. Berlin, Boston 2016.
4. Kumar, P.; Kalwani, M. U.; Dada, M.: The Impact of Waiting Time Guarantees on Customers‘ Waiting Experiences. In: Marketing Science 16 (1997) 4, S. 295–314.
5. Bruhn, M.; Stauss, B. (Hrsg.): Dienstleistungsqualität. Konzepte – Methoden – Erfahrungen. Wiesbaden 2000.
6. Günthner, W.; Borrmann, A.: Digitale Baustelle- innovativer Planen, effizienter Ausführen. Werkzeuge und Methoden für das Bauen im 21. Jahrhundert. Berlin, Heidelberg 2011.
7. Davis, M. M.; Heineke, J.: Understanding the Roles of the Customer and the Operation for Better Queue Management. In: International Journal of Operations & Production Management 14 (1994) 5, S. 21–34.
8. Faullant, R.: Psychologische Determinanten der Kundenzufriedenheit, 1. Aufl. s.l. 2007.
9. Neubert, S. Dr.; Robl, P.: 3D-CAD-Modelle lenken die Fertigung. In: VDI-Z Integrierte Produktion (2018) 04–2018.
10. Kirchhof, R.: Ganzheitliches Komplexitätsmanagement. Grundlagen und Methodik des Umgangs mit Komplexität im Unternehmen, Gabler Edition Wissenschaft. Wiesbaden 2003.
11. Saske, B.; Schwoch, S.; Paetzold, K. et al.: Digitale Abbilder als Basis Digitaler Zwillinge im Anlagenbau: Besonderheiten, Herausforderungen und Lösungsansätze. In: Industrie 4.0 Management 2022 (2022) 5, S. 21–24.
12. Eigner, M.; Stelzer, R.: Product Lifecycle Management. Ein Leitfaden für Product Development und Life Cycle Management, 2., neu bearb. Aufl. Dordrecht 2013