Thema 3.8 — Servicemanagement und Live-Betrieb

In Gesundheit und Pflege liegt der größte Teil von Lebensdauer, Kosten und klinischem Risiko eines Services nach dem Go-live – wie Sie einen Live-Service betreiben, überwachen und unterstützen, ist daher eine Entscheidung der Patientensicherheit, kein Backoffice-Nachgedanke.

Warum das in Gesundheit und Pflege wichtig ist#

Der Start ist der Anfang, nicht das Ende. Ein digitaler Service verbringt einige Monate damit, gebaut zu werden, und, wenn er Erfolg hat, Jahre oder Jahrzehnte damit, betrieben zu werden – und im Betrieb geht der größte Teil des Geldes hin und geschieht der tatsächliche Schaden. Eine gemeinsame Patientenakte, ein E-Verordnungssystem oder eine Plattform für Mutterschaftsakten liefert ihren Wert nur, solange sie verfügbar, korrekt und reaktionsfähig ist. Wenn sie sich verschlechtert oder ausfällt, sind die Folgen keine Unannehmlichkeit, sondern verzögerte Behandlung, übersehene Allergien, abgesagte Kliniken und Klinikpersonal, das unter Druck auf ungewohnte Papierumgehungen zurückfällt.

Gesundheit und Pflege laufen 24 Stunden am Tag, sieben Tage die Woche, und können nicht pausieren. Wenn das Kassensystem eines Supermarkts ausfällt, warten Kunden; wenn das Patientenverwaltungssystem eines Krankenhauses ausfällt, werden womöglich Rettungswagen umgeleitet und elektive Listen verschoben. Das gibt dem Live-Betrieb ein besonderes Gewicht: Ausfallzeit ist ein Ereignis der klinischen Sicherheit, und der Plan, wie Sie sie erkennen, eskalieren, kommunizieren und sich davon erholen, ist Teil Ihrer Sorgfaltspflicht. Der WannaCry-Ransomware-Angriff von 2017 – der die Absage Tausender NHS-Termine und Operationen erzwang – ist der Referenzfall dafür, wie ein operatives Versagen zu einer Krise der Patientensicherheit und des öffentlichen Vertrauens wird (siehe Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit).

Führungskräfte müssen den Live-Betrieb auch ehrlich finanzieren und besetzen. Das hartnäckige Versagen in der Health-Tech ist, einen Go-live zu feiern, das Team aufzulösen und den laufenden Service als „fertig“ zu behandeln. Ein Live-Service ohne ständiges Team, ohne Überwachung und ohne Bereitschaftsabdeckung spart kein Geld – er sammelt still klinisches Risiko an, bis zu dem Tag, an dem er laut versagt. Servicemanagement ist die Disziplin, die einen Live-Service sicher hält, und verdient dieselbe Strenge wie der Bau.

Kernkonzepte#

Servicemanagement und die „Live“-Phase. IT-Servicemanagement (ITSM) ist die Menge an Praktiken zum Entwerfen, Betreiben, Unterstützen und Verbessern von IT-Services über ihre gesamte Lebensdauer. Im Phasenmodell von GOV.UK und NHS ist Live die Phase, in der ein Service im Dauerbetrieb läuft – weiter iterierend, weiter finanziert, weiter verantwortet –, bis er außer Betrieb genommen wird (siehe Thema 3.5 — Lieferlebenszyklen). Live ist kein Ruhezustand; es ist der längste und teuerste Teil des Lebenszyklus.

ITIL 4. ITIL ist das am weitesten verbreitete ITSM-Rahmenwerk. Seine aktuelle Ausgabe, ITIL 4, rahmt ältere prozessschwere Versionen um ein „Service Value System“ und flexible Praktiken neu und ist so entworfen, dass es neben Agile, DevOps und Lean steht, statt mit ihnen zu konkurrieren. Behandeln Sie ITIL als Vokabular und Checkliste von Praktiken, die verhältnismäßig zu übernehmen sind – nicht als Bürokratie, die im Ganzen importiert wird.

Incident-, Problem- und Change-Management. Incident-Management stellt den Normalbetrieb nach einer ungeplanten Störung so schnell wie möglich wieder her – die Priorität ist Wiederherstellung, nicht Diagnose. Problem-Management untersucht die zugrunde liegende Ursache eines oder vieler Vorfälle, um Wiederholung zu verhindern, und führt eine Aufzeichnung bekannter Fehler und Umgehungen. Change-Management (im ITSM-Sinne) steuert, wie Änderungen am Live-Bestand bewertet, genehmigt und freigegeben werden, damit die Korrektur einer Sache nicht eine andere bricht. Diese drei Praktiken sind der operative Kern und greifen ineinander: Ein Vorfall kann ein Problem aufwerfen, dessen Behebung als Änderung geliefert wird.

