Why Are We Still Getting Calls About This? Test-03

☕ Montag, 9:02 Uhr

Der erste Anruf kam aus Berlin. Ein Logistikkoordinator sagte, das Inventarsystem habe die mittlere Ordnung eingefroren. »Wieder«, fügte sie hinzu. Zehn Minuten später kam ein weiterer Anruf – diesmal aus Köln. Das gleiche Problem. Um 9:30 Uhr klingelten die Telefone ununterbrochen. Das System war im halben Land zurückgegangen. Am Service-Desk versuchte Lisa, ruhig zu bleiben. Sie verfolgte den Prozess. Protokolliert die Anrufe. Zugewiesene Kategorien. Setzen Sie Prioritäten. Aber etwas war aus. Die Zwischenwarteschlange füllte sich schnell, doch niemand reagierte flussaufwärts.

🎭 Die unsichtbaren Wände

Lisa wandte sich an das Backend-Team. Keine Antwort. Sie eskalierte. Mark, ein leitender Systemingenieur, antwortete nach zehn Minuten. "Wir untersuchen es", sagte er. „Kannst du mir eine ETA geben?“ „Schau, wir haben 50 andere Dinge auf unserem Teller. Du wirst von uns hören, wenn es etwas zu sagen gibt.“ Gegen Mittag waren die Business-Teams wütend. Service Desk-Agenten entschuldigten sich, stapelten und - leise - Frustration entlüfteten. Es war nicht so, dass es den Menschen egal war. Es war, dass niemand wirklich kollaborierte.

🔍 Was Passierte Wirklich?

Das war kein Technologieproblem. Der Eskalationsweg wurde definiert. SLAs wurden verfolgt. Die Rollen wurden dokumentiert. Aber nichts davon war wichtig.

Denn die Art und Weise, wie die Menschen arbeiten, hat sich nicht verändert.

Die Denkweise in den technischen Teams war: "Es ist nicht meine Aufgabe, Vorfälle zu babysitten." Das Verhalten war passive Vermeidung. Und die Organisation akzeptierte es ruhig.

🧊 Kultur: Der Eisberg, der das Incident Management sank

Was diese Vorfallspirale ausmachte, war kein kaputtes System. Es waren die versteckten Regeln, wie die Menschen funktionierten:

• Die Support-Teams waren überlastet und konzentrierten sich nur auf Projekttermine.
• Niemand hat Wert in der Dokumentation gesehen.
• Es gab keine Praxis, Vorfälle miteinander zu verbinden oder Trends zu kennzeichnen.
• Ladenleiter wurden für das „Weinen des Wolfs“ verantwortlich gemacht – auch wenn echte Misserfolge auftraten.

Am schlimmsten war, dass es nicht das erste Mal war. Das gleiche System war zwei Wochen zuvor gescheitert. Niemand erinnerte sich, weil niemand dafür sorgte, dass die Organisation es tat.

🧭 Also, Was Nun?

Der größte Fehler im Incident Management ist nicht die fehlende Struktur. Es ist der Glaube, dass Struktur allein reicht. Organisationen schreiben oft detaillierte Prozesse und erwarten, dass menschliches Verhalten folgt. Aber es sei denn, dieser Prozess wird durch gemeinsame Verantwortung, Vertrauen und Kommunikation unterstützt - es ist nur Papier. In diesem Fall ergab die Überprüfung nach dem Vorfall:

• Wiederholte Probleme ohne Speicher
• Zwischenfallkategorien, die nichts bedeuteten
• Spezialisten, die nur geschauft haben, wenn sie angeschrien haben
• Und Support-Agenten entschuldigen sich ohne Antworten

🛠 Was Tatsächlich Geholfen Hat

Schließlich, was die Nadel bewegte, war kein neues Werkzeug oder Ticketing-Logik. Es war ein Perspektivenwechsel.

• Teams aus der gesamten Servicekette setzten sich zusammen.
• Sie handelten den Vorfall aus der Sicht jeder Rolle - einschließlich des Filialleiters.
• Zum ersten Mal sahen Backend-Ingenieure die Auswirkungen der Stille.
• Die Leute sprachen. Andere hörten zu.
• Es wurden Vereinbarungen getroffen.

Die Veränderung ist nicht über Nacht passiert. Aber es begann mit etwas Einfachem: Empathie. Von diesem Zeitpunkt an waren Vorfälle nicht nur "Tickets" - sie waren Signale. Und die Menschen reagierten unterschiedlich.

🧩 Abschließender Gedanke

Incident Management bricht nicht zusammen, weil es den Menschen egal ist. Es bricht zusammen, weil die Bedingungen um sie herum die Fürsorge härter machen, als zu ignorieren. Wenn Sie sich fragen, warum die gleichen Probleme immer wieder zurückkehren, ist die Frage vielleicht nicht "Was ist die Ursache des Vorfalls?" Vielleicht ist es "was ist die Ursache dafür, wie wir reagieren?" Das ist keine Prozessfrage. Es ist eine People-Frage.

Ich habe das Buch „ABC of ICT“ von Paul Wilkinson und Jan Schilt angespirgt, das untersucht, wie sich Einstellung, Verhalten und Kultur auf den IT-Erfolg auswirken.