Compliance im Engineering

Aktuell erfolgt dieser Nachweis in den meisten Fällen manuell, oder plakativer ausgedrückt: eine Woche, bevor die Prüfer anrücken, sucht man alle Arten von Dokumentation zusammen oder – noch schlimmer! – erstellt die Nachweise im Nachhinein. Im Endeffekt sind hochqualifizierte Automotive-Ingenieure damit beschäftigt, seitenlange Excel-Sheets auszufüllen. Das ist, gelinde gesagt, nicht besonders wertschöpfend.

Compliance sinnvoll umgesetzt

Diese ineffiziente Vorgehensweise ist unter anderem darauf zurückzuführen, dass im Rahmen von Automotive SPICE ®- oder CMMI-Programmen die Prozesse nicht immer praxisnah festgelegt werden. In viel zu vielen Fällen erfolgt die Prozessdefinition durch Berater. Sie «verschreiben» einem Unternehmen bestimmte Prozesse, ohne darauf Rücksicht zu nehmen, ob diese Prozesse an den Geschäftszielen oder generell den Realitäten

Prozesse ohne Praxisbezug

des Unternehmens ausgerichtet sind. Auch prüfen noch immer zu viele Auditoren, Appraiser und Assessoren die Prozesse anhand von Checklisten auf nominelle Konformität zum Standard. Die Folge sind völlig unrealistische, ineffektive oder sogar geschäftsschädliche Prozessvorgaben, die Entwickler und Ingenieure bestenfalls zähneknirschend anwenden oder letztlich ignorieren.

CMMI-Practices wie «PP SP 2.6: Plan Stakeholder Involvement» beispielsweise dienen keinem Selbstzweck! Alleine deswegen soll niemand seitenweise Dokumente erstellen, Templates ausfüllen, Freigaben erteilen und stundenlange Meetings abhalten müssen. Nein, diese Practice will die Projektbeteiligten schlicht und ergreifend dazu anregen, sich Gedan-ken zu machen: Wer kann zum Erfolg des Projekts beitragen? Wie können diese Personen optimal am Projekt beteiligt werden? Wann soll das geschehen? Kurz gesagt lässt sich die Grundidee von Modellen wie Automotive SPICE ® oder CMMI mit dem Satz zusammenfassen: «Denke nach, bevor du handelst.»

Direkt in der Wertschöpfungskette

Viel sinnvoller ist es daher, Erfahrungen aus Luftfahrtindustrie, Bahntechnik und anderen sicherheitskritischen Einsatzgebieten zu nutzen und den ComplianceNachweis direkt in die Wertschöpfungskette der Entwicklung (Analyse, Entwurf, Implementierung, Integration, Test) einzubauen. Sind bestimmte Aktivitäten nicht wertschöpfend, sollte man sie umgehend eliminieren. Allerdings darf man bei der Wertschöpfung nicht nur den kurzfristigen Projektnutzen in Betracht ziehen. Vielmehr sollten zum Beispiel folgende Wertsteigerungen einkalkuliert werden:

• für das Gesamtunternehmen
• bei einer Wiederverwendung des Prozesses oder der Praktik in anderen Projekten
• durch übertroffene Qualitätserwartungen bei den Kunden
• bei einer erfolgten Freigabe durch TÜV, FDA, benannte Stellen und andere Kontrollinstanzen.

Um dieses Ziel zu erreichen, nutzt man die Traceability-Konzepte, wie man sie aus dem Anforderungsmanagement kennt, das heisst die Nachverfolgbarkeit einer Anforderung über Design, Implementierung und Test hinweg, und wendet sie auf das Management von Prozessen an. Der obere Teil von Grafik 1 zeigt diese Verbindung der Compliance-Ebene mit der ProzessEbene.

Akzeptanz durch Einsicht

Konkret werden die Normen in ihre einzelnen Anforderungen zerlegt, die auf die jeweiligen Elemente der Standardprozess-Beschreibung abgebildet werden. So wird eine Anforderung «6-6.4.1: The software safety requirements shall address each software-based function whose failure could lead to a violation of a technical safety requirement allocated to software» aus der ISO 26262 beispielsweise auf die Prozessschritte «Elaborate Requirements», «Validate requirements» und das «Software Requirements»- Arbeitsprodukt abgebildet.

Grafik 1 lässt sich für Gap-Analysen in beiden Richtungen nutzen:

1. Norm/Standard/Vorgabe → Prozess: Sind alle Normforderungen durch Prozessschritte abgedeckt und praktisch umgesetzt? Hierdurch sichert man ab, dass alle Forderungen von Normen und Standards erfüllt werden, man prüft also den Prozess auf Vollständigkeit.
2. Prozess → Norm/Standard/Vor

