Wo es bei ERP-Einführungen hakt

09.01.2008
Von Reiner Martin
Methoden und Werkzeuge werden nicht konsequent genutzt - häufig aufgrund von Stillhalteabkommen zwischen Anbieter und Anwender.

Alle fünf bis 15 Jahre führen Unternehmen ein neues ERP-System ein. Dabei nehmen sie oft ERP-Anbieter oder -Einführungspartner in Anspruch. Diese verwenden dafür spezielle Methoden und Werkzeuge. Mit deren Qualität befasste sich das unabhängige Beratungsunternehmen MQ Result Consulting AG in Kooperation mit der Hochschule für Technik, Wirtschaft und Gestaltung Konstanz.

Der erste Teil der Studie wurde in der computerwoche-Ausgabe 17/06 (www.computerwoche.de/576955) vorgestellt. Der zweite sollte nun klären, wie die Methoden und Werkzeuge das ERP-Projekt-Management in der Praxis prägen. Hierzu wurden zunächst Projektleiter von 16 ERP-Anbietern interviewt. Sie benannten jeweils zwei Kundenprojekte, deren Leiter auf Anwenderseite ebenso ausführlich befragt wurden.

Taugen Anbieter als Prozessberater?

Wie die Erhebung zeigt, nutzen die Anwenderunternehmen die angebotenen Methoden und Werkzeuge selten. Damit sind sie auf die Unterstützung des ERP-Anbieters bei der Prozessmodellierung angewiesen. Doch ein Hersteller wird nur Lösungen vorschlagen, die mit seinem System im Rahmen der vereinbarten Dienstleistungen zu realisieren sind. Zudem mangelt es den Softwarehäusern oft an Prozess-Know-how.

Geschäftsprozesse werden laut Studie nur dann verbessert, wenn die Geschäftsführung dies explizit einfordert. Hilfreich ist es, wenn das Anwenderunternehmen einen unabhängigen Berater hinzuzieht. So lassen sich bereits vor der Systemauswahl die Sollprozesse beschreiben, die den Maßstab für die Beurteilung der Software bilden.

Der ERP-Anbieter sollte sich in der Feinkonzeption darauf konzentrieren, so konkret wie möglich zu definieren, wie er die Sollprozesse mit seinem System umsetzen kann. Dabei helfen Referenzprozesse, an denen sich das Projektteam orientieren kann.

Die Referenzprozesse bleiben außen vor

Anbieter und Anwender haben in Sachen Prozessverständnis unterschiedliche Wahrnehmungen. So gaben 80 Prozent der Projektleiter von Softwarefirmen an, Referenzprozesse zu verwenden, doch die Anwenderseite bestätigte das längst nicht in jedem Fall.

Meist liegen Referenzprozesse nur für wenige Abläufe vor - und zudem in ungeeigneter Detaillierung. Manchmal wird auch nur ein Modellierungswerkzeug, beispielsweise Visio, vorgehalten. Eine Prozessmodellierung, bei der lediglich die Modellierungskonventionen und Objekte verfügbar sind, überfordert aber Abstraktionsvermögen sowie Zeit- und Kostenbudget der meisten Kunden.

Auch in der Projektdokumenten-Verwaltung schlummern Verbesserungspotenziale. Nur selten machen die Projektleiter auf der Anwenderseite davon Gebrauch - und wenn, dann halbherzig. Es reicht aber nicht, auf einem File-Server eine Projektordnerstruktur einzurichten. Vielmehr bedarf es eines Dokumenten-Management-Systems, das Versionierung, Sperrung von bearbeiteten Dokumenten und automatische Benachrichtigung bei bestimmten Änderungen erlaubt. Ferner sollten alle Projektteilnehmer einfach auf Inhalte zugreifen können, was eine Web-basierende Lösung nahelegt.

Für die Kostenüberwachung bei der ERP-Einführung nutzen Anbieter- und Anwenderprojektleitung meist ganz unterschiedliche Werkzeuge. Alle interviewten Projektleiter auf der Anbieterseite setzen Software ein, um die Kosten im Blick zu behalten. Das Softwarehaus überwacht aber in der Regel nur die eigenen Kosten, für die Kundensicht fühlt es sich nicht verantwortlich.

Eine integrierte Kostenüberwachung gibt es praktisch nicht. Meist erfassen die Anbieter die Kostendaten mehrfach. Für die Fakturierung müssen sie die Angaben dann nochmals gesondert zusammentragen.

So sind die Kostendaten für den Kunden erst mit dem Rechnungserhalt einsehbar. Um die Forderungen zu prüfen, muss er die Kosteninformationen wieder in sein eigenes Projektkosten-Überwachungssystem eingeben. Ein zentrales integriertes Web-basierendes Projekt-Management-Werkzeug wäre eine sinnvolle Alternative.

Die heimlichen Stillhalteabkommen

Wegen der vielfältigen Diskrepanzen sollten die Projektleiter der Auftraggeber eigentlich unzufrieden sein. Aber die Interviews bestätigten das nicht.

entsteht zwischen den Projektleitern auf Anbieter- und Anwenderseite ein unbewusstes Stillhalteabkommen: Möglicherweise wollen beide Parteien sich nicht durch ein konsequentes Bekenntnis zu Methoden und Werkzeugen selbst unter Erfolgsdruck setzen. (fn)