Anpassungsfähigkeit muß schon im Entwurf berücksichtigt werden, denn:

Reine Installationszahlen machen noch keinen Standard

05.02.1988

Streubreite und Treffsicherheit - für moderne Standardsoftware sollte das kein Widerspruch sein. Allerdings erfordert es Modularisierung und "Abstraktion" bereits beim Software-Entwurf. Alberto del Fabro* beschreibt die Bedingungen, die ein Paket erfüllen muß, um den Namen "Standard" zu verdienen.

Jeder Anwender liebäugelt zunächst mit einer auf ihn zugeschnittenen Individuallösung. Software-Angebote "von der Stange" werden stets mit diesem "Maßanzug" verglichen. Der Grund hierfür liegt darin, daß die diversen Organisationsformen meist nur schwer unter einen Hut zu bringen sind; und oftmals gibt es zwingende Gründe, das "eigene Süppchen" zu kochen.

Trotzdem sind die Vorteile einer "Fertigsoftware" bestechend: Unter anderem sprechen die schnelle Verfügbarkeit, die niedrigen Kosten sowie der Erfahrungsaustausch mit anderen Anwendern dafür. Allerdings ist eine Branchenlösung nicht schon allein deshalb eine Standardsoftware, weil sie mehrfach eingesetzt wird; vielmehr muß sie alle gleichartigen Anforderungen der Zielgruppe abdecken, ohne sofort große Anpassungen zu erzwingen.

Daß Standardsoftware eine gewisse Streubreite aufweisen muß, ist wirtschaftlich begründbar: Eine große Zielgruppe begünstigt die Multiplikation und verbilligt das Produkt letztlich für den User. Andererseits leidet die Treffsicherheit, wenn nicht durch geeignete Mechanismen eine exakte Problemlösung herausgefiltert werden kann.

Unverzichtbare Eigenschaften moderner Standardsoftware sind daher die drei folgenden: ein modularer Aufbau der Gesamtlösung (außerhalb eines "harten Kerns" können beliebige Komponenten abgekoppelt werden, ohne die Funktionalität der verbleibenden Bereiche zu beeinträchtigen), die parametergesteuerte Definition unterschiedlicher Programmausprägungen sowie die Anpassungsfähigkeit der anwenderabhängigen Datenelemente in Länge und Aufbau. Ein geschickter Software-Entwurf berücksichtigt dabei, daß der Entwickler diese Merkmale ohne erheblichen Laufzeit- und Platzbedarf implementieren soll.

Leider gibt es noch immer - oder verstärkt - Pakete, die auf andere Weise entstanden sind: Zunächst wird für einen speziellen Kunden eine individuelle Lösung gestrickt. Dabei werden kaum allgemein verwertbare Bestandteile eingewirkt, denn zum einen fehlt unter dem üblichen Projektdruck die Zeit dazu, und zum anderen zahlt der Kunde ja schließlich nur für seine eigenen Anforderungen. Ist die Anwendung fertiggestellt, wird sie dem nächsten Interessenten in einer gut aufgemachten Broschüre als "Standard" angeboten. Der Anwender erkennt den Flop erst dann, wenn er für banale Anpassungen tief in die Tasche greifen muß.

Konnte der Entwickler diesen Vorgang mehrfach wiederholen, so bekommt die Software die Attribute "praxiserprobt" und "ausgereift"; denn unbestreitbar ist eine große Menge Erfahrung in das Produkt eingeflossen. Doch der Ballast aus Vorgänger-Projekten wird nicht entfernt, sondern als Variante, Modul oder Sonderfunktion angepriesen.

Es wäre allerdings weltfremd, zu unterstellen, daß komplexe Standardsysteme auf der grünen Wiese entstehen könnten, - ohne konkreten Bezug zu einem Anwenderprojekt. Erstens stößt der Entwickler heute schnell an die Grenze der Finanzierbarkeit: Er braucht also eine oder mehrere Optionen auf sein Produkt. Ein Auftrag im voraus schafft also erst das Budget für die Realisierung. Zweitens muß bereits in der Entwurfsphase problemspezifisches Know-how mit einfließen, am besten aus bereits durchgeführten Projekten. Nur aus dem Überblick über die Thematik erkennt der Analytiker homogene oder individuelle Anforderungen des Marktsegments.

Für die Bekleidungsfertigung beispielsweise ist dreierlei charakteristisch: der Saison-Bezug (zwei Kollektionen im Jahr bedeuten, zweimal pro Jahr die gesamte Produktpalette umzustellen), die Produktvarianten (Schnitte, Dessins, Qualitäten, Farben und Größen in einstufigen Stücklisten), außerdem die speziellen Arbeitsgänge (Schneiden, Nähen und Legen sowie eventuell Bleichen, Färben und Bedrucken). Diese Merkmale sind typisch für die Masse der Betriebe. Sie gehören in den "harten Kern" einer Standardsoftware; und sie müssen effizient gelöst sein.

Je nach Betriebsausrichtung kommen Varianten hinzu: Diese Spielarten betreffen zum einen die Materialdisposition; sie ist entweder rein auftragsbezogen (im stark modischen Betrieb) oder lagerorientiert (bei eigener Rohstofferzeugung). Zum anderen kann die Fertigung selber variieren (Eigenfertigung, Lohnarbeit, Lohnveredelung oder Auslandsfertigung), aber auch der Faktor "Losgrößen" (Einzelfertigung, Kleinserie oder Großserie).

Außerdem gibt es noch Unterschiede bei den Vertriebswegen und beim Kundenkreis sowie bei der Frage, ob es sich um Einzelhandelsgeschäfte, Einkaufsverbände (Sammelfakturierung) beziehungsweise Katalogversandhäuser mit oder ohne eigenes Vertreternetz (Provisionsabrechnung) handelt.

Daraus resultieren, bei gleichem Endprodukt, stark differierende betriebliche Abläufe; und dieser Tatsache muß eine Standardsoftware Rechnung tragen. Nur durch modularen Aufbau der Gesamtlösung und durch Parametrisierung von Funktionen bietet der Entwickler dem Abnehmer hier eine akzeptable Alternative zur Individuallösung. Der Einsatz einer solchen Standardsoftware schafft dem User neuen Spielraum, den er für die Optimierung seiner betrieblichen Organisation nutzen kann - oder für individuelle Teillösungen, auf die er partout nicht verzichten will.

* Alberto del Fabro ist als selbständiger Unternehmensberater in Saarbrücken tätig.