Die Hardwareleute sind bei Klagen über ungenügende Produktivität kaum angesprochen. Ständige Verbesserungen der Kosten-Effizienz sind ein Beweis für den Einfallsreichtum im Entwurf und in der Produktion von DV-Systemen. Da es aber an allen Ecken und Enden an der Software zu fehlen scheint, steht diese im Brennpunkt um eine höhere Produktivität in der Datenverarbeitung.

Im Zusammenhang mit der Erzeugung und Anwendung von Software lassen sich die Produktivitätsfragen drei deutlich getrennten Aktivitäten zuordnen. Die erste gilt dem Prozeß der Entwicklung und Implementierung von Software. Der zweite Produktivitätsaspekt steht im Zusammenhang mit der Betriebs- und Wartungsfähigkeit der Software, nachdem diese fertig vorliegt. Ein dritter Aspekt betrifft die Leistung der Software/Hardwarekombination und beleuchtet die Produktivitätsfrage vom konventionellen Standpunkt einer Verbesserung der Kosten pro Einheit aus.

Alle drei Aspekte sind natürlich miteinander verflochten, doch sollten sie zur Steigerung der Gesamtproduktivität zuerst einzeln betrachtet werden.

Zählen nur Zeitvergeudung

Das Problem besteht in der Messung der Produktivität in einem sich rasch wandelnden Umfeld. Mit dem Zahlen und der Mittelwertbildung der erzeugten Codezeilen als Mittel zur Gewinnung einer Produktivitätskennzahl wird eine Menge Zeit vergeudet. Jedoch: Die von einem Programmierer erzeugten Codezeilen sind ebensowenig eine Kennzahl für die Produktivität wie es der Betrag ist, der für den Energieverbrauch von einer Kilowattstunde zum Betrieb des Rechners entrichtet werden muß.

Für die Produktivität gibt es eine ganze Reihe von Definitionen. Danach wird die Produktivität etwa durch das Verhältnis von Output zu Input bestimmt, wobei der Input Personal, Kapital, Betriebsmittel und Energie umfaßt. Und die wichtigsten Quantifizierungsgroßen, die für einen aufgewandten Betrag in den Output eingehen, sind:

- Stückkosten (etwa einer Rechnung oder eines Barschecks),

- Umschlagzeit für eine Anforderung,

- Termin-Einhaltung,

- Relevanz der gelieferten Informationen,

- Zahl der Benutzerbeschwerden,

- Betriebszeit des Rechners,

- Wiederholungszeit,

- Mittlere Online-Antwortzeit,

- Dauer des Rechnerausfalls.

Hat man diese Faktoren entsprechend gewichtet, kann ein Produktivitätsindex als Funktion dieser Messungen berechnet werden, der dann zur Kontrolle der DV-Leistung und ihrer Verbesserung dient.

Hier aber ist ein guter Rat angebracht. Rechneranwendungen haben die Tendenz, im Laufe der Zeit immer komplexer zu werden. Einmal, weil mehr Verarbeitungsdetails darin eingehen (beispielsweise aus Gründen des, Datenschutzes, der Revision und Wiederherstellung) oder weil von der Datenverarbeitung immer mehr verlangt wird (durch neue Gesetze, Formulare etc.). Die ausgegebenen Berichte sind daher nach einer gewissen Zeit nicht mehr identisch, so daß beim direkten Vergleichen Schwierigkeiten auftreten.

Der beinahe verzweifelte Appell, bei der Schließung der Produktivitätslücke in der Systementwicklung und im Systembetrieb mitzuhelfen, hat bei Lieferanten von Hardware und Software keinen Eindruck gemacht. Kein Wunder daß die Fachzeitungen und zeitschriften mit Anzeigen gespickt sind, mit denen EDV-Berater und andere Produktivitätsapostel die DV-Benutzer zu erreichen versuchen. Eine Durchsicht der jüngsten amerikanischen Fachpresse ergab die folgenden Versprechungen seitens der Inserenten:

- Verkürzung der Programmentwicklungszeit um bis zu 75 Prozent;

- Produktivitätsteigerung der Programmierer um bis zu 75 Prozent;

- Einsparung des Entwicklungsaufwands um 54 Prozent und des Wartungsaufwands um 70 Prozent;

- Produktivitätssteigerung der Programmierer um 40 Prozent, Produktivitätssteigerung durch verbesserte Programmierung um 25 bis 40 Prozent;

- Produktivitätssteigerung bei der Anwendungsentwicklung von zwei zu eins bis zu 20 zu eins;

- Produktivitätssteigerung der Programmierer um 21 Prozent und Erfüllung der Zeitvorgabe in 94 Prozent der Zeit;

- Vorlage der Ergebnisse in 1/5 der Zeit bei einer Produktivitätssteigerung von 400 Prozent;

- Produktivitätssteigerungen von durchschnittlich 160 Prozent.

Wie man sieht, werden die Produktivitätsversprechungen mit einer Vielzahl von Funktionen verknüpft, unter anderem mit der Produktionsleistung, den Terminen und der Wartung.

