APOSTILA DE

BPM
BUSINESS PROCESS
MANAGEMENT

Fevereiro 2024
Sumário
1. BPM – Business Process Management.................................................................................. 3
1.1. 6 fases do Ciclo BPM ..................................................................................................... 3
1.2. Planejamento de Projeto no ciclo BPM ......................................................................... 3
1.3. Estrutura de Planejamento de Projeto de BPM ............................................................ 4
1.4. Modelagem AS-IS e TO BE. ............................................................................................ 5
1.5. Execução do Ciclo BPM ................................................................................................. 5
1.6. Monitoramento do processo......................................................................................... 5
1.7. Principais siglas em BPM ............................................................................................... 6
1.8. Análise e Melhoria de Processos ................................................................................... 6
1.9. Ciclo BPM não é linear .................................................................................................. 7
1.10. Fase mais importante do ciclo BPM .......................................................................... 8
1.11. Ciclo BPM e Ciclo PDCA ............................................................................................. 8
1.12. Produtos/Artefatos de cada fase ............................................................................... 8
1.13. Simulação de Processo .............................................................................................. 9
2. Modelagem de Processos.................................................................................................... 10
2.1. Quando devo modelar um processo? ......................................................................... 10
2.2. Qual o nível de modelamento de processos? ............................................................. 10
2.3. Modelei meu processo e agora? ................................................................................. 11
2.4. Cadeia de valor e arquitetura de processos ................................................................ 11
2.5. Exemplo de modelo de processos ............................................................................... 15
2.6. Modelagem de processos a partir do Zero.................................................................. 15
2.7. Jogo dos 7 erros do modelo de processo .................................................................... 16
2.8. 5 erros comuns da modelagem de processos ............................................................. 17
2.9. Diretrizes de Modelagem de Processos ...................................................................... 17
2.10. Diagrama descritivo e POP ...................................................................................... 17
2.11. Diagrama de detalhamento de atividades .............................................................. 18
2.12. Validação dos processos .............................................................................................. 19
2.13. 5 Segredos da modelagem de processo .................................................................. 19
2.14. Glossário de processo.............................................................................................. 21
2.15. Exemplo de arquitetura de processo....................................................................... 21
2.16. Modelagem e desempenho de processo ................................................................ 22

2
 1. BPM – Business Process Management
1.1. 6 fases do Ciclo BPM

FASE1: PLANEJAMENTO

Assim como qualquer projeto as definições iniciais começam também pela definição do
ESCOPO, CUSTO, PRAZO, EQUIPE, STAKEHOLDERS, etc. Porém existem elementos mais
específicos do BPM, são eles Método > Metamodelo > Notação > Ferramenta

FASE 2: MODELAGEM

Aqui é feito o levantamento de dados, mapeamento dos processos e a validação dos

processos. Aqui pode ser realizado entrevista, brainstorming, Questionário, Análise de
documentos, etc. Ao fim da validação os gestores validam a modelagem.

FASE 3: SIMULAÇÃO DE PROCESSOS

É uma fase que, em geral, é opcional, pois os modelos matemáticos são complexos e caros.

FASE 4: EXECUÇÃO

Naturalmente ocorre em cada empresa (principalmente quando for AS IS)

FASE 5: MONITORAMENTO

Aqui é onde acompanho o processo, seus indicadores e seus requisitos.

FASE 6: Aqui se atua sobre os riscos mapeados.

1.2. Planejamento de Projeto no ciclo BPM

4 dimensões são fundamentais ESCOPO, PRAZO, CUSTO e QUALIDADE, dentro do projeto

BPM alguns elementos específicos são fundamentais, são eles:

• Método: Qual será a metodologia utilizada para mapear o processo, dentre as diversas
disponíveis. Ele influência muito o Escopo, pois muda prazo, custo (equipe,
ferramentas, etc). Existem referências em literatura mas cada empresa pode ter sua
abordagem.
• Metamodelo: O que será representado? Cadeia de Valor, estrutura organizacional,
mapa de processos, etc? Vou incluir atores, requisitos, riscos, etc? Conforme essa
definição será possível escolher o diagrama com elementos mais adequados ao
metamodelo.
• Notação: Que método de BPMN (Business Processo Management Notation), EPC
(Event Process Chain), etc.
• Ferramenta: Qual apoio de software será escolhido para representação do processo,
como BIZAGE, CAMUNDA, HEFLO, etc.

