Ein JD-Edwards-EnterpriseOne-UpgradeUpgrade-Projekt für JD Edwards EnterpriseOne: umfasst Anwendungscode, Objekte, Datenbank, Tools ReleaseTools Release: technische JD-Edwards-Plattformversion für Runtime, Serverkomponenten, Webclient und Entwicklungswerkzeuge., ESUsElectronic Software Updates: Oracle-Pakete mit Korrekturen und Änderungen für JD Edwards EnterpriseOne. und technische Infrastruktur. 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-ProjektenProjekte zur Aktualisierung von JD Edwards EnterpriseOne über Releases, Tools Releases oder ESUsElectronic Software Updates: Oracle-Pakete mit Korrekturen und Änderungen für JD Edwards EnterpriseOne. hinweg. in der Fertigung, im Großhandel und im Einzelhandel ist das Muster immer dasselbe: Erfolgreich sind die Projekte, in denen der Custom CodeKundenspezifischer Code: angepasste oder neu erstellte JDE-Objekte außerhalb des Oracle-Standards. 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-UpgradesUpgrades von JD Edwards EnterpriseOne auf eine neue Zielversion oder technische Plattform. scheitern (und wie Sie es vermeiden)
Die größte Risikoquelle bei jedem JD-Edwards-EnterpriseOne-UpgradeUpgrade-Projekt für JD Edwards EnterpriseOne: umfasst Anwendungscode, Objekte, Datenbank, Tools ReleaseTools Release: technische JD-Edwards-Plattformversion für Runtime, Serverkomponenten, Webclient und Entwicklungswerkzeuge., ESUsElectronic Software Updates: Oracle-Pakete mit Korrekturen und Änderungen für JD Edwards EnterpriseOne. und technische Infrastruktur. ist unkontrollierter Custom CodeKundenspezifischer Code: angepasste oder neu erstellte JDE-Objekte außerhalb des Oracle-Standards.. Eine typische ausgereifte JDE-InstallationKonkrete EnterpriseOne-Umgebung eines Unternehmens, inklusive Objekten, Path Codes, Datenquellen und Integrationen. sammelt im Laufe ihrer Lebensdauer zwischen 10.000 und 12.000 Custom-ObjekteKundenspezifische JDE-Objekte wie AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business Functions, Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und NERs. an – AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business FunctionsBusiness Functions: kompilierter C-Code in JD Edwards, der Geschäftslogik im Call Object Kernel ausführt., Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden.. 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-ObjekteKundenspezifische JDE-Objekte wie AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business Functions, Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und NERs. 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-LiveGo-Live: Zeitpunkt, an dem die aktualisierte JD-Edwards-Umgebung produktiv genutzt wird. verschiebt sich um Quartale.
Der richtige Ansatz ist das Gegenteil: ernsthaft Zeit in die Assessment-PhaseAssessment-Phase: Analyse vor der Entwicklung, in der Custom CodeKundenspezifischer Code: angepasste oder neu erstellte JDE-Objekte außerhalb des Oracle-Standards., Risiken und betroffene Objekte klassifiziert werden. investieren, jedes Custom-ObjektEin kundenspezifisches JDE-Objekt, das nicht unverändert aus dem Oracle-Standard stammt. klassifizieren und erst danach die Entwicklungsarbeit planen. Korrekt durchgeführt, lässt sich die Entwicklungsphase eines JDE-UpgradesUpgrades von JD Edwards EnterpriseOne auf eine neue Zielversion oder technische Plattform. auf 6 bis 9 Wochen komprimieren – auch bei RepositoriesRepositories: Bestände von JD-Edwards-Objekten in Umgebungen oder Path Codes. in Enterprise-Größe.
Die Methodik zur Analyse von Custom-Objekten
Die Methodik beruht auf einem einfachen, aber wirkungsvollen Prinzip: Nicht jedes Custom-ObjektEin kundenspezifisches JDE-Objekt, das nicht unverändert aus dem Oracle-Standard stammt. 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-ArbeitRetrofitRetrofit: erneutes Einbringen kundenspezifischer Änderungen in den neuen Oracle-Standard nach einem Upgrade.: erneutes Einbringen kundenspezifischer Änderungen in den neuen Oracle-Standard nach einem Upgrade..
So läuft die Analyse ab:

