Foco NO Cliente ou Foco DO Cliente: o que sua empresa está praticando?

Muito falamos aqui neste blog de BPM, metodologias, filosofias, técnicas e notações que utilizamos para otimizar os processos de nossas organizações, com o objetivo de gerar maior valor para os clientes.

Mas é importante lembrar que nós mesmos, praticantes ou interessados em BPM, também somos clientes no nosso dia a dia. Somos clientes de empresa de telefonia, banda larga, TV por assinatura, serviço de streaming, e por aí vai.

Basta nos colocarmos no papel de cliente, que logo vem a mente vários exemplos de coisas que não gostamos ou que gostaríamos que fossem diferentes nas empresas que prestam serviços para nós. Vejamos alguns exemplos dos chamados “momentos da verdade”, que são os momentos em que um cliente entra em contato com a organização, que na verdade se trata do contato sempre com um processo desta organização:

  • Eu quero contratar apenas internet banda larga para minha casa, mas a operadora empurra junto uma linha de telefonia fixa, mesmo que eu não utilize.
  • Eu gosto muito de uma série específica e de alguns canais de documentários, mas hoje não disponho de um pacote de TV por assinatura que me permita escolher apenas estas opções. Assim, sou obrigado a contratar um plano mais completo (e mais caro) com dezenas de canais que nunca vou assistir.
  • Eu gostaria de marcar e agendar uma consulta num posto de saúde pela internet, e não precisar ter que chegar as 04:00 da manhã para pegar uma senha para atendimento.
  • Eu ligo para o 0800 de algum prestador de serviço, mas sou obrigado a repetir todo o meu problema a cada vez que sou encaminhado para um atendente diferente.

Por que isso acontece? Porque as organizações (sejam públicas ou privadas) estão praticando o “Foco no Cliente” (atenção à preposição!), ou seja: tentam projetar ou inferir aquilo que acreditam que o cliente está buscando, ou mesmo ignoram a experiência do cliente, por conta de alguma característica ou restrição interna da organização. Algumas características básicas da abordagem com foco no cliente:

  • Geralmente baseado na Cadeia de Valor da organização, onde a empresa projeta o que o cliente deseja.
  • O cliente se adapta e escolhe o que as empresas oferecem, na forma como oferecem. Ou seja, não existe muita customização ou adaptação às necessidades específicas de cada cliente.

Vejamos outro exemplo para diferenciar o foco no cliente e o foco do cliente.

Uma rede de varejo com uma variada adega de vinhos, que oferta produtos em diferentes faixas de preço, entendeu que seria uma boa ideia possibilitar aos consumidores  interessados em alguns produtos de linha superior, experimentarem a bebida para avaliarem se o valor é justo pela qualidade da bebida.

É claro que abrir uma garrafa de um vinho caro para oferecer uma prova a qualquer pessoa que se diga interessada não é uma boa estratégia, até porque sabemos que o vinho não mantém suas características por muito tempo depois da garrafa aberta.

Então, a solução pensada foi de oferecer porções de degustação dos principais rótulos, por um custo acessível e de valor agregado para um bom conhecedor de vinho. Para isso, disponibilizaram um equipamento específico que permite servir porções mantendo o vinho da garrafa aberta sob condições de ambiente que permitam mantê-lo aberto por algum tempo sem perder suas características.

Pensando sob este ponto de vista, parece uma excelente estratégia para aproximar o cliente do produto e conduzi-lo para uma possível venda, sem perder o valor agregado do produto.

Desta forma, definiram a seguinte jornada para o cliente obter a taça de degustação:

Perceba que o processo exige que o cliente (que deseja apenas tomar uma taça de vinho!) passe por uma grande quantidade de etapas para realizar este desejo: entrar em várias filas, realizar cadastros, realizar crédito, etc. A burocracia envolvida certamente desestimularia aquele cliente eventual que teria interesse em utilizar máquina, mas desistiria ao saber de todos os passos que são necessários. E quem sabe ele seria o cliente que levaria aquela garrafa de vinho top!

