Die Diskussion über das Thema "Wie universell ist Standardsoftware?" wird mit ähnlicher Vehemenz wie die Diskussion über zentrale oder dezentrale Datenverarbeitung geführt. Dennoch ist eine detaillierte Aufzählung der vorhandenen oder nicht vorhandenen Unterschiede hier müßig; in Wahrheit sind nur einige wenige Punkte angesprochen.

Die Vorteile der Eigenentwicklung, sei sie nun selbst durchgeführt oder bei einem Softwarehersteller in Auftrag gegeben, liegen deutlich auf der Hand: Die maßgeschneiderte Software geht auf die speziellen Probleme des einzelnen Anwenders ein und kann besonders an die beim Anwender vorhandene Hardware angepaßt werden, was zu einer Erhöhung der Effizienz führt. Auf der anderen Seite bietet die Standardsoftware auf der Kostenseite besondere Vorteile: Wenn keine allzugroßen Änderungen vorgenommen werden müssen, ist sowohl die Erstellung (oder der Kaufpreis) und die Wartung wesentlich kostengünstiger als eine Eigenentwicklung.

Aus Softwareherstellersicht bieten sich zwei Möglichkeiten der Softwareherstellung; einmal die Auftragsfertigung, wo nach Anwenderwünschen und vorhandener Hardware spezielle Kundenlösungen erstellt werden, oder die "Massenproduktion", wobei durch Mehrfachverkauf derselben Basissoftware die höheren Entwicklungskosten zurückerlangt werden und der Verkaufspreis konkurrenzfähig bleibt.

Hilfsmittel Checkliste

Die heute noch vielfach angebotenen Standardpakete berücksichtigen zu wenig die speziellen Kundenprobleme und müssen entweder vom Anwender, vom Anbieter oder einem eingeschalteten Softwarehaus modifiziert werden. Da es sich meist um historisch gewachsene, einstmals für einen Kunden erstellte und später modifizierte Pakete handelt, ist dies aufwendig und in manchen Fällen sogar teurer als eine Neuproduktion. Der Versuch, eine Lösung für dieses Problem zu finden, zeigt sich in den vereinzelt angebotenen Generatorsystemen und/oder checklistengesteuerten Systemen der Hardwarehersteller.

Frühzeitig erkannte man im Hause SFD, daß auf Dauer der "Massenproduktion", der Herstellung eines leicht anpaßbaren Standards gegenüber der Auftragsfertigung von Software der Vorzug zu geben ist. Die Kosten einer Auftragsfertigung stehen in direktem Verhältnis zu den Personalkosten und steigen, will man keine Verluste in Kauf nehmen, so stark an daß sich in absehbarer Zeit kaum mehr Anwender finden werden, die diese hohen Kosten tragen. Hieran ändert auch der Einsatz von Methoden zur Qualitätssteigerung der Software nichts, da die Erstellungskosten dadurch kaum reduziert werden. Andererseits verlangt der Kunde vom Softwarehaus ein höheres Maß an Anpassung an seine Problemstellung als vom Hardwarehersteller, da das Softwarehaus meist als "Lieferant für Problemlösungen" verstanden wird.

Entschließt man sich als Softwareanbieter zur "Massenproduktion" - um durch Mehrfachverkauf die Entwicklungskosten zu amortisieren und preislich konkurrenzfähig zu bleiben -, so sieht man sich zwei Problemkreisen gegenüber:

- Dem Zwang zur Variabilität gegenüber Kundenwünschen (betriebswirtschaftliche Leistungsfähigkeit und Anpassungsfähigkeit des Softwarepaketes).

- Dem Zwang zu einem hohen Maß an Portabilität, um unterschiedlichen Hardware-lnstallationen und Betriebssystemen bei den Kunden begegnen zu können.

Mini-Modularisierung

