Da Standardsoftware nicht für einen bestimmten Kunden konzipiert wurde, gibt es Anforderungen, die sich damit nicht abdecken lassen. Deshalb müssen sich die Programme auch an nicht dafür vorgesehenen Stellen ändern lassen. Im folgenden werden die Modifikationspolitik und die entsprechenden Richtlinien der Softwarehersteller sowie die Möglichkeiten für einen anwendereigenen Modifikationsrahmen aufgezeigt.

Die wichtigste Voraussetzung für eine Modifikation ist zunächst, die Struktur des zugrundeliegenden Systems zu kennen. Darauf aufbauend stellt die Modifikationspolitik des Softwareherstellers eine bedeutende Prämisse dar, weil Programmänderungen in solch komplexen Systemen stets auch mit einer erhöhten Gefährdung für die Funktionszuverlässigkeit des Gesamtsystems einhergehen. Da auch der Softwarehersteller an einem möglichst fehlerlosen Einsatz seiner Software interessiert ist, bemüh, er sich, Gefahren durch geeignete Maßnahmen entgegenzuwirken.

Die Einflußmöglichkeiten des Herstellers auf das Ausmaß der Modifikationen im Unternehmen beschränken sich dabei allerdings auf Empfehlungen. Er kann aber generell die Programmteile bestimmten, in denen modifiziert werden darf, indem er nur für diese Teile Quellprogramme ausliefert. Nicht in der Original-Source ausgelieferte Programme sind nämlich nur lade- und ablauffähig, aber nicht modifizierbar. Im allgemeinen werden die betriebswirtschaftlichen Anwendungen in der Original-Source ausgeliefert, die zentralen Basisprogramme dagegen nicht.

Einige Softwarehersteller offerieren reduzierte Softwareversionen und sprechen damit verstärkt kleinere Unternehmen an: Durch die ständige Erweiterung des Standardfunktionsumfangs und eine gleichzeitig verstärkte Modularisierung der einzelnen Anwendungen kann diese Zielgruppe Standardsoftware einsetzen, ohne Modifikationen vorzunehmen - bei voller Abdeckung der Anforderungen.

Der Vorteil für das Anwenderunternehmen liegt dabei in einem günstigeren Anschaffungspreis. Der Softwarehersteller hingegen kann auf diese Weise ein weitgehend unmodifizierbares, nur in lade- und ablauffähiger Form ausgeliefertes Paket zur Verfügung stellen. Im übrigen bedeutet dies für den Kunden nicht, daß er keine Systemanpassung durch Tabellen vornehmen könnte; solche Operationen setzen keineswegs einen Eingriff in den Quellcode voraus. Zusätzliche Tabellenfelder oder gar Programmänderungen sind allerdings nicht realisierbar.

Eines der Probleme bei der Modifikation ist die Frage der Haftung. Prinzipiell besteht kein Haftungsanspruch, wenn in modifizierten Systemen Programmfehler auftreten. Ein Haftungsanspruch kann nur insofern geltend gemacht werden, als das Verschulden eindeutig auf seiten des Softwareherstellers liegt. Das ist jedoch nur der Fall, wenn die aufgetretenen Programmfehler auch in der Original-Source nachvollziehbar sind. Nachweispflichtig ist dabei der Anwender.

Die Modifikationsrichtlinien des Herstellers geben Empfehlungen zur möglichst reibungslosen Programmanpassung mit minimalem Aufwand. Ziel ist dabei zum einen, möglichen Überschneidungen von Kundenmodifikationen und Standardweiterentwicklungen vorzubeugen, zum anderen, die Konsequenzen der Modifikation bei einem angestrebten Release-Wechsel so gering wie möglich zu halten.

Als wichtigste Konvention gilt dabei, sämtliche Modifikationen nicht in der Original-Source, sondern in einer speziell dafür eingerichteten Modifikations-Source vorzunehmen. Der Modifikations-Quellcode ist der Original-Source in ablauffähiger Form vorgekettet. Somit werden alle in der Modifikations-Source vorhandenen Module (und nur diese) nicht mehr im Original gelesen. Dadurch bleibt der Standard immer in Form der Original-Source verfügbar, und jede Modifikation ist durch einfaches Löschen der Statements in der Modifikations-Source reversibel, weil automatisch wieder die Standard-Statements gelesen und verarbeitet werden.

User-Exits und Kundenreserven

