A automatização de processos através de BPMS (Business Process Management Suites) tem sido frequentemente adotada nas organizações num esforço para otimizar seus processos. No post Benefícios da Automação de Processos do nosso blog, já discutimos os principais benefícios intrínsecos à automatização de processos.
Neste post, iremos falar de uma situação recorrente no mercado em projetos de automatização de processos: a automatização que é feita sem uma etapa de análise e redesenho e processos efetuada previamente.
Idealmente, em qualquer projeto de implementação de BPM, o ciclo BPM a ser seguido inclui a análise (AS IS) e o redesenho (TO BE) dos processos, antes de seguir para a etapa de implementação (TO DO). Desta forma, garante-se que o cenário atual do processo na organização foi adequadamente estudado, e todas as necessidades de melhoria no processo foram devidamente contempladas. Porém, é comum encontrar empresas que investem em projetos que simplesmente “pulam” as etapas de análise e redesenho, seguindo diretamente para a etapa de implementação.
Na maioria das vezes em que isso ocorre, tratam-se de processos de negócio razoavelmente definidos que estão sendo ativamente executados dentro da organização. Para estes processos são identificadas necessidades de melhoria, e aqui está o grande diferencial em relação a um processo que está passando por um ciclo típico de BPM: as necessidades de melhoria identificadas, ao menos na percepção dos responsáveis por aquele processo, estão relacionadas diretamente aos sistemas que apoiam a execução do processo. Ou seja, em tese os processos estão bem definidos, mas não estão sendo apoiados adequadamente por um sistema. Abaixo alguns dos motivos mais frequentes que levam a automatização direta dos processos:
-O processo é executado em papel, que é um dos casos mais comuns. Com a automatização, busca-se então substituir os formulários em papel por formulários eletrônicos melhorando o fluxo e o gerenciamento da informação;
-O processo é executado com suporte de sistemas, porém são diversos sistemas que precisam ser utilizados. Isto força os usuários a precisar alternar entre os sistemas para executar o processo. Com a automatização, busca-se a integração destes sistemas de maneira automática, passando até mesmo pela criação de um front-end único para a execução do processo pelos usuários (desta forma desativando alguns ou todos os sistemas existentes);
-O processo é executado com suporte de sistemas, porém em diversos pontos os usuários são requisitados a manter documentos/planilhas em repositórios na rede da organização, dificultado a manutenção e auditoria dos mesmos. Com a automatização, busca-se a integração automática destes documentos ao BPMS, controlando o seu ciclo de vida, utilizando o repositório nativo do BPMS ou uma solução de ECM (Enterprise Content Management).
Embora “economize” etapas (e consequentemente custos) do ciclo BPM, a abordagem de automatizar o processo diretamente tem seus riscos. O mais intangível, e não menos importante, é o desperdício de oportunidade: não aproveitar que está sendo direcionado tempo e recursos para melhorar o processo pode prover uma visão míope do mesmo durante a análise para automação, focando única e exclusivamente nas necessidades de sistema. Desta forma, corre-se o risco de deixar passar outras oportunidades de melhoria importantes e impactantes para o processo como um todo.
Outro risco bastante frequente desta abordagem é a possibilidade de “automatizar o erro”, ou seja, pegar um processo que não está bem documentado (conhecimento na cabeça das pessoas), pouco otimizado, por vezes definido incorretamente, com várias lacunas e desperdícios, e simplesmente automatizá-lo. Neste caso, a automatização de processos está longe de ser a solução mágica para todos os problemas: ao se automatizar um processo com erros, o que normalmente se obterá é… um processo com erros automatizado. :-)
Esta situação é muitas vezes alimentada por uma necessidade de provar a tecnologia dentro da organização. Como a aquisição de um BPMS por si não soluciona o problema – é necessário implementar a automatização do processo para que então o produto se faça provar como bom investimento para a empresa, o projeto acaba sendo “um piloto, mas que vai à produção”. A estratégia é arriscada e o tiro pode sair pela culatra: se o processo com problemas for automatizado as is, as falhas continuarão existindo e poderão ser potencializadas, gerando rejeição do uso do sistema pelos participantes do processo e outros resultados insatisfatórios, que poderão desacreditar a adoção do BPMS como solução.
É como construir uma casa sem um projeto arquitetônico, em que se possa analisar a ideia do imóvel e planejar melhorias antes de começar a levantar as primeiras paredes. Pode ser rápido, e pode dar certo, mas as chances de desperdiçar material e chegar ao final com um resultado insatisfatório são bastante elevadas.
O caminho mais seguro é investir em um ciclo completo, porém em partes, gerando quick wins e demonstrando que a gestão por processos com apoio de um bom BPMS pode resultar em excelente retorno para o investimento da organização.
