5 Prinzipien guter Prozessdokumentation

Die beste Prozessmodellierung nützt wenig, wenn die Dokumentation danach in einem Ordner verschwindet, den niemand mehr öffnet. Aus zahlreichen Dokumentationsprojekten haben sich fünf Prinzipien herauskristallisiert, die den Unterschied machen.

1. Für die Nutzenden schreiben, nicht für den Auditor

Dokumentation, die primär für ein Audit geschrieben wird, liest sich formal korrekt – und wird im Alltag trotzdem nicht benutzt. Die entscheidende Frage lautet: Kann eine neue Kollegin oder ein neuer Kollege anhand dieses Dokuments den Prozess tatsächlich ausführen? Wenn nicht, ist es für den Alltag wertlos, selbst wenn es auditfest ist.

2. Dort dokumentieren, wo gearbeitet wird

Prozessdokumentation, die in einem separaten System liegt, das im Tagesgeschäft nie geöffnet wird, verliert schnell an Relevanz. Besser: die Dokumentation dort verankern, wo ohnehin gearbeitet wird – im Intranet, im Ticketsystem oder direkt verlinkt aus der Anwendung heraus.

3. Jedes Dokument braucht einen Owner

Ohne benannte Verantwortung für Aktualität verwaist jede Dokumentation über kurz oder lang. Ein Owner pro Prozess, mit einem festen Reviewintervall im Kalender, ist wirksamer als jede noch so ausgefeilte Vorlage.

4. Aktualität vor Vollständigkeit

Eine lückenhafte, aber aktuelle Dokumentation ist wertvoller als ein vollständiges Dokument, das seit zwei Jahren nicht mehr aktualisiert wurde. Im Zweifel lieber weniger Prozesse dokumentieren, dafür aber verlässlich pflegen.

Veraltete Dokumentation ist gefährlicher als gar keine – sie erzeugt falsches Vertrauen.

5. Ein Format, das durchgehalten wird

Der aufwendigste Dokumentationsstandard nützt nichts, wenn er nach drei Prozessen nicht mehr eingehalten wird. Ein einfaches, konsistentes Format – etwa BPMN 2.0 für den Ablauf plus eine kurze Textbeschreibung für Kontext und Ausnahmen – schlägt in der Praxis fast immer die perfekte, aber zu aufwendige Lösung.

Fazit

Gute Prozessdokumentation ist weniger eine Frage des Werkzeugs als der Disziplin: klare Verantwortlichkeit, ein durchhaltbares Format und der Anspruch, tatsächlich benutzt zu werden statt nur zu existieren.

ISMS-Aufbau nach ISO 27001: ein pragmatischer Leitfaden

Warum ein ISMS mehr ist als ein Zertifikat

Viele Unternehmen starten ein ISMS-Projekt, weil ein Kunde es verlangt oder ein Audit ansteht. Das ist ein legitimer Anlass – aber ein ISMS, das nur für diesen einen Termin gebaut wird, verfehlt seinen eigentlichen Zweck. Ein Informationssicherheits-Managementsystem soll Risiken laufend sichtbar machen, nicht einmalig dokumentieren.

Die ersten 100 Tage: was wirklich zählt

Aus eigener Erfahrung beim Aufbau eines ISMS nach ISO 27001 hat sich eine Reihenfolge bewährt, die Frustration vermeidet:

1. Scope festlegen – welche Bereiche, Standorte und Systeme sind tatsächlich im Geltungsbereich?
2. Bestehendes sichtbar machen – die meisten Organisationen haben mehr Kontrollen, als ihnen bewusst ist, nur nicht dokumentiert.
3. Gap-Analyse gegen ISO 27001 – ehrlich, mit klarer Priorisierung statt Vollständigkeitsanspruch am ersten Tag.
4. Rollen benennen – wer ist Informationssicherheitsbeauftragte:r, wer eskaliert im Vorfall?

Risikomanagement ohne Excel-Friedhof

Ein Risikoregister scheitert fast nie an der Methodik, sondern an der Pflege. Die pragmatische Lösung: ein überschaubares Set an Risiken mit klarem Owner und einem festen Reviewtermin, statt einer 300-Zeilen-Tabelle, die nach dem Kickoff nie wieder geöffnet wird.

Ein Risikoregister, das niemand pflegt, ist ein Bild von der Vergangenheit – kein Steuerungsinstrument für die Gegenwart.

TISAX: Besonderheiten gegenüber ISO 27001

