SAP aus der Cloud - Tabakkonzern macht Dampf

Wie fast überall, so gingen auch bei British American Tobacco (BAT) Anfang des Jahrtausends die IT-Investitionen in den Keller. 2009 musste sich das Unternehmen eingestehen, dass die Infrastruktur im Prinzip veraltet war. "Man hatte über Jahre die Kosten gedrückt", erläutert Thorsten Broese, Group Head of IT Services. "Dabei ist die IT jetzt eigentlich als Enabler gefordert. Aber die Infrastruktur dafür ist nicht vorhanden." Glücklicherweise verstehe das Business inzwischen "mehr und mehr", dass Effizienzgewinne nur erzielbar sind, wenn flexible IT-Infrastrukturen dahinter stehen.

Auch das Komplexitätsargument sprach für eine Neugestaltung. In der Vergangenheit habe BAT rund 180 IT-Abteilungen mit etwa ebenso vielen unterschiedlichen Lösungen unterhalten, berichtet der weltweite IT-Service-Chef , dessen Schreibtisch in Kuala Lumpur steht. BAT habe "jede Datenbank und jede Programmiersprache im Einsatz gehabt, die man sich vorstellen kann". Insgesamt arbeitet der Tabakhersteller mit etwa 2.500 IT-Suppliern zusammen.

Ursprünglich 60 SAP-Instanzen

Aufräumen tat auch im Anwendungsbereich Not. Die ursprünglich 60 SAP-Instanzen waren vor vier Jahren bereits auf acht verringert worden. Doch die Marktsituation erfordert mittlerweile eine noch weiter gehende Konsolidierung "Wir wollen schnell in eine Above-Market-Organisation einsteigen", so Broese, "das heißt, die Business-Prozesse werden globalisiert, und dazu ist es nötig, ein Single Template im Hintergrund aufzusetzen, das in Deutschland gehostet wird."

Der Tabakhandel ist kein Geschäft wie jedes andere mehr. In den USA beispielsweise unterliegt er einer Reihe von legalen Beschränkungen. Deshalb war BAT daran gelegen, seine Kundendaten einem Land zu hosten, das größere Freiräume bietet. "Seit 1998 haben wir ein europäisches Rechenzentrum in Hamburg und Frankfurt; da gab es nie irgendwelche Probleme", sagt Broese.

Was gegen eine Public Cloud sprach

Mit dem Beschluss, die Anwendungen und Daten in Deutschland zu hosten, fiel auch die Entscheidung, die dafür notwendigen Ressourcen nicht selbst aufzubauen, sondern sie aus einer extern betriebenen "Private Cloud" zu beziehen. Auch eine Public Cloud wäre machbar gewesen, konstatiert Broese. - Wenn dafür nicht noch einige Voraussetzungen fehlten: "Unser Vertrag ist ein paar hundert Seiten lang. Da gibt es genügend Standards, die sich auf eine Private Cloud ganz gut adaptieren lassen. Aber die Public Cloud ist juristisch weitgehend unerschlossen Gebiet. Deshalb haben wir uns gesagt: Wir wollen nicht Millionen von Euro in einen Vertrag stecken, sondern lieber in technische Konzepte."

Hinsichtlich des Providers fiel die Wahl auf die T-Systems AG, mit der BAT schon Serviceerfahrungen gesammelt hatte und die darüber hinaus bereits einige Großunternehmen mit IT-Services aus der Cloud versorgte. "Ausgehend von unserem ersten wirklichen Großanwender Shell haben wir seit 2007 unsere Cloud-Lösung immer weiter verfeinert und stellen sie nun vielen Kunden zur Verfügung", sagt Ferri Abolhassan, Geschäftsführer bei T-Systems. Aus seiner Sicht handelt es sich bei der BAT-Lösung um eine hybride Cloud: Technisch gesehen sei es eine Public Cloud mit virtuellen Ressourcen. Der Zugriffsschutz wurde isoliert und damit privatisiert: "Das war dem Kunden wichtig."

