SAPHIR GmbHSAPHIR GmbHSAPHIR GmbH
(Montag - Freitag)
info@saphirgmbh.de
91564 Neuendettelsau

Vom Praxisfall zur Zahl: Beispielrechnung für einen mittelständischen Industriekunden

Die Implementierung ist unkompliziert: Innerhalb weniger Wochen steht ein funktionsfähiger Prototyp, der mit minimalem Aufwand skaliert werden kann.

Vom Praxisfall zur Zahl: Beispielrechnung für einen mittelständischen Industriekunden

Von Wolfgang Klaus, Tech Lead, SAPHIR GmbH

Im letzten Beitrag habe ich den KI-gestützten Discovery-Workshop als Alternative zum monatelangen klassischen Anforderungsprozess beschrieben. Damit das nicht abstrakt bleibt, rechne ich das Ganze in diesem Beitrag an einem realistischen, typischen Praxisfall durch: einem global aufgestellten Industrieunternehmen aus dem deutschen Mittelstand.

Vom Praxisfall zur Zahl: Beispielrechnung für einen mittelständischen Industriekunden
Vom Praxisfall zur Zahl: Beispielrechnung für einen mittelständischen Industriekunden

Das Szenario

Damit die Rechnung greifbar bleibt, lege ich ein konkretes, aber typisches Kundenprofil zugrunde:

  • Umsatz: rund 250 Mio. Euro pro Jahr (bewusst innerhalb der genannten Spanne von 50 bis 770 Mio. Euro gewählt, weil sich in dieser Größenordnung das beschriebene Problem besonders häufig zeigt)
  • Branche: Maschinen- und Anlagenbau mit Serien- und Auftragsfertigung
  • Standorte: vier Produktionsstandorte – Deutschland, Polen, China, USA – plus mehrere Vertriebsniederlassungen
  • ERP-System: ein marktübliches Standard-ERP-System (z. B. SAP S/4HANA oder ein vergleichbares System), zentral betrieben, lokal angepasst

Bewusst habe ich das ursprüngliche Szenario an zwei Stellen präzisiert, weil sich beide Punkte in der Praxis fast immer so zeigen:

Erstens, welche Prozesse dem ERP-Standard typischerweise entgleiten. In der Praxis sind das selten die Kernprozesse wie Finanzbuchhaltung oder Materialwirtschaft, sondern eher unternehmensspezifische Randprozesse mit hoher Komplexität: mehrstufige, standortübergreifende Freigabeprozesse für kundenspezifische Sonderkonfigurationen, die Anbindung von Maschinen- und Sensordaten aus der Produktion für vorausschauende Wartung, oder plant-übergreifende Verfügbarkeitsprüfungen mit länderspezifischen Ausnahmeregeln. Genau für solche Prozesse braucht es eine Applikationsebene oberhalb des ERP-Systems, die orchestriert, was das Standardsystem nicht abbilden kann oder soll, ohne den ERP-Kern selbst aufwendig zu individualisieren.

Zweitens, warum Live-Daten für den MVP-Aufbau so schwer zugänglich sind. Das liegt in global aufgestellten Unternehmen selten an bösem Willen, sondern an strukturellen Gründen: unterschiedliche Datenschutzanforderungen je nach Land (insbesondere beim Datentransfer zwischen EU, USA und China), interne Freigabeprozesse für den Zugriff auf Produktivsysteme, Sorge vor Systeminstabilität bei Testzugriffen auf Live-Umgebungen sowie schlicht organisatorische Trägheit, weil Datenverantwortliche in mehreren Ländern und Abteilungen zustimmen müssen. In der Praxis vergehen für die reine Freigabe von Live-Datenzugriffen häufig Wochen bis Monate – parallel zur eigentlichen Anforderungsphase.

Der Lösungsansatz für dieses Szenario

