Quando uma empresa decide modernizar o ERP, a discussão costuma começar pela tecnologia. Ou seja, pela comparação de plataformas, módulos e prazos. Uma decisão anterior a todas essas, porém, determina o destino do projeto. Afinal, ela separa o que precisa ser reconstruído do que apenas precisa continuar funcionando em uma arquitetura mais moderna. Por isso, essa separação leva à dúvida central deste artigo: vale a pena redesenhar processos durante a migração de ERP?
Dois casos divulgados na mesma semana colocaram essa escolha em evidência. Primeiro, a Zeiss abandonou o greenfield, a reconstrução do zero, após mais de cinco anos e €200 milhões investidos. Em seguida, passou ao brownfield, que preserva o ambiente existente na ida à nuvem.
Por outro lado, a MBRF seguiu o caminho inverso e adotou o brownfield para migrar ao S/4HANA. Assim, concluiu o projeto em onze meses, com estabilidade após o go-live.
Os casos não provam que o brownfield sempre supera o greenfield. No entanto, mostram algo importante a CTOs, CIOs e CFOs de empresas Mid-Market e Enterprise. Migrar um ERP e redesenhar os processos que ele suporta são decisões distintas, com riscos e custos próprios.
Portanto, quem avalia se vale a pena redesenhar processos durante a migração de ERP precisa separar as duas decisões.
Zeiss e MBRF tomaram caminhos opostos
A Zeiss interrompeu uma reconstrução
A Zeiss escolheu o greenfield para substituir o SAP legado. Ou seja, decidiu reconstruir o ambiente sobre o padrão do S/4HANA em nuvem.
Porém, quando a limpeza do legado virou uma reconstrução ampla da operação, a migração perdeu o foco. Como resultado, o projeto, iniciado em 2020, consumiu mais de €200 milhões, segundo a Bloomberg.
Afinal, cada processo redesenhado abria uma nova frente de análise, e as decisões funcionais se tornaram cada vez mais complexas. Por isso, a Zeiss mudou para o brownfield. Assim, o episódio ilustra o custo de adiar a decisão sobre redesenhar processos durante a migração de ERP.
A MBRF migrou o ERP sem redesenhar processos
A MBRF adotou o brownfield na migração do ECC para o S/4HANA em nuvem. Dessa forma, priorizou a conversão técnica e manteve as modificações no mínimo.
Além disso, separou a modernização da revisão dos processos, o que reduziu dependências. Então, depois do go-live, a empresa passou a revisar processos, automatizar atividades e explorar inteligência artificial sobre a nova plataforma.
Essa sequência oferece, portanto, uma resposta prática à dúvida central deste artigo.
Migrar o ERP e redesenhar processos exigem decisões diferentes
A migração preserva a operação em uma plataforma atualizada, enquanto o redesenho muda a forma de trabalhar.
Quando os dois entram no mesmo projeto, cada alteração funcional amplia o escopo, cria dependências e ameaça o cronograma técnico. Por isso, essa decisão deve partir do objetivo da empresa, e não da ferramenta escolhida.
O greenfield reconstrói o ambiente e orienta processos, dados e integrações pelo desenho futuro. Isso faz sentido quando o legado limita a transformação. No entanto, o risco aparece quando a empresa tenta arrumar tudo durante a migração. Afinal, sem escopo e limites claros, cada problema do legado vira uma nova frente.
Por isso, só vale a pena redesenhar processos durante a migração de ERP quando o legado impede a operação desejada.
Por outro lado, o brownfield preserva os dados, processos e customizações necessários. Além disso, adapta o ambiente à nova plataforma e elimina apenas o que não compromete a operação.
Assim, o redesenho fica restrito aos processos que o novo ambiente não consegue absorver.
O custo escondido de reconstruir processos durante a migração
O custo de um projeto de ERP vai além de licenças, consultorias e horas de desenvolvimento. Afinal, ele inclui a quantidade de decisões necessárias para entrar em produção.
Quanto mais processos a empresa redesenhar durante a migração, maior a superfície de mudança. Portanto, esse aumento pesa na conta de quem decide.
Cada processo redesenhado abre uma nova frente
Redesenhar um processo implica revisar regras, papéis, dados, integrações, controles e exceções. Por isso, uma mudança localizada afeta várias áreas. Além disso, o risco cresce quando as regras dependem do conhecimento de poucos profissionais e não estão documentadas.
Ao redesenhar durante a migração, a empresa transforma uma tarefa técnica em descoberta organizacional. Ou seja, tenta mapear a operação enquanto altera a plataforma que a sustenta.
Essa descoberta consome orçamento sem previsão. Por isso, o CFO precisa examinar com rigor se vale a pena redesenhar processos durante a migração de ERP.
A customização antiga precisa de classificação antes do descarte
Tratar toda customização acumulada como problema simplifica demais a questão. Afinal, ela pode atender ao negócio, corrigir limitações da plataforma, cumprir regras fiscais ou apenas permanecer por inércia.
Por isso, o inventário deve identificar por que cada customização existe, quem depende dela e qual o impacto de removê-la.
Sem esse levantamento, a empresa não tem base para decidir o que redesenhar. Isso porque desconhece o que cada regra sustenta.
O núcleo limpo mantém o ERP focado nos processos essenciais
O conceito de núcleo limpo, ou clean core, consiste em manter o ERP próximo do padrão da plataforma. Ou seja, extensões, automações e regras externas ficam em serviços complementares.
Dessa forma, a fronteira reduz customizações, facilita atualizações e torna o redesenho posterior mais barato e menos arriscado. Isso também ajuda a decidir se o redesenho entra agora ou espera a estabilização.
A camada fiscal é a candidata mais natural a ficar fora do núcleo. Afinal, ela muda conforme leis, leiautes, validações e particularidades estaduais e municipais. Incorporar toda a complexidade fiscal ao ERP em plena troca de plataforma aumenta o risco sem gerar vantagem operacional.
Nesse arranjo, portanto, redesenhar processos durante a migração de ERP deixa de incluir as regras tributárias. Assim, elas passam a evoluir em trilha própria.
A Webmania conecta o ERP ao ambiente fiscal
A Webmania oferece APIs para emissão e gestão de documentos fiscais, além de recursos de validação e automação. Inclusive, a plataforma processa mais de 15 milhões de documentos fiscais por mês.
A integração parte dos sistemas empresariais. Assim, o ERP consome emissão, consulta e validação sem incorporar cada particularidade dos fiscos. Logo, ERP e camada fiscal passam a evoluir em ritmos diferentes, e cada nova regra tributária deixa de exigir customização.
Esse ganho pesa sobretudo para empresas Mid-Market e Enterprise, que emitem grandes volumes de notas em vários estados.
O fim do suporte e a Reforma Tributária chegam pela mesma porta
Empresas com ERP legado enfrentam o fim da manutenção padrão do SAP ECC, marcado para o fim de 2027. Consequentemente, a margem para adiar a modernização diminui.
Ao mesmo tempo, a Reforma Tributária exige adaptações nos sistemas fiscais. Na verdade, os dois movimentos recaem, muitas vezes, sobre o mesmo time.
O calendário tecnológico já pressiona
Adiar a migração não elimina a decisão e ainda reduz o tempo disponível. Afinal, o projeto passa a disputar orçamento, especialistas e parceiros.
Tentar resolver todos os problemas do legado nesse período cria um projeto maior justamente quando há menos margem para atrasos. Nesse cenário, portanto, raramente vale a pena redesenhar processos durante a migração de ERP. A exceção é quando o redesenho é condição para operar.
No Brasil, uma segunda pressão acontece em paralelo
A Reforma Tributária impõe mudanças que não dependem da empresa. Afinal, legislação, regulamentação e novos documentos fiscais definem o ritmo da adaptação.
Como essas regras mudam por imposição externa, o calendário tributário não espera o fim do projeto.
O que deve ficar dentro do projeto de migração de ERP
A migração precisa garantir que o novo ambiente sustente a operação com segurança e permita evoluir depois. No entanto, ela não precisa resolver todos os problemas acumulados na vida útil do ERP.
Com esse critério, portanto, a resposta sobre o redesenho torna-se mais objetiva.
Mova primeiro o que precisa continuar funcionando
Primeiro, processos críticos, dados, integrações e regras essenciais devem ser avaliados pela continuidade.
Quando funcionam e não impedem a modernização, a empresa pode preservá-los. Afinal, a melhoria pode acontecer depois, sem transformar o go-live em dependência. Portanto, só vale a pena redesenhar processos durante a migração de ERP quando o processo atual bloqueia a nova plataforma.
Redesenhe depois o que precisa evoluir
Em seguida, com a plataforma estabilizada, a empresa revisa os processos sobre uma arquitetura atualizada, com mais recursos de automação.
Por exemplo, a MBRF seguiu essa sequência, e cada melhoria ganhou escopo e retorno próprios. Além disso, essa ordem ajuda o CTO a defender a estratégia perante o comitê executivo. Isso porque cada melhoria passa a ter um business case independente.
O projeto de migração de ERP exige duas perguntas
A primeira pergunta é técnica: como levar a operação atual para uma plataforma moderna sem interromper o negócio? A segunda, por outro lado, é estratégica: quais partes dessa operação precisam realmente ser transformadas?
Misturar as duas produz um projeto maior do que o necessário, enquanto separá-las permite tomar decisões diferentes para problemas diferentes. Afinal, a segunda pergunta é a que define se vale a pena redesenhar processos durante a migração de ERP.
Cinco critérios para redesenhar processos na migração de ERP
- Processo ou sistema. O time deve verificar se o processo precisa mudar ou se apenas o sistema precisa. Quando o processo continua atendendo ao negócio, não vale a pena redesenhar processos durante a migração de ERP. Afinal, o risco adicionado supera o retorno.
- Origem da customização. É preciso descobrir se ela existe por necessidade atual ou por herança do legado. Também é preciso entender que problema ela resolve e quem depende dela antes de eliminá-la.
- Dono da regra. A empresa deve identificar se a regra pertence ao negócio ou muda por decisão de terceiros. Portanto, quanto mais externa a origem, mais razão existe para colocá-la fora do núcleo.
- Momento do redesenho. O time precisa confirmar se o redesenho tem de ocorrer antes do go-live. Quando não tem, separar os projetos protege o cronograma. Nesse caso, também não vale a pena misturar os dois.
- Responsabilidade do novo ERP. A empresa deve garantir que o novo ERP responda apenas pelo que deveria estar dentro dele.
Em resumo, quem aplica esses critérios com honestidade chega a uma resposta clara. Só vale a pena redesenhar processos durante a migração de ERP quando o legado impede a operação. Todo o restante, por outro lado, pode esperar a estabilização da nova plataforma.
Por fim, se a camada fiscal está entre as peças que podem sair do núcleo, comece por ela. Para isso, conheça a documentação das APIs da Webmania e veja como o ERP consome emissão e validação sem customizações.
