»Rezepte für erfolgreiche IT-Projekte«

von Jürgen Höfling

Share
26.02.2009

»Rezepte für erfolgreiche IT-Projekte« Viele gute IT-Projekte scheitern, weil sie keinen organisatorischen Kontext haben. ­Jürgen Höfling sprach mit Dr. Bruno Wildhaber, Gründer und ­Vorstandsmitglied von Forte Advisors, über die optimale Verzahnung von IT und Geschäftsprozessen.

Bruno Wildhaber, ­Gründer und Vorstandsmitglied von Forte Advisors

Herr Dr. Wildhaber, GRC, was für Governance, Risk ­Management und Compliance steht, ist nicht in aller, aber doch in vieler Munde. Was bringt GRC für ein Unternehmen? Gibt es da einen Business Case?
Nein, es ist unsinnig, das Thema als Business Case aufzuziehen, GRC ist ja eine Antwort auf gesetzliche und innerbetriebliche Vorgaben. Auf solche Vorgaben sollte aber intelligent reagiert werden, mit anderen Worten, die Schlagkraft eines Unternehmens sollte durch GRC-Maßnahmen erhöht werden, um die wirklichen Business Cases erfolg­reicher gestalten zu können.

Welches sind solche GRC-Maßnahmen?
Die IT muss erstens strategisch abgestimmt sein, sie muss zweitens einen Wertbeitrag für das Geschäft liefern, drittens ist sie hinsichtlich der Risiken zu optimieren und schluss­endlich sind die Vorgaben so zu fassen, dass man sie messen kann.

Nun sind nicht alle Vorgaben unmittelbar gesetzlich veranlasst. Könnte man da eine Unterteilung treffen, zum ­einen in Pflicht-Aufgaben, also das Erfüllen der Gesetze, und dann Küraufgaben, also Vorgaben, die man sich zur Not auch sparen kann?
Das erscheint mir als Strategie ziemlich schwammig. Wer definiert denn, was Pflicht oder Kür ist? Letztlich wird ja kein Unternehmen einen Kontrollprozess aufsetzen, der nicht direkt oder indirekt mit gesetzlichen Pflichten zu tun hat oder andererseits Vorteile bei den operativen Geschäften bringt. Letzteres betrifft beispielsweise ein automatisiertes Records Management. Kosten sparen könnte man aber in der Tat, wenn gesetzliche Forderungen nicht von der Revision gigantisch aufgebläht würden!

Was meinen Sie damit genau?
Ein gutes Beispiel ist SOX. Im Gesetzestext stehen ­eigentlich schlichte Dinge, aber schauen Sie sich einen mal an, welchen Moloch die Revisionsleute daraus gemacht haben.

Das, was Sie über Records Management gesagt haben, ist interessant, können Sie das näher erklären? Da scheint mir GRC durchaus Kontakt mit Business Cases zu haben.
Records Management ist ganz wichtig, um die Personengebundenheit von Prozessen abzuschaffen oder wenigstens zu mildern. Die Prozesse in den Unternehmen sollten eben nicht oder nicht entscheidend von der Expertise einiger weniger Koryphäen im Unternehmen abhängen.

Gibt es so etwas wie einen Modellbaukasten für GRC, also das, was man »Best Practices« nennt?
Ein solcher Ansatz funktioniert meiner Ansicht nicht bei GRC, oder höchstens bis auf ein Niveau, wo man Dinge wie grobe Fahrlässigkeit ausschließen will. Und das tut man hoffentlich schon auf einer Grundlagen-Ebene. Alles andere ist sehr unternehmensindividuell, kann jedenfalls nicht in eine Schablone gepresst werden.

Aber es gibt sicher Vorgehensweisen, die mehr zu empfehlen sind als andere?
Ja sicher. Man braucht eine durchgehende Zielkas­kade, mit manifestierbaren Zielen, kurz: einfache, für jeden verständliche Zielbegriffe, und das durchgängig von oben bis unten. In Bezug auf die Implementierung gibt es automatisierte Tools, die eine effiziente Um­setzung von GRC unterstützen.

Manifestierbare Ziele heißt wohl in erster Linie, man braucht gute Messgrößen?
Genau. Und das ist gar nicht so einfach. Um ein Beispiel zu geben: Wenn Sie den Baufortschritt eines ­­Gebäudes ermitteln wollen, reicht es nicht, nur auf den Hof zu blicken und die LKWs zu zählen, die ­Steine abliefern oder Komponenten, um Beton zu machen. Sie müssen auch kontrollieren, ob der Beton für den Hausbau verwendet wird.

Inwieweit kann oder darf GRC an Fachabteilungen oder die IT-Verantwortlichen delegiert werden?
Der Führungsrahmen muss notwendigerweise auf der obersten Managementebene vorgegeben werden, das ist unabdingbar. Wenn das nicht geschieht, wird das Management schlicht seiner Führungsauf­gabe nicht gerecht. Das Management muss sich um die richtige Verzahnung wichtiger IT-Projekte mit den Geschäftsprozessen engagiert kümmern, aber soll sich natürlich nicht in Details einmischen. Ich sage immer: »Heads in – hands out«.

Nun ist die Kommunikation ja keine Einbahnstraße, ­eigentlich sollte sie genau das Gegenteil sein. Auch dieIT-Abteilung hat also eine Bringschuld gegen­über der ­Geschäftsführung, muss ein Projekt aktiv verkaufen und den Wertbeitrag sichtbar machen. Wie steht es damit?
Keine Frage, die Leistungen der IT, insbesondere der Beitrag zur strategischen Unternehmensentwicklung, müssen durch deren Protagonisten, also CIO oder dessen Führungsteam, sichtbar gemacht und den Fachbereichen dargestellt werden. Ohne Informationsmanagement wird es dabei nicht gehen. Alle Protagonisten müssen wissen, wie die eigene Landschaft der Informationsverarbeitung aussieht.

Geschieht das nach Ihren Erfahrungen?
Sicher viel zuwenig. Mehr noch: Viele IT-Abteilungen verzichten auf Quick Wins in ihren Projekten, mit denen sie die Vorstände begeistern könnten, was dann wiederum alle Projektmitarbeiter zusätzlich motivieren würde. Es ist eine Tatsache: viele gute IT-Projekte scheitern, weil sie keinen organisatorischen Kontext haben.

Herr Dr. Wildhaber, vielen Dank für das Gespräch!