BPM como ferramenta para melhoria do nosso dia a dia

Muito se fala sobre modelagem, análise e redesenho de processos para melhorar e otimizar os processos das organizações.

Aqui mesmo no blog já falamos muito destes temas. Em se tratando de organizações tradicionais, contudo, é natural que as iniciativas de BPM sejam voltadas para objetivos mais “ortodoxos”, como por exemplo:

  • Redução de custos (objetivo clássico);
  • Redução dos tempos de execução (também clássico);
  • Melhorar o acompanhamento e controle do processo (extremamente clássico);
  • Melhor atender as necessidades do cliente (este deveria ser o objetivo final de tudo, não é?).

Mas… é possível aplicar também a melhoria de processos para melhorar o meu dia a dia, e a minha interação com as pessoas e empresas que prestam serviços para mim? A resposta: É claro que sim!

Num país com tantas deficiências, onde necessidades básicas muitas vezes não são atendidas, as oportunidades de melhoria saltam aos nossos olhos como… pipocas em uma panela aberta.

Podemos afirmar que o grande benefício, e ao mesmo tempo uma grande fonte de frustração de quem começa a praticar BPM é que isso não muda somente a sua visão dos processos e da sua empresa… Muda também radicalmente a sua visão de mundo, para sempre.

Tenha a plena certeza: após ser pego pela “febre” do BPM, a pessoa vai ser pega adotando técnicas de análise e melhoria de processos em todos os lugares:

  • Na fila do supermercado: pensando que as regras de distribuição dos empacotadores entre os caixas não está clara e bem definida, e precisa ser seguidamente orientada por um supervisor. E que, na sua opinião, este supervisor deveria destinar seu tempo a objetivos mais nobres (como verificar porque um cliente está com cara de zangado discutindo com o caixa ao lado);
  • Na fila de um banco: pensando porque se forma uma fila de 10 pessoas e existe apenas UM caixa atendendo no horário do almoço (justo o momento em que o banco tem mais movimento?);
  • No restaurante: pensando porque a fila está liberada nos dois lados do buffet, mas os pratos não se repetem nos dois lados, e não existe como pegar um prato do outro lado sem ter que entrar na fila de novo;
  • Ao telefone num auto-atendimento: pensando porque eu preciso repetir todo o meu problema cada vez que sou repassado de uma área pra outra, e por que RAIOS sempre pedem pra repetirmos informações que já foram passadas no começo da ligação? Porque preciso ser repassado de uma área pra outra, aliás?

É por isto que ter o hábito de utilizar técnicas de análise e melhoria de processos pode algumas vezes ser frustrante para o praticante de BPM. Pois este praticante passa a ter uma outra visão sobre as coisas, e adquire a habilidade de enxergar processos defeituosos e oportunidades de melhoria a todo momento, muitas vezes com pouco ou nenhum acesso para viabilizar alguma mudança.

Talvez seja neste momento a pior parte, que é ter a coragem de apontar as oportunidades de melhoria, criticar e sugerir. E não somente para as empresas privadas que nos prestam serviços. Para os órgãos públicos também, afinal seu propósito é servir o cidadão, e deveriam ter preocupação fundamental em melhorar seu atendimento.

Nós, profissionais do processos (ou você que está estudando e querendo ser tornar um), muito discutimos o “foco no cliente” ou “foco do cliente” na teoria de BPM, e como sempre deveríamos considerar a visão do cliente para realizar a melhoria em um processo.

Mas se quisermos fazer a diferença não somente para a nossa empresa, mas para a sociedade e o nosso país, temos que dar um passo além: vestir a casaca do analista de processos, enquanto clientes e cidadãos, e ajudar a melhorar todos os processos que temos contato: sugerindo melhorias, criticando, apontando problemas e soluções. E quem sabe, com uma pequena melhoria aqui e outra acolá, isso não pode deixar o seu dia a dia (e o de outras pessoas também) um pouco melhor?

Projetos de Modelagem de Processos – Parte 2 – Características e Desafios

No primeiro artigo da série, vimos os principais tipos de projetos de modelagem de processos, e quais seus objetivos e principais motivadores.
Neste segundo e último artigo vamos descobrir, para cada tipo de projeto de modelagem de processos, qual é o nível de profundidade da modelagem, desafios e riscos (se for o caso) envolvidos.

Modelagem para Conhecer o Processo:

Profundidade da Modelagem:

  • o suficiente para que as atividades do processo e o seu objetivo sejam compreendidos.
  • que permita a identificação das responsabilidades atribuídas ao longo do processo

Desafios

  • eventual resistência dos usuários do negócio em revelar o conhecimento que possuem do processo
  • entender todo o escopo do processo e suas peculiaridades quando a organização não tem uma visão clara de onde ele passa

