Dieser Artikel möchte Ihnen eine kurze Einführung in verhaltensbasierte Denk- und Lösungsansätze bieten, um nachzuforschen warum es möglicherweise in einem (ERP-) Implementierungsprojekt hakt (und dass, obwohl Sie ein perfektes Projektmanagement aufgesetzt haben und eine dezidiertes Qualitätsmanagement betreiben), als auch einige Lösungsansätze bieten, um genau diese Herausforderungen kollaborativ zu lösen.

Im Fokus dieses Artikels steht also die Frage, wie ich (als Kunde) meinen ERP-Software-Implementierer (den Dienstleister) einvernehmlich steuere. Dem voran werden die Fragen diskutiert, warum und wann ein Dienstleister überhaupt gesteuert werden kann und muss.

Warum steuere ich meinen ERP-Implementierer?

Die platte Antwort lautet: „Damit er das liefert, was er soll und zwar in der Qualität die ich mir wünsche.“ Stellt sich also die Frage, ob der Dienstleister das nicht sowie macht, schließlich wurde ja alles vertraglich vereinbart… oder nicht?

Klar ist, dass nicht jedes Detail vertraglich geregelt werden kann. Das ergibt sich allein schon aus der schlichten Tatsache, dass das aufgrund des ernorm hohen Aufwands nicht möglich ist (und oft auch nicht sinnvoll). Daraus ergibt sich also eine gewisse „Unschärfe“ in der Lieferung. Diese „Unschärfe“ ist die Diskrepanz zwischen der Erwartung eines Kunden und der tatsächlichen Lieferung eines Dienstleisters. Das bezieht sich auf alle Lieferdimensionen: Inhalt, Qualität, Zeit und Budget. Wobei die letzteren beiden Punkte (vor allem der letzte) meist vertraglich recht klar geregelt sind. In der Praxis zeigt sich, dass auf Grund dessen tendenziell die ersten beiden Punkte (Inhalt und Qualität) leiden.

Ziel einer einvernehmlichen Steuerung ist in den Bereichen Inhalt und Qualität diese „Unschärfe“ rechtzeitig erkennen und die daraus entstehenden Konflikte gemeinsam zu lösen.

Wann steuere ich meinen ERP-Implementierer?

Ganz einfach: Vom ersten bis zum letzten Tag, an dem der Dienstleister tätig ist. Das beginnt bei der Anforderungsdefinition oder den Antworten auf die Ausschreibung über die Implementierungsphase bis hin zum Go-Live und auch in die spätere Support-Zeit. Konflikte auf Grund o.g. „Unschärfe“ zwischen Erwartung und Erfüllung werden Sie immer finden.

Wie steuere ich meinen ERP-Implementierer?

Diese Frage ist jetzt nicht mehr so klar zu beantworten. Der typische Berater würde wohl sagen: „Das kommt ganz darauf an…“

… denn Sie sollten zunächst klären, wo die Ursache des Problems (sprich: des Konfliktes) liegt. Diese ist nicht immer eindeutig: Von den Symptomen (verspätete Lieferung, mangelnde Qualität, etc.) kann man nicht immer auf die Ursachen und somit auch nicht auf die angemessene Lösung schließen.

Die folgenden zwei Schritte werden Ihnen hier ein paar Ideen und Lösungsansätze an die Hand geben:

Schritt 1: Finden Sie die Ursache

Abgesehen von den anfangs genannten Praxiserfahrungen, sollten Sie sich zunächst vor Augen halten, dass der Dienstleister normalerweise Ihre Erwartungen erfüllen will. Er möchte natürlich, dass Sie mit seinen Leistungen und Lieferungen hochzufrieden sind. Schließlich möchte er weiterhin mit Ihnen Geschäfte machen und ist besonders im mittelständischen ERP-Bereich auf Ihre Empfehlungen und Referenz angewiesen. In einer optimistisch-positiven Grundhaltung sollte man also immer davon ausgehen, dass kein Dienstleister „schlecht“ liefern will.

Wenn die Erwartungen dennoch nicht erfüllt werden, kann dies verschiedene Gründe haben, die Sie erforschen sollten. Ansonsten ziehen Sie u.U. falsche Schlüsse und die angewendete Steuermethodik greift nicht.

Hier ein paar typische Gründe, warum Ihre Erwartungen (also die des Kunden) nicht (voll) erfüllt werden:

