So erstellen Sie einen ERP-Business-Case für die Fertigung, der wirklich genehmigt wird

Ein schwacher ERP-Business-Case beginnt meist in der Welt des Anbieters: Module, Funktionen, Workflows, Integrationen, Implementierungsphasen und Nutzerlizenzen. Genau dort verlieren viele ERP-Projekte ihre Zustimmung, weil der Business Case mit Software beginnt und nicht mit dem Geschäftsproblem und den Kennzahlen, die für die Geschäftsleitung relevant sind.

Dieser Artikel zeigt, wie Sie einen ERP-Business-Case für die Fertigung rund um die Zahlen aufbauen, die ein Führungsgremium, oft CODIR genannt, wirklich bewegen: zurückgewonnene Stunden, vermiedene Margenverluste und reduziertes Risiko. Er zeigt auch, wie Sie Annahmen prüfen, damit der Business Case belastbar wird.

Warum die meisten ERP-Business-Cases scheitern

Das Argument für ein ERP muss damit beginnen, dass das aktuelle Betriebsmodell dem Unternehmen Geld kostet, Wachstum verlangsamt, Margenprobleme verdeckt oder Kundenzusagen gefährdet.

Ein stärkerer Business Case beginnt deshalb mit den Kosten des aktuellen Systems:

• Wie viele Stunden verliert das Team jede Woche durch manuelle Arbeit?
• Wo verschwindet Marge, weil das Unternehmen Probleme zu spät erkennt?
• Welche Risiken werden teurer, wenn das Unternehmen seine Abläufe weiter über Tabellen, Papier, Gedächtnis, getrennte Tools oder ein Legacy-ERP steuert?

Dieser Rahmen verändert die Diskussion. Das Projekt lautet nicht mehr "wir wollen ein ERP kaufen" oder "wir wollen das ERP wechseln." Es lautet: "Wir zahlen bereits $X, weil uns ein tragfähiges operatives System fehlt."

Die 3 Zahlen, die Ihr CODIR wirklich interessieren

Die meisten Modelle für den Return on Investment (ROI) eines ERP werden zu schnell zu breit. Sie versuchen, jeden möglichen Nutzen zu beziffern. Dadurch wirkt das Modell präzise und gleichzeitig wenig überzeugend.

Besser ist es, sich auf drei Zahlen zu konzentrieren.

1. Zurückgewonnene Stunden pro Woche

Beginnen Sie mit der Arbeit, die Menschen bereits erledigen, weil das System sie nicht übernimmt. Typische Beispiele sind Produktionsnachverfolgung, Bestandsprüfungen, Planungsaktualisierungen, doppelte Dateneingabe, Nachfassen im Einkauf, Qualitätsverfolgung, Reporting und Abgleich zwischen Operations und Finance.

Zählen Sie nicht nur offensichtliche Administration, sondern auch operative Unterbrechungen. Ein Planer, der zwei Stunden damit verbringt, den Produktionsplan neu aufzubauen, ist leicht zu modellieren. Ein Produktionsleiter, der 12 Mal am Tag unterbrochen wird, weil niemand der Bestandszahl vertraut, ist schwieriger zu beziffern, aber der Aufwand ist real. Dasselbe gilt für die Zeit, die ein Einkäufer damit verbringt, Engpässe zu verfolgen, die das System früher hätte anzeigen sollen.

Am saubersten lässt sich das nach Rollen schätzen:

• Planer: Stunden für Planaktualisierungen, Prüfung von Einschränkungen und Abgleich von Änderungen
• Produktionsleiter: Stunden für Statusabfragen, Datenkorrekturen und wiederkehrende Fragen
• Bediener: Zeit für Notizen auf Papier plus Zeit für spätere Aktualisierung eines Systems
• Einkauf: Zeit für Nachverfolgung von Engpässen, verspäteten Lieferanten und unklaren Bedarfen
• Finance oder Management: Zeit für Rekonstruktion von Produktionskosten, Marge oder Bestandsinformationen

