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
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
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.
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.
DEDICATÓRIA
A Deus, aos meus pais, minha
namorada e aos meus amigos...
companheiros de todas as horas...
AGRADECIMENTOS
À minha família e namorada pelo apoio e incentivo a esta jornada.
Aos meus amigos, pela força e pela vibração em relação a esta jornada.
Ao Prof. Msc. Orientador Wilson Vendramel, pela sua valorosa orientação e um dos
grandes responsáveis pelo desenvolvimento e finalização deste trabalho.
Aos meus colegas de trabalho pela colaboração e incentivo.
Aos colegas de curso, pela batalha a qual vencemos.
Aos que colaboraram e não impediram a finalização deste estudo.
“Cabe ao ser humano dedicar o máximo de si em tudo o que fizer, nas circuntâncias em que se encontra, neste exato momento, deve empenhar-se de corpo e alma com total seriedade sem se deixar influenciar pelos ventos do elogio ou da censura..."
Daisaku Ikeda
INAZAWA, Rafael Rayato. A Aplicação do BPM para automação de Processos de Negócio nas Organizações – Estudo de Caso: PROJETO NEW_RCMS. 2009. 111 f. Trabalho de Conclusão de Curso (Tecnólogo) – Faculdade de Tecnologia da Zona Leste, São Paulo, SP.
RESUMO
As organizações em um mercado cada vez mais competitivo são constantemente desafiadas a produzirem melhores resultados com menor custo, desenvolverem produtos e serviços baseados em um ciclo de vida mais curto e se relacionarem de forma mais personalizada e integrada com seus clientes, fornecedores e parceiros. As organizações devem ser capazes de melhorar seus processos de negócio e sua comunicação com a área de TI, da qual dependem para viabilizar seus objetivos e estratégias, atualmente buscam melhorar seus processos de negócio e alinhá-los junto com a TI, essa sinergia torna os processos das empresas flexíveis e resilientes frente a um novo tipo de mercado global. É necessária a aplicação de modelos de gestão nas áreas estratégicas da empresa para que se tornem possíveis a representação do ambiente de negócio e o uso de uma arquitetura flexível, dinâmica e adaptável (SOA – Service-Oriented Architecture) possibilitam uma visão sistêmica de toda a organização. Desta maneira, este trabalho foca analisar a implantação do BPM (Business Process Management) nas corporações. Palavras-chave: Arquitetura Orientada a Serviços, Processo de Negócio, BPM.
INAZAWA, Rafael Rayato. The Implementation of BPM for process automation in Business Organizations – Case Study: PROJECT NEW_RCMS. Conclusion Course (Technologist) – Faculdade de Tecnologia da Zona Leste, São Paulo, SP.
ABSTRACT The organization in a market increasingly competitive environment are constantly challenged to produce better results at lower costs, develop products and services based on a life cycle shorter and relate in a more customized and integrated with its customers, suppliers and partners. Organizations must be able to improve their business processes and their communication with the IT area, upon which to put its objectives and strategies currently seeking to improve their business processes and align them with IT, this synergy makes business processes flexible and resilient in the face of a new kind of global market. It is necessary to apply management models in the strategic areas of the company to become possible to represent the business environment and the use of a flexible, dynamic and adaptable (SOA - Service-Oriented Architecture) provide a systemic view of the entire organization . Thus, this work focuses on analyzing the deployment of BPM (Business Process Management) in corporations. Key-Words: Service-Oriented Architecture, business process, BPM.
LISTA DE ABREVIATURAS
BAM Business Activity Monitoring
BI Business Intelligence
BPD Business Process Diagram
BPEL Business Process Execution Language
BPM Business Process Management
BPMI Business Process Management Initiative
BPMN Business Process Modeling Notation
BPMS Business Process Management Systems
BPR Business Process Reengineering
BSC Balanced Scorecard
FAST Fast Analysis Solution Technique
KPI Key Performance Indicators
OASIS Organization for the Advancement of Structured
Information Standards
PMI Project Management Institute
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
SWOT Strengths, Weakness, Opportunities and Threats
TI Tecnologia da Informação
UDDI Universal Description, Discovery and Integration
WfMC Workflow Management Coalition
WfMSs Workflow Management Systems
WS Web Service
WS-BPEL Web Service Business Process Execution Language
WSDL Web Services Definition Language
WSFL Web Service Flow Language
XML eXtensible Markup Language
LISTA DE FIGURAS
Figura 1 – Ilustração de um processo de negócio...........................................................24 Figura 2 – Visão Sistêmica dos Processos.....................................................................25 Figura 3 – Ciclo de BPM..................................................................................................28 Figura 4 – Exemplo de Visão Global de Processos de compra......................................32 Figura 5 - Monitoração de Processos de Negócio com o Websphere Business MQ......41 Figura 6 – Analisando os KPIs (Indicadores Chave de Desempenho)...........................42 Figura 7 – Visualização gráfica dos indicadores.............................................................43 Figura 8 – Exemplo de relatório analítico........................................................................44 Figura 9 – Automação do ciclo de vida de processo de negócios..................................47 Figura 10 – Demonstração das Atividades e Decisões...................................................48 Figura 11 – Componentes da arquitetura SOA...............................................................58 Figura 12 – Exemplo de Aplicação Frontend..................................................................59 Figura 13 – Composição de um Serviço na Arquitetura SOA.........................................60 Figura 14 – Composição de Serviços..............................................................................65 Figura 15 – Orquestração e Coreografia.........................................................................67 Figura 16 – Exemplo de processo de orquestração de serviços.....................................69 Figura 17 – Exemplo de Coreografia de serviços...........................................................69 Figura 18 – Fluxo de Processo BPEL.............................................................................71 Figura 19 – Estrutura básica de uma especificação BPEL.............................................73 Figura 20 – Interface Gráfica modelada pelo BPEL através da ferramenta Eclipse.......75 Figura 21 – Camadas de Abstração de SOA..................................................................76
Figura 22 – O negócio e os domínios da lógica da aplicação.........................................77 Figura 23 – As três principais camadas de serviços.......................................................78 Figura 24 – Serviços utilitários da camada de serviço de aplicação...............................79 Figura 25 – Serviço ServicoSalvarGrupo nas camadas de Aplicação e Negócios.........81 Figura 26 – Ciclos de Vida de SOA.................................................................................83 Figura 27 – Atividades do ciclo de vida com os serviços no ambiente SOA...................86 Figura 28 – Arquitetura Web Services.............................................................................89 Figura 29 – Arquitetura de todos os sistemas do departamento.....................................93 Figura 30 – Processo modelado (As Is)..........................................................................96 Figura 31 – Processo modelado (To Be).......................................................................100 Figura 32 – Interface da aplicação no PDA...................................................................102 Figura 33 – Arquitetura tecnológica e suas aplicações após a implantação do BPM...103
LISTA DE QUADROS
Quadro 1 – Atividades básicas de BPEL.........................................................................72
Quadro 2 – Atividades Estruturadas de BPEL................................................................72
Quadro 3 – Processo de atendimento (As Is).................................................................94 Quadro 4 – Processo de atendimento (To Be)................................................................98 Quadro 5 – Comparativo entre antes e depois da implantação do BPM......................103
LISTA DE TABELAS
Tabela 1 – Objetos de Fluxo...........................................................................................50
Tabela 2 – Objetos de Conexão......................................................................................51
Tabela 3 – Raias (Swimlanes).........................................................................................52
Tabela 4 – Artefatos........................................................................................................53
Tabela 5 – Principais Características da Arquitetura SOA..............................................57
Tabela 6 – Características da Concepção de Serviços...................................................61
Tabela 7 - Fases do Ciclo de Vida do Serviço................................................................63
Tabela 8 – Características do Barramento de Serviços..................................................64
Tabela 9 – Principais sistemas do Service Desk.............................................................92
SUMÁRIO
1. INTRODUÇÃO............................................................................................................19
2. GESTÃO DE PROCESSOS DE NEGÓCIO................................................................22
2.1 Processos de negócio..........................................................................................23
2.1.1 Fluxo de Trabalho de Pessoas..........................................................................25
2.1.2 Características de Processos nas Organizações..............................................26
2.2 Ciclo do Gerenciamento de Processo de Negócio...............................................27
2.2.1 Planejamento do BPM.......................................................................................29
2.2.1.1. Visão Global de Processos............................................................................31
2.2.2 Modelagem de processos..................................................................................32
2.2.2.1 Modelagem de estado atual (As Is)................................................................34
2.2.2.2 Modelagem de estado futuro (To Be).............................................................36
2.2.2.3 Ferramenta e metodologia de modelagem do processo de negócio..............38
2.2.2.4 Otimização de Processos e Solução Imediata de Problemas........................38
2.2.3 Execução de Processos.....................................................................................39
2.2.4 Controle e Análise de Dados.............................................................................40
2.3 Conformidades......................................................................................................44
2.4 Sistemas de Gestão de Processos de Negócio (BPMS)......................................45
2.4.1 Ciclo de Vida de BPMS......................................................................................46
2.5 BPMN e os elementos de BPD.............................................................................48
2.5.1 Objetos de Fluxo (Flow Objects)........................................................................49
2.5.2 Objetos de Conexão..........................................................................................51
2.5.3 Raias (Swimlanes).............................................................................................52
2.5.4 Artefatos.............................................................................................................53
3. ARQUITETURA ORIENTADA A SERVIÇOS..............................................................54
3.1 Características da Arquitetura Orientada a Serviços............................................56
3.2 Componentes SOA...............................................................................................58
3.2.1 Aplicação Frontend............................................................................................59
3.2.2 Serviços.............................................................................................................60
3.2.3 Ciclo de vida dos serviços..................................................................................62
3.2.4 Repositório de serviços......................................................................................63
3.2.5 Barramento de serviços.....................................................................................64
3.3 Composição de serviços.......................................................................................65
3.3.1 Orquestração.....................................................................................................67
3.3.2 Coreografia........................................................................................................68
3.3.3 BPEL..................................................................................................................70
3.4 Camadas de abstração.........................................................................................75
3.4.1 Camada corporativa...........................................................................................76
3.4.2 Camada de processos.......................................................................................76
3.4.3 Camada de serviços..........................................................................................77
3.4.3.1 Camada de serviço de aplicação....................................................................78
3.4.3.2 Camada de serviços de negócio.....................................................................80
3.4.3.3 Camada de serviço de orquestração..............................................................82
3.4.4 Camada de Componentes.................................................................................82
3.4.5 Camada de Objetos...........................................................................................82
3.5 Ciclo de vida SOA.................................................................................................83
3.5.1 Estratégia...........................................................................................................84
3.5.1.1 Bottom-up........................................................................................................84
3.5.1.2 Top-down……………………………………………………………………………85
3.5.2 Modelagem…………………………………………………………………………....85
3.5.3 Implementação……………………………………………………………………….86
3.5.4 Monitoramento (Business Activity Monitoring)...................................................86
3.6 Web Services........................................................................................................87
4. ESTUDO DE CASO....................................................................................................89
4.1 Descrição do ambiente de pesquisa.....................................................................89
4.2 Implantação do BPM na organização...................................................................89
4.3 Modelagem do processo de negócio de Atendimento de chamados...................91
4.4 Resultados obtidos..............................................................................................101
5. CONSIDERAÇÕES FINAIS......................................................................................105
REFERÊNCIAS.............................................................................................................107
GLOSSÁRIO.................................................................................................................110
19
1. INTRODUÇÃO
Melhoria Contínua é um termo bem conhecido para as organizações que
desejam se manter competitivas no mercado. Hoje com a disposição dos mais
variados modelos, métodos e processos de Gestão, algumas têm conseguido
alcançar os principais objetivos que são: manter crescimento, reduzir gastos e
aumentar lucros.
As organizações que conseguem alcançar suas metas e objetivos em geral
são as que possuem processos internos e externos bem definidos, estão sempre em
constante mudança organizacional e se adaptam rapidamente a elas, geralmente
possuem uma ótima infra-estrutura de TI alinhada ao seu processo de negócio, isso
as tornam empresas flexíveis.
A maior dificuldade das empresas é alinhar os seus processos de negócio a
TI, criar uma solução tecnológica adequada que agregue valor ao seu negócio
possibilita a empresa ter uma forte flexibilidade e interoperabilidade para
acompanhar as constantes mudanças de processos e informações.
A aplicação do Business Process Management (BPM) permite mapear os
processos organizacionais da empresa, buscando a integração funcional e
proporcionando maior agilidade nas atividades que envolvem pessoas, tarefas,
máquinas, aplicações de software e outros elementos coordenados para atingir os
objetivos do negócio. Com a utilização de notação de modelagem de processos
como Business Process Management Notation (BPMN), os analistas de negócio
podem documentar os modelos criados e entender melhor os processos da empresa
em diferentes níveis, facilitando deste modo o entendimento dos participantes dos
processos de negócio.
Da necessidade de integração entre diferentes sistemas e a disseminação da
Web surge a Arquitetura Orientada a Serviços – SOA (Service-Oriented Architecture)
que veio com o objetivo de integrar serviços fracamente acoplados, possibilitando o
reuso, modificação e a aplicação em diferentes áreas internas ou externas da
empresa. Atrás de inovação, as empresas vêem cada vez mais demonstrando
20
interesse em Web Services, pois é uma tecnologia atual baseada na Web capaz de
integrar serviços utilizando tecnologia XML (eXtensible Markup Language). De certa
forma essa tecnologia pode sanar boa parte dos problemas de uma organização que
utiliza sistemas diferentes, fazendo com que eles troquem informações, com isso a
empresa pode integrar seus processos a esses sistemas independentes de
plataforma ou linguagem de programação.
Este trabalho tem como objetivo demonstrar os passos necessários para uma
organização implementar o BPM, por meio da modelagem de seus processos,
visando promover a flexibilidade, Interoperabilidade e a reusabilidade de
componentes na organização.
A Justificativa para o desenvolvimento deste trabalho é demonstrar que o
Business Process Management é de extrema importância para as organizações e
que suas contribuições agregam mais valor ao negócio tornando a empresa mais
competitiva no mercado.
A metodologia deste estudo será feita a partir de pesquisa bibliográfica e
também de um estudo de caso que apresenta a modelagem de um processo de
negócio, a fim de demonstrar as principais atividades e características da gestão de
processos de negócio por meio do BPM.
O estudo de caso consiste em analisar um determinado processo de um
serviço oferecido por uma organização, e a utilização de uma ferramenta de
modelagem de negócio (Bizagi Process Modeler), obtendo assim, a inserção,
desses processos no paradigma da orientação a serviços e gestão dos processos de
negócio.
O segundo capítulo aborda a gestão de processos de negócio, que é uma
disciplina de gestão estratégica, que sustenta a idéia de que podemos modelar um
negócio em termos de processos de sua finalidade que podem abranger tradicionais
organizações e fronteiras de sistemas. Ele envolve a descoberta, projeto e entrega
dos processos de negócio, fazendo com que todos os departamentos da
organização estejam alinhados com as metas e estratégias da corporação. Uma boa
gestão ainda permite um ciclo de melhoria contínua onde as organizações devem
estar aptas às constantes mudanças organizacionais em conjunto com a Tecnologia
da Informação para estarem melhor alinhadas com suas metas, estratégias e
21
objetivos.
O terceiro capítulo, aborda a arquitetura orientada a serviços que é uma
aproximação arquitetural para desenvolvimento de sistemas que constrói e distribui
serviços reutilizáveis e encapsulados prestados às empresas para que diferentes
aplicações possam compartilhá-los em um modo vagamente acoplado e altamente
inter-operável. A implementação desses serviços podem ser feitas independente da
plataforma ou linguagem de programação, utilizam protocolos padronizados para a
comunicação e troca de informações. Esses padrões tornam os serviços flexíveis e
reusáveis, podendo ser executados em computadores distribuídos geograficamente.
Essa arquitetura ainda permite a utilização de diversas outras tecnologias incluindo
os sistemas legados da organização, mantendo a interoperabilidade entre os
diversos sistemas da organização.
22
2. GESTÃO DE PROCESSOS DE NEGÓCIO
Segundo a BPMN (apud BALDAM et al., 2008, p.19), a gestão por processos
de negócios envolve a descoberta, projeto e entrega de processos de negócios.
Adicionalmente, o BPM inclui o controle executivo, administrativo e supervisório
desses processos.
A gestão por processos de negócios é a disciplina de modelar, automatizar,
gerenciar e otimizar processos de negócios através do seu ciclo de vida com o
propósito de lhes agregar valor (KHAN apud OLIVEIRA, 2008, p. 19),
O BPM tem vários predecessores como o Gerenciamento de Qualidade Total
(TQM, do inglês Total Quality Management) e de um novo paradigma que surgiu em
meados dos anos 90: Business Process Reengineering (BPR), que prometia
aumentar o desempenho dos negócios em um período relativamente curto pela
reengenharia completa dos processos de negócios existentes. O BPR teve um
grande sucesso inicial, mas o movimento teve um declínio que levou ao fracasso
vários projetos. O BPM surgia 10 anos mais tarde e trazia de volta a gestão por
processos de negócios com soluções que atendiam, através da evolução dos fluxos
de trabalho, a interoperabilidade de processos mais complexos e distribuídos
fisicamente.
Com a integração e aperfeiçoamento dos processos, de forma que as metas e
estratégias estejam alinhadas com a corporação, a gestão por processos pode
trazer eficiência e permitir vincular a atividade das diferentes funções internas aos
fatores competitivos da organização.
No entanto, se o processo como um todo não for corretamente analisado e
avaliado, as correntes funções tornam-se um grupo de pequenas unidades de
negócios isoladas, as quais são avaliadas indevidamente por padrões não
condizentes com as necessidades globais da empresa. O acontecimento mais
comum é o de o organograma receber uma maior atenção do que o próprio negócio.
O termo BPM, Business Process Management, é largamente utilizado pelos
autores para referenciar a automação dos processos, que uma vez passando por
23
esse processo de automatização, pode ser gerenciado posteriormente, por meio de
ferramentas de software.
Já no ambiente de negócios, os executivos se referem à gestão de processos
de negócios de uma forma mais genérica, com uma visão de gerenciamento
humano melhor organizado diante dos negócios da corporação.
2.1 Processos de negócio
Processo de Negócio é a descrição de um conjunto de atividades que
envolvem pessoas, tarefas, máquinas, softwares e outros elementos coordenados
para atingir objetivos de negócio.
“É um fenômeno que ocorre dentro das empresas. Compreende um conjunto de atividades realizadas na empresa, associadas às informações que manipula, utilizando os recursos e a organização da empresa. Forma uma unidade coesa e deve ser focalizado em um tipo de negócio, que normalmente está direcionado a um determinado mercado/cliente, com fornecedores bem definidos (Rozenfeld apud Baldam, et al.,2008, p.196).”
Segundo Moreira (2007, p. 30-31) um processo de negócio pode ser visto
como um conjunto estruturado de tarefas que contribuem coletivamente para que
uma organização atinja os seus objetivos. Os processos de negócio são a base
operativa de uma empresa e fazem parte da cultura desta e o êxito da mesma
depende fortemente da eficiência com que eles são administrados. Assim sendo,
uma má administração dos processos traz altos custos, baixa produtividade e
inadequados tempos de resposta, tanto frente às oportunidades como às ameaças.
A figura 01 exemplifica um processo de negócio.
24
Figura 1 – Ilustração de um processo de negócio.
Fonte: GARCIA e TOLEDO (2007).
A Figura 2 mostra o esquema geral de funcionamento de processos nas
organizações, ela demonstra o que está diretamente envolvido em um processo em
particular (entradas, saídas, recurso e controles), inclusive as influências externas
oriundas do contexto da organização, que podem alterar o modo de funcionamento
do processo até mesmo os produtos produzidos pelo processo (BALDAM et al,
2008, p.21).
25
Figura 2 – Visão Sistêmica dos Processos.
Fonte: BALDAM (2008. p.21).
2.1.1 Fluxo de trabalho de pessoas
Quando as atividades do processo exigem ações ou pareceres de pessoas,
normalmente categoriza-se o processo como de “longa duração”, pois o elemento
humano pode demorar em completar a tarefa. Para os mecanismos de BPM darem
suporte a interação humana, não só devem armazenar e controlar estes processos
de longa duração, mas também prover funcionalidades como:
• Identificação do responsável pela tarefa: Normalmente, quando se
desenha um processo, assinala-se um papel (uma função como
gerente de agência, analista de crédito) às tarefas, ao invés de uma
26
identificação direta da pessoa (como seria um código funcional). Isto é
importante para que os processos sejam independentes das pessoas,
as quais podem sair da empresa ou mudar de função, e também
porque para cada instância do processo o recurso (pessoa) pode ser
diferente. Os papéis podem ser definidos no momento de criação dos
fluxos, durante sua instalação no ambiente, ou mesmo durante sua
execução (KLOPPMANN apud BENEDETE, 2007, p. 31);
• Envio da tarefa para a pessoa responsável e apoio à interação: Depois
de identificado, o responsável pela tarefa tem que ser comunicado
criando itens em uma relação de tarefas que deve ser periodicamente
consultada pela pessoa. As ferramentas de BPM não só avisam o
responsável pela tarefa, mas também fornecem telas onde o contexto
(informações necessárias para entender, executar uma tarefa ou tomar
uma decisão) da atividade é apresentado;
• Tratamento de exceções: Caso uma pessoa demore muito para realizar
uma tarefa, ou caso fique ausente, os mecanismos de fluxo de trabalho
devem ser capazes de encontrar um substituto ou escalar o assunto
para um supervisor tomar a ação necessária.
2.1.2 Características dos processos nas organizações
Segundo Baldam (2008, p. 24), à medida que a visão de processos se
difunde, as formas contemporâneas de racionalização tendem a ver as organizações
como um feixe de processos, e ele classifica esses feixes de processos da seguinte
maneira:
• Transfuncionais: pois atravessam departamentos;
27
• Intrafuncionais: pois pertencem a um departamento ou setor
específico.
Conhecendo a visão do processo, é possível definir o que deve ser feito e
como fazê-lo, não em cima das atividades dos departamentos, mas sim, atividades
que agregam valor a organização independente do departamento que executará o
processo. Deste modo, os processos tramitariam entre departamentos conforme o
serviço que ele necessitar realizar (BALDAM et al., 2008, p. 24).
Porém, com estas características de processos, os departamentos ainda
seriam úteis nas organizações, devido a sua funcionalidade em situações gerenciais.
2.2 Ciclo de Gerenciamento de Processo de Negócio
A descrição das etapas do ciclo de gerenciamento de negócios, segundo
Baldam (2008, p. 56), podem ser aplicadas em um processo específico da
organização ou em processos de negócios onde existe uma gestão da integração
destes já presente, podendo ser utilizada também em um estado de gestão que se
pretende chegar futuramente. A figura 3 ilustra o ciclo do BPM.
28
Figura 3 – Ciclo de BPM
Fonte: BALDAM (2008, p.56)
• Planejamento do BPM: É onde as atividades de BPM que contribuirão
para o alcance de metas organizacionais (desde as estratégicas até
as operacionais) serão definidas, como verificação dos pontos de
falha nos processos que causam danos a organização (financeiros,
imagem, prazos e satisfação de clientes), definição de planos de ação
para implantação, definição dos processos que necessitam de ação
imediata;
• Modelagem e otimização de processos: atividades que permitem
gerar informações sobre o processo atual (As Is) e/ou sobre a
proposta de processo futuro (To Be); documentar os processos;
prover dados de integração entre processos, empregar metodologias
para aperfeiçoar os processos, fazer inovações, simulações e
29
redesenhos; adotar as melhores práticas de modelos de referência;
gerar especificações para implementação, para configuração e
customização (caso o processo não esteja em uso), para execução e
controle;
• Execução de processos: atividades que garantirão a implementação e
a execução dos processos, como implantação de planos de
transferência de tecnologia, treinamentos, ajuste de equipamentos e
softwares (se necessários), acompanhamento de processo
implantado, monitoria e controle da execução das instâncias de
processo;
• Controle e análise de dados: atividades relacionadas ao controle geral
do processo (por meio de diversos recursos, como o uso de
indicadores, BAM, BI, BSC, métodos estatísticos, diagramas de causa
e efeito), gerando informações que posteriormente realimentarão as
atividades de otimização e planejamento.
2.2.1 Planejamento do BPM
As atividades desempenhadas na etapa de planejamento do BPM são
descritas por Baldam (2008, p. 63):
• Definir os processos-chave para a estratégia da organização. Usando
metodologias conhecidas (Cadeia de Valor, BSC, SWOT), é possível
identificar em quais processos a organização tem mais
potencialidade, os pontos que precisam melhorar, quais as ameaças
e oportunidades do mercado, os indicadores que serão usados para
medir o desempenho de seus processos, a meta para esses
indicadores, entre outros;
30
• Levantar os principais pontos fracos dos processos em uso na
organização;
• Identificar as oportunidades (novas abordagens, produtos ou serviços)
que possam ser fornecidas pela organização, levando a preparar os
processos que permitirão sua entrega;
• Perceber que todos os processos podem passar por inovação;
• Preparar, no todo ou em parte, a visão global de processos;
• Classificar os processos que mereçam atenção em ordem de
prioridade;
• Identificar ao time de projetos de processos e às áreas envolvidas as
diretrizes e especificações básicas desejadas a partir do
planejamento;
• Planejar e controlar as tarefas necessárias à implementação.
Os gestores de processo não são os únicos responsáveis pelas atividades do
planejamento. É importante a participação de gestores de outras áreas da
organização, o apoio desses gestores e o seu comprometimento com o BPM de
forma contínua contribuem para o êxito na gestão por processos, caso isso não
ocorra, surgirão processos isolados sem uma visão global dos processos. No
momento da implantação, é fundamental a participação efetiva do gestor da
organização, a fim de evitar possíveis barreiras e desentendimentos, entre os
funcionários dos diversos setores e áreas envolvidas.
De acordo com Baldam (2008, p. 66) não são apenas os processos que
apresentam problemas (qualidade, custo, prazo, etc.) que passarão por otimização,
outros processos que estejam funcionando perfeitamente podem ser otimizados
buscando inovação ou melhoria contínua desse processo.
31
Algumas atividades surgem de imediato e mesmo que a necessidade desse
processo não tenha sido detectada no planejamento estratégico, sua implantação
pode ser imediata.
2.2.1.1 Visão global de processos
Considerado um ponto de controvérsia que precede o BPM, segundo Baldam
(2008, p. 66), a Visão Global de Processos é fundamental numa Gestão Integrada
dos Processos sendo necessário considerar:
• Uma Visão Global dos Processos ajuda a compreensão do
funcionamento da empresa;
• Fazê-lo por completo é complexo e pode levar mais tempo que o
benefício direto e imediato por ele gerado;
• É relativamente fácil fazer o diagrama apenas em macro processo e
posicionar o processo que se deseja modelar de imediato;
• O diagrama pode ser efetivamente feito em etapas e melhorando na
medida em que é usado em projetos pontuais de BPM, alinhando
sempre os projetos ao diagrama macro;
• Para muitas das atividades realizadas, há referenciais que ajudam a
construir os diagramas próprios à organização.
32
Figura 4 – Exemplo de Visão Global de Processos de compra.
Fonte: Adaptado de BALDAM (2008, p.69).
2.2.2 Modelagem de processos
A modelagem de processos de negócio é uma das fases do ciclo de vida
SOA, ela é um conjunto de conceitos, modelos e técnicas com o objetivo de
desenvolver o modelo de negócio da organização. Este modelo é resultado de uma
abstração da organização, considerando as suas características essenciais, do
ponto de vista do negócio (CRUZ apud OLIVEIRA 2008, p. 36).
Nenhum modelo corresponde exatamente à realidade; todos apenas a representam, de um modo que parecerá mais adequado ou menos adequado, de acordo com o contexto, os atores e as finalidades da modelagem (VALLE apud BALDAM et al., 2008, p. 74).
Segundo Baldam (2008, p. 74), é possível utilizar os modelos de processos
de negócios para:
• Discutir e compreender os processos;
• Apoiar a melhoria contínua (análise da eficiência e da eficácia);
• Simular alternativas;
33
• Treinar os operadores dos novos processos;
• Especificar os sistemas de informação que deverão suportar o negócio.
Nesta fase o processo é modelado em termos de atividades, regras,
participantes, interações e relacionamentos. O processo é estruturado em
atividades, que podem ser mapeadas como tarefas que são executadas por pessoas
ou sistemas internos ou externos à corporação. É realizada a validação ou a
simulação dos processos, através do uso de estimativas de tempo de execução e
custo, recursos requeridos pelas atividades e a probabilidade de ocorrência de
eventos.
Essa fase também inclui a definição das métricas de desempenho do
processo para que o analista de negócio possa avaliar o processo implantado e,
possivelmente, reestruturá-lo em função de oportunidades ou de outros motivos
(NADER apud OLIVEIRA, 2008, p. 36).
Os modelos de processo são constituídos de diagramas de fluxo de trabalho e
de textos auxiliares de forma a descrever cada passo do processo de negócio.
Havey (apud SOUZA, 2006, p. 23), afirma que o modelo de processo deve
representar de forma simples e intuitiva o fluxograma de atividades do processo
modelado. A modelagem deve ser realizada em dois níveis: de forma gráfica, com o
auxílio de ferramenta de desenho de processos e com um modelo executável,
utilizado na automação desses processos através dos sistemas de gestão de fluxo
de trabalho.
Durante a descrição de um diagrama de negócio, os eventuais problemas
relacionados ao processo que ele representa são documentados e para cada um
são propostas possibilidades de melhorias. Os principais conceitos envolvidos, as
regras e os recursos utilizados ou produzidos por cada processo são identificados e
modelados como entidades de negócio.
34
2.2.2.1 Modelagem de estado atual (As Is)
Por meio desta modelagem é possível entender o processo existente na
organização e identificar suas falhas. Espera-se, desta forma, obter métricas
suficientes a fim de estabelecer uma base na fase seguinte da análise e
desempenho do processo atual, que permita identificar as melhorias proporcionadas
pelo estado futuro, assim como uma documentação dos prós e contras e do
desempenho do processo.
Na modelagem do estado atual do processo, vários tipos de interações entre
os envolvidos no processo podem existir, incluindo atividades de colaboração e
reuniões. Diversas técnicas podem ser utilizadas na modelagem de processos atual:
técnica de entrevistas, brainstorm, JAD, métodos simplificados de modelagem com
papel, entre outras.
Baldam (et al., 2008, p. 76-77) aponta como sendo relevante as seguintes
etapas para a modelagem do processo atual:
• Preparação do projeto de modelagem: envolve as diversas atividades
de compreensão de escopo (qual processo será modelado,
propósitos, métricas, verificar alinhamento estratégico, prazos e
entregáveis), composição da equipe envolvida, definição de
documentação necessária, planejamento das reuniões (pessoas
envolvidas, datas, agenda, infra-estrutura necessária à reunião),
consulta à documentação do processo, ou que rege o processo
previamente disponível (normas, leis, regulamentos e referências);
• Entrevista e coleta de dados com usuários (especialista de negócio e
facilitadores): podem incluir entrevistas (em aberto ou dirigidas),
criação conjunta da lista de esquema gráfico de atividades, descrição
de informações que comporão o processo e criação de atas de
reunião;
35
• Documentação do processo: será construído o modelo, conforme
metodologia previamente definida. Além dos componentes do
processo propriamente dito, outras informações serão necessárias,
como controle de versão de documentação, publicação, referências e
escopo. Nessa fase é comum o uso intensivo de software de apoio à
modelagem;
• Validade do processo: deve-se testar o modelo em uma instância real
do processo, para verificar se realmente está coerente. Em alguns
casos, a validação é impossível porque o tempo de processamento é
muito longo, ou porque exigiria um grande deslocamento, ou seu
custo seria alto demais. Por exemplo, um processo de compra por
licitação pública, quando envolve grandes somas, pode se
desenvolver por meses;
• Correção de documentação: são corrigidas eventuais distorções
percebidas durante a validação do processo.
Segundo Tachizawa e Scaico (apud Pak, 2006), uma análise do processo
atual deve verificar se os objetivos são atendidos, se as atividades estão bem
relacionadas, se os recursos alocados são suficientes e se as interfaces entre
gerências estão sendo previstas e administradas. Também é importante verificar a
consistência das tarefas utilizadas, evitando a redundância das mesmas.
Como Resultado da modelagem do estado atual JESTON & NELIS (apud
BALDAM et al., 2008, p. 77), espera-se obter:
• Modelo do processo atualmente em uso;
• Métricas apropriadas e suficientes para estabelecer uma base para
futuras medidas de melhorias de processos, priorização e seleção na
fase seguinte de análise do To Be;
36
• Métricas e documentação do atual desempenho do processo;
• Documentação do que trabalha bem e o que precisa funcionar melhor;
• Identificação dos itens mais significativos e de ganho rápido que podem
ser rapidamente implementados;
• Um relatório dessa fase.
2.2.2.2 Modelagem de estado futuro (To Be)
Nessa fase pretende-se criar um ambiente de discussão entre partes 40
envolvidas de forma a melhorar o processo em questão, inová-lo ou mesmo
questionar se ele se faz necessário e se agrega valor à organização (BALDAM et al.,
2008, p. 83). Entre as modelagens do estado futuro mais comuns podem ser citadas:
• Melhoria continua;
• FAST;
• Benchmarking;
• Adoção de melhores práticas e processos comodizados (transformá-
los em commodities);
• Redesenho de processo;
• Inovação de processo.
O objetivo dessa etapa é definir a decisão a ser tomada em relação aos
processos identificados durante a modelagem do estado atual e seu realinhamento
37
com os objetivos e estratégias da organização. Se a decisão for redesenhar os
processos, será necessário desenvolver um novo modelo de processos com as
melhorias previstas para a situação atual identificada (SANTOS apud OLIVEIRA,
2008. P. 40).
Dentre os resultados a serem esperados (O´CONNELL, PYKE &
WHITEHEAD; JESTON & NELIS apud BALDAM et al., 2008, p.93) podem estar
incluídos:
• Redesenho do processo ou mesmo um novo processo;
• Documentação de suporte ao processo redesenhado ou novo
processo;
• Requerimentos de alto nível para as novas opções observadas;
• Modelos de simulação e detalhes de custos ABC;
• Confirmação de que as novas opções atendem às expectativas dos
envolvidos;
• Confirmação que está alinhado à estratégia;
• Um relatório das diferenças que precisam ser atendidas para cumprir
os requerimentos;
• Plano de desenvolvimento e treinamento da equipe;
• Relatório de impactos na organização e em outras esferas (ambiental,
social e etc.);
• Detalhes do plano de comunicação do novo processo.
38
2.2.2.3 Ferramenta e metodologia de modelagem do processo de negócio
Cummins (apud Souza, 2008, p. 47), a ferramenta de definição dos processos
deve ter as seguintes características:
• Ferramenta gráfica interativa: Os processos são exibidos graficamente,
e os elementos do processo são adicionados e conectados com edição
interativa drag-and-drop;
• Distinção visual de tipo de tarefas: O tipo de cada elemento de
processo deve ser identificável visualmente na representação gráfica
do processo.
Gráficos de fluxos e mapeamento de processos sempre foram de grande
utilidade para o homem, existindo desde o surgimento da simbologia como meio de
entendimento e comunicação.
2.2.2.4 Otimização de Processos e Solução Imediata de Problemas
Não são apenas os processos que apresentam problemas (qualidade, custo,
prazo e visibilidade da marca) que passarão por otimização (inovação, redesenho e
melhoria contínua). Um processo de atendimento ao cliente, por exemplo, pode ser
completamente migrado para a Internet, ainda que esteja funcionando corretamente
na verdade, para minimizar custos e prazos de atendimento, pode até ser mesmo
desdobrado (atendimento via Internet para a maioria dos clientes e atendimento
telefônico para exceções), aumentando assim o número de processos (BALDAM et
al., 2008, p. 66).
39
De acordo com Baldam (2008, p. 66), algumas atividades emergem de
imediato, quando surgem situações como novos marcos, problemas de produção ou
qualidade, impedindo entrega ao cliente, concorrência que lança produtos mais
competitivos etc. Ainda que a necessidade desses processos não tenha sido
detectada no Planejamento Estratégico anual (o que não quer dizer que não estejam
alinhados com ele), sua implantação pode ser imediata.
2.2.3 Execução de processos
Nessa fase as definições da fase de modelagem do processo serão
executadas. Os processos serão testados pelos usuários, que indicarão os impactos
positivos e negativos da implementação desses.
Burlton (apud BALDAM et al., 2008, p. 94) sugere as seguintes atividades
para a execução de processos:
• Preparar o teste da nova solução;
• Completar testes e pilotos;
• Atualizar os entregáveis;
• Gerenciar o plano de transferência de tecnologia;
• Desenvolver os planos da execução da nova solução;
• Treinar a equipe;
• Desenvolver e executar os programas de marketing da solução;
• Realizar as mudanças no processo atual ou elaborara um novo
processo.
É também nesta fase, que ocorre a configuração do repositório do BPMS que
suportará o novo processo e a implantação e configuração das aplicações externas
40
que interagem com o processo. Um BPMS é responsável por manter os contextos
de execução dos processos, que inclui a atividade que está em execução, valores
de variáveis, contextos de sub-processos, logs. Ele deve facilitar a integração com
um conjunto de outras plataformas que executam os sistemas externos.
2.2.4 Controle e análise de dados
São geradas as informações sobre o comportamento dos processos, esses
dados são comparados e utilizados para montar indicadores gerais que permitem
avaliar o processo. Algumas técnicas e tecnologias aplicáveis ao controle e análise
dos dados de instâncias de processos, tais como BSC, BI, permitem uma melhor
visão do desempenho geral e apontam se a organização está alcançando seus
objetivos ou se é necessário efetuar ajustes nos processos, nas metas ou mesmo na
estratégia da organização.
Na fase de análise, a medida do desempenho do processo provê informações
de melhorias operacionais. A partir de uma visão “fim-a-fim” do processo é possível
fazer uma análise top-down para determinar a influência de cada passo ou sub-
processo no resultado global. Para dar suporte a essa fase são utilizados os
sistemas BAM (Business Activity Monitoring), onde os processos são instrumentados
com sensores para monitorar suas atividades e variáveis. Um dashboard permite a
monitoração, análise e respostas aos eventos e às exceções que ocorrem em tempo
real.
Normalmente, após o desenvolvimento de aplicações e de sua implantação e
execução em ambiente de produção, pouco suporte é dado ao negócio para avaliar
se a solução implementada foi adequada ou se há potencial para melhores
resultados. BPM, ao contrário, foca na melhoria contínua dos processos de negócio,
e para tanto, provê mecanismos para que o negócio acompanhe o comportamento
dos processos e identifique falhas e oportunidades.
Podemos categorizar essa monitoração dos processos sob dois aspectos:
41
• Operacional: Neste caso, o objetivo da monitoração é acompanhar os
processos no nível do detalhe, ou seja, cada instância em execução.
Procura-se por exceções (se o processo ultrapassou limites de prazo,
custo, conclusão sem sucesso) possibilitando assim o negócio atuar
na correção da situação, priorizando o processo ou mesmo
contatando seus participantes;
• Analítica: Aqui, o objetivo é analisar o conjunto das execuções dos
processos, procurando por exceções recorrentes ou por melhores
estratégias e oportunidades para o negócio. É o momento de
comparar os resultados projetados com os realmente atingidos e
planejar ações de correção.
A monitoração operacional é baseada na situação dos processos em
execução, a qual normalmente é mantida em banco de dados do mecanismo de
execução de processos. A figura 5 mostra duas instâncias de um processo sendo
monitorados pela ferramenta WebSphere Business Monitor da IBM. Nesta
ferramenta podemos definir quais campos devem ser mostrados, o critério para
ordenação das linhas, e filtros, baseados em dados de negócio, para selecionar
apenas os processos que se deseja monitorar.
Figura 5 – Monitoração de Processos de Negócio com o Websphere Business MQ.
Fonte: www.ibm.com.br
42
Já a monitoração analítica é normalmente baseada na análise de eventos
gerados e armazenados pelo mecanismo de execução. A solução da IBM
anteriormente mencionada, por exemplo, de tempos em tempos copia os registros
de eventos para uma base de dados especializada em pesquisas analíticas (que faz
uso de conceitos associados a “Data Warehouse”, como cubos) de forma a permitir
consultas sofisticadas e pesadas sem prejudicar o desempenho do ambiente de
execução de processos.
Com base nos eventos, são gerados os KPI (“Key Performance Indicators” ou
Indicadores Chaves de Desempenho) e os totais (métricas) escolhidos no momento
de projeto dos fluxos. Os KPIs devem ser cuidadosamente escolhidos, pois devem
refletir os objetivos do negócio mais relevantes para o sucesso da empresa, e
devem permitir a identificação antecipada de problemas, possibilitando ações
corretivas.
A figura 6 mostra dois KPI definidos para um processo (percentual de
aprovação e duração do processo). Aos KPI são associados limites, de forma que
seja facilitada a identificação de inconformidades. No exemplo, o processo foi
planejado para durar no máximo três dias, mas em ambiente real está levando mais
de três dias e 4 horas.
Figura 6 – Analisando os KPIs (Indicadores Chave de Desempenho).
Fonte: BENEDETE (2007, p.37).
43
No processo exemplo “aprovação de gastos de viagem”, pode-se definir como
KPIs o custo total do processo, a duração, o percentual aprovado, e o percentual de
aprovações realizadas pela diretoria.
Outra possibilidade é a criação de consoles de monitoração, através da
escolha e demonstração de um conjunto de indicadores em formato gráfico, como
mostrado na figura 7. Desta maneira, fica visualmente fácil e rápido acompanhar o
desempenho dos processos.
Figura 7 – Visualização gráfica dos indicadores.
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.
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).
45
Baldam (2008, p. 135), afirma ainda que, se não tratarmos seriamente o bom
gerenciamento, este fator acarretará prejuízos no mercado e até mesmo
penalidades junto aos órgãos financeiros e legislativos. No entanto, como citado
acima, o bom gerenciamento é alcançado com regulamentações variadas e
transformações no ambiente de negócios consideradas complexas. Para alcançar a
excelência da conformidade, é necessário realizar o levantamento de práticas que
obtiveram sucesso nas determinadas áreas que se pretende aplicar as adequações.
Como as organizações são sistemas semi-abertos, que interagem com o
meio-ambiente, um autogerenciamento visa garantir que os aspectos relacionados a
regulamentações sejam corretamente tratados. Para tanto, a conformidade é o
componente utilizado para este gerenciamento e pode ser definido como adequação
a um conjunto de regras, sejam estas regulações ou legislações governamentais,
padrões de indústria ou políticas e procedimentos internos (JENKINS apud BALDAM
et al., 2008, p. 135).
2.4 Sistemas de Gestão de Processos de Negócio (BPMS)
Business Process Management Systems (BPMSs) foram introduzidos com o
objetivo de prover controle para definir e coordenar a execução de processos de
negócio (GARCIA e TOLEDO apud SOUZA, 2008, p. 28).
Os BPMS´s são sistemas integrados que permitem a operacionalização de
fluxos de processos de negócio, automatizando a execução, controle e
monitoramento desses processos. Um BPMS deve possuir ferramentas que
permitam a modelagem, a execução e orquestração de processos e também deve
possuir ferramentas de análise e monitoramento.
Os sistemas de gestão de processos são plataformas que orquestram os
processos de negócio, junto com todos os sistemas e pessoas envolvidos, dando
uma completa visibilidade e controle aos gestores de processos. São, portanto, os
46
resultados de processos automatizados e geridos com o uso de ferramentas de
gestão de processos (ARORA apud SANTOS, 2007, p. 5).
“Os sistemas para o gerenciamento de processos (BPMS) são mais que um
sistema computacional que suporta a gestão da informação pela organização. Eles,
primeiro e principalmente, ajudam a gerenciar os processos” (OULD apud SANTOS,
2007, p. 5).
Os BPMSs apóiam a automatização de processos de negócio. O ciclo de vida
de automatização inicia com a definição do processo. Em seguida, a definição é
registrada em um BPMS. Para executar um processo, o sistema cria uma instância
de processo e então, coordena, monitora e registra sua execução. O registro pode
ser analisado, podendo gerar uma definição aprimorada do processo (AALST;
HOFSTEDE; WESKE apud ROCHA, 2008, p. 23).
Diferentemente dos Workflows Management Systems (WfMSs), que são
sistemas de software que definem, criam e gerenciam a execução de workflows, os
BPMSs enfatizam processos que cruzam as fronteiras organizacionais e o aspecto
da dinamicidade de processos (HOLLINGSWORTH apud ROCHA, 2008, p. 23).
2.4.1 Ciclo de Vida de BPMS
Considerando o contexto de negócio atual, Business Process Management
Systems (BPMSs) foram introduzidos com o objetivo de prover controle para definir e
coordenar a execução de processos de negócio (GARCIA e TOLEDO apud SOUZA,
2008, p.28).
Geralmente um BPMS apresenta quatro funcionalidades principais que são:
Projeto, Configuração, Execução e Diagnóstico.
47
Figura 9 – Automação do ciclo de vida de processo de negócios.
Fonte: Adaptada de GARCIA e TOLEDO apud SOUZA, (2008, p.30).
• Projeto: o ciclo de vida tem início com a modelagem do processo de
negócio, nesta fase ocorre o levantamento dos processos, do
ambiente, organizacional e técnico. São utilizados editores de
modelagem e ferramentas para validação dos processos de negócios;
• Configuração: nesta fase, os modelos de processos são
implementados. São incluídas informações técnicas que facilitam a
execução dos processos;
• Execução: o processo de negócio pode ser executado através de um
BPMS configurado, o BPMS cria instâncias de um modelo de
processos, coordena a execução e registra as informações coletadas
durante a execução do processo;
• Diagnóstico: o histórico da execução é analisado, identificando
problemas e melhorando os processos. Isso pode levar ao processo
de redesenho do processo (fase de projeto). Conforme mostra a figura
9.
48
2.5 BPMN e os elementos de BPD
A BPMN (Business Process Modeling Notation) é uma notação visual para
representação de fluxos de processos que pode ser mapeada para diversos
formatos de execução, como BPML (Business Process Modeling Language) e BPEL
(Business Process Execution Language) (REIS et al., 2007, p. 07).
A especificação BPMN, criada pelo BPMI (Business Process Management
Initiative) provê uma notação gráfica para representar processos de negócios em um
diagrama, servindo de apoio ao uso de BPM por não-especialistas (BALDAM et al.,
2008, p.79).
A BPMN define um diagrama de processo (Business Process Diagram –BPD),
contendo os elementos gráficos, que representam atividades e fluxos de controle
que determinam a ordem de execução dessas atividades.
Um diagrama de Processos de negócios (BPD) é constituído de um conjunto
de elementos gráficos que permitem o desenvolvimento de diagramas simples
semelhantes aos de fluxo utilizados por analistas de negócio. Os elementos
utilizados são distintos uns dos outros e utilizam formas também comumente
utilizadas pela maioria dos modeladores. Por exemplo, as atividades são
representadas por retângulos e as decisões por losângulos. A figura 10 demonstra
esse exemplo.
Figura 10 – Demonstração das Atividades e Decisões
Fonte: Adaptada de Reis (2007, p. 07).
49
2.5.1 Objetos de Fluxo (Flow Objects)
Um BPD tem um conjunto de três elementos básicos, conhecidos como
Objetos de Fluxo, para que os modeladores não tenham que aprender e reconhecer
um número grande de formas diferentes. A tabela 01 demonstra os três objetos de
fluxo.
50
Nome Descrição Objeto
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).
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).
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).
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).
54
3. ARQUITETURA ORIENTADA A SERVIÇOS
A arquitetura SOA baseia-se em permitir que sistemas corporativos
disponibilizem suas funcionalidades através de serviços que podem ser utilizados
por outros sistemas para a execução de suas tarefas. É importante ressaltar que a
Arquitetura Orientada a Serviços não é um software. Este termo refere-se a um
modelo de arquitetura de software voltada para a construção de aplicações que
implementam processos de negócio ou serviços utilizando um conjunto de
componentes fracamente acoplados e orquestrados a fim de prover um nível de
serviço bem definido (HURWITZ apud MIRANDA 2008, p. 16).
A SOA estabelece um modelo arquitetônico que visa a aprimorar a eficiência, a agilidade e a produtividade de uma empresa, posicionando os serviços como os principais meios para que a solução lógica seja representada no suporte à realização dos objetivos estratégicos associados à computação orientada a serviços (ERL et al., 2008, p.24).
A SOA permite flexibilidade com serviços que podem ser fornecidos
localmente ou podem estar localizados externamente, os serviços podem ser
implementados em qualquer linguagem de programação, plataformas diferentes,
tecnologias diversas podem ser utilizadas e o legado de software pode ser
aproveitado mantendo o principio da interoperabilidade. É uma caracterização de
sistemas distribuídos, em que as funcionalidades do sistema são expostas via
descrição de uma interface, permitindo a publicação, localização e a invocação por
meio de um formato padronizado.
As arquiteturas orientadas a serviços são um caminho para o desenvolvimento de sistemas distribuídos nos quais os componentes destes sistemas são serviços dedicados. Os serviços podem ser executados em computadores distribuídos geograficamente. Protocolos padronizados foram projetados para apoiar troca de serviços de comunicação e de informações. Conseqüentemente, os serviços são plataformas e linguagens de implementações independentes. Sistemas de software podem ser construídos usando serviços de provedores diferentes em nenhuma ligação de interação entre esses serviços (SOMMERVILLE apud OLIVEIRA, 2008, p. 62).
55
A Arquitetura Orientada a Serviço é capaz de oferecer a infra-estrutura
tecnológica necessária para que uma aplicação possa ser definida por meio da
composição de serviços eletrônicos. Dessa forma, oferece apoio à composição de
aplicações distribuídas de uma forma flexível e com baixo custo. Em SOA, a
composição de serviços é vista como um processo de negócio dividido em
componentes reutilizáveis e interoperáveis em Serviços.
Segundo Moreira (2007, p. 18), a arquitetura orientada a serviços é
constituída de relações entre três tipos de participantes:
• Diretório para registro de serviços, repositório que é utilizado para
publicar e localizar as interfaces dos serviços;
• Provedor de serviços, entidade responsável por publicar as interfaces
dos serviços providos por esta no registro de serviços e também
responsável por atender as requisições originadas pelos clientes;
• Cliente, aplicação ou outro serviço que efetua requisições a um serviço.
E esses participantes se relacionam através de três principais operações que
são:
• Publicar: Inicialmente, o provedor de serviço publica a interface do seu
serviço junto ao diretório para registro de serviços;
• Localizar: O cliente pode efetuar uma busca por um determinado
serviço (operação localizar), especificando as características
desejadas, no diretório de registros. Se o serviço existir, a interface e a
localização do respectivo serviço são retornados para o cliente;
• Invocar: O cliente efetua uma invocação ao provedor do serviço
(operação invocar). Os serviços estão baseados nas trocas de
mensagens entre os provedores e os clientes, sendo assim, as
mensagens seguem um formato padrão, garantindo aos serviços a
neutralidade da tecnologia e permitindo que provedores.
56
3.1 Características da Arquitetura Orientada a Serviços
Erl (apud Moreira 2007, p. 19) define SOA como sendo uma tecnologia que
adere aos princípios da orientação a serviços. Quando realizados através do uso da
tecnologia de Web Services, SOA promove esses princípios em todos os processos
de negócios e automação de uma corporação.
Para a composição de Sistemas de Software compostos por serviços, a
Arquitetura SOA deve permitir todas as características apresentadas na Tabela 5.
57
CARACTERÍSTICA DESCRIÇÃO
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).
58
3.2 Componentes SOA
De acordo com a especificação de arquitetura orientada a serviços pela
organização OASIS, SOA é um paradigma para organização e utilização de
competências distribuídas que estão sob o controle de diferentes domínios
proprietários (OASIS, 2007). Para prover essa organização e utilização, a
Arquitetura SOA dispõe de quatro componentes principais: 1- Aplicação Frontend; 2
- Serviço; 3 - Repositório de Serviço e 4 - Barramento de Serviço (KRAFZIG apud
MIRANDA, 2008, p.26).
Esses componentes estão dispostos de forma interoperável ou colaborativa,
fornecendo a estrutura necessária para a disponibilização dos serviços. A Figura 11
ilustra uma visão geral da arquitetura SOA.
Figura 11 – Componentes da arquitetura SOA.
Fonte: MIRANDA (2008, p.26).
59
3.2.1 Aplicação Frontend
Segundo Josuttis (apud Miranda, 2008, p.27) são os elementos ativos de
SOA, iniciando e controlando as atividades de um sistema e entregando o resultado
do serviço, interagindo com o usuário. Existem diferentes tipos de Aplicações
FrontEnd. Um exemplo desse componente é uma aplicação de interface gráfica,
como uma aplicação Web que utiliza um browser para a interação com o usuário,
fazendo a chamada do processo e recebendo o resultado da execução de um
serviço. Uma Aplicação Frontend desempenha um papel muito próximo ao Padrão
de Projetos Facade (Fachada), onde um objeto disponibiliza uma interface que dá
acesso a uma grande quantidade de funcionalidades de um subsistema, abstraídas
do objeto que originou as chamadas. A Figura 12 ilustra um exemplo de Aplicação
FrontEnd.
Figura 12 – Exemplo de Aplicação Frontend.
Fonte: MIRANDA (2008, p.27).
60
3.2.2 Serviços
Um Serviço pode ser entendido como uma função do sistema computacional
construída de forma a ser facilmente vinculada a outros componentes de software,
que podem ser outros serviços. O Serviço tem papel fundamental dentro da
Arquitetura Orientada a Serviços, pois encapsula uma função de negócio que pode
ser reutilizável, tendo como características marcantes a independência de
tecnologias de linguagens de programação em sua implementação e baixo
acoplamento. A Figura 13 ilustra a composição de um serviço com seus sub-
componentes.
Figura 13 – Composição de um Serviço na Arquitetura SOA.
Fonte: KRAFZIG apud MIRANDA (2008, p.28)
Cada serviço deve conter um Contrato, que especifica restrições quanto ao
acesso ao serviço e uso dos serviços. O contrato impõe semântica sobre as
61
funcionalidades e parâmetros do serviço (DAVIES apud MIRANDA, 2008, p. 28). Os
serviços também devem disponibilizar Interfaces, que definem as operações
disponíveis em um serviço. As interfaces podem ser entendidas como as assinaturas
dos métodos definidos em classes na Orientação a Objetos, onde é descrito o tipo
de retorno, o nome da operação, sua visibilidade e argumentos.
A regra de negócio realizada pelo serviço deve estar contido na
Implementação, que proporciona a execução do serviço utilizando a lógica de
negócio e os dados necessários. Alem da lógica de negócios e dos dados, fazem
parte da Implementação os subprogramas, os dados e arquivos de configuração e a
base de dados.
SOA promove a idéia de módulos de software que prestam serviços a outros
módulos, com características e tecnologias diferentes. A concepção de serviço tem
três características principais, conforme mostra a tabela 06.
CARACTERÍSTICA DESCRIÇÃO
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:
62
• Serviço utilitário: são serviços que implementam algumas
funcionalidades gerais que podem ser utilizadas por diferentes
processos de negócios;
• Serviço de entidade: são serviços associados a uma função específica
do de negócio;
• Serviço-tarefa: são serviços que apóiam os processos de negócios
mais gerais que envolvem diferentes atores e atividades.
3.2.3 Ciclo de Vida dos Serviços
Segundo Miranda (2008, p. 30) os serviços são considerados pedaços de
software que encapsulam alguma funcionalidade de negócios. Como tal, seu ciclo de
desenvolvimento é comum aos softwares, consistindo nas fases de: modelagem,
implementação, integração e execução. O ciclo de vida de um serviço pode aplicar o
modelo em cascata, porém, assim como no desenvolvimento de um software, não é
o modelo ideal, podendo assumir um ciclo de vida iterativo, onde o desenvolvimento
de software pode ser ajustado com as experiências obtidas nas fases anteriores. A
Tabela 7 apresenta as etapas do ciclo de vida dos serviços bem como a descrição
de cada etapa.
63
ETAPA DESCRIÇÃO
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).
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).
65
3.3 Composição de Serviços
Segundo Moreira (2007, p.32.) para solucionar problemas como distribuição e
heterogeneidade de aplicações, surge a necessidade de composição de serviços.
Esta técnica permite modelar o processo de negócio e também aumenta a
possibilidade de aproveitar os benefícios da arquitetura orientada a serviços.
O mecanismo da composição de serviços visa combinar dois ou mais serviços
para que, juntos, possam atender a requisitos que vão além das suas capacidades
individuais. Em outras palavras, a composição provê uma abordagem aberta,
baseada em padrões, para conectar Web Services objetivando criar processos de
negócio de alto nível, com um alto valor agregado. A Figura 14 exemplifica uma
composição de serviços.
Uma das principais motivações para a utilização da composição de serviço é
o desenvolvimento de processos de negócio envolvendo vários parceiros e
seqüência de operações.
Figura 14 – Composição de Serviços
Fonte: MOREIRA (2007, p.33).
66
Os padrões são projetados para reduzir a complexidade requerida para
compor Web Services, reduzindo custo e tempo, e aumentando a eficiência global
nos negócios.
De acordo com Moreira (2007, p. 33), a composição de serviços deve atender
as seguintes exigências:
• Habilidade de invocar serviços de maneira assíncrona, alcançando
confiabilidade, escalabilidade e adaptabilidade, características
necessárias em um ambiente de negócios;
• Gerenciar a integridade transacional e de exceções;
• Prover uma clara separação entre a lógica do processo e os Web
Services usados;
• Ser capaz de compor serviços de alto nível de processos existentes.
A composição de serviços faz uso de vários serviços para criar um serviço
e/ou o uso de um serviço por outro serviço vai se tornando mais comum, para a
criação de processos, para isso dois conceitos são muito importantes: orquestração
e coreografia, como visto na figura 15.
Figura 15 – Orquestração e Coreografia.
Fonte: LEITÃO e MARGALHO JUNIOR (2007, p.25)
67
3.3.1 Orquestração
As interações do processo de negócios são controladas por uma das partes
envolvidas no processo. A orquestração envolve interações entre as partes e os
passos entre as interações (FANTINATO; TOLEDO; GIMENES apud SOUZA, 2008,
p.61).
Empresas que têm sistemas legados interconectados ou processo de negócio trabalhando em conjunto necessitam comumente de uma unidade controladora, a fim de facilitar o processo de interoperabilidade entre tais sistemas. Essa solução é conhecida como orquestração de serviços. A forma de implementação deste mecanismo permite que dois ou mais sistemas se comuniquem com uma unidade orquestradora central (MOREIRA, 2007, p. 33-34).
Um dos requisitos que guia a criação de orquestrações é o fato de unir
processos de negócio. Com a orquestração, diferentes processos podem ser
conectados sem que seja necessário desenvolver novamente as sua
funcionalidades em um novo sistema. O uso da orquestração pode reduzir
significativamente a complexidade de implementação, bem como facilitar a
manutenção dos sistemas (ERL, 2005, p. 203).
A Figura 16 exibe o funcionamento do processo de orquestração de serviços.
O coordenador central (por exemplo, um Web Service) recebe uma mensagem do
Web Service 1 requisitando alguma informação. O coordenador invoca alguns
parceiros a fim de agrupar a informação e então retorna o resultado para o Web
Service 1. Este tipo de processo pode ser conhecido como privado e executável, já
que apenas a entidade que está orquestrando o processo conhece o fluxo de
controle e informação que o segue. A principal técnica de implementação da
orquestração é através da linguagem BPEL.
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).
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.
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.
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.
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).
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).
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).
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.
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).
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).
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
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
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).
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).
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).
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).
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.
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.
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
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)
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.
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
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.
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:
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.
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
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
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.
96
Figura 30 – Processo modelado (As Is).
Fonte: do autor.
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;
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.
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.
100
Figura 31 – Processo modelado (To Be).
Fonte: do autor.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.