Customizing einschränken

Wie Firmen ihre Softwareprojekte unter Kontrolle halten können

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 großen 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.

Bei großen 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.

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äßigen Fortschrittsberichte einfließen.

Und wie zügelt man den Systemintegrator? Viele Unternehmen finden das schwierig, weil die externen Spezialisten oft viel Erfahrung aus entsprechenden Großprojekten mitbringen und über einen Wissensvorsprung verfügen. Entscheidend ist, dass der Systemintegrator von Beginn an weiß, 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. (hv)