Qualität ist ein wichtiges Kriterium:
Wo die IT-Verantwortlichen am Entscheidertisch sitzen, sollten sie sich nicht auf kleinliche Brot-und-Butter-Diskussionen einlassen. Entscheidend ist, dass das Business perfekt unterstützt wird. Das darf sogar manchmal etwas mehr kosten.

Eine reine Kostenfixierung führt zu Mehrkosten:
Wenn die Verträge zu eng gestrickt sind, lässt sich die Lösung nicht mehr dem Business anpassen. In diesem Fall verliert man deutlich mehr Geld durch länger dauernde Projekte und entgangenen Umsatz als durch Produkt- oder Projektkosten.

Die Anforderungen müssen technisch erfüllbar sein:
Es hat keinen Zweck, einen Anbieter zu Service-Levels zu zwingen, die er nicht erfüllen kann. Es sei denn, man legt es darauf an, Strafzahlungen zu kassieren. Aber das hat weniger mit IT-Strategie zu tun als mit Financial Engineering. Deshalb muss man einen Plan aufsetzen, der zwar ambitioniert, aber auch erfüllbar ist.

In den Vertrag muss Flexibilität eingearbeitet sein:
„Retrofit Improvements“ kosten unnötig Geld. Und sie lassen sich dadurch vermeiden, dass man es von Anfang an richtig macht. Wer heute ein Projekt plant, muss mit Veränderungen rechnen. Deshalb ist es wichtig, dass sich die Partner Spielräume erhalten.

Pönalen sind keine Lösung:
Man bekommt keinen Provider dazu, den vollen Verlust zu ersetzen. Bestenfalls gibt es Prozente vom Vertragsvolumen. Selbstverständlich gehören Service-Credits heute zu den Best Practices. Aber sie beeinflussen das Verhalten der Provider wenig. Und hat das „Ehepaar“ erst einmal ein Stadium erreicht hat, in dem es sich nur noch darüber unterhält, sollte es schleunigst den Scheidungsrichter aufsuchen. Dann ist die Partnerschaft nicht mehr zu retten.

Globale Verträge brauchen ihre Zeit:
Vom Request for Information bis zur Vertragsunterschrift hat es mehr oder weniger zwölf Monate gedauert. Während dieser Zeit bildete sich unweigerlich ein Rückstau. Die Terminnot , die sich daraus ergab, hat BAT abgefangen, indem beide Partner – im Wissen, dass sie sich grundsätzlich einig waren – den eigentlichen Vertragsabschluss nicht abwarteten, sondern schon mal mit der Arbeit begannen.

Innovationen erwachsen aus Sicherheit:
Die Chemie zwischen den handelnden Personen muss stimmen. Das heißt nicht, dass man sich das Leben gegenseitig allzu einfach macht. Aber Offenheit und Vertrauen sollten da sein. Ohne eine vertrauensvolle Zusammenarbeit kommt man nicht dazu, die Möglichkeiten der Partnerschaft wirklich auszuschöpfen und zu erweitern, weil man ständig mit dem Beseitigen von Problemen beschäftigt ist.

Nicht nur Peitsche, auch Zuckerbrot:
Die Unternehmensanwälte haben dem Konzern beigebracht, wie er sich gegen Misserfolge absichern kann. Aber genauso sinnvoll wäre es, ein System aufzusetzen, das beide Partner von Verbesserungen profitieren lässt. Vereinzelt gibt es bereits solche Shared-Risk/Shared-Gain-Konstrukte, sagt BATs IT-Service-Chef Broese, aber in der Regel seien sie doch noch sehr rudimentär.

German Cloud? - nicht unbedingt nötig!

