Erfolgreiche Produktentwicklung heißt, komplexe Zusammenhänge zu verstehen und beherrschbar zu machen. Durch Transparenz, Risikoreduzierung und Verringerung der Produktlebenszykluskosten bietet Systems Engineering einen systematischen und durchgängigen Ansatz zur Problembewältigung und liefert damit einen entscheidenden Mehrwert. Ohne diese Werkzeuge und Methoden kann die wachsende Komplexität mit der Vernetzung von Hard- und Software nicht mehr überblickt und gehandhabt werden. Obwohl es Systems Engineering seit über 50 Jahren gibt, hat sich der Standard immer noch nicht übergreifend durchgesetzt. Um Systems Engineering nutzenbringend und effizient anzuwenden, bedarf es eines einfachen, pragmatischen Ansatzes, der sich am spezifischen Use-Case des Unternehmens orientiert und über die Betrachtung der Prozesse hinausgeht.

Systems Engineering ist ein machtvolles Werkzeug

Was ist Systems Engineering?
Erfolgreiche Produktentwicklung heißt, komplexe Zusammenhänge zu verstehen und beherrschbar zu machen sowie das Produkt in der Wechselwirkung mit seiner Umwelt über den gesamten Lebenszyklus zu betrachten. Um dabei systematisch vorzugehen, stellt Systems Engineering (SE) einen Leitfaden zur Problemlösung bereit, der kreativ und intelligent anzuwenden ist. Über spezifische Modelle strukturiert SE den Produktentstehungsprozess in einem Ansatz „vom Groben zum Detail“ entlang ineinandergreifender Phasen. Die gegenwärtige Entwicklung von Produkten ist durch einen stetig wachsenden Softwareanteil und eine steigende Vernetzung herausgefordert. Ohne die Werkzeuge und Methoden aus dem Systems Engineering kann diese Komplexität nicht mehr überblickt und gehandhabt werden.

Was ist Systems Engineering nicht?
Systems Engineering ist kein Kochbuch-Ansatz und liefert keine automatische Lösung aller Probleme („silver bullet“). Es ist kein Ersatz oder Gegensatz zu Intuition, Kreativität, Situationskenntnis und geistiger Auseinandersetzung mit Problemen, sondern setzt diese voraus bzw. macht sie nutzbar zur Zielerreichung. Abbildung 1 zeigt, wie Systems Engineering die Problemlösung mit Werkzeugen und Methoden entlang ineinandergreifender Phasen unterstützt. Die Ausprägung der Unterstützung ist abhängig von der Problembeschaffenheit und wird individuell angepasst.

Woher kommt Systems Engineering?
Die Methoden und Werkzeuge des Systems Engineerings haben ihren Ursprung in der Luft- und Raumfahrt. So wurden beispielsweise mit der Apollo Mission in den 60er Jahren technisch umfangreiche Produkte entwickelt, die in ihrer Komplexität und ihrem Programmumfang sowie -risiken alles bisher Dagewesene weit übertrafen und die sich zudem im Spannungsfeld von einer Vielzahl an Anforderungen, Vorgaben, Regularien, Sicherheitsvorschriften und Stakeholdern befanden. Mit herkömmlichen Ansätzen wären derartige Programme nicht in der Zeit und mit dem Erfolg („in 10 Jahren einen Menschen zum Mond und sicher wieder zurück“) möglich gewesen. Mit diesem Hintergrund verbreitete sich Systems Engineering auch in der zunehmend komplexer werdenden Schienen- und Automobilindustrie. In den 90er Jahren wurden die Militärstandards von Systems Engineering in die IEEE-1220 überführt. Durch die Gründung des International Council on Systems Engineering (INCOSE) 1990 mit dem entsprechenden Chapter für den deutschsprachigen Raum 1997, der Gesellschaft für Systems Engineering e.V. (GfSE), etablierte sich Systems Engineering weiter über Anwender in unterschiedlichen Branchen, Handbüchern, Best Practices, Normen und Zertifizierungs-/Trainingsprogrammen.

