Der Aufstieg und Fall ganzer Kulturen hat die Geschichtsforscher immer wieder beschaeftigt. Folgt man den Erkenntnissen eines ihrer fuehrenden Koepfe, so ist bereits in der Hochform einer Kultur ihr drohender Untergang zu erkennen: dann naemlich, wenn auf aktuelle oder anstehende Herausforderungen keine Antworten mehr gefunden werden. Nach Ansicht von Karl Schmitz* kann man grosse Unternehmen mit solchen Kulturen vergleichen. Der Autor prophezeit das Ende der "SAP-Kultur".

Unternehmen haben sich laufend wechselnden Herausforderungen zu stellen und darauf Antworten zu finden. SAPs Herausforderung - und da geht es der deutschen Vorzeigefirma keinen Deut besser als den anderen Giganten der Branche - ist das allzu oft schoengeredete Problem der Softwarewartung.

Wenn Kunden stoehnen, dass der simple Wechsel von R/2-Release 4.3 auf 5.0 bereits ein Projektabenteuer darstellt, das die Grenzen der Durchfuehrbarkeit spueren laesst, dann ist da - gelinde gesagt - ein Problem. Sicher ist es noch zu frueh fuer geschichtsschreiberische Aktivitaeten in Sachen SAP. Doch es mehren sich die Anzeichen dafuer, dass der Erfolg des groessten deutschen Softwarehauses nicht von Dauer ist.

Der Aufstieg der Firma SAP vorbei an der behaebig gewordenen Software AG zur unangefochtenen Nummer eins der deutschen Softwarebranche ist imposant. Diesen Platz werden die Walldorfer auch noch fuer laengere Zeit behaupten, kein Zweifel. Denn noch steht der eigentliche R/3-Boom aus. Und das, obwohl das Redesign der Mainframe-Software R/2, dessen Ergebnis R/3 ist, eher bescheiden ausfiel - das Bild vom alten Wein der Anwendungssoftware in neuen Schlaeuchen der Client-Server-Technik ist hier angebracht. Das jedoch scheint den Kunden nichts auszumachen, die Auftragsbuecher sind prall gefuellt und werden es bis auf weiteres bleiben.

Wer sollte der hochintegrierten Alleskoenner-Software ernsthaft Konkurrenz machen? Datenbankhersteller Oracle vielleicht, der seine "Financials"-Applikationen mit Software anderer Hersteller verbindet? Oder die "Mega"-Produkte von Quantum etwa?

Eine Reihe von Modernisierungen hat sich die SAP mit ihrer R/3- Software verordnet:

- Client-Server-Architektur mit - ab Release 3.0 - endlich ernstzunehmender PC-Funktionalitaet an den Front-ends;

- Lauffaehigkeit unter Hardwarehersteller-unabhaengigen Betriebssystemen wie Unix inklusive Zugestaendnis an die "neue Proprietaet" der IBM-Beerbungsfirma Microsoft (Windows NT) und

- Verzicht auf die hausgemachte Dateiverwaltung und Benutzung eines marktgaengigen relationalen Datenbanksystems.

Doch was hat es mit diesen Neuerungen wirklich auf sich? Client- Server-Architektur ist State of the art - nun auch bei der SAP. Suchen muss man allerdings die Anwenderfirma, die die reine Lehre verfolgt und beispielsweise Techniken des echt verteilten Daten- Managements nutzt. Die Realitaet: Landauf, landab findet man den zentralen Server, der die SAP-Datenbasis beheimatet, jetzt eben eine Unix-Maschine statt eines IBM- oder Siemens-Dickschiffes aus der guten alten Mainframe-Zeit. "Rehosting" waere die angemessenere Bezeichnung fuer das, was hier geschehen ist, und eben nicht Client-Server-Architektur.

Das Datenmodell bleibt dem Anwender verborgen

