Wir werden häufig gefragt: Welche Normen werden sich im Rahmen der digitalisierten Zusammenarbeit in der Produktentwicklung durchsetzen? Wir stellen die aus unserer Sicht spannendsten drei Arbeiten für Sie kurz vor: Der „Klassiker“ ist die ISO/IEC 15288: Systems and Software Engineering – System Life Cycle Processes. Sie beschreibt die Prozesse über den Lebenszyklus eines technischen Systems.
Inhalt
ISO/IEC 15288: Systems and Software Engineering – System Life Cycle Processes
Die ISO/IEC 15288: Systems and Software Engineering – System Life Cycle Processes beschreibt, anders als die ISO 42010, die Prozesse über den Lebenszyklus eines technischen Systems. Es werden vier Prozess-Gruppen inklusive entsprechender Terminologie definiert. Für jede Gruppe werden die für Systems Engineers relevanten Prozesse detailliert. Diese werden unabhängig von der Komplexität eines Systems, der Produktstrukturstufe oder Projektphase angewendet; einzig der erbrachte Aufwand für die Prozesse ändert sich.
- Produktbezogene/ Technische Prozesse: Hier finden sich alle technischen Aktivitäten des Lebenszyklus. Durch deren Anwendung entsteht das Produkt oder der Service. Bestandteile sind beispielsweise Geschäftsfall- und Missionsanalyse, Kundenwunsch und Anforderungsdefinition, Systemanforderungsdefinition, Systemanalyse, Architekturdefinition, Designentwurf sowie Aktivitäten bezüglich Implementierung, Integration, Verifikation, Transition, Validierung, Operation, Wartung und Entsorgung.
- Projekt-/Technische Management-Prozesse: Diese adressieren das technische Management von Entwicklungsvorhaben und ergänzen das Projektmanagement. Die entsprechenden Aktivitäten beziehen sich also auf die Planung, Projektbeurteilung und -steuerung, Entscheidungs-, Risiko- Konfigurations- und Informationsmanagement sowie die Qualitätssicherung. Weiter werden technische Maßnahmen zur Kompensation von Defiziten identifiziert und durchgeführt, beispielsweise hinsichtlich Zeit, Kosten und Qualität der Ergebnisse.
- Vertrags-/Vereinbarungs-Prozesse: In diesem Zusammenhang unterscheidet man den Acquisition Process und den Supply Process. Die damit verbundenen Aktivitäten beziehen sich auf die Vereinbarungen zwischen Kunde und Lieferant des Systems (beziehungsweise der Systemkomponenten) oder der Dienstleistung.
- Organizational Project-Enabling Prozesse: Ziel ist die Bereitstellung der Ressourcen, die zur Erfüllung der Anforderungen der Projekt-Stakeholder notwendig sind. Das sind etwa Qualitätsrichtlinien, Management-Aktivitäten hinsichtlich Lebenszyklus, Infrastruktur, Produktportfolio, Qualitätsmanagement und Wissensmanagement. Damit sind diese Prozesse der Organisation und nicht einzelnen Projekten zugeordnet.
Tailoring hilft weiter
Das Besondere: Die ISO/IEC 15288 definiert einen Tailoring Process, der die Anpassung der Prozesse an die jeweilige Projektsituation ermöglicht – was jedoch in keinem Fall nur ein ‚Weglassen‘ bedeutet, sondern eine Anpassung in Umfang und der formalen Stringenz. Dazu werden zunächst Einflussfaktoren auf das Projekt identifiziert (Komplexität, Risikofaktoren, …), dann erfolgt die Auswahl der je nach Entwicklungsprozess betroffenen Prozesse. Hierfür werden die erwarteten Prozess-Ergebnisse, Aktivitäten und Aufgaben identifiziert, die durchgeführt werden müssen. Unter Berücksichtigung der Projektaspekte wird dann entschieden
- welche Aspekte besondere Berücksichtigung finden und
- welche Prozesse in geringerem Umfang beziehungsweise weniger formal durchgeführt werden.
Prozesse vergleichbar definieren
Ist es sinnvoll, Prozesse vergleichbar zu definieren? Ja! So gelingt es, über komplette Wertschöpfungsketten zu kooperieren ohne große Anlaufschwierigkeiten zu haben. Gleichzeitig wird ja auch definiert, was innerhalb der Prozessschritte passieren soll: Das verhindert unnötige Diskussionen à la „Bei uns aber …“.
Übrigens: iQUAVIS orientiert sich selbstverständlich an diesen Normen!
Mehr über unser Systems-Engineering-Tool iQUAVIS erfahren Sie hier.
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!