Die Tatsache, dass T-Systems in Deutschland beheimatet ist, spielte nach Broeses Darstellung keine große Rolle. Der Begriff "German Cloud" sei zwar "im Kommen", aber im größten Teil der europäischen Union sei das Hosting ebenfalls problemlos möglich gewesen: "Für uns war einfach wichtig, dass die Rahmenbedingungen stimmen und dass sie sich in den kommenden Jahren auch nicht wesentlich ändern."

Im Vorfeld der Auslagerung hatte BAT bereits ein kleineres Projekt absolviert, in dessen Rahmen sich der Konzern über seine Data-Center-Strategie Klarheit verschafft hatte. "Das war eine Frage von Netzwerk-Latency, politischer Stabilität, Verfügbarkeit etc.", sagt Broese. Eine der Anforderung war: Der Provider sollte in der Lage sein, an allen drei Data-Center-Standorten, die letztlich übrig blieben, also in Frankfurt, Singapur und Brasilien, standardisierte Services zur Verfügung stellen können.

Argumente für eine Private Cloud

Das Thema Cloud sei von Anfang an auf der Agenda gewesen, also nicht erst durch T-Systems aufgebracht worden, so Broese. Allerdings habe BAT über Anbieter wie T-Systems, IBM und HP sowie diverse externe Berater im Vorfeld Ideen eingeholt: Was ist heute machbar? Was verfügbar? "So konnten wir mit einem dedizierten Anforderungsprofil in den RFI-Prozess einsteigen."

"Die Kosten waren schon ein Argument für die Cloud, aber nicht das entscheidende", beteuert Broese. Zwar habe BAT schon bei der Ausschreibung konkrete Zielvorstellungen hinsichtlich der Einsparungen gehabt. Aber das eigentliche Thema sei Flexibilität gewesen: "Traditionelle Lösungen haben eben einen hohen Anteil von Fixkosten, die wir mit der Cloud flexibilisieren können. Zudem ging es uns darum, die Business-Modelle flexibler sowie Mergers und Akquisitionen einfacher zu machen."

Hinzu kam, dass die IT nach herkömmlichem Muster zu langsam geworden war. "Die Zeiten, um neue Lösungen aufzusetzen, mussten einfach kürzer werden", räumt Broese ein: "Das waren die Möglichkeiten, die wir in einer standardisierten Umgebung gesehen haben. Und dass sie real sind, haben wir schon in den ersten Monaten des Projekts bewiesen bekommen."

Mehr als reines Hosting

Erfahrungen mit dem Outsourcing einzelner IT-Services hatte BAT vorher schon. T-System war einer der Provider; die Telekom-Tochter hostete BAT-Applikationen hauptsächlich im EMEA-Bereich, während HP diese Aufgabe in Brasilien, Kanada, Australien und Mexiko erfüllte.

Doch das Cloud-Konzept hebt das traditionelle Hosting laut Broese auf eine neue Stufe: Zum einen ermögliche es "Agilität auch für das Business - und das beim Hoch- wie beim Runterfahren der Kapazität", wie der IT-Service-Verantwortliche es formuliert. Zum anderen beschleunige es die IT-Prozesse beträchtlich: "Wir hatten vorher für gewöhnlich Vorlaufzeiten von 13 Wochen, bis wir eine Lösung aufgebaut hatten; jetzt sind wir auf vier Wochen runter. Wir können also wesentlich schneller auf die Anforderungen unseres Kunden reagieren."

Abolhassan beschreibt den Unterschied zum traditionellen Hosting folgendermaßen: "Früher hat der Kunde am Anfang der 13 Wochen Hardware und Software bestellt hat - und dann installierte das jemand. Heute haben wir in der Cloud vorher schon Farmen anlegen, also Kapazitäten vorgehalten, so dass wir quasi auf Knopfdruck , wir nennen das "Zero Touch Provisioning", dem Kunden ein Stück von diesem Weideland zuteilen. Daraus ergeben sich für ihn ganz andere Kosten, weil er keine Überkapazitäten mehr zahlen muss. Und er bekommt die Leistung schneller zur Verfügung gestellt, weil sie quasi präventiv angelegt ist."

