Standardsoftware ist in der Diskussion. Ob ihr Einsatz nutzbringend oder unwirtschaftlich ist, hängt nicht zuletzt vom Grad der Modifikation dieser Produkte ab. Wolfgang Haschke und Robert Hürten* führen in ihrem zweiteiligen Beitrag aus, wie Auswahl, Einsatz und Überprüfung von Standardsoftware sinnvoll erfolgen kann und welche Alternativen zu Standardprodukten und Eigenentwicklungen bestehen.

Auf einem unserer Seminare zur Problematik der Standardsoftware aus Sicht des DV-Revisors berichteten zwei Teilnehmer über ihre Erfahrungen mit der gleichen Standard-FIBU. Die Ergebnisse waren völlig unterschiedlich, obgleich die Unternehmen vergleichbar waren.

Die Einführung bringt oft Probleme mit sich

Teilnehmer A stellte fest, daß nach einer intensiven Phase der Entscheidungsfindung die Einführung des Produktes keine Probleme gebracht habe. Zwischen der Kaufentscheidung und dem Echtlauf der Buchhaltung sei kein halbes Jahr vergangen. Im Unternehmen von Teilnehmers B war das Produkt ein Jahr nach der Kaufentscheidung immer noch nicht einsatzfähig. Einem Berater, den man für die Einführungsunterstützung engagiert hatte, wurde nach zwölf Monaten gekündigt, und das Unternehmen stand wieder am Anfang der Planung.

Da beide Anwender die gleiche Software gewählt hatten, kann die Ursache für die unterschiedlichen Ergebnisse nicht in der Standardsoftware liegen. Der vorliegende Aufsatz soll die wichtigsten Punkte herausarbeiten, die zu beachten sind, um eine wirtschaftliche Nutzung von Standardsoftware zu erreichen .

Die Pläne zur Entwicklung standardisierter Anwendersoftware wurden Ende der 60er Jahre von der damaligen Bundesregierung aufgegriffen und mit beachtlichen Mitteln gefördert. Das volkswirtschaftliche Ziel war, die mehrfache Programmierung von Aufgaben zu vermeiden, die bei allen Anwendern oder großen Anwendergruppen gleichartig auftraten.

Die betriebswirtschaftlichen Vorteile sollten sich bei den Unternehmen durch die schnelle Verfügbarkeit von guten Softwarelösungen ergeben. Fach- und DV-Wissen konnte von außen eingebracht werden, wobei die Entwicklungskosten automatisch auf viele Unternehmen gleichmäßig verteilt waren.

Diese Ziele sind auch im Bereich der Mittleren Datentechnik und der Bürocomputer fast überall erreicht worden. Anders verlief jedoch die Entwicklung bei den Anwendern von Groß-DV-Anlagen. Der Durchbruch für den Einsatz von Standardsoftware kam hier erst Mitte der 80er Jahre. Dabei ist festzustellen, 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ürocomputern.

Für Klein- und Mittelbetriebe bietet sich zur Standardsoftware keine Alternative, weil in den meisten Fällen das Geld und das Know-how fehlt, um eigene Software zu erstellen oder Fremdsoftware zu modifizieren. Standardsoftware ist für diese Unternehmen die einzige - und nicht etwa eine alternative Lösung.

Im Bereich der Groß-DV steht die Standardsoftware im Wettbewerb mit der Eigenentwicklung. Das Wesentliche der Eigen- oder Individualentwicklung ist, daß bei ihr die firmenspezifischen Anforderungen an die Softwarelösung in der Regel nur durch technische Grenzen limitiert wurden. Diese sind heute jedoch so weit gesteckt, daß sie auch bei extremen Anforderungen kaum noch beachtet werden müssen.

Die jahrzehntelange Erfahrung der Software-Entwickler, daß alle ihre Vorstellungen durchführbar waren, verleitet dazu, eine Standardsoftware an "unbedingt notwendige Firmenanforderungen" anzupassen, selbst wenn diese aus betriebswirtschaftlicher Sicht nicht zwingend sind. In diesen Fällen wird die Standardsoftware allzu schnell "verändert", so daß der ursprünglich angestrebte Erfolg, der sich mit den Adjektiven billiger, schneller verfügbar und personenunabhängig beschreiben läßt, 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". Bei der Firma B führte die entgegengesetzte Entscheidung: "Die Software ist an unser vorhandenes System anzupassen", zu der genannten kleinen Katastrophe.

Zwischen diesen zwei konträren Forderungen muß der Weg gefunden werden, der für den Anwender einer Standardsoftware optimal ist. Daß dieser Weg zwischen Erfolg und Mißerfolg nicht breit ist, wird anhand des Phasenkonzeptes im folgenden gezeigt. Wir legen das Sechs Phasen-Modell von Siemens zugrunde:

1. Projektvorschlag

- Bearbeitung Projektantrag

- Voruntersuchung

- Erstellung der ersten Wirtschaftlichkeitsbetrachtung (WB)

- Festlegung von Projekt- und Phasenorganisation

