Der Systems-Engineer oder SE-Koordinator des ausf\u00fchrenden Projektteams erstellt in der Regel den Systems-Engineering-Plan. Diese Person \u00fcbersetzt die Projektanforderungen, den gew\u00e4hlten SE-Ansatz und die Vereinbarungen mit dem Auftraggeber in ein praktikables Dokument, das dem gesamten Team Orientierung gibt. Die Verantwortung liegt somit prim\u00e4r beim Auftragnehmer, aber der Auftraggeber spielt eine unverzichtbare Rolle bei der Festlegung und Pr\u00fcfung. In diesem Artikel beantworten wir die am h\u00e4ufigsten gestellten Fragen zum Eigentum, zur Genehmigung und zur Wartung des Systems-Engineering-Plans.<\/p>\n
Der Systems-Engineering-Plan wird in der Regel vom Systemsingenieur oder SE-Koordinator auf der Seite des Auftragnehmers erstellt. Diese Person verf\u00fcgt \u00fcber das technische und methodische Wissen, um den SE-Ansatz zu beschreiben, die Verifikationsstrategie festzulegen und die Rollen innerhalb des Projekts zu definieren. Bei gr\u00f6\u00dferen Projekten kann diese Aufgabe von einem SE-Manager oder Lead-Ingenieur \u00fcbernommen werden, der vom Projektteam unterst\u00fctzt wird.<\/p>\n
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\u00fcllt wird, sondern um einen lebendigen Plan, der den tats\u00e4chlichen Ansatz beschreibt. Dies erfordert inhaltliches Engagement von jemandem, der das Projekt und die Methodik gut kennt.<\/p>\n
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<\/a> teams hierbij ondersteunt? Bekijk dan wat ons platform voor jouw project kan betekenen.<\/p>\n 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\u00e4tigt, dass der Plan den gestellten Anforderungen und der vereinbarten Arbeitsweise entspricht. Erstellen ist eine inhaltliche Aufgabe; genehmigen ist eine formelle Verantwortung.<\/p>\n In den meisten Projekten erstellt der Auftragnehmer den Plan und der Auftraggeber genehmigt ihn. Die Genehmigung ist keine reine Formalit\u00e4t. Mit der Billigung des Plans verpflichtet sich der Auftraggeber zu dem beschriebenen Ansatz und erkl\u00e4rt, dass die gew\u00e4hlte SE-Methodik den Projektzielen entspricht. Ein Plan, der ohne inhaltliche Pr\u00fcfung genehmigt wird, bietet sp\u00e4ter wenig Halt bei Diskussionen \u00fcber Umfang, Verifizierung oder \u00dcbergabe.<\/p>\n Neben dem Auftraggeber k\u00f6nnen auch ein interner Qualit\u00e4tsmanager, ein SE-Review-Board oder ein unabh\u00e4ngiger Pr\u00fcfer an der Genehmigung beteiligt sein. Bei komplexen Infrastrukturprojekten oder \u00f6ffentlichen Ausschreibungen sind mehrere Genehmigungsebenen \u00fcblich. Es ist ratsam, im Plan selbst festzulegen, wer welche Genehmigung erteilt und zu welchem Zeitpunkt im Projekt.<\/p>\n Der Auftraggeber hat eine dreiteilige Rolle im Systems Engineering Plan: Er setzt die Rahmenbedingungen, pr\u00fcft den Plan auf Konformit\u00e4t mit den vertraglichen Anforderungen und genehmigt ihn formell. Dar\u00fcber hinaus kann der Auftraggeber spezifische SE-Anforderungen vorschreiben, wie z. B. die Verwendung bestimmter Verifikationsmethoden, Berichtsformate oder R\u00fcckverfolgbarkeitsanforderungen, die der Auftragnehmer verarbeiten muss.<\/p>\n 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 \u00f6ffentlichen Projekten oder gro\u00dfen Infrastrukturaufgaben der Fall, bei denen der Auftraggeber selbst ebenfalls \u00fcber SE-Kompetenzen verf\u00fcgt.<\/p>\n Ein h\u00e4ufiger Fehler ist, dass der Auftraggeber den SE-Plan als ein vertraglich abzuhakendes Dokument behandelt. Das untergr\u00e4bt dessen Wert. Ein Auftraggeber, der inhaltlich an der Erstellung des Plans beteiligt ist, erh\u00f6ht die Chance, dass der Plan tats\u00e4chlich den Projektzielen entspricht und sp\u00e4ter als Steuerungsinstrument statt als Schreibtischschubladen-Dokument genutzt wird.<\/p>\n Da SE-Expertise im Projektteam fehlt, wird die Verantwortung f\u00fcr den Systems Engineering Plan oft vor\u00fcbergehend einem externen SE-Berater oder einem beauftragten Spezialisten \u00fcbertragen. Eine andere Option ist, die Verantwortung auf den Projektmanager oder Lead Engineer zu legen, erg\u00e4nzt durch Anleitung von einem SE-Wissenspartner oder \u00fcber eine Plattform, die die Methodik unterst\u00fctzt.<\/p>\n Fehlende SE-Expertise ist ein reales Problem in vielen Organisationen. Nicht jedes Unternehmen besch\u00e4ftigt einen Vollzeit-Systems-Engineer, aber das bedeutet nicht, dass SE-Prinzipien ignoriert werden m\u00fcssen. In der Praxis gibt es drei g\u00e4ngige L\u00f6sungen:<\/p>\n Welcher Ansatz am besten geeignet ist, h\u00e4ngt vom Projektumfang, dem verf\u00fcgbaren 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\u00fctzung und internen Wissensaufbau zu investieren.<\/p>\n Der Systems-Engineering-Plan muss \u00fcberarbeitet werden, wenn wesentliche \u00c4nderungen am Projektumfang, den Systemanforderungen, der Organisationsstruktur oder dem gew\u00e4hlten SE-Ansatz vorgenommen werden. Dar\u00fcber hinaus ist eine \u00dcberarbeitung bei vordefinierten Meilensteinen erforderlich, z. B. nach einer Systempr\u00fcfung oder beim \u00dcbergang in eine neue Projektphase.<\/p>\n Ein SE-Plan ist kein statisches Dokument. Er beschreibt, wie das Projekt den SE-Ansatz umsetzt, und wenn sich die Realit\u00e4t \u00e4ndert, muss sich der Plan mit \u00e4ndern. Typische Zeitpunkte f\u00fcr eine \u00dcberarbeitung sind:<\/p>\n In der Praxis wird die \u00dcberarbeitung des SE-Plans zu oft aufgeschoben oder vergessen. Das f\u00fchrt dazu, dass der Plan die Realit\u00e4t 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\u00fcgbar und \u00c4nderungen sind nachvollziehbar. So bleibt der Systems-Engineering-Plan ein lebendiges Instrument anstelle einer vergessenen Anlage.<\/p>\n \n Nicht jedes Projekt erfordert einen ebenso umfangreichen SE-Plan. Bei kleineren oder weniger komplexen Projekten kann ein pr\u00e4gnanter SE-Ansatz oder ein vereinfachter Plan, der die Kernvereinbarungen festh\u00e4lt, 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\u00e4hlen, damit der Plan praktikabel bleibt und tats\u00e4chlich genutzt wird. <\/p>\n <\/div>\n \n Ein h\u00e4ufiger Fehler ist das unkritische Kopieren einer generischen Vorlage, ohne diese an den spezifischen Projektkontext anzupassen. Andere h\u00e4ufige Fallstricke sind: das Erstellen des Plans ohne Input des ausf\u00fchrenden Teams, die Beschreibung von Verifikationsstrategien, die sich in der Praxis als undurchf\u00fchrbar 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\u00e4gliche Arbeitsweise steuert \u2013 genau das Szenario, das der SE-Plan gerade verhindern muss. <\/p>\n <\/div>\n \n Der SE-Plan ist nur dann wertvoll, wenn er aktiv als Steuerungsinstrument eingesetzt wird. Stellen Sie daher sicher, dass der Plan f\u00fcr alle Beteiligten zug\u00e4nglich ist, regelm\u00e4\u00dfig in Projektbesprechungen diskutiert wird und direkt mit den Arbeitsprozessen f\u00fcr Anforderungsmanagement, Verifizierung und R\u00fcckverfolgbarkeit verbunden ist. Toolunterst\u00fctzung hilft hierbei enorm: Wenn der Plan und die zugeh\u00f6rigen SE-Aktivit\u00e4ten in einer zentralen Plattform leben, ist die Hemmschwelle, ihn zu konsultieren und zu aktualisieren, deutlich geringer. <\/p>\n <\/div>\n \n In der niederl\u00e4ndischen 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\u00e4ndischen Infrastrukturprojekten \u00fcblich ist \u2013 mit-) teil basiert auf dem Leitfaden SE \u2013 kombiniert sowohl den technisch-inhaltlichen Ansatz als auch die Managementvereinbarungen in einem Dokument. <\/p>\n <\/div>\n \n Der SE-Plan ist komplement\u00e4r zum Projektplan und zum Qualit\u00e4tsplan, hat aber einen eigenen Fokus: Er beschreibt spezifisch, wie die SE-Methodik angewendet wird, um ein System zu schaffen, das nachweislich die Anforderungen erf\u00fcllt. Der Projektplan konzentriert sich auf Planung, Budget und Organisation; der Qualit\u00e4tsplan auf Prozessqualit\u00e4t und Sicherungsma\u00dfnahmen. In der Praxis ist es ratsam, die drei Dokumente aufeinander abzustimmen und widerspr\u00fcchliche Vereinbarungen zu vermeiden. Querverweise zwischen den Dokumenten helfen, den Zusammenhang zu wahren. <\/p>\n <\/div>\n \n Ja, in manchen Projekten \u2014 insbesondere bei gro\u00dfen \u00f6ffentlichen Auftraggebern oder Rijkswaterstaat-Projekten \u2014 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\u00fcber, welches Dokument bei etwaigen Widerspr\u00fcchen ma\u00dfgeblich ist. <\/p>\n <\/div>\n \n 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\u00dfend eine bew\u00e4hrte Vorlage als Ausgangspunkt und f\u00fcllen Sie diese Schritt f\u00fcr Schritt zusammen mit dem Projektteam aus, damit der Plan den tats\u00e4chlichen Ansatz widerspiegelt und nicht nur eine Papier\u00fcbung darstellt. Erw\u00e4gen Sie Tool-Unterst\u00fctzung oder Begleitung durch einen erfahrenen SE-Experten f\u00fcr die erste Einrichtung \u2013 die Investition zu Beginn des Projekts zahlt sich durch Klarheit und weniger Diskussionen sp\u00e4ter aus. <\/p>\n <\/div>\n <\/div>\n Eigenaarschap van het systems engineering plan: wie stelt op, wie keurt goed en wanneer herzie je het?<\/p>","protected":false},"author":3,"featured_media":1873,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_improvement_type_select":"improve_an_existing","_thumb_yes_seoaic":false,"_frame_yes_seoaic":false,"seoaic_generate_description":"","seoaic_improve_instructions_prompt":"","seoaic_rollback_content_improvement":"","seoaic_idea_thumbnail_generator":"","thumbnail_generated":false,"thumbnail_generate_prompt":"","seoaic_article_description":"","neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","neve_meta_reading_time":"","_themeisle_gutenberg_block_has_review":false,"seoaic_article_subtitles":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1791","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts\/1791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/comments?post=1791"}],"version-history":[{"count":2,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts\/1791\/revisions"}],"predecessor-version":[{"id":2194,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts\/1791\/revisions\/2194"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/media\/1873"}],"wp:attachment":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/media?parent=1791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/categories?post=1791"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/tags?post=1791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Was ist der Unterschied zwischen entwerfen und genehmigen?<\/h2>\n
Welche Rolle hat der Auftraggeber im SE-Plan?<\/h2>\n
Wie wird Verantwortung bei fehlender SE-Expertise zugewiesen?<\/h2>\n
\n
Wann muss der Systementwicklungsplan \u00fcberarbeitet werden?<\/h2>\n
\n
H\u00e4ufig gestellte Fragen<\/h2>\n
\n Muss jedes Projekt, unabh\u00e4ngig von seiner Gr\u00f6\u00dfe, einen vollst\u00e4ndig ausgearbeiteten System-Engineering-Plan haben? <\/h3>\n
\n Was sind die h\u00e4ufigsten Fehler bei der Ausarbeitung eines System-Engineering-Plans? <\/h3>\n
\n Wie stelle ich sicher, dass der Systemtechnikplan tats\u00e4chlich verwendet und nicht in der Schublade verschwindet? <\/h3>\n
\n Was ist der Unterschied zwischen einem System-Engineering-Plan und einem System-Engineering-Managementplan (SEMP)? <\/h3>\n
\n Wie verh\u00e4lt sich der Systemtechnikplan zu anderen Projektunterlagen wie dem Projektplan oder dem Qualit\u00e4tsplan? <\/h3>\n
\n Kann der Auftraggeber einen eigenen SE-Plan neben dem des Auftragnehmers verlangen? <\/h3>\n
\n Wie beginne ich praktisch mit der Erstellung eines Systems-Engineering-Plans, wenn ich wenig Erfahrung mit SE habe? <\/h3>\n
\u00c4hnliche Beitr\u00e4ge<\/h2>