ads:
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO
PUC–SP
Daniele Chrusciak Szilagyi
Modelagem de Processos de Negócio -
um Comparativo entre BPMN e UML
MESTRADO EM TECNOLOGIAS DA INTELIGÊNCIA E DESIGN DIGITAL
SÃO PAULO – SP
2010
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO
PUC–SP
Daniele Chrusciak Szilagyi
Modelagem de Processos de Negócio -
um Comparativo entre BPMN e UML
MESTRADO EM TECNOLOGIAS DA INTELIGÊNCIA E DESIGN DIGITAL
Dissertação apresentada à Banca
Examinadora como exigência parcial para
obtenção do título de MESTRE em
Tecnologias da Inteligência e Design Digital
pela Pontifícia Universidade Católica de São
Paulo, sob a orientação do Prof. Doutor
Demi Getschko.
SÃO PAULO
2010
ads:
Banca Examinadora
________________________________
________________________________
________________________________
Ao meu marido, Luiz David Szilagyi.
AGRADECIMENTOS
Agradeço em primeiro lugar a DEUS pela vida que me concedeu e pelas
oportunidades infinitas de progresso intelectual e espiritual;
À minha família, que mesmo distante, esteve sempre presente, me apoiando
com seu amor incondicional, acreditando na minha capacidade e me
incentivando;
Ao meu orientador, Prof. Dr. Demi Getschko, e aos professores do TIDD,
pela valiosa contribuição nos ensinamentos repassados;
A todos os meus amigos, que de alguma maneira compartilharam esta etapa
em minha vida.
“Não se pode ensinar alguma coisa a alguém,
pode-se apenas auxiliar a descobrir por si mesmo.”
Galileu Galilei
RESUMO
Levando em consideração que toda organização possui um propósito, o qual
envolve a prestação de serviços ou produção de mercadorias é necessário
entender e estabelecer o conjunto de atividades necessárias para cumprir esta
meta. Este conjunto de atividades é chamado de processo. A modelagem de
processos mostra-se como oportunidade para melhorar tais processos antes de
informatizá-los, proporcionando a análise e o redesenho dos mesmos,
identificando e corrigindo suas falhas, redundâncias e gargalos. Este trabalho
apresenta a importância da técnica de Modelagem de Processos de Negócio
para auxiliar o correto entendimento dos processos de negócio do cliente.
Serão apresentados os benefícios e vantagens da notação de modelagem de
processos de negócio BPMN, em comparação com a notação de Modelagem
de Negócio da UML.
Palavras-chave: Modelagem de processos de negócio, BPMN, UML
ABSTRACT
Considering that all organizations have a purpose, which involves services
performing or products generation its necessary understanding and establishing
the activities set needed to accomplish this goal. This activity set is known as
process. The process modeling appear as an opportunity to improve these
processes before being automatized, proportionating the analysis and the
redesign of them, identifying and correcting their fails, redundancies and bottle-
necks. This work presents the importance of the business process modeling
technique in order to aid the correct understanding of the customer business
process. It will be presented the benefits and advantages of business process
modeling notation BPMN, in comparison with the business modeling from UML.
Keywords: Business Process Modeling; BPMN, UML
LISTA DE FIGURAS
FIGURA 1 – Conceitos da modelagem de processos de negócio.........................15
FIGURA 2 – Áreas de conhecimento do BABOK ..................................................28
FIGURA 3 – Os objetos que compõem um negócio..............................................40
FIGURA 4 – Exemplo de um evento intermediário anexado na borda de uma
atividade................................................................................................................54
FIGURA 5 – Sub-processo collapsed....................................................................57
FIGURA 6 – Um sub-processo expanded .............................................................57
FIGURA 7 – Um sub-processo embutido ..............................................................58
FIGURA 8 – Representação de tarefa e sub-processo com loop..........................58
FIGURA 9 – Representação de tarefa e sub-processo com loop de múltiplas
instâncias ..............................................................................................................59
FIGURA 10 – Representação de tarefa e sub-processo com compensação ........59
FIGURA 11 – Objetos de conexão básicos em BPMN..........................................61
FIGURA 12 – Um exemplo de lanes dentro de um pool .......................................62
FIGURA 13 – Artefatos básicos em BPMN ...........................................................63
FIGURA 14 – Diagrama use-case de negócio do setor de check-in de um
aeroporto...............................................................................................................68
FIGURA 15 – Diagrama de atividade do use-case de negócio check-in
individual ...............................................................................................................69
FIGURA 16 – Um exemplo de diagrama de classes de negócio...........................70
FIGURA 17 – Diagrama de sequência do use-case de negócio check-in
individual ..............................................................................................................71
FIGURA 18 – Processo “Agendamento de Viagem” modelado em UML ..............88
FIGURA 19 – Processo “Agendamento de Viagem” modelado em BPMN ...........89
LISTA DE TABELAS
TABELA 1 – Ferramentas de modelagem de processos ..........................................46
TABELA 2 – Estereótipos BPMN ..............................................................................48
TABELA 3 – Tipos de eventos iniciais em BPMN .....................................................51
TABELA 4 – Tipos de eventos intermediários em BPMN..........................................53
TABELA 5 – Tipos de eventos finais em BPMN........................................................54
TABELA 6 – Tipos de tarefas em BPMN...................................................................56
TABELA 7 – Tipos de gateways em BPMN...............................................................60
TABELA 8 – Elementos estereotipados da UML para a modelagem de negócio .....65
TABELA 9 – Atividade e seqüência em UML e BPMN..............................................72
TABELA 10 – Atribuição de atividades a participantes em UML e BPMN.................73
TABELA 11 – Agrupamento de atividades relacionadas em UML e BPMN ..............74
TABELA 12 – Divisões inclusiva, condicional e complexa em UML e BPMN ...........75
TABELA 13 – Escolhas exclusiva e múltipla em UML e BPMN ................................77
TABELA 14 – Junção simples e múltipla em UML e BPMN......................................79
TABELA 15 – Término implícito em UML e BPMN....................................................80
TABELA 16 – Escolha adiada em UML e BPMN ......................................................82
TABELA 17 – Exemplo de um milestone em UML e BPMN......................................83
TABELA 18 – Cancelar atividade em UML e BPMN .................................................84
TABELA 19 – Eventos de envio e recebimento e sinais em UML e BPMN...............86
TABELA 20 – Outros elementos usados em UML e BPMN ......................................87
LISTA DE ABREVIATURAS E SIGLAS
AD
Activity Diagram
BABOK
Business Analysis Body of Knowledge
BPD
Business Process Diagram
BPDM
Business Process Definition Metamodel
BPM Modelagem de Processo de Negócio
BPMI
Business Process Management Initiative
BPML
Business Process Modeling Language
BPMN
Business Process Modeling Notation
CBAP
Certified Business Analysis Professionals
EPC
Event Driven Process Chain
IDEF3
Integrated DEFinition Method 3
IIBA
International Institute of Business Analysis
KAs
Knowledge Areas
OMG
Object Management Group
RAD
Role Activity Diagram
TI Tecnologia da Informação
UML
Unified Modeling Language
XML
Extensible Modeling Language
SUMÁRIO
DEDICATÓRIA
AGRADECIMENTOS
EPÍGRAFE
RESUMO
ABSTRACT
LISTA DE FIGURAS
LISTA DE TABELAS
LISTA DE ABREVIATURAS E SIGLAS
SUMÁRIO
1 INTRODUÇÃO ...................................................................................................14
1.1 Tema...............................................................................................................16
1.2 Apresentação do problema.............................................................................16
1.3 Apresentação da justificativa ..........................................................................16
1.4 Objetivos.........................................................................................................18
1.4.1 Apresentação do objetivo geral .............................................................18
1.4.2 Apresentação dos objetivos específicos................................................18
1.5 Resultados esperados e contribuições ...........................................................18
1.6 Método de pesquisa .......................................................................................18
1.6.1 Estruturação do trabalho........................................................................19
2 FUNDAMENTAÇÃO TEÓRICA .........................................................................21
2.1 Análise de negócio .........................................................................................21
2.1.1 Histórico da análise de negócios ...........................................................22
2.1.2 Principais conceitos ...............................................................................23
2.1.1.1 Domínios......................................................................................23
2.1.1.2 Soluções ......................................................................................23
2.1.1.3 Requisitos ....................................................................................24
2.1.1.4 Partes interessadas .....................................................................26
2.1.1.5 Tarefas.........................................................................................27
2.1.1.6 Técnicas.......................................................................................27
2.1.3 Áreas de conhecimento .........................................................................27
2.1.3.1 Planejamento e monitoramento da análise de negócios ................28
2.1.3.2 Análise Corporativa ........................................................................29
2.1.3.3 “Elicitação”......................................................................................31
2.1.3.4 Análise de requisitos.......................................................................32
2.1.3.5 Definição e validação da solução ...................................................33
2.1.3.6 Gerenciamento e comunicação dos requisitos ...............................34
2.1.3.7 Competências de apoio..................................................................35
2.2 Processos.......................................................................................................35
2.2.1 A importância dos processos nas organizações....................................35
2.2.2 Processos de negócio............................................................................37
2.3 Modelagem de Processos de Negócio ...........................................................39
2.3.1 Modelagem do estado atual (As Is) .......................................................42
2.3.2 Modelagem do estado futuro (To Be) ....................................................43
2.4 Modelagem versus análise .............................................................................43
2.5 Notações para modelagem de processos de negócio ....................................44
2.6 Ferramentas de modelagem de processos.....................................................45
3 A NOTAÇÃO DE MODELAGEM DE PROCESSOS DE NEGÓCIO –
BPMN........................................................................................................................47
3.1 Histórico e objetivos da notação BPMN..........................................................47
3.2 Elementos gráficos .........................................................................................50
3.2.1 Objetos de Fluxo....................................................................................50
3.2.1.1 Eventos...........................................................................................50
3.2.1.2 Atividades .......................................................................................55
3.2.1.3 Gateways........................................................................................60
3.2.2 Objetos de conexão...............................................................................61
3.2.3 Swimlanes .............................................................................................61
3.2.4 Artefatos ................................................................................................63
4 MODELAGEM DE NEGÓCIO COM UML ..........................................................64
4.1 Apresentação da linguagem UML para modelagem de negócio ....................64
4.2 Diagramas UML para modelagem de processos de negócio .........................66
4.2.1 Diagrama use-case de negócio .............................................................67
4.2.2 Diagrama de atividade ...........................................................................68
4.2.3 Diagrama de classe ...............................................................................69
4.2.4 Diagramas de interação.........................................................................70
5 ANÁLISE COMPARATIVA ENTRE AS NOTAÇÕES DE MODELAGEM
DE PROCESSOS DE NEGÓCIO BPMN E UML ......................................................72
5.1 Seqüência de atividades.................................................................................72
5.2 Atribuição de atividades para participantes ....................................................73
5.3 Agrupamento de atividades relacionadas.......................................................73
5.4 Divisão paralela e sincronização ....................................................................74
5.5 Escolha exclusiva e escolha múltipla..............................................................76
5.6 Junção simples e múltipla...............................................................................78
5.7 Término implícito ............................................................................................79
5.8 Escolha adiada (deferred)...............................................................................81
5.9 Milestones.......................................................................................................82
5.10 Cancelar atividade ..........................................................................................83
5.11 Sinais e eventos .............................................................................................85
5.12 Outros elementos ...........................................................................................86
5.13 Exemplo..........................................................................................................87
6 CONCLUSÕES ..................................................................................................90
6.1 Conclusões .....................................................................................................90
6.2 Sugestões para trabalhos futuros ...................................................................94
REFERÊNCIAS.........................................................................................................95
14
1 INTRODUÇÃO
O movimento da administração científica do final do século XIX e princípio
do século XX baseava-se no pressuposto de que o comportamento no trabalho
podia ser objeto de engenharia, projetado de acordo com os princípios de
racionalidade e eficiência. O principal apóstolo desta revolução foi Frederick
Winslow Taylor. A administração científica de Taylor pode ser interpretada como
sendo a primeira onda da gestão de processos. Muitos dos conceitos de Taylor
servem como base para os princípios de modelagem de processos, e quase um
século depois, continuam vivos e fortes nos pressupostos das organizações
(DAVENPORT, 1994).
A segunda onda veio com a reengenharia de Michael Hammer, baseada na
idéia central de que era possível melhorar drasticamente o desempenho das
empresas por meio de mudanças radicais nas operações. A popularização do
conceito disseminou-se durante a década de 90, assim como outras técnicas de
melhorias de processos e workflows centrados em documentos, por exemplo.
Ainda na mesma década, o autor trata do que poderia ser a principal
conseqüência da reengenharia, no caso, o surgimento da organização orientada
para processos (HAMMER, 2002).
Os processos de negócio e seus projetos ganharam importância nos anos
90. O que era considerado inovador e criativo constituía-se em base para
obtenção de vantagens competitivas na década de 80, como por exemplo,
qualidade e baixo custo tornaram-se apenas requisitos mínimos para uma
organização continuar no mercado. Seguindo os estudos de (SANTOS et al.,
2006), a informação é vista como um bem precioso na sociedade atual, que deve
ser mantido e aproveitado ao máximo. As organizações perceberam a
necessidade de conhecer e controlar os seus processos dando ênfase nas
informações envolvidas, o que auxiliou as mesmas a compreender o seu próprio
negócio, identificando suas necessidades reais, visando maior competitividade,
qualidade total, produtividade e eficiência.
A descoberta de maneiras inovadoras de melhorar processos de negócio é
um caminho reconhecido para a agilidade da empresa e vantagem competitiva.
15
Empresas vêm procurando novas maneiras de reestruturar seus trabalhos e
melhorar seus processos de negócio (SMITH e FINGAR, 2003).
Em face dessa realidade, a Modelagem de Processos de Negócio (BPM)
1
se inclui neste ponto. Ela é usada para usufruir da manipulação da informação,
tornando-se uma abordagem ideal para auxiliar as organizações, identificando e
mapeando suas reais necessidades. Torna-se assim, cada vez mais comum
encontrar organizações que modelam seus processos de negócio obtendo um
maior conhecimento de sua estrutura e necessidades. A modelagem de
processos de negócio é um conjunto de conceitos, modelos e técnicas com o
objetivo de desenvolver o modelo de negócio da organização. Este modelo é
resultado de uma abstração da organização, considerando as suas características
essenciais, do ponto de vista do negócio. De uma forma geral, seu objetivo é
responder às seguintes perguntas a respeito da organização: O que é feito?
Quem faz? Quando? Onde? Por quê? Como? Alguns conceitos para fazer esta
modelagem serão estudados, tais como os objetivos e processos de negócio. A
Figura 1 exemplifica esses conceitos.
Fonte: adaptado de (SANTOS et al., 2006),
FIGURA 1 – Conceitos da modelagem de processos de negócio
1
O termo BPM pode ser facilmente confundido com outros acrônimos. BPM pode também ser usado para
referenciar Business Performance Management (Gerenciamento de Desempenho de Processos); Business
Process Management (Gerenciamento de Processos de Negocio) ou ainda Business Process Monitoring
(Monitoracao de Processos de Negocio). Para não haver dúvidas ou confusão de conceitos, nesta
dissertação o termo BPM é usado com o significado de Modelagem de Processos de Negócio.
16
Existem diversas abordagens para a modelagem de processos de negócio,
ou seja, formas de representação dos conceitos do modelo de negócio. Neste
trabalho será feita uma comparação entre duas abordagens: a modelagem de
negócios utilizando a linguagem de modelagem UML (Unified Modeling
Language) e a BPMN – Notação de Modelagem de Processos de Negócio
(Business Process Modeling Notation), notação esta disponibilizada para os
usuários em maio de 2004 e adotada oficialmente pela OMG (Object Management
Group) em 2006. Tem por objetivo principal fornecer uma especificação do
processo de modelagem de negócio que seja compreensível por usuários de
negócio, desde analistas de negócio que criam os desenhos iniciais dos
processos para os desenvolvedores técnicos responsáveis pela implementação
da tecnologia que executará o processo, e finalmente para os responsáveis pela
gestão do negócio. Assim, BPMN cria uma ponte padronizada entre o processo
de negócio e sua implementação (WHITE, 2004a).
1.1 Tema
Modelagem de Processos de Negócio.
1.2 Apresentação do problema
Como melhorar o entendimento dos processos de negócio através da
modelagem dos processos de negócio usando a notação BPMN?
1.3 Apresentação da justificativa
Um sistema inclui vários elementos: software, hardware, pessoal, dados,
documentação e procedimentos. A Engenharia de Sistemas ajuda a traduzir as
necessidades de negócio em um modelo de sistema que faz uso de um ou mais
destes elementos (PRESSMAN, 2006).
De acordo com (OWEN e RAJ, 2003) a modelagem de processos negócio
tem sido amplamente discutida e praticada. Entretanto, o autor menciona a
17
existência de um “vazio” entre os negócios e os sistemas de informação que
suportam o negócio. Neste contexto, acredita-se que ainda há algum caminho a
percorrer para que a ligação entre estes dois modelos possa ser percorrida sem
sobressaltos.
Pesquisas significativas na área (STANDISH GROUP, 2001) já
demonstraram que para um projeto ter sucesso, os objetivos de negócio devem
estar claros. Um sistema que atenda suas reais necessidades pode ser uma
vantagem competitiva do negócio, caso contrário, este pode ter seu desempenho
prejudicado. Esse é um dos principais motivos do início de uma troca de
paradigma da engenharia de sistemas orientada à tecnologia para estruturas
orientadas ao modelo do negócio (DIAS et al., 2005), neste trabalho fazendo uma
comparação entre as principais notações de modelagem de processos de negócio
utilizadas, UML e BPMN, para melhorar o desenvolvimento do sistema através do
entendimento dos processos de negócio.
A razão de se fazer uma comparação entre essas duas abordagens, é
mostrar que a notação BPMN fornece algumas vantagens para modelar
processos de negócios em relação à UML; já que a mesma foi desenvolvida
especificamente para modelar processos de negócio (OWEN e RAJ, 2003).
De uma maneira clara e objetiva, pode-se descrever as principais
motivações para a modelagem dos processos de negócio:
• Melhor compreensão dos mecanismos principais do negócio;
• Servir como base para a criação de sistemas de informação que deverão
suportar o negócio;
• Melhorar o desenvolvimento do sistema através do entendimento dos
processos de negócio;
• Garantir que usuários, desenvolvedores e especialistas no negócio
tenham um entendimento comum sobre o negócio;
• Melhorar os processos antes de informatizá-los; e
• Corrigir falhas, redundâncias e gargalos no processo (SANTOS et al.,
2006).
18
1.4 Objetivos
1.4.1 Apresentação do objetivo geral
Estudar o Processo de Modelagem de Negócios, através da notação
BPMN e modelagem de processos de negócio com UML para melhorar o
entendimento das necessidades dos clientes, bem como o correto
desenvolvimento do sistema, em uma fase posterior.
1.4.2 Apresentação dos objetivos específicos
• Estudar os conceitos básicos da modelagem de processos de negócio;
• Estudar a modelagem de processos de negócio usando BPMN;
• Estudar a modelagem de negócio com UML;
• Fazer um comparativo entre as duas abordagens e mostrar os
benefícios da notação BPMN.
1.5 Resultados esperados e contribuições
Melhorar o entendimento dos processos de negócio, através da
Modelagem de Processos de Negócio usando BPMN, e, conseqüentemente, o
sucesso dos sistemas desenvolvidos.
1.6 Método de pesquisa
Para que uma pesquisa científica seja considerada confiável e atinja os
objetivos a que se destina é necessária a definição do método a ser utilizado,
visando esclarecer e orientar os procedimentos de forma coerente e organizada
facilitando o trabalho do pesquisador.
Do ponto de vista dos seus objetivos essa dissertação é uma pesquisa
exploratória, pois trava um maior conhecimento do problema, através de
pesquisas bibliográficas. Conforme define Gil (1999), a pesquisa exploratória visa
proporcionar maior familiaridade com o problema com vista a torná-lo explícito ou
19
a construir hipóteses. Envolve levantamento bibliográfico; análise de exemplos
que estimulam a compreensão.
Baseado nesta definição será feito inicialmente o levantamento bibliográfico
e fundamentação teórica do assunto. Serão instaladas ferramentas para
modelagem de processos de negócio, para construção dos elementos e
exemplificação da teoria. Para a modelagem usando a linguagem UML será
utilizada a ferramenta Sparx Systems Enterprise Architect Version 7.5. Já para a
notação BPMN será utilizada a ferramenta Business Process Visual Architect 3.2
Modeler Edition da Visual Paradigm. Para esta dissertação, foi pesquisado
inicialmente uma ferramenta única, que implementasse as duas notações. A
versão proprietária da Sparx, o Enterprise Architect além dos diagramas UML,
disponibiliza a notação BPMN versão 1.1, porém não contempla todos os
elementos estudados no Capítulo 3. Por este motivo, foi estudada e escolhida
outra ferramenta, específica para a notação BPMN, Business Process Visual
Architect 3.2 Modeler Edition.
Após o levantamento bibliográfico e instalação das ferramentas, as duas
notações estudadas, BPMN e UML, serão apresentadas para que a comparação
dessas abordagens possa ser realizada, apresentando assim as conclusões.
1.6.1 Estruturação do trabalho
A apresentação da dissertação é estruturada em forma de capítulos, onde
no Capítulo 1 é apresentado o tema escolhido para a pesquisa, expondo a
justificativa da escolha, demonstrando os objetivos pretendidos, bem como a
estrutura do trabalho.
No Capítulo 2 é feita uma fundamentação teórica, apresentado uma breve
introdução sobre a notação BPMN e modelagem de processos de negócio com
linguagem UML, bem como os principais conceitos relacionados a modelagem de
processos de negócio, para melhor entendimento e desenvolvimento do trabalho.
No Capítulo 3 são apresentados os conceitos teóricos sobre a notação de
modelagem de processos de negócio BPMN, enfatizando seu funcionamento e
características. Para a descrição destes conceitos, os principais autores adotados
20
foram Stephen A. White e Derek Miers, que trabalham com esta notação desde
sua criação, sendo representantes da mesma na OMG.
No Capítulo 4 é apresentado a modelagem de negócio com UML, para
possibilitar que seja feita, no Capítulo 5, uma comparação entre as abordagens
estudadas.
A seguir, no Capítulo 6 são apresentadas as conclusões gerais obtidas na
pesquisa, evidenciando os benefícios da notação BPMN e recomendações para
pesquisas futuras. Por fim, são apresentadas as referências usadas nesta
dissertação.
21
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são descritos os conceitos básicos envolvidos nessa
dissertação, com o objetivo de contextualizar o trabalho desenvolvido na área de
modelagem de processos de negócio. O primeiro item deste capítulo apresenta a
Análise de Negócios e conceitos relacionados. A análise de negócios envolve um
conjunto de habilidades bem definidas e conhecimentos amplos que combinam
assuntos de negócios tradicionais a assuntos técnicos.
O capítulo também apresenta o Guia BABOK (Business Analysis Body of
Knowledge), que descreve as áreas de conhecimento que correspondem às
habilidades e funções de um analista de negócios. O objetivo de se ter um corpo
de conhecimento bem definido é estabelecer um padrão para a indústria que
possa delinear as tarefas da análise de negócios.
Por fim, o segundo item deste capítulo apresenta definições de processos,
seguindo da importância da modelagem de processos de negócio e suas
definições.
2.1 Análise de negócio
Antes de fazer a modelagem dos processos de negócio, é necessário
entender como a organização funciona e atinge suas metas. Não é possível fazer
a modelagem ou até mesmo implementar uma solução sem este conhecimento,
sem a Análise de Negócio. Em outras palavras, antes de uma solução de negócio
ser implementada, é preciso saber o que a solução deve fazer para os usuários
que a utilizarão. Um analista de negócio deve assegurar aquilo que os usuários
querem seja cuidadosamente coletado, documentado, analisado e transmitido de
forma inequívoca às pessoas que vão modelar e implementar a solução de fato.
Segundo o Corpo de Conhecimento de Análise de Negócios - Business
Analysis Body of Knowledge, o BABOK
®
2.0 (IIBA, 2009, p. 3), a análise de
negócios é definida como:
“Conjunto de atividades e técnicas utilizadas para servir como ligação
entre partes interessadas no intuído de compreender a estrutura,
22
políticas e operações de uma organização e para recomendar soluções
que permitam que a organização alcance suas metas”.
Os esforços de Análise de Negócios podem ser empregados com o
objetivo de compreender a situação atual de uma organização, conhecida como
“AS IS” (como é), uma base para a posterior identificação da necessidade do
negócio e da solução, que formará a visão “TO BE” (a ser – visão futura).
Entretanto, a principal aplicação da Análise de Negócios é a definição e validação
de soluções que atendam as necessidades do negócio, seus objetivos e metas.
2.1.1 Histórico da análise de negócios
A Análise de Negócios, como outras importantes disciplinas
organizacionais (gerenciamento de projetos, por exemplo), surgiu da prática cada
vez mais comum das suas atividades e técnicas de forma consistente, agrupada
por determinados membros das organizações que passaram a se reconhecer
como praticantes. Um grupo de praticantes, auto denominados analistas de
negócios criou em outubro de 2003 em Toronto, Canadá, o IIBA
®
, International
Institute of Business Analysis, o Instituto Internacional de Análise de Negócios
(IIBA, 2010). O IIBA
®
destina-se a apoiar a emergente comunidade de Análise de
Negócios através de iniciativas como a criação e desenvolvimento da consciência
e reconhecimento do valor e da contribuição do Analista de Negócios, a definição
do Corpo de Conhecimento de Análise de Negócios (BABOK
®
) e o
reconhecimento público através de um programa de certificação com
reconhecimento internacional.
O comitê responsável pela definição do Corpo de Conhecimento de Análise
de Negócios (Business Analysis Body of Knowledge), conhecido como Guia
BABOK
®
, foi formado em 2004 e definiu e esboçou o padrão global para a prática
da Análise de Negócios que teve a sua primeira versão lançada em 2005, e
atualmente está na versão 2.0, lançada em 2009 (IIBA, 2010).
Segundo o Instituto Internacional de Análise de Negócios (IIBA, 2010), o
Guia BABOK
®
descreve as práticas geralmente aceitas no campo da Análise de
Negócios, e seu conteúdo, também baseado em uma extensa revisão
23
bibliográfica, feitas por praticantes, pesquisas junto à comunidade de Análise de
Negócios e consultas feitas a renomados especialistas. As tarefas e técnicas
descritas são utilizadas pela maioria dos praticantes de Análise de Negócios e
podem ser aplicadas na maioria dos contextos onde ela é executada, na maior
parte das vezes. Como qualquer outro conjunto de práticas, o conteúdo do Guia
BABOK
®
deve ser adaptado para condições específicas e não ser interpretado
como uma imposição a respeito de como devem ser desempenhadas as
atividades.
O IIBA tem como uma de suas metas tornar-se autoridade internacional em
análise de negócios. Para isso este instituto desenvolveu um exame de
certificação que pretende aumentar a visibilidade profissional do analista de
negócios de forma substancial nos ranks de trabalhadores profissionais. O exame
baseia-se no Guia BABOK
®
, que descreve o papel e as responsabilidades de um
analista de negócios típico. Os candidatos que são aprovados no exame tornam-
se Profissionais Certificados em Análise de Negócios (Certified Business Analysis
Professionals, CBAP
®
).
2.1.2 Principais conceitos
O Guia BABOK
®
(IIBA, 2009) define alguns conceitos chaves para a análise
de negócio. Estes conceitos são descritos nos próximos itens.
2.1.1.1 Domínios
Na análise de negócios, um domínio corresponde à área específica da
análise sendo realizada. Esta área pode corresponder a uma organização inteira,
uma unidade organizacional, clientes, fornecedores ou mesmo a interação entre a
organização e esses públicos.
2.1.1.2 Soluções
Para que a organização atenda uma necessidade do negócio, se beneficie
de uma oportunidade ou resolva um problema é necessário um conjunto de
24
mudanças em relação à sua situação atual (modelagem do estado atual “as is” e
modelagem do estado futuro “to be”, descritas nos itens 2.3.1 e 2.3.2 deste
capítulo). Este conjunto de mudanças é chamado de solução.
Cada solução é formada por diferentes componentes de soluções. Cada
componente é um método de criação de uma capacidade requerida para que a
solução tenha efeito. Alguns exemplos de componentes de solução são
processos de negócio remodelados, estrutura organizacional revisada, regras de
negócio, terceirização, aplicações de software/sistemas de informação,
redefinição de cargos, políticas comerciais e desenvolvimento de web sites.
No que tange às soluções, cabe à análise de negócios o auxílio para que a
organização defina a solução ideal para as suas demandas. A solução ideal não
consiste naquela que promete os melhores resultados, mas sim, daquela que
além de atender as demandas, leva em conta todas as limitações (tempo,
orçamento, regulamentos entre outros) sob as quais a organização opera.
2.1.1.3 Requisitos
Segundo o Guia BABOK
®
(IIBA, 2009, p.4), um requisito é:
“1. Uma condição ou capacidade necessária para uma parte interessada
para resolver um problema ou atingir um objetivo;
2. Uma condição ou capacidade que deve ser alcançada ou possuída
por uma solução ou componente de solução para satisfazer um contrato,
padrão, especificação ou outros documentos formalmente impostos;
3. Uma representação documentada de uma condição ou capacidade
como em (1) ou (2)”.
Para efeitos de estudo da análise de negócios, o termo “requisito” é
utilizado no seu sentido mais amplo, ou seja, requisitos incluem, mas não estão
limitados a, condições ou capacidades futuras ou passadas em um
empreendimento e descrições de estruturas organizacionais, papéis, processos,
políticas, regras e sistemas de informações. Um requisito pode descobrir o estado
presente ou futuro de qualquer aspecto do empreendimento (IIBA, 2009).
Segundo o autor Karl E. Wiegers (WIEGERS, 2000) o termo requisito
aponta que diferentes tipos de informações aparecem em diferentes níveis do
projeto, saídos de diferentes pontos de vista e níveis organizacionais. Para o
25
autor, um projeto deve endereçar três níveis de requisitos: requisitos de negócio
(os quais são de interesse para o tema da presente dissertação), requisitos de
usuário e requisitos funcionais. Junto a esses requisitos, o analista também deve
contemplar vários tipos de requisitos não funcionais e outras informações, tais
como regras de negócio, atributos de qualidade, requisitos de interface externa, e
restrições de projeto e implementação (WIEGERS, 2006). Destes requisitos,
serão apresentadas a seguir apenas as definições pertinentes ao tema deste
trabalho.
Seguindo as definições de (WIEGERS, 2006), no primeiro nível estão os
requisitos de negócio, que consistem em metas de nível mais alto, objetivos ou
necessidades da organização. Esses requisitos descrevem a razão de ser da
iniciativa em análise (ou em curso), seus objetivos e as métricas que serão
utilizadas para medir o seu sucesso. Os requisitos de negócio alinham a iniciativa
à estratégia corporativa e não às necessidades específicas de partes
interessadas dentro dela. Seguindo o BABOK, os requisitos de negócio são
desenvolvidos dentro da área de conhecimento Análise Corporativa (IIBA, 2009).
No segundo nível estão os requisitos de usuário que consistem nas
necessidades específicas de todas as partes que possuem interesses em relação
à iniciativa. Os requisitos de usuário criam um vínculo entre os requisitos de
negócio e os requisitos da solução. No guia BABOK, os requisitos de usuário são
definidos na área de conhecimento Análise de Requisitos (IIBA, 2009).
Por fim, no terceiro nível definido pelo autor (WIEGERS, 2006), estão os
requisitos funcionais, que juntamente com os requisitos não funcionais, dentro do
BABOK (IIBA, 2009) são chamados de requisitos da solução. Estes requisitos
indicam quais são as características que ela deve possuir para atender aos
requisitos de negócio e os requisitos dos usuários. Os requisitos da solução
desenvolvidos ao longo do desempenho da área de conhecimento Análise de
Requisitos e podem ser divididos em dois grupos: requisitos funcionais e
requisitos não funcionais. O primeiro grupo, que se refere aos requisitos
funcionais, descrevem o funcionamento da solução, seu comportamento e as
informações que ela irá gerenciar. O segundo grupo contém os requisitos não
funcionais, conhecidos como requisitos de qualidade ou suplementares, como
26
eficiência, velocidade, disponibilidade, aparência e as condições do ambiente sob
as quais a solução irá operar.
Outro conceito definido por (WIEGERS, 2006) dentro da classificação de
requisitos e importante para a análise de negócio, são as regras de negócio, ou
Business Rules. Regras de negócio incluem políticas da corporação,
regulamentações governamentais, padrões industriais (como práticas contábeis),
e algoritmos computacionais. As regras de negócio existem tipicamente fora das
fronteiras de qualquer sistema de software e, portanto devem ser consideradas
como parte do nível organizacional (da análise de negócios). Entretanto, estas
regras geralmente requerem que funcionalidades específicas sejam
implementadas para assegurar que o sistema seja compatível com estas regras.
Regras de negócio devem restringir quem pode executar determinados
casos de uso, e elas podem influenciar atributos de qualidade, como segurança,
por exemplo. Algumas regras de negócio devem ser usadas para controlar o
processamento interno do sistema baseado em combinações específicas de
valores de dados, estados do sistema, condições, ou outros critérios definidos
pelo usuário.
2.1.1.4 Partes interessadas
Uma parte interessada é uma classe de pessoas afetadas pela iniciativa de
forma direta ou indireta. As partes interessadas representam pessoas com as
quais o analista de negócios irá provavelmente interagir de alguma maneira.
Classes comuns de partes interessadas envolvem o próprio analista de negócios,
os clientes, o especialista no domínio do negócio, o usuário final da solução, o
especialista na implementação da solução, o desenvolvedor ou engenheiro de
software, profissionais de gerenciamento da mudança organizacional, arquitetos
de sistemas, instrutores, profissionais de usabilidade, gerentes de projetos,
testadores, agências reguladoras, o patrocinador da iniciativa e fornecedores.
27
2.1.1.5 Tarefas
Uma tarefa é uma parte essencial do trabalho que deve ser desenvolvido
na análise de negócio. Tarefas podem ser desenvolvidas formalmente ou
informalmente. Uma tarefa deve seguir as seguintes características: a) uma tarefa
executa um resultado em uma saída que cria valor – ou seja, quando uma tarefa é
executada alguma coisa útil foi feita; b) uma tarefa é completa – tarefas que
fazem uso de saídas devem ser capazes de ser desenvolvidas por pessoas
diferentes; e, c) uma tarefa é necessariamente parte do propósito da área de
conhecimento a qual ela pertence.
2.1.1.6 Técnicas
Técnicas descrevem como as tarefas são executadas sob circunstâncias
específicas. Uma tarefa pode ter nenhuma, uma ou mais técnicas relacionadas.
Uma técnica deve ser relacionada com no mínimo uma tarefa.
As técnicas descritas no BABOK são direcionadas para cobrir os mais
comuns e extensos usos na comunidade de análise de negócio. É esperado dos
analistas de negócio que eles apliquem suas experiências e melhores
julgamentos na determinação de quais técnicas são apropriadas para uma dada
situação, e isto pode incluir técnicas que não descritas ou mencionadas no
BABOK. As técnicas serão adicionadas, modificadas ou removidas.
2.1.3 Áreas de conhecimento
Conforme o BABOK define, as áreas de conhecimento KAs (Knowledge
Areas) da análise de negócios agrupam tarefas e técnicas com um objetivo em
comum (IIBA, 2009), contudo, elas não indicam uma ordem de execução, como
fases em um projeto. Por exemplo, é comum iniciar um esforço de análise de
negócios pela tarefa “Definir a Necessidade do Negócio”, pertencente à área de
conhecimento Análise Corporativa, ou “Avaliar o Desempenho da Solução”, da
área de conhecimento Definição e Validação da Solução.
28
Apesar das áreas de conhecimento não representarem obrigatoriamente,
como dito, fases de um projeto, é possível partir das atividades de Análise
Corporativa para as atividades de Análise de Requisitos e então para a Definição
e Validação da Solução tratando cada uma como uma fase distinta de um projeto,
contudo, essa seqüência não deve ser imposta como uma metodologia para a
execução da análise de negócios. O BABOK define sete áreas de conhecimento,
mostradas na Figura 2. Cada área de conhecimento é descrita nos próximos
itens.
Fonte: adaptado de SCHEDLBAUER (2010)
FIGURA 2 – Áreas de conhecimento do BABOK
2.1.3.1 Planejamento e monitoramento da análise de negócios
As tarefas presentes nesta área de conhecimento governam a execução
das demais tarefas da análise de negócios. Elas cobrem como são determinadas
quais atividades serão necessárias para que o esforço de análise de negócios
seja completado com sucesso. Isso envolve a identificação das partes
interessadas, o processo utilizado para o gerenciamento dos requisitos, as
técnicas a serem utilizadas e como o sucesso do esforço será avaliado. As
principais tarefas desta área de conhecimento são:
• Identificação das partes interessadas;
29
• Definição dos papéis e responsabilidades das partes interessadas dentro
do esforço de análise de negócios;
• Desenvolvimento de estimativas para as tarefas de análise de negócios;
• Planejamento da forma de comunicação entre o analista de negócios e
as partes interessadas;
• Planejamento de como os requisitos serão abordados, traçados e
priorizados;
• Determinação das soluções que a análise de negócios irá produzir;
• Definição e determinação dos processos de análise de negócios;
• Determinação das métricas que serão utilizadas para monitorar o
trabalho de análise de negócios;
2.1.3.2 Análise Corporativa
A Análise Corporativa, ou Enterprise Analysis, segundo o BABOK (IIBA,
2009) é uma coleção de atividades pré-projeto que servem para capturar uma
visão futura do negócio, formando assim uma base a “elicitação” de requisitos e
para a modelagem da solução.
Freqüentemente a análise corporativa é o ponto de partida para uma
iniciativa, já que suas atividades envolvem a identificação da necessidade do
negócio (razão de ser fundamental da iniciativa em análise), problema ou
oportunidade, define a natureza de uma solução que atenda a essa necessidade
e trabalha para justificar o investimento necessário para a entrega dessa solução.
Os resultados deste trabalho provêm contextualização para a Análise de
Requisitos e identificação da solução para uma data inicial ou planejamento de
longo prazo, pois descreve as atividades de Análise de Negócios que são
empregadas para:
• Compreender completamente os problemas e oportunidades do negócio
através da análise da situação do negócio;
30
• Compreender a mudança necessária para atender às necessidades do
negócio e atingir as metas estratégias através da avaliação das
capacidades da organização;
• Desenvolvimento do plano de negócios e da solução proposta a partir da
definição do escopo da solução;
• Definir e documentar os requisitos do negócio (incluindo a necessidade
do negócio, capacidades requeridas, escopo da solução e plano de
negócios).
As tarefas da Análise Corporativa são:
• Definir a necessidade do negócio: identificar porque uma mudança nas
capacidades ou sistemas organizacionais é necessária (a razão de ser
da iniciativa). Trata-se da definição do problema para o qual o analista
está tentando encontrar a solução. A definição da necessidade do
negócio orienta quais soluções serão consideradas, quais partes
interessadas serão consultadas e quais abordagens de solução serão
aceitas;
• Avaliar lapsos de capacidade: identificação de quais são as capacidades
necessárias para a organização atender à necessidade do negócio.
Essas capacidades (estrutura, pessoas, processos e tecnologia) podem
já ser possuídas pela organização, o que faz a mudança tender a ser
pequena, ou não, o que tende a envolver iniciativas mais complexas;
• Determinar a abordagem da solução: a abordagem da solução deve ser
selecionada com base na sua viabilidade para o atendimento da
necessidade do negócio. Ela deve ser definida em um nível de detalhe
suficiente para a definição do escopo da solução e conseqüente
preparação do plano de negócios;
• Definir o escopo da solução: definição de quais são as novas
capacidades que a iniciativa (ou parte de uma iniciativa) deverá entregar;
• Definir o plano de negócios: determinação de se o investimento
necessário para a entrega da solução é justificado. Esta justificativa se
31
baseia no valor a ser adicionado ao negócio como resultado da solução
implantada em comparação com o custo de desenvolvimento desta
solução.
2.1.3.3 “Elicitação”
A “elicitação”
2
(em inglês, “Elicitation”) descreve o trabalho dos analistas de
negócios no intuito de compreender as necessidades e preocupações das partes
interessadas e os ambientes no qual elas trabalham ou operam.
A grande diferença entre o termo “elicitar” requisitos e o termo mais comum
“levantar” é o foco na extração das necessidades verdadeiras, que costumam
muitas vezes estar explícitas, não se satisfazendo com a simples expressões de
desejos superficiais.
A “elicitação” dos requisitos não costuma ocorrer de forma isolada ou em
compartimentos. Requisitos costumam aparecer de forma cíclica durante sessões
tanto de levantamento quando de validação. A “elicitação” costuma envolver uma
combinação de técnicas para que a definição dos requisitos seja executada de
forma completa. A definição de quais técnicas serão utilizadas depende de
diferentes fatores, como o domínio do negócio, a cultura e o ambiente do negócio,
as habilidades do analista e quais tipos de entregáveis de requisitos devem ser
criados. As técnicas de “elicitação” geralmente aceitas são: brainstorming, análise
documental, grupos focais, análise de interfaces, entrevistas, observação,
prototipagem, workshops de requisitos e pesquisa/questionários.
As tarefas desta área de conhecimento envolvem a preparação, condução,
documentação e confirmação dos resultados da “elicitação”. Em um projeto, a
coleta de requisitos nunca pára. As partes interessadas devem participar do
projeto durante todo seu tempo de vida para assegurar que os itens a serem
entregues satisfaçam os objetivos com o mínimo de "problemas".
2
Como a palavra “elicitação” não existe no vocabulário português, a mesma será descrita entre aspas.
32
2.1.3.4 Análise de requisitos
Após a “elicitação” dos requisitos de um projeto a partir das partes
interessadas, o analista de negócios deve iniciar o processo de formatação dos
requisitos para que os desenvolvedores de soluções criem, no final, a "melhor
solução possível”.
A Análise de Requisitos descreve a priorização e elaboração progressiva
dos requisitos das partes interessadas e da solução para permitir que a equipe da
iniciativa ou projeto implemente a solução que deverá atender à necessidade do
negócio. Ao analisar um conjunto de requisitos, o analista de negócios deve
compreender as necessidades "verdadeiras" das partes interessadas e modelar
uma solução adequadamente.
Esta área de conhecimento também envolve a elaboração de modelos do
estado atual da organização utilizados para a validação do escopo da solução. As
tarefas da Análise de Requisitos são:
• Priorizar requisitos: a priorização garante que os esforços são aplicados
primeiro sobre os requisitos mais críticos;
• Organizar requisitos: criação de um conjunto de visões dos requisitos
que sejam compreensíveis, completas e consistentes para as partes
interessadas em suas diferentes perspectivas;
• Especificar e modelar requisitos: utilizar um conjunto de declarações em
texto, matrizes, diagramas e modelos formais para analisar os desejos
expressados pelas partes interessadas e/ou o estado atual da
organização. Esta tarefa envolve negociação;
• Definir pressupostos e restrições: identificação de fatores além dos
requisitos que afetam a viabilidade das soluções;
• Verificar requisitos: garantia de que as especificações e modelos
atendem ao padrão necessário de qualidade para que possam ser
utilizados;
33
• Validar requisitos: garantia de que todos os requisitos apóiam a entrega
de valor para o negócio, que eles atendam às suas metas e objetivos e
às necessidades das partes interessadas,
2.1.3.5 Definição e validação da solução
A Definição e Validação da Solução se destina a determinação de qual
solução se encaixa melhor à necessidade do negócio, a identificação de lapsos
de capacidades ou falhas em soluções e a determinação de contornos ou
mudanças necessárias.
O analista de negócios deve também avaliar o quão bem uma solução
entregue atende à necessidade original para qual foi desenvolvida, permitindo que
a organização julgue o seu desempenho e eficácia. Isso envolve a avaliação e
validação de componentes de soluções como processos de negócio, estruturas
organizacionais, acordos de terceirização, aplicações de software entre outros.
Por conhecer o ambiente do negócio, o analista de negócios pode avaliar os
impactos de cada solução proposta sobre o ambiente.
Estas atividades possuem como objetivo principal a maximização do valor
entregue para as partes interessadas. As tarefas da Definição e Validação da
Solução são:
• Avaliar solução proposta: avaliação das soluções propostas para a
determinação do quão bem elas atendem aos requisitos das partes
interessadas e da solução;
• Avaliar a prontidão organizacional: avaliar se a organização está
preparada para o uso efetivo de uma nova solução a partir da
compreensão dos seus efeitos;
• Definir requisitos de transição: definição das capacidades necessárias
para a transição entre a solução existente e a nova solução;
• Validar a solução: validar que a solução atende à necessidade do
negócio e respostas apropriadas para eventuais defeitos identificados;
34
• Avaliar desempenho da solução: avaliação de soluções em
funcionamento para a compreensão do valor que elas entregam em
busca de oportunidades de melhoria.
2.1.3.6 Gerenciamento e comunicação dos requisitos
Conflitos, incidentes e mudanças são inerentes ao processo de definição
dos requisitos. O analista de negócios deve saber gerenciar essas situações para
garantir que as partes interessadas e a equipe da iniciativa ou projeto
permaneçam em acordo a respeito do escopo da solução. Esta área de
conhecimento também abrange a definição de como os requisitos são
comunicados às partes interessadas e como o conhecimento obtido pelo analista
de negócios é mantido para utilização futura.
O objetivo do gerenciamento e comunicação dos requisitos é estender a
todos a compreensão dos efeitos das mudanças trazidas pela solução e as
ligações entre a solução e os objetivos e metas do negócio.
A comunicação é fator ao mesmo tempo crítico e difícil para o sucesso de
qualquer iniciativa, uma vez que as partes interessadas representam pessoas de
diversas origens e áreas profissionais. As tarefas desta área de conhecimento
são:
• Gerenciar o escopo e os requisitos da solução: manutenção do
consenso entre as partes interessadas quanto ao escopo genérico da
solução e os requisitos que serão implementados;
• Manter requisitos para reuso: gerenciamento do conhecimento sobre os
requisitos para uso futuro;
• Preparar o pacote de requisitos: estruturação de um conjunto de
requisitos de forma apropriada para que sejam comunicados, entendidos
pelas partes interessadas;
• Comunicar requisitos: conversas, anotações, documentos,
apresentações e discussões fazem parte desta questão fundamental
35
para levar as partes interessadas a uma compreensão comum dos
requisitos.
2.1.3.7 Competências de apoio
Comportamentos, conhecimentos e outras características que apóiam o
desempenho efetivo da Análise de Negócios são abordados nesta área de
conhecimento. As competências de apoio são:
• Pensamento analítico e solução de problemas: pensamento criativo,
tomada de decisão, aprendizado, resolução de problemas e pensamento
sistêmico;
• Características de comportamento: ética, organização pessoal e
confiabilidade;
• Conhecimento de negócios: princípios e práticas de negócios,
conhecimento da indústria, conhecimento da organização, conhecimento
da solução;
• Habilidades de comunicação: comunicações verbais, ensino,
comunicações escritas;
• Habilidades de interação: facilitação e negociação, liderança e influência,
trabalho em equipe;
• Aplicações de software: aplicações de propósito geral, aplicações
especializadas.
2.2 Processos
2.2.1 A importância dos processos nas organizações
Como já apresentado no Capítulo 1 dessa dissertação, as organizações
estão cada vez mais preocupadas e empenhadas na troca de paradigma da
engenharia de sistemas orientada à tecnologia para estruturas orientadas ao
modelo dos processos de negócio. Em meio ao crescimento da complexidade e
dinâmica do ambiente de atuação das organizações, os esforços para lidar com o
36
desafio de sustentação e/ou alcance de competitividade apresentam-se como
elemento chave.
Uma das ferramentas que alavancou o processo de mudanças das
organizações foi a Tecnologia da Informação (TI), que teve ao longo das últimas
décadas uma grande evolução intrínseca em seu desenvolvimento e
aprimoramento. Ao mesmo tempo, segundo Davenport (1994), nos fins dos anos
70 e início dos anos 80 do século XX, a TI foi colocada como uma fonte de
mudanças drásticas e de melhoria empresarial, proporcionando uma vantagem
competitiva das organizações, envolvendo ao mesmo tempo uma série de
alterações intrínsecas aos processos, mesmo que inconscientemente.
Os sistemas de informação são uma parte crítica da infra-estrutura da
maioria das organizações. Para ser útil, um sistema de informação deve estar
integrado e alinhado com a maneira que o negócio conduz suas operações. Ou
seja, isso significa que a construção de tais sistemas requer um entendimento dos
procedimentos, operações e processos da organização. Articular, modelar e
gerenciar processos de negócio são pré-condições para o sucesso da automação
(SCHEDLBAUER, 2010).
Ainda segundo o mesmo autor (SCHEDLBAUER, 2010), processos de
negócio representam um componente crítico intelectual que necessita ser
entendido. Processos geralmente são multifuncionais e envolvem múltiplos
sistemas, aplicações de software e incluem componentes humanos (empregados,
clientes, parceiros e vendedores). Processos devem ser formalmente definidos e
documentados para que eles então possam ser praticados uniformemente e
conscientemente por uma organização.
Nesse sentido, a análise dos processos de negócio da organização tem
uma fundamental importância para a sua efetiva reestruturação (reengenharia,
descrita na Introdução). Uma empresa – ao levantar e modelar seus processos –
evidencia os seus problemas, facilita a reestruturação organizacional e a
concepção e implantação de uma arquitetura integrada de sistemas. Deste modo,
uma organização que conhece os seus processos tem maior potencial de
resultados na integração entre suas áreas (GONÇALVES, 2000).
37
Todo trabalho importante realizado nas empresas faz parte de algum
processo (GONÇALVES, 2000). Não existe um produto ou um serviço oferecido
por uma empresa sem um processo de negócio. Da mesma forma, não faz
sentido existir um processo de negócio que não ofereça um produto ou um
serviço.
Hammer (2001) destaca quatro características de um bom processo: (i) O
processo deve trazer resultados ao invés do próprio trabalho. Todos dentro da
empresa devem entender o porquê e a melhor forma de fazer o trabalho.
Treinamento e avaliação de desempenho reforçam a orientação para os
resultados dos processos. (ii) Os processos devem estar focados nos clientes. É
preciso avaliar os processos em si e analisá-los dentro da visão dos
consumidores. (iii) Os processos são holísticos. Os processos devem transcender
as atividades individuais. Isso significa entender como as atividades podem
trabalhar juntas para produzir o melhor resultado. O valor superior para os
consumidores é atingido quando os departamentos e colaboradores trabalham
juntos para um propósito unificado. (iv) Finalmente, um processo inteligente está
baseado na convicção que o sucesso do negócio depende de modelos dinâmicos
bem desenhados de trabalho.
Hammer (2001) ainda ressalta que a criação de um processo estruturado
faz com que as empresas se tornem menos dependentes de pequenos grupos de
pessoas talentosas, que acabam se tornando indispensáveis. As empresas que
são dependentes de “heróis” podem se ver em apuros quando, repentinamente,
eles partem. Entretanto, se o processo permanece na empresa, pessoas podem
sair e outras podem usar o processo que foi desenvolvido. Smith e Fingar (2003)
citam o grande valor dos processos nas empresas: “As empresas tratam
processos com cuidado porque eles constituem propriedade intelectual.
Processos são o negocio”.
2.2.2 Processos de negócio
Uma vez definida a importância dos processos nas organizações, é
necessário especializar o conceito de processos para a área de negócios.
38
Segundo White e Miers (2008) existem um grande número de definições de
Processos de Negócio. Dentro de uma organização, existem muitos tipos de
processos tanto em termos de objetivos e como eles são desenvolvidos. A
maioria dos processos requer algum tipo de entrada (ou eletrônica ou física), usa
e/ou consome recursos, e produz algum tipo de saída (ou eletrônica ou física). A
maioria das organizações executam centenas de processos diferentes para
fornecer resultados para clientes, equipe da organização ou para satisfazer
regulamentações.
Alguns processos são formais, repetíveis, bem estruturados, e muitos até
mesmo automatizados. White e Miers (2008) chamam esses processos de
“procedimento”, como por exemplo, transações bancárias. Outros processos são
informais, muitos flexíveis, não previsíveis e difíceis de definir ou repetir. Os
autores referem-se a esses processos como “práticas”, onde citam como
exemplos a escrita de um manual de usuário, desenvolvimento de estratégias de
venda ou preparação de uma agenda de conferência.
Uma das definições de processos de negócio apresentada por White e
Miers (2008, p. 27) é: “um processo de negócio ou método de negócio é uma
coleção de tarefas inter-relacionadas, as quais atingem uma meta específica”. A
seguir, são apresentadas algumas definições de outros autores.
Um processo de negócio é um conjunto de atividades lógicas, relacionadas
e seqüenciais que, a partir de uma entrada de um fornecedor, agrega-lhe valor e
produz uma saída para um cliente (HARRINGTON, 1997).
Davenport (1994) define processos de negócio como uma ordenação
específica das atividades de trabalho no tempo, com um começo, um fim e
entradas e saídas claramente identificadas: uma estrutura após a ação.
É importante ressaltar que um processo de negócio tem que ser dinâmico.
Sua definição é essencialmente dinâmica, mudando com o tempo. Novos
componentes vão sendo adicionados e outros são adaptados à medida que o
ambiente muda, a empresa cresce e o conhecimento especializado se
desenvolve. O funcionamento do processo precisa, então, ser adaptado, de modo
que possa se adequar à nova situação (GONÇALVES, 2000).
39
2.3 Modelagem de Processos de Negócio
Segundo os autores Booch, Rumbaugh e Jacobson (2005), uma empresa
de software bem sucedida é aquela que desenvolve seu produto capaz de
satisfazer às necessidades de seus usuários e respectivos negócios. Para estes
autores, um modelo é uma simplificação da realidade e a modelagem é uma parte
central de todas as atividades que levam à implantação de um bom software.
Modelos são construídos para comunicar a estrutura e comportamento desejados
do sistema, controlar sua arquitetura, gerenciar riscos, expor oportunidades de
simplificação e reaproveitamento, e principalmente, para compreender melhor o
sistema que está sendo construído, objetivo este que justifica a modelagem de
processos de negócio, tema central desta dissertação.
Especializando este conceito para negócio, Eriksson e Penker (2000)
definem que um modelo de negócio é uma abstração do funcionamento do
próprio negócio. Tal modelo é composto por: objetivos, recursos, processos e
regras, conforme ilustrado na Figura 3.
• Objetivos: são os propósitos do negócio, ou simplesmente, o resultado
que toda a organização deseja atingir. O autor Schedlbauer (2010) estes
resultados podem ser um produto ou um serviço, mas todo processo
deve ter um resultado;
• Recursos: constituem os objetos utilizados em um negócio, tais como
pessoas, materiais, informações (dados), e sistemas. Segundo
Schedlbauer (2010) os recursos são consumidos, produzidos ou
transformados por um processo;
• Processos: como já definido na seção anterior, os processos constituem
um conjunto de atividades estruturadas para que um produto (bem ou
serviço) seja gerado. Ainda, segundo White e Miers (2008), um processo
em BPMN é o que uma organização faz – seu trabalho – a fim de
alcançar um propósito ou objetivo específico;
• Regras: são declarações que restringem, derivam e fornecem condições
de existência nas atividades dentro de um processo, representado o
conhecimento do negócio, ou seja, as regras definem como o negócio
deve operar.
40
Fonte: Eriksson e Penker (2000)
FIGURA 3 – Os objetos que compõem um negócio
Ainda existem outros elementos considerados essenciais para um modelo
de negócio, como eventos e atividades, por exemplo, que serão definidos
posteriormente no Capítulo3. Outro elemento na opinião da autora desta
dissertação que afeta o negócio e deve ser levado em consideração é o cliente,
pois como definido anteriormente, todo processo resulta em um produto ou
serviço que é recebido por um cliente. Pode-se dizer então que o negócio
depende do cliente.
Schedlbauer (2010, pg. 5) resume esses conceitos na seguinte frase:
“processos descrevem como os recursos são usados e transformados para
alcançar um conjunto de resultados dentro das restrições das regras aplicáveis”.
Seguindo a explicação de (KALPIC e BERNUS, 2002), modelos de
processos de negócio descrevem como um negócio trabalha, ou mais
especificamente, como ele cumpre objetivos, realiza atividades e tarefas. Para
detalhar o “como” da maioria das empresas reais, é necessário uma serie de
modelos, já que um simples processo pode consistir em vários atores (pessoas,
organizações, sistemas
3
) executando várias tarefas, que por sua vez, para serem
cumpridas, esses atores devem completar outras tarefas (sub-tarefas)
3
Conforme a definição de Eriksson e Penker (2000) citada acima, os atores são os recursos.
41
especificadas de maneira coordenada. Em alguns casos, estas sub-tarefas
podem ser executadas em paralelo, outras vezes são seqüenciais. Alguns
processos requerem repetição de sub-tarefas. A maioria dos processos tem
pontos de decisão onde fluxos de processo podem ser ramificados, dependendo
da condição do sistema ou de uma condição específica da execução da tarefa em
questão.
Em processos organizacionais, os atores devem passar informação para
outros atores. Essa transferência de informação pode disparar uma ação para
outro ator realizar. Também existem situações onde o ator pode não precisar
completar toda uma sub-tarefa antes que ele mesmo ou outro ator inicie outra
sub-tarefa dependente. Outros gatilhos também são possíveis, como o tempo ou
interrupções. Alguns processos também podem ser ad-hoc, ou seja, as sub-
tarefas não tem gatilhos bem definidos, acontecem de forma não programada ou
semi-programada.
A criação de um modelo de processo de negócio pode ser instrutivo por si
só, revelando anomalias, inconsistências, ineficiências e oportunidades para
melhoria. Uma vez criado, especialmente se de forma informatizada, é um valioso
meio de compartilhar o conhecimento através da empresa. O modelo também
pode ser usado para formular e avaliar mudanças, como por exemplo, o
lançamento de um novo produto e processos de negócio associados
(KOUBARIAKIS e PLEXOUSAKIS, 2000).
Uma metodologia de modelagem de processos de negócio deve ser capaz
de representar estes diferentes aspectos da descrição de um processo, ainda que
um processo possa parecer diferente quando descrito a partir da perspectiva de
diferentes atores. Um bom modelo deve apresentar uma representação de uma
maneira que seja fácil de ser transferida para o conhecimento tácito para quem
estiver visualizando o modelo.
A importância de usar uma notação padrão para modelagem de processos
de negócio pode prover para as organizações a capacidade de entender seus
procedimentos internos de negócio de forma gráfica, possibilitando que às
mesmas a habilidade de comunicar estes procedimentos de modo padrão. Além
disso, a notação gráfica facilita o entendimento das colaborações e as transações
42
de negócio entre organizações, permitindo que empresas e participantes se
entendam rapidamente (BPMN, 2007).
Antes de serem apresentadas algumas considerações sobre as
ferramentas de modelagem de processos e introduzir as notações adotadas neste
trabalho, ainda deve ser feita mais uma consideração sobre os modelos de
processos de negócio. Estes modelos representam ou o estado atual (“as is”) ou o
estado futuro (“to be”) dos processos de negócio. Modelos devem ser criados de
uma perspectiva particular e não devem ser misturados estes estados (atual e
futuro). (SCHEDLBAUER, 2010).
2.3.1 Modelagem do estado atual (As Is)
Entende-se por modelagem uma atividade de construção de modelos.
Conforme já citado anteriormente, um modelo é uma representação abstrata da
realidade, com maior ou menor grau de formalidade. Assim sendo, não existe um
modelo perfeito, único ou indiscutível para a representação de um processo
(BALDAM et al., 2007). Como resultado da modelagem do estado atual, espera-
se obter (JESTON e NELIS, 2006):
• O modelo do processo atualmente em uso;
• Métricas apropriadas e suficientes para estabelecer uma base para
futuras medidas de melhorias de processos;
• Métricas e documentação do atual desempenho do processo;
• Documentação do que está funcionando bem e do que precisa melhorar;
• Identificação dos itens mais significativos e de rápido retorno, que
podem ser facilmente implementados;
• Um relatório da fase, com custo por atividade, tempo, competências,
relações, agentes, itens de controle, normas, leis, conceitos, desvios,
etc. (LIN, YANG e PAI, 2002).
43
2.3.2 Modelagem do estado futuro (To Be)
A modelagem do estado futuro pretende, inicialmente através de
discussões entre as partes envolvidas, encontrar uma forma de melhorar um dado
processo, inová-lo ou até mesmo questionar se ele se faz necessário e se de fato
agrega valor à organização. Dentre os diversos resultados esperados da
modelagem de estado futuro, deve-se incluir os seguintes (JESTON e NELIS,
2006):
• Redesenho do processo ou ainda um novo processo;
• Documentação de suporte ao processo redesenhado ou criado;
• Requisitos de alto nível para as novas opções observadas;
• Modelos de simulação;
• Confirmação das expectativas dos envolvidos em relação às mudanças;
• Confirmação do alinhamento com a estratégia;
• Relatório das diferenças que precisam ser atendidas para o
cumprimento dos requisitos;
• Plano de desenvolvimento e treinamento da equipe;
• Relatório de impactos na organização;
• Detalhes do plano de comunicação sobre o novo processo.
2.4 Modelagem versus análise
Segundo o autor Schedlbauer (2010) modelagem de processos é a
representação das atividades essenciais que realizam alguma tarefa enquanto a
análise do processo é a tarefa de analisar um processo específico pelas suas
deficiências, ou seja, gargalos, ineficiências, custos, recursos de consumo, e
assim por diante. Por isso, ter um modelo de processo de negócio o mais correto
e completo quanto for possível é um pré-requisito para uma análise de processo
de negócio significativa.
Nesta dissertação, o foco está na modelagem de processo, isto é,
documentar os processos, porém, para fazer isso, foi necessário expor conceitos
de análise para entender como os processos são capturados e entendidos, para
então, serem modelados.
44
2.5 Notações para modelagem de processos de negócio
O BABOK não prescreve uma notação específica para modelar processos,
entretanto uma notação padrão é necessária. Muitas metodologias foram criadas
para modelar processos. Durante a década passada, segundo Schedlbauer
(2010), a UML foi o padrão adotado pela indústria para representação visual de
análise e projeto de artefatos. Este foi um dos motivos de escolher a modelagem
de negócio com UML para comparar com a notação BPMN neste trabalho.
A notação BPMN surgiu como um padrão alternativo à UML, também
sendo gráfica, porém seus símbolos são um pouco diferentes, pois BPMN foi
criada especificamente para modelar processos de negócio. Esta notação não
oferece, portanto qualquer suporte para modelar dados, atores, estados de ciclo
de vida, ou sistemas. Para esse tipo de modelagem, a UML ainda é a melhor
opção, na opinião da autora desta dissertação. Tanto UML como BPMN são
mantidos pelo OMG. No capítulo 5 será apresentada uma análise comparativa
entre essas duas abordagens, para evidenciar melhor essas diferenças.
Existem ainda muitas outras notações por analistas de negócio como
alternativas à UML e BPMN. O essencial é saber quais informações são
relevantes para a compreensão do processo como um todo (LIN, YANG e PAI,
2002). Neste item, são descritas algumas das linguagens e notações existentes
voltadas para a especificação de modelos, selecionadas por seus potenciais ou
por serem padrões bem estabelecidos de pesquisa ou de mercado (LIST e
KORHERR, 2006).
• UML 2.0 Activity Diagram (AD): O Diagrama de Atividade da UML foi
projetado para modelar processos de negócio e fluxos em sistemas de
software. Sua origem esta embasada no desenvolvimento de software;
• Business Process Definition Metamodel (BPDM): A BPDM foi
desenvolvida pelo Object Management Group (OMG) e oferece um
meta-modelo genérico para processos de negócio. A BPDM não prove
uma notação gráfica própria, sua intenção é apenas definir um meta-
modelo genérico com o objetivo de apoiar o mapeamento entre
diferentes ferramentas e linguagens;
45
• Business Process Modeling Notation (BPMN): A BPMN foi criada
para projetar e modelar processos de negócio e suas transformações na
linguagem de execução, a Process Modeling Language (BPML);
• Event Driven Process Chain (EPC): O EPC foi desenvolvido para
modelar processos de negócio que sejam facilmente entendidos e
utilizados pelo pessoal de negócios. Seus elementos básicos são
funções e eventos;
• Integrated DEFinition Method 3 (IDEF3): IDEF3 foi projetado para
modelar processos de negócio e seqüências de um sistema, provendo
duas perspectivas: o esquema do processo e o esquema de objetos. O
primeiro representa o conhecimento sobre “como as coisas são feitas”
dentro de uma organização, isto é, descreve o que acontece em uma
etapa de processo enquanto ela passa por uma seqüência de um
processo de produção. O segundo resume as condições, ou seja, os
eventos pelas quais um determinado objeto passa em um processo;
• Petri Net: A rede de Petri foi projetada para modelagem, análise e
simulação de sistemas dinâmicos, através de procedimentos
concorrentes e não determinísticos. Redes de Petri são utilizadas para
modelar workflows, através de grafos;
• Role Activity Diagram (RAD): O RAD tem sua origem na modelagem e
coordenação, sendo usado para modelar processos de negócio com
ênfase nos papéis, atividades e interações com eventos externos.
2.6 Ferramentas de modelagem de processos
Todos os processos modelados devem ser armazenados, compartilhados e
atualizados (SCHEDLBAUER, 2010). Na fase de modelagem de processos,
ferramentas de software têm demonstrado um grande valor e vem sendo usadas
para facilitar a modelagem, documentação e integração entre os modelos.
Segundo Baldam et al. (2007), deseja-se que as ferramentas de modelagem
tenham as seguintes características:
• Facilidade de desenho do processo;
• Padrões de simbologia prontos para o uso (exemplo: BPMN);
46
• Correções de fluxo com facilidade;
• Integração com bancos de dados e outros sistemas;
• Possibilidade de agregar informações às atividades (regras, custos,
sistemas, documentos gerados, entre outros);
• Publicação dos modelos e documentação em ambiente colaborativo.
A Tabela 1 a seguir apresenta algumas ferramentas de modelagem e
gerenciamento de processos.
Ferramenta Vendedor BPMN UML Colaboração Simulação
Modelagem
de Dados
Análise
de
Impacto
BusinessManager Savvion Sim Não Sim Sim Não Sim
Enterprise
Architect
Sparx Sim Sim Não Não Sim Não
Visual Architect Visual
Paradigm
Sim Sim Sim Não Sim Sim
ProVision BPM MetaStorm Sim Não Sim Sim Não Sim
Process Modeler BizAgi Sim Não Sim Sim Não Não
Process Maker Colosa Sim Não Não Não Não Não
Fonte: adaptado de Schedlbauer (2010).
TABELA 1 – Ferramentas de modelagem de processos
47
3 A NOTAÇÃO DE MODELAGEM DE PROCESSOS DE NEGÓCIO
– BPMN
3.1 Histórico e objetivos da notação BPMN
Em 2001 BPMI.org (Business Process Management Initiative) iniciou o
desenvolvimento da Linguagem de Modelagem de Processos de Negócio, a
BPML (Business Process Modeling Language), uma linguagem de execução de
processo XML (Extensible Modeling Language) e compreendeu que havia uma
necessidade de uma notação gráfica apenas para a modelagem dos processos
de negócio, sem se preocupar com sua execução (WHITE e MIERS, 2008).
Pessoas envolvidas na época decidiram que uma notação era necessária
para orientar a direção das necessidades de negócio do usuário. Em agosto de
2001 foi criado um grupo composto de 35 companhias de modelagem,
organizações e pessoas as quais entre elas trouxeram uma ampla série de
perspectivas para o problema descrito no parágrafo acima. Este grupo, o
“Notation Working Group” desenvolveu o BPMN dentro do BPMI.org. Nascia a
primeira versão desta notação, BPMN 1.0.
Quando eles iniciaram o desenvolvimento do BPMN existia (e ainda existe)
um grande número de notações de modelagem de processos, distribuídas usando
diferentes ferramentas, e usadas dentro de uma grande variedade de
metodologias.
Em maio de 2004 a especificação do BPMN 1.0 estava pronta para ser
publicada. Em fevereiro de 2006 a especificação do BPMN 1.0 foi adotada como
um padrão da OMG (depois que BPMI.org foi incorporado pela OMG). Em
fevereiro de 2008, a OMG lançou o BPMN 1.1. As mudanças para o BPMN 1.2
não incluíram mudanças gráficas significativas; as modificações significativas
ocorreram em seu editorial, complementando a linguagem de sua especificação.
Atualmente encontra-se disponível no site oficial do BPMN a versão BPMN 2.0
(OMG, 2010).
A notação BPMN foi desenvolvida para ser de fácil utilização e
entendimento, e também fornecer a habilidade de modelar processos de negócios
48
complexos. Esta notação define seus modelos de processos de negócio através
de um diagrama chamado Business Process Diagram (BPD). O BPD é construído
através de um conjunto básico de elementos gráficos. Estes elementos permitem
o desenvolvimento de diagramas que são, normalmente, bastante familiares para
a maioria dos analistas de negócio, pois são bastante parecidos com fluxogramas
(WHITE, 2004a).
Ainda segundo este autor (WHITE, 2004a), um dos desafios da notação
BPMN é a criação de mecanismos simples para a construção de modelos de
processos de negócio, porém com a capacidade de lidar com a complexidade
inerente de processos de negócio. BPMN usa uma abordagem minimalista para
lidar com estes dois requisitos conflitantes (processos simples até os mais
complexos), utilizando um pequeno conjunto de categorias de notação, para que
o leitor de um BPD possa facilmente reconhecer os tipos básicos utilizados e
assim compreender a essência do diagrama.
As quatro categorias básicas dos elementos são: Flow Objects (Objetos de
Fluxo), Conecting Objects (Objetos de Conexão), Swimlanes (Raias) e Artifacts
(Artefatos). A seguir, na Tabela 2 serão vistos os principais elementos de cada
categoria (WHITE, 2004a) que serão detalhados e categorizados nas próximas
seções.
FLOW OBJECTS (OBJETOS DE FLUXO)
Elemento
Descrição
Notação
Evento
Um evento é algo que acontece
durante a execução do processo.
Ele afeta a execução do processo
e, geralmente, possui uma causa
(trigger) e um impacto (result).
Os eventos podem ser de três
tipos, baseado no momento em
que afetam o processo:
Start (Início), Intermediate
(Intermediário) e End (Fim).
Atividade
Atividade é um termo genérico
para um trabalho executado por
uma organização dentro de um
processo de negócio (WHITE e
MIERS, 2008).
Atividades são etapas dos
processos com o objetivo de
49
mostrar como um processo é
executado através do seu fluxo de
trabalho. A representação das
atividades costuma ser vista como
um relacionamento entre os
conceitos do modelo de negócio,
por associar o processo aos
papéis e unidades
organizacionais, objetos de
negócio, objetivos e eventos.
Gateway
Um Gateway é usado para
controlar a divergência ou
convergência de fluxos de
seqüência. Dessa forma, ele irá
determinar ramificação,
bifurcação, ligação e junção de
caminhos. Símbolos internos à
notação gráfica irão indicar o tipo
de controle.
CONNECTING OBJECTS (OBJETOS DE CONEXÃO)
Elemento
Descrição
Notação
Fluxo de
Seqüência
Um fluxo de seqüência é usado
para indicar a ordem em que
atividades serão executadas em
um processo.
Fluxo de
mensagem
Um fluxo de mensagem é usado
para mostrar a troca de
mensagens entre dois
participantes do processo. Em
BPMN, dois Pools separados no
diagrama representam dois
participantes (uma entidade de
negócio ou um papel do
processo, por exemplo).
Associação
Usada para associar informação a
objetos de fluxo. Objetos gráficos
ou textuais, que não são de fluxos
podem ser associados a objetos
de fluxo.
SWINLANES (RAIAS)
Elemento
Descrição
Notação
Pool
Um Pool representa um
participante do processo.
Lane
Lanes criam sub-partições de um
Pool. Lanes são usados para
organizar e categorizar as os
elementos do processo.
50
ARTIFACTS (ARTEFATOS)
Elemento
Descrição
Notação
Objetos de
dados
Objetos de dados são
considerados artefatos porque
eles não têm efeito direto no fluxo
de seqüência ou fluxo de
mensagens do processo, mas
eles provêem informação acerca
do que as atividades precisam
para serem executadas e o que
elas produzem.
Grupo
Um grupo de atividades que não
afeta o fluxo de seqüência. O
agrupamento pode ser realizado
para fins de análise ou
documentação. Grupos também
podem ser usados para identificar
atividades de uma transação
distribuída que é mostrada entre
Pools.
Anotações
de texto
Anotações de texto são
mecanismos utilizados pelos
modeladores para prover
informação adicional aos leitores
do diagrama de processo de
negócio.
Fonte: adaptado de WHITE (2004a).
TABELA 2 – Estereótipos BPMN
3.2 Elementos gráficos
3.2.1 Objetos de Fluxo
Objetos de Fluxo são os principais elementos gráficos para definir o
comportamento de um processo de negócio. A BPMN descreve um conjunto de
três Objetos de Fluxo: eventos, atividades e gateways.
3.2.1.1 Eventos
De acordo com a especificação BPMN (OMG, 2008), os eventos aparecem
ou são gerados durante a execução de um fluxo. Somente os eventos têm a
capacidade de iniciar ou terminar um processo, porém não executam tarefas no
processo. Os eventos ainda podem forçar a execução ou desviar para uma
51
determinada atividade. Representado por círculos, o estilo da borda indica o tipo
de evento, que podem ser: inicial (linha simples fina), intermediário (linha dupla
fina) e evento final (linha simples grossa).
Um processo pode ser iniciado por diferentes circunstâncias. Essas
circunstâncias, tal como a chegada de uma mensagem ou um “temporizador” são
chamadas de triggers (gatilhos). Existem seis tipos de eventos iniciais, cada qual
com sua própria representação gráfica, conforme mostra a Tabela 3.
EVENTOS INICIAIS
Trigger
Descrição
Notação
Nenhum
Um evento inicial indica onde um
processo começará. É usado
onde o início de um processo é
indefinido.
Mensagem
O trigger é uma mensagem que
chega de outra entidade de
negócio ou papel (participante).
Por exemplo, um cliente solicita
uma revisão de sua conta.
Uma mensagem é uma
comunicação direta entre dois
participantes do negócio.
Timer
Uma data específica ou um ciclo
específico (por exemplo, toda
segunda-feira, às 9 horas) pode
ser acionado para iniciar um
processo.
Condição
O trigger é uma expressão
condicional que deve ser
satisfeita para o processo iniciar.
Sinal
Indica que um processo é iniciado
quando um sinal é detectado. Por
exemplo, um processo envia uma
mudança na taxa de juros
corrente, acionando qualquer
número de outros processos para
iniciar como um resultado.
É importante diferenciar sinal de
mensagem, a qual possui um
destino específico.
Processos múltiplos podem ter
eventos de início que são
acionados pelo mesmo sinal
transmitido.
52
Múltiplo
Significa que existem múltiplos
caminhos para iniciar um
processo. Apenas um deles será
requerido para iniciar o processo.
Fonte: adaptado de (WHITE e MIERS, 2008) e (OMG, 2008)
TABELA 3 – Tipos de eventos iniciais em BPMN
Eventos intermediários ocorrem após o processo ter iniciado e antes do
seu término. Diferentes tipos indicam circunstâncias especificas de disparo destes
eventos. Estes eventos são apresentados na Tabela 4.
EVENTOS INTERMEDIÁRIOS
Notação
Trigger
Descrição
Catching Throwing
Nenhum
Nenhum trigger é acionado.
Mensagem
O trigger é a mensagem. A
mensagem deve ser enviada
para, ou recebida de, uma outra
entidade de negócio no
processo.
Uma mensagem chega de um
participante e dispara o evento.
O processo continua, se ele
estiver esperando pela
mensagem, caso contrário,
muda o fluxo para um
tratamento de exceção.
Timer
Uma data específica ou um ciclo
específico (por exemplo, toda
segunda-feira, às 9 horas) pode
ser o conjunto que acionará o
Evento.
Se usado dentro de um fluxo
principal poderá agir como um
mecanismo de atraso. Se usado
dentro de um tratamento de
exceção, alternará o fluxo
normal para um fluxo de
exceção.
Condicional
Define uma regra que deve ser
satisfeita para o processo
continuar.
53
Sinal
O trigger é um sinal que é
enviado ou recebido. Um sinal é
comunicação geral dentro e
através do níveis de processo,
através de pools e entre BPDs.
Múltiplo
Define ou mais triggers que
pode ser qualquer combinação
de mensagens, timer, erros,
condições ou sinais.
Erro
Define um evento que
geralmente irá quebrar o
processo ou solicitar correção.
Somente pode ser usado na
borda de uma atividade.
Cancelamento
Usado para cancelar um sub-
processo transacional. Deve ser
anexado na borda de um sub-
processo.
Compensação
Usado para estabelecer o
comportamento solicitado para
desfazer atividades em caso de
um sub-processo transacional
ser cancelado ou necessitar ser
retomado.
Link
Evento de desvio. Usado para
direcionar o fluxo para outra
atividade.
Fonte: adaptado de (WHITE e MIERS, 2008) e (OMG, 2008)
TABELA 4 – Tipos de eventos intermediários em BPMN
Quando um sinal chega de uma sequência de fluxo para um evento
intermediário, acontecerá uma das duas situações:
1) o evento espera alguma coisa acontecer (ou seja, espera a cirscunstância
definida pelo trigger). Este tipo de evento é conhecido como um Evento
Intermediário de Captura (catching). Neste caso, o marcador interno do
evento não é preenchido. Esta situação inclui Eventos Iniciais, desde que
estes eventos também esperem para ser acionados;
2) o evento imediatamente dispara (efetivamente criando a circunstância
definida no trigger). Este tipo de evento é conhecido como um Evento
Intermediário de Lançamento (throwing). Seu marcador interno tem um
54
preenchimento preto. Esta situação inclui Eventos Finais, contanto que eles
também sejam imediatamente acionados.
Um envento intermediário pode ser colocado ou dentro do fluxo normal de
um processo (ou seja, entre atividades), ou eles são anexados na borda de uma
atividade para acionar uma interrupção desta atividade. BPMN usa eventos
anexados na borda de uma atividade como uma meneira de modelar exceções do
fluxo normal do processo. A Figura 4 mostra um exemplo desta situação.
Fonte: WHITE e MIERS (2008)
FIGURA 4 – Exemplo de um evento intermediário anexado na borda de uma atividade
O exemplo apresentado na Figura 4 demonstra uma situação onde o fluxo
normal seria o recebimento da confirmação, caso esta atividade não aconteça em
até 2 dias o fluxo é desviado para a atividade “Enviar notícia de cancelamento”.
Eventos de término, ou eventos finais indicam onde o processo irá
terminar. Diferentes resultados indicam circunstâncias específicas que
encerraram o processo, conforme a Tabela 5.
EVENTOS FINAIS
Resultado
Descrição
Notação
Nenhum
Nenhum resultado é definido.
Significa o término normal de um
processo.
Mensagem
Sinaliza que o processo foi
encerrado com um comunicado.
55
Sinal
Este tipo de evento final indica
que um sinal será propagado
quando o Fim tiver sido
alcançado.
Término
Indica que todas as atividades no
processo devem ser finalizadas
imediatamente.
Erro
Sinaliza que o processo foi
encerrado devido a um erro ou
exceção.
Cancelamento
Usado com um sub-processo
transacional, causa o
cancelamento da transação e
aciona um evento intermediário
de cancelamento na borda do
sub-processo.
Compensação
Este tipo de evento indica que o
final do processo necessita de
uma compensação.
Múltiplo
Representa uma coleção de dói
ou mais resultados de Eventos
Finais. Os resultados pode ser
qualquer combinação de
mensagem, erros, compensação
e/ou sinais.
Fonte: adaptado de (WHITE e MIERS, 2008) e (OMG, 2008)
TABELA 5 – Tipos de eventos finais em BPMN
3.2.1.2 Atividades
Uma atividade pode ser atômica ou não-atômica (composta). Os tipos de
atividades que são parte de um modelo de processo são: Task (Tarefa), Sub-
Process (Sub-Processo) e Process (Processo). Tarefas e Sub-Processos são
representados por retângulos arredondados. Processos não possuem notação
gráfica associada (é o modelo em si, é um conjunto de objetos gráficos) ou é o
conteúdo de um Pool (será visto mais adiante).
As tarefas são atividades atômicas que estão incluídas dentro do processo,
ou seja, elas são o mais baixo nível de detalhes apresentado no diagrama. Seu
uso é indicado quando o trabalho no processo não é mais decomposto. As tarefas
possuem tipos especializados, mostrados na Tabela 6.
56
TAREFAS
Tipo
Descrição
Notação
Nenhum
Uma tarefa genérica ou
indefinida, geralmente usada
durante estágios iniciais do
desenvolvimento do processo.
Um usuário final e/ou um
aplicativo são usados para
executar a tarefa.
Manual
Uma tarefa não-automatizada
que um humano desenvolve fora
do controle de um fluxo de
trabalho.
Por exemplo, um técnico de
telefonia instalando um telefone
no endereço do cliente.
Recepção
Tarefa que espera uma
mensagem chegar de um
participante externo (relacionado
ao processo de negócio). Uma
vez recebida a mensagem, a
tarefa está completa. Similar ao
“catch message event”.
Script
Executa um script de um
modelador. É executada por um
mecanismo de processo de
negócio. Quando a tarefa está
pronta para ser iniciada, o
mecanismo executará o script.
Quando o script for completado,
a tarefa também será
completada.
Envio
Despacha uma mensagem para
um participante externo. Esta
tarefa é similar ao “throw
message event”.
Serviço
Tarefa que fornece algum tipo de
serviço, o qual pode ser um
serviço web ou uma aplicação
automatizada.
Usuário
Uma tarefa típica de um fluxo de
trabalho onde um humano
executa a tarefa com o auxílio de
um aplicativo de software.
Fonte: adaptado de (WHITE e MIERS, 2008) e (OMG, 2008)
TABELA 6 – Tipos de tarefas em BPMN
57
Um sub-processo é uma atividade composta que tem detalhes que são
definidos como um fluxo de outras atividades (OMG, 2008). O sub-processo pode
ser representado graficamente na forma “collapsed”, onde os detalhes do sub-
processo não são visíveis no diagrama (Figura 5) ou na forma “expanded”, onde a
forma gráfica do sub-processo é expandida para mostrar seus detalhes (Figura 6).
Fonte: WHITE e MIERS (2008)
FIGURA 5 – Sub-processo collapsed
Fonte: WHITE e MIERS (2008)
FIGURA 6 – Um sub-processo expanded
Um sub-processo ainda pode ser do tipo embutido (embedded) ou
reutilizável (reusable). Um sub-processo embutido é parte é uma atividade que
contém outras atividades. O sub-processo dentro do processo pertence somente
ao processo “pai” e não está disponível para qualquer outro processo. Uma
importante característica de um sub-processo embutido que ele somente pode
começar com o evento inicial sem nenhum trigger explícito (como uma
mensagem, por exemplo). Somente os processos do nível acima podem fazer uso
de eventos iniciais com triggers. Isso se deve ao fato de que um token que chega
de um processo pai age como o trigger (gatilho) para o sub-processo. Um
exemplo de sub-processo pode ser visualizado na Figura 7.
Um sub-processo reutilizável é um processo modelado separadamente que
pode ser usado em múltiplos contextos. Segundo os autores White e Miers
58
(2008), a distinção entre sub-processos embutidos e reusáveis não é importante
para a maioria dos modeladores. Entretanto, como as organizações desenvolvem
um grande número de modelos de processo, e alguns podem ser reutilizados, a
diferença se torna importante, especialmente quando se considera como os
dados são usados através dos níveis do Processo. Também não existe diferença
gráfica entre sub-processos embutidos e reusáveis. A diferença é puramente
técnica.
Fonte: WHITE e MIERS (2008)
FIGURA 7 – Um sub-processo embutido
Algumas situações pedem que uma tarefa ou uma seqüência de tarefas
sejam executadas repetidas vezes. Esse comportamento chama-se loop e a
notação BPMN especifica um marcador padrão para representar essa situação
conforme mostrado na Figura 8.
Fonte: adaptado de OMG (2008)
FIGURA 8 – Representação de tarefa e sub-processo com loop
59
Outra forma de representação do loop é a execução de múltiplas
instâncias4, conforme a Figura 9. Neste caso, a atividade ou o sub-processo são
executados várias vezes com diferentes conjuntos de dados.
Fonte: adaptado de OMG (2008)
FIGURA 9 – Representação de tarefa e sub-processo com loop de múltiplas instâncias
Uma atividade (seja ela tarefa ou sub-processo) também pode ter o
comportamento de compensação. A compensação é um tipo de atividade focada
na execução de um roolback, ou retornar o estado de um processo a um estado
anterior, para que o processo seja executado. Sua notação é mostrada na Figura
10.
Fonte: adaptado de OMG (2008)
FIGURA 10 – Representação de tarefa e sub-processo com compensação
Concluindo este item sobre atividades, pode-se resumir que uma atividade
é uma unidade de trabalho em um processo. Pode significar uma interação com o
usuário, ou algum processamento independente do perfil. Quando a atividade é
tão isolada que não faz mais sentido subdivisões, ela é chamada de tarefa. Uma
tarefa, portanto, é uma particularização do conceito de atividade. Da mesma
forma, um sub-processo é um tipo de atividade onde existe pelo menos um grau
de detalhamento em seu interior. Hierarquicamente, o processo é a atividade de
mais alto nível e é dividido em atividades menores, chamados sub-processos.
Estes sub-processos são cada vez mais detalhados, até que chega a um nível
onde não existe mais detalhamento, chamado de tarefa (task).
4
Uma instância é uma execução isolada de um processo (REIS, 2008).
60
3.2.1.3 Gateways
Gateways são os mecanismos padronizados na notação BPMN para
desvios. Eles controlam como o processo diverge ou converge, ou seja,
representa pontos de controle para caminhos dentro do processo. Eles separam e
juntam o fluxo de um processo (através do fluxo de seqüência). Como existem
diferentes maneiras de controlar o fluxo do processo, existem diferentes tipos de
gateways. Todos são sempre representados por losangos, porém os marcadores
internos do elemento indicam os diferentes tipos de comportamento. A Tabela 7
define cada tipo de gateway usado na BPMN, bem como sua notação.
Gateways
Tipo
Descrição
Notação
Exclusivo
Exclusive Decision/Merge (XOR)
É o gateway mais usado,
representa o OU, onde o acesso
a um dos caminhos é exclusivo.
Ou seja, apenas um dos
caminhos será seguido, não
importando quantos caminhos
existam para a escolha.
Qualquer um dos caminhos
tomados haverá uma junção na
frente, fazendo com que o fluxo
continue após um dos caminhos.
ou
Evento
Representa um ponto de
ramificação alternativo onde a
decisão é baseada em dois ou
mais eventos que poderiam
ocorrer.
Paralelo
Parallel Fork/Join (AND)
Sinaliza o início ou o término de
um fluxo de atividades
concorrentes. Quando se chega
até a bifurcação do tipo AND, se
seguem os dois caminhos.
Inclusivo
Inclusive Decision/Merge (OR)
Representa uma decisão onde é
possível seguir por um ou mais
caminhos durante o fluxo de
execução.
Complexo
Complex Decision/Merge
Usados em situações onde os
outros tipos de gateways não
provêem suporte para o
61
comportamento desejado. São
usados basicamente para:
1) os gateways testam uma
única condição, mas algumas
vezes é necessário testar
mais de um dado para a
tomada de decisão;
2) misturar comparadores
comuns (AND, OR ou XOR)
com um comparador baseado
em evento, onde cada uma
de suas saídas pode efetuar
testes distintos
3) para saber se uma
determinada saída foi
escolhida, em função de
outras escolhas.
Fonte: adaptado de (WHITE e MIERS, 2008) e (OMG, 2008)
TABELA 7 – Tipos de gateways em BPMN
3.2.2 Objetos de conexão
Os Objetos de Fluxo são conectados ao diagrama pelos Objetos de
Conexão para criar o esqueleto estrutural básico de um processo de negócio.
Existem três tipos básicos de objetos para prover esta função: fluxo de seqüência,
fluxo de mensagem e associação, representados na Figura 11.
Fonte: adaptado de OMG (2008)
FIGURA 11 – Objetos de conexão básicos em BPMN
3.2.3 Swimlanes
Swimlanes ou Raias ajudam a dividir e organizar atividades em diferentes
categorias visuais em um diagrama, de forma a ilustrar diferentes capacidades
funcionais ou responsabilidades. Esta categoria é suportada pela BPMN através
de dois tipos de elementos: pool e lane. De forma geral, uma pool ou lane não
62
interfere nem define o que será feito, mas sim quem o fará e normalmente está
associado a mecanismos de segurança.
Pools são “compartimentos” onde os elementos do fluxo são acomodados
de forma a indicar que participante do processo ou perfil está executando cada
atividade. Um participante é definido como uma regra geral de negócio (por
exemplo, um comprador, um vendedor, um fornecedor) ou como uma entidade
específica do negócio, como por exemplo, uma empresa. Cada pool representa
um processo distinto e cada participante tem seu próprio pool. A única forma de
elementos entre dois pools se comunicarem é através de mensagens. Ou seja,
não é permitido fluxos entre dois elementos do tipo pool. Uma pool é o elemento
mais externo, ou seja, não se pode inserir pools dentro de pools.
As lanes são elementos que são posicionados dentro de pools para indicar
mais de um perfil que colaboram para a execução de um processo. Lanes criam
sub-partições para os objetos dentro de um pool. Estas partições são usadas para
agrupar elementos do processo. Lanes geralmente representam regras da
organização (por exemplo, gerente, administração), mas podem representar
qualquer classificação desejada (por exemplo, departamentos organizacionais,
localização, entre outros). A Figura 12 exemplifica estes conceitos.
Fonte: WHITE e MIERS (2008)
FIGURA 12 – Um exemplo de lanes dentro de um pool
63
3.2.4 Artefatos
Por fim, os Artefatos são elementos extras que podem aparecer dentro do
diagrama, mas que não alteram o fluxo nem executam tarefas. Eles servem como
representações que irão aumentar a clareza do diagrama ou expor certos pontos
relevantes do processo e são definidos por três tipos básicos: objetos de dados,
grupos e anotações de texto, representados na Figura 13.
Fonte: adaptado de OMG (2008)
FIGURA 13 – Artefatos básicos em BPMN
Os objetos de dados são mecanismos que demonstram como os dados
são requeridos ou produzidos por atividades. Eles são conectados em atividades
através de associações. Os grupos são representados por um retângulo
pontilhado e pode ser usado com o propósito de destaque, documentação ou
análise, porém não afeta o fluxo de seqüência. As anotações são mecanismos
que provem ao modelador a capacidade de descrever informações textuais
adicionais ao leitor do diagrama.
64
4 MODELAGEM DE NEGÓCIO COM UML
4.1 Apresentação da linguagem UML para modelagem de negócio
A UML - Linguagem Unificada de Modelagem (Unified Modeling Language)
originou-se a partir da padronização das metodologias de desenvolvimento de
sistemas baseados na orientação a objetos. Foi criada por três grandes
desenvolvedores de sistemas orientados a objetos: Grady Booch, James
Rumbaugh, e Ivar Jacobson, que já haviam criado outras notações de
desenvolvimento de software (BOOCH, RUMBAUGH e JACOBSON, 2005).
A UML é uma linguagem gráfica para visualização, especificação,
construção e documentação de sistemas complexos de software. A UML se
propõe a ser a linguagem definitiva para modelagem de sistemas orientados a
objetos, por ser unificada e facilitar que grupos de desenvolvimentos de software
interpretem de uma maneira correta e sem ambigüidades, modelos gerados por
outros analistas ou grupos de desenvolvimento.
Ainda segundo os criadores desta linguagem (BOOCH, RUMBAUGH e
JACOBSON, 2005), a UML proporciona uma forma padrão para a preparação de
planos de projetos de sistemas, incluindo aspectos conceituais tais como
processos de negócios e funções do sistema, além de itens concretos como as
classes escritas em determinada linguagem de programação, esquemas de banco
de dados e componentes de software reutilizáveis. A UML define em sua versão
2.0, treze tipos de diagramas, divididos em duas categorias: diagramas estruturais
ou estáticos e diagramas dinâmicos. A função dos primeiros é mostrar as
características do sistema que não mudam com o tempo e dos outros como o
sistema responde às requisições ou como evolui com o tempo.
Porém, no seu modelo genérico que descreve outros modelos (meta-
model), a UML não contempla elementos específicos para tratar com diagramas
de modelos de processos de negócio. Atendendo a essa demanda são utilizados
mecanismos de extensão da própria UML definidos pelo OMG (ERIKSSON e
PENKER, 2000). A UML possui um conceito extremamente importante conhecido
como estereótipo (stereotype). Este conceito permite atribuir uma aparência
65
totalmente nova para elementos já existentes na UML, que permitem adequá-la a
novidades e domínios específicos (OMG, 1997). Estes mecanismos de extensão
têm a intenção de servirem aos seguintes propósitos:
• Adicionar elementos de modelagem na criação de modelos;
• Usados nas especificações da UML para definir itens padrões não
considerados ou complexos demais para serem modelados diretamente
pelos elementos do meta-modelo UML;
• Definir processos específicos ou implementação de extensões de
linguagens específicas;
•
Unir arbitrariamente informações semânticas e não semânticas a elementos
do modelo.
A extensão da UML para a modelagem de negócios, em termos de seus
mecanismos de extensão é descrita pela OMG (1997) em sua publicação “UML
Extension for Business Modeling”. O documento, porém não é uma tentativa de
descrever completamente os novos conceitos e notações para a modelagem de
negócios. Ele apenas descreve estereótipos que podem ser usados para adaptar
o uso da UML à modelagem de negócios. O documento afirma que todos os
conceitos da UML podem ser usados para modelar negócios, porém, o uso de
estereótipos para situações comuns de negócios proporciona uma terminologia
comum para este domínio. Os principais estereótipos são apresentados na Tabela
8 a seguir.
Símbolo Conceito Significado
Ator de negócio
Alguém ou alguma coisa fora
do negócio que interage com o
negócio, ou, que executa o
processo.
Worker de negócio
Um participante no processo
que está dentro da organização
executando o processo. Um
worker de negócio interage
com outros workers de negócio
e manipula entidades de
negócio.
66
Entidade de negócio
Uma “coisa” manipulada ou
usada pelos workers de
negócio.
Use-Case de negócio
Um processo de negócio é
expressado como um use case.
Uma seqüência de ações que
um negócio realiza que produz
um resultado observável a um
particular ator de negócio.
Realização de Use-Case de negócio
Uma coleção de diagramas que
mostra como os elementos da
organização (workers e
entidades) são implantados
para dar suporte ao processo
de negócio.
Evento
Um gatilho (trigger) que inicia o
processo.
Entrada
Um objeto que é consumido ou
transformado pelo processo
Saída
Um objeto que é produzido
pelo processo
Resultado
O resultado ou objetivo do
processo
Fonte: adaptado de SCHEDLBAUER (2010).
TABELA 8 – Elementos estereotipados da UML para a modelagem de negócio
4.2 Diagramas UML para modelagem de processos de negócio
A UML fornece diferentes diagramas para cada visão distinta do negócio.
Alguns destes diagramas, segundo (OMG, 1997) são:
• Diagramas Use-Cases de Negócio: contém os processos de negócio;
• Diagramas de Atividades: descrevem os comportamentos dentro do
negócio ou o workflow de negócio;
• Diagramas de Classes: descrevem a estrutura estática do negócio;
67
• Diagramas de Interação (Diagramas de Colaboração e Diagramas de
Seqüência): descrevem as interações dinâmicas entre os workers e as
coisas que eles manipulam.
Seguindo a especificação da OMG (1997), para ser considerado um bom
modelo de negócio, o mesmo deve mostrar o que o processo de negócio fará
(diagramas de use-case e atividade) e mostrar como o processo será executado
(diagramas de classe e interação). A primeira parte de um modelo de negócio é o
modelo use-case de negócio. Ele consiste de um ou mais diagramas de use-case
que contém um ou mais use-case de negócio. O modelo use-case de negócio
fornece uma visão de uma perspectiva do ator de negócio.
A segunda parte de um modelo de negócio é o modelo de objeto. Enquanto
um modelo de use-case mostra o que o processo de negócio fará, um modelo de
objeto mostra como o processo de negócio será feito. A seguir serão
apresentados os diagramas mais utilizados na modelagem de negócio com UML.
4.2.1 Diagrama use-case de negócio
Para entender completamente o objetivo de um negócio, é necessário
conhecer com quem o negócio interage, ou seja, quem fornece a entrada ou está
interessado na saída. O primeiro passo na modelagem de negócio então é definir
a interação entre entidades fora do negócio (fornecedores, clientes, parceiros,
entre outras), e os processos de negócio, os quais são descritos por use-case de
negócio (business use-case). Em outras palavras, um use-case de negócio
documenta um fluxo particular do negócio.
Um diagrama use-case de negócio representa a interação entre os
principais serviços que o negócio fornece (use-case de negócio) e aqueles para
quem os serviços são fornecidos (atores de negócio) (OMG, 1997). A Figura 14
mostra um exemplo deste diagrama.
68
Fonte: adaptado de HEUMAN (2003)
FIGURA 14 – Diagrama use-case de negócio do setor de check-in de um aeroporto
4.2.2 Diagrama de atividade
A partir do diagrama use-case de negócio, pode-se detalhar o workflow de
cada use-case de negócio para detalhar a seqüência de todas as atividades
executadas pelo processo de negócio. A estrutura do fluxo de trabalho é descrita
graficamente com a ajuda do diagrama de atividade da UML (HEUMAN, 2003).
Este diagrama também descreve as atividades que podem ser executadas em
paralelo e se existem caminhos alternativos por meio de um workflow. Ele ainda
descreve os papéis e áreas de responsabilidade de negócio, ou seja, descreve
quem é responsável em fazer o quê no negócio. Papéis e áreas de
responsabilidade são documentados como raias (swimlane da UML) no diagrama
de atividades. As raias mostram quais workers de negócio participam na
realização de um workflow. Na Figura 15, o Agente de check-in e o Agente de
bagagem são os workers envolvidos no use-case de negócio check-in
individual.
69
Fonte: adaptado de HEUMAN (2003)
FIGURA 15 – Diagrama de atividade do use-case de negócio check-in individual
4.2.3 Diagrama de classe
As entidades de negócio podem constituir um diagrama de classes de
negócio. Ele indica como workers se relacionam entre eles e com entidades de
negócio. A Figura 16 mostra um exemplo de diagrama de classe de negócio.
70
Fonte: adaptado de HEUMAN (2003)
FIGURA 16 – Um exemplo de diagrama de classes de negócio
4.2.4 Diagramas de interação
Outros tipos de diagramas usados em um modelo de objeto de negócio são
os diagramas de interação: diagrama de seqüência e diagrama de colaboração.
As informações contidas nestes diagramas são as mesmas; eles apenas as
apresentam de forma diferente. Os diagramas de interação descrevem
graficamente detalhes da interação entre business workers e atores de negócio.
Também mostram como entidades de negócio são associadas, durante a
execução de um use-case de negócio. A interação entre atores de negócio,
workers e entidades de negócio durante a realização de um use-case de negócio
são mostradas através de mensagens trocadas entre os mesmos.
Os diagramas de interação também podem indicar áreas de aprimoramento
do negócio, uma vez que mostram visualmente workers de negócio sendo
responsáveis por várias tarefas. É importante lembras que os diagramas de
interação não mostram decisões. Por este motivo, é necessário criar um diagrama
de interação (ou seqüência ou colaboração) para cada cenário (ou atividade)
descritas no diagrama de atividades que seja considerada relevante mostrar a
interação. A Figura 17 ilustra o fluxo básico do use-case de negócio check-in
individual em um diagrama de seqüência, que descreve o que os participantes
business workers fazem, como eles se comunicam uns com os outros pelo envio
de mensagem e como as entidades de negócio relevantes são manipuladas.
71
Diagramas de interação também podem mostrar a interação de um ator de
negócio com o negócio.
Heuman (2003) descreve que estes diagramas, juntamente com o
diagrama de classe formam o modelo de objeto do negócio. Este modelo fornece
informação detalhada de como o processo de negócio é implementado.
Fonte: adaptado de HEUMAN (2003)
FIGURA 17 – Diagrama de seqüência do use-case de negócio check-in individual
72
5 ANÁLISE COMPARATIVA ENTRE AS NOTAÇÕES DE
MODELAGEM DE PROCESSOS DE NEGÓCIO BPMN E UML
Neste capítulo é realizada uma comparação entre abordagens estudadas.
Conforme descrito no Capítulo 4, o detalhamento de um processo de negócio ou
use-case de negócio com UML é realizado utlizando diversas perspectivas
(diagrama de use-case de negócio, diagrama de atividades de negócio, diagrama
de classes e diagramas de interação), já BPMN utiliza-se apenas de um
diagrama, o BPD. Para poder comparar BPMN com UML, o foco será como estas
notações podem representar graficamente o fluxo de trabalho de um processo de
negócio, tanto no aspecto técnico como visual. A seguir serão descritos alguns
dos comportamentos que podem acontecer em um fluxo de trabalho.
5.1 Seqüência de atividades
Uma seqüência é definida como uma série de atividades ordenadas, com
uma atividade começando após a atividade anterior ser completada (WHITE,
2004b).
Em BPMN, um Diagrama de Processo de Negócio, ou simplesmente BPD,
define uma seqüência como uma série de atividades conectadas pelo fluxo de
seqüência e na notação UML esta seqüência é conectada pelo fluxo de controle.
Em ambas as notações, a direção da ponta do fluxo determina a ordem da
seqüência. A Tabela 9 sumariza a diferença deste conceito entre BPMN e UML.
Elemento
UML
BPMN
Atividade
Seqüência
Fonte: SCHEDLBAUER, 2010
TABELA 9 – Atividade e seqüência em UML e BPMN
73
5.2 Atribuição de atividades para participantes
Partições (ou pools em BPMN) são usadas para indicar quem executa cada
atividade em um processo. Partições podem ser horizontais, verticais, ou ambas.
Partições são nomeadas com o participante do processo que é responsável por
realizar as atividades (tarefas) naquela partição. Se um participante tem que fazer
uma decisão, o ícone de ramificação deve ser mostrado naquela partição do
participante. A Tabela 10 mostra o particionamento em UML e BPMN.
Particionamento
UML
BPMN
Fonte: SCHEDLBAUER, 2010
TABELA 10 – Atribuição de atividades a participantes em UML e BPMN
5.3 Agrupamento de atividades relacionadas
Em muitos processos se torna útil mostrar quais atividades forma um grupo
lógico de atividades relacionadas. Em UML é usada a atividade estruturada,
enquanto em BPMN é aplicado a representação do elemento grupo, conforme
mostrado na Tabela 11.
74
Agrupamento de atividades relacionadas
UML
BPMN
Fonte: SCHEDLBAUER, 2010
TABELA 11 – Agrupamento de atividades relacionadas em UML e BPMN
5.4 Divisão paralela e sincronização
Em algumas situações, um conjunto de atividades precisa ser executado,
mas a ordem em que as mesmas são executadas não importa. Esta situação é
modelada em UML com o par fork/join, enquanto que em BPMN é modelado com
o uso de um gateway inclusivo paralelo. Os elementos notacionais são mostrados
na Tabela 12. Em UML a primeira barra de sincronização é chamada de fork,
enquanto a segunda a qual junta os caminhos novamente é chamada de join. Em
BPMN é utilizado o mesmo ícone tanto para juntar como para separar o fluxo de
trabalho.
Esta semântica é definida tanto para aquelas atividades que podem ser
executadas em qualquer ordem ou ao mesmo tempo (em paralelo). Um fluxo de
trabalho é considerado paralelo quando permite que as atividades sejam
75
executadas concorrentemente (WHITE, 2004b). Entretanto, todas as atividades
entre a divisão e junção devem acontecer antes do processo continuar.
A sincronização combina os caminhos que foram gerados por uma divisão
paralela. Igualmente nesta situação, o conjunto final de atividades dentro dos
fluxos deve ser completado antes que o processo possa continuar. Também se
usa o gateway paralelo em BPMN para representar a sincronização e em UML, as
barras fork e join. A Tabela 12 também ilustra quando acontece uma divisão
condicional e complexa.
Os mecanismos para prover divisão e sincronização são diferentes entre as
duas notações. BPMN fornece mecanismos mais simples com as múltiplas saídas
do fluxo de seqüência. Se um objeto de controle é requisitado, então um gateway
paralelo fica disponível. UML requer que um objeto gráfico, uma bifurcação, cria a
divisão paralela. BPMN aplica uma forma simples, um diamante, para representar
qualquer controle ou restrição em um fluxo entre atividades. Marcadores internos
indicam o tipo exato de controle (isto é, divisões paralelas ou alternativas). BPMN
portanto, emprega um conjunto menor de objetos na modelagem (apenas a forma
de diamante da decisão), enquanto UML aplica dois diferentes tipos de objeto (um
diamante e uma barra) para representar o fluxo de controle. Isto provê uma
distinção mais fácil entre os dois tipos básicos de controle, mas quando um
controle mais complexo é necessário, o qual contém tanto um comportamento
paralelo como um alternativo, então esta distinção fica menos clara (WHITE,
2004b).
Elemento
UML
BPMN
Divisão Inclusiva
(todos os caminhos são
tomados em qualquer
ordem)
fork e join
gateway inclusivo paralelo
76
Divisão Condicional
(somente os caminhos
nas quais as condições
são satisfeitas são
tomados em qualquer
ordem)
fork e join condicional
gateway inclusivo splitting
Gateway complexo
(com semântica
customizada pelo
analista)
fork complexo
gateway complexo
Fonte: SCHEDLBAUER, 2010
TABELA 12 – Divisões inclusiva, condicional e complexa em UML e BPMN
5.5 Escolha exclusiva e escolha múltipla
Uma escolha exclusiva é definida como sendo um ponto no processo onde
o fluxo é dividido em dois ou mais caminhos alternativos exclusivos. Somente um
desses caminhos alternativos deve ser escolhido para o processo continuar.
Tanto BPMN como UML representam este tipo de decisão com o uso de um
diamante, como mostrado na Tabela 13.
A escolha múltipla permite que desde um até todos os caminhos
alternativos sejam escolhidos para executar. Tecnicamente, nenhum caminho
precisa ser escolhido na múltipla escolha, mas isto poderia ser considerado uma
situação inválida onde o fluxo do processo termina inesperadamente.
77
BPMN representa este comportamento usando um gateway inclusivo. A
saída do fluxo de seqüência deste gateway terá expressões booleanas que serão
avaliadas para determinar qual fluxo de seqüência deverá ser usado para
continuar o processo. Quando um token chega ao gateway, todas as expressões
serão avaliadas e para cada expressão que é determinada como verdadeira, o
fluxo de seqüência correspondente será escolhido e um token continuará aquele
caminho. UML usa um nó de bifurcação onde a saída do fluxo de controle tem
condições para criar o comportamento de escolha múltipla. Assim, o nó de
bifurcação cria um conjunto de caminhos paralelos. As representações em BPMN
e UML também são mostradas na Tabela 13.
Elemento
UML
BPMN
Escolha exclusiva
Escolha múltipla
Fonte: adaptado de (WHITE, 2004b)
TABELA 13 – Escolhas exclusiva e múltipla em UML e BPMN
A diferença básica entre as duas notações é que BPMN usa uma variação
do gateway para este comportamento e UML usa uma variação do nó de
bifurcação. Em UML, isto fica um pouco confuso, desde que o comportamento
envolve decisões bem como paralelismo, mas um diamante de decisão não é
usado. O BPD da BPMN além de usar o gateway para mostrar que é um ponto de
78
decisão, também usa um marcador interno para indicar que a decisão não é
exclusiva.
5.6 Junção simples e múltipla
Uma junção simples é definida como sendo o local em um processo onde
um conjunto de caminhos alternativos é unido em um caminho único caminho
(WHITE, 2004b).
A junção simples é outro exemplo de fluxo sem controle em BPMN. Ou
seja, um token pode seguir entre duas atividades sem qualquer mecanismo de
controle interferindo. UML usa o diamante de decisão para convergir um conjunto
de caminhos alternativos. Quando um token chega ao diamante, ele seguirá
imediatamente a saída do fluxo de controle. A Tabela 14 mostra este
comportamento representado nas duas notações.
White (2004b) define uma junção composta como um local no processo
onde existem múltiplos caminhos unindo-se, mas sem nenhum controle do fluxo
dos tokens. Quando um token chega em uma atividade, aquela atividade será
instanciada. Assim, se existem múltiplos caminhos convergindo em uma atividade
sem nenhum controle de token, é possível que a atividade seja instanciada uma
vez para cada um dos caminhos que estão unindo-se. Este comportamento se
difere da sincronização ou junção simples, pois nestes, a atividade somente será
instanciada uma vez.
Como o comportamento de junção múltipla envolve uma situação de fluxo
sem controle, BPMN não emprega gateways. Esta notação permite múltiplos
fluxos de seqüência chegando em uma atividade e isto fornece a localização de
uma junção múltipla. Para cada token que chega em um fluxo de seqüência, uma
instância separada de uma atividade será gerada. A notação UML usa um
diamante para unir um conjunto de caminhos. Quando um token chega ao
diamante, ele seguirá a saída do fluxo de controle. A representação deste
comportamento também está na Tabela 14. Como comparação entre as
notações, um diagrama da notação BPMN fornece um mecanismo mais simples
para representar este comportamento.
79
Elemento
UML
BPMN
Junção simples
Junção múltipla
Fonte: adaptado de (WHITE, 2004b)
TABELA 14 – Junção simples e múltipla em UML e BPMN
5.7 Término implícito
Este comportamento permite que um caminho específico de um processo
seja concluído sem que outros caminhos paralelos sejam requeridos para
finalizar. Ainda segundo White (2004b) algumas notações requerem que todo o
processo termine quando o nó final é alcançado. Muitas notações, tal como
BPMN e UML provém ambas as funcionalidades.
O evento final em BPMN é um indicador que um caminho particular foi
completado. BPMN tem várias variações de evento final e todos eles, exceto um,
fornece o comportamento de término implícito. Todas as variações do evento final
têm um marcador interno que indica um resultado particular de final de caminho.
80
O evento final de término, como seu nome indica, causará a parada de todo o
processo, mesmo se existirem atividades que não iniciaram ou ainda estão ativas.
O nó de fluxo final (um círculo com um marcador interno “X”) na notação
UML é um indicador que um caminho particular foi completado e isto fornece o
comportamento de término implícito. O nó de atividade final (um círculo com um
pequeno círculo interno preenchido) causará que o processo inteiro pare, mesmo
se existirem atividades que ainda não foram iniciadas ou estão ativas. Estes
comportamentos, tanto em BPMN e UML são apresentados na Tabela 15.
Elemento
UML
BPMN
Término implícito
Fonte: adaptado de (WHITE, 2004b)
TABELA 15 – Término implícito em UML e BPMN
As duas notações fornecem mecanismos similares para diagramar este
comportamento. Ambas as notações permitem o término implícito. A diferença é
que BPMN permite que o modelador forneça informações adicionais sobre o
resultado de completar um particular caminho no processo. Diferentes variações
de evento final em BPMN mostram que o final de um caminho resulta em uma
mensagem, exceção, cancelamento de transação, compensação, link para outros
processos ou uma combinação de resultados, como mostrado na Tabela 6 do
Capítulo 3.
81
5.8 Escolha adiada (deferred)
Este comportamento representa um tipo de decisão exclusiva, entretanto, a
base para determinar o caminho que será escolhido é diferente. O
comportamento de decisão exclusiva é baseado na avaliação de dados no
processo, enquanto a escolha adiada (ou deferred) é baseada em um evento que
ocorre durante o processo. Uma vez que o evento ocorre (ou seja, a escolha é
feita), então outros caminhos alternativos serão desabilitados (WHITE, 2004b).
Um diagrama da notação BPMN usa um gateway exclusivo baseado em
dados. Esta decisão representa um ponto de ramificação onde as alternativas são
baseadas em um evento que ocorre naquele ponto no processo. Esta solução é
única em BPMN em que o gateway é suportado por objetos adicionais para
controlar o fluxo de seqüência. O gateway é imediatamente seguido pelos eventos
intermediários. Quando um token chega no gateway, ele espera o evento
(geralmente o recebimento de uma mensagem) que determina qual dos caminhos
será seguido. Outros tipos de eventos, como timer, por exemplo, podem ser
utilizados. Somente uma das alternativas será escolhida.
A UML usa uma configuração especial para um nó de bifurcação, uma
região “interruptível”, e uma ação de receber sinal para fornecer este tipo de
comportamento. No ponto onde a escolha deverá ser feita um nó de bifurcação
cria um número de caminhos paralelos que é igual ao número de opções na
escolha, assim, múltiplos tokens são criados. Estes caminhos paralelos passam
dentro da região “interruptível”. Cada um dos caminhos paralelos levará a ação de
receber sinal dentro da região. Quando o primeiro sinal chega será usado para
sair da região, desse modo desabilitando o recebimento de qualquer outro sinal.
Um dos tokens atravessará a borda da interrupção para seu o destino, enquanto o
outro token será consumido pela região de interrupção. A Tabela 16 mostra esse
comportamento nas duas notações descritas.
Comparando as notações, ambas fornecem representação para este
comportamento. Entretanto, os mecanismos utilizados são diferentes. BPMN
coloca o comportamento no contexto de uma decisão e os eventos que conduzem
a decisão, enquanto UML coloca o comportamento no contexto de um nó de
bifurcação que gera múltiplos caminhos que são ignorados, exceto o iniciado pelo
82
sinal. O uso da bifurcação e uma região “interruptível” não transmitem
intuitivamente a idéia que a decisão está sendo feita no processo.
Escolha Adiada
UML
BPMN
Fonte: adaptado de (WHITE, 2004b)
TABELA 16 – Escolha adiada em UML e BPMN
5.9 Milestones
Existem pontos dentro de um processo onde é importante conhecer um
evento específico como ocorrido ou que uma condição tenha sido encontrada. O
autor White (2004b) define esses eventos ou condições como milestones. O
modelo do processo deve ser capaz de identificar e reagir a estes “marcos”.
Ambas as notações estudadas podem manipular o comportamento de milestone
adequadamente com mecanismos similares.
Na notação BPMN o exemplo mostrado na Tabela 17 mostra como a
informação pode ser passada de uma parte do diagrama de processo de negócio
para outra parte quando o fluxo de seqüência normal não pode ser usado. Esta
informação reflete a ocorrência de um milestone. No exemplo, a conclusão de
uma atividade (TarefaB) em um sub-processo é requerida antes de uma atividade
(TarefaB) em um outro sub-processo possa iniciar. Um evento final de link que
segue a TarefaB é usado para iniciar um evento inicial de link que antecede a
TarefaD. Uma associação opcional de link é usada para reforçar este
relacionamento.
No exemplo mostrado em UML é mostrado como a informação pode ser
passada de uma parte de um processo para outra parte quando o fluxo de
83
controle normal não pode ser usado. Aqui, a finalização de uma atividade
(Atividade B) em uma sub-atividade é requerida antes que uma atividade
(Atividade D) em outra sub-atividade possa começar. Um sinal de envio que
segue a Atividade B é usado para iniciar a recepção correspondente de um sinal
que antecede a Atividade D. O exemplo em UML também é mostrado na Tabela
17.
Milestone
UML
BPMN
Fonte: adaptado de (WHITE, 2004b)
TABELA 17 – Exemplo de um milestone em UML e BPMN
5.10 Cancelar atividade
Este comportamento descreve como é possível que existam duas
atividades competindo. Quando uma das atividades é completada, sinaliza que a
outra atividade deverá parar de processar. Assim, um mecanismo de sinalizar o
cancelamento e um mecanismo para interromper atividades baseado neste sinal
são ambos requeridos (WHITE, 2004b).
84
Um BPD executa manipulação de exceção através de eventos
intermediários que são anexados na borda de uma atividade. Se o gatilho de um
evento intermediário ocorre enquanto a atividade está sendo executada, a
atividade será interrompida e o token sairá da atividade através do evento
intermediário e seguirá o fluxo de seqüência para o próximo objeto. No exemplo
mostrado na Tabela 18, o gatilho para o evento intermediário de exceção é outro
evento intermediário que segue a Tarefa B e está no fluxo geral do processo (não
anexado na borda de uma atividade). Este evento intermediário “lança” o sinal de
cancelamento e o evento intermediário anexado na borda da Tarefa C “captura” o
sinal.
Na UML a manipulação de execução é manipulada através de uma região
“interruptível” que cerca uma ou mais atividades, como mostrado também na
Tabela 16. Se ou uma atividade for completada ou o recebimento de um sinal,
fizer com que um token atravesse a borda “interruptível”, então todas as
atividades dentro da região serão paradas, e o fluxo somente continuará na borda
interrompida. No exemplo mostrado na Tabela 18, o gatilho para a exceção é o
recebimento de um sinal. O sinal é enviado imediatamente após a Atividade B ser
completada. A ação de envio de sinal “lança” o sinal de cancelamento e a ação de
receber sinal em uma região “interruptível” “captura” o sinal.
Cancelar Atividade
UML
85
BPMN
Fonte: adaptado de (WHITE, 2004b)
TABELA 18 – Cancelar atividade em UML e BPMN
As duas notações manipulam o lançamento e a captura de exceções de
uma maneira similar. O mecanismo da BPMN de anexar eventos intermediários
na borda de atividades é mais evidenciado tem uma representação mais intuitiva
de onde as exceções são aplicadas. Além disso, o mecanismo da BPMN é
aplicado somente a atividades completas, uma tarefa ou um sub-processo. A
região “interruptível” é uma construção mais arriscada no sentido que pode
interromper atividades que são um subconjunto de um grupo coesivo de
atividades, tal como aquelas dentro de um padrão de bifurcação e união.
5.11 Sinais e eventos
Sinais indicam que outro processo deveria iniciar e executar enquanto o
processo corrente continua (SCHEDLBAUER, 2010). O nome do sinal e do
evento deve ser o mesmo para indicar que o sinal causa a espera do processo
para iniciar. Os símbolos para eventos e sinais são resumidos na Tabela 19.
O evento inicia o processo que é “cronometrado” (timed) e condicional. Ele
inicia somente quando o sinal é enviado. Um processo também pode iniciar
baseado em um evento timed, ou seja, quando for decorrida certa quantidade de
tempo ou algum ponto específico no tempo foi alcançado. Um sinal pode iniciar
múltiplos processos se todos eles estão esperando pelo mesmo evento.
86
Elemento UML BPMN
Sinal (Envio)
Evento (Receber)
Evento Timed
Fonte: SCHEDLBAUER, 2010
TABELA 19 – Eventos de envio e recebimento e sinais em UML e BPMN
5.12 Outros elementos
A Tabela 20 apresenta outros elementos usados para representar o fluxo
de trabalho de um processo de negócio nas notações estudadas.
O início e o final de um processo devem ser claramente indicados. Existe
somente um começo para cada processo, mas podem existir múltiplos finais. Os
símbolos de processo final podem ser opcionalmente nomeados. Para o autor
Schedlbauer (2010), o uso de um nome é para indicar ou que o processo
terminou com sucesso ou para indicar alguma falha ou pós-condição não
encontrada.
Pré-condições indicam restrições que devem ser verdadeiras para o
processo ser completado com sucesso e pós-condições resume a conseqüência
do processo. Elas podem ser sobre mudanças de dados ou saídas e são críticas
para testes. Estereótipos são um mecanismo geral tanto para BPMN como UML
classificarem construtores. Todos os estereótipos são mostrados entre << e >>.
Estes estereótipos são usados para classificar notas ou como pré-condições ou
pós-condições. Outro elemento útil nas notações são notas de texto, também
mostradas na Tabela 20.
87
Elemento
UML
BPMN
Início de
Processo
Final de
Processo
Pré-Condição
Pós-Condição
Nota de Texto
Ligação de
uma Nota de
Texto com um
Elemento
Fonte: adaptado de (SCHEDLBAUER, 2010) e (WHITE, 2004b)
TABELA 20 – Outros elementos usados em UML e BPMN
5.13 Exemplo
Este item tem por objetivo tornar mais clara (e visual) esta teoria, através
de um exemplo modelado nas duas abordagens apresentadas. Este exemplo é
explorado na documentação oficial BPMN e sua descrição completa encontra-se
em (IBM, 2004). A Figura 18 apresenta o processo de negócio “Agendamento de
Viagem” feito com o Diagrama de Atividade da UML na ferramenta Sparx Systems
88
Enterprise Architect Version 7.5. A seguir será apresentado na Figura 19, o
mesmo processo, implementado na notação BPMN, utilizando a ferramenta
Business Process Visual Architect 3.2 Modeler Edition da Visual Paradigm.
Fonte: adaptado de REIS (2008)
FIGURA 18 – Processo “Agendamento de Viagem” modelado em UML
Pode-se observar que no caso do diagrama UML mostrado na Figura 18,
como não existem mecanismos de compensação e geração de erros, é
necessário utilizar elementos de decisão para indicar o fluxo em caso de erro.
Neste diagrama fica mais difícil identificar qual elemento está sendo utilizado
como parte do tratamento do processo do negócio, e qual decisão foi inserida
como desvio para tratamento de erros, dificultando a manutenção.
act Agendamento de Viagem
Agendamento de v ôo Agendamento de Hotel
Cancela HotelCancela v ôo
Cancela Hotel Cancela v ôo
Tratar com "customer care"
Troca comprador
Env ia av iso de
indisponibilidade
[erro no agendamento?] [erro no agendamento?]
[erro não recuperável?]
[hotel agendado?]
[vôo agendado?]
89
Fonte: adaptado de REIS (2008)
FIGURA 19 – Processo “Agendamento de Viagem” modelado em BPMN
Na Figura 19, pode ser observada a inserção de outros elementos, como
timers e mensagens que são adicionadas ao diagrama. Eles isolam elementos de
interação dos processos de tratamento da lógica de negócios, de forma mais
clara. Resumindo, um diagrama BPMN torna o entendimento mais fácil e adiciona
elementos gráficos que facilitam a compreensão do que está acontecendo no
diagrama.
As conclusões no Capítulo 6 apresentam outras diferenças entre as
notações.
90
6 CONCLUSÕES
6.1 Conclusões
A empresa é a forma pela qual os recursos são organizados para realizar
um trabalho proposto. A organização de uma empresa por processos é uma
forma de tentar alcançar maior eficiência na obtenção do seu produto ou serviço,
melhor adaptação à mudança, melhor integração de seus esforços e maior
capacidade de aprendizado (GONÇALVES, 2000). A idéia de processo não é
nova na administração das empresas, mas é um novo entendimento que diz que
o negócio precisa focar aquilo que pode ser feito para agradar aos clientes
externos.
Porém as empresas estão percebendo que é praticamente impossível
mudar de uma organização por tarefas para uma organização orientada por
processos sem um claro entendimento do que exatamente faz a empresa
funcionar bem. A aplicação da modelagem de processos de negócio tem como
objetivo conhecer os processos de uma organização e propor melhorias para os
mesmos.
A modelagem de processos de negócio pode ser uma excelente ferramenta
para disseminar o conhecimento organizacional, uma vez que as organizações
passam a compreendê-lo como um recurso, tornando-se assim uma excelente
fonte para vantagem competitiva. A maioria dos modelos de negócio são
complexos devido ao fato dos usuários terem diferentes necessidades e estas
necessidades mudarem a cada tempo. Para que uma empresa possa ser
adaptável às mudanças, ela precisa ter uma descrição simples e unificada de
suas entidades (MARSHALL, 1999). Modelos de processos são uma abstração da
realidade, e por esta razão não são perfeitos. Deve ser levado em consideração
que o ambiente muda a cada momento e os processos devem mudar com ele.
Um bom modelo não é tudo, mas é um ótimo ponto de partida.
Foi abordada também nesta dissertação, através do estudo do BABOK
(IIBA, 2009), a análise do negócio. Seu estudo foi importante, pois a análise de
negócios se concentra no domínio do problema, para entender o problema é
necessário entender o negócio e isso se faz através da modelagem de negócios
91
que representa o que é importante para o projeto a partir de diferentes visões.
Através dela é possível alcançar a eficácia que quer dizer “fazer a coisa certa”,
pois traça uma linha que vem da estratégia aos requisitos. Porém, mais uma vez
é conveniente deixar claro neste trabalho que o BABOK é um guia descritivo, ou
seja, não mostra como fazer a análise, apenas diz quais atividades ela deve
contemplar.
Dentro do contexto descrito acima, evidencia-se a necessidade de uma
linguagem (ou notação) para modelagem de negócios que permita uma
modelagem flexível, por processos, de fácil entendimento e representação. Nesta
dissertação foram estudadas duas abordagens representadas pela OMG, as
quais segundo o levantamento bibliográfico são as mais conhecidas e usadas: a
extensão da UML para modelagem de processos de negócio e a notação BPMN.
No que se refere à UML, o que se busca é adaptar esta linguagem através
de seus mecanismos de extensão, aproveitando seu potencial de flexibilidade e
representação dinâmica oferecido por seus diagramas. As extensões definidas
pelos usuários na UML se dão através de estereótipos (stereotypes) e dentre as
motivações para sua utilização pode-se citar:
• A UML já é uma linguagem madura e consolidada;
• A modelagem de negócio e a modelagem de sistemas usando a mesma
linguagem;
• Uso de vários diagramas para representar diferentes visões do negócio.
Porém a notação UML embora seja muito formal, deixa a desejar em
termos de diversidade gráfica, além de utilizar as mesmas simbologias para o
tratamento do negócio e para tratamento de erros, que normalmente não fazem
parte do negócio em si, conforme mostrado no exemplo do item 5.13, no Capítulo
5. Em modelos mais complexos representados por diagramas mal elaborados ou
não refinados, a tendência é confundir e dificultar a visualização e manutenção
dos fluxos de trabalho.
Fazendo uma análise do Capítulo 5, os comportamentos apresentados são
suportados adequadamente pelas duas notações, porém, o Diagrama de
Atividades da UML deixa a desejar graficamente em alguns elementos com
relação à notação do Diagrama de Processos de Negócio, o BPD. Muitos
92
elementos, como atividades e decisões, por exemplo, são representados de uma
maneira bem similar por ambas as notações, porém BPMN contém menos
elementos básicos, os quais possuem variações para manipular com processos
complexos, como mostrado no capítulo anterior, o que torna a notação mais
simples e fácil de usar e entender.
Outra diferença entre as duas abordagens é a terminologia de alguns
elementos. Por exemplo, um Diagrama de Atividades tem um nó inicial (start
node) e um BPD tem um evento inicial (start event). Outras diferenças existem e
não foram demonstradas nesta dissertação, onde a comparação foi enfatizada no
fluxo de controle entre as atividades dos processos.
As similaridades entre os dois diagramas existem porque eles se propõem
a resolver o mesmo problema básico: a modelagem de processos de negócio. As
diferenças estão presentes pelo fato da notação BPMN ter sido criada
exclusivamente pensando em modelar processos de negócio, para ser usada por
pessoas de negócio. Já UML faz uma adaptação de seus elementos para
processos de negócio.
Como BPMN é uma notação e um conjunto de regras para modelagem de
processos de negócio, é possível mapear em detalhes todos os processos de
negócio da empresa, orientados ou não ao desenvolvimento de um software, e
com a capacidade de representar relações entre empresas diferentes (clientes e
fornecedores), ao mesmo tempo com uma visão global da organização através do
uso de sub-processos. A utilização de um padrão visual permite que diferentes
empresas e profissionais possam compartilhar conhecimentos e entendimentos
sobre o funcionamento das regras de processo em comum.
A notação BPMN foi criada e tem o apoio das principais empresas de TI do
mundo, como IBM, SAP, ORACLE e MICROSOFT. BPMN é independente de
ferramenta, de sistemas ou de plataforma de operação. Praticamente todos os
produtos de modelagem de processos do mundo já se adaptaram ou estão se
adaptando ao modelo BPMN, incluindo Microsoft Visio, IDS Scheer Aris, Proforma
Provision e IBM
5
. Dentro da área de modelagem de processos de negócio, BPMN
é a especificação que mais cresce, pois praticamente não possui concorrentes.
5
Estes dados foram obtidos em (hppt://www.bpmn.org/BPMN_Supporters.htm).
93
Atualmente é controlada pela OMG, mesma organização internacional que
controla a UML. Em um futuro próximo, a tendência é que UML (Diagramas de
Atividades) e BPMN irão se fundir.
Relembrando o principal objetivo da BPMN, diminuir a distância de
entendimento entre os objetivos do projeto, a análise de requisitos realizada por
analistas e o programa desenvolvido pelos técnicos, reduzindo assim os riscos do
projeto e tornando a solução final mais aderente aos objetivos de negócio. Ao
aproximar a área de negócios e a área de TI, BPMN torna-se uma ferramenta
eficaz de comunicação entre a primeira (que conhece como funciona o fluxo de
atividades) e a segunda (que precisa automatizar esse fluxo). Isso é possível
através de uma notação simples, porém poderosa e uma visão orientada a
processos.
Os autores (MUEHLEN e RECKER, 2008) realizaram um estudo sobre a
simplicidade da BPMN, “How much BPMN do you need”, analisando 126
diagramas desenhados por empresas e consultores e mostraram que “menos é
mais”, com o desenho do processo mais simples, mais fácil de compreender e
muito mais claro. Algumas considerações apresentadas neste artigo:
• Nenhum dos diagramas utilizou mais de 15 elementos diferentes, e
nenhum usou menos que 3;
• A média foi 9 tipos diferentes por fluxo, ou seja, menos de 20% do
subset total fornecido pela BPMN;
• 5 elementos da BPMN nunca foram usados em nenhum diagrama.
Para endossar o uso de uma notação simples, finalizando assim este
estudo, é apresentado o princípio da “Navalha de Occam” ou Navalha de
Ockham (SAGAN, 2006). Este princípio lógico atribuído ao lógico e frade
Franciscano inglês William de Ockham afirma que a explicação para qualquer
fenômeno deve assumir apenas as premissas necessárias à explicação do
fenômeno e eliminar todas as que não causariam qualquer diferença aparente nas
predições da hipótese ou teoria. O princípio é freqüentemente designado pela
expressão latina Lex Parsimoniae (Lei da Parcimónia), enunciada como: “as
entidades não devem ser multiplicadas além da necessidade”. Esta formulação é
muitas vezes parafraseada como: “se em tudo o mais forem idênticas as várias
94
explicações de um fenômeno, a mais simples é a melhor”. O princípio recomenda
assim que se escolha a teoria explicativa que implique o menor número de
premissas assumidas e o menor número de entidades.
Essa maneira prática e conveniente de proceder incita a escolher a mais
simples dentre duas hipóteses que explicam os dados com igual eficiência, ou
seja, dentre as duas notações apresentadas, BPMN é a mais simples para
modelagem de processos de negócio.
6.2 Sugestões para trabalhos futuros
Com a realização da presente pesquisa foi possível verificar alguns pontos
que poderão ser desenvolvidos em outros trabalhos científicos, no âmbito de
modelagem de processos de negócio. Tratando-se de um estudo exploratório,
mesmo que alguma percepção inicial quanto às vantagens da BPMN tenham sido
levantadas existe a necessidade de pesquisas comprobatórias, para que se
tenham indicadores mais claros, quanto ao benefício da notação BPMN em
relação à UML. Algumas sugestões:
• Como descrito anteriormente, a comparação neste trabalho teve ênfase
no fluxo de controle entre as atividades dos processos. A sugestão seria
realizar uma comparação com ênfase em outros critérios;
• Aplicação da proposta apresentada neste trabalho em estudos de casos
reais;
• Evolução do trabalho rumo à especificação do projeto e implementação
para comprovar de fato que o entendimento dos processos de negócio
auxilia o correto desenvolvimento;
• Testes para a hipótese de melhoria de processos com a modelagem,
comparando o estado atual (as is) e futuro (to be).
95
REFERÊNCIAS
BALDAM, Roquemar et. al. Gerenciamento de Processos de Negócios: BPM.
São Paulo: Editora Érica, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário.
Editora Elsevier. 2ª ed. Rio de Janeiro, 2005.
BPMN – BUSINESS PROCESS MODELING NOTATION. Business Process
Modeling Notation (BPMN) Information. OMG, 2007. Disponível em:
<http://www.bpmn.org>. Acesso em: 07/05/10.
DAVENPORT, Thomas H. Reengenharia de Processos: Como Inovar na
Empresa Através da Tecnologia da Informação. 5
a
ed. Rio de Janeiro,
Campus, 1994.
DIAS, Felipe; FERREIRA, Fernando M. L.; MORGADO, Gisele; et al. Modelagem
de Negócios e Sistemas de Informação, 2005. Artigo publicado na revista
<Conceito/> Informativo Técnico do Núcleo de Computação Eletrônica da UFRJ,
Nov/Dez 2005, nº 3. Disponível em:
http://www.nce.ufrj.br/conceito/artigos/2006/017p1-3.htm. Acesso em 20/01/2010.
ERIKSSON, H.; PENKER, M. Business Modeling with UML: Business Patterns
at Work. John Wiley & Sons Inc., 2000.
GIL, A. C. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999.
96
GONCALVES, Jose Ernesto Lima. As empresas são grandes coleções de
processos. RAE - Revista de Administração de Empresas. São Paulo, v. 40, n. 1,
6-19, jan./mar. 2000.
HAMMER, Michael. A Agenda: O Que as Empresas Precisam Fazer Para
Dominar Esta Década. Rio de Janeiro: Campus, 2002.
__________. The Superefficient Company. Harvard Business Review, vol. 79,
p. 82-91, 2001.
HARRINGTON, James. Gerenciamento Total da Melhoria Contínua. São
Paulo: Makron Books, 1997.
HEUMANN, Jim. Introduction to Business Modeling Using the Unified
Modeling Language (UML). IBM, Software Group, 2003. Disponível em:
<
http://www.ibm.com/developerworks/rational/library/360.html
>. Acesso em:
10/07/10.
IBM Corporation. IBM WebSphere Studio Application Developer Integration
Edition Information Center, 2004. Disponível em
<http://publib.boulder.ibm.com/infocenter/adiehelp/index.jsp?topic=
/com.ibm.etools.ctc.bpel.doc/samples/travelbooking/travelBooking.html>. Acesso
em 16/05/10.
IIBA - INTERNATIONAL INSTITUTE OF BUSINESS ANALYSIS. A Guide to the
Business Analysis Body of Knowledge
®
(BABOK
®
Guide). Toronto:
International Institute of Business Analysis, 2009.
97
__________. About International Institute of Business Analysis, 2010.
Disponível em: <http://www.theiiba.org>. Acesso em 23/04/2010.
JESTON, J.; NELIS, J. Business Process Management: pratical guidelines to
successful implementations. Oxford: Elsevier, 2006.
KALPIC, Brane; BERNUS, Peter. Business process modeling in industry – the
powerful tool in enterprise management. Computers in Industry, Orlando, v. 47,
p. 299-318, 2002.
KOUBARIAKIS, Manolis; PLEXOUSAKIS, Dimitris. Business Process Modelling
and Design. University of Athens, Athens, 2000. Disponivel em:
<http://portal.acm.org/citation.cfm?id=599472&dl=GUIDE&coll=>. Acesso em:
07/05/10.
LIN, Fu-Ren; YANG, Meng-Chyn; PAI, Yu-Hua. A generic structure for
business process modeling. Business Process Management Journal. Vol. 8, n.
1, 2002. p. 19-41. Disponivel em:
<http://fac.ceprin.gsu.edu/welke/CIS9240/Papers/BPM/Generic%20Structure
%20for%20BPM.pdf>. Acesso em: 07/05/10.
LIST, Beate; KORHERR Birgit. An Evaluation of Conceptual Business Process
Modelling Languages. ACM Symposium on Applied Computing, New York, 2006,
p.1532-1539.
MARSHALL, Chris. Enterprise Modeling with UML. Estados Unidos: Addison-
Wesley, 1999.
98
MUEHLEN, Michael zur; RECKER, Jan. How much BPMN do you need. BPM
Research, 2008. Disponível em <http://www.bpm-research.com/2008/03/03/how-
much-bpmn-do-you-need/>. Acesso em 30/06/2010.
OMG – OBJECT MANAGEMENT GROUP, Inc. Business Process Modeling
Notation, V1.1 – OMG Available Specification. OMG, 2008. Disponível em:
<
http://www.omg.org/spec/BPMN/1.1/PDF
>. Acesso em: 28/06/10.
__________. Business Process Model and Notation (BPMN) – Version 2.0.
OMG, 2010. Disponível em: <
http://www.omg.org/spec/BPMN/2.0
>. Acesso em:
13/05/10.
__________. UML Extension for Business Modeling. v1.1. OMG, 1997.
Disponível em: <FTP://ftp.omg.org/pub/docs/ad/97-08-07.pdf>. Acesso em:
15/05/10.
OWEN, Martin; RAJ, Jog. BPMN and Business Process Management:
Introduction to the new business process modeling standard, 2003. Popkin
Software. Disponível em: http://www.bmpn.org. Acesso em 20/01/2010.
PRESSMAN, Roger S. Engenharia de Software. Editora McGraw Hill do Brasil.
6ª ed. São Paulo, 2006.
REIS, Glauco dos Santos. Modelagem de processos de negócios com BPMN
– curso completo. São Paulo: Editora PortalBPM Ltda, 2008.
SAGAN, Carl. O mundo assombrado pelos demônios: a ciência vista como
uma vela no escuro. São Paulo: Companhia das Letras, 2006.
99
SANTOS, A. G.; CRUZ, G. M.; SANTANA, M. R. Modelagem de processos de
negócio para instâncias governamentais, 2006. Monografia de Conclusão do
Programa Residência em Software como foco em Governo Eletrônico. Disponível
em: http://www.residencia.dcc.ufba.br. Acesso em 20/01/2010.
SCHEDLBAUER, Martin J. The Art of Business Process Modeling: the
business analyst´s guide to process modeling with UML & BPMN. Sudbury,
Massachusetts: The Cathris Group, 2010.
SMITH, Howard; FINGAR, Peter. IT Doesn't Matter – Business Process Do. 1
a
edição, Tampa, Florida, USA: Meghan-Kiffer Press, 2003.
STANDISH GROUP International Inc. Extreme Chaos. 2001.
WIEGERS, Karl E. When Telepathy Won´t Do: Requirements Engineering Key
Practices. Cutter IT Journal, vol. 13, no. 5 (Maio 2000).
__________. More About Software Requirements: Thorny Issues and
Practical Advice. Redmond, Washington: Microsoft Press, a Division of Microsoft
Corporation, 2006.
WHITE, Stephen A. Introduction to BPMN, 2004a. IBM Corporation. Disponível
em: http://www.bpmn.org. Acesso em 20/01/2010.
__________. Process Modeling Notations and Workflow Patterns, 2004b.
Business Process Trends – BPTrends: Workflow Handbook. Disponível em
http://www.bptrends.com. Acesso em 07/06/2010.
100
WHITE, Stephen A.; MIERS, Derek. BPMN Modeling and Reference Guide:
understanding and using BPMN. Florida: Future Strategies Inc., Book Division,
2008.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