Sobald die wöchentlichen Stunden sichtbar sind, rechnen Sie sie in Jahreswert um. Achten Sie aber auf die Formulierung: Nicht jede zurückgewonnene Stunde wird zu einer direkten Kosteneinsparung. Ein Teil wird zu Kapazität, also dazu, dass dasselbe Team mehr Volumen bewältigen, schneller antworten, Fehler reduzieren oder an Verbesserungen arbeiten kann, statt das Unternehmen manuell zusammenzuhalten. Diese Unterscheidung macht das Modell glaubwürdiger.

2. Margenverluste, die Sie stoppen können

Hersteller verlieren Marge, wenn das Team Probleme erst erkennt, nachdem das Entscheidungsfenster geschlossen ist. Beispiele:

• Ein Materialpreis hat sich geändert, aber Sales hat noch mit dem alten Kostenwert angeboten
• Ein Los hat mehr Input verbraucht als erwartet, aber Finance sieht die Abweichung erst zum Monatsabschluss
• Die Produktion war verspätet, also hat das Unternehmen Eiltransport bezahlt
• Bestand sah verfügbar aus, aber das Lager stellte zu spät fest, dass er gesperrt, abgelaufen, reserviert oder schlicht falsch war

Solche Verluste erscheinen fast nie in einer sauberen Budgetzeile namens "ERP-Problem." Sie zeigen sich als Ausschuss, Nacharbeit, Eileinkäufe, verspätete Lieferungen, Überbestand, gebrochene Kundenzusagen, ungeklärte Abweichungen und Managementzeit, die in die Rekonstruktion der Ereignisse fließt.

Ein guter Business Case muss nicht behaupten, dass das ERP jeden Margenpunkt zurückholt. Er sollte aber die wenigen wichtigen Verlustpunkte identifizieren, die ein besseres System klar beheben könnte.

3. Risikokosten, wenn Sie nichts tun

Die dritte Zahl vermeiden Teams oft, weil sie unangenehm und schwer zu quantifizieren ist. Was passiert, wenn das Unternehmen nicht handelt?

ERP-Projekte gelten oft als riskant, weil Implementierung Geld, Aufmerksamkeit und Veränderung erfordert. Das stimmt. Aber das aktuelle System beizubehalten, ist ebenfalls mit Risiko verbunden.

Bei einigen Herstellern ist das Risiko kundenseitig: verspätete Aufträge, verfehlte Servicelevels, Vertragsstrafen oder ein wichtiger Kunde, der Vertrauen verliert. Bei anderen liegt das Risiko in Qualität, Rückverfolgbarkeit, Compliance oder Abhängigkeit von einer Schlüsselperson. Manchmal ist das Risiko strategisch: Das Unternehmen will wachsen, ein neues Werk eröffnen, einen neuen Kanal starten oder größere Kunden bedienen, aber das operative System kann die nächste Phase nicht tragen.

Diese Zahl wird nie so sauber sein wie Arbeitsstunden, also unsere erste Zahl. Das ist in Ordnung. Das Ziel ist keine Scheingenauigkeit, sondern der Geschäftsleitung zu zeigen, dass auch der Status quo eine Kostenkurve hat.

So bauen Sie das Modell, ohne perfekte Mathematik vorzutäuschen

Ihr ERP-Business-Case muss nicht perfekt sein. Er muss aber so aufgebaut sein, dass die Geschäftsleitung ihn hinterfragen und trotzdem glauben kann.

Statt sofort das ganze Unternehmen abzubilden, ist es sinnvoll, mit drei bis fünf operativen Abläufen zu beginnen. Erfassen Sie für jeden Ablauf vier Dinge:

1. Welche manuelle Arbeit passiert heute?
2. Wer macht sie, und wie oft?
3. Was kostet diese Arbeit in Zeit, Marge oder Risiko?
4. Was würde sich ändern, wenn diese Arbeit in ein gemeinsames operatives System wandern würde?

Trennen Sie anschließend die Nutzenkategorien. Harte Einsparungen sind Kosten, die das Unternehmen direkt reduzieren kann. Kapazitätsgewinne sind Stunden, die das Team für höherwertige Arbeit einsetzen kann. Margenverbesserung entsteht durch vermiedene Verluste, nicht durch plötzlich höhere Preise. Risikoreduktion entsteht durch geringere Exponierung, auch wenn der genaue finanzielle Wert als Bandbreite angegeben wird.

Für diese Bandbreite helfen drei Szenarien:

