Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Info-Center sollte Betroffene langsam an neue Tools heranführen:


01.11.1985 - 

Know-how-Defizit verprellt User und Experten

Sprachen der 4. Softwaregeneration setzen sich nur zögernd in Deutschland durch. Die Euphorie der ersten Jahre ist einer Katerstimmung gewichen. Der Autor dieses Beitrags zeigt dominante Problemfelder auf, die zu dieser Entwicklung geführt haben, und gleichzeitig Strategien, um die Mißerfolge früherer Jahre zu vermeiden.

Ende der 70er Jahre wurde die deutsche DV-Landschaft um eine neue Softwaregeneration bereichert. Neue Begriffe wie Sprachen der 4. Softwaregeneration, Very High Level Languages (VHLL) oder Endbenutzersprachen wurden geprägt. Man versprach sich, mittels dieser "neuen" Sprachengeneration die Softwarekrise - die sich in Form eines unüberschaubaren Anwendungsstaus und der Bindung immer größerer Programmierkapazitäten für Wartung und Pflege manifestierten, zu lindern oder gar zu überwinden.

Euphoriker prophezeiten damals ein baldiges Ende der Knechtschaft des von Prioritätätenkatalogen und hochnäsigen DV-Spezialisten frustrierten EDV-Laien. Der Endbenutzer in der Fachabteilung sollte nun endlich in die Lage versetzt werden, aktiv am Prozeß der Systementwicklung zu partizipieren und seine originären Probleme ohne DV-Spezialwissen selbst zu lösen.

---------------

Kurzfristige Planung provoziert eine Isolierung der Tools

---------------

Auch auf seiten der DV-Manager bestand eine große Aufgeschlossenheit gegenüber diesen neuen Werkzeugen. Sie ließen Endbenutzersysteme installieren, in der Hoffnung darauf, die Unzufriedenheit in der Fachabteilung aufgrund unerfüllter, aber berechtigter Anwenderwünsche dämpfen zu können. Im Praxiseinsatz traten jedoch Probleme auf, die während der Auswahl und Testinstallation in dieser Dimension nicht erkannt wurden.

Vor allem folgende vier Problemfelder sind hier zu identifizieren:

- Monofunktionale statt multifunktionaler Sprachen

- Unkontrollierter Zugriff auf Produktions-DB statt auf Endbenutzer-DB

- Fehlende Unterstützung des Endbenutzers statt der Einrichtung eines Endbenutzer-Informations-Zentrums (Information Center)

- Nonhybride statt hybrider Sprachen

Die Endbenutzersprachen können funktional in zwei Kategorien eingeteilt werden. Zum einen sind dies monofunktionale Sprachen wie Abfragesprachen (SQL, Inquiry, Natural), Planungssprachen (APL, FCS/EPS ITS/73), Grafiksprachen (GDDM, Telegraph) und Statistiksprachen wie SPSS, zum anderen multifunktionale Sprachen für Abfrage, Planung, Grafik, Statistik, Erstellung und Erfassung von Datenbasen wie Nomad2, Focus, RamislI, AS oder SAS.

Monofunktionale Sprachen decken primär eine Funktion wie Abfrage (Query), Planung, Grafik oder Statistik ab. Dabei dienen diese Abfragesprachen der Selektion von Informationen bestehender Datenbasen.

Hier können entsprechend dem Informationsbedarf nach bestimmten Kriterien situativ Datenfelder miteinander kombiniert, analysiert und in Listform ausgedruckt werden. Planungssprachen dienen der Realisierung von Planungs- und Controllingaufgaben. Sie basieren in der Regel auf der Matrixlogik beziehungsweise -verarbeitung. Es können einzelne Spalten und Zeilen definiert und Elemente der Matrix für Beschaffungs-, Absatz- oder Finanzplanung gezielt verändert werden. So können problemlos Prognosen, Simulationen oder Szenarien entworfen und in allen erdenklichen Variationen durchgerechnet werden.

