31.10.2014, 16:43 Uhr

Wie Firmen ihre Softwareprojekte unter Kontrolle halten können

Noch immer ufern grosse 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?
* Heinrich Vaske ist Chefredaktor unserer Schwesterpublikation «Computerwoche», in der der Artikel ursprnglich erschien. IT-Profis aus grossen Unternehmen kennen das Szenario: Ein komplexes, grosses 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 Grossprojekte 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 macht 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. Lesen Sie auf der nächsten Seite: diese Fehler machen Unternehmen immer wieder

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 gross 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: Grosse Transformationsprogramme gehen immer vom Business aus, doch allein kann es die Auswirkungen seiner Pläne nicht abschliessend 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.

Was können Unternehmen tun?

Entscheidend für den Erfolg von Standardsoftwareeinführungen ist die Vorarbeit. Es gilt eine Systematik zu entwickeln, mit der sich herausfinden lässt, welche Unternehmensprozesse und -funktionen wirklich wettbewerbsrelevant sind. Oft gibt es in Unternehmen keinen Konsens darüber. In diesen Fällen lässt sich auch nicht sagen, wo Customization sinnvoll ist. Tatsächlich ist diese Aufgabe nicht so einfach, wie sie vielleicht erscheint. Kompliziert wird es etwa, wenn bestimmte geschäftskritische Funktionen nur von einer kleinen Gruppe von Mitarbeitern, möglicherweise abhängig von Zeit und Region, benötigt werden - wenn also ein konzernweites Deployment keinen Sinn gibt. Unternehmen müssen in solchen Fällen festlegen, ob die hierfür anfallenden Arbeiten innerhalb des Kernprojekts behandelt oder separat designt und implementiert werden sollten. Wenn branchentypischen Kernanforderungen unterstützt werden sollen, etwa wenn es um E-Commerce für ein Handelsunternehmen geht, muss der Freiheitsgrad des Customizing grösser sein als anderswo. Das System sollte die Business-Anforderungen exakt abdecken. Trotzdem ist auch hier zu prüfen, wie Abweichungen vom Standard mit möglichst geringem Aufwand umzusetzen sind. Wichtige, aber nicht geschäftskritische Anwendungen wie zum Beispiel Finanzbuchhaltung oder Personal, sollten mit dem Standard abgebildet werden, es sei denn, es gibt einen zwingenden Business Case, der mit realistischen Zahlen unterfüttert ist. Diese Anpassungen müssen genau auf ihre Auswirkungen für die Gesamtkosten untersucht werden. Damit man so arbeiten kann, muss das Business in der Lage sein, den Business Case zur Bewertung solcher Anfragen schnell beizubringen. Es gibt auch Anforderungen, die erfüllt werden müssen, aber nur kleine Anwendergruppen in einem Randbereich des Business betreffen. Das können etwa Anforderungen sein, die aufgrund regionaler regulatorischer Vorgaben anfallen. Hier ist es sinnvoll, den Support unabhängig vom Hauptsystem einzurichten und die Entwicklung mit separatem Budget und ausserhalb des Haupt-Implementierungsprozesses voranzutreiben. Lesen Sie auf der nächsten Seite: Härte zeigen

Manchmal muss man Härte zeigen

Unnachgiebig sollten sich die Verantwortlichen geben, wenn es um Nice-to-have-Themen geht, um Prozesse also, die weder Business-Treiber noch global erforderlich sind. Das kann beispielsweise ein komplexer Report sein, den nur ein lokales Office will. Hier sollte der Standard verordnet und Customizing verboten werden. In diesen Bereich fallen besonders viele Kundenanforderungen. Wer hier streng bleibt, kann die Komplexität seines Systems reduzieren und die TCO senken. Es ist völlig normal, dass Abteilungsleiter im grossen Stil Änderungsanforderungen stellen und behaupten, dass diese absolut Business-relevant seien. Umso wichtiger ist es, starke Governance-Prozeduren zu haben, die solche Behauptungen prüfen und gegebenenfalls widerlegen können - auch unter Zeitdruck. Es ist also wichtig, eine Art Framework zu besitzen, das die entscheidenden Funktionen und Fähigkeiten des Unternehmens spiegelt, um daran orientiert die Customizing-Wünsche bewerten zu können. Ebenso geht es - ganz banal - darum, die Autorität der IT im Unternehmen zu stärken, Anwender von der Notwendigkeit standardisierter Prozesse zu überzeugen und den gewählten Systemintegrator an die kurze Leine zu nehmen.

IT braucht eine starke Rolle

Bei grossen IT-Projekten braucht die IT von Anfang an eine starke Rolle. Nur sie kann einen systemzentrischen Blick auf alle Geschäftsprozesse haben, die abgebildet werden sollen. So lässt sich sicherstellen, dass die nicht wettbewerbskritischen Prozesse ohne Abweichungen im Standard abgebildet werden, und dass über Veränderungen grundsätzlich gewacht wird. Wichtig für den Projekterfolg ist es zudem, von Anfang an die Anwender im Boot zu haben. Das Buy-in ist umso wichtiger, je weniger die implementierte Software im Kundensinne angepasst werden soll. Anwender wollen tendenziell immer an ihren Abläufen festhalten. Deshalb müssen die Business-Vorteile durch Standardisierung klar und für jedermann verständlich erklärt werden. Je enger die IT hier mit dem Business zusammenarbeitet, desto eher wird sie verstehen, welche Standards sie - zumutbar - durchsetzen kann. Sinnvoll ist es, gemeinsame Arbeitsgruppen aufzusetzen, um die Kernprozesse zu verstehen, Vereinfachungen vorschlagen zu können und den Hintergrund für Veränderungs- beziehungsweise Customizing-Wünsche zu begreifen. Prototypen für standardisierte Workflows können ein effektives Werkzeug sein, um die Diskussion zu lenken. Geht es um nichtkritische Unternehmensbereiche, ist aber zuweilen auch eine resolute Haltung angebracht, um die Vorteile durch Standardsoftware zu ernten.

Abteilungsleiter aufklären

Um das Projekt nicht ausufern zu lassen, sollte die IT zu Beginn deutlich machen, welches Verhältnis von Standardisierung und Customization sie generell für tolerabel hält. Eine detaillierte Kosten-Nutzen-Kalkulation hilft, Konsens zu schaffen und rahmensprengende Ausnahmen zu vermeiden. Abteilungsleiter, die besonders viele individuelle Anpassungen fordern, sollten aufgeklärt werden, Informationen darüber in die regelmässigen Fortschrittsberichte einfliessen. Und wie zügelt man den Systemintegrator? Viele Unternehmen finden das schwierig, weil die externen Spezialisten oft viel Erfahrung aus entsprechenden Grossprojekten mitbringen und über einen Wissensvorsprung verfügen. Entscheidend ist, dass der Systemintegrator von Beginn an weiss, welche Anforderungen kritisch sind, um das Projekt designen und implementieren zu können. Er sollte auf die ursprünglich ausgemachten Vereinbarungen festgelegt werden und hart bleiben, wenn Änderungswünsche aus Bereichen kommen, die nicht als wettbewerbskritisch identifiziert wurden. 


Das könnte Sie auch interessieren