AMSTERDAM (qua) - "Die sogenannte Softwarekrise ist oft hausgemacht - verursacht durch organisatorische Versäumnisse, nicht durch den Mangel an Werkzeugen und Umgebungen." Mit dieser These eröffnete Manfred Lang, Direktor des Diebold Information Centre, die diesjährige Tagung "Brennpunkt Software-Management".

Die Crux versteckt sich in einer Binsenweisheit, die Henk Sol, Professor für Informationssystementwicklung an der Technischen Universität Delft unmißverständlich aussprach: "Software-Engineering ist kein Selbstzweck." Technologie allein mache noch keinen Unterschied; sie müsse vielmehr in den unternehmerischen Entscheidungsprozeß eingebunden werden.

Ähnlich formulierte es Alan Bignall, Vice President im Bereich System-Support-Services bei IDS Financial Services in Minneapolis: "Technologie ist niemals strategisch - es sei denn für einen Anbieter wie IBM; vielmehr ist sie ein Mittel zur Durchsetzung strategischer Entscheidungen."

Angesichts des für 1992 anstehenden europäischen Binnenmarkts sehen sich viele DV-Anwender mit höheren Anforderungen konfrontiert. Fritz Jagoda, Leiter des Geschäftsbereichs Technology und Anbieterstrategie-Beratung bei der Diebold Deutschland GmbH in Frankfurt, nannte hier unter anderem die expansionsbedingte Notwendigkeit neuer Vertriebskontroll- und Logistiksysteme sowie die Verbesserung der unternehmensweiten Kommunikation.

Um diesen Anforderungen gerecht zu werden, sei, so Jagoda, zusätzliches Know-how erforderlich, vor allem beim Einsatz von Standards für die Entwicklung von mehrsprachigen und multinationalen Anwendungen sowie von Kommunikationskonzepten und im Hinblick auf das Management von Multivendor-Umgebungen.

Wettbewerbsnachteile durch Know-how-Weitergabe

Um die eigene Entwicklungsabteilung zu entlasten, vergibt eine Reihe von Unternehmen ihre Softwareprojekte nach draußen. Eckhard Bollow, Entwicklungsleiter Automatisierte Informationssysteme bei der Deutschen Lufthansa, erkennt darin allerdings die Gefahr von Wettbewerbsnachteilen durch die Weitergabe von Know-how an Dritte. Auf diesen Punkt sei deshalb schon bei Vertragsabschluß zu achten.

Die Alternativen zu der externen Projektvergabe sind die Eigenentwicklung auf der einen, und die Beschaffung von sogenannter Standardsoftware auf der anderen Seite. Die "Software von der Stange" hat für Bollow den Vorteil, daß sie bereits existiert - wenn sich auch der Anbieter keineswegs für ihre Fehlerfreiheit verbürge, so doch für ihre Stabilität. Zudem seien die Kosten kalkulierbar und die Weiterentwicklung Herstellersache.

Allerdings müsse der Kunde dafür gewisse Nachteile in Kauf nehmen; unter anderem solle er sich darüber im klaren sein, daß er keine 100-Prozent-Lösung erhält. Außerdem könne der Anbieter seine Klientel stets zum Einsatz des neuesten Release nötigen, indem er die Wartung älterer Versionen einstelle.

Fällt die Entscheidung zugunsten der Eigenentwicklung aus, so taucht die Frage nach dem geeigneten Instrumentarium auf. Carma McClure Vice President bei der Extended Intelligence Inc. in Chicago, empfiehlt hier zunächst eine Analyse des hauseigenen Entwicklungsprozesses: "Bevor Sie sich für ein Case-Tool entscheiden, fragen Sie sich, in welcher Phase Sie Ihre Produktivität verbessern wollen."

Case-Umgebungen sind bislang fast ausschließlich für die Entwicklung neuer Systeme einsetzbar; das Problem der Software-Altlasten" brennt vielen Anwendern jedoch genauso auf den Nägeln. Eine "geologische Verwerfung zwischen der Technologie und den Anwendungssystemen" konstatierte denn auch Reinhard Krommes, Abteilungsleiter Verteile Systeme bei der Europäischen Kommision in Luxemburg:. Wir nutzen die Technologie der 90er Jahre, aber unsere Anwendungssysteme stammen aus den 70ern."

