Während in vielen Branchen die IT-Industrialisierung schon weit vorangetrieben wurde, steht die Banken- und Versicherungswirtschaft damit erst am Anfang. Lange Zeit leistete sich die Branche kostspielige Sonderwege und setzte überwiegend auf Eigenentwicklungen und individuelle Systemlandschaften. Inzwischen steht diese Strategie unter Druck. So verlieren die in der Assekuranz üblichen Standardprodukte mit ihrer starren Generationen- oder Spartenorientierung an Bedeutung, weil die jüngeren Kunden zunehmend ins Internet abwandern, um sich über Produkte zu informieren, Preise zu vergleichen oder auch per Mausklick den Anbieter zu wechseln.

Die Versicherer reagieren auf das neue Anwenderverhalten mit flexibleren Produkten, die den Kunden in den Mittelpunkt stellen und individuell zu seinem Lebensabschnitt passen. Solche Offerten setzten allerdings eine Menge IT-Leistung voraus - etwa ausgefeilte Datenanalysen, die immer mehr Kundeninformationen aus dem Datawarehouse zutage fördern und als Basis für die Entwicklung neuer Produkte dienen können. Zeitgleich zu diesen notwendigen Innovationen hat sich jedoch der Kostendruck verschärft. Die CIOs stehen daher vor dem Spagat, einerseits die alten monolithischen IT-Strukturen aufzubrechen und auf neue flexiblere Architekturen zu migrieren. Andererseits müssen sie noch effizienter werden, um die Kosten zu senken.

Sourcing allein garantiert keinen Erfolg

Um den Wandel zu neuen Geschäftsmodellen und modernisierten IT-Strukturen im Rahmen engerer Budget-Grenzen zu meistern, bieten sich Outsourcing beziehungsweise Offshoring/Nearshoring als zentrale Bestandteile der Einkaufsstrategie an. Allerdings zeigt die Erfahrung, dass diese Modelle allein noch keinen Erfolg garantieren. Im Gegenteil - in der Vergangenheit sind viele Projekte gescheitert, weil beim Zukauf extern erbrachter Leistungen wichtige Aspekte übersehen oder falsch eingeschätzt wurden. Mal sind es unklare Zieldefinitionen, mal eine unzureichende Steuerung des Dienstleisters. Oder aber es fehlt die Akzeptanz von Seiten der Mitarbeiter (siehe Kasten 2).

Typische Fehler vermeiden

In der Vergangenheit ging das Management oft mit einer falschen oder gar keiner Strategie an das Thema Sourcing heran. Komplexe Systeme wurden kurzerhand als Kostenfaktor identifiziert, den man beseitigte, indem man ihn an einen Provider "wegdrückte". Unterblieb dann auch noch der notwendige Wissenstransfer, waren die externen Dienstleister schnell überfordert und konnten die erwarteten Leistungen nicht erbringen. Das führte häufig dazu, dass viele Verträge wieder rückabgewickelt wurden. 'Wie aber erreicht man ein funktionierendes Zusammenspiel zwischen internen IT-Leistungen und extern zugekauften Services. Die Lösung liegt in einer systematischen und konsequenten Sourcing Governance, die die Rahmenbedingungen für den planvollen und zielorientierten Einsatz interner und externer Ressourcen im Rahmen der Beschaffung definiert. Damit erhält der Anwender die Grundlage für seine Sourcing-Entscheidungen, gleichzeitig werden damit verbundene Risiken minimiert.

Strategisch oder nicht-strategisch?

Bei der Definition der Sourcing-Strategie sollte sich der CIO an den folgenden Grundsatz halten: Es gibt keine Tätigkeit, die zwingend ausgelagert werden muss. Es gibt aber Aufgaben, die intern erbracht werden sollten. Aufgabe des CIO und seiner Mitarbeiter ist es, IT-Services danach einzuteilen, ob sie strategisch sind oder nicht. Dabei hilft folgende Regel: Strategische Aufgaben helfen dem Anwenderunternehmen in Sachen Wettbewerbsfähigkeit und Differenzierung am Markt. Nicht-strategische Dienste dagegen lassen sich mit einem hohen Grad an Prozess- und Produktstandardisierung erbringen. Dieses grobe Schema lässt sich weiter verfeinern. So müssen strategische Geschäftsprozesse nicht komplett intern unterstützt werden, sondern lassen sich weiter in strategische und nicht-strategische Bestandteile untergliedern. Die Analyse sollte dabei dem Leitsatz folgen: Je näher die Aktivität am Kernprozess, desto höher ihr strategischer Anteil.

