Regras do desenho de processo executável

Regras do desenho executável

O nível de detalhamento ideal

Observe o seguinte pedaço de processo abaixo:

Ele especifica três atividades que são executadas pela equipe de compras, após a aprovação de compras, dentro de um processo de compras. Esse fluxo está correto? Novamente, para responder a essa pergunta, temos que questionar qual a sua finalidade.

Se o objetivo desse desenho é treinar as equipes de compras sobre os procedimentos que elas devem realizar, o processo pode estar correto. Se o objetivo é automatizar o processo no Zeev, provavelmente está errado.

Se é a mesma pessoa ou o mesmo conjunto de pessoas que executam essas atividades, em sequencia, como o desenho leva a entender, veja como ficaria o processo automatizado:

• O responsável por compras receberia a primeira tarefa no Zeev, de "Orçar fornecedores". Ligaria para 3 fornecedores, solicitaria propostas comerciais. Anexaria as propostas no sistema e concluiria a tarefa;

• Imediatamente, o sistema criaria uma nova tarefa, para a mesma pessoa. Agora, ela deve ler os orçamentos e escolher o menor preço. O responsável escolhe o melhor fornecedor e finaliza a tarefa;

• Imediatamente, o sistema criaria uma nova tarefa, para a mesma pessoa, solicitando que ela emita uma ordem de compra.

Burocrático, não? Sim, processos muito detalhados, que misturam atividades com procedimentos operacionais geram sistemas e aplicativos burocráticos, que por sua vez geram menor satisfação e engajamento das pessoas.

A regra portanto é: em desenhos visando automação de processos, na grande maioria das vezes, duas ou mais tarefas executadas em sequencia pela mesma pessoa ou grupo de pessoas (dentro da mesma raia), devem ser agrupadas em uma só. Veja como ficaria o desenho:

Essa regra possui uma exceção. Quando as atividades podem, individualmente, levar muito tempo do ator responsável (exemplo: meses, anos), talvez faça sentido, sob o ponto de vista de gestão, quebrá-la em mais tarefas. Com isso, o solicitante ou o gestor poderá ter uma visão mais completa em que ponto, exatamente, a solicitação está.

Trâmite

Observe o desenho abaixo. Ele demonstra um processo simples onde um analista elabora um relatório, envia ele para a secretária do diretor e essa, então, encaminha para o diretor. Esse tipo de trâmite é bem comum, principalmente em processos que hoje ocorrem em formato papel e em pastas.

Ocorre que, quando o processo é automatizado, o trâmite é automatizado. É o Zeev que fica responsável por fazer todos os encaminhamentos necessários. Por isso, atividades que não agreguem valor ao processo, e sim somente façam roteamento de informações, geralmente são desconsideradas no desenho.

Observe em seu desenho visando a automação se existem tarefas humanas cujos títulos utilizem uma das expressões abaixo. São todas candidatas a serem eliminadas ou substituídas por recursos automatizados, como eventos de mensagem, por exemplo.

• Despachar

• Encaminhar

• Avisar

• Enviar

• Comunicar

Veja como nosso processo ficaria mais simples:

O ator externo

Você deve se preocupar com essa regra se o seu processo envolve algum tipo de ator externo à sua organização: um parceiro, um cliente, um fornecedor.

Vejamos o desenho abaixo. É um processo completamente normal. Seu cliente solicita uma proposta, sua equipe comercial monta o orçamento e o cliente pode aprovar ou rejeitar a proposta. Se aprovado, a equipe de entregas despacha o produto.

Quando pensamos em automação do processos, entretanto, você tem que lembrar que as tarefas humanas são executadas dentro do sistema. E aí vem a pergunta: seu cliente irá entrar, 100% das vezes, dentro do Zeev, para pedir um orçamento e para aprovar o orçamento? Pode ser que sim, pode ser que não. Reflita:

• Para o seu cliente (ou qualquer outro ator externo) realizar operações dentro do Zeev, ele precisará ter uma conta nomeada dentro do Zeev. Ele possuirá essa conta? Você irá mantê-la?

• Isso pode impactar no seu licenciamento do Zeev?

• Você tem condições de obrigar o seu cliente ou pessoa externa a entrar no sistema para aprovar orçamentos?

Não existem respostas certas e erradas. Porém, em muitos casos, você não conseguirá, por limitações do seu próprio negócio, obrigar que atores externos entrem na sua plataforma. Nesses casos, seu processo automatizado precisará mudar. Veja o desenho abaixo do processo remodelado, com uma sugestão de como contornar essas limitações:

Infelizmente, sem a possibilidade de seu cliente (pessoa externa) acessar o sistema, você teve que repassar algumas responsabilidades para outro ator, esse sim usuário do sistema. Nesse caso, no exemplo, para um "assistente comercial", que fica responsável por realizar a interface com o cliente, no mundo real.

BPMN compliance

Existe um ditado que diz que "o papel aceita tudo". Isso se aplica ao desenho de processo, também. Quando estamos desenhando um processo para fins de documentação, para treinamento, para "colar na parede", podemos desenhar o processo como bem entendermos. Podemos usar elementos para fins diferentes, podemos desenhar conexões inválidas. Desde, é claro, que nosso público-alvo consiga entender o desenho.

Quando estamos desenhando para fins de automatização, entretanto, o público-alvo é o Zeev. É o motor do Zeev que deve entender primeiro o desenho, para poder executá-lo. Portanto, o desenho do processo deve ser BPMN compliance. BPMN compliance significa que o processo deve ser semanticamente correto e seguir a especificação.

Resumo

Confira no vídeo a seguir as regras fundamentais em desenho BPMN.