Migration eines Software-Moduls

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Formelverzeichnis

1 Einleitung
1.1 xy Deutschland GmbH und xy
1.2 Zielsetzung der Arbeit
1.3 Motivation
1.4 Methodischer Aufbau der Arbeit

2 Migration
2.1 Definitionen
2.1.1 Migration
2.1.2 Software-Modul
2.1.3 IT-Projekt
2.2 Arten
2.2.1 Softwaremigration
2.2.2 Prozessmigration
2.2.3 Datenmigration
2.2.4 Anwendungsmigration
2.3 Strategien
2.3.1 Big Bang (Cold Turkey Strategy)
2.3.2 Chicken-Little Strategy
2.3.3 Database First
2.3.4 Database Last
2.3.5 Butterfly Methodology
2.3.6 Composite Database
2.4 Wirtschaftlichkeitsbetrachtung
2.4.1 Arten und Ziele
2.4.2 Kriterien
2.4.3 Entscheidungsfällung
2.5 Risiken
2.5.1 Kostenüberschreitung
2.5.2 Zeitüberschreitung
2.5.3 Mangelndes Personal
2.5.4 Performance- und Qualitätsverlust

3 Voranalyse
3.1 Product Lifecycle Cost Management (PLCM)
3.1.1 Definition und Aufbau
3.1.2 Anforderungsmanagement
3.1.3 Businessplan
3.1.4 Entwicklung
3.1.5 Rolloutmanagement
3.2 Ursache für die Migration
3.2.1 Ablösung der veralteten Technologie
3.2.2 Erhalt der Wettbewerbsfähigkeit
3.3 Kosten- / Nutzen-Analyse
3.3.1 Interne Kosten- / Nutzen-Analyse
3.3.2 Externe Kosten- / Nutzen-Analyse
3.3.3 Break-Even-Analyse
3.4 Soll- / Ist-Analyse
3.4.1 Erläuterung und Zweck
3.4.2 Voraussetzungen für eine Migration
3.4.3 Ausgleich der Abweichungen

4 Durchführung der Migration
4.1 Vorbereitung
4.1.1 Definition der Infrastruktur
4.1.2 Qualitätssicherung
4.1.3 Probebetrieb
4.2 Umstellung
4.2.1 Datenbanksicherung
4.2.2 Konvertierung
4.2.3 Tests
4.3 Rolloutmanagement
4.3.1 First-Level- und Second-Level-Support
4.3.2 Schulung
4.3.3 Dokumentation

5 Fazit
5.1 Zusammenfassung
5.2 Bewertung und Feedback
5.3 Ausblick

Anhang

Literaturverzeichnis

Eidesstattliche Erklärung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Einsatzbereiche der xy-Software

Abbildung 2: Module der Software xy

Abbildung 3: Teufelsquadrat

Abbildung 4: Erhöhung der Qualität und Senkung der Entwicklungsdauer

Abbildung 5: Dokumentensammlung im Sharepoint

Abbildung 6: Anforderungen an KiWi

Abbildung 7: Inhalte des PLCM-Businessplans

Abbildung 8: KiWi-Vision

Abbildung 9: KiWi-Vertriebsmodell

Abbildung 10: PLCM-Nutzenanalyse

Abbildung 11: PLCM-Präsentation – Entwicklungsübersicht

Abbildung 12: PLCM-Präsentation - Rolloutmanagement-Übersicht

Abbildung 13: Interner Aufwand in MT und Kosten in €

Abbildung 14: Break-Even-Diagramm

Abbildung 15: Break-Even-Diagramm (Prognose) für xy KiWi

Abbildung 16: Prognose des Migrationsumsatzes in den ersten drei Jahren

Abbildung 17: Break-Even-Diagramm (Prognose) mit Break-Even-Point

Abbildung 18: Voraussetzung für eine Migration

Abbildung 19: Migrationsprozess aus Kundensicht

Abbildung 20: Migrationsprozess aus Sicht der xy

Abbildung 21: Teilprozess Vorbereitung innerhalb des Migrationsprozesses

Abbildung 22: Ausschnitt eines Netzwerkplans

Abbildung 23: Vorbereitungstätigkeiten für den Probebetrieb

Abbildung 24: Teilprozess Umstellung innerhalb des Migrationsprozesses

Abbildung 25: Checkliste vor der Umstellung

Abbildung 26: Erster Schritt des Umstellungsprozesses

Abbildung 27: Teilprozesse nach der Vorbereitung der Migration

Abbildung 28: Sicherung einer SQL-Datenbank im Microsoft Enterprise Manager I

Abbildung 29: Sicherung einer SQL-Datenbank im Microsoft Enterprise Manager II

Abbildung 30: Vierter und Fünfter Teilprozess des Umstellungsprozesses

Abbildung 31: ODA-Datenkonvertierung innerhalb des HealthCare-ODA-Converter

Abbildung 32: Abschließende Teilprozess des Umstellungsprozesses

Abbildung 33: Testfälle

Abbildung 34: Ende des Migrationsprozesses

Abbildung 35: Rollout-Tätigkeiten nach der Umstellung

Abbildung 36: Zielgruppen der Migration

Abbildung 37: Migrationsdokumente

Tabellenverzeichnis

Tabelle 1: Kriterien der Wirtschaftlichkeitsbetrachtung

Tabelle 2: Benötigte Kosten für die Break-Even-Analyse

Tabelle 3: Unterteilung der potenziellen Migrationskunden nach Bettenanzahl

Formelverzeichnis

Formel 1: Formel zur Ermittlung des Kosten-Nutzen-Verhältnisses eines IT-Projekts

Formel 2: Berechnung des durchschnittlichen Lizenzbetrages pro Monat

Formel 3: Berechnung der zusätzlichen Umsätze aus Dienstleistungen pro Monat

Formel 4. Berechnung der monatlichen Umsätze für die Migration von xy KiWi

Formel 5: Berechnung des Break-Even-Points

1 Einleitung

Der Begriff Migration kommt ursprünglich aus dem Lateinischen und bedeutet übersetzt „Wanderung“. Da allerdings viele Vorgänge als Wanderung angesehen werden, wird der Begriff Migration in vielen verschiedenen Themenbereichen verwendet und hat somit mehrere verschiedene Bedeutungen. Zum Beispiel wird in der Soziologie mit dem Begriff Migration eine „auf Dauer angelegte, beziehungsweise dauerhaft werdende räumliche Veränderung des Lebensmittelpunktes einer oder mehrerer Personen verstanden“^[1], wohingegen in der Astronomie die „Planetenwanderung“^[2] als Migration bezeichnet wird. Was dieser Begriff in der Informationstechnik (IT) bedeutet und welche Zielgruppen hier eine Rolle spielen, soll unter anderem in dieser Arbeit erläutert werden. Auch in der Abteilung xy der z GmbH spielt der Begriff der Migration seit geraumer Zeit eine wichtige Rolle.

1.1 Das Unternehmen und die Abteilung

Die z GmbH ist ein Unternehmen der a Holding AG, welches „eines der führenden eHealth - Unternehmen in Europa“^[3] ist. Die z GmbH bietet maßgeschneiderte IT-Lösungen für den Akut-, Reha- und Sozialmarkt an. Das Unternehmen ist Marktführer bei Reha-Systemen und umsatzstärkster Anbieter in der Sozialwirtschaft.

