Valeu pelo complemento. Acho que agora entendi melhor o ponto que você levantou e vou detalhar um pouco mais onde o sistema está atacando o problema, porque isso realmente não ficou claro no post.
Ele nasceu dentro de uma operação industrial em que o ERP já existe e continua sendo o sistema oficial. A ideia nunca foi substituir ERP. O problema estava principalmente entre a informação que existia no sistema e o que realmente acontecia fisicamente na expedição.
Antes, uma parte importante desse processo era baseada em papel. A expedição recebia mapas que, dependendo da carga, podiam chegar a dezenas de páginas. O operador precisava trabalhar em cima desse documento para conferir fisicamente os materiais, quantidades, pedidos etc.
Depois da conferência, esse mapa preenchido precisava chegar ao faturamento. Como o processo era físico, havia inclusive a necessidade de digitalizar o documento para transmitir as informações. Então existia uma sequência mais ou menos assim:
ERP → mapa impresso → conferência manual → anotações no papel → digitalização → envio ao faturamento → interpretação das informações → faturamento.
Foi exatamente nesse intervalo que comecei a enxergar a lacuna.
O sistema passou a importar o mapa gerado pelo processo existente, sem precisar substituir o ERP. A partir daí, transforma aquele documento em um fluxo operacional digital.
O operador passa a fazer a conferência dentro do sistema. Conforme os itens são conferidos, o próprio sistema controla quantidade prevista, quantidade conferida, saldo, pedido relacionado e situação da conferência.
Isso parece simples até aparecerem as exceções da operação real.
Existem, por exemplo, produtos que representam conjuntos formados por vários componentes. Não basta saber que foram conferidas determinadas peças; é necessário entender se a quantidade de componentes disponível realmente forma a quantidade necessária de conjuntos. Por isso surgiu uma camada que trata composição e consegue identificar situações como conjunto completo, parcial, bloqueado ou existência de componentes excedentes.
Outra parte importante é que o sistema mantém o estado da operação. Então a informação deixa de depender daquele mapa físico circulando entre pessoas. O faturamento consegue receber digitalmente aquilo que foi efetivamente conferido e trabalhar a partir desse estado.
Posteriormente entraram também validações relacionadas à NF e ao faturamento, para comparar o que deveria sair, o que foi conferido e o que efetivamente foi faturado. O objetivo é justamente reduzir situações em que a divergência só é descoberta no final do processo.
Existe ainda uma camada de Packing List e rastreabilidade por embalagem. A proposta é conseguir registrar não apenas que determinado produto foi expedido, mas em qual embalagem ele foi colocado e manter esse histórico ligado à expedição.
Essa parte é importante mencionar porque ainda não foi implantada completamente na operação real. Ou seja, o sistema que descrevi no post possui funcionalidades que ainda estão em processo de aplicação.
E isso torna o resultado atual interessante para mim: mesmo sem o fluxo completo de Packing List funcionando na operação, a parte que já foi implantada melhorou bastante o processo existente.
A mudança principal não foi simplesmente trocar papel por uma tela. Foi eliminar uma cadeia de trabalho que existia por causa do papel.
Antes:
imprimir → distribuir → conferir → escrever → recolher → digitalizar → enviar → interpretar.
Agora uma parte relevante virou:
importar → conferir digitalmente → validar → disponibilizar para faturamento.
E existe outro ponto que talvez eu não tenha explicado bem: conforme o projeto cresceu, percebi que a conferência era apenas uma das pontas do problema.
Pedido, condição comercial, expedição, composição de produtos, embalagem, faturamento e contexto fiscal acabam se encontrando em algum momento. Por isso o projeto começou pequeno e foi ganhando essas outras camadas.
Hoje também existe um trabalho de pré-faturamento fiscal. Não para substituir o ERP nem emitir a NF por conta própria, mas para reunir o contexto do pedido, produto, cliente e operação e detectar pendências antes de mandar aquilo para o processo oficial de faturamento.
Então concordo bastante com seu ponto sobre configuração.
Hoje uma das perguntas que preciso responder é justamente: o que nesse sistema pertence à empresa onde ele nasceu e o que pertence ao problema de expedição em si?
Se eu descobrir que para colocar o sistema em uma segunda empresa preciso reescrever metade dele, tenho uma solução interna muito boa, mas não necessariamente um produto escalável.
Agora, se eu conseguir separar um núcleo comum — conferência, saldo, composição, rastreabilidade, comunicação com faturamento etc. — e transformar as diferenças de cada empresa em configurações e integrações, aí a situação muda bastante.
E acho que sua sugestão de procurar uma segunda operação semelhante é provavelmente o melhor teste para descobrir isso.
Inclusive, o que eu gostaria de testar não é chegar dizendo “troque seu ERP pelo meu sistema”. Seria quase o contrário:
“Mostre como sua expedição funciona hoje, quais partes ainda dependem de papel, Excel, comunicação manual ou controles paralelos ao ERP e vamos ver se existe uma lacuna semelhante.”
Se não existir, já aprendi alguma coisa. Se existir, tento adaptar o sistema sem alterar seu núcleo. E se eu conseguir fazer isso novamente em uma terceira operação, começo a ter evidência de que existe algo reproduzível ali.
Acho que esse é exatamente o teste de realidade que está faltando agora.