Thema 10.3 — Wissensmanagement und Dokumentation

In einem Satz: In einem sicherheitskritischen Dienst ist das, was Ihre Teams wissen, aber nie aufgeschrieben haben, ein klinisches Risiko und nicht bloß eine Unannehmlichkeit – behandeln Sie Dokumentation daher als erstklassigen Liefergegenstand und Wissenskontinuität als Pflicht, nicht als Nettigkeit.

Warum das in Gesundheit und Pflege wichtig ist#

Digitale Gesundheitsteams sind klein, spezialisiert und oft aus festangestellten Mitarbeitenden, Vertragskräften und Ingenieuren von Lieferanten zusammengesetzt. Die Person, die versteht, warum die Schnittstelle zur Pathologie dreimal wiederholt, bevor sie fehlschlägt, oder welches Flag in der elektronischen Patientenakte einen doppelten Allergiealarm unterdrückt, ist häufig ein einzelner Mensch – und dieser Mensch wechselt die Stelle, geht in Rente oder ist in der Woche krank, in der um 2 Uhr nachts die Integration ausfällt. Wenn das Wissen mit ihnen geht, wird das System nicht bloß schwerer zu warten; es wird schwerer sicher zu betreiben. Eine undokumentierte Behelfslösung, auf die sich eine Klinikerin verließ, kann still verschwinden, und niemand, der bleibt, weiß, dass sie tragend war.

Der Einsatz ist sektorspezifisch. Eine missverstandene Konfiguration kann eine Akte der falschen Patientin, einen verpassten Alarm oder eine defekte Überweisung erzeugen – Schäden, die an Patientenergebnissen gemessen werden, nicht an Ausfall-Tickets. Öffentliche Stellen tragen außerdem gesetzliche Pflichten: Gesundheitsakten müssen für definierte Zeiträume aufbewahrt werden, und Entscheidungen über Versorgung und öffentliches Geld müssen Jahre später prüfbar und auffindbar sein, wenn ein Coroner, eine Aufsichtsbehörde oder eine Anfrage nach dem Freedom of Information Act anklopft. Gutes Wissensmanagement ist daher teils klinische Sicherheit, teils Governance und teils Respekt vor der nächsten Person, die den Dienst am Laufen halten muss. Es ist untrennbar davon, wie Sie den Live-Betrieb führen (siehe Thema 3.8 — Servicemanagement und Live-Betrieb) und wie Sie Teams gestalten (siehe Thema 7.0 — Teamstrukturen, Rollen und Verantwortlichkeiten).

Kernkonzepte#

Wissensmanagement als Disziplin. Wissensmanagement ist die Gesamtheit der Praktiken, mit denen eine Organisation das, was sie weiß, erzeugt, erfasst, teilt und wiederverwendet. Es balanciert drei Komponenten – Menschen und Kultur, Prozesse und Struktur sowie Technologie – und scheitert immer dann, wenn Führungskräfte es als Werkzeugkauf statt als Gewohnheit behandeln. Das „Wissen“ reicht davon, wie ein klinischer Pfad in einem bestimmten Träger tatsächlich funktioniert, bis dazu, wie eine bestimmte Integrations-Engine konfiguriert ist.

Implizites versus explizites Wissen. Implizites Wissen (Tacit Knowledge) lebt in den Köpfen und Händen der Menschen – das Urteilsvermögen, die Intuition und das hart erarbeitete „das muss man wissen, dass dieser Träger Entlassungen anders kodiert“, das schwer aufzuschreiben ist. Explizites Wissen ist, was artikuliert und in Dokumenten, Diagrammen und Runbooks festgehalten wurde. Das meiste Wissen, das einen Dienst sicher hält, beginnt implizit; die Arbeit des Wissensmanagements ist, genug davon in explizite Form zu überführen, dass der Dienst nicht von einem einzelnen Kopf abhängt.

Das SECI-Modell der Wissensumwandlung. Das SECI-Modell (Sozialisation, Externalisierung, Kombination, Internalisierung) von Nonaka und Takeuchi beschreibt, wie Wissen zwischen impliziter und expliziter Form wandert: Teilen durch gemeinsames Arbeiten (Sozialisation), implizites Wissen aufschreiben (Externalisierung), explizite Teile zu größeren Dokumenten kombinieren (Kombination) und dokumentiertes Wissen wieder in geübte Praxis aufnehmen (Internalisierung). Es ist nützlich, weil es daran erinnert, dass Dokumentation allein nicht genügt – Pairing, Hospitation und Communities zählen ebenso wie das Wiki.

