Beim Anbieterwechsel zählt der erste Ausfall mehr als das Übergabeprotokoll

Ein Anbieterwechsel ist nicht fertig, wenn Verträge unterschrieben, Ansprechpartner benannt und Übergabedokumente abgelegt sind. Der echte Test kommt beim ersten Ausfall. Dann zeigt sich, ob der neue Provider die richtigen Abhängigkeiten kennt, ob der Service Desk den Eskalationsweg findet und ob der alte Anbieter noch gebraucht wird, obwohl er offiziell schon raus ist.

Provider Management klingt oft nach Einkauf, Vertragslaufzeit und Service-Level. Für ITSM-Generalisten ist aber die Betriebsübergabe entscheidend. Gemeint ist die Frage, ob ein externer Dienstleister im Störungsfall wirklich handlungsfähig ist. Dazu gehören technische Zugänge, bekannte Schwachstellen, historische Workarounds, Ansprechpartner, Entscheidungsgrenzen und eine klare Reihenfolge für Eskalationen.

Das Übergabeprotokoll beantwortet selten die Ausfallfrage

Ein Übergabeprotokoll dokumentiert, was besprochen, geliefert oder abgenommen wurde. Es ist wichtig, aber es ersetzt keine Ausfallprobe. Im Störungsfall zählen andere Fragen: Wer sieht die Meldung zuerst? Wer darf Änderungen freigeben? Welche Abhängigkeit liegt außerhalb des neuen Vertrags? Welche alte Ausnahme steht nur in einem Ticketverlauf? Welche Rufnummer ist nachts wirklich erreichbar?

Das NIST-Projekt zu Cyber Supply Chain Risk Management beschreibt Lieferkettenrisiken als Thema, das über einzelne Verträge hinausgeht. Für den IT-Betrieb bedeutet das: Ein Provider ist nicht nur ein Vertragspartner, sondern Teil einer Betriebs- und Risikokette. Wenn diese Kette an Übergabepunkten unscharf bleibt, wird der erste Ausfall schnell zum Zuständigkeitsproblem.

Der alte Anbieter verschwindet nicht automatisch aus dem Betrieb

Besonders riskant sind Restabhängigkeiten. Alte Monitoring-Regeln, historische Konfigurationsentscheidungen, nicht dokumentierte Ausnahmen oder Spezialzugänge bleiben oft länger wirksam als die Vertragsbeziehung. Der neue Provider kann dann formal zuständig sein, kennt aber nicht die Ursache. Der alte Provider kennt die Ursache, ist aber nicht mehr klar eingebunden. Dazwischen verliert der Service Desk Zeit.

Deshalb sollte ein Anbieterwechsel nicht nur juristisch und kaufmännisch abgeschlossen werden. Er braucht eine operative Restliste. Darauf stehen bekannte Sonderfälle, nicht übernommene Komponenten, offene Wissenslücken, Altdaten, auslaufende Zugänge und Situationen, in denen der alte Anbieter noch einmal benötigt werden könnte. Diese Liste muss einen Besitzer haben und ein Ablaufdatum, sonst wird sie zur nächsten stillen Schwachstelle.

Eskalationswege müssen vor dem Ernstfall ausprobiert werden

Ein Kontaktblatt wirkt beruhigend, bis niemand weiß, welcher Weg für welchen Fall gilt. Der Service Desk braucht nicht nur Namen, sondern eine belastbare Eskalationslogik. Was ist eine normale Anfrage? Was ist eine kritische Störung? Wer entscheidet über Priorität? Wann wird Management eingeschaltet? Welche Informationen muss das Ticket enthalten, damit der Provider sofort arbeiten kann?

Die CISA-Seite zu Supply Chain Risk Management betont, dass Organisationen Risiken in Lieferketten erkennen, bewerten und steuern müssen. Im ITSM-Alltag wird daraus eine sehr praktische Aufgabe. Die Übergabe muss zeigen, wie ein Risiko im Betrieb erkannt und an die richtige Stelle gebracht wird. Ohne getesteten Eskalationsweg bleibt das Risiko abstrakt, bis ein Ausfall es sichtbar macht.

Servicewissen gehört in Rollen, nicht nur in Dateien

Dokumente helfen nur, wenn jemand sie im richtigen Moment nutzt und pflegt. Ein neuer Provider braucht deshalb klare Rollen auf beiden Seiten. Wer ist Service Owner? Wer entscheidet über Änderungen? Wer bewertet Workarounds? Wer hält die Wissensartikel aktuell? Wer prüft nach 30 oder 60 Tagen, ob die Übergabe im Betrieb wirklich funktioniert?

Hilfreich ist ein kurzer Stabilisierungskorridor nach dem Wechsel. In dieser Phase werden Tickets, Eskalationen, Rückfragen und wiederkehrende Unklarheiten ausdrücklich ausgewertet. Nicht jeder Fehler ist ein Vertragsbruch. Manche Fehler zeigen nur, dass Betriebswissen noch nicht dort angekommen ist, wo es gebraucht wird. Genau diese Lücken müssen früh sichtbar werden.

Der erste Ausfall braucht eine eigene Nachbesprechung

Nach dem ersten relevanten Ausfall sollte nicht nur die technische Ursache besprochen werden. Wichtiger ist die Übergabefrage: Hat der Service Desk richtig geroutet? Hatte der Provider alle Informationen? Waren Berechtigungen vorhanden? Musste der alte Anbieter ungeplant helfen? Haben Eskalationszeiten zum vereinbarten Service-Level gepasst? Gab es Wartezeiten, weil Entscheidungen fehlten?

Das britische NCSC ordnet Supply-Chain-Sicherheit als laufende Steuerungsaufgabe ein, nicht als einmalige Prüfung. Für Providerwechsel heißt das: Die Übergabe endet nicht am Wechseltag. Sie endet erst, wenn der neue Betriebsweg nachweisbar funktioniert und die alten Abhängigkeiten kontrolliert abgebaut sind.

Prüffragen für den nächsten Providerwechsel

• Welche drei Störungsszenarien müssen vor oder kurz nach dem Wechsel getestet werden?
• Welche alten Sonderfälle kennt nur der bisherige Provider?
• Welche Zugänge, Monitoring-Regeln und Wissensartikel haben nach dem Wechsel einen neuen Besitzer?
• Wer entscheidet, wenn Vertrag, Technik und Servicepriorität unterschiedlich bewertet werden?
• Welche Informationen braucht der Provider im Ticket, um ohne Rückfrage zu handeln?
• Wann wird geprüft, ob die Restliste wirklich kleiner geworden ist?

Ein guter Anbieterwechsel nimmt den ersten Ausfall ernst, bevor er passiert. Das Ziel ist nicht Misstrauen gegenüber dem neuen Provider. Das Ziel ist ein Betriebsweg, der unter Druck funktioniert. Wenn Eskalation, Rollen, Restabhängigkeiten und Servicewissen vorab geprüft sind, wird aus dem Übergabeprotokoll ein belastbarer Startpunkt statt ein Ordner für spätere Ausreden.

Quellen und Einordnung: NIST Cyber Supply Chain Risk Management, CISA Supply Chain Risk Management, NCSC Supply Chain Security. Stand der Quellenprüfung: 03.07.2026. Bildquelle: Pexels, Foto-ID 3184292.