Senior-Beratungsgespräch zu Business Central und ERP bei DGP

Wann muss ich in einem ERP-Projekt eskalieren und an wen?

Zu spät eskaliert wird häufiger als zu früh. Der richtige Zeitpunkt lässt sich definieren.

Frank Maier·Zuletzt aktualisiert: 21.09.2026

Inhalt
Läuft es gerade schief?

Ein senior-geführtes Gespräch ordnet die Lage, bevor mehr Geld fließt.

Passende Leistung

Governance & Delivery

Eskalieren müssen Sie, sobald eine Entscheidung länger offen ist als vereinbart, ein Risiko den Termin oder das Budget bedroht und im Projektteam nicht mehr lösbar ist, oder zugesagte Ergebnisse zweimal in Folge ausbleiben. Adressat ist der Lenkungsausschuss, nicht der Projektleiter des Partners. Wichtig ist, dass diese Schwellen vor dem Projekt vereinbart werden. Wo sie fehlen, wird Eskalation als persönlicher Konflikt erlebt und deshalb vermieden.

Wer im Projekt überhaupt steuert: Wer steuert Ihr Projekt, wenn es hart wird?

Die Warnsignale davor: Woran erkenne ich, dass mein ERP-Projekt scheitert?

Die drei Schwellen, ab denen eskaliert wird

Die erste Schwelle ist die Entscheidungsdauer. Vereinbaren Sie vor dem Projekt, wie lange eine Entscheidung offen bleiben darf, je nach Tragweite etwa fünf oder zehn Arbeitstage. Wird diese Frist überschritten, geht die Frage automatisch eine Ebene höher. Das ist kein Misstrauensvotum, sondern ein Mechanismus, und genau deshalb funktioniert er.

Die zweite Schwelle ist das Risiko mit Termin- oder Budgetwirkung, das im Team nicht mehr gelöst werden kann. Typische Fälle sind eine Schnittstelle, deren Gegenstelle nicht liefert, eine Datenqualität, die schlechter ist als angenommen, oder eine Anforderung, die sich als weit größer herausstellt.

Die dritte Schwelle ist das wiederholte Ausbleiben zugesagter Ergebnisse. Einmal kann passieren. Zweimal in Folge ist ein Muster, und Muster lösen sich nicht von selbst. Wer hier auf Besserung wartet, verliert die Zeit, die man später für die Korrektur braucht.

An wen eskaliert wird

Der Adressat ist der Lenkungsausschuss, in dem Ihre Geschäftsführung und die Leitungsebene des Partners sitzen. Nicht der Projektleiter des Partners, denn der ist in der Regel bereits Teil der Situation und hat die Befugnis nicht, die es jetzt braucht.

Wichtig ist der Unterschied zwischen informieren und eskalieren. Informieren heißt, dass eine Lage bekannt gemacht wird. Eskalieren heißt, dass eine Entscheidung eingefordert wird. Eine Eskalation ohne konkrete Entscheidungsvorlage erzeugt Unruhe, aber keine Lösung.

Dazu gehört, dass die Eskalation aus Ihrem Haus kommt und nicht nur vom Dienstleister. Wenn ausschließlich der Partner eskaliert, entsteht ein schiefes Bild, in dem Ihr Unternehmen die Lage immer nur zur Kenntnis nimmt. Steuerung heißt, selbst zu benennen, was nicht läuft.

Wie eine Eskalation aufgebaut sein muss

Eine wirksame Eskalation passt auf eine Seite und enthält vier Teile. Erstens den Sachverhalt in wenigen Sätzen, ohne Schuldzuweisung. Zweitens die Auswirkung in Terminen und Zahlen: Was verschiebt sich, was kostet es, was ist der späteste Zeitpunkt für eine Entscheidung?

Drittens zwei bis drei Handlungsoptionen mit Konsequenzen, nicht nur ein Vorschlag. Vier Augen sehen die Lage ohnehin unterschiedlich, und ein Gremium entscheidet leichter zwischen Optionen als über eine einzelne Empfehlung. Viertens eine klare Frage: Was genau soll entschieden werden, und von wem?

Was nicht hineingehört, sind Vorwürfe und lange Chroniken. Beides verschiebt die Aufmerksamkeit von der Entscheidung auf die Vergangenheit, und genau das verzögert die Lösung.

