Enterprise Application Integration und Service-Oriented Architecture im Product Lifecycle Management

Inhalt

1 Einleitung

2 Product Lifecycle Management (PLM)
2.1 Entstehung und Notwendigkeit des PLM
2.2 Grundlegender Aufbau des PLM
2.3 Reengineering-Ansätze
2.3.1 Produktgestaltung
2.3.2 Prozessgestaltung
2.4 Produktionsplanung und -steuerung
2.5 Produktdatenmanagement

3 Enterprise Application Integration
3.1 Einführung und Begriffsklärung
3.2 EAI-Referenzstruktur
3.3 Architekturkonzepte
3.3.1 Multi-Channel-Architektur
3.3.2 A2A-Integration
3.3.3 Geschäftsprozessintegration
3.4 Vor- und Nachteile von EAI-Lösungen

4 Serviceorientierte Architektur (SOA)
4.1 Einführung und Begriffsklärung
4.2 Bestandteile einer SOA
4.2.1 Application Frontends
4.2.2 Services
4.2.3 Service-Repository
4.2.4 Service-Bus
4.3 Serviceorientierte PLM Architektur
4.3.1 Verbesserte simultane Ingenieurstätigkeiten
4.3.2 Verbesserte Einbeziehung der Konsumenten in die Produktentwicklung
4.4 Anwendungsbeispiel

5 Fazit

Abbildungsverzeichnis

Abb. 1: PDM vs. PLM (Abb. aus [DSM11, S.94]) 3

Abb. 2: Komplexitätstreiber (Abb. nach [FG08, S.26]) 5

Abb. 3: Zusammenspiel zwischen der Referenzstruktur, dem Referenzprozess und dem Wissensspeicher (PPS) (Abb. aus [FG08, S.64]) 7

Abb. 4: Prinzipielle Systemarchitektur von PDMS (Abb. aus [FG08, S.76]) 8

Abb. 5 EAI-Referenzstruktur (Abb. aus [Kel02, S.43]) 12

Abb. 6: n:1 Multichannel-Situationen (Abb. kombiniert aus [Kel02, S.17]) 12

Abb. 7 Point-to-Point-, Hub-and-Spoke- und Bus-Architektur im Vergleich 14

Abb. 8 Geschäftsprozessintegration (Abb. aus [PR01]) 15

Abb. 9: Bestandteile einer SOA (Abb. aus [FZ09, S.9]) 20

Abb. 10: Abb. Grundmodell einer SOA (Abb. nach [PH03]) 21

Abb. 11: Generische serviceorientierte Architektur (Abb. aus [AB10, S.301]) 24

Abb. 12 ESB als Schnittstelle zwischen den PLM Phasen (Abb. nach [SMM12, S.350]) . 26