Major-Incident-Management und Business Continuity. Ein Major Incident ist ein Ereignis mit hoher Auswirkung – ein klinisches System fällt über einen ganzen Trust aus –, das eine erklärte, koordinierte Reaktion mit definierter Einsatzleitung, Kommunikation und klinischer Führung braucht. Business-Continuity-Planung (BCP) ist die breitere Fähigkeit, Versorgung während einer Störung auf akzeptablem Niveau weiter zu erbringen, einschließlich getesteter klinischer Ausfallverfahren (der sichere Papier-Rückfall) und Disaster Recovery. In Gesundheit und Pflege sind diese nicht optional: Patientinnen und Patienten sicher zu halten, während das System ausgefallen ist, ist der ganze Sinn.

Site Reliability Engineering, SLIs, SLOs, SLAs und Fehlerbudgets. Site Reliability Engineering (SRE), bei Google entstanden, wendet die Disziplin des Software-Engineerings auf den Betrieb an. Es misst Zuverlässigkeit mit einem Service-Level-Indikator (SLI) – einer Kennzahl wie Verfügbarkeit oder Latenz – gegen ein Service-Level-Ziel (SLO), ein internes Ziel für diese Kennzahl. Ein Service-Level-Agreement (SLA) ist das externe, oft vertragliche Versprechen, meist lockerer gesetzt als das interne SLO. Die Lücke zwischen 100 % und Ihrem SLO ist das Fehlerbudget: die Menge an Unzuverlässigkeit, die Sie ausgeben können, bevor Sie aufhören müssen, Funktionen auszuliefern, und stabilisieren müssen. In klinischen Systemen müssen SLOs mit Klinikpersonal gesetzt werden, denn „akzeptable“ Ausfallzeit ist ein Sicherheitsurteil, nicht nur ein technisches.

Beobachtbarkeit und Überwachung. Beobachtbarkeit ist die Fähigkeit, den inneren Zustand eines Systems aus seinen äußeren Ausgaben – Logs, Metriken und Traces – zu verstehen, sodass Sie Probleme erkennen und diagnostizieren können, idealerweise bevor es Nutzende tun. Überwachung und Alarmierung verwandeln diese Daten in rechtzeitige Signale für die Menschen in Bereitschaft. Sie können einen Service nicht sicher betreiben, den Sie nicht sehen können.

Bereitschaft, Dienstpläne und der Service Desk. Bereitschafts-Dienstpläne stellen sicher, dass rund um die Uhr ein kompetenter Mensch auf Alarme reagieren kann; in einem 24/7-Versorgungsumfeld sind sie unverzichtbar und müssen menschlich und nachhaltig sein. Ein Service Desk (oder Help Desk) ist die zentrale Anlaufstelle für Endnutzende – die Klinikerin, die sich nicht anmelden kann, die Empfangskraft, deren Buchungsbildschirm eingefroren ist – und leistet Unterstützung, erfasst Vorfälle und leitet sie weiter.

DevOps, Konfigurationsmanagement und die CMDB. DevOps und das SRE-Prinzip „you build it, you run it“ stellen das Team, das einen Service baut, in die Verantwortung für seinen Betrieb und schließen die Lücke zwischen Entwicklung und Betrieb. Konfigurationsmanagement führt eine genaue Aufzeichnung der Komponenten, die einen Service ausmachen, und ihrer Beziehungen, oft in einer Konfigurationsmanagement-Datenbank (CMDB); ohne sie kann niemand bei einem Vorfall sicher beantworten „was betrifft diese Änderung?“

Betrieb versus Bau und Außerbetriebnahme. Organisationen trennen Bau-Finanzierung (neue Fähigkeit schaffen) von Betriebs-Finanzierung (Bestehendes betreiben). Die Unterfinanzierung des Betriebs ist die strukturelle Wurzel der meisten operativen Fehler. Und jeder Service erreicht irgendwann die Außerbetriebnahme – sichere Stilllegung, mit nach Aufbewahrungsrecht migrierten oder archivierten Daten und umgeleiteten Nutzenden –, die eine eigene operative Disziplin ist.

Bewährte Praktiken#

1. Finanzieren und besetzen Sie den „Betrieb“ als erstklassige Verpflichtung, nicht als Rest. Budgetieren Sie vor dem Go-live für die Betriebslebensdauer des Services – Überwachung, Bereitschaft, Service Desk, Sicherheitspatching und kontinuierliche Iteration – und schützen Sie es vor Raubzügen durch den nächsten glänzenden Bau. Die Faustregel der Branche, dass der Betrieb eines Systems über seine Lebensdauer weit mehr kostet als der Bau, gilt auch in der Gesundheit. Ein Service mit Baufinanzierung und ohne Betriebsfinanzierung ist ein klinisches Risiko mit Starttermin.

2. Vermeiden Sie das Antimuster „über die Mauer zum Betrieb werfen“. Lassen Sie ein Projektteam nicht einen Service bauen und ihn an ein separates Betriebsteam übergeben, das nie sah, wie er gemacht wurde. Wenden Sie „you build it, you run it“ an: Halten Sie das Team, das den Service versteht, für seine Zuverlässigkeit rechenschaftspflichtig, oder führen Sie mindestens eine bewusste, dokumentierte Serviceübergabe mit geteilter Bereitschaft und einer Gewährleistungsphase durch. Die Mauer zwischen Bau und Betrieb ist der Ort, an dem Wissen, Verantwortung und Sicherheit durchfallen.

