Vendas
Última Atualização:
Paulo Faustino
Convém arrumar o vocabulário antes de discutir sequência, porque as fronteiras entre categorias esbateram-se e os fornecedores têm interesse em que se esbatam ainda mais.
Um ERP é a espinha dorsal transacional. Regista o que a empresa compra, produz, movimenta, vende, fatura e paga. A sua função é garantir que cada acontecimento económico é registado uma vez, de forma consistente, e fica disponível para quem precisa dele. É o sistema onde vive a verdade sobre o que aconteceu.
Um CRM é a memória da relação comercial. Regista quem são os clientes e potenciais clientes, o que se falou com eles, em que fase estão, o que foi proposto e o que se seguiu. A sua função é evitar que o conhecimento sobre o mercado viva na cabeça e no telemóvel de cada vendedor.
Um BI é uma camada de leitura. Não regista nada de novo: pega em dados que já existem noutros sistemas, combina-os e apresenta-os de forma que permita decidir. A sua função é transformar registo em informação.
Desta arrumação decorre imediatamente uma consequência que resolve metade da questão da sequência: o BI não produz dados, consome-os. Uma empresa que instala um sistema de análise antes de ter registo fiável vai obter gráficos bonitos construídos sobre informação que ninguém garante. É a categoria mais fácil de vender e a mais fácil de desperdiçar.
O que a investigação diz sobre a ordem, e é menos do que se esperaria
Não existe um estudo que diga "implemente A antes de B". O que existe é evidência sobre o que faz estes projetos correrem bem ou mal, e essa evidência aponta consistentemente para uma conclusão que muda a forma de pensar a sequência. Convém dizer desde já que os trabalhos de referência nesta matéria têm mais de duas décadas, o que num tema de tecnologia obriga a uma ressalva: o que mudou desde então foi o custo de entrada, o modelo de subscrição e a fronteira entre categorias. O que não mudou, e é o que sustenta este artigo, foram os determinantes organizacionais do sucesso destes projetos.
Um trabalho empírico com respostas de 86 organizações que tinham concluído ou estavam a concluir uma implementação de ERP avaliou a importância de 22 fatores críticos de sucesso. O resultado, ordenado por importância média numa escala até 5, coloca no topo o apoio da gestão de topo, com 4,29, seguido da competência da equipa de projeto, com 4,20, e da cooperação interdepartamental, com 4,19.
O que aparece no fundo da tabela é ainda mais revelador. A utilização das ferramentas do fornecedor ficou em 21.º lugar, com 3,15, e a utilização de consultores em último, com 2,90. Entre ambos os extremos, e abaixo de tudo o que é organizacional, ficaram a customização mínima e a gestão da mudança.
A leitura é inequívoca: os fatores que decidem estes projetos são organizacionais, não técnicos. Objetivos claros, comunicação entre departamentos, gestão de expectativas e alguém com autoridade a acompanhar valem mais do que a escolha do produto, e valem muito mais do que quem o instala.
Os autores acrescentam uma advertência que merece ser citada: a responsabilidade por aspetos-chave do projeto não deve ser delegada a fornecedores de software ou consultores, que devem ser vistos como recursos auxiliares e não como condutores.
Há uma segunda linha de evidência, do lado do CRM, que é ainda mais dura e menos conhecida.
Um estudo publicado no Journal of Marketing Research construiu uma medida do grau de implementação de processos de gestão de clientes em 3 fases, iniciação, manutenção e terminação, e testou a sua associação com desempenho económico. A amostra teve 211 respostas usáveis em 4 setores e 3 países, com validação cruzada numa segunda amostra e com medida objetiva de rendibilidade dos ativos para 98 empresas.
O resultado principal confirmou o esperado: quanto mais implementados os processos, melhor o desempenho, com o efeito mais forte na fase de manutenção da relação. Mas o resultado que interessa a quem está a decidir sobre software é outro.
O efeito principal da tecnologia de CRM sobre o desempenho foi negativo e estatisticamente significativo, e replicou-se na amostra de validação. E o efeito moderador da tecnologia na fase de iniciação da relação foi igualmente negativo.
Os autores são explícitos na conclusão: implementar com sucesso um programa de gestão de clientes exige mais do que apenas tecnologia, e se as empresas se concentrarem apenas nesse aspeto, os seus esforços serão provavelmente dececionantes. Acrescentam que instalar simplesmente tecnologia ou software não é suficiente, e que os colaboradores têm de ser recompensados por se envolverem nestas atividades.
O mesmo trabalho regista, citando investigação de mercado da época, que cerca de 70% dos projetos de gestão de clientes resultavam em perdas ou em nenhuma melhoria de resultados.
Aqui está a distinção que resolve a pergunta do título: o problema quase nunca é qual sistema, é se existe processo por baixo dele. Um sistema instalado sobre um processo inexistente não cria o processo. Torna visível que ele não existe, e cria trabalho administrativo adicional para quem já não estava a fazer o que devia.
Isto não é argumento para adiar sistemas até os processos estarem perfeitos, o que nunca acontece. É argumento para uma sequência específica dentro de cada projeto: primeiro descrever como o trabalho é feito hoje e como deveria ser feito, depois escolher a ferramenta que suporta essa descrição. A ordem inversa, que consiste em comprar primeiro e descobrir o processo durante a configuração, é a que produz sistemas configurados por quem menos conhece o negócio.
O que os dados dizem sobre valer a pena
Antes de discutir sequência, uma nota sobre se estes investimentos compensam, porque a evidência aqui é mais subtil do que os fornecedores sugerem.
Um estudo longitudinal comparou 63 empresas que adotaram ERP com pares que não adotaram, ao longo de 3 anos. Os adotantes apresentaram rendibilidade dos ativos, rendibilidade do investimento e rotação do ativo significativamente melhores, mas os autores sublinham a razão: a diferença surgiu sobretudo porque o desempenho dos não adotantes decresceu ao longo do tempo, enquanto o dos adotantes se manteve estável.
Traduzindo: o ERP não fez as empresas ganharem mais. Impediu-as de perderem terreno.
Esta distinção tem consequências práticas na forma como se justifica o investimento internamente. Apresentar um projeto destes como gerador de crescimento cria expectativas que a evidência não sustenta e prepara o terreno para a desilusão de quem espera ver a faturação subir. Apresentá-lo como condição para continuar a competir é mais honesto e mais defensável, e alinha as expectativas com aquilo que o sistema efetivamente entrega: capacidade de operar com o mesmo rigor a um volume maior.
E há um segundo achado com implicações diretas para empresas pequenas. Os autores encontraram uma interação significativa entre dimensão e saúde financeira, com relação positiva para as empresas pequenas e negativa para as grandes.
A leitura prudente é esta: para uma empresa pequena e financeiramente saudável, este tipo de investimento tende a compensar, e é isso que os dados mostram. O que os dados não cobrem, e por isso fica como juízo e não como achado, é o caso da empresa pequena em dificuldades, onde o mesmo investimento compete com utilizações mais urgentes do mesmo dinheiro. Em qualquer dos casos, a ordem certa de perguntas começa na tesouraria e não no catálogo de funcionalidades.
Com isto arrumado, é possível construir uma regra de decisão que não depende do que dói mais hoje.
Primeiro: o sistema que regista o dinheiro. Se a empresa não consegue dizer, com fiabilidade e sem cruzar folhas de cálculo, quanto faturou, quanto comprou, quanto tem em stock e quanto lhe devem, esse é o primeiro problema. Sem isto, não há informação de gestão nenhuma que se sustente, e qualquer camada analítica construída por cima vai reproduzir os erros com melhor apresentação.
Segundo: o sistema que regista o mercado. Uma vez garantido o registo transacional, o próximo ativo em risco é o conhecimento comercial, precisamente porque vive fora dos sistemas e sai pela porta quando alguém sai.
Terceiro: a camada de leitura. Quando existem dados fiáveis em pelo menos uma das 2 fontes anteriores, faz sentido investir em transformá-los em decisão.
Esta ordem tem exceções, e é importante nomeá-las em vez de as tratar como desvios:
Se o negócio é de serviços puros, com poucas transações e ciclos longos, o registo transacional é trivial e o valor está quase todo na relação comercial. Aqui o CRM vem primeiro, sem discussão.
Se a empresa já tem contabilidade e faturação a funcionar bem através de soluções específicas que resolvem o essencial, um ERP completo pode ser prematuro, e o esforço rende mais no lado comercial.
Se existe uma decisão de investimento pesada iminente e a informação necessária existe mas está dispersa, um exercício analítico pontual pode preceder tudo o resto, desde que se aceite que é um exercício e não um sistema.
Se o problema é de execução operacional repetitiva e não de falta de informação, provavelmente nenhuma das 3 siglas é a resposta, e o que faz falta é automatização de tarefas concretas.
Vale a pena consultar, antes de decidir, o enquadramento sobre o que faz e não faz um ERP e sobre o âmbito real de um CRM, porque muita da confusão sobre sequência resulta de expectativas erradas quanto ao que cada categoria cobre.
O que muda quando a empresa já tem alguma coisa
A discussão até aqui pressupõe uma folha em branco, o que raramente é o caso. A maior parte das empresas já tem qualquer coisa: um software de faturação, uma folha de cálculo elaborada que alguém mantém há anos, um sistema herdado que ninguém percebe bem mas que funciona.
Esta situação exige uma pergunta anterior a todas as outras: o que existe é insuficiente ou é apenas antigo?
São problemas diferentes com respostas diferentes. Um sistema insuficiente não regista o que a empresa precisa de saber, e substituí-lo é inevitável. Um sistema antigo regista o que interessa mas de forma incómoda, e substituí-lo é uma decisão de conforto que compete com outras utilizações do mesmo dinheiro.
Os sinais que distinguem ambos os casos:
É insuficiente quando existem processos inteiros a decorrer fora do sistema, quando os números têm de ser corrigidos manualmente antes de servirem para alguma coisa, ou quando a informação de que precisas simplesmente não é registada em lado nenhum.
É apenas antigo quando os dados estão lá e corretos, mas obtê-los exige exportações, cruzamentos e tempo de alguém.
No segundo caso, a resposta frequentemente não é substituir. É acrescentar uma camada de leitura por cima do que já existe, aproveitando o investimento feito e resolvendo o problema real, que é de acesso e não de registo.
Há ainda uma armadilha específica das folhas de cálculo que convém nomear, porque é uma das causas mais comuns de projetos precipitados. Uma folha bem construída por alguém competente pode funcionar muito bem durante anos. O risco não é de funcionalidade, é de dependência: se essa pessoa sair, ninguém consegue manter nem corrigir o que ela construiu. A urgência de substituir uma folha de cálculo raramente vem das suas limitações técnicas. Vem de a empresa perceber que depende de uma pessoa para saber quanto vale.
Existe um exercício que resolve a questão em menos de uma hora e que evita meses de avaliação de fornecedores.
Escreve as 10 perguntas a que precisas de conseguir responder para gerir a empresa. Não perguntas genéricas: perguntas que tomarias uma decisão a partir da resposta. Por exemplo:
Qual foi a margem por linha de produto no último trimestre?
Quanto tempo passa entre uma encomenda e a sua expedição?
Que percentagem das propostas enviadas fecha, e em quanto tempo?
Quanto vale o stock parado há mais de 6 meses?
Qual é o custo de servir os 20 maiores clientes?
Depois, para cada pergunta, responde a 3 coisas: os dados existem em algum lado, em que formato estão, e quanto tempo demora hoje a obter a resposta.
O padrão que emerge deste exercício é quase sempre revelador:
Se a maioria dos dados não existe, precisas de um sistema que os registe, e a discussão sobre análise é prematura.
Se os dados existem mas estão dispersos e demoram dias a juntar, o problema é de integração e leitura, e é aí que o retorno é mais rápido.
Se os dados existem, estão juntos e continuas sem responder, o problema não é de sistemas. É de método de gestão, e nenhum software o resolve.
Este último caso é mais comum do que parece, e é o que produz mais frustração. Uma empresa com sistemas decentes que não consegue responder a perguntas simples raramente tem um problema tecnológico. Tem um problema de ninguém ter definido que perguntas importam, o que é matéria de desenho de um painel de gestão e não de escolha de fornecedor.
Vale a pena aplicar um segundo filtro às 10 perguntas, porque nem todas merecem investimento. Para cada uma, pergunta o que farias diferente se tivesses a resposta hoje. Se não consegues nomear uma ação concreta, a pergunta é curiosidade e não necessidade de gestão, e não deve entrar nos requisitos.
Este filtro elimina, tipicamente, metade da lista inicial. E a lista que sobra tem uma propriedade útil: como cada pergunta está ligada a uma decisão, é possível estimar o valor de a responder. Uma pergunta cuja resposta permite poupar alguns milhares de euros por ano justifica investimento; uma que produz um gráfico interessante para a reunião mensal não justifica.
O exercício tem ainda um efeito colateral que compensa por si só. Ao escrever as perguntas e verificar onde estão os dados, descobre-se frequentemente que parte da informação necessária já existe e simplesmente ninguém a pediu. Nesses casos, a solução imediata não custa nada.
O custo que ninguém orçamenta, e é o maior
Passemos à parte que decide se o projeto correrá bem, e que raramente aparece nas propostas.
O custo visível é a licença e a implementação. O custo real inclui várias linhas que ficam por conta da empresa.
O tempo interno, que é o maior de todos. Alguém tem de definir requisitos, validar configurações, testar, corrigir e formar. Essas pessoas continuam a ter o trabalho normal.
A limpeza e conversão de dados, que é o item mais subestimado. Dados de clientes duplicados, artigos com códigos inconsistentes, saldos que nunca fecharam: tudo isto tem de ser resolvido antes, e o esforço não é técnico, é de decisão sobre o que é verdade.
A curva de aprendizagem, que existe e é longa. O estudo dos fatores críticos regista que os projetos desta natureza apresentam uma curva de aprendizagem de cerca de 6 meses no início.
A queda temporária de produtividade durante e depois do arranque, que é normal e deve ser planeada, não descoberta.
A manutenção e a evolução, porque nenhum destes sistemas fica pronto.
Sobre o primeiro ponto, há uma regra empírica que vale a pena adotar: se ninguém dentro da empresa tem tempo para o projeto, o projeto vai falhar independentemente do orçamento. Não é uma questão de dinheiro, é de disponibilidade da única coisa que não se compra.
Uma forma prática de dimensionar isto antes de decidir: estimar quantas horas por semana, e durante quantas semanas, cada pessoa envolvida vai ter de dedicar ao projeto. Multiplicar pelo custo horário dessas pessoas produz um número que costuma ser da mesma ordem de grandeza do orçamento do fornecedor, por vezes superior. Quem apresenta esse número à gestão antes de arrancar evita a conversa desagradável de o descobrir a meio.
E há uma decisão que decorre daqui e que muitas empresas evitam: se as pessoas certas não têm tempo, ou se liberta tempo delas retirando-lhes outras responsabilidades durante o projeto, ou se adia. A terceira opção, que é pedir-lhes que façam ambas, produz um projeto mal feito e uma operação mal gerida em simultâneo.
A decisão que mais divide projetos: customizar ou adaptar
Este ponto tem dados concretos e uma resposta bastante clara.
Perante a diferença entre como a empresa trabalha e como o sistema espera que trabalhe, existem 3 caminhos: mudar a empresa, escolher um sistema que se aproxime mais, ou mudar o sistema.
O estudo dos fatores críticos cita um inquérito a grandes empresas sobre políticas de customização com uma distribuição instrutiva: 41% reengenham o negócio para caber na aplicação, 37% escolhem aplicações que se ajustam ao negócio e customizam um pouco, e apenas 5% customizam a aplicação para caber no negócio.
As razões pelas quais a customização pesada é evitada são conhecidas e acumulam-se ao longo do tempo:
Custos de sistemas de informação mais elevados, no imediato e permanentemente.
Prazos de implementação mais longos.
Incapacidade de beneficiar da manutenção e das atualizações do fornecedor, que é o custo que só aparece anos depois.
A regra que daqui resulta é que se deve customizar apenas quando a forma não padronizada de trabalhar constitui vantagem competitiva demonstrável. E "sempre fizemos assim" não é vantagem competitiva, é hábito.
Isto obriga a uma decisão que é de gestão e não de informática: mudar processos para caber no sistema significa mudar como as pessoas trabalham, e essa é a parte difícil. Quem trata essa mudança como consequência técnica em vez de projeto próprio produz sistemas que ninguém usa como devia.
Quando a conclusão é que existe mesmo uma parte do processo que não cabe no que o mercado vende, e que essa parte é onde reside a vantagem competitiva, a resposta deixa de ser escolher entre pacotes e passa a ser construir.
É esse o terreno da Sales Consulting, que trabalha tanto a implementação de CRM como o desenvolvimento de software à medida, e que faz a distinção que interessa aqui: começar pelo desenho do processo e só depois decidir o que se configura, o que se integra e o que se constrói de raiz. A escolha entre adaptar e customizar deixa de ser uma discussão sobre funcionalidades e passa a ser uma decisão sobre onde a empresa quer mesmo ser diferente.
Como escolher fornecedor sem ser escolhido por ele
Assumindo que a sequência está decidida, resta a escolha concreta, e há um conjunto de práticas que reduzem substancialmente o risco.
Começa por descrever o teu processo, não por pedir demonstrações. Uma demonstração genérica mostra sempre o produto no seu melhor, resolvendo problemas que talvez não sejam os teus. Pedir que o fornecedor demonstre a resolução de 3 ou 4 situações concretas da tua empresa, descritas por escrito com antecedência, muda completamente o valor informativo da reunião.
Envolve quem vai usar, e cedo. Quem tomou a decisão não é quem vai passar 8 horas por dia no sistema. A evidência sobre cooperação e comunicação entre departamentos como fator crítico não é abstrata: traduz-se em ter pessoas de cada área na avaliação e não apenas na formação.
Pede referências de clientes semelhantes em dimensão e setor, e fala com pelo menos um que tenha implementado há mais de 2 anos. As referências recentes falam do processo de venda; as antigas falam do que é viver com o sistema.
Verifica a portabilidade dos teus dados antes de assinar. A pergunta é simples: se decidir mudar daqui a 4 anos, como saio e em que formato? Um fornecedor que hesita nesta resposta está a dizer alguma coisa importante.
Separa o preço de entrada do custo total de 5 anos, incluindo licenças, manutenção, alterações previsíveis e o custo de acrescentar utilizadores à medida que a empresa cresce. Propostas com entrada barata e custo crescente por utilizador são comuns e legítimas, desde que a conta seja feita.
Desconfia de âmbitos que crescem durante a negociação. Se cada conversa acrescenta módulos, o projeto vai crescer também depois de assinado, e o crescimento de âmbito é a causa clássica de derrapagem de prazo e custo.
Uma nota final sobre consultores, dado que a evidência os coloca em último lugar entre os fatores críticos. Isso não significa que não sejam úteis. Significa que são um recurso auxiliar e que a empresa deve manter o controlo e assumir a responsabilidade por todas as fases do projeto. Contratar competência externa para suprir uma falta pontual é sensato; contratá-la para não ter de decidir é o que a evidência desaconselha.
Convém acrescentar um alerta que o próprio estudo regista sobre esta matéria: uma preocupação recorrente com consultores decorre de ligações financeiras ao fornecedor de software recomendado. Perguntar diretamente se existe relação comercial entre quem aconselha e quem vende é uma pergunta legítima, e a reação a ela é informativa por si só.
Porque é que estes projetos falham, e não é por causa do software
O estudo dos fatores críticos regista uma estimativa que enquadra bem o problema: metade das implementações falha em atingir os benefícios esperados porque as empresas subestimam significativamente o esforço envolvido na gestão da mudança.
Vale a pena decompor essa afirmação, porque a expressão gestão da mudança soa vaga e o que ela significa é bastante concreto: convencer pessoas que trabalham de uma forma há anos a trabalharem de outra, sem que ninguém lhes tenha perguntado se queriam, e mantendo o desempenho durante a transição. Descrito assim, deixa de surpreender que seja a parte mais difícil.
Os padrões de falha que se repetem são reconhecíveis e todos organizacionais:
Objetivos difusos. "Modernizar a gestão" não é objetivo. "Fechar o mês em 5 dias úteis em vez de 20" é.
Ausência de dono interno com autoridade. Se o projeto pertence a quem não pode decidir, cada bloqueio espera semanas por uma reunião.
Delegação total no fornecedor. É a tentação mais forte e a que a evidência desaconselha mais claramente.
Formação tratada como evento. Uma sessão antes do arranque não substitui acompanhamento nas semanas seguintes, que é quando as dúvidas reais aparecem.
Manutenção do sistema antigo em paralelo. Enquanto a folha de cálculo continuar a funcionar, metade da equipa vai continuar a usá-la, e os dados no sistema novo nunca ficam completos.
Este último merece ênfase porque é o mais fácil de evitar e o mais frequentemente ignorado. Um sistema com dados parciais é pior do que não ter sistema, porque produz relatórios que parecem completos e não são, e ninguém sabe quais das decisões tomadas com base neles estavam erradas.
O que fazer com dados quando o BI ainda não se justifica
Uma nota para quem conclui, corretamente, que a camada analítica ainda não faz sentido.
Não é preciso um sistema dedicado para ter informação de gestão. É preciso definir um conjunto pequeno de indicadores, com origem identificada e periodicidade fixa, e alguém responsável por os produzir. Uma folha de cálculo bem construída, alimentada por exportações regulares dos sistemas existentes, resolve o problema de gestão de muitas empresas durante anos.
Convém ser explícito sobre a dimensão desse conjunto, porque a tentação é o excesso. Entre 8 e 12 indicadores cobrem a gestão corrente da esmagadora maioria das empresas de dimensão média, e a disciplina de os limitar produz mais atenção a cada um do que qualquer painel com 40 gráficos. Um indicador que ninguém olha durante 3 meses seguidos deve sair da lista, e a revisão anual dessa lista é tão importante como a produção mensal dos números.
O que essa solução não resolve é escala e fiabilidade: exportações manuais falham, ficam desatualizadas e dependem de uma pessoa. Quando o esforço mensal de produzir a informação começa a consumir dias em vez de horas, ou quando as decisões dependem de dados que mudam durante o mês, a automatização passa a compensar.
Enquanto isso, o trabalho útil é definir o que se quer medir. Escolher os indicadores financeiros que realmente informam decisões, e articulá-los com o que já se recolhe em contabilidade, produz mais valor de gestão do que qualquer ferramenta comprada antes dessa definição existir.
Há um cuidado a ter com estas soluções intermédias, e é de disciplina e não de ferramenta: definir uma única versão oficial de cada número e o momento em que é produzido. O que estraga a informação de gestão em folhas de cálculo não é a folha, é existirem 3 versões do mesmo indicador em circulação, cada uma calculada de forma ligeiramente diferente, e ninguém saber qual usar numa reunião.
Um plano de 12 meses que não exige apostar tudo
Reduzido a prática, um percurso realista para uma empresa de dimensão média cabe em 4 fases e um ano.
Meses 1 a 2: diagnóstico e decisão. Fazer o exercício das perguntas, mapear onde estão os dados, calcular o custo total incluindo tempo interno, e escolher qual dos 3 problemas é o primeiro. Definir objetivos mensuráveis, com números e prazos.
Meses 3 a 5: preparação. Limpar e normalizar dados, documentar os processos que vão ser afetados, decidir o que muda na empresa e o que se pede ao sistema, e escolher fornecedor com base em ajuste ao processo e não em número de funcionalidades.
Meses 6 a 9: implementação faseada. Arrancar por um âmbito reduzido, com utilizadores reais, e alargar depois. Um arranque completo em simultâneo maximiza risco sem contrapartida.
Meses 10 a 12: consolidação. Desligar os sistemas antigos, medir os objetivos definidos na primeira fase, e só então decidir se avança o segundo sistema.
A parte mais importante deste calendário é a última linha. Implementar 2 sistemas em simultâneo é a forma mais fiável de falhar ambos, porque compete pelas mesmas pessoas, pelo mesmo tempo de gestão e pela mesma paciência da equipa.
Convém dizer o que fazer com a pressão para acelerar, porque ela vai aparecer. A tentação de comprimir este calendário vem quase sempre do fornecedor, que tem interesse legítimo em faturar mais cedo, e de dentro da empresa, onde alguém quer resultados antes do fim do ano. Ceder produz um arranque com dados por limpar e pessoas por formar, e o tempo aparentemente poupado é gasto a corrigir durante os 6 meses seguintes, com o agravante de a equipa ficar convencida de que o sistema não presta.
A única forma legítima de acelerar é reduzir o âmbito, não comprimir as fases. Arrancar com menos módulos, menos utilizadores ou menos processos é uma decisão defensável. Arrancar com o mesmo âmbito em metade do tempo não é.
Para empresas que estão a preparar crescimento, esta sequência encaixa naturalmente no trabalho mais amplo de escalabilidade, onde a questão não é ter sistemas mas ter processos que suportem o dobro do volume sem duplicar a estrutura.
Onde a automatização entra, e não é onde se pensa
Uma última clarificação, porque a conversa sobre sistemas de gestão passou a misturar-se com a conversa sobre automatização e inteligência artificial, e a mistura produz decisões más.
Automatizar tarefas repetitivas e registar transações são coisas diferentes. Automatizar sobre processos que não estão definidos é acelerar o caos, e automatizar sobre dados que não são fiáveis é multiplicar erros a maior velocidade.
A ordem correta continua a ser a mesma: primeiro registo fiável, depois leitura útil, depois automatização do que se repete. Quem inverte esta ordem acaba com automatismos que ninguém confia e que são desligados ao primeiro erro visível.
Há um caso particular que merece nota porque é onde a ordem pode legitimamente inverter-se: tarefas puramente administrativas, sem dependência de dados de gestão, que consomem horas todas as semanas. Transferir informação entre 2 sistemas à mão, produzir o mesmo relatório repetitivo, ou responder a pedidos idênticos são candidatos a automatização imediata, independentemente do estado dos sistemas de gestão. Não produzem informação melhor, mas libertam tempo, e tempo libertado é precisamente o recurso que os projetos maiores vão exigir.
Isto não significa adiar indefinidamente. Significa que as decisões sobre automatização de processos devem incidir sobre tarefas cujo funcionamento manual já se percebe bem, e que a ausência dessa compreensão é o melhor indicador de que ainda não é o momento.
Este tipo de decisão, que combina prioridade de investimento, desenho de processo e capacidade de execução interna, é precisamente o que se trabalha na imersão CHECKMATE: Processos, onde a escolha de sistemas deixa de ser uma comparação de propostas e passa a ser uma consequência do desenho da operação.
Vale ainda registar que esta discussão é uma peça de um trabalho mais amplo de transformação digital, e que a sequência aqui descrita se mantém válida independentemente do grau de ambição desse trabalho.
O erro que atravessa quase todas as decisões erradas nesta matéria é o mesmo: tratar a escolha como uma comparação de produtos quando é uma decisão sobre a ordem pela qual a empresa vai arrumar aquilo que já faz. A evidência disponível é consistente e desconfortável para quem procura uma solução comprável: os fatores que determinam o sucesso destes projetos são o apoio de quem manda, a competência de quem executa e a cooperação entre departamentos, e os fatores técnicos ficam sistematicamente abaixo. A tecnologia sozinha, medida isoladamente, chegou a mostrar associação negativa com o desempenho. Se ficar apenas uma coisa, que seja o exercício das perguntas. Escrever as 10 perguntas cujas respostas mudariam decisões, e verificar se os dados existem, onde estão e quanto tempo demoram a chegar. Quem faz este exercício descobre quase sempre que a resposta à pergunta do título já estava escrita na própria empresa, e que o único trabalho verdadeiramente difícil não era escolher entre siglas: era decidir o que a empresa precisava mesmo de saber sobre si própria, coisa que nenhum fornecedor pode responder e que quase ninguém se senta a fazer antes de pedir orçamentos.
