Download pdf - Monografia bpm

Transcript
Page 1: Monografia bpm

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

RAFAEL RAYATO INAZAWA

A APLICAÇÃO DO BPM PARA AUTOMAÇÃO DE

PROCESSOS DE NEGÓCIO NAS ORGANIZAÇÕES

ESTUDO DE CASO: PROJETO NEW_RCMS

São Paulo

2009

Page 2: Monografia bpm

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

RAFAEL RAYATO INAZAWA

A APLICAÇÃO DO BPM PARA AUTOMAÇÃO DE

PROCESSOS DE NEGÓCIO NAS ORGANIZAÇÕES

ESTUDO DE CASO: PROJETO NEW_RCMS

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

São Paulo

2009

Page 3: Monografia bpm

Inazawa, Rafael Rayato

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

111 f. Orientador: Wilson Vendramel.

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

1. Gestão do processo de negócio. 2. Arquitetura orientada a

serviços. I. Vendramel, Wilson. II. Faculdade de Tecnologia da Zona Leste.

Page 4: Monografia bpm

CENTRO TECNOLÓGICO DA ZONA LESTE

FACULDADE DE TECNOLOGIA DA ZONA LESTE

RAFAEL RAYATO INAZAWA

A APLICAÇÃO DO BPM PARA AUTOMAÇÃO DE PROCESSOS DE

NEGÓCIO NAS ORGANIZAÇÕES ESTUDO DE CASO: PROJETO NEW_RCMS

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

COMISSÃO EXAMINADORA

_________________________________________

Prof. Msc. Wilson Vendramel

Faculdade de Tecnologia da Z/L

____________________________________

Prof. Msc. Ricardo Satoshi Oyakawa

Faculdade de Tecnologia da Z/L

____________________________________

Esp. Marco Aurélio Aloise Filho

São Paulo, ___ de _____________ de 2009.

Page 5: Monografia bpm

DEDICATÓRIA

A Deus, aos meus pais, minha

namorada e aos meus amigos...

companheiros de todas as horas...

Page 6: Monografia bpm

AGRADECIMENTOS

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

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

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

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

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

Aos colegas de curso, pela batalha a qual vencemos.

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

Page 7: Monografia bpm

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

Daisaku Ikeda

Page 8: Monografia bpm

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

RESUMO

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

Page 9: Monografia bpm

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

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

Page 10: Monografia bpm

LISTA DE ABREVIATURAS

BAM Business Activity Monitoring

BI Business Intelligence

BPD Business Process Diagram

BPEL Business Process Execution Language

BPM Business Process Management

BPMI Business Process Management Initiative

BPMN Business Process Modeling Notation

BPMS Business Process Management Systems

BPR Business Process Reengineering

BSC Balanced Scorecard

FAST Fast Analysis Solution Technique

KPI Key Performance Indicators

OASIS Organization for the Advancement of Structured

Information Standards

PMI Project Management Institute

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SWOT Strengths, Weakness, Opportunities and Threats

TI Tecnologia da Informação

UDDI Universal Description, Discovery and Integration

WfMC Workflow Management Coalition

Page 11: Monografia bpm

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

Page 12: Monografia bpm

LISTA DE FIGURAS

Figura 1 – Ilustração de um processo de negócio...........................................................24 Figura 2 – Visão Sistêmica dos Processos.....................................................................25 Figura 3 – Ciclo de BPM..................................................................................................28 Figura 4 – Exemplo de Visão Global de Processos de compra......................................32 Figura 5 - Monitoração de Processos de Negócio com o Websphere Business MQ......41 Figura 6 – Analisando os KPIs (Indicadores Chave de Desempenho)...........................42 Figura 7 – Visualização gráfica dos indicadores.............................................................43 Figura 8 – Exemplo de relatório analítico........................................................................44 Figura 9 – Automação do ciclo de vida de processo de negócios..................................47 Figura 10 – Demonstração das Atividades e Decisões...................................................48 Figura 11 – Componentes da arquitetura SOA...............................................................58 Figura 12 – Exemplo de Aplicação Frontend..................................................................59 Figura 13 – Composição de um Serviço na Arquitetura SOA.........................................60 Figura 14 – Composição de Serviços..............................................................................65 Figura 15 – Orquestração e Coreografia.........................................................................67 Figura 16 – Exemplo de processo de orquestração de serviços.....................................69 Figura 17 – Exemplo de Coreografia de serviços...........................................................69 Figura 18 – Fluxo de Processo BPEL.............................................................................71 Figura 19 – Estrutura básica de uma especificação BPEL.............................................73 Figura 20 – Interface Gráfica modelada pelo BPEL através da ferramenta Eclipse.......75 Figura 21 – Camadas de Abstração de SOA..................................................................76

Page 13: Monografia bpm

Figura 22 – O negócio e os domínios da lógica da aplicação.........................................77 Figura 23 – As três principais camadas de serviços.......................................................78 Figura 24 – Serviços utilitários da camada de serviço de aplicação...............................79 Figura 25 – Serviço ServicoSalvarGrupo nas camadas de Aplicação e Negócios.........81 Figura 26 – Ciclos de Vida de SOA.................................................................................83 Figura 27 – Atividades do ciclo de vida com os serviços no ambiente SOA...................86 Figura 28 – Arquitetura Web Services.............................................................................89 Figura 29 – Arquitetura de todos os sistemas do departamento.....................................93 Figura 30 – Processo modelado (As Is)..........................................................................96 Figura 31 – Processo modelado (To Be).......................................................................100 Figura 32 – Interface da aplicação no PDA...................................................................102 Figura 33 – Arquitetura tecnológica e suas aplicações após a implantação do BPM...103

Page 14: Monografia bpm

LISTA DE QUADROS

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

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

Quadro 3 – Processo de atendimento (As Is).................................................................94 Quadro 4 – Processo de atendimento (To Be)................................................................98 Quadro 5 – Comparativo entre antes e depois da implantação do BPM......................103

Page 15: Monografia bpm

LISTA DE TABELAS

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

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

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

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

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

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

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

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

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

Page 16: Monografia bpm

SUMÁRIO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Page 17: Monografia bpm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Page 18: Monografia bpm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Page 19: Monografia bpm

19

1. INTRODUÇÃO

Melhoria Contínua é um termo bem conhecido para as organizações que

desejam se manter competitivas no mercado. Hoje com a disposição dos mais

variados modelos, métodos e processos de Gestão, algumas têm conseguido

alcançar os principais objetivos que são: manter crescimento, reduzir gastos e

aumentar lucros.

As organizações que conseguem alcançar suas metas e objetivos em geral

são as que possuem processos internos e externos bem definidos, estão sempre em

constante mudança organizacional e se adaptam rapidamente a elas, geralmente

possuem uma ótima infra-estrutura de TI alinhada ao seu processo de negócio, isso

as tornam empresas flexíveis.

A maior dificuldade das empresas é alinhar os seus processos de negócio a

TI, criar uma solução tecnológica adequada que agregue valor ao seu negócio

possibilita a empresa ter uma forte flexibilidade e interoperabilidade para

acompanhar as constantes mudanças de processos e informações.

A aplicação do Business Process Management (BPM) permite mapear os

processos organizacionais da empresa, buscando a integração funcional e

proporcionando maior agilidade nas atividades que envolvem pessoas, tarefas,

máquinas, aplicações de software e outros elementos coordenados para atingir os

objetivos do negócio. Com a utilização de notação de modelagem de processos

como Business Process Management Notation (BPMN), os analistas de negócio

podem documentar os modelos criados e entender melhor os processos da empresa

em diferentes níveis, facilitando deste modo o entendimento dos participantes dos

processos de negócio.

Da necessidade de integração entre diferentes sistemas e a disseminação da

Web surge a Arquitetura Orientada a Serviços – SOA (Service-Oriented Architecture)

que veio com o objetivo de integrar serviços fracamente acoplados, possibilitando o

reuso, modificação e a aplicação em diferentes áreas internas ou externas da

empresa. Atrás de inovação, as empresas vêem cada vez mais demonstrando

Page 20: Monografia bpm

20

interesse em Web Services, pois é uma tecnologia atual baseada na Web capaz de

integrar serviços utilizando tecnologia XML (eXtensible Markup Language). De certa

forma essa tecnologia pode sanar boa parte dos problemas de uma organização que

utiliza sistemas diferentes, fazendo com que eles troquem informações, com isso a

empresa pode integrar seus processos a esses sistemas independentes de

plataforma ou linguagem de programação.

Este trabalho tem como objetivo demonstrar os passos necessários para uma

organização implementar o BPM, por meio da modelagem de seus processos,

visando promover a flexibilidade, Interoperabilidade e a reusabilidade de

componentes na organização.

A Justificativa para o desenvolvimento deste trabalho é demonstrar que o

Business Process Management é de extrema importância para as organizações e

que suas contribuições agregam mais valor ao negócio tornando a empresa mais

competitiva no mercado.

A metodologia deste estudo será feita a partir de pesquisa bibliográfica e

também de um estudo de caso que apresenta a modelagem de um processo de

negócio, a fim de demonstrar as principais atividades e características da gestão de

processos de negócio por meio do BPM.

O estudo de caso consiste em analisar um determinado processo de um

serviço oferecido por uma organização, e a utilização de uma ferramenta de

modelagem de negócio (Bizagi Process Modeler), obtendo assim, a inserção,

desses processos no paradigma da orientação a serviços e gestão dos processos de

negócio.

O segundo capítulo aborda a gestão de processos de negócio, que é uma

disciplina de gestão estratégica, que sustenta a idéia de que podemos modelar um

negócio em termos de processos de sua finalidade que podem abranger tradicionais

organizações e fronteiras de sistemas. Ele envolve a descoberta, projeto e entrega

dos processos de negócio, fazendo com que todos os departamentos da

organização estejam alinhados com as metas e estratégias da corporação. Uma boa

gestão ainda permite um ciclo de melhoria contínua onde as organizações devem

estar aptas às constantes mudanças organizacionais em conjunto com a Tecnologia

da Informação para estarem melhor alinhadas com suas metas, estratégias e

Page 21: Monografia bpm

21

objetivos.

O terceiro capítulo, aborda a arquitetura orientada a serviços que é uma

aproximação arquitetural para desenvolvimento de sistemas que constrói e distribui

serviços reutilizáveis e encapsulados prestados às empresas para que diferentes

aplicações possam compartilhá-los em um modo vagamente acoplado e altamente

inter-operável. A implementação desses serviços podem ser feitas independente da

plataforma ou linguagem de programação, utilizam protocolos padronizados para a

comunicação e troca de informações. Esses padrões tornam os serviços flexíveis e

reusáveis, podendo ser executados em computadores distribuídos geograficamente.

Essa arquitetura ainda permite a utilização de diversas outras tecnologias incluindo

os sistemas legados da organização, mantendo a interoperabilidade entre os

diversos sistemas da organização.

Page 22: Monografia bpm

22

2. GESTÃO DE PROCESSOS DE NEGÓCIO

Segundo a BPMN (apud BALDAM et al., 2008, p.19), a gestão por processos

de negócios envolve a descoberta, projeto e entrega de processos de negócios.

Adicionalmente, o BPM inclui o controle executivo, administrativo e supervisório

desses processos.

A gestão por processos de negócios é a disciplina de modelar, automatizar,

gerenciar e otimizar processos de negócios através do seu ciclo de vida com o

propósito de lhes agregar valor (KHAN apud OLIVEIRA, 2008, p. 19),

O BPM tem vários predecessores como o Gerenciamento de Qualidade Total

(TQM, do inglês Total Quality Management) e de um novo paradigma que surgiu em

meados dos anos 90: Business Process Reengineering (BPR), que prometia

aumentar o desempenho dos negócios em um período relativamente curto pela

reengenharia completa dos processos de negócios existentes. O BPR teve um

grande sucesso inicial, mas o movimento teve um declínio que levou ao fracasso

vários projetos. O BPM surgia 10 anos mais tarde e trazia de volta a gestão por

processos de negócios com soluções que atendiam, através da evolução dos fluxos

de trabalho, a interoperabilidade de processos mais complexos e distribuídos

fisicamente.

Com a integração e aperfeiçoamento dos processos, de forma que as metas e

estratégias estejam alinhadas com a corporação, a gestão por processos pode

trazer eficiência e permitir vincular a atividade das diferentes funções internas aos

fatores competitivos da organização.

No entanto, se o processo como um todo não for corretamente analisado e

avaliado, as correntes funções tornam-se um grupo de pequenas unidades de

negócios isoladas, as quais são avaliadas indevidamente por padrões não

condizentes com as necessidades globais da empresa. O acontecimento mais

comum é o de o organograma receber uma maior atenção do que o próprio negócio.

O termo BPM, Business Process Management, é largamente utilizado pelos

autores para referenciar a automação dos processos, que uma vez passando por

Page 23: Monografia bpm

23

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

ferramentas de software.

Já no ambiente de negócios, os executivos se referem à gestão de processos

de negócios de uma forma mais genérica, com uma visão de gerenciamento

humano melhor organizado diante dos negócios da corporação.

2.1 Processos de negócio

Processo de Negócio é a descrição de um conjunto de atividades que

envolvem pessoas, tarefas, máquinas, softwares e outros elementos coordenados

para atingir objetivos de negócio.

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

Segundo Moreira (2007, p. 30-31) um processo de negócio pode ser visto

como um conjunto estruturado de tarefas que contribuem coletivamente para que

uma organização atinja os seus objetivos. Os processos de negócio são a base

operativa de uma empresa e fazem parte da cultura desta e o êxito da mesma

depende fortemente da eficiência com que eles são administrados. Assim sendo,