Warum so selten rechtzeitig eskaliert wird

Der häufigste Grund ist die Sorge, als überfordert zu gelten. Projektleiter wollen Probleme lösen, nicht melden, und diese Haltung ist im Alltag richtig. Sie wird zum Risiko, wenn das Problem außerhalb der eigenen Befugnis liegt.

Der zweite Grund ist ein Statusbericht, der nicht abbildet, was los ist. Wenn drei Monate lang alles grün ist und danach plötzlich rot, hat nicht die Lage sich schlagartig geändert, sondern der Bericht hat nicht gemessen, was zählt. Statusfarben nach Gefühl sind der zuverlässigste Vorbote später Eskalationen.

Der dritte Grund ist fehlende Übung. Ein Gremium, das nur zusammenkommt, wenn es brennt, erlebt jede Eskalation als Krise. Ein Gremium, das regelmäßig tagt und auch kleine Entscheidungen trifft, behandelt eine Eskalation als normalen Vorgang. Die Kultur entsteht vor dem Ernstfall, nicht in ihm.

Was Sie vor dem Projektstart vereinbaren sollten

Vier Punkte gehören in die Projektvereinbarung, und sie kosten kaum Zeit. Erstens die Entscheidungsfristen nach Tragweite. Zweitens der Eskalationsweg mit Namen, nicht mit Rollen: Wer genau wird informiert, wer entscheidet?

Drittens ein fester Sitzungsrhythmus des Lenkungsausschusses, auch wenn es gut läuft. Viertens die Regel, dass jede Eskalation eine Entscheidungsvorlage mit Optionen enthält. Diese vier Punkte verwandeln Eskalation von einem Konflikt in ein Verfahren.

Der Nutzen zeigt sich nicht im ersten Monat, sondern in dem Moment, in dem es schwierig wird. Projekte, die diesen Mechanismus haben, korrigieren früher und kleiner. Projekte ohne ihn korrigieren spät und teuer, wenn überhaupt.

“

Eine Eskalation ohne konkrete Entscheidungsvorlage erzeugt Unruhe, aber keine Lösung.

Frank Maier, Gründer von DGP

Häufige Fragen

Kurz nachgefragt

Ab wann sollte man in einem ERP-Projekt eskalieren?

Sobald eine Entscheidung länger offen ist als vereinbart, ein Risiko Termin oder Budget bedroht und im Team nicht lösbar ist, oder zugesagte Ergebnisse zweimal in Folge ausbleiben. Diese Schwellen gehören vor dem Start vereinbart.

An wen eskaliert man in einem ERP-Projekt?

An den Lenkungsausschuss mit Ihrer Geschäftsführung und der Leitungsebene des Partners, nicht an den Projektleiter des Partners. Der ist meist bereits Teil der Situation und hat nicht die nötige Befugnis.

Was gehört in eine Eskalation?

Der Sachverhalt ohne Schuldzuweisung, die Auswirkung in Terminen und Zahlen, zwei bis drei Optionen mit Konsequenzen und eine klare Frage, was von wem entschieden werden soll. Nicht hinein gehören Vorwürfe und lange Chroniken.

Der größere Rahmen dieser Frage: Wer steuert eigentlich Ihr Business-Central-Projekt, wenn es hart wird?.

Passend dazu

Verwandte Fragen

Projekt in Schieflage

Der Go-Live ist verschoben. Was jetzt?

Kein Termin-, sondern ein Steuerungsproblem.

04.08.2026

Lesen →

Projekt in Schieflage

ERP-Projekt scheitert: fünf Warnsignale

Treffen zwei zu, ist Gegensteuern überfällig.

01.08.2026

Lesen →

Projekt in Schieflage

Wie viele ERP-Projekte scheitern wirklich?

Eine belastbare Quote gibt es nicht. Zwei Zahlen sind belegt, beide sagen etwas anderes.

23.09.2026

Lesen →

Wo steht Ihr Projekt wirklich?

Bei DGP sprechen Sie mit einem erfahrenen Berater, nicht mit einem Vertrieb.

Einladungen per E-Mail

Den Überblick behalten, ohne alles selbst zu verfolgen.

Einmal im Monat ordnet Frank Maier ein, was sich in der ERP-Welt bewegt. Dazu kommt die Einladung zum nächsten Live-Webinar.

Danke, Sie sind eingetragen.