ESCOPO: A modelagem será AS IS, TO BE, quais as fronteiras (portas de entrada e saída), etc.

CARDÁPIO DE PROCESSOS: Dentro de um escopo eu tenho diversas possibilidades de

mapeamento, em diversos níveis, com diversos atores, etc. Caso a opção for por um
detalhamento em níveis muito detalhados, o prazo e o custo do projeto são afetados.

3
 1.3. Estrutura de Planejamento de Projeto de BPM

Baseado nas teorias da folha A3, a estrutura de planejamento engloba os seguintes elementos:

CONTEXTO: Descrição do contexto e do problema do cliente. Deve contextualizar o projeto

principalmente nos seguintes aspectos: negócio, tecnologia, pessoas, organização e processos

OBJETIVOS: Enumerar e descrever os objetivos a serem alcançados com o projeto

ORGANIZAÇÃO DO PROJETO: Identificar o organograma do projeto, o modelo de governança

explicando os grupos envolvidos com seus papeis e responsabilidades e a equipe do projeto

Organograma: O organograma abaixo define papéis e responsabilidades dos

integrantes do projeto

Modelo de Governança: O modelo de governança do projeto é sintetizado pela figura

abaixo

Grupo Responsabilidade Quantidade Pessoas

Equipe do projeto: Listar os membros da equipe do projeto, considerando todas as

áreas envolvidas, e seus contatos

ABORDAGEM TÉCNICA: Explicação da metodologia que será utilizando, detalhando as fases,

atividades e produtos. Podem ser incluídas outras informações como responsáveis

PLANO DE MUDANÇA: Descrever como deve ser o procedimento em caso de solicitação de

mudança de escopo/requisitos. Devem ser explicitados o processo, as responsabilidades e os
possíveis tratamentos que serão dados às solicitações de mudança. Eventuais mudanças no
escopo, prazo do projeto ou interrupções não previstas que possam impactar
significativamente o andamento dos trabalhos (prazo ou dedicação de nossos profissionais)
serão discutidas previamente antes de tomarem efeito. Qualquer ajuste no escopo do projeto
ou nos valores contratados necessitará um documento de solicitação de mudança, assinado
por ambas as partes. Nenhuma das partes será obrigada a executar tais alterações sem
assinatura anterior do formulário de solicitação de mudança.

PREMISSAS E RESTRIÇÕES: Premissas: Tudo que foi assumido como verdade para a elaboração
deste plano de projeto. Restrições: Tudo que limita/restringe o projeto. Questões contratuais
podem aparecer com premissas e/ou restrições

PLANO DE COMUNICAÇÃO: O plano de comunicação poderá conter todos os eventos que o

projeto precisa comunicar tais como divulgação de resultados, treinamentos, go lives, etc.
Entretanto, o mais importante é que este plano seja associado às ações de envolvimento dos
stakeholders com o objetivo de deixá-las explícitas.

4
CRONOGRAMA DE PROJETO: O cronograma detalhado com as tarefas, marcos, dependências e
recursos é apresentado no arquivo do Project.

PLANO DE RISCOS: O plano de riscos deve conter desde a identificação dos riscos, com sua
classificação, conjunto de ações para os riscos que terão algum tratamento, conforme o caso. O
plano de risco, ao invés de uma visão pessimista deve ter uma visão preventiva

ACOMPANHAMENTO DO PROJETO: Descrever a rotina de monitoramento, apresentação de

status, reunião de análise crítica e monitoramento dos riscos. Deve ter periodicidade,
envolvidos, modelos de apresentação bem como a forma de acompanhamento de eventuais
questões relevantes ao gerenciamento do projeto.

ANEXOS: Todos os arquivos, documentos e referências que são importantes a execução do

projeto.

1.4. Modelagem AS-IS e TO BE.

Na modelagem AS-IS o foco é o entendimento de como o processo funciona atualmente, é

uma etapa comum para os analistas, pois ele ajuda a compreender como a organização
funciona e da margem para um eventual modelo TO BE.

O modelo TO-BE é um modelo, geralmente baseado no AS-IS, onde se propõe melhorias,

outras versões ou o desenho inicial de um processo. Quando um TO BE for baseado no AS IS, é
importante demonstrar que atividades, tarefas, elementos, etc, mudaram.

Porém existe também um modelo SHOULD BE, que é a visão ideal do processo, que em
geral não pode ser mapeado, mas pode servir de base após o mapeamento AS IS ou pode ser
usado para o desenho inicial de um processo TO BE.

