Die soziale Funktion von Prozessen: Legitimation von Handlungen

Die üblichen Vorteile von Qualitäts- und Prozessmanagement lesen sich wie der Wunschzettel eines Managers. Eine ISO9001-Beratung listet auf:[1]

Bei A-SPICE und ISO26262 ist noch zu ergänzen: Komplexität beherrschen, Fehler früh erkennen, Risiko und Kosten reduzieren. Klingt alles gut, ist aber umstritten.[2][3] Darauf will ich hier nicht hinaus. Denn Prozesse und Normen leisten weit mehr: Sie erfüllen eine soziale Funktion. Sie verlagern die Beweislast.

In einem Projekt stießen wir auf einen dubiosen Fehler: Unter bestimmten Konstellationen hätte ein sicherheitskritischer Sensor einen Fehler unterschlagen. Nach gründlicher Analyse stuften wir ihn als „unabhängigen Mehrfachfehler“ und damit als „sicher“ ein. Unsere Argumentation stützte sich auf Bayes-Schätzer, Fehlerbäume und Felddaten.

Doch beim Review mit der höchsten Qualitätsinstanz und den Juristen kam sofort die Frage: „Auf welcher Norm beruht diese Einschätzung?“ Ich rechnete schon mit sinnlosem Prozessgehampel. Dann fiel mir Luhmann ein. Unsicherheitsabsorption. Ich zeigte den folgenden Passus der ISO26262:[4]

Zustimmendes Nicken. Feinschliff am Wording. Entscheidung verabschiedet. Unsere Argumentation war unverändert, aber etwas hatte sich verschoben: Wir mussten uns nicht mehr rechtfertigen. Der Normverweis übernahm die Legitimation unserer Arbeit. Wie kommt das?

Bei Punkt 2 helfen Prozesse. Sie erzeugen eine „Unsicherheitsabsorption“: [6][2] Denn auch in standardisierten Abläufen gibt es immer Abweichungen. Würden wir jede einzeln betrachten, wären wir paralysiert. Prozesse sind etwas generischer. Sie lassen gewisse Unschärfen zu und erleichtern so die Legitimation. 

Wer sich prozesskonform verhält, muss sich selten rechtfertigen.

Prozesse absorbieren Unsicherheit, weil sie strukturiertes Problemlösungswissen enthalten. Ein Beispiel aus meinem Alltag: Für die Jahresabschlüsse meiner GmbHs nutze ich einen Prozess, der teilautomatisiert Steuererklärungen, eBilanzen, Kalkulationen und Checklisten erzeugt. Aufwand: etwa eine Stunde je GmbH.

Anfangs war das anders: Die Abschlusskosten waren zu hoch. Also begann ich, die Berechnungen mit Excel selbst zu verstehen. Ich rechnete einen Abschluss manuell durch, berücksichtigte Wahlrechte, Rückstellungen, Ansatzregeln. Dieses Wissen war in den Excelformeln eingeschrieben. Die Ergebnisse prüfte ich mit der Steuerberaterin. Das Problem war gelöst.

Dann habe ich daraus einen Prozess gemacht: Inputs erfassen, Sonderfälle abfangen, Outputs generieren, Berechnungen und Ergebnisse prüfen.

Prozesse reproduzieren verifiziertes Problemlösungswissen. Dadurch ermöglichen sie Unsicherheitsabsorption.

Die nächste Ausbaustufe ist das Automatisieren. Ziel: Knopf drücken, fertig. „Automate the Boring Stuff.“[7]

Eine der wichtigsten, vielleicht die wichtigste Führungsaufgabe besteht darin, Sicherheit zu schaffen. Was tun wir in dieser konkreten Situation? Drohen Sanktionen oder Nachteile, wenn wir handeln?

Statt jede Entscheidung neu auszuhandeln, schaffen Prozesse Leitplanken:

• Einzelpersonen legitimieren ihr Handeln über Prozesse der Organisation.
• Organisationen legitimieren ihre Prozesse über Normen und Vorschriften.

Der Mechanismus dahinter wird durch folgendes Beispiel klarer: Laugenbrezel vom Bäcker kaufen. Niemand diskutiert dabei den Wert des Euros (bei niedriger Inflation). Das Eurostück trägt die Verhandlung inhärent in sich.[8] Analog bei Prozessen:

Bei prozesskonformen Verhalten werden Verhandlungen der Ergebnisse extrem verkürzt.

