HSBC-Risikovorstand „Einen kompletten Arbeitstag in der Woche für das SAP-Projekt reserviert“

SAP-Umbau bei HSBC: Ferdun Mazaheri im Interview Quelle: PR

Die HSBC stemmt gerade das größte SAP-Projekt im deutschen Bankensektor. Ein Gespräch mit Risikovorstand Fredun Mazaheri über riskante Missverständnisse, typische Fallstricke und den richtigen Mix aus internem und externem Know-how, damit IT-Projekte gelingen.

  • Teilen per:
  • Teilen per:

Herr Mazaheri, bis 2023 wollen Sie bei der HSBC Deutschland alle Kern-IT-Systeme der Bank austauschen und die jahrzehntealte Technik durch Software von SAP ersetzen. Können Sie angesichts dieses Megaprojektes noch einigermaßen ruhig schlafen?
Fredun Mazaheri: Unbedingt. Ich schlafe sehr gut. Warum sollte ich nicht?

Weil sich in der Vergangenheit zahlreiche Konzerne bei solchen Projekten verhoben haben und immense Probleme hatten. Die mussten teils Milliardensummen abschreiben oder verloren zeitweise den Überblick über ihre Lager oder Lieferketten. Was macht Sie also so entspannt?
Weil ich weiß, dass wir gut unterwegs sind, dass ich ein erstklassiges Team habe, das den Umbau mit großer Sorgfalt vorantreibt. Und weil wir an drei ganz entscheidenden Stellen aufpassen, genau die Fehler nicht zu machen, die zu Problemen oder auch zum Scheitern des Projekts führen können.

Nämlich?
Erstens und vielleicht sogar am wichtigsten: Bei IT-Projekten geht es nicht nur um Technologie. Das ist keine Aufgabe, um die sich allein die IT-Abteilung kümmert und dann ist es gut. Das wäre – speziell bei Großprojekten – geradezu dramatisch falsch. Das sind strategische Themen, die Aufmerksamkeit und Engagement der Führungsebene brauchen. Nur hin und wieder auf ein paar Ampeln zum Projektzustand zu schauen, reicht nicht.

Bei Vorhaben, wie wir sie gerade umsetzen, braucht es wöchentliche Updates auf Vorstandsebene, mit den Leuten, die auch Entscheidungskompetenz haben. Nur dann bekommen Sie als Verantwortlicher mit, was wirklich passiert. Und die Menschen, die so ein Projekt umsetzen, müssen wissen, dass sie auch frühzeitig Gehör finden, wenn sich Schwierigkeiten abzeichnen.

Wird das an niedrigere Hierarchiestufen delegiert, besteht das Risiko, dass Informationen verloren gehen oder, dass Probleme zu spät entdeckt werden.

Aber braucht es nicht jede Menge Technologie-Kompetenz, um Hard- und Software-Großprojekte angemessen begleiten zu können? In deutschen Vorständen haben ja die wenigsten Informatik oder Ähnliches studiert.
Das ist ein Irrtum. Sie müssen ja keine Server installieren oder Software programmieren, wenn sie im Vorstand solch ein Thema verantworten. Da sind nicht in erster Linie Tech- sondern vor allem Managementkompetenzen gefragt. Die sollten im Vorstand Pflicht sein. Das nötige Grundverständnis für die IT kann sich der oder die Zuständige erarbeiten.

Was heißt das für Sie und die HSBC?
Dass ich einen kompletten Arbeitstag in der Woche für das SAP-Projekt reserviert habe. Für Diskussionen mit den Projektverantwortlichen, für Updates zur Lage und auch – falls das erforderlich ist – für kurzfristige Entscheidungen, die anstehen. Bisher läuft das gut und das Team weiß, dass ich erreichbar und involviert bin.

„Wir suchen weiter reichlich gute Leute“

Was ist „Fehler Nummer Zwei“?
Zu wenig interne und zu viel externe Kompetenz, die ein IT-Großprojekt stemmen soll. Unternehmen neigen dazu, sich für große Tech-Projekte zu viele Fachleute von außen zu holen und zu wenig eigene Kompetenzen aufzubauen.

Das ist zum einen riskant, weil mit den Beratern das Know-how am Ende wieder weg ist und dem Unternehmen fehlt. Aber es ist auch riskant, weil Leute von außen selten so gut über die internen Stolperstellen und potenziellen Fallstricke Bescheid wissen, wie interne Spezialisten.