Was kann Systems Engineering?
Systemkompetenz durch eine ganzheitliche Systemsicht, die Betrachtung der Interaktionen von Systems of Systems und die Risikominimierung durch Transparenz und Planungsgenauigkeit komplexer Projekte sind drei typische Use-Cases von Systems Engineering. Auf zwei dieser Use-Cases soll hier anhand von Beispielen aus der Praxis näher eingegangen werden.

Risikominimierung durch Transparenz und Planungsgenauigkeit
Ein Unternehmen der Verteidigungsindustrie entwickelt und produziert über acht Jahre lang ein komplexes Produkt, das in mehreren hunderttausend Konstruktionsstunden und zehntausenden Zeichnungen spezifiziert und mit über fünftausend Unterauftragnehmern produziert wird. Die Auftraggeber des Unternehmens kommen aus dem öffentlichen Bereich mit Auftragssummen, die sich in einem elfstelligen Bereich bewegen. Damit gelten im Gegensatz zu konventionellen Märkten weitere Vorschriften, Regularien und Geheimhaltungsabkommen, die die Produktentwicklung zusätzlich komplex machen.

Nicht selten werden Aufträge dieser Art nur an Unternehmen vergeben, die im Vorfeld nachweisen können, dass sie in der Lage sind, Produkte dieses Umfangs unter den geltenden Rahmenbedingungen entwickeln zu können. Der Standard, der an dieser Stelle eingefordert ist, heißt Systems Engineering. Über diesen Fähigkeitsnachweis wird dem Auftraggeber dargestellt, in welchen Phasen, Abläufen, Ergebnissen und Verantwortlichkeiten das Produkt entwickelt, gefertigt und verifiziert wird. Im Mittelpunkt steht dabei zum Beispiel der Umgang mit Anforderungen, die Zusammenarbeit mit Unterauftragnehmern, das Konfigurationsmanagement und die Arbeitspaketplanung des Milliardenprojekts. Systems Engineering stellt dabei eine Methodik bereit, die jeden einzelnen Produktentstehungsprozess inklusive Arbeitsergebnissen und Schnittstellen betrachtet und in Zusammenhang bringt. Als Grundlage für den Fähigkeitsnachweis gilt eine Systems Engineering Referenz (zum Beispiel ISO15288), nach der die Produktentstehung ausgerichtet ist. Aber nicht nur die prozessuale Verankerung von Systems Engineering wird nachgewiesen, sondern auch die Qualifikationen der Ressourcen, welche Schlüsselrollen im Projekt besetzen. Über Zertifizierungen wird sichergestellt, dass Prozesse nicht nur beschrieben, sondern auch verinnerlicht und gelebt werden.

Entwickeln von Systemkompetenz
Systemdenken zeichnet sich durch verschiedene Fähigkeiten und Vorgehensweisen aus (s. Abbildung 2) und ist Grundlage zur Entwicklung von Systemkompetenz.

Eine ganzheitliche und systemische Betrachtungsweise, die über das Instrument Systems Engineering realisiert wird, verfolgt auch ein OEM aus der Automobilindustrie. Herausforderungen gibt es viele. Die CO2 Vorgaben erfordern immer mehr Effizienzsteigerungen, Elektrifizierung und autonomes Fahren im Zuge der Digitalisierung führen zu ganz anderen Mobilitätsanforderungen und Geschäftsmodellen. Die Integration von immer mehr Funktionen, gesteuert durch immer mehr Software, erhöht deutlich die Komplexität.

