Ein Systems-Engineering-Plan beschreibt, wie ein Projekt den Systems-Engineering-Ansatz in die Praxis umsetzt. Er legt die Methoden, Prozesse und Verantwortlichkeiten fest, die für die Gestaltung, Analyse und Verifizierung eines Systems gelten. Der Plan ist damit das zentrale Steuerungsmittel für alle, die an der technischen Umsetzung eines Projekts beteiligt sind. In den nachfolgenden Abschnitten beantworten wir die häufigsten Fragen zur Erstellung, Verwaltung und Nutzung eines SE-Plans.
Was steht in einem Systemtechnikplan?
Ein System-Engineering-Plan beschreibt den technischen Ansatz eines Projekts: Welche SE-Prozesse werden angewendet, wie Anforderungen verwaltet werden, wie Verifizierung und Validierung gestaltet sind und wer dafür verantwortlich ist. Der Plan dient als technischer Kompass für das Projektteam und bietet Orientierung bei Entscheidungen über Design, Rückverfolgbarkeit und Systemintegration.
In der Praxis enthält ein SE-Plan normalerweise die folgenden Bestandteile:
- Umfang und Systembeschreibung: was fällt in das zu erarbeitende System und was nicht
- Eisenmanagement wie Anforderungen festgehalten, verwaltet und geändert werden
- Verifizierungs- und Validierungsstrategie Welche Methoden werden genutzt, um zu beweisen, dass das System konform ist
- Rückverfolgbarkeitsansatz wie die Beziehung von Anforderung zu Entwurf zu Nachweis verfolgt wird
- Rollen und Verantwortlichkeiten: wie welche SE-Aktivitäten ausführt
- Verwendete Frameworks und Standards wie die SE-Leitlinie oder die INCOSE-Richtlinien
- Werkzeug- und Dokumentationsstruktur: welche Mittel das Team für Modellierung und Registrierung verwendet
Wie umfangreich der Plan ist, hängt vom Projektumfang und den Anforderungen des Auftraggebers ab. Bei größeren Infrastrukturprojekten oder Ausschreibungen im öffentlichen Sektor ist ein detaillierter SE-Plan oft vertraglich vorgeschrieben.
Wanneer wordt een systeemtechnisch plan opgesteld?
Ein Systems-Engineering-Plan wird zu Beginn eines Projekts erstellt, vorzugsweise in der Initiations- oder Erkundungsphase, bevor die technische Ausarbeitung beginnt. Zu diesem Zeitpunkt sind die Rahmenbedingungen des Projekts bekannt, die Ausführung hat aber noch nicht begonnen, was den idealen Zeitpunkt darstellt, um den SE-Ansatz festzulegen und mit allen Beteiligten abzustimmen.
In der Praxis gibt es drei Zeitpunkte, zu denen die Erstellung eines SE-Plans besonders wertvoll ist:
- Beim Start eines Projekts: damit das gesamte Team von Anfang an die gleiche Vorgehensweise anwendet
- Bei einer Ausschreibung oder Vergabe: Auftraggeber im Infrastruktur- und Bausektor verlangen zunehmend einen SE-Plan als Teil des Angebots.
- Bei einer signifikanten Änderung des Projektumfangs oder der Projektorganisation: ein bestehender Plan muss dann überarbeitet werden, um aktuell zu bleiben
Warten Sie nicht, bis das Projekt bereits in vollem Gange ist. Ein SE-Plan, der nachträglich erstellt wird, beschreibt dann oft die bereits entstandene Realität, anstatt die Arbeitsweise zu steuern. Das reduziert seinen Wert erheblich.
Wer ist verantwortlich für das Schreiben eines SE-Plans?
Die Verantwortung für das Schreiben eines Systems-Engineering-Plans liegt beim leitenden Systemingenieur oder dem SE-Manager des Projekts. Diese Person verfügt über das technische und methodische Wissen zur Definition des SE-Ansatzes und kann diesen Ansatz sowohl mit dem Projektmanager als auch mit dem Auftraggeber abstimmen.
In kleineren Projektteams ist der Verfasser des SE-Plans oft dieselbe Person, die ihn auch umsetzt. In grösseren Programmen gibt es manchmal einen separaten SE-Koordinator oder eine Systems-Engineering-Abteilung, die den Plan erstellt und überwacht. Was in beiden Fällen wesentlich ist: Der Inhalt des Plans muss vom gesamten technischen Team getragen werden, nicht nur von der Person, die ihn geschrieben hat.
Es ist daher ratsam, den SE-Plan nicht isoliert zu schreiben. Beziehen Sie die relevanten Disziplinen, den Projektmanager und gegebenenfalls den Auftraggeber in die Erstellung mit ein. So erhöhen Sie die Wahrscheinlichkeit, dass der Plan in der Praxis auch tatsächlich befolgt wird.
Was ist der Unterschied zwischen einem SE-Plan und einem Projektplan?
Der Unterschied zwischen einem System-Engineering-Plan und einem Projektplan liegt im Fokus: Ein Projektplan konzentriert sich auf die Planung, das Budget, das Risiko und die Organisation des Projekts als Ganzes, während ein SE-Plan ausschließlich den technischen Ansatz beschreibt. Beide Dokumente ergänzen sich, sind aber nicht austauschbar.
Was regelt ein Projektplan?
Ein Projektplan beschreibt die Managementaspekte eines Projekts: Wer macht was, wann, mit welchem Budget und welche Risiken werden erkannt. Er richtet sich an den Projektmanager und den Auftraggeber und bietet einen Überblick über Meilensteine, Ergebnisse und die Projektorganisation. Technische Inhalte bleiben hier bewusst außen vor.
Was regelt ein SE-Plan?
Ein SE-Plan geht tiefer auf die technische Umsetzung ein: wie werden Anforderungen strukturiert, wie verläuft die Systemzerlegung, welche Verifikationsmethoden werden angewendet und wie wird die Rückverfolgbarkeit sichergestellt. Er ist primär für das technische Team und die Systemingenieure bestimmt, die täglich mit dem System arbeiten.
In der Praxis bezieht sich ein Projektplan manchmal auf den SE-Plan als Anhang oder als separates Steuerungsdokument. Die beiden Dokumente existieren nebeneinander und werden idealerweise gleichzeitig erstellt, so dass der technische Ansatz und die Projektsteuerung aufeinander abgestimmt sind.
Wie hält man einen Systems-Engineering-Plan während eines Projekts auf dem neuesten Stand?
Sie halten einen Systems-Engineering-Plan aktuell, indem Sie ihn als ein lebendes Dokument behandeln, das sich mit dem Fortschritt des Projekts weiterentwickelt. Legen Sie zu Beginn eine Revisionsstrategie fest, koppeln Sie Überarbeitungen an Meilensteine oder Phasenübergänge und benennen Sie ausdrücklich eine Person, die für die Pflege des Plans verantwortlich ist.
In der Praxis veralten SE-Pläne schnell, wenn es keine Struktur für die Wartung gibt. Projektumfänge ändern sich, Teams wechseln ihre Zusammensetzung und Anforderungen entwickeln sich weiter. Ohne ein aktuelles SE-Plan verliert das Dokument seine steuernde Funktion wird zu einer Formalität, die niemand mehr konsultiert.
Praktische Maßnahmen, um einen SE-Plan aktuell zu halten:
- Koppel revisies aan vaste momenten: bei Phasengrenzen, Vertragsänderungen oder signifikanten Umfangsänderungen
- Machen Sie den Plan zu einem Teil der Projektprüfung. Besprechen Sie während Fortschrittstreffen, ob der beschriebene Ansatz noch mit der Realität übereinstimmt
- Nutzen Sie eine zentrale, zugängliche Umgebung Ein in einer gemeinsamen Umgebung befindlicher Plan ist einfacher zu pflegen als ein Word-Dokument auf der Festplatte von jemandem.
- Besitzer zuweisen eine Person, die Änderungen verfolgt, Versionen verwaltet und signalisiert, wenn eine Überarbeitung erforderlich ist
Datastorms ondersteunt dit proces door eisen, verificaties en traceability centraal en gestructureerd bij te houden, zodat de feitelijke projectwerkelijkheid altijd inzichtelijk is. Dat maakt het bijhouden van een SE-plan aanzienlijk minder arbeidsintensief dan wanneer alles in losse bestanden leeft. Wil je weten hoe dit er in de praktijk uitziet voor jouw project? Bekijk dan de mogelijkheden voor een proeflicentie en ontdek zelf hoe gestructureerd eisenbeheer het verschil maakt.
Häufig gestellte Fragen
Wie umfassend muss ein Systems-Engineering-Plan für ein kleines Projekt sein?
Für kleinere Projekte muss ein SE-Plan nicht Dutzende von Seiten umfassen. Ein prägnantes Dokument von fünf bis zehn Seiten, das die Kernkomponenten abdeckt – den Umfang, das Anforderungsmanagement, die Verifikationsstrategie und die Rollen – ist oft ausreichend. Wichtig ist, dass der Plan nutzbar und akzeptiert ist, nicht dass er beeindruckend aussieht. Passen Sie die Tiefe an die Komplexität und das Risikoprofil des Projekts an.
Welke veelgemaakte fouten moet ik vermijden bij het opstellen van een SE-plan?
Der häufigste Fehler ist es, einen SE-Plan als eine Papierübung zu schreiben: ein Dokument, das für den Auftraggeber geliefert wird, aber nie wirklich vom Team genutzt wird. Andere Fallstricke sind eine zu allgemeine Beschreibung ohne projektspezifische Entscheidungen, die Nicht-Einbeziehung der ausführenden Fachdisziplinen und das Fehlen eines Verantwortlichen für Verwaltung und Wartung. Ein SE-Plan hat nur dann Wert, wenn er die tägliche Arbeitsweise steuert.
Moet ik een specifieke standaard of framework volgen bij het schrijven van een SE-plan?
Es gibt keine universelle Verpflichtung, aber in der niederländischen Infrastruktur- und Bauindustrie wird der Leitfaden Systems Engineering von ProRail/Rijkswaterstaat häufig als Referenz verwendet. International bietet das INCOSE Systems Engineering Handbook einen weithin akzeptierten Rahmen. Welchen Rahmen Sie wählen, hängt von der Branche, dem Auftraggeber und der Projektkomplexität ab. Überprüfen Sie bei Ausschreibungen immer, ob der Auftraggeber einen bestimmten Standard vorschreibt.
Wie stelle ich sicher, dass der SE-Plan tatsächlich vom Team befolgt wird?
Einbindung beginnt bereits während des Schreibprozesses: Lassen Sie die Disziplinen, die den Plan umsetzen sollen, über den Inhalt mitdenken. Stellen Sie danach sicher, dass der Plan leicht zugänglich ist, besprechen Sie ihn explizit bei der Einarbeitung neuer Teammitglieder und machen Sie die beschriebene Vorgehensweise zu einem Teil wiederkehrender Projektüberprüfungen. Ein Plan, den Teammitglieder als ihre eigene Vorgehensweise erkennen, wird automatisch befolgt – ein Plan, der von oben auferlegt wird, verschwindet schnell in einer Schublade.
Welche Werkzeuge eignen sich zur Verwaltung eines SE-Plans und der zugehörigen Anforderungen?
Die Wahl der Werkzeuge hängt vom Projektumfang und der Komplexität der Anforderungsstruktur ab. Für einfache Projekte kann ein gemeinsames Dokument auf einer Kollaborationsplattform wie SharePoint oder Confluence bereits ausreichen. Für Projekte mit einem umfangreichen Anforderungssatz, Rückverfolgbarkeitsanforderungen und mehreren Verifizierungszeitpunkten sind spezialisierte Plattformen wie Datastorms, IBM DOORS oder Jama Connect besser geeignet. Stellen Sie in jedem Fall sicher, dass Werkzeuge und Dokumentationsstruktur im SE-Plan festgelegt sind, damit das gesamte Team auf die gleiche Weise arbeitet.
Was mache ich, wenn sich der Projektumfang mitten im Projekt grundlegend ändert — muss ich dann einen völlig neuen SE-Plan schreiben?
Nicht per se. In den meisten Fällen reicht eine gezielte Überarbeitung der betreffenden Teile, wie die Systembeschreibung, die Anforderungsstruktur oder die Verifikationsstrategie. Dokumentieren Sie die Änderung mit einer Versionsnummer und einer kurzen Erklärung, was sich geändert hat und warum. Ein völlig neuer Plan ist nur notwendig, wenn sich der Umfang so grundlegend verschiebt, dass der ursprüngliche technische Ansatz nicht mehr anwendbar ist.
Kann ein SE-Plan auch bei agilen oder iterativen Projektansätzen eingesetzt werden?
Ja, ein SE-Plan ist auch in agilen oder iterativen Kontexten wertvoll, auch wenn er eine andere Ausgestaltung erfordert. Anstatt eines vollständig ausgearbeiteten Plans zu Beginn, werden die Rahmenbedingungen und Prinzipien festgelegt, die pro Iteration angewendet werden, wie z. B. wie Anforderungen priorisiert werden, wie die Verifizierung pro Sprint organisiert ist und wie die Rückverfolgbarkeit nachverfolgt wird. Der Plan wächst dann mit dem Projekt mit und wird nach jeder Phase oder jedem Sprint auf der Grundlage der gewonnenen Erkenntnisse aktualisiert.