3. Setzen Sie SLOs mit Klinikpersonal und steuern Sie ein Fehlerbudget. Definieren Sie, was „zuverlässig genug“ für jeden Service bedeutet, als messbare SLIs und SLOs, und setzen Sie sie gemeinsam mit dem Klinikpersonal, das die Folgen trägt – Verfügbarkeitsziele für ein System der Notaufnahme sind keine rein technische Wahl. Nutzen Sie das Fehlerbudget, um die ewige Spannung zwischen dem Ausliefern von Funktionen und Stabilbleiben zu schlichten: Wenn die Zuverlässigkeit aufgebraucht ist, halten Sie an und stabilisieren Sie. Halten Sie externe SLAs lockerer als interne SLOs, damit Sie Spielraum haben, zu handeln, bevor Sie ein Versprechen brechen.

4. Machen Sie den Service beobachtbar, bevor Sie ihn größer machen. Instrumentieren Sie Logging, Metriken und Tracing und bauen Sie Dashboards und Alarme, die das Erleben der Nutzenden und des Klinikpersonals spiegeln, nicht nur den Serverzustand. Alarmieren Sie auf Symptome, die zählen (Patientinnen und Patienten können nicht gebucht werden), statt auf jedes zugrunde liegende Zucken, um Alarmmüdigkeit zu vermeiden, die Reagierende trainiert, Pages zu ignorieren. Sie können einen Service nicht sicher halten, dessen Ausfälle Sie von verärgertem Klinikpersonal erfahren.

5. Führen Sie diszipliniertes Incident-, Problem- und Change-Management durch – verhältnismäßig. Geben Sie Vorfällen klare Schweregrade, Reaktionsziele, eine Einsatzleitung bei größeren und eine einzige Wahrheitsquelle während der Reaktion. Speisen Sie ernste Vorfälle in schuldfreie Nachbetrachtungen und einen Problem-Management-Prozess, der Grundursachen behebt, statt den Server wiederholt neu zu starten. Steuern Sie Änderungen über einen passend dimensionierten Prozess – leichte, standardisierte, vorab genehmigte Änderungen für Routinearbeit mit geringem Risiko; eine Change-Advisory-Prüfung nur für wirklich riskante Änderungen –, damit Governance die Sicherheit schützt, ohne zu einem Engpass zu werden, der Menschen zum Umgehen verleitet.

6. Proben Sie Major Incidents und klinische Ausfälle, dokumentieren Sie sie nicht nur. Schreiben, testen und üben Sie regelmäßig Verfahren der Business Continuity und der klinischen Ausfallzeit: wie Versorgung auf Papier weitergeht, wie Personal erfährt, dass das System ausgefallen ist, wie Daten bei der Wiederherstellung abgeglichen werden und wer einen Major Incident erklärt und leitet. Ungeprüfte Pläne scheitern am Tag. Verknüpfen Sie dies ausdrücklich mit Ihrem klinischen Risikomanagement und Gefährdungsprotokoll (siehe Thema 1.6 — Klinische Sicherheit und Risikomanagement), denn Ausfallzeit ist eine klinische Gefährdung mit einer Milderung, die man proben kann.

7. Behandeln Sie das Lernen nach Vorfällen als schuldfrei und systemisch. Führen Sie nach jedem wesentlichen Vorfall eine Nachbetrachtung durch, die fragt, wie das System den Ausfall zuließ, nicht wem die Schuld zu geben ist – denn Schuldzuweisung treibt Meldungen in den Untergrund und wiederholt den Schaden. Erfassen Sie Maßnahmen, weisen Sie Verantwortliche zu und verfolgen Sie sie bis zum Abschluss; speisen Sie Muster in Problem-Management und Design. Eine Lernkultur ist eine Kontrolle der Patientensicherheit und spiegelt die „gerechte Kultur“ (Just Culture) der klinischen Vorfallmeldung.

8. Führen Sie eine genaue Konfigurationsaufzeichnung und steuern Sie den ganzen Bestand. Pflegen Sie eine CMDB oder ein gleichwertiges Inventar dessen, was läuft, was wovon abhängt, welche Versionen bereitgestellt sind und wer jeden Service verantwortet, damit Sie bei einem Vorfall „was betrifft das?“ in Minuten beantworten können. Das stützt sichere Änderung, Sicherheitspatching und Lizenzierung und ist der Punkt, an dem die meisten großen NHS-Bestände am schwächsten sind. Ein unbekanntes, ungepatchtes System ist zugleich ein Ausfall und ein Cybersicherheitsvorfall, der darauf wartet zu geschehen (siehe Thema 1.7).

9. Machen Sie Bereitschaft nachhaltig und Support menschlich. Gestalten Sie Bereitschaftspläne, die angemessen besetzt, fair vergütet und menschlich sind, mit klarer Eskalation und realistischen Erwartungen – ausgebrannte Reagierende treffen langsame, fehleranfällige Entscheidungen gerade in den Momenten, die am meisten zählen. Statten Sie den Service Desk für die reale Nachfrage einer 24/7-Klinikbelegschaft aus und geben Sie Personal an der Front einen schnellen, respektierten Weg, Probleme zu melden. Die Qualität Ihres Supports ist die Qualität der Versorgung, die das Personal von Ihrem Service erlebt.

10. Planen Sie die Außerbetriebnahme als kontrollierte Operation. Entscheiden Sie, solange der Service live ist, wie er dereinst stillgelegt wird: Datenmigration oder -archivierung nach Aufbewahrungsrecht, Umleitung der Nutzenden, Benachrichtigung des Klinikpersonals und Bewahrung von Gefährdungsprotokoll und Prüfspur. Eine ungeplante Stilllegung lässt Daten und Nutzende gestrandet zurück und kann gesetzliche Aufbewahrungspflichten verletzen. Eine geplante ist ein prüfbares operatives Projekt, keine Hektik, wenn der Ersatz eintrifft.

Fragen zur Diskussion im Team#

1. Wenn ein kritisches klinisches System um 3 Uhr morgens an einem Feiertag ausfällt, wer tut genau was – und haben wir es je getestet? Diese Frage erzwingt den Unterschied zwischen einem dokumentierten Plan und einer echten Fähigkeit. In Gesundheit und Pflege ist Ausfallzeit ein klinisches Ereignis: Die praktischen Fragen sind, wer gepaged wird, wie schnell er reagiert, wer die Befugnis hat, einen Major Incident zu erklären, wie Klinikpersonal angewiesen wird, auf Ausfallverfahren umzuschalten, wie Patientinnen und Patienten auf Papier sicher bleiben und wie Daten bei der Wiederherstellung abgeglichen werden. Debattieren Sie, ob Ihr Bereitschaftsplan zu unsozialen Zeiten und an Feiertagen tatsächlich kompetente Abdeckung hat oder auf eine einzige erschöpfte Person ausdünnt, wenn das Risiko am höchsten ist. Überlegen Sie, ob Klinikpersonal das Ausfallverfahren kennt und je geprobt hat oder ob es in einem Ordner liegt, den niemand geöffnet hat. Eine gute, ehrliche Antwort beschreibt eine getestete Reaktion – mit benannten Rollen, einer echten Übung im letzten Jahr und befolgten Lehren –, kein Richtliniendokument, das nie einen Ausfall getroffen hat. Lautet die ehrliche Antwort „wir wissen es nicht wirklich“, ist das selbst der wichtigste Befund, den man dem Vorstand vorlegen muss.

2. Finanzieren und besetzen wir den „Betrieb“ wirklich, oder haben wir den Go-live gefeiert und sind still weggegangen? Der größte Teil der Kosten und des klinischen Risikos eines Services liegt nach dem Start, doch Finanzierungsmodelle belohnen das Bauen neuer Dinge und hungern den Betrieb alter aus. Die zu debattierende Spannung ist der strukturelle Sog der Baufinanzierung gegenüber der unglamourösen, wesentlichen Arbeit, einen Live-Service über Jahre zu überwachen, zu patchen, zu unterstützen und zu iterieren. Schauen Sie ehrlich auf Ihren Live-Bestand: Wie viele Services haben einen benannten Verantwortlichen, ein finanziertes Team, aktuelle Sicherheitspatches und funktionierende Überwachung – und wie viele sind verwaist, laufen auf nicht unterstützter Software, ohne dass jemand rechenschaftspflichtig ist? Überlegen Sie das Muster „über die Mauer zum Betrieb werfen“ und ob die Menschen, die jeden Service betreiben, verstehen, wie er gebaut wurde. Eine gute Antwort kann auf geschützte Betriebsbudgets, benannte Serviceverantwortliche für die Betriebslebensdauer und eine bewusste Serviceübergabe statt eines Verlassens verweisen und die verwaisten Services ehrlich benennen, damit sie übernommen, ersetzt oder stillgelegt werden können, statt sie dem Versagen zu überlassen.

3. Wie entscheiden wir, was „zuverlässig genug“ bedeutet – und wer hat ein Wort mitzureden? Zuverlässigkeit ist nicht gratis, und einer weiteren Neun bei der Verfügbarkeit nachzujagen kann mehr kosten als der Schaden, den sie verhindert; doch in klinischen Systemen ist „akzeptable“ Ausfallzeit ein Sicherheitsurteil, das Ingenieure nicht allein fällen können. Diese Frage fragt, ob Sie explizite SLIs und SLOs haben, ob sie mit dem Klinikpersonal und den operativen Führungskräften gesetzt wurden, die die Folgen tragen, und ob Sie etwas wie ein Fehlerbudget nutzen, um das Ausliefern von Verbesserungen gegen Stabilbleiben abzuwägen. Debattieren Sie den Unterschied zwischen dem internen Ziel, auf das Sie steuern, und dem externen SLA, das Sie versprechen, und ob Ihre Überwachung misst, was Klinikpersonal tatsächlich erlebt, oder nur, was Server melden. Überlegen Sie, ob „wir streben 99,9 % an“ Zähne hat – eine definierte Messung, eine Folge bei Verletzung, einen Verantwortlichen, der handelt. Eine gute Antwort verbindet ein Zuverlässigkeitsziel mit einer Begründung der klinischen Sicherheit, zeigt, dass die Kennzahl gemessen und verantwortet wird, und beschreibt, was das Team anders macht, wenn das Budget aufgebraucht ist, statt einer Zahl auf einer Folie, auf die niemand steuert.

