Integration von IT als Chance sehen

Beim Zusammenschluss zweier Unternehmen oder der Ablösung eines veralteten ERP-Systems spielt die Integration von Software eine wichtige Rolle. Das Projekt "System-Integration" setzt eine gute Planung voraus. Ansonsten laufen Unternehmen Gefahr, sich zu verrennen. Das Wichtigste dabei ist, zu wissen, was mit der Einführung einer neuen Software überhaupt erreicht werden und welche Vorteile sie bringen soll.

Das bestätigt auch Guido Kaufmann, CIO von Local.ch. Das Unternehmen umfasst die drei Firmen Swisscom Directories AG, LTV Gelbe Seiten AG und Local.ch AG und ist je zur Hälfte im Besitz von Swisscom und Publigroupe. Local.ch hat eine gemeinsame Geschäftsleitung und startete letztes Jahr ein Drei-Jahres-Projekt, um die IT der drei Firmen zusammenzuführen und dabei die Systemlandschaft neu zu konzipieren. Kaufmann verfolgte dabei das Ziel, die Geschäftsprozesse von Local.ch auf die Zukunft auszurichten und die Unterhaltsund Betriebskosten zu reduzieren. Dies unter anderem, weil sich das Geschäftsmodell immer stärker vom klassischen Telefonbuch hin zum Onlineverzeichnis verlagert. "Wir haben gesehen, dass die heutige Systemlandschaft den sich wandelnden Anforderungen im Business nicht mehr nachkommen kann und auch viel zu unflexibel und wartungsintensiv ist."

Ziel sei daher eine komplett neue, modulare und flexiblere Systemlandschaft, die eine raschere und auch günstigere Reaktion auf Änderungen im Business erlaube. Neben der klaren Zielsetzung ist eine saubere IT-Struktur eine weitere wichtige Voraussetzung für den Erfolg eines Integrationsprojektes. "Bei der Einführung einer neuen Software sieht man, wie gut die IT ihre Hausaufgaben gemacht hat." Kaufmann bezeichnet eine gute IT-Architektur als "Königsdiziplin der IT". In diesem Zusammenhang erinnert er sich nur ungern an einige frühere Integrationsprojekte: "Die IT-Systemlandschaft war dort zwischenzeitlich so komplex geworden, dass die Integration einer neuen Komponente die Ablösung aller Umsysteme mit sich zog, was teuer und risikobehaftet war."

Synergien nutzen

Beim Integrationsprojekt von Local.ch unterscheidet Kaufmann zwischen den Kernsystemen und den Nicht-Kernsystemen. Nicht-Kernsysteme wie HR-Management, Finanzen und Intranet waren in diesem Jointventure stets zwei- oder dreimal vorhanden. Das Ziel war daher, diese möglichst schnell zusammenzuführen, um die Arbeit der nun näher zusammengerückten Einheiten zu vereinfachen und Synergien zu nutzen. Durch diese Zusammenführung mussten sich die Verantwortlichen für jeweils eines der zwei oder drei Nicht-Kernsysteme entscheiden. Danach konnten sie die entsprechenden Daten auf das neue System migrieren. Bei den Kernsystemen hingegen war das Ziel, erst die einzelnen Elemente voneinander zu entkoppeln, um komponentenweise Systeme abzulösen beziehungsweise einzuführen. Dies ergibt Sinn, denn es dient auch der Verminderung des Risikos. Falls etwas nicht klappt, kommt nicht gleich das ganze System zum Erliegen. Zudem bietet ein solches Szenario genügend Zeit, die Software zu testen und Erfahrungen zu sammeln. Auch ein Fallback-Szenario lässt sich damit leichter umsetzen.

Kaufmann wollte mit seiner Strategie vermeiden, von einem Tag auf den anderen auf ein neues System zu migrieren. Denn er weiss: An einem nicht sauber funktionierenden System, das im Live-Einsatz ist, grössere Korrekturen anzubringen, ist sehr schwierig und gefährlich. Meist bekämpfe man in solchen Fällen nur Symptome, da für tiefgreifendere Änderungen die Zeit gar nicht reiche. Das wäre so, als wenn man an einem fahrenden Auto die Reifen wechsele. Der Trick bei einem Integrationsprojekt besteht daher darin, nicht zu viel, aber auch nicht zu wenig Zeit einzuberechnen. Einerseits ändert sich in der IT und im Business alles sehr schnell, andererseits wird für die Integration und die Einführung einer Software erfahrungsgemäss zu wenig Zeit eingeplant. "Zuerst wird mit Hochdruck entwickelt, und dann treten bei der Integration der Komponenten trotzdem Überraschungen auf."

