Bei Großunternehmen werden nur sechs Prozent der eingesetzten Anwendungen durch Standardsoftware abgedeckt. Generell ist das Verhältnis Standardsoftware zu Individualsoftware eins zu vier. Aus diesen Zahlen läßt sich die Frage nach der Rationalisierung subjektiv-mathematisch beantworten.

Um aber zu verwertbaren Aussagen zu kommen, ist zunächst eine Definition des Begriffes Rationalisierung erforderlich. Rationalisierung soll hier bedeuten: Produktivität (Qualität, Aufwand, Termine) sowie Nutzbarmachung der impliziten Ressourcen der Standardsoftware.

Zur Produktivität von Standardsoftware ist schon viel geschrieben worden. Über Problemkreise wie Anpassungsaufwand, Kompatibilität zu Systemkomponenten, Speicherbedarf, Wartungs- und Erweiterungsfreundlichkeit, Benutzerfreundlichkeit sowie Benutzeroberfläche können sowieso keine objektiv verwertbaren Aussagen gemacht werden: Jeder Anwender muß diese unter seinen speziellen Gesichtspunkten betrachten.

Viel eher sollte der Hersteller von Standardsoftware dem Aspekt der Produktivität mehr Beachtung schenken.

Die Kritik entzündet sich an folgenden Punkten:

þEs wird zuwenig auf die Besonderheiten der Zielgruppe geachtet;

þEs wird zu sehr Wert gelegt auf eine allumfassende Verwendbarkeit der Software;

þEs wird während der Entwicklung zuwenig standardisiert (Standard-Module);

þEs wird zuviel Wert gelegt auf eine allumfassende Integrationsfähigkeit der Standardsoftware mit allen möglichen eigenen und fremden Systemkomponenten;

þDie Projektabwicklung wird nicht den Anforderungen an die Entwicklung von Standardsoftware gerecht.

Was steht hinter diesen Erfahrungen? Die Entwickler wollen sich DV-technisch profilieren und versuchen, die ausgefallensten Features einzubringen sowie alle möglichen Schnittstellenanforderungen zu befriedigen. Darunter leidet die Transparenz, der Anpassungsaufwand, aber auch die Qualität der Standardsoftware.

Der Projektleiter achtet zu wenig auf die temporäre Einbeziehung von Spezialisten sowie auf die Nutzung von Standard-Modulen. Man kann eine Transaktion individuell gestalten oder sie zu 80 Prozent standardisieren (Logon-TPR, Display- TPR, DB-Zugriffs-TPR, Error-TPR, Funktionscodeverwaltung). Nur im letzten Fall bekommt man einen günstigen Entwicklungs-, Anpassungs- und Wartungsaufwand.

Ohne teure Spezialisten

Der Leiter der Software-Entwicklung orientiert sich zu sehr an den Bedürfnissen des Vertriebs und zuwenig an denen des Anwenders oder der Zielgruppe. Dabei wird ein qualitativ gutes Branchenpaket öfter verkauft als das "Eier-legende-Wollmilch-Schwein: Ein klares, begrenztes Konzept erleichtert dem Vertriebsberater die seriöse Argumentation.

Standardsoftware sollte so entwickelt werden, daß der Lebenszyklus den der Hardware- und Systemsoftware-Komponenten überdauern sollte. Das bedeutet: Die Schnittstellen müssen so angelegt werden, daß Standardsoftware wirklich neutral wird. Nur dann ist sie auch rationell.

Jede Standardsoftware hat implizite Ressourcen, die bei entsprechender Nutzung durch den Anwender den Rationalisierungseffekt erheblich steigern. Enthält die Standardsoftware einen Transaktionssteuerteil, eine Datenbank oder einen TP-Monitor, so kann der Anwender diesen Einsatz ohne die sonst zusätzlich notwendigen, teueren Spezialisten bewerkstelligen. Die Unterstützung kommt während der Anpassung - von seiten des Herstellers. Diesen Vorteil können diejenigen Anwender ermessen, die sich etwa mit dem Problem des DB-Einsatzes im Rahmen individueller Software-Entwicklung herumgeschlagen haben (CW 33 vom 14. 8. 81, Gastkommentar, Seite 6). Weitere implizite Ressourcen bei Standardsoftware-Systemen sind:

þAnwender-, Bedienerdokumentation,

þklare Vorstellungen über Performance

þklare Vorstellungen über Speicherbedarf

þBedieneroberfläche (Experten-, Laiencode).

Bei entsprechender Bereitstellung dieser Ressourcen durch den Hersteller sowie die Nutzung durch den Anwender wäre der größte Rationalisierungseffekt gegeben. Hier anzusetzen, darin liegt die Chance der Standardsoftware.

Wie rationell ist nun die Entwicklung von Standardsoftware?

Als Hersteller sollte man sich vorher eingehend mit den Kosten-/Nutzenaspekten befassen. Speziell die Entwicklungskosten könnten in wirtschaftlichen Grenzen gehalten werden, wenn

þProgramm-Entwicklungsbibliotheken für Standardmodule verfügbar sind;

þein speziell auf Standardsoftware ausgerichteter Projektplan zur Entwicklung benutzt wird;

þdie Systemumgebung des Anwender-Softwaresystems von einem professionellen Zentralteam realisiert wird;

þdie Anwendungen von Systemanalytikern mit speziellen Funktions- und

Branchenkenntnissen entworfen und konzipiert werden und

þdie einzelnen Entwicklungsphasen durch entsprechende Methoden und Tools unterstützt werden.

Trotz gezielter Einsparungen auf der Entwicklungsseite zeigt die Praxis, daß der Entwicklungsaufwand von Standardsoftware-Systemen - bedingt durch deren besondere Anforderungen an Qualität, Dokumentation und Einsatzflexibilität - größer ist, als der für herkömmliche, gleichartige individuelle Software. Nur wenn der Markt durch entsprechenden Absatz diesen Entwicklungsaufwand honoriert, ist die Entwicklung rationell, sprich wirtschaftlich. Tut er es nicht, hat man Fehler gemacht.

*Dr. Ullrich Schedl ist Geschäftsführer der UBS Gesellschaft für Unternehmensberatung mbH, München.