1.5. Execução do Ciclo BPM

Está é a etapa onde as pessoas executam um determinado processo no dia a dia. No AS IS é

a análise de continuidade do processo mapeado, para verificar se de fato ele roda conforme o
mapeamento inicial ou se existem atividades esporádicas, etc.

No caso do TO BE, é a verificação de que treinamentos e apoios são necessários para que o
processo novo possa ser executado. É importante um período de operação assistida, onde o
analista “assiste” o novo processo, para auxiliar as pessoas e a organização a absorver o novo
paradigma.

Com o processo rodando, eu consigo coletar dados para elaboração de indicadores de

requisito de negócio daquele processo, para que ele possa ser continuamente monitorado e
melhorado, para verificar as dificuldades dos usuários, mas também as resistências de uso de
novos paradigmas. Isso auxilia o analista a determinar recursos para que o processo esteja
conforme o TO BE, incluindo novas mudanças de paradigma.

1.6. Monitoramento do processo

Aqui os indicadores são monitorados, que são requisitos de controle definidos para aquele
processo e o monitoramento ocorre verificando o processo em diversas instâncias.

5
 A coleta dos dados que alimentam os indicadores são um momento crucial para orientação
do analista na fase de monitoramento, pois precisam entregar um grande nível de confiança.
Os dados coletados, não podem ser alvo de dúvida ou desconfiança por parte do analista ou
dos gestores do processo.

É importante validar, em função do tempo, se os indicadores definidos de fato permitem

um bom nível de monitoramento e gestão do processo tanto em sua análise qualitativa (se
serve ou não para boa gestão do processo) e se as estimativas de meta estabelecidas
inicialmente são realistas, tanto se os dados estiverem demonstrando variações acima ou
abaixo das estabelecidas.

O monitoramento ajuda também a orientar as ações de melhoria contínua.

Ferramentas do BPMNS (Business Process Management System) que incluem dashboards

podem auxiliar no monitoramento, porém quaisquer ferramentas que entreguem
confiabilidade podem ser utilizadas.

1.7. Principais siglas em BPM

BPM: Business Process Management – Gestão de Processos de Negócio

BPA: Business Process Analysis – Análise de Processo de Negócio – Análise de um modelo AS IS

BPI: Business Process Improvement – Melhoria do Processo de Negócio – Implantação de

Melhorias, modelagem de um processo TO BE

BPR: Business Process Reengineering – Reengenharia de Processo de Negócio – Abordagem

mais radical, se análise de processos AS IS, redesenho mais revolucionário do processos

BPMN: Business Process Management Notation – Líder de mercado da notação de modelagem

de processo de negócio.

BPMMM: Business Process Management Maturity Model – Modelo de Maturidade da Gestão

do Processo – Serve como referêncial para organização, como um “norte” para que a
organização saiba onde está e o que será necessário para se chegar ao nível de maturidade
pretendido.

BPMNS: Business Process Management System – Sistema de Gestão de Processo de Negócio –

É um sistema ou aplicação que auxilia ou direciona os processos em uma organização.

1.8. Análise e Melhoria de Processos

Existem 2 grandes etapas dentro da Análise Melhoria de Processos a AS IS e o TO BE.

AS IS, tem o foco de encontrar problemas e riscos e o TO BE, propõe soluções para mitigar,
atenuar ou eliminar os problemas e riscos do processo.

Dentro da análises do processo para predição de melhorias podem ser usadas, entre
outras, 3 ferramentas, como análise SWOT, analisar da perspectiva dos Stakeholders
(criticando a partir da posição de cada interessado/envolvido) e Análise de Habilitadores, onde
o negócio é analisado em diferentes perspectivas, como por exemplo:

• Recursos Humanos (RH): avaliação de questões relacionadas à estrutura

organizacional, definição de papéis/funções, habilidades necessárias e treinamentos;

6
 • Workflow (W): avaliação de questões relacionadas aos passos, gargalos no fluxo de
execução, falta de paralelismo ou idas e vindas repetitivas do processo
• Tecnologia da Informação (TI): avaliação de questões relacionadas às aplicações,
sistemas ou banco de dados;

• Regras e Políticas (RP): avaliação de questões relacionadas às regras impostas internamente

ou externamente, como adequação de normas, definição de prazos, aplicação de punições,
padronização;