• Konservativ: nur Nutzen, die das Team mit hoher Sicherheit erreichen kann (dieser Fall sollte stark genug sein, um das Projekt zu rechtfertigen)
• Wahrscheinlich: Nutzen auf Basis heute beobachteter Arbeit und realistischer Einführung
• Ambitioniert: Nutzen, wenn das System breit angenommen wird und sich operative Gewohnheiten ändern; der ambitionierte Fall sollte zeigen, was möglich wird, wenn das Unternehmen das ERP als echtes operatives System nutzt und nicht nur als Datenbank

So prüfen Sie die Annahmen, bevor Ihr CODIR es tut

Ein gutes CODIR wird das Modell hinterfragen. Das ist seine Aufgabe. Diese Prüfung ist keine Bedrohung, sondern eine Einladung, den Belastungstest von Anfang an in den Business Case einzubauen.

Kennzeichnen Sie zuerst das Vertrauensniveau jedes Inputs. Beobachtete Zahlen sind am stärksten. Sie kommen aus Zeiterfassung, Exporten, Produktionslogs, Einkaufsdaten, Qualitätsberichten, Kundenstrafen, Bestandskorrekturen oder tatsächlichen Margenabweichungen.

Geschätzte Zahlen sind weiterhin nützlich, brauchen aber Verantwortliche. Wenn der Produktionsleiter zum Beispiel 10 Stunden Reportingarbeit pro Woche schätzt, sagen Sie das. Wenn Finance Margenverluste durch Eileinkäufe schätzt, zeigen Sie die Berechnung und die Quelle.

Annahmen sind am schwächsten, also machen Sie sie sichtbar und verstecken Sie sie nicht in der Berechnung. Die Geschäftsleitung vertraut einem Modell eher, wenn sie sieht, wo Urteilsvermögen eingesetzt wurde.

Stellen Sie danach die unbequemen Fragen:

• Welche Nutzen hängen von der Einführung durch Bediener, Planer oder Einkäufer ab?
• Welche Einsparungen sind Cash-Einsparungen, und welche sind Kapazitätsgewinne?
• Welchen Teil des Modells würde Finance zuerst hinterfragen?
• Welche operativen Probleme bleiben auch nach dem ERP-Projekt bestehen?
• Was müsste stimmen, damit der konservative Fall scheitert?
• Was würde das Unternehmen verlieren, wenn es weitere 12 Monate wartet?

Die letzte Frage ist wichtig, weil ERP-Business-Cases oft so bewertet werden, als wäre die Alternative kostenlos. Das ist sie nicht. Die Alternative ist das aktuelle System mit all der manuellen Arbeit, den Verlusten und den Risiken, die damit verbunden sind.

Beispiel: Produktionsreporting

Nehmen wir ein praktisches Beispiel. Stellen Sie sich einen Hersteller mit 100 Mitarbeitenden vor, bei dem Produktionsreporting noch aus Papiernotizen, Aktualisierungen am Schichtende, Tabellenkorrekturen und Fragen an den Produktionsleiter besteht. Bediener erfassen, was während des Laufs passiert ist, aber die Information erreicht Planung, Einkauf, Finance oder Management so spät, dass das Team häufig erst im Nachhinein reagiert.

Dieser Workflow eignet sich gut für den Business Case, weil er alle drei Wertformen gleichzeitig erzeugt. Das Team kann Zeit aus manuellem Reporting zurückgewinnen, Marge schützen, indem Produktionsabweichungen früher sichtbar werden, und Risiko reduzieren, weil die Geschäftsleitung nicht mehr von ein oder zwei Personen abhängt, um zu rekonstruieren, was in der Fertigung passiert ist.

Die folgenden Zahlen sind keine Benchmarks. Sie zeigen, wie ein Prozess so modelliert werden kann, dass Ihr CODIR ihn hinterfragen kann.

Beachten Sie, dass das Modell nicht jeden Input als gleich sicher behandelt. Zurückgewonnene Stunden lassen sich oft aus Interviews schätzen und mit einer kurzen Beobachtungsphase prüfen. Margenverluste können dagegen aus aktuellen operativen Ereignissen und Finance-Daten geschätzt werden. Risikoreduktion basiert meist stärker auf Annahmen, sollte also als Bandbreite formuliert und an ein konkretes Ereignis gebunden werden, das das Unternehmen vermeiden will.

