Wie regle ich die Nachfolge?

Stefan Zumbrunn ist Business-Unit-Leiter bei Zühlke; Richard Gafner ist dort Principle Management Consultant. Viele Unternehmen arbeiten mit Applikationen, die über Jahre gewachsen sind. Solche Legacy-Systeme – auf Deutsch Altsysteme – basieren häufig auf Grossrechnern und wurden individuell für das Unternehmen entwickelt. Mittlerweile sind jedoch die Betriebs- und Entwicklungs­-um­gebungen veraltet, die Software ist unzureichend dokumentiert, sehr komplex und verfügt über zahlreiche verschiedene Schnittstellen. Eine Transformation wird unverzichtbar, die Unternehmens-Software muss durch ein neues System abgelöst werden. Dabei gibt es einige Hürden zu überwinden. Die Erfahrung aus der Praxis hat gezeigt, dass dabei folgende Faktoren entscheidend sind:

Ein Ablöseprojekt unterscheidet sich nicht grundlegend von einer Neuentwicklung. Trotzdem gilt es, einige Punkte zu beachten, zum Beispiel beimRequirements Engineering. Denn bei Ablöseprojekten sind die Anforderungen oft implizit in der bestehenden Applikation versteckt. Folgende Fragen  helfen, die Anforderungen auf den Punkt zu bringen:

Ohne die bestehende Applikation genau zu kennen, ist die Planung der Ablösung mit grossen Risiken behaftet. Erst wenn klar ist, wodurch sich die abzulösende Applikation auszeichnet, worin die genauen Benutzeranforderungen bestehen und wo das Verbesserungspotenzial liegt, ist eine realistische Schätzung und Planung möglich. Wie wichtig die genaue Abklärung der Anforderungen ist, zeigt das Beispiel einer führenden Anbieterin von Finanz- und Versicherungsprodukten. Die bestehende Applikation zum Erstellen von Offerten sollte durch eine neue Lösung ersetzt werden, die sich besser erweitern und einfacher bedienen lässt. Erst im Verlauf des Projekts zeigte sich, dass auch Aktuare und Underwriter – sie zeichnen die Risiken und schliessen Verträge ab – mit der Applikation arbeiten. Dies erweiterte die Anforderungen mit entsprechenden Folgen für den Projektplan. Nur weil Verbesserungen und Veränderungen von Beginn an eingeplant waren, konnte diese unerwartete Hürde trotzdem gemeistert werden: Ein Usability-Spezialist analysierte mit den Benutzern die bestehende Applikation und erarbeitete ein neues Konzept – ohne den Terminplan zu verzögern. Lesen Sie auf der nächsten Seite: Benutzer einbeziehen

In einem anderen Projekt bei einem grossen Versicherer galt es, einen seit über 30 Jahren bestehenden Host abzulösen. Hier wurden die Benutzer anfangs nicht genügend einbezogen. So war zum Beispiel nicht klar, in welch rasendem Tempo die Datentypisten alle Daten auf einem Bildschirm erfassen. Mit der Ablösung des Hosts mussten zudem umfassende und sensible Daten migriert werden. Dieser Prozess war planbar. Ungeplant und trotzdem notwendig war jedoch die Verbesserung der Datenqualität. Auch dies muss von Anfang an berücksichtigt werden.

Eine Ablösung kann nur erfolgreich umgesetzt werden, wenn die Schwächen des Altsystems bekannt sind. Dazu ein Beispiel, ebenfalls aus der Versicherungsbranche: Das Team unterzog erste Features der neuen Applikation einem Usability-Test und dehnte diesen auch auf die alte Applikation aus. Dabei zeigte sich, dass bestimmte Bedienabläufe bei der alten Applikation sehr umständlich waren. Die Benutzer hatten sich aber daran gewöhnt. Erst der Blick von aussen liess das Potenzial erkennen und ermöglichte es dem Projektteam, entsprechende Verbesserungen in die Planung einflies­sen zu lassen. Es lohnt sich deshalb, einen Usability-Spezialisten beizuziehen. Dieser ist in der Lage, durch seine Beobachtungen und Fragen, Abläufe zu verstehen und Verbesserungspotenzial zu erkennen – eine wichtige Voraussetzung für eine optimale Transformation. Bei der Inbetriebnahme und beim Testing unterscheiden sich Ablöseprojekte von Neuentwicklungen. So ist während der Übergangsphase oft ein Parallelbetrieb beider Systeme zu gewährleisten und beim Testen sollte die neue Applikation mit der bestehenden verglichen werden. Lesen Sie auf der nächsten Seite: Veränderungen kommunizieren

