Den Blick für das Wesentliche wahren – wertschöpfende Tätigkeiten im agilen Systems Engineering

„Was ist der Betrachtungsgegenstand in der Entwicklung?“ – eine Frage, die wir unseren Kunden immer wieder stellen und die überraschend häufig zu längeren Diskussionen zwischen den an der Entwicklung beteiligten Personen führt. Warum ist diese Frage im Kontext der Entwicklung von Systemen so wichtig? Ganz einfach! Wenn Sie nicht wissen, was das Ergebnis Ihrer Systementwicklung sein soll, fällt es Ihnen schwer, die für dessen Erzeugung notwendigen Tätigkeiten festzulegen und mit dem erforderlichen Aufwand durchzuführen.

Besonders im Kontext des agilen Systems Engineering gehen wir als SOPHIST davon aus, dass jede Tätigkeit in der Entwicklung eines technischen Systems zweckmäßig eingesetzt wird und einen wichtigen Beitrag zur Wertschöpfung liefert. Dies haben wir mit unserer Definition zu agilem Systems Engineering im vorherigen Artikel dieser Blogserie zum Ausdruck gebracht (Artikel verpasst? Kein Problem, hier können Sie nachlesen!)

„Agiles Systems Engineering ist die bedingungslose Ausrichtung aller Entwicklungstätigkeiten in allen an der Entwicklung beteiligten Gewerken über den gesamten Lebenszyklus des zu entwickelnden Systems an den dynamischen Bedürfnissen des Marktes.“

Nun werden sicher einige, sehr technisch orientierte Disziplinen aufschreien und die Frage stellen:

„Wenn wir wirklich nur die zweckmäßigen Tätigkeiten durchführen sollen, wozu erzeugen wir dann eigentlich so viel Dokumentation? Das hat nichts mit Wertschöpfung, d.h. dem eigentlichen System, das den Kunden verkauft wird, zu tun und verzögert nur die Entwicklung!“

Bei dieser Aussage handelt es sich meist um einen klaren Trugschluss, denn um die Wertschöpfung zu gewährleisten, muss, besonders im regulierten Umfeld, mehr als nur die Entwicklung des Systems fokussiert werden. So sind bspw. für den Verkauf von medizinischen Produkten bestimmte Nachweise zu im Rahmen der Entwicklung durchgeführten Tätigkeiten erforderlich, um eine Zulassung für den Verkauf des Produkts vom Gesetzgeber zu erhalten. Können Sie diese Nachweise nicht führen, erhält Ihr Produkt keine Zulassung. Die Wertschöpfung, also der Verkauf des Produkts am Markt, kann (und darf) nicht erfolgen.

Um derartige Überraschungen zu vermeiden, sollten Sie bewusst die Frage stellen, was in Ihrem Kontext neben dem eigentlichen System tatsächlich erforderlich ist, um eine Wertschöpfung zu gewährleisten.

Beim aufmerksamen Lesen ist Ihnen sicher aufgefallen, dass wir die Begriffe System und Produkt verwendet haben. Dabei handelt es nach unserem Verständnis nicht um Synonyme, sondern wir treffen diese Unterscheidung bewusst. Unter einem System verstehen wir vereinfacht „ein technisches Ding, das durch koordinierte Aktionen bestimmte Services anbietet“ (vgl. [1]).

Unter einem Produkt verstehen wir etwas, das potenziellen Kunden über einen Markt angeboten und verkauft oder im Rahmen einer Individualentwicklung für einen einzigen Kunden erzeugt wird. Dies kann mehr umfassen als ein (technisches) System. Ein einfaches Beispiel ist, dass Produkte häufig Benutzungs- und Wartungshandbücher umfassen, die kein Bestandteil des Systems selbst sind und die neben der Entwicklung des eigentlichen Systems erzeugt werden müssen. Ein weiteres Beispiel dafür sind Beipackzettel von Medikamenten. Als erfahrener Requirements Engineer kommen Ihnen derartige Forderungen sicher als Anforderungen an sonstige Lieferbestandteile bekannt vor.

Was heißt das nun für Sie? Auch wenn der Schwerpunkt im Systems Engineering in der Entwicklung des technischen Systems liegt, sind meist weitere, unterstützende Tätigkeiten erforderlich, um die Wertschöpfung zu gewährleisten, d.h. um das Produkt am Markt zu verkaufen. Diese Tätigkeiten gilt es zu identifizieren und mit ausreichend Ressourcen rechtzeitig durchzuführen. Außerdem gilt es das Produkt und nicht nur das System als Ganzes zu betrachten, alle für dieses Produkt relevanten Stakeholder (z.B. auch den Gesetzgeber, Zulassungsstellen oder ähnliches) als Quelle für mögliche Anforderungen zu betrachten und entsprechende Maßnahmen für die Erfüllung dieser Anforderungen abzuleiten.

Eine erste wertschöpfende Tätigkeit für Sie könnte die Anmeldung zu unserem agilen Systems Engineering Training sein, in dem wir unter anderem detailliert auf das in diesem Blogartikel beschriebene Thema und viele mehr eingehen. Den Link zur Anmeldung finden Sie hier: https://www.sophist.de/trainings/unsere-trainings/agiles-systems-engineering-sophist-gmbh/. Wir freuen uns auf Sie!

Literatur:

[1] Glinz, Martin (2020): A Glossary of Requirements Engineering Terminology. Version 2.0.0. Online verfügbar unter https://www.ireb.org/content/downloads/1-cpre-glossary-2-0/ireb_cpre_glossary_de_2.0.2.pdf, zuletzt geprüft am 15.09.2022.

Weitere Beiträge aus dieser Blogserie finden Sie hier:

  1. Agiles Systems Engineering – Spagat zwischen Problemlöser und Selbstzweck
  2. Keine Continuous Delivery ohne Continuous Documentation! – agiles Systems Engineering im regulierten Umfeld

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert