Was ist passiert?
Ein Mitarbeiter ruft mich an. Schrill brüllt mein Telefon durch die KH-Flure. Der typische Klingelton eines Telefons aus den 2000er Jahren. Klirren in Mono. Ich nehme ab - es insistiert eine mir bekannte Stimme - ein bisschen zu hoch, aber definitiv zu hektisch. Ich dekodiere die Botschaft: Alle Etikettendrucker im Labor stehen still, Probenröhrchen werden seit zwanzig Minuten händisch beschriftet. “Komm bitte schnell” - dann ein erneutes Insistieren des Apparats. Tut tut tut - Leg auf du Hund…
Ich gehe rüber ins Labor, melde mich an als mein Kollege über Druckertreiber zürnt und zum wiederholten Mal die Druckerwarteschlange neu startet. Ich weiß, das kann es nicht sein. Fünf Labordrucker haben gleichzeitig ihren Dienst verweigert. Das kann nur ein Netzwerkproblem sein. Ich versuche ein Etikett zu drucken. Silent Fail. Kalkül oder gewolltes Design-Feature eines in die Jahre gekommenen Windows 3.1 anmutenden User Interfaces. Es ergibt sich, dass die Laborsoftware auf einem Linux Server läuft, der durch den Softwarehersteller administriert wird.
Die Error-Logs aus dem Anwendungsordner sind eindeutig. Druckaufträge bleiben serverseitig hängen und kommen nicht zurück ins Labor an die Netzwerkdrucker. Dokumentation? Forget-It! Ein mysthischer Begriff, behaftet mit alten Flüchen, düsteren Zaubern und der Angst vor dem Stigma der Blasphemie. Es ist ein Tanz auf der Klinge des digitalen Abgrunds und das Einzige, was uns vor dem Absturz bewahrt, ist das schiere Glück der Verdammten.
Wir greifen zum Hörer. Die letzte Instanz. “Der Support” – ein Begriff, der in dieser Branche so viel bedeutet wie‚ Gedanken und Gebete nach einem Flugzeugabsturz. Am anderen Ende meldet sich eine Stimme, so leblos und synthetisch, dass ich vermute, sie wurde direkt aus einer verstaubten Datenbank der frühen 90er extrahiert.
“Haben Sie die PC’s schon neu gestartet?”
Ich spüre, wie mein Puls gegen meine Schläfen hämmert – wie ein eingesperrtes Tier. Ich erkläre ihr die Error-Logs, die hängenden Prozesse, den Linux-Server, die sterbende Hoffnung im Labor. Stille. Ihre Maus klickt verzweifelt durch die Leitung – sie sucht in einem Handbuch, das wahrscheinlich gar nicht existiert oder noch mit einer Schreibmaschine verfasst wurde. So oder so, Sie kennt ihre eigene Software nicht. Sie ist eine Touristin in ihrem eigenen Albtraum.
“Hören Sie bitte gut zu‘, zische ich, während ich den Telefonhörer fast zerquetsche. Das Labor steht still, niemand kann richtig arbeiten, wir brauchen jetzt eine Lösung, es liegt nicht an uns …” Sie unterbricht mich mit der Grazie eines Zirkuselefanten, der soeben die Manege betrat und dessen einzige Aufgabe es ist, wild umsich zu stampfen.
“Die können das ja auch mal von Hand machen”
Die Worte schneiden durch den Lautsprecher des Telefons die betondicke Luft im Labor in Geschnetzeltes. Entsetzte Blicke und eine zum Marsch blasende Infanterie an Mittelfingern schlüpfen durch den Hörer ans andere Ende der Leitung. Es besteht die Möglichkeit eines Telefonattentats. Ich beschwichtige mit Gesten und eskaliere verbal. “Hören Sie, ich brauche jetzt eine verbindliche Zeitangabe mit einer Lösung, ansonsten müssen wir andere Schritte einleiten.”
“15 Minuten” - sie legt auf.
Zwei Minuten voller Empörunug vergehen. Eine Ewigkeit im Vakuum des Scheiterns. Und dann bricht die Hölle los. Ein Geräusch wie maschinengewehrartiges Feuer. Die fünf Drucker kotzen Etiketten in einer Geschwindigkeit aus, die die Gesetze der Physik verspottet. Ein weißer Wasserfall aus Klebepapier ergießt sich über den Boden, die Tische, die fassungslosen Gesichter der Anwesenden. Es folgt Jubel und Dankbarkeit.
Hat die Dame im Support meinen Lösungsvorschlag weitergebeben an jemanden der ihn umsetzen konnte? Wahrscheinlich ja. Das war ein Erfolg. Das war aber auch leider das Problem.
Was ich gesehen habe
Ein Etikettendrucker im Labor druckt patientenbezogene Probenetiketten. Wenn er steht, läuft das Labor händisch weiter – das heißt: Beschriftung mit dem Edding, doppelte Erfassung, Verwechslungsrisiko. Patientenrelevant. Zeitkritisch. Kein Plan B außer „IT anrufen".
Der Mitarbeiter war Erstkontakt. Er hat mich angerufen, weil er nicht wusste, was er tun soll. Keine Diagnose vorher, keine Frage gestellt, keine Logs angesehen. Panik, Anruf, fertig. Ich war zügig am Gerät, der Rest war Routine.
Der Fehler selbst lag nicht mal bei uns. Der Druckspooler beim externen Dienstleister war vollgelaufen. Wir haben das Symptom auf unserer Seite weggeräumt. Die Ursache liegt da, wo wir sie nicht sehen.
Warum das eigentlich das falsche Problem ist
Drei Strukturen sind in dieser Geschichte kaputt. Keine davon ist „der Drucker".
Erstens: der externe Dienstleister. Wir haben keine Sichtbarkeit auf den Spooler-Status. Kein Monitoring, kein Alert, keine Kennzahl. Wir merken den Ausfall, wenn das Labor anruft. Das ist die teuerste Form von Monitoring – Endanwender als Sensor.
Zweitens: das Labor selbst. Ein patientenrelevanter Workflow hängt an komplett von einer einzigen Infrastruktur ab. Keine Redundanz, kein dokumentierter Notfallpfad, der über „händisch beschriften" hinausgeht. Wenn die Probenetikettierung Patientensicherheit berührt, ist das eigentlich ein QM-Thema, kein IT-Thema. Mal ganz von eventuell rechtlichen Aspekten abgesehen.
Drittens: die Triage am IT-Erstkontakt. Der Mitarbeiter ruft direkt den Erfahrenen, weil er den ersten diagnostischen Schritt nicht kann oder kennt. In den fünf Minuten zwischen Anruf und meiner Ankunft hätte er schon am Arbeitsplatz remote Drucker-, Spooler- bzw. Netzwerkverbindung und Errorlogs testen können. Quereinsteiger ohne IT-Erfahrung kommen hier schnell an ihre Grenzen.
Und über all dem schwebt die vierte, eigentliche Falle: das Lob. Lob ist die Belohnung, in eine kaputte Struktur zu springen und sie kurz unsichtbar zu machen. Je öfter ich der bin, der das Loch zustopft, desto profitabler wird es für alle anderen, das Loch nicht zu reparieren. Ich werde zum Single Point of Failure, der das eigentliche Single Point of Failure verdeckt.
Das ist der Klassiker im IT-Support: man fängt als Feuerlöscher an und endet als Brandstifter, weil die Brandmeldeanlage nicht gebaut wird, solange jemand schnell genug rennt.
Was stattdessen passieren müsste
Monitoring beim Dienstleister einfordern. SLA, Statusseite, Alerting. Der Spooler ist Infrastruktur, kein Geheimnis. Wenn der Dienstleister keinen Status liefert, ist das ein Vertragsthema, kein Druckerthema.
Notfallpfad im Labor mit der Laborleitung definieren. Vorrats-Etiketten? Server Redundanz? Dokumentierter Workflow für die ersten fünfzehn Minuten Ausfall, der nicht „IT anrufen und warten" heißt? Das ist QM-Territorium und gehört dort hin.
Triage-Skript für den Erstkontakt. Drei Fragen, die jeder MA im Support vor jedem Anruf an mich beantwortet hat. Drucker erreichbar im Netz – ja/nein? Andere Drucker derselben Marke ebenfalls aus – ja/nein? Spooler-Status sichtbar – ja/nein? Error Logs gecheckt? Wenn er an Frage vier scheitert, weil ihm der Zugriff fehlt oder gar nicht weiß wo diese zu finden sind, ist das auch ein Befund.
Und das Lob runterregeln. Nicht öffentlich, nicht laut. Aber innerlich. Jedes Mal, wenn ich in kurzer Zeit ein Loch zustopfe, das niemand monitort, das keinen Plan B hat und das ein unerfahrener Erstkontakt nicht selbst entschärfen kann, ist das nicht meine Heldentat. Das ist ein Auftrag an drei verschiedene Strukturen, die niemand schreibt, solange ich rechtzeitig da bin.
Das Labor druckt wieder. Das war der einfache Part.