Neste momento podemos fazer um questionamento: este processo está errado?

Conceitualmente e semanticamente o processo está correto, e possivelmente exista um racional justificando cada uma daquelas etapas. Pode ser, por exemplo, que a organização deseja cadastrar e fidelizar o cliente. Ou queira gerar uma base de dados de clientes para mail marketing e promoções. Mas mesmo que o racional utilizado para modelar todas estas etapas no processo seja justificável, o fato é que do ponto de vista do cliente, este processo é ruim e burocrático!

Então como seria este mesmo processo, modelado com foco do cliente? Vejamos:

Percebam a diferença! O que acontece é que neste caso estamos praticando o foco do cliente, ou seja, o processo é baseado nas expectativas do cliente, com a empresa se colocando no lugar do mesmo.

No foco do cliente, os objetivos são:

  • Avaliar apenas o que realmente importa para o cliente, eliminando etapas que não agregam valor ou não são necessárias do ponto de vista do cliente.
  • Reduzir o número de interações, ou seja, a quantidade de vezes que o processo (a organização) precisa se comunicar ou solicitar algo para o cliente.
  • A percepção do cliente se torna a referência sobre a efetividade ou não do processo. Se, por exemplo, meu processo está gerando muitas reclamações no “Reclame Aqui” ou no Procon, isto significa que o processo não está bem, mesmo que atenda a indicadores internos ou benchmarks disponíveis.
  • Melhorar a satisfação do cliente.

Veja que a abordagem do foco do cliente parte de uma premissa bem simples: entender como o cliente vê que sua necessidade deveria ser atendida e estruturar o processo sob a ótica dele. Mas é claro que nem sempre é tão fácil, podem existir fatores que impedem uma transição completa, como por exemplo:

  • O cliente pode não estar disponível para participar do desenho, que é comum no caso de órgãos públicos onde o cliente é o cidadão, ou empresas que oferecem serviços ao grande público. Certamente existem técnicas que permitem captar o feedback do cliente nestes casos (Canal para envio de sugestões/reclamações, Pesquisas de opinião, etc), mas não costuma ser tão efetivo quanto você ter o cliente contribuindo presencialmente.
  • A empresa pode ser regida por regulações e normas que exigem um certo grau de burocratização (Ex: Sarbanes-Oxley), que pode ser visto como desnecessário para o cliente, mas é importante para fins de auditoria e conformidade da organização.

Acreditamos que é importante tentar mudar o paradigma e passar a adotar, sempre que possível, o foco do cliente no desenho dos processos. Mesmo que não seja viável adotar completamente esta abordagem, apenas o exercício de se colocar no lugar do cliente, experimentando o processo, já fornece uma visibilidade muito boa de como vai ser a interação do cliente com os processos, permitindo inclusive antecipar e tratar possíveis problemas.

5 fatores de sucesso para enfrentar os problemas de integrações na automação de processos

Tendo participado de vários de projetos de automação de processos, se tem algo que podemos afirmar como sendo um denominador comum a projetos de automação em empresas das mais diferentes áreas, é dos problemas que surgem quando existe necessidade de integração do processo automatizado com outros sistemas/organizações.

O fato é que problemas relacionados a integrações invariavelmente vão ocorrer, apenas variando de acordo com o grau de complexidade do processo e das integrações em si. Por outro lado, existem sim alguns fatores e cuidados que podem evitar problemas ou facilitar a sua resolução.

Ter conhecimento destes fatores no projeto vai prepará-lo melhor para o que vem pela frente.

Vamos a eles?

1. Ter uma boa governança dos serviços/integrações/funcionalidades disponíveis

Durante a automação do processo, é comum detectar uma ou mais necessidades de integração (ex: salvar alguma informação digitada durante a execução do processo num banco de dados).

Em nossa experiência, boa parte dos problemas que ocorrem nestes casos se devem a falta de governança da organização em relação aos serviços, integrações e sistemas existentes, ou seja, não se sabe se aquela necessidade de integração do processo já se encontra disponível (ex: através de um webservice).

