Die Ablösung von IT-Altsystemen

Intro

Vor einigen Jahren kamen wir in den Kontakt mit einem Kunden, der vor folgender Herausforderung stand.

Er betrieb eine große Applikation, die in einer zentralen Plattform über 10.000 Klienten verwaltete. Die Applikation selbst war funktional recht dürr, verwaltete aber viele Transaktionen und sammelte erhebliche Mengen an Daten. Die jeweilige Verbindung der Klienten zur zentralen Plattform wurde über ein gemanagtes VPN abgebildet, immer verschlüsselt auch bei den Datenverbindungen, die dediziert in ein MPLS-Netz gekoppelt und geführt wurden.

Das System war alt - über 20 Jahre. Es hatte regelmäßige Updates bekommen, so dass Sicherheitsthemen nicht im Vordergrund standen. Die eine oder andere Featureerweiterung schlich sich über die Jahre ebenfalls ein.

Die verwendete Software war lizensiert nach der Anzahl der eingesetzten CPUs und die Anzahl der erlaubten Klientenverbindungen pro CPU wurde in dem Lizenzmodell hart begrenzt. Zum Zeitpunkt des Systementwurfs war dies wahrscheinlich zur Gewährleistung der Qualität auch unter Last eine gute Idee … heutzutage führte eine solche Architektur angesichts der Menge der Klienten und der verbesserten CPU-Leistung dazu, dass über 100 Server in völliger Unterlast vor sich hin brummten.

Ganz abgesehen von den exorbitanten (und stetig weiter steigenden) Lizenzkosten war damit der Hardwarebetrieb auch noch eine erheblicher Kostenfaktor. Der Betrieb der Anbindungen der Klienten belastete ebenfalls erheblich das Budget. Letztlich bestand auch der Wunsch, das System selber weiter entwickeln zu können, um den Anschluss an den Markt nicht zu verlieren - was in der vorliegenden Architektur schon allein aufgrund der Lizenzbindung ausgeschlossen war.

3 statt 100

An diesem Punkt kamen wir ins Spiel. Der Kunde fragte uns, ob wir nicht prüfen könnten, ob es gelänge, die Applikation zu überschaubaren Kosten und in der Folge mit erweiterten Möglichkeiten durch eine Eigenentwicklung zu ersetzen.

Innerhalb von sechs Wochen analysierten wir die Applikation und die Systemlandschaft. Dabei standen wir im regelmäßigen Austausch mit verschiedensten Fachspezialisten des Kunden und teilten unsere Zwischenergebnisse alle zwei Wochen mit den Stakeholdern.

Im Ergebnis präsentierten wir folgende Lösung: Die 100 Server könnten - wenn es denn weiterhin on premise sein müsste - durch 3 ersetzt werden. Das gemanagte VPN, insbesondere mit der MPLS-Komponente, war aus Security-Perspektive ein völlig überdimensionierter Lösungsansatz, so dass hier erhebliche Vereinfachungen umgesetzt werden könnten. Die Lizenzkosten würden vollständig entfallen.

Das Ganze war gekoppelt an einen mehrstufigen Entwicklungs- und Migrationsplan mit verschiedensten Ausstiegsszenarien nach einem Proof of Concept (PoC) für die kritischsten Pfade, einer Minimum Viable Product (MVP) - Phase im Parallelbetrieb und einer dann anschließenden, sukzessiven Migration. Wir hatten es so gestaltet, dass einzelne Klienten auf die neue Plattform hätten migriert werden können (unter Einsparung der Lizenz- und Serverkosten) und dennoch in der Altapplikation weiterhin wie gewohnt sichtbar gewesen wären. Darüber hinaus präsentierten wir zahlreiche Ideen, welche neuen Leistungsangebote leichtgewichtig auf Basis der neuen Plattform implementiert werden könnten. Die Gesamtinvestition schätzten wir auf das Doppelte der jährlichen Lizenz- und Hardwarekosten. Die Stakeholder waren scheinbar begeistert.

Aber wir teilten abschließend auch Beobachtungen, die auf ganz andere Herausforderungen hinwiesen.

Viele Emotionen

Im Zuge der Erarbeitung des Konzepts führten wir zahlreiche Interviews mit den Mitarbeitern durch, die die Plattform in allen Facetten - von der lokalen Anbindung über den Serverbetrieb bis hin zum Management der Kundenschnittstelle - täglich begleiteten. Die betroffenen Mitarbeiter waren auf drei unterschiedliche Abteilungen verteilt, die Stakeholder waren die jeweiligen Abteilungsleiter.

