Monografia BPM

CENTRO TECNOLGICO DA ZONA LESTE
FACULDADE DE TECNOLOGIA DA ZONA LESTE

RAFAEL RAYATO INAZAWA

A APLICAO DO BPM PARA AUTOMAO DE
PROCESSOS DE NEGCIO NAS ORGANIZAES
ESTUDO DE CASO: PROJETO NEW_RCMS

So Paulo
2009



A APLICAO DO BPM PARA AUTOMAO DE
PROCESSOS DE NEGCIO NAS ORGANIZAES

Monografia apresentada no curso de
Tecnologia em Informtica nfase em gesto
de negcios na FATEC ZL como
requerimento parcial para obteno do Ttulo
de Tecnlogo em Informtica nfase em
gesto de negcios

Orientador: Prof. Msc. Wilson Vendramel

So Paulo
2009

Inazawa, Rafael Rayato
A Aplicao do BPM para Automao de Processos de Negcio
nas Organizaes. Estudo de Caso: PROJETO NEW_RCMS /Rafael
Rayato Inazawa So Paulo, SP : [s.n], 2009.
111 f.

Orientador: Wilson Vendramel.
Trabalho de Concluso de Curso (Tecnlogo) Faculdade de
Tecnologia da Zona Leste.

1. Gesto do processo de negcio. 2. Arquitetura orientada a
servios. I. Vendramel, Wilson. II. Faculdade de Tecnologia da
Zona Leste.



A APLICAO DO BPM PARA AUTOMAO DE PROCESSOS DE
NEGCIO NAS ORGANIZAES

Monografia apresentada no curso de
Tecnologia em Informtica com nfase em
gesto de Negcios na FATEC ZL como
requerido parcial para obter o Ttulo de
Tecnlogo em Informtica com nfase em
gesto de Negcios.

COMISSO EXAMINADORA

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

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

____________________________________
Esp. Marco Aurlio Aloise Filho

So Paulo, ___ de _____________ de 2009.

DEDICATRIA

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

AGRADECIMENTOS

minha famlia e namorada pelo apoio e incentivo a esta jornada.
Aos meus amigos, pela fora e pela vibrao em relao a esta jornada.
Ao Prof. Msc. Orientador Wilson Vendramel, pela sua valorosa orientao e um dos
grandes responsveis pelo desenvolvimento e finalizao deste trabalho.
Aos meus colegas de trabalho pela colaborao e incentivo.
Aos colegas de curso, pela batalha a qual vencemos.
Aos que colaboraram e no impediram a finalizao deste estudo.

Cabe ao ser humano dedicar o
mximo de si em tudo o que fizer,
nas circuntncias 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 Aplicao do BPM para automao de Processos de
Negcio nas Organizaes Estudo de Caso: PROJETO NEW_RCMS. 2009. 111 f.
Trabalho de Concluso de Curso (Tecnlogo) Faculdade de Tecnologia da Zona
Leste, So Paulo, SP.

RESUMO

As organizaes em um mercado cada vez mais competitivo so constantemente
desafiadas a produzirem melhores resultados com menor custo, desenvolverem
produtos e servios baseados em um ciclo de vida mais curto e se relacionarem de
forma mais personalizada e integrada com seus clientes, fornecedores e parceiros. As
organizaes devem ser capazes de melhorar seus processos de negcio e sua
comunicao com a rea de TI, da qual dependem para viabilizar seus objetivos e
estratgias, atualmente buscam melhorar seus processos de negcio e alinh-los junto
com a TI, essa sinergia torna os processos das empresas flexveis e resilientes frente a
um novo tipo de mercado global. necessria a aplicao de modelos de gesto nas
reas estratgicas da empresa para que se tornem possveis a representao do
ambiente de negcio e o uso de uma arquitetura flexvel, dinmica e adaptvel (SOA
Service-Oriented Architecture) possibilitam uma viso sistmica de toda a organizao.
Desta maneira, este trabalho foca analisar a implantao do BPM (Business Process
Management) nas corporaes.

Palavras-chave: Arquitetura Orientada a Servios, Processo de Negcio, 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, So 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 Informao
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 Ilustrao de um processo de negcio...........................................................24

Figura 2 Viso Sistmica dos Processos.....................................................................25

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

Figura 4 Exemplo de Viso Global de Processos de compra......................................32

Figura 5 - Monitorao de Processos de Negcio com o Websphere Business MQ......41

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

Figura 7 Visualizao grfica dos indicadores.............................................................43

Figura 8 Exemplo de relatrio analtico........................................................................44

Figura 9 Automao do ciclo de vida de processo de negcios..................................47

Figura 10 Demonstrao das Atividades e Decises...................................................48

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

Figura 12 Exemplo de Aplicao Frontend..................................................................59

Figura 13 Composio de um Servio na Arquitetura SOA.........................................60

Figura 14 Composio de Servios..............................................................................65

Figura 15 Orquestrao e Coreografia.........................................................................67

Figura 16 Exemplo de processo de orquestrao de servios.....................................69

Figura 17 Exemplo de Coreografia de servios...........................................................69

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

Figura 19 Estrutura bsica de uma especificao BPEL.............................................73

Figura 20 Interface Grfica modelada pelo BPEL atravs da ferramenta Eclipse.......75

Figura 21 Camadas de Abstrao de SOA..................................................................76

Figura 22 O negcio e os domnios da lgica da aplicao.........................................77

Figura 23 As trs principais camadas de servios.......................................................78

Figura 24 Servios utilitrios da camada de servio de aplicao...............................79

Figura 25 Servio ServicoSalvarGrupo nas camadas de Aplicao e Negcios.........81

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

Figura 27 Atividades do ciclo de vida com os servios 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 aplicao no PDA...................................................................102

Figura 33 Arquitetura tecnolgica e suas aplicaes aps a implantao do BPM...103

LISTA DE QUADROS

Quadro 1 Atividades bsicas 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 implantao do BPM......................103

LISTA DE TABELAS

Tabela 1 Objetos de Fluxo...........................................................................................50
Tabela 2 Objetos de Conexo......................................................................................51
Tabela 3 Raias (Swimlanes).........................................................................................52
Tabela 4 Artefatos........................................................................................................53
Tabela 5 Principais Caractersticas da Arquitetura SOA..............................................57
Tabela 6 Caractersticas da Concepo de Servios...................................................61
Tabela 7 - Fases do Ciclo de Vida do Servio................................................................63
Tabela 8 Caractersticas do Barramento de Servios..................................................64
Tabela 9 Principais sistemas do Service Desk.............................................................92

SUMRIO

