Definindo o Escopo de Modelagem de um Processo de negócio

Uma definição essencial no início de um projeto de modelagem é o escopo do processo que será modelado. A definição clara dos limites em que será trabalhado o processo é um fator chave para a realização de qualquer projeto de modelagem.

Tomando como exemplo um processo de venda de uma fábrica de móveis: num primeiro momento, poderíamos imaginar que o escopo de um processo desta natureza  inicia com a chegada do cliente na loja e termina com o pagamento:

Contudo, extrapolando um pouco as atividades que se seguem ao pagamento, poderíamos questionar se não deveriam também estar contempladas as etapas de:

  • Entrega dos móveis;
  • Montagem, quando necessário;
  • Acompanhamento dos pagamentos parcelados; ou
  • Acompanhamento da garantia.

Onde efetivamente deveria começar e finalizar este processo?
Não existe uma resposta certa para esta pergunta, pois o escopo de um projeto de modelagem depende de diversos fatores, estando entre eles:

1. Os Resultados esperados do projeto: A motivação inicial pela realização do projeto é um fator primordial na definição do seu escopo. No exemplo acima, a modelagem pode ter sido demandada pela equipe comercial que tem como meta abrir mais 50 lojas nos próximos 12 meses e que precisa, portanto, unificar o processo de atendimento. Ou por uma necessidade desta mesma equipe em unificar o atendimento das suas lojas, tendo em vista que algumas unidades possuem um desempenho espetacular e em outras deixam muito a desejar. Nestes casos, a primeira versão do processo atende as expectativas.
Porém, digamos que a motivação seja garantir a melhor experiência de atendimento ao cliente. Neste caso, a empresa pode estar preocupada com o fato que o atendimento fora da loja, nas etapas de transporte e montagem, são os momentos em que ela menos tem condições de garantir a sua qualidade, criando assim uma necessidade de maior gestão e controle.

2. A Equipe envolvida no projeto: A modelagem de processos é uma atividade de natureza interfuncional que necessita para o seu sucesso da cooperação de todas as áreas envolvidas no processo. Desta forma, a amplitude do escopo da modelagem deve ser norteada também pelas áreas que estão engajadas no projeto de modelagem. A ampliação do escopo exigirá a sensibilização das novas áreas de negócio que serão afetadas.

3. As Expectativas de Prazo e Custos do Projeto: As variáveis clássicas de custo, prazo e escopo estão interligadas desde a concepção do projeto, e a mudança em uma delas tende a gerar reflexos nas demais. Desta forma, a reflexão sobre o escopo do processo deve levar em conta as expectativas de prazos e custos previstos para o projeto, de modo a garantir que a alteração não impactará a sua viabilidade.

Respeitando estes quesitos, podemos avaliar se determinadas partes do processo, devido às suas características, não poderiam ser modeladas separadamente. São exemplos destas situações as etapas de um processo que:

  • Aparentam ser mais independentes em relação a outras. Etapas com estas características costumam tem um bom nível de desacoplamento do restante. Por exemplo, uma etapa final de pesquisa de satisfação do cliente tende a ser a menos acoplada ao processo do que a etapa de pagamento, e poderia ser analisada separadamente.
  • Se repetem em outros processos. Por exemplo, o serviço de transportes pode ser necessário tanto num processo de venda como num processo de manutenção ou devolução do móvel adquirido.
  • São claramente de apoio, sem visibilidade para o cliente final.
  • Não podem retroagir a um ponto anterior do mesmo processo. Por exemplo, no nosso processo de vendas, não é razoável pensarmos que no momento em que o cliente está recebendo o montador do seu móvel ele possa voltar para a etapa de cadastro realizada antes da compra. Isso demonstra que a etapa de montagem e a etapa de cadastro possuem uma certa independência que permite que elas sejam analisadas separadamente.

Neste momento, algumas perguntas chaves muito comuns no início de um projeto de modelagem também podem ser fundamentais para definirmos o escopo mínimo e máximo de um processo, tais como:

  • Quem é o cliente do processo? Ele será atendido com o escopo que está sendo proposto?
  • Quem são os seus fornecedores? No escopo proposto eles interagirão com o processo?
  • Quais são as entradas e saídas do processo? As entradas previstas serão utilizadas no escopo proposto? Este escopo entregará as saídas esperadas?
  • Quais são os indicadores principais? No escopo proposto estes indicadores poderão ser medidos?

