Herausforderungen bei der Ablösung von IT-Altsystemen

Gastbeitrag von | 15.07.2024

Ein Erfahrungsbericht über die Ablösung eines IT-Altsystems mit Beobachtungen jenseits der Technik

Ein Kunde stand vor einer großen Herausforderung: Seit 20 Jahren betrieb er ein Mandanten-System, das 10.000 Klienten und unzählige Transaktionen dieser Klienten verwaltete. Die jeweilige Verbindungen der Klienten zum System wurden über ein gemanagtes VPN mit MPLS Routing abgebildet. Die Lizensierung des Systems basierte auf der Anzahl der genutzten CPUs, wobei die Anzahl der Zugriffe pro CPU begrenzt wurde, was natürlich die Anzahl der CPUs in die Höhe schraubte. Zum Zeitpunkt des Systementwurfs war dies vermutlich eine gute Idee zur Gewährleistung der Zugriffsqualität auch unter Last; heutzutage führt eine solche Architektur aufgrund der verbesserten CPU-Leistung dazu, dass sich 100 Server in völliger Unterlast langweilen. Kurzum: Ein in die Jahre gekommenes System mit exorbitanten Lizenzkosten und erheblichen Hardwarekosten.

Hier kamen wir ins Spiel. Der Kunde fragte uns, ob es möglich wäre, das IT-Altsystem durch eine Eigenentwicklung mit überschaubarem Aufwand und erweiterten Möglichkeiten zu ersetzen.

Technische Alternative. Oder von 100 auf 3.

Innerhalb von sechs Wochen analysierten wir die Anwendung und die Systemlandschaft. Dabei standen wir in regelmäßigem Austausch mit verschiedenen Fachspezialisten des Kunden und teilten alle zwei Wochen unsere Zwischenergebnisse mit den Stakeholdern.

Am Ende präsentierten wir folgende Lösung: Die 100 Server des Altsystems konnten durch 3 ersetzt werden. Das Managed VPN mit der MPLS-Komponente war aus Sicherheitssicht eine völlig überdimensionierte Lösung, so dass erhebliche Vereinfachungen realisiert werden konnten. Lizenzkosten würden komplett entfallen.

Das Ganze war gekoppelt an einen mehrstufigen Entwicklungs- und Migrationsplan mit verschiedenen Ausstiegsszenarien nach einem Proof of Concept für die kritischsten Pfade, einer Minimum-Viable-Product-Phase im Parallelbetrieb und einer anschließenden sukzessiven Migration.

Wir hatten es so konzipiert, dass einzelne Klienten auf die neue Plattform hätten migriert werden können (unter Einsparung von Lizenz- und Serverkosten) und dennoch wie gewohnt in der Altapplikation sichtbar geblieben wären. Darüber hinaus präsentierten wir zahlreiche Ideen, welche neuen Serviceangebote auf Basis der neuen Plattform schlank umgesetzt werden könnten. Die Gesamtinvestition schätzten wir auf das Doppelte der jährlichen Lizenz- und Hardwarekosten. Die Stakeholder schienen begeistert.

Beobachtungen jenseits der Technik

Neben der technischen Alternative teilten wir dem Kunden auch unsere Beobachtungen jenseits der Technik mit.

Im Zuge der Konzeptentwicklung führten wir zahlreiche Interviews mit den Mitarbeitern, die die Plattform in all ihren Facetten – von der lokalen Anbindung über den Serverbetrieb bis hin zum Management der Kundenschnittstelle – täglich betreuten. Diese Mitarbeiter waren auf drei verschiedene Abteilungen verteilt, deren Leiter als Stakeholder fungierten.

In den Gesprächen erlebten wir ein breites Spektrum an Stimmungen: von aufrichtiger Neugier, was moderne Technologie ermöglichen könnte, bis hin zu feindseliger Ablehnung und der offenen Weigerung, Informationen zu teilen. Diese Reaktionen spiegelten wir vorsichtig an die Stakeholder zurück, um zumindest die operative Informationsbereitstellung zu sichern.

Auch auf Stakeholder-Ebene war spürbar, dass die gezeigte Begeisterung eher aus der Notwendigkeit resultierte, politischen Erwartungen zu entsprechen, als aus echter Überzeugung.

Kurz vor unserer finalen Konzeptpräsentation eskalierte die Situation. Anlass war ein Innovationsworkshop, den wir mit einer größeren Anzahl an Mitarbeitern anberaumt hatten, um über neue Anwendungsfälle der Plattform zur Verbesserung des Kundenerlebnisses zu sprechen.

Wir stießen auf totale Verweigerung, angeführt von einem Wortführer des Kunden, der gleich zu Beginn feststellte, dass die Plattform bereits alles könne, was sie müsse, und das nächste offizielle Release alle weiteren Wünsche erfüllen würde. Warum also ihre Zeit verschwenden? Mit viel Moderation ist es uns gelungen, die Veranstaltung einigermaßen zu retten. Die Ergebnisse waren jedoch dürftig, sodass wir letztlich unsere eigene Kreativität bemühen mussten, um Erweiterungsoptionen der Plattform zu entwickeln.

