Programmiersprachen formen Stabsstellen um!

19.09.1980

Roland Mittermeir Institut für Digitale Anlagen, TU Wien

Die Stabsstelle wird in Anlehnung an Dr. Gablers Wirtschaftslexikon als, der Unternehmensleitung unmittelbar unterstellte, zur Beratung und Führungsarbeit heranzuziehende Abteilung" definiert. Wir wollen den Inhaber einer solchen Stabsstelle kurz als "Informationsassistenten" bezeichnen. Dieser Ausdruck erscheint treffend, weil wir uns ausschließlich mit dem Aspekt der Informationsbeschaffung und Informationsaufbereitung zur Entscheidungsfindung aus dem in der Praxis doch viel umfassenderen Aufgabenbereich der Stabsstelle befassen wollen.

Will man die Frage nach wünschbaren Trends bei der Entwicklung neuer Programmiersprachen etwas gehässig beantworten, müßte man sagen, "am besten gar keine". Diese negative Einstellung hat gute Gründe. Sie hegen vor allem in den immensen Kapitalwerten, die auf Anwenderseite in den herkömmlichen Sprachen sowohl in Form von Software wie auch in Ausbildungsinvestitionen hegen. Damit ein neuer Beitrag zum bereits existierenden "Sprachbabylon" unter diesen erschwerenden Bedingungen reüssieren kann, muß er zwei Bedingungen erfüllen: signifikante Produktionsvorteile versprechen und zu existierenden Systemen aufwärtskompatibel sein. Neben den prozeduralen Sprachen (high level languages), deren Haupteinsatzgebiete in der Erstellung von Betriebssoftware und technischer Software hegen, werden diese Bedingungen von den nicht-prozeduralen Sprachen (oft als very high level languages bezeichnet) erfüllt.

Ungleich den prozeduralen Sprachen, die eine kochrezeptähnliche Umgangsweise verlangen, ist bei dieser Sprachform eine dermaßen detaillierte Beschreibung des Handlungsablaufes im Computer nicht nötig. Im Idealfall würde ein Programm in einer nichtprozeduralen Sprache aus einer rein statischen Beschreibung des erwünschten Ergebnisses bestehen. Da zu einer vollständigen Spezifikation jedoch nicht nur eine Beschreibung des Ergebnisses gehört, sondern auch der Ausgangszustand angegeben werden muß, ist hier bereits eine Transformation impliziert und damit auch schon der erste Schritt in Richtung Prozeduralität getan. Die meisten der "nichtprozeduralen" Sprachen erreichen aber auch dieses Niveau bei weitem nicht, sondern stellen vielleicht lediglich sehr einfache Notationen für die Behandlung von Schleifen oder Datengruppen zur Verfügung. Es wäre deshalb wohl auch exakter von "very high level languages" zu sprechen, doch ist diese Terminologie leider auch nicht sehr deskriptiv.

Zu Beginn wurde der Informationsassistent als Inhaber einer Stabsstelle definiert, deren Aufgabe überwiegend in der Beratung und Information der zugehörigen Linieninstanz liegt. Diese Fähigkeit wird sowohl in der Vorbereitung von immer wiederkehrenden Entscheidungen, aber auch im Zusammentragen und Auswerten von Informationen für Nicht-Routine-Entscheidungen hegen Es soll dabei angenommen werden daß das für derartige Entscheidungen nötige Datenmaterial in der Unternehmung in Rohform vorliegt oder beschaffbar ist. Weiter soll angenommen werden, daß die entsprechenden Entscheidungsmodelle von der zugehörigen Fachwissenschaft angeboten werden und den Stabsassistenten bekannt sind.

Es gilt also lediglich, die vorhandenen Rohdaten in eine für Entscheidungsmodelle verwendbare Form aufzubereiten und diese Modelle sodann - gegebenenfalls nach ihrer Programmierung am Computer zu rechnen.

