Um im Wettbewerb bestehen zu können, ist es für industrielle Unternehmen von zentraler Bedeutung, die Auswirkungen produktbezogener Entscheidungen möglichst zum Zeitpunkt der Entscheidung antizipieren zu können. Betriebswirtschaftliche Analysen müssen dazu neben Daten aus transaktionsorientierten und betriebswirtschaftlichen Systemen auch Produkteigenschaften beschreibende Daten des technischen Bereichs wie der Konstruktion berücksichtigen. Gegenwärtig existiert hier jedoch keine ausreichende Integration. Dieser Beitrag thematisiert die Ausgangssituation und zeigt auf, wie Daten aus den verschiedenen Systemen der Bereiche in einem produktorientierten Datawarehouse zusammengeführt und für Auswertungen entlang des gesamten Produktlebenszyklus verfügbar gemacht werden können, um dadurch die Notwendigkeit eines Konzepts für ETLProzesse zur Befüllung von produktorientierten Datawarehouses als Ziel des dargestellten Forschungsvorhabens bzw. den Forschungsbedarf abzuleiten.
In industriellen Unternehmen werden bereits in frühen Phasen des Produktlebenszyklus
bzw. Produktentstehungsprozesses (Vgl. Abb. 1), insb. in der Konstruktion, zentrale
Entscheidungen bzgl. des Bestehens des Produkts bzw. des Unternehmens am Markt
getroffen. Die Auswirkungen dieser Entscheidungen sind jedoch gegenwärtig nur schwer
antizipierbar, oftmals nur durch Erfahrungswissen abschätzbar.
Der vorliegende Beitrag ist Teil eines umfassenden Forschungsprojekts im Kontext der
Digitalen Fabrik mit dem Ziel, Analysen auf Basis technischer und
betriebswirtschaftlicher bzw. transaktionsorientierter Daten über den gesamten Produktlebenszyklus zu
ermöglichen (Vgl. Abb. 2). Zunächst wurde mittels Literaturrecherche und empirischen
Voruntersuchungen in Form von leitfadenbasierten Experteninterviews in
mittelständischen Unternehmen die Notwendigkeit für bereichsübergreifende Analysen über den
gesamten Produktlebenszyklus hinweg festgestellt. Im Anschluss wurden relevante Use
Cases erarbeitet mit dem Ziel der Bestimmung der jeweiligen Informationsbedarfe.
Mögliche Use Cases sind bspw. der Qualitätsmanager
Mit dem Ziel der Deckung der identifizierten Informationsbedarfe werden derzeit mögliche Konzepte der Datenmodellierung evaluiert. Im Anschluss an diese fachliche Konzeption werden auf technischer Ebene einerseits mögliche Konzepte für – aufgrund der Voruntersuchungen anzunehmende mehrstufige – pDWH-Architekturen erarbeitet. Andererseits stehen die für die Befüllung des pDWHs notwendigen ETL-Prozesse im Fokus der Forschung. Hier setzt der vorliegende Beitrag an. Ziel dieses Beitrags ist es, anhand der Voruntersuchungen zu klären, inwiefern Forschungsbedarf im Bereich der ETL-Prozesse für pDWHs besteht und diesen grob abzugrenzen. Im folgenden Kapitel wird nun zunächst auf die vorliegende Problemstellung eingegangen und diese anhand eines Beispiels erläutert. Im Anschluss werden ein möglicher Lösungsansatz und die daraus resultierenden Folgen für ETL-Prozesse thematisiert.
Die im Rahmen der Entscheidungsunterstützung durchgeführten betriebswirtschaftlichen
Analysen nutzen lediglich Daten aus Systemen des betriebswirtschaftlichen Bereichs.
Daten, die bspw. technische Produkteigenschaften beschreiben, wie sie in einem
3DModell (Digital Mock Up, DMU) bzw. 2D-Modell (Zeichnung) hinterlegt sind, werden
nicht berücksichtigt. Die (vornehmlich technische) Produktsicht wird somit nicht mit
einbezogen. Daten aus CAD-, PDM- und PLM-Systemen finden keine Berücksichtigung.
Die Granularität der Daten ist nicht einheitlich, denn die Systeme der technischen
Bereiche enthalten wesentlich ausführlichere Informationen bspw. bzgl. der Geometrie,
wohingegen im ERP-System lediglich die Produktstruktur bis auf Einzelteilebene vorhanden
ist, wie sie bspw. in Stücklisten zu finden ist. So ist es kaum möglich, die Auswirkungen
von technischen Veränderungen an Produktbestandteilen (Baugruppen bzw. Einzelteile)
in der Konstruktion auf betriebswirtschaftliche Kennzahlen zu ermitteln. Daher können
bspw. im Bereich der Angebotskalkulation nur schwer verlässliche Aussagen bzgl. der
Auswirkungen von kundenspezifischen Änderungen an Produktbestandteilen auf die
Kostenstruktur gemacht werden.
Der Qualitätsmanager muss bspw. für Ursachenanalysen im Fall von
Reklamationen konstruktive Informationen sowie Daten zu den verwendeten
Fertigungsverfahren mit Informationen bzgl. des Anwendungsfalles beim Kunden
kombinieren
Der Wissensingenieur benötigt bspw. Kosteninformationen (insb.
historische), um die Auswirkungen verschiedener Materialalternativen für
Komponenten bewerten zu können
Die durchgeführten Voruntersuchungen in einzelnen Unternehmen ergaben, dass Bestrebungen vorhanden sind, die in den jeweiligen Phasen des Produktlebenszyklus zum Einsatz kommenden operativen Systeme durchgängig miteinander zu verknüpfen und die Produktstruktur (wie in Stücklisten tabellarisch dargestellt) nach der Erstellung in CADSystemen über bspw. PDM-/PLM-Systeme in ERP-Systeme zu überführen. In den einzelnen Phasen existieren jedoch unterschiedliche Anforderungen an die Produktstruktur. Somit kann die Gliederung eines Endprodukts in Baugruppen und Einzelteile und deren Stufenzuordnung über den Produktentstehungsprozess hinweg variieren. Bspw. kann die aus konstruktiver Sicht sinnvolle Gliederung in Funktionsgruppen einer Gliederung nach optimalen Fertigungsabläufen in der Produktion weichen. Gliederungsänderungen werden auch nicht zwangsläufig in die in vorangegangenen Phasen eingesetzten Systeme rückübertragen, sodass für ein und dasselbe Endprodukt unterschiedliche Gliederungen parallel existieren können.
Im technischen Bereich der Konstruktion findet verstärkt die Feature-Technologie
Anwendung, bspw. in CAD-Systemen in der Konstruktion
In ERP-Systemen ist das Konzept der Sachnummer bei der Identifizierung von
Komponenten bzw. Endprodukten von zentraler Bedeutung. Sie identifiziert dabei lediglich eine
Klasse von Objekten, bspw. einen bestimmten Schraubentyp. Sie ist also keine
Seriennummer, die genau ein bestimmtes Objekt einer Klasse identifiziert. Jeder Knoten in der
Produktstruktur wird anhand einer Sachnummer eindeutig identifiziert und nach dem
Baukastenprinzip im System hinterlegt.
Im Folgenden soll nun der im vorangegangenen Abschnitt angeführte Sachverhalt anhand eines Beispiels erläutert werden. Abbildung 3 stellt die Produktstruktur für ein beispielhaftes Produkt mit 4 Hierarchiestufen exemplarisch dar.
Rohteile, Einzelteile, Baugruppen und das Endprodukt werden in dieser Baumstruktur als Knoten dargestellt. Wird aus einem Rohteil ein Einzelteil gefertigt bzw. ein Einzelteil in ein anderes Einzelteil umgearbeitet, wird von einer linearen Struktur gesprochen. Findet eine Kombination von Einzelteilen oder Baugruppen zu anderen Baugruppen statt, wie in der Montage, wird dies als konvergierend bezeichnet. (Günther & Tempelmeier, 2009)
zelteil auf Stufe 3 dar. Während des Bearbeitungsprozesses werden somit
winde versehen, technisch gesehen ein weiteres Hinzufügen von Features.
onsprozess wird dann im Rahmen der Montage ein extern beschaffter Bolzen angeschweißt, wieder ein Hinzufügen von weiteren Features. Die resultierende Baugruppe befindet sich auf Stufe 1. An dieser Baugruppe wird dann im weiteren Montageablauf mittels einer Schraube (das dargestellte Einzelteil auf Stufe 1) die andere auf Stufe 1 dargestellte Baugruppe angeschraubt.
an dieser Stelle verzichtet. Am Ende steht das Endprodukt, das in diesem
unternehmen weiterverkauft wird. Eine Betrachtung der im Produktionsablauf eingesetzten Systeme zeigt deutlich die Schnittstellenproblematik und die unterschiedliche Granularität der Daten: Im ERP-System sind lediglich die einzelnen Knoten aus Abbildung 3 (Rohmaterial, Einzelteile, Baugruppen, Endprodukt) als Objekt unter der jeweiligen sogenannten Sachnummer hinterlegt. Abbildung 3 verdeutlicht die hinterlegten Informationen im CADbzw. ERP-System exemplarisch für den linearen Bereich. Auf eine Darstellung im konvergierenden Bereich wurde aus Komplexitätsgründen verzichtet. Hier ist der Sachverhalt jedoch analog zum linearen Bereich.
nen, die in diesen Dokumenten enthalten sind, sind jedoch im Gegensatz zu
zeit und die zu verwendende Maschine bzw. das benötigte Werkzeug zugeordnet. Es besteht eine Verknüpfung, die besagt, dass das Einzelteil aus dem
bspw. das Datum des Anlegens im ERP-System, der Name des anlegenden
onsprozesses für das gesamte Endprodukt ein digitales dreidimensionales
zunächst mit einem viereckigen Stück Material begonnen wird (Rohmaterial), aus dem dann im CAD-System die Form des Winkelstücks erzeugt wird (Einzelteil auf Stufe 3). Es wird hier also ein geometrisches Feature hinzugefügt. Analog verhält es sich mit der Bohrung und dem Gewinde. Auch diese
Das Beispiel zeigt, dass eine Baugruppe nicht die Summe der in sie eingehenden Einzelteile und Rohteile bzw. Baugruppen ist. Dies wird insbesondere im linearen Bereich deutlich. Vielmehr ist eine Baugruppe die Summe der in sie eingehenden Features, also die Summe sämtlicher Features, die in den hierfür verwendeten Einzelteilen bzw. Baugruppen enthalten sind. Die Features sind in den DMUs der CAD-Systeme enthalten. Betriebswirtschaftliche Auswertungen bedienen sich aber der Daten aus den ERP-Systemen.
Zusammenfassend lässt sich also sagen, dass die im Rahmen der Entscheidungsunterstützung benötigten Informationen zwar im Unternehmen durch die Daten der operativen Systeme vorhanden sind, jedoch für Auswertungen verfügbar gemacht werden müssen. 4
Die oben beschriebene Schnittstellenproblematik zeigt, dass Analysen direkt mittels der in den operativen Systemen hinterlegten proprietären Daten bei der Umsetzung zu erheblichen Problemen, insb. aufgrund unterschiedlicher Granularitäten, führen würden. Die benötigten Daten sind somit bereits in operativen Systemen vorhanden, müssen jedoch noch für bereichsübergreifende Zwecke nutzbar gemacht werden.
Um nun hier durchgehende betriebswirtschaftliche Analysen über die gesamte Entstehung
eines Produktes zu ermöglichen, ist somit zwingend eine durchgehende integrierte
dispositive Datenhaltung entlang des gesamten Produktentstehungsprozesses notwendig. Dies
kann durch die Zusammenführung der Daten aus den eingesetzten operativen Systemen in
einem pDWH geleistet werden
Die Feature-Technologie ermöglicht es zudem, in den einzelnen Phasen des
Produktlebenszyklus neue Informationen in Form von Features zu ergänzen und gewährleistet
somit eine durchgängige Flexibilität
Jedoch variieren die Features bezüglich der beinhalteten Informationen entlang des
Produktentstehungsprozesses. Die Feature-Arten (z.B. Konstruktionsfeature,
Fertigungsfeature) in den Feature-Bibliotheken der eingesetzten Systeme können sich unterscheiden.
Dies erfordert bei der Übertragung des digitalen Produktmodells von einem zum anderen
System auch eine tendenziell aufwendige und problembehaftete Transformation der
Features.
Die Feature-Technologie ermöglicht es somit, sowohl Informationen aus dem betriebswirtschaftlichen Bereich als auch aus dem technischen Bereich in einem pDWH zusammenzuführen und für Auswertungen entlang des gesamten Produktlebenszyklus bereitzustellen. Die Produktstruktur wird hierfür mit Features angereichert bzw. die Produktstruktur wird über die Einzelteilebene hinaus um Features erweitert. Hierfür sind verschiedene Modellierungskonzepte möglich. Vorarbeiten führen zu der Annahme, dass eine multidimensionale Modellierung hier geeignet sein könnte. Zu jeder Sachnummer werden die Informationen in Form von Features als Fakten einer multidimensionalen Modellierung hinterlegt. Features unterschiedlicher Sichtweise (bspw. Qualität oder Revisionsstand) stellen unterschiedliche Dimensionen dar. Eine zentrale Herausforderung stellt dabei die Harmonisierung unterschiedlicher Feature-Arten dar. Die Evaluation der Modellierungsmethoden ist Gegenstand eines separaten Forschungsvorhabens im übergeordneten Forschungsprojekt (Vgl. Kapitel 2).
Durch diesen Ansatz wird es möglich, Analysen unter Berücksichtigung sowohl
technischer als auch betriebswirtschaftlicher Daten durchzuführen. Somit können die
Auswirkungen technischer Änderungen auf betriebswirtschaftliche Größen antizipiert werden.
Zur Überführung von Produktstruktur und Produkteigenschaft beschreibenden Daten aus
den operativen Quellsystemen ins pDWH sind umfangreiche ETL-Prozesse notwendig.
ETL-Prozesse umfassen die aufeinanderfolgenden Teilbereiche der Filterung,
Harmonisierung, Aggregation und Anreicherung der Daten
Dieser Beitrag erläutert die Notwendigkeit eines Forschungsvorhabens, dessen Ziel es ist, ein Konzept für die Extraktion und Aufbereitung von Produktdaten (ETL-Prozesse) sowohl aus operativen transaktionsorientierten und betriebswirtschaftlichen als auch produktorientierten Systemen zur Bereitstellung in einem produktorientierten Data Warehouse zu entwickeln, prototypisch umzusetzen und zu evaluieren. Diese ETL-Prozesse beinhalten technische (Zugang zu den relevanten Quellsystemen der verschiedenen Bereiche), semantische (Filterung und Harmonisierung der relevanten Daten) und syntaktische (Integration auf Basis der Feature-Technologie) Herausforderungen.
Das übergeordnete Ziel ist es, durch die fokussierten ETL-Prozesse Daten aus produktorientierten Systemen, wie bspw. Produkteigenschaften, in einem pDWH für betriebswirtschaftliche Analysen bereitzustellen und so bereits bestehende Analysemöglichkeiten um Aussagefähigkeiten bzgl. direkter Ursache-Wirkungsbeziehungen, bspw. von konstruktiven Änderungen einzelner Teile, zu erweitern.
Aufgrund der unterschiedlichen Ausgangssituation in den beiden Bereichen, der Form in der die benötigten Daten in den jeweiligen Systemen vorliegen, sind jeweils abgestimmte ETL-Prozesse notwendig:
Die Nutzung der Feature-Technologie im technischen Bereich lässt den Schluss zu, dass ETL-Prozesse des betriebswirtschaftlichen Bereichs hier nicht übertragbar sind, um die in Form von Features vorliegenden Informationen in einem pDWH zur Verfügung zu stellen.
Zudem erfordert die feature-basierte Konzeption des pDWH hierauf abgestimmte ETL-Prozesse im betriebswirtschaftlichen Kontext, um betriebswirtschaftliche bzw. transaktionsorientierte Daten ins pDWH zu überführen und die erforderliche Integration mit Daten aus technischen Systemen zu leisten. Daher besteht im Bereich der ETL-Prozesse sowohl für transaktionsorientierte bzw. betriebswirtschaftliche als auch produktorientierte Daten weiterer Forschungsbedarf. 6
Binner, H.F. (2003). Prozessorientierte Arbeitsvorbereitung (2. ed.). München Wien:
Hanser.
Chamoni, P., Gluchowski, P. & Hahne, M. (2005). Business Information Warehouse: Perspektiven betrieblicher Informationsversorgung und Entscheidungsunterstützung auf der Basis von SAP-Systemen. Berlin Heidelberg: Springer. Eigner, M. & Stelzer, R. (2009). Product Lifecycle Management: Ein Leitfaden für Product Development und Life Cycle Management (2. ed.). Berlin Heidelberg: Springer.