Die DV-Verantwortlichen entschieden sich häufig zugunsten einer dieser monofunktionalen Sprachen. Zum Einsatz kamen solche Tools, von denen kurzfristig das größte Problemlösungspotential erhofft wurde. Vor allem Abfragesprachen wurden präferiert, um ausschließlich lesende Zugriffe auf bestehende Datenbasen zu ermöglichen. Nach einer gewissen Zeit entstand jedoch die Notwendigkeit, weitere Funktionen wie Planung oder Grafik DV-technisch zu unterstützen. So wurde neben der Abfragesprache ein Planungs- und/ oder Grafikpaket installiert.

Durch diese kurzfristige, unkoordinierte Toolplanung koexistieren nun verschiedene, isolierte monofunktionale Sprachen in den Unternehmungen. Besteht die Notwendigkeit, mehrere Funktionen zu nutzen, so ist der Anwender gezwungen, verschiedene Sprachen mit unterschiedlichen Logiken zu erlernen.

Bei einem Funktionswechsel muß er das System verlassen und sich in einem neuen System wieder anmelden. Unter Umständen sind dem Planungs-, Statistik- und/oder Grafiksystem bereits vorhandene Daten mittels Brückenprogrammen oder gar erneuter manueller Eingabe zügänglich zu machen, obwohl sie der Abfragesprache bereits problemlos zur Verfügung stehen.

Den Anwender packt in einer solchen Situation häufig der Frust, und er kehrt reumütig zu Papier und Griffel zurück. Die DV-Verantwortlichen müssen hier erkennen, daß die Toolgrenzen solcher isolierten monofunktionalen Systeme sehr schnell sichtbar werden.

Multifunktionale Sprachen vermeiden hingegen die Probleme der Syntax-, Logikvielfalt und mangelnden Integrationsfähigkeit. In ihnen vereinigen sich mehrere Funktionen wie Abfrage, Planung, Statistik, Dateierstellung/-erfassung und in einigen Fällen sogar Textverarbeitung.

Es sind integrierte Systeme, in denen eine einheitliche Terminologie (Syntax) Verwendung findet. Der Endbenutzer braucht nicht für jedes Anwendungsgebiet eine spezifische Sprache zu lernen, sondern kann sich innerhalb dieser einheitlichen Systemumgebung bewegen. So besteht für den User die Möglichkeit, bestehende Datenbestände zu selektieren oder eigene anzulegen, die gewonnenen Daten ohne Brückenprogramme oder erneute Eingabe statistischen Auswertungen zugrunde zu legen oder in Berichtsform aufbereitete Informationen mit (denselben) Parametern grafisch zu veranschaulichen. Diese Kategorie ist wegen der verschiedensten Vorteile wie Flexibilität, Endbenutzerfreundlichkeit Sprachmächtigkeit, Datenintegrität und hohe Produktivität am ehesten geeignet, sich unter strategisch langfristiger Perspektive zu etablieren. Hier werden die skizzierten Grenzen monofunktionaler Sprachen nicht evident.

Sprachen der 4. Softwaregeneration zeichnen sich durch ihre Zugriffsfähigkeit auf bestehende Datenbestände aus. Viele Unternehmungen kauften sich gerade wegen dieser Eigenschaft eine Endbenutzersprache. Sie glaubten, ohne Brückenprogramme und redundante Datenbestände die Informationsbedürfnisse der Anwender befriedigen zu können, und gestatteten ihnen den Zugriff auf Produktionsdatenbestände.

Die Art der Zugriffe von Endbenutzern unterscheidet sich jedoch fundamental von der bereits im Einsatz befindlicher operativer Anwendungssysteme. Operative Systeme verarbeiten in der Regel einzelne Sätze. Der Zugriff erfolgt über ein Schlüsselfeld in Form des Databasekey oder Ordnungsbegriffs. Auch bei der Selektion mehrerer Sätze bedient man sich im Dialog überwiegend dieses direkten Zugriffs.

Die Endbenutzer aus Revision, Marketing oder Finanzabteilung erstellen hingegen nicht diese operativen, sondern dispositive oder strategische Informationssysteme. Hier besteht die Notwendigkeit, die operativen Basisdaten situativ nach unterschiedlichsten Kriterien (also auch sequentiell nach Nichtschlüsselfeldern) zu selektieren oder den gesamten Basisdatenbestand in Form von Kennziffern zu strategischen Informationen zu verdichten.

