JANSSEN: Mich irritiert häufig, wie IT-Anbieter mit dem Markt kommunizieren. Als Nicholas Carr seinerzeit behauptete, IT spiele keine Rolle, haben alle Hersteller aufgeschrien. Aber in ihrer Werbung verbreiten sie eine ganz ähnliche Botschaft: Demnach ist in der IT alles ganz einfach. Und wenn es dann doch ein bisschen komplizierter ist und Geld kostet, glauben Geschäftsführung und Endanwender doch, der CIO wäre bloß zu dumm dazu.

KAGERMANN: Die IT ist immer noch eine junge und sehr wettbewerbsintensive Industrie. Da wird dann oft einiges überspitzt dargestellt. Und das ist nicht gut. Wir können uns da nicht ganz von den anderen absetzen. Natürlich ist es immer schwierig, wenn der Anbieter mit jemand anderem als dem CIO zu tun hat. Aber ich werde oft direkt von den CEOs angesprochen und empfinde das als hilfreich. Die Vorstände stellen wichtige Fragen, die wenig mit Technologie zu tun haben: Wie schwierig ist das Projekt? Ist unsere Firma intern richtig aufgestellt dafür? Da halten wir dann auch nicht hinter dem Berg. Ich mache dem CEO klar, dass er voll hinter dem Projekt stehen muss, dass es nicht reicht, nur eine Rede zu halten, und dass ein mehrjähriges Change-Management notwendig sein wird. Aber so etwas kann man nicht in der Werbung sagen.

Und zu Carr möchte ich Folgendes anmerken: Mich hat sein Buch ziemlich schockiert, vor allem sein Vergleich mit der Elektrizität. Ich halte dem entgegen: IT ist strategisch, und Strategie kommt nicht aus der Steckdose.

JANSSEN (brummig): Ich finde es schlicht erschreckend, dass man mit solch einem Buch auf der Bestseller-Liste der Management-Literatur landen kann.

KAGERMANN: Nun ja, das Buch greift eine Grundidee auf, in der ein Körnchen Wahrheit steckt: Warum soll ich mich mit all dem belasten, wenn doch das meiste schon da ist - Internet, Services, Architektur? Ich brauche mir das doch bloß zu nehmen und es zusammenzustöpseln.

JANSSEN: Carrs Problem ist, dass er offenbar die Werbung der IT-Hersteller geglaubt hat. (Beide lachen herzhaft.)

KAGERMANN: So einfach geht das selbstverständlich nicht.

JANSSEN: Nein, denn wir leben in der realen Welt. Wir sind ja durchaus bereit, im Outtasking beliebige Teile der IT wegzugeben. Dummerweise kommt genauso viel, wie wir hinten konsolidiert und standardisiert hinausgeben, vorn in Form neuer Technologien, Werkzeuge und Anforderungen wieder herein, was zusätzliche Komplexität mit sich bringt. Langweilig wird uns auf diese Weise jedenfalls nicht.

Aber worauf ich hinauswollte: Die Anforderungen der Fachbereiche sind ja manchmal durchaus andere als die des CIO. Und wenn sich die Anbieter nicht an die Spielregeln halten, ist die Kommunikation schwierig zu steuern. Mit der SAP pflegen wir glücklicherweise eine Partnerschaft, in der das von beiden Seiten verstanden wird. Aber es gibt auch Lieferanten, die versuchen, über Bande zu spielen und dem Fachbereich etwas zu verkaufen, von dem der CIO genau weiß, dass es nicht in die Landschaft passt.

KAGERMANN: Bei den CEOs laufen die Gespräche oft nach folgendem Muster ab: Wir sind doch gar nicht so viel anders als die anderen. Meine großen Konkurrenten haben doch auch SAP im Einsatz. Warum machen wir nicht dasselbe wie die? Warum machen es sich unsere Leute so schwer? Wir könnten das doch alles viel billiger und schneller und mit weniger Risiko haben. Das stimmt ja auch bis zu einem gewissen Grad. Aber der CIO merkt ziemlich schnell, woran es hapert. Und dann kommen die Begehrlichkeiten der Fachbereiche ins Spiel.

JANSSEN: Sich von anderen zu unterscheiden ist doch ein berechtigtes Grundinteresse im Unternehmen. Die Einzigen, die vollständige Gleichheit und Transparenz wollen, sind der CEO und der CFO.

