Problemas comuns na modelagem de processos em BPMN II – Uso de eventos de mensagens para comunicação dentro do processo

Continuando a série de artigos que falam de erros, problemas e inconsistências básicas de modelagem (veja artigo já publicado aqui), vamos falar hoje de outra situação bem comum, que é a utilização de eventos de mensagem para comunicação entre papéis/raias dentro de um mesmo processo.

Vamos imaginar um processo ponta a ponta de uma organização, como por exemplo um processo de compras, onde em determinado trecho temos uma comunicação entre dois papéis ou áreas diferentes que atuam neste processo, no caso uma comunicação para o solicitante da compra de que a mercadoria foi recebida. Se olharmos apenas uma definição genérica do evento do tipo message, temos que um evento deste tipo trata de “uma comunicação entre 2 participantes do processo”.

Partindo deste pressuposto inicial, alguém poderia imaginar uma modelagem como esta:

Perceba que foram utilizados dois eventos do tipo message, um de envio (throw) na raia de Compras e outro de recebimento (catch) na raia do Solicitante.

Qual o problema desta abordagem? Basta nos aprofundarmos um pouco mais na especificação oficial de BPMN (link), para encontramos o seguinte trecho na seção “10.4.1 Concepts“:

“Messages are triggers, which are generated OUTSIDE of the Pool they are published in. They typically describe B2B communication between different Processes in different Pools.”

Em tradução literal: mensagens são gatilhos gerados fora da pool onde estão publicados, descrevendo tipicamente a comunicação B2B entre diferentes processos em diferentes pools.

Assim, o evento do tipo message só deve ser usado para comunicação com participantes EXTERNOS ao processo, não devendo ser utilizado para comunicar com um participante que já faz parte (ou seja, já é uma raia) do processo.

Partindo deste novo conhecimento adquirido, como ficaria então o processo descrito acima? Para isto, precisaríamos saber um pouco mais sobre de que forma é feita a comunicação entre a área de compras e o solicitante. Supondo, por exemplo, que a comunicação fosse realizada como um email disparado automaticamente pelo sistema (ou pelo processo automatizado), poderíamos ter então este desenho:

Neste caso, em vez do par de eventos do tipo message de envio e recebimento, teríamos apenas uma service task indicando o envio de email de forma automática. Perceba que o recebimento de email pelo solicitante não é uma atividade que envolva trabalho (consumo de recurso) de fato. Assim, receber um email é uma situação passiva e consequência direta do envio do email, portanto não é necessário uma tarefa para receber o email na raia do solicitante.

Problemas comuns na modelagem de processos em BPMN – I – Atividades de transferência do processo

Vamos iniciar hoje uma série de artigos que pretendemos publicar ao longo dos próximos meses, falando especificamente de erros, problemas e inconsistências básicas de modelagem, comuns de ocorrer quando começamos a modelar processos e ainda não conhecemos muito bem a notação BPMN.

Pra começar, vamos falar de uma questão muito frequente, que se refere ao encaminhamento de um papel do processo para outro. Vamos imaginar um processo de Viagens, que foi descrito pela área de negócio da seguinte forma:

  1. Um colaborador solicita a viagem
  2. Solicitação de viagem é encaminhada (atenção especial ao uso desta palavra) para uma área interna chamada “Administrativo”, que tem a responsabilidade de pesquisar e mandar cotações da viagem para o solicitante
  3. Cotações são então encaminhadas de volta para o Solicitante avaliar
  4. Se a cotação for aprovada, processo é direcionado novamente para setor Administrativo comprar os tickets, do contrário processo é direcionado de volta para o setor Administrativo refazer as cotações

Agora veja como o modelador decidiu, inicialmente, representar este processo:

Note que no caso da primeira transferência do processo, do papel “Solicitante” para o papel “Administrativo”, foram criadas 2 atividades:

  • Uma atividade na raia do “Solicitante”, chamada “Encaminhar Viagem para Cotação para Administrativo”
  • Uma atividade na raia do “Administrativo”, chamada “Receber Viagem para Cotação do Solicitante”

O mesmo comportamento foi modelado posteriormente, na transferência do papel “Administrativo” para o papel “Solicitante”, com as atividades “Encaminhar Cotações para Solicitante” e “Receber Cotações do Administrativo”, respectivamente.

Este trecho do processo não está errado do ponto de vista da notação BPMN. Mas o que temos aqui, no entanto, são atividades que na prática não precisariam existir. O modelador optou por explicitar a passagem de bastão de um papel a outro através de atividades de transferência do processo, mas isso não é necessário: em BPMN, o próprio fluxo de sequencia já tem o papel de representar/realizar esta transferência de responsabilidade dentro do processo. Neste caso, como ficaria o desenho do processo ajustado? Veja a seguir:
Perceba que com esta mudança, deixamos o processo mais simples e limpo, ao mesmo tempo mantemos o comportamento esperado.

O conceito de utilizar apenas fluxos de sequência para representar a transferência de atividades dentro do processo costuma se aplicar mesmo que exista, de fato, um encaminhamento físico sendo realizado. Por exemplo, este processo de viagens poderia ser realizado em papel, implicando que o solicitante tivesse que levar fisicamente a solicitação impressa e assinada para o setor Administrativo. Mas mesmo neste caso não seria necessário modelar as atividades de transferência. Caso fosse necessário ressaltar este aspecto de encaminhamento físico de algo, poderiam ser utilizados outros recursos para representar, como adicionar uma anotação ao processo ou documentar esta característica do processo nos procedimentos das atividades.

Um cenário em que poderia ser necessária uma atividade para encaminhar ou receber o processo seria num caso em que as atividades são reconhecidamente manuais, realizadas no plano físico, e que possuem procedimentos adicionais, como protocolar a chamada do documento esperado, carimbar, etc. Por exemplo, num processo logístico poderíamos ter uma atividade da área de “Recebimento” chamada “Enviar material para Estoque”, onde “Estoque” é uma área da organização:

Note que, em linhas gerais, continuamos falando do mesmo exemplo citado no Processo de Viagens: a passagem de bastão de uma área para outra. Se o ato de encaminhamento físico do material de um lugar para outro envolve procedimentos adicionais e tem um tempo de execução relevante (vamos imaginar neste caso uma grande planta industrial, em que seria necessário percorrer a distância entre um setor para outro), ou seja, a atividade consome efetivamente recursos, então neste caso faria mais sentido criar uma atividade de transferência.

Fique ligado para outros artigos desta série no futuro! ;-)

Em que nível devo modelar meu processo?

Uma das principais atividades na transformação de um processo é a sua modelagem. Seja no princípio do projeto, para representar a sua situação atual (AS IS), a criação de modelos para simulação ou comparação de variações, a definição da sua visão de futuro (TO BE) ou o fluxo a ser implementado para automação, a modelagem é importante na representação do processo que está sendo detalhado ou melhorado.

