Pós go-live de ERP: como saber se a migração entregou o prometido

Medir o pós go-live de ERP é comparar o processo real antes e depois da migração: tempo de ciclo, retrabalho, trabalho paralelo fora do sistema, aprovações que escapam do fluxo e horas da equipe. Chamados fechados e disponibilidade do sistema mostram que o ERP novo está de pé; não mostram se a operação ficou melhor do que era.

Este artigo é para quem está entre o primeiro e o sexto mês depois da virada, com a operação ainda instável e a diretoria perguntando se valeu a pena.

Por que chamados e disponibilidade não respondem à diretoria

No hypercare, o painel do projeto mostra chamados por severidade e disponibilidade do ambiente. São os números certos para aquela fase. O problema é quando continuam sendo os únicos no terceiro mês, porque uma operação pode ter zero chamados críticos e estar pior do que antes da migração. Três formas comuns:

O usuário parou de abrir chamado. Sem resposta para um problema menor, a pessoa resolve por fora. A fila cai, e a planilha cresce.

O sistema funciona, mas o processo ficou mais longo. Uma aprovação que tinha um nível agora tem três, porque a configuração seguiu o desenho de alçada do projeto. Nada está quebrado; o pedido só demora mais.

O ganho prometido não era de sistema. Fechamento mais rápido, menos redigitação, menos conferência manual: nenhum desses resultados do business case aparece em um painel de suporte.

A pergunta da diretoria é de processo, e responder exige medir o processo do mesmo jeito antes e depois.

As três fases do pós go-live e o que acompanhar em cada uma

A duração de cada fase varia por projeto. O que muda de uma para outra é a pergunta que se tenta responder.

Fase	Pergunta central	O que acompanhar	Quem é dono	Sinal de alerta
Hypercare (primeiras semanas)	O sistema suporta a operação?	Chamados por severidade, erros de interface, falhas de cadastro e de saldo migrado, transações paradas	Gerente do projeto com o parceiro de implantação	Chamados repetidos sobre o mesmo processo; áreas que deixaram de abrir chamado
Estabilização (primeiros meses)	A operação voltou ao ritmo normal?	Tempo de ciclo dos processos críticos, backlog acumulado, fechamento contábil no prazo, uso real das funções novas	Donos de processo de cada área, com o CIO	Backlog que não volta ao nível de antes; fechamento que só sai com hora extra; planilhas de controle surgindo
Otimização (a partir da estabilização)	A migração entregou o business case?	Indicadores de processo comparados com a linha de base: horas por atividade, retrabalho, trabalho paralelo, aprovações fora do sistema	CFO e diretoria, com os donos de processo	Ganho que aparece no relatório mas não nas horas da equipe; ninguém consegue dizer qual era o "antes"

O erro mais caro é encerrar o hypercare e não abrir a fase de otimização. O projeto passa para o suporte contínuo, a equipe de implantação sai, e a pergunta "valeu a pena?" fica sem dono.

Indicadores de processo, não só de sistema

Indicadores de sistema medem o ERP. Indicadores de processo medem o trabalho que o ERP deveria facilitar. Os dois são necessários, e só o segundo responde à diretoria.

Indicador de processo	O que revela	De onde vem a medida
Tempo de ciclo ponta a ponta (do pedido ao pagamento, da venda ao recebimento)	Se o fluxo ficou mais rápido ou mais lento depois da virada	Log de eventos do ERP
Retrabalho (documentos estornados, alterados depois de aprovados, refeitos)	Se a configuração ou o treinamento estão gerando erro	Log de eventos do ERP, confirmado pelas pessoas
Trabalho paralelo em planilha	Controles que o sistema novo não cobre ou que ninguém confia que cobre	Relato das pessoas
Aprovações fora do sistema (e-mail, mensagem, assinatura em papel)	Alçadas mal configuradas ou mal compreendidas	Relato das pessoas; parte aparece no log como aprovação tardia
Redigitação entre sistemas	Integrações que não vieram ou que ninguém usa	Relato das pessoas
Horas da equipe por atividade	O custo real da operação, comparável com o business case	Relato das pessoas, convertido em reais com premissa declarada

O retrabalho tem custo direto e quase sempre subestimado. A calculadora de custo do retrabalho ajuda a colocar um valor em reais nesse indicador antes da conversa com a diretoria.

O que o sistema mostra: o log de eventos como base

