Startseite » Systems Engineering »

Systems Engineering Return on Investment – oder: Wie viel SE ist notwendig?

Begriffe des Systems Engineerings – Teil 5
Systems Engineering Return on Investment – oder: Wie viel SE ist notwendig?

Systems Engineering Return on Investment – oder: Wie viel SE ist notwendig?
Bild 1: Rentabilität eines Baukastensystems als Analogie zur SE-Einführung Quelle: GfSE
Systems Engineering, Model-Based Systems Engineering, Systemarchitekturen, Prozesse, verschiedene ISO-Richtlinien – das waren die Themen unseres Glossars zum Systems Engineering im Jahr 2015. Noch immer steigt das Interesse am Paradigma Systems Engineering (SE) stark; die Anzahl an Evaluationsprojekten und Einführungsprogrammen bringt dies zum Ausdruck. Teilweise berichten die jeweiligen Unternehmen auch offen über ihre Aktivitäten, beispielsweise am Tag des Systems Engineerings – TdSE. In diesem Zusammenhang kommt aber insbesondere auf Management-Ebene immer wieder die Frage auf: „Was bringt mir das und wie viel SE ist notwendig?“

Christian Tschirner und Sascha Ackva, Mitglieder des Vorstands der GfSE

Warum eigentlich ein „SE-Return on Investment (RoI)“? Beim Systems Engineering (SE) ist die Diskussion über den Wertbeitrag noch relativ jung: Der Ansatz war durch die anfängliche Anwendung in sicherheitskritischen und hochkomplexen Systemen der Luft- und Raumfahrt nicht vordergründig auf den Nachweis von Wirtschaftlichkeit angewiesen. Hier ging es zurecht in erster Linie um Qualität und Sicherheit. Erst mit dem aufkommenden Interesse der Privatwirtschaft kam die Wirtschaftlichkeitsdiskussion auf. Die Bewertung des Wertbeitrags steckt aber in einem Dilemma: Investitionen in neue Technologien und Methoden sollen aus Management-Sicht eine möglichst kurze Amortisationszeit haben: üblicherweise erwartet die Industrie weniger als 24 Monate. SE ist jedoch ein Lebenszyklusansatz, der seine Wirkung langfristig entfaltet – von der Wiege bis zur Bahre, bspw. bei Marktphasen von 60 Monaten. Das bedeutet, dass zunächst in frühen Lebenszyklusphasen ein erhöhter Aufwand einfach akzeptiert werden muss, der sich aber in späteren Phasen ausgleicht, weil etwa das Produkt im Feld weniger Ausfälle aufweist. Bei der Bestimmung eines SE-RoI ist nun das Problem, überhaupt einen geeigneten Ansatz zu identifizieren – alleine schon bedingt durch die Herausforderungen der Kostenrechnung.

Ein Vergleich: Produktbaukastensysteme

Während beim Thema Systems Engineering die Diskussion um die Notwendigkeit aufgrund von Vorabinvestitionen sehr penibel geführt wird, ist die Ausgangslage bei Produktbaukastensystemen nicht anders – deren Notwendigkeit wird allerdings diskussionslos akzeptiert. Die Einführung von Baukästen kann zu enormen Rationalisierungsmöglichkeiten führen – zweifelsfrei. Zur Einführung eines Baukastens sind jedoch erhebliche Vorleistungen notwendig. Rentabel wird er erst im Verlauf seines Lebenszyklus, wenn die Summe der Aufwände für die Anpassung geringer ist als die Aufwände für eine jeweilige Neuentwicklung (Bild 1). Das ist mit Risiken verbunden, die allerdings akzeptiert werden. Gerade deshalb sollte diese Sicht auch für das SE gelten: Zunächst sind die Aufwände hoch, da die Mannschaft noch nicht eingespielt ist, geschult werden muss und vielleicht auch die neue Rolle eines Systems Engineers in Ergänzung zum Projektmanager akzeptiert werden muss. Über die Zeit überwiegen dann aber die Vorteile: Die Kommunikation und Koordination wird verbessert, die Spezifikationen werden besser und damit die Fehler geringer – die Kosten sind dann längst eingespielt.

Vorbild für neue Ansätze in der Produktentstehung sind meist die etablierten Ansätze wie Lean bzw. Six Sigma. Six Sigma verfolgt in seiner Vision genaugenommen ein Qualitätsniveau von 99,99966 %. Man definiert dann aber für den jeweils vorliegenden Fall das notwendige Sigma-Niveau. Bei SE „implementiert“ man jedoch meist unbewusst das „große Ganze“ – statt ebenfalls für das Unternehmen das richtige Niveau zu bestimmen. Zudem: Six Sigma funktioniert nur, wenn es kontinuierlich und dauerhaft in dedizierten Six-Sigma-Projekten zum Einsatz kommt. Mit zahlreichen kleinen Hilfsmitteln werden dann im jeweiligen Projekt enorme Potentiale frei – ein 5S-Workshop schafft definitiv sofortige Transparenz. Aber Hand aufs Herz: Ist das wirklich vergleichbar?

Beispielprojekte aus der SE-Community