Dies erinnert an das Pareto-Prinzip, das besagt, dass 80 Prozent der Ergebnisse in 20 Prozent der Gesamtzeit eines Projekts erreicht werden. Die verbleibenden 20 Prozent der Ergebnisse verursachen die meiste Arbeit, sprich, diese benötigen 80 Prozent der Gesamtzeit.

Sauber testen

Die Nicht-Kernsysteme bei Local.ch wurden per 1. Januar dieses Jahres migriert. Am 31. Dezember war ein kleines Team vor Ort, um die Weichen zu stellen. Diese Umstellung habe das IT-Team sauber testen können, daher sei es keine grosse Sache gewesen. Etwas hektisch wurde es trotzdem vor Weihnachten. «Da sind bei uns manchmal schon etwas die Nerven blank gelegen, weil es in letzter Minute immer noch Anpassungen oder Überraschungen gab.» Momentan gehe es wieder etwas ruhiger zu, "doch uns stehen bei den Kernsystemen noch grössere Herausforderungen bevor, daher werde ich wohl nicht immer so ruhig schlafen wie bei der Migration der Nicht-Kernsysteme".

Bei den Kernsystemen musste sich Kaufmann unter anderem auch mit der Frage auseinandersetzen, ob das Unternehmen neue Software kaufen oder sie selbst entwickeln wollte. Also die klassische Make-or-buy- Frage. Local.ch verfolgt die Strategie, nur diejenigen Anwendungen selbst zu entwickeln, die aus einem bestimmten Grund speziell sind. Umbruchsysteme beispielsweise gebe es auf dem Markt schon viele, diese nochmals selbst zu schreiben, wäre daher nicht sinnvoll gewesen. Beide Vorgehensweisen, kaufen oder selbst entwickeln, bergen Risiken in sich. Baut man eine Software selbst, besteht die Gefahr, dass die Entwickler das alte System nachbauen. Beim Kaufen hingegen kann es damit enden, dass man die Software nach Biegen und Brechen den bestehenden Prozessen anpassen will. "Business follows IT" wäre in einem solchen Fall angebracht. Ausserdem bringt es nichts, aus Standardsoftware eine Individualsoftware machen zu wollen.

Akzeptanz neuer Software sicherstellen

Sehr wichtig sei es auch, die "besten Leute des Business" von Anfang an einzubinden. Denn ein neues System kämpft anfangs erfahrungsgemäss noch mit Kinderkrankheiten. Die sogenannten "Opinion Leaders" müssen daher hinter dem neuen System stehen, damit sie am Anfang, wenn es etwas rumpelt, nicht schlechte Stimmung verbreiten, sondern die Leute mitziehen. Vereinfachte Prozessschritte ("früher war das viel komplizierter") seien dann meist Quick- Wins für die Akzeptanz einer neuen Lösung. Das neue System sollte nach etwa sechs Monaten bei den Benutzern akzeptiert sein, sonst habe man etwas falsch gemacht.

Wohin die Nicht-Akzeptanz eines neuen Systems führen kann, hat Rudolf K. Spiess, ehemaliger CIO der Stadt Biel und mittlerweile Berater bei IT-Projekten, am eigenen Leib erlebt. Er musste ein IT-Projekt begraben, weil die Anwender nicht motiviert waren, damit zu arbeiten. "Die Qualität der Software war dabei nicht das Problem", versichert Spiess. Er hat daraus gelernt, wie wichtig es ist, Anforderungen und Geschäftsprozesse von Anfang an zu definieren und die Mitarbeiter, die sich im Business auskennen, einzubinden.

Er weiss, wovon er spricht. Als die Verwaltung der Stadt Biel sich entschied, von einer Siloarchitektur auf SAP zu migrieren, wandte die Stadt für den Bereich Einwohnerkontrolle ein ganzes Jahr für eine Machbarkeitsstudie und die anschliessende Analyse auf. Dies erfordert zwar grossen Aufwand, "aber diese Investition von Zeit lohnt sich".

Schnittstellen sind teuer

Weitere Probleme bei der Integration von Software sieht Spiess unter anderem bei Schnittstellen. Denn diese sind teuer und verursachen wiederkehrende Kosten. Bei der Berechnung der Migrationskosten werden Anpassungen und Schnittstellen, die noch gemacht werden müssen, oft vernachlässigt. "Aber es wird eben so gemacht, weil es auf den ersten Blick viel einfacher scheint", so Spiess. Am einfachsten wäre es daher seiner Meinung nach, möglichst integrierte IT-Plattformen zu betreiben, die wenige Schnittstellen benötigen. Eine andere Lösung wäre, wenn die Schnittstellen über eine standardisierte "Datendrehscheibe" bedient werden könnten.

