SAP-Transformation bei der Telekom: Weniger Systeme, mehr Standard

Die Deutsche Telekom setzt bei der Migration auf S/4HANA auf einen Clean-Core-Ansatz und Multi-Cloud. Joop Jansen, CFO Deutsche Telekom IT, und Hendrik Oevermann, T-Systems, geben einen Zwischenstand.

Die Deutsche Telekom hat sich mit der SAP-Konsolidierung und -Migration bis 2030 ein Mammutprojekt vorgenommen.

Konsolidierung und Cloud-Migration: Von 83 auf 40 Anwendungen

Anfang 2025 begann die Deutsche Telekom, ihre SAP-Systeme zu konsolidieren und in die Cloud zu migrieren. Ziel ist es, die Zahl zentraler Anwendungen von 83 auf 40 zu reduzieren. Im Zuge der Transformation folgt das Unternehmen dem Clean-Core-Ansatz der SAP und setzt verstärkt auf Standardlösungen.

Im Gespräch mit der Computerwoche berichten Johannes „Joop“ Jansen, CFO Deutsche Telekom IT, und Hendrik Oevermann, Global Head of SAP AO for DTAG & Cross Application Services bei T-Systems, über die Herausforderung, den Spagat zwischen Standardisierung und notwendiger Flexibilität zu meistern.

Historische Gründe für die hohe Systemzahl

Joop Jansen erläutert, dass historisch über viele Jahre verschiedene SAP-Systeme für unterschiedliche Zwecke aufgebaut wurden, unter anderem:

• eigene Systeme für Fleet Management
• separate HR-Systeme je Land
• Logistiksysteme für verschiedene Märkte

Das einzige System, das bereits seit Jahren zentral betrieben wird, ist das Finanzsystem One-Finance Instance (OFI). Bis 2030 soll dieses Prinzip ausgeweitet werden, sodass auch Logistik und HR stärker auf zentrale Plattformen konsolidiert werden.

Zeithorizont und Status der Migration

Die Ambition ist, die Migration bis 2030 abzuschließen. Insgesamt sind 83 Anwendungen relevant für die Transformation. Ende 2025 stand die Telekom bei 76 Anwendungen; seither wird schrittweise weiter bis auf 40 reduziert.

Jansen betont, dass dies auch der Zeitrahmen ist, den man sich gegeben hat. Die Konsolidierung und das Aktualisieren der Systeme seien eine signifikante Investition.

Zitat Johannes „Joop“ Jansen, CFO Deutsche Telekom IT: “Ziel ist, ein möglichst „Clean Core“, um Updates und Migrationen künftig einfacher zu machen.”

Multi-Cloud-Strategie und Sicherheitsanforderungen

Die Deutsche Telekom verfolgt für ihre Cloud-Bedürfnisse grundsätzlich einen Multi-Vendor-Ansatz. Joop Jansen nennt als einen der wichtigsten Unterschiede zwischen den Clouds die Anforderungen an die Sicherheit:

• Workloads mit sehr hohen Security-Anforderungen werden in der Private Cloud betrieben.
• Weniger kritische Lasten laufen in der Public Cloud.

In der Public Cloud arbeitet die Telekom mit mehreren Providern zusammen, in der Private Cloud ausschließlich mit der T Cloud. Laut Jansen funktioniert dieses Modell aktuell sehr gut.

Plattformwechsel binnen Wochen möglich

Hendrik Oevermann erklärt, dass ein Plattformwechsel grundsätzlich mit Downtime verbunden ist, was für das Business kritisch sein kann. Technisch sieht er die Organisation jedoch gut vorbereitet: Über einen Automatisierungs-Layer – intern „Cosmos“ beziehungsweise SAP Multi Hybrid Cloud genannt – werden SAP-Systeme identisch betrieben, etwa auf Google Cloud, Azure oder anderen Hyperscalern sowie der T Cloud Private.

Im Ernstfall könnten Workloads relativ schnell verschoben werden, ohne große Änderungen an den Systemen vornehmen zu müssen. Realistisch sei in einem echten Notfall ein Zeithorizont von Wochen, nicht von Tagen.

Clean Core, Standardisierung und Umgang mit Custom Code

Custom Code weicht Standardfunktionen

