Die Möglichkeit, Software zu standardisieren, muß man in verschiedenen Bereichen sehen: Konzeption, Programmierung und Dokumentation.

Betrachten wir das bekannte Problem der Lohn- und Gehaltsabrechnung, eine Aufgabe, die in jedem Unternehmen zu lösen ist und bei der die Finanzbehörden und die Sozialversicherungsträger vorschreiben, wie die Netto-Lohnberechnung zu erfolgen hat. Man sollte annehmen, daß eine Aufgabenstellung, die so stark in einen gesetzlichen Rahmen gepreßt ist, zu gleichen Software-Lösungen führt. Im Isis-Katalog werden jedoch mehr 100 verschiedene Lohn- und Gehaltsprogramme angeboten. Zu dieser Zahl sind die tausend Lösungen hinzuzurechnen, die in den Programmierabteilungen der deutschen EDV-Anwender entwickelt wurden. Ähnliche Zahlen sind auch bei den anderen Arbeitsgebieten im kommerziellen Bereich festzustellen.

Hier stellt sich in dieser Situation die Frage, ob die zahlreichen Variationen über eine betriebswirtschaftliche Aufgabe notwendig sind, um die organisatorische Entwicklung voranzutreiben, oder ob es nicht rationeller ist, Standardkonzeptionen zu haben, auf denen die Unternehmer zurückgreifen und aufbauen können.

Kein Standard für die Bildschirmverarbeitung

Der notwendigste Ansatzpunkt für eine Standardisierung der Programmierung liegt im Verantwortungsbereich der EDV-Hersteller: die Programmiersprachen. Sicherlich sind hier in der Vergangenheit Standards entwickelt worden (Cobol, RPG etc.). Verwunderlich ist jedoch, daß diese Normen immer wieder auseinanderlaufen, wenn neue technische Mittel auf den Markt kommen. So ist etwa bis heute bei Cobol noch kein allgemein gültiger Standard für die Bildschirmverarbeitung vorhanden.

Auf der Anwenderseite, das heißt, auf der Programmebene, werden heute nur in wenigen Fällen Standardisierungsmöglichkeiten genutzt. Normierte und strukturierte Programmierung sind noch nicht in das Bewußtsein der Anwender gedrungen. Die Vielfalt der Programmierstile und -dialekte ist nicht abzuschätzen. Dies führt dann zu der leider allzuhäufig zu hörenden Aussage: "Ehe ich mich in das vorliegende Programm eingelesen habe, habe ich es neu geschrieben!"

Der zuletzt zitierte Satz hat seine Berechtigung nicht nur in den individuellen Programmierstilen, sondern auch in den unterschiedlichen Dokumentationsmethoden. Diesem Übel haben sich der Normenausschuß Informationsverarbeitung (Nl) und das Deutsche Institut für Normung e. V. (DIN) angenommen. In DIN-Normen haben Sie Richtlinien für die Gliederung und den Inhalt von Programmdokumentationen und Dateibeschreibungen festgelegt.

Angebote nicht vergleichbar

Warum Standardisierung? Wer Gelegenheit hatte, zahlreiche EDV-Umstellungen und Installationen zu beobachten, für den hat sich die Frage nach dem Zweck der Standardisierung beantwortet.

Da ist etwa der Inhaber eines mittelständischen Unternehmens, der mit der Hardware eine Software geliefert bekam, deren Arbeitsergebnisse er sich "ganz anders vorgestellt hat". Die Ursache für diese Enttäuschung liegt vorwiegend in der Tatsache, daß Anbieter und Käufer gleiche Worte für unterschiedliche Begriffe verwandten - und umgekehrt. Damit waren für den Unternehmer die Angebote weder untereinander noch gegenüber seinen eigenen Vorstellungen vergleichbar.

Der Leiter einer EDV-Abteilung tragt sich mit dem Gedanken, eine anstehende Aufgabe mit einer Fremd-Software zu lösen. Aus der großen Zahl der Angebote fallen zunächst die heraus, die nur auf einer bestimmten Hardware oder unter einem speziellen Betriebssystem laufen. Aus den dann verbleibenden Angeboten scheiden wiederum die aus, die entweder firmenspezifische Sonderheiten nicht erfüllen oder aber mit nicht geforderten Sonderheiten das System belasten.

