A Tecfil concluiu no fim de junho a migração do seu ecossistema de gestão para SAP S/4HANA Private Cloud na AWS, substituindo processos manuais e 31 sistemas legados por uma arquitetura baseada em APIs. Foram 38 semanas, com redução de 50% na despesa de TI.
O número que chama atenção é o prazo. Trinta e oito semanas para trocar 31 sistemas é rápido em qualquer leitura — e projetos de ERP têm reputação merecida de estourar cronograma. Mas o que interessa não é o prazo em si: é por que ele coube.
Duas decisões explicam o relógio, e nenhuma delas é "o time trabalhou mais". Ambas são decisões de subtração — sobre o que não seria feito. Este artigo é sobre elas, e sobre a pergunta desconfortável que elas devolvem para qualquer projeto de migração em andamento.
1. O que a Tecfil entregou
Antes das decisões, o escopo, para que a comparação seja honesta.
O destino foi S/4HANA Private Cloud rodando na AWS — modelo que mantém o grau de customização do private cloud sem manter data center próprio, e que separa a decisão de plataforma da decisão de infraestrutura. Foram substituídos 31 sistemas legados e processos que ainda eram manuais, por uma arquitetura baseada em APIs. O resultado financeiro reportado é redução de 50% na despesa de TI.
Dois elementos do escopo merecem destaque porque explicam o rigor: 175 cenários fiscais mapeados e uma simulação completa de go-live envolvendo várias áreas. E a justificativa declarada inclui preparo para a Reforma Tributária — o que muda o enquadramento do projeto: não é modernização discricionária, é adequação com data.
Vale a comparação com o que discutimos aqui há dois dias. No case da VW Caminhões, a métrica de modernização era quantos sistemas foram desligados. A Tecfil traz a métrica seguinte: o que foi cortado para caber no prazo. São duas faces do mesmo princípio — modernização se mede por subtração, não por adição.
2. Decisão 1 — customização como escopo negociável: de 116 para 26 GAPs
O levantamento inicial apontou 116 GAPs de customização — funcionalidades que o padrão do S/4HANA não cobria e que exigiriam desenvolvimento. Depois de revisar os fluxos operacionais, o número caiu para 26.
São 77% do trabalho de customização eliminados antes de virar linha de código. E o mecanismo importa: os GAPs não sumiram por decisão de corte orçamentário. Sumiram porque, ao revisar o fluxo, ficou claro que a maior parte deles não descrevia uma necessidade do negócio — descrevia um hábito herdado do sistema anterior.
Essa é a distinção que quase nenhum projeto faz com honestidade. Um levantamento de GAPs feito perguntando "o que o sistema atual faz que o novo não faz?" produz uma lista de tudo. Feito perguntando "qual resultado de negócio esse comportamento entrega, e o padrão consegue entregar o mesmo resultado de outro jeito?", produz uma lista muito menor. A diferença entre as duas perguntas é o que separa 116 de 26.
Há uma resistência previsível: cada GAP tem um dono que o considera essencial, e discutir isso consome tempo e capital político. É por isso que a revisão de fluxos costuma ser pulada — parece um custo antecipado sem retorno visível. Mas a conta é direta: 90 customizações a menos são 90 desenvolvimentos que não precisam ser especificados, construídos, testados, homologados e documentados. É onde as semanas foram encontradas.
3. Por que cada GAP aceito sem discussão vira sistema que ninguém consegue atualizar
O custo de um GAP aceito não termina no dia da entrega. Começa nele.
Customização em ERP é código que fica fora do caminho de atualização do fornecedor. Toda vez que chega uma release, alguém precisa verificar se aquele desenvolvimento ainda funciona, e frequentemente precisa ajustá-lo. Com 116 customizações, cada ciclo de atualização vira um projeto — e o resultado conhecido é a empresa que fica três versões atrás porque atualizar dá trabalho demais. Aí a plataforma que foi comprada para modernizar vira o novo legado, com a agravante de ser mais cara.
É o mesmo raciocínio que sustenta a discussão de Clean Core: quanto mais o núcleo permanece padrão, mais barato é acompanhar a evolução do produto — incluindo os recursos de IA que a SAP vem embarcando, que assumem estruturas de dados padronizadas para funcionar. Customização excessiva não bloqueia apenas o upgrade; bloqueia o acesso ao que vem depois dele.
Há ainda o custo humano. Cada customização é conhecimento que mora em pouca gente. Quando essa gente sai — e sai —, o comportamento vira caixa-preta: ninguém sabe explicar por que aquele campo é preenchido daquele jeito, e ninguém tem coragem de mexer. Vinte e seis caixas-pretas são administráveis. Cento e dezesseis não são.
4. Decisão 2 — do conector com plantão para a integração automatizada
A segunda decisão é a que costuma passar despercebida na leitura do case, e é tão determinante quanto a primeira: o modelo de conectores on-premise, que exigia intervenção constante do time de TI, foi substituído por uma estrutura de integração automatizada.
Conector que precisa de gente é dívida disfarçada de solução. Ele funciona no dia da entrega — e cobra o juro todos os meses, em plantão. O padrão é reconhecível em qualquer operação: o job que falha e alguém reprocessa na mão; o arquivo que precisa ser conferido antes de subir; a rotina que "só o Fulano sabe rodar"; a divergência de estoque que se resolve com uma consulta no banco toda segunda-feira.
Esse custo não aparece no orçamento do projeto, porque não é linha de investimento — é rotina de sustentação. Mas ele aparece no prazo do próximo projeto, e é aí que a conta fecha: o time que gasta parte relevante da semana mantendo integração viva é o mesmo time que precisaria estar migrando. Trocar conector manual por integração automatizada não é um item de qualidade técnica; é liberação de capacidade — e capacidade liberada é prazo.
Na prática, integração automatizada em contexto de ERP significa um conjunto específico de propriedades: idempotência, para que a mesma mensagem processada duas vezes não gere pedido ou lançamento duplicado; reconciliação automática, para que a divergência entre os dois lados seja detectada por rotina e não por reclamação de cliente; trilha de auditoria, para que a pergunta "esse pedido chegou?" tenha resposta em um registro e não em uma investigação; e arquitetura orientada a eventos, para que o sistema de origem não fique bloqueado esperando o destino responder.
5. O teste que o Brasil exige: 175 cenários fiscais e a Reforma Tributária
Há um detalhe do case que não deve ser tratado como nota de rodapé: 175 cenários fiscais mapeados e simulação completa de go-live com participação de várias áreas.
Complexidade fiscal é a razão pela qual projetos de ERP no Brasil não podem ser comparados diretamente com implementações em outros mercados. Regime tributário, substituição, benefícios estaduais, operações interestaduais, devolução, remessa e industrialização por encomenda geram uma combinatória que não se valida por amostragem. Um cenário fiscal que não foi testado só aparece em produção — e aparece como nota rejeitada, o que significa mercadoria parada e faturamento travado.
Mapear 175 cenários é trabalho pesado e é justamente o tipo de item que sofre pressão para ser reduzido quando o cronograma aperta. O que o case indica é a ordem correta: corte customização, não corte teste fiscal. Um GAP não implementado é uma funcionalidade ausente, que aparece cedo e se resolve com processo. Um cenário fiscal não testado é uma nota rejeitada, que aparece tarde e para a operação.
A Reforma Tributária no horizonte reforça esse ponto e muda o cálculo de quem ainda está decidindo. Adequação a mudança tributária exige tocar o núcleo fiscal do ERP. Fazer isso sobre uma base padronizada, com integração automatizada, é um projeto. Fazer sobre um núcleo com 116 customizações e conectores que exigem plantão é outro — significativamente maior, e com data de entrega definida por terceiros.
6. A ressalva: 38 semanas é escopo disciplinado, não pressa
Vale dizer o que o case não autoriza a concluir.
Não autoriza usar 38 semanas como benchmark universal. O prazo é resultado de um conjunto específico de condições: disposição para revisar fluxos e cortar 77% dos GAPs, decisão de abandonar o modelo de conectores manuais, investimento pesado em validação fiscal antes do go-live e patrocínio para sustentar as discussões desconfortáveis que a revisão de escopo gera.
Um projeto que aceita os 116 GAPs originais e mantém conector manual não faz isso em 38 semanas — nem em 138. Ele entrega em algum momento, com escopo maior, custo maior e uma base mais difícil de atualizar depois. Comprimir prazo sem cortar escopo não acelera o projeto; apenas transfere o atraso para a estabilização pós-go-live, onde ele custa mais caro porque já está em produção.
A leitura correta é a inversa da intuitiva: o prazo não foi conquistado, foi consequência. Consequência de decisões de subtração tomadas antes da primeira linha de código. É por isso que a pergunta útil para o próximo comitê não é "como aceleramos?", e sim: da nossa lista de GAPs, quantos sobreviveriam a uma revisão de fluxo honesta — e quantos dos nossos conectores ainda dependem de alguém acordar de madrugada?
7. Como a CCX ajuda: revisão de fluxo antes do código e integração com reconciliação
As duas decisões que fizeram o prazo da Tecfil caber correspondem a duas frentes de trabalho concretas — e nenhuma delas é "colocar mais gente no projeto".
A primeira é a revisão que antecede o desenvolvimento, e é o que a Consultoria em Tecnologia da CCX entrega: avaliação de infraestrutura, arquitetura e processos com recomendação feita por contexto, não por plataforma. Os entregáveis são exatamente os que sustentam uma decisão de corte de GAP com argumento: diagnóstico, arquitetura-alvo, roadmap, TCO comparativo e plano de migração. É o trabalho que transforma "esse GAP é essencial" em uma conversa sobre qual resultado de negócio ele entrega e a que custo de manutenção — que é a única forma de sair de 116 para 26 sem arbitrariedade.
A segunda é a substituição do conector com plantão, e é a prática de Integrações & APIs Enterprise: conectividade via REST, GraphQL e gRPC e arquitetura event-driven com Kafka e RabbitMQ, com outbox pattern, idempotência por evento e rotina de reconciliação automática. No universo SAP isso se apoia em expertise específica — OData, iDocs e RFC — para os cenários que aparecem em toda operação: SAP ↔ e-commerce em tempo real, Protheus ↔ e-commerce com sincronização de estoque, preço, pedido e nota fiscal, além de CRMs, gateways de pagamento e antifraude. A diferença prática é essa: integração que reconcilia sozinha não consome o time que precisa estar migrando.
Quando o time interno está no limite — que é a situação normal durante uma migração —, a execução pode ser reforçada por squads dedicadas com onboarding em 48h, formadas por engenheiros sêniores com média de 10+ anos de experiência e escala elástica conforme a fase do projeto. Tudo isso dentro de uma metodologia com fases definidas: Discovery e Diagnóstico (1–2 semanas), Arquitetura e Planejamento (1–2 semanas), implementação em sprints, QA e security contínuos, e go-live assistido com suporte dedicado nas primeiras 72h.
Prazo de migração não se ganha com mais gente — se ganha cortando GAP e trocando conector manual por integração automatizada. Integrar SAP ao seu e-commerce →
8. Perguntas frequentes
Quanto tempo leva uma migração para SAP S/4HANA?
Não existe número universal: o prazo é função do escopo de customização e da qualidade das integrações existentes, não do tamanho da empresa. O case da Tecfil registra 38 semanas para substituir 31 sistemas legados, e as duas decisões que explicam esse prazo foram cortar os GAPs de customização de 116 para 26 e abandonar os conectores que exigiam intervenção manual do time de TI.
O que é um GAP de customização em projeto SAP?
É uma funcionalidade que o padrão do S/4HANA não cobre e que exigiria desenvolvimento específico. Cada GAP aceito vira código fora do caminho de atualização do fornecedor, o que significa verificação e ajuste a cada nova release. É por isso que a revisão de fluxos antes do desenvolvimento tem impacto direto no prazo e no custo de manutenção dos anos seguintes.
Por que trocar conectores on-premise por integração automatizada?
Porque conector que exige intervenção manual consome capacidade do time de forma permanente: reprocessamento na mão, conferência de arquivo, plantão para job que falhou. Esse custo não aparece no orçamento do projeto, mas aparece no prazo do projeto seguinte. Integração automatizada com idempotência, reconciliação e trilha de auditoria devolve essa capacidade ao time.
O que a Reforma Tributária muda para quem ainda não migrou?
Adequação tributária exige tocar o núcleo fiscal do ERP, e o custo dessa mudança é proporcional ao grau de customização da base. Sobre um núcleo padronizado com integração automatizada, é um projeto delimitado; sobre um núcleo com dezenas de customizações e conectores manuais, é substancialmente maior — com o agravante de a data ser definida externamente.
Dá para acelerar a migração aumentando o time?
Só marginalmente. As duas alavancas que explicam o prazo do case são de subtração, não de capacidade: reduzir a lista de customizações e eliminar o trabalho manual de sustentação das integrações. Comprimir o cronograma sem cortar escopo transfere o atraso para a estabilização pós-go-live, onde ele custa mais caro porque já está em produção.