Anwender wollen 4GL-Produkte mit mehr Komfort, größerer Funktionalität und Integrationsfähigkeit:

Der Mangel an Akzeptanz ist nicht mehr das Problem CW Bericht

24.03.1989

die 4GLs ist das Akzeptanzproblem weitgehend gelöst." Was Walter Boltz, Geschäftsführer der Wiener Diebold-Niederlassung, hier gelassen ausspricht, scheint fürwahr ein großes Wort.

Doch der Widerspruch aus den DV-Abteilungen bleibt aus: Nicht an Akzeptanz, so die Anwender, sondern an Funktionalität und Integrationsfähigkeit mangelt es den Software-Tools.

Daß sie anfangs massive Probleme mit der Akzeptanz der "Fourth Generation Languages" hatten, streiten die DV-Manager keineswegs ab. So erinnert sich beispielsweise Udo Hey, DV-Leiter bei der Staff GmbH & Co. KG in Lemgo: "Natürlich haben wir in der Anfangsphase Akzeptanzprobleme gehabt; auch ich persönlich habe mich damit schwer getan."

Die Ursache dieser Probleme sieht Hey in der Struktur der 4GLs: "Das ist einfach anders als das, was man vorher kannte; und man muß eben umdenken." Neulinge täten sich deshalb leichter mit den nicht-prozeduralen Programmiersprachen als beispielsweise langjährige Cobol-Experten.

Zustimmung von seiten des Münchner Unternehmensberaters Josef Kraus: "Die Cobol

Programmierer kommen relativ schnell mit den Fourth-Generation-Systemen zurecht, wenn diese prozedurale Elemente enthalten, also Cobol-ähnlich sind. Geraten sie aber an Produkte, wo sie mit dem Prototyping beginnen müssen, dann haben sie ein Problem mit dem Denkansatz. Ich habe allerdings die Erfahrung gemacht, daß junge Mannschaften keine Schwierigkeiten mit der Akzeptanz haben."

Anderer Ansicht ist hier Erwin Schmiedt, Leiter der Programmierung bei der Überlandwerk Nord-Hannover AG in Bremen: "Das gilt nicht für funktionsfähige Sprachen wie zum Beispiel Natural 2." Richtig sei jedoch, "daß sich Nachwuchsprogrammierer erheblich schneller in Natural einarbeiten können als in PL/ 1 oder Cobol."

Die anfangs recht skeptische Beurteilung der sogenannten Software-Werkzeuge durch Anwender und Unternehmensberater ist darauf zurückzuführen, daß der erhoffte Produktivitätsgewinn einem real existierenden Verlust an "künstlerischer Freiheit " gegenübersteht. Im Klartext: Die Kreativität hört da auf, wo die Funktionalität des 4GL-Produkts endet. Kraus verweist auf die emotionalen Konsequenzen: "Früher waren die Entwickler quasi freie Künstler; sie haben sich nicht einschränken lassen bezüglich dessen, was sie tun und wie sie es tun. Und heute ist das alles etwas straffer organisiert. Es gibt ganz klare Vorgaben von oben - letztendlich auch deshalb, weil sich das Management mit der Information als Unternehmensressource auseinandersetzt. "

Nach Ansicht vieler leitender DV-Mitarbeiter ist es die Einsicht in den Nutzwert der nicht-prozeduralen Sprachen, die als Katalysator für die Akzeptanz dieser Produkte dient. Freut sich Hey: "Mittlerweile ist dieses Thema bei uns gelaufen; das 4GL ist auf breiter Ebene akzeptiert, denn die Vorteile liegen nun einmal auf der Hand".

Dazu Kraus: "Es ist ja heute nicht mehr so, daß jeder in der Entwicklungs-mannschaft unbegrenzt viel Zeit hat. Die meisten sind doch zu hundertfünfzig Prozent verplant. Da ist einer froh, wenn er ein mächtiges Werkzeug hat, so daß er seine Arbeit besser tun kann."

Resümiert Helmut Ulrich, Referatsleiter Systementwicklung für den Bereich Methoden, Standards und Technologieeinsatz bei der Schering AG in Berlin: "Es gibt immer Kollegen, die innovationsfreudiger sind als andere; aber auch die konservativeren Kollegen ziehen mit, wenn ein Werkzeug gut und nützlich ist."

Solche Einsicht kommt jedoch selten von ungefähr. Bei Schering war laut Ulrich "ein geballter Schulungsaufwand" notwendig, damit "heute keine sichtbaren Widerstände mehr bestehen".

Über ähnliche Erfahrungen berichtet Bruno Tillmann, verantwortlich für die Anwendungsentwicklung im Teilbereich Geldsysteme bei der Kölner Colonia Versicherungs AG: "Was die Akzeptanz angeht, so haben wir durchaus einen zähen Prozeß hinter uns, der jedoch Anfang der 80er Jahre über die gesamte Entwicklungsmannschaft von über 100 Leuten im weitesten Sinne abgeschlossen wurde. Das ist eine Frage der Schulung und sicherlich auch des Berufsbildes. "