Manchen Externen fehlt es auch schlicht an Identifikation mit der Firma und dem Projekt. Das meine ich gar nicht vorwurfsvoll. Das liegt in der Natur der Sache. Die Internen dagegen wissen, dass sie mit der Technik, die sie in so einem Umbau einführen, auch dann noch werden arbeiten müssen, wenn die Externen weitergezogen sind. Also denken sie nachhaltiger.

Was ist aus Ihrer Sicht ein gutes Kräfteverhältnis?
Ein Drittel Externe. Maximal.

Der Markt für IT-Fachleute ist leer. Kaum ein Unternehmen, das einen SAP-Umbau plant, wie Sie ihn gerade vorhaben, hat die entsprechenden Personalkapazitäten. Erreichen Sie die Quote denn selbst?
Nicht von Anfang an, weil wir unser Personal natürlich am Normalbedarf ausgerichtet hatten. Aber seit klar ist, was wir umsetzen wollen, bauen wir auf.

ITler sind knapp und teuer. Wie leicht konnten Sie die benötigten Stellen denn intern durchsetzen? Und wie erfolgreich sind Sie auf dem Arbeitsmarkt?
Alle haben verstanden, dass wir die Kompetenzen vor allem im Haus brauchen. Und inzwischen nähern wir uns unserer Zielquote immer weiter an. Auch, weil wir – glaube ich – ein für IT-Spezialisten enorm spannendes Projekt stemmen. Das weckt Interesse in der Szene.

Aber die Wahrheit ist auch: Mindestens mal im ersten Jahr ist ein IT-Projekt unserer Größe gar nicht so sehr eine Technologie- sondern eine Personalbaustelle. Wir suchen weiter reichlich gute Leute.

Sie sprachen von drei entscheidenden Fehlern.
Richtig. Große IT-Vorhaben – ganz egal, ob es sich um SAP-Projekte oder solche mit anderen Anbietern handelt – brauchen Zeit. Wir etwa rechnen mit fünf Jahren für den Umbau. Und das ist nicht einmal besonders lange. Um so etwas durchzuziehen, braucht es Ausdauer und Durchhaltewillen. Wer das nicht bedenkt und beherzigt, fährt den Karren garantiert irgendwann vor die Wand.

Warum?
Im Grunde wollen wir doch alle an spannenden Aufgaben arbeiten, oder? So ein IT-Großprojekt ist das ganz sicher – zumindest am Anfang. Da ist es cool, so etwas voranzutreiben. Die ersten Schritte, die ersten Veränderungen, die ersten Meilensteine, die man erreicht, die begeistern. Die sorgen für Aufmerksamkeit und Anerkennung.

Aber dann wird es halt zäh und irgendwann auch uncool. Da kommen neue Themen, da liegt der Fokus im Unternehmen woanders. Und Du steckst immer noch im Projekt – und die Ebene ist lang. Mit dem x-ten Teilschritt begeisterst Du keinen mehr. Im dritten Jahr wird es so richtig schmerzhaft. Und das Risiko, dass irgendwelche neuen Themen anfangen, die Großbaustelle zu kannibalisieren, das steigt mit jedem Monat.

Wer da den Fokus verliert, wer da beginnt, Personal zu verschieben, der legt den Grundstein für Verzögerungen, für Probleme, Kostensprünge und – mitunter zumindest – auch fürs spätere Scheitern.

„Leistungsfähige Standard-Software“

Manche Leute sagen, dass IT-Projekte auch schlicht zu groß und zu komplex dimensioniert sind und das Scheitern damit quasi vorherbestimmt sei. Dass etwa die Deutsche Post 2015 die Gewinnziele wegen eines geplatzten SAP-Projektes kappen musste, dass der Otto-Konzern 2012 eine groß angelegte SAP-Einführung kippte oder dass Lidl 2018 – nach Investitionen von fast einer halben Milliarde Euro – eine SAP-Offensive stoppen musste, all das soll auch an der Komplexität der Vorhaben gelegen haben. Fürchten Sie nicht, dass Ihnen Ähnliches droht, wenn Sie die komplette Bank-IT auf SAP umstellen?
Bitte sehen Sie es mir nach, dass ich mich zu Projekten anderer Unternehmen nicht konkret äußern möchte. Wie gesagt, es gibt immer eine Menge von Gründen, warum etwas scheitern kann. Aber eines ist mir wichtig: Dass jemand ein SAP-Projekt umsetzt, ist per se kein Anlass zur Sorge. Die Walldorfer sind nicht umsonst in vielen Bereichen der Unternehmens-IT als Standard gesetzt und anerkannt. Dass es immer wieder zu prominenten Fehlschlägen kommt, hat meines Erachtens zwei entscheidende Ursachen.

