De la liste brute à l’estimation : comment rendre défendable un upgrade JD Edwards

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.

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.