Curso de Modelagem de Processos CURSO DE MODELAGEM DE PROCESSOS. Tradução e Organização Adinilson Martins

Transcrição

1 CURSO DE MODELAGEM DE PROCESSOS Tradução e Organização Adinilson Martins 1

2 Sumário Introdução Conceito de Processo Análise de Processos Identificação dos processos institucionais Identificação das regras de negócio Modelagem de Processos Benefícios Obtidos com a Modelagem de Processos Notação BPMN Elementos do Diagrama de Processo Divisões - Piscina e Raia Eventos de Início Conexões - Fluxo de Sequência Conexões - Fluxo de Mensagem Atividade - Tarefa Desvios Desvio Exclusivo (baseado em dados): Desvio Exclusivo (baseado em eventos): Desvio Inclusivo: Desvio Paralelo: Eventos Intermediários Atividade - Sub-processo Eventos de Fim Artefatos Permissões em BPMN Ciclo de Vida BPM Planejamento e estratégia Análise de processos de negócio Desenho e modelagem de processos de negócio Implementação de processos Monitoramento e controle de processos Refinamento de processos Referências Anexos Anexo 1: Artefato de Análise de Procesos...34 Anexo 2: Poster da Notação BPMN

3 Introdução Curso de Modelagem de Processos Processo é um conjunto de ações que são executadas para alcançar resultados; Este é o conceito de processo mais simples, objetivo e ao mesmo templo amplo e geral. Sendo assim, processo é algo inerente e indissociável à natureza e à vida das pessoas, gostem elas ou não, tenham elas consciência disso ou não. Um trabalhador que, diariamente, levanta pela manhã, escova os dentes, toma café, põe sua roupa, entra no seu veículo, passa pela portaria do trabalho e registra seu ponto, executa, diariamente, um conjunto de atividades ou ações para alcançar o resultado de chegar ao trabalho, ou seja, este trabalhador executa o processo diário de se preparar e dirigir-se ao trabalho. Em nível macro, pode-se observar geólogos afirmando que as condições naturais do planeta são decorrentes de atividades geológicas ocorridas à milhões de anos, o que quer dizer que ações naturais fizeram o planeta alcançar a condição, ou o resultado atual que permite a vida na terra. Em continuidade a este discurso observa-se ecologistas alardeando sobre ações que continuam transformando o planeta e que, no caso, podem levar a um resultado indesejável para as condições de vida no planeta. Ou seja, o próprio planeta vive um constante processo de transformação. Na verdade tudo que está em movimento está em constante processo de transformação. E segundo o filósofo Heráclito, mesmo que aparentemente algo esteja parado, tudo está em constante movimento, logo tudo está sempre sobre a influência de um processo. Uma vez ciente da inerência dos processos na vida pessoal, empresarial, corporativa, geológica e até universal, um gestor desses contextos pode decidir por desenhar modelos desses processos para conhecê-los melhor e de posse desse conhecimentos, manipulá-los e gerí-los, dentro das suas possibilidades, de forma a direcioná-los a resultados diferenciados, planejados e desejados por ele e por sua organização. E para tal, surgiram métodos e padrões de notação para modelagem e documentação de processos, como é o caso da BPMN (Business Process Model and Notation), desenvolvido pela OMG (Object Management Group), e sobre qual abordaremos neste curso. 1. Conceito de Processo Processo é conhecido como um conjunto definido de atividades ou comportamentos espontâneos ou manipulados que ocorrem na natureza e também podem ser executados por humanos ou máquinas para alcançar uma ou mais metas. Tais processos são disparados por eventos específicos e apresentam um ou mais resultados que podem conduzir ao término do processo ou a transferência de controle para outro processo. Os processos são compostos por várias tarefas ou atividades interrelacionadas que solucionam uma 3

4 questão específica. Curso de Modelagem de Processos Atualmente a visão e gestão de processos é um tema bastante difundido no contexto empresarial, onde será mais comum a aplicação dos conceitos ensinados neste curso. E nesse contexto empresarial, processo é visto como um trabalho ponta a ponta que entrega valor aos clientes e assim é chamado de processo de negócio. Este conceito é chave pois envolve todo o trabalho cruzando limites funcionais necessários para entregar o valor resultante aos clientes do processo. Contudo, uma empresa, normalmente, se organiza assim: Mas, no seu dia a dia, o seu relacionamento interno acontece assim: E é neste cenário que surge a importância da mapeamento e modelagem dos processos com a finalidade de dar visibilidade e organizar os processos em uma forma inteligível para viabilizar a gestão e as integrações de cada atividade específica da organização. 4

5 Por sua vez, a gestão dos processos, apoiada nos modelos desenhados e na documentação do processo, deve visar o objetivo final de promover melhores resultados das atividades quanto aos prazos de execução, quanto a qualidade, quanto ao custo, capacidade, etc. Dessa forma definindo uma gestão por processos que opera dentro de uma organização que passa a ter uma uma estrutura matricial, tendo a administração hierárquica vertical e a administração dos processos horizontal, atuando de forma sinérgica: Estrutura Matricial: Estrutura Hierárquica Estrutura de Processos Uma vez que todo processo corporativo envolve a participação de vários departamentos da organização, observa-se a natureza horizontal ou transversal dos processos empresariais, tendo cada um, um gestor definido. 2. Análise de Processos Antes de partir para o desenho e modelagem de um processo específico, é importante entender, pelo menos em noção, todo o contexto da organização em que ele está inserido e, obrigatoriamente, é importante conhecer todos os componentes que influenciam diretamente no comportamento do processo. Dá-se o nome de Análise de Processo a esse entendimento contextual, ou seja Entender os processos de negócio no escopo da organização como um todo. 2.1 Identificação dos processos institucionais A declaração de missão de uma organização aponta o seu (s) processo (s) finalístico (s). O regimento interno e as declarações de atribuições e competências, dentre outros documentos apontam as atividades e processos específicos que devem ser executadas pela organização. Uma maneira de mapear quais os processos constam na organização é observar verbos no infinitivo, constante nesses documentos, pois, normalmente, eles apontam uma atividade que pode ser uma simples tarefa ou um processo inteiro que 5

6 deve ser modelado. O organograma, a carteira de clientes e de fornecedores, e a tabela de cargos apontam os participantes dos processos. A identificação dos participantes é importante para que seja demonstrado no desenho quem é responsável por cada atividade do processo transversão da empresa. 2.2 Identificação das regras de negócio As regras de negócio compreendem outra informação crítica para modelagem dos processos, pois nelas estão definidos, normalmente, os prazos que o processo deve obedecer, as obrigações legais, as decisões de desvio que ocorrem dentro do processo, dentre outras informações chaves. Documentos contratuais, além de regras de negócio, são também fontes que ajudam a identificar as entradas (, disparos, insumos, etc.) bem como as saídas (produto ou serviço) os quais o processo deve fornecer. Abaixo temos uma visão sistêmica resumida e uma completa das informações diretamente relacionadas com um processo: É interessante e ilustrativamente esclarecedor pensar em um processo como uma esteira de produção industrial. Na fabricação de veículos, por exemplo, pode-se dizer que atuam na esteira de montagem vários departamentos: o departamento responsável pela mecânica dos motores, o departamento responsável pelo estofamento, o departamento responsável pela lataria e no final da esteira temos o departamento de controle de qualidade. Vale lembrar que um pouco antes do início da esteira temos o departamento de projetos e no final da esteira o departamento de entrega e o de comercialização, e por aí vai. Dessa forma é fácil perceber que toda a empresa está envolvida no processo de prdução e venda do veículo, daí a 6

