Outsourcing Dinâmico e Distribuído · esta prática é passível de ser executada com...
120
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: Professor Doutor Rui Jorge Morais Tomaz Valadas Orientador: Professor Doutor José Carlos Martins Delgado Vogais: Professor Rui António dos Santos Cruz Setembro de 2009
Transcript of Outsourcing Dinâmico e Distribuído · esta prática é passível de ser executada com...
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: Professor Doutor Rui Jorge Morais Tomaz Valadas
Orientador: Professor Doutor José Carlos Martins Delgado
Vogais: Professor Rui António dos Santos Cruz
Setembro de 2009
ii
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!
iii
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.
iv
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).
v
Í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 …………………………………………………………………………………….. 1
1.1. Motivação e Enquadramento ………………………………..…………………………… 2
1.2. Objectivos ……………………………………………………….………………………….. 4
1.3. Cenário (Requisitos) ………………………………………………..……………………... 4
1.4. Contribuição ……………………………………………………………..……………….... 6
1.5. Estrutura do Documento….…………………...………………………………………...… 7
Capítulo 2 – Estado da Arte (Outsourcing Clássico + Gestão e Fornecimento de Serviços) … 8
2.1. Outsourcing Clássico ………………………………………………………. ………………… 9
2.1.1. Gestão Estratégica no Outsourcing ……………………………………………... 10
2.1.2. Modelo de Maturidade do Mercado de Outsourcing …………………………… 11
2.1.3. Gestão de Risco ………………………………………………………………….… 12
2.1.4. Service-Level-Agreement (SLA) ……………………………………………….… 14
2.2. Gestão e Fornecimento de Serviços ……………………………………………………….... 17
2.2.1. Gestão de Serviços IT ……………………………………………………………... 17
2.2.2. Boas-Práticas e Modelos ………………………………………………………….. 17
2.2.2.1. Six Sigma ………………………………………………………………... 17
2.2.2.2. ISO/IEC 17799:2005 …………………………………………………… 18
2.2.2.3. Control Objectives for Information and related Technology (CobIT). 19
2.2.2.4. enhanced Telecom Operations Map (eTOM) ………………………. 20
2.2.2.5. Information Technology Infrastructure Library (ITIL) v3 ……………. 22
2.2.2.6. Supply-Chain Operations Reference (SCOR) ………………………. 24
2.2.3. Service-Oriented Architecture (SOA) …………………………………………….. 26
2.2.4. Cloud Computing …………………………………………………………………... 29
2.2.5. Tecnologias no Fornecimento de Serviços ……………………………………... 30
2.2.5.1. Web-Services (WS) …………………………………………………….. 30
2.2.5.2. Extensible Markup Language (XML) …………………………………. 31
vi
2.2.5.3. Simple Object Access Protocol (SOAP) ……………………………… 31
2.2.5.4. Representational State Transfer (REST) …………………………….. 32
2.3. Conclusões ……………………………………………………………………………………... 32
Capítulo 3 - Trabalho Relacionado (unified Service Implementation Language) ………………. 33
3.1. Visão ……..…….………………….…………………………………………………….…….… 34
3.2. Princípios ……...……………………………………………………………………………..…. 34
3.3. Estrutura …………………………………………………………………………………….…... 36
3.4. Unified Services Framework ……………………………………………………..……….….. 37
3.5. Conclusões …………………………………………………………………………………….. 38
Capítulo 4 – Metodologia ………………………………………………………….……………………….. 39
4.1. Introdução ………………………………….…………………………...………………………. 40
4.2. Fase de Concepção de Serviços ….………….………………………….………………...... 43
4.2.1. Estágio de Estratégia dos Serviços ………………………………………………. 43
4.2.1.1.. Definição da Estratégia ……………………………………………….. 44
4.2.1.2. Gestão da Procura de Mercado ………………………………………. 45
4.2.1.3. Gestão de Risco ………………………………………………………… 46
4.2.1.4. Aplicação no Modelo de Referência ………………………………….. 47
4.2.2. Estágio de Design de Serviço …………………………………………………….. 50
4.2.2.1. Gestão de Service Agreements ………………………………………. 51
4.2.2.2. Gestão de Capacidade ………………………………………………… 52
4.2.2.3. Gestão de Fornecedores ………………………………………………. 53
4.2.2.4. Gestão de Risco ………………………………………………………… 54
4.2.2.5. Aplicação no Modelo de Referência ………………………………….. 57
4.3. Fase de Implementação de Serviços …………….………………………………..……...…. 61
4.3.1. Estágio de Pré-Produção e Implementação de Serviço …………..…………… 62
4.3.1.1. Gestão do Conhecimento ……………………………………………..………… 62
4.3.1.2. Gestão de Alterações ………………………………………………….. 63
4.3.1.3. Gestão de Riscos ……………………………………………….………. 64
4.3.1.4. Aplicação no Modelo de Referência ………………………..………… 65
4.4. Fase de Operação de Serviços ……………………….…………………………….…...…… 69
4.4.1. Estágio de Operação …………………………………………………………..… 70
4.4.1.1. Gestão de Eventos …………………………………………………….. 71
4.4.1.2. Gestão de Incidentes …………………………………………………… 71
4.4.1.3. Gestão de Problemas ……………………………………….………….. 71
4.4.1.4. Gestão de Riscos ………………………………………………………...72
4.4.1.5. Aplicação no Modelo de Referência …………………….……………. 73
4.5. Conclusões …………………………………………………………………….…………… 74
vii
Capítulo 5 – Validação do Conceito (Proof-of-Concept) .,,,,,………………………………………… 75
5.1. Caso de Estudo …...……………………..…………………………………………………….. 76
5.2. Conclusões ………………………..……………………………………………………………. 81
Capítulo 6 – Conclusões e Trabalho Futuro ……………………………………………………………. 82
6.1. Conclusões ……...………………………..…………………………………………………….. 83
6.2. Trabalho Futuro …,,,,,,,…………………..…………………………………………………….. 84
Capítulo 7 – Referências …………………………………………………………………………………. 85
Anexo A – Metodologia de Outsourcing Dinâmico ....................................................................…… 89
Anexo B – Diagrama de Fluxo no estágio de Estratégia dos Serviços ...………………………..…… 91
Anexo C – Diagrama de Fluxo no estágio de Design dos Serviços ……………………………..….… 93
Anexo D – Mapa Conceptual para a Gestão de Risco ……………………..……………………..…… 95
Anexo E – Anexo de Boas-Práticas ………………………………………………….…………………… 97
Anexo E.1 - ISO 20000 ………………………………………………………..…………………… 98
Anexo E.2 - CobIT .………………………………………………………………………………... 99
Anexo E.3 - eTOM ………………………………………………………………………………... 102
Anexo E.4 - SCOR .……………………………………………………………………………….. 106
viii
Lista de Tabelas
Tabela 1 - Outsourcing de SI...............................................................................................................3
Tabela 2 - Comparação entre Web-Service’s e REST ....................................................................... 32
Tabela 3 - Fases e Estágios do ciclo de vida de cada versão do serviço ........................................... 37
Tabela 4 - Factores Internos e Externos considerados para uma Avaliação Estratégica .................... 45
Tabela 5 - Categorização dos Riscos ................................................................................................ 65
Tabela 6 - Tabela de Classificação do Impacto ................................................................................. 71
Tabela 7 - Tabela de Classificação da Urgência ................................................................................ 71
ix
Lista de Figuras
Figura 1 - Modelo de maturidade do mercado outsourcing ................................................................ 10
Figura 2 - SLA com estrutura baseado no serviço ............................................................................. 14
Figura 3 - SLA com estrutura baseado no cliente .............................................................................. 14
Figura 4 - SLA com estrutura multi-nível ............................................................................................ 15
Figura 5 - Modelo do CobIT e dos seus principais domínios de aplicação .......................................... 19
Figura 6 - Mapa de Processos da framework eTOM .......................................................................... 21
Figura 7 - Modelo organizacional de alto nível dos cinco processos do SCOR................................... 24
Figura 8 - Colaborações SOA ........................................................................................................... 26
Figura 9 - Protocolo SOAP ................................................................................................................ 30
Figura 10 - Modelo UML simplificado de uma sociedade de serviços ................................................. 35
Figura 11 - Fluxograma Conceptual da Cadeia de Estágios do Ciclo de Vida de um Serviço ............. 36
Figura 12 - Modelo de Referência ..................................................................................................... 40
Figura 13 - Fase de Concepção ........................................................................................................ 41
Figura 14 - Fase de Implementação .................................................................................................. 42
Figura 15 - Fase de Produção ........................................................................................................... 42
Figura 16 - Influência das Actividades de Negócio da entidade organizacional nos padrões de procura
dos Serviços ..................................................................................................................................... 45
Figura 17 - Etapas da Gestão e Análise do Risco no uSIL ................................................................. 46
Figura 18 - Cenário 1 do Estágio de Estratégia ................................................................................. 48
Figura 19 - Cenário 2 do Estágio de Estratégia ................................................................................. 49
Figura 20 - Conteúdo de um Service-Agreement ............................................................................... 51
Figura 21 - Balanceamento de Carga em regime de outsourcing ....................................................... 52
Figura 22 - Intervenção Pró-activa e Reactiva da Gestão de Capacidade .......................................... 53
Figura 23 - Relações de Valor e Risco das várias classes de fornecedores ....................................... 55
Figura 24 - Timer comum ao Cenário 1 e 2 do Estágio de Design ..................................................... 57
Figura 25 - Cenário 1 do Estágio de Design (Simulação de Gestão de Capacidade de natureza Pró-
Activa) .............................................................................................................................................. 58
Figura 26 - Cenário 2 do Estágio de Design (Simulação de Gestão de Capacidade de natureza
Reactiva) .......................................................................................................................................... 59
Figura 27 - Supplier Contract Database............................................................................................. 61
Figura 28 - Âmbito da Gestão de Alterações no Fornecimento de serviços num ambiente de
outsourcing dinâmico e distribuído .................................................................................................... 63
Figura 29 – Cenário 1 do Estágio de Implementação (Knowledge Management Database) ............... 66
Figura 30 - Cenário 2 do Estágio de Implementação (Fase Inicial) .................................................... 67
Figura 31 - Cenário 2 do Estágio de Implementação (Final) .............................................................. 68
Figura 32 - Visão Interna Vs. Visão Externa do Negócio .................................................................... 69
Figura 33 - Estabilidade Vs. Tempo de Resposta .............................................................................. 69
x
Figura 34 - Qualidade de Serviço Vs. Custo de Serviço ..................................................................... 69
Figura 35 - Actividades Reactivas Vs. Actividade Pró-activas ............................................................ 70
Figura 36 - Medidas de Disponibilidade ............................................................................................. 72
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) ....................................................................................................... 73
Figura 38 – Visão da Entidade Cliente .............................................................................................. 76
Figura 39 - Cenário de Activação dos sub-serviços do Marca Plano de Viagem Turística .................. 77
Figura 40 - Cenário de Falha do Fornecedor Hotel 1 ......................................................................... 78
Figura 41 - Cenário de Falha do Fornecedor Rent-A-Car X ............................................................... 79
Figura 42 - Cenário de Falha do Fornecedor Agência Excursões @ .................................................. 80
xi
Acrónimos
API Application Programming Interface
CEO Chief Executive Officer
CFO Chief Financial Officer
CIO Chief Information Officer
CTO Chief Technology Officer
COBIT Control Objectives for Information and related Technology
eTOM Enhanced Telecom Operations Map
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
IEC International Electrotechnical Commission
ISO International Organization Standardization
ISP Internet Service Provider
IT Information Technology
ITIL Information Technology Implementation Library
KMBD Knowledge Management Database
KPI Key-Perfomance Indicator
MSP Managed Service Providers
MTBF Mean Time between Failure
MTBI Mean Time between Incidents
MTTR Mean Time to Repair
OLA Operational-Level-Agreement
REST Representational State Transfer
RCP Remote Call Procedure
SA Service-Agreement
SaaS Software as a Service
SCD Supplier and Contracts Database
SCOR Supply Chain Operations Reference
SIL unified Service Implementation Language
xii
SLA Service-Level-Agreement
SLR Service-Level-Requirements
SOA Service-Oriented-Architecture
SOAP Simple Object Access Protocol
SOD Service-On-Demand
SOX Sarbanes-Oxley Act
UDDI Universal Description Discovery and Integration
USF Unified Services Framework
uSIL Unified Service Implementation Language
WS Web-Services
WSDL Web-Services Description Language
XML eXtensible Markup Language
xiii
1
1.
Introdução
Motivação e Enquadramento ……………………………………………………………………………… 2
Objectivos …………………………………………………………………………………………………….. 4
Cenário (Requisitos) ………………………………………………………………………………………... 4
Contribuição ……………………………………………………………………………………………….... 6
Estrutura do Documento ……………………...…………………………………………………………… 7
2
“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.
3
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
4
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 inter-
organizacionais 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.
1.3. 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:
5
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), deve-
se à 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.
6
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.
1.4. 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, intra-
organizacional). Quando se pretende alargar essas soluções e tecnologias a paradigmas inter-
organizacionais, 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.
7
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.
8
2. Estado da Arte
Outsourcing Clássico ………………………………………………………………………………………. 9
Gestão e Fornecimento de Serviços ………………………………………………………………......... 16
Conclusões ………………………………………………………………………………………………….. 31
9
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.
2.1. Outsourcing Clássico
2.1.1. 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;
10
“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;
2.1.2. 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.
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.
Nível de Maturidade Alto Nível de Maturidade Baixo
Recessionário
Combinativo
Partilhado
Crescimento
Inicial
11
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.
2.1.3. 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].
12
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.
13
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ós-
venda é 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.
2.1.4. 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.
14
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
15
- SLA com estrutura multi-nível, mais complexa (Figura 4).
Figura 4 - SLA com estrutura multi-nível
2.1.5. 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.
16
2.2. Gestão e Fornecimento de Serviços
2.2.1. 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
e-mail 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.
2.2.2. 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.
2.2.2.1. 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.
17
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]
2.2.2.2. 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 17999. 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 17799 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;
18
• 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;
2.2.2.3. 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.
19
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
2.2.2.4. 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:
20
• 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.
21
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]
2.2.2.5. 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]:
22
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.
23
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.
2.2.2.6. 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.
24
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]
25
2.2.3. 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.
26
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.
27
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.
28
2.2.4. 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 infra-
estruturas, 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;
29
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
email. MSPs usados pela SecureWorks e pela IBM caem nesta categoria, assim como serviços anti-
spam 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
2.2.5. Tecnologias no Fornecimento de Serviços
2.2.5.1. 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.
30
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.
2.2.5.2. 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.
2.2.5.3. 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.
31
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.
2.2.5.4. 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.
32
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.
33
3. Trabalho Relacionado
(unified Service Implementation Languange)
Visão …………………………………………….…………………………………………………….…….… 34
Princípios …………………………………………………………………………………………………..…. 34
Estrutura ………………………………………………………………………………………………….…... 36
Unified Services Framework ………………………………………………………………………….….. 37
Conclusões ………………………………………………………………………………………………….. 38
34
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].
3.2. 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;
35
• 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);
36
• 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).
3.3. 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]
37
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.
Modelo da Solução;
Design 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;
Testes (pré-produção ou de produção parcial).
Instalação Incorporação do serviço no sistema (colocação em produção);
Gestão da configuração dos serviços e componentes.
Operação 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;
Detecção de Eventos.
Avaliação 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.
38
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.
3.5. 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 in-
house, de forma complementar com a estrutura do modelo e framework, suportando assim práticas
de Outsourcing genuinamente dinâmicas e distribuídas.
39
Metodologia
Introdução ……………………………………………….…………………………...………………………. 40
Fase de Concepção de Serviços ………………………….………………………….………………...... 43
Fase de Implementação de Serviços ………………………….……………………………………...…. 61
Fase de Operação de Serviços …………………………………….………………………………...…… 69
Conclusões …………………………………………………………………..………………………………. 74
40
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.
41
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
42
• 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.
43
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.
4.2.1. 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.
44
4.2.1.1. 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.
45
Factor Descrição
Forças e Fraquezas
Os atributos da organização. (Recursos e capacidades, Qualidade de
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
garantir sucesso
Conceber e decidir informação relevante para responder a “Como irá o
fornecedor de serviço saber quando atinge o sucesso? Quando
deverão atingir esses factores?”
Ameaças e Oportunidades
Incluir a mentalidade competitiva. Por exemplo, averiguar se existem
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
4.2.1.2. 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
46
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.
4.2.1.3. 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
47
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.
4.2.1.4. 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.
48
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.
Figura 18 - Cenário 1 do Estágio de Estratégia
Cenário 2
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.
49
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).
50
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).
4.2.2. 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.
51
4.2.2.1. 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 300.000 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.
52
4.2.2.2. 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.
53
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
54
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.
4.2.2.3. 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;
55
• 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
56
4.2.2.4. 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 inter-
organizacional;
• 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.
4.2.2.5. 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).
57
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%.
58
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)
59
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)
60
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).
61
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).
4.3. 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).
62
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.
4.3.1. 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.
4.3.1.1. 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, meta-
serviç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.
63
4.3.1.2. 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:
64
• Alteração Standard (pré-autorizada). Uma Alteração Standard é uma mudança para um
serviço ou infra-estrutura para a qual a abordagem é pré-autorizada pela Gestão de
Alterações que tem uma aceitação e procedimento estabelecido para fornecer uma alteração
específica exigida. Os elementos fundamentais de uma Alteração Standard são:
o Existe definido um trigger para iniciar um Request for Change (RFC);
o As funções são bem conhecidas, documentadas e comprovadas;
o A autoridade é concedida previamente;
o O Risco é geralmente baixo e bem compreendido.
• Alterações de Emergência. As Alterações de Emergência são por vezes necessárias e
devem ser testadas antes da utilização final ou o impacto da Alteração de emergência pode
ser maior do que o incidente original. Todas as alterações que possam ser necessárias
deverão ser planeadas, tendo em conta a disponibilidade de recursos para testar as
alterações existentes nos vários fornecedores contratados e activos. A Alteração de
Emergência é reservada para as alterações destinadas a reparar um erro num Serviço que
está a afectar de forma negativa o negócio com elevado grau de impacto.
• Alteração Estratégica. Não existem planos estratégicos ou iniciativas que sejam livres de
custos e isentos de riscos. Existem sempre riscos e custos associados com decisões como a
introdução de novos serviços ou entrar em novos Espaços de Mercados. Assim sendo, é
necessário também incluir no módulo de Gestão de Alterações, mudanças estratégicas como
por exemplo:
o De origem Legal (Alteração regulamentar);
o Mudança organizacional;
o Tecnologia de inovação;
4.3.1.3. Gestão de Riscos
Nesta fase de Implementação do ciclo de vida dos serviços, a área de risco associado foca-se no
módulo de Gestão de Alterações e à informação existente na KMDB.
Segundo Willcocks[17], “Nenhuma alteração é, sem risco”. Alterações simples podem parecer
inofensivas, mas podem causar danos inversamente proporcionais à sua complexidade. Esta sinergia
entre a Gestão de Risco com a Gestão de Alterações, pretende de forma unificada utilizar uma base
de avaliação do risco durante a avaliação do impacto dum conjunto de alterações em serviços.
Na Tabela 5, demonstra-se a matriz que poderá ser utilizada para categorizar os risco e a partir
desta categorização, avaliar o nível de impacto associado.
65
Tabela 5 - Categorização dos Riscos
Atribuição de prioridades. A prioridade é utilizada para estabelecer a ordem em que as
Alterações apresentadas deverão ser consideradas. A prioridade de uma alteração é derivada do seu
impacto e urgência. O impacto é baseado na dualidade entre uma alteração benéfica em que irá
decorrer de uma alteração, com uma alteração que será prejudicial e os níveis dos danos e custos
para o negócio. O impacto não pode ser expresso em termos absolutos, mas pode depender da
probabilidade de um evento ou de uma circunstância.
Relativamente ao módulo de Gestão de Conhecimento e à KMDB, são considerados os seguintes
riscos:
• Alienação de algumas chaves de suporte às operações;
• Custos adicionais para os serviços em transição não planeados;
• Resistência à mudança e ao levantamento de questões burocráticas;
• A falta de maturidade e integração de módulos unificados, resultando na atribuição das culpas
à tecnologia para outras deficiências;
• Perda de horas produtivas, custos mais elevados, perda de receita, ou talvez mesmo falência
das empresas, como resultado do mau envolvimento da fase de Implementação dos
Serviços.
4.3.1.4. 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.
Cenário 1
A Gestão de Conhecimento é especialmente significativa uma vez que um dos principais
elementos do serviço a ser transferido é o conhecimento. Exemplos em que uma transição bem
sucedida assenta numa Gestão do Conhecimento adequada incluem:
66
• Uma compreensão por parte dos vários fornecedores quando surge uma alteração ou
correcção num serviço, incluindo o conhecimento dos erros avaliados antes da sua
implementação, para facilitar as diversas actividades a desencadear;
• O conhecimento da utilização de uma nova versão dum serviço, bem como a interrupção da
sua versão anterior;
• A partilha do conceito de propriedade intelectual e durante os estágios do ciclo de vida dos
Serviços;
• A transferência de conhecimento a actuar como um factor crucial para facilitar uma transição
e implementação dos novos serviços de forma eficiente;
• O registo de erros, soluções e defeitos detectados e documentados durante o estágio de pré-
produção numa Knowlegde Management Database (KMDB);
• Um auxilio em decisões sobre a aprovação de certos itens e serviços, fornecendo todas as
informações relevantes disponíveis (omitindo informação desnecessária e confusa);
• Designar automaticamente quais as variáveis adequadas consoante o pedido que está a ser
executado ou em função do módulo que está a ser desencadeado;
• Conformidade com requisitos legais e outros (por exemplo, política da empresa,
códigos de conduta profissional);
Para cumprir todos estes requisitos, considera-se que a KMBD não deverá ser considerada como
uma simples base de dados com todas em informações concentradas, mas um conjunto de base de
dados referidas ao longo deste modelo com a adição de campos numa biblioteca que seria
considerada tendo em conta a natureza e especialização do produto que essa organização produz.
Segundo a Figura 29, demonstra-se o modo como a KMDB e a Gestão de Conhecimentos deverá ser
estruturada.
Figura 29 – Cenário 1 do Estágio de Implementação (Knowledge Management Database)
67
Cenário 2
Variáveis Consideradas no módulo de Gestão de Alterações:
• RFC(detalhes);
• Proposta de Alteração;
• Planos de Capacidade;
• Listagem dos vários Fornecedores existentes e inactivos;
• Calendarização da Alteração;
• Categorização do Impacto da Alteração;
• RFC’s Rejeitados ou RFC’s Aprovados;
• Relatório da Gestão de Alterações para a KMDB;
Inicialmente simula-se a mesma situação que o cenário da actividade reactiva da Gestão de
Capacidade. Como ilustra a figura 30, é 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 A notifica o outsourcer com a informação que é necessário efectuar uma alteração.
Figura 30 - Cenário 2 do Estágio de Implementação (Fase Inicial)
Como mostra a Figura 31, é nesta situação que a Gestão de Alterações intervém. Com a
avaliação dos Riscos, dos Fornecedores Inactivos disponíveis e do Plano de Capacidade das várias
entidades, será classificado o tipo de Alteração a efectuar. Como existe uma situação de
indisponibilidade dos recursos e capacidade sem aviso prévio, esta situação categoriza-se como uma
Alteração de Emergência.
68
Figura 31 - Cenário 2 do Estágio de Implementação (Final)
Esta situação é tratada com um RFC para o outsourcer proveniente do Fornecedor A, e
posteriormente com a informação reunida e a análise dos riscos realizada, é executado um novo RFC
originário do outsourcer para o Fornecedor B. Nesta situação supõe-se que a Categorização dos
Riscos fosse de Categoria 2 (Impacto Alto, Probabilidade de Risco Baixa), o Fornecedor B aprova
também esse RFC procedendo ao fornecimento da capacidade necessária do serviço ao outsourcer.
69
4.4. Fase de Produção
Nesta fase de Produção do ciclo de vida dos serviços, é focado em maior atenção o estágio de
Produção, uma vez que é a neste que se permite equilibrar certos factores que podem trazer alguma
volatilidade durante a prática de outsourcing. Estes factores são:
• Visão Interna Vs. Visão Externa do Negócio
Figura 32 - Visão Interna Vs. Visão Externa do Negócio
Uma entidade organizacional (quer seja um outsourcer ou um fornecedor), não deverá apenas
focar-se numa visão interna. Uma visão unicamente interna pode levar ao foco em fluxos e módulos
que não são os mais importantes para o negócio. Por outro lado, preocupar-se apenas o fluxo com as
outras entidades poderá levar a estabelecerem-se contratos e compromissos que não são
alcançáveis. Os requisitos de negócio dependem da Capacidade que as infra-estruturas
organizacionais suportam no presente e não da Capacidade numa hipótese futura, sendo necessário
o equilíbrio deste factor;
• Estabilidade Vs. Tempo de Resposta
Figura 33 - Estabilidade Vs. Tempo de Resposta
Os requisitos de negócio mudam constantemente ao longo do tempo. Isto exige Alterações nos
serviços e/ou nas entidades. Se uma entidade organizacional apenas pensar na estabilidade, esta
torna-se rígida e lenta para adaptar-se às necessidades de negócio. Se apenas uma organização se
focar na sua agilidade, poderá perder qualidade no planeamento das Alterações e por consequência,
perder estabilidade;
• Qualidade de Serviço Vs. Custo de Serviço
Figura 34 - Qualidade de Serviço Vs. Custo de Serviço
70
Apesar de existir uma constante pressão para que a qualidade dos Serviços aumentem, não se
consegue garantir sempre uma elevada qualidade por um baixo custo. É nesta perspectiva que o
outsourcer e os seus Fornecedores terão de estabelecer uma usabilidade dos Recursos de forma
optimizada;
• Actividades Reactivas Vs. Actividade Pró-activas,
Figura 35 - Actividades Reactivas Vs. Actividade Pró-activas
Uma entidade reactiva, concebe algo quando é submetida uma pressão externa, Ou seja, só
desenvolve os procedimentos para a produção de um novo serviço, quando a envolvente de negócio
dispara na procura desse serviço.
Uma entidade organizacional pró-activa deverá ter possibilidade e mecanismos que a permitem
integrar novas oportunidades ou uma melhoria contínua nos seus serviços. Contudo, se apenas se
focar na pró-actividade, poderá gerar demasiados custos que não são recuperáveis para o outsourcer
e suas respectivas entidades Fornecedoras.
Como se pode ver pelas Figuras [33 a 36], para cada um desses factores, deverá ser mantido um
equilíbrio no intuito de cumprir os seguintes objectivos:
• Gerir os módulos, tecnologias e infra-estruturas que suportam a entrega dos serviços;
• Suportar a optimização de custos e qualidade;
4.4.1. Estágio de Operação
Como principal distinção desta Fase para as restantes referidas (Concepção e Implementação), os
módulos abordados no estágio de Operação deverão apenas intervir de forma vigilante, sendo o seu
método de actuação expresso através de Alertas, Eventos, Incidentes e Problemas nas Interfaces da
entidade organizacional em causa. Contudo, é necessário possuir uma clara definição das métricas
que realçam a importância da utilização destes módulos na Gestão de Serviços Unificados, bem
como uma noção dos seus Riscos inerentes.
Os principais módulos propostos e desenvolvidos em maior detalhe são:
(1) Gestão de Eventos;
(2) Gestão de Incidentes;
(3) Gestão de Problemas;
(4) Gestão de Riscos.
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.
71
4.4.1.1. Gestão de Eventos
Um evento deverá indicar uma actividade normal que necessita de uma intervenção de rotina. A
Gestão de Eventos depende de monitorização, mas não só. Depende também da detecção de
notificações (Alertas), enquanto monitoriza e verifica o estado dos Fornecedores mesmo quando não
há ocorrências de eventos nestas entidades. Após ter sido detectado um caso, este ser classificado e
conduzido como um Incidente, Problema ou Alteração.
4.4.1.2. Gestão de Incidentes
Um incidente é uma interrupção não planeada de um Serviço ou a redução da qualidade deste.
Falha na configuração de um item que ainda não teve impacto no Serviço também é considerado um
incidente. Assim sendo, o principal objectivo da Gestão de Incidentes consiste em restaurar um
serviço ao seu ponto de funcionamento normal o mais rapidamente possível, minimizando o impacto
negativo sobre o negócio.
Os incidentes são frequentemente detectados pela Gestão de Incidentes, ou em endpoints de
contacto com o Cliente-Final. Como as origens e as causas dos incidentes podem abranger uma
panóplia de hipóteses, é necessário que estes possuam Níveis de Impacto e Urgência, como é
demonstrado na Tabela 6 e 7.
Impacto
Baixo Médio Alto
Funcionalidade afectada
mas sem impacto no
Serviço-Final.
Funcionalidade do Serviço
afectada parcialmente, mas
com alternativa existente
Serviço-Final indisponível
Perda de funcionalidade que
afecta directamente o negócio
Tabela 6 - Tabela de Classificação do Impacto
Urgência
Alta Deverá ser resolvido Imediatamente
Média Programar Resolução dentro do definido nos SA’s
Baixa Planear Resolução
Tabela 7 - Tabela de Classificação da Urgência
Com a inclusão desta categorização dos incidentes nesta metodologia, pretende-se trazer maior
robustez ao modelo de serviços unificados. Esta robustez traduz-se numa redução geral no tempo
entre incidentes, como é demonstrado na Figura 36.
72
Figura 36 - Medidas de Disponibilidade
A possibilidade de redução do Tempo de Detecção e do Tempo de Resposta em Incidentes é
verificada nesta metodologia através do acompanhamento de mecanismos pró-activos (Gestão de
Eventos, Gestão de Capacidade, Gestão de Procura) e com Bases de Dados e Bibliotecas com
informação útil como é o caso da KMDB.
4.4.1.3. Gestão de Problemas
Um Problema é uma causa de um ou mais incidentes. Uma vez a causa não é geralmente
conhecida no momento em que um problema é registado e criado, é a Gestão de Problemas que está
responsável por uma investigação mais aprofundada. Uma Gestão de Problemas eficaz contribui com
o cumprimento dos seguintes objectivos:
• Eliminar incidentes recorrentes;
• Submeter os pedidos de RFC’s para eliminar a causa e resolver o problema;
• Manter a informação sobre problemas e soluções temporárias a disponibilizar à Gestão de
Incidentes;
• Assegurar uma contribuição no aumento da Disponibilidade de serviços para o negócio.
Known Errors Database. As soluções são documentadas numa Base de Dados conhecida por todas
as entidades envolvidas nomeada de Known Errors Database (KEDB), que melhora a eficiência do
módulo de Gestão de Incidentes. A KEDB deverá incluir as seguintes informações:
(1) Diagnóstico e causas dos incidentes,
(2) Registo de Resoluções ou Alterações anteriormente efectuadas com sucesso.
73
4.4.1.4. Gestão de Riscos
Nesta Fase de Operação do ciclo de vida dos serviços, os principais riscos surgem no modo como
os Incidentes e os Problemas são tratados em cada entidade envolvida. A principal dependência da
Gestão de Problemas é o estabelecimento duma ligação eficiente com a Gestão de Incidentes. Isto
permitirá que os Incidentes sejam identificados e que exista uma Classificação dos Incidentes.
Contudo, para garantir este sucesso de dependências, é necessário averiguar os seguintes riscos:
• Falta de progresso na resolução de incidentes devido a ferramentas inadequadas causando
inexistência de alertas e notificações fundamentais para um determinado negócio de serviços;
• Fraca capacidade de relacionar Incidentes com os registos de Problemas na KEDB;
• Falta de informação de suporte adequada, devido a módulos de outras fases inadequados ou
falta de integração entre fornecedores.
4.4.1.5. Aplicação no Modelo de Referência
Para demonstrar a aplicação destas políticas pré-definidas na fase de operação é proposto uma
diferente perspectiva para a observação destas a decorrerem num fluxo inter-organizacional como é o
caso do Modelo de Referência.
Cenário geral
A Figura 37 pretende mostrar o funcionamento de vários cenários anteriormente referidos com a
visualização em maior detalhe do funcionamento dos mecanismos associados à Gestão e Eventos,
Incidentes e Problemas.
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)
74
Para a simulação de Eventos, repete-se o cenário 1 do estágio de Design de ÉpocaAlta(). O Timer
que é desencadeado pelo Outsourcer, é um evento comunicado aos Fornecedores. Este evento
deverá indicar:
(1) Os problemas sobre a disponibilidade do Fornecedor A;
(2) Os problemas sobre a dificuldade em manter certos níveis de desempenho no
fornecimento dos serviços.
Nesta situação o outsourcer poderá efectuar uma activação de outros fornecedores sem que o
Cliente-Final seja directamente afectado com esta alteração no fluxo dos serviços.
Para demonstração de Incidentes, refere-se o Cenário 2 do Estágio de Design em que surge uma
Falha na disponibilidade da capacidade que Fornecedor A deveria garantir ao outsourcer (em que
esta desce de 40% para 10%). O Trigger que é desencadeado pelo Fornecedor A, é um incidente
comunicado ao outsourcer. Este incidente deverá:
(1) Conter as informações respectivas do evento associado;
(2) Permitir uma redução de falhas temporárias críticas.
O outsourcer poderá receber também Incidentes pela entidade Cliente-Final. Com informação
recebida pelo Cliente-Final (independentemente do meio de comunicação utilizado). Em ambas as
situações os Incidentes são direccionados para o módulo de Gestão de Problemas.
Continuando neste Cenário é também possível observar como a Gestão de Problemas deverá
intervir. Com a recepção deste Incidente (ou destes Incidentes caso exista uma dependência de
escala), a Gestão de Problemas deverá:
(1) Eliminar Incidentes recorrentes;
(2) Manter a Informação sobre problemas e soluções temporárias a disponibilizar à Gestão
de Incidentes.
Com esta sequência de actividades, poderá ser necessária a consulta de informação relacionada
na KEDB. Após ser analisado o plano de acção e avaliado os riscos inerentes ao negócio e à
dependência de fornecedores, é submetido o RFC para a Gestão de Alterações no sentido de
eliminar a causa e resolver o problema.
4.5. Conclusões
Neste capítulo foi explicado de forma exaustiva como integrar práticas de outsourcing dinâmico e
distribuído na metodologia de serviços unificados uSIL com a adaptação de alguns dos módulos
participantes nos estágios e fases do ciclo de vida dos serviços e a incrementação de políticas pré-
definidas tanto para a concepção e distribuição do serviços como na Gestão de Risco inerente a todo
este processo de fluxo inter-organizacional.
75
5.
Validação do Conceito
(Proof-of-Concept)
Caso de Estudo ………………………………………..…………………………………………………….. 76
Conclusões ……………………………………..……………………………………………………………. 81
76
Neste capítulo, para proceder à avaliação e validação prática desta metodologia é demonstrado a
simulação de um caso de estudo. Para exemplificar a aplicação desta solução, pretende-se
demonstrar o cenário do funcionamento de uma agência de viagens.
5.1. Caso de Estudo
Perante a aquisição de um pacote de viagem por um consumidor, serão analisadas as distintas
envolvências do fornecimento do serviço - Marcação de um Plano de Viagem Turística. O
fornecimento deste serviço Marcação Plano de Viagem Turística, terá como principais entidades
intervenientes, os fornecedores, a própria agência de viagens (que será a entidade Outsourcer), e do
lado do cliente. Note-se que neste cenário, a infra-estrutura IT desta agência está entregue por
outsourcing a um fornecedor de IT - &.
Entidade Cliente
O Cliente efectua uma reserva de um Plano de Viagem Turística para Londres. Durante o período
de intervalo até ao dia em que irá embarcar no avião para Londres, este poderá monitorizar se todos
os serviços estão actualizados, reservados e disponíveis. As comodidades e especificações
inicialmente definidas pelo Cliente, foram as seguintes (Figura 38):
(1) A hora de chegada a Londres;
(2) Uma Suite de Luxo;
(3) Um Automóvel de classe E.
Figura 38 – Visão da Entidade Cliente
77
Entidade Outsourcer
A Agência de Turismo terá de invocar uma série de pedidos por serviços decompostos pelos
fornecedores A, 1, X e &. Através das políticas pré-definidas assentes nos requisitos estabelecidos, o
modelo de serviços deverá ser capaz de efectuar o balanceamento de carga e integração com todos
estes fornecedores. Adicionalmente, em caso de problemas, desastre, ou escassez de recursos, terá
de activar o Plano-B previamente definido para cada um destes contratos de outsourcing.
O outsourcer definiu como agência de aviação a agência A, como alojamento o Hotel 1 e como
serviço de Rent-a-Car o Fornecedor X. O Cliente não necessita de ter a percepção de que os
diversos serviços que está a usufruir são de diferentes entidades, mas sim que possua uma viagem
para Londres num determinado dia, um quarto de hotel reservado e meio de transporte de acordo
com as suas necessidades. Portanto, para o Cliente, é indiferente se este viajou pelo avião da
agência A, B ou C, se esteve no Hotel 1,2 ou 3 e se viajou no meio de transporte fornecido pela
empresa de Rent-a-Car X, Y ou Z, desde que o custo e as especificações por esses serviços sejam
proporcionais ao que foi pré-definido.
Primeiramente, terá de ser estabelecida uma prioridade dos serviços a serem pedidos. Não faria
sentido o serviço de Rent-a-Car ou de alojamento estivesse garantido se não for possível reservar
primeiramente a viagem de avião para Londres, como ilustra a Figura 39.
Figura 39 - Cenário de Activação dos sub-serviços do Marca Plano de Viagem Turística
78
Posteriormente, existindo um problema de desastre natural na infra-estrutura IT disponibilizada
pelo fornecedor &, toda a informação até à data seria continuada e dada como disponível devido a
um fornecimento de IT pelo fornecedor $ (sendo este fornecedor $ o Plano-B que o fornecedor & já
adquiria para este tipo de situações).
Seguidamente, surgiu uma notificação de que o Hotel 1 não apresenta disponibilidade para
reservar uma Suite com os requisitos definidos. O Hotel possui o seu próprio Fornecedor Plano-B e
terá de averiguar e garantir a reserva no Hotel 2 ou 3, de acordo com:
(1) As especificações que foram previamente definidas com o Cliente (Figura 40);
(2) Os termos estabelecidos em relação aos serviços que os Hotéis 2 e 3 disponibilizavam.
Figura 40 - Cenário de Falha do Fornecedor Hotel 1
79
Após a selecção do fornecedor alternativo Hotel 2 dos Fornecedores de Plano-B do Hotel 1, este
comunica a recuperação da possibilidade de fornecer o serviço com os requisitos totalmente
preenchidos à entidade outsourcer.
Entretanto surgiu um desastre no Fornecedor de Rent-a-Car e este perdeu toda a propriedade
automóvel que possuía. Nesta situação, como mostra a Figura 41, é o outsourcer que terá de avaliar
as alternativas que possuí de Fornecedores Secundários para este tipo de serviços de Rent-a-Car.
Figura 41 - Cenário de Falha do Fornecedor Rent-A-Car X
Dados os detalhes do serviço feito ao outsourcer pelo Cliente-Final, a listagem da SCD tinha
recomendado a comunicação com o Fornecedor Plano-B - Rent-a-Car Y. Com a situação de sucesso
nesta recuperação da qualidade de serviço estabelecida inicialmente, é prosseguido a
disponibilização do Serviço-Final sem necessidade de alarmar o Cliente.
80
Entidade Fornecedor
Para manter este tipo de dinamismo e flexibilidade ao nível global da prestação de um serviço, é
imperativo que o fornecedor seja não só capaz de gerir toda a carga e demand submetida pelo
outsourcer, como também suportar a integração dos dados entre esta entidade e outros
fornecedores. Este Fornecedor poderá ter um Plano de disaster-recovery interno como era no caso
dos Hoteis 2 e 3 e/ou definir com a entidade outsourcer possíveis fornecedores secundários como era
o caso do Plano-B do Rent-a-Car Y.
Ainda nesta situação tida como exemplo, deverá ser incluído no Fornecedor que possui o seu
Plano-B, uma lista de fornecedores que provisionem serviços alternativos caso o seu Plano-B
também falhe ou não possua a capacidade para o fornecer. Existindo políticas pré-definidas que
governem este tipo de situações, o Fornecedor Plano-B passar a ser um outro Fornecedor que o
outsourcer possuísse como fornecedor secundário de outros tipos de serviço, mas que fosse capaz
de fornecer esse serviço adicionalmente. Demonstra-se esta situação na Figura 42.
Figura 42 - Cenário de Falha do Fornecedor Agência Excursões @
81
Tal poderia ser aplicado caso o Cliente tivesse também reservado uma excursão rodoviária
para Manchester. Antes do início dessa tour, o Cliente verificou que um dos pontos de interesse seria
a Rua Oxford, onde se localizava a Universidade Metropolitana de Manchester e o Colégio Real de
Música do Norte, que desejava visitar. Apesar de o cliente também possuir o serviço de Rent-a-Car e
possuir um veículo, este não se sentia seguro para fazer uma viagem tão longa a conduzir e por
conseguinte, procede à adição deste pacote de serviço ao serviço global de Marcar Plano de Viagem
Turística. Nos dias antes da excursão, a entidade Fornecedora RoteirosExcurções @ sofre uma
greve geral dos condutores dos veículos de excursão e é prevista uma greve com duração superior à
estadia do Cliente em Londres. Como esta greve afectava todo este sector, os Fornecedores
Secundários do outsourcer ou até do próprio Fornecedor @ não poderiam intervir de forma efectiva
para solucionar este problema. O outsourcer, nestas situações deverá avaliar quais os Fornecedores
de outras áreas de negócio diferentes mas que possam solucionar esta situação. Neste caso o
outsourcer consegue resolver a situação com a activação de um Fornecedor Frota de Taxis Privados
Ω, e reservando um táxi para transportar o Cliente até à Rua Oxford, em Manchester. Desta forma,
seria garantido o preenchimento total dos requisitos do Cliente.
5.2. Conclusões
Com este caso de estudo hipotético é possível concluir que esta metodologia permite aumentar a
taxa de sucesso no fornecimento de um serviço por prática de outsourcing dinâmico e distribuído e
consequentemente, aumentar a satisfação do Cliente-Final. Foram demonstradas situações de
problemas e desastres e o modo como esta metodologia permite em todos os casos encontrar uma
solução para manter a sobrevivência desses serviços. Estas soluções surgem com a existência de
Fornecedores Secundários, tanto contratados pela entidade outsourcer como pela entidade
Fornecedor Principal, demonstrando assim o valor acrescentado de um sistema heterogéneo,
unificado e de fácil integração inter-organizacional.
82
6.
Conclusões e
Trabalho Futuro
Conclusões …………………………………………………………………………………………………… 83
Trabalho Futuro ………………………………………………………………………………………….….. 84
83
6.1. Conclusões
Este documento, através do trabalho apresentado, vem dar resposta a uma necessidade
emergente na gestão e fornecimento de serviços, perante os sinais já oferecidos pelas organizações
que procuram complementar as frameworks utilizadas. É de destacar o enorme esforço que
actualmente é feito em torno da questão sobre o peso dos benefícios e riscos que estão subjacentes
nos contratos por outsourcing nos dias de hoje, o que gerou um enorme leque de literaturas bastante
inovadoras nas abordagens feitas nesta área.
Tal como descrito nos capítulos relacionados com o Estado da Arte, são muitas as frameworks de
gestão em IT que, apesar de direccionarem-se em objectivos diferentes, na sua essência, todos
partilham o mesmo – a Gestão e Fornecimento de Serviços. Algumas das frameworks tratadas
durante este trabalho têm sofrido várias modificações, traduzidas em novas versões, que no futuro
vêm aprofundar ainda mais a gestão nos seus temas. O outsourcing é sem dúvida um conceito
que futuramente deixará de existir devido a integração automática e simplista entre
organizações e a transacção de recursos entre estas.
É notória a diversidade de sistemas aplicacionais que surgem no intuito de facilitar as relações de
outsourcing, todavia, estas só poderão realmente demonstrar valor acrescentado com um
acompanhamento constante nas diferentes fases de um contrato de outsourcing, desde a análise de
fornecedores e a sua definição contratual, até o serviço final chegar ao consumidor.
A metodologia proposta, explora a natureza da arquitectura genuinamente orientada para os
serviços, cujo domínio de aplicabilidade se situa no domínio da Engenharia dos Serviços e numa
visão de Serviços Unificados. Esta visão de Serviços Unificados deverá ser crucialmente suportada
pelo uSIL, como meio para trazer heterogeneidade e simplicidade ao tratamento da informação entre
diversos sistemas. Desta forma, conclui-se que esta metodologia de outsourcing dinâmico e
distribuído defende a perspectiva que as organizações devem modelar a informação e não
modelar dados.
Em Suma, esta solução pretende contribuir para o enriquecimento dessa busca pelo meio de
incentivar a descentralização das organizações que produzem uma vasta panóplia de serviços e
assim obter uma melhor especialização sobre um determinado serviço que realmente possa trazer
diferenciação e vanguarda no mercado.
84
6.2. Trabalho Futuro
Apesar da Framework unificada já incluir um conjunto considerável de aspectos a ter em conta na
gestão de qualquer serviço, perante o elevado e diversificado número de serviços que se podem
encontrar no dia-a-dia, áreas como Saúde, Banca, Seguros, Educação, entre muitas outras,
certamente têm associado a um conjunto de procedimentos e standards que, se analisados, podem
contribuir de forma positiva para aprofundar e completar esta metodologia dos serviços
unificados[3],[4].
Para complementar, esta visão de Modelo de Serviços Unificados apresenta-se ainda em
investigação, sendo acompanhado pelo Professor Doutor José Delgado[1] e desenvolvido pelos
alunos do Instituto Superior Técnico [2],[3],[4]. Para finalizar a tese, são apresentados neste
subcapítulo as directivas para futuras investigações, no que toca ao fornecimento de serviços por via
de outsourcing dinâmico e distribuído:
• Averiguar Modulo para Gestão Financeira e Jurídica;
• Especificar como aperfeiçoar Funções como Service Desk, Operations Management e
Facilities Management para o tratamento dos serviços durante a sua fase operacional;
• Concretização de ambientes de testes práticos em organizações com este modelo.
• Incluir a gestão de serviços de outsourcing numa estrutura de melhoria contínua dos serviços
unificados (no Plano de Maturidade – Eixo de Versões);
• A definição de templates específicos para a gestão de SA’s, validação e renovação de
Fornecedores juntamente com os templates definidos para cada domínio organizacional a
aplicar;
85
7.
Referências
86
7.1. Referências Bibliográficas
[1] Delgado, Professor Doutor José, "Unified Services Implementation Language (SIL)". Lisboa:
Instituto Superior Técnico, (Outubro 2008).
[2] Levezinho, Rafael Pinheiro da Silva, “Metodologia de Implementação de Serviços”,
Dissertação Instituto Superior Técnico, (Setembro 2008).
[3] Almeida, Miguel, "ITSM Foundation service library". Dissertação Instituto Superior Técnico -
TagusPark, (2009).
[4] Freire, José, "Automatização da gestão de serviços". Dissertação Instituto Superior Técnico -
TagusPark, (2009).
[5] McCray, Shawn, “Guidelines for Sizing Outsourcing Governance Investments”,
Computerworld & TPI’s Sourcing Management Department, (2005).
[6] Cheon, Jung "Theoretical Perspectives on the Outsourcing of Information Systems". Journal
of Information Technology, (1995).
[7] Hyder, Elaine, "The eSourcing Capability Model of Service Providers and Clients". Pittsburg:
Carnegie Mellon University - IT Governance Institute, (2006).
[8] Evans, Nick, "Business Innovation and Disruptive Technology: Harnessing the Power of
Breakthrough Technology for Competitive Advantage". New York: Prentice-Hall, (Agosto
2002).
[9] Fairchild, Andrew., "Information Technology Outsourcing (ITO) Governance: An Examination
of the Outsourcing Management Maturity Model". Proceedings of the 37th Hawaii International
Conference on System Sciences, (2004).
[10] Meng, Fan, "A Unified Framework for Outsourcing Governance", Beijing: Peking University -
IBM China Research Laboratory, (2007).
[11] Fitzgerald, Lewis, "Contracts and Partnerships in the Outsourcing of IT". Proceedings of the
15th International Conference on Information Systems, Vancouver, (1994).
[12] Goo, Jahyun, "Contract as a Source of Trust - Commitment in Successful IT Outsourcing
Relationship: An Empirical Study". Proceedings of the 40th Hawaii International Conference on
System Sciences, Hawaii: Florida Atlantic University, (2007).
[13] Jobber, David, "Principles and Practice of Marketing". New York: McGraw-Hill, (1998).
[14] Kern, Ted, "The Gestalt of an Information Technology Outsourcing Relationship: an
Exploratory Analysis". Proceedings of the 18th International Conference on Information Systems.
Atlanta, (1997).
[15] Klotz, Siagn, "The Present Situation and The Forecast of China's Outsourcing Industry".
Sweden: Göteborg University. School of Business, Economics and Law, (Fevereiro 2008).
87
[16] Loh, Nick, "Determinants of Information Technology Outsourcing: A Cross Sectional
Analysis". Journal of Management Information Systems, (1992).
[17] Willcocks, David., "IT Outsourcing as Strategic Partnering: The Case of the UK Inland
Revenue,". European Journal of Information Systems , (1998).
[18] Lacity, Lois, "Global Information Technology Outsourcing: In Search of Business
Advantage". Chichester: Wiley, (2001).
[19] Gallivan, Michael, "Analyzing IT Outsourcing Relationships as Alliances among Multiple
Clients and Vendors". Proceedings of the 32nd Hawaii International Conference on System
Sciences , Hawaii: Stern School, New York University, (1999).
[20] Muehlena, Michael, "Developing web services choreography standards - the case of REST
vs. SOAP", Science Direct - New Jersey: School of Technology Management, Stevens Institute of
Technology, (2005).
[21] Grefen, Paul, "An analysis of Web-Services Support for Dynamic Business Process
Outsourcing". Eindhoven University of Technology, Technology Management Department, (Março
2006).
[22] Hu, Quyagi "Research Report: Diffusion of Information Systems Outsourcing: A
Reevaluation of Influence Sources". Information Systems Research, (1997).
[23] Shahzada, Jiraya. "Aligning Technology with Business: An Analysis of the Impact of SOA
on Outsourcing". University of Antwerp, (2005).
[24] Syaripah Aris, "Risk Management Practices in IT Outsourcing Projects". Universiti Teknologi
Mara Selangor - Faculty of Information, (2007).
[25] Kern, Ted, "Application Service Provision". Englewood Cliffs: Prentice Hall, (2001).
[26] Thoms, Bernard. "Outsourcing: Inside Out and Outside In". New Jersey: Stevens Institute of
Technology, (2007).
[27] Vail, Erik. "Causal Architecture: Bringing the Zachman Framework to Life". Information
Systems Management Week, (2006).
[28] Willcocks, David. "Strategic Sourcing of Information Systems: Perspectives and Pratices".
Chichester: John Wiley & Sons, (1998).
[29] Da Kai, Zhang. "Study on the Decision Factors of Non-core Business Outsourcing: The
Introduction of the Mature Degree in Outsourcing Market". Shanghai Management Science,
(2006).
[30] Bittinger, Steve, “ITIL Implementation Best Practice in Service Management”, Gartner Audio
Teleconference, (Julho 2004).
[31] Marujo, Liliana, "Advanced Hot Topic - Business Process Management". Computer World ,
Vol. 34, (2007).
88
[32] DiRomualdo, Anthony, "Strategic Intent for IT Outsourcing". Information Week , (Novembro
2006).
[33] Pichot, Antoine, "Dynamic SLA-negotiation based on WS-Agreement". coreGRID, (Junho
2007).
[34] Chaudhury, Jean. "Management of Information Systems Outsourcing: A Bidding
Perspective". Journal of Management Information Systems, (1995).
[35] Overby, Stephanie. “The Hidden Cost of Offshore Outsourcing”, CIO Magazine – Special
Report, (Setembro 2003).
[36] Ikeda, Karen, “Ensuring Information Security when Outsourcing”, FAD Today, (2005).
[37] Overby, Stephanie, “The Factors Influencing Information Systems Outsourcing Partnership”,
35th Hawaii International Conference on System Sciences, (2002).
[38] McGovern, James. “Enterprise Service Oriented Architectures Concepts, Challenges,
Recommendations”, Springer (2006).
[39] Josuttis, Nicolai. “SOA in Pratice”, (Agosto 2007).
[40] Erl, Thomas. “SOA: Principles of Service Design”, (2007).
[41] Peltz, Charles. “Web Services Orchestration and Choreography”, HP Company, (2003).
[42] Tilkov, Stefan. “A Brief Introduction to REST”, (Julho 2008).
[43] Richardson, Leonard, “RESTfull Web Services“, OReilly (2007).
[44] Alves, Tiago, “Cloud Computing”, Revista Tecnológica IST (Novembro2008).
[45] Sterritt, Bustard, “Towards an Autonomic Computing Environment”, IEEE, (2003).
[46] Workshop Compuware, “Six Sigma e a Melhoria da Qualidade do Serviço”, (Maio 2007).
[47] Zúquete, André.,”Segurança em Redes Informáticas”, FCA, (2006).
[48] “ISO/IEC 17799:2005 – “Information techniques - Security techniques - Code of practice for
information security management”, ISO, (2005).
[49] Barthélemy, Jérôme, “The Seven Deadly Sins of Outsourcing”, Academy of Management
Executive Vol 17 No2, (2009).
[50] Bon, Jan Van, “Foundations of IT Service Management Based on ITIL V3”, (Novembro 2007).
[51] Borges, Bruno Rafael Saraiva Lopes, “Automação da Gestão de Infra-estruturas
Tecnológicas”, Dissertação Instituto Superior Técnico, (Setembro 2008).
[52] Alves, Tiago, “Cloud Computing”, Revista Tecnológica IST (Novembro2008).
[53] Geetanjali, Arora “XML Web Services Professional Projects”, (2002).
[54] Thomas, Roy, “Architectural Styles and the Design of Network-based Software
Architectures”¸ Dissertação de Doutoramento, University of California, Irvine (2000).
89
A.
Anexo A
Metodologia de Outsourcing Dinâmico e
Distribuído ao longo do ciclos de vida
do Modelo de Serviços Unificados
90
Anexo A - Metodologia de Outsourcing Dinâmico e Distribuído ao longo do ciclos de vida do Modelo de Serviços Unificados
91
B.
Anexo B
Diagrama de Fluxo no estágio de
Estratégia dos Serviços
92
ANEXO B - Diagrama de Fluxo no estágio de Estratégia dos Serviços
93
C. Anexo C
Diagrama de Fluxo no estágio de
Design dos Serviços
94
ANEXO C - Diagrama de Fluxo no estágio de Design dos Serviços
95
D. Anexo D
Mapa Conceptual para a Gestão de
Risco
96
Anexo D – Mapa Conceptual da Gestão de Risco em todo o Ciclo de Vida dos Serviços
97
E.
Anexo E
Frameworks de Gestão e
Fornecimento de Serviços
98
Anexo E.1 - ISO 20000
O ISSO 2000 está definido em cinco grupos de processos: Service Delivery, Relationship,
Resolution, Control e Release.
Service Delivery Process
O Service Level Management é responsável por definir, acordar, gravar e gerir os serviços.
O Service Reporting inclui a produção de relatórios acordados, fidedignos, atempados e precisos
para permitir à organização tomar decisões informadas e garantir uma comunicação efectiva.
O Capacity Management assegura que o prestador do serviço tem, em qualquer altura,
capacidade suficiente para conhecer as exigências actuais e futuras em conformidades com as
necessidades do negócio do cliente.
O Service Continuity & Availability Management assegura que a continuidade do serviço acordado
e a disponibilidade de entrega do mesmo ao cliente são conhecidas em qualquer circunstância.
O Information Security Management é responsável pela gestão eficiente da segurança da
informação entre todas as actividades do serviço
Relationship Process
O Business Relationship Management é responsável por estabelecer e manter uma boa relação
entre prestador dos serviços e o cliente, baseada em compreender o cliente e os seus business
drivers.
O Supplier Management é responsável pela gestão de fornecedores subcontratados para
assegura a cláusula de ligação e a qualidade dos serviços
Resolution Process
O Incidente Management centra-se no restauro do serviço acordado ao negócio tão cedo quanto
possível ou responder a pedidos do serviço.
Com o Problem Management pretende-se minimizar o efeito no negócio através de identificação e
análise proactiva dos incidentes e através de uma gestão de problemas próxima.
Control Process
O Configuration Management define e controla os componentes do serviço e da infra-estrutura, e
mantém actualizada a informação de configuração.
O Change Management assegura que todas as mudanças são taxadas, aprovadas,
implementadas e revistas de uma forma controlada
Release Process
O Release Management é responsável por entregar, distribuir e explorar uma ou mais alterações
numa versão do ambiente real.
99
Anexo E.2 - CobIT
O CobIT é dividido em quatro principais fases: Plan and Organize; Acquire and Implement; Deliver
and Support; Manage and Evaluate
Plan and Organize
Uso de informação e tecnologia e como isso pode ser usado para que a empresa atinja os seus
objectivos. Salienta que a forma organizacional e infra-estrutura de IT devem ser consideradas para
que se atinja resultados óptimos e para que se gere benefício do seu uso.
O processo Define a Strategic IT Plan and Direction trata a ligação ente os objectivos de negócio e
os objectivos de IT. Nele inclui-se a identificação das dependências críticas e o desempenho
corrente, a construção de um plano de estratégia de IT, a construção de planos tácticos de IT, a
análise de programas de portfólio e a gestão de projecto e portfolios de serviços
O processo Define the Information Architecture inclui a criação e manutenção do modelo de
informação empresarial, a criação e manutenção de dicionários de dados corporativos, o
estabelecimento e manutenção de um programa de classificação de dados, o fornecimento dos
próprios dados com procedimentos e ferramentas para classificação de sistemas de informação, e a
utilização do modelo de informação, dicionário de dados e programa de classificação para planear
sistemas de negócio optimizados.
O processo Determine Technological Direction centra-se na criação e manutenção de um plano de
infra-estrutura tecnológica, criação e manutenção de standards tecnológicos, publicação de standards
tecnológicos, monitorização da evolução tecnológica, e definição do uso estratégico futuro de novas
tecnologias
O processo Define the IT Processes, Organization and Relationships estabelece a estrutura
organizacional de IT, incluindo committees e ligações com os stakeholders e vendedores. Inclui o
desenho de uma frameworks de processos IT, a identificação dos próprios sistemas, a identificação
dos próprios dados, e o estabelecimento e implementação de regras e responsabilidade de IT,
incluindo a supervisão e segregação de deveres.
O processo Manage the IT Investment preocupa-se com a manutenção do portfólio de programa,
manutenção do portfólio de projecto, manutenção do portfólio de serviço, estabelecimento e
manutenção dos processos de orçamentação de IT, e ainda com a identificação, comunicação e
monitorização de investimentos em IT, custos e valor para o negócio.
O processo Communicate Management Aims and Direction trata do estabelecimento e
manutenção de um ambiente e Framework de controlo IT, do desenvolvimento e manutenção de
políticas de IT, e da comunicação da Framework de controlo IT, dos objectivos e da direcção do IT.
O processo Manage IT Humans Resources inclui nas suas actividades a identificação das
capacidades, descrições de posição, escalas e comparação de desempenho pessoal em IT, bem
como a execução de políticas e procedimentos de recursos humanos relevantes para o IT.
100
O processo Manage Quality define um sistema de gestão de qualidade. Inclui o estabelecimento,
manutenção, construção e comunicação dos standards de qualidade ao longo da organização,
construção e comunicação do plano de qualidade para melhoramento contínuo, medição,
monitorização e revisão da conformidade com os objectivos de qualidade.
O processo Assess and Manage IT Risks centra-se na determinação do alinhamento da gestão de
risco, compreensão dos objectivos estratégicos do negócio relevantes, compreensão dos objectivos
de processo de negócio relevantes, identificação dos objectivos internos de IT e estabelecimento do
contexto de risco. Inclui ainda a identificação dos eventos associados com os objectivos, avaliação
dos riscos associados aos eventos, avaliação e selecção das respostas ao risco, prioritização e
planeamento das actividades de controlo. Por fim, aprova e assegura o financiamento para planos de
acção de risco, e trata da manutenção e monitorização de um plano de acção de risco.
Acquire and Implement
O processo Identify Automated Solutions engloba a definição da função de negócio e dos
requisitos técnicos, o estabelecimento de processos para garantir a integridade dos requisitos, a
identificação, avaliação de viabilidade de forma a implementar os requisitos de negócio propostos, a
avaliação dos benefícios operationais de IT das soluções propostas, a avaliação dos benefícios de
negócio das soluções propostas e por fim, o desenvolvimento de um processo de aprovação de
requisitos adicionado à aprovação e comprovação das soluções propostas.
O processo Acquire and Maintain Application Software centra-se na tradução dos requisitos de
negócio para um especificação de desenho de alto nível, na preparação detalhadas dos requisitos
técnicos e de desenho da aplicação de software, e a especificação dos controlos de aplicação no
desenho. Inclui, também, a manutenção e implmentação da funcionalidade automatizada adquirida, o
desenvolvimento formalizado de metodologias e processos para gerir o processo de desenvolvimento
da aplicação, a criação de um plano de avaliação de qualidade do software para o projecto, o
rastreamento e gestão dos requisitos da aplicação e o desenvolvimento de um plano para a
manutenção de aplicações de software.
O processo Enable Operation and Use preocupa-se com o desenvolvimento de uma estratégia
para operacionalizar a solução, com o desenvolvimento de uma metodologia de transferência de
conhecimento, com o desenvolvimento de manuais de procedimentos para o utilizador final, com o
desenvolvimento de documentação de suporte técnicos para as operações e para o staff técnico, com
o desenvolvimento e entrega de treinos, com a avaliação dos resultados destes.
O processo de Procure IT Resources desenvolve políticas de procurement e procedimentos
alinhados com estas no nível corporativo, estabelece e mentém uma lista de fornecedores
acreditados, avalia e seleccciona fornecedores segundo um pedido por processo de proposta,
desenvolve contratos que protegem os interesses da organização e adquire em conformidade com os
procedimentos estipulados.
101
O processo Manage Changes inclui o desenvolvimento e implementação de um processo para
registo, avaliação e prioritização consistente de pedidos de alteração, a avaliação de impacto e
prioritização das alterações beaseadas nas necessidade de negócio, o asseguramento de que
qualquer emergência e alteração crítica seque os processos aprovados, a autorização das alterações,
e a gestão e disseminação da informação relevante respeitante às alterações.
O processo Install and Accredit Solutions and Changes centra-se na construção e revisão dos
planos de implementação, definição e revisão de uma estratégia de teste euma metodologia de
planificação de teste operacional, e construção e manutenção de um repositório de requisitos
técnicos e de negócio e casos de testes para os sistemas acreditados. Inclui ainda a coversão de
sistemas e integração de testes no ambiente de testes, a instalação de um ambiente de teste e
condução de testes finais de aceitação e por fim, a recomendação de promoção para produção
baseada no critério e acreditação acordado.
Deliver and Support
O processo Define and Manage Service Levels preocupa-se com a criação de uma Framework
para definição dos serviços de IT, com a construção de um catálogo de serviços de IT, com a
definição de SLA's para serviços de IT críticos, com a definição de OLA's para conhecer as SLA's,
com a monitorização e reportagem do desempenho do nível de serviço end-to-end, com a revisão das
SLA's e UC's, com a revisão e actualização do catálogo de serviço IT e com a criação do plano de
melhoramento de serviço.
O processo Manage Third-party Services identifica e categoriza as relações terceiras de serviço,
define e documenta os processos de gestão de fornecedor, e estabelece a evolução do fornecedor e
selecção de políticas e procedimentos. Preocupa-se, também, com a identificação, avaliação e
mitigação dos riscos de fornecedor, com a monitorização da entrega de serviço de fornecedor e com
a avaliação dos objectivos a longo prazo da relação de serviço para todos os stakeholders.
O processo Manage Perfomance and Capacity foca-se no estabelecimento de um processo de
planeamento para a revisão de desempenho e capacidade dos recursos de IT, na revisão do
desempenho e capacidade dos recursos de IT correntes, na condução do desempenho e capacidade
dos recursos de IT previstos, na condução de análises de desvios para identificar enganos nos
recursos de IT, e na monitorização e relatório de contínua de disponibilidade, desempenho e
capacidade dos recursos de IT.
O processo Ensure Continuous Service tem funções no desenvolvimento de uma Framework de
continuidade de IT, na condução de uma análise de impacto no negócio e avaliação de risco, no
desenvolvimento e manutenção de planos de continuidade de IT, na identificação e categorização de
recursos de IT baseados nos objectivos de recuperação. Inclui ainda o planeamento e condução de
treino de continuidade de IT, o planeamento de recuperação e reactivação dos serviços de IT, o
planeamento e implementação de armazenamento de backup e protecção e o estabelecimento de
procedimentos para a condução de revisões pós-reactivação.
102
O processo Ensure Systems Security define e mantém um plano de segurança de IT. Nele inclui-
se a definição, estabelecimento e operação de um processo de gestão de identidade, monitorização
de incidentes de segurança, condução de revisões e validações periódicas dos direitos e privilégios
de acesso do utilizador, estabelecimento e manutenção de procedimentos para manter e
salvaguardas chaves criptográficas. Preocupa-se ainda com a implementação e manutenção de
controlos técnicos e procedimentais para proteger o fluxo de informação ao longo das redes e com a
condução de avaliações às vulnerabilidades regulares.
O processo Identify and Allocate Costs inclui o mapeamento da infra-estrutura de IT para serviços
fornecidos e processos de negócio suportados, a identificação de todos os custos de IT e
mapeamento destes para os serviços de IT nas bases de custo unitárias, o estabelecimento e
manutenção de um orçamento de IT e processo de controlo de custos, e por fim, o estabelecimento e
manutenção de políticas e procedimentos de charging.
O processo Educate and Train Users identifica e caracteriza as necessidades de treino dos
utilizados, construindo um programa de treino, conduzindo actividade de treino, educação e
sensibilização. Inclui também o desempenho de avaliações de treino e a identificação e avaliação dos
melhores métodos e ferramentas de entrega de treino.
O processo Manage Service Desk and Incidents centra-se na criação de procedimentos de
classificação e escalonamento, detecção e registo de pedidos de informação de serviços/incidentes;
classificação, investigação e diagnósticos de queries, resolução, recuperação e fecho de incidentes.
Inclui ainda preocupações com a informação dos utilizadores e produção de reports de gestão.
O processo Manage the Configuration desenvolve procedimentos de planeamento de gestão de
configurarão, recolhe a informação de configuração inicial e estabelece baselines, verifica e audita a
informação de configuração e actualiza o repositório de configuração.
O processo Manage Problems inclui a identificação e classificação de problemas, o desempenho
de análise de causa raiz, a resolução de problemas, a revisão do estado dos problemas, o
questionamento das recomendações para melhoramento, a criação de um RFC relacionado e a
manutenção de registos de problemas.
O processo Manage Data trata da tradução do armazenamento de dados e retenção de requisitos
nos procedimentos, definição e manutenção de procedimentos para gerir a biblioteca de media,
definição, manutenção para a salvaguarda de dados de acordo com a definição dos procedimentos
de restauração de dados.
O processo de Manage the Physical Environment foca a definição do nível requerido de protecção
física, a selecção e comissionar o local, a implementação de medidas de ambiente físico, a gestão de
ambiente físico, a definição e implementação de procedimentos para autorização e manutenção de
acesso físico.
O processo Manage Operations inclui a criação/modificação dos procedimentos operacionais,
programação do fluxo de trabalho e batch jobs, monitorização de infra-estrutura e processamento e a
resolução de problemas e furtos e da programação e desempenho de manutenção preventiva.
103
Monitor and Evaluate
O processo Monitor and Evaluate IT Process estabelece a abordagem de monitorização, identifica
e recolhe os objectivos medíveis que suportam os objectivos de negócio, cria scorecards, avalia o
desempenho e identifica as acções de melhoramento de desempenho.
O processo Monitor and Evaluate Internal Control centra-se na monitorização e controlo das
actividades de controlo interno de IT, na monitorização do processo de auto-avaliação, na
monitorização do desempenho de revisões, auditorias e examinações independentes. Inclui a
monitorização do processo para obter garantias sobre os controlos operadores por entidades
terceiras, a monitorização do processo para identificar e avaliar as excepções de controlo, a
monitorização do processo para identificar e avaliar as excepções de controlo, a monitorização do
processo para identificar e remediar as excepções de controlo.
O processo Ensure Regulatory Compliance foca-se na definição e execução de um processo para
identificar requisitos legais, contratuais, políticos e legislatórios, na avaliação da conformidade das
actividades de IT com as políticas, planos e procedimentos de IT, no report da avaliação positiva de
conformidade das actividades de IT com as políticas, planos e procedimento de IT. É também
responsável por fornecer input para alinhas as políticas, planos e procedimentos de IT em resposta
aos requisitos de conformidade, integrar os reports de IT nos requisitos legislatórios com output
similar provenientes de outras funções de negócio.
O processo Provide IT Governance inclui o estabelecimento de um executivo e um board extra de
forma a facilitar a gestão das actividades IT. Entre essas actividades, neste processo, está ainda a
revisão, subscrição, alinhamento e comunicação do desempenho IT, estratégia IT e gestão de
recursos e risco com a estratégia de negócio, a obtenção periódica de avaliação independente de
desempenho e conformidade com políticas, planos e procedimentos, a resolução de indicações da
avaliação independente e assegurar a implementação de gestão de recomendações acordadas e a
gestão de reports do IT Governance.
104
Anexo E.3 – eTOM
O eTOM divide-se em três principais áreas de gestão de processos, sendo: Strategy, Infrastructure
& Product; Operations e Enterprise Management
Strategy, Infrastructure & Product
O conjunto de processos Strategy & Commit é responsável pela geração de estratégias para
suportar os processos de ciclo de vida de infra-estrutura e de produto. É responsável também pelo
estabelecimento de compromissos de negócio dentro da empresa para suportar as estratégias.
O conjunto de processos Infrastructure Lifecycle Management é responsável pela definição,
planeamento e implementação de todas as infra-estruturas necessárias (aplicação, IT e rede), assim
como, todas as infra-estruturas de suporte e competências de negócio (centros de operação,
arquitecturas, entre outros).
O conjunto de processos Product Lifecycle Management centra-se no conhecimento sobre o
funcionamento e desenvolvimento de negócio principal da empresa.
O conjunto de processos Service Development & Management centra-se no planeamento,
desenvolvimento e entrega de serviços para a área de operações.
O conjunto de processos Resource Development & Management centra-se no planeamento,
desenvolvimento e disponibilização dos recursos necessários para o suport de produtos e serviços na
área de operações.
O conjunto de processos Supply Chain Development & Management centra-se nas interacções
necessárias da empresa com os seus fornecedores e parceiros, que estão envolvidos na manutenção
da cadeia de valor.
Operations
O conjunto de processos Operations Support & Readiness é responsável pelo suporte de gestão,
logístico e administrativo aos processos de aprovisionamento, garantia de qualidade e facturação. É
também responsável por garantir a disponibilidade operacional das mesmas áreas.
O conjunto de processos fulfillment é responsável por fornecer aos clientes os produtos solicitados
de forma correcta e no prazo adequado.
O conjunto de processos Assurance é responsável pela execução de actividades de manutenção
pró-activas e relativas para garantir que os serviços fornecidos aos clientes estejam continuamente
disponíveis e com níveis de SLAs e qualidade de serviço adequados.
O conjunto de processos Billing é responsável pela reunião de registos, produção de contas
precisas e no prazo adequado, pelo fornecimento de informações de pré-factura e factura aos
clientes, pelo processamento dos respectivos pagamentos e recepção dos mesmos.
105
O conjunto de processos Customer Relationship Management considera o conhecimento
fundamental das necessidades dos clientes e inclui todas as funcionalidades necessárias para
aquisição, melhoria e retenção de relacionamento com o cliente.
O conjunto de processos Service Management & Operations centra-se no conhecimento de
serviços (acesso, conectividade, conteúdo, entre outros) e inclui todas as funcionalidades necessárias
para a gestão e operação de serviços de comunicações e informações necessários aos clientes
O conjunto de processos Resource Management & Operations mantém o conhecimento sobre os
recursos (aplicação, IT e rede) e é responsável pela gestão de todos os recursos (por exemplo,
redes, sistemas IT, data centers, switch’s e routers) utilizados para fornecer e suportar serviços
solicitados pelos clientes.
O conjunto de processos Supplier/Partner Relationship Management suporta os processos
operacionais essenciais, tanto os processos de instância de cliente e aprovisionamento, garantia de
qualidade, facturação, como os processos de operações funcionais.
Enterprise Management
O conjunto de processos Strategic & Enterprise Planning centra-se nos processos necessários
para desenvolver as estratégias e planos para a empresa.
O conjunto de processos Financial & Asset Management centra-se na gestão de finanças e activos
da empresa.
O conjunto de processos Enterprise Risk Management garante que os riscos e ameaças à
empresa sejam identificados e os controlos apropriados sejam executados para minimizar ou eliminar
os riscos identificados.
O Conjunto de processos Stakehold & External Relations Management centra-se na gestão do
relacionamento da empresa com os seus colaboradores e entidades externas.
O conjunto de processos Enterprise Effectiveness Management centra-se na definição e
fornecimento de ferramentas e metodologias para assegurar que os processos e actividades da
empresa sejam geridos e executados eficientemente e eficazmente.
O conjunto de processos Human Resources Management fornece a infra-estrutura de recursos
humanos utilizada pela empresa para garantir os seus objectivos.
O conjunto de processos Knowledge & Research Management gere o conhecimento e pesquisa
dentro da empresa, incluído a avaliação de aquisições de potenciais tecnologias.
106
Anexo E.4 – SCOR
O SCOR é baseado em cinco processos de gestão distintos: Plan, Source, Make, Deliver e Return.
Plan: Demand/Supply Planning and Management3
À fase de planeamento balanceiam-se os recursos com os requisitos e estabelecem-se os planos
para toda a cadeia de valor, incluindo a fase de Return, e a execução de processos para Source,
Make e Deliver. Inclui, também, a gestão das regras de negócio, desempenho da cadeia de valor,
colecção de dados, inventário, activos capitais, transporte, configuração do planeamento, análise dos
requisitos de regulação e conformidade e levantamento do risco da cadeia de valor. Preocupa-se
ainda com o alinhamento do plano de unidade da cadeia de valor com o plano financeiro.
Source: Sourcing Stocked, Make-to-Order, Engineer-to-Order Product
Na fase de definir a origem da cadeia de valor é feito o escalonamento de entregas, a recepção,
verificação, transferência do produto e a manutenção de dados. Centra-se ainda na gestão de
inventário, gestão dos activos capitais, tratamento dos produtos recém-chegados, estabelecimento da
rede de fornecedores, levantamento dos requisitos de importação/exportação, gestão dos acordos
com fornecedor e levantamento do risco de origem da cadeia de valor.
Make: Make-to-Stock, Make-to-Order, Engineer-to-Order Production Execution
Durante a concepção na cadeia de valor é feito o escalonamento das actividades de produção,
emissão de produto, produção e teste, embalagem, preparação do produto e lançamento do produto
para entrega. São incluídas nesta fase, a finalização da engenharia para os processos de engineer-
to-order product, a gestão de regras, desempenho, dados, produtos em progresso, equipamento,
transporte, rede de produção, conformidade de regulação para produção e risco de concepção na
cadeia de valor.
Deliver: Order, Warehouse, Transportation, and Installation Management for Stocked, Make-to-
Order, and Engineer-to-Order Product
Na fase de entrega do produto, são contemplados todos os passos da gestão de encomendas
desde o processamento de pedido do cliente até ao controlo de descarregamento e selecção de
Transportadores. Inclui também, a gestão de warehouse, desde a recepção e selecção do produto
para dar saído do mesmo, até à recepção e verificação de produto no local do cliente, com respectiva
instalação, se necessário. A fase de entrega na cadeia de valor tem também de preocupar-se com a
facturação do cliente.
107
Return: Return of Raw Material and Receipt of Returns of Finished Goods
A fase de retorno do produto, e última, da cadeia de valor dá relevância a todos os passos para o
retorno de produtos com defeito desde o cliente – identificação das condições do produto, disposição
do produto, autorização do pedido de retorno do produto, escalonamento do despacho do produto e
retorno do produto com defeito – ao fornecedor – autorização para retorno do produto,
escalonamento da recepção do produto, recepção do produto e transferência do produto com defeito.
São também importante nesta fase, todos os passos para o retorno para manutenção, reparação ou
excesso desde a fonte – identificação das condições do produto, disposição do produto, autorização
do pedido retorno do produto e autorização de retorno do produto. Finalmente, preocupa-se com a
gestão das regras de negócio do retorno, desempenho, colecção de dados, inventário de retorno,
activos capitais, transporte, configuração de rede, requisitos e conformidade a regulações e riscos de
retorno na cadeia de valor.
