Outsourcing Dinâmico e Distribuído

Transcrição

1 Outsourcing Dinâmico e Distribuído Rui Miguel de Campos Martins Borges Maurício Dissertação para obtenção do Grau de Mestre em Engenharia de Redes de Comunicações Júri Presidente: Orientador: Vogais: Professor Doutor Rui Jorge Morais Tomaz Valadas Professor Doutor José Carlos Martins Delgado Professor Rui António dos Santos Cruz Setembro de 2009

2 Agradecimentos Ao longo da vida e deste trabalho em particular, muitas pessoas me ensinaram algo. A essas pessoas quero deixar umas palavras de gratidão. Os primeiros agradecimentos vão para os meus pais, Amílcar Fernando Maurício e Ana Bela Maurício, pelo apoio, motivação, exemplo e paciência. Um agradecimento especial ao Professor Doutor José Delgado pelo apoio contínuo desde o início da tese, pelas inúmeras reuniões e sessões de esclarecimento, pela sua visão crítica, pela sua disponibilidade em me receber e pela excelência da sua orientação. A toda a minha família por toda a solidariedade demonstrada, Aos meus companheiros de curso, por todas as aventuras e experiências partilhadas, A todas as pessoas que, directa ou indirectamente, me auxiliaram durante a elaboração desta tese, Muito obrigado a todos! ii

3 Resumo Este trabalho tem como principal foco a definição de uma metodologia capaz de suportar o outsourcing de forma dinâmica e distribuída. Permitindo assim, uma parte variável de um serviço a ser concebido in-house e dinamicamente atribuir a restante parte do serviço a um ou mais fornecedores (através de balanceamento de carga). Para tal, realizou-se uma abordagem no intuito de identificar e implementar os requisitos necessários para suportar de forma ubíqua a integração e interacção das práticas do outsourcing na cadeia de valor das várias entidades organizacionais, bem como o delineamento dos mecanismos necessários para a sua execução em situações de disaster recovery num regime de Service-on-Demand. Deste estudo, deverá resultar uma metodologia definida e estabelecida com o intuito de realçar o que melhor se pratica no outsourcing clássico com um modelo que suporte o fornecimento de serviços. Como resultado obtém-se o outsourcing dinâmico e distribuído, uma solução estratégica e adaptativa para as organizações que usufruem de um serviço ou de uma matéria-prima para conceber um serviço destinado aos consumidores. É através desta união de paradigmas entre Outsourcing e Fornecimento de Serviços que se permite trazer a mais-valia com a adopção deste modelo de serviços no seio empresarial. Este fluxo inter-organizacional, em soluções actuais torna-se complexo e com pouco significado numa relação custo/benefício. Num modelo de serviços unificado, esta prática é passível de ser executada com simplicidade tanto na óptica do(s) Fornecedor(es), como do(s) Cliente(s) (consumidor(es) do Serviço Final) e da entidade Outsourcer (entidade esta que recorre ao outsourcing para produzir o serviço final). Palavras-chave Outsourcing Dinâmico e Distribuído, Modelo de Serviços Unificado (usil), Risco, Modelo de Referência, Capacidade, Disponibilidade, Relações Inter-Organizacionais, Serviços, Arquitectura Orientada aos Serviços. iii

4 Abstract The goal of this dissertation is to analyze and define a methodology that is able to support dynamic and distributed outsourcing: allowing a part of a service to be designed in-house while the remainder is delegated to one or more external suppliers (through load-balancing techniques). As such, a process was designed to identify and implement the necessary requisites to ubiquitously support the integration and interaction of outsourcing between the entities that are part of a supply chain. Additionally, pre-requisites of a number of mechanisms were defined to allow disaster recovery situations on a service-on-demand business environment. This study should lead to a methodology defined and established in order to highlight what best practices in classic outsourcing exists that supports the services delivery model. As a result we obtain the dynamic and distributed outsourcing, an adaptive and strategic solution for organizations that receive a service or a commodity to design a service for consumers. It s through this union of paradigms between outsourcing and service delivery that allows bringing an "added value" with the adoption of this model of services in organizational environment. This inter-organizational flow, in current solutions is a complex and with low meaning in a cost/benefit relation. With an unified services model, this practice is liable to be executed with simplicity and emphasis not only on the suppliers point of view, but as well as on the Client (Consumer of the Final-Service) and the Outsourcer entity (entity that relies on outsourcing to produce the Final-Service). Keywords Dynamic and Distributed Outsourcing, Unified Services Implementation Language (usil), Risk, Reference Model, Capacity, Availability, Inter-organizational Relationships, Service-Oriented Architecture (SOA). iv

5 Índice Agradecimentos.... ii Resumo..... iii Palavras-chave iii Abstract... iv Keywords iv Índice.. v Lista de Tabelas. viii Lista de Figuras... ix Acrónimos xi Capítulo 1 Introdução Motivação e Enquadramento Objectivos Cenário (Requisitos) Contribuição Estrutura do Documento Capítulo 2 Estado da Arte (Outsourcing Clássico + Gestão e Fornecimento de Serviços) Outsourcing Clássico Gestão Estratégica no Outsourcing Modelo de Maturidade do Mercado de Outsourcing Gestão de Risco Service-Level-Agreement (SLA) Gestão e Fornecimento de Serviços Gestão de Serviços IT Boas-Práticas e Modelos Six Sigma ISO/IEC 17799: Control Objectives for Information and related Technology (CobIT) enhanced Telecom Operations Map (etom) Information Technology Infrastructure Library (ITIL) v Supply-Chain Operations Reference (SCOR) Service-Oriented Architecture (SOA) Cloud Computing Tecnologias no Fornecimento de Serviços Web-Services (WS) Extensible Markup Language (XML). 31 v

6 Simple Object Access Protocol (SOAP) Representational State Transfer (REST) Conclusões Capítulo 3 - Trabalho Relacionado (unified Service Implementation Language) Visão Princípios Estrutura Unified Services Framework Conclusões.. 38 Capítulo 4 Metodologia Introdução Fase de Concepção de Serviços Estágio de Estratégia dos Serviços Definição da Estratégia Gestão da Procura de Mercado Gestão de Risco Aplicação no Modelo de Referência Estágio de Design de Serviço Gestão de Service Agreements Gestão de Capacidade Gestão de Fornecedores Gestão de Risco Aplicação no Modelo de Referência Fase de Implementação de Serviços Estágio de Pré-Produção e Implementação de Serviço Gestão do Conhecimento Gestão de Alterações Gestão de Riscos Aplicação no Modelo de Referência Fase de Operação de Serviços Estágio de Operação Gestão de Eventos Gestão de Incidentes Gestão de Problemas Gestão de Riscos Aplicação no Modelo de Referência Conclusões. 74 vi

7 Capítulo 5 Validação do Conceito (Proof-of-Concept).,,,,, Caso de Estudo Conclusões Capítulo 6 Conclusões e Trabalho Futuro Conclusões Trabalho Futuro,,,,,,, Capítulo 7 Referências. 85 Anexo A Metodologia de Outsourcing Dinâmico Anexo B Diagrama de Fluxo no estágio de Estratégia dos Serviços Anexo C Diagrama de Fluxo no estágio de Design dos Serviços Anexo D Mapa Conceptual para a Gestão de Risco Anexo E Anexo de Boas-Práticas. 97 Anexo E.1 - ISO Anexo E.2 - CobIT Anexo E.3 - etom Anexo E.4 - SCOR vii

8 Lista de Tabelas Tabela 1 - Outsourcing de SI...3 Tabela 2 - Comparação entre Web-Service s e REST Tabela 3 - Fases e Estágios do ciclo de vida de cada versão do serviço Tabela 4 - Factores Internos e Externos considerados para uma Avaliação Estratégica Tabela 5 - Categorização dos Riscos Tabela 6 - Tabela de Classificação do Impacto Tabela 7 - Tabela de Classificação da Urgência viii

9 Lista de Figuras Figura 1 - Modelo de maturidade do mercado outsourcing Figura 2 - SLA com estrutura baseado no serviço Figura 3 - SLA com estrutura baseado no cliente Figura 4 - SLA com estrutura multi-nível Figura 5 - Modelo do CobIT e dos seus principais domínios de aplicação Figura 6 - Mapa de Processos da framework etom Figura 7 - Modelo organizacional de alto nível dos cinco processos do SCOR Figura 8 - Colaborações SOA Figura 9 - Protocolo SOAP Figura 10 - Modelo UML simplificado de uma sociedade de serviços Figura 11 - Fluxograma Conceptual da Cadeia de Estágios do Ciclo de Vida de um Serviço Figura 12 - Modelo de Referência Figura 13 - Fase de Concepção Figura 14 - Fase de Implementação Figura 15 - Fase de Produção Figura 16 - Influência das Actividades de Negócio da entidade organizacional nos padrões de procura dos Serviços Figura 17 - Etapas da Gestão e Análise do Risco no usil Figura 18 - Cenário 1 do Estágio de Estratégia Figura 19 - Cenário 2 do Estágio de Estratégia Figura 20 - Conteúdo de um Service-Agreement Figura 21 - Balanceamento de Carga em regime de outsourcing Figura 22 - Intervenção Pró-activa e Reactiva da Gestão de Capacidade Figura 23 - Relações de Valor e Risco das várias classes de fornecedores Figura 24 - Timer comum ao Cenário 1 e 2 do Estágio de Design Figura 25 - Cenário 1 do Estágio de Design (Simulação de Gestão de Capacidade de natureza Pró- Activa) Figura 26 - Cenário 2 do Estágio de Design (Simulação de Gestão de Capacidade de natureza Reactiva) Figura 27 - Supplier Contract Database Figura 28 - Âmbito da Gestão de Alterações no Fornecimento de serviços num ambiente de outsourcing dinâmico e distribuído Figura 29 Cenário 1 do Estágio de Implementação (Knowledge Management Database) Figura 30 - Cenário 2 do Estágio de Implementação (Fase Inicial) Figura 31 - Cenário 2 do Estágio de Implementação (Final) Figura 32 - Visão Interna Vs. Visão Externa do Negócio Figura 33 - Estabilidade Vs. Tempo de Resposta ix

10 Figura 34 - Qualidade de Serviço Vs. Custo de Serviço Figura 35 - Actividades Reactivas Vs. Actividade Pró-activas Figura 36 - Medidas de Disponibilidade Figura 37 - Cenário Geral do Estágio de Operação (entre Eventos e Incidentes com a Gestão de Problemas e Gestão Alterações) Figura 38 Visão da Entidade Cliente Figura 39 - Cenário de Activação dos sub-serviços do Marca Plano de Viagem Turística Figura 40 - Cenário de Falha do Fornecedor Hotel Figura 41 - Cenário de Falha do Fornecedor Rent-A-Car X Figura 42 - Cenário de Falha do Fornecedor Agência 80 x

11 Acrónimos API CEO CFO CIO CTO COBIT etom FTP HTTP IEC ISO ISP IT ITIL KMBD KPI MSP MTBF MTBI MTTR OLA REST RCP SA SaaS SCD SCOR SIL Application Programming Interface Chief Executive Officer Chief Financial Officer Chief Information Officer Chief Technology Officer Control Objectives for Information and related Technology Enhanced Telecom Operations Map File Transfer Protocol HyperText Transfer Protocol International Electrotechnical Commission International Organization Standardization Internet Service Provider Information Technology Information Technology Implementation Library Knowledge Management Database Key-Perfomance Indicator Managed Service Providers Mean Time between Failure Mean Time between Incidents Mean Time to Repair Operational-Level-Agreement Representational State Transfer Remote Call Procedure Service-Agreement Software as a Service Supplier and Contracts Database Supply Chain Operations Reference unified Service Implementation Language xi

12 SLA SLR SOA SOAP SOD SOX UDDI USF usil WS WSDL XML Service-Level-Agreement Service-Level-Requirements Service-Oriented-Architecture Simple Object Access Protocol Service-On-Demand Sarbanes-Oxley Act Universal Description Discovery and Integration Unified Services Framework Unified Service Implementation Language Web-Services Web-Services Description Language extensible Markup Language xii

13 xiii

14 1. Introdução Motivação e Enquadramento 2 Objectivos.. 4 Cenário (Requisitos)... 4 Contribuição... 6 Estrutura do Documento

15 It is not the strongest of the species that survives, nor the most intelligent. It is the one that is the most adaptable to change. Charles Darwin 1.1. Motivação e Enquadramento Independentemente da tendência política de um país, convicção pessoal e cultural de uma organização ou até da oportunidade económica que envolve, o outsourcing, está constantemente a se suceder, crescendo rapidamente ao longo dos sectores industriais. Inicialmente, apesar de ter sido introduzido de forma radical nas empresas para serviços como Help-Desk e Call-Center, o conceito e a aplicação de outsourcing pode ser verificada nas diversas áreas, tais como na extracção de matéria-prima, área financeira e até na área da saúde. Em contrapartida, as entidades tecnológicas abriram portas para que o outsourcing fosse tratado como um componente integral do negócio dessa empresa. Não é portanto de espantar que o outsourcing afecte as rotinas e metodologias praticadas nas organizações e que se tenha tornado um tópico bastante popular desde inícios da década de 90. No entanto, uma das principais ambiguidades que existem em volta da estratégia adoptada a nível organizacional para a prática de outsourcing, é esta ser orientada à redução de custos, quando, segundo dados estatísticos internacionais [26][23], o que é garantido na prática de outsourcing, é um crescimento económico, não forçando realmente a que exista uma redução nos custos operacionais das empresas. Com este argumento, fica implícito que o principal objectivo que levará uma entidade empresarial a praticar o outsourcing não deverá ser focado na obtenção de redução de custos, mas sim na especialização e melhoramento do serviço que pretende fornecer ao cliente, trazendo consequentemente um grau de reconhecimento por competência e um posterior aumento de níveis de fidelização desses mesmos clientes, com a consequente mais-valia. Adicionalmente, a longo prazo, poder-se-á obter uma redução de custos, mas não deverá ser este o mote que decidirá a prática do outsourcing dinâmico e distribuído. No que toca à real essência dos serviços, segundo Jobber[13], podemos e devemos definir um serviço como: Qualquer acto ou desempenho que uma entidade possa oferecer a outra, sendo este essencialmente intangível e que não resulte na propriedade de algo, não podendo portanto vincular a sua produção a um produto físico. O cerne desta definição é que: um output seja um serviço, independentemente do modo como esse output é gerado. Isto implica que os meios de produção dos serviços podem mudar de forma flexível desde que o resultado final seja, no mínimo, satisfatório. 2

16 Na Tabela 1, são apresentadas as várias definições e referências atribuídas ao outsourcing, por especialistas de sistemas de informação: Autor Definição Loh & Venkatram [1992] [16].. uma contribuição significativa proveniente do fornecedor externo de recursos humanos e/ou físicos podendo estes estar associados ao todo ou apenas a uma componente específica da organização. Lacity & Hirschheim [1993] [18]... a prática de adquirir um bem ou um serviço que tenha sido previamente fornecido internamente. Fitzgerald & Willcocks [1994] [11]... o pagamento à comissão a uma parte terceira para a gestão de recursos de IT, pessoas e/ou de actividades e alcance dos resultados esperados. Chaudhury et. al. [1995] [34] o contracto de sub-funções dos sistemas de informação dos fornecedores aos sistemas de informação dos clientes. Cheon et. al. [1995] [6] a decisão organizacional de deixar uma parte ou a totalidade de uma secção da empresa ao controlo de fornecedores externos permitindo assim à organização atingir os seus objectivos. Hu & Saunders [1997] [22] a prática de negócio em que uma empresa contracta na totalidade ou parcialmente, as operações dos sistemas de informação a um ou mais fornecedores externos desses serviços Kern [1997] [15] a decisão tomada por uma organização em fornecer pessoas, bens, sistemas IT para uma empresa terceira que em troca, gere esses serviços, obtendo retornos monetários durante um determinado período de tempo. Willcocks & Kern [1999] [17], [25], [28] o provisionamento de produtos de IT e serviços a uma organização terceira. Tabela 1 - Outsourcing de SI 3

