So alt wie die Datenverarbeitung selbst sind auch immer wieder die Versuche und Überlegungen, die angestellt werden, um die verschiedenartigen Anwendungsprobleme mit Hilfe von Standardanwendungs-Software abzudecken. Die erzielbaren Erfolge sind allgemein bekannt. Standardsoftware als Problemlösung hilft vor allem die Erstellungskosten in Griff zu bekommen, denn gerade im Software-Sektor sind in den letzten Jahren die Entwicklungskosten durch Personalkosten und die wachsende Größe der Anwendungen überproportional gestiegen. Der erhoffte Effekt bei Einsatz von Standard-Software ist verlockend, der Weg hin bis zum erfolgreichen Einsatz jedoch sehr schwierig, wie uns die nachfolgend geschilderten Erfahrungen zeigen.
Auf dem Sektor der System-Software haben die Hersteller seit Einsatz der sogenannten Dritten Rechnergeneration große Anstrengungen unternommen und auch Lösungen geschaffen. Betriebssysteme, Dabenbanken, TP-Monitore und so weiter nehmen in diesem Bereich dem Anwender einen Großteil der Probleme ab.
Im Bereich der Anwender-Software dagegen stellt sich das Problem, Standardlösungen zu schaffen; wesentlich differenzierter. Sofort taucht hier die Frage nach dem Hersteller auf. Unterschiedliche Ausgangsbasen verkomplizieren den Sachverhalt und lassen nur selten herstellerneutrale, allgemein gültige Lösungen zu.
Karriere durch Konkurrenzsituation
Für den Datenverarbeitungsanwender, der Standard-Software entwickeln will, verbleiben, da die Hersteller als Lieferanten neutraler Software ausscheiden, als Alternativen nur artverwandte Unternehmen oder: Software-Büros. Bei artverwandten - Unternehmen trifft man immer wieder auf den Konkurrenzgedanken. Angebotene Lösungen aus diesem Bereich haben speziellen Chauckter. Somit kommen als Erwerbsgewerbe nur noch Software-Büros in Frage. In der Regel entwickeln aber auch diese Unternehmen Software nur aufgrund von vorliegenden Aufträgen, was folgerichtig zu Teillösungen führt und in den seltensten Fällen als umfassende Lösung bezeichnet werden kann.
Größere als branchenbezogene Anforderungen an Standard-Software zu stellen, die über die Probleme eines Sektors hinausgehen, überfordern, so glaube ich, die Möglichkeiten von Standard-Software und zeigen deutlich die Grenzen auf bezüglich Wirtschaftlichkeit, Einsetzbarkeit und Standardisierung.
Ich habe bei meinen Ausführungen bewußt so weit ausgeholt, um zu verdeutlichen, daß es reinem Zufall gleicht, Standard-Software zu bekommen, die unverändert, das heißt 1:1 auf den eigenen Anwendungsfall übernommen werden kann. Folgerung daraus: Anpassung wird in fast jedem Fall erforderlich.
Nur auf den ersten Blick geeignet
Sicht man sich auf dem Software-Markt nach einem bestimmten Produkt um, so erscheinen auf den ersten Blick mehrere der angebotenen Programmpakete geeignet. Auf den zweiten Blick jedoch, und dieser tritt sofort ein, je gründlicher man das Gesamtpaket nach den organisatorischen Möglichkeiten und den einzelnen Programmen durchleuchtet, sitzen im Detail viele kleine Teufel. Dabei gewinnt man als erste Erkenntnis, daß zum Beispiel Programmiersprachen, Betriebssysteme und Richtlinien zugrunde liegen, die im eigenen Haus keine Verwendung finden. Die Art der organisatorischen Vorgaben, der Programmaufbau, die Dokumentation der Programme und die Arbeitsabläufe für das Rechenzentrum passen nicht zur eigenen innerbetrieblichen Organisation.
Bereits an diesem Punkt muß erstmals der Hebel angesetzt werden, um einen möglichst vollständigen Überblick zu bekommen, was einen als Anpassungsaufwand erwartet.
Die zweite, wesentliche Tatsache, die es zu berücksichtigen gilt, ist eindeutig festzustellen, wie groß die einzelnen Programme sind, welche Schwierigkeitsgrade sie beinhalten und ob von der Struktur her Klarheit gegeben ist, denn nur eine genaue Betrachtung des einzelnen Programmes läßt einen gültigen Schluß zu. Dabei sieht man sich immer wieder vor die Entscheidung gestellt, ob man innerhalb des gesamten Programmpaketes ein einzelnes Programm umschreiben beziehungsweise anpassen soll oder, und diese Fälle sind gar nicht selten, ob es nicht gleich effektiver und kostengünstiger ist, einzelne Programme neu zu erstellen.
Schwierigkeitsgrad und Struktur der Programme bestimmen maßgeblich den Grad, bis zu dem man sich in die Problematik eines einzelnen Programmes einarbeiten muß. Zu wenig Einarbeitung schafft bei Einführung und echtem Einsatz im eigenen Betrieb unvermeidlich Schwierigkeiten. Aus Unsicherheit entsteht eine regelrechte Aversion gegenüber dem neuen Software-Paket. Zudem bleibt auch eine große Abhängigkeit gegenüber dem Ersteller der Organisation. Ergänzungs- und Änderungsdienst der Programme werden im Bedarfsfall durch die notwendig werdende Einschaltung von externen Mitarbeitern unbeweglicher.
Nach einer mehrjährigen Phase ausschließlicher Selbsterstellung von Organisationen und Programmen haben wir im letzten Jahr wieder den Versuch unternommen, für einfache, kommerzielle Anwendungsgebiete sogenannte fertige Batch-Software zu kaufen. Unsere gemachten Erfahrungen sehen so aus, daß die Einarbeitung der Mitarbeiter, die ja zwangsläufig vorausgehen muß, und der reine organisatorische Anpassungsaufwand je nach Auslegung der Standard-Software sich auf 25 bis 40 Prozent gegenüber einer eigenen Neuerstellung belaufen.
Dennoch 50 Prozent Gesamtaufwand
Zusätzlicher Aufwand - und dieser darf auf keinen Fall unterschätzt werden - entsteht in Form von höherem Wartungsaufwand, länger dauerndem Änderungsdienst bei Programmfehlern, erforderliche Einarbeitung bei auftretenden Sonderheiten und Fehlersuche bei Kundenreklamationen. Dieser liegt in den ersten Monaten nach dem echten Einsatz fast doppelt so hoch wie bei selbst entwickelten Organisationen. Rechnet man diesen Aufwand noch hinzu, so ergibt das einen Gesamtaufwand von etwa 35 bis 50 Prozent gegenüber einer eigenen Entwicklung.
In bestimmten Fällen erhöht sich der Aufwand nochmals, sofern das Programmpaket durch eventuelle Schnittstellen in eine bestehende Gesamtlösung eingepaßt werden muß.
Diese genannten Prozentzahlen haben Gültigkeit für die organisatorische und hardwaremäßige Anpassung von Standard-Software-Paketen im Batch-Betrieb an die Eigenheiten unseres Betriebes. Vielleicht erscheinen diese Zahlen etwas zu hoch; sie stammen jedoch aus der Praxis. Sie schaffen andererseits jedoch die Voraussetzung eines reibungslosen Ablaufes für unsere 1500 Kunden mit den Besonderheiten, die einem Service-Betrieb anhaften.
Täglich schlechterer Systemdurchsatz
Handelt es sich um keine Batch-Organisation, sondern um eine Organisation in die Datenbanken, TP-Monitore, Dialogfunktionen usw. integriert sind, so wird der Sachverhalt noch schwieriger. Was über den Batch-(...)hmen hinausgeht, verlangt vom EDV-Anwender oft die Einführung neuer oder zusätzlicher Software-Systeme und anderer Hardware-Voraussetzungen, wie zum Beispiel bestimmte Terminals und bestimmte Datenfernverarbeitungseinrichtungen. In diesen FälIen wird ein Anpassen oft unmöglich und zwingt zu der Entscheidung, keine fertige Software zu erwerben, sondern sich bei Erstellung der Organisation und der Programme durch externe Mitarbeiter unterstützen zu lassen; denn es steht fest, daß ein krampfhaftes Anpassen täglich mit schlechterem Durchsatz des Gesamtsystems bezahlt werden muß.
Am Rande noch ein interessanter Erfahrungswert:
Anläßlich eines Herstellerwechsels im Jahre 1973 in unserem Hause, der bedingte, daß alle Programme umgeschrieben werden mußten, haben wir ermittelt, daß auf der Basis von Batch-Verarbeitung der Umstellungsaufwand sich bei etwa 10 bis 15 Prozent des Neuerstellungsaufwandes bewegt.
Zusammenfassend gilt folgende Regel: Steht man vor der Entscheidung, ein neues Gebiet "EDV-mäßig" zu übernehmen, so ist es auf alle Fälle empfehlenswert, sich auf dem Standard-Software-Markt zu orientieren, ob sich dann allerdings ein geeignetes Paket findet, können nur sorgfältige Untersuchungen zeigen. Welcher der beiden. Wege der bessere ist - Eigenentwicklung oder Kauf mit entsprechender Anpassung - kann nur im Einzelfall beantwortet werden.