Todo ERP registra quem fez o quê e quando. Lidos em sequência, esses registros formam um log de eventos, e o process mining reconstrói a partir dele o fluxo real de cada pedido, nota ou lançamento: tempo de ciclo, variantes, gargalos, retrabalho. É a base mais confiável para o lado registrado do processo.

No pós go-live, dois cuidados tornam essa base comparável.

Um vocabulário comum de etapas. O ERP antigo e o novo registram etapas com nomes e granularidades diferentes. Para comparar antes e depois, as duas histórias precisam ser traduzidas para as mesmas etapas de negócio: pedido criado, aprovado, recebido, faturado, pago. Sem isso, a comparação mede a diferença entre os sistemas, não entre os processos.

Separar o que foi migrado em aberto. Nas primeiras semanas, o sistema novo processa documentos que nasceram no antigo. O tempo de ciclo desses casos mistura os dois mundos e distorce a média. A comparação justa usa os casos que começaram e terminaram no sistema novo.

Com esses dois cuidados, a plataforma de process intelligence mostra, com a mesma régua, como o fluxo andava no ERP antigo e como anda no novo.

O que só as pessoas contam

O log mostra o que o sistema registra. Uma parte relevante do trabalho depois de uma migração acontece fora dele, justamente porque é a parte que o sistema novo ainda não resolveu.

• A planilha que o analista voltou a manter porque não confia no relatório novo.
• A aprovação combinada por mensagem antes de ser registrada, para não esperar a fila.
• A conferência a olho de um cálculo que o sistema faz, mas que ninguém ainda viu dar certo por três meses seguidos.
• O relatório gerencial que agora junta duas extrações, porque o padrão do sistema novo não traz a visão que a diretoria pedia.

Nenhum desses itens aparece no log, e todos consomem horas. Juntos, log e relato fazem o mapa completo: um mostra o fluxo registrado com precisão, o outro o trabalho que fica em volta dele.

Como repetir o censo depois do go-live

Se a empresa fez um levantamento completo antes da migração, como descrito no post sobre levantamento de processos antes do ERP, ela já tem a linha de base do lado não registrado: atividades por pessoa, horas, planilhas, controles manuais e integrações informais. Medir o resultado é repetir esse levantamento com a mesma régua.

O Nous Scan faz isso por censo. Um agente de IA entrevista 100% do time do escopo, por link e sem agendar nada. Em duas semanas devolve o mapa da operação: onde o trabalho trava, quanto custa em horas e em reais, e a fila de evolução, do ajuste de processo que não precisa de tecnologia ao que um agente de IA resolve. Nada é plugado em sistema nenhum, o que importa nessa fase: o TI está ocupado com o próprio pós go-live, e o censo não gera demanda para ele. A liderança vê o consolidado, nunca a entrevista individual, e é isso que faz as pessoas contarem sobre a planilha que voltou a existir.

Três regras para a comparação valer.

Mesmo escopo. As mesmas áreas e funções. Se a migração centralizou ou terceirizou uma área, compare por atividade, não por área.

Mesma premissa de custo. O custo por hora precisa ser o mesmo do antes, ou corrigido de forma declarada. Senão a diferença é de premissa, não de processo.

Momento certo. No meio do hypercare, tudo é ruído: a rotina ainda não existe. O censo faz sentido quando os chamados críticos deixaram de dominar o dia, e ainda há tempo de corrigir antes que os desvios virem hábito.

Se não houve censo antes, o comparativo fica mais pobre, não impossível: o log do ERP antigo guarda o lado registrado do antes, e o lado não registrado só pode ser reconstruído pela lembrança das pessoas.

Exemplo: o total esconde a troca

Exemplo ilustrativo, com números hipotéticos. Área de contas a pagar com 14 pessoas, custo por hora carregado de R$ 50, mesma premissa antes e depois.

Atividade	Horas por mês antes	Horas por mês depois	Diferença
Lançamento e conferência de notas	420	260	−160
Controle de aprovações em planilha	30	90	+60
Conciliação de pagamentos	120	70	−50
Montagem do relatório semanal	16	48	+32
Total	586	468	−118

O total caiu 118 horas por mês, cerca de R$ 5.900 por mês na premissa adotada. Mas o controle de aprovações foi para a planilha e o relatório semanal ficou mais trabalhoso: 92 horas por mês que não existiam. Um painel de chamados não mostraria nenhuma das duas, e é nelas que está o próximo ganho.

