Der Systems-Engineer oder SE-Koordinator des ausführenden Projektteams erstellt in der Regel den Systems-Engineering-Plan. Diese Person übersetzt die Projektanforderungen, den gewählten SE-Ansatz und die Vereinbarungen mit dem Auftraggeber in ein praktikables Dokument, das dem gesamten Team Orientierung gibt. Die Verantwortung liegt somit primär beim Auftragnehmer, aber der Auftraggeber spielt eine unverzichtbare Rolle bei der Festlegung und Prüfung. In diesem Artikel beantworten wir die am häufigsten gestellten Fragen zum Eigentum, zur Genehmigung und zur Wartung des Systems-Engineering-Plans.
Wer erstellt in der Regel den System-Engineering-Plan?
Der Systems-Engineering-Plan wird in der Regel vom Systemsingenieur oder SE-Koordinator auf der Seite des Auftragnehmers erstellt. Diese Person verfügt über das technische und methodische Wissen, um den SE-Ansatz zu beschreiben, die Verifikationsstrategie festzulegen und die Rollen innerhalb des Projekts zu definieren. Bei größeren Projekten kann diese Aufgabe von einem SE-Manager oder Lead-Ingenieur übernommen werden, der vom Projektteam unterstützt wird.
Der Verfasser erarbeitet den Plan auf der Grundlage der vertraglichen Anforderungen, der geltenden SE-Standards wie dem SE-Leitfaden oder den INCOSE-Richtlinien und der spezifischen Merkmale des Projekts. Es handelt sich nicht um ein generisches Dokument, das einmal ausgefüllt wird, sondern um einen lebendigen Plan, der den tatsächlichen Ansatz beschreibt. Dies erfordert inhaltliches Engagement von jemandem, der das Projekt und die Methodik gut kennt.
In de praktijk zien we dat het opstellen van het SE-plan regelmatig belandt bij iemand die er naast zijn andere taken weinig tijd voor heeft. Het resultaat is dan een document dat meer op papier klopt dan dat het de dagelijkse werkwijze stuurt. Juist daarom loont het om het opstellen serieus te beleggen bij een aangewezen eigenaar met voldoende mandaat en tijd. Wil je weten hoe Datastorms teams hierbij ondersteunt? Bekijk dan wat ons platform voor jouw project kan betekenen.
Was ist der Unterschied zwischen entwerfen und genehmigen?
Erstellen bedeutet die inhaltliche Ausarbeitung des Systems-Engineering-Plans: des Ansatzes, der Methoden, der Rollen und der Vereinbarungen. Genehmigen bedeutet, formell die Zustimmung zu diesem Plan zu erteilen, womit die genehmigende Partei bestätigt, dass der Plan den gestellten Anforderungen und der vereinbarten Arbeitsweise entspricht. Erstellen ist eine inhaltliche Aufgabe; genehmigen ist eine formelle Verantwortung.
In den meisten Projekten erstellt der Auftragnehmer den Plan und der Auftraggeber genehmigt ihn. Die Genehmigung ist keine reine Formalität. Mit der Billigung des Plans verpflichtet sich der Auftraggeber zu dem beschriebenen Ansatz und erklärt, dass die gewählte SE-Methodik den Projektzielen entspricht. Ein Plan, der ohne inhaltliche Prüfung genehmigt wird, bietet später wenig Halt bei Diskussionen über Umfang, Verifizierung oder Übergabe.
Neben dem Auftraggeber können auch ein interner Qualitätsmanager, ein SE-Review-Board oder ein unabhängiger Prüfer an der Genehmigung beteiligt sein. Bei komplexen Infrastrukturprojekten oder öffentlichen Ausschreibungen sind mehrere Genehmigungsebenen üblich. Es ist ratsam, im Plan selbst festzulegen, wer welche Genehmigung erteilt und zu welchem Zeitpunkt im Projekt.
Welche Rolle hat der Auftraggeber im SE-Plan?
Der Auftraggeber hat eine dreiteilige Rolle im Systems Engineering Plan: Er setzt die Rahmenbedingungen, prüft den Plan auf Konformität mit den vertraglichen Anforderungen und genehmigt ihn formell. Darüber hinaus kann der Auftraggeber spezifische SE-Anforderungen vorschreiben, wie z. B. die Verwendung bestimmter Verifikationsmethoden, Berichtsformate oder Rückverfolgbarkeitsanforderungen, die der Auftragnehmer verarbeiten muss.
Bei einigen Projekten geht die Einbeziehung des Auftraggebers weiter. Er beteiligt sich dann aktiv an SE-Reviews, beurteilt Verifizierungsberichte oder nimmt an Systemabnahmetests teil. Dies ist insbesondere bei öffentlichen Projekten oder großen Infrastrukturaufgaben der Fall, bei denen der Auftraggeber selbst ebenfalls über SE-Kompetenzen verfügt.
Ein häufiger Fehler ist, dass der Auftraggeber den SE-Plan als ein vertraglich abzuhakendes Dokument behandelt. Das untergräbt dessen Wert. Ein Auftraggeber, der inhaltlich an der Erstellung des Plans beteiligt ist, erhöht die Chance, dass der Plan tatsächlich den Projektzielen entspricht und später als Steuerungsinstrument statt als Schreibtischschubladen-Dokument genutzt wird.
Wie wird Verantwortung bei fehlender SE-Expertise zugewiesen?
Da SE-Expertise im Projektteam fehlt, wird die Verantwortung für den Systems Engineering Plan oft vorübergehend einem externen SE-Berater oder einem beauftragten Spezialisten übertragen. Eine andere Option ist, die Verantwortung auf den Projektmanager oder Lead Engineer zu legen, ergänzt durch Anleitung von einem SE-Wissenspartner oder über eine Plattform, die die Methodik unterstützt.
Fehlende SE-Expertise ist ein reales Problem in vielen Organisationen. Nicht jedes Unternehmen beschäftigt einen Vollzeit-Systems-Engineer, aber das bedeutet nicht, dass SE-Prinzipien ignoriert werden müssen. In der Praxis gibt es drei gängige Lösungen:
- Externe Anstellung: Ein SE-Berater oder Freiberufler erstellt den Plan und begleitet die Implementierung. Dies ist effektiv, kann aber bei langwierigen Projekten kostspielig sein.
- Interne Hochskalierung Ein erfahrener Projektmitarbeiter wird in SE-Methoden geschult und übernimmt die Rolle, idealerweise mit Coaching durch einen erfahrenen SE-Experten.
- Werkzeugunterstützung: Een platform dat SE-structuren en templates biedt, verlaagt de drempel voor mensen zonder diepgaande SE-achtergrond. Met een proeflicentie van Datastorms kunnen teams eisendecompositie, traceability en verificatie inrichten in een no-code omgeving, zonder dat ze SE-expert hoeven te zijn.
Welcher Ansatz am besten geeignet ist, hängt vom Projektumfang, dem verfügbaren Budget und der Projektdauer ab. Bei kurzfristigen Projekten ist externe Anstellung oft pragmatisch. Bei Programmen mit mehreren Teilprojekten lohnt es sich, in strukturelle Tool-Unterstützung und internen Wissensaufbau zu investieren.
Wann muss der Systementwicklungsplan überarbeitet werden?
Der Systems-Engineering-Plan muss überarbeitet werden, wenn wesentliche Änderungen am Projektumfang, den Systemanforderungen, der Organisationsstruktur oder dem gewählten SE-Ansatz vorgenommen werden. Darüber hinaus ist eine Überarbeitung bei vordefinierten Meilensteinen erforderlich, z. B. nach einer Systemprüfung oder beim Übergang in eine neue Projektphase.
Ein SE-Plan ist kein statisches Dokument. Er beschreibt, wie das Projekt den SE-Ansatz umsetzt, und wenn sich die Realität ändert, muss sich der Plan mit ändern. Typische Zeitpunkte für eine Überarbeitung sind:
- Auswirkungsänderungen: Wenn sich die Systemgrenzen oder der Anforderungsdatensatz maßgeblich ändern, müssen die Verifizierungsstrategie und der beschriebene Ansatz angepasst werden.
- Organisationsänderungen: Veränderungen im Projektteam, neue Stakeholder oder eine geänderte Verantwortungsstruktur erfordern eine Aktualisierung der Rollen- und Aufgabenverteilung im Plan.
- Phasenübergänge: Beim Übergang von der Planung zur Realisierung oder von der Realisierung zur Abnahme ändern sich die SE-Aktivitäten. Der Plan muss diese neue Phase angemessen beschreiben.
- Vertragliche Verpflichtungen Wenn der Auftraggeber eine periodische Überprüfung vorgeschrieben hat, ist dies eine zwingende Verpflichtung, die nicht umgangen werden darf.
In der Praxis wird die Überarbeitung des SE-Plans zu oft aufgeschoben oder vergessen. Das führt dazu, dass der Plan die Realität nicht mehr widerspiegelt und seinen Steuerwert verliert. Durch die Verwaltung des Plans in einer zentralen Plattform, wie wir sie anbieten, bleibt die aktuelle Version immer verfügbar und Änderungen sind nachvollziehbar. So bleibt der Systems-Engineering-Plan ein lebendiges Instrument anstelle einer vergessenen Anlage.
Häufig gestellte Fragen
Muss jedes Projekt, unabhängig von seiner Größe, einen vollständig ausgearbeiteten System-Engineering-Plan haben?
Nicht jedes Projekt erfordert einen ebenso umfangreichen SE-Plan. Bei kleineren oder weniger komplexen Projekten kann ein prägnanter SE-Ansatz oder ein vereinfachter Plan, der die Kernvereinbarungen festhält, ausreichen. Die vertraglichen Anforderungen des Auftraggebers und die geltenden Standards bestimmen letztendlich den Mindestinhalt. Es ist ratsam, zu Beginn des Projekts bewusst das richtige Detaillierungsniveau zu wählen, damit der Plan praktikabel bleibt und tatsächlich genutzt wird.
Was sind die häufigsten Fehler bei der Ausarbeitung eines System-Engineering-Plans?
Ein häufiger Fehler ist das unkritische Kopieren einer generischen Vorlage, ohne diese an den spezifischen Projektkontext anzupassen. Andere häufige Fallstricke sind: das Erstellen des Plans ohne Input des ausführenden Teams, die Beschreibung von Verifikationsstrategien, die sich in der Praxis als undurchführbar erweisen, und das Planen der Genehmigung, die niemals mehr aktualisiert wird. Das Ergebnis ist ein Dokument, das auf dem Papier stimmt, aber nicht die tägliche Arbeitsweise steuert – genau das Szenario, das der SE-Plan gerade verhindern muss.
Wie stelle ich sicher, dass der Systemtechnikplan tatsächlich verwendet und nicht in der Schublade verschwindet?
Der SE-Plan ist nur dann wertvoll, wenn er aktiv als Steuerungsinstrument eingesetzt wird. Stellen Sie daher sicher, dass der Plan für alle Beteiligten zugänglich ist, regelmäßig in Projektbesprechungen diskutiert wird und direkt mit den Arbeitsprozessen für Anforderungsmanagement, Verifizierung und Rückverfolgbarkeit verbunden ist. Toolunterstützung hilft hierbei enorm: Wenn der Plan und die zugehörigen SE-Aktivitäten in einer zentralen Plattform leben, ist die Hemmschwelle, ihn zu konsultieren und zu aktualisieren, deutlich geringer.
Was ist der Unterschied zwischen einem System-Engineering-Plan und einem System-Engineering-Managementplan (SEMP)?
In der niederländischen Praxis werden die Begriffe 'Systems Engineering Plan' und 'Systems Engineering Management Plan (SEMP)' oft synonym verwendet, aber es gibt einen Bedeutungsunterschied. Der SEMP ist ein Begriff, der insbesondere in internationalen Standards wie denen von INCOSE vorkommt und mehr Wert auf die Managementaspekte des SE-Ansatzes legt, wie Planung, Ressourcen und Governance. Der SE-Plan, wie er in niederländischen Infrastrukturprojekten üblich ist – mit-) teil basiert auf dem Leitfaden SE – kombiniert sowohl den technisch-inhaltlichen Ansatz als auch die Managementvereinbarungen in einem Dokument.
Wie verhält sich der Systemtechnikplan zu anderen Projektunterlagen wie dem Projektplan oder dem Qualitätsplan?
Der SE-Plan ist komplementär zum Projektplan und zum Qualitätsplan, hat aber einen eigenen Fokus: Er beschreibt spezifisch, wie die SE-Methodik angewendet wird, um ein System zu schaffen, das nachweislich die Anforderungen erfüllt. Der Projektplan konzentriert sich auf Planung, Budget und Organisation; der Qualitätsplan auf Prozessqualität und Sicherungsmaßnahmen. In der Praxis ist es ratsam, die drei Dokumente aufeinander abzustimmen und widersprüchliche Vereinbarungen zu vermeiden. Querverweise zwischen den Dokumenten helfen, den Zusammenhang zu wahren.
Kann der Auftraggeber einen eigenen SE-Plan neben dem des Auftragnehmers verlangen?
Ja, in manchen Projekten — insbesondere bei großen öffentlichen Auftraggebern oder Rijkswaterstaat-Projekten — hat der Auftraggeber ein eigenes SE-Rahmenwerk oder SE-Plan auf Programmebene. Der Auftragnehmer ist dann verpflichtet, seinen eigenen SE-Plan darauf abzustimmen und nachzuweisen, dass sein Ansatz in die Rahmenbedingungen des Auftraggebers passt. Dies erfordert eine gute Abstimmung in der Anfangsphase des Projekts und klare Vereinbarungen darüber, welches Dokument bei etwaigen Widersprüchen maßgeblich ist.
Wie beginne ich praktisch mit der Erstellung eines Systems-Engineering-Plans, wenn ich wenig Erfahrung mit SE habe?
Beginnen Sie mit dem Sammeln der vertraglichen SE-Anforderungen und ermitteln Sie, welcher SE-Standard anwendbar ist, wie z. B. dem Leitfaden SE oder einer auftraggeberspezifischen Richtlinie. Verwenden Sie anschließend eine bewährte Vorlage als Ausgangspunkt und füllen Sie diese Schritt für Schritt zusammen mit dem Projektteam aus, damit der Plan den tatsächlichen Ansatz widerspiegelt und nicht nur eine Papierübung darstellt. Erwägen Sie Tool-Unterstützung oder Begleitung durch einen erfahrenen SE-Experten für die erste Einrichtung – die Investition zu Beginn des Projekts zahlt sich durch Klarheit und weniger Diskussionen später aus.
Ähnliche Beiträge
- Welke rollen zijn betrokken bij een goed eisenbeheerproces?
- Hoe zet je een eisenbeheerproces op dat ook voor kleine teams werkt?
- Wat is het verschil tussen een systeemeis en een subsysteemeis?
- Hoe draagt eisenbeheer bij aan een succesvolle oplevering en acceptatie?
- Hoe beheer je eisen van meerdere stakeholders tegelijk?