Der Hauptstandort der z GmbH befindet sich in Koblenz, weitere Standorte befinden sich in Berlin, Hannover, Osnabrück, Höxter, Düsseldorf, Bensheim, Augsburg, München und Oberessendorf.

Die Abteilung xy an dem Standort b ist für die gleichnamige Produktlinie xy verantwortlich, hinter der die Branchenklassiker c und d stehen. Diese ganzheitlichen Branchenlösungen organisieren alle administrativen Prozesse in Reha-, Vorsorge- und Fachkliniken sowie ambulanten Einrichtungen.

Die verschiedenen Einsatzbereiche der Software e sind in Abbildung 1 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Homepage xy Deutschland, 2010

Abbildung 1: Einsatzbereiche der e -Software

Die Thematik der Migration betrifft das Modul Therapieplanung (GTp) der Software e. Aus diesem Grund sind die anderen Einsatzbereiche der Software nicht weiter nennenswert.

Ausgeschrieben bedeutet die Abkürzung GTp Gesundheitswesen Therapieplanung. Dieses Modul ermöglicht den Kunden eine effektive Therapie- und Terminplanung.

1.2 Zielsetzung der Arbeit

In dieser Bachelorarbeit wird auf wissenschaftliche Weise die Thematik der Migration analysiert und erläutert. Dabei wird ein komplettes Migrationsprojekt in der Abteilung xy betrachtet und beispielhaft dargestellt. Zu einem Migrationsprojekt gehören neben der Durchführung der Migration an sich noch einige weitere Prozesse, wie zum Beispiel eine genaue Voranalyse und ein ausführliches Rolloutmanagement. Die einzelnen Subprozesse, die bei dem Migrationsprozess eine Rolle spielen, werden im Nachfolgenden näher erläutert.

Die Tätigkeiten im Unternehmen im Bereich dieser Thematik waren die Erstellung aller Dokumente während der Analyse und der Durchführung des Migrationsprojekts, welche in den einzelnen Phasen für verschiedene Zielgruppen von Bedeutung sind. Diese Dokumente und Unterlagen sind im Anhang dieser Arbeit enthalten.

Diese Bachelorarbeit ist für drei unterschiedliche Gruppen gedacht: das Unternehmen xy, die Duale Hochschule Baden-Württemberg und der Autor der Arbeit. Dabei haben die verschiedenen Gruppen auch unterschiedliche Anforderungen an diese Bachelorarbeit.

Das Unternehmen xy, im Besonderen die Abteilung xy, ist an der genauen und klaren Erläuterung der Migration und der einzelnen Prozesse interessiert. Vor allem die Erstellung der einzelnen Dokumente, zu denen mehrere Analysen mit verschiedenen Bereichen der xy notwendig waren und welche im Laufe der Erstellung dieser Bachelorarbeit durchgeführt wurden, bringen einen wesentlichen Nutzen für weitere Migrationsprojekte innerhalb des Unternehmens. Des Weiteren wurde im Rahmen dieser Bachelorarbeit ein Konzept zur Planung und Durchführung einer Migration eines Software-Moduls innerhalb der xy®-Software erarbeitet.

Die Anforderungen der Dualen Hochschule an eine Bachelorarbeit sind in den Gestaltungsrichtlinien allgemein definiert. Laut diesen soll die Studierende mit der Bachelorarbeit zeigen, dass sie durchaus in der Lage ist, eine praxisbezogene Problemstellung nach wissenschaftlichen Maßstäben zu bearbeiten.^[4]

Und schließlich möchte die Autorin der Bachelorarbeit zeigen, dass sie sich mit dem Thema Migration gezielt auseinander gesetzt hat und dieses auch verstanden hat. Außerdem möchte die Autorin in der Bachelorarbeit ihr Themengebiet sowohl aus Sicht der Theorie als auch aus Praxis-Sicht betrachten; dieses vor allem auch aus dem Grund, um das gelernte Wissen an der Dualen Hochschule auf die Praxis im Unternehmen übertragen und hier nachvollziehen zu können.

Das konkrete Interesse in dieser Arbeit sieht die Autorin darin, notwendige Tätigkeiten und die jeweilige Vorgehensweise bei der Migration eines Software-Moduls in der

Praxis zu erkennen und diese detailliert abzubilden, so dass der Geschäftsprozess Migration nach und nach optimiert und einfacher erweitert bzw. verkürzt werden kann.

1.3 Motivation

Momentan wird in der Abteilung der xy der xy Deutschland GmbH die Migration eines Software-Moduls durchgeführt. Zunächst wird die Migration nur bei einem Kunden durchgeführt. Das Software-Modul soll allerdings noch bei zahlreichen weiteren Kunden migriert werden. Dabei ist die Migration eines Software-Moduls ein relativ neuer Prozess für die Mitarbeiter der Abteilung xy. Es existieren bis dato noch keine Dokumentationen oder Erläuterungen zur Durchführung dieser. Allerdings würden diese die nachfolgenden Migrationen erleichtern und die Durchlaufzeiten des Migrationsprozesses minimieren, da jeder einzelne Prozessschritt ausführlich dokumentiert wäre. Dokumentationen haben außerdem noch den Vorteil, dass sich jeder einzelne Mitarbeiter zu einer beliebigen Zeit und ohne jegliche Abhängigkeit von anderen Mitarbeitern über den gesamten Migrationsprozess informieren kann. Desweiteren werden durch die Erstellung der Dokumente die einzelnen Zielgruppen in das Migrationskonzept mit eingebunden.

In den zielgruppenorientierten Dokumenten werden ein breites Knowhow und viele Informationen gebündelt und auf einfache Weise transportiert.

1.4 Methodischer Aufbau der Arbeit

Die vorliegende Bachelorarbeit setzt sich aus fünf Kapiteln zusammen.

Das erste Kapitel stellt die Einleitung dar. In diesem Kapitel wird kurz auf die Thematik dieser Arbeit eingegangen. Desweiteren ist in diesem Kapitel die Zielsetzung der Arbeit vorzufinden. Der Aufbau der Arbeit – in diesem Abschnitt befinden Sie sich gerade – ist ebenfalls ein Teil des ersten Kapitels.

Im zweiten Kapitel soll der Begriff „Migration“ umfangreich und detailliert erläutert werden.

Im dritten Kapitel wird die Analyse, die vor der Durchführung einer Migration erfolgt, beschrieben. Dieses Kapitel ist bereits sehr praxisorientiert. Hier wird genau auf die Vorgehensweise vor der eigentlichen Migration in dem Migrationsprojekt der Abteilung xy eingegangen.

Im vierten Kapitel „Durchführung der Migration“ wird dann der genaue Ablauf mit der Vorbereitung, der Umstellung und dem Rolloutmanagement, dargestellt.

Und last but not least erfolgt eine kurze Zusammenfassung des Gesagten bzw. Geschriebenen und ein Ausblick zum Thema „Migration“ vor allem in dem Unternehmenszweig xy. des Unternehmens xy.

2 Migration