A consequência disso é a necessidade de se discutir do zero esta integração, fazer orçamento e incluí-la no escopo, o que leva a aumento do prazo e custo do projeto. Um fator que minimiza bastante estes problemas é se a organização já trabalha numa Arquitetura Orientada a Serviços, ou simplesmente SOA (mais informações aqui, aqui e aqui), bem como dispor de ferramentas de governança/pesquisa de serviços.

2. Prever o modelo de dados do processo adequado as necessidades de integração

Quando um processo será automatizado, deve-se previamente fazer uma análise para definir o “modelo de dados” do processo, ou seja, as informações que serão visualizadas e manipuladas ao longo da execução do processo (veja aqui para mais informações).

A definição deste modelo de dados costuma ser mais transparente quando estamos falando de informações que ficam visíveis no formulário eletrônico do processo, ou seja, as informações que os usuários vão visualizar/editar ao acessar as tarefas. Mas infelizmente não é tão óbvio quando falamos de integrações.

Por exemplo, se é necessário chamar uma integração para atualizar uma informação no ERP a partir do processo automatizado, pode se descobrir que uma das informações obrigatórias para se chamar esta integração é específica daquele sistema (ex: um determinado identificador), e esta informação não foi prevista inicialmente no modelo de dados.

Com frequência, inclusive, ocorre a situação de que para obter a informação que você precisa para chamar uma integração, é necessário chamar outra integração!

Este fator costuma gerar muitas dores de cabeça, em muitos casos não é fácil prever todas as possibilidades.

3. Ter conhecimento das funcionalidades e limitações do framework de integração do BPMS

Mesmo que inicialmente a empresa tenha adquirido uma solução de BPMS para um processo pontual ou para apenas gerenciar fluxo de trabalho sem integrações com outros sistemas, o fato é que as necessidades da organização mudam. Quando chegar o momento em que as iniciativas de automação de processos passarem a demandar mais inteligência, com integração de dados existentes em outros sistemas, é importante conhecer as funcionalidades e limitações de integração do BPMS.

Por exemplo, alguns questionamentos comuns nestes casos:

  • Posso chamar webservices através do BPMS?
  • Consigo conectar diretamente num banco de dados através do BPMS?
  • Existem adaptadores nativos que permitem conexões com sistemas conhecidos no mercado?
  • O BPMS me permite realizar transformações complexas de dados ao chamar ou obter o retorno de um webservice?
  • Existe algum formato específico de assinatura do serviço para poder ser acionado?
  • Com que tecnologias o BPMS permite fazer integração? Soap? Rest? Corba? EJB? .net? Controle de arquivos no filesystem? Outros?

Este conhecimento é importante para detectar eventuais restrições da ferramenta, identificar a necessidade de utilizar outras ferramentas em conjunto ao BPMS, ou no pior dos cenários até a troca do próprio BPMS. Por exemplo: se o BPMS não é capaz de fazer transformações de dados complexas ao chamar um webservice, então possivelmente será necessária outra ferramenta (ex: uma ferramenta de barramento de serviços) que fará esta transformação no lugar do BPMS, expondo para o BPMS uma versão simplificada do serviço. Neste mesmo exemplo, pode ser que esta ferramenta adicional não exista na organização, e precisa ser previsto a sua contratação e implantação, dentro do escopo do projeto de automação.

Entenda a importância de uma avaliação detalhada sobre recursos ​dos produtos ao adquirir uma plataforma ​BPMS com ​esta coleção de artigos sobre Seleção de Plataformas de BPM.

4. Equipes dos sistemas disponíveis para apoiar o projeto

