Erstellung eines Konzepts für ETL-Prozesse zur - CEUR

Erstellung eines Konzepts für ETL-Prozesse zur
Befüllung von produktorientierten Datawarehouses
Clemens Haußmann
Lehrstuhl für Wirtschaftsinformatik I
Universität Stuttgart
Abstract
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.
1
Einleitung
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. (Kemper, et al., 2011)
Clemens Haußmann
2
Abbildung 1: Der Produktentstehungsprozess im Produktlebenszyklus (Eigene Darstellung, basierend auf Eigner & Stelzer, 2009; Kemper, et al,. 2011; Vajna, 2009; Westkämper, 2006; Wiendahl, 2010)
Dies liegt darin begründet, dass in industriellen Unternehmen eine Trennung zwischen
den eher dem betriebswirtschaftlichen Bereich zuzuordnenden transaktionsorientierten
bzw. betriebswirtschaftlichen Systemen, wie Enterprise Resource Planning (ERP)Systeme, und den produktorientierten Systemen, wie Computer-Aided Design (CAD)Systeme, die in den technischen Bereichen wie der Konstruktion eingesetzt werden, vorherrscht. Dabei existieren Schnittstellenproblematiken und Medienbrüche sowohl innerhalb der einzelnen Bereiche zwischen den dort eingesetzten Systemen, bspw. zwischen
CAD-System und Product Data Management (PDM)-System bzw. Product Life Cycle
Management (PLM)-System im technischen Bereich, als auch bereichsübergreifend,
bspw. bei der Übertragung der Produktstruktur vom PDM-System ins ERP-System (Lasi
& Kemper, 2011). Dies wurde durch eigene Voruntersuchungen bestätigt.
Für bereichsübergreifende Analysen entlang des Produktlebenszyklus ist somit eine Integration der relevanten Daten der in den jeweiligen Bereichen eingesetzten Systeme
notwendig. Ein Lösungsansatz hierfür ist die Zusammenführung dieser Daten in einem
sogenannten produktorientierten Datawarehouse (pDWH). (Lasi & Kemper, 2011; Kemper, et al., 2011)
2
Forschungsdesign, Forschungsfrage und Themeneinordung
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 (Lasi 2012a) und der Wissensingenieur
WSBI 2012 – ETL-Prozesse zur Befüllung von produktorientierten Datawarehouses
3
(Lasi 2012b). Ziel des Qualitätsmanagers ist es, die Qualität eines Produktes sicherzustellen und dabei insb. Ursachen für mögliche bzw. akute Qualitätsschwankungen zu identifizieren (Lasi 2012a). Die primäre Aufgabe des Wissensingenieurs besteht in der Systematisierung konstruktiven Wissens und der Aufstellung von Konstruktionsregeln (Lasi
2012b).
Abbildung 2: Forschungsdesign
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.
Clemens Haußmann
4
3
Problemstellung
3.1 Getrennte Welten – transaktionsorientierte bzw. betriebswirtschaftliche
und produktorientierte Systeme
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. (Lasi & Kemper, 2011)
Die erhobenen Use Cases zeigen, dass sowohl technische als auch betriebswirtschaftliche
bzw. transaktionsorientierte Daten aus verschiedenen Phasen des Produktlebenszyklus für
Analysen im Vorfeld von Entscheidungen benötigt werden (Lasi 2012a; Lasi 2012b):

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 (Lasi 2012a).