In den Gesprächen verspürten wir ein Spektrum von Stimmungen beginnend bei aufrichtiger Neugier, was moderne Technologie alles möglich machen könnte, bis hin zu feindseliger Ablehnung und der wenig verhohlenen Verweigerung, Informationen zu teilen. Wir spiegelten dies bereits während des Prozesses vorsichtig an die Stakeholder zurück, wodurch zumindest die Informationsbereitstellung operativ gesichert wurde.

Aber auch auf der Stakeholderebene war teils deutlich zu spüren, dass die Zugewandtheit und leise Begeisterung eher durch die wahrgenommene Notwendigkeit getragen wurde, einer politischen Erwartung gerecht werden zu müssen, denn durch echte Überzeugung.

Die Situation eskalierte kurz vor unserer finalen Präsentation des Konzepts, was zu diesem Zeitpunkt in wesentlichen Teilen bereits bekannt war. Anlass dafür war ein Innovationsworkshop, den wir mit einer größeren Anzahl an Mitarbeitern anberaumt hatten und im Rahmen dessen wir über potenziell neue Anwendungsfälle der Plattform zur Verbesserung des Kundenerlebnisses sprechen wollten.

Wir trafen auf Totalverweigerung, getrieben durch einen Wortführer des Kunden, der bereits eingangs 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 wir überhaupt ihre Zeit verschwenden würden? Mit großem moderativem Aufwand gelang es so einigermaßen, die Veranstaltung zu retten. Wenig überraschend waren die Ergebnisse jedoch sehr dürftig, so dass wir zu guter Letzt unsere eigene Kreativität hinsichtlich der Erweiterungsoptionen der Plattform bemühen mussten.

„The major problems of our work are not so much technological as sociological in nature.“ [1]

Das Verhalten erschien uns nur zu natürlich. An dem Plattformbetrieb waren über 20 Mitarbeiter in unterschiedlichsten Rollen beteiligt, die diese z.T. bereits so lange ausübten, wie die Plattform existierte.

Die Mitarbeiter empfanden Werkstolz für das, was sie in den letzten Jahren geleistet hatten. Das System war ihnen bis in kleinste Detail vertraut, mit gemeinsamen Teamerfahrungen unverbrüchlich verknüpft und sie reklamierten berechtigterweise 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 Veränderung immer als Risiko für den relevantesten Parameter, der Betriebsstabilität, gesehen wurde.

Vor diesem Hintergrund der täglichen Arbeit und der stabilitätsorientierten Grundhaltung der Menschen 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 Zweifelsfall sogar ihren Arbeitsplatz.

Auch wenn wir, wie zuvor angedeutet, bei der Präsentation unserer Ergebnisse die Diskussion zu diesem Thema suchten, wurde nicht abschließend klar, ob die Stakeholder sich dieser Situation in ihrer gravierenden Bedeutung wirklich bewusst waren. Es drängte sich für uns das Bild auf, dass sie sich teils selber als Opfer sahen und aus dieser Rolle heraus nicht in der Lage waren, ihre Mitarbeiter in dem Prozess entsprechend zu stützen und ihnen die notwendige psychologische Sicherheit zu vermitteln.

Wir sprachen die dringende Empfehlung aus, alle weiteren Schritte im Rahmen eines bewussten Transformationsvorgehens auch auf zwischenmenschlicher Ebene zu begleiten.

Kein Beispiel, ein Muster

Das was an diesem Beispiel sehr deutlich wird, begegnet uns immer und immer wieder.

Die Gründe, alte Systeme anzufassen, können vielfältig sein. 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 kommt in die Jahre und wird absurd teuer, technische Experten für die verwendeten Techologien sterben aus … die Liste ist sicherlich nicht abschließend.

Was auch immer die Anlässe seien mögen, den involvierten Mitarbeitern wird einiges abverlangt. Sie müssen ihre gewohnten Pfade ganz grundsätzlich verlassen, müssen Neues lernen und dies im schlimmsten Fall in einem Umfeld, was ihnen noch nicht einmal die Sicherheit gibt, dass in der veränderten Welt noch ein Platz für sie da ist. Das was potenziell von Führungskräften als “Blockade” wahrgenommen wird, ist ebenso menschlich wie aus dem Organisationskontext heraus verständlich.