Oevermann beschreibt, dass die Telekom – wie viele große Unternehmen – sehr viel Custom Code und viele Z-Programme hat. Viele davon stammen aus Zeiten, in denen SAP keine Standardlösungen angeboten hat.

Inzwischen gebe es mehr Standardfunktionen in den Kernsystemen. Für Spezialfälle nutzt die Telekom die Business Technology Platform von SAP. Dadurch werde der Custom Code deutlich reduziert.

Der Wechsel von Custom Code auf Standard sei zugleich ein Change-Prozess für die Fachbereiche und brauche Zeit. Oevermann verweist darauf, dass sich die Vorteile gut aufzeigen lassen: In RISE könne man über das Subscription Modell dauerhaft an den SAP-Update-Zyklen teilnehmen und die neuesten Versionen nutzen, ohne immer wieder mehrjährige Projekte pro Applikation starten zu müssen.

HR als Sonderfall: Payroll und länderspezifische Besonderheiten

Jansen ordnet ein, dass im HR-Bereich, insbesondere bei Payroll, viele länderspezifische Besonderheiten existieren. Eine vollständige Standardlösung gebe es nicht. Daher arbeitet die Telekom mit länderspezifischen Instanzen und setzt auf möglichst viel Konfiguration statt Specific Code. Ziel bleibt ein möglichst „Clean Core“, um Updates und Migrationen künftig einfacher zu machen.

Größenordnung des Projekts: Systeme, VMs und Datenbanken

Oevermann beschreibt die Größenordnung aus technischer Sicht von T-Systems: Es geht um insgesamt 83 Anwendungen, jeweils mit mindestens drei, teilweise bis zu neun Systemlandschaften. Dazu gehören neben einer Sandbox mehrere Abnahme-, Test-, Migrations- und Release-Linien.

Auf knapp 1.500 virtuellen Maschinen laufen unterschiedliche SAP-Services, darunter:

• Datenbanken
• Application- und Java-Server
• Web-Dispatcher
• Cloud-Connectoren
• SAP-Router

Bei den Datenbanken gibt es aktuell noch eine Mischlandschaft, da noch nicht alles auf HANA migriert ist. Entsprechend werden sowohl klassische Datenbanken als auch HANA-Systeme betrieben. Allein beim Arbeitsspeicher spricht Oevermann von deutlich über 380 Terabyte RAM für Datenbanksysteme.

Oevermann betont, dass die Telekom in Bezug auf das Volumen der SAP-Services – insbesondere die Datenbankgrößen – klar zu den Top ein Prozent gehört. Es gebe zwar im Markt noch einige wenige größere Player, doch auch aus Sicht von SAP selbst zähle die Telekom weltweit zu den sehr wenigen Installationen in dieser Größenordnung.

Dauer, Vorgehen und Beispiele aus der Migration

Jansen erklärt, dass die Migration auf S/4HANA für das bereits zentralisierte System One Finance Instance marktüblich sei: Sie läuft seit drei Monaten und soll noch neun Monate dauern – insgesamt also etwa zwölf Monate.

Die besondere Herausforderung bestehe darin, dass viele unterschiedliche Systeme schrittweise konsolidiert werden müssen. Als Beispiel nennt Jansen die Integration von Finanzfunktionen der SAP-Lösung für das Flotten-Management in die One-Finance-Instanz: Wenn das System in neun Monaten auf S/4HANA migriert ist, werden dort zusätzliche flottenrelevante Funktionalitäten aufgebaut. Dafür werde dann noch einmal etwa ein Jahr benötigt, um alles zu programmieren.

Effizienzgewinne, Kosten und Betriebsmodell

Jansen sieht einen großen Vorteil der ERP-Transformation darin, dass anschließend keine großen Migrationsprojekte mehr nötig sind, sondern man im normalen Release-Zyklus bleibt. Das reduziere den CapEx der ERP-Systeme deutlich.

Durch weniger Systeme spart die Telekom zudem Lizenzen und Infrastruktur. Jansen ergänzt jedoch, dass ein Teil der Einsparungen durch höhere In-Memory-Kosten von S/4HANA wieder aufgezehrt wird. Insgesamt spricht er von einer OPEX-Reduktion im niedrigen einstelligen Prozentbereich.

KI-Funktionen: SAP Joule, eigene Tools und Betrieb