4. Wissen wir tatsächlich, was wir betreiben – und könnten wir mitten in einem Vorfall „was betrifft diese Änderung?“ beantworten? Die meisten großen Gesundheits- und Pflegebestände sind genau dort am schwächsten, wo es am meisten wehtut: Niemand hält ein genaues, aktuelles Bild davon, was läuft, was wovon abhängt, welche Versionen bereitgestellt sind und wer jeden Service verantwortet. Diese Frage prüft, ob Sie eine Konfigurationsaufzeichnung – eine CMDB oder Gleichwertiges – führen oder ob dieses Wissen in den Köpfen einer Handvoll Menschen und einem Jahrzehnt undokumentierter Integrationen lebt. Debattieren Sie die realen Folgen: eine Änderung, die still ein nachgelagertes System bricht, ein Sicherheitspatch, der nicht angewandt werden kann, weil niemand weiß, was er berühren wird, ein nicht unterstützter Server, der erst entdeckt wird, wenn er ausfällt oder ausgenutzt wird. Die Spannung ist, dass Konfigurationsmanagement unglamourös, nie fertig und leicht aufzuschieben ist, dabei aber sichere Änderung, Patching, Lizenzierung und Cyberresilienz gleichermaßen stützt – derselbe blinde Fleck, der WannaCry zur Krise machte. Eine ehrliche Antwort beschreibt ein gepflegtes Inventar mit Verantwortlichen und Abhängigkeiten, dem Menschen vertrauen und das sie bei Vorfällen nutzen, und benennt die Teile des Bestands, die noch dunkel sind, statt eine Vollständigkeit zu behaupten, die keine große Organisation wirklich hat.

5. Wenn etwas schiefgeht, lernen wir, oder suchen wir jemanden, dem wir die Schuld geben können? Die Kultur Ihrer Vorfall-Nachbetrachtungen entscheidet, ob derselbe Schaden wiederkehrt. Diese Frage fragt, ob ernste Vorfälle eine schuldfreie, systemische Nachbetrachtung auslösen, die fragt, wie das System den Ausfall zuließ – oder ob sie still nach einem Einzelnen suchen, dem man die Schuld gibt, was Meldungen in den Untergrund treibt und Wiederholung garantiert. Debattieren Sie, ob Beinahe-Vorfälle und kleine Fehler überhaupt aufgedeckt werden oder nur die Ausfälle, die zu groß zum Verbergen sind; ob Maßnahmen aus Nachbetrachtungen Verantwortliche erhalten und bis zum Abschluss verfolgt oder aufgeschrieben und vergessen werden; und ob Muster in Problem-Management und Design zurückfließen. Bedenken Sie die Parallele zur klinischen Vorfallmeldung und „Just Culture“: Dieselbe Organisation kann bei Patientensicherheitsvorfällen eine reife, schuldfreie Haltung halten, bei IT-Ausfällen aber eine strafende, oder umgekehrt. Eine gute Antwort zeigt eine Lernkultur mit Evidenz – Nachbetrachtungen, die das System verändert haben, geschlossene Maßnahmen, sinkende Wiederkehr – und ein ehrliches Eingeständnis, wo Angst Meldungen noch unterdrückt, denn eine Lernkultur ist selbst eine Kontrolle der Patientensicherheit, kein weiches Extra.

