Standardsoftware oder Eigenentwicklung? (Teil 1)

Der Lizenzpreis sagt kaum etwas über den Aufwand aus

14.02.1992

Die Installation einer Standardsoftware kostet oft ein Vielfaches der Lizenzgebühr. Um eine Entscheidung zwischen Eigenentwicklung und Standardsoftware treffen zu können, ist es notwendig, den tatsächlichen Aufwand über alle Phasen eines Projektes zu untersuchen. Das hat Robert Hürten* getan, und hier sind die Ergebnisse.

Auf einem Seminar zum Thema Standardsoftware berichteten zwei Teilnehmer aus vergleichbaren Unternehmen über genau entgegengesetzen Erfahrung mit demselben Finanzbuchhaltungs-System. Das eine Unternehmen hatte, so der erste Seminarteilnehmer, nach einer intensiven Phase der Entscheidungsfindung bei der Einführung des Produktes keine Probleme gehabt; zwischen der Kaufentscheidung und dem Echtlauf der Buchhaltung habe kein Halbes Jahr gelegen.

Im Unternehmen, dem der andere Teilnehmer angehört, war das Produkt ein Jahr nach der Kaufentscheidung immer noch nicht einsatzfähig. Einem Berater, der engagiert worden war, um die Einführung zu unterstützen, wurde nach zwölf Monaten gekündigt, weshalb das Unternehmen nach diesem Jahr wieder am Anfang der Planung stand. Im folgenden soll die Frage geklärt werden, welche Faktoren dafür verantwortlich sind, ob Standardsoftware wirtschaftlich sinnvoll eingesetzt werden kann.

Die Pläne zur Entwicklung standardisierter Anwendersoftware wurde Ende der 60er Jahre von der damaligen Bundesregierung aufgegriffen und mit beachtlichen Mitteln gefördert. Das volkswirtschaftliche Ziel hieß: mehrfache Programmierung von solchen Aufgaben vermeiden, die bei allen Anwendern oder großen Anwendergruppen gleichermaßen auftraten. Die betriebswirtschaftlichen Vorteile sollten sich durch die schnelle Verfügbarkeit von guten Softwarelösungen und die damit verbundene Einbringung von Fach- und DV-Wissen bei den Unternehmen - automatisch ergeben. Im Bereich der Mittleren Datentechnik (MDT) und der Bürocomputer sind diese Ziele auch fast überall erreicht worden.

Anders verlief die Entwicklung bei den Anwendern von Großanlagen. Der Durchbruch für den Einsatz von Standardsoftware kam erst in der Mitte der 80er Jahre. Dabei ist anzumerken, daß der Aufwand für die Einführung der Standardsoftware bei den Großanwendern erheblich höher ist als bei den Anwendern von PCs und Bürosystemen. Für Klein- und Mittelbetriebe bietet sich keine Alternative zur Standardsoftware, denn in den meisten Fällen fehlen Geld und Know-how, um eigene Software zu erstellen oder Fremdsoftware zu modifizieren.

Im Bereich der Groß-DV steht die Standardsoftware im Wettbewerb mit der Eigenentwicklung. Das Wesentliche bei der Eigenentwicklung ist, daß bei ihr die firmenspezifischen Anforderungen an die Softwarelösung in der Regel nur durch technische Grenzen limitiert wurden. Diese Grenzen sind heute jedoch so weit gesteckt, daß sich auch die extremsten Anforderungen erfüllen lassen.

Die jahrzehntelange Erfahrung der Software-Entwickler, daß alle ihre Vorstellungen "machbar" waren, verleitet sie dazu, auch Standardsoftware an "unbedingt notwendige Firmenanforderungen" anzupassen selbst dann, wenn diese aus betriebswirtschaftlicher Sicht nicht zwingend sind. In diesen Fällen wird die Standardsoftware allzu schnell "zerändert", so daß das ursprüngliche angestrebte Ziel - billiger, schneller verfügbar, personenunabhängig - nicht mehr erreicht werden kann.

