Abhängig davon, in wie weit sie sich schon einmal mit der Thematik beschäftigt haben, werden sie jetzt wahrscheinlich sagen „Engineering – geht mich nichts an, ich bin Kaufmann“ oder „Ich bin Projektleiter, Ingenieure arbeiten für mich“ oder auch „wir bauen keine Raumschiffe oder Flugzeuge, viel zu kompliziert“. Insbesondere letzte Aussage bekommt man häufig von Leuten, die im Umfeld der Luft- und Raumfahrttechnik oder der Verteidigungstechnik tätig waren. Ein Körnchen Wahrheit ist da sicherlich auch dran, insbesondere wenn wir uns die sehr stark reglementierten Vorgaben der NASA oder des amerikanischen DoD ansehen. Aber man sollte das Kind nicht mit dem Bade ausschütten, es lohnt sich hier ein genauerer Blick hinter die Kulissen. Wenn man sich einmal gedanklich von den Ursprüngen löst, dann erkennt man auf einmal eine ausgesprochen universelle Methodik zur Gestaltung komplexer … sagen wir mal „Dinge“. Das können alle möglichen Sachen sein, wie z.B. Geschäftsprozesse, Unternehmensorganisationen, technische Produkte, Software …. die Liste ist lang und wenn sie am Ende dieses Artikels in einer stillen Minute einmal darüber nachdenken, werden ihnen wahrscheinlich noch viele weitere Beispiele einfallen.

Aber der Reihe nach. Eventuell ist es doch sinnvoll, einmal kurz die Geschichte des System Engineerings zu reflektieren. Es gibt kein spezielles Datum oder Ereignis, das mit dem Entstehen des Systems Engineering (im Folgenden auch SE abgekürzt) in Verbindung steht. Man kann sicherlich sagen, dass erste Ansätze parallel mit dem erstellen komplexerer Strukturen entstanden sind, so gesehen kann man hier sehr weit in die Vergangenheit zurück gehen, wahrscheinlich bis zum Bau der Pyramiden. Als eigenständige Funktion kam das SE bei der Entwicklung komplexer Waffensysteme im zweiten Weltkrieg zum tragen. Zu nennen sind hier beispielsweise die V1 und V2 Programme in Deutschland sowie das Manhattan Projekt zur Entwicklung der  Atombombe in den USA. Hier kamen zum ersten Mal die Probleme komplexer Systeme zum Vorschein: Die Koordination vieler unterschiedlicher fachlicher Disziplinen und der unterschiedlichsten Gewerke. In den 50er und 60er Jahren wurde die Methodik durch die NASA zur Entwicklung Gemini, Apollo und Space Shuttle Programms formalisiert. Höhepunkt war hier sicherlich das Apollo-Programm, in dessen Spitzenzeiten bis zu 400.000 Personen parallel an unterschiedlichsten Stellen an dem gemeinsamen Ziel, der Landung auf dem Mond, gearbeitet haben.

Was sind die besonderen Herausforderungen dieser Projekte? Sie sind

• Komplex mit vielen Schnittstellen
• Interdisziplinär
• Umfangreich
• Häufig unter Verwendung neuer und nicht verifizierter Technologien
• Haben alle ein gemeinsames Ziel, das durch klare Anforderungen festgelegt ist

Wenn wir uns die Liste einmal genau ansehen, dann gilt das für das Space Shuttle genau so wie für die letzte ERP-Einführung, durch die ihr Unternehmen gerade gegangen ist. Lief die gut? Mit hoher Wahrscheinlichkeit nicht. Eventuell hätte es besser laufen können, wenn Sie ein paar von den Ideen des SE im Projekt umgesetzt hätten.

Lösen wir uns also einmal von dem Bild der Raumfahrt und versuchen, das Thema etwas generischer zu betrachten. Was ist ein System? Hier ist es hilfreich, auf die bestehenden Definitionen der einschlägigen Literatur und Richtlinien zurück zu greifen. „Systems Engineering Fundamentals“ des DoD in der Ausgabe vom Januar 2001 sagt zum Beispiel:

„[…] a system is an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.“

Systeme bestehen also aus Menschen (unsere Mitarbeiter), Produkten (das ERP System) und Prozessen (unseren Geschäftsprozessen) und bieten die Fähigkeit, ein gestelltes Ziel zu erfüllen (Geld zu verdienen). Unsere ERP Implementierung, die ich hier als Beispiel nehme, ist also in ihrer Gesamtheit ganz offensichtlich ein System.

Systems Engineering als Aktivität beinhaltet demzufolge alle notwendigen Aktivitäten zur Gestaltung eines Systems. Folgerichtig wäre der korrekte deutsche Begriff auch „Methodik zur Systemgestaltung“, der wahrscheinlich weniger irreführend ist.

In der Literatur finden sich für den Begriff „Systems Engineering“ verschiedene Definitionen:

• A logical sequence of activities and decisions that transforms an operational need into a description of system performance parameters and a preferred system configuration. (MIL-STD-499A, Engineering Management, 1 May 1974. Now cancelled.)
• An interdisciplinary approach that encompasses the entire technical effort, and evolves into and verifies an integrated and life cycle balanced set of system people, products, and process solutions that satisfy customer needs. (EIA Standard IS-632, Systems Engineering, December 1994.)
• An interdisciplinary, collaborative approach that derives, evolves, and verifies a life-cycle bal- anced system solution which satisfies customer expectations and meets public acceptability. (IEEE P1220, Standard for Application and Management of the Systems Engineering Process, [Final Draft], 26 September 1994.)
• Systems Engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem (INCOSE)
• Systems engineering is a methodical, disciplined ap- proach for the design, realization, technical manage- ment, operations, and retirement of a system. (NASA Systems Engineering Handbook, 2007)

… und so weiter, und so fort. Also, in Summe lässt sich sagen: Es ist interdisziplinär, es behandelt den gesamten Lebenszyklus, es ist fokussiert auf Anforderungen, Dokumentation, Synthese und Validierung und erfüllt am Ende den gewünschten Zweck.

Würden Sie nicht auch sagen, dass diese Elemente für eine Vielzahl von unterschiedlichen Projekten gelten und nicht nur für den Bau von Raumschiffen? Und auch wenn es immer wieder Pannen gibt, die Erfolge im Bereich der Luft- und Raumfahrttechnik zeigen, dass die Methodik offensichtlich ausgewachsen ist. Die offene Frage ist nur, welche Methoden für welche Problemstellung relevant sind und welche nicht.

(Wird fortgesetzt)