Wie Firmen ihre Softwareprojekte unter Kontrolle halten können

Noch immer ufern große Standardsoftware-Einführungen kostspielig aus, weil Customizing stattfindet, wo es nur Kosten, aber keinen Nutzen verursacht. Deshalb sind Hausaufgaben vorab wichtig: Was sind meine Kernprozesse? [...]

IT-Profis aus großen Unternehmen kennen das Szenario: Ein komplexes, großes Software- und Transformationsprojekt wird aufgesetzt, das viele Millionen Euro kostet. Monatelang arbeiten Business und IT Seite an Seite an den Spezifikationen, einigen sich auf Business-Ziele, Umfang, Kosten und Zeitrahmen. Sie engagieren einen Systemintegrator für Design und Implementierung. Um Komplexität und damit höhere Kosten zu verhindern, nehmen sie sich fest vor, eng am Standard zu bleiben.

Nach und nach reagieren die Anwender alarmiert und beginnen laut über die vermeintlichen Folgen der Softwareeinführung nachzudenken. Sie beginnen über die Spezifikationen zu diskutieren. Gravierende Veränderungen drohen. Die Angst wächst – und mit ihr Zahl der gewünschten Anpassungen. Oft steckt dahinter nichts anderes als der heimliche Wunsch, die gewohnte Arbeitsweise in die neue Softwarewelt hinüber zu retten.

Egal ob die Veränderungswünsche substanziell oder nur „nice to have“ sind: Sie beginnen sich zu häufen und erhöhen die Komplexität von Software und Einführungsprojekt. Termine werden überschritten, Budgets überzogen. Das Verhältnis von Business und IT, oftmals ohnehin belastet, verschlechtert sich weiter. Für CIOs ist das besonders riskant: Ihr Stuhl wackelt zuerst, wenn Großprojekte ins Schlingern geraten.

Wie Anwender an solche Projekte herangehen sollten, das haben Jens Niebuhr, Eduard Gracia und Abhishek Pathak untersucht. Die drei Manager von Strategy&, vormals Booz & Company, gehen in ihrer Analyse „Preventing complexity drift. A capabilities-driven approach to IT program success“ ins Detail.

WAS MACH DEN GESCHÄFTSERFOLG AUS?
Solche Projekte stehen und fallen demnach mit der Fähigkeit, Softwareanpassungen sinnvoll zu managen. Voraussetzung dafür ist ein klares gemeinsames Verständnis der Geschäftsstrategie und der Ziele, denen das neue System dienen soll. Es geht immer um die Fragen: Was ist wirklich erforderlich, damit das Unternehmen erfolgreich am Markt ist? Und welche Funktionen und Prozesse müssen dafür unterstützt werden? Erst wenn das allen klar ist, verfügen IT-Leiter über die richtigen Informationen, um das Projekt ausrichten und dimensionieren zu können.

Wer einen Anhaltspunkt haben möchte, ob ein laufendes Transformationsprojekt ausufert, sollte einmal die Zahl der von Anwendern gewünschten Modifikationen und Add-ons erheben, die das System in seinen Standardfunktionen nicht abbildet. Solche „Customizations“ sind nicht mit den gängigen Einstellungen und Konfigurationen zu verwechseln, die jedes System vorsieht und die keine Abkehr vom Standard bedeuten. Jede Customization erhöht ausnahmslos den Design- und Implementierungsaufwand, führt zu zusätzlicher Komplexität beim Testing und schafft neue Deployment-Risiken. Die Kosten vervielfachen sich über den gesamten Software-Lebenszyklus hinweg, zumal das System gepflegt und via Upgrades aktuell gehalten werden muss.

UNTERNEHMEN MACHEN HIER IMMER WIEDER FOLGENDE FEHLER:

• Festhalten an Legacy-Prozessen: Firmen, die lange mit demselben System gearbeitet haben, sind damit quasi verwachsen. Ihre Business-User haben verschlungene Pfade gefunden, wie sie arbeiten und Sonderfälle behandeln können. Selbst wenn ein neues System viel wertvoller für das Unternehmen wäre, stellen sich die Nutzer quer, denn sie müssten ganz neuen Prozessen folgen und lernen, ihre Arbeit anders zu verrichten. In solchen Fällen ist Opposition seitens der Anwender die Regel, oftmals fallen Business-Managern ihren IT-Kollegen sogar in den Rücken.

• Zu groß dimensioniert: Oft wollen IT und Business in Transformationsprogrammen alle Probleme auf einmal lösen. Einbezogene Power-User dürfen alle möglichen Anforderungen stellen, die ihren individuellen Interessen entsprechen. Die IT erliegt der Versuchung, sämtliche Stakeholder glücklich zu machen, was mit enormem Aufwand bezahlt wird.

• Schwache Design-Governance und fehlende Macht der IT: Große Transformationsprogramme gehen immer vom Business aus, doch allein kann es die Auswirkungen seiner Pläne nicht abschließend beurteilen. Es kann nicht abschätzen, was starke Customization für die Total Cost of Ownership (TCO) in einem solchen Projekt bedeutet. Nur wenige Unternehmen beschäftigen heute Design-Cracks, die Spezifikationswünsche fundiert steuern und das Maximum an Standardkonformität auf der Architekturebene herausholen. Oft haben die IT-Organisationen auch gar nicht das interne Standing, das nötig wäre, um die wachsende Zahl an Anforderungen einzudämmen.

• Der Integrator wird nicht gezügelt: Unternehmen unterschätzen oft den Interessenskonflikt, in dem sich der gewählte Systemintegrations-Partner befindet, der das System bauen und vielleicht auch langfristig pflegen soll. Seine Incentivierung richtet sich oft danach, ob die Anforderungen des Kunden zu 100 Prozent erfüllt sind, und nicht, ob die Komplexität noch beherrschbar ist.