Abhängigkeit von Schlüsselpersonen und der Bus-Faktor. Der Bus-Faktor ist die Zahl der Personen, die verloren gehen müssten, bevor ein Dienst mangels jemandem, der ihn versteht, stillsteht. Ein Bus-Faktor von eins ist der Standardzustand der meisten kleinen digitalen Teams und ein ernstes betriebliches Risiko in einem Dienst, von dem die Gesundheit von Menschen abhängt. Hohe Fluktuation, starke Nutzung von Vertragskräften und Bindung an einen einzelnen Lieferanten drücken die Zahl; bewusste Dokumentation, Cross-Training und Pairing heben sie wieder an.

Dokumentation als erstklassiger Liefergegenstand. Behandeln Sie Dokumente als Produkte, nicht als Nebenprodukte. Ein Servicehandbuch beschreibt, was der Dienst ist und wie er sich verhält; ein Runbook (oder Playbook) gibt Schritt-für-Schritt-Verfahren zum Starten, Stoppen und Wiederherstellen; ein Architecture Decision Record (ADR) hält fest, warum eine bedeutende Entscheidung getroffen wurde, damit künftige Wartende sie nicht aufdröseln, ohne die Gründe zu kennen. Eine Single Source of Truth bedeutet, dass jede Tatsache an genau einem Ort geführt wird, damit niemand widersprüchlichen Kopien der „aktuellen Architektur“ nachjagt.

Docs-as-Code. Dokumentation im selben versionskontrollierten Repository wie die Arbeit zu halten – in Klartext oder Markdown geschrieben, wie Code geprüft, automatisch veröffentlicht – hält Dokumente nah an dem, was sie beschreiben, und macht es weit wahrscheinlicher, dass sie aktuell bleiben. Wenn das Diagramm neben dem Code liegt und sich im selben Pull Request ändert, verrottet es langsamer.

Communities of Practice. Eine Community of Practice (manchmal Gilde genannt) ist eine teamübergreifende Gruppe, die ein Handwerk teilt – Beauftragte für klinische Sicherheit, Front-End-Entwicklerinnen, Leitungen der Informationsgovernance – und es gemeinsam verbessert. Communities verbreiten implizites Wissen horizontal durch eine Organisation, das vertikale Teamgrenzen sonst einsperren würden.

Records Management und Aufbewahrung. Records Management steuert Informationen über ihren Lebenszyklus, einschließlich der Frage, wie lange sie aufbewahrt werden müssen und wann sie vernichtet werden dürfen. In der Gesundheit ist dies teils gesetzlich: Klinische Akten tragen definierte Aufbewahrungsfristen nach dem NHS Records Management Code of Practice. Das ist etwas anderes als Teamdokumentation, und beides zu vermengen verursacht echte Fehler – ein Punkt, auf den wir unten zurückkommen.

Informationsarchitektur und Auffindbarkeit. Informationsarchitektur ist der strukturelle Entwurf eines Informationsraums, damit Menschen finden, was sie brauchen. Ein Wiki mit zehntausend Seiten und ohne Struktur ist keine Dokumentation; es ist eine Müllhalde. Auffindbarkeit ist der Unterschied zwischen Wissen, das existiert, und Wissen, das genutzt wird.

Bewährte Praktiken#

1. Machen Sie Dokumentation zur Definition of Done, nicht zum nachträglichen Gedanken. Eine Funktion, Integration oder Konfigurationsänderung ist nicht „fertig“, bevor ihr Runbook-Eintrag, ihr ADR (falls eine bedeutende Entscheidung getroffen wurde) und ihre Aktualisierung des Servicehandbuchs existieren. Verankern Sie dies in Ihren Arbeitsweisen, damit es geschrieben wird, solange das Wissen frisch ist, von der Person, die es hat. Ein System sechs Monate später aus dem Gedächtnis nachzudokumentieren ist der Ort, an dem Ungenauigkeiten und gefährliche Lücken geboren werden.

2. Halten Sie eine Single Source of Truth und verlinken Sie von ihr nach außen. Entscheiden Sie je Bereich, wo die maßgebliche Version jeder Tatsache liegt – die Architektur, der Bereitschaftsplan, das Datenflussdiagramm –, und lassen Sie alles andere darauf verweisen, statt zu kopieren. Duplizierte Dokumentation driftet, und in einem klinischen Kontext ist eine veraltete Kopie, die sagt „die Allergieprüfung ist an“, wenn sie aus ist, schlimmer als gar kein Dokument. Löschen oder leiten Sie die veralteten Duplikate, die Sie bereits haben, unerbittlich um.

3. Übernehmen Sie Docs-as-Code und halten Sie Dokumentation neben der Arbeit. Speichern Sie Runbooks, ADRs und Servicehandbücher in der Versionskontrolle neben den Systemen, die sie beschreiben, prüfen Sie Dokumentationsänderungen im selben Pull Request wie die Codeänderung und veröffentlichen Sie automatisch. Das macht Aktualisierungen billig, Änderungen prüfbar und die Historie nachvollziehbar – und es bedeutet, dass die Person, die das System ändert, im selben Atemzug angestoßen wird, die Dokumente zu ändern.

