Monografia bpm

CENTRO TECNOLÓGICO DA ZONA LESTE
FACULDADE DE TECNOLOGIA DA ZONA LESTE

RAFAEL RAYATO INAZAWA

A APLICAÇÃO DO BPM PARA AUTOMAÇÃO DE
PROCESSOS DE NEGÓCIO NAS ORGANIZAÇÕES
ESTUDO DE CASO: PROJETO NEW_RCMS

São Paulo
2009



A APLICAÇÃO DO BPM PARA AUTOMAÇÃO DE
PROCESSOS DE NEGÓCIO NAS ORGANIZAÇÕES

Monografia apresentada no curso de
Tecnologia em Informática ênfase em gestão
de negócios na FATEC ZL como
requerimento parcial para obtenção do Título
de Tecnólogo em Informática ênfase em
gestão de negócios

Orientador: Prof. Msc. Wilson Vendramel

São Paulo
2009

Inazawa, Rafael Rayato
A Aplicação do BPM para Automação de Processos de Negócio
nas Organizações. Estudo de Caso: PROJETO NEW_RCMS /Rafael
Rayato Inazawa– São Paulo, SP : [s.n], 2009.
111 f.

Orientador: Wilson Vendramel.
Trabalho de Conclusão de Curso (Tecnólogo) – Faculdade de
Tecnologia da Zona Leste.

1. Gestão do processo de negócio. 2. Arquitetura orientada a
serviços. I. Vendramel, Wilson. II. Faculdade de Tecnologia da
Zona Leste.



A APLICAÇÃO DO BPM PARA AUTOMAÇÃO DE PROCESSOS DE
NEGÓCIO NAS ORGANIZAÇÕES

Monografia apresentada no curso de
Tecnologia em Informática com ênfase em
gestão de Negócios na FATEC ZL como
requerido parcial para obter o Título de
Tecnólogo em Informática com ênfase em
gestão de Negócios.

COMISSÃO EXAMINADORA

_________________________________________
Prof. Msc. Wilson Vendramel
Faculdade de Tecnologia da Z/L

____________________________________
Prof. Msc. Ricardo Satoshi Oyakawa
Faculdade de Tecnologia da Z/L

____________________________________
Esp. Marco Aurélio Aloise Filho

São Paulo, ___ de _____________ de 2009.

DEDICATÓRIA

A Deus, aos meus pais, minha
namorada e aos meus amigos...
companheiros de todas as horas...

AGRADECIMENTOS

À minha família e namorada pelo apoio e incentivo a esta jornada.

Aos meus amigos, pela força e pela vibração em relação a esta jornada.

Ao Prof. Msc. Orientador Wilson Vendramel, pela sua valorosa orientação e um dos

grandes responsáveis pelo desenvolvimento e finalização deste trabalho.

Aos meus colegas de trabalho pela colaboração e incentivo.

Aos colegas de curso, pela batalha a qual vencemos.

Aos que colaboraram e não impediram a finalização deste estudo.

“Cabe ao ser humano dedicar o
máximo de si em tudo o que fizer,
nas circuntâncias em que se
encontra, neste exato momento, deve
empenhar-se de corpo e alma com
total seriedade sem se deixar
influenciar pelos ventos do elogio ou
da censura..."

Daisaku Ikeda

INAZAWA, Rafael Rayato. A Aplicação do BPM para automação de Processos de
Negócio nas Organizações – Estudo de Caso: PROJETO NEW_RCMS. 2009. 111 f.
Trabalho de Conclusão de Curso (Tecnólogo) – Faculdade de Tecnologia da Zona
Leste, São Paulo, SP.

RESUMO

As organizações em um mercado cada vez mais competitivo são constantemente
desafiadas a produzirem melhores resultados com menor custo, desenvolverem
produtos e serviços baseados em um ciclo de vida mais curto e se relacionarem de
forma mais personalizada e integrada com seus clientes, fornecedores e parceiros. As
organizações devem ser capazes de melhorar seus processos de negócio e sua
comunicação com a área de TI, da qual dependem para viabilizar seus objetivos e
estratégias, atualmente buscam melhorar seus processos de negócio e alinhá-los junto
com a TI, essa sinergia torna os processos das empresas flexíveis e resilientes frente a
um novo tipo de mercado global. É necessária a aplicação de modelos de gestão nas
áreas estratégicas da empresa para que se tornem possíveis a representação do
ambiente de negócio e o uso de uma arquitetura flexível, dinâmica e adaptável (SOA –
Service-Oriented Architecture) possibilitam uma visão sistêmica de toda a organização.
Desta maneira, este trabalho foca analisar a implantação do BPM (Business Process
Management) nas corporações.

Palavras-chave: Arquitetura Orientada a Serviços, Processo de Negócio, BPM.

INAZAWA, Rafael Rayato. The Implementation of BPM for process automation in
Business Organizations – Case Study: PROJECT NEW_RCMS. Conclusion Course
(Technologist) – Faculdade de Tecnologia da Zona Leste, São Paulo, SP.

ABSTRACT

The organization in a market increasingly competitive environment are constantly
challenged to produce better results at lower costs, develop products and services
based on a life cycle shorter and relate in a more customized and integrated with its
customers, suppliers and partners. Organizations must be able to improve their business
processes and their communication with the IT area, upon which to put its objectives
and strategies currently seeking to improve their business processes and align them
with IT, this synergy makes business processes flexible and resilient in the face of a new
kind of global market. It is necessary to apply management models in the strategic areas
of the company to become possible to represent the business environment and the use
of a flexible, dynamic and adaptable (SOA - Service-Oriented Architecture) provide a
systemic view of the entire organization . Thus, this work focuses on analyzing the
deployment of BPM (Business Process Management) in corporations.

Key-Words: Service-Oriented Architecture, business process, BPM.

LISTA DE ABREVIATURAS

BAM Business Activity Monitoring

BI Business Intelligence

BPD Business Process Diagram

BPEL Business Process Execution Language

BPM Business Process Management

BPMI Business Process Management Initiative

BPMN Business Process Modeling Notation

BPMS Business Process Management Systems

BPR Business Process Reengineering

BSC Balanced Scorecard

FAST Fast Analysis Solution Technique

KPI Key Performance Indicators

OASIS Organization for the Advancement of Structured

Information Standards

PMI Project Management Institute

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SWOT Strengths, Weakness, Opportunities and Threats

TI Tecnologia da Informação

UDDI Universal Description, Discovery and Integration

WfMC Workflow Management Coalition

WfMSs Workflow Management Systems

WS Web Service

WS-BPEL Web Service Business Process Execution Language

WSDL Web Services Definition Language

WSFL Web Service Flow Language

XML eXtensible Markup Language

LISTA DE FIGURAS

Figura 1 – Ilustração de um processo de negócio...........................................................24

Figura 2 – Visão Sistêmica dos Processos.....................................................................25

Figura 3 – Ciclo de BPM..................................................................................................28

Figura 4 – Exemplo de Visão Global de Processos de compra......................................32

Figura 5 - Monitoração de Processos de Negócio com o Websphere Business MQ......41

Figura 6 – Analisando os KPIs (Indicadores Chave de Desempenho)...........................42

Figura 7 – Visualização gráfica dos indicadores.............................................................43

Figura 8 – Exemplo de relatório analítico........................................................................44

Figura 9 – Automação do ciclo de vida de processo de negócios..................................47

Figura 10 – Demonstração das Atividades e Decisões...................................................48

Figura 11 – Componentes da arquitetura SOA...............................................................58

Figura 12 – Exemplo de Aplicação Frontend..................................................................59

Figura 13 – Composição de um Serviço na Arquitetura SOA.........................................60

Figura 14 – Composição de Serviços..............................................................................65

Figura 15 – Orquestração e Coreografia.........................................................................67

Figura 16 – Exemplo de processo de orquestração de serviços.....................................69

Figura 17 – Exemplo de Coreografia de serviços...........................................................69

Figura 18 – Fluxo de Processo BPEL.............................................................................71

Figura 19 – Estrutura básica de uma especificação BPEL.............................................73

Figura 20 – Interface Gráfica modelada pelo BPEL através da ferramenta Eclipse.......75

Figura 21 – Camadas de Abstração de SOA..................................................................76

Figura 22 – O negócio e os domínios da lógica da aplicação.........................................77

Figura 23 – As três principais camadas de serviços.......................................................78

Figura 24 – Serviços utilitários da camada de serviço de aplicação...............................79

Figura 25 – Serviço ServicoSalvarGrupo nas camadas de Aplicação e Negócios.........81

Figura 26 – Ciclos de Vida de SOA.................................................................................83

Figura 27 – Atividades do ciclo de vida com os serviços no ambiente SOA...................86

Figura 28 – Arquitetura Web Services.............................................................................89

Figura 29 – Arquitetura de todos os sistemas do departamento.....................................93

Figura 30 – Processo modelado (As Is)..........................................................................96

Figura 31 – Processo modelado (To Be).......................................................................100

Figura 32 – Interface da aplicação no PDA...................................................................102

Figura 33 – Arquitetura tecnológica e suas aplicações após a implantação do BPM...103

LISTA DE QUADROS

Quadro 1 – Atividades básicas de BPEL.........................................................................72

Quadro 2 – Atividades Estruturadas de BPEL................................................................72

Quadro 3 – Processo de atendimento (As Is).................................................................94

Quadro 4 – Processo de atendimento (To Be)................................................................98