Finalmente, é importante que o escopo previsto para o projeto contemple alguns cuidados de modo a evitar que o mesmo não se limite a um escopo tão pequeno que não seja contributivo ou tão grande que se torne inviável. Desta forma, sugerimos sempre uma dose de atenção para que:

  • O processo não se limite a uma só área ou departamento, ou seja, preserve suas características interfuncionais. Processos departamentais tendem a não apresentar todos os benefícios da gestão por processos como aqueles transversais à organização.
  • Se evitem projetos que exigem 6, 10 ou 12 meses de trabalho. Projetos desta amplitude tende a já ter o seu resultado desatualizado ao seu final, além de gerar desmotivação devido a demora na entrega dos seus resultados.
  • No caso do processo ser muito extenso, seja verificada a possibilidade de que o seu escopo seja dividido em dois ou mais projetos, de modo a garantir entregas frequentes.
  • Se lembre que, quanto maior o escopo, mais complexa a sua gestão.
  • Se esteja, contudo, sempre atento para evitar que uma divisão excessiva que sacrifique a visão ponta a ponta do processo.

Finalizando, não podemos deixar de ressaltar que, tão importante quanto à definição do escopo é que estes limites fiquem sempre muito claros para os stakeholders e para as áreas de negócio. A falta de clareza sobre o escopo a ser trabalhado tende a gerar desmotivação e retrabalho nas reuniões de levantamento do processo.

Se você quiser saber um pouco mais sobre este assunto, conheça o nosso curso de modelagem de processo, http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

Evitando as armadilhas mais comuns em projetos de otimização de processos

Projetos de otimização de processos consistem em realizar o trabalho de ajustar um processo buscando sua melhoria. De acordo com Reint Jan Holterman, autor do white paper “Five Common Pitfalls in Process Optimization, And how to avoid them“, os esforços de otimização devem “reforçar as atividades essenciais da empresa, produzindo melhores produtos e serviços, em um período mais curto de tempo, a um custo mais baixo e com mínimo de impacto ambiental”.

