A expansão do mercado somado à um processo evolutivo de informatização faz com que os serviços de TI sejam cada vez mais robustos e eficazes, neste cenário é que aparecem os ERPs. Basicamente um ERP é uma aplicação voltada a uma finalidade específica como sistemas a gestão de ensino, automação comercial, contábil, etc. ou então aplicações mais genéricas como aplicativos de gestão de caixa, emissão de notas fiscais.
O que não se pode negar é que os ERPs são uma excelente ferramenta para ser ter rodando dentro de uma empresa, logo porque além dele gerenciar parcialmente ou todo o fluxo de dados movimentados na empresa ele também consegue ditar regras e auxiliar na organização dos funcionários de empresa. Um exemplo disto são as regras de fechamento de caixa, balanços mensais, solicitação de descontos extras por intermédio de autenticação de um usuário supervisor, etc.
O custo da implantação de um ERP nunca é barato, logo porque ele impacta em questões de infra-estrutura básica como servidores, rede e terminais operacionais, que no meu ponto de vista este é o menor dos problemas financeiramente falando devido aos inúmeros recursos disponíveis no mercado por preços cada vez mais acessíveis. O segundo e principal item impactante é com os usuários e a organização da empresa.
Quando uma empresa contrata a construção de um ERP voltado especificamente para a sua rotina de trabalho diária não há tantos problemas, mas quando é uma solução já pronta onde a empresa e seus funcionários precisarão alterar a sua forma de trabalhar mesmo que para melhor, sempre há resistência e reclamações. Nesta hora eu me lembro do meu professor de banco de dados falando que quem mata a sua aplicação numa implantação são os próprios funcionários.
E ele estava certo, já participei de algumas implantações, como no caso de uma aplicação WEB de gestão de auto-escolas, durante a fase de implantação pude ver de perto a resistência dos funcionários. Por mais que a aplicação agilizava o seu trabalho de uma hora para menos de trinta minutos era visível que muitos simplesmente não queriam migrar, alguns por estarem esgessados na forma de trabalho antigo e outros porque realmente não se importavam se isto seria bom para eles ou para a própria empresa.
Problemas como estes podem parecer absurdos, mas para consultores que trabalham com ERPs são cotidianos.
Mas quando que começa a surgir a bola de neve que comentei no título deste artigo?
A bola de neve começa a partir que um ERP é aplicado na diversas empresas. Cada empresa possui a sua própria forma de trabalhar, podemos pegar umas 800 empresas de diferentes segmentos e todas irão apresentar uma forma diferente para ligar com as suas contas a receber/pagar, isto é normal…logicamente todos nós pensamos de forma diferente, é da natureza do ser humano. Acredito que agora já fique visível o problema que nos leva a bola de neve, ou o que eu carinhosamente chamo de construção do fim do mundo.
Quando um ERP específico é implantado em diversas empresas, geralmente não há custos com desenvolvimentos de novas funcionalidades, logicamente porque o sistema já está pronto se formos levar em conta um ERP maduro. A cada nova implantação são realizadas análises de aderência, acompanhamentos e treinamentos com a empresa para que a mesma possa usar normalmente o sistema.
As divergências começam a aparecer porque por exemplo a empresa tinha um consultor financeiro que havia desenvolvido uma planilha que calculava a depreciação dos seus equipamentos de uso diário com base nas horas de uso, por mais que este não seja um item ‘comum’ no ramo de negócio do ERP, geralmente a empresa mantenedora do ERP irá vender uma customização para atender este item. O problema é que em alguns casos, diversas destas customizações começam a ficar enroladas e misturadas em lógicas que deveriam seguir um fluxo pré-definido e padronizado. Para esclarecer isso, vamos imaginar a seguinte situação:
O funcionário cadastra um cliente através do sistema, depois acessa a tela de vendas e registra a compra do mesmo, depois vai na tela de finalização de compra e registra o parcelamento ou pagamento do valor da compra.
Uma lógica simples com início e fim bem definidos. Mas agora vamos pensar que na última implantação o cliente apresentou um fluxo diferente baseado em alguma regra interna da empresa:
O funcionário cadastra um cliente através do sistema, depois acessa a tela de vendas e registra a compra do mesmo gerando uma parcela já bonificada referente ao desconto, depois vai na tela de finalização de compra e registra o parcelamento ou pagamento do valor da compra.
E seguindo nas vendas, o sistema é implantado em mais um cliente que necessita de uma modificação neste fluxo:
O funcionário cadastra um cliente através do sistema, depois acessa a tela de vendas e registra a compra do mesmo a partir da liberação de um supervisor de vendas, depois vai na tela de finalização de compra e registra apenas o valor da compra.
São exemplos bobos e meio sem sentido estes que citei, na vida real alguns geram um impacto monstruoso dentro da aplicação. Aqui é que começa a ‘complicação’ disto tudo, mas porque?
Quando se começa a mexer no comportamento e fluxo destas lógicas, dependendo o tamanho da aplicação e da arquitetura desta aplicação, o adjetivo de estável começa a ficar duvidoso. O que eu geralmente costumo presenciar é a alteração das regras de negócio das telas impactarem nos 4504932495 relatórios associados direta ou indiretamente à estas regras.
E assim, bem ‘do nada’ a sua aplicação começa a se tornar uma maquininha de gerar bugs em regras de negócio estáveis e maduras até então. Estes bugs começam a minar os outros clientes e até os próprios clientes demandantes destas alterações, logo porque o aplicativo que ele tem em mãos não está funcionando plenamente.
Se para a empresa mantenedora do ERP é um problema sério ter os seus clientes insatisfeitos com o seu produto, pode haver um outro problema silencioso e muito mais crítico, que é o cansaço e stress da equipe que mantém essa aplicação. A constante alteração das regras do sistema o tornaram massante de manipular o que leva a gerar uma carga grande de stress para quem tem que realizar alguma manutenção. Sim! Isto pode ser uma mágoa ou lavagem de roupa suja, mas é o que rola de verdade, e basicamente não tem como mudar isto, por mais que a cada modificação sejam feitas documentações, aumento de salário, etc. sempre será estressante ter que dar manutenção.
Dependendo do caso, as vezes é feito um grande refactoring de uma determinada regra de negócio afim de tentar amenizar ou padronizar de uma forma melhor e que atenda todos os clientes. Este refactoring as vezes nada mais é do que desfazer o castelo de cartas e refazê-lo, logo porque não há como escapar de todas as amarrações necessárias para atender os clientes. Mas as vezes isso dá certo.
Conclusão
Este não é para ser um artigo triste ou dramático, é só para ajudar a compreender como é ‘complicado’ o mundo de quem trabalha com ERPs, e que a culpa não é nem do cliente, nem da empresa e nem dos consultores/desenvolvedores, é como eu disse no título deste artigo, você está em um vale e todo dia sobe a topo da montanha para aumentar a bolinha de neve lá .
Em um belo dia de sol, o vento irá fazer com que ela role montanha abaixo pegando todo mundo.