uma má administração dos processos traz altos custos, baixa produtividade e

inadequados tempos de resposta, tanto frente às oportunidades como às ameaças.

A figura 01 exemplifica um processo de negócio.

Page 24: Monografia bpm

24

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

Fonte: GARCIA e TOLEDO (2007).

A Figura 2 mostra o esquema geral de funcionamento de processos nas

organizações, ela demonstra o que está diretamente envolvido em um processo em

particular (entradas, saídas, recurso e controles), inclusive as influências externas

oriundas do contexto da organização, que podem alterar o modo de funcionamento

do processo até mesmo os produtos produzidos pelo processo (BALDAM et al,

2008, p.21).

Page 25: Monografia bpm

25

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

Fonte: BALDAM (2008. p.21).

2.1.1 Fluxo de trabalho de pessoas

Quando as atividades do processo exigem ações ou pareceres de pessoas,

normalmente categoriza-se o processo como de “longa duração”, pois o elemento

humano pode demorar em completar a tarefa. Para os mecanismos de BPM darem

suporte a interação humana, não só devem armazenar e controlar estes processos

de longa duração, mas também prover funcionalidades como:

• Identificação do responsável pela tarefa: Normalmente, quando se

desenha um processo, assinala-se um papel (uma função como

gerente de agência, analista de crédito) às tarefas, ao invés de uma

Page 26: Monografia bpm

26

identificação direta da pessoa (como seria um código funcional). Isto é

importante para que os processos sejam independentes das pessoas,

as quais podem sair da empresa ou mudar de função, e também

porque para cada instância do processo o recurso (pessoa) pode ser

diferente. Os papéis podem ser definidos no momento de criação dos

fluxos, durante sua instalação no ambiente, ou mesmo durante sua

execução (KLOPPMANN apud BENEDETE, 2007, p. 31);

• Envio da tarefa para a pessoa responsável e apoio à interação: Depois

de identificado, o responsável pela tarefa tem que ser comunicado

criando itens em uma relação de tarefas que deve ser periodicamente

consultada pela pessoa. As ferramentas de BPM não só avisam o

responsável pela tarefa, mas também fornecem telas onde o contexto

(informações necessárias para entender, executar uma tarefa ou tomar

uma decisão) da atividade é apresentado;

• Tratamento de exceções: Caso uma pessoa demore muito para realizar

uma tarefa, ou caso fique ausente, os mecanismos de fluxo de trabalho

devem ser capazes de encontrar um substituto ou escalar o assunto

para um supervisor tomar a ação necessária.

2.1.2 Características dos processos nas organizações

Segundo Baldam (2008, p. 24), à medida que a visão de processos se

difunde, as formas contemporâneas de racionalização tendem a ver as organizações

como um feixe de processos, e ele classifica esses feixes de processos da seguinte

maneira:

• Transfuncionais: pois atravessam departamentos;

Page 27: Monografia bpm

27

• Intrafuncionais: pois pertencem a um departamento ou setor

específico.

Conhecendo a visão do processo, é possível definir o que deve ser feito e

como fazê-lo, não em cima das atividades dos departamentos, mas sim, atividades

que agregam valor a organização independente do departamento que executará o

processo. Deste modo, os processos tramitariam entre departamentos conforme o

serviço que ele necessitar realizar (BALDAM et al., 2008, p. 24).

Porém, com estas características de processos, os departamentos ainda

seriam úteis nas organizações, devido a sua funcionalidade em situações gerenciais.

2.2 Ciclo de Gerenciamento de Processo de Negócio

A descrição das etapas do ciclo de gerenciamento de negócios, segundo

Baldam (2008, p. 56), podem ser aplicadas em um processo específico da

organização ou em processos de negócios onde existe uma gestão da integração

destes já presente, podendo ser utilizada também em um estado de gestão que se

pretende chegar futuramente. A figura 3 ilustra o ciclo do BPM.

Page 28: Monografia bpm

28

Figura 3 – Ciclo de BPM

Fonte: BALDAM (2008, p.56)

• Planejamento do BPM: É onde as atividades de BPM que contribuirão

para o alcance de metas organizacionais (desde as estratégicas até

as operacionais) serão definidas, como verificação dos pontos de

falha nos processos que causam danos a organização (financeiros,

imagem, prazos e satisfação de clientes), definição de planos de ação

para implantação, definição dos processos que necessitam de ação

imediata;

• Modelagem e otimização de processos: atividades que permitem

gerar informações sobre o processo atual (As Is) e/ou sobre a

proposta de processo futuro (To Be); documentar os processos;

prover dados de integração entre processos, empregar metodologias

para aperfeiçoar os processos, fazer inovações, simulações e

Page 29: Monografia bpm

29

redesenhos; adotar as melhores práticas de modelos de referência;

gerar especificações para implementação, para configuração e

customização (caso o processo não esteja em uso), para execução e

controle;

• Execução de processos: atividades que garantirão a implementação e

a execução dos processos, como implantação de planos de

transferência de tecnologia, treinamentos, ajuste de equipamentos e

softwares (se necessários), acompanhamento de processo

implantado, monitoria e controle da execução das instâncias de

processo;

• Controle e análise de dados: atividades relacionadas ao controle geral

do processo (por meio de diversos recursos, como o uso de

indicadores, BAM, BI, BSC, métodos estatísticos, diagramas de causa

e efeito), gerando informações que posteriormente realimentarão as

atividades de otimização e planejamento.

2.2.1 Planejamento do BPM

As atividades desempenhadas na etapa de planejamento do BPM são

descritas por Baldam (2008, p. 63):

• Definir os processos-chave para a estratégia da organização. Usando

metodologias conhecidas (Cadeia de Valor, BSC, SWOT), é possível

identificar em quais processos a organização tem mais

potencialidade, os pontos que precisam melhorar, quais as ameaças

e oportunidades do mercado, os indicadores que serão usados para

medir o desempenho de seus processos, a meta para esses

indicadores, entre outros;

Page 30: Monografia bpm

30

• Levantar os principais pontos fracos dos processos em uso na

organização;

• Identificar as oportunidades (novas abordagens, produtos ou serviços)

que possam ser fornecidas pela organização, levando a preparar os

processos que permitirão sua entrega;

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

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

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

prioridade;

• Identificar ao time de projetos de processos e às áreas envolvidas as

diretrizes e especificações básicas desejadas a partir do

planejamento;

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

Os gestores de processo não são os únicos responsáveis pelas atividades do

planejamento. É importante a participação de gestores de outras áreas da

organização, o apoio desses gestores e o seu comprometimento com o BPM de

forma contínua contribuem para o êxito na gestão por processos, caso isso não

ocorra, surgirão processos isolados sem uma visão global dos processos. No

momento da implantação, é fundamental a participação efetiva do gestor da

organização, a fim de evitar possíveis barreiras e desentendimentos, entre os

funcionários dos diversos setores e áreas envolvidas.

De acordo com Baldam (2008, p. 66) não são apenas os processos que

apresentam problemas (qualidade, custo, prazo, etc.) que passarão por otimização,

outros processos que estejam funcionando perfeitamente podem ser otimizados

buscando inovação ou melhoria contínua desse processo.

Page 31: Monografia bpm

31

Algumas atividades surgem de imediato e mesmo que a necessidade desse

processo não tenha sido detectada no planejamento estratégico, sua implantação

pode ser imediata.

2.2.1.1 Visão global de processos

Considerado um ponto de controvérsia que precede o BPM, segundo Baldam

(2008, p. 66), a Visão Global de Processos é fundamental numa Gestão Integrada

dos Processos sendo necessário considerar:

• Uma Visão Global dos Processos ajuda a compreensão do

funcionamento da empresa;

• Fazê-lo por completo é complexo e pode levar mais tempo que o

benefício direto e imediato por ele gerado;

• É relativamente fácil fazer o diagrama apenas em macro processo e

posicionar o processo que se deseja modelar de imediato;

• O diagrama pode ser efetivamente feito em etapas e melhorando na

medida em que é usado em projetos pontuais de BPM, alinhando

sempre os projetos ao diagrama macro;

• Para muitas das atividades realizadas, há referenciais que ajudam a

construir os diagramas próprios à organização.

Page 32: Monografia bpm

32

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

Fonte: Adaptado de BALDAM (2008, p.69).

2.2.2 Modelagem de processos

A modelagem de processos de negócio é uma das fases do ciclo de vida

SOA, ela é um conjunto de conceitos, modelos e técnicas com o objetivo de

desenvolver o modelo de negócio da organização. Este modelo é resultado de uma

abstração da organização, considerando as suas características essenciais, do

ponto de vista do negócio (CRUZ apud OLIVEIRA 2008, p. 36).

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

Segundo Baldam (2008, p. 74), é possível utilizar os modelos de processos

de negócios para:

• Discutir e compreender os processos;

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

• Simular alternativas;

Page 33: Monografia bpm

33

• Treinar os operadores dos novos processos;

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

Nesta fase o processo é modelado em termos de atividades, regras,

participantes, interações e relacionamentos. O processo é estruturado em

atividades, que podem ser mapeadas como tarefas que são executadas por pessoas

ou sistemas internos ou externos à corporação. É realizada a validação ou a

simulação dos processos, através do uso de estimativas de tempo de execução e

custo, recursos requeridos pelas atividades e a probabilidade de ocorrência de

eventos.

Essa fase também inclui a definição das métricas de desempenho do

processo para que o analista de negócio possa avaliar o processo implantado e,

possivelmente, reestruturá-lo em função de oportunidades ou de outros motivos

(NADER apud OLIVEIRA, 2008, p. 36).

Os modelos de processo são constituídos de diagramas de fluxo de trabalho e

de textos auxiliares de forma a descrever cada passo do processo de negócio.

Havey (apud SOUZA, 2006, p. 23), afirma que o modelo de processo deve

representar de forma simples e intuitiva o fluxograma de atividades do processo

modelado. A modelagem deve ser realizada em dois níveis: de forma gráfica, com o

auxílio de ferramenta de desenho de processos e com um modelo executável,

utilizado na automação desses processos através dos sistemas de gestão de fluxo

de trabalho.

Durante a descrição de um diagrama de negócio, os eventuais problemas

relacionados ao processo que ele representa são documentados e para cada um

são propostas possibilidades de melhorias. Os principais conceitos envolvidos, as

regras e os recursos utilizados ou produzidos por cada processo são identificados e

modelados como entidades de negócio.

Page 34: Monografia bpm

34

2.2.2.1 Modelagem de estado atual (As Is)

Por meio desta modelagem é possível entender o processo existente na

organização e identificar suas falhas. Espera-se, desta forma, obter métricas

suficientes a fim de estabelecer uma base na fase seguinte da análise e

desempenho do processo atual, que permita identificar as melhorias proporcionadas

pelo estado futuro, assim como uma documentação dos prós e contras e do

desempenho do processo.

Na modelagem do estado atual do processo, vários tipos de interações entre

os envolvidos no processo podem existir, incluindo atividades de colaboração e

reuniões. Diversas técnicas podem ser utilizadas na modelagem de processos atual:

técnica de entrevistas, brainstorm, JAD, métodos simplificados de modelagem com

papel, entre outras.

Baldam (et al., 2008, p. 76-77) aponta como sendo relevante as seguintes

etapas para a modelagem do processo atual:

• Preparação do projeto de modelagem: envolve as diversas atividades

de compreensão de escopo (qual processo será modelado,

propósitos, métricas, verificar alinhamento estratégico, prazos e

entregáveis), composição da equipe envolvida, definição de

documentação necessária, planejamento das reuniões (pessoas

envolvidas, datas, agenda, infra-estrutura necessária à reunião),

consulta à documentação do processo, ou que rege o processo

previamente disponível (normas, leis, regulamentos e referências);

• Entrevista e coleta de dados com usuários (especialista de negócio e

facilitadores): podem incluir entrevistas (em aberto ou dirigidas),

criação conjunta da lista de esquema gráfico de atividades, descrição

de informações que comporão o processo e criação de atas de

reunião;

Page 35: Monografia bpm

35

• Documentação do processo: será construído o modelo, conforme

metodologia previamente definida. Além dos componentes do

processo propriamente dito, outras informações serão necessárias,

como controle de versão de documentação, publicação, referências e

escopo. Nessa fase é comum o uso intensivo de software de apoio à

modelagem;

• Validade do processo: deve-se testar o modelo em uma instância real

do processo, para verificar se realmente está coerente. Em alguns

casos, a validação é impossível porque o tempo de processamento é

muito longo, ou porque exigiria um grande deslocamento, ou seu

custo seria alto demais. Por exemplo, um processo de compra por

licitação pública, quando envolve grandes somas, pode se

desenvolver por meses;

• Correção de documentação: são corrigidas eventuais distorções

percebidas durante a validação do processo.

Segundo Tachizawa e Scaico (apud Pak, 2006), uma análise do processo

atual deve verificar se os objetivos são atendidos, se as atividades estão bem

relacionadas, se os recursos alocados são suficientes e se as interfaces entre

gerências estão sendo previstas e administradas. Também é importante verificar a

consistência das tarefas utilizadas, evitando a redundância das mesmas.

Como Resultado da modelagem do estado atual JESTON & NELIS (apud

BALDAM et al., 2008, p. 77), espera-se obter:

• Modelo do processo atualmente em uso;

• Métricas apropriadas e suficientes para estabelecer uma base para

futuras medidas de melhorias de processos, priorização e seleção na

fase seguinte de análise do To Be;

Page 36: Monografia bpm

36

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

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

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

ser rapidamente implementados;

• Um relatório dessa fase.

2.2.2.2 Modelagem de estado futuro (To Be)

