Um checklist para escolher um sistema ERP

Um ERP é um modelo de como a empresa funciona: como um pedido se torna receita, como uma compra se torna uma conta a pagar, como o estoque se movimenta entre um armazém e uma linha de produção. Antes de convidar qualquer fornecedor, coloque esse modelo no papel. Descreva de dez a quinze cenários de ponta a ponta (da cotação ao recebimento, da compra ao pagamento, do planejamento à produção, da contratação ao desligamento) com as suas próprias palavras, incluindo as exceções que distinguem o seu negócio. Um distribuidor com estoque em consignação, um fabricante com subprodutos e uma empresa de serviços com faturamento por marcos são casos típicos em que um sistema genérico falha sem aviso.

Use esses cenários para conduzir as demonstrações, em vez do roteiro do fornecedor. Peça a cada equipe que mostre o fluxo completo, incluindo as partes difíceis: uma nota de crédito sobre uma fatura parcialmente paga, uma contagem de estoque que não bate com o sistema, um fechamento mensal com uma fatura de fornecedor atrasada. A qualidade das respostas diz mais do que o tamanho da lista de funcionalidades.

A aderência também envolve o escopo da plataforma. Uma plataforma que abrange finanças, vendas, estoque, manufatura, RH e suprimentos em um único modelo de dados poupa trabalho de integração no futuro; um conjunto best-of-breed de ferramentas especializadas dá a cada departamento as telas que ele prefere. Nenhuma das abordagens é errada, mas a escolha deve ser consciente, porque determina quanto de integração ficará sob a responsabilidade da organização.

Nenhum ERP funciona sozinho. Ele troca dados com bancos, lojas de e-commerce, sistemas de ponto de venda, um sistema de armazém ou de produção, um CRM, os serviços do fisco e, muitas vezes, a ferramenta de consolidação da controladora. Desenhe o mapa de integrações antes de fazer a escolha. Para cada conexão, defina se ela é em lote ou em tempo real, qual sistema é o dono dos dados e o que acontece quando o outro lado está indisponível.

Em seguida, examine como cada candidato expõe os seus dados. Uma API REST documentada, com autenticação que a organização consiga governar, webhooks para eventos e importação e exportação em massa que possam ser automatizadas são o mínimo. Se o único caminho até os dados for um consultor do fornecedor escrevendo uma stored procedure, cada mudança futura vira um pedido de compra. Peça para ver a documentação da API e pergunte quais outros clientes já se integraram a ela.

Por fim, decida onde ficará a lógica de integração. Conectores ponto a ponto são rápidos de construir e trabalhosos de manter; uma pequena camada de integração sob responsabilidade da organização exige mais trabalho no início e custa consideravelmente menos a partir do terceiro ano.

Trate a migração como uma frente de trabalho própria, com um responsável próprio. Comece com um inventário de dados: quais dados mestres (clientes, fornecedores, itens, plano de contas, colaboradores) e quais transações em aberto (faturas em aberto, pedidos de compra em aberto, saldos de estoque, cadastros de ativo imobilizado) precisam ser migrados, e até que ponto o histórico precisa ser consultável no novo sistema, em vez de mantido em arquivo.

Saneie os dados antes de carregá-los. Clientes duplicados, itens com três unidades de medida e sem fatores de conversão e fornecedores com cadastro fiscal vencido viram, cada um, um problema de conciliação no fim de semana da entrada em produção. Construa os scripts de carga cedo e execute-os repetidamente sobre uma cópia da produção, conciliando os totais de controle (balancete, aging de contas a receber e a pagar, valorização do estoque) a cada vez. A carga final deve transcorrer sem surpresas, porque já terá sido feita várias vezes.

Defina a abordagem da virada com o financeiro. Começar do zero no início de um período, com saldos de abertura, é mais simples do que migrar o histórico de transações; se o histórico for necessário, defina exatamente quais relatórios precisam ser reproduzidos antes do aceite.

Os sistemas que fracassam no primeiro ano raramente são os que têm as funcionalidades erradas. São aqueles em que as pessoas que os usam todos os dias foram informadas da mudança, em vez de participarem dela. Coloque os donos de processo de finanças, vendas e operações na equipe de seleção, com autoridade real. Deixe que conduzam as demonstrações dos cenários e que aprovem os processos futuros junto com o diretor de TI.

Planeje o treinamento por função e por cenário, perto da entrada em produção, com os dados que as pessoas verão em produção. Identifique os usuários-chave de cada departamento antes do início do treinamento e dê a eles tempo no sandbox. Mantenha o sistema antigo em modo somente leitura por um período após a virada, para que as pessoas possam conferir números, e depois desligue-o em uma data anunciada com antecedência.

Por fim, evite reconstruir no novo sistema todos os relatórios e telas existentes. Alguns deles existiam porque o sistema antigo não fazia algo que o novo faz nativamente. Dê aos novos processos um trimestre antes de decidir o que realmente está faltando.