Die wären?
Zum einen, ganz banal: SAP ist so groß und präsent, dass Probleme dort fast zwangsläufig auffallen. Ich könnte Ihnen aus dem Stand vier, fünf andere Softwarehersteller aus der Unternehmens-IT nennen, bei denen Projekte nicht minder krachend gescheitert sind. Bloß, die kennt kaum wer, und damit sind die Fälle natürlich auch viel weniger prominent.

Und zum anderen?
SAP entwickelt leistungsfähige Standard-Software. Das heißt, sie bauen Programme, die sie für standardisierte Prozesse in Unternehmen optimieren. Wenn sich in der Wirtschaftswelt also bestimmte Arbeitsabläufe, juristische Verfahren oder Buchungsprinzipien als besonders effizient erweisen, kann man davon ausgehen, dass man die auch in SAPs Produkten wiederfindet.

Viele Unternehmen machen manches aber intern anders, als es der branchenübergreifende Normalfall vorsieht. Das kann gute Gründe haben, oder auch der Geschichte oder der Gewohnheit geschuldet sein. Wenn ein Unternehmen in solchen Fällen Standard-Software einführen will, hat es zwei Optionen – und beide sind unangenehm: Entweder es passt die Software an die internen Sonderlichkeiten an, oder es passt die internen Prozesse an die Software an.

Wo ist das Problem?
Interne Strukturen umzubauen, gewohnte Arbeitsabläufe umzuschmeißen, das „Haben-wir-immer-schon-so-gemacht“ abzuschaffen, das kostet Kraft. Das ist eine eigene Herausforderung, ein Change-Management-Projekt. An den Standardmodulen von SAP herumzuschrauben, kann da als der vermeintlich leichtere Weg erscheinen.

Nur fängt man sich genau damit in der Regel einen Rattenschwanz neuer Probleme ein. Denn je mehr Baustellen man aufmacht, desto komplexer wird es. Nicht nur, aber eben auch bei Großprojekten wie mit SAP. Bleibt man beim Standard, ist es schnell, effizient und robust. Schraubt man daran herum, können Kosten und Probleme durch die Decke gehen.

Was heißt das für Ihre Baustelle bei der HSBC?
Dass wir uns ganz zu Beginn hingesetzt und einen Plan entwickelt haben, wie wir die Bank und unsere internen Abläufe zukünftig strategisch entwickeln wollen. Und wir haben uns überlegt, wie dazu die Prozesse aussehen sollen. Dann erst haben wir geprüft, mit welcher IT wir dieses Ziel am besten erreichen können. Das war für uns dann SAP. Nun passen wir die Abläufe im Haus an unseren Zukunftsplan an und setzen dabei soweit es geht auf die Standards, die die Plattform bietet.

Dabei müssen wir natürlich die Menschen mitnehmen, die mit der Technik arbeiten müssen, müssen erklären und begründen und dürfen nicht einfach Beschlüsse fassen und uns dann nicht mehr darum kümmern.

Dennoch gilt: Abweichungen vom Software-Standard gibt es nur in absoluten Ausnahmefällen und die Entscheidung darüber liegt ganz oben. Nur dann weiß ich, was passiert und warum. Und ich kann auch die Verantwortung tragen, wenn wir irgendwo von unseren Ursprungsplänen abweichen.

Und, gelingt das?
Bisher passt es. Bis zum Jahresende werden wir den ersten Teil der IT, die Verwaltungskosten, als erstes Modul umstellen können. Und dann geht es schrittweise weiter. Es ist natürlich eine immense Herausforderung, die wir da stemmen; quasi eine Operation am offenen Herzen der Bank. Wir sind auf dem richtigen Weg.

© Handelsblatt GmbH – Alle Rechte vorbehalten. Nutzungsrechte erwerben?
Zur Startseite
-0%1%2%3%4%5%6%7%8%9%10%11%12%13%14%15%16%17%18%19%20%21%22%23%24%25%26%27%28%29%30%31%32%33%34%35%36%37%38%39%40%41%42%43%44%45%46%47%48%49%50%51%52%53%54%55%56%57%58%59%60%61%62%63%64%65%66%67%68%69%70%71%72%73%74%75%76%77%78%79%80%81%82%83%84%85%86%87%88%89%90%91%92%93%94%95%96%97%98%99%100%