Auch die Quantifizierungsgrößen werden gemixt, da in manchen Inseraten von Steigerungsmöglichkeiten und in anderen von möglichen Reduzierungen einer Variablen die Rede ist. Die Größen hängen natürlich nach der Formel P = 100/R(1-R) zusammen, worin P die prozentuale Verbesserung und R die erzielbare Reduzierung darstellt. Mit anderen Worten: Senkt man den Arbeitsaufwand um 25 Prozent beziehungsweise um 75 Prozent, so hat des eine Produktivitätssteigerung von 33 Prozent beziehungsweise von 300 Prozent zur Folge.

Man könnte nun aus den Zusagen der Anbieter schließen, daß die Rettung aus der Produktivitätskrise unmittelbar bevorsteht. Tatsächlich ist es ja möglich, die Produktivität einer bestimmten Tätigkeit des gesamten Anwendungszyklus zu steigern und es ist darüber hinaus vielleicht sogar möglich, die Produktivität in starkem Maß zu steigern, falls die betreffende Anwendung gewissen begrenzten Kriterien und Nebenbedingungen genügt. Doch leider ist die Sache nicht so einfach.

Nehmen wir drei repräsentative Beispiele und analysieren wir die potentielle Produktivitätssteigerung, die mit den Mitteln der heutigen Technologie erzielt werden kann.

Als erstes wählen wir einen ganz einfachen Fall. Ein Unternehmen braucht ein Buchhaltungsprogramm und steht vor der Frage des Kaufs oder der Entwicklung im Haus. Nun haben sich derartige Systeme soweit entwickelt, daß sie dem neuesten Stand der Technik entsprechen und praktisch als Paket "von der Stange" lieferbar sind. Vom wirtschaftlichen Standpunkt aus sind die Alternativen völlig klar. Der Kauf eines Systems spart die Kosten der Entwicklung im Haus ein und vermeidet die Risiken, die mit einem solchen Softwareprojekt und allen seinen wirtschaftlichen Problemen verbunden sind. Außerdem steht das gekaufte System sofort zur Verfügung. Schließlich wird das System durch ein Vertragsunternehmen gewartet, so daß sich die Wartungskosten auf viele Anwender verteilen.

Steht die Eignung der fertig gekauften Software für das Unternehmen fest, wird eine maximale Produktivität durch die Kaufoption erzielt. Unter diesen Umständen gibt es keine bessere Lösung für eine kosteneffiziente Verarbeitung.

Betrachten wir ein zweites Beispiel. Der Benutzer will eine Datei führen, deren Daten von Transaktionen herrühren, die von Zeit zu Zeit vorkommen. Er braucht eine ganze Reihe periodischer Berichte, die den Datei-lnhalt wiedergeben, außerdem will er gelegentlich Abfragen machen. Somit sind die DV-Funktionen recht einfach und entsprechen üblichen Anforderungen.

So wie das Problem dargestellt ist, kommt es bei Endbenutzern recht oft vor. Außerdem ist es eine allgemeine Aufgabe, wie sie bei vielen kaufmännischen Tätigkeiten gestellt wird, bei denen bis jetzt noch keine Rechner eingesetzt worden sind. Gerade in solchen Fällen schrecken Unerfahrene oft vor dem Einsatz eines Rechners zurück, weil sie einen schwierigen Zugriff befürchten oder sich nicht der Tatsache bewußt sind, daß Rechner leicht zur Verarbeitung solcher Daten verwendet werden können.

Außerordentlich produktive und kosteneffiziente Lösungen solcher Probleme in Gestaltkompakter Systeme werden von kommerziellen Online-Diensten im Teilnehmerbetrieb angeboten. Dazu braucht man ein Standard-Datenbankverwaltungsystem und eine entsprechende Datenbanksprache. Die Produktivitätssteigerungen können erstaunlich sein, wenn die Ergebnisse durch Eingabe eines Problems anstatt durch Programmieren einer Lösung erzielt werden.

Das bringt uns zum dritten und schwierigsten Problem, nämlich dem Entwurf und der Implementierung einer neuen Anwendung, für die es weder ein fertiges Anwendungsprogrammpaket, noch ein Entwicklungssystem zur effizienten Implementierung gibt. ln diesem Fall müssen die klassischen Lebenszyklus-Aktivitäten einer Anwendung durchlaufen werden, beginnend mit der Aufgabenstellung über die Detail- und Übersichtsdiagramme, die hierarchischen Strukturübersichten, den Detailentwurf und die Programmierung, über das Testen und die Dokumentation bis hin zum Betrieb in der Praxis mit schließender Wartung (Programmpflege). Dazu sollten die besten Vorgehensweisen und Verfahren gewählt werden, die eine bewährte Softwaretechnik zu bieten hat.

* Werner L. Frank ist Executive Vice-President der lnformatics, Inc. in Woodland Hills, Kalifornien.

Aus Computerworld vom 27. April 1981, S. 45, 52 Übersetzt von Hans J. Hoelzgen, Böblingen.