Modelagem para Documentação ou Treinamento:

Profundidade da Modelagem

  • todas as atividades devem ser documentadas com seus procedimentos detalhados
  • dúvidas comuns e regras de negócio devem ser descritos
  • documentos de apoio deve ser identificados e apontados
  • suas atividades são detalhadas em nível de procedimentos, criando-se uma documentação a nível operacional

Desafios

  • perceber quais informações serão efetivamente procuradas pelos usuários quando eles tiverem uma dúvida
  • organizar a documentação de modo que seja intuitiva para quem estiver aprendendo sobre o funcionamento do processo
  • elaborar uma documentação didática para quem não conhece o processo

Modelagem para Implantação de Auditoria:

Profundidade da Modelagem

  • processos são mapeados, detalhados e documentados o suficiente para que:
    • possam ser padronizados
    • expectativas sobre cada atividade estejam bem claras
    • sejam definidos critérios claros e objetivos de avaliação e medição
    • sejam definidas evidências objetivas que serão avaliadas durante a auditoria

Desafios

  • mudanças nesses processos exigem:
    • aprovação formal dos gestores do processo
    • comunicação das alterações a todos os que executam o processo
    • ciclo de treinamentos para reapresentação do processo

Mapeamento de Processos de Toda a Organização:

Profundidade da Modelagem

  • costumam ser menos detalhados do que processos para auditoria ou treinamento
  • envolvem mais o desenho do processo que a descrição detalhada de cada atividade

Desafios

  • garantir que todos os consultores documentem no mesmo nível de detalhe
  • sentimento que projeto termina quando todos os processos foram entregues (na verdade, este deveria ser o início do ciclo)
  • manter os processos vivos e atualizados
  • base de processos não cair em desuso alguns meses após o projeto
  • justificar o retorno do investimento neste tipo de projeto sem um motivador mais objetivo e com um ROI bem definido.

Riscos envolvidos

  • mapear somente por mapear, sem uma continuidade ou objetivo específico
  • definir uma política de governança para garantir a atualização dos processos
  • definir responsáveis pelos processos e fazer que os mesmos garantam a sua atualização

Modelagem para Padronização dos Processos:

Profundidade da Modelagem

  • detalhar atividades e procedimentos o suficiente para que o mesmo possa ser replicado. Via de regra, no mínimo, no mesmo nível do aplicado na documentação ou treinamento.

Desafios

  • unificar a forma como o processo é executado quando o mesmo é executado de formas distintas em cada local
  • diminuir a resistência à mudança daqueles que acreditam que a sua forma é a melhor
  • perceber as peculiaridades regionais que efetivamente exigem que o processo tenha que ser executado de forma diferenciada

Modelagem para o Redesenho de Processos:

Profundidade da Modelagem

  • o mínimo possível, desde que este mínimo seja o suficiente para o entendimento do processo e seus problemas
  • não envolve a documentação operacional do que é executado

Desafios

  • vencer a resistência das pessoas que não desejam a mudança
  • enfrentar o boicote daqueles que não querem expor os problemas do processo devido às atividades que eles executam

Modelagem para Automação de Processos:

Profundidade da Modelagem

  • entendimento é mais detalhado do que na modelagem para o redesenho
  • os resultados esperados de cada atividade não são alterados. Não há mudança no “o que é feito” em cada atividade do processo. Assim, a situação atual deve ser detalhada a nível operacional.
  • ocorre mudança, contudo, no “como é feito” cada atividade.
  • é desenvolvido o modelo to-do, que melhora o processo com tecnologia
  • atividades manuais passam a ser automáticas
  • prazos passam a ser controlados de forma proativa
  • é implementada a garantia de integridade dos processos

Desafios

  • garantir que realmente o processo é eficaz e atende aos objetivos da organização.
  • modelar todas as regras de negócio no nível de profundidade necessário.

É possível perceber que cada projeto tem as suas particularidades, e estas devem ser levadas em consideração durante o planejamento do projeto, para que o êxito seja obtido!

 

 

Projetos de Modelagem de Processos – Parte 1: Objetivos e Motivadores

A modelagem de processos está sendo muito utilizada pelas organizações para conhecer, documentar e melhorar os seus processos. Porém, as necessidades que levam uma organização a iniciar a modelagem de processos acabam direcionando a tipos de projetos de modelagem com focos diferentes.
Trataremos, neste primeiro artigo da série, dos principais objetivos e motivadores relacionados aos mais comuns tipos de projetos de modelagem de processos.

 

Modelagem para Conhecer o Processo:

Objetivo
  • modelar o processo de modo que a forma como ele é realizado passe a ser de conhecimento dos participantes que executam o processo e da organização como um todo
Motivadores
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Documentação ou Treinamento:

