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

Wissen/Antwort

Senior-geführte Antwort · Governance & Steuerung

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

Ihre Frage im Detail?

Ein senior-geführtes Gespräch bringt Ihre Lage auf den Punkt.

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

Wissen

Wer steuert eigentlich Ihr Business-Central-Projekt, wenn es hart wird?

Governance im Projekt: warum ein interner Projektleiter allein selten reicht.

03.08.2026

Lesen

Wissen

Woran erkenne ich, dass mein ERP-Projekt scheitert?

Die Warnsignale, und was der erste Schritt ist, wenn mehrere zutreffen.

03.08.2026

Lesen

Wissen

Wie lange dürfen Entscheidungen in einem ERP-Projekt dauern?

Entscheidungsdauer als Frühindikator für Governance-Probleme.

03.08.2026

Lesen

Wo steht Ihr Projekt wirklich?

Sprechen Sie mit einem Senior, nicht mit einem Vertrieb.