Parece chover no molhado, afinal se um processo automatizado precisa se comunicar com o sistema X, então a equipe de apoio deste sistema tem que estar envolvida, certo? Bem, temos algumas histórias de iniciativas de automação de processos aprovadas em nível executivo, mas que durante o andamento do projeto as equipes dos sistemas estavam em uma das seguintes condições:

  • Não estavam sabendo do projeto – o popular “cair de paraquedas”  (sim, é comum);
  • Sabiam do projeto e que em algum momento iriam se envolver, mas não tinham nenhum contexto dos objetivos do projeto e o seu papel (tem na prática os mesmos efeitos nocivos da situação anterior);
  • Sabiam do projeto e tinham o contexto, mas não tiveram a alocação reservada para apoiar o projeto (“Eu conheço o projeto e entendo o que devo fazer, mas não sei se vou conseguir ajudá-los ainda neste mês…”).

Quando as equipes dos sistemas começam a se envolver no projeto, é comum surgirem problemas e limitações que não se tinha noção, o que pode ocasionar necessidade de se rediscutir a solução. Aqui o apoio da liderança executiva e da gestão de projetos é fundamental para minimizar os problemas, reforçando a alocação das equipes dos sistemas envolvidos, para se envolverem no projeto de automação o quanto antes, preferencialmente ainda durante as fases de análise e projeto.

5. Atenção à  etapa de testes

Se existem integrações no processo, obviamente as mesmas precisam ser bem testadas, envolvendo as equipes responsáveis pelos sistemas de origem/destino das informações.

Ocorre que na automação de processos, assim como no desenvolvimento tradicional de sistemas, pode ocorrer a tendência de dar ênfase maior apenas a “interface” do processo, que no caso do BPMS são os formulários das atividades enviadas para os usuários. Mas obviamente as integrações que são feitas automaticamente pelo processo devem ser testadas com o mesmo cuidado, verificando se estão retornando ou gravando as informações corretamente.

Isto comumente é realizado utilizando os recursos de rastreamento/auditoria presentes das próprias ferramentas de BPMS (verificando o que está recebendo ou enviando de informações), bem como acessando diretamente o sistema com o qual se tem a integração (para verificar se os dados sendo obtidos/atualizados pelo BPMS estão corretos).

Estas verificações normalmente exigem um conhecimento técnico maior (ex: visualizar payloads em XML, acessar as informações diretamente em tabelas do banco de dados do sistema em questão, etc).

 

Sem dúvida existem outros fatores envolvidos, mas acreditamos que os fatores citados acima dão um bom norte para a equipe do projeto se preparar e enfrentar os problemas que podem ocorrer nas integrações durante a automação de processos.

 

Definindo a equipe nos projetos de BPM

Uma das primeiras dúvidas que costumam ocorrer quando uma empresa começa sua iniciativa de BPM é quais pessoas e perfis deveriam ser envolvidos nos trabalhos. Outro fator complicador é o fato de que podem existir variações na equipe envolvida, dependendo de etapa em que o projeto BPM se encontra.

Vamos começar revisitando, brevemente, as principais etapas do ciclo de melhoria de processos:

  • Modelagem de processos: neste momento o objetivo é modelar o processo atual em execução, gerando o modelo AS IS. Não se entra no mérito do quanto eficiente e efetivo o processo está sendo, ou quais são seus problemas/oportunidades de melhoria. As pessoas envolvidas nesta etapa, assim, devem ter conhecimento de como o processo é de fato executado na organização, mas não necessariamente precisam conhecer todos os seus problemas e ter uma visão mais abrangente
  • Análise de Processos: esta etapa tem o objetivo de coletar informações sobre o desempenho do processo, ou seja, fazer um julgamento de valor do quão adequado e eficiente um processo está sendo. Desta forma as pessoas escolhidas para atuar nesta etapa, além de conhecerem o processo, devem ser capazes também de identificar os problemas que ocorrem no processo e ter uma visão mais abrangente
  • Redesenho de Processos: esta etapa tem o objetivo de definir melhorias num processo para torná-lo mais eficiente e alinhado com os objetivos da organização, gerando o modelo TO BE. As pessoas escolhidas para atuar nesta etapa devem ser representativas dos papéis do processo, sendo importante estarem motivadas com a iniciativa BPM e carentes da mudança, de forma a auxiliar de maneira proativa a definição da visão futura do processo
  • Automação de processos: nesta etapa, o processo TO BE definido na etapa de Melhoria de Processos (TO BE) sofrerá melhorias do ponto de vista tecnológico, de forma a deixá-lo mais rápido, eficiente e automatizado onde for possível

