IT Governance für die bimodale IT

Die bimodale IT, auch als "IT der zwei Geschwindigkeiten" bezeichnet, wird seit geraumer Zeit in Veröffentlichungen beschrieben und in der Praxis in einer zunehmenden Zahl an Firmen umgesetzt. Der Kern dieser neuen Art von IT ist der Aufbau und die Verwaltung von kundenorientierten IT-Systemen in einer sogenannten vertikalen IT, die neben der klassischen Corporate IT existiert.

Dieser Teil der IT hat somit (End-)Kundenkontakt und ist damit den Leistungsprozessen und nicht den Supportprozessen zuzuordnen.

Die aktuellen Veröffentlichungen beziehen sich bisher nur auf einen kleinen Teil der IT Governance, die IT-Organisation, und drehen sich um die Frage, wie viel organisatorische Unabhängigkeit dieser Teil der IT haben muss. Die Autoren sind sich einig, dass es Änderungsbedarf an den bestehenden IT-Governance-Strukturen gibt, um den kundenorientierten Teil der IT (Vertical IT) zielgerichtet zu unterstützen. Es werden aber keine Aussagen gemacht, an welchen Stellen und wie weit diese Abweichungen gehen können, sollen oder müssen.

Das "House of IT Governance"

IT Governance besteht im Sinne dieser Überlegungen aus folgenden Bereichen und ist als House of IT Governance visualisiert:

Zu den Bestandteilen dieses Hauses gehören:

• die IT-Organisation als Basis

• das IT-Service-Management

• das IT-Projektmanagement

• Informationssicherheit

• IT-Strategie & IT-Architektur

• Effizienz & Controlling

Sieht man sich die Bestandteile der IT Governance an, so wird klar, dass es nur in einigen Teilen Abweichungen geben darf, und dass in anderen Bereichen die bestehenden Vorgaben, Methoden und Prozesse für beide Teile der IT gelten müssen. Dabei ist die Grundvorgabe für alle Überlegungen, nur dort von den bestehenden Methoden, Tools und Prozessen abzuweichen, wo es tatsächlich nötig ist, entweder um dem abweichenden Geschäftsauftrag der Vertical IT Rechnung zu tragen, oder um die kulturellen und organisatorischen Besonderheiten gegenüber der klassischen IT zu unterstützen. Heißt das nun, dass die Vertical IT als eine eigene organisatorische Einheit im Organigramm verankert werden muss?

Eigenständigkeit der Vertical IT kann IT Governance gefährden

Es kann in manchen Fällen durchaus Sinn machen, die digitalen Kundensysteme aus einer eigenen organisatorischen Einheit betreuen zu lassen. Im Wesentlichen um das Geschäft, ähnlich einem Inkubator bei Startups, auf eine möglichst freie und eigenständige Art und Weise aufzubauen. Die Gefahr dabei ist aber, dass diese Freiheit zu weit interpretiert und gelebt wird, und damit auch die gesetzlich oder regulatorisch notwendige Governance nicht mehr adäquat umgesetzt werden kann.

Im entgegengesetzten Fall, also der Abbildung der Vertical IT innerhalb der bestehenden IT-Organisation, kann es dagegen passieren, dass die eigentlich akzeptierten Abweichungen zu den Standard-IT-Governance-Verfahren nicht genutzt werden, weil die internen Beharrungskräfte zu groß sind.

Eine allgemeingültige Empfehlung für die eine oder andere Organisationsform lässt sich nicht aussprechen, es sind immer die spezifischen Bedingungen des betrachteten Unternehmens zu berücksichtigen. An folgenden Stellen der IT Governance sind erfahrungsgemäß Abweichungen zu erwarten, zu akzeptieren und für das eigene Unternehmen im Detail auszugestalten:

• Die Ziele einer Vertical IT sind meistens grundlegend andere als die der Corporate IT. Steht in den klassischen IT-Domänen Infrastruktur und ERP meist die Stabilität der Systeme im Mittelpunkt, sind in den kundenorientierten Systemen die wesentlichen Erfolgsfaktoren Flexibilität und Geschwindigkeit in der Umsetzung von Anforderungen. Dies wirkt sich auf viele Bereiche der IT Governance aus.

• In der Portfolioplanung sind oft als kurzfristige Reaktion auf neue Markgegebenheiten oder Änderungen im Kundenverhalten Korrekturen notwending, die nicht vorhersehbar waren oder mit einem Business Case belegbar sind.

• Agile Projektmethoden müssen als Alternative zum klassischen Wasserfallmodell akzeptiert und etabliert werden. Neben der Aufnahme dieser Projekte in das Reporting bedeutet dies auch, dass es einen Product Owner gibt, der an den etablierten Entscheidungsgremien vorbei eigenständig und eigenverantwortlich die inhaltliche Ausrichtung der Weiterentwicklung bestimmt, solange sie keine Auswirkung auf die grundsätzliche Architektur oder Schnittstellen zu den klassischen IT-Domänen hat.