Das Endprodukt Auto, ein optimales Gesamtsystem durch stimmiges Zusammenspiel der einzelnen Komponenten, wird durch einen phasenorientierten Produktentwicklungsplan realisiert, in dem die technologischen Anforderungen die Architekturen vorgeben. Spezialisierte Fachbereiche entwickeln in interdisziplinären Teams die bestmöglichen Lösungen unter Berücksichtigung abgeleiteter Ziele wie Eigenschaften, Kosten, Gewicht und Qualität. An festgelegten Eckpunkten findet die Synchronisation der Komponenten und Subsysteme im Gesamtverbund statt. Über die Verifikation der Anforderungen und die Ableitung von Korrekturmaßnahmen reift das Gesamtsystem über den Produktentstehungsprozess zu einem qualitativ hochwertigen Endprodukt.
Systems Engineering gibt dabei die Entwicklungslogik vor, in der Anforderungen verstanden, interpretiert und zu Zielen heruntergebrochen und kontinuierlich verifiziert werden, um am Ende den unverschiebbaren Meilenstein, Start of Production, qualitativ hochwertig und kostenoptimal zu erreichen.
Ein wesentlicher Erfolgsfaktor im SE ist das Frontloading. Das heißt, der Fokus liegt auf den frühen Projektphasen, in denen die Weichen für den späteren Projektverlauf gelegt werden. Der Aufwand in die genaue Analyse der Anforderungen lohnt sich bei einem Absatz von über zwei Millionen Fahrzeugen pro Jahr, denn Rückrufaktionen und späte Änderungen kosten erhebliche Aufwendungen und Reputation.

Systems Engineering hat sich in vielen Branchen immer noch nicht durchgesetzt

Obwohl Systems Engineering als Standard in seiner heutigen Form seit über 50 Jahren existiert, wird er bis heute nicht umfassend umgesetzt. Dafür gibt es verschiedene Gründe. Drei davon sollen hier näher erläutert werden.

• „Der Systems Engineering Ansatz ist für die Luft- und Raumfahrt entwickelt worden, deswegen passt er auch nur auf diese Branche!“

Systems Engineering hat seinen Ursprung da, wo komplexe Produkte innerhalb von großen Projekten mit zahlreichen Stakeholdern entwickelt wurden. Damit geht die Auffassung einher, dass sich die Anwendungsnotwendigkeit ebenfalls auf diese Branchen und deren Produkte bedingt und der Wirkungsgrad nur da spürbar und hoch ist. Dieses Image lässt Systems Engineering gegenüber anderen Methoden, wie z.B. Agile, oft alt und verstaubt wirken.

Wer in den letzten Jahrzehnten die Produktentwicklung verfolgt hat und einen Blick in die Zukunft wirft, dem wird schnell auffallen, wie sich Produkte, Produktentwicklungszeit, -lebenszyklen und Entwicklungskosten verändert haben bzw. weiter verändern. Erfolgreich sind die Unternehmen, die mutige, technologisch konkurrenzfähige Systemlösungen mit immer größerem Softwareanteil ressourceneffizient anbieten können. Die dazugehörigen Komponenten werden multifunktionaler, die Gesamtlösung muss markt- und kundenspezifisch anpassbar und integrierbar sein und den Zulassungsregularien unterschiedlichster Länder entsprechen. Um das zu realisieren, bedarf es diversifizierter Experten aus unterschiedlichsten Disziplinen.

Mit anderen Worten: Ein Höchstmaß an Anforderungen, viele Stakeholder, hohe Komplexität und Sicherheit betreffen nicht mehr nur die ursprünglichen Systems Engineering Branchen, sondern alle Technologieunternehmen mit Erfolgsanspruch.
Dazu kommt, dass sich SE mit anderen Methoden, wie z.B. Agile, nicht ausschließt, sondern eher ergänzt. Durch agiles Arbeiten können in bestimmten Phasen der Produktentwicklung oft schnell umfassende Probleme gelöst oder ein nächster Schritt erreicht bzw. aufgeholt werden. Dazu sorgt die übergreifende, mittelfristige Zusammenarbeit für zusätzliche Motivation.

• „Der Nutzen von Systems Engineering ist schwer quantifizierbar!“