7 importância de considerar e levantar todas as informações relevantes e diretamente ligadas ao processo antes de partir para o desenho e modelagem. Isto dará dinamismo no desenho e poupara o modelador de grande volume de retrabalho. As questões O que, Quem, Onde, Quando, Como e Porque (5W1H), recomendadas pelo conhecido Framework Zachmann são uma boa sugestão para o levantamento das informações de análise de processo. O Anexo 1 deste documento propõe uma planilha de análise de processos com elaboração baseada nessas questões. 3. Modelagem de Processos Modelar um processo é criar uma representação do processo que o descreva de forma necessária e suficiente para o entendimento e realização do trabalho pretendido. Fluxogramas são os meios mais tradicionais utilizados ao longo da história corporativa para modelar um diagrama de processo. Muitas pessoas ainda tem sobre a mesa aquelas réguas com desenhos de elementos de fluxograma para desenhá-los à lápis ou caneta. Com o advento da tecnologia, muitos padrões de notação para o desenho de diagramas surgiram, como o modelo EPC e UML, dentre outros para apoiar o levantamento de requisitos para o desenvolvimento de sistemas. E nesse meio surgiu a notação BPMN (Business Process Model and Notation) sustentado pela OMG (Object Management Group). A notação BPMN é a mais popular atualmente, dada a facilidade intuitiva de compreendê-la, não precisando ser, necessariamente, um especialista para para avaliar um diragrama. Ela lembra muito os fluxos desenhados com as antigas réguas, só que com mais recursos para representar mais opções no fluxo do processo. O diagrama é a parte mais importante da modelagem de um processos, contudo é apenas parte da documentação. Além do diagrama, deve-se produzir um documento descritivo que explique as atividades desenhadas, em mais detalhes e também deve-se anexar os documentos citados no diagrama, tais como formulários, manuais, normas, regras de negócio, perfil dos participantes, etc. É necessário também definir atributos de classificação e organização para o conjunto de processos conforme sistemática interna, as classificações podem ser: quanto a cadeia de valor, hierarquia, detalhamento, abrangência, dentre outras. Só assim obtem-se o o modelo completo do processo. 3.1 Benefícios Obtidos com a Modelagem de Processos Conforme dito, uma gestão baseada em processos deve ter foco final em melhorar os resultados da organização. E a modelagem dos processos, como um dos meios imprescindíveis para isso, provê informações objetivas e transparentes e viabiliza ações mais assertivas acerca dos ajustes nos processos, além de, também, fornecer alguns benefícios imediatos, tais como: Transformação de conhecimento tácito em explícito e retenção e gestão do conhecimento; Ampla comunicação, conhecimento e participação sobre os processos; 7

8 Curso de Modelagem de Processos Padronização e orientação em todo âmbito organizacional de procedimentos a serem realizados; Maior suporte a capacitação e reciclagem sobre os processos, reduzindo a curva de aprendizado; Eliminação de processos redundantes e concorrentes; Reuniões e debates mais pontuais e objetivos sobre os processos; Gestão de mudanças dos processos mais precisa e assertiva; Representação evidente e gerenciável das integrações entre as áreas e os processos; Facilitação na elicitação de requisitos para automação de processos; Maior garantia de conformidade legal dos processos; Disponibilidade de informações para tomada de decisão. 3.2 Notação BPMN O BPMI (Business Process Management Initiative) desenvolveu um padrão de notação denominado BPMN (Business Process Modeling Notation) e definiu como o principal objetivo do BPMN, fornecer uma notação que seja facilmente compreensível por todos os usuários de negócios, desde os analistas de negócios que criam os rascunhos iniciais dos processos até os desenvolvedores técnicos responsáveis por implementar a tecnologia que irá executar os processos e, por fim, para as pessoas de negócios que irão gerenciar e monitorar os processos. Assim, a BPMN cria uma ponte padronizada entre a concepção de processos de negócios e a implementação de processos. Esta especificação define a notação e semântica de um BPD (Business Process Diagram Diagrama de Processos de Negócio) e representa a incorporação das melhores práticas da comunidade de modelagem de negócios. Um elemento-chave da BPMN é a escolha das formas e dos ícones usados para identificar os elementos gráficos nesta especificação. A intenção é criar uma linguagem visual padrão que todos os modeladores processo irão reconhecer e compreender, ainda que com alguma flexibilidade no tamanho, cor, estilo de linha, e as posições do texto dos elementos gráficos definidos, salvo o que estiver especificado em contrário. Para BPMN, um processo é uma atividade realizada dentro ou entre as empresas ou organizações. Em BPMN um processo é representado como um Gráfico de Fluxo de Objetos, que são um conjunto de outras atividades e os controles que dão sequência a elas. Um BPD pode conter mais de um processo. Cada processo pode ter os seus próprios sub-processos e estará contido dentro de uma piscina. Cada processo é independente em termos de fluxo de sequencia, mas podem estar conectados por fluxo de mensagem. A notação BPMN define que os tipos de atividades que são parte de um Diagrama de Processos de Negócios são: Processo, Sub-Processo e Tarefas. Mas vale destacar que o processo não é um objeto gráfico específico, ele é um conjunto de objetos gráficos. Assim, atividade é um trabalho que é realizado dentro de um processo de negócio e pode ser atômica ou não atômica (composta). Um BPD pode ter os seguintes atributos: Código de Identificação, Nome, Versão, Autor, Data de Criação, Data de Modificação, Quantidade de Piscinas, Classificação, Documentação Adicional. A seguir serão abordados todos os elementos que podem estar contidos em um Diagrama de Processo. No anexo 2 deste documento consta um poster sintetizando o uso desses elementos. 8

9 3.3 Elementos do Diagrama de Processo Curso de Modelagem de Processos Existem quatro categorias básicas de elementos da notação BPMN que são: Objetos de Fluxo, Objetos de Conexão, Divisões e Artefatos. A seguir seguem as figuras ilustrativas desses elementos: Objetos de Fluxo: Eventos: Desvios: Atividades: Simples: Tarefas: Sub-processos: Mensagem: Tempo: De Início Intermediários De Fim Exclusivo (baseado em dados) Normal Normal Erro: Cancela: Compensação: Exclusivo (baseado em eventos) Loop Loop Condicional: Múltipla Instância Múltipla Instância Conector: Inclusivo Sinal: Compensação Ad-Hoc Final imediato: Paralelo Multiplo: Complexo Compensação De Recebimento De Envio Expandido Transação 9

10 Objetos de Conexão: Artefatos: Fluxo de Sequência Normal Fluxo de Sequência Condicional Fluxo de Mensagem Obeto de Dados Fluxo de Sequência Saída Padrão Associação Anotação Grupo Divisões: Piscina: : Raias Nos capítulos a seguir constam explicações detalhadas de uso de cada um desses elementos que compõem essas quatro categorias da notação BPMN. 3.4 Divisões - Piscina e Raia A notação BPMN usa o conceito de divisões conhecido como piscina e "raias" para particionar e organizar as atividades. Graficamente, cada participante é particionado, ou seja, fica contido dentro de uma caixa retangular chamado de Piscina", e/ou também na Raia que são subdivisões da piscina onde se dispõe participantes sobordinados ao participante principal contido na piscina. PODEM existi, ainda,r Raias dentro de Raias. 10

11 Todos os Diagramas de Processos apresentam pelo menos uma Piscina. Em algumas representações as bordas da piscina podem estar ocultas, neste caso considera-se o nome da Piscina como o mesmo nome do diagrama. Mas apenas uma Piscina em um diagrama PODE SER apresentada sem borda. Se houver mais de uma piscina no diagrama, logo, as demais Piscinas DEVEM apresentar bordas. O modelador deve definir um participante para uma piscina ou raia. O participante pode ser um papel ou uma entidade. A conexão entre elementos contidos dentro de uma piscina deve ser feita por Fluxo de Sequência que PODE cruzar as fronteiras entre as Riais de uma piscina, mas não pode cruzar os limites de uma Piscina. A interação entre Piscinas, é representada através de Fluxo de Mensagens que podem se conectar a borda da piscina em interação ou até diretamente aos seus elementos internos que participam da integração com a outra piscina. Uma Piscina pode ser chamada de Caixa Branca quando houver atividades representadas no seu interior. Se não há representação de atividades no seu interior a Piscina é chamada de "Caixa Preta". O desenho de um processo deve começar pela piscina, quando ela for utilizada e de posse da informações obre os participantes do processo, cria-se as raias correspondentes aos mesmos. Abaixo a ilustração de um diagrama com duas piscina em interação: Observe que as atividades dentro da piscina são conectadas por Fluxos de Sequência (setas solidas) e a integração entre as piscinas é feita por Fluxo de Mensagem (setas pontilhadas). 11