Bei den eingangs genannten Beispielen lag der Erfolg der schnellen Einführung der Standardsoftware bei der Firma A in der Entscheidung: "Wir passen unsere Organisation an die ausgewählte Software an; die Standardsoftware darf nicht geändert werden." Die Firma B entschied sich für das Gegenteil: "Die Software ist an unser vorhandenes System anzupassen." Diese Entscheidung führte zu der beschriebenen Katastrophe.

Der für den Anwender einer Standardsoftware optimale Weg liegt irgendwo zwischen diesen beiden konträren Forderungen. Möglicherweise gibt es neben Eigenentwicklung und Standardsoftware noch andere sinnvolle Lösungen. Allerdings werden alle diese Wege schnell zu Gratwanderungen zwischen Erfolg und Mißerfolg.

Der Aufwand von Eigenentwicklung und Standardsoftware verläuft in den einzelnen Projektphasen nicht parallel. Um dies zu belegen, untersuchen wir ein typisches Projekt, das wir nach dem von Siemens stammenden Modell in sechs Phasen unterteilen:

1. Projektvorschlag

- Bearbeitung Projektantrag

- Erstellung einer ersten Wirtschaftlichhkeitsberechnung

- Festlegung Projekt- und Phasenorganisation

2. Planungsphase 1

- Erstellung des Idealkonzepts

- Ist-Aufnahme und Analyse

- Fachliches Grobkonzept

3. Planungsphase 2

- Fachliches Feinkonzept

- DV-Grobkonzept

- Abstimmung der Leistungsbeschreibung

- Testplan

4. Realisierungsphase 1

- DV-Feinkonzept

- Softwareanpassung

- Programmierung

- Stammdatenübernahme

- Test

5. Realisierungsphase 2

- Einweisung Anwender- und RZ-Personal

- Organisationsanspassung

- Probebetrieb/Systemtest

- Übergabe/Abnahme

6. Einsatzphase

- Produktiveinsatz

- Softwarepflege

- Erfolgskontrolle des DV-Projektes

Tabelle 1 zeigt, wie sich der Aufwand über die einzelnen Phasen verteilt. Die ausgewiesenen Prozent-Sätze entsprechen den heute allgemein in der Literatur genannten Sätzen; sie werden nicht in jedem Fall mit der aktuellen Situation eines DV-Anwenders übereinstimmen.

In der ersten Phase parallel

Auch bei dem Einsatz von Standardsoftware werden wie bei einer Eigenentwicklung - die einzelnen Schritte der ersten Phase durchgeführt werden müssen. Will man in diesem Stadium des Projektes bereits entscheiden, daß eine Standardsoftware eingesetzt werden soll, so muß eine Schätzung für eine eventuelle Eigenentwicklung und die Ermittlung eines durchschnittlichen Kaufpreises für die Standardsoftware vorliegen. Der Einsatz einer Standardsoftware wird also in der ersten Phase keine Einsparung gegenüber einer Eigenentwicklung bringen.

In der Planungsphase 1 - der zweiten Entwicklungsphase -müssen die Angebote für eine Standardsoftware eingeholt werden.

Dies kann nach zwei verschiedenen Methoden erfolgen: Zum einen kann der Anwender ein fachliches Grobkonzept erstellen, wie er es bei einer Eigenentwicklung täte, und damit Softwarehäuser zu einem Angebot auffordern. Die eingehenden Angebote vergleicht er später mit seiner Ausschreibung, um das Softwareprodukt zu finden, das seiner Ausschreibung am nächsten kommt.

Zum anderen kann der Anwender die Softwarehäuser anschreiben, von denen er vermutet, daß sie eine für ihn zutreffende Software anbieten können. Auch in diesem Fall muß er die eingehenden Angebote mit seinen Vorstellungen abgleichen, damit er zu einer Entscheidung für ein bestimmtes Produkt kommen kann. In beiden Fällen wird der Aufwand für die Planungsphase 1 mindestens genau so groß sein wie bei einer Eigenentwicklung - bei einer sorgfältigen Produktauswahl sogar noch größer als bei der Eigenentwicklung.

