Implementações de NetSuite que atrasam: 7 padrões de falha

Uma implementação de NetSuite no mid-market é normalmente dimensionada em quatro a sete meses. Pela nossa experiência com clientes ibéricos, as que atrasam não atrasam duas semanas — atrasam um trimestre ou mais, e atrasam por um número reduzido de causas que se repetem com uma constância quase tediosa.

Essa constância é a parte útil. Se a falha fosse aleatória, a única defesa seria orçamento de contingência. Não é aleatória. Nos projetos que herdámos de outros partners a meio do percurso, os mesmos sete padrões explicam a grande maioria do desvio e, em todos os casos, o padrão era detetável no primeiro mês — normalmente na primeira quinzena — por alguém que soubesse o que procurar.

Este artigo é essa lista. Está escrito para ser usado como diagnóstico num projeto já em curso, e não apenas como lista de verificação para um que está a ser planeado.

Por que razão isto importa

O custo de um desvio num ERP não são os honorários adicionais de consultoria, ainda que sejam a parte que aparece no dossiê para o conselho de administração. O custo real é cumulativo e, em grande medida, invisível.

Um projeto que atrasa dois trimestres obriga a equipa financeira a manter dois sistemas em paralelo ao longo de dois fechos adicionais. Consome a credibilidade do sponsor interno, que é o recurso de que o projeto mais precisa no seu último terço. E empurra o go-live para um período que ninguém escolheu — e o momento do go-live importa, porque arrancar com um ERP novo três semanas antes de um prazo de reporte obrigatório ou em plena época alta de vendas transforma uma transição gerível numa crise.

O mais determinante é que altera aquilo em que a organização acredita. Uma empresa que passou por um mau projeto de ERP vai adiar por anos a mudança necessária seguinte e vai abordá-la com um aparato de governação tão pesado que a segunda tentativa será mais lenta do que a primeira. O desvio é caro; a cicatriz institucional é-o ainda mais.

Num relance: os sete padrões

A coluna que importa é a segunda. Todos os sinais são observáveis muito antes da fase em que o custo aterra.

Os sete padrões em detalhe

1. Requisitos recolhidos como lista de funcionalidades em vez de como processo.
O modo de falha é um documento de requisitos que se lê como uma lista de coisas que o sistema tem de conseguir fazer, sem qualquer descrição dos fluxos de ponta a ponta que essas capacidades têm de servir. O sistema é construído contra a lista, passa uma verificação funcional contra a lista e depois chumba na aceitação pelo utilizador porque ninguém consegue completar nele um dia real de trabalho. A correção não tem glamour: documente os oito a doze processos de ponta a ponta que importam — order-to-cash, compra a pagamento, registo a reporte, devoluções, fecho — como fluxos com responsáveis e passagens de mão, e desenhe contra esses.

2. Ausência de um único decisor com autoridade.
O desenho de um ERP gera centenas de decisões, muitas delas transversais e algumas genuinamente de soma nula entre departamentos. Se não existir uma pessoa que possa resolver essas decisões sem convocar um comité, o projeto não falha de forma ruidosa — acumula uma fila de pontos abertos que discretamente se torna o caminho crítico. O sinal é fácil de ler: veja quanto tempo as decisões de desenho ficam sem resolução na semana quatro. Se a resposta for mais do que alguns dias, o projeto vai atrasar e nenhum esforço de execução o evitará.

3. Qualidade dos dados descoberta tarde.
Todos os planos de implementação contêm uma fase de migração. Muito poucos contêm uma fase de análise de perfil, que é onde se descobre que 30 % dos registos de clientes são duplicados, que os artigos históricos têm unidades de medida inconsistentes, que os dados bancários dos fornecedores existem em três formatos e que os saldos de abertura não fecham. Descobrir isto durante a migração significa renegociar o calendário no pior momento possível. Analise o perfil dos dados no primeiro mês, enquanto a descoberta ainda é barata.

4. Customização como resposta por omissão a todas as lacunas.
Cada customização individual é defensável. O que mata é o agregado: uma instância fortemente programada é mais lenta a testar, mais difícil de suportar, mais arriscada nas atualizações e — a parte que surpreende os clientes — mais lenta a alterar mais tarde, o que era normalmente a razão para implementar em primeiro lugar. A disciplina consiste em exigir, para cada customização proposta, uma resposta explícita a "o que é que se parte se adotarmos o processo padrão em vez disto?". Às vezes a resposta é real. Muitas vezes a resposta honesta é que alguém prefere a forma antiga, e isso não é um requisito.