17 1.2. Objectivos Como primeira etapa, dever-se-á considerar a existência de um nicho de empresas que utilizem um modelo de serviços unificado, tanto para o desenvolvimento de aplicações que permitam o fornecimento dos variados serviços aos clientes (baixo-nível), como para o estabelecimento de processos de negócio e monitorização dos workflows intra e inter-organizacionais (alto-nível). A estratégia sobre outsourcing de serviços, deverá despertar os pontos fortes de uma organização para afinar as suas competências core. Cada componente deverá reforçar o outro e se algum desses componentes é fornecido exteriormente, deverá surgir um modelo capaz de suportar o desempenho e a comunicação das organizações. Assim, tal como as organizações procuram esse melhoramento de desempenho, deverão também considerar quais são as suas verdadeiras e essenciais competências para depois decidir como e quando deverão ampliar as suas capacidades, através de parcerias em áreas que não sejam as suas especialidades. É nesta visão que se considera como principal objectivo deste trabalho, definir uma metodologia capaz de suportar práticas de outsourcing, num modelo de serviços unificados. Considera-se que este outsourcing possui as capacidades de ser distribuído, uma vez que permite a distribuição da concepção de partes de um Serviço-Final a vários fornecedores. A capacidade de se tornar dinâmico, deve-se à sua inclusão de forma simples numa cadeia de fornecimento de serviços em fluxos interorganizacionais permitindo um balanceamento de carga entre estas entidades envolvidas. Após esta interiorização, será descrito o cenário em que este tipo de outsourcing dinâmico e distribuído poderá funcionar de forma realmente dinâmica e distribuída, nomeadamente, os requisitos tanto funcionais como não-funcionais para se considerar realmente plausível a existência desse nicho de organizações capazes de assimilar e recorrer ao outsourcing dinâmico e distribuído Cenário (Requisitos) Para que o mundo organizacional esteja apto para suportar este dinamismo ao nível do outsourcing, é necessário elaborar um levantamento dos requisitos necessários para tornar a solução de outsourcing dinâmico e distribuído exequível. Sabendo que existe a liberdade para manipular a interface tanto do lado cliente como do lado fornecedor à luz do modelo definido, serão nomeados os principais problemas, e como esses deverão ser resolvidos ou evitados. Assim, esta envolvente organizacional em que se adquire ou se executa um serviço à medida das circunstâncias poderá ser apelidada de Service-on-Demand (SOD). Em regime de SOD é exigido uma envolvente de concepção, montagem e orquestração de serviços dinâmicos, com uma framework de integração entre o outsourcer e os seus potenciais fornecedores. Os principais requisitos cruciais de resolver, tanto para assegurar um constante dinamismo e flexibilidade no processo de outsourcing, como para garantir uma sustentabilidade nas organizações, são: 4

18 1. Integração - Sabendo que se quer obter algo por outsourcing, é necessário implementar uma Application Programming Interface (API) electrónica capaz de ser inquestionavelmente integrável tanto do lado do(s) fornecedor(es) como do outsourcer que trata da criação do serviço final. Adicionalmente, o cliente também deverá obter o serviço final não necessitando de se questionar qual o fornecedor de outsourcing que está funcional, e se é só um fornecedor ou são vários. É portanto, necessário partir do princípio que se consegue automatizar grande parte dos processos organizacionais nesta situação ideal, propícia para o acto de outsourcing dinâmico e distribuído. 2. Plano-B (Disaster-Recovery) - Um dos principais factores que resulta no fracasso da prática do outsourcing, (criando algum cepticismo por parte das empresas na entrega de uma parte do negócio a outra entidade com ferramentas e/ou pessoal qualificado para essas tarefas), devese à inexistência de mecanismos no outsourcing clássico que deverão ser activados em situações de desastre. Apesar da existência de Service-Level-Agreement s (SLA s) com o intuito de focar os aspectos para a gestão de problemas, estes apenas estão definidos para reagir quando o fluxo dos serviços está a afectar o fornecimento do Serviço-Final diante do Cliente-Final. Esta problemática terá de ser cuidada e resolvida por todas as entidades envolvidas. Por isso mesmo, não deverá ser unicamente a entidade outsourcer a estabelecer uma completa e dinâmica metodologia capaz de trazer um constante alinhamento e sincronização à concepção dos Serviços, mas sim essa metodologia pertencer a um modelo unificado de serviços, partilhado entre todas as entidades. 3. Gestão de Relações entre Entidades em regime de Outsourcing - É importante a existência de uma gestão contínua da relação desenvolvida no processo de outsourcing, entre os diversos fornecedores e o outsourcer como meio de balancear o nível de dependência entre as várias entidades. Para tal, é necessária uma participação aberta entre os todos os intervenientes organizacionais em relação às perspectivas e prioridades de todas as entidades, sendo crucial a manutenção de comunicação entre estas. É também necessário assegurar que o compromisso de objectivos concordados não é afectado com o aparecimento de problemas numa ou várias entidades envolvidas no processo. Uma mentalidade aberta com total transparência na comunicação entre o outsourcer e os fornecedores, deverá ser adoptada com a finalidade de garantir sucesso no processo de outsourcing. Esta gestão das relações é também relevante para garantir que se consegue assimilar toda a transferência da propriedade intelectual obtida nestas práticas de outsourcing. 4. Outsourcing através de múltiplos fornecedores - Esta abordagem em que é possível obter serviços através de múltiplos fornecedores, deverá ser considerado como uma fundamental e adquirida prática de negócio. O outsourcer deverá manter um forte relacionamento com cada fornecedor, desmultiplicando o risco pelas diversas entidades fornecedoras. 5

19 O verdadeiro desafio nesta abordagem será o modo como essa gestão entre vários fornecedores deverá ser lidada e conduzida. Com o outsourcing de múltiplos fornecedores, as vantagens são esclarecedoras, no entanto, existem certos aspectos que deverão ser avaliados com cautela, sendo estes: Complexidade técnica, uma vez que essa complexidade crescerá proporcionalmente com o aumento de fornecedores (embora o conteúdo destes serviços estejam normalizados); Dependências organizacionais, em que os contratos deverão ser cuidadosamente estruturados numa dinâmica de múltiplas organizações envolvidas na concepção de um serviço final. Assim, incentivos, formação e outras intangibilidades terão efeito apenas a longo prazo; Planeamento de integração, deverá ser considerado com minuciosidade, uma vez que este funcionamento unificado dos serviços necessitará de uma forma normalizada e protocolar de monitorização, análise e reportagem Contribuição A principal contribuição deste trabalho foca-se na união e conjugação de dois conceitos que se consideram disparos, Outsourcing e Fornecimento de Serviços. A nível do outsourcing actualmente praticado, nomeado de outsourcing clássico, foi realizado o levantamento dos riscos inerentes à inclusão de entidades externas no fluxo de negócio de uma organização, e analisados os principais modelos utilizados pelas organizações. Nesta análise de casos de estudos, foram analisados tantos casos de sucesso, como casos em que o método de outsourcing foi um fracasso. Destas situações foram retiradas conclusões sobre quais os principais riscos a ter em conta neste tipo de ambiente organizacional. A nível da Gestão e Fornecimento de Serviços, foram analisados os modelos, boas práticas e tecnologias que suportam este conceito de fornecimento de serviços ao longo de uma cadeia de valor de uma organização. Tanto a Gestão de Serviços como o Fornecimento de Serviços possuem modelos e práticas que apenas fazem sentido quando utilizadas a nível local (ou seja, intraorganizacional). Quando se pretende alargar essas soluções e tecnologias a paradigmas interorganizacionais, o resultado torna-se complexo e baixa relação qualidade/custo/risco. É precisamente neste paradigma inter-organizacional e perfeitamente ubíquo na generalização dos serviços que surge o modelo de serviços unificados designado de usil (Unified Service Implementation Language), desenvolvido pelo Professor Doutor José Delgado. Baseando os conhecimentos adquiridos sobre onde está o risco quando se recorre ao outsourcing e como as organizações funcionam a nível de Gestão e Fornecimento de serviços, utilizando este modelo de serviços usil como framework, é pretendido demonstrar como uma metodologia de outsourcing dinâmico e distribuído deverá ser definida e delineada para actuar em situações de fornecimento de serviços de forma genérica. 6

20 1.5. Estrutura do Documento Este Documento está organizado em 6 capítulos, distribuídos da seguinte forma: 1. Introdução Na Introdução, onde se inclui a presente secção, é apresentada a motivação, enquadramento, objectivos e principal contribuição deste trabalho, bem como a organização de todo o documento. 2. Estado da Arte Neste capítulo é realizada uma análise crítica sobre os paradigmas, metodologias, implementações e tecnologias tanto nas práticas do Outsourcing Clássico, como nas práticas de Gestão de Serviços e Fornecimento de Serviços. 3. Trabalho Relacionado (usil - Unified Service Implementation Language) É demonstrada a visão que serve de base ao modelo proposto para o fornecimento de serviços de forma totalmente genérica. São identificados os princípios deste modelo bem como definida a estrutura que a informação gerada e transaccionada nesta metodologia de outsourcing dinâmico e distribuído deverá cumprir. 4. Metodologia (Modelo de Referência) Definição e estruturação da metodologia de outsourcing dinâmico e distribuído num modelo de serviços unificado. Esta definição da metodologia é acompanhada e auxiliada com a explicitação do Modelo de Referência para interpretação deste ambiente de fornecimento de serviços perfeitamente genéricos. Ao longo das várias fases do ciclo de vida dos serviços, serão identificados os módulos a considerar, bem como uma aplicação desses módulos no Modelo de Referência. 5. Validação do Conceito (Proof-of-Concept) Para demonstrar o funcionamento e execução deste modelo de serviços aplicado ao outsourcing dinâmico e distribuído, é descrito um caso de estudo, em forma de exemplificação desta solução numa situação hipotética. 6. Conclusões e Trabalho Futuro Nas conclusões do documento são apresentadas as principais contribuições deste trabalho e o trabalho futuro que poderá ser desenvolvido no sentido de dar continuidade ao aqui realizado. Na última secção deste trabalho, é ainda apresentado um conjunto de anexos que servem de apoio ao documento. 7

21 2. Estado da Arte Outsourcing Clássico. 9 Gestão e Fornecimento de Serviços Conclusões

22 Para estabelecer com precisão este conceito de outsourcing dinâmico e distribuído é necessário focar o âmbito do trabalho de pesquisa em duas principais áreas de aplicação dos sistemas de informação. Pretende-se trazer realçar neste capítulo (de forma global) quais as transformações que o outsourcing clássico tem vindo a sofrer e de que forma o conceito de fornecimento de serviços num paradigma de modelos e arquitecturas orientados aos serviços, tem vindo a evoluir no mundo empresarial Outsourcing Clássico Gestão Estratégica no Outsourcing A nível de Gestão Estratégica, para conseguir levar adiante a intenção de optar pelo outsourcing, terão de ser estabelecidos logo de imediato certas premissas, sendo as de maior relevância as seguintes[32]: Garantir que a organização do cliente e do fornecedor do serviço de outsourcing, têm a capacidade para transportar competências e know-how para o core organizacional da empresa. Uma vez que não basta aceitar como suficiente a propaganda do fornecedor, que afirma ter as capacidades exigidas, mesmo que se esteja próximo de efectuar o compromisso contratual, considera-se de extrema importância que sejam efectuados testes para averiguar se o fornecedor possui ou não as competências necessárias para prestar o serviço que se espera, tanto no momento, como no futuro. Para tal ser expectável, com o melhoramento dos sistemas de informação é que factores como a economia de escala, habilidades técnicas e gestão dos processos de negócio poderão ser validados aquando da avaliação do contrato. Investimento em formação bem como os custos dos operacionais para a formação, poderão ter de ser adquiridos para garantir a selecção correcta de pessoas e habilitações. Competências chave que deverão ter ênfase nestes contratos de outsourcing incluem a medição do desempenho de IT, localização de nichos de serviços no mercado, gestão de projectos, capacidade de tomada de decisões e negociação, e capacidade na resolução de conflitos. Competências em áreas como marketing, finanças e jurídica, poderão também ser necessárias para uma melhor exploração de mercado; Garantir que a cultura organizacional bem como métodos e práticas de trabalho são compatíveis com os parceiros de outsourcing. É necessário efectuar escolhas com alguma prudência, prestando atenção na particularidade em que estes tipos de negócios, possuem objectivos comuns. Logo, para uma relação de outsourcing ter sucesso, os estilos de operação e cultura têm de ser compatíveis a todos os níveis entre o cliente e o fornecedor. A gestão destes resultados requer um esforço constante entre ambas as partes, estando comprometidas a desenvolver um entendimento mútuo para os workflows e na identificação de aspectos críticos da relação criada; 9

23 Proporcionar uma continuidade activa na concepção e desenvolvimento de contratos entre relações empresariais com o objectivo de antecipar a mudança. Uma vez que a tecnologia evolui, o curso dos contratos bem como as condições de negócio têm de acompanhar essa evolução. Portanto, é relevante suportar a capacidade de antecipação de certas prioridades e cláusulas de forma flexível sem que afecte a evolução a longo prazo do serviço; Modelo de Maturidade do Mercado de Outsourcing Através de um estudo realizado na introdução dos vários níveis de maturidade no mercado do outsourcing[29] que incidiu na definição de factores decisivos no negócio de serviços provenientes do core do Outsourcer, considera-se o modelo apresentado na Figura 1. Nível de Maturidade Baixo Nível de Maturidade Alto Inicial Crescimento Partilhado Combinativo Recessionário Aspectos Factores Outsourcer Estabilidade dos Produtos (Qualidade e Quantidade); Número de Outsourcers; Habilidade de lidar e controlar a Gestão de Risco. Fornecedor Produção em Escala; Número de Entidades Fornecedoras; Nível de Custo, Capacidade e de Produção; Negócio de Outsourcing Estabilidade Técnica; Versatilidade na Composição entre Entidades e entre Equipamentos. Envolvente de Mercado Leis Nacionais, Regras Industriais, Entidades Reguladores, Relações de Outsourcing. Figura 1 - Modelo de maturidade do mercado outsourcing Pode-se observar na Figura 1, os níveis de maturidade que evoluem horizontalmente estão divididas em cinco fases distintas, desde a fase Inicial até à fase de Recessão, respectivamente. Isto pretende demonstrar a evolução a que o negócio de outsourcing é submetido, sendo avaliado desde que é introduzido, em que a capacidade (operacional) é reduzida e fraca, até um nível em que novas tendências de negócio surgirão e a atractividade que o negócio de outsourcing tinha, passa a ser desvalorizada, passando por níveis de franco crescimento e combinatório em que o mercado está totalmente racionalizado com os riscos inerentes à prática de outsourcing e capacitado com meios que permitam a produção em massa de serviços de outsourcing. 10

