Ein JD-Edwards-EnterpriseOne-Upgrade gehört zu den strategischsten IT-Projekten, die ein Unternehmen angehen kann. Richtig durchgeführt, modernisiert es zentrale Geschäftsprozesse, senkt die Betriebskosten und löst jahrelang aufgestaute technische Schulden auf. Falsch durchgeführt, kann es den Betrieb monatelang stören und die gesamte ERP-Investition gefährden.

Der Unterschied zwischen den beiden Ergebnissen liegt selten in der Technologie. Er liegt in der Methodik. Nach vielen JDE-Upgrade-Projekten in der Fertigung, im Großhandel und im Einzelhandel ist das Muster immer dasselbe: Erfolgreich sind die Projekte, in denen der Custom Code vor dem Entwicklungsstart sauber analysiert wird.

Dieser Leitfaden erklärt genau, wie das geht – mit demselben Framework, das wir in realen Enterprise-Upgrade-Projekten einsetzen.

Warum JDE-Upgrades scheitern (und wie Sie es vermeiden)

Die größte Risikoquelle bei jedem JD-Edwards-EnterpriseOne-Upgrade ist unkontrollierter Custom Code. Eine typische ausgereifte JDE-Installation sammelt im Laufe ihrer Lebensdauer zwischen 10.000 und 12.000 Custom-Objekte an – Anwendungen, Reports, Business Functions, Business Views, Tabellen. Die meisten dieser Objekte haben ihre ursprünglichen Entwickler überlebt. Die Dokumentation ist lückenhaft oder fehlt ganz. Namenskonventionen haben sich verschoben. Und niemand weiß wirklich, welche Custom-Objekte noch im Einsatz sind, welche Duplikate von Standards sind und welche tatsächlich brechen würden, wenn Oracle in der nächsten Version etwas ändert.

Wenn Upgrade-Teams diese Komplexität ignorieren und direkt in die Entwicklung springen, wächst das Projekt aus dem Ruder. Schätzungen verdoppeln sich. Tests finden endlose Regressionen. Der Go-Live verschiebt sich um Quartale.

Der richtige Ansatz ist das Gegenteil: ernsthaft Zeit in die Assessment-Phase investieren, jedes Custom-Objekt klassifizieren und erst danach die Entwicklungsarbeit planen. Korrekt durchgeführt, lässt sich die Entwicklungsphase eines JDE-Upgrades auf 6 bis 9 Wochen komprimieren – auch bei Repositories in Enterprise-Größe.

Die Methodik zur Analyse von Custom-Objekten

Die Methodik beruht auf einem einfachen, aber wirkungsvollen Prinzip: Nicht jedes Custom-Objekt muss während eines Upgrades neu entwickelt werden. Die meisten lassen sich sichern und automatisch wieder einspielen. Nur ein kleiner Teil – die wirklich betroffenen – erfordert manuelle Retrofit-Arbeit.

So läuft die Analyse ab:

Die vier Phasen der Analyse sind:

Phase 1 – Inventar. Extrahieren Sie das vollständige Repository der Custom-Objekte aus der Kundenumgebung. Typisches Volumen: 10.000–12.000 Objekte.

Phase 2 – Intelligente Filterung. Entfernen Sie veraltete Objekte, Duplikate, aufgegebene Entwicklungs-Branches und überholte Objekte. Allein dieser Schritt reduziert die Arbeitsmenge auf 3.000–4.000 Objekte – rund zwei Drittel weniger.

Phase 3 – Oracle-Abgleich. Vergleichen Sie jedes verbleibende Custom-Objekt mit den Netto-Änderungen von Oracle (ESU, Planner ESU, Tools-Release-Deltas) für die Zielversion. Das Ergebnis: welche Oracle-Standards sich tatsächlich zwischen Quell- und Zielversion geändert haben.

Phase 4 – Klassifizierung der Auswirkungen. Der finale Filter identifiziert die Objekte, die sowohl vom Kunden als auch von Oracle modifiziert wurden. Das sind die wirklich betroffenen – typischerweise nur 200 bis 500 Objekte von ursprünglich über 10.000.

Die drei Kategorien von Custom-Objekten

Nach Abschluss der Analyse fällt jedes Custom-Objekt in eine von drei Kategorien, und jede Kategorie hat einen anderen Aktionsplan.

Nicht betroffene Custom-Objekte (~95 % der Arbeitsmenge). Das sind Objekte, die der Kunde modifiziert hat, die Oracle aber im neuen Release nicht angefasst hat. Die Aktion ist mechanisch: vor dem Upgrade sichern, danach wiederherstellen. Kein manueller Entwicklungsaufwand. Hier zahlt sich die Methodik aus – der Großteil des Custom Codes gelangt gar nicht erst auf den kritischen Entwicklungspfad.