Der Wissensingenieur benötigt bspw. Kosteninformationen (insb. historische), um die Auswirkungen verschiedener Materialalternativen für Komponenten bewerten zu können (Lasi 2012b).
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
WSBI 2012 – ETL-Prozesse zur Befüllung von produktorientierten Datawarehouses
5
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 (VDI, 2003). Features beschreiben „[…]Bereiche von besonderem (technischem) Interesse[…]“ (VDI, 2003, S.10). Ein
Feature stellt die abhängig von einer gewissen Sicht relevanten Eigenschaften und deren
Beziehungen eines Objektes dar. Es ist somit kontextabhängig und kann sowohl ausschließlich geometrische (Form, Abmessungen etc.) oder semantische Informationen
(bspw. Qualitätsinformationen), aber auch beides beinhalten (VDI, 2003). Somit können
bspw. dem Feature „Kernlochbohrung mit Durchmesser 3,5mm“ Qualitätsinformationen
wie zulässige Toleranzen hinzugefügt werden. Die Summe der geometrischen Features
bildet bei feature-basierten Systemen gemeinsam mit dem Grundkörper das dreidimensionale digitale Produktmodell (Lasi & Kemper, 2011).
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. (Grupp, 1987)
Somit unterscheidet sich die Art der Hinterlegung von Produktstrukturen in den Systemen
der jeweiligen Bereiche deutlich.
3.2 Verdeutlichung der Problemstellung anhand eines Beispiels
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.
Clemens Haußmann
6
Abbildung 3: Eine beispielhafte Produktstruktur
(Eigene Darstellung, basierend auf Binner, 2003)
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)
Beispiel:
Aus einem Rohteil auf Stufe 4 wird ein Winkel gefräst. Diesen stellt das Einzelteil auf Stufe 3 dar. Während des Bearbeitungsprozesses werden somit
Features hinzugefügt, hier die Form des Winkels (Geometrie). Im nächsten
Fertigungsschritt wird der Winkel mit einem Loch und dazugehörigem Gewinde versehen, technisch gesehen ein weiteres Hinzufügen von Features.
Das resultierende Einzelteil befindet sich auf Stufe 2. Im weiteren Produktionsprozess 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.
Auf eine Darstellung des Montagevorgangs für diese zweite Baugruppe wird
an dieser Stelle verzichtet. Am Ende steht das Endprodukt, das in diesem
Fall bspw. eine Maschinenkomponente sein kann, die an ein Maschinenbau-
WSBI 2012 – ETL-Prozesse zur Befüllung von produktorientierten Datawarehouses
7
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.
Zu einer Sachnummer sind bspw. Kosten- und Termininformationen bzw.
Arbeitspläne hinterlegt, unter Umständen auch technische Zeichnungen oder
Abbildungen von dreidimensionalen Modellen. Die technischen Informationen, die in diesen Dokumenten enthalten sind, sind jedoch im Gegensatz zu
Kosten- oder Termininformationen somit nicht im ERP-System auswertbar.
Im obigen Beispiel sind dem Einzelteil auf Stufe 3 die benötigte Fertigungszeit und die zu verwendende Maschine bzw. das benötigte Werkzeug zugeordnet. Es besteht eine Verknüpfung, die besagt, dass das Einzelteil aus dem
Rohteil aus Stufe 4 gefertigt wird. Des Weiteren sind je Sachnummer auch
bspw. das Datum des Anlegens im ERP-System, der Name des anlegenden
Sachbearbeiters und der Versionsstand hinterlegt.
Im CAD-System der Konstruktion hingegen (im Folgenden wird von einem
3D-fähigen CAD-System ausgegangen) existiert am Ende des Konstruktionsprozesses für das gesamte Endprodukt ein digitales dreidimensionales
Modell. Der Konstruktionsprozess kann im Beispiel also so aussehen, dass
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
Features werden im Konstruktionsprozess hinzugefügt. Im Beispiel folgt der
Produktionsprozess also dem Konstruktionsprozess.
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üt-
Clemens Haußmann
8
zung 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
Lösungsansatz
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 (Lasi & Kemper, 2011; Kemper, et al., 2011). Dort werden die gesamten Erzeugnisstrukturen mit den dazugehörigen Hierarchien hinterlegt.
Dieses pDWH ermöglicht somit eine integrierte, einheitliche Datenbasis entlang des gesamten Produktentstehungsprozesses. Dabei wird die Produktstruktur um technische Informationen ergänzt, um so die Informationslücke zwischen ingenieurwissenschaftlichen
und betriebswirtschaftlichen Bereichen zu schließen und Transparenz zu ermöglichen.
Insbesondere die technischen Informationen sind zwar in DMUs bzw. Zeichnungen in
CAD- oder PDM-/PLM-Systemen enthalten, im Rahmen von Analysen anhand der Produktstruktur sind sie jedoch nicht direkt auswertbar. Eine Möglichkeit, technische Informationen für betriebswirtschaftliche Analysezwecke im pDWH verfügbar zu machen, ist
mittels der sog. Feature-Technologie (Lasi & Kemper, 2011). Wie in Kapitel 3 erläutert,
entspricht ein Einzelteil der Summe aller Features, analog gilt dies für Baugruppen und
Endprodukte. Mittels Features werden also die technischen Eigenschaften voll beschrieben und es können zudem weitere Informationen in Form von semantischen Features
hinterlegt 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 (VDI, 2003). Diese Skalierbarkeit ist Grundvoraussetzung für eine bereichsübergreifende Nutzung.
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
WSBI 2012 – ETL-Prozesse zur Befüllung von produktorientierten Datawarehouses
9
System auch eine tendenziell aufwendige und problembehaftete Transformation der Features. (VDI, 2003)
Operative Quellsysteme sind hierbei transaktionsorientierte Systeme des betriebswirtschaftlichen Bereiches und produktorientierte Systeme des technischen Bereichs. Das
Grundgerüst der Daten im pDWH wird dabei durch die klassische Produktstruktur gebildet, wie sie in Stücklisten zu finden ist. Die in einer Stückliste hinterlegte Hierarchie wird
im pDWH abgebildet. Nur so kann sichergestellt werden, dass das Datenmodell während
des gesamten Produktlebenszyklus skalierbar ist. Eine reine Beschränkung auf Features
würde zwar im Bereich der Konstruktion unter Umständen ausreichen, jedoch bauen
transaktionsorientierte und betriebswirtschaftliche Systeme wie ERP-Systeme auf dem
Konzept der Sachnummern auf (Vgl. Abb. 3). Diese Sachnummern sind somit auch zentraler Gegenstand betriebswirtschaftlicher Analysen. Eine reine Beschränkung auf Features würde sogar zu einem Informationsverlust führen, denn Informationen wie Versionsstand können nur dem jeweiligen Knoten und keinen Features zugeordnet werden. Die
für Auswertungen essentielle Historisierung der Daten wäre somit nicht möglich. Daher
ist zwingend die Produktstruktur als Grundgerüst für das Datenmodell notwendig.
Mittels Feature-Technologie kann ein Einstieg an jedem Knoten der Produktstruktur stattfinden, wobei jeweils, wie oben gezeigt, sämtliche Informationen über die eingehenden
Einzelteile und Rohteile bzw. Baugruppen voll verfügbar sind.
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.
Clemens Haußmann
10
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 (Chamoni, et al., 2005; Gluchowski, et
al., 2008; Kemper, et al., 2010). Im betriebswirtschaftlichen Bereich ist dies etablierte
Praxis (Chamoni, et al., 2005; Gluchowski, et al., 2008; Kemper, et al., 2010), für produktspezifische Daten aus dem ingenieurwissenschaftlichen Umfeld der Entwicklung
bzw. Produktion mangelt es jedoch an einer konzeptionellen Ausarbeitung für ETLProzesse. Ein Grobkonzept für diese ETL-Prozesse wurde in einer ersten Phase erarbeitet.
Hierbei hat sich gezeigt, dass bereits existierende Konzepte aus dem betriebswirtschaftlichen Bereich nicht direkt übertragbar sind, da sich die Ausgangssituation, wie oben erläutert, grundlegend unterscheidet: Quellsysteme für die zu extrahierenden Daten sind in den
technischen Bereichen geometrieorientierte Systeme wie CAD- bzw. PDM/PLMSysteme. Dort sind die benötigten Daten in DMUs in Form von Features eingebettet. Die
Daten müssen somit aus diesen digitalen Modellen zunächst extrahiert werden. Dies unterscheidet sich deutlich von den im betriebswirtschaftlichen Kontext etablierten ETLProzessen. Eine weitere wesentliche Herausforderung stellt die Harmonisierung und Zusammenführung der aus den DMUs extrahierten Daten mit den betriebswirtschaftlichen
und transaktionsorientierten Daten aus der ERP-Welt dar. Das Konzept sieht daher vor,
die aus den DMUs extrahierten Features anhand der Feature-Arten zu aggregieren, bis sie
konsistent zu den aus den ERP-Systemen übernommenen Produktstrukturen sind. Damit
können betriebswirtschaftliche und transaktionsorientierte Daten (bspw. Plankosten)
ebenfalls im pDWH den jeweiligen Knoten zugeordnet werden. Ziel eines weiteren Forschungsvorhabens muss es daher sein, ein entsprechendes Konzept zu entwickeln, um
zunächst die relevanten Daten in den operativen Quellsystemen zu identifizieren, anschließend zu extrahieren und aufbereitet im pDWH zur Verfügung zu stellen. Das erarbeitete Konzept soll dann der Forschungskonzeption der Gestaltungsorientierten Wirtschaftsinformatik (Österle, et al., 2010) folgend prototypisch implementiert und evaluiert
werden.
5
Zusammenfassung
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
WSBI 2012 – ETL-Prozesse zur Befüllung von produktorientierten Datawarehouses