Objetivos
  • documentar o processo para que dúvidas operacionais possam ser diluídas através da consulta ao processo
  • fornecer uma documentação completa para que os seus executores saibam como realizar suas atividades, evitando erros ou demoras devido a dúvidas
  • fornecer uma documentação que facilite o treinamento de novos colaboradores:
    • minimizando o efeito de perdas de colaboradores
    • auxiliando a organização que passe por um processo de expansão
Motivadores
  • processos em que os executores não tem experiência em executá-lo porque:
    • os papéis tem alta rotatividade ou
    • o processo não é executado com frequência por determinados papéis
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Implantação de Auditoria:

Objetivo
  • descrever os processos que serão objetos de auditoria para que exista uma referência comum sobre o que deve ou não ser feito no processo
Motivadores
  • padronização e documentação de processos que precisam ser auditados devido a exigências internas ou externas da organização
Mapeamento de Processos de Toda a Organização:

Objetivo
  • criar um repositório de processo com todos os processos da organização modelados e documentados
Motivadores
  • criar um ponto de partida para as iniciativas de gestão por processos
  • permitir que novas demandas de melhoria de processos possam ser atendidas rapidamente
Modelagem para Padronização dos Processos:

Objetivo
  • garantir que toda a organização executa o mesmo processo
Motivadores
  • demandada por processos executados em mais de um local. Ex.: Processo utilizado em várias unidades geográficas como no varejo ou no sistema financeiro.
  • processos que possuem diferente desempenhos de acordo com o local onde são executados ou das pessoas que os executam
  • aquisição de outras empresas → Necessidade de unificar a operação
  • abertura de novas unidades → Necessidade de replicar o modelo de gestão
Modelagem para o Redesenho de Processos:

Objetivos
  • a modelagem é focada no entendimento da situação atual do processo (AS IS)
  • objetivo não é a documentação do processo e sim o entendimento de
    • quais são suas atividades
    • quais os seus pontos fracos
    • quais os seus pontos fortes
    • quais suas oportunidades de melhoria
  • criar base para executar todo o ciclo BPM de melhorias: Mapeamento, Redesenho, Automação, Implantação e Melhoria Contínua.
Motivadores
  • redução de custos ou perdas do processo
  • processos críticos que, se não forem bem executados, podem gerar um grande impacto na organização
  • processos com metas cronológicas bem delimitadas
  • processos que possuem muitas perguntas a serem respondidas. Ex: Como é feito o processo? Porque acontecem tantos erros? Porque o processo é tão lento? Como posso melhorá-lo? Como meço os indicadores deste Processo?
  • processos com SLA bem definidos
  • melhorar o atendimento ao cliente final
  • expansão organizacional
  • processos inter-organizacionais (B2B)
  • empresa precisa se certificar ou aderir a uma legislação
Modelagem para Automação de Processos:

Objetivo
  • conhecer o processo o suficiente para propor uma versão automatizada que busque aumentar a sua eficiência operacional
Motivadores
  • ocorre quando a organização está satisfeita com o seu processo, mas acredita que ele poderia ser melhorado com o uso da tecnologia
  • organização entende que não precisa necessariamente discutir o processo a nível de negócio, e sim entregar com mais eficiência o processo da forma como atua hoje

Leia também o artigo Parte 2 – Características e Desafios, que trata da profundidade da modelagem, características, desafios e riscos relacionados a cada tipo de projeto de modelagem.

A importância de avaliar a cultura e o medo da mudança na implementação de BPM

Neste artigo vamos abordar alguns dos aspectos mais críticos, e frequentemente ignorados, no que se refere a implementar BPM nas organizações: como a cultura organizacional e o medo da mudança são fatores que podem afetar consideravelmente o resultado desta iniciativa.

Durante a implementação de projetos de BPM, é muito frequente se deparar com obstáculos relacionados à cultura da organização, principalmente no que se refere à forma como as coisas costumam ser feitas. São procedimentos, padrões e ferramentas que se estabeleceram com o passar do tempo, e acabaram virando a única forma conhecida das pessoas de realizar o seu trabalho. Com a realização de um trabalho de análise e redesenho do processo através de uma iniciativa de BPM, então todos os gaps, ineficiências e problemas desta forma de trabalho podem vir à tona. Podemos citar como exemplo um caso clássico na automatização de processos: a substituição de formulários em papel que devem ser assinados manualmente pelos gestores, por formulários eletrônicos em que a aprovação é controlada por um processo automatizado e realizada através de uma lista de trabalho.

