Ein heißes Eisen ist der Einsatz von "Standardsoftware" vor allem für Klein- und Mittelbetriebe. Denn wo nicht genügend eigene Entwicklungskapazität zur Verfügung steht, muß der User notgedrungen auf "Fertigprodukte" zurückgreifen, meint Hubert H. Cujai, Leiter Org /DV bei der Buckbee Mears Europe GmbH. Daraus resultiere jedoch - vor allem wenn auch die notwendigen Modifikationen außer Haus vorgenommen werden - ein starkes Abhängigkeitsverhältnis zum Lieferanten. Vor einer anderen Gefahr, dem übertriebenen Perfektionismus, warnt Gerhard Reißfelder, Leiter Org/DV bei der Matth. Hohner AG. Seien die Anwender vor der Beschaffung ihrer Standardpakete oft mit "steinzeitlichen Zuständen" zufrieden gewesen, solle plötzlich mit Hilfe moderner Software der Sprung ins 20. Jahrhundert vollzogen werden. Am Schluß komme dann immer wieder das leidige Thema auf: "Wer paßt sich wem an? " kul
Gerhard Reißfelder,
Leiter Org./DV, Matth. Hohner AG, Trossingen
Der Einsatz von Standardsoftware bringt vor allem dann positive Aspekte mit sich, wenn der ganze betriebliche Umfang von einem Hersteller abgedeckt werden kann. Die Basis ist eine einheitliche Datenbank, keine redundante Speicherung von Daten. Deshalb gibt es auch wenig Verwaltungsaufwand. Was besonders wichtig ist: der Wegfall vieler kleiner Insellösungen. Hier bietet sich die Chance für jedes Industrieunternehmen, die gesamte Organisation neu zu überdenken. Es bringt aber auch Gefahren mit sich.
Viele Abteilungen zeichnen sich dadurch aus, daß sie mit Beharrlichkeit versuchen, immer wieder die bestehende Organisation in das Softwarepaket zu integrieren, verbunden mit dem überzogenen Streben nach einer 100-prozentigen Lösung. Vollkommen außer acht-gelassen wird, von welchem Zustand man ausgegangen ist. Während man vorher mit "steinzeitartigen Zuständen" zufrieden war, soll jetzt durch den Einsatz moderner Software mit einem Schlag der Sprung ins 20. Jahrhundert vollzogen werden. Am Schluß kommt immer wieder das leidige Thema auf: "Wer paßt sich wem an?" Dabei wird vergessen, daß Perfektionismus nur mit einem unvertretbaren hohen Aufwand realisierbar ist. Hier bewegt man sich in einem Teufelskreis.
Ein entscheidender Punkt ist auch, daß die Ist-Analyse nicht immer gründlich genug gemacht werden kann. Erschwerend kommt hierbei hinzu, daß die kompetent: en Leute aus der Fachabteilung meist mit der täglichen Arbeit so überlastet sind, daß sie kaum für eine gründliche und genaue Ausarbeitung Zeit haben. Folglich wird das Pflichtenheft zu groß unübersichtlich und ungenau.
Dies birgt wiederum die Gefahr in sich, daß Anwender und Anbieter bei der Systemauswahl aneinander vorbeireden. Schwachpunkte sind nachträgliche Forderungen, die auftauchen weil man sie vergaß, oder weil sich über die Projektlaufzeit hinweg die Umwelt verändert.
In der Akquisitionsphase werden manchmal bereits erkennbare Diskrepanzen zwischen den Bedürfnissen des Anwenders und den Fähigkeiten des Softwaresystems bagatellisiert oder unter den Teppich gekehrt. Ein solch ignoriertes Problem kommt spätestens in der Einführungsphase auf das Projekt zu. Außerdem wird in den meisten Fällen in zu kurzen Einführungszeiträumen gedacht.
Viele Anbieter vermeiden es, den Kunden von unrealistischen Erwartungshaltungen abzubringen. Ebenfalls unterlassen sie es häufig, auf die Komplexität eines solchen Systems hinzuweisen, denn Komplexität wirkt bekanntlich eher abschreckend. Es wird versucht dem Kunden die Verantwortung zuzuschieben, mit dem Hinweis, man brauche nur die Installationsbroschüre genau zu studieren und die Parameter zur Errechnung genau auszufüllen. Dies hat zur Folge, daß vor allem DV-Abteilungen, die keine Erfahrung in Großprojekten haben, Gefahr laufen, durch Fehleinschätzung, Speicherkapazität, Antwortzeit und in der Bereitstellung von Man-Power, das Projekt zu gefährden.
Die Organisationsberatung seitens des Herstellers erfordert eine große Kapazität hochqualifizierter Mitarbeiter. Dies ist jedoch Mangelware bei vielen Anbietern. Hier wird die Hektik, gegenseitige Beschuldigung, sogar das Scheitern in vielen Fällen schon vorprogrammiert. Ebenfalls sollte ja muß, das partnerschaftliche Denken sowohl beim Anbieten und Anwenden noch weiter vertieft werden. Nur dann ist für beide Seiten eine zufriedene und fruchtbare Zusammenarbeit während und nach dem Projekt gewährleistet.
Hubert H. Cujai,
Leiter Org./DV Buckbee Mears Europe GmbH, Müllheim
Als mittleres Unternehmen ohne genügend eigene Softwareentwicklungskapazität waren wir schon immer gezwungen, unser Hauptaugenmerk dem Standardsoftwaremarkt zu widmen. Bekanntlich hat sich das Verhältnis Hardware- zu Softwarekosten innerhalb des Datenverarbeitungsbudgets von 80 zu 20 im Jahre 1955 auf etwa 30 zu 70 in 1984 verändert. Auch eine Verbesserung der Softwareentwicklungsmethoden wird dieses Verhältnis in naher Zukunft nicht groß verändern. Wenn man jetzt noch berücksichtigt, daß die Leistungsfähigkeit der Hardware zum größten Teil von der Qualität der Software bestimmt wird, so gewinnt das Problem der richtigen Auswahl von Standardsoftwarepaketen immer mehr an Bedeutung.
Dies bedingt zwangsläufig daß die professionellen Softwarehäuser mit einem ansteigenden Qualitätsbewußtsein der Anwender zu rechnen haben. Kürzlich hat eine Umfrage in den USA bestätigt, daß die Anwender mit der Qualität von Standardsoftware unzufrieden sind. In den letzten Jahren ist eine Vielzahl von Softwarehäusern (manchmal auch sogenannte) geradezu aus dem Boden geschossen. Dadurch wurde der Softwaremarkt sehr unübersichtlich. Zum anderen ist es durch zum Teil exotisches Fachvokabular kaum möglich, eine frühe Grobauswahl zu treffen.
In der Vergangenheit wurden Installationsentscheidungen oft durch grobe Vergleiche der diversen Angebote getroffen. Die Initiative lag dann meist beim Anbieter; denn die Darstellung der einzelnen Funktionen erfolgte je nach Schwerpunkt des jeweiligen Produktes. Der Anwender wurde mit Listbildern, verbalen Beschreibungen und Ablaufdiagrammen bombardiert. Es gab eine Demonstration bei einem Referenzkunden des Softwarehauses, wobei aber oft die Problematik des neuen Kunden zu kurz kam, denn die Menge der Eindrücke konnte nicht rechtzeitig verarbeitet werden. Nach durchgeführter Installation wurde dann fleißig angepaßt, so daß mit der Zeit das herauskam, was man eigentlich von Anfang an wollte.
Die Vorgehensweise bei der Auswahl und Installation von Standardsoftwarepaketen sollte aus den genannten Gründen nicht wesentlich von der Eigenentwicklung abweichen. Bei größeren Anwendungen ist es immer sinnvoll, ein Projektteam zu etablieren. Dieses Team hat die Aufgabenstellung klar zu definieren und ein detailliertes Pflichtenheft zu erstellen. Dadurch wird der Aufwand im Vorfeld wohl relativ hoch, aber beide Parteien profitieren davon. Der Softwareanbieter ist in der Lange, exakt zu sagen welche Positionen durch sein Standardpaket abgedeckt sind und wo eventuell angepaßt werden muß. Der Kunde kann das Für und Wider eventueller Anpassungen schon in einem sehr frühen Stadium diskutieren und Entscheidungen treffen. Hier ist zu berücksichtigen, daß aus Kostengründen meistens eine 100 prozentige Übereinstimmung nicht erzielbar ist.
Der DV/Organisationsmanager hat in diesem Team darauf zu achten, daß das Gesamtsystem, das heißt Schnittstellen zu anderen Anwendungsgebieten, Datenbeständen und Informationsströmen nicht gefährdet wird. Durch die Entscheidung, ein Standardsoftwareprodukt einzusetzen, begibt sich der Anwender immer in ein gewisses Abhängigkeitsverhältnis zum Lieferanten. Da dieser sein Produkt genau kennt, ist es auch zumeist sinnvoller, daß Modifikationen von ihm vorgenommen werden. Damit die Kosten in einem überschaubaren Rahmen bleiben, sollte vom Lieferanten unter Zugrundelegung des Pflichtenheftes ein Festpreisangebot verlangt werden.
Bei der Grobauswahl kann ein Softwarekatalog eine große Hilfe sein. Mit diesem ist es möglich, sich einen Überblick über das Standardsoftwareangebot für das jeweilige Anwendungsgebiet zu verschaffen. Außerdem erhält man Informationen über die verwendete Programmiersprache, für welche Anlage das Produkt geschrieben wurde, wie oft es installiert ist und ob auch der Quellencode ausgeliefert wird. Die Nichtauslieferung des Quellencodes macht besonders vom Lieferanten der Standardsoftware abhängig. Eine Falschauswahl kann hier eine Folgekostenlawine auslösen und somit zu einer Lebensversicherung des Softwareherstellers führen. Die Mindestabsicherung bei Nichtauslieferung des Quellencodes sind: Hinterlegung der jeweils gültigen Version bei einem Notar und eine Garantiezeit von mindestens einem Jahr, in dem alle Fehler kostenlos zu beseitigen sind.
Ein weiterer wichtiger Gesichtspunkt sind Kapazitätsbetrachtungen in bezug auf Dateien und Programme. Ist es möglich, Dateien den Gegebenheiten anzupassen oder müssen Datenredundanzen hingenommen werden? Sind die Programme modular aufgebaut, so ist es möglich nur die benötigten Funktionen und Programme zu erwerben und somit unnötige Programmlaufzeiten zu vermeiden.
Daß eine ausführliche Dokumentation und ein Bedienerhandbuch zu jedem Standardsoftwarepaket gehören, sollte hier eigentlich gar nicht mehr erwähnt werden müssen. Aber es kommt immer wieder vor, daß beispielsweise ein Bedienerhandbuch aus einigen Hardcopies von Bildschirmmasken und diversen Listbildern besteht. Bei dialogorientierter Software sollte es beim Stand der heutigen Technik selbstverständlich sein, daß das Bedienerhandbuch jedem Benutzer per Tastendruck als Hintergrundinformation zur jeweiligen Bildschirmmaske zur Verfügung steht.
Rolf-Udo Reinholdt,
Leiter Organisationsstelle Maschinenfabrik Goebel GmbH, Darmstadt
Es gibt verschiedene Arten von Standardsoftware. In einer groben Betrachtung läßt sie sich gliedern in Systemsoftware, Programmentwicklungswerkzeuge und Anwendungssoftware. Auf seiten der Betriebssystemsoftware in engerem Sinn hat der Anwender kaum eine andere Wahl, als die angebotenen Komponenten des Herstellers in der jeweils gültigen Fassung einzusetzen. Im Zusammenhang mit Programmentwicklungwerkzeugen geht es darum, Durchgängigkeit vom Entwurf bis zur Realisierung gewährleistet.
Nach meiner Auffassung, liegt die gesamte Problematik in erster Linie im Bereich der Standard- Anwendungssoftware.
Um es vorweg zu sagen, besteht für ein Unternehmen unserer Größenordnung mit einer sehr begrenzten Kapazität in der Programmentwicklung die zwingende Notwendigkeit, wo immer möglich, den Einsatz; von Standardsoftware ins Auge zu fassen. Die Situation mag bei Großunternehmen oder Konzernen anders sein, da sich hier eine maßgeschneiderte firmenindividuelle Entwicklung auch unter den Wirtschaftlichkeitsgesichtspunkten eher lohnt.
Die Beschaffung fertiger Programmprodukte kann zu teuer sein, wenn eine begrenzte Anzahl von Benutzern unterstützt wird. Von dieser Seite scheinen Staffelpreise in Abhängigkeit von der Systemgröße , oder der abzurechnenden Mitarbeiterzahl.
Fachbezogen vom Anforderungsgesichtpunkt betrachtet, laßt sich immer wieder feststellen, daß die wesentlichen Grundfunktionen in den Standardpaketen abgedeckt sind. Selten findet man jedoch branchenspezifische Lösungsansätze, welche die Besonderheiten bestimmter Unternehmensgruppen abdecken. Softwareanbieter wären gut beraten, diesbezüglich spezielle Zusatzkomponenten anzubieten, um somit die Einsatzmöglichkeiten ihrer Produkte erweitern. In unserem Falle geht es um die Abdeckung der Belange des reinen Einzelfertigers im Maschinenbau mit kundenorientierter Konstruktion. Die Besonderheiten berühren sowohl den kommerziellen Bereich, Spielwiese Debitorenbuchhaltung, wie auch den betrieblichen Bereich, beispielsweise Materialwirtschaft und Fertigungssteuerung.
Wenn man die Frage des Preises und die fachliche Seite im Zusammenhang sieht, schließt sich der Kreis gewissermaßen. Zusatzcomponenten im branchenspezifischen Sinn erhöhen die Einsatzmöglichkeiten der Produkte und damit die Anzahl zu erwartender Installationen. Entsprechend kalkulierte niedrigere Gebühren machen den Einsatz von Standardsoftware auch dort attraktiv, wo dies heute aus Kostengesichtspunkten nicht möglich ist.