Ablösen oder weiterentwickeln - so treffen Sie die Entscheidung!

Unternehmen sollten jedes System ihrer IT-Landschaft in regelmäßigen Abständen auf den Prüfstand stellen. Das Ergebnis einer solchen Revision kann sein, dass einzelne oder mehrere Anwendungen oder Systeme einfach nicht mehr wirtschaftlich betrieben werden können oder technisch so veraltet sind, dass eine Ablösung lohnen könnte. Manchmal sind neue Hostingmodelle wie das Cloud-Computing oder eine veränderte Strategie Auslöser von Migrationsprojekten. Früher hat man in solchen Fällen das betroffene System oftmals aufwändig saniert oder sogar von Grund auf neu entwickelt. Angesicht der Masse an hochqualitativer Kaufsoftware für die unterschiedlichsten Einsatzbereiche lässt sich eine zeitaufwändige und risikoreiche Neuentwicklung manchmal nicht mehr vertreten.

Um herauszufinden, ob man ein System durch Standardsoftware ersetzen kann, stellen viele Unternehmen zu Beginn des Entscheidungsprozesses einen klassischen Kriterienkatalog zusammen. Darin werden alle Anforderungen eingetragen, die man für relevant hält. Sie werden nach Funktionsgruppen zusammengestellt, gewichtet und danach bewertet.
Solche Kriterienkataloge haben als Basis der Anforderungsanalyse große Schwächen: Sie sind unübersichtlich, weil die gestiegene Komplexität heutiger Systeme zu endlosen Listen führt. Zudem enthalten sie nur eine sehr schlecht überschaubare strukturelle Sicht auf die Software, nicht jedoch die ebenfalls sehr wichtige Prozessdarstellung. Der entscheidende Schwachpunkt ist aber, dass zum Zeitpunkt, zu dem man diese Kataloge zusammenstellt, nicht selten mehr oder weniger unklar ist, welche Anforderungen und Prozesse das bestehende System genau abdeckt und das künftige System eigentlich erfüllen soll. Man müsste die Anforderungen erst modellieren und hierfür ist eine Listendarstellung denkbar ungeeignet.

Verborgene Anforderungen

Ist das System, das abgelöst werden soll, eine kommerzielle Software, ist eine Anforderungs- und Prozessanalyse des Ist-Zustands normalerweise vergleichsweise einfach: Bei kommerziellen Systemen hat der Hersteller in der Regel gut dokumentiert, welche Anforderungen und Prozesse seine Software abdeckt. Anders sieht es bei Systemen aus, die individuell entwickelt oder gekauft und anschließend stark angepasst wurden. Solche Lösungen sind unter Umständen historisch gewachsen, möglicherweise schlecht dokumentiert und man weiß in vielen Fällen gar nicht so genau, welche Anforderungen sie abbilden.

Oftmals ist es außerdem so, dass die Abhängigkeiten von anderen Systemen nur ungenau erfasst wurden. Bei intern entwickelten Systemen ist die Entscheidung zwischen Ablösung oder Weiterentwicklung zudem aus politischen und sozialen Gründen schwierig: Oftmals betrifft die Entscheidung Mitarbeiter, deren Arbeitsplatz bei einer Kaufsoftware wegfallen würde. Aus naheliegenden Gründen sind diese Beschäftigten oft gegen die Ablösung eines Bestandssystems.

Geht es um die Ablösung von selbstentwickelter Individualsoftware, sollte die Situation durch ein seriöses Auswahlverfahren entschärft werden, das klar zeigt, warum es für das Unternehmen besser ist, ein System zu migrieren. Als Grundlage dafür kann ein Bebauungsplan dienen, den ein IT-Architekturteam erarbeitet hat (Abbildung 1). Er ordnet alle Bestandssysteme fachlich in die Unternehmenslandschaft ein. Der Bebauungsplan mit seinem Domänenmodell dient als erste Orientierung. Er ist für ein Auswahlverfahren noch zu wenig detailliert und muss daher durch eine detaillierte Facharchitektur ergänzt werden.

Festlegen einer Facharchitektur

Mithilfe eines solchen Werkzeugs lässt sich der Bebauungsplan in Zusammenarbeit mit dem Fachbereich weiter detaillieren. Dazu legt man genau fest, was das bisher genutzte System abdeckt und leuchtet dessen Schwachpunkte aus. Wie hierbei vorgegangen werden kann, soll am einfachen Beispiel einer Rechnungsprüfung in einem fiktiven Touristikunternehmen gezeigt werden.

Der fachliche Prozess beginnt damit, dass der Hoteleinkäufer des Unternehmens Zimmerkontingente mit den Hotelbetreibern aushandelt. Ist man sich handelseinig geworden, reserviert der Hotelier ein bestimmtes Zimmerkontingent in einer Saison für das Touristikunternehmen. Dieses Kontingent wird durch ein mobiles Einkaufssystem des Touristikunternehmens dem Buchungssystem zur Verfügung gestellt. Die Zimmer dieses Kontingents werden über den Internetauftritt des Touristikunternehmens oder über Reisebüros an den Endverbraucher verkauft - teilweise regulär, teilweise im Last-Minute-Angebot.

