Anwender der SAP-Standardsoftware R/2 haben in juengster Zeit die bittere Erfahrung gemacht: Je staerker Standardsoftware modifiziert wird, desto groesser sind die Schwierigkeiten beim Releasewechsel. Udo Schweers* raet: Anwender sollten eine Schmerzgrenze bezueglich der Anpassungskosten definieren, die sie nicht ueberschreiten duerfen.

Die Entscheidung zwischen Standardsoftware oder unternehmensspezifischen Entwicklungen (Individualsoftware) laesst sich nur auf Basis des unterschiedlichen Praxisumfelds und der Beduerfnisse eines Unternehmens faellen. Zukunftsorientierte Markt- und Kosten-Nutzen-Analysen ermitteln die Anforderungen an die DV und geben die noetigen Impulse fuer eine Entscheidung.

Die meisten Unternehmen setzen auf Loesungen, die weder ausschliesslich auf Standardsoftware noch auf reinen Individualprodukten beruhen, sondern eher in einer oekonomisch vertretbaren Zwischenzone zu finden sind - eine fuer Insider bekannte Tatsache.

R/2 - ein Beispiel fuer Komplexitaet

Das Beispiel der Mainframe-Standardsoftware R/2 von der SAP AG verdeutlicht, wie komplex Software geraten kann, wenn sehr viele betriebswirtschaftliche Vorgaenge mit Standards abgedeckt werden. In dieses System fliessen mittlerweile umfangreiche Entwicklungsleistungen des Herstellers und die Erfahrungen vieler Anwender ein. Bereits bei der Entwicklung hat SAP erkannt, dass auch ein Standardsystem einen individuellen, das heisst variablen Charakter besitzen muss, um den unterschiedlichen Kundenanforderungen zu entsprechen.

Die Philosophie der modularen Bauweise war ein erster Schritt in Richtung Individualitaet. Der Anwender kann aus einer Reihe von Applikationen und den zugehoerigen Komponenten sein Paket nach den jeweiligen Anspruechen zusammenstellen und gegebenenfalls spaeter ausbauen.

Der naechste Schritt ist die Anpassung der Software ueber die Standardtabellensteuerung. Das System bietet innerhalb einzelner Steuerelemente mehrere Alternativeinstellungen an, damit sich Anpassungen vornehmen lassen, ohne den eigentlichen Standard veraendern zu muessen. Diese Adaptionsmoeglichkeiten sind bereits so komplex, dass sich viele Anforderungen des jeweiligen Unternehmens abdecken lassen.

Die Anpassungsmoeglichkeiten sind je nach Applikation unterschiedlich. Der Bereich Finanzbuchhaltung (RF) ist durch umfangreiche Gesetzgebung in ein sehr enges Korsett gedraengt, so dass die Modifikationsmoeglichkeiten aeusserst gering sind. Dagegen laesst sich die Applikation Vertrieb (RV) nahezu beliebig anpassen. Immerhin muessen die Anforderungen unterschiedlicher Produkte, Maerkte und unternehmerischer Strukturen beruecksichtigt sein.

Sich oeffnende Maerkte haben in den letzten Jahren den Wettbewerb kontinuierlich verschaerft und die Nachfrage nach mehr Flexibilitaet erhoeht. Der Kunde rueckt in den Vordergrund. Durch sein Kaufverhalten bestimmt er direkt die unternehmerischen Strukturen; die Software passt sich dem Kunden an, nicht umgekehrt.

Der Versuch, eine Kundengruppe zu standardisieren, ist oft genug fehlgeschlagen. Kaum kalkulierbare Faktoren wie Wetter, Ernte, Boerse, Mode etc. beeinflussen das Kaufverhalten stark.

Der Kunde kauft dort, wo seine Beduerfnisse abgedeckt werden - das erfordert vom Anbieter ein hohes Mass an Flexibilitaet. Spaetestens hier stoesst eine Standardsoftware an ihre Grenzen, Indivi- dualisierung ist gefragt.

Mit zunehmender Individualitaet der Software steigt natuerlich auch der Aufwand fuer die Installation, Systempflege und Wartung. Um den Aufwand im Rahmen zu halten, sollte sich ueberall dort, wo es moeglich ist, die Organisation einzelner Ablaeufe innerhalb des Unternehmens an den Softwarestandard anpassen und nicht umgekehrt. Erst wenn diese Moeglichkeiten ausgeschoepft sind, stehen Modifikationen an.