Glaubt er nun, das Software-Paket gefunden zu haben, das seinem Anforderungspaket am nächsten kommt und das mit der firmenspezifischen Anforderung durch eigene Programmierer ergänzt werden soll, so scheitert dies dann zuletzt an nicht durchschaubaren Programmstrukturen und den unvollständigen Dokumentationen. Verärgert über die verlorene Zeit, laßt er dann doch die Programme im eigenen Hause schreiben.

Letztes Beispiel: Ein Unternehmen ohne eigene Programmabteilung hatte die gesamte Software als ein Standardpaket von einem Softwarehaus bezogen. Während in den ersten Jahren die Programmpflege durch den Lieferanten gewährt war, war plötzlich keine Betreuung durch den Anbieter zu erhalten. Der Grund dafür war, daß der letzte Mitarbeiter der Programmentwicklung das Softwarehaus verlassen hatte. Nachfolger waren nicht gewillt oder nicht in der Lage, sich in die alten Programme einzuarbeiten.

Aus diesen wenigen Beispielen lassen sich die Gründe für eine Standardisierung der Software ableiten:

þDie Software wird für den zukünftigen Anwender transparent und damit mit anderen Produkten vergleichbar.

þDie Software wird übertragbar von einer EDV-Anlage auf eine andere.

þDie Software wird unabhängig von den Programmierern, die sie entwickelt hatten, und kann dadurch über lange Zeitraume gepflegt werden.

þDie Software ist schneller verfügbar, da sie "vom Lager" abgerufen werden kann.

Standardisierung gleich Rationalisierung

Die Standardisierung der Software zahlt sich für den EDV-Anwender zweimal aus: bei der Anschaffung beziehungsweise Erstellung der Software; bei der Pflege und Wartung.

Der Einsatz von Standardprogrammen verlangt vom Anwender die Bereitschaft, sich im begrenzten Maße an die vorgegebene Lösung anzupassen und gegebenenfalls Abstriche von seinen Vorstellungen vorzunehmen. Dies ist eine normale Folge der meisten

Rationalisierungsmaßnahmen. Für die EDV-Anwender ist dies sicherlich keine neue Erfahrung, denn sie selber schicken oft Briefe in die Welt, die beginnen: "Weil wir auf EDV umgestellt haben, können wir nicht mehr wie bisher..." Mit der Kompromißbereitschaft erkauft sich der Anwender eines guten Standardprogrammes - sofern er sich vergewissert hat, daß er nicht zu den ersten zehn Anwendern gehört - folgende Vorteile:

þKostenersparnis bei der Einführung einer neuen EDV-Anwendung. Standardprogramme kosten viel weniger als der zehnte Teil ihrer Erstellungskosten.

þUmstellungen sind schneller realisiert, da die personellen Engpässe für Systementwicklung, Codierung und Test fortfallen.

þUmstellungen werden sicher durchgezogen, da Standardprogramme besser ausgetestet sind. Diese Aussage trifft jedoch nur dann zuverlässig zu, wenn die Programme schon öfter eingesetzt wurden (siehe oben).

Unwidersprochen ist heute die Aussage, daß 60 Prozent und mehr die vorhandenen Programmiererkapazität mit Wartungs- und Pflegearbeiten belegt ist. In absoluten Zahlen bedeutet dies für die Bundesrepublik, daß rund 120 000 bis 150 000 Programmierer mit Software-Wartung beschäftigt sind. Eine Reduzierung dieses Einsatzes um mindestens zehn Prozent ließe sich erreichen, wenn sich Programmierung und Dokumentation an allgemein anerkannten Standards und Normen orientieren wurden. Dieser Rationalisierungseffekt wäre nicht nur auf volkswirtschaftlicher, sondern auch auf betriebswirtschaftlicher Ebene meßbar.

òRobert Hürten ist Geschäftsführer der Gnosis Gesellschaft für normierte Organisations-Software und Informationsstandards. Seeheim-Jugenheim.