Quando uma encomenda, um pedido ou um caso atravessa várias aplicações, é habitual que cada equipa veja uma versão diferente da sua situação. O CRM pode apresentá-lo como «fechado», a ferramenta operacional como «pendente» e o apoio ao cliente como «em espera». Nem sempre se trata de uma falha técnica: frequentemente, é o resultado de não se ter definido o que representa cada estado, que sistema tem autoridade para o alterar e que factos o justificam.
O desenho de estados de processo em integrações transforma um percurso de negócio num contrato compreensível entre produto, operações e tecnologia. O seu objetivo não é impor um catálogo idêntico a todas as aplicações. É garantir que um estado partilhado tenha um significado inequívoco, uma evidência observável e regras de transição que todos os sistemas ligados respeitem.
Diagnosticar se é necessário um estado partilhado
Nem todos os sistemas devem usar os mesmos estados internos. Uma aplicação pode necessitar de passos técnicos que não acrescentam valor para outras equipas: validação de formato, fila de trabalho, sincronização ou cálculo. O problema surge quando um estado é usado para coordenar decisões entre domínios diferentes ou para comunicar uma promessa ao cliente.
Convém estabelecer um modelo partilhado se ocorrer um ou vários destes sinais:
- Duas equipas respondem de forma diferente à pergunta «o que aconteceu a este pedido?».
- Uma aplicação permite uma ação com base num estado que outra ainda não reconhece.
- Os cancelamentos, as rejeições ou as retomas são geridos por canais manuais.
- Os relatórios agregam etiquetas locais que parecem equivalentes, mas incluem casos diferentes.
- As tentativas de repetição de uma integração devolvem um processo a uma fase anterior ou duplicam tarefas.
Se a necessidade for apenas apresentar informação local, uma tabela de tradução pode ser suficiente. Por exemplo, vários estados técnicos podem ser apresentados como «em curso» numa vista de negócio. Contudo, se vários sistemas decidem, faturam, notificam ou encerram trabalho com base nessa fase, é necessário um contrato explícito. Traduzir etiquetas não substitui a definição de responsabilidades nem de transições.
Desenhar o modelo a partir do percurso de negócio
O melhor ponto de partida não é a lista de estados de uma ferramenta existente, mas sim o ciclo vivido pela entidade de negócio. Desenhe o percurso completo de uma encomenda, caso ou pedido e questione que compromisso representa cada etapa. Em muitos processos transversais surgem cinco momentos, embora os seus nomes possam mudar:
- Início: a entidade existe e foi recebida ou criada.
- Avaliação ou compromisso: a informação é validada e o pedido é aceite, rejeitado ou requer uma correção.
- Execução: existe trabalho ativo para cumprir o compromisso.
- Resultado: a execução termina com sucesso, falha, rejeição ou cancelamento.
- Encerramento: são concluídos efeitos posteriores, como comunicação, reconciliação ou arquivo.
Estes momentos não obrigam à criação de cinco estados. Servem para descobrir decisões relevantes. Um estado merece existir quando altera aquilo que uma pessoa ou sistema pode fazer, a expectativa que outra parte deve receber ou o controlo operacional necessário. Se dois estados produzirem exatamente as mesmas decisões, provavelmente acrescentam complexidade sem valor.
Para cada estado partilhado, documente no mínimo:
- A sua definição em linguagem de negócio e a condição observável que o comprova.
- A entidade à qual se aplica e, quando adequado, o seu âmbito: pedido completo, linha, envio ou tarefa.
- O sistema proprietário que o pode confirmar.
- Os estados de origem permitidos e os desencadeadores válidos.
- As ações permitidas, proibidas ou obrigatórias ao entrar nesse estado.
- A política de saída: automática, manual, por evento externo ou por tempo.
Uma definição como «concluído quando a equipa termina» é ambígua. É preferível: «concluído quando o sistema operacional regista que todas as tarefas obrigatórias do pedido terminaram corretamente». Assim, pode ser verificada, auditada e automatizada.
Não misturar estado, evento, motivo e ação
Grande parte da incoerência resulta da utilização de uma única etiqueta para conceitos diferentes. Separá-los reduz discussões e permite preservar o contexto sem multiplicar estados.
- Estado: condição atual persistente da entidade, como «em execução» ou «cancelada».
- Evento: facto ocorrido num determinado momento, como «pagamento autorizado», «documentação recebida» ou «operação iniciada».
- Motivo: explicação codificada de uma decisão ou resultado, como um motivo de rejeição ou cancelamento.
- Ação: instrução para provocar uma alteração, como «cancelar pedido», «repetir envio» ou «atribuir agente».
Por exemplo, «cliente telefonou» não deveria ser um estado: é um evento de interação. «Cancelada por duplicado» combina um estado final e um motivo. Separar ambos permite medir cancelamentos sem perder a causa e evita criar uma lista interminável de variantes.
Também é necessário distinguir o estado de negócio do estado técnico. «Mensagem pendente de publicação» pode ser essencial para a observabilidade, mas não deve substituir «pedido aceite». Mantenha o estado de negócio estável face aos detalhes de transporte; exponha os dados técnicos quando ajudarem a resolver incidentes.
Atribuir autoridade e controlar as transições
Um estado partilhado necessita de uma fonte de verdade para cada decisão, mesmo que a entidade seja replicada em vários locais. O CRM pode ser proprietário da admissão de um pedido; o sistema operacional, da sua execução; e um sistema financeiro, de uma confirmação de cobrança. O perigo está em permitir que vários sistemas escrevam o mesmo estado sem uma regra de precedência.
Construa uma matriz simples com estado, sistema autorizado, evidência e consumidores. Depois, defina as transições permitidas. Um diagrama é útil, mas as regras têm de poder ser implementadas. Por exemplo:
recebida -> validada -> em_execucao -> concluida recebida|validada|em_execucao -> cancelada validada -> rejeitada
Nem todas as transições devem ser reversíveis. Os estados terminais devem ser tratados como terminais, salvo uma correção governada. Se surgir um erro depois de marcar «concluída», não convém regressar silenciosamente a «em execução». Registe uma ação de correção, o motivo, o responsável e, se o negócio o exigir, um novo ciclo ou uma entidade derivada.
Os estados intermédios são necessários quando alteram uma expectativa ou uma regra operacional. «À espera do cliente» pode justificar a suspensão de um prazo e ativar uma comunicação; «em fila» poderá ser uma condição interna que não deve sair do sistema operacional. Defina também limites temporais: quanto tempo um pedido pode permanecer em cada fase, quem revê a exceção e que alerta é gerado.
Cancelar, repetir e recuperar sem criar regressões
As integrações distribuídas falham, sofrem atrasos e podem entregar a mesma mensagem mais do que uma vez. O desenho do estado deve assumir esta realidade. Publicar uma alteração não implica que todos os consumidores a processem uma única vez nem pela ordem perfeita.
Para cada alteração de estado, publique um identificador estável da entidade, um identificador único do evento, o novo estado, a data efetiva, a origem e uma versão ou sequência. Um consumidor deve conseguir ignorar em segurança um evento já aplicado e detetar um evento antigo. A operação de atualização deve ser idempotente: processar duas vezes a mesma alteração não pode criar duas tarefas, duas notificações nem dois cancelamentos.
As tentativas de repetição técnicas também não devem alterar, por si só, o estado de negócio. Se uma mensagem que anuncia «em execução» falhar na entrega, repita a sua entrega e registe o incidente; não devolva o pedido a «validada». Quando existirem mensagens fora de ordem, defina uma política explícita: rejeitar eventos com uma versão inferior, conservá-los para análise ou aceitá-los apenas se a transição continuar a ser válida.
O cancelamento exige uma decisão de negócio clara. Determine:
- Que estados permitem cancelamento pelo cliente, pela operação ou automaticamente.
- Que efeitos devem ser compensados: tarefas, reservas, comunicações ou movimentos posteriores.
- Quando o cancelamento é imediato e quando fica «solicitado» até que um sistema confirme que é possível interromper o trabalho.
- Que motivos são obrigatórios e que funções podem executar uma correção manual.
Uma alteração manual deve deixar rastreabilidade; não é uma exceção invisível. Guarde quem a efetuou, quando, porquê, qual era o estado anterior e que efeitos foram notificados. Esta informação permite resolver reclamações e melhorar regras deficientes.
Exemplo e controlos antes da implementação
Imagine um pedido que nasce num formulário, é gerido num CRM, é realizado numa aplicação operacional e é consultado pelo apoio ao cliente. O formulário pode criar «recebida», o CRM confirmar «validada» ou «rejeitada», e a operação declarar «em execução» e «concluída». O apoio ao cliente consome o estado partilhado, mas não o altera. Se o cliente pedir o cancelamento durante a execução, o apoio ao cliente cria uma ação de cancelamento; o sistema operacional confirma depois «cancelada» ou informa que já não é possível interromper o trabalho. Desta forma, evita-se confundir um pedido com um resultado.
Antes de implementar, reveja esta lista de verificação:
- Cada estado responde a uma decisão real de negócio ou de operação?
- Existe uma condição observável e um único sistema autorizado a confirmá-la?
- Estão as causas, os eventos e as ações separados do estado persistente?
- Foram definidas transições inválidas, estados terminais e correções excecionais?
- Os consumidores suportam duplicados, atrasos e mensagens fora de ordem?
- Existem alertas para permanências anómalas e reconciliação entre a fonte e as réplicas?
- As alterações ao contrato incluem versão, responsáveis e um plano de compatibilidade?
O modelo deve evoluir com o processo, mas não através de alterações informais de etiquetas. Reveja periodicamente os estados com mais esperas, intervenções manuais, discrepâncias ou pedidos de apoio. Estes sinais indicam que uma definição é insuficiente, que falta um evento ou que está a ser usado um estado técnico para representar uma decisão de negócio. Um contrato pequeno, explícito e governado é mais útil do que um catálogo exaustivo que nenhum sistema interpreta da mesma forma.