Nessa fase pretende-se criar um ambiente de discussão entre partes 40

envolvidas de forma a melhorar o processo em questão, inová-lo ou mesmo

questionar se ele se faz necessário e se agrega valor à organização (BALDAM et al.,

2008, p. 83). Entre as modelagens do estado futuro mais comuns podem ser citadas:

• Melhoria continua;

• FAST;

• Benchmarking;

• Adoção de melhores práticas e processos comodizados (transformá-

los em commodities);

• Redesenho de processo;

• Inovação de processo.

O objetivo dessa etapa é definir a decisão a ser tomada em relação aos

processos identificados durante a modelagem do estado atual e seu realinhamento

Page 37: Monografia bpm

37

com os objetivos e estratégias da organização. Se a decisão for redesenhar os

processos, será necessário desenvolver um novo modelo de processos com as

melhorias previstas para a situação atual identificada (SANTOS apud OLIVEIRA,

2008. P. 40).

Dentre os resultados a serem esperados (O´CONNELL, PYKE &

WHITEHEAD; JESTON & NELIS apud BALDAM et al., 2008, p.93) podem estar

incluídos:

• Redesenho do processo ou mesmo um novo processo;

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

processo;

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

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

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

envolvidos;

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

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

os requerimentos;

• Plano de desenvolvimento e treinamento da equipe;

• Relatório de impactos na organização e em outras esferas (ambiental,

social e etc.);

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

Page 38: Monografia bpm

38

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

Cummins (apud Souza, 2008, p. 47), a ferramenta de definição dos processos

deve ter as seguintes características:

• Ferramenta gráfica interativa: Os processos são exibidos graficamente,

e os elementos do processo são adicionados e conectados com edição

interativa drag-and-drop;

• Distinção visual de tipo de tarefas: O tipo de cada elemento de

processo deve ser identificável visualmente na representação gráfica

do processo.

Gráficos de fluxos e mapeamento de processos sempre foram de grande

utilidade para o homem, existindo desde o surgimento da simbologia como meio de

entendimento e comunicação.

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

Não são apenas os processos que apresentam problemas (qualidade, custo,

prazo e visibilidade da marca) que passarão por otimização (inovação, redesenho e

melhoria contínua). Um processo de atendimento ao cliente, por exemplo, pode ser

completamente migrado para a Internet, ainda que esteja funcionando corretamente

na verdade, para minimizar custos e prazos de atendimento, pode até ser mesmo

desdobrado (atendimento via Internet para a maioria dos clientes e atendimento

telefônico para exceções), aumentando assim o número de processos (BALDAM et

al., 2008, p. 66).

Page 39: Monografia bpm

39

De acordo com Baldam (2008, p. 66), algumas atividades emergem de

imediato, quando surgem situações como novos marcos, problemas de produção ou

qualidade, impedindo entrega ao cliente, concorrência que lança produtos mais

competitivos etc. Ainda que a necessidade desses processos não tenha sido

detectada no Planejamento Estratégico anual (o que não quer dizer que não estejam

alinhados com ele), sua implantação pode ser imediata.

2.2.3 Execução de processos

Nessa fase as definições da fase de modelagem do processo serão

executadas. Os processos serão testados pelos usuários, que indicarão os impactos

positivos e negativos da implementação desses.

Burlton (apud BALDAM et al., 2008, p. 94) sugere as seguintes atividades

para a execução de processos:

• Preparar o teste da nova solução;

• Completar testes e pilotos;

• Atualizar os entregáveis;

• Gerenciar o plano de transferência de tecnologia;

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

• Treinar a equipe;

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

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

processo.

É também nesta fase, que ocorre a configuração do repositório do BPMS que

suportará o novo processo e a implantação e configuração das aplicações externas

Page 40: Monografia bpm

40

que interagem com o processo. Um BPMS é responsável por manter os contextos

de execução dos processos, que inclui a atividade que está em execução, valores

de variáveis, contextos de sub-processos, logs. Ele deve facilitar a integração com

um conjunto de outras plataformas que executam os sistemas externos.

2.2.4 Controle e análise de dados

São geradas as informações sobre o comportamento dos processos, esses

dados são comparados e utilizados para montar indicadores gerais que permitem

avaliar o processo. Algumas técnicas e tecnologias aplicáveis ao controle e análise

dos dados de instâncias de processos, tais como BSC, BI, permitem uma melhor

visão do desempenho geral e apontam se a organização está alcançando seus

objetivos ou se é necessário efetuar ajustes nos processos, nas metas ou mesmo na

estratégia da organização.

Na fase de análise, a medida do desempenho do processo provê informações

de melhorias operacionais. A partir de uma visão “fim-a-fim” do processo é possível

fazer uma análise top-down para determinar a influência de cada passo ou sub-

processo no resultado global. Para dar suporte a essa fase são utilizados os

sistemas BAM (Business Activity Monitoring), onde os processos são instrumentados

com sensores para monitorar suas atividades e variáveis. Um dashboard permite a

monitoração, análise e respostas aos eventos e às exceções que ocorrem em tempo

real.

Normalmente, após o desenvolvimento de aplicações e de sua implantação e

execução em ambiente de produção, pouco suporte é dado ao negócio para avaliar

se a solução implementada foi adequada ou se há potencial para melhores

resultados. BPM, ao contrário, foca na melhoria contínua dos processos de negócio,

e para tanto, provê mecanismos para que o negócio acompanhe o comportamento

dos processos e identifique falhas e oportunidades.

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

Page 41: Monografia bpm

41

• Operacional: Neste caso, o objetivo da monitoração é acompanhar os

processos no nível do detalhe, ou seja, cada instância em execução.

Procura-se por exceções (se o processo ultrapassou limites de prazo,

custo, conclusão sem sucesso) possibilitando assim o negócio atuar

na correção da situação, priorizando o processo ou mesmo

contatando seus participantes;

• Analítica: Aqui, o objetivo é analisar o conjunto das execuções dos

processos, procurando por exceções recorrentes ou por melhores

estratégias e oportunidades para o negócio. É o momento de

comparar os resultados projetados com os realmente atingidos e

planejar ações de correção.

A monitoração operacional é baseada na situação dos processos em

execução, a qual normalmente é mantida em banco de dados do mecanismo de

execução de processos. A figura 5 mostra duas instâncias de um processo sendo

monitorados pela ferramenta WebSphere Business Monitor da IBM. Nesta

ferramenta podemos definir quais campos devem ser mostrados, o critério para

ordenação das linhas, e filtros, baseados em dados de negócio, para selecionar

apenas os processos que se deseja monitorar.

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

Fonte: www.ibm.com.br

Page 42: Monografia bpm

42

Já a monitoração analítica é normalmente baseada na análise de eventos

gerados e armazenados pelo mecanismo de execução. A solução da IBM

anteriormente mencionada, por exemplo, de tempos em tempos copia os registros

de eventos para uma base de dados especializada em pesquisas analíticas (que faz

uso de conceitos associados a “Data Warehouse”, como cubos) de forma a permitir

consultas sofisticadas e pesadas sem prejudicar o desempenho do ambiente de

execução de processos.

Com base nos eventos, são gerados os KPI (“Key Performance Indicators” ou

Indicadores Chaves de Desempenho) e os totais (métricas) escolhidos no momento

de projeto dos fluxos. Os KPIs devem ser cuidadosamente escolhidos, pois devem

refletir os objetivos do negócio mais relevantes para o sucesso da empresa, e

devem permitir a identificação antecipada de problemas, possibilitando ações

corretivas.

A figura 6 mostra dois KPI definidos para um processo (percentual de

aprovação e duração do processo). Aos KPI são associados limites, de forma que

seja facilitada a identificação de inconformidades. No exemplo, o processo foi

planejado para durar no máximo três dias, mas em ambiente real está levando mais

de três dias e 4 horas.

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

Fonte: BENEDETE (2007, p.37).

Page 43: Monografia bpm

43

No processo exemplo “aprovação de gastos de viagem”, pode-se definir como

KPIs o custo total do processo, a duração, o percentual aprovado, e o percentual de

aprovações realizadas pela diretoria.

Outra possibilidade é a criação de consoles de monitoração, através da

escolha e demonstração de um conjunto de indicadores em formato gráfico, como

mostrado na figura 7. Desta maneira, fica visualmente fácil e rápido acompanhar o

desempenho dos processos.

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

Fonte: BENEDETE (2007, p.37).

Finalmente, outro recurso importante é a geração de relatórios analíticos,

onde os indicadores de desempenho e os totais são avaliados sob diversas

dimensões (por exemplo, pelo percentual de aprovação em um determinado período

de tempo, ou por um departamento em específico). A figura 8 mostra um exemplo de

relatório, onde diversos totais são categorizados pela dimensão localidade.

Page 44: Monografia bpm

44

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

Fonte: BENEDETE (2007, p.38).

2.3 Conformidades

Segundo Baldam (2008, p. 136-139), a regulamentação e adequação do

ambiente de negócios de acordo com as exigências e que atenda a demanda

crescente por melhores produtos e serviços é indispensável nos dias de hoje.

Existem atualmente, uma maior complexidade e necessidade de regulamentação

dos ambientes de negócio como jamais existiu, e a previsão é para que haja um

aumento gradativo e contínuo destas características. Estas características, quando

corretamente aplicadas, agregam valor às empresas, influenciando também o modo

como os diretores e analistas de negócios visualizam e gerenciam a organização as

respectivas áreas de negócios.

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

Page 45: Monografia bpm

45

Baldam (2008, p. 135), afirma ainda que, se não tratarmos seriamente o bom

gerenciamento, este fator acarretará prejuízos no mercado e até mesmo

penalidades junto aos órgãos financeiros e legislativos. No entanto, como citado

acima, o bom gerenciamento é alcançado com regulamentações variadas e

transformações no ambiente de negócios consideradas complexas. Para alcançar a

excelência da conformidade, é necessário realizar o levantamento de práticas que

obtiveram sucesso nas determinadas áreas que se pretende aplicar as adequações.

Como as organizações são sistemas semi-abertos, que interagem com o

meio-ambiente, um autogerenciamento visa garantir que os aspectos relacionados a

regulamentações sejam corretamente tratados. Para tanto, a conformidade é o

componente utilizado para este gerenciamento e pode ser definido como adequação

a um conjunto de regras, sejam estas regulações ou legislações governamentais,

padrões de indústria ou políticas e procedimentos internos (JENKINS apud BALDAM

et al., 2008, p. 135).

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

Business Process Management Systems (BPMSs) foram introduzidos com o

objetivo de prover controle para definir e coordenar a execução de processos de

negócio (GARCIA e TOLEDO apud SOUZA, 2008, p. 28).

Os BPMS´s são sistemas integrados que permitem a operacionalização de

fluxos de processos de negócio, automatizando a execução, controle e

monitoramento desses processos. Um BPMS deve possuir ferramentas que

permitam a modelagem, a execução e orquestração de processos e também deve

possuir ferramentas de análise e monitoramento.

Os sistemas de gestão de processos são plataformas que orquestram os

processos de negócio, junto com todos os sistemas e pessoas envolvidos, dando

uma completa visibilidade e controle aos gestores de processos. São, portanto, os

Page 46: Monografia bpm

46

resultados de processos automatizados e geridos com o uso de ferramentas de

gestão de processos (ARORA apud SANTOS, 2007, p. 5).

“Os sistemas para o gerenciamento de processos (BPMS) são mais que um

sistema computacional que suporta a gestão da informação pela organização. Eles,

primeiro e principalmente, ajudam a gerenciar os processos” (OULD apud SANTOS,

2007, p. 5).

Os BPMSs apóiam a automatização de processos de negócio. O ciclo de vida

de automatização inicia com a definição do processo. Em seguida, a definição é

registrada em um BPMS. Para executar um processo, o sistema cria uma instância

de processo e então, coordena, monitora e registra sua execução. O registro pode

ser analisado, podendo gerar uma definição aprimorada do processo (AALST;

HOFSTEDE; WESKE apud ROCHA, 2008, p. 23).

Diferentemente dos Workflows Management Systems (WfMSs), que são

sistemas de software que definem, criam e gerenciam a execução de workflows, os

BPMSs enfatizam processos que cruzam as fronteiras organizacionais e o aspecto

da dinamicidade de processos (HOLLINGSWORTH apud ROCHA, 2008, p. 23).

2.4.1 Ciclo de Vida de BPMS

Considerando o contexto de negócio atual, Business Process Management

Systems (BPMSs) foram introduzidos com o objetivo de prover controle para definir e

coordenar a execução de processos de negócio (GARCIA e TOLEDO apud SOUZA,

2008, p.28).

Geralmente um BPMS apresenta quatro funcionalidades principais que são:

Projeto, Configuração, Execução e Diagnóstico.

Page 47: Monografia bpm

47

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

Fonte: Adaptada de GARCIA e TOLEDO apud SOUZA, (2008, p.30).

• Projeto: o ciclo de vida tem início com a modelagem do processo de

negócio, nesta fase ocorre o levantamento dos processos, do

ambiente, organizacional e técnico. São utilizados editores de

modelagem e ferramentas para validação dos processos de negócios;

• Configuração: nesta fase, os modelos de processos são

implementados. São incluídas informações técnicas que facilitam a

execução dos processos;

• Execução: o processo de negócio pode ser executado através de um

BPMS configurado, o BPMS cria instâncias de um modelo de

processos, coordena a execução e registra as informações coletadas

durante a execução do processo;

• Diagnóstico: o histórico da execução é analisado, identificando

problemas e melhorando os processos. Isso pode levar ao processo

de redesenho do processo (fase de projeto). Conforme mostra a figura

9.

Page 48: Monografia bpm

48

