Aufgaben und Probleme gut zu analysieren und dann zielgerichtete Lösungen zu entwickeln – das ist Systems Engineering. Mit dieser wunderbaren Methodik verbessern und beschleunigen Sie Ihre Arbeit nachhaltig, auch, wenn Sie zunächst nur einzelne Methoden einführen. Selbst diese bringen bereits große Produktivitätssprünge, da Aufgaben nun explizit erledigt und dokumentiert werden. Dazu werden elf Rollen im Systems Engineering definiert, die von drei bis sieben Personen ausgeführt werden. In diesem Artikel stellen wir Ihnen die Rollen und ihre Aufgaben als Teil der Grundlagen des Systems Engineering vor.
Inhalt
Systems Engineering als Chance für KMU
Systems Engineering funktioniert am besten, wenn alle Rädchen ineinandergreifen – idealerweise (aber nicht notwendigerweise) wird dafür die Zusammenarbeit aller Beteiligten im Projekt optimiert: Hier liegt für kleine und mittlere Unternehmen eine besondere Chance, aber auch eine besondere Herausforderung!
Systems Engineering setzt nicht nur auf die Trennung unterschiedlicher Zuständigkeiten im Rahmen des Prozesses – auch der Prozess selbst und, darüber hinaus, Unternehmensstrukturen ändern sich.
Um Missverständnissen vorzubeugen: Wir von Two Pillars sind davon überzeugt, dass diese Veränderungsprojekte nicht zwingend notwendig sind, sondern auch „schon ein wenig Systems Engineering“ große Potentiale heben kann. Der Form halber wollen wir aber in diesem Beitrag diskutieren, wie Systems Engineering aus Sicht der beteiligten Rollen ausgestaltet sein sollte.
Anforderungen an den Maschinenbau
Die Anforderungen an den Maschinenbau sind hoch: Funktionsreichtum und Individualisierungsoptionen sorgen für eine steigende Produktkomplexität. Elektronik, Mechanik und Software treffen aufeinander, sodass bei der Entwicklung neuer Produkte eine Vielzahl von Herausforderungen gelöst werden muss. Varianz in den Produkten kommt hinzu: Der Baukasten als Lösungsansatz will beherrscht werden.
Systems Engineering ist ein ganzheitlicher und interdisziplinärer Ansatz, um diese Anforderungen hinsichtlich Zeit und Ressourcen am besten zu erfüllen: Sie umschiffen elegant Fehlerquellen und vermeiden langwierige Testphasen, indem Sie die klassischen Methoden auf Systems Engineering umstellen – bzw. ergänzen. Aber Vorsicht: Dies revolutioniert nicht nur Ihre Produktentwicklung und Ihr Projektmanagement, sondern auch Ihr Unternehmen selbst.
Für den deutschen, mittelständisch geprägten Maschinenbau liegen Chance und Risiko eng beieinander: Wie kann es gelingen, dass wenige, hoch qualifizierte Mitarbeiter diesen Anforderungen gerecht werden, und zwar, ohne die Arbeitsbelastung zu steigern, sondern sie bestenfalls zu senken?
Vom klassischen Verständnis der einzelnen Rollen im Systems Engineering bewegen wir uns hin und versuchen mit Hilfe der Erfahrungen von Möhringer einen Transfer auf die Spezifika eines maschinenbaulichen Unternehmens.
Rollen im Systems Engineering: Systems Engineering ist Teamwork
Systems Engineering lastet nicht nur auf einer Person, Systems Engineering ist Teamwork! Den einen „Systems Engineer“ gibt es so gar nicht. In der Forschung und in der Praxis haben sich elf verschiedene Rollen herauskristallisiert, die von drei bis sieben Personen ausgefüllt werden.
Bei der „Mutter aller Systems Engineers“, Sarah Sheard, sind es genau genommen zwölf Rollen – sie hat im Jahr 1996 dazu eine Analyse verschiedenster empirisch anzutreffender Aufgabenbereiche gemacht, die bis heute noch höchsten Anklang findet. Die Unterscheidung der verschiedenen Rollen ist besonders für kleine und mittlere Unternehmen wichtig, deren personelle Ressourcen begrenzt sind.
Gewichtung und inhaltlicher Umfang der einzelnen Rollen fallen dabei sehr unterschiedlich aus und sind abhängig von Größe und Anforderung des Projekts. Auch variiert der zeitliche Einsatz der einzelnen Rollen, sodass die elf Rollen im Systems Engineering auf weniger Köpfe verteilt werden können.
Im Folgenden gehen wir auf diese Rollen ein, wie sie von Sheard und Möhringer benannt werden. Zum Teil sind auch andere Bezeichnungen gebräuchlich. Wir verwenden die englischen Bezeichnungen, die auch weibliche Vertreter bezeichnen können.
Requirement Owner (RO): Anforderungsmanagement
Der Requirement Owners (RO) übersetzt Kundenanforderungen in spezifische Anforderungen. Im Wesentlichen findet der RO Antworten auf diese Fragen: Welche Systeme und Subsysteme müssen designt und gebaut werden?
Dazu muss der RO auch die externen Schnittstellen verstehen und sicherstellen, dass die funktionale Architektur des zu entwickelnden Systems den Bedarf erfüllt. Dabei nimmt der Requirement Owner Einfluss auf das gesamte System inklusive seiner Subsysteme und ist auch für spätere Änderungen in den Anforderungen und deren Auswirkungen auf das System verantwortlich.
Die Herausforderung, die sich bereits in diesem frühen Stadium der Produktentwicklung ergibt, ist die Gewährleistung der Traceability: Spätere Änderungen müssen lückenlos nachvollziehbar sein. Bei der Erstellung eines traditionellen Pflichtenheftes in einem Word-Dokument ist dies bei komplexen technischen Projekten kaum noch möglich, weswegen der Einsatz einer Software-Lösung für das Requirements Engineering mehr als ratsam ist. iQUAVIS wäre hier eine Möglichkeit, oder man kann Teile des Requirements Engineering mit einem entsprechenden Tool koordinieren. Über die Schnittstellen von iQUAVIS zu Requirements Managements Tools lesen Sie hier weiter.
Die Rolle des Requirement Owners wird nach Möhringer bei kleinen Projekten dem oder der Vertriebsingenieur:in zugeordnet; bei mittleren und großen Unternehmen liegt die Rolle bei der Projektleitung.
System Designer (SD): Systementwicklung
Der System Designer (SD) tritt nach der Definition der funktionalen Anforderungen durch den Requirement Owner auf und ist für die Gestaltung von Architektur und Konzept zuständig. In diesem Stadium erschafft der System Designer die Systemarchitektur und trifft die Auswahl der wichtigsten Systemkomponenten. Der Schwerpunkt liegt bei der Zuordnung von Funktionen zu Elementen sowie ihrer Anordnung in eine Struktur.
System Designer und Requirement Owner arbeiten in der Praxis oft zusammen: Ihre Rollen überschneiden sich vor allem bei der Auswahl der erforderlichen Subsysteme. Im Unternehmen wird diese Rolle von der Entwicklungsleitung oder einem Entwicklungsingenieur ausgefüllt.
System Analyst (SA): Systemanalyse
Der System Analyst (SA) trägt Sorge für die Erfüllung der Anforderungen im designten System. Darunter fallen z.B. das Systemgewicht, die Leistung, Durchsatz und Ausgabekenngrößen. Von sehr komplexen Bauteilen werden erste Modelle erstellt, um ihre Funktionen zu simulieren und um zu testen, ob sie so funktionieren werden, wie geplant.
Die Systemanalyse kann auf den abstrakteren Ebenen bereits in iQUAVIS erfolgen. Logische Zusammenhänge, kleinere Berechnungen usw. können hier beispielsweise direkt erfolgen. Für komplexere Simulationen werden disziplinspezifische Werkzeuge genutzt, die mit den Daten aus dem SE-Tool versorgt werden.
Validation and Verification (VV)
Im Anschluss an die Simulationen plant und implementiert die Rolle des Validations- und Verifikationsingenieurs Testpläne und -prozeduren: Hier wird sichergestellt, dass das System die Anforderungen erfüllt. Diese Rolle wird aus dem Bereich Entwicklung ausgefüllt.
In diesem Schritt geht es darum, alle Systemeigenschaften zu testen und etwaige Szenarien vorauszusehen. Auftretende Anomalien müssen bestmöglich beantwortet werden.
Logistics and Operations (LO)
Die Logistik- und Operationsrolle wird nach Möhringer auch den Entwicklungsingenieur:innen zugeordnet, bei Großprojekten einer Serviceleiterin oder einem Serviceleiter. Diese Rolle übernimmt den Betrieb und Service des Systems und erstellt die Bedienungs- und Schulungsunterlagen.
Das System wird für den Kunden in Betrieb genommen und Fragen rund um Service, Wartung und Lebenszyklus des Systems werden gemäß der ISO 15288 evaluiert.
Glue (G)
Die Glue-Rolle ist die Troubleshooter-Rolle: Erfahrungsgemäß treten Schnittstellenprobleme bei interdisziplinären Projekten auf. Die Glue-Rolle untersucht diese und findet Lösungen, indem sie Abhängigkeiten und Unverträglichkeiten frühzeitig erkennt. Inhaber:innen dieser Rolle müssen breite Erfahrung und Wissen sowie fundiertes Lerninteresse mitbringen. Üblicherweise übernimmt die Projektleitung diese Rolle.
Customer Interface (CI)
Die Customer Interface-Rolle nimmt die Kundenperspektive ein und prüft die Kundenfreundlichkeit des Systems. Diese Rolle ist eng mit der des System Designers verwandt, wird in Unternehmen je nach Projektgröße von dem oder der Vertriebsingenieur:in oder der Projektleitung übernommen.
Technical Manager (TM)
Die Rolle des Technical Managers beinhaltet im Rahmen des Programm-Managements die Kostenkontrolle, die Ressourcenplanung und die Beaufsichtigung von Supportgruppen. Sie liegt üblicherweise in der Projektleitung.
Information Manager (IM)
Das Information Management hat den Überblick über den Informationsbedarf des Systems und des Unternehmens, inklusive des Datenmanagements und des Konfigurationsmanagements.
Process Engineer (PE)
Die Process-Engineer-Rolle beaufsichtigt das Vorgehen im Systems Engineering: Sie dokumentiert und verbessert die Organisation der Prozesse. Idealerweise überträgt sie ihre Erkenntnisse auch auf Unternehmensabläufe. Diese Rolle liegt in der Verantwortung der Projektleitung, bei Großprojekten im Qualitätsmanagement.
Coordinator
Der Coordinator organisiert die einzelnen Gruppen. Er oder sie vermittelt bei Problemen und erarbeitet Vorschläge für einen Konsens, wenn Probleme zwischen den unterschiedlichen Abteilungen auftreten. Der Coordinator begleitet das Projekt permanent oder bei Bedarf. Die Rolle liegt bei der Projektleitung oder, bei Großprojekten, bei der Geschäftsleitung.
Classified Ads Systems Engineering (CA)
Neben den elf genannten Rollen taucht bei Sarah Sheard noch eine zwölfte Rolle auf, die sie als „Classified Ads Systems Engineering-Role“ bezeichnet und die die vorangegangenen Rollen komplettiert. Die Notwendigkeit dieser Rolle stellte sie über die Analyse von System-Engineer-Stellenausschreibungen fest, die alle „andere“ Fähigkeiten beschrieben. Diese Rolle hat einen starken Schwerpunkt auf Computersysteme und ist nicht eindeutig definiert:
Although the details are unresolved, it is useful to retain this role as a reminder that there are more definitions of systems engineering than the first eleven roles.
Sarah Sheard: Twelve Systems Engineering Role, 1996, S. 5.
Zwei Kategorien der Systems-Engineering-Rollen
Die genannte Einteilung bringt Ihnen bei der Einführung von Systems Engineering mehrere Vorteile: Abhängig von der Beschaffenheit des Projekts können Rollen zugeteilt werden, wobei einzelne Personen mehrere Rollen übernehmen können – bei kleineren Unternehmen wird dies unumgänglich sein. Die Kompetenzen innerhalb des Projekts sind durch die Rollenzuordnung klar abgesteckt, was sowohl für die Teammitglieder als auch die Projektleitung von Vorteil ist. Einzelne Mitglieder haben im Lauf der Zeit die Möglichkeit, ihre Kompetenzen zu erweitern und weitere Rollen zu übernehmen. Gleichzeitig bietet das Rollensystem Flexibilität in der Zuordnung von Kompetenzen; auch neue Teammitglieder können schnell in ihre Funktion eingearbeitet werden.
In der Betrachtung der Rollen im Systems Engineering kristallisieren sich zwei Kategorien heraus: Lebenszyklus- und Programm-Management-Rollen. Zu den Lebenszyklus-Rollen zählen RO, SD, VV, LO und SA. Sie sind während des System-Lebenszyklus aktiv, wohingegen die Rollen TM, G, IM, CO und CI in erster Linie Programm-Management-Rollen sind. Natürlich sind die Grenzen, gerade in kleinen Unternehmen, fließend. Einige der Lebenszyklus-Rollen können Teil des Programm-Managements sein und werden zum Teil auch von ein und derselben Person ausgefüllt. Beide Gruppen arbeiten als Team gemeinsam daran, am Ende ein funktionierendes System innerhalb der vereinbarten Lieferzeit produziert zu haben.
Wie die Darstellung der Rollen gezeigt hat, gibt es den einen Systems Engineer nicht. Für gelungene Systems-Engineering-Projekte müssen mehrere Spezialist:innen Funktionen übernehmen, die sich zum Teil überlappen und ergänzen. Je nach Projekt und Unternehmen variiert die Gewichtung auf den einzelnen Rollen, die sowohl einzelnen Personen als auch Personengruppen zugeteilt sein kann.
Systems Engineering passt sich als Methode diesen Voraussetzungen an und ermöglicht variable Schwerpunkte bei der Rollenverteilung: Risikoreiche Projekte erfordern beispielsweise eine intensivere Systemanalyse; technisch anspruchsvolle Projekte werden mehr Ressourcen für das Customer Interface einplanen müssen.
Die Rollen interagieren während des Projekts zu verschiedenen Themen miteinander. Prägnant sind dabei unter anderem diese Prozesse:
- Risiko: Der Systemanalyst analysiert das Risiko, die Glue-Rolle identifiziert es, und der Technical Manager nimmt sich des Risikos in Form von Risikominderungsplänen an.
- Design Reviews: Die Rolle des Technical Managers organisiert den Review, Customer Interface stellt die Aufmerksamkeit des Kunden sicher, und die Glue-Rolle trägt die Verantwortung dafür, dass das Design durchgängig überwacht wird.
- Metrics: Die benötigten Messdaten werden vom Process Engineer identifiziert, und er gibt die notwendigen Messungen vor. Lebenszyklus-Ingenieure erheben die Werte, die dann vom Technical Manager als Entscheidungsgrundlage genutzt werden.
- Customer Interaction: Die LO-Rolle ist sehr kundenorientiert in den Punkten Benutzerfreundlichkeit und Funktionalität. Der RO muss sehr eng mit ihm zusammenarbeiten, um sicherzustellen, das System den Kundenwünschen entspricht. Um dies zu erreichen, arbeitet wiederum der CI eng mit dem Kunden während des gesamten Prozesses der Produktentwicklung zusammen.
Fazit
Systems Engineering neu in einem Unternehmen einzuführen, erfordert ein Um- und Mitdenken auf allen Ebenen. Die Methodik durchdringt mit seinem ganzheitlichen Ansatz nicht nur das zu entwickelnde System, sondern auch das Unternehmen selbst: Es hat einen nachhaltigen Impact auf Ihr Unternehmen, der sich langfristig positiv auswirken wird.
Wenn Sie den Weg beschreiten wollen, kann ein Ansatz im Change-Prozess sein, sich über die Rollen im Systems Engineering Gedanken zu machen: Welche Rollen sind für Ihr Unternehmen unabdingbar? Welche sind von zweitrangiger Bedeutung? Wie würden Sie die Rollen in Ihrem Unternehmen verteilen?
Die Begleitung bei der Einführung von Systems Engineering ist Teil unserer Leistungen: Wir beraten und schulen Sie und Ihre Mitarbeiter bei der Implementierung von MBSE und unserer Software iQUAVIS und helfen bei der Umstellung auf Systems Engineering. Wie Kunden diese Herausforderung gemeistert haben, erfahren Sie in unseren Erfolgsgeschichten.
Quellen
Möhringer
Sarah Sheard: Twelve Systems Engineering Roles, 1996.
Mehr über MBSE
Tauchen Sie mit diesen Artikeln noch tiefer in das Thema MBSE ein, oder sprechen Sie uns bei Fragen direkt an!
- 11 Freunde – Rollen im Systems Engineering
Aufgaben und Probleme gut zu analysieren und dann zielgerichtete Lösungen zu entwickeln – das ist Systems Engineering. Mit dieser wunderbaren Methodik verbessern und beschleunigen Sie Ihre Arbeit nachhaltig, auch, wenn Sie zunächst nur einzelne Methoden einführen. Selbst diese bringen bereits große Produktivitätssprünge, da Aufgaben nun explizit erledigt und dokumentiert werden. Dazu werden elf Rollen im - Alles über Systems Engineering
Sie wollen sich mit Systems Engineering befassen oder fragen sich, was Model-Based Systems Engineering für Sie tun kann? Dann lesen Sie weiter: Systems Engineering fällt als Schlagwort immer wieder, wenn es um die Bewältigung komplexer Herausforderungen in der Produktentwicklung geht. Doch was steckt wirklich dahinter? Viele verbinden mit dem Begriff eine Fülle an Methoden, Tools und - Entwicklungsbegleitendes Qualitätsmanagement mit iQUAVIS – Webinar Download
Im Januar 2025 fand zum ersten Mal unser Webinar „Entwicklungsbegleitendes Qualitätsmanagement“ statt. Darin stellte unser Experte Matthias Greinert das Arbeiten in unserem MBSE-Tool iQUAVIS hinsichtlich der Fehler- und Risikoanalysen vor. Methoden für das entwicklungsbegleitende Qualitätsmanagement Der Methodenkonfigurator ermöglicht Ihnen in iQUAVIS die FMEA, DRBFM, HOQ und andere Methoden für das entwicklungsbegleitende Qualitätsmanagement. Dies geschieht im
iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.
Systems Engineering ist eine Lebensart – wer sie einmal kennt, kommt nicht von ihr los! Ich brenne dafür, das Engineering zu verändern. Weg von verwirrenden Lasten- und Pflichtenheften hin zu einer modellbasierten Spezifikation. Das hilft mir, viele Aufgaben eines Projekts besser zu bewältigen, mit Kollegen ein gemeinsames eindeutiges Systemverständnis zu bilden und immer die relevanten Aufgaben im Blick zu haben. Und außerdem: Ich bin überzeugt, dass innovative Geschäftsmodelle nur mit einem solchen Ansatz möglich werden: Smarte Services, Things that think, … Let’s go together!