É do nosso conhecimento casos em que usuários de negócio ficaram receosos e resistentes pelo simples fato de que as aprovações necessárias não iriam mais ser em papel, ou seja, sem a assinatura “física” do seu gestor. São usuários que não foram suficientemente informados de todos os conceitos por trás de uma aprovação digital, e chegaram a exigir (já numa fase bem adiantada de uso do processo) que os participantes deveriam adicionalmente imprimir o histórico de aprovações e anexar junto a solicitação, para que fosse dado o encaminhamento para a próxima área envolvida. Temos aqui um caso em que um dos maiores benefícios da automatização de processos, que é a economia de papel, foi praticamente anulada simplesmente pelos receios de usuários mal informados.

Uma mudança na forma de como são feitas as coisas pode mexer ainda com questões comportamentais enraizadas na organização, e que podem passar despercebidas até para o mais experiente analista de processos. Podemos citar o exemplo de um solicitante que aproveitava o momento em que solicitava a aprovação do seu gestor (com o formulário em papel em mãos), para sentar com ele na sua sala, tomar um cafezinho e discutir com ele banalidades e o resultado do futebol no fim de semana. E que, de uma hora pra outra, teve esta rotina agradável e esperada (do ponto de vista dele) sendo substituída pela rápida, eficiente e distante aprovação eletrônica. O exemplo pode até parecer exagerado e cômico, mas é um tipo de percepção que de fato ocorre entre os usuários, e é preciso ficar atento.

A resistência a mudanças pode ser um grande impeditivo para o sucesso de projetos de BPM. Se os usuários não forem suficientemente informados e principalmente convencidos da necessidade da mudança, podem virar grandes opositores e chegar ao ponto de boicotar a iniciativa, levando muitas vezes o projeto ao fracasso. Em outro exemplo que ilustra esta situação, uma das pessoas envolvidas na execução de um processo chegou a temer pelo seu emprego, quando descobriu que a automação do processo iria realizar de forma automática muito dos procedimentos que esta pessoa executava de forma manual, procedimentos os quais tomavam boa parte do seu dia. Foi então necessário um trabalho de informação e conscientização com esta pessoa, informando que esta seria direcionada para atividades de maior valor agregado, para que a resistência e o medo da mudança fossem finalmente superados.

Se durante uma iniciativa de BPM as organizações optarem por ignorar a avaliação da cultura interna e não realizarem uma etapa de gerenciamento das mudanças com todos os envolvidos, certamente poderá se esperar como resultado uma resistência muito grande e, em casos extremos, até o cancelamento da iniciativa.

BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado

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.

Os desafios da homologação de Processos Automatizados

O avanço do BPM trouxe muitos benefícios para as organizações, porém trouxe também alguns novos desafios. Para os usuários finais, isso gerou uma grande mudança cultural que, se não for corretamente encaminhada, pode colocar em risco toda a iniciativa BPM. Engana-se, porém, quem pensa que os usuários finais são os únicos que se depararam com mudanças importantes na adoção de BPM. Também a equipe de TI passou a ter novos desafios, e hoje iremos falar de um destes: a homologação da automação de processos.

A homologação de sistemas tradicionais de TI é um processo bem conhecido que envolve, em linhas gerais, a criação e a execução de roteiros de testes pelos testadores e usuários de negócio. Ao longo do tempo, uma série de ferramentas e metodologias surgiram para facilitar este processo, envolvendo desde a automação dos testes através de ferramentas específicas para este fim, até metodologias como Test Driven Development (TDD), que modificam significativamente o processo de desenvolvimento convencional.

Grande parte das homologações dos sistemas convencionais possuem em comum a existência de uma tela que deve ser homologada, ou seja, uma interface que é a “cara” do sistema para os usuários finais. Estas telas podem eventualmente ter grande complexidade, envolver múltiplos passos para execução e outros complicadores, mas o processo de homologação de um sistema convencional é normalmente bem direto: devem ser testadas todas as interações do usuário com as telas, e se certificar que o sistema está respondendo da forma esperada.