Gewiss, die Lauffaehigkeit der Software unter den gaengigen Unix- Systemen kommt einer laengst faelligen Befreiung vom Alleineinsatz des IBM- und Siemens-Equipments gleich. Oracle, Informix, Sybase: Der Anwender kann nun waehlen zwischen marktgaengigen relationalen Datenbanksystemen, weitere werden folgen. Fast koennte man annehmen, damit sei auch eine Alternative zu der proprietaeren SAP- internen Programmiersprache Abap IV gegeben, denn immerhin handelt es sich um SQL-Datenbanken. Doch naiv, wer geglaubt hatte, man kaeme nun mit den Bordmitteln des normalen Informatikbetriebs an die Datenbasis der SAP-Programme heran. Allzu apokryph ist das verwendete Datenmodell, dem normalen Anwender-Unternehmen bleibt es buchstaeblich verborgen. Weiter geht die proprietaere Abap- Wirtschaft, SQL-Zugriff unerwuenscht. Alles bleibt fest in SAP- Hand.

So laess die Antwort auf die bange Frage, was sich denn nun mit R/3 gegenueber dem Vorgaenger geaendert hat, nichts Epochemachendes erhoffen. Die Modernisierung scheint eine Kalibrierung des R/2- Systems auf Techniken, die heute eben up to date sind: Unix, relationale Datenbank, PC-Benutzer-Interface.

Viele Anwender nennen als Hauptmotiv fuer die SAP-Einfuehrung die Hoffnung, loszukommen von den vielen schlecht oder ueberhaupt nicht dokumentierten firmenspezifischen Verfahren. Sie wollen sich eng an die Standards halten und durch die Automatisierung der Ablaeufe einen Rationalisierungsgewinn erzielen. So, denken sie, entkommen sie der Abhaengigkeit von dem in den Koepfen der Mitarbeiter gebunkerten Wissen. Sie ziehen computergefuehrte Ablaeufe am Gaengelband einer eingekauften Software vor. Das soll die oft vermisste Sicherheit und Zuverlaessigkeit in die Arbeit bringen. SAP als Garant einer neuen Qualitaet - eine Art innerbetriebliche ISO 9000.

Diese Hoffnungen sind truegerisch. Der Anspruch des Systems, die Ablaeufe weitestgehend zu automatisieren und Zuverlaessigkeit dadurch zu erreichen, dass Benutzer die Daten in einer vom System vorgeschriebenen Art und Reihenfolge eingeben, haelt nicht, was er verspricht. Es tritt weder die gewuenschte Rationalisierung ein, noch erreichen Unternehmen die angestrebte Unabhaengigkeit vom im Kopf des Mitarbeiters gespeicherten Wissen. Im Beispiel auf Seite 61 ist dazu ein unpraetentioeses Beispiel wiedergegeben: das Anlegen einer neuen Kostenart im SAP-System RK-P fuer die Projektabrechnung. Mindestens ein halbes Dutzend verschiedener, teilweise sehr umfangreicher Arbeitsschritte ist erforderlich, um zum Ziel zu gelangen.

Der Benutzer benoetigt doppeltes Know-how

Wie das Beispiel zeigt, wird vom Benutzer sowohl buchhalterisches, also auf das jeweilige Sachgebiet bezogenes Wissen, als auch differenziertes Know-how ueber die Handhabung des DV-Systems gefordert. Ebenso sind detaillierte Kenntnisse ueber die betriebsspezifische Implementierung des SAP-Systems noetig. Man muss eben wissen, welche Berichte und welche der oft zahlreichen Abap- Programme von der Kostenarten-Erweiterung beruehrt sind. Vergisst man dabei einzelne Programme oder Berichte, so sind Inkonsistenzen die Folge.

Andere Mitarbeiter werden dann spaeter ueber den Unstimmigkeiten brueten. Das Beispiel macht deutlich, wie umfangreich und systemspezifisch die durchzufuehrenden Arbeiten in der Regel sind.

Die Wortschoepfung "Einpflegen" geht sicher nicht auf das Konto der SAP, doch auffaellig ist die haeufige Bemuehung dieser Kunstvokabel. Die Abhaengigkeit vom ablaufspezifischen Wissen in den Koepfen der Mitarbeiter ist ersetzt durch einen neuen Mix von immer noch ablaufspezifischem, aber jetzt in ein SAP-Vorgehensmodell gepresstem Wissen und einem softwaresystemspezifischen Know-how, das sich auf die Handhabung der Programmfunktionen bezieht.

