Leonardo Peron6 min de leitura
Numa empresa média, transformação digital quer dizer uma coisa concreta: o dado que hoje uma pessoa copia de um sistema para outro passa a chegar sozinho, e a decisão que hoje espera um relatório montado à mão passa a ter o número na hora. O resto é nome de projeto.
Vale começar por aí porque o termo virou etiqueta para qualquer coisa: troca de ERP, aplicativo novo, painel na televisão da sala, curso de ferramenta. Nenhuma dessas é errada. O problema é que, sem descrever o que muda na rotina de quem trabalha, não há como saber se funcionou, e projeto que não tem como falhar também não tem como dar certo.
O que muda de verdade quando funcionou
Dá para verificar pela rotina, sem olhar para a tecnologia.
O dado é digitado uma vez, na origem. O pedido que o representante fecha não é redigitado no escritório à noite. A nota do fornecedor não é lançada à mão.
A passagem entre áreas deixa rastro. Quando o comercial entrega um pedido para a expedição, fica registrado quem recebeu, quando e o que falta, sem depender de mensagem no grupo.
O gestor vê o estado sem perguntar. Quantos pedidos estão parados, em qual etapa, há quanto tempo. Se para saber isso alguém pergunta a três pessoas, nada mudou.
A regra sai da cabeça e da fórmula. Desconto por faixa, prazo por região, aprovação por valor: estão no sistema, com versão, e mudar uma delas não depende de uma pessoa específica.
O cliente faz sozinho o que hoje pede por telefone. Segunda via, status de entrega, histórico de compra. Cada ligação dessas é um atendimento que não precisava existir.
Se nada disso mudou, a empresa trocou de ferramenta. Pode ter valido a pena, mas não foi transformação.
Há uma mudança que quase não aparece e decide o resto: quem é dono da regra. Quando o processo vai para o sistema, alguém da área de negócio precisa decidir como ele funciona e responder por isso. Se a decisão fica com quem configura, a regra passa a ser a que era mais fácil de configurar. Decidir dono, entrada e registro de cada processo vem antes de qualquer projeto.
Por que o projeto de dois anos falha
O formato clássico é conhecido: meses de levantamento, um documento de requisitos, a construção ou implantação de tudo, uma virada grande no fim. Ele falha por desenho, não por execução.
O requisito é escrito antes de alguém usar qualquer coisa. Sai de reunião, e o processo contado em reunião não é o executado. A diferença aparece na virada, quando corrigir custa mais.
O valor só chega no fim. Durante um ano e meio a empresa paga e não usa nada. Se o patrocinador muda de cargo ou o orçamento aperta no meio, sobra custo sem entrega, porque não existe pedaço intermediário que funcione sozinho.
A empresa muda no meio. Abre filial, entra num canal novo, compra outra operação. O documento do primeiro mês descreve uma empresa que já não existe quando o sistema fica pronto.
Tudo vira de uma vez. Fiscal, estoque, financeiro e comercial em risco no mesmo fim de semana. Qualquer defeito atinge todos, e o time volta para a planilha "só por enquanto".
Quem sabe o processo não tem tempo. As pessoas que conhecem a operação são as que estão operando. Num projeto longo, elas participam do começo e somem no meio, e o requisito passa a ser decidido por quem não executa.
Trocar o ERP inteiro às vezes é inevitável, e o critério para reconhecer quando está na comparação entre integrar ou trocar o ERP. Mesmo nesse caso, o desenho que funciona entrega por partes.
Comece por um processo que dói
O ponto de partida não é o maior processo nem o mais visível. É um que atende quatro condições.
Dói de um jeito que dá para medir. Horas de redigitação, pedido com erro, prazo estourado, venda perdida por demora. Três pessoas redigitando pedidos uma hora por dia, em vinte e um dias úteis, somam cerca de sessenta horas por mês. Esse número, medido antes, é o que vai dizer se funcionou.
Começa e termina. Um processo inteiro, de ponta a ponta, e não uma etapa solta. Pedido que entra no sistema novo e continua sendo faturado à mão cria dois lugares para conferir, o que é pior que antes.
Tem dono disponível. Alguém da operação que consiga dedicar algumas horas por semana para decidir o que o sistema faz.
Cabe em semanas. No nosso método, a primeira entrega vai para produção entre três e seis semanas, com gente de verdade usando. Não é demonstração: é o processo rodando, com o número de antes ao lado para comparar.
O próximo processo é escolhido com o que o primeiro ensinou. O plano de longo prazo vira uma lista de candidatos reordenada a cada entrega, e não um cronograma de dois anos. Se a empresa parar no terceiro processo, os três primeiros continuam funcionando.
O papel da integração
Boa parte do que uma empresa média chama de transformação é, na prática, integração. Os sistemas já estão lá: ERP, loja virtual, CRM, banco, WhatsApp, marketplace. O que falta é que eles conversem, e quem faz essa conversa hoje é uma pessoa copiando.
Integrar costuma entregar mais cedo que trocar. Tira a redigitação sem mexer no que funciona e mantém o sistema que o time já sabe usar. E prepara o terreno: quando uma troca vier, os fluxos de dado já estão mapeados, com o dono de cada informação decidido. O que uma integração é, e o que ela não é, tem texto próprio.
O papel da migração de dados
Quando um processo muda de sistema, o dado vai junto, e é aqui que o projeto costuma perder a confiança do time. Na primeira semana o sistema novo mostra um saldo diferente do antigo, ninguém sabe qual está certo, e a planilha volta a ser aberta "só para conferir". Depois disso ela não fecha mais.
Migrar por processo reduz o risco na mesma proporção em que reduz o volume: um conjunto menor de dados, conferido contra a origem antes da virada. A conferência tem método, e ele está em como provar que a migração não perdeu nada.
Quando não é projeto para contratar
Se o processo é padrão de mercado e existe ferramenta pronta que resolve (assinatura eletrônica, emissão de nota, agenda), compre a ferramenta. Não precisa de fornecedor de software, precisa de alguém que configure e treine.
Se ninguém da operação pode dedicar tempo para decidir, adie. Projeto sem dono do lado do negócio atrasa por motivo que nenhum time técnico resolve.
E se o problema é um combinado entre duas áreas que nunca foi feito, sistema nenhum resolve. Faça o combinado primeiro.
Por onde começar na segunda-feira
Liste cada ponto em que alguém copia dado de um lugar para outro: do e-mail para o ERP, do WhatsApp para a planilha, do extrato para o financeiro. Ao lado de cada um, anote quantas pessoas fazem isso e quanto tempo gastam por dia. A calculadora de custo do trabalho manual transforma essas horas num número anual.
O primeiro projeto é o ponto com mais horas que começa e termina dentro de um processo só. Muitas vezes ele não pede sistema novo, e sim uma integração entre os sistemas que já existem.