Un upgrade JD Edwards ne devrait pas commencer par une estimation. Il devrait commencer par une question beaucoup plus inconfortable : quel est réellement le périmètre à estimer ? En théorie, la réponse semble simple. On extrait les objets custom, on les compare au standard, on regarde ce qui a été modifié et on calcule le travail nécessaire pour les faire passer de la release source à la release cible. En pratique, cette séquence linéaire existe rarement. Les environnements réels contiennent des années d’interventions, des copies d’objets standard, des rapports qui ne sont plus jamais exécutés, des objets techniques, des versions modifiées, des objets créés pour des urgences depuis longtemps oubliées, des composants tiers, des personnalisations encore critiques et des personnalisations que plus personne n’utilise. Pour cette raison, l’estimation ne peut pas être la première étape : elle doit être la conséquence d’un processus de qualification.
L'engagement d'Oracle pour le Premier Support de JDE 9.2 jusqu'en 2034 a déplacé la discussion sur le cloud d'une stratégie de sortie temporaire vers un enjeu d'infrastructure à long terme. La plupart des directeurs informatiques traitent JDE comme une charge de travail x86 générique, mais la comparaison des coûts entre JD Edwards sur AWS, Azure et Oracle Cloud est fondamentalement dictée par la « taxe Oracle » sur les licences de base de données. Dans un déploiement typique sur AWS ou Azure, vous vous retrouvez souvent à payer pour deux fois plus de vCPUs afin d'égaler les performances d'un seul OCPU sur OCI, en raison de politiques restrictives de facteur de cœur qui pénalisent le matériel non-Oracle.
Une mise à niveauProcessus de passage d’une version JD Edwards à une version plus récente, avec migration des objets standard et personnalisés. de JD Edwards EnterpriseOneERP Oracle pour les grandes entreprises, utilisé pour gérer finance, distribution, fabrication, achats, ventes et processus opérationnels intégrés. est l'un des projets informatiques les plus stratégiques qu'une organisation puisse entreprendre. Bien menée, elle modernise les processus métier essentiels, réduit les coûts d'exploitation et libère des années de dette technique accumulée. Mal menée, elle peut perturber les opérations pendant des mois et compromettre l'intégralité de l'investissement ERPEnterprise Resource Planning : système intégré qui centralise les processus métier critiques comme finance, achats, ventes, stock et production..
La différence entre les deux issues tient rarement à la technologie. Elle tient à la méthodologie. Après de nombreux projets de mise à niveauProcessus de passage d’une version JD Edwards à une version plus récente, avec migration des objets standard et personnalisés. JDEAbréviation courante de JD Edwards EnterpriseOne. dans l'industrie, la distribution et le retail, le schéma est toujours le même : les projets qui réussissent sont ceux où le code personnaliséObjets ou modifications développés par le client en dehors du standard Oracle JD Edwards. est correctement analysé avant le démarrage du développement.
Parmi tous les artefacts qui déterminent si un upgrade JD Edwards est livré à temps, le Data DictionaryLa couche de métadonnées JDE qui définit chaque data item — alias, longueur, décimales, glossaire, edit rules. C'est le contrat sur lequel reposent chaque form, BSFN, UBE et intégration. est celui que la plupart des plans d'upgrade sous-estiment. Le DD est l'endroit où les changements Oracle d'une release à l'autre rencontrent votre code custom, et une seule modification du nombre de décimales sur un data item standard, passée inaperçue pendant le cut-over, a déjà coûté à plus d'une équipe finance un mois de travail de réconciliation après le go-live.
Voici comment je traite le Data Dictionary dans un vrai upgrade : comment construire le diff entre la release source et la release cible, comment inventorier les items custom avec préfixe 55-69 qui vous suivront indéfiniment, comment repérer les dérives silencieuses de longueur et de décimales qui cassent le retrofittingLe processus qui consiste à réappliquer des modifications custom au-dessus d'une nouvelle release JDE, après qu'Oracle a livré ses propres changements sur les mêmes objets standard., et comment valider le résultat avant que le premier utilisateur se connecte.