Laut ISIS-Katalog sind heute noch immer über 60 Prozent der am Markt angebotenen Standard-Programme weniger als fünfmal installiert. Und das zu einem Zeitpunkt, zu dem jeder Anwender Mittel und Wege sucht, um von den horrenden Software-Kosten herunterzukommen. Daß viele Anwendungen sich nicht für breite Kreise standardisieren lassen, ist klar. Wie aber sieht es bei Unternehmen einer Branche aus? Kann nicht hier ein Ansatz gefunden werden, gemeinsam Software zu entwickeln und gemeinsam einzusetzen? "Eine solche Entwicklung" - so Thilo Tilemann vom BIFOA-Institut - "kann nur dann erfolgreich sein, wenn sie hochkarätiges Anwendungs- und DV-Wissen integriert." CW befragte drei Spezialisten. hö
Prof. Dipl.-Ing. Peter Canisius
Bundesanstalt für Straßenwesen, Köln
Software-Portabilität: Oft zitiert - seiten erreicht. Spätestens nach der schrittweisen Einführung des Unbundling - der gesonderten Berechnung für Software und Hardware - wurde den bis dahin in dieser Sache arglosen Benutzern - von Datenverarbeitungsanlagen klargemacht, daß die Software im Grunde der teuerste Teil der Datenverarbeitung ist. Aber auch die von eigenen Programmierern hergestellten Programme zeichnen sich durch mangelnde Übersichtlichkeit und Gliederung, fehlende Dokumentation sowie rigorose Ausnutzung der in den Compilern mancher Hersteller eingebauten Capricen aus. Sämtlich Eigenschaften, die einer Verwendung eines solchen Programms auf einer anderen DV-Anlage entgegenstehen.
Inzwischen haben mündige DV-Anwender erkannt, daß eine Software, die bei jeder Umrüstung umgestellt werden muß, eine Software, die man seinem Nachbarn nicht weitergeben kann, eine Software, die man darum auch nicht verkaufen kann, in höchstem Maße unwirtschaftlich ist.
Während beim Begriff der Normung von Programmen wenigstens noch einigermaßen klar war, was darunter zu verstehen ist (dennoch aber feststeht, was, wie zu normen ist), wurden unter dem Begriff "Portabilität" die abenteuerlichsten Eigenschaften subsumiert. Leider befinden sich zudem die Hersteller von Computern seit Anbeginn in einem höchst unedlen Wettstreit bei der Herstellung von Compilern. Jeder versucht nämlich, den anderen mit eleganten Möglichkeiten zu überbieten, und somit gibt es leider nur kleine gemeinsame Untermengen von Compilern, die eben in allen Compilern vorhanden sind. Diese gilt es bei einer eventuellen gemeinsamen Software-Entwicklung herauszufinden und - logischerweise - jede portabel anzulegende Programmierung auf diese gemeinsame Grundmenge zu beschränken.
Es gab einmal einen Fachnormenausschuß Informationsverarbeitung, und es gibt ihn noch. Und der sollte eigentlich eine Norm aufstellen, wie man Programme macht und wie man sie dokumentiert. Aber dieser Ausschuß verabschiedete eine solche Norm lange, lange nicht. Daher entschlossen sich Fachleute des Bauwesens bereits 1974, selbst eine praxisnahe Vorschrift zur Dokumentation von DV-Programmen zu schaffen: Die "Dokumentation für DV-Programme im Bauwesen". Ein Schritt weiter auf dem Weg, gemeinsam erstellte Programme gemeinsam nutzen zu können.
Thilo Tilemann
Projektleiter, BIFOA-Institut, Köln
Die zahlreichen Versuche, individuelle Problemstrukturen verschiedener Anwender über ein Standardprogramm zu scheren, haben zu ernüchternden Erfahrungen geführt. Nach dem ISIS-Katalog sind immer noch über 60 Prozent der am Markt angebotenen Standard-Programme weniger als fünfmal installiert.
Kommerzielle Anwendungssysteme sind im wesentlichen nur für das Rechnungswesen branchenübergreifend standardisiert. Für die übrigen Aufgaben gibt es branchenunabhängig allenfalls Insellösungen. Andererseits sind gerade kleinere und mittlere Unternehmungen trotz vorhandener Generatoren und Modularsysteme selten in der Lage, individuelle Anwendungsprogramme selbst zu entwickeln oder ihre externe Entwicklung allein zu finanzieren. Branchensoftware erscheint daher als ein sinnvoller Kompromiß für diese Zielgruppe.
Die bisherigen Erfahrungen mit der Entwicklung von Branchensoftware zeigen jedoch zweierlei: Die Entwicklung ist nur dann erfolgreich, wenn sie hochkarätiges Anwendungs- und DV-Wissen integriert und wenn sie in Gemeinschaftsaktionen - bei Bedarf mit Hilfe öffentlicher Förderung - erfolgt. Dabei kann je nach Branchenstruktur und Alternativen wie DV in oder außer Haus ein anderes organisatorisches Konzept die gemeinsamen Aktionen bestimmen. Einerseits gibt es Branchen mit zahlreichen isolierten, oft "unmündigen" Unternehmungen, wie etwa Handwerks- und Dienstleistungsbetriebe, andererseits solche mit einer überschaubaren Anzahl kommunizierender und aufgeschlossener Anwender. Im ersten Fall wird die Normierung von Aufgabenlösungen teilweise von dominierenden Marktparteien getragen, zum Beispiel in Form von Standard-Kontenrahmen der Kraftfahrzeug Hersteller für die Kfz-Betriebe. Standards gehen aber auch erfolgreich von Gemeinschaftsrechenzentren aus, wie die branchenspezifischen Kennzahlen-Systeme der Datev zeigen. Im anderen Fall erweisen sich temporäre Anwendergemeinschaften als zweckmäßig. Nach mbp/Inftratest liefern die Branchenverbände jedoch nur ein Prozent der Standard-Software.
Wer in diese Anwendergemeinschaften das erforderliche DV-Wissen einbringen sollte, richtet sich insbesondere auch nach der DV-Infrastruktur der Unternehmungen. Benutzer großer Inhouse-Rechner sind sowohl mit Rechnerherstellern als auch mit Softwarehäusern gut gefahren. Dagegen ist mancher MDT-Anwender von der mitgelieferten Branchensoftware herb enttäuscht worden. Wegen der Inkompatibilität der Kleinrechner war oft auch ein Systemwechsel mit erheblichem Aufwand verbunden. Gerade kleine und mittlere Anwender sollten daher Kooperationen mit Service-Rechenzentren überlegen, die neben fundierten Anwendungserfahrungen auch Rechenleistung zu attraktiven Kosten bieten.
Friedrich Winkelhage
Vorstandsmitglied der GMD - Gesellschaft für Mathematik und Datenverarbeitung, St. Augustin
Von Anwendern betriebene gemeinsame Entwicklung von Anwendungssoftware bietet bereits seit einiger Zeit eine zusätzliche Alternative zur Eigenentwicklung oder zum Kauf von Standardsoftware der Hersteller und Softwarehäuser. Intensive Mitwirkung der künftigen Anwender bei der Erhebung der Anwenderanforderungen, etwa im Rahmen einer Branche, dient der Erfassung individueller Wünsche auf breiter Basis und ihrer Berücksichtigung bei der Gestaltung der gemeinsamen Anwendungssoftware.
Bei den am Markt sonst angebotenen Standardpaketen geht der Entwicklung eine solche Untersuchung selten Voraus, da sie nur sehr potente Anbieter durchführen können. Die Fähigkeit der Standardsoftware, individuelle Wünsche des Anwenders abzudecken, läßt daher einiges zu wünschen übrig. Es ist in der Regel der Anwender, der sich beim Einsatz von Standardsoftware anpassen muß. Aus wirtschaftlichen Gründen können sich andererseits besonders kleine und mittlere Unternehmen eine Eigenentwicklung, die diese Besonderheiten berücksichtigt, nicht leisten. Bei gemeinsamer Anwendungssoftware werden die Entwicklungskosten von vielen getragen. Für das einzelne Unternehmen eröffnet sich damit die Möglichkeit, billiger an eine maßgebende mitgestaltende Lösung zu kommen.
Wenn es von den Anwendern gewünscht wird, kann die Übertragbarkeit ein wesentliches Ziel der gemeinsamen Entwicklung sein. Damit sichern sich Unternehmen ihre Unabhängigkeit von Hardware-Herstellern. Viele Anwender, die bereits Erfahrung mit von Hardware-Herstellern angebotener Standardsoftware haben, betonen Wichtigkeit dieser Forderung.
Insgesamt sind wir der Meinung, daß gemeinsame Anwendungssoftware eine interessante Alternative insbesondere für kleine und mittlere Unternehmen ist, die sonst gezwungen sind, auf das ihren Anforderungen nicht immer entsprechende Angebot dies Marktes zurückzugreifen.
Aber auch hier sind einige Probleme zu bewältigen. Die Erhebung individueller Anforderungen ist zeit- und kostenintensiv. Der damit verbundene Aufwand wird oft unterschätzt. Von der Intensität der Mitwirkung aller Betroffenen hängt jedoch die Akzeptanz der Anwendungssoftware im Unternehmen wesentlich ab.
Bei der Benutzer- und Systemspezifikation müssen Kompromisse geschlossen werden, wenn das zu entwickelnde System bei der Vielfalt der Anforderungen noch handhabbar bleiben sollen. Die Abstimmungsprozesse sind oft langwierig und erfordern passende Konfliktlösungsmechanismen in der Entwicklungsorganisation.
Portabilität erfordert zusätzlichen Entwicklungsaufwand. Softwaretechnologie für Entwicklung sehr flexibler und portabler mehrfach verwendbarer Anwendungssoftware ist bestenfalls Ansätzen vorhanden. Das Wartungsproblem eines zwangsläufig komplexen Softwaresystems mit vielen Varianten muß nicht nur technisch sondern auch organisatorisch gelöst werden, wenn für die Anwender eine kontinuierliche und wirtschaftliche Nutzung sichergestellt werden soll.