A representação visual do modelo utilizando uma notação gráfica como BPMN é um dos seus aspectos chave da modelagem. O nível de detalhe das atividades no diagrama de processos, entretanto, é frequentemente tema de debate entre os profissionais de Processos.

A notação BPMN, apesar de poderosa e de ter uma gramática bem definida quanto ao uso dos seus elementos, não estabelece qual seria o nível ideal de modelagem do processo. Ela define formalmente que “uma atividade representa um trabalho”. Mas devemos ir por uma abordagem mais alto nível do significado de trabalho (o “trabalho” é aquilo feito por uma área inteira?) ou mais baixo nível (o “trabalho” é cada ação realizada por alguém para atender ao resultado objetivo do processo?).

Não há uma regra para isso, e na verdade cada tipo de modelo pode requerer um nível de detalhe diferente no mapeamento do processo, de acordo com o propósito para que serve aquele modelo.

Por exemplo, em uma reunião no qual estamos buscando um entendimento amplo sobre o processo, com uma visão ponta a ponta em que possamos identificar suas principais etapas, um nível alto seria o mais apropriado.
Mas e quando vamos mapear um processo que será usado como material de treinamento, num manual de processos ou para descrever o trabalho de uma determinada etapa?

Existem alguns critérios que podem ser interessantes de serem questionados pela equipe ao definir o nível de modelagem do processo que estamos criando.

Como oportunidade de reflexão, um de nossos leitores contribuiu recentemente com dois exemplos de processos. Vamos tomar por base então o seguinte exemplo:

1) Nesse fluxo, podemos perceber que o mapeamento está em nível de procedimento, não de trabalho. O trabalho seria, por exemplo, “Avaliar baixa”, que envolve esta sequência de procedimentos: Consultar arrecadações, selecionar arrecadação, …, até confirmar baixa manual. Embora exista uma sequência entre eles, pode ser uma sequência flexível, em que a ordem dos itens pode eventualmente mudar na operação da pessoa no sistema. Esse nível de detalhe é bem comum de ver em processos modelados por profissionais de TI. Cuidado para não confundir o fluxo de trabalho com o fluxo de interação com sistema. Para esse segundo, devemos utilizar UML (Diagrama de sequência ou diagrama de atividades ou até mesmo passos de um Caso de Uso).

2) Pensando no por quê modelamos processos no nível de operação, geralmente fazemos isso para entender o processo e ter um parâmetro para avaliar o seu desempenho, certo? Assim, normalmente as tarefas são utilizadas para determinar o trabalho do processo, onde podemos medir o tempo e custo da sua realização. Neste sentido, será que realmente interessaria para a organização mensurar detalhadamente quanto tempo leva para executar cada um desses passos? Ou é mais importante entender quanto tempo, dentro da dinâmica do processo, um profissional leva para realizar a análise e a baixa, de uma forma consolidada?

3) Geralmente quando mapeamos nesse baixo nível, fica mais difícil representar as exceções. Por exemplo, no caso em que qualquer um desses passos seja possível o ator voltar atrás em alguma ação. Nesse fluxo, teríamos que desenhar também todas as possibilidades de voltar e refazer algum passo. Ou seja, após ele selecionar o ingresso, ele terá que selecionar uma parcela. Mas se ao selecionar a parcela ele se der conta que escolheu o lançamento errado, ele poderia voltar pra selecionar outro lançamento?

4) Um outro fator a considerar é a manutenibilidade do processo. Queremos dizer com isso que qualquer mínima alteração nas ferramentas podem fazer com que você tenha que criar uma nova versão do seu diagrama de processo, tornando a manutenibilidade da documentação mais custosa e também dando mais chance para ela se tornar rapidamente obsoleta.
Se você tem uma tarefa “Avaliar baixa” e nela descreve os procedimentos, e a sua organização mudar do sistema XPTO para o sistema MEGAXPTO, o trabalho feito pela organização continuará sendo o mesmo, que é avaliar a baixa. O processo não mudou, o que mudou foi a ferramenta. Assim, no nível de mapeamento do trabalho, a manutenção fica mais fácil porque não precisará mudar o fluxo, apenas atualizar o procedimento (passos realizados naquela atividade, que podem ser descritivos complementares ao desenho do fluxo).

Se o plano for automatizar o processo, esses critérios podem ser ainda mais relevantes, porque o motor de processos é muito literal na interpretação do modelo. Confira uma outra reflexão semelhante que já fizemos sobre o assunto aqui no Blog da iProcess no artigo: Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

 

Como representar exceções no fluxo do processo em BPMN?

Com alguns anos de experiência participando de projetos e treinamentos envolvendo processos de negócio, percebemos situações recorrentes quanto à aplicação de exceções na lógica do fluxo do processo de negócio que está sendo desenhado e documentado. A boa modelagem de processos de negócio em BPMN é o resultado do domínio da notação (estudo e compreensão dos elementos), mas para uma modelagem que represente corretamente uma situação de negócio, não basta saber aplicar as regras da notação BPMN, conhecer seus símbolos e o que cada um significa. É preciso também entender os detalhes da lógica do processo de negócio em questão.

Vou aproveitar o tema para repassar as regras da notação BPMN relacionadas à representação de exceções durante a execução de atividades, apresentar algumas ilustrações, de forma a esclarecer algumas dúvidas e confusões comuns quanto à representação da lógica do negócio.  

Como já tratado em outros artigos, atividades retratam o comportamento ou trabalho realizado em um contexto do processo, gerando uma transformação (resultado) ao final deste trabalho. Atividades que podem gerar mais de um resultado normalmente são testadas, pois levam o fluxo por caminhos diferentes (alternativos ou paralelos). Para contextualizar, usarei como exemplo um processo fictício de liberação de crédito, representado abaixo. 

No exemplo, o Processo de Liberação de Crédito realiza dois trabalhos para identificar se o crédito pode ou não ser aprovado. O Processo consiste em analisar se comprador possui restrições de crédito e limite para liberação de crédito.

O processo possui duas tarefas que analisam se o solicitante pode receber o crédito solicitado. A primeira tarefa Consultar situação de crédito (Tarefa de Usuário) analisa se solicitante está em situação de inadimplência ou sem débitos. Caso a tarefa resulte por situação de crédito por inadimplência, o processo é automaticamente finalizado por solicitação reprovada. Se não houver débito(s) o processo segue para verificação do limite. A segunda tarefa Verificar limite de crédito (Tarefa de Serviço) analisa se o solicitante possui limite para liberação de crédito solicitado. Caso o limite de crédito esteja dentro do limite solicitado, o processo é finalizado por solicitação aprovada. Se o limite de crédito estiver abaixo do solicitado, o processo é automaticamente finalizado por solicitação reprovada.