12 Não é muito comum, nem recomendado, porém as piscinas podem ser, também, desenhadas na vertical. 3.5 Eventos de Início Uma vez desenhada a piscina e representado seus respectivos participantes nas respectivas raias, podese começar o desenho do fluxo a partir da escolha do evento de início. Os eventos de início se diferenciam dos demais pela sua borda em linha fina e simples. Um Evento de Início é fonte de um Fluxo de Sequência e dispara um token (sinal de comando) que DEVE ser encerrado por um Evento de Fim. Seis opções de eventos de início podem ser utilizadas: Elemento Início Simples Descrição e Regras de Uso Evento sem um tipo específico. Ele também é usado por um sub-processo que começa quando o fluxo é provocado pelo seu processo parente. Uma mensagem chega de um participante e dispara o início do processo. Início Mensagem Início Tempo Início Condicional Início Sinal Início Multiplo Uma data ou tempo específico ou um ciclo específico (ex: todas as segundas-feiras às 09 da manhã) pode estar configurada para disparar o início do processo Este tipo de evento é disparado, por exemplo, quando a temperatura fica acima dos 40 graus, ou quando chegar um documento de autorização. A expressão de condição do evento deve se tornar falsa e depois verdadeira para que o evento seja disparado novamente A chegada de um sinal que foi transmitido de um outro processo e desencadeia o início do processo. Note que o sinal não é uma mensagem, que tem uma meta específica para Mensagem. Vários processos podem ter Eventos de Início que são desencadeados a partir do mesmo sinal transmitido. Isto significa que existem várias maneiras de desencadear o processo. Apenas uma delas será exigida para iniciar o processo. Os atributos do Evento de Início irão definir quais os outros tipos de desencadeadores se aplicam. Existem algumas regras gerais quando do uso de qualquer evento de início: DEVE: Um evento de início DEVE ser fonte de Fluxo de Sequência. NÃO DEVE: Um evento de início NÃO DEVE ser fonte de Fluxo de Mensagem; 12

13 Curso de Modelagem de Processos Um evento de início NÃO DEVE ser alvo de Fluxo de Sequência como entrada (salvo aqueles dispostos na borda de um sub-processo expandido). PODE: Mais de um fluxo de sequência PODE sair de um evento de início; Um evento de início PODE ser alvo de conexão de Fluxo de Mensagem (do tipo Mensagem ou Múltiplo); PODE haver mais de um evento de início para um mesmo nível de processo, sendo que cada um será independente (darão inicio independentemente um do outro). MAS deve-se considerar que o comportamento do processo será de DIFÍCIL ENTENDIMENTO quando existir mais de um evento de início; Um evento de início PODE ser disposto na borda de um sub-processo. OPCIONAL, DESDE QUE: Um diagrama de processo pode conter vários níveis de processos, tais como processos ou sub- processo. Um Evento de Início, para qualquer nível de processo em um diagrama, é OPCIONAL, DESDE QUE considerado o seguinte: É RECOMENDADO para processos complexos; Se existe um Evento de Fim, DEVE existir ao menos um Evento de Início; Se existe Evento de Início, todos os demais elementos DEVEM ter entrada de fluxo de sequência (salvo os eventos intermediários conectados à borda de atividades); Se não há evento de início os objetos sem conexão de entrada de fluxo de sequência DEVERÃO ser instanciados automaticamente quando o processo for instanciado (salvo atividades de compensação). 3.6 Conexões - Fluxo de Sequência O próximo elemento a ser utilizado no diagrama deve ser o Fluxo de Sequência representado pela seta sólida conforme já demonstrada e que serve para conectar os elementos dentro de uma piscina (menos os artefatos que utlilizam a conexão do tipo Associação). O quadro abaixo explica, por sí só as regras de conexões possíveis para o Fluxo de Sequência. O símbolo da seta indica que o objeto listado na linha pode se conectar ao objeto listado na coluna. Somente os objetos representados fazem parte do escopo de fluxo de sequência. O que não constar no quadro, não é permitido: 13

14 Outras regras gerais para o Fluxo de Sequência: PODE: O Fluxo de Sequência PODE cruzar as fronteiras entre as Raias de uma piscina. NÃO PODE: O Fluxo de Sequência NÃO PODE cruzar os limites de uma Piscina. A interação entre Piscinas, é representada através de Fluxo de Mensagens. Os objetos dentro de sub-processo expandido constantes em um diagrama NÃO PODEM ser conectados a objetos fora do sub-processo por meio de Fluxo de Sequência. O Fluxo de sequência condicional (aquele que tem um pequeno losango desenhado no seu início) é utilizado para representar uma saída de uma condição especificada quando mais de um fluxo de sequência saem de uma atividade. Com este uso elimina-se a necessidade de utilização do Desvio do tipo Condicional (ver capitulo dos Desvios). 14

15 3.7 Conexões - Fluxo de Mensagem Curso de Modelagem de Processos Pode não ser o momento ainda de utilizar o Fluxo de Mensagem utilizado pra conectar diferentes piscinas. Mas aproveitando a organização dos capítulos a possibilidade do modelador estar trabalhando com duas piscinas ao mesmo tempo, segue abaixo o quadro abaixo explica, por sí só as regras de conexões possíveis para o Fluxo de Sequência. O símbolo da seta indica que o objeto listado na linha pode se conectar ao objeto listado na coluna. Somente os objetos representados fazem parte do escopo de fluxo de sequência. O que não constar no quadro, não é permitido: Outras regras gerais para o Fluxo de Mensagem: PODE: Os Fluxos de Mensagem PODEM conectar-se tanto à borda de uma Piscina quanto, atravessar a borda e conectar-se a objetos no seu interior (ver regras de conexão de Fluxo de Mensagem). NÃO PODE: O Fluxo de Mensagens NÃO PODE conectar-se aos objetos que estão dentro da mesma piscina. 3.8 Atividade - Tarefa Após o evento de início, desenhamos um Fluxo de Sequência e, em seguida, podemos desenhar uma atividade do tipo tarefa. Tarefa é uma atividade atômica incluída dentro de um processo. A notação BPMN especifica três tipos de marcadores para a tarefa: Loop, Múltiplas Instâncias, e Compensação. Assim, conforme demonstrado anteriormente, temos a escolha de quatro opções de tarefas para incluir no processo: 15

16 Tarefa Normal Tarefa Loop Tarefa Múltipla Instância Tarefa de Compensação A BPMN não faz especificações quanto ao texto inserido dentro das tarefas, contudo é boa prática que sejam utilizados verbos no infinitivo e que, de preferência, apenas um verbo seja utilizado dentro da figura, representando apenas uma ação a ser tomada. Cada tarefa, sub-processo ou evento é igual a uma ação. O uso das tarefas submete-se a algumas regras gerais: DEVE: Se a tarefa não tem um Fluxo de Sequência de entrada e não existir Evento de Inicio do processo, a Tarefa DEVE ser instanciada quando o processo é instanciado, salvo Tarefas de Compensação que não são consideradas como fluxo normal do processo, logo não devem ser instanciadas com a instanciação do processo. Se for necessário controlar o fluxo de entrada, DEVE-se usar um Desvio ( gateway) de conversão precedendo a Tarefa. PODE: Uma tarefa PODE ter um ou dois marcadores, exceto o uso do Loop e Multipla Instância juntos. Um tarefa PODE ser um alvo para um Fluxo de Sequência, inclusive com múltiplas entradas. A Tarefa PODE ser uma fonte para um Fluxo de Sequência, que pode ter múltiplos fluxo de saída. Se houver vários fluxos sequência de saída, então isso significa que um caminho paralelo está sendo criado em separado para cada fluxo. Se a Tarefa tem várias entradas de fluxo de sequência, quando o acionamento de uma das entradas chegar, A Tarefa será instanciada. Ela não vai esperar a chegada de acionamento dos outros caminhos. Assim quando outro acionamento do mesmo caminho ou de outro caminho chegar, um outro instanciamento da Tarefa será criado a parte. As tarefas ainda podem receber alguns tipos de atributos de acordo com a necessidade de expressar informações do modelador: Tarefa de Serviço: é uma tarefa que fornece algum tipo de serviço, que poderia ser um serviço web ou uma aplicação automática; Tarefa de Recebimento: é uma tarefa simples que é projetada para aguardar a chegada de uma mensagem de um participante externo (em relação ao Processo de Negócios). Uma vez que a mensagem foi recebida, a tarefa é concluída. A tarefa de recebimento pode ser usada para iniciar um processo quando o processo não tem um evento de início e a tarefas de recebimento não tem um Fluxo de Sequência como entrada ou quando o fluxo de seqüência de entrada para a tarefa de recebimento tem um evento de início como fonte. 16