Wie bereits in der Anleitung erwähnt, ist die Bedeutung des Begriffes Migration sehr umfangreich. In dieser Bachelorarbeit soll die Migration eines Software-Moduls näher erläutert werden. Somit sind die nachfolgenden Analysen und Feststellung auf den IT-Bereich zurückzuführen. Selbst in diesem Bereich ist der Begriff Migration weit gefächert. Zum einen sind mehrere verschiedene Migrationsarten vorhanden, zum Anderen sind verschiedene Strategien bei der Migration anwendbar. Die verschiedenen Migrationsarten und -strategien werden unter anderem im diesem Kapitel erläutert. Zunächst soll aber geklärt werden, was unter den einzelnen Begriffen Migration, Software-Modul und IT-Projekt im Rahmen dieser Bachelorarbeit zu verstehen ist.

2.1 Definitionen

2.1.1 Migration

Ursprünglich kommt der Begriff Migration vom lateinischen Wort ‚migrare‘, mit welchem eine Wanderung oder eine Übersiedlung bezeichnet wird. In der IT wird sinngemäß mit der Migration der

„Wechsel oder Übergang hin zu einer neuen Lösung bezeichnet“ ^[5].

Somit wird unter der IT-Migration ein koordinierter

„Übergang von einer bestehenden Ausgangsplattform auf eine Zielplattform“ ^[6]

verstanden. Vor allem im Zusammenhang mit einer Installierung ist die Migration immer dann von Bedeutung, wenn entweder wesentliche Komponenten der Informationsinfrastruktur ersetzt werden oder von einem vor-relationalen auf ein relationales Datenbanksystem übergegangen wird. Grundsätzlich gehört zu einer Migration im Kontext der IT

„die Abwicklung einer Reihe von Teilprozessen, die sich im Rahmen einer Systemüberführung aus einer bisherigen Anwendungsumgebung in eine neue Lösung abspielen“ ^[7].

Oft wird dieser Begriff falsch verstanden. Bei der Migration handelt es sich nicht nur um die reine Übertragung der betrieblich relevanten, produktiven und wichtigen historischen Daten, auch wenn das den Kernprozess der Migration darstellt. Oftmals wird bei einer Migration die IT-Umgebung verändert, womit auch der organisatorische Ablauf anders gestaltet und somit neu modelliert werden muss. Die Modellierung eines neuen organisatorischen Ablaufs gehört ebenfalls zur Migration dazu und stellt somit einen Teilprozess dar. Desweiteren stellen die Prüfung, ob die bereits vorhandenen Rechnersysteme die erforderliche Leistung für das neue System erbringen können, und die notwendigen Tests des neuen Systems nach der Übernahme der Daten ebenfalls Teilprozesse der Migration dar. Somit deckt dieser Begriff nicht nur die technische Übersiedlung von Alt nach Neu ab, sondern auch die Teilprozesse, die vor und nach dem Übergang notwendig sind.

Das Ziel einer Migration ist entweder die Verbesserung der Systeme, die Ablösung von alten, zum Teil auch manuellen Verfahren durch neue maschineller Systeme, die Nutzen neuer Softwarereleases oder der Einsatz leistungsfähiger Hardware.^[8] Somit wird mit diesem Begriff die Planung und Umsetzung des Weges von etablierten Lösungen zu neu definierten Zielsystemen in Projekten beschrieben.

2.1.2 Software-Modul

Wer, wie, was? Das sind auch die Fragewörter, die bei einer Migration eine entscheidende Rolle spielen. Dieser Abschnitt behandelt die Frage nach dem ‚Was‘. Es ist nämlich nicht von vornherein klar, was migriert wird. Während bei der einen Migration ein komplett neues System migriert wird, kann bei einer anderen ‚nur‘ ein neuer Prozessschritt in den bestehende Geschäftsprozess integriert werden, was aber ebenfalls als Migration bezeichnet werden kann. Bei der Migration in dieser Bachelorarbeit und somit auch in dem Unternehmensbereich xy handelt es sich um die Migration eines neuen Moduls in die bestehende Software xy®. Ein Software-Modul ist ein elementarer Bestandteil einer Software. Wobei mit dem Begriff ‚Software‘ ein in einer Programmiersprache geschriebenes Programm bezeichnet wird. Bei der Software xy® handelt es sich um eine Anwendungssoftware oder auch Applikationssoftware genannt. Diese haben das Ziel „die Aufgaben von Anwendern innerhalb eines Computersystems zu lösen“^[9]. xy® ist in der objektorientierten Programmiersprache ‚Delphi‘ geschrieben und beinhaltet momentan fünf Module, die nachfolgend aufgelistet werden.

- Gesundheitswesen Patientenmanagement (GPm)
- Gesundheitswesen Informationslisten (GIL)
- Gesundheitswesen Therapieplanung (GTp)
- Elektronische Patientenakte (EPA)
- KI für Windows (KiWi)

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Erstellung

Abbildung 2: Module der Software xy

Jedes der fünf Module ist ein abgeschlossener, unabhängiger Teil eines gesamten Softwareprograms. Somit muss die Software xy® nicht in ihrer Gesamtheit installiert werden, sondern kann an die Anforderungen des Kunden angepasst werden. In einem Software-Modul werden jeweils Daten und Verarbeitungsschritte zusammengefasst. Durch die Programmierung mehrerer Module ergeben sich folgende Vorteile:^[10]

- Das gesamte System wird übersichtlicher, da es gegliedert und strukturiert wird.
- Kleine und abgeschlossene Programmblöcke sind einfacher zu verstehen als große.
- Die Module können mehrfach verwendet werden und sie sind beliebig kombinierbar.
- Durch das inkrementelle Vorgehen ist die Software leichter zu testen.
- Änderungen sind einfacher durchzuführen
- Die Arbeit kann geteilt werden, womit paralleles Programmieren möglich ist (Verteilung auf mehrere Programmierer).

In dieser Bachelorarbeit handelt es sich um das Software-Modul KiWi, das ebenfalls in der Abbildung 2 zu sehen ist. Die Erläuterung dieses Moduls folgt in einem weiteren Kapitel.

2.1.3 IT-Projekt

Wie bereits in der Erläuterung des Migrations-Begriffes in Kapitel 2.1.1 dargestellt, werden unter diesem Begriff mehrere Teilprozesse zusammengefasst. Deshalb kann die Migration als ein IT-Projekt verstanden werden, wie es bei der xy auch der Fall ist.

^[11] Nach DIN 69901 wird unter einem Projekt „ein Vorhaben bezeichnet, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist“. Zu diesen Bedingungen zählt die Vorgabe eines Ziel, eine zeitliche, finanzielle, personelle oder andere Begrenzungen, eine Abgrenzung gegenüber anderen Vorhaben und eine projektspezifische Organisation (Struktur- und Ablauforganisation). Typisch für Projekte in der Informatik ist die Erstellung neuer oder zumindest wesentlich veränderter Informationssysteme. Außerdem ist die Bewertung von Hardware, Software und Dienstleistungen als Aufgabe des Technologiemanagements und die Migration von Software-Systemen typische IT-Projekte.

Allerdings können nicht alle Tätigkeiten in einem IT-Unternehmen als Projekte bezeichnet werden. Ein Projekt ist deshalb klar definiert durch folgende Merkmale:

- Die Projektlaufzeit ist relativ kurz. Idealerweise dauert ein IT-Projekt wenige Wochen bis maximal ein Jahr.
- An dem Projekt ist eine mittlere bis große Anzahl an Personen und Institutionen beteiligt. Das bedeutet, dass ein Prozess, der von einer einzigen Person erledigt wird, nicht als Projekt bezeichnet werden kann.
- Bei IT-Projekten ist keine isolierte Sichtweise möglich, da meistens Schnittstellen zu anderen Projekten und Komponenten der Informationsinfrastruktur bestehen.
- Der Projektfreiheitsgrad ist gering, da die Projektziele durch die vorgegebenen Planungsziele bestimmt werden.
- Da es zwar wahrscheinlich, allerdings nicht zu 100% sicher ist, dass die Planungsziele erreicht werden, besteht ein gewisses Ergebnisrisiko bei IT-Projekten.
- Es können durchaus auch Unsicherheiten bezüglich der Einhaltung von Termin- und Kostenzielen bei IT-Projekten bestehen.
- Meistens besteht auch ein Wettbewerb um die Ressourcen für die Projektabwicklung, wie Budget, Personal und Betriebsmittel, mit anderen Projekten.

Die gerade aufgezählten Punkte eines IT-Projektes können bei einer Migration und den dazugehörigen Prozessen beobachtet werden. Somit wird eine Migration als ein eigenständiges Projekt angesehen und gehandhabt.

2.2 Arten

Je nachdem was innerhalb der IT migriert wird, gibt es verschiedene Migrationsarten. In diesem Abschnitt soll geklärt werden, welche Migrationsart bei der xy vorliegt. Hierzu sollen zunächst alle vorhandenen Migrationsarten erläutert werden. Es wird zwischen vier verschiedenen Arten unterschieden: Software-, Prozess-, Anwendungs- und Datenmigration.

2.2.1 Softwaremigration

Bei der Softwaremigration werden vorhandene Softwareartefakte in eine neue Umgebung überführt, ohne dass die bestehende Fachlichkeit verändert wird. Es handelt sich hier also um eine Überführung in eine neue operationale Umgebung. Auf technischer Ebene kann die Softwaremigration Änderungen in der Hardware-Umgebung, der Laufzeitumgebung, der Software-Architektur oder der Software-Entwicklungsumgebung auslösen. Zwar ist der Spruch „Never touch a running system“ richtig und wichtig, dennoch existieren Gründe für eine Umstellung der Software, auch wenn diese fehlerfrei funktioniert.

Auch wenn die bestehenden „Systeme das gesamte, historisch gewachsene Knowhow der Unternehmen verkörpern und durch jahrzehntelange Wartung auch stabil arbeiten“, so stehen diesen Vorteilen Nachteile „wie hohe Wartungs- und Lizenzkosten, geringe Anpassungsflexibilität an moderne Technologien und rückläufiges Programmierwissen gegenüber“^[12]. Durch eine Software-Migration werden die aufgezählten Nachteile beseitigt oder zumindest minimiert und etablierte Softwaresysteme in modernen und flexiblen Umgebungen bereitgestellt.

Folgende Prozesse fallen unter die Thematik der Software-Migration:

- (Teil)automatische Konvertierung von Programmen aus antiquierten Programmiersprachen wie z. B. COBOL oder PL/I in moderne(re) Sprachen wie C++ und Java
- Integration in neue Betriebssysteme
- Modernisierung von Datenhaltung und Benutzeroberfläche
- Übertragung in modernere Softwarearchitekturen.^[13]

Heutzutage ist trotzdem noch bemerkbar, dass die meisten Unternehmen vor einer Software-Migration zurückschrecken oder diese immer länger hinauszögern, da diese für die Unternehmen mit viel Arbeit und meistens auch mit viel Frust verbunden ist.

Desweiteren haben Unternehmen im Regelfall „mit technischen und organisatorischen Anforderungen zu kämpfen, wenn sie Software migrieren: Projekte binden in großem Umfang Ressourcen. Außerdem müssen Mitarbeiter neues Wissen über Softwaretechniken auf Programm- und Tool-Ebene aufbauen.“^[14]

Somit müssen sowohl bei der Software-Migration, als auch bei den anderen Migrationsarten eine gründliche Analyse der Effekte durch die Durchführung der Migration ermittelt werden. Sollten keine oder nur sehr wenige und nicht unbedingt relevante Vorteile durch die Migration feststellbar sein, so gilt: „Never touch a running system“.

2.2.2 Prozessmigration

Die Prozessmigration beinhaltet die Entwicklung und die Implementierung von verbesserten Abläufen. Zwar spielt die Verbesserung der bestehenden Geschäftsprozesse bei jeder der vier Migrationsarten eine Rolle, allerdings stellt diese das Hauptziel bei der Prozessmigration dar.

^[15] Bei der Prozessmigration sind zum Einen die neuen und optimierten Abläufe innerhalb des Unternehmens zu designen und zum Anderen, was noch viel wichtiger ist, die organisatorischen Gesichtspunkte neu zu überdenken und gegebenenfalls neu zu modifizieren. Um diese Aufgaben zu bewältigen, müssen Fragen der Zuständigkeit und Verantwortlichkeit innerhalb des Unternehmens behandelt werden.

Nichts wird ohne Grund gemacht, auch nicht eine Prozessmigration, somit existieren folgende Gründe für die Migration von Prozessen:

Zum Beispiel kann durch das Verlagern von Prozessen die Arbeitslast entsprechen ausbalanciert werden, wodurch die zur Verfügung stehenden Rechenleistungen effizienter erschlossen werden können. Außerdem können durch die Neustrukturierung der Prozessabläufe die Ressourcen der vorhandenen Infrastruktur effektiver genutzt werden, z.B. indem eine entfernte, zentrale Speicherstruktur in eine verteilte umgewandelt wird. Durch die Umwandlung der Speicherstruktur werden lokale Zugriffe auf häufig benötigte Massenspeicher beschleunigt, was eine verminderte Transferauslastung der beteiligten Netzwerkinfrastruktur zur Folge hat.

Ein weiterer Grund für die Prozessmigration ist eine erhöhte Fehlerresistenz. Diese ist dadurch begründet, dass ein optimierter Ablauf eine kürzere Laufzeit auf den Rechnersystemen besitzt und somit einer niedrigeren Ausfallwahrscheinlichkeit seitens der technischen Infrastruktur ausgesetzt ist als die bestehenden, nicht optimierten Prozesse.

2.2.3 Datenmigration

Nicht nur Software und Prozesse können migriert werden, sondern auch Daten. Unter der Datenmigration wird „die Überführung von betrieblich-relevanten und wichtigen historischen Daten des abzulösenden Legacy-Systems in eine neue Software-Umgebung“^[16] verstanden. Dabei ist eine klare Abgrenzung der Daten, welche in den Überführungsprozess einfließen sollen, ein wichtiger Prozessschritt dieser Migrationsart. Vor der Überführung der Daten muss die vorhandene Datenqualität überprüft werden. Sollten diese Mängel aufweisen, z.B. weil die Daten wegen einer vernachlässigten Pflege veraltet sind, müssen diese vor der Migration behoben werden. Außerdem könnten wichtige Daten noch nicht digitalisiert, sondern nur noch in Papierform vorliegen. In so einem Fall muss ebenfalls vor der Migration entschieden werden, ob einzelne Daten noch digitalisiert werden müssen. Gründe für eine Datenmigration könnten die Vermeidung von Kompatibilitätsproblemen und die Anpassung der Daten an den veränderten Standard sein. Außerdem könnte die Schaffung einer einheitlichen Datenstruktur der Auslöser für eine Datenmigration sein. Eine einheitliche Datenstruktur muss vor allem bei der Zusammenführung von Daten, z.B. beim Aufkauf eines Unternehmens, hergestellt werden, da hier einige Daten in redundanter Form vorliegen könnten. Eine Anpassung der Daten ist auch bei einer Auslagerung von unternehmensinternen Geschäftsprozessen an einen Dienstleister erforderlich. Bei Aktualisierungen der Software sind oftmals auch Datenmigrationen notwendig. Für die Durchführung von Datenmigrationen werden meistens angefertigte Anwendungen oder Skripte verwendet. Einige solcher Anwendungen oder Skripte sind oft Open-Source-Applikationen und somit kostenlos erhältlich.

