Wie Sie einen Business Case für ein Plant Operating System aufbauen
Team DBR77 IRIS7 Min. Lesezeit

Bauen Sie den Business Case für ein Plant Operating System (Betriebssystem für das Werk) auf Ihrer eigenen Ausgangsbasis auf, nicht auf Prozentangaben von Anbietern. Messen Sie einige Wochen lang vier bis sechs Verluste an einer Linie, geben Sie jedem einen Preis und berechnen Sie, wie viel dieses Verlusts das System beseitigen muss, um sich selbst zu bezahlen. Lassen Sie dann einen Pilot an einer Linie zeigen, ob es das tut, bevor Sie sich für das ganze Werk festlegen.
So bekommt das Controlling eine Zahl, die es prüfen kann, und beide Seiten sind vor dem häufigsten Fehler geschützt: einem Business Case, der auf den Ergebnissen anderer beruht. Im Folgenden: warum die meisten Business Cases scheitern, wie Sie eine Ausgangsbasis messen, wie Sie jeden Verlust bewerten, die Gesamtkosten, der Break-even-Test und die Rolle des Pilots.
Warum die meisten Business Cases für Werkssoftware scheitern
Die meisten Business Cases scheitern auf eine von drei Arten. Sie übernehmen Nutzen in Prozent aus einer Broschüre, sodass niemand im Werk daran glaubt. Sie zählen nur Lizenzgebühren, sodass die echten Kosten erst später auftauchen. Oder sie versprechen eine Zahl, ohne dass man sie prüfen kann.
Die Forschung von McKinsey zur digitalen Fertigung ergab, dass Unternehmen, die in endlosen Pilotphasen („Pilot Purgatory“) feststeckten, keinen spürbaren Nutzen im Ergebnis sahen. McKinsey riet, vom Ergebniswert rückwärts zu arbeiten statt von der Technik aus, mit einer Roadmap in Phasen und einem Business Case. Einfach gesagt: Beginnen Sie mit dem, was das Werk heute verliert.
Wo diese Verluste in einem Werk mit getrennten Werkzeugen liegen, behandelt der Artikel Die wahren Kosten getrennter Systeme und Tabellen im Werk. Dieser Artikel macht daraus einen Business Case.