2.5 BPMN e os elementos de BPD

A BPMN (Business Process Modeling Notation) é uma notação visual para

representação de fluxos de processos que pode ser mapeada para diversos

formatos de execução, como BPML (Business Process Modeling Language) e BPEL

(Business Process Execution Language) (REIS et al., 2007, p. 07).

A especificação BPMN, criada pelo BPMI (Business Process Management

Initiative) provê uma notação gráfica para representar processos de negócios em um

diagrama, servindo de apoio ao uso de BPM por não-especialistas (BALDAM et al.,

2008, p.79).

A BPMN define um diagrama de processo (Business Process Diagram –BPD),

contendo os elementos gráficos, que representam atividades e fluxos de controle

que determinam a ordem de execução dessas atividades.

Um diagrama de Processos de negócios (BPD) é constituído de um conjunto

de elementos gráficos que permitem o desenvolvimento de diagramas simples

semelhantes aos de fluxo utilizados por analistas de negócio. Os elementos

utilizados são distintos uns dos outros e utilizam formas também comumente

utilizadas pela maioria dos modeladores. Por exemplo, as atividades são

representadas por retângulos e as decisões por losângulos. A figura 10 demonstra

esse exemplo.

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

Fonte: Adaptada de Reis (2007, p. 07).

Page 49: Monografia bpm

49

2.5.1 Objetos de Fluxo (Flow Objects)

Um BPD tem um conjunto de três elementos básicos, conhecidos como

Objetos de Fluxo, para que os modeladores não tenham que aprender e reconhecer

um número grande de formas diferentes. A tabela 01 demonstra os três objetos de

fluxo.

Page 50: Monografia bpm

50

Nome Descrição Objeto

Evento

(Event)

Um evento é algo que "acontece" no decurso de

um processo de negócio. Estes eventos afetam o

fluxo do processo e normalmente Tem uma

causa disparador () ou um impacto Resultado ().

Eventos são círculos com centros abertos para

Permitir indicadores internos para diferenciar

diferentes disparadores ou resultados. Existem

três tipos de eventos, com base em quando elas

afetam o fluxo: Início, Intermediário e Final

(tradução do autor).

Atividade

(Activity)

Uma atividade é um termo genérico para o

trabalho que a empresa executa. Uma atividade

pode ser atômicas ou não-atômica (composta).

Os tipos de atividades que fazem parte de um

modelo de processo são: Processo, a sub

processo, e de tarefas. Tarefas e Sub-processos

são retângulos arredondados. Os processos são

contidos dentro de uma piscina (pool) (tradução

do autor).

Portão

(Gateway)

Um gateway é usado para controlar a divergência

e convergência de seqüência de fluxo. Assim, ele

vai determinar a ramificação, bifurcação, fusão e

junção de caminhos. Interno Marcadores vai

indicar o tipo de controle de comportamento

(tradução do autor).

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

Page 51: Monografia bpm

51

2.5.2 Objetos de Conexão

Os Objetos de Fluxo são conectados em um diagrama para criar a estrutura

básica do processo de negócio. Existem três objetos de conexão que possibilitam

esta função, conforme mostra tabela 02.

Nome Descrição Objeto

Fluxo de Seqüência

(Sequence Flow)

A seqüência de fluxo é usado para

mostrar a ordem em que as

atividades serão realizadas em um

processo (tradução do autor).

Fluxo de

Mensagem

(Message Flow)

Um fluxo de mensagens é usado para

mostrar o fluxo de mensagens entre

dois participantes que estão preparados

para enviar e receber. Em BPMN, dois

Pools separados em um Diagrama

representarão os dois participantes (por

exemplo, entidades empresariais ou

papéis de negócio) (tradução do autor).

Associação

(Association)

Uma associação é usada para associar

as informações de Fluxo com objetos.

Texto e Gráfico que não são fluxos, os

objetos podem ser associados com

Fluxo de Objetos. Um seta sobre a

Associação indica uma direção de fluxo

(por exemplo, dados), quando for o

caso (tradução do autor).

Tabela 2 – Objetos de Conexão. Fonte: BPMN (2009).

Page 52: Monografia bpm

52

2.5.3 Raias (Swimlanes)

A BPMN usa o conceito conhecido como "swimlanes" para ajudar a partição e

organizar as atividades. Um diagrama de BPMN pode representar mais de um

processo privado, bem como os processos que mostram a colaboração entre a

processos privados ou participantes. Em caso afirmativo, em seguida, cada

processo de negócio privado será considerado como sendo realizada por diferentes

Participantes. Graficamente, cada participante irá ser particionado; isto é, vai estar

contido em uma caixa retangular, chamada um "pool". Pools podem ter sub-

Swimlanes, que são chamados, simplesmente, "Lanes", como mostra a tabela 03.

Nome Descrição Objeto

Pool

Um Pool representa um participante

em um processo também atua como

uma raia "e um container gráfico

para o particionamento de um

conjunto de atividades de outros

pools, geralmente no contexto de

Situações de B2B (tradução do

autor).

Lane

A Lane é uma sub-partição dentro de

uma piscina e vai estender a todo o

comprimento do interior, quer na

vertical ou horizontalmente. Lanes

são usadas para organizar e

categorizar atividades (tradução do

autor).

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

Page 53: Monografia bpm

53

2.5.4 Artefatos

Segundo a BPMN os artefatos são usados para fornecer informações

adicionais sobre o processo. Existem três artefatos padronizados, mas os

Modeladores ou ferramentas de modelagem são livres para adicionar muitos

artefatos conforme o necessário. É possível que haja esforços da BPMN para

adicionar e padronizar um conjunto maior de artefatos para uso geral ou para os

mercados verticais. A tabela 04 mostra o conjunto atual de artefatos que inclui:

Nome Descrição Objeto

Objeto de

Dados

(Data

Object)

Objetos de dados são considerados Artefatos porque

não têm qualquer efeito direto sobre a Seqüência de

Fluxo de Mensagem ou fluxo do processo, mas eles

fazem fornecer informações sobre as atividades que

necessitam de ser executada e / ou o que eles

produzem (tradução do autor).

Grupo

(Group)

Um conjunto de atividades que estejam dentro da

mesma categoria. Este tipo de agrupamento não

afetam a seqüência de fluxo de atividades dentro do

grupo. O nome da categoria aparece no diagrama

como o rótulo de grupo. Categorias podem ser

usadas para documentação ou fins de análise.

Grupos são uma maneira em que as categorias de

objetos podem ser visualmente exibidos dentro do

diagrama.

Anotação

(Text

Annotation

)

Anotações de Texto é um mecanismo para um

modelador de fornecer informações adicionais para o

leitor de um BPMN Diagrama.

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

Page 54: Monografia bpm

54

3. ARQUITETURA ORIENTADA A SERVIÇOS

A arquitetura SOA baseia-se em permitir que sistemas corporativos

disponibilizem suas funcionalidades através de serviços que podem ser utilizados

por outros sistemas para a execução de suas tarefas. É importante ressaltar que a

Arquitetura Orientada a Serviços não é um software. Este termo refere-se a um

modelo de arquitetura de software voltada para a construção de aplicações que

implementam processos de negócio ou serviços utilizando um conjunto de

componentes fracamente acoplados e orquestrados a fim de prover um nível de

serviço bem definido (HURWITZ apud MIRANDA 2008, p. 16).

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

A SOA permite flexibilidade com serviços que podem ser fornecidos

localmente ou podem estar localizados externamente, os serviços podem ser

implementados em qualquer linguagem de programação, plataformas diferentes,

tecnologias diversas podem ser utilizadas e o legado de software pode ser

aproveitado mantendo o principio da interoperabilidade. É uma caracterização de

sistemas distribuídos, em que as funcionalidades do sistema são expostas via

descrição de uma interface, permitindo a publicação, localização e a invocação por

meio de um formato padronizado.

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

Page 55: Monografia bpm

55

A Arquitetura Orientada a Serviço é capaz de oferecer a infra-estrutura

tecnológica necessária para que uma aplicação possa ser definida por meio da

composição de serviços eletrônicos. Dessa forma, oferece apoio à composição de

aplicações distribuídas de uma forma flexível e com baixo custo. Em SOA, a

composição de serviços é vista como um processo de negócio dividido em

componentes reutilizáveis e interoperáveis em Serviços.

Segundo Moreira (2007, p. 18), a arquitetura orientada a serviços é

constituída de relações entre três tipos de participantes:

• Diretório para registro de serviços, repositório que é utilizado para

publicar e localizar as interfaces dos serviços;

• Provedor de serviços, entidade responsável por publicar as interfaces

dos serviços providos por esta no registro de serviços e também

responsável por atender as requisições originadas pelos clientes;

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

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

são:

• Publicar: Inicialmente, o provedor de serviço publica a interface do seu

serviço junto ao diretório para registro de serviços;

• Localizar: O cliente pode efetuar uma busca por um determinado

serviço (operação localizar), especificando as características

desejadas, no diretório de registros. Se o serviço existir, a interface e a

localização do respectivo serviço são retornados para o cliente;

• Invocar: O cliente efetua uma invocação ao provedor do serviço

(operação invocar). Os serviços estão baseados nas trocas de

mensagens entre os provedores e os clientes, sendo assim, as

mensagens seguem um formato padrão, garantindo aos serviços a

neutralidade da tecnologia e permitindo que provedores.

Page 56: Monografia bpm

56

3.1 Características da Arquitetura Orientada a Serviços

Erl (apud Moreira 2007, p. 19) define SOA como sendo uma tecnologia que

adere aos princípios da orientação a serviços. Quando realizados através do uso da

tecnologia de Web Services, SOA promove esses princípios em todos os processos

de negócios e automação de uma corporação.

Para a composição de Sistemas de Software compostos por serviços, a

Arquitetura SOA deve permitir todas as características apresentadas na Tabela 5.

Page 57: Monografia bpm

57

CARACTERÍSTICA DESCRIÇÃO

Acoplamento Fraco Este conceito trata de minimizar as dependências entre os serviços,

permitindo assim flexibilidade na mudança das regras de negócio;

Reusabilidade do

Serviço

A lógica de uma regra de negócio deve estar definida e

disponibilizada como um serviço que pode ser reutilizado por outros

sistemas;

Contrato do Serviço

Os serviços dispõem de uma especificação para a forma de acesso

e comunicação. Determina a forma de recebimento e envio de

dados aos serviços;

Abstração

A arquitetura SOA promove um alto nível de abstração,

considerando o encapsulamento das regras de negócio em

serviços, permitindo que os mesmos sejam reutilizados;

Composição

Serviços podem ser compostos para formar novos serviços com um

nível maior de abstração e provendo funcionalidades agregadas. A

flexibilidade na composição de novos serviços a partir de serviços já

disponíveis na rede é o grande atrativo da arquitetura (SOUZA,

apud OLIVEIRA, 2008, p.66);

Alta Granularidade

O encapsulamento de funcionalidades no nível de serviço evoca um

alto grau de granularidade nos componentes básicos da arquitetura.

Um objeto individual apresenta operações muito finas para prover

funcionalidades significativas no nível corporativo. Para o

desenvolvimento de aplicações complexas e extensas a alta

granularidade traz vantagens na medida em que detalhes de

implementação são deixados à equipe de desenvolvimento

responsável por aquele serviço (SOUZA apud OLIVEIRA, 2008

p.66).

Heterogeneidade

Para maior interoperabilidade, SOA promove na implementação de

serviços a independência de plataforma de desenvolvimento,

tecnologias de implementação e linguagens de programação.

Ubiqüidade

Os serviços devem ser acessíveis a partir de qualquer lugar e a

qualquer momento facilitando a composição de serviços entre

empresas (SOUZA apud OLIVEIRA, 2008 p.67).

Tabela 5 – Principais Características da Arquitetura SOA. Fonte: Adaptada de MIRANDA (2008, p.21).

Page 58: Monografia bpm

58

3.2 Componentes SOA

De acordo com a especificação de arquitetura orientada a serviços pela

organização OASIS, SOA é um paradigma para organização e utilização de

competências distribuídas que estão sob o controle de diferentes domínios

proprietários (OASIS, 2007). Para prover essa organização e utilização, a

Arquitetura SOA dispõe de quatro componentes principais: 1- Aplicação Frontend; 2

- Serviço; 3 - Repositório de Serviço e 4 - Barramento de Serviço (KRAFZIG apud

MIRANDA, 2008, p.26).

Esses componentes estão dispostos de forma interoperável ou colaborativa,

fornecendo a estrutura necessária para a disponibilização dos serviços. A Figura 11

ilustra uma visão geral da arquitetura SOA.

Figura 11 – Componentes da arquitetura SOA.

Fonte: MIRANDA (2008, p.26).

Page 59: Monografia bpm

59

3.2.1 Aplicação Frontend

Segundo Josuttis (apud Miranda, 2008, p.27) são os elementos ativos de

SOA, iniciando e controlando as atividades de um sistema e entregando o resultado

do serviço, interagindo com o usuário. Existem diferentes tipos de Aplicações

FrontEnd. Um exemplo desse componente é uma aplicação de interface gráfica,

como uma aplicação Web que utiliza um browser para a interação com o usuário,

fazendo a chamada do processo e recebendo o resultado da execução de um

serviço. Uma Aplicação Frontend desempenha um papel muito próximo ao Padrão

de Projetos Facade (Fachada), onde um objeto disponibiliza uma interface que dá

acesso a uma grande quantidade de funcionalidades de um subsistema, abstraídas

do objeto que originou as chamadas. A Figura 12 ilustra um exemplo de Aplicação

FrontEnd.

Figura 12 – Exemplo de Aplicação Frontend.