• Motivação e Métricas (MM): avaliação de questões relacionadas à definição de metas e

acompanhamento de ações;

• Infraestrutura (I): avaliação de questões relacionadas ao espaço físico, disponibilidade de

recursos e equipamentos;

• Colaboração (C): avaliação de questões relacionadas à comunicação, planejamento de

trabalho, integração de artefatos e percepção ou compreensão da colaboração;

• Sustentabilidade (S): avaliação de questões relacionadas ao impacto ambiental, uso de

recursos não renováveis ou desperdício de recursos.

Após estas análises é necessário incluir o ral de preposições em uma matriz de

priorização, para que sejam avaliadas também as melhorias que tem maior potencial de trazer
benefícios ao processo TO BE.

1.9. Ciclo BPM não é linear

Em desenvolvimento de produtos, existe uma obrigatoriedade na sequencia linear, por

conta da necessidade de resolver problemas antes de seguir adiante, em fases mais onerosas
do projeto, atualmente ciclos de desenvolvimento ágeis, quebram um pouco a ideia do
cascateamento de atividades.

7
 Porém o ciclo BPM, as etapas não podem onerar a ENTREGA DE VALOR, caso uma fase
esteja demasiadamente demorada, pode ser “pulada” ou simplificada para que exista entregas
de valor parciais.

1.10. Fase mais importante do ciclo BPM

Via de regra, não existe uma fase mais importante, porém a execução ineficaz pode gerar
problemas na entrega de valor.

Existem organizações onde o planejamento é simplificado, por um modelo claro de

metodologia, notação e escopo que já é utilizado. Ou em outras organizações a modelagem é
usada como meio para chegar a melhorias, mas sem tanta dedicação de tempo e recursos para
modelagem.

Diferente das etapas clássicas de desenvolvimento de produtos e serviços, a não

linearidade, permite que o analista busque “atalhos” e técnicas, para não cair em tentações de
construir modelos robustos, mas não conseguir entregar resultados ou entregar resultados
falhos, por quebra de expectativas (Prazo, Custo, etc).

1.11. Ciclo BPM e Ciclo PDCA

O Ciclo PDCA é considerado “PAI’ de todos os ciclos de melhoria para análise de diferentes
análises, pois ele resume em 4 etapas simplificadas para direcionar basicamente qualquer tipo
de implantação ou plano de ação.

P – PLAN: Planejar – Definir o escopo do que será realizado

D – DO: Fazer – Onde se executa e implementa as ações

C – CHECK: Checar – Verificar a eficácia e o resultado da execução

A – ACT: Agir – Onde são padronizadas as implantações e também coletadas as informações

para novos ciclos de melhoria dentro do processo alvo.

1.12. Produtos/Artefatos de cada fase

Abaixo estarão elencados apenas alguns entregáveis de cada fase, para exemplificar
didaticamente esta fase.

1) PLANEJAMENTO
• Método
• Notação
• Meta modelo
• Ferramenta
• Escopo

2) MODELAGEM
• Ata ou ficha de Processos
• Cadeia de Valor
• Arquitetura de processos
• Modelo de processo AS IS

8
 • DataBook do processo

3) SIMULAÇÃO DE PROCESSOS
• Relatório da simulação indicando gargalos e problemáticas
• Planos de ação para mitigar, atenuar ou eliminar problemas e riscos

4) EXECUÇÃO
• Modelo de processos executáveis
• Plano de comunicação
• Plano de capacitação e Gestão de mudanças
• Plano de operação assistida (onde “n” instâncias do processo são acompanhadas para
depurar melhor os detalhes de sua execução)

5) MONITORAMENTO
• Dashboard de indicadores
• AS BUILT ocasionais do AS IS ou do TO BE modelado

6) MELHORIA
• Documentos de análise
• PLanillha de priorização de melhorias
• ROadMap de elhorias
• Modelo do processo TO BE
• Data Book do processo TO BE

1.13. Simulação de Processo

É uma fase opcional, onde são utilizadas regras matemáticas de probabilidade e estatística com
uso de aplicações de software, para encontrar gargalos e riscos em um processo. O uso da
probabilidade usa um padrão de inferência denominado de “Wha if?” que é uma pergunta
derivada do inglês que sugere “E se?”, ou seja, e se eu aumentar o nível de produtividade de
uma atividade, ou reduzir custos por em outra atividade, qual será o possível resultado disso
para o processo como um todo?

