Entwicklungsmethode Grundlagen zum Systems Engineering und Tipps für die Einführung

Autor / Redakteur: Christian Tschirner / Dipl.-Ing. (FH) Monika Zwettler

Den Elefanten in Scheiben schneiden: Digitalisierung ohne Systems Engineering erscheint unmöglich, aber dabei sollte es auch handhabbar sein – Tipps für die Einführung.

Anbieter zum Thema

Groß wie ein Elefant scheint der Berg an Arbeit, wenn es um die Entwicklung komplexer Produkte und Systeme geht – diese über ihren Lebenszyklus strukturiert zu analysieren, spezifizieren, entwickeln und anzupassen ist Aufgabe des Systems Engineering.
Groß wie ein Elefant scheint der Berg an Arbeit, wenn es um die Entwicklung komplexer Produkte und Systeme geht – diese über ihren Lebenszyklus strukturiert zu analysieren, spezifizieren, entwickeln und anzupassen ist Aufgabe des Systems Engineering.
(Bild: © Olga Itina - stock.adobe.com)

Digitalisierung ist in aller Munde: Fing es mit dem Internet-of-Things an, so geht es heute um Smart Maintenance, Smart Home und Autonomes Fahren. Sogar von den Chancen künstlicher Intelligenz ist die Rede. Ganz gleich, ob es sich um nahe Realität oder kühne Visionen handelt: Hochgradig komplex sind diese Ideen. Das betrifft das Verstehen der Aufgaben aber natürlich auch die Umsetzung. Dass es da zu Unstimmigkeiten in der Entwicklung kommen kann ist klar! Woran das liegt? Zu wenig Struktur.

Der hohe Automatisierungsgrad moderner Prozesse, die zunehmende Vernetzung von Produkten sowie eine Vielzahl von neuen Regularien stellt Unternehmen vor Herausforderungen. Systems Engineering bildet ein flexibles und nachhaltiges Ordnungsprinzip, mit dem Unternehmen diese meistern können.
Der hohe Automatisierungsgrad moderner Prozesse, die zunehmende Vernetzung von Produkten sowie eine Vielzahl von neuen Regularien stellt Unternehmen vor Herausforderungen. Systems Engineering bildet ein flexibles und nachhaltiges Ordnungsprinzip, mit dem Unternehmen diese meistern können.
(Bild: Christian Tschirner)

Revolution der Entwicklungsprozesse

Seit gut 10 Jahren gewinnt ein Thema konsequent an Beachtung, wenn es um komplexe Projekte geht: Systems Engineering. Während um das Jahr 2010 häufig mehr Ablehnung und Desinteresse denn Neugierde bzgl. Systems Engineering aufkam, gewinnt das Thema heute immer mehr an Fahrt. Es ist kein Geheimnis, dass Unternehmen wie die Daimler AG mit ihrem SEED-Projekt, Audi, Claas oder Miele starke Systems-Engineering-Programme installiert haben. Das „Relikt“ der Luft- und Raumfahrt ist salonfähig geworden, auch international. Systems Engineering kann die Entwicklungsarbeit ähnlich revolutionieren, wie es das Toyota Produktionssystem einst mit dem Shopfloor geschafft hat. Dennoch ist das Thema groß und abstrakt und es gibt nicht das eine Systems Engineering. Das sollte jedoch nicht der Grund sein, SE links liegen zu lassen.

Die aktuellen Treiber für Systems Engineering.
Die aktuellen Treiber für Systems Engineering.
(Bild: Christian Tschirner)

Systems Engineering – die Grundlagen