Fonte: MIRANDA (2008, p.27).

Page 60: Monografia bpm

60

3.2.2 Serviços

Um Serviço pode ser entendido como uma função do sistema computacional

construída de forma a ser facilmente vinculada a outros componentes de software,

que podem ser outros serviços. O Serviço tem papel fundamental dentro da

Arquitetura Orientada a Serviços, pois encapsula uma função de negócio que pode

ser reutilizável, tendo como características marcantes a independência de

tecnologias de linguagens de programação em sua implementação e baixo

acoplamento. A Figura 13 ilustra a composição de um serviço com seus sub-

componentes.

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

Fonte: KRAFZIG apud MIRANDA (2008, p.28)

Cada serviço deve conter um Contrato, que especifica restrições quanto ao

acesso ao serviço e uso dos serviços. O contrato impõe semântica sobre as

Page 61: Monografia bpm

61

funcionalidades e parâmetros do serviço (DAVIES apud MIRANDA, 2008, p. 28). Os

serviços também devem disponibilizar Interfaces, que definem as operações

disponíveis em um serviço. As interfaces podem ser entendidas como as assinaturas

dos métodos definidos em classes na Orientação a Objetos, onde é descrito o tipo

de retorno, o nome da operação, sua visibilidade e argumentos.

A regra de negócio realizada pelo serviço deve estar contido na

Implementação, que proporciona a execução do serviço utilizando a lógica de

negócio e os dados necessários. Alem da lógica de negócios e dos dados, fazem

parte da Implementação os subprogramas, os dados e arquivos de configuração e a

base de dados.

SOA promove a idéia de módulos de software que prestam serviços a outros

módulos, com características e tecnologias diferentes. A concepção de serviço tem

três características principais, conforme mostra a tabela 06.

CARACTERÍSTICA DESCRIÇÃO

Interface

A descrição do serviço através de uma interface, ou seja,

como aquele serviço será conhecido e como ele será

acessado;

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

Implementação

Sua implementação, ou seja, a funcionalidade por trás da

interface. Atualmente, essa abordagem converge para o

padrão de Web Services. No passado, sistemas empresariais

operavam com diferentes tipos de interfaces, projetadas em

tecnologias distintas.

Tabela 6 – Características da Concepção de Serviços. Fonte: MIRANDA (2008, p.29).

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

Page 62: Monografia bpm

62

• Serviço utilitário: são serviços que implementam algumas

funcionalidades gerais que podem ser utilizadas por diferentes

processos de negócios;

• Serviço de entidade: são serviços associados a uma função específica

do de negócio;

• Serviço-tarefa: são serviços que apóiam os processos de negócios

mais gerais que envolvem diferentes atores e atividades.

3.2.3 Ciclo de Vida dos Serviços

Segundo Miranda (2008, p. 30) os serviços são considerados pedaços de

software que encapsulam alguma funcionalidade de negócios. Como tal, seu ciclo de

desenvolvimento é comum aos softwares, consistindo nas fases de: modelagem,

implementação, integração e execução. O ciclo de vida de um serviço pode aplicar o

modelo em cascata, porém, assim como no desenvolvimento de um software, não é

o modelo ideal, podendo assumir um ciclo de vida iterativo, onde o desenvolvimento

de software pode ser ajustado com as experiências obtidas nas fases anteriores. A

Tabela 7 apresenta as etapas do ciclo de vida dos serviços bem como a descrição

de cada etapa.

Page 63: Monografia bpm

63

ETAPA DESCRIÇÃO

Modelagem A fase de modelagem gera um produto: a especificação da

interface do serviço. Esta interface inclui a semântica e os

atributos não funcionais;

Implementação

Esta é a fase de codificação do serviço, utilizando tecnologias

como linguagens de programação, protocolos de comunicação e

plataformas de desenvolvimento;

Integração Fase de adequação dos serviços aos sistemas que farão uso da

Arquitetura SOA. É a inserção do serviço no domínio do problema;

Execução Fase em que o serviço estará disponível para uma Aplicação

FrontEnd ou qualquer outro tipo de consumidor.

Tabela 7 - Fases do Ciclo de Vida do Serviço Fonte: MIRANDA (2008, p. 30).

3.2.4 Repositório de Serviços

Miranda (2008, p. 31) cita ainda que outra estrutura importante dentro da

arquitetura SOA é o Repositório de Serviços , que fornece meios para facilitar a

descoberta de serviços, bem como, as informações referentes ao serviço. Essas

informações podem variar, podendo informar sobre a localização física, pessoas de

contato, informações sobre o fornecedor, utilização de restrições de segurança e

níveis do serviço.

Geralmente, um Repositório de Serviços está associado ao escopo de uma

empresa ou organização. É possível utilizar a arquitetura SOA sem um Repositório

de Serviços. Isso depende da quantidade de serviços disponibilizados a nível

empresarial. Por isso, por mais que uma empresa que esteja adotando SOA não

possua muitos serviços a serem disponibilizados, é interessante optar pela utilização

de um repositório, pois isso trará benefícios em longo prazo (KRAFZIG apud

MIRANDA, 2008, p. 31).

Page 64: Monografia bpm

64

3.2.5 Barramento de Serviços

Segundo Galdino (apud Miranda, 2008, p.31) o Barramento de Serviços

interconecta todos os elementos da arquitetura SOA, funcionando como canal de

comunicação. Este barramento facilita o compartilhamento de serviços dentro de

uma corporação, fornecendo transparência na localização dos serviços. Se duas

aplicações precisam se comunicar entre si, uma Aplicação de Frontend invoca as

funcionalidades de um serviço utilizando o Barramento de Serviços. É importante

destacar que o barramento de serviços não é necessariamente composto por uma

tecnologia, podendo abranger uma grande variedade de soluções tecnológicas.

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

CARACTERÍSTICAS DESCRIÇÃO

Conectividade

Objetivo principal do Barramento de Serviços. Permite

interligar os componentes de uma arquitetura SOA,

fornecendo facilidades que permitam ao FrontEnd

invocar as funcionalidades dos serviços;

Tecnologias Heterogêneas

O Barramento suporta uma gama de tecnologias, o

que geralmente é a realidade das empresas, que em

sua maioria, adotam por soluções distintas. Essas

tecnologias variam desde linguagens de programação,

sistemas operacionais, ambientes de execução,

middlewares e protocolos de comunicação;

Serviços Técnicos

Embora a funcionalidade principal do Barramento de

Serviços seja a comunicação entre componentes e

serviços, o barramento também fornece alguns

serviços como auditoria, segurança, transformação de

mensagens e transações.

Tabela 8 – Características do Barramento de Serviços. Fonte: MIRANDA (2008, p. 32).

Page 65: Monografia bpm

65

3.3 Composição de Serviços

Segundo Moreira (2007, p.32.) para solucionar problemas como distribuição e

heterogeneidade de aplicações, surge a necessidade de composição de serviços.

Esta técnica permite modelar o processo de negócio e também aumenta a

possibilidade de aproveitar os benefícios da arquitetura orientada a serviços.

O mecanismo da composição de serviços visa combinar dois ou mais serviços

para que, juntos, possam atender a requisitos que vão além das suas capacidades

individuais. Em outras palavras, a composição provê uma abordagem aberta,

baseada em padrões, para conectar Web Services objetivando criar processos de

negócio de alto nível, com um alto valor agregado. A Figura 14 exemplifica uma

composição de serviços.

Uma das principais motivações para a utilização da composição de serviço é

o desenvolvimento de processos de negócio envolvendo vários parceiros e

seqüência de operações.

Figura 14 – Composição de Serviços

Fonte: MOREIRA (2007, p.33).

Page 66: Monografia bpm

66

Os padrões são projetados para reduzir a complexidade requerida para

compor Web Services, reduzindo custo e tempo, e aumentando a eficiência global

nos negócios.

De acordo com Moreira (2007, p. 33), a composição de serviços deve atender

as seguintes exigências:

• Habilidade de invocar serviços de maneira assíncrona, alcançando

confiabilidade, escalabilidade e adaptabilidade, características

necessárias em um ambiente de negócios;

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

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

Services usados;

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

A composição de serviços faz uso de vários serviços para criar um serviço

e/ou o uso de um serviço por outro serviço vai se tornando mais comum, para a

criação de processos, para isso dois conceitos são muito importantes: orquestração

e coreografia, como visto na figura 15.

Figura 15 – Orquestração e Coreografia.

Fonte: LEITÃO e MARGALHO JUNIOR (2007, p.25)

Page 67: Monografia bpm

67

3.3.1 Orquestração

As interações do processo de negócios são controladas por uma das partes

envolvidas no processo. A orquestração envolve interações entre as partes e os

passos entre as interações (FANTINATO; TOLEDO; GIMENES apud SOUZA, 2008,

p.61).

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

Um dos requisitos que guia a criação de orquestrações é o fato de unir

processos de negócio. Com a orquestração, diferentes processos podem ser

conectados sem que seja necessário desenvolver novamente as sua

funcionalidades em um novo sistema. O uso da orquestração pode reduzir

significativamente a complexidade de implementação, bem como facilitar a

manutenção dos sistemas (ERL, 2005, p. 203).

A Figura 16 exibe o funcionamento do processo de orquestração de serviços.

O coordenador central (por exemplo, um Web Service) recebe uma mensagem do

Web Service 1 requisitando alguma informação. O coordenador invoca alguns

parceiros a fim de agrupar a informação e então retorna o resultado para o Web

Service 1. Este tipo de processo pode ser conhecido como privado e executável, já

que apenas a entidade que está orquestrando o processo conhece o fluxo de

controle e informação que o segue. A principal técnica de implementação da

orquestração é através da linguagem BPEL.

Page 68: Monografia bpm

68

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

Fonte: MOREIRA (2007, p.34).

3.3.2 Coreografia

Diferentemente da orquestração, a coreografia de serviços não concentra o

fluxo de controle em uma única unidade. Ao invés de um único coordenador, todos

os serviços envolvidos na operação conhecem quando e com quem irão interagir,

havendo uma cooperação entre os serviços, cada um conhecendo o seu papel

dentro do fluxo. A colaboração é efetuada através da troca de mensagens entre os

serviços participantes (MOREIRA, 2007, p. 34).

Ao invés de um único coordenador, todos os serviços envolvidos na operação

conhecem quando e com quem irão interagir, havendo uma cooperação entre os

serviços, cada um conhecendo o seu papel dentro do fluxo. A colaboração é

efetuada através da troca de mensagens entre os serviços participantes. A figura 17

exemplifica o funcionamento da coreografia de serviços.

Comparando as duas abordagens, a orquestração se difere da coreografia por descrever um fluxo de processo entre serviços controlados por uma única entidade. Por outro lado, coreografia é mais colaborativa no sentido de que ela traça a seqüência das mensagens entre os participantes envolvidos, em que nenhum deles controla a conversação (MOREIRA, 2007, p. 35).

Page 69: Monografia bpm

69

Figura 17 – Exemplo de Coreografia de serviços

Fonte: MOREIRA (2007, p.35).

As vantagens da orquestração segundo ALLEMANN (apud SOUZA, 2008,

p.63) sobre a coreografia sobre o ponto de vista de um processo de negócio são

dadas pela sua alta flexibilidade, são elas:

• A coordenação de componentes é gerenciada centralmente por

um coordenador;

• Flexibilidade: por exemplo, a incorporação de uma Web Service

em um grande processo de negócio sem que haja um

conhecimento explícito;

• Tolerância a faltas, permitindo cenários alternativos.

Page 70: Monografia bpm

70

3.3.3 BPEL

A BPEL foi criada em 2003, inicialmente pela Microsoft em parceria com a

IBM, SAP e Sibel, após algum tempo o seu controle de padrão foi passado para a

OASIS (Organization for the Advancement of Structured Information Standards).

Esta linguagem descreve os processos de negócios e os protocolos de

negócios de Web Services, que são tratados por um script baseado em XML que

descrevem a lógica de controle de cada processo e protocolo. Esse script será

interpretado em uma máquina intermediaria que irá realizar o controle da

composição. Em sua lógica de negócio que seqüencia, coordena e gerencia a

comunicação entre Web Services dentro de uma aplicação de negócio. BPEL é

apontado como uma ferramenta fundamental para empresas que querem

economizar tempo de desenvolvimento, reduzir custos na entrega de novas

soluções e manutenção de aplicações existentes.

A linguagem de execução de processos de negócios (WS-BPEL –Business Execution Language), que é uma linguagem de programação baseada em XML para controlar as interações dos serviços.(SOMMERVILLE apud SOUZA, 2008,p.54).

A figura 18 demonstra um fluxo de processo BPEL, onde a parte central da

figura representa a máquina intermediária, que realiza a orquestração e coreografia.

Dentro dela existem passos que definem e controlam o fluxo da transação, além de

realizar controles de tratamento de exceções e transações, papéis e parceiros e

persistência e variáveis do Web Services que trabalham no entorno dela.

Page 71: Monografia bpm

71

Figura 18 – Fluxo de Processo BPEL.

Fonte: LEITÃO e MARGALHO JUNIOR (2007, p.27)

Portanto, BPEL é um padrão de linguagem que manipula estrutura de dados

XML, recebe mensagens XML assíncronas de serviços remotos e ainda gerencia

eventos e exceções, retornando partes do processo quando essas exceções

ocorrem, tornando os Web Services mais poderosos para quebrar barreiras

invisíveis de integração entre empresas parceiras ou fornecedoras/clientes, sem ter

problemas com comunicação.

Um processo especificado em BPEL consiste em dois tipos de atividades:

atividades básicas apresentadas no Quadro 01 e atividades estruturadas

apresentadas no Quadro 02. Estas determinam a estrutura, a seqüência do