17 Curso de Modelagem de Processos Tarefa de Envio: é uma tarefa simples que é projetada para enviar uma mensagem para um participante externo (em relação ao Processo de Negócios). Depois que a mensagem tenha sido enviada, a tarefa é concluída; Tarefa do Usuário: é uma típica tarefa de fluxo de trabalho onde um ator humano realiza a tarefa com o auxílio de uma aplicação de software. Tarefa de Script: é executado por um motor de processos de negócios. O modelador ou implementador define um script em uma linguagem que o motor possa interpretar. Quando a tarefa está pronta para começar, o motor irá executar o script. Quando o script estiver concluído, a tarefa também estará concluída; Tarefa Manual: é uma tarefa que deverá ser realizada sem o auxílio de qualquer mecanismo de execução de processos de negócios ou qualquer outra aplicação. Um exemplo disso pode ser um técnico de telefonia na instalação de um telefone no local do cliente. 3.9 Desvios Podemos desenhar outras atividades em sequência à primeira atividade ou podemos precisar utilizar um desvio. Desvios são elementos de modelagem que são utilizados para controlar como o Fluxo de Sequência prossegue quando nas situações de convergência e/ou ramificação dos caminhos de um processo. Se o fluxo não precisa ser controlado, logo um desvio não é necessário. Sendo necessário, podem ser utilizadas cinco opções demonstradas a seguir. Mas antes seguem regras gerais para todos os desvios: PODE: Um Desvio PODE ter múltiplas entradas ou saídas de Fluxo de Sequência; Um Desvio PODE ser ou não uma fonte de Fluxo de Sequência; Um Desvio PODE ser ou não um alvo de Fluxo de Sequência. Neste caso, se não houver nenhuma entrada de fluxo, e se não há Evento de Início, as saídas do Desvio serão disparadas quando o processo for instanciado; NÃO DEVE SER: Um Desvio NÃO DEVE SER alvo de Fluxo de Mensagens; Um Desvio NÃO DEVE SER uma fonte de Fluxo de Mensagens; A notação BPMN não especifica o formato das expressões utilizadas nos Desvios ou qualquer outro elemento BPMN que usa expressões. Contudo é boa prática comum, descrever abaixo dos desvios a pergunta (apenas uma pergunta direta) que direcionará as saídas para o caso do uso do desvio para direcionamento, sendo desnecessária expressões para o desvio utilizado para convergir Fluxos de Sequência. 17

18 3.9.1 Desvio Exclusivo (baseado em dados): Elemento: Ramificando: Convergindo: Exclusivo (baseado em dados) Descrição e regras de uso do Desvio Exclusivo (baseado em dados): Desvios Exclusivos (decisões) são os locais dentro de um processo de negócio onde o fluxo de seqüência pode ter dois ou mais caminhos alternativos. Eles são basicamente a encruzilhada na estrada" para um processo. Qual o caminho a seguir? Apenas um caminho DEVE ser escolhido. A decisão para um Desvio Exclusivo Baseado em Dados baseia-se em expressões que são atributos de saída do Fluxo de Sequência. Estas expressões usam os valores de dados do processo para determinar qual caminho deve ser tomado (Daí o nome de baseado em dados ). Um exemplo para o no caso de duas saídas do desvio é a inserção de uma pergunta simples junto ao desvio, tal como: O cartão de crédito foi autorizado? ; a resposta Sim assume como alternativa 1 e Não como a alternativa 2 e a partir dessas respostas o processo toma sequência. As alternativas de desvio serão avaliadas em uma ordem específica e a primeira que for identificada como VERDADEIRA determinará a sequência do fluxo, as demais, mesmo que também VERDADEIRAS, serão ignoradas. Se não existir uma saída verdadeira nem uma padrão, o modelo do processo é considerado inválido. O último dos desvios PODE SER uma SAÍDA PADRÃO que será escolhida se nenhuma das outras for VERDADEIRA. Embora raro, um Desvio Exclusivo Baseado em Dados pode ser utilizado para convergir entradas, porém seu comportamento será como se ele não existisse (como várias entradas diretamente em uma mesma atividade - e se há várias entradas na mesma atividade, todas elas darão sequência ao processo ao seu tempo, sem qualquer sincronismo). Porém se as atividades de saída do desvio nessas condições vão conectar a um Desvio Paralelo, o uso desse Desvio Exclusivo na saída é necessário para sincronizar qual das atividades terá saída para o Desvio Paralelo que virá em seguida, caso contrário, tal desvio paraleloe aguardará eternamente pela saída das duas atividades que chegarem à ele. 18

19 A mesma figura do desvio sem o X no meio tem o mesmo significado, contudo as duas opções de figuras NÃO DEVEM ser utilizadas no mesmo diagrama de processo Desvio Exclusivo (baseado em eventos): Elemento: Ramificando: Exclusivo (baseado em eventos) Descrição e regras de uso do Desvio Exclusivo (baseado em eventos): Este desvio também é um Desvios Exclusivo (decisão) logo, também é um local dentro de um processo de negócio onde o fluxo de sequência pode ter dois ou mais caminhos alternativos. Eles são basicamente a encruzilhada na estrada" para um processo. Qual o caminho a seguir? Apenas um caminho DEVE ser escolhido. Quando a entrada de fluxo, o comportamento do Desvio Exclusivo Baseado em Eventos é o mesmo que um Desvio Exclusivo Baseado em Dados. Quanto a saída do fluxo de sequência, a ideia básica é que esta decisão representa um ponto de ramificação no processo em que as alternativas são baseadas em eventos que ocorre nesse momento no processo, ao invés de a avaliação de expressões utilizando dados do processo (por isso, no caso deste desvio, não há necessidade de agregar expressões à ele). Aqui o evento evento que chegar primeiro (a mensagem x, a mensagem y ou o tempo x) dá sequência ao fluxo. Tal como o Desvio Exclusivo Baseado em Dados, apenas uma saída do Desvio Exclusivo Baseado em Eventos será liberada, de acordo com os alvos (nos eventos de saída) do Desvio, ou seja, se um alvo é instanciado (por exemplo, uma mensagem é recebida ou um tempo for excedido), então tal saída será a escolhida e as restantes não serão avaliadas (ou seja, os seus alvos serão desabilitados). Eventos Intermediários de Mensagem, Tempo e Sinal e uma Tarefa de Recebimento podem ser alvos deste Desvio. Se um dos alvos deste desvio for uma tarefa de recebimento, NÃO DEVERÁ haver também um Evento de Mensagem como alvo. Não é de uso comum nem recomendado, mas este Desvio pode ser o início de um processo DESDE QUE não haja fluxo de sequência ligado à sua entrada e na sua saída não se insira um Evento de Tempo. 19

20 3.9.3 Desvio Inclusivo: Curso de Modelagem de Processos Elemento: Ramificando: Convergindo: Inclusivo Descrição e regras de uso do Desvio Inclusivo: Esta decisão representa um ponto de ramificação onde as alternativas são baseadas em expressões condicionais contidas na saída do Fluxo de Sequência. Toda condição que for avaliada como VERDADEIRA passará pelo desvio dando sequência ao processo. Se nenhuma condição for verdadeira e não houver uma saída como padrão, o modelo é considerado inválido. Quando RAMIFICANDO, um ou mais caminhos de saída serão selecionados na execução do processo, conforme as condições expressadas nas saídas do Desvio. Todas as condições de saída DEVEM ser avaliadas. Quantas forem as condições de saídas VERDADEIRAS, estas serão ativadas. Se nenhuma das condições de saídas forem verdadeiras, a saída PADRÂO definida será escolhida. Quando o Desvio Inclusivo for usado para convergir fluxos de sequência, ele irá sincronizar todos as entradas, mas no máximo uma para cada sequência de entrada de fluxo. Se um Desvio Inclusivo anterior produziu duas entradas válidas de um total de três, o Desvio Inclusivo seguinte irá sincronizar essas duas entradas válidas e não irá esperar pela terceira mesmo que exista Fluxo de Sequência conectado como entrada. Em resumo, quando CONVERGINDO, se houver vários fluxo de Sequência de entrada, um ou mais deles será usado para continuar o fluxo do processo. (este desvio também pode ser representado por mini diamantes no início de cada flecha de fluxo de sequência, com algumas restrições. Ver Fluxo de Sequência e notação original). 20

