Dalla lista grezza alla stima: come rendere difendibile un upgrade JD Edwards

Un upgrade JD Edwards non dovrebbe iniziare con una stima. Dovrebbe iniziare con una domanda molto più scomoda: qual è davvero il perimetro da stimare? In teoria, la risposta sembra semplice. Si estraggono gli oggetti custom, si confrontano con lo standard, si guarda che cosa è stato modificato e si calcola il lavoro necessario per portarli dalla release di partenza alla release di arrivo. In pratica, questa sequenza lineare esiste raramente. Gli ambienti reali contengono anni di interventi, copie di standard, report mai più eseguiti, oggetti tecnici, versioni modificate, oggetti creati per emergenze ormai dimenticate, componenti consegnati da terze parti, personalizzazioni ancora critiche e personalizzazioni che nessuno usa più. Per questo motivo la stima non può essere il primo passaggio: deve essere la conseguenza di un processo di qualificazione.

L'impegno di Oracle per il Premier SupportSupporto garantito da Oracle per aggiornamenti, patch di sicurezza e assistenza tecnica prioritaria. per JDE 9.2L'ultima versione principale dell'ERP JD Edwards EnterpriseOne, focalizzata su innovazione digitale e cloud. fino al 2034 ha spostato la conversazione sul cloud da una strategia di uscita temporanea a una scelta infrastrutturale a lungo termine. Molti direttori IT trattano JDE come un generico carico di lavoro x86Architettura standard dei processori utilizzata dalla maggior parte dei server e computer moderni., ma il confronto dei costi tra JD Edwards su AWSAmazon Web Services, la piattaforma di servizi di cloud computing di Amazon., AzureLa piattaforma di cloud computing pubblica gestita da Microsoft. e Oracle Cloud è fondamentalmente dettato dalla "Oracle tax" sulle licenze del database. In una tipica implementazione AWS o Azure, ci si ritrova spesso a pagare per il doppio delle vCPUUnità di elaborazione centrale virtuale assegnata a una macchina nel cloud. per eguagliare le prestazioni di una singola OCPUOracle Compute Unit, l'unità di misura della potenza di calcolo utilizzata in Oracle Cloud. di OCIOracle Cloud Infrastructure, l'insieme di servizi cloud di nuova generazione offerti da Oracle., a causa di politiche restrittive sui core-factorMoltiplicatore numerico utilizzato per determinare il numero di licenze software necessarie in base all'hardware. che penalizzano l'hardware non Oracle.

Un upgrade di JD Edwards EnterpriseOneERPEnterprise Resource Planning: sistema gestionale integrato che coordina processi, dati e transazioni aziendali. Oracle per la gestione dei processi aziendali core: finanza, distribuzione, produzione, logistica e integrazioni. è uno dei progetti IT più strategici che un'organizzazione possa intraprendere. Eseguito correttamente, modernizza i processi di business core, riduce i costi operativi e libera anni di debito tecnico accumulato. Eseguito male, può paralizzare le operazioni per mesi e mettere a rischio l'intero investimento sull'ERP.

La differenza tra i due esiti raramente riguarda la tecnologia. Riguarda la metodologia. Dopo molti progetti di upgrade JDEAbbreviazione comune di JD Edwards EnterpriseOne. nel manifatturiero, nella distribuzione e nel retail, lo schema è sempre lo stesso: i progetti che funzionano sono quelli in cui il codice customOggetti o modifiche sviluppati dal cliente rispetto allo standard Oracle JD Edwards. viene analizzato in modo corretto prima dell'inizio dello sviluppo.

Tra tutti gli artefatti che determinano se un upgrade JD Edwards viene consegnato in tempo, il Data DictionaryIl livello di metadati JDE che definisce ogni data item — alias, lunghezza, decimali, glossario, edit rule. È il contratto su cui si basa ogni form, BSFN, UBE e integrazione. è quello che la maggior parte dei piani di upgrade sottovaluta. Il DD è il punto in cui le modifiche Oracle da una release all'altra incontrano il tuo codice custom, e una singola modifica dei decimali su un data item standard, passata inosservata durante il cut-over, è già costata a più di un team finance un mese di riconciliazioni dopo il go-live.

Questo è il modo in cui lavoro sul Data Dictionary in un upgrade reale: come costruire il diff tra release sorgente e target, come inventariare gli item custom con prefisso 55-69 che ti seguiranno per sempre, come individuare gli slittamenti silenziosi di lunghezza e decimali che rompono il retrofittingIl processo di riapplicazione delle modifiche custom sopra una nuova release JDE, dopo che Oracle ha distribuito le proprie modifiche sugli stessi oggetti standard., e come validare il risultato prima che il primo utente effettui il login.

Ogni sistema JD Edwards che ha qualche anno di vita porta con sé una domanda senza risposta facile: quanti degli oggetti custom sviluppati nel tempo sono ancora sostanzialmente identici allo standard Oracle da cui derivano, e quanti si sono evoluti fino a diventare qualcosa di completamente diverso? È una domanda che diventa urgente quando si affronta un upgrade, una migrazione o semplicemente un audit della customizzazione. La risposta, nella maggior parte dei casi, non esiste — perché nessuno l'ha mai cercata sistematicamente. In questo articolo descrivo come affronto questo problema nel mio lavoro, e lo strumento proprietario che ho sviluppato per risolverlo