4. Schreiben Sie Runbooks, denen ein gestresster Fremder um 3 Uhr nachts folgen könnte. Ein Runbook sollte annehmen, dass die Leserin müde ist, das System nicht kennt und unter Druck steht – denn bei einem größeren Vorfall wird sie es sein. Nutzen Sie nummerierte, wörtliche Schritte, benennen Sie die genauen Bildschirme und Befehle und geben Sie das erwartete Ergebnis jedes Schritts an und was zu tun ist, wenn er fehlschlägt. Testen Sie sie, indem jemand, der sie nicht geschrieben hat, in einer Übung eine Wiederherstellung durchführt.

5. Halten Sie das „Warum“ fest, nicht nur das „Was“, mit Architecture Decision Records. Ein kurzer ADR – Kontext, Entscheidung, Folgen – bewahrt die Begründung bedeutender Entscheidungen, damit künftige Wartende eine Entscheidung nicht rückgängig machen, ohne die Einschränkung zu verstehen, die sie trieb. In der Gesundheit ist das besonders wichtig: Eine merkwürdig aussehende Konfiguration kann wegen einer Gefährdungsanalyse zur klinischen Sicherheit oder eines Beschlusses der Informationsgovernance existieren. Die Begründung festzuhalten verhindert, dass eine gut gemeinte „Aufräumaktion“ ein bekanntes Risiko wieder einführt.

6. Heben Sie den Bus-Faktor bei jedem kritischen System bewusst an. Identifizieren Sie die Systeme mit Bus-Faktor eins und behandeln Sie das als Risiko in Ihrem Register mit benannter verantwortlicher Person und Plan. Bilden Sie Paare, rotieren Sie Bereitschaftswissen, halten Sie „Teach-back“-Sitzungen ab, in denen die Expertin dokumentiert, während eine Kollegin mitverfolgt, und verbieten Sie, dass eine einzelne Person die einzige ist, die einen sicherheitskritischen Dienst ausrollen oder wiederherstellen kann. Das ist billiger, als die Lücke bei einem Ausfall zu entdecken.

7. Führen Sie Nachbesprechungen von Vorfällen durch, die Praxis ändern, statt Menschen zu beschuldigen. Führen Sie nach jedem bedeutenden Vorfall eine schuldfreie Nachbesprechung (Post-Incident Review) durch, die dokumentierte, zugewiesene, befristete Maßnahmen hervorbringt – und schließen Sie diese dann tatsächlich. Lehren, die abgelegt und nie wieder angesehen werden, sind Theater; der Test des Prozesses ist, ob ein späterer Vorfall derselben Form verhindert wird. Führen Sie die Erkenntnisse direkt in Runbooks und den klinischen Sicherheitsnachweis zurück (siehe Thema 3.8 — Servicemanagement und Live-Betrieb).

8. Investieren Sie in Informationsarchitektur und Auffindbarkeit. Strukturieren Sie Ihre Wissensbasis so, dass eine neue Kollegin das Bereitschafts-Runbook in unter einer Minute findet, und beschneiden Sie aggressiv – eine veraltete Seite ist eine Last, kein Gewinn. Vereinbaren Sie Namenskonventionen, eine klare Hierarchie und eine verantwortliche Person je Bereich und versehen Sie wichtige Seiten mit einem Datum „zuletzt geprüft“, damit Lesende die Aktualität beurteilen können. Suche ersetzt keine Struktur; sie ergänzt sie.

9. Bauen Sie Communities of Practice auf, um implizites Wissen zu verbreiten. Richten Sie teamübergreifende Gilden für die Handwerke ein, die zählen – klinische Sicherheit, Security, Front-End, Data Engineering – mit leichtem Auftrag: teilen, was Sie lernen, gemeinsame Muster vereinbaren, Neulinge betreuen. Diese Foren bewegen das implizite Wissen, das kein Dokument erfasst, und verringern doppelte Fehler über Teams hinweg (siehe Thema 7.5 — Personal- und Organisationsentwicklung). Geben Sie ihnen Zeit in der Arbeitswoche, sonst verkümmern sie.

10. Trennen Sie Teamdokumentation von gesetzlichen Akten – und managen Sie beides. Seien Sie ausdrücklich, was Teamwissen ist (Runbooks, ADRs, Wikis) und was eine Akte unter gesetzlicher Aufbewahrung (klinische Akten, Versorgungsentscheidungen, finanzielle Freigaben, Entscheidungen der Informationsgovernance). Wenden Sie die Aufbewahrungspläne des NHS Records Management Code of Practice auf Letztere an und lassen Sie nicht zu, dass beiläufiges Löschen im Wiki etwas zerstört, das Sie gesetzlich aufbewahren mussten. Ebenso horten Sie nicht alles ewig „zur Sicherheit“ – Übervorhaltung ist ein eigenes Governance- und Datenschutzrisiko.