21 3.9.4 Desvio Paralelo: Curso de Modelagem de Processos Elemento: Ramificando: Convergindo: Paralelo Descrição e regras de uso do Desvio Paralelo: Um Desvio Paralelo é dispensável, mas é usado como melhor prática. Ele fornece um mecanismo para sincronizar o fluxo paralelo e para criar um fluxo paralelo. Quando usado para RAMIFICAR, todas as saídas serão ativadas na execução do processo. Quando usado para CONVERGIR Fluxos de Sequência, se houver vários fluxos sequência de entrada, todos eles serão usados para continuar o fluxo do processo - o fluxo será sincronizado. Isto é, o fluxo de processo deve continuar quando um sinal (token) chegou de todo um conjunto de sequência de fluxo (ou seja, o processo irá aguardar todos os sinais chegarem antes que ele dê continuidade ao fluxo) Desvio Complexo: Elemento: Ramificando: Convergindo: Complexo 21

22 Descrição e regras de uso do Desvio Complexo: Um Desvio Complexo lida com situações que não são facilmente manipuladas com o uso de outros tipos de Desvios. Ele também pode ser usado para combinar um conjunto de outros Desvios em um único, representando um modo mais compacto. O modelador pode definir expressões complexas que determinam a conversão ou ramificação no comportamento do Desvio Complexo. Quando o Desvio Complexo é usado como uma decisão então uma expressão que determina a sequência do fluxo de saída será escolhida para que o processo continue. A expressão pode se referir a dados do processo e das configurações dos Fluxos de Sequência de saída. Uma expressão pode avaliar os dados do processo e, em seguida, selecionar diferentes saídas do Desvio com base nos resultados da avaliação. Pelo menos uma saída DEVE ser escolhida. Quando o Desvio Complexo for usado para CONVERGIR, então haverá uma expressão que irá determinar qual o Fluxo de Sequência será requerido para que o processo continue. Por exemplo, uma expressão pode especificar que 3 de 5 entradas dará continuidade ao processo. Outro exemplo seria uma expressão que indica que é requerido um comando do Fluxo de Sequência a e que outro dos Fluxos de Sequência "b" ou "c" são aceitáveis. As expressões são necessárias quando houver mais de um Fluxo de Sequência conectado ao Desvio. Outros comandos desconsiderados na expressão podem chegar ao Desvio, mas eles não serão utilizados para dar continuidade ao processo. É uma boa prática evitar o uso do Desvio Complexo, haja vista sua complexidade para compreensão dos leitores do diagrama Eventos Intermediários Os eventos intermediários, como o próprio nome diz, podem ocorrer nos entremeios do diagrama do processo e são identificados pela sua borda dupla. Um evento intermediário acontece em algum lugar entre o evento de início e o evento de fim. Ele não inicia nem finaliza um processo. Eles são usados para representar quando uma mensagem é enviada ou recebida, ou um atraso é esperado, ou causar um desvio no fluxo normal do processo ou demonstrar um trabalho extra de compensação. Existem duas categorias de eventos intermediários, uma que funciona como entrada ou para receber ações e outra de saída ou para enviar ou despachar ações. Os eventos com o interior da figura preenchidos com cor, são os eventos destinados a enviar ações e os eventos intermediários com as figuras não preenchidas no seu interior são destinados à receber ações. Temos nove opções de eventos intermediários, mas apenas cinco deles apresentam, também, a opção de envio, conforme as descrições a seguir: 22

23 Elemento Curso de Modelagem de Processos Descrição e Regras de Uso Mensagem (receber) Mensagem (enviar) A mensagem chega de um participante e dispara o evento. Isso faz com que o processo continue, se estava à espera da mensagem, ou muda o fluxo para um modo de exceção. No fluxo normal os Eventos de Mensagem Intermediárias podem ser usados para enviar mensagens a um participante. Se for utilizado em tratamento de exceção (desenhado na borda de uma atividade) ele vai mudar o fluxo normal para um fluxo de exceção. Se um evento intermediário de Mensagem tem a entrada de um Fluxo de Mensagem ele NÃO DEVE ter uma saída de Fluxo de Mensagem e visse versa. Tempo Erro Cancelamento Compensação Compensação (receber) (enviar) Uma data ou tempo específico ou um ciclo específico (ex: todas as segundasfeiras às 09 da manhã) pode estar configurada para acionar o evento. Se usado dentro do fluxo principal, ele age como um mecanismo de retardo. Se utilizados para manipulação de exceção (desenhado na borda de uma atividade), ele vai mudar o fluxo normal para um fluxo de exceção. Este tipo de eventos só pode ser usado atachado à borda de uma atividade, portanto, ele reage a (captura) um erro conhecido, ou qualquer erro se este não é especificado. Este tipo de evento intermediário é usado para uma transação de Sub-Processo. Este tipo de Evento deve estar anexado à borda de um sub-processo. Ele deve ser disparado se um Evento Final de Cancelamento for encontrado em uma transação do Sub-Processo. Deve também ser acionado, se uma mensagem de transação de protocolo Cancelar foi recebida enquanto o Transação está sendo executada. Este é utilizado para o tratamento de compensação - tanto ativando e realizando compensação. Quando usado em fluxo normal, este evento intermediário indica que uma compensação é necessário. Assim, é usado para "jogar" o evento de compensação. Se o evento identifica uma atividade, então essa é a atividade (e nenhuma outra), que será compensada. Caso contrário, a compensação é transmitida a todas as atividades que já tenham concluído no âmbito da instância do processo, incluindo o Processo de nível superior e incluindo todos os subprocessos. Cada atividade completa, que é objeto de uma compensação será compensada, em ordem inversa da realização das atividades. Para ser compensada, uma atividade deve ter um Evento de Compensação Intermediário anexada à sua borda. Quando anexada à borda de uma atividade, o evento vai ser desencadeado por uma compensação lançada que identifica aquela a atividade ou uma transmissão compensação. Este tipo de evento é acionado quando uma condição se torna verdadeira. Condicional Conector Conector Um conector é um mecanismo para ligar duas seções de um processo. Um Evento de Conexão pode ser usado para criar situações de looping ou para evitar uma longas sequencia de fluxo. Eles são limitados a um único nível do 23

24 (entrada) (saída) processo (ou seja, não pode vincular um processo pai com um sub-processo). Eventos Intermediário de Conexão (ou emparelhamento) também podem ser usadas como "conectores de fim de página" para imprimir um processo em várias páginas. Eles também podem ser utilizados como um objetos genérico de "Go To" dentro do nível do processo. Podem haver múltiplos Eventos de Conexão como fonte, mas SÓ PODE haver um único Evento de Conexão como alvo. Se há um evento intermediário do tipo Conector como fonte, DEVE haver um conector como alvo (com o mesmo nome). Um evento intermediário do tipo Conector quando parte do fluxo normal do processo, NÃO DEVE ser fonte e alvo de Fluxo de Sequência ao mesmo tempo. NÃO DEVE haver mais de um evento intermediário do tipo Conector como alvo para um único Conector como fonte; Sinal (receber) Múltiplo (receber) Sinal (enviar) Múltiplo (enviar) Este tipo de evento é usado para enviar ou receber sinais. Um sinal serve para comunicações gerais dentro e entre os níveis do processo, através de Piscinas, e entre Diagramas de Processos de Negócio. Um sinal BPMN é semelhante a um sinal luminoso lançado ao céu para quem quer que esteja interessado em observar e reagir. Assim, há uma fonte do sinal, mas nenhum alvo específico pretendido (isso é diferente de um Evento de Mensagem, que tem uma origem específica e um alvo específico que pode ser uma entidade ou um papel abstrato). O evento intermediário Sinal pode enviar ou receber um sinal se o evento faz parte de um fluxo normal. O evento só pode receber um sinal quando atachado à borda de uma atividade*. O evento de sinal é diferente de um evento de erro uma vez que o sinal define uma forma mais geral, a condição de erro de não-interrupção de atividades (como a conclusão bem sucedida de outra atividade), bem como possui uma maior abrangência que Eventos de Erro. Este representa que existem vários disparos atribuídos ao evento. Se usado dentro fluxo normal, o evento pode "capturar" o disparo, ou "lançar" os disparos. Quando anexado à borda de uma atividade, o evento só pode "capturar" o disparo. Quando usados para "capturar" o disparo, apenas um dos disparos definidos é exigido. Quando usado para "lançar" o disparo (o mesmo que vários eventos de fim), todos os disparos definidos serão acionados. O evento intermediário Múltiplo NÃO DEVE estar disposto no fluxo normal do processo. Algumas regras gerais são observadas no uso dos eventos intermediários: DEVE: Se um evento intermediário está disposto na borda de uma atividade ele DEVE ser fonte de apenas uma saída de Fluxo de Sequência (salvo no caso de Compensação em que a conexão se dá por meio de Associação); Quando usados em fluxo normal do processo os eventos intermediários DEVEM ser fonte de Fluxo de Sequencia e DEVEM ter apenas uma saída de Fluxo de Sequência (salvo o Conector de saída que não terá Fluxo de Sequência algum); Quando usados em fluxo normal do processo os eventos intermediários Simples e Compensação DEVEM ser alvos de Fluxo de Sequência e DEVEM ter como entrada APENAS um Fluxo de Sequência; 24

