Levantamento de processos antes do ERP: o que mapear antes da implantação ou migração

13 min de leitura

Implantação de ERP atrasa quando o levantamento ouve um key user por área e o processo real mora em planilha, e-mail e WhatsApp. Veja o que mapear antes do fit-gap, a diferença entre migração e troca de sistema e um checklist de pré-projeto.

Levantamento de processos antes do ERP: o que mapear antes da implantação ou migração

O levantamento de processos para implantação de ERP é a etapa que descobre como a empresa realmente trabalha antes de decidir como o sistema novo vai ser configurado. Ele é o insumo do fit-gap, do blueprint, do plano de treinamento e do business case. Quando é feito com um key user por área e em cima do processo desenhado, o projeto descobre o processo real na fase de testes, que é o momento mais caro para descobrir qualquer coisa.

Este artigo mostra o que levantar antes, o que o fit-gap precisa receber, como muda a conta entre migração de versão e troca de ERP, e o papel do parceiro de implantação. É neutro entre fabricantes: os exemplos citam Protheus, Datasul, RM e SAP porque são os mais comuns no Brasil, e o raciocínio vale para qualquer um.

Por que a implantação de ERP atrasa e estoura o orçamento

As causas aparecem com nomes diferentes em cada projeto: escopo que cresce, customização não prevista, usuário que rejeita o sistema na virada. Por trás, o mecanismo costuma ser um só. O projeto foi planejado sobre uma descrição do processo que não corresponde ao que as pessoas fazem.

Três razões para essa distância.

O levantamento ouve um key user por área. É o formato padrão: o consultor funcional faz workshops com uma pessoa-chave de cada departamento. O key user é escolhido por conhecer bem a área, e conhece. Mas descreve o processo da própria mesa e o caso normal. Não sabe o que a colega da filial faz diferente, nem o controle que o analista mais antigo mantém há dez anos. E costuma ser a pessoa mais ocupada da área, respondendo entre uma urgência e outra.

O processo real mora fora do sistema. O ERP atual registra pedidos, notas e lançamentos. Não registra a planilha que controla a fila de aprovação, o e-mail que substitui o workflow, o grupo de WhatsApp em que a expedição combina a ordem de carregamento com o comercial. Esses controles existem porque o sistema atual não cobre alguma necessidade. São exatamente os requisitos que o sistema novo precisaria atender, e ficam invisíveis para quem levanta olhando telas e relatórios do legado.

A exceção não aparece no workshop. Perguntado como funciona o faturamento, o key user descreve o fluxo que funciona. A venda com entrega parcial, a devolução com nota de terceiro, o cliente com regra fiscal especial aparecem depois, nos testes integrados, como "o sistema não faz isso". Cada uma vira uma discussão de mudança de escopo.

O que é fit-gap de ERP e o que ele precisa como insumo

A análise fit-gap compara os requisitos do negócio com o que o ERP entrega de forma padrão. Cada requisito cai em uma de três situações:

  • Fit: o padrão do sistema atende. Basta parametrizar e treinar.
  • Gap com solução: o padrão não atende, e decide-se entre mudar o processo para aderir ao padrão, parametrizar de forma avançada, customizar ou usar um sistema satélite.
  • Fora do escopo: o requisito existe, mas não será tratado neste projeto.

O resultado é a lista de gaps com a decisão e o esforço de cada um. Dela saem o escopo de customização, boa parte do cronograma e uma fatia relevante do orçamento.

O ponto que costuma passar despercebido: o fit-gap só analisa os requisitos que chegam até ele. A qualidade da análise é limitada pela qualidade da lista. Um fit-gap impecável sobre uma lista incompleta produz um projeto bem planejado para uma empresa que não existe.

O que a lista de requisitos precisa conter para o fit-gap ser confiável:

  • as atividades que as pessoas executam, não os módulos que a empresa contratou;
  • volume e frequência de cada uma, para separar o que merece customização do que pode ser feito à mão duas vezes por ano;
  • as exceções, com uma estimativa de quantas vezes ocorrem;
  • os controles mantidos fora do sistema e a razão de existirem;
  • os pontos de passagem entre áreas, que é onde módulos diferentes precisam conversar.