Die Friktionen im Unternehmen, die diese Unsicherheiten mitbringen, gefährden fundamental den Erfolg von den häufig nur fachlich getriebenen Bemühungen zur Ablösung von Altsystemen. Von daher ist man gut beraten, neben dem technisch/fachlichen IT- Projekt eine ganz bewusste Veränderungsbegleitung für die Mitarbeiter und Führungskräfte zu implementieren, die wenigstens folgenden Aspekten Rechnung trägt:
 

Aufbau einer Organisationsvision

Bereits früh im Prozess muss ein Bild entwickelt werden, welche Implikationen das Ersetzen des Systems auf Rollen-, Team- und Prozessebene in sich birgt. Selbst wenn das alte System genau dasselbe leistet, wie das neue, gibt es nahezu zwingend Veränderungen, wie unser Beispiel zeigt. Viel eher ist es aber ja so, dass neue Systeme auch die Chance zur Implementierung wirklich neuer, verbesserter Abläufe mit sich bringen - und diese Chance sollte man nicht verstreichen lassen, sondern 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 und ihm nicht entgegenstehen dürfen. 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, selber Sicherheit zu vermitteln und einen sinnvollen Beitrag in den Veränderungsprozess einzubringen.
 

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.
 

Paradoxa erkennen und besprechen

Häufig ist es so, dass die Ablösung von Altanwendungen auch zum Ziel hat, Personal zu reduzieren. Menschen dazu anzuleiten, darauf hin zu wirken, 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. Den größten Fehler begeht man, wenn man als Führungskraft glaubt, das für alle Offensichtliche mit einem Mäntelchen des Schweigens überdecken zu können.

Wir erkennen, dass es sich offensichtlich nahezu immer um mehr handelt, als nur um einen “Change”. Wir sind bei der Ablösung von Altsystemen mit einer Transformation konfrontiert. Den Unterschied sehe ich darin, dass es sich um mehr Veränderung handelt, als eine oberflächliche Neugestaltung von Prozessen und Abläufen. Vielmehr sind ebenso die impliziten Annahmen, die Prinzipien, die Werte und der Glauben der Menschen in der Organisation betroffen.

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

Verstetigung der Veränderung

Tatsächlich ist es so, dass wir zunehmend erkennen, dass Anwendungen nicht mehr „alt“ werden dürfen. Vor dreißig Jahren war es noch denkbar, ein System zu spezifizieren, zu entwickeln, aufzusetzen und es dann - im äußersten Fall - bis zum heutigen Tage zu betreiben (wie in dem genannten Beispiel). Ein solches Vorgehen erschien lange wie ein sinnvoller Investitionsschutz und weniger wie strategischer Unsinn.

In diesen Tagen schwingt das Pendel bei einer solchen Herangehensweise eher in Richtung strategischen Unsinn. Im Fundament von nahezu jedem Geschäftsmodell findet sich bereits derzeit Informationstechnologie. Eine Abschottung gegen die rasante Weiterentwicklung derselben kommt einem Todesurteil gleich, auch wenn der Tod nur schleichend eintreten mag.

Damit stellen sich in der Erneuerung von Altsystemen eigentlich zwei Herausforderungen: Es geht nicht nur um die Substitution selbst, sondern gleichzeitig um die Schaffung der Rahmenbedingungen dafür, dass das neue System nicht zügig wieder zu einem Altsystem wird.

Die Veränderungsanforderungen, die daraus erwachsen, sind viel größer als der schlichte Austausch des Altsystems selbst. Vielmehr müssen die organisationellen Voraussetzungen dafür geschaffen werden, dass die Organisation den einmal für den Ersatz der Altsysteme durchgeführten Veränderungsprozess verstetigen kann.

Und damit kommen wir an einen Punkt, wo wir eigentlich über nichts anderes sprechen, als über agile Transformation.

PS

… und wie ging es weiter mit dem Beratungsprojekt? Wir implementierten den PoC - zeitlich mit starken Verzögerungen, aber immerhin. Eine Transformationsbegleitung fand unseres Wissens nach nicht statt. Aus Gründen der Konzernpolitik wurde das Projekt sehr zum Leidwesen unserer Stakeholder dann intern in andere Hände gegeben und schließlich eingestampft. Unseres Wissens nach läuft die Plattform immer noch …

Quellen

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