Redundanzen zu vermeiden, ist nach wie vor das Ziel der meisten Systementwickler. Um komplexe Systeme überschaubarer zu machen, plädiert Dieter Schultze * jedoch für kleine, spezialisierte, nahezu identische Programme für jede Geschäftsfall-Variante.
Der System-Analytiker war stolz; denn er hatte "das Unmögliche" geschafft. Bisher hatte die Bank mit 50 verschiedenen Belegen gearbeitet. Der neue Einheitsbeleg aber konnte alle 50 Formulare ablösen.
Das bedeutet jedoch, daß das DV-System die feine Differenzierung der heutigen Abläufe aufheben wird. Das hochkomplexe Formular läßt die Produktivität der beteiligten Fachabteilungen sinken; es zwingt zu einer überholten Zentralisierung und niemand kommt spontan mit dem entsprechenden Erfassungsprogramm zurecht.
Der Output aller Geschäftsfälle wird zentral im Batch ausgegeben. Von echter Dezentralisierbarkeit und integraler Sachbearbeitung keine Rede. Die Bank hat zwar Hunderte von Bildschirmen, aber die Erfassung dieses Einheitsbeleges entspricht - trotz des Online-Systems - der alten Offline-Erfassung: dezentrales Ausfüllen, quasi-zentrales Erfassen durch "Spezialisten", Fehlermeldungen, Rückweisung an den Aussteller, Korrektur und schließlich Einheits-Output.
Welche Idee steht dahinter? Die Entwickler wollten mit einem einzigen Erfassungsprogramm alle möglichen Fälle abdecken und vernachlässigten dafür die differenzierte Behandlung der Geschäftsfälle in den Fachabteilungen. Nennen wir diese alte Design-Form das "Pipeline-Design". Denn wie durch eine Universal-Pipeline schleust man Getreide, Öl, Wasser, Steine - alles durch das gleiche Programm.
Im Inneren des Programms wird dann mühsam an den verschiedensten Orten die Fallunterscheidung vorgenommen, was dann zu diesen hochkomplexen Programmen führt, die wir alle zur Genüge kennen. Alles aus der Idee heraus, keine Zeile Code unnötig oder gar doppelt zu führen.
Zu diesem überholten Design-Verständnis kommt der noch nicht verdaute Hardware-Schub. Schon längst könnten wir mit etwas mehr Hardware in vielen Fällen auf echte, vollständige Online-Programme umstellen. Aber solange wir an der Arbeitsteilung Online am Tage, Batch am Abend für alle Geschäftsfälle festhalten, werden wir uns schwer tun mit kurzen Durchlaufzeiten und schneller, integraler Sachbearbeitung.
"Ein Segment gibt eine Maske und ein Programm", das ist die alte Design-Regel der 70er Jahre, die wir noch häufig antreffen. Eine Design-Regel, die zwar vordergründig das Problem der unvorhergesehenen Kombination von Feld-Manipulationen perfekt löst - aber nur aus DV-Sicht. Denn der Benutzer will etwas anderes: Er will Masken, die jeweils genau auf einen einzigen Geschäftsfall zugeschnitten sind.
Doch vielfach entwerfen wir weiterhin große Allzweck-Masken mit Hunderten von Feldern. Unpraktisch, ohne Bezug zur Sachbearbeitung - aber als strukturierter Spiegel unserer Dateien. Feldbezeichnungen bestehen wegen Platzmangels aus den Kürzeln der Datenbank. Das korrekte Ausfüllen solcher Masken gelingt nur nach langer Praxis.
Von intuitivem "Dialog" keine Spur. Welche Felder man in welchem Fall überhaupt noch ausfüllen darf, ist nur noch wenigen klar.
Die Benutzer verlieren Minuten mit Nachdenken, was sie jetzt schon wieder falsch gemacht haben. Die Antwortzeiten sind lang, da große Programme und volle Schirme hin- und hergeschoben werden. CPU-Zeit wird verbraucht für unnötiges Plausibilisieren von nicht gemachten Eingaben in 100 Feldern.
Das ist die eine Seite dieser Design-Regel. Auf der DV-Seite kommen noch andere Dinge hinzu: Da ist vor allem die Komplexität dieser Programme, die niemand mehr anlangen will. Komplexe Programme sind kaum wartbar und testbar. Der Grund hierfür ist bekannt; die explosionsartig wachsenden Durchlaufvarianten bereits bei einer kleinen Anzahl von IFs, CASEs und LOOPs.
Es gibt Betriebe, die offiziell mit einem Testabdeckungsgrad von 80 Prozent zufrieden sind. Andere erreichen nicht einmal 30 Prozent. Und dennoch gehen auch solche Programme noch in Produktion. Dafür leben sie nicht so lange, und wir müssen sie bereits nach wenigen Jahren durch ein neues, nicht weniger komplexes Nachfolge-Paket ersetzen.
Die Lösung liegt sicher im geschäftsfallorientierten Systementwurf. Von den Abläufen über die Masken und die Programme - alles geschäftsfallorientiert. Damit bietet sich eine hervorragende Möglichkeit, ein großes System von Anfang an auf natürliche Art sehr fein zu gliedern. Denn das ist unsere eigentliche Aufgabe: Komplexität zu reduzieren, durch feines Unterteilen in einer Art, die auch der Benutzer nachvollziehen kann.
Unseren heutigen Top-down-Ansatz - ob funktions- oder datenbezogen - kann der Benutzer nur schwerlich nachvollziehen. Eine Unterteilung in Geschäftsfälle und Geschäftsfall-Varianten hingegen versteht er instinktiv. Denn das entspricht seinem Denken in differenzierten Maßnahmen und Abläufen für bestimmte Geschäftsfall-Arten.
Wenn wir darüber hinaus noch einfache Programme bekommen - was wollen wir dann noch mehr? Unterteilen wir vertikal in beispielsweise 200 Geschäftsfälle, muß sich auch automatisch die Komplexität der beteiligten Programme massiv reduzieren. Wenn jede Geschäftsart ihre eigene Maske und Ablauforganisation hat, sinkt damit automatisch die Zahl der IFs und CASEs in diesen Programmen.
Vertikale statt horizontale Gliederung
Statt daß wir ein System horizontal in Funktionen, Unterfunktionen und Teilfunktionen aufschlüsseln, gliedern wir es vertikal in die Masse der natürlichen Geschäftsfall-Varianten, die durch das System fließen. (Nebenbei: Bei aufwendigen Hauptgeschäftsarten können wir dann immer noch mit unserem normalen Werkzeug des Top-down weiterarbeiten.)
Bei diesen 200 Geschäftsarten besteht einzig noch das Problem, wie man sich jetzt in das richtige Geschäftsart-Programm einklinkt. Und diese Aufgabe übergeben wir dem Benutzer selbst. Er kann aufgrund seines Sachverstandes am besten die jeweils richtige Geschäftsart-Variante auswählen. Die Fallunterscheidung erfolgt damit außerhalb unserer Programme - im Kopf des Benutzers. Daher der Begriff der "Externen Programmierung". Ein Teil der Programmierung wird quasi nach außen verlegt (Abb.).
Der Benutzer gibt also jeweils den gewünschten Geschäftsart-Code ein. Und jetzt sind lineare, verzweigungsfreie, spezialisierte kleine Programme aufrufbar. Im alten Pipeline-Design hingegen mußten Programme intern mühsam die verschiedenen Benutzer-Eingaben daraufhin untersuchen, was der Benutzer denn jetzt eigentlich eingeben wollte, welche der 50 verschiedenen, nur unscharf definierten Geschäftsarten er gerade bearbeiten wollte.
Verständigung mit den Fachabteilungen schwierig
Die meisten werden sagen: Das machen wir seit eh und je so - nach Geschäftsvorfällen arbeiten. Aber meinen wir dasselbe, wenn wir vom Teilsystem "Bestellung" reden und unser Benutzer vom Geschäftsfall "Bestellung"? Wir denken in einer statischen Funktion, er denkt in einem dynamischen Ablauf.
Und weiter: DV-Leute fassen viele, gänzlich unterschiedliche Geschäftsfälle einfach unter dem Begriff "Mutation" oder "Abfrage" zusammen. Und damit wird die differenzierte Realität mit Folgekosten auf Benutzerseite vergewaltigt.
Angenommen, ein Mitarbeiter heiratet. Aus der Sicht des Lohnbüros handelt es sich um einen eindeutigen Geschäftsfall, ein äußeres Ereignis, das gewisse Betriebsabläufe anstößt, um damit gewisse vorbestimmte Resultate zu erreichen: ein kleiner gelber Beleg von der Personalabteilung, ein zusätzlicher freier Tag, Auslösen eines Schreibens über eine prozentuale Gehaltserhöhung und Erfassen einer eventuellen Namensänderung. Das ist der Geschäftsvorfall "Heirat" . Auf dem Bildschirm werden also die Felder Namen, Gehalt, Ferienanspruch, Zivilstandscode benötigt. Mehr nicht, denn alle anderen 200 Felder des Mitarbeiter-Segments sind unnötig.
Jetzt wird der DV-Mann sagen: Aber bitte, alle diese Felder befinden sich doch auf Grundmaske 1, man braucht sich nur die richtigen Felder herauspicken. Das ist richtig - und äußerst mühsam und unproduktiv für die Dame im Lohnbüro. Und sie wird sicher Fehler machen, etwas vergessen oder einen Code falsch angeben.
Es leuchtet ein: Mit einer einfachen Maske - ähnlich dem kleinen gelben Beleg der Personalabteilung - ließen sich verschiedene Dinge massiv vereinfachen: Aufgrund des Geschäftsfall-Codes könnte die Sachbearbeiterin rascher die wenigen dann noch notwendigen Angaben erfassen: Das "Heirats-Programm" kann die Vollständigkeit und Stimmigkeit der Eingaben kontrollieren, vieles kann es als Vorgabewert automatisieren - so das Gewähren eines zusätzliche Ferientags, die Gehaltserhöhung und das Mutieren des Zivilstandscodes auf "verheiratet".
Das Programm ist kleiner und schneller, weil es nur wenige Felder prüft. Die Antwortzeit ist kürzer und die Bearbeitung ist schneller, weil eventuelle Bedienungshinweise Platz auf der Maske haben. Die Entwicklung solcher Programme ist kürzer, da man solche Transaktionen sehr gut mit Sprachen der vierten Generation machen kann.
Der Test ist schneller, da man sich voll auf diesen einen Fall "Heirat" konzentrieren kann. Die Wartung ist einfacher, weil der Programmierer sofort weiß, wo er suchen muß, wenn sich etwas bei der Abwicklung der ,,Heirat" ändert. Und solch eine Änderung hat dann eben praktisch keine Fernwirkung auf andere Geschäftsfälle.
*Dieter Schultze ist Unternehmensberater in Buchs/Zürich.