O que levantar antes da implantação do ERP

Seis itens. Nenhum deles aparece em documentação do sistema atual.

Atividades reais por pessoa

Para cada pessoa do escopo: o que faz, com que frequência, quanto tempo leva, em que sistema ou ferramenta, e onde trava. É a base de tudo. A técnica está detalhada no post sobre mapeamento de atividades, e o roteiro de entrevista para levantamento de processos traz as perguntas.

Planilhas paralelas

Toda planilha de uso recorrente é um requisito não atendido com interface de Excel. Para cada uma: quem mantém, de onde vêm os dados, quem consome, o que aconteceria se ela sumisse. Algumas o ERP novo substitui com o padrão. Outras revelam uma regra de negócio que ninguém documentou.

Controles manuais

Conferência feita a olho porque "o sistema às vezes calcula errado". Dupla checagem antes de pagar. Caderno de protocolo. Cada controle manual responde a um risco que alguém já viveu. O projeto precisa decidir, caso a caso, se o sistema novo elimina o risco, se o controle migra para dentro do sistema ou se continua manual.

Integrações informais

Exportar um relatório, ajustar no Excel e importar em outro sistema é uma integração. Copiar dados de um portal de cliente para o pedido também. Quem faz isso todos os dias não chama de integração, chama de "lançar". Em um levantamento centrado em TI, essas pontes não aparecem no inventário de interfaces e reaparecem na virada como trabalho que ninguém previu.

Exceções

Para cada processo principal, as variações: por filial, por tipo de cliente, por produto, por regime fiscal. E a frequência de cada uma. Exceção que ocorre em 20% dos casos é processo. Exceção que ocorre duas vezes por ano pode ficar manual, e o fit-gap precisa dessa informação para não customizar o que não compensa.

Relatórios que alguém monta à mão

O relatório gerencial da segunda-feira, o fechamento que junta três extrações, o indicador que a diretoria cobra todo mês. Cada um consome horas e define requisitos de dados: se a informação não estiver estruturada no ERP novo, a montagem manual continua depois do go-live, agora com a frustração de ter um sistema novo.

O que o key user conta × o que o time inteiro conta

Tema O que o key user costuma contar O que aparece quando todo o time é ouvido
Fluxo principal O processo como foi desenhado e como funciona na mesa dele Variações por filial, turno, carteira e tempo de casa
Exceções As mais recentes ou as mais traumáticas A lista completa, com frequência estimada de cada uma
Planilhas e controles As que ele mesmo usa As de cada pessoa, incluindo as que só uma pessoa sabe que existem
Integrações As interfaces oficiais Exportações, redigitação entre sistemas, portais de clientes e fornecedores
Tempo gasto Percepção geral ("o fechamento é pesado") Horas por atividade, por mês, somáveis
Passagem entre áreas A visão de um lado Os dois lados do handoff, e onde eles discordam
Relatórios Os que ele recebe ou apresenta Os que cada pessoa monta, para quem e com que esforço
Resistência à mudança Invisível O que as pessoas temem perder, dito por elas, em tempo de tratar

Como o levantamento por censo alimenta o projeto

A alternativa a ouvir um key user por área sempre foi ouvir todos. E sempre esbarrou no custo: uma consultoria tradicional entrevista de 8 a 12 pessoas em cerca de seis semanas, porque é o que cabe na agenda de um consultor. Em um escopo de cem usuários, não fecha.

O censo de processos por agente de IA resolve o problema de escala. Um agente conduz a entrevista com 100% dos usuários do escopo, por link, sem agendamento, com as conversas em paralelo, cerca de 40 minutos por pessoa. Levanta tarefa, frequência, duração, sistema usado e onde trava. Depois os relatos são consolidados: a mesma tarefa descrita por cinco pessoas vira uma tarefa com cinco confirmações, e nada conta duas vezes. Para até três áreas, o ciclo leva cerca de duas semanas.

