Wer schnell und kundenindividuell auf Marktanforderungen reagieren will, muß auf Computer-Integration setzen. Das erfordert von der Informationstechnologie Netzwerkkommunikation, Ausfallsicherheit, Softwaretechnologie der vierten Generation, um Datenstrukturen flexibel an Strukturwandlungen bei Technologien und Märkten anpassen zu können. Vor allem aber erfordert das von der Organisationsentwicklung eine Unternehmenskultur, die zum Management des Wandels befähigt.

Computerintegration ist also erstens Ergebnis eines innovativen Prozesses der Organisationsentwicklung, der alle Unternehmensbereiche horizontal in ein ganzheitliches Organisationskonzept einbindet. CIM ist vorrangig Anwendungskonzept und nicht Hardwarearchitektur. Neuer Wein in alten Schläuchen . . . Dieser "High-Tech"-Einsatz zur Steigerung der Systemeffektivität ("die richtigen Dinge tun") ist jederzeit möglich; die erforderliche Technologie kann "von der Stange" gekauft werden - zumindest bei einigen leistungsfähigen Herstellern, allerdings offenbar bei wenigeren, als vorgeben, es zu sein.

Zur Verwirklichung der Computerintegration braucht man jedoch zweitens eine strategische Konzeption der Informationsverarbeitung. Gegenwärtig sind noch zu viele Unternehmen zu stark mit dem Handwerklichen der Datenverarbeitung beschäftigt, so daß fürs Konzeptionelle zu wenig Zeit und Kraft bleibt. Daher vollzieht sich der dramatische Wandel in der Informationstechnologie zur Zeit vor allem bei der Softwaretechnologie, Stichwort: Werkzeuge und Methoden für Programmiersprachen der vierten Generation (4 GL).

Offenbar ist das Verständnis dieser Zusammenhänge in vielen Unternehmen noch stark umstritten. Unter der Überschrift "4 GLs bislang zu optimistisch eingeschätzt" berichtet die COMPUTERWOCHE (6. März 1987) über eine Umfragestudie der Informatik-Training-GmbH bei deutschen Unternehmen mit dem Ergebnis: durchschnittlicher Produktivitätsgewinn durch Einsatz der Softwaretechnologie der 4. Generation von "nur" 40 Prozent gegenüber herkömmlichen Softwaretechniken (was ja auch schon eine ganze Menge wäre). Ganz anders dagegen Datenverarbeitungs-Guru James Martin: In einem CW-Interview in derselben Ausgabe antwortet Martin auf die Frage, warum in vielen Unternehmen immer noch Techniken wie Hipo oder Structured Analysis und Programmiersprachen wie Cobol oder PL/1 verwendet würden: "Das ist ganz einfach Hinterwäldler-Denken . . . Das ist einfach schlechtes Management." Worum geht es also?

Amerikanische Untersuchungen haben nachgewiesen, daß der durchschnittliche Softwareanteil an den gesamten Datenverarbeitungskosten von 25 Prozent 1980 auf 35 Prozent 1985 gestiegen ist. Hersteller wie IBM stellen sich darauf ein, daß Softwareprodukte und Softwareservice in Zukunft einen erheblichen und steigenden Anteil an den Umsatzerlösen erzielen werden. Kein Zweifel: Das Software-Investment verursacht einen erheblichen Kostenblock, mit deutlich steigender Tendenz. Prognosen sprechen von einem Kostenanteil von 50 Prozent und mehr in naher Zukunft. Nach internationalem Erfahrungssatz kostet eine Zeile Programmcode für Programmdesign, Programmierung sowie Programmtest und -wartung etwa 10 Dollar. Es geht also bei der Softwaretechnologie der 4. Generation zunächst mal schlicht darum, mit möglichst wenig Codierzeilen eine große Funktionalität der Anwendungsprogramme zu erzeugen.

Hinzu kommt ein weiteres: Unternehmen müssen eine wachsende Informationsflut in den Griff bekommen. Dabei sind Sprachbarrieren zwischen Informationsmanagement und Linienmanagement abzubauen. In den meisten Unternehmen gibt es dramatische Anwendungsstaus hinsichtlich befriedigender DV-Anwendungen. Eine genauere Kenntnis des Anwendungsstaus bei den sichtbaren, bei den unsichtbaren und vor allem bei den erforderlichen Applikationen würde in manchen Unternehmen sicherlich ein "Rückstandsmanagement" im Sinne von Krisenmanagement auslösen.

