Wenn im Störfall niemand zuständig ist

Die Systeme laufen. Die Verträge sind unterschrieben und für jeden Service gibt es einen Ansprechpartner. Kennst Du diese Situationen? Das System steht still. Intern heisst es, das Problem liege beim externen System. Extern heisst es, die Ursache liege bei Euch. Und dazwischen wartet die Produktion. Das eigentliche Problem liegt aber in der Schnittstelle dazwischen und dafür scheint sich niemand wirklich verantwortlich zu fühlen. Denn jeder kennt seinen eigenen Bereich, aber niemand hat den Gesamtüberblick. 

Auf dieser Seite erfährst Du:

• warum Störungen im Betrieb eskalieren, obwohl alle Partner reagieren
• Welche Arten von Abhängigkeiten im Betrieb wirklich eine Rolle spielen
• was ein SLA leistet und was eben nicht
• wie Du Abhängigkeiten sichtbar machst und Verantwortung klärst
• wie sich Dein Betrieb anfühlen sollte

Im Alltag läuft alles. Bis zu dem Moment, in dem ein Prozess plötzlich steht und niemand sofort sagen kann, wo die Ursache liegt.

Typische Situationen aus dem Betrieb:

• Ein Produktionssystem liefert keine Daten mehr und die Fertigung steht still
• Eine ERP-Schnittstelle fällt aus und Aufträge bleiben hängen
• Mitarbeitende können sich nicht mehr anmelden und die Arbeit stoppt
• Ein Drittsystem reagiert nicht und Dein System kann nicht weiterarbeiten
• Eine Änderung in der Infrastruktur löst Fehler in mehreren Anwendungen aus

Dann beginnt die bekannte Telefonkette. Intern wird geprüft. Externe Partner werden kontaktiert. Hersteller-Support wird eingeschaltet. Alle arbeiten, aber es fehlt der Überblick, wie alles zusammenhängt. Genau das macht Störungen teuer.

Wenn Abhängigkeiten und Zuständigkeiten unklar sind, wird eine Störung schnell zu einem «Unternehmensproblem». Das Risiko entsteht nicht nur durch den Ausfall selbst, sondern durch die Verzögerung, bis klar ist, wer was lösen muss.

Dieses Problem entsteht nicht an einem einzelnen Punkt. Es ist das Resultat vieler Einzelentscheidungen, die über Jahre hinweg nie im Gesamtbild des Betriebs bewertet wurden.

Isolierte Entscheidungen ohne Blick auf die Gesamtwirkung

API anbinden ohne Abhängigkeiten zu prüfen, Drittsystem integrieren ohne klare Zuständigkeit, Hosting auslagern ohne SLA-Auswirkungen zu klären oder System erweitern ohne Dokumentation und Betriebsabläufe zu aktualisieren: So entsteht eine Systemlandschaft, die im Alltag funktioniert, im Ernstfall aber schwer steuerbar ist, weil Zuständigkeiten, Abhängigkeiten und Abläufe nicht mitgewachsen sind.

Verantwortung entsteht zufällig statt strukturiert

Solange es läuft, fühlt sich niemand gezwungen, diese Fragen sauber zu klären:

• Wer trägt die Gesamtverantwortung für den Betrieb der Kette?
• Wer eskaliert wann zu welchem Partner?
• Wer entscheidet, wenn mehrere Parteien involviert sind?
• Wer kennt die Abhängigkeiten durchgängig vom Auslöser bis zur Wirkung?

Wissen und Dokumentation halten nicht Schritt

Mit jeder Erweiterung wächst die Komplexität. Dokumentation wird nicht konsequent nachgeführt. Wissen bleibt bei einzelnen Personen. Neue Mitarbeitende verstehen nur Teile. Externe Partner kennen nur ihren Ausschnitt. Im Störfall fehlt dann das Gesamtverständnis, das für schnelle Behebung entscheidend wäre.