Eine Integration bezeichnet Spiess als erfolgreich, wenn sie Kosten senkt, zeitliche Abläufe beschleunigt, Ergebnisse qualitativ verbessert, die Arbeitsabläufe erleichtert und trotzdem sicher ist. "Eigentlich müsste man damit beginnen, die Geschäftsprozesse zu optimieren und die Software danach auszuwählen." Ein weiterer wichtiger Punkt, der ebenfalls oft vernachlässigt wird, ist eine Analyse der erreichten Ziele und ein Vergleich mit den ursprünglich gesteckten Zielen. "Am Ende eines Projektes ist man oft froh, dass es endlich fertig ist und schaut nicht mehr zurück, ob man die gesetzten Ziele wirklich erreicht hat», sagt Spiess. Er rät daher, diesen Punkt obligatorisch zu machen, ansonsten falle er unter den Tisch. "Wenn die gesteckten Ziele nicht erreicht worden sind, gibt es eben Pendenzen, deren Abarbeitung zu planen ist."

Klares Ziel ist wichtig

Wie Kaufmann sagt auch André Guyer, Head Global Transformation bei der Zürich-Versicherungsgesellschaft, wie wichtig es ist, ein klares Ziel vor Augen zu haben. Guyer war lange in der Informatik tätig, unter anderem als CIO, und orientierte sich danach immer mehr in Richtung Business. Seit zehn Jahren ist er nun für die Zürich tätig und leitet dort globale Transformationsprojekte. Er weist darauf hin, dass IT nicht alle Probleme lösen könne. Angenommen, ein Unternehmen möchte seine Kompetenzen im Verkaufsbereich steigern und zu diesem Zweck ein neues CRM-System einführen. Dies kann zur Unterstützung des Verkaufsteams durchaus sinnvoll sein. Doch solange sich die Kultur in der Verkaufsabteilung nicht ändert, kann auch das beste IT-System nichts ausrichten. Zumindest werden die Kompetenzen der Mitarbeiter dadurch nicht besser.

"Leute aus der IT glauben oft schon die Lösung zu kennen, bevor sie überhaupt wissen, wo das Problem liegt", stellt Guyer fest. Man müsse auch seine eigenen Stärken und Schwächen akzeptieren können. "Die IT kann nicht immer die Lösung für alles liefern." Dieser Ansatz lässt sich auch mit einem Konzept aus der Softwareentwicklung von Michael Anthony Jackson ausdrücken: "Don't do it. Don't do it yet." Sprich: Man sollte nicht einfach einen Schnellschuss landen, sondern sich gründlich überlegen, ob und inwiefern eine neue Software wirklich Sinn ergibt. Um eine solche Entscheidung fällen zu können, ist es für eine IT-Abteilung auch wichtig, das eigene Business zu kennen. Er habe Softwareentwickler getroffen, die seit 20 Jahren Bankensoftware entwickeln, aber eigentlich kaum eine Ahnung haben, was das Bankenbusiness eigentlich ausmacht.

Menschliche Barrieren

Neben zu schnell gefällten oder schlecht durchdachten Entscheidungen scheitern IT-Projekte wie die Integration einer neuen Software selten an technischen, sondern viel öfter an menschlichen Fragen. Diskussionen, die die Informatik betreffen, werden durch die Geschäftsleitung oft an die IT-Abteilungen delegiert. Diese macht dann einfach, was sie kann, was aber nicht immer mit den Geschäftszielen harmoniert. Daher kann es hilfreich sein, einen neutralen Projektleiter zu haben. Dabei kann es sich um einen externen oder einen internen Berater handeln. Dieser müsse unbedingt über Führungserfahrung verfügen. "Ein Projektleiter ist ein bisschen wie ein Dirigent eines Orchesters", so Guyer. Er müsse Verantwortung übernehmen können und "visibel sein". Zudem muss er Entscheidungen fällen können, auch wenn er damit Gefahr läuft, sich unbeliebt zu machen.

Für ihn steht fest, dass sich die meisten Technikprobleme mit einem guten Management lösen lassen, "aber man kann kein Managementproblem mit Technik lösen". Bringt also ein Integrationsprojekt primär Probleme und Sorgen mit sich? Nein, im Gegenteil. Es birgt vor allem neue Möglichkeiten, so Kaufmann: "Die Integration einer neuen Software ist eine riesige Chance, um sich gemeinsam zu überlegen, wie das zukünftige Geschäft aussehen soll." Wann sonst hat man schon die Möglichkeit, die ganze IT-Infrastruktur komplett zu erneuern?