Häufig wird die Nutzenstiftung der laufenden Anwendungen durch eine starre und "technokratische" Benutzeroberfläche beeinträchtigt, die sich nicht an Ausdrucksform und Arbeitstechnik der Benutzer orientiert. Besonders dramatisch für erfolgreiches Innovationsmanagement ist jedoch der Nachholbedarf an Integration. Häufig sind die Anwendungen historisch gewachsen als Reihung nicht integrierbarer Insellösungen. Starre Daten- und Programmstrukturen zwängen die Organisation in ein Streckbett.

Dagegen muß strategisches Informationsmanagement heute schnell und wirtschaftlich Anpassungsflexibilität an geänderte Marktstrukturen bereitstellen und planmäßig die genannten Engpässe beseitigen; es muß dem Unternehmen durch zukunftsorientierte Infrastruktur der Informationsverarbeitung die erforderlichen Freiräume für das Management des Wandels schaffen. Dabei gilt es, von der Fixierung auf statische, langlebige Strukturen und Abläufe abzurücken. Angesichts der Wirksamkeit des Gesetzes der Akzelleration bei Technologie und Märkten muß man den verkürzten Lebenszyklus von Systemen und Organisationen überdenken. Wenige Jahre können da zu einem sehr langen Zeitraum werden - für manche zu einer Periode unwiederbringlicher Chancen und existenzgefährdender Versäumnisse.

In vielen Unternehmen geraten die Anwendungsstaus in der Informationsverarbeitung zu den eigentlichen Bremsklötzen bei der Unternehmensentwicklung. Ihre Beseitigung durch planmäßige, aber schrittweise Einführung von Computerintegration macht den Einsatz von Softwarewerkzeugen unverzichtbar, wie sie die 4. Generation bereits heute in Ansätzen deutlich erkennen läßt.

Im Gegensatz zu Mumps arbeitet Natural 2 als Code-Generator für dahinterliegende Assembler-Programme. Der Mumps-Code dagegen ist bereits die symbolische Form der direkten Maschineninstruktionen. Dieser wesentliche Unterschied bewirkt unter anderem eine erhebliche Steigerung des Datendurchsatzes bei vergleichbarer Hardwarekonfiguration.

Dadurch wird es zum Beispiel möglich, daß unter Mumps an eine Micro-VAX II für komplexe, kommerzielle Anwendungen bei guten Antwortzeiten etwa 50 Terminals angeschlossen werden können. Unter komplexer Anwendung wird dabei etwa verstanden, wenn in einer integrierten Auftragsabwicklung bei Verarbeitung einer Auftragszeile etwa 40 bis 50 "Dateien" (wie man das wohl herkömmlich ausdrücken müßte) im Dialog fortgeschrieben werden.

Cobols Data Division wird nicht benötigt

Neben der Befehlsstärke zeigt sich in diesem Beispiel (Abbildung 8) der Produktivitätsvorsprung in einem zweiten Kriterium für die Softwaretechnologie der 4. Generation: die für alle Programme zentralisierte Datenbankspeicherung und Datenbankverwaltung. Die Data Division von Cobol wird nicht benötigt. Vielmehr gehört es zu den Voraussetzungen der 4. Sprachgeneration, daß alle Dateiparameter mit Beschreibung der Datenfelder, den Prüfbedingungen und Zugriffsbedingungen für Datensicherheit (zum Beispiel nur Leseberechtigung) und Datenschutz nur einmal für die Datenbankspeicherung (beispielsweise Adabas bei der Software AG) festgelegt und allen zugreifenden Programmen zentral zur Verfügung gestellt werden (sogenannte Data Dictionary).

Außerdem sind in einem Datenbankverwaltungsprogramm (wie Predict bei der Software AG) alle Dateiverwaltungsprozeduren und -protokolle für Neuanlage, Änderung und Löschung standardisiert und müssen nicht für jede Datei neu geschrieben werden. Datenbank-Dienstprogramme ermöglichen zum Beispiel jederzeit auch für bestehende Dateien die Generierung von Zugriffsschlüsseln für die relationale Datenbank. Diese Schlüssel können aus beliebigen Datenfeldern den Bedürfnissen entsprechend hierarchisch strukturiert werden. Ziel ist dabei, durch Befehlsstärke der Programmiersprache und Datenbankverwaltung dem Programmcode den völlig untergeordneten Stellenwert zu verschaffen, der ihm bei der Organisationsentwicklung nur beigemessen werden darf.

