Um weiterhin Zuverlässigkeit und Schnelligkeit bei der Auslieferung von Arzneimitteln sicherzustellen, mußte die GEHE AG ihre veralteten Anwendungsprogramme neu konzipieren. Dabei setzte der Stuttgarter Pharmagroßhandel auf eine Sprache der vierten Generation. Entwickelt wurde nach zwei Verfahren: dem konventionellen Phasenkonzept und dem Prototyping.
Mehr als jede andere Branche steht und fällt der Pharmagroßhandel mit der Qualität seiner Datenverarbeitung. Die in puncto Sicherheit und Qualität überaus anspruchsvolle Anwendungssoftware stand bei der GEHE AG in der Vergangenheit auf einer völlig überalterten Basis: So wurde BTAM-GENA als Terminal-Zugriffsmethode und eine im Anwendungsprogramm selbstgeschriebene TP-Monitor-Logik verwendet. Weiterhin bestand dieses Software-Paket ausschließlich aus Assembler-Programmen; die Datensätze wurden in VSE-DA-Dateien gestreut gespeichert, wobei der logische Zugriff über Schlüsselbegriffe in mehreren Index-Stufen ebenfalls in der Anwendungslogik programmiert war. Dementsprechend existierten auch eigene Reorganisationsmethoden. Schließlich und endlich wurde in verschiedenen Anwendungsprogrammen sogar direkt mit Supervisor-Aufrufen und physischem IOCS gearbeitet.
Dieses Paket wurde immer mehr zum zentralen Problem. Durch die Überalterung sowohl der System- als auch der Anwendungssoftware waren vor allem die internen Strukturen derart unübersichtlich geworden, daß sich auch bei kleinen Änderungen sehr schnell Fehler einschlichen und schließlich eine Weiterentwicklung nur noch mit unvertretbarem Aufwand durchzuführen war. Hinzu kam, daß die Komponenten (zum Beispiel GENA) vom Hersteller teilweise nicht mehr gewartet wurden und das spezifische Know-how zunehmend verlorenging, da im DV-Markt immer weniger Nachwuchskräfte für solche Systeme ausgebildet wurden.
Es war offensichtlich, daß hier für die Zukunft ein Risiko lag, von dem wir uns rechtzeitig befreien mußten. Eine direkte Umsetzung auf den heute noch gültigen Standard wie zum Beispiel Cobol, VSAM beziehungsweise DL/1 und CICS kam für uns nicht in Frage, da wir nicht in eine bereits überholte Technologie investieren wollten.
Die GEHE AG beschloß schließlich ihre komplette Niederlassungssoftware neu zu entwickeln, und zwar mit heute zukunftsträchtigen Systemen, um eine Basis für ihre EDV- und Softwarestrategie der nächsten 15 Jahre zu schaffen. Das neue Paket sollte komplett auf der Basis "Adabas" und "Natural" entstehen, in der Anwendungsentwicklung unterstützt durch das Data Dictionary "Predict".
Mit einem Aufwand von zirka 30 Mannjahren wurde die gesamte Pharma-Software neu entwickelt nicht eines der alten Programme blieb übrig. Das neue System ging im Juli 1985, zweieinhalb Jahre nach Projektbeginn, in der Niederlassung Stuttgart erstmals in Produktion. Die Umstellung aller elf Niederlassungen soll bis 1987 abgeschlossen sein. Dann wird die gesamte Geschäftstätigkeit mit einem Umsatz von zirka 2 Milliarden Mark über DV-Systeme auf Adabas/Natural-Basis abgewickelt.
Das konventionelle Phasenkonzept war vorerst als Grundlage für das Projekt gewählt worden, weil wir noch keine Erfahrung mit den neuen Softwaresystemen hatten und uns nicht zusätzlich mit einer neuen Entwicklungsmethode belasten wollten. Jedoch war zum Zeitpunkt des Projektstarts das Arbeitsgebiet LAWI (Lagerwirtschaft) ausgeklammert worden. Es handelt sich hierbei um einen Batchablauf, der nach Tagesschluß aufgrund der vorliegenden Nachfragen den zukünftigen Bedarf zu ermitteln sucht (Prognose), auf dieser Basis Reichweitenüberprüfungen vornimmt (für welchen Zeitraum muß unter Zugrundelegung des Lagerbestandes und der zu erwartenden Wareneingänge wieviel bestellt werden?) und daraus Bestellvorschläge erarbeitet, über die am nächsten Tag der Einkauf im Rahmen der Disposition online verfügen kann. Es war vorgesehen, die alten Programme dieses Komplexes zwar an die neue Datenbasis anzupassen, die Logik allerdings nicht zu verändern.
Ein Jahr nach Projektstart jedoch wurde offenkundig, daß diese Planungen nicht aufrechterhalten werden konnten. In einer Anwendung, die fast ausschließlich auf Natural basierte, wäre ein entscheidendes Arbeitsgebiet auf Assembler-Basis belassen worden. Eine Integration in die neuen Entwicklungsmethoden wäre für lange Zeit blockiert gewesen.
Auch der Fachbereich selbst drängte nun zunehmend auf eine echte Neuentwicklung. Andere wichtige Funktionen wie Disposition, Wareneingang oder Rechnungsprüfung, die auf Informationen aus LAWI angewiesen waren, hätten zudem viele Neuerungsideen nicht realisieren können.
Schließlich wurde die schlechte Qualität des alten Systems immer offenkundiger. Wir suchten deshalb nach einer Methode, LAWI zu diesem späten Zeitpunkt doch noch in die Gesamtanwendung einzubinden. Die Lösung, die wir schließlich fanden, hieß Prototyping.
Statt wie bei herkömmlicher Vorgehensweise zunächst jede Einzelheit der Planung zu Papier zu bringen, um sie dann in vielen Einzelschritten technisch umzusetzen, werden beim Prototyping zunächst Bausteine entwickelt, die der Benutzer sofort prüfen kann und die dann bereits Bestandteil der Anwendung sind. Durch Einfügen dieser Module in den logischen Zusammenhang entsteht die Gesamtanwendung.
Diese Methode ist nur mit Entwicklungssystemen der vierten Generation möglich. Die Elemente müssen schnell vorgeführt und geändert werden können, was voraussetzt, daß der Entwickler frei ist von konventionell notwendigen Vorbereitungen wie zum Beispiel im TP Monitor. Insbesondere die Möglichkeit, "Benutzersichten" auf die zu verarbeitenden Daten zu definieren (also auf die individuelle Zusammenstellung von Feldern für bestimmte Zwecke), der interaktive Entwurf von Bildschirmmasken oder die Generierung von Reports mit wenigen, wirkungsvollen Anweisungen prädestiniert diese Sprachen geradezu für das Prototyping.
Um das Wesen dieser Entwicklungsmethode zu erkennen, muß zunächst noch einmal das konventionelle Phasenmodell betrachtet werden. Es bestand in diesem Projekt aus sieben Stufen:
1. Vorstudie,
2. Fachkonzept,
3. DV-Grob-Design Definition der DB-Grobstruktur und Entwicklung der Benutzer-Schnittstellen
4. DV-Fein-Design/DV-Konzept/ Detail-DB-Design
5. Realisierung
6. EinzeIfunktions-/Teilintegrationstests
7. Gesamtintegrationstests/Parallelläufe.
Was zeichnet gegenüber diesem klassischen Weg das Prototyping aus? Da darüber unterschiedliche, zum Teil irrige Vorstellungen existieren, hier die Quintessenz unserer Erfahrungen vorab: Prototyping heißt nicht Verzicht auf systematische Analyse, sondern setzt sie im Gegenteil unbedingt voraus.
Es muß ein ausgereiftes Fachkonzept vorliegen, das heißt der Anwender muß im Prinzip (nicht im Detail) wissen, was er will und wie er sich sein künftiges DV-System vorstellt. Zustande kommen kann eine solche Vorlage oft nur mit Unterstützung durch die DV. Auf dieser Basis muß eine grobe Datenstrukturanalyse erstellt und mittels DB-Grobdesign und Datenflußdiagrammen konkretisiert werden. Wann diese Voraussetzungen gegeben sind, hängt von der zu bewältigenden Aufgabe ab:
- Ist ein Basissystem vorhanden, in das nur eine weitere Komponente
eingefügt werden soll, so kann sicherlich der eigentliche Prototyping-Prozeß sehr zügig einsetzen, da auf Daten- und Anwendungsstrukturen zurückgegriffen werden kann. Dies gilt insbesondere für Informationsgewinnung und -aufbereitung aus bereits gespeicherten Daten, geht jedoch auch im operativen Bereich noch sehr zügig, sofern es sich nur um die Manipulation bestehender Daten handelt.
- Soll ein Basissystem erweitert, also auch die Daten- und Anwendungsstruktur modifiziert werden, muß eine mehr oder weniger umfangreiche Designphase vorangehen, damit das Gesamtsystem nicht außer Kontrolle gerät und keine Hardware-Kapazitätsprobleme entstehen. Dabei spielt die Datenbankverwaltung eine wichtige Rolle.
- Will man gar ein komplett neues System entwickeln, so darf das Prototyping frühestens dann einsetzen, wenn die Daten- und Anwendungsstruktur und damit auch das verbundene DB-Design bereits in einer groben Form definiert sind. Die konventionellen Projektphasen wie Vorstudie, Fach- und DV-Grobkonzept bleiben also erhalten, dann jedoch kann eine Verschmelzung der Phasen Detaildesign (sowohl fachlich als auch DV-technisch), Realisierung und Einzelfunktionstests stattfinden.
Sind diese Voraussetzungen gegeben, kann das Prototyping einsetzen. Zunächst muß Anwendern und Programmierern erläutert werden, um was es sich überhaupt handelt. Das bedeutet ausführliche Schulung. Bereits jetzt muß man auch dafür sorgen, daß nicht nach einem flüchtigen Kontakt des Entwicklers mit dem Anwender eine längere Realisierungsphase einsetzt, sondern während des gesamten Projekts eine intensive Kommunikation durchgehalten wird. Da hierbei der Fachbereichsmitarbeiter stark verfügbar sein muß, ist ohne seine entsprechende Freistellung von der Tagesarbeit das Prototyping in der Regel zum Scheitern verurteilt. Schließlich muß gerade beim Prototyping der Gesamtkoordination aller beteiligten Fachbereiche im Rahmen der Projektorganisation ein besonders hoher Stellenwert beigemessen werden, da ansonsten die vielen Detailschnittstellen schnell inkonsistent werden können.
Rund drei Monate nach dem Einstieg in die LAWI-Entwicklung waren die notwendigen Voraussetzungen geschaffen. Der Fachbereich hatte ein konkretes Konzept vorgelegt, auf dessen Basis die EDV-Abteilung die LAWI-Grobstruktur (Funktionen und Datenbasis) definiert hatte. Die fachliche Koordination wurde einem für die Gesamtanalyse verantwortlichen DV-Organisator übergeben, die DV-technische Seite zwischen dem DBA und einem für die Programmierung zuständigen Mitarbeiter aufgeteilt.
Die Entwicklung von LAWI war insofern ungewöhnlich, als wir eine Batch-Anwendung mit Prototyping realisieren wollten, die (außer einer vom Fachbereich vorgegebenen Logik) eigentlich keine Benutzerschnittstellen hat. (Weder Listen noch Masken - die spätere Online-Verarbeitung der Bestellvorschläge findet in einem getrennten Arbeitsgebiet statt.) Wir mußten daher solche Online-Schnittstellen erst schaffen, um die Voraussetzung für die Entwicklung einer komplexen Logik mittels Prototyping zu erhalten.
In der ersten Stufe wurde der gesamte Batch-Prozeß in Teilschritte zerlegt (Definierbarkeit der Eingabeschnittstelle - Vorhandensein einer in sich geschlossenen Logik, die der Anwender als solche erkennen muß - Definierbarkeit der Ausgangsschnittstelle). Da es sich um die Ebene der Fachabteilungen handelt, die hier ihre Erwartungen formulieren, wird sowohl der Aufbau als auch die Tiefe der Gliederung durch die Anwendung bestimmt.
Die zweite Stufe, die Entwicklung der Logikmodule, war das Kernstück des Prototyping und beanspruchte dementsprechend die meiste Zeit. Hier war das in Teilprozesse gegliederte Fachkonzept gleichzeitig zu detaillieren und zu realisieren und es wurden auch die erwähnten Schnittstellen für das Online-Prototyping geschaffen.
In der Praxis lief das so ab, daß der zuständige Anwendungsentwickler entsprechend den vorliegenden Fachkonzeptvorgaben einen Baustein erstellte. Dessen Logik und, daraus abgeleitet, auch die entsprechenden Eingabedaten wurden so lange erweitert beziehungsweise modifiziert, bis das gewünschte Ergebnis vorlag. Insbesondere konnte durch Ausprobieren der verschiedenen Eingabekonstellationen anhand der unmittelbar verfügbaren Ergebnisse die zugrundeliegende Logik beurteilt und weiterentwickelt werden. Das führte in zwei Fällen sogar dazu, daß man die ursprünglichen Vorgaben nahezu komplett beiseite legte, da durch das Prototyping die Mängel und Schwachstellen klar ersichtlich wurden. Das nachfolgende Beispiel mag dies verdeutlichen.
Ein Element der Anwendung (Baustein-Teilprozeß) ist die "Bestellmengenrundung". Grundlage hierfür ist die Reichweitenüberprüfung, die die bis dahin ideale Bestellmenge errechnet hat. Da die Lieferanten feste Verpackungseinheiten vorgeben, muß ermittelt werden, mit welchen Kombinationen aus bis zu vier Bestelleinheiten man dieser Idealmenge am nächsten kommt.
Der Fachbereich hatte für diesen Teilprozeß eine Logik vorgegeben, die nach dem Grundsatz der Geldsorgenzählung die Bestelleinheiten der Größe nach abprüfte. Beim Durchspielen vieler Fallbeispiele am Bildschirm stellten sich dabei mehrere Schwachstellen heraus. So wurden zum Beispiel bei einer Idealmenge von 95 eine Packung zu 50 und drei zu 20 bestellt - statt der in diesem Falle günstigeren Hundertereinheit. Mittels Prototyping konnte jedoch sehr schnell (innerhalb weniger Stunden) eine Alternativlogik entwickelt und ausgetestet werden, die den Anforderungen der Praxis gerecht wurde.
Erst das "Durchspielen" vieler Fallbeispiele, die teilweise in ihren Eingabedaten direkt aus der Praxis übertragen wurden, und die daraus resultierende Möglichkeit, das Ergebnis sofort zu beurteilen, hatten im ersten Modell die Schwachstellen zutage gefördert und gleichzeitig beim Aufbau des zweiten Rundungsmodells den Weg zur praxisgerechten Logik gewiesen.
In einem konventionellen System ist diese für das Prototyping typische Vorgehensweise mit einem vertretbaren Entwicklungsaufwand kaum zu realisieren. Allein ein Batch-Modul durch Masken (unter Beachtung von TP-Monitor-Spezifikationen) onlinefähig zu machen und dieses losgelöst vom Gesamtprogramm zu betrachten, würde den eigentlichen Entwicklungsaufwand für die reine Logik wohl übersteigen.
Probleme, die wir so bereits frühzeitig erkennen konnten, würden bei einer konventionellen Entwicklungsmethode erst zu einem sehr späten Zeitpunkt auffallen. (Im Beispiel der Bestellmengenrundung durch hohe Lagerwerte und damit verbundene schlechte Umschlagszahlen). Dann hätte man sich mühsam durch die Anwendung zurückhangeln müssen, um die Ursache der zu spät erkannten Probleme zu orten. Beim Prototyping dagegen hatten wir in der halben Zeit ein fachlich besseres Ergebnis, das außerdem mit gleicher Methode auf einfache Weise weiter optimiert werden kann.
In der beschriebenen Stufe 2 konnten nun auch die Anforderungen an die Datenbasis bis auf Feldebene konkretisiert und in das DB-Konzept eingegliedert werden. Mit Abschluß dieser Stufe hatte sich das Zwischenprodukt "Logikmodule" herausgebildet, womit auch gleichzeitig die Einzelfunktionstests abgeschlossen waren.
Die dritte Stufe war das Zusammenfügen der entwickelten Bausteine zu Programmen, die vierte und letzte der Test des gesamten Systems im Zusammenhang. Hier wurde eine abschließende Bewertung vorgenommen, gleichzeitig konnten noch Zwischenergebnisse betrachtet und, falls erforderlich, im Rückgriff auf die Stufe 2 überarbeitet werden.
Besonders wichtig ist, daß in der Stufe 3 die Online-Schnittstellen im Programm belassen wurden, obwohl sie für eine Batch-Anwendung eigentlich nicht gebraucht werden. Damit waren zum Beispiel die Voraussetzungen geschaffen für die Teilintegrationstests der Stufe 4. Vor allem aber ließ sich ein Simulationssystem aufbauen, mit dem zum einen die Sachbearbeiter geschult werden können und das zum anderen - durch die Übernahme von Produktionsdaten - einen permanenten Test der Logik erlaubt.
Programmerweiterungen können sofort Integrationstests unterzogen und vom Anwender direkt bewertet werden, wodurch eine Fortentwicklung der Anwender sehr einfach wird. Dasselbe System, das tagsüber online für Simulation und Test eingesetzt wird, arbeitet nachts als Batch-Produktionsprogramm - mit physisch denselben Programmen (lediglich die Ablaufsteuerung wirkt etwas unterschiedlich). Mit konventionellen Sprachen wäre das schwerlich zu realisieren gewesen; in der beschriebenen Form der Entwicklung könnte man beinahe von einem "Abfallprodukt des Prototyping" sprechen.
Ganz besonders muß hervorgehoben werden, daß das Verhältnis zwischen Anwendern und DV-Abteilung durch die intensive Zusammenarbeit viel besser geworden ist, beide haben gegenseitig an Kompetenz gewonnen. Selbstverständlich werden beim Prototyping erhebliche Ansprüche an den Fachbereichsmitarbeiter gestellt. Aber andererseits wird ihm dabei auch der richtige Weg zum Umgang mit der EDV aufgezeigt.
Früher hingegen mußten sich unsere Fachabteilungen selbst organisieren, da das Detailkonzept bereits zu einem sehr frühen Zeitpunkt alle funktionellen und inhaltlichen Apekte nahezu vollständig abzudecken hatte. Damit verglichen ist Prototyping - vorausgesetzt, es wird richtig verstanden und angewandt - eindeutig überlegen: Das Ziel wird schneller und zugleich auf einem qualitativ deutlich höheren Level erreicht.
*Andreas Zimmer ist Leiter der DV-Anwendungsentwicklung bei der GEHE AG, Stuttgart.