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.

BPMN 2.0 – Novos Diagramas e Elementos: Coreografia no detalhe

No artigo anterior (BPMN 2.0 – Novos Diagramas e Elementos: Introdução a Coreografia) introduzimos o assunto a respeito do Diagrama de Coreografia. Neste artigo nossa proposta é detalhar a coreografia, apresentando os principais elementos BPMN utilizados para uma modelagem completa do diagrama em questão.

O diagrama de coreografia abaixo apresenta os detalhes do comportamento da coreografia, descreveremos logo abaixo cada um dos elementos. 

Elementos do diagrama de coreografia

1. Evento (Event)
Os eventos são elementos comuns a ambos diagramas de coreografia e de orquestração. Representam algo que acontece durante o curso do processo e podem ser de três tipos distintos: Inicio, intermediário e fim.

Dos eventos utilizados no diagrama de orquestração, aplica-se na coreografia os eventos:

Início: simples (none), tempo (timer), condicional (conditional), sinal (signal), múltiplo (multiple).
Intermediário: simples (none), condicional (conditional), ligação (link) e múltiplo (multiple). Atachados a atividade: cancelamento (cancel), compensação (compensation), condicional (conditional), sinal (signal) e múltiplo (multiple).
Fim:  simples (none) e terminate.

Para uma leitura mais detalhada sobre eventos veja os artigos sobre eventos de início e fim e eventos intermediários.

2. Atividade (Activity)
especificação da OMG BPMN versão 2.0, descreve interações entre processos como sendo Message Exchange Patterns (MEPs) ou padrões de troca de mensagens.  A MEP é a Atividade (Activity) de uma coreografia, chamada também de Tarefa de Coreografia (Choreography Task).

Atividade - Interação entre os participantes

3. Desvio (Gateway)
Nos processos de orquestração, os gateways são usados para criar caminhos alternativos ou paralelos para o processo. Da mesma forma acontece na coreografia: as interações entre os participantes pode acontecer em seqüência, em paralelo, ou por meio de seleção exclusiva.

4. Participante (Participant)
Os participantes fazem parte da Atividade de coreografia e corresponde a uma piscina (pool) do diagrama de orquestração.

O participante que inicia a troca de mensagens (parte ativa) é representado pelo fundo branco, já o participante que recebe o primeiro comunicado (parte passiva) está representado com o fundo preenchido (aqui em cinza). O participante que inicia a comunicação pode ser representado na extremidade superior ou inferior da atividade, como demostrado na imagem abaixo:

As atividades de coreografia da esquerda e direita são equivalentes

5. Fluxo de Sequência (Sequence Flow)
É utilizado para demostrar a sequência das atividades de coreografia e só pode se conectar a outros objetos do fluxo como os eventos, gateways  e atividades de coreografia.

6. Mensagem (Message)
Representa a informação contida  na comunicação entre duas entidades ou processos. No caso da coreografia, representa a informação transmitida na comunicação entre os participantes.

A mensagem de início, transmitida pelo participante inicial, é representada pelo envelope de fundo branco e a mensagem de retorno (quando houver) é representada pelo envelope de fundo preenchido.

Mensagem - Elemento que representa a informação contida na comunicação entre os participantes.

Interação entre participantes  e atividade multi-instance
No exemplo abaixo, os participantes Cliente e Concessionária interagem na atividade Compra de automóvel e os participantes Concessionária e Fornecedores de Peças interagem na atividade Solicitação de Orçamento.

Atividade de Coreografia - Representa uma interação entre dois participantes (pools)

A atividade da esquerda, representa a comunicação entre o participante Cliente (que inicia a comunicação) e o participante Concessionária. Nesta atividade o Cliente comunica seu interesse na compra de um automóvel. Já a atividade da direita demostra que um dos participantes pode ser multi-instance: o participante Fornecedores de Peças representa um papel atribuído a mais de um participante (a concessionária solicita orçamento para vários fornecedores de peças).

Atividade de subcoreografia (Sub-choreography task)
Uma atividade de subcoreografia agrega a identificação de todos os participantes envolvidos em um subconjunto de atividades de coreografia, e representa uma coregrafia refinada em interações (várias trocas de mensagens). Pode ser declarado mais de um destinatário, mas apenas uma iniciação pode ser realizada. Graficamente, a atividade pode ser demostrada de forma contraída (collapsed), representado pelo símbolo “+” indicando a existência de outro nível de detalhe. A mesma Atividade de subcoreografia pode ser representada de forma expandida (expanded) apresentando o seu conjunto de detalhes na própria coreografia.

A Imagem acima demostra a atividade de subcoreografia contraída(collapsed), representada pelo símbolo “+” indicando a existência de outro nível de detalhe, e sua representação expandida (expanded).

Com estes elementos, BPMN 2.0 possibilita a criação de um diagrama focado em documentar uma visão objetiva do processo, que pode ser compartilhada entre os participantes sem revelar os pormenores do negócio de cada organização envolvida.