KAGERMANN: Es gibt Unternehmen, in denen der CIO die IT-Entscheidungen sehr stark dominiert. In anderen Firmen haben die C-Level-Manager der Fachbereiche das Sagen. Im Rahmen der Akquisition des Spezialanbieters Cartesis habe ich mal überlegt, warum sich eigentlich die Konsolidierungsanwendung von SAP anders verkauft als die von Cartesis. Weil sie unterschiedliche Käuferschichten ansprechen! Der CIO hat uns als Lieferanten ausgewählt, er weiß, dass die Software ins Umfeld passt und er eine verlässliche Applikation erhält. Aber die anderen haben nicht den CIO, sondern den CFO angesprochen - mit dem Argument: Du brauchst die IT gar nicht, du machst doch deine Regeln selbst. Mir ist es da zunächst auch kalt den Rücken hinuntergelaufen. Aber die Fehleranfälligkeit des Systems steigt keineswegs, wenn der CFO die Regeln für die Konsolidierungssoftware definiert.

JANSSEN (mit mildem Sarkasmus): Ja, ja, und wir haben das SAP-Produkt SEM, aber der CFO macht trotzdem das Customizing. Doch wo wir gerade beim Thema Akquisitionen sind: Die aktuellen Konsolidierungen im Softwaremarkt machen mir Sorgen. Man hat beispielsweise im Bereich Business Intelligence einen starken, strategischen Partner und sein Angebot gewählt, aber plötzlich bekommt man das, wogegen man sich entschieden hatte, durch die Hintertür herein. Das verursacht Friktionen in der Strategiediskussion, die weit jenseits des Gewohnten liegen.

KAGERMANN: Im Prinzip gebe ich Ihnen Recht. Aber andere Marktteilnehmer betreiben das sehr viel intensiver als wir. Natürlich werden wir versuchen, nach vier oder fünf Jahren auf ein gemeinsames Produkt zu kommen. Aber wir werden unseren Kunden nicht plötzlich ein anderes Produkt vorsetzen. Wir wissen, wie viel Arbeit das macht. Solch ein Wechsel betrifft ja nicht nur das Produkt, sondern auch die ganzen Regeln, die Zertifizierung, das Einverständnis von CFO und Tochtergesellschaften.

JANSSEN: Aus unserer Erfahrung besteht der Unterschied zwischen SAP und anderen Lieferanten nicht in der schnuckeligeren Software, sondern im Überblick, den der SAP-Vertrieb über den ganzen Bauplan hat. Ein Vertriebler von Hyperion, Business Objects oder einem anderen Spezialanbieter hat dagegen den Vorteil, viel mehr über sein Produkt zu wissen. Um dagegenzuhalten, muss die SAP immer die richtigen Fachleute an den richtigen Ort bringen. Das ist sicher alles andere als leicht.

An dieser Stelle sind die Nischenanbieter einfach noch besser. Wenn man sich einmal dafür entscheidet, SAP einzusetzen, kommen ja manche Dinge einfach mit ins Haus. Dann müssen Sie halt für bestimmte Funktionen auch das SAP Business Warehouse und SAP Portal einsetzen. Man fragt sich dann immer wieder, warum die Anwender eigentlich noch einmal eine Tool-Auswahlstudie machen wollen. Sie könnten doch einfach das nehmen, was im Haus ist. Denn sooo wichtig ist das Tool selbst nun auch wieder nicht - im Gegensatz zu den Integrationskosten für einen Flickerlteppich.

In den vergangenen Jahren hat sich die Münchener Rück intensiv mit der weltweiten Integration des Berichtswesens, des Underwriting etc. beschäftigt. Aber an den Grenzen fasert unser Geschäft mittlerweile ein wenig aus. Wir stoßen immer weiter in Bereiche vor, die nicht mehr zum klassischen Rückversicherungsgeschäft gehören. Hier müssen geschäftsmodellübergreifende Plattformen geschaffen werden, auf denen ganze Ketten von Unternehmen zusammenarbeiten können. Wie stellt sich SAP dieser Herausforderung?

KAGERMANN: Eigentlich haben wir diese Herausforderung schon vor zehn Jahren aufgegriffen. Damals haben wir mit der Hochschule St. Gallen das Thema Business-Networking lanciert. Aber wir waren zu früh dran. Außerdem war SAP R/3 nicht die richtige Plattform dafür. Immerhin war dies der Anstoß dafür, dass wir über den Manufacturing-Bereich hinaus in andere Branchen gegangen sind. Wir hatten anfangs 15 getrennte SAP-R/3-Brachenlösungen. Wieder eine übergreifende Lösung zu bekommen, gelang uns mit Hilfe von SOA. Selbstverständlich stehen wir hier erst am Anfang, aber die Kunden nehmen uns diese Vision zumindest schon einmal ab - auch wenn bei den Referenzen immer noch der eine oder andere Service fehlt. In einigen Jahren werden Kunden wie die Münchener Rück Many-to-many-Beziehungen zu anderen Unternehmen aufbauen können, deren Teilnehmer sich quasi im Flug wechseln oder ergänzen lassen.

