Drei Gründe, weshalb auch Ihre Organisation Systems Engineering braucht 

Das Verständnis für Systems Engineering hat sich bereits während des Zweiten Weltkriegs etabliert und erste Teams haben nach diesem Ansatz technische Produkte entwickelt. Der Durchbruch dieses Ansatzes erfolgte aber erst zum Ende des 20. Jahrhunderts. Systems Engineering bekam einen globalen Charakter und weltweite Anerkennung mit der Gründung von INCOSE im Jahr 1995. Die heutige Praxis zeigt uns, dass diese durchdachten und klar definierten Abläufe im Lebenszyklus eines Produktes (oder einer Dienstleistung) nicht verinnerlicht wurden. 

Was die genauen Gründe dafür sind, ist diskutabel und vielschichtig, daher widmen wir uns dem Aspekt, den wir sicher benennen können. Dabei geht es um die Motivation und die Beweggründe der Etablierung von SE-Praktiken und deren sogenannten „Practitioners“. 

Insbesondere sind es die folgenden drei Punkte, die mittels System Engineering aktiv angegangen werden können: 

1. Komplexität beherrschen  

Dass die Welt immer komplexer wird, ist kein Geheimnis. In der technischen Entwicklung liegt dieses Phänomen jedoch an der Tatsache, dass der Grad der Systemintegration um ein Vielfaches zugenommen hat und weiter zunimmt. Immer mehr Systeme sind Bestandteile anderer Systeme und die Kommunikation zwischen Systemen und Umgebungen expandiert ebenfalls. Um stetig wachsende Komplexität innerhalb eines Projektes bändigen zu können, ist es notwendig das große Ganze überblicken und anschließend teilen zu können. Ein derartiges „Teile und Herrsche“- Vorgehen stammt aus der Softwareentwicklung und wird vor allem in der Algorithmentheorie angewendet. Dabei geht es darum, das Hauptproblem in seine Bestandteile zu zergliedern. Die daraus entstandenen Problemhäppchen werden anschließend separat gelöst, um das große Problem zu bewältigen. Interessieren Sie sich für Softwareentwicklungsansätze? Lesen Sie mehr dazu hier: Agilität beginnt im Kopf – HOOD Blog.

In der Praxis liegt die große Kunst der Aufgaben- und Zuständigkeitsaufteilung darin, eine Balance zu finden und nicht zu grob-, aber auch nicht zu feingranular zu denken. Diese Expertise kann kein Handbuch vermitteln; durch Feedback und Leistungsüberprüfung (im Sinne der Zusammenarbeit und des daraus entstandenen Outputs) am Ende jeder Arbeitsphase lassen sich allerdings Erkenntnisse für die Zukunft gewinnen. Genau auf derartige Lessons Learned besteht der Ansatz des Systems Engineerings und die Rolle des Systems Engineers soll sich dem Problem der Komplexität des Systemlebenszyklus auf diese Weise stellen können. 

2. Dynamik reduzieren  

Ebenso wie die zuvor angesprochene Komplexität, ist hohe Dynamik ein weiteres Kennzeichen der heutigen Gesellschaft. Im privaten Umfeld werden dynamische Zustände reduziert, indem auf Routinen zurückgegriffen und sich auf Bekanntes und Festgelegtes verlassen wird. Dieses Vorgehen erzeugt Gefühle der Sicherheit und in einer weniger dynamischen Lage fällt die Orientierung auch leichter. 

Im Systemlebenszyklus gilt dasselbe: Ein klar definierter Arbeitsstand ermöglicht einen besseren Überblick über anstehende Aufgaben. Veränderungen lassen sich dadurch leichter nachvollziehen, akzeptieren und organisatorisch einordnen. Dies liegt an der Sicherheit, sowohl den bisherigen Weg als auch das zukünftige Ziel zu kennen.  

Systems Engineering reduziert die Dynamik, indem es einerseits das Konfigurationsmanagement priorisiert und andererseits Baselining als zusätzliche Methode heranzieht. Ein Systems Engineer soll dabei den Prozess des Konfigurationsmanagements möglichst früh einplanen, in den Projektplan entsprechend integrieren und die dazugehörigen Aktivitäten durchführen. 

3. Der Projektleiter ist kein Einzelkämpfer

Dieser Punkt bezieht sich weniger auf die aktuellen Gegebenheiten im Entwicklungsumfeld, sondern vielmehr auf die Positionierung eines Systems Engineers innerhalb der organisatorischen Projektstruktur. Die Schaffung einer Rolle, die als Schnittstelle zwischen Fachbereich und Projektleitung fungiert und beide Sichten gleichermaßen bedient, bleibt eine anspruchsvolle Aufgabe. Dies liegt einerseits an der etablierten Wahrnehmung der zentralen Rolle eines Projektleiters, andererseits an der hohen fachlichen Expertise im technischen Management.  

Auch wenn die Verantwortung eines Projektleiters innerhalb eines Projektes umfassend und ganzheitlich ist, ist es essenziell, Aufgaben zu delegieren und Verantwortung gezielt zu übertragen. Insbesondere dann, wenn der Themenkomplex eines Projektes groß ist und die technischen Themen viel Aufmerksamkeit bedürfen – was beispielsweise bei der Systemdefinition der Fall ist. Dabei darf und soll das Verständnis für das große Ganze auf der Systemebene bei einem System Engineer liegen.  

Dass die beiden Rollen des Projektleiters und des System Engineers Überscheidungen haben und eine Zusammenarbeit unabdingbar ist, wird durch das INCOSE Handbuch bestätigt. Es besagt, dass im Bereich der Lebenszykluskonzepte und Stakeholder-Anforderungen die beiden Parteien kollaborieren müssen, während Themen wie Systemdefinition und -strukturpläne in der Zuständigkeit des System Engineers liegen. Der Projektleiter ist verantwortlich für die organisatorischen und ressourcenbezogenen Strukturpläne eines Projektes. 

Quelle: INCOSE Handbook, 5. Version (S. 74) 

Dies sind die drei markantesten Punkte, die für Relevanz des Systems Engineerings in der modernen Produktentwicklung sprechen.   

Haben Sie noch weitere Benefits dieses Ansatzes für Ihre Organisation entdeckt und scheitern dennoch an der Umsetzung dieser Maßnahmen? HOOD beschäftigt sich mit den Themen des koordinierten Systemlebenszyklus, der dazugehörigen Prozesse sowie der Rolle eines Systems Engineers im Allgemeinen. Wie freuen uns auf Ihre (An)fragen! 

Dieser Blogbeitrag wurde von Mia Zipalovic für HOOD geschrieben; das Beitragsbild stammt von Freepik.