Die heute überwiegend im Einsatz befindlichen Produktionsdatenbanken, die auf hierarchischen oder Netzwerkmodellen basieren, erlauben jedoch keine solch unkontrollierten, extensiven Zugriffe auf Nichtschlüsselfelder.

Aus diesem Grunde tritt bereits bei dem gleichzeitigen Zugriff nur weniger Benutzer auf große Datenbestände eine unzumutbar hohe Systembelastung auf. Die Erwartung einer direkten Datennutzung, die häufig ein Hauptkriterium für den Kauf eines Endbenutzersystems darstellte und sich für viele Unternehmungen während der Auswahlphase mit kleinen Testdatenbeständen zu bestätigen schien, konnte somit nicht erfüllt werden.

In diesem Zusammenhang ist jedoch zu betonen, daß dieses Problem nicht in der mangelnden Performancefähigkeit der Endbenutzertools begründet liegt. Ein gleicher sequentieller Zugriff mit einer Sprache der 3. Softwaregeneration, wie Cobol oder PL/ 1, führt zu einer ähnlich hohen Systembelastung und Responsezeit.

Manche Unternehmungen reagieren auf diese Erkenntnis mit einer Verlagerung der Abwicklung von Endbenutzerapplikationen vom Dialog auf abendliche Batchprozesse. Der Anwender darf seine Applikationen lediglich auf Testbeständen formulieren. Die Produktionsabwicklung selbst erfolgt hingegen erst über Nacht im Batch.

Eine solche Lösung ist jedoch sowohl aus DV-technischer als auch aus fachlicher Sicht kaum zu rechtfertigen.

Technisch läßt sich durch die Verlagerung zwar tagsüber eine Beeinträchtigung der Dialoganwendungen vermeiden, die unverhältnismäßig hohe System- und damit Kostenbelastung im Batch bleibt hingegen weiterhin bestehen. Aus fachlicher Sicht ist eine solche Maßnahme ebenso suboptimal, da die Test- nicht die Produktionsumgebung widerspiegelt und aus diesem Grunde die erwarteten Ergebnisse von den tatsächlichen häufig divergieren.

Soll beispielsweise für Marketingzwecke eine bestimmte Zielgruppe von etwa 1000 Personen identifiziert werden, so kann aufgrund des Testbestandes keine Auswahl formuliert werden, die im Praxiseinsatz direkt zu der Selektion dieser gewünschten 1000 Personen (Sätze) führt. Das gleiche gilt für die Einteilung des Gesamtbestandes in etwa gleich große Zielgruppen.

Solche Auswertungen müßten nun in mehreren Batchläufen immer wie der mit neuen Selektionskriterien wiederholt werden, bis ein zufriedenstellendes Ergebnis erzielt werden kann. Dieses Time-lag kann der Endbenutzer jedoch nicht akzeptieren. Er fordert eine sekündliche Verfügbarkeit. Informationsbedarf und Bereitstellung dürfen nicht in einer solch eklatanten Weise auseinanderklaffen.

Der Einsatz einer Endbenutzersprache sollte deshalb mit der Einrichtung spezieller Endbenutzer-DBs einhergehen. Manche Systeme beinhalten bereits eine Datenbank, die auf die Bedürfnisse der Endbenutzer zugeschnitten ist. Diese Datenbanken basieren auf dem Relationenmodell und besitzen ein integriertes Data-Dictionary. In diese Datenbasis können nun Teilmengen der Produktionsbasisbestände und für dispositive Zwecke gezielt verdichtete Bestände einfließen.

Aufgrund der relationalen Eigenschaften der DB und der aggregierten Datenbasis können auf diese Weise Auswertungen in einem Bruchteil der ursprünglichen Zugriffszeiten realisiert werden. Das Time-lag zwischen Infobedarf und -bereitstellung und die hohe Systembelastung sind bei einer solchen Einsatzstrategie nicht mehr zu befürchten.

Es entstehen jedoch zusätzliche Spacekosten, die wegen der relationalen Speicherungsform über denen der Originalbestände liegen, sowie zusätzliche Ladezeiten und -kosten. Eine Entscheidung zugunsten des Einsatzes eines Endbenutzersystems muß diese Faktoren mit ins Kalkül einfließen lassen, um eine rationale Auswahl begründen zu können. Da viele Unternehmungen diese Kostenfaktoren nicht zugrunde gelegt haben, ist der anfänglichen Euphorie ein beklagenswerter Ernüchterungszustand gefolgt.