5. Integração tratada como tarefa a jusante.
Na maioria dos projetos problemáticos que vemos, a integração é dimensionada depois da configuração base, e é aí que o calendário efetivamente se perde. A razão é que a integração é o ponto em que os pressupostos de dois sistemas sobre o mesmo objeto — um cliente, uma encomenda, um preço — têm de ser reconciliados, e esses pressupostos são normalmente incompatíveis de formas que forçam alterações de desenho de volta à construção base. O desenho da integração pertence à mesma fase que o desenho base, e não a uma fase posterior.

6. Operações não representadas no desenho.
A área financeira patrocina os projetos de ERP, pelo que a área financeira comparece nos workshops. O armazém, a equipa de vendas e o serviço ao cliente frequentemente não comparecem, ou enviam alguém sem autoridade. O resultado é um sistema que fecha as contas de forma impecável e torna o picking, a elaboração de propostas ou o atendimento de uma chamada de cliente materialmente mais lentos do que antes. A resistência operacional no go-live é quase sempre uma falha de desenho vestida de gestão da mudança.

7. Formação agendada como última atividade.
A formação é comprimida porque fica no fim de um plano que já consumiu a sua folga. A consequência visível são dois primeiros meses lentos e propensos a erro. A invisível é duradoura: os utilizadores que aprenderam um sistema sob pressão de tempo desenvolvem contornos, e esses contornos tornam-se o processo permanente da organização. Nomeie um responsável pela formação e fixe as datas no início do projeto, e proteja-as.

Sobre o que é preciso ser honesto

Parte do atraso é legítima. Um projeto que se prolonga porque o negócio mudou genuinamente — uma aquisição, um novo canal, uma alteração regulatória — não está a falhar. Confundir alteração de âmbito com falha produz uma equipa de projeto que esconde os novos requisitos, o que é pior.

Nem todos os padrões são culpa da consultora, nem todos são do cliente. Os padrões 1, 4 e 5 recaem normalmente sobre o partner de implementação. Os padrões 2, 6 e 7 recaem normalmente sobre o cliente. O padrão 3 é partilhado. Um partner que culpa o cliente pelos sete não é um partner a manter, e um cliente que culpa o partner pelos sete terá o mesmo projeto duas vezes.

Corrigir um padrão a meio do percurso custa mais do que preveni-lo, e ainda assim vale a pena. O instinto quando um projeto está atrasado é apertar mais na execução. Se a causa subjacente for o padrão 2 ou o 3, apertar mais agrava o desvio, porque se está a construir mais depressa sobre decisões que não estão resolvidas ou dados que não estão limpos.

Uma implementação limpa não garante a adoção. Estes padrões preveem se se entra em produção a horas e dentro do orçamento. Se o sistema é efetivamente bem utilizado é um problema distinto com uma resposta distinta, sobretudo relacionada com propriedade e medição depois do go-live.

Quadro de decisão: diagnosticar um projeto em curso

Percorra por ordem. Pare na primeira correspondência — esse é o seu problema principal, e os pontos seguintes não se resolverão enquanto ele não for resolvido.

1. Há decisões de desenho sem resolução há mais de uma semana?
Corrija a governação antes de tudo o resto. Nomeie um decisor com autoridade sobre o desenho transversal, dê-lhe um espaço fixo na agenda e estabeleça a regra de que um ponto não decidido passa por omissão para o comportamento padrão do sistema após um prazo fixo. Nada mais nesta lista pode ser corrigido enquanto as decisões estiverem estagnadas.

2. Alguém analisou o perfil dos dados reais?
Se não, pare e analise agora — contagens de registos, duplicados, completude dos campos obrigatórios, integridade referencial, se os saldos de abertura fecham. Uma semana investida aqui volta a avaliar honestamente o resto do plano.

3. A documentação de requisitos descreve os processos de ponta a ponta?
Se for uma lista de funcionalidades, reconstrua-a como fluxos antes de continuar a configurar. Consegue fazê-lo em workshops ao longo de duas semanas e fará emergir as lacunas que de outro modo apareceriam no UAT.

4. A integração foi desenhada, ou apenas enumerada?
Se foi apenas enumerada, traga-a para o desenho imediatamente e especifique, por cada objeto integrado, o sistema de referência, a direção do fluxo, a regra de resolução de conflitos e o requisito de latência. Faça-o antes de continuar a configuração base, porque as respostas alteram a base.