Duas características importam em um pré-projeto de ERP. O levantamento não depende do sistema antigo: não precisa de extração, integração nem de hora da TI, que nessa fase já está ocupada com o projeto. E capta justamente o que o sistema antigo não registra.

O resultado alimenta quatro entregas do projeto.

Blueprint. O desenho do processo futuro parte do inventário completo de atividades e variações. A discussão "aderir ao padrão ou customizar" acontece com volume e frequência na mesa.

Lista de gaps. Cada planilha paralela, controle manual e integração informal entra no fit-gap como requisito explícito, no início, quando decidir custa pouco.

Plano de treinamento. Sabendo o que cada pessoa faz hoje, o treinamento é montado por perfil real de atividade, não por módulo. E sabe-se de antemão quem vai ter a rotina mais alterada.

Business case. As horas por atividade, convertidas em reais com premissa de custo por hora declarada, dão a linha de base. Depois do go-live, a mesma medição mostra o que o projeto devolveu.

Exemplo: o tamanho do que fica fora do sistema

Exemplo ilustrativo, com premissas. Escopo de 120 usuários em 6 áreas. Custo por hora carregado de R$ 45.

No formato tradicional, 6 key users participam de 3 workshops de 3 horas cada: 54 horas de conversa, 6 vozes. No censo, 120 pessoas × 40 minutos = 80 horas de conversa, distribuídas e em paralelo, 120 vozes.

Suponha que o censo consolide 45 controles paralelos distintos (planilhas, conferências manuais, redigitações), com média de 6 horas por mês cada um. São 270 horas por mês, 3.240 horas por ano, R$ 145.800 por ano. Na triagem com o parceiro de implantação, suponha que 20 sejam cobertos pelo padrão do ERP novo, 15 se resolvam com parametrização, 7 sejam gaps de verdade e 3 fiquem fora do escopo.

Os números do seu projeto serão outros. O ponto é que os 7 gaps entram no cronograma no mês um, e não no mês nove, e que os R$ 145.800 viram uma linha verificável do business case. O post sobre quanto custa um mapeamento de processos compara a estrutura de custo dos formatos de levantamento.

Migração de versão × troca de ERP: o que muda no levantamento

As duas situações pedem levantamento, com focos diferentes.

Migração de versão ou de plataforma no mesmo fabricante. É o caso de quem sai de uma versão antiga do Protheus, Datasul ou RM para a atual, ou do SAP ECC para o S/4HANA. O risco central é o legado de customizações: programas específicos, pontos de entrada, relatórios, tabelas criadas ao longo de quinze anos. O inventário técnico lista o que existe. Não diz o que ainda é usado, por quem e para quê. O levantamento com os usuários responde isso e permite a decisão mais valiosa de uma migração: o que não levar. Customização sem usuário é custo de migração sem benefício.

Troca de ERP. Muda o fabricante, o modelo de dados e o vocabulário. O risco é de requisito não declarado: tudo o que o sistema antigo fazia de forma tão natural que ninguém lembrou de pedir. Aqui o levantamento precisa ser mais amplo, e a lista de exceções e de integrações informais pesa mais. É também onde a gestão de mudança começa: ouvir cada usuário antes da decisão é diferente de comunicar a decisão depois.

Checklist do pré-projeto de ERP

Antes de fechar escopo, cronograma e orçamento, confirme:

  • Todas as áreas do escopo tiveram 100% dos usuários ouvidos, ou há justificativa explícita para a amostra.
  • Existe inventário de atividades por área com frequência, duração e sistema usado.
  • Planilhas paralelas e controles manuais estão listados, com dono e motivo de existir.
  • Integrações informais (exportar, ajustar, redigitar) estão mapeadas ao lado das interfaces oficiais.
  • Exceções de cada processo principal estão listadas com frequência estimada.
  • Relatórios montados à mão estão identificados, com quem consome.
  • Customizações do sistema atual foram cruzadas com uso real: quem usa, para quê.
  • Handoffs entre áreas foram descritos pelos dois lados.
  • Problemas de processo que independem do sistema foram separados e têm dono.
  • Há linha de base em horas e reais por ano, com premissas declaradas, para o business case.
  • A lista de gaps foi priorizada por volume e impacto, não por quem pediu mais alto.
  • O plano de treinamento parte do perfil real de atividades de cada grupo.