Quadro 5 – Comparativo entre antes e depois da implantação do BPM......................103

LISTA DE TABELAS

Tabela 1 – Objetos de Fluxo...........................................................................................50

Tabela 2 – Objetos de Conexão......................................................................................51

Tabela 3 – Raias (Swimlanes).........................................................................................52

Tabela 4 – Artefatos........................................................................................................53

Tabela 5 – Principais Características da Arquitetura SOA..............................................57

Tabela 6 – Características da Concepção de Serviços...................................................61

Tabela 7 - Fases do Ciclo de Vida do Serviço................................................................63

Tabela 8 – Características do Barramento de Serviços..................................................64

Tabela 9 – Principais sistemas do Service Desk.............................................................92

SUMÁRIO

1. INTRODUÇÃO............................................................................................................19

2. GESTÃO DE PROCESSOS DE NEGÓCIO................................................................22

2.1 Processos de negócio..........................................................................................23

2.1.1 Fluxo de Trabalho de Pessoas..........................................................................25

2.1.2 Características de Processos nas Organizações..............................................26

2.2 Ciclo do Gerenciamento de Processo de Negócio...............................................27

2.2.1 Planejamento do BPM.......................................................................................29

2.2.1.1. Visão Global de Processos............................................................................31

2.2.2 Modelagem de processos..................................................................................32

2.2.2.1 Modelagem de estado atual (As Is)................................................................34

2.2.2.2 Modelagem de estado futuro (To Be).............................................................36

2.2.2.3 Ferramenta e metodologia de modelagem do processo de negócio..............38

2.2.2.4 Otimização de Processos e Solução Imediata de Problemas........................38

2.2.3 Execução de Processos.....................................................................................39

2.2.4 Controle e Análise de Dados.............................................................................40

2.3 Conformidades......................................................................................................44

2.4 Sistemas de Gestão de Processos de Negócio (BPMS)......................................45

2.4.1 Ciclo de Vida de BPMS......................................................................................46

2.5 BPMN e os elementos de BPD.............................................................................48

2.5.1 Objetos de Fluxo (Flow Objects)........................................................................49

2.5.2 Objetos de Conexão..........................................................................................51

2.5.3 Raias (Swimlanes).............................................................................................52

2.5.4 Artefatos.............................................................................................................53

3. ARQUITETURA ORIENTADA A SERVIÇOS..............................................................54

3.1 Características da Arquitetura Orientada a Serviços............................................56

3.2 Componentes SOA...............................................................................................58

3.2.1 Aplicação Frontend............................................................................................59

3.2.2 Serviços.............................................................................................................60

3.2.3 Ciclo de vida dos serviços..................................................................................62

3.2.4 Repositório de serviços......................................................................................63

3.2.5 Barramento de serviços.....................................................................................64

3.3 Composição de serviços.......................................................................................65

3.3.1 Orquestração.....................................................................................................67

3.3.2 Coreografia........................................................................................................68

3.3.3 BPEL..................................................................................................................70

3.4 Camadas de abstração.........................................................................................75

3.4.1 Camada corporativa...........................................................................................76

3.4.2 Camada de processos.......................................................................................76

3.4.3 Camada de serviços..........................................................................................77

3.4.3.1 Camada de serviço de aplicação....................................................................78

3.4.3.2 Camada de serviços de negócio.....................................................................80

3.4.3.3 Camada de serviço de orquestração..............................................................82

3.4.4 Camada de Componentes.................................................................................82

3.4.5 Camada de Objetos...........................................................................................82

3.5 Ciclo de vida SOA.................................................................................................83

3.5.1 Estratégia...........................................................................................................84

3.5.1.1 Bottom-up........................................................................................................84

3.5.1.2 Top-down……………………………………………………………………………85

3.5.2 Modelagem…………………………………………………………………………....85

3.5.3 Implementação……………………………………………………………………….86

3.5.4 Monitoramento (Business Activity Monitoring)...................................................86

3.6 Web Services........................................................................................................87

4. ESTUDO DE CASO....................................................................................................89

4.1 Descrição do ambiente de pesquisa.....................................................................89

4.2 Implantação do BPM na organização...................................................................89

4.3 Modelagem do processo de negócio de Atendimento de chamados...................91

4.4 Resultados obtidos..............................................................................................101

5. CONSIDERAÇÕES FINAIS......................................................................................105

REFERÊNCIAS.............................................................................................................107

GLOSSÁRIO.................................................................................................................110

19

1. INTRODUÇÃO

Melhoria Contínua é um termo bem conhecido para as organizações que
desejam se manter competitivas no mercado. Hoje com a disposição dos mais
variados modelos, métodos e processos de Gestão, algumas têm conseguido
alcançar os principais objetivos que são: manter crescimento, reduzir gastos e
aumentar lucros.

As organizações que conseguem alcançar suas metas e objetivos em geral
são as que possuem processos internos e externos bem definidos, estão sempre em
constante mudança organizacional e se adaptam rapidamente a elas, geralmente
possuem uma ótima infra-estrutura de TI alinhada ao seu processo de negócio, isso
as tornam empresas flexíveis.

A maior dificuldade das empresas é alinhar os seus processos de negócio a
TI, criar uma solução tecnológica adequada que agregue valor ao seu negócio
possibilita a empresa ter uma forte flexibilidade e interoperabilidade para
acompanhar as constantes mudanças de processos e informações.

A aplicação do Business Process Management (BPM) permite mapear os
processos organizacionais da empresa, buscando a integração funcional e
proporcionando maior agilidade nas atividades que envolvem pessoas, tarefas,
máquinas, aplicações de software e outros elementos coordenados para atingir os
objetivos do negócio. Com a utilização de notação de modelagem de processos
como Business Process Management Notation (BPMN), os analistas de negócio
podem documentar os modelos criados e entender melhor os processos da empresa
em diferentes níveis, facilitando deste modo o entendimento dos participantes dos
processos de negócio.

Da necessidade de integração entre diferentes sistemas e a disseminação da
Web surge a Arquitetura Orientada a Serviços – SOA (Service-Oriented Architecture)
que veio com o objetivo de integrar serviços fracamente acoplados, possibilitando o
reuso, modificação e a aplicação em diferentes áreas internas ou externas da
empresa. Atrás de inovação, as empresas vêem cada vez mais demonstrando

20

interesse em Web Services, pois é uma tecnologia atual baseada na Web capaz de
integrar serviços utilizando tecnologia XML (eXtensible Markup Language). De certa
forma essa tecnologia pode sanar boa parte dos problemas de uma organização que
utiliza sistemas diferentes, fazendo com que eles troquem informações, com isso a
empresa pode integrar seus processos a esses sistemas independentes de
plataforma ou linguagem de programação.

Este trabalho tem como objetivo demonstrar os passos necessários para uma
organização implementar o BPM, por meio da modelagem de seus processos,
visando promover a flexibilidade, Interoperabilidade e a reusabilidade de
componentes na organização.

A Justificativa para o desenvolvimento deste trabalho é demonstrar que o
Business Process Management é de extrema importância para as organizações e
que suas contribuições agregam mais valor ao negócio tornando a empresa mais
competitiva no mercado.

A metodologia deste estudo será feita a partir de pesquisa bibliográfica e
também de um estudo de caso que apresenta a modelagem de um processo de
negócio, a fim de demonstrar as principais atividades e características da gestão de
processos de negócio por meio do BPM.

O estudo de caso consiste em analisar um determinado processo de um
serviço oferecido por uma organização, e a utilização de uma ferramenta de
modelagem de negócio (Bizagi Process Modeler), obtendo assim, a inserção,
desses processos no paradigma da orientação a serviços e gestão dos processos de
negócio.

O segundo capítulo aborda a gestão de processos de negócio, que é uma
disciplina de gestão estratégica, que sustenta a idéia de que podemos modelar um
negócio em termos de processos de sua finalidade que podem abranger tradicionais
organizações e fronteiras de sistemas. Ele envolve a descoberta, projeto e entrega
dos processos de negócio, fazendo com que todos os departamentos da
organização estejam alinhados com as metas e estratégias da corporação. Uma boa
gestão ainda permite um ciclo de melhoria contínua onde as organizações devem
estar aptas às constantes mudanças organizacionais em conjunto com a Tecnologia
da Informação para estarem melhor alinhadas com suas metas, estratégias e

21

objetivos.

O terceiro capítulo, aborda a arquitetura orientada a serviços que é uma
aproximação arquitetural para desenvolvimento de sistemas que constrói e distribui
serviços reutilizáveis e encapsulados prestados às empresas para que diferentes
aplicações possam compartilhá-los em um modo vagamente acoplado e altamente
inter-operável. A implementação desses serviços podem ser feitas independente da
plataforma ou linguagem de programação, utilizam protocolos padronizados para a
comunicação e troca de informações. Esses padrões tornam os serviços flexíveis e
reusáveis, podendo ser executados em computadores distribuídos geograficamente.
Essa arquitetura ainda permite a utilização de diversas outras tecnologias incluindo
os sistemas legados da organização, mantendo a interoperabilidade entre os
diversos sistemas da organização.

22

2. GESTÃO DE PROCESSOS DE NEGÓCIO

Segundo a BPMN (apud BALDAM et al., 2008, p.19), a gestão por processos
de negócios envolve a descoberta, projeto e entrega de processos de negócios.
Adicionalmente, o BPM inclui o controle executivo, administrativo e supervisório
desses processos.