24 Estes níveis de maturidade, para além de espelharem uma análise do mercado ao nível de outsourcing, possuem níveis de maturidade análogos aos níveis e dimensões a serem avaliados na framework de estrutura organizacional dos fornecedores a suportarem o outsourcing Gestão de Risco Apesar de existir uma vasta referência bibliográfica investigada sobre este capítulo [12],[19].[22],[24],[32],[35],[36], Jérôme[49] com o seu extensivo e incomparável estudo e investigação sobre a Gestão de Risco, é realçado neste subcapítulo. Pretende-se de forma explicita frisar e definir o que Afinar e Evitar com a Gestão de Risco e Gestão de Relações durante a prática de outsourcing (mapa conceptual da Gestão de Risco em ANEXO D). Estes aspectos serão numerados como os 7 pecados mortais nas práticas de outsourcing das organizações: 1º Pecado Mortal: A prática de Outsourcing em actividades que não devem ser Outsourced. Conhecer quais as actividades que podem ser bem realizadas por vendedores no exterior, exige uma boa compreensão das vantagens competitivas provenientes dos Fornecedores. Essas vantagens traduzem-se em Recursos e Capacidades que são valiosos, raros, difíceis de imitar, e de difícil substituição que conduzem num desempenho superior. As actividades que se baseiam em tais capacidades e recursos (isto é, as actividades core) não devem ser outsourced, porque as empresas correm o risco de perder vantagem competitiva e o factor de distinção do ponto de vista do Cliente- Final. Por outro lado, actividades não essenciais podem ser submetidas à prática de outsourcing por duas razões. Primeiro, outsourcing permite às empresas a centrarem-se nas actividades que fazem melhor e melhorar o seu desempenho global. Em segundo lugar, com transferência de actividades não essenciais para fornecedores especializados podem ajudar a reduzir os custos e melhorar o desempenho de tais actividades. 2º Pecado Mortal: A Selecção do Fornecedor Errado. Uma Útil distinção dos fornecedores pode ser feita entre qualificações hard e soft: Qualificações Hard são tangíveis e podem ser facilmente verificadas no resultado final. Referem-se à capacidade dos fornecedores para fornecer soluções de baixo custo. Qualificações Soft são comportamentais. Podem não ser verificáveis e podem variar dependendo das circunstâncias. Importantes critérios Soft incluem bens culturais próprios, um compromisso de melhoria contínua e flexibilidade, Confiança é um critério soft importante. Os elevados níveis de confiança estão frequentemente associados a sucesso nas actividades outsourcing. Na maioria dos casos, o outsourcer e o fornecedor têm diferentes objectivos empresariais que podem resultar em conflitos de interesse. Por exemplo, o início do contrato é geralmente mais vantajoso para o cliente do que para o vendedor. À medida que o tempo passa, o contrato torna-se sujeito a negociações que podem gerar mal-entendidos. "O Outsourcing é uma operação lucrativa no curto prazo. Deve permanecer rentável a longo prazo"[99]. 11

25 A melhor maneira de identificar os melhores fornecedores, em ambas as qualificações (hard e soft), é através da informação em primeira mão. Uma técnica útil para começar, será confiar a um grande número de fornecedores, actividades comerciais com menor impacto no final, antes de proceder ao outsourcing de actividades mais sensíveis para os fornecedores mais exigentes a nível financeiro. Em primeira mão a experiência é um tanto morosa e revela-se um caminho dispendioso para descobrir se é ou não um fornecedor eficiente e confiável. Uma forma alternativa em termos temporais e financeiros, é a utilização de informação em segunda mão (ou seja, examinar a reputação e nível de maturidade do Fornecedor). A reputação de competência e idoneidade é um activo útil que os fornecedores ambicionam no intuito de atrair novos clientes. 3º Pecado Mortal: Escrever um Contrato Pobre. No que diz respeito ao próprio conteúdo do contrato, os contratos ideais são simultaneamente: Precisos: Contratos mal definidos muitas vezes resultam em custos elevados e níveis de serviço pobres. Custos e requisitos de desempenho devem ser estabelecidos desde o início e claramente especificado no contrato; Completos: Escrever um contrato, que é tão completo quanto possível, tem duas importantes vantagens. Em primeiro lugar, quanto mais completo o contrato, menor o risco de oportunismo das entidades. Incentivos. O contrato deve ser escrito para encorajar o comportamento correcto dos fornecedores. Por exemplo, o fornecedor pode obter um bónus quando aumenta o seu desempenho de indicadores de valor empresarial. Este incentivo poderá ajudar a alinhar as metas dos fornecedores com os objectivos empresariais dos outsourcers. O contrato deverá também abordar a forma como a relação entre entidades poderá mudar ao longo do seu ciclo de vida. Flexível: Devido à evolução da tecnologia e da constante mudança da envolvente empresarial, a activação de práticas por outsourcing não devem ser definidos duma forma inflexível. 4º Pecado Mortal: Negligenciar questões pessoais. A gestão eficaz de questões pessoais é crucial porque os colaboradores geralmente vêm o outsourcing como uma desvalorização das suas competências. Isso pode resultar num êxodo massivo mesmo antes de ser tomada uma decisão de avançar com o outsourcing. Uma comunicação aberta é a chave para a gestão de pessoal em questões de outsourcing. 5º Pecado Mortal: Perder controlo sobre a actividade em outsourcing. Se o mau desempenho de um serviço é atribuído a factores como insuficiente escala económica ou a falta de especialização, a prática de outsourcing faz sentido. Se um mau desempenho de um serviço é atribuído à má gestão, outsourcing não é necessariamente a solução indicada. Por vezes é considerado de maior facilidade a gestão de um Fornecedor do que um departamento (ou com produção in-house). Por outro lado, o outsourcing implica em grandes mudanças no que diz respeito à gestão de uma actividade. 12

26 Com o outsourcing, o controlo através da propriedade directa de bens é substituído pelo controlo de um simples contrato ou simples parâmetros. O Outsourcing não significa abdicar. A inexistência de uma gestão activa é que deve ser evitada a todo o custo. Como o exemplo seguinte esclarece: Um fabricante de computadores realiza o outsourcing de uma grande parte da sua actividade é pós-venda. Embora a lógica de outsourcing ter sido essencialmente focada na redução de custos, um elevado padrão de desempenho do vendedor é também importante pois o serviço pósvenda é crucial no sector da informática (e o fabricante de computadores não quererá perder o seu volume de negócios devido ao seu vendedor outsourced). 6º Pecado Mortal: Negligenciar os custos indirectos do Outsourcing. Os custos indirectos do outsourcing são um tema importante para a camada de gestão da organização. É também paradoxal que esses custos sejam necessários em detrimento do resultado dos estudos de mercado para a activação de actividade por outsourcing. Embora bem sucedido, esta investigação requer despesas substanciais com a pesquisa do fornecedor, com a contratação e gestão de Fornecedores que podem transformar um potencial contracto de outsourcing num completo fracasso. Considera-se fulcral considerar o potencial impacto que os custos indirectos poderão ter na vitalidade da organização. 7º Pecado Mortal: Na ausência de Plano-B (Disaster-Recovery) como estratégia de alternativa ou de emergência. Por vezes, as relações entre entidades que praticam o outsourcing tornam-se como entidades dependentes dos seus investimentos para cumprir certos contratos ou manter um certo nível de serviço padrão nos serviços que oferece. Estas iniciativas levam à inexistência de um plano de restauração ou backup definido para quando um fornecedor, mesmo com todas as providências para evitar falhas ou problemas, falha na mesma. É nesta perspectiva que terá de haver uma divisão de esforços, tanto para manter os níveis de serviço esperado com os fornecedores bem como garantir a disponibilidade de Fornecedores Alternativos em caso de falha ou desastre Service-Level-Agreement (SLA) Ambos os intervenientes deverão estar ao corrente do que é estabelecer um contracto de SLA bem definido e estruturado [9],[12],[24]. Actualmente existem certas negociações de outsourcing que são baseadas unicamente na confiança mútua sem definir explicitamente no contrato, certas regras que poderiam desencadear antecipações e explorar todas as contingências passíveis de surgir [10],[19]. É neste seguimento, que se considera um contrato de SLA bem estruturado como um dos ingredientes chave para se obter sucesso através de outsourcing. Este tipo de SLA s explícitos pretendem padronizar as transacções funcionais e sociais entre clientes e fornecedores criando assim uma rede hierárquica de confiança e compromisso. Esta rede pretende dar suporte durante o estabelecimento de um contrato na primeira fase de negociação entre as várias entidades (fornecedores, outsourcer e cliente) e trazer equilíbrio entre confiança e controlo estrutural no processo de outsourcing de serviços. 13

27 Os SLA s possuem 3 distintos formatos e modo de ligação entre entidades e serviços num contracto de um terminado serviço, podendo ser estes: - SLA com estrutura baseado no serviço (Figura 2); Figura 2 - SLA com estrutura baseado no serviço - SLA com estrutura baseado no cliente (Figura 3); Figura 3 - SLA com estrutura baseado no cliente 14

28 - SLA com estrutura multi-nível, mais complexa (Figura 4). Figura 4 - SLA com estrutura multi-nível Information Technology Service Quality Center (ITsqc) A solução apresentada pelo departamento de IT Governance na Universidade Carnegie Mellon, o esourcing Capability Model [7] é um modelo de capacidade baseado em best-pratices com três princípios: Oferecer orientação e melhoramento nos processos do ciclo de vida da cadeia de produção dos fornecedores de serviços; Fornecer meios de avaliação da capacidade e qualidade dos serviços fornecidos aos clientes; Providenciar diferenciação no que toca ao fornecimento de serviços por meio de outsourcing. Tipos de Sourcing. É efectuada uma diferenciação no tipo de categoria dos serviços disponibilizados por parte do fornecedor, sendo: Selectivo - Onde apenas uma porção do negócio que um fornecedor tem, é requisitada para um determinado serviço (e.g. pode variar desde uma simples tarefa verifica impressão; até um processo inteiro de facturação); Total - Toda uma função de negócio é fornecida (e.g. recursos humanos); Transitório - a velha prática de requisitar apoio operacional por um determinado período de tempo (enquanto sistemas legados não são totalmente substituídos por um novo sistema). Algumas destas soluções propostas, são possíveis adoptar aos vários tipos de outsourcing que se pode pretender de uma mesma entidade fornecedora para diversos serviços, bem como para várias entidades fornecedoras nesse mesmo cenário. 15

29 2.2. Gestão e Fornecimento de Serviços Gestão de Serviços IT O papel das tecnologias da informação no negócio mudou bastante quando comparado com os tempos em que o Chief Executive Officer (CEO) questionava os gestores de IT sobre a aceitação do na organização. Hoje em dia, o IT é reconhecido como uma parte fulcral para o negócio, situação que acarreta novos desafios e problemas: o IT é responsável por desenvolver novos e melhores serviços de IT, tornando-os eficientes o suficiente para serem considerados uma vantagem competitiva para o negócio da organização em que se inserem. [50] Os gestores de IT devem assim encontrar maneiras criativas de fornecer serviços de alta qualidade para competir mais eficientemente, ao mesmo tempo que o fazem tendo por base orçamentos que são, grande parte das vezes, reduzidos. Para proporcionar uma vantagem competitiva ao negócio, o departamento de IT o qual inclui a infra-estrutura, pessoas e processos tem de trabalhar como uma unidade única e funcional num ambiente onde os recursos são limitados. Muitas são as organizações que procuram na gestão de serviços de IT uma forma de se organizarem à volta dos serviços, ao mesmo tempo que vão melhorando a sua qualidade. [44] A gestão de serviços de IT preocupa-se com o suporte e fornecimento de serviços de IT que são implementados como solução para os requisitos do negócio da organização. Assim, é importante que os serviços de IT suportem as actividades nucleares de uma organização, ao mesmo tempo que facilitam o processo de mudança sempre que o negócio necessite de evoluir para responder às grandes necessidades dos seus clientes. Desta forma, considera-se que, cada vez mais, o IT deve ser considerado como um dos principais stakeholders no processo de tomadas de decisão referentes ao negócio da organização. O negócio necessita também que lhe sejam fornecidos dados referentes às métricas dos seus serviços, permitindo assim que se efectuem estudos estatísticos referentes à evolução dos próprios serviços de IT. Para se obter estas métricas e os respectivos resultados é necessário que o departamento de IT tenha consciência da sua posição actual em relação à posição onde desejam estar, como vão chegar onde querem e como vão ter noção que atingiram os objectivos que desejavam Boas-Práticas e Modelos Para trazer alguma uniformidade empresarial no que toca à gestão e fornecimento de serviços, apresentam-se os principais modelos e conjunto de boas práticas que são actualmente utilizados pelas organizações Six Sigma O Six Sigma é um conjunto de boas práticas para a gestão de qualidade dos processos, através da melhoria contínua eliminando os defeitos/ineficácias nos processos. 16

30 Os defeitos são definidos como desvios inaceitáveis tendo em conta as suas especificações ou expectativas do cliente. O Six Sigma usa um modelo para definir o problema e o seu impacto, medir a performance dos processos actuais, analisar os dados recolhidos, melhorar através da recomendação e implementação de soluções e controlar através de monitorização contínua. Tem como grandes objectivos: Melhorar a consistência dos serviços, diminuindo a variância; Ajudar a alinhar as IT com o negócio; Estabelecer prioridades de melhoria; Ser uma referência na qualidade de serviço; Fornecer uma metodologia para a melhoria contínua de qualidade de serviço dos processos.[46] ISO/IEC 17799:2005 Sendo a informação um recurso transversal às organizações, é importante que esta seja gerida de acordo com o Standard de segurança dos dados e informação ISO Foca em maior detalhes, nomeadamente [47]: Confidencialidade: a informação é acessível apenas a quem esteja autorizado; Integridade: salvaguardar a exactidão e completude da informação; Disponibilidade: os utilizadores autorizados devem poder aceder à informação quando desejarem. A ISO estabelece um guia de boas práticas para iniciar, implementar, manter e melhorar a gestão da segurança de informação duma organização [48]. Assim, fornece as linhas de orientação e recomendações para a criação dum plano de segurança. É constituída por onze áreas de controlo de objectivos de segurança e uma introdutória de análise de riscos. No que concerne à análise de riscos, os controlos de segurança devem satisfazer os requisitos definidos pela análise de riscos. Assim, a análise de riscos baseia-se na identificação, quantificação e definição de prioridades dos riscos relevantes para a organização e, por conseguinte, deve indicar quais as acções a tomar para gerir os riscos identificados e quais os controlos de segurança que devem ser usados. As áreas de controlo definidas na ISO são (ANEXO E.1): Política de segurança: fornecer as linhas gerais de orientação e suporte para a segurança de informação de acordo com os requisitos de negócio, leis e regulamentações; Organização da segurança de informação: gerir a segurança de informação interna à organização e a informação prestada a entidades externas; Gestão dos recursos: criar e manter um inventário dos recursos organizacionais e associálos aos seus responsáveis; classificar a informação em termos de valor, requisitos legais e importância para a organização; 17