Agora que relembramos as etapas, vamos listar os papéis comumente envolvidos em cada uma delas, descrevendo as suas típicas responsabilidades.

MODELAGEM DE PROCESSOS

Analista de Processos: atua como facilitador, coletando, reunindo e organizando informações do processo, criando o modelo do processo no nível de informação mais adequado
Representante Funcional: contribui com informações sobre as atividades que realiza durante a execução do processo
Analista de Sistemas/Negócios: apoia com informações sobre os sistemas de informação utilizados no processo
Especialista no Assunto: contribui com visão especializada sobre algum aspecto do negócio do processo (ex: um médico de alguma especialidade; num processo de venda online, seria um colaborador com profundo conhecimento da venda com cartões de crédito)

ANÁLISE DE PROCESSOS

Dono do Processo: avalia e aprova o resultado da análise, garante que a investigação dos problemas não será utilizada para achar culpados, mas sim como um meio de melhorar o processo e a organização
Analista de Sistemas/Negócios: apoia na identificação de problemas e limitações dos sistemas atuais
Representante/Líder Funcional: indica os pontos fortes, problemas e oportunidades de melhoria na execução das suas atividades do processo
Especialistas no Assunto: apoia no detalhamento de aspectos de uma determinada função do negócio
Analista de processos: facilitador que conduz o levantamento e documentação do diagnóstico atual do processo

REDESENHO DE PROCESSOS

Liderança Executiva: assegura que o processo irá atender as necessidades da organização, dando suporte e concordando com as mudanças
Dono do Processo: ajuda a garantir que o novo desenho se adéqua aos objetivos requeridos da organização
Representante Funcional/Participantes/Partes Interessadas: qualquer um que participe ou tenha atividades que afetem o processo. Em empresas maiores, pode ser a uma pessoa que represente uma classe. São fundamentais e trabalham com o Dono do Processo, para garantir que seus interesses no desempenho do novo processo sejam atendidos
Cliente: quando possível, envolvê-lo nesta fase aumenta as chances de sucesso
Analista de processos: atua como facilitador e lidera a equipe no desenvolvimento do desenho futuro do processo

AUTOMAÇÃO DE PROCESSOS

Dono do Processo: responsável pelos resultados do processo. Envolve-se na aprovação da proposição de melhorias e na apresentação da homologação, realizando a aprovação da solução automatizada
Gerente de Projetos: responsável por planejar e gerenciar as atividades do projeto de automação. Envolve-se na gestão da comunicação, tempo e custos do projeto em todas as etapas
Analista de Processos: apoia na revisão do processo, garantindo a integridade do negócio durante a avaliação das mudanças tecnológicas. Compartilha responsabilidade com o Analista de Sistemas na etapa de Proposição de Melhorias, envolve-se na validação do processo durante a homologação e implantação
Analista de Sistemas/Negócio: deve conhecer as funcionalidades disponíveis pela tecnologia a ser utilizada na automatização do processo. Compartilha responsabilidade com o Analista de Processos na etapa de Proposição de Melhorias. Responsável pelo detalhamento na implementação, apoia nas etapas de homologação e implantação
Arquiteto de Sistemas: profissional conhecedor da arquitetura de sistemas que suportará a automação de processos. Envolve-se na etapa de Implementação apoiando no projeto técnico com definições de infraestrutura de software
Desenvolvedor: profissionais que realizarão a implementação da automatização do processo, desenvolvendo os componentes de software conforme o detalhamento funcional do Analista de Sistemas/Negócio. Participam da etapa de implementação e de homologação através de correções e ajustes antes da implantação
Equipe de testes: profissionais responsáveis pela garantia da qualidade da solução. Verifica a aderência da solução à especificação funcional, sendo responsáveis pelo planejamento, elaboração e aplicação de roteiros de testes. Envolve-se nas etapas de implementação e homologação
Representante Funcional/Participantes do Processo: participam das etapas de Proposição de Melhorias para definir os requisitos e de Implementação para o detalhamento. Responsáveis pela homologação, validando a solução frente às expectativas e necessidades do negócio, através da verificação da aderência aos requisitos