• Die Kundenerwartungen wurden nicht klar genug, nicht detailliert genug oder unvollständig kommuniziert.
• Die Kundenerwartungen wurden falsch oder anders verstanden, als sie gemeint waren.
• Der Kunde hat implizite Annahmen, die in seinem Tagesgeschäft selbstverständlich sind – für den Lieferanten jedoch abwegig (oder umgekehrt).
• Beim Dienstleister mangelt es an fachlichem Know-how zum Verständnis der Anforderungen (oder dem Kunden das zur klaren Formulierung).
• Beim Dienstleister mangelt es an technischem Know-how oder der Kreativität zur zufriedenstellenden Umsetzung der Anforderungen.
• Dem Dienstleister mangelt die Methodik und/oder des Wissen zum Know-how Transfer (z.B. vom eigenen fachlichen Experten zum technischen Entwickler).
• Dem Dienstleister mangelt es an Methodik und/oder Wissen zum Prüfen seiner Lieferqualität und/oder seiner Entwicklungsprozesse.
• Dem Dienstleister fehlt es an Mitarbeitern zur Umsetzung in gewünschter Qualität oder Zeit.
• Dem Dienstleister fehlt ein gutes Projektmanagement und/oder Methodik, um sein (ausreichenden) Ressourcen sinnvoll einzusetzen und zu verteilen
• Kunde und Dienstleister finden keine gemeinsame Kommunikationsbasis (reden aneinander vorbei) oder keinen klaren Arbeitsmodus (arbeiten aneinander vorbei) etc.

Sie finden in Ihrer eigenen Praxiserfahrung oder einschlägiger Projektmanagement- und Softwareentwicklungsliteratur sicherlich noch viele andere Gründe, die allesamt keine „Böswilligkeit“ oder „Unfähigkeit“ der einen oder anderen Seite darstellen.

Wichtig ist nur, dass Sie versuchen, sich klar darüber zu werden, woran es hakt bzw. was die Ursachen sind. Im Folgenden finden Sie ebenso einige Lösungsansätze in Form von Steuerungsmethodiken, die Sie dementsprechend auf Ihre Situation übertragen können.

Schritt 2: Finden Sie eine Steuerungsmethodik

Eines Vorweg: Wie Sie an o.g. Gründen sehen, sind die Ursachen für die „Unschärfe“ nicht immer beim Dienstleister zu suchen. Prüfen Sie also, auch ob es nicht in Ihrem eigenen Unternehmen (oder bei sich selbst) Steuerungsbedarf gibt.

Im Folgenden wird nicht auf allgemeine Grundlagen und Werkzeuge des klassischen oder agilen Projektmanagements oder die notwendige fachlichen Qualitätssicherung eingegangen. Im Fokus stehen verhaltensbasierte Lösungsansätze zur Lösung und/oder Vermeidung (also Steuerung) von Konflikten, welche sich typischer Weise in einem ERP-Implementierungsprojekt ergeben können.

Kollaboration vs. Eskalation

In einem ERP-Implementierungsprojekt ziehen alle an dem gleichen Strang (wie oben beschrieben). Daher sollten Sie grundsätzlich versuchen Konflikte kollaborativ zu lösen. Das bedeutet…

1. Konflikte zu erkennen (nicht nur persönliche, sondern auch Zielkonflikte z.B. zwischen hoher Qualität und zu engem Zeitplan),
2. Konflikte offen und pro-aktiv anzusprechen und
3. Konflikte vernehmlich auf Arbeitsebene bzw. im angemessenen Rahmen zu lösen. Teilweise wird dies am besten in einem persönlichen 1:1 Gespräch möglich sein, teilweise eher kreativ in der gemeinsamen Projektgruppe.

Dieses Vorgehen hat ganz klar seine Grenzen. Insbesondere Budget-getriebene Zielkonflikte lassen sich trotz aller Kreativität nicht immer auf Arbeitsebene lösen. Es könnte z.B. notwendig werden, weitere Mitarbeiter einzusetzen, die auf der einen oder anderen Seite den Budget-Rahmen sprengen. Auch kann es passieren, dass trotz aller gemeinsamen Bemühungen die Lieferqualität nicht ausreichend ist. In diesen und anderen Fällen kann eine Eskalation eine sinnvolle Alternative sein, z.B. zur Gesamtprojektleitung, einem Projektsteuerungsgremium oder auch der Geschäftsführung.

Eine zu häufige (und unnötige) Eskalation kann leicht zu einem Überdruss der Beteiligten oder auch zu einem Gewohnheitseffekt führen. Wenn während der Projektlaufzeit ein oder zweimal zur Geschäftsführung eskaliert wird, kann das eine starke Wirkung entfalten. Telefonieren die Geschäftsführer von Kunde und Dienstleister aber täglich wegen irgendwelcher Probleme, ist hier kaum noch eine Wirkung zu erwarten.

Wichtig ist, dass Konflikte (auch unangenehme) nicht ignoriert oder stillschweigend toleriert werden. In der Regel wird der Konflikt dann doch von sich aus eskalieren – und das meist zum ungünstigsten Zeitpunkt…

Bezogen auf die o.g. Ursachen bewegen wir uns hier im Bereich der „Kommunikation“ aber auch von „Ressourcenengpässen“, „Verständnisproblemen“ oder nicht erfüllten Erwartungen.

Positive vs. negative Motivation