O papel do parceiro de implantação

O parceiro de implantação, seja da rede TOTVS, seja SAP ou de outro fabricante, domina o produto e a metodologia. O que ele não tem como saber é o que acontece na empresa do cliente fora do sistema. E o modelo comercial de um projeto de implantação raramente comporta semanas de entrevistas individuais antes do contrato.

Um levantamento por censo no pré-projeto muda três coisas para o parceiro.

Proposta mais precisa. Com inventário de atividades e lista preliminar de gaps, a estimativa de esforço deixa de carregar uma margem grande para o desconhecido, ou de não carregar e virar prejuízo.

Menos mudança de escopo. O que seria descoberto nos testes integrados está na mesa no blueprint. A conversa difícil sobre customização acontece antes da assinatura, não no meio do projeto.

Consultor funcional no lugar certo. O tempo do consultor sai da coleta de informação e vai para o que só ele faz: desenhar a solução, defender o padrão, decidir o gap.

Onde a UpFlux entra

O Nous Scan é o censo de processos por agente de IA da UpFlux. Em um pré-projeto de ERP, ele entrevista todos os usuários do escopo, consolida as atividades, desenha os handoffs entre áreas e entrega horas e reais por ano por atividade, separando piso (o que pelo menos duas pessoas confirmaram) de teto. A liderança recebe só o consolidado, nunca a entrevista individual, o que ajuda as pessoas a contar sobre a planilha que ninguém deveria saber que existe.

O Nous Scan não substitui o fit-gap nem o consultor funcional. Entrega o insumo que os dois precisam, em cerca de duas semanas para até três áreas, sem tocar no sistema atual. O pilar sobre mapeamento de processos explica o método, e a página de mapeamento de processos com IA mostra a entrega.

Perguntas frequentes

O que é levantamento de processos na implantação de ERP?

É a etapa em que se descobre como a empresa executa suas atividades hoje, para definir os requisitos que o novo sistema precisa atender. Inclui atividades por pessoa, exceções, planilhas paralelas, controles manuais e integrações informais. O resultado alimenta o fit-gap, o blueprint, o treinamento e o business case.

O que é fit-gap em um projeto de ERP?

É a análise que compara cada requisito do negócio com a funcionalidade padrão do sistema. O que o padrão atende é fit. O que não atende é gap, e para cada gap decide-se entre mudar o processo, parametrizar, customizar ou usar outra solução. A análise só é tão boa quanto a lista de requisitos que recebe.

Quando fazer o mapeamento de processos na implantação de ERP?

Antes de fechar escopo e contrato, no pré-projeto. Levantado nessa fase, um requisito entra na proposta e no cronograma. Descoberto nos testes ou depois do go-live, vira mudança de escopo, customização de emergência ou planilha paralela no sistema novo.

Migração de versão do ERP também precisa de levantamento de processos?

Precisa, com foco diferente. Na migração, a pergunta principal é quais customizações, relatórios e rotinas ainda são usados, por quem e para quê. Isso permite não migrar o que perdeu a função, que é onde está a maior economia de esforço em um projeto de atualização.

Quanto tempo leva o levantamento de processos antes do ERP?

Com workshops e entrevistas conduzidas por consultores, costuma levar de semanas a meses e cobre uma amostra de usuários. Com um censo de processos por agente de IA, em que todos são entrevistados em paralelo, o levantamento de até três áreas fica pronto em cerca de duas semanas, sem depender de dados do sistema atual.

Próximo passo

Se há uma implantação ou migração no planejamento do próximo ano, o melhor momento para o levantamento é antes do pedido de proposta. Fale com a gente pelo diagnóstico para definir o escopo do censo, sozinho ou junto com o seu parceiro de implantação.

Onde isto vira operação

Leia também