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 reguierte Entwicklung und Produktion von sicherheitsrelevanten Systemen. Das P4-Framework sieht hierfür Templates für DoDs und Standardagenden für Meeting/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 von dem Arbeitsprozess durch das Process Mapping mit integraler Traceability,
  • die Integration der benötigten Elemente in den Arbeitsprozess an den richtigen Stellen und
  • weitgehende Automatisierung.

1. Policies, Umfang und Gültigkeit

Dieser Abschnitt beschreibt, 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 ín welchem Schärfegrad anzuwenden ist. Das P4-Framework sieht hierbei explizit vor, dass mehrere Versionen des Arbeistprozesses 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 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 Prozesselemente nicht eingeführt und durchgeführt werden müssen.

2. Dokumentation des Qualitätsmanagementsystems

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. Dabei kommen als Formate und Tools Markdown, AsciiDoc, LaTeX oder ähnliche zum Einsatz. Aus diesen werden die Prozessdokumentationen generiert (z.B. PDF, HTLM).

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

Für Nachweise und Audits werden sogenannte Mapping-Tabellen erstellt, die die Anforderungen aus den relventen Prozess-Standards auf den Arbeitsprozess abbilden und diese verlinken. Auf diese Weise wird sichergestellt, dass alle Anforderungen der Prorozess-Standards effektiv erfüllt werden, die Arbeitsprozess aber schlank und effizient bleiben. Die Mapping-Tabellen sind damit integraler Bestandteil des Arbeitsprozesses zum Nachweis der Normenkonformität. Audits können halbautomatisch druchgefü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 ebenfalss automatische Prüfung der Ergebnisse stellt sicher, dass die Automatismen nicht fehlschlagen. Die Ergebnisse werden ständig auf Dashboards transparent gemacht. Änderungen an der Automatisierung werden durch Positiv- und Negativtests verfiziert und von Menschen validiert und freigegeben.

2.2 Dokumentation, Feedback, Aktualisierung, Freigabe, Schulung

Der Arbeitsprozess wird innerhalb der Team-, Cluster- und Organisations-Retrospektiven in einem festen Rythmus (Cluster-Cycle-Retrospektive, vierteljährig) begutachtet, sowie Verbesserungen vorgeschlagen, dokumentiert und durch die entsprechende C/TSMG in den Clustern und Teams geschult und eingeführt. 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-spezifiischen Prozesselemente an den CSM. Mindestens einmal pro Jahr wird die Effektivität und Effizienz der Arbeitsprozesse durch das OMC reviewed.

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.