Transformação financeira sem reimplementação do ERP

Chega um novo CFO, encontra uma função financeira mais lenta e menos esclarecedora do que devia ser, e o instinto é atribuir isso ao sistema. O ERP é antigo, ou está mal configurado, ou foi implementado para uma empresa mais pequena. Propõe-se uma reimplementação, é orçamentada e agendada para dentro de um ano.

Pela nossa experiência, esse instinto acerta talvez uma em cada três vezes. Mais frequentemente, o sistema existente é capaz de fazer a maior parte do que lhe é pedido, e a restrição está no desenho de processos, na disciplina de dados e na estrutura de reporting construídas por cima — nada disso é corrigido automaticamente por uma reimplementação, e boa parte disso será simplesmente reconstruída no novo sistema se não for tratada antes.

Isto importa porque uma reimplementação é a alavanca mais cara e de maior risco ao dispor de uma função financeira, e recorre-se a ela com frequência antes de se terem testado as alavancas mais baratas. Este artigo trata dessas alavancas mais baratas e de como determinar, honestamente, se realmente precisa da alavanca cara.

Por que motivo isto importa

O custo de uma reimplementação desnecessária não é apenas o desembolso direto, ainda que este seja substancial para uma empresa mid-market. São os dezoito meses de atenção organizacional que consome, o congelamento de qualquer outra melhoria enquanto o projeto está a decorrer, e o risco real — visível nos padrões de falha de implementações NetSuite que vemos repetidamente — de o novo sistema herdar os mesmos problemas de processo numa interface diferente, porque ninguém corrigiu o processo antes de o migrar.

Há um custo mais subtil. As equipas que passam por uma reimplementação sem corrigirem primeiro o processo tendem a especificar mal os requisitos, porque descrevem o seu processo atual e deficiente em vez do processo de que realmente precisam. O novo sistema implementa então fielmente a antiga disfunção, a um custo consideravelmente maior do que teria custado corrigir a disfunção diretamente.

A alternativa — a transformação a começar pelo processo — tem um perfil menos dramático e um retorno ajustado ao risco muito melhor. É também, e não por coincidência, a preparação que torna uma futura reimplementação (se for genuinamente necessária) mais barata e mais rápida, porque os requisitos já são conhecidos.

Num relance: o que uma reimplementação corrige e o que não corrige

O padrão: as limitações de plataforma são reais e exigem efetivamente substituição. Tudo o que está abaixo das duas primeiras linhas é processo, governação e configuração, e as empresas mid-market propõem rotineiramente a solução do topo da lista para um problema do fundo da lista.

O que funciona e sobre o que é preciso ser honesto

O que funciona:

Uma auditoria de capacidades antes da decisão de substituição. Antes de dimensionar uma reimplementação, estabeleça especificamente o que o sistema atual não consegue fazer — não o que faz mal por causa da forma como foi configurado, mas o que estruturalmente não consegue representar. É normalmente um exercício de duas a três semanas e é a coisa mais valiosa a fazer antes de se comprometer com algo maior.

Redesenho do plano de contas e das dimensões, feito independentemente de qualquer mudança de sistema. Um plano de contas construído para uma empresa com um quinto da sua dimensão atual, ou para um modelo de negócio que entretanto mudou, produz relatórios que não refletem a forma como o negócio é efetivamente conduzido — independentemente do ERP que o aloja. Isto pode ser redesenhado e migrado dentro do sistema existente.

Trabalho de reconciliação e de processo de fecho, tratado como projeto próprio. A disciplina do fecho em cinco dias — reconciliação contínua, datas de corte rígidas, tratamento de exceções assistido por agentes — é atingível na maioria dos ERP mid-market tal como estão. Raramente é o sistema que trava isto.

Racionalização da customização. Um sistema que se tornou frágil ao longo de anos de customização acumulada pode muitas vezes ser recuperado revendo e removendo o que já não é necessário, o que é materialmente mais barato do que substituir a plataforma que está por baixo.

Correções de governação e de propriedade. Os problemas de qualidade de dados que a área financeira atribui ao sistema são frequentemente um problema de propriedade — ninguém fora da área financeira responde pelos dados que cria. Isto corrige-se atribuindo propriedade e tornando a qualidade visível, não mudando de software.

Sobre o que é preciso ser honesto:

Alguns sistemas precisam genuinamente de ser substituídos. Se a sua estrutura de entidades, os seus requisitos de moeda, o seu volume transacional ou as suas necessidades setoriais excedem aquilo para que a plataforma foi construída, nenhum trabalho de processos fecha essa lacuna. A auditoria de capacidades existe para detetar isto honestamente, em vez de o pressupor ou de o negar.

O trabalho de processos não é gratuito e compete pela mesma atenção executiva. Exige disciplina de projeto real, patrocínio real e uma vontade genuína de mudar a forma como os departamentos trabalham — os mesmos ingredientes que uma reimplementação exige, apenas com um orçamento menor e um prazo mais curto. As empresas que não conseguiram sustentar disciplina de processos também terão dificuldade em sustentá-la aqui.

A sequência importa e é frequentemente ignorada. Fazer o trabalho de processos e descobrir depois que precisava mesmo de uma reimplementação não é esforço desperdiçado — o trabalho de processos torna-se nos seus requisitos —, mas fazer primeiro uma reimplementação e descobrir depois que os problemas de processo se mantêm é, sem dúvida, despesa desperdiçada. Coloque sempre o processo antes da plataforma.

Alguns responsáveis querem a reimplementação de qualquer maneira. Um projeto grande e visível é às vezes desejado por razões alheias ao problema declarado — um novo CFO que quer um mandato visível, um conselho de administração que quer ver ação decidida. É uma dinâmica organizacional legítima e vale a pena nomeá-la honestamente em vez de a disfarçar de necessidade técnica.