11
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
Literaturverzeichnis
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.
12
Clemens Haußmann
Eigner, M. & Stelzer, R. (2009). Product Lifecycle Management: Ein Leitfaden für
Product Development und Life Cycle Management (2. ed.). Berlin Heidelberg:
Springer.
Gluchowski, P., Gabriel, R. & Dittmar, C. (2008). Management Support Systeme und
Business Intelligence: Computergestützte Informationssysteme für Fach- und
Führungskräfte (2. ed.). Berlin Heidelberg: Springer.
Grupp, B. (1987). Optimale Verschlüsselung bei Online-Datenverarbeitung: Aufbau
moderner Nummernsysteme für Sachnummern jeder Art, Personennummern und
Auftragsnummern. Köln: TÜV Rheinland.
Günther, H.-O. & Tempelmeier, H. (2009). Produktion und Logistik (8. ed.). Berlin
Heidelberg: Springer.
Kemper, H.-G., Baars, H. & Lasi, H. (2011). Business Intelligence - Innovative
Einsatzfelder in der Industrie, in: Felden, C., Krebs, S. & Stock, S. (Eds.):
Perspektiven der Business Intelligence - Festschrift anlässlich des 60. Geburtstages
von Peter Chamoni. München, Hanser.
Kemper, H.-G., Baars, H. & Mehana, W. (2010). Business Intelligence - Grundlagen und
praktische Anwendungen: Eine Einführung in die IT-basierte
Managementunterstützung (3. ed.). Wiesbaden: Vieweg + Teubner.
Lasi, H., & Kemper, H.-G. (2011). Integrationsansätze zur Verbesserung der
Entscheidungsunterstützung im Innovationsmanagement. HMD - Praxis der
Wirtschaftsinformatik (278), 94-103.
Lasi, H. (2012a). Industrial Intelligence - a BI-based approach to enhance manufacturing
engineering in industrial companies. Proceedings of the 8th CIRP Conference on
Intelligent Computation in Manufacturing Engineering (CIRP ICME). 18 - 20 July
2012. Gulf of Naples, Italy.
Lasi, H. (2012b). Decision Support within Knowledge-Based Engineering - a Business
Intelligence-Based Concept. Proceedings of the 18th Americas Conference on
Information Systems (AMCIS). 09.08.-11.08.2012. Seattle, USA.
Österle, H., Becker, J., Frank, U., Hess, T., Karagiannis, D., Krcmar, H., Loos, P.,
Mertens, P., Oberweis, A. & Sinz, E.J. (2010). Memorandum zur
gestaltungsorientierten Wirtschaftsinformatik. Zeitschrift für betriebswirtschaftliche
Forschung, 62 (6), 664-672.
Vajna, S., Weber, C., Bley, H. & Zeman, K. (2009). CAx für Ingenieure: Eine praxisbezogene Einführung (2. Ed.). Berlin Heidelberg: Springer.
WSBI 2012 – ETL-Prozesse zur Befüllung von produktorientierten Datawarehouses
13
VDI (2003). VDI-Richtlinie 2218: Informationsverarbeitung in der Produktentwicklung Feature-Technologie. Düsseldorf: Verein Deutscher Ingenieure (VDI).
Westkämper, E. (2006). Einführung in die Organisation der Produktion. Berlin
Heidelberg: Springer.
Wiendahl, H.-P. (2010). Betriebsorganisation für Ingenieure (7. ed.). München: Hanser.