JANSSEN: Mich irritiert häufig, wie IT-Anbieter mit dem Markt kommunizieren. Als Nicholas Carr seinerzeit behauptete, IT spiele keine Rolle, haben alle Hersteller aufgeschrieen. 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. Könnten wir da nicht vielleicht doch etwas mehr an einem Strang ziehen?
Foto: Joachim Wendler
KAGERMANN: Die IT ist immer noch eine junge und sehr wettbewerbsintensive Industrie. Sie wird stark aus dem Silicon Valley getrieben, und dort herrschen ganz eigene Gesetze. Jeder würde gern Google oder Microsoft nachahmen. Von daher geistert immer noch die Idee einer Killerapplikation durch die Köpfe. Da wird dann oft einiges überspitzt dargestellt. Und das ist nicht gut. Wir sind vergleichsweise zurückhaltend, aber 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 (siehe auch: "Ohne Change-Management kein SCM-Erfolg"). 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. Dass man Teile des Wertschöpfungsprozesses auslagern kann, ist dabei selbstverständlich.
Carr hat die Anbieter zu ernst genommen
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.
Wenn die Lieferanten über Bande spielen
JANSSEN: Nein, denn wir leben in der realen Welt. Wir sind ja durchaus bereit, im Outtasking beliebige Teile der IT wegzugebe (siehe auch "Sourcing-Modelle im Überblick"). Dummerweise kommt genauso viel, wie wir hinten konsolidiert und standardisiert herausgeben, 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 und diese Kontrolle leichter fällt. 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: Man muss da wohl zwei Bereiche unterscheiden. Bei den CEOs ist das Interesse meist ganz einfach gelagert. Die Gespräche laufen 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.
Foto: Joachim Wendler
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. Die anderen sind eher daran interessiert, dass die Dinge in ihrem Haus doch ein bisschen verschieden sind von den Dingen anderswo.
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, also beispielsweise der Chief Procurement Officer, der CFO oder der Marketing-Chef. Und das ist ein wirklich interessantes Phänomen. 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 will das SAP-Produkt. Er hat uns als Lieferanten ausgewählt, er weiß, dass die Software ins Umfeld passt und er eine verlässliche Applikation erhält. Aber warum haben dann die anderen so gut gegen uns verkauft? Weil sie nicht den CIO, sondern den CFO ansprechen - 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 der CFO wird überhaupt nichts dabei finden. Die Fehleranfälligkeit des Systems steigt keineswegs, wenn er die Regeln für die Konsolidierungssoftware definiert. Für mich ergibt sich daraus die Konsequenz, dass es nicht trivial sein wird, die Vorteile beider Produkte zusammenzuwerfen, denn man kann nicht beiden Herren dienen.
Fusionen erzeugen beim Anwender Friktionen
JANSSEN (mit mildem Sarkasmus): Ja, ja, und wir haben das SAP-Produkt SEM (siehe auch "SAP drängt in die Finanzabteilungen"), aber der CFO macht trotzdem das Customizing. Doch wo wir gerade beim Thema Akquisitionen sind: Die aktuellen Konsolidierungen im Softwaremarkt machen mir schon Sorgen. Für uns stellt sich das so dar: 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 eigentlich entschieden hatte, durch die Hintertür herein. Das verursacht Friktionen in der Strategiediskussion, die weit jenseits des Gewohnten liegen (siehe auch: "SAP will viele Produkte für BI ausmustern")
KAGERMANN: Im Prinzip gebe ich Ihnen Recht. Aber andere Marktteilnehmer betreiben das sehr viel intensiver als wir. Wir werden Produkte, die wir hoch integriert haben, nicht vom Markt nehmen. Natürlich werden wir versuchen, nach vier oder fünf Jahren auf ein gemeinsames Produkt zu kommen. Mein Punkt war: Ist eigentlich das Cartesis-Produkt in der Lage, die schwierigste Sache, die das SEM kann, beispielsweise die Kapitalkonsolidierung in Japan, ebenfalls abzubilden? Diesen Auftrag habe ich an die Entwickler weitergegeben. Auf diese Weise werden wir sehen, wie man sich annähern kann. Aber wir werden unseren Kunden nicht plötzlich ein anderes Produkt vorsetzen. Wir wissen, wie viel Arbeit das macht. Solche in 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.
KAGERMANN: Ja, da haben Sie Recht. Hinzu kommt, dass die Spezialisten oft am CIO vorbei in die Fachabteilungen hinein verkaufen. Wir kommen hingegen über die Architektur. Schon von daher müssen wir auch über den CIO gehen, unsere Beziehung mit den Unternehmen ist eine Ebene höher angelegt. Allerdings werden wir künftig auch versuchen, den anderen Zugang zum Markt zu nutzen. Nach der Akquisition von Business Objects haben wir jetzt 20 000 Kunden, die sich zumindest im BI-Bereich aus einem bestimmten Grund gegen SAP entschieden haben. Wir werden also erstmals mit einer eigenen Vertriebsmannschaft an Kunden herantreten, die nicht überall SAP haben wollen. Und denen werden wir auch keine SAP-Technik unterjubeln. Auf der anderen Seite haben wir eine ganze Menge Kunden, die eine integrierte Lösung bevorzugen. Das wird auf Dauer sicher sogar das größere Geschäft sein. Und diese Kunden sagen sich: Wenn ich schon alles aus einer Hand bekomme, will ich auch einen Vorteil davon haben. Diese Kunden bedienen wir mit dem gewohnten SAP-Vertrieb, der dann nach Bedarf die Produktspezialisten aus dem anderen Team einbezieht - aber unter seiner Steuerung.
Die Hauptherausforderung für uns liegt allerdings darin, eine Produktarchitektur zu entwickeln, die zweierlei ermöglicht: die beste vertikal integrierte Anwendung und gleichzeitig eine agnostische Lösung, die auf jedem transaktionalen System gefahren werden kann. (Leicht ironisch) Damit werden wir noch eine Menge Spaß haben.
Wo bleiben die Plattformen zur Kooperation?
JANSSEN (nachdenklich): Nicht nur die SAP, sondern alle Anbieter mit einem breiten Produktangebot haben - Knowledge-Management hin oder her - das Problem, die Spezialisten genau dahin zu bringen, wo sie gebraucht werden. An dieser Stelle sind die Nischenanbieter einfach noch besser. Wir haben weltweit auch irgendwo Cognos (mittlerweile von IBM übernommen) im Einsatz. Aber im Großen und Ganzen nutzen wir fast ausschließlich SAP-Produkte. 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. Wir sind hier - mit Hilfe von SAP-Software und Eigenentwicklungen - sehr weit gekommen. 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 nicht mehr nur Unternehmen integriert, sondern geschäftsmodellübergreifende Plattformen geschaffen werden, auf denen ganze Ketten von Unternehmen zusammenarbeiten können. Wie stellt sich SAP dieser Herausforderung?
SOA wurde zu früh ein Hype - mit fatalen Folgen
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. Jetzt wissen wir, dass wir dafür andere Mechanismen benötigen. Immerhin war dies der Anstoß dafür, dass wir über den Manufacturing-Bereich hinaus in andere Branchen gegangen sind. Wir haben intern erbittert darüber diskutiert. Und mein Hauptargument war, dass sich Geschäftsmodelle verändern können. Die Unternehmen wollen plötzlich vielleicht Teilprozesse aus einer artfremden Branche verwenden. Zudem gibt es in den unterschiedlichen Branchen eine Menge gleicher Bestandteile. Wir hatten anfangs 15 getrennte SAP-R/3-Brachenlösungen. Um wieder eine übergreifende Lösung zu bekommen, mussten wir diese 15 Lösungen in einem ziemlichen Kraftakt zusammenbringen. Das gelang uns mit Hilfe von SOA. Allerdings muss diese Struktur jetzt auch mit ausreichend Services bestückt werden, damit das kein Schweizer Käse wird, sondern die Kunden irgendwann auch in einem heterogenen Umfeld nahtlose Verbindungen knüpfen können. 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. Ich sehe für uns einen Vorteil darin, auf beiden Feldern zu spielen: zum einen eine Architektur anzubieten und zum anderen die Services zu erstellen. Wir sind nämlich noch nicht so weit, dass wir wirklich entkoppelte Services verbinden können. Aber - ohne jetzt falsche Versprechungen machen zu wollen - 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 wissen Sie, und da sind wir wieder beim Thema Marketing-Kommunikation, SOA ist auch so ein Fall, wo eine Idee zu früh gehypt wurde, nämlich schon, als sie noch nicht mehr als 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?
Foto: Joachim Wendler
KAGERMANN: Sie können solche Ideen leider nicht im Labor einsperren. Wir haben SOA nicht erfunden, sondern das ist ein Trend, wie beispielsweise Client-Server einer war. Und wer hier zu spät kommt, den bestraft das Leben. Ein Thema, das wir selbst in der Hand hatten, ist SAP Business ByDesign. Da mussten wir uns tatsächlich fragen, wann wir damit an den Markt herantreten sollten. 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, oder wie viele unterschiedliche Drucker es im Mittelstand gibt. In dieses schmutzige tägliche Leben müssen wir die Research-Abteilung irgendwann hineinjagen. Deshalb können wir neue Konzepte nicht so lange 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.
Niemand kennt die Pflichten von Softwarearchitekten
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 schon vor gut 40 Jahren geprägt wurde, gibt es in unserer Profession bis heute kein echtes Bemühen um Qualitätssicherung. In der Lebensversicherung darf beispielsweise kein Produkt verkauft werden, für das es keinen zertifizierten Aktuar gibt. Dieser Aktuar prüft alle rechtlichen und wirtschaftlichen Bedingungen des Produkts und berichtet direkt an den Vorstand. Im Software-Engineering - ob bei der SAP, bei einem Dienstleister oder bei uns - gibt es viele Architekten, aber niemand weiß, welche Rechte und Pflichten sie haben. Ein Statiker darf sagen: So wird das nicht gebaut! In unserer Branche erkenne ich nicht einmal die Bereitschaft, sich ernsthaft mit diesen Gedanken auseinanderzusetzen. (Zum Thema siehe auch: "Software-Blutbild zur Qualitätssteuerung".)
KAGERMANN: Jetzt muss ich aber doch mal zur Ehrenrettung unseres Berufsstandes schreiten. Ich sehe immer wieder, dass ein großer Softwarehersteller 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. Wenn man diese Prozesse nicht top-down vorlebt und laufend hinterher ist, fangen die Künstler wieder an, sich selbst zu verwirklichen.
Termintreue ist wichtiger als Softwarequalität
JANSSEN: Ich will Ihnen gern zugestehen, dass SAP hier besser ist als viele Unternehmen, die nach dem Industriestandard entwickeln. 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 auch bei großen und komplexen Projekten häufig zu sehr auf den Termin. Das liegt wohl daran, dass der Termin das ist, worauf der Vorstand vor allem schaut. Manchmal spielen auch vertragsrechtliche Aspekte dabei eine Rolle. Das gilt sogar, wenn die Wahrscheinlichkeit bei über 50 Prozent liegt, dass das Projekt wegen bestimmter Versäumnisse scheitert. Bei großen Projekten muss man einfach einen Volumentest machen, bei einer Mission-critical-Anwendung ist schon mal ein ganz trivialer Praxistest notwendig - ausprobieren, was passiert, wenn jemand aus Versehen einen Stecker zieht. Aber so etwas ist aus Zeitgründen oft nicht vorgesehen. Manche Abteilungen überschätzen ihre Fähigkeiten da wohl auch.
JANSSEN: Aber die Frage, die mich beschäftigt, lautet: Bemühen wir uns als Industrie eigentlich, dahin zu kommen, wo die Ingenieurwissenschaften heute schon stehen?
KAGERMANN: Ich denke, ja. Es dauert ein wenig, und die Produktivität in der Software ist deutlich niedriger als in der Hardware, aber das Bewusstsein ist auf alle Fälle geweckt. In den vergangenen Jahren haben wir uns zumindest bei der SAP in dieser Hinsicht erheblich verbessert.
JANSSEN: Bei der Prozesstreue gelten ja die Inder mittlerweile als Leuchtturm der Branche (siehe auch: "Prozessgüte heißt Wettbewerbsvorteil"). Sind sie wirklich besser?
KAGERMANN: Früher glaubte man, dort würde schlechter entwickelt als hier. Doch das ist trügerisch. Was aus Indien kommt, ist gut, und man bekommt es preiswerter. 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 dann die netten Dinge hinein, die alle begeistern. Aber auch da geht es nicht nur um Schönheit, sondern um einheitliche UI-Standards.
Rechnungswesen fällt nicht unter Lifestyle ...
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, dass sie eben keine Computer-Hacker des MIT Software Science Department beschäftigte. Und ich fürchtete, dass diese Entwicklungskultur im Silicon Valley den Bach hinunter würde. 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. Und wenn man Weltklassesoftware entwickeln will, muss man diese Ressourcen anzapfen; man kann ja nicht nur das Know-how der weltweiten Kunden nutzen. 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 das allein nicht reicht. Ein über-engineertes Produkt ohne Appeal verkauft sich eben nicht.
... aber an Web 2.0 kommt auch die SAP nicht vorbei
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.
Auf der anderen Seite wurde ich kürzlich gefragt, wie ich mir meinen Job im Jahre 2014 vorstelle. Und meiner Ansicht nach wird der gar nicht so viel anders sein als heute. Wahrscheinlich (lacht) mache ich gerade den Windows-2014-Rollout. Was mich künftig beschäftigen wird, ist wohl vor allem die firmenübergreifende Vernetzung. Welche Neuerungen sehen Sie schwerpunktmäßig auf sich zukommen?
KAGERMANN: Selbstverständlich beschäftigt uns das Thema Web 2.0 ebenfalls. Ich sehe das auch unter dem Vorzeichen des War for Talents. Wir haben nicht genug junge High Potentials in der IT-Branche. Und wer sie hat, versucht, sie zu halten. Wenn dann 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. Ich stimme Ihnen insofern zu, als es aus meiner Sicht momentan keine Technik gibt, die die IT in den kommenden sechs Jahren fundamental verändern wird. Es gibt vielleicht solche Quantensprünge, beispielsweise den extremen Parallelismus in den Rechnerarchitekturen, aber ich weiß nicht, ob es 2014 schon Anwendungen dafür geben wird. Ich stelle mir vor, dass man damit beispielsweise eine Realtime-Produktionsoptimierung machen könnte. Die Frage ist, ob man das braucht. Aber damit verhält es sich wohl wie mit Video übers Handy: Ist es State of the Art, wird es genutzt.
Compliance ist für die OSS-Community langweilig
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. Was meinen Sie? Wird sich Open Source über den jetzt abgedeckten Bereich hinaus entwickeln? Oder ist so etwas für die OSS-Szene vielleicht zu langweilig?
KAGERMANN: Letzteres. Ein Grund dafür ist die schlechte Spezifizierbarkeit der Anwendungen im Business-Bereich. 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 (siehe auch: "Compliance kommt von kompliziert"). 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. Aber es könnte durchaus einzelne Anwendungsbausteine geben, die eher auf der maschinennahen Ebene angesiedelt sind und als OSS ausgeliefert werden. Aufgrund der Patente und Lizenzbestimmungen ist es für einen Standardsoftwareanbieter allerdings schwierig, solche Bausteine einzubetten. Sonst käme man vielleicht zu einer Art Halb-Community, bei der der Softwareanbieter für die quelloffene Software Support leistet. Vielleicht ändern sich irgendwann die Bedingungen. Wir haben übrigens einen Prozess etabliert, in dessen Rahmen jedes Stück OSS, das wir - nach einer Fusion oder ähnlichem - in unseren Produkten finden, auf sein Risikopotenzial hin überprüft wird. Und wenn das Risiko zu hoch ist, fliegt es raus.
Wir ordnen unsere Arbeit der E-Mail-Kultur unter
JANSSEN: Ein weiteres Zukunftsthema, das ich gern anschneiden würde, ist die Kommunikationsflut. Ich habe das Gefühl, dass uns die modernen Kommunikationsmittel - Handy, Blackberry etc. - nicht mehr unterstützen, sondern zunehmend versklaven. Haben Sie Hoffnung, dass wir irgendwann lernen, sinnvoller mit dem Zeug umzugehen?
KAGERMANN: Vielfach ordnen wir unsere Arbeitsweise tatsächlich der E-Mail-Kultur unter und geben dabei das Denken auf. Da könnten sich ein paar Dinge verbessern. Zumindest kann man die Kommunikation sinnvoll strukturieren. Beispielsweise findet der Anwender von SAP Business ByDesign morgens eine In-Box vor, in der alle geschäftlichen Aufgaben, die ihn betreffen, zusammengefasst wurden. Das geht in die richtige Richtung.
JANSSEN: Und dann habe ich noch eine allerletzte Frage: Was wünscht sich eigentlich der Softwarelieferant vom CIO?
Foto: Joachim Wendler
KAGERMANN: Ohne die CIOs wären wir nicht, was wir sind. SAP wurde immer auch von den CIOs gepusht. Und wir fahren gut damit, über den CIO in die Unternehmen zu gehen. 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. Wir sehen unsere Aufgabe auch darin, gemeinsam mit dem CIO die Transformation seiner Rolle voranzutreiben. Denn das SOA-Thema wird möglicherweise auch eine organisatorische Trennung mit sich bringen: zwischen den Verantwortlichkeiten für die Infrastruktur und dem Betrieb der Service-Maschinerie.
JANSSEN: Wir sehen eigentlich sogar eine Dreiteilung: Infrastruktur, Applikationsschicht und Business-Architektur.
KAGERMANN: Technisch sind diese Bereiche ja bereits entkoppelt, warum sollen sie es nicht auch organisatorisch sein?
JANSSEN: Auf jeden Fall sollten aus meiner Sicht die eigentliche Dienstleistung und die Governance getrennt sein. Das erhöht die Glaubwürdigkeit gegenüber den Fachbereichen enorm.