Viele Unternehmen sind inzwischen den Ärger mit dem Anwendungsstau leid. Abhilfe erhoffen sie sich durch den Einkauf von Standardprodukten, die sich bereits im Markt bewährt haben. Von Hauruck-Aktionen rät Werner Schmid* allerdings ab: Oberstes Gebot müsse es sein, die DV-Mitarbeiter rechtzeitig für den Umgang mit Fremdsoftware zu "rüsten".
Die Entscheidung, Standardsoftware zu kaufen oder selbst zu entwickeln, sollte nicht zuletzt vor dem Hintergrund der späteren Auswirkungen getroffen werden. Denn anders, als ein bestimmtes Lehrbuch zu wählen (das auch ein urheberrechtlich geschütztes Produkt und insofern vergleichbar ist), verändert Software den Arbeitsablauf, zu dem sie eingesetzt wird. Lehrbücher und die darin enthaltene Meinung kann man wechseln, wenn neue Erkenntnisse gewonnen sind. Bei Software sieht das ein bißchen anders aus.
Im Vergleich zur Software ist der Mensch viel lernfähiger als jedes Programm. Er reagiert sofort auf Veränderungen, ist flexibel und umsichtig. Durch Erfahrung hat er eine Selbstkontrolle geschaffen, die sehr viel feinmaschiger ist als jede programmierte Plausibilitätskontrolle. Menschliche Arbeits- und Denkvorgänge in Programmen abzubilden, ist daher bis heute nur punktuell und ansatzweise gelungen. Die besten Programme gibt es dort, wo der Mensch bereits ohne Computerunterstützung strengen naturwissenschaftlichen oder mathematischen Regeln gefolgt ist, zum Beispiel bei der Bedienung einer Werkzeugmaschine oder bei der Saldierung von Bilanzkonten.
In Fachgebieten, die überwiegend von der Kreativität und der individuellen Entscheidung der Menschen abhängen, ist jede Software nur ein Sub-Optimum: Neue Situationen, die eine Änderung der programmierten Abläufe verlangen, können nur mühsam in das DV-System eingebracht werden. Die Flexibilität, sofort und im Sinne der unternehmerischen Zielsetzung zu reagieren, wird eingeschränkt.
Es ist eine Binsenweisheit, daß die Softwareentwicklung erst dann beginnen sollte, wenn klar definiert ist, "Was" das Programm leisten soll - vor allem, wenn dieses "Was" so beschrieben wird, daß es logisch korrekt, vollständig und verständlich ist. Keine Binsenweisheit, sondern eine Erkenntnis aus jüngerer Zeit ist, daß das "Was" einer DV-Anwendung, von denjenigen beschrieben werden soll, die das "Was" (ist zu tun) auch ohne Softwareunterstützung ausführen können. In diesem Punkt bestehen offensichtlich die größten Schwachstellen und Defizite der gesamten Softwareentwicklung. Es ist aber erfreulich, zu sehen, wie immer mehr Leute ihren individuellen Wunsch nach DV-Unterstützung artikulieren wollen und auch können.
Diese erste Voraussetzung, um Software selbst zu entwickeln, ist in sehr vielen Unternehmen bereits gegeben. Leider haben es sich viele Anwender zu leicht gemacht und nicht verlangt, den Wunsch nach individueller DV-Unterstützung auch formal (nach Eingabedaten, Verarbeitungsregeln und Ausgabedaten) zu dokumentieren. Dadurch ging möglicherweise viel betriebliches Know-how verloren, falls es nicht durch geeignete organisatorische Maßnahmen (DV-Koordinatoren oder ähnliches) gerettet wurde.
Die zweite Voraussetzung für eine eigene Softwareentwicklung ist eine leistungsfähige DV-Abteilung, die über qualifiziertes Personal, brauchbare Methoden und Werkzeuge sowie über genügend technische Ressourcen verfügt. Auch dies ist in vielen Unternehmen vorhanden, nur dem obersten Management nicht immer bekannt.
Seit CIM bewegt das Thema DV auch die Vorständler
Allerdings muß hier noch eine Fallunterscheidung getroffen werden: So sind in der ersten Gruppe Unternehmen, die ihre DV-Abteilung als "eine unter vielen" betrachten, ohne zu wissen, was sie wirklich leistet und leisten kann. Der zweiten Gruppe gehören Firmen an, die keine eigenständige DV-Abteilung haben; die DV-Unterstützung läuft einfach so mit, vergleichbar der Wasserversorgung oder dem "Strom aus der Steckdose".
Und schließlich gibt es noch die Unternehmen, bei denen alle Fäden der Kommunikation aus dem gesamten Betrieb in der DV-Abteilung zusammenlaufen. Der DV-Leiter weiß hier genau, wer wann welche Daten und Informationen braucht, was die Anwender damit tun und was daraus entsteht. Aber gerade weil diese DV-Abteilungen so intensiv mit der Aufrechterhaltung der innerbetrieblichen Daten- und Informationsverarbeitung beschäftigt sind, weiß die Unternehmensleitung nicht, was in der "DV" wirklich läuft, was möglich und was unmöglich ist.
Erst die vor rund zwei Jahren einsetzende CIM-Euphorie hat auch dem Topmanagement die Grenzen der "Computerisierung" deutlich aufgezeigt: Unternehmen, deren Kommunikationsstruktur, bezogen auf die Produktfertigung und -verteilung, nicht klar umrissen und dokumentiert ist, können nicht auf die "CIM-Welle" aufspringen. Sie haben einen erheblichen Nachholbedarf: Zunächst müssen Datenstrukturen und Verarbeitungsfunktionen definiert werden, bevor einzelne CIM-Komponenten in den Betriebsablauf integriert werden können.
Dazu fehlen aber in vielen Unternehmen die zuvor genannten Voraussetzungen - ein Faktum, das in den oberen Managementkreisen offensichtlich nicht bekannt ist. Gleichzeitig aber will die Geschäftsleitung am Segen der Modernisierung und Rationalisierung durch DV-Unterstützung teilhaben. In diesem Punkt hat sich seit zwanzig Jahren nichts geändert.
Das Management ist offensichtlich den Ärger der vergangenen Jahre über die eigene DV-Abteilung leid und erhofft sich Abhilfe durch "fertige" Software, die sich am Markt schon bewährt hat. Die DV-Abteilung oder der DV-Verantwortliche haben wenig Chancen, sich gegen diese Argumentation zu wehren; die Versäumnisse und Defizite (schlicht der Anwendungsstau) sprechen gegen sie. Niemand macht sich die Mühe, zu ergründen, warum Defizite in puncto Personal, Methoden, Verfahren und Werkzeuge zur Softwareentwicklung vorhanden sind. Da diese aber gar nicht oder nicht schnell genug behoben werden können, bleibt nur die Möglichkeit, aus der angebotenen Standardsoftware das beste Produkt zu wählen.
Damit beginnt eine Phase der Umkehrung des Leidensdrucks: Waren es bisher die Anwender in den Fachabteilungen, die immer warten mußten und vertröstet wurden, so sind es jetzt die DV-Mitarbeiter, die sich mit einer neuen Qualität von Problemen befassen müssen: Programme, die sie nicht kennen und mit denen sie konkurrieren müssen. Plötzlich entsteht eine Meßlatte zur Beurteilung der DV-Abteilung.
Schlimmer jedoch als die Spannungen, die in diesem Fall ganz natürlich auftreten, ist der Verlust des Wissens darüber, was die neuen Programme wirklich tun. Es ist nicht bekannt, welche komplexen Abhängigkeiten sich hinter den Funktionen verbergen. Eine einzige falsche Job-Anweisung genügt - und das System klemmt.
Der nächste Schritt ist dann, daß die DV-Mannschaft um die Fertiglösung "drumherum" programmiert: Änderungen werden beantragt und durchgeführt, Schnittstellenprogramme entwickelt und "eingeflickt", zusätzliche Prüfungen eingeführt, nachgeschult und nachgebessert. Doch die Standardsoftware bleibt, was sie ist: ein Stück betriebsfremder Logik, an die sich die eigene Organisation anzupassen hat.
Kleine Unternehmen, die über keine DV-Abteilung verfügen, mußten ihren eigenen Weg zur DV-Unterstützung mit Hilfe von Standardsoftware finden. Das ging, mit vielen Änderungen und Anpassungen (sowohl der Software als auch der Menschen an die Software), so lange gut, bis die natürlichen Veränderungen des Unternehmens einen Punkt erreicht hatten, an dem eine Weiterverwendung der "Standardsoftware" untragbar geworden war. Die Anwendung mußte total erneuert werden, mit allen Konsequenzen. Denn irgendwann ist jede Software ausgereizt und der Betrieb wird unflexibel, in vielen Fällen auch unwirtschaftlich. Ein neues Release kann jetzt auch nicht mehr helfen, denn der Kern, das Verarbeitungsprinzip der Programme, paßt nicht mehr. Dieser Effekt tritt im übrigen auch bei Systemsoftware, bei Betriebssystemen ebenso wie bei Datenbanken auf.
Mit der Einführung der DV wurde das Wissen der Mitarbeiter über die Betriebsabläufe in die Software verlagert. Anfänglich etwas "holprig" im Stapelbetrieb - das "Gewußt-wie" war jedoch auf Tastendruck beliebig abrufbar. Es trat ein Lerneffekt ein: Die Organisation paßte sich der Software an und die Mitarbeiter vergaßen, was sie früher gelernt und gemacht hatten. Die zweite Generation, aufgewachsen mit der Online- und Dialogverarbeitung, bestand bereits aus den Nachfolgern der früheren Mitarbeiter in den Fachabteilungen. Fach- und DV-Kenntnisse waren nicht notwendig, da alles im Dialog geführt wurde. Wenn der Computer oder auch nur das Programm ausfiel (was zum Glück nicht oft vorkam), tappten diese Mitarbeiter buchstäblich im dunkeln.
Die nächste Generation sitzt nicht mehr vor Terminals - nämlich dann, wenn CIM-Konzepte Realität geworden sind. Tritt irgendwo im unentwirrbaren komplexen Gebilde der Daten-Funktionen-Abhängigkeiten eine Störung auf, stehen zumindest Teile des gesamten Betriebs still. In diesem Fall kann keiner mehr sagen, wo der Fehler zu suchen ist. Dieses Symptom ist bereits heute vielfach zu beobachten, so zum Beispiel schon bei relativ harmlosen Schnittstellenproblemen.
Wer dagegen seine DV-Verantwortlichen "rüstet", sie durch Aus- und Weiterbildung stark und kompetent gemacht hat und gemeinsam mit den Anwendern nicht nur die Konzepte erarbeitet, sondern auch implementiert, wird den Vorteil eigener Softwareentwicklungen durchaus spüren: Er ist in der Lage, flexibel und nicht nur auf Störungsfalle zu reagieren, sondern insbesondere dann, wenn der Markt eine flexible Reaktion erwartet.
Der Markt muß ständig im Auge behalten werden
Wer auf Standardsoftware setzt - und es sprechen sehr viele Gründe dafür -, sollte diese Entscheidung konsequent verfolgen. Das bedeutet, ständig über das Marktangebot informiert zu sein und sich Fachwissen über die technischen Details der angebotenen Software anzueignen. Somit wäre der Anwender auch in der Lage, ein bestimmtes SW-Produkt rasch gegen ein anderes auszutauschen, um die geforderte betriebliche Flexibilität zu erhalten.
Diese Strategie erfordert allerdings ein personelles, organisatorisches und technisches Umfeld besonderer Prägung: Der Wechsel oder auch nur die sprunghafte Änderung von Software - was beim Release-Wechsel sehr häufig vorkommt - muß geplant, implementiert, getestet und geschult werden. Dies gilt auch für Eigenentwicklungen, nur daß der Aufwand bei Fremdsoftware höher ist, da die notwendigen Informationen erst einmal in Erfahrung gebracht werden müssen.
Wer Software selbst entwickeln will, muß bereit sein, die dazu erforderlichen Voraussetzungen in personeller, organisatorischer und technischer Hinsicht zu erfüllen. Da es wegen der notwendigen Arbeitsteilung bei Softwareentwicklungen so etwas wie einen "kritischen" Punkt für den personellen Mindestaufwand gibt, bleibt die eigenständige Softwareentwicklung vorwiegend großen Unternehmen vorbehalten.
Die "Ideallinie" ist dort erreicht, wo betriebsspezifische Programme, in denen das eigentliche Know-how des Unternehmens steckt, selbst entwickelt und gepflegt werden. Für "allgemeine" Anwendungen sollte das Angebot an Standardsoftware genutzt werden. Diese Methode entspricht genau der Unternehmensstrategie der "Erfolgreichen".
* Werner Schmid ist Geschäftsführer der GPS Gesellschaft zur Prüfung von Software mbH, Ulm.