1. INTRODUO............................................................................................................19
2. GESTO DE PROCESSOS DE NEGCIO................................................................22
2.1 Processos de negcio..........................................................................................23
2.1.1 Fluxo de Trabalho de Pessoas..........................................................................25
2.1.2 Caractersticas de Processos nas Organizaes..............................................26
2.2 Ciclo do Gerenciamento de Processo de Negcio...............................................27
2.2.1 Planejamento do BPM.......................................................................................29
2.2.1.1. Viso 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 negcio..............38
2.2.2.4 Otimizao de Processos e Soluo Imediata de Problemas........................38
2.2.3 Execuo de Processos.....................................................................................39
2.2.4 Controle e Anlise de Dados.............................................................................40
2.3 Conformidades......................................................................................................44
2.4 Sistemas de Gesto de Processos de Negcio (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 Conexo..........................................................................................51
2.5.3 Raias (Swimlanes).............................................................................................52

2.5.4 Artefatos.............................................................................................................53
3. ARQUITETURA ORIENTADA A SERVIOS..............................................................54
3.1 Caractersticas da Arquitetura Orientada a Servios............................................56
3.2 Componentes SOA...............................................................................................58
3.2.1 Aplicao Frontend............................................................................................59
3.2.2 Servios.............................................................................................................60
3.2.3 Ciclo de vida dos servios..................................................................................62
3.2.4 Repositrio de servios......................................................................................63
3.2.5 Barramento de servios.....................................................................................64
3.3 Composio de servios.......................................................................................65
3.3.1 Orquestrao.....................................................................................................67
3.3.2 Coreografia........................................................................................................68
3.3.3 BPEL..................................................................................................................70
3.4 Camadas de abstrao.........................................................................................75
3.4.1 Camada corporativa...........................................................................................76
3.4.2 Camada de processos.......................................................................................76
3.4.3 Camada de servios..........................................................................................77
3.4.3.1 Camada de servio de aplicao....................................................................78
3.4.3.2 Camada de servios de negcio.....................................................................80
3.4.3.3 Camada de servio de orquestrao..............................................................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 Estratgia...........................................................................................................84

3.5.1.1 Bottom-up........................................................................................................84
3.5.1.2 Top-down85
3.5.2 Modelagem....85
3.5.3 Implementao.86
3.5.4 Monitoramento (Business Activity Monitoring)...................................................86
3.6 Web Services........................................................................................................87
4. ESTUDO DE CASO....................................................................................................89
4.1 Descrio do ambiente de pesquisa.....................................................................89
4.2 Implantao do BPM na organizao...................................................................89
4.3 Modelagem do processo de negcio de Atendimento de chamados...................91
4.4 Resultados obtidos..............................................................................................101
5. CONSIDERAES FINAIS......................................................................................105
REFERNCIAS.............................................................................................................107
GLOSSRIO.................................................................................................................110

19

1. INTRODUO

Melhoria Contnua um termo bem conhecido para as organizaes que
desejam se manter competitivas no mercado. Hoje com a disposio dos mais
variados modelos, mtodos e processos de Gesto, algumas tm conseguido
alcanar os principais objetivos que so: manter crescimento, reduzir gastos e
aumentar lucros.
As organizaes que conseguem alcanar suas metas e objetivos em geral
so as que possuem processos internos e externos bem definidos, esto sempre em
constante mudana organizacional e se adaptam rapidamente a elas, geralmente
possuem uma tima infra-estrutura de TI alinhada ao seu processo de negcio, isso
as tornam empresas flexveis.
A maior dificuldade das empresas alinhar os seus processos de negcio a
TI, criar uma soluo tecnolgica adequada que agregue valor ao seu negcio
possibilita a empresa ter uma forte flexibilidade e interoperabilidade para
acompanhar as constantes mudanas de processos e informaes.
A aplicao do Business Process Management (BPM) permite mapear os
processos organizacionais da empresa, buscando a integrao funcional e
proporcionando maior agilidade nas atividades que envolvem pessoas, tarefas,
mquinas, aplicaes de software e outros elementos coordenados para atingir os
objetivos do negcio. Com a utilizao de notao de modelagem de processos
como Business Process Management Notation (BPMN), os analistas de negcio
podem documentar os modelos criados e entender melhor os processos da empresa
em diferentes nveis, facilitando deste modo o entendimento dos participantes dos
processos de negcio.
Da necessidade de integrao entre diferentes sistemas e a disseminao da
Web surge a Arquitetura Orientada a Servios SOA (Service-Oriented Architecture)
que veio com o objetivo de integrar servios fracamente acoplados, possibilitando o
reuso, modificao e a aplicao em diferentes reas internas ou externas da
empresa. Atrs de inovao, as empresas vem cada vez mais demonstrando
20

interesse em Web Services, pois uma tecnologia atual baseada na Web capaz de
integrar servios utilizando tecnologia XML (eXtensible Markup Language). De certa
forma essa tecnologia pode sanar boa parte dos problemas de uma organizao que
utiliza sistemas diferentes, fazendo com que eles troquem informaes, com isso a
empresa pode integrar seus processos a esses sistemas independentes de
plataforma ou linguagem de programao.
Este trabalho tem como objetivo demonstrar os passos necessrios para uma
organizao implementar o BPM, por meio da modelagem de seus processos,
visando promover a flexibilidade, Interoperabilidade e a reusabilidade de
componentes na organizao.
A Justificativa para o desenvolvimento deste trabalho demonstrar que o
Business Process Management de extrema importncia para as organizaes e
que suas contribuies agregam mais valor ao negcio tornando a empresa mais
competitiva no mercado.
A metodologia deste estudo ser feita a partir de pesquisa bibliogrfica e
tambm de um estudo de caso que apresenta a modelagem de um processo de
negcio, a fim de demonstrar as principais atividades e caractersticas da gesto de
processos de negcio por meio do BPM.
O estudo de caso consiste em analisar um determinado processo de um
servio oferecido por uma organizao, e a utilizao de uma ferramenta de
modelagem de negcio (Bizagi Process Modeler), obtendo assim, a insero,
desses processos no paradigma da orientao a servios e gesto dos processos de
negcio.
O segundo captulo aborda a gesto de processos de negcio, que uma
disciplina de gesto estratgica, que sustenta a idia de que podemos modelar um
negcio em termos de processos de sua finalidade que podem abranger tradicionais
organizaes e fronteiras de sistemas. Ele envolve a descoberta, projeto e entrega
dos processos de negcio, fazendo com que todos os departamentos da
organizao estejam alinhados com as metas e estratgias da corporao. Uma boa
gesto ainda permite um ciclo de melhoria contnua onde as organizaes devem
estar aptas s constantes mudanas organizacionais em conjunto com a Tecnologia
da Informao para estarem melhor alinhadas com suas metas, estratgias e
21

objetivos.
O terceiro captulo, aborda a arquitetura orientada a servios que uma
aproximao arquitetural para desenvolvimento de sistemas que constri e distribui
servios reutilizveis e encapsulados prestados s empresas para que diferentes
aplicaes possam compartilh-los em um modo vagamente acoplado e altamente
inter-opervel. A implementao desses servios podem ser feitas independente da
plataforma ou linguagem de programao, utilizam protocolos padronizados para a
comunicao e troca de informaes. Esses padres tornam os servios flexveis e
reusveis, podendo ser executados em computadores distribudos geograficamente.
Essa arquitetura ainda permite a utilizao de diversas outras tecnologias incluindo
os sistemas legados da organizao, mantendo a interoperabilidade entre os
diversos sistemas da organizao.

22

2. GESTO DE PROCESSOS DE NEGCIO

Segundo a BPMN (apud BALDAM et al., 2008, p.19), a gesto por processos
de negcios envolve a descoberta, projeto e entrega de processos de negcios.
Adicionalmente, o BPM inclui o controle executivo, administrativo e supervisrio
desses processos.
A gesto por processos de negcios a disciplina de modelar, automatizar,
gerenciar e otimizar processos de negcios atravs do seu ciclo de vida com o
propsito de lhes agregar valor (KHAN apud OLIVEIRA, 2008, p. 19),
O BPM tem vrios predecessores como o Gerenciamento de Qualidade Total
(TQM, do ingls 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 negcios em um perodo relativamente curto pela
reengenharia completa dos processos de negcios existentes. O BPR teve um
grande sucesso inicial, mas o movimento teve um declnio que levou ao fracasso
vrios projetos. O BPM surgia 10 anos mais tarde e trazia de volta a gesto por
processos de negcios com solues que atendiam, atravs da evoluo dos fluxos
de trabalho, a interoperabilidade de processos mais complexos e distribudos
fisicamente.
Com a integrao e aperfeioamento dos processos, de forma que as metas e
estratgias estejam alinhadas com a corporao, a gesto por processos pode
trazer eficincia e permitir vincular a atividade das diferentes funes internas aos
fatores competitivos da organizao.
No entanto, se o processo como um todo no for corretamente analisado e
avaliado, as correntes funes tornam-se um grupo de pequenas unidades de
negcios isoladas, as quais so avaliadas indevidamente por padres no
condizentes com as necessidades globais da empresa. O acontecimento mais
comum o de o organograma receber uma maior ateno do que o prprio negcio.
O termo BPM, Business Process Management, largamente utilizado pelos
autores para referenciar a automao dos processos, que uma vez passando por
23

esse processo de automatizao, pode ser gerenciado posteriormente, por meio de
ferramentas de software.
J no ambiente de negcios, os executivos se referem gesto de processos
de negcios de uma forma mais genrica, com uma viso de gerenciamento
humano melhor organizado diante dos negcios da corporao.

2.1 Processos de negcio

Processo de Negcio a descrio de um conjunto de atividades que
envolvem pessoas, tarefas, mquinas, softwares e outros elementos coordenados
para atingir objetivos de negcio.

um fenmeno que ocorre dentro das empresas. Compreende um
conjunto de atividades realizadas na empresa, associadas s informaes
que manipula, utilizando os recursos e a organizao da empresa. Forma
uma unidade coesa e deve ser focalizado em um tipo de negcio, 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 negcio pode ser visto
como um conjunto estruturado de tarefas que contribuem coletivamente para que
uma organizao atinja os seus objetivos. Os processos de negcio so a base
operativa de uma empresa e fazem parte da cultura desta e o xito da mesma
depende fortemente da eficincia com que eles so administrados. Assim sendo,
uma m administrao dos processos traz altos custos, baixa produtividade e
inadequados tempos de resposta, tanto frente s oportunidades como s ameaas.
A figura 01 exemplifica um processo de negcio.

24

Figura 1 Ilustrao de um processo de negcio.
Fonte: GARCIA e TOLEDO (2007).

A Figura 2 mostra o esquema geral de funcionamento de processos nas
organizaes, ela demonstra o que est diretamente envolvido em um processo em
particular (entradas, sadas, recurso e controles), inclusive as influncias externas
oriundas do contexto da organizao, 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 Viso Sistmica dos Processos.
Fonte: BALDAM (2008. p.21).

2.1.1 Fluxo de trabalho de pessoas

Quando as atividades do processo exigem aes ou pareceres de pessoas,
normalmente categoriza-se o processo como de longa durao, pois o elemento
humano pode demorar em completar a tarefa. Para os mecanismos de BPM darem
suporte a interao humana, no s devem armazenar e controlar estes processos
de longa durao, mas tambm prover funcionalidades como:

Identificao do responsvel pela tarefa: Normalmente, quando se
desenha um processo, assinala-se um papel (uma funo como
gerente de agncia, analista de crdito) s tarefas, ao invs de uma
26

identificao direta da pessoa (como seria um cdigo funcional). Isto
importante para que os processos sejam independentes das pessoas,
as quais podem sair da empresa ou mudar de funo, e tambm
porque para cada instncia do processo o recurso (pessoa) pode ser
diferente. Os papis podem ser definidos no momento de criao dos
fluxos, durante sua instalao no ambiente, ou mesmo durante sua
execuo (KLOPPMANN apud BENEDETE, 2007, p. 31);
Envio da tarefa para a pessoa responsvel e apoio interao: Depois
de identificado, o responsvel pela tarefa tem que ser comunicado
criando itens em uma relao de tarefas que deve ser periodicamente
consultada pela pessoa. As ferramentas de BPM no s avisam o
responsvel pela tarefa, mas tambm fornecem telas onde o contexto
(informaes necessrias para entender, executar uma tarefa ou tomar
uma deciso) da atividade apresentado;
Tratamento de excees: 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 ao necessria.

2.1.2 Caractersticas dos processos nas organizaes

Segundo Baldam (2008, p. 24), medida que a viso de processos se
difunde, as formas contemporneas de racionalizao tendem a ver as organizaes
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
especfico.

Conhecendo a viso do processo, possvel definir o que deve ser feito e
como faz-lo, no em cima das atividades dos departamentos, mas sim, atividades
que agregam valor a organizao independente do departamento que executar o
processo. Deste modo, os processos tramitariam entre departamentos conforme o
servio que ele necessitar realizar (BALDAM et al., 2008, p. 24).
Porm, com estas caractersticas de processos, os departamentos ainda
seriam teis nas organizaes, devido a sua funcionalidade em situaes gerenciais.

2.2 Ciclo de Gerenciamento de Processo de Negcio

A descrio das etapas do ciclo de gerenciamento de negcios, segundo
Baldam (2008, p. 56), podem ser aplicadas em um processo especfico da
organizao ou em processos de negcios onde existe uma gesto da integrao
destes j presente, podendo ser utilizada tambm em um estado de gesto 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 contribuiro
para o alcance de metas organizacionais (desde as estratgicas at
as operacionais) sero definidas, como verificao dos pontos de
falha nos processos que causam danos a organizao (financeiros,
imagem, prazos e satisfao de clientes), definio de planos de ao
para implantao, definio dos processos que necessitam de ao
imediata;
Modelagem e otimizao de processos: atividades que permitem
gerar informaes sobre o processo atual (As Is) e/ou sobre a
proposta de processo futuro (To Be); documentar os processos;
prover dados de integrao entre processos, empregar metodologias
para aperfeioar os processos, fazer inovaes, simulaes e
29

redesenhos; adotar as melhores prticas de modelos de referncia;
gerar especificaes para implementao, para configurao e
customizao (caso o processo no esteja em uso), para execuo e
controle;
Execuo de processos: atividades que garantiro a implementao e
a execuo dos processos, como implantao de planos de
transferncia de tecnologia, treinamentos, ajuste de equipamentos e
softwares (se necessrios), acompanhamento de processo
implantado, monitoria e controle da execuo das instncias de
processo;
Controle e anlise de dados: atividades relacionadas ao controle geral
do processo (por meio de diversos recursos, como o uso de
indicadores, BAM, BI, BSC, mtodos estatsticos, diagramas de causa
e efeito), gerando informaes que posteriormente realimentaro as
atividades de otimizao e planejamento.

2.2.1 Planejamento do BPM

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

Definir os processos-chave para a estratgia da organizao. Usando
metodologias conhecidas (Cadeia de Valor, BSC, SWOT), possvel
identificar em quais processos a organizao tem mais
potencialidade, os pontos que precisam melhorar, quais as ameaas
e oportunidades do mercado, os indicadores que sero 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
organizao;

Identificar as oportunidades (novas abordagens, produtos ou servios)
que possam ser fornecidas pela organizao, levando a preparar os
processos que permitiro sua entrega;

Perceber que todos os processos podem passar por inovao;

Preparar, no todo ou em parte, a viso global de processos;

Classificar os processos que meream ateno em ordem de
prioridade;

Identificar ao time de projetos de processos e s reas envolvidas as
diretrizes e especificaes bsicas desejadas a partir do
planejamento;

Planejar e controlar as tarefas necessrias implementao.

Os gestores de processo no so os nicos responsveis pelas atividades do
planejamento. importante a participao de gestores de outras reas da
organizao, o apoio desses gestores e o seu comprometimento com o BPM de
forma contnua contribuem para o xito na gesto por processos, caso isso no
ocorra, surgiro processos isolados sem uma viso global dos processos. No
momento da implantao, fundamental a participao efetiva do gestor da
organizao, a fim de evitar possveis barreiras e desentendimentos, entre os
funcionrios dos diversos setores e reas envolvidas.
De acordo com Baldam (2008, p. 66) no so apenas os processos que
apresentam problemas (qualidade, custo, prazo, etc.) que passaro por otimizao,
outros processos que estejam funcionando perfeitamente podem ser otimizados
buscando inovao ou melhoria contnua desse processo.
31

Algumas atividades surgem de imediato e mesmo que a necessidade desse
processo no tenha sido detectada no planejamento estratgico, sua implantao
pode ser imediata.

2.2.1.1 Viso global de processos

Considerado um ponto de controvrsia que precede o BPM, segundo Baldam
(2008, p. 66), a Viso Global de Processos fundamental numa Gesto Integrada
dos Processos sendo necessrio considerar:

Uma Viso Global dos Processos ajuda a compreenso do
funcionamento da empresa;
Faz-lo por completo complexo e pode levar mais tempo que o
benefcio direto e imediato por ele gerado;
relativamente fcil 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 prprios organizao.

32

Figura 4 Exemplo de Viso Global de Processos de compra.
Fonte: Adaptado de BALDAM (2008, p.69).

2.2.2 Modelagem de processos

A modelagem de processos de negcio uma das fases do ciclo de vida
SOA, ela um conjunto de conceitos, modelos e tcnicas com o objetivo de
desenvolver o modelo de negcio da organizao. Este modelo resultado de uma
abstrao da organizao, considerando as suas caractersticas essenciais, do
ponto de vista do negcio (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), possvel utilizar os modelos de processos
de negcios para:

Discutir e compreender os processos;
Apoiar a melhoria contnua (anlise da eficincia e da eficcia);
Simular alternativas;
33

Treinar os operadores dos novos processos;
Especificar os sistemas de informao que devero suportar o negcio.

Nesta fase o processo modelado em termos de atividades, regras,
participantes, interaes e relacionamentos. O processo estruturado em
atividades, que podem ser mapeadas como tarefas que so executadas por pessoas
ou sistemas internos ou externos corporao. realizada a validao ou a
simulao dos processos, atravs do uso de estimativas de tempo de execuo e
custo, recursos requeridos pelas atividades e a probabilidade de ocorrncia de
eventos.
Essa fase tambm inclui a definio das mtricas de desempenho do
processo para que o analista de negcio possa avaliar o processo implantado e,
possivelmente, reestrutur-lo em funo de oportunidades ou de outros motivos
(NADER apud OLIVEIRA, 2008, p. 36).
Os modelos de processo so constitudos de diagramas de fluxo de trabalho e
de textos auxiliares de forma a descrever cada passo do processo de negcio.
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 nveis: de forma grfica, com o
auxlio de ferramenta de desenho de processos e com um modelo executvel,
utilizado na automao desses processos atravs dos sistemas de gesto de fluxo
de trabalho.
Durante a descrio de um diagrama de negcio, os eventuais problemas
relacionados ao processo que ele representa so documentados e para cada um
so propostas possibilidades de melhorias. Os principais conceitos envolvidos, as
regras e os recursos utilizados ou produzidos por cada processo so identificados e
modelados como entidades de negcio.

34

2.2.2.1 Modelagem de estado atual (As Is)

Por meio desta modelagem possvel entender o processo existente na
organizao e identificar suas falhas. Espera-se, desta forma, obter mtricas
suficientes a fim de estabelecer uma base na fase seguinte da anlise e
desempenho do processo atual, que permita identificar as melhorias proporcionadas
pelo estado futuro, assim como uma documentao dos prs e contras e do
desempenho do processo.
Na modelagem do estado atual do processo, vrios tipos de interaes entre
os envolvidos no processo podem existir, incluindo atividades de colaborao e
reunies. Diversas tcnicas podem ser utilizadas na modelagem de processos atual:
tcnica de entrevistas, brainstorm, JAD, mtodos 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:

Preparao do projeto de modelagem: envolve as diversas atividades
de compreenso de escopo (qual processo ser modelado,
propsitos, mtricas, verificar alinhamento estratgico, prazos e
entregveis), composio da equipe envolvida, definio de
documentao necessria, planejamento das reunies (pessoas
envolvidas, datas, agenda, infra-estrutura necessria reunio),
consulta documentao do processo, ou que rege o processo
previamente disponvel (normas, leis, regulamentos e referncias);

Entrevista e coleta de dados com usurios (especialista de negcio e
facilitadores): podem incluir entrevistas (em aberto ou dirigidas),
criao conjunta da lista de esquema grfico de atividades, descrio
de informaes que comporo o processo e criao de atas de
reunio;
35

Documentao do processo: ser construdo o modelo, conforme
metodologia previamente definida. Alm dos componentes do
processo propriamente dito, outras informaes sero necessrias,
como controle de verso de documentao, publicao, referncias e
escopo. Nessa fase comum o uso intensivo de software de apoio
modelagem;

Validade do processo: deve-se testar o modelo em uma instncia real
do processo, para verificar se realmente est coerente. Em alguns
casos, a validao impossvel 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
licitao pblica, quando envolve grandes somas, pode se
desenvolver por meses;

Correo de documentao: so corrigidas eventuais distores
percebidas durante a validao do processo.

Segundo Tachizawa e Scaico (apud Pak, 2006), uma anlise do processo
atual deve verificar se os objetivos so atendidos, se as atividades esto bem
relacionadas, se os recursos alocados so suficientes e se as interfaces entre
gerncias esto sendo previstas e administradas. Tambm importante verificar a
consistncia das tarefas utilizadas, evitando a redundncia 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;

Mtricas apropriadas e suficientes para estabelecer uma base para
futuras medidas de melhorias de processos, priorizao e seleo na
fase seguinte de anlise do To Be;
36

Mtricas e documentao do atual desempenho do processo;

Documentao do que trabalha bem e o que precisa funcionar melhor;

Identificao dos itens mais significativos e de ganho rpido que podem
ser rapidamente implementados;

Um relatrio dessa fase.

2.2.2.2 Modelagem de estado futuro (To Be)

Nessa fase pretende-se criar um ambiente de discusso entre partes 40
envolvidas de forma a melhorar o processo em questo, inov-lo ou mesmo
questionar se ele se faz necessrio e se agrega valor organizao (BALDAM et al.,
2008, p. 83). Entre as modelagens do estado futuro mais comuns podem ser citadas:

Melhoria continua;
FAST;
Benchmarking;
Adoo de melhores prticas e processos comodizados (transform-
los em commodities);
Redesenho de processo;
Inovao de processo.

O objetivo dessa etapa definir a deciso a ser tomada em relao aos
processos identificados durante a modelagem do estado atual e seu realinhamento
37

com os objetivos e estratgias da organizao. Se a deciso for redesenhar os
processos, ser necessrio desenvolver um novo modelo de processos com as
melhorias previstas para a situao atual identificada (SANTOS apud OLIVEIRA,
2008. P. 40).
Dentre os resultados a serem esperados (OCONNELL, PYKE &
WHITEHEAD; JESTON & NELIS apud BALDAM et al., 2008, p.93) podem estar
includos:

Redesenho do processo ou mesmo um novo processo;
Documentao de suporte ao processo redesenhado ou novo
processo;
Requerimentos de alto nvel para as novas opes observadas;
Modelos de simulao e detalhes de custos ABC;
Confirmao de que as novas opes atendem s expectativas dos
envolvidos;
Confirmao que est alinhado estratgia;
Um relatrio das diferenas que precisam ser atendidas para cumprir
os requerimentos;
Plano de desenvolvimento e treinamento da equipe;
Relatrio de impactos na organizao e em outras esferas (ambiental,
social e etc.);
Detalhes do plano de comunicao do novo processo.

38

2.2.2.3 Ferramenta e metodologia de modelagem do processo de negcio

Cummins (apud Souza, 2008, p. 47), a ferramenta de definio dos processos
deve ter as seguintes caractersticas:

Ferramenta grfica interativa: Os processos so exibidos graficamente,
e os elementos do processo so adicionados e conectados com edio
interativa drag-and-drop;
Distino visual de tipo de tarefas: O tipo de cada elemento de
processo deve ser identificvel visualmente na representao grfica
do processo.

Grficos 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 comunicao.

2.2.2.4 Otimizao de Processos e Soluo Imediata de Problemas

No so apenas os processos que apresentam problemas (qualidade, custo,
prazo e visibilidade da marca) que passaro por otimizao (inovao, redesenho e
melhoria contnua). 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
telefnico para excees), aumentando assim o nmero de processos (BALDAM et
al., 2008, p. 66).
39

De acordo com Baldam (2008, p. 66), algumas atividades emergem de
imediato, quando surgem situaes como novos marcos, problemas de produo ou
qualidade, impedindo entrega ao cliente, concorrncia que lana produtos mais
competitivos etc. Ainda que a necessidade desses processos no tenha sido
detectada no Planejamento Estratgico anual (o que no quer dizer que no estejam
alinhados com ele), sua implantao pode ser imediata.

2.2.3 Execuo de processos

Nessa fase as definies da fase de modelagem do processo sero
executadas. Os processos sero testados pelos usurios, que indicaro os impactos
positivos e negativos da implementao desses.
Burlton (apud BALDAM et al., 2008, p. 94) sugere as seguintes atividades
para a execuo de processos:

Preparar o teste da nova soluo;
Completar testes e pilotos;
Atualizar os entregveis;
Gerenciar o plano de transferncia de tecnologia;
Desenvolver os planos da execuo da nova soluo;
Treinar a equipe;
Desenvolver e executar os programas de marketing da soluo;
Realizar as mudanas no processo atual ou elaborara um novo
processo.

tambm nesta fase, que ocorre a configurao do repositrio do BPMS que
suportar o novo processo e a implantao e configurao das aplicaes externas
40

que interagem com o processo. Um BPMS responsvel por manter os contextos
de execuo dos processos, que inclui a atividade que est em execuo, valores
de variveis, contextos de sub-processos, logs. Ele deve facilitar a integrao com
um conjunto de outras plataformas que executam os sistemas externos.

2.2.4 Controle e anlise de dados

So geradas as informaes sobre o comportamento dos processos, esses
dados so comparados e utilizados para montar indicadores gerais que permitem
avaliar o processo. Algumas tcnicas e tecnologias aplicveis ao controle e anlise
dos dados de instncias de processos, tais como BSC, BI, permitem uma melhor
viso do desempenho geral e apontam se a organizao est alcanando seus
objetivos ou se necessrio efetuar ajustes nos processos, nas metas ou mesmo na
estratgia da organizao.
Na fase de anlise, a medida do desempenho do processo prov informaes
de melhorias operacionais. A partir de uma viso fim-a-fim do processo possvel
fazer uma anlise top-down para determinar a influncia de cada passo ou sub-
processo no resultado global. Para dar suporte a essa fase so utilizados os
sistemas BAM (Business Activity Monitoring), onde os processos so instrumentados
com sensores para monitorar suas atividades e variveis. Um dashboard permite a
monitorao, anlise e respostas aos eventos e s excees que ocorrem em tempo
real.
Normalmente, aps o desenvolvimento de aplicaes e de sua implantao e
execuo em ambiente de produo, pouco suporte dado ao negcio para avaliar
se a soluo implementada foi adequada ou se h potencial para melhores
resultados. BPM, ao contrrio, foca na melhoria contnua dos processos de negcio,
e para tanto, prov mecanismos para que o negcio acompanhe o comportamento
dos processos e identifique falhas e oportunidades.
Podemos categorizar essa monitorao dos processos sob dois aspectos:
41

Operacional: Neste caso, o objetivo da monitorao acompanhar os
processos no nvel do detalhe, ou seja, cada instncia em execuo.
Procura-se por excees (se o processo ultrapassou limites de prazo,
custo, concluso sem sucesso) possibilitando assim o negcio atuar
na correo da situao, priorizando o processo ou mesmo
contatando seus participantes;
Analtica: Aqui, o objetivo analisar o conjunto das execues dos
processos, procurando por excees recorrentes ou por melhores
estratgias e oportunidades para o negcio. o momento de
comparar os resultados projetados com os realmente atingidos e
planejar aes de correo.

A monitorao operacional baseada na situao dos processos em
execuo, a qual normalmente mantida em banco de dados do mecanismo de
execuo de processos. A figura 5 mostra duas instncias de um processo sendo
monitorados pela ferramenta WebSphere Business Monitor da IBM. Nesta
ferramenta podemos definir quais campos devem ser mostrados, o critrio para
ordenao das linhas, e filtros, baseados em dados de negcio, para selecionar
apenas os processos que se deseja monitorar.

Figura 5 Monitorao de Processos de Negcio com o Websphere Business MQ.
Fonte: www.ibm.com.br

42

J a monitorao analtica normalmente baseada na anlise de eventos
gerados e armazenados pelo mecanismo de execuo. A soluo da IBM
anteriormente mencionada, por exemplo, de tempos em tempos copia os registros
de eventos para uma base de dados especializada em pesquisas analticas (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
execuo de processos.
Com base nos eventos, so gerados os KPI (Key Performance Indicators ou
Indicadores Chaves de Desempenho) e os totais (mtricas) escolhidos no momento
de projeto dos fluxos. Os KPIs devem ser cuidadosamente escolhidos, pois devem
refletir os objetivos do negcio mais relevantes para o sucesso da empresa, e
devem permitir a identificao antecipada de problemas, possibilitando aes
corretivas.
A figura 6 mostra dois KPI definidos para um processo (percentual de
aprovao e durao do processo). Aos KPI so associados limites, de forma que
seja facilitada a identificao de inconformidades. No exemplo, o processo foi
planejado para durar no mximo trs dias, mas em ambiente real est levando mais
de trs dias e 4 horas.

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

43

No processo exemplo aprovao de gastos de viagem, pode-se definir como
KPIs o custo total do processo, a durao, o percentual aprovado, e o percentual de
aprovaes realizadas pela diretoria.
Outra possibilidade a criao de consoles de monitorao, atravs da
escolha e demonstrao de um conjunto de indicadores em formato grfico, como
mostrado na figura 7. Desta maneira, fica visualmente fcil e rpido acompanhar o
desempenho dos processos.

Figura 7 Visualizao grfica dos indicadores.

Finalmente, outro recurso importante a gerao de relatrios analticos,
onde os indicadores de desempenho e os totais so avaliados sob diversas
dimenses (por exemplo, pelo percentual de aprovao em um determinado perodo
de tempo, ou por um departamento em especfico). A figura 8 mostra um exemplo de
relatrio, onde diversos totais so categorizados pela dimenso localidade.

44

Figura 8 Exemplo de relatrio analtico.

2.3 Conformidades

Segundo Baldam (2008, p. 136-139), a regulamentao e adequao do
ambiente de negcios de acordo com as exigncias e que atenda a demanda
crescente por melhores produtos e servios indispensvel nos dias de hoje.
Existem atualmente, uma maior complexidade e necessidade de regulamentao
dos ambientes de negcio como jamais existiu, e a previso para que haja um
aumento gradativo e contnuo destas caractersticas. Estas caractersticas, quando
corretamente aplicadas, agregam valor s empresas, influenciando tambm o modo
como os diretores e analistas de negcios visualizam e gerenciam a organizao as
respectivas reas de negcios.

[...] entendemos padres de conformidade como sendo as diversas
referncias que precisam ser seguidas, obrigatoriamente, para a obteno
de certificaes, credenciais ou mesmo autorizaes para um negcio
funcionar em um determinado seguimento do mercado (BALDAM et al.,
2008, p.135).
45

Baldam (2008, p. 135), afirma ainda que, se no tratarmos seriamente o bom
gerenciamento, este fator acarretar prejuzos no mercado e at mesmo
penalidades junto aos rgos financeiros e legislativos. No entanto, como citado
acima, o bom gerenciamento alcanado com regulamentaes variadas e
transformaes no ambiente de negcios consideradas complexas. Para alcanar a
excelncia da conformidade, necessrio realizar o levantamento de prticas que
obtiveram sucesso nas determinadas reas que se pretende aplicar as adequaes.
Como as organizaes so sistemas semi-abertos, que interagem com o
meio-ambiente, um autogerenciamento visa garantir que os aspectos relacionados a
regulamentaes sejam corretamente tratados. Para tanto, a conformidade o
componente utilizado para este gerenciamento e pode ser definido como adequao
a um conjunto de regras, sejam estas regulaes ou legislaes governamentais,
padres de indstria ou polticas e procedimentos internos (JENKINS apud BALDAM
et al., 2008, p. 135).

2.4 Sistemas de Gesto de Processos de Negcio (BPMS)

Business Process Management Systems (BPMSs) foram introduzidos com o
objetivo de prover controle para definir e coordenar a execuo de processos de
negcio (GARCIA e TOLEDO apud SOUZA, 2008, p. 28).
Os BPMSs so sistemas integrados que permitem a operacionalizao de
fluxos de processos de negcio, automatizando a execuo, controle e
monitoramento desses processos. Um BPMS deve possuir ferramentas que
permitam a modelagem, a execuo e orquestrao de processos e tambm deve
possuir ferramentas de anlise e monitoramento.
Os sistemas de gesto de processos so plataformas que orquestram os
processos de negcio, junto com todos os sistemas e pessoas envolvidos, dando
uma completa visibilidade e controle aos gestores de processos. So, portanto, os
46

resultados de processos automatizados e geridos com o uso de ferramentas de
gesto de processos (ARORA apud SANTOS, 2007, p. 5).
Os sistemas para o gerenciamento de processos (BPMS) so mais que um
sistema computacional que suporta a gesto da informao pela organizao. Eles,
primeiro e principalmente, ajudam a gerenciar os processos (OULD apud SANTOS,
2007, p. 5).
Os BPMSs apiam a automatizao de processos de negcio. O ciclo de vida
de automatizao inicia com a definio do processo. Em seguida, a definio
registrada em um BPMS. Para executar um processo, o sistema cria uma instncia
de processo e ento, coordena, monitora e registra sua execuo. O registro pode
ser analisado, podendo gerar uma definio aprimorada do processo (AALST;
HOFSTEDE; WESKE apud ROCHA, 2008, p. 23).
Diferentemente dos Workflows Management Systems (WfMSs), que so
sistemas de software que definem, criam e gerenciam a execuo 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 negcio atual, Business Process Management
Systems (BPMSs) foram introduzidos com o objetivo de prover controle para definir e
coordenar a execuo de processos de negcio (GARCIA e TOLEDO apud SOUZA,
2008, p.28).
Geralmente um BPMS apresenta quatro funcionalidades principais que so:
Projeto, Configurao, Execuo e Diagnstico.

47

Figura 9 Automao do ciclo de vida de processo de negcios.
Fonte: Adaptada de GARCIA e TOLEDO apud SOUZA, (2008, p.30).

Projeto: o ciclo de vida tem incio com a modelagem do processo de
negcio, nesta fase ocorre o levantamento dos processos, do
ambiente, organizacional e tcnico. So utilizados editores de
modelagem e ferramentas para validao dos processos de negcios;
Configurao: nesta fase, os modelos de processos so
implementados. So includas informaes tcnicas que facilitam a
execuo dos processos;
Execuo: o processo de negcio pode ser executado atravs de um
BPMS configurado, o BPMS cria instncias de um modelo de
processos, coordena a execuo e registra as informaes coletadas
durante a execuo do processo;
Diagnstico: o histrico da execuo 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 notao visual para
representao de fluxos de processos que pode ser mapeada para diversos
formatos de execuo, como BPML (Business Process Modeling Language) e BPEL
(Business Process Execution Language) (REIS et al., 2007, p. 07).
A especificao BPMN, criada pelo BPMI (Business Process Management
Initiative) prov uma notao grfica para representar processos de negcios em um
diagrama, servindo de apoio ao uso de BPM por no-especialistas (BALDAM et al.,
2008, p.79).
A BPMN define um diagrama de processo (Business Process Diagram BPD),
contendo os elementos grficos, que representam atividades e fluxos de controle
que determinam a ordem de execuo dessas atividades.
Um diagrama de Processos de negcios (BPD) constitudo de um conjunto
de elementos grficos que permitem o desenvolvimento de diagramas simples
semelhantes aos de fluxo utilizados por analistas de negcio. Os elementos
utilizados so distintos uns dos outros e utilizam formas tambm comumente
utilizadas pela maioria dos modeladores. Por exemplo, as atividades so
representadas por retngulos e as decises por losngulos. A figura 10 demonstra
esse exemplo.

Figura 10 Demonstrao das Atividades e Decises
Fonte: Adaptada de Reis (2007, p. 07).
49

2.5.1 Objetos de Fluxo (Flow Objects)

Um BPD tem um conjunto de trs elementos bsicos, conhecidos como
Objetos de Fluxo, para que os modeladores no tenham que aprender e reconhecer
um nmero grande de formas diferentes. A tabela 01 demonstra os trs objetos de
fluxo.

50

Nome Descrio Objeto
Evento
(Event)
Um evento algo que "acontece" no decurso de
um processo de negcio. Estes eventos afetam o
fluxo do processo e normalmente Tem uma
causa disparador () ou um impacto Resultado ().
Eventos so crculos com centros abertos para
Permitir indicadores internos para diferenciar
diferentes disparadores ou resultados. Existem
trs tipos de eventos, com base em quando elas
afetam o fluxo: Incio, Intermedirio e Final
(traduo do autor).

Atividade
(Activity)
Uma atividade um termo genrico para o
trabalho que a empresa executa. Uma atividade
pode ser atmicas ou no-atmica (composta).
Os tipos de atividades que fazem parte de um
modelo de processo so: Processo, a sub
processo, e de tarefas. Tarefas e Sub-processos
so retngulos arredondados. Os processos so
contidos dentro de uma piscina (pool) (traduo
do autor).

Porto
(Gateway)
Um gateway usado para controlar a divergncia
e convergncia de seqncia de fluxo. Assim, ele
vai determinar a ramificao, bifurcao, fuso e
juno de caminhos. Interno Marcadores vai
indicar o tipo de controle de comportamento
(traduo do autor).

Tabela 1 Objetos de Fluxo.
Fonte: BPMN (2009).

51

2.5.2 Objetos de Conexo

Os Objetos de Fluxo so conectados em um diagrama para criar a estrutura
bsica do processo de negcio. Existem trs objetos de conexo que possibilitam
esta funo, conforme mostra tabela 02.

Nome Descrio Objeto
Fluxo de Seqncia
(Sequence Flow)
A seqncia de fluxo usado para
mostrar a ordem em que as
atividades sero realizadas em um
processo (traduo do autor).

Fluxo de
Mensagem
(Message Flow)
Um fluxo de mensagens usado para
mostrar o fluxo de mensagens entre
dois participantes que esto preparados
para enviar e receber. Em BPMN, dois
Pools separados em um Diagrama
representaro os dois participantes (por
exemplo, entidades empresariais ou
papis de negcio) (traduo do autor).

Associao
(Association)
Uma associao usada para associar
as informaes de Fluxo com objetos.
Texto e Grfico que no so fluxos, os
objetos podem ser associados com
Fluxo de Objetos. Um seta sobre a
Associao indica uma direo de fluxo
(por exemplo, dados), quando for o
caso (traduo do autor).

Tabela 2 Objetos de Conexo.
Fonte: BPMN (2009).

52

2.5.3 Raias (Swimlanes)

A BPMN usa o conceito conhecido como "swimlanes" para ajudar a partio e
organizar as atividades. Um diagrama de BPMN pode representar mais de um
processo privado, bem como os processos que mostram a colaborao entre a
processos privados ou participantes. Em caso afirmativo, em seguida, cada
processo de negcio 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 so chamados, simplesmente, "Lanes", como mostra a tabela 03.

Nome Descrio Objeto
Pool
Um Pool representa um participante
em um processo tambm atua como
uma raia "e um container grfico
para o particionamento de um
conjunto de atividades de outros
pools, geralmente no contexto de
Situaes de B2B (traduo do
autor).

Lane
A Lane uma sub-partio dentro de
uma piscina e vai estender a todo o
comprimento do interior, quer na
vertical ou horizontalmente. Lanes
so usadas para organizar e
categorizar atividades (traduo do
autor).

Tabela 3 Raias (Swimlanes).
Fonte: BPMN (2009).

53

2.5.4 Artefatos

Segundo a BPMN os artefatos so usados para fornecer informaes
adicionais sobre o processo. Existem trs artefatos padronizados, mas os
Modeladores ou ferramentas de modelagem so livres para adicionar muitos
artefatos conforme o necessrio. possvel que haja esforos 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:

Nome Descrio Objeto
Objeto de
Dados
(Data
Object)
Objetos de dados so considerados Artefatos porque
no tm qualquer efeito direto sobre a Seqncia de
Fluxo de Mensagem ou fluxo do processo, mas eles
fazem fornecer informaes sobre as atividades que
necessitam de ser executada e / ou o que eles
produzem (traduo do autor).

Grupo
(Group)
Um conjunto de atividades que estejam dentro da
mesma categoria. Este tipo de agrupamento no
afetam a seqncia de fluxo de atividades dentro do
grupo. O nome da categoria aparece no diagrama
como o rtulo de grupo. Categorias podem ser
usadas para documentao ou fins de anlise.
Grupos so uma maneira em que as categorias de
objetos podem ser visualmente exibidos dentro do
diagrama.

Anotao
(Text
Annotation
)
Anotaes de Texto um mecanismo para um
modelador de fornecer informaes adicionais para o
leitor de um BPMN Diagrama.

Tabela 4 Artefatos.
Fonte: BPMN (2009).
54

3. ARQUITETURA ORIENTADA A SERVIOS

A arquitetura SOA baseia-se em permitir que sistemas corporativos
disponibilizem suas funcionalidades atravs de servios que podem ser utilizados
por outros sistemas para a execuo de suas tarefas. importante ressaltar que a
Arquitetura Orientada a Servios no um software. Este termo refere-se a um
modelo de arquitetura de software voltada para a construo de aplicaes que
implementam processos de negcio ou servios utilizando um conjunto de
componentes fracamente acoplados e orquestrados a fim de prover um nvel de
servio bem definido (HURWITZ apud MIRANDA 2008, p. 16).

A SOA estabelece um modelo arquitetnico que visa a aprimorar a
eficincia, a agilidade e a produtividade de uma empresa, posicionando os
servios como os principais meios para que a soluo lgica seja
representada no suporte realizao dos objetivos estratgicos associados
computao orientada a servios (ERL et al., 2008, p.24).

A SOA permite flexibilidade com servios que podem ser fornecidos
localmente ou podem estar localizados externamente, os servios podem ser
implementados em qualquer linguagem de programao, plataformas diferentes,
tecnologias diversas podem ser utilizadas e o legado de software pode ser
aproveitado mantendo o principio da interoperabilidade. uma caracterizao de
sistemas distribudos, em que as funcionalidades do sistema so expostas via
descrio de uma interface, permitindo a publicao, localizao e a invocao por
meio de um formato padronizado.

As arquiteturas orientadas a servios so um caminho para o
desenvolvimento de sistemas distribudos nos quais os componentes destes
sistemas so servios dedicados. Os servios podem ser executados em
computadores distribudos geograficamente. Protocolos padronizados foram
projetados para apoiar troca de servios de comunicao e de informaes.
Conseqentemente, os servios so plataformas e linguagens de
implementaes independentes. Sistemas de software podem ser
construdos usando servios de provedores diferentes em nenhuma ligao
de interao entre esses servios (SOMMERVILLE apud OLIVEIRA, 2008,
p. 62).

55

A Arquitetura Orientada a Servio capaz de oferecer a infra-estrutura
tecnolgica necessria para que uma aplicao possa ser definida por meio da
composio de servios eletrnicos. Dessa forma, oferece apoio composio de
aplicaes distribudas de uma forma flexvel e com baixo custo. Em SOA, a
composio de servios vista como um processo de negcio dividido em
componentes reutilizveis e interoperveis em Servios.

Segundo Moreira (2007, p. 18), a arquitetura orientada a servios
constituda de relaes entre trs tipos de participantes:

Diretrio para registro de servios, repositrio que utilizado para
publicar e localizar as interfaces dos servios;
Provedor de servios, entidade responsvel por publicar as interfaces
dos servios providos por esta no registro de servios e tambm
responsvel por atender as requisies originadas pelos clientes;
Cliente, aplicao ou outro servio que efetua requisies a um servio.

E esses participantes se relacionam atravs de trs principais operaes que
so:

Publicar: Inicialmente, o provedor de servio publica a interface do seu
servio junto ao diretrio para registro de servios;
Localizar: O cliente pode efetuar uma busca por um determinado
servio (operao localizar), especificando as caractersticas
desejadas, no diretrio de registros. Se o servio existir, a interface e a
localizao do respectivo servio so retornados para o cliente;
Invocar: O cliente efetua uma invocao ao provedor do servio
(operao invocar). Os servios esto baseados nas trocas de
mensagens entre os provedores e os clientes, sendo assim, as
mensagens seguem um formato padro, garantindo aos servios a
neutralidade da tecnologia e permitindo que provedores.
56

3.1 Caractersticas da Arquitetura Orientada a Servios

Erl (apud Moreira 2007, p. 19) define SOA como sendo uma tecnologia que
adere aos princpios da orientao a servios. Quando realizados atravs do uso da
tecnologia de Web Services, SOA promove esses princpios em todos os processos
de negcios e automao de uma corporao.
Para a composio de Sistemas de Software compostos por servios, a
Arquitetura SOA deve permitir todas as caractersticas apresentadas na Tabela 5.

57

CARACTERSTICA DESCRIO
Acoplamento Fraco
Este conceito trata de minimizar as dependncias entre os servios,
permitindo assim flexibilidade na mudana das regras de negcio;
Reusabilidade do
Servio
A lgica de uma regra de negcio deve estar definida e
disponibilizada como um servio que pode ser reutilizado por outros
sistemas;
Contrato do Servio
Os servios dispem de uma especificao para a forma de acesso
e comunicao. Determina a forma de recebimento e envio de
dados aos servios;
Abstrao
A arquitetura SOA promove um alto nvel de abstrao,
considerando o encapsulamento das regras de negcio em
servios, permitindo que os mesmos sejam reutilizados;
Composio
Servios podem ser compostos para formar novos servios com um
nvel maior de abstrao e provendo funcionalidades agregadas. A
flexibilidade na composio de novos servios a partir de servios j
disponveis na rede o grande atrativo da arquitetura (SOUZA,
apud OLIVEIRA, 2008, p.66);
Alta Granularidade
O encapsulamento de funcionalidades no nvel de servio evoca um
alto grau de granularidade nos componentes bsicos da arquitetura.
Um objeto individual apresenta operaes muito finas para prover
funcionalidades significativas no nvel corporativo. Para o
desenvolvimento de aplicaes complexas e extensas a alta
granularidade traz vantagens na medida em que detalhes de
implementao so deixados equipe de desenvolvimento
responsvel por aquele servio (SOUZA apud OLIVEIRA, 2008
p.66).
Heterogeneidade
Para maior interoperabilidade, SOA promove na implementao de
servios a independncia de plataforma de desenvolvimento,
tecnologias de implementao e linguagens de programao.
Ubiqidade
Os servios devem ser acessveis a partir de qualquer lugar e a
qualquer momento facilitando a composio de servios entre
empresas (SOUZA apud OLIVEIRA, 2008 p.67).
Tabela 5 Principais Caractersticas da Arquitetura SOA.
Fonte: Adaptada de MIRANDA (2008, p.21).
58

3.2 Componentes SOA

De acordo com a especificao de arquitetura orientada a servios pela
organizao OASIS, SOA um paradigma para organizao e utilizao de
competncias distribudas que esto sob o controle de diferentes domnios
proprietrios (OASIS, 2007). Para prover essa organizao e utilizao, a
Arquitetura SOA dispe de quatro componentes principais: 1- Aplicao Frontend; 2
- Servio; 3 - Repositrio de Servio e 4 - Barramento de Servio (KRAFZIG apud
MIRANDA, 2008, p.26).
Esses componentes esto dispostos de forma interopervel ou colaborativa,
fornecendo a estrutura necessria para a disponibilizao dos servios. A Figura 11
ilustra uma viso geral da arquitetura SOA.

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

59

3.2.1 Aplicao Frontend

Segundo Josuttis (apud Miranda, 2008, p.27) so os elementos ativos de
SOA, iniciando e controlando as atividades de um sistema e entregando o resultado
do servio, interagindo com o usurio. Existem diferentes tipos de Aplicaes
FrontEnd. Um exemplo desse componente uma aplicao de interface grfica,
como uma aplicao Web que utiliza um browser para a interao com o usurio,
fazendo a chamada do processo e recebendo o resultado da execuo de um
servio. Uma Aplicao Frontend desempenha um papel muito prximo ao Padro
de Projetos Facade (Fachada), onde um objeto disponibiliza uma interface que d
acesso a uma grande quantidade de funcionalidades de um subsistema, abstradas
do objeto que originou as chamadas. A Figura 12 ilustra um exemplo de Aplicao
FrontEnd.

Figura 12 Exemplo de Aplicao Frontend.
60

3.2.2 Servios

Um Servio pode ser entendido como uma funo do sistema computacional
construda de forma a ser facilmente vinculada a outros componentes de software,
que podem ser outros servios. O Servio tem papel fundamental dentro da
Arquitetura Orientada a Servios, pois encapsula uma funo de negcio que pode
ser reutilizvel, tendo como caractersticas marcantes a independncia de
tecnologias de linguagens de programao em sua implementao e baixo
acoplamento. A Figura 13 ilustra a composio de um servio com seus sub-
componentes.

Figura 13 Composio de um Servio na Arquitetura SOA.
Fonte: KRAFZIG apud MIRANDA (2008, p.28)

Cada servio deve conter um Contrato, que especifica restries quanto ao
acesso ao servio e uso dos servios. O contrato impe semntica sobre as
61

funcionalidades e parmetros do servio (DAVIES apud MIRANDA, 2008, p. 28). Os
servios tambm devem disponibilizar Interfaces, que definem as operaes
disponveis em um servio. As interfaces podem ser entendidas como as assinaturas
dos mtodos definidos em classes na Orientao a Objetos, onde descrito o tipo
de retorno, o nome da operao, sua visibilidade e argumentos.
A regra de negcio realizada pelo servio deve estar contido na
Implementao, que proporciona a execuo do servio utilizando a lgica de
negcio e os dados necessrios. Alem da lgica de negcios e dos dados, fazem
parte da Implementao os subprogramas, os dados e arquivos de configurao e a
base de dados.
SOA promove a idia de mdulos de software que prestam servios a outros
mdulos, com caractersticas e tecnologias diferentes. A concepo de servio tem
trs caractersticas principais, conforme mostra a tabela 06.

CARACTERSTICA DESCRIO
Interface
A descrio do servio atravs de uma interface, ou seja,
como aquele servio ser conhecido e como ele ser
acessado;
Contrato Definio de como se dar esse acesso pela sua interface;
Implementao
Sua implementao, ou seja, a funcionalidade por trs da
interface. Atualmente, essa abordagem converge para o
padro de Web Services. No passado, sistemas empresariais
operavam com diferentes tipos de interfaces, projetadas em
tecnologias distintas.
Tabela 6 Caractersticas da Concepo de Servios.

ERL (et al., 2008, p.28) identifica trs tipos fundamentais de servios:
62

Servio utilitrio: so servios que implementam algumas
funcionalidades gerais que podem ser utilizadas por diferentes
processos de negcios;
Servio de entidade: so servios associados a uma funo especfica
do de negcio;
Servio-tarefa: so servios que apiam os processos de negcios
mais gerais que envolvem diferentes atores e atividades.

3.2.3 Ciclo de Vida dos Servios

Segundo Miranda (2008, p. 30) os servios so considerados pedaos de
software que encapsulam alguma funcionalidade de negcios. Como tal, seu ciclo de
desenvolvimento comum aos softwares, consistindo nas fases de: modelagem,
implementao, integrao e execuo. O ciclo de vida de um servio pode aplicar o
modelo em cascata, porm, assim como no desenvolvimento de um software, no
o modelo ideal, podendo assumir um ciclo de vida iterativo, onde o desenvolvimento
de software pode ser ajustado com as experincias obtidas nas fases anteriores. A
Tabela 7 apresenta as etapas do ciclo de vida dos servios bem como a descrio
de cada etapa.

63

ETAPA DESCRIO
Modelagem
A fase de modelagem gera um produto: a especificao da
interface do servio. Esta interface inclui a semntica e os
atributos no funcionais;
Implementao
Esta a fase de codificao do servio, utilizando tecnologias
como linguagens de programao, protocolos de comunicao e
plataformas de desenvolvimento;
Integrao
Fase de adequao dos servios aos sistemas que faro uso da
Arquitetura SOA. a insero do servio no domnio do problema;
Execuo
Fase em que o servio estar disponvel para uma Aplicao
FrontEnd ou qualquer outro tipo de consumidor.
Tabela 7 - Fases do Ciclo de Vida do Servio
Fonte: MIRANDA (2008, p. 30).

3.2.4 Repositrio de Servios

Miranda (2008, p. 31) cita ainda que outra estrutura importante dentro da
arquitetura SOA o Repositrio de Servios , que fornece meios para facilitar a
descoberta de servios, bem como, as informaes referentes ao servio. Essas
informaes podem variar, podendo informar sobre a localizao fsica, pessoas de
contato, informaes sobre o fornecedor, utilizao de restries de segurana e
nveis do servio.
Geralmente, um Repositrio de Servios est associado ao escopo de uma
empresa ou organizao. possvel utilizar a arquitetura SOA sem um Repositrio
de Servios. Isso depende da quantidade de servios disponibilizados a nvel
empresarial. Por isso, por mais que uma empresa que esteja adotando SOA no
possua muitos servios a serem disponibilizados, interessante optar pela utilizao
de um repositrio, pois isso trar benefcios em longo prazo (KRAFZIG apud
MIRANDA, 2008, p. 31).
64

3.2.5 Barramento de Servios

Segundo Galdino (apud Miranda, 2008, p.31) o Barramento de Servios
interconecta todos os elementos da arquitetura SOA, funcionando como canal de
comunicao. Este barramento facilita o compartilhamento de servios dentro de
uma corporao, fornecendo transparncia na localizao dos servios. Se duas
aplicaes precisam se comunicar entre si, uma Aplicao de Frontend invoca as
funcionalidades de um servio utilizando o Barramento de Servios. importante
destacar que o barramento de servios no necessariamente composto por uma
tecnologia, podendo abranger uma grande variedade de solues tecnolgicas.
A Tabela 8 descreve as principais caractersticas do Barramento de Servio.

CARACTERSTICAS DESCRIO
Conectividade
Objetivo principal do Barramento de Servios. Permite
interligar os componentes de uma arquitetura SOA,
fornecendo facilidades que permitam ao FrontEnd
invocar as funcionalidades dos servios;
Tecnologias Heterogneas
O Barramento suporta uma gama de tecnologias, o
que geralmente a realidade das empresas, que em
sua maioria, adotam por solues distintas. Essas
tecnologias variam desde linguagens de programao,
sistemas operacionais, ambientes de execuo,
middlewares e protocolos de comunicao;
Servios Tcnicos
Embora a funcionalidade principal do Barramento de
Servios seja a comunicao entre componentes e
servios, o barramento tambm fornece alguns
servios como auditoria, segurana, transformao de
mensagens e transaes.
Tabela 8 Caractersticas do Barramento de Servios.
Fonte: MIRANDA (2008, p. 32).

65

3.3 Composio de Servios

Segundo Moreira (2007, p.32.) para solucionar problemas como distribuio e
heterogeneidade de aplicaes, surge a necessidade de composio de servios.
Esta tcnica permite modelar o processo de negcio e tambm aumenta a
possibilidade de aproveitar os benefcios da arquitetura orientada a servios.
O mecanismo da composio de servios visa combinar dois ou mais servios
para que, juntos, possam atender a requisitos que vo alm das suas capacidades
individuais. Em outras palavras, a composio prov uma abordagem aberta,
baseada em padres, para conectar Web Services objetivando criar processos de
negcio de alto nvel, com um alto valor agregado. A Figura 14 exemplifica uma
composio de servios.
Uma das principais motivaes para a utilizao da composio de servio
o desenvolvimento de processos de negcio envolvendo vrios parceiros e
seqncia de operaes.

Figura 14 Composio de Servios
Fonte: MOREIRA (2007, p.33).

66

Os padres so projetados para reduzir a complexidade requerida para
compor Web Services, reduzindo custo e tempo, e aumentando a eficincia global
nos negcios.
De acordo com Moreira (2007, p. 33), a composio de servios deve atender
as seguintes exigncias:

Habilidade de invocar servios de maneira assncrona, alcanando
confiabilidade, escalabilidade e adaptabilidade, caractersticas
necessrias em um ambiente de negcios;
Gerenciar a integridade transacional e de excees;
Prover uma clara separao entre a lgica do processo e os Web
Services usados;
Ser capaz de compor servios de alto nvel de processos existentes.

A composio de servios faz uso de vrios servios para criar um servio
e/ou o uso de um servio por outro servio vai se tornando mais comum, para a
criao de processos, para isso dois conceitos so muito importantes: orquestrao
e coreografia, como visto na figura 15.

Figura 15 Orquestrao e Coreografia.
Fonte: LEITO e MARGALHO JUNIOR (2007, p.25)

67

3.3.1 Orquestrao

As interaes do processo de negcios so controladas por uma das partes
envolvidas no processo. A orquestrao envolve interaes entre as partes e os
passos entre as interaes (FANTINATO; TOLEDO; GIMENES apud SOUZA, 2008,
p.61).

Empresas que tm sistemas legados interconectados ou processo de
negcio trabalhando em conjunto necessitam comumente de uma unidade
controladora, a fim de facilitar o processo de interoperabilidade entre tais
sistemas. Essa soluo conhecida como orquestrao de servios. A
forma de implementao 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 criao de orquestraes o fato de unir
processos de negcio. Com a orquestrao, diferentes processos podem ser
conectados sem que seja necessrio desenvolver novamente as sua
funcionalidades em um novo sistema. O uso da orquestrao pode reduzir
significativamente a complexidade de implementao, bem como facilitar a
manuteno dos sistemas (ERL, 2005, p. 203).
A Figura 16 exibe o funcionamento do processo de orquestrao de servios.
O coordenador central (por exemplo, um Web Service) recebe uma mensagem do
Web Service 1 requisitando alguma informao. O coordenador invoca alguns
parceiros a fim de agrupar a informao e ento retorna o resultado para o Web
Service 1. Este tipo de processo pode ser conhecido como privado e executvel, j
que apenas a entidade que est orquestrando o processo conhece o fluxo de
controle e informao que o segue. A principal tcnica de implementao da
orquestrao atravs da linguagem BPEL.

68

Figura 16 Exemplo de processo de orquestrao de servios

3.3.2 Coreografia

Diferentemente da orquestrao, a coreografia de servios no concentra o
fluxo de controle em uma nica unidade. Ao invs de um nico coordenador, todos
os servios envolvidos na operao conhecem quando e com quem iro interagir,
havendo uma cooperao entre os servios, cada um conhecendo o seu papel
dentro do fluxo. A colaborao efetuada atravs da troca de mensagens entre os
servios participantes (MOREIRA, 2007, p. 34).
Ao invs de um nico coordenador, todos os servios envolvidos na operao
conhecem quando e com quem iro interagir, havendo uma cooperao entre os
servios, cada um conhecendo o seu papel dentro do fluxo. A colaborao
efetuada atravs da troca de mensagens entre os servios participantes. A figura 17
exemplifica o funcionamento da coreografia de servios.

Comparando as duas abordagens, a orquestrao se difere da coreografia
por descrever um fluxo de processo entre servios controlados por uma
nica entidade. Por outro lado, coreografia mais colaborativa no sentido
de que ela traa a seqncia das mensagens entre os participantes
envolvidos, em que nenhum deles controla a conversao (MOREIRA,
2007, p. 35).
69

Figura 17 Exemplo de Coreografia de servios

As vantagens da orquestrao segundo ALLEMANN (apud SOUZA, 2008,
p.63) sobre a coreografia sobre o ponto de vista de um processo de negcio so
dadas pela sua alta flexibilidade, so elas:

A coordenao de componentes gerenciada centralmente por
um coordenador;
Flexibilidade: por exemplo, a incorporao de uma Web Service
em um grande processo de negcio sem que haja um
conhecimento explcito;
Tolerncia a faltas, permitindo cenrios alternativos.

70

3.3.3 BPEL

A BPEL foi criada em 2003, inicialmente pela Microsoft em parceria com a
IBM, SAP e Sibel, aps algum tempo o seu controle de padro foi passado para a
OASIS (Organization for the Advancement of Structured Information Standards).
Esta linguagem descreve os processos de negcios e os protocolos de
negcios de Web Services, que so tratados por um script baseado em XML que
descrevem a lgica de controle de cada processo e protocolo. Esse script ser
interpretado em uma mquina intermediaria que ir realizar o controle da
composio. Em sua lgica de negcio que seqencia, coordena e gerencia a
comunicao entre Web Services dentro de uma aplicao de negcio. BPEL
apontado como uma ferramenta fundamental para empresas que querem
economizar tempo de desenvolvimento, reduzir custos na entrega de novas
solues e manuteno de aplicaes existentes.

A linguagem de execuo de processos de negcios (WS-BPEL Business
Execution Language), que uma linguagem de programao baseada em
XML para controlar as interaes dos servios.(SOMMERVILLE apud
SOUZA, 2008,p.54).

A figura 18 demonstra um fluxo de processo BPEL, onde a parte central da
figura representa a mquina intermediria, que realiza a orquestrao e coreografia.
Dentro dela existem passos que definem e controlam o fluxo da transao, alm de
realizar controles de tratamento de excees e transaes, papis e parceiros e
persistncia e variveis do Web Services que trabalham no entorno dela.

71

Figura 18 Fluxo de Processo BPEL.
Fonte: LEITO e MARGALHO JUNIOR (2007, p.27)

Portanto, BPEL um padro de linguagem que manipula estrutura de dados
XML, recebe mensagens XML assncronas de servios remotos e ainda gerencia
eventos e excees, retornando partes do processo quando essas excees
ocorrem, tornando os Web Services mais poderosos para quebrar barreiras
invisveis de integrao entre empresas parceiras ou fornecedoras/clientes, sem ter
problemas com comunicao.
Um processo especificado em BPEL consiste em dois tipos de atividades:
atividades bsicas apresentadas no Quadro 01 e atividades estruturadas
apresentadas no Quadro 02. Estas determinam a estrutura, a seqncia do
processo, j aquelas determinam o que acontecer no processo, por exemplo, o
recebimento de uma mensagem de um Web Service.

72

Quadro 1 Atividades bsicas de BPEL

No Quadro 02, so ilustradas as atividades estruturadas, as quais definem a
ordem em que as atividades devem ser realizadas.

Quadro 2 Atividades Estruturadas de BPEL.

73

Moreira (2007, p. 36 - 37) cita que o BPEL prov expresses para
comportamentos condicionais, para loops, para declarar variveis, para copiar e
atribuir valores. As especificaes baseadas em BPEL utilizam o XML para
descrever aspectos do processo.
Os principais elementos de um documento BPEL esto representados na
Figura 19.

Figura 19 Estrutura bsica de uma especificao BPEL.

74

A tag partner especifica os participantes da composio. Normalmente, neste
local so armazenados os endereos dos servidores que esto disponibilizando os
Web Services. Outro recurso utilizado o de partner links (<partnerLink>), o qual
define as diferentes partes que interagem com o processo (MOREIRA, 2007, p. 37).
A tag variables define as variveis utilizadas no processo. Essas variveis
podem ser inicializadas, copiadas para outros servios e at alteradas. As variveis
representam uma grande vantagem do uso deste padro: a possibilidade de
armazenar estados durante a execuo da composio.
A tag correlationSets identifica para qual instncia de processo uma nova
mensagem recebida deve ser roteada. Este elemento tambm responsvel por
no permitir que existam duas interaes distintas de Web Services caso elas sejam
oriundas do mesmo parceiro.
A seo faultHandlers define as atividades que devem ser realizadas em
resposta falhas resultantes da invocao de servios. Em associao com a tag
faultHandlers, a tag compensationHandlers reverte atividades completadas,
retornando ao seu estado inicial (MOREIRA, 2007, p. 38).
A WS-BPEL tambm fornece uma maneira de tratar eventos
concorrentemente execuo do processo atravs do uso da tag eventHandlers.
Como exemplo de eventos possvel citar o estouro de tempo de determinada
operao. O resto da definio do proccess composto de atividades (activity)
(ROCHA apud SOUZA, 2008, p.58).
Na figura 20, apresentado um exemplo da interface de um programa
executvel, que foi concebida aps a disponibilizao do projeto e modelada
utilizando a linguagem BPEL, desta forma possibilitando uma comunicao entre
processos independente da linguagem de programao, graas utilizao de XML
(ROCHA apud SOUZA, 2008, p.59).

75

Figura 20 Interface Grfica modelada pelo BPEL atravs da ferramenta Eclipse.

3.4 Camadas de Abstrao

Segundo Bieberstein (apud Miranda, 2008, p.22) a arquitetura SOA est
basicamente voltada ao uso de servios, que constituem a abstrao de uma ou
mais regras de negcio. Porm, h mais camadas de abstrao envolvidas no uso
da Arquitetura Orientada a Servios como: Camada Corporativa, Camada de
Processos, Camada de Servios, Camada de Componentes e Camada de Objetos.
A Figura 21 mostra a composio de SOA atravs de suas camadas de
abstrao.

76

Figura 21 Camadas de Abstrao de SOA.
Fonte: BIEBERSTEIN apud MIRANDA (2008. P. 22)

3.4.1 Camada Corporativa

Esta camada descreve as operaes empresariais realizadas por uma
determinada organizao ou empresa. Nesta camada estaro os procedimentos
relevantes das atividades de negcios empresariais pertencentes a uma
determinada corporao (MIRANDA, 2008, p. 22).

3.4.2 Camada de Processos

A camada de processos identifica como alguns processos podem ser
modelados e posteriormente implementados como servios. Nesta camada, utiliza-
se referncia aos procedimentos necessrios para a realizao dos negcios
empresariais (MIRANDA, 2008, p. 23).

77

3.4.3 Camada de Servios

Nesta camada, os servios so mapeados por suas funcionalidades bsicas e
de negcios, identificando as aes crticas para satisfazer as regras de negcio.
Esta camada abrange os servios de todas as naturezas para fins especficos. Cada
servio desta camada pode ser decomposto em vrios outros servios simples que
podem ser implementados utilizando componentes (MIRANDA, 2008, p. 23).
necessrio que a orientao a servios seja propagada por toda a
corporao. Isso pode ser alcanado pela abstrao das camadas de servio (ERL
apud SOUZA, 2008, p.35).
Nas palavras de Baldam (2008, p. 104), o conceito da orientao a servios
expressa a inteno de disponibilizar aplicativos ou rotinas independentes como
servios, em uma rede de computadores (Internet ou Intranet), comunicando se por
padres abertos. A estrutura da organizao pode ser dividida em lgica de negcio
e lgica de aplicao, como apresentado na figura 22.

Figura 22 O negcio e os domnios da lgica da aplicao.
Fonte: ERL apud OLIVEIRA (2008, p.70).
78

A camada de interface de servios da organizao localiza-se entre as
camadas de processo de negcio e de aplicao. Esta camada pode ser divida em
trs tipos de servios, como mostra a figura 23 (ERL apud MOREIRA, 2007, p.27),
os quais sero detalhados posteriormente:

Servios de Utilidades;
Servios de Negcios;
Servios de Coordernao.

Figura 23 As trs principais camadas de servios.
Fonte: ERL adaptado por MOREIRA (2007, p.28).

3.4.3.1 Camada de Servio de Aplicao

A camada de servios de aplicao estabelece o nvel base para expressar
79

funcionalidades com uma tecnologia especfica. O seu propsito prover funes
reusveis relacionadas ao processamento de dados de um sistema novo ou legado
(MOREIRA, 2007, p. 28). A figura 24 ilustra esta camada.
Os servios de aplicao, como so chamados os servios desta camada,
tm como caractersticas principais as seguintes:

Expem funcionalidades dentro de um contexto especfico;
So genricos e reusveis;
Podem ser usados para atingir uma integrao ponto a ponto com
outros servios de aplicao.

Figura 24 Servios utilitrios da camada de servio de aplicao.
Fonte: MOREIRA (2007, p. 49).

Segundo Erl (apud Oliveira, 2008, p. 72), exemplos tpicos deste modelo de
servios so servios utilitrios e wrapper. Os servios dessa camada podem conter
80

lgicas de negcio e de aplicao, este modelo comumente encontrado nos
sistemas distribudos atuais, contudo, sua utilizao no recomendada. Ao invs
disso, os servios de aplicao podem ser facilmente compostos com outros
servios.

3.4.3.2 Camada de servios de negcio

Enquanto os servios de aplicao representam a lgica da aplicao
utilizada para expressar uma funcionalidade especfica, a camada de servios de
negcio introduz um servio centrado apenas em reproduzir a lgica de negcio,
representando a implantao de algum modelo de negcio, esta camada ilustrada
na figura 25 (MOREIRA, 2007, p. 29). Esses servios so a base da arquitetura
orientada aos servios.

O nico propsito para os servios de negcio representar lgica de
negcio da forma mais pura possvel. Um servio de negcio pode ser
classificado como um servio controlador ou um servio utilitrio, por
exemplo. Quando a lgica de aplicao abstrada em uma camada de
servios de aplicao, normal que os servios de negcio sejam
controladores que compem servios de aplicao a fim de executar a sua
lgica de negcio (ERL apud OLIVEIRA, 2008, p.73).

81

Figura 25 Servio ServicoSalvarGrupo nas camadas de Aplicao e Negcios.
Fonte: MOREIRA (2007, p. 51).

Os servios desta camada podem ser classificados em dois modelos:

Servios de negcios centrados em tarefas: encapsula a lgica
especfica para uma tarefa ou processos de negcio. Esse servio tem
um potencial de reuso baixo;

Servios de negcio centrados em entidade: encapsula uma entidade
de negcio especfica. Estes servios so bastante teis para a criao
de servios por serem altamente reusveis. Geralmente so
compostos em uma camada de orquestrao ou por um servio
centrado a tarefa (MOREIRA, 2007, p. 29).

82

3.4.3.3 Camada de servio de orquestrao

Esta camada introduz um nvel de abstrao que diminui a necessidade dos
servios gerenciarem detalhes de interao para garantir que as operaes sejam
executadas em uma ordem seqencial correta. Dentro desta camada, os processos
compem outros servios que provem conjuntos especficos de funes,
independentes das regras de negcio e cenrio requeridos para executar uma
instncia de processo (ERL apud MOREIRA, 2007, p. 29).

3.4.4 Camada de Componentes

Os componentes utilizados nesta camada so blocos de construo de
servios, que podem englobar uma ou mais rotinas escritas em determinada
linguagem de programao. Esses componentes so mapeados em servios ou so
mapeados para se adequarem a servios (MIRANDA, 2008, p. 23).

3.4.5 Camada de Objetos

Esta camada contempla a larga quantidade de classes de objetos, seus
atributos e relacionamentos utilizados em componentes para compor os servios de
uma SOA. Em arquiteturas de SOA modernas, servios so implementados
utilizando os objetos (MIRANDA, 2008, p. 23).

83

3.5 Ciclo de vida SOA

A arquitetura SOA est definida em quatro estgios distintos que compem
seu ciclo de vida. Esses estgios so compostos por etapas que contemplam a
estratgia na elaborao de uma soluo utilizando a Arquitetura SOA, a
modelagem necessria para as regras de negcios, a implementao, que
corresponde codificao dos servios e o monitoramento dos resultados da SOA.
A Figura 26 ilustra as quatro fases do ciclo de vida de SOA (MIRANDA, 2008, p. 24).

Figura 26 Ciclos de Vida de SOA.

84

As etapas do ciclo de vida de SOA, bem como suas descries, conceitos e
caractersticas sero abordadas com maiores detalhes nas quatro sees a seguir.

3.5.1 Estratgia

Corresponde ao primeiro estgio do Ciclo de Vida de uma Arquitetura
Orientada a Servios. Neste estgio, so definidas algumas diretrizes para o uso de
SOA: as atividades que estaro no escopo da Arquitetura; o foco dos processos e
medidas estratgicas com a adoo da Arquitetura Orientada a Servios.
Segundo Erl (2008, p. 300), escolher uma abordagem de entrega uma
deciso crucial, porque representa a escolha com a qual a organizao normalmente
ter de conviver por bastante tempo.

3.5.1.1 Bottom-up

Segundo Erl (2008, p. 299) a estratgia de bottom-up evita custos, esforos e
tempo extras necessrios para entregar servios por meio de uma abordagem top-
down, ela acaba impondo maior carga de governana, porque os servios entregues
bottom-up tendem a ter tempos de vida mais curtos e exigem manuteno e
refatorao mais freqentes.

85

3.5.1.2 Top-down

Erl (2008, p. 299) explica que a estratgia top-down exige mais de um
investimento inicial porque cria uma etapa de anlise positiva, concentrada na
criao do esquema de um inventrio de servios. Uma coleo de candidatos a
servio individualmente definida como parte desse esquema para assegurar que
os designs de servio subseqentes sejam altamente normalizados, padronizados e
alinhados.

3.5.2 Modelagem

Segundo Miranda (2008, p. 25) este segundo estgio do Ciclo de Vida SOA
corresponde a modelagem de processos de negcios. Esta modelagem engloba um
conjunto de prticas ou tarefas realizadas pelas instituies para descrever
visualmente todos os aspectos de um processo de negcio, incluindo seus principais
pontos de deciso para a execuo das atividades. Essa descrio visual
normalmente compreensvel pela maioria das pessoas envolvidas nas
implementaes dos processos de negcios. Em gesto de TI, esse estgio
denominado de Business Processes Management (Gerenciamento de Processos de
Negcios), alternativamente chamado de Business Processes Modeling (Modelagem
de Processos de Negcio). A figura 27 demonstra as atividades do ciclo de vida
associados com os servios no ambiente SOA.

86

Figura 27 Atividades do ciclo de vida com os servios no ambiente SOA.
Fonte: GU e LAGO (2007, p.4).

3.5.3 Implementao

Neste estgio, o foco o desenvolvimento dos servios, ou seja, sua
codificao em alguma plataforma e linguagem de programao, levando em
considerao as tecnologias de implementao disponveis e as decises tomadas
nos estgios anteriores quanto a adoo da Arquitetura SOA, tanto nas tomadas
estratgicas quanto nas modelagens definidas pelos gestores e analistas
(MIRANDA, 2008, p. 25).

3.5.4 Monitoramento (Business Activity Monitoring)

O estgio de monitoramento encerra um ciclo de vida da Arquitetura SOA.
Este estgio, tambm chamado de Business Activity Monitoring BAM
87

(Monitoramento de Atividade de Negcio), permite que seja feita a anlise em tempo
real dos dados trafegados em uma rede atravs do uso de um software que analisa
os dados e exibe informaes gerenciais como resultado (MIRANDA, 2008, p. 26).

3.6 Web Services

A necessidade de conectar informaes e processos mudaram a forma como
o software vem sendo desenvolvido. Sistemas bem-sucedidos de TI exigem cada
vez mais interoperabilidade entre plataformas e servios flexveis que possam
evoluir facilmente com o tempo. Segundo o Word Wide Web Consortium (W3C), a
tecnologia de Web Services fornece um mecanismo padro de interoperabilidade
entre diferentes aplicaes de softwares, executando em uma variedade de
plataformas ou frameworks (W3C, 2009).
apontado como uma grande vantagem dos Web Services, a utilizao de
baixo acoplamento entre sistemas e sua interoperabilidade, alm de usar padres
abertos baseados em XML como WSDL, SOAP .e UDDI. Abaixo na figura 28
demonstrada a arquitetura do Web Services.

As Arquiteturas de aplicao dos Web Services so arquiteturas no
firmemente acopladas nas quais as ligaes de servios podem mudar
durante a execuo. Alguns sistemas sero somente construdos com a
utilizao de Web Services e outros os integraro com componentes
desenvolvidos localmente (SOMMERVILLE, 2003,p.191)

88

Figura 28 Arquitetura Web Services
Fonte: MOREIRA (2007, p.3)

Segundo Sommerville (2003, p.191), os trs padres fundamentais que
possibilitam comunicaes entre Web Services so:

1. SOAP (Simple Object Acess Protocol) Protocolo que define uma
organio para troca estruturada de dados entre Web Services.

2. WSDL (Web Services Description Language) Protocolo que define
como as interfaces dos Web Services podem ser representadas.

3. UDDI (Universal Description, Discovery and Integration) Padro de
descoberta que define como as informaes de descrio do
servio, usadas pelos solicitantes do servio para descobrir servios,
pode ser organizada.

89

4. PROJETO NEW_RCMS: ESTUDO DE CASO

O mtodo de pesquisa adotado para a realizao deste trabalho foi o estudo
de caso, com o objetivo de analisar um caso prtico de implantao do
gerenciamento de processos de negcio em um departamento de Service Desk. O
levantamento de informaes utilizado para esse estudo de caso baseou-se em
etnografia e anlise dos dados atuais e de documentos.

4.1 Descrio do ambiente de pesquisa

O estudo de caso realizou-se dentro do contexto de uma organizao que
atua no mercado de prestao de servios de TI, neste segmento ela est
posicionada em primeiro lugar no Brasil. A empresa tem atuao no mercado
nacional e internacional. Sua diversificada atuao inclui Outsourcing, centros de
pesquisas tecnolgicos, desenvolvimento de hardware e software e solues de TI.
Os trabalhos de pesquisa junto empresa consistiram em entrevistas com
profissionais responsveis pela rea de Processos e usurios. Esta rea em
conjunto com o time de TI, foram os responsveis pela implantao do BPM na
empresa.

4.2 Implantao do BPM na organizao

Para garantir um maior controle e a gerao de informaes mais confiveis
para o monitoramento de suas atividades, a organizao buscou atravs do
90

gerenciamento de seus processos, uma soluo estratgica capaz de auxiliar a
gesto e otimizao dos processos de negcio.
Analisando a forma como o processo era realizado, possvel identificar
alguns pontos que impactavam a gesto dos processos:

Constante ocorrncia de erros;
Controle inadequado dos processos;
Dificuldade para realizar melhorias;
Altas taxas de abandono em ligaes;
Perda de SLAs estabelecidos em contrato;
Clientes insatisfeitos.

A ocorrncia de problemas, devido a falhas no processo, problemas externos
de hardware, software ou erros humanos, era dificilmente detectada durante a
execuo dos processos, desta forma, impactando diretamente a produtividade, e
como conseqncia perda de SLA (porcentagem de servio de acordo com o
contrato) e constantes reclamaes de seus clientes.
O controle e monitoramento dos processos tornam-se falhos devido a pouca
visibilidade dos processos, a possvel inconsistncia de dados como conseqncia
da perda de informaes e a dificuldade de automao das mtricas.
O BPM possibilitou o gerenciamento e a otimizao dos processos de
negcio, por meio da elaborao de workflows para controle e aprovao de
processos, bem como a visualizao das etapas que compe o fluxo da operao,
identificando possveis pontos de melhorias ou gargalos do processo, possvel
tambm identificar em qual estgio do processo as atividades se encontram.
Depois da definio das metas estratgicas, os processos crticos so
modelados, simulados e documentados pela rea de negcio, com o apoio dos
analistas de negcio e de ferramentas de modelagem, os KPIs so identificados
para posterior gerenciamento dos processos. A rea de TI identifica as
oportunidades de integrao e automao do processo desenhado.
91

Aps estas etapas o processo entra em operao, os usurios iro acessar as
atividades do processo atravs de portais via Web. Os processos so executados e
gerenciados, extraindo-se o histrico e as tendncias, que sero utilizadas pela
gerncia como fonte de informao para auxiliar a tomada de deciso.
Atravs da habilidade de entender como os processos ocorrem, intensifica-se
a capacidade de identificar e implantar melhorias importantes para a organizao.
A utilizao da abordagem de arquitetura orientada a servios como melhores
prticas, garante que os processos implantados estejam flexveis para possveis
mudanas das necessidades de negcios.

4.3 Modelagem do processo de negcio de Atendimento de Chamados

Para ilustrar a aplicao do gerenciamento de processos de negcio no
departamento de Service Desk, na qual este estudo foi realizado, essa fase
apresenta a modelagem de um processo atravs de uma ferramenta de notao
BPM. O processo de negcio escolhido para esta transcrio foi o de Fluxo de
atendimento a chamados.
Com base na coleta de dados feito no Service Desk, foram identificados os
principais sistemas, aplicativos e base de dados necessrios para o
desenvolvimento do modelo:

92

SISTEMA DESCRIO
RCMS
Sistema de gerenciamento de chamados de Hardware (sistema Legado),
utilizados pelos analistas do Service Desk, especialistas e clientes.
RETAIN
Sistema de gerenciamento de chamados para Software e Hardware (Sistema
Legado), utilizados pelos analistas do Service Desk, especialistas e clientes.
RTS/PIMS Sistema de pedido de pea.
PORTAL WEB Sistema para clientes abrirem chamados via internet.
WEB LINK
Link direto com a rede da empresa onde os prprios equipamentos abrem um
chamado no RCMS.
PDA
Os PDAs possuem uma aplicao desenvolvida em Java que acessa o
sistema da empresa via internet (tecnologia 3G), dessa forma os tcnicos
fazem atualizaes nos chamados sem precisar ligar na URA do Service Desk.
IRCM
Repositrio de dados informativos do RCMS do Brasil e o tipo de informao
que contm chamados de manuteno de servios de hardware, a informao
provm do RCMS 7.5. Brasil.
LAI2 Banco de dados de gerenciamento de chamados.
YRSX Brasil
SSAC Argentina
OSAR Mxico
FEMS Sistema automtico de proposta e contrato.
PASS PASS banco de dados de inventrio de HW
LA CCPF
Os dados de cliente e inventrio de SW e HW so enviados para o RETAIN
(informaes legadas). Este aplicativo uma interface que pesquisa
informaes do cliente dentro do RCMS / HW / SW / dados de inventrio e os
baixa em perfis de cliente do RETAIN.
CROS Banco de dados de cliente.
PPRF Banco de dados de produtos.
PASS HW Banco de dados de inventrio.
XPOC Banco de dados de parceiros.
Tabela 9 Principais sistemas do Service Desk.
Fonte: do autor.
93

A figura 29 apresenta uma viso macro da arquitetura dos sistemas que se
integram e alimentam a base de dados do RCMS para que ele carregue todas as
informaes dos clientes (cdigo de cliente, informaes de contrato, tipo de
contrato, localidade, produtos com cobertura de garantia, produtos com contrato,
produtos sem contrato).

Figura 29 Arquitetura de todos os sistemas do departamento.
Fonte: do autor.

Inicialmente, o projeto foi executado com a modelagem do estado atual (As
Is). A coleta dos dados ocorreu a partir da interao entre os envolvidos nos
processos analisados e a equipe responsvel pelos processos, atravs da
observao in-loco e de entrevistas. A partir das informaes coletadas, os
94

processos comearam a se construdos, utilizou-se nesta etapa uma ferramenta de
modelagem de processos baseados na notao grfica BPMN. O quadro 03
descreve o processo de negcio no seu estado atual:

DESCRIO DO PROCESSO DE NEGCIO (As Is)

1 - Cliente Liga no Call Dispatch, Analista questiona se seria abertura de chamado, ou se j possui chamado em
aberto de Hardware ou de Software.

2 - Call Dispatch presta o 1 atendimento onde cliente fornece os dados necessrios para abertura do chamado
para Hardware:

Tipo e srie do equipamento;
Nome da empresa;
Endereo;
Telefone;
Pessoa de contato;
Problema.

*Caso o cliente informe tipo e srie do equipamento incorretamente, chamado ser direcionado para uma fila
de inventrio, onde chamado s ser atendido depois de ser liberado por essa fila.

*Call Dispatch monitora todas as filas de atendimento para hardware e caso cliente tenha contrato de
cobertura aloca tcnico de planto para o atendimento.

Para Software:

Cdigo de Cliente;
Produto;
Sistema Operacional;
Tipo e srie do equipamento (se necessrio);
Pessoa de contato;
Telefone;
Problema.

*Caso cliente no possua contrato, o mesmo estar sujeito a ser faturado, se quiser ter atendimento.
Feito isso, caso haja necessidade Call Dispatch direciona chamado para o 2 nvel de atendimento.

3 - Caso Cliente j possua chamado em aberto, Call Dispatch direciona chamado para departamento
responsvel.

4 - Caso seja chamado de Software cliente direcionado para Departamento CAC ADM ou fora do horrio
comercial para gerente onduty e o mesmo decide se chamado ser atendido ou no.

5 - Analista de software faz atualizaes no chamado e descreve todas as aes que foram tomadas para
soluo do problema, chamado pode ser finalizado ou continuar em aberto caso ainda no tenha sido
solucionado.

6 - Caso Seja chamado de Hardware o mesmo direcionado aos tcnicos de planto.

7 - Tcnico liga no Call Dispatch, atualiza o chamado e informa quais medidas foram tomadas para soluo do
problema, chamado pode ser finalizado ou continuar em aberto caso ainda no tenha sido solucionado.

8 - Clientes que possuem Link Direto com a empresa, os prprios equipamentos abrem chamados diretamente
no sistema, quando apresentam algum problema, se chamado for para hardware repassado para o tcnico
com acionamento via voz, se for de software os analistas de Software so informados pelo Call Dispatch via voz
e entram em contato com cliente.

9 - Se as Informaes providas pelo cliente sejam incorretas, chamado poder ser cancelado pelo analista de
95

software ou tcnico.

10 - Clientes que abrem chamado no Portal Web tm acesso ao sistema da empresa com senha e login,
chamado repassado para o tcnico via voz, no caso de analistas de Software, os mesmos so informados
pelo Call Dispatch via voz e entram em contato com cliente.

11 - Se as Informaes providas pelo cliente sejam incorretas, chamado cancelado pelo analista ou tcnico.

12 - Fim do Processo de atendimento ao cliente.

13 - Tcnicos/Especialistas ligam no Call Dispatch e solicitam pedido de pea para trmino da manuteno, o
mesmo fornece seus dados como matrcula e um cdigo de segurana que diferente para cada territrio,
nmero da pea, quantidade e a emergncia. Pedido da pea solicitado no sistema e Estoque envia pela
transportadora.

14 - Caso alguns dos dados esteja incorreto pedido no poder ser consumado.

15 - Tcnicos ligam no Call Dispatch para fazer algumas atualizaes nos chamados.

16 - Fim do Processo de Atendimento a tcnicos.

17 - Call Dispatch monitora todas as filas de atendimento para hardware e caso cliente tenha contrato de
cobertura aloca tcnico de planto e repassa chamado.

Quadro 3 Processo de atendimento (As Is).
Fonte: do autor.

A notao de modelagem de processo de negcio aplicada no estudo de caso
foi a BPMN, j que por meio da utilizao dessa notao, possvel ilustrar um
processo de negcio de forma simplificada e de fcil compreenso. Para a
modelagem do processo escolhido foi utilizada a ferramenta BizAgi Process Modeler
desenvolvido pela empresa BizAgi Ltda.
A figura 30 ilustra a modelagem no estado atual (As Is), a figura demonstra o
processo de atendimento, este fluxo ilustra as informaes descritas no quadro 03.
96

Figura 30 Processo modelado (As Is).
Fonte: do autor.
97

Aps o projeto ter sido executado com a modelagem do estado atual (As Is) e
a equipe responsvel pelos processos ter feito toda a coleta dos dados, essas
informaes coletadas foram processadas e originaram um novo modelo com
processos mais integrados e que agregam maior valor ao negcio.
Com a utilizao de conceitos SOA o novo modelo integra os principais
sistemas utilizados pelos analistas do Service Desk (RCMS, RETAIN, PIMS) em um
nico Frontend. Alm da integrao foi verificado que alguns clientes registravam
um alto nmero de ocorrncias dirias, ento foi criado um portal web (Web
Services) voltado para esses clientes, dessa forma eles podem abrir chamados via
web, oferecendo maior comodidade e diminuindo a volumetria de ligaes no
Service Desk.
Os tcnicos precisavam ligar na URA do Service Desk para atualizar os
chamados, agora utilizam uma aplicao desenvolvida em Java pelo PDA que
conversa com o sistema RCMS via Web Services. Os tcnicos s necessitam ligar
na URA do Service Desk em casos especficos como: a bateria do PDA acabou,
precisam falar com especialista de plataforma de planto para autorizao de pedido
de pea em emergncia mxima para o trmino do atendimento.

DESCRIO DO PROCESSO DE NEGCIO (To Be)

1 - Cliente Liga no Call Dispatch e Analista questiona se seria abertura de chamado, ou se j possui chamado
em aberto de Hardware ou de Software.

*Chamado pode ter sido aberto pelo portal Web ou at mesmo Link Direto caso o cliente possua.

2 - Call Dispatch presta o 1 atendimento onde cliente fornece os dados necessrios para abertura do chamado
para Hardware:

Tipo e srie do equipamento;
Nome da empresa;
Endereo;
Telefone;
Pessoa de contato;
Problema.

*Caso o cliente informe tipo e srie do equipamento incorretamente, chamado ser direcionado para uma fila
de inventrio, onde chamado s ser atendido depois de ser liberado por essa fila.

*Call Dispatch monitora todas as filas de atendimento para hardware e caso cliente tenha contrato de
cobertura analista aloca tcnico de planto.
Para Software:

Cdigo de Cliente;
Produto;
98

Sistema Operacional;
Tipo e srie do equipamento (se necessrio);
Pessoa de contato;
Telefone;
Problema.

*Caso cliente no possua contrato, o mesmo estar sujeito a ser faturado, se quiser ter atendimento.

**Chamados que no tenham contrato precisam ser liberados pelo Gerente Onduty de planto.

3 - Feito isso caso haja necessidade Call Dispatch direciona chamado para o 2 nvel de atendimento.

4 - Caso Cliente j possua chamado em aberto, Call Dispatch direciona chamado para departamento
responsvel.

5 - Caso seja chamado de Software cliente direcionado para Departamento CAC ADM ou fora do horrio
comercial para gerente onduty e o mesmo decide se chamado ser atendido ou no.

6 - Analista de software faz atualizaes no chamado e descreve todas as aes que foram tomadas por ele para
soluo do problema, chamado pode ser finalizado ou continuar em aberto caso ainda no tenha sido
solucionado.

7 - Caso Seja chamado de Hardware o mesmo direcionado aos tcnicos de planto.

8 - Tcnico atualiza o chamado e informa quais medidas foram tomadas para soluo do problema, chamado
pode ser finalizado ou continuar em aberto caso ainda no tenha sido solucionado.

9 - Clientes que possuem Link Direto com a empresa, os prprios equipamentos abrem chamados diretamente
no sistema, quando apresentam algum problema, se chamado for para hardware repassado para o tcnico via
PDA, se for de software os analistas de Software monitoram filas de atendimento e entram em contato com
cliente.

10 - Se as Informaes providas pelo cliente sejam incorretas, chamado poder ser cancelado pelo analista de
software ou tcnico.

11 - Clientes que abrem chamado no Portal Web tm acesso ao sistema da empresa com senha e login,
chamado repassado para o tcnico via PDA, no caso de analistas de Software, os mesmos monitoram filas de
atendimento e entram em contato com cliente.

*Caso o cliente no receba nenhum contato do tcnico ou analista de Software, ele liga no Call Dispatch para
cobrar uma posio do chamado.

12 - Se as Informaes providas pelo cliente estiverem incorretas, chamado cancelado pelo analista de
software ou tcnico.

13 - Fim do Processo de atendimento ao cliente.

14 - Tcnicos/Especialistas Solicitam pedido de pea para trmino da manuteno, o mesmo fornece seus dados
como matrcula e um cdigo de segurana que diferente para cada territrio, nmero da pea, quantidade e a
emergncia. Pedido da pea solicitado no sistema e Estoque envia pela transportadora.

15 - Caso alguns dos dados esteja incorreto pedido no poder ser consumido pelo estoque.

16 - Tcnico Utiliza PDA por onde recebem os chamados, pelo PDA conseguem acesso ao sistema RCMS e
podem fazer algumas atualizaes nos chamados.

*Algumas atualizaes s podem ser feitas pelo Call Dispatch.

17 - Fim do Processo de Atendimento a tcnicos.

Quadro 4 Processo de atendimento (To Be).
Fonte: do autor.

99

A figura 31 ilustra a modelagem no estado futuro (To Be), que demonstra o
processo de atendimento. Este fluxo apresenta as informaes descritas no quadro
04. Comparando esta modelagem com a anterior podemos ver que h um novo Pool
com a Lane denominada Portal Web, no caso o portal que foi criado para os
clientes que abrem muitos chamados no Service Desk.
No Pool dos tcnicos podemos ver que algumas das atividades tambm
mudaram agora eles recebem avisos dos chamados via PDA, quando algum
chamado atualizado ou quando h um novo chamado, o servidor de mensagens
envia automaticamente uma mensagem de aviso e atualiza no chamado com data e
horrio assim que o tcnico ler a mensagem.
100

Figura 31 Processo modelado (To Be).
Fonte: do autor.
101

4.4 Resultados obtidos

A partir da implantao do BPM, o departamento responsvel pelo
desenvolvimento dos processos da empresa obteve uma maior visibilidade,
identificando com mais facilidade, as reas mais relevantes que fazem parte do
processo e observando-se se esses processos so executados corretamente.
Tambm foi possvel identificar os processos que esto integrados e a comunicao
entre eles e a necessidade de remodelar alguns processos.
Identificou-se a maior confiabilidade das informaes geradas, as informaes
so mais confiveis devido ao maior controle e automao, proporcionada pelas
ferramentas de gesto de processos.
O conhecimento sobre os processos tornou-se mais consistente, as
informaes so extradas em tempo real, facilitando a anlise de todos os aspectos
do processo. O controle das informaes disponibiliza dados mais atualizados, alm
de manter uma base com o histrico das operaes de negcios realizadas. Outro
aspecto identificado foi rpida adaptao dos processos as novas condies de
negcios, pois esses so controlados e monitorados de maneira mais efetiva.
Atravs do uso de sistemas BAM, o monitoramento dos processos prov
informaes estatsticas e analticas sobre condies especiais definidas pelos
executivos do negcio, essas condies especiais representam a chave para o
desenvolvimento de indicadores de performance (KPI Key Performance
Indicators).
Por meio desses indicadores de performance, o departamento conseguiu
mapear quais eram os horrios de maior pico de ligaes, quais tipos de skills eram
mais exigidos em determinados horrios, e a gerncia com base nessas
informaes traou uma estratgia para baixar a volumetria de ligaes, cumprir o
SLA e aumentar o grau de satisfao dos clientes com o servio prestado.
Comeando com mudanas internas, a gerncia realocou os analistas nos
horrios de pico, foi criado um portal via Web para os clientes que mais abriam
chamados no departamento, os tcnicos que antes precisavam ligar para a URA do
102

Service Desk, agora acessam o sistema RCMS via internet (Web Services) com os
PDAs. A figura 32 mostra a tela de um PDA executando o programa para visualizar
os chamados.

Figura 32 Interface da aplicao no PDA.
Fonte: do autor.

Com essas medidas a organizao ultrapassou a meta de SLA prevista em
contrato, havendo uma satisfao de mais de 90% de seus clientes. Houve tambm
uma economia de cerca de 40% com gastos em telefonia e a volumetria de ligaes
que antes era de 55 mil caiu para 35 mil ligaes mensais.

103

Fatores de Comparao Antes do BPM Com BPM
Total de ligaes mensais 55 mil 35 mil
Cumprimento de SLA 60% 90% - 95%
Satisfao dos clientes 55% 93%
Quadro 5 Comparativo entre antes e depois da implantao do BPM.
Fonte: do autor.

A figura 33 mostra a arquitetura tecnolgica e suas aplicaes aps a
implantao do BPM no Service Desk:

Figura 33 Arquitetura tecnolgica e suas aplicaes aps a implantao do BPM.
Fonte: do autor.
104

A arquitetura tecnolgica da empresa muito bem estruturada como se pode
observar na figura 33, o mainframe IBM modelo z990 roda as aplicaes que
precisam de maior carga de processamento, no caso os principais sistemas da
empresa, j as outras aplicaes como o DB2 e o sistema de mensagens rodam em
servidores RISC que trocam informaes com o mainframe, dessa forma todas as
informaes so atualizadas em tempo real, caso o cliente queira saber um
posicionamento de seu chamado, por exemplo: o cliente pode at saber quando,
onde e para quem ser entregue a pea para trmino do atendimento ou at mesmo
saber por qual motivo o seu chamado encontra-se pendente, pode-se ainda
adicionar informaes e registrar reclamaes.

105

5. CONSIDERAES FINAIS

Este trabalho demonstrou por meio de um estudo bibliogrfico o potencial que
o BPM possui em termos de agregao de valor aos negcios e que vem sendo
muito utilizado como um recurso estratgico em muitas organizaes para elevar o
potencial competitivo.
Apesar das significativas contribuies do BPM, o sucesso da TI e do negcio
em se alinharem em busca de uma empresa mais moderna e competitiva no
depende apenas de ferramentas, tecnologias ou metodologias, isto tambm est
relacionado ao sistema da organizao, porque quanto mais complexo, amplo e
tendente a mudanas for esse sistema, mais o BPM pode agregar valor, devido ao
seu grande potencial de melhorias nos processos.
Algumas empresas se diferenciam no mercado por possurem um
conhecimento especial (como utilizao de melhores prticas, regras para identificar
oportunidades ou classificar clientes) embutido em seus sistemas. Guardar
conhecimentos valiosos em um sistema que pode ficar ultrapassado e que dificulte o
acesso a eles um risco. O BPM pode identificar e expor os processos de uma
maneira que possam ser facilmente aproveitados e reaproveitados pela empresa.
Neste trabalho tambm foi apresentada uma gesto de processos de negcio
que integra a modelagem de processos de negcio e a criao de servios, atravs
de uma arquitetura orientada a servios. Neste caso, esses servios em SOA devem
ser gerenciveis para que possam ser controlados por um sistema externo de
gerncia de processos de negcio. Nesse ponto, o SOA se prope como soluo de
TI para o BPM.
A partir da pesquisa realizada, nota-se que alguns mecanismos facilitam a
integrao entre as notaes BPMN e BPEL. Isto permite, por exemplo, o
reaproveitamento dos modelos desenvolvidos anteriormente na plataforma de uma
empresa que utiliza Web Services para a comunicao entre os seus sistemas e
clientes, por meio da aplicao da orquestrao de servios, distribudos em
camadas dentro da Arquitetura Orientada a Servio a fim de aumentar a
reusabilidade, interoperabilidade e flexibilidade de seus sistemas.
106

A gesto de processo torna possvel a aproximao da rea de TI com a rea
de negcios, de modo a permitir no somente a comunicao entre eles, mas
tambm que esses interajam de forma mais efetiva disponibilizando uma viso
abrangente dos processos da organizao.
No estudo de caso, foi realizado um modelo para representao de um
processo de negcio de uma organizao que atua no mercado de Outsourcing e
prestao de servios, atravs de uma metodologia de modelagem de estado atual
(As Is) pde-se observar que essa modelagem proporcionou uma viso que serviu
de base, para treinamento, discusso entre equipes e setores correlacionados sobre
as atividades realizadas, padronizao e melhorias dos processos, como tambm
criar metas e controles de melhorias e eliminar retrabalho, burocracia e custos
desnecessrios, possibilitando desta forma dar apoio efetivo implementao de
sistemas de gerenciamento, melhorando a comunicao entre equipe de Tecnologia
e Informao e no-especialistas. Aps toda esta discusso entre os departamentos
correlacionados, as equipes e o time de TI construram um modelo de estado Futuro
(To Be), sendo este implementado na organizao.

107

REFERNCIAS

AALST, W. M. P. Van Der. Business process management: a survey. In:
CONFERNCIA INTERNACIONAL DE BUSINESS PROCESS MANAGEMENT,
1.,2003, Berlin: Springer Verlag, 2003.

ALLEMANN, J. Web service integration and composition for enabling automatic
adaption of heterogeneous WSDL descriptions. 2006. 70f. Dissertao (Cincia
da Computao) - Instituto de Cincias da Computao, Universidade de Zurique,
Zurique, 2006.

ANDRADE, A. Um estudo de aplicao de modelagem de processo de negcio
para apoiar a especificao de requisitos de um sistema. In: SIMPSIO
INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6., 2004, So
Paulo. Anais... So Paulo: SIMPROS, 2004.

BALDAM, R. Gerenciamento de processos de negcios. BPM Business
Process Management. 2. ed. So Paulo: rica, 2008. 240 p.

BENEDETE, A. C. Roteiro para a definio de uma arquitetura SOA utilizando
BPM. 2007. 68f. Monografia (MBA) - Escola Politcnica, Universidade de So Paulo,
So Paulo, 2007.

Business Process Modeling Notation BPMN. Disponvel em
<http://www.omg.org/spec/BPMN/1.2>. Acesso em: Setembro. 2009.

Business Process Modeling Notation BPMN. Disponvel em
<http://www.omg.org/spec/BPMN/2.0>. Acesso em: Setembro. 2009.

CHRISTENSEN, E. Web Services Description Language (WSDL). 2001.
Disponvel em: <http://www.w3.org/TR/2001/NOTE-wsdl-20010315>. Acesso em 8
de maio 2008.

CUBILLOS, J. A. Composicin Semntica de Servicios Web. Grupo de
Engenharia Telemtica, Universidade de Cauca, Colmbia, 2004.

CUMMINS, F. A. Integrao de sistemas. EAI Enterprise Application
Integration. Arquitetura para integrao de sistemas e aplicaes
corportativas. 1. ed. Rio de Janeiro: Campus, 2002.

ERL, T. Service-Oriented Architecture: concepts, technology, and design.
Upper Saddle River: Prentice Hall PTR, 2005.

ERL, T. SOA Principios de Design de Servios. 1 Ed. Pearson/Prentice Hall
Brasil, 2009.
FANTINATO, M; TOLEDO, M. B. F. de; GIMENES, I. M. S. Web Service E-contract
108

Establishment Using Features. In: INTERNATIONAL CONFERENCE ON
BUSINESS PROCESS MANAGEMENT, 4., 2006, Viena. Proceedings Viena:
Springer Berlin/Heidelberg, 2006.

FREITAS, R. M. CEPE: um editor cooperativo para elicitar processos. In:
SIMPSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 16., 2002, Gramado,
RS. Anais... Gramado, RS: Springer Berlin/Heidelberg, 2002.

GARCIA, D. Z. G.; TOLEDO, M. B. F. de. UDDI extension for business process
management systems. In: IADIS WWW/Internet, 2007, Vila Real: IADIS Press,
2007.

GU, Qing; LAGO, Patricia. A stakeholder-driven Service Life Cycle Model for
SOA. IN: IW-SOSWE07, Dubrovnik, Croacia, 2007.

HOLLINGSWORTH, D. Workflow Management Coalition: the workflow reference
model. Jan. 15, 1995.

JESTON, John; NELIS, Johan. Business Process Management: practical
guidelines to successfull implementations. 1. ed. Oxford: Elsevier, 2006, p. 464.

JUNIOR, V. A. M.. Estudo da aplicao de Sistemas de Gesto de Processos de
Negcio em diferentes modelos de desenvolvimento de Software. 2007. 99f.
Trabalho de concluso de curso Universidade Federal de Santa Catarina,
Florianpolis, 2007.

KAMOUN, F. A Roadmap towards the Convergence of Business Process
Management and Service Oriented Architecture. Dubai. UAE.

KHAN, R. N. Business Process Management: a practical guide. 1 ed. Tampa, FL:
Meghan-Kiffer Press, 2004.

KLOPPMANN, M. WS-BPEL Extension for People BPEL4People. EUA:
IBM/SAP, 2005.

LEITO, G. M. MARGALHO JUNIOR, N. A. B. Comparao de ferramentas para
implementao de Web Services. 2007. 89f. Monografia (Graduao) -
Universidade da Amaznia UNAMA Centro de cincias exatas e tecnologia
CCES Curso de Bacharelado em Cincia da computao na rea de engenharia de
software, Belm, 2008.

LEYMANN, F.; ROLLER, D.; SCHMIDT, T. M. Web Services and Business
Process Management. IBM Systems Journal, v.41, n.2, p. 198, 2002.

MIGON, L. B; LOPES, L. C. De histrias a processos: utilizao da tcnica de
Group Storytelling para apoio elicitao de processos de negcios.

MIRANDA, P. A. P. SOA Arquitetura orientada a servios. 2008. 94f. Monografia
(Graduao) - Universidade da Amaznia UNAMA Centro de cincias exatas e
tecnologia CCET Curso de Bacharelado em Cincia da computao, Belm, 2008.
109

MOREIRA, Leo S. Aplicando Composio e Orquestrao de Servios na
Organizao de Sistemas. 2007. 68f. Monografia (Graduao) Gerncia
Educacional de Tecnologia da Informao, Centro Federal de Educao Tecnolgica
do Rio Grande do Norte, Natal, 2007.

OASIS (2007). Web Services Business Process Execution Language Version 2.0.
Disponvel em <http://docs.oasis-open.org/wsbpel-v2.0.pdf>.
Acesso em: Agosto. 2009.

OBJECT MANAGEMENT GROUP - OMG. Disponvel em <http://www.omg.org/>.
Acesso em: Maio. 2009.

OLIVEIRA, F. M. Aplicao do Business Process Management (BPM) nas
Organizaes. 2008. 100f. Trabalho de concluso de curso (tecnlogo) Faculdade
de tecnologia da zona leste, So Paulo, 2008.

PAK, A. F. M. Ferramentas para a Gesto de Mudanas do Modelo ITIL Aplicado
a Uma Empresa de Telecomunicaes. 2006. 128p. Monografia (Graduao)
Universidade de Braslia, Braslia, 2006.

PUNTAR, S; LENDRIKE, H; MAGDALENO, A; BAIO, F; SANTORO, F. Estudo
Conceitual sobre BPMS. 2009. 19f. Relatrios tcnicos do departamento de
informtica aplicada da UNIRIO Universidade Federal do estado do Rio de Janeiro
Centro de Cincias Exatas e tecnologia. Rio de Janeiro, 2009.

REIS, G. Introduo ao BPMN. Revista Portal BPMN, So Paulo, v.1, n.1, p. 7-15,
ago./set. 2007.

SANTOS, R. P. C; PINHO, B. R. B; SANTOS, D. G. S; CAMEIRA, R. F. O que so
BPMS: Sistemas de Suporte s tarefas para a gesto de processos. In: XXVII
Encontro Nacional de Engenharia de Produo, ABEPRO, Foz do Iguau, PR, 2007

SOMMERVILLE, I. Engenharia de Software. 6. ed. So Paulo: Addison Wesley,
2003.

SOUZA, A. C. R. A importncia do business process management (BPM) nas
empresas de software. 2008. 90f. Trabalho de concluso de curso (tecnlogo)
Faculdade de tecnologia da zona leste, So Paulo, 2008.

WORLD WIDE WEB CONSORTIUM W3C Escritrio Brasil. Disponvel em:
<www.w3c.br>. Acesso em: Julho. 2009.

ZIMMERMANN, DOUBROVSKI, GRUNDLER, HOGG. Service Oriented
Architecture and Business Process Choreography in an Order Management
Scenario: Rationale, Concepts, Lessons Learned. San Diego, California,
USA.2005.

110

GLOSSRIO

Balanced Scorecard - Perspectiva de processo, a fim de desenvolver medidas,
coleta de dados e os analistas sobre o foco desta perspectiva.

Benchmarking - Definir, entender e evoluir produtos, projetos, processos e prticas
a partir de um estudo de como outras organizaes desempenham essas mesmas
operaes.

Business Activity Monitoring - Ferramentas de monitoramento em tempo real das
operaes de uma organizao e de seus impactos sobre os resultados do
negcios.

Business Intelligence - Utilizao de uma srie de ferramentas para coletar,
analisar e extrair informaes, que sero utilizadas no auxilio ao processo de gesto
e tomada de deciso.

Business Process Management Initiative - rgo que padroniza a gesto de
processos de negcios.

Business Process Management System Ambiente integrado de componentes
de software que automatizam o ciclo de vida de processos de negcios, desde a sua
concepo e modelagem inicial, passando pela execuo e monitoramento, at
incorporao de melhorias, inclusive com a possibilidade de simulao.

Business Process Modeling Notation - Prov s empresas a capacidade de
compreender os seus processos internos em uma notao grfica e habilita a
comunicao desses procedimentos de uma forma padro.

Drag-and-drop Conceito de clicar e arrastar, recurso utilizado nas ferramentas
grficas.

Dashboard - Representa uma janela da interface de operao contendo um painel
de controle com os principais indicadores de desempenho dos processos
gerenciados.

Fast Analysis Solution Technique - uma ferramenta de melhoria de processos
lanada pela IBM e postriormente aperfeioada por outras corporaes e empresas
de consultoria.

Joint Application Development - Tcnica de levantamento de dados que traz os
usurios para o desenvolvimento do processo como participantes ativos.

Key Performance Indicators Sua finalidade medir qualquer etapa de um
processo ou resultado, no esto limitados apenas s conhecidas mtricas
financeiras, a comparao dos indicadores pode apontar o caminho para a
concluso dos objetivos estratgicos da empresa.

111

Service Level Agreement Contrato onde feito um acordo de nvel de servio
entre um fornecedor de servios de TI e um cliente especificando, em geral em
termos mensurveis, quais servios o fornecedor ir prestar.

Unidade de Resposta Audvel - Aparelho utilizado por empresas de Call Center
(atendimento) para que possam ser digitadas opes no atendimento eletrnico, a
URA um microcomputador convencional, ao qual se agrega um hardware
especfico para realizar as tarefas de telefonia (tais como atender, discar, desligar,
reconhecer dgitos, falar, etc), e um software que controle este hardware de forma a
atender a objetivos especficos.

World Wide Web - Desenvolve tecnologias interoperveis (especificaes, manuais,
software e ferramentas) para levar a utilizao da rede mundial da Internet ao seu
potencial pleno (www.w3c.br).

Visita in-loco - Palavra que vem do latim que significa no lugar. Investigao
realizada no local da pesquisa.

Monografia BPM

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Monografia BPM

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO TECNOLGICO DA ZONA LESTE

FACULDADE DE TECNOLOGIA DA ZONA LESTE

Você também pode gostar