"Ja, haettet Ihr auch die SAP-Ergebnisrechnung RK-E und wuerdet das nicht alles ueber Pseudokostenstellen in RK-S abbilden, dann waere Eure Installation nicht so kompliziert", agitiert der SAP- Consultant den Kunden. Leidgeplagt setzt dieser nun all seine Hoffungen in eine SAP-Totalloesung.

"Und ausserdem: in R/3 sind genau diese Probleme alle geloest, da gibt es ein Customizing, mit dem man die Abfolge der Arbeitsschritte festlegen kann."

Mit diesem Spruch wird in der Regel die kritische Stimme aus der Fachabteilung abgespeist. Auch der Verweis auf die naechste Softwareversion ist beileibe nichts Neues. Wenn schon so viel Geld ausgegeben wurde, dann muss die Software einfach gut sein. Kognitive Dissonanz heisst diese Umdeutung der wirklichen Verhaeltnisse in der Psychologie. Ein Dozent erklaerte das seinem Auditorium so: "Ein Student laedt eine Kommilitonin zum Abendessen ein und gibt dabei ueber seine Verhaeltnisse viel Geld aus. Was erzaehlt er seinen Freunden am naechsten Tag? Das war eine supertolle Frau, koennt Ihr Euch gar nicht vorstellen...". Das Problem, schlicht und ergreifend zuviel Geld ausgegeben zu haben, will schliesslich bewaeltigt werden.

Die Aufwertung des Objekts, fuer das ueber die Massen Geld investiert wurde, ist auch in Unternehmen eine offensichtlich hilfreiche Strategie. Wenn die Vorstandsetage eine zweistellige Millionensumme fuer die SAP-R/3-Einfuehrung im Budget abgesegnet hat, dann muss das einfach eine unvergleichlich gute Software sein. Geht ja nicht anders, denn sonst - nein, ein Vorstand irrt nie.

SAP ist ein funktionales System, das beste vermutlich, das umfangreichste sicherlich, das es heute fuer die Unterstuetzung der Arbeitsablaeufe in einem Unternehmen zu erwerben gibt.

Von den Schrauben im Lager bis zu den Ueberstunden des Personals, alles untergebracht in einem integrierten System, ohne die handelsueblichen und arbeitsintensiven Schnittstellen-Probleme.

Funktionales System heisst nicht mehr und nicht weniger, als dass die Konstrukteure von den Funktionen ausgegangen sind, die die Software im Betrieb erfuellen soll.

Diese Methode beruht auf der einfach anmutenden Idee, die gesamte Software aus der schrittweisen Verfeinerung der abstrakten Hauptfunktion des Systems zu gewinnen - von "oben" nach "unten" sozusagen.

Dieser Top-down-Ansatz, argumentieren seine Protagonisten, ist eine logische, wohlorganisierte Denkdisziplin, die eine geordnete Systementwicklung foerdert und die Komplexitaet des Aufgabenfeldes stufenweise reduziert. Alles bleibt im klassischen Rahmen, und das heisst auch Trennung von Daten und Programmfunktionen.

Die Gegenstaende der zu unterstuetzenden Arbeit sind in der Datenbank niedergelegt: Bestellungen, Rechnungen, Lagerbestaende oder die Zeitereignisse des taeglichen Kommens und Gehens der Beschaeftigten. Die Funktionen, also alles, was mit den Gegenstaenden gemacht wird, sind in den Programmstrukturen realisiert: Material- und Kapazitaetsdispositionen, Auslieferungen, Einlagerungen, Abrechnungen etc.

Den groessten Aerger in bezug auf die Top-down-Methode hat man mit der in puncto Wiederverwendbarkeit an die Software gerichteten Stetigkeitsanforderung. Darunter ist zu verstehen, dass eine Aenderung der Programmspezifikation nur wenige Module betreffen und nicht die gesamte Architektur des Systems beruehren soll.

Funktionen sind nicht der stabilste Teil eines Systems; sie aendern sich oft sehr schnell, waehrend die mit den Funktionen bearbeiteten Gegenstaende eine viel groessere Langlebigkeit aufweisen.

Die funktionale Zerlegung wird aber bei der Top-down-Methode als Hauptkriterium der Strukturierung benutzt. Die kurzfristige Bequemlichkeit einer recht einfach gewonnenen Anfangsstruktur wird durch eine langfristige Katastrophe erkauft: Wenn das System sich aendert, koennen die Entwerfer von vorne anfangen.