Die Erfahrung aus über 100 Kundeninstallationen im Bereich der MDT hat SFD gelehrt, daß kein Kunde in seinen Ansprüchen und Wünschen mit einem anderen identisch ist. Auch wenn es auf den ersten Blick eine gleichartige Problemstellung zu sein schien, so ergaben sich doch im Detail, manchmal auch erst bei der Realisierung Unterschiede, die dann den Plan einer Mehrfacheinsetzung vorhandener Software zunichte machten. Dies führte bei SFD zu einem gänzlich neuen Ansatz für die Softwareerstelung. Nicht mehr das lauffähige Programm steht an erster Stelle, sondern eine Menge von kleinen und kleinsten betriebswirtschaftlichen, anwenderneutralen Funktionen, die gewonnen werden durch Zerlegung komplexer betriebswirtschaftlicher Bereiche (Auftragswesen, Finanzbuchhaltung, etc.).

Für eine spezielle Anwenderlösung werden aus dieser "Leistungsbank" die entsprechend benötigten Funktionen ausgewählt. Da dies checklistenunterstützt bereits vor der Angebotsabgabe erfolgt, lassen sich Überraschungen bei der Realisierung weitestgehend vermeiden.

Die ausgewählten Funktionen werden problemorientiert zu Programmen vereint. Diese Programme sind allerdings für sich gesehen nur Anhäufungen von Funktionen. Der betriebswirtschaftlich sinnvolle Ablauf wird durch Interpretation von Steuersätzen erreicht, in denen (wiederum checklistenunterstützt) festgelegt wird, für welche Belegart welche Funktionen aktiviert oder durchlaufen werden müssen. Ein vereinfachtes Beispiel soll dies verdeutlichen. Funktionen:

1. Ausgabe Anschrift auf Drucker

2. Ausgabe Position auf Drucker

3. Ermitteln Positionspreis

4. Drucken Positionspreis

5. Verändern Artikelbestand

6. Verändern Kundenumsatz

7. Druckgesamtpreis

Angenommen, in diesem Programm soll ein Bewegungsdatensatz zum Zweck der Lieferscheinschreibung verarbeitet werden, so werden der Steuersatz mit der Belegart (= Lieferschein) interpretiert und die Funktionen 1, 2, 5 durchlaufen. Soll die Rechnung geschrieben werden, so wird 1, 2, 3, 4, 6, 7 durchlaufen; sind Lieferschein und Rechnung identisch, so umfaßt diese Belegart die Funktionen 1-7.

Es gibt also keine speziellen Programme "Faktura" und "Lieferscheinschreibung" mehr.

Der Vorteil dieser Vorgehensweise ist:

- Der Anwender, bestimmt den Leistungsumfang "seiner" Software (Prinzip der Eigenfertigung).

- Die Leistungsbank wächst mit der Zahl der unterschiedlichen Anwendungen und

- durch die Anwenderneutralität der Funktionen gibt es weit weniger Schwierigkeiten bei der Kommunikation zwischen Softwarehersteller und Softwarekäufer als bei festen Standard- oder Branchenpaketen.

Bisher war nur von der betriebswirtschaftlichen Abfolge von Funktionen die Rede. Genauso wichtig ist die Flexibilität an der eigentlichen Schnittstelle zum Anwender, nämlich bei der Datenein- und -ausgabe. Die Ansteuerung von Bildschirm und Drucker erfolgt aus den betriebswirtschaftlichen Funktionen parametriert, und die Interpretation der Parameter wird in eigenständigen I/O-Moduln vorgenommen. Damit läßt sich aber nicht nur Flexibilität in Hinsicht auf den Anwender erreichen, sondern auch in großem Maße die Portabilität des eigentlichen Verarbeitungsquellcodes im Hinblick auf verschiedene Hardwarehersteller sicherstellen.

Aus letzterem Grund wurden nicht nur standardisierte Bildschirm- und Druckerschnittstellen, sondern auch eine standardisierte Datenzugriffsschnittstelle eingeführt.

* Hans-Dieter Braun ist Leiter der Entwicklung bei der SFD softwareengineering für datentechnik gmbh & co. kg, 8012 Ottobrunn.