2.2.4 Anwendungsmigration

Last but not least können Anwendungen in eine bestehende Software migriert werden. Unter der Anwendungsmigration wird im Regelfall der Wechsel von einer alten zu einer neuen Software-Lösung bezeichnet, wobei ein einfaches Upgrade oder eine Aktualisierung der Komponenten damit nicht gemeint sind, denn wie bereits im Abschnitt 2.1.3 erwähnt, ist die Migration ein IT-Projekt, welches unter anderem dadurch definiert wird, dass die Ausführung mehr als eine Person benötigt. Ein Upgrade und die Aktualisierung der Komponenten kann aber durch eine einzige Person durchgeführt werden. Bei der Anwendungsmigration findet deshalb meistens eine grundlegende Veränderung der bestehenden Anwendungs-Infrastruktur statt. Der Übergang von der alten zur neuen Software-Lösung erfolgt dabei langsam und schrittweise. Für die Ablösung einer alten Software-Lösung und somit für die Durchführung einer Anwendungsmigration können mehrere Gründe genannt werden: z.B. werden die bestehenden Geschäftsprozesse durch einen umfassenden Generationenwechsel und somit durch die Umstellung auf die neue Technologie effizienter und schneller durchführbar.

Desweiteren sind durch die neue Technologie neue Lösungen implementierbar. Außerdem kann eine veraltete und oft auch individuell angefertigte Software-Lösung ab einem gewissen Zeitpunkt nach der Einführung den gehobenen Ansprüchen der laufenden Prozesse nicht mehr gerecht werden. Ein weiterer Punkt, wieso veraltete Software-Lösungen abgelöst werden sollten, ist, dass diese keine Möglichkeit für Erweiterungen und Anpassungen bieten.

Neben der reinen Implementierung der neuen IT-Lösung müssen bei der Durchführung einer Anwendungsmigration weitere umfangreiche Planungsvorgänge beachtet und ausgeführt werden. Unter anderem müssen vor dem Start des Migrationsprojekts die Risiken der Einführung analysiert werden. Dieser Schritt ist vor allem für die Auswahl einer geeigneten Überführungsstrategie notwendig. Die einzelnen Migrationsstrategien werden im nachfolgenden Kapitel 2.3 näher erläutert.

Bei der Migration von xy® KiWi handelt es sich um die eben vorgestellte Anwendungsmigration.

2.3 Strategien

Im vorherigen Kapitel wurde erläutert, was alles in dem Bereich IT und innerhalb einer bestehenden Software migriert werden kann. In diesem Kapitel soll nun dargestellt werden, welche verschiedenen Migrationsstrategien zur Auswahl stehen. Migrationen können nämlich auf mehrere Arten und Weisen durchgeführt werden. Grundsätzlich gibt es vier Hauptstrategien bei der Umsetzung einer Migration: die parallele Strategie, die Strategie eines direkten Umstiegs, die Pilotstudiendienststrategie und die Strategie des phasenweisen Ansatzes. Bei der Auswahl einer Migrationsstrategie muss im Wesentlichen entschieden werden, ob die Umstellung der laufenden Software schrittweise oder zu einem festen Stichtag durchgeführt werden soll. Die verschiedenen Migrationsstrategien werden nachfolgend genannt und kurz erläutert.

2.3.1 Big Bang (Cold Turkey Strategy)

Der Big Bang Approach, auch Cold Turkey Strategie genannt, wird bei einer stichtagbezogenen Umstellung angewendet, deshalb auch der Name „Big Bang“.

Bei dieser Strategie wird das neue System parallel zum laufenden Altsystem entwickelt. Während der Entwicklung erfolgen laufend verschiedene Tests auf das neue System, damit potentielle Fehlerquellen bereits im Vorfeld beseitigt werden können. Sobald die neue Lösung allen relevanten Tests unterzogen wurde und diese fehlerfrei waren, kommt es zur Umstellen des Altsystems auf das Neusystem. Die Bezeichnung „Big Bang“ beruht darauf, dass das Altsystem an einem festgelegten Stichtag abgeschaltet und das Neusystem aktiviert wird.

Der Nachteil der „Big Bang“ - Vorgehensweise oder auch Cold Turkey Strategie liegt darin, dass für die Neuentwicklung viel Zeit in Anspruch genommen wird. Zeit ist aber in der heutigen Zeit vor allem in der IT ein sehr entscheidender Faktor. In der Neuentwicklungszeit könnten nämlich durchaus notwendige Änderungen am Altsystem durchgeführt werden, welche dann auch in das neue System implementiert werden müssten. Diese zusätzlichen und nicht vorhersehbaren Implementierungen sind mit intensiven Kosten und einer erhöhten Fehleranfälligkeit verbunden.^[17] Außerdem fällt oft eine umfangreiche Dokumentation des Altsystems, wodurch dieses erst einmal einer gründlichen Analyse unterzogen werden muss. Auch die Abhängigkeiten zu anderen Systemen müssen analysiert werden, um Seiteneffekte und Fehler im Echtbetrieb zu vermeiden.

Die große Menge an Daten stellt ebenfalls eine Schwierigkeit bei dieser Methode dar. Die Daten dürfen während der Übertragung vom Altsystem in das Neusystem nicht verändert werden. Diese Übertragung kann aber ab einer bestimmten Anzahl an Daten bis zu mehreren Wochen dauern. Ein Produktivbetrieb ohne Änderungen der Daten ist aber unvorstellbar. Somit würde das Unternehmen, bei dem die Umstellung erfolgt, für mehrere Wochen praktisch stillgelegt. Die Migrationsprojekte, bei der die Cold Turkey Strategie angewandt wird, sind in der Praxis meist schwierig und kaum überschaubar. Diese Strategie scheitert deshalb meistens an der Einhaltung des Zeitplans für die Entwicklung des Neusystems. Meistens dauert die Neuentwicklung länger als geplant. Es entsteht demnach in den meisten Fällen eine Verzögerung der Fertigstellung, welche nicht eingeplante Mehrkosten für das Migrationsprojekt bedeutet. Außerdem ist diese Strategie mit sehr viel Risiko verbunden, denn sollte bei der Umstellung bzw. dem Big Bang etwas schief laufen, können enorme Kosten auf Grund des dann notwendigen Abbaus, der zu Stande kommenden Unterbrechungen und der Kosten für die Fehlerkorrektur anfallen.

2.3.2 Chicken-Little Strategy