Die vier Phasen der Analyse sind:
Phase 1 – Inventar. Extrahieren Sie das vollständige RepositoryRepository: Bestand der JD-Edwards-Objekte in einer Umgebung oder einem Path Code. der Custom-ObjekteKundenspezifische JDE-Objekte wie AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business Functions, Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und NERs. 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-ObjektEin kundenspezifisches JDE-Objekt, das nicht unverändert aus dem Oracle-Standard stammt. mit den Netto-Änderungen von Oracle (ESUElectronic Software Update: Oracle-Paket mit Korrekturen und Änderungen für JD Edwards EnterpriseOne., Planner ESUElectronic Software Update: Oracle-Paket mit Korrekturen und Änderungen für JD Edwards EnterpriseOne.Planner ESUElectronic Software Update: Oracle-Paket mit Korrekturen und Änderungen für JD Edwards EnterpriseOne.: Oracle-Paket, das Upgrade-Planung, Objektänderungen und benötigte Updates für den Zielstand unterstützt., Tools-Release-DeltasÄnderungen zwischen Tools Releases, die technische Objekte, Runtime-Verhalten oder Metadaten beeinflussen können.) 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-ObjektEin kundenspezifisches JDE-Objekt, das nicht unverändert aus dem Oracle-Standard stammt. in eine von drei Kategorien, und jede Kategorie hat einen anderen Aktionsplan.
Nicht betroffene Custom-ObjekteKundenspezifische JDE-Objekte wie AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business Functions, Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und NERs. (~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-ObjekteKundenspezifische JDE-Objekte wie AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business Functions, Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und NERs. (~5 % der Arbeitsmenge). Das sind die Objekte, die sowohl vom Kunden als auch von Oracle modifiziert wurden. Sie erfordern einen manuellen RetrofitRetrofit: erneutes Einbringen kundenspezifischer Änderungen in den neuen Oracle-Standard nach einem Upgrade.Manueller RetrofitRetrofit: erneutes Einbringen kundenspezifischer Änderungen in den neuen Oracle-Standard nach einem Upgrade.: Entwickler prüfen Oracle-Änderungen und übertragen Kundenanpassungen kontrolliert in die neue Version.: 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-UpgradesUpgrades von JD Edwards EnterpriseOne auf eine neue Zielversion oder technische Plattform. in der Praxis aus:

Beachten Sie, dass dieser Zeitplan nur die Entwicklungsphase abdeckt. FunktionstestsFunktionstests: Tests einzelner Geschäftsprozesse oder Funktionen gegen definierte fachliche Erwartungen., User AcceptanceUser Acceptance: fachliche Abnahme durch Anwender oder Process Owner vor der Produktivsetzung. TestsUser AcceptanceUser Acceptance: fachliche Abnahme durch Anwender oder Process Owner vor der Produktivsetzung. Tests: Abnahmetests durch Fachanwender, um Geschäftsprozesse vor dem Go-LiveGo-Live: Zeitpunkt, an dem die aktualisierte JD-Edwards-Umgebung produktiv genutzt wird. zu validieren., Endanwender-Schulungen und Go-Live-AktivitätenGo-Live-Aktivitäten: produktionsnahe Aufgaben rund um Cut-over, Freigabe, Überwachung und Hypercare. 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 AssessmentAssessment: strukturierte Voranalyse von Objekten, Risiken, Abhängigkeiten und Upgrade-Aufwand. weit genug fortgeschritten ist. Das eigentliche Oracle-Upgrade (Tools ReleaseTools Release: technische JD-Edwards-Plattformversion für Runtime, Serverkomponenten, Webclient und Entwicklungswerkzeuge. plus ESUsElectronic Software Updates: Oracle-Pakete mit Korrekturen und Änderungen für JD Edwards EnterpriseOne.) startet noch vor dem vollständigen Abschluss des Assessments. Und die längste Phase – der manuelle RetrofitRetrofit: erneutes Einbringen kundenspezifischer Änderungen in den neuen Oracle-Standard nach einem Upgrade. der betroffenen Objekte – läuft mehrere Wochen lang parallel zu allem anderen.
Was vor dem Start zu tun ist
Bevor ein JDE-EnterpriseOne-Upgrade-ProjektProjekt zur Aktualisierung einer JD Edwards EnterpriseOne-Umgebung, einschließlich technischer und funktionaler Validierung. 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 ReleaseTools Release: technische JD-Edwards-Plattformversion für Runtime, Serverkomponenten, Webclient und Entwicklungswerkzeuge. der Kunde derzeit einsetzt, welche Datenbank und welche MiddlewareMiddleware: technische Zwischenschicht für Kommunikation, Integration und Laufzeitdienste zwischen Systemkomponenten. 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 InfrastructureOracle Cloud Infrastructure: Oracle-Plattform für Cloud-Hosting, Compute, Storage und Datenbankdienste., AWSAmazon Web Services: Cloud-Plattform für Infrastruktur, Datenbanken, Netzwerke und Anwendungen. oder AzureMicrosoft Azure: Cloud-Plattform für Infrastruktur, Datenbanken, Netzwerke und Anwendungen.. Diese Entscheidungen während der Umsetzung zu vermischen, ist das sichere Rezept für Verzögerungen.
Executive SponsorshipExecutive Sponsorship: aktive Unterstützung durch das Management, um Prioritäten, Ressourcen und Entscheidungen zu sichern.. Ein JDE-Upgrade berührt jeden Funktionsbereich des Unternehmens. Ohne einen Sponsor auf C-LevelC-Level: Führungsebene eines Unternehmens, etwa CEO, CFO, CIO oder COO., der bereichsübergreifende Konflikte schnell lösen kann, kommt das Projekt beim ersten Streit zwischen FinanceFinance: Finanzbereich, der häufig Buchhaltung, Abschluss, Reporting und Compliance verantwortet. und OperationsOperations: operative Geschäftsbereiche wie Produktion, Logistik, Einkauf, Vertrieb oder Lagerprozesse. über Test-Prioritäten zum Stillstand.
Häufige Fehler, die zu vermeiden sind
Auch mit einer soliden Methodik können JDE-Upgrade-ProjekteProjekte zur Aktualisierung von JD Edwards EnterpriseOne über Releases, Tools Releases oder ESUsElectronic Software Updates: Oracle-Pakete mit Korrekturen und Änderungen für JD Edwards EnterpriseOne. hinweg. aus dem Ruder laufen. Die häufigsten Fehler:
Die Assessment-PhaseAssessment-Phase: Analyse vor der Entwicklung, in der Custom CodeKundenspezifischer Code: angepasste oder neu erstellte JDE-Objekte außerhalb des Oracle-Standards., Risiken und betroffene Objekte klassifiziert werden. überspringen, um „Zeit zu sparen“. Das kostet später immer mehr Zeit. Die 1–2 Wochen Vorab-Analyse sparen nachgelagert Monate.
Alle Custom-ObjekteKundenspezifische JDE-Objekte wie AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business Functions, Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und NERs. 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 FunctionBusiness Function: kompilierter C-Code in JD Edwards, der Geschäftslogik im Call Object Kernel ausführt. im Order-to-Cash-ProzessOrder-to-Cash: End-to-End-Prozess vom Kundenauftrag bis Zahlungseingang und Verbuchung..
Das Testfenster unterschätzen. Selbst mit einer sauberen Entwicklungsphase braucht das Kundenteam ausreichend Zeit für FunktionstestsFunktionstests: Tests einzelner Geschäftsprozesse oder Funktionen gegen definierte fachliche Erwartungen., RegressionstestsRegressionstests: Tests, die sicherstellen, dass bestehende Funktionen nach Änderungen weiterhin korrekt arbeiten. und User AcceptanceUser Acceptance: fachliche Abnahme durch Anwender oder Process Owner vor der Produktivsetzung.. 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-MigrationLike-for-Like-Migration: Upgrade ohne funktionale Erweiterung, bei dem bestehende Prozesse möglichst unverändert übernommen werden. auf das neue Release sein.
Fazit
Ein JD-Edwards-EnterpriseOne-UpgradeUpgrade-Projekt für JD Edwards EnterpriseOne: umfasst Anwendungscode, Objekte, Datenbank, Tools ReleaseTools Release: technische JD-Edwards-Plattformversion für Runtime, Serverkomponenten, Webclient und Entwicklungswerkzeuge., ESUsElectronic Software Updates: Oracle-Pakete mit Korrekturen und Änderungen für JD Edwards EnterpriseOne. und technische Infrastruktur. ist kein Sprung ins Ungewisse. Mit der richtigen Methodik – einer sauberen Analyse der Custom-ObjekteKundenspezifische JDE-Objekte wie AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme., Business Functions, Business ViewsBusiness Views: JDE-Objekte, die TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und Spalten für AnwendungenAPPL-Objekte: interaktive JD-Edwards-Anwendungen und Formulare für Benutzerprozesse., ReportsUBE-Reports: batchfähige JD-Edwards-Berichte und Verarbeitungsprogramme. und Integrationen bereitstellen., TabellenJDE-Tabellen: physische oder logische Datenstrukturen, in denen EnterpriseOne-Geschäftsdaten gespeichert werden. und NERs., 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 RepositoriesRepositories: Bestände von JD-Edwards-Objekten in Umgebungen oder Path Codes. 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-UpgradeUpgrade-Projekt für JD Edwards EnterpriseOne: umfasst Anwendungscode, Objekte, Datenbank, Tools ReleaseTools Release: technische JD-Edwards-Plattformversion für Runtime, Serverkomponenten, Webclient und Entwicklungswerkzeuge., ESUsElectronic Software Updates: Oracle-Pakete mit Korrekturen und Änderungen für JD Edwards EnterpriseOne. und technische Infrastruktur. planen und besprechen möchten, wie sich diese Methodik auf Ihre Umgebung anwenden lässt, stehen unsere zertifizierten Berater bereit.