Systemarchitektur

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. 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,