Zuständigkeit im ERP-Projekt per RACI-Matrix definieren

ERP-Einführungsprojekte gelingen auf dem sicheren Fundament eines Projektvertrages. Das Anwenderunternehmen, Kunde oder rechtlich gesehen Auftraggeber, und der ERP-Anbieter als Auftragnehmer dokumentieren darin ein gemeinsames Verständnis aller wesentlichen Aspekte des Projektes. Eine detaillierte Beschreibung des Project Scopes muss um eine Beschreibung der Aufgaben und Verantwortlichkeiten ergänzt werden. Dies gilt unabhängig von der gewählten Vertragsart. Bei einem Werkvertrag kann der ERP-Anbieter sogar Schadenersatz verlangen, falls der Kunde seinen Mitwirkungspflichten nicht nachkommt. Doch auch ein Dienstleistungsvertrag muss die Mitwirkungsleistungen möglichst genau festlegen, denn die eindeutige Beschreibung von Aufgaben und Verantwortlichkeiten beeinflusst erheblich den Projekterfolg.

Die RACI-Matrix

Hier kommt die RACI-Matrix ins Spiel – ein gängiges Werkzeug aus dem Projektmanagement. Responsible, Accountable, Consulted und Informed sind die vier Ausprägungen, die in einer Matrix aus Aufgaben (in Zeilen) und Rollen (in Spalten) vergeben werden. Dieses RACI-Chart lässt sich im Vertrag abbilden und im Projektverlauf einfach überwachen. Doch wann und wie wendet man dieses Tool erfolgreich an? Welche Falltüren tun sich auf, wenn Anbieter ihre Vorgaben durchsetzen? Was muss ein Projektleiter zur Anwendung wissen? Die Berater von MQ Result Consulting haben aus ihrer Erfahrung mit der RACI-Matrix bei einer ganzen Reihe von ERP-Einführungen zahlreiche Dos und Don´ts gesammelt, die in folgenden Artikel eingeflossen sind.

Der richtige Zeitpunkt

Anwender erliegen häufig der Versuchung, sich erst nach negativen Projekterfahrungen mit der anspruchsvollen Matrix zu beschäftigen. Doch diese sollte dringend abgestimmt werden, bevor die eigentliche Projektarbeit beginnt. Denn die Einhaltung der in der RACI-Matrix beschriebenen Verantwortlichkeiten ist für das Funktionieren des ERP-Projektes elementar. Dies bedeutet, dass die Matrix unbedingt Bestandteil des ERP-Projektvertrages sein muss, um den Verbindlichkeitscharakter zu manifestieren und sicher zu stellen, dass die definierten Verantwortlichkeiten von Anfang an ausgeführt werden und die Zusammenarbeit im ERP-Projekt zufriedenstellend funktioniert.

Die Matrix muss während der Projektvorbereitung aufgestellt werden, damit sie Bestandteil des Projektvertrages werden kann.

In drei Schritten zur RACI-Matrix

Mithilfe der RACI-Matrix werden die Mitwirkungsleistungen mit konkretem Bezug zu den Projektaktivitäten beschrieben, so dass sie in der zeitlichen Planung des Projektes entsprechend berücksichtigt werden. Bezogen auf die Erstellung der RACI-Matrix sind nach Lehrbuch die folgenden drei Schritte zu durchlaufen:

• alle wichtigen Aktivitäten des Projektes anführen (Zeilen der Matrix),
• die Rollen im Projekt festlegen (Spalten)
• und in den Zellen der Matrix die jeweiligen Verantwortlichkeiten bestimmen.

Dieses Lehrbuchvorgehen stößt bereits bei Schritt Eins im ERP-Projekt an seine Grenzen. Meist nur mit großer ERP-Projekterfahrung lassen sich alle Projektaktivitäten, die eine Regelung der Verantwortlichkeiten erfordern, identifizieren. Es kommen schnell über 100 bis 250 Aktivitäten, sprich Tabellenzeilen zusammen.

Das Trojanische Pferd des Anbieters

Daher ist es in ERP-Projekten üblich, dass der Systemanbieter bereits über eine Referenz-Matrix verfügt. Schließlich müssen die hier aufgeführten Projektaktivitäten exakt mit der grundsätzlichen Projektmethodik, die der Anbieter anwendet, korrelieren. Verfügen die Integratoren über keine fundierte RACI-Matrix, was durchaus noch vorkommt, stellt dies dessen Projektmethoden-Kompetenz massiv in Frage. Anbieter- und Anwenderunternehmen können die RACI-Matrix gleich abstimmen, da der Anbieter in seiner Vorlage bereits die drei Lehrbuchschritte absolviert hat. Doch Vorsicht aus Sicht des Anwenderunternehmens – wer schreibt der bleibt! Das soll verdeutlichen, dass die ERP-Anbieter mit ihren RACI-Vorlagen legitimerweise insbesondere ihre Interessen umgesetzt haben. Auf der Kundenseite fehlt meist die ERP-Projekterfahrung, um die darin für sie enthaltenen Gefahren zu erkennen – und diese lauern bei allen drei Dimensionen der RACI-Matrix.

Gefahren bei der Aufgabenbeschreibung

Bei der ersten Dimension, der Beschreibung der Aufgaben in den Tabellenzeilen, kann der Anbieter seine Interessen durch unterschiedliche Detaillierung verfolgen. Etwa durch exakte, detaillierte Aufgabenbeschreibungen dort, wo es in seinem Interesse ist und das Umgekehrte bei Aufgaben, die dem Anwenderinteresse dienen. Konkretes Beispiel aus dem Bereich Modifikationen: Oft fehlt hier die Aufgabe ‚Entwicklungsdokumentation erstellen‘. Klar, wem ist schonmal ein Softwareentwickler begegnet, der freiwillig seine Entwicklung dokumentiert?