processo, já aquelas determinam o que acontecerá no processo, por exemplo, o

recebimento de uma mensagem de um Web Service.

Page 72: Monografia bpm

72

Quadro 1 – Atividades básicas de BPEL

Fonte: MOREIRA (2007, p.38).

No Quadro 02, são ilustradas as atividades estruturadas, as quais definem a

ordem em que as atividades devem ser realizadas.

Quadro 2 – Atividades Estruturadas de BPEL.

Fonte: MOREIRA (2007, p.38).

Page 73: Monografia bpm

73

Moreira (2007, p. 36 - 37) cita que o BPEL provê expressões para

comportamentos condicionais, para loops, para declarar variáveis, para copiar e

atribuir valores. As especificações baseadas em BPEL utilizam o XML para

descrever aspectos do processo.

Os principais elementos de um documento BPEL estão representados na

Figura 19.

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

Fonte: MOREIRA (2007, p.37).

Page 74: Monografia bpm

74

A tag partner especifica os participantes da composição. Normalmente, neste

local são armazenados os endereços dos servidores que estão 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 variáveis utilizadas no processo. Essas variáveis

podem ser inicializadas, copiadas para outros serviços e até alteradas. As variáveis

representam uma grande vantagem do uso deste padrão: a possibilidade de

armazenar estados durante a execução da composição.

A tag correlationSets identifica para qual instância de processo uma nova

mensagem recebida deve ser roteada. Este elemento é também responsável por

não permitir que existam duas interações distintas de Web Services caso elas sejam

oriundas do mesmo parceiro.

A seção faultHandlers define as atividades que devem ser realizadas em

resposta à falhas resultantes da invocação de serviços. Em associação com a tag

faultHandlers, a tag compensationHandlers reverte atividades completadas,

retornando ao seu estado inicial (MOREIRA, 2007, p. 38).

A WS-BPEL também fornece uma maneira de tratar eventos

concorrentemente à execução do processo através do uso da tag eventHandlers.

Como exemplo de eventos é possível citar o estouro de tempo de determinada

operação. O resto da definição do proccess é composto de atividades (activity)

(ROCHA apud SOUZA, 2008, p.58).

Na figura 20, é apresentado um exemplo da interface de um programa

executável, que foi concebida após a disponibilização do projeto e modelada

utilizando a linguagem BPEL, desta forma possibilitando uma comunicação entre

processos independente da linguagem de programação, graças à utilização de XML

(ROCHA apud SOUZA, 2008, p.59).

Page 75: Monografia bpm

75

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

Fonte: BENEDETE (2007, p.28).

3.4 Camadas de Abstração

Segundo Bieberstein (apud Miranda, 2008, p.22) a arquitetura SOA está

basicamente voltada ao uso de serviços, que constituem a abstração de uma ou

mais regras de negócio. Porém, há mais camadas de abstração envolvidas no uso

da Arquitetura Orientada a Serviços como: Camada Corporativa, Camada de

Processos, Camada de Serviços, Camada de Componentes e Camada de Objetos.

A Figura 21 mostra a composição de SOA através de suas camadas de

abstração.

Page 76: Monografia bpm

76

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

Fonte: BIEBERSTEIN apud MIRANDA (2008. P. 22)

3.4.1 Camada Corporativa

Esta camada descreve as operações empresariais realizadas por uma

determinada organização ou empresa. Nesta camada estarão os procedimentos

relevantes das atividades de negócios empresariais pertencentes a uma