31 Segurança dos recursos humanos: assegurar que todos os stakeholders sabem as suas responsabilidades no que concerne aos recursos de informação; Segurança física e ambiental: plano de prevenção de acessos físicos não autorizados ou outras situações que possam causar danos à informação da organização; Gestão de comunicações e operações: assegurar uma operação correcta e segura das funcionalidades de processamento de informação; Controlo de acesso: assegurar o correcto controlo de acesso à informação; Aquisição, desenvolvimento e manutenção de sistemas de informação: assegurar a existência de preocupação com a segurança de informação no decorrer da aquisição, desenvolvimento e manutenção de sistemas de informação; Gestão de incidentes: assegurar uma gestão de incidentes diligente, consistente e efectiva; Gestão da continuidade do negócio: desenvolver um plano que evite ou restringe interrupções na prestação de serviços e/ou processos críticos devido a falhas graves ou desastres ambientais/sociais; Conformidade: assegurar o correcto alinhamento entre os sistemas de informação e regulamentações legais, estatutárias ou contratuais; Control Objectives for Information and related Technology (CobIT) O IT Governance Institute[45] desenvolveu um conjunto de boas práticas para o IT Governance e controlo, designado por CobIT, que fornece um conjunto de indicadores, métricas, processos e boas práticas para maximizar os benefícios das IT nas organizações. Estas boas práticas estão fortemente focadas no controlo e menos na execução, situando-se no nível de gestão estratégica das organizações, ajudando-as a definir os objectivos e a controlar as IT. As principais motivações do CobIT são [43]: Alinhar as IT com o negócio através de objectivos de negócio e do controlo do risco das IT; Potenciar o IT Governance; Normalização e automação de processos de IT; Definir uma estrutura de auditoria; Conformidade com regulamentações como, por exemplo, SOX (Sarbanes-Oxley Act). As organizações que não implementarem as boas práticas preconizadas pelo CobIT, incorrem em vários riscos, tais como: Desalinhamento dos serviços de IT; Suporte fraco aos objectivos do negócio, provocado pelo desalinhamento dos serviços; Perda de oportunidades devido ao desalinhamento; Conhecimento fragmentado pelas pessoas em vez de haver uma visão holística do conhecimento organizacional; Projecções e decisões de investimento incorrectas. 18

32 Como é ilustrado na Figura 5, O CobIT divide-se nos quatro principais domínios de aplicação Plan and Organize; Acquire and Implement; Deliver and Support; Monitor and Evaluate (Anexo E.2); Figura 5 - Modelo do CobIT e dos seus principais domínios de aplicação enhanced Telecom Operations Map (etom) O etom [29] é um standard utilizado para processos de negócio na indústria das telecomunicações. Descreve todo o âmbito requerido pelo fornecedor do serviço, definindo os elementos chave e como estes devem actuar. É normalmente comparado ao ITIL por também visar a Best-praticies para o Sector das IT, sendo mais específico por focar uma área específica. A Framework representa todo o conjunto de fornecedores de serviços num ambiente organizacional. Num nível abrangente, o etom pode ser visto segundo três áreas de processos principais: 19

33 Estratégia, Infra-estrutura e Produto cobrem o planeamento e gestão do ciclo de vida (associado com o desenvolvimento e entrega). Incluem processos que desenvolvem estratégias, que estabelecem compromissos com o cumprimento das mesmas. Também, desenvolvem e gerem a entrega e melhoria de produtos e infra-estrutura, e a própria cadeia de valor; Operações cobrem o núcleo da gestão de operações e de clientes; Gestão Organizacional cobre a gestão de suporte à empresa e ao negócio. A estrutura no etom usa uma decomposição hierárquica, de tal forma que os processos de negócio da organização são sucessivamente decompostos numa série de níveis. Também inclui vistas de funcionalidade de como os fluxos são emparelhados horizontalmente ao longo da organização interna da empresa. Por exemplo, gerir as relações de cliente envolve uma organização desde o Marketing às encomendas, à facturação, ao suporte pós-serviços e às subsequentes vendas. À vista da estrutura conceptual, a Framework fornece um contexto que diferencia processos de estratégia e ciclo de vida de processos operacionais, em duas áreas de processo alargadas, conjugadas com uma terceira área que corresponde à gestão empresarial (as três áreas de processos descritas anteriormente). São também, identificados os processos funcionais chave, onde se contemplam as entidades internas e externas que interactuam com a organização. Toda a informação é estruturada em quatro blocos ao longo de várias áreas dos processos, sendo estes: Os processos de Mercado, Produto e Cliente incluem aqueles que lidam com gestão de vendas, gestão de marketing, gestão de produto e ofertas bem como processos operacionais, tais como gerir a interface com o cliente, encomendas, problemas, gestão de SLA e facturação; Os processos de Serviço incluem aqueles que lidam com o desenvolvimento do serviço e entrega de capacidade dos serviços, configuração de serviço, gestão de problemas de serviço, análise de qualidade, e avaliação; Os processos de Recursos, incluem aqueles que lidam com desenvolvimento e entrega da infra-estrutura de recursos (rede e IT), e a sua gestão operacional incluindo aspectos tais como o estabelecimento de cláusulas, gestão de dificuldades e gestão de desempenho. A infra-estrutura de recursos suporta produtos e serviços, bem como o suporte à própria organização; Os processos de Fornecimento/Parceria incluem aqueles que lidam com a interacção da organização com os seus fornecedores e parceiros. Envolve tanto os processos que desenvolvem e gerem a cadeia de valor que conjuga produto e infra-estrutura, bem como aqueles que suportam a interface operacional com os seus fornecedores e parceiros. 20

34 Abaixo do nível conceptual, a Framework é decomposta num conjunto de grupos de processos, que oferece um primeiro nível de detalhe até que toda a organização possa ser visualizada. O desempenho desses grupos de processos determina o sucesso da organização e, por isso, têm de ser considerados da perspectiva do CEO, CIO (Chief Information Officer), CTO (Chief Technology Officer), CFO (Chief Financial Officer), etc. Na Figura 6, é demonstrado, de forma resumida, o modo como os processos estão organizados no etom. É preciso notar que o mapa apenas reflecte a estrutura da Framework segundo as áreas onde intervêm os processos. Figura 6 - Mapa de Processos da framework etom [29] Information Technology Infrastructure Library (ITIL) v3 A 30 de Maio de 2007 foi publicada a terceira versão da biblioteca das melhores práticas de gestão de Serviços de IT: ITIL v3. Uma das mudanças fulcrais desta terceira versão foi a passagem do foco que existia no ciclo de vida dos processos e do alinhamento entre o IT e o negócio para um foco no ciclo de vida dos serviços fornecidos pelo IT, bem como a importância da criação de valor para o negócio (ao invés da simples execução dos processos) [2]. Desta forma, este novo foco veio trazer considerações estratégicas e de desenho, bem como culturais e organizacionais. A visão baseada em processos desaparece, dando lugar uma visão baseada no ciclo de vida dos serviços, iniciando-se na estratégia dos mesmos e terminando na sua produção. Esta metodologia consiste num ciclo composto por seis (6) fases e que, a cada iteração, pretende melhorar e evoluir a implementação de ITIL de forma a aumentar a qualidade dos serviços fornecidos. Estas fases traduzem-se nas seguintes questões a analisar e concretizar com respostas[50]: 21

35 1) Qual é a visão? A visão consiste numa definição dos objectivos de negócio em conjunto com o IT. A visão descrita deve descrever o objectivo e abordar todos os aspectos do projecto de implementação de ITIL incluindo pessoas, processos e tecnologia. Uma boa visão deve focar-se sobre os seguintes aspectos: Clarificar a direcção do projecto de implementação de ITIL; Motivar as pessoas a agir de maneira a facilitar a implementação do ITIL; Coordenar as acções das diferentes pessoas; Sublinhar a visão da gestão de topo. 2) Onde estamos agora? Antes de proceder à implementação de ITIL propriamente dita, será necessário definir o estado actual da organização segundo várias perspectivas. Para definirmos o estado actual da organização, as seguintes perguntas devem ser respondidas: Quão grande é o desvio entre o papel do IT e o papel que o mesmo devia desempenhar? O IT está orientado a objectivos que reflictam as necessidades do negócio? Existem processos bem definidos para alcançar os diferentes objectivos? São efectuadas medições do desempenho desses processos com vista à melhoria dos mesmos? Os meios tecnológicos existentes suportam as necessidades dos processos e permitem alcançar os objectivos traçados? As diferentes competências necessárias para a correcta gestão do IT estão bem definidas e bem distribuídas? Será também necessário avaliar o papel dos diferentes stakeholders, uma vez que os mesmos definem o papel do IT, têm controlo financeiro sobre o IT e exercem grande influência nas tomadas de decisão. Assim, terá de ser efectuada uma análise dos diferentes stakeholders, efectuando-se os seguintes passos: Identificar os diferentes grupos de stakeholders existentes; Efectuar o mapeamento dos stakeholders nos diferentes grupos; Identificar relações entre stakeholders; Dentro de cada grupo, identificar as necessidades dos stakeholders; Prioritizar as necessidades identificadas. 3) Onde queremos estar? Uma vez que temos conhecimento do panorama actual da organização, poderemos passar para a fase de definir o panorama futuro da organização. Os resultados do benchmarking efectuado na fase anterior foram úteis para identificar problemas em termos de pessoas, processos e tecnologia. Com base nesses problemas deve ser efectuada uma avaliação dos mesmos com a finalidade de prioritizar as acções de melhoria dos diferentes processos. 22

36 4) Como chegamos onde queremos estar? É nesta fase que o projecto de ITIL se vai concretizar. Várias são as hipóteses de iniciação do projecto de implementação de ITIL, sendo que não existe um consenso em relação a essa matéria. Contudo, existe um conjunto base de processos que deverão ser implementados e que trarão um aumento de qualidade do serviço prestado. 5) Como sabemos que chegámos onde queremos estar? Muitos projectos de implementação de ITIL falham porque, após a implementação, verifica-se que se atingiram objectivos secundários e não os grandes objectivos. Neste contexto, será proveitoso efectuarmos medições e auditorias sobre os processos que foram implementados para verificar se realmente os mesmos correspondem ao esperado. Para tal é necessário verificar se os factores críticos de sucesso foram satisfeitos e efectuar medições com base em indicadores de performance 6) Como mantemos o ritmo? Para manter o ritmo da implementação de ITIL, deverão ser executadas as seguintes acções: Consolidar as alterações efectuadas; Monitorizar constantemente os diferentes processos, prevenindo o aparecimento de problemas devido ao mau funcionamento dos mesmos. Qualquer problema detectado deverá ser alvo de uma avaliação de forma a verificar quais as alterações a efectuar ao processo; Rever e melhorar os processos através de uma nova iteração deste ciclo. Irá criar-se uma nova visão, fazer uma avaliação do estado actual e futuro da organização e seleccionar as alterações que terão de ser efectuadas aos diferentes processos de forma a aumentar a qualidade dos serviços; Gerir o conhecimento, colocando-o tornando-o acessível a qualquer colaborador. Assim, a passagem de conhecimento para novos colaboradores será mais simples e permitirá que rapidamente os mesmos tenham conhecimento da realidade da organização, podendo actuar mais rapidamente sobre os problemas que poderão surgir Supply-Chain Operations Reference (SCOR) O SCOR é utilizado para analisar a cadeia de valor e identificar oportunidades de melhoria no fluxo de trabalho e de informação. Procura condições para estabelecer processos padrão, métricas de avaliação da gestão da cadeia e criar um modelo de gestão que produza melhorias contínuas de forma eficiente. É uma Framework que procura também desenvolver um grupo de indicadores para a gestão da cadeia logística, englobando uma comunicação de métricas em ciclo, custos, serviço/qualidade e activos. 23

37 Ao contrário de algumas tendências que se orientam no sentido de modelos matemáticos para a gestão da cadeia de valor, o SCOR é orientado para a tomada de decisões. Fornece uma estrutura comum, uma terminologia padrão e medidas de desempenho comuns associadas ao benchmarking e às Best-pratices[52]. Estas características fazem do modelo um referencial para a indústria de serviços, embora o sucesso da sua aplicação dependa de uma estratégia de operações consistente com a estratégia de negócio da empresa. Estratégia essa, que tem de estar organizada de forma a suportar processos de decisão rápidos, e as suas práticas de gestão apoiadas por sistemas apropriados, nomeadamente por tecnologias de informação. O SCOR é uma Framework que modela os processos segundo diferentes níveis de granularidade, baseando-se em cinco processos de gestão distintos: Plan, Source, Make, Deliver e Return (Anexo E.4). A Figura 8 demonstra o modelo organizacional dos processos. A um nível mais alto apresenta as categorias dos vários processos, e a um nível mais baixo especifica os processos incluídos em cada categoria do modelo. Para a análise da Framework, neste documento, são considerados os grupos de processos por categorias. Figura 7 - Modelo organizacional de alto nível dos cinco processos do SCOR [52] 24

38 Service-Oriented Architecture (SOA) O conceito de SOA é muito utilizado nos dias de hoje, por muitas organizações[38]. Porém, na maior parte das vezes, não é aplicado correctamente, porque o conceito em si descreve duas coisas muito distintas, as palavras (Service-Oriented) expressam uma metodologia para o desenvolvimento de software, a palavra (Architecture) é uma perspectiva dos componentes de um sistema de software. É esta representação de todas as peças juntas que formam uma construção. Service-Oriented Architecture é uma estratégia que congrega a criação de todos os componentes de software de uma empresa, seguindo a metodologia de programação orientada a serviços. A visão SOA [41] tem como seu componente fundamental os serviços e consiste numa abordagem de arquitectura para a criação de sistemas a partir de serviços autónomos. Com esta filosofia, a integração é uma previsão, onde a solução final provavelmente será composta por serviços desenvolvidos, em linguagens de programação diferentes, alojados em diversas plataformas, com processos de negócios e modelos de segurança distintos. Os serviços devem ser desenhados para proporcionar disponibilidade e estabilidade. Os serviços são criados para durar, enquanto as configurações e as agregações dos serviços são criadas, para mudar. O SOA [39] utiliza o paradigma find-bind-execute. Nesse paradigma, os fornecedores de serviços registam os seus serviços num registo público, onde é usado para que os consumidores de serviços encontrem os serviços que pretendem. Se o serviço desejado estiver no registo, um contrato é fornecido ao consumidor e um endereço para esse serviço. Cada entidade pode tomar o papel de consumidor, fornecedor e/ou registo: Um consumidor de serviços é uma aplicação, um módulo de software ou outro serviço que requer um serviço, e executa de acordo um contracto de interface. Um fornecedor de serviços é uma entidade direccional através da rede que aceita e executa consulta de consumidores, e publica seus serviços e seu contracto de interfaces no registo de serviços para que o consumidor de serviços possa descobrir e aceder ao serviço. Um registo de serviços é o responsável por tornar possível a descoberta de serviços, contendo um repositório de serviços disponíveis e permitindo visualizar as interfaces dos fornecedores de serviços aos consumidores interessados. 25