Meist mangelt es an der Exaktheit in der Umsetzung des harmonisierten Vorgehens, weil die Reichweite nicht ausreichend erkannt ist. Daher Systems Engineering einmal ohne ISO zusammengefasst:

  • Ein Projekt ist immer durch mehr als den reinen Produktentwicklungsprozess geprägt. Das fängt Systems Engineering bewusst auf und bindet mit seinen Vorgehensweisen alle relevanten Stakeholder in das Projekt ein, also auch z.B. Einkauf, Entwicklungsqualität. Insbesondere die zwei wichtigsten Säulen bringt SE zusammen: Die Architekturentwicklung und das Projektmanagement. Damit überwindet SE das oft vorherrschende Silodenken. Die einheitliche Terminologie ist zunächst anstrengend, aber durchaus akzeptierter Nenner der Fachwelt; das macht die Zusammenarbeit leichter.
  • Systems Engineering hat auch einfache Methoden, die im Arbeitsalltag viel zu oft vergessen werden: Das Vorgehen vom Abstrakten zum Konkreten, vom Generellen zum Detail. Statt direkt mit einer Konstruktion zu starten, könnten durch eine Analyse der Ausgangslange späte zeit- und kostenintensive Iterationsschleifen vermieden werden. Solche Methoden der Umfeldanalyse gehören ebenso dazu wie das Denken in Varianten und das Denken in dynamisch veränderlichen Systemgrenzen.

Die verschiedenen Elemente des Systems Engineering.
Die verschiedenen Elemente des Systems Engineering.
(Bild: Christian Tschirner)

Hin zum Model-Based Systems Engineering (MBSE)

Bislang basierte Systems Engineering auf gut gelenkten Dokumenten, was jedoch an die Grenzen der Leistungsfähigkeit in den heutigen Entwicklungsprojekten und -organisationen stößt – die Geburtsstunde des Model-Based Systems Engineering (MBSE). Anders als in der weitgehend etablierten modellbasierten Entwicklung – repräsentiert etwa durch CAD, FEM und auch durchaus Ansätze wie Modelica – stehen im MBSE nicht fachdisziplinspezifische Artefakte im Mittelpunkt, sondern eine fachdisziplinübergreifende Beschreibung des Systems: das Systemmodell, das den Weg von den Kundenbedürfnissen hin zu einer Architektur im Sinne der ISO 15288 eines Produkts zzgl. weiterführender Inhalte repräsentiert und zum Dreh- und Angelpunkt der Arbeit macht.

Ergänzendes zum Thema
Systems Engineering – die Richtlinie ISO 15288

Grundsätzlich ist das Verständnis von Systems Engineering sehr facettenreich, was sich in einer relativ großen Anzahl von Definitionen äußert. Das stiftet Verwirrung. Organisationen wie das International Council on Systems Engineering (INCOSE) oder die ISO-Gremien stecken deshalb viel Energie in Aufklärung, Weiterentwicklung und Verbreitung eines harmonisierten Systems Engineering – mit Erfolg. Aus dieser Arbeit heraus hat sich die Richtlinie „ISO/IEC 15288: Systems and software engineering – System life cycle processes“ entwickelt. Die ISO 15288 beschreibt vier Prozess-Gruppen inkl. entsprechender Terminologie für den Lebenszyklus von technischen Systemen. Für jede Gruppe werden die für Systems Engineers relevanten Prozesse detailliert dargestellt. Je nach Komplexität oder abhängig von weiteren Randbedingungen wird der Aufwand für die Prozesse verändert, was Tailoring heißt. Und hier wird es spannend: Die klassischen SE-Prozesse beginnen bei der Identifikation von Stakeholdern und ihren Bedürfnissen. Daraus werden Use Cases und Anforderungen abgeleitet, die in einer Systemarchitektur münden, die als Grundlage für das weitere Geschehen in der Zusammenarbeit dient.

Je nach Ausgestaltung soll dies von allen Disziplinen für unterschiedliche Zwecke genutzt werden. Und das ist der springende Punkt: Die Einsatzszenarien für das Systemmodell müssen bekannt sein – es geht nicht darum, eine Architektur aufzubauen, man muss sie auch nutzen, z.B. für FMEA, Functional Costing, oder als Grundlage für o.g. zeitlich spätere physikalische Simulationen.

Das Ziel: mehr Systemverständnis