Mapeando exceções nas atividades do fluxo do processo

Descrevi acima um fluxo típico de processo de liberação de crédito, onde a situação de negócio está bem explícita em cada uma de suas tarefas, tanto no que consiste o trabalho realizado, quanto suas saídas (possíveis resultados). Porém algumas situações fora do comum, que não se espera que aconteçam (mas que podem acontecer) foram ignoradas. Estas situações são conhecidas também por exceções. Vejamos algumas situações que deverão ser representadas no fluxo do processo de liberação de crédito.

Situação 1

A tarefa Consultar situação de crédito deve conter um prazo para execução e, caso o prazo seja excedido, uma notificação deverá ser disparada para o responsável.

Situação 2

Caso uma informação de referência da tarefa Consultar situação de crédito estiver incorreta (ex. cpf inválido) e não for possível finalizar a tarefa, deverá ser realizado um tratamento para correção da informação.

Situação 3

Caso o serviço utilizado na tarefa Verificar limite de crédito estiver indisponível ou apresentar erro na sua execução impossibilitando a finalização da tarefa, uma notificação deverá ser disparada para o responsável, finalizando o processo por indisponibilidade no sistema.

Imagine que em nível de negócio todas estas situações devem ser previstas e representadas no fluxo do processo. Como representar estas situações? Qual seria a forma mais adequada de representá-las, levando em conta a lógica do processo e as regras da especificação BPMN 2.0?

Começaremos avaliando, neste artigo, apenas a Situação 1.

Antes de apresentar a solução, mostraremos uma confusão na hora de desenhar esta situação. Um erro bastante comum que presenciamos ao corrigir os exercícios dos alunos nos nossos cursos e por vezes também identificado em processos de melhoria, é a forma como é aplicado o controle de prazos nas tarefas, que geralmente é representado com um evento intermediário diretamente no fluxo do processo, posicionado logo após a tarefa que deveria ser controlada (já vimos casos que o prazo também havia sido posicionado antes da tarefa).

Aqui começa a primeira confusão: o evento que controla o prazo deve ser representado como uma exceção à saída da tarefa. Veremos mais abaixo, nas regras de especificação da notação, que este tipo de situação deve ser representado por um evento anexado a borda da tarefa a ser controlada, e não diretamente no fluxo do processo. Neste caso o evento de tempo deve ser acionado somente se a tarefa não tiver sido executada dentro do prazo e nunca obrigar, como modelado no exemplo abaixo, que o fluxo aguarde sempre por um período de tempo, desta forma paralisando o fluxo. Outro erro, também demonstrado na imagem abaixo, está no gateway que testa a situação de crédito. Veja que foi incluída uma nova saída Em atraso que deverá ser acionada caso a tarefa seja executada após o prazo. Da forma como o fluxo acima foi modelado, a tarefa Consultar situação de crédito não possui, de fato, um controle de tempo. Ela deve ser necessariamente executada para que o fluxo prossiga. Após a conclusão da tarefa é apresentado um controle de tempo contido diretamente no fluxo do processo, que obriga ao processo uma parada no fluxo, por dois (2) dias.

Vejam que o processo acima é válido do ponto de vista da notação BPM. Porém ele não representa corretamente a situação do negócio proposto na situação 1, pois não deveria obrigar a parada do fluxo, e sim controlar o tempo da tarefa Consultar situação de crédito.

Solução proposta para Situação 1:

  1. A tarefa deverá possuir uma condição de tempo associada à sua execução.
  2. A tarefa, mesmo em atraso, poderá ser executada (não deverá ser cancelada).
  3. A tarefa, caindo em atraso, deverá executar um fluxo de exceção para disparo de uma notificação de atraso para o responsável.

Regras da especificação BPMN 2.0:

  • Segundo a especificação oficial da notação BPMN 2.0, quando uma atividade possui prazo para execução, deve ser representado através do elemento Evento Intermediário do tipo Tempo (Timer), conectado à borda da atividade.
  • No momento que a atividade for iniciada, o evento será monitorado e controlado seu tempo.
  • Se o evento for disparado, o fluxo mapeado a partir do evento é executado.
  • A interrupção da tarefa é representada através do desenho da borda do evento. Neste caso, deve conter a borda tracejada, que demonstra que a tarefa, mesmo em atraso, poderá ser executada. A borda contínua representa que, ao ser disparado o evento de tempo, a tarefa seria cancelada.

Levando em conta a lógica desejada para o processo e as regras da especificação BPMN, apresentamos abaixo a solução mais adequada para a situação 1:  O controle do prazo para execução da tarefa está representado corretamente pela exceção – neste caso o evento intermediário de tempo anexado a borda da tarefa. Como já dito, assim que a tarefa é iniciada, o evento passa a controlar seu tempo e caso a tarefa não seja executada e finalizada em até dois (2) dias, o evento de tempo é disparado e o fluxo segue para o próximo ponto onde dispara uma notificação de atraso ao responsável.

Continuaremos em um próximo artigo o assunto, falando a respeito da segunda e terceira situações, bem como as confusões mais comuns na hora de desenhá-las. Fique ligado!

 

 

Como documentar funcionalmente o processo de negócio como requisito de software

Na automação de processos, os processos de negócio são definidos e otimizados a fim de serem executados sobre uma arquitetura de sistemas informatizada.

No artigo Benefícios da Automação de Processos do blog da iProcess, tratamos dos benefícios e vantagens da automação de processos, estabelecendo uma visão dos ganhos obtidos quando se automatiza um processo. Porém, alguns cuidados devem ser tomados para escolher um processo a ser automatizado e estabelecer o nível de detalhamento necessário do processo para tal, tendo como objetivo automatizar processos com tarefas que possam efetivamente demonstrar bons resultados. Em Estudo de Caso: Automatizar o processo (ou não)? Eis a questão! exploramos esta questão através de um estudo de caso.

As etapas de modelagem na transformação de um processo

Nos projetos 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.

O artigo BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado aborda este tema, incluindo aí os riscos envolvidos em um projeto em que se parte diretamente para a etapa de implementação (TO DO), sem passar pelas demais. Isto porque é na etapa de TO BE, em que há a proposição de melhorias no processo e são definidos os requisitos de software que irão compor a solução automatizada. Já falamos sobre esta ligação no artigo O que BPM tem a ver com requisitos de software? Tudo!, enfatizando que os requisitos de software são identificados a partir do processo.

Documentando a modelagem do processo para automação (TO DO)

Passadas todas estas fases, chega a hora da implementação do processo. O processo e os requisitos de software complementares serão detalhados funcionalmente (TO DO) e implementados pela equipe de desenvolvimento. E aí entra em cena a Especificação Funcional do processo. Ela especifica o fluxo a ser automatizado no BPMS e sua estrutura de dados, regras para identificação de participantes e comportamento de cada componente.Resumidamente, a Especificação Funcional deve atender aos seguintes objetivos:

  • Concentrar as informações do processo de negócio necessárias para a automação do processo;
  • Utilizar linguagem que deve ser de fácil compreensão pelo público-alvo;
  • Fornecer informações suficientes para que o projetista possa desenvolver a especificação técnica do processo;
  • Servir de referência para o desenvolvimento e homologação da solução.