"Wir haben uns unsere Systeme angeschaut und sehr viele Server gefunden, die nur zu 20 Prozent ausgelastet sind", bestätigt Broese: " Das ist Kapazität, die wir nicht nutzen. Wenn man konsolidiert und die Möglichkeiten der Cloud nutzt, zahlt man nur für das, was man tatsächlich nutzt."

Ohne Lifecycle-Management up to date

Und noch einen Vorteil der Cloud nennt Broese: "Früher haben wir das Lifecycle-Management auf unserer Seite gehabt. Wir haben einen Server bestellt und den Provider beauftragt, ihn zu betreiben, bis er abgeschrieben war; in der Zwischenzeit gab es unzählige Updates von Betriebssystemen, Datenbanken etc. Mit der Cloud-Lösung ist das Lifecycle-Management inclusive Patching Teil der Lösung. Darum müssen wir uns nicht mehr kümmern. Wir können eine Umgebung erwarten, die up to date ist und auf der wir unsere Lösungen aufsetzen."

Die an dieser Stelle häufig verwendete Analogie zum Strom aus der Steckdose ist allerdings auf einem Bein lahm. Man könnte sogar behaupten, dass es sich gar nicht um echtes Cloud-Computing handelt. Denn die Lizenzen für die Anwendungen, beispielsweise von SAP, Datenbank-Management-Systeme, also Oracle & Co., sowie Betriebssysteme wie Windows-Server, kauft BAT nach wie vor selbst. Teil des Angebots sind hingegen die Nutzungsgebühren für systemnahe Betriebs- und Management-Software wie VMware.

Gemessen und abgerechnet wird die bezogene Leitung im SAP-Umfeld über Enterprise Storage Units oder den "Saps"-Index (SAP Application Performance Standard). Für die Non-SAP-Systeme kommen Parameter wie virtuelle CPUs (definiert nach den Benchmarks des Transaction Processing Performance Council, kurz TPC) sowie virtueller RAM zum Zug.

Was für T-Systems sprach

Abolhassan fasst das Serviceverhältnis folgendermaßen zusammen: BAT ordert keine Server mehr, sondern Leistung. Bezahlt werden Verfügbarkeit und SLAs. Es gibt eine genaue Kapazitätsplanung mit einer rollierenden Vorschau. Und diese Kapazitäten müssen wir bereitstellen. Nur ist die Kapazität nicht mehr klassisch in CPUs oder Speicherplatz oder Boxen messbar, sondern in Transaktionen.

Wie Broese ergänzt, hat BAT ein "ausgeklügeltes" Reporting über SLAs und KPIs installiert: "Wir können monitoren, ob die vereinbarte Leistung vom Partner auch bereitgestellt wird."

Bei der Auswahl des Suppliers legte BAT neben dem Commitment zu den angepeilten Einsparungen auch Wert darauf, dass der designierte Partner bereits eine solide Cloud-Strategie entwickelt hatte: "Für uns war wichtig, nicht erst mit dem Anbieter eine Cloud zu entwickeln, sondern auf Standards aufzusetzen. Gerade im Umfeld von SAP war die Lösung von T-Systems die am meisten standardisierte."

Diese Professionalität des Anbieters spiegle sich beispielsweise in der kurzen Einführungszeit wieder, erläutert Broese: "Wir haben den Vertrag im Februar unterschrieben, und im Mai musste die Lösung übergeben werden - inclusive aller Tests, Prozesse und Dokumentationen. Der erste Markt soll im September dieses Jahres mit SAP aus der Cloud live gehen. Wenn man da erst mit dem Design einer Lösung angefangen hätte, wäre dieser aggressive Plan nicht zu verwirklichen gewesen."

Wer noch im Rennen war

