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.

Tout système JD Edwards ayant quelques années d'existence porte en lui une question sans réponse facile : combien des objets personnalisés développés au fil du temps sont encore fondamentalement identiques au standard Oracle dont ils sont issus, et combien ont évolué au point de devenir quelque chose de complètement différent ? Cette question devient urgente lors d'un upgrade, d'une migration ou d'un audit des personnalisations. Dans la plupart des cas, la réponse n'existe pas — parce que personne ne l'a jamais cherchée de façon systématique. Dans cet article, je décris comment j'aborde ce problème dans mon travail, et l'outil propriétaire que j'ai développé pour le résoudre.