Temos encontrado, ao longo dos projetos de automação de processos em que a iProcess atua, alguns clientes que já possuem uma metodologia, utilizam ferramentas e templates para documentar processos automatizados, enquanto outros não possuem nada definido. Nas organizações que já tenham adotado uma metodologia de desenvolvimento com documentação funcional dos requisitos, é comum encontrarmos documentos como Casos de Uso, Especificações de Interface, Especificações de Serviço ou de Regras de Negócio. Nos projetos de automação de processos, é comum que os requisitos se estendam além da programação do fluxo no BPMS, envolvendo o desenvolvimento ou customização de componentes adicionais ao processo, como aplicações de apoio, cadastros de backoffice e serviços de integração com outros sistemas. Para estes requisitos, os documentos já adotados pela TI continuam sendo bastante apropriados. 

 Assim, a Especificação Funcional do Processo (o modelo TO DO) vem para complementar a documentação do sistema definindo funcionalmente o processo de negócio, e requer um detalhamento de como o fluxo do processo se comportará ao ser automatizado. São informações importantes neste modelo:

  • Diagrama do processo automatizado;
  • Modelo de dados do processo;
  • Identificação de usuários ou grupos de usuários participantes do processo (Papéis);
  • Formulários do Processo;
  • Especificação dos componentes do processo, que são eventos, tarefas humanas e automáticas, notificações/envios de email, controles de tempo, gateways, subprocessos, regras de negócio e sensores de indicadores;
  • Definições de interface para as atividades humanas;
  • Referências a serviços de outros sistemas;

Esta especificação deve ser realizada por um Analista de Processos e Sistemas, ou um analista de sistemas que tenha desenvolvido uma visão de processos, horizontal aos sistemas, e que conheça as capacidades de implementação do BPMS adotado pela empresa

O Analista de Processos e de Sistemas, pode encontrar alguma dificuldade em estabelecer a melhor forma de como escrever utilizando uma linguagem de fácil compreensão pelo usuário e ainda assim fornecer informações suficientes para que sirva de referência para a elaboração da especificação técnica e o posterior desenvolvimento da solução. Uma sugestão nesta situação é o alinhamento com os responsáveis pela aprovação do documento no cliente, para estabelecer qual será o nível de detalhamento da Especificação Funcional do processo, a fim de definir se haverá necessidade de utilizar documentos complementares mais técnicos para a equipe de desenvolvimento, ou em mais alto nível para a equipe de negócio.

Temos observado que, às vezes, o cliente opta por realizar uma “tradução” da especificação para a área de negócio ou absorver para si a aprovação do documento. Quanto mais precisa for a Especificação Funcional do processo, menos problemas de entendimento tendem a ocorrer entre a expectativa do cliente e o que está sendo desenvolvido. Isto porque as etapas de desenvolvimento e homologação dos processos vão utilizar estas informações, garantindo assim, que o que foi definido e aprovado pelo cliente seja entregue.

Cabe aqui salientar que a Especificação Funcional do processo, assim como de sistemas, não fica “congelada”, sem receber as atualizações que ocorrerem no escopo do projeto durante o seu ciclo de vida. Ajustes na documentação funcional podem ser necessários após a finalização da etapa de especificação funcional por diversos motivos e devem ser realizados, sempre que necessário, para que se mantenha a consistência entre o que foi especificado e o que foi desenvolvido. E neste caso, a gestão de mudanças do projeto é que tratará desta atualização.

Se este assunto lhe interessou, no nosso curso iPE03 – Modelagem de Processos para Automação, reservamos um capitulo inteiro para tratar deste assunto, inclusive com exercícios práticos.

Muito prazer, o CLIENTE! (Visão Outside in e Inside out)

Começamos com uma pergunta direta: QUEM É O CLIENTE?
Parece ser uma pergunta um tanto obvia, mas saber exatamente quem é (ou quem são) os seus clientes é fundamental para atender as suas necessidades.

Poderíamos afirmar que:

“Na perspectiva de BPM, cliente é somente aquele que se beneficia da geração de valor e está externo à organização.” (BPM CBOK 3.0, pag.47)

Mas, de uma forma geral, todos nós somos clientes, pessoas comuns que levantam pela manhã para trabalhar, que fazem compras no mercado, utilizam os serviços da rede bancária, que pagam contas, cidadãos que dependem do transporte público para chegar ao seu destino, ou seja, consumidores!

Todos nós, como cidadãos, por exemplo, somos clientes que dependem dos serviços públicos como o acesso à água e a luz, saneamento, limpeza pública e segurança.

Clientes que muitas vezes não têm as expectativas atendidas!

Ao mesmo tempo, quantas vezes, como cidadãos, somos questionados pelo prestador de serviços para saber o que achamos do serviço prestado?

Organizações estão empenhadas em oferecer o melhor valor agregado aos seus produtos e serviços, só que nesta tentativa, trabalham muito mais focados em otimizar e reduzir custos dos seus processos internos e esquecem de avaliar as expectativas dos consumidores destes produtos e serviços.
Assim, saber quem são seus clientes é o caminho para entender suas necessidades, expectativas e o que eles valorizam, e poder produzir e entregar aquilo que seus clientes esperam.

COMO ERA ANTES

Durante décadas organizações determinaram o que seus clientes necessitavam e definiam como seus produtos e serviços seriam disponibilizados. Até então, o cliente era pouco exigente. O foco era: aumento da eficiência na produção.

Esse cenário, de foco na otimização do processo em detrimento às expectativas do cliente, se percebe concretamente nesta célebre frase de Henry Ford, sobre a fabricação do modelo Ford T:

“O carro é disponível em qualquer cor, contanto que seja preto.”

O objetivo de Henry Ford era tornar o carro acessível a todos, aumentando a procura mas ao mesmo tempo reduzindo custos.

Conforme as empresas foram crescendo, foram surgindo novas oportunidades. As empresas foram criando novos planos de expansão e com isto os clientes começaram a impor o que queriam e como queriam. Sendo assim, as estruturas organizacionais e modelos de negócios começaram a tomar novas formas, mas persistia a visão de “dentro para fora”, ou seja, a busca pela eficiência na entrega de valor ao cliente.

OLHAR DE DENTRO PARA FORA OU DE FORA PARA DENTRO?

“Olhar de dentro para fora”: visão conhecida também por Inside out ou ainda por Foco NO Cliente.