6. Haben wir entschieden, wie dieser Service schließlich stillgelegt wird – solange er noch lebt, um es zu planen? Jeder Service wird irgendwann ersetzt oder abgeschaltet, doch die Außerbetriebnahme ist fast immer ein Nachgedanke, hastig erledigt, wenn der Nachfolger eintrifft und das alte System bereits ein Hindernis ist. Diese Frage fragt, ob Sie für jeden Live-Service einen Plan für sichere Stilllegung haben: Daten nach Aufbewahrungsrecht migriert oder archiviert, Nutzende umgeleitet, Klinikpersonal benachrichtigt sowie Gefährdungsprotokoll und Prüfspur bewahrt. Debattieren Sie die spezifischen Risiken in Gesundheit und Pflege, wenn man es falsch macht – gestrandete Akten, die gesetzliche Aufbewahrungspflichten verletzen, verwaiste Daten, auf die niemand zugreifen kann, ein „vorübergehendes“ Altsystem, das jahrelang ungepatcht fortbesteht, weil niemand sein Ende verantwortet. Bedenken Sie, dass in nationalen und Großunternehmensbeständen Jahrzehnte klinischer Akten in einem System liegen können, das stillgelegt werden muss, ohne eine einzige gesetzlich erforderliche Akte zu verlieren. Eine ehrliche Antwort behandelt die Stilllegung als benannte, finanzierte, prüfbare Operation, ab dem Go-live geplant, nicht als Kosten, die später entdeckt werden, und kann auf mindestens einen Service verweisen, dessen Lebensende bereits entschieden statt aufgeschoben ist.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) betreibt eine gemeinsame Patientenakte, die von Krankenhausklinikpersonal, Hausärztinnen, Gemeindeteams und Notdiensten außerhalb der Sprechzeiten über eine Region hinweg genutzt wird. Sie ging vor zwei Jahren live; das Bauprogramm ist abgeschlossen, und ein ständiges Produkt- und Betriebsteam verantwortet sie nun. Dieses Team hat Servicemanagement auf die harte Tour gelernt.

Anfangs überwachte die Akte nur die Server-Verfügbarkeit. An einem Winterabend waren die Server „grün“, während eine ausfallende Integration still verhinderte, dass Medikationsaktualisierungen der Hausarztpraxen durchflossen – sodass Krankenhausklinikpersonal mehrere Stunden lang veraltete Medikationslisten sah, bevor eine Apothekerin es bemerkte und den Service Desk anrief. Die Nachbetrachtung war schuldfrei und systemisch: Sie fand, dass das eigentliche Problem das Fehlen eines SLI war, das das Erleben der Klinikerin spiegelte. Das Team ergänzte durchgängige Beobachtbarkeit, ein gemeinsam mit einer Clinical Safety Officer vereinbartes SLO für die Aktualität der Daten und einen Alarm, der die Bereitschaft pagt, wenn Aktualisierungen die Sicherheitsschwelle überschreiten. Diese Gefährdung wurde in das Gefährdungsprotokoll des klinischen Risikos aufgenommen (Thema 1.6).

Dann dimensionierten sie ihre Praktiken passend. Routinemäßige, risikoarme Konfigurationsupdates wurden zu standardisierten, vorab genehmigten Änderungen, die über eine automatisierte Pipeline mit schnellem Rollback ausgeliefert werden; nur wirklich riskante Änderungen gehen an eine wöchentliche Change-Prüfung mit klinischer Vertretung. Ein menschlicher Bereitschaftsplan deckt Nächte und Feiertage ab, gestützt auf einen Service Desk, der auf die reale 24/7-Nachfrage ausgestattet ist. Entscheidend ist, dass sie ein klinisches Ausfallverfahren schrieben und nun zweimal jährlich proben: eine schreibgeschützte, zwischengespeicherte Kopie der Schlüsselakten, einen Papier-Rückfall, eine SMS-Kaskade, die dem Klinikpersonal sagt, dass das System beeinträchtigt ist, und einen Abgleichsschritt bei der Wiederherstellung. Als im letzten Frühjahr ein Stromausfall im Rechenzentrum das Primärsystem vierzig Minuten offline nahm, ging die Versorgung auf dem getesteten Rückfall weiter, die Einsatzleiterin führte eine ruhige, koordinierte Reaktion, und keine Patientin und kein Patient kam zu Schaden. Der Vorstand sah einen Zuverlässigkeitsbericht, an Maße der klinischen Sicherheit gebunden, keine vage Beruhigung – und die Verantwortung für den Service bis zur eventuellen Außerbetriebnahme ist benannt und finanziert.

Sektorperspektiven#

Startup#

Ein kleines Health-Tech-Unternehmen hat oft keine separate Betriebsfunktion, sodass „you build it, you run it“ die Voreinstellung statt einer Aspiration ist – dieselben Ingenieure, die den Code schrieben, tragen den Pager. Der Vorteil ist schnelle Rückmeldung und keine Mauer, über die man Arbeit werfen kann; die Gefahr ist ein Zwei-Personen-Bereitschaftsplan, der weder nachhaltig noch sicher ist, und Überwachung, die bei „läuft der Server?“ aufhört. Startups sollten ab dem ersten NHS-Kunden SLOs, grundlegende Beobachtbarkeit, schuldfreie Nachbetrachtungen und ein schriftliches Ausfallverfahren übernehmen, denn ein klinischer Ausfall kann sowohl den Vertrag als auch das Unternehmen beenden. Auch ohne ITIL-Zeremonie ist die Absicht – den Service sehen, schnell reagieren, systemisch lernen, Patientinnen und Patienten sicher halten, wenn er versagt – in der Gesundheit nicht verhandelbar.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – betreibt jeden Tag klinische Live-Systeme, hat aber meist keine eigene IT-Funktion und niemanden, dessen Aufgabe Servicemanagement ist. Hier ist „Betrieb“ in die Ränder der klinischen und Verwaltungsarbeit gequetscht, Bereitschaft ist wirklich „das Handy der Praxismanagerin“, und Überwachung ist ein Klinikmitglied, das bemerkt, dass der Buchungsbildschirm eingefroren ist. Die pragmatischen Prioritäten sind die wenigen Dinge, die Patientinnen und Patienten sicher halten: ein schriftliches, geprobtes Ausfallverfahren (wie die Praxis auf Papier konsultiert und danach abgleicht), ein bekannter Eskalationsweg zu jedem Lieferanten, wenn ein gehostetes System ausfällt, und Klarheit darüber, welche SLAs diese Lieferanten tatsächlich schulden. Ein kleiner unabhängiger Health-Tech-Lieferant jenseits der Startup-Phase steht vor dem Spiegelbild – echte Kunden, die von ihm abhängen, aber dünne operative Abdeckung – und muss trotz knappen Geldes glaubwürdige Supportzeiten und Vorfallreaktion bieten. Die Sorgfaltspflicht ist identisch mit der eines großen Trusts; die Ressourcen sind es nicht, die Disziplin ist daher rücksichtslose Priorisierung der sicherheitskritischen Grundlagen vor ITIL-Vollständigkeit.