Für die Applikationsebene selbst greift der im letzten Beitrag beschriebene Workshop-Ansatz. Für das Datenproblem kommt ergänzend eine synthetische Datengrundlage zum Einsatz: Statt auf echte Live-Daten zu warten, wird auf Basis des vorhandenen Datenschemas sowie grober, freigegebener statistischer Kennzahlen (Wertebereiche, Verteilungen, typische Ausnahmefälle) ein realistischer, aber anonymisierter Testdatensatz KI-gestützt erzeugt. Damit lässt sich der Prototyp aufbauen und mit den Fachbereichen validieren, ohne auf die oft monatelange Freigabe echter Produktivdaten warten zu müssen. Der Abgleich mit echten Daten erfolgt dann gezielt in einer späteren, kleineren Testphase – nachdem der Prototyp bereits sein grundsätzliches Vertrauen beim Kunden gewonnen hat.

Die Beispielrechnung

Die folgende Rechnung ist ein vereinfachtes, illustratives Modell auf Basis typischer Erfahrungswerte aus vergleichbaren Projekten. Die tatsächlichen Zahlen hängen naturgemäß von Projektumfang, Beteiligten und Verhandlungssituation ab – sie sollen hier vor allem die Größenordnung des Effekts zeigen, nicht als exakte Kalkulation für ein konkretes Angebot dienen.

Angenommene Ausgangsgrößen:

GrößeAnnahme
Beteiligte Stakeholder je Meeting6 Personen (Vertrieb, Produktion, Qualität, IT – über 4 Standorte verteilt)
Interner Vollkostensatz je Person85 € / Stunde
Externer Tagessatz Dienstleister950 € / Personentag

Klassischer Ansatz – Anforderungsphase über 7 Monate:

PostenRechnungKosten
Interne Meeting-Zeit45 Meetings à 1,5 Std. × 6 Personen × 85 €/Std.34.425 €
Externe Beratungsleistung Vorprojekt180 Personentage × 950 €/Tag171.000 €
Summe ≈ 205.400 €
Zeitbedarf bis validiertes Anforderungsbild ≈ 7 Monate

KI-gestützter Ansatz – Workshop, Synthese, Prototyp:

PostenRechnungKosten
Discovery-Workshop (gebündelt)2 Tage × 8 Std. × 6 Personen × 85 €/Std.8.160 €
KI-gestützte Synthese, synthetische Testdaten, Prototyp15 Personentage × 950 €/Tag14.250 €
Summe ≈ 22.400 €
Zeitbedarf bis validierter Prototyp ≈ 3 Wochen

Modellhafter Effekt: In diesem vereinfachten Rechenbeispiel sinken die direkten Kosten bis zum validierten Ergebnis um etwa 89 Prozent, die Zeit bis zu einer belastbaren Entscheidungsgrundlage verkürzt sich von rund sieben Monaten auf etwa drei Wochen.

Was diese Zahl nicht zeigt – und warum das wichtig ist

Diese Modellrechnung berücksichtigt bewusst noch nicht den größten wirtschaftlichen Hebel: die Opportunitätskosten der Verzögerung selbst. Wenn beispielsweise die manuelle Nacharbeit bei Sonderfreigaben oder ungeplante Maschinenstillstände durch fehlende vorausschauende Wartung im bestehenden Zustand laufende Kosten verursachen, dann zählt jeder Monat frühere Umsetzung zusätzlich – unabhängig von den reinen Projektkosten. Diese Effekte sind im Einzelfall oft deutlich größer als die reine Differenz der Projektkosten, lassen sich aber ohne konkrete Kundendaten seriös nicht pauschal beziffern und wurden deshalb hier bewusst nicht mit eingerechnet.

Fazit

Am konkreten Fall zeigt sich, was in den vorherigen Beiträgen theoretisch beschrieben wurde: Die Standardisierung des Onboarding- und Anforderungsprozesses selbst ist keine akademische Übung, sondern hat bei einem typischen, global aufgestellten Mittelstandskunden einen direkt bezifferbaren wirtschaftlichen Effekt – sowohl in Kosten als auch in Zeit bis zur ersten belastbaren Entscheidung.