25 NÃO DEVE: Se um evento intermediário está disposto na borda de uma atividade ele NÃO DEVE ser um alvo de Fluxo de Sequência; PODE: Um ou mais eventos intermediários (exceto Conector e Simples) PODEM ser dispostos na borda de uma Atividade. ( O Cancela só pode estar e um sub-processo do tipo transação); Quando usados em fluxo normal do processo os eventos intermediários Mensagem, Tempo, Condicional, Conector e Sinal PODEM ser alvos de Fluxo de Sequência e PODEM ter como entrada apenas um Fluxo de Sequência; A notação BPMN não especifica o formato das expressões utilizadas nos eventos ou qualquer outro elemento BPMN que usa expressões. Contudo é boa prática comum, descrever textualmente abaixo dos eventos a sua identificação, origem ou destino, quando for o caso. Um evento intermediário sem nenhum desenho no seu interior pode ser usado, porém só é válido apenas para eventos intermediários que estão no fluxo principal do processo. É um evento sem tipo específico. É utilizado para a modelagem de metodologias que utilizam Eventos para indicar alguma mudança de estado no processo Atividade - Sub-processo Sub-processos podem ser inseridos a qualquer momento no diagrama após o evento de início e antes do evento de fim. Um Sub-Processo é uma atividade composta na qual existem detalhes que são definidos como um fluxo de outras atividades. Um Sub-Processo é um objeto gráfico dentro de um fluxo de processo, mas também pode ser "aberto" para mostrar um outro processo ( incorporado ou reutilizável). O Subprocesso pode estar em exibição contraída, que esconde os seus detalhes ou em uma visão expandida, que mostra seus detalhes dentro da visão do processo no qual ele está contido. Os processos expandidos podem ser usados para vários propósitos, como a representação de um processo hierárquico, um fluxo de exceção ou associação de compensação. Além dessas o Sub-processo expandido pode ser utilizado como um mecanismo para mostrar um conjunto de atividades paralelas de uma forma menos ordenada, mais compacta. Na forma contraída, o objeto de sub-processo usa um marcador + para distingui-lo de uma tarefa comum. A notação BPMN especifica cinco tipos de marcadores padrões para sub-processos: o marcador + ( de contraído ) e mais quatro marcadores que são: Loop, Paralelo (múltipla instância), Compensação e Ad Hoc. Como já visto, existem sete opções de sub-processos: 25

26 Sub-processo Normal Sub-processo Loop Sub-processo Múltipla Instância Sub-processo Ad-Hoc Sub-processo Compensação Sub-processo Expandido Sub-processo Transação A BPMN não faz especificações quanto ao texto inserido dentro dos sub-processos, contudo é boa prática que sejam utilizados verbos no infinitivo e que, de preferência, apenas um verbo seja utilizado dentro da figura, representando apenas uma ação a ser tomada. Cada sub-processo, tarefa ou evento é igual a uma ação. Os sub-processos subordinam-se a algumas regras gerais: PODE: Um Sub-processo contraído pode ter de 1 a 3 tipos de marcadores, em todas as combinações, EXCETO o Loop e o Paralelo (múltiplas instâncias) que não podem ser mostrados ao mesmo tempo; Um Sub-Processo PODE ser alvo para um fluxo de sequência, que pode ter múltiplos fluxo de entrada. Se o Sub-processo tem várias entradas de fluxo de sequência, quando o acionamento de uma das entradas chegar, o Sub-Processo será instanciado. Ele não vai esperar a chegada de acionamento dos outros caminhos. Assim quando outro acionamento do mesmo caminho ou de outro caminho chegar, um outro instanciamento do Sub-processo será criado a parte. Se for necessário controlar o fluxo de entrada, deve-se usar um Desvio ( gateway) de conversão precedendo o Sub-Processo; Um sub processo PODE ser fonte de um ou mais Fluxo de Sequência que terão acionamentos paralelos. Se não houver saída do sub-processo, isto significa que ele encerra o processo, salvo se for um sub-processo de compensação, por não serem considerados parte do fluxo normal do processo, logo ele não encerra o processo; Um sub-processo PODE ser fonte ou alvo de Fluxos de Mensagem. Ele pode ter nenhum ou algum e mais de um fluxo de mensagem conectado a ele. NÃO DEVEM: Se não existir um Evento de Início ou um fluxo sequência conectado ao Sub-Processo, este será 26

27 instanciado quando o processo geral for instanciado, salvo sub processos de compensação pois estes não são considerados parte normal do fluxo, logo NÃO DEVEM ser instanciados quando o processo geral é instanciado. Os sub-processos ainda podem ser classificados em alguns tipos: Sub-Processo Embutido: Um objeto sub-processo embutido é uma atividade que contém outras atividades (um processo). O processo dentro do processo é dependente do processo principal para acionamento e tem visibilidade aos dados globais do processo principal. Os objetos dentro do Sub- Processo embutido, sendo dependente do principal, não têm todas as características de um Diagrama de Processos de Negócios, como piscinas e raias. Um Sub-processo embutido NÃO DEVE ter Evento de Início. As atividades dentro de uma Sub-processo embutido Ad Hoc não são controladas ou sequenciadas em uma ordem específica, a sua execução é determinada pelos executantes das atividades. Elas podem ser paralelas ou sequenciais. Sub-Processo Reutilizável: Um objeto Sub-Processo reutilizável é uma atividade dentro de um processo que "chama" um outro processo em um outro diagrama completo. O processo que é chamado não é dependente do objeto Sub-Processo reutilizável do processo principal. O objeto Sub-Processo reutilizável troca dados com o processo que é chamado. A figura que um subprocesso contraído representa um objeto Sub-Processo reutilizável que faz link para a chamada do outro processo. O processo chamado pode estar em um diagrama que pode ter várias piscinas, mas a troca de dados só ocorrerá com o processo chamado, não com os demais processos do diagrama onde ele reside. O processo chamado DEVE ser instanciado como se fosse um subprocesso sem Evento de Início pois, como reutilizável, ele pode ser chamado por outro objeto de sub-processo reutilizável de qualquer outro processo. Ele pode ser instanciado também como um processo de alto nível através de um Evento de Início distinto (mensagem) como disparador. Sub- Processo de Referência: Pode haver momentos em que um modelador deseje fazer referência a um determinado sub-processo. Se os dois sub-processos apresentam exatamente o mesmo comportamento e propriedades, então quando um fizer referência ao outro, os atributos que definem o comportamento só tem que ser criados uma vez e mantidos em um único local, sendo aquele um processo de referência. Sub-Processo como Transação: Um Sub-Processo contraído ou expandido, pode ser definido como sendo uma operação que terá um comportamento especial que é controlado através de um protocolo de transação. A borda da atividade que representa o sub-processo como transação é dupla. Existem três saídas para uma transação: conclusão bem sucedida (segue o fluxo), Cancelamento, e Perigo (significa que algo saiu errado e que o êxito ou o cancelar normal não é possível usa evento intermediário de erro). Vale lembrar que um Evento Intermediário do tipo Cancelar só pode ser utilizado quando ligado à borda de uma atividade de transações. Não pode ser usado em qualquer fluxo normal e nem ser ligado a uma atividade que não seja de transação Eventos de Fim E para finalizar o desenho dos diagramas na modelagem de um processo, temos o evento de fim que 27

