ATEGRA Software Engineering

Argumente für eine Ablösung einer bestehenden Anwendung

Anwendungssoftware durchläuft einen Lebenszyklus wie viele andere Dinge auch. Die Lebensdauer einer Anwendungssoftware liegt meistens im Bereich zwischen 10 und 20 Jahren, wobei wir in den letzten Jahren einen Trend zu längeren Lebensdauern sehen. Irgendwann kommt der Moment, wo zu prüfen ist, ob sie abgelöst werden soll. Wir stellen hier Überlegungen an, wann der richtige Zeitpunkt dafür gekommen ist.

Die Prüfpunkte

Worauf sollte man achten? Wir empfehlen die folgenden Punkte zu prüfen:

1. Geänderte Realität: Software wird entwickelt, um eine bestimmte Realität abzubilden. Die Realität wird im sog. logischen Datenmodell modelliert. Ein gutes logisches Datenmodell verträgt Erweiterungen gut. Es ist eine Kunst, die Realität zu analysieren, zu verstehen und ein gutes Datenmodell zu erstellen. Aber auch ein gelungenes Datenmodell kann mit den Jahren nicht mehr der Realität entsprechen, wobei man eher sagen sollte, die Realität entspricht nicht mehr dem Datenmodell, das der Software zugrunde liegt. Die Realität hat sich weiterentwickelt. Beispiele dafür sind: Andere Aufgaben, gesetzliche Änderungen, neue Produkte oder Leistungen, die man anbietet. In solchen Fällen sollte man zuerst prüfen, ob die Software erweitert oder angepasst werden kann oder ob man sie vollständig ersetzen sollte.
2. Hohe Wartungskosten pro Jahr: Wenn die Wartungskosten in den letzten Jahren eher zu- und nicht abgenommen haben, könnte das daran liegen, dass das logische Datenmodell auf dem damals die Anwendung basierte sich in der Zwischenzeit massiv verändert hat und die Geschäftsrealität sich stark anders entwickelt hat. So wird z.B. bei einer Organisation, deren Produkt bislang die Personalvermittlung war und die jetzt den neuen Bereich „Beratungsprojekte“ aufbauen will die Anwendungssoftware für die Personalvermittlung wahrscheinlich nicht mehr passen für die neue Aufgabenstellung „Projekte“ und das zugrundeliegende logische Datenmodell. Wenn man nun mit Software-Wartungsarbeiten versucht der neuen Anforderung gerecht zu werden, kann dies relativ hohe Kosten verursachen, sodass eine Neuentwicklung (oder die Beschaffung eines integrierten Software-Pakets) für beide Bereiche „Personalvermittlung“ und „Beratungsprojekte“ mehr Sinn macht. Empfehlung: Prüfen Sie das logische Datenmodell zusammen mit Experten.
3. TCO-Berechnung: Die „Total Cost of Ownership„, also die Summe aller Kosten über einen Zeitraum von z.B. fünf Jahren ist ein universelles Mass für die Kosten einer Lösung. Hier fliessen alle Kosten für Hardware, Software und Personal ein:
   1. Zu den Hardware-Kosten gehören die Anteile an Server-Leistung, Speicherplatz, Datensicherung sowie Kosten für weitere Hardware wie z.B. für die Zugriffssicherung resp. Sicherheit (z.B. RSA-Token).
   2. Zu den Software-Kosten gehören neben den Software-Wartungskosten und Lizenzgebühren auch die anteilsmässigen Kosten für Zusatzsoftware wie z.B. für die Datensicherung oder die Zugriffssicherung.
   3. Bei den Personal-Kosten haben wir viele „unsichtbare“ Kosten, die man korrekterweise auch mitzählen muss. Dazu gehören folgende: a) die Zeit, die die User mit Support-Fällen verbringen, b) die Zeit, die die Informatiker mit Support-Fällen verbringen, c) die Zeit, die die User mit Lernen und Kennenlernen der Software verbringen (nicht nur offizielle Schulungen und Trainings, sondern auch die oft nicht gemessene Zeit für Nachforschungen, Rückfragen und Abklärungen sowie Hilfe durch andere User), d) die Zeit, die Software-Entwickler für die Entwicklung, die Weiterentwicklung und die Wartung aufwenden müssen, e) die Zeit, die die Projektleiter für die Anforderungsspezifikationen aufwenden müssen (in jeder Anwendungssoftware steckt viel organisatorisches Prozess-Know-How, das zuerst erarbeitet werden musste), die Zeit die die Systemadministratoren oder DevOps mit der Betreuung der System verbringen (müssen) u.a.m.
