Ein Systems-Engineering-Plan beschreibt, wie Systems Engineering in einem Projekt oder Programm durchgeführt wird. Das Dokument legt fest, welche Methoden, Prozesse, Rollen und Werkzeuge eingesetzt werden, um Anforderungen zu verwalten, Systeme zu entwerfen und die Verifizierung nachweisbar zu machen. Der SE-Plan ist somit das Fundament jeder strukturierten, nachvollziehbaren Vorgehensweise in komplexen Projektumgebungen. In diesem Artikel beantworten wir die am häufigsten gestellten Fragen zu Inhalt, Aufbau und Nutzung eines Systems-Engineering-Plans.
Welche Bestandteile muss ein Systems-Engineering-Plan beinhalten?
Ein Systems-Engineering-Plan enthält mindestens eine Beschreibung des SE-Ansatzes, die angewandten Methoden und Prozesse, die Rollen und Verantwortlichkeiten innerhalb des Teams, die verwendeten Werkzeuge sowie die Art und Weise, wie Anforderungen, Verifizierung und Rückverfolgbarkeit verwaltet werden. Zusammen bilden diese Komponenten einen praktikablen Rahmen für die Umsetzung von Systems Engineering während des gesamten Projektlebenszyklus.
In der Praxis sind die meisten SE-Pläne rund um einige feste Themen aufgebaut:
- Umfang und Zielsetzung: Was ist das System, das entwickelt wird, und was sind die Grenzen des SE-Ansatzes?
- Eisenmanagement Wie werden Anforderungen formuliert, verwaltet und geändert? Welche Ebenen der Anforderungszerlegung werden verwendet?
- Rückverfolgbarkeit Auf welche Weise wird die Beziehung zwischen Anforderungen, Design und Verifizierung verfolgt?
- Verifizierung und Validierung: Welche Verifizierungsmethoden werden eingesetzt (Inspektion, Prüfung, Analyse, Demonstration) und wer ist dafür verantwortlich?
- Rollen und Verantwortlichkeiten: Wer macht was innerhalb des SE-Teams und wie verhält sich das zur breiteren Projektorganisation?
- Schnittstellen und Abhängigkeiten Wie werden Beziehungen zu anderen Systemen, Disziplinen oder Parteien verwaltet?
- Werkzeug und Dokumentenverwaltung Welche Werkzeuge und Vorlagen werden verwendet, und wie werden Informationen gespeichert und geteilt?
Frameworks wie INCOSE und die niederländische Leitfaden SE bieten eine gute Basis für die Struktur eines SE Plans. Es ist jedoch kein Ausfüllformular — ein guter SE Plan ist immer auf den spezifischen Kontext des Projekts abgestimmt.
Wie unterscheidet sich ein System-Engineering-Plan von einem Projektplan?
Ein Systems-Engineering-Plan konzentriert sich spezifisch auf den technisch-inhaltlichen Ansatz: Wie werden Anforderungen verwaltet, wie wird das System entworfen und wie wird die Verifizierung organisiert? Ein Projektplan befasst sich mit den Managementaspekten: Planung, Budget, Risiko und Kommunikation. Die beiden Dokumente ergänzen sich, haben aber eine klare Unterscheidung in Fokus und Zielgruppe.
Der Projektplan ist das Gebiet des Projektmanagers. Der SE-Plan ist das Gebiet des Systemingenieurs. In der Praxis gibt es Überschneidungen – beide Dokumente berühren Risiken, den Umfang und Rollen – aber die Fragestellung ist fundamental anders.
Ein Projektplan beantwortet Fragen wie: Wann wird etwas geliefert, wer ist für welche Aktivität verantwortlich und wie wird das Budget überwacht? Der SE-Plan beantwortet Fragen wie: Woher wissen wir sicher, dass das System die gestellten Anforderungen erfüllt, wie verfolgen wir die Rückverfolgbarkeit und wie gehen wir mit Änderungen am Entwurf um?
In größeren Programmen sind beide Dokumente formal getrennt. In kleineren Projekten werden sie manchmal kombiniert oder vereinfacht, aber auch dann ist es sinnvoll, den SE-Ansatz explizit zu beschreiben – und sei es nur als separat Kapitel innerhalb des Projektplans.
Wer ist verantwortlich für die Ausarbeitung eines SE-Plans?
Der Systemingenieur ist primär für die Erstellung des Systems-Engineering-Plans verantwortlich. Bei größeren Projekten ist dies der leitende Systemingenieur oder der SE-Manager. Sie stellen sicher, dass der Plan mit der Projektstruktur, den vertraglichen Anforderungen des Auftraggebers und der angewandten SE-Methodik übereinstimmt.
Die Erstellung eines SE-Plans ist selten eine Solistenaufgabe. Der Systemingenieur stimmt sich mit dem Projektmanager über Planung und Umfang ab, mit den technischen Spezialisten über die gewählten Verifikationsmethoden und manchmal auch mit dem Auftraggeber, wenn der Plan Teil vertraglicher Verpflichtungen ist.
Im öffentlichen Sektor und bei großen Infrastrukturprojekten ist der SE-Plan oft ein formal abzulieferndes Dokument. Auftraggeber wie Rijkswaterstaat oder ProRail stellen Anforderungen an Inhalt und Struktur. In diesen Fällen ist der SE-Plan nicht nur ein internes Arbeitsdokument, sondern auch ein Rechenschaftsinstrument nach außen.
Bij kleinere organisaties of projecten zonder toegewijde SE-rol ligt de verantwoordelijkheid vaak bij de technisch projectleider of de senior ingenieur. Juist in die situaties is het belangrijk dat het SE-plan praktisch en beheersbaar blijft — een te zwaar document dat niemand bijhoudt, werkt averechts.
Ein System-Engineering-Plan wird erstellt, wenn
Ein Systems-Engineering-Plan wird vorzugsweise zu Beginn der Definitionsphase erstellt, bevor die eigentliche Systementwicklung beginnt. Zu diesem Zeitpunkt sind die Projektgrenzen bekannt, aber es gibt noch Spielraum, um den SE-Ansatz richtig zu gestalten. Ein früher Beginn verhindert, dass Prozesse ad hoc eingerichtet werden und später schwer zu steuern sind.
In der Praxis hängt der Zeitpunkt von der Projektphase und der Vertragsart ab. Bei einem DBFM-Vertrag oder einem integrierten Vertrag beginnt der SE-Ansatz bereits in der Ausschreibungsphase, da der Auftragnehmer für die Auslegung verantwortlich ist. In diesem Fall wird der SE-Plan frühzeitig als Teil des Angebots oder der Vertragsverhandlungen erstellt.
Der SE-Plan ist kein statisches Dokument. Er wird während des Projekts aktualisiert, wenn sich der Umfang ändert, neue Anforderungen hinzugefügt werden oder sich die Projektorganisation ändert. Ein SE-Plan, der nach der Definitionsphase nie wieder angefasst wird, verliert schnell seinen Wert als Steuerungsinstrument.
Welche Werkzeuge werden benutzt, um einen SE-Plan zu verfolgen?
In der Praxis werden SE-Pläne mit unterschiedlichen Werkzeugen gepflegt: von Word-Dokumenten und Excel-Tabellen bis hin zu spezialisierten MBSE-Plattformen. Die Wahl hängt von der Komplexität des Projekts, dem Budget und der Reife des SE-Ansatzes innerhalb der Organisation ab. Viele Teams beginnen mit einfachen Werkzeugen und stoßen früher oder später an die Grenzen von einzelnen Dateien.
De meest gebruikelijke aanpak in kleinere organisaties is een combinatie van Word voor het SE-plan zelf, Excel voor eisenregistratie en verificatiematrices, en SharePoint of een vergelijkbaar platform voor documentbeheer. Deze aanpak werkt, maar heeft een duidelijk nadeel: traceerbaarheid is handmatig, versies raken versnipperd en bij projectwisselingen gaat kennis verloren.
Gespecialiseerde MBSE-tools zoals DOORS of Cameo bieden meer structuur en traceerbaarheid, maar zijn complex in gebruik en hebben een hoge instapdrempel — zowel qua kosten als qua leercurve. Voor veel teams is dit geen realistisch alternatief.
Wir entwickelten Datastorms als zugängliche Alternative: eine No-Code-Informationsplattform, mit der Systemingenieure Eisen, Rückverfolgbarkeit und Verifizierung Zentral verwalten in einer Umgebung. Die Plattform passt sich der spezifischen Projektstruktur an, fügt sich in bestehende Arbeitsabläufe ein und integriert über eine umfassende API mit bereits genutzten Werkzeugen. So muss ein Team nicht zwischen Einfachheit und Struktur wählen.
Die wichtigsten Kriterien bei der Wahl von Werkzeugen für einen SE-Plan sind: Unterstützung für Nachverfolgbarkeit, die Möglichkeit, Anforderungen und den Überprüfungsstatus zu verfolgen, und ein Prozess, den das Team tatsächlich durchhält. Ein fortschrittliches Werkzeug, das niemand benutzt, ist weniger wert als ein einfacher Ansatz, der konsequent gepflegt wird.
Häufig gestellte Fragen
Wie detailliert muss ein Systemtechnikplan sein?
Der Detaillierungsgrad hängt von der Komplexität des Projekts, den vertraglichen Anforderungen und der Reife des SE-Teams ab. Ein zu detaillierter Plan, den niemand liest oder pflegt, wirkt sich negativ aus – ein zu allgemeiner Plan bietet nicht genügend Halt bei Konflikten oder Änderungen. Eine gute Faustregel: Beschreiben Sie Prozesse detailliert genug, damit ein neues Teammitglied versteht, wie das Projekt aufgebaut ist, aber halten Sie ihn überschaubar genug, um ihn tatsächlich aktuell zu halten.
Was sind die häufigsten Fehler beim Erstellen eines SE-Plans?
De meest gemaakte fout is het opstellen van een SE plan als eenmalig document dat na oplevering in een la verdwijnt. Andere veelvoorkomende valkuilen zijn: te weinig afstemming met de projectmanager over scope en planning, onvoldoende beschrijving van hoe traceability in de praktijk wordt bijgehouden, en het kopiëren van een template zonder aanpassing aan de projectcontext. Een SE plan dat niet leeft, stuurt niet — en dat is precies het doel van het document.
Wie stelle ich sicher, dass der SE-Plan tatsächlich vom Team genutzt wird?
Machen Sie den SE-Plan so konkret und praktisch wie möglich: Beschreiben Sie nicht nur, was getan werden muss, sondern auch wie und von wem. Verknüpfen Sie den Plan mit der täglichen Arbeitspraxis, indem Sie ihn in Überprüfungsmomente, Designentscheidungen und Verifizierungsaktivitäten integrieren. Teams, die den SE-Plan als Arbeitsinstrument und nicht als Rechenschaftsdokument betrachten, halten ihn eher aktuell und relevant.
Moet een SE plan worden goedgekeurd door de opdrachtgever?
Das hängt vom Vertrag und dem Sektor ab. Bei großen Infrastrukturprojekten oder öffentlichen Projekten ist der SE-Plan oft ein formell abzulieferndes Dokument, das die Genehmigung des Auftraggebers erfordert – denken Sie an Projekte für Rijkswaterstaat oder ProRail. Bei kommerziellen oder internen Projekten ist eine formelle Genehmigung weniger üblich, aber es ist immer sinnvoll, den Plan mit dem Auftraggeber zu teilen, damit die Erwartungen an den SE-Ansatz explizit festgehalten sind.
Wie gehe ich mit Änderungen im Projekt um, die den SE-Plan betreffen?
Betrachten Sie den SE-Plan als ein lebendes Dokument mit eigenem Versions- und Änderungsmanagement. Legen Sie im Voraus fest, welche Arten von Änderungen eine Aktualisierung des SE-Plans erfordern – wie z. B. Scope-Änderungen, neue Anforderungsniveaus oder Änderungen in der Projektorganisation – und wer dafür verantwortlich ist. Ein kurzer Überprüfungszyklus pro Projektphase oder bei einem formellen Entscheidungsmoment ist eine effektive Möglichkeit, den Plan aktuell zu halten, ohne dass er zu einem administrativen Aufwand wird.
Ist ein SE-Plan auch für kleinere Projekte sinnvoll?
Ja, auch für kleinere Projekte ist ein SE-Plan wertvoll — er muss dann aber kein aufwendiges formelles Dokument sein. Selbst eine kurze Beschreibung, wie Anforderungen gehandhabt werden, wer für die Verifizierung zuständig ist und welche Werkzeuge verwendet werden, vermeidet Missverständnisse und sorgt für einen nachvollziehbaren Ansatz. Ein leichtgewichtiger SE-Plan von wenigen Seiten reicht für viele kleine Projekte bereits aus, um Struktur zu bieten, ohne unnötigen Overhead.
Welche Standards oder Richtlinien kann ich als Grundlage für meinen SE-Plan verwenden?
Der am häufigsten verwendete internationale Standard ist das INCOSE Systems Engineering Handbuch, das einen umfassenden Rahmen für die Struktur und den Inhalt eines SE-Plans bietet. In den Niederlanden ist die Leidfaden Systems Engineering – entwickelt vom Rijkswaterstaat-Netzwerk – eine häufig verwendete Referenz, insbesondere bei Infrastrukturprojekten. Darüber hinaus bietet der Standard ISO/IEC/IEEE 15288 einen formellen Prozessrahmen. Verwenden Sie diese Standards als Ausgangspunkt, passen Sie die Struktur jedoch immer an den spezifischen Kontext und die Anforderungen Ihres Projekts an.