28 encerra um sinal um token (sinal de comando) de um evento de início do mesmo nível de processo. Podem ser utilizadas oito opções para evento de fim: Elemento Fim simples Fim Mensagem Fim Erro Fim Cancela Fim Compensação Fim Sinal Fim Imediato Fim Multiplo Descrição e Regras de Uso Evento sem um tipo específico. Ele também é usado para mostrar o fim de um Subprocesso que termina, o que faz com que o fluxo retorne ao seu processo parente. Este tipo de final indica que uma mensagem é enviada para um participante na conclusão do Processo. Este tipo de final indica que um erro conhecido deve ser gerado. O erro será abrangido pelo Evento de Erro Intermediário com o mesmo Código de Erro ou sem código de erro que está no limite da atividade de encerramento mais próxima (Hierárquica). O comportamento do processo é indeterminado se nenhuma atividade do Processo apresenta um Evento de Erro Intermediário como esse. O sistema que está executando o processo pode definir tratamento de erros adicionais, neste caso, um comum terminando a instanciação do processo. Este tipo de final é usado dentro de uma transação do Sub-Processo. Ele vai indicar que a transação deve ser cancelada e irá desencadear um Evento Intermediário de Cancelamento anexado ao Sub-Processo. Além disso, ele irá indicar que uma mensagem de Cancelamento do Protocolo de Transação deve ser enviada a entidades envolvidas na a transação. Este tipo de final indica que é necessária uma compensação. Se uma atividade é identificada, então, aquela é a atividade que será compensada. Caso contrário, todas atividades que já tenham sido concluídas dentro do processo, começando com a de nível superior do Processo, incluindo todos os sub-processos, estão sujeitas à compensação, executada em ordem inversa. Para ser compensada, uma atividade deve ter um Evento de Compensação Intermediária anexado a sua borda. Este tipo de final indica que um sinal será transmitido quando o final for alcançado. Note que o sinal, que é transmitido para todo o processo que pode receber o sinal, podem ser enviados entre os diferentes níveis do processo ou piscinas, mas não é uma mensagem (que tem uma origem e um alvo específicos). Esse tipo de final indica que todas as atividades do processo devem ser imediatamente encerradas. Isso inclui todas as instâncias de Multi-Instanciação. O processo é encerrado sem compensação ou manipulação de eventos. Este significa que existem múltiplas consequências na finalização do processo. Todos elas vão ocorrer (ex: podem haver várias mensagens enviadas). Os atributos do Fim do evento definirão qual dos outros tipos de resultados se aplicam. 28

29 Tal como ocorre para os demais elementos, algumas regras gerais são aplicadas a todos os eventos de fim: DEVE: Um evento de fim DEVE ser alvo de Fluxo de Sequência. NÃO DEVE: Um evento de fim NÃO DEVE ser alvo de Fluxo de Mensagem; Um evento de fim NÃO DEVE ser fonte de Fluxo de Sequência (salvo aqueles dispostos na borda de um sub-processo expandido). PODE: PODE haver mais de um evento de fim em um único nível de processo; Um evento de fim PODE ser alvo de mais de um Fluxo de Sequência; Um evento de fim PODE ser disposto na borda de um sub-processo. OPCIONAL, DESDE QUE: Um Diagrama de Processo pode conter vários níveis de processos, tais como processos ou sub- processo. Um Evento de Fim, para qualquer nível de processo em um diagrama, é OPCIONAL, DESDE QUE considerado o seguinte: O evento de fim implícito do processo não terá um resultado; Se existir um Evento de Início, DEVE existir ao menos um Evento de Fim; Se existir um Evento de Fim, os outros elementos de fluxo DEVEM ter um Fluxo de Sequência como saída; Se não existir um evento de fim, os objetos que não possuem Fluxo de Sequência como saída, se finalizam um caminho do processo, mas o processo só finaliza completamente quanto todos os objetos paralelos finalizarem seus caminhos Artefatos Em em qualquer parte do diagrama de um processo, podem ser inseridos os Artefatos, que tem a função de mostrar informações adicionais sobre um processo que não estão diretamente relacionadas com o Fluxo de Sequência ou Fluxo de Mensagens do processo e por este motivo eles são conectados aos objetos de um fluxo por meio das linhas de Associação já demonstradas anteriormente. A notação BPMN fornece três Artefatos padrões: Elemento Descrição e Regras de Uso Objeto de Dados fornecem informações sobre o que o processo faz, ou seja, como documentos, dados e outros objetos são utilizados e atualizados durante o processo. Embora o nome "Objeto de Dados" possa implicar um documento eletrônico, este artefato pode ser usados para representar diferentes tipos de 29

30 [atributo] Obeto de Dados objetos, tanto eletrônicos como físicos. Curso de Modelagem de Processos O objeto de Dados pode ser mostrado como sendo uma entrada ou uma saída de um processo, o que é demonstrado pela seta da linha de Associação do objeto de dados com o objeto do fluxo. Além disso, o atributo de estado do objeto de dados pode mudar para mostrar o impacto do processo sobre o objeto de dados. Ex de atributos: [vazio] ou [preenchido] no caso de um formulário. Embora deva ser evitado, em alguns casos, o Objeto de Dados PODE apresentar-se ligado ao meio de uma seta de Fluxo de Sequência ou de Mensagem que conecta uma atividade a outra mas eles NÃO DEVEM ser confundidos com a própria mensagem, pois representam apenas a "carga" ou o conteúdo da mensagem. Anotação Anotações de texto são mecanismos para o modelador fornecer informações adicionais ao leitor de um diagrama BPMN. Elas também são conectadas aos objetos por linhas de Associação, mas não afetam o fluxo do processo. (O testo é escrito no espaço a partir da figura do grande colchete.) Grupo é um artefato que fornece um mecanismo visual para agrupar elementos de um diagrama informalmente. As categorias podem ser destacadas através de outros mecanismos, tais como cor, definida por um modelador ou uma ferramenta de modelagem. Grupo Como um artefato, um Grupo não é uma atividade ou qualquer objeto de fluxo e, portanto, NÃO PODE conectar-se a um Fluxo de Sequência ou Fluxo de Mensagens. Além disso, os grupos não são limitados por restrições de Piscinas ou Raias. Isto significa que um grupo pode estender além das fronteiras de uma Piscina e cercar os elementos do diagrama, muitas vezes, para identificar as atividades que existem dentro de uma transação. Regras gerais para os Artefatos: DEVE: Os Artefatos DEVEM ser conectados aos objetos de um fluxo por meio das linhas de Associação. NÃO DEVE: Os Artefatos NÃO DEVEM ser alvo ou fonte de Fluxos de Sequência ou Fluxo de Mensagem. PODE: Um modelador ou ferramenta de modelagem PODE adicionar novos tipos de artefatos a um diagrama. Qualquer novo artefato deve seguir as mesmas regras aplicadas a estes artefatos. 30

31 3.14 Permissões em BPMN Curso de Modelagem de Processos As seguintes extensões de um diagrama BPMN são permitidas: Novos marcadores ou indicadores podem ser adicionados aos elementos gráficos especificados. Estes marcadores ou indicadores podem ser usados para destacar um atributo específico de um elemento BPMN para representar um novo subtipo do conceito correspondente. Uma nova forma que representa uma espécie de Artefato pode ser adicionada a um diagrama, mas a forma de um novo artefato NÃO DEVERÁ estar em conflito com uma forma especificada para qualquer outro objeto BPMN ou o marcador. Os elementos gráficos podem ser coloridos, e a coloração pode apresentar especificado semântica que complemente a informação transmitida pelo elemento especificado por este padrão. O estilo de linha de um elemento gráfico pode ser alterado, mas tal alteração não deve estar em conflito com qualquer outro estilo de linha exigidos por esta especificação. Uma extensão não deve alterar a forma especificada de um elemento gráfico ou um marcador definido (por exemplo, mudar um quadrado para um triângulo, ou mudar os cantos arredondados em cantos quadrados, etc.) 4. Ciclo de Vida BPM Conforme já comentado, a modelagem de processos é um trabalho fundamental para a gestão das atividades de uma organização por todos os motivos já citados. Contudo a modelagem não é um fim, pois o objetivo de se ter boa visibilidade e comunicação dos processos compreende um meio para uma melhor gestão empresarial. A gestão baseada em processos deve apoiar-se num ciclo de vida de gerenciamento de processos, denominado ciclo de vida BPM (Businsess Process Management) ilustrado pela figura abaixo: 31

