Skip to main content

Orientações para a construção dos diagramas de modelagem de processos

Elaborado pelo Escritório de Processos do IFSP / CEPR-PRD - 10/10/22

Durante as sessões de modelagem de processos, realizadas pelo Escritório de Processos do IFSP / CEPR-PRD (aqui definido como EP-IFSP) com os servidores das diversas áreas do IFSP, constatamos as boas práticas abaixo que auxiliam no desenvolvimento do trabalho e melhor entendimento de todos os envolvidos.

Orientações para a construção dos diagramas de modelagem de processos

Na criação dos diagramas de modelagem pede-se observar as seguintes orientações:

  • no EP-IFSP utiliza a Business Process Model and Notation (BPMN) na construção dos diagramas de modelagem de processos do IFSP;
  • utilizar a ferramenta indicada pelo EP-IFSP;
  • observe as diretrizes definidas pelo EP-IFSP para salvar os diagramas de modelagem de processos gerados para o IFSP observando Manual de Modelagem de Processos - Guarda dos diagramas de modelagem

  • padronizações de informações do processo:

    • nomear o processo com um verbo no infinitivo;

    • salvar o nome do arquivo com a versão e data da modelagem, caso o processo ainda não esteja implantado ou em funcionamento (processo como ele é, As Is), colocar também antes da versão "To Be" (processo como deve ser, que será implantado);

    • dentro do desenho do processo colocar um cabeçalho com o nome do processo, a área responsável pelo processo (dono do processo), as pessoas envolvidas na modelagem, o tipo da modelagem (As Is ou To Be), a data e versão do processo;

  • chamar para a discussão do processo a ser modelado, todos os envolvidos nele;

  • nem todos os processo são automatizáveis, ou seja, terão rotinas ou sistemas que realizarão parte ou todo o processo;

  • otimizar o processo antes de automatizá-lo. Na otimização sempre observar:

    • minimizar os trade-offs (escolha) existentes;

    • analisar claramente a necessidade de todos os atores envolvidos no processo;

    • verificar controles existentes e que a necessidade de colocação dos que não existam ainda;

    • nem sempre a otimização do processo está relacionada à diminuição das atividades no processo;

    • normalmente as atividades que são automatizadas são aquelas que não tem uma ação cognitiva, ou seja não demandam verificação ou análise do envolvido nela;

  • criar, dentro do possível, uma modelagem simples do processo:

    • o processo deve ser inteligível por qualquer pessoa, lembrando que além dos envolvidos no processo, muitos que lerão esse diagrama são os "clientes" do processo, ou seja, aqueles que receberão o serviço/produto oriundo dele;

    • não utilizar representações rebuscadas existentes nas ferramentas de modelagem, ater-se à utilização das representações mais simples existentes;

    • quando da existência de muitos elementos no processo e, dessa forma, seu desenho ficar muito extenso, verificar a possibilidade da criação de sub-processos, "encapsulando" seus elementos, facilitando assim a visão macro do processo;

    • para facilitar o entendimento do processo, ele deve ser desenhado colocando seus elementos da esquerda para a direita, que "representam" sua realização no tempo, ou seja, procure não colocar uma atividade que ocorreu após outra debaixo da anterior, mesmo que seja de ocorrência em diferentes raias (atores / papeias funcionais);

  • com relação às atividades do processo:

    • as atividades no processo são ações que serão realizadas, dessa forma devem ser descritas com verbos no infinitivo. Caso haja mais de um verbo na descrição da atividade deve-se verificar a possibilidade de quebra essa atividade em várias;

    • normalmente na modelagem temos atividades mais manuais (Ex: tratar, separar, preencher, enviar) e cognitivas (Ex: verificar, escolher, analisar), após estas devem vir gateways que definirão decisão de fluxo do processo;

    • uma atividade só pode ter um fluxo de processo, de entrada ou de saída, nunca devem sair ou entrar mais de uma seta (fluxo) da atividade. Colocar um gateway de junção (sem nenhuma representação dentro dele) para juntar fluxos que entrem no processo e um gateway de decisão (com representação dentro dele, como exclusivo, paralelo, etc..) quando houver mais de um fluxo saindo da atividade;

  • com relação aos gateways (decisão e junção de fluxo) do processo;

    • não colocar uma descrição no gateway, não o representar como uma pergunta, visto inclusive que ele pode ter mais de duas saídas de fluxo, não representa respostas somente de sim ou não, mas de várias alternativas de fluxo;

    • os gateways determinam qual o fluxo a ser adotado quando for atendida uma situação específica, dessa forma, em cada fluxo de saída (seta) deve ser colocada uma descrição suscinta e clara para que o processo corra por esse caminho;

  • com relação aos eventos do processo:

    • os eventos no processo são ações que já foram realizadas, dessa forma devem descritos com verbos no passado;

    • o evento de início do processo é o fator que faz com que o processo se inicie, sua descrição deve expressar isso;

    • eventos intermediários devem ser colocados sempre que se deseja um marco no processo, seja ele relacionado à finalização de uma sequência de atividades ou um marco temporal no processo;

    • colocar os eventos relacionados à ocorrência ou períodos que as mesmas devam ser realizadas/concluídas;

    • o evento final é sempre o produto/serviço entregue pelo processo, sua descrição deve expressar isso;

  • criar uma piscina específica para os artefatos onde serão colocados os documentos, sistemas, banco de dados, associados aos elementos do diagrama. Caso os documentos sejam Documentos ou Processos eletrônicos já existentes, utilizar a sua nomenclatura, facilitando assim a sua localização para uso;

  • atentar-se para o formato orientado para a impressão dos diagramas;

Back to top