IT Governance für die bimodale IT

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.