32 Este documento oferece orientações sobre as fases de Análise de Processos e Desenho e Modelagem de processos, porém observe que existem outras fases importantes, em especial a fase mais crítica que se refere ao Monitoramento de Controle dos Processos, fase na qual são acompanhados o desempenho dos indicadores definidos para o processo, e encaminhadas ações para o caso de não cumprimentos das metas. Por isso é importante que ainda na fase de modelagem e documentação do processo, sejam definidos os indicadores e metas de resultados desejadas. O anexo 3 deste documento sugere atributos para levantamento dos indicadores que devem compor a documentação do processo junto a explicação descritiva dos diagramas elaborados. Abaixo seguem a conceituação de cada fase do Ciclo de Vida BPM baseado nas orientações do Guia BPM- CBOK da Associação de Profissionais de BPM (ABPMP): 4.1 Planejamento e estratégia Nesse modelo, o ciclo de vida BPM começa com o desenvolvimento de um plano e uma estratégia dirigida a processos para a organização. O plano inicia por um entendimento das estratégias e metas da organização desenhadas para assegurar uma proposição de valor atrativa para clientes. O plano fornece uma estrutura e o direcionamento para gerenciamento contínuo de processos centrados no cliente. Estabelece fundação para uma abordagem BPM holística para assegurar o alinhamento com a estratégia organizacional e a integração de estratégia, pessoas, processos e sistemas ao longo de seus limites funcionais. Essa fase estabelece a estratégia e o direcionamento do processo BPM. Também identifica papéis e responsabilidades organizacionais apropriadas de BPM, patrocínio executivo, metas, expectativas de medições de desempenho e metodologias. Caso se espere que atividades transformadoras significativas possam ocorrer, são analisadas mudanças organizacionais em estratégicas. 4.2 Análise de processos de negócio A análise de processos de negócio incorpora várias metodologias com a finalidade de entender os atuais processos organizacionais no contexto das metas e objetivos desejados. A análise assimila informações oriundas de planos estratégicos, modelos de processo, medições de desempenho, mudanças no ambiente externo e outros fatores, a fim de entender completamente os processos de negócio no escopo da organização como um todo. 4.3 Desenho e modelagem de processos de negócio As atividades de desenho de processos focam no desenho intencional e cuidadoso de como o trabalho ponta-a-ponta ocorre de modo a entregar valor aos clientes. A seqüência de atividades é documentada, incluindo o desenho do trabalho realizado, em que tempo, em qual local, por quais atores de processo e utilizando qual metodologia. O desenho define o que a organização quer que o processo seja e responde 32

33 questões como: o quê, quando, onde, quem e como o trabalho ponta-a-ponta é realizado. Um importante componente de desenho é também assegurar que métricas e controles gerenciais apropriados estejam implementados para medição de desempenho e conformidade. Em um ciclo de vida iterativo de BPM, atividades iniciais de desenho podem focar na padronização ou automação de atividades atualmente realizadas ad-hoc, enquanto atividades de desenho mais maduras podem focar no redesenho ou transformação radical do processo, ou melhorias incrementais desenhadas para otimização. Entender o processo envolve tipicamente a modelagem de processo e uma avaliação dos fatores ambientais que habilitam ou restringem o processo. Para organizações que estão menos maduras na prática BPM, pode ser a primeira vez que o processo de negócio ponta-a-ponta tenha sido documentado. Organizações mais maduras podem focar mais em fatores ambientais, nuances e exceções aos processos de negócio. 4.4 Implementação de processos Implementação de processos de negócio é a realização do desenho aprovado de processo de negócio em procedimentos e fluxo de trabalho documentados, testados e operacionais. Também inclui a implementação de políticas e procedimentos novos ou revisados. Durante atividades de implementação assume-se que as fases de análise, modelagem e desenho criaram e aprovaram um conjunto completo de especificações, então, somente pequenos ajustes devem ocorrer durante a implementação. 4.5 Monitoramento e controle de processos No contexto do ciclo BPM, medição e monitoramento provêem informações-chave de desempenho de processos através de métricas relacionadas às metas e ao valor para a organização. A análise de informações de desempenho de processos pode resultar em atividades de melhoria, redesenho ou reengenharia. 4.6 Refinamento de processos A contínua medição e monitoramento de processos de negócio fornecem a informação necessária para que gestores de processo ajustem recursos a fim de atingir objetivos dos processos. O refinamento trata aspectos de ajustes e melhorias pós-implementação de processos com base nos indicadores e informações-chave de desempenho. 33

34 Referências Curso de Modelagem de Processos BPMN-OMG: ABPMP: GUIA BPM CBOK: ZACHMANN: BPMN ANIMADO: Anexos Anexo 1: Artefato de Análise de Procesos PERGUNTAS RESPOSTAS O que? Qual o nome do processo? Qual o objetivo do processo? O que dispara o início do processo? Quais as entradas (insumos) do processo? Quais as principais atividades devem ser realizadas no processo? Quais são as entregas (produto ou serviço) do processo? Qual a classificação do processo quanto à finalidade? (Finalístico, Apoio ou Gerencial?) Qual a classificação do processo quanto à hierarquia? (Macroprocesso, Processo ou Subprocesso?) Qual a classificação do processo quanto ao detalhamento? (Cadeia, Visão Geral, Negócio, Procedimento, Sistema?) Quais os outros processos externos se integram diretamente com este? Quais os indicadores de avaliação de desempenho do processo? Quem? Quem é o gestor geral responsável pelo processo? 34

35 Quem são os participantes que atuam na execução de atividades do processo? Quem é responsável pela documentação do processo? Quem são os clientes do processo? Quem são os fornecedores do processo? Quem são as instituições externas que se relacionam com o processo? (informar locais:url) Curso de Modelagem de Processos Como? Quais as leis, normas ou regras que regem o processo? (informar locais:url) Quais são os manuais ou documentos de procedimentos e intruções usados como apoio para o processo? (informar locais:url) Qual a tecnologia é utilizada na execução do processo? (Sistemas [informar locais:url], computadores, máquinas, ferramentas, etc.) Quais os formulários devem ser alimentadospara o processo? (informar locais:url) Quais os formulários são produzidos pelo processo? (informar locais:url) Quando? Quais as datas chaves determinam momentos de atividades específicas do processo? (informar as atividades envolvidas). Quais os prazos determinados para execução de atividades e de todo o processo? Quando o desempenho do processo é avaliado? Onde? Onde (locais geográficos) as atividades do processo são executadas? (informar as atividades envolvidas). Onde (locais geográficos e virtuais) a documentação do processo é armazenada? Por que? Por que este processo é necessário? 35

36 Anexo 2: Poster da Notação BPMN 1.2 Curso de Modelagem de Processos Anexo 3: Atributos e orientações para indicadores de processos Um processo de negócio é um conjunto de ações que são executadas para alcançar resultados, mas, ao final da execução de um processo, como sabermos se os resultados saíram conforme desejado? Quanto tempo foi gasto na execução do processo? O esforço e custos planejados para o processo foram os mesmos praticados durante sua execução? Os executores do processo agiram conforme as orientações formais do processo? E se os resultados alcançados não forem compatíveis com os resultados desejados, o que fazer? Um processo deve ser bem elaborado, bem documentado e bem disseminado, mas ainda assim, para garantir que ele alcance os melhores resultados, é preciso que a sua execução seja medida e gerenciada. Essas perguntas do parágrafo anterior, dentre outras, refletem a necessidade de se ter Indicadores de Processos, ou seja, informações sobre os resultados alcançados pelo processo que permitam os gestores e líderes fazerem correções e/ou tomarem decisões sobre investimentos, redirecionamentos e outras 36