Standardsoftware oder Eigenentwicklung? (Teil 2 und Schluß)

Abseits eingefahrener Gleise gibt es neue Wege zu entdecken

21.02.1992

Den wenigsten Softwerkern ist bekannt, daß zwischen den zwei Extremen Eigenentwicklung oder Standardsoftware durchaus noch andere Varianten für eine wirtschaftliche Erstellung beziehungsweise Beschaffung von Software existieren. Robert Hürten hat diese Möglichkeiten untersucht und die Vorteile gegen die Nachteile abgewogen.

Standardsoftware besteht per definitionem aus Programmen, die für einen anonymen, abstrakten Anwender geschrieben sind. Wird die Software für eine bestimmte Gruppe geschrieben, deren Einzelmitglieder jedoch unbekannt sind, so heißt sie Branchensoftware. Die Argumente für und gegen den Einsatz von Standardsoftware sind in zahlreichen Veröffentlichungen dargestellt worden. Die Gewichtung der Argumente kann je nach der Interessenlage der Entscheidungsträger sehr unterschiedlich sein, weshalb wir hier kurz die wichtigsten Entscheidungskriterien rekapitulieren.

Zunächst ist zu beachten, daß Standardsoftware nur für Standardaufgaben sinnvoll genutzt werden kann. Dies bestätigen auch die Verkaufsstatistiken der Softwarehäuser. Standardsoftware wird zuallererst in den Arbeitsgebieten eingesetzt, wo die Unternehmen fremdbestimmt sind und sich der Wettbewerb des Marktes nicht auswirkt, also in der Lohn- und Gehaltsabrechnung sowie der Finanzbuchhaltung. Im Vertriebsbereich hingegen ist der Einsatz von Standardsoftware nicht so weit verbreitet.

Risiken worden zu gering eingeschätzt

Die wichtigsten Argumente zugunsten der Standardsoftware lauten:

- Anstehende Aufgaben können schnell realisiert werden.

- Die Entwicklungskosten werden auf viele Anwender verteilt, wodurch ein Kostenvorteil entsteht.

- Die fachliche Kompetenz für die Anwendung wird im Softwareprodukt mitgekauft.

- Bei einem Produkt aus einem guten Softwarehaus kann man eine ausgereifte technische Lösung erwarten.

- Eine Software, die seit längerer Zeit bei einer Vielzahl von Anwendern eingesetzt ist, wird stabil und ausgetestet sein.

- Die Wartungskosten sind im Rahmen eines Wartungsvertrages fest kalkulierbar.

Gegen diese Vorteile sind die folgenden Nachteile abzuwägen:

- Die Standardsoftware ist für den einzelnen Anwender zu breit angelegt und führt deshalb zu einem überhöhten Ressourcenbedarf.

- Die innerbetriebliche Organisation muß an die Standardsoftware angepaßt werden beziehungsweise

- die Standardsoftware muß an die innerbetrieblichen Anforderungen angepaßt werden.

- Die fachliche Kompetenz geht beim Anwender der Standardsoftware mit der Zeit verloren.

- Die kurzfristige Anpassung der gekauften Softwarelösung an neue betriebliche Anforderungen wird dadurch erschwert, daß Programm-Know-how und -Dokumentation beim Anwender nicht vorhanden sind; auf diese Weise gerät der Anwender in die Abhängigkeit vom Lieferanten der Software.

- Der Wartungsvertrag kann sich negativ auswirken, falls nicht benötigte Programmverbesserungen häufig zur Installation "überflüssiger" neuer Releases führen.

Die Praxis zeigt, daß oft die Vorteile zu hoch eingeschätzt und die Nachteile unterbewertet werden.

Eine mögliche Alternative ist die - vollständige oder teilweise - Übernahme einer von einem anderen Anwender aus derselben Branche individuell erstellten Lösung. Die Softwareübernahme unterscheidet sich in den Vor- und Nachteilen beachtlich von dem Einsatz einer Standardsoftware. Dabei findet im allgemeinen eine positive Verschiebung zu den Vorteilen hin statt. Die Softwareübernahme wird bislang nicht eben häufig genutzt wird. Der Grund dafür liegt darin, daß diese Art der Softwarebeschaffung um so wirtschaftlicher ist, je stärker sich die Geschäftstätigkeit von Abgeber und Übernehmer ähneln. Diese Voraussetzung wird aber genau dann am besten erfüllt, wenn die beiden Anwender direkt miteinander konkurrieren. Es leuchtet wohl ein, daß zwischen Mitbewerbern in der Regel kein großes Interesse besteht, einander das interne Organisations-Know-how offenzulegen oder gar weiterzugehen.

Diese Argumentation gegen eine Softwareübernahme wird jedoch öfter vorgetragen, als sie in der Praxis berechtigt ist. In vielen Fällen kommt es beispielsweise nicht zu Überschneidungen der Verkaufsgebiete, oder es existieren bereits Absprachen anderer Art (zum Beispiel allgemeine Geschäftsbedingungen).