Die Ablösung eines Legacy-Systems bietet oft Gelegenheit, Business-Prozesse anzupassen. Damit sind Veränderungen verbunden, die auf Widerstand stossen können. Doch auch wenn sich die Transformation auf die bestehende Funktionalität beschränkt, hat sie Einfluss auf die Benutzer, die Betreuer und die gesamte Organisation. Mit den Benutzern müssen Bedienung, Zuständigkeiten und allenfalls geänderte Ansprüche geklärt werden. Dabei ist insbesondere dem Expectation Management, also dem Umgang mit Erwartungshaltungen, hohe Beachtung zu schenken. Eine der grössten Gefahren bergen Versprechen, die nicht eingehalten werden können. Der Benutzer sollte informiert sein, weshalb das System abgelöst wird, welche prozessualen oder organisatorischen Veränderungen auf ihn zukommen und welche Vorteile diese bringen. Hilfreich ist, eine Benutzergruppe einzurichten, welche die Transformation eng begleitet und Veränderungen aus Benutzersicht kommentiert.

 Eine Transformation bedeutet meist auch eine Veränderung für die Betreuer der Anwendung. Die Mitarbeiter müssen möglichst früh in den Prozess einbezogen werden. In persönlichen Gesprächen können die Chancen aufgezeigt werden, die sich durch die neuen Rollen und Verantwortlichkeiten ergeben. Dafür sollte genügend Zeit eingeplant werden. Und auch hier ist wichtig, keine falschen Versprechungen zu machen.
Wer den Veränderungsprozess erfolgreich umsetzen will, muss Vertrauen aufbauen und Akzeptanz schaffen. Dies bedingt ein dediziertes Change Management, das von erfahrenen Personen gestaltet wird.

Entscheidungsfindung: Wie wird ein Legacy-System abgelöst?

Es gibt mehrere Wege, ein altes System zu ersetzen: Hardware-Transformation: Eine Host-Applikation lässt sich ohne Code-Anpassung auf preisgünstigere Hardware migrieren, beispielsweise Cobol auf Unix oder auf eine PC-Umgebung.Ziel dabei ist, die Lizenzkosten des Hosts zu reduzieren. Ersatz ohne funktionale Anpassungen: Ziel ist eine möglichst günstige und schnelle Abwicklung. Dies ist zwar sinnvoll, dabei wird aber oft die Chance einfacher Verbesserungen verpasst und die Möglichkeit verschenkt, den Umfang zu reduzieren, indem nicht notwendige Features weggelassen werden.Deshalb sollten in jedem Fall auch funktionale Anpassungen eingeplant und gut umgesetzt werden, insbesondere wenn diese mit relativ kleinem Aufwand grossen Nutzen bringen. Ersatz mit funktionalen Erweiterungen/Anpassungen: Dies ist oft die sinnvollste Variante. Der Fokus sollte dabei auf der Ablösung und nicht auf der Erweiterung liegen. Oft birgt die fehlende Bereitschaft zur Definition konsistenter Anforderungen ein Risiko, v.a. wenn die neue Lösung verschiedene alte vereinen soll. Hier ist ein gut organisiertes Change Management entscheidend. Eigenentwicklung versus Standardlösung: Kann und soll eine Standardlösung eingesetzt werden oder ist eine Individualentwicklung wirtschaftlicher? Hier gelten dieselben Überlegungen wie bei einer Neuentwicklung – mit einem Unterschied: Die Benutzer haben hohe Erwartungen an das neue System. Sie akzeptieren Verschlechterungen nur schwer. Dies birgt insbesondere beim Ablösen von Individualentwicklungen durch Standardlösungen ein Risiko. Dem Change-Prozess muss deshalb besondere Aufmerksamkeit geschenkt werden. Betrieb in der Cloud: Im Rahmen der Ablösung sollte auch eine Cloud-Lösung in Betracht gezogen werden, auch wenn diese Überlegungen nicht im
direkten Zusammenhang mit der Erneuerung stehen.