Deshalb nutzen performante Teams maßgeschneiderte Prozesse. Sie müssen nicht jedes Ergebnis einzeln aushandeln. Sie müssen aber zeitgemäß sein. Welches Problem löst der Prozess heute? So klar ist das nicht immer. Vor allem nicht im Engineering. Wir arbeiten streng genommen mit Meta-Prozessen.

Engineering-Prozesse sind oft so generisch wie dieses Beispiel aus A-SPICE:[9]

Offensichtlich widersprechen diese Base Practices meiner Definition von Prozess: Sie enthalten keine spezifische Problemlösung. Die entsteht ja gerade erst.

Engineering-Prozesse sind Meta-Prozesse. So wie Meta-Kommunikation das Sprechen über Kommunikation ist, geht es hier um das Sprechen über das Problemlösen. Nur: A-SPICE, ISO26262 und Projektmanagementstandards drehen sich nicht um das Problemlösen, sondern um das Erkennen von Abweichungen.

Genau darin liegt meine Kritik an diesen Standards: Was sie eigentlich schützen sollten – Problemlösen, Erkenntnis, Lernen, Transformation – erwähnen sie mit keiner Silbe. Stattdessen regeln sie Reviews, Freigaben, Nachverfolgbarkeit. Fraglos wichtig; klingt aber mehr nach Controlling als nach Schöpferischer Zerstörung.[10]

Dennoch müssen wir beides tun: Lösungen schaffen und sie sozial legitimieren. Meine pragmatische Empfehlung:

1. Erarbeite und verifiziere technische Lösungen
2. Beleuchte ihre Entstehung im Lichte der relevanten Prozesse und Normen

Schritt 2 gelingt schlicht dadurch, dass wir die Ergebnisse prozesskonform speichern und sauber verlinken („Traceability“). Zum Beispiel: Anforderungen, Reviews, Bugs und Tasks in Codebeamer, Code im Git, Tests in Tessy, Konstruktionen in CATIA, Schaltungen in eCAD, Risikoanalysen in APIS…

Engineering-Prozesse als Meta-Prozesse können – gerade wegen ihrer Abstraktheit – auch ganz neue Problemlösungen legitimieren.

Und ja: Wer agilkonform erst codiert, später seine Architekturschulden aufräumt und am Ende testgetrieben nachweist, dass alles funktioniert – bitte. Der Punkt für Führungskräfte: Gebt den Teams diese Freiheit. Und legitimiert sie z. B. über Cookbooks.

Tipp: In Spezialfällen wie Sicherheitsnachweis, Risikoanalyse, 8D-Bericht oder Verifikationsreview ist es oft hilfreich, Normenkonformität explizit zu zeigen.
Dafür hat sich bei mir der „vereinfachte Gutachtenstil“ bewährt – siehe letzter Abschnitt.

Ich bin Verfechter guter Prozesse. Aber Prozessgehampel erzeugt bei mir Apathie. Damit meine ich Vorgaben, die weder eine verifizierte Problemlösung noch Meta-Prozesse sind.

Beispiel aus dem Alltag: Beim Arzt müssen wir Datenschutz- und Abrechnungsformulare ausfüllen, obwohl alle relevanten Informationen längst auf der Chipkarte stehen. Durch konkludentes Verhalten im Form beim Betreten des Behandlungsraumes stimmen wir beidem auch noch zu. So mein pragmatisches Rechtsverständnis. Die Formularform ist reines Ärgernis.

Ein häufiges Ärgernis ist auch die FMEA. Ich kann nicht mehr zählen, wie oft wir die nur wegen ISO9001 und ISO26262 befüllt haben. Beide Normen fordern Risikoanalysen. Fehlervermeidung, -erkennung und -behandlung sind heute im Design verankert und werden durch Tests abgesichert. In solchen Fällen ist die FMEA redundant; oder schlimmer: inkonsistent. Erkläre aber mal einem Richter, warum man die Urpraktik „FMEA“ nicht gemacht hat. Also macht man sie …

Triggerwarnung – zu viel Pragmatismus: Schleierhaft sind mir auch viele unternehmensinterne Engineering-Prozess- und Methodenhandbücher. Dort werden Prozesse aus A-SPICE, ISO 26262 oder Methoden aus S(W)EBOK dokumentiert. Aber es sind Meta-Prozesse! Die sind per definitionem abstrakt. In 97,5 % der Fälle heißt das: copy, paste, leicht umformuliert. Irgendwer hat das mal als Bullshit-Arbeit bezeichnet.[11] Eine Tabelle im Projekthandbuch mit Rollen, Tools und Zuständigkeiten tut es vom Sachverhalt genauso gut. Wer tatsächlich mehr wissen will, liest dann direkt in den offiziellen Normen und Handbüchern.

