A decisão
Habitualmente dizemos que não se deve construir. Aqui, construímos.
Na GM Flow, o nosso trabalho habitual é o oposto deste projeto: mapeamos processos e otimizamos com as ferramentas certas — muitas vezes recomendando que não se construa software à medida. Foi por isso que o caso do cliente nos surpreendeu.
-
O cliente e o desafio
O cliente é uma empresa portuguesa especializada em polimento de metais para marcas de luxo. Recebem centenas de peças por encomenda — fivelas, ferragens, componentes metálicos de malas — de grandes casas de luxo. O acabamento que fazem é o último passo antes de a peça regressar à linha da marca, pelo que cada componente passa por critérios de qualidade exigentes e é rastreado individualmente. Chegaram até nós pelo nosso pipeline comercial, com fichas de produção em papel, processos consolidados há anos, e a certeza de que precisavam de digitalizar — mas ainda sem decidir como.
-
Discovery — as fichas de papel diziam tudo
Conduzimos várias sessões intensivas de descoberta, com uma sessão final dedicada à revisão de scope. A abordagem foi deliberada: pedimos para nos mostrarem o trabalho real, não a versão idealizada. Sentámo-nos com as fichas de papel usadas diariamente, percorremos o ciclo de vida completo de uma peça, e fizemos a única pergunta que importa — porquê. Porque é que aquele campo estava ali. Porque é que aquela inspeção acontecia naquele momento. Foi aí que percebemos que um ERP standard obrigaria o cliente a moldar a operação ao software — e numa operação onde a especificidade é o produto, isso seria um retrocesso disfarçado de modernização.
-
Porque é que um ERP tradicional não servia
O cliente podia ter implementado um SAP Business One, um Primavera, um Odoo — e chegaria a 70% do que precisava. O problema estava nos outros 30%, em três pontos concretos:
- Atribuição por performance histórica. Um polidor pode ser mais rápido e preciso numa referência do que noutra. Otimizar a alocação por esses dados — e não só por disponibilidade — exige, num ERP standard, um módulo MES adicional e customização pesada.
- Ciclo de vida peça-a-peça. Retrabalho, QA individual e rastreabilidade individual estão mais próximos de workflows aeroespaciais do que dos fluxos lineares assumidos pela maioria dos ERPs comerciais.
- O custo total. Licenças, parceiro de implementação, customizações e manutenção anual — para uma operação que usaria talvez 40% dos módulos pagos — superam, a médio prazo, o investimento num sistema à medida.
-
A definição do scope
Após a discovery, redigimos a proposta de scope internamente. É uma decisão metodológica nossa: o cliente conhece a operação melhor do que ninguém, mas o desenho do sistema é responsabilidade nossa. Levámos a proposta a sessões de discussão com o cliente, onde ajustámos, adicionámos módulos que tinham ficado de fora, e refinámos prioridades. Um processo iterativo, mas com responsabilidades claras.
-
O que construímos — desenhado para o cliente
O ERP foi desenvolvido em Svelte no frontend e FastAPI no backend, com pipelines de CI/CD e bug tracking ativos desde o primeiro dia. Estruturámos a aplicação em duas sub-apps: uma orientada ao chão de fábrica, onde os funcionários registam em tempo real as peças que trabalham; e um dashboard administrativo que cobre Produção, Catálogo, Clientes, Recursos e Analytics. O sistema funciona out of the box para o cliente porque foi desenhado para o cliente — não há módulos que não se aplicam, campos que não fazem sentido, nem fluxos que obrigam a workarounds.
