Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.10.1996 - 

Standardsoftware/Standardsoftware ist nicht in Walldorf erfunden worden

Welche Fehler zu fatalen Kaufentscheidungen führen

Ende der 60er und Anfang der 70er Jahre startete die damalige Bundesregierung ein Förderungsprogramm für die Entwicklung kommerzieller Standardprogramme. Erreichen wollte sie damit dreierlei: Die junge deutsche Software-Industrie sollte gestützt, die mehrfache, volkswirtschaftlich nicht zu vertretende Entwicklung gleicher Software vermieden werden, und die Anwender im mittelständischen Bereich sollten ohne die Beschäftigung teurer DV-Spezialisten mit der Standardsoftware Know-how einkaufen können. Dieses sollte sowohl die organisatorische als auch die DV- technische Seite umfassen.

Erfüllt wurden diese Hoffnungen in den folgenden Jahren durch die Anbieter mittlerer Datentechnik (MDT) und der Small-Business- Computer. Beispiele dafür sind die Produkte "Comet" von Nixdorf und "Karat" von Kienzle. Derartige Programme deckten nicht nur die sogenannten Kernanwendungen Fibu sowie Lohn- und Gehaltsabrechnung ab. Differenzierte Branchenlösungen fanden sich bald auch für spezielle Anforderungen der Anwender aus verschiedenen Wirtschaftszweigen.

Die damalige Standardsoftware brachte den Benutzern einige wichtige Vorteile: Die Preise waren bei der Vielzahl der Installationen gering. Der Anwender brauchte keine eigene Software-Abteilung. Bis auf wenige Ausnahmen benötigten sie auch keine Berater.

Die Einführung der Software war innerhalb weniger Wochen abgeschlossen. Anpassungen der Programme an spezielle Anforderungen waren eher selten erforderlich.

Letzteres hatte seine Ursache darin, daß der Anwender eher bereit war, seine Organisation an die Software anzupassen, als teure Änderungen an den Programmen vornehmen zu lassen.

Die Marketing-Strategie der Anbieter im MDT-Bereich war darauf gerichtet, nur gleichartige Software-Installationen bei den Kunden zu haben. Sie waren nicht daran interessiert, den Anwendern durch Programmänderungen entgegenzukommen. Sie befürchteten nicht zu Unrecht, daß die Wartung vieler Spezialprodukte nicht mehr mit einem angemessenen Aufwand durchzuführen wäre. Dieses Geschäft überließen sie Softwarepartnern.

Was den Markt der kommerziellen Standardsoftware betrifft, so scheinen die Erfahrungen der MDT-Hersteller heute nicht mehr zu zählen. Wer die SAP-Welt betrachtet, findet genau das Gegenteil des damaligen MDT-Markts.

Die Preise liegen mindestens um eine Zehnerpotenz höher. Die Systeme beschäftigen Legionen von Programmierern. Die müssen sogar noch eine eigene, von SAP kreierte Programmiersprache beherrschen. Software-Anpassungen sind die Regel dabei ist die Unterstützung durch hochbezahlte Berater erforderlich. Die Einführung der Standardsoftware nimmt enorm viel Zeit in Anspruch. Der ursprünglich geplante Aufwand für die Anpassung wird häufig überschritten.

Stellt sich die Frage, warum die Programme der 70er und 80er Jahre für den Anwender einfacher zu handhaben waren als die der 90er Jahre. Schließlich haben sich die betriebswirtschaftlichen Aufgaben und Inhalte im Verlauf der Jahre nicht wesentlich verändert.

Uniforme Software ist nicht mehr gefragt

Sicherlich bietet das DV-technische Umfeld heute andere Möglichkeiten der Gestaltung der Arbeitsabläufe. Die Erfahrung und die Routine der Software-Entwickler müßten aber in demselben Maße zugenommen haben, so daß hinsichtlich des Aufwands keine derart große Diskrepanz bestehen dürfte.

Vielleicht liegt aber der Unterschied der Produkte nicht allein in deren Inhalt und Komplexität, sondern in dem anders gestalteten Markt.

Das Marketing von Nixdorf, Kienzle etc. mußte darauf ausgerichtet sein, dem Anwender die Angst zu nehmen, daß die Nutzung der Standardsoftware eine eigene aufwendige DV-Abteilung verlangt. Produkt und Vertrieb waren darauf ausgerichtet, dem Kunden zu zeigen, daß die Software die wichtigsten Funktionen beim Anwender abdeckt.

Die Zielgruppe, die SAP bedient, verlangt eine andere, entgegengesetzte Marketing-Strategie. Das Unternehmen muß darauf achten, daß sich die DV-Abteilungen des potentiellen Käufers nicht gegen die Nutzung von Standardsoftware aussprechen. SAP darf nicht als "Jobkiller" auftreten.

R/3 ernährt das DV-Fußvolk

Und das geht einfach: SAP macht sich den Trend der Unternehmen zunutze, sich ein unverkennbares individuelles Bild zu geben, das sie von der Konkurrenz abhebt. Also muß die Möglichkeit einer individuellen Anpassung der Standardsoftware herausgestellt werden.