Der bisherige wirtschaftliche Erfolg von SAP taeuscht ueber dieses Strukturproblem hinweg. Die Medaille hat eine Kehrseite: der wahnsinnige Aenderungsaufwand, der gerne Softwarewartung genannt wird und mit zehn bis

15 Prozent der Lizenzerwerbssumme jaehrlich zu bezahlen ist. Wartung ist ein schmeichelhafter Begriff, denn Software verschleisst ja nicht wie ein Kugellager.

Was sich hinter dem Tarnwort verbirgt, sind ganz einfache Dinge: Fehlerkorrektur und Aenderungen oder Erweiterungen, weil die Anforderungen nicht mehr dieselben sind - seien es nun die des Marktes oder die von Benutzern.

Funktionalitaet als Orientierungslinie bedeutet, dass man sich dafuer zu interessieren hat, welche "Funktionen" im Betrieb zu erfuellen sind. Wie das im einzelnen geschieht, beschaeftigt dann die Programmierer. Funktionalitaet stellt das Wie der Arbeitsablaeufe in das Zentrum. Genau dieses "Wie" muss programmiert werden.

Das Manko an diesem Verfahren: Die Kundenanforderungen an die Programme aendern sich laufend. Kunden wollen auf einmal etwas grundsaetzlich anderes oder zumindest neue Behandlungsmoeglichkeiten. Customer- Fokus, der Kunde als Koenig, alles fuer und mit dem Kunden - welcher Betrieb wuerde diese Botschaft heute ignorieren? Fuer die Softwerker bedeutet das: Am "Wie" der Programme muss neu gebastelt werden, Aenderungen ohne Ende stehen an.

Von der Softwarekrise ist schon seit Jahrzehnten die Rede, weil die Handwerker den Aenderungsanforderungen nicht nachkommen. Vom Anwendungsstau ist euphemistisch die Rede. Vor lauter Staus bringen die Entwickler nichts Neues mehr zustande und geraten zusehends in die Schlagzeilen der innerbetrieblichen Kritik. Verstaerkt wird dieses Problem durch die ausgesprochene Schwerfaelligkeit, in der Programmaenderungen oder -erweiterungen erfolgen, wie das auf Seite 58 geschilderte Beispiel der Entstehung eines neuen Abap-Programms zeigt - entnommen aus dem Alltag einer SAP-Anwenderfirma.

Bis zu vier Monaten betraegt die "Zugriffszeit", wenn man darunter die Zeitspanne zwischen Artikulieren des Informationsbegehrens und seiner Erfuellung durch einen entsprechenden Report versteht. Und das alles findet in einer Zeit statt, in der Tempo sozusagen zum moralischen Imperativ erhoben worden ist. Die Schnellen fressen die Langsamen, nicht etwa die Grossen die Kleinen.

Da sitzen nun die Heerscharen von Softwerkern in ihren Programmiergaleeren und versuchen, des Aenderungsaufwands Herr zu werden. Derweil basteln 1500 Leute weiter am R/3-System. Eine Version nach der anderen kommt heraus (in der SAP-Sprache: Put Levels und Releases), immer umfangreicher und filigraner wird das Programm.

Damit sind wir bei unserer Prognose angekommen, warum die grosse Zukunft nicht mehr SAP und vergleichbaren Softwaresystemen gehoert. Diese Programme werden foermlich in ihrer eigenen Komplexitaet ersticken. Ihre Flexibilitaet wird zu einem gravierenden Problem. Was sich laufend im Betrieb aendert, und zwar immer schneller, sind die Funktionen, ist das Wie, wie die Dinge gemacht werden. Dieses Wettrennen mit der Zeit muessen die Hersteller funktionaler Alleskoenner-Software einfach verlieren, und wenn sie noch soviel Fliessbandmethoden ingenieurmaessiger Softwareproduktion anwenden.

Die funktionalen Programme sind ablauf- oder verrichtungsorientiert. Die Arbeitsablaeufe sind bis ins Detail und mit allen denkbaren Alternativen, je nach Einsatzbedingungen, vorgeplant. Was jedoch nicht als Ausfuehrungsmoeglichkeit programmiert wurde, kann auch nicht gemacht werden. Pech fuer den Kunden - Warten auf die naechste Version ist angesagt.