2. Planungsphase I

- Erstellung Idealkonzept

- Ist-Aufnahme und -Analyse

- Fachliche Grobkonzeption und anschließend verbesserte Wirtschaftlichkeitsbetrachtung

3. Planungsphase II

- Fachliche Feinkonzeption

- DV-Grobkonzeption und anschließend verbesserte Wirtschaftlichkeitsbetrachtung

- Abstimmung Leistungsbeschreibung

- Testplan

- Schulungsplan

4. Realisierungsphase I

- DV-Feinkonzeption und anschließend verbesserte Wirtschaftlichkeitsbetrachtung

- Softwareanpassung

- Programmierung

- Stammdatenübernahme

- Test

- Arbeitsanweisungen

5. Realisierungsphase II

- Einweisung Anwender- und RZ-Personal

- Organisationsanpassung

- Probebetrieb

- Übergabe

6. Einsatzphase

- Verfahrensabwicklung (Produktiveinsatz)

- Softwarepflege

- Erfolgskontrolle des realisierten EDV-Projektes (Verfahrensanalyse)

Gehen wir jetzt die einzelnen Phasen durch, um zu sehen, welche Aufgaben bei dem Einsatz von Standardsoftware fortfallen und welche zusätzlich anfallen. Auch beim Einsatz von Standardsoftware müssen die einzelnen Schritte der Projektvorschlagsphase wie bei einer Eigenentwicklung ablaufen.

Soll in diesem Projektstadium über den Einsatz einer bestimmten Standardsoftware entschieden werden, so müßte eine Schätzung der Kosten für eine eventuelle Eigenentwicklung und die Ermittlung eines durchschnittlichen Kaufpreises für die Standardsoftware vorgenommen werden. Der Einsatz einer Standardsoftware wird in der ersten Phase keine Einsparung gegenüber einer Eigenentwicklung bringen.

Größte Einsparungen in Planungsphase II

In der Planungsphase müssen die Angebote für eine Standardsoftware eingeholt werden. Dies kann nach zwei verschiedenen Methoden erfolgen:

1. Der Anwender erstellt wie bei einer Eigenentwicklung eine fachliche Grobkonzeption und fordert damit Softwarehäuser zu einem Angebot auf. Die eingehenden Angebote prüft er später gegen seine Ausschreibung, um das Softwareprodukt zu finden, das seiner Ausschreibung am nächsten kommt.

2. Der Anwender schreibt Softwarehäuser an, von denen er vermutet, daß sie eine Software anbieten, mit denen seine Probleme gelöst werden können. Auch in diesem Fall muß der Anwender die eingehenden Angebote mit seinen Vorstellungen abgleichen, um zu einer Entscheidung für ein bestimmtes Produkt zu kommen. In beiden Fällen wird der Aufwand für die Planungsphase I mindestens genauso groß sein wie bei einer Eigenentwicklung. Bei einer sorgfältigen Produktauswahl wird der Aufwand sogar noch größer.

In der Planungsphase II könnte die größte Einsparung erzielt werden, sofern der Anwender sich dazu entschließt, das ausgesuchte Produkt unverändert einzusetzen. In diesem Fall geht der Aufwand schnell auf Null zurück. Die meisten Softwareprodukte bieten heute eine Flexibilität, die es erlaubt, in einen vorgegebenen Rahmen Anpassungen vorzunehmen. Ein typisches Beispiel ist dafür die Länge von Ordnungsbegriffen, zum Beispiel von Kontonummern oder auch die Zuordnung von Größen, zum Beispiel FIBU Konten zu Bilanzpositionen.

Derartige Anpassungen verlangen in der Regel keinen großen zusätzlichen Aufwand. Den Preis für diese Flexibilität hat der Anwender durch einen erhöhten Hardwarebedarf zu zahlen. Werden dagegen Funktionen oder Änderungen verlangt, die nicht in der Standardsoftware vom Anbieter vorgesehen waren, so hat jetzt in dieser Phase die organisatorische und DV-mäßige Planung zu beginnen.

Da jedoch feste Rahmen im Standard realisiert sind, werden diese Planung und die folgenden Arbeiten aufwendiger sein als wenn diese in einer Eigenentwicklung hätten realisiert werden müssen. Dafür sind nämlich dann nicht nur die zusätzlichen gewünschten Aufgaben zu definieren und zu analysieren, sondern auch das im Standard vorhandene vorgegebene Umfeld.

Der Aufwand für Programmänderungen beziehungsweise -ergänzungen wächst überproportional mit der Aufgabe. Wenn zum Beispiel 50 Prozent des vorhandenen Standardprogramms geändert werden soll, kann der Aufwand bereits 100 Prozent der Eigenentwicklung - bezogen auf Phase 3 bis 5 - betragen.

Die Gefahr des unterschätzten Änderungsaufwandes ist immer dann gegeben, wenn vor dem Kauf der Standardsoftware kein Abgleich zwischen dem Anforderungsprofil des Anwenders und dem Angebotsprofil des später zu ändernden Produktes - spätestens jedoch in der Planungsphase II - gemacht wurde.