Auf die Frage nach KI-Funktionen in S/4HANA beziehungsweise angekündigten Funktionen sagt Jansen, dass im Konzern bereits viele unterschiedliche KI-Lösungen genutzt werden, insbesondere in der Softwareentwicklung und im Office-Umfeld. Für klassische SAP-User sehe man aktuell keinen großen Bedarf für Tools wie Joule; mit fortschreitender Transformation werde man das weiter beobachten.

Oevermann ergänzt, dass T-Systems durch den Wechsel auf moderne Plattformen und in das Betriebsmodell eigene KI-gestützte Tools für Betrieb und Serviceleistungen einbringen kann. Als Beispiel nennt er das Sherlock-Projekt, das Monitoring deutlich prädiktiver mache und zugleich den gesamten Change-Prozess mit dem Kunden vereinheitliche.

Davon profitiere am Ende auch die Telekom – allerdings nicht als „flashiges“ Endkunden-Feature wie Joule (etwa für eine ansprechende Finanzaufbereitung), sondern vor allem durch stabileren, effizienteren und vorausschauenderen Betrieb im Hintergrund.

Zitat Hendrik Oevermann, Global Head of SAP AO for DTAG & Cross Application Services bei T-Systems: “Flexibilität ist entscheidend. Pläne ändern sich, neue Erkenntnisse kommen hinzu.”

S/4HANA-Migration erfordert Flexibilität: Lessons Learned

Oevermann nennt als zentrale Erkenntnis: Flexibilität ist entscheidend, denn Pläne ändern sich und neue Erkenntnisse kommen hinzu. Das gelte für alle beteiligten Partner.

Er beschreibt die Konstellation wie folgt:

• Deutsche Telekom mit ihren Business-Bereichen auf Kundenseite
• SAP als RISE-Lieferant
• T-Systems als Supplier
• weitere Partner ergänzend

Dieses „Dreieck“ aus Telekom, SAP und T-Systems habe eine gewisse Anlaufzeit gebraucht, sei inzwischen aber gut eingespielt und funktioniere als starkes Partnerprogramm sehr zuverlässig, um gemeinsam auf Veränderungen zu reagieren.

SAP S/4HANA Readiness Check

Sehr wichtig sei außerdem der SAP S/4HANA Readiness Check. Er sei essenziell, um Abhängigkeiten unterschiedlicher Komponenten, Custom Code und Schnittstellen zu verstehen und realistisch zu planen.

RISE: Lernkurve für große, komplexe Kunden

Oevermann betont, dass RISE für große, komplexe Kunden neu ist und alle Beteiligten noch lernen. Gleichzeitig stellt er klar: RISE bleibt, und je früher man sich damit beschäftigt, desto besser.

Deadline 2030: Zeitdruck, Startpunkt und Dienstleistermarkt

Zur Frage, ob man sich bei der Migration auf S/4HANA beeilen müsse, sagt Jansen, es sei schwer, für andere Unternehmen zu sprechen. Für die Telekom sei klar gewesen: Man müsse jetzt anfangen, um 2030 dort zu sein, wo man sein wolle.

Oevermann ergänzt aus technischer Sicht, die nächsten ein bis zwei Jahre seien sehr entscheidend. Wenn SAP bei der Deadline 2030 bleibt, sollte ein Unternehmen je nach Größe spätestens 2027 mit der Umstellung starten, sonst könne es knapp werden.

Support und Verfügbarkeit von Dienstleistern

Oevermann schätzt, dass es mehr als genug Dienstleister im Markt gibt. Viele bauten aktuell gezielt Kapazitäten auf, um den Midmarket und kleinere mittelständische Unternehmen besser bedienen zu können.

T-Systems sei traditionell stark im Großkunden-Segment aktiv und dort sehr präsent. Gleichzeitig habe man zuletzt auch wieder kleinere Projekte umgesetzt, etwa im öffentlichen Sektor und bei kirchlichen Einrichtungen.

Bei vielen großen Dienstleistern liege der Fokus naturgemäß auf sehr großen Kunden. Für den klassischen Mittelstand gebe es jedoch ausreichend Alternativen. Auch SAP selbst sei für kleine und mittlere Unternehmen ein sehr guter Anbieter: Mit den Packaged-Angeboten liefere SAP solide, vollkommen ausreichende Services und sei für diese Kundengruppe auch jederzeit bereit, die Umsetzung zu übernehmen.