Die Folge ist, daß die Software an die ausgefallensten Wünsche des Anwenders angepaßt wird damit ernährt sie ihre programmierenden Pfleger. So entstand die logisch unverständliche Situation, daß für die Einführung einer Standardsoftware, die eigentlich die Kosten reduzieren soll, die teuersten Berater der DV-Branche gebraucht werden. Die Standardsoftware ersetzt nicht - wie ursprünglich geplant - fehlendes Know-how, sondern verlangt neues, spezielles und bisher nicht erforderliches.

Die Ursachen dieser Entwicklung liegen in der Situation auf seiten der Anwender. Beim Einkauf eines Standardprogrammes wiederholen sich die gleichen Fehler, die zu Zeiten der Individualprogrammierung gang und gäbe waren. Die Projekte laufen an, ohne daß die angestrebten Ergebnisse vollständig definiert wären. Viele Käufer ordern Standardsoftware, ohne tatsächlich genau zu wissen, welche Funktionalität sie abdecken soll.

Der Kunde kann nun hoffen, daß der Software-Anbieter genau die Funktionalität liefert, die er benötigt. Oder er muß sich ein Anforderungsprofil erarbeiten, mit dessen Hilfe er das oder die Angebote vergleicht.

Die Schwierigkeiten bei der Einführung einer Standardsoftware haben ihre Ursache häufig darin, daß der Anwender erst nach dem Kauf eine Diskrepanz zwischen der benötigten und der gelieferten Funktionalität bemerkt. Manche Funktionalitäten erweisen sich als unnötig, während andere wünschenswert wären.

Doch die Anbieter liefern nur selten eine vergleichbare Beschreibung des Funktionsumfanges ihrer Produkte, die zumindest eine mengenmäßige Bewertung der Funktionalität erkennen ließen. Die Folge ist, daß sich das tatsächliche Produktprofil erst bei der Installation der Software zeigt.

Ein weiterer Irrtum, dem viele Anwender bei der Auswahl von Standardsoftware unterliegen, besteht darin, daß sie die Größe der Standardsoftware mit der Mächtigkeit an Funktionalitäten gleichsetzen. Dabei fallen sich aufdrängende Fragen nach dem Bedarf an zusätzlichen Hardwareressourcen und Personal erstaunlicherweise unter den Tisch.

Beim Einsatz von Standardsoftware sollte auch die Frage geklärt sein, inwieweit das Produktprofil das Anforderungsprofil deckt. Der Vergleich von Anwender- und Produktprofil gibt Hinweise zur Beurteilung der Wirtschaftlichkeit des Produkts oder einer Funktionalität.

Um vergleichen zu können, ist eine Metrik für die Softwarebewertung vonnöten. Hier bietet sich die Function Point Analysis an. Die Maßeinheit Function Point mißt die Funktionalität, die eine Software bietet (siehe Kasten).

Wenn die Frage nach den Kosten kommt, wird allzu schnell nur der Lizenzpreis für das Programm genannt. Die laufenden Kosten einer eigenen Software-Abteilung und der eventuell benötigten Berater werden oft nicht angemessen beurteilt. Würden ferner die Kosten für die Lizenz auf die nutzbare Funktionalität bezogen, ergäbe sich häufig ein ganz anderes Preis-Leistungs-Verhältnis.

Eine weitere Frage, die immer häufiger gestellt wird, ist die nach dem Aufwand für die Programmerweiterungen. Hier haben die Projektleiter einen schwierigen Stand. Diese Kosten lassen sich nur auf Basis von Erfahrungswerten schätzen. Da ein Unternehmen komplexe Standardsoftware allenfalls einmal in einem Jahrzehnt einführt, sind Erfahrungswerte kaum vorhanden.

Kurz- und mittelfristig sind solche Auskünfte höchstens bei anderen Anwendern zu erhalten. Der Koordinator für eine derartige Datenbank wäre im Idealfall der Softwarelieferant selbst. Er wird sich im Zweifelsfall jedoch kaum die Blöße geben und sich durch unschöne Zahlen ein Geschäft verderben wollen. Eine Kooperation der Anwender untereinander wäre also absolut wünschenswert.

Angeklickt

Standardsoftware sieht heute ganz anders aus als in den besten Zeiten von "Comet" und "Karat". Einige ihrer einstigen Vorteile haben sich sogar ins Gegenteil verkehrt. Viele Faktoren, die normalerweise bei einer größeren Kaufentscheidung von Gewicht sind, bleiben unberücksichtigt. Vor allen Dingen lassen sich die Funktionalität und ihre Preiswürdigkeit nicht mehr so einfach ermitteln. Doch gibt es eine Methode, zu recht verläßlichen Anhaltspunkten zu kommen.

*Robert Hürten ist Geschäftsführer der Hürten und Partner Unternehmensberatung in Riedstadt-Leeheim.