Fundamentals of Business Process Management - Marlon Dumas - Sel

13/08/2020 Fundamentos de Gestão de Processos de Negócios
Página 1
Fundamentos de Gestão de Processos de Negócios
https://translate.googleusercontent.com/translate_f 1/192
Página 2
Marlon Dumas r Marcello La Rosa r

Jan Mendling r Hajo A. Reijers
Fundamentos de
Processo de negócio
Gestão
Página 3
Marlon Dumas Jan Mendling

Instituto de Ciência da Computação Instituto de Negócios da Informação
Universidade de Tartu Universidade de Economia de Viena
Tartu, Estônia e negócios
Viena, Áustria
Marcello La Rosa
Queensland University of Technology Hajo A. Reijers
e NICTA Departamento de Matemática
Brisbane, Austrália e Ciência da Computação
Universidade de Tecnologia de Eindhoven
Eindhoven, Holanda
ISBN 978-3-642-33142-8 ISBN 978-3-642-33143-5 (e-book)

DOI 10.1007 / 978-3-642-33143-5
Springer Heidelberg New York Dordrecht Londres
Número de controle da Biblioteca do Congresso: 2013932467
ACM Computing Classification (1998): J.1, H.4, H.3.5, D.2
© Springer-Verlag Berlin Heidelberg 2013

Este trabalho está sujeito a direitos autorais. Todos os direitos são reservados pelo Editor, seja no todo ou em parte
o material diz respeito, especificamente os direitos de tradução, reimpressão, reutilização de ilustrações, recitação,
difusão, reprodução em microfilmes ou de qualquer outra forma física, e transmissão ou informação
armazenamento e recuperação, adaptação eletrônica, software de computador ou por metodologia semelhante ou diferente
agora conhecido ou desenvolvido no futuro. Isentos desta reserva legal são breves trechos em conexão
com críticas ou análises acadêmicas ou material fornecido especificamente para o propósito de inscrição
e executado em sistema informático, para uso exclusivo do adquirente da obra. Duplicação de
esta publicação ou partes dela são permitidas apenas de acordo com as disposições da Lei de Direitos Autorais do
A localização do editor, em sua versão atual, e a permissão de uso devem sempre ser obtidas na Springer.
As permissões de uso podem ser obtidas através do RightsLink no Copyright Clearance Center. Violações
estão sujeitos a processo judicial nos termos da respectiva Lei de Direitos Autorais.
O uso de nomes descritivos gerais, nomes registrados, marcas comerciais, marcas de serviço, etc. nesta publicação
não implica, mesmo na ausência de uma declaração específica, que tais nomes estão isentos do relevante
leis e regulamentos de proteção e, portanto, livre para uso geral.
Embora os conselhos e informações neste livro sejam considerados verdadeiros e precisos na data de publicação
declaração, nem os autores, nem os editores, nem a editora podem aceitar qualquer responsabilidade legal por qualquer
erros ou omissões que podem ser cometidos. O editor não oferece nenhuma garantia, expressa ou implícita, com respeito
ao material aqui contido.
Ilustração da capa : “Drawing Hands” de MC Escher © 2012 The MC Escher Company-Holland. Tudo
direitos reservados. www.mcescher.com
Impresso em papel sem ácido
Springer faz parte da Springer Science + Business Media (www.springer.com)
Página 4
Para Inga e Maia - Marlon

Para Chiara e Lorenzo — Marcello
Para Stefanie - Jan
Para Maddy, Timon e Mayu-Hajo
Página 5
Prefácio
Os processos de negócios representam um ativo essencial das corporações. Eles têm impacto direto
sobre a atratividade de produtos e serviços percebida pelo mercado. Eles
determinar tarefas, empregos e responsabilidades e, com isso, moldar o trabalho de cada em-
ployee. Os processos integram sistemas, dados e recursos dentro e através da organização
zações e qualquer falha podem paralisar a vida corporativa. Processos determinam
o potencial de uma organização para se adaptar a novas circunstâncias e cumprir
um número crescente de requisitos legislativos. Os processos influenciam a receita
potencial tanto quanto moldam o perfil de custo de uma organização.
No entanto, ao contrário de outros ativos corporativos, como produtos, serviços, força de trabalho,
marca, ativos físicos ou monetários, a importância dos processos de negócios não
foi apreciado por um longo período. Apesar do fato de que os processos são a força vital
de uma organização, eles não desenvolveram o status de cidadão principal na diretoria
discussões e processos de tomada de decisão gerencial.
Apenas as crescentes demandas por globalização, integração, padronização, inovação
vação, agilidade e eficiência operacional, e o desafio relacionado de encontrar mais
variáveis no ecossistema corporativo que podem ser otimizadas, finalmente aumentaram
o apetite por refletir e, em última instância, melhorar os processos de negócios.
Em resposta, nas últimas duas décadas, um conjunto abrangente de ferramentas, técnicas,
métodos e metodologias inteiras foram desenvolvidos fornecendo suporte para todos
estágios do ciclo de vida do processo de negócios. Contribuições relevantes foram feitas por
diversas disciplinas, como Engenharia Industrial, Gestão de Operações, Qual-
gestão da sociedade, gestão do capital humano, governança corporativa, conceitual
modelagem, gerenciamento de fluxo de trabalho e engenharia de sistema.
Gerenciamento de processos de negócios (BPM) é a disciplina que agora enfrenta a dificuldade
culto, mas tarefa gratificante de consolidar e integrar a infinidade desses ap-
proaches.
Este livro é a primeira e mais atualizada contribuição que enfrenta e domina esta
desafio. Ele captura de forma sucinta o status atual do BPM e traz
ordem e consistência em abordagens que muitas vezes foram desenvolvidas, discutidas
e implantados de forma isolada.
vii
Página 6
viii Prefácio
"Fundamentos da Gestão de Processos de Negócios" deriva seus méritos de seu

base sólida nas últimas pesquisas aplicadas de BPM. Baseando-se em bases científicas
práticas significa capitalizar em evidências em vez de depender de confiança. este
claramente diferencia esta publicação tão necessária de muitos de seus predecessores.
Em particular, dá ao BPM a credibilidade de que uma disciplina ainda jovem e crescente
requer.
O livro em si também é uma vitrine convincente para a importância de uma nova classe de
processos, ou seja, longa vida, negócios internacionalmente distribuídos, complexos e flexíveis
processos. Neste caso, é o processo de escrever um livro em conjunto envolvendo quatro
autores em quatro países diferentes. A equipe enfrentou esse desafio de maneira brilhante
e o resultado é uma compilação impressionante dos pontos fortes individuais de cada
autor com base em uma compreensão compartilhada dos fundamentos essenciais de BPM e
uma paixão comum pelo tópico.
Não tenho dúvidas de que este livro moldará o conjunto de ferramentas e, espero, ainda mais
a mentalidade das gerações atuais e futuras de profissionais de BPM. Este pub-
comunicação tem o potencial de se tornar um catalisador significativo para o sucesso futuro do BPM
estabelecendo um senso comum para os fundamentos de BPM sobre o qual ele pode
ser desenvolvido e adaptado às circunstâncias individuais. O livro fornece
a consistência e o rigor necessários dentro e entre os diversos e em rápido crescimento
comunidade de profissionais e pesquisadores comprometidos e apaixonados pela
méritos da organização baseada em processos.
Finalmente, e talvez acima de tudo, o livro é uma referência excelente para todos os alunos
dentes que estão ansiosos para aprender mais sobre e querem abraçar o fascínio de
BPM. Este livro de BPM, há muito ausente, aborda uma grave lacuna dentro do
Comunidade BPM, ou seja, a falta de recursos para facilitar a introdução de sub-
jects em educação superior e corporativa. Tornando o BPM mais acessível para o futuro
os tomadores de decisão garantem que os processos desempenhem o papel que merecem.
Brisbane, Austrália Michael Rosemann
Página 7
Prefácio
Primeiro, domine os fundamentos.

Larry Bird (1957–)
O Business Process Management (BPM) é um campo especial por mais de um motivo.

Em primeiro lugar, BPM é uma encruzilhada de pontos de vista múltiplos e bastante diferentes. O negócio
os gerentes são atraídos por BPM por causa de sua capacidade demonstrada de entregar resultados
provas de desempenho organizacional, conformidade regulatória e qualidade de serviço
ity. Os engenheiros industriais veem o BPM como uma oportunidade para aplicar a manufatura bem conhecida
desenvolver técnicas de otimização no contexto de organizações que prestam serviços
em vez de produtos físicos. Finalmente, especialistas em Tecnologia da Informação (TI) ap-
precede o fato de que o BPM lhes fornece uma linguagem compartilhada para se comunicar
com as partes interessadas da empresa. Além disso, tecnologia de automação de processos de negócios
permite que especialistas de TI implementem e monitorem sistemas de TI de uma forma que esteja alinhada
com a visão que os stakeholders do negócio têm da organização. Em outras palavras,
BPM é um campo de fronteira que serve como um cadinho para separar
comunidades. Para quem já experimentou como gerentes de negócios, industriais
engenheiros e profissionais de TI muitas vezes parecem viver em mundos diferentes,
campo de interesse é uma oportunidade notável para alcançar uma compreensão conjunta do
funcionamento interno de uma empresa.
Uma segunda característica especial do BPM é que ele é praticado ativamente e
pesquisado ativamente. Em outras palavras, é um campo onde existem comprovados e
práticas estabelecidas, bem como desafios abertos. As empresas em todo o mundo são automobilísticas
realizando iniciativas de BPM com o objetivo de, por exemplo, superar seus concorrentes
ou atender às demandas de autoridades regulatórias. Acadêmicos em áreas como computador
ciência, ciência da gestão, sociologia e engenharia estão trabalhando no desenvolvimento
otimização de métodos e técnicas para apoiar tais iniciativas. É apropriado ver
BPM como um campo de “teoria na prática”. Por um lado, as demandas práticas inspiram o
desenvolvimento de novos métodos e tecnologias. Por outro lado, o aplicativo
desses métodos e tecnologias, na prática, retroalimenta as pranchetas em
universidades e centros de pesquisa.
Depois de ensinar BPM a milhares de alunos e profissionais no passado
década, sentimos fortemente a falta de um livro didático que estruture nossos cursos
e para permitir que nosso público estude por si mesmo além da aula e lição de casa
ix
Página 8
x Prefácio
atribuições. Esta situação não se deve à falta de excelentes livros sobre BPM - em
fato, há um bom número deles, mas sim devido à interdisciplinaridade e
natureza de BPM em constante evolução.
Existem excelentes tratamentos de BPM de uma perspectiva de gestão de negócios
, mais notavelmente Harmon's Business Process Change e Sharp e McDermott's
Modelagem de fluxo de trabalho . Ambos os livros fornecem estruturas conceituais úteis e
conselhos práticos e definitivamente devem estar nas estantes (ou melhor, nas mãos)
de praticantes de BPM. No entanto, é necessário um histórico introdutório e preferir
anos de experiência habilmente para apreciar verdadeiramente os conselhos dados nestes livros.
Além disso, esses livros dão pouca atenção aos aspectos de tecnologia, como processos de negócios
sistemas de gestão e ferramentas de inteligência de processos.
Do outro lado do espectro, outros livros adotam uma ciência da computação
específico para BPM, como Van der Aalst e Van Hee's Workflow Management e
Weske's Business Process Management , ambos focados na modelagem de processos, anal-
ysis e automação para cientistas da computação. Em um nível mais especializado, pode-se
encontrar uma variedade de livros com foco na modelagem de processos usando linguagens específicas - para
exemplo Método e estilo BPMN de Silver .
Neste contexto, decidimos que era hora de reunir nossos
experiência de ensino em BPM, a fim de entregar um livro que:
• Adota o BPM como um campo interdisciplinar, alcançando um equilíbrio entre os negócios
aspectos de gestão e TI.
• Abrange todo o ciclo de vida do BPM, desde a identificação de processos até a análise
lisando, redesenhando, implementando e monitorando esses processos.
• Segue uma abordagem passo a passo pontuada por vários exemplos, a fim de
tornar o conteúdo acessível a alunos com pouca ou nenhuma experiência em BPM.
• Contém vários exercícios testados em sala de aula, tanto dentro de cada capítulo quanto em
o final dos capítulos, para que os alunos possam testar suas habilidades de forma incremental e
os instrutores têm material para trabalhos de classe, trabalhos de casa e projetos.
• Conta com uma linguagem de modelagem de processos madura e padronizada, ou seja, BPMN.
No espírito de um livro, cada capítulo contém uma série de exames elaborados

ples e exercícios. Alguns desses exercícios estão espalhados ao longo do capítulo e
destinam-se a ajudar o leitor a colocar em prática conceitos e tecnologias
técnicas expostas no capítulo em cenários concretos. Esses exercícios "no capítulo"
são emparelhados com soluções de amostra no final do capítulo. Além disso, cada capítulo
Ter termina com uma série de exercícios adicionais para os quais nenhuma solução é fornecida.
Os instrutores podem desejar usar esses últimos exercícios para as atribuições.
A maioria dos capítulos também contém "caixas destacadas" que fornecem informações complementares
visões em um tópico específico. Essas caixas são tangenciais ao fluxo do livro e
pode ser ignorado por leitores que desejam se concentrar nos conceitos essenciais. Sim-
Da mesma forma, cada capítulo termina com uma seção de "Leituras Adicionais" que fornece
dicas para leitores que desejam aprofundar sua compreensão de um tópico específico.
Para melhor servir aos nossos leitores, criamos um site para coletar mate-
riais: http://fundamentals-of-bpm.org. Este site inclui slides, registro de palestras
exames, exames de amostra, links para recursos relacionados e exercícios adicionais.
Página 9
Prefácio XI
O livro foi elaborado para apoiar cursos de uma ampla variedade. Um curso aprofundado
no BPM poderia cobrir todos os capítulos de uma forma equilibrada. Para ajustar o conteúdo em
um semestre, porém, pode ser necessário sacrificar um ou dois capítulos. Se este
foi necessário, nossa sugestão seria pular o capítulo. 4 ou 10 . Um BPM introdutório
o curso pode pular o Chaps. 2 , 4 , 7 e 10, embora ainda forneça uma imagem consistente
do campo. Um curso sobre automação de processos para alunos de TI pode pular o Chaps. 2 , 5
e 6 . Um curso sobre modelagem de processos se concentraria em Chaps. 2 a 5 , e possivelmente
Indivíduo. 9 se a intenção é produzir modelos de processos executáveis. Capítulos 3 e 4
pode ser integrado em um curso semestral mais amplo sobre modelagem de sistemas. Finalmente,
um curso de melhoria de processos para estudantes de administração pode enfocar o cap. 3 e
Caras. 5 a 8 . Naturalmente, cap. Eu poderia encontrar seu lugar em qualquer um dos cursos acima.
Cada capítulo pode ser entregue como uma combinação de aulas teóricas e aulas
sessões. Capítulos mais curtos ( 1 , 2 , 3 , 5 , 6 e 10 ) podem ser ministrados em uma aula e em uma
sessão de trabalho de classe. Os capítulos 4 , 8 e 9 podem exigir duas aulas e duas aulas
sessões cada. O Capítulo 7 pode ser ministrado em duas aulas e duas aulas
sessões, ou pode ser entregue em uma aula e uma sessão de trabalho pulando
o conteúdo em filas e análise de fluxo.
Este livro é o resultado de muitos anos de prática educacional tanto no
níveis de graduação e pós-graduação em mais de meia dúzia de instituições, incluindo
Eindhoven University of Technology (Holanda), Queensland University of
Tecnologia (Austrália), Humboldt University of Berlin (Alemanha), University of
Tartu (Estônia), Universidade de Economia e Negócios de Viena (Áustria) e Na-
Universidade Internacional da Colômbia. O material neste livro também serviu como um
base para cursos de treinamento profissional ministrados a organizações na Austrália, o
Holanda e outros lugares. Somos gratos aos milhares de alunos que mais
os últimos anos nos deram feedback construtivo e incentivo.
Também devemos muito aos nossos muitos colegas que nos encorajaram e forneceram
com feedback durante todo o processo da ideia para o livro-texto. Nós gostaríamos de
obrigado Wil van der Aalst, Raffaele Conforti, Monika Malinova, Johannes Prescher,
Artem Polyvyanyy, Manfred Reichert, Jan Recker, Michael Rosemann, Matthias
Schrepfer, Arthur ter Hofstede, Irene Vanderfeesten, J. Leon Zhao e Michael zur
Muehlen, que forneceu feedback construtivo sobre as versões preliminares do livro. Fabio Casati
e Boualem Benatallah nos deu o incentivo inicial para começar a escrever
processo. Menções especiais são devidas a Matthias Weidlich que nos forneceu
sugestões personalizadas e abrangentes, e Remco Dijkman que compartilhou conosco
material didático que serviu de entrada para o Chaps. 2 e 9 .
Tartu, Estônia Marlon Dumas

Brisbane, Austrália Marcello La Rosa
Viena, Áustria Jan Mendling
Eindhoven, Holanda Hajo A. Reijers
Página 10
Conteúdo
1 Introdução ao Gerenciamento de Processos de Negócios . . . . . . . . . . . . . 1

1.1 Processos em todos os lugares. . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Ingredientes de um Processo de Negócios. . . . . . . . . . . . . . . . . . 3
1.3 Origens e história do BPM. . . . . . . . . . . . . . . . . . . . . 8
1.3.1 A Organização Funcional. . . . . . . . . . . . . . . . 8
1.3.2 O nascimento do pensamento processual. . . . . . . . . . . . . . . . 10
1.3.3 O Risco e a Queda do BPR. . . . . . . . . . . . . . . . . . 12
1.4 CicloBPML. . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 26
1.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.8 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Identificação do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1 FocusingonKeyProcesses. . . . . . . . . . . . . . . . . . . . . 33
2.1.1 A fase de designação. . . . . . . . . . . . . . . . . . . 34
2.1.2 A fase de avaliação. . . . . . . . . . . . . . . . . . . . 38
2.2 DesigningaProcessArchitecture. . . . . . . . . . . . . . . . . . 42
2.2.1 IdentifyCaseTypes. . . . . . . . . . . . . . . . . . . . . 44
2.2.2 Identificar funções para tipos de caso. . . . . . . . . . . . . . 45
2.2.3 Construir Matrizes de Caso / Função. . . . . . . . . . . . . . 49
2.2.4 IdentifyProcesses. . . . . . . . . . . . . . . . . . . . . . 50
2.2.5 Completar a arquitetura do processo. . . . . . . . . . . . . 55
2.3 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3 Modelagem de processos essenciais . . . . . . . . . . . . . . . . . . . . . . . 63

3.1 FirstStepswithBPMN. . . . . . . . . . . . . . . . . . . . . . . 63
3.2 Ramificação e fusão. . . . . . . . . . . . . . . . . . . . . . . 67
3.2.1 Decisões Exclusivas. . . . . . . . . . . . . . . . . . . . . 67
xiii
Página 11
xiv Conteúdo
3.2.2 Execução Paralela. . . . . . . . . . . . . . . . . . . . . . 69

3.2.3 Decisões Inclusivas. . . . . . . . . . . . . . . . . . . . . 72
3.2.4 Retrabalho e repetição. . . . . . . . . . . . . . . . . . . 77
3.3 InformationArtifacts. . . . . . . . . . . . . . . . . . . . . . . . 79
3.4 Recursos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4 Modelagem Avançada de Processos . . . . . . . . . . . . . . . . . . . . . . . 97
4.1
4.2 ProcessDecomposition.
ProcessReuse. . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 100
. . 97
4.3 Mais sobre retrabalho e repetição. . . . . . . . . . . . . . . . . . . 102
4.3.1 ParallelRepetition. . . . . . . . . . . . . . . . . . . . . . 104
4.3.2 Repetição não controlada. . . . . . . . . . . . . . . . . . . 107
4.4 HandlingEvents. . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.4.1 MessageEvents. . . . . . . . . . . . . . . . . . . . . . . 108
4.4.2 TemporalEvents. . . . . . . . . . . . . . . . . . . . . . . 110
4.4.3 RacingEvents. . . . . . . . . . . . . . . . . . . . . . . . 111
4.5 HandlingExceptions. . . . . . . . . . . . . . . . . . . . . . . . . 114
4.5.1 Processo de aborto. . . . . . . . . . . . . . . . . . . . . . . 115
4.5.2 InternalExceptions. . . . . . . . . . . . . . . . . . . . . 116
4.5.3 ExternalExceptions. . . . . . . . . . . . . . . . . . . . . 117
4.5.4 ActivityTimeouts. . . . . . . . . . . . . . . . . . . . . . 118
4.5.5 Eventos sem interrupção e exceções complexas. . . . . 119
4.5.6 Interlude: EventSubprocessos. . . . . . . . . . . . . . . 121
4.5.7 ActivityCompensation. . . . . . . . . . . . . . . . . . . 122
4.6 Processos e regras de negócios. . . . . . . . . . . . . . . . . . . . 124
4.7 ProcessChoreografias. . . . . . . . . . . . . . . . . . . . . . . 125
4.8 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5 Descoberta do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.1 A configuração da descoberta do processo. . . . . . . . . . . . . . . . . . 155
5.1.1 Analista de processos versus especialista em domínio. . . . . . . . . . . 156
5.1.2 ThreeProcessDiscoveryChallenges. . . . . . . . . . . . 158
5.1.3 ProfileofaProcessAnalyst. . . . . . . . . . . . . . . . . 159
5.2 DiscoveryMethods. . . . . . . . . . . . . . . . . . . . . . . . . 161
5.2.1 Descoberta baseada em evidências. . . . . . . . . . . . . . . . . 161
5.2.2 Descoberta baseada em entrevista. . . . . . . . . . . . . . . . . 162
5.2.3 Descoberta baseada em oficina. . . . . . . . . . . . . . . . . 164
5.2.4 Pontos fortes e limitações. . . . . . . . . . . . . . . . . . 165
Página 12
Conteúdo xv
5.3 ProcessModelingMethod. . . . . . . . . . . . . . . . . . . . . . 167

5.3.1 Identificar os limites do processo. . . . . . . . . . . . . . . 167
5.3.2 Identificar atividades e eventos. . . . . . . . . . . . . . . . 167
5.3.3 Identificar recursos e seusHandovers. . . . . . . . . . 168
5.3.4 Identifique o Fluxo de Controle. . . . . . . . . . . . . . . . . . 169
5.3.5 IdentifyAdditionalElements. . . . . . . . . . . . . . . . 169
5.4 Garantia da qualidade do modelo de processo. . . . . . . . . . . . . . . . . . 171
5.4.1 Qualidade sintática e verificação. . . . . . . . . . . . . . 171
5.4.2 Qualidade semântica e validação. . . . . . . . . . . . . . 172
5.4.3 Qualidade e certificação pragmática. . . . . . . . . . . . . 174
5.4.4 Diretrizes e convenções de modelagem. . . . . . . . . . . 175
5.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6 Análise qualitativa de processos . . . . . . . . . . . . . . . . . . . . . . . 185

6.1 Análise de valor agregado. . . . . . . . . . . . . . . . . . . . . . . . 185
6.1.1 Classificação de valor. . . . . . . . . . . . . . . . . . . . . 185
6.1.2 Eliminação de resíduos. . . . . . . . . . . . . . . . . . . . . . 189
6.2 RootCauseAnalysis. . . . . . . . . . . . . . . . . . . . . . . . . 190
6.2.1 Diagramas de causa e efeito. . . . . . . . . . . . . . . . . . . 191
6.2.2 Diagramas de Por quê. . . . . . . . . . . . . . . . . . . . 196
6.3 Emissão de documentação e avaliação de impacto. . . . . . . . . . . . 198
6.3.1 IssueRegister. . . . . . . . . . . . . . . . . . . . . . . . 198
6.3.2 Análise de Pareto e gráficos PICK. . . . . . . . . . . . . . 201
6.4 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7 Análise Quantitativa de Processos . . . . . . . . . . . . . . . . . . . . . . 213

7.1 Medidas de desempenho. . . . . . . . . . . . . . . . . . . . . . . . 213
7.1.1 Dimensões de desempenho do processo. . . . . . . . . . . . . . 213
7.1.2 BalancedScorecard. . . . . . . . . . . . . . . . . . . . . 217
7.1.3 Modelos de referência e benchmarks do setor. . . . . . . . 218
7.2 FlowAnalysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.2.1 Calculando o tempo do ciclo usando a análise de fluxo. . . . . . . . 219
7.2.2 CycleTimeEfficiency. . . . . . . . . . . . . . . . . . . . 224
7.2.3 CycleTimeandWork-In-Process. . . . . . . . . . . . . . 225
7.2.4 Outras aplicações e limitações da análise de fluxo. . . 227
7.3 Filas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.3.1 Fundamentos da Teoria da Avaliação. . . . . . . . . . . . . . . . . 229
7.3.2 Modelos M / M / 1 e M / M / c. . . . . . . . . . . . . . . . . 232
7.3.3 Limitações da Teoria de Avaliação Básica. . . . . . . . . . . 234
Página 13
xvi Conteúdo
7.4 Simulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

7.4.1 Anatomia de uma Simulação de Processo. . . . . . . . . . . . . . 235
7.4.2 Entrada para Simulação de Processo. . . . . . . . . . . . . . . . 236
7.4.3 SimulationTools. . . . . . . . . . . . . . . . . . . . . . . 240
7.4.4 Uma palavra de cautela. . . . . . . . . . . . . . . . . . . . . . 243
7.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
8 Redesenho do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

8.1 TheEssenceofProcessRedesign. . . . . . . . . . . . . . . . . . 253
8.1.1 WhyRedesign? . . . . . . . . . . . . . . . . . . . . . . . 253
8.1.2 O queéRedesign? . . . . . . . . . . . . . . . . . . . . . . 256
8.1.3 O Quadrângulo do Diabo. . . . . . . . . . . . . . . . . . . 258
8.1.4 Como fazer o redesign? . . . . . . . . . . . . . . . . . . . . . . 259
8.2 HeuristicProcessRedesign. . . . . . . . . . . . . . . . . . . . . 262
8.2.1 CustomerHeuristics. . . . . . . . . . . . . . . . . . . . . 263
8.2.2 BusinessProcessOperationHeuristics. . . . . . . . . . . 264
8.2.3 Heurísticas de comportamento de processos de negócios. . . . . . . . . . . . 266
8.2.4 OrganizationHeuristics. . . . . . . . . . . . . . . . . . . 267
8.2.5 Heurísticas de informação. . . . . . . . . . . . . . . . . . . . 270
8.2.6 TechnologyHeuristics. . . . . . . . . . . . . . . . . . . . 271
8.2.7 ExternalEnvironmentHeuristics. . . . . . . . . . . . . . 271
8.3 O caso de uma instituição de saúde. . . . . . . . . . . . . . . . 273
8.3.1 Envio de arquivos médicos por correio. . . . . . . . . . . . . . . 275
8.3.2 Reuniões periódicas. . . . . . . . . . . . . . . . . . . . . . 275
8.3.3 RequestingMedicalFiles. . . . . . . . . . . . . . . . . . 276
8.4 Design baseado no produto. . . . . . . . . . . . . . . . . . . . . . . . 278
8.4.1 Análise: Criando um modelo de dados do produto. . . . . . . . . . 279
8.4.2 Design: derivando um processo de um modelo de dados do produto. . 285
8.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
9 Automação de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

9.1 Automatizando Processos de Negócios. . . . . . . . . . . . . . . . . . . 297
9.1.1 Sistemas de gerenciamento de processos de negócios. . . . . . . . . . . 298
9.1.2 Arquitetura de umBPMS. . . . . . . . . . . . . . . . . . . 299
9.1.3 TheCaseofACNS. . . . . . . . . . . . . . . . . . . . . 304
9.2 Vantagens de introduzir um BPMS. . . . . . . . . . . . . . . . . 309
9.2.1 Redução da carga de trabalho. . . . . . . . . . . . . . . . . . . . . 309
9.2.2 FlexibleSystemIntegration. . . . . . . . . . . . . . . . . 310
9.2.3 ExecutionTransparency. . . . . . . . . . . . . . . . . . . 311
9.2.4 Aplicação de regras. . . . . . . . . . . . . . . . . . . . . . 312
Página 14
Conteúdo xvii
9.3 Desafios da introdução de umBPMS. . . . . . . . . . . . . . . . . 313

9.3.1 Desafios Técnicos. . . . . . . . . . . . . . . . . . . . 313
9.3.2 Desafios organizacionais. . . . . . . . . . . . . . . . . . 314
9.4 Tornando os modelos de processos executáveis. . . . . . . . . . . . . . . . . 316
9.4.1 Identifique os limites da automação. . . . . . . . . . . . 317
9.4.2 ReviewManualTasks. . . . . . . . . . . . . . . . . . . . 319
9.4.3 Concluir o Modelo de Processo. . . . . . . . . . . . . . . . 323
9.4.4 Traga o Modelo de Processo para um Nível de Granularidade Adequado 324
9.4.5 SpecifyExecutionProperties. . . . . . . . . . . . . . . . 327
9.4.6 TheLastMile. . . . . . . . . . . . . . . . . . . . . . . . 337
9.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
9.8 Leitura adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 351
10 Inteligência de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

10.1 Execução de processos e registros de eventos. . . . . . . . . . . . . . . . . 353
10.1.1 A perspectiva dos participantes sobre a execução do processo. . . 354
10.1.2 A perspectiva do proprietário do processo no processo
Execução. . . . . . . . . . . . . . . . . . . . . . . . . . 354
10.1.3 StructureofEventLogs. . . . . . . . . . . . . . . . . . . 356

10.1.4 Desafios deExtractingEventLogs. . . . . . . . . . . . 359
10.2 AutomaticProcessDiscovery. . . . . . . . . . . . . . . . . . . . 360
10.2.1 Premissas do α- Algoritmo. . . . . . . . . . . . . . 360
10.2.2 As relações de ordem do α- Algoritmo. . . . . . . . . . 361
10.2.3 O algoritmo α . . . . . . . . . . . . . . . . . . . . . . . 364
10.2.4 RobustProcessDiscovery. . . . . . . . . . . . . . . . . . 366
10.3 Análise de desempenho. . . . . . . . . . . . . . . . . . . . . . . . 367
10.3.1 Medição de tempo. . . . . . . . . . . . . . . . . . . . . 367
10.3.2 Medição de custos. . . . . . . . . . . . . . . . . . . . . . 369
10.3.3 QualityMeasurement. . . . . . . . . . . . . . . . . . . . 370
10.3.4 FlexibilidadeMedida. . . . . . . . . . . . . . . . . . . 372
10.4 Verificação de conformidade. . . . . . . . . . . . . . . . . . . . . . . 373
10.4.1 Conformidade do Fluxo de Controle. . . . . . . . . . . . . . . . 374
10.4.2 Conformidade de Dados e Recursos. . . . . . . . . . . . 377
10.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
10.8 Leitura adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Página 15
Siglas
6 mi Máquina, Método, Material, Homem, Medição, Meio

4P Políticas, procedimentos, pessoas, planta / equipamento
7PMG Sete Diretrizes de Modelagem de Processo
abc Custeio baseado em atividades
APQC Centro Americano de Produtividade e Qualidade
ATAMO E então, um milagre ocorre
B2B De empresa para empresa
BAM Monitoramento de Atividades de Negócios
BOM Lista de materiais
BPA Análise de Processo de Negócios
BPEL Linguagem de execução de processos de negócios de serviços da Web
BPM Gestão de Processos de Negócios
BPMN Modelo de Processo de Negócios e Notação
BPMS Sistema de Gestão de Processos de Negócios
BPR Reengenharia do processo de negócios
BTO Construir sob encomenda
BVA Agregação de valor comercial
CEO CEO
Diretor Financeiro
Diretor financeiro
CIO Diretor de Informação
CMMI Modelo de maturidade de capacidade integrado
COO Diretor de Operações
CPO Diretor de Processos
CRM Gestão de Relacionamento com o Cliente
CPN Rede Petri Colorida
CT Tempo de Ciclo
DBMS Sistema de gerenciamento de banco de dados
DCOR Referência de operações da cadeia de design (design do produto)
DES Simulação de eventos discretos
DMR Departamento de estradas principais
DMS Sistema de gestão de documentos
xix
Página 16
xx Siglas
DUR Avaliação do uso de drogas

EPA Agência de Proteção Ambiental
EPC Cadeia de processos orientada a eventos
ERP Planejamento de Recursos Empresariais
eTOM Mapa aprimorado de operações de telecomunicações
FIFO Primeiro a entrar, primeiro a sair
RH Recursos humanos
IDEF3 Definição Integrada para Método de Captura de Descrição de Processo
ISP Provedor de internet
ISTO Tecnologia da informação
ITIL Biblioteca de infraestrutura de tecnologia da informação
KM Gestão do conhecimento
KPI Indicador-Chave de Desempenho
NRW Departamento de Recursos Naturais e Água
NVA Não-agregador de valor
OÁSIS Organização para o Avanço das Informações Estruturadas
Padrões
AMD Grupo de Gerenciamento de Objetos
SO Sistema operacional
PCF Estrutura de classificação de processos
PD Desenvolvimento de Produto
PDCA A planta faz o ato de verificação
PO Ordem de Compra
POS Ponto de venda
PPM Medição de Desempenho de Processo
RBAC Controle de acesso baseado em função
RFID Identificação de rádio frequencia
RFQ Pedido de Orçamento
ROI Retorno sobre o investimento
Método de avaliação CMMI padrão SCAMPI para melhoria de processos
SCOR Modelo de referência de operações da cadeia de suprimentos
Sistema de avaliação de desenvolvimento eletrônico inteligente eDA inteligente
SOA Arquitetura Orientada a Serviços
STP Straight-Through-Processing
TCT Tempo do Ciclo Teórico
TOC Teoria das Restrições
TQM Gestão de qualidade Total
UIMS Sistema de gerenciamento de interface do usuário
UEL Linguagem de Expressão Universal
UML Linguagem de modelagem unificada
Diagrama de atividades UML AD UML
VA Agregação de valor
VCH Hierarquia de Criação de Valor
VCS Sistema de Criação de Valor
VRM Modelo de Referência de Valor
Página 17
Siglas xxi
WIP Trabalho em progresso

WfMC Coalizão de Gestão de Fluxo de Trabalho
WfMS Sistema de gerenciamento de fluxo de trabalho
Linguagem de execução de processos de negócios de serviços da Web WS-BPEL
WSDL Linguagem de definição de serviço da web
XES Fluxo de eventos extensível
XML Extensible Markup Language
XSD Definição de Esquema XML
YAWL Outra linguagem de fluxo de trabalho
Página 18
Lista de Figuras
Fig.1.1 Ingredientesdeprocesso de negócios. . . . . . . . . . . . . . . . . 6

Fig. 1.2 Como o processo saiu de foco ao longo dos tempos. . . . . . 8
Fig. 1.3 Processo de compra na Ford em estágio inicial. . . . . . . . . . . 10
Fig. 1.4 Processo de compra na Ford após redesenho. . . . . . . . . . . . . 11
Fig. 1.5 Funções de trabalho de um gerente responsável por um processo (também conhecido como
proprietário do processo) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Fig. 1.6 Modelo de processo para um fragmento inicial do aluguel de equipamentos
processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Fig.1.7 BPMlifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Fig. 2.1 Os diferentes níveis de detalhe em uma arquitetura de processo. . . . . . 42
Fig. 2.2 Uma arquitetura de processo para uma autoridade portuária. . . . . . . . . . . 44
Fig. 2.3 Decomposições funcionais diferentes dentro do mesmo
organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Fig.2.4 Acase / functionmatrix. . . . . . . . . . . . . . . . . . . . . . . 49
Fig. 2.5 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo
(aplicando a Diretriz1). . . . . . . . . . . . . . . . . . . . . . . 50
(aplicando as Diretrizes 2-7). . . . . . . . . . . . . . . . . . . . . 54
(aplicando a Diretriz 8). . . . . . . . . . . . . . . . . . . . . . . 54
Fig. 2.8 Um mapa de processo para o processo de pagamento da hipoteca. . . . . . . . 56
Fig. 3.1 O diagrama de um processo simples de atendimento de pedidos. . . . . . . . 64
Fig. 3.2 Progresso de três instâncias do processo de atendimento do pedido. . . . 65
Fig. 3.3 Um edifício ( a ), sua miniatura de madeira ( b ) e sua planta ( c ).
(( b ): © 2010, Bree Industries; ( c ): usado com permissão de
planetclaire.org) . . . . . . . . . . . . . . . . . . . . . . . . . 66
Fig. 3.4 Um exemplo do uso de gateways XOR. . . . . . . . . . . . . 68
Fig. 3.5 Um exemplo do uso de gateways AND. . . . . . . . . . . . . 70
Fig. 3.6 Uma versão mais elaborada do processo de atendimento de pedidos
diagrama. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
xxiii
Página 19
xxiv Lista de Figuras
Fig. 3.7 Uma variante do processo de atendimento do pedido com dois diferentes
gatilhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Fig. 3.8 Modelando uma decisão inclusiva: primeiro julgamento. . . . . . . . . . . . . 73
Fig. 3.9 Modelando uma decisão inclusiva: segundo julgamento. . . . . . . . . . . 73
Fig. 3.10 Modelando uma decisão inclusiva com o gateway OR. . . . . . 74
Fig. 3.11 Que tipo o gateway de junção deve ter para que as instâncias
deste processo pode ser concluído corretamente? . . . . . . . . . . . . . . 75
Fig. 3.12 O diagrama do processo de atendimento do pedido com o produto
fabricação. . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Fig. 3.13 Um modelo de processo para o tratamento de correspondência ministerial. . . 78
Fig. 3.14 O exemplo de atendimento de pedido com artefatos. . . . . . . . . . . 80
Fig. 3.15 O exemplo de atendimento de pedido com informações de recursos. . . . . 84
Fig. 3.16 Diagrama de colaboração entre um vendedor, um cliente e dois
fornecedores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Fig. 4.1 Identificação de subprocessos no processo de atendimento de pedidos
ofFig. 3,12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Fig. 4.2 Uma versão simplificada do processo de atendimento do pedido após ocultar
o conteúdo de seus subprocessos. . . . . . . . . . . . . . . . . . 99
Fig. 4.3 Um modelo de processo para desembolsar empréstimos imobiliários, estabelecido ao longo
três níveis hierárquicos por meio do uso de subprocessos. . . . . . . 100
Fig. 4.4 O modelo de processo para desembolsar empréstimos estudantis invoca o mesmo
modelo para assinatura de empréstimos usado pelo processo de desembolso para casa
empréstimos, via uma atividade. . . . . . . . . . . . . . . . . . . . . . 101
Fig. 4.5 O modelo de processo para o tratamento de correspondência ministerial
da Fig. 3.13 simplificado usando uma atividade de loop. . . . . . . . . . . . 103
Fig. 4.6 Um exemplo de ciclo não estruturado. . . . . . . . . . . . . . . . . 104
Fig.4.7 Obtenção de cotações de cinco fornecedores. . . . . . . . . . . . . . . 105
Fig. 4.8 Obtenção de cotações de vários fornecedores, cujo número não é
knownapriori. . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Fig. 4.9 Usando um pool de várias instâncias para representar vários fornecedores. . . 106
Fig. 4.10 Usando um subprocesso ad-hoc para modelar a repetição não controlada. . 108
Fig. 4.11 Substituir atividades que apenas enviam ou recebem mensagens ( a )
com eventos de mensagem ( b ). . . . . . . . . . . . . . . . . . . . . . 109
Fig. 4.12 Usando eventos de cronômetro para conduzir as várias atividades de uma empresa
processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Fig. 4.13 Uma condição de corrida entre uma mensagem recebida e um cronômetro. . . 112
Fig. 4.14 Combinando uma escolha interna em uma festa com uma baseada em eventos
escolha na outra parte. . . . . . . . . . . . . . . . . . . . . . 113
Fig. 4.15 Um exemplo de colaboração de conflito entre dois pools. . 113
Fig. 4.16 Usando um gateway baseado em eventos para corrigir o impasse
colaboração doFig. 4,15 . . . . . . . . . . . . . . . . . . . . . 114
Fig. 4.17 Um diagrama de colaboração entre um cliente, uma agência de viagens e
anairline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Fig. 4.18 Usar um evento de término para sinalizar o término impróprio do processo. 116
Fig. 4.19 Os eventos de erro modelam exceções internas. . . . . . . . . . . . . . 117
Página 20
Lista de Figuras xxv
Fig. 4.20 Os eventos de limite capturam eventos externos que podem ocorrer durante um
atividade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Fig. 4.21 Eventos de limite não interrompidos capturam eventos externos que
ocorrer durante uma atividade e desencadear um procedimento paralelo sem
interromper a atividade envolvente. . . . . . . . . . . . . . . . . 119
Fig. 4.22 Os eventos sem interrupção podem ser usados em combinação com o sinal
eventos para modelar cenários complexos de tratamento de exceções. . . . . . 120
Fig. 4.23 Os subprocessos de evento podem ser usados no lugar de eventos de limite,
e para capturar eventos lançados de fora do escopo de um determinado
subprocesso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Fig. 4.24 Compensando o envio e o pagamento. . . . . . . 123
Fig. 4.25 Um pedido de reabastecimento é acionado sempre que os níveis de estoque
dropbelowathreshold. . . . . . . . . . . . . . . . . . . . . . 124
Fig. 4.26 O diagrama de coreografia para o diagrama de colaboração em
Fig. 4.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Fig. 4.27 O diagrama de coreografia entre um vendedor, um cliente e um
transportadora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Fig. 4.28 Colaboração diagrama de peça 1 / 2 (fragmento de transferência de carga). . 140
Fig. 4.29 Colaboração diagrama de parte 2 / manuseamento de retorno 2 (mercadoria
fragmento). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Fig. 4.30 Coreografia diagrama de peça 1 / 2. . . . . . . . . . . . . . . . . 142
Fig. 4.31 Coreografia diagrama de parte 2 / 2. . . . . . . . . . . . . . . . . 143
Fig. 4.32 Colaboração diagrama de peça 1 / 3 (fragmento de estabelecimento de Crédito) 144
Fig. 4.33 Colaboração diagrama de parte 2 / 3 (fragmento de desembolso empréstimo) 145
Fig. 4.34 Diagrama de parte colaboração 3 / 3 (sub-processos). . . . . . . . 146
Fig. 5.1 As principais atividades e eventos do processo de atendimento de pedidos. . 168
Fig. 5.2 As atividades e eventos do processo de atendimento de pedidos
designados tapaosandlanes. . . . . . . . . . . . . . . . . . . . 169
Fig. 5.3 O fluxo de controle do processo de atendimento do pedido. . . . . . . . . 170
Fig. 5.4 Aspectos de qualidade e atividades de garantia de qualidade. . . . . . . . . . 172
Fig. 5.5 Fragmentos de processos comuns e não sólidos. . . . . . . . . 173
Fig. 5.6 Extrato do modelo do processo de atendimento do pedido com layout incorreto. . 175
Fig. 5.7 Extrato do modelo do processo de atendimento do pedido com bom layout. 175
Fig. 5.8 Um processo de tratamento de reclamações conforme encontrado na prática. . . . . . . . 177
Fig. 5.9 O processo de tratamento de reclamações foi retrabalhado. . . . . . . . . . . . 182
Fig. 5.10 Um processo de solicitação de empréstimo. . . . . . . . . . . . . . . . . . . . . 182
Fig.5.11 Asalescampaignprocess. . . . . . . . . . . . . . . . . . . . . 183
Fig. 6.1 Modelo de um diagrama de causa e efeito baseado nos 6M's. . . . . . 194
Fig. 6.2 Diagrama de causa-efeito para o problema "Equipamento rejeitado na entrega" 195
Fig.6.3 Templateofawhy – whydiagram. . . . . . . . . . . . . . . . . 197
Fig. 6.4 Gráfico de Pareto para despesas excessivas com aluguel de equipamentos. . . . . 202
Fig.6.5 PICKchart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Fig. 6.6 Gráfico de Pareto dos fatores causais do problema “Equipamento não disponível
quando necessário" . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Fig.7.1 Modelo de processo totalmente sequencial. . . . . . . . . . . . . . . . . . 219
Página 21
xxvi Lista de Figuras
Fig. 7.2 Modelo de processo com bloco XOR. . . . . . . . . . . . . . . . . . 220

Fig.7.3 Padrão de bloco XOR. . . . . . . . . . . . . . . . . . . . . . . . 220
Fig. 7.4 Modelo de processo com bloco AND. . . . . . . . . . . . . . . . . . 221
Fig.7.5 AND-blockpattern. . . . . . . . . . . . . . . . . . . . . . . . 221
Fig.7.6 Processo de aplicação de crédito. . . . . . . . . . . . . . . . . . . . . 221
Fig.7.7 Exemplo de loop de trabalho. . . . . . . . . . . . . . . . . . . . . 222
Fig.7.8 Retrabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Fig. 7.9 Atividade que é retrabalhada no máximo uma vez. . . . . . . . . . . . . . 223
Fig. 7.10 Processo de aplicação de crédito com retrabalho. . . . . . . . . . . . . . 223
Fig. 7.11 Estrutura de um sistema M / M / 1 ou M / M / c, parâmetros de entrada e
parâmetros computáveis. . . . . . . . . . . . . . . . . . . . . . 233
Fig. 7.12 Histogramas produzidos por simulação do pedido de crédito
processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Fig. 7.13 Processo de reclamação de resolução de Cetera. . . . . . . . . . . . . . . 241
Fig.7.14 Processo de hipoteca. . . . . . . . . . . . . . . . . . . . . . . . . 249
Fig.8.1 TheDevil'sQuadrangle. . . . . . . . . . . . . . . . . . . . . . 259
Fig.8.2 Theintakeprocess. . . . . . . . . . . . . . . . . . . . . . . . . 274
Fig. 8.3 O processo de entrada após a reformulação do arquivo médico. . . . . . . . . 277
Fig. 8.4 O modelo de dados do produto do piloto do helicóptero. . . . . . . . . . . . . . 280
Fig. 8.5 Um projeto de processo incorreto para os dados de produto do piloto de helicóptero
modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Fig. 8.6 Um projeto de processo correto para os dados do produto piloto do helicóptero
modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Fig. 8.7 Um projeto de processo alternativo para o produto piloto de helicóptero
modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Fig. 8.8 Solução para a proposta de empréstimo. . . . . . . . . . . . . . . . . . . 291
Fig. 8.9 Um projeto de processo completo para os dados do produto piloto do helicóptero
modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Fig. 8.10 Um projeto de processo de baixo custo para o produto piloto de helicóptero
modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Fig. 9.1 A arquitetura de um BPMS. . . . . . . . . . . . . . . . . . . . 299
Fig. 9.2 A ferramenta de modelagem de processos do Bonita Open Solution da Bonita
Suave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Fig. 9.3 O gerenciador da lista de trabalho do BPM Suite do Bizagi. . . . . . . . . . . 301
Fig. 9.4 A ferramenta de monitoramento do BPMOne da Perceptive Software. . . . . 302
Fig.9.5 ThespectrumofBPMStypes. . . . . . . . . . . . . . . . . . . 307
Fig. 9.6 O modelo de atendimento de pedidos que queremos automatizar. . . . . . 318
Fig. 9.7 Processo de admissão: as avaliações inicial ( a ) e final ( c ) podem

ser automatizado em um BPMS; a avaliação pelo comitê ( b )
é um processo manual fora do escopo do BPMS. . . . . . . . 321
Fig. 9.8 O modelo de atendimento de pedido da Fig. 9.6 , completado com
aspectos de fluxo de controle e fluxo de dados relevantes para automação. . . . 325
Fig. 9.9 O processo de vendas de um provedor de serviços B2B. . . . . . . . . . . 326
Fig. 9.10 Estrutura do formato BPMN. . . . . . . . . . . . . . . . . . 328
Página 22
Lista de Figuras xxvii
Fig. 9.11 O XSD descrevendo o pedido de compra ( a ) e um de seus

instâncias ( b ). . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Fig. 9.12 O processo de atendimento automatizado de receitas. . . . . . . . . . 342
Fig. 9.13 O modelo para o processo de vendas de um provedor de serviços B2B,
concluído com fluxo de controle ausente e dados relevantes para
execução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Fig. 9.14 Modelo de processo do FixComp para tratamento de reclamações. . . . . . . . 348
Fig.9.15 Modelo de processo de tratamento de reclamações. . . . . . . . . . . . . . . . . . 349
Fig. 10.1 Exemplo de um log de eventos para o processo de atendimento do pedido. . . . 357
Fig. 10.2 Metamodelo do formato XES. . . . . . . . . . . . . . . . . . . 358
Fig. 10.3 Exemplo de arquivo no formato XES. . . . . . . . . . . . . . . . 358
Fig. 10.4 Definição de um log de fluxo de trabalho. . . . . . . . . . . . . . . . . . . . 361
Fig. 10.5 Padrões de fluxo de controle simples. . . . . . . . . . . . . . . . . . . . 362
Fig. 10.6 Pegada representada como uma matriz do registro do fluxo de trabalho
L = [〈a, b, g, h, j, k, i, l〉,〈a, c, d, e, f, g, j, h, i, k, l〉]. . . . . . 363
Fig. 10.7 Modelo de processo construído pelo algoritmo α do fluxo de trabalho
log L = [〈a, b, g, h, j, k, i, l〉,〈a, c, d, e, f, g, j, h, i, k, l〉]. . . . 365
Fig. 10.8 Exemplos de dois loops curtos, que são problemáticos para o
α -algoritmo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Fig.10.9 Dottedchartoflogdata. . . . . . . . . . . . . . . . . . . . . . 368
Fig. 10.10 Gráfico de cronograma de dados de registro como PM 232. . . . . . . . . . . . . . 369
Fig. 10.11 Modelo BPMN com token no evento de início para repetir o caso
〈A , b, g, i, j, k, l〉. . . . . . . . . . . . . . . . . . . . . . . . . . 375
Fig. 10.12 Repetição do caso não conforme 〈a, b, i, j, k, l〉. . . . . . . . 376
Fig. 10.13 Resultado da repetição de casos no modelo de processo. . . . . . . . . . 377
Fig. 10.14 Modelo de processo construído pelo algoritmo α . . . . . . . . . . 380
Página 23
Capítulo 1
Introdução ao Gerenciamento de Processos de Negócios
Ab ovo usque ad mala.

Horácio (65 aC-8 aC)
Gerenciamento de processos de negócios (BPM) é a arte e a ciência de supervisionar como funciona

é realizado em uma organização para garantir resultados consistentes e para tirar vantagem
de oportunidades de melhoria. Neste contexto, o termo "melhoria" pode levar diferentes
significados diferentes dependendo dos objetivos da organização. Exemplos típicos
dos objetivos de melhoria incluem a redução de custos, reduzindo os tempos de execução e
redução das taxas de erro. As iniciativas de melhoria podem ser pontuais, mas também exibem mais
natureza contínua. É importante ressaltar que BPM não é sobre como melhorar a maneira como as ações individuais
atividades são realizadas. Em vez disso, trata-se de gerenciar cadeias inteiras de eventos, atividades
e decisões que, em última análise, agregam valor à organização e aos clientes. Estes
“Cadeias de eventos, atividades e decisões” são chamadas de processos .
Neste capítulo, apresentamos alguns conceitos essenciais por trás do BPM. Nos começaremos
com uma descrição dos processos típicos encontrados nas organizações contemporâneas.
Em seguida, discutimos os ingredientes básicos de um processo de negócios e fornecemos uma definição
para o conceito, bem como de BPM. A fim de colocar o BPM em um ambiente mais amplo
Em seguida, fornecemos uma visão geral histórica da disciplina de BPM. Finalmente, nós
discuta como uma iniciativa de BPM em uma organização normalmente se desenvolve. Esta discussão
nos leva à definição de um ciclo de vida BPM em torno do qual o livro está estruturado.
1.1 Processos em todos os lugares
Cada organização - seja um órgão governamental, uma organização sem fins lucrativos ou um
empresa — tem que gerenciar vários processos. Exemplos típicos de processos
que podem ser encontrados na maioria das organizações incluem:
• Order-to-cash : Este é um tipo de processo realizado por um fornecedor, que começa
quando um cliente envia um pedido de compra de um produto ou serviço e termina
quando o produto ou serviço em questão foi entregue ao cliente e
o cliente efetuou o pagamento correspondente. Um processo de pedido para pagamento en-
atividades de bússola relacionadas à verificação do pedido de compra, envio (no caso

de produtos físicos), entrega, faturamento, recebimento de pagamento e confirmação.
M. Dumas et al., Fundamentals of Business Process Management , 1

DOI 10.1007 / 978-3-642-33143-5_1 , © Springer-Verlag Berlin Heidelberg 2013
Página 24
2 1 Introdução ao Gerenciamento de Processos de Negócios
• Cotação para pedido : este tipo de processo geralmente precede um processo de pedido para pagamento.
Começa a partir do ponto em que um fornecedor recebe um "Pedido de Cotação" (RFQ)
de um cliente e termina quando o cliente em questão faz um pedido de compra
com base na cotação recebida. O processo do pedido ao pagamento assume a retransmissão desse
apontar. A combinação de uma cotação para pedido e o pedido correspondente
o processo de caixa é denominado processo de cotação para pagamento .
• Adquirir para pagar : Este tipo de processo começa quando alguém em uma organização desiste
conclui que um determinado produto ou serviço precisa ser adquirido. Termina quando
o produto ou serviço foi entregue e pago. Um processo de aquisição para pagamento
inclui atividades como obter cotações, aprovar a compra, selecionar um
fornecedor, emitir um pedido de compra, receber as mercadorias (ou consumir o serviço),
verificar e pagar a fatura. Um processo de aquisição para pagamento pode ser visto como o duplo
do processo de cotação para pagamento no contexto de interações business-to-business. Para
em cada processo de aquisição para pagamento, há um processo de cotação para pagamento correspondente em
do lado do fornecedor.
• Problema para resolução . Este tipo de processo começa quando um cliente levanta um problema
ou problema, como uma reclamação relacionada a um defeito em um produto ou um problema en-
neutralizada ao consumir um serviço. O processo continua até que o cliente,
o fornecedor, ou de preferência ambos, concorda que o problema foi resolvido.
Uma variante desse processo pode ser encontrada nas seguradoras que precisam lidar
com “sinistros de seguros”. Essa variante costuma ser chamada de reivindicação à resolução .
• Pedido de aprovação. Este tipo de processo começa quando alguém se inscreve para um
benefício ou privilégio e termina quando o benefício ou privilégio em questão é
concedida ou negada. Este tipo de processo é comum em agências governamentais, por
por exemplo, quando um cidadão solicita uma licença de construção ou quando um empresário
solicita uma licença para abrir um negócio (por exemplo, um restaurante). Outro processo que
cai nesta categoria é o processo de admissão em uma universidade, que começa quando
um aluno se inscreve para admissão em um grau. Ainda outro exemplo é o processo
para aprovação de pedidos de férias ou licenças especiais em uma empresa.
Como os exemplos acima ilustram, os processos de negócios são o que as empresas fazem
sempre que entregam um serviço ou produto aos clientes. A forma como os processos são destruídos
assinado e executado afeta a "qualidade do serviço" que os clientes percebem
e a eficiência com que os serviços são prestados. Uma organização pode superar
formar outra organização que ofereça tipos de serviço semelhantes, se tiver processos melhores
e os executa melhor. Isso é verdade não apenas para processos voltados para o cliente, mas
também de processos internos, como o processo de aquisição para pagamento, que é realizado
com o propósito de atender a uma necessidade interna.
À medida que avançarmos neste livro, usaremos um exemplo concreto de um método de compra para pagar
processo de aluguel de equipamentos de construção, conforme descrito a seguir.
Exemplo 1.1 Processo de aquisição até o pagamento na BuildIT.
A BuildIT é uma construtora especializada em obras públicas (estradas, pontes, dutos,

túneis, ferrovias, etc.). Dentro do BuildIT, muitas vezes acontece que os engenheiros que trabalham em uma
local de construção (chamados de engenheiros de site ) precisam de um equipamento, como um caminhão, uma escavadeira,
Página 25
1.2 Ingredientes de um Processo de Negócio 3
uma escavadeira, uma bomba de água, etc. A BuildIT possui muito pouco equipamento e, em vez disso, aluga a maioria
de seus equipamentos de fornecedores especializados.
O processo empresarial existente para aluguel de equipamentos é o seguinte. Quando os engenheiros do site
precisam alugar um equipamento, preenchem um formulário denominado “Solicitação de Aluguel de Equipamento”
e enviar esta solicitação por e-mail para um dos balconistas do depósito da empresa. O balconista em
o depósito recebe a solicitação e, após consulta aos catálogos dos fornecedores de equipamentos,
seleciona o equipamento mais econômico que atende à solicitação. Em seguida, o balconista
verifica a disponibilidade do equipamento selecionado com o fornecedor via telefone ou e-mail.
Às vezes, a opção selecionada não está disponível e o secretário tem que selecionar uma alternativa
equipamento e verifique a sua disponibilidade junto do respectivo fornecedor.
Assim que o funcionário encontrar um equipamento adequado disponível para locação, ele adiciona
os detalhes do equipamento selecionado para a solicitação de aluguel. Cada solicitação de aluguel deve ser
aprovado por um engenheiro de obra, que também trabalha no depósito. Em alguns casos, as obras
engenheiro rejeita a solicitação de aluguel de equipamento. Algumas rejeições levam ao cancelamento de
o pedido (nenhum equipamento é alugado). Outras rejeições são resolvidas substituindo o
equipamento selecionado com outro equipamento, como um equipamento mais barato ou um
equipamento mais adequado para o trabalho. Neste último caso, o funcionário precisa realizar
outra consulta de disponibilidade.
Quando um engenheiro de obras aprova um pedido de aluguel, o balconista envia uma confirmação para o
fornecedor. Esta confirmação inclui uma Ordem de Compra (PO) para alugar o equipamento. o
O PO é produzido pelo sistema de informações financeiras da BuildIT usando as informações inseridas por
o secretário. O balconista também registra o engajamento do equipamento em uma planilha que é
mantido com o objetivo de rastrear todos os aluguéis de equipamentos.
Nesse ínterim, o engenheiro do local pode decidir que o equipamento não é mais necessário. No
neste caso, o engenheiro pede ao balconista que cancele a solicitação de aluguel do equipamento.
No prazo devido, o fornecedor entrega o equipamento alugado no canteiro de obras. O site
engenheiro então inspeciona o equipamento. Se tudo estiver em ordem, o engenheiro aceita o
engajamento e o equipamento é colocado em uso. Em alguns casos, o equipamento é enviado de volta
porque não cumpre os requisitos do engenheiro do local. Neste caso, o site
o engenheiro tem que reiniciar o processo de locação.
Terminado o prazo de locação, o fornecedor vem buscar o equipamento. As vezes,
o engenheiro do local pede uma extensão do período de locação entrando em contato com o fornecedor via
e-mail ou telefone 1–2 dias antes da coleta. O fornecedor pode aceitar ou rejeitar este pedido.
Alguns dias após a retirada do equipamento, o fornecedor do equipamento envia uma fatura
para o balconista por e-mail. Neste ponto, o funcionário pede ao engenheiro do local para confirmar que o
o equipamento foi efetivamente alugado pelo período indicado na fatura. O funcionário também verifica
se os preços de aluguel indicados na fatura estiverem de acordo com os da OC. Depois de
esses cheques, o escriturário encaminha a fatura para o departamento financeiro e o financeiro
departamento eventualmente paga a fatura.
1.2 Ingredientes de um Processo de Negócio
O exemplo acima mostra que um processo de negócios abrange uma série de eventos
e atividades . Os eventos correspondem a coisas que acontecem atomicamente, o que significa que eles
não têm duração. A chegada de um equipamento a um canteiro de obras é um acontecimento. este
evento pode desencadear a execução de uma série de atividades. Por exemplo, quando um pedaço de
o equipamento chega, o engenheiro do local o inspeciona. Esta fiscalização é uma atividade, no
sinto que leva tempo.
Quando uma atividade é bastante simples e pode ser vista como uma única unidade de trabalho, nós
chame isso de tarefa . Por exemplo, se a inspeção que o engenheiro do local realiza é bastante
Página 26
simples, por exemplo, apenas verificar se o equipamento recebido corresponde ao que foi
ordenado - podemos dizer que a inspeção do equipamento é uma tarefa. Se por outro lado
a inspeção do equipamento requer muitas etapas - como verificar se o equipamento
atende a especificação constante do pedido de compra, verificando se o equipamento
está em funcionamento e verificando se o equipamento vem com todos os acessos necessários
histórias e dispositivos de segurança - vamos chamá-lo de atividade.
Além de eventos e atividades, um processo típico envolve pontos de decisão ,
ou seja, momentos em que é tomada uma decisão que afeta a forma como o processo é
executado. Por exemplo, como resultado da inspeção, o engenheiro do local pode decidir
que o equipamento deve ser devolvido ou que o equipamento deve ser aceito.
Essa decisão afeta o que acontece mais tarde no processo.
Um processo também envolve uma série de atores (atores humanos, organizações ou soft-
sistemas de armazenamento que atuam em nome de atores humanos ou organizações), objetos físicos
(equipamentos, materiais, produtos, documentos em papel) e objetos imateriais (elec-
documentos tronic e registros eletrônicos). Por exemplo, o aluguel de equipamentos pro-
cesso envolve três tipos de atores humanos (balconista, engenheiro de obra e engenheiro de obras)
e dois tipos de ator organizacional (BuildIT e os fornecedores de equipamentos). o
processo também envolve objetos físicos (o equipamento alugado), documentos eletrônicos
(solicitações de aluguel de equipamentos, POs, faturas) e registros eletrônicos (equipamentos en-
registros de gestão mantidos em uma planilha).
Finalmente, a execução de um processo leva a um ou vários resultados . Para a prova-
ple, o processo de aluguel de equipamento leva a um equipamento sendo usado pela BuildIT,
bem como o pagamento ao fornecedor do equipamento. Idealmente, um resultado
deve agregar valor aos atores envolvidos no processo, que neste exemplo são
BuildIT e o fornecedor. Em alguns casos, este valor não é alcançado ou é apenas parcialmente
alcançado. Por exemplo, quando um equipamento é devolvido, nenhum valor é ganho, nem
pela BuildIT nem pelo fornecedor. Isso corresponde a um resultado negativo , ao contrário
para um resultado positivo que agregue valor aos atores envolvidos.
Dentre os atores envolvidos em um processo, aquele que consome a produção do
o processo desempenha um papel especial, nomeadamente o papel do cliente . Por exemplo, no
processo acima, o cliente é o engenheiro do local, uma vez que é o engenheiro do local que
coloca em uso o equipamento alugado. É também o engenheiro do local que provavelmente
ficar insatisfeito se o resultado do processo for insatisfatório (resultado negativo) ou
se a execução do processo for atrasada. Neste exemplo, o cliente é interno
para BuildIT, o que significa que o cliente é um funcionário da organização. Em outro
processos, como um processo do pedido ao pagamento, o cliente é externo à organização
nização. Às vezes, existem vários clientes em um processo. Por exemplo, em um
processo de venda de uma casa, há um comprador, um vendedor, um agente imobiliário, um ou vários
vários fornecedores de hipotecas e pelo menos um notário. O resultado do processo é um
transação de vendas. Este resultado fornece valor para o comprador que adquire a casa
e ao vendedor que monetiza a casa. Portanto, tanto o comprador quanto o vendedor
podem ser vistos como clientes neste processo, enquanto os demais atores fornecem vários
Serviços.
Exercício 1.1 Considere o seguinte processo para a admissão de alunos de pós-graduação

em uma universidade.
Página 27
Para se inscrever para admissão, os alunos primeiro preenchem um formulário online. Os aplicativos online são
registrados em um sistema de informação ao qual todos os funcionários envolvidos nas admissões
processo tem acesso. Depois que um aluno envia o formulário online, um documento PDF é
gerado e o aluno é solicitado a fazer o download, assinar e enviar por correio juntos
com os documentos necessários, que incluem:
• Cópias autenticadas de diplomas anteriores e históricos acadêmicos.

• Resultados do teste de língua inglesa.
• Currículo.
Quando esses documentos são recebidos pelo escritório de admissões, um oficial verifica o
plenitude dos documentos. Se algum documento estiver faltando, um e-mail é enviado ao aluno. o
o aluno deve enviar os documentos em falta por correio. Supondo que o aplicativo esteja completo,
o escritório de admissões envia as cópias autenticadas dos diplomas para um reconhecimento acadêmico
agência, que verifica os graus e dá uma avaliação de sua validade e equivalência
em termos de padrões de educação locais. Esta agência exige que todos os documentos sejam enviados para
pelo correio, e todos os documentos devem ser cópias autenticadas dos originais. A agência envia
enviar sua avaliação para a universidade também por correio. Supondo que a verificação de grau seja
bem-sucedido, os resultados do teste de língua inglesa são verificados online por um oficial no
escritório de admissões. Se a validade dos resultados do teste de língua inglesa não puder ser verificada, o
o pedido é rejeitado (as notificações de rejeição são enviadas por e-mail).
Uma vez que todos os documentos de um determinado aluno tenham sido validados, o escritório de admissão encaminha
estes documentos por correio interno para o comitê acadêmico correspondente responsável por
decidir se oferece ou não a admissão. O comitê toma sua decisão com base em
as transcrições acadêmicas e o currículo. O comitê se reúne uma vez a cada 2 a 3 semanas e
examina todos os aplicativos que estão prontos para avaliação acadêmica no momento da reunião.
No final da reunião da comissão, o presidente da comissão notifica as admissões
escritório dos resultados da seleção. Esta notificação inclui uma lista de admitidos e rejeitados
candidatos. Poucos dias depois, o escritório de admissão notifica o resultado para cada candidato
via email. Além disso, os candidatos aprovados recebem uma carta de confirmação por correio.
Com relação ao processo acima, considere as seguintes questões:
1. Quem são os atores neste processo?

2. Quais atores podem ser considerados o cliente (ou clientes) neste processo?
3. Que valor o processo oferece ao (s) cliente (s)?
4. Quais são os resultados possíveis deste processo?
À luz do que precede, definimos um processo de negócios como uma coleção de inter-relacionados
eventos, atividades e pontos de decisão que envolvem uma série de atores e objetos,
e que coletivamente levam a um resultado de valor para pelo menos um cliente .
A Figura 1.1 mostra os ingredientes desta definição e suas relações.
Armados com esta definição de um processo de negócios, definimos BPM como um corpo de
métodos, técnicas e ferramentas para descobrir, analisar, redesenhar, executar e monitorar
processos de negócios . Esta definição reflete o fato de que os processos de negócios são os
ponto focal de BPM, e também o fato de que BPM envolve diferentes fases e atividades
no ciclo de vida dos processos de negócios, como discutiremos mais adiante neste capítulo.
Outras disciplinas além de BPM lidam com processos de negócios de maneiras diferentes, como
explicado na caixa “Disciplinas relacionadas”. Um dos recursos comumente associados
atribuída ao BPM é sua ênfase no uso de modelos de processo ao longo do ciclo de vida
dos processos de negócios. Assim, os modelos de processo estão presentes de uma forma ou de uma
Página 28
Fig. 1.1 Ingredientes de um processo de negócios
outro em praticamente todos os capítulos deste livro e dois capítulos são dedicados ao processo
modelagem.
Em qualquer caso, embora seja útil saber que várias disciplinas compartilham o objetivo de
melhorar os processos de negócios, devemos permanecer pragmáticos e não lançar um único disco
pline um contra o outro como se fossem concorrentes. Em vez disso, devemos abraçar qualquer
técnica que nos ajuda a melhorar os processos de negócios, seja esta técnica ou não
é percebido como sendo parte da disciplina de BPM (no sentido estrito) e independentemente
se a técnica em questão usa ou não modelos de processo.
DISCIPLINAS RELACIONADAS
BPM não é de forma alguma a única disciplina que se preocupa em melhorar o
desempenho operacional das organizações. Abaixo, apresentamos brevemente alguns
disciplinas relacionadas e identificar as principais relações e diferenças entre elas
disciplinas e BPM.
Total Quality Management (TQM) é uma abordagem que historicamente

precedido e inspirado BPM. O foco do TQM está na melhoria contínua
gestão e manutenção da qualidade dos produtos e, por extensão, também dos serviços.
Desta forma, é semelhante ao BPM em sua ênfase sobre a necessidade de ongo-
ing esforços de melhoria. Mas onde o TQM coloca a ênfase nos produtos
e os próprios serviços, a visão por trás do BPM é que a qualidade do produto
produtos e serviços podem ser melhor alcançados com foco na melhoria do
processos que criam esses produtos e serviços. Deve-se admitir que
esta visão é um tanto controversa, pois adeptos contemporâneos de TQM fariam
em vez disso, veja o BPM como uma das várias práticas comumente encontradas
dentro de um programa TQM. Não tanto uma distinção teórica, mas um império
Página 29
O único é que as aplicações de TQM são encontradas principalmente na fabricação

domínios - onde os produtos são tangíveis - enquanto BPM é mais orientado para
organizações de serviço.
Gestão de Operações é um campo que se preocupa com o gerenciamento do físico
e funções técnicas de uma empresa ou organização, particularmente aquelas relacionadas
à produção e manufatura. Teoria da probabilidade, teoria das filas, decisão
análise de integração, modelagem matemática e simulação são importantes tecnologias
técnicas para otimizar a eficiência das operações a partir dessa perspectiva. Como
será discutido no Cap. 7 , tais técnicas também são úteis no contexto
de iniciativas de BPM. O que é bastante diferente entre o gerenciamento de operações
e BPM é que o gerenciamento de operações está geralmente preocupado com
controlar um processo existente sem necessariamente alterá-lo, enquanto o BPM é
muitas vezes preocupado em fazer alterações em um processo existente, a fim de implementar
prove.
Lean é uma disciplina de gestão que se origina da indústria
indústria, em particular a filosofia de engenharia da Toyota. Um dos principais
princípios do Lean é a eliminação de desperdícios , ou seja, atividades que não agregam
valor para o cliente, como discutiremos no cap. 6 . A orientação do cliente
do Lean é semelhante ao do BPM e muitos dos princípios por trás do Lean
foram absorvidos pelo BPM. Nesse sentido, o BPM pode ser visto como um recurso mais
disciplina abrangente do que Lean. Outra diferença é que o BPM coloca mais
ênfase no uso da tecnologia da informação como ferramenta para melhorar os negócios
processos e torná-los mais consistentes e repetíveis.
Seis Sigma é outro conjunto de práticas que se originam da fabricação, em
em particular das práticas de engenharia e produção da Motorola. O principal
característica do Seis Sigma é seu foco na minimização de defeitos (er-
rors). Six Sigma coloca uma forte ênfase na medição da produção de
processos ou atividades, especialmente em termos de qualidade. Six Sigma incentiva
gerentes para comparar sistematicamente os efeitos das iniciativas de melhoria
nas saídas. Na prática, Six Sigma não é necessariamente aplicado sozinho, mas
em conjunto com outras abordagens. Em particular, uma abordagem popular é
mesclar a filosofia do Lean com as técnicas do Six Sigma, levando a
uma abordagem conhecida como Lean Six Sigma . Hoje em dia, muitas das técnicas
de Six Sigma são comumente aplicados em BPM também. No cap. 6 , nós vamos
apresentar algumas técnicas de análise de processos de negócios que são compartilhadas por Six
Sigma e BPM.
Em resumo, podemos dizer que o BPM herda da melhoria contínua

filosofia do TQM, abraça os princípios e técnicas de operação
gestão de ações, Lean e Six Sigma, e os combina com a capacidade
capacidades oferecidas pela moderna tecnologia da informação, a fim de alinhar de forma otimizada
processos de negócios com os objetivos de desempenho de uma organização.
Página 30
Fig. 1.2 Como o processo saiu de foco ao longo dos tempos
1.3 Origens e História do BPM
Para entender melhor por que as organizações se envolvem em BPM e quais os benefícios que isso traz
para eles, vale a pena examinar as razões pelas quais o BPM surgiu e evoluiu
hora extra. Abaixo, olhamos para os drivers da disciplina de BPM a partir de um histórico
perspectiva. Começamos com o surgimento de organizações funcionais, continuamos com
a introdução do pensamento de processo, em direção às inovações e falhas de negócios
Reengenharia de processos. Esta discussão fornece a base para a definição do
Ciclo de vida do BPM depois.
1.3.1 A Organização Funcional
A ideia principal do BPM é focar nos processos ao organizar e gerenciar o trabalho

em uma organização. Esta ideia pode parecer intuitiva e direta à primeira vista.
Na verdade, se alguém está preocupado com a qualidade de um determinado produto ou serviço e
a rapidez com que é entregue ao cliente, porque não considerar os próprios passos que são necessários
essencial para produzi-lo? Mesmo sendo intuitivo, foram necessárias várias etapas evolutivas antes
esta ideia tornou-se parte integrante das estruturas de trabalho das organizações. Figura 1.2
fornece uma visão geral de alguns desenvolvimentos históricos relevantes para BPM.
Em tempos pré-históricos, os humanos principalmente se sustentavam ou os pequenos grupos
eles viviam produzindo sua própria comida, ferramentas e outros itens. Tão cedo
sociedades, os consumidores e produtores de um determinado bem eram frequentemente as mesmas pessoas.
Em termos industriais, as pessoas realizavam seus próprios processos de produção. Como um resultado,
eles sabiam como produzir muitas coisas diferentes. Em outras palavras, eles
eram generalistas.
Na antiguidade, em paralelo com o surgimento das cidades e cidades-estado, este trabalho
tura baseada em generalistas começou a evoluir para o que pode ser caracterizado como um
nível intermediário de especialização . As pessoas começaram a se especializar na arte de entregar
Página 31
1.3 Origens e História do BPM 9
um tipo específico de mercadoria, como cerâmica, ou fornecendo um tipo particular de serviço

vícios, como hospedagem para viajantes. Este desenvolvimento generalizado em direção a uma maior
nível de especialização da força de trabalho culminou nas guildas dos artesãos durante
durante a Idade Média. Essas guildas eram essencialmente grupos de mercadores e artesãos
preocupados com a mesma atividade econômica, como barbeiros, sapateiros, pedreiros,
cirurgiões e escultores.
todo um processo em queOseles
trabalhadores desta época mas
estiveram envolvidos, teriam
nãoum bomsobre
tanto entendimento de
os processos
que produziu os bens ou serviços que obteve de terceiros.
Este maior grau de especialização do trabalhador medieval mudou ainda mais para
tende a uma forma de pura especialização durante a Segunda Revolução Industrial,
entre a segunda metade do século 19 e a Primeira Guerra Mundial. Um nome que é
inseparavelmente ligado a ele está o de Frederick W. Taylor (1856-1915), que propôs
um conjunto de princípios conhecido como gestão científica . Um elemento-chave no aplicativo de Taylor
proach era uma forma extrema de divisão do trabalho. Ao estudar meticulosamente as atividades laborais
ities, como as etapas individuais que eram necessárias para lidar com o ferro-gusa em siderúrgicas,
Taylor desenvolveu instruções de trabalho muito específicas para trabalhadores. Trabalhadores iriam apenas
envolver-se na realização de uma das muitas etapas do processo de produção. Não
apenas na indústria, mas também em ambientes administrativos, como organizações governamentais
ções, o conceito de divisão do trabalho tornou-se a forma mais dominante de organização
trabalhos. O resultado desse desenvolvimento foi que os trabalhadores se tornaram puros especialistas que
se preocuparia com apenas uma única parte de um processo de negócios.
Um efeito colateral das ideias de Taylor e seus contemporâneos foi o surgimento
de uma classe totalmente nova de profissionais, a dos gerentes . Afinal alguem
precisava supervisionar a produtividade de grupos de trabalhadores preocupados com o mesmo
parte de um processo de produção. Os gerentes eram responsáveis por definir o pro-
objetivos de produtividade para trabalhadores individuais e certificando-se de que tais objetivos foram cumpridos.
Em contraste com os mestres das guildas medievais, que só podiam atingir tal classificação
com base em uma obra-prima produzida por eles próprios, os gerentes não são necessariamente
especialistas na execução das tarefas que supervisionam. Seu principal interesse é otimizar como
um trabalho é feito com os recursos sob sua supervisão.
Após o surgimento dos gestores, as organizações se estruturaram ao longo do
princípios da divisão do trabalho. Um próximo e óbvio desafio surgiu então: Como diferenciar
entre as responsabilidades de todos esses gestores? A solução foi criar
unidades funcionais em que pessoas com um foco semelhante em parte da produção pro-
cesso foram agrupados. Essas unidades eram supervisionadas por gerentes com diferentes
responsabilidades. Além disso, as unidades e seus gerentes eram hierarquizados
por exemplo: por exemplo, grupos estão sob departamentos, departamentos estão sob negócios
unidades, etc. O que vemos aqui é a raiz das unidades funcionais que nos são familiares
hoje, quando pensamos em organizações: compras, vendas, armazenamento, finanças,
marketing, gestão de recursos humanos, etc.
A organização funcional que emergiu da mentalidade do Segundo In-
Revolução industrial, dominou o cenário corporativo na maior parte do
Séculos 19 e 20. No final da década de 1980, no entanto, os principais americanos
empresas como IBM, Ford e Bell Atlantic (agora Verizon) perceberam que
sua ênfase na otimização funcional estava criando ineficiências em suas operações
rações que afetavam sua competitividade. Projetos caros que introduziram
Página 32
Fig. 1.3 Processo de compra na Ford na fase inicial
novos sistemas de TI ou trabalho reorganizado dentro de um departamento funcional com o objetivo

de melhorar sua eficiência, não estavam ajudando essas empresas a se tornarem
mais competitivo. Parecia que os clientes permaneciam alheios a esses esforços e
continuou a levar seus negócios para outro lugar, por exemplo, para concorrentes japoneses.
1.3.2 O Nascimento do Pensamento Processual
Um dos eventos revolucionários para o desenvolvimento de BPM foi a aquisição da Ford

ção de uma grande participação financeira na Mazda durante os anos 1980. Ao visitar a Mazda's
plantas, uma das coisas que os executivos observadores da Ford notaram foi que as unidades
dentro da Mazda parecia consideravelmente insuficiente em comparação com
unidades dentro da Ford, mas operavam normalmente. Um famoso estudo de caso ilustrando este fenômeno
nomenon, narrado pela primeira vez por Michael Hammer [ 26 ] e posteriormente analisado por
muitos outros tratam do processo de compra da Ford. A Figura 1.3 descreve a maneira como
a perseguição era feita dentro da Ford na época.
Cada compra que a Ford faria precisava passar pelo processo de compra
partição. Ao decidir que uma determinada quantidade de produtos realmente tinha que ser comprada
perseguido, este departamento enviou um pedido ao fornecedor em questão. Também seria
envie uma cópia desse pedido para contas a pagar. Quando o fornecedor fez o acompanhamento, o
as mercadorias encomendadas seriam entregues no depósito de recebimento da Ford. Juntamente com o
mercadoria veio um aviso de embarque, que foi repassado para contas a pagar. O ven-
dor também enviaria uma fatura para contas a pagar diretamente.
Neste contexto, torna-se claro que a principal tarefa das contas a pagar
era verificar a consistência entre três documentos diferentes (pedido de compra
cópia, aviso de envio, fatura), onde cada documento consiste em cerca de 14 dados
itens (tipo de produto, quantidade, preço, etc.). Não surpreendentemente, vários tipos de doenças
crepância foram descobertas todos os dias e resolver essas discrepâncias ocupadas
Página 33
Fig. 1.4 Processo de compra na Ford após o redesenho
várias centenas de pessoas na Ford. Em contraste, na Mazda, apenas cinco pessoas trabalharam
neste departamento, enquanto a Mazda não era 100 vezes menor do que a Ford em qualquer rele-
medida vantajosa. Fundamentalmente, o problema é que a Ford estava detectando e resolvendo
com problemas (neste caso, discrepâncias) um por um, enquanto a Mazda, em vez disso, foi
evitando as discrepâncias em primeiro lugar. Após uma comparação mais detalhada com
Mazda, a Ford realizou várias mudanças em seu próprio processo de compra, levando a
o processo redesenhado representado na Fig. 1.4 .
Em primeiro lugar, foi desenvolvida uma base de dados central para armazenar informações sobre as compras.
Este banco de dados foi usado pelo departamento de compras para armazenar todas as informações
em pedidos de compra. Este banco de dados substituiu um dos fluxos de papel originais. Sec-
em segundo lugar, novos terminais de computador foram instalados no departamento de armazém que
deu acesso direto a esse banco de dados. Quando as mercadorias chegaram, o pessoal do armazém
poderia verificar imediatamente se a entrega realmente correspondia ao que era originalmente
comprado. Se não fosse esse o caso, a mercadoria simplesmente não era aceita: isso colocava o
ônus do fornecedor para garantir que o que foi entregue foi o que foi solicitado e
nada mais. Nos casos em que uma correspondência foi encontrada entre as mercadorias entregues e
o pedido de compra registrado, a aceitação da mercadoria foi registrada. Então o
única coisa que faltou fazer para as contas a pagar era pagar o que foi acordado no
pedido de compra original. Após esta nova configuração, a Ford conseguiu derrubar
sua força de trabalho em contas a pagar de cerca de 500 pessoas até 120 pessoas
(uma redução de 76%).
Exercício 1.2 Considere o processo de compra na Ford.

2. Quais atores podem ser considerados o cliente (ou clientes) neste processo?
Página 34
Um elemento-chave neste estudo de caso é que um problema de desempenho problemático (ou seja, um
quantidade excessiva de tempo e recursos gastos na verificação de documentos em contas
a pagar) é abordada considerando todo o processo. Neste caso, as contas
departamento de pagamentos desempenha um papel importante no processo de compra geral, mas
o processo também envolve tarefas da equipe do departamento de compras, o armazém,
e pelo vendedor. Independentemente dessas barreiras, as mudanças são feitas em todo o processo
e essas mudanças são multifacetadas: incluem mudanças informativas (informações
trocas de informações), mudanças tecnológicas (banco de dados, terminais) e mudanças estruturais
(verificações, políticas).
Esta visão característica de como olhar para o desempenho organizacional foi colocada
avançar em um artigo seminal de Tom Davenport e James Short [ 11 ]. Neste artigo,
os autores exortaram os gerentes a olhar para processos inteiros ao tentar melhorar o
operações de seus negócios, em vez de olhar para uma tarefa ou negócio específico
função. Vários casos foram discutidos onde de fato esta abordagem particular provou
Ser bem sucedido. No mesmo artigo, o importante papel da TI foi enfatizado como um
capacitador para criar um redesenho dos processos de negócios existentes. Na verdade, quando
olhando para o exemplo Ford-Mazda, pareceria difícil mudar o tradicional
procedimento sem as qualidades específicas de TI, o que em geral permite o acesso a
informações de uma forma que independe de tempo e lugar.
1.3.3 A ascensão e queda do BPR
O trabalho de Davenport e Short, assim como o de outros, desencadeou o surgimento

e ampla adoção de um conceito de gestão que foi referido como Negócios
Reprojeto de Processo ou Reengenharia de Processo de Negócio , muitas vezes convenientemente abreviado
transmitido ao BPR . Vários white papers, artigos e livros apareceram sobre o assunto
ao longo da década de 1990 e empresas em todo o mundo montaram equipes de BPR para
revisar e redesenhar seus processos.
O entusiasmo pelo BPR diminuiu, no entanto, no final dos anos 1990. Muitos compa-
nies encerraram seus projetos de BPR e pararam de apoiar outras iniciativas de BPR.
O que tinha acontecido? Em uma análise retrospectiva, uma série de fatores podem ser distinguidos
adivinhado:
1. Uso indevido de conceito: em algumas organizações, sobre cada programa de mudança ou melhoria
projeto de ment foi rotulado BPR, mesmo quando os processos de negócios não eram o núcleo de
esses projetos. Durante a década de 1990, muitas empresas iniciaram uma redução considerável
ções de sua força de trabalho (downsizing) que, uma vez que eram frequentemente embalados como
projetos de redesenho de processos, provocou intenso ressentimento entre a equipe operacional
e média gerência contra BPR. Afinal, não estava nada claro que operando
o aprimoramento profissional estava realmente impulsionando essas iniciativas.
2. Radicalismo excessivo: alguns dos primeiros proponentes do BPR, incluindo Michael Hammer,
enfatizou desde o início que o redesenho tinha que ser radical, no sentido de que
um novo design para um processo de negócios teve que revisar a maneira como o processo era
inicialmente organizado. Uma indicação reveladora é um dos primeiros artigos de Michael Hammer
Página 35
sobre esse assunto que trazia como subtítulo: “Não automatize, oblitere”. Enquanto um
abordagem radical pode ser justificada em algumas situações, é claro que muitos outros
situações requerem uma abordagem muito mais gradual (incremental).
3. Apoie a imaturidade: Mesmo em projetos que eram centrados no processo desde o início
e adotou uma abordagem mais gradual para melhorar o processo de negócios em questão,
as pessoas enfrentaram o problema de que as ferramentas e tecnologias necessárias para implementar
mento, esse novo design não estava disponível ou não era suficientemente poderoso. Um particu-
A questão principal centrou-se no fato de que muita lógica sobre como os processos tiveram que se desenrolar
eram codificados permanentemente nos aplicativos de TI de suporte da época. Compreensível,
as pessoas ficaram frustradas quando notaram que seus esforços para redesenhar um processo
foram frustrados por uma infraestrutura rígida.
Posteriormente, dois eventos importantes reviveram algumas das ideias por trás do BPR e estabeleceram
a base para o surgimento do BPM. Em primeiro lugar, surgiram estudos empíricos
mostrando que as organizações que eram orientadas para o processo, ou seja, as organizações que
buscou aprimorar processos como base para ganhar eficiência e satisfazer seus
clientes - na verdade se saíram melhor do que as organizações não orientadas a processos. Enquanto o
Os gurus BPR iniciais forneceram estudos de caso convincentes, como o da Ford-
Mazda, não ficou claro para muitos se essas eram exceções em vez de
regra. Em um dos primeiros estudos empíricos sobre este tópico, Kevin McCormack [ 49 ] em
rastreou uma amostra de 100 organizações de manufatura dos EUA e descobriu que o processo-
organizações orientadas mostraram melhor desempenho geral, tendiam a ter uma aposta
ter esprit de corps no local de trabalho e sofreu menos com as con-
flictos. Estudos de acompanhamento confirmaram esse quadro, dando credibilidade renovada a
pensamento cesso.
Um segundo desenvolvimento importante foi de natureza tecnológica. Diferentes tipos de
Surgiu o sistema de TI, mais notavelmente os sistemas Enterprise Resource Planning (ERP) e
Sistemas de gerenciamento de fluxo de trabalho (WfMSs). Os sistemas ERP são essencialmente sistemas
que armazenam todos os dados relacionados às operações comerciais de uma empresa de uma forma consistente
forma, para que todas as partes interessadas que precisam de acesso a esses dados possam obter tal acesso.
Esta ideia de um único banco de dados compartilhado e centralizado permite a otimização de
uso de informações e trocas de informações, que é um facilitador chave do processo
melhoria (cf. Cap. 8 ). 1 WfMSs, por outro lado, são sistemas que distribuem
trabalhar para vários atores em uma empresa com base em modelos de processo. Ao fazê-lo,
um WfMS torna mais fácil implementar mudanças nos processos de negócios (por exemplo, para mudar
a ordem em que as etapas são realizadas) porque as alterações feitas no processo
modelo pode ser colocado em execução com relativa facilidade, em comparação com a situação onde
as regras de execução do processo são codificadas dentro de sistemas de software complexos
e enterrado dentro de dezenas de milhares de linhas de código. Além disso, um WfMS muito próximo
apóia a ideia de trabalhar de maneira centrada no processo.
1 Na realidade, os sistemas ERP são muito mais do que um banco de dados compartilhado. Eles também incorporam vários
módulos para apoiar funções típicas de uma organização, como contabilidade, gerenciamento de estoque,
planejamento de produção, logística, etc. No entanto, do ponto de vista de melhoria de processos, o
O conceito de banco de dados compartilhado por trás dos sistemas ERP é um facilitador importante.
Página 36
Fig. 1.5 Funções de trabalho de um gerente responsável por um processo (também conhecido como proprietário do processo)
Originalmente, os WfMSs se preocupavam principalmente com o trabalho de roteamento entre humanos
atores. Posteriormente, esses sistemas foram aos poucos ampliados com módulos para monitorar
e analisar a execução dos processos de negócios. Paralelamente, o surgimento da Web
serviços tornaram mais fácil conectar um WfMS com outros sistemas, em particular ERP
sistemas. À medida que os WfMSs se tornaram mais sofisticados e melhor integrados com outros
sistemas corporativos, eles ficaram conhecidos como Business Process Management Systems
(BPMSs). A funcionalidade dos BPMSs e seu papel na automação de negócios
processos serão discutidos no Cap. 9 .
A visão histórica acima sugere que BPM é um renascimento do BPR, como de fato BPM
adota a visão centrada no processo nas organizações. Porém, algum cuidado é necessário
quando BPR e BPM estão sendo equacionados. A relação é muito melhor compreendida
com base na Fig. 1.5 .
Esta figura mostra que um gerente responsável por um processo de negócios - também
chamado de proprietário do processo - está preocupado em planejar e organizar o processo em
por um lado e monitoramento do processo por outro. A figura nos permite explicar
as diferenças de escopo entre BPR e BPM. Embora ambas as abordagens tomem o
processo de negócios como ponto de partida, o BPR está principalmente preocupado com o planejamento e
organizar o processo. Em contraste, o BPM fornece conceitos, métodos, técnicas,
e ferramentas que cobrem todos os aspectos do gerenciamento de um processo - planejar, organizar, monitorar,
controle - bem como sua execução real. Em outras palavras, o BPR deve ser visto como um
subconjunto de técnicas que podem ser usadas no contexto de BPM.
Esta discussão destaca que o BPM abrange todo o ciclo de vida dos negócios
processos de ness. Assim, a próxima seção fornece uma visão geral dos conceitos,
métodos, técnicas e ferramentas que compõem a disciplina de BPM através das lentes de
o ciclo de vida do BPM . Esta lente fornece uma visão estruturada de como um determinado processo pode
ser gerenciado.
Página 37
1.4 O ciclo de vida do BPM 15
1.4 O ciclo de vida do BPM
Em geral, a primeira pergunta que uma equipe que embarca em uma iniciativa de BPM precisa
esclarecer é “quais processos de negócios pretendemos melhorar”? Logo no início
e antes que a possibilidade de aplicação de BPM seja colocada na mesa, provavelmente haverá
já ter uma ideia de quais problemas operacionais a equipe tem que resolver e quais
os processos de negócios estão colocando esses problemas operacionais. Em outras palavras, a equipe
não vai começar do zero. Por exemplo, se o problema for que os engenheiros do site
claro que seu trabalho está sendo prejudicado por dificuldades em garantir equipamentos de construção
quando necessário, e sabendo que este equipamento é em grande parte alugado,
é claro que este problema deve ser resolvido olhando para o aluguel de equipamentos
processo. Ainda assim, é preciso delimitar esse processo. Em particular, é preciso responder a perguntas
ções como: O processo começa desde o momento em que os fornecedores de aluguel
são selecionados? Termina quando o equipamento alugado é entregue na construção
local ou termina quando o equipamento é devolvido ao fornecedor, ou termina
continuar até que a taxa de aluguel do equipamento seja paga ao fornecedor?
Estas perguntas podem ser fácil ou difícil de resposta dependendo da quantidade de pro-
pensamento de sucesso ocorreu na organização de antemão. Se a organização tem
envolvidos em iniciativas de BPM antes, é provável que um inventário de negócios
está disponível e que o escopo desses processos foi definido, pelo menos para
alguma extensão. Em organizações que não se envolveram com BPM antes, a equipe de BPM
tem que começar pelo menos identificando os processos que são relevantes para o problema em
a mesa, delimitando o escopo desses processos, e identificando as relações entre
esses processos, como, por exemplo, relações de parte (ou seja, um processo sendo parte de
outro processo). Esta fase inicial de uma iniciativa de BPM é chamada de identificação de processo
cátion . Esta fase leva a uma chamada arquitetura de processo , que normalmente leva
a forma de uma coleção de processos e ligações entre esses processos que representam
diferentes tipos de relação.
Em geral, o objetivo de se envolver em uma iniciativa de BPM é garantir que o negócio
processos de qualidade cobertos pela iniciativa de BPM levam a resultados consistentemente positivos
e entregar o máximo valor à organização no atendimento a seus clientes. Medindo
o valor entregue por um processo é uma etapa crucial no BPM. Como software de renome en-
o gineer, Tom DeMarco, disse uma vez: “Você não pode controlar o que não pode medir
certo". Portanto, antes de começar a analisar qualquer processo em detalhes, é importante claramente
definir as medidas de desempenho do processo (também chamadas de métricas de desempenho do processo )
que será usado para determinar se um processo está em "boa forma" ou "ruim
forma".
Medidas relacionadas a custos são uma classe recorrente de medidas no contexto de BPM.
Por exemplo, voltando ao processo de aluguel de equipamentos, uma possível atuação
medida é o custo total de todos os equipamentos alugados pela BuildIT por intervalo de tempo (por exemplo
por mês). Outra classe ampla e recorrente de medidas são aquelas relacionadas ao tempo.
Um exemplo é a quantidade média de tempo decorrido entre o momento em que um equipamento
O pedido de aluguel é submetido por um engenheiro do local e a entrega do equipamento
para o canteiro de obras. Essa medida é geralmente chamada de tempo de ciclo . Finalmente, um terceiro
A classe de medidas recorrentes são aquelas relacionadas à qualidade e, especificamente, às taxas de erro.
Página 38
A taxa de erro é a porcentagem de vezes que uma execução do processo termina em um

resultado negativo. No caso do processo de aluguel de equipamentos, uma dessas medidas
é o número de equipamentos devolvidos por serem inadequados, ou devido
a defeitos no equipamento entregue. A identificação de tal medida de desempenho
certezas (e objetivos de desempenho associados) são cruciais em qualquer iniciativa de BPM. este
a identificação é geralmente vista como parte da fase de identificação do processo, embora
em alguns casos, pode ser adiado para fases posteriores.
Exercício 1.3 Considere o processo de admissão do aluno descrito no Exercício 1.1 .

Do ponto de vista do cliente, identifique pelo menos duas medidas de desempenho
que pode ser anexado a este processo.
Uma vez que uma equipe de BPM identificou quais processos estão lidando e quais
medidas de desempenho devem ser usadas, a próxima fase para a equipe é entender
o processo de negócios em detalhes. Chamamos essa fase de descoberta de processo . Normalmente, um dos
os resultados desta fase são um ou vários modelos de processo as -is . Estes as-is pro
modelos de processos devem refletir o entendimento de que as pessoas na organização têm
sobre como o trabalho é feito. Os modelos de processos têm como objetivo facilitar a comunicação entre
entre as partes interessadas envolvidas em uma iniciativa de BPM. Portanto, eles têm que ser fáceis
para entender. Em princípio, poderíamos modelar um processo de negócios por meio do tex-
descrições reais, como a descrição textual no Exemplo 1.1 . No entanto, tal textual
as descrições são complicadas de ler e fáceis de interpretar erroneamente por causa do ambiente
identidade inerente ao texto de formato livre. É por isso que é prática comum usar diagramas
para modelar processos de negócios. Os diagramas nos permitem compreender mais facilmente
o processo. Além disso, se o diagrama for feito usando uma notação que seja compreendida por todos
partes interessadas, há menos espaço para qualquer mal-entendido. Observe que esses diagramas
ainda pode ser complementado com descrições textuais, de fato, é comum ver
analistas documentando um processo usando uma combinação de diagramas e texto.
Existem muitas linguagens para modelar processos de negócios em forma de diagrama.
Talvez um dos mais antigos sejam fluxogramas . Em sua forma mais básica, fluxogramas
consistem em retângulos, representando atividades, e diamantes, representando pontos em
o processo em que uma decisão é tomada. De forma mais geral, podemos dizer que independentemente
a notação específica usada, um modelo de processo diagramático normalmente consiste em dois
tipos de nó: nós de atividade e nós de controle. Nós de atividade descrevem unidades de
trabalho que pode ser realizado por humanos ou aplicativos de software, ou uma combinação
disso. Os nós de controle capturam o fluxo de execução entre as atividades. Apesar
nem todas as linguagens de modelagem de processo o suportam, um terceiro tipo importante de elemento
em modelos de processo são nós de eventos. Um nó de evento nos diz que algo pode ou
deve acontecer, dentro do processo ou no ambiente do processo, que requer um
reação, como por exemplo a chegada de uma mensagem de um cliente pedindo para cancelar
seu pedido de compra. Outros tipos de nó podem aparecer em um modelo de processo, mas podemos
dizem que os nós de atividade, nós de evento e nós de controle são os mais básicos.
Existem várias extensões de fluxogramas, como fluxogramas interorganizacionais,
onde o fluxograma é dividido nas chamadas raias que denotam diferentes organismos
unidades nacionais (por exemplo, diferentes departamentos em uma empresa). Se você está familiarizado com o
Página 39
Fig. 1.6 Modelo de processo para um fragmento inicial do processo de aluguel de equipamento
Linguagem de modelagem unificada (UML), você provavelmente terá encontrado UML Ac-
Diagramas de atividade . Em sua essência, os diagramas de atividades UML são interorganizacionais
fluxogramas. No entanto, os diagramas de atividades UML vão além da organização cruzada
fluxogramas, fornecendo símbolos para capturar objetos de dados, sinais e paralelismo
entre outros aspectos. Ainda outra linguagem para modelagem de processos é orientada a eventos
Cadeias de processo ( EPCs ). EPCs têm algumas semelhanças com fluxogramas, mas eles diferem
de fluxogramas em que tratam os eventos como cidadãos de primeira classe. Outros idiomas usados
para modelagem de processos incluem diagramas de fluxo de dados e IDEF3 , apenas para citar dois.
Seria estonteante tentar aprender todas essas línguas ao mesmo tempo. Felizmente,
hoje em dia existe um padrão amplamente utilizado para modelagem de processos, a saber, o Business
Modelo de Processo e Notação (BPMN). A última versão do BPMN é BPMN 2.0.
Foi lançado como padrão pelo Object Management Group (OMG) em 2011.
No BPMN, as atividades são representadas como retângulos arredondados. Nós de controle (chamados
gateways ) são representados usando formas de diamante. Atividades e nós de controle são
conectados por meio de arcos (chamados de fluxos) que determinam a ordem em que o
cess é executado. A Figura 1.6 fornece um modelo que representa um fragmento inicial do
processo de aluguel de equipamentos, até o ponto em que o engenheiro da obra aceita ou rejeita
a solicitação de aluguel de equipamento. Este modelo de processo mostra dois pontos de decisão. No
primeiro, o processo segue um de dois caminhos, dependendo se o equipamento
está disponível ou não. No segundo, a solicitação de aluguel do equipamento é aprovada ou
rejeitado. O modelo também mostra os participantes do processo envolvidos neste fragmento
do processo, nomeadamente o engenheiro de obra, o escriturário e o engenheiro de obra. Cada um de
esses participantes são mostrados como uma via separada contendo as atividades realizadas por
o participante em questão.
Página 40
O modelo de processo da Figura 1.6 é capturado em um alto nível de abstração. Na melhor das hipóteses
pode servir para dar a uma pessoa externa um resumo do que acontece neste processo.
Em alguns casos, porém, o modelo precisa de mais detalhes para ser útil. Qual
detalhes adicionais devem ser incluídos em um modelo de processo depende da finalidade.
Muitas vezes, os modelos de processo têm como objetivo servir como documentação do caminho
uma organização funciona. Neste caso, as principais características dos modelos de processo são
simplicidade e compreensibilidade. Assim, anotações de texto adicionais podem ser
adicionado ao modelo de processo para esclarecer o significado de certas atividades ou eventos, mas
além dessas anotações, nenhum detalhe adicional seria adicionado. Em outros casos,
os modelos de processo devem ser analisados em detalhes, por exemplo, a fim de medir
desempenho seguro do processo. Neste caso, mais detalhes podem ser necessários, como como
quanto tempo cada tarefa leva (em média). Finalmente, em alguns casos, os modelos de processo são
pretende ser implantado em um BPMS com a finalidade de coordenar a execução
do processo (cf. Seção 1.3.3 ). No último caso, o modelo precisa ser estendido
com uma quantidade significativa de detalhes sobre as entradas e saídas do processo
e cada uma de suas atividades.
Tendo entendido o processo como está em detalhes, a próxima etapa é identificar e
analisar as questões neste processo. Um problema potencial no aluguel de equipamentos da BuildIT
processo é que o tempo de ciclo é muito alto. Como resultado, os engenheiros do site não conseguem
obtenha o equipamento necessário a tempo. Isso pode causar atrasos em várias obras
tarefas, que podem resultar em atrasos nos projetos de construção. A fim de
analisar esses problemas, um analista precisaria coletar informações sobre o tempo
gasto em cada tarefa do processo, incluindo a quantidade de tempo que o processo
participantes gastam realmente fazendo o trabalho e a quantidade de tempo ocioso, o que significa que
quantidade de tempo em que a solicitação do equipamento é bloqueada, esperando por algo para
acontecer. Esse tempo ocioso também é chamado de tempo de espera . Além disso, o analista precisaria
coletar informações sobre a quantidade de retrabalho que ocorre no processo.
Aqui, retrabalho significa que uma ou várias tarefas são repetidas porque algo foi
errado. Por exemplo, quando o funcionário identifica uma peça adequada de equipamento em um
catálogo do fornecedor, mas depois descobre que o equipamento não está disponível
nas datas exigidas, o funcionário pode precisar procurar novamente por uma peça alternativa
de equipamentos de outro fornecedor. Tempo valioso é gasto pelo funcionário voltando
e adiante entre consultar os catálogos e entrar em contato com os fornecedores para verificar o
disponibilidade de plantas. Para analisar este problema, o analista precisaria encontrar
em que porcentagem de casos a verificação de disponibilidade falha e, portanto, com que frequência o
o funcionário precisa fazer algum retrabalho para identificar peças alternativas de equipamento
e verifique sua disponibilidade. Dada esta informação, um analista de processo pode empregar
várias técnicas a serem discutidas ao longo deste livro, a fim de rastrear o
causa (s) de tempos de ciclo longos e para identificar formas de alterar o processo em ordem
para reduzir o tempo de ciclo.
Outro problema potencial no processo de aluguel de equipamentos da BuildIT é que às vezes
o equipamento entregue no local da construção é inadequado, e o engenheiro do local
tem que rejeitá-lo. Este é um exemplo de resultado negativo. Para analisar este problema,
um analista precisaria descobrir com que freqüência esses resultados negativos estão ocorrendo.
Em segundo lugar, os analistas precisariam obter informações que lhes permitissem
para entender por que esses resultados negativos estão acontecendo. Em outras palavras, onde
Página 41
as coisas deram errado em primeiro lugar? Às vezes, esse resultado negativo pode
resultam de falta de comunicação, por exemplo, entre o engenheiro do local e o balconista.
Caso contrário, pode vir de dados imprecisos (por exemplo, erros na descrição do
equipamento) ou de um erro do lado do fornecedor. Apenas identificando, classificando
e, finalmente, compreender as principais causas de tais resultados negativos pode um
analista descobrir qual seria a forma mais adequada de abordar esta questão. o
identificação e avaliação de problemas e oportunidades para melhoria de processos
é aqui chamada de fase de análise do processo .
Observamos que as duas questões discutidas acima estão intimamente relacionadas ao desempenho
medidas. Por exemplo, o primeiro problema acima está relacionado ao tempo de ciclo e tempo de espera,
ambos são medidas de desempenho típicas de um processo. Da mesma forma, o segundo
questão está ligada à "porcentagem de rejeições de equipamentos", que é essencialmente um erro
taxa - outra medida típica de desempenho. Assim, avaliando os problemas de um processo
muitas vezes anda de mãos dadas com a medição do estado atual do processo com respeito
a certas medidas de desempenho.
Exercício 1.4 Considere novamente o processo de admissão do aluno descrito em Exer-

cise 1.1 . Do ponto de vista do cliente, pense em pelo menos duas questões que
este processo pode ter.
Depois que os problemas em um processo forem analisados e possivelmente quantificados, o próximo

fase é identificar e analisar soluções potenciais para esses problemas. Neste ponto, o
analista irá considerar várias opções possíveis para resolver um problema. Fazendo
então, o analista precisa ter em mente que uma mudança em um processo para abordar um
problema pode potencialmente causar outros problemas no caminho. Por exemplo, para
acelerar o processo de aluguel de equipamentos, pode-se pensar em remover a aprovação
etapas envolvendo o engenheiro de obra. No entanto, se for levado ao extremo, essa mudança
significaria que o equipamento alugado pode às vezes não ser o ideal, uma vez que o
o ponto de vista do engenheiro de obras não é levado em consideração. O engenheiro de obras tem uma
visão sobre os projetos de construção e pode ser capaz de propor formas alternativas de
abordar as necessidades de equipamento de um projeto de construção de uma maneira mais eficaz.
Alterar
maneira um processo
segura não é às
e pode resistir tãomudanças.
fácil quanto parece.
Além Assepessoas
disso, estãoimplicar
a mudança acostumadas a trabalhar
em modificar o em um cer-
sistema (s) de informação que sustentam o processo, a mudança pode ser cara ou pode
exigem mudanças não só na organização que coordena o processo, mas também na
outras organizações. Por exemplo, uma maneira de eliminar o retrabalho que o funcionário tem
a fazer ao verificar a disponibilidade de equipamentos, seria que os fornecedores
vide informações sobre a disponibilidade de plantas. Dessa forma, o balconista usaria
a mesma interface para procurar equipamentos adequados e verificar a disponibilidade de
o equipamento pelo período de tempo necessário. No entanto, essa mudança no processo
exigiria que os fornecedores mudassem seu sistema de informação, de modo que seu sistema
tem expõe informações atualizadas de disponibilidade de equipamento para BuildIT. Esta mudança
está pelo menos parcialmente fora do controle do BuildIT. Supondo que os fornecedores
ser capaz de fazer tais mudanças, uma solução mais radical que poderia ser considerada
seria fornecer dispositivos móveis e conexão à Internet para os engenheiros do site, para
Página 42
que eles podem consultar o catálogo de equipamentos (incluindo informações de disponibilidade)

Qualquer tempo e qualquer lugar. Dessa forma, o secretário não precisaria estar envolvido no
processo durante a fase de busca de equipamentos, evitando assim falhas de comunicação
entre o engenheiro do local e o balconista. Se esta mudança mais radical é ou não
viável exigiria uma análise aprofundada do custo de mudança do processo neste
forma versus os benefícios que tal mudança traria.
Exercício 1.5 Dados os problemas no processo de admissão identificados no Exercício 1.4 ,

que possíveis mudanças você acha que poderiam ser feitas neste processo, a fim de resolver
estas questões?
Equipado com a compreensão de um ou vários problemas em um processo e um pode

conjunto de soluções potenciais, os analistas podem propor uma versão redesenhada do
processo, em outras palavras, um to-be processo que iria resolver os problemas identificados
no processo como está. Este processo futuro é a principal saída do redesenho do processo
fase . Aqui, é importante ter em mente que a análise e o redesenho são intrincadamente
relacionados. Pode haver várias opções de redesenho e cada uma dessas opções deve
ser analisado, de modo que uma escolha informada possa ser feita sobre qual opção deve ser
escolhido.
Depois de redesenhados, as mudanças necessárias nas formas de trabalho e no sistema de TI
fatores da organização devem ser implementados de modo que o processo futuro possa até
ser posta em execução. Esta fase é chamada de implementação de processo . No
caso do processo de aluguel de equipamentos, a fase de implementação do processo significaria
colocar em prática um sistema de informação para registrar e rastrear o aluguel de equipamentos
quests, POs associados a pedidos aprovados e faturas associadas a esses POs.
A implantação de tal sistema de informação significa não apenas desenvolver a composição de TI
nents deste sistema. Também se relacionaria ao treinamento dos participantes do processo para que
eles realizam seu trabalho no espírito do processo redesenhado e fazem o melhor uso
dos componentes de TI do sistema.
De forma mais geral, a implementação do processo pode envolver duas facetas complementares:
gerenciamento de mudanças organizacionais e automação de processos . Mudança organizacional
gestão refere-se ao conjunto de atividades necessárias para mudar a forma de trabalhar de
todos os participantes envolvidos no processo. Essas atividades incluem:
• Explicar as mudanças para os participantes do processo ao ponto que eles entendem

saber quais mudanças estão sendo introduzidas e por que essas mudanças são benéficas
cial para a empresa.
• Colocar em prática um plano de gestão de mudança para que as partes interessadas saibam quando
as mudanças sejam postas em vigor e quais disposições transitórias serão adotadas
planejado para resolver problemas durante a transição para o processo futuro.
• Treinar os usuários para a nova forma de trabalhar e monitorar as mudanças a fim de
garantir uma transição suave para o processo futuro.
Por outro lado, a automação do processo envolve a configuração ou implementação

de um sistema de TI (ou a reconfiguração de um sistema de TI existente) para apoiar o
Processo “futuro”. Este sistema deve apoiar os participantes do processo no desempenho
Página 43
Fig. 1.7 Ciclo de vida BPM
das tarefas do processo. Isso pode incluir a atribuição de tarefas aos participantes do processo,
ajudando os participantes do processo a priorizar seu trabalho, fornecendo aos participantes do processo
com as informações de que precisam para realizar uma tarefa e realizar cruzamentos automatizados
verificações e outras tarefas automatizadas sempre que possível. Existem várias maneiras de im-
implementar tal sistema de TI. Este livro se concentra em uma abordagem particular, que
consiste em estender o modelo de processo a ser obtido a partir do redesenho do processo
fase para torná-lo executável por um BPMS (cf. Seção 1.3.3 ).
Com o tempo, alguns ajustes podem ser necessários porque o negócio implementado
processo de ness não atende às expectativas. Para tanto, o processo precisa ser moni-
orientado e os analistas devem examinar os dados coletados, monitorando o processo em
a fim de identificar os ajustes necessários para melhor controlar a execução do processo.
Essas atividades são englobadas pela fase de monitoramento e controle do processo .
Esta fase é importante porque abordar um ou um punhado de problemas em um processo
não é o fim da história. Em vez disso, gerenciar um processo requer um esforço contínuo.
A falta de monitoramento e melhoria contínua de um processo leva à degradação.
Como Michael Hammer certa vez disse: "todo bom processo eventualmente se torna um mau pro-
cess ”, a menos que seja continuamente adaptado e melhorado para acompanhar as constantes mudanças
panorama das necessidades do cliente, tecnologia e concorrência. É por isso que as fases
no ciclo de vida do BPM deve ser visto como circular: a saída do monitoramento e
o controle realimenta as fases de descoberta, análise e redesenho.
Para resumir, podemos ver o BPM como um ciclo contínuo compreendendo o seguinte
fases (ver Fig. 1.7 ):
• Identificação do processo. Nesta fase, um problema de negócios é colocado, os processos rele-
vantajosa para o problema a ser abordado são identificados, delimitados e relacionados a cada
de outros. O resultado da identificação do processo é um arquivo de processo novo ou atualizado
tectura que fornece uma visão geral dos processos em uma organização e seus
relacionamentos. Em alguns casos, a identificação do processo é feita em paralelo com
Página 44
identificação da medida de desempenho. Neste livro, no entanto, vamos associar desempenho

identificação da medida de mance com a fase de análise do processo, dado que o desempenho
Medidas de mance são freqüentemente usadas para análise de processos.
• Descoberta de processo (também chamada de modelagem de processo no estado em que se encontra). Aqui, o estado atual
de cada um dos processos relevantes é documentado, normalmente na forma de um ou
vários modelos de processo as-is. 2
• Análise de processos. Nesta fase, os problemas associados ao processo as-is são identificados
cado, documentado e, sempre que possível, quantificado por meio de medidas de desempenho.
A saída desta fase é uma coleção estruturada de questões. Esses problemas são típicos
priorizados em termos de seu impacto e, às vezes, também em termos de
esforço estimado necessário para resolvê-los.
• Redesenho de processos (também chamado de melhoria de processos ). O objetivo desta fase é
identificar mudanças no processo que ajudariam a resolver os problemas identificados
na fase anterior e permitir que a organização cumpra seus objetivos de desempenho
tives. Para este fim, várias opções de mudança são analisadas e comparadas em termos de
as medidas de desempenho escolhidas. Isso implica que o redesenho do processo e o processo
análise andam de mãos dadas: à medida que novas opções de mudança são propostas, elas são ana-
lisado usando técnicas de análise de processo. Eventualmente, a mudança mais promissora
as opções são combinadas, levando a um processo redesenhado. A saída desta fase
é tipicamente um modelo de processo futuro, que serve como base para a próxima fase.
• Implementação de processos. Nesta fase, as mudanças necessárias para sair do
processo como está para o processo futuro são preparados e executados. Processo de implementação
mentação cobre dois aspectos: gestão e processo de mudança organizacional
automação. Gestão de mudança organizacional refere-se ao conjunto de atividades re-
quis mudar a forma de trabalhar de todos os participantes envolvidos no processo.
A automação de processos, por outro lado, se refere ao desenvolvimento e implantação
de sistemas de TI (ou versões aprimoradas de sistemas de TI existentes) que suportam o futuro
processo. Neste livro, nosso foco com relação à implementação de processos está em
automação de processos, já que o gerenciamento de mudanças organizacionais é um processo totalmente separado
campo. Mais especificamente, o livro apresenta uma abordagem para automação de processos
em que um modelo de processo executável é derivado do modelo de processo a ser
e este modelo executável é implantado em um BPMS.
• Monitoramento e controle de processos. Assim que o processo redesenhado estiver em execução, rel-
dados evidentes são coletados e analisados para determinar o quão bem está o processo por
formando com relação às suas medidas de desempenho e objetivos de desempenho.
Gargalos, erros recorrentes ou desvios em relação ao comportamento pretendido
são identificados e ações corretivas são realizadas. Novos problemas podem surgir, em
o mesmo ou em outros processos, exigindo que o ciclo seja repetido de forma contínua
base.
2 Esta fase também é chamada de projeto de processo na literatura. No entanto, a descoberta do processo é indiscutivelmente um
termo mais apropriado, uma vez que o processo já existe, pelo menos implicitamente na cabeça dos atores
quem o executa. O objetivo dessa fase é geralmente descobrir o processo, em vez de projetá-lo.
Em casos raros (por exemplo, novas empresas), nenhum processo ainda está em vigor, então as fases de descoberta e análise
não são necessários e o processo deve ser projetado pela primeira vez, em vez de redesenhado.
Página 45
O ciclo de vida do BPM ajuda a entender o papel da tecnologia no BPM. Tech-

tecnologia em geral, e especialmente Tecnologia da Informação (TI), é um instrumento fundamental
para melhorar os processos de negócios. Não surpreendentemente, especialistas de TI, como sistemas de engi-
Os neers geralmente desempenham um papel significativo nas iniciativas de BPM. No entanto, para atingir o máximo
eficácia, os engenheiros de sistema precisam estar cientes de que a tecnologia é apenas um instrumento
para gerenciar e executar processos. Os engenheiros de sistema precisam trabalhar em conjunto com
analistas de processo, a fim de compreender quais são as principais questões que afetam um determinado pro-
processo, e como melhor resolver esses problemas, seja por meio de automação ou por outro
significa. Como um renomado empresário de tecnologia, Bill Gates, uma vez disse isso:
“A primeira regra em qualquer tecnologia usada em um negócio é que a automação aplicada a
uma operação eficiente aumentará a eficiência. A segunda é que a automação
aplicado a uma operação ineficiente aumentará a ineficiência ”. Isso significa que
aprender como projetar e melhorar processos - e não apenas como construir um sistema de TI
sistema para automatizar uma parte estreita de um processo de negócios - é uma habilidade fundamental que
deve estar nas mãos de qualquer graduado em TI. Reciprocamente, os graduados em negócios precisam
para entender como a tecnologia, e particularmente TI, pode ser usada para otimizar o ex-
execução de processos de negócios. Este livro visa estabelecer uma ponte entre esses dois pontos de vista,
apresentando um ponto de vista integrado cobrindo todo o ciclo de vida do BPM.
Um ponto de vista complementar sobre o ciclo de vida do BPM é fornecido pela caixa “Stake-
titulares do ciclo de vida do BPM ”. Esta caixa resume as funções em uma empresa que
estão direta ou indiretamente envolvidos em iniciativas de BPM. 3 A lista de funções descritas em
a caixa destaca o fato de que BPM é interdisciplinar. Uma iniciativa típica de BPM
envolve gerentes em diferentes níveis da organização, administrativo e de campo
trabalhadores (chamados de participantes do processo na caixa), analistas de negócios e de sistema e
Equipes de TI. Assim, o livro visa fornecer uma visão equilibrada das técnicas, tanto
da ciência da gestão e TI, no que se refere ao BPM.
STAKEHOLDERS NO CICLO DE VIDA BPM

Existem diferentes partes interessadas envolvidas com um processo de negócios em todo
seu ciclo de vida. Entre eles podemos distinguir os seguintes indivíduos e
grupos.
• Equipe de gerenciamento . Dependendo de como a gestão de uma empresa é
organizado, pode-se encontrar as seguintes posições. O Executivo Principal
ficer ( CEO ) é responsável pelo sucesso geral dos negócios da empresa.
O Diretor de Operações ( COO ) é responsável por definir a forma
operações são configuradas. Em algumas empresas, o COO também é responsável por
desempenho do processo, enquanto em outras empresas, há uma posição
3A função do cliente não está listada na caixa, pois esta função já foi discutida em
Seções.
Página 46
ção do Chief Process Officer ( CPO ) para este fim. The Chief Information
Officer ( CIO ) é responsável pela operação eficiente e eficaz do
infra-estrutura de sistema de informação. Em algumas organizações, redesenho de processos
os projetos são conduzidos pelo CIO. O Diretor Financeiro ( CFO ) é re-
responsável pelo desempenho financeiro geral da empresa. O CFO
também pode ser responsável por certos processos de negócios, particularmente aqueles
que têm um impacto direto no desempenho financeiro. Outro gerenciamento de po-
situações que têm interesse no ciclo de vida dos processos incluem o Humano
Diretor de Recursos ( RH ) . O diretor de RH e sua equipe desempenham um papel fundamental na
processos que envolvem um número significativo de participantes do processo. Em qualquer
caso, a equipe de gestão é responsável por supervisionar todos os processos, ini-
promover iniciativas de redesenho de processos e fornecer recursos e estratégias
orientação para as partes interessadas envolvidas em todas as fases da vida do processo de negócios-
ciclo.
• Proprietários do processo . Um proprietário de processo é responsável pela eficiência e eficácia
operação ativa de um determinado processo. Conforme discutido no contexto da Fig. 1.5 ,
um proprietário do processo é responsável por um lado pelo planejamento e organização,
e por outro lado, para monitorar e controlar o processo. Em seus
papel de planejamento e organização, o proprietário do processo é responsável por definir
medidas de desempenho e objetivos, bem como iniciar e liderar im-
projetos de comprovação relacionados ao seu processo. Eles também são responsáveis por
garantir recursos para que o processo seja executado sem problemas em uma base diária. No
seu papel de monitoramento e controle, os proprietários do processo são responsáveis por
garantindo que os objetivos de desempenho do processo sejam atendidos e levando
ações corretivas caso não sejam atendidas. Os proprietários do processo também fornecem
orientação para os participantes do processo sobre como resolver exceções e erros
que ocorrem durante a execução do processo. Assim, o proprietário do processo é
envolvido na modelagem de processos, análise, redesenho, implementação e mon-
itoring. Observe que o mesmo indivíduo pode muito bem ser responsável por vários
processos ple. Por exemplo, em uma pequena empresa, um único gerente pode
ser responsável tanto pelo processo de pedido ao pagamento da empresa quanto pelo
processo de atendimento ao cliente pós-venda.
• Participantes do processo . Os participantes do processo são atores humanos que atuam
as atividades de um processo de negócios no dia-a-dia. Eles conduzem
trabalho rotineiro de acordo com as normas e diretrizes da empresa.
Os participantes do processo são coordenados pelo proprietário do processo, que está respondendo
capaz de lidar com aspectos não rotineiros do processo. Participantes do processo
também estão envolvidos como especialistas de domínio durante a descoberta de processos e processos
análise. Eles apóiam atividades de redesenho e esforços de implementação.
• Analistas de processos . Os analistas de processo conduzem a identificação do processo, descobrem
eria (em particular modelagem), atividades de análise e redesenho. Eles coor-
implementação de processos dinâmicos, bem como monitoramento e controle de processos
ling. Eles se reportam à gestão e aos proprietários do processo e interagem intimamente
Página 47
com os participantes do processo. O analista de processo normalmente tem um de dois

motivos. Analistas de processo preocupados com os requisitos organizacionais, por
formance e o gerenciamento de mudanças têm experiência em negócios. Significar-
enquanto, analistas de processos preocupados com a automação de processos têm uma equipe de TI
fundo.
• Engenheiros de sistema . Engenheiros de sistema estão envolvidos no redesenho de processos e
implementação. Eles interagem com analistas de processo para capturar sistema de recuperação
quirements. Eles traduzem os requisitos em um design de sistema e são
responsável pela implementação, teste e implantação deste sistema.
Os engenheiros de sistema também fazem a ligação com o proprietário do processo e os participantes do processo
calças para garantir que o sistema desenvolvido apoie o seu trabalho de uma forma eficaz
maneira ativa. Muitas vezes, implementação, teste e implantação de sistema
são terceirizados para fornecedores externos, caso em que a engenharia do sistema
a equipe será composta pelo menos parcialmente por contratados.
• O Grupo BPM (também denominado Centro de Excelência BPM ). Grande organização
ções que estiveram envolvidas em BPM por vários anos normalmente teriam
acumulou conhecimento valioso sobre como planejar e executar projetos de BPM
bem como quantidades substanciais de documentação do processo. O Grupo BPM
é responsável por preservar este conhecimento e documentação e garantir
que eles são usados para atender aos objetivos estratégicos da organização. Especifi-
naturalmente, o grupo de BPM é responsável por manter a arquitetura do processo
estrutura, priorizando projetos de redesenho de processos, dando suporte ao processo
proprietários e analistas de processo, e garantindo que a documentação do processo
é mantido de forma consistente e que o sistema de monitoramento de processo
tems estão trabalhando de forma eficaz. Em outras palavras, o grupo BPM é responsável
para manter uma cultura BPM e garantir que esta cultura BPM seja suprida
portar os objetivos estratégicos da organização. Nem todas as organizações têm um
Grupo de BPM dedicado. Grupos de BPM são mais comuns em grandes organizações
com anos de experiência em BPM.
No restante do livro, mergulharemos consecutivamente em cada uma das fases do

Ciclo de vida do BPM. O Capítulo 2 trata da fase de identificação do processo. Capítulos 3 - 4
fornecer uma introdução à modelagem de processos, que serve como pano de fundo para sub-
fases sequentes no ciclo de vida do BPM. O Capítulo 5 trata da descoberta do processo
Estágio. Capítulos 6 - 7 número um presente de técnicas de análise de processo. Nós classificamos
essas técnicas em qualitativas (Cap. 6 ) e quantitativas (Cap. 7 ). Um quan-
técnica titativa é aquela que leva dados brutos ou medições como entrada (por exemplo, desempenho
mance mede ao nível das tarefas) e produz medidas agregadas e
resumos quantitativos como saída. Por outro lado, uma técnica qualitativa envolve
julgamento humano, por exemplo, a fim de classificar tarefas ou questões de acordo com sub-
critérios objetivos. Observe que as técnicas qualitativas podem envolver avaliação quantitativa
além do julgamento humano, visto que essas duas fontes de insights costumam servir
objetivos mentais. Em seguida, cap. 8 oferece uma visão geral das técnicas de redesenho de processos,
Página 48
enquanto o cap. 9 discute a implementação do processo com foco nos aspectos de automação.
Finalmente, cap. 10 apresenta ferramentas e técnicas de inteligência de processo, que formam
a espinha dorsal das práticas modernas de monitoramento de processos.
1.5 Recapitulação
Devemos reter neste capítulo que um processo é uma coleção de eventos, atividades
e decisões que levam coletivamente a um resultado que agrega valor a uma organização
clientes da zation. Cada organização possui processos. Compreendendo e gerenciando
esses processos, a fim de garantir que eles produzam valor de forma consistente, é um ingrediente-chave
diente para a eficácia e competitividade das organizações. Através de seu foco
nos processos, as organizações estão gerenciando os ativos que são mais importantes para
servir bem seus clientes.
Se quiséssemos capturar BPM em poucas palavras, poderíamos dizer que BPM é um corpo
de princípios, métodos e ferramentas para projetar, analisar, executar e monitorar negócios
processos. Também vimos que modelos de processos e medidas de desempenho podem ser
vistos como pilares fundamentais para a gestão de processos. Está muito em cima deles
da arte e da ciência do BPM. A definição fornecida abrange
as principais fases do ciclo de vida do BPM e as várias disciplinas relacionadas que compõem
implementar BPM, como Lean, Six Sigma e Gestão de Qualidade Total. A mira de
este capítulo era para dar uma "prévia" das atividades e partes interessadas envolvidas
em cada uma dessas fases. O resto do livro visa lançar luz sobre muitas das
princípios e métodos que são usados em cada uma dessas fases.
1.6 Soluções para exercícios
Solução 1.1
1. Oficial de admissões, candidato, agência de reconhecimento acadêmico e comissão acadêmica

mittee. O escritório de admissões como uma unidade organizacional também pode ser reconhecido como
um ator separado.
2. O requerente.
3. Pode-se argumentar que o valor que o processo proporciona ao requerente é o
avaliação do pedido e subsequente decisão de aceitação ou rejeição. No
neste caso, o processo agrega valor se o requerente for aceito ou rejeitado,
desde que o pedido seja processado na devida ordem. Outro ponto de vista seria
quer dizer que o processo só dá valor ao requerente apenas se o requerente
é aceite, e não se o candidato for rejeitado. Os argumentos podem ser apresentados em
favor de qualquer um desses dois pontos de vista.
4. Candidatura rejeitada devido a documentos incompletos; Candidato rejeitado devido a En-
resultados do teste de língua inglesa; Candidato rejeitado devido à avaliação do acadêmico
agência de reconhecimento; Candidato rejeitado devido à decisão do comitê acadêmico;
Página 49
1.6 Soluções para exercícios 27
Candidato aceito. Uma análise mais aprofundada poderia revelar outras possíveis
vem como "Solicitação retirada pelo candidato" ou "Condição do candidato-
almente aceite, sujeito ao fornecimento de documentos adicionais ”. No entanto, não há
elementos suficientes na descrição do processo para determinar se estes
os resultados são possíveis.
Solução 1.2
1. A unidade com necessidade de compra, departamento de compras, o vendedor, o armazém

casa e o departamento de contas a pagar.
2. A unidade com necessidade de compra.
3. O valor que o processo fornece à unidade com necessidade de compra é o
fornecimento oportuno, preciso e econômico de um item de compra específico. No
neste caso, o processo agrega valor se a necessidade de compra do item for satisfeita
enviado por uma remessa oportuna, precisa e econômica de um fornecedor, acompanhada
com um procedimento de pagamento preciso.
4. O envio de mercadorias pode ser aceito se for preciso, levando a um correspondente
pagamento, ou podem ser rejeitados se o montante ou tipo de envio não estiver correto.
Solução 1.3 As medidas possíveis incluem:
1. Tempo médio entre o momento em que um aplicativo é recebido e o momento em que ele
é aceito ou rejeitado (tempo de ciclo). Observe que se a Universidade anunciar um pré-
prazo definido para notificação de aceitação / rejeição, uma performance alternativa
medida seria a porcentagem de vezes que esse prazo é cumprido.
2. Porcentagem de inscrições rejeitadas devido a documentos incompletos. Aqui nós poderíamos
distinguir entre duas variantes desta medida: uma que conta todos os casos em que
inscrições são inicialmente rejeitadas devido a documentos incompletos, e outro
que conta o número de casos em que os pedidos são rejeitados devido a incom-
documentos completos e quando o requerente não reenviar o pedido preenchido
plicação, por exemplo, porque o prazo para inscrições expirou antes
o requerente reúne os documentos necessários.
3. Porcentagem de inscrições rejeitadas devido ao idioma inglês expirado, inválido ou baixo
resultados do teste de calibração.
4. Porcentagem de inscrições rejeitadas devido a conselhos de reconhecimento acadêmico.
5. Porcentagem de inscrições aceitas.
Observe que o custo incorrido pela Universidade por aplicação não é uma medida que
é relevante do ponto de vista do requerente, mas pode ser relevante do
perspectiva da Universidade.
Solução 1.4 Os possíveis problemas incluem:
1. Longos tempos de execução

2. Inconveniente de reunir e enviar todos os documentos exigidos.
3. Potencialmente: aplicativos maltratados devido à entrega de documentos em papel
entre os participantes do processo.
Página 50
Solução 1.5
Para reduzir o tempo de ciclo, bem como aplicativos maltratados, os aplicativos podem ser
compartilhado em formato eletrônico entre o escritório de admissões e o comitê acadêmico.
Para reduzir a inconveniência do envio, as inscrições podem ser avaliadas em dois
estágios. A primeira fase envolveria documentos submetidos exclusivamente eletronicamente
(por exemplo, cópias digitalizadas em vez de cópias físicas). Somente candidatos aceitos pelo
o comitê acadêmico então precisaria passar pelo processo de apresentação
cópias autenticadas de diplomas por correio para verificação pelo reconhecimento acadêmico
agência.
1.7 Exercícios adicionais
Exercício 1.6 Considere o seguinte processo em uma farmácia.
Os clientes deixam suas prescrições no balcão do drive-through ou na frente

balcão da farmácia. Os clientes podem solicitar que sua receita seja preenchida imediatamente.
Nesse caso, eles têm que esperar entre 15 minutos e uma hora, dependendo da corrente
carga de trabalho. A maioria dos clientes não está disposta a esperar tanto tempo, então eles optam por indicar uma escolha
mais tarde durante o dia. Geralmente, os clientes deixam suas prescrições no
manhã antes de ir para o trabalho (ou na hora do almoço) e eles voltam para pegar as drogas
depois do trabalho, normalmente entre 17h e 18h. Ao descartar sua receita, um técnico
pergunta ao cliente o horário de coleta e coloca a receita em uma caixa rotulada com o
hora anterior à hora de pick-up. Por exemplo, se o cliente pede a receita
estar pronto às 17h, o técnico irá colocá-lo na caixa com a etiqueta 16h (há uma caixa
para cada hora do dia).
A cada hora, um dos técnicos da farmácia recolhe as receitas a serem preenchidas no
hora atual. O técnico então insere os detalhes de cada prescrição (por exemplo, dados médicos,
detalhes do paciente e detalhes da medicação) no sistema de farmácia. Assim que os detalhes de
uma prescrição é inserida, o sistema da farmácia realiza uma verificação automatizada chamada Medicamento
Revisão de utilização (DUR). Esta verificação visa determinar se a receita contém
quaisquer medicamentos que possam ser incompatíveis com outros medicamentos que tenham sido dispensados ao mesmo
cliente no passado, ou medicamentos que podem ser inadequados para o cliente, levando em consideração
os dados do cliente mantidos no sistema (por exemplo, idade).
Todos os alarmes disparados durante o DUR automatizado são revisados por um farmacêutico que realiza um
verificação mais completa. Em alguns casos, o farmacêutico ainda tem que ligar para o médico que emitiu
a prescrição para a confirmar.
Após o DUR, o sistema realiza uma verificação de seguro para determinar se
a apólice de seguro do cliente arcará com o custo total ou parcial dos medicamentos. No
na maioria dos casos, a saída desse cheque é que a seguradora pagaria por um determinado
porcentagem dos custos, enquanto o cliente tem que pagar pela parte restante (também chamada
o co-pagamento ). As regras para determinar quanto a seguradora pagará e
quanto o cliente tem que pagar são muito complicados. Cada seguradora tem
regras diferentes. Em alguns casos, a apólice de seguro não cobre um ou vários medicamentos em um
prescrição, mas o medicamento em questão pode ser substituído por outro medicamento abrangido pelo
apólice de seguro. Quando esses casos são detectados, o farmacêutico geralmente liga para o médico
e / ou o paciente para determinar se é possível realizar a reposição medicamentosa.
Depois que a receita passa na verificação do seguro, ela é atribuída a um técnico que coleta
os medicamentos das prateleiras e os coloca em uma sacola com a prescrição grampeada. Af-
depois que o técnico preencheu uma determinada receita, a sacola é passada para o farmacêutico, que
Página 51
1.7 Exercícios adicionais 29
verifica novamente se a receita foi preenchida corretamente. Após esta verificação de qualidade, o
O farmacêutico fecha o saco e o coloca na área de coleta. Quando um cliente chega para buscar
uma receita, um técnico pega a receita e pede ao cliente o pagamento em
caso os medicamentos na receita não sejam (totalmente) cobertos pelo seguro do cliente.
Com relação ao processo acima, considere as seguintes questões:
1. Que tipo de processo é o acima: ordem para pagamento, aquisição para pagamento ou emissão para
resolução?
5. Tomando a perspectiva do cliente, quais medidas de desempenho podem estar em
anexado a este processo?
6. Que problemas potenciais você prevê que esse processo possa ter? Que informação
você precisaria coletar para analisar essas questões?
7. Quais possíveis mudanças você acha que poderiam ser feitas neste processo para
resolver os problemas acima?
Agradecimento Este exercício é parcialmente inspirado por Andrew McAfee: “Farmácia

Melhoria de serviço no CVS ( A ) ”. Harvard Business Publishing, 2005 .
Exercício 1.7 Considere o seguinte processo em uma empresa com cerca de 800 funcionários
ees.
Uma solicitação de compra é iniciada quando um funcionário da empresa preenche e assina um formulário
no papel. A solicitação de compra inclui informações sobre o bem a ser adquirido, o
quantidade, a data de entrega desejada, o custo aproximado. O funcionário também pode nomear
um fornecedor específico. Os funcionários costumam solicitar orçamentos de fornecedores para obter o necessário
em formação. O preenchimento de todo o formulário pode levar alguns dias, como o solicitante costuma fazer
não tem os dados necessários. A cotação está anexada à solicitação de compra. Esta completada
a solicitação é assinada por dois supervisores. Um supervisor deve fornecer uma aprovação financeira ,
enquanto o outro supervisor tem que aprovar a necessidade da compra e sua conformidade
com a política da empresa (por exemplo, um software solicitado faz parte do padrão operacional
meio Ambiente?). A coleta das assinaturas dos dois supervisores leva em média cinco
dias. Em caso de urgência, o colaborador pode entregar em mãos o formulário, caso contrário é distribuído via
correio interno. Uma solicitação de compra rejeitada é devolvida ao funcionário. Alguns funcionários
faça algumas pequenas modificações e tente em uma segunda tentativa outros supervisores, a fim de
obter a aprovação.
Assim que uma solicitação de compra é aprovada, ela é devolvida ao funcionário que iniciou a compra
requisição de perseguição. O funcionário então encaminha o formulário ao Departamento de Compras.
Muitos funcionários fazem uma cópia do formulário para seu próprio registro, caso o formulário se perca.
O Departamento de compras central verifica se a solicitação de compra está completa e
devolve-o ao funcionário se estiver incompleto.
Com base nas cotações em anexo e outras informações, o Departamento de compras insere o ap-
solicitação de compra comprovada no Enterprise System da empresa. Se o funcionário não
nomeado quaisquer fornecedores, um funcionário do Departamento de compras selecionará um com base em
nas cotações anexadas à requisição de compra, ou com base na lista de fornecedores (também chamada
Master Vendor List ) disponível no Enterprise System da empresa.
Às vezes, o orçamento inicial anexado à solicitação expirou nesse meio tempo. Nisso
caso, a cotação atualizada é solicitada ao fornecedor correspondente. Em outros casos, o fornecedor
Página 52
quem enviou a cotação não é registrado no Enterprise System da empresa. Nesse caso,
o departamento de compras deve dar preferência a outros fornecedores que estejam registrados em
o Enterprise System. Se nenhum desses fornecedores estiver disponível ou se os fornecedores registrados oferecerem
preços mais altos do que o da cotação enviada, o Departamento de compras pode adicionar o
novo fornecedor no Enterprise System.
Quando um fornecedor é selecionado, um pedido de compra é gerado automaticamente pela empresa
Sistema. Em seguida, um fax é gerado e enviado ao fornecedor. Uma cópia do pedido de compra é
enviado para o Gabinete de Contas a Pagar, que faz parte do Departamento Financeiro, que utiliza um
sistema contábil que não está integrado ao Enterprise System.
As mercadorias são sempre entregues no Departamento de Recebimento de Mercadorias. Quando um bem é recebido,
um funcionário deste Departamento seleciona o pedido de compra correspondente no Enterprise Sys-
tem. O balconista verifica a quantidade e qualidade e (no caso positivo) gera um documento
denominado formulário de recebimento de mercadorias do pedido de compra armazenado no Enterprise System. o
as mercadorias são então encaminhadas para o empregado que iniciou a requisição de compra. Uma impressão-
fora do formulário de recebimento de mercadorias é enviado para o Escritório de Contas a Pagar. Se houver algum problema
com a mercadoria, ela é devolvida ao fornecedor e uma nota em papel é enviada ao Comprador
Departamento e ao Gabinete de Contas a Pagar.
O fornecedor eventualmente envia a fatura diretamente para o Escritório de Contas a Pagar. Um funcionário
neste escritório compara o pedido de compra, o recebimento de mercadorias e a fatura - uma tarefa que é
geralmente chamado de “combinação de três vias”. A correspondência de três vias pode consumir muito tempo. E se
há alguma discrepância, pois deve ser investigada, se foi um erro do fornecedor ou
um erro de entrada de dados. A duração do processo de pagamento infelizmente demora muito
desde que expire o desconto para pagamento em determinado período.
Uma transferência bancária é finalmente acionada e um aviso de pagamento é enviado ao fornecedor. Alguns vendedores
indicar explicitamente em sua fatura o número da conta bancária para onde deseja a transferência
ocorrer. Pode acontecer que o número da conta bancária e o nome indicado na fatura
difere daquele registrado no banco de dados do fornecedor. Às vezes, os pagamentos voltam, em
caso em que o vendedor é contatado por telefone, e-mail ou correio. Se os novos dados bancários forem
dado, a transferência é tentada novamente. Se o problema ainda não for resolvido, o Contas a Pagar
O escritório deve entrar em contato novamente com o fornecedor para rastrear a causa do pagamento devolvido.
1. Que tipo de processo é o acima: ordem para pagamento, aquisição para pagamento ou emissão para
resolução?
2. Quem são os atores neste processo? Quem é / são o (s) cliente (s)?
5. Tomando a perspectiva do cliente, quais medidas de desempenho podem estar em
anexado a este processo?
6. Que problemas potenciais você prevê que esse processo possa ter? Que informação
você precisaria coletar para analisar essas questões?
7. Quais possíveis mudanças você acha que poderiam ser feitas neste processo para
resolver os problemas acima?
Agradecimento Este exercício é adaptado de um exercício semelhante desenvolvido por

Michael Rosemann, Universidade de Tecnologia de Queensland.
Exercício 1.8 Considere as fases do ciclo de vida do BPM. Quais dessas fases são
não incluído em um projeto de reengenharia de processos de negócios?
Página 53
1.8 Leitura Adicional 31
1.8 Leitura Adicional
Geary Rummler é considerado um dos primeiros defensores do pensamento de processo como um

abordagem para abordar as deficiências das organizações puramente funcionais. O trabalho dele
no pensamento de processo, desenvolvido durante os anos 1970 e 1980, foi popularizado por um
livro em coautoria com Alan Brache: “Improving Performance: How to Manage the
Espaço em branco no organograma ”[ 80 ]. Um artigo publicado duas décadas depois
por Rummler e Ramias [ 81 ] dá um resumo condensado da metodologia de Rummler
ogia para estruturar organizações em torno de processos.
Dois artigos importantes que popularizaram o pensamento de processo como um conceito de gestão são
aqueles de Hammer [ 26 ] e Davenport e Short [ 11 ] conforme discutido neste capítulo.
Enquanto o trabalho de Rummler lida de forma mais ampla com a estruturação de organizações baseadas
em processos, Hammer, Davenport e Short focam em como redesenhar
processos de negócios para aumentar seu desempenho.
Um tratamento abrangente e consolidado de BPM por um homem de negócios
perspectiva de gestão é fornecida por Paul Harmon em seu livro Business Pro-
cesso Mudança [ 31 ]. O livro de Harmon apresenta a chamada metodologia BPTrends
ogy para BPM. Harmon também é editor do boletim informativo e portal BPTrends
( http://www.bptrends.com ) que apresenta vários artigos e recursos relacionados
para BPM. Uma boa visão geral do campo também é fornecida nos livros de Becker et al. [ 6 ]
e por Rosemann e vom Brocke [ 102 , 103 ].
Conforme mencionado neste capítulo, BPM está relacionado a vários outros campos, incluindo
TQM e Six Sigma. A esse respeito, Elzinga et al. [ 15 ] discutir a relação entre
BPM e TQM, enquanto a aplicação de técnicas Six Sigma no contexto de
BPM é discutido por Harmon [ 31 , Cap. 12], Laguna e Marklund [ 43 , cap. 2]
e Conger [ 8 ].
Página 54
Capítulo 2
Identificação do Processo
As coisas que mais importam nunca devem estar à mercê

das coisas que menos importam.
Johann Wolfgang von Goethe (1749-1832)
A identificação do processo é um conjunto de atividades com o objetivo de definir sistematicamente o conjunto de

processos de negócios de uma empresa e estabelecer critérios claros para priorizá-los.
A saída da identificação do processo é uma arquitetura de processo , que representa o
processos de negócios e suas inter-relações. Uma arquitetura de processo serve como um quadro
trabalho para definir as prioridades e o escopo da modelagem e redesenho de processos
projetos.
Neste capítulo, apresentamos um método para identificação de processos que se baseia em
duas fases: designação e avaliação. A fase de designação está relacionada com
a definição de uma lista inicial de processos. A fase de avaliação considera adequada
critérios para definir as prioridades desses processos. Depois disso, discutimos e ilustramos
um método para transformar a saída desse método em uma arquitetura de processo.
2.1 Focando em processos-chave
Poucas organizações têm os recursos necessários para modelar todos os seus processos em detalhes,
para analisar rigorosamente e redesenhar cada um deles, para implantar tecnologia de automação
a fim de apoiar cada um desses processos e, finalmente, monitorar continuamente
o desempenho de todos os processos em detalhes. Mesmo se esses recursos estivessem disponíveis,
não seria econômico gastá-los dessa maneira. O BPM não é gratuito. Como qualquer um
outro investimento, os investimentos em BPM têm que pagar. Portanto, é imperativo em cada
organização engajada em BPM para focar a atenção em um subconjunto de processos.
Alguns processos precisam receber prioridade porque são de importância estratégica
para a sobrevivência de uma organização. Outros processos podem mostrar problemas marcantes, que
deve ser resolvido para o bem de todas as partes interessadas envolvidas. Em outras palavras, o
processos que uma organização deve focar são encontrados em áreas onde há
grande valor criado ou problemas significativos presentes (ou ambos). Para fazer coisas
mais complexo, o subconjunto de processos de alta prioridade em uma organização está sujeito a
a dinâmica do tempo. Alguns processos podem ser problemáticos em um ponto, mas uma vez

Página 55
34 2 Identificação do Processo
os problemas foram identificados e resolvidos por um programa de melhoria de processos,

uma organização pode fazer apenas inspeções periódicas por algum tempo. Por exemplo,
uma seguradora que sofre de altos níveis de insatisfação do cliente irá
naturalmente tendem a se concentrar em seus processos orientados para o cliente, digamos, seu tratamento de reclamações
processo. Uma vez que este processo tenha melhorado e a satisfação do cliente esteja novamente dentro
a faixa desejada, a ênfase pode passar para seus processos de avaliação de risco, que
são importantes para a viabilidade e competitividade da empresa a longo prazo.
Além da dinâmica do tempo, quais podem ser processos que são de natureza estratégica
importância para uma organização em algum ponto pode se tornar menos importante com o passar do tempo.
As demandas do mercado podem mudar e novos regulamentos ou a introdução de novos produtos
utos podem limitar o que antes era uma atividade lucrativa de negócios. Por exemplo, a chegada
de novos concorrentes oferecendo apólices de seguro com desconto por meio de canais baseados na Web
nels pode levar uma empresa estabelecida a redesenhar seus processos de vendas de seguros para
torná-los mais enxutos, rápidos e acessíveis na web.
Para abordar o imperativo de se concentrar em um subconjunto de processos-chave, o homem
equipe de gestão, analistas de processos e proprietários de processos precisam ter respostas para as
Seguem duas questões: (i) quais processos são executados na organização? e
(ii) em quais deve a organização focar? Em outras palavras, uma organização en-
medido em iniciativas de BPM precisa manter um mapa de seus processos, bem como critérios claros
para determinar quais processos têm maior prioridade. Vimos no cap. 1 que
há uma série de partes interessadas envolvidas na gestão e execução de um negócio
processo de ness. Geralmente, apenas alguns desses interessados têm uma visão geral completa de
todos os processos de negócios em uma organização. No entanto, é precisamente esse insight que é
necessário para identificar o subconjunto de processos que precisam ser gerenciados de perto
ou melhorado. Capturar esse conhecimento e mantê-lo atualizado é precisamente o
objetivo da identificação do processo.
Mais especificamente, a identificação do processo está preocupada com duas fases sucessivas:
designação e avaliação. O objetivo da fase de designação é obter uma
compreensão dos processos em que uma organização está envolvida, bem como suas inter-
relacionamentos. A fase de avaliação , com base no entendimento que se estabelece
na fase anterior, pretende desenvolver uma priorização entre estes para o processo
atividades de gestão (modelagem, redesenho, automação, monitoramento, etc.). Observe que
nenhuma dessas fases está preocupada com o desenvolvimento do modo de processo detalhado
els. As principais atividades que estão envolvidas na identificação do processo que iremos
descrever seguir de perto aqueles identificados por Davenport em [ 10 ].
2.1.1 A Fase de Designação
Se uma organização está no início de se tornar uma organização centrada em processos,

a primeira tarefa difícil que enfrenta é chegar a uma enumeração significativa de seus
processos existentes. Uma dificuldade aqui surge da natureza hierárquica dos negócios
processos de ness: diferentes critérios podem ser considerados para determinar quais cadeias de
operações podem ser vistas como formando um processo de negócios independente e quais
Página 56
2.1 Focando em processos-chave 35
são vistos como parte de outro processo. Existem vários pontos de vista sobre como categorizar
rize processos de negócio (veja o quadro “Categorias de processos de acordo com Porter”).
Alguns deles apoiam a ideia de que existem realmente poucos processos em qualquer
organização. Por exemplo, alguns pesquisadores argumentaram para a existência de apenas
dois processos: (1) gerenciamento da linha de produtos e (2) gerenciamento do ciclo de pedidos.
Outros identificam três processos principais: desenvolvimento de novos produtos, entrega de produtos
serviços aos clientes e gerenciamento de relacionamento com os clientes.
CATEGORIAS DE PROCESSOS DE ACORDO COM PORTER

Diferentes categorizações para processos de negócios foram propostas. 1
dos mais influentes é o modelo da Cadeia de Valor de Michael Porter. É distin-
admite duas categorias de processos: processos centrais (chamados de atividades primárias)
e processos de suporte (atividades de suporte). Os processos centrais cobrem a essência

criação de valor social de uma empresa, ou seja, a produção de bens e serviços
vícios pelos quais os clientes pagam. Porter menciona logística de entrada, operações,
logística de saída, marketing e vendas e serviços. Processos de suporte en-
capaz de executar esses processos centrais. Porter lista infraestrutura, humana
recursos, desenvolvimento de tecnologia e aquisições como tal
cesses. Como uma terceira categoria, outros autores estendem este conjunto de duas categorias
com processos de gestão. Por exemplo, o processo periódico para avaliar o
A força dos concorrentes é esse processo de gerenciamento. A distinção do núcleo,
processos de suporte e gestão é de importância estratégica para uma empresa.
Portanto, se tal distinção for explicitada, por exemplo, na fase do processo
identificação ou ao criar uma arquitetura de processo, é provável que seja um
tópico muito disputado.
A questão é se uma visão excessivamente granulada dos processos, sem

qualquer subdivisão posterior , é útil para uma organização que se esforça para se tornar
centrado. Lembre-se de que a ideia de gerenciamento de processos é gerenciar ativamente
processos de negócios na busca da satisfação de seus clientes específicos. Se alguém selecionar
processos de negócios sejam entidades tão grandes, então o resultado pode ser que eles não podem
ser facilmente gerenciados separadamente, tanto em termos de escopo quanto de velocidade de ação. Considerar,
por exemplo, o quão difícil seria modelar ou redesenhar um processo quando ele cobre
metade de todas as operações dentro de uma organização. Um modelo realista de tal negócio
processo de ness levaria muito tempo para se desenvolver e poderia se tornar extremamente
complexo. Além disso, redesenhar um processo tão grande seria uma tarefa demorada
justo, quanto mais a implementação de tal redesenho. Dependendo da situação, um
organização pode não ter esse tempo.
A principal conclusão disso é que o número de processos que são identificados
na fase de designação deve representar uma compensação entre impacto e gestão
habilidade . Quanto menor for o número de processos que se deseja identificar, maior
seu escopo individual é. Em outras palavras, se apenas um pequeno número de processos é
identificados, então cada um deles cobrirá inúmeras operações. A principal vantagem
Página 57
de um grande escopo de processo é que potencialmente aumenta o impacto que se pode ter com
gerenciando ativamente tal processo. Quanto mais operações são consideradas parte de
um processo, mais fácil se tornará, por exemplo, identificar oportunidades de eficiência
ganhos eliminando o trabalho redundante.
Por outro lado, um grande escopo de um processo de negócios traz consigo uma gama de
questões que tornam mais difícil gerenciá- lo como um processo:
• o envolvimento de um grande número de funcionários tornará a comunicação eficaz

entre eles problemáticos
• se tornará mais difícil manter os modelos de um grande processo atualizados e
• projetos de melhoria relacionados a um grande processo são mais complexos
Para equilibrar as vantagens e desvantagens de um amplo escopo de processo, Davenport

sugeriu que pode ser útil identificar processos amplos e restritos .
Processos amplos são identificados nas áreas onde uma organização sente que é im-
importante para revisar completamente as operações existentes em algum ponto, por exemplo
por causa de forças competitivas ferozes. Imagine que uma organização possa ter encontrado
que seus custos de aquisição são excessivamente altos em comparação com seus concorrentes. Eles selecionam
aquisição como um processo amplo, que abrange todos os serviços e produtos a
empresa adquire de outras partes. Por outro lado, processos estreitos não são direcionados
para grandes revisões; eles precisam ser ativamente monitorados e estão sujeitos a con
ajuste fino e atualização contínua. Um processo estreito pode ser, por exemplo, como o
mesma empresa trata de sugestões de melhorias de seus próprios funcionários.
Exercício 2.1 Explique como funciona a compensação entre impacto e capacidade de gerenciamento
fora para processos amplos e estreitos, respectivamente.
Qualquer enumeração de processos de negócios deve se esforçar para uma descrição razoavelmente detalhada
resultado, que precisa estar alinhado com os objetivos específicos da organização de
gestão de processos. Para a maioria das organizações, como regra prática, isso se resumirá
a uma dúzia a algumas dezenas de processos de negócios. Muito grande e diversificado
as organizações podem se sair melhor com a identificação de algumas centenas de processos.
Para ilustrar isso: dentro de uma empresa de investimento multinacional, que emprega perto de
3.000 funcionários e possui ativos na faixa de € 300 bilhões, 120 negócios diferentes
processos foram identificados. Para cada um desses processos de negócios, um proprietário de processo
é designado, quem supervisiona o desempenho do processo e monitora o alcance
de seus objetivos em termos de satisfação do cliente, lucratividade e prestação de contas
habilidade. Modelos de processos detalhados são mantidos atualizados, tanto como um meio de documentação
ing mudanças planejadas para qualquer processo e para satisfazer os requisitos de finanças
autoridades. Em contraste, para uma pequena clínica médica na Holanda, que em-
estratagemas médicos especialistas, enfermeiras e equipe administrativa, 10 tratamentos diferentes
processos foram identificados. Alguns deles foram mapeados na forma de
modelos de processo e agora estão em processo de automatização com um
sistema de gerenciamento de processos. Para todos os outros processos, é suficiente estar ciente do
opções de tratamento distintas que podem oferecer a diferentes categorias de pacientes.
Página 58
Exercício 2.2 Quais são os impulsionadores potenciais para a empresa de investimento descrita para
identificar um grande número de processos?
Além de uma visão bastante detalhada sobre quais processos de negócios existem, um sub
posição deve ser desenvolvida sobre as relações entre os vários processos. No
uma situação em que as organizações definem processos estreitos e amplos, para evitar
confusão, é importante mapear como processos estreitos se relacionam com processos mais amplos.
Um amplo processo como gerenciamento de pedidos, por exemplo, pode estar relacionado a mais
processos estritamente definidos de reserva, cobrança, remessa e entrega de pedidos. Tudo de
estes podem ser considerados subprocessos do gerenciamento de pedidos. Podemos chamar isso de ex-
ampla de relações hierárquicas entre processos. Os processos também podem estar relacionados a
um ao outro de forma diferente. O faturamento, no exemplo que acabamos de usar, é um processo upstream
em comparação com o envio: para o mesmo pedido, a fatura é enviada geralmente antes do
mercadorias derivadas são enviadas. Outra forma de expressar essa relação é, claro, que
o envio pode ser considerado um processo posterior em comparação ao faturamento. este
ilustra como os processos podem ser relacionados sequencialmente .
Exercício 2.3 Discuta até que ponto o gerenciamento de pedidos pode estar relacionado sequencialmente
para reserva, cobrança, remessa e entrega.
Na maioria das vezes, o insight sobre as relações entre os processos pode ser inferior a
estritamente exato. O objetivo mais importante de capturar relações de dependência é ganhar
uma compreensão de como o desempenho de um processo está relacionado ao de outro. E se
seria, por exemplo, redesenhar um processo existente, é útil entender qual
processos dependem dos resultados de tal processo. Esses processos downstream
pode precisar estar preparado para receber informações ou mercadorias em outra frequência ou
forma do que antes e medidas devem ser tomadas para evitar quaisquer interrupções.
Exercício 2.4 Neste ponto, discutimos as relações hierárquicas e sequenciais entre

entre os processos de negócios. Você pode pensar em outros tipos de relação que são úteis para
distinguir entre processos? Como uma dica, você pode querer pensar sobre o propósito
de identificar as relações entre os processos de negócios.
Embora a designação de processos de negócios e suas inter-relações seja sub-

jeto a diferentes escolhas e preferências de design, algumas orientações gerais estão disponíveis.
Em primeiro lugar, vários chamados modelos de referência para identificação de processos de negócios
existir. Estes são desenvolvidos por uma série de consórcios da indústria, associações sem fins lucrativos,
programas de pesquisa governamentais e acadêmicos. Os exemplos mais conhecidos são os In-
formação Biblioteca de Infraestrutura de Tecnologia (ITIL), as Operações da Cadeia de Suprimentos
Modelo de Referência (SCOR) pelo Conselho da Cadeia de Suprimentos, a Classificação de Processo
Framework (PCF) pelo American Productivity and Quality Center (APQC), o
Modelo de Referência de Valor (VRM) pelo Grupo da Cadeia de Valor, e o Desempenho
Framework de Rummler – Brache. Os modelos de referência padronizam o que pode ser visto como
processos diferentes, com características únicas e entregando produtos diferenciados
utos e como seu desempenho pode ser medido. Seu maior valor está na identidade
identificação de processos regulatórios ou altamente específicos da indústria, ou quando o desempenho
Página 59
benchmarking contra pares e concorrentes é a questão que um processo centrado

organização está atrás. Em outros casos, esses modelos de referência ainda podem ser úteis em
exercícios de identificação em forma de lista de verificação. Por exemplo, uma organização pode
usar o PCF do APQC para inventariar os processos na estrutura que eles usam, sinalizar
aqueles que eles não usam e adicionar seus próprios processos exclusivos. Vamos dar uma olhada mais de perto
no PCF na Sect. 2.2 .
Um segundo fluxo de suporte está disponível na forma de abordagens de design específicas
para desenvolver uma chamada arquitetura de processo . Uma arquitetura de processo é uma organização
visão geral dos processos que existem dentro de um contexto organizacional, que muitas vezes é
acompanhados de orientações sobre como devem ser organizados. Abordagens de design
para arquiteturas de processos de negócios usam uma certa lógica para chegar a uma identificação de
processos de negócios. Na seção 2.2 , entraremos em mais detalhes com relação a um
abordagem de design.
Por fim, o que vale a pena notar com relação à fase de designação é que
os processos mudam com o tempo, deliberadamente ou não. Isso naturalmente implica que o processo
a identificação é de natureza contínua. Para evitar a situação em que alguém se torna
atolado na fase de identificação do processo, a atividade deve ser considerada
ered como um esforço exploratório e iterativo. Quando uma certa visão geral estável é
criado pode muito bem ser utilizável por um período de dois a três anos.
2.1.2 A fase de avaliação
Como afirmado antes, nem todos os processos são igualmente importantes e nem todos os processos podem
recebem a mesma quantidade de atenção. A gestão de processos envolve compromisso,
propriedade, investimento em melhoria de desempenho e otimização. Portanto,
processos que criam perda ou demanda de risco para consolidação, descomissionamento ou
eliminação total. Vários critérios foram propostos para orientar essa avaliação.
Os mais comumente usados são os seguintes.
Importância Este critério se preocupa em avaliar a relevância estratégica de

cada processo. O objetivo é descobrir quais processos têm maior impacto sobre
os objetivos estratégicos da empresa, por exemplo, considerando lucratividade, continuidade,
ou contribuição para uma causa pública. Faz sentido selecionar esses processos para
gestão de processos ativos que se relacionam mais diretamente com os objetivos estratégicos de um
organização.
Disfunção Este critério visa fazer um julgamento de alto nível da "saúde"
de cada processo. A questão aqui é determinar quais processos estão no
problema mais profundo. Esses processos são os que podem lucrar mais com o processo
iniciativas centradas.
Viabilidade Para cada processo, deve-se determinar o quão suscetíveis eles são a
iniciativas de gestão de processos, sejam incidentais ou contínuas. A maioria
notavelmente, a cultura e a política envolvidas em um determinado processo podem ser obstáculos
para obter resultados de tais iniciativas. Em geral, a gestão de processos deve
concentre-se nos processos em que é razoável esperar benefícios.
Página 60
Observe que todos esses critérios pressupõem que haja certas informações disponíveis.
Por exemplo, para avaliar a importância estratégica de um processo, é da maior importância
importância que uma organização tenha uma ideia de seu curso estratégico. É suficiente se
tais considerações estratégicas são definidas em um nível muito abstrato. Neste ponto, para
exemplo, muitas organizações veem o benefício estratégico de ser capaz de mudar o
tipo de produtos que fornece às demandas dos clientes. Zara, o pano espanhol
varejista, é um excelente exemplo de uma organização que segue um método de medir e reagir
estratégia. Ele envia agentes para shoppings para ver o que as pessoas já usam para
determinar os estilos, tecidos e cores dos produtos que deseja entregar. Tal um
organização pode olhar com interesse específico para os negócios de produção e logística
processos que são mais capazes de apoiar esta estratégia.
Da mesma forma, para determinar a disfunção potencial de um processo de negócios, uma organização
nização precisa de informações. Aqui, encontramos um problema do tipo “ovo e galinha”.
Muitas organizações que não trabalham de forma centrada no processo não têm um
uma boa visão quantitativa do desempenho de seus processos individuais. 1
das iniciativas centradas no processo que tal organização pode buscar
exatamente colocar os sistemas e procedimentos em vigor para coletar os dados que são
necessários para uma avaliação de desempenho. Nesses casos, uma organização precisará
usar abordagens mais qualitativas para determinar quais de seus processos não funcionam
formar bem, por exemplo, dependendo das impressões que a gestão ou processo
participantes têm sobre a eficiência ou eficácia dos vários processos. A-
outra abordagem seria confiar nas avaliações do cliente, coletadas por pesquisas
ou entregue espontaneamente na forma de reclamações.
O critério de viabilidade também requer alguma atenção. Tornou-se comum
prática para as organizações passarem por um fluxo contínuo de programas para melhorar
seu desempenho em uma dimensão ou outra. Considere a Philips, a multinacional
empresa de eletrônicos. Ele passou por uma série intermitente de programas de melhoria
gramas desde os anos 1980 para aumentar seu desempenho. O mesmo fenômeno agora pode
ser observada em muitas organizações de telecomunicações e serviços públicos. Desde o
a rentabilidade dos produtos muda drasticamente de um ano para o outro, isso requer
mudanças contínuas em portfólios de produtos e prioridades de mercado. Nestes tipos de
contexto volátil, pode acontecer que gerentes e participantes do processo fiquem cansados
ou totalmente hostil a novas iniciativas. Este tipo de situação não é uma boa
ponto de partida para iniciativas de gerenciamento de processos. Afinal, como outras organizações
medidas, tais iniciativas também dependem da cooperação e boas intenções de
diretamente envolvidos. Embora não tratemos do assunto de gerenciamento de mudanças
em muitos detalhes neste livro, é importante perceber que o sentido político
sitividades dentro de uma organização podem ter um efeito na taxa de sucesso do processo
esforços de gestão também.
AVALIAÇÃO DA MATURIDADE BPM

Uma abordagem mais detalhada para olhar para a fase de avaliação é baseada em matu-
ridade. A avaliação de maturidade de BPM é um corpo de técnicas para determinar o nível
Página 61
de pensamento sistemático de processo em uma organização. Uma avaliação de maturidade de BPM

mento envolve essencialmente dois aspectos. O primeiro aspecto é avaliar o que
até que ponto uma determinada organização cobre a gama de processos que são idealmente ex-
protegido por isso. O segundo aspecto é avaliar em que grau esses processos
são documentados e suportados. Portanto, uma avaliação de maturidade visa
estabelecer uma linha de base para discutir a integridade e a qualidade do
conjunto de processos executados em uma organização.
Uma das estruturas mais amplamente utilizadas para avaliação da maturidade é o Ca-
Estrutura integrada do modelo de maturidade (CMMI). Esta estrutura dis-
distingue várias das chamadas áreas de processo. Várias dessas áreas são específicas
específico para um domínio particular nas várias especificações CMMI. O domínio-
as áreas independentes incluem: gestão de processos, gestão de projetos e
Apoio, suporte.
A cobertura das áreas de processo e o grau de seu suporte fornecem o
base para uma avaliação de maturidade em termos dos cinco níveis de maturidade do CMMI:
Nível 1 (inicial): nesta fase inicial, a organização executa seus processos em

uma forma ad-hoc, sem qualquer definição clara desses processos. Ao controle
está desaparecido.
Nível 2 (gerenciado): nesta fase, o planejamento do projeto junto com o projeto mon-
itoring e controle foram colocados em prática. Medição e análise
é estabelecida, bem como a garantia de qualidade do processo e do produto.
Nível 3 (Definido): Organizações nesta fase adotaram um foco em
cesses. Definições de processos estão disponíveis e o treinamento organizacional é pro
oferecido para permitir que as partes interessadas em toda a organização se envolvam em
documentação e análise de processos. Projeto integrado e gerenciamento de risco
Estão no lugar. A análise e resolução de decisões também estão disponíveis.
Nível 4 (Gerenciado Quantitativamente): Nesta fase, o processo organizacional
o desempenho é monitorado. A gestão do projeto é realizada usando quanti-
técnicas representativas.
Nível 5 (Otimizando): Neste estágio de maturidade, a organização estabeleceu
cumpriu a gestão de desempenho organizacional acompanhada de
análise e resolução.
A avaliação de uma organização em termos desses níveis leva a um chamado

avaliação . As avaliações podem ser realizadas internamente dentro de uma organização (também
chamadas de autoavaliação) ou por uma organização externa com experiência em matu-
avaliação da ridade. Diferentes tipos de avaliação são distinguidos e definidos em
o Método de Avaliação CMMI Padrão para Melhoria de Processos (SCAMPI).
Pergunta Dados todos os critérios discutidos, faz uma avaliação da importância,

disfuncional e viabilidade sempre me apontam os mesmos processos para ativamente
gerir?
Página 62
Não, não há garantia disso. Pode muito bem ser que uma importância estratégica
processo tant também é o processo que pode ser considerado o mais difícil de
gerenciar, simplesmente porque muitos esforços de melhoria anteriores já falharam.
Uma organização pode não ter escolha em tal situação. Se um processo estratégico pode-
não ser melhorado, isso pode acabar sendo fatal para a organização como um todo. Pensar
de uma situação em que o processo de criação de novos produtos cria muita turbulência
e conflitos dentro de uma organização: Se os problemas não puderem ser resolvidos, a empresa
pode parar de funcionar rapidamente. Em outras configurações, pode ser mais importante ganhar
credibilidade com as atividades de gerenciamento de processos primeiro. Isso pode ser feito por
focando em processos problemáticos de importância estratégica mais branda, mas onde
é um grande desejo de mudar. Se for bem-sucedido, um projeto de melhoria em tal lugar
pode dar credibilidade à abordagem de gerenciamento de processos. Estas não são escolhas
que pode ser facilmente prescrito sem levar em consideração o contexto específico. o
vários resultados da avaliação devem ser equilibrados para chegar a uma lista desses processos
que deve receber prioridade sobre os outros.
Pergunta Todos os processos disfuncionais, de importância estratégica e

viável de gerenciar estar sujeito a iniciativas de gerenciamento de processos?
A resposta geral a esta pergunta é que para a maioria das organizações isso não é viável.
ble. Lembre-se novamente de que o gerenciamento de processos consome recursos. Mesmo quando há
um incentivo claro para, por exemplo, redesenhar vários processos de negócios existentes, a maioria
as organizações não têm recursos suficientes - pessoas, fundos e tempo - para fazer isso. Apenas o
as maiores organizações são capazes de apoiar mais do que um punhado de melhorias de processo -
projetos de desenvolvimento ao mesmo tempo. Um bom exemplo é a IBM, uma organização conhecida
ter projetos de melhoria de processos em andamento dentro de todos os seus programas de negócios existentes
cesses em uma base contínua. Outra ressalva de realizar muitas
esforços de gerenciamento de processos é que eles criarão complexidade de coordenação. Ré-
membro que os processos podem estar ligados uns aos outros em vários aspectos, de modo que
as medidas tomadas para um processo devem ser sincronizadas com as tomadas para outro.
Como Davenport [ 10 ] descreve:
A maioria das empresas opta por abordar um pequeno conjunto de processos de negócios a fim de ganhar experiência
riência com iniciativas de inovação, e eles concentram seus recursos nas atividades mais críticas
cesses. Cada iniciativa de sucesso se torna um modelo para esforços futuros.
O que está acontecendo em algumas organizações é que esforços generalizados são feitos
para, pelo menos, modelar todos os processos de negócios importantes, atrasando a decisão de tomar
a etapa para esforços de BPM mais avançados (por exemplo, redesenho ou automação de processos). o
ideia é que os modelos de processo são a base de qualquer esforço de BPM em qualquer
caso e que sua existência ajudará a entender melhor onde as melhorias
pode ser ganho. A criação de um modelo de processo leva a uma visão valiosa de como
processo funciona em tudo e pode fornecer uma boa base para pequenas melhorias que podem
ser facilmente implementado. No lado negativo, tal abordagem carrega o risco de que
melhorias são perdidas e as partes interessadas desenvolvem um sentimento de falta de retorno
pelos esforços. Deve ser enfatizado aqui, também, que a modelagem real de negócios
processos não é um elemento do estágio de identificação do processo.
Página 63
Fig. 2.1 Os diferentes níveis

de detalhes em um processo
arquitetura
Nesta seção, descrevemos as fases de designação e avaliação do processo

em um alto nível de discurso. Agora, vamos nos voltar para uma técnica específica para sugerir
com uma arquitetura de design de processo.
2.2 Projetando uma Arquitetura de Processo
Uma arquitetura de processo é um modelo conceitual que mostra os processos de uma empresa
e torna seus relacionamentos explícitos. Normalmente, esses relacionamentos são definidos em
duas direções. Por um lado, os processos podem estar em uma relação consumidor-produtor
navio. Isso significa que um processo fornece uma saída que o outro processo toma como
uma entrada. Na primeira parte do livro, distinguimos o processo de cotação para pedido
e processos de pedido para pagamento. A saída do primeiro (o pedido) é a entrada para o
o segundo. Observe que este é o mesmo tipo de ordem que o upstream-downstream
relação que distinguimos anteriormente. Além da relação consumidor-produtor, uma
A arquitetura de processamento define diferentes níveis de detalhe. Isso é ilustrado como uma pirâmide em
Fig. 2.1 .
A parte da arquitetura do processo que cobre os processos no nível um é
conhecido como modelo de paisagem de processo ou simplesmente a arquitetura de processo para nível
1. Mostra os principais processos em um nível muito abstrato. Cada um dos elementos de
o modelo da paisagem do processo aponta para processos de negócios mais concretos no nível
dois. Este nível dois mostra os processos em um grau mais fino de granularidade, mas ainda em um
forma bastante abstrata. Cada elemento no nível dois aponta mais para um modelo de processo em
nível três. Os modelos de processo neste terceiro nível mostram os detalhes dos processos
incluindo fluxo de controle, entradas e saídas de dados e atribuição de participantes, como
discutiremos nos capítulos de modelagem.
O desafio mais importante para a definição de uma arquitetura de processo é o
definição do modelo de paisagem de processos, ou seja, capturar os processos no nível um.
A arquitetura do processo no nível um deve ser compreensível em primeiro lugar,
mostrando não muito mais do que aproximadamente 20 categorias de processos de negócios de
Página 64
2.2 Projetando uma Arquitetura de Processo 43
uma empresa. Além disso, deve ser suficientemente completo para que todos os funcionários
da empresa pode se relacionar com ele com seu trabalho diário, e aceitá-lo como um consensual
descrição da empresa. Portanto, é importante definir o arquivo do processo
tectura de forma sistemática, com foco específico na derivação do processo
modelo de paisagem.
Várias perspectivas e abordagens foram definidas para a arquitetura de processos
definição. Aqui, nos concentraremos em uma abordagem desenvolvida por Dijkman [ 14 ].
Esta abordagem específica leva a uma arquitetura de processo no nível um ao longo de dois di-
mensões: tipo de caso e função do negócio. A dimensão do tipo de caso classifica o
tipos de casos que são tratados por uma organização. Um caso é algo que um ou-
ganização (ou parte dela) alças. Normalmente, um caso é um produto ou serviço que é
entregue por uma organização a seus clientes, como um seguro (um serviço) ou um
brinquedo (um produto). Observe que, dependendo da parte da organização para a qual o
arquitetura de processo é projetada, os casos podem representar produtos ou serviços que
são entregues aos clientes da organização. No entanto, eles também podem se referir a
produtos ou serviços que são fornecidos por um departamento da organização a um
outro departamento. Por exemplo, pense em criar um local de trabalho para um novo funcionário
pelo departamento de instalações.
Os casos podem ser classificados deliberadamente, usando qualquer número de propriedades. Para a prova-
ple, uma seguradora lida com seguros, que podem ser classificados de acordo com
tipo de produto (seguro residencial, seguro automóvel e seguro de vida), mas também de acordo
ao canal que a empresa utiliza para interagir com seus clientes (telefone, of-
fice e internet). Uma combinação dessas propriedades também pode ser usada para classificar
casos. No exemplo do seguro, os casos seriam então classificados usando ambos os produtos
tipo e canal (seguro residencial via telefone, seguro residencial via escritório, carro
seguro por telefone, etc.).
A dimensão função classifica as funções de uma organização. Uma função é,
em poucas palavras, algo que uma organização faz. Normalmente, uma decomposição hierárquica
posição das funções pode ser feita: Uma função consiste em subfunções, que, em
por sua vez, consistem em sub-subfunções, etc. Por exemplo, uma empresa de produção realiza
funções de compra, produção e vendas. A função de compras, por sua vez, pode
ser decomposto em funções de seleção de fornecedor e aquisição operacional. FIG-
ure 2.2 mostra um exemplo de uma arquitetura de processo de negócios para uma autoridade portuária,
que A
usa o tipomostra
figura de caso e as
uma dimensões de
organização da processos
função para
porestruturar seusna
tipo de caso processos.
di-
mension e por função de negócio na dimensão vertical. A dimensão da função
mostra o que a organização faz: manuseio pré-chegada de navios de mar, o que envolve
notificando as partes relevantes sobre o tempo estimado de chegada do navio e o que
o navio está carregando; lidar com a chegada real do navio, que envolve guiar
o navio para sua doca; etc. A dimensão do tipo de caso mostra os tipos de casos que o
organização trata: navios, caminhões, trens e transporte terrestre por barcaças.
Existem três processos que são criados para lidar com esses tipos de casos, usando o
funções diferentes. Esses três são mostrados cobrindo as várias funções e casos
tipos. O processo de planejamento de entrada é usado para lidar com a chegada de navios antes da chegada.
O processo de manuseio de entrada é usado para lidar com a chegada e o transbordo do mar
Página 65
Fig. 2.2 Uma arquitetura de processo para uma autoridade portuária
navios e o processo de manuseio de saída é usado para lidar com o transbordo e

partida de caminhões, trens e barcaças.
Para chegar a uma arquitetura de processo de negócios em um sentido semelhante ao que descrevemos
aqui, propomos uma abordagem que consiste nas quatro etapas a seguir:
1. identificar os tipos de caso

2. identificar funções para tipos de caso
3. construir uma ou mais matrizes de caso / função, e
4. identificar processos
Discutiremos agora essas etapas com mais detalhes.
2.2.1 Identificar Tipos de Casos
Na primeira etapa, uma classificação de tipos de caso é desenvolvida para a organização. este
é feito selecionando as propriedades do caso que serão usadas para a classificação. o
objetivo principal para identificar diferentes classes nesta dimensão do processo de arquivamento
tectura é determinar as diferentes maneiras em que processos (semelhantes) são tratados
na organização. É importante ter isso em mente, pois as únicas propriedades
que devem ser incluídos na classificação são aqueles que conduzem a diferentes organizações
comportamento zacional. Propriedades que podem distinguir casos, mas não levam a diferentes
comportamento não deve ser incluído. Por exemplo, uma papelaria vende muitos tipos diferentes
tipos de produto. Porém, vende todos esses tipos de produtos da mesma forma.
Portanto, 'tipo de produto' não é uma dimensão útil ao classificar os casos que
são administrados por uma loja de varejo. Uma seguradora também vende diferentes tipos de
produto (seguros) e, ao contrário da loja de varejo, os produtos que ela vende são
tratada de forma diferente. Por exemplo, para um seguro de vida, uma declaração de saúde deve ser
Página 66
preenchido, mas para um seguro de carro isso não é um requisito. Portanto, o 'produto
tipo 'é de fato uma propriedade útil para classificar os tipos de casos que são tratados por
uma seguradora; este não é o caso para classificar os tipos de casos que são
manuseado por uma loja de varejo.
Uma classificação dos tipos de casos que uma organização lida pode ser desenvolvida
oped usando qualquer número de propriedades. No entanto, alguns dos mais comumente usados
propriedades são:
• Tipo de produto: esta propriedade identifica os tipos de produtos que são manipulados por
Uma organização. Eles podem ser decompostos hierarquicamente. Por exemplo, um seguro
uma empresa de negócios lida com produtos de seguro de vida e danos. Na classe de dam-
seguros de idade, uma decomposição adicional é possível em seguro de carro e casa
seguro; da mesma forma, dentro da classe de seguro de vida, uma decomposição adicional é
possível em seguro saúde e seguro de acidentes.
• Tipo de serviço: se (uma parte de) uma organização lida com serviços em vez de produtos,
esta propriedade identifica os tipos de serviços que a organização lida, semelhantes
à maneira como o tipo de produto identifica os tipos de resultados tangíveis.
• Canal: esta propriedade representa o canal através do qual a organização
tata seus clientes. Podemos, por exemplo, distinguir: contato face a face (sobre
balcão), telefone ou contato pela Internet.
• Tipo de cliente: esta propriedade representa os tipos de cliente que a organização
zação trata. Uma companhia aérea, por exemplo, pode distinguir passageiros frequentes de
viajantes regulares.
Observe novamente que, embora essas sejam as propriedades mais comumente usadas para dis-
Para distinguir diferentes tipos de caso, certamente existem outras propriedades que podem ser usadas.
Qualquer propriedade que distingue tipos de casos que são tratados de forma diferente pode ser
usava. Por exemplo, se uma organização faz as coisas de forma diferente na América do Norte do que
na Europa, os casos podem ser classificados de acordo com a localização. Outro exemplo: if cases
são tratados de forma diferente, dependendo da experiência necessária para lidar com eles,
eles podem ser classificados de acordo com a especialização.
Além disso, observe novamente que a classificação pode ser desenvolvida usando qualquer número e
combinação de propriedades. Se uma empresa vende seguros na América do Norte
e na Europa e o tratamento de seguros difere nesses continentes por causa da
regulamentos, em seguida, uma classificação de casos de acordo com o tipo de produto e localização
pode ser usado.
Exercício 2.5 Considere o caso de um banco e os critérios de classificação do tipo de produto,

tipo de serviço, canal e tipo de cliente. Até que ponto esses critérios estão relacionados a cada
de outros?
2.2.2 Identificar funções para tipos de caso
Na segunda etapa, é desenvolvida uma classificação das funções de negócios que são
realizada nos diferentes tipos de caso. Esta etapa requer que cada um dos tipos de caso
Página 67
é examinado em detalhes e para cada tipo de caso as funções que podem ser executadas nele
são identificados. Potencialmente, as funções que são desempenhadas em uma organização podem ser
relacionados às classificações existentes que são propostas por modelos de referência. Nós já
mencionou uma série deles. Uma pequena parte do PCF da APQC é mostrada na Tabela 2.1 .
Esses modelos de referência podem servir como um ponto de partida para desenvolver uma classificação de
funções de negócios e podem ser adaptados às necessidades específicas da organização.
Quer esta identificação de funções comece com um modelo de referência ou não,
requer entrevistas com diferentes pessoas na organização. Essas entrevistas servem
para identificar as funções diretamente, ou para verificar em que medida as funções
a partir de um modelo de referência se aplicam à organização. As entrevistas devem ser realizadas
com os funcionários que estão envolvidos nos diferentes casos que a organização han-
dles e com gerentes de produto (e serviço) dos diferentes produtos e serviços
que a organização lida. É, portanto, importante observar que os diferentes
as pessoas envolvidas podem muito bem usar termos diferentes para funções de negócios semelhantes.
Homônimos e sinônimos são problemáticos neste contexto. Por exemplo, o que é
chamada de 'aquisição' em uma parte da organização pode ser chamada de 'pesquisa de mercado' em
outro (sinônimo). Ao mesmo tempo, duas funções chamadas 'implementação' podem
representam diferentes atividades: uma pode representar a implementação de software,
enquanto o outro representa a implementação de novos regulamentos na organização
ção (homônimo). Além de estar ciente dos vários termos que estão sendo usados,
um entendimento complexo das operações de uma organização é importante para classificar
essas questões fora. Frameworks como o PCF da APQC podem ajudar a evitar
questões desde o início.
Além disso, as funções podem ser organizadas de forma diferente. Considere, por exemplo,
Fig. 2.3 . É tirado de um caso do mundo real e mostra partes do decurso funcional
composições de dois departamentos da mesma organização, um na Europa e
um na América do Norte. O departamento europeu distingue entre comprar
e vendas, em que compras e vendas são divididas em funções operacionais.
Essas funções dizem respeito ao fornecimento e ordem de pagamento para compras, por um lado
e marketing e operações de vendas para vendas de outro. O norte americano de-
partment distingue entre sourcing, marketing e tratamento de pedidos. Aqui, ou-
O manuseio envolve atividades de vendas operacionais e de ordem de pagamento (mas não é
decomposto mais).
Claramente, no exemplo desta organização, uma etapa de negociação pode ser necessária
entre as diferentes pessoas envolvidas para unificar as decomposições funcionais entre
suas partes europeias e norte-americanas. Isso é especialmente necessário se a função
a decomposição internacional é mais do que apenas um exercício de modelagem. Também pode representar
propriedades organizacionais reais. No caso ilustrado na Fig. 2.3 , os gerentes
estão em vigor para as diferentes funções nos diferentes níveis de decomposição. No
Europa, um gerente é nomeado para vendas, outro para compras e nível inferior
gerentes de sourcing, order-to-pay, marketing e vendas operacionais. No norte
América, existem gerentes para sourcing, marketing e gerenciamento de pedidos
mento. Portanto, quando as decomposições funcionais dos departamentos precisam
ser harmonizada, a estrutura de gestão também deve ser objeto de harmonização.
Uma decomposição funcional não deve ser confundida com uma decomposição ac-
de acordo com o tipo de caso. É possível que uma organização seja estruturada de acordo com
Página 68
Tabela 2.1 Nível um e nível dois da estrutura de classificação de processo APQC
1.0 Desenvolver visão e estratégia 7.6 Implementar soluções de tecnologia da informação

1.1 Definir o conceito de negócio e longo prazo 7.7 Entregar e apoiar informações
visão serviços de tecnologia
1.2 Desenvolver estratégia de negócios
8.0 Gerenciar Recursos Financeiros
1.3 Gerenciar iniciativas estratégicas
8.1 Realizar planejamento e gestão
2.0 Desenvolver e gerenciar produtos e serviços contabilidade
2.1 Gerenciar portfólio de produtos e serviços 8.2 Realizar contabilidade de receita
2.2 Desenvolver produtos e serviços 8.3 Realizar contabilidade e relatórios gerais
8.4 Gerenciar a contabilidade do projeto de ativo fixo
3.0 Comercializar e vender produtos e serviços
8.5 Processar folha de pagamento
3.1 Compreender mercados, clientes e
8.6 Processar contas a pagar e despesas
capacidades
reembolsos
3.2 Desenvolver estratégia de marketing
8.7 Gerenciar operações de tesouraria
3.3 Desenvolver estratégia de vendas
8.8 Gerenciar controles internos
3.4 Desenvolver e gerenciar planos de marketing
8.9 Gerenciar impostos
3.5 Desenvolver e gerenciar planos de vendas
8.10 Gerenciar fundos / consolidação internacionais
4.0 Entregar Produtos e Serviços
9.0 Adquirir, construir e gerenciar ativos
4.1 Planejar e alinhar os recursos da cadeia de abastecimento
9.1 Projetar e construir / adquirir
4.2 Aquisição de materiais e serviços
ativos não produtivos
4.3 Produzir / fabricar / entregar produtos
9.2 Planejar o trabalho de manutenção
4.4 Prestar serviço ao cliente
9.3 Obter e instalar ativos, equipamentos e
4.5 Gerenciar logística e armazenamento
Ferramentas
5.0 Gerenciar Atendimento ao Cliente 9.4 Descarte de produtos produtivos e não produtivos
5.1 Desenvolver atendimento / atendimento ao cliente ativos
estratégia
10.0 Gerenciar risco empresarial, conformidade,
5.2 Planejar e gerenciar o atendimento ao cliente e resiliência
operações
10.1 Gerenciar riscos corporativos
5.3 Medir e avaliar o atendimento ao cliente
10.2 Gerenciar resiliência de negócios
operações
10.3 Gerenciar saúde e segurança ambiental
6.0 Desenvolver e gerenciar capital humano
11.0 Gerenciar Relações Externas
6.1 Desenvolver e gerenciar recursos humanos
11.1 Construir relacionamentos com investidores
Planejamento, políticas e estratégias (RH)
11.2 Gerenciar governo e indústria
6.2 Recrutar, contratar e selecionar funcionários
relacionamentos
6.3 Desenvolver e aconselhar funcionários
11.3 Gerenciar relações com o conselho de administração
6.4 Recompensar e reter funcionários
11.4 Gerenciar questões legais e éticas
6.5 Reimplantar e aposentar funcionários
11.5 Gerenciar programa de relações públicas
6.6 Gerenciar informações de funcionários
12.0 Desenvolver e gerenciar negócios
7.0 Gerenciar Tecnologia da Informação
Capacidades
7.1 Gerenciar o negócio de informações
12.1 Gerenciar processos de negócios
tecnologia
12.2 Gerenciar portfólio, programa e projeto
7.2 Desenvolver e gerenciar cliente de TI
12.3 Gerenciar qualidade
relacionamentos
12.4 Gerenciar mudanças
7.3 Desenvolver e implementar segurança, privacidade,
e controles de proteção de dados 12.5 Desenvolver e gerenciar em toda a empresa
7.4 Gerenciar informações da empresa gestão do conhecimento (KM)
capacidade
7.5 Desenvolver e manter informações
soluções de tecnologia 12.6 Medir e comparar
Página 69
Fig. 2.3 Diferentes decomposições funcionais dentro da mesma organização
função de negócios e outras propriedades. Pode ser tentador desenvolver

a decomposição funcional ainda de acordo com essas outras propriedades. Contudo,
essas outras propriedades devem ser refletidas na dimensão do tipo de caso, em vez do
dimensão da função. Por exemplo, uma organização pode ser estruturada de acordo com
funções de negócios em um departamento de vendas e compras com gerentes que lideram
cada um dos departamentos. Pode ser estruturado de acordo com a localização, tendo
um departamento de vendas e de compras na Europa e na América do Norte. No
nesta situação, a decomposição funcional termina com a decomposição em vendas
e compras. Caso uma decomposição adicional de acordo com a localização seja relevante,
então esta decomposição deve ser refletida na dimensão do tipo de caso, não no
dimensão da função.
Uma decisão importante que deve ser feita ao desenvolver o de- funcional
composição é determinar o nível apropriado de decomposição em que o
a decomposição funcional termina. Em teoria, a decomposição funcional pode ser per-
formado até um nível que representa as tarefas que são realizadas pelo indivíduo
funcionário (preencher formulário, verificar a exatidão das informações no formulário, ter colega
verificar a exatidão das informações no formulário, etc.). No entanto, para uma arquitetura de processo
um nível mais grosseiro de decomposição é normalmente escolhido. Duas regras básicas que podem
ser usado para escolher o nível de decomposição em que a decomposição funcional
termina, são os seguintes.
1. A decomposição funcional deve ser realizada pelo menos até um nível de

quais funções correspondem a diferentes unidades organizacionais (com
gerentes). Por exemplo, se uma organização tem uma fonte e um pedido para
departamento de pagamento e ambos têm seus próprios gerentes, esta é uma forte indicação de que
a decomposição funcional deve conter as funções que são realizadas por
esses departamentos.
2. A decomposição funcional deve incluir funções diferentes para os diferentes
funções em cada departamento. Por exemplo, se o departamento de sourcing tem compradores,
que fazem análise de requisitos e seleção de fornecedores, bem como compradores seniores, que
fazer a gestão de relacionamento com fornecedores e gestão de contratos, isso pode levar a um
decisão de incluir análise de requisitos, seleção de fornecedor, relacionamento com o fornecedor
gestão e gestão de contratos como funções.
Página 70
Fig. 2.4 Uma matriz de caso / função
Observe que essas são regras básicas, que deixam espaço para manuseá-los flex
ìvel. Eles apenas fornecem uma ajuda para determinar o nível mais baixo de decomposição
que deve ser usado.
Exercício 2.6 Considere o caso de uma universidade e os processos de nível um listados

no PCF do APQC. Que tipo de funções mais específicas uma universidade tipifica
cobrir as categorias 2.0, desenvolver e gerenciar produtos e serviços e na 5.0
Gerencia o atendimento ao cliente?
2.2.3 Construir Matrizes de Caso / Função
As duas etapas anteriores da abordagem descrita levam a uma matriz que tem a diferença
diferentes tipos de caso como colunas e as diferentes funções como linhas. Uma célula na matriz
contém um 'X', se a função correspondente pode ser realizada para o correspondente
tipo de caso ing. A Figura 2.4 mostra um exemplo de uma matriz de caso / função. O Matrix
mostra uma decomposição de tipos de caso por tipo de cliente, resultando em três tipos de caso:
um para clientes particulares, um para clientes corporativos e um para clientes internos
clientes. A figura também mostra uma decomposição funcional em três funções principais
e uma decomposição subsequente dessas funções principais em dez subfunções.
As funções de gerenciamento e suporte são realizadas apenas para clientes internos, enquanto
as funções operacionais são realizadas para clientes particulares e corporativos.
Uma matriz de caso / função pode ser dividida em várias matrizes com o propósito de
melhorando a legibilidade. Normalmente, dividiríamos uma matriz de caso / função no caso
uma partição das funções da matriz e tipos de caso é possível de tal forma que todos os X são
Página 71
Fig. 2.5 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo (aplicando a Diretriz 1)
preservado. Por exemplo, a matriz da Fig. 2.4 pode ser particionada em, em um
lado, uma matriz que contém as funções de gestão e suporte e as internas
clientes e, por outro lado, uma matriz que contém as funções operacionais e as
clientes particulares e corporativos.
2.2.4 Identificar Processos
Na quarta e última etapa da abordagem proposta, determinamos qual combinação

nações de funções de negócios e tipos de casos formam um processo de negócios. Para determinar
isso, precisamos encontrar uma compensação entre dois extremos, um em que todo o ma-
trix forma um grande processo e um em que cada cruz única na matriz forma um
processo. Estabelecemos essa compensação pelo uso da regra geral de que, em princípio,
toda a matriz forma um grande processo que só será dividido em caso de
regras se aplicam. Essas regras podem ser formuladas como oito diretrizes. Quando uma diretriz
se aplica, isso pode levar a uma separação dos processos entre as linhas (uma divisão vertical)
ou a uma separação de processos entre colunas (uma divisão horizontal). Alguns dos
diretrizes (diretrizes 5, 6 e 8) só podem levar a divisões verticais, enquanto outras
(Diretrizes 1–4) só podem levar a divisões horizontais. Observe que as diretrizes não são
absoluto: eles podem ou não se aplicar a uma determinada organização e não são
as únicas regras que devem ser consideradas em casos específicos.
A Figura 2.5 mostra o exemplo de execução que usaremos para explicar as diretrizes.
A figura mostra uma matriz de caso / função para um corretor de hipotecas, que corretores de hipoteca
medidores na Holanda e na Bélgica. Ele distingue entre simplex
Página 72
e hipotecas compostas. Uma hipoteca composta pode ser adaptada para o re- específico
peculiaridades de um cliente, compondo-o a partir de diferentes tipos de empréstimos, poupanças
contas, seguros de vida e contas de investimento. Uma hipoteca simplex consiste em
um pacote pré-definido de um empréstimo, uma conta poupança e um seguro de vida. Nestes dif-
diferentes tipos de hipotecas, várias funções de negócios podem ser realizadas. Avaliação de risco
ment envolve a avaliação do risco de ambos os clientes individuais, que estão no processo
de solicitar uma hipoteca e produtos hipotecários como um todo. Corretora de hipotecas
envolve a seleção de um determinado pacote de hipoteca com base nos requisitos
de um cliente específico e, posteriormente, oferecer esse pacote ao cliente e
fechar o contrato. As funções financeiras envolvem o pagamento da hipoteca e
posteriormente cobrando os pagamentos mensais. Finalmente, o desenvolvimento de produtos é o
revisão periódica dos produtos hipotecários e seus componentes.
Diretriz 1: se um processo tiver objetos de fluxo diferentes, ele pode ser dividido verticalmente.
Um objeto de fluxo é um objeto na organização que flui através de um programa de negócios
cesso É o objeto no qual as atividades do processo empresarial estão sendo realizadas.
Normalmente, cada processo de negócios tem um único objeto de fluxo, de modo que objetos de fluxo
pode ser usado para identificar processos de negócios. Consequentemente, se vários objetos de fluxo
podem ser identificados em um processo de negócios, esta é uma forte indicação de que o processo
deve ser dividido.
A Figura 2.5 ilustra a aplicação da Diretriz 1 ao nosso exemplo de execução. 1

objeto de fluxo para o processo de corretagem de hipotecas é um aplicativo de hipoteca em que
as atividades são realizadas durante um pedido de hipoteca por um cliente. Essas atividades
incluir uma avaliação de risco e pagar a hipoteca ao cliente. Outro fluxo
objeto no processo de corretagem de hipotecas é um produto hipotecário em que as atividades
são realizadas periodicamente para avaliar o risco do produto como um todo e para avaliar
comer e desenvolver o produto. Consequentemente, podemos dividir a corretora de hipotecas
processo em dois processos, um que tem um aplicativo de hipoteca como objeto de fluxo e
aquele que tem um produto hipotecário como objeto de fluxo. Chamamos o primeiro de hipoteca
processo de aplicação e este último o processo de desenvolvimento e avaliação do produto.
Diretriz 2: Se o objeto de fluxo de um processo muda multiplicidade, o processo pode ser

dividir verticalmente. Isso se deve ao fato de que em um processo de negócios um único fluxo
objeto às vezes é usado, enquanto outras vezes vários objetos de fluxo do mesmo
tipo são usados. Isso é típico para processamento em lote, no qual certas atividades são
executado para vários casos de cliente em lote ao mesmo tempo. Se, no mesmo
processo, o número de objetos de fluxo que são processados por atividade difere isso pode
ser um motivo para dividir o processo.
Dê uma olhada na Fig. 2.5 , onde o processo de aplicação de hipoteca é realizado para
um único pedido de hipoteca. Em contraste, a cobrança de pagamentos acontece para
todas as hipotecas em lote no final de cada mês. Usando a Diretriz 2, isso pode ser
tomado como motivo de cisão do processo e tendo a Cobrança Hipotecária como um
processo separado.
Diretriz 3: Se um processo muda de estado transacional, ele pode ser dividido verticalmente.
De acordo com a teoria do fluxo de trabalho de ação, um processo de negócios passa por vários
Página 73
ber de estados transacionais. Em particular, podemos distinguir: a iniciação, o ne-

iniciação, a execução e o estado de aceitação. No estado de iniciação, contate
entre um cliente e um provedor é iniciado. No estado de negociação, o cliente
cliente e o fornecedor negociam sobre os termos de serviço ou entrega de um produto
uct. Durante o estado de execução, o provedor entrega o produto ou serviço ao
cliente e durante o estado de aceitação, o cliente e o fornecedor negociam
comeu sobre a aceitação e pagamento da entrega. Uma transição em um processo
de um estado para outro é uma indicação de que o processo pode ser dividido.
Para ilustrar essa diretriz, considere novamente a Fig. 2.5 . Suponha que durante o ne-
negociação declara o corretor de hipotecas e o cliente negocia sobre a seleção
de produtos hipotecários, em última análise, levando a um contrato sendo assinado por ambos os par-
laços. Somente durante o estado de execução a hipoteca é paga ao cliente e
os pagamentos mensais serão cobrados. Pela lógica da Diretriz 3, nós, portanto,
dividir o processo em um processo de aplicação de hipoteca e um pagamento de hipoteca
processo.
Diretriz 4: Se um processo contém uma separação lógica no tempo, ele pode ser dividido ver-
ticamente. Um processo contém uma separação lógica no tempo, se suas partes forem realizadas
em diferentes intervalos de tempo. Os intervalos que normalmente podem ser distinguidos incluem:
uma vez por solicitação do cliente, uma vez por dia, uma vez por mês e uma vez por ano.
Para esclarecer a Diretriz 4, considere a Fig. 2.5 novamente. Seleção de hipoteca, oferta e
a contratação é realizada uma vez por pedido de hipoteca, enquanto o pagamento e a cobrança
a seleção de hipotecas é realizada uma vez por mês. Pela lógica da Diretriz 4,
faria sentido dividir a seleção, oferta e contratação de hipotecas
cobrança do pagamento da hipoteca. Observe que a passagem do tempo em si não é uma razão
para dividir um processo, porque dentro de cada processo, o tempo passa. Para ex-
amplo, entre a atividade de inserir os detalhes da hipoteca em um sistema de computador e
aprovação da hipoteca, o tempo passa, mas a unidade de tempo permanece a mesma: ambos
as atividades acontecem uma vez por aplicativo de hipoteca. Portanto, não nos separaríamos
o processo entre essas atividades. Outra maneira de olhar a Diretriz 4 é que
o processo pode ser dividido, se deve esperar por um gatilho de tempo ou um gatilho por um novo
objeto de fluxo. Por exemplo, a aprovação de uma hipoteca pode ser realizada diretamente após
os detalhes da hipoteca são inseridos, sem ter que esperar por um acionador. No entanto, depois
tendo processado o pedido de hipoteca, o processo deve aguardar o pagamento
acione a data de cobrança para continuar com a cobrança do pagamento. Portanto, nós
dividir o processo entre essas funções pela mesma lógica da Diretriz 4.
Diretriz 5: se um processo contém uma separação lógica no espaço, ele pode ser dividido
horizontalmente. Um processo contém uma separação lógica no espaço, se for executado em
vários locais e é executado de forma diferente nesses locais. É importante
observar que não é suficiente que os processos sejam apenas separados no espaço. o
a separação deve ser tal que não haja escolha a não ser realizar os processos
de forma diferente para as diferentes unidades lógicas.
Para esclarecer esta diretriz: no caso de um processo ser realizado em locais diferentes
dentro do mesmo país, não há necessariamente uma razão para agir de forma diferente
Página 74
nesses locais. Conseqüentemente, não há razão para dividi-lo. Na verdade, a organização
ções devemde
economias seescala.
esforçar
Napara tornarmuitas
verdade, seus processos tão uniformes
organizações quanto
hoje em dia possível,
iniciaram para nos
projetos se beneficiar
quais
eles visam tornar seus processos mais uniformes em diferentes locais, onde
processos tornaram-se diferentes puramente por razões históricas ou porque os diferentes
cátions não compartilham informações sobre seu fluxo de processo. Como outro exemplo, o
processos da Fig. 2.5 são realizados em dois locais diferentes em diferentes países
tentativas. No entanto, ainda nem todos esses processos devem ser diferentes nesses dois locais.
Por exemplo, o pagamento e a cobrança de hipotecas podem ser os mesmos na Bélgica e
Os Países Baixos. No entanto, a avaliação de risco, corretagem de hipotecas e desenvolvimento de produtos
opção pode ser diferente entre a Holanda e a Bélgica, devido à especificidade do país
regras e regulamentos.
As diretrizes 6 e 7 são mais diretas e podem ser descritas como segue.
Diretriz 6: Se um processo contém uma separação lógica em outra dimensão relevante

seção, ele pode ser dividido horizontalmente. Como acontece com a separação no espaço, não é
suficiente para que os processos sejam apenas separados. A separação deve ser tal que
não há escolha a não ser realizar os processos de forma diferente para as diferentes logias
unidades cal.
Diretriz 7: Se um processo é dividido em um modelo de referência, ele pode ser dividido. Uma referência
a arquitetura de processo de referência é uma arquitetura de processo existente que é pré-definida como
uma solução de prática recomendada. Ele estrutura uma coleção de processos. Por exemplo, se um
existe uma arquitetura de processo de serviços financeiros de referência, sua estrutura pode ser usada
como um exemplo ou ponto de partida para estruturar sua própria arquitetura de processo.
A Figura 2.6 mostra os resultados da aplicação das Diretrizes 2 a 7 para o

matriz de caso / função da Fig. 2.5 , que resultou da aplicação da Diretriz 1
ao nosso exemplo de execução. A Figura 2.6 mostra que após a aplicação das Diretrizes 2 a
7, conforme discutido acima, existem seis processos: Desenvolvimento e Avaliação do Produto -
ment Holanda (PD NL), Desenvolvimento e Avaliação de Produto Bélgica (PD
BE), Mortgage Application Netherlands, Mortgage Application Belgium, Mortgage
Pagamento e cobrança da hipoteca.
A orientação final que discutimos aqui é a seguinte.
Diretriz 8: Se um processo cobre (muitas) mais funções em um tipo de caso do que em

outro, pode ser dividido horizontalmente. A aplicação desta última regra depende
na decomposição atual dos processos. Se aplicado, é necessário olhar
na decomposição atual de processos e verifique se, dentro de um processo, (muitos)
mais funções são realizadas para um tipo de caso do que para outro, ou seja: se
um processo tem muito mais cruzes em uma coluna do que em outra. Se sim, este é um
forte indicação de que o processo deve ser dividido para esses dois tipos de caso.
Por exemplo, ao olhar para a Fig. 2.6 , vemos que o aplicativo de hipoteca
O processo da Holanda tem muito mais funções para hipotecas compostas do que para sim-
hipotecas plex. Pela lógica da Diretriz 8, dividiríamos este processo para
aplicação composta e simplex. A aplicação de todas essas oito diretrizes
produz uma arquitetura de processo para o nível um. O resultado pode ser visto na Fig. 2.7 , que
é o modelo de paisagem de processo finalizado para nosso exemplo.
Página 75
Fig. 2.6 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo (aplicando o Guia
linhas 2-7)
Fig. 2.7 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo (aplicando a Diretriz 8)
Página 76
Tabela 2.2
Consumidor-produtor Consumidor Produtor
relações entre
processos Pagamento da hipoteca Aplicativo de hipoteca composto NL
Pagamento da hipoteca Aplicativo de hipoteca simplex NL

Pagamento da hipoteca Aplicação de hipoteca BE
2.2.5 Concluir a Arquitetura do Processo
A abordagem que discutimos anteriormente e que enfatizamos nesta parte do

o livro leva a um modelo de paisagem de processo que cobre os processos no nível um
da pirâmide na Fig. 2.1 . Conforme declarado, este nível fornece apenas uma visão muito abstrata
em cada processo dentro do cenário de processo: mostra principalmente como os processos diferem
uns dos outros em termos dos casos e funções que cobrem.
Há duas coisas que estão faltando em relação ao geral, englobe
características de uma arquitetura de processo, conforme discutimos na Seção 2.2 : (1) o
relações consumidor-produtor entre os processos e (2) os níveis de detalhe
conforme fornecido pela pirâmide na Fig. 2.1 .
No que diz respeito às relações consumidor-produtor, podemos tomar uma ampla ou narrativa
perspectiva de linha sobre o uso de uma saída de um processo como a entrada de outro.
Para o nosso exemplo em execução, pode ser que o processo de desenvolvimento de produto use ag-
dados agregados sobre como o processo de aplicação de hipoteca é realizado para determinar
quais são as necessidades dos clientes e, dessa forma, quais são os novos produtos atrativos.
Esta seria uma interpretação bastante ampla da relação consumidor-produtor.
O que muitas vezes é mais importante saber decorre de uma perspectiva mais restrita, ou seja,
quais relações consumidor-produtor existem entre os processos no que diz respeito ao
mesmos objetos de fluxo. Na Fig. 2.7 , pode-se ver que o pedido de hipoteca (ambos em
Holanda e Bélgica) e o pagamento da hipoteca são divididos, o que foi feito
seguindo a lógica da Diretriz 3. Esta é uma situação onde o objeto de fluxo de um
o processo é consumido aos poucos por outro; a única diferença é o transacional
declarar que o objeto de fluxo está dentro. Especificamente em relação às iniciativas de redesenho,
relações são mais importantes para lembrar e tornar explícito, uma vez que mudar um
processo tem implicações diretas para o desempenho do outro. Podemos capturar isso
interpretação restrita das relações consumidor-produtor para nosso exemplo de execução
como é feito na Tabela 2.2 . Cada linha nesta tabela fornece um único produtor-consumidor
relacionamento, onde o processo do consumidor continua a trabalhar em um objeto de fluxo que é
a saída do processo de produção.
Vamos agora nos concentrar no outro aspecto que torna uma arquitetura de processo para nível
um bastante restritivo em comparação com nossa noção geral de uma arquitetura de processo.
Isso diz respeito ao alto nível de abstração dos processos que se distinguem por
o modelo de paisagem de processo. Para se concentrar nos outros níveis da pirâmide da Fig. 2.1 ,
a questão é que tipo de detalhe adicional eles devem oferecer. Nós nos concentramos aqui em
os insights que faltam sobre (a) as várias etapas que são realizadas em cada processo
e (b) as unidades organizacionais que estão envolvidas em sua execução. Estes dois
elementos devem ser adicionados para obter os modelos para o nível dois do que entendemos por
Página 77
Fig. 2.8 Um mapa de processo para o processo de pagamento da hipoteca
uma arquitetura de processo. É comum se referir a um modelo neste segundo nível como um
mapa de processo .
Para fornecer um exemplo de um mapa de processo, nos concentramos no pagamento da hipoteca
processo que é identificado no modelo de paisagem de processo da Fig. 2.7 . O relacionado
o mapa do processo pode ser visto na Fig. 2.8 .
Como mostra esta figura, o processo de pagamento de hipoteca identificado a partir do processo
modelo de paisagem foi decomposto em quatro etapas principais que podem ser associadas
com este processo. Além disso, duas unidades organizacionais são identificadas que estão associadas
ciado com essas etapas, ou seja, Contabilidade e Faturamento. Em outras palavras, um mapa de processo
fornece mais detalhes sobre o fluxo de controle e inclui informações adicionais com
respeito aos recursos envolvidos para um processo.
Pode-se dizer que mesmo um mapa de processo fornece uma visão abstrata de um processo.
Em primeiro lugar, ainda podemos ver que o fluxo ao longo das etapas em um mapa de processo
é altamente simplificado. É comum, como na Fig. 2.8 , mostrar apenas um progresso linear
ao longo das várias etapas em um mapa de processo: caminhos alternativos, exceções potenciais,
iterações, etc. são deixadas de fora. Para as informações organizacionais que são adicionadas em um
mapa de processo, também, a informação é abstrata: só podemos ver referências a unidades, mas
não o tipo específico de participantes envolvidos.
Exercício 2.7 Dê um exemplo de um caminho alternativo, uma exceção potencial e um

iteração que apareceria em um modelo mais detalhado do pagamento da hipoteca
processo.
Em segundo lugar, há muitos aspectos além do fluxo de controle e informações de recursos

que não são cobertos em nenhum nível de detalhe em um mapa de processo. Pense nos dados que
estão sendo tratados no processo, os relatórios e arquivos que são repassados, os sistemas
que suportam as várias etapas, o tempo que está envolvido na realização dessas etapas,
etc.
Na prática, os mapas de processo acabaram por fornecer um nível mais profundo de percepção sobre
os processos do cenário de processo, independentemente dos objetivos que se busca para o
processos específicos. Em outras palavras, uma visão sobre as etapas e organizações envolvidas
unidades internacionais têm seu valor para qualquer tipo de iniciativa orientada para o processo. Em contraste, um
mais informações sobre, por exemplo, os dados que estão sendo processados em cada etapa
Página 78
2.3 Recapitulação 57
só faria sentido se alguém buscasse automatizar o processo ou quando o

fase de avaliação identificou problemas de qualidade.
Neste livro, não vamos nos concentrar no desenvolvimento de mapas de processo. Em vez de,
vamos nos voltar para o nível mais detalhado de modelos, ou seja, aqueles no nível três de um processo
arquitetura. Como será mostrado, esses modelos são desenvolvidos seguindo regras específicas
e fornecer a visão idealmente ligada ao que se deseja alcançar com
uma iniciativa específica de gerenciamento de processos. Este será o assunto do seguinte
capítulos.
2.3 Recapitulação
Neste capítulo, discutimos a identificação do processo. Primeiro, nós distinguimos

e descreveu as fases de designação e avaliação. A fase de designação visa
em enumerar os principais processos dentro de uma organização, bem como determinar
as fronteiras entre esses processos. Uma visão dos principais processos que
estão sendo realizados em uma organização é importante configurar qualquer homem de processo
atividade de gestão. A fase de avaliação é dedicada a priorizar a análise do processo
e esforços de redesenho. É uma boa prática basear as prioridades na importância de
processos, sua disfunção potencial e a viabilidade de melhorias.
A fase de designação pode ser usada não apenas para enumerar os mais importantes
processos, mas também para projetar uma arquitetura de processo abrangente e consistente. Um pro
A arquitetura do processo define a relação entre os diferentes processos. Frequentemente,
diferentes níveis de detalhe são distinguidos. Discutimos uma abordagem específica para o
definição do nível um da arquitetura do processo. Esta abordagem se baseia na identidade
identificação dos tipos de caso, das funções para esses tipos de caso, a construção de um
matriz de caso / função, a identificação de processos com base em diretrizes, e o
eventual conclusão da arquitetura.
Solução 2.1 Explique como funciona a compensação entre impacto e capacidade de gerenciamento
fora para processos amplos e estreitos, respectivamente. Um amplo processo tem por definição
um grande escopo. Gerenciar isso ativamente pode ter um grande impacto em uma organização
desempenho da zação. O outro lado é que é mais difícil gerenciar ativamente tais
um processo amplo ou os projetos de melhoria que estão relacionados a ele. Para um estreito pro-
cesso, é exatamente o contrário: devido ao seu escopo menor, é mais fácil
gerenciado, mas provavelmente terá um impacto menor no desempenho de uma organização
como um todo.
Solução 2.2 A descrição da empresa de investimento aponta para uma grande retenção financeira
, que podem estar relacionados ao emprego de muitos produtos diferentes (investimentos
instrumentos financeiros) para muitos clientes diferentes, tanto privados como institucionais. Ambos
Página 79
dessas dimensões, produtos e clientes, podem levar a empresa a identificar diferentes

processos que atendem a esses. Além disso, a descrição da empresa também menciona
'responsabilidade': para muitas organizações financeiras, existem requisitos estritos sobre
como eles devem gerenciar e divulgar sua operação, conforme imposto a eles pela regulamentação
agências de latórios. Isso também pode ser um motivador para a identificação de muitos
processos.
Solução 2.3 O gerenciamento de pedidos não está sequencialmente relacionado a nenhum deles. Como dis-
discutidos no texto, reserva, cobrança, remessa e entrega são todos subprocessos de
gerenciamento de pedidos. Portanto, é impossível indicar que algum desses subprocessos
precede ou acompanha o gerenciamento de pedidos; em vez disso, eles são subsumidos por este
processo.
Solução 2.4 As organizações desejam atingir certos objetivos . Os processos são um meio
para
estãoatingir esses objetivos.
relacionados entre si noUma relação
sentido que,contribuem
de que portanto, pode
paraser importante
o mesmo ou é como os processos
metas. Outras relações específicas do contexto também podem ser importantes para as organizações.
Considere como pode ser importante para uma organização saber em qual tecnologia
gies seus processos são baseados; se uma determinada tecnologia se tornar obsoleta, tal
organização sabe quais processos são afetados. Uma linha de raciocínio semelhante pode ser
tomadas para áreas geográficas, regulamentos, etc.
Solução 2.5 Muitos bancos distinguem diferentes tipos de clientes e usam este dis-
tição para definir tipos de produtos e serviços para eles, tanto quanto canais. Para
Por exemplo, um cliente de banco de varejo é tipicamente caracterizado por um baixo a médio
venha quem requer serviços de transação e produtos para acumular riqueza. Frequentemente,
os bancos tentam atender esses clientes por meio de canais padronizados como telefone e
ternet para limitar os custos de transação. Pelo contrário, os clientes de bancos privados são
normalmente têm alta renda ou possuem uma fortuna considerável. Os bancos investem muito
mais em aconselhamento pessoal e consultoria desses clientes e na oferta de
pacotes individuais de produtos e serviços. Muitas vezes, considerações estratégicas como
daqueles um banco neste exemplo têm a consequência de que diferentes classificações
critérios são freqüentemente correlacionados.
Solução 2.6 Os produtos e serviços de uma universidade se relacionam ao ensino e certificação

cação e, essencialmente, apoiar o ciclo de vida de um aluno para a obtenção de um diploma.
Portanto, a categoria 2.0 relaciona-se principalmente ao desenvolvimento e gestão de
currículos e programas de graduação. As entidades acadêmicas de uma universidade estão envolvidas
com essas tarefas. A categoria 5.0 se refere à gestão de serviços estudantis
vícios. Normalmente, as tarefas pertencentes a esta categoria são organizadas em um exame
escritório da universidade auxiliando em todos os assuntos relacionados ao estudo.
Solução 2.7 Um exemplo de caminhos alternativos no processo de pagamento de hipotecas

seria que diferentes condições de pagamento levariam a atividades de cobrança de pagamentos.
Um exemplo de exceção neste processo seria que o saldo da conta é
Página 80
2.5 Exercícios adicionais 59
não é suficiente para cobrar um pagamento. Um exemplo de iteração seria que após um
falha na cobrança do pagamento, isso é tentado novamente (talvez após um certo atraso).
2.5 Exercícios adicionais
Exercício 2.8 Uma universidade fornece educação e serviços aos seus alunos. Isso começa
com admissão de alunos à universidade. Quando um aluno regular, ou seja, um aluno
que vem de uma escola secundária holandesa, envia em seu formulário de admissão tal aluno que é
registrado pelo escritório de admissões. Posteriormente, a elegibilidade para estudar em um determinado
programa é verificado com base nas informações que o aluno forneceu em seu anúncio
formulário de missão. Para alunos que chegam de outra escola, como uma politécnica,
o estudo prévio que o aluno realizou, conforme ficha de admissão, deve ser
examinados em detalhes. Os alunos politécnicos podem vir para a universidade após
completar um ano de cursos (propedeuse) ou depois de receber um diploma politécnico.
Estudantes de universidades de outros países também são aceitos. Também para eles, o
estudos que eles
considerados fizeram
elegíveis anteriormente
e os cursos que jádevem ser examinados
frequentaram em detalhes. Quando os alunos são
(se aplicável)
confira, eles estão matriculados na universidade, o que envolve o envio de uma carta que
eles são aceitos e inserindo os detalhes de sua inscrição no sistema de informações
tem da universidade. Os alunos então se tornam alunos de seus respectivos estudos:
engenharia industrial, construção ou engenharia de construção.
Depois que os alunos estão matriculados, eles podem fazer cursos ou fazer projetos e podem
usar os serviços que são prestados pela universidade, que incluem: formação de línguas
e instalações desportivas. Os projetos são feitos individualmente por um aluno em conjunto
com um palestrante. A universidade reconhece alunos em tempo parcial que fazem seus estudos
enquanto eles estão trabalhando em uma empresa. Esses alunos costumam fazer projetos de mais
natureza prática do que os demais alunos, de modo que o processo que é seguido durante
o projeto também é diferente para esses alunos.
Projete uma arquitetura de processo da seguinte maneira:
1. identificar os tipos de caso que devem aparecer na arquitetura do processo

2. identificar as funções que devem aparecer na arquitetura do processo
3. desenhe uma matriz de caso / função
4. identificar os processos na matriz de função de caso, dividir os processos se e somente se
uma das diretrizes se aplica, indique claramente qual diretriz você aplicou onde
Exercício 2.9 Uma empresa de consultoria fornece consultoria, terceirização e interina

serviços de gestão. A empresa considera a aquisição de projetos como parte daqueles
Serviços. A aquisição pode ser feita para clientes existentes e para novos clientes, seja
porque se trata de aquisição de projetos e não de clientes. Aquisição é tipicamente
começou em 'eventos de networking' por sócios da empresa de consultoria. É tratado
de acordo com um procedimento fixo, mas nenhum documento padrão é usado. Quando um cliente
demonstra interesse em uma consultoria, é feito um levantamento com o cliente. Para manter
manter um relacionamento de longo prazo com os clientes tanto quanto possível, a empresa sempre
Página 81
tente estabelecer um contrato-quadro com novos clientes durante a admissão. Para existir-
clientes, não é necessário estabelecer um contrato-quadro. Como outra forma
de gestão de relacionamento, são realizadas reuniões periódicas com os clientes existentes. Durante
Nessas reuniões, a organização do cliente é discutida com o cliente. Isso permite
o cliente deve decidir se trabalho adicional deve ser feito para melhorar ainda mais o
organização. Ao mesmo tempo, isso permite que a empresa traga atribuições adicionais
mentos. O recebimento e as reuniões ordinárias acontecem no mesmo formulário, no
que um inventário dos desejos do cliente pode ser feito.
Para serviços de consultoria e terceirização, uma equipe de projeto deve ser criada diretamente
após a atribuição de um projeto à empresa de consultoria. Depois que uma equipe de projeto é
criado, há uma reunião de lançamento com o cliente e após a reunião de lançamento, o
projeto é executado. A reunião inicial é a mesma para cada tipo de projeto, mas
a forma como o projeto é executado difere amplamente por tipo de serviço. No
final do projeto sempre há uma reunião de avaliação com o cliente como forma de
controle de qualidade. A criação da equipe do projeto, a reunião de lançamento, a execução
do projeto e a avaliação do projeto acontecem de acordo com um plano de projeto.
A consultoria possui um departamento de serviços, que atende o mercado
pesquisa para os consultores, administra a locação de automóveis e fornece secretaria
Serviços.
Projete uma arquitetura de processo da seguinte maneira:
1. identificar os tipos de caso que devem aparecer na arquitetura do processo

2. identificar as funções que devem aparecer na arquitetura do processo
3. desenhe uma matriz de caso / função
4. identificar os processos na matriz de função de caso; dividir processos se e somente se
uma das diretrizes se aplica e indica qual diretriz você aplicou onde
A importância da identificação explícita de processos foi talvez primeiro discutida por

Davenport [ 10 ], enquanto uma perspectiva semelhante é oferecida por Hammer & Champy [ 29 ].
Sharp & McDermott [ 86 ] dão conselhos práticos sobre como explorar a terra do processo
escapo - um termo alternativo para arquitetura de processo. Outro livro prático cov-
O projeto de arquitetura de processo ering é aquele de Ould [ 64 ]. Uma das questões deixadas em aberto
por esses livros é até que ponto vale a pena identificar e delinear processos em um
maneira específica da empresa, em oposição à adoção de modelos de referência padronizados para
este propósito.
Dijkman [ 14 ] fornece uma pesquisa de abordagens populares de arquitetura de processos. 1
das descobertas desta pesquisa é que os profissionais tendem a aplicar uma mistura de estilos para de-
rive arquiteturas de processo e que nenhuma abordagem única e popular seja seguida. Apesar de
o interesse prático no tema, há pouca pesquisa acadêmica na área de
arquiteturas de processo. As exceções são o trabalho de Frolov et al. [ 20 ] e Zur Muehlen
et al. [ 112 ]. Ambos os grupos de autores enfatizam a importância de um programa hierárquico
arquiteturas de cesso. Ainda não está claro até que ponto prescrito, normativo
as abordagens fornecidas pela academia são aplicáveis e benéficas na prática.
Página 82
O conceito de cadeia de valor - que geralmente aparece no topo de um processo

arquitetura - foi popularizada por Michael Porter [ 67 ]. Porter também contribuiu para
popularizando a distinção entre o processo central (que ele chamou de atividade primária
) e processo de suporte. Um modelo de referência detalhado centrado em torno da noção de
cadeia de valor é o Modelo de Referência de Valor (VRM) definido pelo Grupo de Cadeia de Valor
( http://www.value-chain.org/ ).
Relacionado e até certo ponto complementar ao conceito de cadeia de valor está o
framework de desempenho organizacional de Rummler & Brache [ 80 ]. Neste quadro-
trabalho, as organizações são vistas como sistemas cujo propósito é produzir valor dentro
um determinado ambiente, que inclui concorrentes, fornecedores, mercado de capitais, mão de obra
mercados, regulamentações e outros fatores externos. Dentro deste ambiente, a organização
zações criam valor ao adquirir materiais ou recursos de fornecedores, a fim de
fabricar ou entregar produtos ou serviços para clientes. O valor criado leva
ao lucro dos acionistas.
Rummler & Ramias [ 81 ] descrevem uma variante do framework de Rummler & Brache,
a saber, a Hierarquia de Criação de Valor (VCH). Nesta estrutura, o sistema que
transforma recursos em produtos ou serviços é chamado de Sistema de Criação de Valor
(VCS). O VCS é decomposto em subsistemas de processamento, que por sua vez são
decomposto em processos ponta a ponta e, em seguida, em subprocessos, tarefas e sub
tarefas. O VCH, portanto, fornece uma estrutura conceitual que vai desde
o contexto organizacional ao nível mais baixo de uma arquitetura de processo.
Página 83
Capítulo 3
Modelagem de Processo Essencial
Essencialmente, todos os modelos estão errados, mas alguns são úteis.

George EP Box (1919–)
Os modelos de processos de negócios são importantes em vários estágios do ciclo de vida do BPM. Estar-
antes de começar a modelar um processo, é crucial entender porque estamos modelando
isto. Os modelos que produzimos terão uma aparência bem diferente, dependendo do motivo para
modelá-los em primeiro lugar. Existem muitos motivos para modelar um processo.
O primeiro é simplesmente entender o processo e compartilhar nosso entendimento
do processo com as pessoas que estão envolvidas no processo diariamente.
Na verdade, os participantes do processo normalmente executam atividades bastante especializadas em uma
de tal forma que dificilmente se confrontam com a complexidade de todo o processo.
Portanto, a modelagem de processos ajuda a compreender melhor o processo e identificar
e evitar problemas. Este passo para um entendimento completo é o pré-requisito
paraNeste
conduzir análise,
capítulo, nosredesenho ou automação
familiarizaremos com osde processos. básicos do processo
ingredientes
modelagem usando a linguagem BPMN. Com esses conceitos, seremos capazes de pro-
modelos de processos de negócios duce que capturam relações temporais e lógicas simples
entre atividades, objetos de dados e recursos. Primeiro, vamos descrever algumas
conceitos de modelos de processo, nomeadamente como os modelos de processo se relacionam com as instâncias de processo.
Em seguida, explicaremos os quatro principais blocos estruturais de ramificação e fusão em
modelos de processo. Estes definem decisões exclusivas, execução paralela, inclusive de
cisões e repetição. Finalmente, iremos cobrir artefatos de informação e recursos
envolvidos em um processo.
3.1 Primeiros Passos com BPMN
Com mais de 100 símbolos, BPMN é uma linguagem bastante complexa. Mas, como aluno, há
não há motivo para pânico. Alguns desses símbolos já permitem que você cubra
muitas de suas necessidades de modelagem. Depois de dominar este subconjunto de BPMN, o
os símbolos restantes virão naturalmente para você com a prática. Então, em vez de descrever
ing cada um dos símbolos BPMN detalhadamente, aprenderemos BPMN introduzindo seu
símbolos e conceitos gradualmente, por meio de exemplos.

Página 84
64 3 Modelagem de Processo Essencial
Fig. 3.1 O diagrama de um processo simples de atendimento de pedidos
Neste capítulo, nos familiarizaremos com o conjunto básico de símbolos fornecidos por
BPMN. Conforme afirmado anteriormente, um processo de negócios envolve eventos e atividades . Eventos
representam coisas que acontecem instantaneamente (por exemplo, uma fatura foi recebida)
enquanto as atividades representam unidades de trabalho que têm uma duração (por exemplo, uma atividade para
pagar uma fatura). Além disso, lembramos que em um processo, eventos e atividades são logicamente
relacionados. A forma mais elementar de relação é a da sequência , o que implica que
um evento ou atividade A é seguido por outro evento ou atividade B. Consequentemente, o
os três conceitos mais básicos de BPMN são evento, atividade e arco. Os eventos são representados
enviados por círculos, atividades por retângulos arredondados e arcos (chamados de fluxos de sequência
em BPMN) são representados por setas com uma ponta de seta completa.
Exemplo 3.1 A Figura 3.1 mostra uma sequência simples de atividades modelando um pedido
processo de cumprimento em BPMN. Este processo começa sempre que um pedido de compra tem
recebido de um cliente. A primeira atividade realizada é a confirmação do
ordem. Em seguida, o endereço de envio é recebido para que o produto possa ser enviado para
o cliente. Posteriormente, a nota fiscal é emitida e assim que o pagamento for recebido
o pedido é arquivado, completando assim o processo.
A partir do exemplo acima, notamos que os dois eventos são representados com dois
símbolos ligeiramente diferentes. Usamos círculos com uma borda fina para capturar eventos iniciais
e círculos com uma borda espessa para capturar eventos finais. Os eventos de início e término têm um
papel
início importante emenquanto
do processo, um modelo de processo:
o evento o evento
final indica de início
quando indica quando
as instâncias as instâncias
são concluídas. Para adoprova-
ple, uma nova instância do processo de atendimento do pedido é acionada sempre que uma compra
o pedido é recebido e concluído quando o pedido é atendido. Vamos imaginar que
o processo de atendimento do pedido é realizado em uma organização do vendedor. Todos os dias isso
organização irá executar uma série de instâncias deste processo, cada instância sendo
independente dos outros. Depois que uma instância de processo foi gerada, usamos o
noção de token para identificar o progresso (ou estado ) dessa instância. Tokens são cre-
atados em um evento de início, fluem por todo o modelo de processo até que sejam destruídos em
um evento final. Representamos os tokens como pontos coloridos na parte superior de um modelo de processo. Para ex-
A Fig. 3.2 ampla mostra o estado de três instâncias do processo de atendimento do pedido:
uma instância acabou de começar (token preto no evento de início), outra está enviando o
produto (token vermelho na atividade "Enviar produto"), e o terceiro recebeu o
pagamento e está prestes a iniciar o arquivamento do pedido (token verde no fluxo de sequência
entre “Receber pagamento” e “Pedido de arquivo”).
Embora seja natural dar um nome (também chamado de rótulo ) a cada atividade, nós
não se esqueça de dar rótulos aos eventos também. Por exemplo, dar um nome a
cada evento de início nos permite comunicar o que dispara uma instância do processo,
Página 85
3.1 Primeiros Passos com BPMN 65
Fig. 3.2 Progresso de três instâncias do processo de atendimento do pedido
ou seja, quando uma nova instância do processo deve ser iniciada. Da mesma forma, dando
um rótulo para cada evento final nos permite comunicar quais condições se mantêm quando um
instância do processo é concluída, ou seja, qual é o resultado do processo.
Recomendamos as seguintes convenções de nomenclatura. Para atividades, o rótulo deve
começar com um verbo na forma imperativa seguido por um substantivo, normalmente referindo-se a
um objeto de negócio, por exemplo, “Aprovar pedido”. O substantivo pode ser precedido por um adjetivo,
por exemplo, "Emitir carteira de motorista", e o verbo pode ser seguido por um complemento a ex-
claro como a ação está sendo feita, por exemplo, “Renovar carteira de motorista por meio de agências off-line”.
No entanto, tentaremos evitar rótulos longos, pois isso pode dificultar a legibilidade do
modelo. Como regra geral, evitaremos rótulos com mais de cinco palavras, excluindo
preposições e conjunções. Artigos são normalmente evitados para encurtar rótulos. Para
eventos, o rótulo deve começar com um substantivo (novamente, isso normalmente seria um
objeto) e terminar com um verbo na forma de particípio passado, por exemplo, “Fatura emitida”. O verbo
é um particípio passado para indicar algo que acabou de acontecer. Semelhante a activ-
rótulos de idade, o substantivo pode ser precedido por um adjetivo, por exemplo, “Envio de pedido urgente”. Nós
capitalize a primeira palavra dos rótulos de atividade e evento.
Verbos gerais como "fazer", "fazer", "executar" ou "conduzir" devem ser
substituído por verbos significativos que capturam as especificidades da atividade que está sendo realizada
formada ou a ocorrência do evento. Palavras como “processo” ou “ordem” também são ambíguas
em termos de sua classe gramatical. Ambos podem ser usados como um verbo ("processar", "or-
der ”) e como um substantivo (“ um processo ”,“ uma ordem ”). Recomendamos usar tais palavras
consistentemente, apenas em uma classe gramatical, por exemplo, “ordem” sempre como um substantivo.
Para nomear um modelo de processo, devemos usar um substantivo, potencialmente precedido por um anúncio
jectivo, por exemplo, processo de “atendimento de pedido” ou “tratamento de reclamações” Este rótulo pode ser ob-
entendido nominalizando o verbo que descreve a ação principal de um processo de negócios,
por exemplo, “cumprir pedido” (a ação principal) torna-se “atendimento de pedido” (a etiqueta do processo).
Substantivos em forma de hifenização, como "ordem para pagamento" e "aquisição para pagamento", indicando o
sequência das principais ações no processo, também são possíveis.
Não colocamos letras maiúsculas na primeira palavra dos nomes dos processos, por exemplo, o "atendimento do pedido"
processo. Seguindo essas convenções de nomenclatura, manteremos nossos modelos mais
consistente, torná-los mais fáceis de entender para fins de comunicação e aumentar
sua reutilização.
O exemplo na Fig. 3.1 representa uma maneira possível de modelar o atendimento do pedido
processo de enchimento. No entanto, poderíamos ter produzido um modelo de processo bastante diferente.
Por exemplo, poderíamos ter negligenciado certas atividades ou expandido em outras
ers, dependendo da intenção específica de nossa modelagem. A caixa “Um pouco sobre modelagem
teoria ”reflete sobre as propriedades que sustentam um modelo e as relaciona com as
caso específico de modelos de processo.
Página 86
UM POUCO SOBRE TEORIA DE MODELAGEM

Um modelo é caracterizado por três propriedades: mapeamento, abstração e ajuste
para fins. Primeiro, um modelo implica um mapeamento de um fenômeno do mundo real -
o assunto de modelagem. Por exemplo, um edifício residencial a ser construído
poderia ser modelado por meio de uma miniatura de madeira. Em segundo lugar, um modelo apenas documenta
aspectos relevantes do assunto, ou seja, abstrai de certos detalhes que são irrelevantes
relevante. O modelo de madeira do edifício abstrai claramente dos materiais
o edifício será construído. Terceiro, um modelo serve a um propósito particular
pose , que determina os aspectos da realidade a omitir ao criar um modelo.
Sem um propósito específico, não teríamos indicação sobre o que omitir.
Considere o modelo de madeira novamente. Ele serve ao propósito de ilustrar como o
edifício será semelhante. Assim, ele negligencia aspectos que são irrelevantes para o julgamento
a aparência, como o sistema elétrico do edifício. Então, podemos dizer que um
modelo é um meio de abstrair de um determinado assunto com a intenção de capturar
aspectos específicos do assunto.
Fig. 3.3 Um edifício ( a ), sua miniatura de madeira ( b ) e sua planta ( c ). (( b ): © 2010, Bree
Indústrias; ( c ): usado com permissão de planetclaire.org)
Uma maneira de determinar o propósito de um modelo é entender o auto-alvo

ciência do modelo. No caso do modelo de madeira, o público-alvo poderia
ser um potencial comprador do edifício. Assim, é importante focar no ap-
perância do edifício, ao invés dos detalhes técnicos da construção.
Por outro lado, o modelo de madeira seria de pouca utilidade para um engenheiro que
tem que projetar o sistema elétrico. Neste caso, uma planta do edifício
seria mais apropriado.
Assim, ao modelar um processo de negócios, precisamos ter em mente o
propósito específico e público-alvo para o qual estamos criando o modelo.
Existem dois objetivos principais para a modelagem de processos: projeto organizacional
e design de sistema de aplicação . Modelos de processos para design organizacional são
orientada para os negócios . Eles são construídos por analistas de processo e usados principalmente para
compreensão e comunicação, mas também para benchmarking e melhoria
mento. Como tal, eles precisam ser intuitivos o suficiente para serem compreendidos pelo
várias partes interessadas e normalmente abstrairão dos aspectos relacionados à TI. o
o público-alvo inclui gerentes, proprietários de processos e analistas de negócios. Pró-
modelos de acesso para design de sistema de aplicativo são orientados para TI . Eles são construídos por
Página 87
3.2 Ramificação e fusão 67
engenheiros e desenvolvedores de sistema e usados para automação. Assim, eles devem

conter detalhes de implementação, a fim de ser implantado em um BPMS, ou usado como
projetos para desenvolvimento de software.
Neste e no próximo capítulo, vamos nos concentrar no orientado a negócios
modelos de cesso. No cap. 9 aprenderemos como transformar esses modelos de processo em execução
cortável.
3.2 Ramificação e fusão
Atividades e eventos podem não ser necessariamente realizados sequencialmente. Por exemplo,
no contexto de um processo de tratamento de reivindicações, a aprovação e a rejeição de uma reivindicação
são duas atividades que se excluem. Portanto, essas atividades não podem ser realizadas
em sequência, já que uma instância desse processo executará qualquer uma dessas atividades.
Quando duas ou mais atividades são alternativas uma à outra, dizemos que são mutuamente
exclusivo .
Vamos considerar outra situação. No processo de tratamento de reclamações, uma vez que a reclamação
aprovado, o reclamante é notificado e o desembolso é feito. Notifi-
cação e desembolso são duas atividades que são normalmente realizadas por dois
unidades de negócios diferentes, portanto, são independentes umas das outras e, como tal,
não precisam ser realizados em sequência: eles podem ser realizados em paralelo, ou seja, em
o mesmo tempo. Quando duas ou mais atividades não são interdependentes, elas são concorrentes
alugar .
Para modelar esses comportamentos, precisamos introduzir a noção de gateway . O termo
gateway implica que existe um mecanismo de bloqueio que permite ou proíbe
passagem de tokens pelo gateway. À medida que os tokens chegam a um gateway, eles podem ser
mesclados na entrada ou separados na saída dependendo do tipo de gateway.
Descrevemos os gateways como diamantes e os distinguimos entre divisões e junções.
Um gateway dividido representa um ponto onde o fluxo do processo diverge enquanto uma junção
gateway representa um ponto onde o fluxo do processo converge. As divisões têm uma incom-
fluxo de sequência de ing e múltiplos fluxos de sequência de saída (representando os ramos
que divergem), enquanto as junções têm vários fluxos de sequência de entrada (representando o
ramificações a serem mescladas) e um fluxo de sequência de saída.
Vamos agora ver como exemplos como os acima podem ser modelados com gateways.
3.2.1 Decisões Exclusivas
Para modelar a relação entre duas ou mais atividades alternativas, como no caso
da aprovação ou rejeição de uma reivindicação, usamos uma divisão exclusiva ( XOR ) . Nós usamos um
XOR-join para fundir duas ou mais ramificações alternativas que podem ter sido anteriormente
Página 88
Fig. 3.4 Um exemplo do uso de gateways XOR
bifurcada com uma divisão XOR. Um gateway XOR é indicado com um losango vazio
ou com um diamante marcado com um “X”. De agora em diante, sempre usaremos o “X”
marcador.
Exemplo 3.2 Processo de verificação de faturas.
Assim que uma fatura é recebida de um cliente, é necessário verificar se há incompatibilidades.

A verificação pode resultar em uma destas três opções: i) não há incompatibilidades, nas quais
caso a fatura seja lançada; ii) existem incompatibilidades, mas podem ser corrigidas, nas quais
caso a fatura seja reenviada ao cliente; e iii) há incompatibilidades, mas não podem
ser corrigido, caso em que a fatura é bloqueada. Uma vez que uma dessas três atividades é
realizada a nota fiscal é estacionada e o processo é concluído.
Para modelar este processo, começamos com uma atividade de decisão, nomeadamente “Verificar fatura
para incompatibilidades ”após um evento inicial“ Fatura recebida ”. Uma atividade de decisão é
uma atividade que leva a resultados diferentes. Em nosso exemplo, esta atividade resulta
em três resultados possíveis, que são mutuamente exclusivos; então precisamos usar um
O XOR é dividido após essa atividade para dividir o fluxo em três ramos. Assim, três
fluxos de sequência emanarão deste gateway, um para a atividade "Pós-fatura",
realizada se não houver incompatibilidades, outra no sentido de “Reenviar fatura para
cliente ”, realizada se houver incompatibilidades, mas puderem ser corrigidas, e um terceiro fluxo
para "Bloquear fatura", realizado se houver incompatibilidades que não podem ser corrigidas
(ver Fig. 3.4 ). De uma perspectiva de token, uma divisão XOR roteia o token vindo de
sua ramificação de entrada para uma de suas ramificações de saída, ou seja, apenas uma de saída
ramo pode ser tomado.
Ao usar uma divisão XOR, certifique-se de que cada fluxo de sequência de saída seja anotado
com um rótulo que captura a condição em que aquele ramo específico é obtido. Mais-
over, sempre use condições mutuamente exclusivas, ou seja, apenas uma delas pode ser verdadeira
toda vez que a divisão XOR é alcançada por um token. Esta é a característica do
Gateway dividido em XOR. Em nosso exemplo, uma fatura pode estar correta ou conter erros
correspondências que podem ser corrigidas ou incompatibilidades que não podem ser corrigidas: apenas uma dessas
as condições são verdadeiras por fatura recebida.
Página 89
Na Fig. 3.4, o fluxo rotulado como "incompatibilidades existem, mas não podem ser corrigidas" está marcado
com um corte oblíquo. Esta notação é opcional e é usada para indicar o padrão
fluxo , ou seja, o fluxo que será levado pelo token proveniente da divisão XOR em
caso as condições associadas a todos os outros fluxos de saída sejam avaliadas como falsas. Desde a
este arco tem o significado de caso contrário , pode ser deixado sem rótulo. No entanto, nós altamente
recomendo ainda rotular este arco com uma condição para fins de legibilidade.
Uma vez que qualquer uma das três atividades alternativas tenha sido executada, nós mesclamos o
fluxo de volta para executar a atividade "fatura de parque" que é comum a todos os três
casos. Para isso, usamos um XOR-join. Este gateway particular atua como um passthrough ,
o que significa que ele espera um token chegar de um de seus arcos de entrada e assim que
ele recebe o token, ele envia o token para o arco de saída. Em outras palavras, com um
O XOR-join continua sempre que um branch de entrada é concluído.
Voltando ao nosso exemplo, completamos o modelo de processo com um evento final
“Fatura tratada”. Certifique-se de sempre completar um modelo de processo com uma extremidade
evento, mesmo que seja óbvio como o processo seria concluído.
Exercício 3.1 Modelar o seguinte fragmento de um processo de negócios para avaliar empréstimos
formulários.
Uma vez que um pedido de empréstimo tenha sido aprovado pelo provedor de empréstimo, um pacote de aceitação é
preparada e enviada ao cliente. O pacote de aceitação inclui um cronograma de reembolso
com o qual o cliente deve concordar, enviando os documentos assinados de volta para o empréstimo
fornecedor. Este, então, verifica o acordo de reembolso: se o requerente discordou
o cronograma de reembolso, o credor cancela o pedido; se o requerente concordou,
o provedor de empréstimo aprova o pedido. Em qualquer caso, o processo é concluído com o
credor notificando o requerente sobre o status do pedido.
3.2.2 Execução Paralela
Quando duas ou mais atividades não têm nenhuma dependência de ordem uma da outra
(ou seja, uma atividade não precisa seguir a outra, nem exclui a outra) eles
pode ser executado simultaneamente ou em paralelo . O gateway paralelo ( AND ) é usado para
modelar esta relação particular. Especificamente, usamos uma divisão AND para modelar o paralelo
execução de duas ou mais ramificações e uma junção AND para sincronizar a execução
de dois ou mais ramos paralelos. Um gateway AND é representado como um diamante com um
Marca “+”.
Exemplo 3.3 Verificação de segurança no aeroporto.

Assim que o cartão de embarque for recebido, os passageiros passam para a verificação de segurança. Aqui
eles precisam passar pela triagem de segurança pessoal e pela triagem de bagagem. Mais tarde,
eles podem prosseguir para o nível de partida.
Este processo consiste em quatro atividades. Começa com a atividade “Proceder à segurança
verifique ”e termina com a atividade“ Continuar para o nível de partida ”. Essas duas atividades
têm uma dependência de ordem clara: um passageiro só pode ir para o nível de embarque após
Página 90
Fig. 3.5 Um exemplo do uso de gateways AND
submetidos às verificações de segurança exigidas. Depois da primeira atividade e antes da última

um, precisamos realizar duas atividades que podem ser executadas em qualquer ordem, ou seja, quais
não dependem um do outro: “Passe na triagem de segurança pessoal” e “Passe bagagem
triagem". Para modelar esta situação, usamos uma atividade de link dividido AND “Continuar
para verificação de segurança "com as duas atividades de triagem, e um AND-join ligando o
duas atividades de triagem com a atividade “Prosseguir para o nível de partida” (ver Fig. 3.5 ).
A divisão AND divide o token proveniente da atividade “Prosseguir para a verificação de segurança”
em dois tokens. Cada um desses tokens flui independentemente por um dos dois
ramos. Isso significa que quando alcançamos uma divisão AND, pegamos todos os
ramos (observe que uma divisão AND pode ter vários arcos de saída). Como dissemos
antes, um token é usado para indicar o estado de uma determinada instância. Quando múltiplo para
kens da mesma cor são distribuídos em um modelo de processo, por exemplo, como resultado de
executando uma divisão AND, eles representam coletivamente o estado de uma instância. Para ex-
amplo, se um token estiver no arco, emitindo a partir da atividade "Passe na triagem de bagagem" e
outro token da mesma cor está no incidente do arco para a atividade “Passe pessoal
triagem de segurança ”, isso indica uma instância do processo de verificação de segurança onde
um passageiro acabou de passar pela triagem de bagagem, mas ainda não começou o pessoal
rastreio de segurança.
A junção AND do nosso exemplo espera que um token chegue de cada um dos dois
arcos de entrada e, quando todos estiverem disponíveis, ele mescla os tokens novamente em um.
O token único é então enviado para a atividade “Continuar para o nível de partida”. Isso significa que
prosseguimos quando todas as filiais de entrada foram concluídas (observe novamente que um AND-
junção pode ter vários arcos de entrada). Este comportamento de esperar por uma série de
tokens para chegar e depois mesclar os tokens em um é chamado de sincronização .
Exemplo 3.4 Vamos estender o exemplo de atendimento do pedido da Fig. 3.1 , assumindo
que um pedido de compra só é confirmado se o produto estiver em estoque, caso contrário, o pro-
cess é concluído rejeitando o pedido. Além disso, se o pedido for confirmado, o envio
endereço é recebido e o produto solicitado é enviado enquanto a fatura é emitida-
ted e o pagamento é recebido. Depois disso, o pedido é arquivado e o processo
completa.
O modelo resultante é mostrado na Fig. 3.6 . Deixe-nos fazer algumas observações. Primeiro,
este modelo tem duas atividades que são mutuamente exclusivas: “Confirmar pedido” e “Re-
Página 91
Fig. 3.6 Uma versão mais elaborada do diagrama do processo de atendimento do pedido
ordem exata ”, portanto, nós os precedemos com uma divisão XOR (lembre-se de colocar uma atividade
antes de uma divisão XOR para permitir que a decisão seja tomada, como uma verificação como esta
caso, ou uma aprovação). Em segundo lugar, as duas sequências “Obter endereço de envio” - “Enviar
produto ”e“ Emitir fatura ”-“ Receber pagamento ”pode ser realizado de forma independente
uns dos outros, então os colocamos em um bloco entre uma divisão AND e uma junção AND. No
Na verdade, esses dois conjuntos de atividades são normalmente tratados por diferentes recursos dentro
uma organização de vendedores, como um balconista de vendas para a remessa e um diretor financeiro para
a fatura e, portanto, pode ser executado em paralelo (observe a palavra "entretanto" no
descrição do processo, que indica que duas ou mais atividades podem ser realizadas em
o mesmo tempo).
Vamos comparar esta nova versão do processo de atendimento de pedidos com aquela em
Fig. 3.1 em termos de eventos. A nova versão apresenta dois eventos finais, enquanto o primeiro
versão apresenta um evento final. Em um modelo BPMN, podemos ter vários eventos finais,
cada um capturando um resultado diferente do processo (por exemplo, saldo pago vs. atraso
processado, pedido aprovado vs. pedido rejeitado). BPMN adota o chamado ter- implícito
semântica de minação , o que significa que uma instância de processo é concluída apenas quando cada uma
ken fluindo no modelo atinge um evento final. Da mesma forma, podemos ter vários
eventos em um modelo BPMN, cada evento capturando um gatilho diferente para iniciar um processo
instância. Por exemplo, podemos iniciar nosso processo de atendimento de pedidos quando um novo
o pedido de compra é recebido ou quando um pedido revisado é reenviado. Se um pedido revisado
for reenviado, primeiro recuperamos os detalhes do pedido do banco de dados de pedidos e, em seguida,
continue com o resto do processo. Esta variante do modelo de atendimento do pedido é
mostrado na Fig. 3.7 . Uma instância deste modelo de processo é acionada pelo primeiro evento
que ocorre (observe o uso de uma junção XOR para mesclar os ramos vindos do
dois eventos iniciais).
formulários.
Um pedido de empréstimo é aprovado se passar por duas verificações: (i) a avaliação de risco de empréstimo do requerente-
avaliação, feita automaticamente por um sistema, e (ii) a avaliação da propriedade para a qual o
foi solicitado um empréstimo, realizado por um avaliador imobiliário. A avaliação de risco requer um
Página 92
Fig. 3.7 Uma variante do processo de atendimento do pedido com dois gatilhos diferentes
verificação do histórico de crédito do requerente, realizada por um diretor financeiro. Uma vez que ambos
a avaliação do risco do empréstimo e a avaliação da propriedade foram realizadas, um oficial de crédito pode
avaliar a elegibilidade do candidato. Se o candidato não for elegível, o pedido é rejeitado,
caso contrário, o pacote de aceitação é preparado e enviado ao requerente.
Existem duas situações em que um gateway pode ser omitido. Um XOR-join pode ser
omitido antes de uma atividade ou evento. Neste caso, os arcos de entrada para o XOR-join
estão diretamente conectados à atividade / evento. Um exemplo desta notação abreviada
é mostrado na Fig. 1.6 , onde há dois arcos incidentes para a atividade “Selecionar adequado
equipamento". Uma divisão AND também pode ser omitida quando segue uma atividade ou evento.
Neste caso, os arcos de saída da divisão AND emanam diretamente do ativo
ity / event.
3.2.3 Decisões Inclusivas
Às vezes, podemos precisar tomar um ou mais ramos após uma atividade de decisão.
Considere o seguinte processo de negócios.
Exemplo 3.5 Processo de distribuição de pedidos.

Uma empresa possui dois depósitos que armazenam produtos diferentes: Amsterdã e Hamburgo.
Quando um pedido é recebido, ele é distribuído entre esses depósitos: se algum dos
os produtos são mantidos em Amsterdã, um pedido secundário é enviado para lá; da mesma forma, se algum relevante
os produtos são mantidos em Hamburgo, um pedido secundário é enviado para lá. Depois, o pedido é
registrado e o processo é concluído.
Podemos modelar o cenário acima usando uma combinação de AND e porta XOR
maneiras? A resposta é sim. No entanto, existem alguns problemas. Figuras 3.8 e 3.9
mostram duas soluções possíveis. No primeiro, usamos um XOR-split com três alter-
ramos nativos: um obtido se o pedido contiver apenas produtos de Amsterdã (onde
o sub-pedido é encaminhado para o depósito de Amsterdã), outro levado se o pedido
contém apenas produtos de Hamburgo (da mesma forma, neste ramo o pedido secundário é encaminhado
Página 93
Fig. 3.8 Modelando uma decisão inclusiva: primeiro ensaio
Fig. 3.9 Modelando uma decisão inclusiva: segundo ensaio
para o armazém de Hamburgo), e uma terceira filial a ser tomada no caso de o pedido con
contém produtos de ambos os armazéns (neste caso, os pedidos secundários são encaminhados para
ambos os armazéns). Esses três ramos convergem em uma junção XOR que leva a
o registo da encomenda.
Embora este modelo capture nosso cenário corretamente, o diagrama resultante é
o que é complicado, já que precisamos duplicar as duas atividades que encaminham
encomendas aos respectivos armazéns duas vezes. E se tivéssemos mais de dois armazéns,
o número de atividades duplicadas aumentaria. Por exemplo, se tivéssemos três
armazéns, precisaríamos de um XOR-split com sete filiais de saída, e cada
a atividade precisaria ser duplicada quatro vezes. Claramente, esta solução não é escala
capaz.
Página 94
Fig. 3.10 Modelando uma decisão inclusiva com o gateway OR
Na segunda solução, usamos uma divisão AND com dois arcos de saída, cada
dos quais leva a uma divisão XOR com duas ramificações alternativas. Um está ocupado
se o pedido contém produtos de Amsterdã (Hamburgo), caso em que um ac-
a atividade é executada para encaminhar o sub-pedido para o respectivo armazém; a
outra filial é tomada se o pedido não contiver Amsterdam (Hamburgo)
produtos, caso em que nada é feito até o XOR-join, que funde
os dois ramos de volta. Em seguida, uma junção AND mescla os dois ramos paralelos
saindo da divisão AND e o processo é concluído registrando o ou-
der.
Qual é o problema com esta segunda solução? O cenário de exemplo permite
três casos: os produtos estão apenas em Amsterdã, apenas em Hamburgo ou em ambos os armazéns
casas, enquanto esta solução permite mais um caso, ou seja, quando os produtos estão em
nenhum dos armazéns. Este caso ocorre quando os dois ramos vazios do
duas divisões XOR são tomadas e resulta em não fazer nada entre a atividade "Verificar ou
itens de linha ”e atividade“ Registrar pedido ”. Daí esta solução, apesar de ser mais
compacto do que o primeiro, está errado.
Para modelar situações onde uma decisão pode levar a uma ou mais opções ser-
tomadas ao mesmo tempo, precisamos usar um gateway dividido inclusivo ( OR ) . A
A divisão OR é semelhante à divisão XOR, mas as condições em seus ramos de saída
não precisam ser mutuamente exclusivos, ou seja, mais de um deles pode ser verdadeiro
ao mesmo tempo. Quando encontramos uma divisão OR, pegamos um ou mais
ramos dependendo de quais condições são verdadeiras. Em termos de semântica de token
tiques, isso significa que a divisão OR pega o token de entrada e gera um número
número de tokens equivalentes ao número de condições de saída verdadeiras, onde
este número pode ser pelo menos um e no máximo como o número total de saídas
ramos. Semelhante ao gateway XOR-split, um OR-split também pode ser equipado
com um fluxo padrão, que é obtido apenas quando todas as outras condições avaliam
falso.
A Figura 3.10 mostra a solução para nosso exemplo usando o gateway OR. Depois de
o sub-pedido foi encaminhado para qualquer um dos dois armazéns ou para ambos, usamos
uma junção OR para sincronizar o fluxo e continuar com o registro do pedido.
Uma junção OR continua quando todas as ramificações de entrada ativas forem concluídas. Esperando
para um ramal ativo significa esperar por um ramal de entrada que acabará destruindo
Página 95
Fig. 3.11 Que tipo o gateway de junção deve ter para que as instâncias deste processo possam ser concluídas
corretamente?
fígado um token para a junção OR. Se a ramificação estiver ativa, a junção OR irá esperar por isso
token, caso contrário, não. Depois que todos os tokens de ramos ativos chegaram, o
A junção OR sincroniza esses tokens em um (semelhante ao que uma junção AND faz)
e envia esse token para seu arco de saída. Chamamos esse comportamento de sincronização de mesclagem
em oposição à simples mesclagem do XOR-join e à sincronização do
AND-join.
Vamos nos aprofundar no conceito de ramo ativo. Considere o modelo na Fig. 3.11 ,
que apresenta um gateway de junção com tipo indefinido (aquele acinzentado com uma pergunta
marca de indicação). Que tipo devemos atribuir a esta junção? Vamos tentar uma junção AND para
corresponder à divisão AND anterior. Lembramos que uma junção AND aguarda um token para ar-
rive de cada filial de entrada. Enquanto o token da filial com atividade “C”
sempre chegará, o token da filial com atividades "B" e "D" não pode
chegam se forem roteados para “E” pelo XOR-split. Portanto, se a atividade "D" não for executada,
a junção AND esperará indefinidamente por esse token, com a consequência de que o
a instância do processo não poderá progredir mais. Esta anomalia comportamental
é chamado de deadlock e deve ser evitado.
Vamos tentar um XOR-join. Lembramos que o XOR-join funciona como um passthrough
encaminhando para sua ramificação de saída cada token que chega por meio de um de seus
ramos. Em nosso exemplo, isso significa que podemos executar a atividade "F" uma ou duas vezes,
dependendo se a divisão XOR anterior direciona o token para "E" (neste caso, "F"
é executado uma vez) ou para “D” (“F” é executado duas vezes). Embora esta solução possa funcionar,
temos o problema de não saber se a atividade "F" será executada
uma ou duas vezes, e talvez não queiramos executá-lo duas vezes. Além disso, se este
é o caso, sinalizaríamos que o processo foi concluído duas vezes, já que o final
o evento seguinte a “F” receberá dois tokens. E isso, novamente, é algo que queremos
evitar.
Página 96
O único tipo de junção que falta tentar é a junção OR. Uma junção OR irá esperar por todos os
ramos ativos para concluir. Se as rotas XOR-split controlam para “E”, a junção OR irá
não espere por um token da atividade de rolamento de ramificação “D”, pois isso nunca chegará.
Portanto, ele continuará assim que o token da atividade “C” chegar. Por outro lado, se
as rotas XOR-split controlam para “D”, a junção OR irá esperar que um token também chegue
deste ramo, e uma vez que os dois tokens chegaram, ele irá mesclá-los em um e
envie este token, para que "F" possa ser executado uma vez e o processo possa ser concluído
normalmente.
Pergunta Quando devemos usar uma junção OR?
Uma vez que a semântica de junção OR não é simples, a presença deste elemento em um
modelo pode confundir o leitor. Assim, sugerimos usá-lo apenas quando for estritamente
requeridos. Claramente, é fácil ver que uma junção OR deve ser usada sempre que precisarmos
para sincronizar o controle de uma divisão OR anterior. Da mesma forma, devemos usar um AND-
junte para sincronizar o controle de uma divisão AND anterior e uma junção XOR para mesclar
um conjunto de ramificações que são mutuamente exclusivas. Em outros casos, o modelo não terá
uma estrutura enxuta como os exemplos na Fig. 3.8 ou 3.10 , onde o modelo é composto de
blocos aninhados, cada um delimitado por uma divisão e uma junção do mesmo tipo. O modelo pode
em vez disso, parecido com o da Fig. 3.11 , onde pode haver pontos de entrada ou existem pontos
de uma estrutura de bloco. Nestes casos, jogue o jogo do token para entender o correto
tipo de junção. Comece com uma junção XOR; em seguida, tente uma junção AND e se ambos os gateways liderarem
para modelos incorretos use a junção OR que funcionará com certeza.
Agora que aprendemos os três principais gateways, vamos usá-los para estender
o processo de atendimento do pedido. Suponha que se o produto não estiver em estoque, ele pode ser
fabricado. Desta forma, um pedido nunca pode ser rejeitado.
Exemplo 3.6
Se o produto solicitado não estiver em estoque, ele precisa ser fabricado antes do processamento do pedido
pode continuar. Para fabricar um produto, as matérias-primas necessárias devem ser solicitadas. Dois
fornecedores preferidos fornecem diferentes tipos de matéria-prima. Dependendo do produto para
ser fabricados, as matérias-primas podem ser encomendadas do Fornecedor 1 ou do Fornecedor 2, ou
de ambos. Assim que as matérias-primas estiverem disponíveis, o produto pode ser fabricado e o
pedido pode ser confirmado. Por outro lado, se o produto estiver em estoque, ele é recuperado do
armazém antes de confirmar o pedido. Então, o processo continua normalmente.
O modelo para este processo de atendimento de pedido estendido é mostrado na Fig. 3.12 .
formulários.
Um pedido de empréstimo pode ser acoplado a um seguro residencial que é oferecido com desconto
preços. O requerente pode expressar seu interesse em um plano de seguro residencial no momento de
submeter seu pedido de empréstimo ao credor. Com base nessas informações, se o
pedido de empréstimo for aprovado, o provedor de empréstimo pode apenas enviar um pacote de aceitação
ao requerente, ou envie também uma cotação de seguro residencial. O processo então continua com o
verificação do acordo de reembolso.
Página 97
Fig. 3.12 O diagrama do processo de atendimento do pedido com a fabricação do produto
3.2.4 Retrabalho e Repetição
Até agora vimos estruturas que são lineares, ou seja, cada atividade é realizada no máximo
uma vez. No entanto, às vezes podemos exigir a repetição de uma ou várias atividades, para
instância devido a uma falha na verificação.
Exemplo 3.7
No gabinete do ministro da Fazenda, uma vez recebido um inquérito ministerial, é o primeiro

registrado no sistema. Em seguida, o inquérito é investigado para que uma resposta ministerial
pode ser preparado. A finalização de uma resposta inclui a preparação da resposta
pelo oficial de gabinete e a revisão da resposta pelo registrador principal. Se o
o registrador não aprova a resposta, esta última precisa ser preparada novamente pelo gabinete
oficial para revisão. O processo termina apenas quando a resposta é aprovada.
Para modelar retrabalho ou repetição, primeiro precisamos identificar as atividades, ou mais

em geral o fragmento do processo, que pode ser repetido. Em nosso exemplo este
consiste na sequência de atividades “Preparar a resposta ministerial” e “Rever
resposta ministerial ”. Chamemos isso de nosso bloco de repetição . A propriedade de uma repetição
bloco de decisão é que a última de suas atividades deve ser uma atividade de decisão. Na verdade, isso vai
nos permitem decidir se devemos voltar antes do início do bloco de repetição, de modo que este
pode ser repetido ou para continuar com o resto do processo. Como tal, esta decisão
atividade deve ter dois resultados. Em nosso exemplo, a atividade de decisão é “Revisar
resposta ministerial ”e seus resultados são:“ resposta aprovada ”(neste caso, nós
continuar com o processo) e “resposta não aprovada” (voltamos). Modelar
esses dois resultados, usamos uma divisão XOR com dois ramos de saída: um que
nos permite continuar com o resto do processo (em nosso exemplo, isso é simplesmente
Página 98
Fig. 3.13 Um modelo de processo para lidar com correspondência ministerial
o evento final "correspondência ministerial endereçada"), o outro que volta

antes da atividade “Preparar a resposta ministerial”. Usamos um XOR-join para reconectar
esta ramificação para o ponto do modelo de processo imediatamente antes do bloco de repetição. o
modelo para nosso exemplo é ilustrado na Fig. 3.13 .
Questão Por que precisamos mesclar o ramo de loopback de um bloco de repetição com
um XOR-join?
A razão para usar um XOR-join é que este gateway tem uma semântica muito simples
tiques: ele move qualquer token que recebe em seu arco de entrada para seu arco de saída, que é o que
precisamos neste caso. Na verdade, se fundíssemos o branch de loopback com o resto do
modelo usando uma junção AND, entraríamos em conflito, uma vez que este gateway tentaria sincronizar
cronizar os dois ramos de entrada quando sabemos que apenas um deles pode ser
ativo por vez: se estivéssemos em loop, receberíamos o token do loopback
ramo; caso contrário, receberíamos de outro ramo, indicando que estamos
entrar no bloco de repetição pela primeira vez. Uma junção OR funcionaria, mas é um
exagero, pois sabemos que apenas um ramo estará ativo por vez.
formulários.
Uma vez que um pedido de empréstimo é recebido pelo provedor de empréstimo, e antes de prosseguir com sua
avaliação, o próprio aplicativo precisa ser verificado quanto à integridade. Se o aplicativo for
incompleto, ele é devolvido ao requerente, para que ele possa preencher as informações em falta
e envie-o de volta para o provedor de empréstimo. Este processo é repetido até que o aplicativo seja encontrado
completo.
Aprendemos como combinar atividades, eventos e gateways para modelar o básico

processos de negócios. Para cada um desses elementos, mostramos sua representação gráfica
ção, as regras para combiná-lo com outros elementos de modelagem e explicou seu
comportamento em termos de regras de token. Todos esses aspectos se enquadram no termo componentes de
uma linguagem de modelagem . Se você quiser saber mais sobre este tópico, você pode ler o
box “Componentes de uma linguagem de modelagem”.
COMPONENTES DE UMA LINGUAGEM DE MODELAGEM

Uma linguagem de modelagem consiste em três partes: sintaxe, semântica e notação.
A sintaxe fornece um conjunto de elementos de modelagem e um conjunto de regras para governar
Página 99
3.3 Artefatos de informação 79
como esses elementos podem ser combinados. A semântica vincula o elemento sintático
mentos e suas descrições textuais para um significado preciso. A notação define
um conjunto de símbolos gráficos para a visualização dos elementos.
Por exemplo, a sintaxe BPMN inclui atividades, eventos, gateways e
fluxos de sequência. Um exemplo de regra sintática é que os eventos de início têm apenas
fluxos de sequência de saída, enquanto eventos finais só têm sequência de entrada
fluxos. A semântica BPMN descreve que tipo de comportamento é representado
pelos vários elementos. Em essência, isso se relaciona com a questão de como o elemento
mentos podem ser executados em termos de fluxo de token. Por exemplo, uma junção AND tem
esperar que todas as ramificações de entrada sejam concluídas antes de passar o controle para seu
filial de saída. Um exemplo de notação BPMN é o uso de rotulados arredondados
caixas para representar atividades.
3.3 Artefatos de informação
Conforme mostrado no cap. 2 , um processo de negócios envolve diferentes aspectos organizacionais

como funções, artefatos de negócios, humanos e sistemas de software. Esses aspectos
são capturados por diferentes perspectivas de modelagem de processos. Até agora vimos o
perspectiva funcional , que indica quais atividades devem acontecer no pro-
e a perspectiva do fluxo de controle , que indica quando as atividades e eventos
deve ocorrer. Outra perspectiva importante que devemos considerar ao modelar
processos de negócios é a perspectiva dos dados . A perspectiva dos dados indica qual
artefatos de informação (por exemplo, documentos de negócios, arquivos) são necessários para realizar um ac-
atividade e quais são produzidos como resultado da realização de uma atividade.
Vamos enriquecer o processo de atendimento do pedido do Exemplo 3.6 com artefatos. Deixe-nos
comece identificando os artefatos que cada atividade requer para ser executada,
e aqueles que cada atividade cria como resultado de sua execução. Por exemplo, o primeiro
A atividade do processo de atendimento do pedido é “Verificar disponibilidade de estoque”. Isto exige
um pedido de compra como entrada, a fim de verificar se o produto pedido é ou não
em estoque. Este artefato também é exigido pela atividade "Verificar disponibilidade de matéria-prima"
caso o produto seja fabricado. Artefatos como pedido de compra são chamados de dados
objetos em BPMN. Objetos de dados representam informações que entram e saem da atividade
laços; eles podem ser artefatos físicos, como uma fatura ou uma carta em um pedaço de papel,
ou artefatos eletrônicos, como um e-mail ou um arquivo. Nós os descrevemos como um documento com
o canto superior direito dobrado e vinculá-los às atividades com uma seta pontilhada
com uma ponta de seta aberta (chamada de associação de dados em BPMN). A Figura 3.14 mostra o
objetos de dados envolvidos no modelo de processo de atendimento do pedido.
Usamos a direção da associação de dados para estabelecer se um objeto de dados é
uma entrada ou saída para uma determinada atividade. Uma associação de entrada, como a usada
do pedido de compra à atividade "Verificar disponibilidade de estoque", indica que a compra
pedido é um objeto de entrada para esta atividade; uma associação de saída, como a usada
Página 100
Fig. 3.14 O exemplo de atendimento de pedido com artefatos
da atividade "Obter matérias-primas do Fornecedor 1" para Matérias-primas, indica

que a matéria-prima é um objeto de saída para esta atividade. Para evitar bagunçar o dia-
grama com associações de dados que cruzam fluxos de sequência, podemos repetir um objeto de dados
várias vezes no mesmo modelo de processo. No entanto, todas as ocorrências de um determinado
objeto se referem conceitualmente ao mesmo artefato. Por exemplo, na Fig. 3.14 Compra
o pedido é repetido duas vezes como entrada para “Verificar disponibilidade de estoque” e “Confirmar pedido”
já que essas duas atividades estão distantes uma da outra em termos de layout de modelo.
Freqüentemente, a saída de uma atividade coincide com a entrada para uma atividade subsequente.
Por exemplo, uma vez que as matérias-primas foram obtidas, estas são usadas pela atividade
“Fabrique o produto” para criar um Produto. O Produto, por sua vez, é embalado e
enviado ao cliente pela atividade “Enviar produto”. Efetivamente, os objetos de dados nos permitem
para modelar o fluxo de informações entre as atividades do processo. Tenha em mente, no entanto,
que os objetos de dados e suas associações com atividades não podem substituir a sequência
fluxo. Em outras palavras, mesmo que um objeto seja passado de uma atividade A para uma atividade B,
ainda precisamos modelar o fluxo de sequência de A para B. Uma notação abreviada para
passar um objeto de uma atividade para outra é conectar diretamente os dados
objeto ao fluxo de sequência entre duas atividades consecutivas por meio de um
Associação. Veja, por exemplo, o endereço de envio que está sendo passado da atividade “Get
Página 101
3.3 Artefatos de informação 81
endereço de remessa ”para a atividade“ Enviar produto ”, que é uma abreviatura para indicar
esse endereço de remessa é uma saída de "Obter endereço de remessa" e uma entrada para "Enviar
produtos".
Às vezes, podemos precisar representar o estado de um objeto de dados. Por exemplo,
a atividade “Confirmar pedido” pega um pedido de compra como entrada e retorna um “confirmado”
Pedido de compra como saída: objetos de entrada e saída são os mesmos, mas o objeto
o estado mudou para “confirmado”. Da mesma forma, a atividade “Receber pagamento” assume como
insira um pedido de compra “confirmado” e o transforma em um pedido de compra “pago”.
Um objeto pode passar por vários estados, por exemplo, uma fatura é primeiro "aberta", depois
“Aprovado” ou “rejeitado” e finalmente “arquivado”. Indicar os estados dos objetos de dados é
opcional: podemos fazer isso acrescentando o nome do estado entre colchetes
ao rótulo de um objeto de dados, por exemplo, “Pedido de compra [confirmado]”, “Produto [embalado]”.
Um armazenamento de dados é um local que contém objetos de dados que precisam ser persistidos além
a duração de uma instância de processo, por exemplo, um banco de dados para artefatos eletrônicos ou um arquivo
armário de montagem para físicos. Atividades de processo podem ler / escrever objetos de dados de / para
armazenamentos de dados. Por exemplo, a atividade "Verificar disponibilidade de estoque" recupera o nível de estoque
els para o produto pedido do banco de dados do armazém, que contém estoque
informações de nível para os vários Produtos. Da mesma forma, a atividade “Verificar matérias-primas
disponibilidade ”consulta o catálogo de fornecedores para verificar qual fornecedor entrar em contato. o
O banco de dados do armazém ou o catálogo do fornecedor são exemplos de armazenamentos de dados usados como entrada
às atividades. Um exemplo de armazenamento de dados empregado como saída é o banco de dados de Pedidos,
que é usado pela atividade “Pedido de arquivamento” para armazenar o pedido de compra confirmado. No
desta forma, o pedido recém-arquivado estará disponível para outros processos de negócios dentro
a mesma organização, por exemplo, para um processo de negócios que lida com solicitações de produtos
uct retorna. Os armazenamentos de dados são representados como um cilindro vazio (o banco de dados típico
símbolo) com uma borda superior tripla. Semelhante a objetos de dados, eles estão conectados a
atividades por meio de associações de dados.
Pergunta Os objetos de dados afetam o fluxo do token?
Os objetos de dados de entrada são necessários para que uma atividade seja executada. Mesmo se um token
está disponível no arco de entrada dessa atividade, o último não pode ser executado até
todos os objetos de dados de entrada também estão disponíveis. Um objeto de dados está disponível se tiver sido
criado como resultado da conclusão de uma atividade anterior (cuja saída foram os dados
objeto em si), ou porque é uma entrada para todo o processo (como pedido de compra).
Os objetos de dados de saída afetam apenas o fluxo do token indiretamente, ou seja, quando são usados por
atividades subsequentes.
Pergunta Sempre precisamos modelar objetos de dados?
Objetos de dados ajudam o leitor a entender o fluxo de dados de negócios de um ativo

para o outro. No entanto, o preço a pagar é um aumento da complexidade do diagrama.
Assim, sugerimos usá-los apenas quando forem necessários para uma finalidade específica, por exemplo
para destacar os problemas potenciais no processo em análise (cf. Capítulos 6 e 7 ) ou para
automação (cf. Cap. 9 ).
Página 102
Às vezes, podemos precisar fornecer informações adicionais para o modelo de processo

leitor, com o objetivo de melhorar a compreensão do modelo. Por exemplo, em
o processo de atendimento do pedido, podemos especificar essa atividade "Enviar produto"
inclui a embalagem do produto. Além disso, podemos esclarecer qual negócio
regra é seguida na escolha das matérias-primas dos fornecedores. Tão adicional
as informações podem ser fornecidas por meio de anotações de texto . Uma anotação é descrita como um
retângulo aberto que encapsula o texto da anotação e está vinculado a um
elemento de modelagem de processo por meio de uma linha pontilhada (chamada de associação ) - consulte a Fig. 3.14 para
um exemplo. As anotações de texto não têm semântica, portanto, não afetam o
fluxo de tokens através do modelo de processo.
Exercício 3.5 Junte os quatro fragmentos do processo de avaliação do empréstimo que

você criou nos Exercícios 3.1 - 3.4 .
Dica Observe os rótulos dos eventos de início / fim para entender as dependências do pedido
entre os vários fragmentos. Em seguida, estenda o modelo resultante adicionando todos os
artefatos necessários. Além disso, anexe anotações para especificar as regras de negócios por trás
(i) verificar a integridade de um aplicativo, (ii) avaliar a elegibilidade de um aplicativo,
e (iii) verificar um acordo de reembolso.
3.4 Recursos
Um outro aspecto que precisamos considerar na modelagem de processos de negócios é a re-

perspectiva da fonte . Essa perspectiva, também chamada de perspectiva organizacional ,
dica quem ou o que executa cada atividade. Recurso é um termo genérico para se referir a
qualquer pessoa ou coisa envolvida no desempenho de uma atividade de processo. Um recurso
pode ser:
• Um participante do processo , ou seja, um indivíduo como o funcionário John Smith.

• Um sistema de software , por exemplo, um servidor ou aplicativo de software.
• Um equipamento , como uma impressora ou uma fábrica.
Podemos distinguir entre recursos ativos , ou seja, recursos que podem de forma autônoma
executar uma atividade e recursos passivos , ou seja, recursos que estão apenas envolvidos em
o desempenho de uma atividade. Por exemplo, uma fotocopiadora é usada por um participante para
fazer uma cópia de um documento, mas é o participante que faz a fotocópia
atividade. Assim, a fotocopiadora é um recurso passivo enquanto o participante é um ativo
recurso. Um bulldozer é outro exemplo de recurso passivo, pois é o driver
quem executa a atividade em que o bulldozer é usado.
A perspectiva de recursos de um processo está interessada em recursos ativos, portanto, de
agora com o termo “recurso” nos referimos a um “recurso ativo”.
Freqüentemente, em um modelo de processo, não nos referimos explicitamente a um recurso em um
tempo, como por exemplo um funcionário John Smith, mas em vez disso nos referimos a um grupo de
recursos que são intercambiáveis no sentido de que qualquer membro do grupo pode
Página 103
3.4 Recursos 83
executar uma determinada atividade. Esses grupos são chamados de classes de recursos . Os exemplos são um
toda a organização, uma unidade organizacional ou uma função. 1
Vamos examinar os recursos envolvidos em nosso exemplo de atendimento de pedidos.
Exemplo 3.8
O processo de atendimento do pedido é realizado por uma organização do vendedor que inclui dois
partments: o departamento de vendas e o departamento de armazém e distribuição. A compra
o pedido recebido pelo depósito e distribuição é verificado em relação ao estoque. Esta operação é
realizado automaticamente pelo sistema ERP de armazém e distribuição, que consulta
o banco de dados do warehouse. Se o produto estiver em estoque, ele é recuperado do depósito antes de
antes de as vendas confirmarem o pedido. As próximas vendas emitem uma nota fiscal e aguardam o pagamento, enquanto o
o produto é despachado de dentro do armazém e distribuição. O processo é concluído com o
arquivamento de pedidos no departamento de vendas. Se o produto não estiver em estoque, o sistema ERP dentro
armazém e distribuição verifica a disponibilidade de matérias-primas acessando os fornecedores
Catálogo. Assim que as matérias-primas forem obtidas, o departamento de armazém e distribuição
mento cuida da fabricação do produto. O processo termina com a compra
pedido sendo confirmado e arquivado pelo departamento de vendas.
O BPMN fornece duas construções para modelar aspectos de recursos: pools e pistas . Piscinas
são geralmente usados para modelar classes de recursos, as pistas são usadas para particionar um pool em
subclasses ou recursos únicos. Não há restrições quanto a qual recurso específico
digite uma piscina ou uma pista deve modelar. Normalmente, usaríamos um pool para modelar uma empresa
festa ness como uma organização inteira, como o vendedor em nosso exemplo, e uma pista
modelar um departamento, unidade, equipe ou sistema / equipamento de software dentro dessa organização
nização. Em nosso exemplo, dividimos o pool de vendedores em duas pistas: uma para o
armazém e departamento de distribuição, o outro para o departamento de vendas.
As pistas podem ser aninhadas umas nas outras em vários níveis. Por exemplo, se nós
precisamos modelar um departamento e as funções dentro desse departamento, podemos usar
uma pista externa para o departamento e uma pista interna para cada função. Na ordem
exemplo de atendimento, aninhamos uma via dentro do Armazém e Distribuição para representar
sistema ERP dentro desse departamento.
Poças e pistas são representadas como retângulos dentro dos quais podemos colocar atividades,
eventos, gateways e objetos de dados. Normalmente, modelamos esses retângulos horizontais
, embora modelá-los verticalmente também seja possível. O nome da piscina / pista
é mostrado verticalmente no lado esquerdo de um retângulo horizontal (ou horizontalmente se
a piscina / pista é vertical); para pools e para pistas contendo pistas aninhadas, o nome
está incluído em uma faixa. A Figura 3.15 mostra o exemplo revisado de atendimento do pedido com
aspectos de recursos.
É importante colocar uma atividade na pista certa. Por exemplo, colocamos
atividade "Verificar disponibilidade de estoque" na faixa do Sistema ERP do Armazém e
Distribuição para indicar que esta atividade é realizada automaticamente pelo ERP
sistema desse departamento. Também é importante colocar os eventos corretamente nas pistas.
Em nosso exemplo, colocamos o evento "Pedido de compra recebido" na via do sistema ERP para
indicam que o processo começa dentro do sistema ERP de Armazém e Distribuição,
1 Em BPMN, o termo "participante" é usado em um sentido amplo como sinônimo de classe de recurso, embora
neste livro, não adotamos essa definição.
Página 104
Fig. 3.15 O exemplo de atendimento do pedido com informações de recursos
Página 105
3.4 Recursos 85
enquanto colocamos o evento "Pedido atendido" no pool de vendas para indicar que o processo
conclui no departamento de vendas. Não é relevante onde os objetos de dados são colocados, como
eles dependem das atividades às quais estão vinculados. De acordo com os gateways, precisamos colocar
aqueles que modelam (X) divisões OR sob a mesma pista que a atividade de decisão anterior
foi colocado. Por outro lado, é irrelevante onde colocamos uma divisão AND
e todos se unem a gateways, uma vez que esses elementos são passivos no sentido de que se comportam
de acordo com seu contexto.
Podemos organizar pistas dentro de um pool em uma matriz quando precisamos modelar com-
estruturas organizacionais complexas. Por exemplo, se tivermos uma organização onde funções
abrangem diferentes departamentos, podemos usar faixas horizontais para modelar os vários de-
partments e faixas verticais para modelar as funções dentro desses departamentos. Suportar
lembre-se, entretanto, que no BPMN cada atividade pode ser realizada por apenas um recurso.
Assim, se uma atividade fica na interseção de uma pista horizontal com uma pista vertical,
será realizada pelo recurso que atenda às características de ambas as pistas, por exemplo
um recurso que tem essa função e pertence a esse departamento.
Exercício 3.6 Estenda o processo de negócios para avaliar os pedidos de empréstimo que você
criado no Exercício 3.5 , considerando os seguintes aspectos de recursos.
O processo de avaliação dos pedidos de empréstimo é executado por quatro funções dentro do empréstimo
provedor: um diretor financeiro se encarrega de verificar o histórico de crédito do requerente; um adereço-
avaliador erty é responsável por avaliar a propriedade; um representante de vendas de seguros
envia a cotação de seguro residencial para o requerente, se necessário. Todas as outras atividades são
realizada pelo oficial de crédito, que é o principal ponto de contato com o requerente.
Freqüentemente, há mais de uma empresa participando da mesma empresa

processo. Por exemplo, no processo de atendimento do pedido, existem quatro partes: o
vendedor, o cliente e os dois fornecedores.
Cada parte pode ser modelada por uma piscina. Em nosso exemplo, podemos usar um pool
para o cliente, um para o vendedor e um para cada fornecedor. Cada uma dessas piscinas
conterá as atividades, eventos, gateways e objetos de dados que modelam o
parte do processo de negócios que ocorre nessa organização. Ou, colocando de outra forma,
cada pool modelará o mesmo processo de negócios da perspectiva de um
organização. Por exemplo, o evento “Pedido de compra recebido” que fica no setor de Vendas
pool, terá uma atividade correspondente "Enviar pedido de compra" ocorrendo no
Pool de clientes. Da mesma forma, a atividade "Enviar produto" de Vendas terá um contador
atividade parcial “Receber produto” no pool de clientes. Então, como podemos modelar o
interações entre os pools de duas organizações colaboradoras? Não podemos usar o
fluxo de sequência para conectar atividades que pertencem a pools diferentes desde a sequência
o fluxo não pode cruzar os limites de uma piscina. Para isso, precisamos usar um elemento específico
chamado fluxo de mensagens .
Um fluxo de mensagens representa o fluxo de informações entre dois recursos separados
aulas (piscinas). É representado como uma linha tracejada que começa com um círculo vazio
e termina com uma ponta de seta vazia, e traz uma etiqueta indicando o conteúdo do
mensagem, por exemplo, um fax, um pedido de compra, mas também uma carta ou um telefonema. Ou seja, o
Página 106
o fluxo de mensagens modela qualquer tipo de comunicação entre duas organizações, não
importa se é eletrônico, como enviar um pedido de compra por e-mail ou transmitir um
fax ou manual, como fazer uma ligação ou entregar uma carta em papel.
A Figura 3.16 mostra o modelo completo do processo de atendimento do pedido, incluindo o
pools para o cliente e os dois fornecedores. Aqui podemos ver que o fluxo de mensagens
são etiquetados com a informação que carregam, por exemplo, "Matérias-primas" ou "Enviar-
endereço ”. Um fluxo de mensagem de entrada pode levar à criação de um objeto de dados
jeto pela atividade que recebe a mensagem. Por exemplo, o fluxo de mensagens “Raw
materiais ”é recebido pela atividade“ Obter matérias-primas do Fornecedor 1 ”que
em seguida, cria o objeto de dados “Matérias-primas”. Este também é o caso da compra
pedido, que é gerado pelo evento inicial "Pedido de compra recebido" do
conteúdo do fluxo de mensagens recebidas. Não precisamos criar um objeto de dados para
cada fluxo de mensagem de entrada, apenas quando as informações transportadas pela mensagem são
necessário em outra parte do processo. Em nosso caso, "Matérias-primas" é consumido por ac-
atividade “Produto de fabricação”, portanto, precisamos representá-lo como um objeto de dados. Similarmente,
não precisamos representar explicitamente o objeto de dados que entra em uma saída
mensagem se este objeto de dados não for necessário em outro lugar no processo. Por exemplo, ac-
atividade “Emitir fatura” gera uma fatura que é enviada ao cliente, mas lá
não é um objeto de dados “Fatura” uma vez que esta não é consumida por qualquer atividade no Vendedor
piscina.
Um diagrama BPMN que apresenta dois ou mais pools é chamado de dia de colaboração
grama . A Figura 3.16 mostra diferentes usos de um pool em um diagrama de colaboração. Uma piscina
assim para o vendedor é chamado de processo privado , ou white box pool, uma vez que mostra
a eficácia com que a organização vendedora participa do processo de atendimento do pedido
em termos de atividades, eventos, gateways e objetos de dados. Pelo contrário, uma piscina
assim para o cliente e os dois fornecedores é chamado de processo público , ou preto
box pool, uma vez que esconde como essas organizações realmente participam do pedido
processo de atendimento. Para economizar espaço, podemos representar uma caixa preta com um
piscina em colapso , que é um retângulo vazio com o nome da piscina no
meio.
Pergunta Caixa preta ou caixa branca?
Modelar uma piscina como caixa branca ou caixa preta é uma questão de relevância. Quando
trabalhando em um diagrama de colaboração, uma organização pode decidir se ou não
para expor seu comportamento interno, dependendo dos requisitos do projeto em
mão. Por exemplo, se estivermos modelando o processo de atendimento do pedido do vendedor
perspectiva, pode ser relevante expor o processo de negócios do vendedor apenas,
mas não do cliente e dos fornecedores. Ou seja, o comportamento interno do
cliente e dos fornecedores não são relevantes para fins de compreensão
como o vendedor deve cumprir os pedidos de compra e, como tal, eles podem ser ocultados. Em
por outro lado, se precisarmos melhorar a maneira como o vendedor atende aos pedidos de compra,
também pode querer saber o que é necessário para um fornecedor fornecer matérias-primas, como um
demora no fornecimento de matéria-prima vai desacelerar a fabricação do produto
Página 107
3.4 Recursos 87
Fig. 3.16 Diagrama de colaboração entre um vendedor, um cliente e dois fornecedores
Página 108
ao lado do vendedor. Neste caso, devemos também representar os fornecedores usando branco
box pools.
O tipo de pool afeta a maneira como usamos o fluxo de mensagens para nos conectar ao
piscina. Consequentemente, um fluxo de mensagens pode cruzar o limite de um conjunto de caixa branca
e se conectar diretamente a uma atividade ou evento dentro desse pool, como o pedido de compra
mensagem que é incidente ao evento de início no pool do vendedor. Por outro lado,
uma vez que um conjunto de caixa preta está vazio, os fluxos de mensagens devem parar no limite ou emanar
do limite de uma piscina de caixa preta. Tenha em mente que um fluxo de mensagens é apenas
usado para conectar dois pools e nunca para conectar duas atividades dentro do mesmo pool.
Para isso, usamos um fluxo de sequência.
Uma atividade que é a fonte de uma mensagem, como "Emitir fatura" no Vendedor
pool - é chamado de atividade de envio . A mensagem é enviada após a conclusão da atividade
execução. Por outro lado, uma atividade que recebe uma mensagem, como “Receba
endereço de envio ”- é uma atividade de recebimento . 2 A execução de tal atividade não
comece até que a mensagem recebida esteja disponível. Uma atividade pode atuar como uma recepção
e uma atividade de envio quando tem um fluxo de mensagem de entrada e saída, por exemplo
"Faça o pagamento". A execução desta atividade começará quando ambos os fluxos de controle
token e a mensagem recebida estão disponíveis. Após a conclusão da atividade, um
token de fluxo de controle será colocado no arco de saída e a mensagem de saída será
enviado para fora. Finalmente, quando um fluxo de mensagens incide em um evento inicial como “Compra
pedido recebido ”, precisamos marcar este evento com um envelope leve (ver Fig. 3.16 ).
Este tipo de evento é denominado evento de mensagem . Um evento de mensagem pode ser vinculado a uma saída
objeto de dados para armazenar o conteúdo da mensagem recebida. Nós aprenderemos
mais sobre eventos no próximo capítulo.
Exercício 3.7 Estenda o modelo do Exercício 3.6 , representando as interações entre

entre o credor e o requerente.
No exemplo de atendimento de pedidos, usamos pools para representar as partes de negócios e

pistas para representar os departamentos e sistemas dentro da organização de vendas. Isto é
porque queríamos nos concentrar nas interações entre o vendedor, o cliente e
os dois fornecedores. Como mencionado antes, esse é o uso típico para piscinas e raias.
No entanto,auma
associados poolsvez que BPMN
e pistas, não usar
podemos prescreve
esses quais tipos de
elementos de maneira
recursosdiferente.
específicos devem
Para ser
a prova-
ple, se o foco estiver nas interações entre os departamentos de uma organização,
podemos modelar cada departamento com um pool e usar faixas para particionar o departamento
mentos, por exemplo, em unidades ou funções. Em qualquer caso, devemos evitar o uso de piscinas e pistas
para capturar os participantes por seus nomes, uma vez que os indivíduos tendem a mudar com frequência
dentro de uma organização; em vez disso, devemos usar a função do participante, por exemplo, financeiro
Policial. Por outro lado, podemos usar pools e pistas para representar software específico
sistemas ou equipamentos, por exemplo, um sistema ERP, uma vez que estes mudam com menos frequência em um
organização.
2 Mais especificamente, “Emitir fatura” é uma tarefa de envio e “Obter endereço de entrega” é uma tarefa de recebimento . o
A distinção entre atividade e tarefa será discutida no Cap. 4 .
Página 109
3.5 Recapitulação
No final deste capítulo, devemos ser capazes de compreender e produzir programas básicos
modelos de cesso em BPMN. Um modelo básico de BPMN inclui atividades simples, eventos,
gateways, objetos de dados, pools e pistas. Atividades capturam unidades de trabalho dentro de um
processo. Os eventos definem o início e o fim de um processo e sinalizam algo que acontece
canetas durante a execução do mesmo. Gateways modelam decisões exclusivas e inclusivas,
mesclas, paralelismo e sincronização e repetição. Estudamos a diferença
entre o modelo de processo e a instância de processo. Um modelo de processo descreve todas as possibilidades
várias maneiras de um determinado processo de negócios ser executado, enquanto uma instância de processo captura
execução de um processo específico entre todos os possíveis. O progresso, ou estado, de um
a instância do processo é representada por tokens. Usando tokens, podemos definir o comportamento
de gateways.
Também aprendemos como usar objetos de dados para modelar o fluxo de informações entre
atividades e eventos. Um objeto de dados captura um artefato físico ou eletrônico re-
exigido para executar uma atividade ou acionar um evento, ou que resulte da execução
de uma atividade ou ocorrência de um evento. Objetos de dados podem ser armazenados em um armazenamento de dados
como um banco de dados ou arquivo de modo que eles possam ser persistidos além do processo
instância onde eles são criados. Além disso, vimos como pools e pistas podem ser
usado para modelar recursos humanos e não humanos que realizam atividades de processo
laços. Os pools geralmente modelam classes de recursos, enquanto as pistas são usadas para particionar pools.
A interação entre os conjuntos é capturada por fluxos de mensagens. Os fluxos de mensagens podem ser
diretamente anexado ao limite de uma piscina, caso os detalhes da interação não
Seja relevante.
Atividades, eventos, gateways, artefatos e recursos pertencem ao modelo principal-
diferentes perspectivas de um processo de negócios. A perspectiva funcional captura o ac-
atividades que são executadas em um processo de negócios enquanto a perspectiva de fluxo de controle
combina essas atividades e eventos relacionados em uma determinada ordem. A perspectiva dos dados
cobre os artefatos manipulados no processo, enquanto a perspectiva do recurso cobre
os recursos que realizam as diversas atividades. No próximo capítulo, aprenderemos
como modelar processos de negócios complexos, investigando as várias extensões de
os principais elementos BPMN que apresentamos aqui.
Solução 3.1
Página 110
Solução 3.2
Solução 3.3
Solução 3.4
Página 111
Solução 3.5
Página 112
Solução 3.6 Veja o pool de provedores de empréstimo no modelo da Solução 3.7 .
Solução 3.7
Página 113
3.7 Exercícios Adicionais 93
3.7 Exercícios Adicionais
Exercício 3.8 Que tipos de divisões e junções podemos modelar em um processo? Fazer um
exemplo para cada um deles usando a verificação de segurança em um aeroporto como cenário.
Exercício 3.9 Descreva o seguinte modelo de processo.
Exercício 3.10 Modelar o seguinte processo de negócios para lidar com pagamentos iniciais.
O processo para lidar com pagamentos iniciais começa quando uma solicitação de pagamento foi aprovada
provado. Envolve inserir a solicitação de entrada no sistema, a sub-
pagamento sequencial, emissão de nota fiscal direta e liberação dos itens de linha do fornecedor.
A compensação das partidas individuais do fornecedor pode resultar em um saldo devedor ou credor. Em caso de débito
saldo, os atrasos são processados, caso contrário, o saldo remanescente é pago.
Exercício 3.11 Modelar o seguinte processo de negócios para avaliar riscos de crédito.
Quando uma nova solicitação de crédito é recebida, o risco é avaliado. Se o risco estiver acima de um limite,
uma avaliação de risco avançada precisa ser realizada, caso contrário , uma avaliação de risco simples
satisfazer. Assim que a avaliação for concluída, o cliente é notificado com o resultado de
a avaliação e entretanto o desembolso é organizado. Para simplificar, suponha que o
resultado de uma avaliação é sempre positivo.
Exercício 3.12 Modelar o seguinte fragmento de um processo de negócios para seguros

reivindicações.
Depois que uma reclamação é registrada, ela é examinada por um oficial de sinistros que, em seguida, redige um acordo
recomendação. Esta recomendação é então verificada por um oficial sênior de sinistros que pode
marque a declaração como “OK” ou “Não OK”. Se a reclamação estiver marcada como "Não está OK", ela será enviada de volta
ao oficial de sinistros e a recomendação é repetida. Se a reclamação for “OK”, a reclamação
processo de tratamento continua.
Exercício 3.13 Modelar o fluxo de controle do seguinte processo de negócios para danos
compensação.
Se um inquilino for despejado por causa de danos às instalações, um processo deve ser iniciado pelo
tribunal, a fim de realizar uma audiência para avaliar o valor da compensação que o inquilino deve ao
proprietário das instalações. Este processo começa quando um caixa do tribunal recebe um pedido
para indemnização do proprietário. O caixa, então, recupera o arquivo para aqueles
premissas e verifica se o pedido é aceitável para apresentação e está em conformidade com o
Página 114
descrição das instalações em arquivo. Definir uma data de audiência incorre em taxas para o proprietário. Pode ser
que o proprietário já pagou as taxas com o pedido, caso em que o caixa aloca
uma data de audiência e o processo é concluído. Pode ser que taxas adicionais sejam necessárias, mas o
o proprietário já pagou também essas taxas. Neste caso, o caixa gera um recibo para o
taxas adicionais e receitas com a alocação da data da audiência. Finalmente, se o proprietário não
pagou as taxas exigidas, o caixa apresenta um aviso de taxas e espera que o proprietário pague o
taxas antes de reavaliar a conformidade do documento.
Exercício 3.14 O modelo de processo abaixo pode ser executado corretamente? Se não, como pode
ser corrigido sem afetar o ciclo, ou seja, de modo que "F", "G" e "E" permaneçam em
o ciclo?
Exercício 3.15 Escreva um modelo BPMN para o processo descrito no Exercício 1.1 .
Certifique-se de incluir artefatos e anotações quando apropriado.
Exercício 3.16 Estenda o modelo do Exercício 3.13 adicionando os artefatos que são
manipulado.
Exercício 3.17 Estenda o modelo do Exercício 3.16 adicionando os recursos envolvidos.

Existe algum recurso não humano?
Exercício 3.18 Modele o seguinte processo de negócios. Use gateways e objetos de dados
onde necessário.
Em um tribunal todas as manhãs, os arquivos que ainda não foram processados são verificados para garantir
eles estão em ordem para a audiência naquele dia. Se alguns arquivos estiverem faltando, uma pesquisa será iniciada,
caso contrário, os arquivos podem ser rastreados fisicamente até o local pretendido. Assim que todos os arquivos forem
pronto, são entregues ao Associado; entretanto, a lista de leis do juiz é distribuída ao
pessoas relevantes. Em seguida, são realizadas as audiências de orientações.
Exercício 3.19 Modele o seguinte processo de negócios. Use piscinas / pistas onde
necessário.
O processo de tratamento de reclamações motoras começa quando um cliente envia uma reclamação com o respectivo
documentação. O departamento de notificação da seguradora de automóveis verifica os documentos mediante
Página 115
integridade e registra a reclamação. Em seguida, o departamento de manuseio pega a reclamação

e verifica o seguro. Em seguida, é realizada uma avaliação. Se a avaliação for positiva,
uma Oficina é telefonada para autorizar os reparos e o pagamento é agendado (neste pedido).
Caso contrário, a reclamação é rejeitada. Em qualquer caso (seja o resultado positivo ou negativo),
uma carta é enviada ao cliente e o processo é considerado concluído.
Exercício 3.20 Modelar o seguinte processo de negócios. Use piscinas / pistas onde
necessário.
Quando um sinistro é recebido, um oficial de sinistros primeiro verifica se o reclamante está segurado. Se não, o
o reclamante é informado de que a reclamação deve ser rejeitada enviando uma notificação automática via
um sistema SAP. Caso contrário, um oficial sênior de sinistros avalia a gravidade da reclamação. Sediada
no resultado (reclamações simples ou complexas), os formulários relevantes são enviados ao reclamante,
novamente usando o sistema SAP. Depois que os formulários são devolvidos, eles são verificados quanto à integridade
pelo oficial de sinistros. Se os formulários fornecerem todos os detalhes relevantes, a reclamação é registrada no
sistema de gerenciamento de sinistros e o processo termina. Caso contrário, o reclamante é informado para
atualizar os formulários através do sistema SAP. Após o recebimento dos formulários atualizados, eles são verificados
novamente pelo oficial de sinistros para ver se os detalhes foram fornecidos e assim por diante.
Neste capítulo, apresentamos os fundamentos da modelagem de processos através do BPMN

língua. Outras linguagens convencionais que podem ser usadas para modelar processos de negócios
são diagramas de atividades UML (UML ADs), cadeias de processos orientadas a eventos (EPCs) e
Linguagem de execução de processos de negócios de serviços da Web (WS-BPEL). UML ADs são
outro padrão OMG [ 60 ]. Eles são empregados principalmente na engenharia de software
onde podem ser usados para descrever o comportamento do software e vinculados a outros UML
tipos de diagrama, por exemplo, diagramas de classe, para gerar código de software. UML ADs oferecem um
subconjunto dos elementos de modelagem presentes no BPMN. Por exemplo, construções como o
OR-join não é compatível. Uma boa visão geral desta linguagem e sua aplicação para
a modelagem de processos de negócios é fornecida em [ 16 ].
EPCs foram inicialmente desenvolvidos para o design do processo de referência SAP R / 3
modelo [ 9 ]. Eles obtiveram uma adoção generalizada por várias organizações quando
tornou-se a linguagem de modelagem central do conjunto de ferramentas ARIS [ 12 , 82 ]. Mais tarde, eles foram
usado por outros fornecedores para o design de modelos de referência independentes de SAP, como
ITIL e SCOR. A linguagem EPC inclui elementos de modelagem correspondentes a
Atividades BPMN, gateways AND, XOR e OR, eventos não tipados e objetos de dados.
Uma introdução aos EPCs é fornecida em [ 50 ].
WS-BPEL (BPEL para abreviar) versão 2.0 [ 3 ] é um padrão da Organização para
o Avanço dos Padrões de Informação Estruturada (OASIS). Uma boa visão geral
de BPEL é fornecido em [ 65 ]. BPEL é uma linguagem para execução de processos que rem
reside na tecnologia de serviço da Web para alcançar a comunicação entre processos. Um mapeamento
de BPMN para construções BPEL está disponível na especificação BPMN [ 61 ]. Quão-
sempre, este mapeamento não está completo, pois BPEL oferece um conjunto restrito de construções
em comparação com BPMN, e é essencialmente uma linguagem orientada a blocos , enquanto BPMN é
orientado para gráfico . BPEL é estruturado em blocos que precisam ser devidamente aninhados e
Página 116
não pode se sobrepor. Um bloco é composto por um único nó de entrada e um único nó de saída
que corresponde ao tipo de nó de entrada e coleta todos os ramos de saída
do nó de entrada. Por exemplo, se o nó de entrada for uma divisão AND, o nó de saída
deve ser uma junção AND. Além disso, BPEL não possui uma notação padrão, uma vez que
isso foi considerado fora do escopo pelo OASIS, embora vários fornecedores forneçam
notações particulares para este idioma. Enquanto BPMN 1.2 teve como objetivo ser o conceitual
contrapartida do BPEL, e os mapeamentos estavam, portanto, disponíveis para mover do antigo para
a última linguagem, BPMN 2.0 também pode ser usado para especificar processos executáveis (ver
Indivíduo. 9 ). Assim, o BPMN 2.0 visa substituir o BPEL neste aspecto.
Outras linguagens de modelagem de processos se originam de esforços de pesquisa. Dois deles
são redes de fluxo de trabalho e ainda outra linguagem de fluxo de trabalho (YAWL). Redes de fluxo de trabalho
são uma extensão das redes de Petri para modelar processos de negócios. Sua sintaxe é de propósito
totalmente simples e gira em torno de dois elementos: lugares e transições. O antigo
correspondem aproximadamente a eventos BPMN, enquanto os últimos a atividades BPMN. Um bem
a apresentação de redes de fluxo de trabalho é fornecida em [ 95 ].
YAWL é um sucessor das redes de fluxo de trabalho, pois adiciona construções específicas para cap-
cuidar do comportamento de junção OR, atividades de várias instâncias, subprocessos e cancelamento
regiões. YAWL mantém a simplicidade e intuitividade das redes de fluxo de trabalho, embora
fornece uma linguagem muito mais expressiva. YAWL e seu ambiente de suporte
são apresentados em detalhes em [ 92 ].
Uma comparação das línguas acima em termos de sua expressividade ao longo do
as perspectivas de fluxo de controle, dados e recursos podem ser encontradas em Padrões de fluxo de trabalho
Site da iniciativa [ 108 ]. Com o tempo, essa iniciativa coletou um repositório de trabalho
padrões de fluxo, ou seja, comportamento recorrente do processo, conforme foi observado a partir de um tor-
análise rigorosa de várias linguagens de modelagem de processos e ferramentas de suporte. Vários
linguagens e ferramentas foram comparadas com base em seu suporte para tais padrões.
Página 117
Capítulo 4
Modelagem Avançada de Processos
As ciências não tentam explicar, dificilmente tentam

interpretar, eles fazem principalmente modelos.
John von Neumann (1903–1957)
Neste capítulo, aprenderemos como modelar processos de negócios complexos com BPMN.
As construções apresentadas neste capítulo se baseiam no conhecimento adquirido
no cap. 3 . Em particular, iremos expandir em atividades, eventos e gateways. Nós
aprenderá como usar atividades para modelar subprocessos e como reutilizar esses subprocessos
processos em diferentes processos. Também vamos estender as atividades para modelar mais
formas sofisticadas de retrabalho e repetição. De acordo com os eventos, expandiremos a mensagem
eventos sábios, apresentam eventos temporais e mostram como as condições de corrida podem ser modeladas
entre esses tipos de eventos por meio de um novo tipo de gateway. Também aprenderemos como usar
eventos para lidar com exceções de processos de negócios. Finalmente, vamos mostrar como uma colaboração
diagrama de ração pode ser resumido em um diagrama de coreografia que se concentra apenas em
as interações entre as partes comerciais envolvidas.
4.1 Decomposição do Processo
Ao capturar processos de negócios complexos, o modelo de processo resultante pode ser

grande demais para ser compreendido de uma vez. Pegue o modelo de processo de atendimento de pedidos em
Fig. 3.12 . Embora o cenário em questão ainda seja relativamente simples, este modelo já
contém 14 atividades, seis gateways e dois eventos. À medida que adicionamos objetos de dados e mensagens
sage flui, o modelo fica maior e mais difícil de entender (veja, por exemplo, Fig. 3.16 ). Para
melhorar sua legibilidade, podemos simplificar o processo, ocultando certas partes dentro
um subprocesso . Um subprocesso representa uma atividade composta independente que
pode ser dividido em unidades menores de trabalho. Por outro lado, uma atividade atômica, também
chamada tarefa , é uma atividade que captura uma unidade de trabalho que não pode ser mais quebrada
baixa.
Para usar um subprocesso, primeiro precisamos identificar grupos de atividades relacionadas,
ou seja, aquelas atividades que juntas alcançam um objetivo específico ou geram um determinado
resultado lar no modelo de processo em análise. Em nosso exemplo de atendimento de pedido,
podemos ver que as atividades “Verificar disponibilidade de matéria-prima” e “Comprar matéria-prima

Página 118
98 4 Modelagem Avançada de Processos
Fig. 4.1 Identificação de subprocessos no processo de atendimento de pedidos da Fig. 3.12
materiais do Fornecedor 1 (2) ”, conduzem em conjunto à aquisição de matérias-primas.

Assim, essas atividades e seus gateways de conexão podem ser encapsulados em um sub
processo. Em outras palavras, eles podem ser vistos como as etapas internas de uma macroatividade
denominado “Adquirir matérias-primas”. Da mesma forma, os dois ramos paralelos para envio e
O faturamento do pedido pode ser agrupado em outra atividade de subprocesso chamada “Enviar
e fatura ”. A Figura 4.1 ilustra o modelo resultante, onde as atividades acima
foram incluídos em duas atividades de subprocesso. Representamos essas atividades com
uma grande caixa arredondada que envolve as etapas internas. Como podemos observar de
Fig. 4.1 , também adicionamos um evento inicial e um evento final dentro de cada subprocesso ativ-
, para indicar explicitamente quando o subprocesso inicia e termina.
Lembre-se de que nosso objetivo inicial era simplificar um modelo de processo. Assim que tivermos
identificou os limites dos subprocessos, podemos simplificar o modelo por hid-
ção do conteúdo de seus subprocessos, conforme mostrado na Fig. 4.2 . Isso é feito substituindo
a macro-atividade que representa o subprocesso com uma atividade de tamanho padrão. Nós
indicam que esta atividade esconde um subprocesso, marcando-o com um pequeno quadrado
com um sinal de mais (+) dentro (como se pudéssemos expandir o conteúdo dessa atividade
pressionando o botão mais). Esta operação é chamada de redução de um subprocesso. De
colapsando um subprocesso, reduzimos o número total de atividades (o pedido cumprido
processo de preenchimento tem apenas seis atividades agora), melhorando assim a legibilidade do modelo
ity. No BPMN, um subprocesso que oculta suas etapas internas é chamado de sub-colapsado
processo , em oposição a um subprocesso expandido que mostra suas etapas internas (como
na Fig. 4.1 ).
Página 119
4.1 Decomposição do Processo 99
Fig. 4.2 Uma versão simplificada do processo de atendimento do pedido após ocultar o conteúdo de seu sub
processos
Exercício 4.1 Identificar subprocessos adequados no processo de avaliação do pedido de empréstimo

complicações modeladas no Exercício 3.5 .
Dica Use os blocos de construção que você criou ao longo dos Exercícios 3.1 - 3.4 .
O recolhimento de um subprocesso não implica a perda de seu conteúdo. O subprocesso

ainda está lá, apenas definido em um nível de abstração abaixo. Na verdade, podemos aninhar sub-
processos em vários níveis, de modo a decompor um modelo de processo hierarquicamente. A
exemplo é mostrado na Fig. 4.3 , que modela um processo de negócios para desembolsar em casa
empréstimos. No primeiro nível, identificamos dois subprocessos: um para verificar o aplicativo
responsabilidade da cantora, a outra pela assinatura do empréstimo. No segundo nível, nós fatoramos fora
o agendamento do desembolso do empréstimo dentro do processo de assinatura de empréstimos em um
subprocesso separado.
Conforme descemos na decomposição hierárquica de um modelo de processo, podemos adicionar
mais detalhes. Por exemplo, podemos estabelecer uma convenção que, no nível superior,
apenas modelar atividades de negócios centrais, no segundo nível, adicionamos pontos de decisão, e
assim por diante, até a modelagem de exceções e detalhes que são relevantes apenas para
Automação do processo.
Pergunta Quando devemos decompor um modelo de processo em subprocessos?
Devemos usar subprocessos sempre que um modelo se torna muito grande que é difícil de
Compreendo. Embora seja difícil definir com precisão quando um modelo de processo é "muito grande",
uma vez que a compreensibilidade é subjetiva, foi demonstrado que usando mais do que ap-
cerca de 30 objetos de fluxo (ou seja, atividades, eventos, gateways) leva a um aumento
probabilidade de cometer erros em um modelo de processo (por exemplo, introdução comportamental é-
processa). Assim, sugerimos usar o mínimo de elementos possível para cada modelo de processo
nível, e em particular para decompor um modelo de processo se este tiver mais de 30 fluxos
objetos.
Reduzir o tamanho de um modelo de processo, por exemplo, recolhendo seu sub

processos, é uma das maneiras mais eficazes de melhorar a leitura de um modelo de processo
habilidade. Outros aspectos estruturais que afetam a legibilidade incluem a densidade do
Página 120
Fig. 4.3 Um modelo de processo para desembolso de empréstimos imobiliários, estabelecido em três níveis hierárquicos via
o uso de subprocessos
conexões de modelo de processo, o número de ramificações paralelas, o caminho mais longo de um

início para um evento final, bem como aspectos cosméticos, como o layout, o estilo dos rótulos
(por exemplo, sempre use um estilo verbo-substantivo), a paleta de cores, a espessura das linhas, etc. Mais
informações sobre o estabelecimento de diretrizes de modelagem de processos podem ser encontradas no Cap. 5 .
Mostramos que podemos simplificar um modelo de processo identificando primeiro o
conteúdo de um subprocesso e, em seguida, ocultando esse conteúdo recolhendo o subprocesso
atividade. Às vezes, podemos desejar prosseguir na direção oposta, o que significa que
ao modelar um processo, já identificamos atividades que podem ser divididas em
etapas menores, mas intencionalmente subespecificamos seu conteúdo. Em outras palavras, nós
não vincule a atividade de subprocesso a um modelo de processo em um nível inferior de captura
seu conteúdo (como se ao pressionar o botão de adição nada aconteceria). O motivo
fazer isso é dizer ao leitor que algumas atividades são compostas de subetapas, mas
que revelar os detalhes destes não é relevante. Este poderia ser o caso de atividade
"Enviar produto" no exemplo de atendimento do pedido, para o qual modelar a distinção
entre suas etapas internas para embalagem e para envio não é relevante.
4.2 Reutilizar Processo
Por padrão, um subprocesso é incorporado em seu modelo de processo pai e, como tal
ele só pode ser chamado de dentro desse modelo de processo. Muitas vezes, ao modelar um
processo de negócios, podemos precisar reutilizar partes de outros modelos de processo do mesmo
organização. Por exemplo, um provedor de empréstimo pode reutilizar o subprocesso para assinar
Página 121
4.2 Reutilizar Processo 101
Fig. 4.4 O modelo de processo para desembolsar empréstimos estudantis invoca o mesmo modelo para assinar empréstimos
usado pelo processo de desembolso de empréstimos imobiliários, por meio de uma atividade de chamada
empréstimos contidos no desembolso do empréstimo à habitação para outros tipos de empréstimo, como um
processo para desembolsar empréstimos estudantis ou empréstimos para automóveis.
Em BPMN, podemos definir o conteúdo de um subprocesso fora de seu processo pai,
definindo o subprocesso como um modelo de processo global . Um modelo de processo global é
um modelo de processo que não está embutido em nenhum modelo de processo e, como tal, pode
ser chamado por outros modelos de processo dentro da mesma coleção de modelos de processo. Para
indicam que o subprocesso que está sendo invocado é um modelo de processo global, usamos o
atividade de subprocesso recolhida com uma borda mais espessa (este tipo de atividade é chamado de chamada
atividade em BPMN). Voltando ao exemplo de desembolso de empréstimo da Fig. 4.3 , nós
pode fatorar o subprocesso para assinar empréstimos e defini-lo como um processo global
modelo, de modo que também possa ser invocado por um modelo de processo para desembolsar alunos
empréstimos (ver Fig. 4.4 ).
Questão Subprocesso integrado ou global?
Nossa escolha padrão deve ser definir subprocessos como modelos de processos globais
de modo a maximizar sua reutilização em nossa coleção de modelos de processos. De apoio
processos como pagamento, faturamento, RH, impressão, são bons candidatos para serem
definidos como modelos de processos globais, uma vez que são normalmente compartilhados por vários negócios
processos dentro de uma organização. Além da reutilização, outra vantagem de usar
modelos de processos globais é que qualquer mudança feita nesses modelos será automatizada
propagados para todos os modelos de processo que os invocam. Em alguns casos, no entanto,
podemos querer manter as mudanças internas a um processo específico. Por exemplo, um
O processo de faturamento usado para liquidação de pedidos corporativos normalmente seria diferente
Página 122
do processo de faturamento para pedidos privados. Neste caso, devemos manter dois modelos
variantes do subprocesso de fatura, cada uma incorporada em seu modelo de processo pai:
liquidação de pedidos corporativos e privados.
Exemplo 4.1 Vamos considerar o processo de aquisição de uma empresa farmacêutica.
Uma empresa farmacêutica possui diferentes unidades de negócios em seu departamento de fabricação
mento, cada um produzindo um tipo específico de medicamento. Por exemplo, existe uma unidade de negócios
cuidando de medicamentos inalatórios e outro produzindo vacinas. Os vários negócios
unidades de negócios fazem uso de um processo de aquisição direto para solicitar produtos químicos, e de um
processo de aquisição indireta para solicitar peças de reposição para seus equipamentos.
O processo de aquisição direta depende das matérias-primas que são necessárias para
produzir um tipo específico de medicamento. Por exemplo, as vacinas normalmente incluem ad-
juvants que ajudam a melhorar a eficácia da vacina, que não estão contidos em
medicamentos inalados. Da mesma forma, os medicamentos inalados contêm um propelente químico
para empurrar o medicamento para fora do inalador, o que não é necessário para as vacinas. Desde a
este processo de aquisição é específico para cada unidade de negócios, precisamos modelá-lo como
um subprocesso embutido no modelo de processo de fabricação de cada unidade. Em
por outro lado, o processo de pedido de peças de reposição para o equipamento de sintetização
produtos químicos podem ser compartilhados entre todas as unidades, uma vez que todas as unidades fazem uso do mesmo
equipamento. Assim, vamos modelar esse processo com um modelo de processo global.
Antes de concluir nossa discussão sobre os subprocessos, precisamos apontar alguns

regras sintáticas para usar este elemento. Um subprocesso é um modelo de processo regular. isto
deve começar com pelo menos um evento inicial e terminar com pelo menos um evento final.
Se houver vários eventos de início, o subprocesso será acionado pelo primeiro
um evento que ocorre. Se houver vários eventos finais, o subprocesso retornará
controle para seu processo pai apenas quando cada token fluindo neste modelo atinge
um evento final. Além disso, não podemos cruzar o limite de um subprocesso com um
fluxo de sequência. Para passar o controle para um subprocesso ou receber o controle de um subprocesso,
devemos sempre usar eventos de início e término. Por outro lado, os fluxos de mensagens podem
cruzar os limites de um subprocesso para indicar mensagens que emanam ou são
direcionado a atividades ou eventos internos do subprocesso.
Exercício 4.2 Identifique subprocessos adequados no processo de negócios do Exercício 1.7 .

Entre esses subprocessos, identifique aqueles que são específicos para este processo de negócios
versus aqueles que podem ser potencialmente compartilhados com outros processos de negócios do mesmo
companhia.
4.3 Mais sobre retrabalho e repetição
No capítulo anterior, descrevemos como modelar retrabalho e repetição por meio do

Gateways XOR. Subprocessos expandidos oferecem uma maneira alternativa de modelar peças
de um processo que pode ser repetido. Vamos considerar novamente o processo de abordagem
Página 123
4.3 Mais sobre retrabalho e repetição 103
Fig. 4.5 O modelo de processo para endereçar correspondência ministerial da Fig. 3.13 simplificado
usando uma atividade de loop
correspondência ministerial do Exemplo 3.7 . Para tornar este modelo mais simples, podemos
pegue o fragmento identificado pelo XOR-join e o XOR-split (que inclui
o bloco de repetição e o ramo de loopback) e substitua-o por um subprocesso
contendo as atividades no bloco de repetição. Para identificar que este sub-processo
pode ser repetido (se a resposta não for aprovada), marcamos a atividade do subprocesso
com um símbolo de loop, como mostrado na Fig. 4.5 . Podemos usar uma anotação para especificar o
condição do loop, por exemplo, “até a resposta aprovada”.
Como para qualquer subprocesso, você pode decidir não especificar o conteúdo de um loop
subprocesso. No entanto, se você fizer isso, não se esqueça de colocar uma atividade de decisão como o
última atividade dentro do subprocesso, caso contrário, não há como determinar quando
repita o subprocesso.
Pergunta Atividade de loop ou ciclo?
A atividade de loop é uma notação abreviada para um ciclo estruturado, ou seja, uma repetição
bloco delimitado por um único ponto de entrada para o ciclo, e um único ponto de saída de
o ciclo, como no exemplo acima. Às vezes, pode haver mais de um en-
tente e / ou ponto de saída, ou o ponto de entrada / saída pode estar dentro do bloco de repetição.
Considere, por exemplo, o modelo da Fig. 4.6 . Aqui, o bloco de repetição é feito
de atividades "Avaliar aplicação", "Notificar rejeição" e "Receber feed do cliente
costas"; o ciclo tem um ponto de entrada e dois pontos de saída, dos quais um dentro do
bloco de repetição. Quando um ciclo não estruturado tem vários pontos de saída, como neste
caso, uma atividade de loop não pode ser usada, a menos que condições adicionais sejam usadas para especificar
as situações em que o ciclo pode ser encerrado, o que tornará o modelo mais
complexo.
Exercício 4.3
1. Identifique os pontos de entrada e saída que delimitam os ciclos não estruturados no pro-
modelos de processamento mostrados na Solução 3.4 e no Exercício 3.9 . Quais são as repetições
blocos?
Página 124
Fig. 4.6 Um exemplo de ciclo não estruturado
2. Modelar o processo de negócios da Solução 3.4 usando uma atividade em loop.
4.3.1 Repetição Paralela
A atividade de loop nos permite capturar a repetição sequencial, o que significa que as instâncias
da atividade de loop são executados um após o outro. Às vezes, porém, podemos
precisa executar várias instâncias da mesma atividade ao mesmo tempo, como no
seguinte exemplo.
Exemplo 4.2 Em um processo de aquisição, uma cotação deve ser obtida de todos os
fornecedores. Depois que todas as cotações são recebidas, elas são avaliadas e a melhor cotação é
selecionado. Um pedido de compra correspondente é então colocado.
Vamos supor que existam cinco fornecedores preferenciais. Então podemos usar uma divisão AND para
modelar cinco tarefas em paralelo, cada uma para obter uma cotação de um fornecedor, conforme mostrado em
Fig. 4.7 . No entanto, existem vários problemas com essa solução. Primeiro, quanto maior o
número de fornecedores, maior será o modelo resultante, uma vez que precisamos usar
uma tarefa por fornecedor. Em segundo lugar, precisamos revisar o modelo toda vez que o número
de mudanças de fornecedores. Na verdade, é frequentemente o caso na realidade que uma lista atualizada de
fornecedores é mantido em um banco de dados organizacional que é consultado antes de contatar
os fornecedores.
Para evitar esses problemas, o BPMN fornece um constructo chamado multi-instance ac-
atividade. Uma atividade de várias instâncias indica uma atividade (seja uma tarefa ou um subprocesso)
que é executado várias vezes simultaneamente. Tal construção é útil quando o
mesma atividade precisa ser executada para várias entidades ou itens de dados, como por ex-
suficiente para solicitar cotações de vários fornecedores (como em nosso exemplo), para verificar o
disponibilidade de cada item de linha em um pedido separadamente, para enviar e coletar perguntas
naires para várias testemunhas no contexto de uma reclamação de seguro, etc.
Uma atividade multi-instância é descrita como uma atividade marcada com três pequenas ver-
linhas ticas na parte inferior. A Figura 4.8 mostra uma versão revisada da aquisição
modelo de processo na Fig. 4.7 . Este modelo não é apenas menor, mas também pode funcionar com
uma lista dinâmica de fornecedores, que pode mudar a cada caso.
Página 125
Fig. 4.7 Obtenção de cotações de cinco fornecedores
Para fazer isso, adicionamos uma tarefa para recuperar a lista de fornecedores e passamos essa lista para um
tarefa multi-instância, que contacta os vários fornecedores. Você teria notado
que neste exemplo também marcamos a lista de fornecedores do objeto de dados com o
símbolo de várias instâncias. Isso é usado para indicar uma coleção de objetos de dados semelhantes,
como uma lista de itens de pedido ou uma lista de clientes. Quando uma coleção é usada como entrada
para uma atividade multi-instância, o número de itens na coleção determina o
número de instâncias de atividades a serem criadas. Como alternativa, podemos especificar o número
de instâncias a serem criadas por meio de uma anotação na atividade de várias instâncias (por exemplo, “15
fornecedores ”ou“ conforme base de dados de fornecedores ”).
Voltemos ao nosso exemplo. Suponha que a lista de fornecedores se tornou bastante
grande ao longo do tempo, digamos que haja 20 fornecedores no banco de dados. De acordo com nossa organização
políticas, no entanto, cinco cotações de cinco fornecedores diferentes são suficientes para fazer um
decisão. Assim, não queremos esperar que todos os 20 fornecedores respondam ao nosso
pedido de orçamento. Para fazer isso, podemos anotar a atividade de várias instâncias com o
número mínimo de instâncias que precisam ser concluídas antes de passar o controle para o
arco de saída (por exemplo, “complete quando cinco cotações forem obtidas”, como mostrado na Fig. 4.8 ).
Quando a atividade multi-instância é acionada, 20 tokens são gerados, cada marcação
o andamento de uma das 20 instâncias. Então, assim que as primeiras cinco instâncias
completo, todas as outras instâncias são canceladas (os respectivos tokens são destruídos)
e um token é enviado ao arco de saída para conclusão do sinal.
Vamos pegar o exemplo de atendimento de pedido na Fig. 4.2 e expandir o conteúdo de

o subprocesso de aquisição de matérias-primas. Para tornar este modelo mais realista, nós
pode usar um subprocesso multi-instância no lugar da estrutura delimitada pelos dois
Gateways OU, assumindo que a lista de fornecedores a serem contatados será determinada
Página 126
Fig. 4.8 Obtenção de cotações de vários fornecedores, cujo número não é conhecido a priori
Fig. 4.9 Usando um pool de múltiplas instâncias para representar múltiplos fornecedores
em tempo real a partir de um banco de dados de fornecedores (o modelo atualizado é mostrado na Fig. 4.9 ). Pelo
mesmo princípio, substituímos os dois pools "Fornecedor 1" e "Fornecedor 2" por um único
pool, ou seja, "Fornecedor", que também marcamos com o símbolo de várias instâncias - um
pool multi-instância representa um conjunto de classes de recursos, ou recursos, tendo
características.
Página 127
A partir desta figura, notamos que existem quatro fluxos de mensagens conectados ao sub
processo “Envio e fatura”, como resultado do colapso do conteúdo desta atividade.
A ordem em que essas mensagens são trocadas é determinada pelas atividades
dentro deste subprocesso que os recebe e envia. Em outras palavras, quando se trata
para uma atividade de subprocesso recolhida, a semântica da mensagem para as tarefas descritas em
Sect. 3.4 não é aplicado.
Exercício 4.4 Modelar o seguinte fragmento de processo.

Após um acidente de carro, um depoimento é solicitado a duas testemunhas das cinco que foram
presente, para reclamar o sinistro. Assim que as duas primeiras declarações forem re-
citado, o sinistro pode ser feito na seguradora sem esperar pelo outro
afirmações.
4.3.2 Repetição não controlada
Às vezes, podemos precisar modelar que uma ou mais atividades podem ser repetidas em
número de vezes, sem uma ordem específica, até que uma condição seja atendida. Por exemplo, deixe
presumimos que o cliente de nosso processo de atendimento de pedidos precisa perguntar sobre
o progresso de seu pedido. O cliente pode fazer isso simplesmente enviando um e-mail para
o vendedor. Isso pode ser feito a qualquer momento após o cliente ter enviado a compra
pedido e com a frequência que o cliente desejar. Da mesma forma, o cliente pode tentar
cancelar o pedido ou atualizar seus dados pessoais antes que o pedido seja atendido.
Essas atividades são descontroladas , no sentido de que podem ser repetidas múltiplas
vezes sem ordem específica, ou sem ocorrer de forma alguma, até que uma condição seja atendida - no nosso caso
o pedido sendo atendido.
Para modelar um conjunto de atividades não controladas, podemos usar um subprocesso ad-hoc .
A Figura 4.10 mostra o exemplo do processo do cliente, onde a conclusão
condição (“até que o pedido seja atendido”) foi especificada por meio de uma anotação. O anúncio
O subprocesso hoc é marcado com um símbolo de til na parte inferior da caixa do subprocesso.
Uma ordem parcial pode ser estabelecida entre as atividades de um subprocesso ad-hoc
por meio do fluxo de sequência. No entanto, não podemos representar eventos de início e fim em um anúncio
subprocesso hoc.
Exercício 4.5 Modele o seguinte fragmento de processo.

Um processo típico de recrutamento para o exército começa com a pré-seleção das inscrições de todos os candidatos. Essa
os pré-selecionados são então chamados a fazer os seguintes testes: drogas e álcool, olhos, visão de cores,
audição, sangue, urina, peso, impressão digital e exame médico. A visão colorida pode
só pode ser feito após o exame de vista, enquanto o exame médico só pode ser feito após a coloração
visão, audição, sangue, urina e peso foram testados. Além disso, pode ser necessário
para alguns candidatos repetir alguns desses testes várias vezes para obter uma correta
avaliação, por exemplo, o exame de sangue pode precisar ser repetido se o candidato tiver tomado muito
açúcar nas 24 horas anteriores. Os candidatos que passam em todos os testes são convidados a sentar-se em um mental
exame e exame físico, seguido de entrevista. Só aqueles que também passam esses dois
exames e um bom desempenho na entrevista podem ser recrutados no exército.
Página 128
Fig. 4.10 Usando um subprocesso ad-hoc para modelar a repetição não controlada
4.4 Tratamento de eventos
Como apontamos no cap. 3 , os eventos são usados para modelar algo que acontece em
instantaneamente em um processo. Vimos eventos iniciais, que sinalizam como as instâncias de processo
início (tokens são criados) e eventos finais, que sinalizam quando as instâncias do processo são
completo (os tokens são destruídos). Quando um evento ocorre durante um processo, por exemplo
uma confirmação de pedido é recebida após o envio de um pedido ao cliente e
antes de prosseguir com o embarque, o evento é denominado intermediário . Um token re-
rede presa no fluxo de sequência de entrada de um evento intermediário até o
evento ocorre. Então o token atravessa o evento instantaneamente, ou seja, os eventos podem
não retém tokens. Um evento intermediário é representado como um círculo com uma dupla
fronteira.
4.4.1 Eventos de Mensagem
No capítulo anterior, mostramos que podemos marcar um evento de início com um en-
velope para especificar que novas instâncias de processo são acionadas pelo recebimento de uma mensagem
(cf. Fig. 3.16 ). Além do evento de mensagem inicial, também podemos marcar um evento de término e
um evento intermediário com um envelope para capturar a interação entre nossos
cesso e outra parte. Esses tipos de evento são chamados coletivamente de eventos de mensagem .
Um evento de mensagem final sinaliza que um processo é concluído após o envio de uma mensagem.
Um evento de mensagem intermediária sinaliza o recebimento de uma mensagem, ou que uma mensagem
acaba de ser enviado, durante a execução do processo. Mensagem intermediária e final
eventos sábios representam uma notação alternativa para as atividades que são usadas exclusivamente
para enviar ou receber uma mensagem. Tome, por exemplo, atividades “Devolver o aplicativo ao ap-
plicant ”e“ Receber aplicativos atualizados ”na Fig. 4.11 a, que é um extrato do
modelo de avaliação de empréstimos da Solução 3.7 . É mais significativo substituir o anterior
atividade com um evento de envio de mensagem intermediário e a última atividade com um evento
termedia o recebimento do evento de mensagem, conforme ilustrado na Fig. 4.11 b, uma vez que essas atividades
Página 129
4.4 Tratamento de eventos 109
Fig. 4.11 Substituindo atividades que apenas enviam ou recebem mensagens ( a ) por eventos de mensagem ( b )
não representam realmente unidades de trabalho, mas sim o envio ou recebimento mecânico
de uma mensagem. Um evento de mensagem intermediário que recebe uma mensagem é descrito como
um evento de mensagem inicial, mas com uma borda dupla. Se o evento intermediário sinalizar um
mensagem sendo enviada, o envelope é escurecido.
Além disso, se a atividade de envio for seguida imediatamente por um evento final sem tipo,
podemos substituir isso por um evento de mensagem final, uma vez que, novamente, esta atividade é apenas
usado para enviar uma mensagem após a qual o processo é concluído. Um evento de mensagem final
é representado como um evento final marcado com um envelope escurecido. Cuidado, isso é um começo
O evento de mensagem não é uma notação alternativa para um evento de início não tipado seguido
por uma atividade de recepção: essas duas construções não são intercambiáveis. Na antiga
caso, as instâncias do processo iniciam após o recebimento de uma mensagem específica; no ultimo
caso, as instâncias de processo podem iniciar a qualquer momento, após o qual a primeira atividade requer um
mensagem a ser executada.
Pergunta Evento digitado ou não digitado?
Sugerimos especificar o tipo de evento sempre que conhecido, pois

ajudar o leitor a entender melhor o modelo do processo.
Exercício 4.6 Existe alguma outra atividade no modelo de avaliação de empréstimo da Solução 3.7
que pode ser substituído por um evento de mensagem?
Na BPMN, os eventos vêm em dois sabores com base no preenchimento de seu marcador.
Um marcador sem preenchimento, como aquele no evento de mensagem inicial, denota um evento de captura ,
ou seja, um evento que captura um gatilho, normalmente originado de fora do processo.
Um marcador com um preenchimento escuro como aquele no evento de mensagem final denota um lançamento
Página 130
Fig. 4.12 Usando eventos de cronômetro para conduzir as várias atividades de um processo de negócios
evento , ou seja, um evento que lança um gatilho de dentro do processo. Um intermediário

evento de mensagem tem ambos os tipos, pois pode ser usado como um evento de captura (o
a mensagem é recebida de outro pool) ou como um evento de lançamento (a mensagem é enviada
para outra piscina).
4.4.2 Eventos Temporais
Além do evento de mensagem, existem outros gatilhos que podem ser especificados para um início
evento. Vale a pena notar o evento do cronômetro . Este tipo de evento indica que o processo
instâncias começam na ocorrência de um evento temporal específico, por exemplo, toda sexta-feira
manhã, todos os dias úteis do mês, todas as manhãs às 7h.
Um evento temporizador também pode ser usado como evento intermediário, para modelar uma inter
val que precisa decorrer antes que a instância do processo possa prosseguir. Para indicar um cronômetro
evento, marcamos o símbolo do evento com um relógio de luz dentro do círculo. Eventos de cronômetro
estão capturando eventos apenas porque um cronômetro é um gatilho fora do controle do processo.
Em outras palavras, o processo não gera o cronômetro, mas reage a ele.
Exemplo 4.3 Vamos considerar o seguinte processo em um tribunal de pequenas causas.
Em um tribunal de pequenas causas, as chamadas ocorrem uma vez por mês, para definir o assunto para o
próximos ensaios. O processo de configuração de uma chamada começa três semanas antes da chamada
dia, com a preparação da lista de chamadas contendo informações como detalhes de contato de
as partes envolvidas e a data estimada de audiência. Uma semana antes da chamada, o envolvido
as partes são contatadas para determinar se estão todas prontas para ir a julgamento. Se for esse o caso, o
a chamada é definida, caso contrário, é adiada para o próximo slot disponível. Finalmente, no dia da chamada,
o material da chamada é preparado e a chamada é retida.
Este processo é conduzido por três eventos temporais: ele começa três semanas antes de
a data da chamada, continua uma semana antes da data da chamada e termina em
o dia da chamada. Para modelar esses eventos temporais, precisamos de um início e
dois eventos de temporizador intermediários, conforme mostrado na Fig. 4.12 . Vamos ver como isso
cesso funciona do ponto de vista da semântica do token. Um token capturando um novo in
postura é gerada toda vez que for três semanas antes da data da chamada (nós
suponha que esta data foi agendada por outro processo). Uma vez que a primeira atividade
Página 131
“Prepare callover list” foi completada, o token é enviado através da entrada

arco do seguinte evento temporizador intermediário, ou seja, "1 semana antes da chamada
dia". O evento torna-se assim habilitado . O token permanece preso na entrada
arco progressivo deste evento até que o próprio evento temporal ocorra, ou seja, apenas quando for um
semana antes do dia da chamada. Uma vez que este for o caso, o token instantaneamente tra-
vira o símbolo do evento e se move para o arco de saída. É por isso que os eventos são
dito ser instantâneo , uma vez que não pode reter tokens em oposição a atividades,
que retêm tokens durante a sua execução (lembre-se de que as atividades
sume time).
Exercício 4.7 Modelar o processo de faturamento de um provedor de serviços de Internet (ISP).

O ISP envia uma fatura por e-mail para o cliente no primeiro dia útil de cada mês
(Dia 1). No dia 7, o cliente tem o valor total pendente debitado automaticamente
de sua conta bancária. Se uma transação automática falhar por qualquer motivo, o cliente
é notificado no Dia 8. No Dia 9, a transação que falhou no Dia 7 é tentada novamente. E se
ele falha novamente, no dia 10 uma taxa de atraso é cobrada na conta bancária do cliente. Neste
estágio, o pagamento automático não é mais tentado. No dia 14, o serviço de Internet é
suspenso até que o pagamento seja recebido. Se no dia 30 o pagamento ainda estiver pendente, o
conta é encerrada e uma taxa de desconexão é aplicada. Um procedimento de recuperação de dívidas é então
começado.
4.4.3 Eventos de corrida
Um cenário típico encontrado ao modelar processos com eventos é aquele

onde dois eventos externos competem um contra o outro. O primeiro dos dois eventos que
ocorre determina a continuação do processo. Por exemplo, após um seguro
a cotação foi enviada a um cliente, o cliente pode responder com uma mensagem de aceitação
sábio, caso em que será feito um contrato de seguro, ou com rejeição, no qual
caso a citação seja descartada.
Esta corrida entre eventos externos é capturada por meio do exclu-
divisão sive ( XOR ). Uma divisão exclusiva baseada em evento é representada por um gateway marcado
por um pentágono vazio encerrado em um círculo de linha dupla. A Figura 4.13 apresenta um evento
divisão exclusiva baseada. Quando a execução do processo chega a este ponto (em
outras palavras - quando um token chega a este gateway), a execução para até ei-
então o evento de mensagem ou o evento de temporizador ocorre. Qualquer que seja o evento que ocorrer primeiro,
determinar de que maneira a execução irá prosseguir. Se o evento temporizador ocorrer primeiro, um
A consulta do status da remessa será iniciada e o fluxo de execução voltará para
o gateway exclusivo baseado em eventos. Se a mensagem que sinaliza a entrega do frete é
recebido primeiro, o fluxo de execução continuará ao longo do fluxo de sequência que leva a
a junção AND.
A diferença entre a divisão XOR que vimos no cap. 3 e o baseado em evento
A divisão XOR é que o primeiro modela uma escolha interna que é determinada pela
vêm de uma atividade de decisão, enquanto o último modela uma escolha que é determinada
Página 132
Fig. 4.13 Uma condição de corrida entre uma mensagem recebida e um temporizador
pelo ambiente de processo. 1 Uma escolha interna é determinada pelo resultado de um

atividade de decisão. Assim, a divisão XOR baseada em evento só pode ser seguida por interme-
diate capturando eventos como um cronômetro ou um evento de mensagem, ou recebendo atividades. Desde a
a escolha é atrasada até que um evento aconteça, a divisão baseada em evento também é conhecida como
escolha diferida . Não há junção XOR baseada em evento, então as ramificações que emanam de
uma divisão baseada em evento é mesclada com uma junção XOR normal.
Exercício 4.8 Modele o seguinte processo.

Uma rede de restaurantes envia um pedido de compra (PO) para reabastecer seus depósitos a cada quinta-feira
dia. O sistema de compras da rede de restaurantes espera receber uma "Resposta PO"
ou uma mensagem de erro. No entanto, também pode acontecer que nenhuma resposta seja recebida devido a
erros do sistema ou devido a atrasos no tratamento da OC por parte do fornecedor. Se nenhuma resposta for
recebido até sexta-feira à tarde ou se uma mensagem de erro for recebida, um gerente de compras no
a sede da rede de restaurantes deve ser notificada. Caso contrário, a resposta PO é processada
normalmente.
A divisão baseada em eventos pode ser usada como a contrapartida de uma decisão interna sobre
uma parte colaboradora. Por exemplo, uma escolha feita de dentro do pool de clientes para
enviar uma mensagem de aceitação ou rejeição para uma seguradora, precisa ser
correspondido por uma decisão orientada por evento no pool da seguradora para reagir à escolha feita
pelo cliente. Este exemplo é ilustrado na Fig. 4.14 .
Gateways baseados em eventos podem ser usados para evitar anomalias comportamentais
comunicação entre piscinas. Tome por exemplo o diagrama de colaboração entre o
serviço de leilão e o vendedor na Fig. 4.15 . Esta colaboração pode causar um impasse se o
vendedor já está cadastrado, pois esta parte irá aguardar a solicitação de criação de conta
mensagem que, nesse caso, nunca chegará. Para corrigir esse problema, precisamos permitir que
vendedor receberá a mensagem de confirmação de criação imediatamente, caso o vendedor seja
já cadastrado, conforme mostrado na Fig. 4.16 .
1 Especificamente, a divisão XOR do cap. 3 é chamado de divisão XOR baseada em dados, uma vez que o ramo a tomar é
com base na avaliação de duas ou mais condições nos dados que são produzidos por uma atividade de decisão.
Página 133
Fig. 4.14 Combinando uma escolha interna em uma parte com uma escolha baseada em evento na outra parte
Fig. 4.15 Um exemplo de colaboração de deadlock entre dois pools
Página 134
Fig. 4.16 Usando um gateway baseado em evento para consertar a colaboração de deadlock da Fig. 4.15
Ao conectar pools entre si por meio de fluxos de mensagens, certifique-se de verificar

a ordem dessas conexões para evitar deadlocks. Lembre-se, em particular, que
uma decisão interna em uma das partes deve ser correspondida por uma decisão baseada em eventos em
a outra parte, e que uma atividade com um fluxo de mensagens de saída enviará esse
mensagem após a conclusão da atividade, enquanto uma atividade com uma mensagem de entrada
o fluxo aguardará o início dessa mensagem.
Exercício 4.9 Corrija o diagrama de colaboração na Fig. 4.17 .
Agradecimento Este exercício é parcialmente inspirado por: Niels Lohmann: “Corrigindo

Deadlocking Service Coreographies Usando um gráfico baseado em simulação Edit Dis-
tância ”. LNCS 5240, Springer, 2008.
4.5 Tratamento de exceções
Exceções são eventos que desviam um processo de seu curso normal, ou seja, do que
é comumente conhecido como o cenário de “dia ensolarado”. Essas situações de “dia chuvoso” acontecem
caneta frequentemente na realidade, e como tal, devem ser modelados quando o objetivo é
para identificar todas as possíveis causas de problemas em um determinado processo. As exceções incluem
falhas de negócios, como uma exceção devido a um produto fora de estoque ou descontinuado,
e falhas de tecnologia, como falha do banco de dados, interrupção da rede ou lógica do programa
violação. Eles desviam o curso normal do processo, pois causam a interrupção
Página 135
4.5 Tratamento de exceções 115
Fig. 4.17 Um diagrama de colaboração entre um cliente, uma agência de viagens e uma companhia aérea
ou aborto do processo em execução. Por exemplo, no caso de um produto fora de estoque

de fato, um processo de pedido para pagamento pode precisar ser interrompido para solicitar o produto de
um fornecedor, ou abortado completamente se o produto não puder ser fornecido dentro de um determinado
prazo.
4.5.1 Processo de aborto
A maneira mais simples de lidar com uma exceção é abortar o processo de execução e sinalizar
um encerramento impróprio do processo. Isso pode ser feito usando um evento end terminate ,
como mostrado na Fig. 4.18 . Um evento de término de término (descrito como um evento de término marcado
Página 136
Fig. 4.18 Usando um evento de término para sinalizar o término impróprio do processo
com um círculo completo dentro), causa a cessação imediata da instância do processo em

seu nível atual e para qualquer subprocesso.
No exemplo da Fig. 4.18 - uma variante do empréstimo imobiliário que já vimos na
Fig. 4.3 - um empréstimo imobiliário é rejeitado e o processo é abortado se o requerente tiver
dívidas e / ou baixa responsabilidade. De uma semântica de token, o evento de encerramento destrói todos
tokens no modelo de processo e em qualquer subprocesso. Em nosso exemplo, isso é necessário
para evitar que o processo de deadlock na junção AND, uma vez que um token pode permanecer preso
antes do AND-join se houver alta responsabilidade e dívidas ou baixa responsabilidade e nenhuma dívida.
Observe que se um evento de encerramento for disparado de dentro de um subprocesso, ele
não causa o aborto do processo parental, mas apenas o do subprocesso, ou seja, o
O evento de término é propagado apenas para baixo em uma hierarquia de processo.
Exercício 4.10 Revise os exemplos apresentados até agora neste capítulo, usando o
encerrar o evento de forma adequada.
4.5.2 Exceções Internas
Em vez de abortar todo o processo, podemos lidar com uma exceção interrompendo
a atividade específica que causou a exceção. Em seguida, podemos iniciar uma recuperação
procedimento para trazer o processo de volta a um estado consistente e continuar sua execução,
e se isso não for possível, somente então aborte o processo completamente. BPMN fornece
o evento de erro para capturar esses tipos de cenário. Um evento de erro final é usado para
interromper o subprocesso de inclusão e lançar uma exceção. Esta exceção é então
capturado por um evento de erro de captura intermediário que está anexado ao limite de
o mesmo subprocesso. Por sua vez, este evento limite aciona o procedimento de recuperação
através de uma ramificação de saída que é chamada de fluxo de exceção .
Página 137
Fig. 4.19 Exceções internas do modelo de eventos de erro
O evento de erro é descrito como um evento com um marcador de relâmpago. Seguindo o

Convenções BPMN para eventos de lançamento e captura, o raio está vazio para o
pegando evento intermediário e cheio para o evento de lançamento final.
Um exemplo de eventos de erro é mostrado na Fig. 4.19 no contexto de nosso atendimento de pedido
processo de enchimento. Se houver uma exceção de falta de estoque, a aquisição de matéria-prima
als é interrompido e o procedimento de recuperação é acionado, que neste caso simplesmente
consiste em uma tarefa de notificar o cliente antes de abortar o processo. Em termos de
semântica de token, ao lançar um evento de erro final, todos os tokens são removidos de
o subprocesso envolvente (causando sua interrupção), e um token é enviado por meio
o fluxo de exceção proveniente do evento de erro de limite. Não há restrição
sobre os elementos de modelagem, podemos colocar no fluxo de exceção para modelar a recuperação
procedimento. Normalmente, concluiríamos o fluxo de exceção com uma terminação final
evento para abortar o processo, ou conectar este fluxo de volta ao fluxo de sequência normal se o
exceção foi tratada corretamente.
4.5.3 Exceções Externas
Uma exceção também pode ser causada por um evento externo que ocorre durante uma atividade.
Por exemplo, ao verificar a disponibilidade de estoque para o produto em uma compra
pedido, o vendedor pode receber um cancelamento do pedido do cliente. Sobre este
pedido, o vendedor deve interromper a verificação de disponibilidade de estoque e lidar com o pedido
cancelamento. Cenários como o acima são chamados de exceções não solicitadas, pois
originam-se externamente ao processo. Eles podem ser capturados anexando um
evento de mensagem intermediária para o limite de uma atividade, conforme mostrado na Fig. 4.20 . De
uma semântica de token, quando o evento de mensagem intermediário é acionado, o token é
removido da atividade envolvente, consequentemente causando a interrupção da atividade,
e enviado através do fluxo de exceção proveniente do evento de fronteira, para realizar
o procedimento de recuperação.
Página 138
Fig. 4.20 Eventos de limite

capturar eventos externos que podem
ocorrer durante uma atividade
Antes de usar um evento de fronteira, precisamos identificar o escopo dentro do qual o

processo deve ser receptivo a este evento. Por exemplo, no atendimento de pedido ex-
amplo, os pedidos de cancelamento de pedido só podem ser tratados durante a execução da tarefa
“Verificar disponibilidade de estoque”. Assim, fica aberto o espaço para ser receptivo a este evento
por esta única tarefa. Às vezes, o escopo deve incluir várias atividades. No
nesses casos, podemos encapsular as atividades interessadas em um subprocesso e em
anexe o evento ao limite do subprocesso.
Exercício 4.11 Modele a seguinte rotina para fazer login em um banco na Internet
contagem.
A rotina de login em uma conta bancária na Internet começa assim que as credenciais forem inseridas
do usuário foram recuperados. Primeiro, o nome de usuário é validado. Se o nome de usuário não for
válido, a rotina é interrompida e o nome de usuário inválido é registrado. Se o nome de usuário for válido,
o número de tentativas de senha é definido como zero. Então a senha é validada. Se este não for
válido, o contador para o número de tentativas é incrementado e se menor que três, o usuário
é solicitado a inserir a senha novamente, desta vez junto com um teste CAPTCHA para aumentar
o nível de segurança. Se o número de tentativas malsucedidas atingir três vezes, a rotina não
terrupted e a conta está congelada. Além disso, a validação do nome de usuário e senha pode
ser interrompido caso o servidor de validação não esteja disponível. Da mesma forma, o servidor para testar o
O CAPTCHA pode não estar disponível no momento do login. Nestes casos, o procedimento é inter-
interrompida após notificar o usuário para tentar novamente mais tarde. A qualquer momento durante a rotina de login, o
o cliente pode fechar a página web, resultando na interrupção da rotina.
4.5.4 Tempo limite de atividade
Outro tipo de exceção é aquela provocada pela interrupção de uma atividade que
está demorando muito para ser concluído. Para modelar que uma atividade deve ser concluída dentro
um determinado prazo (por exemplo, uma aprovação deve ser concluída dentro de 24 horas), podemos
anexar um evento temporizador intermediário ao limite da atividade: o temporizador está ativo
vated quando a atividade envolvente começa, e se dispara antes da conclusão da atividade,
provoca a interrupção da atividade. Em outras palavras, um evento temporizador funciona como um tempo limite
quando anexado ao limite de uma atividade.
Página 139
Fig. 4.21 Sem interrupção

eventos de fronteira pegam
eventos externos que ocorrem
durante uma atividade, e acionar
um procedimento paralelo sem
interrompendo o fechamento
atividade
Exercício 4.12 Modele o seguinte fragmento de processo.
Assim que um pedido de atacado for confirmado, o fornecedor transmite esse pedido para o carro
rier para a preparação do orçamento de transporte. A fim de preparar a cotação, o carro
rier precisa computar o plano de rota (incluindo todos os pontos da trilha que precisam ser percorridos
durante a viagem) e estimar o uso do trailer (por exemplo, se é uma carga completa, metade
track-load ou um único pacote). Por contrato, os pedidos de atacado devem ser despachados dentro de
quatro dias a partir do recebimento do pedido. Isso implica que as cotações de transporte devem ser
preparado dentro de 48 horas a partir do recebimento do pedido para permanecer dentro dos termos do
contrato.
4.5.5 Eventos sem interrupção e exceções complexas
Existem situações em que um evento externo ocorrendo durante uma atividade deve apenas
acionar um procedimento sem interromper a atividade em si. Por exemplo, no pedido
processo de atendimento, o cliente pode enviar uma solicitação para atualizar seus detalhes durante
a verificação de disponibilidade de estoque. Os detalhes devem ser atualizados no banco de dados do cliente
sem interromper a verificação de estoque. A fim de denotar que o evento limite é
não interrompendo , usamos uma borda dupla tracejada, como mostrado na Fig. 4.21 .
Exercício 4.13 Estenda o processo de avaliação dos pedidos de empréstimo da Solução 3.7 como
segue.
Um requerente que decidiu não combinar seu empréstimo com um plano de seguro residencial pode
mudar de ideia a qualquer momento antes de a avaliação de elegibilidade ser concluída. Se um pedido
para adicionar um plano de seguro é recebido durante este período, o provedor de empréstimo irá simplesmente
atualize o pedido de empréstimo com este pedido.
Eventos sem interrupção podem ser usados para modelar tratamento de exceção mais complexo
cenários. Considere novamente o exemplo na Fig. 4.19 e assuma que o cliente
envia uma solicitação de cancelamento do pedido durante a aquisição da matéria-prima. Nós pegamos
esta solicitação com um evento de mensagem de limite sem interrupção, e primeiro determine
Página 140
Fig. 4.22 Eventos de não interrupção podem ser usados em combinação com eventos de sinal para modelar
cenários de manipulação de exceção plex
a penalidade que o cliente terá de incorrer com base nas matérias-primas que
já foram encomendados. Encaminhamos essas informações ao cliente que então
pode decidir em 48 horas interromper o cancelamento, caso em que nada
está pronto ou prossiga (veja a Fig. 4.22 ). No último caso, lançamos um sinal de fim
evento . Este evento, representado por um marcador triangular, transmite um sinal definido por
o rótulo do evento, que pode ser capturado por todos os eventos de sinalização de captura com o
mesmo rótulo. Em nosso caso, lançamos um sinal de "Pedido cancelado" e captamos isso com um
evento de sinal intermediário correspondente no limite do subprocesso para adquirir
matéria prima. Este evento faz com que o subprocesso envolvente seja interrompido e
em seguida, aciona um procedimento de recuperação para cobrar do cliente, após o qual o processo é
abortado. Observamos que neste cenário a interrupção da atividade é desencadeada a partir de
dentro do processo, mas fora da própria atividade.
Observe que o evento de sinal é diferente do evento de mensagem, uma vez que tem
uma fonte, mas nenhum destino específico, enquanto uma mensagem tem uma fonte específica e um
alvo específico. Assim como as mensagens, os sinais também podem se originar de um processo modelado
em um diagrama separado.
Página 141
Fig. 4.23 Subprocessos de eventos podem ser usados no lugar de eventos de fronteira e para capturar eventos lançados
fora do escopo de um subprocesso específico
4.5.6 Interlúdio: Subprocessos do Evento
Uma notação alternativa para eventos de fronteira é o subprocesso de evento . Um evento sub-
o processo é iniciado pelo evento que de outra forma seria anexado ao limite
de uma atividade, e inclui o procedimento que seria acionado pelo limite
evento. Uma diferença importante com os eventos de fronteira é que os subprocessos do evento
não precisa se referir a uma atividade específica, mas pode modelar eventos que ocorrem durante o
execução de todo o processo. Por exemplo, a qualquer momento durante o atendimento do pedido
processo, o cliente pode enviar uma consulta sobre o status do pedido. Para lidar com isso
solicitação, que não é específica para uma determinada atividade deste processo, podemos usar um
subprocesso de evento, conforme mostrado na Fig. 4.23 .
O subprocesso do evento é representado em um retângulo pontilhado com cantos arredondados
que é colocado em um subprocesso expandido ou no processo de nível superior. Semelhante
para eventos de fronteira, um subprocesso de evento pode ou não interromper o
processo dependendo se seu evento de início está interrompendo ou não. Se for o evento inicial
não interrompe, isso é representado por uma borda tracejada (única).
Todas as regras sintáticas para um subprocesso se aplicam ao subprocesso do evento, exceto para
eventos de fronteira, que não podem ser definidos em subprocessos de eventos. Por exemplo, o
o subprocesso do evento também pode ser representado como um subprocesso recolhido. Nesse caso,
o evento inicial é representado no canto superior esquerdo do subprocesso do evento recolhido
retângulo para indicar como este subprocesso de evento é acionado.
Pergunta Subprocessos de evento ou eventos de limite?
Os subprocessos do evento são independentes, o que significa que devem ser concluídos com
um evento final. Isso tem a desvantagem de que o procedimento capturado dentro de um evento
Página 142
o subprocesso não pode ser conectado de volta ao restante do fluxo de sequência. A vantagem
é que um subprocesso de evento também pode ser definido como um modelo de processo global e, portanto,
ser reutilizado em outros modelos de processos da mesma organização. Outra vantagem é
que os subprocessos do evento podem ser definidos no nível de um processo inteiro, enquanto
os eventos de fronteira devem se referir a uma atividade específica. Assim, sugerimos o uso de eventos
subprocessos quando o evento que precisa ser tratado pode ocorrer durante o en-
processo de pneu, ou quando precisamos capturar um procedimento reutilizável. Para todos os outros casos,
eventos de fronteira são mais apropriados, uma vez que o procedimento desencadeado por esses eventos
pode ser conectado de volta ao resto do fluxo.
Exercício 4.14 Modelar o seguinte processo de negócios para reembolso de despesas.

Depois que um relatório de despesas é recebido de um funcionário, o funcionário é notificado do
recebimento do relatório. Em seguida, uma nova conta deve ser criada se o funcionário ainda não
tem um. O relatório é então revisado para aprovação automática. Valores abaixo de € 1.000 são
aprovado automaticamente enquanto os valores iguais ou superiores a € 1.000 requerem aprovação manual.
Em caso de rejeição, o colaborador deve receber um aviso de rejeição por e-mail. No caso de
aprovação, o reembolso é depositado diretamente na conta do funcionário. Em qualquer
tempo durante a revisão, o funcionário pode enviar uma Solicitação de retificação de valor. Naquilo
caso a retificação seja registrada e o relatório precise ser revisado novamente. Além disso, se
o relatório não é tratado em 30 dias, o processo é interrompido e o funcionário recebe
um e-mail de aviso de cancelamento para que ele possa reenviar o relatório de despesas do zero.
4.5.7 Remuneração de Atividades
Como parte de um procedimento de recuperação, podemos precisar desfazer uma ou mais etapas que tenham
já foi concluída, devido a uma exceção que ocorreu no sub
processo. Na verdade, os resultados dessas etapas, e possivelmente seus efeitos colaterais, podem não
mais desejados e por este motivo devem ser revertidos. Esta operação é
chamado de compensação e tenta restaurar o processo para um estado de negócios próximo ao
um antes de iniciar o subprocesso que foi interrompido.
Vamos nos aprofundar no subprocesso para envio e tratamento de faturas do pedido
exemplo de cumprimento e assumir que também esta atividade pode ser interrompida no
recepção de uma solicitação de cancelamento de pedido (ver Fig. 4.24 ). Depois de comunicar o
penalidade de cancelamento para o cliente, precisamos reverter os efeitos do envio
e do pagamento. Especificamente, se a remessa já foi feita, precisamos
tratar da devolução do produto, visto que se o pagamento já tiver sido feito, precisamos
reembolsar o cliente. Essas compensações podem ser modeladas por meio de uma compensação
manipulador . Um manipulador de compensação é composto de um evento de compensação de lançamento (um
evento marcado com um símbolo de retrocesso), um evento de compensação intermediário de captura e
uma atividade de compensação. O evento de compensação de lançamento é usado dentro da recuperação
procedimento de uma exceção para iniciar a compensação, e pode ser um intermediário
diate ou um evento final (no último caso, o procedimento de recuperação termina com o
compensação). O evento de compensação intermediário de captura é anexado àqueles
atividades que precisam ser compensadas - em nosso exemplo "Enviar produto" e "Re-
pagamento máximo ”. Esses eventos de limite capturam a solicitação de compensação e acionam
Página 143
Fig. 4.24 Compensando o envio e o pagamento
uma atividade de compensação específica para a atividade a ser compensada. Por exemplo o
a atividade de compensação para “Receber pagamento” é “Reembolsar cliente”. O limite
evento ary está conectado à atividade de compensação por meio de uma seta pontilhada com um
ponta de seta, chamada de associação de compensação (cuja notação é igual à de
a associação de dados). Esta atividade é marcada com o símbolo de compensação para indicar
citar a sua finalidade, não devendo haver fluxo de saída: caso a compensação
procedimento é complexo, esta atividade pode ser um subprocesso.
A compensação só é eficaz se a atividade anexada foi concluída. Uma vez que todos
atividades que poderiam ser compensadas são compensadas, o processo recomeça a partir de um
após o evento de compensação de lançamento, a menos que seja um evento final. Se a compensação
é para todo o processo, podemos usar um subprocesso de evento com uma compensação de início
evento no lugar do evento limite.
Nesta seção, vimos várias maneiras de lidar com exceções em negócios
cesso, do simples processo de aborto ao tratamento de exceções complexas. Antes de adicionar
exceções, é importante entender bem o cenário do dia ensolarado. Então comece por
modelando isso. Em seguida, pense em todas as situações possíveis que podem dar errado. Para cada um de
essas exceções, identifique que tipo de mecanismo de tratamento de exceção precisa ser
usava. Primeiro, determine a causa da exceção: interna ou externa. Em seguida, decida
se abortar o processo é suficiente, ou se um procedimento de recuperação precisa ser acionado.
Finalmente, avalie se a atividade interrompida precisa ser compensada como parte do
o procedimento de recuperação.
Página 144
Fig. 4.25 A reposição

o pedido é acionado sempre
os níveis de estoque caem abaixo de um
limite
Exercício 4.15 Modifique o modelo que você criou no Exercício 4.14 da seguinte maneira.
Se a denúncia não for tratada em 30 dias, o processo é interrompido, o funcionário recebe um
e-mail de aviso de cancelamento e deve reenviar o relatório de despesas. No entanto, se o reembolso-
para as despesas do funcionário já foi feito, um recall de dinheiro precisa ser feito,
para obter o dinheiro de volta do funcionário, antes de enviar o e-mail de aviso de cancelamento.
4.6 Processos e Regras de Negócios
Uma regra de negócios implementa uma política ou prática organizacional. Por exemplo, em
uma loja online, os clientes platinum têm um desconto de 20% para cada compra acima
€ 250. As regras de negócios podem aparecer em diferentes formas em um modelo de processo. Nós temos
vi-os modelados em uma atividade de decisão e na condição de um fluxo saindo
de uma divisão (X) OR (consulte o Exercício 3.5 para alguns exemplos). Uma terceira opção é usar
um evento BPMN dedicado denominado evento condicional . Um evento condicional causa o
ativação do seu fluxo de saída quando a respectiva regra de negócio for cumprida. Condi-
eventos internacionais, identificados por um marcador de página alinhado, podem ser usados como início ou intermediário
captura de eventos, incluindo após um gateway baseado em evento ou anexado a uma atividade
fronteira. Um exemplo de evento condicional é mostrado na Figura 4.25 .
A diferença entre um evento condicional intermediário e uma condição em um
fluxo é que o último é testado apenas uma vez, e se não for satisfeito o correspondente
o fluxo não é obtido (outro fluxo ou o fluxo padrão será usado no lugar). A condição
O evento opcional, por outro lado, é testado até que a regra associada seja satisfeita. Em outro
palavras, o token permanece preso antes do evento até que a regra seja satisfeita.
No exemplo da Fig. 4.25 , observe o uso do evento de erro no limite de
uma atividade de várias instâncias. Este evento interrompe apenas a instância de atividade que se refere
ao produto específico sendo descontinuado, ou seja, a instância a partir da qual o erro
evento é lançado. Todos os outros eventos de limite de interrupção, ou seja, mensagem, temporizador, sinal
e condicional, interromper todas as instâncias de uma atividade de várias instâncias.
Exercício 4.16 Modele o seguinte fragmento de processo de negócios.
Página 145
4.7 Coreografias de Processo 125
Em uma bolsa de valores, as variações dos preços das ações são monitoradas continuamente durante o dia. Um dia
começa quando o sino de abertura toca e termina quando o sino de fechamento toca. Entre o
dois sinos, cada vez que o preço das ações muda em mais de 10%, a entidade da mudança é
determinado pela primeira vez. Em seguida, se a mudança for alta, um alerta de "preço alto da ação" é enviado, caso contrário, um
O alerta de “preço baixo das ações” é enviado.
4.7 Coreografias de Processo
Às vezes, pode ser difícil enquadrar uma colaboração de negócios entre dois ou mais
partes, por exemplo, duas organizações, trabalhando diretamente no nível da colaboração
diagrama. Primeiro, o diagrama de colaboração é normalmente de nível muito baixo e se os termos
das interações
misturar entre
aspectos deas duas partes ainda
comunicação não estão internas.
com atividades claras, pode
Em ser confuso
segundo parauma parte pode não ser
lugar,
para expor suas atividades internas a outras partes (por exemplo, a lógica por trás de uma reclamação
a aprovação deve permanecer privada). Assim, pode ser oportuno focar primeiro no
interações que devem ocorrer entre todas as partes envolvidas, e na ordem em que
essas interações podem ocorrer. No BPMN, essas informações são capturadas por um chore-
diagrama de ografia . Um diagrama de coreografia é o modelo de processo das interações
ocorrendo entre duas ou mais partes. Esta visão de alto nível em atos de colaboração
como um contrato entre todas as partes envolvidas. Uma vez que este contrato foi elaborado, cada
parte pode pegar e refinar em seus processos privados ou, alternativamente, todas as partes
podem trabalhar juntos para refinar a coreografia em um diagrama de colaboração.
A Figura 4.26 mostra a coreografia para a colaboração no atendimento de pedidos de
Fig. 4.9 . Como podemos ver, uma coreografia é de fato um modelo de processo: é iniciada por
um ou mais eventos iniciais e concluídos por um ou mais eventos finais, as atividades são
conectados por meio de fluxos de sequência e gateways são usados para ramificação e mesclagem. o
característica principal é, no entanto, que uma atividade representa uma interação entre dois
partidos, em vez de uma unidade de trabalho. Uma interação pode ser unilateral (uma mensagem é
trocados) ou bidirecionais (uma mensagem é seguida por uma mensagem de retorno no sentido oposto
direção). Cada interação tem um iniciador ou remetente (a parte que envia a mensagem
sábio), e um destinatário ou receptor (a parte que recebe a mensagem, que pode responder
com uma mensagem de retorno). Por exemplo, a primeira atividade da Fig. 4.26 , “Enviar pedido
ordem de busca ”ocorre entre o cliente, que envia o pedido de compra, e
o vendedor, que o recebe.
Uma atividade de coreografia é representada como uma caixa com cantos arredondados, onde dois
faixas, uma na parte superior, a outra na parte inferior da caixa, representam as duas partes
envolvidos na interação capturada pela atividade. Uma faixa de luz é usada para o
iniciador enquanto uma faixa escura é usada para o destinatário. A posição de cada banda
com relação à caixa é deixada para o modelador, desde que as duas bandas estejam opostas
lados. Um envelope anexado a uma faixa por meio de uma linha tracejada representa a mensagem enviada
por essa parte. Este envelope é escurecido se for a mensagem de retorno de uma via dupla
interação.
Uma relação de precedência entre duas interações só pode ser estabelecida se o
o iniciador da segunda interação está envolvido na interação anterior (como
Página 146
Fig. 4.26 O diagrama de coreografia para o diagrama de colaboração na Fig. 4.9
remetente ou como receptor), exceto para a primeira interação. Desta forma, o remetente de
a segunda interação 'sabe' quando isso pode ocorrer. Por outro lado, se houver
não há dependências de ordem entre duas ou mais interações, podemos vinculá-las
interações por meio de uma divisão AND, como mostrado na Fig. 4.26 . Certifique-se, no entanto, de que
o remetente de cada interação após a divisão está envolvido na interação anterior
o separamento.
Uma divisão (X) OR modela os resultados de uma decisão interna que é tomada por um
festa. Isso impõe que os dados sobre os quais a decisão é tomada sejam disponibilizados
para essa parte por meio de uma interação antes da divisão. Em nosso exemplo, os dados exigidos por
a divisão XOR é extrapolada do pedido de compra, que é enviado ao vendedor
na interação antes da divisão. Além disso, todas as interações imediatamente
após a divisão deve ser iniciada pela parte que tomou a decisão. Na nossa
Por exemplo, isso é feito pelo vendedor. Na verdade, não faz sentido que uma decisão tomada
por uma parte resulta em uma interação iniciada por outra parte - esta última não
ser capaz de saber os resultados da decisão nessa fase.
A divisão XOR baseada em evento é usada quando os dados para fazer uma escolha não são ex-
colocada por meio de uma interação antes da divisão. Assim, as partes não envolvidas no
decisão só saberá sobre isso com o recebimento de uma mensagem. Isso impõe que
as interações após uma divisão baseada em eventos devem ter o mesmo remetente ou
o mesmo receptor. Por exemplo, usamos uma divisão baseada em eventos para modelar uma situação
onde um requerente espera por uma mensagem de confirmação que pode chegar de
um corretor ou diretamente da seguradora (a decisão de qual parte interagir com
Página 147
4.7 Coreografias de Processo 127
Fig. 4.27 O diagrama de coreografia entre um vendedor, um cliente e uma transportadora
o requerente é levado pelo corretor juntamente com a seguradora). A Figura 4.27 mostra
outro exemplo: aqui, um vendedor espera por uma das três mensagens possíveis de um cliente
cliente, representando três tipos diferentes de reclamação. A decisão é tomada pelo
o cliente e o vendedor não estão cientes disso até que a reclamação específica seja recebida.
As interações após uma divisão baseada em eventos podem ser restringidas por um cronômetro. Nisso
Por exemplo, se o vendedor não receber nenhuma mensagem após cinco dias, eles irão acionar
uma interação para faturar o cliente. Neste caso, todas as partes nas interações seguem
após a divisão deve estar envolvido na interação que precede a divisão, a fim de ser
ciente do cronômetro.
Exercício 4.17 A coreografia abaixo ilustra as interações que podem ocorrer

entre um vendedor, um cliente e uma transportadora após o frete ter sido entregue pelo
transportadora para o cliente. Use este diagrama como um modelo para construir a coluna correspondente
diagrama de trabalho. Observe o uso do evento terminate neste exemplo. Em um
coreografia, este evento só pode ser usado para denotar um resultado negativo e não para
encerrar à força a coreografia, uma vez que as partes não envolvidas na interação
ção anterior ao evento de término não saberia que o evento de término foi
alcançado.
Página 148
Interações complexas envolvendo mais de uma parte comercial são modeladas por meio de
uma atividade de sub-coreografia. Esta atividade é representada com o símbolo de mais (como
um subprocesso) e pode ter várias bandas representando todas as funções envolvidas. Para
exemplo, a interação "Lidar com reclamação de dano" na Fig. 4.27 ocorre entre as
vendedor, a transportadora e o cliente. As mensagens envolvidas em uma sub-coreografia
são visíveis apenas ao expandir o conteúdo da sub-coreografia, onde também
sua ordem se torna aparente.
Os artefatos não podem ser expressos explicitamente em uma coreografia por meio de objetos de dados ou dados
lojas. Isso ocorre porque uma coreografia não tem um mecanismo de controle central
para manter os dados.
Exercício 4.18 Modelar a coreografia e diagramas de colaboração para o seguinte

processo de aplicação de hipoteca na BestLoans.
O processo de pedido de hipoteca começa com o recebimento de um pedido de hipoteca de um

cliente. Quando um aplicativo é enviado pelo cliente ao corretor, o corretor pode negociar
com o próprio aplicativo, se o valor do empréstimo hipotecário estiver dentro do mandato
o corretor foi dado por BestLoans, ou encaminhe o pedido para BestLoans. Se o
o corretor lida com o aplicativo por conta própria, o que resulta em rejeição ou aprovação
carta sendo enviada de volta para o cliente. Se o corretor enviar uma carta de aprovação, ele encaminha o
detalhes desta aplicação para BestLoans para que a partir daí o cliente possa interagir diretamente
com a BestLoans por uma questão de desembolsar o empréstimo. Neste caso, BestLoans registra o
aplicativo e envia uma confirmação ao cliente.
O corretor só pode lidar com um determinado número de clientes por vez. Se o corretor não for capaz de
responder dentro de uma semana, o cliente deve entrar em contato com BestLoans diretamente. Neste caso, uma redução
sobre a taxa de juros é aplicada caso o pedido seja aprovado.
Se BestLoans lida diretamente com o aplicativo, seu departamento de hipotecas verifica o crédito
do cliente com o Bureau de Registro de Crédito. Além disso, se o valor do empréstimo for maior
de 90% do custo total da casa sendo comprada pelo cliente, o departamento de hipoteca
mento deve solicitar uma oferta de seguro hipotecário ao departamento de seguros. Depois destes
interações BestLoans ou envia uma carta de aprovação ou uma rejeição ao corretor, que o
corretor, em seguida, encaminha para o cliente (essa interação também pode acontecer diretamente entre o
departamento de hipotecas e o cliente, se nenhum corretor estiver envolvido).
Depois que uma carta de aprovação foi enviada ao cliente, o cliente pode aceitar ou rejeitar
a oferta, notificando-a diretamente ao departamento de hipotecas. Se o departamento de hipotecas
recebe uma notificação de aceitação, escreve uma escritura e a envia a um notário externo para
assinatura. O notário envia uma cópia da escritura assinada ao departamento de hipotecas. A seguir, o
o departamento de seguros inicia um contrato de seguro para a hipoteca. Finalmente, a hipoteca
departamento envia uma solicitação de desembolso ao departamento financeiro. Quando este pedido
for tratada, o departamento financeiro notifica o cliente diretamente.
A qualquer momento durante o processo de inscrição, o cliente pode perguntar sobre o status de seu
aplicação com o departamento de hipotecas ou com o corretor, dependendo de qual entidade é
lidar com o cliente. Além disso, o cliente pode solicitar o cancelamento do aplicativo.
Neste caso, o departamento de hipotecas ou o corretor computa o processamento do aplicativo
taxas, que dependem de quão longe está o processo de candidatura, e as comunica ao
cliente. O cliente pode responder dentro de dois dias com uma confirmação de cancelamento, na qual
caso o processo seja cancelado, ou com uma retirada do cancelamento, caso em que o processo
continuou. Se o processo tiver que ser cancelado, BestLoans pode precisar primeiro retirar o empréstimo (se
o desembolso foi feito), então anule o contrato de seguro (se um contrato de seguro
foi sacada) e, finalmente, anular a escritura (se uma escritura foi sacada).
Página 149
4.8 Recapitulação
Este capítulo nos forneceu os meios para modelar processos de negócios complexos. Nós
primeiro aprendeu como estruturar modelos de processos complexos em níveis hierárquicos via sub
atividades de processo. Subprocessos representam atividades que podem ser divididas em um
número de etapas internas, em comparação com as tarefas, que capturam unidades únicas de trabalho.
Um aspecto interessante dos subprocessos é que eles podem ser reduzidos para ocultar detalhes.
Também discutimos como maximizar a reutilização, definindo subprocessos globais dentro de um
coleção de modelos de processo e invocando-os por meio de atividades de chamada. Um subprocesso global
é modelado uma vez e compartilhado por diferentes modelos de processo em um repositório.
Em seguida, expandimos o tópico de retrabalho e repetição. Nós ilustramos como struc-
loops turados podem ser modelados usando uma atividade de loop. Além disso, apresentamos o
atividade multi-instância como uma forma de modelar uma atividade que precisa ser executada
várias vezes sem saber o número de ocorrências de antemão. Além disso, nós
vi como o conceito de multi-instanciação pode ser relacionado a coletas de dados e ex-
tendia a piscinas. Também discutimos subprocessos ad-hoc para captura não estruturada
repetição.
A seguir, expandimos vários tipos de eventos. Explicamos a diferença ser-
entre eventos de captura e lançamento e distinguido entre início, fim e entre
mediar eventos. Vimos como a troca de mensagens entre pools pode ser enquadrada por
eventos de mensagem e como eventos de cronômetro podem ser usados para modelar acionadores temporais para o
processo ou atrasos durante o processo. Em seguida, mostramos como capturar as condições de corrida
ções entre eventos externos ao processo, usando uma divisão baseada em eventos seguida por
eventos intermediários de captura.
Em seguida, mostramos como lidar com exceções. Exceções são situações que
desviar o processo de seu curso normal, devido a falhas de tecnologia ou negócios.
A maneira mais simples de reagir a uma exceção é abortar o processo por meio de um terminate
evento final. As exceções podem ser tratadas usando um evento intermediário de captura no
limite de uma atividade. Se o evento for capturado durante a execução da atividade, o
a atividade é interrompida e um procedimento de recuperação pode ser iniciado. Outro tipo de
exceção é o tempo limite da atividade. Isso ocorre quando uma atividade não é concluída
dentro de um determinado período de tempo. Um evento de limite também pode ser configurado para não interromper
a atividade anexada. Neste caso, o evento é denominado sem interrupção. Estes eventos
são convenientes para modelar procedimentos que devem ser lançados em paralelo a uma atividade
execução, quando ocorre um evento. Relacionado ao tratamento de exceções está a noção de
compensação por atividade. A compensação é necessária para reverter os efeitos de uma atividade
que foi concluído, se esses efeitos não forem mais desejados devido a uma exceção
que ocorreu.
Vimos então como as regras de negócios podem ser definidas em modelos de processo via condicional
eventos. Um evento condicional, disponível como um evento intermediário de início e captura, al-
permite que uma instância de processo seja iniciada, ou progrida, apenas quando o correspondente (booleano)
regra de negócios avaliada como verdadeira.
Concluímos este capítulo sobre modelagem de processo avançada, introduzindo
diagramas de ografia. Um diagrama de coreografia modela as interações que acontecem antes de
entre as várias partes de negócios que participam de um processo de negócios. Cada atividade em
Página 150
a coreografia captura uma interação entre um emissor e um receptor. Para estabelecer

lish uma dependência de ordem entre duas interações, o remetente da segunda atividade
deve estar envolvido no primeiro, caso contrário, esta parte não será capaz de determinar
quando enviar a mensagem relativa à segunda interação. Também discutimos o
regras para o uso de gateways em uma coreografia onde uma decisão é tomada por um
festa com base em dados ou eventos. Sub-coreografias podem ser usadas para modelar
interações envolvendo mais de duas partes, em uma veia semelhante a subprocessos em um
colaboração.
Solução 4.1
Solução 4.2 Possíveis subprocessos são “Solicitar compra”, “Problema de compra ou-
der ”,“ Receber mercadorias ”e“ Processar fatura ”. Destes, "Gerenciar fatura" poderia ser
compartilhado com outros processos de aquisição para pagamento da mesma empresa, por exemplo, com aquele de-
riscado no Exemplo 1.1 para BuildIT. Os primeiros três subprocessos são internos para
este processo de aquisição para pagamento, porque eles são específicos para o sistema empresarial que
apóia este processo.
Solução 4.3
1. No Exercício 3.9, o bloco de repetição vai da atividade "Registrar reivindicação" para a atividade
“Rever a rejeição da reivindicação”. O ponto de entrada para o ciclo é o arco de entrada de ativação
“Registrar reclamação”; os pontos de saída são arcos “reivindicação para ser aceito” e “reivindicação
rejeição aceita ”, estando a primeira dentro do bloco de repetição.
2. Na Solução 3.4, o bloco de repetição é composto por atividades “Verificar aplicação
completude do formulário ”,“ Devolver o formulário ao candidato ”e“ Receber
aplicação datada ”. O ponto de entrada para o ciclo é o arco de saída do XOR-
dividido, enquanto o ponto de saída é o arco "forma completa" que está dentro da repetição
quadra. Para modelar este ciclo com uma atividade em loop, precisamos repetir a atividade “Verificar
completude do formulário de inscrição ”fora da atividade de loop, conforme mostrado abaixo.
Página 151
Neste caso, usar uma atividade de loop ainda é vantajoso, pois reduzimos o tamanho
do modelo original se recolhermos o subprocesso.
Solução 4.4
Página 152
Solução 4.5
Página 153
Solução 4.6 A atividade “Enviar pacote de aceitação” pode ser substituída por um intermediário
enviar evento de mensagem; as atividades “Notificar cancelamento” e “Notificar aprovação” podem cada
ser substituído por um evento de mensagem final, removendo assim o último XOR-join e o un-
evento final digitado completamente. Observe que a atividade "Enviar cotação de seguro para casa" não pode
ser substituído por um evento de mensagem, uma vez que inclui a preparação da cotação. No
Na verdade, um rótulo mais apropriado para esta atividade seria “Prepare seguro residencial
citar". Da mesma forma, não podemos nos livrar da atividade "Rejeitar aplicação", pois esta atividade
altera o status do aplicativo antes de enviá-lo.
Solução 4.7
Solução 4.8
Página 154
Solução 4.9
Solução 4.10 Os eventos de término a seguir devem ser eventos de término: Fig. 4.12 -
“Callover diferido”, Fig. 4.14 - “Cotação rejeitada” nos pools de Cliente e Seguradora,
Fig. 4.18 - “Oferta rejeitada” no pool de Clientes, “Oferta cancelada” na Viagem
Pool da agência e “Pagamento recusado” no pool da companhia aérea.
Página 155
Solução 4.11
Solução 4.12
Página 156
Solução 4.13
Observe que no subprocesso "Avaliação do aplicativo", o aplicativo de empréstimo pode ter

dois estados possíveis: “verificado” ou “não verificado”. Para usar o aplicativo de empréstimo
em qualquer estado como entrada da atividade "Adicionar solicitação de seguro ao aplicativo de empréstimo", nós
não especifique nenhum estado para este objeto de dados no modelo acima.
Página 157
Solução 4.14
Página 158
Solução 4.15
Página 159
Solução 4.16
Nesta solução, não usamos um evento de limite para interromper o subprocesso para moni-
controlar as mudanças nos preços das ações, pois desta forma, o subprocesso só pararia porque
de uma exceção. Em vez disso, usamos a condição de loop para permitir que o subprocesso
conclua normalmente, ou seja, sem ser interrompido.
Página 160
Solução 4.17
Fig. 4.28 colaboração diagrama de peça 1 / 2 (fragmento de expedição de mercadorias)
Página 161
Fig. 4.29 colaboração diagrama de parte 2 / (fragmento manuseamento retorno mercadoria) 2
Na Solução 4.17 , usamos o evento de link para colocar o diagrama em duas páginas, uma vez que
o modelo era muito grande para caber em uma página. O evento de link não tem nenhum se-
mantics: é puramente um expediente notacional para quebrar um diagrama em várias páginas.
Um evento de link de lançamento intermediário (marcado com uma seta inteira) interrompe o processo
fluxo e fornece um link para o diagrama onde o fluxo continua; um intermediário
capturar evento de link (marcado com uma seta vazia) retoma o fluxo e indica
o diagrama de onde esse fluxo é retomado.
Página 162
Solução 4.18
Fig. 4.30 coreografia diagrama de peça 1 / 2
Página 163
Fig. 4.31 coreografia diagrama de parte 2 / 2
Página 164
Fig. 4.32 colaboração diagrama de peça 1 / 3 (fragmento de estabelecimento de Crédito)
Página 165
Fig. 4.33 colaboração diagrama de parte 2 / 3 (fragmento de desembolso empréstimo)
Página 166
Fig. 4.34 colaboração diagrama de parte 3 / 3 (sub-processos)
4.10 Exercícios Adicionais
Exercício 4.19
1. Modelar o processo de cumprimento da prescrição descrito no Exercício 1.6 . Use sub-

processos onde necessário e aninhá-los de forma adequada.
2. Existe algum subprocesso que pode ser potencialmente compartilhado com outros profissionais de negócios
cesses da mesma farmácia ou de outras farmácias?
Página 167
Exercício 4.20 Modelar o processo de negócios descrito no Exercício 3.12 usando um loop
atividade.
Exercício 4.21
1. Qual é a limitação de usar uma atividade de loop para modelar a repetição em vez de usar
ciclos não estruturados?
2. Qual é o requisito para um subprocesso ser usado como uma atividade de loop?
3. Modelar o processo de aquisição para pagamento descrito no Exemplo 1.1 .
Dica Use o modelo da Fig. 1.6 como ponto de partida para o item (3).
Exercício 4.22 Modele o seguinte processo de negócios.
A correspondência da parte é coletada diariamente pela unidade de processamento de correspondência. Dentro disto
unidade, o funcionário do correio classifica a correspondência não aberta nas várias áreas de negócios. O correio é então
distribuído. Quando o e-mail é recebido pelo registro, ele é aberto e classificado em grupos para
distribuição e, portanto, registrado em um registro de correio. Depois disso, o gerente assistente de registro
dentro do registro executa uma verificação de qualidade. Se o e-mail não for compatível, uma lista de requisitos
ções explicando os motivos da rejeição são compiladas e enviadas de volta ao partido. De outra forma,
os detalhes do assunto são capturados e fornecidos ao caixa, que assume as taxas aplicáveis
anexado ao correio. Neste ponto, o gerente assistente de registro coloca o recibo e copia
documentos em um envelope e os envia para o grupo. Enquanto isso, o caixa captura o
detalhes do partido e imprime o arquivo físico do tribunal.
Exercício 4.23 Modelar o seguinte processo para selecionar ganhadores do prêmio Nobel para
química.
Setembro: os formulários de nomeação são enviados. O comitê do Nobel envia confidenciais

formulários para cerca de 3.000 pessoas - professores selecionados em universidades de todo o mundo, não
bel laureados em física e química, e membros da Real Academia Sueca de
Ciências, entre outros.
Fevereiro: prazo para inscrições. Os formulários de nomeação preenchidos devem chegar ao nº-
Comitê bel até 31 de janeiro do ano seguinte. O comitê analisa o
nomeações e seleciona os candidatos preliminares. Cerca de 250-350 nomes são nomeados
já que vários indicados geralmente enviam o mesmo nome.
Março – maio: consulta com especialistas. O comitê do Nobel envia a lista dos pré-
candidatos liminários a especialistas especialmente nomeados para a sua avaliação do trabalho do
candidatos.
Junho-agosto: redação do relatório. O comitê do Nobel elabora o relatório com
recomendações a serem submetidas à Academia. O relatório é assinado por todos os membros da
o Comitê.
Setembro: o comitê apresenta recomendações. O comitê do Nobel submete seu relatório
com recomendações sobre os candidatos finais aos membros da Academia. O relatório
é discutido em duas reuniões da seção de química da Academia.
Outubro: os ganhadores do Nobel são escolhidos. No início de outubro, a Academia seleciona o prêmio Nobel
reatas em química por maioria de votos. A decisão é final e sem apelação. o
os nomes dos ganhadores do Nobel são então anunciados.
Dezembro: Prêmios Nobel recebem seu prêmio. A cerimônia de premiação do prêmio Nobel ocorre
em 10 de dezembro em Estocolmo, onde os laureados com o Nobel recebem seu prêmio Nobel, que
consiste em uma medalha e um diploma do Nobel e um documento confirmando o valor do prêmio.
Página 168
Agradecimento Este exercício é retirado de "Nomeação e Seleção de Chem-

istry Laureates ”, Nobelprize.org. 29 de fevereiro de 2012 (http://www.nobelprize.org/nobel_
prêmios / química / nomeação)
Exercício 4.24
1. Qual é a diferença entre eventos de arremesso e captura?

2. Qual é o significado de um evento anexado ao limite de uma atividade e o que
eventos podem ser anexados ao limite de uma atividade?
3. Qual é a diferença entre o evento final não tipado e o final final
evento.
Exercício 4.25 O que há de errado com o modelo a seguir?
Exercício 4.26 Estenda o modelo de processo de faturamento visto no Exercício 4.7 da seguinte maneira.
A qualquer momento após a falha da primeira transação, o cliente pode pagar a fatura diretamente para
o ISP. Em caso afirmativo, o processo de faturamento é interrompido e o pagamento é registrado. Este direto
o pagamento também deve cobrir as taxas de atraso, com base no número de dias passados desde o dia 7 (o
último dia para evitar incorrer em multas por atraso). Se o pagamento direto não incluir taxas atrasadas, o
O ISP envia uma notificação ao cliente de que as taxas serão cobradas na próxima fatura,
antes de concluir o processo.
Página 169
Exercício 4.27 O que há de errado com o modelo a seguir?
Exercício 4.28 Modele o seguinte processo de negócios em um fornecedor.

Depois que um fornecedor notifica um varejista sobre a aprovação de um pedido de compra, o fornecedor pode
receber uma confirmação de pedido, uma alteração de pedido ou um cancelamento de pedido do varejista. isto
pode acontecer que nenhuma resposta seja recebida. Se nenhuma resposta for recebida após 48 horas, ou se
um cancelamento de pedido for recebido, o fornecedor irá cancelar o pedido. Se uma confirmação de pedido
for recebido em 48 horas, o fornecedor processará o pedido normalmente. Se um pedido mudar
for recebido dentro de 48 horas, o fornecedor atualizará o pedido e solicitará novamente ao varejista
confirmação. O varejista pode alterar um pedido no máximo três vezes. Depois, o
o fornecedor cancelará automaticamente o pedido.
Exercício 4.29 Revise o modelo no Exercício 3.9 usando o evento terminate.

Quando uma reclamação é recebida, ela é primeiro registrada. Após o registro, a reclamação é classificada
levando a dois resultados possíveis: simples ou complexo. Se a reclamação for simples, o seguro
política é verificada. Para reivindicações complexas, tanto a apólice quanto os danos são verificados inde-
pendentemente. Um resultado possível da verificação da política é que a reivindicação é inválida. Nesse caso,
qualquer processamento é cancelado e uma carta é enviada ao cliente. No caso de um complexo
reclamação, isso implica que a verificação de danos seja cancelada se ainda não tiver sido concluída.
Após a (s) verificação (ões), é realizada uma avaliação que pode levar a dois resultados possíveis:
positivo ou negativo. Se a avaliação for positiva, a oficina é contatada para autorizar o
reparos e o pagamento é agendado (neste pedido). Em qualquer caso (se o resultado é
positivo ou negativo), uma carta é enviada ao cliente e o processo é encerrado. A qualquer momento
após o cadastro e antes do término do processo, o cliente poderá ligar para modificar o
detalhes da reclamação. Se uma modificação ocorrer antes do pagamento ser agendado, a reclamação é
classificado novamente (simples ou complexo) e o processo é repetido. Se um pedido para modificar o
o pedido for recebido após o agendamento do pagamento, o pedido será rejeitado.
Página 170
Um processo de tratamento de pedido começa quando um pedido é recebido. O pedido é registrado primeiro.
Se a data atual não for um dia útil, o processo aguarda até o dia útil seguinte
antes de proceder. Caso contrário, uma verificação de disponibilidade é realizada e um pedido de compra novamente
sponse é enviado de volta para o cliente. Se algum item não estiver disponível, qualquer processamento relacionado a
o pedido deve ser interrompido. Depois disso, o cliente precisa ser notificado de que o pedido de compra
não pode ser processado posteriormente. A qualquer momento durante o processo, o cliente pode enviar uma compra
pedido de cancelamento de pedido. Quando tal solicitação é recebida, o processo de manuseio do pedido de compra
é interrompido e o cancelamento é processado. O cliente também pode enviar um “Cliente
solicitação de mudança de endereço ”durante o processo de tratamento do pedido. Quando tal pedido for recebido,
é apenas registrado, sem nenhuma ação adicional.
Exercício 4.32
1. Qual é a diferença entre uma colaboração e um diagrama de coreografia?

Quais são os respectivos objetivos de modelagem?
2. Modele o diagrama de coreografia para o diagrama de colaboração que você modelou
no Exercício 3.7 .

processo de negócios para aplicações eletrônicas de desenvolvimento de terras.
O Sistema de Avaliação de Desenvolvimento Eletrônico Inteligente (Smart eDA) é um governo de Queensland
iniciativa governamental que visa fornecer um serviço intuitivo de preparação, alojamento e avaliação
aplicações de desenvolvimento de terras. O processo de negócios de desenvolvimento de terras começa com o
recebimento de um pedido de urbanização de um requerente. Após o recebimento de um terreno
aplicativo de desenvolvimento, o gerente de avaliação interage com o cadastro para recuperar
informação gráfica sobre a área de desenvolvimento designada. Esta informação é usada para
obter uma validação inicial da proposta de desenvolvimento da Câmara Municipal. Se o plano for
válido, o gerente de avaliação envia ao requerente uma cotação dos custos que incorrerão para
processar o aplicativo. Esses custos dependem do tipo de plano de desenvolvimento (para residências
ou fins comerciais), e na licença / licença que será necessária para o plano ser
aprovado. Se o candidato aceitar o orçamento, a avaliação pode começar.
A avaliação consiste em uma análise detalhada do plano de desenvolvimento. Primeiro, a avaliação
gerente interage com o Departamento de Estradas Principais (DMR) para verificar se há conflitos com
obras planejadas de desenvolvimento de estradas. Se houver conflitos, o aplicativo não pode prosseguir e
deve ser rejeitado. Nesse caso, o candidato é notificado pelo gestor da avaliação. o
o candidato pode desejar modificar o plano de desenvolvimento e submetê-lo novamente para avaliação. Nisso
caso, o processo é retomado de onde foi interrompido.
Se o plano de desenvolvimento incluir modificações no ambiente natural, a avaliação
gerente precisa solicitar uma licença de alteração de terra ao Departamento de Recursos Naturais
e Água (NRW). Se o plano for para fins comerciais, taxas adicionais serão aplicadas
para obter esta licença. Assim que a licença é concedida, esta é enviada pela NRW diretamente para o ap-
plicant. Da mesma forma, se a área de desenvolvimento designada for regulamentada por ambiente especial
leis de proteção, o gerente de avaliação precisa solicitar uma licença ambiental para o
Agência de Proteção Ambiental (EPA). Da mesma forma, uma vez que a licença é concedida, este é enviado
pela EPA diretamente ao requerente. Uma vez que a permissão e / ou licença exigidas foram obedecidas
retido, o gerente de avaliação notifica o Requerente da aprovação final.
A qualquer momento durante este processo, o requerente pode acompanhar o andamento de sua aplicação por
interagindo diretamente com o gerente de avaliação.
Gerente de avaliação, cadastro, DMR, NRW e EPA são todos entidades do governo de Queensland
laços. Em particular, NRW e EPA fazem parte do Departamento de Meio Ambiente e Recursos
Gestão dentro do Governo de Queensland.
Página 171

processo de negócios para solicitar atividades de manutenção na Sparks.
O processo de pedido de negócios começa com o recebimento de uma solicitação de ordem de serviço de um
cliente. Após o recebimento desta solicitação, o departamento de pedidos da Sparks estima
o uso esperado de suprimentos, peças e mão de obra e prepara uma cotação com a estimativa
custo total da atividade de manutenção. Se o veículo do cliente for segurado, o pedido
departamento interage com o departamento de seguros para recuperar os detalhes do cliente
plano de seguro para que possam ser anexados ao orçamento. O departamento de pedidos então
envia a cotação para o cliente, que pode aceitar ou rejeitar a cotação notificando
o departamento de pedidos dentro de cinco dias. Se o cliente aceitar a cotação, o pedido
departamento entra em contato com o departamento de armazém para verificar se as peças necessárias estão em estoque
antes de agendar uma reunião com o cliente. Se algumas peças não estiverem em estoque, o
departamento de pedidos faz o pedido das peças necessárias interagindo com um revendedor certificado e
aguarda uma confirmação do pedido do revendedor, a ser recebida em três dias. Se for
não recebido, o departamento de pedidos pede as peças novamente de um segundo revendedor. Se não houver resposta
é recebido do segundo revendedor também, o departamento de pedidos notifica o cliente de que o
as peças não estão disponíveis e o processo termina. Se as peças necessárias estão em estoque ou têm
pedido, o departamento de pedidos interage com uma garagem externa para reservar um
baia de serviço equipada e mecânico devidamente qualificado para realizar o trabalho. Uma confirmação
da nomeação é então enviada pela oficina para o departamento de pedidos, que encaminha o
confirmação para o cliente. O cliente tem uma semana para pagar Sparks, caso contrário, o
departamento de pedidos cancela a ordem de serviço, enviando um aviso de cancelamento para ambos
baia de serviço e o mecânico que foram reservados para este pedido. Se o cliente pagar
vez, a ordem de serviço é executada.
Exercício 4.35 Modelar a coreografia e os diagramas de colaboração para o seguinte
processo de negócios na MetalWorks. Tenha em mente que o propósito deste BPMN
diagrama serve como meio de comunicação entre as partes interessadas do negócio
e a equipe de TI, que deve construir um sistema de software para automatizar esse processo.
Um processo de produção sob encomenda (BTO), também conhecido como processo de produção sob pedido, é um "pedido ao pagamento"
processo onde os produtos a serem vendidos são fabricados com base em uma compra confirmada
ordem. Em outras palavras, o fabricante não mantém nenhum produto pronto para embarque em seus
estoque. Em vez disso, os produtos são fabricados sob demanda quando o cliente os encomenda.
Essa abordagem é usada no contexto de produtos customizados, como produtos metalúrgicos,
onde os clientes geralmente enviam pedidos de produtos com requisitos muito específicos.
Consideramos um processo BTO em uma empresa chamada MetalWorks. O processo começa quando
MetalWorks recebe um pedido de compra (PO) de um de seus clientes. Este PO é chamado de
"PO Cliente". O pedido de compra do cliente pode conter um ou vários itens de linha. Cada item de linha
refere-se a um produto diferente.
Ao receber um pedido de compra do cliente, um oficial de vendas verifica o pedido de compra para determinar se toda a linha
os itens do pedido podem ser produzidos dentro dos prazos indicados no pedido. Como um resultado
desta verificação, o oficial de vendas pode confirmar o pedido de compra do cliente ou perguntar ao cliente
para revisar os termos do pedido (por exemplo: alterar a data de entrega para uma data posterior). No
Em alguns casos extremos, o representante de vendas pode rejeitar o pedido, mas isso acontece muito raramente. E se
o cliente é solicitado a revisar o PO, o processo BTO será colocado em "stand-by" até que o
o cliente envia uma OC revisada. O oficial de vendas irá então verificar a OC revisada e
aceite, rejeite ou peça novamente ao cliente para fazer mais alterações.
Assim que um pedido é confirmado, o oficial de vendas cria uma "ordem de serviço" para cada item de linha no
PO Cliente. Em outras palavras, um pedido de compra do cliente dá lugar a vários pedidos de serviço (um
por item de linha). A ordem de serviço é um documento que permite aos funcionários da MetalWorks manter
acompanhamento da fabricação de um produto solicitado por um cliente.
Página 172
Para fabricar um produto, normalmente são necessárias várias matérias-primas. Alguns

essas matérias-primas são mantidas em estoque no armazém da MetalWorks, mas outras precisam
a ser obtido de um ou vários fornecedores. Assim, cada ordem de serviço é examinada por um
engenheiro de produção. O engenheiro de produção determina quais matérias-primas são necessárias
a fim de cumprir a ordem de serviço. O engenheiro de produção anota a ordem de serviço com um
lista de matérias-primas necessárias. Cada matéria-prima listada na ordem de serviço é verificada posteriormente
por um oficial de compras. O oficial de compras determina se a matéria-prima necessária
o material está disponível em estoque ou precisa ser pedido. Se o material tiver que ser pedido, o
oficial de compras seleciona um fornecedor adequado para a matéria-prima e envia uma PO para o
fornecedor selecionado. Este "pedido de uma matéria-prima" é chamado de "pedido de material" e é diferente
do pedido de compra do cliente. Um PO de material é um PO enviado pela MetalWorks para um de seus fornecedores,
ao passo que um pedido de compra de cliente é um pedido de compra recebido pela MetalWorks de um de seus clientes.
Assim que todos os materiais necessários para cumprir uma ordem de serviço estiverem disponíveis, a produção pode começar.
A responsabilidade pela produção de uma ordem de serviço é atribuída à mesma produção
engenheiro que examinou anteriormente a ordem de serviço. O engenheiro de produção é o responsável
para programar a produção. Uma vez que o produto foi fabricado, ele é verificado por um
inspetor de qualidade. Às vezes, o inspetor de qualidade encontra um defeito no produto e relata
para o engenheiro de produção. O engenheiro de produção então decide se: (i) o produto
deve passar por uma pequena correção; ou (ii) o produto deve ser descartado e fabricado novamente.
Assim que a produção for concluída, o produto é enviado ao cliente. Não há necessidade
esperar até que todos os itens de linha solicitados em um pedido de compra do cliente estejam prontos antes de enviá-los.
Assim que um produto estiver pronto, ele pode ser enviado ao cliente correspondente.
A qualquer momento (antes do envio do produto), o cliente pode enviar um “cancelar
pedido ”mensagem para um determinado pedido. Quando isso acontece, o diretor de vendas determina se o pedido
ainda pode ser cancelado e, em caso afirmativo, se o cliente deve ou não pagar uma multa. Se o
o pedido pode ser cancelado sem penalidade, todo o trabalho relacionado a esse pedido é interrompido e o
o cliente é notificado de que o cancelamento foi bem-sucedido. Se o cliente precisar pagar um
penalidade, o representante de vendas primeiro pergunta ao cliente se ele aceita pagar a multa de cancelamento.
Se o cliente aceitar pagar a multa de cancelamento, o pedido é cancelado e todo o trabalho
relacionado ao pedido é interrompido. Caso contrário, o trabalho relacionado ao pedido continua.
Neste capítulo, mostramos como os subprocessos podem ser usados para reduzir o complexo
de um modelo de processo, reduzindo o tamanho geral do modelo de processo . O tamanho é uma métrica
fortemente relacionado à compreensibilidade de um modelo de processo. Intuitivamente, o menor
o tamanho, mais compreensível será o modelo. Existem outras métricas que podem
ser medido a partir de um modelo de processo para avaliar sua compreensibilidade, por exemplo, o
grau de estruturação , o diâmetro e o coeficiente de conectividade . Um com
Uma discussão preensiva sobre as métricas do modelo de processo está disponível em [ 50 ]. As vantagens
de modularização de modelos de processo em subprocessos e técnicas automáticas são
coberto em [ 75 ], enquanto a correlação entre o número de objetos de fluxo e erro
a probabilidade em modelos de processo é estudada em [ 54 , 55 ].
O BPMN 2.0 oferece vários outros tipos de eventos além dos principais apresentados
neste capítulo. Por exemplo, o evento de link pode ser usado para modularizar um processo
sequencialmente (útil quando um modelo de processo não cabe em um único papel e tem que ser
dividido em vários papéis). Um exemplo de evento de link é mostrado nas Figs. 4,28 e
4,29 . O evento múltiplo pode ser usado para capturar um de um conjunto de eventos ou lançar um conjunto de
Página 173
eventos. Além disso, o BPMN 2.0 fornece outro tipo de diagrama além das colaborações
e coreografias. Este tipo de diagrama é chamado de diagrama de conversação e enfoca
nas mensagens trocadas por duas ou mais partes do processo, abstraindo do
ordem precisa em que as mensagens ocorrem. Todas essas construções são descritas em
detalhes na especificação BPMN 2.0 da OMG [ 61 ]. Existem também vários livros
que apresentam BPMN 2.0 por exemplo, entre outros [ 2 , 87 , 107 ].
Este capítulo conclui nossa cobertura da linguagem BPMN 2.0. Para mais em
formação nesta linguagem, apontamos para o site do BPMN: www.bpmn.org, Onde
a especificação oficial pode ser baixada em. Este site também fornece um link para um
pôster BPMN útil, um guia de referência rápida sobre todos os elementos BPMN e inclui
uma lista abrangente de livros sobre o assunto, bem como implementações de ferramentas que
apoiar este padrão.
Página 174
capítulo 5
Descoberta de Processo
Todas as verdades são fáceis de entender uma vez que são descobertas;
o objetivo é descobri-los.
Galileo Galilei (1564-1642)
Os capítulos anteriores mostraram como criar um modelo BPMN. Este capítulo vai
além disso, mostrando como criar modelos corretos e completos. Para isso
final, é preciso entender completamente o funcionamento de um processo de negócios, e
é preciso possuir as habilidades técnicas para representá-lo em um BPMN adequado
modelo. Esses dois tipos de habilidade dificilmente são unificados na mesma pessoa. Conseqüentemente,
várias partes interessadas com habilidades diferentes e complementares estão normalmente envolvidas
na construção de um modelo de processo.
Este capítulo apresenta os desafios enfrentados pelas partes interessadas envolvidas no
preparação para um modelo de processo. Em seguida, discutimos métodos para facilitar a comunicação eficaz
comunicação e coleta de informações neste ambiente. Dadas as informações coletadas em
desta forma, mostramos passo a passo como construir um processo e quais critérios devem
ser verificada antes que um modelo de processo seja aceito como uma representação autorizada de
um processo de negócios.
5.1 A configuração da descoberta do processo
A descoberta do processo é definida como o ato de reunir informações sobre um existente

processo e organizando-o em termos de um modelo de processo as-is. Esta definição em-
organiza a coleta e a organização de informações. Assim, a descoberta do processo é
uma atividade muito mais ampla do que modelar um processo. Claramente, a modelagem é parte de
esta atividade. O problema é que a modelagem só pode começar uma vez o suficiente em
formação foi montada. Na verdade, a coleta de informações muitas vezes prova ser
pesado e demorado na prática. Portanto, precisamos primeiro definir um
ambiente no qual as informações podem ser coletadas de forma eficaz. A fim de abordar estes
problemas, podemos descrever quatro fases de descoberta do processo:
1. Definição do cenário: Esta fase é dedicada à montagem de uma equipe em uma empresa
que será responsável por trabalhar no processo.

Página 175
156 5 Descoberta de Processo
2. Coleta de informações: esta fase se preocupa em construir um entendimento

do processo. Diferentes métodos de descoberta podem ser usados para adquirir informações
em um processo.
3. Conduzindo a tarefa de modelagem: Esta fase trata da organização da criação de
o modelo de processo. O método de modelagem fornece orientação para mapear o
processo de forma sistemática.
4. Garantindo a qualidade do modelo de processo: Esta fase visa garantir que o resultado
os modelos de processo atendem a diferentes critérios de qualidade Esta fase é importante para
estabelecer confiança no modelo de processo.
Normalmente, um ou vários analistas de processo são responsáveis por conduzir o mod

eling e análise de um processo de negócio. Muitas vezes, o analista de processo não está familiarizado
com todos os detalhes do processo de negócios. A definição da configuração do processo de dis-
cobertura é fundamental, pois ajuda o analista de processo a garantir o compromisso de
vários especialistas de domínio para fornecer informações sobre o processo. Estes domínios
os especialistas devem cobrir as perspectivas relevantes sobre o processo. Portanto, diferem
devem estar envolvidos especialistas no domínio ent . Um especialista de domínio é qualquer indivíduo que tenha
conhecimento íntimo sobre como um processo ou atividade é realizada. Normalmente, o do-
especialista principal é um participante do processo, mas também pode ser um proprietário ou gerente do processo
que trabalha em estreita colaboração com os participantes do processo que executam o processo. Além disso
fornecedores e clientes do processo podem ser considerados especialistas de domínio. o
os especialistas no domínio envolvidos devem ter uma visão conjunta de todas as atividades do processo.
É tarefa do proprietário do processo garantir o compromisso e o envolvimento de
essas pessoas. A seguir, vamos nos concentrar na relação entre o processo
analista e especialista de domínio, a fim de ilustrar três desafios do processo de descoberta
ery.
5.1.1 Analista de Processo Versus Especialista em Domínio
Um problema fundamental da descoberta do processo relaciona-se à questão de quem é

vai modelar o processo de negócios. Este problema é ilustrado pelo seguinte
exercício.
Exercício 5.1 Considere as duas tarefas a seguir e explique suas diferenças:
• A tarefa de modelar o processo de assinatura de um contrato de aluguel em sua cidade.

• A tarefa de modelar o processo de obtenção da placa do seu carro em Liecht-
enstein como residente estrangeiro.
O objetivo deste exercício é enfatizar uma diferença potencial de conhecimento

sobre processos. Se você já adquiriu algum conhecimento sobre mapeamento,
cesso com BPMN com a ajuda deste livro, você será capaz de criar uma inicial
modelo de processo para o processo de locação. A razão é que você não tem apenas modelagem
Página 176
5.1 A configuração da descoberta do processo 157
Tabela 5.1 Perfil típico de analista de processo e especialista de domínio
Aspecto Analista de Processo Especialista em Domínio
Habilidades de modelagem Forte limitado

Conhecimento do Processo limitado Forte
conhecimento, mas também algum conhecimento sobre o domínio do aluguel de um apartamento na sua cidade.
É provável que o caso seja diferente para obter a placa de um carro em Liechtenstein
como residente estrangeiro. Existem apenas alguns residentes estrangeiros que vivem em Liechtenstein,
nosso colega Jan vom Brocke sendo um deles. A maioria das outras pessoas não
saber como funciona esse processo. Se devemos modelar um processo que fazemos
não sei, temos que reunir uma grande quantidade de informações sobre ele para
para entender como funciona. Essa é exatamente a situação que normalmente enfrentamos
prática: um processo precisa ser modelado, temos as habilidades de modelagem necessárias, mas
temos apenas um conhecimento limitado do domínio correspondente.
A fim de descrever a situação típica de modelagem de uma forma plástica, distinguimos
adivinhar entre a função de um analista de processo e a função de um especialista de domínio . Em um real
projeto de modelagem, temos um ou alguns analistas de processo e vários especialistas de domínio.
Analistas de processo e especialistas de domínio têm funções complementares no ato do processo
descoberta, bem como diferentes intensidades, conforme mostrado na Tabela 5.1 . O analista de processo
é aquele que possui profundo conhecimento das técnicas de modelagem de processos de negócios.
Um analista de processo está familiarizado com linguagens como BPMN e hábil na organização
informações em termos de um diagrama de processo. No entanto, analistas de processo normalmente
uma compreensão limitada do processo concreto que deve ser modelado. Para
por isso, eles dependem das informações fornecidas por especialistas no domínio.
Os especialistas do domínio têm conhecimento detalhado da operação do negócio considerado
processo. Eles têm uma compreensão clara do que acontece dentro dos limites do
o processo, quais participantes estão envolvidos, quais informações são necessárias e quais
saída é gerada. No lado negativo, o especialista em domínio normalmente não está familiarizado
com linguagens como BPMN. Em algumas empresas, os especialistas em domínio até se recusam a recusar
cussão os modelos e diagramas de processo, porque eles se sentem mais confortáveis aderindo
à linguagem natural para explicar o que está acontecendo no processo. Como consequência
Portanto, os especialistas de domínio muitas vezes contam com um analista de processo para organizar seu processo
conhecimento em termos de um modelo de processo.
Nesta fase, deve ser enfatizado que a diferença nas habilidades de modelagem de
analistas de processo e especialistas de domínio resultam apenas de diferentes exposições a práticas
modelagem tica e treinamento de modelagem. Muitas empresas usam programas de treinamento para
melhorar as habilidades de modelagem de especialistas no domínio. Esse treinamento é um pré-requisito para
iniciativas de modelagem onde se espera que os participantes do processo modelem processos em
seus próprios. Por outro lado, existem empresas de consultoria especializadas em um
domínio particular. É uma vantagem quando analistas de processo de consultorias podem
ser atribuído a projetos de modelagem que são especialistas em modelagem e têm pelo menos um
certo nível de especialização no domínio.
Página 177
5.1.2 Três desafios de descoberta de processo
O fato de que o conhecimento de modelagem e o conhecimento de domínio estão frequentemente disponíveis em diferentes
diferentes pessoas em um projeto de modelagem têm fortes implicações. Isso dá origem a três
desafios essenciais da descoberta do processo, ou seja, conhecimento do processo fragmentado,
pensamento em casos e falta de familiaridade com linguagens de modelagem de processos.
Exercício 5.2 Um varejista de livros online enfrenta um problema com seu processo de pedido em termos
de tempo de processamento. Para identificar a causa raiz do problema, a empresa
decide que cada equipe envolvida com o processo de pedido deve modelar sua parte do
processo. Por que essa abordagem pode ser problemática?
O primeiro desafio da descoberta do processo está relacionado ao conhecimento do processo fragmentado

borda . Os processos de negócios definem um conjunto de atividades relacionadas logicamente. Essas atividades
são normalmente atribuídos a participantes especializados. Isso tem como consequência que um
analista de processo precisa reunir informações sobre um processo não apenas conversando com
um único especialista em domínio, mas com vários especialistas em domínio que são responsáveis por
as diferentes tarefas do processo. Normalmente, os especialistas de domínio têm um resumo
posição do processo geral e uma compreensão muito detalhada de sua própria tarefa.
Isso geralmente torna difícil confundir as diferentes visões. Em particular, um
especialista em domínio pode ter uma ideia diferente sobre qual saída deve ser esperada
de uma atividade upstream do que o especialista de domínio realmente trabalhando nela. Potencial
conflitos nas informações fornecidas devem ser resolvidos. Também é frequentemente o caso de
as regras do processo não são definidas explicitamente em detalhes. Nessas situações, faça-
principais especialistas podem operar com suposições divergentes, que muitas vezes não são exatamente
consistente. O conhecimento fragmentado do processo é uma das razões pelas quais o processo de dis-
Covery requer várias iterações. Tendo recebido contribuições de todos os domínios relevantes
especialistas, o analista de processo deve fazer propostas para resolver inconsistências,
o que novamente requer feedback e, eventualmente, aprovação dos especialistas do domínio.
O segundo desafio da descoberta do processo decorre do fato de que o domínio ex-
perts normalmente pensam em processos em um nível de caso . Especialistas em domínio acharão fácil
para descrever as atividades que realizaram para um caso específico, mas eles podem ter
problemas em responder a perguntas gerais sobre como um processo funciona em geral
maneira. Os analistas de processo costumam obter respostas como "você não pode realmente generalizar, todos
caso é diferente ”para tal pergunta. Na verdade, é tarefa do analista de processo
organizar e abstrair das informações fornecidas pelo especialista no domínio
de forma que um modelo de processo definido sistematicamente possa surgir. Portanto,
é necessário fazer perguntas específicas sobre o que acontece se alguma tarefa for concluída,
e se certas condições forem válidas ou não, e se certos prazos não forem
conheceu. Desta forma, o analista de processo pode fazer engenharia reversa das condições que regem
as decisões de roteamento de um processo de negócios.
O terceiro desafio da descoberta do processo é o resultado do fato de que os especialistas no domínio
normalmente não estão familiarizados com as linguagens de modelagem de processos de negócios . Esta observação
ção já deu origem à distinção de especialistas de domínio e analistas de processo. No
neste contexto, o problema não é apenas que os especialistas no domínio muitas vezes não são treinados para
Página 178
5.1 A configuração da descoberta do processo 159
criam modelos de processos, mas também não são treinados para ler
modelos de processamento que outros criaram. Essa falta de treinamento pode dificultar o ato de
buscando feedback para um esboço de um modelo de processo. Nesta situação, normalmente não é
apropriado para mostrar o modelo ao especialista do domínio e solicitar correções. Até
se os especialistas de domínio entendem bem os rótulos de atividades, muitas vezes eles não
suportar as partes sofisticadas do fluxo de controle capturadas no modelo. Portanto, o
analista de processo tem que explicar o conteúdo do modelo de processo em detalhes, por exemplo
ple, traduzindo a notação formal do modelo de processo para uma linguagem natural
descrição com o mesmo significado. Os especialistas em domínio se sentirão à vontade para responder
a essas explicações de linguagem natural, apontando aspectos que precisam de modificação
ou maiores esclarecimentos de acordo com sua compreensão do processo.
5.1.3 Perfil de um Analista de Processo
As habilidades de um analista de processo desempenham um papel importante na descoberta do processo. Especialista

analistas de processo podem ser descritos com base em um conjunto de disposições gerais, suas
comportamento em um projeto de análise de processo, e em termos do processo resultante de
seus esforços.
Exercício 5.3 Você é o gerente de uma empresa de consultoria e precisa contratar

uma pessoa para o projeto de análise de processo recém-assinado com um varejista de livros online.
Considere os dois perfis a seguir, quem você contrataria como analista de processo?
• Mike Miller tem dez anos de experiência de trabalho com um varejista online. Ele tem
trabalhei em diferentes equipes envolvidas com o processo de pedidos do varejista online.
• Sara Smith tem cinco anos de experiência trabalhando como analista de processos no banco-
setor ing. Ela está familiarizada com duas ferramentas diferentes de modelagem de processos.
Pesquisas sobre experiência na área geral de análise e projeto de sistemas encontraram

que existem certos traços pessoais que podem ser observados no processo de especialista
analistas. Aparentemente, parece existir um conjunto de certas disposições pessoais que
ajudar a se tornar um especialista em análise de processos. Uma das maneiras de descrever por
A sonalidade é o chamado Modelo de Cinco Fatores, desenvolvido na pesquisa psicológica.
Em essência, este modelo contém as dimensões abertura (apreciando a arte, emo-
ção e aventura), consciência (tendência à autodisciplina, realização
e planejamento), extroversão (ser positivo, enérgico e buscar companhia), concordar
habilidade (ser compassivo e cooperativo) e neuroticismo (ser ansioso,
deprimido e vulnerável). Esses fatores também foram estudados em relação aos seus
conexão com analistas especializados. Esses especialistas parecem ser fortes em termos
de conscienciosidade e extroversão. Na verdade, os projetos de descoberta de processos requerem um
planejamento cuidadoso e coordenação de entrevistas com vários especialistas no domínio

em um período limitado de tempo. Além disso, os projetos de descoberta de processos às vezes são
sujeito à política interna da empresa em situações em que a agenda de diferentes pro-
partes interessadas do processo não está totalmente claro ou onde as partes interessadas podem temer perder
Página 179
sua posição. Em tal ambiente, é valioso ter um energético e ex

analista de processo transversal envolvido, que é capaz de criar uma atmosfera positiva para
trabalhando no projeto.
A descoberta de processos em geral pertence à categoria de problemas mal definidos. este
significa no início de um projeto de descoberta de processo, não é exatamente claro quem
dos especialistas do domínio devem ser contatados, qual documentação pode ser utilizada,
e que agenda as diferentes partes interessadas podem ter em mente. A maneira como
analistas especialistas navegam por um projeto é fortemente influenciado por experiências com
projetos anteriores. Portanto, há uma grande diferença entre a maneira como os novatos
e analistas especializados conduzem a compreensão e solução de problemas. Em termos de
compreensão do problema, foi observado que analistas especializados abordam um projeto
em termos de quais são as coisas que precisam ser alcançadas. Os novatos não têm esse objetivo claro
orientação e tentar abordar as coisas de uma forma ascendente. Isso significa que muitas vezes
comece investigando o material que é facilmente acessível e converse com pessoas que prontamente
responder. Os especialistas trabalham de maneira diferente. Eles têm um conjunto explícito de gatilhos e
heurísticas disponíveis a partir de experiências com projetos anteriores. Eles tendem a pagar específicos
atenção aos seguintes aspectos:
• Trazer as pessoas certas a bordo. Se você precisa falar com um determinado participante do processo
pant, certifique-se de que seu supervisor imediato e aquele acima deles estejam a bordo
e que o participante do processo sabe que sua hierarquia apóia seu envolvimento
no esforço de descoberta do processo.
• Ter um conjunto de hipóteses de trabalho sobre como o processo está estruturado em diferentes
níveis de detalhes. Para avançar com o projeto, é importante ter um
conjunto curto e preciso de hipóteses de trabalho, que eles desafiam passo a passo.
Prepare um amplo conjunto de perguntas e suposições a serem discutidas em workshops
ou entrevistas.
• Identificar padrões nas informações fornecidas por especialistas do domínio. Estes podem
ser utilizado para construir partes de um modelo de processo. Essas informações
normalmente referem-se à estrutura de controle específica. Por exemplo, declarações sobre certos
atividades sendo alternativas, exclusivas ou sujeitas a certas condições geralmente apontam
para o uso de gateways XOR. De forma semelhante, declarações sobre atividades sendo
independente de outra, ou às vezes estando em uma ou outra ordem, muitas vezes sugere
simultaneidade gest. Pelo conhecimento de tais padrões, muitas vezes é fácil para o especialista
analistas para esboçar processos.
• Prestar atenção à estética do modelo. Os modelos precisam ter uma boa aparência para serem envolventes
para um grande público. Isso não só ajuda a ter um modelo resultante que é
fácil de entender pelas partes interessadas, mas também valioso em todo o processo de
criando o modelo. Os especialistas também usam o nível certo de abstração. Por exemplo,
você não deve mostrar um modelo superdetalhado para um gerente de nível executivo. o
importância do layout é aparente pelo fato de que os analistas especialistas costumam pegar metade
do tempo ao criar um modelo para reposicionar seus elementos de uma forma significativa
maneira.
Página 180
5.2 Métodos de descoberta 161
5.2 Métodos de descoberta
Como agora temos uma ideia aproximada das tarefas que um analista de processo tem e quais
capacidades e limitações que ele deve ter em mente ao interagir com o domínio
especialistas, recorremos a diferentes técnicas para reunir informações sobre um processo.
Em geral, distinguimos três classes de técnicas de descoberta, a saber, evidências
descoberta baseada, descoberta baseada em entrevista e descoberta baseada em workshop. Lá
são pontos fortes e limitações, que discutiremos posteriormente.
Exercício 5.4 Imagine que você receba a tarefa de modelar o processo de

como um pedido de livro é processado pelo seu varejista de livros online favorito. Como você pode
reúne sistematicamente as informações necessárias sobre esse processo?
5.2.1 Descoberta Baseada em Evidências
Várias peças de evidência estão normalmente disponíveis para estudar como uma
cess funciona. Aqui, discutimos três métodos: análise de documentos, observação e
descoberta automática de processos.
A análise de documentos explora o fato de que geralmente há material de documentação
disponível que pode ser relacionado a um processo existente. No entanto, existem alguns potenciais
questões iniciais com análise de documentos. Primeiro, a maior parte da documentação disponível
sobre as operações de uma empresa não está prontamente organizado de uma forma orientada para o processo
maneira. Pense em um organograma, por exemplo. Ele define os departamentos e po-
sições, é útil identificar um conjunto potencial de partes interessadas no processo. Tal material
pode ajudar a estruturar as fases de um processo. Por exemplo, no caso do nosso livro online
varejista, pode revelar que o departamento de vendas, o departamento de logística e o
o departamento financeiro provavelmente estará envolvido com o pedido do livro. Segundo, o nível
de granularidade do material pode não ser apropriado. Enquanto um organograma
desenha uma imagem abstrata de uma empresa, muitas vezes há muitos documentos que
resumir partes de um processo em um nível muito granular. Muitas empresas documentam
ment instruções de trabalho detalhadas para tarefas e perfis de trabalho para posições. Esses são
normalmente muito detalhado para modelagem de processos. Terceiro, muitos dos documentos são
apenas parcialmente confiável. Para um projeto de descoberta de processo, é importante identificar
como um processo funciona na realidade. Muitos documentos não mostram necessariamente a realidade.
Alguns deles estão desatualizados e alguns afirmam como as coisas deveriam funcionar idealisticamente,
e não como as pessoas os conduzem na realidade. A vantagem da análise de documentos
é que um analista de processo pode usá-los para se familiarizar com certas partes de um processo
e seu ambiente, e também para formular hipóteses. Isso é útil antes de falar -
para especialistas no domínio. No lado negativo, um analista de processo deve ter em mente que
os documentos não refletem necessariamente a realidade do processo.
Se usarmos a observação como método de descoberta, seguiremos diretamente o processo
de casos individuais a fim de compreender como funciona um processo.
O analista de processo pode desempenhar o papel ativo de um cliente de um processo ou o
Página 181
papel passivo de um observador. Como parte da função do cliente ativo , o analista de processo
aciona a execução de um processo e registra as etapas que são executadas e o conjunto
de opções que são oferecidas. Por exemplo, no caso do varejista de livros online, o
o analista pode criar um novo pedido de livro e acompanhar quais atividades são realizadas
ao lado do varejista. Isso fornece uma boa compreensão dos limites de
o processo e seus marcos essenciais. No entanto, o analista verá apenas aqueles
partes do processo que requerem interação com o cliente. Todo backoffice pro
processamento permanece uma caixa preta. O papel de um observador passivo é mais apropriado para
compreensão de todo o processo, mas também requer acesso às pessoas e pontos turísticos
onde o processo está sendo trabalhado. Normalmente, esse acesso requer a aprovação de
os gerentes e supervisores das equipes correspondentes. Além disso, pode haver
ser um problema potencial com as pessoas agindo de forma diferente, porque estão cientes de estar
observado. As pessoas geralmente mudam seu comportamento sob observação de tal forma
que trabalhem com mais rapidez e diligência. É importante ter isso em mente quando
os tempos de execução devem ser estimados. No entanto, a descoberta baseada na observação tem
a vantagem de revelar como um processo é conduzido na realidade hoje, que está em
contraste com a análise de documentos que normalmente captura o passado.
Uma terceira opção de descoberta automática de processo emerge da extensa op-
suporte racional de processos de negócios fornecido por vários sistemas de informação.
A descoberta automática de processos usa logs de eventos que são armazenados por essas informações
sistemas de informação. Esses dados de evento devem ser registrados de tal forma que cada evento
pode ser exatamente relacionado a três coisas: um caso individual do processo, um específico
atividade do processo e um momento preciso. Se essas três informações
estão disponíveis nos logs de eventos, então as técnicas de descoberta automática de processos podem
ser usado para reconstruir o modelo de processo, por exemplo, para o varejista de livros online.
Uma vez que esta abordagem compartilha algumas características com mineração de dados, onde o significado
informações completas são extraídas de dados granulares, essas técnicas de
a descoberta de processos é incluída na área de pesquisa de mineração de processos. A vantagem
tática da descoberta automática de processos é que os logs de eventos capturam a execução de um
processo com muita precisão, incluindo informações sobre os tempos de execução. Uma limitação
é que algumas informações de log podem ser enganosas. Este pode ser o caso se um
o sistema trava de tal forma que os logs não são armazenados corretamente. Esses tipos de falha relacionados a
um armazenamento defeituoso de logs de eventos é resumido com o termo ruído. Além disso, o
os modelos resultantes da mineração de processos podem não ser diretamente compreensíveis. Processo
o comportamento pode ser muito complexo, de modo que os modelos gerados dificilmente são legíveis.
Nesse caso, os logs devem ser filtrados ou agrupados para obter modelos que ajudam
compreender o processo.
5.2.2 Descoberta baseada em entrevista
A descoberta baseada em entrevista refere-se a métodos que se baseiam no domínio de entrevistas

perts sobre como um processo é executado. Com esses métodos, temos que explicitamente
levar em consideração os desafios da descoberta do processo, ou seja, o fato de que o processo
Página 182
o conhecimento está espalhado por diferentes especialistas de domínio, que os especialistas de domínio tipificam
pense em termos de casos individuais, e que os especialistas do domínio muitas vezes não são familiares
familiarizado com linguagens de modelagem de processos de negócios. Isso tem implicações em como o
as entrevistas podem ser agendadas e quais fases e iterações são necessárias.
Exercício 5.5 Considere que o processo de pedido de sua livraria online favorita
tem dez atividades principais que são conduzidas por pessoas diferentes. Quanto tempo faz
você precisa aproximadamente para criar um modelo de processo que seja validado e aprovado
pelo proprietário do processo? Faça suposições apropriadas.
Mencionamos que o conhecimento do processo é tipicamente fragmentado devido a

socialização e divisão do trabalho. Por este motivo, as entrevistas devem ser realizadas
com vários especialistas de domínio envolvidos no processo. Como o analista de processo pode
ainda não entendo os detalhes do envolvimento de diferentes especialistas no domínio,
pode ser necessário para descobrir o processo passo a passo. Existem duas estratégias
disponível para agendamento de entrevistas: começando de trás para os produtos e re-
resultados do processo e começando do início, avançando. Regente
entrevistas de uma maneira direta permite seguir o fluxo de processamento na ordem de
como isso se desenrola. Isso é particularmente útil para entender quais decisões são
tomadas em um determinado estágio. No entanto, seguir o processamento de forma regressiva tem
também vantagens. Pessoas que trabalham em um processo exigem que certas informações estejam disponíveis
para a realização de seu trabalho, e esta perspectiva torna mais fácil considerar o que tem
a ser alcançada antes que uma atividade específica possa ser realizada. Ambas as perspectivas, a
as perspectivas downstream e upstream são importantes ao entrevistar o domínio
especialistas. Com cada parceiro de entrevista, deve ser esclarecido qual contribuição é esperada
de atividades anteriores anteriores, quais decisões são tomadas e em que formato
os resultados de uma atividade são encaminhados para a parte subsequente.
Os desafios da descoberta enfatizam que a experiência do analista de processo é
necessário para abstrair informações sobre como casos individuais são executados em ordem
para construir modelos de processo significativos. Normalmente, o analista de processo reúne
formação sobre o processo em entrevistas e posteriormente organiza o material offline
antes de construir um modelo de processo inicial. Como consequência, entrevistar um do-
O especialista principal geralmente é conduzido em iterações diferentes. Após uma entrevista inicial, o
analistas de processo cria um modelo de processo de rascunho, que é então discutido com o do-
principal especialista em termos de correção e integralidade. Aqui é importante perguntar
o que acontece se algo der errado ou como casos inesperados são tratados. este
A entrevista de feedback geralmente desencadeia outra rodada de retrabalho. Em alguns casos, o sec-
A segunda rodada de feedback leva à aprovação do modelo de processo. Em outros casos, um terceiro
a rodada de feedback é necessária para verificar o modelo de processo retrabalhado novamente. Frequentemente,
especialistas de domínio se sentem mais confortáveis com entrevistas de formato livre, onde podem desconsiderar
cuss o processo com um nível de detalhe que eles acham apropriado. Entrevistas estruturadas,
em contraste, pode criar a sensação de percorrer uma lista de verificação, com o efeito de
especialistas em domínio retêm informações importantes que não são explicitamente solicitadas
para.
É uma força da descoberta baseada em entrevista que a situação de entrevista fornece
uma imagem rica e detalhada do processo e das pessoas que nele trabalham. Tem o
Página 183
potencial para revelar percepções inconsistentes que diferentes especialistas de domínio podem ter
sobre como um processo funciona. Também ajuda o analista de processo a entender o processo
em detalhe. No entanto, é um método de descoberta que exige muito trabalho. Várias iterações são
necessário para chegar a um ponto onde os especialistas do domínio se sintam confortáveis com a forma como um
processo é descrito em um modelo de processo.
Uma armadilha recorrente das entrevistas é que, quando questionados sobre como um determinado processo ou ac-
atividade é realizada, o entrevistado tende a descrever a forma normal de processamento.
Assim, as exceções tendem a ser deixadas de lado. Em outras palavras, a entrevista acaba sendo encoberta
ing apenas o cenário de “dia ensolarado”. Uma maneira de evitar essa armadilha é reservar tempo
durante a entrevista para enfocar os cenários de “dias chuvosos”. Perguntas que podem ser
usados para iniciar a discussão sobre o cenário de dia chuvoso são: "Como você lidou com o seu
cliente mais difícil? ”,“ Qual foi o caso mais difícil em que trabalhou? ”.
Esta técnica permite descobrir variações ou exceções no processo que,
embora não seja necessariamente frequente, tem um impacto suficiente no processo para valer a pena
documentando.
5.2.3 Descoberta baseada em oficina
A descoberta baseada em workshop também oferece a oportunidade de obter um rico conjunto de informações
no processo de negócios. Embora nem sempre seja o caso, a configuração pode
ser organizado de forma que as contribuições para a discussão sejam imediatamente
usado para modelar o processo. Em contraste com as entrevistas, não envolve apenas mais participação
ipants, mas também um conjunto maior de funções. Funções adicionais são necessárias para facilitar o
discussão e para operar a ferramenta de modelagem de processos. O facilitador cuida
de organizar as contribuições verbais dos participantes. O operador da ferramenta é re-
responsável por inserir diretamente os resultados da discussão na ferramenta de modelagem. De várias
especialistas de domínio também participam, tanto quanto o proprietário do processo e o processo e
alyst . O envolvimento com este extenso conjunto de pessoas requer preparação diligente
e agendamento. Além disso, o processo não será esboçado em detalhes apenas
uma sessão. Pode-se esperar que sejam necessárias três a cinco sessões de meio dia.
No início de um esforço de descoberta de processo, quando ainda não há informações disponíveis
capaz de modelar o processo, pode ser benéfico ter um mais leve e
abordagem participativa na organização dos workshops. Uma técnica para envolver o
participantes do workshop no esforço de descoberta é pedindo aos participantes do workshop para
construir um mapa do processo usando notas adesivas. O facilitador começa com um bloco de
Post-it. Cada nota adesiva deve representar uma tarefa ou evento. O grupo começa
para discutir como o processo normalmente começa. O facilitador então escreve o nome do
(supostamente) a primeira tarefa ou evento em uma nota adesiva e a afixa na parede. Então o
o facilitador pergunta o que pode acontecer a seguir. Os participantes começam mencionando um ou mais
tarefas possíveis. O facilitador escreve essas atividades em novos post-its e começa
afixando-os na parede, organizando-os, por exemplo, da esquerda para a direita ou de cima para
inferior para capturar a ordem das atividades. Nesta fase, nenhuma linha é desenhada entre
as tarefas e nenhum gateway são descobertos. O objetivo deste exercício é construir
Página 184
Tabela 5.2 Pontos fortes e limitações relativos dos métodos de descoberta de processos
Aspecto Provas Entrevista Oficina
Objetividade Alto médio-alto médio-alto

Riqueza médio Alto Alto
Consumo de Tempo médio baixo médio médio

Imediato de Feedback baixo Alto Alto
um mapa de atividades e sua ordenação temporal. Às vezes, os participantes discordam

se algo é uma tarefa ou duas tarefas. Se o desacordo não puder ser resolvido,
as duas tarefas podem ser escritas como duas notas adesivas e essas duas notas adesivas relacionadas são
colados um ao lado do outro. O facilitador também precisa prestar atenção ao fato de que
as tarefas publicadas devem ter o mesmo nível de detalhe. Quando as pessoas começam homens-
ção de pequenos micro-passos, como “colocar o documento em uma máquina de fax”, o facilitador
tor deve tentar elevar o nível de abstração. No final, este exercício leva a um
mapa que o analista de processo pode tomar como entrada para construir um modelo inicial.
Exercício 5.6 Considere as duas empresas a seguir. A empresa A é jovem, fundada

há três anos e cresceu rapidamente para um número atual de 100 funcionários. Com-
empresa B é de propriedade do estado e opera em um domínio com ampla saúde e saúde
regulamentos de curadoria. Como essas características diferentes podem influenciar um workshop
abordagem de descoberta baseada?
A descoberta do processo baseado em oficina requer uma facilitação organizada e um at-

atmosfera de abertura. Em termos de facilitação, o facilitador deve garantir que o
liberdade condicional é equilibrada entre os diferentes participantes. Isso significa por um lado
restringindo o tempo de fala dos participantes falantes. Por outro lado, mais
participantes introvertidos devem ser encorajados a expressar suas perspectivas. Uma atmosfera
esfera de abertura é útil para que todos participem. Este aspecto é influente
com a cultura da empresa. Em organizações com uma forte ênfase
hierarquia, pode ser difícil para os especialistas de domínio expressar sua opinião abertamente se
seu supervisor está presente. Se a criatividade e o pensamento independente são apreciados em
empresa, os participantes provavelmente se sentirão à vontade para discutir questões. Isto é
a responsabilidade do facilitador de estimular uma interação construtiva na oficina
em ambos os casos. Nesse caso, os workshops têm o potencial de resolver inconsistências
diretamente com todas as partes envolvidas.
5.2.4 Pontos fortes e limitações
Os diferentes métodos de descoberta de processos têm vantagens e limitações. Estes

pode ser discutido em termos de objetividade, riqueza, consumo de tempo e imediatismo
de feedback (ver Tabela 5.2 ).
Página 185
• Objetividade: métodos de descoberta baseados em evidências normalmente fornecem o melhor nível
de objetividade. Documentos existentes, registros existentes e observação fornecem uma
conta tendenciosa de como um processo funciona. Com base em entrevistas e em workshops
Covery ambos têm que confiar nas descrições e interpretações de especialistas do domínio
que estão envolvidos com o processo. Isso carrega o risco de que essas pessoas possam
ter percepções e ideias de como o processo funciona, que pode ser parcialmente
incorreto. Pior ainda, o analista de processo também corre o risco de que os especialistas do domínio
pode ocultar oportunisticamente informações relevantes sobre o processo. Isso pode ser
o caso se o projeto de descoberta de processo acontece em um ambiente político onde
grupos de partes interessadas no processo devem temer a perda de poder, perda de influência ou
perda de posição.
• Riqueza: Embora os métodos de descoberta baseados em entrevistas e workshops mostram
algumas limitações em termos de objetividade, eles são normalmente fortes em fornecer
percepções sobre o processo. Especialistas no domínio envolvidos em entrevistas e workshops
são uma boa fonte para esclarecer as razões e objetivos de porque um processo é configurado como ele
é. Métodos baseados em evidências podem mostrar questões que precisam ser discutidas e levantadas
perguntas, mas muitas vezes não fornecem uma resposta. Conversando com especialistas de domínio também
oferece uma visão da história do processo e da organização envolvente. este
é importante para entender quais partes interessadas têm qual agenda. Evidence-
métodos de descoberta baseados às vezes fornecem insights sobre considerações estratégicas
sobre um processo quando são documentados em white papers, mas dificilmente permitem
conclusões sobre as agendas pessoais das diferentes partes interessadas.
• Consumo de tempo: os métodos de descoberta diferem na quantidade de tempo que requerem.
Embora a documentação de uma empresa e de um determinado processo possa ser facilmente feita
disponível para um analista de processo, é muito mais demorado realizar
entrevistas e workshops. Enquanto a descoberta baseada em entrevista sofre de vários
iterações de feedback, é difícil agendar workshops com vários domínios ex-
perts em curto prazo. A descoberta automática de processos muitas vezes envolve uma significativa
quantidade de tempo para extrair, reformatar e filtrar os logs de eventos. Passiva
a observação também requer coordenação e tempo de aprovação. Portanto, é um bom
idéia de começar com a análise de documentos, uma vez que a documentação muitas vezes pode ser feita
acessível a curto prazo.
• Imediato de feedback: os métodos que se baseiam diretamente na conversa
e a interação com especialistas de domínio é melhor para obter feedback imediato.
A descoberta baseada em workshop é melhor a este respeito, uma vez que percepções inconsistentes
sobre o funcionamento de um processo pode ser resolvido diretamente pelas partes envolvidas.
As entrevistas oferecem a oportunidade de fazer perguntas sempre que relacionadas ao processo
aspectos não são claros. No entanto, nem todos os problemas podem ser resolvidos diretamente com um único
especialista em domínio. Métodos de descoberta baseados em evidências levantam várias questões sobre
como um processo funciona. Muitas vezes, essas perguntas só podem ser respondidas conversando com
especialistas de domínio.
Uma vez que cada método de descoberta tem pontos fortes e limitações, é recomendado
utilizar uma mistura deles em um projeto de descoberta. O analista de processo normalmente começa
com documentação que está prontamente disponível. É fundamental organizar o projeto em
de forma que as informações possam ser coletadas dos especialistas de domínio relevantes
Página 186
5.3 Método de Modelagem de Processo 167
de forma eficiente e eficaz. Entrevistas e workshops devem ser agendados

durante o horário normal de trabalho dos especialistas no domínio. Portanto, eles devem estar motivados
para participar e se envolver de forma que seja o menos demorado para
eles. Uma vez que surjam questões sobre detalhes específicos de um processo, pode ser necessário
volte aos métodos de descoberta baseados em evidências.
Exercício 5.7 Em que situações simplesmente não é possível usar um ou mais dos
métodos de descoberta descritos?
5.3 Método de Modelagem de Processo
Modelar um processo na fase de descoberta é uma tarefa complexa. Portanto, é bom

seguir um procedimento predefinido para abordar essa tarefa de forma sistemática.
Uma maneira de fazer isso é trabalhar em cinco etapas, da seguinte maneira:
1. Identifique os limites do processo

2. Identificar atividades e eventos
3. Identifique os recursos e suas transferências
4. Identifique o fluxo de controle
5. Identifique elementos adicionais
5.3.1 Identificar os limites do processo
A identificação dos limites do processo é essencial para a compreensão do escopo

do processo. Parte deste trabalho pode ter sido feito já com a definição
de uma arquitetura de processo. Tecnicamente, isso significa que precisamos identificar os eventos
que acionam nossos processos e aqueles que identificam os possíveis resultados do processo.
Por exemplo, vamos considerar novamente o processo de atendimento de pedidos que modelamos em
Indivíduo. 3 . Observamos que este processo é desencadeado pelo recebimento de um pedido de compra
do cliente e conclui com o cumprimento do pedido como um resultado.
Esses dois eventos marcam os limites desse processo. Assim, usamos uma
evento de mensagem e um evento final em BPMN para representá-los. Se nosso processo fosse
Se tivéssemos resultados negativos, teríamos modelado esses resultados por meio de eventos de término.
5.3.2 Identificar Atividades e Eventos
O objetivo da segunda etapa é identificar as principais atividades do processo. o

A vantagem de começar com as atividades é que os especialistas no domínio serão claramente capazes
para declarar o que estão fazendo, mesmo que não estejam cientes de que estão trabalhando como parte de um
processo de negócios abrangente. Além disso, os documentos podem mencionar explicitamente as atividades,
Página 187
Fig. 5.1 As principais atividades e eventos do processo de atendimento de pedidos
por exemplo, um conjunto de instruções de trabalho. No caso do processo de atendimento do pedido,

esta fase pode levar a um conjunto de atividades para as quais a ordem e as condições de roteamento
ainda não estão definidos. Nesta etapa, também precisamos identificar os eventos que ocorrem durante
o processo, que modelaremos com eventos intermediários. A Figura 5.1 lista os 12
atividades do nosso exemplo. 1 Observe que este conjunto inicial de atividades e eventos pode
passar por revisões, por exemplo, mais atividades podem ser adicionadas à medida que adicionamos mais detalhes em
nosso modelo. Se o processo for muito complexo, sugerimos focar nas atividades principais
e eventos apenas neste estágio, e adicionar os outros em um estágio posterior, quando um mais profundo
compreensão desses elementos e suas relações foi adquirida.
5.3.3 Identificar recursos e suas transferências
Assim que tivermos definido o conjunto de atividades e eventos principais, podemos nos voltar para a questão
de quem é responsável por eles. Essas informações fornecem a base para o
definição de pools e pistas, e a atribuição de atividades e eventos a um dos
essas piscinas e pistas. Nesta fase, a ordem das atividades ainda não está definida.
Portanto, é uma boa etapa identificar primeiro os pontos do processo onde o trabalho
é transferido de um recurso para outro, por exemplo, de um departamento para outro.
Esses pontos de transferência são importantes, pois um participante está sendo atribuído a uma nova tarefa
para executar, geralmente tem que fazer suposições sobre o que foi concluído ser-
diante. Tornar essas suposições explícitas é uma etapa essencial na descoberta do processo.
A Figura 5.2 mostra o conjunto de atividades e eventos do processo de atendimento de pedidos agora
sendo atribuídos a pools e pistas. Os fluxos de sequência indicam pontos de transferência. o
pontos de transferência também ajudam a identificar as partes do processo que podem ser estudadas em
isolamento do resto. Essas partes podem ser refinadas em subprocessos com a ajuda
das partes interessadas envolvidas. Por exemplo, no processo de atendimento do pedido, a aquisição
posição de matérias-primas (cf. Fig. 4.19 ) pode ser tratada isoladamente do resto
o processo, uma vez que esta parte envolve os fornecedores e pessoal do armazém
e departamento de distribuição.
1 Para simplificar, consideramos apenas um fornecedor neste exemplo, então, por exemplo, há apenas um
atividade “Solicitar matérias-primas” em vez de “Solicitar matérias-primas do Fornecedor 1” e “Solicitar
matérias-primas do Fornecedor 2 ”.
Página 188
5.3 Método de Modelagem de Processo 169
Fig. 5.2 As atividades e eventos do processo de atendimento de pedidos atribuídos a pools e pistas
5.3.4 Identificar o fluxo de controle
Os pontos de transferência definem uma estrutura inicial para o fluxo de controle. Em essência, con
O fluxo de trol está relacionado às questões de quando e por que as atividades e eventos são executados.
Tecnicamente, precisamos identificar dependências de pedidos, pontos de decisão, ex simultâneos
execução de atividades e eventos e potencial reformulação e repetição. Pontos de decisão
exigem a adição de (X) divisões OR e as condições relevantes no se- alternativo
fluxos de sequência. O retrabalho e a repetição podem ser modelados com estruturas em loop. Concordar-
atividades de aluguel que podem ser executadas independentemente umas das outras estão vinculadas a E
entradas. As divisões baseadas em eventos são usadas para reagir a decisões tomadas fora do processo.
Se tivermos modelado mais de uma parte comercial na etapa anterior por meio do uso de
vários pools nesta etapa, também precisamos capturar a troca de informações
entre os vários pools por meio de fluxos de mensagens. A Figura 5.3 mostra como as restrições de ordem
são capturados por arcos de fluxo de controle no processo de atendimento do pedido. Aqui podemos ver
que as transferências que identificamos na etapa anterior foram agora refinadas em
dependências mais elaboradas.
Exercício 5.8 Qual é a relação entre o tipo de um gateway e as condições

ções dos arcos subsequentes?
5.3.5 Identificar Elementos Adicionais
Finalmente, podemos estender o modelo capturando os artefatos envolvidos e a exceção

manipuladores. Para os artefatos, isso significa adicionar objetos de dados, armazenamentos de dados e suas relações
a atividades e eventos por meio de associações de dados. Para os manipuladores de exceção, este
significa usar eventos de fronteira, fluxos de exceção e manipuladores de compensação. Como nós
mencionado no Chaps. 3 e 4 , a adição de elementos de dados e exceções, depende
Página 189
Fig. 5.3 O fluxo de controle de

o processo de atendimento do pedido
Página 190
5.4 Garantia da Qualidade do Modelo de Processo 171
sobre o propósito particular de modelagem. Por exemplo, se o processo deve ser automático
automatizado, é desejável capturar explicitamente os dados e os aspectos de exceção. Nesta etapa
também podemos adicionar mais anotações para ajudar a suportar cenários de aplicativos específicos,
por exemplo, se o modelo é usado para análise de risco ou para estimativa de custo de processo, nós
pode ser necessário adicionar informações de risco e custo. Em geral, quais elementos devem ser adicionados
depende do cenário de aplicação particular.
Nesta seção, ilustramos um método para construir um modelo de processo de negócios
através de uma série de etapas incrementais. Em um cenário onde várias partes de negócios
estão envolvidos, uma opção alternativa é começar com um diagrama de coreografia primeiro, e
em seguida, refine incrementalmente este diagrama em um diagrama de colaboração. Nesse caso,
usamos o diagrama de coreografia para identificar os recursos primeiro e modelar cada um
-los através de uma piscina. Em seguida, dentro de cada pool, modelamos os eventos e atividades que
lidar com a transferência de informações entre as partes (ou seja, enviar e receber atividades,
mensagem e eventos de sinal); podemos derivar esses elementos das atividades do
diagrama de coreografia. Podemos então continuar com a Etapa 2 do método acima
adicionando as demais atividades internas. Em seguida, na Etapa 3, modelamos os recursos internos
dentro de cada parte usando pistas, e então continue com o resto do método como
normal.
5.4 Garantia da Qualidade do Modelo de Processo
A descoberta de processo envolve pelo menos um analista de processo e vários especialistas de domínio.
Uma vez que coletar informações e organizá-las em um modelo de processo muitas vezes é feito em um
forma sequencial, e não simultaneamente, são necessárias várias etapas de qualidade
garantia. Aqui, nos concentramos na qualidade sintática, semântica e pragmática. Figura 5.4
mostra que a verificação é usada para alcançar a qualidade sintática, a validação fornece se-
qualidade mântica, e a certificação garante qualidade pragmática. Diretrizes de modelagem e
convenções ajudam a garantir uma boa qualidade desde o início.
5.4.1 Qualidade Sintática e Verificação
Os modelos de processos construídos em projetos de descoberta de processos normalmente precisam aderir

às regras e diretrizes sintáticas. A qualidade sintática está relacionada ao objetivo de produzir
um modelo de processo que está em conformidade com essas regras. Em primeiro lugar, isso significa que o conteúdo
do modelo deve estar de acordo com a sintaxe, conforme definido pela linguagem de modelagem de processos
calibre em uso. Por exemplo, em BPMN não é permitido desenhar um fluxo de sequência através
os limites das piscinas. BPMN define um amplo conjunto de regras de sintaxe. Segue
essas regras ajudam a garantir que um modelo de processo sempre possa ser interpretado. Estar-
além disso, muitas empresas definem diretrizes a fim de garantir consistência e
comparabilidade dos modelos de processo, que discutiremos a seguir.
A verificação aborda essencialmente as propriedades formais de um modelo que pode ser
verificado sem conhecer o processo do mundo real. No contexto do modelo de processo
Página 191
Fig. 5.4 Aspectos de qualidade e atividades de garantia de qualidade
verificação, correção estrutural e comportamental podem ser distinguidas. Estrutural

correção se relaciona aos tipos de elementos que são usados no modelo e como eles
estão conectados. Por exemplo, uma atividade deve sempre ter uma entrada e uma saída
indo de arco e cada elemento deve estar em um caminho de um evento inicial para um evento final
do modelo de processo. Essas propriedades muitas vezes podem ser verificadas facilmente por inspeção
ção da estrutura baseada em gráfico do modelo de processo. A correção comportamental se relaciona
para sequências potenciais de execução, conforme definido pelo modelo de processo. É um general
suposição de que um caso nunca deve ser capaz de chegar a um deadlock ou livelock. este
é o caso quando a propriedade de solidez é mantida (ver Cap. 3 ). Som comum e
fragmentos de processo não saudáveis estão representados na Fig. 5.5 . Propriedades de verificação, como
a integridade pode ser verificada após a criação de um modelo de processo. Alternativamente, um processo
A ferramenta de modelagem pode garantir que um modelo esteja correto por design. Isso pode ser alcançado por
permitindo apenas operações de edição no modelo que preservam a estrutura e o comportamento
correção.
Exercício 5.9 Dê uma olhada na Fig. 5.5 . Explique o que exatamente está errado no
fragmentos do modelo de processo doentios.
5.4.2 Qualidade Semântica e Validação
A qualidade semântica está relacionada ao objetivo de produzir modelos que façam declarações verdadeiras
sobre o domínio considerado, seja para processos as-is existentes ou futuros futuros pro
cesses. O desafio particular de uma avaliação da qualidade semântica é que o processo
Página 192
Fig. 5.5 Som comum e fragmentos de processo doentios
modelo deve ser comparado com o domínio do mundo real de um determinado negócio
cesso Isso significa que não há um conjunto de regras formais que possam ser usadas para verificar facilmente
qualidade semântica. Se o modelo de processo no centro da Fig. 5.4 é bom
a qualidade semântica só pode ser avaliada conversando com as pessoas envolvidas no processo
e consultando a documentação.
A validação lida com a verificação da qualidade semântica de um modelo, comparando
com o processo de negócios do mundo real. Existem dois aspectos essenciais da semântica
qualidade do tique: validade e completude indexCompleteness. Validade significa que todos
as afirmações incluídas no modelo são corretas e relevantes para o problema. Validade
pode ser avaliada explicando os especialistas do domínio como o processamento é capturado no
modelo. O especialista de domínio deve apontar qualquer diferença entre o que o
estados do modelo e o que é possível na realidade. Completude significa que o modelo
contém todas as declarações relevantes sobre um processo que seriam corretas. Integridade
é mais difícil de avaliar. Aqui, o analista de processo tem que perguntar sobre várias alter-
opções de processamento nativas em diferentes estágios do processo. Por exemplo, o modelo
na Fig. 5.3 ainda estão faltando todos os elementos de dados e manipuladores de exceção. É o trabalho de
Página 193
o analista de processo para julgar a relevância desses elementos adicionais. Este julgamento-
deve ser feito no contexto do objetivo de modelagem, que o
analista de processo deve estar familiarizado. Vamos considerar um exemplo para entender
a diferença entre validade e completude. Se o modelo de processo para empréstimo como-
avaliações expressa que qualquer diretor financeiro pode realizar a tarefa de verificar
o histórico de crédito de um determinado requerente, enquanto na prática isso requer uma
autorização, o modelo tem um problema de qualidade semântica (declaração inválida). E se
a tarefa de verificar o histórico de crédito é omitida, então ele tem um problema semântico devido
para incompletude. A validação pode ser suportada por técnicas como simulação ou
terviews. Como alternativa, existem ferramentas que fornecem veracidade por design. Isto é,
por exemplo, obtido através da construção de um modelo de processo a partir dos registros de uma informação
sistema, como veremos no cap. 10 . Na prática, os modelos de processo muitas vezes exigem o
aprovação do proprietário do processo. Esta aprovação é uma etapa de validação especial, uma vez que
novamente se refere à exatidão e integridade do modelo de processo. Além
que, a aprovação do proprietário do processo estabelece o caráter normativo do
modelo de processo disponível. Como consequência, o modelo de processo agora pode ser arquivado,
publicado ou usado como uma entrada para o redesenho do processo.
5.4.3 Qualidade Pragmática e Certificação
A qualidade pragmática está relacionada ao objetivo de construir um modelo de processo de boa usabilidade.
O desafio particular da avaliação da qualidade pragmática é prognosticar o
uso real de um modelo de processo de antemão. Consequentemente, este aspecto muito
concentra-se em como as pessoas interagem com um modelo. Se o modelo de processo no
centro da Fig. 5.4 é de boa qualidade pragmática e pode, por exemplo, ser verificado por
testar o quão bem um usuário entende o conteúdo do modelo.
A certificação é a atividade de verificar a qualidade pragmática de um modelo de processo
investigando seu uso. Existem vários aspectos da usabilidade, incluindo
capacidade de suporte, manutenção e aprendizagem. A compreensibilidade se relaciona ao fato de como
fácil é ler um modelo de processo específico. A capacidade de manutenção aponta para a facilidade de aplicação
executar mudanças em um modelo de processo. O aprendizado está relacionado ao grau de quão bom um
modelo de processo revela como um processo de negócio funciona na realidade. Existem vários
características de um modelo que influenciam a usabilidade, incluindo seu tamanho, sua estrutura
complexidade e seu layout gráfico. A certificação pode ser realizada usando o usuário
entrevistas ou experiências do usuário. Como alternativa, existem regras que se esforçam para fornecer
usabilidade por design. Isso pode ser alcançado, por exemplo, seguindo as regras de design em
a estrutura do modelo de processo. Existem duas verificações essenciais para a compreensão,
manutenibilidade e aprendizagem. O primeiro diz respeito à consistência entre visuais
estrutura e estrutura lógica. A Figura 5.6 e a Fig. 5.7 mostram o mesmo fragmento de
o modelo de processo de atendimento de pedidos. O segundo modelo é um retrabalho do primeiro
em termos de layout. Aqui, as posições dos elementos foram alteradas com o objetivo de
melhorar a consistência entre a estrutura visual e a estrutura lógica. O segundo
check está relacionado a rótulos significativos. É importante que atividades e outras
Página 194
Fig. 5.6 Extrato do modelo do processo de atendimento do pedido com layout incorreto
Fig. 5.7 Extrato do modelo do processo de atendimento do pedido com bom layout
elementos têm rótulos que seguem convenções de nomenclatura específicas, como aqueles apresentados em
Sect. 3.1 .
5.4.4 Diretrizes e convenções de modelagem
As diretrizes e convenções de modelagem são uma ferramenta importante para proteger o modelo
consistência e integridade para iniciativas de modelagem maiores com várias pessoas em
envolvido. Os objetivos de tais diretrizes e convenções são aumentar a legibilidade
Página 195
e comparabilidade para facilitar a análise eficiente do modelo. Um documento de orientação

ment normalmente cobre convenções de nomenclatura para processos, tarefas e eventos, modelagem
convenções para layout e uso de tarefas, eventos, pistas e pools, e uma restrição
ção do conjunto de elementos. As convenções de nomenclatura geralmente recomendam ou reforçam o
estilo verbo-objeto para rotular atividades e estilos adequados para outros elementos como
discutido na Seção 3.1 . Devem ser evitados verbos muito técnicos e genéricos. Mod-
As convenções eling definem o uso e layout do elemento. Layout para modelos BPMN é
normalmente definido com uma orientação horizontal. O uso de pools pode ser obrigatório para
cada modelo junto com o fluxo de mensagens correspondente. O detalhe de como começa e termina
eventos são capturados também podem ser especificados. Todas as convenções geralmente vêm junto
com regras como capitalizar ou o que fazer referência nos nomes dos elementos, por exemplo, usando um
glossário. Por fim, restrições podem ser definidas de forma a simplificar o conjunto de elementos
de BPMN. Essas restrições são recomendadas para aumentar a compreensão dos modelos
também por usuários não especialistas.
Um conjunto de diretrizes que foi proposto recentemente são as chamadas Sete
Diretrizes de modelagem de processos ( 7PMG ). Este conjunto foi desenvolvido como um amálgama
dos insights derivados das pesquisas disponíveis. Especificamente, a análise
de grandes conjuntos de modelos de processo por vários pesquisadores identificaram muitos syn-
erros táticos, bem como estruturas complexas que inibiam sua interpretação. o
as diretrizes que fazem parte do 7PMG são úteis para orientar os usuários no sentido de mitigar
tais problemas. As diretrizes são as seguintes:
G1: Use o mínimo de elementos possível no modelo. O tamanho de um modelo de processo tem
efeitos indesejáveis sobre a compreensão do modelo de processo e a probabilidade
de erros sintáticos. Estudos têm mostrado que modelos maiores tendem a ser mais
difícil de entender e com maior taxa de erro.
G2: Minimize os caminhos de roteamento por elemento. Para cada elemento em um modelo de processo,
é possível determinar o número de arcos de entrada e saída. este
A figura resumida dá uma ideia dos caminhos de roteamento por meio de tal elemento.
Um número alto torna mais difícil entender o modelo. Além disso, o número
de erros sintáticos em um modelo parece fortemente correlacionado ao uso do modelo
elementos com alto número de caminhos de roteamento.
G3: Use um evento inicial e um evento final. Estudos empíricos estabeleceram que o
o número de eventos de início e término está positivamente conectado com um aumento no erro
probabilidade. Os modelos que atendem a esse requisito são mais fáceis de entender e
permitir todos os tipos de análise formal.
G4: Modelo o mais estruturado possível. Um modelo de processo é estruturado se cada divisão
gateway corresponde a um respectivo gateway de junção do mesmo tipo. Estruturado em blocos
os modelos podem ser vistos como fórmulas com colchetes balanceados, ou seja, cada abertura
colchete tem um colchete de fechamento correspondente do mesmo tipo. Não estruturado
modelos não são apenas mais propensos a incluir erros, as pessoas também tendem a subestimar
suportá-los com menos facilidade. No entanto, conforme discutido no cap. 4.3 , às vezes é
não é possível ou desejável transformar um fragmento de modelo de processo não estruturado
(por exemplo, um ciclo não estruturado) em um estruturado. É por isso que esta diretriz
afirma “o mais estruturado possível”.
Página 196
Fig. 5.8 Um processo de tratamento de reclamações conforme encontrado na prática
G5: Evite os gateways OR. Modelos que têm apenas AND-gateways e XOR-gate-
maneiras são menos sujeitas a erros. Este achado empírico está aparentemente relacionado ao
fato de que as combinações de escolhas representadas por uma divisão OR são mais diferentes
mais difícil de entender do que o comportamento capturado por outros gateways.
G6: Use rótulos de atividade verbo-objeto. Uma ampla exploração de estilos de rotulagem que são
usado em modelos de processos reais, revela a existência de uma série de
estilos. Destes, as pessoas consideram o estilo verbo-objeto, como “Informar com
simples ”, como significativamente menos ambíguo e mais útil do que o substantivo de ação
rótulos (por exemplo, “análise de reclamação”) ou rótulos que não seguem nenhum desses estilos
(por exemplo, “Agenda do incidente”).
G7: Decompor um modelo com mais de 30 elementos. Esta diretriz se refere ao G1
isso é motivado por uma correlação positiva entre tamanho e erros. Para mod-
els com mais de 30 elementos, a probabilidade de erro tende a aumentar drasticamente.
Portanto, os modelos grandes devem ser divididos em modelos menores. Por exemplo,
grandes subcomponentes com uma única entrada e uma única saída podem ser substituídos por
uma atividade que aponta para o subcomponente original como um subprocesso.
A necessidade de diretrizes como 7PMG é enfatizada pela estrutura do processo

modelos que vimos na prática. A Figura 5.8 mostra uma versão simplificada de um componente
modelo de processo de tratamento de reclamações de um de nossos parceiros do setor. Uma reclamação é trig-
gerada por um telefonema de um cliente reclamante. É decidido se o com
reclamação pode ser tratada ou se deve ser encaminhada a uma parte interna ou externa.
Uma referência externa leva a uma confirmação por telefone para a parte externa. Um em
a referência final é adicionada à agenda do incidente. Se nenhuma referência for necessária, uma reclamação
a análise é conduzida e o reclamante é contatado. Em qualquer caso, a reclamação
é arquivado e o caso é encerrado.
Exercício 5.10 Considere o modelo de processo da Fig. 5.8 . Explique qual guia 7PMG-
linhas apontam para potencial de melhoria. Remodelar o processo com base em seu observador
vações.
Página 197
O 7PMG é apenas um dos conjuntos disponíveis de diretrizes de modelagem. Além disso,

é um conjunto provisório no sentido de que a pesquisa na área de qualidade do modelo de processo
está se desenvolvendo rapidamente. Muitas de suas diretrizes já são aplicadas na prática e
foram discutidos como estado da arte em lugares anteriores deste livro. Por exemplo,
na seção 3.1 a convenção de rotulagem verbo-objeto benéfica já foi mencionada.
Além disso, o limite para começar a decompor modelos de processo como na diretriz G7 foi
discutido na Seção 4.1 . O que é especial sobre o 7PMG é que essas diretrizes
têm uma forte base empírica e, como tal, transcendem o conhecimento do indivíduo
modeladores. À medida que os insights se desenvolvem, parece provável e favorável que o conjunto
será atualizado e expandido.
5.5 Recapitulação
Este capítulo descreveu como proceder nas diferentes fases do processo de descoberta
ery. Em essência, definimos quatro estágios de descoberta do processo, ou seja, definir o
configuração da descoberta do processo, aplicando diferentes métodos de descoberta para reunir
formação sobre o processo, modelagem passo a passo do processo e, finalmente, abordando
diferentes aspectos da garantia de qualidade.
A definição da configuração da descoberta do processo deve levar em consideração o
diferentes características e habilidades complementares de analistas de processo e domínio
especialistas. Embora os analistas de processos sejam especializados em análise e modelagem de processos,
muitas vezes carecem de conhecimento detalhado do domínio. Em contraste, os especialistas de domínio têm tipi
habilidades de modelagem limitadamente limitadas, mas compreensão detalhada da parte do processo
eles estão envolvidos. Isso implica três desafios de descoberta de processo. Primeiro,
diferentes especialistas de domínio entendem apenas uma parte do processo. Diferem
As visões parciais devem ser integradas na descoberta do processo. Em segundo lugar, especialistas de domínio
tendem a pensar em casos e não no nível geral do processo. O analista de processo tem
para abstrair desses casos. Terceiro, os especialistas de domínio costumam ter dificuldades em
modelos de processos permanentes. Portanto, o analista de processo deve orientar o domínio
especialista em ler o modelo para obter feedback.
Diferentes métodos de descoberta de processos podem ser usados, desde os baseados em evidências
métodos para entrevistas e workshops. Métodos baseados em evidências normalmente fornecem
a visão mais objetiva da execução do processo. No entanto, o imediato
a qualidade do feedback é baixa e a riqueza do insight pode ser medíocre. Entrevistas
pode ser tendencioso para a perspectiva ou opinião do parceiro de entrevista, mas re-
detalhes ricos de vitela do processo. A situação da entrevista oferece a chance de dirigir
feedback e esclarecimento. Workshops podem ajudar a resolver imediatamente inconsistentes
perspectivas de diferentes especialistas no domínio. Por outro lado, é difícil ter
todos os especialistas de domínio necessários ingressando de forma síncrona. Recomenda-se utilizar um
mistura dos métodos que reflete as especificidades do projeto de descoberta.
Em seguida, definimos um método de modelagem de processo incluindo seis etapas. Primeiro, o limite
aries do processo devem ser definidas em termos de eventos de início e fim. Segundo, o
atividades essenciais do processo devem ser identificadas. Posteriormente, precisamos de-
termine as transferências entre diferentes pessoas e departamentos. Uma vez que esse aspecto
Página 198
for esclarecido, podemos esboçar os detalhes do fluxo de controle. Então, as condições de roteamento
ções e eventos intermediários devem ser adicionados. Finalmente, perspectivas adicionais e
anotações podem ser incluídas.
Nas últimas seções deste capítulo, discutimos diferentes medidas de qualidade
garantia. Em primeiro lugar, enfatizamos a verificação como uma ferramenta para garantir a sintática cortical
retidão. Em seguida, discutimos como a validação ajuda a estabelecer a qualidade semântica.
Por fim, apresentamos diferentes aspectos da qualidade pragmática e descrevemos como eles
pode ser certificado.
Solução 5.1 Caso você deva mapear o processo de assinatura de um contrato de locação
trato em sua cidade, é provável que você tenha alguma experiência com esse processo,
de alugar um apartamento você mesmo, ou de histórias de seus amigos, ou de você ou seu
amigos dando um apartamento para alugar. Supondo que você já tenha estudado os capítulos sobre
modelagem de processos, você tem conhecimento de domínio e conhecimento de modelagem de processos.
Esta é uma situação incomum. Na maioria das vezes, você enfrenta situações como mapear o
processo de obtenção da placa do seu carro em Liechtenstein como residente estrangeiro.
Este é um processo para o qual você provavelmente não terá conhecimento de domínio. Processo
descoberta normalmente traz você como um analista de processo em um ambiente que você faz
não sei em detalhes de antemão. A descoberta do processo está preocupada com a compreensão
o processo em consideração e também o domínio que o cerca.
Solução 5.2 Uma vantagem de ter equipes modelando os próprios processos é primeiro
que muitos modelos de processo podem ser criados em um curto espaço de tempo. É crítico
embora essas equipes possuam as habilidades necessárias em modelagem de processos. De acordo
para o terceiro desafio de descoberta de processos, os especialistas de domínio normalmente não têm
cessar habilidades de modelagem e sentir-se desconfortável com a tarefa de modelagem. Além disso,
especialistas de domínio muitas vezes pensam em casos (segundo desafio) e não têm o processo por-
perspectiva de generalizar. Finalmente, existe o risco de que os resultados de tal modelagem
iniciativa pode ser fragmentada e difícil de integrar. Normalmente é o responsável
capacidade do analista de processo para integrar as perspectivas fragmentadas.
Solução 5.3 O conhecimento do domínio pode ser muito útil para analisar processos. isto
ajuda a fazer as perguntas certas e a construir analogias com experiências anteriores. Em
por outro lado, as habilidades de um analista de processo experiente não devem ser subestimadas.
estimado. Essas habilidades são independentes de domínio e se relacionam a como uma descoberta de processo
projeto pode ser organizado. Analistas de processo experientes são normalmente muito qualificados em
definir o escopo e conduzir um projeto na direção certa. Eles possuem soluções de problemas
habilidades para lidar com várias situações críticas de um projeto de descoberta de processo. Lá
é claramente uma compensação entre os dois conjuntos de habilidades. Deve ser garantido que um cer-
Um certo nível de experiência em análise de processo está disponível. Se esse não for o caso do
aplicando especialista em domínio, o analista de processo pode ser preferido.
Página 199
Solução 5.4 Como um cliente, teríamos que confiar principalmente em programas baseados em evidências
descoberta de sucesso. Podemos fazer pedidos exemplares e estudar os diferentes processos
opções para eles. Em relação a esses pedidos feitos, também poderíamos entrar em contato com os clientes
atendimento ao cliente e informações sobre o processo que não podemos observar diretamente.
Se fôssemos atribuídos a um projeto de descoberta de processo pelo proprietário do processo, nós
obtenha acesso aos especialistas de domínio dentro da empresa. Nesse caso, também podemos usar
entrevistas e métodos de descoberta baseados em workshops.
Solução 5.5 Este processo contém dez atividades principais que são executadas por diferentes
pessoas ent. Podemos supor que haverá uma reunião inicial com o processo
proprietário e alguns especialistas de domínio importantes no primeiro dia. Um dia pode ser necessário
para estudar a documentação disponível. Uma entrevista com um especialista de domínio pode levar
de duas a três horas, para que pudéssemos atender duas pessoas por dia,
e documentar os resultados da entrevista durante a noite. Vamos supor que encontramos alguns
pessoas apenas uma vez, enquanto buscamos feedback de importantes especialistas no domínio em duas
entrevistas adicionais. Então, haveria uma aprovação final do proprietário do processo.
Isso totaliza um dia para o pontapé inicial, um para o estudo do documento, cinco dias para o
entrevistas de primeira iteração e mais cinco dias se presumirmos que encontraremos cinco especialistas
três vezes. Então, precisamos de um dia para preparar a reunião para a aprovação final com
o dono do processo, que seria no dia seguinte. Se não houver atrasos e
problemas de agendamento, isso resulta em 2 + 5 + 5 + 2 = 14 dias úteis no mínimo.
Solução 5.6 Antes de começar com a descoberta do processo, é importante entender

a cultura e o sentimento de uma organização. Existem empresas que pregam
e praticar uma cultura aberta em que todos os funcionários são incentivados a expressar seus
ideias e suas críticas. Essas organizações podem se beneficiar muito de workshops como
os participantes podem apresentar suas idéias livremente. Em organizações estritamente hierárquicas
ções, é necessário ter um cuidado especial para que cada participante receba uma parte igual da
liberdade condicional em um workshop e que as idéias e críticas não sejam retidas. Pode ser o
caso a jovem empresa dinâmica tem uma cultura mais aberta do que a empresa
com extensas regulamentações de saúde e segurança. Isso deve ser levado em consideração
ao organizar um workshop.
Solução 5.7 Existem várias circunstâncias que podem restringir a aplicação de

diferentes métodos de descoberta. A observação direta pode não ser possível se o processo
funciona parcialmente em um ambiente remoto ou perigoso. Por exemplo, a descoberta de um
processo de uma empresa produtora de petróleo para bombear óleo de uma plataforma de petróleo para um navio pode
pertencem a esta categoria. Então, pode haver casos em que a documentação não
existem, por exemplo, quando uma empresa iniciante, que passou por um período de
o crescimento rápido quer estruturar seu processo de compra. A falta de contribuição também pode ser
um problema para a descoberta automática do processo com base nos dados do log de eventos. Se o processo
sob consideração ainda não é suportado por sistemas de informação, então não há
dados disponíveis para conduzir a descoberta automática do processo. Em geral, entrevistas
são sempre possíveis. Ainda pode ser um problema obter o compromisso de fazer
principais especialistas para uma entrevista. Este é normalmente o caso quando a descoberta do processo
Página 200
projeto está sujeito a políticas internas da empresa e agendas ocultas. Baseado em oficina
descoberta pode ser crítica em empresas com forte hierarquia que possuem uma cultura
de suprimir o pensamento criativo de sua equipe.
Solução 5.8 O tipo de gateway deve ser consistente com as condições do

arcos subsequentes. Se houver uma divisão XOR, as condições nos arcos devem ser
mutuamente exclusivos. Se houver uma divisão OR, as condições podem ser não exclusivas.
Se uma divisão AND for usada, não deve haver condições nos arcos.
Solução 5.9 Quatro fragmentos não sólidos são mostrados com os seguintes problemas:
• A falta de sincronização está relacionada a uma divisão AND seguida por uma junção XOR. No
neste caso, os dois tokens criados a partir da divisão AND não são sincronizados XOR-
juntar, levando potencialmente à execução duplicada de atividades a jusante.
• Um deadlock ocorre, por exemplo, se uma divisão XOR é seguida por uma junção AND.
Como a divisão XOR cria um token apenas em um de seus arcos de saída, a junção AND
exigir um token em cada um de seus arcos de entrada fica preso esperando um segundo
token para chegar.
• No caso de haver uma divisão OR seguida por uma junção XOR, potencialmente obteremos uma falta
de sincronização. Isso depende das condições da divisão OR. Se apenas um
token é gerado a partir dele, o processo pode prosseguir corretamente. Se vários tokens
são gerados, há uma falta de sincronização. Na mesma linha, há um
conflito potencial se a divisão OR for seguida por uma junção AND.
• Um livelock pode ocorrer em uma estrutura de loop inadequada. Aqui, há um XOR-
join usada como uma entrada para um loop, mas a saída do loop é modelada com uma divisão AND.
Isso tem como consequência que nunca é possível sair do loop. Cada vez que o
AND-split é alcançado, ele cria um token saindo do loop, mas também outro token
que permanece dentro do loop.
Solução 5.10 O modelo de processo revela vários problemas. Vários elementos com
o mesmo nome é mostrado duas vezes (evento final e atividade de arquivamento), portanto, G1 é
violado. Além disso, a estrutura de controle é muito complicada, violando G4 pedindo um
Fig. 5.9 O processo de tratamento de reclamações retrabalhado

Fundamentals of Business Process Management - Marlon Dumas - Sel

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fundamentals of Business Process Management - Marlon Dumas - Sel

Enviado por

Direitos autorais:

Formatos disponíveis

13/08/2020 Fundamentos de Gestão de Processos de Negócios

Fundamentos de Gestão de Processos de Negócios

Marlon Dumas r Marcello La Rosa r

Marlon Dumas Jan Mendling

ISBN 978-3-642-33142-8 ISBN 978-3-642-33143-5 (e-book)

Número de controle da Biblioteca do Congresso: 2013932467

ACM Computing Classification (1998): J.1, H.4, H.3.5, D.2

© Springer-Verlag Berlin Heidelberg 2013

Impresso em papel sem ácido

Springer faz parte da Springer Science + Business Media (www.springer.com)

Para Inga e Maia - Marlon

"Fundamentos da Gestão de Processos de Negócios" deriva seus méritos de seu

Brisbane, Austrália Michael Rosemann

Primeiro, domine os fundamentos.

O Business Process Management (BPM) é um campo especial por mais de um motivo.

No espírito de um livro, cada capítulo contém uma série de exames elaborados

Tartu, Estônia Marlon Dumas

1 Introdução ao Gerenciamento de Processos de Negócios . . . . . . . . . . . . . 1

3 Modelagem de processos essenciais . . . . . . . . . . . . . . . . . . . . . . . 63

3.2.2 Execução Paralela. . . . . . . . . . . . . . . . . . . . . . 69

4 Modelagem Avançada de Processos . . . . . . . . . . . . . . . . . . . . . . . 97

5 Descoberta do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.3 ProcessModelingMethod. . . . . . . . . . . . . . . . . . . . . . 167

5.8 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 183

6 Análise qualitativa de processos . . . . . . . . . . . . . . . . . . . . . . . 185

7 Análise Quantitativa de Processos . . . . . . . . . . . . . . . . . . . . . . 213

7.4 Simulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

8 Redesenho do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

9 Automação de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

9.3 Desafios da introdução de umBPMS. . . . . . . . . . . . . . . . . 313

10 Inteligência de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

10.1.3 StructureofEventLogs. . . . . . . . . . . . . . . . . . . 356

6 mi Máquina, Método, Material, Homem, Medição, Meio

DUR Avaliação do uso de drogas

WIP Trabalho em progresso

Fig.1.1 Ingredientesdeprocesso de negócios. . . . . . . . . . . . . . . . . 6

Fig. 7.2 Modelo de processo com bloco XOR. . . . . . . . . . . . . . . . . . 220

Fig. 9.7 Processo de admissão: as avaliações inicial ( a ) e final ( c ) podem

Fig. 9.11 O XSD descrevendo o pedido de compra ( a ) e um de seus

Ab ovo usque ad mala.

Gerenciamento de processos de negócios (BPM) é a arte e a ciência de supervisionar como funciona

1.1 Processos em todos os lugares

atividades de bússola relacionadas à verificação do pedido de compra, envio (no caso

M. Dumas et al., Fundamentals of Business Process Management , 1

Exemplo 1.1 Processo de aquisição até o pagamento na BuildIT.

A BuildIT é uma construtora especializada em obras públicas (estradas, pontes, dutos,

1.2 Ingredientes de um Processo de Negócio

Exercício 1.1 Considere o seguinte processo para a admissão de alunos de pós-graduação

1.2 Ingredientes de um Processo de Negócio 5

• Cópias autenticadas de diplomas anteriores e históricos acadêmicos.

Com relação ao processo acima, considere as seguintes questões:

1. Quem são os atores neste processo?

6 1 Introdução ao Gerenciamento de Processos de Negócios

Fig. 1.1 Ingredientes de um processo de negócios

Total Quality Management (TQM) é uma abordagem que historicamente

O único é que as aplicações de TQM são encontradas principalmente na fabricação

Em resumo, podemos dizer que o BPM herda da melhoria contínua

Fig. 1.2 Como o processo saiu de foco ao longo dos tempos

1.3 Origens e História do BPM

1.3.1 A Organização Funcional

A ideia principal do BPM é focar nos processos ao organizar e gerenciar o trabalho

um tipo específico de mercadoria, como cerâmica, ou fornecendo um tipo particular de serviço

Fig. 1.3 Processo de compra na Ford na fase inicial