IT-Governance - Herausforderungen

9. Herausforderungen in der Praxis

Ziele der Lektion

• Erkennen der Bedeutung des kontinuierlichen Verbesserungsprozesses
• Diskussion über mögliche Problemstellungen im Zusammenhang mit IT-Governance

Es gibt mannigfaltige Stolpersteine bei versuchten Optimierungsmaßnahmen der IT-Governance. In vielen Fällen fehlt ein strukturell gut durchdachter Top-Down-Ansatz, der aus Zeit- und Kostengründen mitunter nicht verfolgt wird. Ganz wichtig bei solchen Verbesserungsmaßnahmen ist das Schaffen von Quick Wins, um die für die Mitarbeiter*innen in der Regel schwer greifbare IT-Governance positiv erlebbar zu machen und um Zeit zu gewinnen, echte strukturelle Anpassungen vornehmen zu können. Ein wesentlicher Schlüsselfaktor sind die Stimmungen und die Gruppendynamik, die während einer Umstellungsphase – sei es eine geschäftsprozess-, IT-Prozess oder tool-bezogene Maßnahme. Generell müssen bei der Einführung von IT-Governance die vier Dimensionen Processes (Prozesse), People (Mitarbeiter*innen), Products (Anwendungen, IT Tools) und Partners (Lieferant*innen) betrachtet werden.

Vier Dimensionen bei der Einführung von IT-Governance [eigene Darstellung]

In jeder dieser vier Dimensionen lauert das Potential für Konflikte und Schwierigkeiten bei der Einführung von IT-Governance.

People

Die Einführung eines IT Tools für spezielle Aufgaben löst bei den Mitarbeiter*innen sehr oft Unbehagen aus. Oft kommen auch neue Konzepte durch das neue IT Tool zur Anwendung, die eine große Umstellung der Arbeit nach sich ziehen.

Symbolische Darstellung der Arbeitszufriedenheit vor, während und nach einer Tooleinführung [eigene Darstellung]

Typischerweise steigt die Arbeitszufriedenheit mit einem neu einzuführenden Tool kurzfristig an – je mehr Erwartungen in das neue Tool zur Lösung aktueller Probleme gesetzt werden, desto mehr – dann holt die Realität die Erwartungen ein und drückt die Arbeitszufriedenheit in den negativen Bereich. Erste Kinderkrankheiten technischer Natur, erste Sonderfälle bei der Abbildung der Geschäftsfälle, aber auch vermehrte Kritik des User Handlings machen sich bemerkbar. Ist das Tool oder die Software-Entwicklung hier zusätzlich noch mit Fehlern behaftet – im schlimmsten Fall werden Zielsetzungen nicht erreicht – kann sich die Arbeitszufriedenheitskurve nur schwer erholen. Im Normalfall wird diese aber mit der Zeit positiv und pendelt sich auf einem höheren Niveau als zu Zeiten des Vorgängertools ein. Man kann sagen, dass sich diese Entwicklung nach Einführung eines neuen IT Tools prinzipiell so gestaltet – je wichtiger das Tool für den Geschäftsprozess ist, desto heftiger fallen die Höhen und Tiefen aus. Die Zahlenangaben in obiger Grafik haben nur die Bedeutung, die Zufriedenheit (positiver Zahlenbereich) und Unzufriedenheit (negativer Zahlenbereich) zu repräsentieren, die Phasenbezeichnungen sind frei gewählt.

Bei IT-Governance-Projekten kommt den beteiligten Akteur*innen entscheidende Bedeutung zu. Erfahrungsgemäß schwingt bei vielen Projekten, wo es darum geht, Vorgaben, Maßnahmen, Aktivitäten, Kontrollen in die Organisation zu bringen und zudem viele Personen zu involvieren sind, die Gefahr des Scheiterns mit. Nicht zuletzt aufgrund der erzeugten Dynamik in der Stimmungslage kommt bei solchen Projekten die Management Awareness und dem Projektmarketing eine wichtige Rolle zu. Nachdem das Top Management symbolisch wichtige Zeichen setzt, indem der Chief Execution Officer (CEO) das Projekt auf Veranstaltungen erwähnt, auf seine berichtspflichtigen Mitarbeiter*innen einwirkt und ausdrückt, dass ihm das Thema wichtig ist, kann das Projektmarketing durch gezielte Information die breite Masse des Unternehmens informieren. Darauf aufbauend muss die Projektleitung eine „Koalition der Willigen“ suchen, wodurch dessen*deren unmittelbare Kolleg*innen positiv mit den IT-Governance-Projekten in Berührung kommen. Die Gegner*innen und Unkenrufer*innen wird es in einer Organisation immer geben, jedoch erzeugt man mit der Zeit eine gewisse Gruppendynamik und eine positive Stimmung, derer diese sich nicht erwehren werden können. Wenn die Gegner*innen in der Unterzahl sind, kippt die allgemeine Atmosphäre gegen sie und die allgemein positiven Maßnahmen werden auch so erlebt und die Verbesserungen können dabei lukriert werden. Im Gegensatz dazu können fachlich als eindeutig notwendig erachtete und gute IT-Governance-Projekte scheitern, wenn Unkenrufer*innen und Gegner*innen einerseits in einer schwer vermeidbaren organisatorischen Position sind oder wenn diese es schaffen, das gesamte Projekt atmosphärisch bei den Kolleg*innen zu diskreditieren.