A gestão por processos de negócios é a disciplina de modelar, automatizar,
gerenciar e otimizar processos de negócios através do seu ciclo de vida com o
propósito de lhes agregar valor (KHAN apud OLIVEIRA, 2008, p. 19),

O BPM tem vários predecessores como o Gerenciamento de Qualidade Total
(TQM, do inglês Total Quality Management) e de um novo paradigma que surgiu em
meados dos anos 90: Business Process Reengineering (BPR), que prometia
aumentar o desempenho dos negócios em um período relativamente curto pela
reengenharia completa dos processos de negócios existentes. O BPR teve um
grande sucesso inicial, mas o movimento teve um declínio que levou ao fracasso
vários projetos. O BPM surgia 10 anos mais tarde e trazia de volta a gestão por
processos de negócios com soluções que atendiam, através da evolução dos fluxos
de trabalho, a interoperabilidade de processos mais complexos e distribuídos
fisicamente.

Com a integração e aperfeiçoamento dos processos, de forma que as metas e
estratégias estejam alinhadas com a corporação, a gestão por processos pode
trazer eficiência e permitir vincular a atividade das diferentes funções internas aos
fatores competitivos da organização.

No entanto, se o processo como um todo não for corretamente analisado e
avaliado, as correntes funções tornam-se um grupo de pequenas unidades de
negócios isoladas, as quais são avaliadas indevidamente por padrões não
condizentes com as necessidades globais da empresa. O acontecimento mais
comum é o de o organograma receber uma maior atenção do que o próprio negócio.

O termo BPM, Business Process Management, é largamente utilizado pelos
autores para referenciar a automação dos processos, que uma vez passando por

23

esse processo de automatização, pode ser gerenciado posteriormente, por meio de
ferramentas de software.

Já no ambiente de negócios, os executivos se referem à gestão de processos
de negócios de uma forma mais genérica, com uma visão de gerenciamento
humano melhor organizado diante dos negócios da corporação.

2.1 Processos de negócio

Processo de Negócio é a descrição de um conjunto de atividades que
envolvem pessoas, tarefas, máquinas, softwares e outros elementos coordenados
para atingir objetivos de negócio.

“É um fenômeno que ocorre dentro das empresas. Compreende um
conjunto de atividades realizadas na empresa, associadas às informações
que manipula, utilizando os recursos e a organização da empresa. Forma
uma unidade coesa e deve ser focalizado em um tipo de negócio, que
normalmente está direcionado a um determinado mercado/cliente, com
fornecedores bem definidos (Rozenfeld apud Baldam, et al.,2008, p.196).”

Segundo Moreira (2007, p. 30-31) um processo de negócio pode ser visto
como um conjunto estruturado de tarefas que contribuem coletivamente para que
uma organização atinja os seus objetivos. Os processos de negócio são a base
operativa de uma empresa e fazem parte da cultura desta e o êxito da mesma
depende fortemente da eficiência com que eles são administrados. Assim sendo,
uma má administração dos processos traz altos custos, baixa produtividade e
inadequados tempos de resposta, tanto frente às oportunidades como às ameaças.
A figura 01 exemplifica um processo de negócio.

24

Figura 1 – Ilustração de um processo de negócio.
Fonte: GARCIA e TOLEDO (2007).

A Figura 2 mostra o esquema geral de funcionamento de processos nas
organizações, ela demonstra o que está diretamente envolvido em um processo em
particular (entradas, saídas, recurso e controles), inclusive as influências externas
oriundas do contexto da organização, que podem alterar o modo de funcionamento
do processo até mesmo os produtos produzidos pelo processo (BALDAM et al,
2008, p.21).

25

Figura 2 – Visão Sistêmica dos Processos.
Fonte: BALDAM (2008. p.21).

2.1.1 Fluxo de trabalho de pessoas

Quando as atividades do processo exigem ações ou pareceres de pessoas,
normalmente categoriza-se o processo como de “longa duração”, pois o elemento
humano pode demorar em completar a tarefa. Para os mecanismos de BPM darem
suporte a interação humana, não só devem armazenar e controlar estes processos
de longa duração, mas também prover funcionalidades como:

• Identificação do responsável pela tarefa: Normalmente, quando se
desenha um processo, assinala-se um papel (uma função como
gerente de agência, analista de crédito) às tarefas, ao invés de uma

26

identificação direta da pessoa (como seria um código funcional). Isto é
importante para que os processos sejam independentes das pessoas,
as quais podem sair da empresa ou mudar de função, e também
porque para cada instância do processo o recurso (pessoa) pode ser
diferente. Os papéis podem ser definidos no momento de criação dos
fluxos, durante sua instalação no ambiente, ou mesmo durante sua
execução (KLOPPMANN apud BENEDETE, 2007, p. 31);

• Envio da tarefa para a pessoa responsável e apoio à interação: Depois
de identificado, o responsável pela tarefa tem que ser comunicado
criando itens em uma relação de tarefas que deve ser periodicamente
consultada pela pessoa. As ferramentas de BPM não só avisam o
responsável pela tarefa, mas também fornecem telas onde o contexto
(informações necessárias para entender, executar uma tarefa ou tomar
uma decisão) da atividade é apresentado;

• Tratamento de exceções: Caso uma pessoa demore muito para realizar
uma tarefa, ou caso fique ausente, os mecanismos de fluxo de trabalho
devem ser capazes de encontrar um substituto ou escalar o assunto
para um supervisor tomar a ação necessária.

2.1.2 Características dos processos nas organizações

Segundo Baldam (2008, p. 24), à medida que a visão de processos se
difunde, as formas contemporâneas de racionalização tendem a ver as organizações
como um feixe de processos, e ele classifica esses feixes de processos da seguinte
maneira:

• Transfuncionais: pois atravessam departamentos;

27

• Intrafuncionais: pois pertencem a um departamento ou setor
específico.

Conhecendo a visão do processo, é possível definir o que deve ser feito e
como fazê-lo, não em cima das atividades dos departamentos, mas sim, atividades
que agregam valor a organização independente do departamento que executará o
processo. Deste modo, os processos tramitariam entre departamentos conforme o
serviço que ele necessitar realizar (BALDAM et al., 2008, p. 24).

Porém, com estas características de processos, os departamentos ainda
seriam úteis nas organizações, devido a sua funcionalidade em situações gerenciais.

2.2 Ciclo de Gerenciamento de Processo de Negócio

A descrição das etapas do ciclo de gerenciamento de negócios, segundo
Baldam (2008, p. 56), podem ser aplicadas em um processo específico da
organização ou em processos de negócios onde existe uma gestão da integração
destes já presente, podendo ser utilizada também em um estado de gestão que se
pretende chegar futuramente. A figura 3 ilustra o ciclo do BPM.

28

Figura 3 – Ciclo de BPM
Fonte: BALDAM (2008, p.56)

• Planejamento do BPM: É onde as atividades de BPM que contribuirão
para o alcance de metas organizacionais (desde as estratégicas até
as operacionais) serão definidas, como verificação dos pontos de
falha nos processos que causam danos a organização (financeiros,
imagem, prazos e satisfação de clientes), definição de planos de ação
para implantação, definição dos processos que necessitam de ação
imediata;

• Modelagem e otimização de processos: atividades que permitem
gerar informações sobre o processo atual (As Is) e/ou sobre a
proposta de processo futuro (To Be); documentar os processos;
prover dados de integração entre processos, empregar metodologias
para aperfeiçoar os processos, fazer inovações, simulações e

29

redesenhos; adotar as melhores práticas de modelos de referência;
gerar especificações para implementação, para configuração e
customização (caso o processo não esteja em uso), para execução e
controle;

• Execução de processos: atividades que garantirão a implementação e
a execução dos processos, como implantação de planos de
transferência de tecnologia, treinamentos, ajuste de equipamentos e
softwares (se necessários), acompanhamento de processo
implantado, monitoria e controle da execução das instâncias de
processo;

• Controle e análise de dados: atividades relacionadas ao controle geral
do processo (por meio de diversos recursos, como o uso de
indicadores, BAM, BI, BSC, métodos estatísticos, diagramas de causa
e efeito), gerando informações que posteriormente realimentarão as
atividades de otimização e planejamento.

2.2.1 Planejamento do BPM

As atividades desempenhadas na etapa de planejamento do BPM são
descritas por Baldam (2008, p. 63):

• Definir os processos-chave para a estratégia da organização. Usando
metodologias conhecidas (Cadeia de Valor, BSC, SWOT), é possível
identificar em quais processos a organização tem mais
potencialidade, os pontos que precisam melhorar, quais as ameaças
e oportunidades do mercado, os indicadores que serão usados para
medir o desempenho de seus processos, a meta para esses
indicadores, entre outros;

30

• Levantar os principais pontos fracos dos processos em uso na
organização;

• Identificar as oportunidades (novas abordagens, produtos ou serviços)
que possam ser fornecidas pela organização, levando a preparar os
processos que permitirão sua entrega;

• Perceber que todos os processos podem passar por inovação;

• Preparar, no todo ou em parte, a visão global de processos;

• Classificar os processos que mereçam atenção em ordem de
prioridade;

• Identificar ao time de projetos de processos e às áreas envolvidas as
diretrizes e especificações básicas desejadas a partir do
planejamento;

• Planejar e controlar as tarefas necessárias à implementação.