Neben der Einrichtung einer Modifikations-Source sehen die Richtlinien der Hersteller auch die Nutzung von User-Exits und Kundenreserven vor. User-Exits unterstützen Änderungen der Ablauflogik. Dabei handelt es sich um leere, vom Hersteller bereits vordefinierte Programmodule, in die sich die Standardverarbeitung verzweigt.

Unternehmensspezifische Anforderungen lassen sich in Form von individuellen Prüfungen und Verarbeitungen programmieren und in diesen Modulen ablegen. Der Aufruf des Moduls veranlaßt die Ausführung der zusätzlich programmierten Verarbeitungsschritte; anschließend wird das Programm durch den Rücksprung in das Ausgangsmodul Standardmäßig fortgeführt. Leere Module bleiben wirkungslos.

Der Vorteil von User-Exits besteht in einer vordefinierten beziehungsweise mit Einschränkungen (unter Einhaltung der Herstellervorgaben zur Schnittstellen-Spezifikation) selbst programmierbaren, aber normierten Schnittstelle für die Kundenmodifikation. Diese Schnittstelle macht eine Programmmodifikation im Standardmodul selbst unnötig und garantiert einen möglichst geringen Umstellungsaufwand auf neue Release-Stände, weil nicht mehr alle Programmodifikationen nachzuvollziehen sind sondern lediglich der User-Exit richtig Positioniert werden muß.

Unter Kundenreserve ist zum einen der freie, für Felder des Anwenders reservierte Speicherplatz, innerhalb bestehender Satzbeschreibungen zu verstehen. Für den Anwender bedeutet dies, daß er - in Abhängigkeit von der Größe des freigelassenen Speicherplatzes - beliebig viele eigene Felder anhängen kann, ohne daß diese durch künftige Standardfelder verschoben werden, was eine korrekte Interpretation des Satzes unmöglich machen würde.

Zum anderen gibt es auch Kundenreserven zur Nominierung der Namensgebung von Modifikationen. Namenskonventionen bestehen beispielsweise für

- Tabellen,

- Felder,

- Programmodule,

- Transaktionen und

- Dateien.

Hervorzuheben bleibt, daß die Einhaltung der Namenskonventionen wie auch der übrigen Modifikationsrichtlinien nicht zwingend vorgeschrieben ist. Diese Konventionen sollen lediglich dabei helfen, den Aufwand des modifizierenden Unternehmens bei späteren Release-Wechseln zu minimieren. Ein Unternehmen, daß sich an diese Vorgaben hält, kann jedoch nicht davon ausgehen, daß die Herstellerhaftung für das modifizierte System erhalten bleibt.

Dokumentation ist unerläßlich

Modifikationen sollten auf das genaueste getestet und zwingend mit der Dokumentation der vorgenommenen Programmänderungen verbunden werden, wenn nicht die Wartung und die Weiterentwicklung des Gesamtsystems gefährdet werden soll. Abgesehen von der Dokumentation, die den Benutzern des Systems zugedacht ist, sind dabei vor allem die Quellcode-Kennzeichnung sowie die technischen Beschreibungen der Modifikation von grundlegender Bedeutung.

Ergänzt durch eine Modifikationsliste, die der Übersicht über alle Modifikationen dienen soll, bilden die Dokumentationsrichtlinien in Verbindung mit den erläuterten Konventionen die Voraussetzung für die Wartung und die Release-Fähigkeit des Systems, wenn der Standard modifiziert ist.

Einflußnahme auf den Hersteller

Ergänzt werden die programmtechnischen Möglichkeiten zur Anpassung von Standardsoftware durch die Einflußnahme der Anwender auf die Entwicklung der Softwarelösungen. Entwicklungsarbeit wird oftmals in kleinen Arbeitsgruppen geleistet. Trotzdem kommt große Bedeutung für die funktionale Qualität der Software nicht nur der Kommunikation der einzelnen Arbeitsgruppen untereinander zu, sondern vor allem auch dem Informationsfluß zwischen Hersteller und Anwender.

Für den Softwarehersteller gilt es, das Erfahrungspotential möglichst vieler Anwender zu nutzen und dieses Know-how in optimierte Lösungen umzusetzen.

Der Kunde profitiert von dieser anwenderorientierten Vorgehensweise, weil er die Chance hat, seine individuellen Realisierungswünsche vertreten zu können und - im Falle der Akzeptanz - als Standard geltend zu machen.