39 Figura 8 - Colaborações SOA As operações descritas na Figura 1 são: Publicar Serviço: para poder aceder a um serviço deve ser publicada a sua descrição para que possa ser descoberto e invocado, pelos consumidores; Descobrir Serviço: um consumidor de serviços descobre, o serviço que cumpra os critérios pretendidos, consultando o registo de serviços Universal Description Discovery and Integration (UDDI); Ligar e Invocar: quando o consumidor tiver a descrição do serviço, ele invoca-o de acordo com as informações contidas na descrição do serviço. A agilidade muitas vezes é promovida como uma das maiores vantagens da SOA [40], porque uma organização com processos de negócios, implementados numa infra-estrutura menos rígida é mais aberta a mudanças que uma organização limitada por aplicações monolíticas. Os serviços e interfaces associadas devem permanecer estáveis, permitindo que sejam reconfigurados ou reagrupados para acompanhar sempre novas necessidades das empresas. Os serviços permanecem estáveis, contando com interfaces baseadas em padrões e em mensagens bem definidas. Características do SOA. Erl [40] define o SOA como sendo uma tecnologia que adere aos princípios da orientação a serviços. Quando realizados através do uso da tecnologia de Web-Services, o SOA promove esses princípios em todos os processos de negócios e automação de uma organização. 26

40 Algumas das principais características do SOA: Baixo acoplamento: os serviços mantêm um relacionamento que minimiza as dependências entre eles, necessitando apenas que eles saibam da existência uns dos outros. Contrato: os serviços aderem a um contrato de comunicação, sendo definido colectivamente por um ou vários consumidores de serviços. Autonomia: os serviços têm controlo sobre a lógica que encapsulam. Abstracção: além da descrição que está no contrato do serviço, eles encapsulam a lógica de execução. Reutilização: a lógica é dividida entre os serviços com a finalidade de promover a reutilização. Composição: um conjunto de serviços pode ser coordenado e agregado para formar serviços compostos. Estado: os serviços guardam poucas informações específicas de uma actividade. Benefícios intrínsecos ao SOA. Com o SOA é possível acrescentar flexibilidade e agilidade ao negócio, mas tais objectivos para serem garantidos, uma organização deve adoptar esta visão como uma mudança no estilo e ciclo de vida organizacional[15]. Para comprovar tais hipóteses de sucesso, uma organização deverá alcançar certos benefícios, tais como: Redução de custos: através da divisão das funcionalidades da infra-estrutura organizacional (auditoria, segurança, gestão, e serviços partilhados; Redução de redundâncias: um dos principais objectivos do SOA é a capacidade de implementar funcionalidades uma única vez e conseguir reutilizar essas funcionalidades em todas as aplicações necessárias; Melhor consistência, segurança e conformidade: Se uma regra de negócio é implementada num serviço, então todas as aplicações que usam esse serviço terão de aplicar essa regra de negócio de modo consistente; Produtividade, eficiência, eficácia e satisfação acrescida: O SOA permite o acesso a qualquer tipo de informação que uma aplicação necessite[21]. Assim sendo, deverá suportar os processos de negócio de forma mais eficiente para que as aplicações orientadas aos serviços tenham uma melhor aceitação por parte do utilizador. Neste caso do outsourcing, é imperativo ter em conta que, para aplicações externas, a melhoria de utilização e produção, provoca também uma melhoria na satisfação do cliente final. Impacto do SOA no Outsourcing. Com o sucesso do SOA, veio-se a aumentar o número de debates em relação às mudanças das práticas de negócio. Muitos profissionais, peritos e investigadores, começaram a argumentar sobre o impacto do SOA no outsourcing de sistemas de informação[8]. É dada uma enorme ênfase no crescimento que o sector industrial tem vindo a apresentar nas novas áreas do outsourcing de sistemas de informação e que, ao longo dos anos, o outsourcing tem enfrentado constantes evoluções. 27

41 Cloud Computing O primeiro problema ao definir cloud computing é que cada pessoa parece possuir a sua própria definição. Como metáfora para a Internet, "A Nuvem" é um cliché familiar, mas quando combinada com computação o seu significado torna-se relativamente obscuro. A grande maioria dos analistas define cloud computing como uma versão actualizada de utility computing - servidores virtuais disponíveis através da Internet. Outros vão para além dessa definição, considerando tudo o que é consumido para além duma firewall está "na nuvem" (outsourcing clássico exclusive)[44]. Apenas quando se reflecte acerca do que as tecnologias de informação necessitam constantemente é que cloud computing se torna claro: uma forma de aumentar e/ou adicionar capacidades de forma prática e rápida sem existir a necessidade de investir em novas infraestruturas, treinar novo pessoal ou licenciar novo software. Cloud Computing abrange qualquer serviço por subscrição ou pay-per-use que estenda as actuais capacidades das IT em tempo real e através da Internet. O Conceito de Cloud Computing encontra-se num estado inicial, com um modesto conjunto de grandes e pequenos prestadores de serviços que disponibilizam serviços cloud-based, que vão desde grandes aplicações a pequenos serviços de filtragem de SPAM. Apresentam-se os vários ramos de cloud computing conhecidos: 1) Saas (Software as a Service) Este género de cloud computing distribui uma única aplicação através do browser a milhões de clientes. Do ponto de vista do consumidor, isto significa que não existe necessidade de investimentos a nível de servidores ou licenciamento de software. Pelo lado do fornecedor, com apenas uma aplicação para gerir, os custos são bastante baixos quando comparados com hospedagem convencional (Exemplo: Salesforce.com); 2) Utility Computing Utilizada pela Amazon, Sun e outras companhias que oferecem espaço e servidores virtuais que podem ser acedidos por pedido. A maioria das empresas adopta esta gama de cloud computing para necessidades suplementares não críticas; 3) Web-Services Provedores de serviços Web oferecem APIs que permitem a desenvolvedores explorar funcionalidades através da Internet sem necessitarem de disponibilizar aplicações completas. Estes variam entre fornecedores de serviços de negócios discretos e grandes APIs disponibilizadas pela Google Maps, pelo Bloomberg e até serviços de processamento de cartões de crédito; 28

42 4) Managed Service Providers (MSP) Uma das formas de cloud computing mais antiquada, um managed service é basicamente uma aplicação exposta às IT e não ao utilizador final, como por exemplo, serviços de scan de vírus de . MSPs usados pela SecureWorks e pela IBM caem nesta categoria, assim como serviços antispam cloud-based. Hoje em dia, com todas estas ligações cloud-based em evidência, a cloud computing surge como uma larga gama de serviços que clientes podem utilizar individualmente. Assim, a ideia de vários serviços a correr numa infra-estrutura ágil e escalável deverá eventualmente fazer parte de cada empresa existente da nuvem. Cloud computing torna-se deste modo um conceito interessante de perspectivar como esta situação utópica de modelos de serviços unificados poderá vir a tratar-se de uma realidade bem sólida na forma de fazer negócio nas organizações de um futuro promissor Tecnologias no Fornecimento de Serviços Web-Services (WS) Os Web-Services dependem da ubiquidade existente nos protocolos internet como é o caso do HTTP (Hypertext Transfer Protocol) e FTP (File Transfer Protocol)[33]. O WSDL (Web-Services Description Language) é baseada na descrição do XML (extensible Markup Language) para poder interligar e descrever os serviços existentes na rede com um conjunto de endpoints (endereços e protocolos) que operam em mensagens, sejam estas orientadas a documentos ou orientadas a procedimentos. As operações e mensagens são descritas de modo abstracto, ligando-se a um protocolo de rede específico e a um formato de mensagem que define o endpoint. O UDDI (Universal Description, Discovery and Integration) é a iniciativa de criar uma plataforma independente e aberta para (1) a descrição dos serviços disponíveis, (2) descobertas de negócios e (3) para a integração de serviços de negócio através da Internet[21]. Modelo dos Web-Services. O modelo dos Web-Services apresenta as seguintes características: Existem três aplicações que desempenham as funções seguintes: pedido de dados, disponibilização dos dados e registo dos serviços; Estas aplicações necessitam de trocar dados ou interagir com outras aplicações. As interacções envolvidas no Modelo Web-Services são: publicar (publishing), procurar (finding) e associar (binding). As interacções iniciais são transformadas em objectos do modelo de Web-Services. Estes objectos incluem o serviço e a sua descrição. SOA e Web-Services (WS). Muitas entidades organizacionais associam o paradigma SOA com Web-Services, mas esta associação não é considerada como a mais apropriada. A arquitectura SOA é governada por um conjunto de princípios, enquanto os WS são apenas um tipo de standard middleware para implementar serviços. 29

43 Esta tecnologia de Web-Services facilita o desenvolvimento de sistemas orientados aos serviços, mas a sua utilização não garante uma iniciativa verdadeiramente aplicada ao paradigma SOA Extensible Markup Language (XML) extensible Markup Language (XML) consiste na linguagem de marcação de dados (meta-markup language) que fornece um formato para descrever dados estruturados, facilitando declarações mais precisas do conteúdo, obtendo melhores resultados nas procuras realizadas através de múltiplas plataformas[53]. O XML permite a definição de um número infinito de tags XML num sistema para criar tags para dados estruturados. As tags XML são adoptadas por intranets das organizações e Internet. Verifica-se uma capacidade em manipular e procurar por dados independentemente das aplicações onde estão alojados. Uma vez que o dado foi encontrado, este pode ser distribuído pela rede e apresentado num browser de várias formas possíveis, ou então esse dado pode ser transferido para outras aplicações para futuro processamento e visualização Simple Object Access Protocol (SOAP) O SOAP é um protocolo em XML que estabelece a troca de informação entre computadores. Muito embora o SOAP possa ser utilizado num número diversificado de sistemas de mensagens e possa ser entregue por diversos protocolos de transporte, o objectivo inicial do SOAP era o transporte por chamada Remote Call Procedure (RPC) via HTTP[54]. O SOAP permite que as aplicações clientes se liguem facilmente a serviços remotos e invoquem métodos remotos. O SOAP é um protocolo que as aplicações utilizam para comunicar num ambiente distribuído. Isto implica que o SOAP possa ser usado para pedir informação numa rede. Como o SOAP utiliza o XML, o pedido pode ser feito de um computador para outro sendo processado em diferentes sistemas operativos. A resposta ao pedido é devolvida à aplicação requisitante no formato de mensagem SOAP. O SOAP é considerado uma base de protocolo ao formato pedido-resposta, como é visível na Figura 9. Figura 9 - Protocolo SOAP [54] Limitações dos Web-Services com SOAP. Pode-se transferir só pacotes de dados usando o SOAP, mas enquanto envia os dados pela rede, primeiro precisa de colocar os dados no formato SOAP, que inclui o SOAP requisitante e a mensagem que necessita de ser transferida. 30

44 Quando o requisitante encontra a aplicação fornecedora, a aplicação envia um Acknowledgement (ACK) para a aplicação requisitante, os dados no formato mensagem XML é passada para a aplicação requisitante. Para isso a aplicação requisitante necessita de um parser para a mensagem XML, para o parsers conseguir extrair a informação dos dados que foram transferidos, requer um código extenso Representational State Transfer (REST) O REST, implementado na a área de cruzamento de fluxos entre organizações, o workflow do REST actua no sentido mais amplo para descrever qualquer interface Web que utiliza também a linguagem XML e HTTP, sem as abstracções adicionais dos protocolos baseados em padrões de troca de mensagens (como é o caso do protocolo SOAP que deriva dos Web-Services). É possível desenhar sistemas de serviços Web de acordo com o estilo arquitectónico do REST, descrito por Fielding. [20] Dado que a definição de REST é muito ampla, é possível afirmar que existe um grande número de aplicações REST na rede (praticamente qualquer coisa acessível mediante um pedido HTTP GET ). De forma mais restritiva, em oposição aos Web-Services e aos RPC s, o REST pode-se encontrar em diferentes áreas da Web: A blogosfera está em sua maior parte, baseado em REST, dado que implica chamar arquivos/ficheiros XML (em formato RSS ou Atom) que contem listas de ligações a outros recursos; A Amazon.com oferece a sua interface tanto em formato REST como em formato SOAP (sendo a versão REST a que recebe maior tráfego cerca de 85%)[43] ; EBay oferece uma interface REST; Bloglines oferece uma API baseada em REST; Yahoo! oferece uma API em REST. De qualquer forma, deve-se ter em mente que as aplicações descritas acima não são total e puramente escritas em REST, isto é, não respeitam todas as restrições que impõe a arquitectura REST, são todas inspiradas em REST e respeitam os aspectos mais significativos e restritivos da sua arquitectura, em particular a restrição de "interface uniforme". Estes serviços são denominados "Acidentalmente RESTful" 2.3. Conclusões Com a análise e pesquisa efectuada para o desenvolvimento deste capítulo, sobressai-se a diversidade ao nível de tecnologias, frameworks e modelos que são disponibilizados e utilizados actualmente, em que cada player defende que a sua solução é a melhor por todos os motivos. 31

45 Cada vez mais se caminha para uma convergência de filosofias e metodologias, no sentido lato, o que vem facilitar a interoperabilidade entre as diferentes aplicações existentes dentro das organizações e com os parceiros de negócio (sejam estes de que sector empresarial se trate). As metodologias, os modelos, as best-pratices e as tecnologias apresentadas vão precisamente nesse sentido, em que já se tenta aproximar à filosofia SOA. Nota-se uma evolução no sentido que os grandes vendedores do mercado, estabelecem uma base comum, definem padrões, o que permitiu agilizar a Internet e favorecer a interoperabilidade entre as suas aplicações. Foram conseguidos avanços significativos, em vários domínios, como exemplo o SOAP (que é o protocolo de excelência dos Web-Services). O REST devido à sua simplicidade por apoiar na estrutura da rede no protocolo HTTP, tem como conceito base os recursos, não precisando de uma interface de descrição, não necessita de ocupar tanta largura de banda (o que lhe aumenta a performance entre grandes sistemas). Seguidamente, na Tabela 2, apresenta-se uma comparação entre a tecnologia de Web- Services com a tecnologia REST. W-S REST Paradigma Centrado nos Documentos Centrado nos Protocolos Visão Um serviço produz um documento; Data binding; Decompõe o universo em recursos tão simples quanto necessário para suportar apenas leitura e escrita; Ênfase Formato da representação dos dados; Protocolo de ligação; Problemas Complexidade; Granularidade; Desempenho; Cliente necessita de conhecer antecipadamente as operações existentes e semântica; Baixo nível; Adequa-se pouco a serviços; Falta de visão semântica; Vantagens Integração Empresarial; Simplicidade; Desempenho; Tabela 2 - Comparação entre Web-Service s e REST É assim neste enquadramento que surge o modelo de serviços unificados usil [1], como um modelo capaz de suportar a metodologia de outsourcing dinâmico e distribuído desenvolvida neste trabalho, devido a: (1) O seu paradigma ser centrado aos serviços; (2) Apresentar como ênfase a interacção directa serviço-a-serviço; (3) Incluir como principais vantagens, tratar-se de ser um modelo unificado que suporta qualquer tipo de serviços e ser genuinamente orientado a serviços. 32

46 3. Trabalho Relacionado (unified Service Implementation Languange) Visão Princípios Estrutura Unified Services Framework Conclusões