Neues in einem Unternehmen zu etablieren, heißt Veränderung. Veränderung in einem Unternehmen bedeutet Ressourcen, „Reibung“ und Zeit. Diesen Aufwänden muss bei der Entscheidung zur Veränderung ein Business Case gegenüberstehen, der die Aufwände durch einen deutlich größeren Nutzen kompensiert. Einen typischen SE Business Case gibt es allgemeingültig jedoch nicht.
Studien belegen den positiven Einfluss von Systems Engineering in Projekten. In Abbildung 3 wird beispielsweise dargestellt, welchen Einfluss SE durch Frontloading auf die Produktentwicklungszeit und das Risikoaufkommen in Projekten haben kann. Mit Systems Engineering verbessern sich in Abhängigkeit von der Projektkomplexität nicht nur zentrale Projektmessgrößen wie Produktqualität, Terminplanungs- und Kostenstabilität, sondern auch Kundenzufriedenheit und das Leistungspotential im Unternehmen selbst. Zur Interpretation der Studien sollte man die eigenen Messgrößen allerdings genau kennen. Welchen Einfluss die Investition in die Analyse von Produktanforderungen auf die Anzahl von späteren Änderungs- und Korrekturmaßnahmen hat, kann nur beurteilt werden, wenn die Änderungskosten z.B. getrackt und zurückverfolgt werden können. In den meisten Fällen liegen diese Daten aber nicht vor. Der Aufwand, die größten Probleme und Kostentreiber im Produktentstehungsprozess zu identifizieren und über unternehmensinterne Experten bewerten und abschätzen zu lassen, ist oft geringer als gedacht und lohnt sich.
Neben messbaren Vorteilen im Entwicklungsprojekt lässt sich in Abhängigkeit vom Produktlebenszyklus der Gesamtnutzen von Systems Engineering erst mittel- bis langfristig feststellen. Das heißt typischerweise mindestens eine Produktgeneration nach dem neuen Standard. Grund dafür ist die Betrachtung des gesamten Produktlebenszyklus. Aufwand, der zu Beginn investiert wurde, rentiert sich messbar gegebenenfalls erst am Ende des Zyklus.

• „Systems Engineering wird oft als sehr theoretisch wahrgenommen.“

Die SE-Normen, -Standards und -Institutionen sind für viele unübersichtlich, wenig griffig und oft nicht so präsent wie andere DIN- oder ISO-Standards.
Selbst die aktiven Systems Engineering Communities haben es trotz internationaler Veranstaltungen, länderspezifischer Chapter, regelmäßiger Veranstaltungen und Veröffentlichungen noch nicht geschafft, daran etwas zu ändern und bleiben trotz steigender Mitgliederzahl größtenteils unter sich.
Auch die Systems Engineering Umsetzung hat teilweise den Ruf, formal und bürokratisch zu sein. Hintergrund sind hier häufig Beispiele aus Projekten mit öffentlichen Auftraggebern, bei denen unzählige Formulare und Stapel von Dokumenten erzeugt werden. Die Luft- und Raumfahrtindustrie ist zum Beispiel eine dieser Branchen. Allerdings wird dort längst fast durchgehend papierlos gearbeitet. Systems Engineering gibt kein Kochrezept vor, wie vielleicht von vielen erwartet und gefordert wird, es bietet vielmehr eine Philosophie und Denkweise mit Methoden und Tools, die in einen spezifischen Kontext gesetzt und interpretiert werden müssen.
Auch das Projektmanagement entwickelte sich in den 40er Jahren als Planungs- und Steuerungsinstrument in der Luft- und Raumfahrtindustrie und wurde bei der Entwicklung der Atlas Rakete und beim B52 Bomber angewandt. Projektmanagement hat sich bei vielen schneller als ein Ansatz zur Problemlösung etabliert, weil es nicht auf die Produktentwicklung fokussiert und es branchenübergreifend und in unterschiedlichsten Anwendungsfällen verwendet und weiterentwickelt werden konnte.