“The major problems of our work are not so much technological as sociological in nature.” – To DeMarco¹

Das Verhalten der Mitarbeiter erschien uns nur allzu verständlich. Über 20 Mitarbeiter in unterschiedlichsten Rollen waren am Plattformbetrieb beteiligt, viele von ihnen seit der Einführung der Plattform:

  • Die Mitarbeiter empfanden Stolz auf das, was sie in den letzten Jahren geleistet hatten. Das System war ihnen bis ins kleinste Detail vertraut, und es war eng mit gemeinsamen Teamerfahrungen verknüpft. Sie reklamierten zu Recht absolutes Expertentum.
  • Alle Prozesse und Rollen waren eingespielt, jeder wusste, wofür er stand. Eine Kultur des Lernens war nicht ausgeprägt, denn Lernen hätte Veränderung impliziert. Und Veränderung war nicht gewünscht, da sie als Risiko für den wichtigsten Parameter, die Betriebsstabilität, gesehen wurde.

Vor diesem Hintergrund war unser Vorschlag disruptiv. Er stellte alles in Frage: ihre Kompetenz, die Abläufe und Prozesse, ihre soziale Integration, ihre Vergangenheit, ihre technischen Überzeugungen und im schlimmsten Fall sogar ihren Arbeitsplatz.

Auch wenn wir bei der Präsentation unserer Ergebnisse die Diskussion suchten, wurde nicht klar, ob die Stakeholder die Tragweite der Situation wirklich erkannten. Es schien, als sähen sie sich selbst als Opfer und seien daher nicht in der Lage, ihre Mitarbeiter im Prozess zu unterstützen und ihnen die notwendige psychologische Sicherheit zu vermitteln.

Wir empfahlen dringend, alle weiteren Schritte im Rahmen eines bewussten Transformationsvorgehens auch auf zwischenmenschlicher Ebene zu begleiten.

Veränderungsbegleitung bei der Ablösung von IT-Altsystemen

Das, was an diesem Beispiel sehr deutlich wird, begegnet uns immer wieder. Die Gründe, Altsysteme zu überarbeiten, sind vielfältig:

  • Die Einarbeitungszeit neuer Mitarbeiter ist zu lang,
  • die Systeme sind nicht mehr sicher,
  • die Lizenzkosten zu hoch,
  • eine Weiterentwicklung ist nicht mehr möglich,
  • die notwendige Hardware wird alt und teuer,
  • technische Experten für die verwendeten Technologien sterben aus.

Die Liste ist lang und nicht abschließend.

Egal, welche Anlässe es gibt, den beteiligten Mitarbeitern wird viel abverlangt. Sie müssen ihre gewohnten Pfade verlassen, Neues lernen und dies im schlimmsten Fall in einem Umfeld, das ihnen nicht einmal die Sicherheit gibt, dass in der veränderten Welt noch ein Platz für sie ist. Was von Führungskräften als “Blockade” wahrgenommen wird, ist ebenso menschlich wie aus dem Organisationskontext heraus verständlich.

Die Unsicherheiten, die diese Friktionen im Unternehmen mit sich bringen, gefährden den Erfolg der oft nur fachlich getriebenen Bemühungen zur Ablösung von Altsystemen. Daher ist es ratsam, neben dem technischen IT-Projekt eine bewusste Veränderungsbegleitung für Mitarbeiter und Führungskräfte zu implementieren, die mindestens folgende Aspekte berücksichtigt:

Aufbau einer Organisationsvision

Bereits früh im Prozess muss ein Bild entwickelt werden, welche Implikationen das Ersetzen des Systems auf Rollen-, Team- und Prozessebene hat. Selbst wenn das alte System genau dasselbe leistet wie das neue, gibt es nahezu zwangsläufig Veränderungen, wie unser Beispiel zeigt. Neue Systeme bieten jedoch oft die Chance zur Implementierung wirklich neuer, verbesserter Abläufe – und diese Chance sollte man nutzen und entsprechend begleiten.

Führungskräfte als Verbündete

Gerade die Führungskräfte müssen verstehen, welche Ablaufänderungen ihre Bereiche betreffen, wie sich Schnittstellen verschieben und dass sie diesen Prozess mitgestalten müssen. Hierfür ist es notwendig, dass auch die Führungskräfte selbst ein frühes Verständnis ihrer zukünftigen Rolle entwickeln können. Nur aus einer eigenen Position der Sicherheit heraus sind sie in der Lage, Sicherheit zu vermitteln und einen sinnvollen Beitrag zum Veränderungsprozess zu leisten.

Veränderungsbedarfe erkennen und begleiten

