modelo de outsourcing para gestão da oferta e operação de ... · pdf...
TRANSCRIPT
UNIVERSIDADE METODISTA DE PIRACICABA FACULDADE DE ENGENHARIA, ARQUITETURA E URBANISMO
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE PRODUÇÃO
Modelo de Outsourcing para Gestão da Oferta e
Operação de Serviços de TI: Múltiplos Casos
de Aplicação
SANTA BÁRBARA d’OESTE
2010
UNIVERSIDADE METODISTA DE PIRACICABA FACULDADE DE ENGENHARIA E ARQUITETURA E URBANISMO
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE PRODUÇÃO
Modelo de Outsourcing para Gestão da Oferta e
Operação de Serviços de TI: Múltiplos Casos
de Aplicação
Gilmar Souza Santos
Orientador: Prof. Dr. Fernando Celso Campos
SANTA BÁRBARA d’OESTE
2010
Tese apresentada no Programa de Pós-Graduação em Engenharia de Produção da Faculdade de Engenharia, Arquitetura e Urbanismo da Universidade Metodista de Piracicaba – UNIMEP para obtenção do título de Doutor em Engenharia de Produção.
Modelo de Outsourcing para Gestão da Oferta e Operação
de Serviços de TI: Múltiplos Casos de Aplicação
Gilmar Souza Santos
Tese de Doutorado defendida e aprovada, em ___ de________ de _____, pela Banca Examinadora constituída pelos Professores:
Profª. Drª. Pollyana Notargiacomo Mustaro
Universidade Presbiteriana Mackenzie – UPM/PPGEE
Prof. Dr. Paulo Rogério Politano
Universidade Federal de São Carlos – UFSCar/DC
Prof. Dr. Orlando Roque da Silva
Universidade Metodista de Piracicaba – UNIMEP/PPGEP
Prof. Dr. Íris Bento da Silva
Universidade Metodista de Piracicaba – UNIMEP/PPGEP
Prof. Dr. Fernando Celso de Campos (orientador)
Universidade Metodista de Piracicaba – UNIMEP/PPGEP
Agradecimentos
Muitas pessoas e instituições contribuíram direta ou indiretamente para o esforço de
pesquisa que resultou na presente tese de doutorado. Desejo expressar meu
agradecimento e reconhecimento, especialmente:
• Ao nosso senhor Jesus Cristo, por guiar todos os meus passos.
• À minha mãe, Celina Santos (acima de tudo aqui na terra), ao meu padrasto
Paulo Francisco dos Santos (in memoriam), à minha avó Felizbela Maria de
Jesus (in memoriam) e ao meu avô Antonio Mariano Genésio dos Santos (in
memoriam) pelos valores que me ensinaram na vida e que me fizeram crer que
tudo deve ser alcançado com humildade, honestidade e perseverança.
• Aos meus queridos irmãos Zonilton, Gilvan, Celineide, Nei, Renan e Ana Paula
pelo apoio e companheirismo durante toda a minha vida.
• Aos colegas de trabalho e amigos que me deram as maiores oportunidades de
conhecimentos na minha carreira profissional: Alberto Mendonça, Sergio
Gramacho, Carol Passos, Likiso Hattori, Paulo Marcelo Moreira, Rogério Velame,
Renata Dias, Marcia Auta e Eduardo Sena.
• Meu profundo agradecimento especial ao meu orientador, Fernando Celso de
Campos, pela oportunidade, compreensão, ensinamentos e diretrizes,
imprescindíveis para a conclusão deste trabalho.
• Aos Professores Doutores Iris Bento (UNIMEP e UNICAMP), Orlando Silva
(UNIMEP), Pollyana Mustaro (MACKENZIE) e Paulo Politano (UFSCAR) pelos
valiosos direcionamentos para a versão final da tese.
• Ao PPGEP da UNIMEP pelo excelente nível de ensino, aprendizado e atenção
ao longo destes anos, em especial ao Coordenador do Departamento Prof. Dr.
Paulo Jorge Figueiredo e à Secretaria Sra. Clarissa Bolandim.
RESUMO
O presente trabalho discute uma proposta de melhoria nos processos de oferta e
operação de serviços de tecnologia da informação (TI), sob a visão do provedor
externo. Embora existam modelos do mercado para esta finalidade, a relação entre
processos, ciclo de vida e as práticas da oferta e operação de serviços de TI como
também uma visão prescritiva não têm sido objeto de pesquisa, o que o presente
estudo, de natureza pesquisa-ação, busca investigar. Percebe-se no decorrer do
estudo que os modelos de melhoria de processos disponíveis atendem aos fatores
críticos para o sucesso de um relacionamento de outsourcing de TI. Falta, porém,
integrá-los e adequá-los de forma a serem utilizados de forma efetiva. Por meio de
um modelo integrado de práticas, métodos quantitativos, matrizes de
relacionamentos e de três estudos de casos, algumas propostas são apresentadas e
discutidas como contribuições para a gestão da oferta e operação.
Palavras-chave: MOPP, Serviços de TI, Oferta e Operação de TI, Governança de
TI, Provedores de TI.
ABSTRACT
This study discusses a proposal to improve the processes of IT Services Offering and
Operation, from the external provider. Although there are models in the market for
this purpose, the relationship between processes, outsourcing life cycle and IT
Services Offering and Operation practices as well as a prescriptive vision have not
been the research object. The present study, action-research nature, seeks to
investigate. It was observed during the study models to improve processes available
to meet critical to the success of IT outsourcing relationship. It remains, however,
integrate and adapt them in order to be used effectively. Through an integrated
model of practice, quantitative methods, relationship matrix and three case studies,
some proposals are presented and discussed as contributions to offering and
operation management.
Key-words: MOPP, IT Services, IT Offering and Operation, IT Governance, IT
Providers.
Lista de Figuras
Página
Figura 1 – Mapa Mental da Estrutura do Trabalho 3
Figura 2 – Outline da Metodologia 9
Figura 3 – Estrutura Principal do Trabalho 12
Figura 4 – Estrutura da Revisão da Literatura 14
Figura 5 – Decisões Clientes x Provedores 19
Figura 6 – Melhoria Incremental x Melhoria Radical 25
Figura 7 – Governança x Gestão de Serviços de TI 28
Figura 8 – Relacionamentos entre os frameworks 32
Figura 9 – CobiT v4.1 39
Figura 10 – Modelo ISF 51
Figura 11 – Modelo GSD 52
Figura 12 – Modelo Integrated Framework 53
Figura 13 – Modelo de Combinação de Práticas do ITGI 55
Figura 14 – Modelo Gartner’s Process Model Selection Framework 57
Figura 15 – Modelo SAAD 58
Figura 16 – Modelo INNO IT 59
Figura 17 – Modelo COBITIL 61
Figura 18 – COBITIL - Relacionamento ITIL x ISO 20000 x CobiT 62
Figura 19 – Centros de Excelência em Pesquisa de Serviços de TI 63
Figura 20 – Visão Geral do MOPP 70
Figura 21 – Evolução dos Frameworks e Modelos Integrados 77
Figura 22 – Fluxo Macro do Modelo MOPP 78
Figura 23 – Ciclo de Vida de Contratação 79
Figura 24 – Média Dinâmica – SLA Contratual 88
Figura 25 – Valores no Relacionamento de Outsourcing 90
Figura 26 – Ciclo de Vida do Projeto de Implantação 94
Figura 27 - Ciclo de Vida da Operação 106
Figura 28 – Gerenciamento Demanda Operação TI 107
Figura 29 – Fábrica de Software Oculta em Demandas 113
Figura 30 – Visão Suporte de Serviços x Gestão de Mudanças 118
Figura 31 – Relação entre Indicadores Suporte Serviços 122
Figura 32 – Melhoria Contínua – Oferta e Operação de Serviços de TI 131
Figura 33 - Funil de Inovação para Provedores de TI 134
Figura 34 – Gestão de Conhecimento em Serviços de TI 137
Figura 35 – Fases do Estudo de Caso Múltiplo 156
Figura 36 – Aplicação do Modelo nos Estudos de Caso 157
Figura 37 – Fase do MOPP Aplicada no Modelo 159
Figura 38 – QFD x Análise Concorrência 164
Figura 39 – Contexto estudo de caso no MOPP 166
Figura 40 – Ciclo de Vida da oferta Outsourcing 168
Figura 41 – Estrutura da Transição 169
Figura 42 – Contexto Estudo da ISO 20000 com o MOPP 179
Figura 43 – Estrutura da ISO 20000 182
Figura 44 – Processo de implantação da ISO/IEC 20000 184
Figura 45 – Governança Interna de TI – Escopo ISO 20000 188
Figura 46 – Escopo x Detalhe MOPP 197
Figura 47 – Tela Principal de Navegação do MOPP 211
Figura 48 – Cadastros e Relacionamentos do MOPP 211
Figura 49 – Tela de Navegação Processos do MOPP 212
Figura 50 – MOPP - Consulta Processos x Frameworks x Templates 213
Figura 51 – MOPP - Tela de Consulta Processos 214
Figura 52 – MOPP - Tela de Template 215
Lista de Quadros
Página
Quadro 1 - Modelo SIPOC 11
Quadro 2 – Frameworks do mercado vinculados a Outsourcing 31
Quadro 3 – Relação PDCA x Riscos na ISO 27005 46
Quadro 4 – Exemplo de Aplicação do Modelo da Infosys 54
Quadro 5 – Comparação MOPP x e-SCM /SP 71
Quadro 6 – Comparação MOPP x ISF x GSD 72
Quadro 7 – Comparação MOPP x IF x ITGI 73
Quadro 8 – Comparação MOPP x PMS x SAAD x COBIITIL 74
Quadro 9 – Comparação MOPP x INNO-IT 75
Quadro 10 – Comparação MOPP x Modelos Integrados 76
Quadro 11 – Processo de Inteligência do Mercado 81
Quadro 12 – Prospecção do Mercado 81
Quadro 13 – Qualificação da Oportunidade 82
Quadro 14 – Relação de Certificações Exigidas em Propostas 83
Quadro 15 – Proposta Técnica 83
Quadro 16 – Precificação e Proposta Comercial 84
Quadro 17 – Negociação e Contratos. 93
Quadro 18 – Processo Plano de Projeto 96
Quadro 19 – Mobilização do Plano de Transição 98
Quadro 20 – Modelo de Operação 100
Quadro 21 – Modelo de Governança 103
Quadro 22. Exemplo de Lições Aprendidas 104
Quadro 23 – Kick-off e Lições Aprendidas 105
Quadro 24 – Gerenciamento de Demandas 108
Quadro 25 – Especificação dos Requisitos de Serviços 110
Quadro 26 – Gestão de Mudanças 117
Quadro 27 – Indicadores Operacionais 120
Quadro 28 – Suporte de Serviços 121
Quadro 29 – Projetos de Demanda Eventual 126
Quadro 30 – MOPP - Método de Movimentação de Baseline 127
Quadro 31 – MOPP – Aplicação da Movimentação de Baseline 128
Quadro 32 – Gerenciamento da Qualidade 130
Quadro 33 – Critérios de Melhoria da Qualidade 133
Quadro 34 – Matriz de Responsabilidades (RACI) 136
Quadro 35 – Processos Conhecimento e Inovação do Provedor 138
Quadro 36 – Escritório de Projetos 141
Quadro 37 – Áreas da Segurança da Informação 142
Quadro 38 – Processo de Gestão da Segurança da Informação 144
Quadro 39 – Governança & Compliance em Provedores de TI 149
Quadro 40 – Matriz Relacionamento Oferta x Outsourcing x Práticas 151
Quadro 41 – Matriz Ciclos de Vida x Práticas de Conhecimento 152
Quadro 42 – Relacionamento Oferta x Processos x Mercado 154
Quadro 43 – Protocolo de Pesquisa - Primeiro Estudo de Caso 158
Quadro 44 – Utilização do MOPP em Projeto de Transição 160
Quadro 45 – Escopo da Proposta 162
Quadro 46 – Requisitos estratégicos solicitados pelo cliente 162
Quadro 47 – Protocolo de Pesquisa – Segundo Estudo de Caso 165
Quadro 48 – Processos MOPP no Projeto de Transição 167
Quadro 49 – Protocolo de Pesquisa – Terceiro Estudo de Caso 178
Quadro 50 – Modelo MOPP na Operação dos Serviços 180
Quadro 51 – Integração ISO 9001 x ISO 20000 187
Quadro 52 – Análise do Resultado do Terceiro Estudo de Caso 189
Quadro 53 – Resumo dos Estudos de Caso do Modelo MOPP 194
Quadro 54 – Comparação PostgreSQL x MySQL x Oracle XE 209
Quadro 55 – Comparação Java x PHP x C# 210
Lista de Tabelas
Página
Tabela 1 – Certificações ISO e CMMI 66
Tabela 2 – Exemplo de certificação das empresas 67
Tabela 3 – Método para Gainsharing 85
Tabela 4 – Faturamento e Gainsharing 86
Tabela 5 – Proposta para penalidades 87
Tabela 6 – Faturamento e Penalidades 88
Tabela 7 – Rendimento Total x Sigma do Serviço de TI 114
Tabela 8 – Simulação Indicadores de Suporte 124
Lista de Abreviações
ASQ American Society for Quality
BSC Balanced Scorecard
CIO Chief Information Officer (Diretor de Informática)
CISA Certified Information Systems Auditor
CMDB Configuration Management Data Base
CMMI Capability Maturity Model Integrated
CobiT Control for Information and Related Information Technology
COPC Customer Operations Performance Center
COSO Committee of Sponsoring Organizations (Governança)
DMAIC Definir, Medir, Analisar, Melhorar e Controlar (Seis Sigma)
EFQM European Foundation for Quality Management
EPM Enterprise Project Management
eSCM eSource Capability Model
e-SCM IT Enabled Source Capability Model
GxP Normas regulatórias para produção de medicamentos
HIPAA Health Insurance Portability and Accountability Act
IF Integrated Framework
IPMA International Project Management Association
ISF Integrated System Framework for Excellence
ITGI IT Governance Institute
ITIL IT Infrastructure Library
ITSM IT Service Management
KGI Key Goal Indicator
KPI Key Performance Indicator
MBNQA Malcom Baldrige National Quality Awards
MOPP Modelo de Outsourcing para Provedores de TI
MOC Management Organizational Change
NOC Network Operation Center
OLA Operational Level Agreement
OPM3 Organizational Project Management
OUTSOURCING Terceirização
PCMM People Capability Maturity Model
PMBoK Project Management Body of Knowledge
PMI Project Management Institute
PMO Project Management Office
PMP Project Management Professional
QFD Quality Function Deployment
RFI Request for Information
RFP Request for Proposals
SLA Service Level Agreeement
SLM Service Level Management
SOX Lei Sarbanes-Oxley (Responsabilidade Fiscal EUA)
TI Tecnologia da Informação
TMA Tempo Médio de Atendimento
TME Tempo Médio de Espera
URA Unidade de Resposta Audível
WIP Work In Process (atividades em processos)
SUMÁRIO
1. INTRODUÇÃO
1.1. PROBLEMAS DE PESQUISAS E QUESTÕES CORRELATAS
1.2. OBJETIVOS
1.2.1. Objetivos Gerais
1.2.2. Objetivos Específicos
1.3. ORIGINALIDADE E INOVAÇÃO DO TRABALHO
1.4. METODOLOGIA DE PESQUISA
1.5. ESTRUTURA DO TRABALHO
1
5
6
6
6
7
9
12
2. REVISÃO DA LITERATURA
2.1. ESTRATÉGIAS DE OFERTA E OPERAÇÃO
2.1.1. Outsourcing de Tecnologia da Informação
2.1.2. Projetos de Implantação de Serviços de TI
2.1.3. Vantagem Competitiva na Indústria de TI
2.1.4. Serviços de TI
2.1.5. Estratégia Comercial da Oferta de Serviços de TI
2.1.6. Qualidade em Serviços de TI
2.1.7. Governança de TI
2.1.8. Gestão do Conhecimento e Inovação em TI
2.2. FRAMEWORKS DE OFERTA E OPERAÇÃO
2.2.1. CMMI 1.2
2.2.2. PCMM
2.2.3. ITIL v3
2.2.4. ISO/IEC 20000
2.2.5. ISO/IEC 27001
2.2.6. Cobit v4.1
2.2.7. Val IT
2.2.8. eSCM/SP
2.2.9. SAS 70
2.2.10. COSO
2.2.11. PMBoK – PMI
2.2.12. OPM3 – PMI
2.2.13. IPMA
14
15
15
17
20
22
23
25
27
28
31
33
34
35
37
37
38
39
40
41
42
42
43
44
2.2.14. COPC
2.2.15. ISO 9001
2.2.16. SO 14001
2.2.17. ISO 27005
2.2.18. ISO 38500
2.2.19. Lean Six Sigma
2.3. PRINCIPAIS MODELOS E TRABALHOS PUBLICADOS
2.3.1. ISF – Integrated System Framework for Excellence
2.3.2. Global Service Delivery – TATA
2.3.3. Integrated Framework – Infosys
2.3.4. ITGI – IT Governance Institute
2.3.5. Gartner PMS – Process Model Selection Framework
2.3.6. Saad de Outsourcing de TI
2.3.7. INNOIT – Innovation IT
2.3.8. GSS – COBITIL
2.4. CENTROS DE EXCELÊNCIA
2.5. MERCADO DE TI X MODELOS INTEGRADOS
44
45
46
46
47
48
50
50
52
53
55
56
57
59
60
62
65
3. DESENVOLVIMENTO E ANÁLISE DO MODELO
3.1. GESTÃO DA CONTRATAÇÃO
3.1.1. Inteligência de Mercado
3.1.2. Prospecção de Mercado
3.1.3. Qualificação de Oportunidade
3.1.4. Proposta Técnica
3.1.5. Proposta Comercial e Precificação
3.1.5.1. Método de Bonificações e Penalidades
3.1.6. Negociação e Contrato
3.2. GESTÃO DO PROJETO DE IMPLANTAÇÃO
3.2.1. Plano de Projeto
3.2.2. Mobilização do Plano de Transição (As Is)
3.2.3. Modelo de Operação
3.2.4. Modelo de Governança
3.2.5. Kick Off Meeting e Lições Aprendidas
3.3. OPERAÇÃO DOS SERVIÇOS
3.3.1. Gerenciamento da Demanda
3.3.2. Especificação dos Requisitos da Operação
3.3.2.1. Método para OLA – Equipe Provedor
69
78
80
81
82
83
84
85
89
94
95
97
99
101
104
106
106
109
111
3.3.3. Gestão de Mudanças
3.3.4. Suporte de Serviços
3.3.4.1. Método para Avaliação Indicadores Suporte Serviços
3.3.4.2. Método de Dimensionamento Capacidade Suporte
3.3.5. Projetos de Demandas Eventuais
3.3.5.1. Método para Movimentação de Baseline
3.4. GESTÃO DA QUALIDADE
3.4.1. Método para Avaliação do Nível Qualidade Serviços TI
3.5. GESTÃO DO CONHECIMENTO E INOVAÇÃO
3.6. ESCRITÓRIO DE PROJETOS (PMO)
3.7. GESTÃO DA SEGURANÇA DA INFORMAÇÃO
3.8. GOVERNANÇA & COMPLIANCE DE TI
115
118
122
123
125
126
128
131
134
139
142
145
4. MATRIZES DE RELACIONAMENTO DE PRÁTICAS
4.1. OFERTA X CICLO DE VIDA X PRÁTICA
4.2. CICLO DE VIDA X PRÁTICAS DE CONHECIMENTO
4.3. OFERTA X PROCESSOS X NECESSIDADES CLIENTES
150
150
152
153
5. APLICAÇÃO DO MODELO
5.1. CASO 1 – CONTRATAÇÃO DE SERVIÇOS DE TI
5.2. CASO 2 – IMPLANTAÇÃO DE SERVIÇOS DE TI
5.3. CASO 3 – OPERAÇÃO DE SERVIÇOS DE TI
156
157
165
178
6. CONCLUSÃO
6.1. LIMITAÇÕES DA PESQUISA
6.2. TRABALHOS FUTUROS
191
196
197
REFERÊNCIAS BIBLIOGRÁFICAS 199
APÊNDICE A – Telas Sistemas MOPP 209
1
1. INTRODUÇÃO
Os modelos voltados para gestão da oferta e operação de serviços foram
viabilizados a partir da década de 90 com a disseminação dos frameworks de
qualidade, gestão e governança de TI a exemplo do CMMI – Capability Maturity
Model Integration, ITIL – IT Infrastructure Library e CobiT - Control Objectives for
Information and related Technology. As metodologias específicas mais conhecidas
para gestão da oferta e operação de serviços de TI, oriundas do governo americano
(CMMI), governo inglês (ITIL), entidades privadas (PMBoK – Project Management
Body of Knowledge) e universidades (e-SCM – eSourcing Capability Model), em
conjunto com as necessidades das empresas de TI em combinar estas práticas,
estabeleceram as bases para modelos integrados, principalmente dentro de grandes
empresas (ITIL SS, 2007; SAAD, 2006). Entretanto, segundo Monteiro (2004),
quando analisados individualmente, verifica-se que os modelos disponíveis não
atendem completamente aos fatores críticos da terceirização de serviços de TI,
devido a uma demanda de soluções que atendam processos de TI cada vez mais
integrados.
Na década atual, torna-se necessário combinar práticas de uma forma mais
prescritiva, com uma atenção maior em provedores externos de TI e no ciclo de vida
de outsourcing (SANTOS, 2006). Outro aspecto importante é a crescente
necessidade de modelos combinados prescritivos para oferta e operação de
serviços no mercado internacional, no qual o uso de elementos como custos,
qualidade e inovação assume uma grande importância (SONG, 2007; KUMAR,
2007).
Dessa maneira, este trabalho apresenta algumas contribuições importantes para
utilização em provedores externos, por meio de um modelo prescritivo de integração
de práticas desenvolvido pelo autor, denominado MOPP (Modelo de Outsourcing
para Provedores de TI), matrizes de relacionamentos, métodos, exemplos de
aplicação em serviços de TI e um aplicativo contendo base de dados do modelo,
conforme o ciclo de vida da oferta e operação de serviços de TI.
2
Este capítulo introdutório apresenta o contexto do tema estudado, os objetivos,
originalidade, justificativa, relevância, estrutura do trabalho e a metodologia aplicada.
O tema da pesquisa enquadra-se na área de concentração Gestão e Estratégias em
Engenharia de Produção. A tese também apresenta contribuições para as seguintes
áreas e subáreas de conhecimento em Engenharia de Produção da ABEPRO
(Associação Brasileira de Engenharia de Produção): a) 4.1 Gestão de Sistemas de
Qualidade; 4.3. Normalização, Auditoria e Certificação; 6.2. Gestão de Projetos; 6.6.
Gestão da Inovação; 6.7. Gestão da Tecnologia; 6.8. Gestão do Conhecimento.
Existem no mercado modelos que visam suportar as atividades de provedores de
serviços em Gestão Integrada de Outsourcing. O e-SCM/SP (eSourcing Capability
Model) da Universidade Carnegie-Mellon é o mais conhecido deles. Outro é o ISF
(Integrated System Framework for Excellence) da PUC-RS/ISD. No entanto, estes
modelos são descritivos, proprietários e com uma necessidade de investimentos
significativos para implantação. Também não seguem um ciclo de vida prescritivo
(eSCM) e são específicos de provedores internos de TI (ISF). Conforme Santos e
Campos (2008b), os valores da implantação do e-SCM podem atingir dois milhões
de reais para sair do nível inicial diretamente para o último nível de maturidade.
Nesse contexto, a pesquisa visa complementar os modelos integrados atuais,
fundamentados, na sua maioria, na descrição não-prescritiva do outsourcing de
serviços e produção sob o ponto de vista apenas da empresa compradora (cliente).
O tema da pesquisa não se restringe a práticas de gestão de TI, como também a
governança, segurança, qualidade, inovação, conhecimento e gerenciamento de
projetos. Pelas pesquisas realizadas, não existe estudo mais aprofundado visando
vincular um modelo prescritivo, não proprietário para provedores externos de TI, às
melhores práticas do mercado como eSCM-SP, CobiT, PMI, ITIL, TQM, CMMI e
outros. A relevância deste trabalho está em contribuir na oferta de outsourcing com
um modelo denominado MOPP (Modelo de Outsourcing para Provedores) de forma
automatizada conforme o tipo de oferta e as necessidades dos clientes e também
mostrar estudos de casos com a aplicação do modelo. As práticas são vinculadas
dentro de ciclos de cada área de conhecimento (venda, implantação, operação,
governança, qualidade, conhecimento e segurança da informação), formando um
ciclo maior que compõe o modelo.
3
O trabalho procura demonstrar que os provedores devem se aprofundar e investir
em modelos integrados de práticas e certificações para entregar valor aos seus
clientes. Para que um provedor sobreviva e vença, é preciso que obtenha vantagens
sobre os concorrentes. É necessário ser melhor que a concorrência em fazer
produtos e serviços de valor superior para os clientes (HITT et al., 2007). Outro fator
importante demonstrado no trabalho é a necessidade dos provedores estarem
alinhados com a vantagem competitiva das empresas clientes, por meio de
integração de melhores práticas, conforme a necessidade da oferta ou operação dos
serviços de TI. Os serviços e operação de TI ofertados somente possuem valor no
contexto da estratégia. (KAPLAN & NORTON, 2004). A estrutura do MOPP é
composta por ciclo de vida, métodos, áreas de conhecimento, matrizes e estudos de
casos em operação e oferta de serviços de TI, conforme mostrado no mapa mental
da figura 1.
Figura 1 – Mapa Mental da Estrutura do Trabalho
4
A relevância da pesquisa está associada à importância das melhores práticas e
certificações para os provedores no relacionamento com os seus clientes e na busca
de vantagem competitiva. Existem problemas neste processo, a exemplo de
ausência de melhoria contínua e da entrega de serviços inconsistentes, conforme
relatado por Saad (2006). Segundo Slack (2002), uma gestão da operação de
sucesso passa por uma mentalidade que considere tanto o cliente quando os
concorrentes. O modelo desenvolve um modelo de oferta e operação de serviços
(do contrato ao serviço pós-venda) com a finalidade de contribuir na busca desta
vantagem competitiva.
O MOPP será útil para os provedores de Tecnologia da Informação (TI) que estão
buscando vantagem competitiva no mercado mundial, por meio do uso de modelos
de integração dos processos de oferta de outsourcing. Conforme Schniederjans et
al. (2007), existe uma urgente necessidade de formar uma base de conceitos,
filosofia, procedimentos, metodologias e práticas de outsourcing para resolver
alguns problemas de qualidade em serviços de TI, enquanto Hammer (2000) relata
que, em uma relação comercial, os clientes não estão de modo algum interessados
pelas atividades às quais os provedores dedicam parte de suas energias: o
orçamento anual, o organograma, o plano de sucessão de executivos, o programa
de remuneração. Na melhor das hipóteses, tudo isso não passa de meios para a
consecução de um fim. Os clientes exigem resultados.
Conforme o ITGI (2008), existem problemas para entregar esses resultados para os
clientes: a) Os indicadores são geralmente reativos, não espelhando o que
efetivamente ocorre nos serviços; b) Existe uma dificuldade no acesso às práticas
mais adequadas como também aos seus templates; c) Uma combinação de práticas
não são avaliadas pelos provedores; d) Existe apenas a aplicação de padrões de
forma individual (ex. ITIL); e) As práticas não são relacionadas ao seu devido uso
no ciclo de vida de outsourcing; f) A utilização de modelos, processos e governança
pelos provedores não acompanham os clientes ou vice-versa.
Os valores mudam assim como os cenários. Os provedores devem estar preparados
para oferecer qualidade e inovação e não apenas redução de custos dos seus
serviços aos clientes. Também precisam estar sintonizados com a estratégia
5
corporativa e de governança de TI dos seus clientes, por meio de uma efetiva
governança de seus contratos e também do uso combinado das melhores práticas
de gestão estratégica de TI, a exemplo do CobiT e COSO. Para Silva et al. (2006), o
mercado de tecnologia da informação atual é marcado por novas e inovadoras
maneiras de se fazer negócios. A arena atual de negócios internacionais requer que
o negócio entregue alta qualidade para seus clientes. Iniciativas de qualidade não
devem estar restritas a um departamento ou função dentro de um provedor
(FEIGENBAUM, 2007). Portanto, esta pesquisa contribui para o conhecimento e
aplicação pelos provedores das melhores práticas de forma combinada e também de
um modelo integrado de oferta e operação de serviços de TI e de métodos inéditos e
testados por meio de estudos de casos. Neste contexto, torna-se necessário
responder aos problemas e questões relacionadas com os modelos de outsourcing,
conforme mostrado no tópico seguinte.
1.1. Problema de Pesquisa e Questões Correlatas
A definição do problema de pesquisa pode ser descrita na seguinte questão
principal:
“Por que não existe um modelo prescritivo de oferta de outsourcing, não
proprietário, para dar suporte aos provedores externos de TI no seu
relacionamento com o cliente durante o ciclo de vida da oferta e que utilize os
processos dos melhores frameworks do mercado?“
Além da questão principal existem outras que derivam desta e carecem de uma
investigação e tratamento, a saber:
Questão 1: É possível desenvolver um modelo de oferta de outsourcing para
suportar os provedores de TI no seu relacionamento com o cliente, a partir de um
ciclo de vida que contemple outsourcing, governança, serviços de TI, qualidade,
segurança e inovação?
6
Questão 2: É possível vincular as práticas do mercado a cada etapa do ciclo de
forma independente e automatizado, ou seja, o provedor pode retirar ou incluir novas
práticas a cada processo?
Questão 3: Pode ser desenvolvido um relacionamento de cada oferta do provedor
com as necessidade do cliente, conforme o segmento de mercado (financeiro,
industrial, comércio, saúde e governo), a partir de um relacionamento com as
melhores práticas de TI adequadas a cada setor?
Questão 4: É possível desenvolver um modelo prescritivo que considere a aplicação
das principais práticas do mercado em diversas áreas de atuação do provedor
(projetos, software, governança, qualidade, inovação, serviços de TI) indicando a
melhor utilização da prática dentro de um ciclo de vida de oferta de outsourcing?
1.2. Objetivos
Neste capítulo são apresentados os objetivos do trabalho. Inicialmente é discutido o
objetivo geral e na sequência o detalhamento dos objetivos específicos.
1.2.1. Objetivo Geral
O objetivo principal deste trabalho é o de pesquisar e propor um modelo de oferta de
outsourcing de produtos e serviços, de forma integrada e prescritiva, não
proprietário, para provedores externos de TI, a partir do ciclo de vida vinculado às
melhores práticas do mercado em várias áreas de conhecimento: vendas,
implantação, operação, governança, qualidade, conhecimento, inovação, segurança
da informação e projetos.
1.2.2. Objetivos Específicos
a. Desenvolver o ciclo de vida para oferta de outsourcing contemplando uma
sequência lógica de processos das áreas de venda, projeto de implantação,
operação, governança, qualidade, inovação e segurança da informação;
b. Automatizar o modelo com ferramentas open source do mercado, visando seu
uso de forma gratuita pelos provedores de TI;
7
c. Vincular as etapas do ciclo de vida com os processos dentro das melhores
práticas do mercado (Ex. COSO, CobiT, PMI, IPMA, ITIL, ISO 20000), entrando
no detalhe de como cada processo da prática estudada pode ser utilizado no
modelo e apontando a fonte de cada framework para a busca e pesquisa;
d. Criar relacionamentos de cada processo do ciclo de vida com templates;
e. Desenvolver matrizes de relacionamento da aplicação das melhores práticas
conforme o tipo de oferta do provedor de TI (ex. fábrica de software, service
desk, NOC);
f. Desenvolver matrizes de relacionamento da aplicação das melhores práticas com
as necessidades do cliente e também conforme cada etapa do ciclo de vida do
modelo;
g. Provar que o modelo funciona em venda, projeto de implantação e na operação
de serviços de TI, por meio de estudos de caso. Objetiva também indicar quais
etapas e práticas foram utilizadas, referenciando o modelo;
h. Tornar o modelo independente das práticas utilizadas, para que o provedor tenha
flexibilidade de incluir, atualizar ou excluir as práticas relacionadas como também
independer das versões dos frameworks;
i. Fornecer aos provedores de TI métodos quantitativos de gainsharing
(bonificação), penalty (penalidade), dimensionamento, OLA (Operational Level
Agreement ou Níveis de Serviços Operacionais), Melhoria Contínua e de
movimentação de baseline para serem utilizados na análise da oferta e operação
de outsourcing.
1.3. Originalidade e Inovação do Trabalho
A originalidade deste trabalho está dividida em cinco elementos:
− Um modelo de ciclo de vida x processos vinculando as melhores práticas
e a templates
Foi desenvolvido um modelo denominado MOPP para uso dos provedores de TI
em suas ofertas e operação de outsourcing. O objetivo principal do modelo é
combinar as práticas existentes no mercado, de forma prescritiva. Consiste em
vincular os processos de cada prática a uma etapa do ciclo de vida,
8
prescrevendo para o provedor uma maneira prática para uso nas suas
atividades de oferta e operação dos serviços de TI.
− Matrizes relacionando oferta x práticas x necessidades dos clientes
As matrizes são úteis para os provedores selecionarem qual a prática mais
adequada conforme a oferta e também conforme as necessidades dos clientes.
Também são utilizadas para relacionarem qual é a prática mais necessária
conforme o ciclo de vida da oferta e operação dos serviços de TI.
− Casos práticos do uso efetivo de frameworks em serviços de TI
Os estudos práticos apresentados na pesquisa têm a intenção de contribuir no
uso do modelo pelos provedores nas vendas, transição e operação de TI.
Elementos como Propostas de Serviços de TI, Modelo de Operação, Modelo de
Governança e Certificação da Operação de TI são demonstrados de forma clara
e objetiva, permitindo a utilização nos processos de outsourcing.
− Métodos quantitativos para operação de serviços de TI
São mostrados os métodos de dimensionamento de baselines, Níveis
Operacionais de Serviços (OLA) com uso de práticas Lean Six Sigma, nível de
qualidade, dimensionamento de recursos para propostas, avaliação da melhoria
contínua e também cálculos de penalidades e bonificações de forma
ponderada, conforme os níveis de serviços (SLA) apresentados.
− Aplicativo contendo uma base de informações do modelo para uso pelos
provedores
Disponibilização de uma base de dados atualizável, desenvolvida em software
livre (Java e PostgreSQL) para consulta e atualização de nova combinação de
práticas dentro do modelo MOPP. O Java e PostgreSQL podem ser instalados e
utilizados sem maiores encargos para os provedores. Uma justificativa da
escolha desta plataforma é apresentada no Apêndice A. Também são
mostradas as telas, instruções de uso e instalação da aplicação desenvolvida. A
customização mais adequada de cada processo de cada etapa do ciclo de vida
pode ser realizada pelo provedor, como também atualizada, ajudando a
melhorar ainda mais o modelo.
9
1.4. Metodologia de Pesquisa
Do ponto de vista de seus objetivos a abordagem metodológica é descritiva e
explicativa, pois proporciona um maior conhecimento do assunto, por meio da
construção de um referencial teórico e também da observação e participação em
oferta e operação de TI. Apresenta informações sobre uma dada situação, grupo ou
entidade (Miguel, 2007). Também existe a preocupação de observar, registrar,
analisar, classificar e interpretar os fatos, além de identificar os fatores que
determinaram ou que contribuíram para a ocorrência dos resultados dos estudos de
caso, como também contribuir com novos conhecimentos relacionados à
problemática em questão. Conforme o outline (esboço) mostrado na figura 2, a
partir de um referencial teórico, o modelo é desenvolvido e aplicado por meio de
uma pesquisa-ação em múltiplos estudos de casos. Uma avaliação de resultados é
realizada para cada estudo. Finalmente, é apresentada uma conclusão e avaliação
final da pesquisa.
Figura 2 – Outline da Metodologia
Do ponto de vista da abordagem do problema é uma pesquisa qualitativa, onde o
modelo de oferta e operação de serviços de TI e sua importância é o motivo principal
da abordagem. O procedimento técnico adotado foi o estudo de caso. Segundo
Miguel et al. (2009), este tipo de pesquisa é um estudo de natureza empírica que
10
investiga um determinado fenômeno, geralmente contemporâneo, dentro de um
contexto real de vida, quando as fronteiras entre o fenômeno e o contexto em que
ele se insere não são claramente definidas. A principal tendência em todos os tipos
de estudo de caso, é que estes tentam esclarecer o motivo pelo qual uma decisão
ou um conjunto de decisões foram tomadas, como foram implementadas e quais
resultados foram alcançados. Neste trabalho, o objetivo foi analisar a gestão da
oferta e operação de serviços de TI, permitindo o seu amplo e detalhado
conhecimento (GIL, 1996). Procurou-se também utilizar protocolos para os estudos
de casos. Yin (2005) relata que o protocolo de estudo de caso é uma das táticas
principais para aumentar a confiabilidade da pesquisa e destina-se a orientar o
pesquisador ao realizar a coleta de dados. O estudo de caso múltiplo foi realizado
junto a serviços de TI em três segmentos de mercado: manufatura, financeira e de
telecomunicações.
Quanto à sua natureza é uma pesquisa-ação a qual foi concebida e realizada em
estreita associação com o desenvolvimento e aplicação de um modelo em três tipos
de problemas de outsourcing de TI, no qual o pesquisador e os participantes da
situação ou do problema estavam envolvidos de modo cooperativo ou participativo
(THIOLLENT, 2005). A pesquisa-ação é um tipo de metodologia de pesquisa na qual
o pesquisador deve estar empenhado em solucionar algum problema através de
uma ação. A pesquisa-ação foi desenvolvida por meio de três estudos de casos,
tendo o autor influenciado nos resultados obtidos. Para este tipo de pesquisa, o
problema a ser solucionado tornou-se objeto de estudo que foi abordado durante o
desenvolvimento da tese.
A metodologia de pesquisa-ação para os estudos de casos seguiu o descrito em
(Miguel et al., 2009): a) o autor tomou ações durante todo o projeto, pois fazia parte
dele, não sendo observador; b) a pesquisa foi interativa, envolvendo cooperação e
interatividade com a equipe do projeto; c) a pesquisa foi conduzida em tempo real,
sendo os estudos de caso realizados no momento da execução; d) a pesquisa
estava relacionada a uma mudança, no caso aplicação do modelo na oferta e
operação de serviços de TI; e) envolveu vários tipos de coleta de dados, tanto
técnicas quantitativas como qualitativas para o desenvolvimento dos modelos de
operação e de governança; f) a pesquisa envolveu um pré-entendimento e avaliação
11
da situação atual antes da aplicação do modelo e g) o autor influenciou nos
resultados dos trabalhos, dada suas qualificações, uso do modelo apresentado
nesta tese e suas certificações. As pesquisas tiveram como base uma participação
direta na concepção e implantação de serviços de outsourcing de TI, aplicando o
modelo prescrito neste trabalho.
Na documentação dos processos do modelo MOPP, utilizou-se o padrão MIT
Process Handbook do MIT (MIT, 2009) para a apresentação da base de dados.
Iniciado em 1991, esta biblioteca apresenta uma documentação para consulta online
de 5.000 atividades de negócios. Inclui também estudos de casos, processos
relacionados e modelos. Utiliza-se neste trabalho alguns conceitos deste framework
como a estruturação e apresentação de processos, incluindo seus relacionamentos.
Também foi utilizado como padrão o SIPOC (Suppliers-Inputs-Process-Outputs-
Customers). Este diagrama define os principais processos envolvidos no projeto,
facilitando a visualização do escopo do modelo. O quadro 1 mostra o modelo do
SIPOC utilizado na pesquisa.
Quadro 1 - Modelo SIPOC
Fornecedores
(Suppliers)
Insumos
(Inputs)
Processo
(Process)
Produtos
(Outputs)
Clientes
(Customers)
Fornecedores do
processo
Entradas para o
processo
Atividades do
processo
Saídas do
processo
Clientes que
utilizarão as saídas
Para as matrizes, o trabalho seguiu os padrões L-shaped matrix e o T-shaped matrix
adaptados, mais comuns e que servem para comparar duas ou três informações
para identificação dos respectivos relacionamentos (PRIES, 2009). Um diagrama em
formato de matriz é utilizado para analisar e ilustrar relacionamentos entre dois ou
mais grupos de informações.
Para a apresentação do modelo na internet, utilizou-se a linguagem Java/JSP na sua
versão Java 6, o banco de dados PostgreSQL 8.3 e o servidor web Tomcat 6, todos
software livre (open source). O modelo Open Source difere do modelo tradicional em
basicamente dois aspectos: a) o processo de desenvolvimento é essencialmente
uma produção colaborativa e b) a sua filosofia de propriedade intelectual permite a
12
livre distribuição do código fonte, bem como o direito de modificá-lo. Informações
sobre o aplicativo MOPP e os critérios de seleção dos padrões de software livre
estão no apêndice A do trabalho.
A seguir é apresentada a estrutura do trabalho desenvolvida para a tese,
abrangendo introdução, referencial teórico, desenvolvimento do modelo, aplicação
do modelo e conclusão.
1.5. Estrutura do Trabalho
Conforme mostrado na figura 3, a estrutura principal compreende cinco capítulos. O
trabalho está fundamentado em um referencial teórico, desenvolvimento do modelo,
aplicação do modelo e conclusão. Um apêndice também faz parte do trabalho,
conforme detalhamento a seguir.
Figura 3 – Estrutura Principal do Trabalho
Inicialmente são apresentados o contexto, justificativa, problema da pesquisa,
originalidade, delimitação, metodologia e a estrutura do trabalho. Na sequência, o
referencial teórico tem o papel de fundamentar, bem como fornecer subsídio para a
estruturação do modelo. Apresenta-se nesta fase uma revisão das estratégias que
13
levaram à utilização dos modelos combinados, os principais frameworks de oferta,
projetos e operação de serviços de TI e os modelos atuais de combinação de
práticas. Apresenta também os centros de excelência e uma visão geral do mercado
atual de TI.
A etapa do desenvolvimento contempla a formulação do modelo MOPP, abrangendo
o ciclo de vida, matrizes e métodos. Na sequência, é apresentada a aplicação do
modelo por meio de estudos de casos múltiplos, relacionando as etapas de
Contratação, Implantação e Operação dos serviços. Foram selecionados três casos:
RFP (Request for Proposals) de Outsourcing de Infraestrutura de TI, Projeto de
Implantação de um Outsourcing de ERP (Enterprise Resource Planning) e Operação
em um Centro de Monitoramento de Rede (NOC). Finalmente, na fase da conclusão,
busca-se responder aos objetivos e proposições inicialmente formulados, como
também apresentar os resultados dos trabalhos, contribuições e a sua continuidade.
No apêndice A, apresenta-se um guia de instalação e uso da base de dados do
MOPP. Contempla informações sobre instalação, acesso, consulta e atualização da
base de dados do aplicativo MOPP. Também são apresentados os critérios de
seleção de plataforma open source.
14
2. REVISÃO DA LITERATURA
Neste capítulo é apresentado o referencial teórico que foi utilizado para realização do
presente trabalho. O material bibliográfico mostra um conteúdo sobre as
metodologias e práticas que sustentam o trabalho. Também é apresentada a revisão
bibliográfica sobre as pesquisas realizadas atualmente, destacando ciclos de vida de
outsourcing, projetos, serviços e de governança de TI.
Conforme mostrado na figura 4, a revisão da literatura inicia-se com uma análise das
principais estratégias e conceitos que servem de diretrizes para o uso de frameworks
e das práticas combinadas. Na sequência são explorados os principais frameworks
de melhores práticas da oferta e operação de serviços de TI do mercado. Para
complementar o referencial, são mostrados os modelos integrados atuais, principais
centros de excelência no assunto (na visão da pesquisa), e também uma visão geral
do mercado de TI, alvo dos modelos integrados.
Figura 4 – Estrutura da Revisão da Literatura
15
2.1. Estratégias de Oferta e Operação de Serviços de TI
Apresenta-se nesta seção as técnicas e estratégias que são utilizadas na gestão da
oferta e operação dos serviços de TI. Conceitos relacionados a outsourcing,
estratégia empresarial, serviços de TI, projetos e qualidade de TI são necessário
para o entendimento do modelo MOPP.
2.1.1. Outsourcing de Tecnologia da Informação
Gottschalk e Solli-Saether (2006) definem outsourcing de TI como um processo de
contratação total ou parcial dos serviços de TI de uma empresa para um ou mais
fornecedores externos. O termo outsourcing é proveniente do conceito de sourcing,
que significa deslocamento total ou parcial das atividades executadas pelas
empresas para um prestador de serviços (provedor), dentro ou fora da empresa.
Quando a provisão de serviços é realizada por um provedor contratado fora da
empresa, denomina-se de outsourcing (terceirização). Existem outras variações com
origem no conceito de sourcing, como multisourcing (terceirização dos serviços para
mais de um provedor), insourcing (internalização dos serviços), co-sourcing (criação
de uma empresa independente pelo cliente e pelo provedor para prestar
determinado serviço), BPO - Business Process Outsourcing (terceirização de
processos de negócios a exemplo de folha de pagamento, contabilidade e gestão
financeira) e, finalmente, KPO - Knowledge Process Outsourcing (terceirização das
atividades de gestão de conhecimento & inovação).
Existem provedores de TI que fornecem apenas uma parte da solução (ex. fábrica
de software), como também existe o conceito de full-service providers ou provedores
que cobrem todos os serviços e produtos de TI. Este tipo de provedor é o alvo
principal desta pesquisa. Conforme Harries e Harrison (2008), o outsourcing é a
transferência da responsabilidade da gestão e operacionalização para as funções de
negócios não principais para uma terceira parte. Segundo Maschio e Silva (2007),
um exemplo é o conceito de fábrica de software. Nas organizações mais maduras, o
cliente define a solução e a especificação pode ser realizada pelo provedor por meio
de sua fábrica de requisitos. Após a validação da especificação, o projeto e o
desenvolvimento do software são realizados pela fábrica de código. A cotação do
preço e prazo de codificação são feitas com base na especificação. Na entrega do
16
produto (código), o próprio fornecedor do outsourcing pode realizar os testes
funcionais, integração e de regressão, através de sua fábrica de testes. Tudo isto
ocorre principalmente em provedores com CMMI nível 5 (nível máximo de qualidade
em processos de software dessa certificação).
Segundo Saad (2006), algumas vantagens do outsourcing para as empresas são:
a. Concentração no seu negócio principal (core capabilities);
b. Redução de custos e aumento de produtividade;
c. Melhoria no desempenho dos serviços;
d. Manter-se atualizado em relação aos concorrentes;
e. Proporcionar acesso a novas tecnologias;
f. Redução de riscos;
g. Compartilhamento de riscos;
h. Padronização dos diversos sistemas;
i. Facilitação de migração de novos sistemas;
j. Reengenharia e gestão dos sistemas legados;
k. Flexibilidade na redução ou aumento de recursos.
Um exemplo de outsourcing é a terceirização de um serviço de monitoramento e
gerenciamento de redes de uma empresa petroquímica para um ou mais provedores
de TI. Este serviço não faz parte do negócio principal da empresa (resinas
petroquímicas). Além disto, estando na responsabilidade de uma empresa
especializada, o risco é compartilhado, ocorre uma atualização mais rápida da
tecnologia de redes LAN, WAN e Wireless (sem fio), com aumento de produtividade
e redução de custos.
Existem algumas contradições importantes sobre o outsourcing. Atualmente as
empresas não terceirizam apenas as atividades que não fazem parte do seu core
business (negócio principal). Os clientes podem terceirizar também funções críticas
para o sucesso dos seus negócios (BURKHOLDER, 2006). Um exemplo é o
conceito de KPO (Knowledge Process Outsourcing) e de Open Innovation (Inovação
Aberta), quando os problemas para melhoria de processos do core business são
solucionados pelo mercado, em empresas ou profissionais que tenham a solução.
17
Diversos modelos de melhoria de processos estão disponíveis no mercado com o
objetivo de auxiliar a organização na obtenção da qualidade em outsourcing.
Quando analisados individualmente, verifica-se que os modelos disponíveis não
atendem completamente os fatores críticos da terceirização de serviços de TI, pelo
seu caráter descritivo, sem vínculo a ciclo de vida de outsourcing e necessidades
dos clientes. Como exemplo, no que se refere ao ciclo de vida, foi desenvolvido o
modelo eSCM-SP (eSourcing Capability Model for Service Providers) como um guia
de melhores práticas descritivo para a melhoria da capacidade dos provedores de
serviço de TI (MONTEIRO, 2004).
Conforme Halvey e Melby (2005), os aspectos financeiros do outsourcing envolvem
todas as etapas do ciclo de vida da oferta e operação de serviços de TI. A empresa
que faz um outsourcing busca dos seus provedores de TI, além da qualidade,
economia do custo de propriedade dos serviços. Segundo Welborn (2008), o
outsourcing nem sempre garante sucesso no negócio. Existe risco envolvido. A
vantagem de outsourcing deve ser balanceada cuidadosamente com os riscos
embutidos em custos atrativos. Sem uma técnica de análise de avaliação de riscos,
a alternativa de terceirização pode gerar resultados imprevisíveis como: problemas
de entrega no prazo, baixa qualidade dos serviços e outras variáveis negativas de
desempenho.
2.1.2. Projetos de Implantação de Serviços
O PMBoK (2004:1), manual de melhores práticas em gerenciamento de projetos do
PMI – Project Management Institute, define um projeto como: Um empreendimento
temporário que tem atividades relacionadas e executadas progressivamente para
atingir um propósito (objetivo) claramente definido, tendo um produto (ou serviço)
único como resultado. Segundo Heldman (2005), o gerenciamento de projetos
abrange uma série de ferramentas e técnicas, utilizadas por pessoas para
descrever, organizar e monitorar o andamento das atividades do projeto. Os
gerentes de projetos são os responsáveis pela administração dos processos
envolvidos e pela aplicação das ferramentas e técnicas necessárias ao cumprimento
das atividades do projeto. O gerenciamento de projetos consiste na aplicação de
conhecimento. Patah et al (2007) argumenta que um projeto é um empreendimento
18
temporário com o objetivo de criar um produto ou serviço único. O gerenciamento de
projetos por sua vez é a aplicação de conhecimentos, habilidades, ferramentas e
técnicas para projetar atividades que visam atingir os requisitos do projeto.
O projeto de implantação ou de transição é previsto na contratação dos serviços e
visa preparar os serviços para a operação. Uma atividade de due diligence faz parte
desta etapa e visa assegurar que as condições da proposta (parque de hardware,
software, pessoas, processos, redes) continuam os mesmos. Entende-se por due
diligence o processo mútuo em que duas organizações examinam previamente os
riscos e condições associadas a uma negociação em andamento, antes que o
formato final do negócio seja estabelecido (SAAD, 2006). Dentre as questões
tipicamente examinadas encontram-se os aspectos financeiros, legais,
administrativos e técnicos. O outsourcing de serviços de TI é uma das áreas em que
a realização de um due diligence mostra-se altamente recomendável. As
informações devem ser disponibilizadas por cada uma das partes (cliente e
provedor) de forma transparente e de acordo com o nível solicitado de detalhes,
visando a criação de um cenário favorável a uma negociação.
Bayuk (2009) ressalta que a apresentação por parte do provedor de certificações
como ISO 20000, ISO 27001, CMMI e também a SAS 70 (Governança) elimina a
solicitação de informações de forma excessiva, reduzindo o custo do processo de
due diligence. As adequações maiores provenientes do processo devem ser
realizadas por meio de solicitação de mudança (Change Request). Saad (2006)
observa que o projeto de implantação dos serviços é realizado durante o período de
transição. Este período é compreendido entre o momento em que o contrato com o
provedor é assinado e o momento em que a operação é integralmente transferida
para o provedor. A implantação de serviços é um projeto que ocorre logo após a
venda dos mesmos.
Os projetos de venda e implementação requerem um processo de negociação,
conforme pode ser visto em Kujala et al. (2008). A visão principal é integrar todas as
fases dentro de uma solução total. Existem duas perspectivas: a do fornecedor e a
do cliente. Existe uma troca constante de informações entre os dois, desde a fase
de preparação da proposta até o projeto de transição. Conforme exposto na figura 5,
19
projetos deste tipo iniciam com a decisão de investimento do cliente e a busca de
oportunidades pelo provedores. A fase seguinte é de preparação, onde o cliente
elabora uma RFI (Request for Information ou Solicitação de Informações) e na
sequência uma RFP (Request for Proposals ou Solicitação de Proposta de
Fornecimento de Serviços). O fornecedor toma a decisão de participar ou não da
concorrência. Na terceira etapa, os fornecedores enviam propostas para o cliente
que seleciona quem prestará o serviço. O contrato é assinado e logo depois é
implementado por meio de um projeto de transição, onde são definidos os modelos
de operação, governança e níveis de serviços do contrato.
Figura 5 – Decisões Clientes x Provedores
Fonte: adaptado de Kujala et al. (2008, p. 35).
A absorção do serviço contratado exige um cuidadoso planejamento e envolve uma
equipe composta por recursos do cliente e do provedor (SAAD, 2006). É atribuição
do provedor liderar este processo, sendo responsável pela execução da maior parte
do trabalho resultante. O papel do cliente durante a transição dos serviços é o de
assegurar que todas as ações estão sendo tomadas e fornecer pleno suporte ao
provedor quando por este solicitado.
Em um relacionamento longo (acima de dois anos), o outsourcing de TI inicia-se no
projeto de implantação com a percepção do cliente de que os custos precisam ser
reduzidos por meio de contratação de um provedor de TI externo. Existem riscos
para futuras iniciativas de qualidade e inovações nesta fase inicial. Em uma segunda
fase, o cliente evolui em valores. Os objetivos de aumento de qualidade são
requisitados para que a TI possa estar mais orientada ao negócio. Em uma terceira
20
e última fase existe uma clara preocupação em adicionar valor ao negócio do cliente
através de inovações (WEEKS, 2007). Neste aspecto, o projeto de transição de
serviços deve ser conduzido da maneira mais eficaz possível, para que a operação
possa estar preparada para estas mudanças de valores ao longo do tempo.
Um exemplo de projeto de transição é quando um provedor conquista um contrato
de outsourcing de serviços de infraestrutura de TI, envolvendo service desk,
monitoramento de redes e suporte de campo (field support). Inicialmente é realizada
uma negociação contratual, incluindo um due diligence. Na sequência é montado um
plano de transição, incluindo absorção de recursos humanos, treinamentos, plano de
infraestrutura, modelo de operação e modelo de governança. Após a execução
desta etapa inicia-se a operação do serviço de TI com qualidade e economia, de
forma a ajudar em um negócio melhor para o cliente e também converter-se em uma
vantagem competitiva para o provedor, assunto que será apresentado no próximo
item.
2.1.3. Vantagem Competitiva na Indústria de TI
Segundo Luecke (2008) as empresas não devem entender as competências
essenciais simplesmente declarando o que elas fazem. As empresas de informática
não podem afirmar que a sua competência essencial é a produção de software. Em
vez disso, deve ser determinado aquilo em que a empresa é melhor do que a
concorrência e que traga valor para os seus clientes. Silva (2008) relata duas
abordagens mais utilizadas para o desenvolvimento da estratégia corporativa: as
Estratégias Competitivas de Porter (2004) e a RBV - Visão Baseada em Recursos
(Resource Based View – RBV). Segundo Porter (2004), a essência de uma
estratégia competitiva é relacionar uma companhia ao seu meio ambiente. Ele
definiu que o processo de formulação da estratégia empresarial inicia-se pela
análise do ambiente, por meio das cinco forças competitivas – competidores,
fornecedores, clientes, novos entrantes e produtos substitutos. Posteriormente à
análise do ambiente, o autor afirma que a empresa deve se posicionar no mercado
mediante a escolha de uma de três estratégias competitivas: diferenciação, liderança
no custo e enfoque. Fleury (2003) relata que a RBV considera que toda empresa
21
possui um portfolio de recursos: físicos, financeiros, intangíveis (marca, imagem),
organizacionais (cultura, sistemas, processos) e recursos humanos. É a partir desse
portfolio que a empresa pode criar vantagens competitivas.
Contrapondo os conceitos das cinco forças competitivas e da visão baseada em
recursos, Contador (2004) sugere o Modelo de Campos e Armas de Competição.
Campo de Competição é um atributo de interesse do comprador, como preço,
qualidade e prazo de entrega. Arma da competição é um meio utilizado pela
empresa para competir. Alvo é um objetivo que a arma procura aprimorar. O modelo
de campos e armas da competição é construído a partir das relações entre esses
três elementos. Para a empresa ser bem-sucedida, basta ter excelência apenas
naquelas poucas armas que lhe dão vantagem competitiva no campo escolhido para
competir. No modelo MOPP, o provedor de TI tem alvos na sua oferta e operações
de serviços de TI. Um deles é a qualidade no atendimento aos seus clientes. Para
tanto, precisa dispor de melhores práticas na qualidade do processo. Armas como
ITIL, ISO 20000 e CMMI podem ser utilizadas para atingir estes alvos.
Outra visão de vantagem competitiva é a RBV ou Visão Baseada em Recursos.
Conforme Barney (2004), a RBV oferece um conjunto de ferramentas, baseadas em
uma teoria que explica porque algumas empresas têm um desempenho superior a
outras. Segundo Hitt et al. (2007), dentro da empresa os recursos e suas
competências internas assumem um papel fundamental na estratégia. Para Slack
(2002), fazer melhor em manufatura para alcançar vantagem competitiva pode ser
traduzido em cinco aspectos: fazer certo, fazer rápido, fazer pontualmente, fazer
com flexibilidade e fazer barato. Conforme Kaplan & Norton (2004), o Balanced
Scorecard (BSC) é um Sistema de Mensuração de Desempenho Estratégico que
ajuda nesta discussão. Além dos indicadores financeiros, que resumem os
resultados das iniciativas já adotadas, o BSC acrescenta um equilíbrio a estes
indicadores de resultados os indicadores não-financeiros, sob três outras
perspectivas – clientes, processos internos, aprendizado e conhecimento. Em
Governança de TI, o BSC é traduzido em atividades de curto prazo por meio do
CobiT, um dos frameworks utilizados no modelo MOPP.
Um exemplo prático de estratégia competitiva em serviços de TI ocorre quando um
22
provedor explora suas competências essenciais para atender ou superar os padrões
da concorrência global em TI. Inicia-se combinando seus recursos tangíveis (ex.
computadores, software, redes, pessoas, processos, instalações, recursos
financeiros, patentes) e intangíveis (ex. conhecimento, marca, reputação, melhores
práticas, certificações e valores) para formar as sua capacitações (o que pode ser
executado com os recursos). Exemplos de capacitações formadas a partir destes
recursos abrangem desenvolvimento de software, monitoramento de redes,
consultoria de ERP, gestão jurídica, gestão de pessoas e gestão de facilities. As
competências essenciais são formadas por capacitações que servem de fonte de
vantagem competitiva para o provedor sobre seus rivais. Para descobrir suas
competências essenciais, o provedor pode utilizar quatro critérios para as
capacitações: a) é rara; b) é valiosa; c) é difícil de imitar; d) é insubstituível. Das seis
capacitações do exemplo citado, três podem ser classificadas como fontes de
vantagem competitiva sustentável (desenvolvimento de software, monitoramento de
redes e consultoria de ERP) e devem ser protegidas e valorizadas pelo provedor
(incluindo gestão diferenciada de todos os recursos que compõem estas
capacitações) e três são passiveis de outsourcing (gestão de pessoas, gestão
jurídica e gestão de facilities), por não fazerem parte da core competence.
Esta seção apresentou a formulação da estratégia empresarial, com a finalidade de
obter uma compreensão geral da gestão estratégica de oferta de outsourcing. Uma
visão de serviços de TI é apresentada a seguir.
2.1.4. Serviços de TI
Serviço é qualquer ato ou desempenho, essencialmente intangível, que uma parte
pode oferecer a outra e que não resulta na propriedade de nada. A execução de um
serviço pode estar ou não ligada a um produto concreto (KOTLER, 2000). Ainda
segundo Kotler (2000), os serviços apresentam quatro características principais:
− Intangibilidade: ao contrário dos produtos físicos, não podem ser vistos,
sentidos, ouvidos, cheirados ou provados antes de serem adquiridos;
− Inseparabilidade: os serviços são produzidos e consumidos simultaneamente;
23
− Variabilidade: pelo fato de dependerem de quem os fornece, além de onde e
quando são fornecidos, os serviços são altamente variáveis;
− Perecibilidade: serviços não podem ser estocados.
O valor entregue ao cliente é a diferença entre o valor total percebido e o custo total
do serviço. O valor total é o conjunto de benefícios que os clientes esperam de um
determinado produto ou serviço. O custo total é o conjunto de custos em que os
consumidores esperam incorrer para avaliar, obter, utilizar e descartar um produto
ou serviço. O ITIL SS (2007) relata que os serviços de TI apresentam duas visões:
a) a visão da utilidade (utility), ou seja, o que o cliente obtém. A medição é baseada
na quantidade de resultados chaves suportados e nas quantidades de restrições
removidas para a oferta e operação dos serviços; b) visão da garantia do serviço
(warranty), ou seja, como é entregue. A medição é baseada nos níveis de
disponibilidade, capacidade, continuidade e segurança da informação. Um exemplo
de serviço de TI é uma manutenção corretiva de software, um monitoramento de
redes ou um suporte de microinformática. Devem ser úteis para o cliente e também
apresentar uma garantia no seu uso diário.
Os serviços de TI são ofertados e demandados pelo mercado. Neste contexto, a
negociação pela melhor oferta e operação é uma constante no relacionamento
comercial entre os provedores de serviços de TI e os clientes, como será
apresentado no próximo tópico.
2.1.5. Estratégia Comercial na Indústria de TI
Pereira (2004) relata que uma estratégia bem realizada na oferta e operação dos
serviços de TI é importante na negociação comercial. Trata-se da habilidade de
fazer com que acreditem na capacidade do provedor de demonstrar, realizar e
cumprir promessas. Vender software e serviços de TI exige habilidade. Vendedores
com argumentos fracos, incorretos ou incompletos, tentando vender algo de que não
tem completo domínio possui maior dificuldade de obter a confiança do cliente.
Para conhecer mais sobre os concorrentes, Pereira (2004) recomenda
relacionamentos com o cliente e os fornecedores deles. Uma indicação para isto é
24
utilizar o QFD (Quality Function Deployment). Junior et al. (2003) define o QFD,
também conhecido como Casa da Qualidade, como um refinamento sucessivo dos
requisitos do cliente por meio de uma série de processamentos (desdobramentos),
de tal maneira que os produtos ou serviços finais traduzam os atributos
estabelecidos pelos próprios clientes. Já para Carvalho (1997), o QFD também pode
ser utilizado para análise competitiva externa, sob a ótica do cliente. Abrange três
aspectos para cada requisito do cliente: (a) a avaliação comparativa dos principais
produtos concorrentes existentes no mercado; (b) os pontos de venda; e (c) a meta
e taxa de melhoria. A avaliação comparativa do produto estudado com seus
principais concorrentes é feita quanto ao grau de satisfação a um determinado
requisito.
Nalebuff e Brandeburg (1996) relatam que em uma negociação existe a necessidade
de conceder o mesmo preço para cada cliente. Outra alternativa é incluir uma opção
de reter o negócio do cliente desde que iguale qualquer lance da concorrência.
Segundo Guena (2005), assimetria de informações ocorre quando um participante
de um contrato detém informações relevantes que não são do conhecimento de
todos os outros participantes. A assimetria de informação pode causar gastos com a
busca de informação privilegiada para melhoria de posição estratégica, negócios
não realizados e uso oportunista de informações. Uma estratégia comercial
pressupõe o estabelecimento de um processo de vendas consistente, abrangente e
automatizado. Do ponto de vista do provedor, envolve as etapas de inteligência de
mercado, participação em concorrências, qualificação das propostas (avaliação da
eventual participação), negociação e contratação.
Exemplo de estratégia comercial do provedor inclui a elaboração de um processo de
vendas, automatizado por meio de um sistema de gestão de relacionamento com o
cliente (CRM – Customer Relationship Management) e a estruturação de uma
equipe de venda e de pré-venda, incluindo executivos comerciais para o
relacionamento com o mercado e analistas de processos para montagem e análise
de propostas técnicas e comerciais. O CRM é aplicado em toda a etapa de
contratação do ciclo de vida do modelo MOPP, incluindo inteligência, prospecção e
qualificação do mercado.
25
2.1.6. Qualidade em Serviços e Produtos de TI
Segundo Christensen et al. (2007), O conceito de qualidade foi primeiramente
associado à definição de conformidade às especificações. Posteriormente o conceito
evoluiu para a visão de satisfação do cliente. Por sua vez, a gestão da qualidade
representa a busca da satisfação, não só do cliente, como também de todos os
stakeholders (entidades significativas na existência da empresa a exemplo de
clientes, fornecedores, funcionários, governo e sociedade) e também da excelência
organizacional da empresa.
A melhoria contínua busca evoluir constantemente os processos de trabalho, tendo
como retorno a economia de tempo, gastos, re-trabalho, ou seja, a busca de eficácia
dos trabalhos. A melhoria contínua é baseada no sistema japonês Kaizen, que
traduzido para o português significa KAI – “mudança” e ZEN – “bom”, ou seja, a
mudança para melhor. Segundo Christensen et al. (2007) a melhoria pode ser
incremental ou radical (breakthrough). Na melhoria incremental os processos são
melhorados por etapa. Métodos como Kaizen e PDCA (Plan, Do, Check, Act) são
utilizados neste etapa.
Na melhoria radical o objetivo é dar um salto acentuado para um novo patamar.
Inovações de impacto assim como implantação de metodologias como o Lean Six
Sigma fazem parte desta fase, conforme mostra a figura 6.
Figura 6 – Melhoria Incremental x Melhoria Radical fonte: ASQ (2007, p.1)
26
Segundo Parasuraman et al. (1985), a qualidade do serviço percebida pelo
consumidor é formada pela comparação entre as expectativas do serviço e o
resultado percebido do serviço fornecido. Os mesmos pesquisadores identificaram
cinco fatores determinantes da qualidade dos serviços.
− Confiabilidade: a habilidade de desempenhar o serviço exatamente como
prometido;
− Capacidade de resposta: a disposição de ajudar os clientes e de fornecer o
serviço dentro do prazo estipulado;
− Segurança: o conhecimento e a cortesia dos funcionários e sua habilidade de
transmitir confiança e segurança;
− Empatia: a atenção individualizada dispensada aos clientes;
− Itens tangíveis: a aparência das instalações físicas, dos equipamentos, dos
funcionários e do material de comunicação.
Os aspectos citados acima podem ser tratados dentro de modelos e metodologia de
TI para melhoria da ergonomia, satisfação dos profissionais, reconhecimento e
recompensa, trabalho em equipe, produtividade e premiações por clientes
satisfeitos. O objetivo é aumentar a qualidade percebida pelo cliente. Esta qualidade,
segundo Silva et al (2006), é formada pela comparação entre as expectativas do
serviço e o resultado percebido do serviço fornecido.
Uma ferramenta que pode ser utilizada para apurar a percepção e aumentar a
qualidade dos serviços é o QFD (Quality Function Deployment). Conforme O CQPA
Handbook (Certified Quality Process Analyst da ASQ – American Society for
Quality), o QFD foi inicialmente desenvolvido no estaleiro da Mitsubishi Heavy
Industries Ltd. para estruturar um processo que permitisse vincular cada etapa da
construção de navios ao atendimento e à satisfação de determinados requisitos do
cliente (CHRISTENSEN et al., 2007). Junior et al. (2003) definem o QFD, também
conhecido como Casa da Qualidade, como um refinamento sucessivo dos requisitos
do cliente por meio de uma série de processamentos (desdobramentos), de tal
maneira que os produtos finais traduzam os atributos estabelecidos pelos próprios
clientes. O QFD se processa, em geral, em quatro etapas: planejamento do produto,
27
desenvolvimento de componentes, planejamento do processo e planejamento da
produção. A ênfase neste trabalho está no questionário para análise da concorrência
quanto aos serviços escopo de uma RFP (Request for Proposals), ou proposta de
fornecimento de produtos ou serviços. A avaliação comparativa do produto estudado
com seus principais concorrentes é feita quanto ao grau de satisfação a um
determinado requisito do cliente (CARVALHO, 1997).
Uma aplicação prática da gestão da qualidade na oferta e operação de serviços de
TI inclui a adoção de certificações e práticas a exemplo do Lean Six Sigma, ITIL,
ISO 9001, ISO 20000, ISO 14001 e Qualidade Total. Também abrange a montagem
de Grupos de Melhorias de Qualidade em Serviços de TI, Auditoria Interna,
Treinamentos em Qualidade, Portal de Gestão da Qualidade, Sistemas de Registros,
Acompanhamento de Ocorrências (Não Conformidades e Oportunidades de
Melhorias), Registros, Análise de Desvios, Erros Embarcados e Defeitos de Quality
Assurance.
2.1.7. Governança de TI
A Governança de TI é uma parte integral da Governança Corporativa. Consiste em
liderança, estrutura organizacional e processos que garantem que a TI Corporativa
sustente e estenda os objetivos e estratégias corporativas. Conforme o ITGI (2008),
esta área de conhecimento consiste em cinco princípios: Alinhamento Estratégico,
Entrega de Valor, Gerenciamento de Riscos, Gerenciamento de Recursos e Medição
de Desempenho. Uma das metas da Governança de TI é se alinhar com os objetivos
de negócio definidos pela estratégia corporativa. Estas metas organizacionais de
alto nível e objetivos são usadas como entradas para gerar as metas específicas,
métricas de objetivos e desempenho necessários para gerenciar a TI eficientemente.
Ao mesmo tempo, os processos de auditoria são implementados para medir e
analisar o desempenho da organização. A Gestão de Serviços de TI concentra-se
em fornecer os serviços de forma eficiente e eficaz; já a Governança de TI
preocupa-se no desempenho do serviço, transformando-o e posicionando-o para
alcançar os requisitos de negócio, conforme figura 7.
28
Stachtchenco (2009) relata que a governança deve ser observada em termos de
transparência, criação de valor, otimização de recursos e gerenciamento de riscos e
não apenas em termos de compliance (atendimento a alguma norma ou termo
regulatório).
Figura 7 – Governança x Gestão de Serviços de TI
Fonte: CobiT v4.1 (2006, p.25)
Conforme Grembergen e Haes (2009), a Governança Corporativa de TI está
substituindo a Governança de TI. Isto significa que as informações, dados, sistemas
e demais recursos não pertencem somente a área de TI, como também a toda a
corporação. O termo TI tem levado a debates da integração da área de TI com o
negócio, quando o correto seria pensar na integração da TI corporativa, ou seja, de
toda a organização. Uma aplicação de Governança em provedores de serviços de TI
pode contemplar, por exemplo, a certificação SAS 70 que abrange as melhores
práticas de governança corporativa, segurança da informação e controles internos
de TI.
2.1.8. Gestão do Conhecimento e da Inovação em Serviços de TI
Segundo Mergel et al. (2007), conhecimento implica em capacidades emocionais e
cognitivas assim como habilidades relacionadas ao aspecto físico, que permitem
tomar ações. Pode ser entendido como saber como e por quê. Para os autores, a
Gestão do Conhecimento, por sua vez, aplica as melhores práticas de gestão para o
29
conhecimento dos recursos da organização. Takeuchi e Nonaka (2008) definem
conhecimento explícito como o conhecimento cuja transmissão se dá através da
linguagem formal e de forma sistemática. Pode ser armazenado e compartilhado,
logo, mais fácil de gerenciar, podendo ser armazenado em normas, manuais e livros.
O conhecimento não-explícito é igual ao conhecimento tácito. O conhecimento tácito
é o conhecimento que a pessoa possui, incluindo suas habilidades. É pessoal, não
pode ser expressado formalmente. É intrínseco à pessoa.
Takeuchi e Nonaka (2008) destacam também que uma organização cria e utiliza
conhecimento convertendo o conhecimento tácito em conhecimento explícito, e vice-
versa. Para tornar possível a utilização dos conhecimentos da empresa é necessária
a localização de suas fontes. Isto é feito através do mapeamento. Somente por meio
dele é possível identificar os especialistas, pessoas com conhecimento de
determinados assuntos, e localizar o acervo intelectual da empresa. Santiago Jr.
(2004) relata que o efetivo valor do conhecimento tem se tornado um fator de
sobrevivência das grandes corporações. Existem dois tipos de conhecimento:
− Explícito: o conhecimento que é o objetivo e facilmente captado, codificado e
compartilhado. Este é um conhecimento transmissível em linguagem formal e
sistemática;
− Tácito: o conhecimento que reside essencialmente na mente das pessoas. Difícil
de ser formulado e comunicado.
Schumpeter (1982) definiu a inovação como a obtenção de diferenciais competitivos
pela modificação de produtos ou meios de produção. Ele classificou a inovação em
três estágios: invenção, inovação e difusão. Enquanto a invenção é entendida como
uma idéia potencialmente aberta para a exploração comercial, mas não
necessariamente realizada, na idéia de inovação está implícita uma ênfase na
exploração comercial. Por fim, a difusão está relacionada com a propagação de
novos produtos e processos pelos mercados potenciais (SCHUMPETER, 1982).
Outra visão do processo de inovação é visto em Tidd et al. (2008), que é a busca,
seleção e implementação, com aprendizado contínuo ao longo da vida útil do
processo de inovação. Embora muitos abordem a inovação como um processo, em
geral o que se observa são os resultados (produtos ou serviços) mais estudados do
30
que os elementos orgânicos que fazem da inovação um modelo repetível e
sustentável (SYLVER, 2008).
Um conceito mais recente na área é a Open Innovation ou Inovação Aberta.
Conforme Chesbrough (2005), este conceito trata a inovação como um sistema
aberto onde tanto idéias externas e internas são debatidas e as melhores
alternativas são selecionadas. Um dos benefícios desse modelo é que as empresas
conseguem dividir os riscos e custos do processo de inovação. Exemplos de
conhecimento e inovação na oferta e operação de serviços de TI em provedores
incluem a estruturação de portais de recepção de idéias e propostas, tanto internas
como externas (inovação aberta), comitês de conhecimento, portais de lições
aprendidas, base de conhecimento, área responsável pela análise de viabilidade,
incentivos, definição de processos, coaching e acompanhamento dos projetos de
inovação.
As estratégias de outsourcing de TI contribuíram para o surgimento de frameworks
de melhores práticas na oferta e operação de serviços de TI, conforme mostrado no
próximo tópico.
31
2.2. Frameworks de Oferta de Operação de Serviços de TI
Atualmente existem vários modelos em gestão da oferta e operação de serviços de
TI, mostrados no quadro 2. Parte deles são direcionados a produtos de software
como o CMMI (Maturidade do Processo de Software), ISO 9126 (Qualidade do
Produto de Software) e a ISO/IEC 15504 (Maturidade do Processo de Software).
Outros são voltados à gestão de serviços de TI, governança e compliance como o
ITIL (Melhores Práticas de Gestão de Serviços de TI), ISO/IEC 20000 (Norma para
Gestão de Serviços de TI), ISO/IEC 27001 (Norma de Gestão da Segurança da
Informação), CobiT (Governança, Controles e Auditoria de TI) eSCM/SP (Melhores
Práticas de Outsourcing de TI). O investimento em certificações permite às
empresas conquistar clientes no exterior e, consequentemente, elevar suas receitas.
A tendência atual é de crescimento de pesquisas relacionadas com a área.
Quadro 2 – Frameworks do mercado vinculados a Outsourcing
Modelo Entidade Definição
CMMI v1.2 for Services Carnegie-Mellon Modelo de Maturidade em serviços de software.
Cobit v4.1 e ISO 38500 ITGI/ISACA e ISO Frameworks de Governança, Controle e
Auditoria de TI
Val IT ITGI/ISACA Modelo de Governança de Investimentos em TI
COSO e SAS70 COSO e AICPA Frameworks de Governança Corporativa
eSCM-SP Carnegie-Mellon Framework de Gerenciamento de Outsourcing
de TI
ITIL v3 OGC/itSMF Gestão de Serviços de TI
PMI/PmBok e IPMA PMI e IPMA Metodologias de Gerenciamento de Projetos
OPM3 PMI Metodologia de Maturidade de Projetos, Portfólio
e Programas
ISO 20000 ISO Norma ISO para Gestão de Serviços de TI com
certificação das empresas.
Lean Six Sigma Toyota, Motorola,
ASQ
Metodologia combinando velocidade e
eliminação de desperdícios (lean) com a
qualidade do processo (six sigma).
ISO 27001 ISO Norma voltada à segurança da informação
ISO 27005 ISO Norma concentrada em riscos de segurança
COPC COPC Modelo com melhores práticas de call center
32
Segundo o Gartner (instituto de pesquisa americano de tecnologia da informação,
reconhecido internacionalmente), uma certificação como a ISO 20000 combinada
com a SAS 70 garante uma gestão eficiente dos serviços de TI da área escopo, bem
como controles adequados. Em 2006, este instituto de pesquisa previu que em 2010
cerca de 45% das empresas americanas iriam exigir nas suas RFP´s de TI (Request
for Proposals ou Propostas de Fornecimento) algum tipo de certificação (GARTNER,
2006; SANTOS, 2006). A figura 8 mostra os principais relacionamento entre os
frameworks mais conhecidos no mercado. O BSC, COSO e as normas regulatórias
(ex.: SOX, Basel II) fornecem diretrizes corporativas que são traduzidas pelo CobiT e
repassadas sob a forma de governança de TI, controles e auditorias para os demais
frameworks. O e-SCM/SP fornece diretrizes de outsourcing e a ISO 9001 o sistema
de gestão da qualidade.
Figura 8 – Relacionamento entre os frameworks
O PCMM auxilia o CMMI nos requisitos relacionados com a gestão de pessoas. O
CMMI, por sua vez recebe diretrizes de melhores práticas em gestão de projetos do
PMBoK, de gestão quantitativa do Lean Six Sigma, gestão de aplicações
33
(sustentação) do ITIL e de riscos da ISO 27005. A ISO 20000 fornece requisitos
auditáveis para o ITIL e recebe as melhores práticas de gestão de segurança da
informação da ISO 27001. A ISO 27001 está vinculada a ISO 27005 por meio de
práticas de riscos de segurança. A ISO 38500, por sua vez, fornece requisitos de
governança de TI para os padrões ISO.
Além de investimentos nesses frameworks individuais, as empresas estão buscando
cada vez mais melhorar seus processos de gestão de serviços e a qualidade de TI.
Dessa forma, os investimentos em modelos internos também estão nas suas
estratégias. Modelos desenvolvidos internamente, a exemplo de MGP - Metodologia
de Gerenciamento de Projetos ou MGO – Metodologia de Gerenciamento de
Outsourcing, fazem parte dessas prioridades, porém ainda não existem de forma
totalmente integradas, por incorporarem diretrizes de frameworks de forma
individualizada e não o que existe de melhor em cada um deles.
2.2.1. CMMI v 1.2 for Services
O CMMI 1.2 Dev é a versão de maturidade de processo de software mais conhecida
atualmente. Foi criada pelo SEI (Software Engineering Institute) e concentra-se na
melhoria dos processos de desenvolvimento de software. O CMMI 1.2 for Services
vai além e preocupa-se com o software em operação, acrescentado a visão de
serviços. O CMMI organiza as práticas, que já são consideradas efetivas, em uma
estrutura que visa auxiliar a organização a estabelecer prioridades para melhoria e
também fornece um guia para a implementação dessas melhorias (SEI, 2009). O
CMMI - Capability Maturity Model Integration foi criado como uma integração e
evolução dos modelos SW-CMM - Capability Maturity Model for Software; SECM -
EIA 731 - System Engineering Capability Model e IPD-CMM - Integrated Product
Development CMM. O CMMI é um modelo alinhado com a Norma ISO/IEC 15504 e
é apresentado em duas representações: uma por estágio e outra contínua (SEI,
2009). O CMMI, na sua versão de maturidade por estágio, está dividido em cinco
níveis, conforme abaixo:
1. Inicial – Processo imprevisível e reativo;
2. Gerenciado – Processo caracterizado por projetos e ainda reativo;
34
3. Definido – processo caracterizado para a organização e pró-ativo;
4. Gerenciado Quantitativamente – processo medido e controlado;
5. Otimizado – Objetiva a melhoria contínua do processo;
Conforme o SEI (2009), o objetivo do CMMI for Service 1.2 é complementar os
outros dois modelos do CMMI: Development e Acquisition. O framework agregou
práticas do ITIL v3 e da ISO 20000 dentro de seu modelo, substituindo a etapa de
engenharia, mantendo apenas a Gestão de Requisitos (REQM). Apesar de não ser
tão prescritivo quanto o ITIL v3, este framework traz as vantagens de utilização dos
processos de desenvolvimento de software (ex.: requisitos, treinamentos, controle e
monitoramento quantitativo), bem como aspectos vitais para qualquer oferta e
operação de serviços de TI (sustentação de software, fábrica de manutenção,
suporte de sistemas e outros). Alguns processos relacionados a serviços de TI são
incorporados neste modelo: Estratégia, Capacidade, Transição, Entrega e
Continuidade do Serviço. O CMMI-SVC, como também é conhecido, faz referência a
serviços de sistemas e não apenas de aplicações. Entendendo sistemas de uma
forma mais ampla, abrangendo itens de infraestrutura, instalações, aplicações,
hardware, redes e pessoas, necessários para a prestação do serviço. O CMMI pode
ser utilizado em provedores de serviços de TI, fábricas de software e também em
serviços de manutenção para os seus clientes.
2.2.2. PCMM (People Capability Maturity Model).
O PCMM foi desenvolvido pelo Instituto de Engenharia de Software (SEI) da
Universidade Carnegie Mellon, com o objetivo de medir a capacitação das empresas
na gestão de pessoas na produção de software. Possui cinco níveis: Inicial,
Gerenciado, Definido, Gerenciado Quantitativamente, Em Otimização (SEI, 2009).
Em 1995 foi lançada a primeira versão do PCMM pelo SEI. Uma nova versão,
apresentada em julho de 2001, foi aprimorada com o aprendizado adquirido por
meio de implementações realizadas com a versão 1.0, bem como ajustada para
facilitar a integração junto ao Capability Maturity Model Integration – CMMI. Como
exemplo, o PCMM pode ser aplicado em uma fábrica de software do provedor de TI.
Utiliza-se intensamente plano de carreira, plano de treinamento, mapeamento de
35
competências, reconhecimento e recompensa. A aplicação da satisfação interna dos
colaboradores também faz parte do PCMM dentro de uma fábrica de software.
O PCMM complementa outros frameworks a exemplo do CMMI e PMBoK, por conter
uma forte concentração em gestão de pessoas no desenvolvimento de software. O
objetivo é a satisfação dos profissionais de TI, antes da satisfação dos clientes.
2.2.3. ITIL v3
Framework de Gestão de Serviços de TI, desenvolvido pela OGC (Office of
Government Commerce) do Governo Inglês, com a contribuição de empresas de
mercado no final da década de 80. O ITIL se consolidou no mercado como a melhor
prática para Gerenciamento de Serviços de TI. Na versão 3, existe o conceito de
ciclo de vida do serviço, composto por cinco livros:
− Estratégia de Serviços (Service Strategy- SS);
− Projeto do Serviço (Service Design - SD);
− Transição do Serviço (Service Transition - ST);
− Operação do Serviço (Service Operation - SO);
− Melhoria Contínua dos Serviços (Continual Service Improvement – CSI).
Conforme o ITIL SS (2007), o provedor de serviços de TI inicia a Estratégia de oferta
do serviço gerenciando os requisitos de negócios (Gestão de Demandas), e
traduzindo isto em uma estratégia para entregar o serviço (Estratégia do Serviço),
validando os custos para manter estes serviços (Gestão Financeira) e introduzindo o
serviço dentro do portfolio de serviços (Gestão de Portfolio de Serviços). Neste
momento ainda não existe valor para o negócio. Conforme o ITIL SD (2007), quando
a estratégia está completa, inicia-se a segunda fase que é o projeto do serviço (fase
de Design do Serviço), por meio de atribuição de requisitos de níveis de serviços
(Gestão de Níveis de Serviços), analisando a disponibilidade e capacidade
requisitada (Gestão de Capacidade e Disponibilidade), selecionando os
fornecedores que realizarão o suporte dos serviços (Gestão de Fornecedores),
definindo a adequada provisão de continuidade de serviços (Gestão de Continuidade
dos Serviços), validando e projetando os requisitos de segurança (Gerenciamento
36
de Segurança) e introduzindo o serviço dentro do Catálogo de Serviços (Gestão de
Catálogo de Serviços).
O ITIL ST (2007) relata que na terceira fase (Transição dos Serviços) o serviço está
pronto para ser implementado no ambiente de produção. O provedor de serviços
define o plano de transição (Planejamento de Transição e Suporte) e avalia, aprova,
implementa e planeja a mudança (Processo de Gestão de Mudanças). Após a
implementação da mudança, o serviço é testado (Validação e Teste de Serviço) em
um ambiente de homologação. Se o teste for bem sucedido, o serviço é
documentado (Gestão de Conhecimento) e seus componentes são incluídos no
banco de dados de ativos e configurações (Gestão de Ativos e Configuração). A
última atividade é realizar a liberação no ambiente de produção (Gestão de
Liberação e Instalação) e, após o go-live (entrada em operação), uma revisão pós-
implementação deverá ser executada (Gestão da Avaliação).
Conforme o ITIL SO (2007), na quarta fase (Operação do Serviço), o serviço começa
a ser gerenciado e suportado para que alcance o nível de serviço acordado por meio
do gerenciamento dos chamados dos usuários (Service Desk e Gestão de
Solicitações), monitorando os alertas e eventos do serviço (Gestão de Eventos),
restaurando as interrupções não programadas dos serviços (Gestão de Incidentes),
evitando as causas dos incidentes e reduzindo a duração de incidentes (Gestão de
Problemas), gerenciando a maneira segura de utilização do serviço (Gestão de
Acesso), mantendo o produto de software (Função de Gestão de Aplicação),
executando as atividades diárias (Gestão de Operação) e suportando a infra-
estrutura (Gestão Técnica).
Conforme o ITIL SI (2007), a fase de Melhoria Contínua do Serviço é acionada
durante todas as fases do ciclo de vida. É responsável por medir o serviços e os
processos (Medição dos Serviços), e documentar os resultados (Report do Serviço)
para que seja melhorada a qualidade do serviço e a maturidade dos processos
(Melhoria do Serviço). Estas melhorias devem ser implementadas na próxima fase
do ciclo de vida do serviço, iniciando-se novamente na Estratégia do Serviço. Dessa
forma, o ciclo recomeça.
37
2.2.4. ISO/IEC 20000
Também concentrada em Serviços de TI, a norma ISO 20000 foi publicada em 2005
pela ISO (International Organization for Standardization) e IEC (International
Electrotechnical Commission). Trata-se de um padrão para certificação das
empresas em gestão de serviços de TI. A versão brasileira (NBR ISO/IEC 20000) foi
publicada em novembro/2008. A norma é baseada no ITIL, IT Infrastructure Library,
conjunto de melhores práticas para Serviços de TI e sucedeu a norma BS 15000. A
ISO/IEC 20000 possui duas partes: ISO 20000-1, que trata da especificação para a
gerência de serviços de TI e a ISO/IEC 20000-2 que trata do código de prática para
a gerência dos serviços de TI. A certificação é baseada nos requisitos da parte 1 da
norma (ISO 20000, 2005).
A norma divide-se em quatro macro-áreas: a) Sistema de Gestão; b) Planejamento e
Implementação de Gerenciamento de Serviços (PDCA); c) Planejamento e
Implementação de Serviços Novos ou Modificados; b) Processos de Gerenciamento
de Serviços. O Sistema de Gestão está alinhado com a ISO 9001:2008 e é formado
pelos processos de Responsabilidade da Direção, Competências, Conscientização e
Treinamento e Requisitos de Documentação. O PDCA contempla os requisitos do
planejamento, execução, avaliação e melhoria do serviço. O planejamento e
implementação de serviços novos ou modificados está relacionado à gestão de
projetos. Os requisitos dos processos estão classificados em quatro macro-
processos: Entrega, Resolução, Controle, Liberação e Relacionamento e envolvem
Gestão de Incidentes, Gestão de Capacidade, Gestão de Mudanças e outros. Existe
um relacionamento entre o ITIL e a ISO/IEC 20000. O ITIL fornece as melhores
práticas de serviços de TI, enquanto a ISO 20000 determina os requisitos mínimos
para a gestão dos serviços
2.2.5. ISO/IEC 27001
A ISO 27001 é uma norma internacional para referência da implantação de
processos de gestão de segurança da informação, publicada pelo ISO - International
Organization for Standardization em outubro de 2005.
Esta norma veio tornar padrão internacional o que havia sido desenvolvido e
38
publicado pela entidade normativa inglesa BSI (British Standard Institution), com a
designação de BS7799-2. A norma ISO/IEC 27001 (Information Technology -
Information Security Management Systems - Requirements) trata da implantação de
um processo de gestão de segurança da informação (ISMS - Information Security
Management Systems). Esta norma, em conjunto com a ISO/IEC 27002 (Código de
Melhores Práticas da Gestão de Segurança da Informação), é a principal referência
para quem procura gerenciar a segurança da informação de maneira eficiente e com
eficácia (ISO 27001, 2007).
As melhores práticas de segurança da informação incorporadas na ISO 27001
aplicam-se em qualquer área dentro do provedor de serviços de TI. Um exemplo
prático é a elaboração da política de segurança da informação, BIA (Análise de
Impacto no Negócio), normas específicas para cada unidade de negócio (ex.
aplicações, infraestrutura, consultoria) e também regras específicas para segurança
em aplicações. Neste aspecto, a ISO 27001 pode ser complementada por outros
frameworks específicos de segurança de aplicações como o OWASP (Open Web
Application Security Project), WASC (Web Application Security Consortium) e pela
ISO 27034.
2.2.6. CobiT v4.1
Conforme o CobiT v4.1 (2006), o CobiT (Control Objectives for Information and
related Technology) é um guia para a governança de TI mantido pelo ISACA
(Information Systems Audit and Control Foundation). O CobiT inclui recursos tais
como um sumário executivo, um framework, controle de objetivos, mapas de
auditoria, um conjunto de ferramentas de implementação e um guia com técnicas de
gerenciamento. As práticas de gestão do CobiT são recomendadas para governança
e controle de TI. É formado por um conjunto de 318 controles, distribuídos em 34
processos. O CobiT determina o que deve ser controlado, sob a visão de
governança de TI e não como os processos devem ser estruturados. Conforme
mostrado na figura 9, este framework possui três visões: critérios de informação,
processos de TI e recursos de TI.
39
O CobiT está dividido em quatro domínios:
− Planejamento e organização;
− Aquisição e implementação;
− Entrega e suporte;
− Monitoração.
Exemplos de aplicação do CobiT na oferta e operação de serviços de TI abrangem
elaboração do modelo de governança em projetos de transição, auxílio nos
processos da certificação SAS 70 e auditoria dos serviços ofertados.
2.2.7. Val IT
Desenvolvido pelo ITGI (IT Governance Institute) o Val IT foi criado com o objetivo
específico de criar uma estrutura de suporte para auxiliar os gestores a avaliar,
selecionar, gerir e mensurar o retorno de seus investimentos em TI. Conforme
Harries e Harrison (2008), O Val IT envolve três domínios:
− Value Governance (VG) – Governança do Valor: Garante que as práticas da
gestão de valor estão internalizadas na organização;
Figura 9 – CobiT v4.1 Fonte: Traduzido CobiT (2006, p. 25)
40
− Portfolio Management (PM) – Gestão de Portfolio: Garante que a empresa
otimiza os valores por meio do seu portfolio de investimentos envolvendo TI;
− Investment Management (IM) – Gestão de Investimentos: Garante que
investimentos individuais da empresa contribuam com o valor esperado.
Para o Val IT, o investimento em TI é para beneficiar parte da empresa ou mesmo a
empresa toda e não é um custo direto somente de TI. Este framework ajuda neste
entendimento, demonstrando o valor de TI ao negócio. Trabalha como um
complemento do Cobit (VAL IT, 2006).
Exemplos de utilização do Val IT em serviços de TI incluem o modelo de governança
em projetos de transição e operação de serviços de TI e também na governança de
investimentos do próprio provedor de serviços.
2.2.8. e-SCM/SP
O eSCM (eSourcing Capability Model) é um guia de melhores práticas para gestão
de outsourcing, desenvolvido por um consórcio liderado pelo Information Technology
Services Qualification Center (ITsqc) da Carnegie Mellon University (CMU). Contou
com a participação de empresas como: Accenture, EDS, IBM Global Services e
Satyam Computer Services. Na sua versão eSCM/SP (eSourcing Capability Model
for Service Providers ) é utilizada para a melhoria da capacidade dos provedores de
serviço no processo de oferta de outsourcing. Uma visão geral do modelo é
mostrada na figura 9.
O eSCM inclui cinco niveis de capacidade (Capability Levels) que determinam o
caminho da melhoria para provedores de serviços. O eSCM/SP aborda um ciclo de
vida de outsourcing de forma genérica, sem entrar no detalhe de cada processo:
− Nível 1 – Provendo serviços;
− Nível 2 – Atendendo aos requisitos consistentemente;
− Nível 3 – Gerenciando o desempenho organizacional;
− Nível 4 – Agregando valor pró-ativamente;
− Nível 5 – Mantendo a excelência.
41
A cada etapa do ciclo de vida são vinculados os processos. O ciclo abrange as
etapas de contratação, projeto, execução e transferência dos serviços e é apoiado
por processos de gestão do conhecimento, pessoas, desempenho, relacionamento,
tecnologia e ameaças (eSCM, 2004). Para alcançar ao nível 5 de maturidade, um
fornecedor de serviço deve demonstrar excelência e a melhoria do desempenho
eficazmente, conseguindo manter-se no nível 4 pelo período mínimo de dois anos.
Monteiro (2004) relata que o ITsqc lançou em novembro de 2001 a versão 1.0 do
eSCM-SP contendo 100 práticas. Em outubro de 2002 a versão 1.1 do eSCM-SP foi
lançada contendo 94 práticas e mais recentemente, em abril de 2004, foi lançada a
atual versão do modelo, 2.0, compreendendo um total de 84 práticas. O ciclo de vida
de fornecimento abrange as etapas de iniciação, execução, encerramento e
contínua. A cada etapa, são vinculados processos próprios do modelo, no formato
descritivo. Exemplos de utilização do eSCM/SP em provedores de serviços de TI
contemplam a elaboração de uma metodologia de alto nível (determinando o que
deve ser feito) de gerenciamento de outsourcing, que pode servir de diretriz para a
oferta, operação e encerramento dos serviços.
2.2.9. SAS 70
Conforme Santos (2006), a SAS 70 (Statement on Auditing Standards No 70) foi
desenvolvida em 1993 pelo American Institute of Certified Public Accountants
(AICPA) ou Instituto Americano dos Contadores Públicos Certificados. Permite que
uma organização de auditoria avalie e expresse uma opinião sobre os controles
internos de um provedor de serviços. Também fornece um relatório de auditoria que
um cliente pode usar ao avaliar um provedor. A SAS 70 é uma certificação que
permite às organizações de auditoria (ex. PwC, KPMG) alocar auditores para
examinar as atividades e processos de controle de provedores, assim como a
efetividade destes controles para seus clientes em dois tipos de relatórios: tipo I e
tipo II. O primeiro tipo descreve os controles e procedimentos colocados em
operação pelo provedor de serviços em uma determinada data; já o segundo tipo
atende aos objetivos do primeiro tipo e contempla os testes de efetividade dos
controles.
42
Uma auditoria do SAS 70 pode ser realizada por um auditor independente ou
certified public accountant (CPA). Conforme o Gartner (2005), o SAS 70, quando
combinado com a ISO 20000, pode complementar uma a outra e não são
redundantes. A SAS 70 concentra-se em áreas como governança corporativa, riscos
e segurança. A base é o CobiT, COSO e a ISO 27002. Exemplos de SAS 70 em
provedores abrangem certificação de serviços de TI demandados por clientes que
estão sujeitos a SOX (Lei Sarbanes-Oxley).
2.2.10. COSO
Conforme Singleton et al. (2008), o COSO (Commitee of Sponsoring Organizations
of the Treadway Commision) indica as áreas de interesse que são relevantes para
auditoria de sistemas. Ele pode ser utilizado para mitigar os riscos e ajudar na
eficácia dos controles internos. O COSO é um processo. Este processo é constituído
de cinco elementos, que estão inter-relacionados entre si e estão presentes em todo
o ambiente da empresa. Os cinco elementos são: a) Ambiente de Controle, b)
Avaliação e Gerenciamento dos Riscos; c) Atividade de Controle; d) Informação e
Comunicação e e) Monitoramento. O COSO é utilizado neste trabalho no quesito
compliance interno dos provedores de TI. Este padrão está relacionado ao Cobit, no
que se refere a controle de TI e governança e também ao SAS 70 para compliance
com a governança corporativa, controles internos e segurança da informação.
O COSO pode ser utilizado na busca da SAS 70 pelos provedores e também na
determinação das diretrizes de governança corporativa. O framework também pode
ser utilizado em modelos de governança no projeto de transição e na operação dos
serviços de TI.
2.2.11. PMBoK – PMI
O Project Management Body of Knowledge (PMBOK Guide) é um guia de melhores
práticas em Gerenciamento de Projetos do PMI (Project Management Institute).
Conforme o PMBoK (2004: 1), o conjunto de conhecimentos do manual vem dos
praticantes e acadêmicos que utilizam e desenvolvem tanto as práticas amplamente
testadas e aprovadas quanto aquelas modernas e inovadoras, com aplicação mais
restrita. O PMBoK também estabelece uma linguagem comum para a profissão,
43
servindo de referência básica para Gerenciamento de Projetos. Periodicamente são
realizadas revisões e novas versões são desenvolvidas. A estrutura do PMBOK
contempla cinco grupos de processos: a) Iniciação; b) Planejamento; c) Execução;
d) Monitoramento e Controle e e) Encerramento e nove áreas de conhecimento
específicas, a saber: Gerenciamento da Integração do Projeto; Gerenciamento do
Escopo do Projeto; Gerenciamento do Prazo do Projeto; Gerenciamento do Custo do
Projeto; Gerenciamento da Qualidade do Projeto; Gerenciamento dos Recursos
Humanos do Projeto; Gerenciamento da Comunicação do Projeto; Gerenciamento
dos Riscos do Projeto; Gerenciamento das Aquisições do Projeto (PMBoK, 2004: 9).
Heldman (2005) relata que as áreas de conhecimento congregam os processos que
possuem características comuns e os grupos de processos apresentam a ordem em
que os processos devem ser executados. O PMBoK pode ser utilizado como guia
em projetos de transição de serviços de TI, projetos de demandas eventuais e
também em propostas de concorrências.
2.2.12. OPM 3 – PMI
O OPM3 é uma abreviatura do Organizational Project Management Maturity Model.
Usando o OPM3, as organizações podem avaliar seu nível da maturidade em
projetos. Este framework possui quatro níveis da maturidade (Padronização,
Mensuração, Controle e Melhoria Contínua), para seus três domínios: Projetos,
Programas e Portfolios. (OPM3, 2003:3).
O OPM3 foi desenvolvido pelo PMI (Project Management Institute) e tem como
objetivo padronizar modelos de maturidade para o mercado em gerenciamento de
projetos. A proposta do modelo é suportar as organizações a desenvolverem
capacidades para alinhar seus objetivos estratégicos a sua operação através de
projetos.
O ciclo OPM3 é formado pelas seguintes etapas:
− Conhecimento e preparação para avaliação;
− Avaliação da maturidade;
− Plano de melhoria;
44
− Implementar melhorias;
− Reavaliar e repetir o processo.
O OPM3 é útil como base na estruturação de PMO (Escritório de Projetos) em
provedores, auxiliando na determinação de padrões de gestão e maturidade de
portfolio de projetos.
2.2.13. IPMA – International Project Management Association
É uma prática européia de gerenciamento de projetos. Possui alguns processos
adicionais ao PMBoK como Gestão Ambiental e Gestão de Conhecimento.
Conforme a ABGP (2009), a estrutura internacional do padrão é apresentada no
documento IPMA International Competence Baseline (ICB), o qual descreve as
áreas de qualificação da competência em gerência de projetos, bem como a
taxonomia utilizada para a avaliação do conhecimento, experiência e atitude pessoal
dos profissionais de gerência de projetos. O ICB está disponível em inglês (adotado
como versão padrão pelo IPMA), alemão e francês. São usadas as seguintes
referências: a) Inglês: UK Body of Knowledge (APM), b) Alemão:
Beurteillungsstruktur (VZPM) e o German PM-Kanon (PM-Zert), e c) Francês:
Critères dAnalyse (AFITEP).
Cada Associação Nacional é responsável por estabelecer a sua própria definição de
competências (NCB), as quais devem ser conformes com o ICB e levarem em
consideração as especificidades culturais de cada país. A ABGP possui sua versão
do NCB Brasileiro intitulado Referencial Brasileiro de Competências (RBC) em
Gerenciamento de Projetos (http://www.abgp.org.br). Pela sua característica
principal em competências, o IPMA pode ser utilizado no acompanhamento de
competências do Gerente de Projetos e de toda a equipe. Também pode ser
complementar ao PMBoK para o provedor implementar práticas de Gestão de
Conhecimento, Inovação, Meio-Ambiente e Informática em projetos.
2.2.14. COPC - Customer Operations Performance Center
A COPC foi desenvolvida em 1995 nos Estados Unidos como uma norma de gestão
baseada em processos de serviços elaborada por um comitê formado por
representantes de empresas como American Express, Compaq, Dell, Microsoft e
45
Motorola (COPC, 2009). Com o objetivo de padronizar os procedimentos nos centros
de atendimento ao cliente, a norma COPC tomou por base as melhores práticas
existentes nessas empresas. Foi fundada então a COPC Inc., empresa exclusiva
para a emissão da certificação. A COPC realiza auditorias nos provedores
interessados nesta certificação, com base em requisitos contidos em suas duas
normas.
Existe uma demanda de empresas de Call Center e Contact Center pela COPC.
Este padrão certifica o profissional e também a empresa. No Brasil as maiores
empresas de Call Center possuem esta certificação e utilizam as suas práticas, a
exemplo da Atento e da Teleperformance. É o equivalente a uma empresa
concentrada em software necessitar do CMMI para obter diferencial no mercado. O
referencial do padrão é a norma COPC-2000 CSP (provedores de serviços) e o
COPC-2000 VMO (vendedor de soluções).
2.2.15. ISO 9001:2008
A norma ISO 9000 determina um sistema de gerenciamento de qualidade que deve
ser seguido pelas organizações (ISO 9001, 2008). O provedor deve seguir alguns
passos e atender alguns requisitos da ISO 9001 para serem certificadas. Dentre
esses requisitos pode-se citar:
− Padronização de todos os processos chaves do negócio, processos que afetam o
produto e conseqüentemente o cliente;
− Monitoramento e medição dos processos de fabricação para assegurar a
qualidade do produto/serviço, por meio de indicadores de desempenho e
desvios; Implementação e manutenção dos registros adequados e necessários
para garantir a rastreabilidade dos processos;
− Inspeção de qualidade e meios apropriados de ações corretivas quando
necessário;
− Revisão sistemática dos processos e do sistema da qualidade para garantir sua
eficácia.
Exemplos de aplicação da ISO 9001:2008 na oferta e operação de serviços de TI
abrangem aplicação de um gap analysis, implantação dos processos e do sistema
46
de gestão, auditoria interna e auditoria externa. Recomenda-se um escopo que
contemple todas as áreas do provedor, incluindo projetos, contratos e áreas
corporativas, para que ocorra de fato uma padronização geral de processos.
2.2.16. ISO 14001:2004
A norma ISO 14001 é uma norma criada para auxiliar empresas a identificar,
priorizar e gerenciar seus riscos ambientais como parte de suas práticas usuais. A
ISO 14001 exige que as empresas se comprometam com a prevenção da poluição e
com melhorias contínuas, como parte do ciclo normal de gestão empresarial (ISO
14001, 2004). Para os serviços de TI voltados para a indústria é estratégico as
empresas conseguirem a certificação 14001, pois demonstram que estão aderentes
às melhores práticas de gestão ambiental.
Esta certificação está sendo exigida cada vez mais em concorrências de tecnologia
da informação para clientes nas áreas petroquímicas, saneamento e mineração,
entre outras. Adotar também dentro do provedor de serviços de TI as práticas da
ISO 14001 pode ser considerado relevante, pois seus clientes do segmento
industrial podem solicitar este compliance em RFP (Request for Proposals).
2.2.17. ISO/IEC 27005
A ISO 27005 fornece as diretrizes para o gerenciamento dos riscos de segurança da
informação (SI) e fornece sustentação aos conceitos especificados na ISO
27001:2005, além de auxiliar na implementação e certificação do sistema de gestão
dessa norma (ISO 27005, 2007). A ISO 27005, a exemplo de outras normas de
sistemas de gestão, também adota o modelo PDCA (Plan, Do, Check, Act),
conforme quadro 3.
Quadro 3 – Relação PDCA x Riscos na ISO 27005
PDCA Processo de Gerenciamento de Riscos de Segurança
Plan Estabelecer o contexto, avaliar o risco e desenvolver plano de tratamento e aceitação do risco
Do Implementar o plano de tratamento dos riscos Check Monitorar e revisar de forma contínua os riscos Act Manter e melhorar o processo de gestão de riscos de segurança
47
A norma abrange as etapas de identificação, estimativa, avaliação, tratamento e
aceitação ou não dos riscos. Tudo isto é complementado pelas atividades de
comunicação, monitoramento e revisão dos riscos.
O provedor pode utilizar as melhores práticas da ISO 27005 no modelo de
governança de projetos de transição e também na operação de serviços de TI. Em
conjunto com as práticas da ISO 27001 e ISO 27002 é útil na elaboração da análise
de impacto nos negócios (BIA) e do plano de riscos do provedor.
2.2.18. ISO/IEC 38500
A ISO 38500 é baseada em um padrão australiano (AS8015) e cobre os aspectos
relacionados à Governança Corporativa de TI (ISO 38500, 2009). O padrão AS8015
provê seis princípios orientadores para o estabelecimento de uma governança
corporativa e também para o uso aceitável, eficiente e efetivo dos recursos de TI.
Esta norma sugere que a Governança Corporativa de TI está substituindo a
Governança de TI. Isto significa que as informações, dados, sistemas e demais
recursos não pertencem somente a área de TI, mas a toda a corporação.
Os objetivos dessa norma são:
− Estabelecer responsabilidades facilmente compreensíveis para a TI;
− Planejar a TI para que ela ofereça o melhor suporte à organização;
− Validar as aquisições de TI;
− Garantir o melhor desempenho da TI sempre que necessário;
− Garantir a conformidade da TI junto às normas regulamentares;
− Garantir que a utilização dos recursos de TI respeite os fatores humanos.
A ISO 38500, em conjunto com outras práticas de governança de TI como o CobiT e
Val IT, é utilizado na elaboração do modelo de governança do projeto de transição e
da operação de serviços de TI. Também pode ser utilizada na governança do próprio
provedor de serviços de TI.
48
2.2.19. Lean Six Sigma
O Lean Six Sigma combina a velocidade e eliminação de desperdícios do Lean com
a qualidade dos processos do Six Sigma. A metodologia Seis Sigma, como também
conhecida em português, tem o principal objetivo de implementar um processo
sistemático de melhorar de forma drástica a qualidade dos processos e eliminar as
deficiências e ineficácias (GYGI et al. 2008). São usadas ferramentas estatísticas
conhecidas a exemplo de controle estatístico de processo e planejamento de
experimentos, porém sua abordagem e a forma de implementação são consideradas
únicas e bastante eficazes (KUBIAK; BENBOW, 2009). Esta metodologia foi
originalmente desenvolvida pela Motorola, no início no final da década de 80 e
adotada com sucesso por outras empresas como a GE, AlliedSignal e ABB
(WERKEMA, 2002).
Conforme George (2004), o Seis Sigma enfatiza a necessidade de reconhecer
oportunidades e eliminar defeitos definidos pelos clientes, reconhece que a variação
prejudica nossa capacidade de entregar serviços de alta qualidade de forma
confiável, requer decisões baseadas em dados e incorpora um abrangente conjunto
de ferramentas da qualidade sob uma estrutura denominada DMAIC (Definir, Medir,
Analisar, Melhorar e Controlar) para a solução eficaz de problemas. Oferece também
uma infraestrutura cultural prescritiva que é eficaz na obtenção de resultados
sustentáveis e, quando corretamente aplicado, promete grandes resultados nos
projetos selecionados.
O Lean Manufacturing (Produção Enxuta), por sua vez, focaliza em maximização de
velocidade de processo, oferece ferramentas para a análise de fluxo de processo e
tempos de atrasos em cada atividade do processo, centra na separação do trabalho
adicionador de valor do não-adicionador com ferramentas para eliminar as causas-
raiz de atividades não-adicionadoras de valor e o seu custo. Oferece também um
meio de quantificar e eliminar o custo da complexidade (GEORGE, 2004). O
aumento de velocidade é uma das fases mais importantes do Lean e pode ser obtido
observando as sete fontes de desperdícios (PRIES 2009; GEORGE, 2004; KUBIAK;
BEMBOW, 2009), sendo elas: Super-processamento (tentar adicionar mais valor a
um serviço/produto); Transporte (movimentação desnecessária de materiais,
49
produtos ou informações); Movimento (movimentação desnecessária de pessoas);
Estoques (qualquer trabalho em processo além daquilo que é necessário para
produzir para o cliente); Tempo de espera (qualquer atraso entre o fim de um
passo/atividade de processo e o início do passo/atividade seguinte); Processamento
(algumas operações de um processo poderiam nem existir); Defeitos (produzir
produtos defeituosos significa desperdiçar materiais, mão-de-obra, movimentação de
materiais defeituosos e outros);
O MOPP utiliza quatro ferramentas do Lean Six Sigma: Rendimento do Processo
(RTY), Lead Time, Voz do Cliente (VOC) e Quality Function Deployment (QFD), esta
última explicada no capítulo 2.1.6. - Qualidade dos Serviços de TI.
Kubiak e Benbow (2009) relatam que rendimento do processo é a proporção de itens
corretos (em conformidade com as especificações) que é retirado de um processo
comparado ao número de itens brutos colocados nele. O FTY (First Time Yield ou
Rendimento Inicial do Processo) mede o rendimento considerando valores redutores
de rendimento como inspeção e retrabalho. O RTY (Rolled Throughput Yield ou
Rendimento Final do Processo) é a multiplicação do FTY para cada etapa envolvida
no processo, ou seja, RTY = FTY1 x FTY2 x ... x FTYn .
Werkema (2007) cita que o Lead Time representa o tempo que se leva para entregar
um serviço ou produto após o recebimento da demanda. A equação utilizada chama-
se Lei de Little, ou seja: Lead Time = Quantidade de Trabalho em Processos (WIP –
Work in Process) / Ìndice Médio de Conclusão (ER – Exit Rate), ou LT = WIP/ ER.
George (2004) relata que o WIP aplica-se a todo e qualquer processo, incluindo
serviços de TI, a exemplo de incidentes pendentes de usuários ou demandas
evolutivas de software. Já o índice médio de conclusão pode ser representado como
a capacidade de vazão dos processos. Em serviços de TI, pode ser medida pela
capacidade total da equipe em resolver os incidentes, por exemplo. O aumento do
ER pode ser conseguido aumentando a produtividade e a redução do WIP por meio
de uma gestão eficiente da demanda. Para George (2003), adicionar capacidade
sempre é dispendioso. O Lead Time mostra que é muito melhor reduzir o WIP, pois
requer investimentos de capital intelectual em vez de capital financeiro (o custo
continuado de pessoas, equipamentos e tecnologias) em serviços.
50
A VOC (Voice Of Customer ou Voz do Cliente) é utilizada no Lean Six Sigma para
capturar o que o cliente espera (exigência) de um processo, serviço ou produto. Esta
voz pode ser capturada por meio de entrevistas, questionários, monitoria e
pesquisas. Trata-se de uma entrada chave para desenvolvimento de produtos e
também do QFD (Quality Function Deployment).
A partir dos frameworks apresentados, foi possível desenvolver modelos
combinados a partir das especialidades e prescrições de cada prática, conforme
tópicos seguintes.
2.3. Principais modelos e trabalhos publicados
No Brasil, o trabalho de Santos (2006) sobre integração de práticas em certificações
de TI abordou a questão de reunir as práticas dentro de cada certificação para que
as empresas pudessem utilizar a melhor combinação. No entanto, este trabalho não
detalhou uma combinação de processos dentro de cada prática e sua melhor
integração para ser utilizado pelas empresas. Santos (2006) também destacou a
combinação de um processo específico, no caso Gestão de Configuração para
alinhamento entre Engenharia de Software e Gestão de Serviços de TI dentro das
empresas. Neste trabalho, modelos como o MAN/TI, encontrado em Laurindo
(2008) não é incluído neste tópico por se tratar de análise de TI nas organizações e
não ser baseado em práticas de outsourcing e na combinação de frameworks e
melhores práticas do mercado. Desta forma, apresenta-se nos próximos tópicos os
modelos integrados que foram considerados para comparação com o MOPP.
2.3.1. ISF – Integrated System Framework for Excellence
Este modelo de integração de práticas foi desenvolvido pelo ISD (empresa
representante no Brasil do SEI – Software Engineering Institute que detém os
direitos do CMMI em parceria com a PUC-RS). O ISF ou Integrated System
Framework (ISF for Excellence) está integrado às melhores práticas e tem a
expectativa de melhorar a gestão de serviços de TI das empresas (ISD, 2009). O
framework é mostrado na figura 10.
51
Também tem por objetivo auxiliar as empresas nas decisões envolvendo os diversos
modelos e melhores práticas disponíveis sem a necessidade de conhecimento
detalhado de cada referência.
Figura 10 – Modelo ISF
fonte: Adaptado de ISD Brasil, 2008
Os padrões incorporados na versão inicial do ISF for Excellence são: CMMI, ISO
9001, CobiT, ITIL, ISO 15504, eSCM, People CMM (PCMM), Six Sigma e MBNQA.
Existe uma visão de relacionamento no ISF que visa destacar o conceito de cada
framework (ex. ITIL e CMMI), bem como seu relacionamento com os demais. O
objetivo principal deste modelo é apresentar os modelos de forma integrada, cada
um sendo utilizado e explorado em seu potencial. O modelo está em um nível
elevado de abstração, não é prescritivo, aplica-se mais fortemente a departamentos
internos de TI das empresas e também não está vinculado a um ciclo de vida de
outsourcing. Combina as práticas em um modelo de alto nível, sem efetivamente
entrar no detalhe da aplicação de cada processo em cada prática.
52
2.3.2. Global Service Delivery da Tata Consultancy Service - TCS
O modelo de outsourcing GSD da TCS (2009), Tata Consultancy Service, maior
provedor indiano de TI, combina melhores práticas de mercado como ITIL e CMMI,
conforme pode ser visto figura 11.
Figura 11 – Estrutura do Modelo GSD
fonte: Traduzido de Tata Consultancy Service, 2007
A TCS é uma das principais provedores mundiais em tecnologia da informação com
faturamento anual de US$ 5 bilhões em 2008. Mekinian (2009) relata que a
estratégia de outsourcing da TCS com o GSD serve para posicioná-la e competir
com os principais players (competidores) globais. O modelo está estruturado em
torno de quatro visões: negócios, tecnologia, processo e pessoas.
A visão de negócios envolve preços, qualidade, serviços, disponibilidade a
satisfação dos usuários internos e externos. Nesse aspecto, utiliza-se como base o
padrão Malcom Baldrige administrado pela ASQ (American Society for Quality). O
uso do MBNQA (Malcon Baldrige National Quality Awards) visa alinhar os projetos e
processos às metas estratégicas. Logo após, os problemas críticos são identificados
53
e solucionados por meio do Seis Sigma. Nesse aspecto, a visão de tecnologia diz
respeito a excelência nas atividades operacionais, visão da capacidade do negócio,
melhoria na entrega e gestão do consumo de tecnologia com o Seis Sigma. Para a
etapa de processos, o objetivo é realizar compliance com as normas regulatórias,
maturidade, gestão de projetos, gestão da qualidade, metodologia e gestão de
processos. Nessa etapa utiliza-se a ISO 9001, ISO 20000, ISO 27001, CMMI e ITIL.
Finalmente, a última etapa envolve o fator Recursos Humanos. Neste aspecto a
preocupação maior do modelo é a gestão de pessoas por meio de mudanças
organizacionais (MOC), liderança, capacitações, competências e incentivos
necessários. Nesta etapa o modelo recomenda utilizar o PCMM (People Capability
Maturity Model, voltado para gestão de pessoas em processos de software).
2.3.3. Integrated Framework da Infosys - IF
Conforme a Infosys (2009), o Seis Sigma é utilizado no IF para direcionar a melhoria
contínua dos processos e alinhamento estratégico. Neste aspecto, este framework
considera que o Seis Sigma reconhece áreas e projetos problemáticos, define
esforços e projetos de melhoria, determina e implementa soluções de nível de
ruptura orientadas a dados, tudo de forma prevista e repetida para melhorar os
resultados do negócio.
Figura 12 - Integrated Framework
fonte: Infosys, 2009
O objetivo deste modelo integrado é a qualidade para alcançar as metas dos
negócios, conforme mostrado na figura 12.
54
O Seis Sigma proporciona ferramentas, técnicas, metodologias DMAIC (Definir,
Medir, Analisar, Melhorar, Controlar) / DMADV (Definir, Medir, Analisar, Desenvolver
e Validar) para melhoria contínua de processos e para novos produtos
desenvolvidos. O ITIL fornece processos e práticas para entrega e suporte dos
serviços de TI. O CMMI suporta os processos e práticas de desenvolvimento e
manutenção das aplicações, também utilizado como um modelo de maturidade dos
processos de software. O CobiT provê objetivos de controle, guia de auditoria, KPI
(Key Performance Indicador), KGI (Key Goal Indicator) e um framework de
maturidade do ciclo de vida de TI, sendo a base para o modelo da Infosys. Uma
aplicação descrita pelo modelo e que detalha alguns processos é apresentada no
quadro 4. Trata-se de um exemplo em uma implantação da Sarbanes-Oxley (SOX):
Quadro 4 – Exemplo de Aplicação do Modelo da Infosys (IF)
# Processo de Compliance Aplicação do Modelo
1 Avaliação de controles gerais de TI
(avaliação gerencial da seção 404 da
SOX).
ITIL – Gerenciamento de Incidentes, Eventos e
Acesso – eventos, incidentes e logs de transação
auxiliam a detectar acessos não autorizados.
2 Requisito Específico – Deve existir
uma política de controle de acesso.
CobiT – AI.6. Gestão de Mudanças garante que
mudanças realizadas são autorizadas e estão em
conformidades com os padrões e procedimentos.
3 Avaliação de Controles de Aplicações
de TI (Avaliação Gerencial de
controles internos.
Requisito Específico – Controle de
sistemas devem ser implementados
para segregação de funções e
aprovações.
CobiT Control Objective – AI.2. Aquisição e
Manutenção de Aplicações de TI e CobiT. AI.2.3. –
Auditoria e Controle de Aplicações garantem que
controles de negócios, onde apropriado, são
implementados de forma automatizada em
aplicações para que o processo seja realizado com
exatidão, no tempo, de forma completa, autorizado
e de forma auditável.
4 Avaliação dos controles dos
fornecedores.
Requisito Específico: PCAOB Padrão
de Auditoria 5 (SAS 70).
CMMI Gestão de Acordos com Fornecedores
(SAM). SP 1.3. – esta prática específica fornece o
processo e melhores práticas para estabelecer
acordos com fornecedores onde os controles
internos são exigidos para os processos esperados.
SP 2.2. e SP 2.3. Fornece o processo para
monitorar e avaliar os processos do fornecedor.
fonte: Infosys (2009)
55
O modelo da Infosys apresenta uma visão genérica e não fornece um modelo
pronto, para que seja realizado como um guia para uso por provedores de TI. Existe
uma limitação do modelo pelo fato de não tratar um ciclo de vida e também de
considerar apenas quatro frameworks (Seis Sigma, ITIL, CMMI e CobiT). Este
modelo é proprietário, porém prescritivo.
2.3.4. Combinação de Práticas do ITGI – IT Governance Institute
O Modelo do ITGI (ITGI, 2008) está estruturado de forma hierárquica, iniciando-se
pelas diretrizes estratégicas e de compliance da empresa, conforme pode ser visto
na figura 13.
Figura 13 – Modelo de Combinação de Práticas do ITGI fonte: ISACA (2006, p.25)
A estrutura apresentada do modelo do ITGI na figura 13 (Drivers, Governança
Corporativa, Governança de TI, Padrões das Melhores Práticas, Processos e
Procedimentos), é detalhada nos parágrafos seguintes de modo a favorecer a
compreensão do que se pretende com um Modelo de Governança de TI e qual a
abrangência de fatores, normas e atividades que o envolvem.
56
− Drivers. Nesta parte da estrutura de governança são determinadas as
necessidades do negócio com suas metas, assim como as conformidades
necessárias a exemplo de Basiléia II, HIPAA e Sarbanes-Oxley.
− Governança Corporativa. Para suportar os drivers, são determinados os
objetivos de negócios e de controles, por intermédio do Balanced Scorecard
(BSC) e do COSO. Enquanto o BSC suporta a estratégia empresarial por meio
das perspectivas financeira, do cliente, processos internos e
aprendizagem/conhecimento, o COSO preocupa-se com a governança
corporativa com um ambiente necessário de controle, gestão de risco, atividade
de controle, informação/comunicação e monitoramento.
− Governança de TI. O framework Cobit v4.1 suporta a Governança de TI, por
meio de matriz de relacionamento entre os controles e governança de TI com a
governança corporativa. Determina também o que deve ser realizado nos
modelos, normas e nas metodologias abaixo dele.
− Padrões de Melhores Práticas. As práticas de qualidade, segurança e gestão
de serviços direcionam a empresa para requisitos dos processos a serem
implantados para suportar as diretrizes de governança de TI, determinados pelo
CobiT. A ISO 9001:2008 determina os requisitos de um sistema de gestão de
qualidade. A ISO/IEC 20000, por sua vez, fornece os processos de gestão de
serviços de TI (também inclui sistema de gestão de qualidade específico de
serviços). Finalmente, a ISO/IEC 27001 fornece as diretrizes para a gestão de
segurança da informação.
− Processos e Procedimentos. O funcionamento das práticas no dia-a-dia é
possível por meio de políticas, processos, procedimentos, instruções de trabalho
e templates, fornecidos pelo sistema de gestão de qualidade e pelos processos
de gestão de serviços suportados pelo ITIL (ex. gerenciamento de capacidade).
2.3.5. Gartner PMS - Process Model Selection Framework
O modelo PMS, apresentado na figura 14, classifica os frameworks de práticas de TI
em quadrantes. O objetivo deste modelo é selecionar os modelos mais adequados
para serem utilizados pelos provedores internos e externos de TI (GARTNER, 2008).
57
O modelo de combinação do Gartner divide os frameworks holísticos, genéricos e
específicos com nível de abstração baixo, moderado e alto. O ITIL, CMMI e CobiT
são considerados genéricos entre baixa e moderada abstração, enquanto o Seis
Sigma e a ISO 9001 são considerados holísticos e de alta abstração. O PMS não
apresenta a melhor combinação dos frameworks para utilização pelas empresas.
Figura 14 – Gartner’s Process Model Selection Framework
fonte: Gartner, 2005
O framework determina uma visão baseada em duas visões (holística e abstração)
para seleção do melhor modelo, não se preocupando em qual fase ele se enquadra
dentro de um processo de outsourcing. O CobiT fornece objetivos gerais de controle
para a organização. CMMI e ITIL definem processos e práticas para os controles
definidos pelo CobiT. Esses três frameworks são complementares.
2.3.6. Modelo Saad de Outsourcing de TI Este modelo foi desenvolvido por Saad (2006) e é composto por um ciclo de vida de
outsourcing. O objetivo é a descrição da melhor prática para cada etapa do ciclo,
58
sem necessariamente entrar no detalhe de certificações e melhores práticas do
mercado. Também tem como objetivo:
− Reduzir e controlar custos operacionais;
− Incrementar o grau de flexibilidade;
− Reproduzir o prazo de disponibilização de novos produtos;
− Utilizar recursos especializados em áreas específicas ;
− Melhorar a qualidade de serviços de TI;
− Ganhar acesso às melhores práticas da indústria;
− Melhorar o retorno e reduzir investimentos em ativos de TI.
Este modelo define um ciclo de vida típico de outsourcing de TI, sob o ponto do
relacionamento em um processo de prestação de serviços na visão do cliente. Não
contempla frameworks mais adequados para o uso em cada etapa do ciclo de vida.
O modelo é composto de seis fases, subdivididas em subfases, conforme figura 15.
Figura 15 – Modelo SAAD
fonte: Saad (2006, p.267)
A tomada de decisão de realizar ou não um outsourcing é executada por meio de um
estabelecimento de um contexto e de uma avaliação interna para determinar o
escopo, objetivos e benefícios desta operação. A seleção do provedor é realizada
por meio de pesquisa do mercado de outsourcing, visitas a clientes dos provedores
atuais, pré-qualificação dos provedores, envio de RFP (Request for Proposals),
avaliação das propostas, verificação das competências e capacidade do provedor. A
negociação do contrato é realizada inicialmente por meio de um due diligence, que
consiste no levantamento de informações de forma a avaliar o risco para execução
dos serviços. Na sequência são negociados os termos e condições contratuais por
uma equipe designada. Aspectos como escopo dos serviços, prazos, composição da
equipe, espaço físico, propriedade intelectual, plano de continuidade, condições de
rescisão, penalidades e estrutura de preços fazem parte da negociação. O projeto
de transição no modelo contempla a transição de recursos humanos, transição de
recursos tecnológicos e transição dos serviços para a operação.
59
A Gestão do contrato na operação de serviços de TI contempla uma estrutura de
relacionamento entre o cliente e o provedor com foco em resultados e não em
controles e relacionamento mútuo nos diversos níveis hierárquicos. Envolve temas
como gestão da operação, atualização tecnológica e capacidade do provedor.
Finalmente, a fase de finalização do contrato envolve a sua renovação ou
transferência das atividades para outro provedor.
2.3.7. INNOIT - Innovation IT Trata-se de um modelo de inovação para provedores internos e externos de TI, com
base no modelo CobiT v4.1, conforme a figura 16. Surgiu de uma pesquisa para
uma tese de doutorado em Gestão de Sistemas de Informações na Universidade de
Praga (SIMKOVA, 2008). O INNOIT foi todo desenvolvido baseado no CobiT v4.1 e
segue sua estrutura de processos.
Figura 16 – Modelo INNO IT fonte Zimkowa (2008, p.1).
60
O modelo define uma série de domínios com seus respectivos processos. Em cada
processo existem as metas definidas e os objetivos de desempenho. O modelo
possui quadro domínios: Avaliação da Inovação (IA), Estratégia da Inovação (IS),
Implementação da Inovação (II) e Pesquisa e Desenvolvimento (RD). Como entrada
para o modelo existem as demandas dos clientes, competição do mercado e
mudanças radicais. O modelo também contempla barreiras para a sua execução
como as políticas governamentais, requisitos legais e propriedade intelectual.
Apesar do modelo se basear apenas no CobiT v4.1 e também ter como objetivo uma
única área de provedores de TI (inovação), ele serviu para comparação com o
MOPP no contexto de um novo framework baseado na estrutura de padrões já
reconhecidos no mercado.
2.3.8. GSS - COBITIL Este modelo foi desenvolvido em uma tese de Doutorado em Engenharia Elétrica
defendida pelo Professor Sergio Clemente na Universidade de São Paulo, Brasil, em
maio de 2007 (CLEMENTE, 2007). A questão que o autor respondeu foi: “Como
elaborar, em alinhamento com a norma ISO/IEC 20000 a partir de modelos
existentes, um modelo para gerenciamento de serviços de TI para controle e
execução das práticas dos processos, e que possa auxiliar na implantação de uma
gestão de serviços de TI mais eficiente e eficaz?”.
O autor combinou as práticas ITIL, ISO 20000 e CobiT para desenvolver um modelo
de referência em suporte em serviços de TI, específico de empresas clientes,
conforme mostrado na figura 17.
O objetivo da pesquisa é apresentado abaixo:
− Desenvolver um método para criação de modelo de gerenciamento de serviços
de TI (GSTI)
− Desenvolver um modelo de gerenciamento de serviços de TI aplicando o método
de criação de modelo de GSTI
− Desenvolver um método para especializar o modelo de GSTI de acordo com o
papel de TI.
61
Para o objetivo deste trabalho, o segundo item (modelo COBITIL) foi selecionado
para estudo e comparação com o modelo MOPP.
Figura 17 – Modelo COBITITIL (ITIL, CobiT e ISO 20000) fonte: Clemente (2007)
O modelo desenvolvido pelo autor concentra-se no CobiT para controle dos
processos e no ITIL como executor dos processos e possui um objetivo de estar
alinhado com a norma ISO/IEC 20000, conforme figura 18. O modelo COBITIL
concentra-se nos processos de suporte de serviços dos frameworks utilizados e
utiliza modelo de maturidade do CobiT e do ITIL para medir o nível de utilização de
cada processo de suporte de serviços.
O modelo prioriza a estrutura do Cobit, qual seja, maturidade, metas e indicadores e
os utiliza para todos os processos citados. Não se trata de um modelo independente,
mas sim altamente dependente das versões do CobiT e ITIL.
62
Segundo Clemente (2007), quando houver mudanças nas versões dos modelos ITIL
e/ou CobiT deve-se reaplicar o método de criação de modelo de gerenciamento de
serviços de TI utilizando as novas versões do ITIL e /ou CobiT.
Figura 18 – Relacionamento ITIL x ISO 20000 x CobiT fonte: Clemente (2007)
Para tanto, devem ser seguidas as seguintes etapas: a) selecionar os modelos;
alinhar os modelos; b) conceber a estrutura; c) definir os papéis e responsabilidades;
d) definir atividades e subprocessos; e) definir as entradas e saídas do novo modelo;
f) definir as metas; g) definir métricas; h) definir os níveis de maturidade. As
comparações entre frameworks, realizadas neste modelo, já estavam contempladas
em publicações especializadas, a exemplo do ITIL x CobiT ou CobiT x PMBoK,
disponíveis na página no ISACA desde 2005 (http://www.isaca.org).
2.4. Centros de Excelência em Modelos e Práticas Outsourcing
Alguns centros de excelência na pesquisa, ensino e estudo das práticas abordadas
nesta tese são mostradas na figura 19. Logo em seguida, são apresentados os
63
estudos realizados em práticas e certificações por estas universidade, entidades e
empresas:
Figura 19 – Centros de Excelência em Gestão da Oferta e Serviços de TI
a. Área Acadêmica − Universidade Carnegie-Mellon – EUA : pesquisas em outsourcing e qualidade
de serviços de software (CMMI for Development e Services) por meio do SEI
(Software Engineering Institute). Pesquisas conduzidas em outsourcing de
serviços de TI com o framework eSCM do seu centro de pesquisa IT Services
Qualification Center.
− Universidade de São Paulo - Engenharia de Produção - DTI : pesquisas em
Gestão de TI e Qualidade de software do DTI (Departamento de Tecnologia da
Informação).
− Universidade Federal do Rio de Janeiro – Engenharia de Produção: pesquisa
conduzidas por professores da UFRJ no framework eSCM.
− George Washington University: A GWU conduz capacitação e certificação
reconhecida em gerenciamento de projetos no nível de pós-graduação.
64
− FIAP – Faculdade de Informática e Administração Paulista - Os cursos de
pós-graduação em ISO 20000, ITIL, CobiT, ISO 27001, PMI, Outsourcing e CMMI
estão entre os melhores do Brasil. Forma profissionais para o mercado e
contribui para pesquisas em Gestão de Sistemas de Informações, Gestão de
Projetos e Governança de TI.
− Universidade de Antuérpia – Pesquisadores desta universidade participaram
ativamente na elaboração e revisão do CobiT. Publicam também papers, livros e
informações gerais em governança de TI.
− MIT – Sloan School of Management - CISR – Centro de Pesquisas em
Sistemas de Informações - Atualmente o centro mais avançado em pesquisas
relacionadas a Governança de TI. Possui pesquisadores que são referências no
mundo acadêmico e empresarial na área de Governança de TI.
b. Área Empresarial
− Infosys / TCS / Satyam e Wipro: Os provedores indianos estão na vanguarda
quanto o assunto é práticas e certificações em todas as áreas de tecnologia da
informação, incluindo software, serviços e processos de TI. A Satyam foi uma das
criadoras do eSCM junto com a Universidade Carnegie-Mellon. As principais
empresas indianas possuem o CMMI 5, eSCM 5, ISO 20000, ISO 27001 e SAS
70. Para maiores informações ver trabalho de Santos e Campos (2008b) no
XXVIII ENEGEP sobre vantagem competitiva em práticas e certificações das
empresas indianas.
− HP / IBM / Accenture: Os provedores americanos realizam pesquisam e buscam
certificar suas unidades de software e serviços de TI pelo mundo, com atenção
maior para a Índia. No Brasil a IBM possui a sua unidade de Hortolândia
certificada no nível máximo do eSCM e CMMI. A HP possui certificações ISO
20000 e ISO 27001.
− SEI / ASQ / PMI / IPMA / ISACA / IAOP e OGC: Estes institutos são criadores e
promovem a disseminação das melhores práticas e certificações no mercado
mundial de TI, que incluem gerenciamento de projetos (PMBok, IPMA, PMO,
OPM3), Segurança e Governança de TI (CISA, CGEIT, CISM) e Gestão de
Serviços de TI (ITIL)
65
− ISD / Quint Wellington / Brunise: Estas empresas são parceiras dos institutos
proprietários das práticas e certificações e ajudam na sua disseminação por meio
de capacitações, eventos e preparatórios para certificação.
− Vale do Rio Doce / Petrobrás / Bradesco: São empresas usuárias das práticas
e certificações. São algumas das principais empresas disseminadoras da
importância das práticas e certificações em TI.
2.5. Mercado de Tecnologia da Informação e os Modelos Integrados
O mercado de Tecnologia da Informação abrange atualmente uma indústria que
fatura US$ 1,2 trilhão no mundo em 2009, crescendo a taxas próximas de 10% ao
ano. O volume de negócio no Brasil supera US$ 20 bilhões, sendo US$ 9 bilhões em
serviços de TI. Puxando esse crescimento estão os serviços de outsourcing, que
movimentam US$ 70 bilhões em 2008, e vêm crescendo cada vez mais
(BRASSCOM, 2010). Ainda segundo a Brasscom (2010), o Brasil aparece em
segundo lugar no ranking mundial em número de mainframes, com grande oferta de
profissionais habilitados em COBOL. Além disso, possui outras vantagens em
serviços de TI a exemplo do Sistema de Pagamentos Brasileiro (SPB),
transferências de fundos interbancários, soluções tecnológicas que são benchmarks
em automação bancária, internet banking, operações pelo celular, governo
eletrônico, fuso horário próximo dos Estados Unidos e uma das maiores
comunidades de desenvolvedores em Java. O desafio, porém, é cada vez mais
crescer a participação de empresas brasileiras de TI no exterior. Modelos de
outsourcing como o MOPP podem auxiliar nesse objetivo.
A busca de exportações de serviços tem crescido entre as nacionais, que estão
cada vez mais preparadas para competir no mercado global em qualidade e preço. A
IBM e a HP, as duas maiores multinacionais americanas e maiores do mundo em
tecnologia da informação dominam o mercado nacional de TI. Há necessidade da
redução de diferenças (gaps) das empresas nacionais com as multinacionais. Das
empresas nacionais que atuam em serviços de TI a CPM Braxis é a primeira do
ranking. O Brasil possui um mercado de serviços de TI competitivo, com a presença
de empresas de grande porte, como Accenture, Atos Origin, BRQ, BT, Cast, CPM
Braxis, Datasul, DTS, EDS, G&P, GFT, HSBC, Hughes, IBM, Intel, Itautec, Microsoft,
66
Politec, Promon, Resource, Salles BPO, Satyam, Siemens, Stefanini, Sun, Tata,
Tivit, Totvs, Ubik e Unisys. Conforme Santos e Campos (2008b), a busca de
certificações e práticas devem ser um caminho a ser perseguido para reduzir esta
diferença.
As empresas indianas iniciaram o processo de certificação da produção e serviços
de TI ainda no inicio da década de 1990. Foram inovadores ao buscar o nível 5 do
CMM – Capability Maturity Model (antecessor ao CMMI), BS 15000 (antecessora da
ISO/IEC 20000) e também na BS 7799 (anterior a ISO/IEC 27001). Santos e
Campos (2008b) relatam que as vantagens em certificações das empresas indianas
na década de 90 eram bem significativas. As empresas indianas tiveram a
consciência, ainda no inicio da década de 80, que software e serviços poderiam
trazer mais capacidade de TI para o País e participação maior no mercado mundial.
A busca de certificações internacionais foi um dos pilares desta estratégia
competitiva. A tabela 1 mostra a quantidade de três importantes certificações
classificadas por país. Nota-se pelas informações que existe uma desvantagem do
Brasil em relação a algumas empresas indianas em certificações ISO e CMMI.
Tabela 1 – Certificações ISO e CMMI
# País CMMI ISO 20000 ISO 27001
1 Brasil 48 4 21
2 Estados Unidos 718 15 85
3 India 204 44 435
4 Japão 172 60 2997
5 Coréia do Sul 78 34 82
6 China 240 37 180
7 Reino Unido 48 52 370
Fonte: ISO, itSMF e CMU/SEI, base: março/2009
Em fevereiro de 2010, o Brasil possuía apenas cinco empresas com a certificação
CMMI Nível 5, que é o nível de maturidade necessário para uma maior
competitividade dos provedores no mercado internacional de software. Esta
quantidade na India já ultrapassa 100 empresas. Conforme a tabela 1, em
segurança da informação a quantidade de certificações das empresas brasileiras
67
representa 5% do total de empresas certificadas na Índia. Os provedores indianos
buscam cada vez mais uma diferenciação por meio de certificações corporativas ou
de seus profissionais.
Um dos motivos do interesse menor da certificação internacional dos provedores
brasileiros é a ausência de sua maior inserção no mercado internacional. O mercado
doméstico geralmente é o primeiro alvo dos atuais e dos novos provedores.
Conforme mostrado na tabela 2, a empresa brasileira representada na tabela - CPM
Braxis - é uma das exceções, não representando a grande maioria em termos de
certificações (SANTOS;CAMPOS, 2008b).
Os dados tabulados na tabela 2 mostram que algumas certificações como PCMM
(concentrada na gestão de pessoas em desenvolvimento de software) e ISO 27001
(requisitos para segurança da informação) ainda são poucas valorizadas pelas
empresas de TI brasileiras.
Tabela 2 – Exemplo de Certificação das empresas Certificação TCS -
India Infosys-India
Wipro-India
Satyam-India
Patni-India
CPM Braxis-Brasil
Engenharia de Software • CMMI Nível 5 X X X X X X • PCMM Nível 5 X X X X • PCMM Nível 3 X Gestão Serviços de TI • ISO 20000 X X X X X • ISO 27001 X X X X X • e-SCM Nível 5 X X X X X X • SAS 70 X X X X X X • SOX X X X X X Qualidade de Serviços TI • ISO 9001:2008 X X X X X X • ISO 14001:2004 X X X X • TL 9000 X X X X X
Fonte: Santos e Campos (2008b)
É importante comparar o Brasil com a India em tecnologia da informação. Estes
países estão em um estágio bem próximo em termos de desenvolvimento
econômico. O mercado indiano de TI ainda não é tão importante para os seus
provedores, se comparado com o internacional. Sendo assim, os provedores
indianos têm a necessidade de aumentar a sua competitividade no mercado global.
As empresas indianas buscam mostrar aos seus clientes que a qualidade é uma
68
preocupação constante. Iniciou-se no final da década de 90 com a conquista de
certificações no CMMI nível 5 (nível máximo de qualidade em processos de
software). Outro aspecto é que, apenas em uma única empresa indiana, a
quantidade de profissionais certificados em Six Sigma Black Belt está acima de 350
e já existem mais de 100 Master Black Belts (WIPRO, 2008). Nas empresas
brasileiras de TI não existem profissionais certificados na quantidade necessária
para gerar mudanças. Neste aspecto ainda não existe uma preocupação maior dos
provedores brasileiras de TI em aplicar na gestão da qualidade total em tecnologia
da informação.
A pesquisa partiu de estudos de estratégias de oferta e operações de serviços de TI.
Na sequência, avaliou-se os principais frameworks do mercado para delinear os
modelos integrados que serviram de base para comparação com o modelo MOPP. A
partir de uma pesquisa na literatura, experiências e publicações do autor em
congressos e periódicos em engenharia de produção, foi possível desenvolver o
modelo, conforme o leitor poderá acompanhar no próximo capítulo.
69
3. DESENVOLVIMENTO E ANÁLISE DO MODELO MOPP
Existem várias modelos integrados no mercado. Cada um com sua aplicação
específica. Alguns deles têm aplicação em controles ou em ciclo de vida de
outsourcing. Novos modelos estão sendo criados na área acadêmica e no mercado.
A principal diferença do MOPP para estes modelos reside no seu formato prescritivo
e também na combinação do que existe de melhor em cada prática, indicando como
esta combinação aplica-se a cada tipo de oferta ou operação de serviços de TI. O
modelo pode servir como uma arma de competição (Contador, 2004) para os
provedores, incluindo técnicas, métodos e ferramentas para a busca de vantagem
competitiva.
A figura 20 apresenta uma visão geral do MOPP. A partir das necessidades do
mercado e também dos frameworks disponíveis, a exemplo do ITIL, ISO 20000,
CobiT, CMMI, PMI, o modelo MOPP foi desenvolvido dentro de um conceito de ciclo
de vida de outsourcing. Contempla as fases de contratação, projeto de implantação,
operação e projetos eventuais. Além do ciclo de vida, o modelo também oferece um
conjunto de métodos, matrizes e templates para utilização de forma prescritiva pelos
provedores de serviços de TI. O modelo inicia-se com o processo de inteligência do
mercado e termina na operação dos serviços. A finalização dos serviços, na visão do
provedor, não é considerada no MOPP, mas apenas a oferta e operação. Para cada
etapa, são vinculados os processos dos frameworks (ex. ITIL, Cobit, ISO 27005,
IPMA) mais adequados e também uma prescrição da utilização pelos provedores.
Em termos gerais, o modelo é formado pelos seguintes elementos:
− Ciclo de Vida, abrangendo as etapas de Contratação, Projetos de Implantação, Operação dos Serviços e Projetos Eventuais;
− Áreas de conhecimento incuindo governança, segurança, inovação, conhecimento e qualidade;
− Templates;
− Métodos; − Matrizes de Relacionamento.
As áreas de conhecimento a exemplo de Governança de TI e Qualidade fornecem o
conjunto de práticas necessárias para alinhamento com o negócio, conformidade,
70
melhoria contínua, segurança e inovação na oferta e operação dos serviços de TI.
Essas melhores práticas podem ser utilizadas em qualquer fase do ciclo de vida.
Figura 20 – Visão Geral do MOPP
Para melhor entendimento da contribuição do modelo MOPP para os provedores de
TI, é apresentada uma comparação entre o MOPP e modelos integrados de mercado
e acadêmicos. Alguns modelos são específicos de provedores de TI e outros são
mais genéricos, mas todos buscam integração das práticas.
71
Quadro 5 – Comparação MOPP x e-SCM /SP
# e-SCM / SP – Sourcing Capability Model – Universidade Carnegie Mellon
Modelo MOPP
01 Modelo descritivo contendo recomendações de alto nível para o Ciclo de Vida de Outsourcing.
Modelo prescritivo, recomendando qual framework é o mais adequado dentro do ciclo de vida de outsourcing e como utilizá-lo. Considera templates para uso dos provedores de forma automatizada.
02 No relacionamento com as práticas, o eSCM compara a amplitude das práticas do seu framework com o CobiT, ISO 20000 e outros, deixando claro que, implantando o eSCM/SP, parte dos processos de outros modelos estarão também implantados
O modelo em si não compara nenhum processo com outras práticas. Trabalha no conceito de combinação de práticas, podendo o provedor seguir qualquer caminho recomendado ou até mesmo criar uma nova combinação de práticas.
03 O modelo trabalha no conceito de maturidade dos processos para os provedores de TI.
Não trabalha com maturidade dos processos, mas atua sobre um ciclo de vida completo de outsourcing abrangendo também Governança & Compliance de TI. A visão de maturidade dos processos é deixada para oportunidades de trabalhos futuros para o MOPP.
04 O eSCM certifica provedores nos níveis 2, 3, 4 ou 5 (sendo que o nível 5 é obtido automaticamente após 2 anos no nível 4). O valor total para a certificação até o nivel 5 é de US$ 2 milhões.
O modelo não certifica, podendo ser utilizado para efeito de análise de gap e de melhoria dos processos de outsourcing do provedor. Utiliza inclusive o próprio e-SCM/SP como um dos frameworks dentro do ciclo de vida.
05 O Modelo objetiva os Provedores de TI. Não contempla, porém, a visão do tipo de oferta do provedor nem o tipo de necessidade do cliente, mas apenas a visão do ciclo de vida de outsourcing.
Tem por objetivo os provedores de TI e também contempla tipo de oferta do provedor e as necessidades dos clientes (segmento de mercado).
06 O eSCM não considera gerenciamento de projetos como um processo a parte, deixando esta parte para o práticas como o PMI.
Além do projeto de implantação de serviços de TI, o escritório de gerenciamento de projeto (PMO) é um processo complementar ao ciclo de vida de outsourcing. Também considera Segurança da Informação, Qualidade, Conhecimento e Inovação como processos independentes.
07 O e-SCM é um modelo proprietário, com investimento de US$ 2 milhões para atingir o nível 5.
Não é proprietário. É gratuito, podendo ser utilizado sem nenhum tipo de autorização, desde que referenciado.
08 O e-SCM/SP não está em base de dados, mas apenas em formato PDF.
O modelo está em base de dados web no padrão open source (PostgreSQL e Java), podendo ser consultado e atualizado pelos provedores.
09 O e-SCM/SP não possui métodos para auxílio de atividades operacionais da oferta e operação de serviços de TI.
Contempla uma série de métodos para auxílio dos provedores na gestão dos serviços de TI.
72
Quadro 6 – Comparação MOPP x ISF x GSD
# ISF – Integrated System Framework for Excellence - ISD/PUC-RS
Modelo MOPP
01 Não contempla um ciclo de vida de outsourcing, de fácil compreensão. O modelo está em formato top down, incluindo um Sistema de Gestão no topo (ISO 9001 e PNQ/Baldrige), CobiT como Governança de TI, práticas de outsourcing e gestão de serviços de TI e software fazendo a interface com o Seis Sigma que atua na melhoria contínua..
O modelo contempla ciclo de vida de outsourcing e também abrange um conjunto maior de frameworks, além dos estabelecidos pelo ISF.
02 O ISF utiliza combinação de práticas e atua também vinculando os frameworks a cada etapa de seu modelo, porém não determina como deve ser utilizado.
Utiliza combinação de prática, porém vincula os frameworks a cada etapa do ciclo de vida e estabelece como deve ser utilizado.
03 O ISF é altamente proprietário e é fornecido como uma solução, junto com os serviços da empresa ISD.
Não é proprietário
04 O ISF contempla uma base de dados com facilidade de atualização e consulta em plataforma open source, incluindo templates.
Também contempla uma base de dados com facilidade de atualização e consulta em plataforma open source, incluindo templates.
05 O ISF não relaciona os frameworks com o tipo de oferta do provedor e com as necessidades do mercado.
Realiza os dois tipos de relacionamentos.
06 O ISF não possui métodos para auxílio de atividades operacionais da oferta e operação de serviços de TI.
Contempla uma série de métodos para auxílio dos provedores na gestão dos serviços de TI.
07 O ISF abrange além de provedores de TI, também o departamento de TI das empresas.
O modelo tem como público alvo os provedores de TI.
# GSD – Global Service Delivery da Tata Consultancy Service – TCS
Modelo MOPP
01 O modelo divide as práticas e certificações em quatro níveis, no formato top-down, não abrangendo um ciclo de vida de outsourcing. Relaciona o Negócio com o Malcolm Baldrige (MBNQA). Tecnologia o Six Sigma. Processos com a ISO, CMMI e ITIL. Pessoas com o PCMM.
O MOPP trabalha em camadas de negócios, tecnologia e processos de forma implícita dentro de cada etapa do ciclo de vida de outsourcing. Na etapa de contratação, o fator negócio tem maior destaque, enquanto na operação a tecnologia se sobressai. A quantidade de frameworks do MOPP vai além do Baldrige, ISO, CMMI, ITIL, PCMM e Six Sigma, envolvendo também CobiT, COPC, eSCM, IPMA dentre outros.
02 Modelo altamente proprietário Modelo não proprietário 03 Modelo em base de dados, porém em
software pago. Modelo em base de dados em open source.
04 Modelo não contempla relacionamentos com o tipo de oferta do provedor e nem com a necessidade do mercado.
Contempla relacionamentos com o tipo de oferta do provedor e com as necessidades do mercado.
06 O GSD não possui métodos para auxílio de atividades operacionais da oferta e operação de serviços de TI.
Contempla uma série de métodos para auxílio dos provedores na gestão dos serviços de TI.
73
Quadro 7 – Comparação MOPP x IF x ITGI
# IF – Integrated Framework da Infosys
Modelo MOPP
01 O modelo está dividido em camadas, iniciando-se pelo Seis Sigma no topo como diretriz principal. O ITIL e o CMMI estão na camada central, onde o primeiro determina as diretrizes para gerenciamento de serviços de TI e o segundo determina o modelo de maturidade de processos de software. Na base o modelo utiliza o CobiT como padrão para Governança de TI, Controles e Compliance.
Abrange um ciclo de vida e não camadas. A quantidade de frameworks envolvidos não se restringe ao ITIL, CMMI, Seis Sigma e Cobit.
02 O IF entra no detalhe de como utilizar os frameworks, porém apenas para aplicações específicas como a SOX, não abrangendo um ciclo de vida. .
O MOPP também entra no detalhe, porém dentro de um ciclo de vida de outsourcing e em áreas de conhecimento como governança, projetos, inovação e qualidade.
03 Modelo altamente proprietário Modelo não proprietário 04 Modelo em base de dados, porém em
software pago. Modelo em base de dados em open source.
05 Modelo não contempla relacionamentos com o tipo de oferta do provedor e nem com a necessidade do mercado.
Contempla relacionamentos com o tipo de oferta do provedor e com a necessidade do mercado.
06 O GSD não possui métodos para auxílio de atividades operacionais da oferta e operação de serviços de TI.
Contempla uma série de métodos para auxílio dos provedores na gestão dos serviços de TI.
# O Modelo de Integração de Práticas do ITGI – IT Governance Institute
Modelo MOPP
01 Está estruturado em uma hierarquia, onde o nível maior são os drivers de negócios. O CobiT é utilizado na camada de Governança de TI determinando o que deverá ser realizado pela área de TI. Na camada de melhores práticas são utilizados os padrões da ISO 27002, ISO 9001 e ISO 20000. Na camada de execução das atividades, utiliza-se os princípios de segurança, procedimentos de QA (Quality Assurance) e o ITIL.
Além de estar organizado em hierarquia, o modelo também abrange um ciclo de vida de outsourcing. Envolve uma quantidade bem maior de frameworks.
02 Concentra-se no que deve ser feito (descrição dos processos), indicando os frameworks mais adequados.
Além da descrição (o que fazer), também atua na prescrição (como fazer).
03 Objetivo maior em Governança de TI, a combinação de práticas inicia-se com o BSC e o COSO para alinhamento das práticas de TI com o desempenho do negócio e as conformidades regulatórias da empresa.
O objetivo maior é apoiar o processo de oferta e operação de serviços de TI, por meio de um modelo prescritivo de ciclo de vida, métodos e matrizes de relacionamento.
04 O modelo não está em base de dados e também não determina relacionamento com a oferta e necessidade dos clientes.
Está em base de dados open source e relaciona os frameworks com a oferta do provedor e as necessidades dos seus clientes.
74
Quadro 8 – Comparação MOPP x PMS x SAAD x COBIITIL # Gartner PMS – Process Model
Selection Framework Modelo MOPP
01 Modelo de combinação de práticas por meio de quadrantes. Os frameworks como o ITIL, CMMI e CobiT são classificados nos níveis específicos, genéricos e holísticos em termos de relevância para a TI e na outra dimensão em baixo, moderado e alto em termos de nível de abstração.
O objetivo é vincular cada frameworks a ciclo de vida, oferta do provedor e necessidades dos clientes, não destacando em linhas gerais qual frameworks é mais específico ou mais abstrato de forma isolada. O modelo tem uma proposta diferente do PMS, sendo totalmente complementar.
02 Altamente proprietário Não proprietário 03 Modelo descritivo, não contemplando
métodos e relacionamentos com a oferta e necessidades dos clientes.
É prescritivo, contempla métodos e matrizes de relacionamentos.
04 Não contempla base de dados. Contempla base de dados open source para consulta e atualização.
# Modelo SAAD de Outsourcing de TI Modelo MOPP 01 O modelo compreende seis fases do
ciclo de vida de outsourcing, sendo elas: Tomada de decisão, RFI/RFP, negociação, transição, gestão da contratação e finalização.
Também contempla ciclo de vida, porém sob a visão do provedor de TI. Abrange algumas fases do modelo SAAD.
02 Modelo descritivo, não contemplando métodos e relacionamentos com a oferta e necessidades dos clientes
É prescritivo, contempla métodos e matrizes de relacionamentos.
03 Não está em base de dados Contempla base de dados open source para consulta e atualização.
04 Não é proprietário Não é proprietário # Modelo GSS-COBITIL Modelo MOPP
01 O modelo refere-se a suporte de serviços de TI e relacionamento entre ITIL, ISO 20000 e CobiT. Baseia-se fortemente na estrutura do CobiT para criação do meta-modelo COBITIL. São três os elementos do modelo: a) Método de criação de modelo de gerenciamento de serviços de TI; b) Modelo GSS – COBITIL; c) Método de Especialização do GSS- CobiTIL. O Autor sugere para trabalhos futuros relacionamentos com outros frameworks como PMI x ITIL.
O relacionamento entre os frameworks é realizado dentro do ciclo de vida de outsourcing e não diretamente entre os frameworks. A pesquisa não se restringiu a tapenas três frameworks, devido à sua abrangência ser bem maior do que apenas Suporte a Serviços de TI. O MOPP considera o método de especialização por tipo de necessidade do mercado. Não contempla um meta-modelo para criação de outros métodos. O objetivo é flexibilizar a vinculação e a prescrição de métodos, frameworks de prescrições dentro de um ciclo de vida de outsourcing de TI na visão do provedor de TI.
02 Modelo descritivo, não contemplando métodos e relacionamentos com a oferta e necessidades dos clientes
É prescritivo, contempla métodos e matrizes de relacionamentos.
03 Não está em base de dados Contempla base de dados open source para consulta e atualização.
04 Não é proprietário Não é proprietário 05 O meta-modelo do COBITIL é
altamente dependente das versões dos frameworks do mercado
Não é dependente das versões de mercado.
06 Trata-se de um modelo baseado na estrutura do CobiT, combinado com o ITIL e ISO 20000.
Estrutura principal baseada no ciclo de vida clássico de outsourcing, porém com um detalhamento, prescrições, métodos e matrizes originais.
07 Tese de Doutorado em Engenharia Elétrica na Escola Polítécnica da USP.
Tese de Doutorado em Engenharia de Produção no PPGEP – FEAU – UNIMEP.
75
Quadro 9 – Comparação MOPP x INNO-IT # Modelo INNO-IT
Modelo MOPP
01 Modelo que objetiva a inovação em serviços de TI
Abrange um ciclo de vida, abrangendo além de inovação, todos os processos necessários para a oferta e operação de serviços de TI
02 Utiliza o Cobit como base para montagem do modelo.
Utiliza os frameworks mais conhecidos do mercado para montagem do modelo.
03 Modelo descritivo, não contemplando métodos e relacionamentos com a oferta e necessidades dos clientes
É prescritivo, contempla métodos e matrizes de relacionamentos.
04 Não está em base de dados Contempla base de dados open source para consulta e atualização.
05 Não é proprietário Não é proprietário 06 Tese de Doutorado em Gestão de
Sistemas de Informações da Universidade de Praga
Tese de Doutorado em Engenharia de Produção no PPGEP – FEAU – UNIMEP
O quadro 5 compara o MOPP com o e-SCM/SP que é um modelo integrado de
outsourcing da Universidade Carnegie-Mellon.. O Quadro 6 faz a comparação com o
ISF da ISD/PUC-RS e com o GSD da Tata Consultancy Services. Já no quadro 7,
pode ser visto a comparação com o framework IF da Infosys. O quadro 8 compara o
MOPP com o PMS do Gartner, Modelo Saad e o CobiTIL, este último desenvolvido
na Universidade de São Paulo. Para finalizar, o quadro 9 mostra a visão MOPP x
Inno-IT, modelo desenvolvido na Universidade de Praga.
Avaliando o MOPP em relação aos demais modelos, as principais vantagens são:
− Não proprietário;
− Prescritivo;
− Ciclo de vida de outsourcing;
− Base de dados para armazenar os dados do modelo;
− Escalável, podendo ser melhorado;
− Não proprietário.
O principal avanço em relação aos modelos atuais é o fato de ser uma pesquisa
científica que contempla uma modelagem das situações reais do mercado de oferta
e operação de outsourcing de TI. Pode ser utilizado na iniciativa privada, com poucas
adaptações e sem custo de licenciamento.
76
O MOPP foi inspirado em modelos utilizados pelas empresas nas décadas de 1980,
1990 e na década de 2000, conforme Quadro 10. O objetivo é situar o modelo no
tempo, bem como sua contribuição em relação a outras iniciativas.
Quadro 10 – Comparação MOPP x Modelos de Combinação de Práticas
Ano Fato Relevante em Combinação de Práticas Responsável 1985
Processos de Software
Criação de Modelo de Maturidade de Processos de Software - CMM
CMU / SEI
1989 Serviços de TI
Criação de Modelo de Gerenciamento de Serviços de TI - ITIL
OGC
1993 Processos de
Software
Criação de um padrão de melhores práticas para maturidade de processos de software – ISO 15504
ISO
1996 Auditoria TI
Lançamento da versão inicial do CobiT dirigido a auditoria de sistemas.
ISACA
2000 Processos de
Software
Lançamento do CMMI, substituindo o CMM CMU / SEI
2000 Serviços de TI
Atualização do Modelo de Gerenciamento de Serviços de TI - ITIL v2
OGC
2002 Norma Serviços
de TI
Lançamento da norma BS 15000 para Gerenciamento de Serviços de TI
BSI
2004 Gerenciamento de
Projetos
Lançamento da versão 3 do PMBok., Guia de Referência de Melhores Práticas de Gerenciamento de Projetos do PMI
PMI
2004 Gerenciamento de
Outsourcing.
Criação de modelo de gerenciamento de outsourcing, específicos de provedores de serviços de TI e também em clientes. eSCM/SP e eSCM/CL.
CMU / ITSQB
2005 Governança de TI
Lançamento da versão 4.1 do CobiT e manuais suplementares com visão completa de Governança de TI.
ISACA / ITGI
2005 Serviços de TI
Criação da norma ISO 20000, substituindo a norma BS 15000.
ISO
2006 Segurança da
Informação
Criação da norma ISO 27001 e ISO 27002 substituindo a as normas BS 7799-1 e ISO 17799.
ISO
2007 Ciclo de Vida de
Serviços
Lançamento do ITIL v3, substituindo o ITIL v2. O objetivo passou a ser de ciclo de vida de serviços de TI.
OGC
2007 Combinação de
Frameworks
Desenvolvimento do modelo GSS-COBITIL como framework de tese de doutorado – Engenharia Elétrica – Sistemas Digitais - USP
Sergio Clemente
2006 /2008 Combinação de
Frameworks
Desenvolvimento de modelos por universidades, empresas e entidades do mercado , combinando práticas. ISF, IF, GSD, ITGI, COBITIL, INNOIT e outros.
Infosys, TCS, ISACA,
USP, UPraga CONTRIBUIÇÃO DESTE TRABALHO
2009 Modelo prescritivo
específicos em Combinação de
Práticas de Frameworks,
matrizes e base de dados.
Desenvolvimento do modelo MOPP direcionado não apenas em combinação de frameworks como solução, mas também relacionando estes frameworks, suas práticas dentro de um ciclo de vida de outsourcing, métodos, matrizes de relacionamento para oferta e operação, aplicação e base de dados para consulta e atualização.
Gilmar Santos FEAU-PPGEP
UNIMEP
77
A figura 21 apresenta uma evolução de frameworks e modelos integrados, iniciando-
se na década de 80 com o CMM.
Figura 21 – Evolução dos Frameworks e Modelos Integrados
O ITIL surgiu em 1989/1990 como um conjunto de melhores práticas em serviços de
TI. Na sequência, em 1995, o CobiT foi desenvolvido inicialmente para ser um guia
de auditoria, tornando-se depois um framework completo de Governança e Auditoria
de TI. No ano 2000 foi lançado uma evolução do modelo CMM, denominado CMMI.
Além de integrar os diversos modelos anteriores, outra mudança do CMMI em
relação ao CMM foi a possibilidade de utilização de duas diferentes abordagens para
a melhoria de processos: contínua e por estágio. Em 2004, foi lançada o e-SCM
contendo as melhores práticas em gestão de outsourcing. Na sequência, a ISO
20000 foi lançada em 2005, com foco na certificação das empresas em qualidade de
serviços de TI
A partir de 2007 começaram a surgir os modelos integrados, de forma mais
consistente e baseados em melhores práticas do mercado. Neste contexto, foram
aperfeiçoados os modelos ISF da ISD e o GSD da TCS, além de surgirem trabalhos
acadêmicos concentrados nessa área. Dentro desse histórico, o modelo MOPP
começou a ser desenvolvido, visando uma contribuição nesse campo de pesquisa,
sendo concluído em 2010.
78
O desenho do modelo foi implementado em uma aplicação web, desenvolvida sob
software livre utilizando plataforma Java 6 com banco de dados PostgreSQL. No
Apêndice A são apresentadas as funcionalidades e um roteiro de instalação da
aplicação bem como os critérios da seleção de software livre (open source). Como
referência de documentação do MOPP, utilizou-se o padrão Process Handbook do
MIT (http://process.mit.edu), conforme o MIT (2009).
Figura 22 – Fluxo Macro do Modelo MOPP
Com base nos requisitos do cliente, o modelo contempla as etapas da gestão da
contratação, gestão de projetos de implantação (transição), gestão da operação,
projetos de demandas eventuais, governança de TI, qualidade, conhecimento &
inovação e segurança da informação, conforme mostrado na figura 22.
3.1. Gestão de Contratação
O macro-processo Gestão de Contratação envolve inteligência de mercado,
qualificação de propostas, elaboração, apresentação de propostas técnicas,
propostas comerciais e contratação, conforme figura 23. É importante observar
cada processo da Gestão de Contratação e nas questões: o que isto significa em
termos de atividade, o que é realizado em cada uma das fases e também o que é
necessário para passar à fase seguinte. O ciclo de vida de venda de serviços e
79
produtos de software apresenta diferenças, inclusive em termos de faturamento. A
obtenção de receitas com produto é realizada geralmente na entrega e aceite pelo
cliente. Uma análise de mercado é importante para a definição da melhor estratégia
para a oferta de serviços e produtos, quais sejam: a) Preço baixo; b) Diferenciação;
c) Foco. Em uma estratégia de preço baixo, o provedor decide posicionar-se no
mercado oferecendo produtos e serviços competitivos. Em uma estratégia de
diferenciação, o provedor oferece produtos e serviços de qualidade superior. Na
estratégia de foco, o provedor escolhe um segmento de mercado específico e se
concentra nele. Uma empresa que desenvolve soluções utilizando conceitos de
cloud computing (computação nas nuvens) ou software para smartphones é um
exemplo desta estratégia.
Figura 23 – Ciclo de Vida da Contratação
Os processos envolvidos nesta fase são direcionados para o estudo do mercado,
propostas e contratos, conforme abaixo:
− Inteligência do Mercado;
− Prospecção;
− Qualificação;
− Proposta Técnica;
− Precificação e Proposta Comercial;
− Negociação e Contratos.
80
3.1.1. Inteligência de mercado
Nesta parte do modelo o provedor atua dentro do conceito de inteligência
competitiva, iniciando-se pela análise de concorrência no mercado de TI. Assim que
os concorrentes são identificados, o provedor deve descobrir suas características,
especificamente suas estratégias, seus objetivos, suas forças e fraquezas e seus
padrões de reação. Utilizar-se dos conceitos de estratégia competitiva apresentados
no referencial teórico, particularmente os princípios da análise externa e também das
forças competitivas de Porter, é fundamental nesta etapa do processo. Outro
aspecto importante do referencial teórico utilizado nesta parte do modelo é a análise
do mercado.
A avaliação do Magic Quadrant do Gartner (guia mundial para comparação de
produtos, serviços e empresas líderes do mercado de tecnologia da informação)
auxilia na análise dos principais players (competidores) de TI no mercado mundial.
Uma análise das empresas que possuem certificações como também dos modelos
de outsourcing utilizados serve como base para estabelecimento de estratégia de
oferta de serviços e produtos de TI. O provedor deve inicialmente estabelecer os
principais tipos e fontes das informações competitivas. Coletar os dados, avaliá-los,
analisá-los e disseminar as informações dentro da organização. Os principais
clientes internos desta informação são as áreas comerciais e também as equipes de
pré-vendas, envolvidas na elaboração de propostas técnicas e comerciais.
O modelo MOPP recomenda que exista um catálogo de serviços direcionado a
vendas do provedor de TI. Significa um conhecimento por toda a empresa do
portfolio de serviços, com suas respectivas características. O modelo considera que
esta informação vai além do conceito de offerings (documentação da oferta de
serviços). Todos os catálogos de serviços utilizados na operação devem ser
herdados deste catálogo de vendas.
81
O processo de inteligência de mercado utiliza-se de componentes de práticas e
templates, conforme o quadro 11.
Quadro 11 – Processo de Inteligência do Mercado
# Framework/Processo/Template Aplicação no Modelo MOPP
01 e-SCM - Cnt08 – Informações de
Mercado
Estabelecer procedimentos para coletar e disseminar
internamente as informações do mercado para o
provedor de TI.
02 ITIL V3 SE – Desenvolvimento da
Oferta de Serviços
Estabelecer os requisitos para o desenvolvimento da
oferta do provedor, incluindo mercado, portfolio dos
serviços e resultados esperados.
03 Template - Formulário Inteligência
Mercado
Uso interno do provedor para armazenamento das
informações do mercado.
3.1.2. Prospecção de Mercado
O objetivo deste processo é a busca de novos clientes e oportunidade de negócios.
Funciona por meio de editais publicados, sondagens junto a empresas clientes e não
clientes como também expectativa de novos negócios. O processo de prospecção
de mercado utiliza-se de componentes de práticas e templates, conforme quadro 12.
Quadro 12 – Prospecção do Mercado
# Framework/Processo/Template Aplicação no Modelo
01 e-SCM - Cnt08 – Informações de Mercado Este processo pode ser utilizado para
estabelecer procedimentos de informações do
mercado.
02 Template - Formulário Inteligência Mercado Utilizado para uso interno do provedor com base
na prática eSCM para captura de informações.
82
3.1.3. Qualificação da Oportunidade
A qualificação no modelo envolve uma análise pelo provedor de TI de que a
oportunidade de negócio pode ser viável a partir das suas competências. Isto
significa combinar suas capacidades para fornecer algum serviço ou produto.
Conforme Prahalad e Hamel (1990), os recursos podem não propiciar vantagem
competitiva. Podem ser a fonte de uma vantagem competitiva quando são
integrados em uma capacitação. Se a oportunidade aplicar-se a uma competência
como suporte a infraestrutura de TI, por exemplo, e o provedor possuir esta
competência e avaliar que o mercado em termos de concorrência é viável, a
oportunidade é internalizada.
O processo de qualificação da oportunidade utiliza-se de componentes de práticas e
templates, conforme quadro 13. No modelo MOPP um fator crítico de sucesso para
as fases de propostas técnicas e comerciais é a definição de níveis de serviços
(SLA) de pré-venda entre todos os participantes das atividades. Este acordo deve
ser assinado na fase de qualificação, garantindo que as informações consigam
trafegar com consistência, agilidade e com qualidade dentro do provedor, para a
elaboração de uma proposta competitiva.
Quadro 13 – Qualificação da Oportunidade
# Processo/Template Aplicação no Modelo MOPP
01 e-SCM - Cnt08 – Informações de
Mercado
Este processo pode ser utilizado para estabelecer
procedimentos da qualificação com relações às
informações de mercado.
02 e-SCM - Cnt03 – Confirmações das
condições atuais
Confirmar as premissas necessárias para avaliação
da oportunidade.
03 e-SCM - Cnt06 – Obter informações
adicionais
Documentar os requisitos do cliente para de forma
exata para apurar análise de oportunidades.
04 Template - Formulário Qualificação
Oportunidade
Utilizado para qualificação e internalização da
oportunidade.
83
3.1.4. Proposta Técnica
Tem a função de preparação de proposta técnica e comercial de forma a atender as
necessidades do cliente. A proposta deve contemplar as respostas à RFP exigidas
pelo cliente, como também anexar as certificações e atestados técnicos necessários
para pontuação, conforme mostrado no quadro 14.
Quadro 14 – Exemplo de Relação de Certificações Exigidas em Propostas
CMMI ISO 20000 ISO 27001 SAS 70
ISO 9001 ISO 14001 eSCM COBIT V4.1
ITIL V3 CISA CISM / CISSP CSQE / CSTE
PMP / IPMA CQPA / CQIA CSSGB / CSSBB JAVA / .NET
CISCO MCSE / MCP AIX / HP UX OMG UML
Normalmente, a proposta técnica envolve a utilização de padrões definidos pelo
cliente. Na ausência destas determinações, podem ser utilizados padrões do modelo
MOPP. Os processos e templates estão descritos no quadro 15.
Quadro 15 – Proposta Técnica
# Processo/Template Aplicação no Modelo
01 e-SCM - nt06 – Obter informações
adicionais
Documentar os requisitos do cliente para de
forma exata apurar análise de oportunidades.
02 PMI/PMBoK - Gerenciamento de Aquisição Determinação do tipo de oferta (unitário,
global ou administração).
03 Template - Modelo de Resposta a RFI
(Request for Information)
Preenchimento de resposta às solicitações de
informações do cliente.
04 Template - Modelo de Resposta à RFP
(Request for Proposal)
Modelo para preenchimento de proposta
técnica
84
3.1.5. Proposta Comercial e Precificação
Na proposta comercial deve ser considerado o dimensionamento de todos os
recursos. Estes itens são precificados e incluídos na proposta comercial. A
precificação deverá ser realizada com base em preço fixo, preço unitário ou preço
por administração. Devem ser considerados os impostos e todas as situações
prevendo projetos especiais ocasionados por demandas eventuais ou movimentação
de baseline durante a operação. A forma de pagamento e demais condições
comerciais também são atividades deste processo. Um exemplo de negociação é a
entrega dos serviços com pagamento antecipado.
Os processos e templates para este processo são mostrados no quadro 16.
Quadro 16 – Precificação e Proposta Comercial
# Processo/Template Aplicação no Modelo MOPP
01 e-SCM - Cnt02 – Precificação Criar um padrão de precificação para a
proposta comercial.
02 e-SCM - Cnt08 – Responder aos Requisitos
do Cliente
Responder aos requisitos do cliente
03 e-SCM - Cnt07 – Revisar os requisitos do
cliente
Realizar uma avaliação (QA) da proposta.
04 CobiT PO05 - Gerenciamento de
Investimentos em TI
Alocar orçamento e recursos financeiros para
os investimentos na proposta.
05 Templates - Proposta Comercial Preenchimento da Proposta Comercial.
06 Templates - Modelo de Precificação Modelo de precificação para as propostas.
Como complementação dos processos e templates prescritos para a proposta
comercial, é apresentado a seguir um método quantitativo para bonificações e
penalidades em oferta de serviços de TI.
85
Método de Bonificações (gainsharing) e Penalidades (penalty)
No modelo MOPP, devem ser estabelecidos na proposta comercial os requisitos
para gainsharing (compartilhamento de ganhos) e penalidades. O objetivo principal é
minimizar o problema de multas e bonificações de forma total sobre o valor do
faturamento. Um exemplo disto é uma SLA atingida de 94,9% contra uma meta de
95,0%. No modelo MOPP, a multa aplicada não seria por um percentual fixo e sim
de forma proporcional, conforme critérios determinados. É comum os clientes
exigirem redução de preços durante a vigência contratual. Neste caso, os aspectos
gerais desta redução estão previstos em contrato. A multa ou bonificação deve ser
aplicada sobre a fatura mensal do serviço. Um modelo para precificação de
gainsharing e penalidades é mostrado na tabela 3.
Tabela 3 – Método para gainsharing
Indicadores Valores Contratados
Acima do Contratado Muito Acima do Contratado
Severidades/Indicador META Percentual Pontos Percentual Pontos
1 Atend. Incidentes no prazo – prioridade alta
95% 96%-98% +3 99%-100% +4
2 Atend. Incidentes no prazo– média
92% 93%-98% +2 99%-100% +4
3 Atend. Incidentes no prazo - baixa
90% 91%-98% +1 99%-100% +4
4 Solicitação Serviços no prazo
95% 96%-98% +2 99%-100% +4
5 Disponibilidade 99% 99,1%-99,5%
+3 99,5%-99,9% +5
6 Satisfação Usuário 95% 96%-98% +4 99%-100% +7
7 Taxa de Abandono 10% 9%-4% +4 3%-1% +5
8 Suporte 1º. Nível 60% 61%-80% +2 81%-95% +7
9 Entrega Projetos no Prazo
90% 91%-95% +2 96%-100% +5
10
Mudanças Executadas com Sucesso
95% 96%-98% +2 99%-100% +5
TOTAL POSSÍVEL + 25 + 50
O somatório da pontuação é transcrito para a tabela 4. De acordo o total apurado
uma bonificação é adicionada ao contrato. Vale ressaltar que neste modelo podem
86
ser incluídos outros indicadores como, por exemplo, quantidade de incidentes.
Quanto menor o volume, maior a pontuação e maior será o gainsharing.
Outro aspecto importante é que o mesmo modelo pode ser aplicado para situação
de penalidades, invertendo-se os percentuais referentes a cada indicador e
estabelecendo pontuação conforme descrito na tabela 4.
Tabela 4 – Faturamento e Gainsharing
PT % FATURA
PT % FATURA
PT % FATURA
PT % FATURA
PT % FATURA
1 0,2 11 1,4 21 2,4 31 3,4 41 4,4
2 0,4 12 1,5 22 2,5 32 3,5 42 4,5
3 0,5 13 1,6 23 2,6 33 3,6 43 4,6
4 0,6 14 1,7 24 2,7 34 3,7 44 4,7
5 0,7 15 1,8 25 2,8 35 3,8 45 4,8
6 0,8 16 1,9 26 2,9 36 3,9 46 4,9
7 0,9 17 2,0 27 3,0 37 4,0 47 5,0
8 1,0 18 2,1 28 3,1 38 4,1 48 5,1
9 1,2 19 2,2 29 3,2 39 4,2 49 5,2
10 1,3 20 2,3 30 3,3 40 4,3 50 5,3
A proposta financeira, após finalizada, deve passar por uma análise de garantia de
qualidade e também por uma análise jurídica quando necessário, em conjunto com a
proposta técnica. Alguns elementos da análise envolvem valores do investimento,
fluxo de caixa, rentabilidade e termos financeiros como bonificações, penalidades e
condições de pagamento.
87
No modelo MOPP as cláusulas de penalidades são equivalentes ao do gainsharing,
mas de forma invertida, conforme tabela 5.
Tabela 5 – Proposta para penalidades
Indicadores Valores Contratados
Acima do Contratado Muito Acima do Contratado
Severidades/Indicador META Percentual Pontos Percentual Pontos
1 Atend. Incidentes no prazo – prioridade alta
95% 90%-94% -3 80%-90% -4
2 Atend. Incidentes no prazo – prior. média
92% 86%-91% -2 80%-85% -4
3 Atend. Incidentes no prazo – prior. baixa
90% 81%-90% -1 70%-80% -4
4 Solicitação Serviços no prazo
95% 92%-94% -2 90%-92% -4
5 Disponibilidade 99% 98,4%-98,9% -3 98,0%-98,3% -5
6 Satisfação Usuário 95% 92%-94% -4 90%-91% -7
7 Taxa de Abandono 10% 11%-15% -4 16%-18% -5º
8 Suporte 1º. Nível 60% 51%-59% -2 40%-50% -7
9 Entrega Projetos no Prazo
90% 85%-89% -2 80%-84% -5
10
Mudanças Executadas com Sucesso
95% 92%-94% -2 90%-91% -5
TOTAL POSSÍVEL - 25 - 50
Da mesma forma do gainsharing, as penalidades utilizam o somatório da pontuação
para determinar o percentual a ser aplicado sobre a fatura, conforme mostrado na
tabela 6.
88
Tabela 6 – Faturamento e Penalidades
PT % FATURA
PT % FATURA
PT % FATURA
PT % FATURA
PT % FATURA
1 0,2 11 1,4 21 2,4 31 3,4 41 4,4
2 0,4 12 1,5 22 2,5 32 3,5 42 4,5
3 0,5 13 1,6 23 2,6 33 3,6 43 4,6
4 0,6 14 1,7 24 2,7 34 3,7 44 4,7
5 0,7 15 1,8 25 2,8 35 3,8 45 4,8
6 0,8 16 1,9 26 2,9 36 3,9 46 4,9
7 0,9 17 2,0 27 3,0 37 4,0 47 5,0
8 1,0 18 2,1 28 3,1 38 4,1 48 5,1
9 1,2 19 2,2 29 3,2 39 4,2 49 5,2
10 1,3 20 2,3 30 3,3 40 4,3 50 5,3
O modelo MOPP prevê que a bonificação ou penalidade pelos níveis de serviços
abaixo ou acima da meta não deve considerar um único mês, mas sim uma média
dos últimos três meses anteriores à data do cálculo. A figura 24 mostra um exemplo
deste cálculo.
Figura 24 – Média Dinâmica – SLA Contratual
A média é dinâmica, contando sempre os três últimos meses. No exemplo exposto
na figura 24, a média de outubro, novembro e dezembro contou + 03 pontos no
primeiro quadro e – 03 pontos no segundo, resultados bem mais adequados do que
considerar cada mês de forma individual, pois considera se os resultados estão
89
sendo persistentes ao longo do tempo. O método pode ser também na situação do
SLA ter sido referente ao mesmo indicador (reincidência).
3.1.6. Negociação e Contrato
Essa é uma das fases principais do MOPP. Os contratos de outsourcing requerem
um processo de negociação, conforme visto em Kujala et al. (2008). O objetivo é
integrar todas as fases dentro de uma solução total. Existem duas perspectivas: a do
fornecedor e a do cliente. Existe uma troca constante de informações entre os dois,
desde a fase de preparação da proposta até o projeto de transição. Os projetos
deste tipo iniciam com a decisão de investimento do cliente e a busca de
oportunidades pelos provedores. A fase seguinte é de preparação, onde o cliente
prepara uma RFP e o fornecedor toma a decisão de participar da concorrência. Na
terceira etapa, o fornecedor envia a proposta para o cliente que seleciona quem irá
prestar o serviço. O Contrato é assinado na sequência e logo depois é
implementado por meio de um projeto de transição, onde são definidos os modelos
de operação, governança e níveis de serviços do contrato.
Uma questão fundamental no relacionamento entre provedores de TI e clientes é a
percepção clara que os valores mudam ao longo do contrato. Em um primeiro
momento existe uma preocupação em redução de custos, porém mudanças ocorrem
e o provedor de TI deve estar preparado para entregar outros diferenciais como
qualidade e inovação. O cliente está preocupado inicialmente em uma TI mais
eficiente do ponto de vista financeiro, motivo pelo qual ele busca uma terceirização,
tentando no mínimo manter a qualidade atual. Após ganhar a concorrência o
provedor inicia a implantação do contrato, colocando em prática o que foi acordado.
Conforme Kujala et al. (2008), do ponto de vista estratégico, o processo de
outsourcing é iniciado antes mesmo da colocação e resposta a uma RFP (Request
for Proposals).
Conforme figura 25, em um relacionamento longo, o outsourcing de TI inicia-se com
uma percepção da alta direção do cliente de que a TI representa uma função non-
core ou não principal do negócio (WEEKS et al., 2008). Na realidade é enxergada
como uma commodity, onde os custos precisam ser reduzidos por meio de
90
contratação de um provedor de TI externo. Os contratos geralmente são ganhos
neste aspecto (custo), ou seja, quando o cliente tem a evidência que poderá reduzir
os custos de TI do serviço em uns 20%, por exemplo. Existem riscos para futuras
iniciativas de qualidade e inovações nesta fase inicial. Pode ocorrer redução de
motivação para inovar por parte das unidades de negócios, já que todo contato com
o provedor de TI passa a ser do CIO (Chief Information Officer ou Diretor de
Informática) e da sua área de TI. O provedor de TI, por sua vez, fica com o desafio
de manter o contrato rentável apesar das pressões do cliente em redução de custos.
Convive-se, em alguns casos, com infra-estrutura do cliente muito desatualizada e
equipe do contrato altamente enxuta, o que eleva ainda mais a pressão. O
relacionamento é dominado neste ponto por constantes negociações em torno de
escopo e custo acordado, não sobrando tempo para mais nada, além de manter o
operacional rodando.
Figura 25 – Valores no Relacionamento de Outsourcing
Fonte: adaptado de Weeks et al. (2008, p. 133)
Em uma segunda fase, ocorre uma insatisfação compartilhada entre provedor e
cliente com a fase anterior. Neste aspecto, os objetivos de aumento de qualidade
são requisitados para que a TI possa estar mais orientada ao negócio. O cliente está
disposto a rever as capacidades de TI como também negociar quais são os recursos
ideais para prestação dos serviços. O provedor avalia quais as melhores plataformas
de práticas, processos, hardware e software para aumento da qualidade e quem
poderá financiá-los. Temas como best practices e benchmarking são citados com
frequência. Um exemplo disto é a implantação da ISO 20000 ou de uma ISO 9001
em um contrato de um provedor de TI de porte mundial.
91
Em uma terceira e última fase existe uma clara preocupação em adicionar valor ao
negócio do cliente por meio de inovações. No mercado, existem exemplos como
automação de processos de negócios, introdução de um método de medição/reporte
de TI baseado em metas do negócio (ex. Lean Six Sigma ou Balanced Scorecard),
uma solução efetiva de resolução de problemas, portal de conhecimento para
colaboração, busca de soluções por toda a empresa, uma base de dados de
configurações (CMDB), integrada de forma automatizada com demais bases de
dados de negócios e de sistemas. Tudo isto alinhado com o negócio do cliente.
A sequência apresentada (custo, qualidade e inovação) deve ser bem gerenciada
nesta etapa de negociação e contrato do modelo. Não adianta tentar implantar no
inicio do contrato um serviço inovador, quando isto representará aumento de custo
não suportado pelo contrato e difícil de negociar (principalmente em época de crise
financeira). Também não se deve insistir apenas na redução de custos e na
implantação de uma simples documentação dos processos sem pensar em
qualidade e inovação. No longo prazo (acima de dois anos), isto não se sustenta,
podendo levar à perda do contrato em clientes mais exigentes. Existe um desafio e
pressão para os provedores de TI reduzirem custos e ao mesmo tempo aumentar
valor dos contratos por meio da qualidade e inovação, tudo isto em um tempo cada
vez mais curto. Eliminar este trade-off será um desafio constante. O modelo MOPP
pressupõe que a contratação de um provedor não deve levar em consideração,
exclusivamente, o critério de menor preço. Além disso, a remuneração futura não
pode variar em função da redução de preço que o cliente conseguiu com o provedor
que já ofereceu o menor valor. Pelo modelo, os provedores devem empregar sempre
profissionais qualificados e competentes para a oferta de produtos e serviços
consistentes, que permitam manter os níveis de serviços acima do contratado.
A etapa de negociação e contratos envolve aspectos como a negociação para inicio
do plano de transição e condições de assinatura do contrato. Também sugere
processos de due diligence em que o provedor examina previamente os riscos e
condições associadas a uma negociação antes que o formato final do negócio seja
estabelecido. O provedor deve levantar informações de forma a avaliar o nível de
risco e as informações disponíveis com relação à operação dos serviços. Considera
92
questões como estrutura das funções a serem terceirizadas, Recursos Humanos,
recursos de TI, serviços e suprimentos. Após o due diligence o provedor e o cliente
devem classificar o que foi encontrado nos seguintes aspectos:
− Itens acordados previamente que foram confirmados na due diligence;
− Itens acordados previamente que foram considerados incorretos, podendo reabrir
um processo de negociação;
− Itens novos identificados como relevantes;
− Itens cuja evolução ao longo da operação é desconhecida e que poderá impactar
no desempenho do provedor;
Alguns tipos de contratos restringem-se a cláusulas jurídicas, remetendo as
condições de operação, governança e comerciais para a proposta técnica e
comercial. Outros tipos de contratos exigem negociação para a elaboração do seu
conteúdo, a exemplo do escopo do serviço, níveis de serviço, SLA,
responsabilidades, penalidades, gainsharing, prazo, composição da equipe, espaço
físico, equipamentos, propriedade intelectual, condições de rescisão. Um aspecto
importante que deve ser considerado na assinatura do contrato são as condições
para a execução do plano de transição. Recomenda-se no modelo MOPP que a
assinatura do contrato seja realizada após a execução do plano de transição.
Ao longo da vida útil do contrato é importante uma renegociação para mantê-lo
atualizado, diante das mudanças de cenário na operação dos serviços. Visa proteger
o provedor de eventos como demandas eventuais em excesso, oscilação fora do
normal da demanda dos serviços, novos serviços, aumento da quantidade de
usuários previstos no baseline inicial e outros aspectos importantes para proteger o
relacionamento do outsourcing.
93
Os processos e templates para este processo estão descritos no quadro 17.
Quadro 17 – Negociação e Contratos.
# Processo/Template Aplicação no Modelo MOPP
01 e-SCM - Cnt09 – Regras Contratuais Criar um padrão de precificação para a
proposta comercial.
02 e-SCM - Cnt10 – Criação do Contrato Responder aos requisitos do cliente
03 e-SCM - Cnt11 – Assinatura do Contrato Realizar uma avaliação (QA) da
proposta.
04 ISO 20000 - Gerenciamento de Níveis de Serviços Determinar as condições dos níveis de
serviços para o contrato
05 ITIL V3 - Gerenciamento de Níveis de Serviços Determinar as condições dos níveis de
serviços para o contrato
06 IPMA - Aquisições e Contratos Define requisitos para a negociação e
elaboração de contratos.
07 Template - Modelo de Contrato Modelo de contrato de outsourcing
08 Template - Modelo de Due Diligence Modelo para realização de due
diligence
94
3.2. Gestão do Projeto de Implantação dos Serviços
O macro-processo Gestão de Projeto de Implantação envolve a transição da
operação do contrato para o provedor que ganhou a proposta. Refere-se também a
abordagem a ser utilizada pelo provedor para a migração das atividades do escopo
de serviços relacionados com a RFP. Envolve aspectos como:
− Transição da gestão que consiste na transferência das responsabilidades da
gestão da operação dos serviços contratados do cliente ou do provedor atual
para o novo provedor;
− Execução de projeto de transição para determinação do modelo de operação e
de governança do contrato, conforme estabelecido no processo de negociação e
contrato.
Nesta etapa do ciclo de vida, o modelo MOPP segue algumas fases a exemplo de
Plano de Mobilização, Preparação, Tomada do Controle e Estabilização para o
Plano de Transição, conforme figura 26. Pode envolver também a alocação de
especialistas nos diversos assuntos da RFP para a implantação dos serviços (ex.
Recrutamento, Treinamento, Mudanças Organizacionais, Governança, Operação,
Infraestrutura e Comunicação).
Figura 26 – Ciclo de Vida do Projeto de Implantação
95
Os processos envolvidos nesta fase são direcionados para a implantação dos
projetos de forma a garantir uma operação de sucesso, abrangendo: Plano de
Projeto; Mobilização e Recursos Humanos; Modelo de Operação; Modelo de
Governança; Tomada de Controle; Lições Aprendidas e Kick-off
3.2.1. Plano de Projeto
Cada etapa do projeto de transição está contemplada no plano do projeto. Trata-se
de um plano geral para a execução das atividades do projeto de implantação.
Abrange uma montagem de um planejamento baseado nas melhores práticas (ex.
PMI e IPMA), alocando profissionais especializados para cada uma das atividades
contratadas. Envolve também elaboração de cronogramas, gestão do escopo,
integração, atividades do PMO, gestão de riscos e de comunicação. No modelo
MOPP o plano contém os seguintes aspectos:
− Plano de capacitação da equipe da operação;
− Plano de Mobilização, Contratação de pessoal;
− Plano de Handover e de Shadow (transferência de conhecimento);
− Plano de absorção das pessoas;
− Plano de comunicação;
− Plano de Gerenciamento de Riscos;
− Plano para elaboração do Modelo de Operação;
− Plano para elaboração do Modelo de Governança;
− Plano de Cut Over (entrada em operação).
Os processos e templates para este processo estão descritos no quadro 18.
96
Quadro 18 – Processo Plano de Projeto
# Processo/Template Aplicação no Modelo MOPP
01 ESCM - Sdd02 – Projeto e Implantação
do Serviço
Estabelecer processos e procedimentos para
implantação dos serviços
02 ESCM - Cnt10 – Plano do Projeto e da
Implantação
Planejar e acompanhar a implantação do Plano de
Projeto
03 PMBoK – Gerenciamento de Integração Realizar uma avaliação (QA) da proposta. Abrange
também todas as change request (mudanças).
04 PMBoK – Gerenciamento de Escopo Determina como será realizada a verificação do
escopo, para que o projeto de transição não fique
incompatível com o que foi contratado.
05 PMBoK – Gerenciamento do Tempo Elaboração de cronograma e formato de
acompanhamento das atividades quanto às suas
datas de entregas.
06 PMBoK – Gerenciamento de Riscos Determina um plano de riscos para a execução do
plano de transição, como também os riscos
envolvidos com a operação.
07 PMBoK – Gerenciamento de
Comunicação
Determina as formas de comunicação entre o
provedor e o cliente durante todo a etapa de
transição e também durante a operação.
08 PMBoK – Gerenciamento de Recursos
Humanos
Determina como será realizada a absorção dos
profissionais e os treinamentos necessários.
09 IPMA – Gestão de Conhecimento em
Projetos
Diretrizes para a Gestão de Conhecimento do
plano de transição
10 OPM3 – Gestão de Programa em
Projetos
Determinar as atividades do Escritório de Projetos
11 Template - Modelo de Plano de Projeto Modelo para a elaboração de um plano de projeto
12 Template - Modelo de Cronograma Cronograma para uso na transição
13 Template - Modelo de
Acompanhamento de Riscos
acompanhamento dos riscos do projeto de
transição.
97
3.2.2. Mobilização do Plano de Transição (As is)
Esta fase normalmente tem duração de um mês. Consiste em assegurar que os
objetivos, premissas e escopo detalhado do projeto sejam entendidos plenamente
pela equipe do provedor de TI. O modelo MOPP prevê o entendimento dos modelos
de processos e governança utilizados atualmente pela operação atual. Com isto a
equipe de transição terá os elementos essenciais para o trabalho de mobilização,
que consiste em disponibilizar a equipe da operação, definir os modelos de
operação / governança e executar as atividades do plano de comunicação e
gerenciar os riscos. Durante o levantamento da situação atual devem ser conhecidos
os modelos de operação e gestão em uso corrente no cliente, para suportar as
operações dos serviços contratados.
Também abrange a mobilização dos recursos para a operação, como também a
estrutura preparada para a mudança que se inicia. Sob a ótica técnica, a
Mobilização trata de comunicar os stakeholders sobre a mobilização, gerenciar os
riscos inerentes, contratar e mobilizar a equipe do provedor para o projeto, e
desenvolver o plano de cut over. No modelo, é nesta etapa que ocorre a
disponibilização dos recursos tecnológicos e do apoio necessário à condução do
projeto. Inclui aspectos fundamentais, mas por vezes negligenciados, como
assegurar que os ambientes de trabalho facilitem a comunicação e a integração
entre os membros das equipes.
Os processos e templates são mostrados no quadro 19.
98
Quadro 19 – Mobilização do Plano de Transição
# Processo/Template Aplicação no Modelo MOPP
01 e-SCM/SP - Del01 – Planejamento
Entrega dos Serviços
Princípios para o planejamento da entrega dos
serviços.
02 e-SCM/SP - Del02 – Treinamento
do Cliente
Diretrizes para treinamento da equipe do projeto,
operação e também para o cliente.
03 e-SCM/SP - Del07 – Modificação
de Serviços
Determina requisitos para a gestão de mudanças no
plano de transição.
04 e-SCM/SP - Trf91 – Absorção de
Recursos
Diretrizes para transferência de recursos do cliente ou
de provedores anteriores para o provedor atual.
05 CobiT P02 – Definir Arquitetura de
Informação
Diretrizes de arquitetura de informação para a
operação.
06 CobiT P03 – Definir Diretrizes
Tecnológicas
Determinar diretrizes para arquitetura tecnológica de
um plano de transição.
07 CobiT P03 – Definir Processos,
Estrutura e Relacionamentos em TI
Determinar o que deve ser considerado na elaboração
de processos, estrutura e relacionamento entre
provedor e o cliente no modelo de governança.
08 CobiT P07 – Gerenciar RH Determina as formas de comunicação entre o
provedor e o cliente durante todo a etapa de transição
e também durante a operação.
09 IPMA – Negociação e Reuniões Determina aspectos gerais para negociação em
projetos, report e reuniões.
10 ISO 20000 – Sistema de Gestão Sistema de gestão incluindo responsabilidade da
direção, requisitos de documentação, treinamentos e
conscientização para a gestão do plano.
11 ISO 9001 - Projetos Requisitos para a qualidade na gestão de projetos no
plano de transição.
12 Template - Modelo de As Is de
Projetos de Transição
Modelo para entendimento da situação atual do
Modelo de Operação e de Governança
13 Template - Modelo de Plano de
Treinamento
Modelo de um Plano de Treinamento para uso em
projeto de transição.
99
3.2.3. Modelo de Operação
No modelo MOPP, refere-se aos mecanismos que permitem garantir os níveis de
gestão para os diversos tipos de serviços que foram estipulados na proposta técnica.
Para realizar a gestão e acompanhamento dos serviços de Operação, que
compreende os serviços contratados, o provedor deve partir do pressuposto do tripé
processos, tecnologia e pessoas. Esta etapa do modelo envolve desenho do modelo
futuro de operação, passando por mapeamento e validação dos processos alinhados
com o cliente.
A equipe da operação deverá ser capacitada nestes novos processos. O provedor
pode sugerir as suas ferramentas tecnológicas ou utilizar ferramentas do cliente,
dependendo do que foi estipulado no contrato. Nesta fase todas as oportunidades de
melhoria dos processos devem ser consideradas. Envolve, inclusive, a montagem de
um catálogo de serviços e dos fluxos e documentação dos processos operacionais,
a serem utilizados pela equipe da operação. O catálogo deve ser baseado em cada
serviço escopo da proposta técnica.
O modelo pressupõe que a metodologia a ser utilizada siga os padrões
estabelecidos no MOPP ou metodologias próprias do provedor alinhadas com este
modelo. Importante alinhar as metodologias de operação com as do cliente, para
que ocorra sinergia entre os processos. Os processos e templates são mostrados
no quadro 20.
100
Quadro 20 – Modelo de Operação
# Processo/Template Aplicação no Modelo MOPP
01 eSCM/SP - Sdd04 – Especificação
dos Serviços
Princípios para o planejamento da entrega dos serviços.
03 eSCM/SP - Sdd07 – Verificação do
Serviço
Determina requisitos para a gestão de mudanças no
plano de transição.
04 eSCM/SP - Sdd08 – Implantação
do Serviço
Determina requisitos para a gestão de mudanças no
plano de transição.
06 CobiT P02 – Definir Arquitetura de
Informação
Diretrizes para a arquitetura de informação para a
operação.
07 CobiT P03 – Definir Diretrizes
Tecnológicas
Determina diretrizes para arquitetura tecnológica de um
plano de transição.
08 CobiT P04 – Definir Processos,
Estrutura e Relacionamentos em TI
Determina o que deve ser considerado na elaboração
de processos, estrutura e relacionamento entre
provedor e o cliente.
09 Cobit DS11 – Gestão de Dados Diretrizes para o gerenciamento dos dados relacionados
com a operação dos serviços.
10 CobiT DS12 – Gestão de Ambiente
Físico
Diretrizes para o gerenciamento da infraestrutura
necessária para o serviço.
11 CobiT DS13 – Gestão de
Operações
Diretrizes para o gerenciamento da operação do
serviço.
12 ISO 20000 – Sistema de Gestão Sistema de gestão incluindo responsabilidade da
direção, requisitos de documentação, treinamentos e
conscientização para a gestão do plano.
14 ITIL V3 – Operação de Serviços –
Gestão de Incidentes, Solicitações,
Eventos, Problemas e Service
Desk,
Práticas para gestão de incidentes, solicitações de
usuários, monitoramento, análise de causa raiz,
resolução de problemas e atendimento primeiro nível ao
usuário, necessários para o modelo de operação.
19 Template - RDM – Requisição de
Mudança
Modelo de Requisição de Mudanças para utilização na
fase de operação dos serviços
20 Template - Catálogo de Serviços Modelo de Catálogo de Serviços
101
3.2.4. Modelo de Governança
O objetivo desta etapa do modelo é de garantir que a oferta e operação de
outsourcing suportem os objetivos e estratégias de negócio dos serviços
contratados, adicionando valor por meio dos serviços entregues, balanceando os
riscos e obtendo o retorno sobre os investimentos realizados nas atividades escopo
do sérico contratado do provedor. A construção de um Modelo de Governança das
atividades escopo dos serviços nas fases de Transição e Execução tem como
principais benefícios para o cliente:
− Confiança do cliente e dos usuários nos serviços prestados;
− Contrato totalmente comprometido com o Negócio;
− Garantia do Retorno sobre o Investimento (ROI);
− Serviços mais confiáveis;
− Maior transparência.
Enquanto o Modelo de Operação fornece os serviços e produtos que fazem parte do
contrato de forma eficiente e eficaz, o Modelo de Governança se preocupa no
desempenho do contrato, transformando-o e posicionando-o para alcançar os
requisitos do que foi contratado pelo cliente do provedor. Dessa forma, durante esta
fase, a partir do levantamento realizado na fase de mobilização o provedor define,
em conjunto com o cliente, o Modelo de Governança implementado na fase de
transição e consolidado na operação. No modelo MOPP, a construção do Modelo de
Governança considera os seguintes aspectos:
− Definição dos níveis de serviços (SLA) com o cliente a partir dos objetivos de
níveis de serviços (SLO) testados durante o plano de transição. Contempla
também acordos internos de níveis de serviços (OLA) entre as diversas equipes
do provedor e também com outros provedores, caso necessário;
− Definição dos reports entre o provedor e o cliente, bem como sua periodicidade,
conteúdo, clientes e fontes de informações;
− Definição de sign-off (condições de aprovação) pelo cliente das entregas durante
a operação;
− Templates a serem utilizados durante a operação;
102
− Definição da gestão da qualidade, bem como padrões de documentação a serem
utilizados;
− Definição de KPIs (Indicadores de Desempenho) para serem utilizados na
operação;
− Definição de compliance, controles e auditorias a serem realizadas na operação,
incluindo aderência Sarbanes-Oxley, Basel II, HIPAA, ISO 9001, ISO 14001, ISO
20000, ISO 27001 e SAS 70 e outros padrões e normas, conforme as
necessidades e exigências do cliente.
Os processos e templates são mostrados no quadro 21.
103
Quadro 21 – Modelo de Governança # Processo/Template Aplicação no Modelo MOPP
01 e-SCM/SP - Rel01 – Interações com
o Cliente; Rel05 – Informações com
Stakeholders; Rel06 –
Relacionamento com o Cliente;
Rel07 – Relacionamento Parceiros e
Fornecedores; e-SCM/SP - Rel08 –
Criação de Valor
Princípios para a interação diária com o cliente.
Diretrizes para o relacionamento com todas as partes
interessadas da operação do serviço, incluindo cliente,
fornecedores, funcionários, parceiros e outros.
Diretrizes para o relacionamento com o cliente durante
a operação dos serviços. Diretrizes para
relacionamento com os demais provedores do cliente.
Procedimentos e controles para a criação de valor na
entrega dos serviços.
02 CobiT PO01 – Definir um Plano
Estratégico de TI. CobiT ME1, ME2,
ME3 – Monitoramento, Avaliação do
Desempenho de TI; Monitoramento
e Avaliação de Controles Internos;
Garantia de Compliance com
Requisitos Externos; Prover
Governança de TI;
Planejamento estratégico de TI. Diretrizes para avaliar
o desempenho da operação. Diretrizes para avaliação
dos controles da operação dos serviços. Determinação
das atividades de compliance com padrões como
SOX, Base II, ISO 9001 e outras. Diretrizes gerais
para a governança da operação, incluindo alinhamento
com o negócio, riscos, entrega de valor, gestão dos
recursos e monitoramento da performance.
03 VAL IT VG – Governança de Valor;
VAL IT PM - Gestão de Portfolio
Diretrizes para a governança de valor para o contrato;
Prática para gestão do portfolio da operação do
contrato, incluindo todos os serviços em operação e
projetos.
04 ITIL V3 – Projeto de Serviços –
Catálogo de Serviços; Projeto de
Serviços – Gestão de Níveis de
Serviços; Estratégia de Serviços –
Gestão de Demandas; Projeto de
Serviços – Gestão de Fornecedores
Práticas para determinação do catálogo de serviços da
operação do contrato; determinação dos níveis de
serviços da operação dos serviços. gestão das
demandas contratuais e eventuais da operação.
gestão de outros provedores do cliente com impacto
nos serviços.
05 ISO 20000 – Relacionamento com o
Negócio / ISO 38500 – Strategy,
Performance / ISO 27005 - Riscos
Normas para relacionamento com o cliente, riscos e
governança corporativa de TI. Utilização no plano de
transição e na operação.
06 Template de SLA Modelo de formulário para Acordo de Nível de Serviço
07 Template de Book de Indicadores Modelo de relatório mensal para discussão do
desempenho e metas contratuais.
104
3.2.4. Kick-off Meeting e Lições Aprendidas
Após a tomada de controle, a transição é finalizada com a aprovação para entrada
do serviço em operação (kick-off meeting) e também do corte da atividade de
transição para a operação (cut over). No modelo, o aceite da execução do plano de
cut over ocorre conforme a verificação das atividades planejadas pelo cliente. Na
reunião de kick-off os planos elaborados, papéis e responsabilidades, abordagem a
ser utilizada, metodologias e os principais procedimentos do modelo de gestão de
serviços e operações devem ser compartilhados com a equipe do projeto. No
MOPP, as lições aprendidas são as informações coletadas e documentadas ao
longo do projeto de transição que podem ser utilizadas para beneficiar a operação,
projetos futuros ou outros projetos que estejam sendo executados pelo provedor ou
até mesmo pelo cliente. Essas lições podem ser positivas ou negativas.
Durante o projeto de transição, conhecimento deve ser transferido, integrado, criado
e explorado para criar novo valor organizacional. Durante a transição, coletas de
informações e reuniões das lições aprendidas devem ser realizadas durante todas
as fases do projeto. O quadro 22 mostra um exemplo de lições aprendidas para o
projeto de transição. A classificação é feita em lições positivas e negativas, área
afetada como também se estão relacionadas a hardware, software, diagnóstico,
governança, treinamento, absorção, processo ou compliance. Deve ser classificado
também o grau de importância (prioridade).
Quadro 22. Exemplo de Lições Aprendidas Tipo Influência Prioridade Área
Afetada Descrição Lição Aprendida
Diagnóstico Negativa Alta Suporte ERP.
Mapeamento do backlog de chamados pendentes no terceiro nível.
Levar também em consideração os chamados pendentes dos sistemas legados com interface com o ERP.
Após a realização da reunião de kick-off a operação estará pronta para começar.
Todos os recursos estão disponíveis, ferramentas em operação e processos
customizados. O Modelo de Operação e o Modelo de Governança estão prontos
para serem colocados em funcionamento pela equipe que irá assumir o contrato.
105
Os processos e templates são mostrados no quadro 23.
Quadro 23 – Kick-off e Lições Aprendidas
# Processo/Template Aplicação no Modelo MOPP
01 PMI-PMBoK - Gerenciamento de Integração
do Projeto
Encerramento do projeto de transição
02 PMI-PMBoK - Gerenciamento de
Comunicação
Relatório e report de lições aprendidas
03 IPMA - Informação, Documentação e
Reporting
Documentação do projeto de transição para
arquivo e reuso.
04 IPMA - Gestão do Conhecimento em Projetos Gestão do conhecimento acumulado durante
o projeto de transição.
05 e-SCM/SP - Trf06 – Transferência de
Conhecimento
Transferência de conhecimento da transição
para a operação.
06 e-SCM/SP - Knw01 – Compartilhamento de
conhecimento
Compartilhamento de conhecimento entre
transição e operação..
07 Template - Lições Aprendidas Template para elaboração das lições
aprendidas do projeto de transição
08 Template - Padrão de Ata de Kick-off Template para ata de reunião de kick-off
meeting.
O MOPP recomenda a utilização de técnicas de gerenciamento ágil de projetos
(APM) para a coleta diária das lições aprendidas. Ocorre por meio de
armazenamento de informações de todos os comprometidos para os itens que foram
bons no projeto ou que precisam melhorar. Um exemplo de técnica inclui o
framework Scrum e o seu stand up meeting diário de 15 minutos ( reuniões diárias
contendo o escopo, o que fazer, o que está executado, impedimentos e o que está
pronto ).
106
3.3. Operação dos Serviços
A operação dos serviços abrange um gerenciamento de demanda para capturar e
avaliar as necessidades do negócio, conforme figura 27. Os requisitos dos serviços
contemplam níveis de serviços, capacidade, continuidade, segurança e
subcontratação. Na sequência, é apresentada a etapa de gestão de mudanças que
abrange configurações, mudanças e liberação e, finalmente, o suporte dos serviços
abrangendo entrega e suporte. Ocorrem também projetos especiais que ocorrem por
conta de oscilações de demandas e também de necessidades eventuais dos
clientes.
Figura 27 - Ciclo de Vida da Operação
3.3.1. Gerenciamento da Demanda
No modelo MOPP, gerenciamento de demandas é um aspecto crítico para a
operação dos serviços. Uma demanda mal gerenciada é uma fonte de riscos para a
operação. Por outro lado, excesso de capacidade gera custos desnecessários. O
objetivo é evitar uma demanda do negócio muito superior à capacidade de TI para
atendê-la. A operação não pode prometer uma demanda superior à sua capacidade,
passando a impressão de que o serviço será atendido. A ausência de
107
balanceamento entre oferta e demanda pode indicar que as solicitações não serão
entregues nos prazos negociados. Por isso a gestão da demanda é um pilar
importante para a operação de serviços de TI e é considerado como um elemento
essencial do modelo MOPP.
A gestão adequada da demanda exige disciplina e controles rígidos. O ponto de
partida para a gestão da demanda é a priorização das necessidades de negócio face
à estratégia da empresa. O processo de priorização dos requerimentos deve ter
critérios claros e pré-estabelecidos, tais como justificativa econômica e riscos. Uma
vez estabelecidas as prioridades, é necessário avaliar se a capacidade existente é
suficiente para atender todas as demandas, ou se existem mecanismos e condições
para aumentar a capacidade existente. O plano anual de TI deve refletir este
equilíbrio e requer, muitas vezes, que se reavaliem as demandas ou se recorra a
algum mecanismo para adequar a capacidade. A demanda poderá vir de diversas
fontes como fusões & aquisições (M&A) do cliente, expansão de negócios e
movimentação de baseline, conforme figura 28.
Figura 28 – Gerenciamento Demanda Operação TI
Ocorre também uma recepção, análise, comparação com a capacidade atual, apoio
das áreas do cliente e das áreas corporativas do provedor (ex. RH e Comercial).
108
Finalmente é realizado um mapa de necessidades contendo informações como
recursos, pessoas e processos para o ajuste nos serviços.
Os processos e templates são mostrados no quadro 24.
Quadro 24 – Gerenciamento de Demandas
# Framework/Processo/Template Aplicação no Modelo MOPP
01 ITIL V3 - Estratégia de Serviços –
Gerenciamento de Demandas;
Estratégia de Serviços – Portfolio de
Serviços; Estratégia de Serviços –
Economia do Serviço; Design do
Serviço – Planejamento de
Capacidade.
Diretrizes para o gerenciamento da demanda.
Relatório e reporte de Lições Aprendidas. Determinar
e avaliar os valores financeiros envolvidos com a
demanda. Avaliar a capacidade atual e futura para
atendimento da demanda.
02 eSCM/ SP - Rel01 – Interação com o
Cliente; Rel06 – Relacionamento com
o cliente
Diretrizes para o relacionamento com o cliente,
quanto às demandas dos serviços. Entendimento
das necessidades dos clientes e elaborar processos
para o relacionamento diário.
03 IPMA – Negociação e Reuniões Diretrizes para negociações e reuniões de demandas
de novos projetos.
04 IPMA – Recursos Diretrizes para determinar o mapa de recursos da
demanda.
05 IPMA – Custos e Financiamentos Diretrizes para determinar os aspectos financeiros da
demanda dos serviços.
06 Cobit - PO5 – Gerenciar Investimentos
em TI; VAL IT – PM - Gestão de
Portfolio
Determinar a viabilidade financeira das novas
demandas. Avaliar o portfolio atual do provedor para
priorização e inclusão da nova demanda.
07 ISO 20000 – Relacionamento com o
Negócio; Implantação de Serviços
Novos ou Modificados.
Alocar responsável para o relacionamento com o
cliente. Controlar as novas demandas. Manter base
de dados de todos os stakeholders da demanda.
07 Template - Formulário de Solicitação
de Novas Demandas
Template para o cliente solicitar novas demandas.
08 Template - Modelo de Business Case Business case da avaliação da demanda.
109
3.3.2. Especificação dos Requisitos dos Serviços
Estabelecida a necessidade da demanda, o provedor executa a especificação dos
requisitos para a operação. Esta etapa envolve o mapeamento de padrões de
continuidade e disaster recovery necessários, o nível de segurança da informação,
as necessidades de subcontratação junto a terceiros e os níveis de capacidade.
Finalmente, devem ser validados o SLA para os serviços em operação durante o
prazo alinhado com o cliente na fase de operação. Os requisitos validados e
aprovados pela gestão da equipe da operação e pelo responsável do cliente serão
utilizados como entrada para a etapa de gestão de mudanças.
Os processos e templates são mostrados no quadro 25.
110
Quadro 25 – Especificação dos Requisitos de Serviços
# Framework/Processo/Template Aplicação no Modelo MOPP
01 ITIL V3 - Projeto do Serviço –
Continuidade; Projeto do Serviço –
Capacidade; Projeto do Serviço – Níveis
de Serviços; Projeto do Serviço –
Fornecedores; Projeto do Serviço –
Segurança da Informação
Necessário para estabelecer o plano de
continuidade do serviço, incluindo disaster
recovery, plano de operação reduzida e plano de
restore. Especificação dos requisitos mínimos de
desempenho dos serviços. Especificação dos
níveis de serviços acordados no plano de
transição, incluindo os requisitos determinados no
catálogo de serviços. Necessidades de
contratações e de segurança da informação
lógica, física e de aplicações para os projetos.
02 ISO 27001 - A.8 – Requisitos para
Segurança de Recursos Humanos; A.9 –
Requisitos para Segurança de Recursos
Humanos; A.10 – Requisitos para
Segurança de Recursos Humanos; A.11
– Requisitos para Controle de Acesso.
A.12 – Requisitos para segurança de
sistemas
Utilizar na especificação do nível de segurança
relacionados a pessoas, ambiente físico onde
funcionará o serviço, acesso e sistemas. Também
considerar para o nível de segurança relacionado
a rede LAN, WAN, Servidores e Aplicações.
03 IPMA - Aquisições e Contratos Necessário para subcontratações de serviços
pelo provedor nas instalações do cliente.
04 CMMI 1.2 for Services – RD
(Desenvolvimento Requisitos) e REQM
(Gestão de Requisitos)
Diretrizes aplicáveis na recepção, equalização e
gestão dos requisitos de serviços de software.
05 Cobit - DS1 – Gerenciar Níveis de
Serviços; DS2 – Gerenciar Partes
Terceiras; DS3 – Gerenciar Capacidade e
Desempenho; DS4 – Garantir
Continuidade dos Serviços; DS5 –
Garantir Segurança da Informação;
Controles para os requisitos dos níveis de
serviços do modelo. Requisitos de
subcontratação de partes terceiras pelo provedor.
Requisitos de desempenho, capacidade,
continuidade e segurança da informação.
10 Templates - Plano de Continuidade do
Serviço
Template para elaboração do Plano de
Continuidade do Serviço
11 Templates - Padrão de SLA Template para elaboração do SLA (Acordo de
Níveis de Serviços).
111
Como complementação da especificação dos serviços, o trabalho mostra a seguir
um método para avaliação dos níveis de indicadores internos em projetos dos
provedores de TI.
Método para Avaliação de Acordo de Níveis de Serviços Operacionais (OLA
entre as equipes do provedor ou entre parceiros no serviço ao cliente).
Dentro dos requisitos de níveis de serviços, o acordo contratado com o cliente é
realizado de forma total, fim-a-fim, desde a origem do serviço (exemplo: aplicação
em um datacenter) até a sua finalização (exemplo: consulta na estação do usuário).
Um exemplo é um acordo de nível de serviço de tempo de atendimento em um
contrato de outsourcing de ERP. Conforme o ITIL SO (2007), os níveis de serviços
(SLA) determinam os indicadores e requisitos para a operação dos serviços de TI. O
ITIL sugere exemplos destes indicadores. Para o suporte, determina-se o percentual
máximo de atendimento em determinado período de tempo. Um exemplo é
determinar um indicador de 90% dos chamados de alta prioridade atendidos em até
02 horas.
Para ilustrar, o MOPP fornece um exemplo de prioridade de serviços em
manutenção corretiva de complexidade média. Supondo que 90% dos chamados
necessitam ser atendidos em até 8 horas, conforme requisitos contratuais. No final
do mês, supondo que o indicador apresentado ficou em 91%, conclui-se que está
acima do contratado de 90% e o SLA foi atendido. O processo interno do provedor
para prover o serviço, de forma aparente, foi bem-sucedido. Porém, Avaliando a
capacidade para cada etapa do serviço, nota-se que o chamado passou por várias
áreas antes de ter sido solucionado de forma definitiva e que, em algumas delas, o
indicador ficou abaixo da meta. O MOPP sugere que os níveis de serviços entre as
equipes do provedor sejam na média igual ao nível total acordado com o cliente. O
exemplo abaixo mostra uma situação de atendimento de demanda corretiva:
− Service Desk - Atendimento da demanda, verificação de regras básicas de
autorização/aprovação e encaminhamento. SLA atingido de 94% em até 02:00
horas;
112
− Equipe de suporte funcional - Análise da demanda, elaboração de
especificação funcional. Alteração do status do chamado para << resolvido >> e
disponibilização para o Service Desk. SLA de 89% em até 02:00 horas;
− Equipe da Fábrica de Software do ERP - Desenvolve especificação técnica,
elabora a metrificação, desenvolve a demanda, realiza os códigos unitários e
retorna para a área operacional. 86% em até 02:00 horas
− Equipe de Testes - Recebe a demanda desenvolvida da área funcional e realiza
os testes de regressão e funcional e retorna para a área funcional. 95% em até
02:00 horas.
Utilizando o conceito de Rendimento do Seis Sigma (RTY) de forma adaptada a
serviços de TI, a visão acima apresentada representa o método tradicional de
rendimento e de saída comparada à entrada para cada equipe interna do provedor.
Neste aspecto, os ofensores foram a equipe funcional e também a fábrica de
software, áreas com nível de serviço abaixo do contratado de 90%. Estes resultados,
porém, induzem a erros, pois existem variáveis envolvidas como inspeção e
retrabalho em especificação funcional, por exemplo, que acabam penalizando um
setor em detrimento de outro.
O modelo MOPP recomenda utilizar o FTY – First Time Yield do Lean Six Sigma de
forma adaptada para avaliar o real rendimento de cada setor de atendimento da
demanda. No modelo original para cada 100 demandas registradas no mês, a
fábrica estava atendendo apenas 86 no prazo. O processo de uma fábrica de
software deveria ser receber as demandas, realizar o desenvolvimento e retornar o
produto para a área funcional. Isto nem sempre ocorre com 100% de efetividade,
gerando o conceito de fábrica oculta, adaptada do Lean Six Sigma, conforme
mostrado na figura 29.
A fábrica de software recebeu 100 demandas, das quais 14 especificações
funcionais não cumpriram os critérios de qualidade estabelecidos e foram
justamente as que tiveram o prazo de atendimento não atendido, sendo que todas
elas necessitaram ser corrigidas ou retrabalhadas. Desse total, 10 foram devolvidas
para a equipe funcional. Dessa forma a fábrica atendeu em 96% os níveis de
113
serviços e não em 86%, como originalmente estava calculado, ou seja, FTY = (100 –
4 / 100) x 100% = 96% .
Já para o cálculo da capacidade de todo o processo, o MOPP recomenda utilizar o
Rolled Throughtput Yield (RTY) adaptado a serviços de TI, conforme a seguir:
RTY = FTYService Desk x FTYFuncional x FTYFábrica x FTYTeste As etapas individuais do
processo são enfileirada para criar uma estrutura de execução de tarefas complexas
como, por exemplo, a manutenção de software. Para calcular o rendimento das
quatro etapas internas, sob o ponto de vista do provedor, é multiplicado o FTY para
cada etapa unida, criando o que o Seis Sigma denomina de RTY (Rolled Throughput
Yield ou Rendimento Final do Processo). No exemplo dado o RTY do processo de
manutenção corretiva é de: RTY = 0,95 x 0,89 x 0,86 x 0,94, resultando em RTY =
0,68 ou 68% (0,68 x 100%).
Figura 29 – Fábrica de Software Oculta em Demandas
fonte: adaptado de Gygi et al.(2009, p. 130)
Isso significa que a chance de uma demanda corretiva passar pelo processo na
primeira vez sem retrabalho é de somente 68%. Como a última etapa (testes de
software) mostra um rendimento de 94%, existem fábricas ocultas no processo.
Pelo conceito do Seis Sigma, o RTY nunca pode ser maior do que o menor FTY
114
dentro do sistema. O modelo MOPP, dessa forma, sugere atenção em etapas
individuais (como por exemplo, a fábrica de software ilustrada no exemplo) com o
menor FTY. Depois deve seguir para a etapa com o segundo menor, no caso a
equipe funcional.
Se ocorrer altos níveis de serviços, mas a quantidade de áreas do provedor se
tornar cada maior para atender a demanda corretiva, o FTY do processo continuará
a se desgastar, pois a complexidade aumenta. Uma situação hipotética é o
envolvimento de áreas do cliente, parceiros, fornecedores e de outros provedores do
cliente para atendimento de um chamado. Um processo de quatro passos tem muito
menos oportunidades para erro do que um processo de oito passos, conforme
mostrado na tabela 7.
Se todas as demandas, por exemplo, fossem atendidas já no service desk com um
nível de entrega padrão 03 sigma (93,32%) de resolução no prazo contratado, o
rendimento seria este mesmo valor. Porém, se percorressem sete áreas diferentes
dentro do provedor com o mesmo rendimento (93,32%), o seu rendimento total
(RTY) seria de apenas 61,63%, conforme mostrado na tabela 7. O objetivo de
melhoria dos serviços, portanto, é realizar a demanda com o maior rendimento
individual possível e com a menor quantidade de etapas.
Tabela 7 – Rendimento Total x Sigma do Serviço de TI
Passos RTY
+/- 3σ (93,32%) +/- 4σ (99,379%) +/- 5σ (99,9767% +/- 6σ (99,99966%)
1 93,32% 99,379% 99,9767% 99,99966%
7 61.63% 95,733% 99,839% 99,9976%
10 50,08% 93,96% 99,768% 99,9966%
20 25,08% 88,29% 99,536% 99,9932%
40 6,29% 77,94% 99,074% 99,9864%
Fonte: adaptado de George (2003, p. 65)
Outro aspecto relevante que este método traz é a adaptação do Lead Time (Lei de
Little) da manufatura enxuta (Lean) para operação de serviços de TI. Entende-se
Lead Time como a relação entre a quantidade de trabalho em processo (Work In
Process) dividida pelo índice médio (Exit Rate) de conclusão (LT = WIP / ER). Se
115
existir uma fila de 100 demandas corretivas de software aguardando suporte,
capacidade da equipe de analistas de atendimento de 20 demandas dias, o Lead
Time será de 10 dias, considerando que não ocorra nenhuma nova demanda. LT
menor reduz custos e aumenta satisfação do cliente com os serviços de TI. Existem
duas formas de redução: reduzindo a fila de chamados ou aumentando a
produtividade da equipe. O método aqui apresentado na tese indica algumas ações
para redução do LT em serviços de TI: Influenciar a demanda (ex. Acordo de Nível
de Serviço, self-service), gestão do conhecimento, planejamento de capacidade,
redução da complexidade de infraestrutura e aplicações, aumento da qualidade e
atenção em análise de causa e resolução de problemas.
3.3.3. Gestão de Mudanças
Esta etapa é responsável pelas alterações, configurações e instalações de serviços
novos ou modificados no ambiente de TI. Envolve atividades como análise de
modificações, configurações, liberação e mudança organizacional. Inicialmente é
feita uma solicitação de mudança (RFC), que é devidamente avaliada quanto a
riscos, impacto e contingência. Para a análise de impacto é utilizado o processo de
gerenciamento de configurações. O impacto é avaliado por meio da base de dados
de configurações (CMDB), contendo os itens necessários para a prestação dos
serviços e todos seus inter-relacionamentos. Na sequência a mudança é
encaminhada para um comitê que a aprova. Uma vez aprovada, passa por um
processo de homologação e testes.
Finalmente, a mudança é instalada no ambiente de produção e o CMDB é
atualizado. Para finalizar o processo, uma revisão pós-implementação deve ser
realizada. Pelo modelo MOPP esta revisão pode ser executada via interface com os
incidentes registrados no Service Desk. Devidamente orientados, os operadores
podem vincular novos incidentes a alguma mudança executada recentemente.
Podem existir mudanças com um ciclo maior de avaliação pós-implementação. Por
exemplo, processos com ciclo de execução mensal. Nesta etapa do MOPP, também
é considerada a mudança organizacional (MOC). Tem por objetivo reduzir as
resistências para a concretização de mudanças dos serviços de TI. Envolve a
construção de um plano capaz de mobilizar as pessoas envolvidas, modelar a
116
situação antes e depois da mudança, desenhar as mudanças das atribuições e
impactos com os novos serviços, comunicar mudanças na estrutura organizacional e
finalmente gerar informações autorizando o inicio do processo da gestão de
mudanças de serviços de TI. Após a realização da mudança, o serviço novo ou
modificado estará pronto para receber o devido suporte, ao lado da operação
existente. Os processos e templates são mostrados no quadro 26.
117
Quadro 26 – Gestão de Mudanças
# Processo/Template Aplicação no Modelo MOPP
01 ITIL V3 - Transição do Serviço – Plano de
Transição; Transição do Serviço –
Gerenciamento de Mudanças; Transição do
Serviço – Gerenciamento de Ativos e
Configurações; Transição do Serviço –
Testes de Homologação; Transição do
Serviço – Release e Instalação; Transição do
Serviço – Avaliação Pós-Implementação
Necessário para estabelecer o plano de
continuidade do serviço, incluindo disaster
recovery, plano de operação reduzida e plano
de restore. Requisitos mínimos de desempenho
dos serviços. Níveis de serviços acordados no
plano de transição, incluindo os requisitos
determinados no catálogo de serviços.
necessidades de subcontratação. Requisitos
de segurança da informação.
07 Cobit - P09 – Avalia e Gerencia Riscos de TI;
P07 – Gerencia Recursos Humanos de TI;
A16 – Gerenciar Mudanças; A17 – Instala e
Valida Soluções e Mudanças; DS9 –
Gerenciar Configurações
Utilização na avaliação de riscos da operação,
contratação e controles dos recursos da
operação de serviços de TI. Controles das
mudanças, homologações, liberações e
revisões assim como dos itens de
configuração, incluindo auditorias e evidências
necessárias.
12 e-SCM/SP - Del07 – Modificações em
Serviços
Estabelecer e implementar procedimentos para
modificação no serviço.
13 e-SCM - Sdd08 – Instalação de Serviços Estabelecer e implementar procedimentos para
instalação de serviço.
14 IPMA - Conflitos e Crises; IPMA –
Configurações e Mudanças
Necessário para a gestão de eventuais
conflitos e crises durante as mudanças dos
serviços.
15 CMMI 1.2 – CM – Gestão de Configurações Requisitos controle das versões dos sistemas
durante a operação dos serviços..
16 PMI/PMBoK - Gerenciamento de Recursos
Humanos; Gerenciamento de Integração
Gestão de RH, treinamentos e competências
para as mudanças e controle das mudanças
durante os projetos eventuais da operação..
17 Template - Requisição de Mudanças (RDM) Formulário para solicitação da mudança
18 Template - Mapa de Release Formulário para planejamento de Release.
118
3.3.4. Suporte de Serviços
Esta etapa é responsável pelo suporte e atendimento dos serviços em operação.
Abrange o service desk, suporte a solicitações e incidentes, gerenciamento de
problemas, gestão da base de conhecimento, gestão de acesso, gestão de eventos
e suporte técnico. A figura 30 mostra a visão geral do suporte a serviços e também o
o relacionamento dessa etapa com a gestão de mudanças dentro do modelo MOPP.
As informações para a gestão do suporte de serviços podem ter origem no suporte
técnico por meio de monitoramento de eventos, da própria equipe do provedor e,
principalmente, da demanda dos usuários. As necessidades dos usuários são
recebidas inicialmente pelo service desk que direciona o chamado como incidente
ou solicitações de serviços. Os incidentes também podem ser provenientes de
eventos de exceção (falhas em TI). Os incidentes com causa desconhecida
proporcionam o registro de um problema para resolução de forma definitiva via
gestão de mudanças e release (liberação). A gestão de configuração auxilia os
incidentes e problemas na análise dos itens de configuração com histórico de
problemas e também apóia a gestão de mudanças na análise de impacto.
Figura 30 – Visão Suporte de Serviços e Relação com Gestão de Mudanças
119
Os indicadores operacionais de serviços mostrados no quadro 27 são normalmente
utilizados para aferir o nível de suporte.
O suporte técnico envolve atividades como gerenciamento e monitoramento de
redes, suporte de servidores, suporte de storage (armazenamento), administração
de banco de dados, gestão de datacenter, gerenciamento ambiente intranet/internet,
gerenciamento de facilities (instalações) e suporte ao ambiente de aplicações e
suporte técnico ao desenvolvimento de software. O objetivo principal desta etapa do
ciclo de vida é solucionar os chamados, problemas e eventos como também
conceder os acessos necessários para os usuários.
120
Quadro 27 – Indicadores Operacionais
# Indicador Descrição Índice Sugerido MOPP
1 Taxa de Abandono Taxa da quantidade de total de chamadas com desistência em relação ao volume total.
<= 5%
2 Tempo Médio de Espera
Tempo médio de atendimento de 100% das ligações telefônicas.
<= 40 segundos
3 Suporte 1º. Nível % de suporte no 1º. Nível com script de atendimento.
>= 60%
4 Tempo de Atendimento
Tempo de atendimento por prioridade dos chamados (incidentes) ou por tempo máximo de máximo (solicitações)
Incidentes:
− Prioridade 0 (vip e emergênca) – até 02 h
− Prioridade 1 – até 02 h
− Prioridade 2 – Até 08 hs
− Prioridade 3 – Até 24 hs
Solicitações:
− Até 12 horas (tempo máximo)
5 Satisfação do Usuário % Satisfação do Usuário do total de avaliações respondidas
>= 95% de satisfação do usuário
6 Disponibilidade Técnica
% sobre os itens críticos (ex. servidores de ERP, Link de Dados, Servidor de Correio Eletrônico)
>= 99,5% de disponibilidade (aproximadamente 04 horas no máximo de indisponibilidade planejada mensal para serviços 24 x 7)
7 % Eventos Exceção registrados e tratados como incidentes
Percentual de eventos convertido em incidentes
100% (todo evento de exceção deve ser convertido em incidentes e acompanhados devidamente).
Os processos e templates do suporte de serviços são mostrados no quadro 28.
121
Quadro 28 – Suporte de Serviços
# /Processo/Template Aplicação no Modelo MOPP
01 Cobit - DS8 – Gerenciar Service
Desk e Incidentes; DS10 – Gerenciar
Problemas; DS11 – Gerenciar
Dados; DS12 – Gerenciar Ambiente
Físico; DS13 – Gerenciar
Operacões;
Controles e diretrizes para service desk e incidentes no
modelo. Gestão de problemas, gestão de dados,
incluindo administração de banco de dados. Controles
para facilities de datacenter, NOC e de outras áreas da
operação. Diretrizes e controles para o gerenciamento
de operação, incluindo gestão de datacenter e storage
06 ITIL v3 -SO – incidentes; SO –
Problemas; SO – Eventos; SO –
Acesso; Funções de Gerenciamento
Técnico, Operações e Service Desk;
ST – Gestão de Conhecimentos
Gestão de Incidentes na operação, controle de
problemas, análise de causa raiz e gestão de erros
conhecidos. Também aplicável em monitoramento e
gestão de evento, acesso, gestão da operação
(datacenter, redes, servidores, facilities, storage e
dados, jobs, backup) e Gestão de Conhecimento.
14 e-SCM/SP - Kmw03 – Sistema de
Conhecimento; Del03 – Entregar
Serviços; Del05 – Corrigir
problemas.
Aplicação de gestão de conhecimento e customização
de ferramentas de service desk. Solicitação e gestão
dos serviços solicitados pelos usuários como acesso,
instalações e outros. Também aplicáveis a gestão de
eventos, incidentes e problemas.
17 ISO 20000 - 8.2. Gerenciamento de
Incidentes; 8.3. Gerenciamento de
Problemas; ISO 9001 – Sistema de
Gestão
Determinação (a atividade deve ser executada) para a
gestão de incidentes, garantindo a execução das
atividades. Gestão de problemas, garantindo a
execução das atividades. Desenvolvimento e
implantação do Sistema de Gestão.
19 CMMI for Services – RD
(Requisitos), PP/IPM/PMC/QPM
(Projetos), (TS (Desenvolvimento),
PI (Integração), Ver&Val (Testes e
Inspeção)
Recebimento de requisitos, projeto, desenvolvimento e
integração da demanda e testes/inspeções nos serviços
de software.
20 ISO 27001 - A.10.10.
Monitoramento; A.10.5. Backup;
A.10.2. Gerenciamento de Acesso
de Usuários
Gestão e Segurança de acessos. Testes backups e
mídias dos serviços prestados pelo provedor. Controle
necessário para garantir a concessão correta dos
acessos dos serviços de TI.
21 Template – Formulário de incidentes Modelo de tela para registro de incidentes
122
O trabalho mostra a seguir três métodos para auxílio na gestão da operação de
serviços de TI. O primeiro ajuda as equipes do provedor a realizar correlações entre
indicadores de suporte, indicando o melhor equilíbrio para otimizar os custos dos
serviços e aumentar a satisfação do cliente. O segundo método está relacionado ao
balanceamento das equipes de suporte. O terceiro fornece um apoio no
dimensionamento dos serviços de TI, conforme padrões definidos (baseline) na
contratação.
Método para Avaliação de Indicadores de Suporte Serviços
O método consiste em acompanhar de forma quantitativa os principais indicadores
de suporte a serviços. Para tanto, esboçou-se inicialmente uma relação entre alguns
indicadores que formam a operação dos serviços, conforme mostrado na figura 31.
A seta maior determina a relação entre as duas variáveis (positiva ou negativa) e a
seta de direção determina o sentido da influência da variável.
Figura 31 – Relação entre Indicadores Suporte Serviços
123
Para tornar mais claro, quanto maior o Tempo Médio de Atendimento, significa que o
Atendente de Service Desk está tentando resolver o chamado e, com isto, aumentar
o Suporte no 1º. Nível. Isto, porém, aumenta a Taxa de Abandono, com redução na
satisfação do usuário. O Tempo Médio de Espera (TME) tem uma correlação
negativa com a Taxa de Abandono, que por sua vez influencia de forma negativa o
Tempo Médio de Atendimento (TMA). O aumento do Suporte 1º. Nível favorece a
redução dos incidentes para atendimento. Por sua vez, a redução de incidentes e da
taxa de abandono aumenta a satisfação dos usuários.
Uma gestão eficaz de problemas apresenta vários benefícios no processo de
operação de serviços de TI, suportando a redução do volume de incidentes e
reduzindo o Lead Time. O nível do tempo médio de atendimento e do suporte 1º
nível apresenta um equilíbrio com a taxa de abandono e com o tempo médio de
atendimento (TMA). O método não recomenda aumentar o suporte 1º. nível de forma
não planejada, pois poderá incrementar de forma acentuada a taxa de abandono,
gerando insatisfação dos usuários. George (2004) alerta que, para melhorar
resultados de indicadores (ex: satisfação do usuário), existe a necessidade de
encontrar fatores críticos (ex. taxa de abandono, TMA, Suporte 1º. Nível,
produtividade e TME) que afetam o resultado e neles concentrar os esforços.
Algumas variáveis podem e devem ser controladas de forma estatística, para
melhorar os resultados. Um equilíbrio deve ser realizado. No dimensionamento dos
recursos para o suporte, deve-se questionar qual o equilíbrio ideal dos indicadores
em termos de custos dos serviços e satisfação do cliente. Um exemplo seria
estabelecer um Tempo Médio de Atendimento (TMA) de 5 minutos, suportando uma
Taxa de Abandono de 3%, um Tempo Médio de Espera (TME) de 90% em até 40
segundos e um Suporte 1º. Nível de 90% dos chamados passíveis e de 60% sobre o
volume total dos chamados.
Método de Dimensionamento Capacidade de Suporte de Serviços
A formula de Erlang é uma das técnicas mais indicadas para determinar a
capacidade de recursos de serviços de TI (Koole, 2007). É utilizada para
dimensionamento em qualquer sistema constituído por filas, inclusive em service
124
desk. Trata-se de uma forma quantitativa de fazer previsões sobre carga de trabalho
que pode chegar aleatoriamente (como as chamadas telefônicas) com base em
informações já disponíveis (como a duração média de uma chamada). As fórmulas
de Erlang são usadas para determinar o tamanho da equipe e o número de troncos
necessários em uma central de serviços. Existem dois tipos de fórmula Erlang. A
Fórmula Erlang B é usada quando o tráfego é aleatório e não existe fila; Já a Erlang
C é quando o tráfego é aleatório e existe fila, partindo do pressuposto de que todos
os chamadores permanecerão esperando indefinidamente.
Em um suporte técnico, a quantidade de chamadas que entra em determinado
espaço de tempo pode ser chamada de β, medida em unidades de tempo.
Considera-se que não existe taxa de abandono e que o cliente aguarda até ser
atendido. A quantidade de chamadas é denominada de λ. Considera-se então a
carga do Service Desk como a = β x λ. Com a premissa de um service desk com
média de uma chamada por minuto (λ), um Tempo Médio de Atendimento (TMA ou
β) de 5 minutos, o tempo total das chamadas será de a = λ x β = 1 x 5 = 5. Os
chamados registrados via internet e também o tempo de espera tolerável podem
entrar no modelo para determinar o dimensionamento do suporte necessário. O
provedor também pode negociar com o cliente o nível de taxa de abandono
desejado e partir desta premissa, determinar a capacidade de suporte técnico,
conforme o volume de chamadas e de chamados. Na tabela 8 é mostrada o
resultado de uma simulação em planilha eletrônica para alguns indicadores
importantes de suporte.
Tabela 8 – Simulação Indicadores de Suporte
Descrição Valores
Taxa Abandono (%) 10%
Quantidade Chamadas/Dia/URA (qtde) 5000
Quantidade Chamadas Atendidas (qtde) 4500
TMA Atendimento (minutos) 5
Capacidade Atendimento/Dia/Atendente (qtde) 360
Quantidade de Atendentes (qtde) 12,5
Ao considerarmos 10% de taxa de abandono, 500 chamadas registradas na URA
(Unidade de Resposta Audível) não convertidas em chamados (5000 – 4500) e um
tempo médio de atendimento de 5 minutos, a capacidade de atendimento dia de
125
cada atendente será de 360 chamadas (5 minutos x 12 x 6 horas/dia). Como
premissa, o modelo considera um turno contínuo de 6 horas para cada atendente.
No exemplo do volume de chamadas com uma taxa aceitável de abandono de 10%,
a quantidade de atendentes necessária seria de 12,5. O método aqui apresentado
propõe ser simples, não considerando a flutuação de chamadas ao longo do dia
para efeito de otimização de recursos e nem o recurso de registro de chamados por
meio da web ou atendentes dedicados aos chamados denominados vips (altamente
prioritários), o que poderia afetar o dimensionamento final.
3.3.5. Projetos de Demandas Eventuais
Esta etapa contempla movimentação de baseline e também detecção de demandas
eventuais. Esta análise é realizada durante a análise dos requisitos dos serviços. O
MOPP considera que na etapa da operação são comuns situações que impactam de
maneira significativa os esforços e volumes previstos no início dos serviços e
também ao longo do contrato. As etapas do projeto devem seguir uma metodologia
de gerenciamento de projetos própria ou do cliente, porém algumas etapas podem
ser abreviadas, conforme a urgência do acordo entre cliente e provedor. Os itens
abaixo ilustram algumas dessas situações:
− Preparação e instalações de estações de trabalho em larga escala;
− Projetos de novas aplicações;
− Roll-out de aplicações para outras empresas;
− Aquisição ou venda de novas empresas que já utilizam à mesma plataforma;
− Aquisição ou venda de novas empresas que utilizam plataformas diferentes;
− Implantação ou desativação de módulos e funcionalidades;
− Migração de versão do ERP ou aplicação;
− Migração de infraestrutura;
− Implantação ou desativação de novas ferramentas com plataformas específicas.
Os projetos podem ser detectados não somente por demandas eventuais dos
usuários, como também por análise de ambiente da operação, como, por exemplo,
oscilações bruscas na demandas de acesso a sistemas, solicitações de serviços e
também para casos especiais de análise de causa raiz de problemas. Os processos
e templates são mostrados no quadro 29.
126
Quadro 29 – Projetos de Demanda Eventual
# Processo/Template Aplicação no Modelo MOPP
01 Cobi/t - PO10 – Gerenciar Projetos Controles, auditoria e diretrizes o gerenciamento de
projetos.
02 PMI-PMBoK - Gerenciamento de
Integração; Gerenciamento do
Escopo
Project Charter e Gerenciamento do Escopo/ Mudanças
para a entrega.de demanda eventual e para o plano de
projeto. Aplica-se também a definição, aprovação e
verificação do escopo da demanda eventual,
04 IPMA - Iniciação do Projeto;
Encerramento do Projeto; Estrutura
do Projeto; Conteúdo e Escopo do
Projeto.
Requisitos para a iniciação do projeto de demanda
eventual. Aplicam-se também a estrutura, conteúdo,
escopo e encerramento do projeto de demanda
eventual.
05 ISO 20000 - Planejamento e
Implementação de serviços novos ou
modificados.
Determinação (deve ser) para a gestão de projetos de
serviços novos ou modificados referentes às demandas
eventuais, garantindo a execução das atividades.
06 ISO 9001 - 7.3. Projeto e
Desenvolvimento
Diretrizes para planejamento e controle de projeto
07 eSCM/SP - Sdd03 – Planejamento e
implantação do projeto
Diretrizes para elaboração de procedimentos e controle
para planejamento e implantação do projeto.
08 Template - Project Charter Modelo para autorização de inicio do projeto.
09 Template - Status Report Template reporte periódico do projeto
10 Template - Lições Aprendidas Modelo de Lições Aprendidas para uso nos projetos de
demandas eventuais.
O modelo MOPP prevê também uma análise de viabilidade dentro da etapa de
requisitos para análise das flutuações de demanda. Os projetos durante a operação,
quando previamente viabilizados e executados evitam uma série de problemas no
suporte do serviço.
Método para Movimentação de Baseline de Serviços de TI
Os projetos de demandas eventuais dependem da observação de eventuais
flutuações ou aumento da demanda por serviços de TI na operação do cliente. O
127
modelo considera que em operação de TI ocorrem situações que impactam de
maneira significativa os esforços e volumes previstos no início dos serviços e
também ao longo do contrato, conforme explicado no inicio deste capítulo. Da
mesma forma, o aumento da eficiência da equipe do provedor de TI, decorrente da
melhoria dos processos relacionados, maior conhecimento do processo em questão
e melhoria dos aplicativos, escopo de uma RFP, podem ocasionar em decréscimo
ao longo da operação dos serviços. Dessa forma o modelo considera que deve
existir uma revisão periódica do baseline definido na proposta comercial. Como
balizador para esta revisão, propõe-se neste trabalho um método descrito no quadro
30, tomando por base em informações mais comuns em gerenciamento de serviços
de TI, tais como: quantidade de usuários, quantidade de chamados e quantidade de
chamadas.
Quadro 30 –MOPP - Método de Movimentação de Baseline
Variável Base de cálculo
CS – Capacidade da equipe de suporte 2º. nível
Qtde. Recursos x 176 horas (horas mensais comerciais de trabalho)
MC - Média de Chamados Mês
Média de chamados dos três últimos meses obtidos no momento do acionamento da movimentação de baseline
BU – Base de Usuários do Cliente do provedor
Quantidade total dos usuários do cliente, objeto do contrato
MR – Mediana de Resolução de cada chamado
Medida do tempo de atendimento dos chamados do mês anterior ao acionamento de movimentação de baseline.
QH – Horas por Usuários QH = ( MC / BU ) * MR
UA – Grupo de Usuários Adicionais
Quantidade de usuários adicionais para que seja identificado uma situação de acionamento da movimentação de baseline.
QM – Quantidade de chamados por usuários
QM = MC / BU
PG – Percentual de esforço para grupos de usuários adicionais
PG = ( QM * UA ) / MC
BL – Baseline revisado do suporte de TI após o cálculo passa a ser o novo CS a ser utilizado na próxima movimentação.
BL = CS * PG
O modelo do quadro 31 demonstra que o baseline se movimenta a cada grupo de 50
usuários. A movimentação do baseline para mobilização de posto de trabalho ocorre
128
dentro de um prazo máximo de 30 (trinta) dias e a desmobilização deve ocorrer em
até 60 dias, após a formalização com o cliente. No quadro 31 é mostrado um
exemplo prático do uso da movimentação de baseline do modelo MOPP com o
acréscimo de mais 50 usuários na operação.
Quadro 31 –MOPP – Aplicação da Movimentação de Baseline
Variável Valores
CS – Capacidade da equipe de suporte 2º. nível 6.500 horas
MC - Média de Chamados Mês 5.000
BU – Base de Usuários do Cliente do provedor 4.000 usuários
MR – Mediana de Resolução de cada chamado 3 horas
QH – Horas por Usuários QH = ( 5.000 / 4.000 ) * 3 = 3,75
UA – Grupo de Usuários Adicionais 100
QM – Quantidade de chamados por usuários QM = MC / BU = 5.000 / 4.000 = 1,25
PG – Percentual de esforço para grupos de usuários adicionais
PG = ( QM * UA ) / MC = ( 1,25 * 100 ) / 5.000 = 2,50%
BL – Baseline revisado do suporte de TI após o cálculo passa a ser o novo CS a ser utilizado na próxima movimentação.
BL = CS * PG = 6.500 * 2,50% = 6.662,5 horas (nova capacidade necessária para os serviços de TI)
Para cada 100 usuários adicionais haverá um impacto de 162,5 horas na equipe de
suporte. De uma capacidade inicial de 6.500 horas da equipe, após a movimentação
haverá necessidade de 6.662, 5 horas para suportar o serviço. Em termos práticos,
haverá necessidade de incorporar na equipe mais um profissional para suportar a
nova demanda. Os valores podem mudar para aumento da quantidade de
aplicações suportadas ou ativos de rede e servidores monitorados.
3.4. Gestão da Qualidade
Gans (2002) relata que serviço sem qualidade faz com que o cliente substitua o
provedor de TI. Por outro lado, a aplicação de melhores práticas gera lealdade no
relacionamento. Dessa forma, o Modelo prevê uma estrutura de gestão da qualidade
dentro do provedor de TI, responsável pela aquisição e certificação de práticas da
129
qualidade, disseminação da gestão da qualidade por toda a empresa e também pela
manutenção das certificações. Além, disto são atribuições dessa área:
− Elaborar um plano de qualidade cujo objetivo é determinar o progresso das
atividades e avaliar a conformidade dos produtos gerados e serviços prestados
com relação aos procedimentos, métodos e padrões estabelecidos;
− Implementar e manter um sistema de qualidade para prover requisitos claros de
qualidade, por meio de procedimentos e políticas. Os processos podem ser
apoiados pelo uso de ferramentas;
− Permitir aos contratos monitorar, analisar e agir diante de desvios no processo e
comunicar aos envolvidos.
Hall e Johnson (2009) argumentam que, às vezes, o movimento de padronização de
processos para garantir a qualidade deve ser adequado em áreas como serviços de
TI. Um processo de vendas que deu certo para infra-estrutura de redes pode ser
adotado para todos os serviços de TI ou cada área poderia ter seu processo
específico alinhado com um processo corporativo. Estes são alguns dos
questionamentos abordados pelos autores. Há processos em serviços de TI que
naturalmente resistem à definição e à padronização. Um exemplo é a área de
vendas de TI. São mais arte do que ciência. Devem existir flexibilidade, criatividade
e dinamismo nos mesmos. Outra visão importante em oferta e serviços de TI é a
implantação da gestão da qualidade, conforme os seguintes conceitos:
− Gerenciamento de Times;
− Custo da Qualidade de Serviços de TI;
− Auditoria;
− Melhoria Contínua;
− Análise de Dados;
− Relacionamento com o Cliente;
− Relacionamento com o Fornecedor.
130
Os processos e templates do Gerenciamento da Qualidade são mostrados no
quadro 32.
Quadro 32 – Gerenciamento da Qualidade
# Framework/Processo/Template Aplicação no Modelo
01 PMI-PMBoK-Gerenciamento da
Qualidade
Utilizado para aferir e garantir a qualidade nos projetos
do provedor de TI.
02 IPMA – Qualidade do Projeto; IPMA –
Conflitos e Crises.
Determinar os requisitos da qualidade dos projetos de
transição e de demandas eventuais. Necessário para
tratamento dos conflitos e crises durante o ciclo.
03 ISO 20000 – PDCA Diretrizes para o planejamento, execução, avaliação e
melhoria contínua dos processos de serviços de TI.
04 ISO 9001 - 7.3. Sistema de Gestão Sistema de Gestão utilizado na oferta e operação.
05 eSCM/SP - Rel06 – Relacionamento
com o Cliente
Diretrizes gerais para o relacionamento com o cliente.
06 SCM/SP - Rel07 – Relacionamento
com Fornecedores e Parceiros.
Diretrizes para o relacionamento com fornecedores e
parceiros.
07 CMMI 1.2 for Services – OPF
(Definição da área de Garantia e
Controle da Qualidade) e PPQA
(Processos de Planejamento e
Garantia da Qualidade)
Definição de atribuições e processos para
planejamento, garantia e controle da qualidade para
serviços de software.
08 CobiT - P08 – Gerenciar Qualidade Controles e maturidade do gerenciamento da
qualidade dos serviços ofertados.
09 Lean Six Sigma Diretrizes para eliminação de desperdícios, aumento
da velocidade dos processos e melhoria da qualidade
dos processos.
10 Template - Pesquisa de Satisfação
com usuário
Modelo para autorização de inicio do projeto.
Apresenta-se a seguir um método para avaliar o nível da qualidade dos projetos de
serviços de TI em andamento, conforme um conjunto de critérios.
131
Método para Avaliação do Nível da Qualidade em Operação de Serviços de TI
Existem oportunidades para melhoria da qualidade dos serviços de TI, utilizando os
conceitos clássicos. Conforme a figura 32, no inicio do projeto ocorre um período de
transição, onde o provedor de serviços de TI preocupa-se basicamente com alguns
fatores como absorção de pessoal e implantação dos modelos futuros de operação e
governança.
Figura 32 – Melhoria Contínua – Oferta e Operação de Serviços de TI
A qualidade em serviços de TI é implantada durante o período de transição, de tal
forma que a operação possa iniciar com todos os planos, procedimentos e
instruções de trabalho. Ainda durante a fase de transição, ocorre um PDCA de
melhoria de serviços. O ciclo PDCA do serviço de TI começa pelo planejamento (P-
Plan), em seguida as ações planejadas são executadas (D-Do), avalia-se se o que
foi feito está de acordo com o planejado (C-Check) e toma-se uma ação e promove-
se melhorias para eliminar ou mitigar os defeitos nos serviços executados (A-Act). O
132
PDCA para manter os resultados dos serviços em um nível desejado, pode também
ser chamado de SDCA (S- Standard), aplicando-se na etapa de melhoria
incremental para os padrões já atingidos. Conforme Falconi (2004), O PDCA,
quando utilizado sobre um SDCA, tem a função de alterar a maneira de trabalhar
(padrões) para conseguir melhores resultados. O primeiro ponto é que não dá para
usar bem o PDCA (melhoria da operação) sem o SDCA (boa operação).
Com o sucesso da implantação o provedor continua com a melhoria contínua após a
entrada em operação. Sendo assim, o projeto está preparado para realizar um salto
quântico (mudança acentuada) de melhoria radical por meio de algumas práticas
como inovação, Seis Sigma ou novas tecnologias. Ao atingir um novo patamar a
empresa consegue uma alta satisfação do cliente, gerando novas oportunidades de
negócios. Nem sempre isto ocorre, as vezes o provedor não mantém a qualidade
após a entrada em operação. Dessa forma, não existe nenhuma iniciativa de
melhoria da qualidade, podendo gerar uma insatisfação do cliente no longo prazo
(dois anos). O recomendado é que a fase de implantação dos serviços seja
executada dentro das melhores práticas para que a operação seja iniciada com os
modelos de operação e de governança factíveis e com padrão adequado de
qualidade. O que também pode ocorrer é o contrato não cumprir o que foi
determinado pelo plano de transição. Neste caso, ocorre uma deterioração cada vez
maior dos processos, podendo gerar uma perda do projeto.
Se o contrato tiver ainda no seu inicio, uma reversão através de um PDCA de
resolução de problemas pode ser a solução. O objetivo é retornar ao patamar
necessário para iniciar um novo ciclo de melhoria contínua. Implantação de
melhores práticas, sistema de qualidade e capacitação constante podem ser uma
solução. O quadro 33 mostra o método de posicionamento dos projetos no gráfico
da qualidade. Para cada critério é informado se a qualidade dos serviços de TI está
sendo radical (radical), incremental (increm.), manutenção (manut.) ou sem esforço
de melhoria (s/Esf.). Para a identificação dos contratos e projetos que estão
adotando melhoria radical, alguns fatores como adoção de estratégias de qualidade
total como Excelência de Qualidade (MBNQA, EFQM e PNQ), Lean Six Sigma,
Satisfação dos profissionais são fundamentais. Para que o projeto ou contrato esteja
em uma situação de melhoria incremental, os processos de gestão de TI, baseados
133
em melhores práticas, devem estar padronizados e funcionando plenamente. Para
uma avaliação quantitativa, pode ser fixado um valor de 10 pontos para cada
resposta positiva dos requisitos do quadro 33, facilitando a aplicação do método.
Quadro 33 – Critérios de Melhoria da Qualidade
# Critério Radical Increm Manut. s/Esf. 1 Níveis de Serviços de suporte (SLA) dentro da
meta contratual Sim Sim Sim Não
2 Satisfação do cliente dentro da meta estipulada Sim Sim Sim Não 3 Programas de Qualidade Total, Implantados (Lean,
Six Sigma, Gerenciamento Pelas Diretrizes e Padrões EFQM/MBNQA/PNQ)
Sim Não Não Não
4 Melhores Práticas de Governança do Contrato utilizadas e alinhadas com a Governança de TI (ex. CobiT, COSO, SAS 70, SOX, Val IT, Risk IT)
Sim Sim Não Não
5 Inovações e Gestão de Conhecimento utilizados de forma plena para a melhoria da qualidade
Sim Não Não Não
5 Melhores práticas de Gestão de TI, Engenharia de Software e Segurança da Informação utilizadas de forma plena na operação dos serviços do contrato, incluindo automatização (ex. ITIL, CMMI, PMBoK, eSCM, ISO 20000, ISO 27001)
Sim Sim Não Não
6 Clima Organizacional da Equipe de Operação e Projetos acima de 70%
Sim Não Não Não
7 Gestão de Projetos e Portfolio funcionando de forma plena, com metodologia, ferramentas e práticas (OPM3, PMBoK e outros).
Sim Sim Não Não
8 Processos e procedimentos padronizados, seguidos pela equipe e de acordo com as normas da qualidade (ISO 9001, CMMI, ISO 20000 e ISO 27001).
Sim Sim Sim Não
9 Inexistência de penalidades aplicadas Sim Sim Sim Não 10 Reuniões, evidências de registros, relatórios dentro
do prazo e na qualidade exigidos pelo cliente Sim Sim Sim Não
11 Comitê executivo do projeto, envolvendo alta direção do cliente e do provedor com reuniões periódicas.
Sim Não Não Não
12 Canal de comunicação efetivo do cliente com o provedor de serviços, incluindo escalação de problemas de forma automatizada e follow-up.
Sim Sim Não Não
Na melhoria incremental, os indicadores de níveis de serviços estão dentro das
metas e o usuário está satisfeito com o serviço, porém a qualidade total, inovações e
gestão do conhecimento ainda não faz parte dos processos. Para a fase de
manutenção, as práticas de gestão de processos e de governança, presentes na
melhoria incremental não estão implantadas, assim como canais de comunicação
não funcionam de forma plena. A preocupação é a constante negociação entre o
provedor e o cliente dos problemas de escopo, ausência de qualidade e inovações e
o fato do serviço prestado atender apenas o que foi contratado e nada mais. Projeto
134
e contratos classificados como sem esforço deixam de atender todos os requisitos
acordados com o cliente, levando à conflitos diários, alta insatisfação, penalidades
constantes e finalmente a perda do contrato ou projeto pelo provedor dos serviços.
3.5. Gestão do Conhecimento e da Inovação
No modelo MOPP, o processo de conhecimento e inovação (Knowledge &
Innovation) possui duas visões. A primeira delas é de colaboração interna por meio
de recursos como portais, gestão de conteúdo e redes sociais. Ajmal e Koskinen
(2008) relatam que as equipes de alto desempenho são formadas de pessoas com
diversas habilidades e conhecimentos trabalhando juntas em um período
determinado. A transferência de conhecimentos para toda a organização é
essencial. Há necessidade de aprender com as experiências e as práticas das
atividades diárias. As oportunidades detectadas a partir das necessidades dos
clientes dos provedores de TI dentro do conceito de pull ou “puxar” do mercado são
importantes. A segunda visão está relacionada ao conceito de push ou “empurrar”
para o mercado as idéias ou soluções criadas por meio de pesquisa &
desenvolvimento, conforme pode ser visto na figura 33. Os pontos mais escuros
(em azul) indicam as idéias que entram no método para avaliação, dentro dos
conceitos de inovação fechada e aberta.
Figura 33 - Funil de Inovação para Provedores de TI
135
O modelo prevê uma área de inovação dentro de provedores de serviços de TI, que
pode ser denominada de Conhecimento & Inovação. Esta área deve ter a
incumbência de ser catalisadora, ou seja, realizar pesquisa & desenvolvimento,
avaliar as idéias dos colaboradores e também de inovação aberta, acompanhar os
projetos de inovação, manter parcerias com universidades e centros de pesquisas e
buscar financiamentos para a inovação do provedor junto a órgãos de fomentos
como BNDES, Banco Mundial, Finep, CNPQ e FAPESP. A relação abaixo descreve
as etapas do processo de inovação dentro do MOPP:
− As idéias podem ser classificadas em Inicial, Estruturada ou Discutida. Na Inicial
existe uma iniciativa que pode trazer alguma forma de resultado (eficiência,
qualidade, controle, garantia de aderência etc.). Pode ser também a
caracterização de uma oportunidade ou problema a ser resolvido. Na Estruturada
deve existir pelo menos um objetivo e uma justificativa. Quanto mais próxima de
uma proposta, mais estruturada está a idéia. Na Discutida, o provedor já
consegue obter a opinião e colaboração de outras pessoas que acrescentaram
ou adequaram o objetivo e a justificativa;
− Na fase de proposta a idéia discutida deve passar por uma aprovação formal
do(s) patrocinador(es) para seguir em frente. Deve conter dados como objetivo,
justificativa, problemas resolvidos, metas, produtos e serviços, patrocinador,
riscos e orçamento necessário. A área de Conhecimento & Inovação do provedor
é responsável por esta etapa;
− Na fase de estudo de viabilidade deve ser realizado o trabalho necessário para
criar as condições para que os resultados sejam verificados de forma
experimental e controlada (com ou sem envolvimento de clientes). Por exemplo,
simulação e protótipo. O Principal produto desta fase é um relatório dos
resultados obtidos, comparando com a expectativa e com os cenários
existentes no cliente. Na existência de problemas, há necessidade de realizar
mudanças na proposta ou mesmo desistir da iniciativa;
− Na fase de projeto piloto, a equipe de inovação do provedor deve seguir os
critérios de um Projeto, conforme metodologia de gestão de projetos existente.
Deve envolver um caso real, de um cliente externo. Também deve ser gerado um
relatório com os resultados;
136
− Na fase final de inovação propriamente dita, o modelo pressupõe a utilização do
produto ou serviço de TI em larga escala e com método já bem definido e
experimentado. Os resultados em ganho de competitividade irão aparecer. Existe
uma disseminação do uso, contratos com clientes. Medições dos resultados são
realizadas para avaliar retorno, sendo divulgadas trimestralmente para todo o
provedor.
Uma matriz RACI determina papéis e responsabilidades. A partir das atividades, a
matriz apresenta quem é o executor da atividade (R - Responsible), gestor da
atividade (A - Accountable), consultado (C – Consulted) e informado (I – Informed). A
matriz RACI do processo de gestão da inovação de um provedor de TI é mostrada
no quadro 34. Ela determina as atribuições de cada área ou pessoa no processo de
inovação dentro do provedor de TI.
Quadro 34 – Matriz de Responsabidade (RACI) Fases Colaborador
(Interno/Externo) Financeiro Área
I&K Patrocinador?
Diretoria Projeto Comercial
Idéia R A
Avaliação Técnica R A
Avaliação do Investimento
R R A
Patrocínio C A, R
Desenvolvimento Produto/Serviço
I C A C R
Parceriais e Open Innovation
I R A
Comercialização I C I A I R
O Patrocinador e a Diretoria da empresa são os maiores responsáveis pelo sucesso
ou não da implementação dos processos do modelo MOPP no provedor de TI, pois
fornecem os investimentos, consciência e recursos necessários para fazer acontecer
a inovação.
137
Já para a Gestão de Conhecimento em Serviços de TI, o MOPP adaptou uma
versão do modelo ITIL - SKMS (Service Knowledge Management System), conforme
figura 34.
Camada de
Apresentação
Camada de
Processamento de
Conhecimento
Camada de
Integração da
Informação
Ferramentas, Dados
e Informações
Portal
Governança
de TI
Portal
Gestão de
Documentaçào
CMDB
DSL
Planilhas, doc, forms
Portal
Governança,
Gestão Serviços e
SLM
Auto-Atendimento
no Portal do
Usuário
Cálculo
Indicadores
Templates e
Relatórios
Monitoramento e
Performance Infra
Capacity
Planning do
Negócio
Esquema das
Ferramentas
(NetFlow e FlexVision)
Análise e Reconciliação de
Dados SQL’s Pré-Formatados
SAP Sw de
ITSM e
Segurança
a Estruturados
Aplicação,
Infra e
Sistemas
Sistema de Conhecimento Monitoramento Infra de TI
1 2
Docs.
Eletrônicos
Figura 34 – Gestão de Conhecimento em Serviços de TI Fonte: Santos e Campos (2009, p.134)
O modelo adaptado pode ser implantado de forma completa ou reduzida em
serviços de TI. Parte-se da premissa de que todo o conhecimento vinculado aos
serviços de TI, prestados pelo provedor de TI, necessita estar integrado e alinhado
com a perspectiva do negócio (SANTOS; CAMPOS, 2009).
Na camada de apresentação é apresentado um portal de inovação & conhecimento
para rede social interna, colaboração, coleta de idéias, propostas e inovações para
melhorias dos serviços de TI. Na camada de processamento de conhecimento,
recomenda-se pelo modelo implantar um book de indicadores, baseado nos
processos de serviços de TI. Na camada de integração de informações são
desenvolvidas consultas padrões para coleta de informações de análise de
desempenho, capacidade e monitoramento dos serviços. Na camada de avaliação e
ferramentas é criada uma base de dados de configurações (CMDB) usando recursos
138
já existentes em ferramentas de IT Service Management do mercado. O quadro 35
mostra as práticas recomendadas no modelo MOPP para a gestão de inovação e
conhecimento de provedor.
Quadro 35 – Processos para Conhecimento e Inovação Provedor TI # Frameworks/Processo/Template Aplicação no Modelo MOPP
01 e-SCM/SP – knw01 – Compartilhar
Conhecimentos; knw03 – Sistema de
Conhecimento; knw05 – Engajamento de
Conhecimento; knw06 – Reuso; ppl01 –
Motivação para Inovação; prf11 –
Implantação da Inovação.
Coleta, armanenamento e transferência de
conhecimento por todos os projetos do provedor.
Formação de comitê de conhecimento, sistemas,
base de conhecimento, banco de dados,
aplicações, portais e políticas para utilização por
todos os projetos.
02 IPMA – Trabalho Colaborativo à
Distância; IPMA – Gestão do
Conhecimento em Projetos
Desenvolvimento de AVA (Ambiente Virtual de
Ensino) e e-Learning para disseminar
conhecimento. Coleta, armazenamento e
disseminação de conhecimento tácito e explícito
por todos os projetos.
03 CMMI for Services – Organizational
Innovation and Deployment
Seleção e implantação de inovações dentro dos
serviços shared e também nos projetos nos
clientes do provedor.
04 ITIL V3 – ST – Gestão do Conhecimento Aplicação do modelo SKMS do ITIL v3 dentro dos
provedores, desde a coleta dos dados dos
serviços em formato estruturado e não
estruturado, formatação e apresentação (portais,
base de conhecimento e aplicações).
05 Templates – Formulário para proposta de
inovação
Permite aos profissionais do provedor informar as
suas idéias ou propostas para posterior avaliação
de viabilidade.
06 Templates – Formulário para montagem
de documento de conhecimento
Auxilia a montagem de documento de
conhecimento em sistemas de serviços de TI
(ITSM)
139
3.6. Escritório de Projetos (PMO - Project Management Office)
No modelo MOPP, a visão de escritório de projetos serve para apoiar os demais
processos do ciclo de vida de outsourcing nas melhores práticas de gerenciamento
de projetos, programas e portfolio sob a ótica do provedor. Todos os projetos,
independentes do ciclo, devem ser automatizados em ferramentas de
gerenciamento de portfolio, para gestão e alinhamento com a estratégia do
provedor.
− Contratação de Serviços
Pelo modelo a contratação deve utilizar escritórios de projetos (PMO) centralizados,
ou seja, escritórios centrais dos provedores de TI. Nesta fase as principais
atividades de um PMO devem ser:
� Centralização da Documentação;
� Treinamento Gerentes de Projetos;
� Padronização de processos dos projetos de contratação;
� Governança do projeto;
� Auditoria do projeto;
� Disseminação de melhores práticas para as equipes de projetos.
− Projetos de Transição
Esta fase utiliza intensamente as funções de escritório de projetos. O MOPP
pressupõe que deve existir PMOs descentralizados conforme a importância do
projeto de transição para o provedor. O PMO descentralizado deve estar integrado
com o centralizado. O modelo pressupõe o uso da mesma ferramenta de gestão,
possibilitando armazenamento e acompanhamento do portfolio de projetos do
provedor. As funções nesta etapa são:
� Ponto focal de relacionamento entre a equipe de transição e o cliente;
� Aprovação das entregas da transição, antes da submissão ao cliente;
� Capacitação da Equipe do Projeto;
� Governança do Projeto de Transição;
� Auditoria do Projeto;
� Risco do Projeto.
140
− Operação de Serviços
Esta fase utiliza as práticas de gerenciamento de projetos dentro do conceito de
projetos de demandas eventuais e de movimentação de baseline. O modelo utiliza
as práticas da Metodologia de Gerenciamento de Projetos e a estrutura de PMO
centralizado do provedor. Os projetos eventuais da operação também devem fazer
parte do portfolio de projetos do PMO centralizado. As principais etapas são:
� Uso da Metodologia de Gerenciamento de Projetos;
� Capacitação da Equipe do Projeto;
� Auditoria dos Projetos Eventuais da Operação;
� Padronização e documentação das práticas;
� Fornecimento de ferramentas de Project Management para a equipe do
projeto;
� Disseminação de melhores práticas para os projetos eventuais.
− Estrutura típica de PMO do Provedor de Serviços de TI
Apoiados por ferramentas de PPM (Project and Porfolio Management) e de EPM
(Enterprise Project Management) o provedor pode gerenciar implementar o seu
escritório de projetos. O primeiro passo é coletar os dados do portfólio atual e
automatizá-lo, com as seguintes atribuições:
� Elaboração, divulgação e treinamento das equipes dos projetos na
Metodologia de Gerenciamento de Projetos e Portfolio;
� Registros e acompanhamento de issues (problemas);
� Registro e acompanhamento de riscos;
� Registros das Auditorias dos Projetos;
� Registros e Análise dos Indicadores Gerenciais dos Projetos;
� Acompanhamento de time sheet (registro de horas trabalhadas das equipes);
� Acompanhamento dos cronogramas dos projetos e repositório de
documentos;
� Controle de treinamentos e coaching dos gerentes de projetos;
� Gerenciamento da demanda (incidentes, solicitações de serviços e idéias
para inovação);
� Registros dos chamados de Service Desk do PMO;
� Gestão Financeira do portfólio;
141
� Gestão de troubled projects (projetos de serviços de TI com problemas);
� Dashboard para relatórios gerenciais para a diretoria do provedor.
O quadro 36 mostra as práticas recomendadas no modelo MOPP para o Escritório
de Projetos (PMO).
Quadro 36 – Escritório de Projetos
# Processo/Template Aplicação no Modelo MOPP
01 OPM3 – Processos de Gestão de
Portfolio; Processos de Gestão
de Programas
Utilização na elaboração da Metodologia de
Gerenciamento de Projetos e PMO dos provedores.
Auditoria dos projetos, capacitação dos Gerentes de
Projetos, padronização dos processos, customização das
ferramentas de PPM (Project and Portfolio Management)
e EPM (Enterprise Project Management).
02 IPMA – Controle de Projetos Inspeção nos projetos, PDCA, registros de desvios e
plano de ação.
03 CMMI for Services – Strategic
Service Management; PP –
Project Planning; IPMA –
Integrated Project Management;
Project Monitoring and Control;
Quantitative Project Management;
Determinação da gestão de demandas, avaliação
financeira do portfólio e gestão quantitativa dos projetos.
04 Lean Six Sigma Seleção dos projetos. Avaliação da contribuição dos
projetos para as metas estratégicas do provedor e
quantificação dos processos e dos resultados.
05 ITIL v3 SE – Gestão de Portfolio
dos Serviços; SD – Gestão de
Catálogo dos Serviços
Auxílio na análise e inclusão dos serviços resultantes dos
projetos dentro do portfólio (realizados, atuais e futuros) e
do catálogo (serviços atuais).
08 Templates – Lista de Verificação
Auditoria de Projetos
Lista para auditoria de projetos, incluindo apontamentos
de conformidades e oportunidades de melhorias
09 Template – Matriz de Seleção de
Portfolio de Projetos
Matriz para seleção dos projetos para compor um portfolio
conforme necessidades do negócio.
142
3.7. Gestão de Segurança (Information Security Management)
No modelo MOPP, a segurança da informação é aplicada na oferta de outsourcing
para serviços compartilhados como também nos serviços executados nas
instalações dos clientes. O modelo considera importante que os provedores
obtenham a certificação ISO/IEC 27001, como também pode colocar em práticas as
suas recomendações, não somente na área escopo da certificação, como também
em toda a empresa e em seus clientes. Outro ponto importante é a parceria com
players (competidores) mundiais de ferramentas de segurança da informação, pois o
objetivo é a implementação e consultoria nas melhores práticas automatizadas. Para
a finalidade do modelo, a segurança da informação é dividida de forma prescritiva
em governança, informações para gestão, identidade e acesso e gestão de
ameaças, conforme quadro 37.
Quadro 37 – Áreas da Segurança da Informação
Governança de Segurança da
Informação (ISG – Information Security
Governance)
Gestão de Informações de Segurança
(SIM - Security Management
Management)
Gestão de Ameaças (TM - Threat
Management)
Gestão de Identidade e Acesso (IAM -
Identity and Access Management)
No modelo MOPP, o nível menor é de gestão de ameaças que os provedores
podem oferecer aos seus clientes como serviço. Abrange tecnologias como
antivírus, anti-spam, firewall ou IDS (monitora o tráfego contínuo da rede,
identificando ataques que estejam em execução). Os provedores devem fazer
parcerias com fornecedores de ferramentas e soluções do mercado. O objetivo é a
implementação da solução com a consultoria necessária para as empresas. O
segundo nível é de Gestão de Identidade e Acesso que garante controle sobre a
criação de usuários e sobre os acessos a cada ambiente, aplicação ou recurso da
organização. Abrange temas tecnológicos como provisionamento (alocar para cada
usuário a conta e direitos adequados para uso dos recursos corporativos), controle
de acesso (garantir a prevenção de acessos não autorizados mantendo a
integridade das informações), Single Sign-On (ponto único de acesso dos usuários).
143
O terceiro nível é o de gerenciamento das informações de segurança que processa
todas as informações geradas pelos sistemas de segurança, mantendo a
auditabilidade destes sistemas e atuando em qualquer situação de anormalidade.
Abrange tecnologias como portais de visualização dos eventos de segurança,
correlação, vulnerabilidades e outras informações detectadas pelas ferramentas de
TM e IAM, auditoria de correlação de eventos que coleta dados, audita e efetua
correlações para tomada de decisões, análise de vulnerabilidades que permite aos
clientes realizar verificações regulares em determinados componentes de sua rede,
como por exemplo, servidores e roteadores para encontrar brechas de sistemas ou
de configurações, classificação e identificação de ativos. Estes fatores permitem
classificar os ativos por confidencialidade, integridade e disponibilidade para medir o
prejuízo com a perda de um destes três elementos. Também existe o Forensics para
coleta de provas e evidências no ambiente dos clientes para causas forenses.
O quarto nível refere-se à governança de segurança da informação, que contém
temas como Gestão de Riscos relacionados à segurança da informação,
monitoramento dos indicadores de segurança e alinhamento da segurança da
informação com o negócio da empresa. Neste aspecto, o provedor deve utilizar um
modelo de maturidade para realização de assessment nos potenciais clientes, antes
da implantação ou consultoria nas tecnologias e processos. Existem modelos do
mercado, como por exemplo o modelo desenvolvido para aplicações e alinhado com
o CMMI, visto em Carbonel (2008).
O quadro 38 mostra as práticas recomendadas no modelo MOPP para a gestão de
inovação e conhecimento de provedor.
144
Quadro 38 – Processo de Gestão da Segurança da Informação
# Processo/Template Aplicação no Modelo MOPP
01 ISO 27001 – Todos os Processos Requisitos gerais para determinação dos
políticas, planos, procedimentos, controles,
conscientização, auditoria de segurança e
compliance dos serviços operados pelo provedor.
02 ISO 27005 – Todos os Processos Identificação, avaliação e controles dos riscos
relacionados com a segurança dos projetos.
03 CobiT – PO9 – Avaliar e Gerenciar Riscos;
DS5 – Garantir Segurança dos Sistemas;
DS4 – Garantir Continuidade dos Serviços
Controles e Requisitos de Auditoria e Governança
para Segurança, Riscos e Continuidade da oferta
e operação dos serviços de TI pelos provedores.
04 ITIL v3 – SD – Gerenciamento de
Segurança; SO – Gerenciamento de
Acesso; SD – Gerenciamento de
Continuidade; SD – Gerenciamento de
Disponibilidade
Requisitos de segurança lógica e física. Melhores
práticas para gestão e testes de continuidade.
Determinação das regras de acessos e dos
critérios de disponibilidade da infra e aplicações
dos projetos do provedor.
05 ISO 20000 – Gerenciamento de
Segurança; Gerenciamento de
Disponibilidade e Continuidade
Determinação da política de segurança, gestão
dos incidentes de segurança, elaboração do
plano de continuidade e os testes relacionados
nos projetos.
05 eSCM/SP – thr04 – Segurança; thr07 –
Disaster Recovery
Identificação e gestão de requisitos de segurança
física, lógica, acesso. Recomenda-se também
utilizar as diretrizes para uso em segurança de
aplicações e banco de dados dos projetos.
06 CMMI for Services – Continuidade do
Serviço
Estabelecimento e manutenção dos planos de
segurança da operação dos serviços fornecidos
pelos provedores.
08 Template – BIA – Business Impact Analysis Determinação das informações estratégicas do
provedor para avaliação e tratamento dos riscos,
bem como elaboração do plano de continuidade.
09 Template – Plano de Continuidade Plano de Continuidade do provedor
145
3.8. Governança & Compliance para Provedores de TI
O outsourcing de TI é uma estratégia que objetiva aumentar a eficácia dos sistemas
de informações nas organizações. Segundo Robinson (2007), esta necessidade
pode ser traduzida em forma de alinhamento estratégico, gestão eficiente de
recursos e ativos de TI, gestão de portfólio, investimentos de TI, gerenciamento de
riscos e manutenção da excelência operacional. Para Parkinson e Baker (2005),
informações de governança devem gerar suporte ao negócio, adequação às leis e
regulamentos e também devem gerar resultados confiáveis e transparentes. Dessa
forma, a Governança & Compliance do modelo MOPP para provedores de TI refere-
se a uma visão interna das áreas do provedor. Não apenas em termos de
governança de TI, mas também governança corporativa e compliance com
regulação. Sphilberg at al (2007) relatam que alinhar uma TI com fraco desempenho
aos objetivos estratégicos não é governança de TI. Silva (2009) constata, em
pesquisa realizada, que empresas de TI não costumam priorizar planejamento
estratégico de tecnologia da informação (PETI). Segundo a autora, existe um conflito
entre planejamento estratégico empresarial e o PETI em provedores.
Os provedores precisam possuir flexibilidade para que possam responder
rapidamente às alterações competitivas e do mercado. Também precisam
estabelecer e manter uma estrutura adequada de controles financeiros e
procedimentos para emissão de relatórios financeiros, além de evidenciar eficácia da
estrutura de controles internos e procedimentos para emissão das demonstrações
financeiras. Os controles e procedimentos são atestados por auditoria interna. Mais
a frente devem ser auditados e atestados por auditoria independente seguindo a
norma SAS 70. Como preparação para este compliance, o provedor de TI deve
adotar as práticas PCAOB, COSO, CobiT e ISO/IEC 17999. Estes padrões são a
base mínima necessária para a montagem de um conjunto referencial de melhores
práticas em controles internos.
Um dos frameworks utilizados no modelo é a a SAS 70, a qual auxilia o provedor
nas suas qualificações para atendimento a clientes sujeitos a normas regulatórias, a
exemplo da lei Sarbanes-Oxley, Basel II, GxP ou HIPAA. Os relatórios formais de
auditoria são importantes no processo de comunicar a efetividade dos controles
146
internos existentes. Há dois tipos de relatórios da SAS 70. No tipo 1 a avaliação do
auditor é se a descrição dos controles declarada representa a operação em
determinada data e se os controles foram desenhados de forma adequada a
alcançar os objetivos específicos. O tipo II abrange todos os aspectos do tipo I, além
de incluir opinião sobre se os controles que foram testados operam com efetividade,
permitindo obter garantia de que os objetivos de controle foram atingidos durante um
período mínimo de seis meses. O SAS 70 permite ao provedor divulgar e evidenciar
para os seus clientes a eficácia dos seus controles internos. A utilização atual das
melhores práticas incorporadas neste padrão significa que os objetivos e atividades
de controle têm total transparência. Cria-se uma confiança na relação cliente e
provedor de TI.
O modelo de governança deve seguir as melhores práticas, endereçando os
aspectos de alinhamento estratégico, entrega de valor, riscos, recursos e
monitoramento. Abaixo, são mostrados os principais domínios da governança com
seus principais requisitos, sob o ponto de vista do modelo MOPP:
a. Alinhamento TI Interna x Negócio do Provedor
A área interna de TI deve alinhar suas estratégias com a área de negócio do
provedor de TI. Assegurará dessa forma que o investimento realizado esteja em
harmonia com os objetivos estratégicos da organização.
b. Entrega de Valor
Deve ser estabelecido um modelo de medida de valor entregue pela área de TI ao
negócio do provedor antes de embarcar em grandes projetos. Outro objetivo desta
fase é levantar se a área interna entrega benefícios de acordo com um custo
compatível. A governança procura estabelecer um modelo de medida de valor
entregue pela TI interna ao provedor para todas as suas atividades e projetos.
c. Gerenciamento de riscos
O modelo de governança corporativa do provedor deve assegurar transparência,
adequada divulgação, eficientes processos de tomada de decisão e controle, além
de tratamento justo e igual para todos os sócios ou acionistas. Para cada vez mais
aperfeiçoar a estrutura de governança, a área interna de TI deve reforçar os seus
147
controles internos, levando em consideração todos os aspectos relacionados à
normas regulatórias. Essas normas determinam que as empresas adotem uma série
de medidas que têm como objetivo proteger investidores ao exigir maior precisão e
confiabilidade das divulgações empresariais. A Governança assegura que os riscos
mais significantes da área interna de TI possam ser estudados e gerenciados de
forma apropriada. A metodologia COSO-ERM (Enterprise Risk Management) pode
ser utilizada para esta finalidade. Contempla as seguintes atividades:
− Criação de Ambiente Interno para Gestão de Riscos;
− Determinação de objetivos (estratégia, apetite ao risco e tolerância);
− Identificação de eventos;
− Entendimento dos Riscos;
− Avaliação (assessment) dos Riscos;
− Respostas aos Riscos;
− Atividades de Controles;
− Informacão e Comunicação;
− Monitoramento.
Quando a área interna de TI do provedor também é responsável em manter serviços
de TI para clientes externos do provedor, a exemplo de Hosting e NOC (Network
Operation Center), torna-se imprescindível controlar os riscos operacionais conforme
práticas já consolidadas (ex. Segurança, Riscos e Continuidade da NIST – National
Institute of Standard and Technology dos Estados Unidos). Também há necessidade
de manter um eficaz plano de continuidade de serviços baseados na ISO 27001 e
BS 25999.
d. Gerenciamento de Recursos
O objetivo do gerenciamento de recursos na governança da área interna do
provedor de TI é garantir que os recursos utilizados no mesmo estão sendo capazes
de atender a estratégia de TI. Envolve também assegurar o estudo da existência de
capacidade suficiente para dar suporte às atividades críticas do provedor e
otimização de custos das atividades contratuais.
148
A área interna de TI deve buscar a satisfação dos clientes externos e dos usuários
finais do provedor de TI, obtida quando existe, em cada um dos processos
envolvidos na prestação dos serviços, a preocupação de satisfazer a necessidade
do cliente interno do próximo processo. Fazer com qualidade será sempre a forma
mais econômica de realizar qualquer serviço escopo do provedor de TI é outro
objetivo.
e. Monitoramento e Desempenho
O objetivo deste domínio para a área interna de TI é a medição e monitoração das
atividades de gestão. É possível desta maneira governar a prestação dos seus
serviços e assegurar o seu alinhamento com a estratégia do provedor de TI e os
níveis de serviços (SLAs) mantidos com os clientes externos pelas diversas áreas.
Nesta fase devem ser utilizadas as métricas definidas no CobiT v4.1 (KPI – Key
Performance Indicator e KPG – Key Performance Goal) bem como o modelo
Balanced Scorecard para melhor alinhamento e integração com os objetivos
estratégicos. O quadro 39 mostra as práticas recomendadas no modelo MOPP para
a governança e compliance em provedor.
O trabalho destaca no capítulo seguinte as matrizes de relacionamento. Elas são
necessárias para entender a relação dos frameworks com os ciclos de vida de
outsourcing, ofertas dos provedores e necessidades do mercado.
149
Quadro 39 – Governança & Compliance em Provedores de TI
# Processo/Template Aplicação no Modelo MOPP
01 CobiT – Todos os Processos de
Planejamento e Organização, Aquisição e
Implantação, Entrega e Suporte,
Monitoramento e Avaliação.
Requisitos gerais Governança, Controles e
Auditoria dos processos de oferta e operação de
serviços de TI dos provedores. Auxílio no
alinhamento
02 COSO – Todos os Processos de Ambiente
de Controle, Avaliação e Gerenciamento
dos Riscos, Atividades de Controle,
Informação e Comunicação,
Monitoramento.
Auxílio ao CobiT para os processos de
governança do provedor. Contemplam riscos,
manual de conduta, ética, segregação de
funções, alçadas, riscos corporativos e controles
de prevenção e de detecção das atividades do
provedor.
03 ITIL SE – Gestão Financeira; Gestão de
Portfolio dos Serviços; Gestão da
Demanda.
Análise financeira de fornecimento do serviço.
Inclusão do serviço fornecido dentro do portfólio
do provedor e gerenciamento das demandas
internas e externas (clientes) por novos serviços.
04 ISO 27005 – Identificação, Análise e
Controle dos Riscos
Auxílio no BIA e nas avaliações dos riscos
operacionais do provedor.
05 Val IT – VG – Governança de Valor;
Gestão de Portfolio (PM); Gestão de
Investimentos (IM)
Determinação dos investimentos realizados pelo
provedor para suportar a oferta e operação dos
serviços do provedor, bem a avaliação dos seus
benefícios e a sua governança (confiabilidade e
transparência).
05 ISO 38500 – Todos os Princípios:
Responsabilidade, Estratégia, Aquisição,
Desempenho, Conformidade e Ambiente
Humano.
Utilização dos princípios para determinação das
responsabilidades da alta direção do provedor,
como também da sua estratégia e conformidade
na oferta e operação dos serviços de TI.
06 OPM 3 – Gestão dos Processos de
Portfolio
Aplicação na gestão de projetos e portfólio e na
priorização dos projetos. Utilização no apoio de
implementação de ferramentas de PMO,
treinamentos e metodologias de governança de
projetos.
08 Template – Auditoria dos Controles &
Compliance
Utilizar para auditoria dos processos do provedor,
com a finalidade de compliance geral.
150
4. MATRIZES DE RELACIONAMENTO
Nesta seção são apresentadas matrizes de relacionamento do modelo, necessárias
para determinar a melhor prática a ser aplicada na oferta e operação de serviços de
TI, conforme o tipo de estratégia do provedor e a necessidade do mercado.
As ofertas dos provedores de TI abrangem software, hardware, redes, processos de
negócios e vendas de soluções. Para cada tipo de oferta existem desafios na busca
da melhor prática que pode ser oferecida aos clientes. Estas dificuldades passam por
todas as fases do ciclo de vida de outsourcing. Percebe-se nos modelos atuais
analisados uma preocupação em combinação de práticas, porém não existe um
relacionamento com a fase do ciclo de outsourcing. Os frameworks estão em um
nível elevado para uso efetivo pelos provedores. A melhor definição é que sejam
diretrizes prescritivas para que a empresa ou o provedor possam utilizar a melhor
combinação de práticas e adequá-la de acordo com o tipo de oferta e fase do
outsourcing. Uma dificuldade de implementação dos modelos atuais é que nem
sempre a empresa possui o conhecimento e visão detalhada das práticas para
montar o melhor conjunto de soluções para a oferta e operação dos serviços.
4.1. Matriz de Relacionamento Oferta x Ciclo de Vida x Prática
O quadro 40 mostra um relacionamento entre as principais oferta e os processos dos
frameworks que foram considerados no modelo MOPP. O detalhamento maior,
incluindo as práticas para cada oferta, está contemplado na aplicação desenvolvida
e que faz parte desta pesquisa. Na fase de contratação de um serviço como o
Service Desk, é relevante utilizar frameworks que tenham processos vinculados a
outsourcing, atendimento de usuários, base de conhecimento e suporte remoto a
exemplo de eSCM/SP e do ITIL. Na fase do projeto de implantação, os frameworks
mais indicados são de projetos como o PMBoK, mas o ITIL e CobiT devem ser
utilizados nesta fase para elaboração do Modelo de Operação e de Governança. Já
na operação, utiliza-se plenamente modelos focados no dia-a-dia das atividades
como ISO 20000, ITIL e Lean Six Sigma.
151
Quadro 40 – Matriz Relacionamento Oferta x Ciclo de Outsourcing x Prática
Oferta/Macro Processo
Contratação Projeto Operação
Service Desk e Field Support
• eSCM/SP
• CobiT
• ISO 9001
• ITIL
• PMI/PMBok
• IPMA
• CobiT
• ITIL
• ITIL
• LEAN SIX SIGMA
• ISO 20000
• ISO 9001
NOC / SOC (Network Operation Center)
• eSCM/SP
• CobiT
• ISO 9001
• ISO 27001
• ISO 27005
• PMI/PMBok
• IPMA
• CobiT
• ITIL
• SO 27001
• ITIL
• ISO 20000
• ISO 27001
• ISO 27005
• ISO 9001
Sustentação de Software (Manutenção Corretiva, Evolutiva e Testes)
• eSCM/SP
• CMMI
• CobiT
• ISO 9001
• PMI/PMBok
• IPMA
• CMMI
• CMMI
• ITIL
• ISO 20000
• PCMM
• ISO 9001
BPO – Business Process Outsourcing
• eSCM/SP
• CobiT
• ISO 9001
• Val IT
• PMI/PMBok
• IPMA
• OPM3
• ITIL
• ISO 27001
• ISO 20000
• CobiT
• Val IT
• ISO 9001
Suporte de Infraestrutura de TI (Servidores, Sistemas Operacionais, Banco de Dados, Redes).
• eSCM/SP
• CobiT
• ISO 9001
• ITIL
• PMI/PMBok
• IPMA
• ITIL
• ISO 20000
• ISO 27001
• ISO 9001
152
4.2. Matriz de Relacionamento Ciclo de Vida x Práticas de Conhecimento
O quadro 41 mostra um relacionamento das fases do ciclo de vida de outsourcing
com os macroprocessos de governança, qualidade, conhecimento e inovação. Este
relação é importante, pois os provedores podem utilizá-la para determinar os valores
entregues para o cliente ao longo do seu relacionamento, agregando diferencial em
relação aos seus competidores.
Quadro 41 – Matriz Ciclos de Vida x Práticas de Conhecimento
Oferta/Macro Processo
Governança & Compliance
Qualidade Inovação & Conhecimento
Segurança
Informação
Contratação • SAS 70
• CobiT
• SOX
• ISO 38500
• VAL IT
• Lean Seis Sigma
• ISO 9001
• ISO 20000
• e-SCM
• ITIL (SKMS)
• IPMA
• E-SCM
• ISO 27001
• ISO 27005
• COSO
• CobiT
• e-SCM/SP
Projeto • IPMA
• SAS 70
• CobiT
• SOX
• OPM3
• ISO 27005
• PMI
• IPMA
• Lean Seis Sigma
• ISO 9001
• PMI
• IPMA
• ITIL
• HDI
• ISO 20000
• ISO 27001
• ISO 27005
• CobiT
Operação • SAS 70
• CobiT
• SOX
• COSO
• ISO 27005
• ISO 38500
• VAL IT
• Lean Seis Sigma
• ISO 9001
• ISO 20000
• CMMI
• ITIL
• HDI
• ISO 20000
• e-SCM/SP
• ISO 27001
• ISO 27005
• COSO
• CobiT
153
A matriz pode ser analisada da seguinte forma: Na etapa de contratação, os
frameworks e padrões de governança & compliance mais indicados são a SAS 70,
CobiT, SOX, úteis para elaboração de propostas e negociação. Já para a etapa de
projeto de implantação dos serviços de TI (nas instalações do cliente), são
acrescentados outros frameworks indicados para governança de projetos, a exemplo
de OPM3, IPMA e ISO 27005, necessários para a elaboração do Modelo de
Governança de Projetos (OPM3, IPMA) e Plano de Riscos (ISO 27005). Para a
operação, é adicionado o COSO, pois existe uma necessidade nesta etapa de
alinhamento com a governança corporativa da empresa, como também de
desenvolvimento de controles internos, a exemplo de código de ética e segregração
de funções.
4.3. Matriz de Relacionamento Oferta do Provedor x Processos dos
Frameworks x Necessidades do Cliente
O quadro 42 mostra um exemplo da matriz de relacionamento dos processos
conforme a oferta do provedor e as necessidades do cliente. A versão completa que
abrange todas as ofertas do provedor encontra-se no banco de dados que faz parte
desta tese. Os clientes do mercado financeiro como também os que possuem ações
negociadas em bolsas de valores americanas necessitam de maior atenção a
normas regulatórias como Basel (Acordo da Basiléia) e SOX (Lei Sarbanes-Oxley),
portanto, as ofertas do provedor, principalmente as que envolvem serviços em
produção a exemplo de monitoramento de redes, gerenciamento de datacenter e
manutenção corretiva de aplicações devem incorporar as práticas adequadas como
Cobit, ISO 27001 e COSO.
154
Quadro 42 – Relacionamento Oferta x Processos x Mercado
Oferta/Cliente Telecom Banking Indústria Call Center Empresa SOX ...
Varejo Governo
Service Desk e Field Support
COPC
ITIL
ISO 9001
ITIL
CobiT
ISO 9001
ITIL
ISO 9001
COPC
ITIL
ISO 9001
COSO
CobiT
ITIL
ISO 9001
ITIL
ISO 9001
ITIL
ISO 9001
CobiT
ISO 20000
NOC / SOC (Network and Security Operation Center)
ITIL
ISO 20000
ISO 27001
ISO 9001
CobiT
ITIL
ISO 20000
ISO 27001
SAS 70
BS 25999
ISO 9001
ITIL
ISO 20000
ISO 27001
ISO 9001
ITIL
ISO 20000
ISO 27001
COSO
CobiT
ISO 27001
SAS 70
BS 25999
ISO 9001
ITIL
ISO 20000
ISO 27001
ISO 9001
ITIL
ISO 20000
ISO 27001
ISO 9001
CobiT
Sustentação de Software (Corretiva, Evolutiva e Testes)
CMMI
ITIL
ISO 20000
ISO 27001
CMMI
CobiT
ITIL
ISO 20000
ISO 27001
SAS 70
BS 25999
CMMI
ITIL
ISO 20000
ISO 27001
CMMI
ITIL
ISO 20000
ISO 27001
CMMI
COSO
CobiT
ISO 27001
SAS 70
BS 25999
ITIL
ISO 20000
ISO 27001
ITIL
ISO 20000
ISO 27001
CobiT
ISO 9001
BPO – Business Process Outsourcing
ITIL
ISO 20000
ISO 27001
ISO 9001
CobiT
ITIL
ISO 20000
ISO 27001
SAS 70
ISO 9001
ITIL
ISO 20000
ISO 27001
ISO 9001
ITIL
ISO 20000
ISO 27001
COSO
CobiT
ISO 27001
SAS 70
BS 25999
ISO 9001
ITIL
ISO 20000
ISO 27001
ISO 9001
ITIL
ISO 20000
ISO 27001
ISO 9001
155
No modelo, as práticas a serem priorizadas podem mudar conforme as necessidades
do cliente. Por exemplo, oferta de fábrica de software em empresas que estão
sujeitas a SOX devem contemplar também práticas como COSO e CobiT e não
apenas CMMI e ISO 9001. Para possibilitar um conhecimento mais detalhado do
MOPP, o capítulo seguinte apresenta a aplicação do modelo por meio de estudos de
casos, abrangendo as três fases principais do ciclo de vida: Contratação,
Implantação e Operação.
156
5. APLICAÇÃO DO MODELO
Esta pesquisa utilizou um projeto de casos múltiplos. O ciclo de vida de outsourcing,
presente no MOPP é comum e vincula os três estudos de casos. Cada estudo de
caso em particular consistiu no desenvolvimento em um estudo completo (YIN,
2005). Procurou-se em cada um dos casos evidências convergentes com respeito
a oferta e operação de serviços de TI. O autor influenciou nos resultados dos
trabalhos da pesquisa-ação, por conta das qualificações, certificações e do uso do
modelo apresentado nesta tese.
A conclusão de cada caso está relacionada com os outros casos. Os estudos foram
baseados em três situações diferentes do ciclo de vida do MOPP, conforme mostra
a figura 35.
Figura 35 – Fases do Estudo de Caso Múltiplo
O primeiro estudo de caso explora a elaboração de uma proposta técnica, com a
aplicação de técnicas de combinação de práticas dos processos de contratação do
modelo MOPP em um prazo de quatro meses. O segundo estudo de caso aborda
um projeto de transição realizado em uma empresa de mineração, onde as técnicas
do MOPP puderam ser aplicadas. O prazo do projeto foi de oito meses. O autor
157
participou como responsável pela governança de TI. Finalmente, na terceira situação
é abordado um estudo da operação de serviços de TI aproveitando a visão dos
processos em execução no dia-a-dia por meio de uma implantação e certificação da
norma ISO/IEC 20000 (Gestão de Serviços de TI) em um prazo de dez meses.
Figura 36 – Aplicação do Modelo nos Estudos de Caso
A figura 36 mostra as etapas, áreas de conhecimento e métodos do modelo MOPP
utilizado em cada estudo de caso. Apresenta-se a seguir os casos com seus
respectivos conteúdos e resultados.
5.1. Contratação: Proposta Técnica de Infraestrutura de TI de Instituição
Financeira Internacional
De acordo com Yin (2005), a elaboração de um protocolo é uma estratégia seguida
para aumentar a confiabilidade do estudo de caso. O protocolo para o estudo de
caso é mais do que um instrumento, pois contém os procedimentos e as regras
gerais são seguidas ao se utilizar o instrumento. Para atingir maior confiabilidade, os
procedimentos metodológicos são descritos com detalhes, a fim de possibilitar o
entendimento e reuso do método. Buscou-se descrever de forma clara o protocolo
158
de pesquisa utilizado. Importante ressaltar que o protocolo de pesquisa serviu como
ferramenta de apoio ao pesquisador, por seguir um roteiro lógico de
questionamentos, que permitiram uma posterior organização das informações para o
estudo de caso. Yin (2005) relata que o protocolo de pesquisa deve apresentar: a)
uma visão geral do projeto em estudo; b) procedimentos de campo; c) questões do
estudo de caso; d) guia para o relatório (evidências e formato dos dados).
O objeto do primeiro estudo de caso é a oferta de serviços de TI, demonstrada por
meio de uma concorrência internacional de infraestrutura de TI. No quadro 43 é
representado o protocolo de pesquisa utilizado para obtenção das informações.
Quadro 43 – Protocolo de Pesquisa estudo de caso oferta de TI
Protocolo de Pesquisa Visão geral do estudo de caso
− Estudar uma concorrência de oferta de serviços de TI, sob o ponto de vista de um provedor externo.
Procedimento de campo − Entendimento da RFP (Request for Proposals). − Busca de informações para elaboração das propostas − Pesquisa em ação, envolvendo o autor, como responsável por sete
das 22 propostas. − Elaboração da estratégia de mercado para a oferta de TI − Elaboração das propostas técnicas
Questões do estudo de caso
− Quais as estratégias utilizadas em uma concorrência de TI? − Como utilizar inteligência de mercado, combinando melhores práticas
para vencer a concorrência em serviços de TI? − Como utilizar principios de QFD e de Contratação (RFP) em
concorrências de TI ? − Qual a importância de uma oferta de serviços para garantir sucesso
na fase de operação de TI ? Fontes de evidência − Observação direta
− Entrevistas − Documentação interna para elaboração das propostas − RFP – Request for Proposals − Proposta Técnica − Práticas e certificações do mercado
Por meio do protocolo foram obtidas informações sobre as fases do plano de
transição, estruturação do due dilligence, modelos de governança e operação e,
finalmente, da passagem final da transição para a operação com a análise dos
resultados. Os capítulos deste estudo de caso buscam responder às questões
formuladas no protocolo. A proposta foi elaborada de julho a outubro/2008 e
envolveu a participação de uma equipe multidisciplinar. O autor participou no
formato de pesquisa-ação, responsável pela elaboração direta de sete propostas e
159
quality assurance de todas as demais. Desta forma, conseguiu aplicar e testar os
conceitos do modelo MOPP.
A proposta foi vencedora para o provedor em questão. O resultado foi divulgado
ainda em 2008 e o projeto entrou em operação em 2009. Na figura 37 é mostrado
onde se enquadra o estudo de caso no modelo MOPP.
Figura 37 – Fase do MOPP Aplicada no Modelo
5.1.1. Utilização do Modelo MOPP no Estudo de Caso
No quadro 44 estão demonstrados os processos, práticas e templates do modelo
MOPP que foram utilizados na implementação em uma concorrência de TI de um
provedor de TI. Seguindo o recomendado no modelo, a integração de Frameworks a
exemplo de ISO 20000, ITIL, CobiT, PMBoK possibilitou um conteúdo adequado da
proposta técnica, conforme os requisitos solicitados pelo cliente e com diferenciais
em relação aos demais concorrentes.
160
Quadro 44 – Utilização do MOPP em Projeto de Transição # MOPP Descrição MOPP x Estudo de Caso
01 Oferta Outsourcing de Infra-estrutura de TI Aplicação no Estudo Caso
02 Processo Etapa Processo Descrição do Processo
Gestão da
Contratação
Inteligência Competitiva;
Prospecção; Qualificação;
Proposta Técnica; Proposta
Comercial e Contrato.
Análise da concorrência,
Abordagem, Avaliação da RFP,
Precificação, Métodos para
Bonifcação/Penalidades e
Negociação Contratual.
03 Prática Nome da Prática
QFD – Quality Function Deployment Análise concorrência
eSCM cnt01 – Negociação; eSCM cnt02 –
Precificação; eSCM cnt04 – Informações de
Mercado; eSCM cnt06 – Revisão dos
Requisitos; eSCM cnt06 – Respostas aos
Requisitos; eSCM cnt10 – Criação do
Contrato; eSCM cnt11 – Assinatura do
Contrato.
Negociação contratual,
Benefícios e Penalidades,
Análise da Concorrência,
Elaboração e Análise da RFP,
Elaboração e Negociação do
Contrato.
ITIL v3 SS - Gerenciamento de Demandas; SD
–Níveis de Serviços; SE – Portfolio de
Serviços; SD – Gestão de Fornecedores
Análise demandas eventuais,
determinação dos níveis iniciais
do serviço (SLO), análise dos
serviços e dos parceiros.
PMBok – Aquisições, Tempo e Comunicação Análise RFI e RFP,
Cronograma e Comunicação
COBIT ME4 – Garantir Governança de TI Utilização na proposta técnica
CobiT DS2 – Gerenciar Partes Terceiras Análise parceiros cliente
CMMI – SAM – Gestão de Acordos com
Fornecedores
Determinação níveis de
serviços iniciais (SLO)
ISO 20000 – Gestão de Fornecedores Análise parceiros cliente
ISO 9001 – Sistema de Gestão Utilização na proposta técnica
04 Template Nome do Template
RFP – Request for Proposals Padrão inicial da RFP
Modelo de Precificação Auxilio na proposta comercial
Catálogo de Serviços de Vendas Auxilio no catálogo vendas
Status Report Interação equipe e diretoria
Inteligência Competitiva Dados dos concorrentes
Questionário QFD para Serviços Análise concorrência
161
Os processos mais utilizados estão relacionados com a inteligência de mercado,
vendas, relacionamento com o cliente e com fornecedores. Dessa forma, práticas
como eSCM, PMI, QFD e Inteligência de Mercado foram utilizadas na pesquisa-ação
da oferta de outsourcing. O modelo MOPP foi utilizado nas propostas com base nas
prescrições de cada prática do quadro 44.
5.1.2. Descrição do Estudo de Caso
O objetivo é de apresentar uma visão de venda de serviços de TI, utilizando as
práticas de Gestão de Serviços de TI, Inteligência do Mercado e QFD.
5.1.2.1. Contratação de Serviços de TI
O objeto do estudo foi uma concorrência de serviços de infra-estrutura de TI para um
conglomerado financeiro mundial, com presença nas principais praças financeiras
dos continentes. O escopo estava baseado em um conjunto de serviços no banco
em todo o Brasil e suporte remoto para o México e EUA. A concorrência foi realizada
em uma única etapa. O autor participou ativamente na elaboração e estratégia de
sete do total de vinte e três propostas. Dentro do contexto da concorrência na
estratégia de venda de um provedor de TI o processo foi iniciado antes mesmo da
colocação e resposta a uma RFP (Request for Proposals). Conforme Kujala et al
(2007), a decisão da participação e a apresentação da proposta com oferta e preço
competitivo torna-se fundamental para que o cliente possa selecionar o provedor e
assinar um contrato de longo prazo (dois anos). O provedor, estudado no caso,
possuía no seu portfolio parte dos serviços necessários para a concorrência. Outros
serviços foram avaliados, conforme determinações do modelo.
Neste contexto, o escopo abrangeu um plano de implantação dos serviços,
apresentação de certificações e diferenciais competitivos.
162
Os proponentes deveriam apresentar propostas para um ou mais módulos de
serviços descritos no quadro 45.
Quadro 45 – Escopo da Proposta − Service Desk − Service Desk - Financial − Quality Assurance − Event Management − Incident Management − Asset Management − License Control − Distributed Services − Warehouse Management
− Workstations Environment Control
− Voice & Contact Center Services
− Data Network Services
− ATM Services − Firewall Services Servers Software Technical Support
− UAT Support − Servers Software Release Management
− Data Center Operations
− Client Engineering − Network Engineering − Infrastructure Feasibility Studies
− Infrastructure Project Management
Para cada escopo descrito acima o cliente solicitou precificação (pricing) e três
questões fundamentais para serem respondidas, conforme quadro 46.
Quadro 46 – Requisitos estratégicos solicitados pelo cliente Capacidade para atender aos requisitos solicitados
Sim/Não Explique, citando casos reais adicionalmente, se possível
Possui algum diferencial em relação ao serviço escopo, que possa proporcionar melhorias de processos, qualidade e/ou redução de custos ?
Sim/Não Explique os diferenciais
Gostaria de propor funcionalidades adicionais aos requisitos apresentados que seriam vantajosas para o cliente.
Sim/Não Especifique os serviços adicionais.
5.1.2.3. Estratégia dos Concorrentes
Partiu-se do pressuposto que todos os concorrentes tinham as mesmas informações
e estavam agindo de forma racional. Seguindo o questionário de Coyne e Horn
(2009) para comportamento de concorrentes, foram obedecidas as seguintes
premissas:
−−−− Concorrência não perceberá a ação do provedor de TI. Foi montado um
grupo com reuniões e ações fechadas, garantindo confidencialidade das
informações;
−−−− Concorrência não vai se sentir ameaçada. A concorrência teve participação
dos maiores players (competidores) do mercado mundial de TI. Ainda que estes
concorrentes percebessem o comportamento do provedor, não se sentiram
ameaçadas, por conta de seu porte e alto orçamento para a pré-venda;
163
−−−− Preparar uma resposta será será prioridade para a concorrência. Ainda que
se sentissem ameaçadas, as empresas concorrentes poderiam não reagir,
sobretudo se uma reação vigorosa custasse mais do que ignorar o
comportamento do provedor de TI estudado;
−−−− Concorrência não será capaz de vencer inércia organizacional. Os principais
concorrentes eram os maiores provedores mundiais de TI. Ainda que a gerência
local reagisse, a matriz como um todo poderia resistir (EUA, Alemanha, Holanda
e India). As reações quanto a dimensionamento de profissionais, por exemplo,
poderia exigir grandes mudanças nas empresas concorrentes, devido a alçadas.
Na elaboração da proposta, foi considerado que as empresas concorrentes
tomariam decisões simples. Considerou-se que responsabilidades na preparação da
proposta as impediam de alocar tempo para analisar as opções de reação das
demais empresas. Outra questão considerada foi pesquisar, através de inteligência
de mercado, as opções de reação que os concorrentes estavam trabalhando. A
premissa era de que os concorrentes escolheriam a opção que daria o maior retorno
ao contrato em um primeiro momento, não percebendo a crise financeira mundial de
2008 que se aproximava e que também impactou seriamente na situação financeira
do cliente estudado.
5.1.2.4. Avaliação dos competidores pelo QFD
A voz do cliente é a base para a atribuição dos requisitos. Com os dados coletados
através de entrevistas, pesquisas e reuniões a empresa pode utilizar um processo
de planejamento e tomada de decisão (CHRISTENSEN, 2007). Para cada item
crítico da proposta, formulou-se questão no formato da análise da concorrência pelo
cliente, seguindo o padrão do QFD (Quality Function Deployment). Aplicou-se um
conjunto de questões a clientes chaves que também utilizam ou utilizaram serviços
dos principais concorrentes da proposta. Conseguiu-se identificar os pontos fortes e
fracos de cada serviço ofertado, ajustando-os conforme as respostas dos clientes. A
entrada para o questionário partiu do processo de inteligência do mercado do MOPP
e o resultado foi utilizado na RFP, conforme a figura 38. Também foram utilizados
critérios de seleção de RFP encontrados em Halvey e Melby (2005), combinados
com os conceitos de análise da concorrência de Coyne e Horn (2009). O quadro foi
distribuído para os principais clientes que já haviam mantido relacionamento com os
164
principais concorrentes na proposta. Permitiu-se dessa forma obter informações
referentes aos serviços escopo da RFP e que seriam prestados pelo ganhador da
concorrência. Ocorreu uma classificação em termos de qualidade (em uma escala
de 1 a 5 – muito satisfeito a muito insatisfeito). Trata-se de uma avaliação qualitativa
que buscava identificar como os clientes percebiam alguns serviços críticos para a
proposta em comparação com os principais concorrentes. As informações foram
utilizadas na RFP.
Figura 38 – QFD x Análise Concorrência
As respostas dos clientes foram combinadas com as informações obtidas por meio
de inteligência competitiva. Desta maneira, as propostas foram elaboradas baseadas
em métodos e informações que, normalmente, não haveria como conseguir pela
estratégia tradicional de vendas de produtos e serviços de TI. O QFD foi utilizado de
forma não-convencional e parcial, conforme encontrado em Miguel e Carnevalli
(2006). O provedor estudado venceu a concorrência, levando todas as propostas
acima estipuladas. Fechou um contrato pelo período de cinco anos com a instituição
financeira.
Apresentou-se neste estudo de caso as estratégias utilizadas em uma concorrência
de TI, utilizando conceitos de inteligência de mercado, QFD e inteligência
competitiva. Também foi abordada a importância da oferta de serviços de TI dentro
do ciclo de vida de outsourcing, conforme o que foi proposto no protocolo de
pesquisa. Como continuidade, no próximo estudo apresenta-se a aplicação do
modelo em uma implantação de serviços de TI.
165
5.2. Projeto de Implantação TI: Transição de Serviços em Empresa Mineradora
O objeto do estudo de caso é uma implantação da operação de serviços de TI em
uma empresa mineradora, por uma provedor de serviços de TI. No Quadro 47 é
representado o protocolo utilizado para obtenção das informações da pesquisa.
Quadro 47 – Protocolo de Pesquisa – Segundo Estudo de Caso
Protocolo de Pesquisa Visão geral do estudo de caso
− Estudar um projeto de transição para operação de um serviço de outsourcing de ERP em uma empresa de mineração.
Procedimento de campo − Entendimento da situação atual − Preparação das atividades − Pesquisa em ação, envolvendo o autor, como Gerente de
Governança e Qualidade do projeto. − Contato com a equipe do cliente − Contato com as equipes dos provedores que prestavam os serviços
Questões do estudo de caso
− Quais as fases de um projeto de transição de serviços de TI ? − É possível realizar uma transição de forma eficiente da contratação
para a operação de serviços de TI? − Como deve ser desenvolvido os modelos de governança e de
operação em um plano de transição ? − Ocorreu economia com a consolidação dos provedores correntes ? − Ocorreu uma transição eficiente para a produção ?
Fontes de evidência − Observação direta − Entrevistas − Documentação interna dos processos de suporte, manutenção e
testes do ERP − Due Dilligence
− RFP – Proposta Técnica − RFP – Proposta Financeira − Práticas e Certificações do Mercado
Por meio do protocolo foram obtidas informações sobre as fases do plano de
transição, estruturação do due dilligence, modelos de governança, operação e,
finalmente, da passagem final da transição para a operação com a análise dos
resultados. Os capítulos deste estudo de caso buscam responder às questões
formuladas no protocolo.
Este estudo de caso foi finalizado em agosto de 2008. O escopo foi o outsourcing de
ERP (Enterprise Resource Planning) de uma importante empresa mineradora,
envolvendo os serviços de service desk, gestão de acesso, suporte funcional, fábrica
de software, parametrização, testes automatizados de software.
166
O autor foi responsável pela implantação do modelo de governança e, portanto, com
uma visão ampla das práticas e dos processos implantados.
Figura 39 – Contexto estudo de caso no MOPP
O estudo de caso utilizou processos, templates e práticas relacionadas da etapa de
Gestão de Projetos do modelo MOPP, conforme destacado na figura 39. O modelo
foi utilizado em todas as fases do projeto de transição, incluindo passagem das
atividades para a operação.
5.2.1. Utilização do Modelo MOPP no Estudo de Caso
No quadro 48 estão demonstrados os processos, práticas e templates do modelo
MOPP que foram utilizados na implementação do Plano de Transição do serviço de
outsourcing de ERP no cliente.
167
Quadro 48 – Processos MOPP no Projeto de Transição
# MOPP Descrição
01 Oferta Outsourcing de Manutenção de ERP Aplicação no Estudo Caso
02 Processos Fase do Processo Descrição do Processo
Projeto Project Charter, Plano de
Projeto, Execução,
Acompanhamento,
Fechamento do Projeto,
Lições Aprendidas.
Escopo do projeto transição,
diretrizes, atividades diárias,
indicadores, status report,
relatórios gerenciais, cut off,
kick off e inicio da operação.
Operação Estratégia e Projeto do
Serviço
Demandas, portfolio ,Níveis
Serviços e Plano Operação
Governança Modelo de Governança KPIs, Controles, Compliance
03 Prática Nome da Prática
PMI/PMBoK – Project Charter, Escopo, Tempo,
Riscos, Comunicação, RH.
Cronogramas, Plano de
Riscos, Comunicação
Stakeholders, Plano de Infra,
Absorção e Treinamento.
CobiT ME4 – Prover Governança de TI Modelo de Governança
IPMA – Gestão de Conhecimentos e SSMA
(Segurança, Saúde e Meio Ambiente)
Modelo de Governança e
Modelo de Operação
CobiT ME3 – Garantir Compliance e Requisitos
Externos; P04 - Definir Organização, Processos e
Relacionamentos de TI
Modelo de Governança
ITIL v3 SS - Gerenciamento de Demandas; SD –
Gerenciamento de Níveis de Serviços; ST –
Gerenciamento de Mudanças; SO –
Gerenciamento de Incidentes
Modelo de Governança e de
Operação
eSCM ppl05 – Definição de Papéis; ppl08 –
Competências Pessoais; sdd05 – Projeto do
Serviço; del 01 – Plano de Entrega de Serviços
Modelo de Operação
CMMI V&V – Validação e Verificação; CAR –
Análise e Resolução de Causa; PPQA – Garantia
de Qualidade do Produto e do Processos; PP –
Project Planning.
Plano de Projeto e Modelo
de Operação
04 Template Nome do Template
Project Charter Escopo projeto
SLA – Service Level Management Modelo de Governança
Catálogo de Serviços Modelo de Governança
Status Report Modelo de Operação
168
Os processos mais utilizados estão relacionados com projetos como PMI e IPMA e
práticas de implantação de processos de TI como ITIL e
CobiT. O modelo MOPP foi utilizado no Modelo de Governança e também na
elaboração do modelo de operação do projeto de transição.
5.2.2. Considerações Gerais
O estudo de caso em gestão de projetos de TI foi realizado no departamento de TI
de uma importante empresa mineradora. O autor participou como gerente de projeto
responsável pela construção e implantação da Governança de TI no âmbito do
contrato de outsourcing de um ERP, durante os oito meses da transição. O provedor
de serviços estudado utilizou metodologia própria para gerenciamento de projetos,
baseada em conceitos e melhores práticas do PMBOK – A Guide to the Project
Management Book of Knowledge – 2004 edition, do PMI (Project Management
Institute) e no ICB 3.0 (2004) do IPMA (International Project Management
Association). A figura 40 mostra o projeto de implantação dentro do contexto do ciclo
de vida de outsourcing de TI.
Figura 40 – Ciclo de Vida da oferta Outsourcing
Os Gerentes de Projetos de cada área possuíam certificações PMP (Project
Management Professional) e também existiam profissionais certificados em IPMA
(outra certificação internacional em gestão de projetos).
A complexidade de um projeto de transição de serviços de TI pode ser reduzida
quando uma efetiva governança e um expertise em relacionamento são colocados
em práticas (GOOLSBY, 2002). Sendo assim, a utilização de recursos humanos
169
qualificados em gestão de projetos de serviços de TI impacta de forma positiva um
projeto de transição. Não existe necessidade de capacitação e ocorre aumento no
nível de qualidade dos produtos entregues. No plano de transição estudado, um
Escritório de Projetos (PMO) foi criado para viabilizar padrões, treinamentos,
auditoria e governança de todos os projetos. Esta área era a responsável pela
interface com o cliente. A figura 41 mostra as áreas envolvidas no projeto de
implantação do serviço. O modelo de governança abrangeu também o processo de
qualidade e integração, na visão de gestão de projetos. Uma das funcionalidades do
PMO é atuar como uma área centralizada dedicada a melhorar as práticas e
resultados de um gerenciamento de projetos (KENDAL e ROLLINS, 2006). Neste
aspecto, o escritório de projetos funcionou como um elemento gerencial de apoio
aos gerentes de projetos como também como responsável pela governança e
adoção das melhores práticas para o plano de transição.
Figura 41 – Estrutura da Transição
5.2.3. Etapas do Projeto de Transição
O projeto teve inicio ainda na fase de contratação. O escopo e o plano de projeto
foram desenvolvidos nas instalações do provedor de TI. As fases do projeto
seguiram as melhores práticas de gerenciamento de projetos PMBoK (PMI) e ICB
(IPMA).
− Escopo do Projeto – O escopo contemplava implantação de serviços de transição
do outsourcing de ERP em oito meses para operação regular das atividades.
170
Contemplava desenvolvimento dos modelos de governança e de operação para
os serviços de manutenção evolutiva, manutenção corretiva, manutenção
adaptativa, administração de acesso, service desk, testes de sistemas e fábrica
de software do ERP.
− Iniciação do Projeto - O projeto teve inicio na criação e formalização de um
contrato de prestação de serviços. Foi designado um PMO (Escritório de
Projetos) para realizar as ações da gestão do plano de transição.
− Planejamento do Projeto - Foi elaborado um documento denominado plano de
projeto. Este plano foi baseado nos requisitos definidos em contrato, práticas de
gerenciamento de projetos, coleta de informações sobre o escopo e requisitos
esperados do projeto, sempre com o objetivo de atender às necessidades do
cliente.
− Análise de Risco do Projeto - A análise dos riscos do projeto foi baseada na
identificação de riscos potenciais, restrições e no feedback obtido do cliente. As
informações sobre os potenciais riscos na operação eram avaliadas e reportadas
para o cliente semanalmente, assim como a sua estratégia de controle e
resposta. A exigência do cliente nesta fase encontra respaldo em Yang et al.
(2007), no qual uma empresa possui uma série de alternativas para gerenciar os
riscos dos provedores, incluindo qualificação, sign-off e penalidades.
− Validação do Cliente - O cliente avaliou os produtos gerados e definidos para
cada fase do ciclo de vida do projeto, registrando o resultado dessa análise por
meio de inspeções e aceitação. Os processos desenvolvidos no modelo de
governança descreviam a forma de validação dos produtos pelo cliente.
− Controle do Projeto - Atividades de controle foram desenvolvidas ao longo de
todo o ciclo de vida do projeto e visaram assegurar que os objetivos estavam
sendo atingidos, através da monitoração e avaliação do seu progresso, tomando
ações corretivas e preventivas quando necessárias. Seguindo o modelo MOPP,
práticas foram combinadas a exemplo do CobiT, SOX e Val IT. Destacou-se o
acompanhamento de indicadores de desempenho, cronogramas,
acompanhamento dos custos, mudanças de escopo, entre outros artefatos. O
controle do projeto foi realizado por um Escritório de Gerenciamento de Projetos
(PMO), estruturado para a finalidade de gerenciamento e apoio às atividades do
plano de transição. O objetivo desta área na transição era adicionar valor
171
priorizando a melhoria dos projetos de implantação de serviços de TI e identificar
novos objetivos para a própria área (HURT;THOMAS, 2009). O Escritório de
Projetos realizou o controle por meio da PO10 do CobiT v4.1, combinado com as
práticas do OPM3, CMMI for Services, PMBoK e do IPMA, conforme definido no
modelo MOPP.
− Encerramento do Projeto - Após a validação feita pelo cliente do último produto
entregue, foi formalizada a entrega do final do projeto. O encerramento do projeto
seguiu os processos de entrega do produto final, com registro de aceitação do
cliente, avaliação do nível de satisfação e o arquivamento dos documentos e
registros do projeto e registro das lições aprendidas. Neste momento iniciou-se a
fase de operação do serviço.
− Documentação Gerada - Takeuchi e Nonaka (2008) destacam que uma
organização cria e utiliza conhecimento convertendo o conhecimento tácito em
conhecimento explícito, e vice-versa. Uma das funções do gerenciamento de
projetos é converter o conhecimento tácito em explícito e aplicar conhecimento,
habilidades, ferramentas e técnicas para satisfazer os stakeholders (THOMAS et
al., 2008). Desta forma, todos os documentos gerados foram armazenados no
PMO durante todo o ciclo de vida do projeto. Esta documentação foi utilizada na
melhoria dos projetos existentes na época como também em projetos futuros.
Santos e Campos (2009) ressaltam que o conhecimento obtido em projetos de TI
pode ser utilizado como uma competência dos provedores, agregando valor aos
seus serviços e produtos de TI. No estudo de caso, as lições aprendidas e base
de conhecimento do projeto foram armazenadas no PMO centralizado do
provedor.
5.2.4. Etapas da Implantação dos Serviços
A execução do projeto foi realizada em três etapas. Inicialmente foi realizado um
entendimento da situação do outsourcing do ERP (as is) e em seguida um
planejamento e execução das atividades para entrada do serviço em operação. Nos
primeiros contatos com os stakeholders (partes interessadas) do projeto foram
mapeadas as expectativas, situação atual, problemas e características do projeto,
conforme as fases de entendimento da situação atual. Também foi executado um
processo de due diligence.
172
5.2.4.1. Entendimento da Situação Atual (as is)
A etapa de due diligence foi conduzida paralelamente à negociação do contrato,
sendo sua conclusão um pré-requisito para o inicio do projeto de transição.
Seguindo o explicado em Saad (2006), foram informadas para o cliente evidências
da capacidade do provedor selecionado, considerando-se quatro áreas: a)
Continuidade e disponibilidade dos serviços; b) Conformidade com as melhores
práticas do mercado de TI (ISO 27001, ISO 20000, SAS 70 e CMMI) e com as leis e
regulamentos; c) Segurança da informação e d) Controles e níveis de serviços.
O provedor, por sua vez, validou informações que foram informadas pelo cliente na
RFP (Request for Proposals), a exemplo de recursos humanos, estrutura
organizacional, recursos de TI (hardware, software, comunicações), serviços e
suprimentos. Após encerrada a fase inicial de due diligence as partes classificaram
os itens levantados em: a) itens confirmados; b) itens incorretos; c) itens novos
identificados; d) itens com evolução desconhecida. Todos os itens foram
confirmados. O resultado da due diligence poderia reabrir as negociações dos
termos e condições contratuais (BAYUC, 2009). Ao final desta fase, a equipe do
provedor obteve os elementos essenciais para o trabalho de mobilização, que
consistia em disponibilizar a equipe para a operação do projeto. Também contribuiu
para a definição do modelo de operação e de governança e para a execução das
atividades do plano de comunicação e gerenciamento de riscos na fase seguinte.
− Entendimento do Modelo de Operação - O entendimento da situação atual (as
is) e o detalhamento dos processos relacionados foram necessários para uma
avaliação de impacto e determinação das adequações requeridas. Tiwari et al.
(2006) alerta que um fator crítico de sucesso no modelo de operação é uma
rápida, porém, compreensiva análise das práticas atuais e sua comparação com
uma melhor prática apropriada, identificando os seus gaps e estabelecendo
planos de ação. As informações obtidas nesta etapa do trabalho foram utilizadas
na definição do modelo de operação da etapa seguinte, e integraram o conteúdo
programático dos treinamentos realizados junto à equipe do projeto. O produto
desta etapa foi o relatório de entendimento do modelo atual, contendo plano de
comunicação, processos, procedimentos, modelos de testes, ferramentas,
173
ambiente tecnológico, papéis e responsabilidades, áreas e usuários entre outros.
O critério de aceite foi a aprovação pelo PMO do Provedor de TI e pelo
responsável do cliente.
− Entendimento do Modelo de Governança - Durante a transição ocorreu uma
combinação do modelo de governança já existente no cliente com o novo modelo
que estava sendo implantado, conforme sugerido pelo MOPP. O cliente teve
participação ativa nesta fase. Goodman e Colier (2007) relatam que, para evitar
problemas na qualidade e na governança dos serviços durante um projeto de
transição, os provedores devem concentrar-se em três áreas: i) Uma efetiva
obtenção dos requisitos do cliente); ii) Vincular os requisitos do cliente com os
processos de serviços de TI e iii) O processo deve ser flexível e adaptável às
diversas situações dos clientes. Durante esta fase foi realizada uma análise de
gaps da situação atual, baseada em combinação de práticas como eSCM,
ISACA/ITGI, CobiT, ITIL, ISO 20000, PMBok, IPMA, CMMI e MIT-CISR.
Conforme o modelo MOPP, as informações obtidas nesta etapa do trabalho
foram utilizadas na definição do modelo de governança realizado na etapa
seguinte, e integraram o conteúdo programático dos treinamentos realizados
junto à equipe do projeto. O produto gerado nesta fase contemplou um relatório
de entendimento do modelo atual de governança. Este documento definia os
níveis de serviços, indicadores, controle de riscos, aderência Sarbanes-Oxley,
práticas de auditoria, padrões de qualidade e outros. O critério de aceite foi
através da aprovação do documento pela equipe do PMO do provedor de TI e
pelo gerente responsável do cliente.
5.2.4.2. Desenho da Operação dos Serviços (to be)
Nesta fase do estudo de caso, foi definido o Modelo de Governança e o Modelo de
Operação para a operação dos serviços de TI.
174
− Definição do Modelo de Governança - O modelo definido nesta fase suportou
as atividades relacionadas à gestão de governança descritas na proposta técnica
para a entrada em operação, a exemplo de níveis de serviços, riscos, qualidade,
relatórios, reuniões, controles de TI, auditoria e alinhamento com o negócio. O
produto entregue nesta fase foi o Relatório com Modelo de Governança contendo
o plano de governança de TI, indicadores de níveis de serviços, processos de
gestão, auditoria, controles de riscos, plano de adequação do contrato à lei
Sarbanes-Oxley, monitoramento de desempenho, agenda de reuniões, sign off e
templates.
− Definição do Modelo de Operação - Consistiu na revisão e definição do
desenho de processos, metodologias, tecnologias e ferramentas de suporte
adotadas durante a fase de operação. Suportou as atividades relativas à gestão
dos serviços descritos na RFP, como por exemplo, prover o atendimento ao
usuário, gestão da fila de chamados, gestão de mudanças, testes, fábrica de
software, desenvolvimento e implementação das manutenções corretivas e
evolutivas do ERP. O modelo de operação procurou resolver três valores (Bani
Ali et al., 2008) para a satisfação dos usuários com o ERP: características do
software (facilidade do uso, qualidade da informação e funcionalidade);
características do usuário (experiência, treinamentos e nível de educação) e
características organizacionais e de projetos (porte da organização, porte do
ERP e complexidade do projeto).
− RH e Treinamento - Fez parte do projeto a contratação e mobilização da equipe
para a operação. Ocorreu uma priorização na absorção da equipe existente por
meio de recomendação do cliente. O produto desta etapa foi a lista dos recursos
por posição de trabalho, disponibilidade da equipe e ajustes no plano de gestão
das pessoas. Uma preocupação nesta etapa foi o conhecimento, conforme
encontrado em Reich (2008). Segundo o autor uma gestão efetiva de
conhecimento em projetos facilita a criação e integração do conhecimento,
minimiza perda de conhecimento e preenche deficiências da equipe ao longo da
duração do projeto.
175
No projeto de transição, ocorreu uma ênfase nos processos de qualidade,
baseado em padrões como ITIL, PMI, ISO 9001, ISO 20000 e CMMI, buscando
um trabalho padronizado e compartilhado, conforme o MOPP. Hansen (2009)
argumenta que, em colaboração em projetos de implantação. é de grande
importância a transferência de melhores práticas para redução de custos na
operação.
− Gestão de Riscos Operacionais - Nesta etapa foi elaborado um plano de
gerenciamento de riscos para utilização da equipe de operação. O plano seguiu
o padrão apresentado em Stomeburner et al. (2001), ISO 27005 (2007) e
também no PmBoK (2005)
− Cut over (preparação para entrada em operação) - Esta etapa teve como
objetivo, planejar as atividades de preparação final para a tomada de controle da
operação. O plano de cut over abrangeu o plano de melhoria dos serviços,
modelos de operação e governança, check-list, cronograma de atividades e
apresentação.
− Kick-off Meeting (aprovação do inicio da operação) - Esta etapa estava
relacionada à aprovação formal do cliente para inicio da operação dos serviços
de TI contratados. Seguindo a proposta do MOPP, um relatório de revisão pós-
transição foi preparado pelo PMO do projeto e o seu conteúdo foi acordado com
o cliente e com o provedor
Conforme previsto no protocolo de pesquisa, neste estudo de caso foram
apresentadas as fases do plano de transição. Também foi demonstrada uma forma
eficiente de realização deste processo, por meio do desenvolvimento de um modelo
de operação e de governança. A transição foi realizada com sucesso, com a
operação assumindo totalmente o controle das atividades. Como lição aprendida
final do estudo, o plano de transição é o primeiro e decisivo teste com relação ao
sucesso do outsourcing de TI. Pelo demonstrado nas etapas do estudo de caso, o
período de transição constitui-se em uma fase importante na geração de subsídios
para a operação dos serviços de TI.
176
5.2.5. Análise dos Resultados
As proposições formuladas no protocolo de pesquisa do estudo de caso foram
avaliadas quanto aos seus resultados, conforme abaixo:
− Execução do projeto de transição de acordo com o que foi contratado
(escopo), no menor custo possível e dentro do mais padrão da qualidade -
Esta proposição pode ser considerada como verdadeira, pois os indicadores do
projeto em termos de escopo, custo e prazo ficaram acima do aceitável e foram
aprovados pelo cliente e pelo provedor. O encerramento do projeto de transição
foi aceito pelo cliente e a operação dos serviços foi autorizada. Segundo
Monteiro (2008), um projeto de sucesso pode ser definido como: a) Dentro do
prazo; b) Dentro do custo; c) Dentro do escopo e qualidade planejada e d) De
acordo com a expectativa do cliente. O projeto de transição atingiu todos estes
elementos, sendo o mais importante o que atendeu a expectativa do cliente.
Ocorreu também uma preocupação com a combinação das restrições prazo,
escopo, custos e qualidade. Ocorreram reduções de prazos sem afetar a moral
da equipe e também redução de custos em algumas frentes do plano de
transição sem um aumento de riscos do projeto.
A satisfação do cliente foi o principal indicador de sucesso do plano de transição.
Na conclusão do plano, torna-se fundamental que o cliente e o provedor realizem
uma revisão dos resultados alcançados, conforme sugerido pelo modelo MOPP.
− Entrega do Modelo de Operação e Modelo de Governança e de todos os
recursos necessários para a operação do serviços – Esta proposição pode
ser considerada verdadeira. Os modelos foram entregues para a gestão da
operação dos serviços e os recursos contratados ficaram disponibilizados para o
inicio das atividades de operação. Os acordos dos Níveis de Serviços e dos
Níveis Operacionais definidos durante a transição foram monitorados a partir da
entrada dos serviços em operação. As penalidades (penalties) e bonificações
(gainsharing) começaram a ser adotadas. A equipe da operação iniciou a
execução das atividades no conceito de operação assistida. Após os três meses
177
de acompanhamento, a operação iniciou de fato as suas atividades de forma
independente da equipe de transição, configurando o sucesso do projeto de
implantação dos serviços.
O próximo tópico apresenta o terceiro e último estudo de caso, no qual é abordada a
etapa de operação dos serviços de TI em um centro de operação de redes.
178
5.3. Operação de TI: Serviços de TI com a ISO/IEC 20000 em um Centro de
Operação de Rede (NOC)
O estudo de caso teve como escopo uma implantação e certificação da norma
ISO/IEC 20000 em uma operação de serviços de TI de um importante provedor
brasileiro de TI. Este processo ocorreu entre janeiro/2008 a outubro/2008. No
Quadro 49 é representado o protocolo de pesquisa utilizado para obtenção das
informações básicas da pesquisa.
Quadro 49 – Protocolo de Pesquisa – Terceiro Estudo de Caso
Protocolo de Pesquisa Visão geral do estudo de caso
− Estudar um projeto de implantação e certificação de operação de serviços de TI, dentro de um Global Operation Center de provedor, utilizando o Modelo de Outsourcing para Provedores (MOPP).
Procedimento de campo − Entendimento dos problemas e elaboração de gap analysis
− Elaboração de Plano de Ação − Pesquisa em ação, envolvendo o autor, como Gerente do Projeto − Contato com o órgão certificador e a equipe do cliente − Implantação dos processos operacionais e de gestão para a
operação dos serviços de TI, utilizando as melhores práticas do ITIL, ISO 9001 e ISO 20000.
Questões do estudo de caso
− Quais as fases para implantação de um modelo combinado de melhores práticas em uma operação de serviços de TI ?
− É possível realizar uma certificação em operação da infraestrutura de TI, mesmo com a operação em andamento ?
− Como deve ser desenvolvido o gap analysis e o plano de ação ? − Ocorreu benefícios com a conquista da certificação da operação de
serviços de TI ? − Como ocorreu a combinação das práticas contidas no modelo
MOPP? Fontes de evidência − Observação direta
− Gap Analysis
− Entrevistas − Documentação interna dos processos de operação de serviços de TI − Práticas e Certificações do mercado
Por meio do protocolo foram obtidas informações sobre as deficiências da área, gap
analysis, processos atuais e necessidades de melhorias e implantação de melhores
práticas, contidas no MOPP, para a implantação e certificação da ISO 20000 em um
Centro de Operação de Redes. O modelo MOPP foi utilizado em uma
implementação e certificação da norma ISO/IEC 20000 dentro de um Centro de
Operação Redes.
179
O autor participou no formato pesquisa-ação, como Gerente do Projeto. O estudo
transcorreu em 2008 com continuidade em 2009, por conta da manutenção da
certificação.
Figura 42 – Contexto Estudo da ISO 20000 com o MOPP
O estudo de caso se enquadra dentro da etapa de operação e projeto de operação
do modelo MOPP. O objetivo era utilizar a avaliar a combinação de práticas
recomendadas pelo modelo dentro de uma operação de serviços de TI, bem como
projetos provenientes de demandas eventuais e de novos clientes na operação,
conforme figura 42.
5.3.1. Utilização do Modelo MOPP no Estudo de Caso
No quadro 50 estão demonstrados os processos, práticas e templates do modelo
MOPP que foram utilizados na implantação e certificação da norma ISO/IEC 20000
em um Centro de Operação de Redes (NOC) de um provedor brasileiro de TI.
180
Quadro 50 – Modelo MOPP na Operação dos Serviços
# MOPP
01 Oferta Gestão da Operação Serviços NOC Aplicação Estudo Caso
02 Processos Fase do Processo Descrição do Processo
Gestão da Operação Estratégia, Projeto,
Transição, Operação e
Melhoria dos Serviço
Demandas serviços da
Operação, Planos, Gestão
de Mudanças, Eventos e
Incidentes da área escopo.
Gestão da Qualidade Melhoria do Serviço Gestão de Melhorias
03 Práticas Nome da Prática Aplicação Estudo de Caso
ISO 20000 – Todos os Processos
de Sistema de Gestão, PDCA,
Entrega, Controle, Liberação,
Resolução e Relacionamentos na
Operação dos serviços de TI.
Sistema Gestão do NOC, PDCA, Novos
Projetos, Níveis de Serviços, Plano e
Testes de Continuidade, Plano de
Capacidade, Relatório Financeiro, Base
de Dados de Configurações, Gestão de
Incidentes e Problemas, Gestão de
Mudanças e Liberação, Plano de
Disponibilidade e Gestão Segurança do
NOC.
ITIL V3 – Todos os processos de
Estratégia, Projeto, Transição,
Operação e Melhoria dos Serviços.
Aplicação das melhores práticas de
Gestão de Serviços de TI no GOC
(Gestão da Demandas, Gestão
Financeira, Projeto do Serviço, Transição,
Operação dos Serviços e Melhoria
Contínua.
ISO 27001 – A5. Política de
Segurança da Informação; A9.
Segurança Física e Ambiental;
A13. Gestão de Incidentes de
Segurança; A11. Gestão de Acesso
Política e Processos de Segurança do
NOC; Processos, Acesso Físico e Lógico
e Incidentes de Segurança.
eSCM del03 – Entrega do Serviço Apoio na montagem dos processo de
entrega dos serviços
04 Templates Nome do Template Aplicação Estudo de Caso
Plano de Capacidade Elaboração do plano
SLA – Service Level Management Elaboração de SLA e OLA
Catálogo de Serviços Auxílio no Catálogo
Status Report Relatórios Gerenciais
Plano e Teste de Continuidade Elaboração do Plano/Testes
181
Os processos mais utilizados estão relacionados à Gestão de Serviços de TI,
Governança e Qualidade. Práticas de gestão e operação de processos de TI como
ISO 20000, ISO 27001, HDI, CMMI, ITIL e
CobiT foram utilizadas. O modelo MOPP foi utilizado durante todo o projeto e na
operação dos serviços do NOC nos 10 meses das atividades. O autor foi o Gerente
do Projeto comprometido no caso e, dessa maneira, tornou-se mais adequada a
utilização da pesquisa-ação.
5.3.2. Descrição do Estudo de Caso
O objetivo é apresentar a aplicação do modelo em uma implantação da ISO/IEC
20000 dentro de um Centro de Operação de Redes ou Network Operation Center
(NOC). Esta norma é fortemente alinhada com a metodologia ITIL e com a ISO
9001:2008 e consiste em requisitos de gestão, entrega, controle, liberação,
resolução e relacionamento de serviços de TI. A busca de certificações é uma
constante entre as empresas que buscam competir no mercado de tecnologia da
informação e aumentar a competitividade de seus produtos e serviços de TI. Neste
contexto, a ISO/IEC 20000 traz diferencial competitivo na gestão de serviços de TI e
na melhoria da qualidade percebida pelos clientes.
A ISO 20000 garante para o ITIL alguns complementos fundamentais, dentro de um
sistema de gestão, como por exemplo a responsabilidade da alta direção sobre o
sistema de qualidade de serviços de TI, competência, treinamento e requisitos de
documentação para a execução dos processos. Tudo isto é auditado quanto à sua
eficácia. Outro aspecto fundamental é a inclusão dos processos do ciclo PDCA,
incluindo auditoria, registros, evidências de não- conformidades e oportunidades de
melhorias com suas respectivas ações preventivas e corretivas. Processos
importantes de relacionamento com o cliente (incluindo gestão de reclamações) e de
gestão de fornecedores são auditados e escalados, quando necessário.
182
Exige-se também um processo de melhoria de serviços com atividades bem
definidas, incluindo determinações claras de entradas e saídas. Os processos da
ISO 20000 são mostrados na figura 43.
Figura 43 – Estrutura da ISO 20000
fonte: Adaptado da ISO 20000 (2005, p.1)
A pesquisa foi realizada em uma empresa líder em TI no Brasil, cuja certificação na
norma foi obtida em 2008 e renovada em 2009. A coleta de dados foi realizada
durante a execução do projeto. A pesquisa-ação teve como base uma participação
na concepção e implantação na gerência do projeto da ISO/IEC 20000 em um
Centro de Operações de Rede (NOC) de um importante provedor nacional de TI,
com operações na America Latina, EUA, Europa e Ásia, 14 centros de
desenvolvimento, full it service provider, 200 clientes, 85 centros de atendimentos
técnicos, atuação em Application Outsourcing, IT Services, ERP Solutions, Fábrica
de Software, Consultoria e Revenda de Equipamentos de TI.
5.3.4. O problema no Gerenciamento de Serviços de TI na área escopo
Alguns problemas estavam dificultando a prestação de um serviço de qualidade para
os clientes do NOC, sendo eles:
183
− Ausência de um sistema de gestão da qualidade no NOC. Não havia trabalho
padronizado por meio de procedimentos, instruções de trabalho e registros,
dificultando a melhoria dos serviços;
− Falta da percepção do cliente quantos aos serviços oferecidos pelo NOC, uma
vez que não havia contato diretamente com o usuário final (serviço meio);
− Ausência de um processo formal de melhoria contínua e análise de problemas,
com a utilização de técnicas como PDCA, QFD e Kaizen. Os problemas e
oportunidades detectados junto ao cliente não eram resolvidos e escalados da
forma apropriada dentro da empresa.
− Cliente insatisfeito com informações gerenciais e com o próprio relacionamento
com o NOC. Os temas discutidos em reuniões não eram documentados.
Pendências não eram endereçadas;
− Falta de visão do negócio dos clientes, por parte da equipe. Questões do tipo:
Por que o servidor A, que possui serviços estratégicos do cliente, é mais
importante que o servidor B não eram respondidas adequadamente;
− Problemas de segurança física e lógica da informação;
− Falta de um plano de continuidade efetivo, envolvendo disaster recovery, plano
de operação e plano de restore;
− Níveis de serviços reportados ao cliente sem sempre refletia à realidade, com
solicitações de recálculo de indicadores de disponibilidade. Um dos motivos da
divergência eram os expurgos realizados (interrupções não programadas);
− Indicadores operacionais não estavam formalizados, dificultando as reuniões
com os clientes;
− Ferramenta de ITSM (IT Service Management) subutilizada, com alguns módulos
importantes como problemas, mudanças e configurações não adequados;
− Gerenciamento de Mudanças com problemas de análise, execução e revisão;
− Falta de processes owners que pudessem assumir as responsabilidades sobre
cada processo. Ausência de definição de um responsável geral (service
manager) pelo gerenciamento dos serviços.
Para Milner e Olsen (2008), serviços de TI, a exemplo de centro de operação e
central de atendimento (call center), torna-se a face pública de uma empresa. Ainda
segundo os autores, o impacto de um serviço sem qualidade pode impactar toda a
organização. Uma vez que o NOC oferecia serviços para vários clientes e competia
184
com outras organizações nacionais e multinacionais do segmento de infra-estrutura,
houve a necessidade de desenvolver as melhores práticas do mercado e buscar
uma certificação em uma norma internacional que pudesse reconhecer as melhores
práticas que estavam sendo implantadas. O fator motivador foi o desejo de oferecer
valor agregado e aumentar o valor do serviço percebido pelos clientes.
5.3.5. Fases do projeto
As principais fases da implantação da ISO/IEC 20000 na empresa obedeceram a sequência descrita na figura 44.
dsfdsfdfssdsfdsf
Figura 44 – Processo de implantação da ISO/IEC 20000
O processo de implantação da ISO/IEC 20000 foi realizado em sete meses, com
investimento de US$ 250,000.00 e consistiu em:
a. Definir e aprovar o escopo: um escopo foi definido inicialmente e submetido à
aprovação prévia do órgão certificador;
Definir e aprovar o
escopo
Elaborar e aprovar
plano do projeto Avaliar as práticas
atuais
Comparar as práticas
com a ISO 20000
Documentar a avaliar as diferenças (gap analysis)
Elaborar plano de
ação
Treinar equipes em
ITIL e ISO 20000 Definir e Implantar
Sistema de Gestão
Realizar Auditoria
Interna Treinar Processos
Sistema Gestão .
Implantar Processos
ISO 20000
Realizar Pré-
Auditoria Externa
Obter a Certificação ISO 20000 Realizar Auditoria
Final Externa Obter a
Recomendação
185
b. Elaborar e aprovar o Project charter, Declaração de Escopo e Plano de Projeto: o
Project Chart, Declaração de Escopo, assim como um Plano de Projeto foram
desenvolvidos, conforme as melhores práticas de gerenciamento de projetos. O
Os documentos foram apresentados ao sponsor (patrocinador) e ao comitê de
projeto para aprovação;
c. Avaliar as práticas atuais: as práticas utilizadas pelo centro de operações foram
mapeadas e documentadas;
d. Comparar os processos atuais com a ISO/IEC 20000: com base nas práticas
mapeadas da área, uma comparação foi realizada com cada requisito da norma.
Exemplo:
• Norma: Planos de disponibilidade e de continuidade de serviço devem ser
desenvolvidos e revisados, pelo menos anualmente, para assegurar que os
requisitos sejam satisfeitos conforme acordados em todas as circunstâncias,
de normal a uma grande perda de serviço. Estes planos devem ser mantidos
para assegurar que reflitam mudanças acordadas e necessárias para a
organização.
• Prática do Centro de Operações: Não existe plano de continuidade como
também revisão. O Plano de disponibilidade é realizado apenas pra os ativos
de rede.
e. Documentar e avaliar as diferenças (gap analysis): No exemplo anterior, uma
necessidade de melhoria foi identificada, sendo: implantar plano de continuidade,
abrangendo testes periódicos e revisão anual. O Plano deverá abranger todos os
itens de configuração do centro de operações. Ampliar o plano de disponibilidade
para todos os itens.
f. Elaborar plano de ação: Um plano de ação, contemplando ações corretivas,
melhorias, automatização, treinamentos e elaboração de documentação foi
elaborado.
g. Treinar no mercado as equipes em ITIL, ISO 20000: foram realizados três
treinamentos em ITIL v2 e dois treinamentos em ITIL v3, totalizando 70
colaboradores. Para a ISO/IEC 20000 o treinamento contemplou 20 profissionais
entre consultoria e auditoria. Para a ISO/IEC 9001 foram capacitados 30
profissionais. O total foi de 2.000 horas de treinamento.
h. Definir e implantar sistema de gestão da ISO 20000: inicialmente foram criados
os padrões de documentação conforme as determinações de sistema de gestão
186
da ISO 9001. Contemplou a metodologia para elaboração do manual de gestão,
políticas, planos, procedimentos, instruções de trabalho e registros. Toda a
documentação foi armazenada em portal de gestão. Também envolveu um
processo automatizado de aprovação e controle de versão dos documentos, com
evidências de auditoria (logs). Um sistema para registro das não conformidades
e oportunidades de melhorias foi desenvolvido.
i. Implantar processos da ISO 20000: Os processos da norma foram implantados
com base no plano de ação. Um status report semanal era produzido e enviado
ao comitê do projeto.
j. Treinar as equipes nos processos e no sistema de gestão: depois de capacitados
nos padrões da norma e na biblioteca ITIL, os colaboradores foram treinados nos
processos novos ou modificados.
k. Realizar auditoria interna: antes da primeira pré-auditoria, uma auditoria interna
foi realizada com auditores internos certificados na norma ISO 20000. Um plano
de auditoria, relatório final com plano de ação para as não-conformidades foram
produzidos como evidências para a auditoria externa.
l. Realizar pré-auditoria: uma vez com todos os processos implantados, sistema de
gestão montado e as não-conformidades da auditoria interna já fechadas, foi
realizada uma pré-auditoria externa com o órgão certificador. Esta etapa
envolveu dois dias. Foram identificadas não-conformidades menores. Se ocorrer
uma quantidade excessiva de não-conformidades recomenda-se realizar uma
segunda pré-auditoria antes da auditoria final.
m. Realizar auditoria externa final: após o fechamento das não-conformidades da
pré-auditoria a auditoria externa foi recomendada, sem nenhuma não-
conformidade.
n. Obter a recomendação para a certificação: após a realização da auditoria final
não foi detectada nenhuma não-conformidade – se ocorresse alguma não
conformidade, a recomendação somente será realizada após o fechamento
desta. Dessa forma, a recomendação foi realizada.
o. Obter a certificação na norma ISO/IEC 20000: após trinta dias após a
recomendação, o certificado é recebido e a empresa foi formalmente declarada
como certificada ISO/IEC 20000. A partir deste momento foi divulgado para a
imprensa, clientes e fornecedores esta conquista e os benefícios decorrentes.
187
5.3.6. Exemplos de Combinação de Práticas Utilizadas
Durante o projeto, recorreu-se ao MOPP para selecionar pontos de integração da
ISO 20000 com a norma NBR ISO 9001, que já estava implantada na área escopo.
Neste aspecto, utilizou o modelo para realizar esta interface conforme o quadro 51.
Quadro 51 – Integração ISO 9001 x ISO 20000
Id Processo ISO 20000
Processo ISO 9001
Oportunidades de Integração para a ISO 20000
01 3. Requisitos Sistema de Gestão
− Sistema de Gestão da Qualidade
Desenvolver o Manual da ISO 20000 baseado no Manual de Gestão da ISO 9001, aproveitando a estrutura e diretrizes. Utilizar o padrão do item 5.3. – Política da Qualidade para Política de Serviços
02 3.1. Responsabilidade da Direção
− Responsa-bilidade Administração
Planejar e realizar a Reunião de Análise Crítica seguindo a ISO 9001, com foco em Gestão de Serviços de TI.
03 3.2. Requisitos Documentação
4.2. Requisitos de Documentação
Utilizar os mesmos documentos obrigatórios da ISO 9001: Controle de Documentos, Controle de Registros etc. Manter o mesmo padrão de versionamento e formatação da documentação da ISO 9001. Realizar o versionamento de forma automatizada com controles de logs para aprovação.
04 3.3. Competência, Conscient. e Treinamento
6.2. Recursos Humanos
Manter o mesmo padrão de análise de competências e plano de treinamento da ISO 9001. Desenvolver treinamentos específicos em Gestão de Serviços de TI, mapeados por meio dos gaps identificados.
06 4.4. PDCA-Melhoria Contínua (Act)
8.5. Melhorias; 8.5.2. Ações Corretivas; 8.5.3. Ações Preventivas
Manter o conceito de Grupo de Melhoria recomendado pela ISO 9001, priorizando Melhoria dos Serviços. Utilizar o sistema de ações corretivas, preventivas e oport. de melhorias da ISO 9001.
07 5. Serviços Novos ou Modificados
7.3. Projeto e Desenvolvimento
Tratar, da mesma forma da ISO 9001, toda nova entrada ou modificação de serviços como um projeto. Utilizar recomendações e adequar os procedimentos da ISO 9001 para a nova realidade.
08 7.2. Relacion. com o Negócio
7.2. Processos Cliente; 8.2.1. Satisfação do Cliente
Manter os mesmos controles da ISO 9001. Desenvolver um banco de dados de reclamações e alocando um responsável pela satisfação do cliente, conforme exige a ISO 20000.
09 7.3. Gerenc. Fornecedores
7.4. Aquisição Utilizar os controles de fornecedores, incluindo contratos e inspeção dos requisitos do item 7.3
10 4.3. PDCA - (Check)
8.2.2. Auditorias Internas
Utilizar os mesmos padrões da ISO 9001 para a ISO 20000, incluindo procedimentos de Plano de Auditoria, Formação de Auditores, Pré-Auditoria. As duas normas são baseadas na ISO/IEC 19011.
188
5.3.7. Governança de TI da área escopo
A implantação da governança na área escopo da certificação ISO/IEC 20000
combinou o modelo do ISACA/ITGI com conceitos do MOPP, no que se refere ao
uso de práticas, além das recomendadas pelo modelo original do ISACA, conforme
pode ser visto na figura 45.
Figura 45 – Governança Interna de TI – Serviço Área Escopo ISO 20000
fonte: Santos e Campos (2008a, p.5)
O objetivo era utilizar o que havia de mais aplicável em termos de processos e
práticas existentes no mercado para governança de TI.
5.3.8. Avaliação do Estudo de Caso
O modelo MOPP mostrou-se eficiente na combinação das práticas para a
implantação e operação dos processos de serviços de TI em um centro de operação
de redes. A sua eficácia foi medida pelo alcance da certificação ISO/IEC 20000 pelo
189
provedor de serviços de TI. Práticas de qualidade como ISO 9001, combinadas com
práticas de serviços de TI como ITIL e ISO 20000 e práticas de gerenciamento de
projetos (PMI e IPMA) tornou possível a execução do projeto. O diferencial do
modelo MOPP é que cada prática foi utilizada baseada na prescrição do modelo.
Cassidy (2002) define que uma evolução de processos passa necessariamente pela
medição completa das métricas, antes e depois, além de outros fatores como
documentação de procedimentos e automação das atividades. A conquista da
certificação ISO/IEC 20000 pela empresa estudada não foi o único resultado visível
do projeto. Melhorias dos processos, tecnologias e das pessoas foram observados,
conforme quadro 52.
Quadro 52 – Análise do Resultado do Terceiro Estudo de Caso Qual a Visão ? Tornar o centro de operação de rede um centro de excelência
na gestão de serviços de TI dentro e fora da empresa em um prazo de 06 meses.
Onde Estava ? Processos inadequados, tecnologias inadequadas e pessoas desmotivadas e com problemas de capacitação. Foram medidos os seguintes indicadores: a. Possibilidade da conquista de clientes com a aquisição da
certificação b. Aumento dos valores dos serviços prestados após a
conquista da norma. c. Satisfação do cliente d. Disponibilidade do Itens de Configurações dos clientes. e. Produtividade f. Custo do centro de operações g. Itens de Configurações cobertos por Planos de
Capacidade h. Pesquisa de clima interno
Qual o resultado almejado ? Certificada na norma ISO/IEC 20000 em um prazo de seis meses, com a implantação dos processos, sistema de gestão, adequação da tecnologia e forte capacitação e conscientização dos profissionais da área e das interfaces externas.
O que foi feito para chegar até o resultado ?
Projeto de implantação da norma ISO/IEC 20000
Como a empresa ficou sabendo que atingiu o resultado ?
Certificação ISO/IEC 20000 obtida e comparação dos indicadores abaixo com os medidos antes da implantação da norma: i. Possibilidade da conquista de clientes com a aquisição da
certificação j. Aumento dos valores dos serviços prestados após a
conquista da norma. k. Aumento da satisfação do cliente l. Disponibilidade do Itens de Configurações dos clientes. m. Incremente da produtividade n. Redução de custos do centro de operações o. Itens de Configurações cobertos por Planos de
Capacidade p. Aumenta da satisfação de clima interno
190
Conforme o que foi proposto no protocolo de pesquisa, este estudo de caso
abrangeu as melhores práticas utilizadas em uma operação de serviços de TI. A
implantação dos processos da ISO 20000 ocorreu com a operação funcionando.
Inicialmente foi desenvolvido um gap analysis das práticas atuais e na sequência
estas práticas foram comparadas com os requisitos da norma. Por fim, foi realizada
uma análise dos benefícios. Dessa maneira, o estudo atendeu as condições e
questões do protocolo. No próximo capítulo deste trabalho é apresentada a
conclusão do trabalho, incluindo a avaliação dos resultados obtidos, limitações e
trabalhos futuros sugeridos.
191
6. CONCLUSÃO
Ao analisar o modelo MOPP, os seus métodos, matrizes e a aplicação em três
estudos de casos, constata-se que o fator crítico fundamental para uso de práticas
pelos provedores de TI é a sua combinação de forma prescritiva, agregando valor
aos serviços de TI. Revisando Monteiro (2004), ao analisar modelos integrados
como o eSCM/SP concluiu-se que não são prescritivos, não apresentam visões
conforme o segmento de mercado, clientes atendidos, o porte da organização, a
estratégia do provedor de TI e principalmente o suporte a outros modelos de
melhoria de processos. Além de uma visão prescritiva, apresentou-se também no
modelo MOPP as matrizes de relacionamento entre a oferta do provedor,
necessidades dos clientes e a aplicação dos processos em diversos estágios do
ciclo de vida da oferta e operação de serviços de TI.
Conforme Haried e Ramamurthy (2009), o sucesso em estabelecimento de práticas
e modelos é medido em termos da percepção do cliente. Além disto, deve existir um
equilíbrio entre as metas do provedor de serviços de TI e as necessidades do
cliente, incluindo aspectos estratégicos e financeiros. Nesta linha, o trabalho também
procurou contribuir com uma série de métodos quantitativos para gainsharing,
penalidades, movimentação de baseline, estabelecimento de redução de lead time,
melhoria contínua e aumento das atividades de valor agregado.
No trabalho foi desenvolvido um ciclo geral para oferta de outsourcing,
contemplando as seguintes áreas de conhecimento: contratação, projeto de
implantação, operação, governança, qualidade, inovação & conhecimento e
segurança da informação. Cada ciclo contemplou os processos principais para a
oferta e, finalmente, em cada processo foram vinculados as práticas e os templates.
O modelo foi totalmente automatizado por meio de ferramentas open source. A
linguagem selecionada a Java, na sua versão JDK 1.6. o banco de dados foi o
PostgreSQL 8.3 e finalmente optou-se pelo servidor Tomcat 6. A solução foi
totalmente desenvolvida em ambiente web. O modelo open source foi desenvolvido
para ser atualizado por meio de colaboração entre empresas, comunidade de
desenvolvedores, clientes e parceiros do provedor. O open source difere do modelo
192
tradicional em basicamente dois aspectos: o processo de desenvolvimento, que é
essencialmente uma produção colaborativa e a filosofia de propriedade intelectual,
que permite a livre distribuição do código fonte, bem como o direito de modificá-lo.
Todos os processos foram vinculados às melhores práticas do mercado. O
diferencial do modelo é que, para cada etapa do ciclo de vida, foram integrados os
processos mais adequados de cada framework do mercado. Por exemplo, para a
prática modelo de governança do projeto de transição de serviços, alguns
frameworks foram selecionados, como por exemplo: eSCM/SP – Rel06
(Relacionamento com o Cliente), CobiT ME1 ( Monitorar e Avaliar Performance de
TI), CobiT ME3 (Prover Governança de TI), ITIL v3 – Governança de Valor, ITIL v3 –
Gestão de Demanda, ISO 20000 – Relacionamento com o Negócio e ISO 38500 -
Princípio 2: Estratégia. Para cada processo das práticas estudadas, o modelo
informa a melhor maneira de utilizá-lo dentro do ciclo de vida para a oferta de
outsourcing. Para a modelagem do processo foi utilizado o padrão do Process
Handbook do MIT e também o SIPOC. Para cada processo vinculado às etapas do
ciclo de vida, o modelo relacionou os templates mais adequados. Um exemplo é o
processo modelo de governança do projeto de implantação. Os templates
vinculados foram: acordo de nível de serviço (SLA), templates para procedimentos e
instruções de trabalho e também o book de indicadores mensais. Os templates
também constavam nos anexos para uso livre dos provedores de serviços.
Dentro da pesquisa também foram desenvolvidas matrizes para melhor
direcionamento do relacionamento dos frameworks com as ofertas de outsourcing,
conforme abaixo:
Ocorreu um relacionamento das práticas por meio da Matriz de Oferta x Prática x
Ciclo de Vida Operacional. Nesta matriz foram relacionadas as práticas com as
ofertas dos provedores de TI e também com cada etapa do ciclo de vida de
outsourcing. Por exemplo, para a oferta NOC (Network Operation Center), para a
venda do produto foi recomendado nesta pesquisa a utilização do eSCM/SP e
também do PMI/PMBoK. Para o projeto de implantação dos serviços recomendou-se
a utilização do IPMA, PMI/PMBoK e CobiT e na operação o uso do ITIL, ISO 27001
e da ISO 20000. Ao selecionar a oferta do provedor, o sistema informa os
193
processos mais adequados de cada prática para cada oferta selecionada. Dentro do
sistema ao selecionar o processo do framework é informado de qual maneira ele
poderá ser utilizada para a oferta e operação do provedor.
Na matriz Ciclo de Vida x Prática x Ciclo de Conhecimento, foram relacionadas as
práticas com as ofertas dos provedores e com o ciclo de conhecimento (governança,
inovação, qualidade e segurança da informação). Por exemplo, para a relação da
etapa de operação dos serviços com a qualidade são relacionados os modelos e
metodologias QFD, ISO 20000, ISO 9001 e Lean Six Sigma.
O trabalho desenvolveu também um relacionamento entre oferta do provedor e a
necessidade dos clientes, conforme a importância do uso adequado de cada prática
o segmento do mercado onde o cliente está inserido (financeiro, industrial, comércio,
governo). Por exemplo, para a oferta de outsourcing de fábrica de software de uma
instituição financeira o modelo MOPP sugere que o uso de frameworks como o
CMMI, ITIL e PMI/PMBoK não são suficientes, mas também devem ser destacados
outros modelos como a ISO 27005, CobiT e SAS 70. Para as empresas que
necessitam de compliance com a SOX, uma ênfase deve ser realizada em práticas
como o CobiT, COSO e ISO 27001, incluindo busca das certificações para o
provedor e também para seus profissionais. O Modelo MOPP indica que estas ações
representam um diferencial na estratégia de oferta do provedor.
194
A pesquisa provou que o modelo é aplicável na oferta de outsourcing, por meio de
três estudos de casos, conforme Quadro 53. Estas três aplicações são apenas
exemplos de como o modelo funciona, podendo ser utilizado em outros tipos de
oferta de outsourcing.
Quadro 53 – Resumo dos Estudos de Caso do Modelo MOPP
# Estudo de Caso Tipo de Oferta Fase do MOPP
1 Concorrência de infraestrutura de TI em uma instituição financeira mundial
Infraestrutura de TI (Operação de Datacenter, Service Desk, Field
Support, Storage, NOC, Projetos de infraestrutura, gestão de ativos, Suporte Servidores, Suporte Redes).
Contratação
2 Projeto de transição de uma empresa de mineração, líder brasileira e mundial no seu setor de atuação.
Outsourcing de ERP Oracle Projeto de Implantaçào
3 Implantação e Certificação da ISO/IEC 20000 em um Centro de Operação de Redes
Gestão de Eventos de Redes/ Servidores e Monitoramento de Operação de Clientes.
Operação dos Serviços
O modelo foi aplicado em três projetos envolvendo as três fases do ciclo
operacional: contratação, projeto de implantação e operação. Para a contratação o
modelo foi aplicado em uma oferta de outsourcing de uma concorrência de porte na
área de serviços de TI. Tratou-se de uma RFP (Request for Proposals) para
outsourcing de infraestrutura de TI para uma instituição financeira americana, uma
das maiores do mundo. Para o projeto de implantação, o modelo foi aplicado pelo
autor em um projeto de transição em uma empresa líder mundial em mineração. Na
operação o estudo de caso selecionado foi um projeto de implantação e certificação
da ISO/IEC 20000 em um Centro de Operação de Redes. Foram utilizadas todas as
práticas do modelo para melhoria da operação de serviços de gerenciamento e
monitoramento de redes.
Foi demonstrado na pesquisa que o modelo é independente dos frameworks e de
suas versões, apesar de estarem relacionados. Ficou evidenciado que o provedor
pode a qualquer momento excluir, incluir ou atualizar as práticas e templates
aplicáveis a cada etapa do ciclo de vida de oferta de outsourcing. Por fim, o modelo
195
MOPP apresentou um padrão para gainsharing (bonificação) e penalty (penalidade)
para ser utilizado por provedores nas suas ofertas de outsourcing. O modelo é
flexível, permitindo inclusão ou exclusão de indicadores e de pontuação, assim como
dos valores das penalidades e das bonificações. Também foi apresentado um
modelo quantitativo para movimentação de baseline, prevendo adequações
contratuais e na oferta de outsourcing ao longo da operação dos serviços.
Além dos objetivos específicos, a pesquisa buscou responder às questões
formuladas no inicio da pesquisa. Os modelos atuais utilizados no mercado são
proprietários e os que são desenvolvidos em universidades estão em alto nível,
preocupam-se apenas em relacionar as práticas não visando todos os conceitos
vinculados à oferta de outsourcing. O modelo MOPP envolveu uma pesquisa
detalhada e prática do uso dos frameworks no ciclo de vida de oferta de outsourcing.
Outro aspecto importante demonstrado na pesquisa foi a vinculação das práticas do
mercado a cada etapa, realizada a partir da melhor aplicação de cada conceito a
determinado processo do ciclo de vida de oferta de outsourcing. Existem práticas
relacionadas nos frameworks do mercado, porém não costumam ser relacionadas
no seu nível detalhado, pois exige um conhecimento elevado de cada uma delas. No
caso do modelo COBITIL estudado, por exemplo, ocorreu um relacionamento entre
o ITIL e o CobiT neste nível, porém vinculado a um determinado processso de TI
(Suporte de Serviços) e também resumido a dois frameworks (ITIL e CobiT). A
pesquisa mostra a localização de cada framework para pesquisa por parte dos
provedores de TI.
Para aumentar sua vantagem competitiva, os provedores de TI devem entregar valor
ao cliente, tornar sua oferta não muito adequada de imitar e também transformar
seus produtos e serviços em algo valioso, difícil de copiado pelos concorrentes.
Neste aspecto, o MOPP recomendou um conjunto de práticas relacionando as
ofertas do provedor de TI com as necessidades do cliente. Outro fator mostrado foi
que os provedores não podem trabalhar com um mesmo conjunto de estratégias e
práticas para as suas diversas ofertas. Em tecnologia da informação alguns
processos são considerados artes, antes de ser uma ciência, pela própra
característica de serviços de TI e também pela necessidade de flexibilidade. Em
fábrica de software, por exemplo, frameworks não amplamente utilizados em
196
software como ITIL, ISO 27005 e ISO 20000 podem ser úteis, assim como em
infraestrutura de TI o PCMM pode ser muito importante, pois concentra=se em
gestão de pessoas.
6.1. Limitações da Pesquisa
Quanto ao desenvolvimento do modelo proposto, esta tese se limitou em apresentar
um modelo prescritivo sob o ponto de vista de provedores de TI, não considerando
as necessidades do departamento de tecnologia da informação das empresas
clientes. O objeto de estudo são importantes provedores de serviços de TI. Quanto à
aplicação do modelo, limitou-se a apresentar três estudos de casos refletindo as três
etapas principais do ciclo de vida da oferta e operação de serviços de TI. Áreas de
conhecimento a exemplo de Gestão de Segurança da Informação e Gestão do
Conhecimento não puderam ser aplicados. Também não foi considerado um único
estudo de caso considerando as três etapas: contratação, projeto e operação, mas
três estudos de forma distinta. Outra limitação é que o aplicativo desenvolvido
contempla apenas um banco de informações para consulta, não contemplando os
métodos quantitativos apresentados no trabalho. Algumas limitações são
oportunidades de melhorias abordadas no capítulo seguinte de trabalhos futuros.
197
6.1. Trabalhos Futuros
Para a continuidade deste trabalho, recomenda-se as seguintes pesquisas:
− Modelo direcionado para as pequenas e médias empresas (PME) de
informática. O modelo pode e deve ser adaptado para pequenos e médios
provedores de serviços de TI, conforme mostrado na figura 46. Pode ser
adaptado quanto ao ciclo de vida, adaptado para as PMEs.
Figura 46 – Escopo x Detalhe MOPP
As práticas podem ser adequadas às necessidades das pequenas e médias
empresas de tecnologia da informação, conforme a sua aplicação. As PMEs
podem ser acrescentadas e estudadas em matrizes de frameworks para a oferta
do provedor nesse mercado.
− Desenvolvimento de um framework de maturidade dos processos, baseados
nos processos apresentados neste trabalho e no ciclo de vida. Desenvolver um
modelo de maturidade dos processos contemplados no modelo MOPP. Níveis de
maturidade dos modelos CobiT, CMMI e eSCM/SP podem ser utilizados como
base de informações.
198
− Modelo para os departamentos internos das empresas. O modelo foi
desenvolvido originalmente para provedores externos de TI. Os ciclos de vida do
modelo podem ser adaptados para os departamentos internos de TI das
empresas.
− Pesquisas e matriz de relacionamento das ofertas dos provedores de TI
com cenários e novas tecnologias (ex. crise financeira, cloud computing e
redes sociais). Contemplar dentro das matrizes de relacionamento as práticas e
processos mais adequados para alguns cenários econômicos e tecnológicos,
como, por exemplo, crise financeira com redução de demanda e também novas
tecnologias a exemplo de cloud computing e redes sociais. O modelo, por ser
prescritivo, pode ser adaptado para descrever a aplicação de cada prática dentro
de um novo cenário ou de uma nova tecnologia.
− Aplicação do Modelo em outros tipos de oferta de outsourcing. Aplicar o
modelo em outros tipos de oferta e operações de serviços de TI a exemplo de
Service Desk, BPO (Business Operations Outsourcing) e Segurança da
Informação.
− Desenvolvimento de Mapa de Processos, detalhando o SIPOC apresentado
para cada processo. O modelo por ser detalhado por meio de mapas de
processos, conforme as necessidades dos provedores de serviços.
− Utilização de frameworks de métodos ágeis no MOPP e também na sua
implementação. Métodos ágeis como o Scrum podem ser utilizados combinados
como PMBoK e o IPMA na etapa de projetos de implantação, visando a sua
agilização. Também poderão ser utilizados na própria implementação do MOPP.
− Acrescentar a utilização das melhores práticas, de forma combinada, em
automação industrial. Pesquisar sobre a utilização e combinação dos
frameworks do mercado (ITIL, ISO 9001, Lean Six Sigma, ISO 27001, ISO
27005, ISO 38500, CobiT) para desenvolvimento de um modelo focado em
automação industrial.
199
REFERÊNCIAS BIBLIOGRÁFICAS
ABGP. Associação Brasileira de Gerenciamento de Projetos. http://www.abgp.org.br.
Acesso em 14/04/2009.
AJMAL, M. M.; KOSKINEN, K. U. Knowledge Transfer in Project-Based Organizations: An Organizational Culture Perspective. Project Management Journal. WILEY/PMI. V.39, N.1. , p. 7-15, 2008.
ASQ. American Society for Quality. http://www.asq.org. Acesso em 01/06/2007.
BANI ALI, A. S.; ANBARI, F. T.; MONEY, W. H. Impact of Organizational and Project Factors on Acceptance and Usage of Project Management Software. Project Management Journal. WILEY/PMI. V.39, n.2. p. 55-72, 2008.
BAYUC, J. Vendor Due Diligence. ISACA Journal. V.3, 2009, p. 34-38.
BARNEY, J. O Futuro da Estratégia. RAE-Revista de Administração de Empresas –
vol.3. n2., pg. 45-48, 2004.
BRASSCOM. Associação Brasileira de Empresas de Tecnologia da Informação e
Comunicação. http://www.brasscom.org.br. Acesso em 20/01/2010.
BURKHOLDER, N. C. Outsourcing. The Definite View, Applications, and
Implications. 1a. ed. New Jersey: John Wiley & Sons, 2006
CARBONEL, J. C. Assessing IT Security Governance Through a Maturity Model and
the Definition of a Governance Profile. Information Systems Control. V.2. 2008, p. 29-
32, 2008.
CARVALHO, M. M.. QFD: uma ferramenta de tomada de decisão em projeto. 1997.
162 p. Tese (Doutorado Engenharia de Produção) – EPS- UFSC, Florianópolis, 1997
CASSIDY, A. A Practical Guide to Information Systems Process Improvement. 1a.
ed. Boston: St. Lucie. 2001:49.
200
CHESBROUGH, H. Open Innovation. 1ª. ed. Boston: Harvard Business Press, 2005
CLEMENTE, S. O Modelo GSS-COBITIL para Gerenciamento de Suporte de
Serviços de Tecnologia da Informação. 2007. 186 p. Tese (Doutorado) – Engenharia
Elétrica – Sistemas Digitais - USP, São Paulo, 2007.
CHRISTENSEN, E. H.; COOMBES-BETZ, K. M.; STEIN, M. S. The Certified Quality
Process Analyst Handbook. Milwaukee. ASQ-American Society for Quality, 2007
COBIT V4.1. Cobit v4.1. ISACA/ITGI, 2006
COPC. Customer Operations Performance Center. HTTP://www.copc.com. Acesso
em 20/12/2009.
COYNE, P. C..; HORN, J. Como Prever a Reação de Concorrentes. Harvard Business Review. Vol. 87, N. 4, Pg. 70-77, 2009.
eSCM. Manual eSCM/SP. ITSQC. http://itsqc.cmu.edu/. Carnegie Mellon University, 2004
FEIGENBAUM, A.V. The International Growth of Quality. Quality Progress. ASQ –
American Society for Quality. February, 2007.
FALCONI, V. Gerenciamento pelas Diretrizes. 4ª. ed. Belo Horizonte: INDG, 2004
FIANI, R. Teoria dos Jogos. 1ª. ed. Rio de Janeiro: Campus, 2004
FLEURY, A. C. C.; FLEURY, M. T. L. Estratégias Competitivas e Competências
Essenciais: Perspectivas pra a Internacionalização da Indústria no Brasil. Revista
Gestão e Produção. São Carlos, vol. 10. N2. P.129-144, 2003.
GANS, N. Customer Loyalty and Supplier Competition. Management Science.
Vol.48. No. 2. P.207-221, 2002.
GARTNER. http://www.gartner.com. Acesso em 05/12/2008
201
GARTNER. ISO/IEC 20000 Has an Important Role in Sourcing Management
Disponível em http://www.gartner.com. Acesso em 05/01/2006
GARTNER. Reduce Service Risk by Using SAS 70 and BS 15000 (ISO/IEC 20000)
Standards. Disponível em http://www.gartner.com. 05/12/2005
GEORGE, M. L. Lean Six Sigma for Services. New York: McGraw-Hill, 2003 GIL, A. C. Como Elaborar Projetos de Pesquisa. São Paulo: Atlas, 1996.
GREMBERGEN, W.V.; HAES, S.D. Enterprise Governance of Information
Technology. New York: Spring. 1ª. ed. 2009.
GUENA. R. Teoria dos Jogos. Apostila MBA Economia de Empresas FIPE. São
Paulo: 2005.
GOOLSBY, K. Implementing/Transitioning into Outsourcing: Advice for Starting an
Outsourcing Relationship. Outsourcing Journal. July, 2002.
GOODMAN, J.; COLLIER, C. D. Deliver Great Service by Listening and Adapting.
Quality Progress. ASQ – American Society for Quality. March, 2007.
GOTTSCHALK, P.; SOLLI-SAETHER, H.. Managing Successful IT Outsourcing
Relationships. 1a. ed. Hershey: IRM Press, 2006.
GYGI, C.; DECARLO, N.; WILLIANS, B. Seis Sigma para Leigos. 1ª Ed. Rio de
Janeiro: AltaBooks, 2008.
HALL, J. M.; JOHNSON, M. E. When Should a Process Be Art, Not Science?. Harvard Business Review. V.87, N. 3, p. 68-76, 2009.
HALVEY, J. K.; MELBY, B. M. Information Technology Outsourcing Transactions – Process, Strategies and Contracts. 2a. ed. New Jersey: 2005.
202
HAMMER, M. A Agenda. 5ª. ed. Rio de Janeiro: Campus, 2000.
HANSEN, M. T. Quando a Colaboração Interna é Ruim para a Empresa. Harvard Business Review. V.87, n. 4., p. 62-69, 2009.
HARIED, P.; RAMAMURTHY, F.T. Evaluating the Success in International Sourcing of Information Technology Projects: The Need for a Relational Client-Vendor Approach. Project Management Journal. WILEY/PMI. V.40, n.3. p. 56-71, 2009.
HARRIES, S.; HARRISON, P. Recognising the Need for Val IT. Information Systems
Control Journal, v.3, 2008. p.18-19, 2008.
HELDMAN, K. Project Management. 3a. ed. New Jersey: Wiley Publishing, 2005
HITT, M. A.; IRELAND, R. D.; HOSKISSON, R. E. Administração Estratégica. 2ª. ed.
São Paulo: Thomson Pioneira, 2007
HURT, M., THOMAS, J.L. Building Value Through Sustainable Project Management Offices. Project Management Journal. WILEY/PMI. V.40, n.1. p. 55-72, 2009.
INFOSYS. Modelo ISF. http://ww.infosys.com. Acesso em 20/03/2009.
ISD. Modelo ISF. http://www.isd.com.br. Acesso em 31/03/2009.
ISO 9001. http://www.iso.com, 2008.
ISO 14001. http://www.iso.com, 2004.
ISO 27001. http://www.iso27001certificates.com/. 2007.
ISO 27005. http://www.iso27001certificates.com/. 2007.
ISO 20000. http://www.isoiec20000certification.com/. 2005.
ISO 38500. http://www.iso.com. 2008.
ITGI. IT Control Objectives. Rolling Meadows: ISACA, 2008
ITIL SS. Livro Service Strategy. Londres: OGC. 2007
ITIL SD. Livro Service Design. Londres: OGC. 2007
203
ITIL ST. Livro Service Transition. Londres: OGC. 2007
ITIL SO. Livro Service Operation. Londres: OGC. 2007
ITIL CSI. Livro Service Improvement. Londres: OGC. 2007
JORGENSEN, S.; ZACCOUR, G.. Developments in differential game theory and numerical methods: economic and management applications. Computational Management Science. Vol.4. N.2. Pg. 159-181. 2007.
JUNIOR, I. M; CIERCO, A.A.; ROCHA, A.V.; MOTA, E.B. Gestão da Qualidade. 2ª. ed. Rio de Janeiro: FGV Editora, 2003.
KAPLAN, R.; NORTON, D. Mapas Estratégicos. 1ª. ed. Rio Janeiro: Campus, 2004
KENDALL, G. I.; ROLLINS, S.C. Advanced Project Portfolio Management and the PMO. 1ª. ed. Boca Raton: J. Ross Publishing, 2003.
KOOLE, G. Call Center Mathematics. Vrije Universiteit Amsterdam, 2007.
KOTLER, P. Administração de Marketing. Edição de Novo Milênio. 1ª. ed. São Paulo:
Prentice Hall. 2000.
KUBIAK, T. M.; BENBOW, D. W. The Certified Six Sigma Black Belt Handbook. 2ª.
Ed. Milwaukee: ASQ Quality Press, 2009
KUJALA, J.; MURTOARO, J.; ARTTO, K. A Negotiation Approach to Project Sales
and Implementation. Project Management Journal. v 38, n.4, p.33-44, 2007
KUMAR, S.; ARBI, A.S Outsourcing strategies for apparel manufacture: a case study. Journal of Manufacturing Technology Management. v 19, n.1, p.73-91, 2007
LAURINDO, F. J. B. Tecnologia da Informação. 1ª. ed. São Paulo: Atlas, 2008.
LUECHE, R. Estratégia. Harvard Business Essentials. 1ª. Ed. Rio de Janeiro:
Record, 2008.
204
MONTEIRO, A. Certificação PMP. 2a. ed. Rio de Janeiro: Brasport, 2006.
MONTEIRO, L. F. S. Modelo e-SCM: Uma Alternativa para a Melhoria de Processos
de Serviços Terceirizados de TI. Monografia. FGV. Brasilia, 2004.
MASCHIO, P. L. B.; SILVA, R. P. 10 Passos para Inovação em Outsourcing. Revista Mundo PM, n. 13, p.82-88, 2007.
MEKINIAN, G. C. Tata Consultancy Services: Globalization of IT Services. Harvard
Business Case. Boston. 24/04/2009.
MIGUEL, P. A. C. (Coord.). Metodologia de Pesquisa em Engenharia de Produção e Gestão de Operações. 1ª. Ed. Rio de Janeiro: Abepro/Campus, 2009. MIGUEL, P.A.C..; CARNEVALLI, J.A. Aplicações não-convencionais do Desdobramento da Função Qualidade. 1. ed. São Paulo: Artliber, 2006.
MIGUEL, P. A. C. Estudo de caso na engenharia de produção: estruturação e recomendações para sua condução. Revista Produção. V.17.n.1, p. 216-229, 2007.
MILNER, J. M.; OLSEN, T. L.. Service-Level Agreements in Call Centers: Perils and Prescriptions. Management Science. Vol. 54, n.2, p. 238-252, 2008.
MIT. Process Handbook Project. http://www.mit.edu. Acessado em 01/03/2009.
MERGEL, I.; VONKORTZFLEISCH, H. F.O; PROLL, C. Potentials of Social Networks
for Knowledge Management. . Hawaii Conference on System Sciences, 2007.
NALEBUFF, B. J.; BRANDENBURGER, A. M. Co-Opetition. 1.ed. Currency Book: New York, 1996.
OPM3. Organizational Project Management Maturity Model. PMI, 2003.
PARKINSON, M. J. A.; BAKER, N. J. IT and Enterprise Governance. Information Systems Control Journal. ISACA/ITGI. p. 10-14. V.3, 2005.
PATAH, L. A.; OLIVEIRA, A. L. P.; CHEN, E. C. T. Um Programa para a Implantação da Cultura do Gerenciamento de Projetos. Mundo Project Management. Ano 3. No. 18.
205
PARASURAMAN, A.; ZEITHAML, V. A.; BERRY, L. A conceptual model of service
quality and its implications for future research. Journal of Marketing, v. 49 (fall), p. 41-
50, 1985.
PEREIRA, A. Vendendo Software. 1a. ed. São Paulo: Novatec, 2004.
PMBOK. Guia de Conhecimentos em Gerenciamento de Projetos. 3ª. ed. PMI –
Project Management Institute. 2004
PORTER, M. Estratégia Competitiva. 2a. ed. Rio de Janeiro: Campus, 2004.
PRAHALAD, C. K.; HAMEL, G. The Core Competence of the Corporation. Harvard
business Review. P.3-15. May, June, 1990.
PRIES, K. H. Six Sigma for the New Millennium. 2a. ed. Milwaukee: ASQ Quality Press, 2009.
REICH, B. H.; GEMINO, A.; SAUER, C. Modeling the Knowledge Perspective of IT
Projects. Project Management Journal. WILEY/PMI. V.39, 2008 p. S4-s14, 2008.
ROBINSON, N. The Many Faces of IT Governance. Information Systems Control.
V.1, 2007, p. 14-16.
SAAD, A. C. Terceirização de Serviços de TI. 1ª. ed. Rio de Janeiro: Brasport, 2006
SANTOS, G. S.; CAMPOS, F.C. Gestão do Conhecimento em Serviços de TI: Um
Estudo de Caso do Modelo ITIL-SKMS em Monitoramento de Infraestrutura de TI.
Revista Gestão Industrial, v.5, Edição Especial Gestão do Conhecimento, p. 124-
141, 2009.
SANTOS, G. S.; CAMPOS, F.C. Uma Abordagem de Governança Interna de TI para
Provedores de Outsourcing. XV Simpep, 2008a.
206
SANTOS, G. S.; CAMPOS, F.C. Vantagem Competitiva em Certificações de
Produção de Software e Gestão de Serviços de TI: Lições das Empresas de TI
Indianas. XXVIII ENEGEP, 2008b.
SANTOS, G. S.. Combinação de Melhores Práticas em Certificações de TI. São
Paulo: USP-3º. Contecsi/11rd WCA, 2006
SANTIAGO JR., J. R. S.. Gestão do Conhecimento – A Chave para o Sucesso
Empresarial. 1ª. ed. São Paulo: Novatec, 2004.
SCHNIEDERJANS, M. J.; SCHNIEDERJAN, A. M.;SCHNIEDERJAN, D.G.S.
Outsourcing Management Information Systems. 1ª. ed. London: Ideagroup, 2007.
SCHUMPETER, J.. A Teoria do Desenvolvimento Econômico. 1ª. ed. São Paulo: 1982.
SEI. Software Engineering Institute. CMU – Carnegie Mellon University.
HTTP://www.sei.cmu.edu. Acesso em 28/12/2009.
SLACK, N. Vantagem Competitiva em Manufatura. 1ª. ed. São Paulo: Atlas, 2002.
SHPILBERG, D.; BEREZ, S.; PURYEAR, R.; SHAH, S. Avoiding the Alignment Trap
in Information Technology. MIT Sloan Management Review. p. 51-58, 2007
SILVA, E. M.. YUE, G.. ROTONDANO, R. G.i. LAURINDO, F. J. B.. Gestão da
Qualidade de Serviços de TI. Em Busca de Competitividade. Revista Produção.
V.15.n.2, p;329-340, 2006
SILVA, E. M. O Relacionamento entre Estratégia de Manufatura, Práticas de
Produção e Desempenho Operacional e de Negócio: Uma Survey em Firmas do
Setor Moveleiro. Tese (Doutorado em Engenharia de Produção) – EESC – USP
2008.
SILVA, M. C. M. Perspectivas do Alinhamento Estratégico entre Negócios e
Tecnologia da Informação em Empresas de Software do Porto Digital: Um Prisma de
207
Divergentes Facetas. 2009. 245 p. Tese (Doutorado Administração de Empresas) –
PROPAD- UFPE, Recife, 2009
SIMKOVA, E. INNO IT Framework. Cobit Focus. ISACA. 2008.
SINGLETON, T. W. The COSO Model: How IT Auditors Can Use IT to Measure the
Effectiveness on Internal Controls. Information Systems Control Journal, v.1 , 2008.
p.9-10, 2008.
SONG, N.; PLATTS, K; BANCE, D. Total acquisition cost of overseas outsourcing/sourcing: a framework and a case study. Journal of Manufacturing Technology Management. v 18, n.7, p.858-875, 2007
STACHTCHENCO, P. The Taking Governance Forward Mapping Initiative. Isaca
Journal. ISACA. V.1. , p.28-31, 2008.
STONEBURNER, G.; GOGUEN, A; FERINGA, A. Risk Management Guide for Information Technology Systems. Washington: NIST, 2001.
SYLVER, B.. Inovação: Um processo para ser repetido. Revista HSM Management. Ed. 67. São Paulo: HSM, 2008 TAKEUCHI, H.; NONAKA, I. Gestão do Conhecimento. 1ª. ed. Porto Alegre: Bookman, 2008. THIOLLENT, M. Metodologia da Pesquisa Ação. 16 ed. São Paulo: Cortez, 2005. THOMAS, M.; JACQUES, P. H.; ADAMS, J. R.; KIHNEMAN-WOOTEN, J. Developing an Effective Project: Planning and Team Building Combined. Project Management Journal. WILEY/PMI. V.39, N.4. , p.105-113, 2008.
TCS. Global Delivery Model. http://www.tcs.com. Acesso em 20/03/2009.
TIDD, J.; BESSANT, J.; PAVITT, K.; Gestão da Inovação. 3ª. ed. Bookman: Porto
Alegre, 2008.
TIWARI, A.; TURNER, C; SACKETT, P. A Framework for Implementing Cost and
Quality Practices Within Manufacturing. Journal Of Manufacturing Technology
Management. v.18, n.6, p.731-760, 2007.
208
VAL IT. Val IT Framework. Enterprise Value: Governance of IT Investments.
ISACA/ITGI, 2006
WEEKS, M.; FEENY, D. Outsourcing: From Cost Management to Innovation and
Business Value. California Management Review. Hass School of Business – UC
Berkeley. v 50, n.4, p.127-146, 2008.
WERKEMA, C. Criando a Cultura Seis Sigma. 1ª. Ed. Rio de Janeiro: Qualitymark, 2002 YANG, Z.; GOKER, Y.;BABICH, V. Supply Disruptions, Asymmetric Information, and a Backup Production Option. Management Science. Vol.55, N.2. p. 192-209, 2009. YIN, R. Estudo de caso: Planejamento e Métodos. Porto Alegre:Bookman,2005.3ªed.
209
APÊNDICE A - APLICATIVO MOPP
1. Tecnologia
Para automatizar o modelo, foi desenvolvido um software em plataforma livre (open
source), conforme especificação abaixo:
• Linguagem de Programação: Java 6 e JSP
• Banco de Dados: PostgreSQL 8.3
• Servidor Web: Tomcat 6.0
O PostgreSQL foi selecionado por ser um banco de dados de código livre, robusto,
com funções de triggers, stored procedures, views e sequence, como também
possuir uma linguagem procedural denominada PGPLSQL, bem próxima à
linguagem PL/SQL da Oracle. O banco de dados selecionado leva vantagem sobre o
MYSQL, por exemplo, que é seu concorrente mais próximo em open source
(software livre). O MYSQL, que pertence a uma empresa de TI (Sun Microsystems),
passou a ter, a partir da sua versão mais recente, recursos de triggers e stored
procedures, elementos fundamentais em banco de dados. Este banco de dados não
possui uma linguagem procedural, que permite flexibilidade e adição de recursos
adicionais em procedures, triggers e outros códigos SQL. Já o Oracle XE é gratuito e
possui todas as vantagens do PostgreSQL, porém, pela sua característica de ser
uma versão gratuita do banco de dados principal da Oracle (alto valor de
investimento), não foi considerado pelo risco da sua continuidade. O quadro 54 faz
uma comparação entre as principais funções dos três bancos de dados.
Quadro 54 – Comparação PostgreSQL x MySQL x Oracle XE
# Atributos PostgreSQL MySQL Oracle XE
01 Executa em Windows e Linux X X X 02 Compatibilidade com PHP, Java, C#, Ruby, C/C++ X X X 03 Licença Gratuita X X X
04 Baixa exigência de processamento X X
05 Recursos de triggers, sequence, sp e views X Recente X
06 Suporte a SSL (segurança de aplicações) X Recente X
07 Propriedade independente X X
08 Linguagem Procedural X X
09 Robustez (tamanho banco, tabelas, linhas, campos) X X
210
A linguagem Java foi selecionada pelo fato de ser uma plataforma livre, ao contrário
da plataforma .NET. Permitirá dessa forma facilidade na manutenção e atualização
do código da aplicação por parte dos provedores. O PHP (linguagem open source)
também poderia ter sido utilizada, porém, trata-se de uma linguagem e não de uma
plataforma com vários recursos e frameworks (JSP, JSTL, Struts, JSF, VRaptor,
Hibernate) avançados como o Java, sem contar que é uma linguagem totalmente
interpretada com erros ocorrendo em tempo de execução. Também não é
fortemente orientada a objetos. Com o código em Java, o provedor poderá realizar
uma engenharia reversa e na sequência uma reengenharia do código da aplicação
de forma muito rápida, colocando-o no formato MVC (Mode-View-Controller) e
utilizando os recursos mais avançados da linguagem Java. O quadro 56 mostra
uma comparação entre as três linguagens de desenvolvimento que foram avaliadas
para o desenvolvimento do aplicativo MOPP.
Quadro 55 – Comparação Java x PHP x C#
# Atributos Java PHP C#
01 Open Source X X 02 Forte orientação a objetos X X 03 Fortemente tipada e com sobrecarga de métodos X X
04 Linguagem não interpretada (100%) X X
05 Fácil Portabilidade X X
06 Suporte a SSL (segurança de aplicações) X X X
07 Propriedade independente X X
08 Plataforma de desenvolvimento com recursos extras X X
09 Robustez (tamanho banco, tabelas, linhas, campos) X X
211
2. Acesso ao sistema, navegação e cadastros
Para acessar a tela principal do sistema (figura 47), deve ser digitado o seguinte
comando no browser: http://localhost:8080/mopp/mopp.jsp.
Figura 47 – Tela Principal de Navegação do MOPP
Para realizar um cadastro de um novo processo, framework ou de um novo
relacionamento, deve-se clicar na opção << Cadastro e Matrizes >>. Será mostrada
uma tela, conforme figura 48.
Figura 48 – Cadastros e Relacionamentos do MOPP
212
O usuário pode navegar no sistema clicando nos ícones. Por exemplo, ao clicar na
opção << Gestão de Projetos >> é mostrada a tela dos processos da etapa do ciclo
de vida, conforme figura 49.
Figura 49 – Tela de Navegação Processos do MOPP
213
Ao clicar em um dos processos, como por exemplo, Modelo de Governança, é
mostrada uma tela no padrão SIPOC e do Process Handbook- MIT, com as opções
de consulta das melhores práticas dos frameworks (ITIL, CMMI, CobiT, Lean Six
Sigma) e dos templates vinculados ao processo de outsourcing, conforme figura 50.
Figura 50 – MOPP - Tela de Consulta Processos x Frameworks x Templates
Por meio do SIPOC, pode ser acessada a tela de consulta das práticas e templates,
conforme o processo ativo e também realizar alterações.
3. Inclusão e consulta de processos e prática
Para incluir uma nova prática, os seguintes dados são necessários:
• Id: automática do sistema
• Id Prática: código do framework no processo da metodologia
• Tipo Prática: informar se o framework é referente a << Outsourcing >>, <<
Governança de TI >>, < Serviços de TI >>.
• Proprietário: o responsável pelo framemwork (ex. OGC, ISACA, ISO)
• Localização: informar o local onde pode ser encontrado o framework
• Id Prática: O código da prática/processo dentro do framework
214
• Descrição do framework: descrição resumida do framework
• Descrição da prática: descrever o objetivo principal da prática/processo
• Resumo do Modelo: descrever os principais aspectos da prática/processo, útil
para entender a sua aplicação no MOPP.
• Utilidade no Modelo MOPP: descrever como o modelo pode ser utilizado de
forma prescritiva no MOPP.
Todas as informações dos quadros descritos na pesquisa já estão cadastradas no
sistema, conforme figura 51. O usuário pode acrescentar novos processos,
relacioná-lo às práticas dos frameworks e informar como pode ser utilizado dentro do
ciclo de vida do modelo MOPP.
Figura 51 – MOPP - Tela de Consulta Processos
215
4. Inclusão de um novo template
Para incluir um novo template (figura 52), prencher os seguintes campos:
Figura 52 – MOPP - Tela de Template
• Id Template: automática do sistema
• Descrição do Template: Descrição do template (ex. Project charter, catálogo de
serviços).
• Localização do Template: Localizaçào do template. Informar o endereço web:
http://localhost:8080/tese/modelo/templates/<<nomedotemplate>>
• Utilidade no Modelo: Descrever como o MOPP poderá ser utilizado na situação
específica do provedor.
5. Código de Acesso ao Banco de Dados – Java x PostgreSQL 8.3
<%@ page import="java.sql.*" %><%@ page import="java.text.*" %> <%@ page import="java.util.Date" %><% String url = "jdbc:postgresql://localhost:5432/postgres"; Connection con = null; Statement stm = null; ResultSet res2 = null; Class.forName ("org.postgresql.Driver"); con = DriverManager.getConnection(url, "postgres", "gilmar"); stm = con.createStatement(); %>
6. Procedimentos de Instalação do Aplicativo MOPP
a. O CD que acompanha esta pesquisa contém a seguinte estrutura:
216
− << \jsp >> contém os arquivos fontes jsp
− << \bd >> contém o backup do banco de dados em postgreSQL
− << ferramentas >> contém as ferramentas necessárias (open source) para
instalação e operação do aplicativo:
� JDK 6 (Compilador Java)
� Banco de Dados PosgreSQL 8.3
� pgAdmin III 1.8 (navegador PostgreSQL)
� Tomcat 5.5 (servidor web)
� Drive JDBC do PostgreSQL (para acesso ao banco de dados)
b. Para a instalação proceder da seguinte forma:
− Instalar o JDK 6
− Instalar o PostgreSQL e o pgAdmin III
− Instalar o Tomcat 6.0
− Importar o banco de dados dentro do PostgreSQL (backup no CD):
� Clicar no botão direito do mouse no banco de dados postgres
(banco default, mantido dessa forma para facilitar a instalação e
operação do banco de dados).
� Seleciona a opção << Restaurar >>
� No campo << Nome do arquivo >> clique na opção << procurar >>
e localizar o backup no diretório << \bd >> do CD.
� Manter desmarcadas as opções << Somente Dados >>, <<
Somente Esquema >> << Objeto Unitário >>.
� Clique em << OK >>
− Copiar as páginas JSP para o servidor web na pasta
\tomcat\webapps\root\mopp
− Copiar o arquivo postgresql-8.3-604.jdbc4 (driver JDBC do PostgreSQL
para acesso ao banco de dados) para a pasta \tomcat\lib
− Acessar o browser e testar a aplicação digitando:
http://localhost:8080/mopp/mopp.jsp.