![\"Compliance](\"https:\/\/www.m-q.ch\/wp-content\/uploads\/2021\/02\/Compliance-im-Engineering.jpg\")
<\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
A<\/strong><\/em>ktuell erfolgt dieser Nachweis in den meisten F\u00e4llen manuell, oder plakativer ausgedr\u00fcckt: eine Woche, bevor die Pr\u00fcfer anr\u00fccken, sucht man alle Arten von Dokumentation zusammen oder \u2013 noch schlimmer! \u2013 erstellt die Nachweise im Nachhinein. Im Endeffekt sind hochqualifizierte Automotive-Ingenieure damit besch\u00e4ftigt, seitenlange Excel-Sheets auszuf\u00fcllen. Das ist, gelinde gesagt, nicht besonders wertsch\u00f6pfend.<\/p>\n Compliance sinnvoll umgesetzt<\/strong><\/p>\n <\/p>\n Diese ineffiziente Vorgehensweise ist unter anderem darauf zur\u00fcckzuf\u00fchren, dass im Rahmen von Automotive SPICE \u00ae- oder CMMI-Programmen die Prozesse nicht immer praxisnah festgelegt werden. In viel zu vielen F\u00e4llen erfolgt die Prozessdefinition durch Berater. Sie \u00abverschreiben\u00bb einem Unternehmen bestimmte Prozesse, ohne darauf R\u00fccksicht zu nehmen, ob diese Prozesse an den Gesch\u00e4ftszielen oder generell den Realit\u00e4ten<\/p>\n <\/p>\n Prozesse ohne Praxisbezug<\/strong><\/em><\/p>\n <\/p>\n des Unternehmens ausgerichtet sind. Auch pr\u00fcfen noch immer zu viele Auditoren, Appraiser und Assessoren die Prozesse anhand von Checklisten auf nominelle Konformit\u00e4t zum Standard. Die Folge sind v\u00f6llig unrealistische, ineffektive oder sogar gesch\u00e4ftssch\u00e4dliche Prozessvorgaben, die Entwickler und Ingenieure bestenfalls z\u00e4hneknirschend anwenden oder letztlich ignorieren.<\/p>\n <\/p>\n CMMI-Practices wie \u00abPP SP 2.6: Plan Stakeholder Involvement\u00bb beispielsweise dienen keinem Selbstzweck! Alleine deswegen soll niemand seitenweise Dokumente erstellen, Templates ausf\u00fcllen, Freigaben erteilen und stundenlange Meetings abhalten m\u00fcssen. 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\u00f6nnen diese Personen optimal am Projekt beteiligt werden? Wann soll das geschehen? Kurz gesagt l\u00e4sst sich die Grundidee von Modellen wie Automotive SPICE \u00ae oder CMMI mit dem Satz zusammenfassen: \u00abDenke nach, bevor du handelst.\u00bb<\/p>\n Direkt in der Wertsch\u00f6pfungskette<\/strong><\/p>\n <\/p>\n Viel sinnvoller ist es daher, Erfahrungen aus Luftfahrtindustrie, Bahntechnik und anderen sicherheitskritischen Einsatzgebieten zu nutzen und den ComplianceNachweis direkt in die Wertsch\u00f6pfungskette der Entwicklung (Analyse, Entwurf, Implementierung, Integration, Test) einzubauen. Sind bestimmte Aktivit\u00e4ten nicht wertsch\u00f6pfend, sollte man sie umgehend eliminieren. Allerdings darf man bei der Wertsch\u00f6pfung nicht nur den kurzfristigen Projektnutzen in Betracht ziehen. Vielmehr sollten zum Beispiel folgende Wertsteigerungen einkalkuliert werden:<\/p>\n <\/p>\n Um dieses Ziel zu erreichen, nutzt man die Traceability-Konzepte, wie man sie aus dem Anforderungsmanagement kennt, das heisst die Nachverfolgbarkeit einer Anforderung \u00fcber 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.<\/p>\n Akzeptanz durch Einsicht<\/strong><\/p>\n <\/p>\n Konkret werden die Normen in ihre einzelnen Anforderungen zerlegt, die auf die jeweiligen Elemente der Standardprozess-Beschreibung abgebildet werden. So wird eine Anforderung \u00ab6-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\u00bb aus der ISO 26262 beispielsweise auf die Prozessschritte \u00abElaborate Requirements\u00bb, \u00abValidate requirements\u00bb und das \u00abSoftware Requirements\u00bb- Arbeitsprodukt abgebildet.<\/p>\n <\/p>\n Grafik 1 l\u00e4sst sich f\u00fcr Gap-Analysen in beiden Richtungen nutzen:<\/p>\n <\/p>\n \u00dcbersch\u00fcssiger\u00abProzessm\u00fcll\u00bb<\/strong><\/em><\/p>\n <\/p>\n gabe: Gibt es f\u00fcr jeden Prozessschritt eine Begr\u00fcndung methodischer, technischer, normativer oder gesch\u00e4ftlicher Art? Auf diese Weise k\u00f6nnen \u00fcberfl\u00fcssige Schritte (\u00abWaste\u00bb im Sinne von LEAN oder einfach nur \u00fcbersch\u00fcssiger \u00abProzessm\u00fcll\u00bb) identifiziert und eliminiert werden.<\/p>\n <\/p>\n Akzeptanz entsteht durch rationale und emotionale Einsicht \u2013 eine in der Psychologie weit verbreitete Erkenntnis. Ziel ist es daher, eine durchg\u00e4ngige Argumentationskette von den einzelnen Normanforderungen bis hin zu den einzelnen Entwicklungsschritten aufzuzeigen. Damit wird f\u00fcr den Endanwender transparent, warum bestimmte Schritte durchgef\u00fchrt werden m\u00fcssen. Diese Transparenz sorgt f\u00fcr mehr Verst\u00e4ndnis und f\u00fchrt letztlich zu einer erh\u00f6hten Prozessakzeptanz. Jeder Mensch kann Vorgaben und Vorschriften viel eher nachvollziehen und befolgen, wenn ihm die Gr\u00fcnde f\u00fcr die jeweiligen Massnahmen klar dargelegt und verst\u00e4ndlich gemacht werden. Dieses Verfahren ist parallel auf mehrere Normen oder Standards anwendbar. Beispiele f\u00fcr derartige Kombinationen sind<\/p>\n <\/p>\n Der Aufwand l\u00e4sst 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 \u00dcberschneidungen der Vorgaben eliminieren und einheitlich in den Prozessen umsetzen. Dieser Ansatz wurde bereits erfolgreich f\u00fcr die Modelle SPICE und CMMI sowie f\u00fcr die Normen zur Entwicklung von Medizinprodukten umgesetzt. Die Anzahl der einzelnen<\/p>\n <\/p>\n Schritte transparent machen<\/strong><\/em><\/p>\n <\/p>\n Normforderungen konnte dabei um \u00fcber 75 Prozent reduziert werden.<\/p>\n <\/p>\n 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 \u2013 so sinnvoll sie auch ist \u2013 immer nur ein erster Schritt sein. F\u00fcr wirkliche Verbesserungen im Entwickleralltag ist es entscheidend, dass jeder definierte Prozessschritt auch wirklich sinnvoll ist und praktisch umgesetzt wird.<\/p>\n Konkrete Prozesse durch Tailoring<\/strong><\/p>\n <\/p>\n F\u00fcr den Endanwender ist es wichtig, dass die Prozesse m\u00f6glichst konkret und f\u00fcr seinen Einsatzzweck geeignet sind. Es liegt aber in der Natur der Sache, dass standardisierte Prozesse zwangsl\u00e4ufig abstrakt und damit in den seltensten F\u00e4llen wirklich pr\u00e4gnant genug sind, um in der t\u00e4glichen Projektpraxis direkt nutzbringend und anwendbar zu sein.<\/p>\n <\/p>\n Jeder, der mehrere Entwicklungsprojekte geleitet oder entscheidend mitgestaltet hat, kann best\u00e4tigen, 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\u00e4ndig dazu, passen sich ver\u00e4nderten Umst\u00e4nden an und setzen neue Technologien gewinnbringend ein. Kein Standardprozess kann dieser Varianz und Ver\u00e4nderungsgeschwindigkeit jemals Rechnung tragen<\/p>\n <\/p>\n \u00dcber Tailoring zu akzeptierten Prozessen<\/strong><\/em><\/p>\n <\/p>\n Es geht also darum, eine abstrakte Standard-Prozessbeschreibung auf den konkreten Projekteinsatz masszuschneidern, das heisst die richtigen Schritte f\u00fcr ein bestimmtes Projekt auszuw\u00e4hlen und im Projektkontext zu detaillieren. Ein Standardprozess gibt etwa vor, dass Anforderungen erfasst, dokumentiert und auf Sinnhaftigkeit und Vollst\u00e4ndigkeit gepr\u00fcft werden m\u00fcssen. Wie dies in einem konkreten Projekt optimal geschehen sollte, h\u00e4ngt sehr stark vom Kontext ab.<\/p>\n <\/p>\n In einer sicherheitskritischen Umgebung, wie etwa einem Automobil, m\u00fcssen diese Anforderungen im Normalfall strukturiert erfasst, in einem Anforderungsmanagement-System dokumentiert und durch Verifikation und Validierung gepr\u00fcft werden. Die ISO 26262 macht hier eine Reihe klarer Vorgaben: Zum Beispiel m\u00fcssen alle technischen Sicherheitsanforderungen auf \u00dcbereinstimmung und Konsistenz mit dem funktionalen Sicherheitskonzept und den vorl\u00e4ufigen Architekturannahmen gepr\u00fcft werden (ISO 26262:2011 4-6.4.6.1). Dieser Nachweis l\u00e4sst sich effizient nur durch zumindest semi-automatisierte AnforderungsmanagementSysteme erbringen.<\/p>\n <\/p>\n 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\u00fcfung aller Anforderungen an derartige Systeme w\u00fcrde man v\u00f6llig \u00fcber 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\u00e4sst sich unm\u00f6glich sinnvoll per Excel verwalten, auch wenn viele Unternehmen dies heute noch versuchen, teilweise \u00fcber viele Produktvarianten hinweg<\/p>\n <\/p>\n 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\u00fcfungen direkt in die Umsetzung \u00fcberzugehen.<\/p>\n <\/p>\n Wie wendet man nun abstrakte Standardprozesse in konkreten Projektgegebenheiten an? Die L\u00f6sung lautet: durch Prozesstailoring. Tailoring bedeutet zweierlei:<\/p>\n <\/p>\n Prozesstailoring ist ein weiterer wichtiger Schritt hin zu sinnvollen, konkreten und akzeptierten Prozessen in der Entwicklung. Um aber die gr\u00f6sstm\u00f6gliche Wertsch\u00f6pfung zu erzielen, ist es entscheidend, dass die praktische Umsetzung so effizient wie m\u00f6glich erfolgt.<\/p>\n Effizienz durch Automatisierung<\/strong><\/p>\n <\/p>\n Als letzter Schritt hin zu einer wertsch\u00f6pfenden Prozessorientierung sollten die wichtigsten Prozessschritte daher automatisiert ablaufen. Dies betrifft beispielsweise \u00c4nderungs-, 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\u00e4glich verwenden. Moderne Entwicklungsplattformen lassen sich durch Prozessdefinitionen projektspezifisch konfigurieren oder enthalten Workflow-Engines, die beispielsweise \u00c4nderungsanforderungen verwalten und \u00fcber mehrere Disziplinen hinweg bis zur Umsetzung steuern. Der untere Teil von Grafik 1 zeigt diese Verbindung der Prozess-Ebene mit der Ausf\u00fchrungsEbene.<\/p>\n <\/p>\n Nachweiskette im Hintergrund<\/strong><\/em><\/p>\n <\/p>\n Aus Compliance-Sicht erh\u00e4lt man automatisch eine durchg\u00e4ngige Nachweiskette von den Anforderungen der Standards bis hin zu den konkreten Arbeitsergebnissen. Koppelt man moderne PLM\/ALMWerkzeuge mit entsprechend ausger\u00fcsteten ProzessmanagementSystemen, funktioniert diese Nachweiskette vollst\u00e4ndig ohne Medienbruch oder manuellen Eingriff.<\/p>\n <\/p>\n Damit werden durch die ganz normale Abarbeitung der Prozesse in den Entwicklungsprojekten die Nachweise im Hintergrund gesammelt und k\u00f6nnen bei Bedarf mit einem direkten Bezug zu den Normen und Standards als Report generiert werden. Die Ingenieure sind ausschliesslich wertsch\u00f6pfend t\u00e4tig, die Nachweiserstellung erfolgt automatisch. Selbstverst\u00e4ndlich funktioniert dieser Ansatz auch parallel mit mehreren Standards und Normen. F\u00fchrende Fahrzeughersteller sowie ihre Zulieferer erzielen auf diese Weise Effizienzgewinne, die weit im zweistelligen Prozentbereich liegen.<\/p>\n","protected":false},"excerpt":{"rendered":" Aktuell erfolgt dieser Nachweis in den meisten F\u00e4llen manuell, oder plakativer ausgedr\u00fcckt: eine Woche, bevor die Pr\u00fcfer anr\u00fccken, sucht man alle Arten von Dokumentation zusammen oder \u2013 noch schlimmer! \u2013 erstellt die Nachweise im Nachhinein. Im Endeffekt sind hochqualifizierte Automotive-Ingenieure damit besch\u00e4ftigt, seitenlange Excel-Sheets auszuf\u00fcllen. Das ist, gelinde gesagt, nicht besonders wertsch\u00f6pfend. […]<\/p>\n","protected":false},"author":66,"featured_media":12701,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[4],"tags":[4804],"class_list":["post-12698","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-risikomanagement","tag-9-2013"],"acf":[],"yoast_head":"\n\n
\n
\n
\n