Überschüssiger«Prozessmüll»

gabe: Gibt es für jeden Prozessschritt eine Begründung methodischer, technischer, normativer oder geschäftlicher Art? Auf diese Weise können überflüssige Schritte («Waste» im Sinne von LEAN oder einfach nur überschüssiger «Prozessmüll») identifiziert und eliminiert werden.

Akzeptanz entsteht durch rationale und emotionale Einsicht – eine in der Psychologie weit verbreitete Erkenntnis. Ziel ist es daher, eine durchgängige Argumentationskette von den einzelnen Normanforderungen bis hin zu den einzelnen Entwicklungsschritten aufzuzeigen. Damit wird für den Endanwender transparent, warum bestimmte Schritte durchgeführt werden müssen. Diese Transparenz sorgt für mehr Verständnis und führt letztlich zu einer erhöhten Prozessakzeptanz. Jeder Mensch kann Vorgaben und Vorschriften viel eher nachvollziehen und befolgen, wenn ihm die Gründe für die jeweiligen Massnahmen klar dargelegt und verständlich gemacht werden. Dieses Verfahren ist parallel auf mehrere Normen oder Standards anwendbar. Beispiele für derartige Kombinationen sind

• Automotive: ISO 26262, Automotive SPICE ® und ISO TS 16949
• Medical Devices: IEC 62304, ISO 14971, ISO XXX
• Aerospace/Defense: CMMI-DEV, DO-178B/C, DO-254 und AS 9100 C

Der Aufwand lässt sich noch weiter reduzieren, wenn man diese Vorgaben miteinander kombiniert und die Prozesse auf das so entstehende Gesamtmodell abbildet. Auf diese Weise lassen sich auch inhaltliche Überschneidungen der Vorgaben eliminieren und einheitlich in den Prozessen umsetzen. Dieser Ansatz wurde bereits erfolgreich für die Modelle SPICE und CMMI sowie für die Normen zur Entwicklung von Medizinprodukten umgesetzt. Die Anzahl der einzelnen

Schritte transparent machen

Normforderungen konnte dabei um über 75 Prozent reduziert werden.

Allerdings bewegt man sich mit diesen Verfahren immer noch auf der Theorieebene. Viel zu viele Unternehmen bleiben im Prozessmanagement bei der reinen Prozesspublikation stehen oder stecken. Dabei kann eine Visualisierung der Prozesse – so sinnvoll sie auch ist – immer nur ein erster Schritt sein. Für wirkliche Verbesserungen im Entwickleralltag ist es entscheidend, dass jeder definierte Prozessschritt auch wirklich sinnvoll ist und praktisch umgesetzt wird.

Konkrete Prozesse durch Tailoring

Für den Endanwender ist es wichtig, dass die Prozesse möglichst konkret und für seinen Einsatzzweck geeignet sind. Es liegt aber in der Natur der Sache, dass standardisierte Prozesse zwangsläufig abstrakt und damit in den seltensten Fällen wirklich prägnant genug sind, um in der täglichen Projektpraxis direkt nutzbringend und anwendbar zu sein.

Jeder, der mehrere Entwicklungsprojekte geleitet oder entscheidend mitgestaltet hat, kann bestätigen, dass je zwei Entwicklungsprojekte niemals genau nach dem gleichen Prozess ablaufen. Es besteht eine viel zu hohe Varianz beispielsweise in Projektzielen, eingesetzten Technologien, Kundenanforderungen, Organisationsstrukturen oder Erfahrung der Projektbeteiligten. Auch lernen gute Organisationen ständig dazu, passen sich veränderten Umständen an und setzen neue Technologien gewinnbringend ein. Kein Standardprozess kann dieser Varianz und Veränderungsgeschwindigkeit jemals Rechnung tragen

Über Tailoring zu akzeptierten Prozessen

Es geht also darum, eine abstrakte Standard-Prozessbeschreibung auf den konkreten Projekteinsatz masszuschneidern, das heisst die richtigen Schritte für ein bestimmtes Projekt auszuwählen und im Projektkontext zu detaillieren. Ein Standardprozess gibt etwa vor, dass Anforderungen erfasst, dokumentiert und auf Sinnhaftigkeit und Vollständigkeit geprüft werden müssen. Wie dies in einem konkreten Projekt optimal geschehen sollte, hängt sehr stark vom Kontext ab.