Diese Entwicklung wird es auch im Systems Engineering geben. Allerdings nur unter entsprechenden Voraussetzungen. Denn im Vergleich zum relativ übersichtlichen und greifbaren Projektmanagementstandard, sind die Prozesse und Ergebnisse im Systems Engineering deutlich umfangreicher und spezifischer. Um das zu durchdringen, ist sowohl ein Verständnis der Zusammenhänge innerhalb der Prozesse und Ergebnisse notwendig, als auch ein technisches Verständnis, um den Transfer auf die Anwendung und die Entwicklung des Produkts sicher zu stellen. Deswegen nützt es in der Praxis nichts, wenn Unternehmen ihre Mitarbeiter nur zu Schulungen und Zertifizierungen schicken oder punktuell SE-Ergebnisse einfordern. Hinter den Aktivitäten muss ein Konzept liegen, z.B. welche Qualifikationen notwendig sind, um ausgewählte SE-Abläufe und Ergebnisse erbringen zu können. Oder wie, wo und ab wann die Umsetzung stattfindet und welche konkreten Personen die Eckpfeiler sind. Anderenfalls herrscht schnell Desillusion, wenn Gelerntes nicht umgesetzt werden kann oder die Voraussetzungen generell fehlen. Wie man die passenden Voraussetzungen in einem pragmatischen Ansatz schaffen kann, lesen Sie im nächsten Abschnitt.

SE benötigt einen maßgeschneiderten, pragmatischen und industriellen Ansatz

Ein maßgeschneiderter Anzug zeichnet sich vor allem durch Individualität aus. Das heißt, individuelle Passgenauigkeit, ausgesuchte Materialien, hohe Funktionalität. Der Träger ist mit dem Anzug nicht nur maximal bewegungs- und leistungsfähig, sondern fühlt sich auch noch wohl damit. Systems Engineering muss ebenfalls maßgeschneidert sein, damit sich das Unternehmen damit identifizieren kann und die eingesetzten Methoden Effizienz und Effektivität garantieren. Typische Fails bei der Einführung von SE finden Sie in der Abbildung 4. Sieben pragmatische Punkte sollen Ihnen helfen, diese Fails zu vermeiden und sich auf die wichtigen, wesentlichen Punkte zu konzentrieren, die auf den gesammelten Best Practices etablierter Industrieunternehmen aufbauen.

a) Den SE-Use Case definieren!
Systems Engineering kann nicht alles, deshalb sollte am Beginn genau analysiert werden, was sich das Unternehmen von SE verspricht, warum und wo man es einsetzen will. Systems Engineering betrachtet den gesamten Produktlebenszyklus, deshalb ist auch eine ganzheitliche Analyse notwendig. Welche Herausforderungen bestehen aktuell bzw. zukünftig und welchen Mehrwert bietet SE in diesem Kontext? Wird es durch die Digitalisierung einen höheren Softwareanteil in den Produkten geben, was zusätzliche Iterationen und eine umfangreichere Verifikationsstrategie bedeutet? Oder gibt es durch die Vielzahl der Märkte spezifischere Anforderungen, die strukturierter analysiert werden müssen? Ganzheitlich bedeutet auch den Einbezug der Unternehmensstrategie, von Veränderungen gesetzlicher Rahmenbedingungen und Technologietrends, der Erwartungen der Geschäftsführung und des Anspruchs bestehender bzw. zukünftiger Kunden.

b) Auf Vorhandenem aufbauen!
Unternehmen, die schon viele Jahre Produkte entwickeln, die gewachsen sind und deren Herausforderungen sich durch neue Technologien, Anforderungen und Konkurrenten ändern, besitzen in der Regel bereits Standards, die berücksichtigt werden müssen. Auch wenn diese Standards nicht den Stempel „Systems Engineering“ tragen, wurden sie über die Jahre geschliffen und sind etabliert. Diese Standards müssen nicht neu erfunden werden, sondern sollten vor allem hinsichtlich Redundanzen zu anderen Ergebnissen oder Vollständigkeit im Kontext mit weiteren Entwicklungsarbeitsergebnissen stehen.
Wird bei der SE-Implementierung nicht auf Bewährtem aufgebaut, ist man meistens ineffizient unterwegs und verliert sich im Detail. Außerdem ist eine Evolution von Arbeitsergebnissen für langjährige Wissensträger viel leichter nachzuvollziehen, als eine Revolution, bei der „alte Freunde“ durch „junge Querulanten“ ersetzt werden.