O que fazer com os desvios

Cada desvio encontrado tem uma causa, e a ordem de tratamento importa. Começar pelo mais caro é o caminho mais comum, e quase sempre o errado.

Tipo de desvio	Sinal típico	Primeira resposta	Quem resolve
Processo	Duas áreas fazem a mesma etapa de jeitos diferentes; regra que ninguém sabe quem definiu	Ajustar e documentar o processo, sem mexer no sistema	Dono do processo
Treinamento	Uma parte do time usa a função, outra contorna	Treinar por perfil de atividade real, não por módulo	Gestor da área com o key user
Configuração	Todos contornam o mesmo ponto; alçada que não corresponde à prática	Revisar a parametrização com o parceiro de implantação	CIO com o parceiro
Rotina estável e repetitiva	Processo já ajustado, sistema configurado, e a atividade continua consumindo muitas horas em tarefas de regra clara	Avaliar execução por agentes de IA	Dono do processo com TI

A sequência é deliberada: ajuste de processo não custa licença nem projeto, treinamento resolve boa parte do que parece defeito de sistema, e configuração exige o parceiro e um ciclo de teste. Só depois, com o processo estável, faz sentido colocar agentes de IA executando rotina: automatizar um processo que ainda está mudando é automatizar o desvio.

No exemplo acima, a planilha de aprovações é provavelmente configuração, e o relatório semanal, treinamento. Nenhum dos dois pede tecnologia nova.

Como responder "valeu a pena?" para a diretoria

Em uma página: o que melhorou, em horas e reais por ano, com a premissa declarada; o que piorou ou surgiu, com a mesma régua (esconder essa parte destrói a credibilidade da primeira); o que ainda não dá para medir, como o fechamento anual; e a fila de correção, com dono e prazo. Com esse formato, a diretoria discute prioridades, não se o projeto deu certo.

Perguntas frequentes

O que é hypercare em um projeto de ERP?

É o período logo após o go-live em que a equipe do projeto e o parceiro de implantação continuam dedicados ao suporte, resolvendo defeitos e problemas de dados com prioridade. Termina quando o volume de chamados se estabiliza e o suporte passa para a estrutura contínua.

Quanto tempo dura a estabilização pós implantação de ERP?

Varia com o tamanho do projeto, o número de áreas e se a virada foi de uma vez ou por ondas. O critério mais útil não é o calendário, e sim o processo: a estabilização termina quando os processos críticos voltaram ao tempo de ciclo de antes, o backlog acumulado foi absorvido e o fechamento sai no prazo sem esforço extraordinário.

Como medir o sucesso da implantação de ERP?

Comparando o processo real antes e depois, com a mesma régua: tempo de ciclo, retrabalho, trabalho paralelo em planilha, aprovações fora do sistema e horas da equipe por atividade. O log de eventos do ERP mede o que o sistema registra; um levantamento com as pessoas mede o que fica fora dele.

Process mining serve para avaliar a migração de ERP?

Serve, e é a base do lado registrado da comparação. Ele reconstrói o fluxo real a partir dos registros do ERP antigo e do novo e mostra tempo de ciclo, variantes e retrabalho. Para comparar, os dois logs precisam ser traduzidos para as mesmas etapas de negócio, e os documentos migrados em aberto devem ser tratados à parte.

Dá para medir o resultado se não houve levantamento antes da migração?

Dá, com menos precisão. O histórico do ERP antigo ainda permite reconstruir o fluxo registrado do antes. O que se perde é a linha de base do trabalho fora do sistema, que só pode ser estimada pela lembrança das pessoas. Um censo feito agora mostra a operação atual e passa a ser a linha de base das próximas medições.

Quando colocar agentes de IA depois do go-live?

Depois que o processo foi ajustado, o time foi treinado e a configuração foi revisada. Agentes de IA funcionam melhor em rotinas estáveis, repetitivas e com regra clara. Colocados no meio da estabilização, tendem a automatizar contornos que deveriam ser corrigidos.

Próximo passo

Se a migração já foi feita e a pergunta da diretoria está na mesa, o Nous Scan mede a operação de hoje em duas semanas, sem tocar no ERP novo nem gerar demanda para o TI. A página de mapeamento de processos com IA mostra como é a entrega.