Dabei hat sich BAT die Sache jedoch nicht allzu leicht gemacht. Wie Broese berichtet, begann die Auswahl mit sieben Suppliern, von denen am Ende T-Systems, HP, IBM und Fujitsu übrig blieben: "Die haben wir uns sehr genau auf ihre Referenzen und die Unterschiede der Lösungen angesehen."

Für T-Systems habe schließlich auch der "Cultural Fit" gesprochen, geht Broese ins Detail: " Wir wollten einen Partner, der genug Agilität und Flexibilität hat, um auch Weiterentwicklungen in der IT einzubeziehen, die wir uns heute noch nicht vorstellen können." Denn die Laufzeit des Vertrags ist auf insgesamt sieben Jahre angelegt: "Und in dieser Zeit wird sich die IT-Welt deutlich verändert haben."

Was BAT von T-Systems erwarten darf, weiß der Konzern inzwischen, denn er arbeitet schon seit einigen Jahren mit dem IT-Dienstleister zusammen. "Vor zwei oder drei Jahren hatten wir mal ein paar Probleme mit Systemverfügbarkeiten, aber seither gab es keine Major Incidents mehr", sagt Broese: "Die Qualität, die wir in den vergangenen zwei Jahren dort gesehen haben, ist die, die wir brauchen, um unsere Lösungen bereitstellen zu können."

Der aktuelle Stand des Projekts

Aus diesem Grund war es möglich, das Projekt auf der organisatorischen und technischen Seite bereits voranzutreiben, bevor die Rechtsanwälte die letzten Vertragsdetails ausgehandelt hatten. Denn die Zeit drängte. Für die Übergabe der Server sind zwei Jahre vorgesehen. "Wir wollen ja nicht nur SAP übergeben, sondern wir haben auch noch 1400 andere Server, die wir in die neue Welt hinüberführen müssen", erläutert Broese.

Derzeit werden die für SAP-Systeme üblichen User Acceptance Tests vorgenommen; bis September soll das Fine-Tuning abgeschlossen sein. Parallel laufen Training, Datenmigration etc. Einige Hundert Leute sind mit dem Aufsetzen der neuen SAP-Lösung beschäftigt.

"Wir beginnen jetzt, die ersten Server zu migrieren", berichtet Broese. Den Anfang mache Australien, wo das derzeit genutzte Gebäude mit 300 Servern praktischerweise verlassen werde. Gerade abgeschlossen ist die Integration der ersten Server aus dem Frankfurter Data Center in die neue Cloud-Umgebung. Auch in Brasilien ist BAT dabei, die Umgebung vom bisherigen Servicepartner HP auf T-Systems zu übertragen. Bis Ende 2014 soll die SAP-Lösung aus der Cloud voll in Betrieb sein.

Flexibilität in den Vertrag eingebaut

Wie Broese darlegt, erlaubt das Vertragswerk unterschiedliche Service-Levels: "Für die globale SAP-Lösung brauchen wir schließlich andere Verfügbarkeiten als für das Verwalten von E-Mail-Systemen."

Verfügbarkeit war laut Broese denn auch ein Grund dafür, warum BAT der Public Cloud den Vorzug gegenüber den Angeboten aus der Public Cloud gibt. 99,9 Prozent, wie sie beispielsweise für die unternehmenskritischen SAP-Systeme benötigt werden, seien dort noch nicht zu bekommen.

Der Vertrag mit T-Systems ist zudem darauf angelegt, dass BAT dieselbe Lösung mit denselben SLAs, KPIs und Prozessen nicht nur in Frankfurt, sondern auch in Singapur und Brasilien bekommt: "Die Gleichheit der Lösungen war uns sehr wichtig. Und wir wollten berechtigterweise darauf vertrauen, dass wir sie geliefert bekommen, obwohl die Lösungen aus unterschiedlichen Rechenzentren heraus angeboten werden", so der IT-Service-Chef: "Auf diese Weise spart man viel Aufwand, beispielsweise beim Testing."

Ohne Vertrauen ist Kontrolle nichts