Aufteilung in Einzelaktivitäten

Das folgende Beispiel zeigt den Aufbau eines Sourcing-Profils mit sieben Einzelaktivitäten für einen insgesamt strategischen Geschäftsprozess: Die erste Aktivität, die "Initiierung" des Projekts, erfordert ein detailliertes Wissen um den Geschäftsprozess. Damit ist sie zu 100 Prozent strategisch. Auch beim zweiten Punkt "Definition" handelt es sich aufgrund der Geschäftsprozess- und IT-Relevanz um eine komplett strategische Aktivität. Beim "Design" lässt sich hingegen zumindest zum Teil externe Unterstützung zurückgreifen - etwa zur Erstellung des Pflichtenhefts. Der nicht-strategische Anteil beträgt etwa 40 Prozent. '"Build" wiederum ist überwiegend nicht-strategisch. Hier werden nur bis zu 20 Prozent Inhouse-Kompetenz - zum Managen der externen Leistungen - benötigt. Das gleiche Verhältnis gilt für "Deployment". Hier muss die interne IT lediglich vorbereitend und begleitend tätig werden. Beim "Betrieb" handelt es sich um eine in der Regel nicht-strategische Aktivität, die maximal zehn Prozent internen Steuerungsanteil verlangt. Als letzter Punkt im Sourcing-Profil steht "Optimize" als überwiegend strategische Tätigkeit auf dem Programm, sofern das Gesamtprojekt strategische Bedeutung hat. Mindestens 80 Prozent sollten intern erbracht werden - von Change-Requests bis zur Beendigung von Services.

An den Kunden und am Markt orientieren

Um eine derart differenzierte Sourcing-Strategie umzusetzen, bedarf es einer Sourcing-fähigen IT-Organisation, die ein umfassendes Verständnis von den Bedürfnissen der Fachbereiche - also der internen Kunden - hat. Einer ihrer ersten Schritte besteht darin, einen Servicekatalog zu erstellen und sich mit dem Kundenprozess vertraut zu machen. Dabei sollte siche die IT ein klares Bild von der Nahtstelle zwischen Business und IT (Line of Visibility) verschaffen. Wichtig ist aber auch die Schnittstelle zur "anderen Seite" - dem Markt für externe Provider und Lieferanten. Auch darauf sollte die Sourcing-Strategie ausgerichtet sein. Die IT steht also beim Sourcing keinesfalls vor einer Entweder-oder-Entscheidung - entweder für den Kunden und gegen den Markt oder umgekehrt. Sie sollte vielmehr in beide Richtungen schauen und sich sowohl Kunden- als auch Marktorientiert aufstellen.

Erfolgsfaktor Brückenkopf

Eine weitere wichtige organisatorische Maßnahme ist die Einrichtung eines Brückenkopfs (Bridgehead). Dieser fungiert in einem globalen Softwareentwicklungs-Team als fachliche und koordinierende Schnittstelle zwischen dem lokalen Kernteam (Auftraggeber) und dem Offshore-Entwicklungsteam (Auftragnehmer) und sorgt für ein nahtloses Projekt-Management.

Die fachlichen Aufgaben des Brückenkopfs orientieren sich an Qualitäts- und Ausführungsfragen. Es geht um Hilfe bei fachlichen Lücken, Vermittlung von Wissen über projektrelevante Systeme sowie um das Sicherstellen von Standards und Vorgaben. Der koordinative Teil des Brückenkopfs beseitigt Steuerungsdefizite, trifft Absprachen mit dem Offshore-Management und kümmert sich um Controlling und Eskalations-Management.

Schließlich sollten nach außen vergebene Projekte auf ihren Erfolg und die auftragsgemäße Umsetzung hin überprüft werden. Hierzu empfiehlt sich ein KPI-Framework (Key Performance Indicator). Um die korrekte Ausführung einzelner Projektschritte zu ermitteln, gilt es, einige wenige aussagekräftige Kennzahlen festzulegen - etwa den KPI "Pünktlichkeit", der die Abweichung von Lieferterminen prozentual misst, oder den KPI "Antwortzeiten", der die Abweichungen von der Spezifikation angibt. (sp)