Um Missverständnissen vorzubeugen: Im MBSE geht es nicht um die möglichst durchgängige Simulation von Produkteigenschaften und -verhalten. Es könnte durchaus eine gute Grundlage geschaffen werden, diese Themen zu organisieren. In erster Linie sollen aber Systemverständnis über die Aufgabe und das technische Management eines Projekts besser werden.

Systems Engineering – den Elefanten in Scheiben schneiden

Ganz gleich, in welcher Abteilung Sie angesiedelt sind, (MB)SE kann mit Ihrem Verständnis für die eigenen Aufgaben und Prozesse hilfreich sein. Sie werden Aufwand reduzieren können und Fehler systematisch vermeiden. Widerspruchsfreie Spezifikationen sind der Startpunkt dank MBSE. Finden Sie Ihren eigenen Einsatzszenarien entlang des Produktlebenszyklus – und überlegen, ob und wie sie diese auf Basis des Systemmodells unterstützen können; immer, wenn es um Elemente ihres Produkts und ihre Zusammenhänge geht kann dies der Fall sein.

Der Nutzen daraus ergibt sich schnell. Haben Sie ein erstes Szenario umgesetzt, geht es entweder entlang des Prozesses immer tiefer in die Details oder in neue parallele Szenarien. Letztlich ergibt sich so sukzessive eine Datenbasis im Sinne des Systemmodells, die den Einstieg in das SE erleichtert.

Tipps für die Einführung von Systems Engineering

Wie nun aber konkret Vorgehen? Patentrezepte gibt es nicht. Es gibt aber wiederkehrende Erfolgsmuster, die berücksichtigt werden sollten:

  • Einsatzszenario kennen: Zu lange wurde auf das bloße Erstellen einer Architektur fokussiert. Sie ist allerdings nur Mittel zum Zweck. Identifizieren Sie die Anwendungsfälle des MBSE bzw. der Systemarchitektur in Ihrem Unternehmen. Das reicht von einer bloßen Visualisierung zur Verbesserung der Kommunikation in Meetings bis zur vollständigen Digitalisierung von einzelnen Prozessen. Wichtig ist, dass ein Szenario konkret benannt ist. Fragen Sie sich immer: Wofür kann ich die Informationen des Systemmodells nutzen und wie sieht der Prozess aus? Gibt es eine bestimmte Methode, die etabliert ist, z.B. DRBFM o.ä.?
  • Methoden lernen: Lange vernachlässigt in der Entwicklungsarbeit, im Toyota Produktionssystem der Schlüssel zum Erfolg. Methoden geben eine klare Struktur und vereinheitlichen die Arbeit. Bewusste Zeit für methodisches Arbeiten am Anfang kann viel Ärger zum Ende des Projekts sparen und ist die Grundlage für Systems Engineering
  • 3P-Konzept verstehen: Methoden – ja. Aber sinnvoll! Eine Methode muss einfach gesagt gefallen unter den Kriterien Process (also in den Prozess passen), Performance (also das liefern, was benötigt wird) und Presentation (es muss auch einfach gefallen…). Viele wissenschaftliche Methoden liefern die 150%-Version einer Methode. Auch Methoden können getailort werden.
  • Systems Engineering kommunizieren: Beschäftigen Sie sich nicht nur mit dem Thema, sondern reden Sie auch darüber. Schnell werden Sie feststellen, dass viele Kollegen sich auch mit ähnlichen Gedanken herumschleppen.
  • Nicht kaputtrechnen: Rechnen Sie nicht den ROI im ersten Schritt. Es wird dauern, aber mit jedem neuen Projekt werden Sie besser. Auch ein Baukastensystem rechnet sich frühestens in der zweiten Produktgeneration. Und dann kann das Rechnen beginnen.
  • Workshop vor Software: Software ist für das MBSE unabdingbar. Aber zu Beginn starten Sie per „pen-and-paper“. Es gibt gute Workshopkarten und Beispiele, wie Sie die Systemarchitektur mit Kollegen gemeinsam grob entwickeln und dadurch signifikante Vorsprünge aufbauen. Systemverständnis ist das Schlagwort.
  • Software einführen: Es geht heute nicht mehr ohne Software – nach einiger Zeit. Gucke Sie sich gut auf dem Markt um. Es gibt inzwischen viele kleinere Hersteller, die sehr gute Software anbietet – und gerade bei der Usability punkten können.
  • Mit Partnern arbeiten: Schicken Sie Ihre Leute hinaus, Austausch mit Gleichgesinnten ist essentiell. Es ist soviel los in der SE-Community! Sie werden nicht verlieren, wenn Sie sich mit anderen Unternehmen über SE austauschen.
  • Hierarchien überwinden: SE setzt fachliche Akzente. Das deutsche Karrieresystem sieht Erfolg nur über disziplinarische Führung und Management. Ein Chief Systems Engineer benötigt keine Mitarbeiter – sollte aber mit einem Bereichsleiter auf Augenhöhe stehen. Seine Entscheidung sollte Gewicht haben dürfen.
  • Die Eierlegende-Wollmilch-Sau vermeiden: Große Plattformen malen ein Bild der nahtlosen und durchgängig digitalisierten Prozesse – eine schöne Vision, aber weit weg von der Realität. Wenn heute noch mit Excel und Power Point gearbeitet wird, ist der Weg zur Vision lang und auch technisch heute noch lange nicht gelöst. Wichtig ist: Akzeptieren Sie, dass SE in kleinen Schritten vorangeht, aber jeder seinen Nutzen für Sie bringen kann. Jeder kleine Schritt bringt auch Ihre Mitarbeiter voran.