Vor- und Nachteile der Übernahme

Auch bei der Softwareübernahme läßt sich - wie bei der Installation einer Standardsoftware - der Vorteil einer schnellen Realisierung anstehender Aufgaben erreichen. Da in der Regel nur Software von gleichartigen Anwendern übernommen wird, wird sich die für die Realisierung notwendige Zeit noch verkürzen. Die Praxis zeigt, daß Notwendigkeit, die übernommenen Software an die Vorstellungen des Ziel-Anwenders anzupassen, im Durchschnitt weniger größer ist als bei der Standardsoftware. Das Gleiche läßt sich auch im Hinblick auf eine Anpassung der innerbetrieblichen Organisation an die Fremdsoftware beobachten.

Wird die Software von einem gleichgelagerten Unternehmen übernommen, so tritt auch im Stadium der Softwareauswahl eine Beschleunigung ein. Die Ursache dafür liegt darin, daß zwischen Anbieter und Interessent das gleiche fachliche Sprachniveau besteht. Der Anbieter kann den Interessenten bei der Ermittlung seines Organisationsbedarfs fachlich kompetenter unterstützen als der Verkäufer einer Standardsoftware.

Da es sich bei der zu übernehmenden Software um eine Individual-Lösung handelt, übernimmt der neue Anwender auch kein zu breit angelegtes Programm. Der Bedarf an Hardwareressourcen wird also nicht überhöht sein.

Kommt der Anbieter aus der gleichen Branche, so ist er genauso wie der Abnehmer gezwungen, auf neue Anforderungen zu reagieren, die zum Beispiel vom Gesetzgeber verlangt werden. Also wird die Softwarepflege in Hinblick auf fremdbestimmte Anforderungen kein Problem sein. Allerdings dürften Anpassungen der Software an neue Bedürfnisse des Abnehmers problematisch sein, wenn der Anbieter in diesen Neuerungen keine Vorteile für sich erkennt.

Die absoluten Produktkosten bei der Softwareübernahme werden mit großer Wahrscheinlichkeit höher sein als für eine Standardsoftware. Das ergibt sich daraus, daß bei der Kalkulation des Preises nicht von hohen Verkaufszahl auszugehen ist. Die Praxis zeigt, daß nur ganz selten "Freundschaftspreise" gemacht werden, vor allem nicht bei Mitbewerbern. Ob die im Vergleich zur Standardsoftware hohen Produktpreise über das gesamte Projekt gesehen tatsächlich weniger günstig sind, muß anhand der unterschiedlichen Vor- und Nachteile bewertet werden.

Im Gegensatz zur Standardsoftware wird man bei der Übernahmesoftware nur selten Referenzen einholen können. Aussagen über die Zuverlässigkeit der Programme sind lediglich vom Ersteller zu bekommen. Der Käufer sollte sich also die Quellprogramme zeigen lassen, um zu sehen, wie die Programmierung beschaffen ist. Die Erfahrung zeigt, daß für ein gutes Softwarehaus die Dokumentation einen anderen Stellenwert hat als für eine firmeninterne Programmiergruppe. Ferner sollte der Interessent nicht nur mit den DV-Leuten verhandeln, sondern auch Gespräche mit Mitarbeitern der Abteilungen führen, die die zu übernehmende Software nutzen.

Die SW-Pflege bleibt am Abnehmer hängen

Besondere Beachtung muß bei einer Übernahmesoftware der künftigen Entwicklung des Produkts beigemessen werden. Nur seiten wird bei einer Software-Übernahme die Pflege der Software zu einem festen Preis vertraglich geregelt. In der Regel geht der Anbieter keine Verpflichtung für die Software ein, weswegen er dem Käufer die Quellprogramme aushändigt. Im Gegensatz zur Standardsoftware muß der Abnehmer also Programmierer beschäftigen, die die Pflege der Software durchfuhren. Die Alternative, ein drittes Unternehmen für die Plfege der übernommenen Software einzuschalten, ist erfahrungsgemäß sowohl von den Kosten als auch von der Wirkung her nicht sinnvoll.

Nur das Konzept wird übernommen

Die Übernahme einer laufenden DV-Anwendung scheitert häufig an der Tatsache, daß beim Interessenten nicht dieselbe Hard- oder Software installiert ist wie beim Programmentwickler. Beachtet man, daß heute erfahrungsgemäß zirka 30 Prozent des Entwicklungsaufwands für das fachliche, Grob- und Feinkonzept aufgewandt wird, so kann eine Konzeptübernahme bereits eine merkliche Reduzierung der Software-Entwicklungskosten bedeuten. Von einer Konzeptübernahme sprechen wir, wenn von einer laufenden DV-Anwendung nur das fachliche Konzept übernommen wird.

In den Fällen, in denen Anbieter und Interessent mit gleichen Datenbankstrukturen arbeiten, können auch die Programmvorgaben noch sinnvoll mit übernommen werden. Die Aufgaben des Abnehmers beschränken sich dann weitgehend auf die codierung und den Test. Auf diese Weise dürfte mehr als 50 Prozent des Gesamtaufwandes einzusparen sein.