Meine Kritik an gängigen Qualitäts- und Prozessmanagementstandards ist, dass sie in ihrer praktischen Konsequenz die Prozessdokumentation über alles stellen. Das werfe ich nicht den Anwendern vor (Stichwort: „falsch umgesetzt“). Der gemeinsame Nenner unzähliger Organisationen mit diesem Problem ist der Standard. Den hat ein Gremium oder eine Arbeitsgruppe im genau jenem Controllingduktus freigegeben …

Motiviert durch mein Eureka-Moment in der QM-Diskussion habe ich einen „vereinfachten Gutachtenstil“[12] adaptiert, der gezielt Getanes mit Normen und Standards verknüpft. Das soll die Legitimation erleichtern.

Das Schöne: Man kann das auch verschachteln. Zum Beispiel beim obigen Sensorfall:

1. Obersatz: Kann der Sensorfehler X zu unzulässig hohem Risiko des Sicherheitsziels A führen?
2. Definition: Dafür müsste eine Verkettung abhängiger Einfachfehler eintreten.
   1. Obersatz: Wann sind Einfachfehler abhängig?
   2. Definition: ISO26262-2 3.78 und 3.30: „… unabhängige Fehler sind statistisch unabhängig“. Also: P(A ∩ B ∩ C) = P(A) ⋅ P(B) ⋅ P(C)
   3. Subsumtion: Grafik: Fehlerbaum mit Bayes-Wahrscheinlichkeiten aus Felddaten.
   4. Konklusion: Die Einfachfehler sind unabhängig.
3. Subsumtion: UML-Diagramme mit Fehlerketten und Sicherheitsmechanismen.
4. Konklusion: Der Sensorfehler ergibt sich aus einer Verkettung unabhängiger Einzelfehler. Er kann deshalb als sicher eingestuft werden. Ein unzulässig hohes Risiko für Sicherheitsziel A liegt nicht vor.

Diese kompakte Formulierung leistet mir im Projektalltag gute Dienste und passt in den Anhang von Berichten. Und: Techniker wie Nicht-Techniker fühlen sich abgeholt. Was denken Sie? Gerne in den Kommentaren.

— Ihr, Nico Litschke

1. ↑ Im Internet: https://qualitaetsmanagement.me/qualitaetsmanagement-iso-9001/iso-9001-anforderungen/
2. ↑ Kühl, S. (2011). Organisationen: eine sehr kurze Einführung (1. Aufl.). Wiesbaden: Springer VS.
3. ↑ Sprenger, R. K. (2015). Das Prinzip Selbstverantwortung. Wege zur Motivation. Frankfurt am Main: Campus Verlag.
4. ↑ International Organization for Standardization. (2018). ISO 26262 Road Vehicles – Functional Safety – Part 1: Vocabulary (ISO 26262-1:2018, 2nd Ed.).
5. ↑ Luhmann spricht von Variation und Selektion von Sinnmöglichkeiten mit anschließender Retention im sozialen System.[6]
6. ↑ Luhmann, N. (1991). Soziale Systeme: Grundriss einer allgemeinen Theorie (4. Aufl.). Frankfurt am Main: Suhrkamp.
7. ↑ Sweigart, A. (2015). Automate the Boring Stuff with Python. Practical Programming for Total Beginners. San Francisco: No Starch Press.
8. ↑ Geld und Wahrheit sind so genannte „symbolisch-generalisierte Medien“. Sie ersetzen aufwändige Kommunikationen.[6]
9. ↑ VDA QMC Working Group 13 / Automotive SIG. (2017). Automotive SPICE Process Assessment / Reference Model (Version PAM 4.0).
10. ↑ Schumpeter, J. (1987). Theorie der wirtschaftlichen Entwicklung: Eine Untersuchung über Unternehmergewinn, Kapital, Kredit, Zins und den Konjunkturzyklus (7. Aufl.). Berlin: Duncker & Humblot.
11. ↑ Graeber, D. (2019). Bullshit Jobs: Vom wahren Sinn der. Stuttgart: Klett-Cotta.
12. ↑ Wikipedia-Autoren. (2025). Juristische Fallbearbeitung. In Wikipedia – Die freie Enzyklopädie. Im Internet, Stand 01.08.2025: https://de.wikipedia.org/w/index.php?title=Juristische_Fallbearbeitung&oldid=254346962