5. O número de customizações está a crescer de sprint para sprint?
Se sim, institua um controlo de customizações: cada pedido precisa de uma consequência de negócio concreta por adotar o padrão em vez disso. Conte com rejeitar um terço delas, e conte que isso seja desconfortável.

6. O armazém, as vendas e o serviço ao cliente validaram os seus próprios processos?
Se não, realize esses workshops antes do UAT, em vez de descobrir a lacuna durante ele.

7. A formação tem um responsável nomeado e datas protegidas?
Se não, atribua ambos agora e trate essas datas como inamovíveis e não como a folga do projeto.

Custo e esforço indicativos

Os intervalos pressupõem uma única instância de NetSuite, uma a cinco entidades e um perfil transacional de mid-market. Ambientes multi-instância, operações de M&A em simultâneo ou um projeto já depois do UAT alteram isto de forma substancial. Peça um orçamento para uma avaliação dimensionada ao seu projeto.

Perguntas frequentes

O nosso projeto já está atrasado. Devemos mexer na data de go-live ou apertar com a equipa?
Diagnostique primeiro. Se a causa forem decisões estagnadas, dados sujos ou integração não desenhada, apertar com a equipa aumenta o custo final porque se está a construir sobre fundações instáveis. Se a construção for genuinamente sólida e o que resta for volume, um empurrão pode funcionar. Estabelecer a distinção leva cerca de uma semana e é a semana de maior valor de que dispõe.

Como sabemos se o problema é o nosso partner de implementação?
Veja quais os padrões presentes. Um partner responsável por um documento de requisitos em formato lista de funcionalidades, por um número de customizações não gerido e por uma integração não dimensionada não está a entregar ao nível exigível. Um partner confrontado com decisões estagnadas do cliente, responsáveis operacionais ausentes e nenhum responsável pela formação está a ser impedido de entregar. Ambas as situações são recuperáveis; exigem respostas opostas.

Podemos entrar em produção por fases para reduzir o risco?
Muitas vezes sim e, para grupos com várias entidades, é normalmente o correto. Mas o faseamento tem um custo: um período com dois sistemas a funcionar, com reconciliação entre eles. Faseie ao longo de fronteiras onde a reconciliação seja barata — por entidade legal ou por geografia, raramente por função — porque dividir o order-to-cash entre dois sistemas cria precisamente o encargo de reconciliação que o projeto devia eliminar.

Quanta contingência deve ter um projeto de ERP no mid-market?
Em vez de uma percentagem, coloque a contingência onde a incerteza efetivamente está — correção de dados e integração, que é onde os desvios se concentram. Um plano com 15 % distribuídos uniformemente é menos útil do que um com intervalos realistas nessas duas frentes de trabalho e estimativas apertadas no resto.

Ainda não começámos. Qual é a coisa de maior valor a fazer primeiro?
Analisar o perfil dos seus dados e nomear o seu decisor. Ambas custam quase nada, ambas são habitualmente omitidas e, juntas, cobrem os dois padrões que geram os maiores desvios.

Encerramento — Próximos passos

Nenhum destes sete padrões é exótico e nenhum exige ferramentas especializadas para ser detetado. O que exigem é alguém disposto a procurá-los cedo, quando a descoberta é inconveniente e não catastrófica — que é precisamente quando ninguém a quer ouvir, porque o projeto continua nominalmente dentro do prazo.

Se a sua implementação está em curso, o diagnóstico acima leva uma manhã. Percorra-o por ordem e pare na primeira correspondência. Se ainda está em planeamento, as duas apólices de seguro mais baratas ao seu alcance são uma análise de perfil dos dados e um decisor nomeado, e nenhuma delas precisa de rubrica orçamental.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes do mid-market em toda a Península Ibérica. Especializa-se em ligar sistemas CRM e ERP para fluxos de order-to-cash sem fricção, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas de vendas e financeira. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar encaminhamento de exceções, processamento de documentos e 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 a nível de editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de implementação e de boas práticas — https://docs.oracle.com/en/cloud/saas/netsuite/
• APQC, Open Standards Benchmarking (indicadores de desempenho de projetos de ERP e TI) — https://www.apqc.org
• Panorama Consulting Group, ERP Report anual (dados de duração, orçamento e concretização de benefícios dos projetos) — https://www.panorama-consulting.com
• Standish Group, CHAOS Report (investigação sobre resultados de projetos de TI) — https://www.standishgroup.com
• Experiência da Atypical Tech em projetos de implementação de NetSuite no mid-market ibérico