Entscheidungsvergleich

Make-or-Buy in der IT: Der Stundensatz entscheidet nicht

Wie Mittelständler interne, externe und gemeinsame IT-Leistung nach Fähigkeit, Steuerbarkeit, Gesamtkosten, Risiko und Ausstieg vergleichen.

„Der Dienstleister kostet weniger pro Stunde als ein interner Administrator.“ Der Satz klingt nach einer wirtschaftlichen Entscheidung. Tatsächlich vergleicht er nur zwei Preise, deren Leistungsumfang häufig nicht derselbe ist.

Interne Arbeitszeit enthält Kontextwissen, Abstimmung, Vertretung und Bereitschaft – oder eben erkennbare Lücken darin. Ein externer Stundensatz kann nur die beauftragte Bearbeitung umfassen; Koordination, Vertragssteuerung, Zugänge, Dokumentation, Notfälle und Übergabe kommen hinzu. Umgekehrt kann ein spezialisierter Anbieter Fähigkeiten, Werkzeuge und Abdeckung bereitstellen, die intern unverhältnismäßig teuer wären.

Make-or-Buy ist daher keine Grundsatzfrage „eigene IT oder Outsourcing“. Sie muss für einen klar abgegrenzten Service oder Leistungsteil beantwortet werden.

Erst die Leistung schneiden, dann die Optionen vergleichen

„Wir lagern den IT-Betrieb aus“ ist zu grob. Schon der Betrieb eines einzelnen Systems kann unterschiedliche Leistungsbausteine enthalten:

  • fachliche Serviceverantwortung,
  • Plattformadministration,
  • Benutzer- und Berechtigungsverwaltung,
  • Monitoring und Erstreaktion,
  • Patch- und Schwachstellenmanagement,
  • Backup und Wiederherstellung,
  • Störungsanalyse und Eskalation,
  • Changes und Releases,
  • Hersteller- und Lizenzsteuerung,
  • Dokumentation, Reporting und Verbesserung.

Diese Bausteine können intern, extern oder gemeinsam erbracht werden. Die Entscheidung wird besser, wenn nicht ganze Abteilungen, sondern konkrete Verantwortungsgrenzen betrachtet werden.

Der NCSC-Leitfaden zur Auswahl eines Managed Service Providers fordert unter anderem klare Rollen, Leistungsvereinbarungen, Incident-Meldung, Reporting, minimale Rechte, Wiederherstellung und Regeln für das Vertragsende. Der Leitfaden ist auf britische kleine und mittlere Organisationen ausgerichtet. Seine Kernfrage ist allgemein übertragbar: Was genau übernimmt der Dienstleister – und was bleibt beim Kunden?

Drei Betriebsmodelle statt einer falschen Zweiteilung

Intern

Die Organisation beschäftigt und steuert die notwendigen Rollen selbst. Das kann besonders sinnvoll sein, wenn:

  • die Leistung eng mit geschäftskritischen Prozessen verbunden ist,
  • häufig Kontextwissen und schnelle Abstimmung benötigt werden,
  • das Unternehmen die Fähigkeit strategisch erhalten will,
  • Bedarf und Auslastung hinreichend dauerhaft sind,
  • geeignete Mitarbeitende gewonnen und vertreten werden können.

Interner Betrieb bedeutet nicht automatisch bessere Kontrolle. Fehlen Vertretung, Dokumentation, Monitoring oder klare Rechte, kann eine interne Ein-Personen-Abhängigkeit schlechter steuerbar sein als ein guter externer Service.

Extern

Ein Anbieter erbringt den definierten Leistungsteil. Das kann sinnvoll sein, wenn:

  • spezialisierte Kompetenz nur punktuell benötigt wird,
  • eine breitere zeitliche Abdeckung nötig ist,
  • Leistung und Qualität gut beschreibbar sind,
  • Standards und Skaleneffekte tatsächlich nutzbar sind,
  • der Markt mehrere tragfähige Anbieter und einen realistischen Wechselweg bietet.

Ein Vertrag überträgt Aufgaben. Er überträgt nicht automatisch die Verantwortung der Organisation für ihren Geschäftsbetrieb, ihre Daten oder die Auswahl angemessener Kontrollen.

Gemeinsam oder Co-managed

Viele belastbare Modelle liegen dazwischen. Die IT behält Service-Ownership, Architektur, Priorisierung und kritisches Kontextwissen. Ein Dienstleister übernimmt beispielsweise Monitoring, standardisierte Administration oder definierte Rufbereitschaft.

Das kann Spezialisierung und interne Steuerungsfähigkeit verbinden. Es funktioniert aber nur mit eindeutigen Übergaben. „Beide kümmern sich“ ist kein Co-Management, sondern eine Zuständigkeitslücke.

Acht Entscheidungsfelder

1. Geschäftswirkung und Kritikalität

