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.

03.01.1986 - 

Hersteller betrachten Standardsoftware nicht länger als "Stiefkind":

SSW dient als Hebel für den Kundeneinstieg

BERLIN (mer) - Aufgeschreckt durch stagnierende Absatzzahlen und den Preisverfall ihrer Maschinen, investieren viele Hersteller zunehmend in den Bereich der Software. Insbesondere Standardpakete gelten dabei als wirksame "Hebel" für den Verkauf weiterer Produkte.

Diente das Softwaregeschäft den Herstellern noch vor wenigen Jahren als reines "Zubrot", sehen sie in ihrem bislang vernachlässigten "Stiefkind" mittlerweile eine sprudelnde Ertragsquelle. Wettbewerbsvorteile sind allerdings auch hier nur durch qualitativ hervorstechende Lösungen zu erzielen. Dies wurde aus den einzelnen Referaten deutlich, die sich auf dem Software-Kongreß "Compas 85" in Berlin mit dem Thema "Standard-Software aus der Sicht der Hersteller" beschäftigten.

Unterschiedliche Lösungen für das gleiche Problem

Offensichtlich prägt die Größenklasse der vermarkteten Hardware auch die Angebotspalette an Standardprogrammen. Nach Ansicht von Albert Schaller, Leiter der Abteilung Anwendungssoftware-Planung bei der Siemens AG, München, wird dies im wesentlichen durch die DV-technischen Voraussetzungen und Gegebenheiten beim Anwender selbst bestimmt und erfordert deshalb unterschiedliche Lösungen für das gleiche Problem.

Benutzer von General-Purpose-Computern beschäftigen meist eigene Datenverarbeitungs- und Organisationsabteilungen, die sich mit der im Unternehmen eingesetzten Software und deren Anpassung an die individuellen Bedürfnisse befassen. Dagegen seien bei Usern von Small-Business-Systemen im Durchschnitt nur ein bis fünf Mitarbeiter für diesen Bereich eingesetzt. Bei PC-Anwendern fehle der DV-Hintergrund oft völlig.

Nach den Ausführungen des Siemens-Referenten ist denn auch der Anteil an eigenentwickelten Programme bei Großanwendern besonders hoch. Die dort verwendete Standard-Software wird normalerweise mittels individueller Änderungen und Ergänzungen dem Unternehmen angepaßt. Dagegen nimmt nach seinen Erfahrungen die Verwendung von standardisierten Lösungen ohne solche Änderungen zu, je kleiner der Betrieb und/oder die eingesetzten Rechner sind, Schaller: "Hier ist man eher bereit, kleinere Änderungen der Organisation in Kauf zu nehmen, sofern das Standardpaket den betrieblichen Anforderungen im allgemeinen entspricht. "

Für Hersteller und Systemhäuser wird das unterschiedliche Benutzerverhalten zum Gradmesser bei der Standardisierung ihrer Produkte: Je nach Anwendungsfall muß entschieden werden, welches Entwicklungsvorgehen sinnvoll erscheint. Die Art des Vorgehens hängt wiederum von der erreichbaren Einsatzzahl des Programms ab. Für einen einzelnen oder sehr wenige Einsätze kann nach Meinung des Referenten nur eine individuelle Lösung in Frage kommen.

Ein sequentieller Ansatz bietet sich an, wenn insbesondere die Parameter der späteren Standardlösung vor Entwicklungsbeginn nur unvollständig festgelegt werden können. Der simultane Ansatz schließlich lohnt nur bei großen Stückzahlen und ist außerdem lediglich für Lösungen denkbar, die weitgehend vor Entwicklungsbeginn in ihrem Funktionsumfang definierbar sind.

Dagegen sei, so Schaller in seinem Vortrag, das häufige Vorgehen kleiner, meist regional tätiger Softwarehäuser für die "Hardware-Größen" der Branche der falsche Weg. SW-Entwickler für PC und kleine Mehrplatzsysteme konzipierten nämlich ihre Pakete meist zunächst als Projektlösung für einen Anwendungsfall. Später würden daraus Branchenpakete - etwa durch Hinzufügen einiger funktionaler Erweiterungen.

