Die Krise der Datenverarbeitung oder: Tools versus People

14.09.1990

Dietrich Bartels, Wiesbaden

Hr. Dietrich Bartels ist Abteilungsleiter der Systementwicklung in einem großen Versicherungsunternehmen und verantwortlich für alle "Finanz-Systeme"

Befindet sich die DV in einer Krise? Je nach Erfahrung, beruflicher Position und last, not least aktueller Gemütslage wird darauf mit einem mehr oder weniger eindeutigen "Ja" geantwortet.

Ein Symptom für die Krise ist unter anderem das expansive Beraterwesen - je mehr professionelle Berater es gibt, desto größer ist wohl die Ratlosigkeit (Analogien zur Psycho-Branche in den USA und bald auch bei uns sind beabsichtigt). Ein weiteres Symptom ist die Flut von Artikeln, die uns in dieser und verwandten Zeitschriften begegnen - im Kern handelt es sich dabei um Ausführungen zu dem Thema "Wie-man-es-eigentlichalles-besser-machen-müßte".

Schließlich kann als Symptom noch die Anstrengung eines großen - beziehungsweise eines sehr, sehr großen - Herstellers erwähnt werden, der vermehrt die Gemeinde der DV-Betreiber mit in Abkürzungen (zumeist drei Buchstaben wie etwa "CUA") verpackten Heilslehren oder Versprechungen zu trösten sucht.

Symptome zu suchen ist eine Sache - das Phänomen zu beschreiben eine andere. Also worin besteht die Krise? Die Angebote der Berater und des großen Herstellers liefern - weil marktorientiert - die Antwort: irgendwie hat der Anwendungsentwickler das Gefühl, seine Sache nicht richtig zu machen; die Resultate seiner Tätigkeit sind einfach dürftig und vor allem mit früher Versprochenem Oberhaupt nicht zu vergleichen. Da dies Gefühl von den Abnehmern der DV-Produkte, auch Endbenutzer genannt sehr intensiv geteilt wird, muß es wohl richtig sein. Also: Krise = mangelnde Produktivität = BACKLOG = Anwendungsstau = etc.

Vor allem die Insider quält noch eine andere Form der Krise: Abgesehen vom Fortschritt muß man sich mehr und mehr um die Erhaltung (zu adäquaten Kosten, versteht sich) des Bestehenden kümmern: Schreckliche Fehler lauern in den bestehenden Systeme" - ATT hat in letzter Zeit das bekannteste Beispiel geliefert - und vermutlich jeder Verantwortungsträger wüßte von namenlosen kleinen Katastrophen zu berichten. Stellt man sich vor, was alles noch Passieren könnte, so wird es einem recht unheimlich, und so ist der nächste Aspekt der Krise Angst und Unsicherheit.

Wenn nun eine Krise da ist, SO will man sie bewältigen dazu wiederum muß man ihre Ursachen kennen. Wie in der Medizin werden hier vor allem Therapien (= Tools) angeboten; nun sind diese Tool & Methoden-Lehren zweifellos alle sehr nützlich, Jedoch gibt es einige tiefergehende Ursachen, die jeder mit CASE noch mit Repositories in den Griff zu bekommen sein dürften. Beispiele:

Zieldefinition/Endbenutzer:

Die "selbstverständlichen" Anwendungsgebiete der DV sind - abgesehen von Kleinbetrieben, wo man demzufolge lustvoll, aber ertragsarm, gern "auf DV umstellen" würde ausgeschöpft. Alle einfachen Massenvorgänge - Rechnungsschreibung als Beispiel - laufen hervorragend.

Je nach Unternehmen hat sich seit mehr oder vielen Jahren die Anforderung auf Gebiete verlagert, die in ihren Anforderungen schwieriger zu formulieren sind: Die Spitze dieses Berges ist die Forderung nach Systemen, die letztlich einem (hochbezahlten - aber auch verunsicherten) Manager Entscheidungen ersparen oder zumindest durch eine Flut von angeblich objektiven Daten erleichtern sollen.

Mit zunehmender Komplexität vermag der Anwender immer weniger zu formulieren, was er eigentlich will.

Mit dieser Situation konfrontiert ist der DV-Mann versucht, selbst Inhalte und Ziele festzulegen. Das kann auf Vorstands- oder auf Projektleiterebene ein sehr erfolgreiches Modell sein, scheitert aber häufig an Kompetenzstreitigkeiten. Man sollte sich klarmachen, daß wirkliche Entscheidungen nur aus den Köpfen der Betroffenen kommen können - man muß etwas konsequent wollen, und kein Werkzeug kann einem dies abnehmen.

Systembetrieb/Rechenzentrum:

Der zentrale Begriff für Rechenzentrumsleiter lautet "Verfügbarkeit", häufig wird auch statt dessen von "Performance" gesprochen. Im Kern geht es dabei einfach um "Funktionieren", weniger um Inhalte. Diese Situation führt dazu, daß man sich einen möglichst hochautomatisierten und obendrein sicheren Betrieb wünscht - Daten werden angenommen, verändert und wieder zur Verfügung gestellt. Der Schrecken des Rechenzentrums besteht darin, daß dieser Prozeß Oberhaupt nicht oder zu spät erfolgt. Beispielsweise sind Monatsabschlußdaten angeblich unvollständig oder sie stehen zu spät -zur Verfügung. Die Benutzer und die DV-Betreiber selbst sind dabei sogenannten Systemfehlern (bis zum Zusammenbruch einer Postleitung) gegenüber erheblich, weniger tolerant als gegenüber Bearbeitungsfehlern durch den Bediener. Vom "System" wird eine hundertprozentige Lösung erwartet, die man dank langer Erfahrung vom Individuum nicht erwartet. Übersehen wird dabei allerdings oft, daß das "System" ebenfalls von Individuen entwickelt und betrieben wird.

Diese Mentalität findet sich analog in der Diskussion über AKWs: Die gesamte Sicherheitstechnik wird auf das genaueste untersucht und diskutiert, die Qualifikation und psychische Verfassung der Bediener weniger. Nun mag man von einem AKW aus offensichtlichen Gründen erwarten, daß die Technik hochgradig fehlerresistent ist. Ob diese Anforderung in eben so hohem Maße für durchschnittliche kommerzielle DV-Systeme sinnvoll und wirtschaftlich lösbar sein kann, ist zu bezweifeln.

Systementwicklung/Analytiker etc.:

Ob bei gewaltigen Neuentwicklungen oder scheinbar harmlosen Änderungsaufträgen: die Systementwickler (Analytiker, Programmierer, neuerdings "Systemingenieure") produzieren grundsätzlich Fehler. Das kann vor allem bei Änderungen unerwartet schmerzhaft und teuer werden - hier besteht das Risiko einer echten Verschlechterung, wenn auch erfreulicherweise meist vorübergehend.

Das Hilfsmittel gegen derlei lautet Testen. Allerdings muß man sich dazu klarmachen, daß auch der durch Werkzeuge best- gestützte Test voraussetzt, daß der Tester das gewünschte Ergebnis en detail kennt. Dies bedeutet, daß das gewünschte Ergebnis genau bekannt ist und durchdacht wurde.

Die Realität ist eine andere. Die verfügbare Technik läßt eine Unzahl von Modifikationen mit anschließender Umwandlung und begrenztem Text zu. Man probiert einfach so lange, bis etwas herauskommt, was vernünftig erscheint. Die anschließenden Praxisergebnisse sind oft sehr überraschend, und man wundert sich, warum man diese Ergebnisse nicht vorher einschätzen konnte.

Eine Antwort liegt darin, daß man durch die extreme technische Unterstützung von theoretischen Gedankengängen weggeführt wird. Entwicklungs- und Testtools sind bereits heute in unüberschaubarem Umfang verfügbar, aber Aufwand/Interesse an diesen Werkzeugen hindern oft den Blick auf das zu erstellende Produkt. In diesem Sinne verfuhren Tools eben dazu, die vorliegenden Aufgabenstellungen nur unzulänglich theoretisch zu durchdringen und zu beherrschen.

Die vorangegangenen Ausführungen und Beispiele mögen Tool-polemisch erscheinen. Um Mißverständnissen vorzubeugen: Wir sind von Tools umgeben, vom Staubsauger bis zum Satelliten - und diese Tools sind im allgemeinen nicht nur nützlich, sondern auch unverzichtbar. Und es ist völlig richtig, auch in der DV nach immer besseren Werkzeugen zu suchen.

Jedoch sollte dem Bemühen um immer bessere Werkzeuge und Methoden ein Bemühen um immer bessere und bewußtere Menschen (Manager, Mitarbeiter, ...) entsprechen. Leider gibt eshierfür weniger Patentrezepte als für perfekte Entwicklungsumgebungen die Einsicht, daß People Systeme anfordern, entwickeln und betreiben, kann jedoch auch ohne Patentrezept ungemein nützlich sein. Anders ausgedrückt: Kompetente Mitarbeiter sind allemal wichtiger als erstklassige Werkzeuge - die Bereitschaft zur sachlichen Auseinandersetzung macht manche Diskussion (gegebenenfalls auch Investition) über (in) Werkzeuge überflüssig (was umgekehrt eben nicht gilt). Ein beträchtlicher Fortschritt ist bereits dann erzielt, wenn DV-Theoretiker - heutzutage auch schon Praktiker - sich still und leise hin und wieder die Frage stellen, ob sie noch wissen, wovon sie reden.