Processes

Als erster Ansatzpunkt für eine kritische Würdigung fungiert der Geschäftsprozess. Wenn dieser bereits vor Varianten und Ausnahmen strotzt, deren Aktivitäten noch durch mehrere Akteure oder Rollen durchgeführt und verschiedene Medien – also IT Tools – angewendet werden, dann leidet die Transparenz. Weder ist eine effiziente Überwachung der Geschäftsfälle noch ein durchgängiges Reporting in so einem Fall möglich. In den meisten Fällen ist so ein Prozess nicht wirklich reproduzierbar und durch die Abhängigkeit von einzelnen wissenden Key Playern für ein Unternehmen auch recht gefährlich. Hohe Durchlaufzeiten sind dabei garantiert. Symptomatisch ist dabei auch, dass Informationen nicht wirklich geordnet erfasst, verändert und strukturiert abgelegt werden. Alles passiert ad hoc, mitunter werden dieselben Kontrolltätigkeiten durch verschiedene Personen unterschiedlich in verschiedenen Phasen des Prozesses durchgeführt. In so einem Fall ist dringender Handlungsbedarf für ein Business Process Reengineering gegeben. Der Boden ist in so einer Situation gut aufbereitet, denn schon jede kleine Maßnahme, die eine reale Verbesserung für die beteiligten Akteure bringt, wird mit hoher Wahrscheinlichkeit positiv aufgenommen. Vorweg stellt sich hier das Problem, wo man beginnt.

Ein Geschäftsprozess muss klar definiert und eindeutig an den strategischen Zielen ausgerichtet sein, wobei vor allem der Kundenbedarf – oder allgemeiner formuliert: der Bedarf der Stakeholder – berücksichtigt werden muss. Die Verantwortlichkeiten für die Durchführung der einzelnen Prozessschritte sollen genau festgelegt werden. Die Anzahl der involvierten Rollen und Akteure soll so groß wie nötig und so klein wie möglich sein, insbesondere bei einem einzelnen Prozessschritt. Dabei kann ein Akteur auch mehrere Rollen bekleiden. Ganz wesentlich ist es zudem, den Informationsbedarf pro Prozessschritt zu ermitteln, diese zentral zusammenzuführen und verwertbar zu machen. Die Weitergabe der Information soll dabei tunlichst optimiert werden. Dabei setzt IT-Governance nicht nur bei dem zuletzt erwähnten Informationsbedarf an, wo dies ja offensichtlich erscheint, sondern bei allen zuvor erwähnten Aspekten. IT kann bei jeder Einflussgröße in den Geschäftsprozess eingreifen, aber auch im schlimmsten Fall ein Hemmschuh sein, also dann, wenn durch den Einsatz der IT die Abarbeitung der Geschäftsfälle erschwert und dadurch die Durchlaufzeit oder der Aufwandseinsatz erhöht wird.

Products

Eine große Gefahr einer grundsätzlichen Themenverfehlung geht dann aus, wenn IT- Prozesse ausschließlich um die bereits vorhandenen IT-Tools entworfen und implementiert werden. Da in so einem Anwendungsfall nicht mehr das ursprünglich formulierte strategische Ziel angepeilt wird, beschränkt man sich hier auf die bereits bestehende IT-Unterstützung und nimmt diese als unverrückbar an. Allerdings kann bei einer nicht effizienten IT-Unterstützung der Geschäftsprozesse kein Erfolg durch Business Process Reengineering erzielt werden, weil die Mankos der fehlenden IT-Unterstützung des Geschäftsprozesses ja bestehen bleiben. Es ist daher essentiell, sich bei der Geschäftsprozessmodellierung unbedingt auf die strategischen Ziele des Prozesses zu konzentrieren und die Aktivitäten technologie-unabhängig zu formulieren. Erst in einem zweiten Schritt sollte man die Effektivität und Effizienz der aktuell angewendeten IT-Unterstützung hinterfragen.