Persönliche Veränderungsbedarfe, die durch das neue Umfeld gefordert werden, müssen frühzeitig erkannt und begleitet werden. Den Mitarbeitern muss die Chance gegeben werden, auch zukünftig eine Expertenrolle, wenn auch eine veränderte, einnehmen zu können. Dieser Prozess erfordert eine individuelle, persönliche Führung, wie wir sie leider viel zu selten in Organisationen im Regelbetrieb beobachten.

Widersprüche erkennen und besprechen

Häufig ist es so, dass die Ablösung von Altanwendungen auch das Ziel hat, Personal zu reduzieren. Menschen dazu anzuleiten, ihren eigenen Arbeitsplatz in der gewohnten Form überflüssig zu machen, gelingt nur, wenn man den erkennbaren Widerspruch benennt und die zukünftigen Handlungsoptionen gemeinsam ausarbeitet. Der größte Fehler ist es, als Führungskraft zu glauben, das Offensichtliche mit einem Mantel des Schweigens überdecken zu können.

Wir erkennen, dass es sich fast immer um mehr handelt als nur um einen “Change”. Bei der Ablösung von Altsystemen sind wir mit einer Transformation konfrontiert. Der Unterschied liegt darin, dass es um mehr Veränderung geht als nur um eine oberflächliche Neugestaltung von Prozessen und Abläufen. Vielmehr sind auch die impliziten Annahmen, Prinzipien, Werte und der Glaube der Menschen in der Organisation betroffen.

Ist das einmal verstanden, könnte man meinen, dass es mit einer professionellen Transformationsbegleitung getan ist. Das Altsystem wird ausgewechselt, das neue ist da, Prozesse und Workflows rekalibrieren sich, die Menschen finden sich im neuen Umfeld ein. Aber so einfach funktioniert unsere Welt heute leider nicht mehr.

Verstetigung der Veränderung

In der Tat erkennen wir immer mehr, dass Anwendungen nicht mehr “alt” werden dürfen. Vor zwanzig Jahren war es noch denkbar, ein System zu spezifizieren, zu entwickeln, zu implementieren und dann – im Extremfall – bis heute zu betreiben (wie im genannten Beispiel). Ein solches Vorgehen erschien lange Zeit eher als sinnvoller Investitionsschutz denn als strategischer Unsinn.

Heute schlägt das Pendel bei einem solchen Vorgehen eher in Richtung strategischer Unsinn aus. Informationstechnologie ist bereits heute die Grundlage fast aller Geschäftsmodelle. Sich ihrer rasanten Weiterentwicklung zu verschließen, kommt einem Todesurteil gleich, auch wenn der Tod nur schleichend eintritt.

Bei der Erneuerung von Altsystemen geht es also eigentlich um zwei Herausforderungen: Es geht nicht nur um die Ablösung selbst, sondern gleichzeitig darum, die Rahmenbedingungen dafür zu schaffen, dass das neue System nicht schnell wieder zum Altsystem wird.

Die damit verbundenen Veränderungsanforderungen gehen weit über die bloße Ablösung des Altsystems hinaus. Vielmehr müssen die organisatorischen Voraussetzungen dafür geschaffen werden, dass die Organisation den Veränderungsprozess, der mit der Ablösung des Altsystems eingeleitet wurde, verstetigen kann. Diese Verstetigung fand in unserem Projekt leider nicht statt. Zeitlich stark verzögert konnten wir das Proof of Concept umsetzen, aus konzernpolitischen Gründen wurde das Projekt dann zum Leidwesen unserer Stakeholder intern in andere Hände gegeben und schließlich eingestellt. Die Plattform läuft heute noch…

 

Hinweise: 

Melden Sie sich gerne bei Dr. Stefan Barth, wenn Sie sich mit ihm über technologiegetriebenen Wandel austauschen wollen oder konkreten Unterstützungsbedarf haben. Auf LinkedIn ist Stefan Barth gut zu erreichen.

[1] DeMarco, Tom; Lister, Timothy, “Peopleware – Productive Projects and Teams”, 3rd Edition, Addison Wesley, 2013

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Dr. Stefan Barth hat zwei weitere Beiträge im t2informatik Blog veröffentlicht:

t2informatik Blog: Der Gestaltungswunsch von Führungskräften

Der Gestaltungswunsch von Führungskräften

t2informatik Blog: Weg mit den Budgets

Weg mit den Budgets

Dr. Stefan Barth
Dr. Stefan Barth

Dr. Stefan Barth ist COO der Qvest Digital AG und treibt die agile Transformation der Organisation voran. Zuvor war er als Berater, Start-Up Mitgründer, Mitglied der Geschäftsleitung eines TecDAX-Unternehmens sowie Einzelunternehmer tätig. Zunächst aus der Welt der klassischen Führung kommend, veränderte er seine Haltung und erarbeitete sich über verschiedenste Mandate Erfahrungen in agilen Transformationsprozessen und der Steuerung von agilen Organisationen. Sein Know-how vermittelt er in Beratungsprojekten, Vorträgen und Artikeln.