Großunternehmen#

Ein NHS Trust oder großer Lieferant betreibt Servicemanagement in seiner vollständigsten Form: ein formaler Service Desk, ITIL-ausgerichtete Incident-/Problem-/Change-Praktiken, Change Advisory Boards, Pläne für Major Incidents und Business Continuity und oft ein 24/7-Betriebszentrum. Die charakteristische Herausforderung ist ein ausuferndes Altsystem mit schwachen Konfigurationsaufzeichnungen, ungepatchten Systemen und unklarer Verantwortung – die Bedingungen, die WannaCry zur Krise machten. Die klassischen Fehler sind Change-Prozesse, die so schwer sind, dass Personal sie umgeht, und ein „Betrieb“, der ständig ausgehungert wird, um den nächsten Bau zu finanzieren. Das Großunternehmen hat die Ressourcen, Beobachtbarkeit, nachhaltige Bereitschaft und getestete Kontinuität ordentlich zu betreiben; die Aufgabe ist daher, die Praktiken verhältnismäßig und wirklich klinisch verantwortet zu halten, statt ein Papierritual, das falsche Sicherheit gibt.

Regierung#

Eine nationale Stelle betreibt Services, die Millionen berühren können; ein Ausfall ist daher ein nationaler Vorfall mit parlamentarischen und Vertrauensfolgen, und Zuverlässigkeitsziele sind Angelegenheiten öffentlicher Rechenschaft. Die Lieferung der Regierung koppelt ITSM mit der Erwartung des GOV.UK Service Manual, dass Live-Services ordentlich betrieben, überwacht und iteriert – nicht beim Start eingefroren – werden, und mit gesetzlichen Pflichten zu Aktenaufbewahrung und Cybersicherheit (NCSC, DSPT). Ausgabenkontrollen und mehrjährige Finanzierungsvereinbarungen prägen, wie „Betriebs“-Finanzierung aussieht, und die schiere Größe erhöht den Einsatz bei Business Continuity, koordinierter Major-Incident-Reaktion und der sicheren Außerbetriebnahme nationaler Altsysteme mit Jahrzehnten an Akten. Der Zielkonflikt ist Assurance und Resilienz versus Geschwindigkeit und Kosten, offen unter Kontrolle aufgelöst.

Häufige Fehlermuster#

• Über die Mauer zum Betrieb werfen. Ein Bauteam übergibt einen Service an ein Betriebsteam, das nie sah, wie er gemacht wurde; Wissen, Verantwortung und Sicherheit fallen durch die Lücke. Gegenmittel: „you build it, you run it“ oder eine bewusste Übergabe mit Gewährleistungsphase und geteilter Bereitschaft.
• Der verwaiste Live-Service. Das Projekt endet, das Team löst sich auf, die Betriebsfinanzierung verdunstet; der Service verrottet, bleibt ungepatcht und sammelt still klinisches und Cyberrisiko an. Gegenmittel: benannte Serviceverantwortliche und geschütztes Betriebsbudget für die Betriebslebensdauer.
• Die Server überwachen, nicht den Service. Alles ist „grün“, während Klinikpersonal veraltete oder fehlende Daten sieht. Gegenmittel: SLIs, die das Erleben der Nutzenden und des Klinikpersonals spiegeln, mit Alarmierung auf Symptome, die zählen.
• Ungetestete Kontinuitätspläne. Ein klinisches Ausfallverfahren existiert auf dem Papier, wurde aber nie geprobt und scheitert am Tag. Gegenmittel: Pläne für Major Incidents und Ausfälle regelmäßig üben und beheben, was bricht.
• Schuldgetriebene Vorfall-Nachbetrachtungen. Fehlersuche treibt Meldungen in den Untergrund und wiederholt den Schaden. Gegenmittel: schuldfreies, systemisches Lernen nach Vorfällen mit verfolgten Maßnahmen.
• Change-Prozess-Theater. Ein Change Board, so schwer, dass Teams es umgehen, oder so leicht, dass riskante Änderungen ungeprüft ausgeliefert werden. Gegenmittel: passend dimensionieren – Standardänderungen vorab genehmigen, Prüfung für wirklich riskante reservieren.
• Keine Konfigurationsaufzeichnung. Niemand kann bei einem Vorfall „was betrifft diese Änderung?“ beantworten. Gegenmittel: eine CMDB oder Gleichwertiges mit Verantwortlichkeit und Abhängigkeiten pflegen.

