“Esse sistema não funciona.”
A frase é relativamente comum. O sistema é lento, complicado, exige etapas demais, não entrega o relatório esperado, não conversa com outras áreas ou simplesmente “não atende a empresa”.
E pode ser verdade. Mas às vezes não, na verdade, eu diria que é mais fácil culpar o sistema sempre.
Existem sistemas ruins, mal projetados, mal implantados e inadequados para aquilo que deveriam fazer. Mas, antes de colocar a culpa na tecnologia, talvez exista uma pergunta um pouco mais incômoda:
O processo que o sistema deveria executar está realmente definido?
Porque uma coisa é um software não conseguir atender um processo claro. Outra, bem diferente, é esperar que ele organize algo que a própria empresa ainda não conseguiu definir.
Como deveria funcionar?
Parece uma pergunta simples.
Imagine que uma empresa decida substituir seu sistema comercial. Durante o levantamento, alguém pergunta como uma oportunidade deve avançar até se transformar em venda.
A resposta começa bem:
“O vendedor cadastra o cliente e envia a proposta.”
E depois?
“Depende.”
Depende do valor. Depende do cliente. Depende de quem vendeu. Às vezes precisa de aprovação. Em alguns casos não precisa. Determinado vendedor fala diretamente com o financeiro. Outro manda mensagem para o gerente. Existe desconto máximo, mas algumas pessoas podem ultrapassá-lo. Ninguém sabe exatamente em quais situações.
E quando a proposta é recusada?
“Normalmente o vendedor acompanha.”
Normalmente?
Perceba que ainda nem começamos a discutir software.
Se entradas, atividades, responsabilidades, decisões, exceções e resultados não estão minimamente claros, qualquer sistema terá dificuldade para representar aquele fluxo. Não porque necessariamente seja ruim, mas porque estamos pedindo à tecnologia uma resposta que a própria organização ainda não possui.
O sistema está criando burocracia?
Pode estar.
Mas também pode estar apenas tornando visível uma complexidade que antes ficava escondida.
Quando uma atividade acontece informalmente, várias decisões podem existir apenas na cabeça das pessoas. Um colaborador sabe que determinado cliente precisa de aprovação especial. Outro sabe que acima de certo valor deve consultar o gestor. Alguém conhece a exceção que nunca foi documentada.
Enquanto todos se lembram, funciona.
Quando o sistema exige que essas regras sejam configuradas, surge o desconforto:
“Por que precisa de tanta coisa?”
Talvez porque a regra sempre tenha existido. Só nunca havia sido explicitada.
É claro que o contrário também acontece. Sistemas podem introduzir etapas inúteis, exigir informações sem finalidade e criar burocracia onde ela não existia. O ponto é justamente não assumir a resposta antes do diagnóstico.
Trocar o sistema resolve?
Às vezes, sim. Às vezes, não!
Em certa ocasião, fui contratado por uma instituição, onde ficou bem claro que a minha missão seria trocar o sistema. A fala exata do dono da empresa foi: “Estou te contratando e a primeira coisa que vai fazer será trocar este sistema que não nos atende.”
Mas trocar o sistema sem entender o processo pode produzir uma situação curiosa: uma empresa investe em uma nova plataforma, migra dados, treina pessoas, integra ferramentas e, alguns meses depois, começa a reproduzir exatamente os mesmos controles paralelos e improvisos que existiam antes.
O sistema mudou.
O problema permaneceu.
E então surge a conclusão de que a nova ferramenta também “não atende”.
Talvez realmente não atenda. Mas, se dois ou três sistemas diferentes tropeçam sempre no mesmo ponto, vale investigar se estamos diante de uma limitação tecnológica ou de uma indefinição operacional.
Quem decide o quê?
Essa pergunta costuma revelar bastante coisa.
Quem pode aprovar?
Qual é o critério?
Quem recebe a atividade seguinte?
O que acontece quando falta informação?
Quais situações fogem do fluxo normal?
Como sabemos que a etapa terminou?
Qual resultado precisa ser produzido?
Não é necessário transformar toda atividade em um manual gigantesco. Processo definido não significa burocracia documental.
Significa existir clareza suficiente para que a operação não dependa de interpretações diferentes a cada execução.
E aqui existe uma diferença importante: desenhar um processo não é simplesmente desenhar um fluxograma.
O fluxograma pode representar o processo. Mas o processo envolve regras, responsabilidades, informações, critérios, exceções e resultados.
Um desenho bonito com caixas e setas não resolve isso sozinho.
O sistema deveria se adaptar à empresa?
Sim. Até certo ponto.
Uma boa solução tecnológica precisa considerar a realidade da organização. Obrigar uma empresa a abandonar práticas eficientes apenas para obedecer à lógica de uma ferramenta pode ser uma péssima decisão.
Mas existe um limite.
Customizar um sistema para reproduzir toda exceção, todo improviso e toda forma histórica de trabalhar pode transformar tecnologia nova em uma versão digital dos mesmos problemas antigos.
A pergunta, portanto, não deveria ser apenas:
“Como fazemos isso hoje?”
Também precisamos perguntar:
“Por que fazemos assim?”
Talvez exista uma boa razão.
Talvez ninguém saiba.
E essa diferença pode alterar completamente o projeto.
Antes de escolher a ferramenta
Existe uma tentação natural de começar pela solução.
Qual ERP comprar? Qual CRM implantar? Qual plataforma contratar? Qual automação desenvolver?
São perguntas importantes, mas talvez estejam chegando cedo demais.
Antes delas, vale compreender ao menos:
- qual problema precisa ser resolvido;
- como o trabalho acontece hoje;
- quais informações entram e quais resultados precisam sair;
- quem é responsável por cada decisão;
- quais regras realmente precisam existir;
- quais exceções são legítimas;
- quais etapas não agregam valor;
- e como saberemos se o novo processo funciona melhor.
Com isso minimamente compreendido, a tecnologia começa a ocupar o lugar correto: habilitar, organizar, integrar, automatizar e dar escala a uma operação que possui lógica compreensível.
E se o sistema for realmente ruim?
Troque! Acredite, existem muitos sistemas realmente ruins
Não existe mérito algum em manter uma ferramenta inadequada apenas porque processos também precisam ser revistos.
Mas faça isso sabendo exatamente o que o novo sistema deverá resolver.
Caso contrário, existe o risco de conduzir uma implantação cara para descobrir, meses depois, que o software mudou e a dificuldade continua exatamente no mesmo lugar.
Quando um sistema parece não funcionar, o diagnóstico não deveria começar tentando defendê-lo.
Também não deveria começar condenando-o.
Talvez a melhor primeira pergunta seja mais simples:
O que exatamente deveria estar funcionando aqui?
A resposta ajuda a separar problema de tecnologia, problema de implantação e problema de processo.
E pode evitar que a empresa compre uma nova ferramenta para informatizar uma indefinição antiga.
Antes de substituir tecnologia, vale entender o problema que ela deveria resolver. A FLEURISILVA atua na análise de processos, tecnologia e gestão para apoiar decisões mais bem fundamentadas. www.fleurisilva.com.br