Den Wartungsaufwand solcher Systeme bezifferte George DiNardo, Mitglied der Geschäftsleitung bei der Mellon Bank in Pittsburgh: "Für jeden Dollar, der in die Entwicklung gesteckt wird, müssen im Verlauf des Lebenszyklusses weitere neun Dollar für die Maintenance ausgegeben werden." Die Lösung dieses Problems werde zunehmend zur wettbewerbsentscheidenden Frage.

Folglich plädierte der Banker dafür, die Case-Technik über den gesamten Maintenance-Lifecycle auszudehnen. Die Mellon Bank habe bereits 1984 begonnen, sukzessive den Wartungsprozeß zu vereinfachen - durch eine wiederverwendbare Entity-Library, grafische Analyse- und Design-Tools, einen automatischen Cobol-Restrukturierer, ein Dateivergleichsprogramm, einen Static Analyzer für Cobol sowie einen Anwendungsgenerator.

Als Thema der Zukunft bezeichnete DiNardo das sogenannte Reverseengineering existierender Anwendungen. Damit sei die Möglichkeit gemeint, Datenauszüge sowie Extrakte der jeweiligen Anwendungslogik zu erstellen und anschließend in grafische oder objektorientierte Formate zu überführen.

Innerhalb der kommenden zwei bis drei Jahre sollen, so der US-Anwender, entsprechende Werkzeuge verfügbar sein. Bereits realisiert seien dagegen Tools für das "Re-Engineering", also die Restrukturierung von Anwendungen durch Eliminierung redundanter Daten und logischer Fehler sowie durch die Modularisierung in funktionelle Einheiten.

Die Vereinheitlichung geht mit Risiken einher

Ein Thema der Gegenwart ist auch die unternehmensweite Integration der Informationssysteme. Daß die angestrebte Vereinheitlichung neben Vorteilen auch Risiken in sich birgt, betonte Walter Boltz, Geschäftsführer der Diebold GmbH in Wien: Komplexe Systeme, so der Österreicher, litten an mangelnder Stabilität und höherer Verletzbarkeit.

Fazit des Unternehmensberaters: Auch die Integration dürfe nicht zum Selbstzweck werden; vielmehr müsse sie sich durch geschäftliche Notwendigkeiten rechtfertigen lassen. Die Vorteile seien dabei unbedingt gegen die Kosten und Risiken abzuwägen.

Mit Problemen bei der Realisierung supranationaler Software-Entwicklungen beschäftigte sich Lutz Martiny, in der Geschäftsleitung der Münchner GAO für Forschung und Entwicklung zuständig. Neben technischen Schwierigkeiten bei der Integration unterschiedlicher Hard- und Softwaresysteme stünden Personalprobleme, die aus unterschiedlichen Sprachen und Arbeitsauffassungen resultierten.

Die Gretchenfrage nach dem Return on Invest

Auf der organisatorischen Seite müsse vor allem die Frage der Standardisierung sowie die Zuordnung von Verantwortlichkeiten gelöst werden. Bezüglich der Software-Entwicklung sei zu klären, ob die Aufgaben der Anforderungsdefinition, der Design-Entwicklung und der Wartung in der Zentrale oder der jeweiligen Tochtergesellschaft wahrgenommen werden sollen.

Martiny empfahl dem Auditorium weiterhin, ein internationales Beratungshaus zu engagieren: Unternehmensphilosophie und Entwicklungsstandards müßten somit nur ein einziges Mal erklärt werden; auch Sprachprobleme und Reiseaufwand ließen sich so ebenfalls minimieren.

Wichtig sei, daß das Management sich frühzeitig über die unternehmensweiten Standards und die aus der Realisierung erwachsenden Kosten klar werde. Martiny: "Das kann nur vom Vorstand kommen; ein DV-Leiter hat da nicht viel zu melden."

Im Zusammenhang mit der Entscheidung für oder gegen eine informationstechnische Investition wird immer wieder die Gretchenfrage nach dem Return on Investment gestellt. Leif Lundkvist, Vorstandsvorsitzender der ebenfalls in München ansässigen Deckel AG, schlug vor, die Beziehung zwischen Kosten und Nutzen einmal von der anderen Seite her zu beleuchten: "Anstatt zu fragen, wie hoch der Return on Investment ist, sollten Sie vielmehr fragen: Was wird aus dem Unternehmen, wenn wir nicht investieren?"