TISAX orientiert sich am VDA-ISA-Prüfkatalog und richtet sich speziell an die Automobilbranche und ihre Zulieferer. Wer bereits ein ISMS nach ISO 27001 betreibt, hat die wesentliche Grundlage geschaffen – TISAX verlangt aber zusätzlich einen klaren Fokus auf den Schutz von Prototypen, sensiblen Entwicklungsdaten und die Nachweisführung gegenüber Geschäftspartnern über die ENX-Plattform.

Vom Projekt in den Regelbetrieb

Der Moment, in dem ein ISMS-Projekt endet und der Regelbetrieb beginnt, wird häufig unterschätzt. Ohne feste Reviewzyklen, ein internes Audit-Programm und klare Verantwortlichkeit verliert das System innerhalb weniger Monate an Aktualität. Genau diese Übergabe – inklusive Dokumentation, die auch ohne externe Unterstützung gepflegt werden kann – gehört für mich zum Auftrag dazu, nicht als optionales Extra.

7 typische Fehler bei der BPMN-Modellierung

BPMN 2.0 ist deshalb so wirkungsvoll, weil Fachbereich und IT dieselbe Notation lesen können – vorausgesetzt, sie wird sauber angewendet. In der Praxis sehe ich immer wieder dieselben sieben Fehler, die ein Modell entweder unverständlich oder schlicht falsch machen.

1. Fehlende oder falsche Swimlanes

Swimlanes zeigen, wer für welchen Schritt verantwortlich ist. Werden sie weggelassen „der Übersicht halber“, geht genau die Information verloren, die für die Umsetzung am wichtigsten ist: die Zuständigkeit. Ein Prozess ohne klare Lane-Zuordnung lässt sich später kaum in Rollen und Berechtigungen übersetzen.

2. Gateways ohne eindeutige Bedingung

Ein exklusives Gateway ohne beschriftete Ausgänge ist keine Modellierung, sondern eine Verlegenheitslösung. Jede abzweigende Kante braucht eine Bedingung, die auch jemand ohne Kontextwissen versteht. Sonst wird das Modell im Review zur Ratesession.

3. Falscher Detailgrad

Ein häufiges Extrem: entweder wird jeder Klick in der Anwendung als eigene Aktivität modelliert, oder ein kompletter Vorgang steckt in einer einzigen Box. Beides macht das Modell unbrauchbar. Die Faustregel: eine Aktivität sollte eine fachlich abgeschlossene Handlung einer Person oder eines Systems beschreiben – nicht mehr, nicht weniger.

4. Start- und Endereignisse werden verwechselt

Prozesse mit mehreren möglichen Startpunkten oder ganz ohne definiertes Ende sind in der Praxis erstaunlich häufig. Das Ergebnis: Unklarheit darüber, wann ein Vorgang überhaupt beginnt oder abgeschlossen ist – mit direkten Folgen für Kennzahlen wie Durchlaufzeiten.

5. Unklare Aktivitätsnamen

„Bearbeiten“, „Prüfen“, „Klären“ – solche Aktivitätsnamen sagen nichts über das eigentliche Handeln aus. Besser ist die Konvention Verb + Objekt: „Rechnung prüfen“, „Freigabe erteilen“. Das erzwingt Klarheit schon beim Modellieren.

6. Ausnahmen werden ignoriert

Der Standardfall ist meist schnell modelliert. Der eigentliche Wert eines Prozessmodells zeigt sich aber im Umgang mit Ausnahmen: Was passiert bei Fristüberschreitung, bei fehlender Freigabe, bei einem Systemausfall? Wer diese Pfade weglässt, liefert ein Hochglanzmodell, das an der Realität vorbeigeht.

7. Kein Pflegeprozess nach der Modellierung

Der größte Fehler passiert oft nicht während der Modellierung, sondern danach: Niemand ist dafür zuständig, das Modell aktuell zu halten. Ein Prozessmodell ohne Owner und ohne Reviewzyklus ist nach einem Jahr Makulatur.

Ein BPMN-Modell ist kein Abschlussdokument eines Projekts – es ist eine lebende Beschreibung der Organisation.

Fazit

Die meisten dieser Fehler entstehen nicht aus Unwissen über die Notation, sondern aus Zeitdruck: Modelliert wird für die nächste Präsentation, nicht für den langfristigen Betrieb. Wer BPMN 2.0 von Anfang an als Governance-Instrument versteht statt als Grafik für ein Kickoff-Meeting, vermeidet die meisten dieser Fallstricke automatisch.