É a visão sob o ponto de vista da organização. Se preocupa com o “de dentro”, com foco em seus produtos e serviços. É a organização que determina o que agrega valor para seus clientes e cria a cadeia de valor idealizado por Michel Porter.

Este modelo fazia sentido em sua época, onde a interação com o cliente não era algo comum, pois este ficava em segundo plano. A preocupação das organizações era em fazer as coisas certas. O foco era a eficiência, o controle de custos e a redução de erros.

Atualmente, as organizações estão focadas muito mais na eficácia, ao grau em que os resultados de uma organização correspondem às necessidades dos seus clientes.
Hoje a exigência está muito maior, principalmente no que se refere não apenas a qualidade ou preço dos produtos, mas principalmente ao atendimento real às suas necessidades.

“Olhar de fora para dentro”: visão conhecida também por Outside in ou ainda por Foco DO Cliente.

É a visão sob o ponto de vista do cliente, se preocupando com o que vem de fora, onde o foco é sempre o cliente. É o cliente que determina através de suas experiências aquilo que é importante para a empresa, o que gera valor para concepção dos seus produtos e serviços. A visão do cliente consiste em conhecer a organização pelo lado de fora, tem a ver com o valor percebido, se o cliente está ou não satisfeito.

O gerenciamento de processos consiste na experiência do cliente como ponto de partida para o desenho e implementação de processos. Os processos são desenhados em torno deste relacionamento do cliente com os produtos, serviços e pontos de contatos (momentos da verdade) que devem ser conhecidos pela organização para alcançar a real necessidade e satisfação de seus clientes.

Mas você pode estar se perguntando, como entender de fato as necessidades do cliente? Existe uma fórmula mágica para isto?

O que existe hoje são técnicas e métodos utilizados para “trazer o cliente” para análise e redesenho dos processos, através de coleta de informações como pesquisas de opinião, avaliação dos comentários e reclamações do SAC, comentários enviados por pessoas através de sites como o “Reclame aqui”, e até mesmo workshops e entrevistas envolvendo o cliente. Redesenho é um repensar sob a ótica do cliente, é uma nova visão do negócio. Isso é transformação (construir processos com foco do cliente).

Não se trata mais de apenas oferecer um produto para um cliente, mas de entender a sua real necessidade. O foco assim é a percepção de valor do cliente, o que ele acha que é importante. Esta experiência de consumo leva o cliente a participar da criação do processo ponta a ponta, e permite a organização identificar atividades, que pela visão de “dentro para fora” (inside out), não seriam identificadas.

Vejamos o exemplo da tão conhecida IBM. Empresa de 103 anos de vida, que já passou por altos e baixos em sua história e ainda está no topo das empresas de TI. Mas como explicar sua longevidade? Como ela pode estar viva e próspera em um setor caracterizado pela inovação e a mudança? Dois pontos nos chamam a atenção: a cultura e a mudança.


Thomas Watson
, fundador da IBM, criou sua empresa baseado em três crenças básicas. Achamos relevante destacar uma delas: “Prestar o melhor serviço ao Cliente”. Tinha por base a satisfação e desejo do cliente, ou seja, a crença é direcionada ao cliente e as suas necessidades.

O segundo ponto relevante e mais significativo foi à busca pela mudança, pela transformação.
Em 1991 foi apresentada como a “Nova IBM”, voltada para a visão do mercado atual e obcecada pela qualidade. Segundo a própria IBM, a mudança foi causada pelo aumento do nível de exigência dos seus clientes, o que gerou a necessidade de criar valor para seus clientes.

A IBM de hoje não se considera uma empresa de tecnologia, mas uma empresa que resolve business problems usando a tecnologia. Segundo a IBM, ela não vende “brocas”, vende ferramentas para produzir “buracos na parede”, a IBM é focada nos trabalhos que seus clientes precisam que sejam realizados.

Quem já assistiu o filme “Quero ser Grande” (Big, 1988) estrelado Tom Hanks, percebe uma ligação da história com a visão “outside in”.

No filme, Josh (Tom Hanks) se torna adulto da noite para o dia, e conhece o Sr. MacMillan, dono de uma empresa que fabrica brinquedos (naquela clássica cena do The Big Piano). Confira aqui a cena do filme.

O dono da empresa comenta com ele sua preocupação de que não estão obtendo boas vendas, e Josh acaba ganhando o emprego porque começa a expor para a empresa a visão do cliente (ele como criança em corpo de um adulto).

Com o foco do cliente, os produtos desenvolvidos pela empresa se tornam muito mais atraentes aos consumidores, e a empresa volta a gerar crescimento.

O foco hoje não pode ser mais o produto ou o lucro que este lhe proporciona, mas a experiência vivida pelo cliente ao consumi-lo. O cliente de hoje procura ser compreendido e ter suas expectativas atendidas. Para a organização fica a responsabilidade de conhecer seu cliente e entender porque ele procura pelo seu produto ou serviço. Conhecer o cliente e atender suas necessidades é um desafio, e deve ser encarado como uma grande oportunidade de crescimento para a empresa e para a geração de novas soluções inerentes ao mercado atual.

BPMN: Introdução ao Diagrama de Conversação

Com sua versão 2.0, oficialmente lançada em 2011, BPMN não apenas adicionou novos elementos ao diagrama de processo, mas também propôs dois tipos de diagramas complementares, que possibilitam obter perspectivas diferenciadas sobre o processo: o Diagrama de Coreografia e o Diagrama de Conversação.

O Diagrama de Coreografia apresenta uma visão bastante interessante da interação entre processos, especialmente em processos business-to-business, onde há diversas partes interessadas envolvidas. Ele abstrai as particularidades da lógica do processo mapeado no diagrama de orquestração (aquele que já conhecemos bem) e foca na sequência e as dependências envolvidas na troca de informações do processo com agentes externos. Esse diagrama já foi apresentado em nosso blog nos artigos: BPMN 2.0 – Novos Diagramas e Elementos: Introdução a Coreografia e Coreografia no detalhe.

Neste artigo, vamos falar sobre o Diagrama de Conversação.

Diagrama de Conversação (Conversation Diagram)

O Diagrama de Conversação tem o propósito de dar visibilidade sobre os participantes do domínio do processo. Neste diagrama, o foco não é a lógica do processo, mas a comunicação: quem são os participantes e sobre o quê eles “conversam”.

O Diagrama de Conversação pode ser facilmente extraído de um Diagrama de Processo.

Neste diagrama, os participantes são as pools. Todas elas são representadas como “black pools” (o fluxo do processo dentro delas não é visualizado), colocando o foco da atenção da modelagem na troca de mensagens entre elas.

As mensagens podem ser agrupadas por assunto, criando os nodos de conversação (conversation nodes).

Por exemplo:
Em nosso processo “Vender Livros via Web” (que está no nosso Guia de referência rápida BPMN 2.0), temos a Loja (que é quem executa este processo) e que se comunica com o Cliente e com a Editora.

