Alterar uma regra de negócio pode mudar quem reúne os requisitos para um serviço, quanto se cobra ou como uma operação é classificada. A decisão importante não é apenas que regra aplicar daqui em diante, mas também o que fazer com os registos criados ao abrigo da versão anterior. Recalculá-los pode corrigir resultados, mas também alterar saldos, relatórios e decisões já comunicadas. Mantê-los intactos preserva o que aconteceu, embora possa perpetuar um erro ou uma política que já não se aplica.
Para decidir como aplicar alterações retroativas a regras de negócio, convém separar a data de vigência da data de registo, avaliar as consequências e definir que histórico será conservado. A política adequada pode ser prospetiva, retroativa ou específica para determinados casos. Deve ser decidida antes de publicar a alteração e ser compreensível para as equipas de produto, operações e tecnologia, bem como para as pessoas afetadas.
Uma nova regra não define, por si só, o tratamento do passado
Uma regra determina como avaliar uma situação, mas não necessariamente o que fazer com resultados já calculados. Por exemplo, alterar um critério de elegibilidade pode mudar o resultado de candidaturas anteriores. Sem uma decisão explícita, diferentes equipas podem interpretar a alteração de formas incompatíveis: a aplicação usa a nova regra, um relatório mantém o cálculo anterior e uma intervenção manual introduz um terceiro resultado.
Comece por identificar o motivo da alteração. Não é o mesmo corrigir um erro de implementação, mudar uma política, responder a uma obrigação aplicável ou melhorar um limiar para o futuro. Se a regra anterior funcionava como tinha sido definida e a organização muda de critério, aplicá-la ao passado pode alterar decisões legítimas tomadas na altura. Se o cálculo estava errado, manter todos os resultados pode perpetuar danos. O motivo não determina automaticamente o tratamento, mas ajuda a identificar que resultados devem ser investigados e quem deve aprovar a decisão.
Defina também o que significa «registo existente». Pode tratar-se de uma operação iniciada, de uma operação encerrada, de um pagamento liquidado ou de uma decisão comunicada. Estes estados têm consequências diferentes. Classifique os registos por estado e não pressuponha que todos podem ser alterados pelo mesmo procedimento.
Separar a data de registo da data de vigência
A data em que o sistema guarda uma operação nem sempre coincide com o período a que a regra diz respeito. Uma candidatura registada hoje pode referir-se a um serviço prestado no mês passado; uma correção recebida agora pode descrever uma condição que já existia. Por isso, modele pelo menos duas noções temporais:
- Data de registo: quando o sistema recebeu ou guardou o dado.
- Data de vigência: a partir de quando a regra deve ser considerada válida para avaliar uma operação ou um período.
Consoante o domínio, pode ser necessário especificar também a data efetiva da operação, o momento do cálculo ou o período faturado. Não acrescente datas sem uma necessidade concreta: defina quais alteram o resultado e como são interpretadas. A equipa deve conseguir responder, para cada caso, que regra era válida na data relevante e quando foram registadas as informações utilizadas.
Este modelo evita tratar uma regra como se tivesse sido sempre igual. Também permite corrigir dados recebidos tardiamente sem confundir uma alteração do registo com uma alteração de política. Documente os critérios para resolver datas-limite, fusos horários, operações que atravessam períodos e registos incompletos.
Escolher entre aplicação prospetiva, recálculo ou correção seletiva
Há três estratégias habituais. A aplicação prospetiva usa a nova regra apenas para operações cuja data de vigência seja posterior à data acordada. Mantém os resultados anteriores e costuma ser adequada para alterações de política quando se pretende respeitar as condições existentes. O risco é deixar por corrigir resultados afetados por um defeito real.
O recálculo retroativo volta a avaliar um conjunto definido de registos com a nova regra. Pode ser adequado se o cálculo anterior estava incorreto ou se uma decisão formal exigir a correção de períodos anteriores. Antes de o escolher, verifique se o resultado pode alterar saldos, pagamentos, acesso a serviços, obrigações ou relatórios já encerrados. O recálculo técnico não determina, por si só, que ajuste deve ser feito: um resultado diferente pode exigir uma compensação, uma aprovação ou uma comunicação separada.
A correção caso a caso limita a intervenção aos registos com um erro, uma reclamação ou uma condição específica. É útil quando o âmbito é limitado ou as exceções exigem análise humana, mas pode ser lenta e desigual se não existirem critérios de inclusão e resolução. Registe por que motivo cada caso é incluído ou excluído e quem tomou a decisão.
Compare as opções com perguntas concretas: que problema está a ser corrigido? Que pessoas e períodos são afetados? Que resultado teria ocorrido com cada versão? Há operações encerradas ou decisões comunicadas? Que aprovações são necessárias? É possível reverter a atualização sem perder provas? Se houver incerteza quanto ao impacto ou à autoridade para decidir, suspenda a execução em massa e resolva primeiro essa incerteza.
Avaliar efeitos e dependências antes de alterar registos
Um valor recalculado pode alimentar outras decisões. Acompanhe o percurso desde o dado de origem até aos saldos, relatórios, decisões, comunicações e sistemas ligados. Uma alteração na classificação de uma operação, por exemplo, pode afetar uma vista analítica e uma integração que utiliza essa classificação, mesmo sem alterar o registo financeiro original. Não basta confirmar que a tabela principal contém o valor esperado.
Prepare uma simulação que compare o resultado atual com o proposto para o âmbito escolhido. Resuma quantos registos mudariam, quais são os casos extremos e que dependências receberiam alterações. Se o impacto for amplo ou difícil de interpretar, divida o trabalho por períodos, estados ou grupos operacionais. Defina antecipadamente que diferenças são esperadas, que exceções exigem análise e que resultado obriga a interromper o processo.
Verifique também os efeitos secundários. Uma atualização não deve enviar notificações repetidas por engano, duplicar movimentos nem voltar a aplicar ajustes manuais. Se outros sistemas reagirem a uma alteração do registo, determine se o recálculo deve desencadear essas reações, evitá-las ou gerar uma comunicação diferente. Esta decisão deve fazer parte da conceção, não ficar implícita no mecanismo de atualização.
Conservar o histórico, explicar decisões e controlar a execução
Não substitua o único valor disponível se mais tarde for necessário explicar por que motivo um resultado mudou. Conserve o valor anterior, o novo valor, a regra aplicada, as datas relevantes, o motivo e a referência à aprovação correspondente. A implementação técnica dependerá do sistema, mas o histórico deve permitir reconstruir a decisão tomada para cada registo.
Conceba o recálculo como um processo controlado: delimite o âmbito, execute a simulação, valide amostras com as equipas de operações e de negócio, aprove as exceções e aplique a alteração por etapas, se possível. Depois, compare os resultados reais com os previstos e reveja as dependências. Defina quem pode suspender a execução, como corrigir uma falha e que provas serão conservadas. Não confunda reverter uma atualização com apagar o registo do que aconteceu.
A comunicação também faz parte da alteração. Indique que período foi revisto, que resultados podem mudar, quando a mudança será visível e a quem recorrer em caso de divergência. Se as pessoas já tiverem recebido uma decisão ou um montante, determine antecipadamente quem comunica a correção e como cada caso será tratado. Evite prometer que não haverá consequências enquanto a análise estiver incompleta.
Lista de verificação antes de publicar a alteração
- Descreva o motivo da alteração e distinga uma correção de uma mudança de política.
- Defina a data de vigência, a data de registo relevante e os estados abrangidos.
- Escolha por escrito entre aplicação prospetiva, recálculo retroativo ou correção seletiva.
- Identifique saldos, relatórios, decisões, comunicações e integrações que podem mudar.
- Simule o resultado e valide as exceções com os responsáveis de negócio e operações.
- Conserve os valores anteriores, a regra aplicada, o motivo e as aprovações.
- Preveja como evitar notificações repetidas, movimentos duplicados e a perda de ajustes manuais.
- Defina a comunicação, a supervisão, os critérios de suspensão e o tratamento de divergências.
Uma alteração retroativa bem gerida não consiste simplesmente em executar um novo cálculo sobre dados antigos. É uma decisão de produto e operações sobre que resultados são considerados válidos, para que datas e com que provas. Quando a vigência, o âmbito e as consequências são claros, a equipa pode corrigir o que for necessário sem apagar o contexto que permite explicar o passado.