Die Einwände, die Sie vorwegnehmen müssen

Widerstand gegen ERP ist oft rational, weil viele Führungsteams teure Projekte gesehen haben, die verspätet waren, Nutzer enttäuscht haben oder das Unternehmen mit einem starren System zurückgelassen haben, das weiterhin Tabellen braucht.

Hier sind einige häufige Einwände und mögliche Antworten:

"Die Implementierung lenkt das Team ab"

Dieser Einwand ist berechtigt. ERP-Implementierung braucht Aufmerksamkeit von Menschen, die bereits operative Verantwortung tragen. Auch wenn die Implementierung schnell ist, wie bei Bonx mit etwa einem bis drei Monaten, braucht sie trotzdem Fokus und Einsatz des Teams.

Die Antwort besteht nicht darin, so zu tun, als würde das Projekt keine Arbeit erfordern. Zeigen Sie stattdessen den Implementierungsumfang klar: welche Abläufe zuerst kommen, wer das Projekt intern verantwortet, welche Daten vorbereitet werden müssen und wie das Team verhindert, dass das ERP-Projekt zu einem Jahr Workshops wird, bevor Wert entsteht.

Wenn der Business Case interne Teamzeit als Kostenblock enthält, wird er glaubwürdiger. Er zwingt auch das Gespräch mit dem Anbieter, praktisch zu bleiben. Ein Anbieter, der sechs Monate Discovery braucht, bevor operativer Wert sichtbar wird, sollte anders bewertet werden als einer, der mit den Abläufen beginnen kann, die heute Kosten verursachen.

"Wir haben ERP-Implementierung schon versucht"

Dieser Einwand betrifft nicht Software, sondern Vertrauen. Wenn das Unternehmen bereits ein ERP versucht hat und das Projekt gescheitert ist, muss der Business Case benennen, was diesmal anders ist. Nur einen anderen Anbieter zu wählen, reicht meist nicht.

War das letzte Projekt zu stark von Finance geführt? Hat es versucht, das ganze Unternehmen im Voraus zu modellieren? Haben Bediener das System gemieden, weil es sie verlangsamte? Hat die Implementierung Prozesse eingefroren, die sich weiter verändert haben? Hat der Anbieter das Unternehmen in Workflows gezwungen, die in der Demo sauber aussahen, aber in der realen Produktion nicht funktionierten?

Ein glaubwürdiger Business Case erklärt den Fehlermechanismus und zeigt dann, wie das neue Projekt ihn vermeidet.

"Das Team wird es nicht annehmen"

Teams lehnen Systeme nicht ab, weil sie manuelle Arbeit mögen. Sie lehnen Systeme ab, die ihre Arbeit schwerer machen.

Das Argument zur Einführung sollte sich deshalb auf die Arbeit selbst konzentrieren. Welche Aufgaben werden einfacher? Welche doppelte Eingabe verschwindet? Welche Fragen erfordern nicht mehr dieselbe Person? Welche Produktionsupdates passieren im normalen Arbeitsfluss statt nach der Schicht?

Einführung ist kein Kommunikationsplan. Sie entsteht daraus, ob das ERP Menschen wirklich hilft, ihre Arbeit zu erledigen.

"Die Einsparungen sind zu theoretisch"

Darum sollte das Modell harte Einsparungen, Kapazitätsgewinne, Margenverbesserung und Risikoreduktion trennen. Wenn die Geschäftsleitung nur harte Einsparungen akzeptiert, sagen Sie klar, was das Modell belegen kann. Lassen Sie diese enge Definition aber nicht den Wert ausblenden, den das Unternehmen offensichtlich braucht.

Ein Planer, der 10 Stunden pro Woche zurückbekommt, reduziert vielleicht keine Personalkosten. Wenn diese Zeit aber zu besserer Planung, weniger Engpässen, schnelleren Kundenantworten und weniger Feuerwehreinsätzen führt, hat sie trotzdem Geschäftswert. Das Modell sollte das klar sagen, statt jede zurückgewonnene Stunde als direkte Kostensenkung auszugeben.

"Das ist ein Operations-Projekt, keine Unternehmenspriorität"

