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ößer 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 außerhalb des Haupt-Implementierungsprozesses voranzutreiben.
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)