Systems Engineering ist wie Sport

Warum Systems Engineering? Es gibt keine rationale Antwort dafür, man muss einfach daran glauben, dass die Struktur und Konsequenz von SE Unternehmen voranbringen und keine Last sind. Und auch, dass es für die Mitarbeiter leichter wird. Systems Engineering kann man mit Sport vergleichen – auch hinsichtlich der Frage, wie intensiv man sich dem Thema verschreiben wird. Selbstredend hinken die Beispiele etwas, zeigen aber die besondere Idee des Ansatzes auf:

  • Fußball: 1974 und 2014 – Deutschland ist Fußball-Weltmeister. Das Produkt ist beides Mal der Pokal. Aber der Weg ist anders. 1974 maßgeblich durch Standfußball und wenige Tore geprägt, laufen Jogis Jungs 2014 durchschnittlich 115,3 km pro Spiel. Tore fallen wie am Fließband. Es gibt abgesteckte „Räume“, einstudierte Laufwege und Passpunkte. Eigentlich ein Graus für jeden Ingenieur, wird er doch in seiner Individualität eingeschränkt. Schweini und Co. vermitteln aber pure Spielfreude und sind auch nach dem Spiel topfit – vielleicht. auch, weil das Umfeld aus Hotel, Reiseplanung,... beachtet wurde? Geht das nicht auch in der Produktentwicklung? 2018 wollen wir nicht vergessen – auch ein Top-System braucht Pflege!
  • Jogging Es tut ein wenig weh, den inneren Schweinehund zu überwinden. Aber nach einiger Zeit, durchaus auch etwas „Materialsport“ läuft das Ganze rund, macht Spaß – und hat positive Effekte auf die Stimmung, Schlafqualität, Gesundheit und vieles mehr. Und es ist bekannt, dass der regelmäßige 10-km-Volkslauf weitaus gesundheitsfördernder ist, als ein Marathon. Die Randbedingungen aus Vorbereitung, Trainingsplan, Sportklamotten … können übrigens die gleichen sein. Warum also mal nicht den Systems Engineering-Elefanten mal in Scheiben schneiden?

Dieser Beitrag erschien zuerst auf unserem Partnerportal www.konstruktionspraxis.de

* Dr. Christian Tschirner, Vorstandsmitglied Gesellschaft für Systems Engineering und Geschäftsführer der Two Pillars GmbH

(ID:46237464)