Foto: SAP
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
Foto: T-Systems
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."