Die Information und deren Wandlung innerhalb des Geschäftsprozesses ist ein kritischer Erfolgsfaktor. Es ist wichtig zu hinterfragen, wann welche Information von wem in welcher Form benötigt wird. Die eingesetzten IT-Tools sollten diese Fragestellungen soweit wie möglich unterstützen. In einem Szenario, wo unkoordiniert Informationen erzeugt, verändert, an verschiedenen Orten oder – technisch gesehen – Datenbanken abgelegt werden, stellt die Informationsweitergabe den Prozess Manager vor große Probleme. Es entstehen meist auch verschiedene Datenbasen, die sich ziemlich sicher auseinander entwickeln. Im Falle von Kundenstämmen kann das zum Beispiel fatal sein.

Ein anderes mögliches Phänomen ist, dass theoretische Konzepte mit einer bestimmten Zielsetzung für den internen Bedarf und für ein anderes Ziel abgewandelt und dadurch das eigentlich ursprüngliche Konzept desavouiert oder zumindest negativ beeinflusst werden. Dies ist zum Beispiel der Fall, wenn Standardapplikationen angeschafft, diese aber so intensiv für eigene Zwecke adaptiert werden, sodass die ursprüngliche Zielsetzung nicht erreicht wird. Salopp formuliert bedeutet das, dass ein IT-Tool falsch eingesetzt wird oder es „ver-customized“ wird. Das kann zwar mitunter funktionieren, allerdings nur bei immensem Entwicklungs- und Adaptierungsaufwand. Schon allein die Tatsache, dass das theoretische Konzept abgewandelt wird, legt nahe, dass an den Grundfesten manipuliert wird und gute Chancen bestehen, sich große Probleme in Entwicklung und Betrieb einzuhandeln. Beispielsweise laufen individuell entwickelte Applikationen immer Gefahr, nicht mehr upgrade-fähig zu sein. Bei einer IT-Investition in ein Tool sollte daher immer die ursprüngliche Zielsetzung kritisch hinterfragt werden, um sicherzustellen, dass die theoretischen Konzepte auch zur jeweiligen Unternehmenssituation passen.

Es kann auch eine Situation entstehen, wo einem an sich funktionierenden Tool ständig geringe Adaptierungen und vermeintlich kleine Verbesserungen widerfahren. Dadurch kann es passieren, dass ständig „Pflasterlösungen“ für kurzfristige Anforderungen entwickelt werden, die aber in Summe zu kurz greifen, um die IT-Governance konzeptuell zu verbessern. Auch hier ist es ratsam, das dahinter stehende Konzept kritisch zu hinterfragen und Lösungen zu suchen, die generisch formuliert und möglichst flexibel anwendbar sind. Anders ausgedrückt gibt es Lösungen für konkrete Problemstellungen, die – falls zu konkret formuliert – nicht ausreichend allgemein das Problem lösen und somit für andere Spezialfälle wiederum nicht anwendbar sind. Für diese Spezialfälle müssen dann ebenso Lösungen entwickelt werden usw. Allerdings wurden eventuell schon zwei Lösungswege für ein- und dasselbe Problem formuliert und implementiert. Die Chance ist groß, dass es noch eine dritte Gruppe von Spezialfällen gibt. Ohne das grundsätzliche Problem ausreichend generisch zu formulieren, wird sich das Problem dadurch nicht nachhaltig lösen lassen. Zusätzlich erfordert die Toolimplementierung eine Auseinandersetzung mit den grundlegenden Konzepten, andernfalls wird ein Problem individuell gelöst, obwohl bereits eine anders angewendete Lösung für ein ähnliches Problem existiert.