47 3.1. Visão A visão que serve de base ao modelo proposto para desenvolver a solução, corresponde a uma sociedade centrada no conceito de serviço, entendido como universal e não apenas num dado contexto. Ou seja, as tradicionais infra-estruturas de suporte ao negócio (IT, logística, distribuição, etc.) devem ser elas próprias parte integrante do negócio e os seus serviços serem considerados serviços de negócio, como qualquer outro. A gestão deve ser global, unificada e dinâmica. Os tradicionais silos organizacionais devem ser essencialmente vistos sobre uma única realidade expansiva e dinâmica, não correspondendo a divisões reais, estanques e estáticas[1] Princípios Com esta solução, pretende-se possuir: (1) A capacidade de analisar e avaliar a envolvente de mercado; (2) A capacidade do outsourcer e do(s) fornecedor(es) se adaptarem ao que o cliente quer; (3) Se os fornecedores estão a ser acompanhados de uma constante monitorização de balanceamento de carga e a serem apoiados por mecanismos de suporte a desastres/recuperações. Assume-se que o comportamento de qualquer sistema pode ser modelado por uma sociedade de serviços implementados com base em recursos e que interagem por troca de mensagens entre si e pela transformação do estado de outros recursos e bens. Os serviços a que este modelo se refere são totalmente genéricos e envolvem todas as áreas, tais como serviços de base informática, logísticos, financeiros, etc. Para tal, o paradigma dos serviços deverá ser encarado como uma especialização do paradigma dos objectos, cujos princípios fundamentais incluem: Um sistema como sendo uma sociedade de objectos que interagem entre si (Figura 10); Um objecto deve encapsular o estado e comportamento, podendo depois ser sujeito ao princípio do encobrimento da informação (escondendo toda a informação que não seja relevante para a interacção entre objectos); O comportamento de um objecto ser passível de organizar em operações, estas constituídas por conjuntos de acções; Os objectos interagem por mensagens, em que cada objecto é que decide o que fazer (que operação invocar) perante o teor da mensagem recebida; Um sistema executado por classes, em que uma classe é a descrição de um dado objecto. Uma classe pode ter muitas instâncias que partilhem a mesma descrição (comportamento e estrutura do estado). O valor do estado não deve ser guardado, pois este é independente de instância para instância; 34

48 Deve ser possível definir uma nova classe (derivada) à custa de outra classe já existente, podendo obter por partilha, a sua descrição, mas com a possibilidade de acrescentar novas características e/ou redefinir as já existentes (herança ou delegação); Suporte para a substituição de um objecto por outro pertencente à mesma classe (ou derivada) sem quebra de capacidade de tratamento das mensagens dirigidas ao objecto original, ou seja suporte do polimorfismo. Figura 10 - Modelo UML simplificado de uma sociedade de serviços [1] No paradigma dos objectos, nada é dito sobre a evolução temporal das classes dos objectos, nem sobre a fiabilidade da existência dos objectos ou do meio de comunicação de mensagens. A noção de distância geográfica e de tempo de comunicação não existem, nem geralmente se tomam medidas especiais de robustez face a eventuais falhas de comunicação entre objectos (o que não propicia uma visão de práticas de outsourcing). O que o paradigma dos serviços unificados pretende, é especializar o paradigma dos objectos de forma a aplicá-lo ao mundo real dos serviços, em que a noções típicas de um sistema distribuído (distância, tempo, fiabilidade e evolução) são fundamentais de se considerar e ter em conta. Assim, pode definir-se o paradigma dos serviços como uma especialização do paradigma dos objectos, mantendo o que este já tem mas explicitando que: Um serviço é uma especialização do conceito de classe, por inclusão das características específicas do paradigma dos serviços (mas os princípios básicos de classe, instanciação, comunicação por mensagens, encobrimento de informação, reutilização por herança, polimorfismo, mantêm-se); 35

49 Um sistema é, em primeira instância, uma sociedade de serviços que interagem entre si. Há objectos que não são serviços (recursos que servem de base à implementação dos serviços, nomeadamente), mas a modelação e organização de sistemas são claramente orientadas aos serviços; Os serviços não têm um comportamento fixo mas pode variar ao longo do tempo, de forma independente dos restantes. Têm um ciclo de vida, que se renova em sucessivas versões; Nenhum serviço pode (deve) depender da fiabilidade da existência de outro nem sequer do meio de comunicação de mensagens entre serviços. Todos os serviços devem estar preparados para não conseguir comunicar com um ou mais dos serviços com que tem previsto interagir (o modo de lidar com essa situação é responsabilidade do serviço) Estrutura Este modelo não se destina apenas a modelar sistemas de informação, mas sim sistemas completos (incluindo as próprias entidades do mundo real) em que os aspectos mais relevantes sejam a organização de entidades que interajam por meio de prestação de serviços. Os serviços dizem assim respeito a qualquer domínio e são ubíquos[1]. É importante referir que um Serviço é, em rigor, uma classe e não passa de um conceito. A instância de um serviço é um objecto cuja funcionalidade pode ser invocada por outra instância de um serviço. No entanto, por simplicidade, designa-se a instância de um serviço simplesmente por serviço. A Figura 11 ilustra a ligação dos vários estágios. A ideia fundamental é que se passa pelos vários estágios de concepção e implementação até chegar ao funcionamento, em que a par da operação se vai avaliando os vários Key Perfomance Indicators (KPI s) do sistema, para verificar se estes estão dentro dos valores esperados. Figura 11 - Fluxograma Conceptual da Cadeia de Estágios do Ciclo de Vida de um Serviço [1] 36

50 Na Tabela 3 demonstra-se em maior detalhe cada uma das Fases do ciclo de vida do serviço, com os seus estágios e principais actividades a concretizarem. Fase Estágio Principais Actividades Estratégia Definição da estratégia; Definição dos KPI's estratégicos de avaliação do serviço. Concepção Análise Análise de Requisitos; Modelo do problema. Design Modelo da Solução; Definição da Arquitectura da Solução; Definição dos KPI's concretos de avaliação do serviço. Desenvolvimento Implementação dos componentes necessários; Gestão desses esforços (Project Management / Workforce Management). Implementação Pré-Produção Montagem de todos os componentes do serviço em pré-produção; Instalação Operação Testes (pré-produção ou de produção parcial). Incorporação do serviço no sistema (colocação em produção); Gestão da configuração dos serviços e componentes. Execução dos pedidos de execução das funções do serviço; Administração do serviço. Produção Monitorização Monitorização do funcionamento operacional do serviço; Avaliação Detecção de Eventos. Avaliação do funcionamento em termos dos KPI's; Gestão do serviço. Libertação dos recursos utilizados por esta versão do serviço; Transição Finalização Passagem de recursos para a nova versão do serviço; Finalização graciosa desta versão do serviço. Extinção Eliminação completa do serviço (sem nova versão); Libertação global de todos os recursos e componentes. Tabela 3 - Fases e Estágios do ciclo de vida de cada versão do serviço [1] 3.4. Unified Services Framework - USF A framework designada por USF (Unified Services Framework), em que a palavra Unified exprime o requisito fundamental de se poder aplicar a qualquer tipo de serviço, num sistema heterogéneo, surge como modelo capaz de expressar e estruturar os diversos aspectos que devem ser tidos em consideração ao conceber, implementar, operar e gerir um serviço ou um grupo de serviços. 37

51 Pretende-se desta framework a possibilidade de desenvolver uma arquitectura de um sistema empresarial com base no paradigma da sociedade de serviços. O USF apresenta a visão pelo ponto de vista de um serviço, pelo que parece faltar a visão global de como é que os vários serviços se coordenam entre si. No entanto, o modelo reflecte apenas a visão recursiva dos serviços. Todo o sistema pode ser descrito por um serviço (visão macro), que depois se pode decompor em serviços de mais baixo nível[1],[3]. Os princípios da framework aplicam-se em qualquer nível de granularidade e abstracção. O USF apresenta uma correspondência à framework de Zachman. No entanto, a framework de Zachman é apenas direccionada a implementações orientadas aos processos[27]. Assim, como principal diferença no USF, é notada a separação dos serviços e dos sistemas em subsistemas. Com esta separação, é possível considerar em maior detalhe cada um desses serviços e é promovido o princípio do encobrimento da informação, reutilização por herança e polimorfismo. O USF usa eixos e células no cruzamento de cada valor possível dos eixos, numa envolvente de cinco dimensões (eixos): 1. Ciclo de Vida (estágios) com graus de granularidade; 2. Intervenção (áreas) com graus de granularidade; 3. Interacção (contextos) valores determinados; 4. Maturidade (grau) - tuplo de valores; 5. Evolução (versões) valores indeterminados. Os três primeiros eixos têm um pequeno número de valores possíveis, mas mesmo esses, podem ser refinados num número muito maior de possibilidades. O número de células é assim potencialmente elevado, o que ilustra a complexidade envolvida no desenvolvimento de um serviço, pelo que o nível de detalhe deve ser ajustado consoante os casos. Para a viabilização de serviços por outsourcing, considera-se a possibilidade de utilização de todos os eixos. Contudo, os mais críticos e que terão maior relevância durante as práticas de outsourcing, são os eixos Ciclo de Vida, Interacção, Maturidade e Evolução Conclusões Pode-se assim concluir, que o principal contributo desta solução traduz-se na implementação, definição e gestão dos módulos que interpretem políticas pré-definidas, nos próprios serviços e/ou no middleware de suporte nas diferentes Fases e Estágios do ciclo de vida dos serviços, para a: (1) Gestão de relações entre entidades, (3) Avaliação dos custos por ter o serviço reservado/previsto nos Fornecedores. (4) Gerir o balanceamento de carga entre os Fornecedores e uma possível produção inhouse, de forma complementar com a estrutura do modelo e framework, suportando assim práticas de Outsourcing genuinamente dinâmicas e distribuídas. 38

52 Metodologia Introdução Fase de Concepção de Serviços Fase de Implementação de Serviços Fase de Operação de Serviços Conclusões

53 4.1. Introdução Com uma investigação no que actualmente se pratica para gerir e conceber serviços por meio de outsourcing, é possível notar como o outsourcing clássico carece duma gestão do risco e acompanhamento inerente á prática de outsourcing duma forma transversal aos ciclos de vida dos serviços e das entidades organizacionais. As best-pratices existentes para a Gestão de Serviço possuem inúmeras interdependências e não cobrem todos os estágios do ciclo de vida dos serviços. Casos como o ITIL, etom, SCOR, contribuem para uma solidificação dos conceitos a ter em conta mas não podem ser considerados como soluções perfeitas. Adicionalmente existe o problema destas frameworks possuírem um carácter organizacional unicamente generalista. O Fornecimento de Serviços apresenta uma panóplia de soluções e ferramentas que pretendem englobar vários sectores de mercados com uma vastidão de níveis de abstracção e camadas de aplicação no intuito de suportar o conceito de Cloud Computing e SOA. Contudo, apenas contribuem para um aumento na dependência de metodologias e frameworks inadequadas (como é o caso dos Web-Services e REST) para este novo paradigma de serviços. Assume-se assim a iniciativa de desenvolver um modelo de referência e a sua metodologia de serviços unificados para a prática e concepção de serviços por outsourcing dinâmico e distribuído. Ao longo das diferentes fases do ciclo de vida do serviço, são identificados os principais módulos que deverão ser incluídos nesta metodologia. Inicialmente, dever-se-á ter em conta o modelo de referência utilizado para suportar a metodologia que é proposta neste trabalho, como é ilustrado na Figura 12. Figura 12 - Modelo de Referência Este modelo de referência pretende demonstrar o fluxo inter-organizacional que existe entre os diversos fornecedores e a entidade outsourcer. Adicionalmente existe também o contacto com o Cliente-Final, mas este é apenas proveniente do outsourcer. Com esta situação genérica, serão abordados os diversos pontos de acção em que se evidenciam as vantagens de utilização deste modelo para a prática de outsourcing dinâmico e distribuído. 40

54 Ao longo deste capítulo serão identificados e definidos os módulos existentes nesta metodologia em função das diferentes fases do ciclo de vida do serviço. Cada um destes módulos irá conter: (1) Os seus objectivos e justificação da sua implementação nas diferentes fases do ciclo de vida dos serviços; (2) Definição das características e componentes destes módulos (3) Os Riscos que necessitam ser averiguados durante o funcionamento e simulação deste modelo. (4) Uma simulação da execução destes módulos com as suas políticas pré-definidas em diferentes cenários do Modelo de Referência. Estes cenários da aplicação do modelo de referência pretendem demonstrar como os problemas inicialmente identificados no inicio deste trabalho poderão ser resolvidos com a adopção desta metodologia e do modelo de serviços unificados usil. Desta sinergia resulta a - Metodologia de Outsourcing Dinâmico e Distribuído num modelo de Serviços Unificados, As principais áreas e estágios de intervenção no ciclo de vida dos serviços para a inclusão neste modelo, são: Fase de Concepção Estágios de Estratégia e Design (Figura 13); Figura 13 - Fase de Concepção 41

55 Fase de Implementação Estágio de Pré-produção e Implementação (Figura 14); Figura 14 - Fase de Implementação Fase de Produção - considerado o estágio de Operação que irá influenciar consequentemente a Fase de Transição (Figura 15). Figura 15 - Fase de Produção Desde a fase de Concepção dos serviços até à fase de Produção dos serviços que é necessário obter informação das métricas obtidas e partilhadas por parte dos fornecedores para a entidade outsourcer que mantém o contacto com o cliente também ter acesso a uma monitorização em tempo real do estado dos serviços que disponibiliza. Em Anexo A, apresenta-se a metodologia com todos os módulos das diferentes fases agregados. 42

56 4.2. Fase de Concepção de Serviço Sendo esta a Fase Inicial do ciclo de vida dos serviços, esta foca-se nos conceitos estratégicos e tácticos na gestão de serviços e de entidades organizacionais. Enumeram-se de seguida os principais focos a considerar no estágio da Estratégia e no estágio de Design dos serviços: Ao nível da Estratégia: Definição da Estratégia; Gestão da Procura; Gestão de Risco. Ao nível do DESIGN: Gestão de Service Agreements; Gestão de Capacidade; Gestão de Fornecedores; Gestão de Risco; Cada um destes módulos, são de seguida analisados e estabelecidos os parâmetros pretendidos nas políticas pré-definidas para suportar um ambiente organizacional de outsourcing. Após a definição do modelo e dos respectivos módulos, expõem-se vários cenários que propõem a aplicação no modelo de referência. Em Anexo B e C, estão ilustrados os diagramas de um possível fluxo de informação dos serviços nestes estágios Estágio de Estratégia dos Serviços Para alcançar os objectivos de negócio, as organizações utilizam qualquer tipo de activo existente, estando sujeitos a variados constrangimentos. Estes incluem custos e riscos associados com a complexidade, incertezas e conflitos existentes na envolvente do negócio. O potencial de criação de valor acrescentado depende do desempenho dos activos de negócio. Estes activos têm de operar imperativamente ao seu máximo potencial, podendo pertencer ao negócio CORE da organização ou ser disponibilizados por outras vias de acordos financeiros. Exemplificando, num sistema da Bolsa de Valores, não é suficiente que este serviço forneça a informação das transferências e transacções em tempo-real, mas que este esteja disponível sem interrupção durante as horas úteis de transacções, com o intuito de minimizar as perdas de informação durante o período de mercado. Para garantir situações como estas, os clientes (Entidades Bancárias de Investimento) poderão estar dispostas a pagar por uma prestação Premium desse tipo de serviços em que era assegurada um maior nível de certeza e fiabilidade em comparação a um serviço utilizado por um concorrente. 43