Kostenexplosion und Anwendungsstau erzwingen also eine kritische Überprüfung des Software-Investments. Dabei zeigen Untersuchungen der Kostenstruktur, daß zwei Drittel der Softwarekosten durch Softwarewartung gebunden werden. Dafür gibt es vor allem drei Gründe: Erstens die Fehlerbehebung, das heißt herkömmliche Programmiersprachen beherrschen die Systemkomplexität nicht angemessen; zweitens die veränderte Systemumgebung, weil üblicherweise ein überholtes Anwendungsprofil realisiert wird, und drittens die veränderten Benutzeranforderungen, weil die Anwender ihr eigenes Anforderungsprofil meist erst durch On-the-Job-Training in der neuen Systemumgebung erkennen (vergleiche Abbildung 4). Wer den Tätigkeitsnachweis seiner Programmiertruppe kritisch durchsieht, wird unschwer bestätigt finden, daß über die Hälfte mit Softwarewartung befaßt ist.

Noch aufschlußreicher als dieser immense Software-Wartungsaufwand sind Untersuchungen über die Ursachen der Softwarefehler oder unabweislichen Softwareanpassungen. Danach sind über die Hälfte aller Softwarefehler durch ein mangelhaftes Systemkonzept aufgrund der Anforderungsanalyse bedingt (siehe Abbildung 5).

Auch dies hat eine Reihe einleuchtender Gründe: Erstens hat das Topmanagement häufig genug die Festlegung des strategischen Systemkonzepts nicht als seine ureigenste Aufgabe begriffen. Zweitens hat das Informationsmanagement oftmals eine Coaching-Funktion gegenüber dem Linienmanagement bei der Festlegung des Anforderungsprofils nicht wirksam genug wahrgenommen und dadurch Übersetzungsschwierigkeiten und Sprachbarrieren verursacht. Drittens sind die Fachabteilungen im Anschluß an die Systemanalyse zuwenig in den Systementwicklungsprozeß einbezogen, so daß sie häufig praxisferne oder wenig benutzerfreundliche Anwendungen als fertiges Paket vorgesetzt bekommen (kein sogenanntes Prototyping, siehe Abbildung 6). Viertens wird bei zu vielen Projekten das Anforderungsprofil zu statisch als "Pflichtenheft" und nicht als dynamischer Lernprozeß der gesamten Organisation verstanden (vergleiche "Lernspirale", Abbildung 7).

Die Beteiligten beginnen ihre "eigentlichen" Anforderungen häufig erst in der neuen Systemumgebung zu verstehen. Wird diese Rückkopplung aus den Fachabteilungen nicht in einem ständigen, wechselseitigen Lernprozeß in die Systementwicklung einbezogen, wird häufig ein überholtes Anforderungsprofil realisiert. Das Ergebnis dieser Untersuchungen läßt sich so zusammenfassen: Die Behebung der durch mangelhaftes Systemkonzept entstandenen Fehler bindet vier Fünftel des gesamten Software-Wartungsaufwandes; eigentliche Programmierfehler kann man dabei vergessen. Dieser Sachverhalt begründet nachdrücklich den Handlungsbedarf für das Informationsmanagement, Werkzeuge der Softwareerstellung und Methoden des Projektmanagements angesichts der Chancen durch die Softwaretechnologie der 4. Generation zu überprüfen.

Was aber verbirgt sich eigentlich hinter diesem vielgenannten Schlagwort wirklich? Ein einfaches Beispiel soll den Produktivitätsvorsprung der 4. Sprachgeneration verdeutlichen. Abbildung 8 zeigt eine Gegenüberstellung der Programmiersprachen der 3. (wie Cobol) und der 4. Generation (zum Beispiel Natural 2 oder Mumps) für eine beliebige, einfache Aufgabe (siehe den selbsterklärenden Programmcode in Natural 2). Zunächst fällt auf, daß das unvollständige Cobol-Programm erheblich mehr Codierzeilen umfaßt als die beiden lauffähigen 4GL-Versionen in Natural 2 oder Mumps.

Das ist darauf zurückzuführen, daß die Sprachen der 3. Generation wie Cobol die ganze Programmprozedur, das "Wie" des Programms, abbilden, die sehr viel mächtigeren Sprachbefehle der 4. Sprachgeneration dagegen die Problemstruktur, das "Was" der Problemlösung. So braucht Mumps für die Lösung dieser Aufgabe lediglich die Programmschleife (F), den Datenbankzugriff (S und Q), die bedingte Verarbeitung (I)und die Ausgabe (W).