In diesem Werdegang der Produkte sieht Schaller durchaus Vorteile für den Anwender: Die Programme seien praxisnah entstanden, sie enthalten Funktionen, die tatsächlich gebraucht würden und die Entwickler seien für den raschen Einbau von Anpassungen verfügbar.

Standard-Software darf nicht beim Kunden reifen

Allerdings verbindet der Referent damit auch etliche Nachteile: Die Produkte seien nicht von vornherein auf größere Einsatzzahlen und die daraus resultierenden Änderungen und Erweiterungen ausgerichtet. Zudem habe die Wartung der Programme ihre Grenzen. Schaller: "Das Beispiel zeigt deutlich, daß ein solches Vorgehen für Hardware-Hersteller ungeeignet ist."

Auch Hasso Plattner, Geschäftsführer der SAP GmbH, Walldorf, kritisierte in seinem Vortrag die weitverbreitete Methode, Standardpakete beim Kunden "reifen" zu lassen. Ziel eines Herstellers müsse es sein, die Anwendungsfunktionen so auszubauen, daß alle denkbaren Anforderungen abgedeckt würden. Der Qualitätsanspruch an Benutzerfunktionen sei heute derart hoch, daß - so Plattner wörtlich - "eine Umprogrammierung oder Erweiterung bestehender Standardpakete beim Kunden eine gefährliche Sache ist."

Deshalb müsse der Programmaufbau bei Standardsoftware für eine permanente Weiterentwicklung konzipiert sein. Denn selbst in klassischen Anwendungsgebieten, wie etwa der Finanzbuchhaltung, gebe es keinen endgültigen Stand der Systeme. Sobald eine qualitative Neuerung Einzug in die Arbeit der Fachabteilung halte, ändere diese auch ihre Verhaltensweise, was seinerseits wieder neue Anforderungen an das Anwendungssystem zur Folge habe.

Klassische Design-Techniken versagen den Dienst

Dies führt nach Ansicht des SAP-Managers zu einer extremen Modularisierung der Programme sowie ZU aufwendigen Steuerungs- und Verwaltungsmechanismen. Die übliche Beziehung "Transaktion - Programm" könne nicht aufrechterhalten werden. Vielmehr definiere sich das Programm in Abhängigkeit der Dateninhalte dynamisch bei der Ausführung selbst. Zum Beispiel müsse die Dokumentation teilweise Bestandteil des Runtime-Systems sein und datenabhängig erstellt werden können. Plattner: "Hier versagen klassische Design- und Dokumentationstechniken ihren Dienst."

Weitere Probleme sieht der SAP-Geschäftsführer bei den Datenbanken. Zwar spielt die Unterstützung, die ein DBMS bei der Entwicklung von Standardsoftware bieten kann, nicht die Rolle wie in der Individualprogrammierung; Kopfzerbrechen jedoch bereitet den Herstellern nach Worten Plattners die Wahl zwischen Datenbankunabhängigkeit und der Entscheidung für eine bestimmte Datenbank. Denn wesentliche Teile eines DB-Systems wie Datenkatalog, View-Verwaltung, feldweise Verarbeitung oder Verdichtungstechniken seien auch Bestandteil eines Anwendungssystems. Wolle der Hersteller mehrere Datenbanken unterstützen, müßten diese Funktionen redundant unterhalten und über Datentransferschnittstellen mit den entsprechenden Komponenten im jeweiligen DBMS verbunden werden. Plattner: "Die Entwicklung der Datenbanksysteme ist heute noch so unbestimmt, daß eine eindeutige Entscheidung für ein spezielles DB-System und damit die ausschließliche Verwendung seiner Funktionen eine gefährlichere Entscheidung darstellt als die Wahl eines bestimmten Betriebssystems und damit der dazugehörigen Hardware."