Da lista bruta à estimativa: como tornar um upgrade JD Edwards defensável

Um upgrade JD Edwards não deveria começar por uma estimativa. Deveria começar por uma pergunta muito mais desconfortável: qual é realmente o escopo a ser estimado? Em teoria, a resposta parece simples. Extraem-se os objetos custom, comparam-se com o standard, verifica-se o que foi modificado e calcula-se o trabalho necessário para levá-los da release de origem para a release de destino. Na prática, essa sequência linear raramente existe. Ambientes reais contêm anos de intervenções, cópias de objetos standard, relatórios que nunca mais foram executados, objetos técnicos, versões modificadas, objetos criados para emergências há muito esquecidas, componentes de terceiros, customizações ainda críticas e customizações que ninguém mais usa. Por isso, a estimativa não pode ser o primeiro passo: deve ser a consequência de um processo de qualificação.

O compromisso da Oracle com o Premier Support para o JDE 9.2 até 2034 mudou a conversa sobre nuvem de uma estratégia de saída temporária para uma jogada de infraestrutura de longo prazo. A maioria dos diretores de TI trata o JDE como uma carga de trabalho x86 genérica, mas a comparação de custos entre JD Edwards no AWS, Azure e Oracle Cloud é fundamentalmente ditada pela "taxa Oracle" no licenciamento de banco de dados. Em uma implantação típica no AWS ou Azure, muitas vezes você acaba pagando pelo dobro de vCPUs para igualar o desempenho de um único OCPU da OCI devido a políticas restritivas de fator de núcleo que penalizam o hardware não-Oracle.

Uma atualização do JD Edwards EnterpriseOneERPEnterprise Resource Planning: sistema integrado usado para gerenciar processos essenciais de negócio, como finanças, compras, vendas, estoque e produção. empresarial da Oracle para processos financeiros, distribuição, manufatura, logística e operações corporativas. é um dos projetos de TI mais estratégicos que uma organização pode realizar. Bem executada, ela moderniza os processos de negócio essenciais, reduz os custos operacionais e elimina anos de dívida técnica acumulada. Mal conduzida, pode interromper as operações por meses e colocar em risco todo o investimento no ERP.

A diferença entre os dois resultados raramente está na tecnologia. Está na metodologia. Após muitos projetos de upgrade do JDEAbreviação comum de JD Edwards EnterpriseOne. em manufatura, distribuição e varejo, o padrão é sempre o mesmo: os projetos que dão certo são aqueles em que o código customizadoCódigo, objetos e alterações desenvolvidos fora do padrão entregue pela Oracle para atender necessidades específicas do cliente. é analisado adequadamente antes do início do desenvolvimento.

De todos os artefatos que decidem se um upgrade JD Edwards será entregue no prazo, o Data DictionaryA camada de metadados JDE que define cada data item — alias, comprimento, casas decimais, glossário, edit rules. É o contrato em que cada form, BSFN, UBE e integração se apoia. é o que a maioria dos planos de upgrade subestima. O DD é onde as mudanças da Oracle de uma release para outra encontram seu código custom, e uma única alteração de casas decimais em um data item padrão, não percebida durante o cut-over, já custou a mais de uma equipe financeira um mês de trabalho de conciliação após o go-live.

É assim que eu trabalho o Data Dictionary em um upgrade real: como construir o diff entre a release origem e a release destino, como inventariar os itens custom com prefixo 55-69 que vão acompanhar você para sempre, como identificar as mudanças silenciosas de comprimento e casas decimais que quebram o retrofittingO processo de reaplicar modificações custom sobre uma nova release JDE, depois que a Oracle entregou suas próprias mudanças nos mesmos objetos padrão., e como validar o resultado antes que o primeiro usuário faça login.

Uma equipe de desenvolvimento JDE composta por dois ou três profissionais que suporta de 2.000 a 3.000 usuários ativos vive em um dilema perigoso. Você não tem recursos para sustentar um comitê de mudanças corporativo com seis camadas de aprovação, mas operar sem governança alguma garante que uma NERNamed Event Rule: lógica de negócios criada no JDE usando ferramentas visuais, sem necessidade de código em C. não testada ou a specEspecificação técnica que define a estrutura de dados, telas ou regras de um objeto no JD Edwards. de uma tabela modificada corrompa o ambiente de produção antes do final do mês. Trocar esse caos por fluxos gigantescos no Jira ou ferramentas externas de ITSM só adiciona sobrecarga administrativa sem resolver a raiz do problema nas promoções de specs.

Todo CNCConfigurable Network Computing: a arquitetura técnica proprietária e a função de administrador de sistemas do JD Edwards EnterpriseOne. sênior já atendeu àquela chamada de escalonamento durante a madrugada: uma aplicação customizada ou UBEUniversal Batch Engine: o mecanismo de processamento em lote e relatórios do JD Edwards. passou perfeitamente pelos testes em DV, mas no momento em que chegou a PY, surgiram violações de memória ou as processing optionsParâmetros configuráveis pelo usuário que alteram o comportamento ou a lógica de uma aplicação ou relatório sem mexer no código. simplesmente desapareceram. Na grande maioria dessas regressões pós-implantação, a lógica subjacente da C business functionComponente modular de lógica de negócios em C ou Event Rules reutilizável dentro do JD Edwards. ou das Event RulesLinguagem de script nativa visual do JD Edwards anexada a eventos de interface e processamento. está completamente correta. Em vez disso, falhas de execução procedimental dentro do Object Management WorkbenchFerramenta centralizada do JD Edwards (P98220) para gerenciar o ciclo de vida, versionamento e promoção de objetos. (P98220) — especificamente os erros de promoção no JDE OMW que quebram objetos customizados — introduzem colisões de tokens, especificações órfãs e poluição de cache que passam despercebidas pelos logs de compilação padrão.