Eine NewCo-IT entsteht nicht aus einem Greenfield — sie entsteht aus einer abgetrennten Einheit mit geerbten Systemen, laufenden TSA-Abhängigkeiten und einem Betriebsmodell, das erst definiert werden muss. Die Führungsperspektive ist operativ: Entscheidungsfähigkeit von Tag 1, Steuerungsfähigkeit unter Unsicherheit, Standalone-Fähigkeit als Ziel.
IT-Aufbau unter Betrieb
Die NewCo-IT muss laufen, während sie aufgebaut wird. Kein Stillstand, kein Übergabepunkt ohne Verantwortung.
Vom Konzernkind zum Standalone
Jeder Systembereich, jeder Prozess, jede Lizenz muss eigenständig werden. Nichts ist automatisch übertragbar.
Operative Tiefe
IAM-Aufbau, Provider-Selektion, ERP-Stabilisierung, Security-Baseline: Parallelarbeit ohne Puffer.
Wertlogik kennen
IT-Kosten und -Strukturen beeinflussen direkt EBITDA, Multiple und Equity Story der NewCo.
Execution, nicht Planung
Kein Folien-Modus. Lieferverantwortung für TOM, Provider-Verträge, Betriebsprozesse und TSA-Exit.
Schnittstelle Deal / Betrieb
Verständnis der Bruchstellen zwischen Transaktionslogik, IT-Aufbau und laufendem Betrieb.
Ohne verbindliches Target Operating Model (TOM) entsteht keine Zielarchitektur — nur ad-hoc-Entscheidungen unter Zeitdruck. Das TOM muss vor dem Lösungsdesign stehen, nicht danach.
Make-or-Buy-Entscheidungen
Welche IT-Services werden intern erbracht, welche extern bezogen? Diese Entscheidung bestimmt die Kostenstruktur auf Jahre.
Zielarchitektur
Cloud-Strategie, ERP-Zielzustand, Applikationslandschaft: muss grob stehen, bevor Migrationen beginnen.
Betriebsorganisation
Internes IT-Team, MSP, Hybrid: Organisationsform und Führungsmodell definieren, bevor Provider-Verträge geschlossen werden.
Service-Katalog
Welche Services liefert die IT an wen, zu welchem SLA? Basis für alle Provider-Verträge und Kostenverrechnung.
Scope-Disziplin
Jede Erweiterung über Day-1-Scope hinaus muss aktiv entschieden werden — nicht durch Unterlassen entstehen.
Evolutionspfad
Minimum Viable Stack zu Day 1 — Zielzustand in 12–24 Monaten. Phasierung ist kein Kompromiss, sondern Methode.
Governance im Zielbild
IT-Governance-Struktur, Reporting-Linien, Decision Rights: müssen Teil des TOM sein, nicht Nachlieferung.
Alignment mit CFO/Investor
Das TOM muss zur Equity Story passen. IT-Kosten, die das EBITDA-Ziel gefährden, sind kein TOM-Baustein.
»Wer das TOM erst nach den ersten Provider-Entscheidungen definiert, steuert rückwärts — gegen bereits gesetzte Fakten.«
In der NewCo ist IT kein Overhead — sie ist direkte Voraussetzung für operative Handlungsfähigkeit, Investor-Vertrauen und EBITDA-Stabilität. Wer IT als reinen Kostenfaktor managt, verliert den Hebel.
Reaktiv gesteuert
TSA verlängert · Standalone-Fähigkeit verzögert · Cost Model unklar
Ergebnis: Investoren sehen unkontrollierten IT-Overhead → EBITDA-Druck
Proaktiv gesteuert
TOM klar · TSA-Exit planbar · Cost Model bottom-up belastbar
Ergebnis: Standalone-Fähigkeit als Equity-Story-Baustein
Operative Lücken nach Day 1 · TSA-Drift · Wissensabfluss · Investoren-Eskalation
Betriebsstabilität ab Day 1 · TSA-Exit planmäßig · Cost Model hält den Investor-Test
Operative Handlungsfähigkeit
Ohne stabile IT kein stabiler Betrieb. Day-1-Readiness ist nicht optional — sie ist Closing-Bedingung.
Investor-Vertrauen
Ein robustes IT-Cost-Model und ein klarer TSA-Exit-Plan sind sichtbare Signale für Investoren und Board.
EBITDA-Stabilität
Ungeplante IT-Kosten durch TSA-Verlängerungen, Security-Incidents oder Betriebsausfälle treffen direkt die GuV.
Standalone als Exit-Ticket
Vollständige Standalone-Fähigkeit ist Voraussetzung für jeden weiteren Deal — Refinanzierung, Add-on, Exit.
Das Standalone Cost Model ist die Basis für jede finanzielle Planung der NewCo-IT. Wer es aus Konzernperspektive fortschreibt, unterschätzt die tatsächlichen Kosten systematisch — und verdeckt operative Risiken vor dem Investor.
Bottom-up-Kalkulation
Jeder IT-Service muss einzeln kalkuliert werden: Infrastruktur, Applikationen, Security, Support, Lizenzen. Konzernumlagen sind keine Grundlage für ein belastbares Standalone-Modell.
Regel Jede Kostenlinie braucht einen Vertrag oder ein Angebot — keine Schätzung ohne Grundlage.
TSA-Kosten sichtbar machen
TSA-Kosten sind keine Übergangskosten — sie sind laufende Betriebskosten mit definiertem Enddatum. Wer sie nicht im Cost Model führt, hat ein falsches Kostenbild.
Regel Monatliches TSA-Burn-down-Tracking ist Pflicht, nicht Kür.
Make-or-Buy-Entscheidungen
Eigenleistung, MSP oder Cloud-Dienst: jede Entscheidung hat eine Kostenstruktur mit unterschiedlicher Skalierbarkeit und einem anderen Risikoprofil. Entscheidungsgrundlage: TCO über 3 Jahre, nicht nur laufende Kosten.
Prinzip Günstig today kann teuer in 18 Monaten sein.
»Ein IT-Budget, das aus dem Konzernmodell abgeleitet ist, unterschätzt die Standalone-Kosten regelmäßig um 20–40 %. Das ist kein Fehler — das ist systembedingt.«
Der Aufbau einer eigenen Identitätsinfrastruktur ist der kritischste und am häufigsten unterschätzte Workstream beim NewCo-IT-Aufbau. Ohne eigene IAM-Basis gibt es keine Standalone-Fähigkeit — nur TSA-Abhängigkeit.
Eigene AD-Domäne
Eigene DNS-Architektur, eigene Domäne, eigenes PKI: Voraussetzung für jeden weiteren IT-Aufbauschritt. Muss vor Day 1 funktionieren.
Hybrides Identitätsmodell
Während der TSA-Phase: eigene Domäne plus föderierter Zugriff auf Legacy-Systeme. Technisch sauber, vertraglich abgesichert, operativ steuerbar.
Compliance ab Day 1
NIS2 und DSGVO erfordern nachweisbare Zugriffssteuerung ab dem ersten Betriebstag. IAM ist kein Folge-Workstream.
Privileged Access
Administratorzugänge, Service-Accounts und Break-Glass-Konzepte der NewCo müssen von Konzernstrukturen vollständig getrennt sein.
SSO & Federation
Föderierter SSO zu TSA-Services und Cloud-Diensten: technisch notwendig für reibungslosen Betrieb, vertraglich exakt zu begrenzen.
Exit aus der Konzern-Identität
Vollständiger IAM-Exit aus dem Konzernverbund ist Bedingung für Standalone-Fähigkeit — nicht optional, nur zeitlich versetzt.
»Wer IAM als technisches Infrastrukturthema behandelt, hat Day 1 noch nicht verstanden.«
Für die NewCo ist der TSA kein Sicherheitsnetz — er ist eine strukturelle Abhängigkeit mit Kostenfolge. Aktives TSA-Management beginnt am ersten Tag nach Signing, nicht am Closing.
TSA-Verständnis ab Signing
Jede TSA-Leistung, jede SLA, jeder Exit-Mechanismus muss verstanden und im eigenen Cost Model abgebildet sein — nicht erst nach Closing.
Exit-Planung parallel zum Betrieb
Für jede TSA-Leistung muss der Exit-Pfad definiert sein, bevor die TSA startet. Wer erst nach Verlängerung plant, zahlt.
Monatliches Burn-down
TSA-Kosten sind keine Fixbeträge. Monatliche Transparenz über offene TSA-Kosten und geplante Exit-Termine ist Pflicht.
Sunset-Provisions nutzen
Vertragliche Eskalationsmechanismen sind das einzige Instrument, das den Verkäufer zum TSA-Exit-Engagement zwingt.
»Jeder Monat TSA-Verlängerung kostet — und verhindert die Standalone-Fähigkeit, die der Investor erwartet.«
Silent Dependencies sind undokumentierte technische oder organisatorische Abhängigkeiten, die erst nach Day 1 sichtbar werden. Sie sind die häufigste Ursache operativer Ausfälle in der NewCo — und hätten vor Closing identifiziert werden können.
Konzernservices ohne Vertrag
Globale Security-Dienste, zentrale Monitoring-Plattformen, DNS-Dienste: in keiner TSA, aber operativ genutzt. Werden nach Day 1 abgeschaltet — ohne Vorwarnung.
Abwehr Netzwerkflussanalyse über mindestens 30 Tage vor Closing. Discovery-Tools einsetzen, nicht nur Interviews führen.
Hard-coded Referenzen
Servernamen, IP-Adressen, Endpunkte in Batch-Jobs oder Applikationskonfigurationen, die nach Day 1 nicht mehr erreichbar sind. Erfordern oft manuelle Nacharbeit unter Produktionsdruck.
Abwehr Code-Scanning, Konfigurations-Audits, systematische Discovery auf Applikationsebene vor CutOver.
Wissens-Dependencies
Betriebswissen, das nur in den Köpfen von Konzern-IT-Mitarbeitern existiert — nicht dokumentiert, nicht übergeben. Geht mit dem letzten Handover-Tag unwiederbringlich verloren.
Abwehr Strukturierter Wissenstransfer mit Shadowing- und Reverse-Shadowing-Phasen. Nicht verhandelbar.
»Was nicht dokumentiert ist, existiert für die NewCo nicht — bis es ausfällt.«
IT-Governance in der NewCo entsteht nicht automatisch — sie muss aufgebaut werden: Entscheidungsstrukturen, Eskalationspfade, Meeting-Rhythmen, Provider-Steuerung. Wer damit nach Day 1 beginnt, hat bereits Steuerungsverlust riskiert.
Governance-Design
Decision Rights · Eskalationslogik · Meeting-Rhythmen · SMO-Struktur
Governance-Etablierung
Erste Steuerungs-Meetings · Eskalationswege testen · Provider-Onboarding
Provider-Steuerung
SMO operativ · SLA-Monitoring · Eskalationshistorie · Change-Advisory-Board
Reifegradsteigerung
ITIL-Prozesse etabliert · KPI-Reporting · Kostensteuerung operativ
Standalone-Betrieb
Vollständige Steuerungsfähigkeit · TSA-Exit abgeschlossen · Konzernunabhängig
»IT-Governance in der NewCo ist kein Verwaltungsrahmen — sie ist operatives Steuerungsinstrument unter Aufbaudruck.«
Kein Konzept ohne prüfbares Ergebnis. Die Lieferobjekte sind konkret, namentlich zugeordnet und vertraglich belastbar.
TOM mit Make-or-Buy-Entscheidungen · Service-Katalog · Betriebsorganisation
Checkliste mit Ja/Nein-Kriterien · Minimum Viable Stack · Cutover-Playbook
Bottom-up-Kalkulation · TSA-Kosten sichtbar · Make-or-Buy-TCO
AD-Konzept · Hybrides Identitätsmodell · Compliance-Nachweis
Exit-Pfade je Modul · Burn-down-Tracking · Sunset-Eskalationslogik
ITIL-Prozesse · CMDB · Provider-Steuerungsmodell · RACI
»Was nicht prüfbar und nicht übergabefähig ist, ist kein Deliverable.«
Im NewCo-IT-Aufbau prallen drei Perspektiven aufeinander, die selten dieselbe Sprache sprechen. Wer nur eine steuert, verliert die anderen beiden.
CIO / IT-Lead
Trägt operative Verantwortung ab Day 1 — ohne fertiges Team, ohne vollständige Systeme, mit TSA-Abhängigkeiten, die er nicht selbst verhandelt hat. Braucht operativen Partner, der parallel aufbaut und steuert.
CFO
Sieht IT als Kostenlinie, die das EBITDA-Ziel gefährdet, wenn sie nicht kontrolliert wird. Braucht ein belastbares Cost Model und monatliche Transparenz über TSA-Kosten und Exit-Status.
Investor / Board
Bewertet Standalone-Fähigkeit als Kernbaustein der Equity Story. Ungeplante TSA-Verlängerungen und operative IT-Schwächen zerstören Vertrauen in die Führung.
Synchronisiert — nicht isoliert. Erfolgreiche NewCo-IT-Führungen synchronisieren diese drei Perspektiven durch gemeinsame Sprache: operative Statusberichte für CIO, Cost-Model-Updates für CFO, Standalone-Roadmap für den Investor.
Die größten Risiken beim NewCo-IT-Aufbau sind strukturell vorhersehbar — und werden trotzdem regelmäßig zu spät adressiert.
TOM zu spät definiert
Ohne verbindliches Target Operating Model werden Provider-Entscheidungen, Make-or-Buy-Weichenstellungen und Kostenpläne gegen ein bewegliches Zielbild getroffen. Das erzeugt strukturelle Fehlpassungen, die nach Closing teuer korrigiert werden müssen.
TSA-Drift
Ohne aktives Exit-Management verlängern sich TSAs automatisch — monatlich teurer, ohne dass Standalone-Fortschritt erzeugt wird. Der Verkäufer hat keinen Anreiz zum Exit, solange kein Druck besteht.
Wissensabfluss
IT-Schlüsselpersonen aus dem Konzern verlassen die Handover-Phase — mit ihnen gehen kritisches Betriebswissen und Konfigurationswissen, das nirgendwo dokumentiert ist. Nicht reparierbar nach dem Tatsächlichen.
Security-Lücken in der Transition
Die Übergangsphase vergrößert die Angriffsfläche — hybride Identitätsmodelle, geteilte Systeme, temporäre Zugänge. NIS2- und DSGVO-Anforderungen gelten unverändert ab Day 1.
Überschätzte interne Kapazität
NewCo-IT-Teams sind typischerweise kleiner als geplant, mit zu vielen parallelen Prioritäten. IT-Aufbau neben Tagesbetrieb neben TSA-Management neben Provider-Onboarding: strukturell zu viel ohne dedizierte Kapazität.
»NewCo-IT-Risiken eskalieren nicht linear — sie kumulieren, weil jede ungelöste Abhängigkeit neue Blockaden erzeugt.«
16 Faktoren aus der Praxis — nicht aus Frameworks. Jeder adressiert eine Schwäche, die in realen NewCo-IT-Situationen zu messbaren Problemen geführt hat.
TOM vor Provider-Entscheidungen. Wer zuerst Provider auswählt und dann das TOM anpasst, baut die IT-Organisation rückwärts.
Standalone Cost Model ab Signing. Bottom-up-Kalkulation muss vor dem ersten Investor-Review fertig sein — nicht danach.
IAM-Aufbau als kritischen Pfad behandeln. Active Directory und IAM-Architektur sind Voraussetzung für jeden weiteren IT-Aufbauschritt — kein Folge-Workstream.
TSA-Exit-Planung parallel zum Betrieb. Wer TSA-Exits nicht ab Signing plant, produziert Verlängerungen mit ungeplanten Kosten und verzögerter Standalone-Fähigkeit.
Wissenstransfer strukturiert und termingebunden. Vier bis sechs Wochen dedizierter Handover mit Dokumentation, Shadowing und Reverse-Shadowing — nicht verhandelbar.
Silent-Dependency-Scan vor Day 1. Netzwerkflussanalyse, Discovery-Tools, Code-Scanning: technische Tiefe, nicht nur Interview-basiertes Scoping.
Governance-Architektur von Tag 1. Ohne klare Decision Rights und Eskalationspfade werden Entscheidungen verschleppt — und verschleppte Entscheidungen blockieren den Aufbau.
Minimum Viable Stack definieren und verteidigen. Day-1-Scope ist nicht der günstigste Zustand — er ist der kleinste tragfähige Betriebszustand. Jede Ergänzung muss begründet werden.
Security als Tag-1-Workstream. Security-Baseline, NIS2-Anforderungen und DSGVO gelten ab Day 1 — nicht nach der Transition.
Betriebsprozesse vor Go-Live implementiert. ITIL-Prozesse, CMDB, Incident- und Change-Management: müssen vor Day 1 funktionieren — nicht nur dokumentiert sein.
Dedizierte Kapazität für den IT-Aufbau reservieren. IT-Aufbau neben Tagesgeschäft erzeugt strukturell vorhersehbare Qualitäts- und Terminprobleme.
Hypercare als eigenständige Phase mit Budget. Zwei bis drei Monate erhöhte Supportbereitschaft nach Day 1 sind Pflicht — nicht Kür.
Betriebspartner früh festlegen. Der spätere IT-Betriebspartner (MSP oder intern) muss spätestens in der Konzeptionsphase feststehen und Stabilisierungsverantwortung übernehmen.
Endanwender früh vorbereiten. Schulungen, Kommunikation, Change Management beginnen vor Day 1 — nicht am Go-Live-Montag.
Kostensteuerung monatlich sichtbar machen. TSA-Burn-down, Standalone-Cost-Entwicklung, Provider-Kosten: monatliches Reporting an CFO und Board ist Standard, nicht Aufwand.
Risiken früh transparent machen. Risiken die vor Day 1 sichtbar sind, sind steuerbar. Risiken die erst nach Day 1 eskalieren, erzeugen Krisen unter maximalem Betriebsdruck.
»Keiner dieser Faktoren ist überraschend. Die Schwierigkeit liegt in der konsequenten Umsetzung — unter Zeitdruck, begrenzten Ressourcen und gleichzeitigem Betrieb.«
Der NewCo-IT-Aufbau erzeugt eine eigene Fachsprache an der Schnittstelle von Transaktion, IT-Betrieb, Finance und Programm-Management. Dieses Glossar definiert die zentralen Begriffe — als operative Referenz, nicht als Lexikoneinträge.
AD-Aufbau / Identity-Fundament
Aufbau einer eigenen Active-Directory-Infrastruktur als Basis der NewCo-IT-Identität. Kritischer Pfad: ohne AD-Fundament kein Day-1-Zugriff, kein Security-Fundament, kein TSA-Exit.
Application Rationalization
Systematische Bewertung und Bereinigung des geerbten Applikationsportfolios. Ziel: Komplexitätsreduktion, Kosteneinsparung und Vorbereitung auf den Standalone-Betrieb.
Bottom-up-Kalkulation
Kostenkalkulation auf Basis einzelner IT-Services, Verträge und Ressourcen. Gegensatz zur Konzernumlage-Fortschreibung. Im NewCo-Kontext Pflicht — nur bottom-up ist belastbar.
Brückenlösung
Temporäre technische Lösung für den Betrieb während der Transition. Jede Brückenlösung erzeugt technische Schulden und ein Sicherheitsrisiko — muss aktiv gemanagt und terminiert werden.
CMDB (Configuration Management Database)
Zentrale Datenbank aller IT-Assets und ihrer Beziehungen. Muss für die NewCo vollständig aufgebaut werden — Voraussetzung für Incident-Management, Change-Management und Kostenverrechnung.
CutOver-Readiness
Zustand vor dem Wechsel auf NewCo-eigene Systeme: alle Systeme getestet, Runbooks vorhanden, Rollback-Szenarien vorbereitet, Go/No-Go-Kriterien definiert.
Day-1 Readiness
Zustand, in dem die NewCo am ersten Tag nach Closing eigenständig operationsfähig ist: IT, Netzwerk, Identität, Billing, Payroll, Security, Support. Kein Perfektion-Anspruch — Überlebensfähigkeit.
Day-2 Readiness
Fähigkeit der NewCo, nach der initialen Betriebsaufnahme in einen stabilen, nachhaltigen IT-Betrieb überzugehen. Day 1 sichert den Betrieb — Day 2 sichert Qualität und Weiterentwicklung.
Decision Rights
Verbindliche Definition, wer im IT-Aufbau welche Entscheidungen treffen darf. Unklare Decision Rights erzeugen Entscheidungsstaus, die den Aufbau blockieren.
Equity Story (IT-Fokus)
Narrativ, wie die IT-Struktur den Unternehmenswert der NewCo stützt. Standalone-Fähigkeit, TSA-Exit-Disziplin und robustes Cost Model sind die Bausteine einer belastbaren IT-Equity-Story.
Escalation Matrix
Strukturierte Eskalationslogik mit klar definierten Ebenen, Entscheidungsträgern und Reaktionszeiten. Muss vor Day 1 stehen und getestet sein.
Governance-Modell
Steuerungsrahmen für den IT-Aufbau und Betrieb: Entscheidungsstrukturen, Eskalationspfade, Meeting-Rhythmen, Reporting-Linien. Schwache Governance erzeugt Aufbaustaus.
Hypercare
Intensivbetreuungsphase direkt nach Day 1. Erhöhte Supportbereitschaft, engmaschiges Monitoring, dedizierte Eskalationswege. Typisch: 4–8 Wochen — nicht verhandelbar.
ITIL/ITSM
Prozessrahmen für standardisierten IT-Betrieb. Muss vor Day 1 operativ implementiert sein — Incident, Change, Problem Management als Mindest-Prozesse der NewCo-IT.
Knowledge Transfer (KT)
Strukturierte Wissensübergabe vom Konzern an die NewCo-IT. Phasen: Dokumentation → Shadowing → Reverse-Shadowing → eigenständiger Betrieb. Zeitfenster: 4–6 Wochen dediziert.
Landing Zone
Vorkonfigurierte Cloud-Umgebung als Zielplattform für migrierte Workloads. Muss vor Migrationsbeginn vollständig konfiguriert, gehärtet und getestet sein.
Lizenzmanagement
Aufbau eines eigenständigen Softwarelizenz-Managements. Im NewCo-Kontext besonders kritisch: ELA-Novation, Change-of-Control-Klauseln, neue Hersteller-Beziehungen aufbauen.
Make-or-Buy
Entscheidungsrahmen für jeden IT-Service: intern erbringen, extern beziehen oder hybrid. Bestimmt Kostenstruktur, Skalierbarkeit und Risikoprofil der NewCo-IT.
Minimum Viable Stack
Kleinstmöglicher funktionaler IT-Zustand für Day-1-Geschäftsfähigkeit: Billing, Payroll, Identität, E-Mail, kritische Fachprozesse. Jede Ergänzung muss begründet werden.
MSP (Managed Service Provider)
Externer Partner, der definierte IT-Services als Betriebsleistung erbringt. Im NewCo-Kontext häufigste Organisationsform für schnellen Betriebsaufbau ohne sofortige interne Vollkapazität.
Operating Model
Zielbetriebsmodell der NewCo-IT: Welche Services werden intern erbracht, welche extern? Das Operating Model muss vor dem Lösungsdesign definiert sein.
Operational Readiness
Formalisierte Prüfung der Betriebsbereitschaft: CMDB befüllt, Runbooks vorhanden, Eskalationswege getestet, Personal geschult. Nicht bestanden? Kein Go-Live.
Provider-Steuerung / SMO
Service Management Office als Steuerungsinstanz zwischen NewCo-IT und externen Providern. Dreistufiges Meeting-Modell: operativ (wöchentlich), taktisch (monatlich), strategisch (halbjährlich).
Service Catalog
Strukturiertes Verzeichnis aller IT-Services der NewCo. Grundlage für SLA-Definition, Kostenverrechnung und Provider-Steuerung.
Silent Dependencies
Nicht dokumentierte technische oder organisatorische Abhängigkeiten, die erst nach Day 1 sichtbar werden. Häufigste Ursache operativer Ausfälle in der NewCo-IT.
Standalone-Fähigkeit
Fähigkeit der NewCo, alle IT-Services eigenständig zu betreiben oder zu beziehen — ohne jede Abhängigkeit vom ehemaligen Mutterkonzern. Kein Zustand des Closing — sondern Ziel des IT-Aufbaus.
Standalone Cost Model
Bottom-up-Kalkulation aller IT-Kosten der NewCo ohne Konzernumlagen. Basis für EBITDA-Planung, Investor-Reporting und Make-or-Buy-Entscheidungen.
Target Operating Model (TOM)
Zielbetriebsmodell für die IT nach Abschluss des Aufbaus. Muss vor dem Lösungsdesign stehen — bestimmt alle nachfolgenden Entscheidungen.
TSA (Transitional Service Agreement)
Vertragliche Regelung zur Übergangsbewirtschaftung von IT-Services durch den Verkäufer nach Closing. Für die NewCo: notwendige Übergangsbrücke mit definiertem Enddatum und aktivem Exit-Management.
TSA Burn-down
Monatliche Verfolgung der verbleibenden TSA-Kosten und Exit-Termine. Pflicht-Steuerungsinstrument im NewCo-IT-Betrieb.
TSA Exit
Geplante Beendigung einer Übergangsvereinbarung. Ohne aktives Exit-Management und Sunset-Provisions werden TSAs systematisch verlängert.
Workstream
Thematisch abgegrenzter Arbeitsbereich im IT-Aufbauprogramm. Typisch in der NewCo: IAM/Identity, Infrastruktur, ERP-Stabilisierung, Applikationen, Security, Workplace, Provider-Onboarding, TSA-Management.
Die meisten NewCo-IT-Aufbauten scheitern nicht an Technologie. Sie scheitern an fehlendem Target Operating Model, TSA-Drift, Silent Dependencies und der Annahme, eine IT-Organisation lasse sich aufbauen, während der Betrieb läuft — ohne dedizierte Führung.
Operative NewCo-IT-Führung beginnt dort, wo Projektpläne enden.