Der genaue Verkaufsprozess an den Kunden soll hier nicht im Mittelpunkt stehen, weil er für die Migration unerheblich ist. Wichtiger ist der Verlauf der Reise. Gehen wir als erste Vereinfachung davon aus, dass der Kunde seine Reise antritt. Hier gibt es den Fall, dass er mit der Hotelleistung zufrieden ist und den gesamten Urlaub sein Zimmer vertragsgemäß in Anspruch nimmt. Ist er mit seinem Zimmer nicht zufrieden, kann er es in demselben Hotel tauschen. Wechselt er dabei in der gleichen Zimmerkategorie, hat das auf die Rechnungsstellung des Hoteliers kaum Auswirkungen. Entscheidet er sich aber für eine höhere Kategorie, ist nicht nur die Zimmernummer betroffen, sondern auch der Preis.

Fallbeispiel Rechnungsprüfung

In regelmäßigen Abständen schickt der Hotelier an das Reiseunternehmen Sammelrechnungen über den Aufenthalt der Gäste der entsprechenden Reiseveranstalter. Viele kleinere Hotels haben keine ausgereifte Rechnungsstellung, sondern schreiben ihre Rechnungen entweder auf Basis einer Tabellenkalkulation oder senden Sie als Brief – manchmal sogar noch handgeschrieben. Um die arbeitsaufwändige Prüfung der Rechnung zu automatisieren hat das Reiseunternehmen vor Jahren eine spezielle Anwendung außerhalb des SAP-Systems entwickelt. Es vergleicht die Rechnungen der Hoteliers mit den tatsächlichen Einkäufen und verfügt Schnittstellen zu SAP und dem Buchungssystem. Mithilfe dieser Rechnungsprüfung gibt der Sachbearbeiter zunächst die Rechnungen manuell ein, ordnet sie einer Belegart (mit/ohne Bestellbezug etc.) sowie dem Reiseveranstalter und dem Gast zu. Erst danach kann der Rechnungsbetrag validiert werden.

Der gerade beschriebene Prozess ist langsam, fehleranfällig und sehr teuer. Aus diesem Grund wünscht sich der Fachbereich eine moderne IT-Unterstützung, dies es ermöglicht, Rechnungen automatisiert zu erfassen. Um herauszufinden, ob für diese Lösung ein Standardprodukt in Frage käme, entwickelt die IT zusammen mit dem Fachbereich mehrere fachliche Komponentendiagramme und analysiert die Prozesse (Abbildung 2). Die Komponentendiagramme bildet die fachliche Soll-Landschaft ab. Sie zeigen hierbei anhand von mehreren Komponenten übersichtlich auf, welche Anforderungen die neue Software umsetzen soll. Es ist sozusagen eine intelligentere Form des klassischen Kriterienkatalogs.

Mehrstufige Anforderungsanalyse

Die Anforderungen, die man jeder Komponente zuordnet, lassen sich analog einem Kriterienkatalog beliebig fein (zum Beispiel in mehreren Ebenen) ausarbeiten. Zu jeder Komponente entsteht mindestens ein Diagramm, das zeigt, welche Anforderungen sie im Detail umsetzt (Abbildung 3).

Im Gegensatz zu einem Kriterienkatalog ist ein Unternehmen mit Hilfe dieser Sicht problemlos in der Lage, Wechselwirkungen zwischen den einzelnen fachlichen Komponenten zu beschreiben. Eine Komponente könnte zum Beispiel sein, Rechnungen per Scanner in Bilddateien umzuwandeln. Eine andere kann ein OCR-Modul sein, das Rechnungen wieder in Texte verwandelt, die sich maschinell weiterverarbeiten lassen. Eine weitere Komponente könnte in der Lage sein, E-Mails mit elektronischen Rechnungen direkt zu verarbeiten. Letztere Komponente steht zum Beispiel in Wechselwirkung mit einem Regelwerk, das die fachlichen Regeln für die Weiterverarbeitung festlegt.

Ergänzend zur Komponentensicht zeigen Prozessdiagramme, in welcher Reihenfolge die eben skizzierten fachlichen Komponenten aufgerufen werden. Hat man ein fachliches Komponentendiagramm und die Prozesse als Ziellösung der fachlichen Architektur erarbeitet, lässt sich das derzeit eingesetzte System damit gut bewerten. Da das aktuelle System nur über eine manuelle Digitalisierung ohne OCR-Funktionen und Posteingangsverarbeitung verfügt, schneiden die drei erwähnten Komponenten für die automatische Digitalisierung von Rechnungen schlecht ab (Abbildung 4). Analog dazu lässt sich nun auch Kaufsoftware einordnen. Zum Schluss des Vorgangs kann man die Anforderungen zum Beispiel für eine Ausschreibung in einen klassischen Kriterienkatalog überführen. Er ist in diesem flexiblen Auswahlprozess jedoch nicht die Basis, sondern nur eine Art zusätzliche Sicht auf die modellierten Anforderungen.

Fazit

Das hier beschriebene Auswahlverfahren kombiniert klassische Methoden der objektorientierten Anforderungsanalyse mit einer neuartigen, einfachen und übersichtlichen Komponentendarstellung. Die oftmals starren und endlosen Anforderungskataloge werden durch übersichtliche Darstellungen ersetzt. Durch diese fachlichen Sichten lassen sich Anforderungen in mehreren Ebenen beliebig detailliert darstellen. Trotz der Abbildung komplexer Anforderungen bleibt die Darstellung übersichtlich. Daher ist eine Bewertung von Softwareprodukten für alle Beteiligten einfach nachvollziehbar.