11. Machen Sie das Onboarding zu einem Test Ihrer Dokumentation. Behandeln Sie jedes Onboarding als Live-Audit: Wenn ein kompetenter neuer Ingenieur oder eine neue Klinikerin aus Ihrem schriftlichen Material plus etwas Pairing nicht produktiv werden kann, ist Ihre Dokumentation gescheitert, und die Lücken, auf die sie stoßen, sind Ihr Backlog. Bitten Sie Neue, als ersten Beitrag das Erste zu beheben, was sie verwirrte. Das verwandelt Onboarding von einem einseitigen Kostenfaktor in eine kontinuierliche Verbesserungsschleife für Wissenskontinuität.

Fragen zur Diskussion im Team#

1. Wenn die eine Person, die unsere kritischste Integration versteht, morgen ginge, wie lange wären wir dann ungeschützt – und was genau wüssten wir nicht? Das verwandelt die abstrakte Idee eines Bus-Faktors in einen konkreten Stresstest Ihrer wichtigsten Systeme. Gehen Sie ein reales Beispiel durch – den Pathologie-Feed, die Single-Sign-On-Konfiguration, die Abgleichslogik der gemeinsamen Versorgungsakte – und fragen Sie ehrlich, wer sonst es ohne diese Person betreiben, ändern und wiederherstellen könnte. Die aufzudeckende Spannung ist, dass das tiefste Wissen meist bei Ihrer meistbeschäftigten, vertrauenswürdigsten Person liegt und der Lieferdruck es für sie rational macht, nie innezuhalten und es aufzuschreiben. Unterscheiden Sie Wissen, das wirklich implizit und schwer zu kodifizieren ist, von Wissen, das schlicht nie erfasst wurde, weil niemand Zeit dafür einräumte. Eine gute, ehrliche Antwort benennt Ihre Systeme mit Bus-Faktor eins laut, gibt zu, welche Lücken real sind, und liefert einen bezifferten Plan – Pairing, Dokumentations-Sprints, Cross-Training – statt einer vagen Beruhigung, „es ist alles in den Köpfen der Leute, und das ist in Ordnung“. Ist das Gespräch bequem, waren Sie nicht konkret genug.

2. Wenn wir etwas aufschreiben, woher wissen wir, dass es je jemand finden, ihm vertrauen und es aktuell halten wird – und wo belügt uns unsere Dokumentation bereits? Veraltete Dokumentation ist nicht neutral; in einem sicherheitskritischen Umfeld führt sie eine gestresste Bedienerin aktiv zur falschen Handlung. Die Diskussion sollte den Unterschied zwischen dem Haben von Dokumenten und dem Haben von Dokumenten angehen, die Menschen finden, denen sie vertrauen und nach denen sie handeln können – eine Frage von Informationsarchitektur, Verantwortung und Aktualität, nicht von Menge. Debattieren Sie, ob Ihre Wissensbasis eine echte Struktur hat oder zu einem Wildwuchs geworden ist, in dem niemand navigiert, und ob Dokumente nah genug an der Arbeit liegen (Docs-as-Code), um aktuell zu bleiben, oder in einem separaten Werkzeug driften, das niemand aktualisiert. Fragen Sie jede Person, wann sie sich zuletzt auf ein internes Dokument verließ und es falsch fand und was das kostete. Eine starke Antwort identifiziert konkrete Seiten, von denen Sie wissen, dass sie veraltet sind, weist Verantwortliche und Prüfdaten zu und vereinbart eine Single Source of Truth für die wichtigsten Tatsachen – und ist bereit, mehr zu löschen als hinzuzufügen.

3. Was hat sich nach unserem letzten ernsten Vorfall tatsächlich an unserer Arbeitsweise geändert – und wenn die Antwort „nicht viel“ lautet, warum führen wir weiter Nachbesprechungen durch? Nachbesprechungen von Vorfällen sind verbreitet; Nachbesprechungen, die Praxis ändern, sind selten, und in der Lücke zwischen beiden wiederholen sich dieselben Fehler. Das prüft, ob Ihr Lessons-Learned-Prozess eine echte Rückkopplungsschleife oder ein Ritual ist, das ein Dokument und keine Änderung hervorbringt. Erkunden Sie die kulturellen Bedingungen ehrlich: Nachbesprechungen fördern die Wahrheit nur zutage, wenn sie schuldfrei sind, und Menschen verbergen die wahre Ursache, wenn der Prozess sie bestraft, psychologische Sicherheit ist also eine Voraussetzung, keine Nettigkeit (siehe Thema 8.1 — Veränderungsmanagement). Schauen Sie auf Ihre letzten Vorfälle und verfolgen Sie jede Maßnahme dahin, ob sie abgeschlossen wurde und ob sie Wiederholung verhindert hat. Eine gute Antwort kann auf eine konkrete Änderung verweisen – ein neu geschriebenes Runbook, einen neuen Alarm, eine Designkorrektur –, die eine frühere Nachbesprechung hervorbrachte, und ist offen zu Maßnahmen, die protokolliert und still aufgegeben wurden, mit einem Plan, diese Schleife zu schließen.