Os gestores de processo não são os únicos responsáveis pelas atividades do
planejamento. É importante a participação de gestores de outras áreas da
organização, o apoio desses gestores e o seu comprometimento com o BPM de
forma contínua contribuem para o êxito na gestão por processos, caso isso não
ocorra, surgirão processos isolados sem uma visão global dos processos. No
momento da implantação, é fundamental a participação efetiva do gestor da
organização, a fim de evitar possíveis barreiras e desentendimentos, entre os
funcionários dos diversos setores e áreas envolvidas.

De acordo com Baldam (2008, p. 66) não são apenas os processos que
apresentam problemas (qualidade, custo, prazo, etc.) que passarão por otimização,
outros processos que estejam funcionando perfeitamente podem ser otimizados
buscando inovação ou melhoria contínua desse processo.

31

Algumas atividades surgem de imediato e mesmo que a necessidade desse
processo não tenha sido detectada no planejamento estratégico, sua implantação
pode ser imediata.

2.2.1.1 Visão global de processos

Considerado um ponto de controvérsia que precede o BPM, segundo Baldam
(2008, p. 66), a Visão Global de Processos é fundamental numa Gestão Integrada
dos Processos sendo necessário considerar:

• Uma Visão Global dos Processos ajuda a compreensão do
funcionamento da empresa;

• Fazê-lo por completo é complexo e pode levar mais tempo que o
benefício direto e imediato por ele gerado;

• É relativamente fácil fazer o diagrama apenas em macro processo e
posicionar o processo que se deseja modelar de imediato;

• O diagrama pode ser efetivamente feito em etapas e melhorando na
medida em que é usado em projetos pontuais de BPM, alinhando
sempre os projetos ao diagrama macro;

• Para muitas das atividades realizadas, há referenciais que ajudam a
construir os diagramas próprios à organização.

32

Figura 4 – Exemplo de Visão Global de Processos de compra.
Fonte: Adaptado de BALDAM (2008, p.69).

2.2.2 Modelagem de processos

A modelagem de processos de negócio é uma das fases do ciclo de vida
SOA, ela é 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 (CRUZ apud OLIVEIRA 2008, p. 36).

Nenhum modelo corresponde exatamente à realidade; todos apenas a
representam, de um modo que parecerá mais adequado ou menos
adequado, de acordo com o contexto, os atores e as finalidades da
modelagem (VALLE apud BALDAM et al., 2008, p. 74).

Segundo Baldam (2008, p. 74), é possível utilizar os modelos de processos
de negócios para:

• Discutir e compreender os processos;

• Apoiar a melhoria contínua (análise da eficiência e da eficácia);

• Simular alternativas;

33

• Treinar os operadores dos novos processos;

• Especificar os sistemas de informação que deverão suportar o negócio.

Nesta fase o processo é modelado em termos de atividades, regras,
participantes, interações e relacionamentos. O processo é estruturado em
atividades, que podem ser mapeadas como tarefas que são executadas por pessoas
ou sistemas internos ou externos à corporação. É realizada a validação ou a
simulação dos processos, através do uso de estimativas de tempo de execução e
custo, recursos requeridos pelas atividades e a probabilidade de ocorrência de
eventos.

Essa fase também inclui a definição das métricas de desempenho do
processo para que o analista de negócio possa avaliar o processo implantado e,
possivelmente, reestruturá-lo em função de oportunidades ou de outros motivos
(NADER apud OLIVEIRA, 2008, p. 36).

Os modelos de processo são constituídos de diagramas de fluxo de trabalho e
de textos auxiliares de forma a descrever cada passo do processo de negócio.
Havey (apud SOUZA, 2006, p. 23), afirma que o modelo de processo deve
representar de forma simples e intuitiva o fluxograma de atividades do processo
modelado. A modelagem deve ser realizada em dois níveis: de forma gráfica, com o
auxílio de ferramenta de desenho de processos e com um modelo executável,
utilizado na automação desses processos através dos sistemas de gestão de fluxo
de trabalho.

Durante a descrição de um diagrama de negócio, os eventuais problemas
relacionados ao processo que ele representa são documentados e para cada um
são propostas possibilidades de melhorias. Os principais conceitos envolvidos, as
regras e os recursos utilizados ou produzidos por cada processo são identificados e
modelados como entidades de negócio.

34

2.2.2.1 Modelagem de estado atual (As Is)

Por meio desta modelagem é possível entender o processo existente na
organização e identificar suas falhas. Espera-se, desta forma, obter métricas
suficientes a fim de estabelecer uma base na fase seguinte da análise e
desempenho do processo atual, que permita identificar as melhorias proporcionadas
pelo estado futuro, assim como uma documentação dos prós e contras e do
desempenho do processo.

Na modelagem do estado atual do processo, vários tipos de interações entre
os envolvidos no processo podem existir, incluindo atividades de colaboração e
reuniões. Diversas técnicas podem ser utilizadas na modelagem de processos atual:
técnica de entrevistas, brainstorm, JAD, métodos simplificados de modelagem com
papel, entre outras.

Baldam (et al., 2008, p. 76-77) aponta como sendo relevante as seguintes
etapas para a modelagem do processo atual:

• Preparação do projeto de modelagem: envolve as diversas atividades
de compreensão de escopo (qual processo será modelado,
propósitos, métricas, verificar alinhamento estratégico, prazos e
entregáveis), composição da equipe envolvida, definição de
documentação necessária, planejamento das reuniões (pessoas
envolvidas, datas, agenda, infra-estrutura necessária à reunião),
consulta à documentação do processo, ou que rege o processo
previamente disponível (normas, leis, regulamentos e referências);

• Entrevista e coleta de dados com usuários (especialista de negócio e
facilitadores): podem incluir entrevistas (em aberto ou dirigidas),
criação conjunta da lista de esquema gráfico de atividades, descrição
de informações que comporão o processo e criação de atas de
reunião;

35

• Documentação do processo: será construído o modelo, conforme
metodologia previamente definida. Além dos componentes do
processo propriamente dito, outras informações serão necessárias,
como controle de versão de documentação, publicação, referências e
escopo. Nessa fase é comum o uso intensivo de software de apoio à
modelagem;

• Validade do processo: deve-se testar o modelo em uma instância real
do processo, para verificar se realmente está coerente. Em alguns
casos, a validação é impossível porque o tempo de processamento é
muito longo, ou porque exigiria um grande deslocamento, ou seu
custo seria alto demais. Por exemplo, um processo de compra por
licitação pública, quando envolve grandes somas, pode se
desenvolver por meses;

• Correção de documentação: são corrigidas eventuais distorções
percebidas durante a validação do processo.

Segundo Tachizawa e Scaico (apud Pak, 2006), uma análise do processo
atual deve verificar se os objetivos são atendidos, se as atividades estão bem
relacionadas, se os recursos alocados são suficientes e se as interfaces entre
gerências estão sendo previstas e administradas. Também é importante verificar a
consistência das tarefas utilizadas, evitando a redundância das mesmas.

Como Resultado da modelagem do estado atual JESTON & NELIS (apud
BALDAM et al., 2008, p. 77), espera-se obter:

• Modelo do processo atualmente em uso;

• Métricas apropriadas e suficientes para estabelecer uma base para
futuras medidas de melhorias de processos, priorização e seleção na
fase seguinte de análise do To Be;

36

• Métricas e documentação do atual desempenho do processo;

• Documentação do que trabalha bem e o que precisa funcionar melhor;

• Identificação dos itens mais significativos e de ganho rápido que podem
ser rapidamente implementados;

• Um relatório dessa fase.

2.2.2.2 Modelagem de estado futuro (To Be)

Nessa fase pretende-se criar um ambiente de discussão entre partes 40
envolvidas de forma a melhorar o processo em questão, inová-lo ou mesmo
questionar se ele se faz necessário e se agrega valor à organização (BALDAM et al.,
2008, p. 83). Entre as modelagens do estado futuro mais comuns podem ser citadas:

• Melhoria continua;

• FAST;

• Benchmarking;

• Adoção de melhores práticas e processos comodizados (transformá-
los em commodities);

• Redesenho de processo;

• Inovação de processo.

O objetivo dessa etapa é definir a decisão a ser tomada em relação aos
processos identificados durante a modelagem do estado atual e seu realinhamento

37

com os objetivos e estratégias da organização. Se a decisão for redesenhar os
processos, será necessário desenvolver um novo modelo de processos com as
melhorias previstas para a situação atual identificada (SANTOS apud OLIVEIRA,
2008. P. 40).

Dentre os resultados a serem esperados (O´CONNELL, PYKE &
WHITEHEAD; JESTON & NELIS apud BALDAM et al., 2008, p.93) podem estar
incluídos:

• Redesenho do processo ou mesmo um novo processo;

• Documentação de suporte ao processo redesenhado ou novo
processo;

• Requerimentos de alto nível para as novas opções observadas;

• Modelos de simulação e detalhes de custos ABC;

• Confirmação de que as novas opções atendem às expectativas dos
envolvidos;

• Confirmação que está alinhado à estratégia;

• Um relatório das diferenças que precisam ser atendidas para cumprir
os requerimentos;

• Plano de desenvolvimento e treinamento da equipe;

• Relatório de impactos na organização e em outras esferas (ambiental,
social e etc.);

• Detalhes do plano de comunicação do novo processo.

38

2.2.2.3 Ferramenta e metodologia de modelagem do processo de negócio

Cummins (apud Souza, 2008, p. 47), a ferramenta de definição dos processos
deve ter as seguintes características:

• Ferramenta gráfica interativa: Os processos são exibidos graficamente,
e os elementos do processo são adicionados e conectados com edição
interativa drag-and-drop;

• Distinção visual de tipo de tarefas: O tipo de cada elemento de
processo deve ser identificável visualmente na representação gráfica
do processo.

Gráficos de fluxos e mapeamento de processos sempre foram de grande
utilidade para o homem, existindo desde o surgimento da simbologia como meio de
entendimento e comunicação.

2.2.2.4 Otimização de Processos e Solução Imediata de Problemas

Não são apenas os processos que apresentam problemas (qualidade, custo,
prazo e visibilidade da marca) que passarão por otimização (inovação, redesenho e
melhoria contínua). Um processo de atendimento ao cliente, por exemplo, pode ser
completamente migrado para a Internet, ainda que esteja funcionando corretamente
na verdade, para minimizar custos e prazos de atendimento, pode até ser mesmo
desdobrado (atendimento via Internet para a maioria dos clientes e atendimento
telefônico para exceções), aumentando assim o número de processos (BALDAM et
al., 2008, p. 66).

39

De acordo com Baldam (2008, p. 66), algumas atividades emergem de
imediato, quando surgem situações como novos marcos, problemas de produção ou
qualidade, impedindo entrega ao cliente, concorrência que lança produtos mais
competitivos etc. Ainda que a necessidade desses processos não tenha sido
detectada no Planejamento Estratégico anual (o que não quer dizer que não estejam
alinhados com ele), sua implantação pode ser imediata.

2.2.3 Execução de processos

Nessa fase as definições da fase de modelagem do processo serão
executadas. Os processos serão testados pelos usuários, que indicarão os impactos
positivos e negativos da implementação desses.

Burlton (apud BALDAM et al., 2008, p. 94) sugere as seguintes atividades
para a execução de processos:

• Preparar o teste da nova solução;

• Completar testes e pilotos;

• Atualizar os entregáveis;

• Gerenciar o plano de transferência de tecnologia;

• Desenvolver os planos da execução da nova solução;

• Treinar a equipe;

• Desenvolver e executar os programas de marketing da solução;

• Realizar as mudanças no processo atual ou elaborara um novo
processo.

É também nesta fase, que ocorre a configuração do repositório do BPMS que
suportará o novo processo e a implantação e configuração das aplicações externas

40

que interagem com o processo. Um BPMS é responsável por manter os contextos
de execução dos processos, que inclui a atividade que está em execução, valores
de variáveis, contextos de sub-processos, logs. Ele deve facilitar a integração com
um conjunto de outras plataformas que executam os sistemas externos.

2.2.4 Controle e análise de dados

São geradas as informações sobre o comportamento dos processos, esses
dados são comparados e utilizados para montar indicadores gerais que permitem
avaliar o processo. Algumas técnicas e tecnologias aplicáveis ao controle e análise
dos dados de instâncias de processos, tais como BSC, BI, permitem uma melhor
visão do desempenho geral e apontam se a organização está alcançando seus
objetivos ou se é necessário efetuar ajustes nos processos, nas metas ou mesmo na
estratégia da organização.

Na fase de análise, a medida do desempenho do processo provê informações
de melhorias operacionais. A partir de uma visão “fim-a-fim” do processo é possível
fazer uma análise top-down para determinar a influência de cada passo ou sub-
processo no resultado global. Para dar suporte a essa fase são utilizados os
sistemas BAM (Business Activity Monitoring), onde os processos são instrumentados
com sensores para monitorar suas atividades e variáveis. Um dashboard permite a
monitoração, análise e respostas aos eventos e às exceções que ocorrem em tempo
real.

Normalmente, após o desenvolvimento de aplicações e de sua implantação e
execução em ambiente de produção, pouco suporte é dado ao negócio para avaliar
se a solução implementada foi adequada ou se há potencial para melhores
resultados. BPM, ao contrário, foca na melhoria contínua dos processos de negócio,
e para tanto, provê mecanismos para que o negócio acompanhe o comportamento
dos processos e identifique falhas e oportunidades.

Podemos categorizar essa monitoração dos processos sob dois aspectos:

41

• Operacional: Neste caso, o objetivo da monitoração é acompanhar os
processos no nível do detalhe, ou seja, cada instância em execução.
Procura-se por exceções (se o processo ultrapassou limites de prazo,
custo, conclusão sem sucesso) possibilitando assim o negócio atuar
na correção da situação, priorizando o processo ou mesmo
contatando seus participantes;

• Analítica: Aqui, o objetivo é analisar o conjunto das execuções dos
processos, procurando por exceções recorrentes ou por melhores
estratégias e oportunidades para o negócio. É o momento de
comparar os resultados projetados com os realmente atingidos e
planejar ações de correção.

A monitoração operacional é baseada na situação dos processos em
execução, a qual normalmente é mantida em banco de dados do mecanismo de
execução de processos. A figura 5 mostra duas instâncias de um processo sendo
monitorados pela ferramenta WebSphere Business Monitor da IBM. Nesta
ferramenta podemos definir quais campos devem ser mostrados, o critério para
ordenação das linhas, e filtros, baseados em dados de negócio, para selecionar
apenas os processos que se deseja monitorar.

Figura 5 – Monitoração de Processos de Negócio com o Websphere Business MQ.
Fonte: www.ibm.com.br

42

Já a monitoração analítica é normalmente baseada na análise de eventos
gerados e armazenados pelo mecanismo de execução. A solução da IBM
anteriormente mencionada, por exemplo, de tempos em tempos copia os registros
de eventos para uma base de dados especializada em pesquisas analíticas (que faz
uso de conceitos associados a “Data Warehouse”, como cubos) de forma a permitir
consultas sofisticadas e pesadas sem prejudicar o desempenho do ambiente de
execução de processos.

Com base nos eventos, são gerados os KPI (“Key Performance Indicators” ou
Indicadores Chaves de Desempenho) e os totais (métricas) escolhidos no momento
de projeto dos fluxos. Os KPIs devem ser cuidadosamente escolhidos, pois devem
refletir os objetivos do negócio mais relevantes para o sucesso da empresa, e
devem permitir a identificação antecipada de problemas, possibilitando ações
corretivas.

A figura 6 mostra dois KPI definidos para um processo (percentual de
aprovação e duração do processo). Aos KPI são associados limites, de forma que
seja facilitada a identificação de inconformidades. No exemplo, o processo foi
planejado para durar no máximo três dias, mas em ambiente real está levando mais
de três dias e 4 horas.

Figura 6 – Analisando os KPIs (Indicadores Chave de Desempenho).
Fonte: BENEDETE (2007, p.37).

43

No processo exemplo “aprovação de gastos de viagem”, pode-se definir como
KPIs o custo total do processo, a duração, o percentual aprovado, e o percentual de
aprovações realizadas pela diretoria.

Outra possibilidade é a criação de consoles de monitoração, através da
escolha e demonstração de um conjunto de indicadores em formato gráfico, como
mostrado na figura 7. Desta maneira, fica visualmente fácil e rápido acompanhar o
desempenho dos processos.

Figura 7 – Visualização gráfica dos indicadores.

Finalmente, outro recurso importante é a geração de relatórios analíticos,
onde os indicadores de desempenho e os totais são avaliados sob diversas
dimensões (por exemplo, pelo percentual de aprovação em um determinado período
de tempo, ou por um departamento em específico). A figura 8 mostra um exemplo de
relatório, onde diversos totais são categorizados pela dimensão localidade.

44

Figura 8 – Exemplo de relatório analítico.

2.3 Conformidades

Segundo Baldam (2008, p. 136-139), a regulamentação e adequação do
ambiente de negócios de acordo com as exigências e que atenda a demanda
crescente por melhores produtos e serviços é indispensável nos dias de hoje.
Existem atualmente, uma maior complexidade e necessidade de regulamentação
dos ambientes de negócio como jamais existiu, e a previsão é para que haja um
aumento gradativo e contínuo destas características. Estas características, quando
corretamente aplicadas, agregam valor às empresas, influenciando também o modo
como os diretores e analistas de negócios visualizam e gerenciam a organização as
respectivas áreas de negócios.

[...] entendemos padrões de conformidade como sendo as diversas
referências que precisam ser seguidas, obrigatoriamente, para a obtenção
de certificações, credenciais ou mesmo autorizações para um negócio
funcionar em um determinado seguimento do mercado (BALDAM et al.,
2008, p.135).

45

Baldam (2008, p. 135), afirma ainda que, se não tratarmos seriamente o bom
gerenciamento, este fator acarretará prejuízos no mercado e até mesmo
penalidades junto aos órgãos financeiros e legislativos. No entanto, como citado
acima, o bom gerenciamento é alcançado com regulamentações variadas e
transformações no ambiente de negócios consideradas complexas. Para alcançar a
excelência da conformidade, é necessário realizar o levantamento de práticas que
obtiveram sucesso nas determinadas áreas que se pretende aplicar as adequações.

Como as organizações são sistemas semi-abertos, que interagem com o
meio-ambiente, um autogerenciamento visa garantir que os aspectos relacionados a
regulamentações sejam corretamente tratados. Para tanto, a conformidade é o
componente utilizado para este gerenciamento e pode ser definido como adequação
a um conjunto de regras, sejam estas regulações ou legislações governamentais,
padrões de indústria ou políticas e procedimentos internos (JENKINS apud BALDAM
et al., 2008, p. 135).