Hier geht es um die Frage, ob ein Kunde zum Erreichen bestimmter Ziele (sprich: zur Erfüllung bestimmter Erwartungen) versucht, den Dienstleister positiv oder negativ zu beeinflussen. Bei einer positiv-optimistischen Grundhaltung ist sicherlich die positive Motivation vorzuziehen.

Im Falle der positiven Motivation werden Dienstleister oder auch den Projektmitgliedern eine positive Konsequenz (sprich: eine Belohnung) in Aussicht gestellt, falls bestimmte Ziele oder Erwartungen erreicht werden. Z.B. ein Bonus für die zeitgerechte Auslieferung oder eine sehr niedrige Fehlerrate.

Jedoch hat auch die positive Methodik Grenzen, z.B. wenn trotz aller Versuche, positiver Motivation und klarer Kommunikation, keine Qualitative Steigerung bei den Lieferungen zu sehen ist. Der Grund könnte z.B. sein, dass die Geschäftsführung des Dienstleisters schlicht zu wenige (teuere) Tester einsetzt. Bevor hier jedoch zur negativen Motivation gegriffen wird (z.B. mit einem Verweis auf die festgelegte Liefqualität und möglichen Schadenersatz), müssen erst die Ursachen klar sein: Beiden Varianten, positive und negative Motivation, funktionieren nur, wenn der Dienstleister überhaupt in der Lage ist, die Erwartung zu erfüllen. Z.B. müsste ein Dienstleister in der Kürze der Zeit überhaupt in der Lage sein, benötigtes Know-how aufzubauen oder einzukaufen.

Bezogen auf die o.g. Ursachen bewegen wir uns in den Bereichen „Termin- oder Qualitätserfüllung durch Ressourceneinsatz“ oder anderen budgetlastigen Themen, die sich nicht auf Know-how oder Fähigkeiten des Dienstleisters beziehen. Z.B. der weg brechenden Marge eines Dienstleisters durch Qualitätsprobleme.

Coaching des Dienstleisters

Hier geht es um das Coaching (oder Training) des Dienstleisters durch den Kunden. Hier handelt es sich ganz klar um ein kollaboratives Konzept: Im Fokus steht der Projekterfolg mit allen Mitteln. Dazu zählt auch, dass der Kunde bereit ist, den Dienstleister in Bereichen zu coachen, in denen dieser Schwächen in Know-how oder Methodik hat – und das auch, wenn das zu Projektbeginn nicht abzusehen war.

Das Coaching des Dienstleisters erfüllt hier mehrere Aufgaben:

• Es löst einen möglichen Konflikt einvernehmlich und ohne großen Aufwand. Also einen Konflikt, der weder durch Eskalation noch Motivation ohne Weiteres lösbar wäre.
• Mit der Vermittlung von Methodik und/oder Know-how wird es unmittelbar für den Dienstleister leichter, die Kundenerwartungen zu verstehen und zu erfüllen. Somit wird die „Unschärfe“ verringert.
• Es handelt sich um eine präventive Maßnahme. Ohne Coaching würde spätestens die Lieferung die inhaltlichen oder qualitativen Mängel zeigen oder aber die Lieferung käme verspätet.

Beispiele für Coaching-Bereiche sind hier:

1. Vermittlung von fachlichem Know-how
2. Vermittlung von Projektmanagement- und/oder Qualitätsmanagementmethodik
3. Vermittlung von Kommunikations- und/oder Workshop-Methodik

Voraussetzung zur Anwendung von erfolgreichem Coaching ist u.a. das Erkennen der Know-how- oder Methodik-Lücken, das Vorhandensein von dem Know-how beim Kunden und nicht zuletzt die Bereitschaft des Dienstleisters sich coachen zu lassen. Coaching und Know-how kann in den meisten Fällen auch extern eingekauft werden, hier stellt sich jedoch die Frage, wer die Kosten übernimmt.

Bezogen auf die o.g. Ursachen bewegen wir uns in den Bereichen von „Methodik- oder Know-how-Mängeln“ des Dienstleisters. Umgekehrt könnte hier aber auch ein (externes) Coaching des Kunden notwendig sein.

… und was gibt es sonst noch zu beachten?

Ungefähr tausend andere Dinge, ganz klar. Sie sollten mit dieser kurzen Einführung jedoch in der Lage sein, selber ein wenig Ursachenforschung bei Problemen bzw. Konflikten im Projekt zu betreiben und selber verhaltensbasierte Lösungsansätze zu entwickeln und auszuprobieren.

Viel Erfolg mit Ihrem Projekt!

Diesen Artikel und mehr zum Thema ERP-Einführung finden Sie auch auf erpmanager.de.

Details zu diesem Thema, sowie weitere Grundlagen und Literatur zur ERP-Einführung finden Sie natürlich auch in dem Buch “Vorgehensmodell zur ERP-Einführung in kleinen und mittelständischen Unternehmen (KMU). Ein Modell aus der Perspektive eines Softwarehauses” (ISBN 978-3-638-94778-7).