Im Folgenden ein kleiner Überblick über Projekte, die sich mit dem Wertbeitrag des SE auseinandergesetzt haben. Bei allen Ansätzen wird auf die klassischen SE-Prozesse abgezielt (vgl. ISO/IEC 15288). Aufwände für Projektmanagement-Aktivitäten sind noch nicht einberechnet.

  • Beim Luftfahrtunternehmen Boeing wurden für drei gleichzeitig ablaufende ähnliche Projekte SE-Aktivitäten in unterschiedlichem Umfang eingesetzt [Fra95] – hier zeigte sich bei erhöhtem SE-Aufwand ein positiver Einfluss auf die Produktqualität und die Projektlaufzeit.
  • Rolls-Royce hat durch den Einsatz von SE in mehreren Testprojekten eine Reduktion der fehlerbedingten Designänderungen von 30 – 70 % auf etwa 2 % erreicht [DYY+12, S.135].
  • In einer quantitativen Studie wurde von Honour die Korrelation von Budget- und Terminüberschreitungen mit dem investierten SE-Aufwand untersucht [Hon13]. Das Optimum für SE-Aktivitäten lag bei etwa 15 % des Projektbudgets; so erreichten die Überschreitungen ein Minimum (Bild 2). Sowohl weniger als auch mehr Aufwand für SE führten zu schlechteren Ergebnissen.

Das zeigt: Unternehmen sollten zukünftig bei der Planung von Projektbudgets umdenken und zu den klassischen Projektmanagement-Aktivitäten auch Ressourcen für SE einplanen.

Zur Abschätzung des notwendigen Aufwands für SE-Aktivitäten wurden unterschiedliche Modelle entwickelt. Das „Eine“ existiert jedoch nicht. Das ist aber auch nicht schlimm, da grundsätzlich unternehmensindividuell abgewogen werden sollte, „wie viel SE nötig ist“. Das bekannteste Konzept hierzu ist das CoSysMo – Constructive Systems Engineering Cost Model [Val05]. Es basiert auf den Phasen der ISO/IEC 15288; die SE-Aktivitäten werden in jeder Phase des Lebenszyklus durchgeführt – jedoch mit unterschiedlicher Intensität. Dadurch ergibt sich eine Verteilung des SE-Aufwandes in Personenmonaten im Lebenszyklus und nach notwendiger Intensität. Ein anderer, pragmatischer Ansatz ist die Erweiterung der bekannten FMEA zur Bewertung der Rentabilität von SE-Methoden. Hier werden Prozessschritte analysiert, um präventiv Fehler bzw. Lücken im Entwicklungsprozess zu erkennen und die Auswirkung zu bewerten. Dann wird die Höhe des Risikos vor und nach der Maßnahme mit den Kosten für die Maßnahmen in Relation gesetzt –
Ergebnis: Der RoI für diese Maßnahme (Bild 3) [ESL+13].

Systems Engineering hat das Potential,
Entwicklung und nahestehende Bereiche zu vereinen

Selten wird wirklich offen über den Nutzen und die implementierte Intensität von Systems Engineering gesprochen. Viel wichtiger ist aber: SE hat das Potential, die Entwicklung und nahestehende Bereiche zu vereinen und bietet ein einheitliches Fundament für alle wesentlichen Tätigkeiten zur Erfüllung der Kundenbedürfnisse. Erstmals bietet sich die Chance, mit einem Paradigma alle Stakeholder der Produktentstehung „an Bord zu holen“ – der Einkauf zieht Nutzen bei der Beschaffung, der Vertrieb, der Projektleiter, der Fachexperte… Das INCOSE Systems-Engineering Center of Excellence (SECOE) untersucht genau diesen Return-on-Investment des Systems-Engineering und bestätigt eine gegenläufige Korrelation zwischen den aufgetretenen Kosten- und Zeitüberschreitungen von Projekten und dem Aufwand für das Systems-Engineering.

Bild 1: Rentabilität eines Baukastensystems als Analogie zur SE-Einführung
Quelle: GfSE
Bild 2: Kosten- und Zeitüberschreitungen in Korrelation mit den Systems-Engineering-Aufwendungen
Quelle: [Hon13]/GfSE
Bild 3: Erweiterte FMEA zur Bestimmung des SE-RoI (Beispiel)
Quelle: GfSE

Info

Zu dieser Rubrik

‚In erster Linie geht es um Kommunikation‘ – das war der Titel der Titelstory der ersten Ausgabe der develop3 systems engineering, heute KEM Systems Engineering. Tatsächlich wird die Bedeutung von Kommunikation in Projekten häufig unterschätzt. Projekte sind heute höchst interdisziplinär und im Regelfall über Zeitzonen, Kulturkreise und Sprachräume verteilt. Die präzise und konsistente Verwendung von Begriffen wird somit zur Schlüsselkompetenz. Eine der ersten Aufgaben des Systems Engineers im Projekt ist deshalb die Schaffung eines Vokabulars, das eine eindeutige Kommunikation fördert. Zur Unterstützung dieser Aufgabe veröffentlichen wir in enger Zusammenarbeit mit der Gesellschaft für Systems Engineering (GfSE) e.V. in jeder Ausgabe der KEM Systems Engineering Definitionen zu relevanten Begriffen des Systems Engineerings; Ausgangspunkt hierfür ist die deutsche Übersetzung V. 3.2.2 des Handbuchs Systems Engineering des International Council on Systems Engineering (INCOSE).

kem.redaktion@konradin.de

Unsere Whitepaper-Empfehlung
Video-Tipp

Unterwegs zum Thema Metaverse auf der Hannover Messe...

Aktuelle Ausgabe
Titelbild KEM Konstruktion | Automation 3
Ausgabe
3.2024
LESEN
ABO
Newsletter

Abonnieren Sie unseren Newsletter

Jetzt unseren Newsletter abonnieren

Webinare & Webcasts
Webinare

Technisches Wissen aus erster Hand

Whitepaper
Whitepaper

Hier finden Sie aktuelle Whitepaper


Industrie.de Infoservice
Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de