Por que colocamos uma máquina de estados no coração do ERP

Fernando · Fundador, FlowIQ.Work · 2026-06-11

ERPs falham quando a regra de negócio vive espalhada em código. Modelar cada entidade como máquina de estados torna toda mudança de dado uma transição explícita: auditável por construção, reversível e barata de evoluir — o custo de um fluxo novo cai para a escrita de uma configuração.

Todo sistema de gestão começa simples: cadastro, listagem, edição. O problema aparece no segundo ano, quando ninguém mais sabe por que um pedido pode ser cancelado em uma tela e não em outra.

Estado implícito é dívida

Quando a regra "só pode faturar contrato ativo" vive num if dentro de um serviço, ela é invisível: não aparece em auditoria, não aparece em documentação e quebra em silêncio quando alguém muda o campo errado.

O que muda com FSM

Na nossa engine, cada entidade declara seus estados e transições em configuração. Faturar é uma transição que só existe a partir de 'ativo'. O motor valida, persiste atomicamente e registra o histórico — sem código novo por domínio.

O efeito prático: adicionar um fluxo de aprovação novo é escrever YAML, não abrir seis arquivos de serviço. E o cliente audita o próprio negócio lendo o log de transições.

FSM não engessa o desenvolvimento?

Não — engessa a bagunça. Fluxos novos são configuração; o que fica rígido é a impossibilidade de mudar dado sem transição registrada.

Serve para sistemas pequenos?

Sim. O custo inicial é o mesmo de um CRUD bem feito, e o ganho aparece na primeira regra de negócio não trivial.