Reifegradmodell#

Checkliste#

• Jeder Live-Service hat einen benannten Verantwortlichen und ein geschütztes Betriebsbudget für seine Betriebslebensdauer.
• Das Team, das jeden Service betreibt, versteht, wie er gebaut wurde (oder eine dokumentierte Übergabe mit Gewährleistung und geteilter Bereitschaft existiert).
• SLIs und SLOs sind definiert, und die Ziele klinischer Systeme wurden mit Klinikpersonal gesetzt; externe SLAs sind lockerer als interne SLOs.
• Beobachtbarkeit (Logs, Metriken, Traces) und symptombasierte Alarmierung spiegeln das Erleben von Klinikpersonal und Nutzenden, nicht nur den Serverzustand.
• Incident-Management hat Schweregrade, Reaktionsziele, eine Einsatzleitungsrolle und eine einzige Wahrheitsquelle während der Reaktion.
• Problem-Management behebt Grundursachen; Nachbetrachtungen sind schuldfrei, und ihre Maßnahmen werden bis zum Abschluss verfolgt.
• Change-Management ist passend dimensioniert: Standardänderungen vorab genehmigt und automatisiert; nur riskante Änderungen geprüft, mit klinischem Input.
• Verfahren zu Business Continuity und klinischer Ausfallzeit sind geschrieben, mit dem Gefährdungsprotokoll verknüpft und mindestens jährlich geprobt.
• Bereitschaftspläne sind angemessen besetzt, menschlich und fair vergütet; der Service Desk ist auf die reale 24/7-Nachfrage ausgestattet.
• Eine Konfigurationsaufzeichnung (CMDB oder Gleichwertiges) listet Komponenten, Abhängigkeiten, Versionen und Verantwortliche und stützt Sicherheitspatching.
• Ein Plan zur Außerbetriebnahme deckt Datenmigration/-archivierung nach Aufbewahrungsrecht, Umleitung der Nutzenden und Bewahrung von Sicherheits- und Prüfakten ab.

Zentrale Quellen#

• ITIL 4 — das Service Value System und Managementpraktiken (Incident, Problem, Change, Service Desk, Service-Level-Management) — PeopleCert / AXELOS.
• Google — Site Reliability Engineering und The Site Reliability Workbook (SLIs, SLOs, Fehlerbudgets, Bereitschaft, schuldfreie Post-Mortems).
• GOV.UK Service Manual — einen Live-Service betreiben und iterieren; den Status eines Services überwachen; einen Service nach dem Start pflegen.
• NHS England — Standards zum klinischen Risikomanagement DCB0129/DCB0160 und die Behandlung von Systemausfallzeit als klinische Gefährdung (siehe Thema 1.6).
• NHS England / NCSC — Cybersicherheitsbetrieb, das Data Security and Protection Toolkit (DSPT) und Lehren aus dem WannaCry-Vorfall 2017 (siehe Thema 1.7).
• ISO/IEC 20000 (IT-Servicemanagement) und ISO 22301 (Business-Continuity-Managementsysteme).
• DevOps Research and Assessment (DORA) — Fähigkeiten, die Liefer- und Betriebsleistung verbinden (Überwachung, Änderung, Zuverlässigkeit).
• OKRs und KPIs für operatives und Zuverlässigkeitsreporting an die Führung (siehe Thema 10.0 — Objectives & Key Results (OKRs)).

Referenzen#

1. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. Incident management — Wikipedia — https://en.wikipedia.org/wiki/Incident_management
4. Change management (ITSM) — Wikipedia — https://en.wikipedia.org/wiki/Change_management_(ITSM)
5. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
6. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Service-level objective — Wikipedia — https://en.wikipedia.org/wiki/Service-level_objective
9. Service level indicator — Wikipedia — https://en.wikipedia.org/wiki/Service_level_indicator
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
12. Configuration management database — Wikipedia — https://en.wikipedia.org/wiki/Configuration_management_database
13. Help desk — Wikipedia — https://en.wikipedia.org/wiki/Help_desk
14. Site Reliability Engineering (SRE book) — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Google — https://sre.google/books/
15. ITIL 4 Foundation and service management practices — PeopleCert / AXELOS — https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565
16. Service Manual: operating a service and monitoring its status — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
17. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. ISO/IEC 20000-1 — IT service management systems — International Organization for Standardization — https://www.iso.org/standard/70636.html
20. ISO 22301 — Security and resilience: business continuity management systems — International Organization for Standardization — https://www.iso.org/standard/75106.html
21. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/