2.4 Sistemas de Gestão de Processos de Negócio (BPMS)

Business Process Management Systems (BPMSs) foram introduzidos com o
objetivo de prover controle para definir e coordenar a execução de processos de
negócio (GARCIA e TOLEDO apud SOUZA, 2008, p. 28).

Os BPMS´s são sistemas integrados que permitem a operacionalização de
fluxos de processos de negócio, automatizando a execução, controle e
monitoramento desses processos. Um BPMS deve possuir ferramentas que
permitam a modelagem, a execução e orquestração de processos e também deve
possuir ferramentas de análise e monitoramento.

Os sistemas de gestão de processos são plataformas que orquestram os
processos de negócio, junto com todos os sistemas e pessoas envolvidos, dando
uma completa visibilidade e controle aos gestores de processos. São, portanto, os

46

resultados de processos automatizados e geridos com o uso de ferramentas de
gestão de processos (ARORA apud SANTOS, 2007, p. 5).

“Os sistemas para o gerenciamento de processos (BPMS) são mais que um
sistema computacional que suporta a gestão da informação pela organização. Eles,
primeiro e principalmente, ajudam a gerenciar os processos” (OULD apud SANTOS,
2007, p. 5).

Os BPMSs apóiam a automatização de processos de negócio. O ciclo de vida
de automatização inicia com a definição do processo. Em seguida, a definição é
registrada em um BPMS. Para executar um processo, o sistema cria uma instância
de processo e então, coordena, monitora e registra sua execução. O registro pode
ser analisado, podendo gerar uma definição aprimorada do processo (AALST;
HOFSTEDE; WESKE apud ROCHA, 2008, p. 23).

Diferentemente dos Workflows Management Systems (WfMSs), que são
sistemas de software que definem, criam e gerenciam a execução de workflows, os
BPMSs enfatizam processos que cruzam as fronteiras organizacionais e o aspecto
da dinamicidade de processos (HOLLINGSWORTH apud ROCHA, 2008, p. 23).

2.4.1 Ciclo de Vida de BPMS

Considerando o contexto de negócio atual, Business Process Management
Systems (BPMSs) foram introduzidos com o objetivo de prover controle para definir e
coordenar a execução de processos de negócio (GARCIA e TOLEDO apud SOUZA,
2008, p.28).

Geralmente um BPMS apresenta quatro funcionalidades principais que são:
Projeto, Configuração, Execução e Diagnóstico.

47

Figura 9 – Automação do ciclo de vida de processo de negócios.
Fonte: Adaptada de GARCIA e TOLEDO apud SOUZA, (2008, p.30).

• Projeto: o ciclo de vida tem início com a modelagem do processo de
negócio, nesta fase ocorre o levantamento dos processos, do
ambiente, organizacional e técnico. São utilizados editores de
modelagem e ferramentas para validação dos processos de negócios;

• Configuração: nesta fase, os modelos de processos são
implementados. São incluídas informações técnicas que facilitam a
execução dos processos;

• Execução: o processo de negócio pode ser executado através de um
BPMS configurado, o BPMS cria instâncias de um modelo de
processos, coordena a execução e registra as informações coletadas
durante a execução do processo;

• Diagnóstico: o histórico da execução é analisado, identificando
problemas e melhorando os processos. Isso pode levar ao processo
de redesenho do processo (fase de projeto). Conforme mostra a figura
9.

48

2.5 BPMN e os elementos de BPD

A BPMN (Business Process Modeling Notation) é uma notação visual para
representação de fluxos de processos que pode ser mapeada para diversos
formatos de execução, como BPML (Business Process Modeling Language) e BPEL
(Business Process Execution Language) (REIS et al., 2007, p. 07).

A especificação BPMN, criada pelo BPMI (Business Process Management
Initiative) provê uma notação gráfica para representar processos de negócios em um
diagrama, servindo de apoio ao uso de BPM por não-especialistas (BALDAM et al.,
2008, p.79).

A BPMN define um diagrama de processo (Business Process Diagram –BPD),
contendo os elementos gráficos, que representam atividades e fluxos de controle
que determinam a ordem de execução dessas atividades.

Um diagrama de Processos de negócios (BPD) é constituído de um conjunto
de elementos gráficos que permitem o desenvolvimento de diagramas simples
semelhantes aos de fluxo utilizados por analistas de negócio. Os elementos
utilizados são distintos uns dos outros e utilizam formas também comumente
utilizadas pela maioria dos modeladores. Por exemplo, as atividades são
representadas por retângulos e as decisões por losângulos. A figura 10 demonstra
esse exemplo.

Figura 10 – Demonstração das Atividades e Decisões
Fonte: Adaptada de Reis (2007, p. 07).

49

2.5.1 Objetos de Fluxo (Flow Objects)

Um BPD tem um conjunto de três elementos básicos, conhecidos como
Objetos de Fluxo, para que os modeladores não tenham que aprender e reconhecer
um número grande de formas diferentes. A tabela 01 demonstra os três objetos de
fluxo.

50

Nome Descrição Objeto

Um evento é algo que "acontece" no decurso de
um processo de negócio. Estes eventos afetam o
fluxo do processo e normalmente Tem uma
causa disparador () ou um impacto Resultado ().
Evento Eventos são círculos com centros abertos para
(Event) Permitir indicadores internos para diferenciar
diferentes disparadores ou resultados. Existem
três tipos de eventos, com base em quando elas
afetam o fluxo: Início, Intermediário e Final
(tradução do autor).

Uma atividade é um termo genérico para o
trabalho que a empresa executa. Uma atividade
pode ser atômicas ou não-atômica (composta).
Os tipos de atividades que fazem parte de um
Atividade
modelo de processo são: Processo, a sub
(Activity)
processo, e de tarefas. Tarefas e Sub-processos
são retângulos arredondados. Os processos são
contidos dentro de uma piscina (pool) (tradução
do autor).

Um gateway é usado para controlar a divergência
e convergência de seqüência de fluxo. Assim, ele
Portão vai determinar a ramificação, bifurcação, fusão e
(Gateway) junção de caminhos. Interno Marcadores vai
indicar o tipo de controle de comportamento
(tradução do autor).
Tabela 1 – Objetos de Fluxo.
Fonte: BPMN (2009).

51

2.5.2 Objetos de Conexão

Os Objetos de Fluxo são conectados em um diagrama para criar a estrutura
básica do processo de negócio. Existem três objetos de conexão que possibilitam
esta função, conforme mostra tabela 02.


A seqüência de fluxo é usado para
Fluxo de Seqüência mostrar a ordem em que as
(Sequence Flow) atividades serão realizadas em um
processo (tradução do autor).

Um fluxo de mensagens é usado para
mostrar o fluxo de mensagens entre
dois participantes que estão preparados
Fluxo de
para enviar e receber. Em BPMN, dois
Mensagem
Pools separados em um Diagrama
(Message Flow)
representarão os dois participantes (por
exemplo, entidades empresariais ou
papéis de negócio) (tradução do autor).

Uma associação é usada para associar
as informações de Fluxo com objetos.
Texto e Gráfico que não são fluxos, os
Associação objetos podem ser associados com
(Association) Fluxo de Objetos. Um seta sobre a
Associação indica uma direção de fluxo
(por exemplo, dados), quando for o
caso (tradução do autor).
Tabela 2 – Objetos de Conexão.
Fonte: BPMN (2009).

52

2.5.3 Raias (Swimlanes)

A BPMN usa o conceito conhecido como "swimlanes" para ajudar a partição e
organizar as atividades. Um diagrama de BPMN pode representar mais de um
processo privado, bem como os processos que mostram a colaboração entre a
processos privados ou participantes. Em caso afirmativo, em seguida, cada
processo de negócio privado será considerado como sendo realizada por diferentes
Participantes. Graficamente, cada participante irá ser particionado; isto é, vai estar
contido em uma caixa retangular, chamada um "pool". Pools podem ter sub-
Swimlanes, que são chamados, simplesmente, "Lanes", como mostra a tabela 03.


Um Pool representa um participante
em um processo também atua como
uma raia "e um container gráfico
para o particionamento de um
Pool
conjunto de atividades de outros
pools, geralmente no contexto de
Situações de B2B (tradução do
autor).

A Lane é uma sub-partição dentro de
uma piscina e vai estender a todo o
comprimento do interior, quer na
Lane vertical ou horizontalmente. Lanes
são usadas para organizar e
categorizar atividades (tradução do
autor).
Tabela 3 – Raias (Swimlanes).
Fonte: BPMN (2009).

53

2.5.4 Artefatos

Segundo a BPMN os artefatos são usados para fornecer informações
adicionais sobre o processo. Existem três artefatos padronizados, mas os
Modeladores ou ferramentas de modelagem são livres para adicionar muitos
artefatos conforme o necessário. É possível que haja esforços da BPMN para
adicionar e padronizar um conjunto maior de artefatos para uso geral ou para os
mercados verticais. A tabela 04 mostra o conjunto atual de artefatos que inclui:


Objetos de dados são considerados Artefatos porque
Objeto de não têm qualquer efeito direto sobre a Seqüência de
Dados Fluxo de Mensagem ou fluxo do processo, mas eles
(Data fazem fornecer informações sobre as atividades que
Object) necessitam de ser executada e / ou o que eles
produzem (tradução do autor).