57 Definição da Estratégia Desenvolver Activos Estratégicos. Tanto a entidade Outsourcer como os Fornecedores deverão considerar a Gestão de Serviços como um activo estratégico e confiar-lhes desafios e oportunidades em termos da Gestão de Clientes, de Serviços e de contratos de suporte. Investimentos realizados em activos confiáveis são menos arriscados quando é demonstrada a capacidade para distribuir e entregar os serviços de forma consistente. Nesta perspectiva, é considerado que a gestão de serviço deverá ser um sistema de controlo fechado, e em constante repetição, possuindo as seguintes principais directrizes: Desenvolver e garantir a manutenção dos Activos de serviço; Compreender o potencial no desempenho dos activos dos clientes; Mapear os activos de serviços em activos de clientes através dos serviços; Planear, desenvolver e operar serviços que sejam adequados; Extrair o potencial do serviço através dos seus activos; Redução de riscos para o Cliente; Controlar o custo dos serviços prestados. Os Activos estratégicos são dinâmicos por natureza. Destes é esperado que garantam o seu desempenho positivo aquando de alterações nas condições de negócio ou de objectivos da sua organização. Este desempenho num futuro imediato deverá beneficiar do conhecimento e da experiência adquirida no passado. O potencial de desempenho dos serviços é primeiramente aumentado com a relação quantitativa adequada entre os serviços a oferecer aos Clientes e o Planeamento do impacto que esses serviços poderão e deverão trazer ao negócio dos Clientes. Para tal ser garantido, as questões chave a ser levantadas e analisadas são: Qual é o Espaço/Área de Mercado? O que é procurado no Espaço de Mercado? Poderá ser oferecido algo único nesse espaço? A envolvente de mercado já se encontra saturada? Existe um Portfolio de Serviços desenvolvido e adequado para o dado Espaço de Mercado? O Catálogo de Serviços é passível de ser ajustado para um dado Cliente? As respostas a estas perguntas provavelmente revelarão padrões que permitem a introspecção de futuras decisões estratégicas. Estas decisões relacionadas formam a base da Avaliação Estratégica, sendo esta influenciada tanto por factores Internos como Externos, como é possível verificar na Tabela 4. 44