Die Chicken-Little Strategy wird bei einer schrittweisen Umstellung angewendet. Bei dieser Strategie ist eine Entscheidung für den Zeitpunkt der Datenbank-implementierung möglich. Der Migrationsprozess wird bei dieser Strategie in elf kleine Teilschritte zerlegt, somit wird auf eine inkrementelle Weise vorgegangen. Die inkrementelle Vorgehensweise sagt aus, dass ein Projekt in seiner Gesamtheit geplant, allerdings in einzelnen Schritten realisiert wird. Dieser Lösungsansatz ist in der IT auch unter dem Begriff „Divide & Conquer“ bekannt. Durch die Aufteilung des zentralen Prozesses in mehrere Teilprozesse soll der notwendige Aufwand minimiert werden.

Außerdem können die Teilprozesse somit parallel oder sequentiell (nacheinander) abgearbeitet werden. Die Teilprozesse werden dann entweder schrittweise zu einer Gesamtlösung zusammengefasst oder der letzte Teilprozess ergibt bereits das fertige Gesamtergebnis. Vor der Anwendung der Chicken Little Strategy müssen die Struktur und die Funktionsweise des Alt-Systems bekannt und verstanden sein. Somit ist der erste der elf Teilschritte bei der Chicken Little Strategy das Analysieren der zur Legacy-System gehörenden Dokumentation. Das Legacy-System ist ein großes Software-System, welches wichtige Aufgaben im Unternehmen erledigt. Generell wird jedes System nach seiner Einführung zu einem Legacy-System.^[18]

Nachdem das System, welches umgewandelt werden soll, erfolgreich analysiert worden ist, folgt im zweiten Schritt der Chicken Little Strategy die Zerlegung des Legacy-Systems. Hierbei muss vor allem auf das Vorhanden sein von definierten Schnittstellen zwischen den einzelnen Modulen und Datenbank-Backends geachtet werden. Als Backend wird der Teil der Programme bezeichnet, die auf dem Server laufen.^[19] Der dritte Schritt dieser Strategie ist die Konzipierung und Erstellung der Benutzeroberfläche des neuen Zielsystems. Daraufhin werden im vierten Schritt die künftigen Zielanwendungen entwickelt.

Im fünften Schritt wird dann das neue Datenbank-Backend entwickelt, im sechsten Schritt wird die Zielumgebung installiert und im siebten Schritt werden die Entwicklung und die Installation der Gateways beschrieben. Gateways extrahieren die zu überführenden Daten aus den Quellstrukturen des Altsystems und integrieren diese anschließend in das Zielsystem.^[20] Die Umstellung der alten Anwendungssysteme erfolgt im Schritt neun und die Benutzeroberfläche wird dann in Schritt 10 migriert. Im letzten Schritt der Chicken Little Strategy, also in Schritt 11, erfolgt die Umschaltung vom alten auf das neue System, indem das alte System umgestellt und das Altsystem abgeschaltet und das neue System aktiviert wird. Nach diesem Schritt gilt die Chicken Little Strategy als beendet und somit die Migration abgeschlossen.

Bei der Chicken Little Strategy kann des Weiteren zwischen zwei Alternativen gewählt werden: Database First und Database Last. Wo der Unterschied liegt und welche Vor-und Nachteile bei den jeweiligen Alternativen zustande kommen, wird in den nachfolgenden zwei Unterkapiteln erläutert.

2.3.3 Database First

Bei der Database First Approach handelt es sich ebenfalls wie bei der Database Last Approach um die Art und Weise der Datenbankimplementierung. Der Database First – Ansatz wird auch als Forward Migration (dt. Vorwärts Migration) bezeichnet.

Bei dieser Alternative wird das bestehende Datenbanksystem vor den Anwendungen und den Benutzeroberflächen modernisiert. Das Altsystem sollte allerdings schon vor der Migration der Anwendungen und der Benutzeroberflächen auf die neu migrierte Datenbank zugreifen können. Damit dies möglich ist, muss ein sogenannter Forward Gateway zur Herstellung der Kommunikation zwischen dem alten und dem neuen System implementiert werden. Nachdem die Anwendungen und Benutzeroberflächen ebenfalls migriert worden sind, kann der Forward Gateway wieder deaktiviert werden. Ab diesem Zeitpunkt gilt der Migrationsprozess als abgeschlossen.

Vorteile bei dieser Alternative sind, dass die Datenbank am Ende der Migration mit den Anwendungen zusammenpasst, da ja mit der Entwicklung der neuen Anwendungsumgebung erst begonnen wird, wenn das Datenbanksystem bereits migriert ist, und bei der Entwicklung umfangreiche Tests mit den zu entwickelnden Anwendungen durchführbar sind. Weitere Vorteile sind Verbesserungen im Bereich Reporting, welcher das betriebliche Berichtswesen darstellt und das Gesamtsystem wird bei der Migration der Anwendungssysteme weniger belastet.

Allerdings sind bei dieser Option auch Nachteile vorhanden. Und zwar wird eine strikte Trennung zwischen den Anwendungssystemen und der Datenbasis vorausgesetzt, da diese Alternative nur auf Systemen mit einer definierten Schnittstelle zum Datenbackend anwendbar ist. Die Entwicklung des neuen Datenbanksystems bereits bevor alle Anforderungen bekannt sind, stellt einen weiteren Nachteil dieser Alternative dar.

Auch die Konzeption und Entwicklung des notwendigen Forward Gateways könnte sich als schwierig erweisen.

2.3.4 Database Last

Die zweite Alternative der Chicken Little Strategy ist die Database Last, welche das genaue Gegenteil zur Database First Alternative darstellt. Database Last ist auch unter dem Begriff Reverse Migration (dt. Rückwärts Migration) bekannt. Wie auch bei Database First ist hier eine definierte Schnittstelle zum Datenbank-Backend zur Durchführung notwendig. Bei dieser Alternative werden zunächst die „Anwendungssysteme vom Altsystem in die neue Lösung migriert“.^[21] Für den Zugriff der Anwendungen, sowohl des neuen als auch des alten Systems, auf die Daten muss ein Reserve Gateway entwickelt werden.

Erst im nächsten Schritt wird das neue Datenbanksystem entwickelt und die Daten aus dem alten System migriert. Danach kann der Reserve Gateway wieder deaktiviert werden.

Nichts desto trotz verfügt auch diese Alternative über Vor- und Nachteile.

Ein Vorteil ist, dass die Datenbank genau auf die Anforderungen der neuen Anwendungen abgestimmt werden kann. Dadurch sind allerdings im Vorfeld keine Testfälle der Anwendungen auf dem zukünftigen Datenbanksystem durchführbar.

Außerdem könnte sich ebenfalls wie bei der Database First Methode die Konzeption des Gateways als schwierig erweisen. Im Regelfall ist eine Leistungssteigerung im Bereich Datendurchsatz und Performance bei einer frühzeitigen Neuimplementierung des Datenbanksystems geboten, aus diesem Grund ist mit einer stärkeren Belastung der alten Datenbasis als bei der Database First Alternative zu rechnen. Die neuen Anwendungen könnten desweiteren höhere Anforderungen an die alte Datenbasis stellen.

2.3.5 Butterfly Methodology