4. Welche der Dinge, die wir halten, sind gesetzliche Akten, die wir aufbewahren müssen, welche sind Arbeitsnotizen, die wir auf Aktualität pflegen – und sind wir sicher, dass wir Erstere nicht löschen und Letztere nicht horten? Gesundheits- und Pflegeorganisationen tragen Aufbewahrungspflichten, die die meisten digitalen Teams eher instinktiv als nach Regel behandeln, und beide Fehlerrichtungen sind real: beiläufig eine Wiki-Seite löschen, die sich als Dokumentation einer Versorgungsentscheidung erwies, oder alles ewig „zur Sicherheit“ horten und ein Datenschutz- und Auffindbarkeitsrisiko schaffen. Die Diskussion sollte eine klare Linie ziehen zwischen einer Akte nach dem NHS Records Management Code of Practice – klinische Akten, Versorgungs- und Finanzierungsentscheidungen, Beschlüsse der Informationsgovernance – und Teamwissen wie Runbooks und ADRs, das Sie auf Frische, nicht auf gesetzliche Aufbewahrung managen. Bringen Sie die unbequemen Mischfälle ans Licht, etwa einen ADR, der dokumentiert, warum eine Gefährdung der klinischen Sicherheit akzeptiert wurde, und der beides sein kann. Die Spannung ist, dass Ingenieure auf ordentliche, aktuelle Dokumentation optimieren, während Governance auf vertretbare Aufbewahrung optimiert, und die beiden Instinkte ziehen in entgegengesetzte Richtungen. Eine ehrliche Antwort kann sagen, wer den Aufbewahrungsplan verantwortet, wo die Grenze gezogen ist und was mit einer konkreten Akte geschähe, wenn sie Jahre später von einem Coroner, einer Aufsichtsbehörde oder per Anfrage nach dem Freedom of Information Act verlangt würde.

5. Was in unseren Arbeitsweisen sorgt tatsächlich dafür, dass Dokumentation geschrieben wird, solange das Wissen frisch ist – und wo verlassen wir uns noch auf guten Willen und gute Absichten? Jedes Team stimmt zu, dass Dokumentation zählt; weit weniger haben einen Mechanismus, der sie standardmäßig statt durch Heldentaten entstehen lässt. Diese Frage prüft, ob Aufschreiben in den Arbeitsfluss hineingebaut ist – eine Definition of Done, die „fertig“ ohne Runbook-Eintrag oder ADR blockiert, Dokumentation, die im selben Pull Request wie die Änderung geprüft wird, Docs-as-Code, sodass das Diagramm neben dem Beschriebenen liegt – oder ob sie davon abhängt, dass Einzelne innehalten und schreiben, wenn der Lieferdruck „ausliefern“ sagt. Untersuchen Sie die Anreize ehrlich: Ein System sechs Monate später aus dem Gedächtnis nachzudokumentieren ist der Ort, an dem gefährliche Ungenauigkeiten entstehen, der Wert liegt also fast ganz im Erfassen im Moment. Schauen Sie auf Ihre letzten Änderungen und fragen Sie, ob die Dokumentation von der Person, die das Wissen hielt, zur rechten Zeit geschrieben oder später von jemandem angeflanscht wurde, der sie rekonstruierte. Eine starke Antwort verweist auf konkrete, bereits bestehende Mechanismen und benennt die Lücken, in denen der Prozess noch auf Gedächtnis und Willenskraft setzt, mit einem Plan, sie zu schließen.

