CASE 07 · PRODUZIERENDER MITTELSTAND
Nicht jede Lücke braucht Eigenentwicklung.
In einem laufenden ERP-Projekt wurden im Rahmen der ERP-Beratung und Fit-Gap-Prüfung Change Requests vom Anbieter mit 640.000 € bewertet. Gemeinsam mit Kunde, Fachbereichen und Softwarehaus wurde jede Anforderung erneut am realen Geschäftsfall geprüft. Der vom Anbieter bewertete Umfang sank auf 185.000 €.
Was wurde konkret verändert?
Standard → Konfiguration → Prozessanpassung → begründete Restlücke
Jede geplante Erweiterung musste am tatsächlichen Geschäftsfall und am Standard geprüft werden.
Bewerteter Umfang aus Fit-Gap-Analysen und Change Requests im laufenden ERP-Projekt.
Beratende Projektleitung · NBC-Mandat · anonymisiert, ohne identifizierende Merkmale
Entwickelt wurde nur, was der Standard nicht sinnvoll abbildete.
Für zahlreiche Anforderungen stand zunächst individuelle Entwicklung im Raum. Vor einer Freigabe wurde deshalb am tatsächlichen Geschäftsfall geprüft, ob vorhandene Funktionen, Konfiguration oder eine vertretbare Prozessänderung den Bedarf bereits erfüllen konnten.
Nur Anforderungen mit einer verbleibenden, fachlich begründeten Lücke wurden weiter als Sonderentwicklung betrachtet. Diese Prüfung veränderte den geplanten Entwicklungsumfang und machte nachvollziehbar, wofür individueller Code weiterhin erforderlich war.
NBC / ERP
Eigenentwicklung ist oft ein sehr teuresDenkmal für einen Prozess,den niemand anfassen wollte.
Eigenentwicklung blieb die begründete Restlücke.
Die vom Anbieter bewerteten Change Requests wurden nicht als gegebener Entwicklungsbedarf akzeptiert. Jede Anforderung wurde gemeinsam mit Fachbereichen, Kunde und Softwarehaus erneut gegen realen Geschäftsfall, Standard, Konfiguration und Prozessstandardisierung geprüft.
Messbasis im Überblick
MEINE ROLLE IM PROJEKT
Meine Rolle lag in der fachlichen Neuprüfung der als Change Requests bewerteten Anforderungen und in der Moderation zwischen Fachbereichen, Kunde und Softwarehaus. Ich habe die Entscheidung so strukturiert, dass Standard, Konfiguration und Prozessanpassung vor individueller Entwicklung geprüft wurden.
GESCHÄFTLICHE RELEVANZ
Im laufenden ERP-Projekt stand nicht nur der Preis einzelner Change Requests zur Diskussion. Jede unnötige Eigenentwicklung hätte zusätzliches Budget und technische Komplexität erzeugt; nach der Neuprüfung blieb nur die fachlich begründete Restlücke mit 185.000 € bewertetem Umfang.
Fit-Gap-Entscheidungsprotokoll öffnen
REKONSTRUIERTER ARBEITSAUSZUG
fiktive AnforderungenFit-Gap Entscheidungsprotokoll · vier mögliche Endpunkte
Die Beispiele machen die Entscheidungsregel greifbar, ohne die tatsächlichen Projektanforderungen nachzuerfinden.
AnforderungStandardwegKonfigurationProzessEntscheidung
Liefertermin im Standardauftragdeckt Bedarfnicht erforderlichnicht erforderlich
Standard reicht
Variantenabhängige FreigaberegelGrundfunktion vorhandenRegel parametrierbarnicht erforderlich
Konfiguration reicht
Zusätzliche interne Prüfschleifefachlicher Kern abgedecktkeine Zusatzlogik nötigPrüfschritt organisatorisch vorziehen
Prozessanpassung reicht
Spezialfreigabe mit technischem Nachweisnicht vollständigreicht nichtfachliche Pflicht bleibt
Restlücke → Business Case
ERGEBNIS & MESSBASIS640.000 € → 185.000 € vom Anbieter bewerteter Umfang · Differenz 455.000 € ≈ 71,1 % · kein ausgewiesener Netto-Projektgewinn
So sind wir vorgegangen
Die Prüfung setzte nicht beim Preis der Change Requests an, sondern bei ihrer fachlichen Notwendigkeit. Jede als Sonderentwicklung bewertete Anforderung musste deshalb erneut erklären, welchen realen Geschäftsfall sie abbildet und warum der Standard nicht reicht.
AusgangslageEin bestehendes Lastenheft hatte Anforderungen teilweise nicht präzise genug geklärt. Im späteren Projektverlauf entstanden daraus Fit-Gap-Analysen und Change Requests mit einem vom Anbieter bewerteten Umfang von 640.000 Euro.
NeuprüfungGemeinsam mit Kunde, Fachbereichen und Softwarehaus wurde jede Anforderung fachlich neu verstanden: Was ist tatsächlich gemeint, wie wird der Prozess genutzt und welcher Teil ist wirklich unverzichtbar?
AlternativenVor einer Eigenentwicklung wurden konsequent Standard, Konfiguration und eine sinnvolle Prozessstandardisierung beziehungsweise Prozessanpassung geprüft. Erst danach durfte eine Restlücke als Entwicklung weiterlaufen.
RestumfangNur branchenspezifische Funktionen, die die vorhandene Lösung tatsächlich nicht sinnvoll abbilden konnte, blieben bestehen. Der vom Anbieter bewertete Umfang sank dadurch von 640.000 auf 185.000 Euro.
PROJEKTLOGIK · ENTSCHEIDUNGEN
Darauf kam es an.
Der entscheidende Schritt war, „Abweichung vom heutigen Prozess“ nicht automatisch mit „Softwarelücke“ gleichzusetzen. Eigenentwicklung wurde erst nach drei vorgelagerten Prüfungen zulässig.
Standard zuerst gegen den echten Geschäftsfall prüfen
Nicht die bestehende Arbeitsweise wurde eins zu eins zum Soll erklärt. Zuerst wurde geprüft, ob der fachliche Zweck bereits im Standard erreichbar ist.
Konfiguration und Prozessanpassung als echte Lösungen zulassen
Parametrisierung oder eine sinnvoll standardisierte Arbeitsweise waren keine zweitklassigen Kompromisse, sondern bewusst gleichwertige Lösungswege vor individueller Entwicklung.
Nur die verbleibende Restlücke entwickeln
Erst wenn Standard, Konfiguration und vertretbare Prozessstandardisierung nicht ausreichten, wurde eine Anforderung zur Entwicklungsfrage. Dadurch ließ sich der bewertete Umfang deutlich reduzieren.
Prüfen Sie eine geplante Eigenentwicklung vor dem Auftrag.
Eine Anforderung wird erst dann zur Entwicklungsfrage, wenn Standard, Konfiguration und eine sinnvolle Prozessanpassung fachlich nicht ausreichen.
- „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.
- Eine Anforderung wird bereits als Change Request bewertet, bevor der reale Geschäftsfall erneut gegen den Standard geprüft wurde.