Wie rechtfertige ich ein ERP-Budget gegenüber der Geschäftsführung?

Ein ERP-Budget wird bewilligt, wenn drei Dinge auf dem Tisch liegen: was der heutige Zustand jedes Jahr kostet, welche unternehmerischen Ziele ohne das Projekt nicht erreichbar sind und welches Risiko mit jedem Jahr Verzögerung wächst. Eine Aufstellung von Funktionen überzeugt keine Geschäftsführung, eine Gegenüberstellung von Kosten des Bleibens und Kosten des Handelns schon.

Wo ein ERP tatsächlich Geld spart: drei Posten, die auf keiner Rechnung stehen

Womit Sie rechnen müssen: die vier Kostenblöcke einer Einführung

Die Kosten des heutigen Zustands sichtbar machen

Der wirksamste Teil einer Budgetbegründung ist die Gegenrechnung. Sie beginnt mit Aufwänden, die heute anfallen und niemandem als Kosten erscheinen, weil sie zum Alltag gehören: die Tage, die jeden Monat in die manuelle Aufbereitung von Zahlen gehen, die Korrekturen aus fehlerhaften Stammdaten, die Doppelerfassung zwischen Systemen, die Abstimmungsschleifen, weil zwei Auswertungen unterschiedliche Zahlen zeigen.

Diese Posten lassen sich beziffern, ohne Gutachten. Fragen Sie in drei Bereichen, wie viele Stunden pro Monat für Tätigkeiten aufgewendet werden, die es bei sauberer Datenlage nicht bräuchte. Rechnen Sie das auf ein Jahr hoch. Die Zahl ist in den meisten Mittelständlern größer, als die Beteiligten erwarten, und sie ist belastbarer als jede Einsparprognose.

Der zweite Teil sind die Kosten verzögerter Entscheidungen. Wenn eine Deckungsbeitragsrechnung erst drei Wochen nach Monatsende vorliegt, entscheidet die Geschäftsführung drei Wochen lang auf Basis von Vermutungen. Was das kostet, lässt sich nicht exakt beziffern, aber es lässt sich an konkreten Entscheidungen des letzten Jahres zeigen.

Den Bezug zu unternehmerischen Zielen herstellen

Eine Geschäftsführung bewilligt Budgets für Ziele, nicht für Systeme. Die Frage lautet deshalb nicht, was das ERP kann, sondern welche der beschlossenen Unternehmensziele mit dem heutigen Stand nicht erreichbar sind. Wer in zwei weitere Länder expandieren will, braucht eine Systembasis, die das trägt. Wer die Lieferfähigkeit verbessern will, braucht verlässliche Bestandsdaten.

Dieser Bezug macht aus einem IT-Vorhaben ein Geschäftsvorhaben. Er ändert auch den Gesprächspartner: Statt über Investitionssummen zu verhandeln, sprechen Sie über die Voraussetzungen für etwas, das ohnehin beschlossen ist.

Hilfreich ist, die Ziele mit Zeitpunkten zu verknüpfen. Ein Rollout in ein weiteres Land braucht Vorlauf. Wenn der Markteintritt für übernächstes Jahr geplant ist, ergibt sich der Projektstart daraus, und die Diskussion verschiebt sich vom Ob zum Wann.

Das Risiko realistisch darstellen

Zur Ehrlichkeit gehört, die Risiken des Projekts zu nennen und nicht nur die des Nichtstuns. Große Technologieprogramme überschreiten in 65 bis 80 Prozent der Fälle ihr Budget oder ihren Zeitplan. Wer diese Zahl selbst auf den Tisch legt, wirkt nicht schwach, sondern vorbereitet, und kann im nächsten Satz erklären, was dagegen unternommen wird.

Quelle: McKinsey: The end of ERP as we know it. Five ways AI is disrupting ERP, Mai 2026

Die wirksamste Absicherung ist die Klärungsarbeit vor dem Start und eine Steuerung, die auf Ihrer Seite sitzt. Beides lässt sich als eigener Posten im Budget ausweisen, und genau das macht den Antrag glaubwürdig: Sie beantragen nicht nur Geld für Software, sondern für die Maßnahmen, die das bekannte Risiko senken.

Nennen Sie außerdem eine Abbruchbedingung. Ein Antrag, der beschreibt, an welchem Punkt und anhand welcher Kriterien das Vorhaben überprüft wird, nimmt der Entscheidung viel von ihrer Schwere. Geschäftsführungen bewilligen leichter, wenn die Entscheidung nicht endgültig ist.

Wie der Antrag aufgebaut sein sollte

Ein tragfähiger Antrag passt auf zwei Seiten. Er beginnt mit der Ausgangslage in Zahlen, nennt die Ziele, für die das Vorhaben Voraussetzung ist, und stellt die Kosten über fünf Jahre den Kosten des Bleibens gegenüber. Danach folgen die Risiken mit den Gegenmaßnahmen und am Ende der Entscheidungsweg mit Zeitpunkten.

Was nicht hineingehört, sind Funktionslisten, Produktvergleiche und technische Details. Sie gehören in den Anhang oder in ein separates Dokument, weil sie die Kernfrage verdecken.

Ein praktischer Hinweis zum Schluss: Rechnen Sie in Bandbreiten, nicht in Punktwerten. Eine Spanne mit benannten Annahmen ist glaubwürdiger als eine exakte Summe, die jeder als Verhandlungsposition erkennt, und sie erspart Ihnen die unangenehme Situation, später die erste Zahl verteidigen zu müssen.