Anpassung in einem vorgesehenen Rahmen

Bei der Planungsphase 2 hingegen kann eine Einsparung erreicht werden, sofern der Anwender sich entschließt, das ausgesuchte Produkt unverändert einzusetzen. In diesem Fall geht der Aufwand auf Null zurück.

Die meisten Softwareprodukte bieten heute eine Flexibilität, die es erlaubt, in einem vorgesehenen Rahmen Anpassungen vorzunehmen. Ein typisches Beispiel ist dafür die Länge von Ordnungsbegriffen, zum Beispiel Kontonummern, oder die Zuordnung von Größen wie beispielsweise Fibu-Konten zu Bilanzpositionen.

Derartige Anpassungen werden in der Regel keinen großen zusätzlichen Aufwand verlangen. Den Preis für diese Flexibilität zahlt der Anwender durch einen erhöhten Hardwarebedarf.

Werden dagegen Funktionen oder Änderungen verlangt, die nicht vom Anbieter vorgesehen waren, so hat jetzt in dieser Phase die organisatorische und DV-mäßige Planung zu beginnen.

Der Aufwand wächst überproportional

Da in der Standardsoftware feste Rahmen realisiert sind, werden diese Planung und die folgenden Arbeiten aufwendiger sein, als wenn diese in einer Eigenentwicklung hätten realisiert werden müssen: Es muß nicht nur die gewünschte zusätzliche Aufgabe, sondern auch das im Standard vorgegebene Umfeld definiert und analysiert werden.

Der Aufwand für Programmänderungen beziehungsweise -ergänzungen wächst überproportional mit der Aufgabe. Wenn zum Beispiel 50 Prozent des vorhandenen Standardprogrammes geändert werden sollen, so kann der Aufwand bereits 100 Prozent der Eigenentwicklung betragen.

Die Gefahr, den Änderungsaufwand zu unterschätzen ist immer dann vorhanden, wenn vor dem Kauf der Standardsoftware - spätestens in der Planungsphase 1 - kein Abgleich zwischen dem Anforderungsprofil des Anwenders einerseits und dem Angebotsprofil des zu ändernden Produktes andererseits gemacht wurde.

Für den Aufwand, der in der Realisierungsphase 1 für das DV-Feinkonzept und die Programmierung zu erbringen ist, gilt dasselbe, was bereits zur Planungsphase 2 gesagt wurde: Änderungen in bestehende Programmstrukturen und -Codes einzubauen, ist erheblich aufwendiger und - im Hinblick auf die Fehlerwahrscheinlichkeit - ungünstiger, als ein neues Programm zu schreiben.

Dies läßt sich daher erklären, daß der Hersteller der Standardsoftware sicherlich mit einer anderen Methodik arbeitet als der Anwender. Der Aufwand hängt letztlich auch davon ab, welche Dokumentation der Hersteller der Standardsoftware dem Anwender für die Programmänderungen zur Verfügung stellt.

Zu beachten ist außerdem, daß bei Änderungen auch der Aufwand für das DV-Feinkonzept sowie für die Codierung überproportional zum Umfang der Aufgabe steigen wird. Dasselbe gilt für die Programm-Einzeltests. An Stelle des Systemtests wird beim Einsatz der Standardsoftware der Abnahmetest stehen. Der Aufwand für diese Tests dürfte im Normalfall gleich groß sein. Die Standardsoftware bringt hier keine Ersparnisse.

Entweder die Software oder die Organisation

In der Realisierungsphase 2 wird der Aufwand für die Einweisung der Fachabteilung und des RZ-Personals bei einer unveränderten Standardsoftware wahrscheinlich größer sein als bei einer Eigenentwicklung. Dies resultiert daraus, daß die neue Software nicht das vorhandene Umfeld berücksichtigt. Wenn die Programme nicht angepaßt werden, muß eben das Umfeld, also die Organisation des Unternehmens, angepaßt werden.