Esta forma de realizar os testes ainda continua válida no caso de homologação de automação de processos, e ainda existirão telas que deverão ser homologadas (nos casos em que usuários interagem com o processo), mas existem diferenças importantes. A principal delas diz respeito ao “coração” da automação de processos, que é o fluxo automatizado que deve ser testado. No lugar de ter apenas uma ou mais telas que precisam ser testadas, agora o principal foco dos testes passa a ser o processo automatizado em si, ou seja, a execução das tarefas seguindo o fluxo desenhado. Isto traz uma série de dificuldades bem específicas, e abaixo listamos algumas das mais importantes:

  • Um processo automatizado, muitas vezes, é iniciado por outro sistema. Nestes casos é preciso simular o disparo do processo manualmente, utilizando por exemplo ferramentas de testes de serviços (ex: SoapUI), que não são muito amigáveis para usuários finais. Nestes casos, também é preciso montar manualmente diferentes versões do que costumamos chamar de dados de entrada do processo, ou seja, os dados que serão exibidos e manipulados durante a execução do processo. Cada uma destas versões tratará de um diferente cenário previsto nos roteiros de testes.
  • Diferente de uma tela de sistema convencional, que via de regra pode ser homologada por um único usuário, um processo automatizado é composto de atividades enviadas para usuários diferentes, muitas vezes pertencentes a diferentes setores da organização. Desta forma, diversos usuários de negócio precisarão ser envolvidos no processo de homologação, cada um testando as atividades que lhe competem. Isto gera uma série de questões adicionais que precisam ser previstas em tempo de planejamento, como por exemplo, os tempos de espera que um determinado usuário poderá ter durante o dia, enquanto aguarda que os fluxos em execução atinjam o estágio em que este usuário participa do processo.
  • Embora sejam executados por diferentes papéis e eventualmente setores da organização, deve-se garantir a integridade e a perfeita execução do processo automatizado como um todo: isso exige um perfil que precisará acompanhar a execução do processo entre os diversos papéis/setores, e garantir a correta execução de todos os caminhos previstos. Envolve ações como, por exemplo, garantir a integridade dos dados sendo manipulados de uma atividade para outra, e garantir que o encaminhamento feito na atividade anterior executou o andamento correto no processo.
  • Muitas vezes, durante a execução do processo automatizado, existem integrações automáticas que não tem uma “interface” visível para os usuários. Por exemplo, são integrações que gravam e/ou obtêm informações em banco de dados e sistemas legados, usualmente via invocação de serviços. Nestes casos é preciso testar estas integrações manualmente durante a execução do processo, utilizando ferramentas mais técnicas (ex: a própria ferramenta de administração do BPMS), que no geral são pouco amigáveis para usuários finais. Nestes casos a homologação destas integrações tende a ser “delegada” para perfis mais técnicos do projeto, como analistas e testadores, visto que dificilmente um usuário de negócio terá o conhecimento ou perfil necessário para fazer estas verificações.
  • Em muitos casos, as aplicações acessadas para apoiar a realização das atividades foram construídas especificamente para serem invocadas através do processo. Logo, nestes casos é necessário ter preocupações adicionais de testes de segurança destas aplicações, como por exemplo:
    • Garantir que uma determinada aplicação só conseguirá ser acessada através da atividade específica que a invoca, e que não poderá ser acessada através de artifícios como, por exemplo, colar a url no navegador;
    • Garantir que somente os usuários dos papéis que estão atribuídos à atividade terão acesso aquela determinada instância de processo.

Como vimos, a homologação de automação de processos traz novos desafios em relação à homologação de sistemas convencionais, e precisa desta forma ser adequadamente planejada e estimada no cronograma do projeto.

Como manter a aderência ao modelo TO BE na automatização de processos

Num ciclo BPM típico, o processo TO-BE é desenhado em conjunto com a área de negócios.  A partir daí, de acordo com um conjunto de critérios e avaliações, pode-se optar por seguir o ciclo e efetuar a automatização deste processo numa ferramenta de BPMS.

Durante a implementação e testes de processos automatizados, um dos questionamentos mais recorrentes dos usuários de negócio é de como o fluxo do processo automatizado ficou diferente da visão TO-BE que foi desenhada com a participação deles. Frequentemente existe o questionamento de que o processo automatizado ficou mais “poluido” e com “muitas caixinhas a mais” em relação ao modelo TO-BE original.

Vejamos o processo fictício abaixo, desenhado em um nível mais genérico:

Modelo de Processo TO-BEO que podemos concluir deste processo?

  • Não existe a preocupação em detalhar em nível mais baixo/operacional as atividades, e sim mostrar uma visão de alto nível do processo, para auxiliar na compreensão do mesmo como um todo;
  • Algumas atividades podem estar ocultas, ou podemos ter uma atividade que encapsule outras (caso por exemplo da atividade “Geração e Envio da OC” – possivelmente 2 atividades separadas?);
  • Não está claro se as atividades são de responsabilidade de uma pessoa ou sistema;
  • Não fica claro qual exatamente é o responsável pela atividade, pois a divisão de roles foi feita em nível departamental, e não em papéis/funções (não entrando no mérito se esta seria a melhor abordagem de modelagem).

Este processo cumpre seu papel ao mostrar em um nível mais genérico qual o processo de execução de compras da empresa. Para fins de automação, no entanto, este processo não está no nível adequado. É necessário então um trabalho de levantamento no detalhe da execução deste processo, definindo todas as atividades, responsáveis, regras de negócio, automações, etc.

Vamos agora analisar o mesmo processo anterior, mas desenhado em um nível mais analítico, já em preparação para a automação:

