Brücken schlagen zwischen Business- und PLM-Architektur

Vor Jahrzehnten, als die Werften die ersten CAD/CAM- und Nesting-Systeme einsetzten, waren ihre PLM-Landschaften vergleichsweise einfach. Heute können sie 30 bis 40 unterschiedliche und zum Teil sehr spezialisierte Anwendungen umfassen, die zusammenspielen müssen, um die Prozesse der unterschiedlichen Bereiche zu unterstützen. Deshalb wird es für die Werften immer schwieriger, den Überblick zu behalten und sicherzustellen, dass die PLM-Architektur ihre gegenwärtigen und künftigen Anforderungen erfüllt. EA hilft Ihnen, die Komplexität ihrer PLM-Landschaften besser zu managen.

Einige Werften haben bereits Erfahrung mit EA gesammelt und sind glücklich damit. Andere beklagen sich über den damit verbundenen Papierkram, der ihrer Ansicht nach zu wenig Nutzen produziert. Das ist jedoch unserer Meinung nach kein Grund, auf EA zu verzichten, denn die Komplexität der PLM-Landschaften nimmt weiter zu. Die Lösung besteht darin zu wissen, was genau wie zu tun ist.

Nutzung vorhandener EA-Frameworks

Es gibt für EA eine Vielzahl von Standards-Frameworks mit Empfehlungen, wie die Unternehmen am besten vorgehen sollten. Wenn Kunden sich bereits für ein bestimmtes Framework entschieden haben, folgen wir diesem Standard gerne.

Ein wesentlicher Bestandteil ist die Einbindung und das verbindliche Engagement der Organisation, was die Überprüfung der organisatorischen Abläufe einschließt. Außerdem müssen die Sponsoren, Stakeholder etc. identifiziert, der Umfang und das Budget festgelegt werden. Der vielleicht wichtigste Punkt aber ist die Definition der Architektur-Vision bzw. der gewünschten Ziel-Situation.

Wenn die organisatorischen Aufgaben zufriedenstellend erledigt sind, folgt als nächster Punkt die Definition der PLM-Architektur. Dazu müssen die Unternehmen zunächst die Ist-Situation ihrer IT und Geschäftsbereiche verstehen. Dann ist es zweckmäßig, eine oder mehrere Ziel-Architekturen zu definieren, die miteinander verglichen werden können, um die Vision zu detaillieren. Ausgehend davon kann man dann die Lücke zwischen Ist- und Ziel-Zustand analysieren. Die Lücken können fehlende Skills sein, nicht präzise definierte Prozesse, fehlende oder fehlerhafte Informationen oder funktionale Defizite der Anwendungen. Eine konsolidierte Gap-Analyse ist die Grundlage für die Implementierung der Ziel-Architektur.

Eine der wesentlichen Herausforderungen bei der EA ist das Zusammenspiel von Business-Architektur und IT-Architektur. Um es besser zu verstehen, haben wir eine Best Practice entwickelt, die sich Information Flow Analysis (IFA) nennt. Sie beschreibt den Weg der wichtigsten Informations- bzw. Business-Objekte durch die Organisation. Im Schiffbau gehört dazu z.B. die Schiffsspezifikation, die den Input für die nächsten Objekte liefert. Das kann ein General Arrangement Plan, ein P&ID oder ein Testprotokoll sein. Ihre Input-/Output-Beziehungen veranschaulichen die Informationsflüsse zwischen den verschiedenen Bereichen und Abteilungen.

Wenn man die IFA um relevante Informationen ergänzt, z.B. in welchen IT-Systemen diese Objekte erzeugt und verwaltet werden, kann man leicht die Brücke zwischen Business zur IT-Architektur schlagen. Die Definition von Business Objects und die Analyse der Informationsflüsse ist der Schlüssel für eine an den Business-Anforderungen ausgerichtete PLM-Architektur. Dabei gilt der Grundsatz des so viel wie nötig, aber so wenig wie möglich, um sich nicht in zu vielen Details zu verlieren.

Drei Beispiele aus der Praxis

Im Rahmen unserer Web-Seminarreihe PROSTEP Shipbuilding PLM Insights stellen wir Ihnen drei praktische EA-Projekte vor, die wir in letzter Zeit realisiert haben. Sie veranschaulichen die Vielseitigkeit des Ansatzes. Im ersten Anwendungsfall hatte das betreffende Unternehmen alle erforderlichen IT-Anwendungen installiert und wollte wissen, wie sie integriert werden müssen, um die Geschäftsprozesse optimal zu unterstützen. Anhand der Input-Output-Beziehungen zwischen den Business-Objekten konnten wir die Integrationsanforderungen sehr einfach visualisieren.

Im zweiten Anwendungsfall untersuchen wir den Informationsfluss bei derselben Werft aus der Sicht des Schiffsentwicklungsprozesses, um eine genauere Planung des nächsten Projekts zu ermöglichen. Dazu verknüpften wir das Netzwerk der bereits erfassten Business-Objekte mit den Meilensteinen. Auf diese Weise konnte die Werft die Arbeitslast pro Meilenstein und auch die Auswirkungen der Verschiebung eines Meilensteins besser abschätzen. Außerdem analysieren wir in einem dritten Beispiel den Fluss der Business-Objekte aus Sicht der Kollaboration-Beziehungen mit unterschiedlichen Partnertypen. Die Art wie Unternehmen zusammenarbeiten hat nämlich ebenfalls Auswirkungen auf die PLM-Architektur.

Zusammenfassend lässt sich festhalten, dass die Bedeutung von EA für die Werften mit wachsender Komplexität der PLM-Systemlandschaften zunimmt. Es gibt eine Vielzahl von Tools zur Modellierung der EA und der Beziehungen zwischen Business und IT-Architekturen, aber sie sind nur dann hilfreich, wenn das Unternehmen genau weiß, was es damit eigentlich erreichen will. Noch wichtiger ist Governance: EA ist eine strategische Disziplin, die den gesamten Lebenszyklus der PLM-Architektur begleiten muss.