Bei der Konzeptübernahme handelt es sich um einen echten Know-how-Kauf. Sie ist mit einem Auftrag an einen externen Berater zu vergleichen, der eine neue DV-Konzeption erarbeiten soll. Für eine wirkungsvolle Konzeptübernahme sind weitgehend die gleichen Voraussetzungen zu beachten wie bei einer Softwareübernahme.

Bei einer Konzeptübernahme ist der zukünftige Anwender jedoch nicht an den vorhandenen starren Rahmen einer bestimmten technischen Lösung gebunden. Dadurch sind eventuell notwendige Änderungen an dem vorliegenden Konzept leichter durchzufahren. Programmtechnische Auswirkungen auf bereits bestehende Programme brauchen dabei nicht beachtet zu werden. Bei der Konzeptübernahme erhält der Anwender trotz der konzeptionellen Fremdbestimmung eine individuelle technische Lösung.

Das wirkt sich vor allem bei der Softwarepflege positiv aus. Der übernehmende Betrieb hat mit der Kodierung auch die technische Dokumentation erstellt. Er ist also bei Programmänderungen nicht auf fremde Unterlagen angewiesen. Auch bei der Softwarepflege unterliegt er keiner Fremdbestimmung, wie sie zum Beispiel bei einer Standardsoftware vorliegt.

Der Vorteil der Konzeptübernahme gegenüber einem Beratungsauftrag liegt darin, daß das Ergebnis schon vor der Auftragserteilung bekannt ist und bewertet werden kann. Außerdem werden die Kosten für das fertige "Konzept" günstiger sein als die eines Beraterauftrags für die Entwicklung eines gleichwertigen Konzeptes.

Die dritte Alternative zu Standardsoftware und Eigenerstellung heißt kooperative Software-Entwicklung. Dabei bilden gleichartige DV-Anwender eine Arbeitsgemeinschaft mit dem Ziel, gemeinsam eine Anwendungssoftware zu planen, zu entwickeln und zu pflegen.

Die Kooperative Entwicklung kann als der Idealfall einer Branchen-Standard-Software angesehen werden: Die künftigen Anwender haben Einfluß auf den Inhalt, die Gestaltung und die Pflege ihrer Anwendung.

Ein Spezialfall der Kooperativen Entwicklung liegt dann vor, wenn mehrere gleichartige Anwender gemeinsam einen Software-Entwickler beauftragen, eine neue Softwarelösung zu erstellen. Ein typisches Beispiel für eine Kooperative Entwicklung sind die gemeinsamen Rechenzentren der Geldinstitute.

Die Gruppengröße ist ein wichtiger Faktor

Die wesentlichen Vorteile der Kooperativen Entwicklung wurden bereits oben erwähnt: Mitbestimmung bei Inhalt, Aufbau und Weiterentwicklung (Pflege) der Software. Dadurch, daß die Software im Hinblick auf eine definierte Anwendergruppe entwickelt wird, läßt sich eine Überladung der Lösung vermeiden. Außerdem können die Anwender insofern auf die Programmierer einwirken, daß sie bestimmte Methoden und Strukturen anwenden oder einhalten. Bei der Softwarepflege bestimmt die Entwicklungsgruppe selbst den Rhythmus für die Einführung von Änderungen und Ergänzungen.

Voraussetzung für die Nutzung dieser Vorteile ist aber, daß die Gruppe langfristig kooperativ arbeitet. Um dies zu erreichen, sind die Kooperationsverträge sorgfältig zu gestalten. Die Gruppe darf nicht zu groß sein, auch wenn dies unter dem Gesichtspunkt der Kostenverteilung sinnvoll wäre. Es besteht sonst die Gefahr, daß auf der einen Seite der Einfluß des einzelnen abnimmt und auf der anderen Seite zu viele Zugeständnisse an individuelle Wünsche der Gruppenmitglieder gemacht werden.

Wenn diese Voraussetzungen berücksicht werden, ist die kooperative Entwicklung für die Beteiligten die günstigste Lösung. Die bei den anderen Beschaffungsmethoden aufgeführten Nachteile kommen hier kaum zum Tragen. Der wichtigste Nachteil liegt hingegen in der Möglichkeit, daß die Entwicklungsgruppe auseinanderfällt und sich kein Gruppenmitglied für ein Fortbestehen der Software verantwortlich fühlt. Die Folgen einer solchen Situation verringern sich jedoch merklich, wenn eine vollständige Dokumentation über alle Phasen des Software-Life-Cycle geführt wird.

Die Kosten für eine kooperativ erstellte Software fallen nicht linear mit der Anzahl der Gruppenmitglieder. Auch bei drei und mehr Mitgliedern werden die anteiligen Kosten kaum unter 50 Prozent der Kosten einer Eigenentwicklung sinken.

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