Modelo de Processo TO-DOPodemos notar uma série de diferenças em relação ao processo anterior:

  • Atividades que na visão TO-BE eram uma só, agora foram separadas em atividades diferentes (atividades “Geração da OC” e “Envio OC fornecedor”). Percebam que o contrário também pode ser verdadeiro, ou seja: 2 ou mais atividades no modelo TO-BE podem virar apenas uma atividade no modelo automatizado;
  • O nível de granularidade do processo mudou: em vez de lanes em nível departamental, agora temos exatamente qual o papel/função que executa cada atividade;
  • Utilizando elementos visuais, foi especificado qual o tipo de cada tarefa (humana, automática, email);
  • Foi estabelecido um controle de tempo de execução das atividades, e envio de alertas por email caso as atividades não sejam executadas no seu prazo.

Assim, um processo que no nível TO-BE tinha apenas 3 atividades, virou um processo automatizado com 11 atividades. De certa forma, é fácil entender a perplexidade dos usuários, não?

Vamos tentar entender os motivos porque isso acontece. Durante o detalhamento do processo em preparação a automação, uma série de regras de negócio e de execução do processo são definidas, regras estas que não estavam visíveis no desenho do processo TO-BE. Isso acaba gerando necessidades adicionais na modelagem do processo automatizado, como por exemplo:

  • Buscar dados de apoio numa base de dados, para exibição nas atividades do processo;
  • Fazer transformação de dados entre atividades;
  • Buscar valores de parametrização utilizados pelo processo em sistemas de Back-Office;
  • Invocar procedimentos ou serviços específicos relacionados a regras do processo (ex: serviço institucional para calcular o prazo de uma atividade);
  • Etc.

A “multiplicação” de atividades no modelo automatizado em relação ao modelo TO-BE está ligado, principalmente, aos seguintes fatores:

  • Nível de detalhamento do modelo TO-BE. Em linhas gerais, quanto mais detalhado um modelo TO-BE, maiores são as chances do modelo automatizado ficar semelhante;
  • Recursos e possibilidades de automação da ferramenta de BPMS. Por exemplo, se a ferramenta de BPMS oferece mecanismos nativos para alertas por email, que estejam embutidas na própria configuração das atividades humanas, todas as atividades de alerta que temos no exemplo acima não seriam necessárias, como por exemplo a atividade “Alerta para enviar OC”.
  • O diagrama TO-BE que foi modelado numa ferramenta, mas implementado em uma ferramenta diferente, pode fazer com que uma tarefa que havia sido modelada de uma determinada forma tenha que ser, por restrições e características técnicas do BPMS, implementada de forma diferente.
  • perspectiva sob a qual o processo é modelado. Se o processo TO BE foi modelado unicamente sob a perspectiva de negócio (em que o controle do processo é executado por pessoas), ou se ele foi modelado já sob a perspectiva da automatização (em que o controle do processo é realizado pelo BPMS).

Percebemos, no mercado de ferramentas de BPMS, que existe um movimento no sentido de deixar a transição do modelo TO-BE para o modelo automatizado um pouco mais suave. Na última versão do Oracle BPM 11g, por exemplo, apenas 3 tipos de atividades (humana, serviço e regra de negócio) serão exibidas por padrão na trilha de auditoria dos processos, ocultando outras atividades mais técnicas (ex: adapters, scripts) que possam estar sendo utilizadas.

Podemos ver que não existe uma solução ou resposta simples para esta questão, em virtude da quantidade de fatores envolvidos que podem gerar esta diferença dos processos TO-BE em relação aos processos automatizados.

Uma forma de minimizar este impacto é que a equipe de tecnologia (analista de sistemas) se envolva no redesenho do processo, analisando juntamente com a área de negócio as melhorias tanto sob o aspecto de negócio quanto sob o aspecto tecnológico, de forma que o analista de sistemas traga para o TO BE a perspectiva do processo automatizado.

Melhores práticas de modelagem BPMN

Neste artigo, temos como objetivo demonstrar algumas das melhores práticas de modelagem BPMN. Esperamos que seja útil para o seu trabalho de modelagem.

Nomenclatura de Atividade:

  • Uma prática difundida entre profissionais de processos é utilizar na nomenclatura de atividades verbos no infinitivo. O nome da atividade deve identificar a principal ação envolvida em sua execução. Ex: “Aprovar solicitação de Viagem”; “Emitir contrato de prestação de serviços”, etc.

Tipos de Atividades:

  • Sempre que possível, procure utilizar os tipos de atividades da BPMN para distinguir entre tarefas manuais, humanas, serviços, etc:

Atualização: Para um melhor entendimento sobre os diferentes tipos de tarefas, veja estes artigos:

Nomenclatura das Lanes:

  • As Lanes de um processo devem ser nomeadas observando-se  o nível de granularidade. Por exemplo: caso o processo esteja sendo modelado a nível departamental, recomenda-se então que todas as lanes do processo sejam departamentos. Evite utilizar níveis de granularidade diferentes num mesmo modelo de processo, como por exemplo nomear uma lane como “Financeiro” (ou seja, um departamento) e nomear outra lane como “Analista de Compras” (ou seja, uma função/papel);
  • Evite o uso de cargos. Cargos são funcionais, e muitas vezes um papel em um processo pode ser realizado por pessoas de cargos diferentes.

Envio e recebimento de mensagens:

  • Procure padronizar, dentro de modelos relacionados, a forma utilizada para envio e recebimento de mensagens. Utilizar ou eventos intermediários do tipo message (catch/throw), ou tasks do tipo send e receive, não ambos ao mesmo tempo.

Gateways:

  • Quando um gateway testa uma informação obtida na atividade imediatamente anterior, é apropriado posicioná-lo próximo à tarefa, na mesma lane;
  • Não devem ser atribuídos a ações de tarefas (consultar informações, atualizar informações, etc). Devem ser utilizados apenas para representar a lógica de roteamento do processo, como demonstrado abaixo:

Forma inadequada:

Forma adequada:

Um início, muitos fins:

  • Evite utilizar mais de um evento de início no processo;
  • Utilize diversos eventos de fim, esclarecendo na nomenclatura de cada um o estado em que o processo encerrou.


Join e fork:

Os pontos de divergência e convergência no processo devem ser abertos e fechados, utilizando os gateways apropriados:

Fluxo paralelo:

Decisão exclusiva:

Decisão inclusiva:

Simples,  limpo e eficaz:

  • Procure manter o processo simples e limpo, evitando cruzar conexões;
  • Utilize eventos de link para continuar determinadas partes do processo que estejam no miolo e sejam complicadas de expor na página principal;
  • Transforme conjuntos de atividades com o mesmo objetivo em subprocessos, hierarquizando o modelo;
  • Utilize os artefatos de dados, anotações e grupos comedidamente.

Implantação de BPMS não substitui os sistemas da empresa

Num artigo anterior deste blog, procuramos abordar as diferenças entre BPM e Workflow, com a intenção de minimizar a confusão existente com relação a este dois termos. Neste sentido, achamos interessante continuarmos a desmitificar outros mitos que se referem a BPM no que tange o aspecto da tecnologia.

Hoje, vamos falar de um dos mitos que mais escutamos durante os nossos projetos: a idéia de que a implementação de BPM irá “substituir” total ou parcialmente os sistemas atuais, e passar eventualmente a ser o repositório central das informações da organização. Ou, como já ouvimos algumas vezes, que o BPMS vai passar a ser o “ERP” da organização!

Em uma iniciativa BPM, uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Neste sentido, um BPMS atua como orquestrador da execução dos processos entre pessoas e sistemas, definindo o fluxo do trabalho e da informação entre estes participantes. Mas então, vem a pergunta: quem é o dono da informação numa automação de processos? Vamos primeiramente analisar 2 dos cenários mais frequentes de automação de processos.

1) Automação de processos que originalmente eram executados em papel, pouco/nenhum apoio de sistemas:

Neste caso, a organização não dispõe de sistemas para apoiar a execução destes processos, ou dispõe de sistemas que atendem apenas a uma parte do processo.

Normalmente são criados formulários eletrônicos que são responsáveis pelo início e execução do processo (ex: num processo de solicitação de viagem, o formulário inicial conteria os dados da viagem desejada pelo usuário). Durante a execução destes processos, usualmente existem pontos de integração com sistemas existentes na empresa (ex: sistema financeiro, contábil, etc). Neste cenário, eventualmente o BPMS poderá servir como repositório de algumas informações, normalmente sendo o repositório das “solicitações” em si (ex: solicitações de compra, solicitações de viagem, etc), e não dos dados de negócio de fato. Mas na experiência que temos, com bastante frequência as informações originadas/geradas pelos processos automatizados são enviadas para gravação em sistemas existentes da organização, como por exemplo ERP ou sistemas legados, que são de fato os responsáveis por armazenar e manter aquelas informações.

2) Automação de processos com apoio de sistemas:

Neste caso já existe um ou mais sistemas que apoiam a execução de parte ou todo um processo, mas o fluxo de execução das atividades não é orquestrado e controlado, ou seja, os sistemas e usuários responsáveis por aquele processo estão desconectados uns dos outros, o que gera então a necessidade de automação.