Um conjunto de atividades que estejam dentro da
mesma categoria. Este tipo de agrupamento não
afetam a seqüência de fluxo de atividades dentro do
grupo. O nome da categoria aparece no diagrama
Grupo
como o rótulo de grupo. Categorias podem ser
(Group)
usadas para documentação ou fins de análise.
Grupos são uma maneira em que as categorias de
objetos podem ser visualmente exibidos dentro do
diagrama.

Anotação
Anotações de Texto é um mecanismo para um
(Text
modelador de fornecer informações adicionais para o
Annotation
leitor de um BPMN Diagrama.
)
Tabela 4 – Artefatos.
Fonte: BPMN (2009).

54

3. ARQUITETURA ORIENTADA A SERVIÇOS

A arquitetura SOA baseia-se em permitir que sistemas corporativos
disponibilizem suas funcionalidades através de serviços que podem ser utilizados
por outros sistemas para a execução de suas tarefas. É importante ressaltar que a
Arquitetura Orientada a Serviços não é um software. Este termo refere-se a um
modelo de arquitetura de software voltada para a construção de aplicações que
implementam processos de negócio ou serviços utilizando um conjunto de
componentes fracamente acoplados e orquestrados a fim de prover um nível de
serviço bem definido (HURWITZ apud MIRANDA 2008, p. 16).

A SOA estabelece um modelo arquitetônico que visa a aprimorar a
eficiência, a agilidade e a produtividade de uma empresa, posicionando os
serviços como os principais meios para que a solução lógica seja
representada no suporte à realização dos objetivos estratégicos associados
à computação orientada a serviços (ERL et al., 2008, p.24).

A SOA permite flexibilidade com serviços que podem ser fornecidos
localmente ou podem estar localizados externamente, os serviços podem ser
implementados em qualquer linguagem de programação, plataformas diferentes,
tecnologias diversas podem ser utilizadas e o legado de software pode ser
aproveitado mantendo o principio da interoperabilidade. É uma caracterização de
sistemas distribuídos, em que as funcionalidades do sistema são expostas via
descrição de uma interface, permitindo a publicação, localização e a invocação por
meio de um formato padronizado.

As arquiteturas orientadas a serviços são um caminho para o
desenvolvimento de sistemas distribuídos nos quais os componentes destes
sistemas são serviços dedicados. Os serviços podem ser executados em
computadores distribuídos geograficamente. Protocolos padronizados foram
projetados para apoiar troca de serviços de comunicação e de informações.
Conseqüentemente, os serviços são plataformas e linguagens de
implementações independentes. Sistemas de software podem ser
construídos usando serviços de provedores diferentes em nenhuma ligação
de interação entre esses serviços (SOMMERVILLE apud OLIVEIRA, 2008,
p. 62).

55

A Arquitetura Orientada a Serviço é capaz de oferecer a infra-estrutura
tecnológica necessária para que uma aplicação possa ser definida por meio da
composição de serviços eletrônicos. Dessa forma, oferece apoio à composição de
aplicações distribuídas de uma forma flexível e com baixo custo. Em SOA, a
composição de serviços é vista como um processo de negócio dividido em
componentes reutilizáveis e interoperáveis em Serviços.

Segundo Moreira (2007, p. 18), a arquitetura orientada a serviços é
constituída de relações entre três tipos de participantes:

• Diretório para registro de serviços, repositório que é utilizado para
publicar e localizar as interfaces dos serviços;

• Provedor de serviços, entidade responsável por publicar as interfaces
dos serviços providos por esta no registro de serviços e também
responsável por atender as requisições originadas pelos clientes;

• Cliente, aplicação ou outro serviço que efetua requisições a um serviço.

E esses participantes se relacionam através de três principais operações que
são:

• Publicar: Inicialmente, o provedor de serviço publica a interface do seu
serviço junto ao diretório para registro de serviços;

• Localizar: O cliente pode efetuar uma busca por um determinado
serviço (operação localizar), especificando as características
desejadas, no diretório de registros. Se o serviço existir, a interface e a
localização do respectivo serviço são retornados para o cliente;

• Invocar: O cliente efetua uma invocação ao provedor do serviço
(operação invocar). Os serviços estão baseados nas trocas de
mensagens entre os provedores e os clientes, sendo assim, as
mensagens seguem um formato padrão, garantindo aos serviços a
neutralidade da tecnologia e permitindo que provedores.

56

3.1 Características da Arquitetura Orientada a Serviços

Erl (apud Moreira 2007, p. 19) define SOA como sendo uma tecnologia que
adere aos princípios da orientação a serviços. Quando realizados através do uso da
tecnologia de Web Services, SOA promove esses princípios em todos os processos
de negócios e automação de uma corporação.

Para a composição de Sistemas de Software compostos por serviços, a
Arquitetura SOA deve permitir todas as características apresentadas na Tabela 5.

57

CARACTERÍSTICA DESCRIÇÃO

Este conceito trata de minimizar as dependências entre os serviços,
Acoplamento Fraco
permitindo assim flexibilidade na mudança das regras de negócio;

A lógica de uma regra de negócio deve estar definida e
Reusabilidade do
disponibilizada como um serviço que pode ser reutilizado por outros
Serviço
sistemas;

Os serviços dispõem de uma especificação para a forma de acesso
Contrato do Serviço e comunicação. Determina a forma de recebimento e envio de
dados aos serviços;

A arquitetura SOA promove um alto nível de abstração,
Abstração considerando o encapsulamento das regras de negócio em
serviços, permitindo que os mesmos sejam reutilizados;

Serviços podem ser compostos para formar novos serviços com um
nível maior de abstração e provendo funcionalidades agregadas. A
Composição flexibilidade na composição de novos serviços a partir de serviços já
disponíveis na rede é o grande atrativo da arquitetura (SOUZA,
apud OLIVEIRA, 2008, p.66);

O encapsulamento de funcionalidades no nível de serviço evoca um
alto grau de granularidade nos componentes básicos da arquitetura.
Um objeto individual apresenta operações muito finas para prover
funcionalidades significativas no nível corporativo. Para o
Alta Granularidade desenvolvimento de aplicações complexas e extensas a alta
granularidade traz vantagens na medida em que detalhes de
implementação são deixados à equipe de desenvolvimento
responsável por aquele serviço (SOUZA apud OLIVEIRA, 2008
p.66).

Para maior interoperabilidade, SOA promove na implementação de
Heterogeneidade serviços a independência de plataforma de desenvolvimento,
tecnologias de implementação e linguagens de programação.

Os serviços devem ser acessíveis a partir de qualquer lugar e a
Ubiqüidade qualquer momento facilitando a composição de serviços entre
empresas (SOUZA apud OLIVEIRA, 2008 p.67).
Tabela 5 – Principais Características da Arquitetura SOA.
Fonte: Adaptada de MIRANDA (2008, p.21).

58

3.2 Componentes SOA

De acordo com a especificação de arquitetura orientada a serviços pela
organização OASIS, SOA é um paradigma para organização e utilização de
competências distribuídas que estão sob o controle de diferentes domínios
proprietários (OASIS, 2007). Para prover essa organização e utilização, a
Arquitetura SOA dispõe de quatro componentes principais: 1- Aplicação Frontend; 2
- Serviço; 3 - Repositório de Serviço e 4 - Barramento de Serviço (KRAFZIG apud
MIRANDA, 2008, p.26).

Esses componentes estão dispostos de forma interoperável ou colaborativa,
fornecendo a estrutura necessária para a disponibilização dos serviços. A Figura 11
ilustra uma visão geral da arquitetura SOA.

Figura 11 – Componentes da arquitetura SOA.
Fonte: MIRANDA (2008, p.26).

59

3.2.1 Aplicação Frontend

Segundo Josuttis (apud Miranda, 2008, p.27) são os elementos ativos de
SOA, iniciando e controlando as atividades de um sistema e entregando o resultado
do serviço, interagindo com o usuário. Existem diferentes tipos de Aplicações
FrontEnd. Um exemplo desse componente é uma aplicação de interface gráfica,
como uma aplicação Web que utiliza um browser para a interação com o usuário,
fazendo a chamada do processo e recebendo o resultado da execução de um
serviço. Uma Aplicação Frontend desempenha um papel muito próximo ao Padrão
de Projetos Facade (Fachada), onde um objeto disponibiliza uma interface que dá
acesso a uma grande quantidade de funcionalidades de um subsistema, abstraídas
do objeto que originou as chamadas. A Figura 12 ilustra um exemplo de Aplicação
FrontEnd.

Figura 12 – Exemplo de Aplicação Frontend.

60

3.2.2 Serviços

Um Serviço pode ser entendido como uma função do sistema computacional
construída de forma a ser facilmente vinculada a outros componentes de software,
que podem ser outros serviços. O Serviço tem papel fundamental dentro da
Arquitetura Orientada a Serviços, pois encapsula uma função de negócio que pode
ser reutilizável, tendo como características marcantes a independência de
tecnologias de linguagens de programação em sua implementação e baixo
acoplamento. A Figura 13 ilustra a composição de um serviço com seus sub-
componentes.

Figura 13 – Composição de um Serviço na Arquitetura SOA.
Fonte: KRAFZIG apud MIRANDA (2008, p.28)

Cada serviço deve conter um Contrato, que especifica restrições quanto ao
acesso ao serviço e uso dos serviços. O contrato impõe semântica sobre as

61

