Ereignismanagement in Tabellenkalkulationen: Wann es funktioniert und was zuerst bricht

Die meisten Ereignisprotokolle beginnen in einer Tabelle, und das aus gutem Grund. Sie ist schon da, jeder kann sie nutzen, sie braucht keine Beschaffung und kein Projekt, und sie lässt sich an einem Nachmittag an die tatsächliche Arbeitsweise eines Standorts anpassen. Nur sehr wenige speziell entwickelte Systeme können alle vier Punkte für sich beanspruchen.

Die nützliche Frage lautet also nicht, ob Tabellen ein schlechter Weg sind, Ereignisse zu verwalten. Sie lautet, welcher Teil zuerst nachgibt, an welchem Punkt, und was sich in jeder Phase tun lässt, ohne zwingend das Werkzeug zu wechseln.

Wann eine Tabelle noch das richtige Werkzeug ist

Man sollte hier offen sein, denn vieles, was zu diesem Thema geschrieben wird, ist es nicht.

Eine Tabelle bleibt ein taugliches Ereignisprotokoll, wenn alles Folgende zutrifft:

• Ein Standort oder ein Betrieb, klein genug, dass eine Person das ganze Bild im Kopf hat
• Eine Person pflegt die Datei, alle anderen tragen über sie bei
• Ein Aufkommen, das so gering ist, dass zwischen den Überprüfungen nichts vergessen wird
• Korrekturmassnahmen, die innerhalb von Wochen abgeschlossen werden, solange die Beteiligten noch im Amt sind
• Keine Pflicht, einem Dritten kurzfristig Nachweise über die Nachverfolgung vorzulegen

Wenn das Ihren Betrieb beschreibt, ist das Protokoll nicht Ihr Problem, und ein Wechsel macht nichts sicherer. Der Rest dieses Artikels ist trotzdem als Liste von Warnsignalen nützlich, aber es besteht keine Eile.

Was zuerst versagt

Die Ausfälle kommen nicht gleichzeitig. Sie treten in einer ziemlich festen Reihenfolge auf, und wenn Sie erkennen, in welcher Phase Sie sind, wissen Sie, was zu beheben ist.

1. Die Nachverfolgung, noch vor dem Protokoll

Zuerst fällt auf, dass das Protokoll selbst meist korrekt bleibt. Ereignisse werden erfasst, Daten stimmen, Beschreibungen sind angemessen. Was verfällt, ist alles Nachgelagerte: die Korrekturmassnahme, ihr Verantwortlicher, das Fälligkeitsdatum und ob jemand bestätigt hat, dass sie gewirkt hat.

Der Grund ist struktureller, nicht kultureller Art. Eine Tabelle hält Ereignisse gut fest und Verpflichtungen schlecht. Eine Zeile kann festhalten, was passiert ist. Sie kann niemanden nachfassen, und ein Fälligkeitsdatum in einer Zelle ist nur so gut wie die Person, die daran denkt, danach zu sortieren. So wird das Protokoll zu einer genauen Aufzeichnung der Ereignisse und zu einer schlechten Aufzeichnung der Reaktionen, also das Gegenteil dessen, wofür es gedacht ist.

An diesem Punkt merken die meisten Organisationen, dass der Unterschied zählt, meist weil jemand fragt, was aus einem Ereignis von vor acht Monaten geworden ist. Massnahme, ursprüngliches Ereignis und Wirksamkeitsprüfung als einen zusammenhängenden Datensatz zu führen, statt an drei Stellen, die gegeneinander abgeglichen werden müssen, ist das eigentliche Problem, das es zu lösen gilt, und genau so ist ENSURE aufgebaut.

2. Die einzige Kopie

Der zweite Ausfall kommt mit der zweiten Person. Zwei Personen müssen in derselben Woche in die Datei schreiben, oder jemand muss per Telefon melden, während er vor dem Geschehenen steht.

Was folgt, ist bekannt: eine Kopie auf dem Desktop von jemandem, eine Version in einem E-Mail-Verlauf, eine Kopie im gemeinsamen Laufwerk, die aktuell sein kann oder nicht, und eine Phase des Abgleichs, für die niemand Zeit hat. Das Protokoll hört auf, eine einzige Quelle zu sein, und wird zu mehreren Darstellungen desselben Monats.

