CW: Bereits vor drei Jahren hat die SAP angekündigt, das R/3-Kernsystem in separate Module zu zerteilen. Bislang haben Sie dieses Versprechen nicht eingelöst. Haben Sie das Engagement für die Entkopplung des R/3-Systems angesichts Ihrer Mammut-Projekte wie "Mysap.com" und "Enjoy SAP" heruntergefahren?
Tolkmit: Nein, die Modularisierung von Anwendungen verstärkt sich im Zeitalter von E-Commerce sogar noch. Die Programmbausteine, die hinter den künftigen Web-Anwendungen stehen, werden kleiner, und die Kopplungstechniken spielen dabei eine wichtige Rolle. Insofern wird uns die Komponentisierung von R/3 auch in Zukunft stark beschäftigen.
Das Konzept, das wir 1996 auf der Sapphire in Wien vorstellten, haben wir mit Leben gefüllt. Nur wie wir unsere Software heute zerlegen, hat sich im Gegensatz zu den ursprünglichen Plänen geändert.
CW: Konkret bitte...
Tolkmit: Wir wollen Applikationen nicht einfach nur technisch an irgendeiner theoretisch festgelegten Linie zerschneiden. Ziel ist vielmehr, die natürliche Trennung von Aufgaben, Prozessen und Organisation im Unternehmen durch unsere Softwaremodule zu unterstützen. Wenn man an einer Stelle die Software austauscht, soll sich das auch nur dort auswirken und möglichst wenig Nebeneffekte nach sich ziehen. Diesen Maßstab legen wir heute an, wenn wir modularisieren. Ein erster Schritt dazu war die Heraustrennung der Personalwirtschaft (Human Resources = HR).
CW: Geplant war auch, die Finanz- und Logistikanwendungen zu entflechten.
Tolkmit: Logistik und Finanzen trennen zu wollen, so wie wir es damals planten, ist aus heutiger Sicht falsch. Man kann die Funktionen nicht glasklar voneinander abgrenzen und beispielsweise alle Finanzaspekte in einer Finanzbuchhaltungskomponente und die Produktionsbelange in einem entsprechenden Fertigungsmodul abbilden.
Der Charme einer integrierten Lösung besteht doch gerade darin, daß Aktionen etwa im Logistikbereich Auswirkungen auf den Finanzteil haben und umgekehrt, und daß diese auch sofort sichtbar sind.
Mit unseren "New-Dimension"-Produkten zum Beispiel für Supply-Chain-Management, Sales Force Automation und Data-Warehousing haben wir das erreicht: Auf der einen Seite sind diese Satelliten stark mit R/3 integriert, auf der anderen Seite aber können sie auch als unabhängige Softwarekomponente eingesetzt werden, die kompatibel mit allen bestehenden R/3-Versionen ab dem Release 3.1 aufwärts sind. Ein Beispiel dafür ist das Business Information Warehouse (SAP BW), daß sich mit allen R/3-Systemen ab Release 3.1 verträgt.
CW: Sie richten sich bei der Modularisierung also nach üblichen Geschäftsabläufen und -Szenarien.
Tolkmit: Ja. Man kann beispielsweise ein R/3-System so konfigurieren, daß ein System als Vertriebssystem (SD) arbeitet und eine zweite Installation für die Produktionsplanung (PP) und Finanzwirtschaft (FI) vorgesehen ist.
CW: Können Kunden in diesem Fall dann unterschiedliche R/3-Versionen im Verbund einsetzen und aktualisieren?
Tolkmit: Entlang dieser Anwendungsszenarien ist das möglich.
CW: Kunden sind also auf die vorgedachten Geschäftsmodelle von SAP angewiesen, da sonst die entsprechenden Interfaces nicht vorhanden sind.
Tolkmit: Innerhalb des "Interface Advisors" sind diese Integrationsszenarien und Verbindungsmöglichkeiten der unterschiedlichen Bausteine beschrieben.
CW: Dazu braucht man allerdings eine Vielzahl von Schnittstellen und einen Übertragungsmechanismus zwischen den einzelnen Systemen.
Tolkmit: Wir greifen dazu auf unsere Business Application Programming Interfaces (BAPIs) zurück, die auch für die Anbindung externer Systeme angewendet werden. Ferner setzen wir den hauseigenen Mechanismus Application Link Enabling (ALE) ein und übertragen die Daten in einem sogenannten Intermediate-Document-(Idoc-)Format. Stark nachgefragt wird derzeit von Kunden allerdings die XML-Kompatibilität von Schnittstellen. Wir wollen mit unseren BAPIs neben den Idocs deshalb künftig auch diesen Standard unterstützen.
CW: Ihre Verbindungstechnik ALE mit den dazugehörigen Idocs ist laut Diebold kompliziert, wenig praxiserprobt und hat vor allem bei großen Datenmengen Performance-Probleme. Zudem sind am Markt wenig erfahrene Berater mit ALE-Know-how verfügbar.
Tolkmit: Das stimmt nur teilweise. Aber der Markt insgesamt hat bisher wenig Erfahrung darin, wie und welche Anwendungen sinnvoll zu verteilen sind. Es gibt keinen Generalbebauungsplan, und auch die Standardisierung von Schnittstellen ist wenig fortgeschritten.
Es bedeutet für Kunden immer einen konzeptionellen Aufwand, sich zu überlegen, wie man die Systeme verteilt und beispielsweise das Recovery und Backup organisiert, das in verteilten Systemen natürlich komplizierter ist.
Die angesprochenen Performance-Probleme treten in der Regel durch geringe Bandbreiten auf, wenn Anwendungen auf verschiedenen Rechnern installiert sind. Aber die Modularisierung von Applikationen muß ja nicht zwangsläufig bedeuten, daß die Module auf unterschiedlichen Systemen ablaufen. Es besteht die Möglichkeit, die Verarbeitung innerhalb eines Rechners zu verteilen. Die Bandbreite spielt dann keine Rolle mehr, und man hat genauso die Möglichkeit, Softwarebausteine separat zu aktualisieren. Eventuell durch Verteilung auf verschiedene Rechner auftretende Performance-Probleme sind damit aus der Welt.
CW: Empfehlen Sie, R/3 eher auf einem einzigen System zu fahren?
Tolkmit: Wir analysieren die IT-Landschaft bei unseren Kunden sehr genau und beraten sie dahingehend, was und wie Anwendungen sinnvoll auf Rechner zu verteilen sind. Wenn man es nicht unbedingt muß, vermeidet man es.
CW: Seit kurzem sind nun R/3-Anwendungen für IBMs OS/390-Mainframes verfügbar (siehe CW 18/99, Seite 13). Als Datenbank-Server ist der Großrechner schon länger verfügbar. Jahrelang sah die SAP keine Notwendigkeit, diese Plattform anzubieten. Ist der im Zuge des Internet-Computings forcierte Rezentralisierungsgedanke von Rechnerfarmen ausschlaggebend für diesen Schritt?
Tolkmit: Es gab immer wieder Anfragen von OS/390-Awendern. Doch ist es mit der Portierung der Programme allein nicht getan. Sie ist zwar aufwendig, aber überschaubar. Der größte Kostenblock entsteht im laufenden Betrieb. Wir müssen permanent Service und Support vorhalten, die Außendiensttechniker müssen vorhanden und ausgebildet sein - das ist der erheblichere Kostenfaktor. Diesen hohen Aufwand kann man natürlich nicht auf eine verhältnismäßig geringe Zahl von Kunden verteilen, denn dann hat man keine marktüblichen Preise mehr.
CW: Aber nun scheint es sich auf einmal doch zu lohnen. Wieviel Geschäft versprechen Sie sich von dem OS/390-Angebot?
Tolkmit: Die Kostenseite haben wir analysiert. Die Einnahmen betreffend, halten wir es mit dem "Kaiser": "Schaun wir mal, dann sehn wir''s schon." Große Erwartungen haben wir allerdings nicht - der Gesamtkuchen der SAP wird dadurch nicht viel größer.
CW: Warum dieser Wandel?
Tolkmit: Wir haben sehr lange gezögert, das stimmt. Die Nachfrage kommt aus zwei Richtungen: Zum einen schätzen die Kunden die hohe Verfügbarkeit und Stabilität der IBM-Systeme. Zum anderen möchten IT-Shops ihre Investitionen schützen, also ihr Mainframe-Know-how behalten und keine neue Plattform ins Haus holen.
CW: Welche neuen Plattformen nehmen Sie ins Programm?
Tolkmit: Wir bieten mit IBM gemeinsam DB/2 für Solaris an und werden künftig wieder Adabas D als Datenbank für R/3 aktiv vermarkten. Im Oktober 1997 hatten wir ja bereits die Verantwortung für die Weiterentwicklung und Pflege von Adabas D im R/3-Umfeld von der Software AG übernommen.
CW: Vor wenigen Wochen haben Sie R/3 auf Linux vorgestellt. Damit bieten Sie eine günstige Betriebssystem-Alternative zu Microsofts Windows NT. Jetzt wollen Sie Adabas D wieder verkaufen, das Ihnen gehört und zu einem sehr günstigen Preis ins Rennen geschickt werden könnte. Sind die beiden Ankündigungen als Warnschuß in Richtung Microsoft und Oracle zu verstehen? Schließlich basieren rund 70 Prozent der R/3-Installationen auf dieser Datenbank, und die Ellison-Company ist im Applikationsgeschäft einer Ihrer schärfsten Konkurrenten.
Tolkmit: Auf Oracle achten wir sehr.
CW: Neukunden, hieß es damals, sollten auf Basis von Adabas D nicht gewonnen werden. Was hat Sie zu dem Sinneswandel bewogen?
Tolkmit: Wir haben mit über 600 Installationen eine sehr breite Basis, und die Pflege wurde ohnehin von uns gewährleistet. Zudem ist Adabas D ein gutes Produkt. Aber auch hier wollen wir sehen, wie sich der Markt entwickelt, schließlich sind wir kein Datenbankanbieter.