Zuerst ist zu klären, welche Geschäftsleistung vom Service abhängt. Wie wirkt ein Ausfall? Welche Antwort- und Wiederherstellungszeiten werden wirklich benötigt? Welche Entscheidungen müssen in einer Störung schnell fallen?

Der ITSM-Beitrag beschreibt IT-Services als geschäftsbezogene Leistungen. Genau auf dieser Ebene sollte Make-or-Buy beginnen. Der Server ist kein ausreichender Entscheidungsgegenstand, wenn eigentlich die Verfügbarkeit der Warenwirtschaft gesteuert werden muss.

2. Benötigte Fähigkeit

Nicht jede Kompetenz muss dauerhaft intern vorhanden sein. Aber die Organisation muss wissen, welche Fähigkeit sie abgibt und welche sie behalten muss.

Zu prüfen sind:

  • fachliches und technisches Kontextwissen,
  • Architektur- und Integrationsverständnis,
  • Hersteller- oder Spezialzertifizierung,
  • Störungs- und Wiederherstellungsfähigkeit,
  • Vertrags- und Lieferantensteuerung,
  • Fähigkeit, Leistung und Risiken unabhängig zu beurteilen.

Wer die gesamte Beurteilungsfähigkeit auslagert, kann später kaum erkennen, ob der Service angemessen erbracht wird.

3. Nachfrage und Abdeckung

Ein interner Vollzeitbedarf ist anders zu bewerten als wenige spezialisierte Einsätze. Ebenso verändert eine notwendige Abdeckung außerhalb der Geschäftszeit die Optionen.

Verglichen werden sollten reale Szenarien:

  • Normalbetrieb,
  • Lastspitze oder Projektphase,
  • Urlaub und Krankheit,
  • kritischer Incident,
  • parallele Störungen,
  • notwendige Rufbereitschaft.

Ein niedriger Stundensatz hilft nicht, wenn die benötigte Reaktionszeit nicht vertraglich und operativ erreichbar ist.

4. Steuerbarkeit und Entscheidungsrechte

Für jeden Leistungsteil muss feststehen:

  • Wer priorisiert?
  • Wer darf einen produktiven Change freigeben?
  • Wer genehmigt privilegierte Zugriffe?
  • Wer entscheidet über Risikoakzeptanz und Notfallmaßnahmen?
  • Wer nimmt die Leistung ab?

Der Dienstleister benötigt technische Berechtigungen, aber nicht automatisch das fachliche Entscheidungsrecht. Der Beitrag zu Verantwortlichkeiten zeigt, warum diese Ebenen getrennt werden müssen.

5. Sicherheit und Lieferkette

Externe Leistung erweitert die Lieferkette. Das ist kein pauschales Gegenargument, aber ein eigener Risikobereich.

NIST SP 800-161 Rev. 1 Update 1 behandelt Risiken von Produkten und Services über Entwicklung, Integration, Betrieb und weitere Lieferstufen. Für einen Mittelständler bedeutet das pragmatisch:

  • Welche Unterauftragnehmer sind beteiligt?
  • Welche Systeme und Daten kann der Anbieter erreichen?
  • Wie werden privilegierte Konten geschützt und entzogen?
  • Welche Protokolle und Nachweise sind verfügbar?
  • Wie werden Sicherheitsvorfälle gemeldet?
  • Wie ist die Wiederherstellung getestet?

Der Maßstab muss zur Kritikalität des Services passen. Eine Lieferkette für eine unkritische Standardleistung braucht nicht dieselbe Tiefe wie der privilegierte Betrieb zentraler Identitäts- und Backup-Systeme.

6. Vollständige Kosten

Beim internen Modell gehören mindestens dazu:

  • Gehalt und Lohnnebenkosten,
  • Rekrutierung, Einarbeitung und Weiterbildung,
  • Werkzeuge, Lizenzen und Arbeitsmittel,
  • Vertretung, Bereitschaft und Führung,
  • nicht produktiv verrechenbare Betriebs- und Abstimmungszeit.

Beim externen Modell gehören mindestens dazu:

  • Grund- und Verbrauchsentgelte,
  • Einführungs- und Übergabekosten,
  • Zusatzleistungen außerhalb des Vertrags,
  • interne Service- und Lieferantensteuerung,
  • Sicherheits- und Qualitätsprüfungen,
  • Änderungen, Eskalationen und Exit.

Der Artikel zu IT-Kosten zeigt, wie interne Arbeitskosten und Leistungskennzahlen zusammengeführt werden können. Die Make-or-Buy-Entscheidung braucht dasselbe Prinzip: vergleichbare Kosten für einen vergleichbaren Leistungsumfang.

7. Wissen und Personenabhängigkeit

Auslagerung kann Personenabhängigkeit reduzieren, wenn der Anbieter dokumentierte Prozesse und mehrere qualifizierte Mitarbeitende bereitstellt. Sie kann eine neue Abhängigkeit schaffen, wenn Wissen nur beim Dienstleister liegt und nicht übertragbar ist.