Um dieses beidseitige Interesse an einem möglichst engen Kontakt zu befriedigen, haben sich in der Praxis drei Verfahrensweisen entwickelt, die einander ergänzen: Zum einen gehen wertvolle Impulse von Benutzerkonferenzen aus. Definitionsgemäß sollen diese Veranstaltungen in erster Linie der Kommunikation der Anwender untereinander dienen. Aktuelle Produktentwicklungen und neue Tendenzen am Hard- und Softwaremarkt können dabei ebenso diskutiert werden wie Konzepte der Aus- und Weiterbildung.

Zum zweiten entstehen Funktionserweiterungen daraus, daß die Anwender dem Hersteller mitteilen, welche Leistungen sie vom System erwarten. Ein hoher funktionaler Erfüllungsgrad stellt die Existenzgrundlage von Standardsoftware dar. Dafür ist die Kooperation zwischen Entwickler und Anwender eine wichtige Voraussetzung - gerade in der Spezifikationsphase. Dazu lädt der Hersteller solche Anwender ein, die bezüglich Betriebsgröße und Branche für das jeweilige Projekt repräsentativ sind und entsprechendes Know-how mitbringen, damit sie die funktionalen Anforderungen definieren und die ersten Entwürfe beurteilen.

Eine dritte Möglichkeit zur Kontaktaufnahme bietet der zentrale Kundenservice. Jeder Installation ist im Normalfall ein Betreuer zugeordnet, der als langfristiger, zentraler Ansprechpartner dient. Dabei werden als Berater oftmals auch Mitarbeiter der Entwicklungsabteilung eingesetzt. Damit besteht die Möglichkeit, Alltagsprobleme, beispielsweise Mängel bei der Implementierung und im Produktivbetrieb der Softwarekomponenten, direkt in der laufenden Entwicklungen zu berücksichtigen.

Für Kunden, die einen Wartungsvertrag abgeschlossen haben, steht weiterhin ein Telefondienst zur Verfügung. Probleme können also im Bedarfsfall unverzüglich bearbeitet werden.

Diese Serviceleistungen des Softwareherstellers garantieren dem Anwender aber nicht nur Hilfe in Problemsituationen, sondern bieten ihm darüber Hinaus auch die Gelegenheit. seinen Gestaltungsvorschlägen Ausdruck zu verleihen.

Will der Softwarehersteller nicht am Markt vorbeiproduzieren, so kommt der Zusammenarbeit mit den Anwendern große Bedeutung zu. Aber auch wenn jeder einzelne Beitrag eines Anwenders sehr wertvoll sein kann, werden aus absatzpolitischen Gründen in die Standardsoftware nur die Anforderungen einfließen, die von den meisten Anwendern als sinnvoll angesehen werden.

Erschwerter Release-Wechsel

Die Konsequenzen einer Systemanpassung manifestieren sich in einem mehr oder minder erschwerten Release-Wechsel. Das Ziel des Release-Wechsels, die Teilnahme an aktuellen Software-Entwicklungen, läßt sich bei zusätzlich realisierten Systemanpassungen nur mit Hilfe eines erhöhten Umstellungsaufwands erreichen.

Je nach betrieblicher Aufgabenstellung und ablauforganisatorischen Vorgaben unterscheidet sich das Ausmaß des Mehraufwands dabei individuell bezüglich Intensität und Ausprägung.

Moderne Standardsoftware bietet zahlreiche Möglichkeiten zur Unterstützung der individuellen Ablauforganisation. Aufbauend auf der modularen Systemstruktur und abgesehen von der Modifikation der Standardprogramme, stellt dabei die Anpassung durch Tabellensteuerung die herausragende Eigenschaft dar. Trotzdem sollten auch die vom Softwarehersteller vordefinierten Systemanpassungsmöglichkeiten immer genauestens auf ihre Notwendigkeit hin überprüft werden, da die Problematik auch hier weniger in der einmaligen Anpassung und den damit verbundenen Kosten als im permanenten Pflegeaufwand beim Release-Wechsel besteht.

* Michael Fuchs ist als Doktorand bei der AEG Mobile Communication in Ulm beschäftigt und dort als Assistent der Projektleitung für die Einführung von SAP-Standardsoftware zuständig. Weiterhin arbeitet er als freier Berater für Plenum Institut, München.