A otimização de processos requer, então, que se possa produzir uma visão de futuro melhor para a execução de um processo olhando para a forma como ele acontece atualmente e seu histórico (lições aprendidas). Envolve atividades de modelagem, análise e redesenho do processo, e apesar de este ciclo já se constituir em uma prática comum em organizações que buscam a melhoria de processos através das práticas de BPM, estima-se que 60 a 70% de todos os processos de otimização não produzam resultados satisfatórios (leia mais aqui: http://esopsfables.wordpress.com/2012/02/29/why-process-improvement-projects-fail/).

Em seu white paper, Holterman explora as cinco falhas mais comuns, responsáveis pelos problemas neste tipo de projeto:

1. Falta de clareza sobre onde começa e onde termina o trabalho

Muitos projetos são iniciados com uma declaração “vamos otimizar o processo tal”, mas não está claro para a equipe por onde começar e até onde se vai.

A falta de clareza sobre o início e fim do projeto leva a uma sequência de armadilhas que resultam em um processo desestruturado e interminável.

Em um projeto de otimização de processos é fundamental compreender a situação atual, o status quo do processo. Quem está envolvido, quais são as entradas e saídas, quais são os limites do escopo deste processo, qual é o tempo que o processo leva atualmente para ser executado, que exceções comumente levam a resultados diferentes e com que frequência acontecem, são questões iniciais que precisam ser feitas antes mesmo de se iniciar alguma ação de otimização.

Conhecer bem a situação atual do processo é tão importante quanto ter claro onde se quer chegar. É preciso que todos os participantes tenham uma visão clara de que melhoria deseja-se atingir com o projeto, se é um ganho de produtividade, de redução de tempo, de redução de custos, e que parâmetros definirão o atingimento do resultado esperado.

2. Usar indicadores (KPIs) inadequados

Os indicadores de performance (KPIs) são as referências que apontam a direção para a linha de chegada.

Indicadores mal definidos levarão a equipe a sair do curso, já que apontam para a direção errada.

Sintomas comuns de um KPIs mal definido:

  • não está relacionado ou é impactado muito levianamente pelo processo de negócio;
  • pode gerar interpretações diferentes;
  • não é impactado apenas pelo processo, mas também por  fatores externos;
  • não está relacionado de alguma forma aos objetivos estratégicos da organização, de forma que mesmo que o processo obtenha alguma otimização, não há garantia que produzirá algum resultado melhorado para a empresa.

3. Falta de apoio do dono do processo e da alta gestão

O Dono do Processo (Processo Owner) é o responsável pelo desempenho do processo de negócio, e espera-se que seja o maior interessado no sucesso de um projeto de otimização, já que afetará diretamente os resultados do produto ou serviço gerado pelas atividades do processo de negócio.

Consequentemente, sem um Dono do Processo que se importe em acompanhar o trabalho de otimização do seu processo (seja por falta de interesse ou de tempo para apoiar o trabalho), não se pode esperar grandes resultados do projeto.

Também o apoio da alta gestão da empresa ao projeto de otimização é essencial para o sucesso da iniciativa, de forma a garantir o envolvimento e a disponibilidade dos recursos necessários às ações de melhoria.

4. Não adotar as mudanças no processo

É da natureza humana apresentar resistência a mudanças – mudar envolve sair da zona de conforto, aquela em que conhecemos e controlamos como as coisas funcionam.

Por este motivo, comunicar bem e garantir que os envolvidos tenham tempo suficiente para compreender e aceitar as mudanças propostas é fundamental para o sucesso da implantação de otimizações no processo. As pessoas precisam entender por quê as mudanças estão sendo feitas para assimilar os benefícios a serem obtidos e efetivamente adotá-las.

5. Displicência na execução

Holterman aponta que em muitas organizações, os projetos de otimização acabam se perdendo em um perpétuo estudo e desgastante levantamento de informações, colecionando e analisando todo tipo de dado que se pode coletar acerca do processo na tentativa de representá-lo da forma mais apurada, às vezes envolvendo até mesmo coleta de informações de outros processos que nem estão diretamente relacionados ao escopo de otimização prevista no projeto. Mas dispender toda energia em gerar estatísticas complexas e painéis de monitoramento não trarão resultados práticos de otimização.
Controlar a execução, garantindo que as otimizações definidas sejam efetivamente executadas como planejadas, são um dos grandes desafios de um projeto de otimização e podem encontrar suporte na implementação do processo em um BPMS (Business Process Management Sustem).  Para mais informações do que esperar da implementação de um processo em um BPMS, leia nosso post “Benefícios da Automação de Processos“.

E veja no artigo “Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!” que avaliações recomendamos antes da decisão por automatizar um processo de negócio.

 

Vale a Pena Mapear Todos os Processos da Organização?

Um dos temas mais polêmicos quando falamos em projetos de modelagem de processos são os projetos cujo objetivo é mapear todos os processos da organização. Projetos desta natureza exigem um envolvimento global de toda a organização, pois dada a natureza dos processos de negócio, toda as áreas e papéis existentes terão que contribuir para o sucesso deste trabalho.

As empresas possuem dentro da sua operação algumas centenas de processos de negócio relevantes. O esforço para mapear tantos processos é enorme, exigindo via de regra algumas milhares de horas de trabalho.

Este esforço não se deve tanto à complexidade técnica do trabalho que tem a ser realizado, mas sim ao volume de processos que devem ser tratados. Como consequência, o projeto acaba envolvendo um número elevado de analistas de processos, muitas vezes até um número maior do que a empresa possui nos seus quadros, fazendo assim da terceirização um meio para viabilizar o trabalho.

Apesar deste número elevado de horas, este tipo de trabalho traz como resultado uma descrição em alto nível destes processos de negócio. Isso porque, se estes consultores precisassem detalhar a nível de procedimento em cada um dos processos, o esforço cresceria exponencialmente, tornando o projeto impraticável. Desta forma, o resultado de tamanho esforço é uma documentação ampla e organizada que mostra a estrutura e hierarquia de cada processo, mas sem entrar em detalhes sobre como são executados os procedimentos de suas atividades.

Com tantas pessoas envolvidas e tanto trabalho a cumprir, projetos desta natureza acabam sendo projetos caros. Não só pelas milhares de horas dos analistas de processos, mas também (e principalmente) pelo tempo demandado das áreas de negócio e por toda mobilização que acaba se fazendo necessária.

Tal mobilização acaba gerando enorme expectativa dentro da empresa: todos esperam que, ao final deste trabalho, a empresa terá um repositório com todos os seus processos e suas respectivas atividades. E é justamente na viabilidade em atender estas expectativas que está o maior desafio.

Processos de negócio são elementos vivos dentro das organizações: diariamente, surgem novas necessidades ou requisitos que exigem a sua adaptação. Quando os processos são modelados ou redesenhados de forma gradativa e planejada, a implantação de uma política de governança que garanta a atualização desta base torna-se natural. Os envolvidos nestes processos possivelmente participaram de toda uma estratégia de mobilização e discussão sobre os processos, sendo assim mais fácil obter o seu comprometimento. Contudo, quando todos os processos da organização são mapeados em poucos meses numa estratégia de documentação em série, a manutenção desta governança e a criação deste comprometimento torna-se muito mais difícil.

Desta forma, a pergunta que fica é: “Como fazer para garantir que, ao final do projeto, toda e qualquer MUDANÇA em QUALQUER PROCESSO será corretamente identificada, analisada e documentada no repositório de processos?

A viabilidade da organização em oferecer esta garantia acaba se tornando o ponto mais crítico de sucesso, uma vez que:

  1. Se a empresa não conseguir manter a base de processos atualizada, em pouco tempo existirão inúmeros processos desatualizados;
  2. Se houverem processos desatualizados, as áreas de negócio começarão a perceber que o repositório de processos não serve como base de consulta;
  3. Se o repositório não servir como repositório de consultas, ele deixará de ser utilizado.
  4. Se ele deixar de ser utilizado, toda a iniciativa cairá em descrédito.

É claro que projetos desta natureza podem trazer inúmeros benefícios, e que as empresas terminando estes projetos se conhecem muito melhor do que quando começaram. Contudo, é importante que as organizações tenham em mente que existe um limite de detalhamento que é passível de manutenção, e que elas não devem investir na criação de uma documentação que elas não conseguirão manter.

 


Conheça mais sobre o Ciclo de Vida de Processos e Projetos de BPM e desenvolva seus conhecimentos nas atividades de mapeamento, análise e redesenho de processos com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

BPMN: demonstrando a continuidade de processos

Uma das principais vantagens de BPMN pode também ser o seu calcanhar de aquiles: embora robusta e flexível, Business Process Modeling Notation, como diz o nome, é apenas uma notação para representar de forma padronizada aspectos lógicos de um processo de negócio. Seu objetivo não é propor uma metodologia de análise ou de documentação de processos, mas uma linguagem comum que possa ser interpretada igualmente por todos os envolvidos.

A flexibilidade da notação em permitir que um mesmo cenário de negócio possa ser modelado de formas diferentes – com alguma eventual sutil diferença em sua interpretação, possibilita que o seu uso possa ser implementado conforme for mais conveniente para a organização. Por outro lado, implica em um problema comum a todos que iniciam a sua utilização: a ausência de uma metodologia ou padrão de uso.

Por isso, é comum que profissionais que utilizam o padrão eEPC da metodologia ARIS encontrem alguma dificuldade em traçar um paralelo claro de uso entre as duas notações.

Uma das dúvidas mais comuns relacionadas à especificação de processos com uma ou outra notação está na forma como se representa a conexão entre processos.

BPMN oferece diferentes formas de se representar a continuidade de processos. Cabe aos analistas identificar qual a forma mais apropriada para atender as necessidades de documentação do seu processo – que pode (ou deve!) ser guiada por uma abordagem padrão da organização.

Neste artigo, exploramos duas formas de representar a continuidade de processos com BPMN.

 I. Acionamento por comunicação explícita entre processos

Uma das formas de se demonstrar a comunicação entre processos com BPMN é através de acionamento explícito, em que o término de um fluxo invoca diretamente o fluxo de um outro processo. Isto é feito através da diagramação em pools. Nesta notação, cada processo é disposto em uma pool. Como já vimos em artigo anterior, a comunicação entre pools acontece sempre através de message flow. Por isso, quando um processo em uma pool termina já planejando iniciar outro processo, isto precisa ser feito com eventos do tipo message.

O exemplo abaixo é o que permite um paralelo mais próximo desse comportamento com um modelo eEPC. Quando o Processo de Inscrição em Eventos termina com a identificação de que precisa iniciar o Processo de Viagens Corporativas, o evento de fim é representado como um evento de end message event, e um conector de message flow realiza a transição para a pool daquele processo. O diagrama abaixo apresenta essa representação usando uma pool black box para representar o processo de Viagens.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool black box. A sua lógica poderia estar representada em detalhes em um outro diagrama.

Se for interesse do processo visualizar mais claramente a interação entre os dois fluxos, pode-se usar a representação abaixo, que demonstra como um fluxo inicia o outro e quais atividades se seguem depois que a participação no evento foi autorizada. A diferença entre o modelo acima e o abaixo é que na representação acima o Processo de Viagens Corporativas está em uma pool black box, enquanto no diagrama abaixo está em uma pool white box.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool white box, possibilitando uma visão completa da sequênia de atividades em nível operacional.

A principal vantagem desta abordagem é que fica explícito no diagrama que um processo de negócio maior tem continuidade através dos seus processos, porém causa um certo nível de dependência entre os processos.

 II.Orquestração de Processos

Uma segunda abordagem é utilizar um diagrama de orquestração, que em um nível um pouco mais alto, fica responsável por controlar o término de um determinado processo e identificar que outro deve ser iniciado na sequência. Esta abordagem baseia-se no conceito amplo de subprocessos em BPMN.

Para BPMN, não existe uma definição de arquitetura de processos, ou de estruturação de níveis. Cada organização deve orientar como vê a empresa e definir seu próprio mapa de processos. Para BPMN, as coisas são bem mais simples. Uma atividade, em um fluxo de trabalho, pode ser:

  • Uma tarefa (um conjunto de procedimentos que compoem uma atividade realizada por uma pessoa ou grupo de pessoas, em seu menor nível de granularidade);
    ou
  • Um subprocesso, que nada mais é do que uma abstração de que naquela etapa, um conjunto definido de atividades representadas em um fluxo (um processo!) acontecerão. Quando este fluxo é concluído, então a atividade de subprocesso é encerrada e o fluxo no qual ela se encontra dá seguimento.

Assim, uma forma de demonstrar que o término de um processo dará início a um outro processo, é representá-los como subprocessos de um processo orquestrador, que dá a sequência entre eles, desta forma:

Processo de Participação em Eventos visto fim-a-fim, através da orquestração sequenciada de processos da organização.

Neste cenário, os diagramas dos processos orquestdados não precisam preocupar-se com regras que influenciarão no próximo processo (como identificar se há ou não viagem para a participação no evento). Esta lógica pode ser atribuída ao processo que faz a orquestração:

Processo de Participação em Eventos fim a fim, agora com alguma lógica de roteamento dos processos envolvidos.

Note que neste caso, os eventos de início e fim são do tipo none. Isto porque no caso de processo de Viagens, não é mais um evento de comunicação entre processos que definirá o seu início, e sim o processo orquestrador.

Nesta abordagem o processo de inscrição de eventos pode ser simplificado.

Nesta abordagem o Processo de Viagens Corporativas também pode ser simplificado, tornando-o otimizado para reuso por outros processos de negócio.

As vantagens desta abordagem são:

  • O diagrama orquestrador permite uma visão simples e clara de um processo de negócio orquestrado fim-a-fim. Isto torna-se um pouco mais difícil no cenário de acionamento por comunicação explícita, uma vez que torna-se necessário navegar de um processo para outro para chegar-se ao fim e compreender o contexto geral do processo de negócio.
  • Os processos são independentes da lógica de roteamento da orquestração, tornando-os reusáveis por outros processos de negócio (por exemplo: o processo de viagens corporativas poderia também ser usado em um processo de Execução de Projeto, Apresentação de Treinamentos, etc)
  • É possível criar condições diferentes que levem a orquestração a executar ou não um processo após a realização de outro (como foi feito para definir a execução do processo de viagens e de reembolso), e estas regras podem ser mudadas sem impactar na lógica dos processos adjacentes.

Existem também outras formas de possibilitar a representação de sequência, como uso de eventos de signal, por exemplo. Estas duas entretanto são as mais comuns e que tornam mais visível esta comunicação. O critério de definição de qual abordagem utilizar passa por uma avaliação da organização sobre como manterá todos os seus diagramas de processos reunidos e organizados, através do estabelecimento de uma arquitetura de processos.

Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários

No artigo anterior iniciamos o estudo dos eventos, detalhando os principais tipos de gatilhos para eventos de início e fim de processo.

O evento intermediário (Intermediate event) sinaliza um ponto no decorrer do processo no qual é previsto que um fato irá ocorrer.

Eventos intermediários podem ser tanto do tipo catch (aguardam a ocorrência do fato para que o processo continue) quando do tipo throw (geram a ocorrência do fato e dão continuidade ao processo).

Em geral os eventos intermediários são conectados ao processo através de conectores de fluxo de sequência, dando o contexto de que ocorrem durante o processo. Entretanto, um evento intermediário também pode ser definido para ocorrer durante uma tarefa tarefa específica. Neste caso, o evento intermediário é anexado à borda da atividade, como mostrado em alguns exemplos abaixo.

Os tipos de evento intermediário mais comuns são:

Tempo ou Prazo (Timer)
Utilizado para representar um fato relacionado a uma condição temporal, como uma data específica (ex. 01 de janeiro), uma data relativa (próxima terça-feira), um intervalo de tempo (em sete dias) ou uma situação de espera de tempo.

O evento de timer é simbolizado por um relógio.

Quando utilizado no fluxo do processo, o evento intermediário de timer representa que o processo deverá parar naquele ponto do processo e aguardar que a condição de tempo se torne verdadeira.

Neste exemplo, quando a tarefa “Preparar viagem” for finalizada, o processo realizará uma pausa aguardando a data de início da viagem. Só então o processo continuará, iniciando a tarefa “Realizar viagem”.

Quando utilizado na borda de uma atividade, o evento intermediário de timer representa que que, enquanto a atividade estiver em execução, o evento poderá acontecer, e neste caso, o fluxo desenhado a partir do evento será executado. Neste caso, o evento intermediário poderá ser de dois tipos:

Timer interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, ela será interrompida, e o fluxo seguirá pelo conector que se origina no evento.
A borda do evento é dupla e lisa.
No exemplo ao lado, se a atividade “Confirmar recebimento de mercadorias” for concluída  antes da data de entrega prevista, o processo seguirá sua execução pelo fluxo normal do processo. Entretanto, se a data de entrega prevista for atingida e o recebimento das mercadorias não tiver sido confirmado, a tarefa é automaticamente cancelada e o fluxo que sai do evento de timer é disparado, dando início à atividade “Cancelar o pedido”. A atividade de “Confirmar recebimento de mercadorias” não poderá mais ser realizada pois foi interrompida.

 

Timer non-interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, um fluxo paralelo será iniciado a partir do conector que se origina no evento, mas a tarefa permanece aguardando a sua execução.
A borda do evento é dupla e tracejada.
No exemplo ao lado, se o após dois dias úteis a tarefa “Avaliar pedido” ainda não tiver sido finalizada, o fluxo iniciado no evento é disparado, iniciando a tarefa “Receber aviso de atraso na avaliação”. A atividade de avaliar pedido, entretanto, poderá ser realizada normalmente, dando sequência ao fluxo normal do processo. Se a tarefa “Avaliar pedido” for finalizada antes da ocorrência dos dois dias úteis, então a atividade “Receber aviso de atraso na avaliação” não acontecerá.

 

Condicional (Conditional)
Utilizado para representar um fato relacionado a uma condição de negócio, pausando o processo até que ela se torne verdadeira.

No exemplo ao lado, ações são compradas e então o processo aguarda até que a condição “Valor de venda atingido” se torne verdadeira, dando continuidade ao processo e iniciando a tarefa “Vender ações”.

O evento do tipo conditional também pode ser conectado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será acionado quando a condição de negócio associada se torne verdadeira.

 

Mensagem (Message)
Eventos intermediários de tipo message são utilizados para demonstrar um ponto do processo onde ocorre uma comunicação com um outro processo ou agente externo.

O evento de “throw message” tem como símbolo um envelope preto e sinaliza o envio da comunicação, enquanto o evento do tipo “catch message” tem como símbolo um envelope branco e sinaliza o recebimento da mesma.

No exemplo acima, o Processo de Logística de Treinamentos prevê uma atividade para “Alugar sala de treinamento”. Após alugar a sala, o processo aguarda uma “Comunicação do número de Participantes”. Quando esta comunicação for recebida, a próxima atividade poderá ser iniciada, providenciando cadeiras e mesas para os participantes do treinamento cujas inscrições foram confirmadas.

Este exemplo apresenta o Processo de Inscrições de Treinamento, no qual há uma tarefa para receber as fichas de inscrição e então uma atividade para “Verificar inscrições pagas”. Quando as inscrições pagas forem verificadas, o processo poderá comunicar o número de participantes que estão inscritos, enviando uma mensagem (que será recebida no processo demonstrado anteriormente, no evento com o mesmo nome). Após, o processo segue, iniciando a tarefa de “Providenciar impressão dos certificados”.

A identificação de que a mensagem enviada por um processo é a mesma recebida em outro processo deve ser explicitada utilizando-se a mesma descrição para o elemento.

É possível ainda demonstrar visualmente esta comunicação, colocando-se os dois processos em um mesmo diagrama BPMN e apresentando como esta mensagem flui de um processo para o outro. Neste caso, utiliza-se um conector especial para demonstrar essa ligação entre processos através da troca de mensagens (envio e recebimento): o conector de fluxo de mensagem (message flow).

O conector de fluxo de mensagem pode ser usado apenas para conectar elementos de envio e recebimento de mensagem, e caracteriza-se por uma linha tracejada com uma seta vazada apontando para o destino da mensagem.

É importante ressaltar que para o BPMN, uma comunicação é realizada sempre para fora do processo, nunca entre eventos de mensagem de um mesmo processo.

O evento do tipo mensagem também pode ser utilizado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será sempre “catch”, aguardando a chegada de uma mensagem, e será acionado se a mensagem for recebida enquanto a atividade estiver sendo executada.

Ligação (Link)
Eventos intermediários de link representam uma ligação entre pontos distantes de um mesmo do processo.

Este elemento é utilizado frequentemente em processos cujo número de atividades é muito grande e há pontos do processo que estão visualmente distantes ou bloqueados. Assim, para evitar a sobreposição de conectores de fluxo de sequência, pode-se utilizar este evento, criando uma “ponte virtual” entre pontas do fluxo do processo.

O evento de “throw” link tem como símbolo uma seta preta e sinaliza a ponta de origem da ligação, enquando o evento do tipo “catch” tem como símbolo uma seta branca e sinaliza o destino da mesma.

O exemplo acima apresenta um exemplo de uso de eventos de ligação (link). Observe que há dois eventos de ligação com o mesmo nome: “Continuar negociação”. O primeiro tem a seta preta, indicando a origem da ligação, e o segundo a seta branca, indicando o destino da ligação. Com isso, a leitura que se faz deste diagrama é de que após a realização da atividade “Verificar condições de férias” o processo dá sequência ao fluxo iniciando a tarefa “Avaliar solicitação de férias”.

Para entender melhor o uso de eventos de mensagem e link, leia também estes artigos:

No próximo artigo, um elemento fundamental para a abstação de conjuntos de tarefas na estruturação de diagramas de processos com níveis de profundidade e granularidade diferentes: os subprocessos.


Confira todos os artigos deste guia de BPMN Nível 1:

Caso de Sucesso – Aumento da produtividade e efetividade nos negócios do SICREDI com a adoção de SOA e BPM

Marcio Lermen, gerente de tecnologia do Sicredi

Durante o Oracle Open World 2012 em São Paulo, Marcio Lermen, gerente de tecnologia do Sicredi, apresentou como caso de sucesso a adoção da suíte de SOA e BPM da Oracle para a automação dos processos da organização e o uso do Oracle Exalogic como plataforma de hardware e software para dar alta performance a esta suíte.

De acordo com Marcio, a escolha destas tecnologias foi feita dado o desafio que o Sicredi tinha quanto a decisões e processos manuais em um cenário de negócio complexo, em que os processos estão distribuídos entre as cooperativas do sistema. A adoção destas tecnologias viabilizou o redesenho e automação dos processos, apresentando excelentes ganhos no controle da execução dos processos.

Dentre os benefícios obtidos com esta adoção, foi mencionado o ganho de tempo na execução de um processo. Em alguns casos, a automação de um processo (que antes era ad-hoc e feito via envio de e-mails e trocas de telefonemas) fez com que o ciclo de vida do mesmo, que costumava levar vários dias, pudesse ser realizado no mesmo dia. Além disto, foi mencionado o ganho de desempenho com o uso do Oracle Exalogic, que chegou na ordem de 4 a 6 vezes. Segundo Márcio, para conseguir esta performance foi preciso que todos os serviços envolvidos estivessem dentro do Exalogic.

Como pontos importantes apresentados por ele, foram citados os seguintes fatores:

  • o mapeamento e desenho do processo as-is e to-be antes da automação do mesmo;
  • a definição dos pontos onde serão gerados indicadores (que serão enviados ao BAM na execução) durante a definição do processo;
  • a quebra do processo principal em subprocessos menores, inclusive para facilitar o controle de versão e o desenvolvimento;
  • governança SOA, contendo uma arquitetura bem definida, além da necessidade de uma garantia de que a mesma será utilizada dentro dos projetos.

Foram mostrados alguns exemplos de processos criados utilizando Oracle BPM, sendo que muitos deles foram mapeados e criados em parceria com a iProcess.

É um orgulho para nós poder fazer parte de cases de sucesso em BPM do sicredi.

Estimando a duração de processos II – processos não lineares

Em um artigo anterior sobre a estimativa da duração de processos, concluímos que a duração do processo é a soma da duração das suas atividades e dos tempos de espera entre elas. Esta fórmula se aplica para processos em que todas as atividades acontecem de forma linear. Entretanto, muitos processos de negócio precisam prever no seu fluxo de atividades caminhos alternativos ou paralelos, o que certamente agrega complexidade a esta avaliação.

Este artigo visa buscar um aprofundamento um pouco maior sobre como estimar a duração de processos nestes casos. Está longe de ser uma referência que cubra todos os cenários possíveis, mas o publicamos com a expectativa de apoiar o processo de compreensão sobre a variabilidade da duração de processos.

Alguns dos principais aspectos de variação em tempos de processos que precisam ser considerados em uma análise de duração são:

  • A ocorrência de fluxos paralelos
  • A ocorrência de fluxos alternativos
  • Repetições (loops)
  • Paradas por espera de eventos externos

 I. Fluxos paralelos
A duração de um conjunto de atividades executadas em fluxos paralelos não pode ser estimada com a simples soma das suas durações e os handoffs, uma vez que elas ocorrem paralelamente, ou seja, podem iniciar ao mesmo tempo. Nestas situações, é necessário estimar-se a duração de cada fluxo paralelo. A duração deste conjunto de atividades é dada pela duração do caminho com a duração maior (já que as atividades dos outros fluxos são executadas dentro deste período).

 II. Fluxos alternativos
A duração de um processo que apresenta a possibilidade de fluxos alternativos terá uma duração variável. A duração do processo poderá variar para mais ou para menos, de acordo com o fluxo que a instância do processo seguir quando o mesmo for executado.

 III. Repetições (loops)
A duração de um processo que apresenta atividades passíveis de repetição também irá variar, com acréscimo da duração desta atividade tantas vezes quantas ela se repetir.

IV. Eventos externos
Processos que dependam da ocorrência de eventos externos para que parte de suas atividades sejam executadas também podem apresentar variações no seu resultado. Neste caso, a variação dependerá do tempo que o processo levará para receber o retorno sobre a ocorrência externa (como aguardar a resposta de um cliente ou fornecedor, esperar um determinado horário programado, etc) para cada instância.

Ao calcular-se a duração de processos, é importante considerar que podem existir cenários em que há, inclusive, a combinação destes aspectos, o que requer uma análise ainda mais cuidadosa.

Partindo -se do entendimento de como estes aspectos podem promover variação do tempo do processo além da simples soma de duração de atividades e esperas em handoffs, podemos perceber que, nestes casos, o processo poderá ter uma estimativa de duração variável, de acordo com os caminhos que cada instância do processo poderá seguir.

Assim, cabe ao analista definir que critério utilizará para identificar qual, afinal, é a duração do processo:

  • Estimativa do caminho crítico (o caminho do processo que executa todas as atividades críticas para o atingimento do bom resultado do processo).
  • Estimativa do caminho padrão (o caminho que é executado no processo na maior parte das vezes).
  • Estimativa do caminho feliz (o caminho no qual o processos é executado no seu melhor caso, com o mínimo ou nenhuma exceção do negócio).
  • Estimativa do melhor caso (a duração mínima esperada da execução do processo).
  • Estimativa do pior caso (quando todas as exceções de negócio possíveis podem ocorrer, gerando o resultado mais negativo possível).

Em um processo não-linear, cada uma destas opções irá possivelmente apresentar um resultado diferente no cálculo da duração.

Técnicas de diagramas de precedência e rede e métodos de análise do caminho crítico, muito comuns no gerenciamento de projetos por exemplo, podem ser empregadas para a realização da estimativa de duração dos processos.

Estimando a duração de processos

Durante a análise de um processo, um dos trabalhos comumente realizados é a estimativa da duração do processo e suas atividades.

Apesar de ser um atributo importante para o entendimento de um processo, o tempo é uma informação  frequentemente avaliada de modo bastante displicente. A estimativa de tempo do processo acaba por ser realizada com base na percepção das pessoas em função do trabalho realizado, em geral na forma de “chute”. O resultado é uma avaliação que não condiz com a realidade – ou porquê foi superestimado, levando a crer que o processo possui um desempenho superior ao seu real potencial, ou subestimado, levando ao entendimento de que o processo não é eficiente pois está sempre atrasado.

Assim, uma avaliação de tempo realizada sem um estudo apropriado tende a impactar em diversas decisões equivocadas de melhoria, já que é um critério essencial para a avaliação do desempenho do processo.

Para se estimar o tempo envolvido na realização de um processo, é necessário compreender os conceitos de: duração, execução e trabalho.

Esquema de espera, execução, trabalho e duração da atividadeO trabalho, ou esforço,  é o tempo que o participante da atividade leva, efetivamente, na realização do trabalho a ser executado. Em uma tarefa, é possível que o trabalho seja realizado em partes antes da mesma ser considerada como concluída.  Por exemplo, o preenchimento de um formulário, a pesquisa de dados adicionais e a complementação do mesmo. Portanto, o tempo de trabalho é a soma do tempo dispendido em ações necessárias para que a tarefa seja concluída.

A execução é o tempo dispendido deste o início do trabalho até o mesmo ser concluído, inclusive o tempo entre as partes do trabalho. Por exemplo, do momento em que a pessoa iniciou o preenchimento do formulário, até o momento em que o mesmo foi completamente preenchido.

A duração é o tempo calculado desde o momento em que a tarefa esteve disponível para o participante responsável pela atividade. Por exemplo, desde o momento que o formulário foi deixado na caixa de entrada do participante,  mais o tempo de espera que levou para que a pessoa tomasse o formulário em mãos para iniciar o trabalho, até o seu completo  preenchimento.

Analisar a execução de um processo requer conhecer o tempo de trabalho, execução e duração de cada atividade envolvida.

Ao se calcular a duração de um processo, entretanto, não basta somar as durações das atividades envolvidas. Em um processo executado manualmente (ou seja, sem o controle por um BPMS), a duração é afetada também pelo handoff, que é a espera dispendida no transporte das informações do processo entre os participantes das atividades.

Esquema de espera, execução, trabalho e duração de processo manual

Um exemplo clássico do tempo de espera em transporte é, por exemplo, o tempo levado para que um formulário preenchido em uma atividade seja disponibilizado para o participante da próxima atividade.

Assim, a duração do processo é a soma da duração das atividades mais a soma das esperas entre atividades.

Estimar corretamente os tempos de um processo pode levar a várias ações de melhoria, como:

  • Definir níveis de serviço (SLA) realistas;
  • Definir indicadores que apoiem na identificação de gargalos em atividades, baseados no tempo de espera que uma atividade leva para ser iniciada;
  • Melhorar a distribuição de recursos para realizar as atividades de acordo com o volume de trabalho;
  • Melhorar as ferramentas utilizadas pelos participantes das atividades a fim de agregar velocidade à realização do trabalho;
  • Avaliar melhoria de desempenho simplificando-se ou removendo-se tempos de transporte (handoffs), ou mesmo buscando métodos de transporte mais eficazes.

A automatização de processos é uma alternativa para a busca de desempenho e solução para o transporte das informações entre as atividades. Em geral, há dois benefícios comumente identificados na automatização relacionados ao tempo de execução do processo:

  1. Eliminação do tempo de handoff, já que o motor do processo disponibiliza as informações ao próximo participante imediatamente após a conclusão da atividade anterior;
  2. Eliminação do tempo de espera em atividades executadas pelo sistema (como serviços de busca ou gravação de informações, por exemplo), já que a execução das mesmas é realizada imediatamente  quando a atividade é disponibilizada.

Esquema de espera, execução, trabalho e duração de processo automatizado

Seja executado por controles manuais ou automatizado com um BPMS, compreender a análise dos tempos na avaliação da duração de atividades e processos é uma ferramenta de gestão fundamental rumo à melhoria do desempenho dos processos da organização.


Leia mais sobre o cálculo da duração de processos no artigo complementar Estimando a duração de processos II – processos não lineares.