Viele Wege führen nach Rom, aber kein Mensch erwartet, dass man von Palermo und Venedig aus die gleiche Route wählt. Auch wenn das Ziel das gleiche ist – die Startpunkte liegen viel zu weit voneinander entfernt. Unternehmen, die sich mit der Modernisierung ihrer bestehenden Greenscreen-Applikationen beschäftigen, haben ebenfalls gemeinsame Ziele. Sie wollen geschäftskritische Anwendungen, die in Jahren und Jahrzehnten entwickelt wurden und in denen umfangreiches Firmenwissen steckt, mit moderner Oberfläche versehen, Wartungs- und Entwicklungskosten senken und so die Lebensdauer um möglichst viele Jahre verlängern.

Damit endet aber die Gemeinsamkeit der Unternehmen beim Reengineering – trotzdem versuchen viele Anbieter von Reengineering-Lösungen, jedem Anwender das eigene Produkt als die beste aller Alternativen zu verkaufen. Das wirkt in Präsentationen meist sehr überzeugend – führt aber in der Praxis oft zu erheblichen Problemen – wenn nicht gar zum Scheitern von Projekten. Es gibt nicht für alle Unternehmen die eine beste Lösung, aber eine beste Lösung gibt es für jedes Unternehmen. Diese kann sich von der Lösung eines anderen Unternehmens aber erheblich unterscheiden, es kommt auch hier auf den Startpunkt an.

Eigenentwicklung vs. Standard-Lösung

Bei erfolgreicher Modernisierung von Anwendungen muss man sich zuerst der Frage stellen, ob es für die bestehende Eigenentwicklung eine Standard-Lösung gibt, die in wesentlichen Kernprozessen den Bedarf abdeckt. Für zahlreiche Anforderungen kann dies der rentabelste Weg sein. Bedeutet die Einführung einer Standard-Lösung aber erhebliche Anpassung von erfolgreich etablierten betrieblichen Prozessen oder gibt es für spezifische Anforderungen keine technische Umsetzung, bietet Reengineering eine sinnvolle Alternative zur kompletten Neuentwicklung. Auch wenn ein Reengineering-Projekt mit Arbeit und Aufwand verbunden ist, die Investition in jahrelange Individualentwicklung wird geschützt und kann (oft zu sehr vertretbaren Kosten) zukunftssicher weiterentwickelt werden.

Reengineering-Projekte werden in zwei Phasen abgewickelt, wobei das wesentliche Augenmerk auf der ersten Phase liegen muss. Hier erfolgt Standortbestimmung mit Produktauswahl und Einführung des Reengineering-Tools, in Phase zwei wird umgesetzt. „Die Praxis zeigt: Je sorgfältiger die Reise vorbereitet wird, desto entspannter ist die Ankunft in Rom – desto punktgenauer werden Reengineering-Projekte in Zeit und Budget realisiert. Leider sparen viele Unternehmen hier an der falschen Stelle, um dann in der zweiten Phase erheblich draufzuzahlen“, berichtet Dipl.-Ing. Martin Schmid, Geschäftsführer der Schmid Informatik in Linz.

In den Reengineering-Projekten wird zunächst eine Grobanalyse der bestehenden Applikationen durchgeführt, in der der konkrete Modernisierungsbedarf festgelegt wird: Welche Applikationen sollen aus welchen Gründen modernisiert werden?
Im Zuge der anschließenden Detailanalyse findet eine Inventur der bestehenden Applikationsumgebung statt. Als Ergebnis erhalten die Unternehmen dann eine Übersicht, welche Modernisierungsvariante notwendig bzw. sinnvoll ist, in welchen Schritten diese durchgeführt werden sollte, welcher Zeitrahmen und Aufwand kalkuliert werden muss und welche Maßnahmen bis zum Echtbetrieb der „neuen“ Lösung durchzuführen sind.

Als Beispiel führt Schmid ein Reengineering-Projekt beim voestalpine Stahl Service Center (voestalpine SSC) in Linz an. Dort stand man vor der Frage, wie die hoch spezialisierte PPS-Lösung (Anarbeitungssystem, AAS), deren Entwicklung 1989 auf einer S/38 begonnen hat und die auf einer iSeries eingesetzt wird, an heutige Architektur- und Oberflächenanforderungen angepasst werden kann.

„Es gab keine Standard-Lösung, die unsere Anforderungen abdecken konnte“, erzählt Mag. Christian Huber, Leiter IT, Prozess- und Projektmanagement beim voestalpine SSC. „Mit der Funktionalität des AAS waren wir auch rundum zufrieden. Die Greenscreen-Oberflächen waren jedoch veraltet und externer Zugriff aus anderen Abteilungen des Konzerns war nur sehr aufwendig möglich.“

Das bestehende System sollte im Zuge des Reengineerings-Projektes neu strukturiert und browserfähig gemacht werden; gleichzeitig galt es, die gewachsenen Sourcen zu bereinigen und von RPG III auf RPG IV umzustellen, um die Wartbarkeit zu verbessern. Die Umstellung ist abgeschlossen, nach Abschluss der Testphase und Fertigstellung der Schulungsunterlagen steht der termingerechten Inbetriebnahme des neuen AAS nichts mehr im Wege.

Fachautorin: Andrea Drescher