Exemplo:

Uma determinada organização deseja aumentar sua capacidade de oferta, porém desejam
testar 2 hipóteses e avaliar os impactos, sendo:

Hipótese 1: Abrir uma filial do negócio com gestão própria

Hipótese 2: Incluir no negócio esquema de franquias

As simulações parametrizadas, entregam resultados esperados para cada um dos cenários

propostos (TO BE) e entrega relatórios segundo os parâmetros de input, no exemplo os
impactos analisados seriam TEMPO, CUSTO e INVESTIMENTO.

9
Na simulação, foi possível ainda incluir outro cenário possível, de implantação de um 2º turno
dentro da estrutura existente.

Com base nos resultados, foi possível planejar as decisões do negócio, sendo eles:

Abertura de 2º turno no ANO 1. Abertura de uma unidade filial em outro estado no ANO 2.
Entre o ANO 3 e ANO 5 a expansão de franquias nos estados em que as unidades dirigidas
estariam instaladas.

2. Modelagem de Processos
2.1. Quando devo modelar um processo?

Processos sempre são realizados, mesmo quando parecem altamente caóticos. Neste
ponto pode haver uma confusão, achando que por ainda não estar maduro ele não pode ser
modelado.

Modelar um processo AS IS, ajuda a compreender além do processo a cultua da

organização e as oportunidades de melhoria podem ser relevantes para aquela e outras áreas.

2.2. Qual o nível de modelamento de processos?

Realizar a arquitetura de processos da organização, iniciando pela cadeia de valor no nível 0,

onde estão os Processos da figura abaixo:

A partir daí, os níveis são desdobrados, conforme o escopo do projeto BPM definido
pelos objetivos alinhados, podendo ir para nível 1, 2 ou 3 dependendo das características da

10
organização e do processo que está sendo mapeado. Os níveis são referenciados por
subprocessos, cada vez que é necessário um detalhamento maior em um subprocesso.

Já o detalhamento do macro processo, onde estarão os fluxos de atividades em níveis

de detalhamento altos, vai depender de qual o objetivo. Se é um objetivo mais estratégico,
para tomada de decisão em um modelo AS IS, ele pode ser mais simplificado. Por outro lado,
se for um nível de execução para instrução de trabalho em um TO BE por exemplo, pode ser
necessário um nível de detalhamento para cada etapa do sistema para que ele possa ser
operado inclusive usando o modelo para o treinamento dos atores responsáveis pelo fluxo.

2.3. Modelei meu processo e agora?

O primeiro passo é a validação em camadas deste modelo de processo.

• 1º passo: Fazer uma checagem individual do modelo além da simulação do software.

• 2º passo: Um cross checking da equipe de processos é fundamental para verificar as
regras de notação e o conteúdo.
• 3º passo: Validação do processo, pelos gestores e se for o caso, pela governança da
organização.

Com a modelagem validada, é possível usar o modelo do trabalho como uma “POP –
Procedimento Operacional padrão”, para que seja usado como treinamento.

Este processo pode ser usado para simulações de processo e identificações de gargalos,
problemas, riscos e alçada de tomada de decisão.

Também pode ser usado para automatização de processos, substituindo processos

humanos, por processos informatizados.

Pode ser usado para análise e gestão de riscos de compliance.

2.4. Cadeia de valor e arquitetura de processos

A cadeia de valor, nada mais é do que o encadeamento dos processos da empresa,

quais atividades se relacionam para que o processo possa transformar uma entrada em
uma saída que entrega valor.

Em geral existem 3 macroprocessos.

11
 Os macroprocessos são os processos “CORE”, são processos primários da organização.
Dizem respeito ao processo chave. Por exemplo, para um fabricante de móveis, uma
processo de negócio é a fabricação de mobiliário.

Os processos de apoio existem para complementar o negócio da empresa e por fim os

processos de gestão que como o nome diz, gerenciam os demais processos da organização.

12
Baseado na cadeia de valor da organização, eu desdobro cada processo em níveis (camadas) e
deste nível 0 (ZERO), permite a definição da arquitetura de processos.

13
A partir desta arquitetura de processos, eu começo a detalhar pela BPMN o processo e seus
subprocessos, chegando em alguns casos ao nível operacional.

A composição da cadeia de valor e da arquitetura de processos de uma organização,

depende muito do ramo de negócio de cada organização e também dos objetivos dos gestores
de processos, mas em geral, podem ser descritos conforme a estrutura demonstrada.