Deshalb sollte festgelegt werden:

  • welche Dokumentation dem Unternehmen gehört,
  • wie Änderungen und Entscheidungen nachvollzogen werden,
  • welche Kenntnisse intern erhalten bleiben,
  • wie Vertretung auf beiden Seiten funktioniert,
  • wie regelmäßig Wissen und Unterlagen geprüft werden.

8. Ausstieg und Reversibilität

Eine gute Einstiegsentscheidung enthält einen Ausstieg:

  • Welche Daten, Konfigurationen und Protokolle werden herausgegeben?
  • In welchem Format?
  • Wer unterstützt die Übergabe und zu welchen Kosten?
  • Wie werden Konten und Zugänge entzogen?
  • Welche Übergangszeit ist realistisch?
  • Kann ein anderer Anbieter oder ein internes Team übernehmen?

Der Technology Code of Practice fordert die Betrachtung des vollständigen Technologie-Lebenszyklus. Für Make-or-Buy heißt das: Die wirtschaftliche Bewertung endet nicht mit Vertragsunterschrift oder Go-live.

Konstruiertes Beispiel: Günstiger Support ohne Servicegrenze

Das folgende Beispiel ist konstruiert.

Ein Unternehmen vergleicht die Kosten eines internen Administrators mit einem externen Supportangebot. Der externe Stundensatz erscheint günstiger. Im Angebot steht „Administration nach Aufwand“.

Offen bleiben:

  • Wer überwacht Systeme und beginnt ohne Ticket mit der Reaktion?
  • Wer bewertet und installiert kritische Patches?
  • Welche Antwortzeit gilt außerhalb der Bürozeiten?
  • Wer darf produktive Änderungen freigeben?
  • Wo liegen aktuelle Dokumentation und Notfallzugänge?
  • Was geschieht beim Vertragsende?

Nach dem Service-Zuschnitt wird die Entscheidung differenzierter. Standardisierte Wartungsaufgaben und Erstreaktion können extern sinnvoll sein. Service-Ownership, Priorisierung, Architektur und kritische Freigaben bleiben intern. Für den Notfall wird eine konkrete Abdeckung vereinbart.

Das Beispiel beweist weder, dass ein Mischmodell immer günstiger ist, noch dass Outsourcing überlegen wäre. Es zeigt nur: Erst eine vergleichbare Leistung erlaubt einen belastbaren Kostenvergleich.

Eine Entscheidungsmatrix ohne Scheingenauigkeit

Kriterium Intern Extern Gemeinsam
Geschäftskontext häufig direkt verfügbar muss übertragen und gepflegt werden intern verankert, extern nutzbar
Spezialkompetenz nur bei dauerhaftem Aufbau oft flexibel zugänglich gezielter Zukauf
zeitliche Abdeckung erfordert Vertretung und Bereitschaft vertraglich skalierbar, kostet entsprechend geteilte Abdeckung
Steuerung direkte Führung, aber interne Engpässe möglich klare Leistungs- und Vertragssteuerung nötig Übergaben besonders wichtig
Kostenstruktur höherer fixer Anteil stärker vertrags- und verbrauchsabhängig doppelte Schnittstellen möglich
Abhängigkeit von Mitarbeitenden und internem Wissen von Anbieter und Lieferkette Abhängigkeit verteilt
Ausstieg Rekrutierung und Wissensaufbau Daten-, Wissens- und Vertragsübergabe Übernahmegrenzen vorab definieren

Die Matrix sollte keine universelle Gesamtpunktzahl erzeugen. Ein nicht beherrschbares Sicherheits- oder Ausstiegsrisiko darf nicht durch einen günstigen Preis „überpunktet“ werden.

Wann der Preis tatsächlich entscheiden darf

Bei einer standardisierten und gut abgrenzbaren Leistung kann der Preis ein starkes Kriterium sein. Dafür müssen jedoch vergleichbar feststehen:

  • Umfang und Ausschlüsse,
  • Mengengerüst,
  • Servicezeiten und Qualität,
  • Rollen und Übergaben,
  • Sicherheitsanforderungen,
  • Reporting und Nachweise,
  • Änderungs- und Beendigungsregeln.

Dann ist der Preis nicht mehr Ersatz für die Leistungsbeschreibung, sondern Teil einer echten wirtschaftlichen Wahl.

Der erste sinnvolle Schritt lautet daher nicht „Angebote einholen“. Beschreiben Sie auf einer Seite den betroffenen IT-Service, seine Leistungsteile, Kritikalität, Entscheidungsrechte, benötigte Abdeckung und den gewünschten Exit. Erst danach lässt sich seriös entscheiden, was intern bleiben, extern erbracht oder gemeinsam organisiert werden soll.

Quellen

  1. Choosing a managed service provider (MSP) – UK National Cyber Security Centre
  2. NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations – National Institute of Standards and Technology
  3. The Technology Code of Practice – UK Government Digital Service
  4. Digital and Data Benefits Framework – UK Government