Arbeitsprozess der Organisation

Referenzprozess

Version 2.0

Um aus dem P4-Framework mit seinen grundsätzlichen Rollen, Artefakten und Meeting/Events einen „Arbeitsprozess der Organisation“ zu machen, müssen weitere Elemente hinzugefügt werden, insbesondere wenn spezielle Standards und Regularien einzuhalten sind. Dies betrifft besonders die regulierte Entwicklung und Produktion von sicherheitsrelevanten Systemen. Das P4-Framework sieht hierfür Templates für Dokument, Checklisten, DoDs und Standardagenden für Meetings/Events vor.

Durch sogn. „Process Mapping“ kann das P4-Framework mehrere Prozessnormen und Standards gleichzeitig erfüllen, ohne die Komplexität auf der Arbeitsebene zu erhöhen.

Wir erreichen dies durch

  • die Trennung der Prozessanforderungen vom Arbeitsprozess durch Process Mapping mit integrierter Traceability,
  • die Integration der benötigten Elemente in den Arbeitsprozess an den richtigen Stellen und
  • weitgehende Automatisierung und Nutzung von KI.

1. Grundsätze (Policies), Umfang und Gültigkeit

Dieser Abschnitt beschreibt, welche Arten von Prozessnormen, welche Normen und Standards und in welche Ausgabe für die Definition des Arbeitsprozesses der Organisation [Name der Organisation] relevant sind, sowie nach welchen Regeln der Arbeitsprozess in welchem Schärfegrad anzuwenden ist. Das P4-Framework sieht hierbei explizit vor, dass mehrere Versionen des Arbeitsprozesses parallel gültig sein können. Diese Versionen durchlaufen einen Lebenszyklus von „Vorgeschlagen“, „In Arbeit“, „gültig“ bis „zurückgezogen“.

Versionen bestehen aus Hauptversion.Unterversion.Korrektur (Major.Minor.Fix).

  • Hauptversion: Größer, strukturelle Änderungen.
  • Unterversion: Kleinere inhaltliche Anpassungen ohne strukturelle Änderungen.
  • Korrektur: Anpassungen aufgrund von Fehlern; Kleine Ergänzungen und Umformulierungen, um Missverständnisse auszuschließen.

Für neue Produkte wird die Anwendung der jeweils neuesten gültigen Hauptversion empfohlen. Während der Produktentwicklung wird nur in Ausnahmefällen auf eine neuere Hauptversion migriert, da größere Änderungen an vielen Dokumenten zu erwarten sind.

1.1 Kontinuierliche Verbesserung

1.2 Erklärung der Anwendbarkeit (Statement of Applicability) und Geltungsbereich

Liste der möglichen anzuwendenden Prozessnormen und Standards (für einen für Europa produzierendes Unternehmen):

  • Qualitätsmanagement: ISO 9001, ISO 13485 (Medizin), IATF 16949 (Automotive), EN 9100 (Avionik)
  • Umweltschutz: ISO 14001
  • Security: ISO 27001, IEC 62443 (Produktsicherheit), TISAX (Automotive)
  • Produktsicherheit: IEC 61508 , IEC 60601 (Medizin), ISO 26262 (Automotive), DO 178 (Avionik), EN 50126ff (Bahn)
  • Prozessreifegrad: CMMI, SPICE, ASPICE

1.3 Risikobasierter Ansatz

Die Einführung von Prozess-Standards und Arbeitsprozesselementen erfolgt risikobasiert, d.h. das oberste Management (OMC) definiert Regeln, nach denen (Prozess-)Risiken bewertet werden, und Schwellwerte, unterhalb derer risikomindernde Prozesselemente nicht durchgeführt werden müssen.

2. Dokumentation des Managementsystems

Das P4-Framework sieht vor, dass alle Prozessdokumente maschinenlesbar in einem (Git-)Repository abgelegt werden. Hierbei wird der Docs-as-code-Gedanke weitergeführt zu Process-as-code (PaC). Dabei kommen als Formate und Tools Markdown, AsciiDoc, LaTeX oder ähnliche, sowie YAML und JSON zum Einsatz. Aus diesen werden die Prozessdokumentationen generiert (z.B. PDF, HTML).

2.1 Prozess-Effektivität, Nachweise & Audits, Automatisierung