3. Die Nachweise rund um den Datensatz

Ein Ereignis ist selten nur eine Zeile. Es kommt mit Fotos, einer Zeugenaussage, einem Erlaubnisschein, einer Schichtübergabenotiz, einer medizinischen Akte, manchmal einem Lieferantenbericht.

Nichts davon passt in eine Zelle, also landet es in E-Mails und einem Ordner, mit dem Ereignis über eine Referenznummer und das Gedächtnis von jemandem verbunden. Das funktioniert, solange diese Person da ist. Es überlebt ihren Weggang nicht, und es ist der Teil, der sich danach am schwersten rekonstruieren lässt, weil das Material noch existiert und niemand sicher sagen kann, welche Version damals berücksichtigt wurde. Nachweise an dem Datensatz zu halten, zu dem sie gehören, statt sie in der Nähe abzulegen, macht dies auch Jahre später nachvollziehbar.

4. Der Änderungsverlauf

Der vierte Ausfall ist derjenige, der nach einem schweren Ereignis am meisten zählt, und im Alltag ist er am wenigsten sichtbar.

Die Frage ist nicht, wer die Datei bearbeitet hat. Sie ist enger gefasst: Wer hat die Einstufung der Schwere von «schwer» auf «leicht» geändert, an welchem Datum und mit welcher Begründung? Wer hat das Abschlussdatum verschoben? Wer hat die Massnahme als erledigt markiert, und was hat ihn oder sie davon überzeugt?

Eine Tabelle kann nichts davon im Nachhinein beantworten, und die fehlende Antwort ist nicht neutral. Sie wirkt wie eine Lücke, und zwar genau dann, wenn eine klare Darstellung am wertvollsten ist, ob der Leser nun ein Auditor, ein Versicherer oder eine Untersuchungsbehörde ist.

5. Vergleich, nicht Zählen

Als Letztes bricht die Auswertung weg, und sie bricht leiser als der Rest.

Die meisten Protokolle können eine Zählung liefern. Was sie kaum liefern, ist der Vergleich: diese Schicht gegen jene Schicht, dieser Standort gegen die Gruppe, die Quote an Beinahe-Unfällen in diesem Quartal bereinigt um die Tatsache, dass ein Standort alles meldet und ein anderer fast nichts. Reine Zahlen aus Standorten mit unterschiedlicher Meldekultur sind nahezu bedeutungslos, und der Aufwand, das von Hand zu korrigieren, ist der Grund, warum es selten ein zweites Mal gemacht wird.

Zwei Folgen, die man benennen sollte

Zu wenige Meldungen durch Reibung. Wenn für die Meldung eines kleinen Ereignisses die Datei gesucht, Bearbeitungsrechte angefragt und in eine gemeinsame Tabelle getippt werden muss, werden kleine Ereignisse nicht mehr gemeldet. Schwere Ereignisse kommen immer durch, weil jemand sie eskaliert. Beinahe-Unfälle und Erste-Hilfe-Fälle verschwinden dagegen leise, und genau das sind die Frühindikatoren, auf die das ganze System angewiesen ist. Ein Rückgang bei den gemeldeten Beinahe-Unfällen ist meist zuerst ein Meldeproblem und erst dann eine Verbesserung der Sicherheit.

Die Frage, die sich nicht schnell beantworten lässt. Nach einem schweren Ereignis fragt jemand nach allen ähnlichen Ereignissen der letzten drei Jahre und danach, was jeweils unternommen wurde. Das ist eine berechtigte Frage, und sie aus einer Tabelle, einem Posteingang und einem gemeinsamen Laufwerk zu beantworten, kostet Tage an Arbeit, die sich im Nachhinein kaum rechtfertigen lassen.

Was Sie klären sollten, bevor Sie etwas ändern

Mehrere dieser Probleme lassen sich deutlich verringern, ohne ein System zu kaufen, und es lohnt sich, damit zu beginnen, schon weil sich dann zeigt, welche davon wirklich am Werkzeug liegen.