Bei der Butterfly Methodology handelt es sich um den „Parallelbetrieb zweier separater Systeme“^[22] Es handelt sich hier somit um die parallele Strategie, bei der eine Zeit lang sowohl das Altsystem als auch das Neusystem ausgeführt wird.^[23] Dieser Parallelbetrieb findet solange statt, bis alle Beteiligten von der korrekten Funktion des Neusystems überzeugt sind. Die Butterfly Methodology ist der sicherste Migrationsansatz. Sollte nämlich ein Fehler oder eine Unterbrechung eintreten, so kann das alte System als Sicherung genutzt werden. Die Nachteile dieser Strategie sind vor allem die Mehrkosten, da zusätzliches Personal oder zusätzliche Ressourcen bei vorhandenen Angestellten notwendig sind. Außerdem müssen Daten doppelt erfasst werden und es könnte ein zusätzliches System oder ein zusätzlicher Server notwendig werden.

2.3.6 Composite Database

Außer der parallelen Strategie (Butterfly Methodology), dem direkten Umstieg (Cold Turkey Strategy) und dem phasenweisen Ansatz (Chicken Little Strategy) ist noch eine vierte Migrationsstrategie möglich. Bei dieser vierten Strategie, der Pilotstudienstrategie, wird das neue System nur in einem vorher definierten und begrenzten Bereich, wie z.B. innerhalb einer einzigen Abteilung, eingefügt.^[24] Diese Abteilung testet dann das neue System. Sobald alle Tests erfolgreich durchgeführt wurde, kann das neue System in den anderen Abteilungen bzw. in der restlichen Organisation des Unternehmens installiert werden. Dies geschieht nachdem eventuell aufgetretene Probleme und Fehler bereits beseitigt und erneut getestet würden. Die Migration in dem restlichen Unternehmen kann dabei entweder in einem Zug oder phasenweise erfolgen. Diese Strategie ist in der Literatur auch unter dem englischen Begriff Composite Database Approach vorzufinden und ist ein Vorfahr der Chicken Little Strategie.

Ob und welche Strategie für die Migration geeignet ist, hängt jeweils vom Grad der lokalen Gegebenheiten ab. Es gibt also demnach keine Anleitung zur Auswahl der richtigen Migrationsstrategie. Allerdings sind einige Empfehlungen bei unterschiedlichen Gegebenheiten vorhanden: sind z.B. wenige oder gar keine Änderungen am Datenschema des Altsystems notwendig, so ist die Entwicklung von Gateways relativ einfach, womit die Chicken Little Strategy empfohlen wird. Sind hingegen viele und grundlegende Änderungen des alten Datenschemas notwendig, wird die Big Bang Strategie empfohlen, da hier das Neusystem mit dem parallel laufenden Altsystem nicht kommunizieren muss.

Auf die ausgewählte Migrationsstrategie bei der Migration von xy® KiWi wird in Kapitel 4.1 dieser Bachelorarbeit eingegangen.

Bevor allerdings die geeignetste Migrationsstrategie definiert wird, sollten alle Aspekte für und gegen eine Migration betrachtet werden. Einer dieser Aspekte ist die Wirtschaftlichkeitsbetrachtung, denn eine Migration sollte idealerweise auch einen wirtschaftlichen Vorteil für das Unternehmen erzeugen.

2.4 Wirtschaftlichkeitsbetrachtung

Die Entscheidung für oder gegen eine Migration hängt häufig mit dem Ergebnis der Wirtschaftlichkeitsanalyse zusammen. Eine Migration sollte erst durchgeführt, wenn sich dadurch auch Vorteile für das Unternehmen ergeben. Die Wirtschaftsbetrachtung kann auf mehrere Arten erfolgen und beinhaltet unterschiedliche Kriterien. Nachfolgend soll in diesem Kapitel deshalb die Arten und die Kriterien der Wirtschaftlichkeitsanalyse vorgestellt werden.

2.4.1 Arten und Ziele

Wirtschaftlichkeitsbetrachtungen können auf zwei verschiedene Arten durchgeführt werden. Entweder fällt die Entscheidung auf die Ex-Ante- oder die Ex-Post-Analyse.

Die Begriffe „Ex-Ante“ und „Ex-Post“ kommen ursprünglich aus dem Lateinischen und bedeuten „vorher“ und „nachher“. Wie die Namen schon vermuten lassen, findet die Ex-Ante-Analyse vor und die Ex-Post-Analyse nach der Migration statt. Die Ex-Ante-Analyse wird meistens durchgeführt, um das Migrationsprojekt zu rechtfertigen oder um bessere Vertragskonditionen auszuhandeln.^[25] Die vorher getätigte Analyse findet in der Regel nach einer erfolgreichen Migration keinen Einsatz mehr in einem Unternehmen. Es wird allerdings empfohlen, regelmäßige Wirtschaftlichkeitsanalysen zur Identifizierung der Abweichungen von den geplanten Kosten und Nutzen durchzuführen.

Die Ex-Post-Analyse wird erst nach einer erfolgreichen Migration zum nachträglichen Nachweis eines positiven Beitrags oder zur Analyse der tatsächlich angefallenen Kosten und Nutzen durchgeführt.

Die Erstellung von Wirtschaftsanalysen ist nicht immer einfach. Häufig können nicht alle Kosten und Nutzen analysiert werden. Vor allem bei länger dauernden Projekten sind die Kosten z.B. auf Grund einer möglichen Inflation, und die Nutzen z.B. auf Grund der relativ raschen Veränderungen im IT-Sektor und der Weiterentwicklung bei der Konkurrenz, nur sehr schwer im Vorfeld zu definieren. Nutzen, die nichts mit Kosteneinsparungen zu tun haben und in keiner Weise verbucht werden können, werden oft bei der Wirtschaftlichkeitsanalyse nicht weiter berücksichtigt. Diese Auslassung relevanter Nutzen führt zwangsweise oft zu einem negativen Ergebnis der Wirtschaftsanalyse. Ein weiterer Nachteil der Nicht-Beachtung aller Nutzen ist die Überbewertung der anfallenden Kosten. Somit könnten wichtige Migrationsprojekte nicht genehmigt und dadurch nicht durchgeführt werden. Ein Projekt ist dann wirtschaftlich, wenn dessen Kosten möglichst niedrig, die Leistung und das Ergebnis allerdings möglichst hoch sind.^[26] Meistens ist von der Effizienz eines Projektes die Rede. Darunter ist nichts anderes als die Wirtschaftlichkeit eines Projektes gemeint. Unter Effizienz und somit auch unter der Wirtschaftlichkeit wird die „Verbesserung wertmäßiger Input-/Output-Verhältnisse (Kosten zu Leistung) durch Einsatz des Produktionsfaktors Information“^[27] verstanden.

2.4.2 Kriterien

Wenn die Rede von „Wirtschaftlichkeit“ ist, dann ist hiermit meistens der Nutzen von etwas gemeint. Dabei kann der Nutzen aus mehreren Aspekten betrachtet werden. Mit dem Begriff „Kriterien“ werden sowohl die Pro- als auch die Kontra-Aspekte einer bestimmten Thematik betrachtet. Bei Wirtschaftlichkeitsbetrachtung in der IT sind die wirtschaftlichen, technischen und qualitativ-strategischen Kriterien einer Migration relevant, welche in Tabelle 1 jeweils zu sehen sind.