• In den IT-Prozessen werden ebenfalls Änderungen gegenüber den klassischen Vorgehensweisen nötig. Im IT-Support muss plötzlich der bestehende Customer Service oder ein externes Call Center als 1st Level Support und lokale Ansprechpartner bzw. Administratoren als Key-User oder sogar 2nd Level Support eingebunden werden. Auch im Release-Management gibt es oft unterschiedliche Anforderungen. Während für die klassischen IT-Systeme oft ein etablierter Release-Zyklus mit monatlichen oder noch selteneren Deployments existiert, werden Änderungen in den neuen Systemen meist mindestens wöchentlich, bei hoch frequentierten Online-Services teilweise mehrmals täglich deployed.

• Das Change-Management übernimmt in der vertikalen IT oft vollständig die Implementierung von Neuerungen vom Projektmanagementprozess. In der klassischen IT werden einzelne große oder eine größere Anzahl kleinerer Change Requests im selben Funktionsbereich oft in einem Projekt gebündelt. Dies macht mit Hinblick auf die Oberziele Stabilität und Kosteneffizienz auch absolut Sinn. In der vertikalen IT wird eher der entgegengesetzte Weg beschritten, große Änderungen in möglichst kleine Teile zu zerlegen, diese dann kontinuierlich zu entwickeln und zu deployen, um den Kunden Änderungen möglichst schnell zugänglich zu machen und dabei aber keinen zu großen Versionssprung zu haben, der die Nutzer überfordert.

• Budgetplanung und Controlling finden aufgrund der abweichenden Zielsetzung und unterschiedlichen Ausprägung von Projekt- und Change-Management in veränderter Form statt. Meist wird ein Budget bereitgestellt, und der Product Owner ist dafür verantwortlich, dieses optimal für das Unternehmen einzusetzen. Ob er einzelne große Projekte oder kontinuierliche Verbesserung aus dem Budget heraus finanziert, liegt dann in seinem Ermessen. Wichtig ist nur, dass am Jahresende der Maßnahmen-Mix den geplanten positiven Beitrag zur Geschäftsentwicklung gebracht hat. Welche der Maßnahmen dabei die „Killer-Applikation“ war, lässt sich meist im Nachhinein nicht mehr feststellen.
  Auch die Zuordnung des Budgets ist ein ewiger Quell für Diskussionen zwischen IT und Fachbereichen, zum Beispiel bei einem SEO-Projekt, wie es wahrscheinlich aktuell tausende gibt: Das Ausliefern von aktuellen Sitemaps und von Meta-Tag-Informationen ist Teil der IT-Verantwortung, die Bereitstellung des Contents für diese Meta-Tags dagegen nicht. Eine Zuordnung der Aktivitäten im Projekt zu diesen Bereichen ist aber meist nur grob möglich und mit entsprechendem Aufwand verbunden. Hier muss also eine Lösung gefunden werden, wie sich die Budgets zusammensetzen, ohne einen zusätzlichen Controlling-Overhead zu schaffen.

• Die Werkzeuge im Supplier-Management unterscheiden sich ebenfalls von den klassischen Vorgehensweisen. Die Partner für die -igitalen Kundensysteme sind meist nicht die Preferred Supplier der IT, sondern oft kleinere oder spezialisierte Agenturen, die nicht über ein ausgeprägtes Service-Management verfügen. Die Zusammenarbeit mit diesen Partnern unterscheidet sich fundamental, sie ist meist viel direkter als im klassischen Outsourcing von Projekten, vor allem weil die agilen Projektmethoden von Interaktion und Iteration geprägt sind. Daher ist es notwendig, die Prozesse anzupassen, in dem zum Beispiel das Reporting des Lieferanten reduziert wird, wenn im Gegenzug ein Kundenvertreter an den Daily Standups teilnimmt und dort die aktuellen Themen direkt aus erster Hand erfährt und nicht erst am Monatsende.

Fazit

Die herkömmlichen Methoden der IT Governance sind nur teilweise für die Vertical IT geeignet. Es sind Anpassungen nötig, um die Spezifika dieser kundenorientierten Systeme zu berücksichtigen wie direkte Konkurrenz und Vergleichbarkeit mit Wettbewerbern, Trends im Online-Geschäft, Geschwindigkeit und Flexibilität bei der Anpassung.

Bei allen regulatorischen oder gesetzlichen Vorgaben wie beim Risikomanagement, beim internen Kontrollsystem, oder bei IT-Strategie und IT-Architektur oder auch bei den IT-Regularien muss dagegen darauf geachtet werden, keine Unterschiede in der Umsetzung zuzulassen.