Capabilities klassifizieren – Projekte scheitern am Customizing

Jede Abteilung will die Systeme genau auf ihre Abläufe angepasst haben. Doch die Analysten von Strategy& raten, sich diesen Wünschen vehementer zu verweigern. [...]

Geht es um den Grund für das Scheitern von Projekten, fallen schnell Stichworte wie Mangel an Geld, an Zeit oder Skills. Die Analysten von Strategy& thematisieren in ihrem Papier „Preventing complexity-drift – a capabilities-driven approach to IT program success“ etwa ganz anderes: zu viel Customisierung. Kurz: CIOs müssen aufhören, jede gewünschte System-Anpassung umzusetzen.

Als abschreckendes Beispiel berichtet Strategy& von einem Öl-Konzern, der ein neues ERP-System ausrollen wollte. Die IT hatte den klaren Auftrag, Anpassungen auf ein Minimum zu beschränken. Geschäftsführung und CIO setzten sich zusammen und identifizierten höchstens 300 Customisierungen, die sich auf spezielle Reportings oder Workflows bezogen. Soweit die Vereinbarung.

Am Schluss hatte die IT zehnmal so viele System-Anpassungen vorgenommen. Das Projekt sprengte den zeitlichen Rahmen um das Doppelte und den finanziellen um ein Vielfaches.
    
Strategy@ sieht die Ursache dafür in schwacher Governance. Vor allem aber hatten CIO und Geschäftsleitung nicht hinterfragt, welche der gewünschten Anpassungen sich überhaupt auf das Kerngeschäft des Unternehmens bezogen. Das galt nämlich nur für 39 Prozent der Anpassungen, wie sich im Rückblick herausstellte.

CORE-CAPABILITIES ODER NON-CORE-CAPABILITIES?
Diese Frage ist aber ganz entscheidend. Business und CIO müssen einen Rahmen festlegen. Auf der einen Achse geht es um die Business-Fertigkeiten. Beziehen sich diese auf das Kerngeschäft, also etwa das E-Commerce-System eines Handelskonzerns?

Oder handelt es sich um Non-Core-Capabilities wie beispielsweise Human Resources? Die andere Achse bildet die Art der Customisierungs-Anfrage. Diese kann sich auf gängige Prozesse beziehen, die von vielen Nutzern ausgeführt werden, oder auf sehr spezifische Abläufe mit wenigen Anwendern.

Ob der Customisierungswunsch umgesetzt wird, hängt weniger von der Art der Anfrage – also der Zahl der Nutzer – ab. Wichtiger ist die Klassifizierung als Core- oder Noncore-Capability. Wird der Ruf nach Anpassung gängiger Prozesse laut, die nicht das Kerngeschäft unterstützen, rät Strategy& zum Erstellen eines Business Case. Spezifische Anfragen, die nicht zum Kerngeschäft gehören, werden auch nicht umgesetzt. Solche, die zum Kerngeschäft zählen, schon – aber außerhalb des Programmrahmens.
    
4 RATSCHLÄGE: WIE MAN MIT CUSTOMIZING-WÜNSCHEN UMGEHT
Damit das in der Praxis funktioniert, nennt Strategy& vier Voraussetzungen:

• Die IT braucht Autorität: Die Analysten fordern einen „System-zentrischen“ Blick auf das gesamte Projekt. Damit spielt die IT eine starke Rolle.

• Verständnis für die Nutzer: Dass Endanwender gewohnte Abläufe ungern ändern, ist nur natürlich. Die IT muss ihnen erklären, warum bestimmte Änderungen nötig sind. Ein gutes Mittel ist es, den Nutzern Prototypen standardisierter Prozesse vorzustellen und Anregungen von ihnen einzuholen.

• Immer den Projektrahmen im Auge behalten: Die IT sollte Standardisierung und Customizierung regelmäßig überprüfen. Das Projekt soll zeitlich wie finanziell im Rahmen bleiben. Fällt ein Fachbereichsleiter durch übermäßig viele Customisierungsanfragen auf, gehört das ins Reporting.

• Die System-Integratoren einbeziehen: Es ist wichtig, dass die für die System-Integration Verantwortlichen den System-zentrischen Blick auf das Projekt übernehmen. Das muss der CIO sicherstellen.

Strategy& bezeichnet die Komplexität großer Projekte als „alten Teufel“. CIOs müssen ihn aber bändigen können – denn mit einem gescheiterten IT-Projekt können auch sie fallen.

*Christiane Pütter ist Redakteurin der cio.de