Die klassische Aussage „A fool with a tool is still a fool“ unterstreicht plakativ den Fakt, dass ein oft angepriesenes IT-Tool für eine Aufgabenstellung organisatorischen Charakters in den meisten Fällen wenig bis gar keine positiven Effekte hat. Mitunter wird vor dem eigentlichen Problem kapituliert und mit Statements á la „Mit dem Tool können wir das dann sehr leicht elektronisch abbilden“ die Erwartungshaltung nach oben geschraubt. Wenn das Problem selbst gar nicht bei der IT-Unterstützung liegt, kann eine Adaptierung der IT-Unterstützung des Geschäftsprozesses hier gar keine Linderung bieten. Ähnliches gilt für das Upgrade von bestehenden Applikationen oder Systemen auf eine neue Version mit neuen Funktionen und Möglichkeiten. Hart formuliert: Auch Papier und Bleistift ist ein Tool und in vielen Fällen kein schlechtes. Der Prozess dahinter bildet für das Tool das Fundament, und dieser muss durchdacht und konsistent genug für den nachfolgenden Aufbau sein.

Partners

Bei Projekten, bei denen eine Optimierung der internen Abläufe einer IT verfolgt wird, müssen auch Lieferantenbeziehungen berücksichtigt werden. Wird beispielsweise Software von einem Lieferanten bezogen, so muss im Sinne eines geordneten Change Managements großes Augenmerk auf Schnittstellen zwischen den internen Abläufen und den Prozessen des Lieferanten gelegt werden. Oftmals wird den Lieferanten zu viel Spielraum gelassen um eine vermeintliche Flexibilität zu erhalten. Die Angst, mit einem zu großen Bürokratismus nicht rasch genug auf Änderungswünsche reagieren zu können, verleitet Projekt- oder sogar IT-Leiter dazu, Fremdfirmen einen zu großen Einfluss auf das interne Änderungswesen nehmen zu lassen. Unternehmensfremden Softwareentwicklern wird dabei beispielsweise erlaubt, Änderungen der Software direkt, ohne Tests auf produktiven Anwendungsservern, durchzuführen. Die Wahrscheinlichkeit ist sehr hoch, dass es dabei zu Fehlern und damit massiven Auswirkungen auf den Betrieb der Anwendung kommt. Als Folge kann es sogar zu einem kompletten Stillstand eines Geschäftsprozesses und damit finanziellen Verlusten des Unternehmens kommen. Als anderes Beispiel kann angeführt werden, dass bei der Umsetzung von Änderungswünschen die konzeptuelle Verantwortung oft an die Entwicklungsfirma „abgetreten“ wird. Bei der konzeptuellen Verantwortung kommt es darauf an, die technische Umsetzung der fachlichen Anforderungen zu überwachen und in Hinblick auf spätere Erweiterbarkeit zu steuern. Wenn die Kontrolle der konzeptuellen Umsetzung fehlt, kann eine künftige Erweiterung oder der Umstieg auf eine neue Technologie stark beeinträchtigt oder im schlimmsten Fall unmöglich gemacht werden. Bei der Auswahl neuer Partner sollte immer darauf geachtet werden, ob die Lieferantenfirmen selbst IT Service Management etabliert haben. Das Einfordern einer Dokumentation des Change Management Prozesses und seiner Schnittstellen des Lieferanten sollte einer der ersten Schritte bei der Auswahl eines neuen Partners sein. Aufschluss darüber, ob eine Partnerfirma strukturiert arbeitet, liefert auch die Art und Weise, wie Projekte geplant, dokumentiert und abgewickelt werden.

Die Prozessreife der Partnerfirmen kann direkten Einfluss auf den Erfolg der Einführung von IT-Governance in einem Unternehmen haben. Noch so gut gestaltete IT Service Management Prozesse des eigenen Unternehmens werden ineffektiv und können kostenintensiv werden, wenn die Schnittstellen zu den Prozessen der Partnerunternehmen nicht richtig definiert oder nicht bekannt sind.

Wiederholungsaufgaben

1. Nennen und beschreiben Sie kurz die vier Dimensionen, die bei der Einführung von IT-Governance beachtet werden müssen.
2. Welche Anforderungen werden an die Definition und Ermittlung eines Geschäftsprozesses gestellt?
3. Welche Gefahren für einen Geschäftsprozess können bei der Unterstützung durch IT-Tools auftreten?
4. Was ist für den Erfolg von IT-Governance Projekten in Hinblick auf beteiligte Personen und Akteure zu beachten?
5. Welche Rolle spielen Lieferantenfirmen bei IT-Governance Projekten und was ist bei der Prozessgestaltung in Hinblick auf Partnerfirmen zu beachten?

Lösungen