In einer sicherheitskritischen Umgebung, wie etwa einem Automobil, müssen diese Anforderungen im Normalfall strukturiert erfasst, in einem Anforderungsmanagement-System dokumentiert und durch Verifikation und Validierung geprüft werden. Die ISO 26262 macht hier eine Reihe klarer Vorgaben: Zum Beispiel müssen alle technischen Sicherheitsanforderungen auf Übereinstimmung und Konsistenz mit dem funktionalen Sicherheitskonzept und den vorläufigen Architekturannahmen geprüft werden (ISO 26262:2011 4-6.4.6.1). Dieser Nachweis lässt sich effizient nur durch zumindest semi-automatisierte AnforderungsmanagementSysteme erbringen.

Nun gibt es aber in jedem Automobil auch Systembereiche, die nicht als sicherheitskritisch eingestuft werden, beispielsweise die meisten Funktionen eines Infotainment-Systems. Mit einer formalen Prüfung aller Anforderungen an derartige Systeme würde man völlig über das Ziel hinausschiessen. Heisst dies, dass man auf das strukturierte Management dieser Anforderungen verzichten kann? Ganz sicher nicht! Anforderungen an Infotainment-Systeme sind sehr umfangreich, nicht selten erreichen komplexe Systeme bis zu tausend Einzelanforderungen. Eine derartige Anzahl von Anforderungen lässt sich unmöglich sinnvoll per Excel verwalten, auch wenn viele Unternehmen dies heute noch versuchen, teilweise über viele Produktvarianten hinweg

In anderen Systembereichen kann es wiederum am effizientesten sein, die Anforderungen mit Use Cases oder weniger strukturiert mit User Stories zu beschreiben und ohne weitere Prüfungen direkt in die Umsetzung überzugehen.

Wie wendet man nun abstrakte Standardprozesse in konkreten Projektgegebenheiten an? Die Lösung lautet: durch Prozesstailoring. Tailoring bedeutet zweierlei:

1. Bekannte Varianzen werden bereits in die Standardprozesse eingebaut und für jedes Projekt wird entschieden, welche Variante konkret zum Einsatz kommt. Dies geschieht in der Regel anhand von Tailoring-Kriterien, wie beispielsweise der Sicherheitseinstufung des Produkts (ASI-Level) oder der Anzahl der Requirements.
2. Unbekannte Varianzen – etwa beim Einsatz völlig neuer Technologien – lassen sich beherrschen, indem man dem Entwicklungsteam höhere Freiheitsgrade bei der Prozessgestaltung einräumt. Im Extremfall definiert das Entwicklungsteam seine Prozesse selbst!

Prozesstailoring ist ein weiterer wichtiger Schritt hin zu sinnvollen, konkreten und akzeptierten Prozessen in der Entwicklung. Um aber die grösstmögliche Wertschöpfung zu erzielen, ist es entscheidend, dass die praktische Umsetzung so effizient wie möglich erfolgt.

Effizienz durch Automatisierung

Als letzter Schritt hin zu einer wertschöpfenden Prozessorientierung sollten die wichtigsten Prozessschritte daher automatisiert ablaufen. Dies betrifft beispielsweise Änderungs-, Build- oder Freigabeprozesse. Hier verwendet man die per Tailoring konkretisierten Prozesse direkt in den PLM/ALMWerkzeugen, die Ingenieure zur Entwicklung von Hardware, Software und Elektronik tagtäglich verwenden. Moderne Entwicklungsplattformen lassen sich durch Prozessdefinitionen projektspezifisch konfigurieren oder enthalten Workflow-Engines, die beispielsweise Änderungsanforderungen verwalten und über mehrere Disziplinen hinweg bis zur Umsetzung steuern. Der untere Teil von Grafik 1 zeigt diese Verbindung der Prozess-Ebene mit der AusführungsEbene.

Nachweiskette im Hintergrund

Aus Compliance-Sicht erhält man automatisch eine durchgängige Nachweiskette von den Anforderungen der Standards bis hin zu den konkreten Arbeitsergebnissen. Koppelt man moderne PLM/ALMWerkzeuge mit entsprechend ausgerüsteten ProzessmanagementSystemen, funktioniert diese Nachweiskette vollständig ohne Medienbruch oder manuellen Eingriff.

Damit werden durch die ganz normale Abarbeitung der Prozesse in den Entwicklungsprojekten die Nachweise im Hintergrund gesammelt und können bei Bedarf mit einem direkten Bezug zu den Normen und Standards als Report generiert werden. Die Ingenieure sind ausschliesslich wertschöpfend tätig, die Nachweiserstellung erfolgt automatisch. Selbstverständlich funktioniert dieser Ansatz auch parallel mit mehreren Standards und Normen. Führende Fahrzeughersteller sowie ihre Zulieferer erzielen auf diese Weise Effizienzgewinne, die weit im zweistelligen Prozentbereich liegen.