Der Aufwand, der in der Realisierungsphase I für die DV Feinkonzeption und die Programmierung zu erbringen ist, kann unter dem gleichen Gesichtspunkt bewertet werden wie bei der Planungsphase II. Was dort gesagt wurde gilt an dieser Stelle entsprechend Änderungen in bestehende Programmstrukturen und -codes einzubauen ist erheblich auf wendiger und im Hinblick auf die Fehlerwahrscheinlichkeit ungünstiger als ein neues Programm zu schreiben.

Dies erklärt sich auch daraus, 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 Anbieter von Standardsoftware dem Anwender für die Programmänderungen zur Verfügung stellt.

Zu beachten ist, daß bei Änderungen auch der Aufwand für die DV-Feinkonzeption sowie für die Programmierung über proportional zum Umfang der Aufgabe steigen wird. Das gleiche gilt auch für die Programm-Einzeltests. Anstelle des Systemtests wird beim Einsatz von Standardsoftware der Abnahmetest stehen. Der Aufwand für diese Tests dürfte im Normalfall gleich groß sein. Die Standardsoftware bringt hier kaum Ersparnisse.

In der Realisierungsphase II ist der Aufwand für die Einweisung der Anwender und des RZ-Personals sowie für Organisationsanpassungen bei der Anwendung einer unveränderten Standardsoftware möglicherweise größer als bei einer Eigenentwicklung. Ursache hierfür ist die Tatsache, daß die neue Software nicht das vorhandene Umfeld berücksichtigt. Da die Programme nicht angepaßt wurden, muß das Umfeld, die Organisation des Unternehmens, angepaßt werden

Wurden starke Anpassungsänderungen in der Software vorgenommen, so wird der Aufwand für die Realisierungsphase II mindestens so hoch sein, wie bei einer Eigenentwicklung. Geringer wird er auf keinen Fall .

In der Einsatzphase sind vor allem die Kosten für die Softwarepflege zu beachten. Bei unveränderter Standardsoftware werden die Kosten für die Softwarepflege im Rahmen eines Pflegevertrages geleistet. Diese liegen im Durchschnitt bei 15 Prozent des Produktpreises. Mit diesen Kosten läßt sich fest kalkulieren.

Ob sie gerechtfertigt sind, soll hier nicht hinterfragt werden. Geprüft werden muß jedoch, welche Leistungen im Rahmen des Vertrages erbracht werden. In vielen Fällen kann ein Pflegevertrag Nachteile für den Anwender bringen. Dies ist dann der Fall, wenn er gezwungen ist, alle Release-Änderungen mit zu machen, auch wenn diese für ihn keinen Vorteil bringen.

Individuelle Wünsche sind in keinem Pflegevertrag abgedeckt. Solche Änderungen sind nur zuzüglich der normalen Kosten der Softwarehäuser zu realisieren. Wurde die Standardsoftware angepaßt, so wird der Softwarelieferant die Pflege nur in den wenigsten Fällen im Rahmen eines Pflegevertrages übernehmen. Hier wird die Pflege gegen Aufwand, das heißt, nicht in voraus kalkulierbar, erbracht.

Sehr aufwendig ist die Softwarepflege, wenn sie von eigenen Mitarbeitern geleistet wird und gleichzeitig ein Pflegevertrag läuft, der den jeweils neuesten Stand des Release garantiert oder fordert. In diesem Fall muß bei jeder neuen Release-Lieferung das Pflegepersonal aktiv werden. Bei jedem Release-Wechel ist nämlich zu prüfen ob die bestehenden Änderungen mit der neuen Ausführung kompatibel sind. Bei der Entscheidung für oder gegen eine Eigenentwicklung Software sollte man in keinem Fall eine Ersparnis bei der Softwarepflege ansetzen.

Die Erstellung einer Kalkulation für die Installation von Standardsoftware ist aufwendiger als die Vorkalkulation für eine Eigenentwicklung, weil hier mehrere Seiten zu betrachten sind.

Dies scheint auch der Grund für die häufig auftretende Klage zu sein, daß man sich bei den Installationskosten verschätzt habe.

Wird die DV-Revision in das Auswahlverfahren für eine Standardsoftware eingeschaltet, so sollte sie auf folgende Punkte achten:

- ein Abgleich von Anforderungs- und Angebotsprofil des Softwareproduktes muß rechtzeitig vorgenommen werden;

- anhand der Ergebnisse des Abgleiches sind die notwendigen Änderungen und/oder Ergänzungen zu definieren;

- auf Programmänderungen zu Lasten organisatorischer Maßnahmen ist zu verzichten:

- der Kostenvergleich zwischen Eigenentwicklung und Standardsoftware sollte im Sinne der angeführten Argumente realistisch sein.

*Wolfgang Haschke und Robert Hürten sind Unternehmensberater bei der EDV-Controlling Unternehmensberatung GmbH in Heppenheim.