4. Technische Inkompatibilität mit aktuellem Betriebssystem, Browser, Office o.a.: Wenn eine Anpassung unmöglich ist oder zu hohe Kosten für eine Anpassung entstehen würden, dann ist das auch ein Kriterium, das in den Entscheid für eine Ablösung einfliessen wird. Empfehlung: Konsultieren Sie die Herstellerin der Software und bitten sie sie um eine Stellungnahme.
5. Zu geringe Robustheit: Wenn die Anwendungssoftware zu oft „abstürzt“ oder wenn bestimmte Funktionen nicht mehr funktionieren oder nicht immer. Wie häufig genau „zu oft“ ist, hängt vom Einzellfall ab, aber wenn die Anwendungssoftware mehrmals am Tag dazu führt, dass man wegen eines Neustarts zu viel Zeit warten muss, dann besteht Handlungsbedarf. Mangelhafte Robustheit kann verschiedene Ursachen haben, eine davon kann relativ alte Anwendungssoftware auf einem relativ neuen Betriebssystem sein. Empfehlung: Messen Sie die Robustheit Ihrer Software: Wie oft kommt es zu Problemen? Führen Sie ein Log-Buch.
6. Es stellt sich die Frage, ob man auch Performance, aus Anwendersicht die Antwortszeiten als mögliches Kriterium für eine Ablösung in Erwägung ziehen möchte. Oft kann man die Performance mit neuer (stärkerer) Hardware oder auch mit Optimierungen an der Software verbessern und muss nicht gerade die ganze Software ablösen. Es kann aber auch Ausnahmefälle geben, wo tatsächlich die Software als ganze abgelöst werden muss.

Was kann man wiederverwerten? Was kann man „retten“?

Wenn man eine Software-Anwendung entwickelt oder evaluiert, parametriert, einführt, dann müssen viele Fragen im Bereich Prozesse geklärt werden. Das Detail-Wissen zu diesen Prozessen kann nie vollständig dokumentiert werden, sondern steckt immer auch in den Köpfen einiger weniger Personen.

Wenn eine bestehende Anwendungssoftware durch eine neue Anwendungssoftware ersetzt werden soll, dann sollte man soviel wie möglich von dem bestehenden organisatorischen Prozess-Know-How wiederverwerten. Dazu stehen uns folgende Optionen zur Verfügung:

• Option 1: Ein oder mehrere erfahrene User wirken mit, die die bestehende Anwendungssoftware gut kennen, ein Flair für Prozess-Organisation haben und in der Lage sind die Anforderungen den Informatikern mitzuteilen.
• Option 2: Den oder die Informatiker mitwirken lassen, die die „alte“ Anwendungssoftware entwickelt und gewartet haben. Diese Informatiker haben wertvolles Detailwissen zu Funktionen, Datensemantik und Schnittstellen. Es ist auch durchaus möglich und sinnvoll, dass die Informatiker des alten Anbieters mit den Informatikern des neuen Anbieters im gleichen Projekt für die Neuentwicklung zusammenarbeiten.

Fazit: Eine Ablösung muss gut vorbereitet werden. Nutzen Sie das Know-How der ATEGRA-Projektleiter.