Quando um ERP de prateleira não chega: como construímos o sistema da Aurum do zero

Na GM Flow, o nosso trabalho habitual é o oposto deste projeto. Entramos em empresas, mapeamos processos, e otimizamos com as ferramentas certas — frequentemente recomendando precisamente que _não_ se construa software à medida quando uma solução existente serve. Foi por isso que o caso da Aurum nos surpreendeu: depois de várias semanas de discovery, a conclusão foi que tínhamos mesmo de construir um ERP do zero. E hoje, percebemos porquê.

O cliente

A Aurum é 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 e acessórios — vindas de algumas das casas mais reconhecidas do mundo, incluindo a Hermès. O acabamento que fazem é o último passo antes de a peça regressar à linha de produção da marca, o que significa que cada componente passa por critérios de qualidade extremamente exigentes e é rastreado individualmente.

Como nos cruzámos

A Aurum chegou até nós pelo nosso pipeline comercial num momento em que já estavam ativamente a avaliar ERPs no mercado. Tinham fichas de produção em papel, processos consolidados ao longo de anos, e a consciência clara de que precisavam de digitalizar. O que ainda não tinham decidido era como.

Discovery: as fichas de papel diziam tudo

Conduzimos várias sessões intensivas de descoberta, espalhadas por algumas semanas, com uma sessão final dedicada à revisão de scope. A abordagem foi simples mas deliberada: pedimos para nos mostrarem o trabalho real, não a versão idealizada dele. Sentámo-nos com as fichas de produção em papel que usavam diariamente, percorremos o ciclo de vida completo de uma peça desde a receção até à expedição, e fizemos a única pergunta que importa nestes casos — porquê. Porque é que aquele campo estava ali. Porque é que aquela inspeção acontecia naquele momento. Porque é que aquela peça voltava àquela estação.

Foi nesse processo que percebemos que um ERP standard, por mais robusto que fosse, ia obrigar a Aurum a moldar a sua operação ao software — e não o contrário. 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

Sejamos diretos: a Aurum podia ter implementado um SAP Business One, um Primavera, um Odoo. Funcionalmente, conseguir-se-ia chegar a 70% do que precisavam. O problema estava nos outros 30%, e em três pontos concretos:

Primeiro, a atribuição automática de tarefas baseada em performance histórica por tipo de peça e por funcionário. Estatisticamente, um polidor pode ser consistentemente mais rápido e preciso numa determinada referência do que noutra. Otimizar a alocação com base nesses dados — e não apenas em disponibilidade — é o tipo de funcionalidade que num ERP standard exige um módulo MES adicional e customização pesada.

Segundo, o ciclo de vida de uma peça de luxo com retrabalho, QA peça-a-peça e rastreabilidade individual está mais próximo dos workflows de indústrias como a aeroespacial do que dos fluxos lineares assumidos pela maioria dos ERPs comerciais.

Terceiro, e talvez o mais subestimado: o custo total. Licenças, parceiro de implementação, customizações sucessivas e manutenção anual de um ERP de prateleira — para uma operação que iria usar talvez 40% dos módulos pelos quais estaria a pagar — superam, a médio prazo, o investimento num sistema feito à medida das necessidades reais.

A definição do scope

Após a discovery, redigimos a proposta de scope internamente. Esta é 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 depois a proposta a sessões de discussão com a Aurum, onde ajustámos, adicionámos módulos que tinham ficado de fora, e refinámos prioridades. Foi um processo iterativo, mas com responsabilidades claras.

O que construímos

O ERP foi desenvolvido em Svelte no frontend e FastAPI no backend, com pipelines de CI/CD e bug tracking ativos em ambas as camadas desde o primeiro dia. Estruturámos a aplicação em duas sub-apps: uma orientada à operação em chão de fábrica, onde os funcionários registam em tempo real as peças que estão a trabalhar e as que terminam; e um dashboard administrativo que cobre Produção (planeamento, encomendas, tarefas), Catálogo (fichas técnicas, perfis de encomenda, fases de produção), Clientes, Recursos (funcionários, stock, materiais, expedição) e Analytics.

O sistema funciona out of the box para a Aurum porque foi desenhado para a Aurum. Não há módulos que não se aplicam, não há campos que não fazem sentido, não há fluxos que obrigam a workarounds.

O que ficou

Mais do que o resultado técnico, o que valorizamos neste projeto foi o processo de chegar lá. Construir software à medida só faz sentido quando a alternativa standard implica comprometer aquilo que torna o negócio competitivo. Para a Aurum, esse era exatamente o caso. Para a maioria das empresas com quem trabalhamos, não é — e somos os primeiros a dizê-lo.