Fertigungsanforderungen wurden zunächst fast automatisch als Sonderentwicklung eingeordnet. Standard, Konfiguration, Prozessanpassung und echte Restlücke waren fachlich nicht sauber voneinander getrennt.
640.000 € → 185.000 €diskutiert → verbleibend
~430Mitarbeitende
18 MonateProjekt
DER FALL IN 15 SEKUNDEN
Jede Anforderung wurde zum Customizing.
Die kritische Frage war nicht, wie viel Individualität technisch möglich ist, sondern welche Abweichungen wirklich geschäftskritisch und wirtschaftlich begründet sind.
01 · VORHER
FERTIGUNGAblauf Agewachsen
PLANUNGRegel Bhistorisch
LOGISTIKAusnahme Clokal
QUALITÄTPrüfung Dindividuell
CUSTOMIZATION TRAP„Standard kann das nicht“ wird zur Ausgangsannahme – nicht zum geprüften Ergebnis.
DISKUTIERTER UMFANG640.000 €Change Requests
Gewachsene Abläufe wurden vorschnell zu Software-Sonderfällen.Anforderung → Customizing, ohne vorgelagerten Fit-Nachweis.
02 · ENTSCHEIDUNG
Was ist wirklich eine Restlücke?
01Standardnachgewiesener Fit
02Konfigurationohne Entwicklung
03ProzessanpassungArbeitsweise ändern
04Restlückewirtschaftlich begründen
Ein Fit-to-Standard-Gate zwingt jede Individualität zur Begründung.Fachliche Projektleitung · Priorisierung · CR-Prüfung
03 · DANACH
STANDARDübernimmtnachgewiesener Fit
KONFIGURATIONübernimmtohne Custom Code
PROZESSpasst sich anwo wirtschaftlich sinnvoll
RESTLÜCKEbleibt sichtbarbewusst akzeptiert
NEUER ENTSCHEIDUNGSZUSTANDNur begründete Restlücken bleiben individuell; Standard und Konfiguration tragen den übrigen Umfang.
VERBLEIBENDER UMFANG185.000 €dokumentierte CRs
Individualität wurde wirtschaftlich begrenzt, nicht technisch verboten.Sonderentwicklungsumfang; kein bereits verbuchter Jahresgewinn.
WAS WIR VERÄNDERT HABEN
Nicht jede Abweichung ist eine Softwarelücke.
VerworfenJede Anforderung wurde zum Customizing.
EntschiedenNicht jede Abweichung ist eine Softwarelücke.
01 · ANFORDERUNG
Prozessbezug vor Lösungswunsch.
Anforderungen wurden zuerst fachlich beschrieben, bevor aus ihnen eine technische Sonderentwicklung werden durfte.
02 · NACHWEIS
Standardfit musste gezeigt werden.
Demo, Beispieldaten und offene Rückfragen dienten als Nachweis – nicht die Länge einer Featureliste oder eine ungeprüfte Aussage.
03 · WIRTSCHAFTLICHKEIT
Restlücken wurden bewusst entschieden.
Nur Anforderungen, die nach Standard, Konfiguration und Prozessanpassung offen blieben, wurden als wirtschaftlich zu begründende Restlücken behandelt.
ÜBERTRAGBARKEIT
Kommt Ihnen das bekannt vor?
Dieser Case ist besonders relevant, wenn ERP-Anforderungen schnell in Customizing übersetzt werden und Projektbudget sowie Komplexität mit jeder Fachanforderung wachsen.
„Das muss individuell entwickelt werden“ fällt, bevor Standard oder Konfiguration belastbar geprüft wurden.
Historisch gewachsene Abläufe werden eins zu eins als Systemanforderung übernommen.
Change Requests wachsen, ohne dass Restlücken nach geschäftlicher Relevanz und Wirtschaftlichkeit priorisiert werden.
Dann sollte jede Restlücke erst fachlich und wirtschaftlich begründet werden – bevor sie zur Sonderentwicklung wird.
ARBEITSARTEFAKT · ANONYMISIERTPHASE 7.2 · EVIDENCE PAPER
Arbeitslogik statt Mockup. Der Ausschnitt zeigt die dokumentierte Fit-to-Standard-Prüfung. Messbasis: Projektplan, Budget und dokumentierte Change Requests.
Datenschutz: redaktionell neu gesetzt aus den bereits anonymisierten Case-Angaben; keine Kundenbezeichnung, personenbezogenen Daten oder erfundenen Dashboard-Werte.
DER NACHWEIS
Dokumentierter Projektkontext.
Die Wirkung bleibt an Messbasis, Rolle und Projektgrenze gebunden. Details sind verfügbar, ohne die Hauptgeschichte zu überladen.
Welche Sonderentwicklung ist bei Ihnen wirklich geschäftskritisch?
Bringen Sie eine konkrete ERP-Anforderung oder Change-Request-Liste mit. Wir prüfen Standardfit, Konfiguration, mögliche Prozessanpassung und die wirtschaftliche Begründung verbleibender Restlücken.