c) Die Unternehmenssprache verwenden!
Gerade Unternehmen, die generell noch wenig mit Systems Engineering zu tun hatten, orientieren sich bei der Einführung stark an einer Referenz in Form einer DIN- oder ISO-Norm. Die Folge daraus ist die Verwendung des Vokabulars aus diesen Normen, in Form einer Mischform der verschiedenen Richtlinien, einer „Englisch/Deutsch Variation“ oder als Akronym. Während ein zertifizierter Systems Engineer die Wichtigkeit des ConOps als zentrales Ergebnis aus der Business- und Missionsanalyse propagiert, fragen sich die Mitarbeiter ohne SE-Erfahrung, was hinter der Abkürzung wohl steht und was sich generell dahinter verbirgt. Die Mitarbeiter mit SE-Basisschulung überlegen dagegen, was nochmal der Unterschied zwischen ConOps und OpsCon war.
Wenn diese Begriffe aus der Norm verwendet werden, ist ein einheitlicher Gebrauch sicherzustellen und ein Abkürzungsverzeichnis bereitzustellen, das für jedermann zugänglich ist. Noch besser ist es allerdings, diese Ergebnisse unternehmensspezifisch oder produktspezifisch zu übersetzen und keine Akronyme zu verwenden. Nur so werden Arbeitsergebnisse konkret.

d) Das gesamte Unternehmen gezielt involvieren!
Auch wenn Systems Engineering impliziert, dass es sich ausschließlich um eine Disziplin aus dem Engineering handelt, ist dem nicht so und es ist von Beginn an darauf zu achten, sämtliche Bereiche in die Aktivitäten zu integrieren. Ziel ist es, dass SE verstanden wird, dass sich die Methodik etabliert und die Mitarbeiter mittelfristig ein Systemdenken aufbauen. Auch wenn die technischen SE-Prozesse hauptsächlich im Verantwortungsbereich des Entwicklungsbereichs liegen, gibt es oft wesentliche Eingangs- und Ausgangsgrößen, deren Erstellung in anderen Bereichen liegt. Der Vertrieb stellt beispielsweise die Schnittstelle zum Kunden dar und ist über das Anforderungsmanagement und die Vertragsgestaltung einer der zentralen Stellhebel für die erfolgreiche Produktentwicklung.

Um einen „Pull“ der Bereiche zu generieren, müssen deren Erwartungen unbedingt in die SE-Bedarfsanalyse einfließen. Für jeden Bereich muss erkennbar werden, wo ihr individueller Mehrwert durch die Anwendung von SE entsteht und wo sie die entscheidenden Beitragsleister sind.

e) Die Rahmenbedingungen ändern!
Qualifizierte und motivierte Mitarbeiter, involvierte Fachbereiche und unternehmensspezifische SE-Arbeitsergebnisse können nur unter bestimmten Voraussetzungen ihre volle Wirkung entfalten. Diese Rahmenbedingungen müssen überlegt geschaffen und konsequent durchgesetzt werden. Die wichtigsten sind Rollen und deren Mandat, die Organisationsstruktur, Abläufe und Mindset.

Die Rolle eines Senior Systems Engineers (SSE) muss über eine Rollenbeschreibung klar definiert sein. Dazu gehören die Aufgaben, die Berichts- und Eskalationswege, der Verantwortungsbereich, die Kompetenzen (das Mandat) und die notwendigen Qualifikationen. Um die Rolle des SSE zu erfüllen, bedarf es gleichzeitig der Erfüllung der Rahmenbedingungen. Oft stellt sich nämlich heraus, dass die notwendigen Strukturen, z.B. das Eskalationsgremium, noch gar nicht besetzt bzw. etabliert sind. Für die Einhaltung von veränderten Strukturen, Gremienlandschaften und Abläufen ist immer noch das Management zuständig. Vorgeben und Vorleben!

f) Leuchtturmprojekte installieren!
Leuchtturmprojekte oder auch Pilotprojekte sind Projekte, die sich durch drei Dinge auszeichnen:

• Sie bieten die Gelegenheit, neue Prozesse, Methodiken, Arbeitsergebnisse, Rollen und Gremien in der Anwendung zu verifizieren und final zu justieren.
• Sie schaffen ein anschauliches, praktisches Beispiel, wie die neuen Abläufe wirklich funktionieren und welche Konsequenzen, Aufgaben und Verantwortlichkeiten daraus für jeden Beteiligten resultieren.
• Ein Leuchtturmprojekt stellt vor allem den Nutzen heraus. Über diese Projekte wird die positive Wirkung der Veränderung transportiert und vor allem kommuniziert. Die Kommunikation des Nutzens ist sowohl auf der Ebene des Projektleiters, als auch aus der Perspektive des einzelnen Projektmitarbeiters notwendig.

Damit Leuchtturmprojekte diesen drei Dingen gerecht werden können, müssen sie gut ausgewählt und geplant werden. Dazu sollte der Stellenwert der Projekte im Portfolio, der aktuelle Projektstatus und die Projektphase betrachtet werden.

g) Dem Unternehmen Zeit geben!
Im Rahmen der Einführung/Implementierung von Systems Engineering entstehen Dokumente. Die Dokumente geben neue Richtlinien vor, beschreiben neue Verfahren, Abläufe und Rollen, die eingehalten werden sollen. Im Rahmen der täglichen Arbeit werden neue oder zusätzliche Ergebnisse eingefordert, für die Templates bereitgestellt werden.
In der Regel bedeutet das für das Management, dass die notwendigen Grundlagen und Strukturen geschaffen sind und SE erfolgreich eingeführt ist. Doch dem ist nicht so. Die SE-Denkweise, die in einem veränderten Handeln mündet und bei dem die definierten Standards weiterentwickelt und verbessert werden, braucht Zeit und Aufmerksamkeit. Eine nachhaltige Verankerung von Systems Engineering muss sichergestellt werden. In der Praxis haben sich dazu folgende Maßnahmen bewährt:

• Center of Competence (CoC): Das CoC ist eine institutionalisierte Einheit, die im Unternehmen umfassend das Systems Engineering repräsentiert. Wie ein CoC in Form eines SE-Offices aussehen kann, lesen Sie in diesem Heft im Fallbeispiel.
• Prozessverantwortliche: Durch Paten, die sich für bestimmte Abläufe und deren Arbeitsergebnisse verantwortlich fühlen, wird sichergestellt, dass Prozesse weiterentwickelt und Änderungen zentral und übergreifend eingesteuert werden können. Wichtig ist, dass sie als Ansprechpartner für den Prozess bekannt sind und Änderungen sowie Lessons Learned gezielt einfließen und strukturiert umgesetzt werden.
• Qualifikationen: Schon während der Definition des maßgeschneiderten SE-Ansatzes ist es essentiell, dass parallel die notwendigen Qualifikationen identifiziert und die passenden Maßnahmen definiert werden. Gerade in den Leuchtturmprojekten erhält man einen guten Indikator, welchen Handlungsbedarf es dazu gibt. Qualifikationsmaßnahmen können über interne und externe Trainings bzw. Zertifizierungen stattfinden und sollten im Qualifikationskatalog für die Mitarbeiter transparent vorliegen. Um sicher zu gehen, dass die Mitarbeiter während der Qualifikation den Unternehmensbezug herstellen können, sind Case-Studies und integrierte Dialoge mit der Geschäftsführung wichtig.

Fazit und Ausblick

Systems Engineering unterstützt mit einem strukturierten Ansatz vom Groben ins Feine und unter Beteiligung aller Stakeholder den gesamten Produktlebenszyklus. Es ist längst nicht mehr ausschließlich ein Standard in der Luft- und Raumfahrt und wird vor allem da angewendet, wo komplexe Produkte entwickelt und in ein Gesamtsystem integriert werden müssen.
Bei der Implementierung von SE bedarf es einer genauen Analyse, welchen Mehrwert Systems Engineering im Unternehmen leisten soll und kann. Außerdem sollte hinter der Implementierung ein einfacher und verständlicher Ansatz liegen, der zum einen die Nachvollziehbarkeit über unternehmenseigene Begriffe und bekannte Standards gewährleistet und zum anderen den Nutzen über Leuchtturmprojekte herausstellt. Unter der konsequenten Einbindung aller Fachbereiche wird SE über ein Center of Competence verankert und die kontinuierliche Weiterentwicklung sichergestellt.