6. Wie bewegen wir das Wissen, das kein Dokument je erfassen wird – das Urteilsvermögen und das „das muss man wissen, dass dieser Träger Entlassungen anders kodiert“ –, und wird das jedes Mal schwerer, wenn der Vertrag einer Vertragskraft endet? Vieles, was einen Dienst sicher hält, ist implizit: Intuition, Mustererkennung und hart erarbeiteter Kontext, der sich dem Aufschreiben widersetzt, und das SECI-Modell erinnert daran, dass Dokumentation allein es nie vollständig externalisiert. Diese Frage verlangt, wie bewusst Sie dieses Wissen durch Pairing, Hospitation, Teach-back-Sitzungen und Communities of Practice verbreiten, statt anzunehmen, das Wiki erledige das. Die Spannung ist dort am schärfsten, wo Sie sich auf Vertragskräfte und mehrere Lieferanten stützen, weil ihr tiefstes Wissen am Ende jedes Auftrags zur Tür hinausgeht, wenn Erfassung nicht vertragliche und kulturelle Erwartung ist, sondern ein Gefallen, um den in der letzten Woche gebeten wird. Diskutieren Sie, ob Ihre Handwerke – klinische Sicherheit, Integration, Data Engineering – lebendige Gilden mit geschützter Zeit haben oder teamübergreifendes Lernen nur zufällig geschieht. Eine ehrliche Antwort unterscheidet Wissen, das wirklich implizit ist und Weitergabe von Mensch zu Mensch braucht, von Wissen, das bloß nicht erfasst wurde, und kann auf echte Praktiken verweisen – einen Pairing-Plan, einen Wissenskontinuitätsplan für ausscheidende Vertragskräfte, eine aktive Community of Practice – statt auf ein Ideal.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) betreibt eine gemeinsame Versorgungsakte, die Daten aus drei Akutträgern, Gemeindediensten und einem Fallmanagementsystem der Sozialpflege zieht. Die Integration wurde vor zwei Jahren weitgehend von einem Vertragsingenieur, „Dev“, gebaut, der jede Eigenheit der Abgleichslogik verstand, die entscheidet, wann sich zwei Datensätze auf dieselbe Person beziehen. Devs Vertrag endet in sechs Wochen. Es gibt ein Wiki, das aber zuletzt während des Aufbaus wesentlich aktualisiert wurde.

Die Lieferleiterin behandelt das als Bus-Faktor-eins-Risiko und setzt es mit ihrem eigenen Namen auf das Programm-Risikoregister. Über die sechs Wochen finanziert sie eine kleine „Wissenskontinuitäts“-Anstrengung: Dev bildet jeden Morgen ein Paar mit zwei festangestellten Ingenieuren, und statt eines Abschieds-Brain-Dumps externalisieren sie laufend – schreiben Runbooks für die Fehlerbilder, die Dev auswendig kennt, und ADRs, die erklären, warum die Abgleichslogik bestimmte Abweichungen toleriert (es zeigt sich, dass eine scheinbar schlampige Regel existiert, um eine bekannte Patientensicherheitsgefährdung zu vermeiden, die im ursprünglichen klinischen Sicherheitsnachweis markiert wurde). Die Dokumente liegen im selben Git-Repository wie der Integrationscode, in Pull Requests geprüft, sodass sie versioniert und aktuell sind.

Zwei Monate nach Devs Weggang beginnt der Feed eines Akutträgers, über Nacht doppelte Patientendatensätze zu erzeugen. Der Ingenieur in Bereitschaft – der Dev nie getroffen hat – öffnet das Runbook, folgt den nummerierten Schritten, bestätigt das erwartete Ergebnis auf jeder Stufe und stellt binnen einer Stunde den korrekten Abgleich wieder her. In der schuldfreien Nachbesprechung findet das Team den Auslöser (eine vorgelagerte Änderung, wie der Träger NHS-Nummern kodiert) und macht daraus einen Überwachungsalarm und eine Runbook-Aktualisierung. Was ein mehrtägiges, hochriskantes Gerangel – und ein echter Patientensicherheitsvorfall – gewesen wäre, wurde eine dokumentierte einstündige Wiederherstellung, weil implizites Wissen explizit gemacht wurde, solange die Person, die es hielt, noch da war.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit lebt mit dem höchsten Bus-Faktor-Risiko und dem geringsten Spielraum, es anzugehen: eine Handvoll Ingenieure, tiefes Wissen in jedem Kopf und eine Kultur, die Ausliefern über Schreiben stellt. Der pragmatische Schritt ist leichte, billige Dokumentation im Arbeitsfluss – ADRs als kurze Markdown-Dateien im Repository, Runbooks, die geschrieben werden, wenn zum ersten Mal etwas kaputtgeht, Docs-as-Code von Tag eins an, damit sich die Gewohnheit bildet, bevor der Umfang sie schwer macht. Gründerinnen und Gründer sollten der Versuchung widerstehen, alle Dokumentation auf „nach dem Product-Market-Fit“ zu verschieben, denn ein Ausfall in einem klinischen Produkt oder eine gescheiterte Prüfung der klinischen Sicherheit oder nach DTAC (Digital Technology Assessment Criteria) mangels Nachweisen kann existenziell sein. Das Ziel ist keine polierte Wissensbasis, sondern sicherzustellen, dass kein einzelner Weggang das Unternehmen versenken kann.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – trägt dieselben Pflichten zu klinischer Sicherheit und Aktenaufbewahrung wie ein großer Träger, aber ohne eigene IT- oder Wissensmanagement-Funktion und mit wenig Spielraum, eine aufzubauen. Hier muss die Praxis radikal verhältnismäßig sein: ein auffindbarer Ort für die Handvoll Runbooks, die zählen (wie das klinische System wiederhergestellt wird, wen man anruft, wenn die gemeinsame Versorgungsakte ausfällt), eine einfache Regelung mit benannter verantwortlicher Person, damit kritisches Wissen nicht allein bei der Praxismanagerin oder einer langjährigen Pflegekraft liegt, und eine klare Linie zwischen den gesetzlichen Akten, die sie aufbewahren müssen, und den Arbeitsnotizen, bei denen das nicht gilt. Das akute Risiko ist ein Bus-Faktor von eins im Gewand der Kontinuität: Die Person, die weiß, wie alles konfiguriert ist, führt auch den Tagesbetrieb, und ein Ruhestand oder eine lange Krankheit kann niemanden zurücklassen, der ein sicherheitskritisches System betreiben kann. Wo Systeme von einem Anbieter geliefert und gehostet werden, sollte der kleine Anbieter dennoch seine eigene lokale Konfiguration und Behelfslösungen aufschreiben, denn der Lieferant dokumentiert nicht, wie diese Organisation das Produkt tatsächlich nutzt.