Für Nachweise und Audits werden sogenannte Mapping-Tabellen erstellt, die die Anforderungen aus den relevanten Prozess-Standards (siehe unter 1.) auf den Arbeitsprozess abbilden und diese verlinken. Auf diese Weise wird sichergestellt, dass alle Anforderungen der Prozess-Standards effektiv erfüllt werden, die Arbeitsprozess aber schlank und effizient bleiben. Die Mapping-Tabellen sind damit integraler Bestandteil der Nachweiskette zur Normenkonformität. Interne Audits können entlang der Nachweiskette halbautomatisch durchgeführt werden.

Durch einen größtmöglichen Grad der Automatisierung (siehe 2.4) von Prozessschritten fallen nur wenige menschliche Tätigkeiten an. Prozessschritte können dadurch nicht vergessen werden. Menschen werden entlastet. Eine ebenfalls automatische Prüfung der Ergebnisse stellt sicher, dass die Automatismen nicht fehlschlagen. Zusätzlich werden die Ergebnisse ständig auf Dashboards transparent gemacht. Änderungen an der Automatisierung werden durch Positiv- und Negativtests verifiziert und von Menschen validiert und freigegeben.

2.2 Dokumentation, Feedback, Verbesserung, Freigabe, Schulung

Der Arbeitsprozess wird innerhalb der Team-, Cluster- und Organisations-Retrospektiven in einem festen Rythmus (Cluster-Retrospektive, vierteljährig) begutachtet, sowie Verbesserungen vorgeschlagen, dokumentiert und durch die entsprechende TSMG in den Clustern und Teams geschult und eingeführt. Wir verfolgend hier den empfohlenen PDCA-Zyklus. Prozessverbesserungen werden dabei im Improvement-Backlog der betroffenen Cluster und Teams festgehalten und geplant.

2.3 Zuständigkeit und Delegation

Die oberste Zuständigkeit (Autorität) für die Arbeitsprozesse hat der Managementkreis der Organisation (OMC), vertreten durch den Organisation Scrum Master. Dieser deligiert die Definition der Cluster-spezifischen Prozesselemente an die jeweiligen CSM. Die Notwendigkeit, die Effektivität und Effizienz der Arbeitsprozesse wird kontinuierlich durch die CSMG reviewed. Mindestens einmal pro Jahr werden die Änderungen durch das OMC gesichtet und genehmigt.

Validierung von Prozessen

[tbd]

2.4 Software-Werkzeuge

  1. Software-Werkzeuge haben einen eindeutigen Zweck. Jedes einzelne Software-Werkzeug ist so gestaltet, dass es von einem Skript aufrufbar ist.
  2. Für die Automatisierung von Prozessschritten und das Generieren von Dokumenten eingesetze Software-Werkzeuge unterliegen der Versionskontrolle und werden bei jeder Änderung durch Tests verifiziert und durch Anwendungsszenarien validiert.
  3. Software-Werkzeuge sind von den Eingangsformaten rückwärtskompatibel.
  4. Software-Werkzeuge sollen sich möglichst selten ändern.
  5. Es ist möglich und sinnvoll, mehrere Software-Werkzeuge für die menschliche Bedienung innerhalb einer Oberfläche zu integrieren.

Validierung von Werkzeugen

Prozesse und Prozessbereiche

  • Prozessmanagement: Wie werden Prozesse angelegt, geschult, eingeführt und verbessert.
    • Glossar
    • Performance Monitoring
    • Improvement
    • Training
  • IT und Datenmanagement: Wie werden Software-Tools ausgesucht, eingeführt und verbessert? Wie werden Daten gesichert und wiederhergestellt?
  • Risikomangement: Wie geht die Organsation mit Risiken um.
  • Produktentwicklung: Der Lebenszyklus eines Produkts. Wie werden Produkte definiert, geplant, entwickelt, getestet, freigegeben, gewartet und zurückgezogen.
    • RE, Solutions Design, Integration, V&V
    • Konfigurations- und Change-Management
    • Feedback, Analyse, Problembehebung, Wartung
    • End-of-life
  • Lieferantenmangement: Wie werden Lieferanten ausgesucht und mit ihnen gearbeitet? Wie werden Zulieferungen eingekauft und die Qualität sichergestellt?
    • Selektion
    • QM
  • Produktion: Wie werden Produkte produziert und deren Qualität sichergestellt?
  • Vertrieb
  • Reklamationen und Rückläufer
  • Service

Compliance in Operations (ISO 37301)

  • Sicherheit der Mitarbeiter
  • Gleichstellung & Diverstät
  • Wie wird die Compliance anderer ISO-Standards sichergestellt (z.B. ISO 9001, ISO 14001, ISO 50001)