Produktivitätsverstärker bei CIM-Lösungen

Dies sind alles Produktivitätsverstärker bei kommerziellen Anwendungen (wie CIM-Lösungen) und kaum zu überschätzen in ihrer Wirkung. Denn: Was sind kommerzielle Anwendungen anderes als endlose Dateiverwaltungen, Textmanipulationen und Maskengenerierungen für Bildschirme und Listen, verbunden lediglich durch ein paar Rechenoperationen?

Seit längerer Zeit gibt es derartige Softwarewerkzeuge. Jedoch: Nur eine Minderheit in Deutschlands Programmierstuben setzt sie sein. Die Kostenauswirkungen des Einsatzes der Softwaretechnologie der 4. Generation sind jedoch erheblich. Erfahrungen mit Natural 2 der Software AG bestätigen zum Beispiel im praktischen, kommerziellen Einsatz bei der University of Texas in Houston, daß die Softwarekosten bei Einsatz von Cobol um das Dreifache höher sind als beim Einsatz von Adabas/Predict/Natural 2. Außerdem zeigen Untersuchungen (vergleiche COMPUTERWOCHE Nr. 21/1984), daß beispielweise ein derartiges Datenbanksystem wie Mumps gegenüber Cobol 1 nur einen Bruchteil des Programmieraufwandes und zweitens nur ein Viertel des Datenbankspeicherbedarfs benötigt.

Mumps ist das technokratische Kürzel für "Massachusetts General Hospital's Utility Multiprogramming System" und bezeichnet ein hierarchisches und relationales Datenbank-Betriebssystem, in das eine befehlsstarke Interpretersprache integriert ist. Obwohl dritte, international normierte Programmiersprache (ANSI-Standard X 11.1 1977), ist Mumps außerhalb des Krankenhausbereiches verhältnismäßig unbekannt geblieben.

Zehnjähriges Mumps weitgehend unbekannt

Dies ist um so unverständlicher, als Mumps seit über zehn Jahren die Funktionalität im praktischen Einsatz bietet, um die sich die Newcomer der Softwaretechnologie der 4. Generation gerade erst bemühen. Da bleibt einem wohl angesichts derartiger Paradoxa nur noch das Dichterwort in Schillers Demitrius (1. Aufzug, Zeile 461 ff.): "Was ist Mehrheit? . . ." Daß die Produktivitätsvorteile der vierten Sprachgeneration nicht nur in der Retorte eines Benchmarks nachweisbar sind, belegt ein Fallbeispiel (siehe Abbildung 9). Dieses Fallbeispiel ist für eine Umstiegsstrategie auf die Softwaretechnologie der 4. Generation aufschlußreich, weil es die Kostenentwicklung des gleitenden Übergangs aus einer bestehenden Stapelorganisation zum Bildschirmdialog darstellt.

Gezeigt werden Entwicklung und Struktur der Datenverarbeitungskosten gegenüber einer Ausgangslage in 1979: zentralisierter Großrechner (sogenannter Mainframe), Programmiersprache Assembler, stapelorientierte und nicht integrierte Teillösungen mit Datenerfassung über Bildschirm. 1980 wurde entschieden, das gesamte bestehende Software-Investment zu verschrotten und durch eine ganzheitlich konzipierte, dialoggestützte Betriebsorganisation für alle Funktionsbereiche des Unternehmens unter Einsatz des Datenbank-Betriebssystems Mumps zu ersetzen. Verallgemeinernd lassen sich folgende Ergebnisse ableiten:

- Auch bei komplexen Organisationen reicht ein Jahr für Systemkonzept, Programmierung und System-Implementierung eines integrierbaren Subsystems, wie zum Beispiel Auftragsabwicklung mit Hochregallager-Steuerung. Dieser Sachverhalt ist auf den außerordentlichen Produktivitätsvorsprung geeigneter Datenbankcomputer zurückzuführen.

- Programmierkosten waren für die Umstellung der Stapelanwendung auf den Bildschirmdialog nicht entscheidungsrelevant. Auch dies ist durch den außerordentlich hohen Produktivitätsvorsprung der Programmierwerkzeuge der 4. Generation und den gleichermaßen hohen Wartungsaufwand für das herkömmliche Software-Investment bei Verwendung von Softwarewerkzeugen der 3. Generation zu erklären.