Dieser Einwand bedeutet meist, dass der Business Case zu nah an der Fertigung geblieben ist.

Operations ist der erste Ort, an dem die Kosten sichtbar werden, aber die Wirkung betrifft das ganze Unternehmen. Unzuverlässiger Bestand beeinflusst Vertriebszusagen, verspätete Produktion beeinflusst Umsatz, schwache Rückverfolgbarkeit beeinflusst Risiko, manuelles Reporting beeinflusst Management und fragile Systeme beeinflussen Wachstum.

Der ERP-Business-Case sollte operative Arbeit mit Ergebnissen auf Unternehmensebene verbinden, ohne daraus eine allgemeine Transformationsrede zu machen.

So präsentieren Sie den Business Case, damit er genehmigt wird

Beginnen Sie mit den Geschäftskosten, nicht mit der Software. Eine starke Präsentation für einen ERP-Business-Case folgt meist dieser Reihenfolge:

1. Benennen Sie das operative Problem in klarer Sprache.
2. Zeigen Sie die aktuellen Kosten in Stunden, Marge und Risiko.
3. Präsentieren Sie zuerst das konservative ROI-Modell.
4. Erklären Sie die Annahmen und das Vertrauensniveau.
5. Zeigen Sie Implementierungsumfang und internen Aufwand.
6. Beantworten Sie Einwände, bevor sie gestellt werden.
7. Enden Sie mit der Entscheidung: freigeben, verschieben oder die Kosten des aktuellen Betriebsmodells akzeptieren.

Die Personen im Raum sind genauso wichtig wie die Inhalte der Präsentation. Ein ERP-Business-Case für die Fertigung kann nicht von einer Abteilung allein getragen werden. Wenn Operations den Business Case ohne Finance baut, können die Zahlen angegriffen werden. Wenn Finance den ERP-Business-Case ohne Operations baut, kann das Modell die Arbeit übersehen, die Wert schafft. Wenn die Geschäftsleitung erst am Ende eingebunden wird, wird das Projekt leicht zu einer Softwarediskussion statt zu einer Unternehmensentscheidung.

Fazit: Der Business Case dient nicht dem Kauf von Software

Ein ERP-Business-Case für die Fertigung fordert die Geschäftsleitung nicht wirklich auf, Software zu genehmigen. Er stellt eine deutlich unbequemere Frage: Kann das aktuelle Betriebsmodell uns in die nächste Unternehmensphase bringen?

Wenn die Antwort ja lautet, kann das ERP-Projekt warten. Wenn das Team operative Fragen noch schnell beantworten, Bestand vertrauen, Marge erklären, Lieferzusagen einhalten und wachsen kann, ohne weitere Schichten manueller Koordination aufzubauen, kann ein ERP-Projekt verfrüht sein.

Wenn das Unternehmen aber bereits durch manuelle Arbeit, späte Entscheidungen, unklare Marge, fragile Rückverfolgbarkeit oder operatives Wissen in den Köpfen weniger Personen bezahlt, ist der Business Case nicht spekulativ.

Bonx ist das KI-native Fertigungs-ERP, das zeigt, dass Implementierung nicht Jahre von Beratung bedeuten muss, bevor Wert entsteht, und dass ERP nicht zu einem weiteren System werden muss, das das Team ständig mit Daten versorgt.

Viele ERP-Business-Cases scheitern am Timing. Wenn Wert erst nach einer langen Implementierung sichtbar wird, diskontiert die Geschäftsleitung den Return. Wenn das System früher damit beginnen kann, manuelle Arbeit zu reduzieren, wird der Business Case leichter zu verteidigen.

Bonx-Kunden gehen in 1 bis 3 Monaten live, verbinden Operations mit den Tools, die bereits im Stack vorhanden sind, und nutzen Bonx für Auftragsmanagement, Bestand, Einkauf und Lieferantenmanagement, Planung, Produktion, Qualität, Rückverfolgbarkeit und Logistik.

Der stärkste ERP-Business-Case sagt am Ende nicht: "Diese Software hat ROI." Er sagt: "Die Art, wie wir Operations heute steuern, hat bereits Kosten. Das ist die Höhe, das können wir zurückgewinnen, und das riskieren wir, wenn wir weiter so tun, als wäre das aktuelle System kostenlos."

‍