Irgend etwas geht seinen Gang.

Endspiel

Samuel Beckett Footnote 1

FormalPara Zusammenfassung

Wir sehen uns den Lebenszyklus einer Systemlandschaft und darin insbesondere den eines Anwendungssystems im Unternehmen an. In den Folgekapiteln vertiefen wir zwei der Phasen: die Anpassung von Standardsoftware und die Administration eines Anwendungssystems. Gemäß der Perspektive des Buchs, nämlich der eines Unternehmens, welches Unternehmenssoftware einsetzt, beginnt unser Lebenszyklus nach der „Geburt“, d. h. der Entwicklung und Auslieferung des Anwendungssystems durch den Softwareanbieter. Die Entwicklung von Unternehmenssoftware ist somit nicht im Fokus, einige Aspekte finden sich jedoch im Teil „Eigenentwicklung“ des Kapitels über Anpassung. Beispiele sind die SAP Legacy System Migration Workbench und SAP Enhancement Packages.

FormalPara Lernziele

Einen Überblick über den Lebenszyklus von Anwendungssystemen und Systemlandschaften gewinnen.

Nachdem heute Unternehmen nicht mehr wie früher überwiegend eigenentwickelte Programme einsetzen sondern Standardsoftware, könnte man den hier vorgestellten Lebenszyklus von Unternehmenssoftware als das Phasenmodell des „Software-Engineering der Wirtschaftsinformatik“ ansehen: statt auf Neuentwicklung liegt der Fokus auf Konfiguration und Anpassung der Software, wobei auch darin Softwareentwicklung im Rahmen von Zusatzentwicklung und Erweiterung ihren Platz hat. Aus Sicht eines Unternehmens, welches die Software einsetzt, stellt sich der Lebenszyklus eines Anwendungssystems und allgemeiner einer Systemlandschaft gemäß Abb. 13.1 dar. Hier berührt die Thematik dieses Buches das Informationsmanagement. Wir konzentrieren uns wiederum auf die technologischen Aspekte.

Abb. 13.1
figure 1

Lebenszyklus

Full size image

1 Planung

Zunächst sind die Systemlandschaft und die darin enthaltenen Anwendungssysteme zu planen. Typische Fragen sind hierbei:

  • Welche Teile der bestehenden Systemlandschaft sollen durch ein oder mehrere neue Anwendungssysteme ersetzt werden? Im Folgenden nehmen wir an, dass es sich nur um eines handelt.

  • Welche Anforderungen hinsichtlich Funktionalität und Integrierbarkeit mit der bestehenden Systemlandschaft hat das Anwendungssystem zu erfüllen?

  • In welcher zeitlichen Abfolge sollen Teile der Systemlandschaft ersetzt werden?

2 Auswahl und Kauf

Nach der Planung nimmt das Unternehmen zu den Softwareanbietern Kontakt auf und prüft, welche Anwendungssysteme die Anforderungen am besten erfüllen. Dabei spielen auch finanzielle und strategische Fragen eine Rolle.

  • Es kann sein, dass ein teures Produkt die Anforderungen besser erfüllt, wegen des großen Preisunterschieds greift man aber lieber zum hinsichtlich der Funktionalität zweitbesten Produkt.

  • Unter der berechtigten Erwartung, dass sich Produkte desselben Softwareanbieters leichter miteinander integrieren lassen, kann die Unternehmensstrategie sein, sich auf nur wenige Anbieter zu konzentrieren und diese möglichst zu wählen. Nach der Strategie Best of Suite wird der Anbieter ausgewählt, dessen Produkte insgesamt im Zusammenwirken für das Unternehmen am besten geeignet sind, selbst wenn andere Anbieter bei einzelnen Produkten vorteilhafter sind. Bei Best of Breed wird für jede Komponente das beste Produkt gewählt.

  • Nicht nur die Kosten für den Softwarekauf sind zu berücksichtigen, sondern die für den ganzen Lebenszyklus. Dies sind insbesondere die Einführungskosten, bestimmt durch die Anpassung des Systems an die Unternehmensbedürfnisse. Daneben eine Vielzahl von Kosten, wie für Personal, Wartung, Energie und Kühlung der Hardware. Man nennt diese Gesamtkosten im Jargon Total Cost of Ownership (TCO) .

  • Berücksichtigt werden sollte auch das Projektrisiko: wird das System bei anderen hinsichtlich Größe und Branche ähnlichen Unternehmen bereits eingesetzt, und was sind Erfahrungswerte hinsichtlich der Kosten?