• Protokoll und Massnahmenliste trennenFühren Sie den Ereigniseintrag als Bericht darüber, was passiert ist, und geben Sie Korrekturmassnahmen eine eigene Liste mit je einer verantwortlichen Person und einem Termin. Der grösste Teil des oben beschriebenen Verfalls entsteht dadurch, dass sich beides eine Zeile teilt.
• Eine Datei, eine verantwortliche Person, alle anderen nur LesezugriffBeiträge kommen über ein Formular oder über die verantwortliche Person. Das ist weniger bequem, beendet aber das Versionsproblem vollständig.
• Eine Ordnerregel einführen und die Referenznummer nutzenEin Ordner pro Ereignis, nach der Referenznummer benannt, mit allen Anlagen. Unspektakulär, aber genau das macht den Eintrag auch nach drei Jahren auffindbar.
• Entscheidungen festhalten, nicht nur ErgebnisseWenn sich die Einstufung der Schwere oder ein Abschlussdatum ändert, ergänzen Sie eine datierte Zeile, wer es geändert hat und warum. Das ist ein schlechter Ersatz für einen echten Änderungsverlauf, aber weit besser als nichts.
• Monatlich und kurz prüfenZwanzig Minuten im Monat für offene Massnahmen erfassen mehr als eine gründliche Jahresprüfung, weil die Beteiligten noch da sind und sich noch erinnern.

Was ISO 45001 tatsächlich verlangt

Die Norm schreibt kein Werkzeug vor, und es lohnt sich, genau zu wissen, was sie verlangt.

Abschnitt 7.5 verlangt, dass dokumentierte Information gelenkt, identifizierbar und auffindbar ist. Abschnitt 10.2 verlangt Nachweise über die Art der Ereignisse, die ergriffenen Massnahmen und die Ergebnisse von Korrekturmassnahmen, einschliesslich ihrer Wirksamkeit. Nichts davon schliesst eine Tabelle aus.

Anzeichen, dass die Schwelle überschritten ist

Eine dieser Schwellen zu überschreiten, ist meist noch handhabbar. Bei dreien gleichzeitig übersteigt der Aufwand, um das Werkzeug herumzuarbeiten, den Aufwand für seinen Ersatz.

• Mehr als ein Standort oder eine Schicht meldet in dasselbe Protokoll
• Mehr als eine Person muss es in derselben Woche aktualisieren
• Korrekturmassnahmen, die länger bestehen als die Person, die sie angestossen hat
• Nachweise, die zusammen mit dem Eintrag aufbewahrt und auf Anfrage vorgelegt werden müssen
• Fragen zu Mustern über mehrere Jahre, kurzfristig gestellt
• Gemeldete Beinahe-Unfälle sinken, obwohl sich sonst nichts geändert hat

Wenn Sie wechseln, wechseln Sie weniger, als Sie denken

Der häufige Fehler ist, die Migration als Archivierungsprojekt zu behandeln. Fünf Jahre Historie werden importiert, das meiste davon unvollständig, und das neue System ist am ersten Tag bereits voller Einträge, denen niemand traut.

Besser ist es, nur offene Punkte zu übernehmen: Ereignisse, die noch abgeklärt werden, und Massnahmen, die noch offen sind. Historische Einträge bleiben dort, wo sie sind, aufbewahrt und auffindbar, mehr verlangt die Norm von ihnen nicht. Das neue System startet dann sauber, und das erste vollständige Jahr darin ist wirklich mit sich selbst vergleichbar.

Ein praktischer Einstieg

Nehmen Sie das zuletzt abgeschlossene Ereignis in Ihrem Protokoll. Versuchen Sie, vier Dinge an einem Ort zusammenzutragen: den Bericht darüber, was passiert ist, die Abklärung, die damals berücksichtigten Nachweise und die Bestätigung, dass die Korrekturmassnahme gewirkt hat.

Wenn das nur wenige Minuten dauert, trägt die jetzige Lösung. Wenn es einen Nachmittag und ein Gespräch mit jemandem braucht, der das Unternehmen verlassen hat, ist das die Antwort, und sie ist nützlicher als jedes allgemeine Argument über Tabellen.