Quadro de decisão: substituir ou corrigir a camada de processos

Percorra por ordem. Pare na primeira correspondência.

1. Consegue nomear uma transação, estrutura de entidades ou requisito de reporting específicos que o sistema atual não consiga representar, independentemente da configuração?
Se sim e for material, provavelmente precisa de uma mudança de plataforma — mas dimensione a substituição em torno dessa lacuna específica, e não em torno de um descontentamento geral. Se não, prossiga.

2. O seu descontentamento diz respeito, na verdade, à velocidade do fecho, à fiabilidade dos relatórios ou à qualidade dos dados?
Estes são os problemas mais frequentemente mal atribuídos. Percorra o quadro do fecho em cinco dias e o modelo de custódia de master data antes de pressupor uma limitação de plataforma. A maioria dos problemas de fecho e de reporting no mid-market resolve-se aqui.

3. O seu plano de contas ou a sua estrutura dimensional acompanharam o negócio?
Se não, redesenhe-os dentro do sistema atual. Só isto resolve uma parte considerável das queixas do tipo "o nosso reporting não reflete o negócio" e não exige migração.

4. O sistema está fortemente customizado e frágil?
Faça uma revisão de customização antes de pressupor que a substituição é o único caminho. Distinga a customização irrecuperável — construída sobre uma versão ou arquitetura que o fornecedor já não suporta bem — da customização que está simplesmente por documentar e desarrumada, que pode ser racionalizada no lugar.

5. Os problemas de qualidade e de propriedade dos dados são, na verdade, organizacionais e não técnicos?
Se os dados chegam tarde ou errados de fora da área financeira, isso é uma correção de governação, e nenhuma mudança de sistema o resolve, incluindo um sistema novo.

6. Concluiu uma auditoria de capacidades genuína, independente do contributo do fornecedor?
Se não, encomende uma antes de qualquer conversa sobre orçamento. É o artefacto que separa "estamos descontentes com os nossos sistemas financeiros" de um verdadeiro caso de negócio.

7. Auditoria concluída e lacuna confirmada e material?
Dimensione agora uma reimplementação — mas dimensione-a face a um processo que já foi corrigido, para que o novo sistema herde boas práticas em vez de codificar a antiga disfunção.

Custo e esforço indicativos

O trabalho que começa pelo processo custa habitualmente uma fração de uma reimplementação e entrega a maior parte da melhoria que um CFO procura na realidade. Peça um orçamento para uma auditoria de capacidades dimensionada.

Perguntas frequentes

Como sabemos se o nosso descontentamento é com o sistema ou com o processo construído sobre ele?
A auditoria de capacidades foi concebida precisamente para responder a isto, separando "o sistema não consegue fazer X" de "o sistema nunca foi configurado nem usado para fazer X". A maior parte do descontentamento no mid-market cai na segunda categoria.

Os fornecedores e os partners de implementação dão-nos uma resposta honesta nesta matéria?
Desconfie de quem tenha receitas dependentes de a resposta ser "substitua-o". Uma auditoria é mais credível quando é dimensionada e entregue independentemente de quem lhe possa vender a substituição.

Podemos fazer o trabalho a começar pelo processo e ainda assim acabar por precisar de uma reimplementação mais tarde?
Sim, e esse é um bom resultado, não uma falha. Terá corrigido problemas que de outro modo teriam sido reconstruídos no novo sistema, e dimensionará a eventual substituição com requisitos reais em vez de suposições.

Quanto tempo leva o trabalho que começa pelo processo a mostrar resultados?
As melhorias de fecho e de reconciliação são visíveis dentro de um a dois trimestres. O redesenho do plano de contas nota-se no ciclo de reporting completo seguinte. As mudanças de governação e de propriedade levam mais tempo a enraizar — tipicamente dois a três trimestres antes de a melhoria de qualidade de dados ser durável e não um empurrão temporário.

Qual é o maior sinal de que realmente precisamos de uma reimplementação?
Quando a auditoria de capacidades produz uma lacuna estrutural específica e nomeada — uma moeda que o seu sistema não consegue tratar, uma estrutura de entidades que não consegue modelar, um volume transacional que não consegue processar — em vez de uma lista genérica de frustrações. A frustração é um sintoma. Uma lacuna estrutural nomeada é um caso de negócio.

Fecho — Próximos passos

A transformação financeira é habitualmente vendida como uma decisão de plataforma, porque essa é a versão visível e financiável do pedido. A maior parte do valor real está por baixo da plataforma, no processo, na governação e na estrutura — e está disponível mais depressa, com menos risco e sem o congelamento de dezoito meses que uma reimplementação impõe a tudo o resto.

O primeiro passo honesto é a auditoria de capacidades, conduzida independentemente de quem tenha interesse na resposta. Se encontrar uma lacuna estrutural genuína, passa a ter um verdadeiro caso de negócio. Se não encontrar — que é o resultado mais comum —, tem um roteiro mais barato e mais rápido e a opção de voltar à substituição quando tiver esgotado o que a melhoria de processos pode dar.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento de documentos e a reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis e com automonitorização.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são de nível editorial e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de capacidades da plataforma e de configuração — https://docs.oracle.com/en/cloud/saas/netsuite/
• APQC, Open Standards Benchmarking — medidas de transformação financeira e de desempenho de processos — https://www.apqc.org
• Panorama Consulting Group, ERP Report anual — dados sobre a decisão de substituir versus otimizar — https://www.panorama-consulting.com
• Experiência de projetos da Atypical Tech em transformação financeira mid-market na Ibéria