Ein Trost bleibt den Projektverantwortlichen, die ihr Unternehmen in die Totalabhaengigkeit der Dreibuchstabenfirma aus Walldorf getrieben haben: Man befindet sich in guter Gesellschaft. Unternehmen von Weltrang (wie die eigene Firma) haben sich schliesslich fuer SAP entschieden. Mehrheit schuetzt zwar nicht vor Irrtum, aber macht ihn doch merklich ertraeglicher. "Hammelherden- Syndrom" ist auch eine zutreffende Bezeichnung fuer dieses Phaenomen. Beim Grobentwurf einer Software-Systemarchitektur steht man vor der Frage, ob die Struktur eher auf den gewuenschten Aktionen oder aber auf den Daten und Informationen, den zu manipulierenden Objekten, aufsetzen soll. Sowohl Aktionen als auch Daten sind wichtig fuer das Programmsystem. Man muss sich entscheiden, wovon man ausgehen will.

Diese Frage ist vor allem unter dem Gesichtspunkt der Erweiterbarkeit oder praeziser der Stetigkeit wichtig. Stetigkeit ist fuer die Erstentwicklung eines Systems noch nicht so relevant, gewinnt aber entscheidende Bedeutung, wenn man den gesamten Software-Lebenszyklus betrachtet. Unter dem Gesichtspunkt, wie gut eine Software-Architektur spaetere Veraenderungsprozesse uebersteht, sind Objekte den Funktionen entscheidend ueberlegen.

Die Alternative heisst Objektorientierung

Im Werdegang eines Systems sind Funktionen der eher fluechtige Teil. Permanent entstehen neue Anforderungen. Wenn die Architektur zu sehr auf Funktionen beruht, dann ist nicht gewaehrleistet, dass die Weiterentwicklung des Systems ebenso gleitend erfolgen kann, wie sich Anforderungen aendern. Entwickelt sich ein System, koennen sich seine Aufgaben radikal aendern. Sehr viel mehr Bestaendigkeit dagegen findet sich in den Datenarten, auf denen gearbeitet wird, zumindest, wenn man dies auf einem ausreichend abstrakten Niveau betrachtet.

Das Plaedoyer fuer die Benutzung der Daten(objekte) als Schluessel zur Systemmodularisierung wird vor allem auf die Qualitaetsziele Vertraeglichkeit, Wiederverwendbarkeit und Erweiterbarkeit der Software gegruendet. Die Methode des objektorientierten Entwurfs fuehrt zu Software-Architekturen, die auf den von einem System oder Teilsystem bearbeiteten Objekten beruhen, und nicht auf den Funktionen, die das System realisieren soll. Man fragt also nicht, was das System tut, sondern woran es etwas tut.

Gegenstand des Softwaresystems sollten die Objekte des Geschaeftsalltags sein und nicht irgendwelche Informatikobjekte, wie sie heute noch mit den zahllosen Objekt-Libraries verkauft werden. Das alternative System wird kuenftig Objekte anbieten wie Kunden, Produkte, Anfragen, Offerten, Auftragsbestaetigungen, Rechnungen, Mahnungen etc.

Sie alle weisen gewisse Eigenschaften auf und reagieren auf bestimmte "Botschaften", in der Fachsprache heute meist "Methoden" genannt. Diese Botschaften repraesentieren Aktionen, die die Benutzer des Softwaresystems mit den Objekten durchfuehren koennen: Rechnungen koennen gebucht oder storniert, Offerten an Kunden verschickt werden etc.

Die Objekte des Systems lassen sich "klonen", wobei das neu erzeugte Objekt die meisten Eigenschaften seiner Vorlage erbt; nur wenige Dinge werden gezielt ueberschrieben oder weggelassen. Neue Eigenschaften lassen sich hinzufuegen, ebenso neue Botschaften, auf die die Objekte reagieren koennen oder sollen. Die Software-Objekte sind "abgekapselt", das heisst, sie zeigen nach aussen nur die Antennen fuer die Botschaften, auf die sie antworten koennen.