Die eingangs erwaehnte Kosten-Nutzen-Analyse hat den Aufwand fuer solche Anpassungen zu beruecksichtigen. Es empfiehlt sich, eine Schmerzgrenze zu definieren, bei deren Ueberschreitung eine Standardloesung zu individuell und damit zu teuer wird. Gewiss ist es nicht einfach, den kuenftigen Modifikationsaufwand auf Heller und Pfennig abzuschaetzen. Deshalb sollte an dieser Stelle grosszuegig geplant werden. Ausserdem sind intensive Gespraeche mit erfahrenen Anwendern hilfreich. Ein nachtraeglicher "Rueckzug" aus einem installierten System ist nur unter immensem Kostenaufwand moeglich, von den technischen Problemen ganz zu schweigen.

Die Modifikation von Standardsoftware fuehren in der Regel gut bezahlte Spezialisten durch. Das bedeutet: Die Kosten fuer den Personaleinsatz wachsen schnell ueber die eigentlichen Softwarekosten hinaus. Was vor Jahren noch als gegeben hingenommen wurde, rueckt heute in den Mittelpunkt und versteht sich als Anforderung und Ansatz zur Loesung.

Ein Pruefstein fuer Standardsoftware-Benutzer ist der Release- Wechsel. Immer schnellere Entwicklungsleistungen der SAP erfordern die Adaption vorhandener Release-Staende in immer kuerzeren Zyklen. Das Einspielen des neuen Release sollte natuerlich mit deutlich geringerem Aufwand zu realisieren sei als eine Erstinstallation. Dennoch ist die Aufgabe nicht trivial: Tabellenaenderungen auf Standardebene muessen sich ebenso logisch ueberpruefen lassen wie Modifikationen in dem "alten Release".

Bei diesen Veraenderungen handelt es sich meist um sehr komplexe Gebilde, die vor einem bestimmten Hintergrund und mit einer entsprechenden Strategie entstanden. Um die Standardsoftware auf einen neuen Release-Stand zu bringen, ist es erforderlich, sich genau in die jeweiligen Hintergruende (warum wurde geaendert) und Strategien (was wurde geaendert) einzuarbeiten sowie alle betroffenen Objekte zu pruefen und gegebenenfalls erneut zu aendern.

Releasewechsel koennen laenger als ein Jahr dauern

Diese Aufgabe, die eine Analyse der vorgenommenen Aenderungen nach betriebswirtschaftlicher Notwendigkeit einschliesst, erfor-dert einen enormen Personalauf-wand. Umsetzungszeiten pro Release- Wechsel von bis zu anderthalb Jahren sind moeglich.

Dadurch wird deutlich, wo das eigentliche Problem liegt: Die Kosten fuer Beratung, interne Pflege und Modifikation der Software uebersteigen in der Regel den Anschaffungsaufwand bei weitem. Bei Release-Wechseln ist die gleiche Beratungs- und Modifikationsleistung, die bei der Neueinfuehrung von Standardsoftware notwendig war, noch einmal einzubringen.

SAP selbst beschraenkt sich darauf, fuer den R/2-Release-Wechsel Werkzeuge anzubieten, die lediglich eine Uebernahme von Standards in die neue Version unterstuetzen. Die Verwaltung der vorgenommenen Modifikationen bleibt dem Anwender ueberlassen. Nur wenige Softwarehaeuser, die IMD zaehlt sich dazu, haben bis dato diese Marktluecke erschlossen, indem sie ganzheitliche Loesungen zur Pflege und Transparenz des Systems offerieren.

Gefragt sind Systeme, die ein Tool-gestuetztes, integriertes Standardsystem-Management besitzen. Philosophie sollte es sein, mit gezielten, teilweise automatisierten Vorgaengen die Folgekosten (Pflege, Systemwartung, Release-Wechsel) im Umgang mit SAP- Software zu reduzieren. Es ist beruhigend zu sehen, dass das Prinzip der freien Marktwirtschaft auch hier greift und es immer wieder findige Unternehmen gibt, die neben und gemeinsam mit bekannten Softwaregroessen Schwachstellen aufdecken und sinnvolle Loesungen anbieten.