IT-Support auslagern: So prüfen Sie Anbieter

Beispiel: Nach einem Software-Release schlagen Zahlungen fehl. Der Helpdesk kann Tickets annehmen, der Cloud-Anbieter meldet verfügbare Server und das Entwicklungsteam muss die Anwendung prüfen. Wenn Sie IT-Support auslagern, muss das Angebot genau diese Grenzen und Übergaben benennen. Trennen Sie Service Desk, Infrastrukturbetrieb und Anwendungssupport; vergleichen Sie Anbieter anschließend anhand von Zuständigkeit, qualifizierter Reaktion, Wiederherstellung und dokumentiertem Ausstieg.
Dieser Leitfaden hilft Ihnen, den Leistungsumfang zu beschreiben, Zusagen zu prüfen und die Übergabe vorzubereiten. Eine pauschale „Risikoverlagerung“ gibt es nicht: Nach dem BSI-Baustein zur Nutzung von Outsourcing bleibt die Verantwortung für Informationssicherheit bei der auslagernden Organisation.

Welchen Support brauchen Sie wirklich?
- Service Desk
Typischer Umfang: Arbeitsplätze, Konten und Nutzeranfragen
Vor der Anfrage klären: Sprachen, Zeiten, Kanäle, Geräte und Eskalation - Infrastrukturbetrieb
Typischer Umfang: Server, Netzwerk, Cloud und Backup
Vor der Anfrage klären: Überwachung, Patches, Wiederherstellung und Zuständigkeiten - Anwendungssupport
Typischer Umfang: Fehleranalyse, Wartung und Weiterentwicklung einer Software
Vor der Anfrage klären: Codezugang, Dokumentation, Releases und Übergabe an Entwicklung
Ein Anbieter kann einzelne Bereiche abdecken, ohne alle drei zu übernehmen. Prüfen Sie deshalb das konkrete Angebot statt einer allgemeinen Bezeichnung wie „Managed IT“.
Welche Zusagen gehören in den Vertrag?
Eine schnelle Ticketbestätigung ist keine schnelle Lösung. Definieren Sie Prioritäten anhand der geschäftlichen Auswirkung: Was gilt als kritischer Ausfall? Wann beginnt die Reaktionszeit? Wann übernimmt ein qualifizierter Mensch? Welche Zwischenlösung ist zulässig? Wer informiert die Betroffenen und in welchem Rhythmus?
Für kritische Systeme brauchen Sie zusätzlich vereinbarte Ziele für Wiederanlauf und Datenverlust sowie einen getesteten Wiederherstellungsweg. Lassen Sie sich einen Beispielbericht zeigen: Er sollte Fälle, tatsächliche Reaktions- und Lösungszeiten, wiederkehrende Ursachen und offene Risiken trennen. Eine pauschale Garantie für „störungsfreien Betrieb“ ist keine brauchbare Leistungsbeschreibung.
Sicherheit, Übergabe und Ausstieg prüfen
- Zugänge: Welche Rechte erhält der Anbieter, wie werden sie protokolliert und beim Vertragsende entzogen?
- Dokumentation: Wo liegen Architektur, Konfiguration, Runbooks und Zugangsinventar? Wer kann sie exportieren?
- Unterauftragnehmer: Welche Aufgaben geben weitere Dienstleister weiter, und wer koordiniert einen Vorfall?
- Wiederherstellung: Wann wurde ein Restore zuletzt getestet und welche Systeme waren umfasst?
- Exit: Wie lange unterstützt der Anbieter den Wechsel und in welchem Format übergibt er Daten und Betriebswissen?
Planen Sie eine Übergangsphase mit gemeinsamem Ticket-Review und klaren Abnahmekriterien. Die Qualität zeigt sich daran, ob das interne Team nach der Übergabe noch weiß, wer bei welchem Fehler handelt. Für den breiteren Entscheid zwischen interner und externer Leistung lesen Sie auch unseren Leitfaden zu IT-Outsourcing-Modellen.
Zwei Angebote fair vergleichen
Schicken Sie beiden Anbietern denselben anonymisierten Vorfall: Die Auftragsanwendung ist an einem Werktag zwei Stunden nicht erreichbar. Fragen Sie, wann sie den Fall annehmen, wer die Ursache eingrenzt, wie sie den Betrieb wiederherstellen und wer Kunden sowie Geschäftsführung informiert. Fordern Sie eine Beispiel-Eskalation und einen Bericht über einen ähnlichen Vorfall an.
Bewerten Sie nicht nur die zugesagte Minutenangabe. Ein Angebot mit 15 Minuten Eingangsbestätigung und unklarer Entstörung kann schwächer sein als eines mit 30 Minuten qualifizierter Reaktion, klaren Wiederanlaufzielen und geübtem Restore. Die passende Gewichtung hängt davon ab, wie teuer dieser konkrete Ausfall für Sie ist.
Fragen Sie nach Leistungen außerhalb der Pauschale: größere Versionswechsel, neue Standorte, Datenmigrationen, Sicherheitsvorfälle und Unterstützung beim Anbieterwechsel. So wird aus einem günstigen Monatspreis eine realistische Vergleichsbasis.
Ein Vorfall zeigt, wo der Vertrag endet
Für individuell entwickelte Software ist die wichtigste Grenze oft nicht die Ticketannahme, sondern die Übergabe zwischen Anwendung, Cloud-Betrieb und einem fremden Dienst. Geben Sie jedem Bieter denselben Fall: Nach einem Release schlagen Zahlungen fehl; der Cloud-Dienst ist erreichbar, die Anwendung meldet einen Fehler beim Zahlungsanbieter. Wer stoppt weitere Releases, wer prüft Logs und Transaktionen, wer spricht mit dem Zahlungsanbieter und wer entscheidet über einen Rollback? Lassen Sie Zuständigkeit und Uhrzeit für jeden Schritt schriftlich zuordnen.
Ein brauchbarer Nachweis enthält mindestens Alarmzeit, erste qualifizierte Diagnose, Entscheidung, Zwischenlösung, Wiederherstellung und Nachbereitung. Fragen Sie, was der Anbieter selbst leisten kann und welchen Beitrag Ihr Team oder ein Dritter liefern muss. Die Cloud-Hosting-Prüfung ergänzt diese Abgrenzung um Konten, Backups und Restore. Wenn Sie primär eine eigene Anwendung betreuen lassen wollen, schreiben Sie „Anwendungssupport und Weiterentwicklung“ in die Anfrage statt eines unbestimmten „IT-Supports“.
Eine einseitige Leistungsbeschreibung für die Anfrage
Geben Sie jedem Anbieter dieselbe knappe Ausgangslage: betroffene Systeme, Nutzerzahl als Größenordnung, Standorte, Supportzeiten, kritische Abläufe und bekannte Fremdanbieter. Ergänzen Sie, welche Aufgaben intern bleiben und welche Rechte ein externer Dienstleister erhält. Beschreiben Sie einen typischen Vorfall und einen kritischen Ausfall mit geschäftlicher Wirkung. So müssen Anbieter Annahmen offenlegen, statt eine unpassende Standardpauschale zu bepreisen.
Fordern Sie für beide Fälle dieselben Nachweise: Eingang und Priorisierung, zuständige Rolle, Eskalation, Kommunikation, Wiederherstellung und Dokumentation danach. Bitten Sie um eine getrennte Liste der einmaligen Übergabe, monatlichen Leistung und Arbeit außerhalb des Vertrags. Ein Angebot ist erst vergleichbar, wenn auch Abhängigkeiten von Ihrem Team, eingesetzte Unterauftragnehmer und der Rückweg bei Vertragsende sichtbar sind.
Häufige Fragen
Brauchen wir wirklich einen Support rund um die Uhr?
Nur wenn ein Ausfall außerhalb der Geschäftszeiten relevante Folgen hat und dann auch jemand handeln kann. Legen Sie für jedes kritische System fest, wer einen Alarm annimmt, welche Entscheidung die Person treffen darf und wie sie Fachleute erreicht. Eine ständig erreichbare Ticketannahme ist noch keine durchgehende Entstörung.
Was unterscheidet Reaktionszeit und Wiederherstellungszeit?
Die Reaktionszeit sagt, wann der Anbieter einen Vorfall qualifiziert aufnimmt. Die Wiederherstellungszeit beschreibt, bis wann ein vereinbarter Dienst wieder nutzbar sein soll. Definieren Sie Priorität, Startpunkt, Messung, Ausnahmen und Zwischenlösung getrennt. Fragen Sie nach Berichten über tatsächlich erreichte Werte, nicht nur nach einer Zahl im Angebot.
Was passiert mit offenen Tickets beim Anbieterwechsel?
Vereinbaren Sie vorab eine exportierbare Liste mit Status, Priorität, Verlauf, Zuständigkeit und nächstem Schritt. Ein gemeinsamer Übergabetermin sollte kritische Fälle und wiederkehrende Ursachen einzeln durchgehen. Zugänge werden erst entzogen, wenn die vereinbarte Übergabe und der sichere Weiterbetrieb geprüft sind.
Wann passt Scorpion Power?
Scorpion Power beschreibt auf seiner Leistungsseite Wartung, Support und Weiterentwicklung von Web- und Softwarelösungen. Wenn es um eine Anwendung, ihre Integrationen oder die Zusammenarbeit mit einem Entwicklungsteam geht, können wir den Bedarf mit Ihnen eingrenzen. Suchen Sie einen allgemeinen 24/7-Helpdesk für Arbeitsplätze und Netzwerke, verlangen Sie ein ausdrücklich dafür ausgewiesenes Angebot mit belegter Abdeckung.
Beschreiben Sie uns die betroffene Anwendung und Ihr Supportziel. Wir sagen Ihnen im Erstgespräch, welche Teile wir übernehmen können und wo ein anderer Spezialist nötig ist.