Strategische Bedeutung vielfach noch unterschätzt:

Software-Entwicklung ist Management-Sache

16.12.1988

MÜNCHEN (qua) - Von der Frage, wie der Softwarebedarf eines Unternehmens gedeckt wird, hängt oft die Wettbewerbsfähigkeit des Betriebs ab. Deshalb sollte das Management diese Entscheidung keineswegs delegieren. So Richard Mills, Professor an der Harvard University und Chef-Berater für American Express, beim ersten Kongreß der Münchner Softlab GmbH.

Den spezifischen Interessen des Veranstalters entsprechend lautete das Motto der Tagung "Strategien der Software-Entwicklung". Die Themen der Vorträge kreisten zumeist um die Begriffe Computer Aided Software Engineering (CASE) und integrierte Projekt-Unterstützungs-Umgebung (IPSE).

"Das Management muß die CASE-Technologie genauso behandeln wie jedes andere Investitions- oder Strategie-Problem, denn eine Entscheidung für CASE bezieht beides ein: Investition - von mehr als nur Geld - und Strategie", forderte Professor Mills. Die Kriterien seien hier dieselben wie bei jeder anderen Unternehmensentscheidung: Kosten gegen Nutzen und Risiko gegen Gewinn.

Einen ähnlichen Standpunkt vertrat der Unternehmensberater und ehemalige Bertelsmann-Geschäftsführer Helmut Bender: Anstatt die Softwarekosten in ihrem Verhältnis zum Unternehmensumsatz zu bewerten, sei die Software besser unter einem Kosten-/Nutzen-Aspekt zu betrachten.

Grundlegend ist die Entscheidung, ob Standardsoftware eingesetzt oder eine sogenannte Individuallösung entwickelt werden soll. Mit den Rahmenbedingungen, unter denen die eine oder die andere Möglichkeit sinnvoll sein kann, setzte sich Heinz Kratt, Hauptabteilungsleiter Software-Entwicklung beim Kölner Gerling-Konzern, auseinander.

Kratt kam zu dem Ergebnis, daß Standardpakete in Großunternehmen immer dann effektiv einsetzbar seien, "wenn Standardprobleme in operativen Bereichen DV-technisch unterstützt werden sollen". Strategische Unternehmensziele, "also primär die Orientierung am Markt", könnten jedoch mit Standardsoftware nur bedingt unterstützt werden. "Aufgrund der zunehmend enger werdenden Märkte sind marktorientierte Individualität und schnelle Reaktionsfähigkeit gefordert; dies kann per definitionem mit Standardsoftware nur schwierig erreicht werden."

Allerdings, so merkte Kratt an, werde im Mainframe-Bereich die Entscheidung, ob Standard oder individuell, nicht primär durch das verfügbare Angebot, sondern eher durch unzureichende Ressourcen im Entwicklungbereich und mangelnde Produktivität der Entwicklungsabteilungen geprägt: "Eine Vielzahl der Entscheidungen für Standardsoftware sind Zwangsentscheidungen."

Überdies seien bei der Entscheidung für Standardpakete "gerade in Großunternehmen" immer wieder Fehleinschätzungen der entstehenden Kosten und Aufwände zu beobachten. Die Folgeaktivitäten zur Integration in die bestehende DV-Landschaft würden meist unterschätzt. "Standardsoftware ist und bleibt ein Stück betriebsfremder Logik, an die sich die Unternehmensstruktur anzupassen hat."

Besonders stark betroffen seien davon die Unternehmen mit hochintegrierten Softwaresystemen und standardisierten Software-Produktionsumgebungen. "Die wachsenden Bemühungen, den Software-Entwicklungsprozeß im Sinne einer industriellen Fertigung zu organisieren, erschweren gleichzeitig die Integration von Einzelaggregaten."

Die Forderung des Kölners lautete deshalb, daß Standardpakete sowie Entwicklungssysteme sowohl an strukturelle Gegebenheiten als auch an Hardwarekomponenten anpaßbar sein müßten. "Die Zeiten, in denen eine Software-Entscheidung eine Hardware-Entscheidung bedingt - oder umgekehrt -, sollten bald der Vergangenheit angehören."

Eine Entscheidung für "individuelle" Software führt zu der Frage, welche Methoden und Werkzeuge zu verwenden seien. Mills vertrat die Ansicht, daß die Auswahl eines methodischen Rahmens die Grundlage bilden und nach Möglichkeit nicht revidiert werden sollte: "Ein Rahmen, der sich ständig bewegt, ist kein Rahmen."

Auf dieser Basis ließen sich die einzelnen Software-Werkzeuge dann austauschen - dem jeweils aktuellen Stand der Technik entsprechend. Zwar entwickelten sich auch die Vorgehensweisen ständig weiter, doch könne der Anwender es sich einfach nicht leisten, "jeden Dienstagmittag" seine Methode zu ändern. Von dem Versuch, eigene CASE-Werkzeuge zu schreiben, riet Mills den Anwendern ab: "Lassen Sie die Technologie den Technologen!"

Wolfgang Thury, Mitglied der Softlab-Geschäftsführung, verglich das Konzept der integrierten Projektunterstützungsumgebung mit der Idee der computerintegrierten Fertigung: "CIM als fertiges Produkt gibt es nicht; es ist ein Lösungsansatz. Die ideale IPSE gibt es ebensowenig; die heute verfügbaren Produkte sind Prototypen."

Walter Boltz, Geschäftsführer der Wiener Diebold-Dependance, stellte fest: "CASE ist keine Revolution, sondern die evolutionäre Weiterentwicklung von Methoden und Werkzeugen. Während in der Hardwaretechnologie selten mehr als drei Jahre zwischen Basisinnovation und kommerzieller Nutzung liegen, sind die Zeiträume bei der Softwaretechnologie zumindest dreimal länger."

Orakelte der Analyst: Meiner Überzeugung nach werden auch 1995 noch zumindest 20 bis 30 Prozent der Unternehmen Software so entwickeln, wie man dies heute eigentlich nicht mehr tun sollte - nämlich unstrukturiert, in einer Sprache der dritten Generation und ohne CASE-Tools."

Forderungen an ein Software-Werkzeug

(nach Helmut Bender)

- Der Werkzeug-lnput entspricht der Benutzerdokumentation.

- Schnelles Prototyping

- Die Prototypen müssen das Endprodukt widerspiegeln.

- Frei von Verwaltungsballast

- Implizierte Dictionary-Automatik

- Das Werkzeug generiert strukturierten Code; die Software muß auch ohne Werkzeug zu pflegen sein.