Gefahren bei den Projektrollen

In der zweiten Dimension Projektrollen (in den Spalten) setzt sich dies fort. Meist unterscheiden die ERP-Anbieter zwei Gruppen ‚Anbieter‘ und ‚Anwender‘, also das Produktionsunternehmen. Eine dritte Gruppe existiert üblicherweise nicht. Schließlich hat der Anbieter kein Interesse daran, dass im Projekt noch ein vom Anwender beauftragter unabhängiger ERP-Berater mitarbeitet, der beispielsweise in der Qualitätssicherung unterstützt. Bei der Detaillierung der Projektrollen ist Fingerspitzengefühl gefordert. Werden alle Rollen im Projekt schulbuchmäßig als Spalten geführt, kann das den Abstimmungsprozess überfrachten. Ist es nicht eher eine interne Angelegenheit des Anbieters, dass neben der Rolle ‚Projektleitung‘ noch ‚Developer‘, ‚Leadconsultant‘ und ‚Consultant‘ geführt werden? Intern kann sowohl auf Seiten des Anbieters als auch des Kunden eine weitere Detaillierung der Rollen erfolgen, die im Verlauf des Projektes für die eigenen Zwecke verfeinert wird. Doch in die RACI-Matrix des Projektvertrags gehört das nicht.

Gefahren bei den Verantwortlichkeiten

In der letzten Dimension der Verantwortlichkeiten lauern ebenfalls Falltüren für den Auftraggeber. Die vier Ausprägungen nach Lehrbuch werden oft auf zwei oder drei reduziert. Dies ist durchaus legitim, da es helfen kann den Abstimmungsprozess zwischen Anbieter und Kunde auf das Wesentliche zu konzentrieren. Es birgt allerdings auch Gefahren. So wird meistens bei den RACI-Vorlagen der ERP-Anbieter auf die Verantwortungsausprägung ‚I‘ (Informed) verzichtet, was sich negativ auf die Funktionsweise des Lenkungskreises im ERP-Projekt auswirken kann. Auch der Umgang mit den Verantwortungsausprägungen ‚R‘ (Responsible) und ‚A‘ (Accountable) kann Falltüren haben. Nach Lehrbuch wird die Verantwortungsausprägung ‚Responsible‘ der Projektrolle zugewiesen, die verantwortlich im Sinne von zuständig für die tatsächliche Ausführung der Aufgabe ist. ‚Accountable‘ steht für rechenschaftspflichtig und haftbar. Diese Projektrolle trägt die Verantwortung für eine Projektaufgabe und stellt sicher, dass die Arbeit erfolgreich abgeschlossen wird. Je Projektaufgabe muss es genau einen Accountable geben. Es ist legitim, wenn die ERP-Anbieter in ihren RACI-Vorlagen diese Rollen umdefinieren, solange dadurch keine Unschärfen entstehen. Wenn ein Anbieter aber eine Verantwortlichkeit ‚V‘ beschreibt als ‚ist verantwortlich für die korrekte Ausführung und führt die Aufgabe auch selber durch‘ ist das gleichbedeutend mit den Zuweisungen R und A zu einer Rolle, also eine zulässige Verdichtung. In einem anderen Beispiel spricht ein ERP-Anbieter von ‚D‘ Durchführender und ‚U‘ Unterstützender, lässt dabei allerdings offen, ob der Durchführende (Responsible) auch Verantwortlicher (Accountable) ist. Das sollte unbedingt klargestellt werden, bevor die Projektarbeit beginnt. Ansonsten sind Zwistigkeiten im Projektverlauf vorprogrammiert.

Der Nutzen der RACI-Matrix

Wurden diese Falltüren erfolgreich verriegelt, kann der Auftraggeber mit einer abgestimmten RACI-Matrix sehr fundiert prüfen, ob er die erforderlichen Mitwirkungsleistungen erbringen kann. Dies betrifft die zeitliche Verfügbarkeit von Ressourcen ebenso wie die erforderlichen Qualifikationen. Der Kunde kann prüfen, ob noch externe Unterstützung hinzugezogen werden sollte. Liegt eine abgestimmte RACI-Matrix vor, sollte diese dann im Projekt über das Projektportal allen Projektakteuren zugänglich sein und konsequent abgearbeitet werden – was leider in vielen ERP-Projekten nicht der Fall ist. Die RACI-Matrix kann somit zum zwingenden Element für eine Planung und Steuerung von ERP-Projekten werden. Schon um Streit im Projektverlauf zu vermeiden. Das gilt auch bei starkem Einsatz von agilen Projektmethoden. Positiv ist anzumerken, dass die ERP-Anbieter dies weitgehend erkannt haben und mit Ihren RACI-Vorlagen meist sehr gut aufgestellt sind. Auf Seiter der Produktionsbetriebe wird der Stellenwert jedoch eher unterschätzt. Hier muss man sich darüber bewusst sein, dass die Abstimmung der RACI-Matrix anspruchsvoll ist, entsprechend viel Zeit erfordert und enoerm von ERP-Projekterfahrung profitiert. So lassen sich Fragen auf Augenhöhe klären. Die Berater von MQ Result Consulting unterstützen auf Wunsch dabei.