58 Factor Descrição Os atributos da organização. (Recursos e capacidades, Qualidade de Forças e Fraquezas Serviço, Qualidade Operacional, Custos de infra-estrutura, Conhecimento do Produto, Relações com os Clientes e Fornecedores. Competências que trazem Distinção Desenvolver respostas para O que torna especial um determinado Fornecedor de Serviços tanto do ponto de vista do negócio como para o Cliente-Final? Factores Críticos para Conceber e decidir informação relevante para responder a Como irá o fornecedor de serviço saber quando atinge o sucesso? Quando garantir sucesso deverão atingir esses factores? Incluir a mentalidade competitiva. Por exemplo, averiguar se existem Ameaças e Oportunidades vulnerabilidades na substituição de um Fornecedor, ou se existem meios para superar a competição das alternativas organizacionais existentes no mercado. Tabela 4 - Factores Internos e Externos considerados para uma Avaliação Estratégica Gestão da Procura de Mercado A Gestão da Procura (Demand Management) é um aspecto crítico e uma fonte de risco devido ao factor de incerteza da procura. O cliente é relutante em pagar por uma dada capacidade que está desocupada ou passiva a menos que esta retorne valor ao negócio do outsourcer que se compromete com o Cliente Final. É deveras importante o estudo do negócio do cliente com a finalidade de identificar, analisar, codificar e padronizar para fornecer informação suficiente à Gestão de Capacidade. Na Figura 16, permite ilustrar como as actividades e planos de negócio dos clientes influenciam os parâmetros das políticas pré-definidas a adoptar na Gestão de Procura. Figura 16 - Influência das Actividades de Negócio da entidade organizacional nos padrões de procura dos Serviços 45

59 A análise e monitorização dos padrões de negócio tornam possível uma previsão da procura dos serviços disponíveis no catálogo de serviços. É também possível prever superficialmente a procura de um activo de serviço que suporte esse serviço. Deve-se definir vários níveis de padrões de procura para garantir uma constante sincronização entre os planos de negócio do cliente com as tarefas a serem designadas pelo fornecedor do serviço. Se um serviço não regulado pede por uma nova alocação de recursos (por exemplo pessoas), a adição desse novo colaborador pode ser traduzido numa procura adicional. Ou seja, é realizado um novo pedido de serviço. Do mesmo modo, os novos casos de negócio podem ser utilizados como uma previsão realizada pela Gestão de Procura do serviço em termos de incidentes e pedidos realizados Gestão de Risco Quando a Gestão de Serviços é eficaz, os serviços no Catálogo de Serviços do outsourcer representam oportunidades para criar valor para os clientes e capturar valor para os interessados. Caso contrário, esses serviços podem ser ameaçados com a possibilidade de falha. A implementação de estratégias muitas vezes requer alterações no Portfolio de Serviços, o que significa a necessidade duma Gestão de Riscos associada. A Figura 18 pretende ilustrar a diferença entre Análise e Gestão quando se fala em Risco. A Análise de Risco deverá estar preocupada com a recolha de informações sobre a exposição ao risco de forma que a organização possa tornar as decisões adequadas e gerir apropriadamente os riscos. A Gestão de Risco implica ter processos paralelos ao desenvolvimento dos serviços para acompanhar os riscos, o acesso e a fiabilidade em manter uma informação actual sobre os riscos. Figura 17 - Etapas da Gestão e Análise do Risco no usil em regime de outsourcing 46

60 Na Figura 17 observam-se as várias etapas da Gestão de Risco e Análise de Risco a manter numa plataforma de serviços unificados em regime de prestação de serviços por outsourcing. É importante frisar que estas etapas devem ser colocadas no contexto de um quadro organizacional para a gestão de risco. Contudo, alguns riscos ligados a tópicos tais como a segurança, são altamente especializados e pelo que esta metodologia terá de ser melhorada pois, nesta perspectiva, apenas prevê uma visão geral de tais aspectos. Riscos com os Fornecedores. Os riscos para a Entidade Empresa surgem quando a sua origem é na incerteza do negócio dos Fornecedores. A materialização dos Riscos em diferentes formas, tais como problemas técnicos, perda de controlo nas operações, falhas de segurança na informação, atrasos no lançamento de serviços, falta de cumprimento regulamentar e curtas quebras financeiras permitem medir os danos resultantes em termos financeiros e em termos de perdas de clientes, fornecedores e parceiros Aplicação no Modelo de Referência Para demonstrar a aplicação destas políticas pré-definidas no modelo de referência, propõem-se dois cenários. Variáveis Consideradas no estágio de Estratégia dos serviços: Recursos Capacidade Custos de Infra-Estrutura Cenário 1 Unindo assim os conceitos referidos do outsourcing clássico com os principais métodos da gestão e fornecimento de serviços, é demonstrando um ambiente de execução desta metodologia. A Figura 19 demonstra uma situação em que o outsourcer pretende obter um serviço do Fornecedor A podendo este ser adaptado aos pedidos variáveis por parte do outsourcer. Nesta situação o outsourcer não necessita de um Fornecedor alternativo, estando o A apto para adaptação pedida pelo outsourcer, responde este: (1) Se essa capacidade é possível ser-lhe reservada e/ou disponibilizada de imediato (Capacidade), (2) Se pretende reserva da restante parte do serviço ou se poderá descartar essa necessidade e considerar essa capacidade como disponível para outras entidades outsourcers (CapacidadeExtra), (3) Os custos adjacentes à disponibilização do serviço (90%) e adicionalmente os custos por necessitar de reservas adicionais. 47

61 O outsourcer decide aceitar a disponibilização dos 90% (CapacidadeA) com 10% (CapacidadeExtraA) adicionais reservados para situações de backup ou de emergência (com os devidos custos), enviando a resposta ao Fornecedor A. Cenário 2 Figura 18 - Cenário 1 do Estágio de Estratégia Na Figura 18, demonstra-se uma situação em que a entidade Outsourcer pretende obter um serviço em que é necessário o envolvimento de duas entidades fornecedoras. Este envolvimento deve-se à impossibilidade de adaptação do Fornecedor A aos pedidos realizados pelo Outsourcer. Supondo-se uma situação em que se pretende evitar uma sobrecarga dos pedidos dos Clientes- Finais por um determinado serviço ou recurso (exemplificando uma futura época-alta para o negócio), o Outsourcer pretende aumentar a capacidade anteriormente disponibilizada em mais 20% (CapacidadeA). Dado existir uma protecção de informação, o outsourcer não tem obrigação de saber qual a capacidade total de uma entidade fornecedora. Poderá apenas saber se a capacidade contratada com o Fornecedora A, neste caso 100%, era fornecida com os níveis de qualidade estabelecidos. Não conseguindo obter a totalidade da capacidade que iria necessitar, o Outsourcer procede ao estabelecimento de contacto com a entidade Fornecedora B. 48

62 Figura 19 - Cenário 2 do Estágio de Estratégia Nesta situação, igualmente como na Figura 19, não irá necessitar da totalidade da capacidade oferecida pelo fornecedor B sobre um determinado serviço (CapacidadeB). 49

63 O fornecedor, estando este apto para adaptação responderá ao outsourcer: (1) Se essa capacidade (CapacidadeB) é possível ser-lhe reservada e disponibilizada de imediato, (2) Se pretende reserva da restante parte do serviço ou se poderá ser considerado como capacidade disponível para outras entidades outsourcers (CapacidadeExtraB), (3) Os custos adjacentes à disponibilização do serviço (20%) e adicionalmente os custos por necessitar de reservas adicionais (CustosB). O outsourcer decide aceitar a disponibilização dos 20%, descartando a possibilidade reserva de capacidade em excesso (80%) (CapacidadeExtraB) Estágio de Design de Serviço O Design de um serviço é importante neste paradigma pois trata-se de um ponto de incubação que requer a propagação das suas actividades a todos os módulos que garantem o Fornecimento dos Serviços ao longo de toda a sua cadeia de valor. Ao conceber ou alterar um serviço, é importante que todos os intervenientes do ciclo de vida do serviço estejam envolvidos desde início. É comum e provável que exista a possibilidade de um serviço recém-concebido ter de ser implementado e estar operacional em situações de último minuto para o Cliente. Isto traduz-se na necessidade do conhecimento antecipado dos Fornecedores sobre os Pedidos de Serviços, Disponibilidade e Capacidade que poderão ser inquiridos a estes pela entidade Outsourcer. Os Objectivos deste estágio de Design do ciclo de vida dos serviços são: Fornecer uma abordagem pré-definida para a concepção de novos serviços ou para a alteração de serviços a serem transitados e implementados para o ambiente de produção e operação; Garantir que existe informação oriunda do estágio de Estratégia dos Serviços para que estes sejam concebidos de forma a estarem alinhados e satisfaçam os objectivos de negócio; Desenhar os serviços de acordo com uma escala de Custo e Tempo, uma vez que os serviços precisam de ser entregues nos prazos acordados e dentro dos custos esperados; Identificar e gerir riscos que sejam provenientes do estágio de Estratégia, realizando um mapeamento completo dos possíveis riscos. Os módulos de gestão que se consideram fundamentais de serem incluídos (e que são descritos em maior detalhes seguidamente) para suportar práticas de outsourcing neste estágio são: (1) Gestão de Service Agreements (SA); (2) Gestão de Capacidade; (3) Gestão de Fornecedores; (4) Gestão de Risco; Após a definição do modelo e dos respectivos módulos, expõem-se vários cenários que propõem a aplicação no Modelo de Referência. 50

64 Gestão de Service Agreements Tendo em vista o que actualmente é praticado para a gestão do outsourcing clássico é dado um especial foco à gestão dos níveis de serviço. Nesta metodologia, mais importante do que a gestão e protecção dos níveis de desempenho contratados com as entidades externas, é a capacidade de descoberta de uma entidade outsourcer por uma entidade fornecedora que possua uma política-prédefinida ou variável Funcionalidades de Serviço. Com esta informação sobre a funcionalidade de serviço, pretende-se definir e publicar de forma padronizada quais os serviços que uma entidade fornecedora concebe ou concretiza. Para interiorizar este conceito, segue-se o seguinte exemplo: Uma entidade outsourcer do sector têxtil, necessita de um fornecedor que lhe consiga fornecer unidades de camisas concebidas em algodão. Nesta situação, não é de maior relevância a questão de a camisa ser concebida com 100% de algodão ou 10% de algodão e 90% polyester, mas sim que as camisas contenham tecido de algodão. É por esta importância ser mais elevada em saber qual o tipo de serviço que é disponibilizado pelos fornecedores do que com que níveis de desempenho este vem agregado, que é proposto a implementação do módulo de Gestão de Service Agreements (SA s) nesta metodologia. Os Service Agreements deverão ser uma estrutura com os diversos documentos para a gestão dos serviços e dos seus contratos inter-organizacionais inerentes. Assim sendo, toda a documentação que está relacionada com a gestão dos níveis desses serviços também é incorporada nos SA s, como é ilustrado na Figura 20. Figura 20 - Conteúdo de um Service-Agreement A Figura 21 demonstra que o módulo de Gestão de Service Agreements, trata da criação e documentação de objectivos através de Funcionalidade de Serviços, SLA s, SLR s e OLA s. 51

65 Gestão de Capacidade A Gestão de Capacidade necessita de uma relação constantemente bidireccional com os estágios de Estratégia e Design dos serviços. Durante a Estratégia de serviço são estabelecidos planos de negócio e como os serviços poderão suportar essas estratégias. Estes Planos são desenvolvidos com o foco em estabelecer uma compreensão clara sobre os factores externos (como o potencial dos diversos Fornecedores e das suas capacidades de entrega). Entenda-se que a Gestão de Capacidade é essencialmente um módulo que procura de forma constante ao longo do ciclo de vida dos serviços, assegurar um Plano de Balanceamento de Carga. Este balanceamento de carga, como ilustrado na Figura 21 traduz-se em: Figura 21 - Balanceamento de Carga em regime de outsourcing Balanço de Custos Vs. Recursos Necessários: a necessidade de assegurar que a capacidade de processamento dos serviços é comparada entre a verificação dos custos dispendidos com a necessidade do negócio e também com a necessidade de utilizar esses recursos de forma optimizada e dinâmica. Balanço de Recursos Vs. Procura de Mercado: as necessidades de assegurar os Fornecedores dados como disponíveis estão capazes de suportar as procuras expectáveis pelo cliente (tanto no presente como no futuro). Poderá ser necessário também gerir e controlar a Procura (Demand) de um recurso em particular. Um exemplo para tal, é um Hotel que em Época Alta considera previsível a necessidade de um maior número de Funcionários. Mas por se tratar de uma situação mediática (por razões políticas ou religiosas) é gerada uma necessidade imediata do aumento de funcionários (independentemente de se tratar de uma época com maior ou menor afluência turística). Situações como estas estão previstas para serem suportadas nesta metodologia. 52

66 Plano de Capacidade. É, essencialmente, um plano da capacidade de um determinado serviço existente, concebido e disponibilizados por várias entidades organizacionais. Este Plano de Capacidade deverá estar alinhado com o negócio e com o orçamento previsto para o ciclo de vida dos serviços. A produção e manutenção do Plano de Capacidade deverão ocorrer em intervalos prédefinidos estando a sua manutenção (revisão) sempre terminada antes do começo de novas negociações ou activação com Fornecedores Alternativos (ou de Plano-B). Os principais Conteúdos e Contextos do Plano de capacidade são: Gestão de Capacidade do negócio: Esta variável pretende traduzir as necessidades existentes nos planos de negócios para os serviços e para as infra-estruturas organizacionais, assegurando-se de que futuras exigências de negócio para o fornecimento de serviços é quantificada, projectada, planeada e implementada duma forma oportuna. Isto deverá ser conseguido usando os dados existentes sobre a actual utilização de recursos pelos vários Fornecedores. Estas exigências vêm dos estágios de Estratégia e Design com informações e requisitos tanto para novos serviços, como para a melhoria e evolução dos serviços existentes; Gestão de Capacidade de serviço: É focada uma especial atenção sobre a gestão, controlo e previsão do desempenho e capacidade dos Serviços existentes; Pretende-se que esta variável seja capaz de gerir e controlar o desempenho, utilização e capacidade de um determinado serviço (independentemente de este se tratar de IT ou não). Como é demonstrado na Figura 22, a Gestão de Capacidade intervém tanto de forma pró-activa, como reactiva. Figura 22 - Intervenção Pró-activa e Reactiva da Gestão de Capacidade 53

67 Nesta metodologia de outsourcing dinâmico e distribuído, a Gestão de Capacidade pretende influenciar o modo como a capacidade dos serviços é controlada Gestão de Fornecedores Os serviços podem ser adquiridos a partir de um único ou vários fornecedores. Neste modelo, os serviços são mais susceptíveis de serem provenientes de dois ou mais fornecedores concorrentes, onde a necessidade padrão para os serviços ou produtos é garantirem que estes são facilmente disponibilizados. Esta noção de Outsourcing dinâmico e distribuído pretende criar valor e distinção com a capacidade de dividir e difundir o Risco pelos vários intervenientes. O objectivo fundamental da Gestão de Fornecedores é garantir que o valor dos fornecedores está plenamente realizado. Este valor é obtido através de todos os aspectos de relacionamento desde a garantia de desempenho operacional até à capacidade de resposta a mudanças exigidas com as flutuações da procura. O outsourcer deve também garantir que as prioridades de negócio correspondem às prioridades dos fornecedores. Um fornecedor deve compreender quais os serviços que são mais significativos para o negócio. Para garantir que todas as actividades e contactos com um fornecedor são coerentes e coordenadas, cada fornecedor deve ter um único registo com informação sobre todos os serviços que é responsável. A Gestão de Fornecedores deverá realizar também: A Categorização dos fornecedores (Principal, Secundário, Plano-B) e manutenção da Supplier and Contracts Database (SCD); A avaliação e criação de novos contratos com fornecedores; O estabelecimento e oficialização dos novos fornecedores; Garantir o desempenho dos fornecedores segundo os seus contratos (procedendo quando necessário a uma renovação ou rescisão destes). Supplier and Contract Database (SCD). Num fluxo organizacional com serviços fornecidos por múltiplas entidades fornecedoras, terá de se atribuir uma categoria de Fornecedor Principal e uma de Fornecedor Secundário para cada serviço disponível no Catálogo de Serviços do Outsourcer. Para além da Categorização atribuída a cada Fornecedor, deverá também existir um Classificação para estes no que toca à sua intervenção na concepção do Serviço-Final. Estas Classes dos Fornecedores poderão ser de teor: Estratégico: para uma relação de Parceria que envolva partilha confidencial de informações estratégicas para facilitar planos e estratégias de longo prazo. Relações com Fornecedores desta Classe exigem um envolvimento da informação obtida a Fase de Concepção; 54

68 Táctico: para os relacionamentos que envolvem uma significativa actividade comercial e interacção com o negócio das entidades organizacionais. Esta Classe de Relações requer um contacto regular entre as entidades e aferir revisões do desempenho obtido das transições de serviços entre estas; Operacional: para os fornecedores de produtos ou serviços operacionais. Nesta classe, poderá envolver um menor acompanhamento devido à sua baixa complexidade e significância no negócio final. Com esta classificação pretende-se definir uma relação entre: (1) o Valor e Importância dos Fornecedores, com (2) o Risco e Impacto que estes fornecedores poderão trazer ao negócio. Como é possível observar na Figura 23, são os fornecedores estratégicos que representam maior valor ao negócio, mas são também os que possuem maior risco e impacto em situações de desastre. Para tal, a solução mais conveniente seria realizar um ajuste do Timer da variável Disponibilidade com um menor período entre actualizações das informações sobre esses Fornecedores (como por exemplo, Estado Activo/Inactivo, a sua Capacidade e Disponibilidade). Figura 23 - Relação de Valor e Risco das várias classes de fornecedores 55

69 Gestão de Risco Neste estágio do ciclo de vida, a área de risco associado foca-se no módulo de Gestão de Fornecedores e à informação existente na SCD. Esta área inclui riscos como: A falta de empenho das entidades em tratar a Gestão de Fornecedores como um fluxo interorganizacional; Fornecedores concordarem com metas e níveis de serviço que são impossíveis de satisfazer, ou fornecedores que falham e são incapazes de satisfazer as condições do contrato; A cultura organizacional dos Fornecedores não estarem alinhadas com a da Empresa; Os fornecedores não são cooperativos e não estão dispostos a participar no apoio necessário ao módulo de Gestão de Fornecedores; As exigências das empresas e dos procedimentos contratuais serem excessivos e burocráticos Aplicação no Modelo de Referência Para demonstrar a aplicação destas políticas pré-definidas no modelo de referência, propõem-se os seguintes três cenários. Variáveis Consideradas no módulo de Gestão de Capacidade: Disponibilidade (e o seu respectivo Timer); PlanoCapacidade(negocio,serviço); Desempenho (dos serviços); Capacidade; Cenário Inicial (antes de Cenário 1 e 2 ocorrerem) Na Figura 25, é simulado uma timeout realizado por um Timer que existiria neste modelo como forma para obter uma renovação da informação aos fornecedores existentes com a actualização das seguintes variáveis: (1) Qual a Disponibilidade dos fornecedores; (2) Quais as Capacidades disponibilizadas ao outsourcer; (3) O Plano de Capacidade tendo em conta as especificações do negócio acordado dos serviços com as especificações do que o Fornecedor está a disponibilizar ao outsourcer; (4) O Desempenho com que um serviço está a ser executado e/ou fornecido (caso sejam Fornecedores Activos) e o Desempenho acordado com os Fornecedores Inactivos (quer estes sejam Fornecedores Activos ou Inactivos). 56

70 Figura 24 - Timer comum ao Cenário 1 e 2 do Estágio de Design Cenário 1 Na situação da Figura 24 para demonstrar uma intervenção da Gestão de Capacidade de forma pró-activa, simula-se um cenário em que se prevê uma procura em excesso tendo em conta os recursos que o outsourcer possui no momento. Numa relação entre a tendência da procura com a verificação da disponibilidade de um determinado serviço ao Cliente-Final por parte do outsourcer, este procede à activação da função EpocaAlta(). Com esta situação, pretendendo suportar uma possível super-afluência a um determinado serviço, o Outsourcer pretende aumentar os 40% de capacidade que lhe era fornecida pelo Fornecedor A (CapacidadeA), e se necessário proceder à activação do Fornecedor B para lhe requisitar uma determinada capacidade adicional (CapacidadeB). O outsourcer realiza então o pedido de: (1) Aumentar a capacidade fornecida pelo Fornecedor A de 40% para 100% (CapacidadeA), (2) Activar o Fornecedor B uma vez que este deu a indicação de estar inactivo (ou seja, que não possuía nenhuma informação nem pedido de fornecimento de serviços por parte do outsourcer. Para além da activação, o especifica que para esta situação, a capacidade que vai necessitar é entre 0 e 50%. Desta forma demonstra-se a dinâmica pró-activa das entidades com o Fornecedor A sob utilização máxima, e o Fornecedor B activo, com possibilidade de utilização até 50%. 57

71 Figura 25 - Cenário 1 do Estágio de Design (Simulação de Gestão de Capacidade de natureza Pró-Activa) Esta oscilação na definição da capacidade necessária do Fornecedor B surge por razões em diferentes perspectivas. Na perspectiva do outsourcer, deve-se a que esta activação de EpocaAlta() é baseada em tendências e previsões. Não sendo possível obter valores com precisão, estabelecem-se limites mínimos e máximos de forma a diminuir o risco. Na perspectiva do Fornecedor, com uma aproximação dos limites de utilização máxima que este fornecedor deverá reservar para este outsourcer, existe uma possibilidade para o Fornecedor B rentabilizar o seu negócio com a possibilidade de destacar parte ou totalidade desses restantes 50% a outras entidades empresariais. (Figura 25) 58

72 Cenário 2 Na situação da Figura 26, para demonstrar a intervenção da Gestão de Capacidade de forma reactiva, simula-se um cenário em que é accionado um Trigger desencadeado por parte do Fornecedor A, em que este reduz a sua capacidade disponível para o outsourcer de forma drástica. O Fornecedor notifica o outsourcer com a informação que lhe é possível disponibilizar e pede por indicações para tentar regularizar o negócio. Sendo para o outsourcer impossível assegurar qualidade nos serviços fornecidos ao Cliente-Final, procede: (1) à activação do Fornecedor B, (2) ao pedido de uma capacidade entre 30% a 40%; Figura 26 - Cenário 2 do Estágio de Design (Simulação de Gestão de Capacidade de natureza Reactiva) 59

73 Novamente verifica-se um intervalo de capacidade requisitado ao Fornecedor B, uma vez que o outsourcer pretende assegurar que no mínimo consegue assegurar os 40% de Capacidade de um serviço (como era inicialmente a posição de fornecimento com o Fornecedor A). Caso este possa falhar os restantes 10% (CapacidadeA) que estão a ser disponibilizados, o outsourcer passa a obter a totalidade da capacidade necessária de um serviço a partir do Fornecedor B com os 40% (CapacidadeB). Desta Forma, completa-se o cenário de reactividade da gestão das capacidades de várias entidades envolvidas no Modelo de Referência. Cenário 3 Variáveis Consideradas no módulo de Gestão de Fornecedores: CategoriaFornecedor (PrincipalSecundário Plano-B); ClasseFornecedor(Estratégico,Táctico,Operacional); Plano de Capacidade; Base de Dados - SCD Service Agreement (SLA,SLR,OLA,Detalhes) - permitindo a possibilidade de monitorização e revisão destes sobre possíveis rupturas de fornecimento); Na Figura 27, demonstra-se como a SCD de um outsourcer deverá proceder à actualização das informações existentes sobre os Fornecedores com quem estabelece relações. Neste cenário, é exemplificado o Fornecedor A como sendo o Fornecedor Principal. Por consequência directa, este Fornecedor é de classe Estratégica. O Fornecedor B, surge como sendo um Fornecedor Secundário. Esta categoria de Fornecedor Secundário, aliada à sua classe de Fornecedor Táctica, pretende realçar que este fornecedor poderá ser activado e começar a fornecer o Outsourcer tanto em situações de emergência (actuando como um Fornecedor de Disaster-Recovery), ou suportar o Fornecedor A no fornecimento do serviço ao outsourcer (actuando como um Fornecedor de Backup). 60

74 Figura 27 - Supplier Contract Database A SCD apresenta-se como uma base de dados integrante de um núcleo de base de dados abordado na Fase de Implementação, designado como Knowlegde Management Database (KMDB) Fase de Implementação de Serviço Na Fase de Implementação, pretende-se focar todos os aspectos da execução de um serviço, no ciclo de vida dos serviços unificados. É necessário garantir que um serviço possa funcionar tanto em circunstâncias de extrema previsibilidade como em situações anormais. No caso de transição e instalação de serviços entre entidades por práticas de outsourcing, as principais metas a atingir (durante a execução de um serviço quer em produção in-house quer por meio de outsourcing) são: Garantir que o serviço pode ser utilizado em conformidade com os requisitos e limiares especificados no âmbito do serviço; Reduzir as variações do desempenho previsto e real de serviço implementado; Reduzir os erros conhecidos e minimizar os riscos durante a transição de serviços novos ou alterados, para produção; Aumentar a satisfação do cliente, do utilizador com a inclusão de novos serviços, comunicações, documentação, formação e transferência de conhecimento entre os intervenientes das várias entidades envolvidas; Melhoria das comunicações e inter-equipas de trabalho (outsourcer, clientes, utilizadores e fornecedores). 61

75 Estas metas só poderão ser atingidas se existir uma implementação de sistemas capazes de suportar esta metodologia. Assim, considera-se crucial e fundamental que todas as entidades intervenientes possuam sistemas que suportem o usil Estágio de Pré-Produção e Implementação de Serviço Nesta Fase, consideram-se os módulos de: (1) Gestão de Conhecimento (no estágio de pré-produção); (2) Gestão de Alterações (no estágio de implementação). Após a definição do modelo e dos respectivos módulos desta fase e seu e estágio, expõem-se vários cenários que propõem a aplicação no modelo de referência Gestão do Conhecimento A Gestão do Conhecimento (Knowledge Management) pretende assegurar que a informação certa é entregue até à entidade competente para no momento certo tomar uma determinada decisão. Numa prática de outsourcing, em que estão múltiplas entidades a participar na produção e fornecimento de um serviço, considera-se vital manter uma qualidade na informação que percorre neste fluxo inter-organizacional proposto. Objectivos. Os objectivos da Gestão do Conhecimento incluem: Influenciar os fornecedores de serviços a serem mais eficientes e a melhorarem a qualidade dos serviços, Aumentar a satisfação não só do Cliente-Final, mas de todas as Entidades organizacionais; Facilitar o acesso a conhecimento valioso partindo de entidades externas (dados, metaserviços, informações) provenientes de diversas fontes (tais como as informações existentes na SCD). Knowledge Management Database (KMDB). Durante o ciclo de vida do serviço, uma organização precisa de se concentrar em recuperar, partilhar e utilizar os seus conhecimentos através da resolução de problemas e tomada de decisões. Para alcançar este objectivo, o conhecimento precisa de ser transferido entre as várias entidades envolvidas na prática de outsourcing para as outras entidades ao longo do ciclo de vida dos serviços. É nesta perspectiva que é proposto uma base de dados de Gestão de Conhecimento que engloba outras Base de Dados específicas. 62

76 Gestão de Alterações O módulo de Gestão de Alterações assegura que as Alterações e Correcções nos serviços, são registadas, avaliadas, autorizadas, planeadas e testadas através de uma implementação e documentação desta. Apresenta como principal objectivo garantir que sejam utilizados métodos padronizados para a movimentação rápida e eficiente de todas as Alterações a serem desencadeadas. Consequentemente, pretende-se assegurar que o risco global das entidades é optimizado com a definição adequada nas políticas pré-definidas. A Figura 28, pretende demonstrar como a Gestão de Alterações deverá ser considerada como um dos módulos fundamentais para a gestão de serviços por outsourcing, devido à sua relevância no ciclo de vida do serviço. Poderão surgir alterações de várias naturezas para implementar no modo como esses serviços são fornecidos (Estratégico, Táctico e/ou Operacional) Figura 28 - Âmbito da Gestão de Alterações no Fornecimento de serviços num ambiente de outsourcing dinâmico e distribuído A Gestão de Alterações deverá proporcionar para o negócio, a redução de erros nos serviços e uma implementação mais exacta das mudanças de entidades fornecedoras. A existência de Confiança e Garantia de continuidade dos serviços são essenciais para o sucesso e a sobrevivência de qualquer organização. Tipos de Alterações nos Serviços. Existem vários tipos de Incidentes e Eventos durante os estágios de Operação e Produção num serviço que pode levar a uma obrigatoriedade de alteração do serviço disponibilizado ao Cliente-Final. Classificam-se os seguintes tipos de Alteração consoante a sua natureza: 63