JANSSEN: Ich sage bei unseren Outtasking-Beziehungen auch immer: Momentan sind die Scheidungskosten einfach zu hoch.

KAGERMANN: Ja, Scheidung und Hochzeit müssen einfacher und billiger werden.

JANSSEN (lacht): Gut, es darf schon etwas kosten, aber es müssen ja nicht gerade alle Verwandten zu Besuch kommen. (Wieder ernst) Was die unternehmensübergreifenden Ketten angeht, so erwarte ich, dass wir die Fähigkeit dazu in den kommenden fünf Jahren entwickeln werden. Aber SOA ist auch so ein Fall, wo eine Idee zu früh gehypt wurde, nämlich schon, als sie noch eine Marketechture war. Und heute ist das Thema beinahe schon veraltet. Die Anbieter sollten sich fragen: Wie früh dürfen wir eine Idee kommunizieren, wenn wir sichergehen wollen, dass es keine Totgeburt wird?

KAGERMANN: Sie können solche Ideen leider nicht im Labor einsperren. Wir haben SOA nicht erfunden, sondern das ist ein Trend. Und wer hier zu spät kommt, den bestraft das Leben. Ein Thema, das wir selbst in der Hand hatten, ist SAP Business ByDesign. Ich denke, man muss in den Markt gehen, wenn man ihn braucht. Irgendwann müssen die Entwickler aus dem Labor herauskommen und sich die Hände beim Kunden schmutzig machen. Die eigentlichen Probleme entdecken sie nur blutig vor Ort. Wenn die Produktentwicklung abgeschlossen ist, muss man herausfinden, ob das Konzept bei der Kundschaft ankommt und wo die Software noch löchrig ist. In diesem Prozess ändern sich mitunter die Prioritäten. Im Labor hätten wir niemals herausgefunden, dass beim Betrieb über das Netz die Performance nachlässt oder dass die Leute nicht offenbaren wollen, welche Software sie auf ihren Laptops haben. In dieses schmutzige tägliche Leben müssen wir die Research-Abteilung hineinjagen. Deshalb können wir neue Konzepte nicht einschließen, bis sie fix und fertig sind.

JANSSEN: Die Formulierung "blutig beim Kunden" schmeckt mir überhaupt nicht.

KAGERMANN (lacht): Es sind unsere Leute, die bluten, nicht die der Kunden.

JANSSEN: Da bin ich aber beruhigt. Außerdem sind wir gern bereit, uns ab und zu als Partner für einen Forschungsprototypen zur Verfügung zu stellen. Doch Software-Engineering ist schon eine seltsame Disziplin. Obwohl der Begriff vor gut 40 Jahren geprägt wurde, gibt es in unserer Profession bis heute kein echtes Bemühen um Qualitätssicherung.

KAGERMANN: Jetzt muss ich aber doch mal zur Ehrenrettung unseres Berufsstandes schreiten. Ein großer Softwarehersteller muss ungleich mehr Aufwand treiben muss als ein kleiner. Das liegt vor allem an den Produktstandards. Wir haben etwa zwei Dutzend solcher Standards, die eingehalten werden müssen. Das macht uns schon das Leben schwer - auch unter betriebswirtschaftlichen Gesichtpunkten. Aber in einem haben Sie Recht: Wir haben eigentlich alle für die Qualitätssicherung notwendigen Prozesse definiert und etabliert, aber am Ende ist das immer eine Frage der Menschen.

JANSSEN: Außerdem muss man sich schon fragen: Sind nicht vielfach die Kunden selbst schuld? Am Ende des Tages zählt oft nur der Termin. Die Qualität ist leider das Erste, was hinten herunterfällt. Und wie Sie sicher wissen, wollen die Kunden trotzdem immer noch zusätzliche Features. Manche - wie die Münchener Rück - berechtigte, andere völlig überzogene (lacht).

KAGERMANN (stimmt ein): Und das dann noch auf den letzten Drücker! Aber tatsächlich achten die Teams häufig zu sehr auf den Termin. Das liegt wohl daran, dass der Termin das ist, worauf der Vorstand vor allem schaut.

