Monografia bpm
Upcoming SlideShare
Loading in...5
×
 

Monografia bpm

on

  • 2,058 views

Acesse centenas de materiais e mais de 04 mil horas de cursos online gratuitos de TI no Portal GSTI: www.portalgsti.com.br.

Acesse centenas de materiais e mais de 04 mil horas de cursos online gratuitos de TI no Portal GSTI: www.portalgsti.com.br.

Statistics

Views

Total Views
2,058
Views on SlideShare
2,032
Embed Views
26

Actions

Likes
2
Downloads
135
Comments
0

1 Embed 26

http://www.gestaosi.com.br 26

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Monografia bpm Document Transcript

  • 1. CENTRO TECNOLÓGICO DA ZONA LESTE FACULDADE DE TECNOLOGIA DA ZONA LESTE RAFAEL RAYATO INAZAWAA APLICAÇÃO DO BPM PARA AUTOMAÇÃO DEPROCESSOS DE NEGÓCIO NAS ORGANIZAÇÕES ESTUDO DE CASO: PROJETO NEW_RCMS São Paulo 2009
  • 2. CENTRO TECNOLÓGICO DA ZONA LESTE FACULDADE DE TECNOLOGIA DA ZONA LESTE RAFAEL RAYATO INAZAWAA APLICAÇÃO DO BPM PARA AUTOMAÇÃO DEPROCESSOS 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
  • 3. Inazawa, Rafael Rayato A Aplicação do BPM para Automação de Processos de Negócionas Organizações. Estudo de Caso: PROJETO NEW_RCMS /RafaelRayato Inazawa– São Paulo, SP : [s.n], 2009. 111 f. Orientador: Wilson Vendramel. Trabalho de Conclusão de Curso (Tecnólogo) – Faculdade deTecnologia da Zona Leste. 1. Gestão do processo de negócio. 2. Arquitetura orientada aserviços. I. Vendramel, Wilson. II. Faculdade de Tecnologia daZona Leste.
  • 4. CENTRO TECNOLÓGICO DA ZONA LESTE FACULDADE DE TECNOLOGIA DA ZONA LESTE RAFAEL RAYATO INAZAWAA 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.
  • 5. DEDICATÓRIA A Deus, aos meus pais, minha namorada e aos meus amigos... companheiros de todas as horas...
  • 6. 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 dosgrandes 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.
  • 7. “Cabe ao ser humano dedicar omáximo de si em tudo o que fizer,nas circuntâncias em que seencontra, neste exato momento, deveempenhar-se de corpo e alma comtotal seriedade sem se deixarinfluenciar pelos ventos do elogio ouda censura..." Daisaku Ikeda
  • 8. INAZAWA, Rafael Rayato. A Aplicação do BPM para automação de Processos deNegó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 ZonaLeste, São Paulo, SP. RESUMOAs organizações em um mercado cada vez mais competitivo são constantementedesafiadas a produzirem melhores resultados com menor custo, desenvolveremprodutos e serviços baseados em um ciclo de vida mais curto e se relacionarem deforma mais personalizada e integrada com seus clientes, fornecedores e parceiros. Asorganizações devem ser capazes de melhorar seus processos de negócio e suacomunicação com a área de TI, da qual dependem para viabilizar seus objetivos eestratégias, atualmente buscam melhorar seus processos de negócio e alinhá-los juntocom a TI, essa sinergia torna os processos das empresas flexíveis e resilientes frente aum 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 doambiente 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 ProcessManagement) nas corporações.Palavras-chave: Arquitetura Orientada a Serviços, Processo de Negócio, BPM.
  • 9. INAZAWA, Rafael Rayato. The Implementation of BPM for process automation inBusiness Organizations – Case Study: PROJECT NEW_RCMS. Conclusion Course(Technologist) – Faculdade de Tecnologia da Zona Leste, São Paulo, SP. ABSTRACTThe organization in a market increasingly competitive environment are constantlychallenged to produce better results at lower costs, develop products and servicesbased on a life cycle shorter and relate in a more customized and integrated with itscustomers, suppliers and partners. Organizations must be able to improve their businessprocesses and their communication with the IT area, upon which to put its objectivesand strategies currently seeking to improve their business processes and align themwith IT, this synergy makes business processes flexible and resilient in the face of a newkind of global market. It is necessary to apply management models in the strategic areasof the company to become possible to represent the business environment and the useof a flexible, dynamic and adaptable (SOA - Service-Oriented Architecture) provide asystemic view of the entire organization . Thus, this work focuses on analyzing thedeployment of BPM (Business Process Management) in corporations.Key-Words: Service-Oriented Architecture, business process, BPM.
  • 10. LISTA DE ABREVIATURASBAM Business Activity MonitoringBI Business IntelligenceBPD Business Process DiagramBPEL Business Process Execution LanguageBPM Business Process ManagementBPMI Business Process Management InitiativeBPMN Business Process Modeling NotationBPMS Business Process Management SystemsBPR Business Process ReengineeringBSC Balanced ScorecardFAST Fast Analysis Solution TechniqueKPI Key Performance IndicatorsOASIS Organization for the Advancement of Structured Information StandardsPMI Project Management InstituteSOA Service-Oriented ArchitectureSOAP Simple Object Access ProtocolSWOT Strengths, Weakness, Opportunities and ThreatsTI Tecnologia da InformaçãoUDDI Universal Description, Discovery and IntegrationWfMC Workflow Management Coalition
  • 11. WfMSs Workflow Management SystemsWS Web ServiceWS-BPEL Web Service Business Process Execution LanguageWSDL Web Services Definition LanguageWSFL Web Service Flow LanguageXML eXtensible Markup Language
  • 12. LISTA DE FIGURASFigura 1 – Ilustração de um processo de negócio...........................................................24Figura 2 – Visão Sistêmica dos Processos.....................................................................25Figura 3 – Ciclo de BPM..................................................................................................28Figura 4 – Exemplo de Visão Global de Processos de compra......................................32Figura 5 - Monitoração de Processos de Negócio com o Websphere Business MQ......41Figura 6 – Analisando os KPIs (Indicadores Chave de Desempenho)...........................42Figura 7 – Visualização gráfica dos indicadores.............................................................43Figura 8 – Exemplo de relatório analítico........................................................................44Figura 9 – Automação do ciclo de vida de processo de negócios..................................47Figura 10 – Demonstração das Atividades e Decisões...................................................48Figura 11 – Componentes da arquitetura SOA...............................................................58Figura 12 – Exemplo de Aplicação Frontend..................................................................59Figura 13 – Composição de um Serviço na Arquitetura SOA.........................................60Figura 14 – Composição de Serviços..............................................................................65Figura 15 – Orquestração e Coreografia.........................................................................67Figura 16 – Exemplo de processo de orquestração de serviços.....................................69Figura 17 – Exemplo de Coreografia de serviços...........................................................69Figura 18 – Fluxo de Processo BPEL.............................................................................71Figura 19 – Estrutura básica de uma especificação BPEL.............................................73Figura 20 – Interface Gráfica modelada pelo BPEL através da ferramenta Eclipse.......75Figura 21 – Camadas de Abstração de SOA..................................................................76
  • 13. Figura 22 – O negócio e os domínios da lógica da aplicação.........................................77Figura 23 – As três principais camadas de serviços.......................................................78Figura 24 – Serviços utilitários da camada de serviço de aplicação...............................79Figura 25 – Serviço ServicoSalvarGrupo nas camadas de Aplicação e Negócios.........81Figura 26 – Ciclos de Vida de SOA.................................................................................83Figura 27 – Atividades do ciclo de vida com os serviços no ambiente SOA...................86Figura 28 – Arquitetura Web Services.............................................................................89Figura 29 – Arquitetura de todos os sistemas do departamento.....................................93Figura 30 – Processo modelado (As Is)..........................................................................96Figura 31 – Processo modelado (To Be).......................................................................100Figura 32 – Interface da aplicação no PDA...................................................................102Figura 33 – Arquitetura tecnológica e suas aplicações após a implantação do BPM...103
  • 14. LISTA DE QUADROSQuadro 1 – Atividades básicas de BPEL.........................................................................72Quadro 2 – Atividades Estruturadas de BPEL................................................................72Quadro 3 – Processo de atendimento (As Is).................................................................94Quadro 4 – Processo de atendimento (To Be)................................................................98Quadro 5 – Comparativo entre antes e depois da implantação do BPM......................103
  • 15. LISTA DE TABELASTabela 1 – Objetos de Fluxo...........................................................................................50Tabela 2 – Objetos de Conexão......................................................................................51Tabela 3 – Raias (Swimlanes).........................................................................................52Tabela 4 – Artefatos........................................................................................................53Tabela 5 – Principais Características da Arquitetura SOA..............................................57Tabela 6 – Características da Concepção de Serviços...................................................61Tabela 7 - Fases do Ciclo de Vida do Serviço................................................................63Tabela 8 – Características do Barramento de Serviços..................................................64Tabela 9 – Principais sistemas do Service Desk.............................................................92
  • 16. SUMÁRIO1. INTRODUÇÃO............................................................................................................192. 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
  • 17. 2.5.4 Artefatos.............................................................................................................533. 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
  • 18. 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........................................................................................................874. 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..............................................................................................1015. CONSIDERAÇÕES FINAIS......................................................................................105REFERÊNCIAS.............................................................................................................107GLOSSÁRIO.................................................................................................................110
  • 19. 191. INTRODUÇÃO Melhoria Contínua é um termo bem conhecido para as organizações quedesejam se manter competitivas no mercado. Hoje com a disposição dos maisvariados modelos, métodos e processos de Gestão, algumas têm conseguidoalcançar os principais objetivos que são: manter crescimento, reduzir gastos eaumentar lucros. As organizações que conseguem alcançar suas metas e objetivos em geralsão as que possuem processos internos e externos bem definidos, estão sempre emconstante mudança organizacional e se adaptam rapidamente a elas, geralmentepossuem uma ótima infra-estrutura de TI alinhada ao seu processo de negócio, issoas tornam empresas flexíveis. A maior dificuldade das empresas é alinhar os seus processos de negócio aTI, criar uma solução tecnológica adequada que agregue valor ao seu negóciopossibilita a empresa ter uma forte flexibilidade e interoperabilidade paraacompanhar as constantes mudanças de processos e informações. A aplicação do Business Process Management (BPM) permite mapear osprocessos organizacionais da empresa, buscando a integração funcional eproporcionando maior agilidade nas atividades que envolvem pessoas, tarefas,máquinas, aplicações de software e outros elementos coordenados para atingir osobjetivos do negócio. Com a utilização de notação de modelagem de processoscomo Business Process Management Notation (BPMN), os analistas de negóciopodem documentar os modelos criados e entender melhor os processos da empresaem diferentes níveis, facilitando deste modo o entendimento dos participantes dosprocessos de negócio. Da necessidade de integração entre diferentes sistemas e a disseminação daWeb surge a Arquitetura Orientada a Serviços – SOA (Service-Oriented Architecture)que veio com o objetivo de integrar serviços fracamente acoplados, possibilitando oreuso, modificação e a aplicação em diferentes áreas internas ou externas daempresa. Atrás de inovação, as empresas vêem cada vez mais demonstrando
  • 20. 20interesse em Web Services, pois é uma tecnologia atual baseada na Web capaz deintegrar serviços utilizando tecnologia XML (eXtensible Markup Language). De certaforma essa tecnologia pode sanar boa parte dos problemas de uma organização queutiliza sistemas diferentes, fazendo com que eles troquem informações, com isso aempresa pode integrar seus processos a esses sistemas independentes deplataforma ou linguagem de programação. Este trabalho tem como objetivo demonstrar os passos necessários para umaorganização implementar o BPM, por meio da modelagem de seus processos,visando promover a flexibilidade, Interoperabilidade e a reusabilidade decomponentes na organização. A Justificativa para o desenvolvimento deste trabalho é demonstrar que oBusiness Process Management é de extrema importância para as organizações eque suas contribuições agregam mais valor ao negócio tornando a empresa maiscompetitiva no mercado. A metodologia deste estudo será feita a partir de pesquisa bibliográfica etambém de um estudo de caso que apresenta a modelagem de um processo denegócio, a fim de demonstrar as principais atividades e características da gestão deprocessos de negócio por meio do BPM. O estudo de caso consiste em analisar um determinado processo de umserviço oferecido por uma organização, e a utilização de uma ferramenta demodelagem 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 denegócio. O segundo capítulo aborda a gestão de processos de negócio, que é umadisciplina de gestão estratégica, que sustenta a idéia de que podemos modelar umnegócio em termos de processos de sua finalidade que podem abranger tradicionaisorganizações e fronteiras de sistemas. Ele envolve a descoberta, projeto e entregados processos de negócio, fazendo com que todos os departamentos daorganização estejam alinhados com as metas e estratégias da corporação. Uma boagestão ainda permite um ciclo de melhoria contínua onde as organizações devemestar aptas às constantes mudanças organizacionais em conjunto com a Tecnologiada Informação para estarem melhor alinhadas com suas metas, estratégias e
  • 21. 21objetivos. O terceiro capítulo, aborda a arquitetura orientada a serviços que é umaaproximação arquitetural para desenvolvimento de sistemas que constrói e distribuiserviços reutilizáveis e encapsulados prestados às empresas para que diferentesaplicações possam compartilhá-los em um modo vagamente acoplado e altamenteinter-operável. A implementação desses serviços podem ser feitas independente daplataforma ou linguagem de programação, utilizam protocolos padronizados para acomunicação e troca de informações. Esses padrões tornam os serviços flexíveis ereusáveis, podendo ser executados em computadores distribuídos geograficamente.Essa arquitetura ainda permite a utilização de diversas outras tecnologias incluindoos sistemas legados da organização, mantendo a interoperabilidade entre osdiversos sistemas da organização.
  • 22. 222. GESTÃO DE PROCESSOS DE NEGÓCIO Segundo a BPMN (apud BALDAM et al., 2008, p.19), a gestão por processosde negócios envolve a descoberta, projeto e entrega de processos de negócios.Adicionalmente, o BPM inclui o controle executivo, administrativo e supervisóriodesses 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 opropó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 emmeados dos anos 90: Business Process Reengineering (BPR), que prometiaaumentar o desempenho dos negócios em um período relativamente curto pelareengenharia completa dos processos de negócios existentes. O BPR teve umgrande sucesso inicial, mas o movimento teve um declínio que levou ao fracassovários projetos. O BPM surgia 10 anos mais tarde e trazia de volta a gestão porprocessos de negócios com soluções que atendiam, através da evolução dos fluxosde trabalho, a interoperabilidade de processos mais complexos e distribuídosfisicamente. Com a integração e aperfeiçoamento dos processos, de forma que as metas eestratégias estejam alinhadas com a corporação, a gestão por processos podetrazer eficiência e permitir vincular a atividade das diferentes funções internas aosfatores competitivos da organização. No entanto, se o processo como um todo não for corretamente analisado eavaliado, as correntes funções tornam-se um grupo de pequenas unidades denegócios isoladas, as quais são avaliadas indevidamente por padrões nãocondizentes com as necessidades globais da empresa. O acontecimento maiscomum é o de o organograma receber uma maior atenção do que o próprio negócio. O termo BPM, Business Process Management, é largamente utilizado pelosautores para referenciar a automação dos processos, que uma vez passando por
  • 23. 23esse processo de automatização, pode ser gerenciado posteriormente, por meio deferramentas de software. Já no ambiente de negócios, os executivos se referem à gestão de processosde negócios de uma forma mais genérica, com uma visão de gerenciamentohumano 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 queenvolvem pessoas, tarefas, máquinas, softwares e outros elementos coordenadospara 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 vistocomo um conjunto estruturado de tarefas que contribuem coletivamente para queuma organização atinja os seus objetivos. Os processos de negócio são a baseoperativa de uma empresa e fazem parte da cultura desta e o êxito da mesmadepende fortemente da eficiência com que eles são administrados. Assim sendo,uma má administração dos processos traz altos custos, baixa produtividade einadequados tempos de resposta, tanto frente às oportunidades como às ameaças.A figura 01 exemplifica um processo de negócio.
  • 24. 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 nasorganizações, ela demonstra o que está diretamente envolvido em um processo emparticular (entradas, saídas, recurso e controles), inclusive as influências externasoriundas do contexto da organização, que podem alterar o modo de funcionamentodo processo até mesmo os produtos produzidos pelo processo (BALDAM et al,2008, p.21).
  • 25. 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 elementohumano pode demorar em completar a tarefa. Para os mecanismos de BPM daremsuporte a interação humana, não só devem armazenar e controlar estes processosde 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. 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 sedifunde, as formas contemporâneas de racionalização tendem a ver as organizaçõescomo um feixe de processos, e ele classifica esses feixes de processos da seguintemaneira: • Transfuncionais: pois atravessam departamentos;
  • 27. 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 ecomo fazê-lo, não em cima das atividades dos departamentos, mas sim, atividadesque agregam valor a organização independente do departamento que executará oprocesso. Deste modo, os processos tramitariam entre departamentos conforme oserviço que ele necessitar realizar (BALDAM et al., 2008, p. 24). Porém, com estas características de processos, os departamentos aindaseriam ú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, segundoBaldam (2008, p. 56), podem ser aplicadas em um processo específico daorganização ou em processos de negócios onde existe uma gestão da integraçãodestes já presente, podendo ser utilizada também em um estado de gestão que sepretende chegar futuramente. A figura 3 ilustra o ciclo do BPM.
  • 28. 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. 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ãodescritas 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. 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 doplanejamento. É importante a participação de gestores de outras áreas daorganização, o apoio desses gestores e o seu comprometimento com o BPM deforma contínua contribuem para o êxito na gestão por processos, caso isso nãoocorra, surgirão processos isolados sem uma visão global dos processos. Nomomento da implantação, é fundamental a participação efetiva do gestor daorganização, a fim de evitar possíveis barreiras e desentendimentos, entre osfuncionários dos diversos setores e áreas envolvidas. De acordo com Baldam (2008, p. 66) não são apenas os processos queapresentam problemas (qualidade, custo, prazo, etc.) que passarão por otimização,outros processos que estejam funcionando perfeitamente podem ser otimizadosbuscando inovação ou melhoria contínua desse processo.
  • 31. 31 Algumas atividades surgem de imediato e mesmo que a necessidade desseprocesso não tenha sido detectada no planejamento estratégico, sua implantaçãopode 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 Integradados 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. 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 vidaSOA, ela é um conjunto de conceitos, modelos e técnicas com o objetivo dedesenvolver o modelo de negócio da organização. Este modelo é resultado de umaabstração da organização, considerando as suas características essenciais, doponto 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 processosde 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. 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 ematividades, que podem ser mapeadas como tarefas que são executadas por pessoasou sistemas internos ou externos à corporação. É realizada a validação ou asimulação dos processos, através do uso de estimativas de tempo de execução ecusto, recursos requeridos pelas atividades e a probabilidade de ocorrência deeventos. Essa fase também inclui a definição das métricas de desempenho doprocesso 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 ede 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 deverepresentar de forma simples e intuitiva o fluxograma de atividades do processomodelado. A modelagem deve ser realizada em dois níveis: de forma gráfica, com oauxí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 fluxode trabalho. Durante a descrição de um diagrama de negócio, os eventuais problemasrelacionados ao processo que ele representa são documentados e para cada umsão propostas possibilidades de melhorias. Os principais conceitos envolvidos, asregras e os recursos utilizados ou produzidos por cada processo são identificados emodelados como entidades de negócio.
  • 34. 342.2.2.1 Modelagem de estado atual (As Is) Por meio desta modelagem é possível entender o processo existente naorganização e identificar suas falhas. Espera-se, desta forma, obter métricassuficientes a fim de estabelecer uma base na fase seguinte da análise edesempenho do processo atual, que permita identificar as melhorias proporcionadaspelo estado futuro, assim como uma documentação dos prós e contras e dodesempenho do processo. Na modelagem do estado atual do processo, vários tipos de interações entreos envolvidos no processo podem existir, incluindo atividades de colaboração ereuniões. Diversas técnicas podem ser utilizadas na modelagem de processos atual:técnica de entrevistas, brainstorm, JAD, métodos simplificados de modelagem compapel, entre outras. Baldam (et al., 2008, p. 76-77) aponta como sendo relevante as seguintesetapas 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. 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 processoatual deve verificar se os objetivos são atendidos, se as atividades estão bemrelacionadas, se os recursos alocados são suficientes e se as interfaces entregerências estão sendo previstas e administradas. Também é importante verificar aconsistência das tarefas utilizadas, evitando a redundância das mesmas. Como Resultado da modelagem do estado atual JESTON & NELIS (apudBALDAM 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. 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 40envolvidas de forma a melhorar o processo em questão, inová-lo ou mesmoquestionar 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 aosprocessos identificados durante a modelagem do estado atual e seu realinhamento
  • 37. 37com os objetivos e estratégias da organização. Se a decisão for redesenhar osprocessos, será necessário desenvolver um novo modelo de processos com asmelhorias 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 estarincluí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. 382.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 processosdeve 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 grandeutilidade para o homem, existindo desde o surgimento da simbologia como meio deentendimento 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 emelhoria contínua). Um processo de atendimento ao cliente, por exemplo, pode sercompletamente migrado para a Internet, ainda que esteja funcionando corretamentena verdade, para minimizar custos e prazos de atendimento, pode até ser mesmodesdobrado (atendimento via Internet para a maioria dos clientes e atendimentotelefônico para exceções), aumentando assim o número de processos (BALDAM etal., 2008, p. 66).
  • 39. 39 De acordo com Baldam (2008, p. 66), algumas atividades emergem deimediato, quando surgem situações como novos marcos, problemas de produção ouqualidade, impedindo entrega ao cliente, concorrência que lança produtos maiscompetitivos etc. Ainda que a necessidade desses processos não tenha sidodetectada no Planejamento Estratégico anual (o que não quer dizer que não estejamalinhados 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ãoexecutadas. Os processos serão testados pelos usuários, que indicarão os impactospositivos e negativos da implementação desses. Burlton (apud BALDAM et al., 2008, p. 94) sugere as seguintes atividadespara 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 quesuportará o novo processo e a implantação e configuração das aplicações externas
  • 40. 40que interagem com o processo. Um BPMS é responsável por manter os contextosde execução dos processos, que inclui a atividade que está em execução, valoresde variáveis, contextos de sub-processos, logs. Ele deve facilitar a integração comum 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, essesdados são comparados e utilizados para montar indicadores gerais que permitemavaliar o processo. Algumas técnicas e tecnologias aplicáveis ao controle e análisedos dados de instâncias de processos, tais como BSC, BI, permitem uma melhorvisão do desempenho geral e apontam se a organização está alcançando seusobjetivos ou se é necessário efetuar ajustes nos processos, nas metas ou mesmo naestratégia da organização. Na fase de análise, a medida do desempenho do processo provê informaçõesde melhorias operacionais. A partir de uma visão “fim-a-fim” do processo é possívelfazer 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 ossistemas BAM (Business Activity Monitoring), onde os processos são instrumentadoscom sensores para monitorar suas atividades e variáveis. Um dashboard permite amonitoração, análise e respostas aos eventos e às exceções que ocorrem em temporeal. Normalmente, após o desenvolvimento de aplicações e de sua implantação eexecução em ambiente de produção, pouco suporte é dado ao negócio para avaliarse a solução implementada foi adequada ou se há potencial para melhoresresultados. 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 comportamentodos processos e identifique falhas e oportunidades. Podemos categorizar essa monitoração dos processos sob dois aspectos:
  • 41. 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 emexecução, a qual normalmente é mantida em banco de dados do mecanismo deexecução de processos. A figura 5 mostra duas instâncias de um processo sendomonitorados pela ferramenta WebSphere Business Monitor da IBM. Nestaferramenta podemos definir quais campos devem ser mostrados, o critério paraordenação das linhas, e filtros, baseados em dados de negócio, para selecionarapenas 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. 42 Já a monitoração analítica é normalmente baseada na análise de eventosgerados e armazenados pelo mecanismo de execução. A solução da IBManteriormente mencionada, por exemplo, de tempos em tempos copia os registrosde eventos para uma base de dados especializada em pesquisas analíticas (que fazuso de conceitos associados a “Data Warehouse”, como cubos) de forma a permitirconsultas sofisticadas e pesadas sem prejudicar o desempenho do ambiente deexecução de processos. Com base nos eventos, são gerados os KPI (“Key Performance Indicators” ouIndicadores Chaves de Desempenho) e os totais (métricas) escolhidos no momentode projeto dos fluxos. Os KPIs devem ser cuidadosamente escolhidos, pois devemrefletir os objetivos do negócio mais relevantes para o sucesso da empresa, edevem permitir a identificação antecipada de problemas, possibilitando açõescorretivas. A figura 6 mostra dois KPI definidos para um processo (percentual deaprovação e duração do processo). Aos KPI são associados limites, de forma queseja facilitada a identificação de inconformidades. No exemplo, o processo foiplanejado para durar no máximo três dias, mas em ambiente real está levando maisde três dias e 4 horas. Figura 6 – Analisando os KPIs (Indicadores Chave de Desempenho). Fonte: BENEDETE (2007, p.37).
  • 43. 43 No processo exemplo “aprovação de gastos de viagem”, pode-se definir comoKPIs o custo total do processo, a duração, o percentual aprovado, e o percentual deaprovações realizadas pela diretoria. Outra possibilidade é a criação de consoles de monitoração, através daescolha e demonstração de um conjunto de indicadores em formato gráfico, comomostrado na figura 7. Desta maneira, fica visualmente fácil e rápido acompanhar odesempenho 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 diversasdimensões (por exemplo, pelo percentual de aprovação em um determinado períodode tempo, ou por um departamento em específico). A figura 8 mostra um exemplo derelatório, onde diversos totais são categorizados pela dimensão localidade.
  • 44. 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 doambiente de negócios de acordo com as exigências e que atenda a demandacrescente por melhores produtos e serviços é indispensável nos dias de hoje.Existem atualmente, uma maior complexidade e necessidade de regulamentaçãodos ambientes de negócio como jamais existiu, e a previsão é para que haja umaumento gradativo e contínuo destas características. Estas características, quandocorretamente aplicadas, agregam valor às empresas, influenciando também o modocomo os diretores e analistas de negócios visualizam e gerenciam a organização asrespectivas á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. 45 Baldam (2008, p. 135), afirma ainda que, se não tratarmos seriamente o bomgerenciamento, este fator acarretará prejuízos no mercado e até mesmopenalidades junto aos órgãos financeiros e legislativos. No entanto, como citadoacima, o bom gerenciamento é alcançado com regulamentações variadas etransformações no ambiente de negócios consideradas complexas. Para alcançar aexcelência da conformidade, é necessário realizar o levantamento de práticas queobtiveram sucesso nas determinadas áreas que se pretende aplicar as adequações. Como as organizações são sistemas semi-abertos, que interagem com omeio-ambiente, um autogerenciamento visa garantir que os aspectos relacionados aregulamentações sejam corretamente tratados. Para tanto, a conformidade é ocomponente utilizado para este gerenciamento e pode ser definido como adequaçãoa 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 BALDAMet al., 2008, p. 135).2.4 Sistemas de Gestão de Processos de Negócio (BPMS) Business Process Management Systems (BPMSs) foram introduzidos com oobjetivo de prover controle para definir e coordenar a execução de processos denegócio (GARCIA e TOLEDO apud SOUZA, 2008, p. 28). Os BPMS´s são sistemas integrados que permitem a operacionalização defluxos de processos de negócio, automatizando a execução, controle emonitoramento desses processos. Um BPMS deve possuir ferramentas quepermitam a modelagem, a execução e orquestração de processos e também devepossuir ferramentas de análise e monitoramento. Os sistemas de gestão de processos são plataformas que orquestram osprocessos de negócio, junto com todos os sistemas e pessoas envolvidos, dandouma completa visibilidade e controle aos gestores de processos. São, portanto, os
  • 46. 46resultados de processos automatizados e geridos com o uso de ferramentas degestão de processos (ARORA apud SANTOS, 2007, p. 5). “Os sistemas para o gerenciamento de processos (BPMS) são mais que umsistema 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 vidade 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ânciade processo e então, coordena, monitora e registra sua execução. O registro podeser 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ãosistemas de software que definem, criam e gerenciam a execução de workflows, osBPMSs enfatizam processos que cruzam as fronteiras organizacionais e o aspectoda 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 ManagementSystems (BPMSs) foram introduzidos com o objetivo de prover controle para definir ecoordenar 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. 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. 482.5 BPMN e os elementos de BPD A BPMN (Business Process Modeling Notation) é uma notação visual pararepresentação de fluxos de processos que pode ser mapeada para diversosformatos 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 ManagementInitiative) provê uma notação gráfica para representar processos de negócios em umdiagrama, 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 controleque determinam a ordem de execução dessas atividades. Um diagrama de Processos de negócios (BPD) é constituído de um conjuntode elementos gráficos que permitem o desenvolvimento de diagramas simplessemelhantes aos de fluxo utilizados por analistas de negócio. Os elementosutilizados são distintos uns dos outros e utilizam formas também comumenteutilizadas pela maioria dos modeladores. Por exemplo, as atividades sãorepresentadas por retângulos e as decisões por losângulos. A figura 10 demonstraesse exemplo. Figura 10 – Demonstração das Atividades e Decisões Fonte: Adaptada de Reis (2007, p. 07).
  • 49. 492.5.1 Objetos de Fluxo (Flow Objects) Um BPD tem um conjunto de três elementos básicos, conhecidos comoObjetos de Fluxo, para que os modeladores não tenham que aprender e reconhecerum número grande de formas diferentes. A tabela 01 demonstra os três objetos defluxo.
  • 50. 50 Nome Descrição Objeto Um evento é algo que "acontece" no decurso de um processo de negócio. Estes eventos afetam o fluxo do processo e normalmente Tem uma causa disparador () ou um impacto Resultado (). Evento Eventos são círculos com centros abertos para (Event) Permitir indicadores internos para diferenciar diferentes disparadores ou resultados. Existem três tipos de eventos, com base em quando elas afetam o fluxo: Início, Intermediário e Final (tradução do autor). Uma atividade é um termo genérico para o trabalho que a empresa executa. Uma atividade pode ser atômicas ou não-atômica (composta). Os tipos de atividades que fazem parte de umAtividade modelo de processo são: Processo, a sub(Activity) processo, e de tarefas. Tarefas e Sub-processos são retângulos arredondados. Os processos são contidos dentro de uma piscina (pool) (tradução do autor). Um gateway é usado para controlar a divergência e convergência de seqüência de fluxo. Assim, ele Portão vai determinar a ramificação, bifurcação, fusão e(Gateway) junção de caminhos. Interno Marcadores vai indicar o tipo de controle de comportamento (tradução do autor). Tabela 1 – Objetos de Fluxo. Fonte: BPMN (2009).
  • 51. 512.5.2 Objetos de Conexão Os Objetos de Fluxo são conectados em um diagrama para criar a estruturabásica do processo de negócio. Existem três objetos de conexão que possibilitamesta função, conforme mostra tabela 02. Nome Descrição Objeto A seqüência de fluxo é usado para Fluxo de Seqüência mostrar a ordem em que as (Sequence Flow) atividades serão realizadas em um processo (tradução do autor). Um fluxo de mensagens é usado para mostrar o fluxo de mensagens entre dois participantes que estão preparados Fluxo de para enviar e receber. Em BPMN, dois Mensagem Pools separados em um Diagrama (Message Flow) representarão os dois participantes (por exemplo, entidades empresariais ou papéis de negócio) (tradução do autor). Uma associação é usada para associar as informações de Fluxo com objetos. Texto e Gráfico que não são fluxos, os Associação objetos podem ser associados com (Association) Fluxo de Objetos. Um seta sobre a Associação indica uma direção de fluxo (por exemplo, dados), quando for o caso (tradução do autor). Tabela 2 – Objetos de Conexão. Fonte: BPMN (2009).
  • 52. 522.5.3 Raias (Swimlanes) A BPMN usa o conceito conhecido como "swimlanes" para ajudar a partição eorganizar as atividades. Um diagrama de BPMN pode representar mais de umprocesso privado, bem como os processos que mostram a colaboração entre aprocessos privados ou participantes. Em caso afirmativo, em seguida, cadaprocesso de negócio privado será considerado como sendo realizada por diferentesParticipantes. Graficamente, cada participante irá ser particionado; isto é, vai estarcontido 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 Um Pool representa um participante em um processo também atua como uma raia "e um container gráfico para o particionamento de um Pool conjunto de atividades de outros pools, geralmente no contexto de Situações de B2B (tradução do autor). A Lane é uma sub-partição dentro de uma piscina e vai estender a todo o comprimento do interior, quer na Lane vertical ou horizontalmente. Lanes são usadas para organizar e categorizar atividades (tradução do autor). Tabela 3 – Raias (Swimlanes). Fonte: BPMN (2009).
  • 53. 532.5.4 Artefatos Segundo a BPMN os artefatos são usados para fornecer informaçõesadicionais sobre o processo. Existem três artefatos padronizados, mas osModeladores ou ferramentas de modelagem são livres para adicionar muitosartefatos conforme o necessário. É possível que haja esforços da BPMN paraadicionar e padronizar um conjunto maior de artefatos para uso geral ou para osmercados verticais. A tabela 04 mostra o conjunto atual de artefatos que inclui: Nome Descrição Objeto Objetos de dados são considerados Artefatos porque Objeto de não têm qualquer efeito direto sobre a Seqüência de Dados Fluxo de Mensagem ou fluxo do processo, mas eles (Data fazem fornecer informações sobre as atividades que Object) necessitam de ser executada e / ou o que eles produzem (tradução do autor). Um conjunto de atividades que estejam dentro da mesma categoria. Este tipo de agrupamento não afetam a seqüência de fluxo de atividades dentro do grupo. O nome da categoria aparece no diagrama Grupo como o rótulo de grupo. Categorias podem ser (Group) usadas para documentação ou fins de análise. Grupos são uma maneira em que as categorias de objetos podem ser visualmente exibidos dentro do diagrama. Anotação Anotações de Texto é um mecanismo para um (Text modelador de fornecer informações adicionais para o Annotation leitor de um BPMN Diagrama. ) Tabela 4 – Artefatos. Fonte: BPMN (2009).
  • 54. 543. ARQUITETURA ORIENTADA A SERVIÇOS A arquitetura SOA baseia-se em permitir que sistemas corporativosdisponibilizem suas funcionalidades através de serviços que podem ser utilizadospor outros sistemas para a execução de suas tarefas. É importante ressaltar que aArquitetura Orientada a Serviços não é um software. Este termo refere-se a ummodelo de arquitetura de software voltada para a construção de aplicações queimplementam processos de negócio ou serviços utilizando um conjunto decomponentes fracamente acoplados e orquestrados a fim de prover um nível deserviç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 fornecidoslocalmente ou podem estar localizados externamente, os serviços podem serimplementados em qualquer linguagem de programação, plataformas diferentes,tecnologias diversas podem ser utilizadas e o legado de software pode seraproveitado mantendo o principio da interoperabilidade. É uma caracterização desistemas distribuídos, em que as funcionalidades do sistema são expostas viadescrição de uma interface, permitindo a publicação, localização e a invocação pormeio 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. 55 A Arquitetura Orientada a Serviço é capaz de oferecer a infra-estruturatecnológica necessária para que uma aplicação possa ser definida por meio dacomposição de serviços eletrônicos. Dessa forma, oferece apoio à composição deaplicações distribuídas de uma forma flexível e com baixo custo. Em SOA, acomposição de serviços é vista como um processo de negócio dividido emcomponentes 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 quesã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. 563.1 Características da Arquitetura Orientada a Serviços Erl (apud Moreira 2007, p. 19) define SOA como sendo uma tecnologia queadere aos princípios da orientação a serviços. Quando realizados através do uso datecnologia de Web Services, SOA promove esses princípios em todos os processosde negócios e automação de uma corporação. Para a composição de Sistemas de Software compostos por serviços, aArquitetura SOA deve permitir todas as características apresentadas na Tabela 5.
  • 57. 57CARACTERÍSTICA DESCRIÇÃO Este conceito trata de minimizar as dependências entre os serviços,Acoplamento Fraco permitindo assim flexibilidade na mudança das regras de negócio; A lógica de uma regra de negócio deve estar definida e Reusabilidade do disponibilizada como um serviço que pode ser reutilizado por outros Serviço sistemas; Os serviços dispõem de uma especificação para a forma de acessoContrato do Serviço e comunicação. Determina a forma de recebimento e envio de dados aos serviços; A arquitetura SOA promove um alto nível de abstração, Abstração considerando o encapsulamento das regras de negócio em serviços, permitindo que os mesmos sejam reutilizados; Serviços podem ser compostos para formar novos serviços com um nível maior de abstração e provendo funcionalidades agregadas. A Composição flexibilidade na composição de novos serviços a partir de serviços já disponíveis na rede é o grande atrativo da arquitetura (SOUZA, apud OLIVEIRA, 2008, p.66); O encapsulamento de funcionalidades no nível de serviço evoca um alto grau de granularidade nos componentes básicos da arquitetura. Um objeto individual apresenta operações muito finas para prover funcionalidades significativas no nível corporativo. Para oAlta Granularidade desenvolvimento de aplicações complexas e extensas a alta granularidade traz vantagens na medida em que detalhes de implementação são deixados à equipe de desenvolvimento responsável por aquele serviço (SOUZA apud OLIVEIRA, 2008 p.66). Para maior interoperabilidade, SOA promove na implementação de Heterogeneidade serviços a independência de plataforma de desenvolvimento, tecnologias de implementação e linguagens de programação. Os serviços devem ser acessíveis a partir de qualquer lugar e a Ubiqüidade qualquer momento facilitando a composição de serviços entre empresas (SOUZA apud OLIVEIRA, 2008 p.67). Tabela 5 – Principais Características da Arquitetura SOA. Fonte: Adaptada de MIRANDA (2008, p.21).
  • 58. 583.2 Componentes SOA De acordo com a especificação de arquitetura orientada a serviços pelaorganização OASIS, SOA é um paradigma para organização e utilização decompetências distribuídas que estão sob o controle de diferentes domíniosproprietários (OASIS, 2007). Para prover essa organização e utilização, aArquitetura 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 apudMIRANDA, 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 11ilustra uma visão geral da arquitetura SOA. Figura 11 – Componentes da arquitetura SOA. Fonte: MIRANDA (2008, p.26).
  • 59. 593.2.1 Aplicação Frontend Segundo Josuttis (apud Miranda, 2008, p.27) são os elementos ativos deSOA, iniciando e controlando as atividades de um sistema e entregando o resultadodo serviço, interagindo com o usuário. Existem diferentes tipos de AplicaçõesFrontEnd. 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 umserviço. Uma Aplicação Frontend desempenha um papel muito próximo ao Padrãode Projetos Facade (Fachada), onde um objeto disponibiliza uma interface que dáacesso a uma grande quantidade de funcionalidades de um subsistema, abstraídasdo objeto que originou as chamadas. A Figura 12 ilustra um exemplo de AplicaçãoFrontEnd. Figura 12 – Exemplo de Aplicação Frontend. Fonte: MIRANDA (2008, p.27).
  • 60. 603.2.2 Serviços Um Serviço pode ser entendido como uma função do sistema computacionalconstruí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 daArquitetura Orientada a Serviços, pois encapsula uma função de negócio que podeser reutilizável, tendo como características marcantes a independência detecnologias de linguagens de programação em sua implementação e baixoacoplamento. 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 aoacesso ao serviço e uso dos serviços. O contrato impõe semântica sobre as
  • 61. 61funcionalidades e parâmetros do serviço (DAVIES apud MIRANDA, 2008, p. 28). Osserviços também devem disponibilizar Interfaces, que definem as operaçõesdisponíveis em um serviço. As interfaces podem ser entendidas como as assinaturasdos métodos definidos em classes na Orientação a Objetos, onde é descrito o tipode retorno, o nome da operação, sua visibilidade e argumentos. A regra de negócio realizada pelo serviço deve estar contido naImplementação, que proporciona a execução do serviço utilizando a lógica denegócio e os dados necessários. Alem da lógica de negócios e dos dados, fazemparte da Implementação os subprogramas, os dados e arquivos de configuração e abase de dados. SOA promove a idéia de módulos de software que prestam serviços a outrosmódulos, com características e tecnologias diferentes. A concepção de serviço temtrês características principais, conforme mostra a tabela 06.CARACTERÍSTICA DESCRIÇÃO A descrição do serviço através de uma interface, ou seja, Interface como aquele serviço será conhecido e como ele será acessado; Contrato Definição de como se dará esse acesso pela sua interface; Sua implementação, ou seja, a funcionalidade por trás da interface. Atualmente, essa abordagem converge para o Implementação padrão de Web Services. No passado, sistemas empresariais operavam com diferentes tipos de interfaces, projetadas em tecnologias distintas. Tabela 6 – Características da Concepção de Serviços. Fonte: MIRANDA (2008, p.29). ERL (et al., 2008, p.28) identifica três tipos fundamentais de serviços:
  • 62. 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 desoftware que encapsulam alguma funcionalidade de negócios. Como tal, seu ciclo dedesenvolvimento é 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 omodelo 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 desenvolvimentode software pode ser ajustado com as experiências obtidas nas fases anteriores. ATabela 7 apresenta as etapas do ciclo de vida dos serviços bem como a descriçãode cada etapa.
  • 63. 63 ETAPA DESCRIÇÃO A fase de modelagem gera um produto: a especificação da Modelagem interface do serviço. Esta interface inclui a semântica e os atributos não funcionais; Esta é a fase de codificação do serviço, utilizando tecnologiasImplementação como linguagens de programação, protocolos de comunicação e plataformas de desenvolvimento; Fase de adequação dos serviços aos sistemas que farão uso da Integração Arquitetura SOA. É a inserção do serviço no domínio do problema; Fase em que o serviço estará disponível para uma Aplicação Execução FrontEnd ou qualquer outro tipo de consumidor. Tabela 7 - Fases do Ciclo de Vida do Serviço Fonte: MIRANDA (2008, p. 30).3.2.4 Repositório de Serviços Miranda (2008, p. 31) cita ainda que outra estrutura importante dentro daarquitetura SOA é o Repositório de Serviços , que fornece meios para facilitar adescoberta de serviços, bem como, as informações referentes ao serviço. Essasinformações podem variar, podendo informar sobre a localização física, pessoas decontato, informações sobre o fornecedor, utilização de restrições de segurança eníveis do serviço. Geralmente, um Repositório de Serviços está associado ao escopo de umaempresa ou organização. É possível utilizar a arquitetura SOA sem um Repositóriode Serviços. Isso depende da quantidade de serviços disponibilizados a nívelempresarial. Por isso, por mais que uma empresa que esteja adotando SOA nãopossua muitos serviços a serem disponibilizados, é interessante optar pela utilizaçãode um repositório, pois isso trará benefícios em longo prazo (KRAFZIG apudMIRANDA, 2008, p. 31).
  • 64. 643.2.5 Barramento de Serviços Segundo Galdino (apud Miranda, 2008, p.31) o Barramento de Serviçosinterconecta todos os elementos da arquitetura SOA, funcionando como canal decomunicação. Este barramento facilita o compartilhamento de serviços dentro deuma corporação, fornecendo transparência na localização dos serviços. Se duasaplicações precisam se comunicar entre si, uma Aplicação de Frontend invoca asfuncionalidades de um serviço utilizando o Barramento de Serviços. É importantedestacar que o barramento de serviços não é necessariamente composto por umatecnologia, podendo abranger uma grande variedade de soluções tecnológicas. A Tabela 8 descreve as principais características do Barramento de Serviço. CARACTERÍSTICAS DESCRIÇÃO Objetivo principal do Barramento de Serviços. Permite interligar os componentes de uma arquitetura SOA, Conectividade fornecendo facilidades que permitam ao FrontEnd invocar as funcionalidades dos serviços; O Barramento suporta uma gama de tecnologias, o que geralmente é a realidade das empresas, que em sua maioria, adotam por soluções distintas. EssasTecnologias Heterogêneas tecnologias variam desde linguagens de programação, sistemas operacionais, ambientes de execução, middlewares e protocolos de comunicação; Embora a funcionalidade principal do Barramento de Serviços seja a comunicação entre componentes e Serviços Técnicos serviços, o barramento também fornece alguns serviços como auditoria, segurança, transformação de mensagens e transações. Tabela 8 – Características do Barramento de Serviços. Fonte: MIRANDA (2008, p. 32).
  • 65. 653.3 Composição de Serviços Segundo Moreira (2007, p.32.) para solucionar problemas como distribuição eheterogeneidade 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 apossibilidade 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çospara que, juntos, possam atender a requisitos que vão além das suas capacidadesindividuais. Em outras palavras, a composição provê uma abordagem aberta,baseada em padrões, para conectar Web Services objetivando criar processos denegócio de alto nível, com um alto valor agregado. A Figura 14 exemplifica umacomposiçã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 eseqüência de operações. Figura 14 – Composição de Serviços Fonte: MOREIRA (2007, p.33).
  • 66. 66 Os padrões são projetados para reduzir a complexidade requerida paracompor Web Services, reduzindo custo e tempo, e aumentando a eficiência globalnos negócios. De acordo com Moreira (2007, p. 33), a composição de serviços deve atenderas 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çoe/ou o uso de um serviço por outro serviço vai se tornando mais comum, para acriação de processos, para isso dois conceitos são muito importantes: orquestraçãoe coreografia, como visto na figura 15. Figura 15 – Orquestração e Coreografia. Fonte: LEITÃO e MARGALHO JUNIOR (2007, p.25)
  • 67. 673.3.1 Orquestração As interações do processo de negócios são controladas por uma das partesenvolvidas no processo. A orquestração envolve interações entre as partes e ospassos 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 unirprocessos de negócio. Com a orquestração, diferentes processos podem serconectados sem que seja necessário desenvolver novamente as suafuncionalidades em um novo sistema. O uso da orquestração pode reduzirsignificativamente a complexidade de implementação, bem como facilitar amanutençã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 doWeb Service 1 requisitando alguma informação. O coordenador invoca algunsparceiros a fim de agrupar a informação e então retorna o resultado para o WebService 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 decontrole e informação que o segue. A principal técnica de implementação daorquestração é através da linguagem BPEL.
  • 68. 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 ofluxo de controle em uma única unidade. Ao invés de um único coordenador, todosos 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 papeldentro do fluxo. A colaboração é efetuada através da troca de mensagens entre osserviços participantes (MOREIRA, 2007, p. 34). Ao invés de um único coordenador, todos os serviços envolvidos na operaçãoconhecem quando e com quem irão interagir, havendo uma cooperação entre osserviç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 17exemplifica 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. 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ãodadas 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. 703.3.3 BPEL A BPEL foi criada em 2003, inicialmente pela Microsoft em parceria com aIBM, SAP e Sibel, após algum tempo o seu controle de padrão foi passado para aOASIS (Organization for the Advancement of Structured Information Standards). Esta linguagem descreve os processos de negócios e os protocolos denegócios de Web Services, que são tratados por um script baseado em XML quedescrevem a lógica de controle de cada processo e protocolo. Esse script seráinterpretado em uma máquina intermediaria que irá realizar o controle dacomposição. Em sua lógica de negócio que seqüencia, coordena e gerencia acomunicação entre Web Services dentro de uma aplicação de negócio. BPEL éapontado como uma ferramenta fundamental para empresas que queremeconomizar tempo de desenvolvimento, reduzir custos na entrega de novassoluçõ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 dafigura 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 derealizar controles de tratamento de exceções e transações, papéis e parceiros epersistência e variáveis do Web Services que trabalham no entorno dela.
  • 71. 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 dadosXML, recebe mensagens XML assíncronas de serviços remotos e ainda gerenciaeventos e exceções, retornando partes do processo quando essas exceçõesocorrem, tornando os Web Services mais poderosos para quebrar barreirasinvisíveis de integração entre empresas parceiras ou fornecedoras/clientes, sem terproblemas com comunicação. Um processo especificado em BPEL consiste em dois tipos de atividades:atividades básicas apresentadas no Quadro 01 e atividades estruturadasapresentadas no Quadro 02. Estas determinam a estrutura, a seqüência doprocesso, já aquelas determinam o que acontecerá no processo, por exemplo, orecebimento de uma mensagem de um Web Service.
  • 72. 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 aordem em que as atividades devem ser realizadas. Quadro 2 – Atividades Estruturadas de BPEL. Fonte: MOREIRA (2007, p.38).
  • 73. 73 Moreira (2007, p. 36 - 37) cita que o BPEL provê expressões paracomportamentos condicionais, para loops, para declarar variáveis, para copiar eatribuir valores. As especificações baseadas em BPEL utilizam o XML paradescrever aspectos do processo. Os principais elementos de um documento BPEL estão representados naFigura 19. Figura 19 – Estrutura básica de uma especificação BPEL. Fonte: MOREIRA (2007, p.37).
  • 74. 74 A tag partner especifica os participantes da composição. Normalmente, nestelocal são armazenados os endereços dos servidores que estão disponibilizando osWeb Services. Outro recurso utilizado é o de partner links (<partnerLink>), o qualdefine as diferentes partes que interagem com o processo (MOREIRA, 2007, p. 37). A tag variables define as variáveis utilizadas no processo. Essas variáveispodem ser inicializadas, copiadas para outros serviços e até alteradas. As variáveisrepresentam uma grande vantagem do uso deste padrão: a possibilidade dearmazenar estados durante a execução da composição. A tag correlationSets identifica para qual instância de processo uma novamensagem recebida deve ser roteada. Este elemento é também responsável pornão permitir que existam duas interações distintas de Web Services caso elas sejamoriundas do mesmo parceiro. A seção faultHandlers define as atividades que devem ser realizadas emresposta à falhas resultantes da invocação de serviços. Em associação com a tagfaultHandlers, 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 eventosconcorrentemente à execução do processo através do uso da tag eventHandlers.Como exemplo de eventos é possível citar o estouro de tempo de determinadaoperaçã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 programaexecutável, que foi concebida após a disponibilização do projeto e modeladautilizando a linguagem BPEL, desta forma possibilitando uma comunicação entreprocessos independente da linguagem de programação, graças à utilização de XML(ROCHA apud SOUZA, 2008, p.59).
  • 75. 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 oumais regras de negócio. Porém, há mais camadas de abstração envolvidas no usoda Arquitetura Orientada a Serviços como: Camada Corporativa, Camada deProcessos, 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 deabstração.
  • 76. 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 umadeterminada organização ou empresa. Nesta camada estarão os procedimentosrelevantes das atividades de negócios empresariais pertencentes a umadeterminada corporação (MIRANDA, 2008, p. 22).3.4.2 Camada de Processos A camada de processos identifica como alguns processos podem sermodelados e posteriormente implementados como serviços. Nesta camada, utiliza-se referência aos procedimentos necessários para a realização dos negóciosempresariais (MIRANDA, 2008, p. 23).
  • 77. 773.4.3 Camada de Serviços Nesta camada, os serviços são mapeados por suas funcionalidades básicas ede 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. Cadaserviço desta camada pode ser decomposto em vários outros serviços simples quepodem ser implementados utilizando componentes (MIRANDA, 2008, p. 23). É necessário que a orientação a serviços seja propagada por toda acorporação. Isso pode ser alcançado pela abstração das camadas de serviço (ERLapud 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 comoserviços, em uma rede de computadores (Internet ou Intranet), comunicando se porpadrões abertos”. A estrutura da organização pode ser dividida em lógica de negócioe 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. 78 A camada de interface de serviços da organização localiza-se entre ascamadas de processo de negócio e de aplicação. Esta camada pode ser divida emtrê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. 79funcionalidades com uma tecnologia específica. O seu propósito é prover funçõesreusá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 deserviços são serviços utilitários e wrapper. Os serviços dessa camada podem conter
  • 80. 80lógicas de negócio e de aplicação, este modelo é comumente encontrado nossistemas distribuídos atuais, contudo, sua utilização não é recomendada. Ao invésdisso, os serviços de aplicação podem ser facilmente compostos com outrosserviç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çãoutilizada para expressar uma funcionalidade específica, a camada de serviços denegó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 é ilustradana figura 25 (MOREIRA, 2007, p. 29). Esses serviços são a base da arquiteturaorientada 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. 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. 823.4.3.3 Camada de serviço de orquestração Esta camada introduz um nível de abstração que diminui a necessidade dosserviços gerenciarem detalhes de interação para garantir que as operações sejamexecutadas em uma ordem seqüencial correta. Dentro desta camada, os processoscompõ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 umainstâ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 deserviços, que podem englobar uma ou mais rotinas escritas em determinadalinguagem de programação. Esses componentes são mapeados em serviços ou sãomapeados 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, seusatributos e relacionamentos utilizados em componentes para compor os serviços deuma SOA. Em arquiteturas de SOA modernas, serviços são implementadosutilizando os objetos (MIRANDA, 2008, p. 23).
  • 83. 833.5 Ciclo de vida SOA A arquitetura SOA está definida em quatro estágios distintos que compõemseu ciclo de vida. Esses estágios são compostos por etapas que contemplam aestratégia na elaboração de uma solução utilizando a Arquitetura SOA, amodelagem necessária para as regras de negócios, a implementação, quecorresponde à 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. 84 As etapas do ciclo de vida de SOA, bem como suas descrições, conceitos ecaracterí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 ArquiteturaOrientada a Serviços. Neste estágio, são definidas algumas diretrizes para o uso deSOA: as atividades que estarão no escopo da Arquitetura; o foco dos processos emedidas estratégicas com a adoção da Arquitetura Orientada a Serviços. Segundo Erl (2008, p. 300), escolher uma abordagem de entrega é umadecisão crucial, porque representa a escolha com a qual a organização normalmenteterá 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 etempo 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 entreguesbottom-up tendem a ter tempos de vida mais curtos e exigem manutenção erefatoração mais freqüentes.
  • 85. 853.5.1.2 Top-down Erl (2008, p. 299) explica que a estratégia top-down exige mais de uminvestimento inicial porque cria uma etapa de análise positiva, concentrada nacriação do esquema de um inventário de serviços. Uma coleção de candidatos aserviço é individualmente definida como parte desse esquema para assegurar queos designs de serviço subseqüentes sejam altamente normalizados, padronizados ealinhados.3.5.2 Modelagem Segundo Miranda (2008, p. 25) este segundo estágio do Ciclo de Vida SOAcorresponde a modelagem de processos de negócios. Esta modelagem engloba umconjunto de práticas ou tarefas realizadas pelas instituições para descrevervisualmente todos os aspectos de um processo de negócio, incluindo seus principaispontos de decisão para a execução das atividades. Essa descrição visualnormalmente é compreensível pela maioria das pessoas envolvidas nasimplementações dos processos de negócios. Em gestão de TI, esse estágio édenominado de Business Processes Management (Gerenciamento de Processos deNegócios), alternativamente chamado de Business Processes Modeling (Modelagemde Processos de Negócio). A figura 27 demonstra as atividades do ciclo de vidaassociados com os serviços no ambiente SOA.
  • 86. 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, suacodificação em alguma plataforma e linguagem de programação, levando emconsideração as tecnologias de implementação disponíveis e as decisões tomadasnos estágios anteriores quanto a adoção da Arquitetura SOA, tanto nas tomadasestraté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. 87(Monitoramento de Atividade de Negócio), permite que seja feita a análise em temporeal dos dados trafegados em uma rede através do uso de um software que analisaos 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 comoo software vem sendo desenvolvido. Sistemas bem-sucedidos de TI exigem cadavez mais interoperabilidade entre plataformas e serviços flexíveis que possamevoluir facilmente com o tempo. Segundo o Word Wide Web Consortium (W3C), atecnologia de Web Services fornece um mecanismo padrão de interoperabilidadeentre diferentes aplicações de softwares, executando em uma variedade deplataformas ou frameworks (W3C, 2009). É apontado como uma grande vantagem dos Web Services, a utilização debaixo acoplamento entre sistemas e sua interoperabilidade, além de usar padrõesabertos 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. 88 Figura 28 – Arquitetura Web Services Fonte: MOREIRA (2007, p.3) Segundo Sommerville (2003, p.191), os três padrões fundamentais quepossibilitam 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. 894. PROJETO NEW_RCMS: ESTUDO DE CASO O método de pesquisa adotado para a realização deste trabalho foi o estudode caso, com o objetivo de analisar um caso prático de implantação dogerenciamento de processos de negócio em um departamento de Service Desk. Olevantamento de informações utilizado para esse estudo de caso baseou-se emetnografia 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 queatua 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 mercadonacional e internacional. Sua diversificada atuação inclui Outsourcing, centros depesquisas tecnológicos, desenvolvimento de hardware e software e soluções de TI. Os trabalhos de pesquisa junto à empresa consistiram em entrevistas comprofissionais responsáveis pela área de Processos e usuários. Esta área emconjunto com o time de TI, foram os responsáveis pela implantação do BPM naempresa.4.2 Implantação do BPM na organização Para garantir um maior controle e a geração de informações mais confiáveispara o monitoramento de suas atividades, a organização buscou através do
  • 90. 90gerenciamento de seus processos, uma solução estratégica capaz de auxiliar agestão e otimização dos processos de negócio. Analisando a forma como o processo era realizado, é possível identificaralguns 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 externosde hardware, software ou erros humanos, era dificilmente detectada durante aexecução dos processos, desta forma, impactando diretamente a produtividade, ecomo conseqüência perda de SLA (porcentagem de serviço de acordo com ocontrato) e constantes reclamações de seus clientes. O controle e monitoramento dos processos tornam-se falhos devido a poucavisibilidade dos processos, a possível inconsistência de dados como conseqüênciada perda de informações e a dificuldade de automação das métricas. O BPM possibilitou o gerenciamento e a otimização dos processos denegócio, por meio da elaboração de workflows para controle e aprovação deprocessos, 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íveltambé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ãomodelados, simulados e documentados pela área de negócio, com o apoio dosanalistas de negócio e de ferramentas de modelagem, os KPIs são identificadospara posterior gerenciamento dos processos. A área de TI identifica asoportunidades de integração e automação do processo desenhado.
  • 91. 91 Após estas etapas o processo entra em operação, os usuários irão acessar asatividades do processo através de portais via Web. Os processos são executados egerenciados, extraindo-se o histórico e as tendências, que serão utilizadas pelagerência como fonte de informação para auxiliar a tomada de decisão. Através da habilidade de entender como os processos ocorrem, intensifica-sea capacidade de identificar e implantar melhorias importantes para a organização. A utilização da abordagem de arquitetura orientada a serviços como melhorespráticas, garante que os processos implantados estejam flexíveis para possíveismudanç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 nodepartamento de Service Desk, na qual este estudo foi realizado, essa faseapresenta a modelagem de um processo através de uma ferramenta de notaçãoBPM. O processo de negócio escolhido para esta transcrição foi o de “Fluxo deatendimento a chamados”. Com base na coleta de dados feito no Service Desk, foram identificados osprincipais sistemas, aplicativos e base de dados necessários para odesenvolvimento do modelo:
  • 92. 92 SISTEMA DESCRIÇÃO Sistema de gerenciamento de chamados de Hardware (sistema Legado), RCMS utilizados pelos analistas do Service Desk, especialistas e clientes. Sistema de gerenciamento de chamados para Software e Hardware (Sistema RETAIN 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. Link direto com a rede da empresa onde os próprios equipamentos abrem um WEB LINK chamado no RCMS. Os PDA´s possuem uma aplicação desenvolvida em Java que acessa o PDA 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. Repositório de dados informativos do RCMS do Brasil e o tipo de informação IRCM 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 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 LA CCPF 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. 93 A figura 29 apresenta uma visão macro da arquitetura dos sistemas que seintegram e alimentam a base de dados do RCMS para que ele carregue todas asinformações dos clientes (código de cliente, informações de contrato, tipo decontrato, 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 (AsIs). A coleta dos dados ocorreu a partir da interação entre os envolvidos nosprocessos analisados e a equipe responsável pelos processos, através daobservação in-loco e de entrevistas. A partir das informações coletadas, os
  • 94. 94processos começaram a se construídos, utilizou-se nesta etapa uma ferramenta demodelagem de processos baseados na notação gráfica BPMN. O quadro 03descreve 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 emaberto de Hardware ou de Software.2 - Call Dispatch presta o 1º atendimento onde cliente fornece os dados necessários para abertura do chamadopara 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 departamentoresponsável.4 - Caso seja chamado de Software cliente é direcionado para Departamento CAC ADM ou fora do horáriocomercial 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 parasolução do problema, chamado pode ser finalizado ou continuar em aberto caso ainda não tenha sidosolucionado.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 doproblema, 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 diretamenteno sistema, quando apresentam algum problema, se chamado for para hardware é repassado para o técnicocom acionamento via voz, se for de software os analistas de Software são informados pelo Call Dispatch via voze entram em contato com cliente.9 - Se as Informações providas pelo cliente sejam incorretas, chamado poderá ser cancelado pelo analista de
  • 95. 95software 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 informadospelo 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, omesmo 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 pelatransportadora.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 decobertura 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 casofoi a BPMN, já que por meio da utilização dessa notação, é possível ilustrar umprocesso de negócio de forma simplificada e de fácil compreensão. Para amodelagem do processo escolhido foi utilizada a ferramenta BizAgi Process Modelerdesenvolvido pela empresa BizAgi Ltda. A figura 30 ilustra a modelagem no estado atual (As Is), a figura demonstra oprocesso de atendimento, este fluxo ilustra as informações descritas no quadro 03.
  • 96. 96Figura 30 – Processo modelado (As Is). Fonte: do autor.
  • 97. 97 Após o projeto ter sido executado com a modelagem do estado atual (As Is) ea equipe responsável pelos processos ter feito toda a coleta dos dados, essasinformações coletadas foram processadas e originaram um novo modelo comprocessos mais integrados e que agregam maior valor ao negócio. Com a utilização de conceitos SOA o novo modelo integra os principaissistemas utilizados pelos analistas do Service Desk (RCMS, RETAIN, PIMS) em umúnico Frontend. Além da integração foi verificado que alguns clientes registravamum alto número de ocorrências diárias, então foi criado um portal web (WebServices) voltado para esses clientes, dessa forma eles podem abrir chamados viaweb, oferecendo maior comodidade e diminuindo a volumetria de ligações noService Desk. Os técnicos precisavam ligar na URA do Service Desk para atualizar oschamados, agora utilizam uma aplicação desenvolvida em Java pelo PDA queconversa com o sistema RCMS via Web Services. Os técnicos só necessitam ligarna 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 pedidode 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 chamadoem 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 chamadopara 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. 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 departamentoresponsável.5 - Caso seja chamado de Software cliente é direcionado para Departamento CAC ADM ou fora do horáriocomercial 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 parasolução do problema, chamado pode ser finalizado ou continuar em aberto caso ainda não tenha sidosolucionado.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, chamadopode 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 diretamenteno sistema, quando apresentam algum problema, se chamado for para hardware é repassado para o técnico viaPDA, se for de software os analistas de Software monitoram filas de atendimento e entram em contato comcliente.10 - Se as Informações providas pelo cliente sejam incorretas, chamado poderá ser cancelado pelo analista desoftware 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 deatendimento 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 paracobrar uma posição do chamado.12 - Se as Informações providas pelo cliente estiverem incorretas, chamado é cancelado pelo analista desoftware 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 dadoscomo matrícula e um código de segurança que é diferente para cada território, número da peça, quantidade e aemergê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 epodem 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. 99 A figura 31 ilustra a modelagem no estado futuro (To Be), que demonstra oprocesso de atendimento. Este fluxo apresenta as informações descritas no quadro04. Comparando esta modelagem com a anterior podemos ver que há um novo Poolcom a Lane denominada Portal Web, no caso é o portal que foi criado para osclientes que abrem muitos chamados no Service Desk. No Pool dos técnicos podemos ver que algumas das atividades tambémmudaram agora eles recebem avisos dos chamados via PDA, quando algumchamado é atualizado ou quando há um novo chamado, o servidor de mensagensenvia automaticamente uma mensagem de aviso e atualiza no chamado com data ehorário assim que o técnico ler a mensagem.
  • 100. 100Figura 31 – Processo modelado (To Be). Fonte: do autor.
  • 101. 1014.4 Resultados obtidos A partir da implantação do BPM, o departamento responsável pelodesenvolvimento dos processos da empresa obteve uma maior visibilidade,identificando com mais facilidade, as áreas mais relevantes que fazem parte doprocesso 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çãoentre eles e a necessidade de remodelar alguns processos. Identificou-se a maior confiabilidade das informações geradas, as informaçõessão mais confiáveis devido ao maior controle e automação, proporcionada pelasferramentas de gestão de processos. O conhecimento sobre os processos tornou-se mais consistente, asinformações são extraídas em tempo real, facilitando a análise de todos os aspectosdo processo. O controle das informações disponibiliza dados mais atualizados, alémde manter uma base com o histórico das operações de negócios realizadas. Outroaspecto identificado foi à rápida adaptação dos processos as novas condições denegó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 pelosexecutivos do negócio, essas condições especiais representam a chave para odesenvolvimento de indicadores de performance (KPI – Key PerformanceIndicators). Por meio desses indicadores de performance, o departamento conseguiumapear quais eram os horários de maior pico de ligações, quais tipos de skills erammais exigidos em determinados horários, e a gerência com base nessasinformações traçou uma estratégia para baixar a volumetria de ligações, cumprir oSLA 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 noshorários de pico, foi criado um portal via Web para os clientes que mais abriamchamados no departamento, os técnicos que antes precisavam ligar para a URA do
  • 102. 102Service Desk, agora acessam o sistema RCMS via internet (Web Services) com osPDA´s. A figura 32 mostra a tela de um PDA executando o programa para visualizaros chamados. Figura 32 – Interface da aplicação no PDA. Fonte: do autor. Com essas medidas a organização ultrapassou a meta de SLA prevista emcontrato, havendo uma satisfação de mais de 90% de seus clientes. Houve tambémuma economia de cerca de 40% com gastos em telefonia e a volumetria de ligaçõesque antes era de 55 mil caiu para 35 mil ligações mensais.
  • 103. 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 aimplantaçã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. 104 A arquitetura tecnológica da empresa é muito bem estruturada como se podeobservar na figura 33, o mainframe IBM modelo z990 roda as aplicações queprecisam de maior carga de processamento, no caso os principais sistemas daempresa, já as outras aplicações como o DB2 e o sistema de mensagens rodam emservidores RISC que trocam informações com o mainframe, dessa forma todas asinformações são atualizadas em tempo real, caso o cliente queira saber umposicionamento 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é mesmosaber por qual motivo o seu chamado encontra-se pendente, pode-se aindaadicionar informações e registrar reclamações.
  • 105. 1055. CONSIDERAÇÕES FINAIS Este trabalho demonstrou por meio de um estudo bibliográfico o potencial queo BPM possui em termos de agregação de valor aos negócios e que vem sendomuito utilizado como um recurso estratégico em muitas organizações para elevar opotencial competitivo. Apesar das significativas contribuições do BPM, o sucesso da TI e do negócioem se alinharem em busca de uma empresa mais moderna e competitiva nãodepende apenas de ferramentas, tecnologias ou metodologias, isto também estárelacionado ao sistema da organização, porque quanto mais complexo, amplo etendente a mudanças for esse sistema, mais o BPM pode agregar valor, devido aoseu grande potencial de melhorias nos processos. Algumas empresas se diferenciam no mercado por possuírem umconhecimento especial (como utilização de melhores práticas, regras para identificaroportunidades ou classificar clientes) embutido em seus sistemas. Guardarconhecimentos valiosos em um sistema que pode ficar ultrapassado e que dificulte oacesso a eles é um risco. O BPM pode identificar e expor os processos de umamaneira que possam ser facilmente aproveitados e reaproveitados pela empresa. Neste trabalho também foi apresentada uma gestão de processos de negócioque integra a modelagem de processos de negócio e a criação de serviços, atravésde uma arquitetura orientada a serviços. Neste caso, esses serviços em SOA devemser gerenciáveis para que possam ser controlados por um sistema externo degerência de processos de negócio. Nesse ponto, o SOA se propõe como solução deTI para o BPM. A partir da pesquisa realizada, nota-se que alguns mecanismos facilitam aintegração entre as notações BPMN e BPEL. Isto permite, por exemplo, oreaproveitamento dos modelos desenvolvidos anteriormente na plataforma de umaempresa que utiliza Web Services para a comunicação entre os seus sistemas eclientes, por meio da aplicação da orquestração de serviços, distribuídos emcamadas dentro da Arquitetura Orientada a Serviço a fim de aumentar areusabilidade, interoperabilidade e flexibilidade de seus sistemas.
  • 106. 106 A gestão de processo torna possível a aproximação da área de TI com a áreade negócios, de modo a permitir não somente a comunicação entre eles, mastambém que esses interajam de forma mais efetiva disponibilizando uma visãoabrangente dos processos da organização. No estudo de caso, foi realizado um modelo para representação de umprocesso de negócio de uma organização que atua no mercado de Outsourcing eprestaçã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 serviude base, para treinamento, discussão entre equipes e setores correlacionados sobreas atividades realizadas, padronização e melhorias dos processos, como tambémcriar metas e controles de melhorias e eliminar retrabalho, burocracia e custosdesnecessários, possibilitando desta forma dar apoio efetivo à implementação desistemas de gerenciamento, melhorando a comunicação entre equipe de Tecnologiae Informação e não-especialistas. Após toda esta discussão entre os departamentoscorrelacionados, as equipes e o time de TI construíram um modelo de estado Futuro(To Be), sendo este implementado na organização.
  • 107. 107REFERÊNCIASAALST, 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 automaticadaption of heterogeneous WSDL descriptions. 2006. 70f. Dissertação (Ciênciada 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óciopara apoiar a especificação de requisitos de um sistema. In: SIMPÓSIOINTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6., 2004, SãoPaulo. Anais... São Paulo: SIMPROS, 2004.BALDAM, R. Gerenciamento de processos de negócios. BPM – BusinessProcess Management. 2. ed. São Paulo: Érica, 2008. 240 p.BENEDETE, A. C. Roteiro para a definição de uma arquitetura SOA utilizandoBPM. 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 8de maio 2008.CUBILLOS, J. A. Composición Semántica de Servicios Web. Grupo deEngenharia Telemática, Universidade de Cauca, Colômbia, 2004.CUMMINS, F. A. Integração de sistemas. EAI – Enterprise ApplicationIntegration. Arquitetura para integração de sistemas e aplicaçõescorportativas. 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 HallBrasil, 2009.FANTINATO, M; TOLEDO, M. B. F. de; GIMENES, I. M. S. Web Service E-contract
  • 108. 108Establishment Using Features. In: INTERNATIONAL CONFERENCE ONBUSINESS 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 processmanagement systems. In: IADIS WWW/Internet, 2007, Vila Real: IADIS Press,2007.GU, Qing; LAGO, Patricia. A stakeholder-driven Service Life Cycle Model forSOA. IN: IW-SOSWE´07, Dubrovnik, Croacia, 2007.HOLLINGSWORTH, D. Workflow Management Coalition: the workflow referencemodel. Jan. 15, 1995.JESTON, John; NELIS, Johan. Business Process Management: practicalguidelines 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 deNegó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 ProcessManagement 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 paraimplementaçã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 desoftware, Belém, 2008.LEYMANN, F.; ROLLER, D.; SCHMIDT, T. M. Web Services and BusinessProcess 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 deGroup 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 etecnologia – CCET Curso de Bacharelado em Ciência da computação, Belém, 2008.
  • 109. 109MOREIRA, Leo S. Aplicando Composição e Orquestração de Serviços naOrganização de Sistemas. 2007. 68f. Monografia (Graduação) – GerênciaEducacional de Tecnologia da Informação, Centro Federal de Educação Tecnológicado 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) nasOrganizações. 2008. 100f. Trabalho de conclusão de curso (tecnólogo) Faculdadede tecnologia da zona leste, São Paulo, 2008.PAK, A. F. M. Ferramentas para a Gestão de Mudanças do Modelo ITIL Aplicadoa 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. EstudoConceitual sobre BPMS. 2009. 19f. Relatórios técnicos do departamento deinformática aplicada da UNIRIO – Universidade Federal do estado do Rio de JaneiroCentro 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ãoBPMS: Sistemas de Suporte às tarefas para a gestão de processos. In: XXVIIEncontro Nacional de Engenharia de Produção, ABEPRO, Foz do Iguaçu, PR, 2007SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Addison Wesley,2003.SOUZA, A. C. R. A importância do business process management (BPM) nasempresas 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 OrientedArchitecture and Business Process Choreography in an Order ManagementScenario: Rationale, Concepts, Lessons Learned. San Diego, California,USA.2005.
  • 110. 110 GLOSSÁRIOBalanced 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áticasa partir de um estudo de como outras organizações desempenham essas mesmasoperações.Business Activity Monitoring - Ferramentas de monitoramento em tempo real dasoperações de uma organização e de seus impactos sobre os resultados donegó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ãoe tomada de decisão.Business Process Management Initiative - Órgão que padroniza a gestão deprocessos de negócios.Business Process Management System – Ambiente integrado de componentesde software que automatizam o ciclo de vida de processos de negócios, desde a suaconcepçã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 decompreender os seus processos internos em uma notação gráfica e habilita acomunicação desses procedimentos de uma forma padrão.Drag-and-drop – Conceito de clicar e arrastar, recurso utilizado nas ferramentasgráficas.Dashboard - Representa uma janela da interface de operação contendo um painelde controle com os principais indicadores de desempenho dos processosgerenciados.Fast Analysis Solution Technique - É uma ferramenta de melhoria de processoslançada pela IBM e postriormente aperfeiçoada por outras corporações e empresasde consultoria.Joint Application Development - Técnica de levantamento de dados que traz osusuários para o desenvolvimento do processo como participantes ativos.Key Performance Indicators – Sua finalidade é medir qualquer etapa de umprocesso ou resultado, não estão limitados apenas às conhecidas métricasfinanceiras, a comparação dos indicadores pode apontar o caminho para aconclusão dos objetivos estratégicos da empresa.
  • 111. 111Service Level Agreement – Contrato onde é feito um acordo de nível de serviçoentre um fornecedor de serviços de TI e um cliente especificando, em geral emtermos 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, aURA é um microcomputador convencional, ao qual se agrega um hardwareespecí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 aatender 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 seupotencial pleno (www.w3c.br).Visita in-loco - Palavra que vem do latim que significa “no lugar”. Investigaçãorealizada no local da pesquisa.