ilide info-fundamentals-of-business-process-management-marlon-dumas-sel-pr_aaf29086b8683c13f41ca9be23976f9e

Prévia do material em texto

<p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 1/192</p><p>Página 1</p><p>Fundamentos de Gestão de Processos de Negócios</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 2/192</p><p>Página 2</p><p>Marlon Dumas r Marcello La Rosa r</p><p>Jan Mendling r Hajo A. Reijers</p><p>Fundamentos de</p><p>Processo de negócio</p><p>Gestão</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 3/192</p><p>Página 3</p><p>Marlon Dumas</p><p>Instituto de Ciência da Computação</p><p>Universidade de Tartu</p><p>Tartu, Estônia</p><p>Marcello La Rosa</p><p>Queensland University of Technology</p><p>e NICTA</p><p>Brisbane, Austrália</p><p>Jan Mendling</p><p>Instituto de Negócios da Informação</p><p>Universidade de Economia de Viena</p><p>e negócios</p><p>Viena, Áustria</p><p>Hajo A. Reijers</p><p>Departamento de Matemática</p><p>e Ciência da Computação</p><p>Universidade de Tecnologia de Eindhoven</p><p>Eindhoven, Holanda</p><p>ISBN 978-3-642-33142-8 ISBN 978-3-642-33143-5 (e-book)</p><p>DOI 10.1007 / 978-3-642-33143-5</p><p>Springer Heidelberg New York Dordrecht Londres</p><p>Número de controle da Biblioteca do Congresso: 2013932467</p><p>ACM Computing Classification (1998): J.1, H.4, H.3.5, D.2</p><p>© Springer-Verlag Berlin Heidelberg 2013</p><p>Este trabalho está sujeito a direitos autorais. Todos os direitos são reservados pelo Editor, seja no todo ou em parte</p><p>o material diz respeito, especificamente os direitos de tradução, reimpressão, reutilização de ilustrações, recitação,</p><p>difusão, reprodução em microfilmes ou de qualquer outra forma física, e transmissão ou informação</p><p>armazenamento e recuperação, adaptação eletrônica, software de computador ou por metodologia semelhante ou diferente</p><p>agora conhecido ou desenvolvido no futuro. Isentos desta reserva legal são breves trechos em conexão</p><p>com críticas ou análises acadêmicas ou material fornecido especificamente para o propósito de inscrição</p><p>e executado em sistema informático, para uso exclusivo do adquirente da obra. Duplicação de</p><p>esta publicação ou partes dela são permitidas apenas de acordo com as disposições da Lei de Direitos Autorais do</p><p>A localização do editor, em sua versão atual, e a permissão de uso devem sempre ser obtidas na Springer.</p><p>As permissões de uso podem ser obtidas através do RightsLink no Copyright Clearance Center. Violações</p><p>estão sujeitos a processo judicial nos termos da respectiva Lei de Direitos Autorais.</p><p>O uso de nomes descritivos gerais, nomes registrados, marcas comerciais, marcas de serviço, etc. nesta publicação</p><p>não implica, mesmo na ausência de uma declaração específica, que tais nomes estão isentos do relevante</p><p>leis e regulamentos de proteção e, portanto, livre para uso geral.</p><p>Embora os conselhos e informações neste livro sejam considerados verdadeiros e precisos na data de publicação</p><p>declaração, nem os autores, nem os editores, nem a editora podem aceitar qualquer responsabilidade legal por qualquer</p><p>erros ou omissões que podem ser cometidos. O editor não oferece nenhuma garantia, expressa ou implícita, com respeito</p><p>ao material aqui contido.</p><p>Ilustração da capa : “Drawing Hands” de MC Escher © 2012 The MC Escher Company-Holland. Tudo</p><p>direitos reservados. www.mcescher.com</p><p>Impresso em papel sem ácido</p><p>Springer faz parte da Springer Science + Business Media (www.springer.com)</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://www.mcescher.com</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://www.springer.com</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://www.springer.com/mycopy</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 4/192</p><p>Página 4</p><p>Para Inga e Maia - Marlon</p><p>Para Chiara e Lorenzo — Marcello</p><p>Para Stefanie - Jan</p><p>Para Maddy, Timon e Mayu-Hajo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 5/192</p><p>Página 5</p><p>Prefácio</p><p>Os processos de negócios representam um ativo essencial das corporações. Eles têm impacto direto</p><p>sobre a atratividade de produtos e serviços percebida pelo mercado. Eles</p><p>determinar tarefas, empregos e responsabilidades e, com isso, moldar o trabalho de cada em-</p><p>ployee. Os processos integram sistemas, dados e recursos dentro e através da organização</p><p>zações e qualquer falha podem paralisar a vida corporativa. Processos determinam</p><p>o potencial de uma organização para se adaptar a novas circunstâncias e cumprir</p><p>um número crescente de requisitos legislativos. Os processos influenciam a receita</p><p>potencial tanto quanto moldam o perfil de custo de uma organização.</p><p>No entanto, ao contrário de outros ativos corporativos, como produtos, serviços, força de trabalho,</p><p>marca, ativos físicos ou monetários, a importância dos processos de negócios não</p><p>foi apreciado por um longo período. Apesar do fato de que os processos são a força vital</p><p>de uma organização, eles não desenvolveram o status de cidadão principal na diretoria</p><p>discussões e processos de tomada de decisão gerencial.</p><p>Apenas as crescentes demandas por globalização, integração, padronização, inovação</p><p>vação, agilidade e eficiência operacional, e o desafio relacionado de encontrar mais</p><p>variáveis no ecossistema corporativo que podem ser otimizadas, finalmente aumentaram</p><p>o apetite por refletir e, em última instância, melhorar os processos de negócios.</p><p>Em resposta, nas últimas duas décadas, um conjunto abrangente de ferramentas, técnicas,</p><p>métodos e metodologias inteiras foram desenvolvidos fornecendo suporte para todos</p><p>estágios do ciclo de vida do processo de negócios. Contribuições relevantes foram feitas por</p><p>diversas disciplinas, como Engenharia Industrial, Gestão de Operações, Qual-</p><p>gestão da sociedade, gestão do capital humano, governança corporativa, conceitual</p><p>modelagem, gerenciamento de fluxo de trabalho e engenharia de sistema.</p><p>Gerenciamento de processos de negócios (BPM) é a disciplina que agora enfrenta a dificuldade</p><p>culto, mas tarefa gratificante de consolidar e integrar a infinidade desses ap-</p><p>proaches.</p><p>Este livro é a primeira e mais atualizada contribuição que enfrenta e domina esta</p><p>desafio. Ele captura de forma sucinta o status atual do BPM e traz</p><p>ordem e consistência em abordagens que muitas vezes foram desenvolvidas, discutidas</p><p>e implantados de forma isolada.</p><p>vii</p><p>Página 6</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 6/192</p><p>viii Prefácio</p><p>"Fundamentos da Gestão de Processos de Negócios" deriva seus méritos de seu</p><p>base sólida nas últimas pesquisas aplicadas de BPM. Baseando-se em bases científicas</p><p>práticas significa capitalizar em evidências em vez de depender de confiança. este</p><p>claramente diferencia esta publicação tão necessária de muitos de seus predecessores.</p><p>Em particular, dá ao BPM a credibilidade de que uma disciplina ainda jovem e crescente</p><p>requer.</p><p>O livro em si também é uma vitrine convincente para a importância de uma nova classe de</p><p>processos, ou seja, longa vida, negócios internacionalmente distribuídos, complexos e flexíveis</p><p>processos. Neste caso, é o processo de escrever um livro em conjunto envolvendo quatro</p><p>autores em quatro países diferentes. A equipe enfrentou esse desafio de maneira brilhante</p><p>e o resultado é uma compilação impressionante dos pontos fortes individuais de cada</p><p>autor com base em uma compreensão compartilhada dos fundamentos essenciais de BPM e</p><p>uma paixão comum pelo tópico.</p><p>Não tenho dúvidas de que este livro moldará o conjunto de ferramentas e, espero, ainda mais</p><p>a mentalidade das gerações atuais e futuras de profissionais de BPM. Este pub-</p><p>comunicação tem o potencial de se tornar um catalisador significativo para o sucesso futuro do BPM</p><p>estabelecendo um senso comum para os fundamentos de BPM sobre o qual ele pode</p><p>ser desenvolvido e adaptado às circunstâncias individuais. O livro fornece</p><p>a consistência e o rigor necessários dentro e entre os diversos e em rápido crescimento</p><p>comunidade de profissionais e pesquisadores comprometidos e apaixonados</p><p>comumente associados</p><p>atribuída ao BPM é sua ênfase no uso de modelos de processo ao longo do ciclo de vida</p><p>dos processos de negócios. Assim, os modelos de processo estão presentes de uma forma ou de uma</p><p>Página 28</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 27/192</p><p>6 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>Fig. 1.1 Ingredientes de um processo de negócios</p><p>outro em praticamente todos os capítulos deste livro e dois capítulos são dedicados ao processo</p><p>modelagem.</p><p>Em qualquer caso, embora seja útil saber que várias disciplinas compartilham o objetivo de</p><p>melhorar os processos de negócios, devemos permanecer pragmáticos e não lançar um único disco</p><p>pline um contra o outro como se fossem concorrentes. Em vez disso, devemos abraçar qualquer</p><p>técnica que nos ajuda a melhorar os processos de negócios, seja esta técnica ou não</p><p>é percebido como sendo parte da disciplina de BPM (no sentido estrito) e independentemente</p><p>se a técnica em questão usa ou não modelos de processo.</p><p>DISCIPLINAS RELACIONADAS</p><p>BPM não é de forma alguma a única disciplina que se preocupa em melhorar o</p><p>desempenho operacional das organizações. Abaixo, apresentamos brevemente alguns</p><p>disciplinas relacionadas e identificar as principais relações e diferenças entre elas</p><p>disciplinas e BPM.</p><p>Total Quality Management (TQM) é uma abordagem que historicamente</p><p>precedido e inspirado BPM. O foco do TQM está na melhoria contínua</p><p>gestão e manutenção da qualidade dos produtos e, por extensão, também dos serviços.</p><p>Desta forma, é semelhante ao BPM em sua ênfase sobre a necessidade de ongo-</p><p>ing esforços de melhoria. Mas onde o TQM coloca a ênfase nos produtos</p><p>e os próprios serviços, a visão por trás do BPM é que a qualidade do produto</p><p>produtos e serviços podem ser melhor alcançados com foco na melhoria do</p><p>processos que criam esses produtos e serviços. Deve-se admitir que</p><p>esta visão é um tanto controversa, pois adeptos contemporâneos de TQM fariam</p><p>em vez disso, veja o BPM como uma das várias práticas comumente encontradas</p><p>dentro de um programa TQM. Não tanto uma distinção teórica, mas um império</p><p>Página 29</p><p>1.2 Ingredientes de um Processo de Negócio 7</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 28/192</p><p>O único é que as aplicações de TQM são encontradas principalmente na fabricação</p><p>domínios - onde os produtos são tangíveis - enquanto BPM é mais orientado para</p><p>organizações de serviço.</p><p>Gestão de Operações é um campo que se preocupa com o gerenciamento do físico</p><p>e funções técnicas de uma empresa ou organização, particularmente aquelas relacionadas</p><p>à produção e manufatura. Teoria da probabilidade, teoria das filas, decisão</p><p>análise de integração, modelagem matemática e simulação são importantes tecnologias</p><p>técnicas para otimizar a eficiência das operações a partir dessa perspectiva. Como</p><p>será discutido no Cap. 7 , tais técnicas também são úteis no contexto</p><p>de iniciativas de BPM. O que é bastante diferente entre o gerenciamento de operações</p><p>e BPM é que o gerenciamento de operações está geralmente preocupado com</p><p>controlar um processo existente sem necessariamente alterá-lo, enquanto o BPM é</p><p>muitas vezes preocupado em fazer alterações em um processo existente, a fim de implementar</p><p>prove.</p><p>Lean é uma disciplina de gestão que se origina da indústria</p><p>indústria, em particular a filosofia de engenharia da Toyota. Um dos principais</p><p>princípios do Lean é a eliminação de desperdícios , ou seja, atividades que não agregam</p><p>valor para o cliente, como discutiremos no cap. 6 . A orientação do cliente</p><p>do Lean é semelhante ao do BPM e muitos dos princípios por trás do Lean</p><p>foram absorvidos pelo BPM. Nesse sentido, o BPM pode ser visto como um recurso mais</p><p>disciplina abrangente do que Lean. Outra diferença é que o BPM coloca mais</p><p>ênfase no uso da tecnologia da informação como ferramenta para melhorar os negócios</p><p>processos e torná-los mais consistentes e repetíveis.</p><p>Seis Sigma é outro conjunto de práticas que se originam da fabricação, em</p><p>em particular das práticas de engenharia e produção da Motorola. O principal</p><p>característica do Seis Sigma é seu foco na minimização de defeitos (er-</p><p>rors). Six Sigma coloca uma forte ênfase na medição da produção de</p><p>processos ou atividades, especialmente em termos de qualidade. Six Sigma incentiva</p><p>gerentes para comparar sistematicamente os efeitos das iniciativas de melhoria</p><p>nas saídas. Na prática, Six Sigma não é necessariamente aplicado sozinho, mas</p><p>em conjunto com outras abordagens. Em particular, uma abordagem popular é</p><p>mesclar a filosofia do Lean com as técnicas do Six Sigma, levando a</p><p>uma abordagem conhecida como Lean Six Sigma . Hoje em dia, muitas das técnicas</p><p>de Six Sigma são comumente aplicados em BPM também. No cap. 6 , nós vamos</p><p>apresentar algumas técnicas de análise de processos de negócios que são compartilhadas por Six</p><p>Sigma e BPM.</p><p>Em resumo, podemos dizer que o BPM herda da melhoria contínua</p><p>filosofia do TQM, abraça os princípios e técnicas de operação</p><p>gestão de ações, Lean e Six Sigma, e os combina com a capacidade</p><p>capacidades oferecidas pela moderna tecnologia da informação, a fim de alinhar de forma otimizada</p><p>processos de negócios com os objetivos de desempenho de uma organização.</p><p>Página 30</p><p>8 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 29/192</p><p>Fig. 1.2 Como o processo saiu de foco ao longo dos tempos</p><p>1.3 Origens e História do BPM</p><p>Para entender melhor por que as organizações se envolvem em BPM e quais os benefícios que isso traz</p><p>para eles, vale a pena examinar as razões pelas quais o BPM surgiu e evoluiu</p><p>hora extra. Abaixo, olhamos para os drivers da disciplina de BPM a partir de um histórico</p><p>perspectiva. Começamos com o surgimento de organizações funcionais, continuamos com</p><p>a introdução do pensamento de processo, em direção às inovações e falhas de negócios</p><p>Reengenharia de processos. Esta discussão fornece a base para a definição do</p><p>Ciclo de vida do BPM depois.</p><p>1.3.1 A Organização Funcional</p><p>A ideia principal do BPM é focar nos processos ao organizar e gerenciar o trabalho</p><p>em uma organização. Esta ideia pode parecer intuitiva e direta à primeira vista.</p><p>Na verdade, se alguém está preocupado com a qualidade de um determinado produto ou serviço e</p><p>a rapidez com que é entregue ao cliente, porque não considerar os próprios passos que são necessários</p><p>essencial para produzi-lo? Mesmo sendo intuitivo, foram necessárias várias etapas evolutivas antes</p><p>esta ideia tornou-se parte integrante das estruturas de trabalho das organizações. Figura 1.2</p><p>fornece uma visão geral de alguns desenvolvimentos históricos relevantes para BPM.</p><p>Em tempos pré-históricos, os humanos principalmente se sustentavam ou os pequenos grupos</p><p>eles viviam produzindo sua própria comida, ferramentas e outros itens. Tão cedo</p><p>sociedades, os consumidores e produtores de um determinado bem eram frequentemente as mesmas pessoas.</p><p>Em termos industriais, as pessoas realizavam seus próprios processos de produção. Como um resultado,</p><p>eles sabiam como produzir muitas coisas diferentes. Em outras palavras, eles</p><p>eram generalistas.</p><p>Na antiguidade, em paralelo com o surgimento das cidades e cidades-estado, este trabalho</p><p>tura baseada em generalistas começou a evoluir para o que pode ser caracterizado como um</p><p>nível intermediário de especialização . As pessoas começaram a se especializar na arte de entregar</p><p>Página 31</p><p>1.3 Origens e História do BPM 9</p><p>um tipo específico de mercadoria, como cerâmica, ou fornecendo um tipo particular de serviço</p><p>vícios, como hospedagem para viajantes. Este desenvolvimento generalizado em direção a uma maior</p><p>nível de especialização da força de trabalho culminou nas guildas dos artesãos durante</p><p>durante a Idade Média. Essas guildas eram essencialmente grupos de mercadores e artesãos</p><p>preocupados com a mesma atividade econômica, como barbeiros, sapateiros, pedreiros,</p><p>13/08/2020 Fundamentos</p><p>de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 30/192</p><p>cirurgiões e escultores. Os trabalhadores desta época teriam um bom entendimento detodo um processo em que eles estiveram envolvidos, mas não tanto sobre os processos</p><p>que produziu os bens ou serviços que obteve de terceiros.</p><p>Este maior grau de especialização do trabalhador medieval mudou ainda mais para</p><p>tende a uma forma de pura especialização durante a Segunda Revolução Industrial,</p><p>entre a segunda metade do século 19 e a Primeira Guerra Mundial. Um nome que é</p><p>inseparavelmente ligado a ele está o de Frederick W. Taylor (1856-1915), que propôs</p><p>um conjunto de princípios conhecido como gestão científica . Um elemento-chave no aplicativo de Taylor</p><p>proach era uma forma extrema de divisão do trabalho. Ao estudar meticulosamente as atividades laborais</p><p>ities, como as etapas individuais que eram necessárias para lidar com o ferro-gusa em siderúrgicas,</p><p>Taylor desenvolveu instruções de trabalho muito específicas para trabalhadores. Trabalhadores iriam apenas</p><p>envolver-se na realização de uma das muitas etapas do processo de produção. Não</p><p>apenas na indústria, mas também em ambientes administrativos, como organizações governamentais</p><p>ções, o conceito de divisão do trabalho tornou-se a forma mais dominante de organização</p><p>trabalhos. O resultado desse desenvolvimento foi que os trabalhadores se tornaram puros especialistas que</p><p>se preocuparia com apenas uma única parte de um processo de negócios.</p><p>Um efeito colateral das ideias de Taylor e seus contemporâneos foi o surgimento</p><p>de uma classe totalmente nova de profissionais, a dos gerentes . Afinal alguem</p><p>precisava supervisionar a produtividade de grupos de trabalhadores preocupados com o mesmo</p><p>parte de um processo de produção. Os gerentes eram responsáveis por definir o pro-</p><p>objetivos de produtividade para trabalhadores individuais e certificando-se de que tais objetivos foram cumpridos.</p><p>Em contraste com os mestres das guildas medievais, que só podiam atingir tal classificação</p><p>com base em uma obra-prima produzida por eles próprios, os gerentes não são necessariamente</p><p>especialistas na execução das tarefas que supervisionam. Seu principal interesse é otimizar como</p><p>um trabalho é feito com os recursos sob sua supervisão.</p><p>Após o surgimento dos gestores, as organizações se estruturaram ao longo do</p><p>princípios da divisão do trabalho. Um próximo e óbvio desafio surgiu então: Como diferenciar</p><p>entre as responsabilidades de todos esses gestores? A solução foi criar</p><p>unidades funcionais em que pessoas com um foco semelhante em parte da produção pro-</p><p>cesso foram agrupados. Essas unidades eram supervisionadas por gerentes com diferentes</p><p>responsabilidades. Além disso, as unidades e seus gerentes eram hierarquizados</p><p>por exemplo: por exemplo, grupos estão sob departamentos, departamentos estão sob negócios</p><p>unidades, etc. O que vemos aqui é a raiz das unidades funcionais que nos são familiares</p><p>hoje, quando pensamos em organizações: compras, vendas, armazenamento, finanças,</p><p>marketing, gestão de recursos humanos, etc.</p><p>A organização funcional que emergiu da mentalidade do Segundo In-</p><p>Revolução industrial, dominou o cenário corporativo na maior parte do</p><p>Séculos 19 e 20. No final da década de 1980, no entanto, os principais americanos</p><p>empresas como IBM, Ford e Bell Atlantic (agora Verizon) perceberam que</p><p>sua ênfase na otimização funcional estava criando ineficiências em suas operações</p><p>rações que afetavam sua competitividade. Projetos caros que introduziram</p><p>Página 32</p><p>10 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 31/192</p><p>Fig. 1.3 Processo de compra na Ford na fase inicial</p><p>novos sistemas de TI ou trabalho reorganizado dentro de um departamento funcional com o objetivo</p><p>de melhorar sua eficiência, não estavam ajudando essas empresas a se tornarem</p><p>mais competitivo. Parecia que os clientes permaneciam alheios a esses esforços e</p><p>continuou a levar seus negócios para outro lugar, por exemplo, para concorrentes japoneses.</p><p>1.3.2 O Nascimento do Pensamento Processual</p><p>Um dos eventos revolucionários para o desenvolvimento de BPM foi a aquisição da Ford</p><p>ção de uma grande participação financeira na Mazda durante os anos 1980. Ao visitar a Mazda's</p><p>plantas, uma das coisas que os executivos observadores da Ford notaram foi que as unidades</p><p>dentro da Mazda parecia consideravelmente insuficiente em comparação com</p><p>unidades dentro da Ford, mas operavam normalmente. Um famoso estudo de caso ilustrando este fenômeno</p><p>nomenon, narrado pela primeira vez por Michael Hammer [ 26 ] e posteriormente analisado por</p><p>muitos outros tratam do processo de compra da Ford. A Figura 1.3 descreve a maneira como</p><p>a perseguição era feita dentro da Ford na época.</p><p>Cada compra que a Ford faria precisava passar pelo processo de compra</p><p>partição. Ao decidir que uma determinada quantidade de produtos realmente tinha que ser comprada</p><p>perseguido, este departamento enviou um pedido ao fornecedor em questão. Também seria</p><p>envie uma cópia desse pedido para contas a pagar. Quando o fornecedor fez o acompanhamento, o</p><p>as mercadorias encomendadas seriam entregues no depósito de recebimento da Ford. Juntamente com o</p><p>mercadoria veio um aviso de embarque, que foi repassado para contas a pagar. O ven-</p><p>dor também enviaria uma fatura para contas a pagar diretamente.</p><p>Neste contexto, torna-se claro que a principal tarefa das contas a pagar</p><p>era verificar a consistência entre três documentos diferentes (pedido de compra</p><p>cópia, aviso de envio, fatura), onde cada documento consiste em cerca de 14 dados</p><p>itens (tipo de produto, quantidade, preço, etc.). Não surpreendentemente, vários tipos de doenças</p><p>crepância foram descobertas todos os dias e resolver essas discrepâncias ocupadas</p><p>Página 33</p><p>1.3 Origens e História do BPM 11</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 32/192</p><p>Fig. 1.4 Processo de compra na Ford após o redesenho</p><p>várias centenas de pessoas na Ford. Em contraste, na Mazda, apenas cinco pessoas trabalharam</p><p>neste departamento, enquanto a Mazda não era 100 vezes menor do que a Ford em qualquer rele-</p><p>medida vantajosa. Fundamentalmente, o problema é que a Ford estava detectando e resolvendo</p><p>com problemas (neste caso, discrepâncias) um por um, enquanto a Mazda, em vez disso, foi</p><p>evitando as discrepâncias em primeiro lugar. Após uma comparação mais detalhada com</p><p>Mazda, a Ford realizou várias mudanças em seu próprio processo de compra, levando a</p><p>o processo redesenhado representado na Fig. 1.4 .</p><p>Em primeiro lugar, foi desenvolvida uma base de dados central para armazenar informações sobre as compras.</p><p>Este banco de dados foi usado pelo departamento de compras para armazenar todas as informações</p><p>em pedidos de compra. Este banco de dados substituiu um dos fluxos de papel originais. Sec-</p><p>em segundo lugar, novos terminais de computador foram instalados no departamento de armazém que</p><p>deu acesso direto a esse banco de dados. Quando as mercadorias chegaram, o pessoal do armazém</p><p>poderia verificar imediatamente se a entrega realmente correspondia ao que era originalmente</p><p>comprado. Se não fosse esse o caso, a mercadoria simplesmente não era aceita: isso colocava o</p><p>ônus do fornecedor para garantir que o que foi entregue foi o que foi solicitado e</p><p>nada mais. Nos casos em que uma correspondência foi encontrada entre as mercadorias entregues e</p><p>o pedido de compra registrado, a aceitação da mercadoria foi registrada. Então o</p><p>única coisa que faltou fazer para as contas a pagar era pagar o que foi acordado no</p><p>pedido de compra original. Após esta nova configuração, a Ford conseguiu derrubar</p><p>sua força de trabalho em contas a pagar de cerca de 500 pessoas até 120 pessoas</p><p>(uma redução de 76%).</p><p>Exercício 1.2 Considere o processo de compra na Ford.</p><p>1. Quem são os atores neste processo?</p><p>2. Quais atores podem ser considerados o cliente (ou clientes) neste processo?</p><p>3. Que valor o processo</p><p>oferece ao (s) cliente (s)?</p><p>4. Quais são os resultados possíveis deste processo?</p><p>Página 34</p><p>12 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>Um elemento-chave neste estudo de caso é que um problema de desempenho problemático (ou seja, um</p><p>quantidade excessiva de tempo e recursos gastos na verificação de documentos em contas</p><p>a pagar) é abordada considerando todo o processo. Neste caso, as contas</p><p>departamento de pagamentos desempenha um papel importante no processo de compra geral, mas</p><p>o processo também envolve tarefas da equipe do departamento de compras, o armazém,</p><p>e pelo vendedor. Independentemente dessas barreiras, as mudanças são feitas em todo o processo</p><p>e essas mudanças são multifacetadas: incluem mudanças informativas (informações</p><p>trocas de informações), mudanças tecnológicas (banco de dados, terminais) e mudanças estruturais</p><p>(verificações, políticas).</p><p>Esta visão característica de como olhar para o desempenho organizacional foi colocada</p><p>avançar em um artigo seminal de Tom Davenport e James Short [ 11 ]. Neste artigo,</p><p>os autores exortaram os gerentes a olhar para processos inteiros ao tentar melhorar o</p><p>operações de seus negócios, em vez de olhar para uma tarefa ou negócio específico</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 33/192</p><p>função. Vários casos foram discutidos onde de fato esta abordagem particular provouSer bem sucedido. No mesmo artigo, o importante papel da TI foi enfatizado como um</p><p>capacitador para criar um redesenho dos processos de negócios existentes. Na verdade, quando</p><p>olhando para o exemplo Ford-Mazda, pareceria difícil mudar o tradicional</p><p>procedimento sem as qualidades específicas de TI, o que em geral permite o acesso a</p><p>informações de uma forma que independe de tempo e lugar.</p><p>1.3.3 A ascensão e queda do BPR</p><p>O trabalho de Davenport e Short, assim como o de outros, desencadeou o surgimento</p><p>e ampla adoção de um conceito de gestão que foi referido como Negócios</p><p>Reprojeto de Processo ou Reengenharia de Processo de Negócio , muitas vezes convenientemente abreviado</p><p>transmitido ao BPR . Vários white papers, artigos e livros apareceram sobre o assunto</p><p>ao longo da década de 1990 e empresas em todo o mundo montaram equipes de BPR para</p><p>revisar e redesenhar seus processos.</p><p>O entusiasmo pelo BPR diminuiu, no entanto, no final dos anos 1990. Muitos compa-</p><p>nies encerraram seus projetos de BPR e pararam de apoiar outras iniciativas de BPR.</p><p>O que tinha acontecido? Em uma análise retrospectiva, uma série de fatores podem ser distinguidos</p><p>adivinhado:</p><p>1. Uso indevido de conceito: em algumas organizações, sobre cada programa de mudança ou melhoria</p><p>projeto de ment foi rotulado BPR, mesmo quando os processos de negócios não eram o núcleo de</p><p>esses projetos. Durante a década de 1990, muitas empresas iniciaram uma redução considerável</p><p>ções de sua força de trabalho (downsizing) que, uma vez que eram frequentemente embalados como</p><p>projetos de redesenho de processos, provocou intenso ressentimento entre a equipe operacional</p><p>e média gerência contra BPR. Afinal, não estava nada claro que operando</p><p>o aprimoramento profissional estava realmente impulsionando essas iniciativas.</p><p>2. Radicalismo excessivo: alguns dos primeiros proponentes do BPR, incluindo Michael Hammer,</p><p>enfatizou desde o início que o redesenho tinha que ser radical, no sentido de que</p><p>um novo design para um processo de negócios teve que revisar a maneira como o processo era</p><p>inicialmente organizado. Uma indicação reveladora é um dos primeiros artigos de Michael Hammer</p><p>Página 35</p><p>1.3 Origens e História do BPM 13</p><p>sobre esse assunto que trazia como subtítulo: “Não automatize, oblitere”. Enquanto um</p><p>abordagem radical pode ser justificada em algumas situações, é claro que muitos outros</p><p>situações requerem uma abordagem muito mais gradual (incremental).</p><p>3. Apoie a imaturidade: Mesmo em projetos que eram centrados no processo desde o início</p><p>e adotou uma abordagem mais gradual para melhorar o processo de negócios em questão,</p><p>as pessoas enfrentaram o problema de que as ferramentas e tecnologias necessárias para implementar</p><p>mento, esse novo design não estava disponível ou não era suficientemente poderoso. Um particu-</p><p>A questão principal centrou-se no fato de que muita lógica sobre como os processos tiveram que se desenrolar</p><p>eram codificados permanentemente nos aplicativos de TI de suporte da época. Compreensível,</p><p>as pessoas ficaram frustradas quando notaram que seus esforços para redesenhar um processo</p><p>foram frustrados por uma infraestrutura rígida.</p><p>Posteriormente, dois eventos importantes reviveram algumas das ideias por trás do BPR e estabeleceram</p><p>a base para o surgimento do BPM. Em primeiro lugar, surgiram estudos empíricos</p><p>mostrando que as organizações que eram orientadas para o processo, ou seja, as organizações que</p><p>buscou aprimorar processos como base para ganhar eficiência e satisfazer seus</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 34/192</p><p>clientes - na verdade se saíram melhor do que as organizações não orientadas a processos. Enquanto o</p><p>Os gurus BPR iniciais forneceram estudos de caso convincentes, como o da Ford-</p><p>Mazda, não ficou claro para muitos se essas eram exceções em vez de</p><p>regra. Em um dos primeiros estudos empíricos sobre este tópico, Kevin McCormack [ 49 ] em</p><p>rastreou uma amostra de 100 organizações de manufatura dos EUA e descobriu que o processo-</p><p>organizações orientadas mostraram melhor desempenho geral, tendiam a ter uma aposta</p><p>ter esprit de corps no local de trabalho e sofreu menos com as con-</p><p>flictos. Estudos de acompanhamento confirmaram esse quadro, dando credibilidade renovada a</p><p>pensamento cesso.</p><p>Um segundo desenvolvimento importante foi de natureza tecnológica. Diferentes tipos de</p><p>Surgiu o sistema de TI, mais notavelmente os sistemas Enterprise Resource Planning (ERP) e</p><p>Sistemas de gerenciamento de fluxo de trabalho (WfMSs). Os sistemas ERP são essencialmente sistemas</p><p>que armazenam todos os dados relacionados às operações comerciais de uma empresa de uma forma consistente</p><p>forma, para que todas as partes interessadas que precisam de acesso a esses dados possam obter tal acesso.</p><p>Esta ideia de um único banco de dados compartilhado e centralizado permite a otimização de</p><p>uso de informações e trocas de informações, que é um facilitador chave do processo</p><p>melhoria (cf. Cap. 8 ). 1 WfMSs, por outro lado, são sistemas que distribuem</p><p>trabalhar para vários atores em uma empresa com base em modelos de processo. Ao fazê-lo,</p><p>um WfMS torna mais fácil implementar mudanças nos processos de negócios (por exemplo, para mudar</p><p>a ordem em que as etapas são realizadas) porque as alterações feitas no processo</p><p>modelo pode ser colocado em execução com relativa facilidade, em comparação com a situação onde</p><p>as regras de execução do processo são codificadas dentro de sistemas de software complexos</p><p>e enterrado dentro de dezenas de milhares de linhas de código. Além disso, um WfMS muito próximo</p><p>apóia a ideia de trabalhar de maneira centrada no processo.</p><p>1 Na realidade, os sistemas ERP são muito mais do que um banco de dados compartilhado. Eles também incorporam vários</p><p>módulos para apoiar funções típicas de uma organização, como contabilidade, gerenciamento de estoque,</p><p>planejamento de produção, logística, etc. No entanto, do ponto de vista de melhoria de processos, o</p><p>O conceito de banco de dados compartilhado por trás dos sistemas ERP é um facilitador importante.</p><p>Página 36</p><p>14 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>Fig. 1.5 Funções de trabalho de um gerente responsável por um processo (também conhecido como proprietário do processo)</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 35/192</p><p>Originalmente, os WfMSs se preocupavam principalmente com o trabalho de roteamento entre humanos</p><p>atores. Posteriormente, esses sistemas foram aos poucos ampliados com módulos para monitorar</p><p>e analisar a execução dos processos de negócios.</p><p>Paralelamente, o surgimento da Web</p><p>serviços tornaram mais fácil conectar um WfMS com outros sistemas, em particular ERP</p><p>sistemas. À medida que os WfMSs se tornaram mais sofisticados e melhor integrados com outros</p><p>sistemas corporativos, eles ficaram conhecidos como Business Process Management Systems</p><p>(BPMSs). A funcionalidade dos BPMSs e seu papel na automação de negócios</p><p>processos serão discutidos no Cap. 9 .</p><p>A visão histórica acima sugere que BPM é um renascimento do BPR, como de fato BPM</p><p>adota a visão centrada no processo nas organizações. Porém, algum cuidado é necessário</p><p>quando BPR e BPM estão sendo equacionados. A relação é muito melhor compreendida</p><p>com base na Fig. 1.5 .</p><p>Esta figura mostra que um gerente responsável por um processo de negócios - também</p><p>chamado de proprietário do processo - está preocupado em planejar e organizar o processo em</p><p>por um lado e monitoramento do processo por outro. A figura nos permite explicar</p><p>as diferenças de escopo entre BPR e BPM. Embora ambas as abordagens tomem o</p><p>processo de negócios como ponto de partida, o BPR está principalmente preocupado com o planejamento e</p><p>organizar o processo. Em contraste, o BPM fornece conceitos, métodos, técnicas,</p><p>e ferramentas que cobrem todos os aspectos do gerenciamento de um processo - planejar, organizar, monitorar,</p><p>controle - bem como sua execução real. Em outras palavras, o BPR deve ser visto como um</p><p>subconjunto de técnicas que podem ser usadas no contexto de BPM.</p><p>Esta discussão destaca que o BPM abrange todo o ciclo de vida dos negócios</p><p>processos de ness. Assim, a próxima seção fornece uma visão geral dos conceitos,</p><p>métodos, técnicas e ferramentas que compõem a disciplina de BPM através das lentes de</p><p>o ciclo de vida do BPM . Esta lente fornece uma visão estruturada de como um determinado processo pode</p><p>ser gerenciado.</p><p>Página 37</p><p>1.4 O ciclo de vida do BPM 15</p><p>1.4 O ciclo de vida do BPM</p><p>Em geral, a primeira pergunta que uma equipe que embarca em uma iniciativa de BPM precisa</p><p>esclarecer é “quais processos de negócios pretendemos melhorar”? Logo no início</p><p>e antes que a possibilidade de aplicação de BPM seja colocada na mesa, provavelmente haverá</p><p>já ter uma ideia de quais problemas operacionais a equipe tem que resolver e quais</p><p>os processos de negócios estão colocando esses problemas operacionais. Em outras palavras, a equipe</p><p>não vai começar do zero. Por exemplo, se o problema for que os engenheiros do site</p><p>claro que seu trabalho está sendo prejudicado por dificuldades em garantir equipamentos de construção</p><p>quando necessário, e sabendo que este equipamento é em grande parte alugado,</p><p>é claro que este problema deve ser resolvido olhando para o aluguel de equipamentos</p><p>processo. Ainda assim, é preciso delimitar esse processo. Em particular, é preciso responder a perguntas</p><p>ções como: O processo começa desde o momento em que os fornecedores de aluguel</p><p>são selecionados? Termina quando o equipamento alugado é entregue na construção</p><p>local ou termina quando o equipamento é devolvido ao fornecedor, ou termina</p><p>continuar até que a taxa de aluguel do equipamento seja paga ao fornecedor?</p><p>Estas perguntas podem ser fácil ou difícil de resposta dependendo da quantidade de pro-</p><p>pensamento de sucesso ocorreu na organização de antemão. Se a organização tem</p><p>envolvidos em iniciativas de BPM antes, é provável que um inventário de negócios</p><p>está disponível e que o escopo desses processos foi definido, pelo menos para</p><p>alguma extensão. Em organizações que não se envolveram com BPM antes, a equipe de BPM</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 36/192</p><p>tem que começar pelo menos identificando os processos que são relevantes para o problema em</p><p>a mesa, delimitando o escopo desses processos, e identificando as relações entre</p><p>esses processos, como, por exemplo, relações de parte (ou seja, um processo sendo parte de</p><p>outro processo). Esta fase inicial de uma iniciativa de BPM é chamada de identificação de processo</p><p>cátion . Esta fase leva a uma chamada arquitetura de processo , que normalmente leva</p><p>a forma de uma coleção de processos e ligações entre esses processos que representam</p><p>diferentes tipos de relação.</p><p>Em geral, o objetivo de se envolver em uma iniciativa de BPM é garantir que o negócio</p><p>processos de qualidade cobertos pela iniciativa de BPM levam a resultados consistentemente positivos</p><p>e entregar o máximo valor à organização no atendimento a seus clientes. Medindo</p><p>o valor entregue por um processo é uma etapa crucial no BPM. Como software de renome en-</p><p>o gineer, Tom DeMarco, disse uma vez: “Você não pode controlar o que não pode medir</p><p>certo". Portanto, antes de começar a analisar qualquer processo em detalhes, é importante claramente</p><p>definir as medidas de desempenho do processo (também chamadas de métricas de desempenho do processo )</p><p>que será usado para determinar se um processo está em "boa forma" ou "ruim</p><p>forma".</p><p>Medidas relacionadas a custos são uma classe recorrente de medidas no contexto de BPM.</p><p>Por exemplo, voltando ao processo de aluguel de equipamentos, uma possível atuação</p><p>medida é o custo total de todos os equipamentos alugados pela BuildIT por intervalo de tempo (por exemplo</p><p>por mês). Outra classe ampla e recorrente de medidas são aquelas relacionadas ao tempo.</p><p>Um exemplo é a quantidade média de tempo decorrido entre o momento em que um equipamento</p><p>O pedido de aluguel é submetido por um engenheiro do local e a entrega do equipamento</p><p>para o canteiro de obras. Essa medida é geralmente chamada de tempo de ciclo . Finalmente, um terceiro</p><p>A classe de medidas recorrentes são aquelas relacionadas à qualidade e, especificamente, às taxas de erro.</p><p>Página 38</p><p>16 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>A taxa de erro é a porcentagem de vezes que uma execução do processo termina em um</p><p>resultado negativo. No caso do processo de aluguel de equipamentos, uma dessas medidas</p><p>é o número de equipamentos devolvidos por serem inadequados, ou devido</p><p>a defeitos no equipamento entregue. A identificação de tal medida de desempenho</p><p>certezas (e objetivos de desempenho associados) são cruciais em qualquer iniciativa de BPM. este</p><p>a identificação é geralmente vista como parte da fase de identificação do processo, embora</p><p>em alguns casos, pode ser adiado para fases posteriores.</p><p>Exercício 1.3 Considere o processo de admissão do aluno descrito no Exercício 1.1 .</p><p>Do ponto de vista do cliente, identifique pelo menos duas medidas de desempenho</p><p>que pode ser anexado a este processo.</p><p>Uma vez que uma equipe de BPM identificou quais processos estão lidando e quais</p><p>medidas de desempenho devem ser usadas, a próxima fase para a equipe é entender</p><p>o processo de negócios em detalhes. Chamamos essa fase de descoberta de processo . Normalmente, um dos</p><p>os resultados desta fase são um ou vários modelos de processo as -is . Estes as-is pro</p><p>modelos de processos devem refletir o entendimento de que as pessoas na organização têm</p><p>sobre como o trabalho é feito. Os modelos de processos têm como objetivo facilitar a comunicação entre</p><p>entre as partes interessadas envolvidas em uma iniciativa de BPM. Portanto, eles têm que ser fáceis</p><p>para entender. Em princípio, poderíamos modelar um processo de negócios por meio do tex-</p><p>descrições reais, como a descrição textual no Exemplo 1.1 . No entanto, tal textual</p><p>as descrições são complicadas de ler e fáceis de interpretar erroneamente por causa do ambiente</p><p>identidade inerente ao texto de formato livre. É por isso que é prática comum usar diagramas</p><p>para modelar processos de negócios. Os diagramas nos permitem compreender mais facilmente</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 37/192</p><p>o processo. Além disso, se o diagrama for feito usando uma notação que seja compreendida por todos</p><p>partes interessadas, há menos espaço para qualquer mal-entendido. Observe que esses diagramas</p><p>ainda pode ser complementado com descrições textuais, de fato, é comum ver</p><p>analistas documentando um processo usando uma combinação</p><p>de diagramas e texto.</p><p>Existem muitas linguagens para modelar processos de negócios em forma de diagrama.</p><p>Talvez um dos mais antigos sejam fluxogramas . Em sua forma mais básica, fluxogramas</p><p>consistem em retângulos, representando atividades, e diamantes, representando pontos em</p><p>o processo em que uma decisão é tomada. De forma mais geral, podemos dizer que independentemente</p><p>a notação específica usada, um modelo de processo diagramático normalmente consiste em dois</p><p>tipos de nó: nós de atividade e nós de controle. Nós de atividade descrevem unidades de</p><p>trabalho que pode ser realizado por humanos ou aplicativos de software, ou uma combinação</p><p>disso. Os nós de controle capturam o fluxo de execução entre as atividades. Apesar</p><p>nem todas as linguagens de modelagem de processo o suportam, um terceiro tipo importante de elemento</p><p>em modelos de processo são nós de eventos. Um nó de evento nos diz que algo pode ou</p><p>deve acontecer, dentro do processo ou no ambiente do processo, que requer um</p><p>reação, como por exemplo a chegada de uma mensagem de um cliente pedindo para cancelar</p><p>seu pedido de compra. Outros tipos de nó podem aparecer em um modelo de processo, mas podemos</p><p>dizem que os nós de atividade, nós de evento e nós de controle são os mais básicos.</p><p>Existem várias extensões de fluxogramas, como fluxogramas interorganizacionais,</p><p>onde o fluxograma é dividido nas chamadas raias que denotam diferentes organismos</p><p>unidades nacionais (por exemplo, diferentes departamentos em uma empresa). Se você está familiarizado com o</p><p>Página 39</p><p>1.4 O ciclo de vida do BPM 17</p><p>Fig. 1.6 Modelo de processo para um fragmento inicial do processo de aluguel de equipamento</p><p>Linguagem de modelagem unificada (UML), você provavelmente terá encontrado UML Ac-</p><p>Diagramas de atividade . Em sua essência, os diagramas de atividades UML são interorganizacionais</p><p>fluxogramas. No entanto, os diagramas de atividades UML vão além da organização cruzada</p><p>fluxogramas, fornecendo símbolos para capturar objetos de dados, sinais e paralelismo</p><p>entre outros aspectos. Ainda outra linguagem para modelagem de processos é orientada a eventos</p><p>Cadeias de processo ( EPCs ). EPCs têm algumas semelhanças com fluxogramas, mas eles diferem</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 38/192</p><p>de fluxogramas em que tratam os eventos como cidadãos de primeira classe. Outros idiomas usados</p><p>para modelagem de processos incluem diagramas de fluxo de dados e IDEF3 , apenas para citar dois.</p><p>Seria estonteante tentar aprender todas essas línguas ao mesmo tempo. Felizmente,</p><p>hoje em dia existe um padrão amplamente utilizado para modelagem de processos, a saber, o Business</p><p>Modelo de Processo e Notação (BPMN). A última versão do BPMN é BPMN 2.0.</p><p>Foi lançado como padrão pelo Object Management Group (OMG) em 2011.</p><p>No BPMN, as atividades são representadas como retângulos arredondados. Nós de controle (chamados</p><p>gateways ) são representados usando formas de diamante. Atividades e nós de controle são</p><p>conectados por meio de arcos (chamados de fluxos) que determinam a ordem em que o</p><p>cess é executado. A Figura 1.6 fornece um modelo que representa um fragmento inicial do</p><p>processo de aluguel de equipamentos, até o ponto em que o engenheiro da obra aceita ou rejeita</p><p>a solicitação de aluguel de equipamento. Este modelo de processo mostra dois pontos de decisão. No</p><p>primeiro, o processo segue um de dois caminhos, dependendo se o equipamento</p><p>está disponível ou não. No segundo, a solicitação de aluguel do equipamento é aprovada ou</p><p>rejeitado. O modelo também mostra os participantes do processo envolvidos neste fragmento</p><p>do processo, nomeadamente o engenheiro de obra, o escriturário e o engenheiro de obra. Cada um de</p><p>esses participantes são mostrados como uma via separada contendo as atividades realizadas por</p><p>o participante em questão.</p><p>Página 40</p><p>18 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>O modelo de processo da Figura 1.6 é capturado em um alto nível de abstração. Na melhor das hipóteses</p><p>pode servir para dar a uma pessoa externa um resumo do que acontece neste processo.</p><p>Em alguns casos, porém, o modelo precisa de mais detalhes para ser útil. Qual</p><p>detalhes adicionais devem ser incluídos em um modelo de processo depende da finalidade.</p><p>Muitas vezes, os modelos de processo têm como objetivo servir como documentação do caminho</p><p>uma organização funciona. Neste caso, as principais características dos modelos de processo são</p><p>simplicidade e compreensibilidade. Assim, anotações de texto adicionais podem ser</p><p>adicionado ao modelo de processo para esclarecer o significado de certas atividades ou eventos, mas</p><p>além dessas anotações, nenhum detalhe adicional seria adicionado. Em outros casos,</p><p>os modelos de processo devem ser analisados em detalhes, por exemplo, a fim de medir</p><p>desempenho seguro do processo. Neste caso, mais detalhes podem ser necessários, como como</p><p>quanto tempo cada tarefa leva (em média). Finalmente, em alguns casos, os modelos de processo são</p><p>pretende ser implantado em um BPMS com a finalidade de coordenar a execução</p><p>do processo (cf. Seção 1.3.3 ). No último caso, o modelo precisa ser estendido</p><p>com uma quantidade significativa de detalhes sobre as entradas e saídas do processo</p><p>e cada uma de suas atividades.</p><p>Tendo entendido o processo como está em detalhes, a próxima etapa é identificar e</p><p>analisar as questões neste processo. Um problema potencial no aluguel de equipamentos da BuildIT</p><p>processo é que o tempo de ciclo é muito alto. Como resultado, os engenheiros do site não conseguem</p><p>obtenha o equipamento necessário a tempo. Isso pode causar atrasos em várias obras</p><p>tarefas, que podem resultar em atrasos nos projetos de construção. A fim de</p><p>analisar esses problemas, um analista precisaria coletar informações sobre o tempo</p><p>gasto em cada tarefa do processo, incluindo a quantidade de tempo que o processo</p><p>participantes gastam realmente fazendo o trabalho e a quantidade de tempo ocioso, o que significa que</p><p>quantidade de tempo em que a solicitação do equipamento é bloqueada, esperando por algo para</p><p>acontecer. Esse tempo ocioso também é chamado de tempo de espera . Além disso, o analista precisaria</p><p>coletar informações sobre a quantidade de retrabalho que ocorre no processo.</p><p>Aqui, retrabalho significa que uma ou várias tarefas são repetidas porque algo foi</p><p>errado. Por exemplo, quando o funcionário identifica uma peça adequada de equipamento em um</p><p>catálogo do fornecedor, mas depois descobre que o equipamento não está disponível</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 39/192</p><p>nas datas exigidas, o funcionário pode precisar procurar novamente por uma peça alternativa</p><p>de equipamentos de outro fornecedor. Tempo valioso é gasto pelo funcionário voltando</p><p>e adiante entre consultar os catálogos e entrar em contato com os fornecedores para verificar o</p><p>disponibilidade de plantas. Para analisar este problema, o analista precisaria encontrar</p><p>em que porcentagem de casos a verificação de disponibilidade falha e, portanto, com que frequência o</p><p>o funcionário precisa fazer algum retrabalho para identificar peças alternativas de equipamento</p><p>e verifique sua disponibilidade. Dada esta informação, um analista de processo pode empregar</p><p>várias técnicas a serem discutidas ao longo deste livro, a fim de rastrear o</p><p>causa (s) de tempos de ciclo longos e para identificar formas de alterar o processo em ordem</p><p>para reduzir o tempo de ciclo.</p><p>Outro problema potencial no processo de aluguel de equipamentos da BuildIT é que às vezes</p><p>o equipamento entregue no local da construção é inadequado, e o engenheiro do local</p><p>tem que rejeitá-lo. Este é um exemplo de resultado negativo. Para analisar este problema,</p><p>um analista precisaria descobrir com que freqüência esses resultados negativos estão ocorrendo.</p><p>Em segundo lugar, os analistas precisariam obter informações que lhes permitissem</p><p>para entender por que esses resultados negativos estão acontecendo. Em outras palavras, onde</p><p>Página 41</p><p>1.4 O</p><p>ciclo de vida do BPM 19</p><p>as coisas deram errado em primeiro lugar? Às vezes, esse resultado negativo pode</p><p>resultam de falta de comunicação, por exemplo, entre o engenheiro do local e o balconista.</p><p>Caso contrário, pode vir de dados imprecisos (por exemplo, erros na descrição do</p><p>equipamento) ou de um erro do lado do fornecedor. Apenas identificando, classificando</p><p>e, finalmente, compreender as principais causas de tais resultados negativos pode um</p><p>analista descobrir qual seria a forma mais adequada de abordar esta questão. o</p><p>identificação e avaliação de problemas e oportunidades para melhoria de processos</p><p>é aqui chamada de fase de análise do processo .</p><p>Observamos que as duas questões discutidas acima estão intimamente relacionadas ao desempenho</p><p>medidas. Por exemplo, o primeiro problema acima está relacionado ao tempo de ciclo e tempo de espera,</p><p>ambos são medidas de desempenho típicas de um processo. Da mesma forma, o segundo</p><p>questão está ligada à "porcentagem de rejeições de equipamentos", que é essencialmente um erro</p><p>taxa - outra medida típica de desempenho. Assim, avaliando os problemas de um processo</p><p>muitas vezes anda de mãos dadas com a medição do estado atual do processo com respeito</p><p>a certas medidas de desempenho.</p><p>Exercício 1.4 Considere novamente o processo de admissão do aluno descrito em Exer-</p><p>cise 1.1 . Do ponto de vista do cliente, pense em pelo menos duas questões que</p><p>este processo pode ter.</p><p>Depois que os problemas em um processo forem analisados e possivelmente quantificados, o próximo</p><p>fase é identificar e analisar soluções potenciais para esses problemas. Neste ponto, o</p><p>analista irá considerar várias opções possíveis para resolver um problema. Fazendo</p><p>então, o analista precisa ter em mente que uma mudança em um processo para abordar um</p><p>problema pode potencialmente causar outros problemas no caminho. Por exemplo, para</p><p>acelerar o processo de aluguel de equipamentos, pode-se pensar em remover a aprovação</p><p>etapas envolvendo o engenheiro de obra. No entanto, se for levado ao extremo, essa mudança</p><p>significaria que o equipamento alugado pode às vezes não ser o ideal, uma vez que o</p><p>o ponto de vista do engenheiro de obras não é levado em consideração. O engenheiro de obras tem uma</p><p>visão sobre os projetos de construção e pode ser capaz de propor formas alternativas de</p><p>abordar as necessidades de equipamento de um projeto de construção de uma maneira mais eficaz.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 40/192</p><p>Alterar um processo não é tão fácil quanto parece. As pessoas estão acostumadas a trabalhar em um cer-maneira segura e pode resistir às mudanças. Além disso, se a mudança implicar em modificar o</p><p>sistema (s) de informação que sustentam o processo, a mudança pode ser cara ou pode</p><p>exigem mudanças não só na organização que coordena o processo, mas também na</p><p>outras organizações. Por exemplo, uma maneira de eliminar o retrabalho que o funcionário tem</p><p>a fazer ao verificar a disponibilidade de equipamentos, seria que os fornecedores</p><p>vide informações sobre a disponibilidade de plantas. Dessa forma, o balconista usaria</p><p>a mesma interface para procurar equipamentos adequados e verificar a disponibilidade de</p><p>o equipamento pelo período de tempo necessário. No entanto, essa mudança no processo</p><p>exigiria que os fornecedores mudassem seu sistema de informação, de modo que seu sistema</p><p>tem expõe informações atualizadas de disponibilidade de equipamento para BuildIT. Esta mudança</p><p>está pelo menos parcialmente fora do controle do BuildIT. Supondo que os fornecedores</p><p>ser capaz de fazer tais mudanças, uma solução mais radical que poderia ser considerada</p><p>seria fornecer dispositivos móveis e conexão à Internet para os engenheiros do site, para</p><p>Página 42</p><p>20 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>que eles podem consultar o catálogo de equipamentos (incluindo informações de disponibilidade)</p><p>Qualquer tempo e qualquer lugar. Dessa forma, o secretário não precisaria estar envolvido no</p><p>processo durante a fase de busca de equipamentos, evitando assim falhas de comunicação</p><p>entre o engenheiro do local e o balconista. Se esta mudança mais radical é ou não</p><p>viável exigiria uma análise aprofundada do custo de mudança do processo neste</p><p>forma versus os benefícios que tal mudança traria.</p><p>Exercício 1.5 Dados os problemas no processo de admissão identificados no Exercício 1.4 ,</p><p>que possíveis mudanças você acha que poderiam ser feitas neste processo, a fim de resolver</p><p>estas questões?</p><p>Equipado com a compreensão de um ou vários problemas em um processo e um pode</p><p>conjunto de soluções potenciais, os analistas podem propor uma versão redesenhada do</p><p>processo, em outras palavras, um to-be processo que iria resolver os problemas identificados</p><p>no processo como está. Este processo futuro é a principal saída do redesenho do processo</p><p>fase . Aqui, é importante ter em mente que a análise e o redesenho são intrincadamente</p><p>relacionados. Pode haver várias opções de redesenho e cada uma dessas opções deve</p><p>ser analisado, de modo que uma escolha informada possa ser feita sobre qual opção deve ser</p><p>escolhido.</p><p>Depois de redesenhados, as mudanças necessárias nas formas de trabalho e no sistema de TI</p><p>fatores da organização devem ser implementados de modo que o processo futuro possa até</p><p>ser posta em execução. Esta fase é chamada de implementação de processo . No</p><p>caso do processo de aluguel de equipamentos, a fase de implementação do processo significaria</p><p>colocar em prática um sistema de informação para registrar e rastrear o aluguel de equipamentos</p><p>quests, POs associados a pedidos aprovados e faturas associadas a esses POs.</p><p>A implantação de tal sistema de informação significa não apenas desenvolver a composição de TI</p><p>nents deste sistema. Também se relacionaria ao treinamento dos participantes do processo para que</p><p>eles realizam seu trabalho no espírito do processo redesenhado e fazem o melhor uso</p><p>dos componentes de TI do sistema.</p><p>De forma mais geral, a implementação do processo pode envolver duas facetas complementares:</p><p>gerenciamento de mudanças organizacionais e automação de processos . Mudança organizacional</p><p>gestão refere-se ao conjunto de atividades necessárias para mudar a forma de trabalhar de</p><p>todos os participantes envolvidos no processo. Essas atividades incluem:</p><p>• Explicar as mudanças para os participantes do processo ao ponto que eles entendem</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 41/192</p><p>saber quais mudanças estão sendo introduzidas e por que essas mudanças são benéficas</p><p>cial para a empresa.</p><p>• Colocar em prática um plano de gestão de mudança para que as partes interessadas saibam quando</p><p>as mudanças sejam postas em vigor e quais disposições transitórias serão adotadas</p><p>planejado para resolver problemas durante a transição para o processo futuro.</p><p>• Treinar os usuários para a nova forma de trabalhar e monitorar as mudanças a fim de</p><p>garantir uma transição suave para o processo futuro.</p><p>Por outro lado, a automação do processo envolve a configuração ou implementação</p><p>de um sistema de TI (ou a reconfiguração de um sistema de TI existente) para apoiar o</p><p>Processo “futuro”. Este sistema deve apoiar os participantes do processo no desempenho</p><p>Página 43</p><p>1.4 O ciclo de vida do BPM 21</p><p>Fig. 1.7 Ciclo de vida BPM</p><p>das tarefas do processo. Isso pode incluir a atribuição de tarefas aos participantes do processo,</p><p>ajudando os participantes do processo a priorizar seu trabalho, fornecendo aos participantes do processo</p><p>com as informações de que precisam para realizar uma tarefa e realizar cruzamentos automatizados</p><p>verificações e outras tarefas automatizadas sempre que possível. Existem várias maneiras de im-</p><p>implementar tal sistema de TI. Este livro se concentra em uma abordagem particular, que</p><p>consiste em estender o modelo de processo a ser obtido a partir do redesenho do processo</p><p>fase para torná-lo executável por um BPMS (cf. Seção 1.3.3 ).</p><p>Com o tempo, alguns ajustes podem ser necessários porque</p><p>o negócio implementado</p><p>processo de ness não atende às expectativas. Para tanto, o processo precisa ser moni-</p><p>orientado e os analistas devem examinar os dados coletados, monitorando o processo em</p><p>a fim de identificar os ajustes necessários para melhor controlar a execução do processo.</p><p>Essas atividades são englobadas pela fase de monitoramento e controle do processo .</p><p>Esta fase é importante porque abordar um ou um punhado de problemas em um processo</p><p>não é o fim da história. Em vez disso, gerenciar um processo requer um esforço contínuo.</p><p>A falta de monitoramento e melhoria contínua de um processo leva à degradação.</p><p>Como Michael Hammer certa vez disse: "todo bom processo eventualmente se torna um mau pro-</p><p>cess ”, a menos que seja continuamente adaptado e melhorado para acompanhar as constantes mudanças</p><p>panorama das necessidades do cliente, tecnologia e concorrência. É por isso que as fases</p><p>no ciclo de vida do BPM deve ser visto como circular: a saída do monitoramento e</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 42/192</p><p>o controle realimenta as fases de descoberta, análise e redesenho.</p><p>Para resumir, podemos ver o BPM como um ciclo contínuo compreendendo o seguinte</p><p>fases (ver Fig. 1.7 ):</p><p>• Identificação do processo. Nesta fase, um problema de negócios é colocado, os processos rele-</p><p>vantajosa para o problema a ser abordado são identificados, delimitados e relacionados a cada</p><p>de outros. O resultado da identificação do processo é um arquivo de processo novo ou atualizado</p><p>tectura que fornece uma visão geral dos processos em uma organização e seus</p><p>relacionamentos. Em alguns casos, a identificação do processo é feita em paralelo com</p><p>Página 44</p><p>22 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>identificação da medida de desempenho. Neste livro, no entanto, vamos associar desempenho</p><p>identificação da medida de mance com a fase de análise do processo, dado que o desempenho</p><p>Medidas de mance são freqüentemente usadas para análise de processos.</p><p>• Descoberta de processo (também chamada de modelagem de processo no estado em que se encontra). Aqui, o estado atual</p><p>de cada um dos processos relevantes é documentado, normalmente na forma de um ou</p><p>vários modelos de processo as-is. 2</p><p>• Análise de processos. Nesta fase, os problemas associados ao processo as-is são identificados</p><p>cado, documentado e, sempre que possível, quantificado por meio de medidas de desempenho.</p><p>A saída desta fase é uma coleção estruturada de questões. Esses problemas são típicos</p><p>priorizados em termos de seu impacto e, às vezes, também em termos de</p><p>esforço estimado necessário para resolvê-los.</p><p>• Redesenho de processos (também chamado de melhoria de processos ). O objetivo desta fase é</p><p>identificar mudanças no processo que ajudariam a resolver os problemas identificados</p><p>na fase anterior e permitir que a organização cumpra seus objetivos de desempenho</p><p>tives. Para este fim, várias opções de mudança são analisadas e comparadas em termos de</p><p>as medidas de desempenho escolhidas. Isso implica que o redesenho do processo e o processo</p><p>análise andam de mãos dadas: à medida que novas opções de mudança são propostas, elas são ana-</p><p>lisado usando técnicas de análise de processo. Eventualmente, a mudança mais promissora</p><p>as opções são combinadas, levando a um processo redesenhado. A saída desta fase</p><p>é tipicamente um modelo de processo futuro, que serve como base para a próxima fase.</p><p>• Implementação de processos. Nesta fase, as mudanças necessárias para sair do</p><p>processo como está para o processo futuro são preparados e executados. Processo de implementação</p><p>mentação cobre dois aspectos: gestão e processo de mudança organizacional</p><p>automação. Gestão de mudança organizacional refere-se ao conjunto de atividades re-</p><p>quis mudar a forma de trabalhar de todos os participantes envolvidos no processo.</p><p>A automação de processos, por outro lado, se refere ao desenvolvimento e implantação</p><p>de sistemas de TI (ou versões aprimoradas de sistemas de TI existentes) que suportam o futuro</p><p>processo. Neste livro, nosso foco com relação à implementação de processos está em</p><p>automação de processos, já que o gerenciamento de mudanças organizacionais é um processo totalmente separado</p><p>campo. Mais especificamente, o livro apresenta uma abordagem para automação de processos</p><p>em que um modelo de processo executável é derivado do modelo de processo a ser</p><p>e este modelo executável é implantado em um BPMS.</p><p>• Monitoramento e controle de processos. Assim que o processo redesenhado estiver em execução, rel-</p><p>dados evidentes são coletados e analisados para determinar o quão bem está o processo por</p><p>formando com relação às suas medidas de desempenho e objetivos de desempenho.</p><p>Gargalos, erros recorrentes ou desvios em relação ao comportamento pretendido</p><p>são identificados e ações corretivas são realizadas. Novos problemas podem surgir, em</p><p>o mesmo ou em outros processos, exigindo que o ciclo seja repetido de forma contínua</p><p>base.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 43/192</p><p>2 Esta fase também é chamada de projeto de processo na literatura. No entanto, a descoberta do processo é indiscutivelmente um</p><p>termo mais apropriado, uma vez que o processo já existe, pelo menos implicitamente na cabeça dos atores</p><p>quem o executa. O objetivo dessa fase é geralmente descobrir o processo, em vez de projetá-lo.</p><p>Em casos raros (por exemplo, novas empresas), nenhum processo ainda está em vigor, então as fases de descoberta e análise</p><p>não são necessários e o processo deve ser projetado pela primeira vez, em vez de redesenhado.</p><p>Página 45</p><p>1.4 O ciclo de vida do BPM 23</p><p>O ciclo de vida do BPM ajuda a entender o papel da tecnologia no BPM. Tech-</p><p>tecnologia em geral, e especialmente Tecnologia da Informação (TI), é um instrumento fundamental</p><p>para melhorar os processos de negócios. Não surpreendentemente, especialistas de TI, como sistemas de engi-</p><p>Os neers geralmente desempenham um papel significativo nas iniciativas de BPM. No entanto, para atingir o máximo</p><p>eficácia, os engenheiros de sistema precisam estar cientes de que a tecnologia é apenas um instrumento</p><p>para gerenciar e executar processos. Os engenheiros de sistema precisam trabalhar em conjunto com</p><p>analistas de processo, a fim de compreender quais são as principais questões que afetam um determinado pro-</p><p>processo, e como melhor resolver esses problemas, seja por meio de automação ou por outro</p><p>significa. Como um renomado empresário de tecnologia, Bill Gates, uma vez disse isso:</p><p>“A primeira regra em qualquer tecnologia usada em um negócio é que a automação aplicada a</p><p>uma operação eficiente aumentará a eficiência. A segunda é que a automação</p><p>aplicado a uma operação ineficiente aumentará a ineficiência ”. Isso significa que</p><p>aprender como projetar e melhorar processos - e não apenas como construir um sistema de TI</p><p>sistema para automatizar uma parte estreita de um processo de negócios - é uma habilidade fundamental que</p><p>deve estar nas mãos de qualquer graduado em TI. Reciprocamente, os graduados em negócios precisam</p><p>para entender como a tecnologia, e particularmente TI, pode ser usada para otimizar o ex-</p><p>execução de processos de negócios. Este livro visa estabelecer uma ponte entre esses dois pontos de vista,</p><p>apresentando um ponto de vista integrado cobrindo todo o ciclo de vida do BPM.</p><p>Um ponto de vista complementar sobre o ciclo de vida do BPM é fornecido pela caixa “Stake-</p><p>titulares do ciclo de vida do BPM ”. Esta caixa resume as funções em uma empresa que</p><p>estão direta ou indiretamente envolvidos em iniciativas de BPM. 3 A lista de funções descritas em</p><p>a caixa destaca o fato de que BPM é interdisciplinar. Uma iniciativa típica de BPM</p><p>envolve gerentes em diferentes níveis da organização, administrativo e de campo</p><p>trabalhadores (chamados de participantes do processo na caixa), analistas de negócios e de sistema e</p><p>Equipes de TI. Assim, o livro visa fornecer uma visão equilibrada das técnicas, tanto</p><p>da ciência da gestão e TI,</p><p>no que se refere ao BPM.</p><p>STAKEHOLDERS NO CICLO DE VIDA BPM</p><p>Existem diferentes partes interessadas envolvidas com um processo de negócios em todo</p><p>seu ciclo de vida. Entre eles podemos distinguir os seguintes indivíduos e</p><p>grupos.</p><p>• Equipe de gerenciamento . Dependendo de como a gestão de uma empresa é</p><p>organizado, pode-se encontrar as seguintes posições. O Executivo Principal</p><p>ficer ( CEO ) é responsável pelo sucesso geral dos negócios da empresa.</p><p>O Diretor de Operações ( COO ) é responsável por definir a forma</p><p>operações são configuradas. Em algumas empresas, o COO também é responsável por</p><p>desempenho do processo, enquanto em outras empresas, há uma posição</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 44/192</p><p>3 A função do cliente não está listada na caixa, pois esta função já foi discutida em</p><p>Seções.</p><p>Página 46</p><p>24 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>ção do Chief Process Officer ( CPO ) para este fim. The Chief Information</p><p>Officer ( CIO ) é responsável pela operação eficiente e eficaz do</p><p>infra-estrutura de sistema de informação. Em algumas organizações, redesenho de processos</p><p>os projetos são conduzidos pelo CIO. O Diretor Financeiro ( CFO ) é re-</p><p>responsável pelo desempenho financeiro geral da empresa. O CFO</p><p>também pode ser responsável por certos processos de negócios, particularmente aqueles</p><p>que têm um impacto direto no desempenho financeiro. Outro gerenciamento de po-</p><p>situações que têm interesse no ciclo de vida dos processos incluem o Humano</p><p>Diretor de Recursos ( RH ) . O diretor de RH e sua equipe desempenham um papel fundamental na</p><p>processos que envolvem um número significativo de participantes do processo. Em qualquer</p><p>caso, a equipe de gestão é responsável por supervisionar todos os processos, ini-</p><p>promover iniciativas de redesenho de processos e fornecer recursos e estratégias</p><p>orientação para as partes interessadas envolvidas em todas as fases da vida do processo de negócios-</p><p>ciclo.</p><p>• Proprietários do processo . Um proprietário de processo é responsável pela eficiência e eficácia</p><p>operação ativa de um determinado processo. Conforme discutido no contexto da Fig. 1.5 ,</p><p>um proprietário do processo é responsável por um lado pelo planejamento e organização,</p><p>e por outro lado, para monitorar e controlar o processo. Em seus</p><p>papel de planejamento e organização, o proprietário do processo é responsável por definir</p><p>medidas de desempenho e objetivos, bem como iniciar e liderar im-</p><p>projetos de comprovação relacionados ao seu processo. Eles também são responsáveis por</p><p>garantir recursos para que o processo seja executado sem problemas em uma base diária. No</p><p>seu papel de monitoramento e controle, os proprietários do processo são responsáveis por</p><p>garantindo que os objetivos de desempenho do processo sejam atendidos e levando</p><p>ações corretivas caso não sejam atendidas. Os proprietários do processo também fornecem</p><p>orientação para os participantes do processo sobre como resolver exceções e erros</p><p>que ocorrem durante a execução do processo. Assim, o proprietário do processo é</p><p>envolvido na modelagem de processos, análise, redesenho, implementação e mon-</p><p>itoring. Observe que o mesmo indivíduo pode muito bem ser responsável por vários</p><p>processos ple. Por exemplo, em uma pequena empresa, um único gerente pode</p><p>ser responsável tanto pelo processo de pedido ao pagamento da empresa quanto pelo</p><p>processo de atendimento ao cliente pós-venda.</p><p>• Participantes do processo . Os participantes do processo são atores humanos que atuam</p><p>as atividades de um processo de negócios no dia-a-dia. Eles conduzem</p><p>trabalho rotineiro de acordo com as normas e diretrizes da empresa.</p><p>Os participantes do processo são coordenados pelo proprietário do processo, que está respondendo</p><p>capaz de lidar com aspectos não rotineiros do processo. Participantes do processo</p><p>também estão envolvidos como especialistas de domínio durante a descoberta de processos e processos</p><p>análise. Eles apóiam atividades de redesenho e esforços de implementação.</p><p>• Analistas de processos . Os analistas de processo conduzem a identificação do processo, descobrem</p><p>eria (em particular modelagem), atividades de análise e redesenho. Eles coor-</p><p>implementação de processos dinâmicos, bem como monitoramento e controle de processos</p><p>ling. Eles se reportam à gestão e aos proprietários do processo e interagem intimamente</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 45/192</p><p>Página 47</p><p>1.4 O ciclo de vida do BPM 25</p><p>com os participantes do processo. O analista de processo normalmente tem um de dois</p><p>motivos. Analistas de processo preocupados com os requisitos organizacionais, por</p><p>formance e o gerenciamento de mudanças têm experiência em negócios. Significar-</p><p>enquanto, analistas de processos preocupados com a automação de processos têm uma equipe de TI</p><p>fundo.</p><p>• Engenheiros de sistema . Engenheiros de sistema estão envolvidos no redesenho de processos e</p><p>implementação. Eles interagem com analistas de processo para capturar sistema de recuperação</p><p>quirements. Eles traduzem os requisitos em um design de sistema e são</p><p>responsável pela implementação, teste e implantação deste sistema.</p><p>Os engenheiros de sistema também fazem a ligação com o proprietário do processo e os participantes do processo</p><p>calças para garantir que o sistema desenvolvido apoie o seu trabalho de uma forma eficaz</p><p>maneira ativa. Muitas vezes, implementação, teste e implantação de sistema</p><p>são terceirizados para fornecedores externos, caso em que a engenharia do sistema</p><p>a equipe será composta pelo menos parcialmente por contratados.</p><p>• O Grupo BPM (também denominado Centro de Excelência BPM ). Grande organização</p><p>ções que estiveram envolvidas em BPM por vários anos normalmente teriam</p><p>acumulou conhecimento valioso sobre como planejar e executar projetos de BPM</p><p>bem como quantidades substanciais de documentação do processo. O Grupo BPM</p><p>é responsável por preservar este conhecimento e documentação e garantir</p><p>que eles são usados para atender aos objetivos estratégicos da organização. Especifi-</p><p>naturalmente, o grupo de BPM é responsável por manter a arquitetura do processo</p><p>estrutura, priorizando projetos de redesenho de processos, dando suporte ao processo</p><p>proprietários e analistas de processo, e garantindo que a documentação do processo</p><p>é mantido de forma consistente e que o sistema de monitoramento de processo</p><p>tems estão trabalhando de forma eficaz. Em outras palavras, o grupo BPM é responsável</p><p>para manter uma cultura BPM e garantir que esta cultura BPM seja suprida</p><p>portar os objetivos estratégicos da organização. Nem todas as organizações têm um</p><p>Grupo de BPM dedicado. Grupos de BPM são mais comuns em grandes organizações</p><p>com anos de experiência em BPM.</p><p>No restante do livro, mergulharemos consecutivamente em cada uma das fases do</p><p>Ciclo de vida do BPM. O Capítulo 2 trata da fase de identificação do processo. Capítulos 3 - 4</p><p>fornecer uma introdução à modelagem de processos, que serve como pano de fundo para sub-</p><p>fases sequentes no ciclo de vida do BPM. O Capítulo 5 trata da descoberta do processo</p><p>Estágio. Capítulos 6 - 7 número um presente de técnicas de análise de processo. Nós classificamos</p><p>essas técnicas em qualitativas (Cap. 6 ) e quantitativas (Cap. 7 ). Um quan-</p><p>técnica titativa é aquela que leva dados brutos ou medições como entrada (por exemplo, desempenho</p><p>mance mede ao nível das tarefas) e produz medidas agregadas e</p><p>resumos quantitativos como saída. Por outro lado, uma técnica qualitativa envolve</p><p>julgamento humano, por exemplo, a fim de classificar tarefas ou questões de acordo com sub-</p><p>critérios objetivos. Observe que as técnicas qualitativas podem envolver avaliação quantitativa</p><p>além do julgamento humano, visto que essas duas fontes de insights costumam servir</p><p>objetivos mentais. Em seguida, cap. 8 oferece uma visão geral das técnicas de redesenho de processos,</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f</p><p>46/192</p><p>Página 48</p><p>26 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>enquanto o cap. 9 discute a implementação do processo com foco nos aspectos de automação.</p><p>Finalmente, cap. 10 apresenta ferramentas e técnicas de inteligência de processo, que formam</p><p>a espinha dorsal das práticas modernas de monitoramento de processos.</p><p>1.5 Recapitulação</p><p>Devemos reter neste capítulo que um processo é uma coleção de eventos, atividades</p><p>e decisões que levam coletivamente a um resultado que agrega valor a uma organização</p><p>clientes da zation. Cada organização possui processos. Compreendendo e gerenciando</p><p>esses processos, a fim de garantir que eles produzam valor de forma consistente, é um ingrediente-chave</p><p>diente para a eficácia e competitividade das organizações. Através de seu foco</p><p>nos processos, as organizações estão gerenciando os ativos que são mais importantes para</p><p>servir bem seus clientes.</p><p>Se quiséssemos capturar BPM em poucas palavras, poderíamos dizer que BPM é um corpo</p><p>de princípios, métodos e ferramentas para projetar, analisar, executar e monitorar negócios</p><p>processos. Também vimos que modelos de processos e medidas de desempenho podem ser</p><p>vistos como pilares fundamentais para a gestão de processos. Está muito em cima deles</p><p>da arte e da ciência do BPM. A definição fornecida abrange</p><p>as principais fases do ciclo de vida do BPM e as várias disciplinas relacionadas que compõem</p><p>implementar BPM, como Lean, Six Sigma e Gestão de Qualidade Total. A mira de</p><p>este capítulo era para dar uma "prévia" das atividades e partes interessadas envolvidas</p><p>em cada uma dessas fases. O resto do livro visa lançar luz sobre muitas das</p><p>princípios e métodos que são usados em cada uma dessas fases.</p><p>1.6 Soluções para exercícios</p><p>Solução 1.1</p><p>1. Oficial de admissões, candidato, agência de reconhecimento acadêmico e comissão acadêmica</p><p>mittee. O escritório de admissões como uma unidade organizacional também pode ser reconhecido como</p><p>um ator separado.</p><p>2. O requerente.</p><p>3. Pode-se argumentar que o valor que o processo proporciona ao requerente é o</p><p>avaliação do pedido e subsequente decisão de aceitação ou rejeição. No</p><p>neste caso, o processo agrega valor se o requerente for aceito ou rejeitado,</p><p>desde que o pedido seja processado na devida ordem. Outro ponto de vista seria</p><p>quer dizer que o processo só dá valor ao requerente apenas se o requerente</p><p>é aceite, e não se o candidato for rejeitado. Os argumentos podem ser apresentados em</p><p>favor de qualquer um desses dois pontos de vista.</p><p>4. Candidatura rejeitada devido a documentos incompletos; Candidato rejeitado devido a En-</p><p>resultados do teste de língua inglesa; Candidato rejeitado devido à avaliação do acadêmico</p><p>agência de reconhecimento; Candidato rejeitado devido à decisão do comitê acadêmico;</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 47/192</p><p>Página 49</p><p>1.6 Soluções para exercícios 27</p><p>Candidato aceito. Uma análise mais aprofundada poderia revelar outras possíveis</p><p>vem como "Solicitação retirada pelo candidato" ou "Condição do candidato-</p><p>almente aceite, sujeito ao fornecimento de documentos adicionais ”. No entanto, não há</p><p>elementos suficientes na descrição do processo para determinar se estes</p><p>os resultados são possíveis.</p><p>Solução 1.2</p><p>1. A unidade com necessidade de compra, departamento de compras, o vendedor, o armazém</p><p>casa e o departamento de contas a pagar.</p><p>2. A unidade com necessidade de compra.</p><p>3. O valor que o processo fornece à unidade com necessidade de compra é o</p><p>fornecimento oportuno, preciso e econômico de um item de compra específico. No</p><p>neste caso, o processo agrega valor se a necessidade de compra do item for satisfeita</p><p>enviado por uma remessa oportuna, precisa e econômica de um fornecedor, acompanhada</p><p>com um procedimento de pagamento preciso.</p><p>4. O envio de mercadorias pode ser aceito se for preciso, levando a um correspondente</p><p>pagamento, ou podem ser rejeitados se o montante ou tipo de envio não estiver correto.</p><p>Solução 1.3 As medidas possíveis incluem:</p><p>1. Tempo médio entre o momento em que um aplicativo é recebido e o momento em que ele</p><p>é aceito ou rejeitado (tempo de ciclo). Observe que se a Universidade anunciar um pré-</p><p>prazo definido para notificação de aceitação / rejeição, uma performance alternativa</p><p>medida seria a porcentagem de vezes que esse prazo é cumprido.</p><p>2. Porcentagem de inscrições rejeitadas devido a documentos incompletos. Aqui nós poderíamos</p><p>distinguir entre duas variantes desta medida: uma que conta todos os casos em que</p><p>inscrições são inicialmente rejeitadas devido a documentos incompletos, e outro</p><p>que conta o número de casos em que os pedidos são rejeitados devido a incom-</p><p>documentos completos e quando o requerente não reenviar o pedido preenchido</p><p>plicação, por exemplo, porque o prazo para inscrições expirou antes</p><p>o requerente reúne os documentos necessários.</p><p>3. Porcentagem de inscrições rejeitadas devido ao idioma inglês expirado, inválido ou baixo</p><p>resultados do teste de calibração.</p><p>4. Porcentagem de inscrições rejeitadas devido a conselhos de reconhecimento acadêmico.</p><p>5. Porcentagem de inscrições aceitas.</p><p>Observe que o custo incorrido pela Universidade por aplicação não é uma medida que</p><p>é relevante do ponto de vista do requerente, mas pode ser relevante do</p><p>perspectiva da Universidade.</p><p>Solução 1.4 Os possíveis problemas incluem:</p><p>1. Longos tempos de execução</p><p>2. Inconveniente de reunir e enviar todos os documentos exigidos.</p><p>3. Potencialmente: aplicativos maltratados devido à entrega de documentos em papel</p><p>entre os participantes do processo.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 48/192</p><p>Página 50</p><p>28 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>Solução 1.5</p><p>Para reduzir o tempo de ciclo, bem como aplicativos maltratados, os aplicativos podem ser</p><p>compartilhado em formato eletrônico entre o escritório de admissões e o comitê acadêmico.</p><p>Para reduzir a inconveniência do envio, as inscrições podem ser avaliadas em dois</p><p>estágios. A primeira fase envolveria documentos submetidos exclusivamente eletronicamente</p><p>(por exemplo, cópias digitalizadas em vez de cópias físicas). Somente candidatos aceitos pelo</p><p>o comitê acadêmico então precisaria passar pelo processo de apresentação</p><p>cópias autenticadas de diplomas por correio para verificação pelo reconhecimento acadêmico</p><p>agência.</p><p>1.7 Exercícios adicionais</p><p>Exercício 1.6 Considere o seguinte processo em uma farmácia.</p><p>Os clientes deixam suas prescrições no balcão do drive-through ou na frente</p><p>balcão da farmácia. Os clientes podem solicitar que sua receita seja preenchida imediatamente.</p><p>Nesse caso, eles têm que esperar entre 15 minutos e uma hora, dependendo da corrente</p><p>carga de trabalho. A maioria dos clientes não está disposta a esperar tanto tempo, então eles optam por indicar uma escolha</p><p>mais tarde durante o dia. Geralmente, os clientes deixam suas prescrições no</p><p>manhã antes de ir para o trabalho (ou na hora do almoço) e eles voltam para pegar as drogas</p><p>depois do trabalho, normalmente entre 17h e 18h. Ao descartar sua receita, um técnico</p><p>pergunta ao cliente o horário de coleta e coloca a receita em uma caixa rotulada com o</p><p>hora anterior à hora de pick-up. Por exemplo, se o cliente pede a receita</p><p>estar pronto às 17h, o técnico irá colocá-lo na caixa com a etiqueta 16h (há uma caixa</p><p>para cada hora do dia).</p><p>A cada hora, um dos técnicos da farmácia recolhe as receitas a serem preenchidas no</p><p>hora atual. O técnico então insere os detalhes de cada prescrição (por exemplo, dados médicos,</p><p>detalhes do paciente e detalhes da medicação) no sistema de farmácia. Assim que os detalhes de</p><p>uma prescrição é inserida, o sistema da farmácia realiza uma verificação automatizada chamada Medicamento</p><p>Revisão de utilização (DUR). Esta verificação visa determinar se a receita contém</p><p>quaisquer medicamentos que possam ser incompatíveis com outros medicamentos que tenham sido dispensados ao mesmo</p><p>cliente no passado, ou medicamentos que podem ser inadequados para o cliente,</p><p>levando em consideração</p><p>os dados do cliente mantidos no sistema (por exemplo, idade).</p><p>Todos os alarmes disparados durante o DUR automatizado são revisados por um farmacêutico que realiza um</p><p>verificação mais completa. Em alguns casos, o farmacêutico ainda tem que ligar para o médico que emitiu</p><p>a prescrição para a confirmar.</p><p>Após o DUR, o sistema realiza uma verificação de seguro para determinar se</p><p>a apólice de seguro do cliente arcará com o custo total ou parcial dos medicamentos. No</p><p>na maioria dos casos, a saída desse cheque é que a seguradora pagaria por um determinado</p><p>porcentagem dos custos, enquanto o cliente tem que pagar pela parte restante (também chamada</p><p>o co-pagamento ). As regras para determinar quanto a seguradora pagará e</p><p>quanto o cliente tem que pagar são muito complicados. Cada seguradora tem</p><p>regras diferentes. Em alguns casos, a apólice de seguro não cobre um ou vários medicamentos em um</p><p>prescrição, mas o medicamento em questão pode ser substituído por outro medicamento abrangido pelo</p><p>apólice de seguro. Quando esses casos são detectados, o farmacêutico geralmente liga para o médico</p><p>e / ou o paciente para determinar se é possível realizar a reposição medicamentosa.</p><p>Depois que a receita passa na verificação do seguro, ela é atribuída a um técnico que coleta</p><p>os medicamentos das prateleiras e os coloca em uma sacola com a prescrição grampeada. Af-</p><p>depois que o técnico preencheu uma determinada receita, a sacola é passada para o farmacêutico, que</p><p>Página 51</p><p>1.7 Exercícios adicionais 29</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 49/192</p><p>verifica novamente se a receita foi preenchida corretamente. Após esta verificação de qualidade, o</p><p>O farmacêutico fecha o saco e o coloca na área de coleta. Quando um cliente chega para buscar</p><p>uma receita, um técnico pega a receita e pede ao cliente o pagamento em</p><p>caso os medicamentos na receita não sejam (totalmente) cobertos pelo seguro do cliente.</p><p>Com relação ao processo acima, considere as seguintes questões:</p><p>1. Que tipo de processo é o acima: ordem para pagamento, aquisição para pagamento ou emissão para</p><p>resolução?</p><p>2. Quem são os atores neste processo?</p><p>3. Que valor o processo oferece ao (s) cliente (s)?</p><p>4. Quais são os resultados possíveis deste processo?</p><p>5. Tomando a perspectiva do cliente, quais medidas de desempenho podem estar em</p><p>anexado a este processo?</p><p>6. Que problemas potenciais você prevê que esse processo possa ter? Que informação</p><p>você precisaria coletar para analisar essas questões?</p><p>7. Quais possíveis mudanças você acha que poderiam ser feitas neste processo para</p><p>resolver os problemas acima?</p><p>Agradecimento Este exercício é parcialmente inspirado por Andrew McAfee: “Farmácia</p><p>Melhoria de serviço no CVS ( A ) ”. Harvard Business Publishing, 2005 .</p><p>Exercício 1.7 Considere o seguinte processo em uma empresa com cerca de 800 funcionários</p><p>ees.</p><p>Uma solicitação de compra é iniciada quando um funcionário da empresa preenche e assina um formulário</p><p>no papel. A solicitação de compra inclui informações sobre o bem a ser adquirido, o</p><p>quantidade, a data de entrega desejada, o custo aproximado. O funcionário também pode nomear</p><p>um fornecedor específico. Os funcionários costumam solicitar orçamentos de fornecedores para obter o necessário</p><p>em formação. O preenchimento de todo o formulário pode levar alguns dias, como o solicitante costuma fazer</p><p>não tem os dados necessários. A cotação está anexada à solicitação de compra. Esta completada</p><p>a solicitação é assinada por dois supervisores. Um supervisor deve fornecer uma aprovação financeira ,</p><p>enquanto o outro supervisor tem que aprovar a necessidade da compra e sua conformidade</p><p>com a política da empresa (por exemplo, um software solicitado faz parte do padrão operacional</p><p>meio Ambiente?). A coleta das assinaturas dos dois supervisores leva em média cinco</p><p>dias. Em caso de urgência, o colaborador pode entregar em mãos o formulário, caso contrário é distribuído via</p><p>correio interno. Uma solicitação de compra rejeitada é devolvida ao funcionário. Alguns funcionários</p><p>faça algumas pequenas modificações e tente em uma segunda tentativa outros supervisores, a fim de</p><p>obter a aprovação.</p><p>Assim que uma solicitação de compra é aprovada, ela é devolvida ao funcionário que iniciou a compra</p><p>requisição de perseguição. O funcionário então encaminha o formulário ao Departamento de Compras.</p><p>Muitos funcionários fazem uma cópia do formulário para seu próprio registro, caso o formulário se perca.</p><p>O Departamento de compras central verifica se a solicitação de compra está completa e</p><p>devolve-o ao funcionário se estiver incompleto.</p><p>Com base nas cotações em anexo e outras informações, o Departamento de compras insere o ap-</p><p>solicitação de compra comprovada no Enterprise System da empresa. Se o funcionário não</p><p>nomeado quaisquer fornecedores, um funcionário do Departamento de compras selecionará um com base em</p><p>nas cotações anexadas à requisição de compra, ou com base na lista de fornecedores (também chamada</p><p>Master Vendor List ) disponível no Enterprise System da empresa.</p><p>Às vezes, o orçamento inicial anexado à solicitação expirou nesse meio tempo. Nisso</p><p>caso, a cotação atualizada é solicitada ao fornecedor correspondente. Em outros casos, o fornecedor</p><p>Página 52</p><p>30 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>quem enviou a cotação não é registrado no Enterprise System da empresa. Nesse caso,</p><p>o departamento de compras deve dar preferência a outros fornecedores que estejam registrados em</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 50/192</p><p>o Enterprise System. Se nenhum desses fornecedores estiver disponível ou se os fornecedores registrados oferecerempreços mais altos do que o da cotação enviada, o Departamento de compras pode adicionar o</p><p>novo fornecedor no Enterprise System.</p><p>Quando um fornecedor é selecionado, um pedido de compra é gerado automaticamente pela empresa</p><p>Sistema. Em seguida, um fax é gerado e enviado ao fornecedor. Uma cópia do pedido de compra é</p><p>enviado para o Gabinete de Contas a Pagar, que faz parte do Departamento Financeiro, que utiliza um</p><p>sistema contábil que não está integrado ao Enterprise System.</p><p>As mercadorias são sempre entregues no Departamento de Recebimento de Mercadorias. Quando um bem é recebido,</p><p>um funcionário deste Departamento seleciona o pedido de compra correspondente no Enterprise Sys-</p><p>tem. O balconista verifica a quantidade e qualidade e (no caso positivo) gera um documento</p><p>denominado formulário de recebimento de mercadorias do pedido de compra armazenado no Enterprise System. o</p><p>as mercadorias são então encaminhadas para o empregado que iniciou a requisição de compra. Uma impressão-</p><p>fora do formulário de recebimento de mercadorias é enviado para o Escritório de Contas a Pagar. Se houver algum problema</p><p>com a mercadoria, ela é devolvida ao fornecedor e uma nota em papel é enviada ao Comprador</p><p>Departamento e ao Gabinete de Contas a Pagar.</p><p>O fornecedor eventualmente envia a fatura diretamente para o Escritório de Contas a Pagar. Um funcionário</p><p>neste escritório compara o pedido de compra, o recebimento de mercadorias e a fatura - uma tarefa que é</p><p>geralmente chamado de “combinação de três vias”. A correspondência de três vias pode consumir muito tempo. E se</p><p>há alguma discrepância, pois deve ser investigada, se foi um erro do fornecedor ou</p><p>um erro de entrada de dados. A duração do processo de pagamento infelizmente demora muito</p><p>desde que expire o desconto para pagamento em determinado período.</p><p>Uma transferência bancária é finalmente acionada e um aviso de pagamento é enviado ao fornecedor. Alguns vendedores</p><p>indicar explicitamente em sua fatura o número da conta bancária para onde deseja a transferência</p><p>ocorrer. Pode acontecer que o número da conta bancária e o nome indicado na fatura</p><p>difere daquele registrado no banco de dados do fornecedor. Às vezes, os pagamentos voltam, em</p><p>caso em que o vendedor é contatado por telefone, e-mail ou correio. Se os novos dados</p><p>pela</p><p>méritos da organização baseada em processos.</p><p>Finalmente, e talvez acima de tudo, o livro é uma referência excelente para todos os alunos</p><p>dentes que estão ansiosos para aprender mais sobre e querem abraçar o fascínio de</p><p>BPM. Este livro de BPM, há muito ausente, aborda uma grave lacuna dentro do</p><p>Comunidade BPM, ou seja, a falta de recursos para facilitar a introdução de sub-</p><p>jects em educação superior e corporativa. Tornando o BPM mais acessível para o futuro</p><p>os tomadores de decisão garantem que os processos desempenhem o papel que merecem.</p><p>Michael RosemannBrisbane, Austrália</p><p>Página 7</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 7/192</p><p>Prefácio</p><p>Primeiro, domine os fundamentos.</p><p>Larry Bird (1957–)</p><p>O Business Process Management (BPM) é um campo especial por mais de um motivo.</p><p>Em primeiro lugar, BPM é uma encruzilhada de pontos de vista múltiplos e bastante diferentes. O negócio</p><p>os gerentes são atraídos por BPM por causa de sua capacidade demonstrada de entregar resultados</p><p>provas de desempenho organizacional, conformidade regulatória e qualidade de serviço</p><p>ity. Os engenheiros industriais veem o BPM como uma oportunidade para aplicar a manufatura bem conhecida</p><p>desenvolver técnicas de otimização no contexto de organizações que prestam serviços</p><p>em vez de produtos físicos. Finalmente, especialistas em Tecnologia da Informação (TI) ap-</p><p>precede o fato de que o BPM lhes fornece uma linguagem compartilhada para se comunicar</p><p>com as partes interessadas da empresa. Além disso, tecnologia de automação de processos de negócios</p><p>permite que especialistas de TI implementem e monitorem sistemas de TI de uma forma que esteja alinhada</p><p>com a visão que os stakeholders do negócio têm da organização. Em outras palavras,</p><p>BPM é um campo de fronteira que serve como um cadinho para separar</p><p>comunidades. Para quem já experimentou como gerentes de negócios, industriais</p><p>engenheiros e profissionais de TI muitas vezes parecem viver em mundos diferentes,</p><p>campo de interesse é uma oportunidade notável para alcançar uma compreensão conjunta do</p><p>funcionamento interno de uma empresa.</p><p>Uma segunda característica especial do BPM é que ele é praticado ativamente e</p><p>pesquisado ativamente. Em outras palavras, é um campo onde existem comprovados e</p><p>práticas estabelecidas, bem como desafios abertos. As empresas em todo o mundo são automobilísticas</p><p>realizando iniciativas de BPM com o objetivo de, por exemplo, superar seus concorrentes</p><p>ou atender às demandas de autoridades regulatórias. Acadêmicos em áreas como computador</p><p>ciência, ciência da gestão, sociologia e engenharia estão trabalhando no desenvolvimento</p><p>otimização de métodos e técnicas para apoiar tais iniciativas. É apropriado ver</p><p>BPM como um campo de “teoria na prática”. Por um lado, as demandas práticas inspiram o</p><p>desenvolvimento de novos métodos e tecnologias. Por outro lado, o aplicativo</p><p>desses métodos e tecnologias, na prática, retroalimenta as pranchetas em</p><p>universidades e centros de pesquisa.</p><p>Depois de ensinar BPM a milhares de alunos e profissionais no passado</p><p>década, sentimos fortemente a falta de um livro didático que estruture nossos cursos</p><p>e para permitir que nosso público estude por si mesmo além da aula e lição de casa</p><p>ix</p><p>Página 8</p><p>x Prefácio</p><p>atribuições. Esta situação não se deve à falta de excelentes livros sobre BPM - em</p><p>fato, há um bom número deles, mas sim devido à interdisciplinaridade e</p><p>natureza de BPM em constante evolução.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 8/192</p><p>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</p><p>Modelagem de fluxo de trabalho . Ambos os livros fornecem estruturas conceituais úteis e</p><p>conselhos práticos e definitivamente devem estar nas estantes (ou melhor, nas mãos)</p><p>de praticantes de BPM. No entanto, é necessário um histórico introdutório e preferir</p><p>anos de experiência habilmente para apreciar verdadeiramente os conselhos dados nestes livros.</p><p>Além disso, esses livros dão pouca atenção aos aspectos de tecnologia, como processos de negócios</p><p>sistemas de gestão e ferramentas de inteligência de processos.</p><p>Do outro lado do espectro, outros livros adotam uma ciência da computação</p><p>específico para BPM, como Van der Aalst e Van Hee's Workflow Management e</p><p>Weske's Business Process Management , ambos focados na modelagem de processos, anal-</p><p>ysis e automação para cientistas da computação. Em um nível mais especializado, pode-se</p><p>encontrar uma variedade de livros com foco na modelagem de processos usando linguagens específicas - para</p><p>exemplo Método e estilo BPMN de Silver .</p><p>Neste contexto, decidimos que era hora de reunir nossos</p><p>experiência de ensino em BPM, a fim de entregar um livro que:</p><p>• Adota o BPM como um campo interdisciplinar, alcançando um equilíbrio entre os negócios</p><p>aspectos de gestão e TI.</p><p>• Abrange todo o ciclo de vida do BPM, desde a identificação de processos até a análise</p><p>lisando, redesenhando, implementando e monitorando esses processos.</p><p>• Segue uma abordagem passo a passo pontuada por vários exemplos, a fim de</p><p>tornar o conteúdo acessível a alunos com pouca ou nenhuma experiência em BPM.</p><p>• Contém vários exercícios testados em sala de aula, tanto dentro de cada capítulo quanto em</p><p>o final dos capítulos, para que os alunos possam testar suas habilidades de forma incremental e</p><p>os instrutores têm material para trabalhos de classe, trabalhos de casa e projetos.</p><p>• Conta com uma linguagem de modelagem de processos madura e padronizada, ou seja, BPMN.</p><p>No espírito de um livro, cada capítulo contém uma série de exames elaborados</p><p>ples e exercícios. Alguns desses exercícios estão espalhados ao longo do capítulo e</p><p>destinam-se a ajudar o leitor a colocar em prática conceitos e tecnologias</p><p>técnicas expostas no capítulo em cenários concretos. Esses exercícios "no capítulo"</p><p>são emparelhados com soluções de amostra no final do capítulo. Além disso, cada capítulo</p><p>Ter termina com uma série de exercícios adicionais para os quais nenhuma solução é fornecida.</p><p>Os instrutores podem desejar usar esses últimos exercícios para as atribuições.</p><p>A maioria dos capítulos também contém "caixas destacadas" que fornecem informações complementares</p><p>visões em um tópico específico. Essas caixas são tangenciais ao fluxo do livro e</p><p>pode ser ignorado por leitores que desejam se concentrar nos conceitos essenciais. Sim-</p><p>Da mesma forma, cada capítulo termina com uma seção de "Leituras Adicionais" que fornece</p><p>dicas para leitores que desejam aprofundar sua compreensão de um tópico específico.</p><p>Para melhor servir aos nossos leitores, criamos um site para coletar mate-</p><p>riais: http://fundamentals-of-bpm.org. Este site inclui slides, registro de palestras</p><p>exames, exames de amostra, links para recursos relacionados e exercícios adicionais.</p><p>Página 9</p><p>Prefácio XI</p><p>O livro foi elaborado para apoiar cursos de uma ampla variedade. Um curso aprofundado</p><p>no BPM poderia cobrir todos os capítulos de uma forma equilibrada. Para ajustar o conteúdo em</p><p>um semestre, porém, pode ser necessário sacrificar um ou dois capítulos. Se este</p><p>foi necessário, nossa sugestão seria pular o capítulo. 4 ou 10 . Um BPM introdutório</p><p>o curso pode pular o Chaps. 2 , 4 , 7 e 10, embora ainda forneça uma imagem consistente</p><p>do campo. Um curso sobre automação de processos para alunos de TI pode pular o Chaps. 2 , 5</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://fundamentals-of-bpm.org</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 9/192</p><p>e 6 . Um curso sobre modelagem de processos se concentraria em Chaps. 2 a 5 , e possivelmente</p><p>Indivíduo. 9 se a intenção é produzir modelos de processos executáveis. Capítulos 3 e 4</p><p>pode ser integrado em um curso semestral mais amplo sobre modelagem de sistemas. Finalmente,</p><p>um curso de melhoria de processos para estudantes de administração pode</p><p>bancários forem</p><p>dado, a transferência é tentada novamente. Se o problema ainda não for resolvido, o Contas a Pagar</p><p>O escritório deve entrar em contato novamente com o fornecedor para rastrear a causa do pagamento devolvido.</p><p>1. Que tipo de processo é o acima: ordem para pagamento, aquisição para pagamento ou emissão para</p><p>resolução?</p><p>2. Quem são os atores neste processo? Quem é / são o (s) cliente (s)?</p><p>3. Que valor o processo oferece ao (s) cliente (s)?</p><p>4. Quais são os resultados possíveis deste processo?</p><p>5. Tomando a perspectiva do cliente, quais medidas de desempenho podem estar em</p><p>anexado a este processo?</p><p>6. Que problemas potenciais você prevê que esse processo possa ter? Que informação</p><p>você precisaria coletar para analisar essas questões?</p><p>7. Quais possíveis mudanças você acha que poderiam ser feitas neste processo para</p><p>resolver os problemas acima?</p><p>Agradecimento Este exercício é adaptado de um exercício semelhante desenvolvido por</p><p>Michael Rosemann, Universidade de Tecnologia de Queensland.</p><p>Exercício 1.8 Considere as fases do ciclo de vida do BPM. Quais dessas fases são</p><p>não incluído em um projeto de reengenharia de processos de negócios?</p><p>Página 53</p><p>1.8 Leitura Adicional 31</p><p>1.8 Leitura Adicional</p><p>Geary Rummler é considerado um dos primeiros defensores do pensamento de processo como um</p><p>abordagem para abordar as deficiências das organizações puramente funcionais. O trabalho dele</p><p>no pensamento de processo, desenvolvido durante os anos 1970 e 1980, foi popularizado por um</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 51/192</p><p>livro em coautoria com Alan Brache: “Improving Performance: How to Manage the</p><p>Espaço em branco no organograma ”[ 80 ]. Um artigo publicado duas décadas depois</p><p>por Rummler e Ramias [ 81 ] dá um resumo condensado da metodologia de Rummler</p><p>ogia para estruturar organizações em torno de processos.</p><p>Dois artigos importantes que popularizaram o pensamento de processo como um conceito de gestão são</p><p>aqueles de Hammer [ 26 ] e Davenport e Short [ 11 ] conforme discutido neste capítulo.</p><p>Enquanto o trabalho de Rummler lida de forma mais ampla com a estruturação de organizações baseadas</p><p>em processos, Hammer, Davenport e Short focam em como redesenhar</p><p>processos de negócios para aumentar seu desempenho.</p><p>Um tratamento abrangente e consolidado de BPM por um homem de negócios</p><p>perspectiva de gestão é fornecida por Paul Harmon em seu livro Business Pro-</p><p>cesso Mudança [ 31 ]. O livro de Harmon apresenta a chamada metodologia BPTrends</p><p>ogy para BPM. Harmon também é editor do boletim informativo e portal BPTrends</p><p>( http://www.bptrends.com ) que apresenta vários artigos e recursos relacionados</p><p>para BPM. Uma boa visão geral do campo também é fornecida nos livros de Becker et al. [ 6 ]</p><p>e por Rosemann e vom Brocke [ 102 , 103 ].</p><p>Conforme mencionado neste capítulo, BPM está relacionado a vários outros campos, incluindo</p><p>TQM e Six Sigma. A esse respeito, Elzinga et al. [ 15 ] discutir a relação entre</p><p>BPM e TQM, enquanto a aplicação de técnicas Six Sigma no contexto de</p><p>BPM é discutido por Harmon [ 31 , Cap. 12], Laguna e Marklund [ 43 , cap. 2]</p><p>e Conger [ 8 ].</p><p>Página 54</p><p>Capítulo 2</p><p>Identificação do Processo</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://www.bptrends.com</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 52/192</p><p>As coisas que mais importam nunca devem estar à mercê</p><p>das coisas que menos importam.</p><p>Johann Wolfgang von Goethe (1749-1832)</p><p>A identificação do processo é um conjunto de atividades com o objetivo de definir sistematicamente o conjunto de</p><p>processos de negócios de uma empresa e estabelecer critérios claros para priorizá-los.</p><p>A saída da identificação do processo é uma arquitetura de processo , que representa o</p><p>processos de negócios e suas inter-relações. Uma arquitetura de processo serve como um quadro</p><p>trabalho para definir as prioridades e o escopo da modelagem e redesenho de processos</p><p>projetos.</p><p>Neste capítulo, apresentamos um método para identificação de processos que se baseia em</p><p>duas fases: designação e avaliação. A fase de designação está relacionada com</p><p>a definição de uma lista inicial de processos. A fase de avaliação considera adequada</p><p>critérios para definir as prioridades desses processos. Depois disso, discutimos e ilustramos</p><p>um método para transformar a saída desse método em uma arquitetura de processo.</p><p>2.1 Focando em processos-chave</p><p>Poucas organizações têm os recursos necessários para modelar todos os seus processos em detalhes,</p><p>para analisar rigorosamente e redesenhar cada um deles, para implantar tecnologia de automação</p><p>a fim de apoiar cada um desses processos e, finalmente, monitorar continuamente</p><p>o desempenho de todos os processos em detalhes. Mesmo se esses recursos estivessem disponíveis,</p><p>não seria econômico gastá-los dessa maneira. O BPM não é gratuito. Como qualquer um</p><p>outro investimento, os investimentos em BPM têm que pagar. Portanto, é imperativo em cada</p><p>organização engajada em BPM para focar a atenção em um subconjunto de processos.</p><p>Alguns processos precisam receber prioridade porque são de importância estratégica</p><p>para a sobrevivência de uma organização. Outros processos podem mostrar problemas marcantes, que</p><p>deve ser resolvido para o bem de todas as partes interessadas envolvidas. Em outras palavras, o</p><p>processos que uma organização deve focar são encontrados em áreas onde há</p><p>grande valor criado ou problemas significativos presentes (ou ambos). Para fazer coisas</p><p>mais complexo, o subconjunto de processos de alta prioridade em uma organização está sujeito a</p><p>a dinâmica do tempo. Alguns processos podem ser problemáticos em um ponto, mas uma vez</p><p>M. Dumas et al., Fundamentals of Business Process Management ,</p><p>DOI 10.1007 / 978-3-642-33143-5_2 , © Springer-Verlag Berlin Heidelberg 2013</p><p>33</p><p>Página 55</p><p>34 2 Identificação do Processo</p><p>os problemas foram identificados e resolvidos por um programa de melhoria de processos,</p><p>uma organização pode fazer apenas inspeções periódicas por algum tempo. Por exemplo,</p><p>uma seguradora que sofre de altos níveis de insatisfação do cliente irá</p><p>naturalmente tendem a se concentrar em seus processos orientados para o cliente, digamos, seu tratamento de reclamações</p><p>processo. Uma vez que este processo tenha melhorado e a satisfação do cliente esteja novamente dentro</p><p>a faixa desejada, a ênfase pode passar para seus processos de avaliação de risco, que</p><p>são importantes para a viabilidade e competitividade da empresa a longo prazo.</p><p>Além da dinâmica do tempo, quais podem ser processos que são de natureza estratégica</p><p>importância para uma organização em algum ponto pode se tornar menos importante com o passar do tempo.</p><p>As demandas do mercado podem mudar e novos regulamentos ou a introdução de novos produtos</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://dx.doi.org/10.1007/978-3-642-33143-5_2</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 53/192</p><p>utos podem limitar o que antes era uma atividade lucrativa de negócios. Por exemplo, a chegada</p><p>de novos concorrentes oferecendo apólices de seguro com desconto por meio de canais baseados na Web</p><p>nels pode levar uma empresa estabelecida a redesenhar seus processos de vendas de seguros para</p><p>torná-los mais enxutos, rápidos e acessíveis na web.</p><p>Para abordar o imperativo de se concentrar em um subconjunto de processos-chave, o homem</p><p>equipe de gestão, analistas de processos e proprietários de processos precisam ter respostas para as</p><p>Seguem duas questões: (i) quais processos são executados na organização? e</p><p>(ii) em quais deve a organização focar? Em outras palavras, uma organização en-</p><p>medido em iniciativas de BPM precisa manter um mapa de seus processos, bem como critérios claros</p><p>para determinar quais processos têm maior prioridade. Vimos no cap. 1 que</p><p>há uma série de partes interessadas envolvidas na gestão e execução de um negócio</p><p>processo de ness.</p><p>Geralmente, apenas alguns desses interessados têm uma visão geral completa de</p><p>todos os processos de negócios em uma organização. No entanto, é precisamente esse insight que é</p><p>necessário para identificar o subconjunto de processos que precisam ser gerenciados de perto</p><p>ou melhorado. Capturar esse conhecimento e mantê-lo atualizado é precisamente o</p><p>objetivo da identificação do processo.</p><p>Mais especificamente, a identificação do processo está preocupada com duas fases sucessivas:</p><p>designação e avaliação. O objetivo da fase de designação é obter uma</p><p>compreensão dos processos em que uma organização está envolvida, bem como suas inter-</p><p>relacionamentos. A fase de avaliação , com base no entendimento que se estabelece</p><p>na fase anterior, pretende desenvolver uma priorização entre estes para o processo</p><p>atividades de gestão (modelagem, redesenho, automação, monitoramento, etc.). Observe que</p><p>nenhuma dessas fases está preocupada com o desenvolvimento do modo de processo detalhado</p><p>els. As principais atividades que estão envolvidas na identificação do processo que iremos</p><p>descrever seguir de perto aqueles identificados por Davenport em [ 10 ].</p><p>2.1.1 A Fase de Designação</p><p>Se uma organização está no início de se tornar uma organização centrada em processos,</p><p>a primeira tarefa difícil que enfrenta é chegar a uma enumeração significativa de seus</p><p>processos existentes. Uma dificuldade aqui surge da natureza hierárquica dos negócios</p><p>processos de ness: diferentes critérios podem ser considerados para determinar quais cadeias de</p><p>operações podem ser vistas como formando um processo de negócios independente e quais</p><p>Página 56</p><p>2.1 Focando em processos-chave 35</p><p>são vistos como parte de outro processo. Existem vários pontos de vista sobre como categorizar</p><p>rize processos de negócio (veja o quadro “Categorias de processos de acordo com Porter”).</p><p>Alguns deles apoiam a ideia de que existem realmente poucos processos em qualquer</p><p>organização. Por exemplo, alguns pesquisadores argumentaram para a existência de apenas</p><p>dois processos: (1) gerenciamento da linha de produtos e (2) gerenciamento do ciclo de pedidos.</p><p>Outros identificam três processos principais: desenvolvimento de novos produtos, entrega de produtos</p><p>serviços aos clientes e gerenciamento de relacionamento com os clientes.</p><p>CATEGORIAS DE PROCESSOS DE ACORDO COM PORTER</p><p>Diferentes categorizações para processos de negócios foram propostas. 1</p><p>dos mais influentes é o modelo da Cadeia de Valor de Michael Porter. É distin-</p><p>admite duas categorias de processos: processos centrais (chamados de atividades primárias)</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 54/192</p><p>e processos de suporte (atividades de suporte). Os processos centrais cobrem a essência</p><p>criação de valor social de uma empresa, ou seja, a produção de bens e serviços</p><p>vícios pelos quais os clientes pagam. Porter menciona logística de entrada, operações,</p><p>logística de saída, marketing e vendas e serviços. Processos de suporte en-</p><p>capaz de executar esses processos centrais. Porter lista infraestrutura, humana</p><p>recursos, desenvolvimento de tecnologia e aquisições como tal</p><p>cesses. Como uma terceira categoria, outros autores estendem este conjunto de duas categorias</p><p>com processos de gestão. Por exemplo, o processo periódico para avaliar o</p><p>A força dos concorrentes é esse processo de gerenciamento. A distinção do núcleo,</p><p>processos de suporte e gestão é de importância estratégica para uma empresa.</p><p>Portanto, se tal distinção for explicitada, por exemplo, na fase do processo</p><p>identificação ou ao criar uma arquitetura de processo, é provável que seja um</p><p>tópico muito disputado.</p><p>A questão é se uma visão excessivamente granulada dos processos, sem</p><p>qualquer subdivisão posterior , é útil para uma organização que se esforça para se tornar</p><p>centrado. Lembre-se de que a ideia de gerenciamento de processos é gerenciar ativamente</p><p>processos de negócios na busca da satisfação de seus clientes específicos. Se alguém selecionar</p><p>processos de negócios sejam entidades tão grandes, então o resultado pode ser que eles não podem</p><p>ser facilmente gerenciados separadamente, tanto em termos de escopo quanto de velocidade de ação. Considerar,</p><p>por exemplo, o quão difícil seria modelar ou redesenhar um processo quando ele cobre</p><p>metade de todas as operações dentro de uma organização. Um modelo realista de tal negócio</p><p>processo de ness levaria muito tempo para se desenvolver e poderia se tornar extremamente</p><p>complexo. Além disso, redesenhar um processo tão grande seria uma tarefa demorada</p><p>justo, quanto mais a implementação de tal redesenho. Dependendo da situação, um</p><p>organização pode não ter esse tempo.</p><p>A principal conclusão disso é que o número de processos que são identificados</p><p>na fase de designação deve representar uma compensação entre impacto e gestão</p><p>habilidade . Quanto menor for o número de processos que se deseja identificar, maior</p><p>seu escopo individual é. Em outras palavras, se apenas um pequeno número de processos é</p><p>identificados, então cada um deles cobrirá inúmeras operações. A principal vantagem</p><p>Página 57</p><p>36 2 Identificação do Processo</p><p>de um grande escopo de processo é que potencialmente aumenta o impacto que se pode ter com</p><p>gerenciando ativamente tal processo. Quanto mais operações são consideradas parte de</p><p>um processo, mais fácil se tornará, por exemplo, identificar oportunidades de eficiência</p><p>ganhos eliminando o trabalho redundante.</p><p>Por outro lado, um grande escopo de um processo de negócios traz consigo uma gama de</p><p>questões que tornam mais difícil gerenciá- lo como um processo:</p><p>• o envolvimento de um grande número de funcionários tornará a comunicação eficaz</p><p>entre eles problemáticos</p><p>• se tornará mais difícil manter os modelos de um grande processo atualizados e</p><p>• projetos de melhoria relacionados a um grande processo são mais complexos</p><p>Para equilibrar as vantagens e desvantagens de um amplo escopo de processo, Davenport</p><p>sugeriu que pode ser útil identificar processos amplos e restritos .</p><p>Processos amplos são identificados nas áreas onde uma organização sente que é im-</p><p>importante para revisar completamente as operações existentes em algum ponto, por exemplo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 55/192</p><p>por causa de forças competitivas ferozes. Imagine que uma organização possa ter encontrado</p><p>que seus custos de aquisição são excessivamente altos em comparação com seus concorrentes. Eles selecionam</p><p>aquisição como um processo amplo, que abrange todos os serviços e produtos a</p><p>empresa adquire de outras partes. Por outro lado, processos estreitos não são direcionados</p><p>para grandes revisões; eles precisam ser ativamente monitorados e estão sujeitos a con</p><p>ajuste fino e atualização contínua. Um processo estreito pode ser, por exemplo, como o</p><p>mesma empresa trata de sugestões de melhorias de seus próprios funcionários.</p><p>Exercício 2.1 Explique como funciona a compensação entre impacto e capacidade de gerenciamento</p><p>fora para processos amplos e estreitos, respectivamente.</p><p>Qualquer enumeração de processos de negócios deve se esforçar para uma descrição razoavelmente detalhada</p><p>resultado, que precisa estar alinhado com os objetivos específicos da organização de</p><p>gestão de processos. Para a maioria das organizações, como regra prática, isso se resumirá</p><p>a uma dúzia a algumas dezenas de processos de negócios. Muito grande e diversificado</p><p>as organizações podem se sair melhor com a identificação de algumas centenas de processos.</p><p>Para ilustrar isso: dentro de uma empresa de investimento multinacional, que emprega perto de</p><p>3.000 funcionários e possui ativos na faixa de € 300 bilhões, 120 negócios diferentes</p><p>processos foram identificados. Para cada um desses processos de negócios, um proprietário de processo</p><p>é designado, quem supervisiona o desempenho do processo e monitora o alcance</p><p>de seus objetivos em termos de satisfação do cliente, lucratividade e prestação de contas</p><p>habilidade. Modelos de processos detalhados são mantidos</p><p>atualizados, tanto como um meio de documentação</p><p>ing mudanças planejadas para qualquer processo e para satisfazer os requisitos de finanças</p><p>autoridades. Em contraste, para uma pequena clínica médica na Holanda, que em-</p><p>estratagemas médicos especialistas, enfermeiras e equipe administrativa, 10 tratamentos diferentes</p><p>processos foram identificados. Alguns deles foram mapeados na forma de</p><p>modelos de processo e agora estão em processo de automatização com um</p><p>sistema de gerenciamento de processos. Para todos os outros processos, é suficiente estar ciente do</p><p>opções de tratamento distintas que podem oferecer a diferentes categorias de pacientes.</p><p>Página 58</p><p>2.1 Focando em processos-chave 37</p><p>Exercício 2.2 Quais são os impulsionadores potenciais para a empresa de investimento descrita para</p><p>identificar um grande número de processos?</p><p>Além de uma visão bastante detalhada sobre quais processos de negócios existem, um sub</p><p>posição deve ser desenvolvida sobre as relações entre os vários processos. No</p><p>uma situação em que as organizações definem processos estreitos e amplos, para evitar</p><p>confusão, é importante mapear como processos estreitos se relacionam com processos mais amplos.</p><p>Um amplo processo como gerenciamento de pedidos, por exemplo, pode estar relacionado a mais</p><p>processos estritamente definidos de reserva, cobrança, remessa e entrega de pedidos. Tudo de</p><p>estes podem ser considerados subprocessos do gerenciamento de pedidos. Podemos chamar isso de ex-</p><p>ampla de relações hierárquicas entre processos. Os processos também podem estar relacionados a</p><p>um ao outro de forma diferente. O faturamento, no exemplo que acabamos de usar, é um processo upstream</p><p>em comparação com o envio: para o mesmo pedido, a fatura é enviada geralmente antes do</p><p>mercadorias derivadas são enviadas. Outra forma de expressar essa relação é, claro, que</p><p>o envio pode ser considerado um processo posterior em comparação ao faturamento. este</p><p>ilustra como os processos podem ser relacionados sequencialmente .</p><p>Exercício 2.3 Discuta até que ponto o gerenciamento de pedidos pode estar relacionado sequencialmente</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 56/192</p><p>para reserva, cobrança, remessa e entrega.</p><p>Na maioria das vezes, o insight sobre as relações entre os processos pode ser inferior a</p><p>estritamente exato. O objetivo mais importante de capturar relações de dependência é ganhar</p><p>uma compreensão de como o desempenho de um processo está relacionado ao de outro. E se</p><p>seria, por exemplo, redesenhar um processo existente, é útil entender qual</p><p>processos dependem dos resultados de tal processo. Esses processos downstream</p><p>pode precisar estar preparado para receber informações ou mercadorias em outra frequência ou</p><p>forma do que antes e medidas devem ser tomadas para evitar quaisquer interrupções.</p><p>Exercício 2.4 Neste ponto, discutimos as relações hierárquicas e sequenciais entre</p><p>entre os processos de negócios. Você pode pensar em outros tipos de relação que são úteis para</p><p>distinguir entre processos? Como uma dica, você pode querer pensar sobre o propósito</p><p>de identificar as relações entre os processos de negócios.</p><p>Embora a designação de processos de negócios e suas inter-relações seja sub-</p><p>jeto a diferentes escolhas e preferências de design, algumas orientações gerais estão disponíveis.</p><p>Em primeiro lugar, vários chamados modelos de referência para identificação de processos de negócios</p><p>existir. Estes são desenvolvidos por uma série de consórcios da indústria, associações sem fins lucrativos,</p><p>programas de pesquisa governamentais e acadêmicos. Os exemplos mais conhecidos são os In-</p><p>formação Biblioteca de Infraestrutura de Tecnologia (ITIL), as Operações da Cadeia de Suprimentos</p><p>Modelo de Referência (SCOR) pelo Conselho da Cadeia de Suprimentos, a Classificação de Processo</p><p>Framework (PCF) pelo American Productivity and Quality Center (APQC), o</p><p>Modelo de Referência de Valor (VRM) pelo Grupo da Cadeia de Valor, e o Desempenho</p><p>Framework de Rummler – Brache. Os modelos de referência padronizam o que pode ser visto como</p><p>processos diferentes, com características únicas e entregando produtos diferenciados</p><p>utos e como seu desempenho pode ser medido. Seu maior valor está na identidade</p><p>identificação de processos regulatórios ou altamente específicos da indústria, ou quando o desempenho</p><p>Página 59</p><p>38 2 Identificação do Processo</p><p>benchmarking contra pares e concorrentes é a questão que um processo centrado</p><p>organização está atrás. Em outros casos, esses modelos de referência ainda podem ser úteis em</p><p>exercícios de identificação em forma de lista de verificação. Por exemplo, uma organização pode</p><p>usar o PCF do APQC para inventariar os processos na estrutura que eles usam, sinalizar</p><p>aqueles que eles não usam e adicionar seus próprios processos exclusivos. Vamos dar uma olhada mais de perto</p><p>no PCF na Sect. 2.2 .</p><p>Um segundo fluxo de suporte está disponível na forma de abordagens de design específicas</p><p>para desenvolver uma chamada arquitetura de processo . Uma arquitetura de processo é uma organização</p><p>visão geral dos processos que existem dentro de um contexto organizacional, que muitas vezes é</p><p>acompanhados de orientações sobre como devem ser organizados. Abordagens de design</p><p>para arquiteturas de processos de negócios usam uma certa lógica para chegar a uma identificação de</p><p>processos de negócios. Na seção 2.2 , entraremos em mais detalhes com relação a um</p><p>abordagem de design.</p><p>Por fim, o que vale a pena notar com relação à fase de designação é que</p><p>os processos mudam com o tempo, deliberadamente ou não. Isso naturalmente implica que o processo</p><p>a identificação é de natureza contínua. Para evitar a situação em que alguém se torna</p><p>atolado na fase de identificação do processo, a atividade deve ser considerada</p><p>ered como um esforço exploratório e iterativo. Quando uma certa visão geral estável é</p><p>criado pode muito bem ser utilizável por um período de dois a três anos.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 57/192</p><p>2.1.2 A fase de avaliação</p><p>Como afirmado antes, nem todos os processos são igualmente importantes e nem todos os processos podem</p><p>recebem a mesma quantidade de atenção. A gestão de processos envolve compromisso,</p><p>propriedade, investimento em melhoria de desempenho e otimização. Portanto,</p><p>processos que criam perda ou demanda de risco para consolidação, descomissionamento ou</p><p>eliminação total. Vários critérios foram propostos para orientar essa avaliação.</p><p>Os mais comumente usados são os seguintes.</p><p>Importância Este critério se preocupa em avaliar a relevância estratégica de</p><p>cada processo. O objetivo é descobrir quais processos têm maior impacto sobre</p><p>os objetivos estratégicos da empresa, por exemplo, considerando lucratividade, continuidade,</p><p>ou contribuição para uma causa pública. Faz sentido selecionar esses processos para</p><p>gestão de processos ativos que se relacionam mais diretamente com os objetivos estratégicos de um</p><p>organização.</p><p>Disfunção Este critério visa fazer um julgamento de alto nível da "saúde"</p><p>de cada processo. A questão aqui é determinar quais processos estão no</p><p>problema mais profundo. Esses processos são os que podem lucrar mais com o processo</p><p>iniciativas centradas.</p><p>Viabilidade Para cada processo, deve-se determinar o quão suscetíveis eles são a</p><p>iniciativas de gestão de processos, sejam incidentais ou contínuas. A maioria</p><p>notavelmente, a cultura e a política envolvidas em um determinado processo podem ser obstáculos</p><p>para obter resultados de tais iniciativas. Em geral, a gestão de processos deve</p><p>concentre-se nos processos em que é razoável esperar benefícios.</p><p>Página 60</p><p>2.1 Focando em processos-chave 39</p><p>Observe que todos esses critérios pressupõem que haja certas informações disponíveis.</p><p>Por exemplo, para avaliar a importância estratégica de um processo, é da maior importância</p><p>importância que uma organização tenha uma ideia de seu curso estratégico. É suficiente se</p><p>tais considerações estratégicas são definidas em um nível</p><p>muito abstrato. Neste ponto, para</p><p>exemplo, muitas organizações veem o benefício estratégico de ser capaz de mudar o</p><p>tipo de produtos que fornece às demandas dos clientes. Zara, o pano espanhol</p><p>varejista, é um excelente exemplo de uma organização que segue um método de medir e reagir</p><p>estratégia. Ele envia agentes para shoppings para ver o que as pessoas já usam para</p><p>determinar os estilos, tecidos e cores dos produtos que deseja entregar. Tal um</p><p>organização pode olhar com interesse específico para os negócios de produção e logística</p><p>processos que são mais capazes de apoiar esta estratégia.</p><p>Da mesma forma, para determinar a disfunção potencial de um processo de negócios, uma organização</p><p>nização precisa de informações. Aqui, encontramos um problema do tipo “ovo e galinha”.</p><p>Muitas organizações que não trabalham de forma centrada no processo não têm um</p><p>uma boa visão quantitativa do desempenho de seus processos individuais. 1</p><p>das iniciativas centradas no processo que tal organização pode buscar</p><p>exatamente colocar os sistemas e procedimentos em vigor para coletar os dados que são</p><p>necessários para uma avaliação de desempenho. Nesses casos, uma organização precisará</p><p>usar abordagens mais qualitativas para determinar quais de seus processos não funcionam</p><p>formar bem, por exemplo, dependendo das impressões que a gestão ou processo</p><p>participantes têm sobre a eficiência ou eficácia dos vários processos. A-</p><p>outra abordagem seria confiar nas avaliações do cliente, coletadas por pesquisas</p><p>ou entregue espontaneamente na forma de reclamações.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 58/192</p><p>O critério de viabilidade também requer alguma atenção. Tornou-se comum</p><p>prática para as organizações passarem por um fluxo contínuo de programas para melhorar</p><p>seu desempenho em uma dimensão ou outra. Considere a Philips, a multinacional</p><p>empresa de eletrônicos. Ele passou por uma série intermitente de programas de melhoria</p><p>gramas desde os anos 1980 para aumentar seu desempenho. O mesmo fenômeno agora pode</p><p>ser observada em muitas organizações de telecomunicações e serviços públicos. Desde o</p><p>a rentabilidade dos produtos muda drasticamente de um ano para o outro, isso requer</p><p>mudanças contínuas em portfólios de produtos e prioridades de mercado. Nestes tipos de</p><p>contexto volátil, pode acontecer que gerentes e participantes do processo fiquem cansados</p><p>ou totalmente hostil a novas iniciativas. Este tipo de situação não é uma boa</p><p>ponto de partida para iniciativas de gerenciamento de processos. Afinal, como outras organizações</p><p>medidas, tais iniciativas também dependem da cooperação e boas intenções de</p><p>diretamente envolvidos. Embora não tratemos do assunto de gerenciamento de mudanças</p><p>em muitos detalhes neste livro, é importante perceber que o sentido político</p><p>sitividades dentro de uma organização podem ter um efeito na taxa de sucesso do processo</p><p>esforços de gestão também.</p><p>AVALIAÇÃO DA MATURIDADE BPM</p><p>Uma abordagem mais detalhada para olhar para a fase de avaliação é baseada em matu-</p><p>ridade. A avaliação de maturidade de BPM é um corpo de técnicas para determinar o nível</p><p>Página 61</p><p>40 2 Identificação do Processo</p><p>de pensamento sistemático de processo em uma organização. Uma avaliação de maturidade de BPM</p><p>mento envolve essencialmente dois aspectos. O primeiro aspecto é avaliar o que</p><p>até que ponto uma determinada organização cobre a gama de processos que são idealmente ex-</p><p>protegido por isso. O segundo aspecto é avaliar em que grau esses processos</p><p>são documentados e suportados. Portanto, uma avaliação de maturidade visa</p><p>estabelecer uma linha de base para discutir a integridade e a qualidade do</p><p>conjunto de processos executados em uma organização.</p><p>Uma das estruturas mais amplamente utilizadas para avaliação da maturidade é o Ca-</p><p>Estrutura integrada do modelo de maturidade (CMMI). Esta estrutura dis-</p><p>distingue várias das chamadas áreas de processo. Várias dessas áreas são específicas</p><p>específico para um domínio particular nas várias especificações CMMI. O domínio-</p><p>as áreas independentes incluem: gestão de processos, gestão de projetos e</p><p>Apoio, suporte.</p><p>A cobertura das áreas de processo e o grau de seu suporte fornecem o</p><p>base para uma avaliação de maturidade em termos dos cinco níveis de maturidade do CMMI:</p><p>Nível 1 (inicial): nesta fase inicial, a organização executa seus processos em</p><p>uma forma ad-hoc, sem qualquer definição clara desses processos. Ao controle</p><p>está desaparecido.</p><p>Nível 2 (gerenciado): nesta fase, o planejamento do projeto junto com o projeto mon-</p><p>itoring e controle foram colocados em prática. Medição e análise</p><p>é estabelecida, bem como a garantia de qualidade do processo e do produto.</p><p>Nível 3 (Definido): Organizações nesta fase adotaram um foco em</p><p>cesses. Definições de processos estão disponíveis e o treinamento organizacional é pro</p><p>oferecido para permitir que as partes interessadas em toda a organização se envolvam em</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 59/192</p><p>documentação e análise de processos. Projeto integrado e gerenciamento de risco</p><p>Estão no lugar. A análise e resolução de decisões também estão disponíveis.</p><p>Nível 4 (Gerenciado Quantitativamente): Nesta fase, o processo organizacional</p><p>o desempenho é monitorado. A gestão do projeto é realizada usando quanti-</p><p>técnicas representativas.</p><p>Nível 5 (Otimizando): Neste estágio de maturidade, a organização estabeleceu</p><p>cumpriu a gestão de desempenho organizacional acompanhada de</p><p>análise e resolução.</p><p>A avaliação de uma organização em termos desses níveis leva a um chamado</p><p>avaliação . As avaliações podem ser realizadas internamente dentro de uma organização (também</p><p>chamadas de autoavaliação) ou por uma organização externa com experiência em matu-</p><p>avaliação da ridade. Diferentes tipos de avaliação são distinguidos e definidos em</p><p>o Método de Avaliação CMMI Padrão para Melhoria de Processos (SCAMPI).</p><p>Pergunta Dados todos os critérios discutidos, faz uma avaliação da importância,</p><p>disfuncional e viabilidade sempre me apontam os mesmos processos para ativamente</p><p>gerir?</p><p>Página 62</p><p>2.1 Focando em processos-chave 41</p><p>Não, não há garantia disso. Pode muito bem ser que uma importância estratégica</p><p>processo tant também é o processo que pode ser considerado o mais difícil de</p><p>gerenciar, simplesmente porque muitos esforços de melhoria anteriores já falharam.</p><p>Uma organização pode não ter escolha em tal situação. Se um processo estratégico pode-</p><p>não ser melhorado, isso pode acabar sendo fatal para a organização como um todo. Pensar</p><p>de uma situação em que o processo de criação de novos produtos cria muita turbulência</p><p>e conflitos dentro de uma organização: Se os problemas não puderem ser resolvidos, a empresa</p><p>pode parar de funcionar rapidamente. Em outras configurações, pode ser mais importante ganhar</p><p>credibilidade com as atividades de gerenciamento de processos primeiro. Isso pode ser feito por</p><p>focando em processos problemáticos de importância estratégica mais branda, mas onde</p><p>é um grande desejo de mudar. Se for bem-sucedido, um projeto de melhoria em tal lugar</p><p>pode dar credibilidade à abordagem de gerenciamento de processos. Estas não são escolhas</p><p>que pode ser facilmente prescrito sem levar em consideração o contexto específico. o</p><p>vários resultados da avaliação devem ser equilibrados para chegar a uma lista desses processos</p><p>que deve receber prioridade sobre os outros.</p><p>Pergunta Todos os processos disfuncionais, de importância estratégica e</p><p>viável de gerenciar estar sujeito a iniciativas de gerenciamento de processos?</p><p>A resposta geral a esta pergunta é que para a maioria das organizações isso não é viável.</p><p>ble. Lembre-se novamente de que o gerenciamento de processos consome recursos. Mesmo quando há</p><p>um incentivo claro para, por exemplo, redesenhar vários processos de negócios existentes, a maioria</p><p>as organizações não têm recursos suficientes - pessoas, fundos e tempo - para fazer isso. Apenas o</p><p>as maiores organizações são capazes de apoiar mais do que</p><p>um punhado de melhorias de processo -</p><p>projetos de desenvolvimento ao mesmo tempo. Um bom exemplo é a IBM, uma organização conhecida</p><p>ter projetos de melhoria de processos em andamento dentro de todos os seus programas de negócios existentes</p><p>cesses em uma base contínua. Outra ressalva de realizar muitas</p><p>esforços de gerenciamento de processos é que eles criarão complexidade de coordenação. Ré-</p><p>membro que os processos podem estar ligados uns aos outros em vários aspectos, de modo que</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 60/192</p><p>as medidas tomadas para um processo devem ser sincronizadas com as tomadas para outro.</p><p>Como Davenport [ 10 ] descreve:</p><p>A maioria das empresas opta por abordar um pequeno conjunto de processos de negócios a fim de ganhar experiência</p><p>riência com iniciativas de inovação, e eles concentram seus recursos nas atividades mais críticas</p><p>cesses. Cada iniciativa de sucesso se torna um modelo para esforços futuros.</p><p>O que está acontecendo em algumas organizações é que esforços generalizados são feitos</p><p>para, pelo menos, modelar todos os processos de negócios importantes, atrasando a decisão de tomar</p><p>a etapa para esforços de BPM mais avançados (por exemplo, redesenho ou automação de processos). o</p><p>ideia é que os modelos de processo são a base de qualquer esforço de BPM em qualquer</p><p>caso e que sua existência ajudará a entender melhor onde as melhorias</p><p>pode ser ganho. A criação de um modelo de processo leva a uma visão valiosa de como</p><p>processo funciona em tudo e pode fornecer uma boa base para pequenas melhorias que podem</p><p>ser facilmente implementado. No lado negativo, tal abordagem carrega o risco de que</p><p>melhorias são perdidas e as partes interessadas desenvolvem um sentimento de falta de retorno</p><p>pelos esforços. Deve ser enfatizado aqui, também, que a modelagem real de negócios</p><p>processos não é um elemento do estágio de identificação do processo.</p><p>Página 63</p><p>42 2 Identificação do Processo</p><p>Fig. 2.1 Os diferentes níveis</p><p>de detalhes em um processo</p><p>arquitetura</p><p>Nesta seção, descrevemos as fases de designação e avaliação do processo</p><p>em um alto nível de discurso. Agora, vamos nos voltar para uma técnica específica para sugerir</p><p>com uma arquitetura de design de processo.</p><p>2.2 Projetando uma Arquitetura de Processo</p><p>Uma arquitetura de processo é um modelo conceitual que mostra os processos de uma empresa</p><p>e torna seus relacionamentos explícitos. Normalmente, esses relacionamentos são definidos em</p><p>duas direções. Por um lado, os processos podem estar em uma relação consumidor-produtor</p><p>navio. Isso significa que um processo fornece uma saída que o outro processo toma como</p><p>uma entrada. Na primeira parte do livro, distinguimos o processo de cotação para pedido</p><p>e processos de pedido para pagamento. A saída do primeiro (o pedido) é a entrada para o</p><p>o segundo. Observe que este é o mesmo tipo de ordem que o upstream-downstream</p><p>relação que distinguimos anteriormente. Além da relação consumidor-produtor, uma</p><p>A arquitetura de processamento define diferentes níveis de detalhe. Isso é ilustrado como uma pirâmide em</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 61/192</p><p>Fig. 2.1 .</p><p>A parte da arquitetura do processo que cobre os processos no nível um é</p><p>conhecido como modelo de paisagem de processo ou simplesmente a arquitetura de processo para nível</p><p>1. Mostra os principais processos em um nível muito abstrato. Cada um dos elementos de</p><p>o modelo da paisagem do processo aponta para processos de negócios mais concretos no nível</p><p>dois. Este nível dois mostra os processos em um grau mais fino de granularidade, mas ainda em um</p><p>forma bastante abstrata. Cada elemento no nível dois aponta mais para um modelo de processo em</p><p>nível três. Os modelos de processo neste terceiro nível mostram os detalhes dos processos</p><p>incluindo fluxo de controle, entradas e saídas de dados e atribuição de participantes, como</p><p>discutiremos nos capítulos de modelagem.</p><p>O desafio mais importante para a definição de uma arquitetura de processo é o</p><p>definição do modelo de paisagem de processos, ou seja, capturar os processos no nível um.</p><p>A arquitetura do processo no nível um deve ser compreensível em primeiro lugar,</p><p>mostrando não muito mais do que aproximadamente 20 categorias de processos de negócios de</p><p>Página 64</p><p>2.2 Projetando uma Arquitetura de Processo 43</p><p>uma empresa. Além disso, deve ser suficientemente completo para que todos os funcionários</p><p>da empresa pode se relacionar com ele com seu trabalho diário, e aceitá-lo como um consensual</p><p>descrição da empresa. Portanto, é importante definir o arquivo do processo</p><p>tectura de forma sistemática, com foco específico na derivação do processo</p><p>modelo de paisagem.</p><p>Várias perspectivas e abordagens foram definidas para a arquitetura de processos</p><p>definição. Aqui, nos concentraremos em uma abordagem desenvolvida por Dijkman [ 14 ].</p><p>Esta abordagem específica leva a uma arquitetura de processo no nível um ao longo de dois di-</p><p>mensões: tipo de caso e função do negócio. A dimensão do tipo de caso classifica o</p><p>tipos de casos que são tratados por uma organização. Um caso é algo que um ou-</p><p>ganização (ou parte dela) alças. Normalmente, um caso é um produto ou serviço que é</p><p>entregue por uma organização a seus clientes, como um seguro (um serviço) ou um</p><p>brinquedo (um produto). Observe que, dependendo da parte da organização para a qual o</p><p>arquitetura de processo é projetada, os casos podem representar produtos ou serviços que</p><p>são entregues aos clientes da organização. No entanto, eles também podem se referir a</p><p>produtos ou serviços que são fornecidos por um departamento da organização a um</p><p>outro departamento. Por exemplo, pense em criar um local de trabalho para um novo funcionário</p><p>pelo departamento de instalações.</p><p>Os casos podem ser classificados deliberadamente, usando qualquer número de propriedades. Para a prova-</p><p>ple, uma seguradora lida com seguros, que podem ser classificados de acordo com</p><p>tipo de produto (seguro residencial, seguro automóvel e seguro de vida), mas também de acordo</p><p>ao canal que a empresa utiliza para interagir com seus clientes (telefone, of-</p><p>fice e internet). Uma combinação dessas propriedades também pode ser usada para classificar</p><p>casos. No exemplo do seguro, os casos seriam então classificados usando ambos os produtos</p><p>tipo e canal (seguro residencial via telefone, seguro residencial via escritório, carro</p><p>seguro por telefone, etc.).</p><p>A dimensão função classifica as funções de uma organização. Uma função é,</p><p>em poucas palavras, algo que uma organização faz. Normalmente, uma decomposição hierárquica</p><p>posição das funções pode ser feita: Uma função consiste em subfunções, que, em</p><p>por sua vez, consistem em sub-subfunções, etc. Por exemplo, uma empresa de produção realiza</p><p>funções de compra, produção e vendas. A função de compras, por sua vez, pode</p><p>ser decomposto em funções de seleção de fornecedor e aquisição operacional. FIG-</p><p>ure 2.2 mostra um exemplo de uma arquitetura de processo de negócios para uma autoridade portuária,</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 62/192</p><p>que usa o tipo de caso e as dimensões da função para estruturar seus processos.A figura mostra uma organização de processos por tipo de caso na di-</p><p>mension e por função de negócio na dimensão vertical. A dimensão da função</p><p>mostra o que a organização faz: manuseio pré-chegada de navios de mar, o que envolve</p><p>notificando as partes relevantes sobre o tempo estimado de chegada do navio e o que</p><p>o navio está carregando; lidar com a chegada real do navio, que envolve guiar</p><p>o navio para sua doca; etc. A dimensão do tipo de caso mostra os tipos de casos que o</p><p>organização trata: navios, caminhões, trens e transporte terrestre por barcaças.</p><p>Existem três processos que são criados para lidar com esses tipos de casos, usando o</p><p>funções diferentes. Esses três são mostrados cobrindo as várias funções e casos</p><p>tipos. O processo de planejamento de entrada</p><p>é usado para lidar com a chegada de navios antes da chegada.</p><p>O processo de manuseio de entrada é usado para lidar com a chegada e o transbordo do mar</p><p>Página 65</p><p>44 2 Identificação do Processo</p><p>Fig. 2.2 Uma arquitetura de processo para uma autoridade portuária</p><p>navios e o processo de manuseio de saída é usado para lidar com o transbordo e</p><p>partida de caminhões, trens e barcaças.</p><p>Para chegar a uma arquitetura de processo de negócios em um sentido semelhante ao que descrevemos</p><p>aqui, propomos uma abordagem que consiste nas quatro etapas a seguir:</p><p>1. identificar os tipos de caso</p><p>2. identificar funções para tipos de caso</p><p>3. construir uma ou mais matrizes de caso / função, e</p><p>4. identificar processos</p><p>Discutiremos agora essas etapas com mais detalhes.</p><p>2.2.1 Identificar Tipos de Casos</p><p>Na primeira etapa, uma classificação de tipos de caso é desenvolvida para a organização. este</p><p>é feito selecionando as propriedades do caso que serão usadas para a classificação. o</p><p>objetivo principal para identificar diferentes classes nesta dimensão do processo de arquivamento</p><p>tectura é determinar as diferentes maneiras em que processos (semelhantes) são tratados</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 63/192</p><p>na organização. É importante ter isso em mente, pois as únicas propriedades</p><p>que devem ser incluídos na classificação são aqueles que conduzem a diferentes organizações</p><p>comportamento zacional. Propriedades que podem distinguir casos, mas não levam a diferentes</p><p>comportamento não deve ser incluído. Por exemplo, uma papelaria vende muitos tipos diferentes</p><p>tipos de produto. Porém, vende todos esses tipos de produtos da mesma forma.</p><p>Portanto, 'tipo de produto' não é uma dimensão útil ao classificar os casos que</p><p>são administrados por uma loja de varejo. Uma seguradora também vende diferentes tipos de</p><p>produto (seguros) e, ao contrário da loja de varejo, os produtos que ela vende são</p><p>tratada de forma diferente. Por exemplo, para um seguro de vida, uma declaração de saúde deve ser</p><p>Página 66</p><p>2.2 Projetando uma Arquitetura de Processo 45</p><p>preenchido, mas para um seguro de carro isso não é um requisito. Portanto, o 'produto</p><p>tipo 'é de fato uma propriedade útil para classificar os tipos de casos que são tratados por</p><p>uma seguradora; este não é o caso para classificar os tipos de casos que são</p><p>manuseado por uma loja de varejo.</p><p>Uma classificação dos tipos de casos que uma organização lida pode ser desenvolvida</p><p>oped usando qualquer número de propriedades. No entanto, alguns dos mais comumente usados</p><p>propriedades são:</p><p>• Tipo de produto: esta propriedade identifica os tipos de produtos que são manipulados por</p><p>Uma organização. Eles podem ser decompostos hierarquicamente. Por exemplo, um seguro</p><p>uma empresa de negócios lida com produtos de seguro de vida e danos. Na classe de dam-</p><p>seguros de idade, uma decomposição adicional é possível em seguro de carro e casa</p><p>seguro; da mesma forma, dentro da classe de seguro de vida, uma decomposição adicional é</p><p>possível em seguro saúde e seguro de acidentes.</p><p>• Tipo de serviço: se (uma parte de) uma organização lida com serviços em vez de produtos,</p><p>esta propriedade identifica os tipos de serviços que a organização lida, semelhantes</p><p>à maneira como o tipo de produto identifica os tipos de resultados tangíveis.</p><p>• Canal: esta propriedade representa o canal através do qual a organização</p><p>tata seus clientes. Podemos, por exemplo, distinguir: contato face a face (sobre</p><p>balcão), telefone ou contato pela Internet.</p><p>• Tipo de cliente: esta propriedade representa os tipos de cliente que a organização</p><p>zação trata. Uma companhia aérea, por exemplo, pode distinguir passageiros frequentes de</p><p>viajantes regulares.</p><p>Observe novamente que, embora essas sejam as propriedades mais comumente usadas para dis-</p><p>Para distinguir diferentes tipos de caso, certamente existem outras propriedades que podem ser usadas.</p><p>Qualquer propriedade que distingue tipos de casos que são tratados de forma diferente pode ser</p><p>usava. Por exemplo, se uma organização faz as coisas de forma diferente na América do Norte do que</p><p>na Europa, os casos podem ser classificados de acordo com a localização. Outro exemplo: if cases</p><p>são tratados de forma diferente, dependendo da experiência necessária para lidar com eles,</p><p>eles podem ser classificados de acordo com a especialização.</p><p>Além disso, observe novamente que a classificação pode ser desenvolvida usando qualquer número e</p><p>combinação de propriedades. Se uma empresa vende seguros na América do Norte</p><p>e na Europa e o tratamento de seguros difere nesses continentes por causa da</p><p>regulamentos, em seguida, uma classificação de casos de acordo com o tipo de produto e localização</p><p>pode ser usado.</p><p>Exercício 2.5 Considere o caso de um banco e os critérios de classificação do tipo de produto,</p><p>tipo de serviço, canal e tipo de cliente. Até que ponto esses critérios estão relacionados a cada</p><p>de outros?</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 64/192</p><p>2.2.2 Identificar funções para tipos de caso</p><p>Na segunda etapa, é desenvolvida uma classificação das funções de negócios que são</p><p>realizada nos diferentes tipos de caso. Esta etapa requer que cada um dos tipos de caso</p><p>Página 67</p><p>46 2 Identificação do Processo</p><p>é examinado em detalhes e para cada tipo de caso as funções que podem ser executadas nele</p><p>são identificados. Potencialmente, as funções que são desempenhadas em uma organização podem ser</p><p>relacionados às classificações existentes que são propostas por modelos de referência. Nós já</p><p>mencionou uma série deles. Uma pequena parte do PCF da APQC é mostrada na Tabela 2.1 .</p><p>Esses modelos de referência podem servir como um ponto de partida para desenvolver uma classificação de</p><p>funções de negócios e podem ser adaptados às necessidades específicas da organização.</p><p>Quer esta identificação de funções comece com um modelo de referência ou não,</p><p>requer entrevistas com diferentes pessoas na organização. Essas entrevistas servem</p><p>para identificar as funções diretamente, ou para verificar em que medida as funções</p><p>a partir de um modelo de referência se aplicam à organização. As entrevistas devem ser realizadas</p><p>com os funcionários que estão envolvidos nos diferentes casos que a organização han-</p><p>dles e com gerentes de produto (e serviço) dos diferentes produtos e serviços</p><p>que a organização lida. É, portanto, importante observar que os diferentes</p><p>as pessoas envolvidas podem muito bem usar termos diferentes para funções de negócios semelhantes.</p><p>Homônimos e sinônimos são problemáticos neste contexto. Por exemplo, o que é</p><p>chamada de 'aquisição' em uma parte da organização pode ser chamada de 'pesquisa de mercado' em</p><p>outro (sinônimo). Ao mesmo tempo, duas funções chamadas 'implementação' podem</p><p>representam diferentes atividades: uma pode representar a implementação de software,</p><p>enquanto o outro representa a implementação de novos regulamentos na organização</p><p>ção (homônimo). Além de estar ciente dos vários termos que estão sendo usados,</p><p>um entendimento complexo das operações de uma organização é importante para classificar</p><p>essas questões fora. Frameworks como o PCF da APQC podem ajudar a evitar</p><p>questões desde o início.</p><p>Além disso, as funções podem ser organizadas de forma diferente. Considere, por exemplo,</p><p>Fig. 2.3 . É tirado de um caso do mundo real e mostra partes do decurso funcional</p><p>composições de dois departamentos da mesma organização, um na Europa e</p><p>um na América do Norte. O departamento europeu distingue entre comprar</p><p>e vendas, em que compras e vendas são divididas em funções operacionais.</p><p>Essas funções dizem respeito ao fornecimento e ordem de pagamento para compras, por um lado</p><p>e marketing e operações de vendas para vendas de outro. O norte americano de-</p><p>partment distingue entre sourcing, marketing e tratamento de pedidos. Aqui, ou-</p><p>O manuseio envolve atividades de vendas operacionais e de ordem de pagamento (mas não é</p><p>decomposto mais).</p><p>Claramente, no exemplo desta organização, uma etapa</p><p>de negociação pode ser necessária</p><p>entre as diferentes pessoas envolvidas para unificar as decomposições funcionais entre</p><p>suas partes europeias e norte-americanas. Isso é especialmente necessário se a função</p><p>a decomposição internacional é mais do que apenas um exercício de modelagem. Também pode representar</p><p>propriedades organizacionais reais. No caso ilustrado na Fig. 2.3 , os gerentes</p><p>estão em vigor para as diferentes funções nos diferentes níveis de decomposição. No</p><p>Europa, um gerente é nomeado para vendas, outro para compras e nível inferior</p><p>gerentes de sourcing, order-to-pay, marketing e vendas operacionais. No norte</p><p>América, existem gerentes para sourcing, marketing e gerenciamento de pedidos</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 65/192</p><p>mento. Portanto, quando as decomposições funcionais dos departamentos precisam</p><p>ser harmonizada, a estrutura de gestão também deve ser objeto de harmonização.</p><p>Uma decomposição funcional não deve ser confundida com uma decomposição ac-</p><p>de acordo com o tipo de caso. É possível que uma organização seja estruturada de acordo com</p><p>Página 68</p><p>2.2 Projetando uma Arquitetura de Processo 47</p><p>Tabela 2.1 Nível um e nível dois da estrutura de classificação de processo APQC</p><p>1.0 Desenvolver visão e estratégia</p><p>1.1 Definir o conceito de negócio e longo prazo</p><p>visão</p><p>1.2 Desenvolver estratégia de negócios</p><p>1.3 Gerenciar iniciativas estratégicas</p><p>2.0 Desenvolver e gerenciar produtos e serviços</p><p>2.1 Gerenciar portfólio de produtos e serviços</p><p>2.2 Desenvolver produtos e serviços</p><p>3.0 Comercializar e vender produtos e serviços</p><p>3.1 Compreender mercados, clientes e</p><p>capacidades</p><p>3.2 Desenvolver estratégia de marketing</p><p>3.3 Desenvolver estratégia de vendas</p><p>3.4 Desenvolver e gerenciar planos de marketing</p><p>3.5 Desenvolver e gerenciar planos de vendas</p><p>4.0 Entregar Produtos e Serviços</p><p>4.1 Planejar e alinhar os recursos da cadeia de abastecimento</p><p>4.2 Aquisição de materiais e serviços</p><p>4.3 Produzir / fabricar / entregar produtos</p><p>4.4 Prestar serviço ao cliente</p><p>4.5 Gerenciar logística e armazenamento</p><p>5.0 Gerenciar Atendimento ao Cliente</p><p>5.1 Desenvolver atendimento / atendimento ao cliente</p><p>estratégia</p><p>5.2 Planejar e gerenciar o atendimento ao cliente</p><p>operações</p><p>5.3 Medir e avaliar o atendimento ao cliente</p><p>operações</p><p>6.0 Desenvolver e gerenciar capital humano</p><p>6.1 Desenvolver e gerenciar recursos humanos</p><p>Planejamento, políticas e estratégias (RH)</p><p>6.2 Recrutar, contratar e selecionar funcionários</p><p>6.3 Desenvolver e aconselhar funcionários</p><p>6.4 Recompensar e reter funcionários</p><p>6.5 Reimplantar e aposentar funcionários</p><p>6.6 Gerenciar informações de funcionários</p><p>7.0 Gerenciar Tecnologia da Informação</p><p>7.1 Gerenciar o negócio de informações</p><p>tecnologia</p><p>7.2 Desenvolver e gerenciar cliente de TI</p><p>relacionamentos</p><p>7.3 Desenvolver e implementar segurança, privacidade,</p><p>e controles de proteção de dados</p><p>7.4 Gerenciar informações da empresa</p><p>7.5 Desenvolver e manter informações</p><p>7.6 Implementar soluções de tecnologia da informação</p><p>7.7 Entregar e apoiar informações</p><p>serviços de tecnologia</p><p>8.0 Gerenciar Recursos Financeiros</p><p>8.1 Realizar planejamento e gestão</p><p>contabilidade</p><p>8.2 Realizar contabilidade de receita</p><p>8.3 Realizar contabilidade e relatórios gerais</p><p>8.4 Gerenciar a contabilidade do projeto de ativo fixo</p><p>8.5 Processar folha de pagamento</p><p>8.6 Processar contas a pagar e despesas</p><p>reembolsos</p><p>8.7 Gerenciar operações de tesouraria</p><p>8.8 Gerenciar controles internos</p><p>8.9 Gerenciar impostos</p><p>8.10 Gerenciar fundos / consolidação internacionais</p><p>9.0 Adquirir, construir e gerenciar ativos</p><p>9.1 Projetar e construir / adquirir</p><p>ativos não produtivos</p><p>9.2 Planejar o trabalho de manutenção</p><p>9.3 Obter e instalar ativos, equipamentos e</p><p>Ferramentas</p><p>9.4 Descarte de produtos produtivos e não produtivos</p><p>ativos</p><p>10.0 Gerenciar risco empresarial, conformidade,</p><p>e resiliência</p><p>10.1 Gerenciar riscos corporativos</p><p>10.2 Gerenciar resiliência de negócios</p><p>10.3 Gerenciar saúde e segurança ambiental</p><p>11.0 Gerenciar Relações Externas</p><p>11.1 Construir relacionamentos com investidores</p><p>11.2 Gerenciar governo e indústria</p><p>relacionamentos</p><p>11.3 Gerenciar relações com o conselho de administração</p><p>11.4 Gerenciar questões legais e éticas</p><p>11.5 Gerenciar programa de relações públicas</p><p>12.0 Desenvolver e gerenciar negócios</p><p>Capacidades</p><p>12.1 Gerenciar processos de negócios</p><p>12.2 Gerenciar portfólio, programa e projeto</p><p>12.3 Gerenciar qualidade</p><p>12.4 Gerenciar mudanças</p><p>12.5 Desenvolver e gerenciar em toda a empresa</p><p>gestão do conhecimento (KM)</p><p>capacidade</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 66/192</p><p>soluções de tecnologia 12.6 Medir e comparar</p><p>Página 69</p><p>48 2 Identificação do Processo</p><p>Fig. 2.3 Diferentes decomposições funcionais dentro da mesma organização</p><p>função de negócios e outras propriedades. Pode ser tentador desenvolver</p><p>a decomposição funcional ainda de acordo com essas outras propriedades. Contudo,</p><p>essas outras propriedades devem ser refletidas na dimensão do tipo de caso, em vez do</p><p>dimensão da função. Por exemplo, uma organização pode ser estruturada de acordo com</p><p>funções de negócios em um departamento de vendas e compras com gerentes que lideram</p><p>cada um dos departamentos. Pode ser estruturado de acordo com a localização, tendo</p><p>um departamento de vendas e de compras na Europa e na América do Norte. No</p><p>nesta situação, a decomposição funcional termina com a decomposição em vendas</p><p>e compras. Caso uma decomposição adicional de acordo com a localização seja relevante,</p><p>então esta decomposição deve ser refletida na dimensão do tipo de caso, não no</p><p>dimensão da função.</p><p>Uma decisão importante que deve ser feita ao desenvolver o de- funcional</p><p>composição é determinar o nível apropriado de decomposição em que o</p><p>a decomposição funcional termina. Em teoria, a decomposição funcional pode ser per-</p><p>formado até um nível que representa as tarefas que são realizadas pelo indivíduo</p><p>funcionário (preencher formulário, verificar a exatidão das informações no formulário, ter colega</p><p>verificar a exatidão das informações no formulário, etc.). No entanto, para uma arquitetura de processo</p><p>um nível mais grosseiro de decomposição é normalmente escolhido. Duas regras básicas que podem</p><p>ser usado para escolher o nível de decomposição em que a decomposição funcional</p><p>termina, são os seguintes.</p><p>1. A decomposição funcional deve ser realizada pelo menos até um nível de</p><p>quais funções correspondem a diferentes unidades organizacionais (com</p><p>gerentes). Por exemplo, se uma organização tem uma fonte e um pedido para</p><p>departamento de pagamento e ambos têm seus próprios gerentes, esta é uma forte indicação de que</p><p>a decomposição funcional deve conter as funções que são realizadas por</p><p>esses departamentos.</p><p>2. A decomposição funcional deve incluir funções diferentes para os diferentes</p><p>funções em cada departamento. Por exemplo, se o departamento de sourcing tem compradores,</p><p>que fazem análise de requisitos e seleção de fornecedores, bem como compradores seniores, que</p><p>fazer a gestão de relacionamento com fornecedores e gestão de contratos, isso pode levar a um</p><p>decisão de incluir análise de requisitos, seleção de fornecedor, relacionamento com o fornecedor</p><p>gestão e gestão de contratos como funções.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 67/192</p><p>Página 70</p><p>2.2 Projetando uma Arquitetura de Processo 49</p><p>Fig. 2.4 Uma matriz de caso / função</p><p>Observe que essas são regras básicas, que deixam espaço para manuseá-los flex</p><p>ìvel. Eles apenas fornecem uma ajuda para determinar o nível mais baixo de decomposição</p><p>que deve ser usado.</p><p>Exercício 2.6 Considere o caso de uma universidade e os processos de nível um listados</p><p>no PCF do APQC. Que tipo de funções mais específicas uma universidade tipifica</p><p>cobrir as categorias 2.0, desenvolver e gerenciar produtos e serviços e na 5.0</p><p>Gerencia o atendimento ao cliente?</p><p>2.2.3 Construir Matrizes de Caso / Função</p><p>As duas etapas anteriores da abordagem</p><p>descrita levam a uma matriz que tem a diferença</p><p>diferentes tipos de caso como colunas e as diferentes funções como linhas. Uma célula na matriz</p><p>contém um 'X', se a função correspondente pode ser realizada para o correspondente</p><p>tipo de caso ing. A Figura 2.4 mostra um exemplo de uma matriz de caso / função. O Matrix</p><p>mostra uma decomposição de tipos de caso por tipo de cliente, resultando em três tipos de caso:</p><p>um para clientes particulares, um para clientes corporativos e um para clientes internos</p><p>clientes. A figura também mostra uma decomposição funcional em três funções principais</p><p>e uma decomposição subsequente dessas funções principais em dez subfunções.</p><p>As funções de gerenciamento e suporte são realizadas apenas para clientes internos, enquanto</p><p>as funções operacionais são realizadas para clientes particulares e corporativos.</p><p>Uma matriz de caso / função pode ser dividida em várias matrizes com o propósito de</p><p>melhorando a legibilidade. Normalmente, dividiríamos uma matriz de caso / função no caso</p><p>uma partição das funções da matriz e tipos de caso é possível de tal forma que todos os X são</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 68/192</p><p>Página 71</p><p>50 2 Identificação do Processo</p><p>Fig. 2.5 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo (aplicando a Diretriz 1)</p><p>preservado. Por exemplo, a matriz da Fig. 2.4 pode ser particionada em, em um</p><p>lado, uma matriz que contém as funções de gestão e suporte e as internas</p><p>clientes e, por outro lado, uma matriz que contém as funções operacionais e as</p><p>clientes particulares e corporativos.</p><p>2.2.4 Identificar Processos</p><p>Na quarta e última etapa da abordagem proposta, determinamos qual combinação</p><p>nações de funções de negócios e tipos de casos formam um processo de negócios. Para determinar</p><p>isso, precisamos encontrar uma compensação entre dois extremos, um em que todo o ma-</p><p>trix forma um grande processo e um em que cada cruz única na matriz forma um</p><p>processo. Estabelecemos essa compensação pelo uso da regra geral de que, em princípio,</p><p>toda a matriz forma um grande processo que só será dividido em caso de</p><p>regras se aplicam. Essas regras podem ser formuladas como oito diretrizes. Quando uma diretriz</p><p>se aplica, isso pode levar a uma separação dos processos entre as linhas (uma divisão vertical)</p><p>ou a uma separação de processos entre colunas (uma divisão horizontal). Alguns dos</p><p>diretrizes (diretrizes 5, 6 e 8) só podem levar a divisões verticais, enquanto outras</p><p>(Diretrizes 1–4) só podem levar a divisões horizontais. Observe que as diretrizes não são</p><p>absoluto: eles podem ou não se aplicar a uma determinada organização e não são</p><p>as únicas regras que devem ser consideradas em casos específicos.</p><p>A Figura 2.5 mostra o exemplo de execução que usaremos para explicar as diretrizes.</p><p>A figura mostra uma matriz de caso / função para um corretor de hipotecas, que corretores de hipoteca</p><p>medidores na Holanda e na Bélgica. Ele distingue entre simplex</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 69/192</p><p>Página 72</p><p>2.2 Projetando uma Arquitetura de Processo 51</p><p>e hipotecas compostas. Uma hipoteca composta pode ser adaptada para o re- específico</p><p>peculiaridades de um cliente, compondo-o a partir de diferentes tipos de empréstimos, poupanças</p><p>contas, seguros de vida e contas de investimento. Uma hipoteca simplex consiste em</p><p>um pacote pré-definido de um empréstimo, uma conta poupança e um seguro de vida. Nestes dif-</p><p>diferentes tipos de hipotecas, várias funções de negócios podem ser realizadas. Avaliação de risco</p><p>ment envolve a avaliação do risco de ambos os clientes individuais, que estão no processo</p><p>de solicitar uma hipoteca e produtos hipotecários como um todo. Corretora de hipotecas</p><p>envolve a seleção de um determinado pacote de hipoteca com base nos requisitos</p><p>de um cliente específico e, posteriormente, oferecer esse pacote ao cliente e</p><p>fechar o contrato. As funções financeiras envolvem o pagamento da hipoteca e</p><p>posteriormente cobrando os pagamentos mensais. Finalmente, o desenvolvimento de produtos é o</p><p>revisão periódica dos produtos hipotecários e seus componentes.</p><p>Diretriz 1: se um processo tiver objetos de fluxo diferentes, ele pode ser dividido verticalmente.</p><p>Um objeto de fluxo é um objeto na organização que flui através de um programa de negócios</p><p>cesso É o objeto no qual as atividades do processo empresarial estão sendo realizadas.</p><p>Normalmente, cada processo de negócios tem um único objeto de fluxo, de modo que objetos de fluxo</p><p>pode ser usado para identificar processos de negócios. Consequentemente, se vários objetos de fluxo</p><p>podem ser identificados em um processo de negócios, esta é uma forte indicação de que o processo</p><p>deve ser dividido.</p><p>A Figura 2.5 ilustra a aplicação da Diretriz 1 ao nosso exemplo de execução. 1</p><p>objeto de fluxo para o processo de corretagem de hipotecas é um aplicativo de hipoteca em que</p><p>as atividades são realizadas durante um pedido de hipoteca por um cliente. Essas atividades</p><p>incluir uma avaliação de risco e pagar a hipoteca ao cliente. Outro fluxo</p><p>objeto no processo de corretagem de hipotecas é um produto hipotecário em que as atividades</p><p>são realizadas periodicamente para avaliar o risco do produto como um todo e para avaliar</p><p>comer e desenvolver o produto. Consequentemente, podemos dividir a corretora de hipotecas</p><p>processo em dois processos, um que tem um aplicativo de hipoteca como objeto de fluxo e</p><p>aquele que tem um produto hipotecário como objeto de fluxo. Chamamos o primeiro de hipoteca</p><p>processo de aplicação e este último o processo de desenvolvimento e avaliação do produto.</p><p>Diretriz 2: Se o objeto de fluxo de um processo muda multiplicidade, o processo pode ser</p><p>dividir verticalmente. Isso se deve ao fato de que em um processo de negócios um único fluxo</p><p>objeto às vezes é usado, enquanto outras vezes vários objetos de fluxo do mesmo</p><p>tipo são usados. Isso é típico para processamento em lote, no qual certas atividades são</p><p>executado para vários casos de cliente em lote ao mesmo tempo. Se, no mesmo</p><p>processo, o número de objetos de fluxo que são processados por atividade difere isso pode</p><p>ser um motivo para dividir o processo.</p><p>Dê uma olhada na Fig. 2.5 , onde o processo de aplicação de hipoteca é realizado para</p><p>um único pedido de hipoteca. Em contraste, a cobrança de pagamentos acontece para</p><p>todas as hipotecas em lote no final de cada mês. Usando a Diretriz 2, isso pode ser</p><p>tomado como motivo de cisão do processo e tendo a Cobrança Hipotecária como um</p><p>processo separado.</p><p>Diretriz 3: Se um processo muda de estado transacional, ele pode ser dividido verticalmente.</p><p>De acordo com a teoria do fluxo de trabalho de ação, um processo de negócios passa por vários</p><p>Página 73</p><p>52 2 Identificação do Processo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 70/192</p><p>ber de estados transacionais. Em particular, podemos distinguir: a iniciação, o ne-</p><p>iniciação, a execução e o estado de aceitação. No estado de iniciação, contate</p><p>entre um cliente e um provedor é iniciado. No estado de negociação, o cliente</p><p>cliente e o fornecedor negociam sobre os termos de serviço ou entrega de um produto</p><p>uct. Durante o estado de execução, o provedor entrega o produto ou serviço ao</p><p>cliente e durante o estado de aceitação, o cliente e o fornecedor negociam</p><p>comeu sobre a aceitação e pagamento da entrega. Uma transição em um processo</p><p>de um estado para outro é uma indicação de que o processo pode ser dividido.</p><p>Para ilustrar essa diretriz, considere novamente a Fig. 2.5 . Suponha que durante o ne-</p><p>negociação declara o corretor de hipotecas e o cliente negocia sobre a seleção</p><p>de produtos hipotecários, em última análise, levando a um contrato sendo assinado por ambos os par-</p><p>laços. Somente durante o estado de execução a hipoteca é paga ao cliente e</p><p>os pagamentos mensais serão cobrados. Pela lógica da Diretriz 3, nós, portanto,</p><p>dividir o processo em um processo de</p><p>aplicação de hipoteca e um pagamento de hipoteca</p><p>processo.</p><p>Diretriz 4: Se um processo contém uma separação lógica no tempo, ele pode ser dividido ver-</p><p>ticamente. Um processo contém uma separação lógica no tempo, se suas partes forem realizadas</p><p>em diferentes intervalos de tempo. Os intervalos que normalmente podem ser distinguidos incluem:</p><p>uma vez por solicitação do cliente, uma vez por dia, uma vez por mês e uma vez por ano.</p><p>Para esclarecer a Diretriz 4, considere a Fig. 2.5 novamente. Seleção de hipoteca, oferta e</p><p>a contratação é realizada uma vez por pedido de hipoteca, enquanto o pagamento e a cobrança</p><p>a seleção de hipotecas é realizada uma vez por mês. Pela lógica da Diretriz 4,</p><p>faria sentido dividir a seleção, oferta e contratação de hipotecas</p><p>cobrança do pagamento da hipoteca. Observe que a passagem do tempo em si não é uma razão</p><p>para dividir um processo, porque dentro de cada processo, o tempo passa. Para ex-</p><p>amplo, entre a atividade de inserir os detalhes da hipoteca em um sistema de computador e</p><p>aprovação da hipoteca, o tempo passa, mas a unidade de tempo permanece a mesma: ambos</p><p>as atividades acontecem uma vez por aplicativo de hipoteca. Portanto, não nos separaríamos</p><p>o processo entre essas atividades. Outra maneira de olhar a Diretriz 4 é que</p><p>o processo pode ser dividido, se deve esperar por um gatilho de tempo ou um gatilho por um novo</p><p>objeto de fluxo. Por exemplo, a aprovação de uma hipoteca pode ser realizada diretamente após</p><p>os detalhes da hipoteca são inseridos, sem ter que esperar por um acionador. No entanto, depois</p><p>tendo processado o pedido de hipoteca, o processo deve aguardar o pagamento</p><p>acione a data de cobrança para continuar com a cobrança do pagamento. Portanto, nós</p><p>dividir o processo entre essas funções pela mesma lógica da Diretriz 4.</p><p>Diretriz 5: se um processo contém uma separação lógica no espaço, ele pode ser dividido</p><p>horizontalmente. Um processo contém uma separação lógica no espaço, se for executado em</p><p>vários locais e é executado de forma diferente nesses locais. É importante</p><p>observar que não é suficiente que os processos sejam apenas separados no espaço. o</p><p>a separação deve ser tal que não haja escolha a não ser realizar os processos</p><p>de forma diferente para as diferentes unidades lógicas.</p><p>Para esclarecer esta diretriz: no caso de um processo ser realizado em locais diferentes</p><p>dentro do mesmo país, não há necessariamente uma razão para agir de forma diferente</p><p>Página 74</p><p>2.2 Projetando uma Arquitetura de Processo 53</p><p>nesses locais. Conseqüentemente, não há razão para dividi-lo. Na verdade, a organização</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 71/192</p><p>ções devem se esforçar para tornar seus processos tão uniformes quanto possível, para se beneficiareconomias de escala. Na verdade, muitas organizações hoje em dia iniciaram projetos nos quais</p><p>eles visam tornar seus processos mais uniformes em diferentes locais, onde</p><p>processos tornaram-se diferentes puramente por razões históricas ou porque os diferentes</p><p>cátions não compartilham informações sobre seu fluxo de processo. Como outro exemplo, o</p><p>processos da Fig. 2.5 são realizados em dois locais diferentes em diferentes países</p><p>tentativas. No entanto, ainda nem todos esses processos devem ser diferentes nesses dois locais.</p><p>Por exemplo, o pagamento e a cobrança de hipotecas podem ser os mesmos na Bélgica e</p><p>Os Países Baixos. No entanto, a avaliação de risco, corretagem de hipotecas e desenvolvimento de produtos</p><p>opção pode ser diferente entre a Holanda e a Bélgica, devido à especificidade do país</p><p>regras e regulamentos.</p><p>As diretrizes 6 e 7 são mais diretas e podem ser descritas como segue.</p><p>Diretriz 6: Se um processo contém uma separação lógica em outra dimensão relevante</p><p>seção, ele pode ser dividido horizontalmente. Como acontece com a separação no espaço, não é</p><p>suficiente para que os processos sejam apenas separados. A separação deve ser tal que</p><p>não há escolha a não ser realizar os processos de forma diferente para as diferentes logias</p><p>unidades cal.</p><p>Diretriz 7: Se um processo é dividido em um modelo de referência, ele pode ser dividido. Uma referência</p><p>a arquitetura de processo de referência é uma arquitetura de processo existente que é pré-definida como</p><p>uma solução de prática recomendada. Ele estrutura uma coleção de processos. Por exemplo, se um</p><p>existe uma arquitetura de processo de serviços financeiros de referência, sua estrutura pode ser usada</p><p>como um exemplo ou ponto de partida para estruturar sua própria arquitetura de processo.</p><p>A Figura 2.6 mostra os resultados da aplicação das Diretrizes 2 a 7 para o</p><p>matriz de caso / função da Fig. 2.5 , que resultou da aplicação da Diretriz 1</p><p>ao nosso exemplo de execução. A Figura 2.6 mostra que após a aplicação das Diretrizes 2 a</p><p>7, conforme discutido acima, existem seis processos: Desenvolvimento e Avaliação do Produto -</p><p>ment Holanda (PD NL), Desenvolvimento e Avaliação de Produto Bélgica (PD</p><p>BE), Mortgage Application Netherlands, Mortgage Application Belgium, Mortgage</p><p>Pagamento e cobrança da hipoteca.</p><p>A orientação final que discutimos aqui é a seguinte.</p><p>Diretriz 8: Se um processo cobre (muitas) mais funções em um tipo de caso do que em</p><p>outro, pode ser dividido horizontalmente. A aplicação desta última regra depende</p><p>na decomposição atual dos processos. Se aplicado, é necessário olhar</p><p>na decomposição atual de processos e verifique se, dentro de um processo, (muitos)</p><p>mais funções são realizadas para um tipo de caso do que para outro, ou seja: se</p><p>um processo tem muito mais cruzes em uma coluna do que em outra. Se sim, este é um</p><p>forte indicação de que o processo deve ser dividido para esses dois tipos de caso.</p><p>Por exemplo, ao olhar para a Fig. 2.6 , vemos que o aplicativo de hipoteca</p><p>O processo da Holanda tem muito mais funções para hipotecas compostas do que para sim-</p><p>hipotecas plex. Pela lógica da Diretriz 8, dividiríamos este processo para</p><p>aplicação composta e simplex. A aplicação de todas essas oito diretrizes</p><p>produz uma arquitetura de processo para o nível um. O resultado pode ser visto na Fig. 2.7 , que</p><p>é o modelo de paisagem de processo finalizado para nosso exemplo.</p><p>Página 75</p><p>54 2 Identificação do Processo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 72/192</p><p>Fig. 2.6 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo (aplicando o Guia</p><p>linhas 2-7)</p><p>Fig. 2.7 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo (aplicando a Diretriz 8)</p><p>Página 76</p><p>2.2 Projetando uma Arquitetura de Processo 55</p><p>Tabela 2.2</p><p>Consumidor-produtor</p><p>relações entre</p><p>processos</p><p>Consumidor Produtor</p><p>Pagamento da hipoteca Aplicativo de hipoteca composto NL</p><p>Pagamento da hipoteca Aplicativo de hipoteca simplex NL</p><p>Pagamento da hipoteca Aplicação de hipoteca BE</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 73/192</p><p>2.2.5 Concluir a Arquitetura do Processo</p><p>A abordagem que discutimos anteriormente e que enfatizamos nesta parte do</p><p>o livro leva a um modelo de paisagem de processo que cobre os processos no nível um</p><p>da pirâmide na Fig. 2.1 . Conforme declarado, este nível fornece apenas uma visão muito abstrata</p><p>em cada processo dentro do cenário de processo: mostra principalmente como os processos diferem</p><p>uns dos outros em termos dos casos e funções que cobrem.</p><p>Há duas coisas que estão faltando em relação ao geral, englobe</p><p>características de uma arquitetura de processo, conforme discutimos na Seção 2.2 : (1) o</p><p>relações consumidor-produtor entre os processos e (2) os níveis de detalhe</p><p>conforme fornecido pela pirâmide na Fig. 2.1 .</p><p>No que diz respeito às relações consumidor-produtor, podemos tomar uma ampla ou narrativa</p><p>perspectiva de linha sobre o uso de uma saída de um processo como a entrada de outro.</p><p>Para o nosso exemplo em execução, pode ser que o processo de desenvolvimento de produto use ag-</p><p>dados agregados sobre como o processo de aplicação de hipoteca</p><p>é realizado para determinar</p><p>quais são as necessidades dos clientes e, dessa forma, quais são os novos produtos atrativos.</p><p>Esta seria uma interpretação bastante ampla da relação consumidor-produtor.</p><p>O que muitas vezes é mais importante saber decorre de uma perspectiva mais restrita, ou seja,</p><p>quais relações consumidor-produtor existem entre os processos no que diz respeito ao</p><p>mesmos objetos de fluxo. Na Fig. 2.7 , pode-se ver que o pedido de hipoteca (ambos em</p><p>Holanda e Bélgica) e o pagamento da hipoteca são divididos, o que foi feito</p><p>seguindo a lógica da Diretriz 3. Esta é uma situação onde o objeto de fluxo de um</p><p>o processo é consumido aos poucos por outro; a única diferença é o transacional</p><p>declarar que o objeto de fluxo está dentro. Especificamente em relação às iniciativas de redesenho,</p><p>relações são mais importantes para lembrar e tornar explícito, uma vez que mudar um</p><p>processo tem implicações diretas para o desempenho do outro. Podemos capturar isso</p><p>interpretação restrita das relações consumidor-produtor para nosso exemplo de execução</p><p>como é feito na Tabela 2.2 . Cada linha nesta tabela fornece um único produtor-consumidor</p><p>relacionamento, onde o processo do consumidor continua a trabalhar em um objeto de fluxo que é</p><p>a saída do processo de produção.</p><p>Vamos agora nos concentrar no outro aspecto que torna uma arquitetura de processo para nível</p><p>um bastante restritivo em comparação com nossa noção geral de uma arquitetura de processo.</p><p>Isso diz respeito ao alto nível de abstração dos processos que se distinguem por</p><p>o modelo de paisagem de processo. Para se concentrar nos outros níveis da pirâmide da Fig. 2.1 ,</p><p>a questão é que tipo de detalhe adicional eles devem oferecer. Nós nos concentramos aqui em</p><p>os insights que faltam sobre (a) as várias etapas que são realizadas em cada processo</p><p>e (b) as unidades organizacionais que estão envolvidas em sua execução. Estes dois</p><p>elementos devem ser adicionados para obter os modelos para o nível dois do que entendemos por</p><p>Página 77</p><p>56 2 Identificação do Processo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 74/192</p><p>Fig. 2.8 Um mapa de processo para o processo de pagamento da hipoteca</p><p>uma arquitetura de processo. É comum se referir a um modelo neste segundo nível como um</p><p>mapa de processo .</p><p>Para fornecer um exemplo de um mapa de processo, nos concentramos no pagamento da hipoteca</p><p>processo que é identificado no modelo de paisagem de processo da Fig. 2.7 . O relacionado</p><p>o mapa do processo pode ser visto na Fig. 2.8 .</p><p>Como mostra esta figura, o processo de pagamento de hipoteca identificado a partir do processo</p><p>modelo de paisagem foi decomposto em quatro etapas principais que podem ser associadas</p><p>com este processo. Além disso, duas unidades organizacionais são identificadas que estão associadas</p><p>ciado com essas etapas, ou seja, Contabilidade e Faturamento. Em outras palavras, um mapa de processo</p><p>fornece mais detalhes sobre o fluxo de controle e inclui informações adicionais com</p><p>respeito aos recursos envolvidos para um processo.</p><p>Pode-se dizer que mesmo um mapa de processo fornece uma visão abstrata de um processo.</p><p>Em primeiro lugar, ainda podemos ver que o fluxo ao longo das etapas em um mapa de processo</p><p>é altamente simplificado. É comum, como na Fig. 2.8 , mostrar apenas um progresso linear</p><p>ao longo das várias etapas em um mapa de processo: caminhos alternativos, exceções potenciais,</p><p>iterações, etc. são deixadas de fora. Para as informações organizacionais que são adicionadas em um</p><p>mapa de processo, também, a informação é abstrata: só podemos ver referências a unidades, mas</p><p>não o tipo específico de participantes envolvidos.</p><p>Exercício 2.7 Dê um exemplo de um caminho alternativo, uma exceção potencial e um</p><p>iteração que apareceria em um modelo mais detalhado do pagamento da hipoteca</p><p>processo.</p><p>Em segundo lugar, há muitos aspectos além do fluxo de controle e informações de recursos</p><p>que não são cobertos em nenhum nível de detalhe em um mapa de processo. Pense nos dados que</p><p>estão sendo tratados no processo, os relatórios e arquivos que são repassados, os sistemas</p><p>que suportam as várias etapas, o tempo que está envolvido na realização dessas etapas,</p><p>etc.</p><p>Na prática, os mapas de processo acabaram por fornecer um nível mais profundo de percepção sobre</p><p>os processos do cenário de processo, independentemente dos objetivos que se busca para o</p><p>processos específicos. Em outras palavras, uma visão sobre as etapas e organizações envolvidas</p><p>unidades internacionais têm seu valor para qualquer tipo de iniciativa orientada para o processo. Em contraste, um</p><p>mais informações sobre, por exemplo, os dados que estão sendo processados em cada etapa</p><p>Página 78</p><p>2.3 Recapitulação 57</p><p>só faria sentido se alguém buscasse automatizar o processo ou quando o</p><p>fase de avaliação identificou problemas de qualidade.</p><p>Neste livro, não vamos nos concentrar no desenvolvimento de mapas de processo. Em vez de,</p><p>vamos nos voltar para o nível mais detalhado de modelos, ou seja, aqueles no nível três de um processo</p><p>arquitetura. Como será mostrado, esses modelos são desenvolvidos seguindo regras específicas</p><p>e fornecer a visão idealmente ligada ao que se deseja alcançar com</p><p>uma iniciativa específica de gerenciamento de processos. Este será o assunto do seguinte</p><p>capítulos.</p><p>2.3 Recapitulação</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 75/192</p><p>Neste capítulo, discutimos a identificação do processo. Primeiro, nós distinguimos</p><p>e descreveu as fases de designação e avaliação. A fase de designação visa</p><p>em enumerar os principais processos dentro de uma organização, bem como determinar</p><p>as fronteiras entre esses processos. Uma visão dos principais processos que</p><p>estão sendo realizados em uma organização é importante configurar qualquer homem de processo</p><p>atividade de gestão. A fase de avaliação é dedicada a priorizar a análise do processo</p><p>e esforços de redesenho. É uma boa prática basear as prioridades na importância de</p><p>processos, sua disfunção potencial e a viabilidade de melhorias.</p><p>A fase de designação pode ser usada não apenas para enumerar os mais importantes</p><p>processos, mas também para projetar uma arquitetura de processo abrangente e consistente. Um pro</p><p>A arquitetura do processo define a relação entre os diferentes processos. Frequentemente,</p><p>diferentes níveis de detalhe são distinguidos. Discutimos uma abordagem específica para o</p><p>definição do nível um da arquitetura do processo. Esta abordagem se baseia na identidade</p><p>identificação dos tipos de caso, das funções para esses tipos de caso, a construção de um</p><p>matriz de caso / função, a identificação de processos com base em diretrizes, e o</p><p>eventual conclusão da arquitetura.</p><p>2.4 Soluções para exercícios</p><p>Solução 2.1 Explique como funciona a compensação entre impacto e capacidade de gerenciamento</p><p>fora para processos amplos e estreitos, respectivamente. Um amplo processo tem por definição</p><p>um grande escopo. Gerenciar isso ativamente pode ter um grande impacto em uma organização</p><p>desempenho da zação. O outro lado é que é mais difícil gerenciar ativamente tais</p><p>um processo amplo ou os projetos de melhoria que estão relacionados a ele. Para um estreito pro-</p><p>cesso, é exatamente o contrário: devido ao seu escopo menor, é mais fácil</p><p>gerenciado, mas provavelmente terá um impacto menor no desempenho de uma organização</p><p>como um todo.</p><p>Solução 2.2 A descrição da empresa de investimento aponta para uma grande retenção financeira</p><p>, que podem estar relacionados ao emprego de muitos produtos diferentes (investimentos</p><p>instrumentos financeiros) para muitos clientes diferentes, tanto privados como institucionais. Ambos</p><p>Página 79</p><p>58 2 Identificação do Processo</p><p>dessas dimensões, produtos e clientes, podem levar a empresa a identificar diferentes</p><p>processos que atendem a esses. Além disso, a descrição da empresa também menciona</p><p>'responsabilidade': para muitas organizações financeiras, existem requisitos estritos sobre</p><p>como eles devem gerenciar e divulgar</p><p>enfocar o cap. 3 e</p><p>Caras. 5 a 8 . Naturalmente, cap. Eu poderia encontrar seu lugar em qualquer um dos cursos acima.</p><p>Cada capítulo pode ser entregue como uma combinação de aulas teóricas e aulas</p><p>sessões. Capítulos mais curtos ( 1 , 2 , 3 , 5 , 6 e 10 ) podem ser ministrados em uma aula e em uma</p><p>sessão de trabalho de classe. Os capítulos 4 , 8 e 9 podem exigir duas aulas e duas aulas</p><p>sessões cada. O Capítulo 7 pode ser ministrado em duas aulas e duas aulas</p><p>sessões, ou pode ser entregue em uma aula e uma sessão de trabalho pulando</p><p>o conteúdo em filas e análise de fluxo.</p><p>Este livro é o resultado de muitos anos de prática educacional tanto no</p><p>níveis de graduação e pós-graduação em mais de meia dúzia de instituições, incluindo</p><p>Eindhoven University of Technology (Holanda), Queensland University of</p><p>Tecnologia (Austrália), Humboldt University of Berlin (Alemanha), University of</p><p>Tartu (Estônia), Universidade de Economia e Negócios de Viena (Áustria) e Na-</p><p>Universidade Internacional da Colômbia. O material neste livro também serviu como um</p><p>base para cursos de treinamento profissional ministrados a organizações na Austrália, o</p><p>Holanda e outros lugares. Somos gratos aos milhares de alunos que mais</p><p>os últimos anos nos deram feedback construtivo e incentivo.</p><p>Também devemos muito aos nossos muitos colegas que nos encorajaram e forneceram</p><p>com feedback durante todo o processo da ideia para o livro-texto. Nós gostaríamos de</p><p>obrigado Wil van der Aalst, Raffaele Conforti, Monika Malinova, Johannes Prescher,</p><p>Artem Polyvyanyy, Manfred Reichert, Jan Recker, Michael Rosemann, Matthias</p><p>Schrepfer, Arthur ter Hofstede, Irene Vanderfeesten, J. Leon Zhao e Michael zur</p><p>Muehlen, que forneceu feedback construtivo sobre as versões preliminares do livro. Fabio Casati</p><p>e Boualem Benatallah nos deu o incentivo inicial para começar a escrever</p><p>processo. Menções especiais são devidas a Matthias Weidlich que nos forneceu</p><p>sugestões personalizadas e abrangentes, e Remco Dijkman que compartilhou conosco</p><p>material didático que serviu de entrada para o Chaps. 2 e 9 .</p><p>Marlon Dumas</p><p>Marcello La Rosa</p><p>Jan Mendling</p><p>Hajo A. Reijers</p><p>Tartu, Estônia</p><p>Brisbane, Austrália</p><p>Viena, Áustria</p><p>Eindhoven, Holanda</p><p>Página 10</p><p>Conteúdo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 10/192</p><p>1 Introdução ao Gerenciamento de Processos de Negócios . . . . . . . . . . . . . 1</p><p>1.1 Processos em todos os lugares. . . . . . . . . . . . . . . . . . . . . . . . 1</p><p>1.2 Ingredientes de um Processo de Negócios. . . . . . . . . . . . . . . . . . 3</p><p>1.3 Origens e história do BPM. . . . . . . . . . . . . . . . . . . . . 8</p><p>1.3.1 A Organização Funcional. . . . . . . . . . . . . . . . 8</p><p>1.3.2 O nascimento do pensamento processual. . . . . . . . . . . . . . . . 10</p><p>1.3.3 O Risco e a Queda do BPR. . . . . . . . . . . . . . . . . . 12</p><p>1.4 CicloBPML. . . . . . . . . . . . . . . . . . . . . . . . . 15</p><p>1.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26</p><p>1.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 26</p><p>1.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 28</p><p>1.8 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 31</p><p>2 Identificação do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . 33</p><p>2.1 FocusingonKeyProcesses. . . . . . . . . . . . . . . . . . . . . 33</p><p>2.1.1 A fase de designação. . . . . . . . . . . . . . . . . . . 34</p><p>2.1.2 A fase de avaliação. . . . . . . . . . . . . . . . . . . . 38</p><p>2.2 DesigningaProcessArchitecture. . . . . . . . . . . . . . . . . . 42</p><p>2.2.1 IdentifyCaseTypes. . . . . . . . . . . . . . . . . . . . . 44</p><p>2.2.2 Identificar funções para tipos de caso. . . . . . . . . . . . . . 45</p><p>2.2.3 Construir Matrizes de Caso / Função. . . . . . . . . . . . . . 49</p><p>2.2.4 IdentifyProcesses. . . . . . . . . . . . . . . . . . . . . . 50</p><p>2.2.5 Completar a arquitetura do processo. . . . . . . . . . . . . 55</p><p>2.3 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57</p><p>2.4 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 57</p><p>2.5 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 59</p><p>2.6 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 60</p><p>3 Modelagem de processos essenciais . . . . . . . . . . . . . . . . . . . . . . . 63</p><p>3.1 FirstStepswithBPMN. . . . . . . . . . . . . . . . . . . . . . . 63</p><p>3.2 Ramificação e fusão. . . . . . . . . . . . . . . . . . . . . . . 67</p><p>3.2.1 Decisões Exclusivas. . . . . . . . . . . . . . . . . . . . . 67</p><p>xiii</p><p>Página 11</p><p>xiv Conteúdo</p><p>3.2.2 Execução Paralela. . . . . . . . . . . . . . . . . . . . . . 69</p><p>3.2.3 Decisões Inclusivas. . . . . . . . . . . . . . . . . . . . . 72</p><p>3.2.4 Retrabalho e repetição. . . . . . . . . . . . . . . . . . . 77</p><p>3.3 InformationArtifacts. . . . . . . . . . . . . . . . . . . . . . . . 79</p><p>3.4 Recursos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82</p><p>3.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89</p><p>3.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 89</p><p>3.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 93</p><p>3.8 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 95</p><p>4 Modelagem Avançada de Processos . . . . . . . . . . . . . . . . . . . . . . . 97</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 11/192</p><p>4.1 ProcessDecomposition. . . . . . . . . . . . . . . . . . . . . . . 974.2 ProcessReuse. . . . . . . . . . . . . . . . . . . . . . . . . . . . 100</p><p>4.3 Mais sobre retrabalho e repetição. . . . . . . . . . . . . . . . . . . 102</p><p>4.3.1 ParallelRepetition. . . . . . . . . . . . . . . . . . . . . . 104</p><p>4.3.2 Repetição não controlada. . . . . . . . . . . . . . . . . . . 107</p><p>4.4 HandlingEvents. . . . . . . . . . . . . . . . . . . . . . . . . . . 108</p><p>4.4.1 MessageEvents. . . . . . . . . . . . . . . . . . . . . . . 108</p><p>4.4.2 TemporalEvents. . . . . . . . . . . . . . . . . . . . . . . 110</p><p>4.4.3 RacingEvents. . . . . . . . . . . . . . . . . . . . . . . . 111</p><p>4.5 HandlingExceptions. . . . . . . . . . . . . . . . . . . . . . . . . 114</p><p>4.5.1 Processo de aborto. . . . . . . . . . . . . . . . . . . . . . . 115</p><p>4.5.2 InternalExceptions. . . . . . . . . . . . . . . . . . . . . 116</p><p>4.5.3 ExternalExceptions. . . . . . . . . . . . . . . . . . . . . 117</p><p>4.5.4 ActivityTimeouts. . . . . . . . . . . . . . . . . . . . . . 118</p><p>4.5.5 Eventos sem interrupção e exceções complexas. . . . . 119</p><p>4.5.6 Interlude: EventSubprocessos. . . . . . . . . . . . . . . 121</p><p>4.5.7 ActivityCompensation. . . . . . . . . . . . . . . . . . . 122</p><p>4.6 Processos e regras de negócios. . . . . . . . . . . . . . . . . . . . 124</p><p>4.7 ProcessChoreografias. . . . . . . . . . . . . . . . . . . . . . . 125</p><p>4.8 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129</p><p>4.9 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 130</p><p>4.10 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 146</p><p>4.11 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 152</p><p>5 Descoberta do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155</p><p>5.1 A configuração da descoberta do processo. . . . . . . . . . . . . . . . . . 155</p><p>5.1.1 Analista de processos versus especialista em domínio. . . . . . . . . . . 156</p><p>5.1.2 ThreeProcessDiscoveryChallenges. . . . . . . . . . . . 158</p><p>5.1.3 ProfileofaProcessAnalyst. . . . . . . . . . . . . . . . . 159</p><p>5.2 DiscoveryMethods. . . . . . . . . . . . . . . . . . . . . . . . . 161</p><p>5.2.1 Descoberta baseada em evidências. . . . . . . . . . . . . . . . . 161</p><p>5.2.2 Descoberta baseada em entrevista. . . . . . . . . . . . . . . . . 162</p><p>5.2.3 Descoberta baseada em oficina. . . . . . . . . . . . . . . . . 164</p><p>5.2.4 Pontos fortes e limitações. . . . . . . . . . . . . . . . . . 165</p><p>Página 12</p><p>Conteúdo xv</p><p>5.3 ProcessModelingMethod. . . . . . . .</p><p>sua operação, conforme imposto a eles pela regulamentação</p><p>agências de latórios. Isso também pode ser um motivador para a identificação de muitos</p><p>processos.</p><p>Solução 2.3 O gerenciamento de pedidos não está sequencialmente relacionado a nenhum deles. Como dis-</p><p>discutidos no texto, reserva, cobrança, remessa e entrega são todos subprocessos de</p><p>gerenciamento de pedidos. Portanto, é impossível indicar que algum desses subprocessos</p><p>precede ou acompanha o gerenciamento de pedidos; em vez disso, eles são subsumidos por este</p><p>processo.</p><p>Solução 2.4 As organizações desejam atingir certos objetivos . Os processos são um meio</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 76/192</p><p>para atingir esses objetivos. Uma relação que, portanto, pode ser importante é como os processosestão relacionados entre si no sentido de que contribuem para o mesmo ou</p><p>metas. Outras relações específicas do contexto também podem ser importantes para as organizações.</p><p>Considere como pode ser importante para uma organização saber em qual tecnologia</p><p>gies seus processos são baseados; se uma determinada tecnologia se tornar obsoleta, tal</p><p>organização sabe quais processos são afetados. Uma linha de raciocínio semelhante pode ser</p><p>tomadas para áreas geográficas, regulamentos, etc.</p><p>Solução 2.5 Muitos bancos distinguem diferentes tipos de clientes e usam este dis-</p><p>tição para definir tipos de produtos e serviços para eles, tanto quanto canais. Para</p><p>Por exemplo, um cliente de banco de varejo é tipicamente caracterizado por um baixo a médio</p><p>venha quem requer serviços de transação e produtos para acumular riqueza. Frequentemente,</p><p>os bancos tentam atender esses clientes por meio de canais padronizados como telefone e</p><p>ternet para limitar os custos de transação. Pelo contrário, os clientes de bancos privados são</p><p>normalmente têm alta renda ou possuem uma fortuna considerável. Os bancos investem muito</p><p>mais em aconselhamento pessoal e consultoria desses clientes e na oferta de</p><p>pacotes individuais de produtos e serviços. Muitas vezes, considerações estratégicas como</p><p>daqueles um banco neste exemplo têm a consequência de que diferentes classificações</p><p>critérios são freqüentemente correlacionados.</p><p>Solução 2.6 Os produtos e serviços de uma universidade se relacionam ao ensino e certificação</p><p>cação e, essencialmente, apoiar o ciclo de vida de um aluno para a obtenção de um diploma.</p><p>Portanto, a categoria 2.0 relaciona-se principalmente ao desenvolvimento e gestão de</p><p>currículos e programas de graduação. As entidades acadêmicas de uma universidade estão envolvidas</p><p>com essas tarefas. A categoria 5.0 se refere à gestão de serviços estudantis</p><p>vícios. Normalmente, as tarefas pertencentes a esta categoria são organizadas em um exame</p><p>escritório da universidade auxiliando em todos os assuntos relacionados ao estudo.</p><p>Solução 2.7 Um exemplo de caminhos alternativos no processo de pagamento de hipotecas</p><p>seria que diferentes condições de pagamento levariam a atividades de cobrança de pagamentos.</p><p>Um exemplo de exceção neste processo seria que o saldo da conta é</p><p>Página 80</p><p>2.5 Exercícios adicionais 59</p><p>não é suficiente para cobrar um pagamento. Um exemplo de iteração seria que após um</p><p>falha na cobrança do pagamento, isso é tentado novamente (talvez após um certo atraso).</p><p>2.5 Exercícios adicionais</p><p>Exercício 2.8 Uma universidade fornece educação e serviços aos seus alunos. Isso começa</p><p>com admissão de alunos à universidade. Quando um aluno regular, ou seja, um aluno</p><p>que vem de uma escola secundária holandesa, envia em seu formulário de admissão tal aluno que é</p><p>registrado pelo escritório de admissões. Posteriormente, a elegibilidade para estudar em um determinado</p><p>programa é verificado com base nas informações que o aluno forneceu em seu anúncio</p><p>formulário de missão. Para alunos que chegam de outra escola, como uma politécnica,</p><p>o estudo prévio que o aluno realizou, conforme ficha de admissão, deve ser</p><p>examinados em detalhes. Os alunos politécnicos podem vir para a universidade após</p><p>completar um ano de cursos (propedeuse) ou depois de receber um diploma politécnico.</p><p>Estudantes de universidades de outros países também são aceitos. Também para eles, o</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 77/192</p><p>estudos que eles fizeram anteriormente devem ser examinados em detalhes. Quando os alunos sãoconsiderados elegíveis e os cursos que já frequentaram (se aplicável)</p><p>confira, eles estão matriculados na universidade, o que envolve o envio de uma carta que</p><p>eles são aceitos e inserindo os detalhes de sua inscrição no sistema de informações</p><p>tem da universidade. Os alunos então se tornam alunos de seus respectivos estudos:</p><p>engenharia industrial, construção ou engenharia de construção.</p><p>Depois que os alunos estão matriculados, eles podem fazer cursos ou fazer projetos e podem</p><p>usar os serviços que são prestados pela universidade, que incluem: formação de línguas</p><p>e instalações desportivas. Os projetos são feitos individualmente por um aluno em conjunto</p><p>com um palestrante. A universidade reconhece alunos em tempo parcial que fazem seus estudos</p><p>enquanto eles estão trabalhando em uma empresa. Esses alunos costumam fazer projetos de mais</p><p>natureza prática do que os demais alunos, de modo que o processo que é seguido durante</p><p>o projeto também é diferente para esses alunos.</p><p>Projete uma arquitetura de processo da seguinte maneira:</p><p>1. identificar os tipos de caso que devem aparecer na arquitetura do processo</p><p>2. identificar as funções que devem aparecer na arquitetura do processo</p><p>3. desenhe uma matriz de caso / função</p><p>4. identificar os processos na matriz de função de caso, dividir os processos se e somente se</p><p>uma das diretrizes se aplica, indique claramente qual diretriz você aplicou onde</p><p>Exercício 2.9 Uma empresa de consultoria fornece consultoria, terceirização e interina</p><p>serviços de gestão. A empresa considera a aquisição de projetos como parte daqueles</p><p>Serviços. A aquisição pode ser feita para clientes existentes e para novos clientes, seja</p><p>porque se trata de aquisição de projetos e não de clientes. Aquisição é tipicamente</p><p>começou em 'eventos de networking' por sócios da empresa de consultoria. É tratado</p><p>de acordo com um procedimento fixo, mas nenhum documento padrão é usado. Quando um cliente</p><p>demonstra interesse em uma consultoria, é feito um levantamento com o cliente. Para manter</p><p>manter um relacionamento de longo prazo com os clientes tanto quanto possível, a empresa sempre</p><p>Página 81</p><p>60 2 Identificação do Processo</p><p>tente estabelecer um contrato-quadro com novos clientes durante a admissão. Para existir-</p><p>clientes, não é necessário estabelecer um contrato-quadro. Como outra forma</p><p>de gestão de relacionamento, são realizadas reuniões periódicas com os clientes existentes. Durante</p><p>Nessas reuniões, a organização do cliente é discutida com o cliente. Isso permite</p><p>o cliente deve decidir se trabalho adicional deve ser feito para melhorar ainda mais o</p><p>organização. Ao mesmo tempo, isso permite que a empresa traga atribuições adicionais</p><p>mentos. O recebimento e as reuniões ordinárias acontecem no mesmo formulário, no</p><p>que um inventário dos desejos do cliente pode ser feito.</p><p>Para serviços de consultoria e terceirização, uma equipe de projeto deve ser criada diretamente</p><p>após a atribuição de um projeto à empresa de consultoria. Depois que uma equipe de projeto é</p><p>criado, há uma reunião de lançamento com o cliente e após a reunião de lançamento, o</p><p>projeto é executado. A reunião inicial é a mesma para cada tipo de projeto, mas</p><p>a forma como o projeto é executado difere amplamente por tipo de serviço. No</p><p>final do projeto sempre há uma reunião de avaliação com o cliente como forma de</p><p>controle de qualidade. A criação da equipe do projeto, a reunião de lançamento, a execução</p><p>do projeto e a avaliação do projeto acontecem de acordo com um plano de projeto.</p><p>A consultoria possui um departamento de serviços, que atende o mercado</p><p>pesquisa para os consultores, administra a locação de automóveis</p><p>e fornece secretaria</p><p>Serviços.</p><p>Projete uma arquitetura de processo da seguinte maneira:</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 78/192</p><p>1. identificar os tipos de caso que devem aparecer na arquitetura do processo</p><p>2. identificar as funções que devem aparecer na arquitetura do processo</p><p>3. desenhe uma matriz de caso / função</p><p>4. identificar os processos na matriz de função de caso; dividir processos se e somente se</p><p>uma das diretrizes se aplica e indica qual diretriz você aplicou onde</p><p>2.6 Leitura Adicional</p><p>A importância da identificação explícita de processos foi talvez primeiro discutida por</p><p>Davenport [ 10 ], enquanto uma perspectiva semelhante é oferecida por Hammer & Champy [ 29 ].</p><p>Sharp & McDermott [ 86 ] dão conselhos práticos sobre como explorar a terra do processo</p><p>escapo - um termo alternativo para arquitetura de processo. Outro livro prático cov-</p><p>O projeto de arquitetura de processo ering é aquele de Ould [ 64 ]. Uma das questões deixadas em aberto</p><p>por esses livros é até que ponto vale a pena identificar e delinear processos em um</p><p>maneira específica da empresa, em oposição à adoção de modelos de referência padronizados para</p><p>este propósito.</p><p>Dijkman [ 14 ] fornece uma pesquisa de abordagens populares de arquitetura de processos. 1</p><p>das descobertas desta pesquisa é que os profissionais tendem a aplicar uma mistura de estilos para de-</p><p>rive arquiteturas de processo e que nenhuma abordagem única e popular seja seguida. Apesar de</p><p>o interesse prático no tema, há pouca pesquisa acadêmica na área de</p><p>arquiteturas de processo. As exceções são o trabalho de Frolov et al. [ 20 ] e Zur Muehlen</p><p>et al. [ 112 ]. Ambos os grupos de autores enfatizam a importância de um programa hierárquico</p><p>arquiteturas de cesso. Ainda não está claro até que ponto prescrito, normativo</p><p>as abordagens fornecidas pela academia são aplicáveis e benéficas na prática.</p><p>Página 82</p><p>2.6 Leitura Adicional 61</p><p>O conceito de cadeia de valor - que geralmente aparece no topo de um processo</p><p>arquitetura - foi popularizada por Michael Porter [ 67 ]. Porter também contribuiu para</p><p>popularizando a distinção entre o processo central (que ele chamou de atividade primária</p><p>) e processo de suporte. Um modelo de referência detalhado centrado em torno da noção de</p><p>cadeia de valor é o Modelo de Referência de Valor (VRM) definido pelo Grupo de Cadeia de Valor</p><p>( http://www.value-chain.org/ ).</p><p>Relacionado e até certo ponto complementar ao conceito de cadeia de valor está o</p><p>framework de desempenho organizacional de Rummler & Brache [ 80 ]. Neste quadro-</p><p>trabalho, as organizações são vistas como sistemas cujo propósito é produzir valor dentro</p><p>um determinado ambiente, que inclui concorrentes, fornecedores, mercado de capitais, mão de obra</p><p>mercados, regulamentações e outros fatores externos. Dentro deste ambiente, a organização</p><p>zações criam valor ao adquirir materiais ou recursos de fornecedores, a fim de</p><p>fabricar ou entregar produtos ou serviços para clientes. O valor criado leva</p><p>ao lucro dos acionistas.</p><p>Rummler & Ramias [ 81 ] descrevem uma variante do framework de Rummler & Brache,</p><p>a saber, a Hierarquia de Criação de Valor (VCH). Nesta estrutura, o sistema que</p><p>transforma recursos em produtos ou serviços é chamado de Sistema de Criação de Valor</p><p>(VCS). O VCS é decomposto em subsistemas de processamento, que por sua vez são</p><p>decomposto em processos ponta a ponta e, em seguida, em subprocessos, tarefas e sub</p><p>tarefas. O VCH, portanto, fornece uma estrutura conceitual que vai desde</p><p>o contexto organizacional ao nível mais baixo de uma arquitetura de processo.</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://www.value-chain.org/</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 79/192</p><p>Página 83</p><p>Capítulo 3</p><p>Modelagem de Processo Essencial</p><p>Essencialmente, todos os modelos estão errados, mas alguns são úteis.</p><p>George EP Box (1919–)</p><p>Os modelos de processos de negócios são importantes em vários estágios do ciclo de vida do BPM. Estar-</p><p>antes de começar a modelar um processo, é crucial entender porque estamos modelando</p><p>isto. Os modelos que produzimos terão uma aparência bem diferente, dependendo do motivo para</p><p>modelá-los em primeiro lugar. Existem muitos motivos para modelar um processo.</p><p>O primeiro é simplesmente entender o processo e compartilhar nosso entendimento</p><p>do processo com as pessoas que estão envolvidas no processo diariamente.</p><p>Na verdade, os participantes do processo normalmente executam atividades bastante especializadas em uma</p><p>de tal forma que dificilmente se confrontam com a complexidade de todo o processo.</p><p>Portanto, a modelagem de processos ajuda a compreender melhor o processo e identificar</p><p>e evitar problemas. Este passo para um entendimento completo é o pré-requisito</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 80/192</p><p>para conduzir análise, redesenho ou automação de processos.Neste capítulo, nos familiarizaremos com os ingredientes básicos do processo</p><p>modelagem usando a linguagem BPMN. Com esses conceitos, seremos capazes de pro-</p><p>modelos de processos de negócios duce que capturam relações temporais e lógicas simples</p><p>entre atividades, objetos de dados e recursos. Primeiro, vamos descrever algumas</p><p>conceitos de modelos de processo, nomeadamente como os modelos de processo se relacionam com as instâncias de processo.</p><p>Em seguida, explicaremos os quatro principais blocos estruturais de ramificação e fusão em</p><p>modelos de processo. Estes definem decisões exclusivas, execução paralela, inclusive de</p><p>cisões e repetição. Finalmente, iremos cobrir artefatos de informação e recursos</p><p>envolvidos em um processo.</p><p>3.1 Primeiros Passos com BPMN</p><p>Com mais de 100 símbolos, BPMN é uma linguagem bastante complexa. Mas, como aluno, há</p><p>não há motivo para pânico. Alguns desses símbolos já permitem que você cubra</p><p>muitas de suas necessidades de modelagem. Depois de dominar este subconjunto de BPMN, o</p><p>os símbolos restantes virão naturalmente para você com a prática. Então, em vez de descrever</p><p>ing cada um dos símbolos BPMN detalhadamente, aprenderemos BPMN introduzindo seu</p><p>símbolos e conceitos gradualmente, por meio de exemplos.</p><p>M. Dumas et al., Fundamentals of Business Process Management ,</p><p>DOI 10.1007 / 978-3-642-33143-5_3 , © Springer-Verlag Berlin Heidelberg 2013</p><p>63</p><p>Página 84</p><p>64 3 Modelagem de Processo Essencial</p><p>Fig. 3.1 O diagrama de um processo simples de atendimento de pedidos</p><p>Neste capítulo, nos familiarizaremos com o conjunto básico de símbolos fornecidos por</p><p>BPMN. Conforme afirmado anteriormente, um processo de negócios envolve eventos e atividades . Eventos</p><p>representam coisas que acontecem instantaneamente (por exemplo, uma fatura foi recebida)</p><p>enquanto as atividades representam unidades de trabalho que têm uma duração (por exemplo, uma atividade para</p><p>pagar uma fatura). Além disso, lembramos que em um processo, eventos e atividades são logicamente</p><p>relacionados. A forma mais elementar de relação é a da sequência , o que implica que</p><p>um evento ou atividade A é seguido por outro evento ou atividade B. Consequentemente, o</p><p>os três conceitos mais básicos de BPMN são evento, atividade e arco. Os eventos são representados</p><p>enviados por círculos, atividades por retângulos arredondados e arcos (chamados de fluxos de sequência</p><p>em BPMN) são representados por setas com uma ponta de seta completa.</p><p>Exemplo 3.1 A Figura 3.1 mostra uma sequência simples de atividades modelando um pedido</p><p>processo de cumprimento em BPMN. Este processo começa sempre que um pedido de compra tem</p><p>recebido de um cliente. A primeira atividade realizada é a confirmação do</p><p>ordem. Em seguida, o endereço de envio é recebido para que o produto possa ser enviado para</p><p>o cliente. Posteriormente, a nota fiscal é emitida e assim que o pagamento for recebido</p><p>o pedido é arquivado, completando assim o processo.</p><p>A partir do exemplo acima, notamos que os dois eventos são representados com</p><p>dois</p><p>símbolos ligeiramente diferentes. Usamos círculos com uma borda fina para capturar eventos iniciais</p><p>e círculos com uma borda espessa para capturar eventos finais. Os eventos de início e término têm um</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://dx.doi.org/10.1007/978-3-642-33143-5_3</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 81/192</p><p>papel importante em um modelo de processo: o evento de início indica quando as instâncias doinício do processo, enquanto o evento final indica quando as instâncias são concluídas. Para a prova-</p><p>ple, uma nova instância do processo de atendimento do pedido é acionada sempre que uma compra</p><p>o pedido é recebido e concluído quando o pedido é atendido. Vamos imaginar que</p><p>o processo de atendimento do pedido é realizado em uma organização do vendedor. Todos os dias isso</p><p>organização irá executar uma série de instâncias deste processo, cada instância sendo</p><p>independente dos outros. Depois que uma instância de processo foi gerada, usamos o</p><p>noção de token para identificar o progresso (ou estado ) dessa instância. Tokens são cre-</p><p>atados em um evento de início, fluem por todo o modelo de processo até que sejam destruídos em</p><p>um evento final. Representamos os tokens como pontos coloridos na parte superior de um modelo de processo. Para ex-</p><p>A Fig. 3.2 ampla mostra o estado de três instâncias do processo de atendimento do pedido:</p><p>uma instância acabou de começar (token preto no evento de início), outra está enviando o</p><p>produto (token vermelho na atividade "Enviar produto"), e o terceiro recebeu o</p><p>pagamento e está prestes a iniciar o arquivamento do pedido (token verde no fluxo de sequência</p><p>entre “Receber pagamento” e “Pedido de arquivo”).</p><p>Embora seja natural dar um nome (também chamado de rótulo ) a cada atividade, nós</p><p>não se esqueça de dar rótulos aos eventos também. Por exemplo, dar um nome a</p><p>cada evento de início nos permite comunicar o que dispara uma instância do processo,</p><p>Página 85</p><p>3.1 Primeiros Passos com BPMN 65</p><p>Fig. 3.2 Progresso de três instâncias do processo de atendimento do pedido</p><p>ou seja, quando uma nova instância do processo deve ser iniciada. Da mesma forma, dando</p><p>um rótulo para cada evento final nos permite comunicar quais condições se mantêm quando um</p><p>instância do processo é concluída, ou seja, qual é o resultado do processo.</p><p>Recomendamos as seguintes convenções de nomenclatura. Para atividades, o rótulo deve</p><p>começar com um verbo na forma imperativa seguido por um substantivo, normalmente referindo-se a</p><p>um objeto de negócio, por exemplo, “Aprovar pedido”. O substantivo pode ser precedido por um adjetivo,</p><p>por exemplo, "Emitir carteira de motorista", e o verbo pode ser seguido por um complemento a ex-</p><p>claro como a ação está sendo feita, por exemplo, “Renovar carteira de motorista por meio de agências off-line”.</p><p>No entanto, tentaremos evitar rótulos longos, pois isso pode dificultar a legibilidade do</p><p>modelo. Como regra geral, evitaremos rótulos com mais de cinco palavras, excluindo</p><p>preposições e conjunções. Artigos são normalmente evitados para encurtar rótulos. Para</p><p>eventos, o rótulo deve começar com um substantivo (novamente, isso normalmente seria um</p><p>objeto) e terminar com um verbo na forma de particípio passado, por exemplo, “Fatura emitida”. O verbo</p><p>é um particípio passado para indicar algo que acabou de acontecer. Semelhante a activ-</p><p>rótulos de idade, o substantivo pode ser precedido por um adjetivo, por exemplo, “Envio de pedido urgente”. Nós</p><p>capitalize a primeira palavra dos rótulos de atividade e evento.</p><p>Verbos gerais como "fazer", "fazer", "executar" ou "conduzir" devem ser</p><p>substituído por verbos significativos que capturam as especificidades da atividade que está sendo realizada</p><p>formada ou a ocorrência do evento. Palavras como “processo” ou “ordem” também são ambíguas</p><p>em termos de sua classe gramatical. Ambos podem ser usados como um verbo ("processar", "or-</p><p>der ”) e como um substantivo (“ um processo ”,“ uma ordem ”). Recomendamos usar tais palavras</p><p>consistentemente, apenas em uma classe gramatical, por exemplo, “ordem” sempre como um substantivo.</p><p>Para nomear um modelo de processo, devemos usar um substantivo, potencialmente precedido por um anúncio</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 82/192</p><p>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,</p><p>por exemplo, “cumprir pedido” (a ação principal) torna-se “atendimento de pedido” (a etiqueta do processo).</p><p>Substantivos em forma de hifenização, como "ordem para pagamento" e "aquisição para pagamento", indicando o</p><p>sequência das principais ações no processo, também são possíveis.</p><p>Não colocamos letras maiúsculas na primeira palavra dos nomes dos processos, por exemplo, o "atendimento do pedido"</p><p>processo. Seguindo essas convenções de nomenclatura, manteremos nossos modelos mais</p><p>consistente, torná-los mais fáceis de entender para fins de comunicação e aumentar</p><p>sua reutilização.</p><p>O exemplo na Fig. 3.1 representa uma maneira possível de modelar o atendimento do pedido</p><p>processo de enchimento. No entanto, poderíamos ter produzido um modelo de processo bastante diferente.</p><p>Por exemplo, poderíamos ter negligenciado certas atividades ou expandido em outras</p><p>ers, dependendo da intenção específica de nossa modelagem. A caixa “Um pouco sobre modelagem</p><p>teoria ”reflete sobre as propriedades que sustentam um modelo e as relaciona com as</p><p>caso específico de modelos de processo.</p><p>Página 86</p><p>66 3 Modelagem de Processo Essencial</p><p>UM POUCO SOBRE TEORIA DE MODELAGEM</p><p>Um modelo é caracterizado por três propriedades: mapeamento, abstração e ajuste</p><p>para fins. Primeiro, um modelo implica um mapeamento de um fenômeno do mundo real -</p><p>o assunto de modelagem. Por exemplo, um edifício residencial a ser construído</p><p>poderia ser modelado por meio de uma miniatura de madeira. Em segundo lugar, um modelo apenas documenta</p><p>aspectos relevantes do assunto, ou seja, abstrai de certos detalhes que são irrelevantes</p><p>relevante. O modelo de madeira do edifício abstrai claramente dos materiais</p><p>o edifício será construído. Terceiro, um modelo serve a um propósito particular</p><p>pose , que determina os aspectos da realidade a omitir ao criar um modelo.</p><p>Sem um propósito específico, não teríamos indicação sobre o que omitir.</p><p>Considere o modelo de madeira novamente. Ele serve ao propósito de ilustrar como o</p><p>edifício será semelhante. Assim, ele negligencia aspectos que são irrelevantes para o julgamento</p><p>a aparência, como o sistema elétrico do edifício. Então, podemos dizer que um</p><p>modelo é um meio de abstrair de um determinado assunto com a intenção de capturar</p><p>aspectos específicos do assunto.</p><p>Fig. 3.3 Um edifício ( a ), sua miniatura de madeira ( b ) e sua planta ( c ). (( b ): © 2010, Bree</p><p>Indústrias; ( c ): usado com permissão de planetclaire.org)</p><p>Uma maneira de determinar o propósito de um modelo é entender o auto-alvo</p><p>ciência do modelo. No caso do modelo de madeira, o público-alvo poderia</p><p>ser um potencial comprador do edifício. Assim, é importante focar no ap-</p><p>perância do edifício, ao invés dos detalhes técnicos da construção.</p><p>Por outro lado, o modelo de madeira seria de pouca utilidade para um engenheiro que</p><p>tem que projetar o sistema elétrico. Neste caso, uma planta do edifício</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://planetclaire.org</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 83/192</p><p>seria mais apropriado.</p><p>Assim, ao modelar um processo de negócios, precisamos ter em mente o</p><p>propósito específico e público-alvo para o qual estamos criando o modelo.</p><p>Existem dois objetivos principais para a modelagem de processos: projeto organizacional</p><p>e design de sistema de aplicação . Modelos de processos para design organizacional são</p><p>orientada</p><p>para os negócios . Eles são construídos por analistas de processo e usados principalmente para</p><p>compreensão e comunicação, mas também para benchmarking e melhoria</p><p>mento. Como tal, eles precisam ser intuitivos o suficiente para serem compreendidos pelo</p><p>várias partes interessadas e normalmente abstrairão dos aspectos relacionados à TI. o</p><p>o público-alvo inclui gerentes, proprietários de processos e analistas de negócios. Pró-</p><p>modelos de acesso para design de sistema de aplicativo são orientados para TI . Eles são construídos por</p><p>Página 87</p><p>3.2 Ramificação e fusão 67</p><p>engenheiros e desenvolvedores de sistema e usados para automação. Assim, eles devem</p><p>conter detalhes de implementação, a fim de ser implantado em um BPMS, ou usado como</p><p>projetos para desenvolvimento de software.</p><p>Neste e no próximo capítulo, vamos nos concentrar no orientado a negócios</p><p>modelos de cesso. No cap. 9 aprenderemos como transformar esses modelos de processo em execução</p><p>cortável.</p><p>3.2 Ramificação e fusão</p><p>Atividades e eventos podem não ser necessariamente realizados sequencialmente. Por exemplo,</p><p>no contexto de um processo de tratamento de reivindicações, a aprovação e a rejeição de uma reivindicação</p><p>são duas atividades que se excluem. Portanto, essas atividades não podem ser realizadas</p><p>em sequência, já que uma instância desse processo executará qualquer uma dessas atividades.</p><p>Quando duas ou mais atividades são alternativas uma à outra, dizemos que são mutuamente</p><p>exclusivo .</p><p>Vamos considerar outra situação. No processo de tratamento de reclamações, uma vez que a reclamação</p><p>aprovado, o reclamante é notificado e o desembolso é feito. Notifi-</p><p>cação e desembolso são duas atividades que são normalmente realizadas por dois</p><p>unidades de negócios diferentes, portanto, são independentes umas das outras e, como tal,</p><p>não precisam ser realizados em sequência: eles podem ser realizados em paralelo, ou seja, em</p><p>o mesmo tempo. Quando duas ou mais atividades não são interdependentes, elas são concorrentes</p><p>alugar .</p><p>Para modelar esses comportamentos, precisamos introduzir a noção de gateway . O termo</p><p>gateway implica que existe um mecanismo de bloqueio que permite ou proíbe</p><p>passagem de tokens pelo gateway. À medida que os tokens chegam a um gateway, eles podem ser</p><p>mesclados na entrada ou separados na saída dependendo do tipo de gateway.</p><p>Descrevemos os gateways como diamantes e os distinguimos entre divisões e junções.</p><p>Um gateway dividido representa um ponto onde o fluxo do processo diverge enquanto uma junção</p><p>gateway representa um ponto onde o fluxo do processo converge. As divisões têm uma incom-</p><p>fluxo de sequência de ing e múltiplos fluxos de sequência de saída (representando os ramos</p><p>que divergem), enquanto as junções têm vários fluxos de sequência de entrada (representando o</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 84/192</p><p>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.</p><p>3.2.1 Decisões Exclusivas</p><p>Para modelar a relação entre duas ou mais atividades alternativas, como no caso</p><p>da aprovação ou rejeição de uma reivindicação, usamos uma divisão exclusiva ( XOR ) . Nós usamos um</p><p>XOR-join para fundir duas ou mais ramificações alternativas que podem ter sido anteriormente</p><p>Página 88</p><p>68 3 Modelagem de Processo Essencial</p><p>Fig. 3.4 Um exemplo do uso de gateways XOR</p><p>bifurcada com uma divisão XOR. Um gateway XOR é indicado com um losango vazio</p><p>ou com um diamante marcado com um “X”. De agora em diante, sempre usaremos o “X”</p><p>marcador.</p><p>Exemplo 3.2 Processo de verificação de faturas.</p><p>Assim que uma fatura é recebida de um cliente, é necessário verificar se há incompatibilidades.</p><p>A verificação pode resultar em uma destas três opções: i) não há incompatibilidades, nas quais</p><p>caso a fatura seja lançada; ii) existem incompatibilidades, mas podem ser corrigidas, nas quais</p><p>caso a fatura seja reenviada ao cliente; e iii) há incompatibilidades, mas não podem</p><p>ser corrigido, caso em que a fatura é bloqueada. Uma vez que uma dessas três atividades é</p><p>realizada a nota fiscal é estacionada e o processo é concluído.</p><p>Para modelar este processo, começamos com uma atividade de decisão, nomeadamente “Verificar fatura</p><p>para incompatibilidades ”após um evento inicial“ Fatura recebida ”. Uma atividade de decisão é</p><p>uma atividade que leva a resultados diferentes. Em nosso exemplo, esta atividade resulta</p><p>em três resultados possíveis, que são mutuamente exclusivos; então precisamos usar um</p><p>O XOR é dividido após essa atividade para dividir o fluxo em três ramos. Assim, três</p><p>fluxos de sequência emanarão deste gateway, um para a atividade "Pós-fatura",</p><p>realizada se não houver incompatibilidades, outra no sentido de “Reenviar fatura para</p><p>cliente ”, realizada se houver incompatibilidades, mas puderem ser corrigidas, e um terceiro fluxo</p><p>para "Bloquear fatura", realizado se houver incompatibilidades que não podem ser corrigidas</p><p>(ver Fig. 3.4 ). De uma perspectiva de token, uma divisão XOR roteia o token vindo de</p><p>sua ramificação de entrada para uma de suas ramificações de saída, ou seja, apenas uma de saída</p><p>ramo pode ser tomado.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 85/192</p><p>Ao usar uma divisão XOR, certifique-se de que cada fluxo de sequência de saída seja anotado</p><p>com um rótulo que captura a condição em que aquele ramo específico é obtido. Mais-</p><p>over, sempre use condições mutuamente exclusivas, ou seja, apenas uma delas pode ser verdadeira</p><p>toda vez que a divisão XOR é alcançada por um token. Esta é a característica do</p><p>Gateway dividido em XOR. Em nosso exemplo, uma fatura pode estar correta ou conter erros</p><p>correspondências que podem ser corrigidas ou incompatibilidades que não podem ser corrigidas: apenas uma dessas</p><p>as condições são verdadeiras por fatura recebida.</p><p>Página 89</p><p>3.2 Ramificação e fusão 69</p><p>Na Fig. 3.4, o fluxo rotulado como "incompatibilidades existem, mas não podem ser corrigidas" está marcado</p><p>com um corte oblíquo. Esta notação é opcional e é usada para indicar o padrão</p><p>fluxo , ou seja, o fluxo que será levado pelo token proveniente da divisão XOR em</p><p>caso as condições associadas a todos os outros fluxos de saída sejam avaliadas como falsas. Desde a</p><p>este arco tem o significado de caso contrário , pode ser deixado sem rótulo. No entanto, nós altamente</p><p>recomendo ainda rotular este arco com uma condição para fins de legibilidade.</p><p>Uma vez que qualquer uma das três atividades alternativas tenha sido executada, nós mesclamos o</p><p>fluxo de volta para executar a atividade "fatura de parque" que é comum a todos os três</p><p>casos. Para isso, usamos um XOR-join. Este gateway particular atua como um passthrough ,</p><p>o que significa que ele espera um token chegar de um de seus arcos de entrada e assim que</p><p>ele recebe o token, ele envia o token para o arco de saída. Em outras palavras, com um</p><p>O XOR-join continua sempre que um branch de entrada é concluído.</p><p>Voltando ao nosso exemplo, completamos o modelo de processo com um evento final</p><p>“Fatura tratada”. Certifique-se de sempre completar um modelo de processo com uma extremidade</p><p>evento, mesmo que seja óbvio como o processo seria concluído.</p><p>Exercício 3.1 Modelar o seguinte fragmento de um processo de negócios para avaliar empréstimos</p><p>formulários.</p><p>Uma vez que um pedido de empréstimo tenha sido aprovado pelo provedor de empréstimo, um pacote de aceitação é</p><p>preparada e enviada ao cliente. O pacote de aceitação inclui um cronograma de reembolso</p><p>com o qual o cliente deve concordar, enviando os documentos assinados de volta para o empréstimo</p><p>fornecedor. Este, então, verifica o acordo de reembolso: se o requerente discordou</p><p>o cronograma de reembolso, o credor cancela o pedido; se o requerente concordou,</p><p>o provedor de empréstimo aprova o pedido. Em qualquer caso, o processo é concluído com o</p><p>credor notificando o requerente sobre o status do pedido.</p><p>3.2.2 Execução Paralela</p><p>Quando duas ou mais atividades não têm nenhuma</p><p>dependência de ordem uma da outra</p><p>(ou seja, uma atividade não precisa seguir a outra, nem exclui a outra) eles</p><p>pode ser executado simultaneamente ou em paralelo . O gateway paralelo ( AND ) é usado para</p><p>modelar esta relação particular. Especificamente, usamos uma divisão AND para modelar o paralelo</p><p>execução de duas ou mais ramificações e uma junção AND para sincronizar a execução</p><p>de dois ou mais ramos paralelos. Um gateway AND é representado como um diamante com um</p><p>Marca “+”.</p><p>Exemplo 3.3 Verificação de segurança no aeroporto.</p><p>Assim que o cartão de embarque for recebido, os passageiros passam para a verificação de segurança. Aqui</p><p>eles precisam passar pela triagem de segurança pessoal e pela triagem de bagagem. Mais tarde,</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 86/192</p><p>eles podem prosseguir para o nível de partida.</p><p>Este processo consiste em quatro atividades. Começa com a atividade “Proceder à segurança</p><p>verifique ”e termina com a atividade“ Continuar para o nível de partida ”. Essas duas atividades</p><p>têm uma dependência de ordem clara: um passageiro só pode ir para o nível de embarque após</p><p>Página 90</p><p>70 3 Modelagem de Processo Essencial</p><p>Fig. 3.5 Um exemplo do uso de gateways AND</p><p>submetidos às verificações de segurança exigidas. Depois da primeira atividade e antes da última</p><p>um, precisamos realizar duas atividades que podem ser executadas em qualquer ordem, ou seja, quais</p><p>não dependem um do outro: “Passe na triagem de segurança pessoal” e “Passe bagagem</p><p>triagem". Para modelar esta situação, usamos uma atividade de link dividido AND “Continuar</p><p>para verificação de segurança "com as duas atividades de triagem, e um AND-join ligando o</p><p>duas atividades de triagem com a atividade “Prosseguir para o nível de partida” (ver Fig. 3.5 ).</p><p>A divisão AND divide o token proveniente da atividade “Prosseguir para a verificação de segurança”</p><p>em dois tokens. Cada um desses tokens flui independentemente por um dos dois</p><p>ramos. Isso significa que quando alcançamos uma divisão AND, pegamos todos os</p><p>ramos (observe que uma divisão AND pode ter vários arcos de saída). Como dissemos</p><p>antes, um token é usado para indicar o estado de uma determinada instância. Quando múltiplo para</p><p>kens da mesma cor são distribuídos em um modelo de processo, por exemplo, como resultado de</p><p>executando uma divisão AND, eles representam coletivamente o estado de uma instância. Para ex-</p><p>amplo, se um token estiver no arco, emitindo a partir da atividade "Passe na triagem de bagagem" e</p><p>outro token da mesma cor está no incidente do arco para a atividade “Passe pessoal</p><p>triagem de segurança ”, isso indica uma instância do processo de verificação de segurança onde</p><p>um passageiro acabou de passar pela triagem de bagagem, mas ainda não começou o pessoal</p><p>rastreio de segurança.</p><p>A junção AND do nosso exemplo espera que um token chegue de cada um dos dois</p><p>arcos de entrada e, quando todos estiverem disponíveis, ele mescla os tokens novamente em um.</p><p>O token único é então enviado para a atividade “Continuar para o nível de partida”. Isso significa que</p><p>prosseguimos quando todas as filiais de entrada foram concluídas (observe novamente que um AND-</p><p>junção pode ter vários arcos de entrada). Este comportamento de esperar por uma série de</p><p>tokens para chegar e depois mesclar os tokens em um é chamado de sincronização .</p><p>Exemplo 3.4 Vamos estender o exemplo de atendimento do pedido da Fig. 3.1 , assumindo</p><p>que um pedido de compra só é confirmado se o produto estiver em estoque, caso contrário, o pro-</p><p>cess é concluído rejeitando o pedido. Além disso, se o pedido for confirmado, o envio</p><p>endereço é recebido e o produto solicitado é enviado enquanto a fatura é emitida-</p><p>ted e o pagamento é recebido. Depois disso, o pedido é arquivado e o processo</p><p>completa.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 87/192</p><p>O modelo resultante é mostrado na Fig. 3.6 . Deixe-nos fazer algumas observações. Primeiro,</p><p>este modelo tem duas atividades que são mutuamente exclusivas: “Confirmar pedido” e “Re-</p><p>Página 91</p><p>3.2 Ramificação e fusão 71</p><p>Fig. 3.6 Uma versão mais elaborada do diagrama do processo de atendimento do pedido</p><p>ordem exata ”, portanto, nós os precedemos com uma divisão XOR (lembre-se de colocar uma atividade</p><p>antes de uma divisão XOR para permitir que a decisão seja tomada, como uma verificação como esta</p><p>caso, ou uma aprovação). Em segundo lugar, as duas sequências “Obter endereço de envio” - “Enviar</p><p>produto ”e“ Emitir fatura ”-“ Receber pagamento ”pode ser realizado de forma independente</p><p>uns dos outros, então os colocamos em um bloco entre uma divisão AND e uma junção AND. No</p><p>Na verdade, esses dois conjuntos de atividades são normalmente tratados por diferentes recursos dentro</p><p>uma organização de vendedores, como um balconista de vendas para a remessa e um diretor financeiro para</p><p>a fatura e, portanto, pode ser executado em paralelo (observe a palavra "entretanto" no</p><p>descrição do processo, que indica que duas ou mais atividades podem ser realizadas em</p><p>o mesmo tempo).</p><p>Vamos comparar esta nova versão do processo de atendimento de pedidos com aquela em</p><p>Fig. 3.1 em termos de eventos. A nova versão apresenta dois eventos finais, enquanto o primeiro</p><p>versão apresenta um evento final. Em um modelo BPMN, podemos ter vários eventos finais,</p><p>cada um capturando um resultado diferente do processo (por exemplo, saldo pago vs. atraso</p><p>processado, pedido aprovado vs. pedido rejeitado). BPMN adota o chamado ter- implícito</p><p>semântica de minação , o que significa que uma instância de processo é concluída apenas quando cada uma</p><p>ken fluindo no modelo atinge um evento final. Da mesma forma, podemos ter vários</p><p>eventos em um modelo BPMN, cada evento capturando um gatilho diferente para iniciar um processo</p><p>instância. Por exemplo, podemos iniciar nosso processo de atendimento de pedidos quando um novo</p><p>o pedido de compra é recebido ou quando um pedido revisado é reenviado. Se um pedido revisado</p><p>for reenviado, primeiro recuperamos os detalhes do pedido do banco de dados de pedidos e, em seguida,</p><p>continue com o resto do processo. Esta variante do modelo de atendimento do pedido é</p><p>mostrado na Fig. 3.7 . Uma instância deste modelo de processo é acionada pelo primeiro evento</p><p>que ocorre (observe o uso de uma junção XOR para mesclar os ramos vindos do</p><p>dois eventos iniciais).</p><p>Exercício 3.2 Modelar o seguinte fragmento de um processo de negócios para avaliar empréstimos</p><p>formulários.</p><p>Um pedido de empréstimo é aprovado se passar por duas verificações: (i) a avaliação de risco de empréstimo do requerente-</p><p>avaliação, feita automaticamente por um sistema, e (ii) a avaliação da propriedade para a qual o</p><p>foi solicitado um empréstimo, realizado por um avaliador imobiliário. A avaliação de risco requer um</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 88/192</p><p>Página 92</p><p>72 3 Modelagem de Processo Essencial</p><p>Fig. 3.7 Uma variante do processo de atendimento do pedido com dois gatilhos diferentes</p><p>verificação do histórico de crédito do requerente, realizada por um diretor financeiro. Uma vez que ambos</p><p>a avaliação do risco do empréstimo e a avaliação da propriedade foram realizadas, um oficial de crédito pode</p><p>avaliar a elegibilidade do candidato. Se o candidato não for elegível, o pedido é rejeitado,</p><p>caso contrário, o pacote de aceitação é preparado e enviado ao requerente.</p><p>Existem duas situações em que um gateway pode ser omitido. Um XOR-join pode ser</p><p>omitido antes de uma atividade ou evento. Neste caso, os arcos de entrada para o XOR-join</p><p>estão diretamente conectados à atividade / evento. Um exemplo desta notação abreviada</p><p>é mostrado na Fig. 1.6 , onde há dois arcos incidentes para a atividade “Selecionar adequado</p><p>equipamento". Uma divisão AND também pode ser omitida quando segue uma atividade ou evento.</p><p>Neste caso, os arcos de saída da divisão AND emanam diretamente do ativo</p><p>ity / event.</p><p>3.2.3 Decisões Inclusivas</p><p>Às</p><p>vezes, podemos precisar tomar um ou mais ramos após uma atividade de decisão.</p><p>Considere o seguinte processo de negócios.</p><p>Exemplo 3.5 Processo de distribuição de pedidos.</p><p>Uma empresa possui dois depósitos que armazenam produtos diferentes: Amsterdã e Hamburgo.</p><p>Quando um pedido é recebido, ele é distribuído entre esses depósitos: se algum dos</p><p>os produtos são mantidos em Amsterdã, um pedido secundário é enviado para lá; da mesma forma, se algum relevante</p><p>os produtos são mantidos em Hamburgo, um pedido secundário é enviado para lá. Depois, o pedido é</p><p>registrado e o processo é concluído.</p><p>Podemos modelar o cenário acima usando uma combinação de AND e porta XOR</p><p>maneiras? A resposta é sim. No entanto, existem alguns problemas. Figuras 3.8 e 3.9</p><p>mostram duas soluções possíveis. No primeiro, usamos um XOR-split com três alter-</p><p>ramos nativos: um obtido se o pedido contiver apenas produtos de Amsterdã (onde</p><p>o sub-pedido é encaminhado para o depósito de Amsterdã), outro levado se o pedido</p><p>contém apenas produtos de Hamburgo (da mesma forma, neste ramo o pedido secundário é encaminhado</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 89/192</p><p>Página 93</p><p>3.2 Ramificação e fusão 73</p><p>Fig. 3.8 Modelando uma decisão inclusiva: primeiro ensaio</p><p>Fig. 3.9 Modelando uma decisão inclusiva: segundo ensaio</p><p>para o armazém de Hamburgo), e uma terceira filial a ser tomada no caso de o pedido con</p><p>contém produtos de ambos os armazéns (neste caso, os pedidos secundários são encaminhados para</p><p>ambos os armazéns). Esses três ramos convergem em uma junção XOR que leva a</p><p>o registo da encomenda.</p><p>Embora este modelo capture nosso cenário corretamente, o diagrama resultante é</p><p>o que é complicado, já que precisamos duplicar as duas atividades que encaminham</p><p>encomendas aos respectivos armazéns duas vezes. E se tivéssemos mais de dois armazéns,</p><p>o número de atividades duplicadas aumentaria. Por exemplo, se tivéssemos três</p><p>armazéns, precisaríamos de um XOR-split com sete filiais de saída, e cada</p><p>a atividade precisaria ser duplicada quatro vezes. Claramente, esta solução não é escala</p><p>capaz.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 90/192</p><p>Página 94</p><p>74 3 Modelagem de Processo Essencial</p><p>Fig. 3.10 Modelando uma decisão inclusiva com o gateway OR</p><p>Na segunda solução, usamos uma divisão AND com dois arcos de saída, cada</p><p>dos quais leva a uma divisão XOR com duas ramificações alternativas. Um está ocupado</p><p>se o pedido contém produtos de Amsterdã (Hamburgo), caso em que um ac-</p><p>a atividade é executada para encaminhar o sub-pedido para o respectivo armazém; a</p><p>outra filial é tomada se o pedido não contiver Amsterdam (Hamburgo)</p><p>produtos, caso em que nada é feito até o XOR-join, que funde</p><p>os dois ramos de volta. Em seguida, uma junção AND mescla os dois ramos paralelos</p><p>saindo da divisão AND e o processo é concluído registrando o ou-</p><p>der.</p><p>Qual é o problema com esta segunda solução? O cenário de exemplo permite</p><p>três casos: os produtos estão apenas em Amsterdã, apenas em Hamburgo ou em ambos os armazéns</p><p>casas, enquanto esta solução permite mais um caso, ou seja, quando os produtos estão em</p><p>nenhum dos armazéns. Este caso ocorre quando os dois ramos vazios do</p><p>duas divisões XOR são tomadas e resulta em não fazer nada entre a atividade "Verificar ou</p><p>itens de linha ”e atividade“ Registrar pedido ”. Daí esta solução, apesar de ser mais</p><p>compacto do que o primeiro, está errado.</p><p>Para modelar situações onde uma decisão pode levar a uma ou mais opções ser-</p><p>tomadas ao mesmo tempo, precisamos usar um gateway dividido inclusivo ( OR ) . A</p><p>A divisão OR é semelhante à divisão XOR, mas as condições em seus ramos de saída</p><p>não precisam ser mutuamente exclusivos, ou seja, mais de um deles pode ser verdadeiro</p><p>ao mesmo tempo. Quando encontramos uma divisão OR, pegamos um ou mais</p><p>ramos dependendo de quais condições são verdadeiras. Em termos de semântica de token</p><p>tiques, isso significa que a divisão OR pega o token de entrada e gera um número</p><p>número de tokens equivalentes ao número de condições de saída verdadeiras, onde</p><p>este número pode ser pelo menos um e no máximo como o número total de saídas</p><p>ramos. Semelhante ao gateway XOR-split, um OR-split também pode ser equipado</p><p>com um fluxo padrão, que é obtido apenas quando todas as outras condições avaliam</p><p>falso.</p><p>A Figura 3.10 mostra a solução para nosso exemplo usando o gateway OR. Depois de</p><p>o sub-pedido foi encaminhado para qualquer um dos dois armazéns ou para ambos, usamos</p><p>uma junção OR para sincronizar o fluxo e continuar com o registro do pedido.</p><p>Uma junção OR continua quando todas as ramificações de entrada ativas forem concluídas. Esperando</p><p>para um ramal ativo significa esperar por um ramal de entrada que acabará destruindo</p><p>Página 95</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 91/192</p><p>3.2 Ramificação e fusão 75</p><p>Fig. 3.11 Que tipo o gateway de junção deve ter para que as instâncias deste processo possam ser concluídas</p><p>corretamente?</p><p>fígado um token para a junção OR. Se a ramificação estiver ativa, a junção OR irá esperar por isso</p><p>token, caso contrário, não. Depois que todos os tokens de ramos ativos chegaram, o</p><p>A junção OR sincroniza esses tokens em um (semelhante ao que uma junção AND faz)</p><p>e envia esse token para seu arco de saída. Chamamos esse comportamento de sincronização de mesclagem</p><p>em oposição à simples mesclagem do XOR-join e à sincronização do</p><p>AND-join.</p><p>Vamos nos aprofundar no conceito de ramo ativo. Considere o modelo na Fig. 3.11 ,</p><p>que apresenta um gateway de junção com tipo indefinido (aquele acinzentado com uma pergunta</p><p>marca de indicação). Que tipo devemos atribuir a esta junção? Vamos tentar uma junção AND para</p><p>corresponder à divisão AND anterior. Lembramos que uma junção AND aguarda um token para ar-</p><p>rive de cada filial de entrada. Enquanto o token da filial com atividade “C”</p><p>sempre chegará, o token da filial com atividades "B" e "D" não pode</p><p>chegam se forem roteados para “E” pelo XOR-split. Portanto, se a atividade "D" não for executada,</p><p>a junção AND esperará indefinidamente por esse token, com a consequência de que o</p><p>a instância do processo não poderá progredir mais. Esta anomalia comportamental</p><p>é chamado de deadlock e deve ser evitado.</p><p>Vamos tentar um XOR-join. Lembramos que o XOR-join funciona como um passthrough</p><p>encaminhando para sua ramificação de saída cada token que chega por meio de um de seus</p><p>ramos. Em nosso exemplo, isso significa que podemos executar a atividade "F" uma ou duas vezes,</p><p>dependendo se a divisão XOR anterior direciona o token para "E" (neste caso, "F"</p><p>é executado uma vez) ou para “D” (“F” é executado duas vezes). Embora esta solução possa funcionar,</p><p>temos o problema de não saber se a atividade "F" será executada</p><p>uma ou duas vezes, e talvez não queiramos executá-lo duas vezes. Além disso, se este</p><p>é o caso, sinalizaríamos que o processo foi concluído duas vezes, já que o final</p><p>o evento seguinte a “F” receberá dois tokens. E isso, novamente, é algo que queremos</p><p>evitar.</p><p>Página 96</p><p>76 3 Modelagem de Processo Essencial</p><p>O único tipo de junção que falta tentar é a junção OR. Uma junção OR irá esperar por todos os</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 92/192</p><p>ramos ativos para concluir. Se as rotas XOR-split controlam para “E”, a junção OR irá</p><p>não espere por um token da atividade de rolamento de ramificação “D”, pois isso nunca chegará.</p><p>Portanto, ele continuará assim que o token da atividade “C” chegar. Por outro lado, se</p><p>as rotas XOR-split controlam para “D”, a junção OR irá esperar que um token também chegue</p><p>deste ramo, e uma vez que os dois tokens chegaram, ele irá mesclá-los em um e</p><p>envie este token, para que "F" possa ser executado uma vez e o processo possa ser concluído</p><p>normalmente.</p><p>Pergunta Quando devemos usar uma junção OR?</p><p>Uma vez que a semântica de junção OR não é simples, a presença deste elemento</p><p>em um</p><p>modelo pode confundir o leitor. Assim, sugerimos usá-lo apenas quando for estritamente</p><p>requeridos. Claramente, é fácil ver que uma junção OR deve ser usada sempre que precisarmos</p><p>para sincronizar o controle de uma divisão OR anterior. Da mesma forma, devemos usar um AND-</p><p>junte para sincronizar o controle de uma divisão AND anterior e uma junção XOR para mesclar</p><p>um conjunto de ramificações que são mutuamente exclusivas. Em outros casos, o modelo não terá</p><p>uma estrutura enxuta como os exemplos na Fig. 3.8 ou 3.10 , onde o modelo é composto de</p><p>blocos aninhados, cada um delimitado por uma divisão e uma junção do mesmo tipo. O modelo pode</p><p>em vez disso, parecido com o da Fig. 3.11 , onde pode haver pontos de entrada ou existem pontos</p><p>de uma estrutura de bloco. Nestes casos, jogue o jogo do token para entender o correto</p><p>tipo de junção. Comece com uma junção XOR; em seguida, tente uma junção AND e se ambos os gateways liderarem</p><p>para modelos incorretos use a junção OR que funcionará com certeza.</p><p>Agora que aprendemos os três principais gateways, vamos usá-los para estender</p><p>o processo de atendimento do pedido. Suponha que se o produto não estiver em estoque, ele pode ser</p><p>fabricado. Desta forma, um pedido nunca pode ser rejeitado.</p><p>Exemplo 3.6</p><p>Se o produto solicitado não estiver em estoque, ele precisa ser fabricado antes do processamento do pedido</p><p>pode continuar. Para fabricar um produto, as matérias-primas necessárias devem ser solicitadas. Dois</p><p>fornecedores preferidos fornecem diferentes tipos de matéria-prima. Dependendo do produto para</p><p>ser fabricados, as matérias-primas podem ser encomendadas do Fornecedor 1 ou do Fornecedor 2, ou</p><p>de ambos. Assim que as matérias-primas estiverem disponíveis, o produto pode ser fabricado e o</p><p>pedido pode ser confirmado. Por outro lado, se o produto estiver em estoque, ele é recuperado do</p><p>armazém antes de confirmar o pedido. Então, o processo continua normalmente.</p><p>O modelo para este processo de atendimento de pedido estendido é mostrado na Fig. 3.12 .</p><p>Exercício 3.3 Modelar o seguinte fragmento de um processo de negócios para avaliar empréstimos</p><p>formulários.</p><p>Um pedido de empréstimo pode ser acoplado a um seguro residencial que é oferecido com desconto</p><p>preços. O requerente pode expressar seu interesse em um plano de seguro residencial no momento de</p><p>submeter seu pedido de empréstimo ao credor. Com base nessas informações, se o</p><p>pedido de empréstimo for aprovado, o provedor de empréstimo pode apenas enviar um pacote de aceitação</p><p>ao requerente, ou envie também uma cotação de seguro residencial. O processo então continua com o</p><p>verificação do acordo de reembolso.</p><p>Página 97</p><p>3.2 Ramificação e fusão 77</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 93/192</p><p>Fig. 3.12 O diagrama do processo de atendimento do pedido com a fabricação do produto</p><p>3.2.4 Retrabalho e Repetição</p><p>Até agora vimos estruturas que são lineares, ou seja, cada atividade é realizada no máximo</p><p>uma vez. No entanto, às vezes podemos exigir a repetição de uma ou várias atividades, para</p><p>instância devido a uma falha na verificação.</p><p>Exemplo 3.7</p><p>No gabinete do ministro da Fazenda, uma vez recebido um inquérito ministerial, é o primeiro</p><p>registrado no sistema. Em seguida, o inquérito é investigado para que uma resposta ministerial</p><p>pode ser preparado. A finalização de uma resposta inclui a preparação da resposta</p><p>pelo oficial de gabinete e a revisão da resposta pelo registrador principal. Se o</p><p>o registrador não aprova a resposta, esta última precisa ser preparada novamente pelo gabinete</p><p>oficial para revisão. O processo termina apenas quando a resposta é aprovada.</p><p>Para modelar retrabalho ou repetição, primeiro precisamos identificar as atividades, ou mais</p><p>em geral o fragmento do processo, que pode ser repetido. Em nosso exemplo este</p><p>consiste na sequência de atividades “Preparar a resposta ministerial” e “Rever</p><p>resposta ministerial ”. Chamemos isso de nosso bloco de repetição . A propriedade de uma repetição</p><p>bloco de decisão é que a última de suas atividades deve ser uma atividade de decisão. Na verdade, isso vai</p><p>nos permitem decidir se devemos voltar antes do início do bloco de repetição, de modo que este</p><p>pode ser repetido ou para continuar com o resto do processo. Como tal, esta decisão</p><p>atividade deve ter dois resultados. Em nosso exemplo, a atividade de decisão é “Revisar</p><p>resposta ministerial ”e seus resultados são:“ resposta aprovada ”(neste caso, nós</p><p>continuar com o processo) e “resposta não aprovada” (voltamos). Modelar</p><p>esses dois resultados, usamos uma divisão XOR com dois ramos de saída: um que</p><p>nos permite continuar com o resto do processo (em nosso exemplo, isso é simplesmente</p><p>Página 98</p><p>78 3 Modelagem de Processo Essencial</p><p>Fig. 3.13 Um modelo de processo para lidar com correspondência ministerial</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 94/192</p><p>o evento final "correspondência ministerial endereçada"), o outro que volta</p><p>antes da atividade “Preparar a resposta ministerial”. Usamos um XOR-join para reconectar</p><p>esta ramificação para o ponto do modelo de processo imediatamente antes do bloco de repetição. o</p><p>modelo para nosso exemplo é ilustrado na Fig. 3.13 .</p><p>Questão Por que precisamos mesclar o ramo de loopback de um bloco de repetição com</p><p>um XOR-join?</p><p>A razão para usar um XOR-join é que este gateway tem uma semântica muito simples</p><p>tiques: ele move qualquer token que recebe em seu arco de entrada para seu arco de saída, que é o que</p><p>precisamos neste caso. Na verdade, se fundíssemos o branch de loopback com o resto do</p><p>modelo usando uma junção AND, entraríamos em conflito, uma vez que este gateway tentaria sincronizar</p><p>cronizar os dois ramos de entrada quando sabemos que apenas um deles pode ser</p><p>ativo por vez: se estivéssemos em loop, receberíamos o token do loopback</p><p>ramo; caso contrário, receberíamos de outro ramo, indicando que estamos</p><p>entrar no bloco de repetição pela primeira vez. Uma junção OR funcionaria, mas é um</p><p>exagero, pois sabemos que apenas um ramo estará ativo por vez.</p><p>Exercício 3.4 Modelar o seguinte fragmento de um processo de negócios para avaliar empréstimos</p><p>formulários.</p><p>Uma vez que um pedido de empréstimo é recebido pelo provedor de empréstimo, e antes de prosseguir com sua</p><p>avaliação, o próprio aplicativo precisa ser verificado quanto à integridade. Se o aplicativo for</p><p>incompleto, ele é devolvido ao requerente, para que ele possa preencher as informações em falta</p><p>e envie-o de volta para o provedor de empréstimo. Este processo é repetido até que o aplicativo seja encontrado</p><p>completo.</p><p>Aprendemos como combinar atividades, eventos e gateways para modelar o básico</p><p>processos de negócios. Para cada um desses elementos, mostramos sua representação gráfica</p><p>ção, as regras para combiná-lo com outros elementos de modelagem e explicou seu</p><p>comportamento em termos de regras de token. Todos esses aspectos se enquadram no termo componentes de</p><p>uma linguagem de modelagem . Se você quiser saber mais sobre este tópico, você pode ler o</p><p>box “Componentes de uma linguagem de modelagem”.</p><p>COMPONENTES DE UMA LINGUAGEM DE MODELAGEM</p><p>Uma linguagem de modelagem consiste em três partes: sintaxe, semântica e notação.</p><p>A sintaxe fornece um conjunto de elementos de modelagem e um conjunto de regras para governar</p><p>Página 99</p><p>3.3 Artefatos de informação 79</p><p>como esses elementos podem ser combinados. A semântica vincula o elemento sintático</p><p>mentos e suas descrições textuais para um significado preciso. A notação define</p><p>um conjunto de símbolos gráficos para a visualização dos elementos.</p><p>Por exemplo, a sintaxe BPMN inclui atividades, eventos, gateways e</p><p>fluxos de sequência. Um exemplo de regra sintática é que os eventos de início têm apenas</p><p>fluxos de sequência de saída, enquanto eventos finais só têm sequência de entrada</p><p>fluxos. A semântica BPMN descreve que tipo de comportamento é representado</p><p>pelos vários elementos. Em essência, isso se relaciona com a questão de como o elemento</p><p>13/08/2020</p><p>Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 95/192</p><p>mentos podem ser executados em termos de fluxo de token. Por exemplo, uma junção AND tem</p><p>esperar que todas as ramificações de entrada sejam concluídas antes de passar o controle para seu</p><p>filial de saída. Um exemplo de notação BPMN é o uso de rotulados arredondados</p><p>caixas para representar atividades.</p><p>3.3 Artefatos de informação</p><p>Conforme mostrado no cap. 2 , um processo de negócios envolve diferentes aspectos organizacionais</p><p>como funções, artefatos de negócios, humanos e sistemas de software. Esses aspectos</p><p>são capturados por diferentes perspectivas de modelagem de processos. Até agora vimos o</p><p>perspectiva funcional , que indica quais atividades devem acontecer no pro-</p><p>e a perspectiva do fluxo de controle , que indica quando as atividades e eventos</p><p>deve ocorrer. Outra perspectiva importante que devemos considerar ao modelar</p><p>processos de negócios é a perspectiva dos dados . A perspectiva dos dados indica qual</p><p>artefatos de informação (por exemplo, documentos de negócios, arquivos) são necessários para realizar um ac-</p><p>atividade e quais são produzidos como resultado da realização de uma atividade.</p><p>Vamos enriquecer o processo de atendimento do pedido do Exemplo 3.6 com artefatos. Deixe-nos</p><p>comece identificando os artefatos que cada atividade requer para ser executada,</p><p>e aqueles que cada atividade cria como resultado de sua execução. Por exemplo, o primeiro</p><p>A atividade do processo de atendimento do pedido é “Verificar disponibilidade de estoque”. Isto exige</p><p>um pedido de compra como entrada, a fim de verificar se o produto pedido é ou não</p><p>em estoque. Este artefato também é exigido pela atividade "Verificar disponibilidade de matéria-prima"</p><p>caso o produto seja fabricado. Artefatos como pedido de compra são chamados de dados</p><p>objetos em BPMN. Objetos de dados representam informações que entram e saem da atividade</p><p>laços; eles podem ser artefatos físicos, como uma fatura ou uma carta em um pedaço de papel,</p><p>ou artefatos eletrônicos, como um e-mail ou um arquivo. Nós os descrevemos como um documento com</p><p>o canto superior direito dobrado e vinculá-los às atividades com uma seta pontilhada</p><p>com uma ponta de seta aberta (chamada de associação de dados em BPMN). A Figura 3.14 mostra o</p><p>objetos de dados envolvidos no modelo de processo de atendimento do pedido.</p><p>Usamos a direção da associação de dados para estabelecer se um objeto de dados é</p><p>uma entrada ou saída para uma determinada atividade. Uma associação de entrada, como a usada</p><p>do pedido de compra à atividade "Verificar disponibilidade de estoque", indica que a compra</p><p>pedido é um objeto de entrada para esta atividade; uma associação de saída, como a usada</p><p>Página 100</p><p>80 3 Modelagem de Processo Essencial</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 96/192</p><p>Fig. 3.14 O exemplo de atendimento de pedido com artefatos</p><p>da atividade "Obter matérias-primas do Fornecedor 1" para Matérias-primas, indica</p><p>que a matéria-prima é um objeto de saída para esta atividade. Para evitar bagunçar o dia-</p><p>grama com associações de dados que cruzam fluxos de sequência, podemos repetir um objeto de dados</p><p>várias vezes no mesmo modelo de processo. No entanto, todas as ocorrências de um determinado</p><p>objeto se referem conceitualmente ao mesmo artefato. Por exemplo, na Fig. 3.14 Compra</p><p>o pedido é repetido duas vezes como entrada para “Verificar disponibilidade de estoque” e “Confirmar pedido”</p><p>já que essas duas atividades estão distantes uma da outra em termos de layout de modelo.</p><p>Freqüentemente, a saída de uma atividade coincide com a entrada para uma atividade subsequente.</p><p>Por exemplo, uma vez que as matérias-primas foram obtidas, estas são usadas pela atividade</p><p>“Fabrique o produto” para criar um Produto. O Produto, por sua vez, é embalado e</p><p>enviado ao cliente pela atividade “Enviar produto”. Efetivamente, os objetos de dados nos permitem</p><p>para modelar o fluxo de informações entre as atividades do processo. Tenha em mente, no entanto,</p><p>que os objetos de dados e suas associações com atividades não podem substituir a sequência</p><p>fluxo. Em outras palavras, mesmo que um objeto seja passado de uma atividade A para uma atividade B,</p><p>ainda precisamos modelar o fluxo de sequência de A para B. Uma notação abreviada para</p><p>passar um objeto de uma atividade para outra é conectar diretamente os dados</p><p>objeto ao fluxo de sequência entre duas atividades consecutivas por meio de um</p><p>Associação. Veja, por exemplo, o endereço de envio que está sendo passado da atividade “Get</p><p>Página 101</p><p>3.3 Artefatos de informação 81</p><p>endereço de remessa ”para a atividade“ Enviar produto ”, que é uma abreviatura para indicar</p><p>esse endereço de remessa é uma saída de "Obter endereço de remessa" e uma entrada para "Enviar</p><p>produtos".</p><p>Às vezes, podemos precisar representar o estado de um objeto de dados. Por exemplo,</p><p>a atividade “Confirmar pedido” pega um pedido de compra como entrada e retorna um “confirmado”</p><p>Pedido de compra como saída: objetos de entrada e saída são os mesmos, mas o objeto</p><p>o estado mudou para “confirmado”. Da mesma forma, a atividade “Receber pagamento” assume como</p><p>insira um pedido de compra “confirmado” e o transforma em um pedido de compra “pago”.</p><p>Um objeto pode passar por vários estados, por exemplo, uma fatura é primeiro "aberta", depois</p><p>“Aprovado” ou “rejeitado” e finalmente “arquivado”. Indicar os estados dos objetos de dados é</p><p>opcional: podemos fazer isso acrescentando o nome do estado entre colchetes</p><p>ao rótulo de um objeto de dados, por exemplo, “Pedido de compra [confirmado]”, “Produto [embalado]”.</p><p>Um armazenamento de dados é um local que contém objetos de dados que precisam ser persistidos além</p><p>a duração de uma instância de processo, por exemplo, um banco de dados para artefatos eletrônicos ou um arquivo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 97/192</p><p>armário de montagem para físicos. Atividades de processo podem ler / escrever objetos de dados de / para</p><p>armazenamentos de dados. Por exemplo, a atividade "Verificar disponibilidade de estoque" recupera o nível de estoque</p><p>els para o produto pedido do banco de dados do armazém, que contém estoque</p><p>informações de nível para os vários Produtos. Da mesma forma, a atividade “Verificar matérias-primas</p><p>disponibilidade ”consulta o catálogo de fornecedores para verificar qual fornecedor entrar em contato. o</p><p>O banco de dados do armazém ou o catálogo do fornecedor são exemplos de armazenamentos de dados usados como entrada</p><p>às atividades. Um exemplo de armazenamento de dados empregado como saída é o banco de dados de Pedidos,</p><p>que é usado pela atividade “Pedido de arquivamento” para armazenar o pedido de compra confirmado. No</p><p>desta forma, o pedido recém-arquivado estará disponível para outros processos de negócios dentro</p><p>a mesma organização, por exemplo, para um processo de negócios que lida com solicitações de produtos</p><p>uct retorna. Os armazenamentos de dados são representados como um cilindro vazio (o banco de dados típico</p><p>símbolo) com uma borda superior tripla. Semelhante a objetos de dados, eles estão conectados a</p><p>atividades por meio de associações de dados.</p><p>Pergunta Os objetos de dados afetam o fluxo do token?</p><p>Os objetos de dados de entrada são necessários para que uma atividade seja executada. Mesmo se um token</p><p>está disponível no arco de entrada dessa atividade, o último não pode ser executado até</p><p>todos os objetos de dados de entrada também estão disponíveis. Um objeto de dados está disponível se tiver sido</p><p>criado como resultado da conclusão de uma atividade anterior (cuja saída foram os dados</p><p>objeto em si), ou porque é uma entrada para todo o processo (como pedido de compra).</p><p>Os objetos de dados de saída afetam apenas o fluxo do token indiretamente, ou seja, quando são usados por</p><p>atividades subsequentes.</p><p>Pergunta Sempre precisamos modelar objetos de dados?</p><p>Objetos de dados ajudam o leitor a entender o fluxo de dados</p><p>de negócios de um ativo</p><p>para o outro. No entanto, o preço a pagar é um aumento da complexidade do diagrama.</p><p>Assim, sugerimos usá-los apenas quando forem necessários para uma finalidade específica, por exemplo</p><p>para destacar os problemas potenciais no processo em análise (cf. Capítulos 6 e 7 ) ou para</p><p>automação (cf. Cap. 9 ).</p><p>Página 102</p><p>82 3 Modelagem de Processo Essencial</p><p>Às vezes, podemos precisar fornecer informações adicionais para o modelo de processo</p><p>leitor, com o objetivo de melhorar a compreensão do modelo. Por exemplo, em</p><p>o processo de atendimento do pedido, podemos especificar essa atividade "Enviar produto"</p><p>inclui a embalagem do produto. Além disso, podemos esclarecer qual negócio</p><p>regra é seguida na escolha das matérias-primas dos fornecedores. Tão adicional</p><p>as informações podem ser fornecidas por meio de anotações de texto . Uma anotação é descrita como um</p><p>retângulo aberto que encapsula o texto da anotação e está vinculado a um</p><p>elemento de modelagem de processo por meio de uma linha pontilhada (chamada de associação ) - consulte a Fig. 3.14 para</p><p>um exemplo. As anotações de texto não têm semântica, portanto, não afetam o</p><p>fluxo de tokens através do modelo de processo.</p><p>Exercício 3.5 Junte os quatro fragmentos do processo de avaliação do empréstimo que</p><p>você criou nos Exercícios 3.1 - 3.4 .</p><p>Dica Observe os rótulos dos eventos de início / fim para entender as dependências do pedido</p><p>entre os vários fragmentos. Em seguida, estenda o modelo resultante adicionando todos os</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 98/192</p><p>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,</p><p>e (iii) verificar um acordo de reembolso.</p><p>3.4 Recursos</p><p>Um outro aspecto que precisamos considerar na modelagem de processos de negócios é a re-</p><p>perspectiva da fonte . Essa perspectiva, também chamada de perspectiva organizacional ,</p><p>dica quem ou o que executa cada atividade. Recurso é um termo genérico para se referir a</p><p>qualquer pessoa ou coisa envolvida no desempenho de uma atividade de processo. Um recurso</p><p>pode ser:</p><p>• Um participante do processo , ou seja, um indivíduo como o funcionário John Smith.</p><p>• Um sistema de software , por exemplo, um servidor ou aplicativo de software.</p><p>• Um equipamento , como uma impressora ou uma fábrica.</p><p>Podemos distinguir entre recursos ativos , ou seja, recursos que podem de forma autônoma</p><p>executar uma atividade e recursos passivos , ou seja, recursos que estão apenas envolvidos em</p><p>o desempenho de uma atividade. Por exemplo, uma fotocopiadora é usada por um participante para</p><p>fazer uma cópia de um documento, mas é o participante que faz a fotocópia</p><p>atividade. Assim, a fotocopiadora é um recurso passivo enquanto o participante é um ativo</p><p>recurso. Um bulldozer é outro exemplo de recurso passivo, pois é o driver</p><p>quem executa a atividade em que o bulldozer é usado.</p><p>A perspectiva de recursos de um processo está interessada em recursos ativos, portanto, de</p><p>agora com o termo “recurso” nos referimos a um “recurso ativo”.</p><p>Freqüentemente, em um modelo de processo, não nos referimos explicitamente a um recurso em um</p><p>tempo, como por exemplo um funcionário John Smith, mas em vez disso nos referimos a um grupo de</p><p>recursos que são intercambiáveis no sentido de que qualquer membro do grupo pode</p><p>Página 103</p><p>3.4 Recursos 83</p><p>executar uma determinada atividade. Esses grupos são chamados de classes de recursos . Os exemplos são um</p><p>toda a organização, uma unidade organizacional ou uma função. 1</p><p>Vamos examinar os recursos envolvidos em nosso exemplo de atendimento de pedidos.</p><p>Exemplo 3.8</p><p>O processo de atendimento do pedido é realizado por uma organização do vendedor que inclui dois</p><p>partments: o departamento de vendas e o departamento de armazém e distribuição. A compra</p><p>o pedido recebido pelo depósito e distribuição é verificado em relação ao estoque. Esta operação é</p><p>realizado automaticamente pelo sistema ERP de armazém e distribuição, que consulta</p><p>o banco de dados do warehouse. Se o produto estiver em estoque, ele é recuperado do depósito antes de</p><p>antes de as vendas confirmarem o pedido. As próximas vendas emitem uma nota fiscal e aguardam o pagamento, enquanto o</p><p>o produto é despachado de dentro do armazém e distribuição. O processo é concluído com o</p><p>arquivamento de pedidos no departamento de vendas. Se o produto não estiver em estoque, o sistema ERP dentro</p><p>armazém e distribuição verifica a disponibilidade de matérias-primas acessando os fornecedores</p><p>Catálogo. Assim que as matérias-primas forem obtidas, o departamento de armazém e distribuição</p><p>mento cuida da fabricação do produto. O processo termina com a compra</p><p>pedido sendo confirmado e arquivado pelo departamento de vendas.</p><p>O BPMN fornece duas construções para modelar aspectos de recursos: pools e pistas . Piscinas</p><p>são geralmente usados para modelar classes de recursos, as pistas são usadas para particionar um pool em</p><p>subclasses ou recursos únicos. Não há restrições quanto a qual recurso específico</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 99/192</p><p>digite uma piscina ou uma pista deve modelar. Normalmente, usaríamos um pool para modelar uma empresa</p><p>festa ness como uma organização inteira, como o vendedor em nosso exemplo, e uma pista</p><p>modelar um departamento, unidade, equipe ou sistema / equipamento de software dentro dessa organização</p><p>nização. Em nosso exemplo, dividimos o pool de vendedores em duas pistas: uma para o</p><p>armazém e departamento de distribuição, o outro para o departamento de vendas.</p><p>As pistas podem ser aninhadas umas nas outras em vários níveis. Por exemplo, se nós</p><p>precisamos modelar um departamento e as funções dentro desse departamento, podemos usar</p><p>uma pista externa para o departamento e uma pista interna para cada função. Na ordem</p><p>exemplo de atendimento, aninhamos uma via dentro do Armazém e Distribuição para representar</p><p>sistema ERP dentro desse departamento.</p><p>Poças e pistas são representadas como retângulos dentro dos quais podemos colocar atividades,</p><p>eventos, gateways e objetos de dados. Normalmente, modelamos esses retângulos horizontais</p><p>, embora modelá-los verticalmente também seja possível. O nome da piscina / pista</p><p>é mostrado verticalmente no lado esquerdo de um retângulo horizontal (ou horizontalmente se</p><p>a piscina / pista é vertical); para pools e para pistas contendo pistas aninhadas, o nome</p><p>está incluído em uma faixa. A Figura 3.15 mostra o exemplo revisado de atendimento do pedido com</p><p>aspectos de recursos.</p><p>É importante colocar uma atividade na pista certa. Por exemplo, colocamos</p><p>atividade "Verificar disponibilidade de estoque" na faixa do Sistema ERP do Armazém e</p><p>Distribuição para indicar que esta atividade é realizada automaticamente pelo ERP</p><p>sistema desse departamento. Também é importante colocar os eventos corretamente nas pistas.</p><p>Em nosso exemplo, colocamos o evento "Pedido de compra recebido" na via do sistema ERP para</p><p>indicam que o processo começa dentro do sistema ERP de Armazém e Distribuição,</p><p>1 Em BPMN, o termo "participante" é usado em um sentido amplo como sinônimo de classe de recurso, embora</p><p>neste livro, não adotamos essa definição.</p><p>Página 104</p><p>84 3 Modelagem de Processo Essencial</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 100/192</p><p>Fig. 3.15 O exemplo de atendimento do pedido com informações de recursos</p><p>Página 105</p><p>3.4 Recursos 85</p><p>enquanto colocamos o evento "Pedido atendido" no pool de vendas para indicar que o processo</p><p>conclui no departamento de vendas. Não é relevante onde os objetos de dados são colocados, como</p><p>eles dependem das atividades às quais estão vinculados. De acordo com os gateways, precisamos colocar</p><p>aqueles que modelam (X) divisões OR sob a mesma pista que a atividade de decisão anterior</p><p>foi colocado. Por outro lado, é irrelevante onde colocamos</p><p>uma divisão AND</p><p>e todos se unem a gateways, uma vez que esses elementos são passivos no sentido de que se comportam</p><p>de acordo com seu contexto.</p><p>Podemos organizar pistas dentro de um pool em uma matriz quando precisamos modelar com-</p><p>estruturas organizacionais complexas. Por exemplo, se tivermos uma organização onde funções</p><p>abrangem diferentes departamentos, podemos usar faixas horizontais para modelar os vários de-</p><p>partments e faixas verticais para modelar as funções dentro desses departamentos. Suportar</p><p>lembre-se, entretanto, que no BPMN cada atividade pode ser realizada por apenas um recurso.</p><p>Assim, se uma atividade fica na interseção de uma pista horizontal com uma pista vertical,</p><p>será realizada pelo recurso que atenda às características de ambas as pistas, por exemplo</p><p>um recurso que tem essa função e pertence a esse departamento.</p><p>Exercício 3.6 Estenda o processo de negócios para avaliar os pedidos de empréstimo que você</p><p>criado no Exercício 3.5 , considerando os seguintes aspectos de recursos.</p><p>O processo de avaliação dos pedidos de empréstimo é executado por quatro funções dentro do empréstimo</p><p>provedor: um diretor financeiro se encarrega de verificar o histórico de crédito do requerente; um adereço-</p><p>avaliador erty é responsável por avaliar a propriedade; um representante de vendas de seguros</p><p>envia a cotação de seguro residencial para o requerente, se necessário. Todas as outras atividades são</p><p>realizada pelo oficial de crédito, que é o principal ponto de contato com o requerente.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 101/192</p><p>Freqüentemente, há mais de uma empresa participando da mesma empresa</p><p>processo. Por exemplo, no processo de atendimento do pedido, existem quatro partes: o</p><p>vendedor, o cliente e os dois fornecedores.</p><p>Cada parte pode ser modelada por uma piscina. Em nosso exemplo, podemos usar um pool</p><p>para o cliente, um para o vendedor e um para cada fornecedor. Cada uma dessas piscinas</p><p>conterá as atividades, eventos, gateways e objetos de dados que modelam o</p><p>parte do processo de negócios que ocorre nessa organização. Ou, colocando de outra forma,</p><p>cada pool modelará o mesmo processo de negócios da perspectiva de um</p><p>organização. Por exemplo, o evento “Pedido de compra recebido” que fica no setor de Vendas</p><p>pool, terá uma atividade correspondente "Enviar pedido de compra" ocorrendo no</p><p>Pool de clientes. Da mesma forma, a atividade "Enviar produto" de Vendas terá um contador</p><p>atividade parcial “Receber produto” no pool de clientes. Então, como podemos modelar o</p><p>interações entre os pools de duas organizações colaboradoras? Não podemos usar o</p><p>fluxo de sequência para conectar atividades que pertencem a pools diferentes desde a sequência</p><p>o fluxo não pode cruzar os limites de uma piscina. Para isso, precisamos usar um elemento específico</p><p>chamado fluxo de mensagens .</p><p>Um fluxo de mensagens representa o fluxo de informações entre dois recursos separados</p><p>aulas (piscinas). É representado como uma linha tracejada que começa com um círculo vazio</p><p>e termina com uma ponta de seta vazia, e traz uma etiqueta indicando o conteúdo do</p><p>mensagem, por exemplo, um fax, um pedido de compra, mas também uma carta ou um telefonema. Ou seja, o</p><p>Página 106</p><p>86 3 Modelagem de Processo Essencial</p><p>o fluxo de mensagens modela qualquer tipo de comunicação entre duas organizações, não</p><p>importa se é eletrônico, como enviar um pedido de compra por e-mail ou transmitir um</p><p>fax ou manual, como fazer uma ligação ou entregar uma carta em papel.</p><p>A Figura 3.16 mostra o modelo completo do processo de atendimento do pedido, incluindo o</p><p>pools para o cliente e os dois fornecedores. Aqui podemos ver que o fluxo de mensagens</p><p>são etiquetados com a informação que carregam, por exemplo, "Matérias-primas" ou "Enviar-</p><p>endereço ”. Um fluxo de mensagem de entrada pode levar à criação de um objeto de dados</p><p>jeto pela atividade que recebe a mensagem. Por exemplo, o fluxo de mensagens “Raw</p><p>materiais ”é recebido pela atividade“ Obter matérias-primas do Fornecedor 1 ”que</p><p>em seguida, cria o objeto de dados “Matérias-primas”. Este também é o caso da compra</p><p>pedido, que é gerado pelo evento inicial "Pedido de compra recebido" do</p><p>conteúdo do fluxo de mensagens recebidas. Não precisamos criar um objeto de dados para</p><p>cada fluxo de mensagem de entrada, apenas quando as informações transportadas pela mensagem são</p><p>necessário em outra parte do processo. Em nosso caso, "Matérias-primas" é consumido por ac-</p><p>atividade “Produto de fabricação”, portanto, precisamos representá-lo como um objeto de dados. Similarmente,</p><p>não precisamos representar explicitamente o objeto de dados que entra em uma saída</p><p>mensagem se este objeto de dados não for necessário em outro lugar no processo. Por exemplo, ac-</p><p>atividade “Emitir fatura” gera uma fatura que é enviada ao cliente, mas lá</p><p>não é um objeto de dados “Fatura” uma vez que esta não é consumida por qualquer atividade no Vendedor</p><p>piscina.</p><p>Um diagrama BPMN que apresenta dois ou mais pools é chamado de dia de colaboração</p><p>grama . A Figura 3.16 mostra diferentes usos de um pool em um diagrama de colaboração. Uma piscina</p><p>assim para o vendedor é chamado de processo privado , ou white box pool, uma vez que mostra</p><p>a eficácia com que a organização vendedora participa do processo de atendimento do pedido</p><p>em termos de atividades, eventos, gateways e objetos de dados. Pelo contrário, uma piscina</p><p>assim para o cliente e os dois fornecedores é chamado de processo público , ou preto</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 102/192</p><p>box pool, uma vez que esconde como essas organizações realmente participam do pedidoprocesso de atendimento. Para economizar espaço, podemos representar uma caixa preta com um</p><p>piscina em colapso , que é um retângulo vazio com o nome da piscina no</p><p>meio.</p><p>Pergunta Caixa preta ou caixa branca?</p><p>Modelar uma piscina como caixa branca ou caixa preta é uma questão de relevância. Quando</p><p>trabalhando em um diagrama de colaboração, uma organização pode decidir se ou não</p><p>para expor seu comportamento interno, dependendo dos requisitos do projeto em</p><p>mão. Por exemplo, se estivermos modelando o processo de atendimento do pedido do vendedor</p><p>perspectiva, pode ser relevante expor o processo de negócios do vendedor apenas,</p><p>mas não do cliente e dos fornecedores. Ou seja, o comportamento interno do</p><p>cliente e dos fornecedores não são relevantes para fins de compreensão</p><p>como o vendedor deve cumprir os pedidos de compra e, como tal, eles podem ser ocultados. Em</p><p>por outro lado, se precisarmos melhorar a maneira como o vendedor atende aos pedidos de compra,</p><p>também pode querer saber o que é necessário para um fornecedor fornecer matérias-primas, como um</p><p>demora no fornecimento de matéria-prima vai desacelerar a fabricação do produto</p><p>Página 107</p><p>3.4 Recursos 87</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 103/192</p><p>Fig. 3.16 Diagrama de colaboração entre um vendedor, um cliente e dois fornecedores</p><p>Página 108</p><p>88 3 Modelagem de Processo Essencial</p><p>ao lado do vendedor. Neste caso, devemos também representar os fornecedores usando branco</p><p>box pools.</p><p>O tipo de pool afeta a maneira como usamos o fluxo de mensagens para nos conectar ao</p><p>piscina. Consequentemente, um fluxo de mensagens pode cruzar o limite de um conjunto de caixa branca</p><p>e se conectar diretamente a uma atividade ou evento dentro desse pool, como o pedido de compra</p><p>mensagem que é incidente ao evento de início no pool do vendedor. Por outro lado,</p><p>uma vez que um conjunto de caixa preta está vazio, os fluxos de mensagens devem parar no limite ou emanar</p><p>do limite de uma piscina de caixa preta. Tenha em mente que um fluxo de mensagens é apenas</p><p>usado para conectar dois pools e nunca para conectar duas atividades dentro do mesmo pool.</p><p>Para isso, usamos um fluxo de sequência.</p><p>Uma atividade que é a fonte de uma mensagem, como "Emitir fatura" no Vendedor</p><p>pool - é chamado de atividade de envio</p><p>. . . . . . . . . . . . . . 167</p><p>5.3.1 Identificar os limites do processo. . . . . . . . . . . . . . . 167</p><p>5.3.2 Identificar atividades e eventos. . . . . . . . . . . . . . . . 167</p><p>5.3.3 Identificar recursos e seusHandovers. . . . . . . . . . 168</p><p>5.3.4 Identifique o Fluxo de Controle. . . . . . . . . . . . . . . . . . 169</p><p>5.3.5 IdentifyAdditionalElements. . . . . . . . . . . . . . . . 169</p><p>5.4 Garantia da qualidade do modelo de processo. . . . . . . . . . . . . . . . . . 171</p><p>5.4.1 Qualidade sintática e verificação. . . . . . . . . . . . . . 171</p><p>5.4.2 Qualidade semântica e validação. . . . . . . . . . . . . . 172</p><p>5.4.3 Qualidade e certificação pragmática. . . . . . . . . . . . . 174</p><p>5.4.4 Diretrizes e convenções de modelagem. . . . . . . . . . . 175</p><p>5.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178</p><p>5.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 179</p><p>5.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 181</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 12/192</p><p>5.8 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 183</p><p>6 Análise qualitativa de processos . . . . . . . . . . . . . . . . . . . . . . . 185</p><p>6.1 Análise de valor agregado. . . . . . . . . . . . . . . . . . . . . . . . 185</p><p>6.1.1 Classificação de valor. . . . . . . . . . . . . . . . . . . . . 185</p><p>6.1.2 Eliminação de resíduos. . . . . . . . . . . . . . . . . . . . . . 189</p><p>6.2 RootCauseAnalysis. . . . . . . . . . . . . . . . . . . . . . . . . 190</p><p>6.2.1 Diagramas de causa e efeito. . . . . . . . . . . . . . . . . . . 191</p><p>6.2.2 Diagramas de Por quê. . . . . . . . . . . . . . . . . . . . 196</p><p>6.3 Emissão de documentação e avaliação de impacto. . . . . . . . . . . . 198</p><p>6.3.1 IssueRegister. . . . . . . . . . . . . . . . . . . . . . . . 198</p><p>6.3.2 Análise de Pareto e gráficos PICK. . . . . . . . . . . . . . 201</p><p>6.4 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204</p><p>6.5 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 205</p><p>6.6 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 208</p><p>6.7 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 210</p><p>7 Análise Quantitativa de Processos . . . . . . . . . . . . . . . . . . . . . . 213</p><p>7.1 Medidas de desempenho. . . . . . . . . . . . . . . . . . . . . . . . 213</p><p>7.1.1 Dimensões de desempenho do processo. . . . . . . . . . . . . . 213</p><p>7.1.2 BalancedScorecard. . . . . . . . . . . . . . . . . . . . . 217</p><p>7.1.3 Modelos de referência e benchmarks do setor. . . . . . . . 218</p><p>7.2 FlowAnalysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . 219</p><p>7.2.1 Calculando o tempo do ciclo usando a análise de fluxo. . . . . . . . 219</p><p>7.2.2 CycleTimeEfficiency. . . . . . . . . . . . . . . . . . . . 224</p><p>7.2.3 CycleTimeandWork-In-Process. . . . . . . . . . . . . . 225</p><p>7.2.4 Outras aplicações e limitações da análise de fluxo. . . 227</p><p>7.3 Filas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229</p><p>7.3.1 Fundamentos da Teoria da Avaliação. . . . . . . . . . . . . . . . . 229</p><p>7.3.2 Modelos M / M / 1 e M / M / c. . . . . . . . . . . . . . . . . 232</p><p>7.3.3 Limitações da Teoria de Avaliação Básica. . . . . . . . . . . 234</p><p>Página 13</p><p>xvi Conteúdo</p><p>7.4 Simulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235</p><p>7.4.1 Anatomia de uma Simulação de Processo. . . . . . . . . . . . . . 235</p><p>7.4.2 Entrada para Simulação de Processo. . . . . . . . . . . . . . . . 236</p><p>7.4.3 SimulationTools. . . . . . . . . . . . . . . . . . . . . . . 240</p><p>7.4.4 Uma palavra de cautela. . . . . . . . . . . . . . . . . . . . . . 243</p><p>7.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243</p><p>7.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 244</p><p>7.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 246</p><p>7.8 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 250</p><p>8 Redesenho do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253</p><p>8.1 TheEssenceofProcessRedesign. . . . . . . . . . . . . . . . . . 253</p><p>8.1.1 WhyRedesign? . . . . . . . . . . . . . . . . . . . . . . . 253</p><p>8.1.2 O queéRedesign? . . . . . . . . . . . . . . . . . . . . . . 256</p><p>8.1.3 O Quadrângulo do Diabo. . . . . . . . . . . . . . . . . . . 258</p><p>8.1.4 Como fazer o redesign? . . . . . . . . . . . . . . . . . . . . . . 259</p><p>8.2 HeuristicProcessRedesign. . . . . . . . . . . . . . . . . . . . . 262</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 13/192</p><p>8.2.1 CustomerHeuristics. . . . . . . . . . . . . . . . . . . . . 263</p><p>8.2.2 BusinessProcessOperationHeuristics. . . . . . . . . . . 264</p><p>8.2.3 Heurísticas de comportamento de processos de negócios. . . . . . . . . . . . 266</p><p>8.2.4 OrganizationHeuristics. . . . . . . . . . . . . . . . . . . 267</p><p>8.2.5 Heurísticas de informação. . . . . . . . . . . . . . . . . . . . 270</p><p>8.2.6 TechnologyHeuristics. . . . . . . . . . . . . . . . . . . . 271</p><p>8.2.7 ExternalEnvironmentHeuristics. . . . . . . . . . . . . . 271</p><p>8.3 O caso de uma instituição de saúde. . . . . . . . . . . . . . . . 273</p><p>8.3.1 Envio de arquivos médicos por correio. . . . . . . . . . . . . . . 275</p><p>8.3.2 Reuniões periódicas. . . . . . . . . . . . . . . . . . . . . . 275</p><p>8.3.3 RequestingMedicalFiles. . . . . . . . . . . . . . . . . . 276</p><p>8.4 Design baseado no produto. . . . . . . . . . . . . . . . . . . . . . . . 278</p><p>8.4.1 Análise: Criando um modelo de dados do produto. . . . . . . . . . 279</p><p>8.4.2 Design: derivando um processo de um modelo de dados do produto. . 285</p><p>8.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288</p><p>8.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 289</p><p>8.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 292</p><p>8.8 Leitura Adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 295</p><p>9 Automação de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . 297</p><p>9.1 Automatizando Processos de Negócios. . . . . . . . . . . . . . . . . . . 297</p><p>9.1.1 Sistemas de gerenciamento de processos de negócios. . . . . . . . . . . 298</p><p>9.1.2 Arquitetura de umBPMS. . . . . . . . . . . . . . . . . . . 299</p><p>9.1.3 TheCaseofACNS. . . . . . . . . . . . . . . . . . . . . 304</p><p>9.2 Vantagens de introduzir um BPMS. . . . . . . . . . . . . . . . . 309</p><p>9.2.1 Redução da carga de trabalho. . . . . . . . . . . . . . . . . . . . . 309</p><p>9.2.2 FlexibleSystemIntegration. . . . . . . . . . . . . . . . . 310</p><p>9.2.3 ExecutionTransparency. . . . . . . . . . . . . . . . . . . 311</p><p>9.2.4 Aplicação de regras. . . . . . . . . . . . . . . . . . . . . . 312</p><p>Página 14</p><p>Conteúdo xvii</p><p>9.3 Desafios da introdução de umBPMS. . . . . . . . . . . . . . . . . 313</p><p>9.3.1 Desafios Técnicos. . . . . . . . . . . . . . . . . . . . 313</p><p>9.3.2 Desafios organizacionais. . . . . . . . . . . . . . . . . . 314</p><p>9.4 Tornando os modelos de processos executáveis. . . . . . . . . . . . . . . . . 316</p><p>9.4.1 Identifique os limites da automação. . . . . . . . . . . . 317</p><p>9.4.2 ReviewManualTasks. . . . . . . . . . . . . . . . . . . . 319</p><p>9.4.3 Concluir o Modelo de Processo. . . . . . . . . . . . . . . . 323</p><p>9.4.4 Traga o Modelo de Processo para um Nível de Granularidade Adequado 324</p><p>9.4.5 SpecifyExecutionProperties. . . . . . . . . . . . . . . . 327</p><p>9.4.6 TheLastMile. . . . . . . . . . . . . . . . . . . . . . . . 337</p><p>9.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338</p><p>9.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 338</p><p>9.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 347</p><p>9.8 Leitura adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 351</p><p>10 Inteligência de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353</p><p>10.1 Execução de processos e registros de eventos. . . . . . . . . . . . . . . .</p><p>. A mensagem é enviada após a conclusão da atividade</p><p>execução. Por outro lado, uma atividade que recebe uma mensagem, como “Receba</p><p>endereço de envio ”- é uma atividade de recebimento . 2 A execução de tal atividade não</p><p>comece até que a mensagem recebida esteja disponível. Uma atividade pode atuar como uma recepção</p><p>e uma atividade de envio quando tem um fluxo de mensagem de entrada e saída, por exemplo</p><p>"Faça o pagamento". A execução desta atividade começará quando ambos os fluxos de controle</p><p>token e a mensagem recebida estão disponíveis. Após a conclusão da atividade, um</p><p>token de fluxo de controle será colocado no arco de saída e a mensagem de saída será</p><p>enviado para fora. Finalmente, quando um fluxo de mensagens incide em um evento inicial como “Compra</p><p>pedido recebido ”, precisamos marcar este evento com um envelope leve (ver Fig. 3.16 ).</p><p>Este tipo de evento é denominado evento de mensagem . Um evento de mensagem pode ser vinculado a uma saída</p><p>objeto de dados para armazenar o conteúdo da mensagem recebida. Nós aprenderemos</p><p>mais sobre eventos no próximo capítulo.</p><p>Exercício 3.7 Estenda o modelo do Exercício 3.6 , representando as interações entre</p><p>entre o credor e o requerente.</p><p>No exemplo de atendimento de pedidos, usamos pools para representar as partes de negócios e</p><p>pistas para representar os departamentos e sistemas dentro da organização de vendas. Isto é</p><p>porque queríamos nos concentrar nas interações entre o vendedor, o cliente e</p><p>os dois fornecedores. Como mencionado antes, esse é o uso típico para piscinas e raias.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 104/192</p><p>No entanto, uma vez que BPMN não prescreve quais tipos de recursos específicos devem serassociados a pools e pistas, podemos usar esses elementos de maneira diferente. Para a prova-</p><p>ple, se o foco estiver nas interações entre os departamentos de uma organização,</p><p>podemos modelar cada departamento com um pool e usar faixas para particionar o departamento</p><p>mentos, por exemplo, em unidades ou funções. Em qualquer caso, devemos evitar o uso de piscinas e pistas</p><p>para capturar os participantes por seus nomes, uma vez que os indivíduos tendem a mudar com frequência</p><p>dentro de uma organização; em vez disso, devemos usar a função do participante, por exemplo, financeiro</p><p>Policial. Por outro lado, podemos usar pools e pistas para representar software específico</p><p>sistemas ou equipamentos, por exemplo, um sistema ERP, uma vez que estes mudam com menos frequência em um</p><p>organização.</p><p>2 Mais especificamente, “Emitir fatura” é uma tarefa de envio e “Obter endereço de entrega” é uma tarefa de recebimento . o</p><p>A distinção entre atividade e tarefa será discutida no Cap. 4 .</p><p>Página 109</p><p>3.5 Recapitulação 89</p><p>3.5 Recapitulação</p><p>No final deste capítulo, devemos ser capazes de compreender e produzir programas básicos</p><p>modelos de cesso em BPMN. Um modelo básico de BPMN inclui atividades simples, eventos,</p><p>gateways, objetos de dados, pools e pistas. Atividades capturam unidades de trabalho dentro de um</p><p>processo. Os eventos definem o início e o fim de um processo e sinalizam algo que acontece</p><p>canetas durante a execução do mesmo. Gateways modelam decisões exclusivas e inclusivas,</p><p>mesclas, paralelismo e sincronização e repetição. Estudamos a diferença</p><p>entre o modelo de processo e a instância de processo. Um modelo de processo descreve todas as possibilidades</p><p>várias maneiras de um determinado processo de negócios ser executado, enquanto uma instância de processo captura</p><p>execução de um processo específico entre todos os possíveis. O progresso, ou estado, de um</p><p>a instância do processo é representada por tokens. Usando tokens, podemos definir o comportamento</p><p>de gateways.</p><p>Também aprendemos como usar objetos de dados para modelar o fluxo de informações entre</p><p>atividades e eventos. Um objeto de dados captura um artefato físico ou eletrônico re-</p><p>exigido para executar uma atividade ou acionar um evento, ou que resulte da execução</p><p>de uma atividade ou ocorrência de um evento. Objetos de dados podem ser armazenados em um armazenamento de dados</p><p>como um banco de dados ou arquivo de modo que eles possam ser persistidos além do processo</p><p>instância onde eles são criados. Além disso, vimos como pools e pistas podem ser</p><p>usado para modelar recursos humanos e não humanos que realizam atividades de processo</p><p>laços. Os pools geralmente modelam classes de recursos, enquanto as pistas são usadas para particionar pools.</p><p>A interação entre os conjuntos é capturada por fluxos de mensagens. Os fluxos de mensagens podem ser</p><p>diretamente anexado ao limite de uma piscina, caso os detalhes da interação não</p><p>Seja relevante.</p><p>Atividades, eventos, gateways, artefatos e recursos pertencem ao modelo principal-</p><p>diferentes perspectivas de um processo de negócios. A perspectiva funcional captura o ac-</p><p>atividades que são executadas em um processo de negócios enquanto a perspectiva de fluxo de controle</p><p>combina essas atividades e eventos relacionados em uma determinada ordem. A perspectiva dos dados</p><p>cobre os artefatos manipulados no processo, enquanto a perspectiva do recurso cobre</p><p>os recursos que realizam as diversas atividades. No próximo capítulo, aprenderemos</p><p>como modelar processos de negócios complexos, investigando as várias extensões de</p><p>os principais elementos BPMN que apresentamos aqui.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 105/192</p><p>3.6 Soluções para exercícios</p><p>Solução 3.1</p><p>Página 110</p><p>90 3 Modelagem de Processo Essencial</p><p>Solução 3.2</p><p>Solução 3.3</p><p>Solução 3.4</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 106/192</p><p>Página 111</p><p>3.6 Soluções para exercícios 91</p><p>Solução 3.5</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 107/192</p><p>Página 112</p><p>92 3 Modelagem de Processo Essencial</p><p>Solução 3.6 Veja o pool de provedores de empréstimo no modelo da Solução 3.7 .</p><p>Solução 3.7</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 108/192</p><p>Página 113</p><p>3.7 Exercícios Adicionais 93</p><p>3.7 Exercícios Adicionais</p><p>Exercício 3.8 Que tipos de divisões e junções podemos modelar em um processo? Fazer um</p><p>exemplo para cada um deles usando a verificação de segurança em um aeroporto como cenário.</p><p>Exercício 3.9 Descreva o seguinte modelo de processo.</p><p>Exercício 3.10 Modelar o seguinte processo de negócios para lidar com pagamentos iniciais.</p><p>O processo para lidar com pagamentos iniciais começa quando uma solicitação de pagamento foi aprovada</p><p>provado. Envolve inserir a solicitação de entrada no sistema, a sub-</p><p>pagamento sequencial, emissão de nota fiscal direta e liberação dos itens de linha do fornecedor.</p><p>A compensação das partidas individuais do fornecedor pode resultar em um saldo devedor ou credor. Em caso de débito</p><p>saldo, os atrasos são processados, caso contrário, o saldo remanescente é pago.</p><p>Exercício 3.11 Modelar o seguinte processo de negócios para avaliar riscos de crédito.</p><p>Quando uma nova solicitação de crédito é recebida, o risco é avaliado. Se o risco estiver acima de um limite,</p><p>uma avaliação de risco avançada precisa ser realizada, caso contrário , uma avaliação de risco simples</p><p>satisfazer. Assim que a avaliação for concluída, o cliente é notificado com o resultado de</p><p>a avaliação e entretanto o desembolso é organizado. Para simplificar, suponha que o</p><p>resultado de uma avaliação é sempre positivo.</p><p>Exercício 3.12 Modelar o seguinte fragmento de um processo de negócios para seguros</p><p>reivindicações.</p><p>Depois que uma reclamação é registrada, ela é examinada por um oficial de sinistros que, em seguida, redige um acordo</p><p>recomendação. Esta recomendação é então verificada por um oficial sênior de sinistros que pode</p><p>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</p><p>ao oficial de sinistros e a recomendação é repetida. Se a reclamação</p><p>for “OK”, a reclamação</p><p>processo de tratamento continua.</p><p>Exercício 3.13 Modelar o fluxo de controle do seguinte processo de negócios para danos</p><p>compensação.</p><p>Se um inquilino for despejado por causa de danos às instalações, um processo deve ser iniciado pelo</p><p>tribunal, a fim de realizar uma audiência para avaliar o valor da compensação que o inquilino deve ao</p><p>proprietário das instalações. Este processo começa quando um caixa do tribunal recebe um pedido</p><p>para indemnização do proprietário. O caixa, então, recupera o arquivo para aqueles</p><p>premissas e verifica se o pedido é aceitável para apresentação e está em conformidade com o</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 109/192</p><p>Página 114</p><p>94 3 Modelagem de Processo Essencial</p><p>descrição das instalações em arquivo. Definir uma data de audiência incorre em taxas para o proprietário. Pode ser</p><p>que o proprietário já pagou as taxas com o pedido, caso em que o caixa aloca</p><p>uma data de audiência e o processo é concluído. Pode ser que taxas adicionais sejam necessárias, mas o</p><p>o proprietário já pagou também essas taxas. Neste caso, o caixa gera um recibo para o</p><p>taxas adicionais e receitas com a alocação da data da audiência. Finalmente, se o proprietário não</p><p>pagou as taxas exigidas, o caixa apresenta um aviso de taxas e espera que o proprietário pague o</p><p>taxas antes de reavaliar a conformidade do documento.</p><p>Exercício 3.14 O modelo de processo abaixo pode ser executado corretamente? Se não, como pode</p><p>ser corrigido sem afetar o ciclo, ou seja, de modo que "F", "G" e "E" permaneçam em</p><p>o ciclo?</p><p>Exercício 3.15 Escreva um modelo BPMN para o processo descrito no Exercício 1.1 .</p><p>Certifique-se de incluir artefatos e anotações quando apropriado.</p><p>Exercício 3.16 Estenda o modelo do Exercício 3.13 adicionando os artefatos que são</p><p>manipulado.</p><p>Exercício 3.17 Estenda o modelo do Exercício 3.16 adicionando os recursos envolvidos.</p><p>Existe algum recurso não humano?</p><p>Exercício 3.18 Modele o seguinte processo de negócios. Use gateways e objetos de dados</p><p>onde necessário.</p><p>Em um tribunal todas as manhãs, os arquivos que ainda não foram processados são verificados para garantir</p><p>eles estão em ordem para a audiência naquele dia. Se alguns arquivos estiverem faltando, uma pesquisa será iniciada,</p><p>caso contrário, os arquivos podem ser rastreados fisicamente até o local pretendido. Assim que todos os arquivos forem</p><p>pronto, são entregues ao Associado; entretanto, a lista de leis do juiz é distribuída ao</p><p>pessoas relevantes. Em seguida, são realizadas as audiências de orientações.</p><p>Exercício 3.19 Modele o seguinte processo de negócios. Use piscinas / pistas onde</p><p>necessário.</p><p>O processo de tratamento de reclamações motoras começa quando um cliente envia uma reclamação com o respectivo</p><p>documentação. O departamento de notificação da seguradora de automóveis verifica os documentos mediante</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 110/192</p><p>Página 115</p><p>3.8 Leitura Adicional 95</p><p>integridade e registra a reclamação. Em seguida, o departamento de manuseio pega a reclamação</p><p>e verifica o seguro. Em seguida, é realizada uma avaliação. Se a avaliação for positiva,</p><p>uma Oficina é telefonada para autorizar os reparos e o pagamento é agendado (neste pedido).</p><p>Caso contrário, a reclamação é rejeitada. Em qualquer caso (seja o resultado positivo ou negativo),</p><p>uma carta é enviada ao cliente e o processo é considerado concluído.</p><p>Exercício 3.20 Modelar o seguinte processo de negócios. Use piscinas / pistas onde</p><p>necessário.</p><p>Quando um sinistro é recebido, um oficial de sinistros primeiro verifica se o reclamante está segurado. Se não, o</p><p>o reclamante é informado de que a reclamação deve ser rejeitada enviando uma notificação automática via</p><p>um sistema SAP. Caso contrário, um oficial sênior de sinistros avalia a gravidade da reclamação. Sediada</p><p>no resultado (reclamações simples ou complexas), os formulários relevantes são enviados ao reclamante,</p><p>novamente usando o sistema SAP. Depois que os formulários são devolvidos, eles são verificados quanto à integridade</p><p>pelo oficial de sinistros. Se os formulários fornecerem todos os detalhes relevantes, a reclamação é registrada no</p><p>sistema de gerenciamento de sinistros e o processo termina. Caso contrário, o reclamante é informado para</p><p>atualizar os formulários através do sistema SAP. Após o recebimento dos formulários atualizados, eles são verificados</p><p>novamente pelo oficial de sinistros para ver se os detalhes foram fornecidos e assim por diante.</p><p>3.8 Leitura Adicional</p><p>Neste capítulo, apresentamos os fundamentos da modelagem de processos através do BPMN</p><p>língua. Outras linguagens convencionais que podem ser usadas para modelar processos de negócios</p><p>são diagramas de atividades UML (UML ADs), cadeias de processos orientadas a eventos (EPCs) e</p><p>Linguagem de execução de processos de negócios de serviços da Web (WS-BPEL). UML ADs são</p><p>outro padrão OMG [ 60 ]. Eles são empregados principalmente na engenharia de software</p><p>onde podem ser usados para descrever o comportamento do software e vinculados a outros UML</p><p>tipos de diagrama, por exemplo, diagramas de classe, para gerar código de software. UML ADs oferecem um</p><p>subconjunto dos elementos de modelagem presentes no BPMN. Por exemplo, construções como o</p><p>OR-join não é compatível. Uma boa visão geral desta linguagem e sua aplicação para</p><p>a modelagem de processos de negócios é fornecida em [ 16 ].</p><p>EPCs foram inicialmente desenvolvidos para o design do processo de referência SAP R / 3</p><p>modelo [ 9 ]. Eles obtiveram uma adoção generalizada por várias organizações quando</p><p>tornou-se a linguagem de modelagem central do conjunto de ferramentas ARIS [ 12 , 82 ]. Mais tarde, eles foram</p><p>usado por outros fornecedores para o design de modelos de referência independentes de SAP, como</p><p>ITIL e SCOR. A linguagem EPC inclui elementos de modelagem correspondentes a</p><p>Atividades BPMN, gateways AND, XOR e OR, eventos não tipados e objetos de dados.</p><p>Uma introdução aos EPCs é fornecida em [ 50 ].</p><p>WS-BPEL (BPEL para abreviar) versão 2.0 [ 3 ] é um padrão da Organização para</p><p>o Avanço dos Padrões de Informação Estruturada (OASIS). Uma boa visão geral</p><p>de BPEL é fornecido em [ 65 ]. BPEL é uma linguagem para execução de processos que rem</p><p>reside na tecnologia de serviço da Web para alcançar a comunicação entre processos. Um mapeamento</p><p>de BPMN para construções BPEL está disponível na especificação BPMN [ 61 ]. Quão-</p><p>sempre, este mapeamento não está completo, pois BPEL oferece um conjunto restrito de construções</p><p>em comparação com BPMN, e é essencialmente uma linguagem orientada a blocos , enquanto BPMN é</p><p>orientado para gráfico . BPEL é estruturado em blocos que precisam ser devidamente aninhados e</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 111/192</p><p>Página 116</p><p>96 3 Modelagem de Processo Essencial</p><p>não pode se sobrepor. Um bloco é composto por um único nó de entrada e um único nó de saída</p><p>que corresponde ao tipo de nó de entrada e coleta todos os ramos de saída</p><p>do nó de entrada. Por exemplo, se o nó de entrada for uma divisão AND, o nó de saída</p><p>deve ser uma junção AND. Além disso, BPEL não possui uma notação padrão, uma vez que</p><p>isso foi considerado fora do escopo pelo OASIS, embora vários fornecedores forneçam</p><p>notações particulares para este idioma. Enquanto BPMN 1.2 teve como objetivo ser o conceitual</p><p>contrapartida do BPEL, e os mapeamentos estavam, portanto, disponíveis para mover do antigo para</p><p>a última linguagem, BPMN 2.0 também pode ser usado para especificar processos executáveis (ver</p><p>Indivíduo. 9 ). Assim, o BPMN 2.0 visa substituir o BPEL neste aspecto.</p><p>Outras linguagens de modelagem de processos se originam de esforços de pesquisa. Dois deles</p><p>são redes de fluxo de trabalho e ainda outra linguagem de fluxo de trabalho (YAWL). Redes de fluxo de trabalho</p><p>são uma extensão das redes de Petri para modelar processos de negócios. Sua sintaxe é de propósito</p><p>totalmente simples e gira em torno de dois elementos: lugares e transições. O antigo</p><p>correspondem aproximadamente a eventos BPMN, enquanto os últimos a atividades BPMN. Um bem</p><p>a apresentação de redes de fluxo de trabalho é fornecida em [ 95 ].</p><p>YAWL é um sucessor das redes de fluxo de trabalho, pois adiciona construções específicas para cap-</p><p>cuidar do comportamento de junção OR, atividades de várias instâncias, subprocessos e cancelamento</p><p>regiões. YAWL mantém a simplicidade e intuitividade das redes de fluxo de trabalho, embora</p><p>fornece uma linguagem muito mais expressiva. YAWL e seu ambiente de suporte</p><p>são apresentados em detalhes em [ 92 ].</p><p>Uma comparação das línguas acima em termos de sua expressividade ao longo do</p><p>as perspectivas de fluxo de controle, dados e recursos podem ser encontradas em Padrões de fluxo de trabalho</p><p>Site da iniciativa [ 108 ]. Com o tempo, essa iniciativa coletou um repositório de trabalho</p><p>padrões de fluxo, ou seja, comportamento recorrente do processo, conforme foi observado a partir de um tor-</p><p>análise rigorosa de várias linguagens de modelagem de processos e ferramentas de suporte. Vários</p><p>linguagens e ferramentas foram comparadas com base em seu suporte para tais padrões.</p><p>Página 117</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 112/192</p><p>Capítulo 4</p><p>Modelagem Avançada de Processos</p><p>As ciências não tentam explicar, dificilmente tentam</p><p>interpretar, eles fazem principalmente modelos.</p><p>John von Neumann (1903–1957)</p><p>Neste capítulo, aprenderemos como modelar processos de negócios complexos com BPMN.</p><p>As construções apresentadas neste capítulo se baseiam no conhecimento adquirido</p><p>no cap. 3 . Em particular, iremos expandir em atividades, eventos e gateways. Nós</p><p>aprenderá como usar atividades para modelar subprocessos e como reutilizar esses subprocessos</p><p>processos em diferentes processos. Também vamos estender as atividades para modelar mais</p><p>formas sofisticadas de retrabalho e repetição. De acordo com os eventos, expandiremos a mensagem</p><p>eventos sábios, apresentam eventos temporais e mostram como as condições de corrida podem ser modeladas</p><p>entre esses tipos de eventos por meio de um novo tipo de gateway. Também aprenderemos como usar</p><p>eventos para lidar com exceções de processos de negócios. Finalmente, vamos mostrar como uma colaboração</p><p>diagrama de ração pode ser resumido em um diagrama de coreografia que se concentra apenas em</p><p>as interações entre as partes comerciais envolvidas.</p><p>4.1 Decomposição do Processo</p><p>Ao capturar processos de negócios complexos, o modelo de processo resultante pode ser</p><p>grande demais para ser compreendido de uma vez. Pegue o modelo de processo de atendimento de pedidos em</p><p>Fig. 3.12 . Embora o cenário em questão ainda seja relativamente simples, este modelo já</p><p>contém 14 atividades, seis gateways e dois eventos. À medida que adicionamos objetos de dados e mensagens</p><p>sage flui, o modelo fica maior e mais difícil de entender (veja, por exemplo, Fig. 3.16 ). Para</p><p>melhorar sua legibilidade, podemos simplificar o processo, ocultando certas partes dentro</p><p>um subprocesso . Um subprocesso representa uma atividade composta independente que</p><p>pode ser dividido em unidades menores de trabalho. Por outro lado, uma atividade atômica, também</p><p>chamada tarefa , é uma atividade que captura uma unidade de trabalho que não pode ser mais quebrada</p><p>baixa.</p><p>Para usar um subprocesso, primeiro precisamos identificar grupos de atividades relacionadas,</p><p>ou seja, aquelas atividades que juntas alcançam um objetivo específico ou geram um determinado</p><p>resultado lar no modelo de processo em análise. Em nosso exemplo de atendimento de pedido,</p><p>podemos ver que as atividades “Verificar disponibilidade de matéria-prima” e “Comprar matéria-prima</p><p>M. Dumas et al., Fundamentals of Business Process Management ,</p><p>DOI 10.1007 / 978-3-642-33143-5_4 , © Springer-Verlag Berlin Heidelberg 2013</p><p>97</p><p>Página 118</p><p>98 4 Modelagem Avançada de Processos</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://dx.doi.org/10.1007/978-3-642-33143-5_4</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 113/192</p><p>Fig. 4.1 Identificação de subprocessos no processo de atendimento de pedidos da Fig. 3.12</p><p>materiais do Fornecedor 1 (2) ”, conduzem em conjunto à aquisição de matérias-primas.</p><p>Assim, essas atividades e seus gateways de conexão podem ser encapsulados em um sub</p><p>processo. Em outras palavras, eles podem ser vistos como as etapas internas de uma macroatividade</p><p>denominado “Adquirir matérias-primas”. Da mesma forma, os dois ramos paralelos para envio e</p><p>O faturamento do pedido pode ser agrupado em outra atividade de subprocesso chamada “Enviar</p><p>e fatura ”. A Figura 4.1 ilustra o modelo resultante, onde as atividades acima</p><p>foram incluídos em duas atividades de subprocesso. Representamos essas atividades com</p><p>uma grande caixa arredondada que envolve as etapas internas. Como podemos observar de</p><p>Fig. 4.1 , também adicionamos um evento inicial e um evento final dentro de cada subprocesso ativ-</p><p>, para indicar explicitamente quando o subprocesso inicia e termina.</p><p>Lembre-se de que nosso objetivo inicial era simplificar um modelo de processo. Assim que tivermos</p><p>identificou os limites dos subprocessos, podemos simplificar o modelo por hid-</p><p>ção do conteúdo de seus subprocessos, conforme mostrado na Fig. 4.2 . Isso é feito substituindo</p><p>a macro-atividade que representa o subprocesso com uma atividade de tamanho padrão. Nós</p><p>indicam que esta atividade esconde um subprocesso, marcando-o com um pequeno quadrado</p><p>com um sinal de mais (+) dentro (como se pudéssemos expandir o conteúdo dessa atividade</p><p>pressionando o botão mais). Esta operação é chamada de redução de um subprocesso. De</p><p>colapsando um subprocesso, reduzimos o número total de atividades (o pedido cumprido</p><p>processo de preenchimento tem apenas seis atividades agora), melhorando assim a legibilidade do modelo</p><p>ity. No BPMN, um subprocesso que oculta suas etapas internas é chamado de sub-colapsado</p><p>processo , em oposição a um subprocesso expandido que mostra suas etapas internas (como</p><p>na Fig. 4.1 ).</p><p>Página 119</p><p>4.1 Decomposição do Processo 99</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 114/192</p><p>Fig. 4.2 Uma versão simplificada do processo de atendimento do pedido após ocultar o conteúdo de seu sub</p><p>processos</p><p>Exercício 4.1 Identificar subprocessos adequados no processo de avaliação do pedido de empréstimo</p><p>complicações modeladas no Exercício 3.5 .</p><p>Dica Use os blocos de construção que você criou ao longo dos Exercícios 3.1 - 3.4 .</p><p>O recolhimento de um subprocesso não implica a perda de seu conteúdo. O subprocesso</p><p>ainda está lá, apenas definido em um nível de abstração abaixo. Na verdade, podemos aninhar sub-</p><p>processos em vários níveis, de modo a decompor um modelo de processo hierarquicamente. A</p><p>exemplo é mostrado na Fig. 4.3 , que modela um processo de negócios para desembolsar em casa</p><p>empréstimos. No primeiro nível, identificamos dois subprocessos: um para verificar o aplicativo</p><p>responsabilidade da cantora, a outra pela assinatura do empréstimo. No segundo nível, nós fatoramos fora</p><p>o agendamento do desembolso do empréstimo dentro do processo de assinatura de empréstimos em um</p><p>subprocesso separado.</p><p>Conforme descemos na decomposição hierárquica de um modelo de processo, podemos adicionar</p><p>mais detalhes. Por exemplo, podemos estabelecer uma convenção que, no nível superior,</p><p>apenas modelar atividades de negócios centrais, no segundo nível, adicionamos pontos de decisão, e</p><p>assim por diante, até a modelagem de exceções e detalhes que são relevantes apenas para</p><p>Automação do processo.</p><p>Pergunta Quando devemos decompor um modelo de processo em subprocessos?</p><p>Devemos usar subprocessos sempre que um modelo se torna muito grande que é difícil de</p><p>Compreendo. Embora seja difícil definir com precisão quando um modelo de processo é "muito grande",</p><p>uma vez que a compreensibilidade é subjetiva,</p><p>foi demonstrado que usando mais do que ap-</p><p>cerca de 30 objetos de fluxo (ou seja, atividades, eventos, gateways) leva a um aumento</p><p>probabilidade de cometer erros em um modelo de processo (por exemplo, introdução comportamental é-</p><p>processa). Assim, sugerimos usar o mínimo de elementos possível para cada modelo de processo</p><p>nível, e em particular para decompor um modelo de processo se este tiver mais de 30 fluxos</p><p>objetos.</p><p>Reduzir o tamanho de um modelo de processo, por exemplo, recolhendo seu sub</p><p>processos, é uma das maneiras mais eficazes de melhorar a leitura de um modelo de processo</p><p>habilidade. Outros aspectos estruturais que afetam a legibilidade incluem a densidade do</p><p>Página 120</p><p>100 4 Modelagem Avançada de Processos</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 115/192</p><p>Fig. 4.3 Um modelo de processo para desembolso de empréstimos imobiliários, estabelecido em três níveis hierárquicos via</p><p>o uso de subprocessos</p><p>conexões de modelo de processo, o número de ramificações paralelas, o caminho mais longo de um</p><p>início para um evento final, bem como aspectos cosméticos, como o layout, o estilo dos rótulos</p><p>(por exemplo, sempre use um estilo verbo-substantivo), a paleta de cores, a espessura das linhas, etc. Mais</p><p>informações sobre o estabelecimento de diretrizes de modelagem de processos podem ser encontradas no Cap. 5 .</p><p>Mostramos que podemos simplificar um modelo de processo identificando primeiro o</p><p>conteúdo de um subprocesso e, em seguida, ocultando esse conteúdo recolhendo o subprocesso</p><p>atividade. Às vezes, podemos desejar prosseguir na direção oposta, o que significa que</p><p>ao modelar um processo, já identificamos atividades que podem ser divididas em</p><p>etapas menores, mas intencionalmente subespecificamos seu conteúdo. Em outras palavras, nós</p><p>não vincule a atividade de subprocesso a um modelo de processo em um nível inferior de captura</p><p>seu conteúdo (como se ao pressionar o botão de adição nada aconteceria). O motivo</p><p>fazer isso é dizer ao leitor que algumas atividades são compostas de subetapas, mas</p><p>que revelar os detalhes destes não é relevante. Este poderia ser o caso de atividade</p><p>"Enviar produto" no exemplo de atendimento do pedido, para o qual modelar a distinção</p><p>entre suas etapas internas para embalagem e para envio não é relevante.</p><p>4.2 Reutilizar Processo</p><p>Por padrão, um subprocesso é incorporado em seu modelo de processo pai e, como tal</p><p>ele só pode ser chamado de dentro desse modelo de processo. Muitas vezes, ao modelar um</p><p>processo de negócios, podemos precisar reutilizar partes de outros modelos de processo do mesmo</p><p>organização. Por exemplo, um provedor de empréstimo pode reutilizar o subprocesso para assinar</p><p>Página 121</p><p>4.2 Reutilizar Processo 101</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 116/192</p><p>Fig. 4.4 O modelo de processo para desembolsar empréstimos estudantis invoca o mesmo modelo para assinar empréstimos</p><p>usado pelo processo de desembolso de empréstimos imobiliários, por meio de uma atividade de chamada</p><p>empréstimos contidos no desembolso do empréstimo à habitação para outros tipos de empréstimo, como um</p><p>processo para desembolsar empréstimos estudantis ou empréstimos para automóveis.</p><p>Em BPMN, podemos definir o conteúdo de um subprocesso fora de seu processo pai,</p><p>definindo o subprocesso como um modelo de processo global . Um modelo de processo global é</p><p>um modelo de processo que não está embutido em nenhum modelo de processo e, como tal, pode</p><p>ser chamado por outros modelos de processo dentro da mesma coleção de modelos de processo. Para</p><p>indicam que o subprocesso que está sendo invocado é um modelo de processo global, usamos o</p><p>atividade de subprocesso recolhida com uma borda mais espessa (este tipo de atividade é chamado de chamada</p><p>atividade em BPMN). Voltando ao exemplo de desembolso de empréstimo da Fig. 4.3 , nós</p><p>pode fatorar o subprocesso para assinar empréstimos e defini-lo como um processo global</p><p>modelo, de modo que também possa ser invocado por um modelo de processo para desembolsar alunos</p><p>empréstimos (ver Fig. 4.4 ).</p><p>Questão Subprocesso integrado ou global?</p><p>Nossa escolha padrão deve ser definir subprocessos como modelos de processos globais</p><p>de modo a maximizar sua reutilização em nossa coleção de modelos de processos. De apoio</p><p>processos como pagamento, faturamento, RH, impressão, são bons candidatos para serem</p><p>definidos como modelos de processos globais, uma vez que são normalmente compartilhados por vários negócios</p><p>processos dentro de uma organização. Além da reutilização, outra vantagem de usar</p><p>modelos de processos globais é que qualquer mudança feita nesses modelos será automatizada</p><p>propagados para todos os modelos de processo que os invocam. Em alguns casos, no entanto,</p><p>podemos querer manter as mudanças internas a um processo específico. Por exemplo, um</p><p>O processo de faturamento usado para liquidação de pedidos corporativos normalmente seria diferente</p><p>Página 122</p><p>102 4 Modelagem Avançada de Processos</p><p>do processo de faturamento para pedidos privados. Neste caso, devemos manter dois modelos</p><p>variantes do subprocesso de fatura, cada uma incorporada em seu modelo de processo pai:</p><p>liquidação de pedidos corporativos e privados.</p><p>Exemplo 4.1 Vamos considerar o processo de aquisição de uma empresa farmacêutica.</p><p>Uma empresa farmacêutica possui diferentes unidades de negócios em seu departamento de fabricação</p><p>mento, cada um produzindo um tipo específico de medicamento. Por exemplo, existe uma unidade de negócios</p><p>cuidando de medicamentos inalatórios e outro produzindo vacinas. Os vários negócios</p><p>unidades de negócios fazem uso de um processo de aquisição direto para solicitar produtos químicos, e de um</p><p>processo de aquisição indireta para solicitar peças de reposição para seus equipamentos.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 117/192</p><p>O processo de aquisição direta depende das matérias-primas que são necessárias paraproduzir um tipo específico de medicamento. Por exemplo, as vacinas normalmente incluem ad-</p><p>juvants que ajudam a melhorar a eficácia da vacina, que não estão contidos em</p><p>medicamentos inalados. Da mesma forma, os medicamentos inalados contêm um propelente químico</p><p>para empurrar o medicamento para fora do inalador, o que não é necessário para as vacinas. Desde a</p><p>este processo de aquisição é específico para cada unidade de negócios, precisamos modelá-lo como</p><p>um subprocesso embutido no modelo de processo de fabricação de cada unidade. Em</p><p>por outro lado, o processo de pedido de peças de reposição para o equipamento de sintetização</p><p>produtos químicos podem ser compartilhados entre todas as unidades, uma vez que todas as unidades fazem uso do mesmo</p><p>equipamento. Assim, vamos modelar esse processo com um modelo de processo global.</p><p>Antes de concluir nossa discussão sobre os subprocessos, precisamos apontar alguns</p><p>regras sintáticas para usar este elemento. Um subprocesso é um modelo de processo regular. isto</p><p>deve começar com pelo menos um evento inicial e terminar com pelo menos um evento final.</p><p>Se houver vários eventos de início, o subprocesso será acionado pelo primeiro</p><p>um evento que ocorre. Se houver vários eventos finais, o subprocesso retornará</p><p>controle para seu processo pai apenas quando cada token fluindo neste modelo atinge</p><p>um evento final. Além disso, não podemos cruzar o limite de um subprocesso com um</p><p>fluxo de sequência. Para passar o controle para um subprocesso ou receber o controle de um subprocesso,</p><p>devemos sempre usar eventos de início e término. Por outro lado, os fluxos de mensagens podem</p><p>cruzar os limites de um subprocesso para indicar mensagens que emanam ou são</p><p>direcionado a atividades ou eventos internos do subprocesso.</p><p>Exercício 4.2 Identifique subprocessos adequados no processo de negócios do Exercício 1.7 .</p><p>Entre esses subprocessos, identifique aqueles que são específicos para este processo de negócios</p><p>versus aqueles que podem ser potencialmente</p><p>compartilhados com outros processos de negócios do mesmo</p><p>companhia.</p><p>4.3 Mais sobre retrabalho e repetição</p><p>No capítulo anterior, descrevemos como modelar retrabalho e repetição por meio do</p><p>Gateways XOR. Subprocessos expandidos oferecem uma maneira alternativa de modelar peças</p><p>de um processo que pode ser repetido. Vamos considerar novamente o processo de abordagem</p><p>Página 123</p><p>4.3 Mais sobre retrabalho e repetição 103</p><p>Fig. 4.5 O modelo de processo para endereçar correspondência ministerial da Fig. 3.13 simplificado</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 118/192</p><p>usando uma atividade de loop</p><p>correspondência ministerial do Exemplo 3.7 . Para tornar este modelo mais simples, podemos</p><p>pegue o fragmento identificado pelo XOR-join e o XOR-split (que inclui</p><p>o bloco de repetição e o ramo de loopback) e substitua-o por um subprocesso</p><p>contendo as atividades no bloco de repetição. Para identificar que este sub-processo</p><p>pode ser repetido (se a resposta não for aprovada), marcamos a atividade do subprocesso</p><p>com um símbolo de loop, como mostrado na Fig. 4.5 . Podemos usar uma anotação para especificar o</p><p>condição do loop, por exemplo, “até a resposta aprovada”.</p><p>Como para qualquer subprocesso, você pode decidir não especificar o conteúdo de um loop</p><p>subprocesso. No entanto, se você fizer isso, não se esqueça de colocar uma atividade de decisão como o</p><p>última atividade dentro do subprocesso, caso contrário, não há como determinar quando</p><p>repita o subprocesso.</p><p>Pergunta Atividade de loop ou ciclo?</p><p>A atividade de loop é uma notação abreviada para um ciclo estruturado, ou seja, uma repetição</p><p>bloco delimitado por um único ponto de entrada para o ciclo, e um único ponto de saída de</p><p>o ciclo, como no exemplo acima. Às vezes, pode haver mais de um en-</p><p>tente e / ou ponto de saída, ou o ponto de entrada / saída pode estar dentro do bloco de repetição.</p><p>Considere, por exemplo, o modelo da Fig. 4.6 . Aqui, o bloco de repetição é feito</p><p>de atividades "Avaliar aplicação", "Notificar rejeição" e "Receber feed do cliente</p><p>costas"; o ciclo tem um ponto de entrada e dois pontos de saída, dos quais um dentro do</p><p>bloco de repetição. Quando um ciclo não estruturado tem vários pontos de saída, como neste</p><p>caso, uma atividade de loop não pode ser usada, a menos que condições adicionais sejam usadas para especificar</p><p>as situações em que o ciclo pode ser encerrado, o que tornará o modelo mais</p><p>complexo.</p><p>Exercício 4.3</p><p>1. Identifique os pontos de entrada e saída que delimitam os ciclos não estruturados no pro-</p><p>modelos de processamento mostrados na Solução 3.4 e no Exercício 3.9 . Quais são as repetições</p><p>blocos?</p><p>Página 124</p><p>104 4 Modelagem Avançada de Processos</p><p>Fig. 4.6 Um exemplo de ciclo não estruturado</p><p>2. Modelar o processo de negócios da Solução 3.4 usando uma atividade em loop.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 119/192</p><p>4.3.1 Repetição Paralela</p><p>A atividade de loop nos permite capturar a repetição sequencial, o que significa que as instâncias</p><p>da atividade de loop são executados um após o outro. Às vezes, porém, podemos</p><p>precisa executar várias instâncias da mesma atividade ao mesmo tempo, como no</p><p>seguinte exemplo.</p><p>Exemplo 4.2 Em um processo de aquisição, uma cotação deve ser obtida de todos os</p><p>fornecedores. Depois que todas as cotações são recebidas, elas são avaliadas e a melhor cotação é</p><p>selecionado. Um pedido de compra correspondente é então colocado.</p><p>Vamos supor que existam cinco fornecedores preferenciais. Então podemos usar uma divisão AND para</p><p>modelar cinco tarefas em paralelo, cada uma para obter uma cotação de um fornecedor, conforme mostrado em</p><p>Fig. 4.7 . No entanto, existem vários problemas com essa solução. Primeiro, quanto maior o</p><p>número de fornecedores, maior será o modelo resultante, uma vez que precisamos usar</p><p>uma tarefa por fornecedor. Em segundo lugar, precisamos revisar o modelo toda vez que o número</p><p>de mudanças de fornecedores. Na verdade, é frequentemente o caso na realidade que uma lista atualizada de</p><p>fornecedores é mantido em um banco de dados organizacional que é consultado antes de contatar</p><p>os fornecedores.</p><p>Para evitar esses problemas, o BPMN fornece um constructo chamado multi-instance ac-</p><p>atividade. Uma atividade de várias instâncias indica uma atividade (seja uma tarefa ou um subprocesso)</p><p>que é executado várias vezes simultaneamente. Tal construção é útil quando o</p><p>mesma atividade precisa ser executada para várias entidades ou itens de dados, como por ex-</p><p>suficiente para solicitar cotações de vários fornecedores (como em nosso exemplo), para verificar o</p><p>disponibilidade de cada item de linha em um pedido separadamente, para enviar e coletar perguntas</p><p>naires para várias testemunhas no contexto de uma reclamação de seguro, etc.</p><p>Uma atividade multi-instância é descrita como uma atividade marcada com três pequenas ver-</p><p>linhas ticas na parte inferior. A Figura 4.8 mostra uma versão revisada da aquisição</p><p>modelo de processo na Fig. 4.7 . Este modelo não é apenas menor, mas também pode funcionar com</p><p>uma lista dinâmica de fornecedores, que pode mudar a cada caso.</p><p>Página 125</p><p>4.3 Mais sobre retrabalho e repetição 105</p><p>Fig. 4.7 Obtenção de cotações de cinco fornecedores</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 120/192</p><p>Para fazer isso, adicionamos uma tarefa para recuperar a lista de fornecedores e passamos essa lista para um</p><p>tarefa multi-instância, que contacta os vários fornecedores. Você teria notado</p><p>que neste exemplo também marcamos a lista de fornecedores do objeto de dados com o</p><p>símbolo de várias instâncias. Isso é usado para indicar uma coleção de objetos de dados semelhantes,</p><p>como uma lista de itens de pedido ou uma lista de clientes. Quando uma coleção é usada como entrada</p><p>para uma atividade multi-instância, o número de itens na coleção determina o</p><p>número de instâncias de atividades a serem criadas. Como alternativa, podemos especificar o número</p><p>de instâncias a serem criadas por meio de uma anotação na atividade de várias instâncias (por exemplo, “15</p><p>fornecedores ”ou“ conforme base de dados de fornecedores ”).</p><p>Voltemos ao nosso exemplo. Suponha que a lista de fornecedores se tornou bastante</p><p>grande ao longo do tempo, digamos que haja 20 fornecedores no banco de dados. De acordo com nossa organização</p><p>políticas, no entanto, cinco cotações de cinco fornecedores diferentes são suficientes para fazer um</p><p>decisão. Assim, não queremos esperar que todos os 20 fornecedores respondam ao nosso</p><p>pedido de orçamento. Para fazer isso, podemos anotar a atividade de várias instâncias com o</p><p>número mínimo de instâncias que precisam ser concluídas antes de passar o controle para o</p><p>arco de saída (por exemplo, “complete quando cinco cotações forem obtidas”, como mostrado na Fig. 4.8 ).</p><p>Quando a atividade multi-instância é acionada, 20 tokens são gerados, cada marcação</p><p>o andamento de uma das 20 instâncias. Então, assim que as primeiras cinco instâncias</p><p>completo, todas as outras instâncias são canceladas (os respectivos tokens são destruídos)</p><p>e um token é enviado ao arco de saída para conclusão do sinal.</p><p>Vamos pegar o exemplo de atendimento de pedido na Fig. 4.2 e expandir o conteúdo de</p><p>o subprocesso de aquisição de matérias-primas. Para tornar este modelo mais realista, nós</p><p>pode usar um subprocesso multi-instância no lugar da estrutura delimitada pelos dois</p><p>Gateways OU, assumindo que a lista de fornecedores a serem contatados será determinada</p><p>Página 126</p><p>106 4 Modelagem Avançada de Processos</p><p>Fig. 4.8 Obtenção de cotações de vários fornecedores, cujo número não é conhecido a priori</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 121/192</p><p>Fig. 4.9 Usando um pool de múltiplas instâncias para representar múltiplos fornecedores</p><p>em tempo real a partir de um banco de dados de fornecedores (o modelo atualizado é mostrado na Fig. 4.9 ). Pelo</p><p>mesmo princípio,</p><p>substituímos os dois pools "Fornecedor 1" e "Fornecedor 2" por um único</p><p>pool, ou seja, "Fornecedor", que também marcamos com o símbolo de várias instâncias - um</p><p>pool multi-instância representa um conjunto de classes de recursos, ou recursos, tendo</p><p>características.</p><p>Página 127</p><p>4.3 Mais sobre retrabalho e repetição 107</p><p>A partir desta figura, notamos que existem quatro fluxos de mensagens conectados ao sub</p><p>processo “Envio e fatura”, como resultado do colapso do conteúdo desta atividade.</p><p>A ordem em que essas mensagens são trocadas é determinada pelas atividades</p><p>dentro deste subprocesso que os recebe e envia. Em outras palavras, quando se trata</p><p>para uma atividade de subprocesso recolhida, a semântica da mensagem para as tarefas descritas em</p><p>Sect. 3.4 não é aplicado.</p><p>Exercício 4.4 Modelar o seguinte fragmento de processo.</p><p>Após um acidente de carro, um depoimento é solicitado a duas testemunhas das cinco que foram</p><p>presente, para reclamar o sinistro. Assim que as duas primeiras declarações forem re-</p><p>citado, o sinistro pode ser feito na seguradora sem esperar pelo outro</p><p>afirmações.</p><p>4.3.2 Repetição não controlada</p><p>Às vezes, podemos precisar modelar que uma ou mais atividades podem ser repetidas em</p><p>número de vezes, sem uma ordem específica, até que uma condição seja atendida. Por exemplo, deixe</p><p>presumimos que o cliente de nosso processo de atendimento de pedidos precisa perguntar sobre</p><p>o progresso de seu pedido. O cliente pode fazer isso simplesmente enviando um e-mail para</p><p>o vendedor. Isso pode ser feito a qualquer momento após o cliente ter enviado a compra</p><p>pedido e com a frequência que o cliente desejar. Da mesma forma, o cliente pode tentar</p><p>cancelar o pedido ou atualizar seus dados pessoais antes que o pedido seja atendido.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 122/192</p><p>Essas atividades são descontroladas , no sentido de que podem ser repetidas múltiplas</p><p>vezes sem ordem específica, ou sem ocorrer de forma alguma, até que uma condição seja atendida - no nosso caso</p><p>o pedido sendo atendido.</p><p>Para modelar um conjunto de atividades não controladas, podemos usar um subprocesso ad-hoc .</p><p>A Figura 4.10 mostra o exemplo do processo do cliente, onde a conclusão</p><p>condição (“até que o pedido seja atendido”) foi especificada por meio de uma anotação. O anúncio</p><p>O subprocesso hoc é marcado com um símbolo de til na parte inferior da caixa do subprocesso.</p><p>Uma ordem parcial pode ser estabelecida entre as atividades de um subprocesso ad-hoc</p><p>por meio do fluxo de sequência. No entanto, não podemos representar eventos de início e fim em um anúncio</p><p>subprocesso hoc.</p><p>Exercício 4.5 Modele o seguinte fragmento de processo.</p><p>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</p><p>os pré-selecionados são então chamados a fazer os seguintes testes: drogas e álcool, olhos, visão de cores,</p><p>audição, sangue, urina, peso, impressão digital e exame médico. A visão colorida pode</p><p>só pode ser feito após o exame de vista, enquanto o exame médico só pode ser feito após a coloração</p><p>visão, audição, sangue, urina e peso foram testados. Além disso, pode ser necessário</p><p>para alguns candidatos repetir alguns desses testes várias vezes para obter uma correta</p><p>avaliação, por exemplo, o exame de sangue pode precisar ser repetido se o candidato tiver tomado muito</p><p>açúcar nas 24 horas anteriores. Os candidatos que passam em todos os testes são convidados a sentar-se em um mental</p><p>exame e exame físico, seguido de entrevista. Só aqueles que também passam esses dois</p><p>exames e um bom desempenho na entrevista podem ser recrutados no exército.</p><p>Página 128</p><p>108 4 Modelagem Avançada de Processos</p><p>Fig. 4.10 Usando um subprocesso ad-hoc para modelar a repetição não controlada</p><p>4.4 Tratamento de eventos</p><p>Como apontamos no cap. 3 , os eventos são usados para modelar algo que acontece em</p><p>instantaneamente em um processo. Vimos eventos iniciais, que sinalizam como as instâncias de processo</p><p>início (tokens são criados) e eventos finais, que sinalizam quando as instâncias do processo são</p><p>completo (os tokens são destruídos). Quando um evento ocorre durante um processo, por exemplo</p><p>uma confirmação de pedido é recebida após o envio de um pedido ao cliente e</p><p>antes de prosseguir com o embarque, o evento é denominado intermediário . Um token re-</p><p>rede presa no fluxo de sequência de entrada de um evento intermediário até o</p><p>evento ocorre. Então o token atravessa o evento instantaneamente, ou seja, os eventos podem</p><p>não retém tokens. Um evento intermediário é representado como um círculo com uma dupla</p><p>fronteira.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 123/192</p><p>4.4.1 Eventos de Mensagem</p><p>No capítulo anterior, mostramos que podemos marcar um evento de início com um en-</p><p>velope para especificar que novas instâncias de processo são acionadas pelo recebimento de uma mensagem</p><p>(cf. Fig. 3.16 ). Além do evento de mensagem inicial, também podemos marcar um evento de término e</p><p>um evento intermediário com um envelope para capturar a interação entre nossos</p><p>cesso e outra parte. Esses tipos de evento são chamados coletivamente de eventos de mensagem .</p><p>Um evento de mensagem final sinaliza que um processo é concluído após o envio de uma mensagem.</p><p>Um evento de mensagem intermediária sinaliza o recebimento de uma mensagem, ou que uma mensagem</p><p>acaba de ser enviado, durante a execução do processo. Mensagem intermediária e final</p><p>eventos sábios representam uma notação alternativa para as atividades que são usadas exclusivamente</p><p>para enviar ou receber uma mensagem. Tome, por exemplo, atividades “Devolver o aplicativo ao ap-</p><p>plicant ”e“ Receber aplicativos atualizados ”na Fig. 4.11 a, que é um extrato do</p><p>modelo de avaliação de empréstimos da Solução 3.7 . É mais significativo substituir o anterior</p><p>atividade com um evento de envio de mensagem intermediário e a última atividade com um evento</p><p>termedia o recebimento do evento de mensagem, conforme ilustrado na Fig. 4.11 b, uma vez que essas atividades</p><p>Página 129</p><p>4.4 Tratamento de eventos 109</p><p>Fig. 4.11 Substituindo atividades que apenas enviam ou recebem mensagens ( a ) por eventos de mensagem ( b )</p><p>não representam realmente unidades de trabalho, mas sim o envio ou recebimento mecânico</p><p>de uma mensagem. Um evento de mensagem intermediário que recebe uma mensagem é descrito como</p><p>um evento de mensagem inicial, mas com uma borda dupla. Se o evento intermediário sinalizar um</p><p>mensagem sendo enviada, o envelope é escurecido.</p><p>Além disso, se a atividade de envio for seguida imediatamente por um evento final sem tipo,</p><p>podemos substituir isso por um evento de mensagem final, uma vez que, novamente, esta atividade é apenas</p><p>usado para enviar uma mensagem após a qual o processo é concluído. Um evento de mensagem final</p><p>é representado como um evento final marcado com um envelope escurecido. Cuidado, isso é um começo</p><p>O evento de mensagem não é uma notação alternativa para um evento de início não tipado seguido</p><p>por uma atividade de recepção: essas duas construções não são intercambiáveis. Na antiga</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 124/192</p><p>caso, as instâncias do processo iniciam após o recebimento de uma mensagem específica; no ultimo</p><p>caso, as instâncias de processo podem iniciar a qualquer momento, após o qual a primeira atividade requer um</p><p>mensagem a ser executada.</p><p>Pergunta Evento digitado ou não digitado?</p><p>Sugerimos especificar o tipo de evento sempre que conhecido, pois</p><p>ajudar o leitor a entender melhor o modelo do processo.</p><p>Exercício 4.6 Existe alguma outra atividade no modelo de avaliação de empréstimo da Solução 3.7</p><p>que pode ser substituído por um evento de mensagem?</p><p>Na BPMN, os eventos vêm em dois sabores com base no preenchimento de seu marcador.</p><p>Um marcador sem preenchimento, como aquele no evento de mensagem inicial, denota um evento de captura ,</p><p>ou seja, um evento que captura</p><p>um gatilho, normalmente originado de fora do processo.</p><p>Um marcador com um preenchimento escuro como aquele no evento de mensagem final denota um lançamento</p><p>Página 130</p><p>110 4 Modelagem Avançada de Processos</p><p>Fig. 4.12 Usando eventos de cronômetro para conduzir as várias atividades de um processo de negócios</p><p>evento , ou seja, um evento que lança um gatilho de dentro do processo. Um intermediário</p><p>evento de mensagem tem ambos os tipos, pois pode ser usado como um evento de captura (o</p><p>a mensagem é recebida de outro pool) ou como um evento de lançamento (a mensagem é enviada</p><p>para outra piscina).</p><p>4.4.2 Eventos Temporais</p><p>Além do evento de mensagem, existem outros gatilhos que podem ser especificados para um início</p><p>evento. Vale a pena notar o evento do cronômetro . Este tipo de evento indica que o processo</p><p>instâncias começam na ocorrência de um evento temporal específico, por exemplo, toda sexta-feira</p><p>manhã, todos os dias úteis do mês, todas as manhãs às 7h.</p><p>Um evento temporizador também pode ser usado como evento intermediário, para modelar uma inter</p><p>val que precisa decorrer antes que a instância do processo possa prosseguir. Para indicar um cronômetro</p><p>evento, marcamos o símbolo do evento com um relógio de luz dentro do círculo. Eventos de cronômetro</p><p>estão capturando eventos apenas porque um cronômetro é um gatilho fora do controle do processo.</p><p>Em outras palavras, o processo não gera o cronômetro, mas reage a ele.</p><p>Exemplo 4.3 Vamos considerar o seguinte processo em um tribunal de pequenas causas.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 125/192</p><p>Em um tribunal de pequenas causas, as chamadas ocorrem uma vez por mês, para definir o assunto para o</p><p>próximos ensaios. O processo de configuração de uma chamada começa três semanas antes da chamada</p><p>dia, com a preparação da lista de chamadas contendo informações como detalhes de contato de</p><p>as partes envolvidas e a data estimada de audiência. Uma semana antes da chamada, o envolvido</p><p>as partes são contatadas para determinar se estão todas prontas para ir a julgamento. Se for esse o caso, o</p><p>a chamada é definida, caso contrário, é adiada para o próximo slot disponível. Finalmente, no dia da chamada,</p><p>o material da chamada é preparado e a chamada é retida.</p><p>Este processo é conduzido por três eventos temporais: ele começa três semanas antes de</p><p>a data da chamada, continua uma semana antes da data da chamada e termina em</p><p>o dia da chamada. Para modelar esses eventos temporais, precisamos de um início e</p><p>dois eventos de temporizador intermediários, conforme mostrado na Fig. 4.12 . Vamos ver como isso</p><p>cesso funciona do ponto de vista da semântica do token. Um token capturando um novo in</p><p>postura é gerada toda vez que for três semanas antes da data da chamada (nós</p><p>suponha que esta data foi agendada por outro processo). Uma vez que a primeira atividade</p><p>Página 131</p><p>4.4 Tratamento de eventos 111</p><p>“Prepare callover list” foi completada, o token é enviado através da entrada</p><p>arco do seguinte evento temporizador intermediário, ou seja, "1 semana antes da chamada</p><p>dia". O evento torna-se assim habilitado . O token permanece preso na entrada</p><p>arco progressivo deste evento até que o próprio evento temporal ocorra, ou seja, apenas quando for um</p><p>semana antes do dia da chamada. Uma vez que este for o caso, o token instantaneamente tra-</p><p>vira o símbolo do evento e se move para o arco de saída. É por isso que os eventos são</p><p>dito ser instantâneo , uma vez que não pode reter tokens em oposição a atividades,</p><p>que retêm tokens durante a sua execução (lembre-se de que as atividades</p><p>sume time).</p><p>Exercício 4.7 Modelar o processo de faturamento de um provedor de serviços de Internet (ISP).</p><p>O ISP envia uma fatura por e-mail para o cliente no primeiro dia útil de cada mês</p><p>(Dia 1). No dia 7, o cliente tem o valor total pendente debitado automaticamente</p><p>de sua conta bancária. Se uma transação automática falhar por qualquer motivo, o cliente</p><p>é notificado no Dia 8. No Dia 9, a transação que falhou no Dia 7 é tentada novamente. E se</p><p>ele falha novamente, no dia 10 uma taxa de atraso é cobrada na conta bancária do cliente. Neste</p><p>estágio, o pagamento automático não é mais tentado. No dia 14, o serviço de Internet é</p><p>suspenso até que o pagamento seja recebido. Se no dia 30 o pagamento ainda estiver pendente, o</p><p>conta é encerrada e uma taxa de desconexão é aplicada. Um procedimento de recuperação de dívidas é então</p><p>começado.</p><p>4.4.3 Eventos de corrida</p><p>Um cenário típico encontrado ao modelar processos com eventos é aquele</p><p>onde dois eventos externos competem um contra o outro. O primeiro dos dois eventos que</p><p>ocorre determina a continuação do processo. Por exemplo, após um seguro</p><p>a cotação foi enviada a um cliente, o cliente pode responder com uma mensagem de aceitação</p><p>sábio, caso em que será feito um contrato de seguro, ou com rejeição, no qual</p><p>caso a citação seja descartada.</p><p>Esta corrida entre eventos externos é capturada por meio do exclu-</p><p>divisão sive ( XOR ). Uma divisão exclusiva baseada em evento é representada por um gateway marcado</p><p>por um pentágono vazio encerrado em um círculo de linha dupla. A Figura 4.13 apresenta um evento</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 126/192</p><p>divisão exclusiva baseada. Quando a execução do processo chega a este ponto (em</p><p>outras palavras - quando um token chega a este gateway), a execução para até ei-</p><p>então o evento de mensagem ou o evento de temporizador ocorre. Qualquer que seja o evento que ocorrer primeiro,</p><p>determinar de que maneira a execução irá prosseguir. Se o evento temporizador ocorrer primeiro, um</p><p>A consulta do status da remessa será iniciada e o fluxo de execução voltará para</p><p>o gateway exclusivo baseado em eventos. Se a mensagem que sinaliza a entrega do frete é</p><p>recebido primeiro, o fluxo de execução continuará ao longo do fluxo de sequência que leva a</p><p>a junção AND.</p><p>A diferença entre a divisão XOR que vimos no cap. 3 e o baseado em evento</p><p>A divisão XOR é que o primeiro modela uma escolha interna que é determinada pela</p><p>vêm de uma atividade de decisão, enquanto o último modela uma escolha que é determinada</p><p>Página 132</p><p>112 4 Modelagem Avançada de Processos</p><p>Fig. 4.13 Uma condição de corrida entre uma mensagem recebida e um temporizador</p><p>pelo ambiente de processo. 1 Uma escolha interna é determinada pelo resultado de um</p><p>atividade de decisão. Assim, a divisão XOR baseada em evento só pode ser seguida por interme-</p><p>diate capturando eventos como um cronômetro ou um evento de mensagem, ou recebendo atividades. Desde a</p><p>a escolha é atrasada até que um evento aconteça, a divisão baseada em evento também é conhecida como</p><p>escolha diferida . Não há junção XOR baseada em evento, então as ramificações que emanam de</p><p>uma divisão baseada em evento é mesclada com uma junção XOR normal.</p><p>Exercício 4.8 Modele o seguinte processo.</p><p>Uma rede de restaurantes envia um pedido de compra (PO) para reabastecer seus depósitos a cada quinta-feira</p><p>dia. O sistema de compras da rede de restaurantes espera receber uma "Resposta PO"</p><p>ou uma mensagem de erro. No entanto, também pode acontecer que nenhuma resposta seja recebida devido a</p><p>erros do sistema ou devido a atrasos no tratamento da OC por parte do fornecedor. Se nenhuma resposta for</p><p>recebido até sexta-feira à tarde ou se uma mensagem de erro for recebida, um gerente de compras no</p><p>a sede da rede de restaurantes deve ser notificada. Caso contrário, a resposta PO é processada</p><p>normalmente.</p><p>A divisão baseada em eventos pode ser usada como a contrapartida de uma decisão interna sobre</p><p>uma parte colaboradora. Por exemplo, uma escolha feita de dentro do pool de clientes para</p><p>enviar uma mensagem de aceitação ou rejeição para uma seguradora, precisa ser</p><p>correspondido por uma decisão orientada por evento no pool da seguradora para reagir à escolha feita</p><p>pelo cliente. Este exemplo é ilustrado na Fig. 4.14 .</p><p>Gateways baseados em eventos podem ser usados para evitar anomalias comportamentais</p><p>comunicação entre</p><p>piscinas. Tome por exemplo o diagrama de colaboração entre o</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 127/192</p><p>serviço de leilão e o vendedor na Fig. 4.15 . Esta colaboração pode causar um impasse se o</p><p>vendedor já está cadastrado, pois esta parte irá aguardar a solicitação de criação de conta</p><p>mensagem que, nesse caso, nunca chegará. Para corrigir esse problema, precisamos permitir que</p><p>vendedor receberá a mensagem de confirmação de criação imediatamente, caso o vendedor seja</p><p>já cadastrado, conforme mostrado na Fig. 4.16 .</p><p>1 Especificamente, a divisão XOR do cap. 3 é chamado de divisão XOR baseada em dados, uma vez que o ramo a tomar é</p><p>com base na avaliação de duas ou mais condições nos dados que são produzidos por uma atividade de decisão.</p><p>Página 133</p><p>4.4 Tratamento de eventos 113</p><p>Fig. 4.14 Combinando uma escolha interna em uma parte com uma escolha baseada em evento na outra parte</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 128/192</p><p>Fig. 4.15 Um exemplo de colaboração de deadlock entre dois pools</p><p>Página 134</p><p>114 4 Modelagem Avançada de Processos</p><p>Fig. 4.16 Usando um gateway baseado em evento para consertar a colaboração de deadlock da Fig. 4.15</p><p>Ao conectar pools entre si por meio de fluxos de mensagens, certifique-se de verificar</p><p>a ordem dessas conexões para evitar deadlocks. Lembre-se, em particular, que</p><p>uma decisão interna em uma das partes deve ser correspondida por uma decisão baseada em eventos em</p><p>a outra parte, e que uma atividade com um fluxo de mensagens de saída enviará esse</p><p>mensagem após a conclusão da atividade, enquanto uma atividade com uma mensagem de entrada</p><p>o fluxo aguardará o início dessa mensagem.</p><p>Exercício 4.9 Corrija o diagrama de colaboração na Fig. 4.17 .</p><p>Agradecimento Este exercício é parcialmente inspirado por: Niels Lohmann: “Corrigindo</p><p>Deadlocking Service Coreographies Usando um gráfico baseado em simulação Edit Dis-</p><p>tância ”. LNCS 5240, Springer, 2008.</p><p>4.5 Tratamento de exceções</p><p>Exceções são eventos que desviam um processo de seu curso normal, ou seja, do que</p><p>é comumente conhecido como o cenário de “dia ensolarado”. Essas situações de “dia chuvoso” acontecem</p><p>caneta frequentemente na realidade, e como tal, devem ser modelados quando o objetivo é</p><p>para identificar todas as possíveis causas de problemas em um determinado processo. As exceções incluem</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 129/192</p><p>falhas de negócios, como uma exceção devido a um produto fora de estoque ou descontinuado,</p><p>e falhas de tecnologia, como falha do banco de dados, interrupção da rede ou lógica do programa</p><p>violação. Eles desviam o curso normal do processo, pois causam a interrupção</p><p>Página 135</p><p>4.5 Tratamento de exceções 115</p><p>Fig. 4.17 Um diagrama de colaboração entre um cliente, uma agência de viagens e uma companhia aérea</p><p>ou aborto do processo em execução. Por exemplo, no caso de um produto fora de estoque</p><p>de fato, um processo de pedido para pagamento pode precisar ser interrompido para solicitar o produto de</p><p>um fornecedor, ou abortado completamente se o produto não puder ser fornecido dentro de um determinado</p><p>prazo.</p><p>4.5.1 Processo de aborto</p><p>A maneira mais simples de lidar com uma exceção é abortar o processo de execução e sinalizar</p><p>um encerramento impróprio do processo. Isso pode ser feito usando um evento end terminate ,</p><p>como mostrado na Fig. 4.18 . Um evento de término de término (descrito como um evento de término marcado</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 130/192</p><p>Página 136</p><p>116 4 Modelagem Avançada de Processos</p><p>Fig. 4.18 Usando um evento de término para sinalizar o término impróprio do processo</p><p>com um círculo completo dentro), causa a cessação imediata da instância do processo em</p><p>seu nível atual e para qualquer subprocesso.</p><p>No exemplo da Fig. 4.18 - uma variante do empréstimo imobiliário que já vimos na</p><p>Fig. 4.3 - um empréstimo imobiliário é rejeitado e o processo é abortado se o requerente tiver</p><p>dívidas e / ou baixa responsabilidade. De uma semântica de token, o evento de encerramento destrói todos</p><p>tokens no modelo de processo e em qualquer subprocesso. Em nosso exemplo, isso é necessário</p><p>para evitar que o processo de deadlock na junção AND, uma vez que um token pode permanecer preso</p><p>antes do AND-join se houver alta responsabilidade e dívidas ou baixa responsabilidade e nenhuma dívida.</p><p>Observe que se um evento de encerramento for disparado de dentro de um subprocesso, ele</p><p>não causa o aborto do processo parental, mas apenas o do subprocesso, ou seja, o</p><p>O evento de término é propagado apenas para baixo em uma hierarquia de processo.</p><p>Exercício 4.10 Revise os exemplos apresentados até agora neste capítulo, usando o</p><p>encerrar o evento de forma adequada.</p><p>4.5.2 Exceções Internas</p><p>Em vez de abortar todo o processo, podemos lidar com uma exceção interrompendo</p><p>a atividade específica que causou a exceção. Em seguida, podemos iniciar uma recuperação</p><p>procedimento para trazer o processo de volta a um estado consistente e continuar sua execução,</p><p>e se isso não for possível, somente então aborte o processo completamente. BPMN fornece</p><p>o evento de erro para capturar esses tipos de cenário. Um evento de erro final é usado para</p><p>interromper o subprocesso de inclusão e lançar uma exceção. Esta exceção é então</p><p>capturado por um evento de erro de captura intermediário que está anexado ao limite de</p><p>o mesmo subprocesso. Por sua vez, este evento limite aciona o procedimento de recuperação</p><p>através de uma ramificação de saída que é chamada de fluxo de exceção .</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 131/192</p><p>Página 137</p><p>4.5 Tratamento de exceções 117</p><p>Fig. 4.19 Exceções internas do modelo de eventos de erro</p><p>O evento de erro é descrito como um evento com um marcador de relâmpago. Seguindo o</p><p>Convenções BPMN para eventos de lançamento e captura, o raio está vazio para o</p><p>pegando evento intermediário e cheio para o evento de lançamento final.</p><p>Um exemplo de eventos de erro é mostrado na Fig. 4.19 no contexto de nosso atendimento de pedido</p><p>processo de enchimento. Se houver uma exceção de falta de estoque, a aquisição de matéria-prima</p><p>als é interrompido e o procedimento de recuperação é acionado, que neste caso simplesmente</p><p>consiste em uma tarefa de notificar o cliente antes de abortar o processo. Em termos de</p><p>semântica de token, ao lançar um evento de erro final, todos os tokens são removidos de</p><p>o subprocesso envolvente (causando sua interrupção), e um token é enviado por meio</p><p>o fluxo de exceção proveniente do evento de erro de limite. Não há restrição</p><p>sobre os elementos de modelagem, podemos colocar no fluxo de exceção para modelar a recuperação</p><p>procedimento. Normalmente, concluiríamos o fluxo de exceção com uma terminação final</p><p>evento para abortar o processo, ou conectar este fluxo de volta ao fluxo de sequência normal se o</p><p>exceção foi tratada corretamente.</p><p>4.5.3 Exceções Externas</p><p>Uma exceção também pode ser causada por um evento externo que ocorre durante uma atividade.</p><p>Por exemplo, ao verificar a disponibilidade de estoque para o produto em uma compra</p><p>pedido, o vendedor pode receber um cancelamento do pedido do cliente. Sobre este</p><p>pedido, o vendedor deve interromper a verificação de disponibilidade de estoque e lidar com o pedido</p><p>cancelamento. Cenários como o acima são chamados de exceções não solicitadas, pois</p><p>originam-se externamente ao processo. Eles podem ser capturados anexando um</p><p>evento de mensagem intermediária para o limite de uma atividade, conforme mostrado na Fig. 4.20 . De</p><p>uma semântica de token, quando o evento de mensagem intermediário é acionado, o token é</p><p>removido da atividade envolvente, consequentemente causando a interrupção da atividade,</p><p>e enviado através do fluxo de exceção proveniente do evento de fronteira, para realizar</p><p>o procedimento de recuperação.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 132/192</p><p>Página 138</p><p>118 4 Modelagem Avançada de Processos</p><p>Fig. 4.20 Eventos de limite</p><p>capturar eventos externos que podem</p><p>ocorrer durante uma atividade</p><p>Antes de usar um evento de fronteira, precisamos identificar o escopo dentro do qual o</p><p>processo deve ser receptivo a este evento. Por exemplo, no atendimento de pedido ex-</p><p>amplo, os pedidos de cancelamento de pedido só podem ser tratados durante a execução da tarefa</p><p>“Verificar disponibilidade de estoque”. Assim, fica aberto o espaço para ser receptivo a este evento</p><p>por esta única tarefa. Às vezes, o escopo deve incluir várias atividades. No</p><p>nesses casos, podemos encapsular as atividades interessadas em um subprocesso e em</p><p>anexe o evento ao limite do subprocesso.</p><p>Exercício 4.11 Modele a seguinte rotina para fazer login em um banco na Internet</p><p>contagem.</p><p>A rotina de login em uma conta bancária na Internet começa assim que as credenciais forem inseridas</p><p>do usuário foram recuperados. Primeiro, o nome de usuário é validado. Se o nome de usuário não for</p><p>válido, a rotina é interrompida e o nome de usuário inválido é registrado. Se o nome de usuário for válido,</p><p>o número de tentativas de senha é definido como zero. Então a senha é validada. Se este não for</p><p>válido, o contador para o número de tentativas é incrementado e se menor que três, o usuário</p><p>é solicitado a inserir a senha novamente, desta vez junto com um teste CAPTCHA para aumentar</p><p>o nível de segurança. Se o número de tentativas malsucedidas atingir três vezes, a rotina não</p><p>terrupted e a conta está congelada. Além disso, a validação do nome de usuário e senha pode</p><p>ser interrompido caso o servidor de validação não esteja disponível. Da mesma forma, o servidor para testar o</p><p>O CAPTCHA pode não estar disponível no momento do login. Nestes casos, o procedimento é inter-</p><p>interrompida após notificar o usuário para tentar novamente mais tarde. A qualquer momento durante a rotina de login, o</p><p>o cliente pode fechar a página web, resultando na interrupção da rotina.</p><p>4.5.4 Tempo limite de atividade</p><p>Outro tipo de exceção é aquela provocada pela interrupção de uma atividade que</p><p>está demorando muito para ser concluído. Para modelar que uma atividade deve ser concluída dentro</p><p>um determinado prazo (por exemplo, uma aprovação deve ser concluída dentro de 24 horas), podemos</p><p>anexar um evento temporizador intermediário ao limite da atividade: o temporizador está ativo</p><p>vated quando a atividade envolvente começa, e se dispara antes da conclusão da atividade,</p><p>provoca a interrupção da atividade. Em outras palavras, um evento temporizador funciona como um tempo limite</p><p>quando anexado ao limite de uma atividade.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 133/192</p><p>Página 139</p><p>4.5 Tratamento de exceções 119</p><p>Fig. 4.21 Sem interrupção</p><p>eventos de fronteira pegam</p><p>eventos externos que ocorrem</p><p>durante uma atividade, e acionar</p><p>um procedimento paralelo sem</p><p>interrompendo o fechamento</p><p>atividade</p><p>Exercício 4.12 Modele o seguinte fragmento de processo.</p><p>Assim que um pedido de atacado for confirmado, o fornecedor transmite esse pedido para o carro</p><p>rier para a preparação do orçamento de transporte. A fim de preparar a cotação, o carro</p><p>rier precisa computar o plano de rota (incluindo todos os pontos da trilha que precisam ser percorridos</p><p>durante a viagem) e estimar o uso do trailer (por exemplo, se é uma carga completa, metade</p><p>track-load ou um único pacote). Por contrato, os pedidos de atacado devem ser despachados dentro de</p><p>quatro dias a partir do recebimento do pedido. Isso implica que as cotações de transporte devem ser</p><p>preparado dentro de 48 horas a partir do recebimento do pedido para permanecer dentro dos termos do</p><p>contrato.</p><p>4.5.5 Eventos sem interrupção e exceções complexas</p><p>Existem situações em que um evento externo ocorrendo durante uma atividade deve apenas</p><p>acionar um procedimento sem interromper a atividade em si. Por exemplo, no pedido</p><p>processo de atendimento, o cliente pode enviar uma solicitação para atualizar seus detalhes durante</p><p>a verificação de disponibilidade de estoque. Os detalhes devem ser atualizados no banco de dados do cliente</p><p>sem interromper a verificação de estoque. A fim de denotar que o evento limite é</p><p>não interrompendo , usamos uma borda dupla tracejada, como mostrado na Fig. 4.21 .</p><p>Exercício 4.13 Estenda o processo de avaliação dos pedidos de empréstimo da Solução 3.7 como</p><p>segue.</p><p>Um requerente que decidiu não combinar seu empréstimo com um plano de seguro residencial pode</p><p>mudar de ideia a qualquer momento antes de a avaliação de elegibilidade ser concluída. Se um pedido</p><p>para adicionar um plano de seguro é recebido durante este período, o provedor de empréstimo irá simplesmente</p><p>atualize o pedido de empréstimo com este pedido.</p><p>Eventos sem interrupção podem ser usados para modelar tratamento de exceção mais complexo</p><p>cenários. Considere novamente o exemplo na Fig. 4.19 e assuma que o cliente</p><p>envia uma solicitação de cancelamento do pedido durante a aquisição da matéria-prima. Nós pegamos</p><p>esta solicitação com um evento de mensagem de limite sem interrupção, e primeiro determine</p><p>Página 140</p><p>120 4 Modelagem Avançada de Processos</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 134/192</p><p>Fig. 4.22 Eventos de não interrupção podem ser usados em combinação com eventos de sinal para modelar</p><p>cenários de manipulação de exceção plex</p><p>a penalidade que o cliente terá de incorrer com base nas matérias-primas que</p><p>já foram encomendados. Encaminhamos essas informações ao cliente que então</p><p>pode decidir em 48 horas interromper o cancelamento, caso em que nada</p><p>está pronto ou prossiga (veja a Fig. 4.22 ). No último caso, lançamos um sinal de fim</p><p>evento . Este evento, representado por um marcador triangular, transmite um sinal definido por</p><p>o rótulo do evento, que pode ser capturado por todos os eventos de sinalização de captura com o</p><p>mesmo rótulo. Em nosso caso, lançamos um sinal de "Pedido cancelado" e captamos isso com um</p><p>evento de sinal intermediário correspondente no limite do subprocesso para adquirir</p><p>matéria prima. Este evento faz com que o subprocesso envolvente seja interrompido e</p><p>em seguida, aciona um procedimento de recuperação para cobrar do cliente, após o qual o processo é</p><p>abortado. Observamos que neste cenário a interrupção da atividade é desencadeada a partir de</p><p>dentro do processo, mas fora da própria atividade.</p><p>Observe que o evento de sinal é diferente do evento de mensagem, uma vez que tem</p><p>uma fonte, mas nenhum destino específico, enquanto uma mensagem tem uma fonte específica e um</p><p>alvo específico. Assim como as mensagens, os sinais também podem se originar de um processo modelado</p><p>em um diagrama separado.</p><p>Página 141</p><p>4.5 Tratamento de exceções 121</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 135/192</p><p>Fig. 4.23 Subprocessos de eventos podem ser usados no lugar de eventos de fronteira e para capturar eventos lançados</p><p>fora do escopo de um subprocesso específico</p><p>4.5.6 Interlúdio: Subprocessos do Evento</p><p>Uma notação alternativa para eventos de fronteira é o subprocesso de evento . Um evento sub-</p><p>o processo é iniciado pelo evento que de outra forma seria anexado ao limite</p><p>de uma atividade, e inclui o procedimento que seria acionado pelo limite</p><p>evento. Uma diferença importante com os eventos de fronteira é que os subprocessos do evento</p><p>não precisa se referir a uma atividade específica, mas pode modelar eventos que ocorrem durante o</p><p>execução de todo o processo. Por exemplo, a qualquer momento durante o atendimento do pedido</p><p>processo, o cliente pode enviar uma consulta sobre o status do pedido. Para lidar com isso</p><p>solicitação, que não é específica para uma determinada atividade deste processo, podemos usar um</p><p>subprocesso de evento, conforme mostrado na Fig. 4.23 .</p><p>O subprocesso</p><p>do evento é representado em um retângulo pontilhado com cantos arredondados</p><p>que é colocado em um subprocesso expandido ou no processo de nível superior. Semelhante</p><p>para eventos de fronteira, um subprocesso de evento pode ou não interromper o</p><p>processo dependendo se seu evento de início está interrompendo ou não. Se for o evento inicial</p><p>não interrompe, isso é representado por uma borda tracejada (única).</p><p>Todas as regras sintáticas para um subprocesso se aplicam ao subprocesso do evento, exceto para</p><p>eventos de fronteira, que não podem ser definidos em subprocessos de eventos. Por exemplo, o</p><p>o subprocesso do evento também pode ser representado como um subprocesso recolhido. Nesse caso,</p><p>o evento inicial é representado no canto superior esquerdo do subprocesso do evento recolhido</p><p>retângulo para indicar como este subprocesso de evento é acionado.</p><p>Pergunta Subprocessos de evento ou eventos de limite?</p><p>Os subprocessos do evento são independentes, o que significa que devem ser concluídos com</p><p>um evento final. Isso tem a desvantagem de que o procedimento capturado dentro de um evento</p><p>Página 142</p><p>122 4 Modelagem Avançada de Processos</p><p>o subprocesso não pode ser conectado de volta ao restante do fluxo de sequência. A vantagem</p><p>é que um subprocesso de evento também pode ser definido como um modelo de processo global e, portanto,</p><p>ser reutilizado em outros modelos de processos da mesma organização. Outra vantagem é</p><p>que os subprocessos do evento podem ser definidos no nível de um processo inteiro, enquanto</p><p>os eventos de fronteira devem se referir a uma atividade específica. Assim, sugerimos o uso de eventos</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 136/192</p><p>subprocessos quando o evento que precisa ser tratado pode ocorrer durante o en-</p><p>processo de pneu, ou quando precisamos capturar um procedimento reutilizável. Para todos os outros casos,</p><p>eventos de fronteira são mais apropriados, uma vez que o procedimento desencadeado por esses eventos</p><p>pode ser conectado de volta ao resto do fluxo.</p><p>Exercício 4.14 Modelar o seguinte processo de negócios para reembolso de despesas.</p><p>Depois que um relatório de despesas é recebido de um funcionário, o funcionário é notificado do</p><p>recebimento do relatório. Em seguida, uma nova conta deve ser criada se o funcionário ainda não</p><p>tem um. O relatório é então revisado para aprovação automática. Valores abaixo de € 1.000 são</p><p>aprovado automaticamente enquanto os valores iguais ou superiores a € 1.000 requerem aprovação manual.</p><p>Em caso de rejeição, o colaborador deve receber um aviso de rejeição por e-mail. No caso de</p><p>aprovação, o reembolso é depositado diretamente na conta do funcionário. Em qualquer</p><p>tempo durante a revisão, o funcionário pode enviar uma Solicitação de retificação de valor. Naquilo</p><p>caso a retificação seja registrada e o relatório precise ser revisado novamente. Além disso, se</p><p>o relatório não é tratado em 30 dias, o processo é interrompido e o funcionário recebe</p><p>um e-mail de aviso de cancelamento para que ele possa reenviar o relatório de despesas do zero.</p><p>4.5.7 Remuneração de Atividades</p><p>Como parte de um procedimento de recuperação, podemos precisar desfazer uma ou mais etapas que tenham</p><p>já foi concluída, devido a uma exceção que ocorreu no sub</p><p>processo. Na verdade, os resultados dessas etapas, e possivelmente seus efeitos colaterais, podem não</p><p>mais desejados e por este motivo devem ser revertidos. Esta operação é</p><p>chamado de compensação e tenta restaurar o processo para um estado de negócios próximo ao</p><p>um antes de iniciar o subprocesso que foi interrompido.</p><p>Vamos nos aprofundar no subprocesso para envio e tratamento de faturas do pedido</p><p>exemplo de cumprimento e assumir que também esta atividade pode ser interrompida no</p><p>recepção de uma solicitação de cancelamento de pedido (ver Fig. 4.24 ). Depois de comunicar o</p><p>penalidade de cancelamento para o cliente, precisamos reverter os efeitos do envio</p><p>e do pagamento. Especificamente, se a remessa já foi feita, precisamos</p><p>tratar da devolução do produto, visto que se o pagamento já tiver sido feito, precisamos</p><p>reembolsar o cliente. Essas compensações podem ser modeladas por meio de uma compensação</p><p>manipulador . Um manipulador de compensação é composto de um evento de compensação de lançamento (um</p><p>evento marcado com um símbolo de retrocesso), um evento de compensação intermediário de captura e</p><p>uma atividade de compensação. O evento de compensação de lançamento é usado dentro da recuperação</p><p>procedimento de uma exceção para iniciar a compensação, e pode ser um intermediário</p><p>diate ou um evento final (no último caso, o procedimento de recuperação termina com o</p><p>compensação). O evento de compensação intermediário de captura é anexado àqueles</p><p>atividades que precisam ser compensadas - em nosso exemplo "Enviar produto" e "Re-</p><p>pagamento máximo ”. Esses eventos de limite capturam a solicitação de compensação e acionam</p><p>Página 143</p><p>4.5 Tratamento de exceções 123</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 137/192</p><p>Fig. 4.24 Compensando o envio e o pagamento</p><p>uma atividade de compensação específica para a atividade a ser compensada. Por exemplo o</p><p>a atividade de compensação para “Receber pagamento” é “Reembolsar cliente”. O limite</p><p>evento ary está conectado à atividade de compensação por meio de uma seta pontilhada com um</p><p>ponta de seta, chamada de associação de compensação (cuja notação é igual à de</p><p>a associação de dados). Esta atividade é marcada com o símbolo de compensação para indicar</p><p>citar a sua finalidade, não devendo haver fluxo de saída: caso a compensação</p><p>procedimento é complexo, esta atividade pode ser um subprocesso.</p><p>A compensação só é eficaz se a atividade anexada foi concluída. Uma vez que todos</p><p>atividades que poderiam ser compensadas são compensadas, o processo recomeça a partir de um</p><p>após o evento de compensação de lançamento, a menos que seja um evento final. Se a compensação</p><p>é para todo o processo, podemos usar um subprocesso de evento com uma compensação de início</p><p>evento no lugar do evento limite.</p><p>Nesta seção, vimos várias maneiras de lidar com exceções em negócios</p><p>cesso, do simples processo de aborto ao tratamento de exceções complexas. Antes de adicionar</p><p>exceções, é importante entender bem o cenário do dia ensolarado. Então comece por</p><p>modelando isso. Em seguida, pense em todas as situações possíveis que podem dar errado. Para cada um de</p><p>essas exceções, identifique que tipo de mecanismo de tratamento de exceção precisa ser</p><p>usava. Primeiro, determine a causa da exceção: interna ou externa. Em seguida, decida</p><p>se abortar o processo é suficiente, ou se um procedimento de recuperação precisa ser acionado.</p><p>Finalmente, avalie se a atividade interrompida precisa ser compensada como parte do</p><p>o procedimento de recuperação.</p><p>Página 144</p><p>124 4 Modelagem Avançada de Processos</p><p>Fig. 4.25 A reposição</p><p>o pedido é acionado sempre</p><p>os níveis de estoque caem abaixo de um</p><p>limite</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 138/192</p><p>Exercício 4.15 Modifique o modelo que você criou no Exercício 4.14 da seguinte maneira.</p><p>Se a denúncia não for tratada em 30 dias, o processo é interrompido, o funcionário recebe um</p><p>e-mail de aviso de cancelamento e deve reenviar o relatório de despesas. No entanto, se o reembolso-</p><p>para as despesas do funcionário já foi feito, um recall de dinheiro precisa ser feito,</p><p>para obter o dinheiro de volta do funcionário, antes de enviar o e-mail de aviso de cancelamento.</p><p>4.6 Processos e Regras de Negócios</p><p>Uma regra de negócios implementa uma política ou prática organizacional. Por exemplo, em</p><p>uma loja online, os clientes platinum têm um desconto de 20% para cada compra acima</p><p>€ 250. As regras de negócios podem aparecer em diferentes formas em um modelo de processo. Nós temos</p><p>vi-os modelados em uma atividade de decisão e na condição de um fluxo saindo</p><p>de uma divisão (X) OR (consulte o Exercício 3.5 para alguns exemplos).</p><p>. 353</p><p>10.1.1 A perspectiva dos participantes sobre a execução do processo. . . 354</p><p>10.1.2 A perspectiva do proprietário do processo no processo</p><p>Execução. . . . . . . . . . . . . . . . . . . . . . . . . . 354</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 14/192</p><p>10.1.3 StructureofEventLogs. . . . . . . . . . . . . . . . . . . 356</p><p>10.1.4 Desafios deExtractingEventLogs. . . . . . . . . . . . 359</p><p>10.2 AutomaticProcessDiscovery. . . . . . . . . . . . . . . . . . . . 360</p><p>10.2.1 Premissas do α- Algoritmo. . . . . . . . . . . . . . 360</p><p>10.2.2 As relações de ordem do α- Algoritmo. . . . . . . . . . 361</p><p>10.2.3 O algoritmo α . . . . . . . . . . . . . . . . . . . . . . . 364</p><p>10.2.4 RobustProcessDiscovery. . . . . . . . . . . . . . . . . . 366</p><p>10.3 Análise de desempenho. . . . . . . . . . . . . . . . . . . . . . . . 367</p><p>10.3.1 Medição de tempo. . . . . . . . . . . . . . . . . . . . . 367</p><p>10.3.2 Medição de custos. . . . . . . . . . . . . . . . . . . . . . 369</p><p>10.3.3 QualityMeasurement. . . . . . . . . . . . . . . . . . . . 370</p><p>10.3.4 FlexibilidadeMedida. . . . . . . . . . . . . . . . . . . 372</p><p>10.4 Verificação de conformidade. . . . . . . . . . . . . . . . . . . . . . . 373</p><p>10.4.1 Conformidade do Fluxo de Controle. . . . . . . . . . . . . . . . 374</p><p>10.4.2 Conformidade de Dados e Recursos. . . . . . . . . . . . 377</p><p>10.5 Recapitulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378</p><p>10.6 Soluções para exercícios. . . . . . . . . . . . . . . . . . . . . . . . 379</p><p>10.7 Exercícios adicionais. . . . . . . . . . . . . . . . . . . . . . . . . . 382</p><p>10.8 Leitura adicional. . . . . . . . . . . . . . . . . . . . . . . . . . . 382</p><p>Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385</p><p>Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391</p><p>Página 15</p><p>Siglas</p><p>6 mi Máquina, Método, Material, Homem, Medição, Meio</p><p>4 P Políticas, procedimentos, pessoas, planta / equipamento</p><p>7PMG Sete Diretrizes de Modelagem de Processo</p><p>abc Custeio baseado em atividades</p><p>APQC Centro Americano de Produtividade e Qualidade</p><p>ATAMO E então, um milagre ocorre</p><p>B2B De empresa para empresa</p><p>BAM Monitoramento de Atividades de Negócios</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 15/192</p><p>BOM Lista de materiais</p><p>BPA Análise de Processo de Negócios</p><p>BPEL Linguagem de execução de processos de negócios de serviços da Web</p><p>BPM Gestão de Processos de Negócios</p><p>BPMN Modelo de Processo de Negócios e Notação</p><p>BPMS Sistema de Gestão de Processos de Negócios</p><p>BPR Reengenharia do processo de negócios</p><p>BTO Construir sob encomenda</p><p>BVA Agregação de valor comercial</p><p>CEO CEO</p><p>Diretor FinanceiroDiretor financeiro</p><p>CIO Diretor de Informação</p><p>CMMI Modelo de maturidade de capacidade integrado</p><p>COO Diretor de Operações</p><p>CPO Diretor de Processos</p><p>CRM Gestão de Relacionamento com o Cliente</p><p>CPN Rede Petri Colorida</p><p>CT Tempo de Ciclo</p><p>DBMS Sistema de gerenciamento de banco de dados</p><p>DCOR Referência de operações da cadeia de design (design do produto)</p><p>DES Simulação de eventos discretos</p><p>DMR Departamento de estradas principais</p><p>DMS Sistema de gestão de documentos</p><p>xix</p><p>Página 16</p><p>xx Siglas</p><p>DUR Avaliação do uso de drogas</p><p>EPA Agência de Proteção Ambiental</p><p>EPC Cadeia de processos orientada a eventos</p><p>ERP Planejamento de Recursos Empresariais</p><p>eTOM Mapa aprimorado de operações de telecomunicações</p><p>FIFO Primeiro a entrar, primeiro a sair</p><p>RH Recursos humanos</p><p>IDEF3 Definição Integrada para Método de Captura de Descrição de Processo</p><p>ISP Provedor de internet</p><p>ISTO Tecnologia da informação</p><p>ITIL Biblioteca de infraestrutura de tecnologia da informação</p><p>KM Gestão do conhecimento</p><p>KPI Indicador-Chave de Desempenho</p><p>NRW Departamento de Recursos Naturais e Água</p><p>NVA Não-agregador de valor</p><p>OÁSIS Organização para o Avanço das Informações Estruturadas</p><p>Padrões</p><p>AMD Grupo de Gerenciamento de Objetos</p><p>SO Sistema operacional</p><p>PCF Estrutura de classificação de processos</p><p>PD Desenvolvimento de Produto</p><p>PDCA A planta faz o ato de verificação</p><p>PO Ordem de Compra</p><p>POS Ponto de venda</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 16/192</p><p>PPM Medição de Desempenho de Processo</p><p>RBAC Controle de acesso baseado em função</p><p>RFID Identificação de rádio frequencia</p><p>RFQ Pedido de Orçamento</p><p>ROI Retorno sobre o investimento</p><p>Método de avaliação CMMI padrão SCAMPI para melhoria de processos</p><p>SCOR Modelo de referência de operações da cadeia de suprimentos</p><p>Sistema de avaliação de desenvolvimento eletrônico inteligente eDA inteligente</p><p>SOA Arquitetura Orientada a Serviços</p><p>STP Straight-Through-Processing</p><p>TCT Tempo do Ciclo Teórico</p><p>TOC Teoria das Restrições</p><p>TQM Gestão de qualidade Total</p><p>UIMS Sistema de gerenciamento de interface do usuário</p><p>UEL Linguagem de Expressão Universal</p><p>UML Linguagem de modelagem unificada</p><p>Diagrama de atividades UML AD UML</p><p>VA Agregação de valor</p><p>VCH Hierarquia de Criação de Valor</p><p>VCS Sistema de Criação de Valor</p><p>VRM Modelo de Referência de Valor</p><p>Página 17</p><p>Siglas xxi</p><p>WIP Trabalho em progresso</p><p>WfMC Coalizão de Gestão de Fluxo de Trabalho</p><p>WfMS Sistema de gerenciamento de fluxo de trabalho</p><p>Linguagem de execução de processos de negócios de serviços da Web WS-BPEL</p><p>WSDL Linguagem de definição de serviço da web</p><p>XES Fluxo de eventos extensível</p><p>XML Extensible Markup Language</p><p>XSD Definição de Esquema XML</p><p>YAWL Outra linguagem de fluxo de trabalho</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 17/192</p><p>Página 18</p><p>Lista de Figuras</p><p>Fig.1.1 Ingredientesdeprocesso de negócios. . . . . . . . . . . . . . . . . 6</p><p>Fig. 1.2 Como o processo saiu de foco ao longo dos tempos. . . . . . 8</p><p>Fig. 1.3 Processo de compra na Ford em estágio inicial. . . . . . . . . . . 10</p><p>Fig. 1.4 Processo de compra na Ford após redesenho. . . . . . . . . . . . . 11</p><p>Fig. 1.5 Funções de trabalho de um gerente responsável por um processo (também conhecido como</p><p>proprietário do processo) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14</p><p>Fig. 1.6 Modelo de processo para um fragmento inicial do aluguel de equipamentos</p><p>processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17</p><p>Fig.1.7 BPMlifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . . 21</p><p>Fig. 2.1 Os diferentes níveis de detalhe em uma arquitetura de processo. . . . . . 42</p><p>Fig. 2.2 Uma arquitetura de processo para uma autoridade portuária. . . . . . . . . . . 44</p><p>Fig. 2.3 Decomposições funcionais diferentes dentro do mesmo</p><p>organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48</p><p>Fig.2.4 Acase / functionmatrix. . . . . . . . . . . . . . . . . . . . . . . 49</p><p>Fig. 2.5 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 18/192</p><p>(aplicando a Diretriz1). . . . . . . . . . . . . . . . . . . . . . . 50</p><p>Fig. 2.6 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo</p><p>(aplicando as Diretrizes 2-7). . . . . . . . . . . . . . . . . . . . . 54</p><p>Fig. 2.7 Uma matriz de caso / função evoluindo para um modelo de paisagem de processo</p><p>(aplicando a Diretriz 8). . . . . . . . . . . . . . . . . . . . . . . 54</p><p>Fig. 2.8 Um mapa de processo para o processo de pagamento da hipoteca. . . . . . . . 56</p><p>Fig. 3.1 O diagrama de um processo simples de atendimento de pedidos. . . . . . . . 64</p><p>Fig. 3.2 Progresso de três instâncias do processo de atendimento do pedido. . . . 65</p><p>Fig. 3.3 Um edifício ( a ), sua miniatura de madeira ( b ) e sua planta ( c ).</p><p>(( b ): © 2010, Bree Industries; ( c ): usado com permissão de</p><p>planetclaire.org) . . . . . . . . . . . . . . . . . . . . . . . . . 66</p><p>Fig. 3.4 Um exemplo do uso de gateways XOR. . . . . . . . . . . . . 68</p><p>Fig. 3.5 Um exemplo do uso de gateways AND. . . . . . . . . . . . . 70</p><p>Fig. 3.6 Uma versão mais elaborada do processo de atendimento de pedidos</p><p>diagrama. . . . .</p><p>Uma terceira opção é usar</p><p>um evento BPMN dedicado denominado evento condicional . Um evento condicional causa o</p><p>ativação do seu fluxo de saída quando a respectiva regra de negócio for cumprida. Condi-</p><p>eventos internacionais, identificados por um marcador de página alinhado, podem ser usados como início ou intermediário</p><p>captura de eventos, incluindo após um gateway baseado em evento ou anexado a uma atividade</p><p>fronteira. Um exemplo de evento condicional é mostrado na Figura 4.25 .</p><p>A diferença entre um evento condicional intermediário e uma condição em um</p><p>fluxo é que o último é testado apenas uma vez, e se não for satisfeito o correspondente</p><p>o fluxo não é obtido (outro fluxo ou o fluxo padrão será usado no lugar). A condição</p><p>O evento opcional, por outro lado, é testado até que a regra associada seja satisfeita. Em outro</p><p>palavras, o token permanece preso antes do evento até que a regra seja satisfeita.</p><p>No exemplo da Fig. 4.25 , observe o uso do evento de erro no limite de</p><p>uma atividade de várias instâncias. Este evento interrompe apenas a instância de atividade que se refere</p><p>ao produto específico sendo descontinuado, ou seja, a instância a partir da qual o erro</p><p>evento é lançado. Todos os outros eventos de limite de interrupção, ou seja, mensagem, temporizador, sinal</p><p>e condicional, interromper todas as instâncias de uma atividade de várias instâncias.</p><p>Exercício 4.16 Modele o seguinte fragmento de processo de negócios.</p><p>Página 145</p><p>4.7 Coreografias de Processo 125</p><p>Em uma bolsa de valores, as variações dos preços das ações são monitoradas continuamente durante o dia. Um dia</p><p>começa quando o sino de abertura toca e termina quando o sino de fechamento toca. Entre o</p><p>dois sinos, cada vez que o preço das ações muda em mais de 10%, a entidade da mudança é</p><p>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</p><p>O alerta de “preço baixo das ações” é enviado.</p><p>4.7 Coreografias de Processo</p><p>Às vezes, pode ser difícil enquadrar uma colaboração de negócios entre dois ou mais</p><p>partes, por exemplo, duas organizações, trabalhando diretamente no nível da colaboração</p><p>diagrama. Primeiro, o diagrama de colaboração é normalmente de nível muito baixo e se os termos</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 139/192</p><p>das interações entre as duas partes ainda não estão claras, pode ser confuso paramisturar aspectos de comunicação com atividades internas. Em segundo lugar, uma parte pode não ser</p><p>para expor suas atividades internas a outras partes (por exemplo, a lógica por trás de uma reclamação</p><p>a aprovação deve permanecer privada). Assim, pode ser oportuno focar primeiro no</p><p>interações que devem ocorrer entre todas as partes envolvidas, e na ordem em que</p><p>essas interações podem ocorrer. No BPMN, essas informações são capturadas por um chore-</p><p>diagrama de ografia . Um diagrama de coreografia é o modelo de processo das interações</p><p>ocorrendo entre duas ou mais partes. Esta visão de alto nível em atos de colaboração</p><p>como um contrato entre todas as partes envolvidas. Uma vez que este contrato foi elaborado, cada</p><p>parte pode pegar e refinar em seus processos privados ou, alternativamente, todas as partes</p><p>podem trabalhar juntos para refinar a coreografia em um diagrama de colaboração.</p><p>A Figura 4.26 mostra a coreografia para a colaboração no atendimento de pedidos de</p><p>Fig. 4.9 . Como podemos ver, uma coreografia é de fato um modelo de processo: é iniciada por</p><p>um ou mais eventos iniciais e concluídos por um ou mais eventos finais, as atividades são</p><p>conectados por meio de fluxos de sequência e gateways são usados para ramificação e mesclagem. o</p><p>característica principal é, no entanto, que uma atividade representa uma interação entre dois</p><p>partidos, em vez de uma unidade de trabalho. Uma interação pode ser unilateral (uma mensagem é</p><p>trocados) ou bidirecionais (uma mensagem é seguida por uma mensagem de retorno no sentido oposto</p><p>direção). Cada interação tem um iniciador ou remetente (a parte que envia a mensagem</p><p>sábio), e um destinatário ou receptor (a parte que recebe a mensagem, que pode responder</p><p>com uma mensagem de retorno). Por exemplo, a primeira atividade da Fig. 4.26 , “Enviar pedido</p><p>ordem de busca ”ocorre entre o cliente, que envia o pedido de compra, e</p><p>o vendedor, que o recebe.</p><p>Uma atividade de coreografia é representada como uma caixa com cantos arredondados, onde dois</p><p>faixas, uma na parte superior, a outra na parte inferior da caixa, representam as duas partes</p><p>envolvidos na interação capturada pela atividade. Uma faixa de luz é usada para o</p><p>iniciador enquanto uma faixa escura é usada para o destinatário. A posição de cada banda</p><p>com relação à caixa é deixada para o modelador, desde que as duas bandas estejam opostas</p><p>lados. Um envelope anexado a uma faixa por meio de uma linha tracejada representa a mensagem enviada</p><p>por essa parte. Este envelope é escurecido se for a mensagem de retorno de uma via dupla</p><p>interação.</p><p>Uma relação de precedência entre duas interações só pode ser estabelecida se o</p><p>o iniciador da segunda interação está envolvido na interação anterior (como</p><p>Página 146</p><p>126 4 Modelagem Avançada de Processos</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 140/192</p><p>Fig. 4.26 O diagrama de coreografia para o diagrama de colaboração na Fig. 4.9</p><p>remetente ou como receptor), exceto para a primeira interação. Desta forma, o remetente de</p><p>a segunda interação 'sabe' quando isso pode ocorrer. Por outro lado, se houver</p><p>não há dependências de ordem entre duas ou mais interações, podemos vinculá-las</p><p>interações por meio de uma divisão AND, como mostrado na Fig. 4.26 . Certifique-se, no entanto, de que</p><p>o remetente de cada interação após a divisão está envolvido na interação anterior</p><p>o separamento.</p><p>Uma divisão (X) OR modela os resultados de uma decisão interna que é tomada por um</p><p>festa. Isso impõe que os dados sobre os quais a decisão é tomada sejam disponibilizados</p><p>para essa parte por meio de uma interação antes da divisão. Em nosso exemplo, os dados exigidos por</p><p>a divisão XOR é extrapolada do pedido de compra, que é enviado ao vendedor</p><p>na interação antes da divisão. Além disso, todas as interações imediatamente</p><p>após a divisão deve ser iniciada pela parte que tomou a decisão. Na nossa</p><p>Por exemplo, isso é feito pelo vendedor. Na verdade, não faz sentido que uma decisão tomada</p><p>por uma parte resulta em uma interação iniciada por outra parte - esta última não</p><p>ser capaz de saber os resultados da decisão nessa fase.</p><p>A divisão XOR baseada em evento é usada quando os dados para fazer uma escolha não são ex-</p><p>colocada por meio de uma interação antes da divisão. Assim, as partes não envolvidas no</p><p>decisão só saberá sobre isso com o recebimento de uma mensagem. Isso impõe que</p><p>as interações após uma divisão baseada em eventos devem ter o mesmo remetente ou</p><p>o mesmo receptor. Por exemplo, usamos uma divisão baseada em eventos para modelar uma situação</p><p>onde um requerente espera por uma mensagem de confirmação que pode chegar de</p><p>um corretor ou diretamente da seguradora (a decisão de qual parte interagir com</p><p>Página 147</p><p>4.7 Coreografias de Processo 127</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 141/192</p><p>Fig. 4.27 O diagrama de coreografia entre um vendedor, um cliente e uma transportadora</p><p>o requerente é levado pelo corretor juntamente com a seguradora). A Figura 4.27 mostra</p><p>outro exemplo: aqui, um vendedor espera por uma das três mensagens possíveis de um cliente</p><p>cliente, representando três tipos diferentes de reclamação. A decisão é tomada pelo</p><p>o cliente e o vendedor não estão cientes disso até que a reclamação específica seja recebida.</p><p>As interações após uma divisão baseada em eventos podem ser restringidas por um cronômetro. Nisso</p><p>Por exemplo, se o vendedor não receber nenhuma mensagem após cinco dias, eles irão acionar</p><p>uma interação para faturar o cliente. Neste caso,</p><p>. . . . . . . . . . . . . . . . . . . . . . . . . 71</p><p>xxiii</p><p>Página 19</p><p>xxiv Lista de Figuras</p><p>Fig. 3.7 Uma variante do processo de atendimento do pedido com dois diferentes</p><p>gatilhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72</p><p>Fig. 3.8 Modelando uma decisão inclusiva: primeiro julgamento. . . . . . . . . . . . . 73</p><p>Fig. 3.9 Modelando uma decisão inclusiva: segundo julgamento. . . . . . . . . . . 73</p><p>Fig. 3.10 Modelando uma decisão inclusiva com o gateway OR. . . . . . 74</p><p>Fig. 3.11 Que tipo o gateway de junção deve ter para que as instâncias</p><p>deste processo pode ser concluído corretamente? . . . . . . . . . . . . . . 75</p><p>Fig. 3.12 O diagrama do processo de atendimento do pedido com o produto</p><p>fabricação. . . . . . . . . . . . . . . . . . . . . . . . . . . 77</p><p>Fig. 3.13 Um modelo de processo para o tratamento de correspondência ministerial. . . 78</p><p>Fig. 3.14 O exemplo de atendimento de pedido com artefatos. . . . . . . . . . . 80</p><p>Fig. 3.15 O exemplo de atendimento de pedido com informações de recursos. . . . . 84</p><p>Fig. 3.16 Diagrama de colaboração entre um vendedor, um cliente e dois</p><p>fornecedores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87</p><p>Fig. 4.1 Identificação de subprocessos no processo de atendimento de pedidos</p><p>ofFig. 3,12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98</p><p>Fig. 4.2 Uma versão simplificada do processo de atendimento do pedido após ocultar</p><p>o conteúdo de seus subprocessos. . . . . . . . . . . . . . . . . . 99</p><p>Fig. 4.3 Um modelo de processo para desembolsar empréstimos imobiliários, estabelecido ao longo</p><p>três níveis hierárquicos por meio do uso de subprocessos. . . . . . . 100</p><p>Fig. 4.4 O modelo de processo para desembolsar empréstimos estudantis invoca o mesmo</p><p>modelo para assinatura de empréstimos usado pelo processo de desembolso para casa</p><p>empréstimos, via uma atividade. . . . . . . . . . . . . . . . . . . . . . 101</p><p>Fig. 4.5 O modelo de processo para o tratamento de correspondência ministerial</p><p>da Fig. 3.13 simplificado usando uma atividade de loop. . . . . . . . . . . . 103</p><p>Fig. 4.6 Um exemplo de ciclo não estruturado. . . . . . . . . . . . . . . . . 104</p><p>Fig.4.7 Obtenção de cotações de cinco fornecedores. . . . . . . . . . . . . . . 105</p><p>Fig. 4.8 Obtenção de cotações de vários fornecedores, cujo número não é</p><p>knownapriori. . . . . . . . . . . . . . . . . . . . . . . . . . . 106</p><p>Fig. 4.9 Usando um pool de várias instâncias para representar vários fornecedores. . . 106</p><p>Fig. 4.10 Usando um subprocesso ad-hoc para modelar a repetição não controlada. . 108</p><p>Fig. 4.11 Substituir atividades que apenas enviam ou recebem mensagens ( a )</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://planetclaire.org</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 19/192</p><p>com eventos de mensagem ( b ). . . . . . . . . . . . . . . . . . . . . . 109</p><p>Fig. 4.12 Usando eventos de cronômetro para conduzir as várias atividades de uma empresa</p><p>processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110</p><p>Fig. 4.13 Uma condição de corrida entre uma mensagem recebida e um cronômetro. . . 112</p><p>Fig. 4.14 Combinando uma escolha interna em uma festa com uma baseada em eventos</p><p>escolha na outra parte. . . . . . . . . . . . . . . . . . . . . . 113</p><p>Fig. 4.15 Um exemplo de colaboração de conflito entre dois pools. . 113</p><p>Fig. 4.16 Usando um gateway baseado em eventos para corrigir o impasse</p><p>colaboração doFig. 4,15 . . . . . . . . . . . . . . . . . . . . . 114</p><p>Fig. 4.17 Um diagrama de colaboração entre um cliente, uma agência de viagens e</p><p>anairline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115</p><p>Fig. 4.18 Usar um evento de término para sinalizar o término impróprio do processo. 116</p><p>Fig. 4.19 Os eventos de erro modelam exceções internas. . . . . . . . . . . . . . 117</p><p>Página 20</p><p>Lista de Figuras xxv</p><p>Fig. 4.20 Os eventos de limite capturam eventos externos que podem ocorrer durante um</p><p>atividade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118</p><p>Fig. 4.21 Eventos de limite não interrompidos capturam eventos externos que</p><p>ocorrer durante uma atividade e desencadear um procedimento paralelo sem</p><p>interromper a atividade envolvente. . . . . . . . . . . . . . . . . 119</p><p>Fig. 4.22 Os eventos sem interrupção podem ser usados em combinação com o sinal</p><p>eventos para modelar cenários complexos de tratamento de exceções. . . . . . 120</p><p>Fig. 4.23 Os subprocessos de evento podem ser usados no lugar de eventos de limite,</p><p>e para capturar eventos lançados de fora do escopo de um determinado</p><p>subprocesso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 121</p><p>Fig. 4.24 Compensando o envio e o pagamento. . . . . . . 123</p><p>Fig. 4.25 Um pedido de reabastecimento é acionado sempre que os níveis de estoque</p><p>dropbelowathreshold. . . . . . . . . . . . . . . . . . . . . . 124</p><p>Fig. 4.26 O diagrama de coreografia para o diagrama de colaboração em</p><p>Fig. 4.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126</p><p>Fig. 4.27 O diagrama de coreografia entre um vendedor, um cliente e um</p><p>transportadora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127</p><p>Fig. 4.28 Colaboração diagrama de peça 1 / 2 (fragmento de transferência de carga). . 140</p><p>Fig. 4.29 Colaboração diagrama de parte 2 / manuseamento de retorno 2 (mercadoria</p><p>fragmento). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141</p><p>Fig. 4.30 Coreografia diagrama de peça 1 / 2. . . . . . . . . . . . . . . . . 142</p><p>Fig. 4.31 Coreografia diagrama de parte 2 / 2. . . . . . . . . . . . . . . . . 143</p><p>Fig. 4.32 Colaboração diagrama de peça 1 / 3 (fragmento de estabelecimento de Crédito) 144</p><p>Fig. 4.33 Colaboração diagrama de parte 2 / 3 (fragmento de desembolso empréstimo) 145</p><p>Fig. 4.34 Diagrama de parte colaboração 3 / 3 (sub-processos). . . . . . . . 146</p><p>Fig. 5.1 As principais atividades e eventos do processo de atendimento de pedidos. . 168</p><p>Fig. 5.2 As atividades e eventos do processo de atendimento de pedidos</p><p>designados tapaosandlanes. . . . . . . . . . . . . . . . . . . . 169</p><p>Fig. 5.3 O fluxo de controle do processo de atendimento do pedido. . . . . . . . . 170</p><p>Fig. 5.4 Aspectos de qualidade e atividades de garantia de qualidade. . . . . . . . . . 172</p><p>Fig. 5.5 Fragmentos de processos comuns e não sólidos. . . . . . . . . 173</p><p>Fig. 5.6 Extrato do modelo do processo de atendimento do pedido com layout incorreto. . 175</p><p>Fig. 5.7 Extrato do modelo do processo de atendimento do pedido com bom layout. 175</p><p>Fig. 5.8 Um processo de tratamento de reclamações conforme encontrado na prática. . . . . . . . 177</p><p>Fig. 5.9 O processo de tratamento de reclamações foi retrabalhado. . . . . . . . . . . . 182</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 20/192</p><p>Fig. 5.10 Um processo de solicitação de empréstimo. . . . . . . . . . . . . . . . . . . . . 182</p><p>Fig.5.11 Asalescampaignprocess. . . . . . . . . . . . . . . . . . . . . 183</p><p>Fig. 6.1 Modelo de um diagrama de causa e efeito baseado nos 6M's. . . . . . 194</p><p>Fig. 6.2 Diagrama de causa-efeito para o problema "Equipamento rejeitado na entrega" 195</p><p>Fig.6.3 Templateofawhy – whydiagram. . . . . . . . . . . . . . . . . 197</p><p>Fig. 6.4 Gráfico de Pareto para despesas excessivas com aluguel de equipamentos. . . . . 202</p><p>Fig.6.5 PICKchart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204</p><p>Fig. 6.6 Gráfico de Pareto dos fatores causais do problema “Equipamento não disponível</p><p>quando necessário" . . . . . . . . . . . . . . . . . . . . . . . . . . . 208</p><p>Fig.7.1 Modelo de processo totalmente sequencial. . . . . . . . . . . . . . . . . . 219</p><p>Página 21</p><p>xxvi Lista de Figuras</p><p>Fig. 7.2 Modelo de processo com bloco XOR. . . . . . . . . . . . . . . . . . 220</p><p>Fig.7.3 Padrão de bloco XOR. . . . . . . . . . . . . . . . . . . . . . . . 220</p><p>Fig. 7.4 Modelo de processo com bloco AND. . . . . . . . . . . . . . . . . . 221</p><p>Fig.7.5 AND-blockpattern. . . . . . . . . . . . . . . . . . . . . . . . 221</p><p>Fig.7.6 Processo</p><p>de aplicação de crédito. . . . . . . . . . . . . . . . . . . . . 221</p><p>Fig.7.7 Exemplo de loop de trabalho. . . . . . . . . . . . . . . . . . . . . 222</p><p>Fig.7.8 Retrabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . 223</p><p>Fig. 7.9 Atividade que é retrabalhada no máximo uma vez. . . . . . . . . . . . . . 223</p><p>Fig. 7.10 Processo de aplicação de crédito com retrabalho. . . . . . . . . . . . . . 223</p><p>Fig. 7.11 Estrutura de um sistema M / M / 1 ou M / M / c, parâmetros de entrada e</p><p>parâmetros computáveis. . . . . . . . . . . . . . . . . . . . . . 233</p><p>Fig. 7.12 Histogramas produzidos por simulação do pedido de crédito</p><p>processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239</p><p>Fig. 7.13 Processo de reclamação de resolução de Cetera. . . . . . . . . . . . . . . 241</p><p>Fig.7.14 Processo de hipoteca. . . . . . . . . . . . . . . . . . . . . . . . . 249</p><p>Fig.8.1 TheDevil'sQuadrangle. . . . . . . . . . . . . . . . . . . . . . 259</p><p>Fig.8.2 Theintakeprocess. . . . . . . . . . . . . . . . . . . . . . . . . 274</p><p>Fig. 8.3 O processo de entrada após a reformulação do arquivo médico. . . . . . . . . 277</p><p>Fig. 8.4 O modelo de dados do produto do piloto do helicóptero. . . . . . . . . . . . . . 280</p><p>Fig. 8.5 Um projeto de processo incorreto para os dados de produto do piloto de helicóptero</p><p>modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286</p><p>Fig. 8.6 Um projeto de processo correto para os dados do produto piloto do helicóptero</p><p>modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286</p><p>Fig. 8.7 Um projeto de processo alternativo para o produto piloto de helicóptero</p><p>modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287</p><p>Fig. 8.8 Solução para a proposta de empréstimo. . . . . . . . . . . . . . . . . . . 291</p><p>Fig. 8.9 Um projeto de processo completo para os dados do produto piloto do helicóptero</p><p>modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292</p><p>Fig. 8.10 Um projeto de processo de baixo custo para o produto piloto de helicóptero</p><p>modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292</p><p>Fig. 9.1 A arquitetura de um BPMS. . . . . . . . . . . . . . . . . . . . 299</p><p>Fig. 9.2 A ferramenta de modelagem de processos do Bonita Open Solution da Bonita</p><p>Suave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300</p><p>Fig. 9.3 O gerenciador da lista de trabalho do BPM Suite do Bizagi. . . . . . . . . . . 301</p><p>Fig. 9.4 A ferramenta de monitoramento do BPMOne da Perceptive Software. . . . . 302</p><p>Fig.9.5 ThespectrumofBPMStypes. . . . . . . . . . . . . . . . . . . 307</p><p>Fig. 9.6 O modelo de atendimento de pedidos que queremos automatizar. . . . . . 318</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 21/192</p><p>Fig. 9.7 Processo de admissão: as avaliações inicial ( a ) e final ( c ) podem</p><p>ser automatizado em um BPMS; a avaliação pelo comitê ( b )</p><p>é um processo manual fora do escopo do BPMS. . . . . . . . 321</p><p>Fig. 9.8 O modelo de atendimento de pedido da Fig. 9.6 , completado com</p><p>aspectos de fluxo de controle e fluxo de dados relevantes para automação. . . . 325</p><p>Fig. 9.9 O processo de vendas de um provedor de serviços B2B. . . . . . . . . . . 326</p><p>Fig. 9.10 Estrutura do formato BPMN. . . . . . . . . . . . . . . . . . 328</p><p>Página 22</p><p>Lista de Figuras xxvii</p><p>Fig. 9.11 O XSD descrevendo o pedido de compra ( a ) e um de seus</p><p>instâncias ( b ). . . . . . . . . . . . . . . . . . . . . . . . . . . . 329</p><p>Fig. 9.12 O processo de atendimento automatizado de receitas. . . . . . . . . . 342</p><p>Fig. 9.13 O modelo para o processo de vendas de um provedor de serviços B2B,</p><p>concluído com fluxo de controle ausente e dados relevantes para</p><p>execução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345</p><p>Fig. 9.14 Modelo de processo do FixComp para tratamento de reclamações. . . . . . . . 348</p><p>Fig.9.15 Modelo de processo de tratamento de reclamações. . . . . . . . . . . . . . . . . . 349</p><p>Fig. 10.1 Exemplo de um log de eventos para o processo de atendimento do pedido. . . . 357</p><p>Fig. 10.2 Metamodelo do formato XES. . . . . . . . . . . . . . . . . . . 358</p><p>Fig. 10.3 Exemplo de arquivo no formato XES. . . . . . . . . . . . . . . . 358</p><p>Fig. 10.4 Definição de um log de fluxo de trabalho. . . . . . . . . . . . . . . . . . . . 361</p><p>Fig. 10.5 Padrões de fluxo de controle simples. . . . . . . . . . . . . . . . . . . . 362</p><p>Fig. 10.6 Pegada representada como uma matriz do registro do fluxo de trabalho</p><p>L = [〈a, b, g, h, j, k, i, l〉,〈a, c, d, e, f, g, j, h, i, k, l〉]. . . . . . 363</p><p>Fig. 10.7 Modelo de processo construído pelo algoritmo α do fluxo de trabalho</p><p>log L = [〈a, b, g, h, j, k, i, l〉,〈a, c, d, e, f, g, j, h, i, k, l〉]. . . . 365</p><p>Fig. 10.8 Exemplos de dois loops curtos, que são problemáticos para o</p><p>α -algoritmo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 366</p><p>Fig.10.9 Dottedchartoflogdata. . . . . . . . . . . . . . . . . . . . . . 368</p><p>Fig. 10.10 Gráfico de cronograma de dados de registro como PM 232. . . . . . . . . . . . . . 369</p><p>Fig. 10.11 Modelo BPMN com token no evento de início para repetir o caso</p><p>〈A , b, g, i, j, k, l〉. . . . . . . . . . . . . . . . . . . . . . . . . . 375</p><p>Fig. 10.12 Repetição do caso não conforme 〈a, b, i, j, k, l〉. . . . . . . . 376</p><p>Fig. 10.13 Resultado da repetição de casos no modelo de processo. . . . . . . . . . 377</p><p>Fig. 10.14 Modelo de processo construído pelo algoritmo α . . . . . . . . . . 380</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 22/192</p><p>Página 23</p><p>Capítulo 1</p><p>Introdução ao Gerenciamento de Processos de Negócios</p><p>Ab ovo usque ad mala.</p><p>Horácio (65 aC-8 aC)</p><p>Gerenciamento de processos de negócios (BPM) é a arte e a ciência de supervisionar como funciona</p><p>é realizado em uma organização para garantir resultados consistentes e para tirar vantagem</p><p>de oportunidades de melhoria. Neste contexto, o termo "melhoria" pode levar diferentes</p><p>significados diferentes dependendo dos objetivos da organização. Exemplos típicos</p><p>dos objetivos de melhoria incluem a redução de custos, reduzindo os tempos de execução e</p><p>redução das taxas de erro. As iniciativas de melhoria podem ser pontuais, mas também exibem mais</p><p>natureza contínua. É importante ressaltar que BPM não é sobre como melhorar a maneira como as ações individuais</p><p>atividades são realizadas. Em vez disso, trata-se de gerenciar cadeias inteiras de eventos, atividades</p><p>e decisões que, em última análise, agregam valor à organização e aos clientes. Estes</p><p>“Cadeias de eventos, atividades e decisões” são chamadas de processos .</p><p>Neste capítulo, apresentamos alguns conceitos essenciais por trás do BPM. Nos começaremos</p><p>com uma descrição dos processos típicos encontrados nas organizações contemporâneas.</p><p>Em seguida, discutimos os ingredientes básicos de um processo de negócios e fornecemos uma definição</p><p>para o conceito, bem como de BPM. A fim de colocar o BPM em um ambiente mais amplo</p><p>Em seguida, fornecemos uma visão geral histórica da disciplina de BPM. Finalmente, nós</p><p>discuta como uma iniciativa de BPM em uma organização normalmente se desenvolve. Esta discussão</p><p>nos leva à definição de um ciclo de vida BPM em torno do qual o livro está estruturado.</p><p>1.1 Processos em todos os lugares</p><p>Cada organização - seja um órgão governamental, uma organização sem fins lucrativos ou um</p><p>empresa — tem que gerenciar vários processos. Exemplos típicos de processos</p><p>que podem ser encontrados na maioria das organizações incluem:</p><p>• Order-to-cash : Este é um tipo de processo realizado por um fornecedor, que começa</p><p>quando um cliente envia um pedido de compra de um produto ou serviço e termina</p><p>quando o produto ou serviço em questão foi entregue ao cliente e</p><p>o cliente efetuou o pagamento correspondente. Um processo de pedido para pagamento en-</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 23/192</p><p>atividades de bússola relacionadas à verificação do pedido de compra, envio (no caso</p><p>de produtos físicos),</p><p>entrega, faturamento, recebimento de pagamento e confirmação.</p><p>M. Dumas et al., Fundamentals of Business Process Management ,</p><p>DOI 10.1007 / 978-3-642-33143-5_1 , © Springer-Verlag Berlin Heidelberg 2013</p><p>1</p><p>Página 24</p><p>2 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>• Cotação para pedido : este tipo de processo geralmente precede um processo de pedido para pagamento.</p><p>Começa a partir do ponto em que um fornecedor recebe um "Pedido de Cotação" (RFQ)</p><p>de um cliente e termina quando o cliente em questão faz um pedido de compra</p><p>com base na cotação recebida. O processo do pedido ao pagamento assume a retransmissão desse</p><p>apontar. A combinação de uma cotação para pedido e o pedido correspondente</p><p>o processo de caixa é denominado processo de cotação para pagamento .</p><p>• Adquirir para pagar : Este tipo de processo começa quando alguém em uma organização desiste</p><p>conclui que um determinado produto ou serviço precisa ser adquirido. Termina quando</p><p>o produto ou serviço foi entregue e pago. Um processo de aquisição para pagamento</p><p>inclui atividades como obter cotações, aprovar a compra, selecionar um</p><p>fornecedor, emitir um pedido de compra, receber as mercadorias (ou consumir o serviço),</p><p>verificar e pagar a fatura. Um processo de aquisição para pagamento pode ser visto como o duplo</p><p>do processo de cotação para pagamento no contexto de interações business-to-business. Para</p><p>em cada processo de aquisição para pagamento, há um processo de cotação para pagamento correspondente em</p><p>do lado do fornecedor.</p><p>• Problema para resolução . Este tipo de processo começa quando um cliente levanta um problema</p><p>ou problema, como uma reclamação relacionada a um defeito em um produto ou um problema en-</p><p>neutralizada ao consumir um serviço. O processo continua até que o cliente,</p><p>o fornecedor, ou de preferência ambos, concorda que o problema foi resolvido.</p><p>Uma variante desse processo pode ser encontrada nas seguradoras que precisam lidar</p><p>com “sinistros de seguros”. Essa variante costuma ser chamada de reivindicação à resolução .</p><p>• Pedido de aprovação. Este tipo de processo começa quando alguém se inscreve para um</p><p>benefício ou privilégio e termina quando o benefício ou privilégio em questão é</p><p>concedida ou negada. Este tipo de processo é comum em agências governamentais, por</p><p>por exemplo, quando um cidadão solicita uma licença de construção ou quando um empresário</p><p>solicita uma licença para abrir um negócio (por exemplo, um restaurante). Outro processo que</p><p>cai nesta categoria é o processo de admissão em uma universidade, que começa quando</p><p>um aluno se inscreve para admissão em um grau. Ainda outro exemplo é o processo</p><p>para aprovação de pedidos de férias ou licenças especiais em uma empresa.</p><p>Como os exemplos acima ilustram, os processos de negócios são o que as empresas fazem</p><p>sempre que entregam um serviço ou produto aos clientes. A forma como os processos são destruídos</p><p>assinado e executado afeta a "qualidade do serviço" que os clientes percebem</p><p>e a eficiência com que os serviços são prestados. Uma organização pode superar</p><p>formar outra organização que ofereça tipos de serviço semelhantes, se tiver processos melhores</p><p>e os executa melhor. Isso é verdade não apenas para processos voltados para o cliente, mas</p><p>também de processos internos, como o processo de aquisição para pagamento, que é realizado</p><p>com o propósito de atender a uma necessidade interna.</p><p>À medida que avançarmos neste livro, usaremos um exemplo concreto de um método de compra para pagar</p><p>processo de aluguel de equipamentos de construção, conforme descrito a seguir.</p><p>Exemplo 1.1 Processo de aquisição até o pagamento na BuildIT.</p><p>A BuildIT é uma construtora especializada em obras públicas (estradas, pontes, dutos,</p><p>túneis, ferrovias, etc.). Dentro do BuildIT, muitas vezes acontece que os engenheiros que trabalham em uma</p><p>local de construção (chamados de engenheiros de site ) precisam de um equipamento, como um caminhão, uma escavadeira,</p><p>https://translate.google.com/translate?hl=pt-BR&prev=_t&sl=auto&tl=pt&u=http://dx.doi.org/10.1007/978-3-642-33143-5_1</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 24/192</p><p>Página 25</p><p>1.2 Ingredientes de um Processo de Negócio 3</p><p>uma escavadeira, uma bomba de água, etc. A BuildIT possui muito pouco equipamento e, em vez disso, aluga a maioria</p><p>de seus equipamentos de fornecedores especializados.</p><p>O processo empresarial existente para aluguel de equipamentos é o seguinte. Quando os engenheiros do site</p><p>precisam alugar um equipamento, preenchem um formulário denominado “Solicitação de Aluguel de Equipamento”</p><p>e enviar esta solicitação por e-mail para um dos balconistas do depósito da empresa. O balconista em</p><p>o depósito recebe a solicitação e, após consulta aos catálogos dos fornecedores de equipamentos,</p><p>seleciona o equipamento mais econômico que atende à solicitação. Em seguida, o balconista</p><p>verifica a disponibilidade do equipamento selecionado com o fornecedor via telefone ou e-mail.</p><p>Às vezes, a opção selecionada não está disponível e o secretário tem que selecionar uma alternativa</p><p>equipamento e verifique a sua disponibilidade junto do respectivo fornecedor.</p><p>Assim que o funcionário encontrar um equipamento adequado disponível para locação, ele adiciona</p><p>os detalhes do equipamento selecionado para a solicitação de aluguel. Cada solicitação de aluguel deve ser</p><p>aprovado por um engenheiro de obra, que também trabalha no depósito. Em alguns casos, as obras</p><p>engenheiro rejeita a solicitação de aluguel de equipamento. Algumas rejeições levam ao cancelamento de</p><p>o pedido (nenhum equipamento é alugado). Outras rejeições são resolvidas substituindo o</p><p>equipamento selecionado com outro equipamento, como um equipamento mais barato ou um</p><p>equipamento mais adequado para o trabalho. Neste último caso, o funcionário precisa realizar</p><p>outra consulta de disponibilidade.</p><p>Quando um engenheiro de obras aprova um pedido de aluguel, o balconista envia uma confirmação para o</p><p>fornecedor. Esta confirmação inclui uma Ordem de Compra (PO) para alugar o equipamento. o</p><p>O PO é produzido pelo sistema de informações financeiras da BuildIT usando as informações inseridas por</p><p>o secretário. O balconista também registra o engajamento do equipamento em uma planilha que é</p><p>mantido com o objetivo de rastrear todos os aluguéis de equipamentos.</p><p>Nesse ínterim, o engenheiro do local pode decidir que o equipamento não é mais necessário. No</p><p>neste caso, o engenheiro pede ao balconista que cancele a solicitação de aluguel do equipamento.</p><p>No prazo devido, o fornecedor entrega o equipamento alugado no canteiro de obras. O site</p><p>engenheiro então inspeciona o equipamento. Se tudo estiver em ordem, o engenheiro aceita o</p><p>engajamento e o equipamento é colocado em uso. Em alguns casos, o equipamento é enviado de volta</p><p>porque não cumpre os requisitos do engenheiro do local. Neste caso, o site</p><p>o engenheiro tem que reiniciar o processo de locação.</p><p>Terminado o prazo de locação, o fornecedor vem buscar o equipamento. As vezes,</p><p>o engenheiro do local pede uma extensão do período de locação entrando em contato com o fornecedor via</p><p>e-mail ou telefone 1–2 dias antes da coleta. O fornecedor pode aceitar ou rejeitar este pedido.</p><p>Alguns dias após a retirada do equipamento, o fornecedor do equipamento envia uma fatura</p><p>para o balconista por e-mail. Neste ponto, o funcionário pede ao engenheiro do local para confirmar que o</p><p>o equipamento foi efetivamente alugado pelo período indicado na fatura. O funcionário também verifica</p><p>se os preços de aluguel indicados na fatura estiverem de acordo com os da OC. Depois de</p><p>esses cheques, o escriturário encaminha a fatura para o departamento financeiro e o financeiro</p><p>departamento eventualmente paga a fatura.</p><p>1.2 Ingredientes de um Processo de Negócio</p><p>O exemplo acima mostra que um processo de negócios abrange uma série de eventos</p><p>e atividades . Os eventos correspondem a coisas que acontecem atomicamente, o que significa que eles</p><p>não têm duração. A chegada de um equipamento a um canteiro de obras é um acontecimento. este</p><p>evento</p><p>pode desencadear a execução de uma série de atividades. Por exemplo, quando um pedaço de</p><p>o equipamento chega, o engenheiro do local o inspeciona. Esta fiscalização é uma atividade, no</p><p>sinto que leva tempo.</p><p>Quando uma atividade é bastante simples e pode ser vista como uma única unidade de trabalho, nós</p><p>chame isso de tarefa . Por exemplo, se a inspeção que o engenheiro do local realiza é bastante</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 25/192</p><p>Página 26</p><p>4 1 Introdução ao Gerenciamento de Processos de Negócios</p><p>simples, por exemplo, apenas verificar se o equipamento recebido corresponde ao que foi</p><p>ordenado - podemos dizer que a inspeção do equipamento é uma tarefa. Se por outro lado</p><p>a inspeção do equipamento requer muitas etapas - como verificar se o equipamento</p><p>atende a especificação constante do pedido de compra, verificando se o equipamento</p><p>está em funcionamento e verificando se o equipamento vem com todos os acessos necessários</p><p>histórias e dispositivos de segurança - vamos chamá-lo de atividade.</p><p>Além de eventos e atividades, um processo típico envolve pontos de decisão ,</p><p>ou seja, momentos em que é tomada uma decisão que afeta a forma como o processo é</p><p>executado. Por exemplo, como resultado da inspeção, o engenheiro do local pode decidir</p><p>que o equipamento deve ser devolvido ou que o equipamento deve ser aceito.</p><p>Essa decisão afeta o que acontece mais tarde no processo.</p><p>Um processo também envolve uma série de atores (atores humanos, organizações ou soft-</p><p>sistemas de armazenamento que atuam em nome de atores humanos ou organizações), objetos físicos</p><p>(equipamentos, materiais, produtos, documentos em papel) e objetos imateriais (elec-</p><p>documentos tronic e registros eletrônicos). Por exemplo, o aluguel de equipamentos pro-</p><p>cesso envolve três tipos de atores humanos (balconista, engenheiro de obra e engenheiro de obras)</p><p>e dois tipos de ator organizacional (BuildIT e os fornecedores de equipamentos). o</p><p>processo também envolve objetos físicos (o equipamento alugado), documentos eletrônicos</p><p>(solicitações de aluguel de equipamentos, POs, faturas) e registros eletrônicos (equipamentos en-</p><p>registros de gestão mantidos em uma planilha).</p><p>Finalmente, a execução de um processo leva a um ou vários resultados . Para a prova-</p><p>ple, o processo de aluguel de equipamento leva a um equipamento sendo usado pela BuildIT,</p><p>bem como o pagamento ao fornecedor do equipamento. Idealmente, um resultado</p><p>deve agregar valor aos atores envolvidos no processo, que neste exemplo são</p><p>BuildIT e o fornecedor. Em alguns casos, este valor não é alcançado ou é apenas parcialmente</p><p>alcançado. Por exemplo, quando um equipamento é devolvido, nenhum valor é ganho, nem</p><p>pela BuildIT nem pelo fornecedor. Isso corresponde a um resultado negativo , ao contrário</p><p>para um resultado positivo que agregue valor aos atores envolvidos.</p><p>Dentre os atores envolvidos em um processo, aquele que consome a produção do</p><p>o processo desempenha um papel especial, nomeadamente o papel do cliente . Por exemplo, no</p><p>processo acima, o cliente é o engenheiro do local, uma vez que é o engenheiro do local que</p><p>coloca em uso o equipamento alugado. É também o engenheiro do local que provavelmente</p><p>ficar insatisfeito se o resultado do processo for insatisfatório (resultado negativo) ou</p><p>se a execução do processo for atrasada. Neste exemplo, o cliente é interno</p><p>para BuildIT, o que significa que o cliente é um funcionário da organização. Em outro</p><p>processos, como um processo do pedido ao pagamento, o cliente é externo à organização</p><p>nização. Às vezes, existem vários clientes em um processo. Por exemplo, em um</p><p>processo de venda de uma casa, há um comprador, um vendedor, um agente imobiliário, um ou vários</p><p>vários fornecedores de hipotecas e pelo menos um notário. O resultado do processo é um</p><p>transação de vendas. Este resultado fornece valor para o comprador que adquire a casa</p><p>e ao vendedor que monetiza a casa. Portanto, tanto o comprador quanto o vendedor</p><p>podem ser vistos como clientes neste processo, enquanto os demais atores fornecem vários</p><p>Serviços.</p><p>Exercício 1.1 Considere o seguinte processo para a admissão de alunos de pós-graduação</p><p>em uma universidade.</p><p>13/08/2020 Fundamentos de Gestão de Processos de Negócios</p><p>https://translate.googleusercontent.com/translate_f 26/192</p><p>Página 27</p><p>1.2 Ingredientes de um Processo de Negócio 5</p><p>Para se inscrever para admissão, os alunos primeiro preenchem um formulário online. Os aplicativos online são</p><p>registrados em um sistema de informação ao qual todos os funcionários envolvidos nas admissões</p><p>processo tem acesso. Depois que um aluno envia o formulário online, um documento PDF é</p><p>gerado e o aluno é solicitado a fazer o download, assinar e enviar por correio juntos</p><p>com os documentos necessários, que incluem:</p><p>• Cópias autenticadas de diplomas anteriores e históricos acadêmicos.</p><p>• Resultados do teste de língua inglesa.</p><p>• Currículo.</p><p>Quando esses documentos são recebidos pelo escritório de admissões, um oficial verifica o</p><p>plenitude dos documentos. Se algum documento estiver faltando, um e-mail é enviado ao aluno. o</p><p>o aluno deve enviar os documentos em falta por correio. Supondo que o aplicativo esteja completo,</p><p>o escritório de admissões envia as cópias autenticadas dos diplomas para um reconhecimento acadêmico</p><p>agência, que verifica os graus e dá uma avaliação de sua validade e equivalência</p><p>em termos de padrões de educação locais. Esta agência exige que todos os documentos sejam enviados para</p><p>pelo correio, e todos os documentos devem ser cópias autenticadas dos originais. A agência envia</p><p>enviar sua avaliação para a universidade também por correio. Supondo que a verificação de grau seja</p><p>bem-sucedido, os resultados do teste de língua inglesa são verificados online por um oficial no</p><p>escritório de admissões. Se a validade dos resultados do teste de língua inglesa não puder ser verificada, o</p><p>o pedido é rejeitado (as notificações de rejeição são enviadas por e-mail).</p><p>Uma vez que todos os documentos de um determinado aluno tenham sido validados, o escritório de admissão encaminha</p><p>estes documentos por correio interno para o comitê acadêmico correspondente responsável por</p><p>decidir se oferece ou não a admissão. O comitê toma sua decisão com base em</p><p>as transcrições acadêmicas e o currículo. O comitê se reúne uma vez a cada 2 a 3 semanas e</p><p>examina todos os aplicativos que estão prontos para avaliação acadêmica no momento da reunião.</p><p>No final da reunião da comissão, o presidente da comissão notifica as admissões</p><p>escritório dos resultados da seleção. Esta notificação inclui uma lista de admitidos e rejeitados</p><p>candidatos. Poucos dias depois, o escritório de admissão notifica o resultado para cada candidato</p><p>via email. Além disso, os candidatos aprovados recebem uma carta de confirmação por correio.</p><p>Com relação ao processo acima, considere as seguintes questões:</p><p>1. Quem são os atores neste processo?</p><p>2. Quais atores podem ser considerados o cliente (ou clientes) neste processo?</p><p>3. Que valor o processo oferece ao (s) cliente (s)?</p><p>4. Quais são os resultados possíveis deste processo?</p><p>À luz do que precede, definimos um processo de negócios como uma coleção de inter-relacionados</p><p>eventos, atividades e pontos de decisão que envolvem uma série de atores e objetos,</p><p>e que coletivamente levam a um resultado de valor para pelo menos um cliente .</p><p>A Figura 1.1 mostra os ingredientes desta definição e suas relações.</p><p>Armados com esta definição de um processo de negócios, definimos BPM como um corpo de</p><p>métodos, técnicas e ferramentas para descobrir, analisar, redesenhar, executar e monitorar</p><p>processos de negócios . Esta definição reflete o fato de que os processos de negócios são os</p><p>ponto focal de BPM, e também o fato de que BPM envolve diferentes fases e atividades</p><p>no ciclo de vida dos processos de negócios, como discutiremos mais adiante neste capítulo.</p><p>Outras disciplinas além de BPM lidam com processos de negócios de maneiras diferentes, como</p><p>explicado na caixa “Disciplinas relacionadas”. Um dos recursos</p>