14
 cadeia de
valor

arquitetura
de processos

Fluxo de
Processos

Diagrama de
atividade

2.5. Exemplo de modelo de processos

Em uma farmácia, a compra do medicamento pode ser realizada no balcão ou via drive
thru. A receita é cadastrada no sistema e existe uma verificação automática, para verificar
possíveis alergias do paciente ao medicamento e se o seguro de saúde do paciente, cobre
parte ou todo o custo do medicamento.

Evento de início: Quando a receita chega

Evento final: Se sucesso, o medicamento é retirado pelo paciente. Se falha, a receita gera
restrição e o paciente não retira o medicamento.

Atividades: Os nomes dos eventos, são sempre com verbo no infinitivo + substantivo.

Gateways: Balcão ou Drivethru, alergia ou não, seguro cobre ou não

Atores: Farmacêutico, Sistema (quando executa scripts), paciente

Recursos: Receita, elementos químicos, medicamento, sistema

Regra de negócio: O paciente paga a diferença do que o seguro de saúde não cobre

Com estes elementos é possível criar o diagrama BPMN do processo exemplificado.

2.6. Modelagem de processos a partir do Zero

Todo mapeamento começa pelo levantamento de dados: Onde são realizadas entrevistas
com os participantes e interações com o processo. Verificar se o mapeamento é AS IS ou TO BE,
qual a notação, ferramenta e a Arquitetura de processos.

Sugestão de passo a passo para construção do modelo do processo.

1º PASSO: Incluir a Pool e as raias com o nome dos atores do processo

15
 2º PASSO: Evento de inicio

3º PASSO: Momentos de transferir o processo de atores

4º PASSO: Completar os Gateways

5º PROCESSO: Incluir o(s) evento(s) de fim. Esta etapa define a lógica do processo

6º PASSO: Voltar desde o inicio da lógica para incluir os objetos de dados, banco de dados e
anotações.

7º PASSO: Validação criando cenários, imaginar possibilidades “What If?”

8º PASSO: Cross checking antes de consolidar o modelo quanto a lógica e também o padrão
de notação da organização

2.7. Jogo dos 7 erros do modelo de processo

Caixas de atividades
Evento de
não devem receber
inicio sem
duas setas de
descrição
entrada

Atividades
abstratas, sem Gateway
tipologia inclusivo, para
divergência de
caminho único
Conjugação
verbal da 1ª
atividade

Não existe
evento de fim

A pergunta do
Gateway é realizada
por um bloco de
atividade

16
 2.8. 5 erros comuns da modelagem de processos

1º ERRO: Não identificar processos sem objetivos que não agregam valor, ou que não estão
ligados com o objetivo inerente aquele processo ou com a estratégia da organização;

2º ERRO: Diferenciar a Cadeia de Valor e a Arquitetura de Processos, para que seja possível
situar o processo modelado dentro da estrutura de valor da organização;

3º ERRO: Não definir a porta de entrada e de saída do processo

4º ERRO: O modelo não pode seguir sempre o caminho em que o processo sempre é para o o
sucesso, sem considerar as falhas e os “Wha tif?” do processo.

5º ERRO: Processo excessivamente complexo, que não possa ser lido e acaba se tornando
pouco usual. O processo precisa ser útil a organização.

2.9. Diretrizes de Modelagem de Processos

São os padrões definidos pela organização para modelagem de processos, para que as boas
práticas sejam seguidas por todos os analistas ou áreas que mapeiam processos, evitando
divergências de notação nos modelos criados.

Exemplos: Fontes usadas, raias na horizontal, ferramenta utilizada, padrão de uso dos
artefatos.

No modelo de diretrizes podem ser contidos as definições de conceitos, exemplos do que é

certo e errado na modelagem e pontos de atenção na representação de processos.

2.10. Diagrama descritivo e POP

Em contextos certificatórios, como ISSO 9001 por exemplo, são mais comumente usados
descritivos de processo, representados por um POP – Procedimento Operacional Padrão.

17
 Quando os analistas mapeiam o processo é importante compreender se a organização
documento atividades de forma descritiva ou em forma de diagrama do processo. Porém em
geral, se houver necessidade do processo descritivo, é importante entregar no databook do
processo, o diagrama do processo mais o descritivo.

Existem organizações que exigem também as Instruções de trabalho, neste caso é