determinada corporação (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 serviços. Nesta camada, utiliza-

se referência aos procedimentos necessários para a realização dos negócios

empresariais (MIRANDA, 2008, p. 23).

Page 77: Monografia bpm

77

3.4.3 Camada de Serviços

Nesta camada, os serviços são mapeados por suas funcionalidades básicas e

de negócios, identificando as ações críticas para satisfazer as regras de negócio.

Esta camada abrange os serviços de todas as naturezas para fins específicos. Cada

serviço desta camada pode ser decomposto em vários outros serviços simples que

podem ser implementados utilizando componentes (MIRANDA, 2008, p. 23).

É necessário que a orientação a serviços seja propagada por toda a

corporação. Isso pode ser alcançado pela abstração das camadas de serviço (ERL

apud SOUZA, 2008, p.35).

Nas palavras de Baldam (2008, p. 104), o conceito da orientação a serviços

“expressa a intenção de disponibilizar aplicativos ou rotinas independentes como

serviços, em uma rede de computadores (Internet ou Intranet), comunicando se por

padrões abertos”. A estrutura da organização pode ser dividida em lógica de negócio

e lógica de aplicação, como apresentado na figura 22.

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

Fonte: ERL apud OLIVEIRA (2008, p.70).

Page 78: Monografia bpm

78

A camada de interface de serviços da organização localiza-se entre as

camadas de processo de negócio e de aplicação. Esta camada pode ser divida em

três tipos de serviços, como mostra a figura 23 (ERL apud MOREIRA, 2007, p.27),

os quais serão detalhados posteriormente:

• Serviços de Utilidades;

• Serviços de Negócios;

• Serviços de Coordernação.

Figura 23 – As três principais camadas de serviços. Fonte: ERL adaptado por MOREIRA (2007, p.28).

3.4.3.1 Camada de Serviço de Aplicação

A camada de serviços de aplicação estabelece o nível base para expressar

Page 79: Monografia bpm

79

funcionalidades com uma tecnologia específica. O seu propósito é prover funções

reusáveis relacionadas ao processamento de dados de um sistema novo ou legado

(MOREIRA, 2007, p. 28). A figura 24 ilustra esta camada.

Os serviços de aplicação, como são chamados os serviços desta camada,

têm como características principais as seguintes:

• Expõem funcionalidades dentro de um contexto específico;

• São genéricos e reusáveis;

• Podem ser usados para atingir uma integração ponto a ponto com

outros serviços de aplicação.

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

Fonte: MOREIRA (2007, p. 49).

Segundo Erl (apud Oliveira, 2008, p. 72), exemplos típicos deste modelo de

serviços são serviços utilitários e wrapper. Os serviços dessa camada podem conter

Page 80: Monografia bpm

80

lógicas de negócio e de aplicação, este modelo é comumente encontrado nos

sistemas distribuídos atuais, contudo, sua utilização não é recomendada. Ao invés

disso, os serviços de aplicação podem ser facilmente compostos com outros

serviços.

3.4.3.2 Camada de serviços de negócio

Enquanto os serviços de aplicação representam a lógica da aplicação

utilizada para expressar uma funcionalidade específica, a camada de serviços de

negócio introduz um serviço centrado apenas em reproduzir a lógica de negócio,

representando a implantação de algum modelo de negócio, esta camada é ilustrada

na figura 25 (MOREIRA, 2007, p. 29). Esses serviços são a base da arquitetura

orientada aos serviços.

O único propósito para os serviços de negócio é representar lógica de negócio da forma mais pura possível. Um serviço de negócio pode ser classificado como um serviço controlador ou um serviço utilitário, por exemplo. Quando a lógica de aplicação é abstraída em uma camada de serviços de aplicação, é normal que os serviços de negócio sejam controladores que compõem serviços de aplicação a fim de executar a sua lógica de negócio (ERL apud OLIVEIRA, 2008, p.73).

Page 81: Monografia bpm

81

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

Fonte: MOREIRA (2007, p. 51).

Os serviços desta camada podem ser classificados em dois modelos:

• Serviços de negócios centrados em tarefas: encapsula a lógica

específica para uma tarefa ou processos de negócio. Esse serviço tem

um potencial de reuso baixo;

• Serviços de negócio centrados em entidade: encapsula uma entidade

de negócio específica. Estes serviços são bastante úteis para a criação

de serviços por serem altamente reusáveis. Geralmente são

compostos em uma camada de orquestração ou por um serviço

centrado a tarefa (MOREIRA, 2007, p. 29).

Page 82: Monografia bpm

82

3.4.3.3 Camada de serviço de orquestração

Esta camada introduz um nível de abstração que diminui a necessidade dos

serviços gerenciarem detalhes de interação para garantir que as operações sejam

executadas em uma ordem seqüencial correta. Dentro desta camada, os processos

compõem outros serviços que provêem conjuntos específicos de funções,

independentes das regras de negócio e cenário requeridos para executar uma

instância de processo (ERL apud MOREIRA, 2007, p. 29).

3.4.4 Camada de Componentes

Os componentes utilizados nesta camada são blocos de construção de

serviços, que podem englobar uma ou mais rotinas escritas em determinada

linguagem de programação. Esses componentes são mapeados em serviços ou são

mapeados para se adequarem a serviços (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 serviços de

uma SOA. Em arquiteturas de SOA modernas, serviços são implementados

utilizando os objetos (MIRANDA, 2008, p. 23).

Page 83: Monografia bpm

83

3.5 Ciclo de vida SOA

A arquitetura SOA está definida em quatro estágios distintos que compõem

seu ciclo de vida. Esses estágios são compostos por etapas que contemplam a

estratégia na elaboração de uma solução utilizando a Arquitetura SOA, a

modelagem necessária para as regras de negócios, a implementação, que

corresponde à codificação dos serviços 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.

Fonte: MIRANDA (2008, p.24).

Page 84: Monografia bpm

84

As etapas do ciclo de vida de SOA, bem como suas descrições, conceitos e

características serão abordadas com maiores detalhes nas quatro seções a seguir.

3.5.1 Estratégia

Corresponde ao primeiro estágio do Ciclo de Vida de uma Arquitetura

Orientada a Serviços. Neste estágio, são definidas algumas diretrizes para o uso de

SOA: as atividades que estarão no escopo da Arquitetura; o foco dos processos e

medidas estratégicas com a adoção da Arquitetura Orientada a Serviços.

Segundo Erl (2008, p. 300), escolher uma abordagem de entrega é uma

decisão crucial, porque representa a escolha com a qual a organização normalmente

terá de conviver por bastante tempo.

3.5.1.1 Bottom-up

Segundo Erl (2008, p. 299) a estratégia de bottom-up evita custos, esforços e

tempo extras necessários para entregar serviços por meio de uma abordagem top-

down, ela acaba impondo maior carga de governança, porque os serviços entregues

bottom-up tendem a ter tempos de vida mais curtos e exigem manutenção e

refatoração mais freqüentes.

Page 85: Monografia bpm

85

3.5.1.2 Top-down

Erl (2008, p. 299) explica que a estratégia top-down exige mais de um

investimento inicial porque cria uma etapa de análise positiva, concentrada na

criação do esquema de um inventário de serviços. Uma coleção de candidatos a

serviço é individualmente definida como parte desse esquema para assegurar que

os designs de serviço subseqüentes sejam altamente normalizados, padronizados e

alinhados.

3.5.2 Modelagem

Segundo Miranda (2008, p. 25) este segundo estágio do Ciclo de Vida SOA

corresponde a modelagem de processos de negócios. Esta modelagem engloba um

conjunto de práticas ou tarefas realizadas pelas instituições para descrever

visualmente todos os aspectos de um processo de negócio, incluindo seus principais

pontos de decisão para a execução das atividades. Essa descrição visual

normalmente é compreensível pela maioria das pessoas envolvidas nas

implementações dos processos de negócios. Em gestão de TI, esse estágio é

denominado de Business Processes Management (Gerenciamento de Processos de

Negócios), alternativamente chamado de Business Processes Modeling (Modelagem

de Processos de Negócio). A figura 27 demonstra as atividades do ciclo de vida

associados com os serviços no ambiente SOA.

Page 86: Monografia bpm

86

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

Fonte: GU e LAGO (2007, p.4).

3.5.3 Implementação

Neste estágio, o foco é o desenvolvimento dos serviços, ou seja, sua

codificação em alguma plataforma e linguagem de programação, levando em

consideração as tecnologias de implementação disponíveis e as decisões tomadas

nos estágios anteriores quanto a adoção da Arquitetura SOA, tanto nas tomadas

estratégicas quanto nas modelagens definidas pelos gestores e analistas

(MIRANDA, 2008, p. 25).

3.5.4 Monitoramento (Business Activity Monitoring)

O estágio de monitoramento encerra um ciclo de vida da Arquitetura SOA.

Este estágio, também chamado de Business Activity Monitoring – BAM

Page 87: Monografia bpm

87

(Monitoramento de Atividade de Negócio), permite que seja feita a análise em tempo

real dos dados trafegados em uma rede através do uso de um software que analisa

os dados e exibe informações gerenciais como resultado (MIRANDA, 2008, p. 26).

3.6 Web Services

A necessidade de conectar informações e processos mudaram a forma como

o software vem sendo desenvolvido. Sistemas bem-sucedidos de TI exigem cada

vez mais interoperabilidade entre plataformas e serviços flexíveis que possam

evoluir facilmente com o tempo. Segundo o Word Wide Web Consortium (W3C), a

tecnologia de Web Services fornece um mecanismo padrão de interoperabilidade

entre diferentes aplicações de softwares, executando em uma variedade de

plataformas ou frameworks (W3C, 2009).

É apontado como uma grande vantagem dos Web Services, a utilização de

baixo acoplamento entre sistemas e sua interoperabilidade, além de usar padrões

abertos baseados em XML como WSDL, SOAP .e UDDI. Abaixo na figura 28 é

demonstrada a arquitetura do Web Services.

As Arquiteturas de aplicação dos Web Services são arquiteturas não firmemente acopladas nas quais as ligações de serviços podem mudar durante a execução. Alguns sistemas serão somente construídos com a utilização de Web Services e outros os integrarão com componentes desenvolvidos localmente (SOMMERVILLE, 2003,p.191)

Page 88: Monografia bpm

88

Figura 28 – Arquitetura Web Services

Fonte: MOREIRA (2007, p.3)

Segundo Sommerville (2003, p.191), os três padrões fundamentais que

possibilitam comunicações entre Web Services são:

1. SOAP (Simple Object Acess Protocol) – Protocolo que define uma

organição 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) – Padrão de

descoberta que define como as informações de descrição do

serviço, usadas pelos solicitantes do serviço para descobrir serviços,

pode ser organizada.

Page 89: Monografia bpm

89

4. PROJETO NEW_RCMS: ESTUDO DE CASO

O método de pesquisa adotado para a realização deste trabalho foi o estudo

de caso, com o objetivo de analisar um caso prático de implantação do

gerenciamento de processos de negócio em um departamento de Service Desk. O

levantamento de informações utilizado para esse estudo de caso baseou-se em

etnografia e análise dos dados atuais e de documentos.

4.1 Descrição do ambiente de pesquisa

O estudo de caso realizou-se dentro do contexto de uma organização que

atua no mercado de prestação de serviços de TI, neste segmento ela está

posicionada em primeiro lugar no Brasil. A empresa tem atuação no mercado

nacional e internacional. Sua diversificada atuação inclui Outsourcing, centros de

pesquisas tecnológicos, desenvolvimento de hardware e software e soluções de TI.

Os trabalhos de pesquisa junto à empresa consistiram em entrevistas com

profissionais responsáveis pela área de Processos e usuários. Esta área em

conjunto com o time de TI, foram os responsáveis pela implantação do BPM na

empresa.

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

Para garantir um maior controle e a geração de informações mais confiáveis

para o monitoramento de suas atividades, a organização buscou através do

Page 90: Monografia bpm

90

gerenciamento de seus processos, uma solução estratégica capaz de auxiliar a

gestão e otimização dos processos de negócio.

Analisando a forma como o processo era realizado, é possível identificar

alguns pontos que impactavam a gestão dos processos:

• Constante ocorrência de erros;

• Controle inadequado dos processos;

• Dificuldade para realizar melhorias;

• Altas taxas de abandono em ligações;

• Perda de SLA´s estabelecidos em contrato;

• Clientes insatisfeitos.

A ocorrência de problemas, devido a falhas no processo, problemas externos

de hardware, software ou erros humanos, era dificilmente detectada durante a

execução dos processos, desta forma, impactando diretamente a produtividade, e

como conseqüência perda de SLA (porcentagem de serviço de acordo com o

contrato) e constantes reclamações de seus clientes.

O controle e monitoramento dos processos tornam-se falhos devido a pouca

visibilidade dos processos, a possível inconsistência de dados como conseqüência

da perda de informações e a dificuldade de automação das métricas.

O BPM possibilitou o gerenciamento e a otimização dos processos de

negócio, por meio da elaboração de workflows para controle e aprovação de

processos, bem como a visualização das etapas que compõe o fluxo da operação,

identificando possíveis pontos de melhorias ou “gargalos” do processo, é possível

também identificar em qual estágio do processo as atividades se encontram.

Depois da definição das metas estratégicas, os processos críticos são

modelados, simulados e documentados pela área de negócio, com o apoio dos

analistas de negócio e de ferramentas de modelagem, os KPIs são identificados

para posterior gerenciamento dos processos. A área de TI identifica as

oportunidades de integração e automação do processo desenhado.

Page 91: Monografia bpm

91

Após estas etapas o processo entra em operação, os usuários irão acessar as

atividades do processo através de portais via Web. Os processos são executados e

gerenciados, extraindo-se o histórico e as tendências, que serão utilizadas pela

gerência como fonte de informação para auxiliar a tomada de decisão.

Através da habilidade de entender como os processos ocorrem, intensifica-se

a capacidade de identificar e implantar melhorias importantes para a organização.

A utilização da abordagem de arquitetura orientada a serviços como melhores

práticas, garante que os processos implantados estejam flexíveis para possíveis

mudanças das necessidades de negócios.

4.3 Modelagem do processo de negócio de Atendimento de Chamados

Para ilustrar a aplicação do gerenciamento de processos de negócio no

departamento de Service Desk, na qual este estudo foi realizado, essa fase

apresenta a modelagem de um processo através de uma ferramenta de notação

BPM. O processo de negócio escolhido para esta transcrição 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 necessários para o

desenvolvimento do modelo:

Page 92: Monografia bpm

92

SISTEMA DESCRIÇÃO

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 peça.

PORTAL WEB Sistema para clientes abrirem chamados via internet.

WEB LINK Link direto com a rede da empresa onde os próprios equipamentos abrem um

chamado no RCMS.

PDA

Os PDA´s possuem uma aplicação desenvolvida em Java que acessa o

sistema da empresa via internet (tecnologia 3G), dessa forma os técnicos

fazem atualizações nos chamados sem precisar ligar na URA do Service Desk.

IRCM

Repositório de dados informativos do RCMS do Brasil e o tipo de informação

que contém chamados de manutenção de serviços de hardware, a informação

provém do RCMS 7.5. Brasil.

LAI2 Banco de dados de gerenciamento de chamados.

YRSX Brasil

SSAC Argentina

OSAR México

FEMS Sistema automático de proposta e contrato.

PASS PASS – banco de dados de inventário de HW

LA CCPF

Os dados de cliente e inventário de SW e HW são enviados para o RETAIN

(informações legadas). Este aplicativo é uma interface que pesquisa

informações do cliente dentro do RCMS / HW / SW / dados de inventário 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 inventário.

XPOC Banco de dados de parceiros.

Tabela 9 – Principais sistemas do Service Desk. Fonte: do autor.

Page 93: Monografia bpm

93

A figura 29 apresenta uma visão macro da arquitetura dos sistemas que se

integram e alimentam a base de dados do RCMS para que ele carregue todas as

informações dos clientes (código de cliente, informações 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 interação entre os envolvidos nos

processos analisados e a equipe responsável pelos processos, através da

observação in-loco e de entrevistas. A partir das informações coletadas, os

Page 94: Monografia bpm

94

processos começaram a se construídos, utilizou-se nesta etapa uma ferramenta de

modelagem de processos baseados na notação gráfica BPMN. O quadro 03

descreve o processo de negócio no seu estado atual:

DESCRIÇÃO DO PROCESSO DE NEGÓCIO (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 necessários para abertura do chamado para Hardware:

• Tipo e série do equipamento; • Nome da empresa; • Endereço; • Telefone; • Pessoa de contato; • Problema.

*Caso o cliente informe tipo e série do equipamento incorretamente, chamado será direcionado para uma fila de inventário, 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 técnico de plantão para o atendimento.

Para Software:

• Código de Cliente; • Produto; • Sistema Operacional; • Tipo e série do equipamento (se necessário); • Pessoa de contato; • Telefone; • Problema.

*Caso cliente não 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º nível de atendimento.

3 - Caso Cliente já possua chamado em aberto, Call Dispatch direciona chamado para departamento responsável. 4 - Caso seja chamado de Software cliente é direcionado para Departamento CAC ADM ou fora do horário comercial para gerente onduty e o mesmo decide se chamado será atendido ou não. 5 - Analista de software faz atualizações no chamado e descreve todas as ações que foram tomadas para solução do problema, chamado pode ser finalizado ou continuar em aberto caso ainda não tenha sido solucionado. 6 - Caso Seja chamado de Hardware o mesmo é direcionado aos técnicos de plantão. 7 - Técnico liga no Call Dispatch, atualiza o chamado e informa quais medidas foram tomadas para solução do problema, chamado pode ser finalizado ou continuar em aberto caso ainda não tenha sido solucionado. 8 - Clientes que possuem Link Direto com a empresa, os próprios equipamentos abrem chamados diretamente no sistema, quando apresentam algum problema, se chamado for para hardware é repassado para o técnico com acionamento via voz, se for de software os analistas de Software são informados pelo Call Dispatch via voz e entram em contato com cliente. 9 - Se as Informações providas pelo cliente sejam incorretas, chamado poderá ser cancelado pelo analista de

Page 95: Monografia bpm

95

software ou técnico. 10 - Clientes que abrem chamado no Portal Web têm acesso ao sistema da empresa com senha e login, chamado é repassado para o técnico via voz, no caso de analistas de Software, os mesmos são informados pelo Call Dispatch via voz e entram em contato com cliente. 11 - Se as Informações providas pelo cliente sejam incorretas, chamado é cancelado pelo analista ou técnico. 12 - Fim do Processo de atendimento ao cliente. 13 - Técnicos/Especialistas ligam no Call Dispatch e solicitam pedido de peça para término da manutenção, o mesmo fornece seus dados como matrícula e um código de segurança que é diferente para cada território, número da peça, quantidade e a emergência. Pedido da peça é solicitado no sistema e Estoque envia pela transportadora. 14 - Caso alguns dos dados esteja incorreto pedido não poderá ser consumado. 15 - Técnicos ligam no Call Dispatch para fazer algumas atualizações nos chamados. 16 - Fim do Processo de Atendimento a técnicos. 17 - Call Dispatch monitora todas as filas de atendimento para hardware e caso cliente tenha contrato de cobertura aloca técnico de plantão e repassa chamado.

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

A notação de modelagem de processo de negócio aplicada no estudo de caso

foi a BPMN, já que por meio da utilização dessa notação, é possível ilustrar um

processo de negócio de forma simplificada e de fácil compreensão. 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 informações descritas no quadro 03.

Page 96: Monografia bpm

96

Figura 30 – Processo modelado (As Is).

Fonte: do autor.

Page 97: Monografia bpm

97

Após o projeto ter sido executado com a modelagem do estado atual (As Is) e

a equipe responsável pelos processos ter feito toda a coleta dos dados, essas

informações coletadas foram processadas e originaram um novo modelo com

processos mais integrados e que agregam maior valor ao negócio.

Com a utilização de conceitos SOA o novo modelo integra os principais

sistemas utilizados pelos analistas do Service Desk (RCMS, RETAIN, PIMS) em um

único Frontend. Além da integração foi verificado que alguns clientes registravam

um alto número de ocorrências diárias, então 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 ligações no

Service Desk.

Os técnicos precisavam ligar na URA do Service Desk para atualizar os

chamados, agora utilizam uma aplicação desenvolvida em Java pelo PDA que

conversa com o sistema RCMS via Web Services. Os técnicos só necessitam ligar

na URA do Service Desk em casos específicos como: a bateria do PDA acabou,

precisam falar com especialista de plataforma de plantão para autorização de pedido

de peça em emergência máxima para o término do atendimento.

DESCRIÇÃO DO PROCESSO DE NEGÓCIO (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 necessários para abertura do chamado para Hardware:

• Tipo e série do equipamento; • Nome da empresa; • Endereço; • Telefone; • Pessoa de contato; • Problema.

*Caso o cliente informe tipo e série do equipamento incorretamente, chamado será direcionado para uma fila de inventário, 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 técnico de plantão.

Para Software:

• Código de Cliente; • Produto;

Page 98: Monografia bpm

98

• Sistema Operacional; • Tipo e série do equipamento (se necessário); • Pessoa de contato; • Telefone; • Problema.

*Caso cliente não possua contrato, o mesmo estará sujeito a ser faturado, se quiser ter atendimento. **Chamados que não tenham contrato precisam ser liberados pelo Gerente Onduty de plantão. 3 - Feito isso caso haja necessidade Call Dispatch direciona chamado para o 2º nível de atendimento. 4 - Caso Cliente já possua chamado em aberto, Call Dispatch direciona chamado para departamento responsável. 5 - Caso seja chamado de Software cliente é direcionado para Departamento CAC ADM ou fora do horário comercial para gerente onduty e o mesmo decide se chamado será atendido ou não. 6 - Analista de software faz atualizações no chamado e descreve todas as ações que foram tomadas por ele para solução do problema, chamado pode ser finalizado ou continuar em aberto caso ainda não tenha sido solucionado. 7 - Caso Seja chamado de Hardware o mesmo é direcionado aos técnicos de plantão. 8 - Técnico atualiza o chamado e informa quais medidas foram tomadas para solução do problema, chamado pode ser finalizado ou continuar em aberto caso ainda não tenha sido solucionado. 9 - Clientes que possuem Link Direto com a empresa, os próprios equipamentos abrem chamados diretamente no sistema, quando apresentam algum problema, se chamado for para hardware é repassado para o técnico via PDA, se for de software os analistas de Software monitoram filas de atendimento e entram em contato com cliente. 10 - Se as Informações providas pelo cliente sejam incorretas, chamado poderá ser cancelado pelo analista de software ou técnico. 11 - Clientes que abrem chamado no Portal Web têm acesso ao sistema da empresa com senha e login, chamado é repassado para o técnico via PDA, no caso de analistas de Software, os mesmos monitoram filas de atendimento e entram em contato com cliente. *Caso o cliente não receba nenhum contato do técnico ou analista de Software, ele liga no Call Dispatch para cobrar uma posição do chamado. 12 - Se as Informações providas pelo cliente estiverem incorretas, chamado é cancelado pelo analista de software ou técnico. 13 - Fim do Processo de atendimento ao cliente. 14 - Técnicos/Especialistas Solicitam pedido de peça para término da manutenção, o mesmo fornece seus dados como matrícula e um código de segurança que é diferente para cada território, número da peça, quantidade e a emergência. Pedido da peça é solicitado no sistema e Estoque envia pela transportadora. 15 - Caso alguns dos dados esteja incorreto pedido não poderá ser consumido pelo estoque. 16 - Técnico Utiliza PDA por onde recebem os chamados, pelo PDA conseguem acesso ao sistema RCMS e podem fazer algumas atualizações nos chamados. *Algumas atualizações só podem ser feitas pelo Call Dispatch. 17 - Fim do Processo de Atendimento a técnicos.

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

Page 99: Monografia bpm

99

A figura 31 ilustra a modelagem no estado futuro (To Be), que demonstra o

processo de atendimento. Este fluxo apresenta as informações 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 técnicos podemos ver que algumas das atividades também

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

horário assim que o técnico ler a mensagem.

Page 100: Monografia bpm

100

Figura 31 – Processo modelado (To Be).

Fonte: do autor.

Page 101: Monografia bpm

101

4.4 Resultados obtidos

A partir da implantação do BPM, o departamento responsável 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 são executados corretamente.

Também foi possível identificar os processos que estão integrados e a comunicação

entre eles e a necessidade de remodelar alguns processos.

Identificou-se a maior confiabilidade das informações geradas, as informações

são mais confiáveis devido ao maior controle e automação, proporcionada pelas

ferramentas de gestão de processos.

O conhecimento sobre os processos tornou-se mais consistente, as

informações são extraídas em tempo real, facilitando a análise de todos os aspectos

do processo. O controle das informações disponibiliza dados mais atualizados, além

de manter uma base com o histórico das operações de negócios realizadas. Outro

aspecto identificado foi à rápida adaptação dos processos as novas condições de

negócios, pois esses são controlados e monitorados de maneira mais efetiva.

Através do uso de sistemas BAM, o monitoramento dos processos provê

informações estatísticas e analíticas sobre condições especiais definidas pelos

executivos do negócio, essas condições 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 horários de maior pico de ligações, quais tipos de skills eram

mais exigidos em determinados horários, e a gerência com base nessas

informações traçou uma estratégia para baixar a volumetria de ligações, cumprir o

SLA e aumentar o grau de satisfação dos clientes com o serviço prestado.

Começando com mudanças internas, a gerência realocou os analistas nos

horários de pico, foi criado um portal via Web para os clientes que mais abriam

chamados no departamento, os técnicos que antes precisavam ligar para a URA do

Page 102: Monografia bpm

102

Service Desk, agora acessam o sistema RCMS via internet (Web Services) com os

PDA´s. A figura 32 mostra a tela de um PDA executando o programa para visualizar

os chamados.

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

Fonte: do autor.

Com essas medidas a organização ultrapassou a meta de SLA prevista em

contrato, havendo uma satisfação de mais de 90% de seus clientes. Houve também

uma economia de cerca de 40% com gastos em telefonia e a volumetria de ligações

que antes era de 55 mil caiu para 35 mil ligações mensais.

Page 103: Monografia bpm

103

Fatores de Comparação Antes do BPM Com BPM

Total de ligações mensais 55 mil 35 mil

Cumprimento de SLA 60% 90% - 95%

Satisfação dos clientes 55% 93%

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

A figura 33 mostra a arquitetura tecnológica e suas aplicações após a

implantação do BPM no Service Desk:

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

Fonte: do autor.

Page 104: Monografia bpm

104

A arquitetura tecnológica da empresa é muito bem estruturada como se pode

observar na figura 33, o mainframe IBM modelo z990 roda as aplicações que

precisam de maior carga de processamento, no caso os principais sistemas da

empresa, já as outras aplicações como o DB2 e o sistema de mensagens rodam em

servidores RISC que trocam informações com o mainframe, dessa forma todas as

informações são 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 peça para término do atendimento ou até mesmo

saber por qual motivo o seu chamado encontra-se pendente, pode-se ainda

adicionar informações e registrar reclamações.

Page 105: Monografia bpm

105

5. CONSIDERAÇÕES FINAIS

Este trabalho demonstrou por meio de um estudo bibliográfico o potencial que

o BPM possui em termos de agregação de valor aos negócios e que vem sendo

muito utilizado como um recurso estratégico em muitas organizações para elevar o

potencial competitivo.

Apesar das significativas contribuições do BPM, o sucesso da TI e do negócio

em se alinharem em busca de uma empresa mais moderna e competitiva não

depende apenas de ferramentas, tecnologias ou metodologias, isto também está

relacionado ao sistema da organização, porque quanto mais complexo, amplo e

tendente a mudanças 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 possuírem um

conhecimento especial (como utilização de melhores práticas, 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 também foi apresentada uma gestão de processos de negócio

que integra a modelagem de processos de negócio e a criação de serviços, através

de uma arquitetura orientada a serviços. Neste caso, esses serviços em SOA devem

ser gerenciáveis para que possam ser controlados por um sistema externo de

gerência de processos de negócio. Nesse ponto, o SOA se propõe como solução de

TI para o BPM.

A partir da pesquisa realizada, nota-se que alguns mecanismos facilitam a

integração entre as notações BPMN e BPEL. Isto permite, por exemplo, o

reaproveitamento dos modelos desenvolvidos anteriormente na plataforma de uma

empresa que utiliza Web Services para a comunicação entre os seus sistemas e

clientes, por meio da aplicação da orquestração de serviços, distribuídos em

camadas dentro da Arquitetura Orientada a Serviço a fim de aumentar a

reusabilidade, interoperabilidade e flexibilidade de seus sistemas.

Page 106: Monografia bpm

106

A gestão de processo torna possível a aproximação da área de TI com a área

de negócios, de modo a permitir não somente a comunicação entre eles, mas

também que esses interajam de forma mais efetiva disponibilizando uma visão

abrangente dos processos da organização.

No estudo de caso, foi realizado um modelo para representação de um

processo de negócio de uma organização que atua no mercado de Outsourcing e

prestação de serviços, através de uma metodologia de modelagem de estado atual

(As Is) pôde-se observar que essa modelagem proporcionou uma visão que serviu

de base, para treinamento, discussão entre equipes e setores correlacionados sobre

as atividades realizadas, padronização e melhorias dos processos, como também

criar metas e controles de melhorias e eliminar retrabalho, burocracia e custos

desnecessários, possibilitando desta forma dar apoio efetivo à implementação de

sistemas de gerenciamento, melhorando a comunicação entre equipe de Tecnologia

e Informação e não-especialistas. Após toda esta discussão entre os departamentos

correlacionados, as equipes e o time de TI construíram um modelo de estado Futuro

(To Be), sendo este implementado na organização.

Page 107: Monografia bpm

107

REFERÊNCIAS

AALST, W. M. P. Van Der. Business process management: a survey. In: CONFERÊNCIA 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. Dissertação (Ciência da Computação) - Instituto de Ciências da Computação, Universidade de Zurique, Zurique, 2006. ANDRADE, A. Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6., 2004, São Paulo. Anais... São Paulo: SIMPROS, 2004. BALDAM, R. Gerenciamento de processos de negócios. BPM – Business Process Management. 2. ed. São Paulo: Érica, 2008. 240 p. BENEDETE, A. C. Roteiro para a definição de uma arquitetura SOA utilizando BPM. 2007. 68f. Monografia (MBA) - Escola Politécnica, Universidade de São Paulo, São Paulo, 2007. Business Process Modeling Notation – BPMN. Disponível em <http://www.omg.org/spec/BPMN/1.2>. Acesso em: Setembro. 2009. Business Process Modeling Notation – BPMN. Disponível em <http://www.omg.org/spec/BPMN/2.0>. Acesso em: Setembro. 2009. CHRISTENSEN, E. Web Services Description Language (WSDL). 2001. Disponível em: <http://www.w3.org/TR/2001/NOTE-wsdl-20010315>. Acesso em 8 de maio 2008. CUBILLOS, J. A. Composición Semántica de Servicios Web. Grupo de Engenharia Telemática, Universidade de Cauca, Colômbia, 2004. CUMMINS, F. A. Integração de sistemas. EAI – Enterprise Application Integration. Arquitetura para integração de sistemas e aplicações 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 Serviços. 1ª Ed. Pearson/Prentice Hall Brasil, 2009. FANTINATO, M; TOLEDO, M. B. F. de; GIMENES, I. M. S. Web Service E-contract

Page 108: Monografia bpm

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: SIMPÓSIO 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-SOSWE´07, 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 aplicação de Sistemas de Gestão de Processos de Negócio em diferentes modelos de desenvolvimento de Software. 2007. 99f. Trabalho de conclusão de curso – Universidade Federal de Santa Catarina, Florianópolis, 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. LEITÃO, G. M. MARGALHO JUNIOR, N. A. B. Comparação de ferramentas para implementação de Web Services. 2007. 89f. Monografia (Graduação) - Universidade da Amazônia – UNAMA Centro de ciências exatas e tecnologia – CCES Curso de Bacharelado em Ciência da computação na área de engenharia de software, Belém, 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 histórias a processos: utilização da técnica de Group Storytelling para apoio à elicitação de processos de negócios. MIRANDA, P. A. P. SOA – Arquitetura orientada a serviços. 2008. 94f. Monografia (Graduação) - Universidade da Amazônia – UNAMA Centro de ciências exatas e tecnologia – CCET Curso de Bacharelado em Ciência da computação, Belém, 2008.

Page 109: Monografia bpm

109

MOREIRA, Leo S. Aplicando Composição e Orquestração de Serviços na Organização de Sistemas. 2007. 68f. Monografia (Graduação) – Gerência Educacional de Tecnologia da Informação, Centro Federal de Educação Tecnológica do Rio Grande do Norte, Natal, 2007. OASIS (2007). Web Services Business Process Execution Language Version 2.0. Disponível em <http://docs.oasis-open.org/wsbpel-v2.0.pdf>. Acesso em: Agosto. 2009. OBJECT MANAGEMENT GROUP - OMG. Disponível em <http://www.omg.org/>. Acesso em: Maio. 2009. OLIVEIRA, F. M. Aplicação do Business Process Management (BPM) nas Organizações. 2008. 100f. Trabalho de conclusão de curso (tecnólogo) Faculdade de tecnologia da zona leste, São Paulo, 2008. PAK, A. F. M. Ferramentas para a Gestão de Mudanças do Modelo ITIL Aplicado a Uma Empresa de Telecomunicações. 2006. 128p. Monografia (Graduação) –Universidade de Brasília, Brasília, 2006. PUNTAR, S; LENDRIKE, H; MAGDALENO, A; BAIÃO, F; SANTORO, F. Estudo Conceitual sobre BPMS. 2009. 19f. Relatórios técnicos do departamento de informática aplicada da UNIRIO – Universidade Federal do estado do Rio de Janeiro Centro de Ciências Exatas e tecnologia. Rio de Janeiro, 2009. REIS, G. Introdução ao BPMN. Revista Portal BPMN, São 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 são BPMS: Sistemas de Suporte às tarefas para a gestão de processos. In: XXVII Encontro Nacional de Engenharia de Produção, ABEPRO, Foz do Iguaçu, PR, 2007 SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003. SOUZA, A. C. R. A importância do business process management (BPM) nas empresas de software. 2008. 90f. Trabalho de conclusão de curso (tecnólogo) Faculdade de tecnologia da zona leste, São Paulo, 2008. WORLD WIDE WEB CONSORTIUM – W3C Escritório Brasil. Disponível 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.

Page 110: Monografia bpm

110

GLOSSÁRIO

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 práticas a partir de um estudo de como outras organizações desempenham essas mesmas operações.

Business Activity Monitoring - Ferramentas de monitoramento em tempo real das operações de uma organização e de seus impactos sobre os resultados do negócios. Business Intelligence - Utilização de uma série de ferramentas para coletar, analisar e extrair informações, que serão utilizadas no auxilio ao processo de gestão e tomada de decisão. Business Process Management Initiative - Órgão que padroniza a gestão de processos de negócios. Business Process Management System – Ambiente integrado de componentes de software que automatizam o ciclo de vida de processos de negócios, desde a sua concepção e modelagem inicial, passando pela execução e monitoramento, até à incorporação de melhorias, inclusive com a possibilidade de simulação. Business Process Modeling Notation - Provê às empresas a capacidade de compreender os seus processos internos em uma notação gráfica e habilita a comunicação desses procedimentos de uma forma padrão. Drag-and-drop – Conceito de clicar e arrastar, recurso utilizado nas ferramentas gráficas. Dashboard - Representa uma janela da interface de operação contendo um painel de controle com os principais indicadores de desempenho dos processos gerenciados. Fast Analysis Solution Technique - É uma ferramenta de melhoria de processos lançada pela IBM e postriormente aperfeiçoada por outras corporações e empresas de consultoria. Joint Application Development - Técnica de levantamento de dados que traz os usuários para o desenvolvimento do processo como participantes ativos. Key Performance Indicators – Sua finalidade é medir qualquer etapa de um processo ou resultado, não estão limitados apenas às conhecidas métricas financeiras, a comparação dos indicadores pode apontar o caminho para a conclusão dos objetivos estratégicos da empresa.

Page 111: Monografia bpm

111

Service Level Agreement – Contrato onde é feito um acordo de nível de serviço entre um fornecedor de serviços de TI e um cliente especificando, em geral em termos mensuráveis, quais serviços o fornecedor irá prestar. Unidade de Resposta Audível - Aparelho utilizado por empresas de Call Center (atendimento) para que possam ser digitadas opções no atendimento eletrônico, a URA é um microcomputador convencional, ao qual se agrega um hardware específico para realizar as tarefas de telefonia (tais como atender, discar, desligar, reconhecer dígitos, falar, etc), e um software que controle este hardware de forma a atender a objetivos específicos. World Wide Web - Desenvolve tecnologias interoperáveis (especificações, manuais, software e ferramentas) para levar a utilização da rede mundial da Internet ao seu potencial pleno (www.w3c.br). Visita in-loco - Palavra que vem do latim que significa “no lugar”. Investigação realizada no local da pesquisa.