Schritt 1: eine belastbare Ausgangsbasis messen
Wählen Sie eine Linie und messen Sie vier bis acht Wochen lang; füllen Sie Lücken bei Bedarf von Hand. Jeder Verlust braucht eine Definition, eine Quelle und einen Verantwortlichen.
| Verlust | Wie Sie ihn messen | Wo die Daten heute liegen | Wie Sie ihn bewerten |
|---|---|---|---|
| Ungeplanter Stillstand | Stunden pro Monat, mit Stillstandsgründen | Maschinendaten, Schichtberichte, MES | Entgangener Deckungsbeitrag pro Stunde am Engpass, Überstunden zum Aufholen |
| Ausschuss und Nacharbeit | Stück oder kg pro Woche, nach Fehlerart | Qualitätsformulare, MES, ERP | Material plus Arbeit plus Maschinenzeit |
| Verspätetes oder fehlendes Material | Minuten, die die Linie auf Material wartet | Schichtnotizen, Lagerprotokolle | Wie Stillstand, plus Eilfracht |
| Abtippen und Abgleichen | Stunden pro Woche, in denen Daten zwischen Werkzeugen kopiert werden | Planer, Schichtleiter und Qualitätsmitarbeiter fragen | Vollkostensatz pro Stunde |
| Verspätete Instandhaltung | Überfällige vorbeugende Arbeitsaufträge, wiederkehrende Störungen | CMMS, Whiteboard | Reparaturkosten, Ersatzteile, verursachter Stillstand |
| Kundenreklamationen | Anzahl pro Quartal und Kosten der Bearbeitung | Qualität, Vertrieb | Gutschriften, Sortieren, Versand, verlorene Aufträge |
Für Qualitätsverluste ist die Methode der Qualitätskosten der ASQ ein nützlicher Rahmen. Sie teilt Fehlerkosten in interne Fehlerkosten für Fehler, die gefunden werden, bevor der Kunde das Produkt erhält, und externe Fehlerkosten für Fehler, die danach gefunden werden. Zählen Sie beide getrennt.
Branchenzahlen helfen als Einordnung, nicht als Ihre Zahl. Siemens berichtet, dass ein durchschnittliches großes Werk 27 Stunden im Monat durch ungeplanten Stillstand verliert. Ihre Linie kann weit darüber oder darunter liegen. In den Business Case gehört nur Ihre eigene Zahl.
Schritt 2: jeden Verlust bewerten, dann den Break-even prüfen
Beginnen Sie nicht mit „Das System senkt den Stillstand um X %“. Beginnen Sie mit der Frage, die das Controlling prüfen kann: Wie viel Verlust muss beseitigt werden, um die Kosten zu decken?
Illustratives Beispiel: Ein Werk im Zweischichtbetrieb misst sechs Wochen lang eine Engpasslinie. Der ungeplante Stillstand liegt im Schnitt bei 22 Stunden im Monat. Jede Stunde an dieser Linie entspricht 1.500 € entgangenem Deckungsbeitrag, also kostet der Stillstand etwa 33.000 € im Monat. Planer und Schichtleiter verbringen 30 Stunden pro Woche mit Abtippen, zu 45 € pro Stunde, was etwa 5.800 € im Monat hinzufügt. Betragen die vollen monatlichen Kosten des Systems für diese Linie 6.000 €, erreicht es den Break-even, wenn es etwa 4 Stunden Stillstand im Monat beseitigt, oder eine kleinere Kombination aus Stillstand und Abtippen. Das Team hält das schriftlich als Ziel des Pilots fest.
Das verändert die Diskussion. Statt über die Behauptung eines Anbieters zu streiten, fragt das Team: Ist es realistisch, 4 von 22 Stunden im Monat zu beseitigen? Die Produktion kann das anhand der Stillstandsgründe beurteilen.
Halten Sie zwei Listen getrennt. Harte Einsparungen werden in Geld gemessen: Stillstand, Ausschuss, Überstunden, Fracht. Weicher Nutzen, etwa schnellere Audits oder eine leichtere Einarbeitung, kommt auf eine eigene Liste und wird nicht zur Summe addiert. Ein CFO vertraut dem Business Case eher, wenn die weiche Liste klar gekennzeichnet ist.
Schritt 3: die Gesamtkosten zählen
Abonnementgebühren sind nur ein Teil der Kosten:
- Software: pro Modul, pro Standort, pro Benutzer, je nach Preismodell.
- Einführung: Konfiguration, Bereinigung der Stammdaten, Tests.
- Integration: ERP, bestehendes CMMS oder WMS, Maschinendaten.
- Hardware: Tablets, Scanner, Edge-Geräte, Änderungen am Netzwerk in der Fertigung.
- Interne Zeit: Key User, IT/OT, Schichtleiter während der Schulung. Das sind echte Kosten, auch wenn keine Rechnung kommt.
- Change Management: Schulung, neue Routinen, Begleitung in den ersten Monaten.
Kürzen Sie den letzten Punkt nicht, damit die Zahlen aufgehen. Die Forschung von Prosci ergab, dass Projekte mit exzellentem Change Management etwa siebenmal häufiger ihre Ziele erreichten als Projekte mit schlechtem Change Management: 88 % gegenüber 13 %.
Schritt 4: den Pilot zum Beweis machen
Im Pilot wird der Business Case bestätigt oder beendet. Vereinbaren Sie vor dem Start schriftlich:
- Die Linie und den Umfang: welche Module, welche Schichten.
- Die Kennzahlen: dieselben Definitionen wie in der Ausgangsbasis.
- Das Ziel: den Break-even-Wert aus Schritt 2, plus ein ehrgeizigeres Ziel.
- Den Entscheidungstermin: wann Controlling und Produktion die Ergebnisse vergleichen.
- Die Regel: welches Ergebnis zum Ausrollen, zu einem zweiten Pilot oder zum Abbruch führt.
Entscheidet das Werk zugleich über eine Layoutänderung oder neue Anlagen, testen Sie das getrennt in einer Simulation. Wie Sie einen Business Case für einen digitalen Zwilling aufbauen behandelt Investitionsentscheidungen. Die Auswahl zwischen Anbietern vor dem Pilot behandelt der Artikel Wie Sie ein Plant Operating System bewerten.
Wie das in DBR77 IRIS funktioniert
DBR77 IRIS unterstützt einen Business Case, der klein beginnt. Die Preise gelten pro Modul, sodass der Pilot ein Modul an einer Linie abdecken kann; weitere Module lassen sich später ergänzen, wobei Daten und Konfigurationen übernommen werden. Der Monatspreis umfasst Hosting, Updates und Standard-Support. Einführung, individuelle Integrationen und Premium-Schulungen werden separat angeboten, sodass sie von Anfang an in der Kostenzeile stehen können.
Die IRIS-Preisseite hat einen ROI-Rechner, der nach Linien, ungeplanten Stillstandsstunden pro Monat, Instandhaltungsbudget und Qualitätskosten fragt. Seine Ergebnisse sind Schätzungen auf Basis von Branchen-Benchmarks; betrachten Sie sie also als ersten Entwurf und ersetzen Sie sie durch Ihre Ausgangsbasis.
Während des Pilots verfolgen IRIS KPI und die Qualitätsanalysen in IRIS QMS dieselben Kennzahlen wie die Ausgangsbasis: OEE, MTBF, MTTR, geplanter und ungeplanter Stillstand, Erstdurchlaufquote und Kosten schlechter Qualität, mit Drill-down vom Werk bis zu Linie, Schicht und Maschine. So wird der Vorher-nachher-Vergleich zu einem Bericht, nicht zu einer Diskussion.
Häufige Fragen
Können wir Benchmark-Zahlen von Anbietern im Business Case verwenden?
Nur als Einordnung. Das Controlling sollte Ihre eigene Ausgangsbasis und ein Break-even-Ziel sehen. Benchmarks aus anderen Werken beschreiben andere Werke.
Was, wenn wir keine Daten für eine Ausgangsbasis haben?
Messen Sie vier Wochen lang an einer Linie von Hand: Stillstandszeiten und -gründe, Ausschussmengen, Stunden für das Abtippen. Grobe eigene Daten sind besser als präzise geliehene.
Welche Amortisationszeit sollten wir anstreben?
Nutzen Sie dieselbe Hürde, die Ihr Werk für Anlagen verwendet, und beurteilen Sie sie nach denselben Regeln.
Fazit
Ein Business Case für ein Plant Operating System braucht keine erfundenen Zahlen. Er braucht eine Ausgangsbasis von Ihrer eigenen Linie, einen Wert für jeden Verlust, eine vollständige Kostenliste und ein Break-even-Ziel, das ein Pilot bestätigen kann. So bekommt das Controlling eine Zahl, die es prüfen kann, und die Produktion ein Ziel, für das sie Verantwortung übernehmen kann.
Quellen
- McKinsey & Company, How digital manufacturing can escape "pilot purgatory", 2018
- ASQ, Cost of Quality (COQ)
- Siemens, The True Cost of Downtime 2024, 2024
- Prosci, The Correlation Between Change Management and Project Success, 2023