Systems Engineering ist kein „ready-to-use approach“, es stellt vielmehr die Methoden und Werkzeuge bereit, um komplexe Aufgaben und Probleme in der Lösung zu unterstützen. Wie in Abbildung 5 dargestellt, muss der Anspruch SE zu implementieren weiter sein, als der Fokus auf Prozessdefinitionen und einzelne Arbeitsergebnisse. SE-Abläufe müssen maßgeschneidert werden, damit sie in die Abläufe der vorhandenen Geschäftsprozesse passen und den produktspezifischen Anforderungen gerecht werden. Um diese Abläufe zu vertreten und notwendige Arbeitsergebnisse zu erarbeiten, bedarf es definierter Kompetenzen, die über Qualifikationen gezielt und nachhaltig aufgebaut werden müssen. Verbindlichkeit und echte Verankerung entstehen über die Bereitstellung der notwendigen Rahmenbedingungen. Die Organisationsstruktur muss gewährleisten, dass Verantwortlichkeiten, Rollen, Gremien und Meilensteine ein ausreichendes Mandat haben und konsequent eingefordert werden.
Die Betrachtung dieser Dimensionen bedeutet in der Praxis Einschnitte und Veränderungen in allen Unternehmensbereichen. Veränderungen sind für Individuen grundsätzlich nicht immer einfach zu verstehen und zu akzeptieren. Deshalb ist eine gezielte Begleitung der Veränderung durch Kommunikations und Change Management-Maßnahmen unbedingt erforderlich. Dazu gehört die kontinuierliche Einbindung des gesamten Unternehmens und die Information und Kommunikation des Projektverlaufs und der –ergebnisse an die Beteiligten. Informationsveranstaltungen und ein festes Team aus Multiplikatoren, die alle Fachbereiche vertreten, sind dafür adäquate Mittel.
Alle Erfahrungen, die 3DSE in den letzten 15 Jahre branchenübergreifend im Rahmen von Systems Engineering gemacht hat, spiegeln sich in einem SE-Referenzmodell wider. Eingeflossen sind nicht nur Erkenntnisse aus den Key-Branchen Automobil, Luft- und Raumfahrt, Verteidigung und Transport, sondern auch aus Unternehmen der Bereiche Landmaschinen, Haushaltsgeräte, Energie und Elektronik. Die wesentlichen Inhalte und Ausprägungen der SE-Dimensionen sind in einem SE-Referenzmodell abgebildet.
Durch eine kundenspezifische Kalibrierung des Modells kann eine Bewertung gegenüber den definierten Zielzuständen gemacht werden. Daraus abgeleitet werden Potentiale und Handlungsbedarfe für die Umsetzung von Systems Engineering. Über eine Umsetzungsroadmap werden die notwendigen Maßnahmen abgeleitet, unternehmensspezifisch geplant und nachgehalten. Mit SE-Trainings für unterschiedliche Fähigkeitsniveaus, basierend auf Case Studies und Simulationen, baut 3DSE notwendige SE-Kompetenzen im Unternehmen auf.

Das International Council on Systems Engineering (INCOSE) sagt in seiner Vision 2025, dass der Mehrwert von Systems Engineering zukünftig auch verstärkt in den Bereichen kommerzielle Produkte, Dienstleistungen, öffentlicher Dienst und Infrastruktur genutzt werden wird. Das Internet of Things sorgt für eine immer stärkere Vernetzung von Nutzern und Computern, bei der über Devices vom Auto bis zu Haushaltsgeräten alles gesteuert und kontrolliert wird. Daraus folgend wird die Nachfrage an Systems of Systems wachsen, um Informationen und Services entsprechend bereitzustellen.