Modeln wie echte Kerle

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Die Einführung von SysML ist nichts anderes, als ein System zu entwickeln und zu betreiben. Also genau das, was wir Systems Engineers am besten können, oder? Bei meinen Trainings- und Beratungseinsätzen stelle ich jedoch regelmäßig fest, dass bei der Einführung modellbasierter Entwicklung Kernelemente des Systems Engineering ignoriert und Best Practices über Bord geworfen werden. Was läuft da schief?

 

 

Auch echte Teufelskerle lernen das Sprechen und Laufen bei Mama. SysML stellt für Ingenieure erst mal eine Sprachbarriere dar. Eine Schulung reicht nicht. Oft fehlt ein Coach, der schnell Fragen beantwortet und den Einführungsprozess treibt.

Der goldene Westen liegt nicht am Atlantik. Das Pilotprojekt ist ein Produktivprojekt mit mangelnden Ressourcen. Es fehlt das Bewusstsein, dass die Einführung eine Investition ist, deren Rendite man erst später ernten kann.

Eine echte Heldin reitet am Pazifik weiter. Die Einführung wird als Projekt angesehen. Das ist bekanntlich irgendwann zu Ende. Der Betrieb des Systems, also die kontinuierliche Verbesserung, spielt oft keine große Rolle. In manchen Unternehmen gilt das Einführungsprojekt schon mit Lizenzkauf als abgeschlossen.

Calamity Jane kam sicher nicht auf dem Esel nach South Dakota. Den Anwendern wird ein Tool vorgesetzt, dass SysML „kann“. Man macht sich nicht klar, dass das Tool der Schlüssel zu guten Modellen ist. Dabei spielt Usability eine unterschätze Rolle.

Aussehen ist nicht alles. Es wird vergessen, dass die Macht des Modells nicht in bunten Diagrammen sondern in den Daten dahinter liegt. Diese Macht entfaltet sich erst, wenn man diese Daten nutzt.

 

Das Resultat sind frustrierte Systementwickler, neue Hindernisse im Projekt, eine Sammlung von Diagrammen ohne Betrachter, ein Haufen ungenutzter Daten, also schlicht Modelle von geringem Wert. Das Märchen von der konsistenten, nachverfolgbaren, interdisziplinären und widerspruchsfreien Systembeschreibung wäre auch zu schön gewesen. Aber, man hört immer wieder, dass Unternehmen SysML erfolgreich einsetzen. Vermutlich haben sie zur Einführung Dinge wie diese getan:

 

• Erstellung eines Vorgehenskonzepts, in dem der „Geschäftsfall“ und die strategischen Ziele des Unternehmens definiert wurden.
• Entwicklung eines Betriebskonzepts welches die Bedarfe der Nutzer (z.B. Requirement Engineers, Systemarchitekten, Systementwickler) und Betreiber (Prozess, Methoden und Tool-Verantwortliche) beschreibt.
• Die Durchführung einer Stakeholder-Analyse mit dem Ziel, alle Betroffenen, Befürworter, Gegner und Profiteure zu identifizieren und ins Boot zu holen.
• Analyse des Systemkontextes mit dem Ziel, den Umfang und die Schnittstellen (z.B. Requirement Management, Change Management oder auch CAN-Datenbanken) der Modellierungsumgebung zu beschreiben
• Durchführung einer Anwendungsfallanalyse, um zu beschreiben, zu welchem Zweck die Modelle verwendet werden sollen und welches Ergebnis von Wert wir erwarten.

 

Meine Erfahrung ist, dass alle, die SysML erfolgreich einsetzen mit der Implementierung der Anwendungsfälle begonnen haben, die mit überschaubarem Aufwand den größten Nutzen versprechen, die beliebten Low-Hanging-Fruits. Sicher haben diese Success-Story-Autoren nicht versucht im ersten Anlauf das System in voller Breite und Tiefe durchzumodellieren und zu simulieren. Sie sind iterativ-inkrementell vorgegangen, und haben die Möglichkeiten von Modellierung für die eigene Organisation sukzessive analysiert, weiterentwickelt und genutzt. Und jetzt, Systems Engineers, tut was ihr am besten könnt!