IT-Outsourcing — Warum viele Business Cases das falsche Modell finanzieren
LCC-Outsourcing verspricht Kostensenkung durch günstige Delivery. In der Praxis liefert es häufig das Gegenteil — weil der Business Case ein Modell einkauft, dessen Incentives, Kompetenzstruktur, Delivery-Mindset und Governance-Logik strukturell falsch konstruiert sind.
Das Problem ist kein Ausführungsversagen und kein schwieriger Provider. Es ist ein Denkfehler im Modell selbst: Der Business Case rechnet den Inputpreis präzise — und die Kosten des Modells erstaunlich unpräzise.
»Der niedrige Preis des LCC-Modells ist real. Die Kosten seiner Konstruktionsfehler stehen in keinem Business Case.«
Die Motive — und ihr blinder Fleck
Die Motive hinter Outsourcing-Entscheidungen sind selten irrational. IT-Organisationen sind historisch gewachsen, schwer vergleichbar und oft nicht ausreichend steuerbar. Der Druck, das zu ändern, ist berechtigt.
Die Ziele lassen sich in zwei Gruppen fassen:
- IT-Kosten variabilisieren: interne Fixkosten in variable externe Kosten überführen
- Headcount im indirekten Bereich reduzieren
- Nicht-differenzierende Leistungen aus dem eigenen Managementfokus entfernen
- Kostendruck auf Helpdesk, Client Services, Standardbetrieb und klassische Infrastruktur erhöhen
- IT-Kosten vergleichbarer und planbarer machen
- Transparenz schaffen: alles Messbare messbar machen
- Klare KPIs, SLAs und Reporting-Strukturen etablieren
- Prozesse härten, Ticketpflicht und definierte Eingangskanäle erzwingen
- Informelle Arbeitsweisen und Zuruf-Modelle strukturell zurückdrängen
- Standardisierung forcieren und Verantwortlichkeiten formal sauberer strukturieren
- Betrieb kontrollierbar, vergleichbar und steuerbar machen
Der Fehler beginnt nicht beim Ziel. Er beginnt beim Modell, mit dem das Ziel erreicht werden soll.
Indirekter Effekt, den Business Cases selten benennen: Der Strukturierungsdruck eines Outsourcing-Programms erzwingt, was im normalen Betrieb oft unterbleibt: Ticketvolumen wird sichtbar und messbar, Wissen wird dokumentiert, Prozesse und Notfallprozeduren werden geschärft, Ownership-Lücken werden benannt, Automatisierung wird überhaupt erst ernsthaft diskutiert. Diese positiven Effekte kommen nicht aus der Delivery des Providers. Sie entstehen aus dem Zwang zur Formalisierung, den das Programm erzeugt — unabhängig davon, ob das Outsourcing selbst gelingt.
Der architektonische Fehler: Vier strukturelle Mängel des LCC-Modells
LCC-Outsourcing scheitert häufig nicht an schlechter Ausführung oder schwierigen Providern. Es scheitert, weil das Modell selbst auf vier strukturellen Konstruktionsfehlern aufgebaut ist — unabhängig davon, welcher Provider es betreibt.
Incentive Misalignment: Das falsche Anreizmodell
Das gebräuchlichste Preismodell im LCC-Outsourcing ist Unit-based Pricing: Preis pro Ticket, Preis pro Head, Preis pro Tower. Dieses Modell erzeugt ein strukturelles Incentive Misalignment.
Der Kunde will Volumenreduktion, Shift-Left, Automatisierung und echte Effizienz. Der Provider verdient an Volumen, Komplexität und fortbestehendem manuellen Betrieb. Das ist kein Vorwurf — es ist Systemlogik.
Ein Provider, der pro Ticket abrechnet, hat ökonomisch kein starkes Eigeninteresse daran, Ticketvolumen substanziell zu reduzieren. Shift-Left und Automatisierung werden vertraglich versprochen und rhetorisch unterstützt. Ökonomisch sind sie für den Provider ein Umsatzproblem.
»Ein Provider, der pro Ticket abrechnet, hat kein wirtschaftliches Interesse daran, Tickets zu reduzieren. Das ist kein Versagen — es ist Konstruktionslogik.«
Seniority-Gap: Die Pyramidenkalkulation
Provider verkaufen Seniorität. Was tatsächlich geliefert wird, ist ein pyramidenförmiges Delivery-Modell: wenige Senior-Profile an der Spitze, viele Junior-Ressourcen im operativen Betrieb.
Ein als „Senior“ klassifizierter Mitarbeiter im LCC-Kontext verfügt häufig über 3–5 Jahre Berufserfahrung. Die Anforderungen eines komplexen, heterogenen IT-Betriebs — mit gewachsener Systemlandschaft, implizitem Firmenwissen und dynamischen Sonderlogiken — entsprechen regelmäßig einer Erfahrungstiefe von 10–15 Jahren mit belastbarem Kontext- und Betriebswissen.
Dieser Seniority-Gap ist kein Qualitätsversagen des Providers. Er ist ein Kalkülversagen des Business Case, der nominelle Profile mit realer Leistungstiefe gleichsetzt. Die operative Konsequenz: Re-Work, Eskalationen, Fehlentscheidungen und konstante Nachsteuerung — Kostenblöcke, die den nominellen LCC-Vorteil schrittweise aufzehren.
»Der Business Case kauft einen Senior-Profil-Preis. Im operativen Betrieb zahlt er für Re-Work, Eskalation und Nachsteuerung, die nirgendwo verrechnet werden.«
Compliance-Mindset: Wenn Prozessdisziplin Servicewirksamkeit ersetzt
Ein systematisch unterschätztes Merkmal vieler LCC-Delivery-Modelle ist das Compliance-Mindset: die strukturelle Tendenz, Prozessvorgaben zu erfüllen — statt Probleme zu lösen. Es zeigt sich in drei Mustern:
- Yes-Sir-Pattern: Machbarkeit wird bestätigt, bevor sie geprüft wurde. Ehrlicher Widerspruch bleibt aus.
- Checklisten-Treue: Das Ticket wird formal geschlossen. Die Ursache bleibt offen.
Der Business Case misst SLA-Erfüllung. Er misst keine Servicewirksamkeit. SLA-Konformität und operative Betriebsstabilität sind nicht dasselbe — ein Provider kann formal liefern und dennoch keinen belastbaren Business Value erzeugen.
»Ein grünes SLA kann ein rotes Betriebsmodell verdecken. Lange.«
Retained Organization: Die vergessene Seite des Business Case
LCC-Modelle funktionieren nur mit einer starken Retained Org. Wer Delivery auslagert, muss intern Steuerungsfähigkeit aufbauen oder erhalten: Service Ownership, Architekturhoheit, Governance, Eskalationsfähigkeit, Demand Management, Vendor Steering, Qualitätskontrolle.
Ein Business Case, der diese Intelligent Customer Capability nicht explizit finanziert, ist strukturell unvollständig. Als Orientierungsgröße gilt: Der Re-Invest in Retained Capability muss typischerweise in der Größenordnung von 20 – 30 % der erwarteten Savings liegen. Wer das nicht einrechnet, kauft keine Einsparung — er kauft Scheinsavings und verschiebt Steuerungskosten in Kostenstellen, die nie als IT-Kosten auftauchen.
»Savings ohne Retained Capability sind meist Scheinsavings. Die Steuerungskosten verschwinden nicht — sie verlagern sich.«
»Viele LCC-Outsourcing-Programme reduzieren Komplexität nicht. Sie verlagern sie — in Governance, Re-Work und informelle Strukturen, die in keinem KPI auftauchen.«
Vier Kostenblöcke, die der Business Case systematisch unterschätzt
Der Business Case eines LCC-Programms ist präzise dort, wo Präzision leicht fällt — beim Inputpreis des Providers. Er ist erschreckend unscharf dort, wo die eigentlichen Risiken liegen.
Fehler in der Ausgangsanalyse
Fehler im Delivery-Modell
Verdeckte Betriebs- und Governance-Kosten
Transition, Transformation und physische Realität
Viele Business Cases rechnen den Provider-Inputpreis auf den Cent genau. Re-Work, Governance Overhead, Transitionsdynamik und Retained Capability rechnen sie auf die Million unscharf.
»Der Provider kostet nicht nur Tagessätze. Er erzeugt ein Governance-, Lizenz- und Kontrollökosystem — das vollständig mitfinanziert, gesteuert und verantwortet werden muss.«
Der systemische Denkfehler: Inputpreis statt Modellpreis
Der Business Case eines LCC-Programms ist in sich arithmetisch konsistent. Das Problem sind nicht die Zahlen — das Problem sind die vier Prämissen, auf denen er aufgebaut ist.
Das Modell nimmt an: richtige Incentives, ausreichende Seniority, operative Servicewirksamkeit durch formale Compliance, Delivery-Savings als Netto-Savings. Alle vier Annahmen tragen strukturell nicht.
Der Business Case unterstellt
- Alignierte Provider-Incentives: Shift-Left, Automatisierung, Volumenreduktion
- Senior-Profile im operativen Delivery
- SLA-Erfüllung = operative Servicewirksamkeit
- Delivery-Savings als Netto-Savings
- Standardisierbarer, homogener Betrieb
- Dokumentiertes, transferierbares Wissen
- Transition vollständig eingepreist — Transformation im Run-Preis enthalten
- Datenschutz- und Zugriffsstandards automatisch auf Kundenniveau
- Saubere, vollständige Datenbasis
- Klar definierte, stabile Prozesse
- Eindeutige Leistungsgrenzen und Scope-Definitionen
- Stabiler, gleichförmiger Ticketstrom ohne wesentliche Peaks oder Ausnahmen
- Provider-Synergien aus Mehrkundenbetrieb direkt wirksam auf Kundenebene
- Stabile Organisation ohne wesentliche Veränderungsdynamik
- Nutzer können das Supportmodell sprachlich und kulturell ohne Mehraufwand nutzen
- Planbare, lineare Skalierung
- Retained Org läuft parallel weiter
Die strukturelle Realität
- Incentive Misalignment: Provider-Umsatz und Kundenziel zeigen in entgegengesetzte Richtungen
- Pyramidenstruktur mit Seniority-Gap in der Delivery-Basis
- SLA-Konformität ≠ Servicewirksamkeit
- Scheinsavings, wenn Retained Capability und Governance Overhead nicht gegengerechnet werden
- Heterogener Betrieb mit hoher Ausnahme- und Sonderfallquote
- Implizites Wissen, das sich nicht linear übertragen lässt
- Transition siebenstellig auf Kundenseite — Transformation danach, oft zusätzlich bepreist
- Zugriffsdisziplin und Audit-Fähigkeit erfordern aktiven Governance-Aufwand
- Historisch gewachsenen Ausnahmen und Sonderlogiken
- Lokaler Improvisation und informellen Lösungen
- Informellen Zusatzleistungen ohne vertragliche Existenz
- Physischen Serviceanforderungen und lokaler Nähe
- Dynamischem Ticketalltag: Rollouts, Peaks, Altlasten und Sonderfälle machen Standard zur Ausnahme
- Kundenspezifischem Delivery-Team trotz Synergieversprechen — reale Wiederverwendung operativ deutlich kleiner
- Politischen Schnittstellen und informellen Eskalationswegen
- Hoher Veränderungsdynamik: M&A, Reorganisationen, Standortänderungen
- Verdeckter Mehrarbeit, die nie in einem Ticket landet
- Altersstruktur, Sprachfähigkeit und Supportakzeptanz der Nutzerbasis – nie systematisch analysiert
- Sich verschiebenden Prioritäten und Anforderungen
- Retained Org muss aktiv aufgebaut werden — nicht aufrechterhalten
Das Problem ist nicht, dass Outsourcing nicht funktioniert. Es ist, dass viele Business Cases ein Modell finanzieren, das auf falschen Annahmen über Incentives, Seniority, Mindset und Retained Capability aufgebaut ist — und dass diese Fehler erst sichtbar werden, wenn das Programm läuft und der Schaden bereits entsteht.
»Ein unreifes Betriebsmodell wird durch Outsourcing nicht reifer — sondern nur schwerer steuerbar.«
Wie Outsourcing funktionieren kann
Die Kritik an falschen Prämissen bedeutet keine Absage an Outsourcing. Sie bedeutet eine Absage an schlecht vorbereitetes, zu breit angelegtes und zu schnell durchgezogenes Outsourcing. Was gelingt, folgt anderen Regeln.
Incentives richtig konstruieren. Unit-based Pricing ist für den Kunden das falsche Modell. Outcome-based oder Risk-Reward-Strukturen schaffen echtes Alignment. Wer pro Ticket zahlt, bekommt Ticket-Optimierung — keine Betriebsstabilisierung.
Retained Organization als Pflicht einpreisen. Kein LCC-Modell funktioniert ohne belastbare Retained Org. Service Ownership, Architekturhoheit, Governance und Eskalationsfähigkeit müssen intern bleiben oder aktiv aufgebaut werden. Das gilt auch für Datenschutz und Access Governance: Need-to-Know, minimale Rechtevergabe, SoD-Disziplin und Audit-Fähigkeit sind keine selbstverständlichen Provider-Leistungen — sie müssen als aktive Steuerungsaufgabe der Retained Org definiert und finanziert werden. Orientierungsgröße: ca. 10–15 % der erwarteten Savings als Re-Invest in Intelligent Customer Capability — sonst sind es Scheinsavings.
Seniority-Anforderungen vertraglich belastbar definieren. Nominelle Senior-Profile sind kein Lieferversprechen. Erfahrungstiefe, Nachweisbarkeit und Konsequenzen bei Nichterfüllung müssen vertraglich spezifiziert sein — nicht als Wunschliste, sondern als steuerbare Anforderung mit echtem Vertragsgewicht.
Standardisieren vor Outsourcen. Asset-Struktur, Rollenmodell, Prozessklarheit und Ticketsemantik gehören verbessert, bevor der Provider die Tür betritt. Wer ein unvollständig verstandenes Betriebsmodell auslagert, übergibt dem Provider Komplexität, Lücken und implizite Abhängigkeiten. Chaos lässt sich nicht outsourcen — es wird teurer.
Scope-Ehrlichkeit und inkrementelles Vorgehen. Kein Big Bang. Nicht Helpdesk, Client, Fieldservice, Infrastruktur und Backoffice gleichzeitig vollständig auslagern. Kleine, pilotierbare Wellen mit echten Lernschleifen. Scope, der auf Wunschbild statt Betriebsrealität basiert, erzeugt strukturell vorhersehbare Nachverhandlungen — meist zu Ungunsten des Kunden.
Ausschreibungsreife braucht Substanz, Zeit und interne Führung. Bevor ein Outsourcing belastbar verhandelt werden kann, müssen Leistungen, Servicegrenzen, Mengenbilder, Abhängigkeiten, lokale Sonderfälle, Rollen, SLAs und Governance-Strukturen in einem belastbaren Lastenheft beschrieben werden. Dieser Vorbereitungsaufwand bindet Einkauf, IT, Architektur, Operations und Fachbereiche oft über Monate. Wer diesen Aufwand unterschätzt, kalkuliert nicht den realen Eintrittspreis des Modells — und verhandelt am Ende keinen stabilen Scope, sondern Interpretationsspielräume.
Exit-Fähigkeit von Tag 1 konstruieren. Re-Sourcing, AI-Automatisierung, M&A und Reorganisationsdynamik müssen vertraglich eingepreist sein — nicht erst, wenn das Modell kriselt. Wer Exit-Fähigkeit nicht von Anfang an plant, zahlt dafür doppelt.
Transition und Transformation separat einpreisen. Beide Phasen haben unterschiedliche Kostenlogiken und dürfen im Business Case nicht verschmelzen. Die Transition (typisch 6–12 Monate) ist der operative Übergabeprozess: Knowledge Transfer, Shadowing, Parallelbetrieb, Hypercare und Governance-Aufbau. Sie erzeugt auf Kundenseite schnell siebenstellige Cash-out-Kosten — und bindet genau die internen Leistungsträger, die parallel für Automatisierung, Security und Architektur gebraucht würden. Dazu kommt: LCC-Delivery ist physisch träge. Wer in dieser Phase kurzfristig On-Site-Unterstützung benötigt, plant besser mit einem Vorlauf von drei bis sechs Monaten. Die Transformation folgt danach: Standardisierung, Tooling-Umbau, Prozesshärtung, Operating-Model-Redesign. Provider bepreisen diese Phase häufig zusätzlich. Der nominelle Run-Preis enthält sie in der Regel nicht. Wer den Business Case auf den Zielbetrieb rechnet, aber nicht auf den Weg dorthin, rechnet strukturell zu günstig — und kauft sich eine Nachverhandlung ein.
Echte Betriebswirksamkeit messen — nicht nur SLA-Ampeln. Nutzerzufriedenheit, Eskalationsraten, First-Contact-Resolution und Business-Impact sind die Messgrößen, die zählen. Einsparungen müssen end-to-end gerechnet werden: inklusive Schatten-IT, Schnittstellenkosten, versteckter Mehrarbeit, Lizenzanpassungen und Governance-Aufwand. Nur was unternehmensweit günstiger wird, ist echte Einsparung.
IT muss fachlich führen. Finance und Procurement dürfen nicht allein treiben. Operatives Wissen über Servicegrenzen, Sonderlogik und technische Abhängigkeiten muss in die Vertragsgestaltung einfließen. Wer die Inhalte dem Einkauf überlässt, bekommt einen Vertrag, der auf dem Papier gut aussieht und im Betrieb nicht hält.
Vendor-Management-Mandat sauber übertragen oder intern behalten. Steuerungsrechte gegenüber Drittanbietern müssen vertraglich und tatsächlich übertragen sein — nicht nur dem Prime-Provider in Aussicht gestellt. Bestehende Drittanbieter akzeptieren externe Steuerer nicht automatisch. Ohne echtes Mandat entsteht kein Vendor Management, sondern nur eine neue Eskalationslücke.
Knowledge Transfer aktiv steuern — nicht als Bringschuld delegieren. Was der Kunde nicht explizit übergibt, gilt dem Provider später als nicht bekannt. Implizites Wissen, Zusammenhangswissen und gewachsene Firmenlogik lassen sich nicht in einem linearen Übergabeprozess abbilden. Das muss aktiv gemanagt, nicht nur dokumentiert werden. Eigenanalyse und Mitverantwortung des Providers müssen vertraglich eingefordert werden.
Mitarbeiter der abgebenden Organisation aktiv führen. Doppelbelastung aus Normalbetrieb und Transition ist real. Wer diese Menschen nicht explizit schützt, führt und mit Perspektive ausstattet, verliert genau die Erfahrungsträger, die für eine stabile Übergabe unverzichtbar sind. Die personelle Stabilität der abgebenden Seite ist eine kritische Erfolgsvariable — kein HR-Thema am Rande.
Einsparungen end-to-end rechnen. Inklusive Schatten-IT, Schnittstellenkosten, versteckter Mehrarbeit, Lizenz- und Rollenanpassungen, Governance-Aufwand und Know-how-Verlust. Nur was unternehmensweit günstiger wird, ist echte Einsparung.
Provider als verlängerte Werkbank – bewusst. Steuerungsfähigkeit und fachliche Ownership müssen intern erhalten bleiben. Wer die Steuerungskompetenz outsourct, verliert die Handlungsfähigkeit.
Vertrauen und Arbeitsbeziehungen aktiv aufbauen. Outsourcing ist kein Distanzierungsmodell. Reisen in beide Richtungen, gemeinsame Reviews, echte Kommunikation auf operativer Ebene – das sind keine Nice-to-haves.
Nutzerbasis vor dem Outsourcing konkret analysieren. Altersstruktur, Sprachfähigkeit und Kommunikationsrealität der Belegschaft bestimmen, welche Supportmodelle tragfähig sind. Englischsprachige Offshore-Modelle funktionieren nicht in jeder Umgebung gleich. Wer diese Analyse überspringt, riskiert strukturell sinkende Supportakzeptanz und verlängerte Klärungszeiten – ohne dass es in einem SLA sichtbar wird.
»Outsourcing funktioniert nicht durch Größe und Härte — sondern durch richtiges Incentive-Design, explizit finanzierte Retained Capability und operative Ehrlichkeit über die eigene Ausgangsposition.«
»Wer ein LCC-Modell einkauft, kauft nicht günstige Delivery. Er kauft ein Steuerungsproblem — es sei denn, das Modell ist von Anfang an bewusst und vollständig konstruiert.«
LCC-Outsourcing ist kein Fehler — wenn das Modell richtig konstruiert ist.
Die meisten Probleme entstehen nicht, weil Provider schlecht liefern. Sie entstehen, weil Business Cases falsche Annahmen über Incentives, Seniority, Compliance-Mindset und Retained Capability machen — und weil diese Fehler erst sichtbar werden, wenn das Programm läuft und der Schaden bereits entsteht. Wer ein LCC-Modell einkauft, kauft nicht einfach günstige Delivery. Er kauft ein Steuerungsproblem — es sei denn, er hat das Modell bewusst, vollständig und mit dem richtigen konstruktiven Gegengewicht gebaut.
Pierre Kromat 