Coletar, documentar, organizar e manter as informações sobre os processos é sempre um grande desafio para as organizações e para os profissionais da disciplina de gerenciamento por processos de negócio (BPM).
A modelagem de processos é uma importante atividade do ciclo de vida BPM, pois o modelo de processo materializa o conhecimento da organização sobre um determinado fluxo de atividades.
Podemos modelar processos visando diferentes objetivos:
- Modelagem para descoberta, aplicada para alinhar o entendimento básico do que a organização faz em um processo
- Modelagem para análise da situação atual (AS IS), para entender como o processo funciona e ajudar na identificação de problemas e gaps
- Modelagem de proposta da visão de futuro (TO BE), com uma proposta de alterações do AS IS visando um processo mais otimizado
- Modelagem para automatização em um BPMS (TO DO/TO RUN), definindo o modelo de processo executável
- Modelagem para robotização com RPA, definindo o fluxo de ações operacionais para robotizar uma atividade
- Modelagem para manual de processo, documentando e orientando a execução do trabalho
- Modelagem de processos para auditoria, formalizando o processo organizacional geralmente para adoção de iniciativas relacionadas a certificações de qualidade.
Esta reflexão sobre o objetivo da modelagem – para quê estamos criando o modelo – é essencial para entendermos que informações precisam ser coletadas e documentadas em complemento ao diagrama em cada caso. Não apenas o objetivo, mas o nível de detalhamento e as informações requeridas por cada um desses tipos de projetos também é diferente. Até mesmo os elementos usados na modelagem (se você estiver usando a notação BPMN) podem ser diferentes. Já discutimos um pouco sobre isso no artigo Um BPMN para cada propósito de modelagem de processos.
Portanto, a primeira coisa que você precisa fazer antes de começar a modelar ou documentar o processo, é saber que tipo de modelagem você precisa fazer.
Isso é importante para que a equipe não gaste tempo levantando e documentando informações que não são relevantes para o projeto que está sendo conduzido, o que é um risco muito comum em atividades de modelagem e análise de processos.
Existem diversos métodos e ferramentas para coletar e formalizar, de forma documentada, as informações de um processo. É comum profissionais criarem templates de canvas para reunir essas informações, adaptarem uma tabela SIPOC, adaptarem o 5W2H ou criarem modelos próprios.
Com algumas variações, basicamente estas são as informações que o analista de processos deve buscar formalizar para cada tipo de modelo.
Modelagem para Descoberta do Processo
Este tipo de modelo é realizado com frequência para se desenhar uma visão inicial do escopo do processo, dando visibilidade sobre onde ele começa, como termina, e quais são as suas principais atividades, como as pessoas envolvidas coordenam seu trabalho para entregar o resultado do processo.
Costuma ser uma modelagem simplificada e em alto nível.
Na modelagem para a descoberta do processo, o foco maior está em gerar uma visão integrada do trabalho realizado e dos participantes envolvidos e como estão relacionados através de um fluxo de trabalho.
Raramente é realizada alguma documentação complementar, mas nestes casos, geralmente documenta-se:
- Objetivo: para quê o processo existe
- Gatilho: o que inicia o processo
- Entradas: informações de entrada do processo
- Saídas: o que o processo gera ao final, os possíveis fins que pode chegar
- Para cada atividade, a identificação do responsável por executá-la e uma breve descrição
Este modelo pode ser o ponto de partida para a realização de outras atividades como análise ou redesenho do processo.
Modelagem da situação situação atual (AS IS)
Este tipo de projeto visa coletar informações analíticas que possibilitem avaliar como a organização realiza o processo atualmente (AS IS). Costuma ser uma modelagem do processo em nível de tarefas. Se o processo analisado for muito longo, é recomendável dividí-lo em etapas, utilizando subprocessos.
Neste tipo de projeto de modelagem, o foco maior está em reunir, principalmente, informações sobre o ambiente de negócios, políticas e regras que regem o processo atual e informações quantitativas que possibilitem identificar desperdícios, riscos, gaps e outros problemas.
Nestes casos, geralmente documenta-se:
- Objetivo: para quê o processo existe
- Gatilho: o que inicia o processo
- Interfaces do processo (outros processos que podem acontecer antes ou depois do processo em análise)
- Entradas: informações de entrada do processo
- Saídas: o que o processo gera ao final, os possíveis fins que pode chegar
- Para cada atividade, a identificação do responsável, o método de alocação, uma breve descrição, recursos utilizados, custos dos recursos, tempo de execução, tempo de espera, sistemas utilizados, regras que devem ser atendidas, riscos que podem estar associados ao descumprimento da atividade, indicativo de valor agregado
- Para cada gateway, os resultados possíveis, a % frequência de cada resultado, regras e políticas que determinam o comportamento do gateway
- Para cada evento, a média de tempo que costuma levar para ser acionado
- Uma lista de problemas identificados (diagnóstico), uma matriz GUT que ajude a avaliar a criticidade do problema, uma descrição dos seus impactos (custos, qualidade, tempo perdido em função do problema)
As reflexões geradas na análise deste modelo geralmente são utilizadas como ponto de partida para a proposta de melhorias, que se concretizarão em um novo modelo do processo (TO BE) que é descrito a seguir.
Modelagem de novo desenho de processo mais otimizado (TO BE)
Este tipo de modelo reflete uma visão futura do processo desejado (TO BE), ao incluir nele uma ou mais mudanças propostas, geralmente a partir das melhorias identificadas no modelo AS IS.
Ao contrário do que muitas pessoas imaginam, o modelo TO BE não é único. É bastante comum que hajam várias versões de modelo TO BE para um processo, no qual diferentes alternativas de desenho do fluxo podem ser comparadas para se tomar a decisão sobre como o processo deverá ser implementado.
Além disso, um conjunto de mudanças em um processo pode apresentar prazos de implantação diferentes. Mudanças pontuais em tarefas ou em funcionalidades de sistemas existentes podem ser feitas mais rapidamente do que mudanças estruturais, alterações em políticas ou aquisição de novas ferramentas. Assim, é possível que o processo TO BE tenha versões parciais que permitam visualizar as mudanças progressivas à medida que forem implementadas.
Raramente é realizada alguma documentação aprofundada até que se tenha uma definição final do processo, mas os modelos TO BE podem conter descrições sobre:
- Objetivo: para quê o processo existe
- Gatilho: o que inicia o processo
- Saídas: o que o processo gera ao final, os possíveis fins que pode chegar
- Para cada atividade, a identificação do responsável e uma breve descrição
- Sinalizações visuais que permitam identificar qual ou quais elementos estão mudando
Os modelos TO BE são o ponto de partida para outros projetos de modelagem, que podem incluir modelagem para automação com BPMS, para robotização com RPA, para criação de manuais de execução ou para auditoria.
Modelagem para automatização em um BPMS (TO DO/TO RUN)
A modelagem para automatização envolve transformar o modelo de processo em um requisito de software. O diagrama criado será utilizado como referência pelo BPMS para gerenciar e comunicar os envolvidos sobre quando devem realizar alguma ação em um determinado caso de processo em execução.
O nível de detalhe de um processo para automação em um BPMS está no nível de processo de trabalho, em que cada tarefa executada por cada participante e as regras lógicas de roteamento do trabalho estão claros.
Chamamos de TO DO a especificação do processo a ser automatizada, que contém as instruções para que a equipe de desenvolvimento possa replicar na ferramenta de BPMS o fluxo, a lógica, as regras, as interfaces e as interações planejadas para que o processo possa ser executado. Já o TO RUN é o modelo efetivamente implementado dentro da ferramenta e que será executado pelo sistema.
A documentação necessária para se criar o modelo TO DO ou TO RUN dependerá significativamente do BPMS adotado pela empresa, mas em geral são documentadas características minuciosas como:
- Gatilho: o que inicia o processo
- Modelo de dados: todos os dados a serem manipulados pelos participantes do processo no decorrer do processo e seus tipos de dados.
- Para cada atividade, a regra para identificar o usuário executor, os campos do modelo de dados que farão parte do formulário da tarefa, regras de preenchimento e validação de dados no formulário da tarefa, prazo para responder à atividade (quando aplicável), regras de escalação (caso o prazo se esgote) e opções de resultado da atividade
- Para cada gateway, que informação no modelo de dados será utilizado para verificar qual o caminho a ser seguido
- Para cada evento, informações complementares de acordo com o tipo (quantidade de tempo no caso de timer, condição lógica no caso de conditional, etc)
Para saber mais sobre este tema, confira estes webinares:
Modelagem para robotização com RPA (Robotic Process Automation)
A robotização de trabalho é um tema emergente dentro da disciplina de BPM. Embora a automação e os robôs já estejam presentes há muitos anos nos processos de manufatura, seus homônimos robôs de software começaram a se popularizar recentemente nos escritórios.
Um robô dificilmente executa um processo de negócio inteiro, mas pode atuar em uma ou mais atividades do processo, executando um nível mais baixo de ações, que podem ser modeladas como um fluxo de processo operacional.
O modelo do processo para RPA foca em modelar a sequência lógica que o robô deverá seguir e as ações necessárias para que ele execute um determinado trabalho. Já a documentação de um processo para robotização com RPA geralmente inclui, além de uma descrição do trabalho e da identificação do gatilho de início e de resultado da tarefa, a descrição dos detalhes operacionais em cada passo como: abrir o aplicativo, inserir nome de usuário, inserir senha, apertar botão, clicar no menu, etc. o suficiente para que o desenvolvedor que treinará o robô possa configurar as instruções.
Veja mais no artigo Como modelar fluxos de processos para RPA usando BPMN.
Modelagem para orientar a execução do trabalho (Manual do Processo)
Este tipo de modelagem tem como objetivo materializar as instruções de trabalho a serem seguidas pelos executores dos processos. Uma das grandes expectativas das organizações é que, ao ter seus processos documentados, eles magicamente serão seguidos corretamente pelos seus colaboradores. Infelizmente as coisas não são tão simples, elas passam por questões como: a qualidade da documentação, a atualização do seu conteúdo, a facilidade de encontrar e acessar essa documentação.
Mesmo assim, é um dos tipos de projetos mais comuns e normalmente acontece após o redesenho do processo, como uma das melhorias implantadas em um projeto TO BE.
Na modelagem para orientar a execução do processo, o diagrama do processo é um guia que apresenta quais atividades devem ser executadas por quem, e cada atividade tem uma descrição complementar com um guia dos procedimentos a serem executados para que a atividade seja dada como concluída, e o processo possa assim seguir adiante para as próximas ações.
O nível de detalhe de um processo para documentação precisa ser cuidadosamente avaliada. Diagramas muito detalhados se tornam muito extensos e difíceis de ler. Assim, é mais comum que eles tragam as principais atividades, e elas sejam detalhadas em descritivos complementares. Em geral, esse tipo de material tem detalhes complementares como:
- Objetivo: por quê o processo existe
- Gatilho: o que inicia o processo
- Políticas e regras relacionadas ao processo
- Sistemas e ferramentas utilizados no processo (e links para os manuais de uso dos sistemas, quando aplicável)
- Informação sobre a última atualização do documento
- Para cada atividade, uma matriz RACI indicando quem é o responsável por executar, quem é responsável pelo seu resultado, quem pode ser consultado em caso de dúvidas e quem deve ser informado sobre seu andamento, além de um descritivo dos passos operacionais (ou um Procedimento Operacional Padrão / Instrução de Trabalho em anexo), que pode conter guias, prints de telas, etc., além do prazo padrão para execução da atividade.
- Para cada gateway, qual a regra empregada para determinar o caminho a ser seguido
- Para cada evento, informações complementares que permitam compreender o gatilho da sua execução (quantidade de tempo, condição lógica, origem/destino das mensagens, etc.)
Modelagem de processos para auditoria
Outro tipo de projeto comum que leva a modelagem de processos é quando a organização busca formalizar seus processos para atender a regulamentações ou certificações de área, como ISO, CMM, etc.
Nesses casos, é comum que a documentação para esses processos seja semelhante à usada para manualização, como descrito no item acima, já que a organização deve prover os meios e o conhecimento necessário para que o trabalho seja executado de forma padronizada. Além disso, também é comum que algumas atividades chave do processo tenham a identificação das evidências a serem geradas na execução, ou seja: alguma “prova” de que a atividade foi realizada dentro dos padrões desejados, e que possa ser posteriormente verificada pelos auditores para validar que o processo foi executado em conformidade com o processo definido pela empresa.
Como podemos ver, dependendo do tipo de modelagem que está sendo criada, tanto os elementos da notação quanto as informações complementares a serem registradas para um processo podem variar bastante.
Não deixe de complementar o entendimento desse artigo com a leitura: Um BPMN para cada propósito de modelagem de processos.
Esperamos que esse conteúdo possa servir como um guia para os seus próximos projetos de BPM!