Großunternehmen#

Ein großer NHS-Träger, ein ICS oder ein Health-Tech-Lieferant sieht sich dem gegenteiligen Fehler gegenüber: zu viel Dokumentation, verstreut über SharePoint, Confluence, Netzlaufwerke und E-Mail, ohne Single Source of Truth und mit schlechter Auffindbarkeit. Die Herausforderung im Großunternehmen sind Informationsarchitektur, Verantwortung und Beschneiden – entscheiden, wo jede Tatsache geführt wird, Verantwortliche zuweisen, Duplikate abschaffen und Wissensmanagement mit Servicemanagement und Änderungskontrolle verbinden. Communities of Practice verdienen sich hier ihren Platz, indem sie Muster über Dutzende Teams verbreiten, die sonst je dieselbe Lektion schmerzhaft lernen würden. Das zu steuernde Risiko ist starke Nutzung von Vertragskräften und mehreren Lieferanten, bei der Wissen am Ende jedes Vertrags zur Tür hinausgeht, wenn Erfassung nicht vertragliche und kulturelle Erwartung ist.

Regierung#

Eine nationale oder lokale öffentliche Stelle – NHS England, DHSC, UKHSA oder eine Kommunalverwaltung – arbeitet unter gesetzlichen Pflichten des Records Management, Informationsfreiheitspflichten und öffentlicher Prüfung; Wissensmanagement ist daher teils eine Frage des Rechts und der öffentlichen Rechenschaft. Entscheidungen zu Diensten, Geld und Politik müssen dokumentiert, für definierte Zeiträume aufbewahrt und Jahre später für Ausschüsse, Prüfungen des National Audit Office und öffentliche Untersuchungen auffindbar sein; die jüngere Geschichte großer Untersuchungen zeigt, wie schlechte Aktenführung selbst zum Skandal wird. Die Regierung muss die Linie zwischen gesetzlichen Akten (nach Plan aufbewahrt und vernichtet) und Arbeitswissen (auf Aktualität gemanagt) halten und den NHS Records Management Code of Practice diszipliniert anwenden. Transparenz ist das Losungswort: Die Arbeitsannahme sollte sein, dass Dokumentation eines Tages von der Öffentlichkeit gelesen werden kann.

Häufige Fehlermuster#

• Die Heldin und der Bus-Faktor von eins. Die Einzelperson feiern, die das System „einfach kennt“, ohne je die Arbeit zu finanzieren, dieses Wissen zu verbreiten. Es fühlt sich effizient an, bis zu dem Tag, an dem sie nicht verfügbar ist und ein sicherheitskritischer Dienst niemanden hat, der ihn betreiben kann.
• Einmal-Dokumentation. Dokumente, die während eines Aufbaus entstehen und nie wieder angefasst werden und in selbstsichere Unwahrheit driften. Veraltete Dokumente sind gefährlicher als keine, weil Menschen danach handeln.
• Die Wiki-Müllhalde. Tausende Seiten, keine Struktur, keine Verantwortlichen, keine Prüfdaten – Wissen, das technisch existiert, aber nicht gefunden oder ihm nicht vertraut werden kann. Menge mit Wert verwechselt.
• Dokumente fern der Arbeit. Dokumentation in einem separaten Werkzeug, das beim Programmieren niemand öffnet, was garantiert, dass sie von der Realität abweicht. Docs-as-Code ist das Gegenmittel.
• Lessons-Learned-Theater. Nachbesprechungen, die ein Dokument und eine Liste nie abgeschlossener Maßnahmen hervorbringen, sodass sich derselbe Vorfall wiederholt. Der Prozess wird Ritual, nicht Verbesserung.
• Akten mit Notizen verwechseln. Entweder etwas löschen, das Sie gesetzlich aufbewahren mussten, oder alles ewig horten und ein Datenschutz- und Auffindbarkeitsrisiko schaffen. Beides rührt daher, gesetzliche Akten nicht von Teamdokumentation zu unterscheiden.
• Schuldzuweisung im Besprechungsraum. Nachbesprechungen, die die Person nächst dem Fehler bestrafen, was alle lehrt, die wahre Ursache zu verbergen, und die Ehrlichkeit zerstört, von der der Prozess abhängt.