Unter anderem wegen der hohen Anforderungen sei der Preis nicht das alleinseligmachende Argument gewesen "Wir haben in den vergangenen Jahren lernen müssen: Wenn man zu sehr nur auf den Preis schaut, zahlt man woanders Lehrgeld. Oft in der Form, dass Projekte länger brauchen."

Vertrauen ist für Broese die Grundlage einer derartigen Partnerschaft: "Sie können heute mit jedem Provider alle SLAs vereinbaren. Aber wenn Sie 99,9 Prozent vereinbaren und die Technik nur für 99,7 Prozent designt ist, dann ist der Rest schlicht eine Risikoversicherung." Deshalb seien die Techniker bei BAT Punkt für Punkt durch die Lösung gegangen und hätten sichergestellt, dass von den Datenbanken über die Schnittstellen bis zu den Netzen jede Komponente redundant ausgelegt sei.

"Diese Lösungen beruht auf dem Prinzip der Redundanz", bestätigt Abohassan aus der Perspektive des Dienstleisters: "Alles, was man sich vorstellen kann, sollte durch Redundanzen abgesichert sein - vom kompletten Rechenzentrum über die internen Komponenten jede RZ bis zu den Menschen. Jede Tätigkeit wird immer nach dem Vier-Augen-Prinzip erbracht. Und alles, was getan wird, folgt einem klaren Prozess. Wir wollen eine tatsächliche Verfügbarkeit von 99,9 Prozent erreichen, ohne über den Abschluss einer Versicherung die Folgen eines Ausfalls zu mildern. Wir investieren das Geld, das wir sonst in eine Versicherung stecken müssten, lieber in Technik, die den Ausfall verhindert."

Broese hat ebenfalls "kein Interesse" an Pönalen oder Service Credits. Das Management-Board habe derzeit großes Vertrauen in die IT, das diese auf gar keinen Fall enttäuschen wolle: "Wir haben in Projekte mit Gesamtkosten von mehreren 100 Millionen Euro investiert, und dieses Risiko geht unser Board nur ein, wenn es sicher sein kann, dass Infrastruktur und Systeme stabil laufen. Wenn das Tagesgeschäft nicht funktioniert, ist die Diskussion über einen Business Enabler IT schnell zurückgekehrt zur Frage, warum wir nicht einmal fähig sind, eMails von A nach B zu senden. Und dann sitzen wir nicht mehr am Tisch, wo die Entscheidungen getroffen werden."

Konsequente Provider-Strategie

Der Deal mit T-Systems ist Teil einer völlig überarbeiteten Provider-Strategie. Die ursprünglich 2500 IT-Lieferanten will BAT auf fünf "Core Strategic Suppliers" verringern, mit denen wirkliche Partnerschaften aufgebaut werden sollen. Dazu Broese: "Sicher haben auch wir Benchmark-Klauseln im Vertrag; jeder Lieferant muss sicherstellen, dass er wettbewerbsfähig ist. Auf der anderen Seite können und wollen wir nicht alle drei Jahren in einen RFP einsteigen, der ein Jahr in Anspruch nimmt und dann eventuell wieder zwei Jahre Transition nach sich zieht."

Neben dem Data-Center-Provider T-Systems hat BAT mit Wipro einen Partner für den Application Support ausgewählt. Im Servicedesk-Bereich fiel die Wahl auf Fujitsu. Remote Infrastructure Mangement macht HCL von Indien aus. Im Netzbereich läuft gerade eine Ausschreibung, die Ende dieses Quartals entschieden sein sollte. "Von allen Partnern erwarten wir auch eine intensive Zusammenarbeit untereinander", führt Broese aus.

Die kommenden beiden Jahre

Der Übergang in die Cloud wird bei BAT dadurch begünstigt, dass viele der vorhandenen Server ihr Lebensende ohnehin erreicht haben. Broese: "Wir hatten jahrelang nicht in Infrastruktur investiert, so dass manche Server fünf oder sechs Jahre alt sind. Den ohnehin notwendigen Hardware-Refresh verbinden wir gleich mit der Migration auf Cloud-Lösungen."