Abb. 13: ESB als Bestandteil simultaner Ingenieurstätigkeit (Abb. nach [SMM12, S.351] 26

Abb. 14: Integration von CRM und CAD mithilfe eines ESB (Abb. nach [SMM12, S.352]) 27

Abb. 15: Produktveränderung mithilfe serviceorientierter Architekturen (Abb. nach [BCM08, S.7]) 28

1 Einleitung

Effektives und aktives IT-Management ist heutzutage eine der Hauptaufgaben von Unternehmen, wenn sie am Markt konkurrenzfähig sein wollen. Es reicht in den mo- dernen und schnelllebigen Märkten nicht mehr aus, Aufgaben abteilungsintern zu lösen und die Ergebnisse und Daten nach Anfrage in schriftlicher Form weiter zu geben. Vielmehr muss jeder Schritt von der Produktidee bis zum Recycling in inte- grierter und teilweise sogar automatisierter Form kommunizieren und zusammenar- beiten. Aus diesem Grund bekommt die Organisation aller benötigten IT-Systeme des Produktlebenszyklus eine immer stärkere Rolle in den Unternehmen. Informa- tionen sind der Hauptträger unternehmerischer Innovationspotentiale und daher ist es notwendig, jedem Teilnehmer im Produktlebenszyklus alle Daten zu jedem Zeit- punkt bereitstellen zu können. Außerdem bringt jede Veränderung in der Produkt- palette wie auch dem Unternehmen selbst Veränderungen auf Ebene der IT-Sys- teme mit sich. Wenn eine Abteilung eine neue Anwendung programmiert oder ein externes Unternehmen gekauft wird, kommt es regelmäßig zu Kompatibilitätsprob- lemen mit den über die Jahre gewachsenen Altanwendungen. Diese neuen Anwen- dungen müssen nun auf eine möglichst effektive Art und Weise in das IT-System der Unternehmung integriert werden, ohne dass die Altanwendungen ihre Funktion verlieren oder Daten verloren gehen.

Die vorliegende Arbeit soll einen Einblick in das Management des angesprochenen Produktlebenszyklus geben und einige Möglichkeiten aufzeigen, eine Systemin- tegration vorzunehmen. Im Product Lifecycle Management gibt es schon vor der Anwendung von Systemintegrationsmethoden einige Möglichkeiten die Produkt- und Prozessstruktur so zu vereinfachen, dass redundante Datenhaltung und Inkom- patibilitäten im Informationsfluss vermieden werden können. Die vorgestellten An- sätze sollen zeigen, wie schon während der Entstehung eines Produktes durch die Beachtung einfacher Regeln die Informationsflut in komplexen Unternehmen verrin- gert werden kann. Um schließlich eine unternehmensweite Systemintegration vor- nehmen zu können, sollen zwei Ansätze beschrieben werden, die trotz einiger ver- wandter Elemente unterschiedliche Schwerpunkte setzten. Diese sind zum einen die Enterprise Application Integration (EAI) und zum anderen die serviceorientierte Architektur (SOA). Während der erste Ansatz eher darauf abzielt die Anwendungen weitestgehend unberührt zu lassen und lediglich ihre Zusammenarbeit zu verbes- sern, liegt der Schwerpunkt von SOA darin, die komplette Systemstruktur neu zu gestalten. Die folgenden Ausführungen sollen auf eine anschauliche Weise zeigen, wie durch den Einsatz der genannten Modelle die Zusammenarbeit verschiedener Anwendungen unternehmensübergreifend verbessert werden kann.

2 Product Lifecycle Management (PLM)

2.1 Entstehung und Notwendigkeit des PLM

Auf dem immer stärker vernetzten globalen Markt sind innovative Produkte, stei- gende Variantenzahlen und kürzer werdende Entwicklungszeiten eine der Grund- voraussetzungen um ein konkurrenzfähiger Marktteilnehmer zu werden und diese Wettbewerbssituation über einen möglichst langen Zeitraum aufrecht zu erhalten [SS12b, S.336]. Um die sich ständig verändernde Produktpalette rentabel anbieten zu können, müssen Möglichkeiten gefunden werden, die anfallenden Kosten nicht nur in einzelnen Bereichen des Produktlebenszyklus, wie beispielsweise der Be- schaffung oder der Produktion zu senken, sondern von der Produktidee bis zum Recycling alle Kosten zu beachten und damit auch den engen Verflechtungen der verschiedenen Kostenstellen konzeptionell Rechnung zu tragen.

Diese Verflechtungen zeigen sich stark in der neuen Rolle des Ingenieurs, der ne- ben der ursprünglichen kreativen Arbeit heutzutage immer mehr in den Planungs-, Beschaffungs-, und Produktionsprozess involviert ist [ES09, S.3]. Problematisch ist hierbei vor allem, dass die benötigten Informationen aus den verschiedenen Unter- nehmensabteilungen oft über die Jahre hinweg unübersichtlich verwaltet wurden und ein Zugriff auf die benötigten Daten daher mit einem hohen Aufwand einher- geht. Somit ist die zielgerichtete Bereitstellung von allen relevanten Informationen in aufbereiteter Form und unmittelbar zum benötigten Zeitpunkt wichtig für den Ge- schäftserfolg. Betriebsinterne wie auch betriebsexterne Informationen werden zur wesentlichen Ressource des Produktdefinitionsprozesses. [ES09, S.4]. Aufgrund der oft schlecht verfügbaren und unzureichend aufbereiteten Daten können viele mittelständige Unternehmen dem Innovationsdruck nicht standhalten, welcher durch die Schnelllebigkeit der Produkte am Markt entsteht. Es wird also durch die Tatsache, dass neue Technologien immer möglichst schnell und kostengünstig ein- geführt werden müssen um die eigenen Forschungs- und Entwicklungskosten zu decken, immer öfter der Fall sein, dass unausgereifte und fehlerhafte Produkte zu früh für den Markt freigegeben werden und sich dadurch eine negative Wettbe- werbssituation für Unternehmen mit mangelbehaftetem Informationsfluss ergibt. [FG08, S.2].

Eine Möglichkeit, die Kosten der Produktentstehung zu senken und somit nicht auf Innovationen verzichten zu müssen, bietet das Product Lifecycle Management. Auf- grund der bisherigen Betrachtung der Markt- und Unternehmenssituationen der heutigen Zeit lässt sich festhalten, dass einer der wichtigsten Aspekte von PLM also darin liegt, die gezielte Nutzung und Bereitstellung des im Unternehmen vorhanden- en Wissens zu gewährleisten. Damit soll mit minimalem Aufwand bei der Produkt- entwicklung der maximale Vorteil gegenüber den Wettbewerbern erbracht werden [FG08, S.3]. Ein weiterer wichtiger Aspekt ist die integrierte Unterstützung von Workflows. Die verschiedenen Nutzer der PLM-Lösung können also durch eine Workflow-Engine sofort über Änderungen der Produkte, die Freigabe von Aufträgen oder ähnliches informiert werden [OJB08, S.44].

2.2 Grundlegender Aufbau des PLM

PLM ist entgegen der oft vorherrschenden Meinung keine in sich abgeschlossene IT-Lösung, sondern ein strategisches Managementkonzept. Ein an dieser Stelle häufiger Fehler ist das Gleichsetzen des Product Data Management (PDM) mit dem PLM, welches jedoch lediglich eine Möglichkeit zur Verwaltung der im PLM anfallenden Daten darstellt. Die Etablierung von PLM bewirkt und erfordert hingegen grundsätzliche Veränderungen im Unternehmen und bei den betroffenen Menschen [DSM11, S.93]. Es werden nicht nur die Prozesse innerhalb des Unternehmens und zwischen den einzelnen Standorten beeinflusst sondern auch die Beziehungen mit den Kunden, welche aktiv in den Produktentstehungsprozess eingebunden werden können, wie auch den Zulieferern, die von der Idee bis zur Entsorgung des Produktes über notwendige Teilelieferungen informiert sind.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: PDM vs. PLM (Abb. aus [DSM11, S.94])

PLM darf trotzdem nicht isoliert betrachtet werden, sondern muss in die gesamte IT-Strategie des Unternehmens integriert sein. Da mit einer systemtechnischen Lö- sung für das Product Lifecycle Management Informationen von verschiedenen Er- zeugersystemen, wie z.B. CAD-,CAE-,CAM- und Office-Systemen erfasst werden, ist es wichtig, das System flexibel dem Produkt- und Prozessmodell des Anwenders anzupassen [ES09, S. 12].

Die PLM-Lösung besteht also aus mehreren Teillösungen die auf die Phasen des Produktlebenszyklus abgebildet werden können. Die Idee dahinter besteht darin, die verschiedenen Teillösungen so zu integrieren, dass möglichst wenige Schnitt- stellen benötigt werden und aus der Sicht des Anwenders nur auf eine integrierte Softwarelösung zugegriffen werden muss, um alle nötigen Informationen zu erlang- en. Teillösungen können beispielsweise das Customer Relationship Management (CRM) in der Produktplanung und im Vertrieb, das Product Data Management (PDM) in der Produktplanung und Entwicklung, das Engineering Data Management (EDM) und das Supplier Relationship Management (SRM) in der Produktionsplan- ung, wie auch das Produktionsplanungs- und Steuerungssystem (PPS) in der Fertigung sein. [SS12a,S.195ff]. Um den Umfang der vorliegenden Arbeit überschaubar zu halten werden sich die weiteren Ausführungen maßgeblich auf das PDM und auf das PPS beschränken.

Um ein funktionsfähiges PLM zu gewährleisten, muss die Komplexität der Daten reduziert werden. Deswegen ist bei der PLM-Umsetzung ein ganzheitlicher Reengineering-Ansatz von Nöten, der den Produktentstehungsprozess hinsichtlich der Dimensionen Zeit, Kosten und Qualität zu optimieren versucht. Hierbei gibt es folgende zwei Hauptkomponenten, die verbessert werden können um Daten überschaubarer zu machen [FG08, S.28]:

- Das Produkt selbst,
- Die Prozesse der Produktentstehung

2.3 Reengineering-Ansätze

2.3.1 Produktgestaltung

Mit steigenden Anforderungen der Kunden erhöht sich bei vielen Unternehmen die Anzahl der Produktvarianten in steigendem Maße. Problematisch hierbei ist, dass sich die dadurch steigende Unternehmenskomplexität nur unzureichend beherr- schen lässt und die steigende Variantenzahl Auswirkungen auf die interne Ablauf- und Aufbauorganisation besitzt [FG08, S.9]. Durch den gehemmten Informations- fluss zwischen Kundenmanagement, Entwicklung und Absatz können vom Kunden gewünschte Produktvarianten ins Sortiment aufgenommen werden, deren Erlöse nicht die Entwicklungs- und Herstellungskosten rechtfertigen und somit von be- triebswirtschaftlich rentableren Produkten mitgetragen werden müssen. Außerdem werden Produktvarianten aufgrund einer fehlenden Strategie im Umgang mit Alt- daten oft durch völlig neue Datenpakete beschrieben, wodurch die Menge an akti- ven Produktdaten und damit die interne Vielfalt überproportional ansteigt. [FG08, S.18]. Um diese Datenvielfalt zu ordnen gibt es zwei Möglichkeiten die im Wesent- lichen auf der Idee beruhen, möglichst alle vom Markt geforderten Produktvarianten mit möglichst wenigen Komponenten zu erzeugen. Das ist zum einen die nutzen- /marktgerechte Optimierung der externen Vielfalt und die Entkopplung der externen und internen Vielfalt [FG08, S.25].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Komplexitätstreiber (Abb. nach [FG08, S.26])

Die Optimierung der externen Vielfalt setzt daran an, dass viele Unternehmen sich gezwungen sehen nach dem Credo zu handeln, dass alle Kundenbedürfnisse und -wünsche mit dem eigenen Produktangebot erfüllt sein müssen. Es muss also die Frage gestellt werden, inwiefern es sich lohnt, auf die Bedürfnisse des Kunden ein- zugehen. Dementsprechend müssen wirksame Marktstrategien entwickelt werden [FG08, S.27].

Die Entkopplung von externer und interner Vielfalt kann durch konfigurierbare aus Modulen aufgebaute Produkte realisiert werden. Hierbei werden Standartprodukte definiert und verschiedene Module zugefügt oder entnommen, um kundenspezifi- sche Anforderungen zu erfüllen. Schuh;Rudolf;Vogels beschreiben diesen Prozess als dreistufig [SRV14, S.121-125]. Zunächst müssen die vorhandenen Potentiale der modularen Produkte analysiert und auf die Bedürfnisse der Kunden hin unter- sucht werden. Im nächsten Schritt werden aus den gefundenen Daten Standartpro- dukte entwickelt, die dem Anspruch der Mehrzahl der Kunden genügen und als Aus- gangspunkt für zukünftige Variationen dienen. Im dritten und letzten Schritt werden dann die gewünschten Features geprüft und übernommen. Nach dieser letzten Stufe können die spezifischen Produkte mit einem normalen PEP entwickelt wer- den. Bei diesem Vorgehen wird also in der Produktplanung, -gliederung und -kon- struktion Freiraum gelassen für noch nicht vorhandene Informationen bezüglich zu- künftiger Marktbedürfnisse welche dann auch nach der Markteinführung leicht ins Produkt einfließen können. Eine reale Erscheinungsform dieser Überlegungen sind Multi-Life-Produkte, welche sich durch Funktions- und/oder Eigenschaftsvorräte auszeichnen, die bei entsprechenden neuen Anforderungen genutzt werden kön- nen. Zwingend notwendig bei solchen Produkten sind standardisierte Komponen- tenschnittstellen um eine Inkompatibilität mit zukünftigen Modulen zu vermeiden [PBFG07, S.101]. Durch diese Maßnahmen kann das Informationsvolumen bei ho- her Variations- und Innovationsvielfalt vergleichsweise niedrig gehalten werden.

2.3.2 Prozessgestaltung

Ein weiterer Komplexitätstreiber im Unternehmen sind schlecht beziehungsweise nicht angepasste Unternehmensprozesse, da diese gleichzeitig Wissens- und damit auch Informationsprozesse sind. Um die Vorteile der modularen Produkte nutzen zu können müssen ebenfalls die Prozesse im Unternehmen modular aufgebaut und unabhängig voneinander funktionsfähig sein. Nach der groben Definition der Pro- zessmodule müssen die Prozessschnittstellen definiert werden, was die Vorausset- zung eines durchgängigen Prozesses ist. Durch die Abstimmung eines jeden Pro- zesses mit seinen vor- und nachgelagerten Schritten in Bezug auf Daten, Aufgaben und Funktionen der IT-Systeme kann sichergestellt werden, dass veränderte Anfor- derungen an die Organisationsstruktur leichter von einer Organisationseinheit auf eine andere übertragen werden können [SS12a, S. 300]. Wie bei der Schaffung modularer Produkte müssen auch hier nach der Modularisierung der Prozesse Standartprozesse entwickelt werden die aus nichtvariablen Prozessmodulen beste- hen, welche immer durchlaufen werden müssen und aus variablen Prozessmodu- len, welche nicht immer zur Anwendung kommen [FG08, S. 51]. Durch die Standar- disierung der Schnittstellen können in einer derartigen Organisationsstruktur Pro- zesse integriert werden. Beispielsweise können durch den Zukauf externer Unter- nehmen Prozesse in den Prozessablauf eingegliedert werden, die vorher außerhalb der Unternehmung stattgefunden haben [SS12a, S.301].

2.4 Produktionsplanung und -steuerung

Aufgabe der Produktionsplanung und -steuerung (PPS) als Informationssystem liegt unter anderem in der Bereitstellung von Informationen, der Erstellung von Plä- nen, der Koordination von Abteilungen und der Überwachung und Steuerung von Prozessen [SS12a, S.195]. In Bezug auf die bisherigen Ausführungen fungiert die PPS als Wissensspeicher, der die Daten- und Informationsflüsse zwischen den Standardprodukten und den zugehörigen Standartprozessen koordiniert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Zusammenspiel zwischen der Referenzstruktur, dem Referenzprozess und dem Wis- sensspeicher (PPS) (Abb. aus [FG08, S.64])

Hauptaufgabe der PPS-Systeme ist dabei die Produktion zu planen und Materialien zu beschaffen. Dazu werden Materialstammdaten, Stücklisten und Arbeitspläne aus der Produkt- und Prozessstruktur benötigt, die über geeignete Schnittstellen ange- fordert werden können oder direkt im PPS-System verwaltet werden. (Schuh S.352) Der entscheidende Nachteil eines PPs-Systems zur Verwaltung der Daten liegt da- rin, dass Wissensinhalte, welche dezentral in IT-Systemen über das gesamte Un- ternehmen verteilt sind, nicht ohne größeren Aufwand in das System integriert wer- den können. So werden CAD-Modelle der Konstruktion in anderen Datenbanken und in anderen Formaten gespeichert wie die zugehörigen Simulationsdaten [FG08, S.65]. Ein Produktdatenmanagementsystem (PDM) kann in diesem Fall eine Lö- sung bieten, mit dem Daten- und Informationsflüsse erfasst, verwaltet, gepflegt und gesteuert werden.

[...]