"Von je her", fährt der Entwicklungsleiter fort, "haben wir hier den Organisations-programmierer; wir trennen also nicht zwischen Planung und Software-Entwicklung." Durch dieses Berufsbild bedingt, komme jeder Programmierer mit der planerischen Komponente der Software-Entwicklung in Berührung und erlebe am eigenen Leib deren Auswirkungen im Hinblick auf Produktivitätserfolge, Langlebigkeit, Strukturverbesserung, Flexibilität sowie Wartbarkeit.

Allerdings ließe sich die Akzeptanz beträchtlich steigern, wenn die Software-Entwicklungswerkzeuge tatsächlich den Ansprüchen der Benutzer gerecht würden. Klagt Tillmann: "Wenn der Entwickler es gelöffelt hat, auf diese Weise zu arbeiten, dann fehlen ihm im Grunde genommen die mächtigen Tools, die ihm die Arbeit wirklich abnehmen." Nach Möglichkeit, fordert der Anwender, müssen diese Werkzeuge alle aus einer Hand kommen: "Das sollte aus einem Guß sein, und in der Mitte muß ein Dictionary stehen."

Auch der Wiener Diebold-Manager Boltz beklagt den Etikettenschwindel, unter dem die Akzeptanz der Software-Tools oft zu leiden hat: "Auf der Marketingseite wird hier mitunter viel Schindluder getrieben; da werden Produkte als Sprachen der vierten Generation bezeichnet, die bei ernsthafter Analyse keineswegs auch nur annähernd den Komfort und die Funktionalität anderer Produkte haben. Das liegt daran, daß es weder eine Standardisierung noch einen branchenüblichen Funktionsumfang gibt."

Die 4GL-typische Klippe der Overhead-Erzeugung will der DV-Leiter Hey umschiffen, indem er von seinen Mitarbeitern detailliertes Know-how im Bereich der maschinennahen Programmiersprachen fordert: "Ich lege nach wie vor Wert darauf, daß die Anwendungsentwickler und Organisationsprogrammierer fundierte Assembler-Kenntnisse haben, damit sie eine Vorstellung davon bekommen, was sie möglicherweise anrichten. Mit einer Sprache der vierten Generation kann man, wenn man sie nicht richtig einsetzt, viel Last auf die Mühle bringen "

Entschiedene Vorbehalte haben eine Reihe von DV-Managern dagegen, 4GL-Produkte als Enduser-Tools einzusetzen. Kategorische Ablehnung zum Beispiel von Gerhard Hipp, dem Leiter der Qualitätssicherung bei der Dresdner Bank in Frankfurt: "4GL-Produkte gehören in die Hand von Profis."

Auch der Unternehmensberater Kraus relativiert diesbezügliche Marketingparolen der 4GL-Anbieter: "Das Thema ist etwas überbewertet worden. Erstens hat man den Begriff Endanwender nicht richtig definiert; denn ein Endanwender ist eigentlich jeder, der an Informationen heran will, ob er nun Programmierer oder Fachbereichsmensch ist. Zweitens ist der Endanwender heute nicht in der Lage, eigene Programme zu schreiben - zumindest nicht effiziente."

Tillmann widerspricht hier: "Wir haben Endbenutzer, die die Datenverarbeitung so professionell beherrschen, daß sie Focus, AS und ähnliche Produkte einsetzen können. Die Fachbereiche greifen auf Datenkonserven zu und fahren ihre Anwendungen, von denen wir gar nichts wissen; allerdings arbeiten sie auf Datenextrakte - nicht gegen die echten Daten."

Akzeptanzprobleme, die für die Programmiersprachen der vierten Generation als gelöst gelten, treten beim Einsatz integrierter Anwendungsentwicklungssysteme oft erneut zu Tage In diesem Zusammenhang sprach der Hamburger Unternehmensberater Frank Dörfel auf dem diesjährigen Online-Kongreß von den Befürchtungen der Programmier, "wenn schon nicht überflüssig, so doch ein wenig flüssig zu werden", beziehungsweise "sich in einen Bestandteil der Software-Entwicklungs-maschinerie zu verwandeln."

Die Widerstände älterer Programmier gegen CASE gründen meist in der konkreten Angst um den Arbeitsplatz. Erläutert Walter Boltz: "Absolut gesehen, wird in der Industrie der Bedarf an Software-Entwicklern konstant steigen; er wird sich jedoch vom reinen Programmierer zum Analytiker verschieben. Und das kann für den einen oder anderen schon ein Problem sein."

Fazit des Managementberaters: "Es gibt sehr wohl Widerstände auf seiten gestandener Cobol-Programmierer bei der Einführung solcher Systeme. Aber man muß als Verantwortlicher auch bereit sein, Ärger zu akzeptieren."

Dörfel will neue Techniken keinesfalls gegen den Widerstand der Entwicklungsabteilung durchdrücken; andernfalls stehe der Produktivitätsfortschritt auf dem Spiel. Dörfel: "Entwickler sind clevere Leute; die finden jedes Schlupfloch, das das Werkzeug ihnen läßt. Wenn es nicht gelingt, eine breite Basis zu schaffen, werden diese Hilfsmittel noch lange ein kümmerliches Dasein fristen."