CW: Die Einführung von R/3 und die Neuorganisation der Geschäftsprozesse verlaufen in Unternehmen oft nicht synchron. Empfehlen Sie das Re-Engineering vor, während oder nach der Software-Implementierung?
Zencke: Diese Entscheidung überlassen wir unseren Kunden. Sie kann nicht durch ein Software-Instrument oder eine Anwendung vorweggenommen werden. Da wir auf sehr unterschiedliche Anwenderszenarien treffen, müssen unsere Methoden offen sein. Die IBM beispielsweise, einer unserer größten Kunden, hat Hunderte von Niederlassungen und eigenständigen Vertriebssystemen. Kunden und Produkte, die in diesen Systemen angesprochen werden, sind nicht identisch. Deshalb wird bei der IBM mit der R/3-Entscheidung das Ziel verbunden, Tausende von gewachsenen Prozessen zu vereinheitlichen und zu verschlanken. Sie werden in wohldefinierte Unternehmensprozesse umgesetzt.
CW: Führt diese Vereinheitlichung nicht zu einem Verlust an Individualität? In der Vergangenheit wurde oft kritisiert, daß SAP-Kunden auf ein Software-unabhängiges Re-Engineering verzichten und vorhandene Prozesse, so wie sie sind, betonieren.
Zencke: Nahezu alles, was wir im letzten Jahr unternommen haben, hatte zum Ziel, Prozesse variabel zu gestalten. Sie sollen eben nicht in einer einmaligen Einstellung definiert werden. Im Gegenteil: Wir gehen von einer Grundstruktur aus, die Veränderungen möglich macht. Es ist der falsche Ansatz, die idealen Prozesse über Jahre hinweg herauszuarbeiten und auf dem Papier zu fixieren, um anschließend noch einmal anderthalb Jahre für die Implementierung aufzuwenden. Dann haben wir tatsächlich eine Zementierung von Strukturen, die längst schon wieder überholt sind.
Die betriebswirtschaftlichen und ökonomischen Rahmenbedingungen wandeln sich schneller, als es die langfristig getakteten Projekte können. Deshalb sollte man im Rahmen einer Re-Engineering-Diskussion vor allem die Top-Unternehmensziele festlegen und jene Kernprozesse herausarbeiten, deren Beschleunigung einem Unternehmen Vorteile bringt. Diese per ABC-Analyse ermittelten Prozesse müssen möglichst schnell implementiert werden.
CW: Gerade die R/3-Einführung ist dafür bekannt, daß sie Jahre dauern kann. Was haben Sie konkret unternommen, um sie einfacher zu machen?
Zencke: Anfang der 90er Jahre haben wir damit angefangen, die SAP-Prozeßmodelle in einem PC-basierten Umfeld zu publizieren. Dazu haben wir das Aris-Toolset von IDS verwendet, das von R/3 unabhängig ist. Firmen konnten ihre Prozesse analysieren und sich dann eventuell - nicht notwendigerweise - für R/3 entscheiden. Mittlerweile sind wir so weit, daß diese Prozeßmodelle und eine Reihe ergänzender Tools ein Toolset bilden, das wir die Business Engineering Workbench nennen. Diese ist integraler Bestandteil des R/3-Systems geworden. Sie soll nicht nur als Re-Engineering-Tool dienen, sondern die Möglichkeit bieten, sehr schnell über mögliche Prozeßabläufe im SAP-System Klarheit zu gewinnen. Zunächst wird keine 100-Prozent-Einführung angestrebt, sondern die schnelle Implementierung der wichtigsten Prozesse - so, wie sie aus einer ABC-Analyse hervorgegangen sind. In einem zweiten und dritten Schritt des kontinuierlichen Change-Managements kann der Abdeckungsgrad erhöht werden. Je nach Erfahrungen und Lernverhalten der jeweiligen Firma können die Prozesse dabei verschlankt und optimiert werden.
CW: Der "Analyzer" ist nicht mehr das einzige Werkzeug, mit dem R/3-Anwender ihre Geschäftsprozesse modellieren können ...
Zencke: ... es gibt inzwischen auch Schnittstellen zu anderen Tools, sowohl zu einfachen Grafik-Werkzeugen wie Visio als auch zu intelligenteren Modellie- rungs-Tools wie Intellicorp. Wenn wir in Form der Business Engineering Workbench ein betriebswirtschaftliches Repository als Teil des R/3-Systems anbieten, dann müssen wir dieses offen gestalten. Wir haben in diesem Repository Informationen über Prozeß- und Objektdatenmodelle abgelegt. Über entsprechende APIs können fremde Toolsets auf diesen Modelle aufsetzen und sie bei Bedarf in eine andere Systemumgebung überführen. Damit machen wir das betriebswirtschaftliche Wissen, das Teil des R/3-Systems ist, auch für andere Umgebungen verfügbar.
CW: Warum ist das wichtig?
Zencke: Es kann unseren Beratungspartnern nützen, die möglicherweise eine andere Tool-Wahl getroffen haben als SAP. Es kann auch unseren Kunden dienen, die mit demselben Tool nicht nur die SAP-, sondern auch die vorhandene Legacy-Umgebung modellieren möchten. Wenn Kunden schon vor ihrer SAP-Entscheidung bestimmte Tools ausgewählt haben, müssen ihnen darin ebenfalls unsere Inhalte zur Verfügung stehen.
CW: Damit hat sich Ihre Verbindung zur IDS gelockert?
Zencke: Sie hat nicht mehr den exklusiven Charakter der Vergangenheit. Unsere Offenheit an dieser Stelle ist aber kein Streitpunkt. Das Aris-Toolset ist ja ebenfalls offen, es unterstützt additiv zu dem, was für das SAP-System benötigt wird, auch andere Modellierungsmethoden.
CW: Anwender geben weitaus mehr für Beratungsleistungen als für die R/3-Software selbst aus. Müßte SAP da nicht gegensteuern?
Zencke: Wir haben unsere Partnerstrategie deshalb aufgelegt, weil SAP mit seinem R/3-System in eine Kundenbasis hereingewachsen ist, die von den eigenen Beratungskräften nicht mehr zu bewältigen gewesen ist. Also arbeiten wir mit den sogenannten Big Six, aber auch mit einer Reihe lokaler Beratungshäuser zusammmen. Wir müssen diese Häuser ausbilden, als wären es SAP-eigene R/3-Berater.
Ganz offen gesprochen: Es gibt teilweise einen Interessenkonflikt. SAP möchte in jedem Fall schnell implementieren, während ein Beratungshaus unter Umständen der Versuchung erliegt, möglichst viele Mitarbeiter beim Kunden unterzubringen. Wir haben deshalb ein Benchmarking für Beratungshäuser eingeführt. Wir können ermitteln, was eine schnelle und was eine langsame Einführung ist. Unsere eigenen Spezialisten definieren Musterfälle und beweisen, daß es möglich ist, schlanke Einführungen von R/3 schnell und qualitativ hochwertig zu realisieren.
CW: SAP übt also Kontrolle über die Beratungsbranche aus?
Zencke: Unsere Kunden haben Anspruch auf Transparenz. Sie wollen wissen, ob ihr Projekt von der Dauer und Qualität her optimal läuft. Von uns erfahren sie beispielsweise, unter welchen Bedingungen es gelungen ist, ein FI-Modul innerhalb von sechs Wochen einzuführen. Mit Hilfe unserer Business Engineering Workbench können wir das, was ein Berater beim Kunden tut, festhalten und dem Kunden transparent machen. Alle Einstellungsabsichten, alle Prozeßauswahlen, alle Customizing-Aktivitäten werden im System dokumentiert, so daß der Kunde eine Wissensdatenbank erhält, auf der er morgen weiterarbeiten kann. Es gibt also keine Abhängigkeit von dem Berater, der die Ersteinführung gemacht hat.
CW: Herr Plattner, stellvertretender Vorstandsvorsitzender der SAP AG, hat schon vor Jahren angekündigt, er wolle eine sehr simple Einführungsmethode für R/3 etablieren. Was ist daraus geworden?
Zencke: Es handelt sich dabei um den Configure-to-order-Gedanken. Vor allem für unsere kleinen Kunden kommt es darauf an, daß sie sich nicht in der funktionalen Mächtigkeit des R/3-Systems verlieren. Wir müssen ihnen eine Möglichkeit schaffen, den von ihnen benötigten Ausschnitt aus dem R/3-System innerhalb von zwei Wochen zu identifizieren. Zu Beginn öffnen wir diesen Kunden nur einen gewissen Korridor und versuchen, sie nicht mit 1001 Entscheidungen zu überlasten.
Einen Automobilzulieferer beispielsweise interessiert es nicht, was wir im Bereich Treasury für große multinationale Konzerne bieten. Er will auch nicht wissen, was wir im Öl- oder im Food-Bereich machen. Möglicherweise deckt der Ausschnitt von R/3, den er nutzt, nur 20 Prozent des gesamten Systems ab. Daher konzentrieren wir unsere Anstrengungen darauf, das Zuschneiden von R/3 auf den jeweils benötigten Maßanzug zu fördern. Der Kunde soll einen Teilausschnitt des Systems definieren und herausfiltern können, der seinem Geschäftsinteresse entspricht.
CW: Ist nicht generell der Ansatz eines multifunktionalen Systems fragwürdig, wenn dieses mehrheitlich Funktionen bietet, die der Kunde gar nicht benötigt?
Zencke: Das haben wir uns sehr lange überlegt - vor allem auch, weil es gestern noch technische Restriktionen gab, die gegen den Einsatz einer solch umfassenden Lösung sprachen. Wenn man aber bedenkt, daß das gesamte R/3-System heute auf einem Laptop läuft, gibt es aus der technischen Überlegung her keine Notwendigkeit zu sagen, wir liefern nur 20 Prozent. Wir liefern alles!
Ein zweiter Aspekt ist noch wichtiger. Wir haben uns gefragt: Ist eine Mittelstandsversion von R/3 eigentlich sinnvoll? Wie sieht der Ausschnitt des R/3-Systems aus, den der Mittelständler braucht? Ich will Ihnen ganz offen sagen: Wir sind an einer solchen Definition gescheitert. Wie auch immer wir das Paket geschnürt haben, stets kamen Kunden mit Anforderungen, von denen wir nicht geglaubt hatten, daß sie benötigt würden.
CW: Der Ansatz, aus einem komplexen Paket die benötigten Funktionen herauszuselektieren, wird immer häufiger in Frage gestellt. Anwendungen der Zukunft setzen sich angeblich aus verschiedenen, teilweise Internet-fähigen Objekten und Modulen zusammen ...
Zencke: ... ob das die Zukunft ist, weiß noch keiner. Zumindest im Bereich der betriebswirtschaftlichen Applikationen sind wir noch sehr viel weiter davon entfernt, als sich das manch einer träumen läßt. Objektorientierte Standardsoftwareprodukte aus dem betriebswirtschaftlichen Bereich gibt es auf dem Markt so gut wie gar nicht, nahezu alle Konkurrenten und Partner der SAP haben damit eklatante Schwierigkeiten bekommen.
Natürlich ist es eine schöne Vorstellung zu sagen: Funktionen werden von unterschiedlichen Herstellern bezogen, zu Komponenten gekapselt und der Kunde stöpselt diese dann zusammen. Ob das aber die Industrie der Zukunft sein wird? Ich wage mal, ein Fragezeichen zu setzen. Es steckt eine unvorstellbare Engineering-Arbeit darin, die Kommunikationsschnittstellen solcher Komponenten herstellerübergreifend zu definieren. Wenn das nicht geschieht, funktioniert das ganze Spiel ja nicht.
CW: Ein R/4 will die SAP nach Bekunden ihres Vorstandsvorsitzenden nicht herausbringen, aber offensichtlich haben Sie Erfahrungen in der Verbindung unterschiedlicher Komponenten ...
Zencke: ... was in der Linie der evolutionären Weiterentwicklung von R/3 liegt. Im Rahmen unserer Arbeiten innerhalb der OAG (Open Application Group, Anm. d. Red.) haben wir beispielsweise nach Wegen gesucht, wie sich das Materialwirtschaftssystem eines Herstellers A mit der Finanzbuchhaltung des Herstellers B so unterhalten kann, daß die rechtlichen Anforderungen erfüllt werden, die sich aus der Bestands- und Rechnungsprüfung ergeben. Dieses eine kleine Szenario hat uns ein Jahr intensiver Arbeit gekostet. Und daran waren noch nicht einmal alle OAG-Mitglieder beteiligt. Durchgehend implementiert wird das auch erst in diesem Jahr. Die herstellerübergreifende Standardisierung erfordert also das berühmte Bohren dicker Bretter.
CW: Erweckt die SAP mit der Definition sogenannter "Business Objects" nicht den Anschein, sie sei ebenfalls im Markt für objektorientierte Systeme zu Hause?
Zencke: Grundprinzipien der Objektorientierung wie Datenkapselung und Methodendefinition gehören zur Grundlage der R/3-Anwendungsorientierung - auch wenn Abap/4 heute noch nicht den Anspruch hat, eine vollständig objektorientierte Entwicklungsumgebung zu sein. De facto implementieren wir nicht eine Vielzahl von Prozessen parallel, sondern Objekte und Objektmethoden, aus deren Kombinationsfähigkeit sich die Vielzahl möglicher Prozesse ergibt. In der Business Engineering Workbench ist die prozeßorientierte Sicht mit Business-Objekten und ihren Methoden verbunden. Wir gehen jetzt schrittweise dazu über, diese Objekte mit Business-APIs zu versehen, die den externen Zugriff auf bestimmte Methoden dieser Business-Objekte ermöglichen.
CW: Vereinfacht gesagt: Sie schaffen eine Art Kapsel für Funktionen oder Objektmethoden, die beispielsweise über das Internet angesprochen werden sollen?
Zencke: Ja, aber nicht nur für das Internet. Es kann auch sein, daß ein Kunde eine individualisierte PC-Oberfläche über die SAP-Anwendung stülpen möchte. Denken Sie nur an den Telefonverkauf, da möchte man nur ganz bestimmte Daten überhaupt eingeben, alles andere soll automatisch beschickt werden. Solche Formen der Individualisierung liegen im Trend und werden von uns aktiv unterstützt. Trotzdem möchten wir aber, daß die internen, wirklich komplexen betriebswirtschaftlichen Funktionen und die nachfolgende Integration in Manufacturing, Lieferwesen oder Fakturierung exakt so läuft, wie SAP es in den prozeßorientierten Implementierungen vorgesehen hat.
CW: Kritiker halten Ihnen vor, nur scheinbar moderne Ansätze wie Objektorientierung und Internet zu adaptieren, in Wirklichkeit aber mit einem seit 20 Jahren unveränderten Softwarekonzept ins nächste Jahrhundert gehen zu wollen ...
Zencke: ...das ist einfach falsch. Schon der Weg vom Mainframe, einem wirklich monolithischen System also, in eine Client-Server-Umgebung war ein riesiger Sprung. So ist beispielsweise die Art der von R/3 unterstützten Integration völlig anders als die von R/2. Mag sein, daß der Eindruck eines Monolithen entstanden ist, weil wir anfangs in R/3 eine zentrale Datenbankstrategie verfolgen mußten. Unser Problem ist, daß verteilte Datenbanksysteme auch heute noch extreme Limitationen aufweisen.
Doch wir haben hier frühzeitig reagiert und bereits 1993 das Application-Link-Enabling-Konzept vorgestellt. ALE ermöglicht per Message-orientierter Kommunikation den Verbund heterogener R/3-Systeme, von R/2- und R/3-Systemen sowie von R/3 und Systemen anderer Hersteller. Es kommt immer dann zum Einsatz, wenn eine zentrale Datenhaltung nicht zu realisieren ist.