Customizing einschränken

Wie Firmen ihre Softwareprojekte unter Kontrolle halten können

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.