Wurden starke Anpassungsänderungen in der Software vorgenommen, so kann der Aufwand für die Realisierungsphase 2 genau so hoch sein wie bei einer Eigenentwicklung. Auf keinen Fall wird er jedoch geringer sein.

Vor allem die Kosten für die Softwarepflege sind in der Einsatzphase zu betrachten. Bei unveränderter Standardsoftware wird dieser Aufwand im Rahmen eines Pflegevertrages geleistet. Mit den Kosten für einen solchen Vertrag, die im Durchschnitt bei 15 Prozent des Produktpreises liegen, läßt sich fest kalkulieren.

Ob diese Kosten gerechtfertigt sind, soll hier nicht geprüft werden. Geprüft werden muß hingegen, welche Leistungen im Rahmen des Vertrages erbracht werden. In vielen Fällen kann ein Pflegevertrag Nachteile für den Anwender mit sich bringen. Das ist beispielsweise dann der Fall, wenn der Kunde gezwungen ist, alle Release-Änderungen mitzumachen, ob sie ihm nun einen Vorteil bringen oder nicht. Individuelle Wünsche sind in keinem Pflegevertrag abgedeckt. Solche Anforderungen sind nur zu den normalen Kosten der Softwarehäuser zu realisieren.

Wurde die Standardsoftware angepaßt, so übernimmt der Softwarelieferant die Pflege im Rahmen eines Pflegevertrages nur selten. Hier wird die Pflege gegen Aufwand - das heißt: nicht im voraus kalkulierbar - erbracht.

Sehr aufwendig wird die Softwarepflege, wenn sie von eigenen Mitarbeitern erbracht wird und gleichzeitig ein Pflegevertrag läuft, der den jeweils neuesten Release-Stand garantiert. In diesem Fall muß bei jeder neuen Release-Lieferung das Pflegepersonal aktiv werden, um zu prüfen, ob die bestehenden Anderungen mit dem neuen Release kompatibel sind. Bei der Entscheidung für oder gegen Eigenentwicklung von Software sollte man also in keinem Fall von einer Ersparnis bei der Softwarepflege ausgehen.

Die Kalkulation für die Installation einer Standardsoftware ist aufwendiger als die Vorkalkulation für eine Eigenentwicklung. Eine abgesicherte Entscheidung für eine Standardsoftware basiert unter anderem darauf, daß der Anwender sich auf der einen Seite über die Kosten der Eigenentwicklung, auf der anderen Seite über die Kosten der Software-Installation im klaren ist. Wenn - wie es allzu oft geschieht - die doppelte Kostenermittlung aus Zeitgründen nicht exakt durchgeführt wird, läßt sich die angesetzte Ersparnis durch die Standardsoftware meist nicht erreichen.

Tabelle 1 auf Seite 14 zeigt nicht nur die Aufwandsabweichungen pro Phase, sondern auch die Ersparnisse über die gesamte Projektdauer. Dabei wird der Aufwand für die Eigenentwicklung mit 100 Prozent angesetzt. Die dafür angenommenen Kosten betragen 500000 Mark; für die Einmallizenz der Standardsoftware sind 20 Prozent der Eigenentwicklungskosten veranschlagt.

Aus dieser Gegenüberstellung wird deutlich, daß es falsch ist, lediglich den Lizenzpreis der Standardsoftware mit den Kosten der Eigenentwicklung zu vergleichen. Die Ersparnis beträgt allenfalls zirka 50 Prozent und kann nur erreicht werden, wenn der Anwender bereit ist, sein Anforderungsprofil an das Angebotsprofil der Software anzugleichen.

*Robert Hürten leitet die Unternehmensberatung Hürten & Partner in Riedstadt-Leeheim. Der Vorliegende Beitrag basiert auf einem Vortrag, den der Autor im Herbst des vergangenen Jahres beim 4. Kolloquium über Software-Entwicklungssysteme und -Werkzeuge der Technischen Akademie Esslingen gehalten hat.