Atuando há mais de 18 anos com projetos de automação no Brasil, pude observar que projetos de sucesso de automação de processos normalmente foram executado em um ambiente com as seguintes características:
- A plataforma de BPMS escolhida atendia as expectativas planejadas, conseguindo entregar todos os requisitos e funcionalidades desejadas no momento em que ela foi selecionada;
- O processo escolhido era propício para automação, tendo características que realçaram os ganhos que a tecnologia pode trazer em uma automação de processos;
- O modelo de negócio (TO-BE) foi revisitado e transformado em um modelo para automação (TO-DO) adaptando e detalhando as suas características e funcionalidades para que fosse suportado adequadamente pela ferramenta;
- A equipe de automação tinha conhecimento e expertise suficientes para realizar a automação, tendo uma base conceitual de processos e tecnologia adequadas e o conhecimento técnico necessário para usar as ferramentas disponibilizadas e
- A gestão da mudança foi considerada como algo fundamental para a implantação do processo, disparando ações de mobilização e preparação para que o processo automatizado fosse realmente utilizado.
Contudo, nem sempre é fácil criar um ambiente com essas características e, ao longo do caminho, muitos problemas podem aparecer. Ao longo deste artigo apresento, para cada um destes fatores, os principais desafios enfrentados pelas organizações no momento de automação de um processo, buscando descrever o motivo pelo qual problemas ocorrem.
As seções a seguir apresentam em seu subtítulo os principais problemas enfrentados. Os motivos pelos quais eles ocorrem estão realçados em negrito ao longo da explanação.
Fator #1: A plataforma BPMS deve atender as expectativas planejadas
Problemas que impactam neste fator:
#1.1 A plataforma de BPMS não atende às necessidades da forma como se gostaria
#1.2 O desenvolvimento de processos na plataforma é muito complexo para ser realizado pelo negócio
#1.3 A plataforma foi escolhida por ser do mesmo fabricante do meu ERP e não atende adequadamente os meus processos
A escolha de uma plataforma de BPM é uma árdua e difícil tarefa, pois envolve inúmeros fatores que vão desde questões técnicas até elementos de natureza financeira, mercadológica ou funcional. Escolher um BPMS não é tão simples como escolher um editor de texto ou um navegador. Empresas que nunca utilizaram uma solução de automação de processos podem não entender toda a amplitude e complexidade desta escolha até virem a usar uma, o que pode prejudicar a qualidade do processo de seleção.
O leque de funcionalidades oferecido por uma plataforma de BPM é muito amplo e envolve uma série de siglas e tecnologias tais como BPA, BPMS, BPMN, BRMS, BAM, ECM e SOA, para citar algumas.
Saber o que a empresa realmente precisa para atender aos seus processos é essencial para que a plataforma atenda aos requisitos dos projetos. Isso envolve uma discussão ampla do que é necessário e de que forma cada funcionalidade atenderá às expectativas.
Nos projetos de seleção de plataforma de BPM executados pela iProcess, a primeira etapa visa justamente identificar quais os requisitos que deverão ser avaliados, com base numa planilha com mais de 500 itens. Entender o que é realmente importante para o cenário de processos da organização e refletir o que se espera de cada funcionalidade é fundamental para que não se descubra no andamento do projeto que a suíte adquirida não atende às necessidades do processo.
Entre as características desejadas, uma das grandes expectativas é a possibilidade da própria área de negócio conseguir automatizar os seus processos. Contudo, para este sonho se tornar realidade, a plataforma precisa ser simples e objetiva, provendo um ambiente de configuração de processos, formulários e integrações descomplicado que permita o desenvolvimento através de ações intuitivas de configuração. A solução deve prover capacidade ao negócio de desenvolver o seu processo sem que para isso sejam necessários conhecimentos técnicos em tecnologia da informação.
Evidentemente que toda a simplicidade gera limitações. Neste caso, os processos precisarão se adequar para utilização de formulários com inteligência limitada, fluxo com regras de negócio simples e possivelmente inexistência de integrações com outros sistemas de informação.
O desequilíbrio na avaliação destes fatores pode fazer com que todo um projeto de automação planejado para ter baixo envolvimento da TI simplesmente se mostre inviável.
Finalmente, é importante ressaltar que muitos processos de seleção se iniciam de forma invertida. Isto é, partem do produto para definir os requisitos. Isso acontece devido à ideia que uma plataforma de um fabricante predominante entre os sistemas da minha organização terá mais aderência às minhas necessidades. A suposição que normalmente é feita é que se parte dos sistemas forem do mesmo fabricante do BPMS, a integração e operação dos processos será muito mais fácil.
Esse pensamento não leva em conta que sistemas de informação são desenvolvidos para atender a necessidades transacionais, cujo foco está no modelo de informação necessário para o negócio e em como estas informações são transformadas ao longo das transações. Por outro lado, processos automatizados visam atender o fluxo destas informações, organizando como elas transitam entre as diferentes pessoas e sistemas.
Soluções de automação de processos trazem para o mundo sistêmico a capacidade de atender necessidades de trâmite e execução que não são atendidas pelos sistemas convencionais. Por isso a escolha de um BPMS deve se focar nos requisitos de processos ao invés de serem simplificados a uma análise de aderência aos sistemas que a organização já utiliza.
Fator #2: O processo automatizado deve ter características favoráveis à automação
Problemas que impactam neste fator:
#2.1 A automação do processo não traz os ganhos esperados
#2.2 O processo é complexo demais para ser automatizada pelo negócio
Por mais produtiva que possa ser a plataforma utilizada, toda automação exige esforço e tempo e é um investimento que gera expectativas nos envolvidos. Entre as motivações mais comuns para a automação, podemos citar a necessidade de controle, diminuição de prazo, aumento da eficiência e eficácia, rastreabilidade ou garantia da integridade do processo, entre outros fatores.
Os ganhos obtidos com a automação, sejam eles quantitativos ou qualitativos, dependem das metas traçadas para os seus indicadores, e de acordo com a natureza e as características do processo a automação pode se mostrar pouco eficaz para alcançar estes ganhos frente ao investimento que se faz necessário.
Projetos de automação devem ser iniciados por uma análise de ROI que avalie quais são os ganhos esperados, o quanto eles podem ser atingidos com a automação e o quanto o investimento para se obter estes ganhos justifica a execução do projeto. A falta de uma análise adequada antes do início do projeto pode alimentar a ideia de que os ganhos oriundos com a automação são periféricos e estigmatizar toda e qualquer iniciativa futura.
Além disso, tão importante quanto entender se a plataforma não é muito complexa para ser usada pelo negócio, é avaliar se o processo é suficientemente simples para que possa ser automatizado sem o envolvimento da TI. Processos cuja automação é conduzida pelo negócio costumam ter algumas características que fazem que a sua configuração não exija um conhecimento técnico aprofundado. Por exemplo, processos centrados em pessoas, com atividades baseadas em formulários de interfaces simples e com pouca (ou nenhuma) necessidade de integração.
Processos que demandem a incorporação de informações de sistemas legados ou de sistemas externos, que precisem de formulários complexos ou de muitas de regras de negócio e validações, ou que tenham atividades humanas intercaladas com atividades sistêmicas tendem a exigir um conhecimento técnico que normalmente só é dominado pelos profissionais da área de TI.
Entender claramente as características do processo é fundamental para que a iniciativa de automação, quando feita pelo negócio, possa chegar até o fim como uma ação bem-sucedida.
Fator #3: Transformação do Modelo de Negócio para um Modelo de Automação
Problemas que impactam neste fator:
#3.1 Acreditar que as informações do modelo de negócios (TO-BE) são suficientes para a automação
#3.2 Não pensar na usabilidade do processo automatizado
#3.3 O processo trava devido à falta de regras e exceções
#3.4 Acreditar que o processo irá substituir as aplicações
#3.5 Trazer toda a complexidade das aplicações para dentro do processo
Desenvolvido com o foco de mostrar para as áreas quais as expectativas de negócio são esperadas no processo e como o mesmo deverá ser executado, o modelo TO-BE não traz inúmeras das informações que são necessárias para uma automação de processos, tais como a interface e as informações que devem ser disponibilizadas para o ator no momento da execução ou as regras que definem quais pessoas na organização devem executar uma determinada atividade. Com a falta deste discernimento, não é raro que projetos inteiros sejam implementados sem que o modelo de negócios seja detalhado para um modelo de automação, gerando como resultado processos automatizados que não atendem às necessidades do negócio.
Num processo automatizado, a responsabilidade por distribuir as atividades entre as pessoas e decidir a ordem como o processo é executado é do motor de processo, que passa a orquestrar a sua execução de acordo com o diagrama modelado. Ao contrário do processo manual, em que as pessoas interpretam o fluxo do processo e podem improvisar as decisões sobre a sequência das atividades, um processo automatizado segue um caminho pré-definido no momento do seu desenvolvimento, de modo que todas as exceções relevantes devem ser conhecidas antecipadamente para garantir que o processo não irá “travar”. Processos automatizados sem este cuidado correm o risco de serem rapidamente abandonados por sua incapacidade de atender necessidades do negócio.
Tendo suas atividades sendo orquestradas pela plataforma, a interface disponibilizada para a execução de cada atividade passa a ser uma preocupação adicional. É através da interface que cada participante irá interagir com o processo. A automação exige uma visão conjunta que una as necessidades do processo e a usabilidade fornecida pela sua interface, de modo a fornecer um ambiente agradável e produtivo para quem vai executar o processo.
Apesar do cuidado necessário para que a interface do participante com o processo seja adequada, é importante ter em mente que a automação do processo não vem para substituir as aplicações, mas sim para complementar a camada transacional de informações com uma camada de tramitação de processos. Processos automatizados orquestram transações de sistemas legados que gerenciam informações financeiras ou comerciais, por exemplo, ao longo da sua execução. A camada de processos não vem para substituir estes sistemas, mas sim para unir suas operações sobre uma visão única de atendimento ao negócio.
Por isso é importante que esteja muito claro para a equipe de automação o que deve estar na camada de processos e o que deve estar na camada de aplicação, para evitar que sejam trazidas para o desenvolvimento do processo toda a complexidade de uma transação de processamento de informações. Exemplificando, não é porque a empresa decidiu automatizar o processo de pagamento da folha que ela trará para as telas do processo o cálculo do salário, imposto, contribuição e retenção, visto que esta responsabilidade cabe ao sistema de RH.
Fator #4: Equipe de desenvolvimento deve ter conhecimento e expertise suficiente na plataforma e nos conceitos de processos
Problemas que impactam neste fator:
#1 TI acha que a plataforma de BPMS é mais uma ferramenta de desenvolvimento
#2 Equipe não tem domínio técnico sobre a plataforma de BPMS
#3 A falta de visão de processos pela equipe de automação
Tão importante quanto a área de negócios ter os conhecimentos de técnicos exigidos pela plataforma quando ela vai automatizar um processo é que a TI tenha conhecimento de processos quando a sua complexidade exige que ela assuma esta automação. Não raro os times de tecnologia assumem que a plataforma de BPMS é mais uma ferramenta ou linguagem a ser aprendida, e não entendem que a forma de pensar e propor soluções é diferente. Enquanto linguagens convencionais trabalham orientadas a casos de uso ou transações, onde a análise do problema está focado em como o usuário irá interagir em uma determinada tela para realizar uma transação, a visão de processos exige a busca por soluções orientadas a forma como processo irá tramitar, como as atividades serão disponibilizadas, quem deverá ser alocado e como sistemas e pessoas se integram neste modelo.
A falta da visão de processos pelo time de TI pode fazer com que a sequência de atividades proposta mais se pareça com um grande “wizard” de passo-a-passo de execução de uma transação do que a orquestração de atividades de diferentes participantes que possuem responsabilidades e indicadores que precisam ser medidos para que possa gerar dados relevantes para a gestão do processo.
Juntando estes dois aspectos, é comum vermos estas equipes subdimensionarem o esforço de aprendizado necessário para se desenvolver e gerenciar uma plataforma de BPM. Isso faz com que as equipes enfrentem dificuldades técnicas que podem causar atrasos ou até mesmo o cancelamento do projeto.
Fator #5: Entender a importância da gestão da mudança na implantação do processo
Problemas que impactam neste fator:
#5.1 Resistência dos usuários inviabiliza o uso da solução
#5.2 Falta de patrocínio da direção na adoção do processo automatizado
#5.3 Não são executadas atividades de gestão da mudança
A implantação de um processo automatizado pode se demonstrar tão ou mais complexa do que a adoção de um novo processo TO-BE, tendo em vista que:
- Traz uma nova configuração do processo, discutida e redesenhada para que o processo automatizado já carregue consigo os ganhos das mudanças priorizadas; e
- Além do desafio das pessoas de saírem de sua área de conforto para fazerem o processo de uma forma diferente, a automação traz consigo transparência, controle e rastreabilidade sobre tudo o que é feito no processo.
A falta de visão dos gestores de que a mudança pode gerar resistências dos usuários pode inviabilizar a adoção do novo processo, que começa a ser boicotado desde as etapas de homologação e capacitação até a sua execução.
A realização de ações de gestão da mudança são fundamentais para a conscientização de todos de porquê as coisas devem mudar. A equipe deve estar particularmente interessa em demonstrar:
- A necessidade de se fazer o processo de forma diferente;
- O que motiva a implantação das mudanças aprovadas;
- A importância para a empresa de se buscar que as metas do processo sejam atingidas;
- Os problemas que existiam na forma como o processo era feito anteriormente.
As iniciativas de gestão de mudança neste caso são tão importantes quanto as ações de implementação de qualquer processo futuro. Ainda apresentam o agravante que os participantes, no caso da automação, irão resistir não só a sair da zona de conforto como também à possibilidade de terem suas ações visíveis, rastreáveis e controladas.
Para o sucesso destas ações, o patrocínio da liderança executiva é fundamental, porque garante que os envolvidos receberão uma mensagem clara e inequívoca: as mudanças chegaram para ficar e deverão ser cumpridas para o sucesso dos planos traçados e de toda a organização.
Conclusão
A quantidade de obstáculos listados acima mostra que o caminho para um projeto de automação de sucesso é cheio de desafios.
Se por um lado observamos que projetos que contemplem os fatores de sucesso apresentados inicialmente tem grande chance de dar certo, é inevitável notar que a falta de qualquer um destes fatores pode ser determinante para um eventual fracasso. Cabe à equipe estar atenta para estes fatores, para evitar estes e outros problemas e usufruir dos ganhos que a automação pode trazer à organização.
Autor: Eduardo Britto é sócio fundador e diretor da iProcess. É mestre em ciências da computação com ênfase em automação de processos pela UFRGS (Universidade Federal do Rio Grande do Sul), professor de MBA em BPM na Unisinos e Senac-SC além de outras certificações como OCEB Business and Technical, CBPP, PMP e CDIA+.
Saiba mais sobre o autor: https://br.linkedin.com/in/eduardobritto
Artigo publicado originalmente em Revista BPM