Der größte Teil der Migration wird nach Broeses Beschreibung also folgendermaßen vonstatten gehen: Der alte Server bleibt dort, wo er ist, man baut einen neuen in der Cloud auf, spielt dort die Anwendung auf, muss wegen der Tests die Systeme eine Zeitlang parallel betreiben und macht am Ende den Switch-over.

Abolhassan bestätigt das: "Das genau ist unser Ansatz. Wir ziehen keine Server um. Vielmehr ist der Server auf unserer Seite bereits angelegt. Nach unserem "Farming"-Konzept müssen wir Server und Kunden nicht mehr eins zu eins zuordnen. Und das ist genau der Punkt, wo der Kunde von den Größenvorteilen profitieren kann. "

Was bringt es wem?

"Dieses Modell rechnet sich auch für uns", sagt de T-Systems-Manager: " Es gibt uns - um im Bild der Farm zu bleiben - die Möglichkeit, Getreide einer bestimmten Sorte groß angelegt und hoch standardisiert anzubauen und an Kunden, die dafür Bedarf haben, zu vertreiben. Das ist immer sehr viel günstiger für uns als eine individuelle Lösung. Diesen Vorteil teilen wir uns mit dem Kunden."

Den Vertragswert beziffern die beiden Partner mit 160 Millionen Euro über sieben Jahre. Die Projektkosten gehen allerdings über dieses Volumen hinaus, weil ja noch Personalkosten und parallele Run-Kosten hinzukommen. Auch der Umstieg auf das einheitliche SAP-System ist hier noch nicht eingepreist.

Den Ertrag, den sich BAT davon erhofft, erläutert Broese folgendermaßen: "Selbstverständlich haben wir jetzt erst einmal relativ hohe Kosten durch die Migration der alten Systeme in die Cloud. Diese Kosten wollen wir nach der Transition-Phase, sprich: ab 2014, nicht nur wieder eingespielt haben, sondern darüber hinaus noch mindestens 20 Millionen über die gesamte Vertragslaufzeit sparen. Das ist möglich, weil wir von einem Fünftel weniger Hosting-Kosten ausgehen."

Naturgemäß erwartet BAT von T-Systems, dass der Dienstleister seine Effizienz von Jahr zu Jahr steigert. Die erwarteten Preissenkungen sind vertraglich festgelegt - allerdings auf der Basis der jetzt benötigten Volumina. Inwieweit sie steigen, lässt sich kaum vorhersagen. Laut Broese verzeichnete der Konzern in den vergangenen drei Jahren Voluminazuwächse von 40 bis 50 Prozent: "De facto werden wir also deutlich mehr sparen, als wir es im Business-Case berechnet haben", konstatiert der IT-Service-Verantwortliche.

Entwicklungen in der Zukunft

Tatsächlich sind sieben Jahre in der IT eine halbe Ewigkeit. Nicht nur die Technik, auch die geschäftlichen Anforderungen können sich in dieser Zeit enorm verändern. Ein Vertrag, der beide Seiten langfristig zufrieden stellen soll, muss das berücksichtigen. Broese sieht sich hier bestens abgesichert: "Wenn wir etwas Neues machen wollen, das höhere Kapazität erfordert, also beispielsweise eine erweiterte BI-Lösung, dann sagen wir der T-Systems: Wir brauchen in vier Wochen doppelte Kapazität. T-Systems muss dann intern sicherstellen, dass genügend CPU-Kerne und Speicherplatz bevorratet sind, um unsere drastische gestiegenen Anforderung zu erfüllen."