Mit dem Kauf der Software sind einmalige Lizenzkosten verbunden. Dafür gibt es verschiedene Preismodelle. Ein gängiges basiert auf der Anzahl der Benutzer, welche das System verwenden (Named Users). Bei diesem Modell kommt es tatsächlich auf die Anzahl der Personen an, nicht auf die Anzahl der Benutzerkennungen. So könnte eine Person mehrere Benutzer für Testzwecke haben. Preisunterschiede kann es für verschiedene Benutzerkategorien geben (z. B. Entwickler oder Sachbearbeiter). Ein anderes Modell bezieht sich auf die Anzahl der Benutzer, welche gleichzeitig im System arbeiten können (Concurrent Users). Schließlich sind auch lastabhängige Preise möglich, etwa nach der Anzahl der Personalstammsätze oder nach dem Bewegungsdatenaufkommen (Lehmann und Buxmann 2009). Daneben fallen regelmäßige Wartungskosten an, die an den Softwareanbieter zu bezahlen sind. Sie liegen oftmals pro Jahr in der Größenordnung von 20 % der Lizenzkosten.

Eine Alternative für den Kauf, insbesondere für kleinere oder mittelgroße Unternehmen, ist es, das Anwendungssystem vom Softwareanbieter oder einem anderen Unternehmen betreiben zu lassen und nur für die Nutzung der Software zu bezahlen. Heute firmiert dies unter dem Begriff Software as a Service (SaaS), früher nannte man es Application Service Providing (ASP) (siehe Abschn. 6.5.2).

3 Installation

Die Installation eines großen Anwendungssystems ist oftmals nicht so problemlos wie die Installation eines kleinen PC-Programms. Insbesondere liegen Installationsmenge und -dauer Größenordnungen darüber.

4 Einführung

Es schließt sich der aufwändigste Teil an: die Einführung der Software im Unternehmen, organisiert in einem Einführungsprojekt . Wir konzentrieren uns auf drei Aktivitäten:

  • Anpassung

  • Altdatenübernahme

  • Integration

5 Anpassung

Wir gehen davon aus, dass es sich bei dem Anwendungssystem um Standardsoftware handelt. Entsprechend nimmt die Anpassung einen großen Raum ein. Sie kann Monate bis Jahre dauern, je nachdem, wie weit die Funktionalität der Standardsoftware und die Unternehmensanforderungen auseinander liegen. Dies ist das Thema von Kap. 14.

6 Altdatenübernahme

Der Anlass für ein neues Anwendungssystem ist selten die Firmengründung, vielmehr wird es meist ein Vorgängersystem ablösen. Zumindest Teile der vorhandenen Daten müssen daher im neuen System übernommen werden. Zu überlegen ist, welche Stammdaten und insbesondere welche Bewegungsdaten zu migrieren sind, z. B. nur die Salden, die Einzelposten oder auch ausgeglichene Posten (Willinger und Gradl 2007, S. 26). Dabei wird klar, dass die Altdatenübernahme nicht eine rein technische Angelegenheit ist, sondern betriebswirtschaftliche Überlegungen einschließt, z. B. buchhalterische bei offenen Posten hinsichtlich der Gegenbuchung (Willinger und Gradl 2007, S. 29 ff.) oder die Frage der Reihenfolge der Datenübernahme, z. B. Stamm- vor Bewegungsdaten, Bestellungen vor Wareneingangsbuchungen (Willinger und Gradl 2007, S. 42).

Die Altdatenübernahme, auch Datenmigration genannt, ist ein spezieller Aspekt der Integration über Datenaustausch, die prinzipiellen Techniken kommen zum Einsatz (vgl. Kap. 9). Traditionell wird die Altdatenübernahme von Programmierern durchgeführt, was ein Engpass bei einem Einführungsprojekt sein kann, denn Programmierer werden übergreifend für verschiedene Aufgaben und Funktionsbereiche benötigt. Doch haben sich spezialisierte Werkzeuge gebildet, welche insbesondere Techniken aufgreifen, die Programmierung vermeiden bzw. nur an wenigen Stellen erforderlich machen, so dass die Aufgabe teilweise auch von anderen Mitarbeitern übernommen werden kann.