- Die Wirtschaftlichkeit der Datenbankcomputer ermöglicht eine Trendumkehr gegenüber der allgemeinen Tendenz eines steigenden Software-Kostenanteils. Entgegen dem landläufig beobachteten Trend (Software-Kostenanteil zur Zeit etwa 35 Prozent mit steigender Tendenz) konnte in diesem Fallbeispiel der Software-Kostenanteil seit Jahren auf konstante 10 Prozent gesenkt werden.

- Als Folge der hohen Bildschirmdichte durch Computerintegration hängen die Datenverarbeitungskosten vor allem vom Hardware-Investment für die erforderliche Benutzerzahl und für die Ausfallsicherheit ab.

Diese Leistungsunterschiede sind bekannt, dennoch beherrscht Cobol unverändert die deutsche Programmierszene. Angesichts derartigen Beharrungsvermögens werden hohe Anforderungen an das Durchsetzungsvermögen des Informationsmanagements gestellt hinsichtlich einer unvoreingenommenen Überprüfung der zeitgemäßen Softwarewerkzeuge.

Wie die Untersuchung der Fehlerquellen beim Software-Investment zeigt, müssen aber auch die Methoden des Software-Engineering überdacht werden. Denn: Über die Hälfte aller Softwarefehler werden durch mangelhaftes Systemdesign verursacht und binden gut vier Fünftel des gesamten Software-Wartungsaufwandes. Wir haben eine Reihe sehr Plausibler Gründe für diese prekäre Situation genannt. Wer also vermeiden will, daß der Lösungsstau bei der Informationsverarbeitung schneller wächst als die Lösungskapazität, der muß bei den Methoden des Projektmanagements neue Wege suchen.

Das herkömmliche Verfahren des Reißbrettentwurfs von Ablauforganisation erweist sich bei der Computerintegration als wenig erfolgversprechend. Vielmehr ist die frühzeitige Einbeziehung der Fachabteilungen beim Systemdesign und bei der Implementierung benutzererprobter und integrierbarer Realisierungsstufen erforderlich. Dadurch können Änderungswiderstände bei angestrebter hoher Bildschirmdichte von vornherein abgebaut und praxiserprobte Lösungen eingebaut werden. Das erforderliche Know-how für die Einbindung vieler handlungsorientierten Ideen können die Praktiker in den Fachabteilungen nur im praktischen Umgang mit der neuen Systemumgebung durch Einübung zugewinnen.

Dadurch wird der Projektablauf prozeßorientiert. Er heißt "inside-out approach" (vergleiche COMPUTERWOCHE vom 13. Juli 1984) oder "prototyping", weil der Aufgabenbaum in integrierbare Teilsysteme mit einem überschaubaren Arbeitsumfang von wenigen Arbeitsmonaten aufgegliedert wird. Durch die systematische Integration werden dabei die betroffenen Benutzer zu Beteiligten während des gesamten Projektablaufes gemacht. Die praxiserprobte Anwendung ist dann Ergebnis eigener Implementierungsbemühungen der betroffenen Fachabteilung.

Anders der herkömmliche, phasenorientierte Projektablauf: Hier wird das Gesamtprojekt in den Phasen Systemkonzept, Systemdesign, Programmierung und Implementierung realisiert, als Vorgabe fertiger Problemlösungen aufgrund eines "Pflichtenheftes" ohne Einbeziehung der Benutzer. Dabei geraten die Dauer komplexen Gesamtkonzepte und die verkürzten Lebenszyklen von Organisationskonzepten ständig miteinander in Konflikt. Ergebnis ist überwiegend die datentechnische Realisierung überholter Systemkonzepte.

Anstelle dieser langwierigen Realisierung komplexer Gesamtprojekte beim phasenorientierten Projektablauf stellt das Prototyping schnell eine praktisch nutzbare Basislösung bereit. Erfahrungen aus dem praktischen Betrieb der ersten Realisierungsstufe (Prototyp als integrierbare Insellösung) werden bei Design und Implementierung der Folgestufen berücksichtigt. Voraussetzung ist dazu jedoch ein Systemdesign, das die Anforderungen an die Computerintegration festlegt und in schlüssiges, aber offenes Datenbankdesign und Datenfluß umsetzt (siehe Abbildung 6). (wird fortgesetzt)

*Jens Christopher Ruhsert ist Geschäftsführer der Wilhelm Gienger GmbH & Co. KG, München, Fachgroßhändler für Haustechnik.