Zu den wirtschaftlichen Kriterien gehören zum Einen die Software-Kosten, womit die Aufwendungen für die Betriebssystem- und die Anwendungs-Software gemeint sind, zum Anderen die Hardware-Kosten, worunter die „Aufwendungen zur Erweiterung der Hardware oder zur Neuanschaffung von Komponenten“^[28] fallen. Zum Beispiel können durch die Migration teure Hochleistungsserver abgelöst werden, was zu Kosten-einsparungen führt. Ein weiteres wirtschaftliches Kriterium ist die Mitarbeiterschulung, in der die Neuerungen den Mitarbeitern näher gebracht werden. Da Migrationsprojekte häufig einen größeren Eingriff in die bestehende IT-Architektur bedeuten, müssen Migrationsprojekte sorgfältig geplant werden. Die Migrationsplanung zählt ebenfalls zu den wirtschaftlichen Kriterien der Wirtschaftlichkeitsanalyse. Weitere Kriterien sind die Systemeinführung, der Support und die Administration. Vor allem bei einer weichen Migration, wie es bei den ersten xy® KiWi-Migrationen der Fall war, war der Administrationsaufwand sehr hoch, da hier eine Zeit lang ein Probebetrieb des neuen Systems neben dem Echtbetrieb des alten Systems bestand.

Unter die technischen Kriterien fallen die Hardware- und Software-Abhängigkeit, die Systemstabilität und die Systemperformance, sowie die Sicherheit und die Benutzerfreundlichkeit des Systems. Unter anderem ist die Überprüfung der einzelnen Schnittstellen in dieser Art der Kriterien eingegliedert. Die Wirtschaftlichkeits-betrachtung beinhaltet auch die Prüfung der Systemstabilität, da die Ausfallzeit eines Systems ein wichtiges Kriterium zur Entscheidungsfällung darstellt. Selbstverständlich sollten die Sicherheit und die Benutzerfreundlichkeit des Neusystems nicht schlechter als die des Altsystems sein. Dieser Aspekt wird ebenfalls bei der Prüfung der Wirtschaftlichkeit des Neusystems betrachtet.

Zu den qualitativ-strategischen Kriterien der Wirtschaftlichkeitsprüfung zählt unter anderem die Unabhängigkeit von den proprietären Software-Anbietern, d.h. ob Updates nur bei einem Anbieter vorhanden sind. Desweiteren sollte ein angemessener Support des Neusystems zur Verfügung stehen. Zum Beispiel ist eine Unterstützung bei der Integration und der Pflege des Neusystems ein wesentlicher Punkt, der zu einer positiven Wirtschaftlichkeitsanalyse beiträgt.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Erstellung

Tabelle 1: Kriterien der Wirtschaftlichkeitsbetrachtung

2.4.3 Entscheidungsfällung

Die Wirtschaftlichkeitsanalyse von Investitionsprojekten stellt in ihrer Grundform eine Kosten-Nutzen-Analyse dar. Dabei sollen idealerweise die Nutzen die Kosten überwiegen, oder sich zumindest die Waagschale halten. Ist dies der Fall, so ist die Analyse positiv und das Projekt somit wirtschaftlich. Auf die Kosten-Nutzen-Analyse des Migrationsprojekts der xy wird im dritten Kapitel dieser Bachelorarbeit näher eingegangen.

Bei der Entscheidungsfällung für oder gegen die Durchführung eines Migrationsprojektes kann die Betrachtung folgender Thematiken hilfreich sein^[29]:

- Skalierbarkeit der Migration

Je größer die Anzahl der Client-Installationen, desto höher sind in der Regel auch die Kostenvorteile. Allerdings ist auch der Initialaufwand für die Planung und Durchführung der Migration umso höher, je höher die Benutzeranzahl ist. Somit kann die Wirtschaftlichkeit durch die Anzahl der Lizenzen beeinflusst werden.

- Dringlichkeit der Migration

Hat die Migration eine hohe Dringlichkeit, so fällt die Entscheidung in der Praxis oft, trotz einer nicht ausreichenden Wirtschaftlichkeit des Projektes, für ein Migrationsprojekt.

- Strategische Bedeutung der Migration

Sollte die Migration ein strategisch wichtiges Vorhaben abdecken, wie z.B. die Schaffung von Wettbewerbsvorteilen, dann kann ebenfalls wie bei der Thematik der Dringlichkeit, die Migration trotz einer negativ ausgefallenen Wirtschaftlichkeitsanalyse gerechtfertigt sein.

- Art der Migration

Die Strategie der Migration hat im Regelfall eher wenig Einfluss auf die Entscheidung. Allerdings müssen die Vor- und Nachteile der gewählten Migrationsstrategie analysiert werden. Sollte sich herausstellen, dass unumgängliche Schwierigkeiten bei der gewählten Strategie zu bewältigen sind, so kann diese Thematik durchaus Einfluss auf die Entscheidung haben.

- Teilbarkeit der Migration

Im Falle einer Aufteilung der Migration in Teilschritte können erste Erfolge in den Teilmigrationen die Unterstützung des Projektes „durch die Unternehmensführung bekräftigen und unter Umständen für die Gewährleitung zusätzlicher finanzieller oder personeller Ressourcen sorgen“^[30].

Vor der endgültigen Entscheidung zur Durchführung einer Migration müssen außer der Wirtschaftlichkeit auch die möglichen Risiken analysiert werden. Denn alleine durch eine positiv ausgefallene Wirtschaftlichkeitsbetrachtung sollte noch keine Entscheidung für eine Migration gefällt werden. Denn sollten die Risiken bei der geplanten Migration zu hoch sein oder in einer großen Menge vorliegen, kann die Entscheidung durchaus noch gegen eine Migration erfolgen.

[...]

^[1] Vgl. Kröhnert (2010)

^[2] Vgl. Lesch (2010), S. 574

^[3] Vgl. CompuGroup Medical (2010)

^[4] Vgl. DHBW-Ravensburg (2009)

^[5] Vgl. Thome (2009), S. 1

^[6] Vgl. Heinrich, Lehner (2005), S. 531

^[7] Vgl. Thome (2009), S. 2

^[8] Vgl. Hildebrand (2007), S. 117

^[9] Vgl. Disterer, Bechte (2003), S. 282

^[10] Vgl. nachfolgend Merker, Merker (2006)

^[11] Vgl. nachfolgend Heinrich (1997), S. 8 f.

^[12] Vgl. Kaiser, Kroha, Winter (2006)

^[13] Ebd.

^[14] Vgl. manager magazin Online (2009)

^[15] Vgl. nachfolgend Thome (2009), S. 2f.

^[16] Vgl. Thome (2009), S.4

^[17] Vgl. Thome (2009), S. 12

^[18] Vgl. Liebhart (2007), S. 183

^[19] Vgl. Kirk (2000)

^[20] Vgl. Thome (2009), S. 10

^[21] Vgl. Thome (2009), S. 11

^[22] Vgl. Liebhart (2007), S. 239

^[23] Vgl. Laudon, Laudon, Schoder (2006), S. 569

^[24] Ebd.

^[25] Vgl. Amberg, Markov (2009)

^[26] Vgl. Disterer, Fels, Hausotter (2003), S. 109

^[27] Ebd., S. 327

^[28] Vgl. Amberg, Markov (2009), S. 3 f.

^[29] Vgl. nachfolgend Amberg, Markov (2009), S. 6 f.

^[30] Vgl. Amberg, Markov (2009), S. 7