Der Einsatz des bereits gekauften Endbenutzersystems läßt sich nämlich unter Umständen wegen dieser unvorhergesehenen zusätzlichen

--------------

Time-lag-Verkürzungen ließen Kosten explodieren

--------------

Kostenfaktoren nun nicht mehr aufgrund quantifizierbarer Kosten/Nutzen-Relationen betriebswirtschaftlich begründen.

Der Einsatz neuer Tools bedarf der organisatorischen Einbettung dieser Werkzeuge in die Unternehmensstruktur. Auch dieser Tatsache schenken manche Unternehmungen nicht die erforderliche Beachtung. Endbenutzersprachen werden häufig ausgewählt, implementiert und dem Endbenutzer zur Verfügung gestellt. Diese Aktionen alleine reichen jedoch nicht aus, da für den Endbenutzer die Probleme nun erst beginnen.

Auch eine Sprache der vierten Softwaregeneration ist eine - wenn auch auf sehr hoher Ebene angesiedelte - Programmiersprache, an die der Anwender herangeführt werden muß. Fehlt jegliche Unterstützung von seiten der DV, so fühlt sich der Anwender aufgrund seines fehlenden Systemwissens überfordert und lastet sein Know-how-Defizit der

noch unbekannten Sprache an. Auf diese Weise können irreversible Akzeptanzbarrieren entstehen.

Eine einmalige Schulungsmaßnahme durch den Systemhersteller beziehungsweise -vertreiber ist hier häufig ebenso nicht zu empfehlen da solche Schulungsmaßnahmen aufgrund ihrer Allgemeingültigkeit für jegliche Art von Anwendungen nicht den spezifischen Einsatzspektren im Unternehmen Rechnung tragen können. Auch fehlt hier die anschließende Betreuung.

Der erfolgreiche Einsatz von Endbenutzersystemen ist meist nur durch die Einrichtung eines Endbenutzer-Informations-Zentrums (EIZ) zu gewährleisten. Dieser Instanz obliegt die Ausarbeitung und Durchführung von mehrstufigen, speziell auf die Probleme der jeweiligen Fachabteilung ausgerichteten Schulungsmaßnahmen, die Zurverfügungstellung der erforderlichen Datenbasis und die permanente Anwenderunterstützung und -betreuung.

Das EIZ hat dabei den DV-Markt zu beobachten und neue Endbenutzertools im Sinne einer evolutorischen Systemstrategie auszuwählen und einzuführen. Häufig sind die Akzeptanzprobleme auf seiten der Endbenutzer und eine unkoordinierte, inkompatible Toolvielfalt auf das Fehlen dieser Instanz zurückzuführen.

Sprachen der vierten Softwaregeneration sind im Normalfall auf den Endbenutzer in der Fachabteilung zugeschnitten. Die Problemformulierung, das "Was", steht bei diesen nichtprozeduralen Sprachen im Vorder-

---------------

Akzeptanzprobleme durch fehlende Info-Center vorprogrammiert

---------------

dergrund. Wie die Datenverarbeitung eine Anforderung realisiert, das "Wie" der prozeduralen Sprachen der dritten Softwaregeneration (Cobol, PL/1, Pascal), steht hierbei im Hintergrund. Die Nichtprozeduralität dieser Systeme wurde ursprünglich als Stärke dieser Sprachen angesehen, da hierdurch erst eine Programmierung durch DV-Laien ohne tieferes DV-Wissen ermöglicht wurde. In dieser Stärke liegen aber auch die Grenzen dieser Endbenutzersysteme begründet.

Ihr Einsatzgebiet ist auf komplexitätsarme Applikationen in der Fachabteilung beschränkt. Hier können Ad-hoc-Anforderungen problemlos formuliert werden. Die Berichtsgestaltung, wie Überschriften-/Summenbildung, Seitennumerierung, Seitenvorschub oder Reportformatierung, erfolgt weitgehend automatisch.