Handelt es sich dabei um die Entscheidungsvorbereitung für Routineprobleme, so kann angenommen werden, daß sowohl für die Aufbereitung der Rohdaten wie auch für das Entscheidungsmodell selbst geeignete Computerprogramme vorliegen oder daß solche Programme in einer anwendungsorientierten Spezialsprache relativ kurzfristig erstellt werden können. Für neuartige Problemstellungen kann damit im allgemeinen jedoch nicht gerechnet werden, und es stellt sich nur die Alternative, auf die entsprechende Information zu verzichten oder die zur Entscheidungsvorbereitung nötigen Programme selbst zu schreiben. Es gilt also, die in vielen derartigen Fällen sehr hohen Kosten der Informationsbescheffung den Opportunitätskosten der nicht vorhandenen Informationen gegenüberzustellen und aus diesen meist nur schwer quantifizierbaren Größen eine Entscheidung abzuleiten. Diese Entscheidungsfindung kann sehr oft dadurch präjudiziert werden, daß der zur Verfügung stehende Zeitraum zum Abfassen und Austesten eines konventionellen Programms nicht mehr ausreicht. Unabhängig davon, wie diese Meta-Entscheidung - informationsgestützte Entscheidungsfindung oder Verzicht auf die an sich vorhandenen Rohdaten und intuitive Entscheidung - ausfällt, der Informationsassistent wird in keinem Fall voll befriedigt sein, denn der Verzicht auf eine quantitativ abgestützte Entscheidungsvorbereitung ist wider seine Berufsethik.

Durch die kompakte Notation wird der Zeitaufwand für die Programmerstellung dermaßen reduziert, daß ein Informationsverzicht aus Zeitgründen weitgehend ausgeschlossen werden kann Dies gilt nicht zuletzt auch deshalb, weil durch die geringere Chance Fehler zu machen, die Programm-Testphase drastisch verkürzt werden kann.

Es ergibt sich nun die Frage wie weit derartige Verbesserungen tatsächlich wirksam werden können, insbesondere ob man damit die Stelle des Informationsassistenten nicht überhaupt einsparen könne. Letzteres scheint meines Erachtens zu weit gegangen zu sein, da selbst bei sehr einfachen Programmiersprachen die Belastung des Entscheidungsträgers durch deren Erlernen und ihre Anwendung als zu hoch angesehen werden muß.

Lediglich in jenen Fällen, wo sich der Informationsassistent selbst wieder eines EDV-Fachmannes zur Lösung seiner Programmieraufgaben bedient wird dieser zusätzliche Schritt überflüssig werden. Damit tritt aber nicht nur eine weitere Beschleunigung der Informationsgewinnung ein, sondern die bei der Zusammenarbeit von Fachleuten unterschiedlicher Gebiete auftretenden Kommunikationsverluste unterbleiben.

Insbesondere ist zu prüfen, ob Sprachen, über deren Prinzipien man sich bereits Anfang der siebziger Jahre (vor allem in Artificial Intelligence-Kreisen) im klaren war, innerhalb der kommenden Dekade den Durchbruch zur kommerziellen Anwendung schaffen werden.

Hauptgrund, warum derartige Sprachen bisher nicht reüssieren konnten, ist wohl ihr Mangel an effizienter Nutzung der Hardware. Gelang es erst vor kurzem, kaufmännische Anwender zu überzeugen, daß Programme, die in höheren Programmiersprachen geschrieben wurden, nicht notwendigerweise ineffizienter sind als Assemblerprogramme und daß etwaige Nachteile in der optimalen Maschinenausnutzung durch höhere Programmierer-Produktivität mehr als ausgeglichen werden, ist es schwer, diesen Leuten zu sagen, sie können noch weiter auf eine effiziente Auslastung ihrer teuren Anlagen zu Gunsten einer "besseren" Sprache verzichten. Betrachtet man jedoch die rasante Entwicklung auf dem Gebiet der Computer-Hardware mit dem damit einhergehenden Preisverfall und stellt diese Entwicklung der stagnierenden Software-Produktivität gegenüber, müssen Fragen nach einer möglichst effizienten Hardware-Nutzung in Zukunft Fragen einer effizienten Nutzung des Humankapitals weichen.

* Auszug aus einem Vortrag auf de Fachtagung "Informationssysteme de 80er Jahre" vom 8. bis 12. September in Linz.