funcionalidades e parâmetros do serviço (DAVIES apud MIRANDA, 2008, p. 28). Os
serviços também devem disponibilizar Interfaces, que definem as operações
disponíveis em um serviço. As interfaces podem ser entendidas como as assinaturas
dos métodos definidos em classes na Orientação a Objetos, onde é descrito o tipo
de retorno, o nome da operação, sua visibilidade e argumentos.

A regra de negócio realizada pelo serviço deve estar contido na
Implementação, que proporciona a execução do serviço utilizando a lógica de
negócio e os dados necessários. Alem da lógica de negócios e dos dados, fazem
parte da Implementação os subprogramas, os dados e arquivos de configuração e a
base de dados.

SOA promove a idéia de módulos de software que prestam serviços a outros
módulos, com características e tecnologias diferentes. A concepção de serviço tem
três características principais, conforme mostra a tabela 06.

CARACTERÍSTICA DESCRIÇÃO

A descrição do serviço através de uma interface, ou seja,
Interface como aquele serviço será conhecido e como ele será
acessado;

Contrato Definição de como se dará esse acesso pela sua interface;

Sua implementação, ou seja, a funcionalidade por trás da
interface. Atualmente, essa abordagem converge para o
Implementação padrão de Web Services. No passado, sistemas empresariais
operavam com diferentes tipos de interfaces, projetadas em
tecnologias distintas.
Tabela 6 – Características da Concepção de Serviços.

ERL (et al., 2008, p.28) identifica três tipos fundamentais de serviços:

62

• Serviço utilitário: são serviços que implementam algumas
funcionalidades gerais que podem ser utilizadas por diferentes
processos de negócios;

• Serviço de entidade: são serviços associados a uma função específica
do de negócio;

• Serviço-tarefa: são serviços que apóiam os processos de negócios
mais gerais que envolvem diferentes atores e atividades.

3.2.3 Ciclo de Vida dos Serviços

Segundo Miranda (2008, p. 30) os serviços são considerados pedaços de
software que encapsulam alguma funcionalidade de negócios. Como tal, seu ciclo de
desenvolvimento é comum aos softwares, consistindo nas fases de: modelagem,
implementação, integração e execução. O ciclo de vida de um serviço pode aplicar o
modelo em cascata, porém, assim como no desenvolvimento de um software, não é
o modelo ideal, podendo assumir um ciclo de vida iterativo, onde o desenvolvimento
de software pode ser ajustado com as experiências obtidas nas fases anteriores. A
Tabela 7 apresenta as etapas do ciclo de vida dos serviços bem como a descrição
de cada etapa.

63

ETAPA DESCRIÇÃO

A fase de modelagem gera um produto: a especificação da
Modelagem interface do serviço. Esta interface inclui a semântica e os
atributos não funcionais;
Esta é a fase de codificação do serviço, utilizando tecnologias
Implementação como linguagens de programação, protocolos de comunicação e
plataformas de desenvolvimento;

Fase de adequação dos serviços aos sistemas que farão uso da
Integração
Arquitetura SOA. É a inserção do serviço no domínio do problema;

Fase em que o serviço estará disponível para uma Aplicação
Execução
FrontEnd ou qualquer outro tipo de consumidor.
Tabela 7 - Fases do Ciclo de Vida do Serviço
Fonte: MIRANDA (2008, p. 30).

3.2.4 Repositório de Serviços

Miranda (2008, p. 31) cita ainda que outra estrutura importante dentro da
arquitetura SOA é o Repositório de Serviços , que fornece meios para facilitar a
descoberta de serviços, bem como, as informações referentes ao serviço. Essas
informações podem variar, podendo informar sobre a localização física, pessoas de
contato, informações sobre o fornecedor, utilização de restrições de segurança e
níveis do serviço.

Geralmente, um Repositório de Serviços está associado ao escopo de uma
empresa ou organização. É possível utilizar a arquitetura SOA sem um Repositório
de Serviços. Isso depende da quantidade de serviços disponibilizados a nível
empresarial. Por isso, por mais que uma empresa que esteja adotando SOA não
possua muitos serviços a serem disponibilizados, é interessante optar pela utilização
de um repositório, pois isso trará benefícios em longo prazo (KRAFZIG apud
MIRANDA, 2008, p. 31).

64

3.2.5 Barramento de Serviços

Segundo Galdino (apud Miranda, 2008, p.31) o Barramento de Serviços
interconecta todos os elementos da arquitetura SOA, funcionando como canal de
comunicação. Este barramento facilita o compartilhamento de serviços dentro de
uma corporação, fornecendo transparência na localização dos serviços. Se duas
aplicações precisam se comunicar entre si, uma Aplicação de Frontend invoca as
funcionalidades de um serviço utilizando o Barramento de Serviços. É importante
destacar que o barramento de serviços não é necessariamente composto por uma
tecnologia, podendo abranger uma grande variedade de soluções tecnológicas.

A Tabela 8 descreve as principais características do Barramento de Serviço.

CARACTERÍSTICAS DESCRIÇÃO

Objetivo principal do Barramento de Serviços. Permite
interligar os componentes de uma arquitetura SOA,
Conectividade
fornecendo facilidades que permitam ao FrontEnd
invocar as funcionalidades dos serviços;

O Barramento suporta uma gama de tecnologias, o
que geralmente é a realidade das empresas, que em
sua maioria, adotam por soluções distintas. Essas
Tecnologias Heterogêneas
tecnologias variam desde linguagens de programação,
sistemas operacionais, ambientes de execução,
middlewares e protocolos de comunicação;

Embora a funcionalidade principal do Barramento de
Serviços seja a comunicação entre componentes e
Serviços Técnicos serviços, o barramento também fornece alguns
serviços como auditoria, segurança, transformação de
mensagens e transações.
Tabela 8 – Características do Barramento de Serviços.
Fonte: MIRANDA (2008, p. 32).

65

3.3 Composição de Serviços

Segundo Moreira (2007, p.32.) para solucionar problemas como distribuição e
heterogeneidade de aplicações, surge a necessidade de composição de serviços.
Esta técnica permite modelar o processo de negócio e também aumenta a
possibilidade de aproveitar os benefícios da arquitetura orientada a serviços.

O mecanismo da composição de serviços visa combinar dois ou mais serviços
para que, juntos, possam atender a requisitos que vão além das suas capacidades
individuais. Em outras palavras, a composição provê uma abordagem aberta,
baseada em padrões, para conectar Web Services objetivando criar processos de
negócio de alto nível, com um alto valor agregado. A Figura 14 exemplifica uma
composição de serviços.

Uma das principais motivações para a utilização da composição de serviço é
o desenvolvimento de processos de negócio envolvendo vários parceiros e
seqüência de operações.

Figura 14 – Composição de Serviços
Fonte: MOREIRA (2007, p.33).

66

Os padrões são projetados para reduzir a complexidade requerida para
compor Web Services, reduzindo custo e tempo, e aumentando a eficiência global
nos negócios.

De acordo com Moreira (2007, p. 33), a composição de serviços deve atender
as seguintes exigências:

• Habilidade de invocar serviços de maneira assíncrona, alcançando
confiabilidade, escalabilidade e adaptabilidade, características
necessárias em um ambiente de negócios;

• Gerenciar a integridade transacional e de exceções;

• Prover uma clara separação entre a lógica do processo e os Web
Services usados;

• Ser capaz de compor serviços de alto nível de processos existentes.

A composição de serviços faz uso de vários serviços para criar um serviço
e/ou o uso de um serviço por outro serviço vai se tornando mais comum, para a
criação de processos, para isso dois conceitos são muito importantes: orquestração
e coreografia, como visto na figura 15.

Figura 15 – Orquestração e Coreografia.
Fonte: LEITÃO e MARGALHO JUNIOR (2007, p.25)

67

3.3.1 Orquestração

As interações do processo de negócios são controladas por uma das partes
envolvidas no processo. A orquestração envolve interações entre as partes e os
passos entre as interações (FANTINATO; TOLEDO; GIMENES apud SOUZA, 2008,
p.61).

Empresas que têm sistemas legados interconectados ou processo de
negócio trabalhando em conjunto necessitam comumente de uma unidade
controladora, a fim de facilitar o processo de interoperabilidade entre tais
sistemas. Essa solução é conhecida como orquestração de serviços. A
forma de implementação deste mecanismo permite que dois ou mais
sistemas se comuniquem com uma unidade orquestradora central
(MOREIRA, 2007, p. 33-34).

Um dos requisitos que guia a criação de orquestrações é o fato de unir
processos de negócio. Com a orquestração, diferentes processos podem ser
conectados sem que seja necessário desenvolver novamente as sua
funcionalidades em um novo sistema. O uso da orquestração pode reduzir
significativamente a complexidade de implementação, bem como facilitar a
manutenção dos sistemas (ERL, 2005, p. 203).

A Figura 16 exibe o funcionamento do processo de orquestração de serviços.
O coordenador central (por exemplo, um Web Service) recebe uma mensagem do
Web Service 1 requisitando alguma informação. O coordenador invoca alguns
parceiros a fim de agrupar a informação e então retorna o resultado para o Web
Service 1. Este tipo de processo pode ser conhecido como privado e executável, já
que apenas a entidade que está orquestrando o processo conhece o fluxo de
controle e informação que o segue. A principal técnica de implementação da
orquestração é através da linguagem BPEL.

Monografia bpm

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Monografia bpm

Similar a Monografia bpm (20)

Más de Fernando Palma

Más de Fernando Palma (20)

Monografia bpm