importante questionar se um mesmo processo requer as 3 dimensões de notação e
representação documentadas.

2.11. Diagrama de detalhamento de atividades

Não é uma instrução detalhada de processos e sim uma estrutura de elementos de uma
determinada atividade com grande nível de detalhes.

A figura abaixo demonstra quais são os elementos em um diagrama de atividade e não existe
necessariamente um sentido de fluxo, mas uma distribuição lógica destes elementos pelo
diagrama. O diagrama de atividade tem similaridade com o diagrama de tartaruga de uma
atividade.

18
Em geral o diagrama é incluído no mapeamento de processos, para atividades mais críticas
dentro de um processo, independente do nível em que ela aparece.

2.12. Validação dos processos

Na validação de processos queremos mostrar ao cliente e/aos stakeholders a

representação do mesmo de forma abstrata, ou seja, o modelo é uma representação dentro de
um padrão de notação que gera uma compreensão mais profunda de um determinado
processo.

Uma forma interessante de validar, é montar um data book do processo e enviar com
antecedência todo material, para que durante a validação exista mais substância nos
comentários e eles convirjam para melhorias da notação e da compreensão do processo.

Agendar com antecedência e dar sentido de importância para validação. Se o mapeamento

foi trabalho de uma equipe multifuncional para um grupo de clientes, trazer todas estas
pessoas para apresentação.

Lembrando que se o processo for muito complexo e/ou grande, é interessante demonstrá-
lo de forma prática, mas sem perder os detalhes importantes que vão conduzir as melhorias.

Os envolvidos precisam contribuir para uma versão final do mapeamento e o book pode
ser atualizado e a versão validada pode ser entregue para todos. Lembrando que a versão
validada pode ser tanto a AS IS quanto a TO BE.

2.13. 5 Segredos da modelagem de processo

O objetivo número 1 do modelo do processo, é comunicar de forma compreensível como um

processo ocorre.

1º) No nome da atividade

19
 Usar o padrão de nome com verbo no inifitivo + substantivo, de maneira resumida, por
exemplo:

“Elaborar um relatório de entrega”

2º) Evitar falta de uniformidade no tamanho dos elementos, tendo em um diagrama

elementos do mesmo tipo de tamanhos diferentes
3º) Não bagunçar os textos dos elementos, textos as vezes do lado direito, as vezes do
lado esquerdo
4º) Colocar tipos das atividades, não deixar atividades abstratas.
5º)Setas de fluxos se cruzando, setas tortas, etc. Alguns padrões de notação de
algumas organizações, definem até mesmo onde as setas devem sair dos elementos e
onde devem entrar.

Exemplo:

ANTES

DEPOIS

20
 2.14. Glossário de processo

Se no seu modelo de negócio houverem muitos termos técnicos, siglas, termos específicos, etc,
torna-se importante, a criação de um glossário no book do processo, para que o diagrama não
fique contaminado com informações excessivas e também para que o leitor do processo não se
confunda com estes termos no diagrama sem eles terem um glossário de consulta incluídos no
mesmo documento de apresentação.

2.15. Exemplo de arquitetura de processo

21
 2.16. Modelagem e desempenho de processo

1) Desempenho ruim do processo e modelo ruim

Problemas no desempenho, não existem informações que corroborem para clareza do processo,
nem quanto aos seus elementos, nem quanto aos detalhes, além disso a notação também não
está boa, com muita abstração e um fluxo que vai e volta (caracol).

22
 2) Desempenho ruim do processo, modelagem boa

Aqui a modelagem melhorou, com tipos das atividades, anotações, sentido de fluxo. Mas
faltam detalhes por exemplo de como a vodka é misturada na atividade 5, o que deixa o
desempenho do processo ruim.

3) Desempenho bom, modelagem ruim

Na prática o processo está acontecendo com nível de detalhes que permite sua correta
execução, porém, por falha do time de analistas ou dos validadores, o processo fica mal
modelado, dificultando sua leitura e representação.

Falta de uniformidade no tamanho dos elementos, setas tortas, evento de fim com alção
(EVENTO DE FIM NUNCA PODE TER AÇÃO), Gateway com pergunta (GATEWAY NUNCA FAZ
PERGUNTA), entre outras representações ruins.

23
 4) Desempenho bom e modelagem boa

Nível de detalhamento das atividades bom, que mostra a qualidade do processo e a modelagem
usa todas as boas práticas, além de uniformidade da representação e uso de eventos.

24