6.1 Beispiel: SAP Legacy System Migration Workbench

Die SAP Legacy System Migration Workbench (Willinger und Gradl 2007) bietet einen einheitlichen Zugang zu mehreren Verfahren der Datenmigration und eine Benutzerführung. Die unterstützten Datenmigrationsverfahren sind Batch-Input (siehe Abschn. 9.4), Direct-Input (Standardprogramme zur Datenübernahme, welche jedoch nicht wie Batch-Input eine Eingabe über die Benutzeroberfläche simulieren, sondern recht direkt in die Datenbank mit weniger Prüflogik schreiben (Willinger und Gradl 2007, S. 51)Footnote 2, BAPI (siehe Abschn. 10.6) und Intermediate Document (IDoc; siehe Abschn. 9.4). Ein besonderer Vorteil dieses Werkzeugs gegenüber der direkten Verwendung der unterstützten Datenmigrationsverfahren sind Methoden der Datenkonvertierung und Flexibilität, z. B. indem eigener ABAP-Code hinzugefügt werden kann. Der Einsatz der Legacy System Migration Workbench ist daher besonders dann sinnvoll, wenn die Quell- und Zieldatenstrukturen stark voneinander abweichen. Entsprechend der umfangreichen Funktionalität und Komplexität ist ein gewisser Einarbeitungsaufwand zu veranschlagen.

7 Integration

Integration umfasst die vielfältigen Konfigurations- und Entwicklungstätigkeiten, die für die Einrichtung einer Systemlandschaft erforderlich sind und die wir in den Kapiteln über Integration kennengelernt haben. Kommt Standardsoftware aus der Hand eines Softwareanbieters zum Einsatz, sind viele Integrationsmöglichkeiten bereits im Customizing der zu integrierenden Systeme vorgesehen. In manchen Fällen ist jedoch Entwicklungsaufwand nötig.

8 In Betrieb nehmen

Nach Anpassung, Tests und Schulung der Anwender kann die Software in Betrieb genommen werden, man nennt dies Go live. Im laufenden Betrieb gibt es weitere administrative Tätigkeiten, insbesondere:

  • Benutzerverwaltung: Im Anwendungssystem müssen Benutzer angelegt werden, welche die passenden Berechtigungen benötigen.

  • Systemüberwachung: Das System muss überwacht werden, denn die Leistung kann nachlassen und Systemteile können ausfallen.

  • Problembearbeitung: Im laufenden Betrieb können sich Probleme ergeben, welche sich nicht durch die Systemkonfiguration lösen lassen, sondern Softwarefehler als Ursache haben. Die Hauptaufgabe ist hierbei dafür zu sorgen, dass die Softwarekorrekturen ins System gelangen.

9 Änderungsmanagement

Im Laufe der Zeit können sich auf Unternehmensseite zusätzliche Anforderungen an die Software ergeben, welche zu berücksichtigen sind. Im IT-Jargon wird dieses Änderungsmanagement auch Change Management genannt. Oft lässt es sich durch weitere Anpassungen, inklusive Erweiterungen, erledigen.

Auch der Übergang zu einer neuen Version der Software ist möglich, Releasewechsel oder Upgrade genannt – eine Rückkopplung zur Phase „Planung“. Ein Releasewechsel ist besonders sinnvoll, wenn die neue Version benötigte Funktionalität bietet, vielleicht auch solche, die manche Eigenentwicklung nun überflüssig macht (Rückführung in den Standard). Ebenso kann ein Wechsel zu einer qualitativ besseren, stabileren Version hilfreich sein. Gerade neu erstellte Software („First Customer Shipment“) hat Kinderkrankheiten, welche in späteren Versionen hoffentlich behoben sind. Der Aufwand für einen Releasewechsel ist nicht zu unterschätzen, gerade wenn das System Modifikationen enthält.

Zum Leidwesen mancher Unternehmen ist ein Releasewechsel auch aus organisatorischen Gründen erforderlich, selbst wenn die neue Version für das Unternehmen keinen zusätzlichen größeren Nutzwert bringt, nämlich dann, wenn die Wartungsphase für eine Softwareversion abläuft. Zumindest kann die Wartung durch den Softwareanbieter oder ein dafür spezialisiertes Unternehmen teurer werden. Ein weiterer Grund kann sein, dass der Softwareanbieter möglichst viele Unternehmen auf die neue Version bringen möchte, um seinen Wartungsaufwand zu verringern oder die Verkaufszahlen für die neue Version zu verbessern, und den Wechsel daher schmackhaft macht.

Eine ausführliche Schilderung des Releasewechsels am Beispiel Microsoft Dynamics NAV findet sich in Hesseler und Görtz (2008, S. 365 ff.).

9.1 Beispiel: SAP Enhancement Packages

Ein Releasewechsel bringt viel neue Funktionalität auf einen Schlag, oft mehr als ein Unternehmen zu einem Zeitpunkt einführen möchte, und verursacht meist hohen Aufwand. Die Idee von SAP Enhancement Packages (Kaplan und Oehler 2011) ist dagegen, aufbauend auf einem Basisrelease, wie SAP ERP 6.0, schrittweise weitere Funktionen zu installieren und zu aktivieren. Ein Enhancement Package enthält Funktionen („Business Functions“), die getrennt voneinander aktiviert werden können. Enhancement Packages waren zunächst für SAP ERP verfügbar und sind es nun auch für andere Produkte der SAP Business Suite.

Technische Inhalte eines Enhancement Packages sind insbesondere Programmcode, Benutzeroberflächenelemente, Tabelleneinträge und Append-Strukturen von Datenbanktabellen. Erst nach der Aktivierung zeigen sie tatsächlich Wirkung, z. B. können dadurch neue Felder auf den Benutzeroberflächen erscheinen oder neuer Programmcode verfügbar sein. Nicht aktivierter Programmcode wird bei der Kompilierung nicht berücksichtigt, so dass das Enhancement Package weder funktional noch performanzmäßig einen Unterschied ausmacht (Kaplan und Oehler 2011, S. 37). Das Aktivieren bzw. „Umschalten“ geschieht durch Schalter des „Switch-Frameworks“.

Für ein Basisrelease gibt es im Zeitablauf verschiedene Enhancement Packages, die kumulativ sind, d. h. aufeinander aufbauen. Administrativ lassen sich Enhancement Packages wie Support Packages (vgl. Abschn. 15.3) regelmäßig installieren, aber erst bei Bedarf aktiveren.

Zwischen Enhancement Packages verschiedener Komponenten können Abhängigkeiten bestehen, z. B. könnte ein Enhancement Package für SAP ERP von einem für SAP NetWeaver abhängen. Die Softwarewerkzeuge zur Behandlung von Enhancement Packages erkennen solche Abhängigkeiten.

Die Wartung der Enhancement Packages geschieht mit eigenen Support-Packages (siehe Abschn. 15.3), getrennt von den Support-Packages des Basisrelease.

Der Ursprung der Enhancement Packages kam von der Idee, Branchenlösungen zu SAP ERP, z. B. für die Automobilbranche, nicht weiter als getrennte Systeme verfügbar zu machen, sondern als Erweiterungen zu SAP ERP. Heute gibt es branchenspezifische („Industry Extension“) und branchenübergreifende Funktionen („Enterprise Extension“), die aktiviert werden können.

10 Literatur

Hesseler M, Görtz M (2008) Basiswissen ERP-Systeme. 1. korrigierter Nachdruck, W3 L, Herdecke, Witten

Kaplan M, Oehler C (2011) SAP Enhancement Packages – Funktionsweise und Implementierung. 2. Auflage, Galileo Press, Bonn

Lehmann S, Buxmann P (2009) Preisstrategien von Software-Anbietern. Wirtschaftsinformatik, Vol. 51, Nr. 6, S. 519–529

Willinger M, Gradl J (2007) Datenmigration in SAP. 2. Auflage, Galileo Press, Bonn