Nennen und beschreiben Sie kurz die vier Dimensionen, die bei der Einführung von IT Business Alignment beachtet werden müssen.

Processes, Products, People, Partners

In der Dimension „Processes“ werden Geschäftsprozesse, deren Ermittlung und Definition behandelt. Die zweite Dimension „Products“ behandelt Softwarewerkzeuge (IT Tools) zur Unterstützung der Geschäftsprozesse. In der Dimension „People“ werden die betroffenen Mitarbeiter betrachtet. Die Dimension „Partners“ zielt auf Lieferanten und andere Partnerunternehmen ab.

Welche Anforderungen werden an die Definition und Ermittlung eines Geschäftsprozesses gestellt?

Ein Geschäftsprozess muss klar definiert und eindeutig an den strategischen Zielen ausgerichtet sein, wobei vor allem der Bedarf der Stakeholder berücksichtigt werden muss. Die Verantwortlichkeiten für die Durchführung der einzelnen Prozessschritte sollen genau festgelegt werden, wobei die Anzahl der involvierten Rollen und Akteure so groß wie nötig und so klein wie möglich sein sollte. Ganz wesentlich ist es zudem, den Informationsbedarf pro Prozessschritt zu ermitteln, diese zentral zusammenzuführen und verwertbar zu machen.

Welche Gefahren für einen Geschäftsprozess können bei der Unterstützung durch IT-Tools auftreten?

Generell sollte der Ansatz verfolgt werden, das IT-Tool an den zu unterstützenden Prozess anzupassen und nicht umgekehrt. Das gilt vor allem bei standardisierter Software „von der Stange“. Werden Geschäftsprozesse „verbogen“, um ein bestimmtes Tool verwenden zu können, können diese Prozesse ineffizient und kostenintensiv werden. Darüber hinaus kann die Anpassung des Prozesses an das Softwarewerkzeug in eine Inflexibilität gegenüber Kundenbedürfnissen resultieren.

Was ist für den Erfolg von IT-Governance Projekten in Hinblick auf beteiligte Personen und Akteure zu beachten?

Bei vielen Projekten, die eine Änderung der Organisation bewirken, kommt der Akzeptanz der beteiligten Akteure für die durchzuführenden Maßnahmen eine große Bedeutung zu. Aufgrund der erzeugten Dynamik in der Stimmungslage kommen bei solchen Projekten der Management Awareness und dem Projektmarketing eine wichtige Rolle zu. Das Top Management sollte symbolisch wichtige Zeichen setzen, beispielsweise indem das Projekt durch den CEO auf Veranstaltungen erwähnt wird und ausgedrückt wird, dass das Thema von entsprechender Wichtigkeit ist. Darauf aufbauend muss die Projektleitung eine „Koalition der Willigen“ suchen, wodurch deren unmittelbare Kollegen positiv mit den IT Business Alignment Projekten in Berührung kommen. Gegner und Unkenrufer können aufgrund der entstehenden Gruppendynamik und positiven Grundstimmung zu einer konstruktiven Mitarbeit im Projekt bewegt werden. Es ist wichtig, alle nötigen Wissensträger von Beginn an in das Projekt einzubinden und konstruktive Kritik zuzulassen, um zu vermeiden, dass nicht beachtete Akteure das gesamte Projekt atmosphärisch bei den Kollegen diskreditieren.

Welche Rolle spielen Lieferantenfirmen bei IT-Governance Projekten und was ist bei der Prozessgestaltung in Hinblick auf Partnerfirmen zu beachten?

Die Schnittstellen zwischen unternehmensinternen Abläufen und den Prozessen des Lieferanten- oder Partnerfirmen stellen einen Erfolgsfaktor für IT-Governance Projekten dar.

Noch so gut gestaltete IT Service Management Prozesse des eigenen Unternehmens werden ineffektiv und können kostenintensiv werden, wenn die Schnittstellen zu den Prozessen der Partnerunternehmen nicht richtig definiert oder nicht bekannt sind. Bei der Auswahl neuer Partner sollte daher immer darauf geachtet werden, ob die Lieferantenfirmen selbst IT Service Management etabliert haben. Das Einfordern einer Dokumentation des Change Management Prozesses und seiner Schnittstellen des Lieferanten sollte einer der ersten Schritte bei der Auswahl eines neuen Partners sein. Aufschluss darüber, ob eine Partnerfirma strukturiert arbeitet, liefert auch die Art und Weise, wie Projekte geplant, dokumentiert und abgewickelt werden.