Ein Objekt "Rechnung" zum Beispiel reagiert auf eine Botschaft "buchen". Das Innenleben eines solchen Objekts geht seine Aussenwelt sozusagen nichts an, lediglich seine Kommunikationsmoeglichkeiten mit dieser Aussenwelt muessen "oeffentlich" sein.

So sind Aenderungen eines Objekts wesentlich besser ueberschaubar und bleiben - wegen der Kapselung - ohne moeglicherweise boese Folgen fuer andere Teile des Softwaresystems. Bei funktionalen Systemen dagegen muessen die Programmierer immer praesent haben, wie ein geaenderter Programmteil mit anderen Systemteilen zusammenhaengt.

Mit aeusserster Konsequenz zu Ende gedacht, heisst dies: In Software "modelliert" werden nur die "Gegenstaende", die Objekte eines Arbeitssystems. Sie reagieren auf bestimmte Anforderungen, die als "Botschaften" oder "Methoden" implementiert werden. Wie damit umgegangen wird, drueckt sich in der "ereignisgesteuerten" Handhabung des Softwaresystems durch seine Benutzer aus. Diese Handhabung beruht im wesentlichen auf Organisation und Absprache.

Die Menschen selbst werden zu Traegern der betrieblichen Flexibilitaet, darin liegt der entscheidende Vorteil der neuen Architektur. Frueher fuehrten - chronisch verspaetet - neue Ist- Analysen zur Erkenntnissen ueber zu veraendernde Arbeitsablaeufe. Diese wurden dann von Programmierern auf dem Wege umfangreicher Programmaenderungen in neue Transaktionen umgesetzt. Die Benutzer erhielten aufwendige Trainingseinheiten, um sich mit dem System vertraut zu machen. Nach dem neuen Konzept aendern sich Dinge auf der Basis von Absprachen zwischen Menschen, die untereinander festlegen, wie sie denn demnaechst mit den Objekten ihres Arbeitssystems umgehen werden.

Die Arbeitsorganisation obliegt allein den Menschen

Menschen haben die bisher noch von keinem Computersystem erreichte Faehigkeit, auch Orientierungen von grundlegender Bedeutung, wenn es sein muss, binnen kuerzester Zeitabschnitte aendern zu koennen.

Ein Softwaresystem kann da nur mithalten, wenn es die Art der Arbeitsabwicklung der Regie von Menschen ueberlaesst, jedenfalls so weitgehend wie moeglich, und nicht jedesmal ein Redesign des gesamten Systems erfordert.

Wenn die kommerziell angebotenen "Objektbibliotheken" eines Tages nicht mehr nur die Herzen der Programmierer erfreuen, sondern praktische Dinge des Arbeitslebens repraesentieren, dann wird eine neue Aera der Software-Entwicklung anbrechen. "Programmierer" im engsten Sinne des Wortes gibt es dann nicht mehr. An ihre Stelle treten Mitarbeiter, die neue Objekte entwerfen und Werkzeugkaesten bereitstellen, mit denen man - ohne Programmierung im heute ueblichen Sinne - solche Objekte veraendern und erweitern kann.

Die Jobs in der Softwarebranche aendern sich grundlegend. Es wird "Broker" geben, die das Angebot an Objekten checken und eine anforderungsgerechte Auswahl treffen. Und es wird eine Art von "Barmixern" geben, vielleicht die Benutzer selbst, die diese Halbfertigprodukte zu einem funktionierenden Arbeitssystem zusammensetzen.

Dr. Karl Schmitz hat ueber 100 Firmen zu speziellen Problemen beim Einsatz der SAP-Software beraten, besonders in solchen Faellen, in denen es Konflikte mit der Arbeitnehmer-Interessenvertretung gab. Seine Beratungstaetigkeit bezieht sich auf

- Projekte, in denen klassische Anwendungen auf Client-Server- Architekturen umgestellt werden,

- die Auswahl und den Aufbau von Softwre-Entwicklungswerkzeugen, die objektorientierten Entwurfsmethoden folgen und Realisierungen neuer Anwendungen durch kontinuierliche Verfeinerung von protoypischen Loesungen anstreben sowie

- Projekte, in denen es um die verstaerkte Einbeziehung PC- orientierter Software in grosse Multiuser-Systeme geht.