Diagrama de Orquestração: Processo de Negócio "Vender Livros via Web"

Então neste processo, temos claramente três participantes: a Loja, o Cliente e a Editora (que pode ser mais de uma, já que o subprocesso “Encomendar obra” ocorre múltiplas vezes, enviando listas de títulos às diferentes editoras envolvidas no pedido com obras faltando em estoque).

Diagrama de Conversação: os participantes do processo do exemplo Vender Livros via Web

Com o Cliente, a Loja conversa sobre o pedido de livros, o pagamento do pedido de livros (envio do título de cobrança e confirmação de pagamento) e a entrega do pedido de livros (envio dos livros vendidos e confirmação de recebimento).

Com a(s) Editora(s), a Loja conversa sobre encomenda de títulos (lista de títulos e entrega da encomenda).

Essas “conversas” podem ser descritas detalhadamente, apresentando a troca de mensagens entre os participantes:

Ou agrupadas, reunindo as “conversas” por assunto usando os elementos de nó de conversação (conversation node), estes símbolos em formato de hexágono. Os nós de convesação são conectados aos participantes através de ligações de conversação (conversation link), que são linhas duplas conectando o nodo aos participantes da conversa.

Querendo-se, é possível subir mais ainda o nível da abstração da conversa, reunindo os nodos com temas em comum com um nó de sub-conversação (sub-conversation node), que possui um marcador [+] na base. No exemplo, podemos reunir as conversas entre cliente e livraria em um nó de sub-conversação de “Venda de livros”.

Cada um dos três diagramas acima são um mesmo Diagrama de Conversação, porém visualizado em níveis de detalhamento diferentes.

Para um processo tão simples como este, o Diagrama de Conversação pode não parecer uma ferramenta muito relevante. Mas considere um processo mais complexo, como por exemplo a aquisição de um imóvel, onde temos: o cliente, a construtora, o banco, as lojas de material para construção:

Diagrama de Conversação para o processo de negócio de construir e vender imóveis de uma construtora.

Este diagrama pode ser uma ótima ferramenta para alinhar entre os participantes que tipo de informação será trocada com quem no decorrer do processo.


Aprenda a utilizar todo o potencial da notação BPMN e seus três tipos de diagrama com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Métodos para levantamento de informações na Modelagem e Análise de Processos

Em projetos envolvendo modelagem e análise de processos de negócio é imprescindível que a equipe tenha a compreensão correta dos processos ponta-a-ponta da organização para uma visão precisa do negócio. Esta compreensão pode ser obtida com uma coleta de informações realizada ao longo do esforço de forma consistente, caso contrário alguma informação importante poderia faltar, e seria difícil fornecer uma visão clara do negócio.

Existem diversos métodos especializados para levantamento destas informações. Falaremos sobre isto em uma série de artigos, trazendo as diversas formas de captura de informações para a realização do trabalho de modelagem.

Neste artigo, iniciaremos falando dos métodos Pesquisa, Entrevista e Observação Direta.

PESQUISA

A pesquisa serve para obter o contexto inicial do processo, serve também para complementar o entendimento do negócio e para preencher algumas lacunas na documentação do processo que não foram obtidas por outros métodos.

Pode ser pesquisado todo o tipo de documento, desde formulários, manuais dos sistemas da empresa, políticas da organização, registros de auditorias, documentação de processos, descrições escritas das partes interessadas e autores do processo, etc.

Esforço: O empecilho fica por conta do tempo requerido para realizar estes levantamentos, que muitas vezes não é suficiente para conciliar diferenças de opinião e informações levantadas versus o trabalho realizado na prática.

ENTREVISTA

Entrevista é um “processo de comunicação fundamental entre pessoas que se caracteriza pela realização direta, face a face, que se estabelece entre o profissional e o usuário” (Ballestero-Alvarez, 1997).

A entrevista é um método muito utilizado para a coleta de informações. Ela pode ser realizada de forma individual ou em grupo, conduzida por um facilitador. Pode ser presencial, por telefone, conferência web ou e-mail.

Participantes: Devem ser entrevistados os integrantes do processo, que contribuem com informações sobre as atividades que executam, assim como seus líderes. Podem também ser pessoas responsáveis pelo desenho, execução e desempenho do processo, não esquecendo daqueles que fornecem entradas ou recebem saídas do processo.

Ponto de atenção: A realização da Entrevista (em grupo) é muitas vezes confundida com outro método, o Workshop.
A diferença básica destes dois métodos é que no caso da entrevista em grupo os participantes limitam-se em falar das suas atividades (seu papel no processo), é algo mais pontual. Por exemplo: Entrevistar três operadores de empilhadeira de um CD (Centro de Distribuição). Ambos operadores realizam atividades referentes a movimentação de porta pallets da área de armazenagem para a área de separação.

Já o Workshop  consiste em reunir diferentes pontos de vista sobre o processo com representantes de todos os papéis envolvidos para discutir o processo. Falaremos mais sobre este método em nosso próximo artigo sobre o assunto.

Vale ressaltar que nada impede que outros métodos sejam aplicados juntamente com a entrevista, servindo assim como complemento para coleta de informações não obtidas com esta técnica.

Perfil do entrevistado: A avaliação do perfil do entrevistado é crucial para uma coleta consistente, portanto antes da escolha do entrevistado, verifique seu nível de atuação dentro da empresa e se o seu papel condiz com o nível de informação exigida.
Por exemplo: Analista marca uma entrevista com o Gestor do Centro de Distribuição para mapear atividades operacionais do setor de coleta de encabidados da sua unidade. Neste caso, o que poderia dar errado? Possivelmente o gestor simplificará as atividades operacionais, e com isto detalhes das atividades poderão ser perdidos, pois só quem executa é que conhece as atividades e muitos problemas que hoje acontecem não serão relatados.
Desta forma, concluímos que a escolha pelo gestor não seria a mais apropriada, pois a definição e manutenção de procedimentos de nível operacional fica em posse do auxiliar de operação, além é claro daqueles detalhes práticos, tarefas e passos executados no dia-a-dia que não são documentados e não passam pelo conhecimento do gestor.

Esforço: A entrevista pode exigir um grande esforço do analista para obter o grau de detalhamento satisfatório, isso deve-se a forte dependência das informações fornecidas pelos entrevistados. Esta dinâmica pode ser ineficiente caso o entrevistado não compartilhe, por algum motivo, as informações de como suas atividades são executadas de verdade. Os motivos são diversos, desde medo do fracasso e reprovação, até o medo da mudança (do novo) ou ter que começar a  fazer diferente de como é realizado hoje (este é um medo cultural). Além disto, a entrevista exige que os entrevistados parem as suas atividades, o que pode trazer dificuldades de agenda.

OBSERVAÇÃO DIRETA

