Change Management

Die Telekom-IT wird agil

22.06.2020
Von 
Jens Dose ist Editor in Chief von CIO. Seine Kernthemen drehen sich rund um CIOs, ihre IT-Strategien und Digitalisierungsprojekte.

Eine Zeitvorgabe für die neuen Prozesse gibt es nicht. "Die Abteilungen können sich so schnell oder langsam damit vertraut machen, wie sie wollen und können," betont Maragkopoulou. Das sei ein wichtiger Faktor für die Akzeptanz in der Belegschaft. Bisher sei etwa die Hälfte der 10.000 Mitarbeiter in den agilen Modus gewechselt.

Probleme mit hybriden Methoden

Problematisch sieht die Managerin Abteilungen, die sowohl mit der neuen als auch mit der alten Methode arbeiten: "Die Mitarbeiter dort sind in einem Spannungsfeld, das ihnen die Freude an der Transformation nimmt. Sie müssen ständig zwischen zwei Geschwindigkeiten wechseln."

Daher sei es besonders wichtig, diese hybriden Abteilungen schnell vollständig auf das SAFe-Framework umzustellen. Zehn bis 20 Prozent der Organisation arbeiteten aber zunächst weiter im alten Modus. Erst durch Legacy-Abbau oder Umstrukturierungen könnten sie in die neue Welt wechseln.

In "Leuchtturmprojekten" setzen Telekom-Mitarbeiter Werkzeuge aus dem SAFe-Baukasten ein, um beispielsweise Kundenschnittstellen zu verbessern.
In "Leuchtturmprojekten" setzen Telekom-Mitarbeiter Werkzeuge aus dem SAFe-Baukasten ein, um beispielsweise Kundenschnittstellen zu verbessern.
Foto: Deutsche Telekom/Carsten Güse; Haroc Marcard

Auf der technischen Ebene bildet Collaboration-Software eine tragende Säule. Sie fördert den Erfahrungsaustausch und die Zusammenarbeit der Mitarbeiter in den IT- und Fachabteilungen. "Zu den wichtigsten Zutaten für den Erfolg unseres Change-Prozesses gehören aber Open-Source-Software und Microservices," sagt die IT-Leiterin. Quelloffene Software biete die nötige Skalierbarkeit und sei flexibel genug, um mit den agilen Methoden Schritt zu halten.

Damit könne die IT die richtigen Entscheidungen zur richtigen Zeit treffen, um eine bestimmte Anforderung zu erfüllen, "aber ohne einen Fünf-Jahres-Plan einzugehen, den wir später eventuell verteidigen müssen, wenn die Lösung schon wieder obsolet geworden ist." Durch Microservice-Strukturen ließen sich einzelne Anwendungsteile besser bearbeiten und testen. Zudem bleibe der Rest der Anwendung intakt, sollte bei einem Microservice mal etwas schief gehen.