Im Betrieb existieren zwei Ebenen, die selten gemeinsam betrachtet werden. Abhängigkeiten sind alle Verbindungen, die dafür sorgen, dass Dein System funktioniert. Das sind technische Verbindungen wie Schnittstellen und Infrastruktur, aber auch organisatorische und vertragliche Verbindungen wie Hersteller-Support, Partner, Zuständigkeiten und Eskalationswege.

Verantwortung im Betrieb bedeutet, dass klar ist, wer im Störfall welchen Teil der Kette verantwortet, wer entscheiden darf und wer die Wiederherstellung des Betriebs steuert. Erst wenn beide Ebenen zusammen gedacht werden, entsteht echte Betriebssicherheit.

Viele Unternehmen wissen, dass ihre Systeme voneinander abhängen. Und viele haben SLAs mit Partnern und Herstellern. Im Ernstfall zeigt sich aber, ob diese SLAs die reale Abhängigkeitskette abdecken oder nur einzelne Teile. Genau an dieser Stelle entscheidet sich, ob ein Incident sauber gelöst wird oder zur Eskalation wird.

Was bedeutet SLA im IT-Betrieb wirklich

SLA steht für Service Level Agreement. Es ist eine vertragliche Vereinbarung zwischen Dir und einem Dienstleister, die definiert, welche Betriebsleistung garantiert wird.

Typische Inhalte sind Verfügbarkeit, Reaktionszeiten, Wiederherstellungszeiten, Support-Zeiten, Eskalationsstufen und Kommunikationswege. Ein SLA beschreibt damit, wie schnell jemand reagieren muss und welche Leistung zugesichert ist. Es beschreibt aber nicht automatisch, wer entlang der gesamten Systemkette verantwortlich ist, wenn die Ursache zwischen mehreren Systemen liegt.

Warum SLAs im Ernstfall oft nicht helfen

Viele Unternehmen haben SLAs, und trotzdem dauern Störungen lange. Der Grund ist, dass Verantwortungen entlang der Kette nicht eindeutig sind.

Ein typisches Muster:

• Das Hosting-SLA greift, aber die Ursache liegt in einer Schnittstelle
• Der Hersteller-Support reagiert, aber die Infrastruktur ist der Engpass
• Mehrere Partner sind involviert und jeder betrachtet nur seinen Teil
• Niemand steuert die Kette durchgängig.

Hier geht es nicht um mehr Dokumentation. Es geht um Betriebstransparenz und klare Steuerbarkeit im Ernstfall.

Technische Lösungsansätze
Eine vollständige Abhängigkeitskarte zeigt, welche Systeme, Schnittstellen und Komponenten an einem Prozess hängen. Kritische Punkte wie «Single Points-of-Failure» werden sichtbar. Upstream- und Downstream-Verbindungen werden verständlich, so dass Du Auswirkungen einer Störung oder Änderung sofort abschätzen kannst. Jede Abhängigkeit erhält eine Bewertung, wie kritisch sie ist und wie sie abgesichert ist.

Organisatorische Lösungsansätze
Zuständigkeiten werden entlang der Kette definiert, intern und extern. Eskalationswege sind klar und geübt. SLAs werden so angepasst, dass sie die realen Abhängigkeiten abdecken, statt nur einzelne Vertragsinseln. Betrieb wird steuerbar, auch wenn Personen wechseln oder Partner ersetzt werden.

Zielbild: Wie sollte sich Dein Betrieb anfühlen?

Im Ernstfall gibt es keine Telefonkette mehr, um Zuständigkeiten zu suchen. Statt Unsicherheit gibt es Orientierung:

• Du weisst, welche Abhängigkeit welchen Prozess beeinflusst
• Du weisst sofort, wer bei welcher Störung zuständig ist
• Eskalation läuft strukturiert und schnell
• SLAs greifen, weil sie zur Systemkette passen
• Betrieb bleibt stabil, auch wenn Schlüsselpersonen fehlen

Betriebssicherheit entsteht, wenn Systemlandschaft, Verantwortung und SLAs zusammen gedacht werden.