Segundo Lakatos & Marconi (1992), a observação direta intensiva é um tipo de atividade que “[...] utiliza os sentidos na obtenção de determinados aspectos da realidade. Não consiste apenas em ver e ouvir, mas também examinar fatos ou fenômenos que se deseja estudar”.

Observação direta é um método que pode ser definido como um acompanhamento presencial do processo a ser modelado que sujeita o pesquisador a um contato mais direto com a realidade.

Este método auxilia na identificação de evidências revelando comportamentos, atividades e tarefas difíceis de serem lembradas por outras técnicas. Muito eficiente no diagnóstico de oscilações e desvios que ocorrem no dia-a-dia do trabalho.

Participantes: A escolha correta do executor do processo deve representar o nível de desempenho típico para executores daquele processo. Este executor deve entender o impacto de suas tarefas no resultado final do processo ponta-a-ponta, ter uma compreensão (uma visão) do todo e ter critérios para entender se o desempenho de suas atividades são satisfatórias.

Esforço: Para que o observador possa capturar informações consistentes com um grau de detalhamento satisfatório, deve ser levado em conta uma variedade grande de execuções de processos, observação de diversos grupos de executores e locais. Este esforço exige tempo e esforço, o que pode não ser possível em determinados projetos.

Riscos: A presença do observador pode provocar alterações na forma como os atores executam suas atividades, acabando com a naturalidade dos mesmos. Com isto, os atores ao serem observados realizam suas atividades da forma como aprenderam e não como realmente realizam no seu dia-a-dia. Este cenário pode gerar uma visão distorcida, criando falsas impressões da realidade e impactando de forma direta no resultado do processo.

Alguns cuidados podem ser tomados para que este tipo de problema não venha ocorrer, como dar as condições e tempo necessário para que o executor do processo se sinta confortável. Outra solução é realizar um comparativo dos resultados obtidos na observação com resultados anteriores registrados, garantindo assim que o trabalho realizado pelo observador represente a rotina diária do ator do processo.

Em nosso próximo artigo sobre o assunto continuaremos falando dos métodos especializados para levantamento e coleta de informações.
Confira: Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2.

 


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

 

Desmistificando tipos de tarefas em BPMN: Tarefas automáticas

No artigo anterior (Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual) iniciamos uma série de três artigos sobre os tipos de tarefas em BPMN. Para facilitar o entendimento, estamos discutindo os os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefas de execução de rotinas automáticas

Para representar situações em que rotinas que são executadas automaticamente no processo (em que seu acionamento é determinado pelo andamento do fluxo do processo, sem que haja uma pessoa para acioná-lo), BPMN sugere três tipos de tarefa: tarefa de serviço, tarefa de script e tarefa de regra de negócio:

Os tipos de tarefa automáticas: tarefa de serviço (service task), tarefa de script (script task) e tarefa de regra de negócio (business rule task)

De acordo com a especificação:

“Uma Service Task (tarefa de serviço) é uma tarefa que usa algum tipo de serviço, que pode ser um Web Service ou uma aplicação automatizada.” (pág 156)

“Uma Script Task (tarefa de script) é executada pelo motor de processos de negócio (business process engine). O modelador ou implementador define um script em uma linguagem que o motor de processos consegue interpretar. Quando a tarefa estiver pronta para iniciar, o motor de processos executará o script. Quando o script for concluído, a tarefa também será concluída.” (pag 162)

“Uma Business Rule Task (tarefa de regra de negócio) propicia um mecanismo para o processo para enviar informações a um Business Rules Engine (motor de regras de negócio) e obter o resultado do cálculo que o motor de regras pode prover. ” (pag 161)

 

Todas as três são utilizadas na modelagem quando temos um processo que está sendo automatizado (se o processo é executado manualmente, fora de um BPMS ou workflow, é necessário que haja uma atividade manual em que uma pessoa acione a execução de uma funcionalidade; portanto a tarefa em si é de uma pessoa).

 A diferença entre elas é que a tarefa de serviço (service task) aciona a operação de um sistema de informação externo com o qual o motor de processo se comunica (process engine) – que pode ser implementado através de tecnologias como webservices, RMI (Remote Method Invocation), EJB (Enterprise Java Beans), etc. Já a tarefa de script (script task) executa um trecho de código que a própria aplicação de motor de processos interpreta e executa (e cada fornecedor de produto pode definir sua linguagem de script própria). Por exemplo, a transformação de um tipo de dado em outro ou a realização de cálculos com os dados da instância do processo, são exemplos de tarefas de script.

A tarefa de regra de negócio (business rule task) comporta-se da mesma forma que a tarefa de serviço, porém possui o propósito específico de obter resultado da aplicação de uma determinada regra de negócio no processo (leia mais sobre regras de negócio e Business Rules Management no artigo Business Rules e a Dinâmica do Negócio).

Um exemplo de processo com tarefas automáticas de serviço, de tarefa e regra de negócio

No processo hipotético acima temos exemplos aplicados dos três tipos de tarefas automáticas.

  • A tarefa “Identificar prioridade do atendimento” é uma tarefa de regra de negócio, pois executa uma regra da organização (por exemplo: chamados de clientes com contas premium ou chamados que já tiveram uma visita técnica mas o problema não foi solucionado são tratadas como prioridade “emergência”, enquanto as demais são prioridade “normal”. Se a organização quiser mudar esta regra e incluir outros planos no atendimento de prioridade emergencial, pode modificar a regra de negócio sem impactar no processo).
  • Neste processo em que todos os chamados são originados com prioridade “normal”, a tarefa “Elevar prioridade do atendimento” é uma tarefa de script pois muda de “normal” para “emergência” uma informação do próprio processo, elevando a prioridade dos processos que passam por ela (sem precisar acessar outros sistemas).
  • A tarefa “Identificar técnico responsável” é uma tarefa de serviço pois acessa o sistema de localização da empresa identificando que técnico está mais próximo do endereço do cliente. Ela aciona um serviço deste sistema, e recebe como retorno a informação do técnico disponível.
  • A tarefa de serviço a seguir “Sinalizar sistema de chamados”, aciona um serviço do sistema usado pela empresa para enviar ao comunicador do técnico a nova chamada prioritária.
  • A tarefa de serviço “Agendar visita técnica” registra o chamado no sistema que libera a lista de clientes a serem visitados no dia pelos técnicos. Como é uma visita normal, ela é registrada de acordo com o agendamento realizado com o cliente na criação da ficha de atendimento.

Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual

Em sua riqueza de elementos para a representação de processos de negócio, a notação BPMN traz uma classificação de tipos de tarefas.

Elas ajudam a identificar a forma como a tarefa deve ser executada:

Estes elementos e seus comportamentos esperados estão descritos na especificação BPMN (disponível em http://www.omg.org/spec/BPMN/Current). Apesar disto, a identificação de quando usar cada tipo de tarefa ainda é alvo de alguma ambiguidade.

Em uma série de três artigos, trataremos estes tipos de tarefas com mais detalhes para esclarecer as dúvidas comuns. Para facilitar o entendimento, trataremos os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefa abstrata

A tarefa abstrata (abstract task) é a tarefa sem tipo específico.

Tarefa abstrata (abstract task)

Sobre ela, a especificação diz:

“Uma tarefa sem nenhum tipo de especificação é chamada tarefa abstrata (Abstract Task) (ela era referenciada como None Task em BPMN 1.2).” (pag. 154)

Ou seja, a tarefa abstrata (abstract task) pode ser utilizada em modelagens cujo tipo de tarefa ainda não está definido ou em casos onde a tipificação da tarefa simplesmente não se faz necessária. É o caso dos processos executados manualmente.

Um processo de negócio modelado com tarefas abstratas.

Tarefas de interação humana

Para representar tarefas cuja execução envolve a atuação de pessoas em um processo, BPMN sugere dois tipos de tarefa: a user task (tarefa de usuário) e a manual task (tarefa manual).

Tarefa manual (manual task) e Tarefa de usuário (user task)

O que a especificação diz sobre estes tipos de tarefa:

“Uma Tarefa de Usuário (User Task) é uma tarefa típica de “workflow” onde um ator humano desempenha a tarefa com a assistência de uma aplicação de software e é disponibilizada através de uma lista de de trabalho ou outra forma de gerenciamento semelhante. ” (pág 160)

“Uma Tarefa Manual (Manual Task) é uma tarefa que é esperada que seja executada sem o suporte de nenhuma aplicação de execução de processos de negócio ou outra aplicação. Um exemplo disso pode ser um técnico de telefonia instalando um telefone no endereço de um cliente.” (pág 161)

“10.3.4.1 Tarefas com o envolvimento humano
Em muitos fluxos de trabalho, o envolvimento humano é necessário para executar certas tarefas especificadas no modelo de fluxo de trabalho. BPMN especifica dois tipos de tarefas com o envolvimento humano, a Tarefa Manual (Manual Task) e a Tarefa de Usuário (User Task).
A tarefa de usuário é executada e gerenciada por um motor de execução de processos de negócio. Atributos relativos ao envolvimento humano, como as pessoas envolvidas e a renderização de interfaces de usuário (UI) podem ser especificados em grande detalhe.(…)
Uma tarefa manual é uma tarefa que não é gerenciada por qualquer mecanismo de processo de negócio. Ela pode ser considerada como uma tarefa não gerenciada, não gerenciada no sentido de que o motor de processos de negócio não acompanha o início e o fim de tal tarefa.
Um exemplo disso poderia ser uma instrução de papel como base para um técnico de telefonia instalar um telefone em um local do cliente.” (pág 165)

 

Ou seja, uma user task (tarefa de usuário) é a tarefa que é executada através de uma aplicação e gerenciada por uma lista de trabalho(1). Em outras palavras, é a tarefa realizada através de uma aplicação, como um BPMS (Business Process Management Suite), uma aplicação de workflow, uma ferramenta de gestão de cronograma ou qualquer outro sistema que apoie o controle do processo.

Já as tarefas manuais (manual task) são aquelas executadas no mundo físico, sem o controle por parte de uma aplicação.

Aqui há uma confusão comum na interpretação do “uso de uma aplicação”, inclusive replicada em literatura. Para entender claramente a diferença entre elas, é preciso compreender que o que define se uma tarefa é user ou manual task não é se usamos alguma ferramenta para executá-la, e sim se há um sistema controlando a sua execução.

Isto quer dizer que, se temos por exemplo um processo de venda de produtos que é todo executado manualmente, mas em uma determinada atividade uma planilha eletrônica é usada para calcular o valor a ser cobrado do cliente, e um e-mail é enviado ao cliente com o orçamento do produto, ainda assim (apesar de usar uma aplicação de planilha e o software de e-mail para o trabalho) esta será uma tarefa manual, pois não há controle nem gestão sobre quem faz, quando iniciou e quando concluiu a tarefa.

Mesmo utilizando ferramentas como planilha eletrônica e email, ainda assim a tarefa "Apresentar orçamento" neste processo é manual.

Numa modelagem de processo que não será automatizado, e que portanto são pessoas que lerão e interpretarão o modelo, não faz muito sentido essa diferenciação, já que as pessoas, ao lerem a documentação do processo, têm condições de interpretar o modelo mesmo que os tipos de tarefas não estejam esclarecidos.

Na modelagem para automatização, entretanto, isso é muito importante. A tarefa de usuário é aquela em que o processo deve aguardar que um usuário informe o resultado do trabalho, registrando que a mesma foi concluída para então dar seguimento ao fluxo do processo. Já sobre a tarefa manual o sistema não tem nenhum controle, então mesmo que ela seja incluída no modelo, ele “passará batido” por ela.

Por exemplo:
Considere novamente o processo de atendimento de chamado, no qual há uma atividade para um técnico de telefonia para realizar uma visita técnica ao cliente, e que este processo terá sua execução controlada por uma aplicação (por exemplo um BPMS).

Neste processo, podemos ter dois cenários:

Cenário 1: O Técnico acessa uma lista de tarefas, com todos os chamados a realizar, identifica o chamado que está executando e finaliza a tarefa. Com isso, o sistema identifica que a mesma foi concluída e segue o fluxo disponibilizando a próxima tarefa ao respectivo ator responsável. Neste caso, a tarefa está sendo controlada pelo sistema (seu início e fechamento), portanto é modelada como uma tarefa de usuário.

Cenário 2: O Técnico não acessa o sistema. Ele pode, por exemplo, receber ao início do dia uma lista impressa com todos os clientes a visitar. A cada visita, o cliente assina o papel confirmando que o atendimento foi realizado. Ao fim do dia, quando o técnico retorna para a empresa, ele entrega a lista ao Atendente, que então verifica se o atendimento foi realizado e registra no sistema o resultado do atendimento. Neste caso, a tarefa do técnico é modelada como uma tarefa manual, para que fique visível aos que olham o modelo em que momento o mesmo realiza seu trabalho (e que, do ponto de vista do processo de negócio, existe uma dependência da tarefa de "Verificar resultado do serviço" em relação à "Realizar visita técnica", mas o sistema não controla o início nem o fim do trabalho realizado.

Assim, concluímos que, na modelagem com a notação BPMN, o tipo de tarefa não é definido pelo uso de sistemas para realizá-la, e sim se há alguma aplicação sendo utilizada para controlá-la.

_______

(1) Processos podem ser controlados por aplicações de diferentes tipos. Isto já foi tema deste blog no artigo Gerenciando a execução de processos com (ou sem) um BPMS.

 


Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04