Bundesdeutsche EDV-Leiter haben eine ungebrochene Vorliebe für die Eigenprogrammierung, obgleich sich mit Standard-Software das EDV-Budget spürbar ausdünnen ließe.
Unbelehrbarkeit oder doch "besseres Wissen": Woran liegt's, daß fertige Programme bei den für die Beschaffung Verantwortlichen einen so schweren Stand haben?
Zunächst ist festzustellen, daß die Vorteile mehrfach verwendbarer Software niemandem mehr erklärt werden müssen. Voraussetzung: Sie ist überhaupt im Individualfall anwendbar.
Angesichts einer ins Rechenzentrum stehenden Inflation der Software-Ausgaben braucht das Problembewußtsein der Anwender nicht eigens geschärft zu werden. (Die Marktforschungsgesellschaft IDC glaubt, daß sich die Software-Aufwendungen der europäischen Benutzer in den nächsten vier Jahren verdoppeln.) Nur konsequent ist, die Effektivität bei der Software-Entwicklung und -Beschaffung zu verbessern. Nach wie vor scheiden sich die Geister erst wenn die Frage "Make or buy?" am konkreten Umstellungsprojekt gestellt wird. Daß das Wahlergebnis bisher stets gegen die Software von der Stange ausfiel, ist bekannt (siehe oben). Als Grund für die Ablehnung wird meistens angegeben, "bevor ich ein Fremdpaket umständlich (und aufwendig) anpasse, schreibe ich das Programm lieber selber."
Andersrum: "Es gibt zuwenig Standard-Programme, die den Wunsch nach dem Maßanzug vergessen machen können."
Die Folge: Von rund acht Milliarden Mark, die Anwender hierzulande jährlich für Entwicklung, Kauf und Pflege von Software ausgeben, werden ganze 300 Millionen (3,7 Prozent) "outside" (bei Software-Häusern und Hardware-Herstellern) deponiert, wie eine Diebold-Studie feststellt. Für Marktkenner sicherlich nicht überraschend: Den Löwenanteil erlöst mit 180 Millionen Mark IBM - wer sonst?
Die "reinen" Software-Produzenten müssen sich mit einem bescheidenen Rest von 54 Millionen- Mark zufriedengeben - wer da behauptet, satt zu werden, lebt offenkundig von der Einbildung.
Der Branche ist klare das Produktgeschäft der unabhängigen Software-Fabriken wird auch auf absehbare Zeit keine wesentlichen Fortschritte machen.
Dennoch ist zu differenzieren: Ein fremdes Paket wird um so eher akzeptiert, je systemnäher es ist - logisch, daß Betriebssoftware bessere Verkaufschancen vorfindet als Anwendungssoftware.
Tatsächlich täuscht hier beim ersten Ausgenschein die Zahl der beispielsweise im Isis-Softwarekatalog aufgelisteten Programme über die wahren Marktverhältnise hinweg, weil der bloße Eintrag nichts über den Grad der Akzeptanz aussagt. Immerhin: Ladenhüter fliegen aus dem Infratest-Report nach zwei Jahren heraus. So fielen von 77 bis 78 rund 330 Programme dem Rotstift zum Opfer. Der Verdacht drängt sich auf, daß hier eine Reihe von Anbietern den Isis-Katalog als kostenlosen Werbeträger "mißverstanden" hat und mit verkappten Individualprogrammen Beratungsaufträge zu ködern versuchte.
Das klingt zwar abträglich, obwohl das einzelne Software-Produkt hervorragend sein kann - nur nicht übertragbar ist.
Physikalische Meßgrößen fehlen
Und hier offenbart sich die ganze Crux der Software-Auswahl: Für die Beurteilung der Leistung von Software gibt es keine physikalischen Meßgrößen. Da dies auch so bleiben wird, fordern nur Illusionisten so etwas wie ein Gütesiegel für Software.
Auch die Funktionsbeschreibungen der Hersteller sind nicht gerade Aufklärungshilfen, denn jeder Anbieter verwendet seine eigene Nomenklatur, so daß Fehlinterpretationen an der Tagesordnung sind.
Oft kann der Interessent nur durch aufwendige Tests feststellen, ob er die Produktbeschreibungen verstanden hat. Aber welcher EDV-Chef hat schon die Muße, die Software-Evaluation dermaßen auf die Spitze zu treiben?
Was den Praktiker auszeichnet: Er behilft sich mit Annäherungsversuchen. Und bei der Software sieht es so aus, daß Anwender-Aussagen zu vergleichenden Akzeptanzlisten zusammengestellt werden (Datapro Honor Roll etc.). Die Erfahrungen anderer Software-Anwender zu nutzen, um Fehler bei der eigenen Programm-Auswahl zu minimieren, wäre immerhin ein Ansatz, die Akzeptanz von "Fertig-Ware" zu verbessern. Eine Garantie für die Leistungsfähigkeit, Qualität und Zuverlässigkeit eines Software-Produktes ist damit freilich nicht gegeben - aber hat die, wer selbst programmiert?