JANSSEN: Bei der Prozesstreue gelten ja die Inder mittlerweile als Leuchtturm der Branche. Sind sie wirklich besser?

KAGERMANN: Früher glaubte man, dort würde schlechter entwickelt als hier. Doch das ist trügerisch. Das Offshoring ist schwierig, aber am Ende zahlt es sich aus. Einige Sachen können aber andere Leute besser. So machen wir die ganz tiefe Integration in Walldorf, und das User Interface entsteht in Palo Alto. Im Silicon Valley ist einfach mehr Sizzle. Da kommen die netten Dinge hinein, die alle begeistern.

JANSSEN: Als SAP vor einigen Jahren begann, auch in Palo Alto zu entwickeln, hat mir das, ehrlich gesagt, Sorgen bereitet. Ich hatte an der SAP vor allem das relativ ordentliche Engineering geschätzt. Und ich fürchtete, dass diese Entwicklungskultur im Silicon Valley den Bach hinunter- ginge. Aber das ist offenbar doch nicht passiert. Allerdings stelle ich es mir schwierig vor, die unterschiedlichen Communities zusammenzubringen.

KAGERMANN: Das ist tatsächlich nicht einfach. Aber wenn es gut läuft, ergibt sich daraus ein Mehrwert. Damit der Spagat gelingt, muss man jedoch eine Kultur des gegenseitigen Respekts schaffen. Sie dürfen um Himmels willen nicht den Fehler begehen, in Kategorien wie besser oder schlechter zu denken. Man muss ständig betonen, dass Engineering Excellence auch weiterhin in unseren Unternehmenswerten verankert ist. Andererseits muss man denen, die das längst verinnerlicht haben, klarmachen, dass sich ein über-engineertes Produkt ohne Appeal nicht verkauft.

JANSSEN: SAP steht nun mal weniger für Lifestyle, Rechnungswesen ist ja auch nicht wirklich fancy. Und als CIO habe ich eigentlich sowieso keine Lust auf all das Web-2.0-Zeug, das aus dem privaten Umfeld in die Unternehmen eingedrungen ist. Ich glaube auch nicht, dass das alles besonders effizient ist, sondern nur eine Möglichkeit, noch mehr Zeit zu verschwenden. Aber wir werden uns diesen Dingen öffnen müssen, weil wir unsere private Lebensweise schon darauf abgestimmt haben.

KAGERMANN: Ich sehe das Thema Web 2.0 auch unter dem Vorzeichen des War for Talents. Wir haben nicht genug junge High Potentials in der IT-Branche. Wenn ein neues Lebensgefühl aufkommt, können wir uns dem schon deshalb nicht verschließen. Also beschäftigen wir uns auch mit sozialen Netzen und anderen neuen Formen des Miteinander-Umgehens. Aber wir setzen diese Techniken nur dort ein, wo es sinnvoll ist, also die Produktivität oder das Teambuilding fördert.

JANSSEN: Was wird eigentlich aus Open Source werden? Es hat sich am Markt durchgesetzt, aber eigentlich nur bei technologienahen Themen, an denen der akademische Hacker Freude hat. Eine Open-Source-Software für das Rechnungswesen gibt es meines Wissens nicht. Wir selbst fangen allerdings gerade an, in einer Open-Source-Aktivität Risikomodelle für die Versicherungsindustrie zu entwickeln. Ist so etwas für die OSS-Szene vielleicht zu langweilig?

KAGERMANN: Technologische Probleme lassen sich mathematisch spezifizieren und deshalb leichter von losen Entwicklergemeinschaften bearbeiten. Der andere Grund ist der Zwang zur Anpassung, Lokalisierung und Erfüllung von Compliance-Anforderungen. Ich weiß nicht, ob eine freie Community auf Dauer die Lust dafür aufbringt. Die Leute kommen ja eher aus der kreativen Ecke. Und Compliance ist ein Bereich, der nicht einmal bei uns jedem Entwickler Spaß macht.

JANSSEN: Und dann habe ich noch eine allerletzte Frage: Was wünscht sich eigentlich der Softwarelieferant vom CIO?

KAGERMANN: Ohne die CIOs wären wir nicht, was wir sind. SAP wurde immer auch von den CIOs gepusht. Und wir fahren gut damit. Selbstverständlich beschäftige ich mich auch gern mit dem Business. Aber es ist schwer, sich mit dem Business auszutauschen, wenn dort gar kein IT-Verständnis herrscht. Deshalb bin ich immer froh, wenn ein starkes Gegengewicht auf der anderen Seite existiert.