Betroffene Custom-Objekte (~5 % der Arbeitsmenge). Das sind die Objekte, die sowohl vom Kunden als auch von Oracle modifiziert wurden. Sie erfordern einen manuellen Retrofit: Der Entwickler prüft die Oracle-Änderungen, versteht, was der neue Standard tut, und führt die Anpassungen des Kunden in die neue Version zusammen. Hier konzentriert sich die eigentliche Entwicklungsarbeit.

Reine Standards. Objekte, die der Kunde nie modifiziert hat. Sie werden einfach durch das neue Oracle-Release ersetzt. Null Aufwand für den Kunden.

Die Tatsache, dass von über 10.000 Objekten nur 200–500 manuelle Arbeit erfordern, macht eine Entwicklungsphase von 6 bis 9 Wochen realistisch. Ohne diese Filterung würde dasselbe Upgrade 6 bis 9 Monate dauern.

Ein realistischer Entwicklungs-Zeitplan

So sieht die Entwicklungsphase eines gut geplanten JDE-Upgrades in der Praxis aus:

Beachten Sie, dass dieser Zeitplan nur die Entwicklungsphase abdeckt. Funktionstests, User Acceptance Tests, Endanwender-Schulungen und Go-Live-Aktivitäten werden separat vom Kundenteam gesteuert und folgen einem eigenen Zeitplan. Die Entwicklungsphase liefert die aktualisierte, testbereite Codebasis.

Die Phasen überlappen sich bewusst. Backup und Umgebungs-Setup beginnen, sobald das Assessment weit genug fortgeschritten ist. Das eigentliche Oracle-Upgrade (Tools Release plus ESUs) startet noch vor dem vollständigen Abschluss des Assessments. Und die längste Phase – der manuelle Retrofit der betroffenen Objekte – läuft mehrere Wochen lang parallel zu allem anderen.

Was vor dem Start zu tun ist

Bevor ein JDE-EnterpriseOne-Upgrade-Projekt gestartet wird, müssen drei Voraussetzungen erfüllt sein.

Ein klares Inventar der Quellumgebung. Das bedeutet, genau zu wissen, welche EnterpriseOne-Version und welches Tools Release der Kunde derzeit einsetzt, welche Datenbank und welche Middleware sie unterstützen und welche Integrationen mit Drittsystemen bestehen.

Eine definierte Zielarchitektur. Entscheiden Sie von Anfang an, ob das Upgrade nur ein Versionssprung auf der bestehenden Infrastruktur ist oder ob ein Plattformwechsel dazugehört – auf Oracle Cloud Infrastructure, AWS oder Azure. Diese Entscheidungen während der Umsetzung zu vermischen, ist das sichere Rezept für Verzögerungen.

Executive Sponsorship. Ein JDE-Upgrade berührt jeden Funktionsbereich des Unternehmens. Ohne einen Sponsor auf C-Level, der bereichsübergreifende Konflikte schnell lösen kann, kommt das Projekt beim ersten Streit zwischen Finance und Operations über Test-Prioritäten zum Stillstand.

Häufige Fehler, die zu vermeiden sind

Auch mit einer soliden Methodik können JDE-Upgrade-Projekte aus dem Ruder laufen. Die häufigsten Fehler:

Die Assessment-Phase überspringen, um „Zeit zu sparen“. Das kostet später immer mehr Zeit. Die 1–2 Wochen Vorab-Analyse sparen nachgelagert Monate.

Alle Custom-Objekte gleich behandeln. Ein Custom-Report, den vor fünf Jahren drei Anwender genutzt haben, verdient nicht denselben Aufwand wie eine täglich ausgeführte Business Function im Order-to-Cash-Prozess.

Das Testfenster unterschätzen. Selbst mit einer sauberen Entwicklungsphase braucht das Kundenteam ausreichend Zeit für Funktionstests, Regressionstests und User Acceptance. Diese Phase zu komprimieren, führt zu Go-Live-Fehlern.

Scope-Änderungen mit dem Upgrade vermischen. Neue Funktionen, neue Module und neue Integrationen sollten in ein Folgeprojekt verschoben werden. Das Upgrade selbst muss eine Like-for-Like-Migration auf das neue Release sein.

Fazit

Ein JD-Edwards-EnterpriseOne-Upgrade ist kein Sprung ins Ungewisse. Mit der richtigen Methodik – einer sauberen Analyse der Custom-Objekte, intelligenter Filterung und einer klaren Trennung zwischen betroffenen und nicht betroffenen Objekten – wird die Entwicklungsphase planbar, schnell und risikoarm.

Das Entwicklungsfenster von 6 bis 9 Wochen ist auf Repositories in Enterprise-Größe erreichbar – auch bei mehr als 10.000 Custom-Objekten –, weil die große Mehrheit dieser Objekte niemals manuell überarbeitet werden muss.

Wenn Sie ein JD-Edwards-EnterpriseOne-Upgrade planen und besprechen möchten, wie sich diese Methodik auf Ihre Umgebung anwenden lässt, stehen unsere zertifizierten Berater bereit.