Neste cenário, com frequência as atividades do processo automatizado são executadas nos próprios sistemas, cabendo ao processo automatizado basicamente controlar o início e término das atividades, e a comunidação dos envolvidos nos pontos onde há necessidade de alguma intervenção humana. Assim, as atividades na lista de trabalho meramente direcionam os usuários para os sistemas onde estes deverão efetivamente realizar as atividades. Outro cenário bastante frequente é a busca, pelo processo automatizado, de informações armazenadas em sistemas existentes, de forma a apoiar os usuários na execução dos processos. E, como não poderia deixar de ser, neste cenário é ainda mais frequente e usual a necessidade de, em diversos pontos do processo automatizado, enviar as informações geradas durante a execução do processo para armazenamento em sistemas existentes.

Com base nos cenários visto acima, retomamos então a pergunta. Quem é realmente o dono da informação numa automação de processos?

Note que, em qualquer um dos casos que citamos até agora, normalmente o BPMS não é a fonte principal dos dados sendo manipulados, mas atua principalmente como integrador destas informações, buscando e enviando dados para outros sistemas durante a execução dos processos.

Podemos concluir, então, que a implementação de um processo automatizado de forma nenhuma significa a descontinuidade dos sistemas existentes!

BPM e Workflow – Qual a diferença?

Com o crescimento da temática de Gestão por Processos nas organizações, muitas pessoas tem dúvida de quais seriam as diferenças entre BPM e Workflow. Primeiramente, vamos conceituar cada um destes termos:

  • Workflow é um tipo de tecnologia para automação do fluxo de atividades de um processo, tecnologia esta que existe há varios anos. Com uma ferramenta de workflow, é possível coordenar a execução de um processo de negócio através da execução ordenada de tarefas, que podem ser de responsabilidade de pessoas ou de sistemas.
  • BPM (Business Process Managament), segundo a definição do BPM CBOK, é “uma abordagem disciplinada para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio automatizados ou não para alcançar os resultados pretentidos consistentes e alinhados com as metas estratégicas de uma organização“.

Podemos identificar de imediato que BPM tem uma abordagem e uma área de atuação muito mais abrangente que Worklow. No que se refere a tecnologia, a adoção de BPM geralmente inclui, por exemplo, a utilização de produtos de software para modelagem, análise e desenho de processos (BPA – Business Process Analysis), automação do fluxo de trabalho (Workflow), motores de regras de negócio (BRM – Business Rules Managament), monitoramento de processos de negócio (BAM – Business Activity Monitoring), Gerenciamento de Conteúdo (GED/ECM) e gerenciamento de repositório de processos.

Visão geral - Tecnologia de apoio a BPM

BPM também é uma disciplina, que orienta a empresa a conduzir sua operação numa abordagem horizontal, com o foco voltado aos seus processos de negócio. Desta forma, é perfeitamente possível que uma organização adote BPM e não precise, necessariamente, implementar ou utilizar uma ferramenta de automação ou BPMS (Business Process Managament System), embora o apoio assistido de tecnologia seja cada vez mais importante para a implementação bem sucedida de BPM nas organizações. Não podemos deixar de mencionar que BPM envolve também mudanças na cultura e valores da organização, indo assim muito além de uma simples plataforma tecnológica para apoio a execução dos processos.

Workflow, por sua vez, refere-se apenas a tecnologia que implementa a automação de fluxos de trabalho. Projetos de implementação de workflow normalmente costumam ser ações mais pontuais, específicas e departamentais dentro da organização, sendo frequentemente tentativas de melhoria de processo problemáticos, com foco por exemplo em diminuição de prazo e maior controle das atividades, e na maioria das vezes sem uma abordagem estruturada e planejada de melhoria de processos embasando o trabalho.

Nota-se que as organizações frequentemente utilizam ferramentas de workflow para automatizar processos de apoio (ex: processo de solicitação de viagem), e não processos primários ou core, o que também é um fator relevante a destacar. Também nota-se que as organizações usualmente automatizam processos numa ferramenta de workflow sem passar por uma fase de análise e desenho prévio daqueles processos, ou seja, sem avaliar as necessidades de melhoria e gerar o modelo TO-BE, o que pode levar a resultados pouco satisfatórios.

Com base no que detalhamos até agora, gostaríamos de concluir este artigo alertando para uma certa confusão que existe hoje no mercado, onde temos ferramentas de Workflow que autointitulam-se como “plataforma de BPM” ou “BPMS”, embora na prática implementem apenas uma parte dos conceitos relacionados a BPM (normalmente a automação de fluxo de trabalho, e eventualmente o gerenciamento de documentos).

É importante ter claro que se uma empresa está apenas automatizando fluxos de trabalho utilizando uma ferramenta de Workflow, sem uma abordagem estruturada para gerenciamento e monitoramento de processos de negócios que embase este trabalho, ela não está implementando BPM, mas apenas automatizando seus fluxos de trabalho.