Reifegradmodell#

Checkliste#

• Jedes kritische System hat ein Servicehandbuch, ein aktuelles Runbook und ADRs für seine bedeutenden Entscheidungen.
• Dokumentation ist Teil Ihrer Definition of Done und wird im selben Pull Request wie die Änderung geprüft.
• Jeder Bereich hat eine benannte Single Source of Truth; bekannte Duplikate sind gelöscht oder umgeleitet.
• Systeme mit Bus-Faktor eins stehen im Risikoregister mit Verantwortlichen und einem aktiven Cross-Training-Plan.
• Runbooks wurden von jemandem getestet, der sie nicht geschrieben hat, in einer Übung oder einem echten Vorfall.
• Nachbesprechungen von Vorfällen sind schuldfrei und bringen zugewiesene, befristete Maßnahmen hervor, die geschlossen werden.
• Die Wissensbasis hat eine klare Struktur, Seitenverantwortliche und Prüfdaten; veraltete Seiten werden beschnitten.
• Mindestens eine aktive Community of Practice existiert für ein teamübergreifendes Handwerk, mit geschützter Zeit dafür.
• Gesetzliche Akten sind von Teamdokumentation unterschieden und nach dem richtigen Aufbewahrungsplan gemanagt.
• Neue Kolleginnen und Kollegen werden gebeten, als frühen Beitrag die erste Dokumentationslücke zu beheben, auf die sie stoßen.

Zentrale Quellen#

• NHS England / NHSX, Records Management Code of Practice 2021 — gesetzliche Aufbewahrungspläne und Lebenszyklus-Pflichten für Gesundheits- und Pflegeakten.
• GOV.UK Service Manual (Government Digital Service) — Leitlinien zum Schreiben für und Betreiben von digitalen Diensten, einschließlich Dokumentation und Betrieb eines Dienstes.
• NHS Digital Service Standard — Erwartungen an den Aufbau und die Pflege nachhaltiger, gut dokumentierter digitaler Dienste.
• Michael Nygard, „Documenting Architecture Decisions“ (2011) — das Ursprungsmuster für Architecture Decision Records (ADRs).
• Google, Site Reliability Engineering — schuldfreie Nachbesprechungen (Postmortems), Runbooks und das Verringern betrieblicher Schlüsselpersonen-Risiken.
• Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity (1998) — der grundlegende Text zu Communities of Practice.
• Nonaka & Takeuchi, The Knowledge-Creating Company (1995) — das SECI-Modell der Umwandlung von implizitem in explizites Wissen.
• Die Write-the-Docs-Community — Praxisleitlinien zu Docs-as-Code und zum Behandeln von Dokumentation als Produkt.

Referenzen#

1. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
2. Tacit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Tacit_knowledge
3. Explicit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Explicit_knowledge
4. SECI model of knowledge dimensions — Wikipedia — https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions
5. Bus factor — Wikipedia — https://en.wikipedia.org/wiki/Bus_factor
6. Runbook — Wikipedia — https://en.wikipedia.org/wiki/Runbook
7. Architectural decision — Wikipedia — https://en.wikipedia.org/wiki/Architectural_decision
8. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
9. Community of practice — Wikipedia — https://en.wikipedia.org/wiki/Community_of_practice
10. Records management — Wikipedia — https://en.wikipedia.org/wiki/Records_management
11. Information architecture — Wikipedia — https://en.wikipedia.org/wiki/Information_architecture
12. Postmortem documentation — Wikipedia — https://en.wikipedia.org/wiki/Postmortem_documentation
13. Onboarding — Wikipedia — https://en.wikipedia.org/wiki/Onboarding
14. Records Management Code of Practice 2021 — NHS England / NHSX — https://www.nhsx.nhs.uk/information-governance/guidance/records-management-code/
15. Service manual — Government Digital Service (GOV.UK) — https://www.gov.uk/service-manual
16. Documenting Architecture Decisions — Michael Nygard — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
17. Site Reliability Engineering — Google — https://sre.google/books/
18. Write the Docs — docs-as-code guidance — https://www.writethedocs.org/guide/docs-as-code/