APRENDER. PRATICAR. EVOLUIR.1. Separar o destino da passagem para o destino
A solução futura deve permitir consultar posições reconciliadas. Para lá chegar, o projeto pode precisar de conversão histórica, formação, coexistência temporária e um procedimento de retorno. Esses requisitos de transição têm ciclo de vida próprio: não desaparecem por a funcionalidade nova passar testes. Identifica quando cada capacidade temporária é necessária e o critério para a retirar. A comparação de dados deve começar por um contrato: população incluída, data de negócio, estado das operações, chaves, moeda, unidades e transformações autorizadas. Uma contagem global sem estes limites pode comparar populações diferentes. Usa dados sintéticos para desenvolver o método e confirma depois, em ambiente autorizado, a qualidade e o acesso aos dados reais necessários à aceitação.
2. Reconhecer o falso sucesso por totais
Na ficha fictícia, a origem contém duas posições EUR de 100 e 250 e uma posição USD de 150. O destino mantém as três linhas e os mesmos totais por moeda, mas substitui a posição EUR de 100 por outra referência. Contagem e soma passam, embora falte uma posição e exista outra inesperada. Compara primeiro a identidade segundo o contrato e depois atributos, valores e estados relevantes. Não somes EUR e USD num único total sem uma regra explícita de conversão e momento de avaliação. Também não normalizes todas as referências para maiúsculas só para aumentar correspondências se o contrato distingue letras. As regras de comparação precisam de ser aprovadas pelos consumidores da informação e verificadas com casos normais e exceções.
3. Tratar duplicados e diferenças antes de agregar
Uma chave repetida não deve ser silenciosamente substituída pela última linha lida. Pode indicar duplicação indevida, granularidade mal definida ou uma regra legítima de múltiplos movimentos. Regista o conflito e confirma o contrato antes de escolher deduplicação ou agregação. Se os montantes forem representados em cêntimos inteiros, a unidade deve ficar explícita; comparar 100 com 100,00 sem saber a unidade pode esconder um erro de escala. Um total líquido zero também pode esconder diferenças opostas em duas contas. O exercício local identifica chaves em falta, inesperadas, duplicadas e montantes divergentes por registo, conservando totais por moeda como controlo complementar. O resultado produz candidatos a investigar, não uma aprovação automática de migração.
4. Ligar critérios, exceções e autoridade
Define critérios antes do cutover e liga cada um ao requisito, conjunto de dados, versão do teste e responsável pela aceitação. Um teste não executado é desconhecido; não é aprovação implícita nem falha funcional comprovada. Uma exceção aceite deve identificar quem pode aceitar o risco, o âmbito, o prazo, a medida compensatória e a condição de fecho. O facto de alguém fechar um ticket não transforma automaticamente essa pessoa em aprovador da mudança. Se uma correção alterar a transformação de dados, avalia os testes e consumidores dependentes; não repitas apenas o caso que revelou o defeito. No comité, apresenta o estado de cada critério e as lacunas que condicionam avançar, prolongar coexistência ou retornar.
5. Verificar operação, adoção e retirada do legado
A migração pode reconciliar corretamente e continuar sem criar o valor esperado se o turno noturno não tiver acesso, formação ou procedimento de suporte. Distingue defeito da solução de limitações organizacionais ou de processos que restringem a utilização. Para retirar o legado, confirma consumidores, histórico necessário, retenção, suporte e a rota de consulta ou recuperação acordada. Um backup antigo não é, por si só, um serviço de consulta histórica aceite. Mede a adoção e o resultado com população, período e denominador estáveis, preservando diferenças entre equipas. Não atribuas causalidade à mudança apenas porque o indicador global melhorou. O handover deve tornar operáveis os critérios: quem observa, quem decide, quando intervém e qual evidência conserva durante a estabilização.
Três linhas e totais iguais por moeda podem esconder uma referência em falta e outra indevida. A reconciliação deve comparar identidade e conteúdo, não apenas agregados.
Armadilhas comuns
Somar moedas sem contrato, deduplicar sem regra, aceitar testes desconhecidos, confundir ticket fechado com aprovação e desligar o legado antes de confirmar consumidores.
Tópicos relacionados: Decisões, versões e dependências · Modelar, verificar e validar requisitos · Medir o resultado e interpretar evidência
Aceita a transição com identidade, diferenças explicadas, critérios verificáveis e operação preparada.
Referência: The Business Analysis Standard · CBAP six-knowledge-area blueprint, May 2026 handbook