OUTROS PAPÉIS IMPORTANTES NO GERENCIAMENTO POR PROCESSOS

Além disso, temos também papéis que costumam ser transversais, que dependendo do contexto e do papel podem se envolver em uma, algumas ou em todas as etapas:

Patrocinador e Dono do Processo: orientam sobre os objetivos da iniciativa e e asseguram que o resultado de cada uma das etapas estão adequados e alinhados aos objetivos da organização
Cliente: apoiando o levantamento e definições nas etapas
Designer de processos: atuando em conjunto com o Analista de Processos, focado na elaboração da representação gráfica dos processos
Arquiteto de Processos: responsável pela governança e manutenção do repositório de processos

Perceba que as definições acima refletem cenários comuns de ocorrer nas organizações, mas que não precisam ser seguidos à risca. Alguns exemplos em que é natural, e até esperado, existirem diferenças:

  • É muito frequente que algumas pessoas acumulem papéis/funções. Por exemplo:
    • O Dono do Processo também atua como Representante Funcional de alguma parte do processo
    • O Analista de Sistemas também é o responsável pelos testes
    • etc
  • Podemos ter projetos mais simples, em que não será necessária a participação de um ou mais papéis. Por exemplo, numa automação de processos com poucas integrações com sistemas externos, pode não ser necessária a participação de um Arquiteto de Sistemas
  • Se estamos falando de uma organização que está começando sua iniciativa de BPM, alguns papéis podem nem existir ainda, e precisarão ser definidos posteriormente, como costuma ser o caso do Dono do Processo

No final de contas, independente da quantidade de pessoas, nome dos papéis e quais papéis se deseja envolver formalmente na iniciativa, o importante é todas as pessoas chave estarem envolvidas, bem como todas as informações necessárias estarem disponíveis. Da nossa experiência, estes fatores aumentam consideravelmente as chances de um projeto de sucesso. :-)

 

Problemas comuns na modelagem de processos em BPMN III – Uso de tarefas para sinalizar o resultado de gateways

Continuando a série sobre problemas comuns na modelagem de processos em BPMN (veja os artigos anteriores aqui e aqui), hoje iremos falar de uma situação bastante recorrente que constatamos nos nossos treinamentos, que é o uso de tarefas para sinalizar o resultado de gateways no processo.

Para explicar melhor o que queremos dizer, veja o exemplo abaixo:

Perceba que a pessoa que modelou o processo, para demonstrar os resultados do gateway relativo à atividade “Avaliar Reembolso”, optou por criar duas tarefas em cada um dos fluxos de sequencia ligados ao gateway, nomeando-as como “Aprovado” e “Reprovado”.

O elemento Tarefa (Task) de BPMN se refere a um trabalho que é efetivamente realizado dentro de um processo. Uma tarefa deve, essencialmente, indicar uma ação a ser realizada, que consuma algum recurso (como a tarefa “Avaliar Reembolso” no exemplo acima).

Logo, concluímos que não faz sentido utilizar uma tarefa apenas para indicar uma mudança de status ou sinalizar os resultados de um gateway.

Qual então seria a forma correta de modelar este caso? Veja no exemplo atualizado abaixo:

A abordagem correta (e mais simples!) é simplesmente nomear os fluxos de sequencia ligados ao gateway. No caso acima, cada fluxo de sequência foi nomeado com os resultados possíveis da tarefa de Avaliar reembolso, ou seja, “Aprovado” ou “Reprovado”.

Com isto, o desenho do processo fica mais limpo e fácil de interpretar. Simples e prático! :-)

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! ;-)