Komplexe, abteilungsübergreifende Systeme lassen sich jedoch nicht in dieses vom Endbenutzer als angenehm empfundene Korsett zwängen. Zur Formulierung solcher Systeme werden Sprachelemente wie Schleifen und bedingungsabhängige Aktionsfolgen (PERFORM, DO, GOTO, IF Bedingung THEN Aktion(sfolge) ELSE . . .) benötigt, die ausschließlich Merkmale prozeduraler Sprachen darstellen.

Aus diesem Grunde können nichtprozedurale Sprachen in der Systementwicklung für komplexe Systeme nur partiell Verwendung finden. Mit dem Einsatz nichtprozeduraler, multifunktionaler Sprachen, die auch als nonhybride Systeme bezeichnet werden können, ist zwar eine horizontale Integration erzielt worden; eine echte vertikale Synthese wurde jedoch nicht erreicht (lediglich über CALL-Aufrufe können nichtprozedurale Endbenutzersysteme unter Umständen prozedurale Sprachen aufrufen und umgekehrt).

Sollen Sprachen der vierten Softwaregeneration als Universalwerkzeuge auch Einzug in die Programmierung halten, so ist von dem Kauf der weitverbreitetsten, seit Ende der 70er/Anfang der 80er Jahre in Deutschland vermarkteten nonhybriden Systeme abzuraten.

Erst in jüngster Zeit werden in Deutschland hybride Sprachen der vierten Softwaregeneration angeboten. So enthält beispielsweise Nomad2 als multifunktionale, hybride Sprache der vierten Softwaregeneration die notwendigen, nichtprozeduralen Funktionen für den Endbenutzer wie Abfrage, Planung, Grafik Statistik, Textverarbeitung, integriertes Datenbankmanagementsystem inklusive Data-Dictionary, welches hierarchische und relationale Strukturen unterstützt mit Zugriffsfähigkeit auf externe Datenbasen (IMS, SQL/SD, in Zukunft auch DB2).

Diese nichtprozedurale Sprache ist jedoch im Gegensatz zu nonhybriden Systemen in eine prozedurale Umgebung eingebettet. Mittels dieser Sprachelemente - ähnlich wie

PL/ 1 - können so auch komplexere Applikationen realisiert werden. Durch diese Eigenschaft eröffnen sich diesen hybriden Sprachen Einsatzfelder in der klassischen Programmierung, die nonhybriden Endbenutzersystemen verschlossen bleiben. Neben der Entwicklung komplexer Systeme können sie vor allem im Bereich des Prototyping oder als Testtools gezielt Verwendung finden.

Betrachtet man die Unternehmungen aufgrund dieser skizzierten Problemfelder, so dominieren eindeutig die negativen Einflußfaktoren. Das Bild wird durch monofunktionale, nonhybride Systeme geprägt. Der Begriff des Endbenutzer-Informations-Zentrums beziehungsweise Information Centers ist bekannt, ihre Realisierung jedoch wenig verbreitet.

In der Programmierabteilung betreut ein Programmierer so "nebenbei" die Abfragesprache, eine andere Instanz unterstützt den Einsatz der Planungssprache. Für das Grafikpaket ist keiner so recht zuständig. Aufgrund dieser Rahmenbedingungen packt den Endbenutzer der Frust. Wegen der zu hohen Systembelastung (Produktions- statt Endbenutzer-DB) und geringen Eignung der im Einsatz befindlichen nonhybriden Tools für die Systementwicklung herrscht Ratlosigkeit auf seiten der DV. In dieses Spannungsfeld sind die Unternehmungen jedoch nicht unverschuldet geraten, sondern ihr kurzfristig angelegter, unkoordinierter Aktionismus ist der Ausfluß dieser Entwicklung.

Eine Sprache der vierten Generation ist statt dessen aufgrund einer langfristig angelegten, koordinierten Strategie einzuführen. Eine so angelegte Strategie sollte sich an den - aus den skizzierten Programmfeldern abgeleiteten - Thesen

- horizontale Integration durch multifunktionale Sprachen

- kontrollierter Zugriff auf Endbenutzer-DB

- Einrichtung eines Endbenutzer Informations-Zentrums (EIZ)

- vertikale Integration durch hybride Sprachen

orientieren. Nur so lassen sich die Mißerfolge früherer Jahre vermeiden.

*Heribert Thimme arbeitet als Systemanalytiker im Gerling-Konzern in Köln.