Und was ist, wenn das in der zur Verfügung stehenden Zeit technisch nicht möglich sein sollte? Für diesen Fall weist der Vertrag auch die Möglichkeit aus, dedizierte Server aufzusetzen - nach dem klassischen Hosting-Modell. "Das ist allerdings nicht unser Ziel", gibt Broese zu bedenken, "denn dann kommen wir wieder in die Diskussion um die Kapazitätsausnutzung und die Vorlaufzeiten hinein."

Ein Thema, dass der Vertrag derzeit noch nicht abdeckt, ist die Collaboration über Betriebsgrenzen hinweg. "Dann kommt möglicherweise auch die Public Cloud wieder ins Gespräch", sagt Broese. Aber auch dafür seien Lösungen aus den Bereichen Hybrid Cloud oder Public-Private Cloud denkbar - sofern die Verträge dahingehend erweitert werden, dass sie einen Zugriff von außen einschließen.

"Es gibt wenige Lösungen, die wir Farm-seitig nicht vorbereitete hätten", beteuert Abolhassan: "Sollte es aber tatsächlich Besonderheiten geben, die wir nicht vorhalten, machen wir quasi ein neues Beet auf, das wir klassisch bewirtschaften." Im Übrigen liege das Problem nicht in der Kapazität. "Die können wir im Grunde unendlich bereitstellen." Es liege vielmehr in der Art des Getreides. Kritisch werde es, wenn T-Systems für eine Art von Anwendung noch keinen Standardprozess habe. Mit dem Thema Collaboration beispielsweise werde die Ebene der Anwendungen verlassen , und ganz andere Prozesse und Geschäftsmodelle würden ein Thema. "Da sind gewichtigere Probleme zu lösen als die Frage des Hosting", bestätigt Broese.

COMPUTERWOCHE-Kommentar: Keine Wolke über der Farm

Was für ein hübsches Bild, das T-Systems-Geschäftsführer Ferry Abolhassan uns da aufmalt: "Unsere kleine (Server-)Farm", bewirtschaftet von IT-Gärtnern in magentafarbenen Gummistiefeln. Dort wachsen Business-Anwendungen aller Art, und der Wertbeitrag für das Kundenunternehmen lässt sich rund ums Jahr abernten.

Immerhin ist dieses Bild weitaus detaillierter und stimmiger als die oft bemühte "IT aus der Steckdose". Letztere wurde der Sache eigentlich nie gerecht, weil IT-Anwendungen eben nicht so gleichförmig und beliebig nutzbar sind wie elektrische Energie.

Da passt die Farm mit ihren unterschiedlichen Beeten semantisch weit besser. Wie Abolhassan ausführt, kann das dort gezogene Getreide oder auch Gemüse unterschiedlicher Art sein. Und die Betreiber müssen sich dementsprechend genau überlegen, was sie wo und in welcher Menge anbauen wollen. Deshalb schließen sie mit ihren Kunden ausgeklügelte Servicevereinbarungen ab.

Nicht ganz korrekt ist es, diese Vereinbarungen mit dem Schlagwort "Cloud Computing" zu belegen. Denn zum einen bedürfen die Leistungen, die T-Systems für seine Großkunden erbringt, durchaus einer - wenn auch gestrafften - Planung.

Zum Zweiten, und das ist weit gravierender, kommt ein wesentliches Element des Gesamtpakets eben nicht aus der "Cloud": Die Nutzungsverträge für die gehosteten Anwendungen muss der Kunde nach wie vor selbst mit dem Softwareanbieter schließen. Um im Bild zu bleiben: Der Anwender bringt die Setzlinge mit, die auf dem Farmland wachsen sollen.

Vermutlich ist das anders gar nicht möglich. Denn die Lizenzpolitik der Softwareanbieter sieht noch keine praktikablen Cloud-Modelle vor. Schließlich steht hier ein Kernbestandteil der Geschäftsmodelle zur Disposition. Doch soll sich der Cloud-Gedanke auf breiter Basis durchsetzen, müssen die Anbieter mitspielen und ihre Lizenzpolitik anpassen. (qua)