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.