Iso20000 2

NORMA ABNT NBR
BRASILEIRA ISO/IEC
20000-2
Segunda edição
20.08.2013
Exemplar para uso exclusivo - Easy Net Comercio de Equipamentos de Informatica Ltda - ME - 06.733.460/0001-05 (Pedido 735517 Impresso: 22/04/2020)
Válida a partir de
20.09.2013
Tecnologia da informação — Gerenciamento

de serviços
Parte 2: Guia de aplicação do sistema de gestão
de serviços
Information technology — Service management
Part 2: Guidance on the application of service managemente systems
ICS 03.080.99; 35.020 ISBN 978-85-07-04374-4
Número de referência
ABNT NBR ISO/IEC 20000-2:2013
106 páginas
© ISO/IEC 2012 - © ABNT 2013

© ISO/IEC 2012
Todos os direitos reservados. A menos que especificado de outro modo, nenhuma parte desta publicação pode ser
reproduzida ou utilizada por qualquer meio, eletrônico ou mecânico, incluindo fotocópia e microfilme, sem permissão por
escrito da ABNT, único representante da ISO/IEC no território brasileiro.
© ABNT 2013
Todos os direitos reservados. A menos que especificado de outro modo, nenhuma parte desta publicação pode ser
reproduzida ou utilizada por qualquer meio, eletrônico ou mecânico, incluindo fotocópia e microfilme, sem permissão por
escrito da ABNT.
ABNT
Av.Treze de Maio, 13 - 28º andar
20031-901 - Rio de Janeiro - RJ
Tel.: + 55 21 3974-2300
Fax: + 55 21 3974-2346
abnt@abnt.org.br
www.abnt.org.br
ii © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

Sumário Página
Prefácio Nacional ...............................................................................................................................iv

Introdução ..........................................................................................................................................vii
1 Escopo ................................................................................................................................1
1.1 Geral ....................................................................................................................................1

1.2 Aplicação ............................................................................................................................2
2 Referência normativa .........................................................................................................2
3 Termos e definições ...........................................................................................................2
4 Requisitos gerais do sistema de gestão de serviços .....................................................3
4.1 Responsabilidades da direção..........................................................................................3
4.1.1 Compromisso da direção ..................................................................................................3
4.1.2 Política de gerenciamento de serviço ............................................................................10
4.1.3 Autoridade, responsabilidade e comunicação ..............................................................12
4.1.4 Representante da direção ...............................................................................................13
4.2 Governança de processos operados por outras partes ...............................................15
4.2.1 Guia para processos operados por outras partes ........................................................15
4.2.2 Outras partes ....................................................................................................................15
4.2.3 Demonstração da responsabilidade e autoridade ........................................................15
4.2.4 Desempenho e conformidade de processos .................................................................16
4.2.5 Determinar o desempenho e conformidade do processo ............................................17
4.2.6 Controle do planejamento e priorização de melhorias do processo ..........................17
4.3 Gerenciamento de documentação..................................................................................18
4.3.1 Estabelecer e manter documentos .................................................................................18
4.3.2 Controle de documentos .................................................................................................19
4.3.3 Controle de registros .......................................................................................................20
4.4 Gerenciamento de recursos ............................................................................................20
4.4.1 Disponibilização de recursos ..........................................................................................20
4.4.2 Recursos humanos ..........................................................................................................21
4.5 Estabelecimento e melhoria do SGS ..............................................................................23
4.5.1 Definição do escopo ........................................................................................................23
4.5.2 Planejar o SGS (Planejar) ................................................................................................24
4.5.3 Implementar e operar o SGS (Fazer) ..............................................................................26
4.5.4 Monitorar e analisar criticamente o SGS (Checar)........................................................26
4.5.5 Manter e melhorar o SGS (Agir) ......................................................................................28
5 Desenho e transição de um serviço novo ou modificado ............................................29
5.1 Geral ..................................................................................................................................29
5.1.1 Intenção dos requisitos ...................................................................................................29
5.1.2 Conceitos ..........................................................................................................................29
5.1.3 Explicação sobre os requisitos ......................................................................................29
5.2 Planejar serviços novos ou modificados .......................................................................30
5.2.1 A necessidade de serviços novos ou modificados ......................................................30
5.2.2 Mudanças com impacto significativo a um serviço ou cliente ....................................30
© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados iii

5.2.3 Política em mudanças com impacto significativo .........................................................30

5.2.4 Gerenciando mudança como um projeto.......................................................................31
5.2.5 Contribuições de outras partes ......................................................................................32
5.2.6 Análise de risco ................................................................................................................32
5.2.7 Critério para aceitação de serviços ................................................................................32
5.2.8 Remoção de serviço ........................................................................................................32

5.3 Desenho e desenvolvimento de serviços novos ou modificados ...............................33
5.3.1 Atividades executadas pelo provedor de serviços, cliente e outras partes ...............33
5.3.2 Gerenciamento de risco ..................................................................................................34
5.3.3 Atividades do Desenho de Serviço ................................................................................35
5.4 Transição de um serviço novo ou modificado ..............................................................37
5.5 Documentos e registros ..................................................................................................38
5.6 Autoridades e responsabilidades ...................................................................................38
6 Processos de entrega de serviço ...................................................................................38
6.1 Gerenciamento de nível de serviço ................................................................................38
6.1.2 Conceitos ..........................................................................................................................39
6.1.3 Explicação dos requisitos ...............................................................................................39
6.1.4 Documentos e registros ..................................................................................................43
6.1.5 Autoridades e responsabilidades ...................................................................................44
6.2 Relatos de serviço............................................................................................................44
6.2.2 Conceitos ..........................................................................................................................44
6.3 Gerenciamento de continuidade e disponibilidade de serviço ...................................45
6.3.2 Conceitos ..........................................................................................................................46
6.3.4 Continuidade do serviço e monitoramento da disponibilidade e testes ....................49
6.4 Orçamento e contabilização para serviços ...................................................................52
6.4.2 Conceitos ..........................................................................................................................52
6.5 Gerenciamento da capacidade .......................................................................................55
6.5.2 Conceitos ..........................................................................................................................56
iv © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados


6.6 Gerenciamento da segurança da informação ...............................................................59
6.6.2 Conceitos ..........................................................................................................................59

7 Processo de relacionamento ..........................................................................................63
7.1 Processo de gerenciamento de relacionamento do negócio ......................................63
7.1.2 Conceitos ..........................................................................................................................64
7.2 Gerenciamento de fornecedor ........................................................................................67
7.2.2 Conceitos ..........................................................................................................................67
8 Processos de resolução ..................................................................................................71
8.1 Gerenciamento de incidente e requisição de serviço ..................................................71
8.1.2 Conceitos ..........................................................................................................................71
8.1.4 Procedimento para incidente crítico ..............................................................................73
8.2 Gerenciamento de problema ...........................................................................................75
8.2.2 Conceitos ..........................................................................................................................75
9 Processos de controle .....................................................................................................79
9.1 Gerenciamento de configuração ....................................................................................79
9.1.2 Conceitos ..........................................................................................................................79
9.2 Gerenciamento de mudanças .........................................................................................83
© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados v

9.2.2 Conceitos ..........................................................................................................................83

9.3 Gerenciamento de liberação e implementação .............................................................86

9.3.2 Conceitos ..........................................................................................................................87
Bibliografia .......................................................................................................................................105
Anexo
Anexo A (informativo) Interfaces entre processos e integração de processos com SGS ...........93
Figuras
Figura 1 – Metodologia PDCA aplicada ao gerenciamento de serviços .......................................xi
Figura 2 – Sistema de gestão de serviços ........................................................................................1
Figura 3 – Exemplo de relacionamento entre fornecedor-líder e fornecedor subcontratado ....70
Tabelas
Tabela 1 – Matriz-exemplo de resolução de incidentes resolvidos nos prazos baseada
em prioridades..................................................................................................................72
Tabela A.1 – Interfaces e integração entre desenho e transição de serviços novos
ou modificados .................................................................................................................93
Tabela A.2 − Interfaces e integração para GNS ..............................................................................94
Tabela A.3 – Interfaces e integração para relatos de serviço .......................................................94
Tabela A.4 – Interfaces e integração para gerenciamento de disponibilidade e continuidade
do serviço .........................................................................................................................95
Tabela A.5 – Interfaces e integração para serviços de contabilidade e orçamento ....................96
Tabela A.6 – Interfaces e integração entre gerenciamento da capacidade e o resto do SGS ...97
Tabela A.7 – Interfaces e integração para GSI ................................................................................98
Tabela A.8 – Interfaces e integração para GRN ..............................................................................99
Tabela A.9 – Interfaces e integração para gerenciamento de fornecedores................................99
Tabela A.10 – Interfaces e integração para gerenciamento de requisição de serviço
e incidente.......................................................................................................................100
Tabela A.11 – Interfaces e integração para gerenciamento de problemas ................................101
Tabela A.12 – Interfaces e integração para gerenciamento de configuração ............................102
Tabela A.13 – Interfaces e integração para gerenciamento de mudanças.................................103
Tabela A.14 – Interfaces e integração para gerenciamento de liberação e implementação ....104
vi © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

Prefácio Nacional
A Associação Brasileira de Normas Técnicas (ABNT) é o Foro Nacional de Normalização. As Normas

Brasileiras, cujo conteúdo é de responsabilidade dos Comitês Brasileiros (ABNT/CB), dos Organismos
de Normalização Setorial (ABNT/ONS) e das Comissões de Estudo Especiais (ABNT/CEE), são
elaboradas por Comissões de Estudo (CE), formadas por representantes dos setores envolvidos,
delas fazendo parte: produtores, consumidores e neutros (universidades, laboratórios e outros).
Os Documentos Técnicos ABNT são elaborados conforme as regras da Diretiva ABNT, Parte 2.
A Associação Brasileira de Normas Técnicas (ABNT) chama atenção para a possibilidade de que
alguns dos elementos deste documento podem ser objeto de direito de patente. A ABNT não deve ser
considerada responsável pela identificação de quaisquer direitos de patentes.
A ABNT NBR ISO/IEC 20000-2 foi elaborada no Comitê Brasileiro de Computadores e Processamento
de Dados (ABNT/CB-21), pela Comissão de Estudo de Operações de Tecnologia da Iinformação
(CE-21:007.25). O Projeto circulou em Consulta Nacional conforme Edital nº 05, de 06.06.2013
a 08.07.2013, com o número de Projeto ABNT NBR ISO/IEC 20000-2.
Esta Norma é uma adoção idêntica, em conteúdo técnico, estrutura e redação, à

ISO/IEC 20000-2:2012, que foi elaborada pelo Technical Committee Information Technology
(ISO/IEC/JTC 1), conforme ISO/IEC/ Guide 21-1:2005.
Esta segunda edição cancela e substitui a edição anterior (ABNT NBR 20000-2:2008), a qual foi
tecnicamente revisada. As principais diferenças são como se segue:
— maior alinhamento com a ABNT NBR ISO 9001 e ABNT NBR ISO/IEC 27001;
— mudanças na terminologia para refletir o uso internacional;
— novo guia sobre a governança dos processos operados por outras partes;
— mais guias sobre a definição do escopo de aplicação do SGS;
— mais guias sobre a melhoria contínua do SGS e serviços;
— mais guias sobre o desenho e transição de serviços novos ou modificados.
A ABNT NBR ISO/IEC 20000, sob o título geral “Tecnologia da informação – Gerenciamento
de serviços”, tem previsão de conter as seguintes partes:
— Parte 1: Requisitos do sistema de gerenciamento de serviços;
— Parte 2: Guia de aplicação do Sistema de gestão de serviços;
— Parte 3: Direcionamento para a definição de escopo e aplicabilidade da

ABNT NBR ISO/IEC 20000-1;
— Parte 5: Exemplo de um plano de implementação da ABNT NBR ISO/IEC 20000-1.
© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados vii

O Escopo desta Norma Brasileira em inglês é o seguinte:
Scope
General
This part of ABNT NBR ISO/IEC 20000 provides guidance on the application of an SMS based
on ABNT NBR ISO/IEC 20000-1. This part of ABNT NBR ISO/IEC 20000 provides examples and
suggestions to enable organizations to interpret and apply ABNT NBR ISO/IEC 20000-1, including
references to other parts of ABNT NBR ISO/IEC 20000 and other relevant standards. This part
of ABNT NBR ISO/IEC 20000 is independent of specific best practice frameworks and the service
provider can apply a combination of generally accepted guidance and their own techniques.
Customers Service Management System (SMS) Customers

(and other Governance of processes (and other
Management responsibility
interested operated by other parties interested
Establish the SMS
parties) Documentation management parties)
Resource management
Service Design and transition of new or changed services Services

Requirements
Service delivery processes

Capacity management Service level management Information security
management
Service continuity & Service reporting Budgeting &
availability management accounting for services
Control processes
Configuration management
Change management
Release and deployment
management
Resolution processes Relationship processes

Incident and service request Business relationship
management management
Problem management Supplier management
Figure – Service management system
Figure 2 shows the processes from Clauses 6 to 9 in the central box. The Clause 5 design and transition
of new or changed services process surrounds the Clause 6 to 9 processes. This shows that the new
or changed services are operated by the processes in the central box. When there are no new
or changed services to which Clause 5 applies, all services can be delivered directly by Clauses 6 to 9.
The interfaces between the service management processes and the relationships between different
components of the SMS may be implemented differently by different service providers. The nature
of the relationship between the service provider and the customer can also influence how the SMS
is implemented to fulfil the requirements of ABNT NBR ISO/IEC 20000-1. For these reasons the
interfaces between processes are not represented in Figure 2.
Application
The service provider is accountable for the SMS and therefore cannot ask another party to fulfil
the requirements of Clause 4 of ABNT NBR ISO/IEC 20000-1:2011. For example, the service
provider cannot ask another party to provide the top management and demonstrate top management
commitment or to demonstrate the governance of processes operated by other parties.
viii © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

Some activities in Clause 4 may be performed by another party under the management of the service
provider. For example, service providers can engage other parties to conduct internal audits on their
behalf. Another example is where a service provider asks another party to create the initial service
management plan. The plan, once created and agreed, is the direct responsibility of and is maintained
by the service provider. In these examples, the service provider is using other parties for specific
short-term activities. The service provider has accountability, authorities and responsibilities for the
SMS. The service provider can therefore demonstrate evidence of fulfilling all of the requirements
of Clause 4 of ABNT NBR ISO/IEC 20000-1:2011.
The service provider can show evidence of fulfilling all requirements directly or can show evidence
of fulfilling most of the requirements directly as well as the governance of processes operated by other
parties. If the service provider relies on other parties for operation of the majority of the processes
in Clauses 5 to 9, the service provider is unlikely to be able to demonstrate governance of the processes.
However, if other parties operate only a minority of the processes, the service provider can normally
fulfil the requirements specified in ABNT NBR ISO/IEC 20000-1.
The defined, agreed and documented accountability, authorities and responsibilities for the SMS are
readily accessible to both the service provider and other relevant parties. To fulfil the requirements
of ABNT NBR ISO/IEC 20000-1 the service provider can agree changes to the terms of existing
contracts or other documented agreements.
ABNT NBR ISO/IEC 20000 excludes the specification of, or specific guidance about, any product
or tool. However, organizations can use this part of ABNT NBR ISO/IEC 20000 to help them use
or develop products or tools that support operation of the SMS.
© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados ix

Introdução
Esta parte da ABNT NBR ISO/IEC 20000 fornece orientação sobre a aplicação do sistema
de gerenciamento de serviços (SGS) com base na ABNT NBR ISO/IEC 20000-1. Esta parte da
ABNT NBR ISO/IEC 20000 não adiciona nenhum requisito aos mencionados
na ABNT NBR ISO/IEC 20000-1 e não explicita como a evidência pode ser fornecida a um avaliador
ou auditor. A intenção desta parte da ABNT NBR ISO/IEC 20000 é permitir que organizações e indivíduos
interpretem a ABNT NBR ISO/IEC 20000-1 com mais precisão e, portanto, a usem de forma mais eficaz.
Um SGS é definido na ABNT NBR ISO/IEC 20000-1 como um sistema de gestão para direcionar,
monitorar e controlar as atividades de gerenciamento de serviços do provedor de serviços. Convém
que o SGS inclua o que é necessário para o planejamento, o desenho, a transição, a entrega
e a melhoria dos serviços. Isto inclui, no mínimo, políticas de gerenciamento de serviços, objetivos,
planos, processos, interfaces de processos, documentação e recursos. O SGS engloba todos
os processos como um sistema de gestão mais abrangente, com os processos de gerenciamento
de serviços como parte do SGS.
A implementação e integração de um SGS, coordenadas, fornecem controle do andamento, uma

maior eficácia, eficiência e oportunidades de melhoria contínua. Isso permite a uma organização
trabalhar efetivamente com uma visão compartilhada. A operação de processos, conforme especificado
nas Seções 5 a 9, requer que o pessoal esteja bem organizado e coordenado. Ferramentas apropriadas
podem ser utilizadas para permitir que os processos de gestão do serviço sejam eficazes e eficientes.
As organizações mais eficazes consideram o impacto do SGS durante todas as fases do ciclo de vida
do serviço, desde o planejamento e desenho até a transição e operação, incluindo a melhoria contínua.
Esta parte da ABNT NBR ISO/IEC 20000 fornece exemplos e sugestões para que as organizações
interpretem e apliquem a ABNT NBR ISO/IEC 20000-1, incluindo referências a outras partes
da ABNT BR ISO/IEC 20000 e a outras normas pertinentes.
Usuários de normas são responsáveis pela sua correta aplicação. É importante para as organizações
e indivíduos que usam a ABNT NBR ISO/IEC 20000 entender os pontos listados abaixo.
— A ABNT NBR ISO/IEC 20000-1 não pretende incluir todos os requisitos estatutários
e regulatórios necessários, ou todas as obrigações contratuais do provedor de serviços.
Conformidade com a ABNT NBR ISO/IEC 20000-1 por si só não confere imunidade
em obrigações estatutárias.
— A ABNT NBR ISO/IEC 20000-1 é aplicável aos provedores de serviços internos e externos,
grandes e pequenos, comerciais e não comerciais.
— A ABNT NBR ISO/IEC 20000-1 promove a adoção de uma abordagem de processos integrados
ao planejar, estabelecer, implementar, operar, monitorar, medir, analisar criticamente, manter
e melhorar um SGS para o planejamento, o desenho, a transição, a melhoria e a entrega
de serviços que satisfaçam os requisitos de serviço.
A ABNT NBR ISO/IEC 20000 promove a aplicação da metodologia conhecida como “Plan-Do-
Check-Act” (PDCA) para o SGS e os serviços. A metodologia PDCA, mostrada na Figura 1, pode ser
brevemente descrita como segue:
Planejar: estabelecer, documentar e acordar o SGS, incluindo as políticas, objetivos, planos

e processos necessários para desenhar e entregar os serviços, de acordo com as necessidades
de negócio, os requisitos do cliente e as políticas do provedor de serviços.
x © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

Fazer: implementar e operar o SGS para o desenho, transição, entrega e melhoria dos serviços.
Verificar: monitorar, medir e analisar criticamente o SGS e os serviços contra os planos, políticas,
objetivos, requisitos e relatos dos resultados.
Agir: tomar ações para melhorar continuamente o desempenho do SGS. Isso inclui os processos
de gerenciamento de serviços e os serviços.
Quando usado dentro de um SGS, os aspectos mais importantes de uma abordagem de processo
integrado e da metodologia PDCA são os seguintes:
a) compreender e cumprir os requisitos de serviço para atingir a satisfação do cliente;
b) estabelecer a política e os objetivos para o gerenciamento do serviço;
c) desenhar e entrega de serviços com base no SGS que adicione valor para o cliente;
d) monitorar, medir e analisar o desempenho do SGS e dos serviços;
e) melhorar continuamente o SGS e os serviços baseados em medições objetivas.
Onde outros sistemas de gestão estão presentes, a implementação de um SGS, com a adoção
de uma abordagem de processo e da metodologia PDCA, permite ao provedor de serviços alinhar
ou integrar plenamente os sistemas de gestão da organização. Por exemplo, é possível integrar
a ABNT NBR ISO/IEC 20000 com um sistema de gestão da qualidade baseado
na ABNT NBR ISO 9001 e/ou um sistema de gestão de segurança da informação baseadona
ABNT NBR ISO/IEC 27001. Uma abordagem de sistema de gestão integrada aumenta a eficiência,
estabelece uma responsabilidade e rastreabilidade clara e melhora o planejamento organizacional,
a comunicação e o controle.
Planejar
Sistema de
gerenciamento
de serviços
Processos de
gerenciamento
Fazer de serviços Agir
Serviços
Checar
Figura 1 – Metodologia PDCA aplicada ao gerenciamento de serviços
© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados xi

Como indicado na ABNT NBR ISO/IEC 20000-1:
ABNT NBR ISO/IEC 20000 pode ser utilizada por:
a) uma organização que busca serviços, de provedores de serviços e exige garantia de que suas
necessidades de serviço serão cumpridas;
b) uma organização que exige uma abordagem consistente de todos os seus provedores
de serviços, incluindo aqueles em uma cadeia de suprimentos;
c) um provedor de serviços que se propõe a demonstrar a sua capacidade para o desenho,

transição, entrega e melhoria dos serviços que satisfaçam as exigências de serviço;
d) um provedor de serviços para monitorar, medir e analisar criticamente os seus processos

de gerenciamento de serviços e serviços;
e) um provedor de serviços para melhorar o desenho, transição, entrega e melhoria dos serviços
por meio da efetiva implementação e operação do SGS; um consultor, como critério para
a avaliação da conformidade do SGS de um provedor de serviços, com os requisitos desta
parte da ABNT NBR ISO/IEC 20000”
Esta parte da ABNT NBR ISO/IEC 20000 pode ser usada por uma organização em busca de orientação
sobre como melhorar o gerenciamento de serviços, se não está interessada em buscar a certificação.
xii © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

NORMA BRASILEIRA ABNT NBR ISO/IEC 20000-2:2013
Tecnologia da informação — Gerenciamento de serviços

Parte 2: Guia de aplicação do sistema de gestão de serviços
1 Escopo
1.1 Geral
Esta parte da ABNT NBR ISO/IEC 20000 fornece orientações sobre a aplicação de um SGS,
com base na ABNT NBR ISO/IEC 20000-1. Esta parte da ABNT NBR ISO/IEC 20000 fornece exemplos
e sugestões para permitir que as organizações interpretem e apliquem a ABNT NBR ISO/IEC 20000-1,
incluindo referências a outras partes da ABNT NBR ISO/IEC 20000 e outras normas pertinentes.
Esta parte da ABNT NBR ISO/IEC 20000 é independente de estruturas específicas de boas práticas
e o prestador de serviço pode aplicar uma combinação de orientações aceitas de forma geral
e as suas próprias técnicas.
Consumidor Sistema de gerenciamento de serviços (SGS) Consumidor

(e outras (e outras
Responsabilidade da diração Governança de processos
partes operados por outras partes partes
interessadas) Estabelecimento do SGS Gerencimento de documentação
interessadas)
Gerenciamento de recursos
Desenho e transição de serviços novos ou modificados

Requisitos de
Serviços
serviço Processo de fornecimento de serviços
Gerenciamento do Gerenciamento da capacidade
nível de serviço
Gestão da segurança Relatos de serviço
da informação
Orçamento e contabilização para serviços
Gerenciamento de continuidade
e disponibilidade de serviço
Processos de controle
Gerenciamento de configuração
Gerenciamento de mudanças
Gerenciamento de liberação e
implementação
Processos de Resolução Processos de relacionamento

Gerenciamento de incidentes e Gerenciamento de relações de negócio
requisições de serviço Gerenciamento de fornecedores
Gerenciamento de problemas
Figura 2 – Sistema de gestão de serviços
A Figura 2 mostra os processos das seções de 6 a 9 no retângulo central. A Seção 5, desenho

e transição de serviços novos ou modificados, envolve os processos das seções 6 a 9. Isto mostra que
os novos serviços ou modificados são operados pelos processos no retângulo central. Quando não
existem serviços novos ou modificados aos quais a seção 5 se aplica, todos os serviços podem ser
fornecidos diretamente pelas seções de 6 a 9.
As interfaces entre os processos de gerenciamento de serviços e as relações entre diferentes

componentes do SGS podem ser implementadas de forma diferente por diferentes provedores
de serviços. A natureza da relação entre o prestador e o cliente também pode influenciar a forma como
o SGS é implementado para cumprir os requisitos da ABNT NBR ISO/IEC 20000-1. Por estas razões,
as interfaces entre os processos não são representadas na Figura 2.
© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados 1

1.2 Aplicação
O provedor de serviços é responsável pelo SGS e, portanto, não está apto a pedir à outra parte para
cumprir os requisitos da Seção 4 da ABNT NBR ISO/IEC 20000-1. Por exemplo, o provedor de serviço
não está apto a pedir à outra parte para proporcionar a alta direção e demonstrar o comprometimento
de alta direção ou a demonstrar a governança de processos operados por outras partes.
Algumas atividades na Seção 4 podem ser realizadas por outra parte sob a gestão do provedor
de serviços. Por exemplo, provedores de serviço podem envolver outras partes para conduzir
auditorias internas em seu nome. Outro exemplo é quando um provedor de serviço pede à outra
parte para criar o plano inicial de gerenciamento do serviço. O plano, uma vez criado e acordado,
é de responsabilidade direta e mantido pelo provedor de serviços. Nestes exemplos, o provedor
de serviços está usando outras partes para atividades específicas de curto prazo. O provedor
de serviços tem a autoridade, responsabilidade e faz a prestação de contas com o SGS. O provedor
de serviços pode, portanto, demonstrar evidência de cumprimento de todos os requisitos da Seção 4
da ABNT NBR ISO/IEC 20000-1:2011.
O provedor de serviços pode mostrar evidências de cumprimento de todos os requisitos, ou pode

mostrar evidências de cumprimento de maior parte dos requisitos, diretamente, como também
a governança de processos operados por outras partes. Se o provedor de serviço se baseia
em outras partes para operação da maioria dos processos nas seções 5 a 9, é improvável que
o provedor de serviços seja capaz de demonstrar a governança dos processos. No entanto, se outras
partes operam apenas uma minoria dos processos, o provedor de serviços pode, normalmente,
cumprir os requisitos especificados na ABNT NBR ISO/IEC 20000-1.
A prestação de contas, as autoridades e as responsabilidades acordadas, definidas e documentadas,

pelo SGS são facilmente acessíveis, tanto para o provedor de serviços como para outras partes
pertinentes. Para cumprir os requisitos da ABNT NBR ISO/IEC 20000-1, o provedor de serviços pode
acordar mudanças dos termos dos contratos existentes ou outros acordos documentados.
A ABNT NBR ISO/IEC 20000 exclui a especificação de, ou orientação específica sobre,
qualquer produto ou ferramenta. No entanto, as organizações podem usar esta parte da
ABNT NBR ISO/IEC 20000 para ajudá-los a utilizar ou desenvolver produtos ou ferramentas que
suportem a operação do SGS
2 Referência normativa
O documento relacionado a seguir é indispensável para a aplicação deste documento. Para referências
datadas, somente a edição citada se aplica. Para referências não datadas, a última edição do referido
documento (incluindo emendas) se aplica.
ABNT NBR ISO/IEC 20000-1, Tecnologia da informação – Gerenciamento de serviço – Parte 1:

Requisitos do Sistema de Gestão de Serviços
3 Termos e definições
Para os fins deste documento, os termos e definições dados na ABNT NBR ISO/IEC 20000-1
se aplicam.
2 © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

4 Requisitos gerais do sistema de gestão de serviços

4.1 Responsabilidades da direção
4.1.1 Compromisso da direção
4.1.1.1 Responsabilidades da alta direção
Convém que a alta direção seja a gestão que direcione, monitore e controle o provedor de serviços
no mais alto nível.
Convém que a alta direção esteja ciente de que o cumprimento dos requisitos da
ABNT NBR ISO/IEC 20000-1 inclui:
a) demonstrar seu comprometimento de estar envolvida em todas as fases dos SGS, começando
com o planejamento e estabelecimento do SGS e continuando com a operação, monitoração,
medição, análise crítica, manutenção e melhoria contínua do SGS;
b) demonstrar sua prestação de contas e responsabilidades para o SGS;
c) assegurar que os requisitos de serviço, escopo do SGS, política e objetivos de gestão de serviços
sejam compreendidos e reconhecidos por todas as partes interessadas do SGS;
d) assegurar que o plano de gerenciamento de serviço seja criado, implementado, mantido e alinhado
com os objetivos de negócio;
e) garantir o fornecimento de recursos adequados para cumprir os objetivos de gerenciamento

de serviços e aderir à política de gerenciamento de serviços;
f) garantir que o desempenho do SGS seja relatado para o nível da alta direção;
g) alcançar os objetivos de gerenciamento de serviços, inclusive quando estes variam devido

às mudanças nas necessidades do negócio ou requisitos do serviço;
h) assegurar que os riscos para os serviços sejam minimizados, por exemplo, pela avaliação
dos riscos associados às mudanças e ações tomadas.
Convém que a alta direção também assegure que todas as fases do ciclo de vida do serviço sejam
fornecidas em níveis acordados, conforme definido nos requisitos de serviço. O ciclo de vida do serviço
inclui o planejamento, implementação, operação, monitoração, medição, análise crítica, manutenção
e melhoria contínua. O ciclo de vida do serviço também inclui a transferência do serviço para
um cliente, ou uma parte diferente, ou eventual remoção do serviço.
Convém que a alta direção esteja ciente de que eles são responsáveis por garantir que o SGS
e os serviços fornecidos pelo SGS sejam avaliados e analisados criticamente. Convém que
as avaliações incluam análises críticas do próprio provedor de serviço e auditorias internas, bem
como auditorias externas. Mais informações sobre análises críticas da direção podem ser encontradas
em 4.5 desta parte da ABNT NBR ISO/IEC 20000.
4.1.1.2 Evidência de comprometimento da alta direção
Sem o comprometimento da alta direção, é possível que possam ser tomadas decisões de gestão
que conflitem com os requisitos de um SGS eficaz. Exemplos incluem a realocação de recursos
para outros projetos, a falta de comunicação sobre o SGS e os conflitos não resolvidos no processo
de desenho.

Convém que haja evidência do comprometimento e prestação de contas da alta direção disponível
para análise por um avaliador. Convém que a alta direção seja capaz de fornecer evidências com base
em registros de seu envolvimento em:
a) reuniões regulares sobre o SGS, como, por exemplo, presidindo as reuniões de planejamento
para que o SGS continue alinhado com as necessidades de negócio e requisitos de serviços
novos ou modificados;
b) assegurar que o SGS inclui uma definição do escopo, a política de gerenciamento de serviços,
os objetivos de gerenciamento de serviços e o plano de gerenciamento de serviços;
c) aprovar a política de gerenciamento de serviços, os objetivos de gerenciamento de serviços

e o plano de gerenciamento de serviços;
d) aprovar os processos e procedimentos consistentes com, e que suportem, as políticas de SGS.
A aprovação da alta direção do plano de gerenciamento de serviços é importante porque o plano

pode ter implicações para compromissos com o cliente, planejamento de atividades para fornecedores
e alocação de recursos para melhorias e outras mudanças.
O alinhamento entre as políticas, processos e procedimentos permite que as diretrizes da alta direção
sejam disseminadas para todo o pessoal do provedor de serviços. Convém que as decisões da direção
sejam alinhadas com a maneira como o pessoal do provedor de serviços opera no dia a dia.
4.1.1.3 Comunicações da alta direção
Convém que a alta direção se envolva ativamente em um programa contínuo de comunicações.

Convém que as comunicações sejam conduzidas por procedimentos de comunicação aprovados,
conforme descrito em 4.1.3.2.
Convém que a alta direção se envolva ativamente em um programa contínuo de comunicação

para explicar como o SGS estabelecido está alinhado com os objetivos de negócio e expectativas
dos clientes. Isso é importante para o sucesso do SGS porque o pessoal que compreende a
finalidade e importância do SGS é menos propenso a resistir às mudanças, devido ao medo ou falta
de conhecimento. Comunicações da alta direção sobre o SGS podem ser uma oportunidade para
o provedor de serviços para motivar a sua própria organização. Além disso, a apreciação da importância
do SGS, tanto pela direção quanto pelo pessoal, poderia reduzir o risco ou a probabilidade de que
sejam tomadas decisões, ou soluções entregues, que contradizem O SGS.
Convém que o programa de comunicação explique o seguinte:
a) mudanças organizacionais, políticas, normas, visão e missão, bem como os objetivos de negócio;
b) necessidades do negócio, por exemplo, a relação entre o SGS e os serviços fornecidos e também
como estes suportam as metas e objetivos organizacionais definidos;
c) como o estabelecimento do SGS está alinhado com os objetivos de negócio e expectativas dos
clientes;
d) como a política de gerenciamento de serviço, os objetivos do gerenciamento de serviços

e o plano de gerenciamento de serviços suportam a realização dos requisitos de serviço;
e) os requisitos do cliente, por exemplo, metas de serviço, capacidade prevista com base na demanda
prevista, segurança da informação e continuidade de serviços para apoiar a continuidade
dos negócios;

f) os requisitos legais, como horas de trabalho, saúde e segurança e proteção de dados, que variam
em cada país;
g) os requisitos regulatórios, por exemplo, que os registros sejam mantidos por um período de tempo
específico;
h) requisitos contratuais, por exemplo, a exigência de assinar um acordo de não divulgação antes
de ter acesso à informação do provedor de serviços;
i) acordos documentados com o cliente;
j) análises regulares de dados recolhidos por meio da medição do SGS e componentes, por exemplo,
medições de processo.
Além disso, as comunicações podem ser uma oportunidade para o provedor de serviços motivar a sua
própria organização.
Um programa de comunicação é importante para o sucesso dos SGS porque o pessoal que compreende
a finalidade e importância do SGS é menos propenso a resistir às mudanças devido ao medo ou falta
de conhecimento.
Convém que as comunicações gerem uma apreciação da importância do SGS tanto pela direção
quanto pelo pessoal, reduzindo o risco ou a probabilidade de que decisões sejam tomadas ou soluções
fornecidas em contradição com o SGS.
Convém que o resultado dessas atividades de comunicação faça com que as pessoas compreendam
o seu papel no gerenciamento de serviços e como elas contribuem para o cumprimento dos requisitos
de serviço e cumprimento dos objetivos de gestão de serviços.
4.1.1.4 Objetivos do gerenciamento de serviços
Convém que a alta direção defina os objetivos acordados para o gerenciamento de serviços. Convém
que os objetivos estejam alinhados com os objetivos de negócio e com a política de gerenciamento
de serviços.
Por exemplo, objetivos genéricos de gerenciamento de serviços podem incluir o seguinte:
a) permitir o aumento da agilidade dos negócios por meio de uma entrega mais rápida de serviços
b) reduzir indisponibilidades não planejadas para serviços críticos de negócio;
c) otimizar o custo dos serviços fornecidos por meio da eficiência operacional;
d) aumentar a qualidade dos serviços, reduzindo os riscos.
Convém que os objetivos de gerenciamento de serviços reais sejam definidos de modo que
as realizações possam ser medidas contra os objetivos com precisão. Convém que a medição também
permita que as oportunidades de melhoria sejam priorizadas.
Convém que os objetivos sejam entradas-chave para o plano de gerenciamento de serviços. Convém
que o plano identifique as ações para a realização dos objetivos e alinhamento com os outros
componentes do SGS.

Convém que os objetivos de gerenciamento de serviços sejam analisados criticamente em intervalos

regulares, para possibilitar à alta direção decidir como e quando devem ser revisados.
Convém que o provedor de serviços assegure que a eficácia de cada componente do SGS seja
medida para avaliar a eficácia do apoio aos objetivos de gerenciamento de serviços. Por exemplo,
a medição da eficácia do suporte aos objetivos por um processo específico. Convém que as medições
também demonstrem o valor do SGS no apoio aos objetivos de negócio.
O provedor de serviços pode achar útil medir as contribuições individuais para a realização
dos objetivos. Isso irá facilitar ao pessoal que suporta o SGS trabalhar de forma integrada para
os mesmos objetivos.
4.1.1.5 Plano de gerenciamento de serviço
Convém que o plano de gerenciamento de serviços facilite a coordenação de todas as iniciativas

de SGS para assegurar a conquista dos objetivos de gerenciamento de serviços. Convém que o plano
e as políticas também estejam alinhados.
O plano pode ser um poderoso mecanismo para permitir visibilidade e controle do início ao fim. Convém
também evitar que iniciativas incompatíveis sejam aprovadas ou implementadas. Convém que o plano
permita que a utilização de recursos e capacidades seja a mais eficiente e eficaz possível.
Convém que o plano seja comunicado a todas as partes interessadas. Isso garantiria um entendimento
comum do escopo das iniciativas, as tarefas, prazos e responsabilidades atribuídas. Convém que
as responsabilidades atribuídas sejam incluídas nas medições de desempenho de todos os envolvidos
no SGS, incluindo aqueles envolvidos em iniciativas do plano de gerenciamento de serviços.
Convém que o plano não seja considerado concluído quando o SGS for implementado. Convém que
o plano exista de forma permanente e seja alterado para acomodar as necessidades de mudanças
de negócio, requisitos de clientes ou prioridades do provedor de serviços.
O plano de gerenciamento de serviços pode consistir em um único plano ou um programa de mudanças

coordenadas, gerenciadas centralmente, com algumas mudanças implementadas localmente.
Convém que o provedor de serviços esteja sempre ciente da necessidade de manter todas as mudanças
implementadas localmente, sob a gestão global do plano de gerenciamento de serviços. Por exemplo,
uma melhoria de um processo pode ser realizada localmente, sob o controle do responsável local pelo
processo, mas é incluída no programa de gestão centralizada global.
Planos para uma finalidade específica, por exemplo, para o processo de gerenciamento da continuidade
e disponibilidade do serviço, podem ser referenciados a partir do plano global de gerenciamento
de serviços em vez de nele incluído. Convém que os planos especializados e seu alinhamento com
o plano global sejam analisados criticamente a uma frequência que seja adequada à taxa de mudanças.
Convém que isso seja feito pelo menos anualmente.
Convém que quaisquer mudanças resultantes de análises críticas ou mudanças nos requisitos
do serviço ou planos individuais sejam documentadas no plano de gerenciamento de serviços global.
Por exemplo, mudanças no horário de expediente para 24 horas de operação, atualizações tecnológicas
ou mudanças de competências.
Convém que o conteúdo do plano de gerenciamento de serviços inclua:
a) uma introdução;

b) uma descrição das funções organizacionais do provedor de serviços;
c) prioridades das iniciativas;
d) resultados esperados alinhados aos objetivos de negócio;
e) medidas de desempenho;
f) metas de serviço;
g) planos de projeto;
h) tarefas e dependências;
i) realização de benefícios alcançados como resultado de melhorias implementadas anteriormente;
j) os prazos e as pessoas responsáveis pela execução das iniciativas do plano;
k) os riscos e opções de mitigação de riscos.
Convém que os riscos para o plano de gerenciamento de serviços sejam identificados, avaliados
gerenciados inicialmente e como parte da metodologia PDCA (Plan-Do-Check-Act). Convém que
a avaliação de riscos abranja as entradas, saídas, atividades, responsabilidades e prestação de
contas para a mitigação dos riscos. Convém também que o plano seja desenhado para assegurar que
os objetivos acordados e exigências de serviço sejam alcançados.
4.1.1.6 Recursos para apoiar o plano de gerenciamento de serviços
Convém que os recursos necessários para atingir os objetivos de gerenciamento de serviços sejam
documentados no plano de gerenciamento de serviços. Convém que o seguinte seja considerado:
a) a criação de recursos humanos, considerando as habilidades e experiência dos indivíduos, e não

se baseie exclusivamente no número de pessoas;
b) os recursos técnicos, por exemplo, infraestrutura e capacidade, de apoio aos processos da SGS;
c) as ferramentas de suporte aos processos do SGS;
d) a estrutura do escritório e de outras instalações e facilidades para a continuidade do serviço;
e) os dados e informações, por exemplo, detalhes dos requisitos de clientes, planos de negócio
do cliente, necessidades empresariais do provedor de serviços, políticas de gerenciamento
de serviços, medições de desempenho e outros relatórios;
f) os recursos financeiros, orçados em um nível de detalhe adequado para gerir o planejamento,

implementação, operação e melhoria da SGS;
g) a quantidade e disponibilidade do pessoal do provedor de serviços, e as suas horas trabalhadas;
h) os processos, procedimentos e prazos para o planejamento de retenção, introdução e sucessão

de pessoal devidamente qualificado.
4.1.1.7 Conteúdo dos requisitos de serviço
A seção 3.34 da ABNT NBR ISO/IEC 20000-1:2011 inclui as necessidades do negócio, o cliente
e os usuários do serviço e as necessidades do provedor de serviços na definição de requisitos

de serviço. Convém que a alta direção seja responsável por garantir que os serviços fornecidos
cumpram os requisitos de serviço acordados.
Convém que as exigências do cliente e as necessidades do negócio sejam documentadas, monitoradas

e analisadas para garantir o alinhamento permanente com serviços novos ou modificados, bem como
com os serviços no ambiente de produção.
Convém que os requisitos de serviço incluam as metas de serviço necessárias e expectativas

de qualidade. Convém que as necessidades do provedor de serviços incluam detalhes sobre os
requisitos de recursos e capacidade. Os requisitos de serviço são uma entrada para o SGS, mostrados
na Figura 2.
Exemplos de requisitos de serviço podem incluir:
a) um serviço em uso, incluindo os requisitos de nível de serviço;
b) os critérios de qualidade para a concepção de serviços novos ou modificados;
c) as prioridades para a importância do negócio de serviços;
d) os requisitos de disponibilidade;
e) os requisitos regulatórios;
f) os requisitos de segurança de informação.
4.1.1.8 O papel da alta direção em concordar e cumprir as exigências de serviços
À alta direção convém assegurar que os requisitos de serviço sejam definidos em termos de:
a) resultados desejados, esperados pelos clientes, por exemplo, eficácia, eficiência, satisfação;
b) as restrições que o serviço irá remover;
c) a funcionalidade de um serviço a partir da perspectiva do cliente, incluindo as necessidades

dos usuários do serviço, muitas vezes referidas como “adequadas ao seu propósito”;
d) padrões de atividade de negócio e a demanda que convém que o serviço suporte;
e) garantia de que o serviço e os produtos serão fornecidos ou que irão atender a determinadas
especificações acordadas, frequentemente referida como garantia.
Uma característica típica de garantia é que ela é definida em termos de continuidade, disponibilidade,
de capacidade e de segurança do serviço. Por exemplo, a garantia assegura que o serviço continuará
a ser adequado ao seu propósito, mesmo em níveis de serviço degradados devido a grandes rupturas
ou catástrofes. Convém que a garantia também assegure segurança para os serviços.
Convém que as necessidades dos usuários do serviço sejam definidas dentro do contexto das
necessidades do cliente. Convém que se descreva o benefício que um usuário vai ganhar com o uso
do serviço como parte do desempenho das suas atividades de trabalho.
Exemplos são dados abaixo.
Exemplo 1: Remover restrições. Mudança desejável para um serviço. Pode permitir que os usuários tenham
acesso ao serviço remotamente, em vez de apenas a partir de locais fixos.

Exemplo 2: Funcionalidade. A melhoria desejada, no tempo de processamento, para transações comerciais.
Exemplo 3: Desempenho. Um usuário pode precisar processar uma transação de compras por minuto
e 50 transações em uma hora.
4.1.1.9 Necessidade dos provedores de serviços

Convém, do ponto de vista do provedor de serviços, que os requisitos de serviço incluam os listados
abaixo:
a) Requisitos para garantir a entrega das necessidades do negócio e os interesses mais amplos
da organização que possui a organização de prestação de serviço. Por exemplo, os requisitos para
cumprir as políticas, normas, requisitos estatutários e regulatórios e as obrigações contratuais.
b) O escopo da SGS para dirigir, monitorar e controlar um conjunto integrado de processos

de gerenciamento de serviços e atividades. Isso inclui os requisitos para recursos, as capacidades
e os recursos necessários para o desenho, transição, entrega e melhoria dos serviços.
Por exemplo, as unidades organizacionais, pessoas, processos, informação e tecnologia
necessária para apoiar o SGS.
c) Limitações do SGS, por exemplo, limitações de recursos humanos, técnicos, de informação,

e financeiros.
d) Requisitos para a medição, auditoria, relatórios e melhoria dos serviços prestados contra
os objetivos de negócio definidos.
e) Requisitos para a medição, auditoria, relatórios e melhoria da eficácia das SGS.
4.1.1.10 Requisitos conflitantes
Se o provedor de serviços estabelece que ocorreu um conflito em requisitos, convém que uma ação
seja tomada. Exemplos de conflitos nos requisitos incluem o seguinte:
a) Se houver conflitos entre requisitos do cliente e necessidades de negócio dos clientes, convém
que o conflito seja resolvido pelo cliente, por exemplo, uma exigência do cliente que está
em conflito com a direção estratégica do negócio. Alternativamente, o provedor de serviços pode
analisar as diferenças e propor requisitos de serviço revistos.
b) Os conflitos entre os requisitos do cliente e as necessidades do provedor de serviços

de negócio próprio podem ocorrer quando as necessidades dos clientes são irrealistas em termos
de prioridades, custos ou fundos disponíveis. Convém que a natureza do conflito e o porquê
os requisitos não são realistas sejam claramente comunicados ao cliente.
c) Convém que os requisitos de manutenção em conflito com os requisitos legais ou regulatórios,

ou das obrigações contratuais, sejam resolvidos. Por exemplo, a distribuição de software pode
ser restringida por um contrato de licença de uma forma não compatível com as necessidades
do cliente para acesso a novas versões de software.
Convém que o provedor de serviços assegure que os riscos decorrentes de conflitos são avaliados
e quantificados de modo a identificar métodos de minimização de riscos. Convém que a avaliação
inclua o risco para a satisfação do cliente e a capacidade de atender às necessidades dos clientes
e objetivos.

Convém que conflitos e seu impacto potencial possam ser documentados e discutidos com o cliente
para que eles possam ser resolvidos. Convém que, se um conflito for identificado após o projeto
do serviço, seja acordado que o conflito venha a ser resolvido como uma ação corretiva ou como uma
oportunidade de melhoria.
4.1.1.11 Riscos para o serviço

Convém que a alta direção assegure que os riscos para o SGS e os serviços sejam identificados,
documentados e avaliados. Os riscos para um serviço podem incluir a incapacidade de cumprir
os requisitos regulatórios e estatutários ou obrigações contratuais. Por exemplo, a incapacidade
de atender às exigências de licença de software ou a falta de prova de idoneidade financeira.
Convém que a alta direção assegure que todos os riscos identificados sejam gerenciados, inclusive
assegurando que:
a) as opções sejam desenvolvidas e documentadas para gerenciar os riscos identificados;
b) opções preferenciais sejam acordadas com o cliente;
c) as opções de mitigação de riscos acordados são implementadas quando necessário.
NOTA O provedor de serviços vai achar úteis os requisitos e recomendações da ABNT NBR ISO 31000
para a gestão de riscos.
4.1.2 Política de gerenciamento de serviço
4.1.2.1 Diretrizes para a política de gestão de serviço
Convém que a política de gerenciamento de serviços seja específica para as circunstâncias

do provedor de serviços e tenha foco no cliente. Não convém que a política seja uma declaração
genérica, amplamente aplicável. Em vez disso, convém que a política reflita as circunstâncias
e os objetivos da provedora.
Convém que a política se baseie no escopo acordado do SGS e, portanto, dê apoio aos objetivos
do provedor de serviços de gerenciamento de serviços e ao plano de gerenciamento de serviços.
Convém que a política represente a alta direção e o compromisso de cumprir as exigências de serviço.
Convém também que a política assegure o cumprimento dos requisitos para a concepção e transição
do processo de serviços novos ou modificados da Seção 5 da ABNT NBR ISO/IEC 20000-1:2011.
Convém que a política dê uma orientação clara da alta direção para gestores de provedores de serviços
e colaboradores.
Exemplo 1: Serviços estão alinhados aos objetivos de negócio do cliente.
Exemplo 2: Mudanças nos processos ou procedimentos só são feitas mediante processo de gerenciamento
das mudanças.
Exemplo 3: Funções e responsabilidades para os processos de gerenciamento de serviços são definidos

e documentados de forma consistente e o desempenho do pessoal é medido com base na realização
dessas responsabilidades.
Convém que a política de gerenciamento de serviços seja estruturada de forma que possa ser
usada para avaliar se os objetivos do provedor de serviços de gerenciamento de serviços estão

sendo cumpridos. Convém, por exemplo, que seja possível demonstrar uma ligação entre a política
de gerenciamento de serviços e o que está sendo feito para alcançar os objetivos de serviço
do provedor. Convém que a política de gerenciamento de serviços seja estruturada para permitir
a medição da aderência à política.
Convém também que o provedor de serviços seja capaz de demonstrar que esta conexão entre
os objetivos do provedor de serviços e a política de gerenciamento de serviços tem sido eficaz desde
que a política de gerenciamento de serviço foi inicialmente acordada.
Convém que a política de gerenciamento de serviços defina claramente os níveis de autoridade,

por exemplo, tornando possível determinar se convém que uma iniciativa de melhoria seja aprovada
pelo responsável pelo processo individualmente ou pela alta direção.
Convém que a política de gerenciamento de serviço seja comunicada e compreendida dentro

da própria organização do provedor de serviços. A política de gerenciamento de serviço também pode
ser disponibilizada para clientes e fornecedores, conforme necessário. Referências à política, discutidas,
compreendidas e utilizadas de forma adequada podem ser usadas como prova de cumprimento desta
exigência. Por exemplo, atas de reunião, pesquisas de colaboradores, contratos de fornecedores,
acordos de subcontratados, solicitações de mudanças na política ou pedidos de esclarecimento
do impacto das políticas sobre os processos, procedimentos e comportamentos durante
as operações-padrão e sem planejamento, pesquisas com clientes, pesquisas de fornecedores.
Convém que a alta direção seja também responsável por assegurar que a política de gerenciamento
de serviços seja analisada criticamente em intervalos adequados, no mínimo, anualmente. Convém
que isso identifique eventuais deficiências, garantindo o alinhamento contínuo com as necessidades
do negócio e requisitos do cliente. Convém que os critérios de qualidade aplicados durante a revisão
da política de gerenciamento de serviços levem em consideração o seguinte:
a) a validade da política contra os requisitos do serviço;
b) a adequação da frequência de revisão;
c) o alinhamento entre a política e os objetivos de gerenciamento de serviços;
d) o alinhamento entre a política e o plano de gerenciamento de serviços;
e) o alinhamento entre a política e os processos de gerenciamento de serviços;
f) se a revisão está documentada, aprovada, rastreada, adequada, e se é viável;
g) a adequação do quadro para estabelecer, implementar, operar, monitorar, revisar, manter

e melhorar o SGS;
h) as ações de remediação e de melhoria identificadas em avaliações anteriores e auditorias

ao SGS.
4.1.2.2 Melhorias e outras mudanças na política
Após uma revisão da política de gerenciamento de serviço, se uma deficiência for encontrada, convém
que a alta direção assegure que ela seja corrigida. Convém que as deficiências sejam corrigidas,
como uma alteração na política, nos objetivos de gerenciamento de serviços, no plano, nos processos
ou nos procedimentos.

Convém também que a política seja atualizada para refletir quaisquer alterações nos objetivos
de gerenciamento de serviços ou no escopo do SGS.
4.1.3 Autoridade, responsabilidade e comunicação
4.1.3.1 Autoridade e responsabilidade

Convém que o provedor de serviços assegure que as autoridades e responsabilidades para todos
os aspectos do SGS sejam definidas. Convém que as descrições de cargo sejam acordadas, alocadas
aos indivíduos, comunicadas a todos os funcionários e mantida atualizada por meio de um procedimento
de gestão de documentos. Convém que o provedor de serviços assegure que todos os funcionários
são encorajados a se estabelecerem e se manterem conscientes de como suas atividades podem
contribuir para a realização dos objetivos de gerenciamento de serviços.
4.1.3.2 Procedimentos de comunicação
Convém que a alta direção seja responsável por garantir que os procedimentos de comunicação sejam
projetados, passem pela transição e sejam implementados e utilizados. A alta direção pode delegar
o projeto atual dos procedimentos. No entanto, convém aprová-los antes da aplicação e fazer cumprir
o seu uso. Convém que a alta direção esteja ativamente envolvida nos processos de comunicação.
Convém que a alta direção compreenda o valor da conscientização, motivação e participação do pessoal
na gestão eficaz de serviços e melhoria contínua. Convém que os procedimentos de comunicação
encorajem a motivação pessoal. Por exemplo, a comunicação de resultados positivos de participação
de funcionários em atividades de melhoria pode ter um efeito motivacional significativo.
Convém que os procedimentos de comunicação cubram no mínimo: o método de entrega, os horários

e/ou frequência e a audiência. Convém que os procedimentos cubram também os mecanismos
de escalação, detalhes dos contatos, manutenção da lista de distribuição, métodos de comunicação,
ferramentas e informação de acesso, horários e responsabilidades.
Convém que os procedimentos de comunicação incluam o seguinte.
a) o método de entrega;
b) a periodicidade e frequência;
c) o público-alvo para as comunicações;
d) mecanismos de escalação;
e) os detalhes de contato para o público-alvo de comunicações;
f) manutenção de lista de distribuição;
g) métodos de comunicação;
h) ferramentas e acesso à informação;
i) horários e responsabilidades.
A comunicação pode tomar formas diferentes e será dependente da cultura ou da organização,

do indivíduo com quem está sendo feita a comunicação e do papel desta pessoa na organização.

Métodos de comunicação da alta direção pode incluir material de orientação pessoal, palestras
e workshops, publicações internas com os funcionários, e-mail, mídia social ou fóruns de realimentação
de colaboradores.
4.1.4 Representante da direção

4.1.4.1 Compreensão das responsabilidades
Convém que o representante da direção seja um membro da equipe de gestão do provedor de serviços
que tem autoridade para garantir que o SGS seja estabelecido, utilizado, melhorado ao longo do tempo
e alinhado com as necessidades mutáveis do negócio. Convém que esta autoridade inclua a garantia
de que os processos de gerenciamento de serviços que têm interfaces adequadas entre si estejam
integrados com o resto dos SGS.
Convém que o provedor de serviços assegure que está claro quem é o representante da direção e que
os níveis de responsabilidade e autoridade dele sejam compreendidas pelos:
a) proprietários do processo, que têm a autoridade e responsabilidade de assegurar que o processo,

suas interfaces com outros processos e sua integração com o SGS estejam documentados,
em conformidade, medidos e melhorados;
b) proprietários de serviços, que têm a autoridade e a responsabilidade de um serviço durante todo

o seu ciclo de vida, incluindo o desenho, transição, implementação, a melhoria e retirada;
c) outros funcionários do provedor de serviços;
d) grupos internos;
e) fornecedores, incluindo fornecedores líderes;
f) o cliente.
NOTA Por exemplo, em interfaces entre os processos de gerenciamento de serviços e integração

com outros componentes do SGS, por favor, ver o Anexo A nesta parte da ABNT NBR ISO/IEC 20000.
4.1.4.2 Responsabilidades
Convém que o representante da direção seja responsável por garantir que sejam obtidos os itens
a seguir:
a) todos os aspectos das responsabilidades de gestão especificados na ABNT NBR ISO/IEC 20000-1
sejam realizados, incluindo as exigências da alta direção;
b) os requisitos de serviço sejam documentados;
c) o SGS e a definição de escopo atendam às próprias necessidades do provedor de serviços,

as necessidades do cliente e dos usuários dos serviços;
d) o escopo e os detalhes do SGS sejam verificados em intervalos adequados para assegurar que
os requisitos de serviço continuem a ser preenchidos, por exemplo, se as necessidades do cliente
mudam, é possível que o SGS ou o escopo da SGS também tenha que mudar;
e) a política de gerenciamento de serviço e os objetivos sejam usados como base para as decisões
durante o planejamento inicial dos processos, para o desenho dos processos e operação
e melhoria dos processos;

f) o desenho dos processos comece com a identificação das entradas e saídas e quaisquer
atividades realizadas como parte dos processos;
g) a política e os objetivos ditem os critérios para priorizar as melhorias de processos de gerenciamento

de serviços;
h) os processos de gerenciamento de serviços tenham interfaces adequadas e eficazes entre

si e estejam integrados com o resto do SGS;
i) a metodologia PDCA seja aplicada e utilizada para a melhoria contínua dos SGS e serviços;
j) auditorias internas e avaliações do SGS sejam realizadas em intervalos regulares, a fim

de medir a capacidade do SGS para alcançar os objetivos de gerenciamento de serviços e cumprir
as exigências do serviço.
4.1.4.3 Gerenciamento de ativos
Convém que a alta direção esteja ciente de que a ABNT NBR ISO/IEC 20000-1 requer que todos
os bens utilizados para entregar os serviços sejam geridos de acordo com requisitos legais, regulatórios
e financeiros e obrigações contratuais pertinentes. Convém que os ativos sejam geridos por meio
de procedimentos eficazes.
Exemplos de bens, que convém serem administrados, incluem licenças de software, dispositivos
móveis, componentes de infraestrutura, pessoas, contratos, procedimentos e outros documentos.
Convém que os provedores de serviços sejam capazes de identificar com precisão a localização,
situação e outros detalhes pertinentes aos ativos.
Convém que a alta direção esteja ciente de que a gestão de ativos requer um banco de dados
de configuração preciso (BDGC), ou meios equivalentes de manutenção de registros, a serem
estabelecidos e utilizados de forma eficaz. Convém que as informações no BDGC sejam mantidas
atualizadas por meio de processos eficazes de gerenciamento de serviços, como por exemplo,
alterações na BDGC aprovadas por meio do processo de gerenciamento de mudança.
Requisitos legais podem incluir as leis de privacidade e proteção de dados, bem como propriedade
intelectual e leis de direitos autorais. Outros requisitos legais podem se relacionar com a proteção
dos ativos de informações de clientes ou a proteção de informações financeiras.
Requisitos regulatórios e obrigações contratuais podem incluir a garantia de que ativos estejam
conforme com os requisitos comerciais de licença e as normas, por exemplo, padrões de segurança
para criptografia de informações sensíveis em laptops.
NOTA O provedor de serviços vai achar a série ISO/IEC 19770 para gerenciamento de ativos de
software útil.
4.1.4.4 Relato de um representante da direção
Convém que relatos para a alta direção incluam, mas não se limitem a os temas na Seção 4.1.4.2.
Convém, por exemplo, que os relatos identifiquem oportunidades de melhoria contínua obtidas
utilizando a metodologia PDCA. Convém que isto seja baseado em relatórios de desempenho dos
SGS e dos serviços.
Convém que a frequência e o nível de detalhe dos relatos sejam adequados para o nível de atividade,
categorias de mudanças e seriedade de todos os problemas e riscos identificados pelo representante

da administração. Convém que opções de mudanças sejam fornecidas para as correções

de deficiências, para ajudar na priorização das ações e decisões posteriores tomadas pela alta direção.
Convém que relatos para a alta direção articulem claramente o valor entregue pelo SGS em apoio aos
objetivos de negócio.
4.2 Governança de processos operados por outras partes
4.2.1 Guia para processos operados por outras partes
Convém que o provedor de serviços tenha ciência de que pode atender aos requisitos
da ABNT NBR ISO/IEC 20000-1 demonstrando governança de processos operados por outras
partes, para uma minoria dos processos.
Convém que o provedor de serviços seja capaz de identificar todos os processos de gerenciamento
de serviços ou partes de processos que são operados por outras partes. Convém que o provedor de
serviços tenha visibilidade, do princípio ao fim, do desempenho de outras partes operando qualquer
um dos processos das seções 5 a 9.
Convém que o provedor de serviços seja capaz de demonstrar o controle de todas as partes operando
processos do SGS e convém que isso seja suportado por todos os contratos e outros documentos
acordados.
4.2.2 Outras partes
Outras partes incluem:
a) grupos internos que são unidades organizacionais da mesma organização do provedor de serviço,
mas não diretamente controladas pelo provedor de serviço, como, por exemplo, um data center
ou uma equipe especializada em segurança;
b) um cliente atuando como fornecedor, como, por exemplo, um cliente que executa algumas
atividades do gerenciamento de incidentes e solicitações de serviço;
c) fornecedores, como, por exemplo, terceirização dos testes efetuados como parte do processo
de gerenciamento de liberação e implementação.
Fornecedores podem ser fornecedores líderes com responsabilidades por gerenciar fornecedores
subcontratados.
4.2.3 Demonstração da responsabilidade e autoridade
Convém que o provedor de serviços demonstre responsabilidade e autoridade nos processos,

fornecendo evidências, como as descritas abaixo.
a) O provedor de serviços é quem presta contas pela eficácia dos processos de gerenciamento
de serviço operados pelo provedor de serviços ou por outra parte, como, por exemplo, a matriz
de tomada de decisões, evidência dos níveis de autorização dentro da própria organização
do provedor de serviço.
b) Que o provedor de serviço tem o poder de exigir aderência a um processo. Por exemplo,
estabelecendo a política de segurança da informação, usando controles, detectando violações
e iniciando ações corretivas. Outro exemplo inclui o fornecimento de evidências de que práticas
foram modificadas a pedido do provedor de serviço.

c) Análise de registros do processo, incluindo medições pelo provedor de serviço. Por exemplo,
considerando um conjunto completo de registros de incidentes ou um relatório de incidentes
e tomando decisões baseadas no conteúdo, mesmo que os registros de incidentes sejam
fornecidos por outra parte que opere o processo de gerenciamento de incidentes.
d) Controlando a definição de todos os processos do SGS, incluindo quaisquer processos

das Seções 5 a 9 operados por outras partes. Isso inclui as interfaces entre cada processo.
Por exemplo, documentando, acordando e operando as interfaces e dependências do processo
de gerenciamento das mudanças com o processo de gerenciamento da configuração. Detalhe
adicional encontra-se na Seção 4.2.4.
e) Controlando o planejamento e definindo prioridades para melhorias em todos os processos

das Seções 4 a 9 da ABNT NBR ISO/IEC 20000-1:2011. Por exemplo, avaliando e priorizando
uma melhoria no processo de gerenciamento da capacidade, mesmo que o processo seja operado
por outra parte.
O provedor de serviços pode solicitar a outras partes para que operem processos desenhados
e documentados pelo provedor de serviço. Alternativamente, o provedor de serviços pode aprovar
os processos que outras partes desenhem, documentem e operem.
Convém que o provedor de serviços esteja ciente de que se ele confia em outras partes para
a operação da maioria de seus processos, é pouco provável que seja possível demonstrar governança
adequada dos processos.
NOTA A governança dos processos operados por outras partes está descrita na
ABNT ISO/IEC TR 20000-3:2009.
NOTA BRASILEIRA A ISO revisou o ISO/IEC TR 20000-3, e o publicou como Norma (ISO/IEC 20000-3),
em 2012, desta forma a ABNT está em processo de adoção da referida Norma.
4.2.4 Desempenho e conformidade de processos
Convém que o provedor do serviço assegure que cada processo descrito nas seções 5 a 9 entreguem
os resultados desejados e contribuam para atingir os objetivos do gerenciamento de serviços.
Convém que a governança dos processos operados por outras partes inclua uma definição
do processo, incluindo:
a) identificação do dono do processo, como, por exemplo, que grupo ou gerente da organização
do provedor de serviço é responsável pelo processo;
b) responsabilidade pela operação, como, por exemplo, que grupo ou gerente é responsável pela
operação;
c) o objetivo do processo, resultados do processo e a contribuição para os requisitos do serviço

e os objetivos do gerenciamento de serviço a serem atingidos;
d) entradas e saídas do processo e as partes que as geram;
e) definição das interfaces com outros processos, incluindo os processos de gerenciamento

de serviços, como por exemplo, dados transferidos entre processos ou a transferência
de atividades ou informações de uma parte para outra;

f) definição das interfaces entre processos e outros componentes do SGS, como, por exemplo, entre
os processos e as políticas e objetivos do gerenciamento de serviço;
g) a frequência e o método pelo qual a informação é transferida de cada processo e para cada
processo;
h) documentos e registros exigidos pelo provedor de serviço para governança dos processos
operados por outras partes e quem os gera;
i) prestação de contas e responsabilidades claras para todas as atividades necessárias.
Convém que a definição de interfaces entre os componentes do SGS inclua métodos pelos quais
os processos de gerenciamento de serviços são estabelecidos e continuamente melhorados para
suportar as políticas e objetivos do gerenciamento de serviços e as mudanças das necessidades
do negócio. Por exemplo, como convém que os componentes do SGS, incluindo processos, sejam
medidos em relação ao seu alinhamento e apoio à política de gerenciamento de serviços.
4.2.5 Determinar o desempenho e conformidade do processo
Convém que o provedor de serviços garanta que todos os processos sejam eficazes:
a) documentando e acordando com outras partes a frequência e o formato dos documentos

e registros a serem disponibilizados ao provedor de serviço e a outras partes;
b) estabelecendo o ciclo de análise crítica e o critério para as avaliações de processo;
c) conduzindo uma avaliação de processo em relação aos requisitos da

ABNT NBR ISO/IEC 20000-1;
d) definindo as obrigações das outras partes nas atividades de análise crítica de processo;
e) analisando o desempenho de processos;
f) analisando as interfaces entre processos ou parte de processos operados por outras partes
e outros processos, assim como as políticas e planos;
g) analisando o alinhamento entre processos ou partes de processos operados por outras partes
e os objetivos do gerenciamento de serviços;
h) estabelecendo prioridades e planejando atividades para melhorias ou correções para

otimizar processos.
4.2.6 Controle do planejamento e priorização de melhorias do processo
Convém que o provedor de serviços seja capaz de demonstrar que controla a prioridade dada
à melhoria de processos, incluindo aqueles operados por outras partes.
Exemplo 1 Uma proposta de melhoria para o processo de gerenciamento de mudanças pode ser
considerada como tendo maior benefício para a organização do que uma proposta de melhoria no processo
de liberação e implementação. Convém que a priorização das melhorias de processo seja alinhada com os
objetivos de negócio e com os requisitos de serviço.
Exemplo 2 Convém que uma melhoria no processo de gerenciamento de incidentes operado por outra
parte seja dirigida pelos objetivos de negócio e requisitos de serviço do provedor de serviço e de sua
organização.

4.3 Gerenciamento de documentação
4.3.1 Estabelecer e manter documentos
4.3.1.1 Documentos como evidências

Convém que o provedor de serviços assegure que a evidência esteja disponível para qualquer auditoria
do SGS. Convém que a maior parte das evidências esteja na forma de documentos. Os documentos
podem ser de qualquer tipo, formato ou meio adequados para a sua finalidade, por exemplo, em papel,
arquivos eletrônicos, em um banco de dados ou processador de texto.
Os seguintes documentos podem ser considerados como evidência para uma auditoria do SGS:
a) políticas, objetivos e planos para o gerenciamento de serviços;
b) documentos de processo e procedimentos;
c) catálogo de serviços;
d) documentos do serviço, incluindo desenho, especificação de requisitos, ANS, critérios de aceitação

e análises críticas de serviços;
e) documentos contratuais, incluindo a especificação de requisitos e controle de mudanças;
f) atividades de planejamento de auditoria e relatórios;
g) documentos que descrevem ou que estejam associados a uma mudança em particular, como
as atividades de planejamento de mudanças;
Convém que o provedor de serviços esteja ciente de que alguns documentos, como políticas,
são requeridos pela ABNT NBR ISO/IEC 20000-1 para cumprir os requisitos de processos
específicos. Uma organização pode utilizar documentos adicionais, incluindo políticas, para proporcionar
maior clareza ou assegurar o funcionamento efetivo ou a melhoria do SGS e da entrega de serviços.
Registros são um tipo especial de documento e convém que estejam disponíveis como evidência.
4.3.1.2 Produção de documentos, incluindo registros
Convém que o provedor de serviços compreenda que um procedimento eficaz é essencial para
a produção de documentos, incluindo registros. Isso inclui a utilização de um sistema de numeração
e de nomenclatura que se alinhe com o objetivo e a revisão do histórico dos documentos. O uso
de modelos e formatos padronizados pode reduzir o esforço de criação, acesso, atualização e utilização
do conteúdo.
Convém que haja evidência de um procedimento de aceitação de documentos, em conformidade com

os papéis e responsabilidades por documentos, definidos no SGS.
Convém que o provedor de serviços também compreenda que os documentos, como ANS, políticas
e planos podem ser interdependentes, por exemplo, uma política de segurança da informação
definindo qual informação pode ser armazenada em equipamentos móveis, ou um servidor que suporta
a entrega de um serviço de correio eletrônico. Convém que estas interdependências sejam entendidas
e gerenciadas quando mudanças forem realizadas nos documentos.

Registros que mostram o que, de fato, foi realizado ou o que ocorreu, nem sempre requerem
um procedimento de aceitação, como, por exemplo, um registro de incidente. Convém que um registro
de incidente seja atualizado à medida que o incidente progrida até o seu encerramento. Seguir
um procedimento de aceitação a cada vez que um registro de incidente é atualizado poderia causar
atrasos inaceitáveis na resolução de incidentes.
NOTA Documentos e registros não precisam ser únicos para o SGS. Uma vez que atendam aos
requisitos da ABNT NBR ISO/IEC 20000-1, eles podem, também, abranger os requisitos de normas como
a ABNT NBR ISO 9001 ou ABNT NBR ISO/IEC 27001.
4.3.2 Controle de documentos
Convém que o controle de documentos seja reconhecido como essencial. Convém que o controle
de documentos inclua análise crítica periódica com atualização ou arquivamento, se necessários.
Convém que a análise crítica ocorra no mínimo anualmente. Convém que documentos sejam protegidos
contra danos, como, por exemplo, aqueles causados por condições ambientais inadequadas e mau
funcionamento de hardware.
Controle pode prover visibilidade dos impactos de mudanças, como, por exemplo, uma alteração
em um ANS que impacta contratos com outras partes ou os requisitos de disponibilidade. Convém que
o provedor de serviço assegure que os documentos são controlados pela utilização de:
a) denominação da versão e numeração;
b) designação da responsabilidade pela criação, edição, revisão, aprovação, atualização, remoção

e arquivamento de documentos;
c) registros de mudança que indicam a data, autor, aprovação da mudança e natureza das revisões;
d) avaliação de alterações dos documentos identificados pelo processo de gerenciamento

da mudança, antes da aprovação;
e) identificação dos relacionamentos entre documentos específicos e outros componentes do SGS;
f) mecanismos de controle de acesso a documentos e distribuição;
g) um procedimento para aprovar documentos para uso;
h) um procedimento para revisão e atualização, quando necessárias, e reaprovação de documentos;
i) um procedimento para assegurar que documentos de origem externa definidos pelo provedor
de serviço e considerados necessários para o planejamento e a operação do SGS sejam
identificados e sua distribuição controlada;
j) um procedimento para assegurar que documentos sejam descartados de acordo com a política
de segurança da informação e com requisitos legais e regulatórios;
k) um procedimento para arquivamento de documentos que perderam a validade.
Para realizar o controle de documentos, técnicas de gestão de documentos, gestão do conhecimento,

gestão de mudanças e gerenciamento de configuração podem ser usadas, como, por exemplo, uma
política sobre como as versões de documentos são exibidas.
Convém que o provedor de serviços identifique os documentos que estão sujeitos aos procedimentos de
controle de documentos. Isso pode incluir documentos de origem externa, como normas, regulamentos

ou documentos de clientes. Convém que o provedor do serviço distinga entre os diferentes tipos
de controle a serem aplicados a diferentes tipos de itens como, por exemplo, entre aqueles de origem
interna e externa ou de documentos que requerem níveis de segurança diferenciados devido à natureza
de seu conteúdo.
Convém que os documentos controlados incluam todos os listados na Seção 4.3.1.1. Muitos documentos
são classificados como IC, que, consequentemente, também são controlados pelo processo
de gerenciamento da configuração. Nos casos em que o controle de documentos é realizado
por meios eletrônicos, convém que atenção especial seja dada para assegurar a aprovação adequada,
acesso, distribuição, mídia e procedimentos de arquivamento.
NOTA 1 O provedor de serviços vai considerar úteis as Seções 4.2.3 e 4.2.4 da

ABNT NBR ISO 9001:2008.
NOTA 2 Para maiores informações, ver a Seção 5.10 da ISO/IEC TR 20000-4:2010, processo
de gerenciamento de item de informação.
4.3.3 Controle de registros
Convém que registros associados ao SGS sejam alinhados aos requisitos da

ABNT NBR ISO/IEC 20000-1, requisitos legais e regulatórios e a obrigações contratuais. Por exemplo,
retenção de registros, práticas de arquivamento e de descarte. Convém que registros retidos incluam
o registro de revisões em documentos e o acompanhamento dos comentários das revisões para
resolução. Convém que estes requisitos e obrigações influenciem o desenho do SGS.
Convém que quaisquer conflitos entre requisitos legais e regulatórios ou obrigações contratuais
e os requisitos da ABNT NBR ISO/IEC 20000-1 sejam resolvidos. Isto se aplica a todos os registros
que são criados e usados como parte do SGS e inclui, mas não se limita a, documentação, logs
e registros de bancos de dados, registros de erros conhecidos, IC, registros de incidentes e registros
de requisição de mudança.
Convém que registros definidos para comprovar evidências da conformidade com requisitos
e a efetividade da operação do SGS sejam controlados. Convém que a organização estabeleça
um procedimento documentado para definir os controles necessários para identificação,
armazenamento, proteção, recuperação, retenção e descarte dos registros. Convém que os registros
permaneçam legíveis, prontamente identificáveis e recuperáveis.
NOTA Maiores informações sobre gerenciamento de registros podem ser encontradas na ISO/IEC 15489-1.
4.4 Gerenciamento de recursos

4.4.1 Disponibilização de recursos
4.4.1.1 Recursos para implementar o SGS
Convém que o provedor de serviços disponibilize todos os recursos acordados no plano para
estabelecer, implementar, manter e melhorar o SGS e os serviços acordados. Os recursos incluem
pelo menos os seguintes:
a) recursos humanos, como, por exemplo, pessoas para desenhar, implementar e operar o SGS, alta
direção e pessoas envolvidas no gerenciamento do SGS e serviços;
b) recursos técnicos, como, por exemplo, capacidade de infraestrutura suficiente para atender aos
requisitos de serviço, ferramentas para suportar os processos do SGS, instalações e ambientes
de escritório e instalações para assegurar a continuidade dos serviços;

c) informação, como, por exemplo, detalhes dos requisitos dos clientes, planos e necessidades
do negócio, políticas de gerenciamento de serviços, medições e demais relatórios;
d) recursos financeiros, incluindo tanto os fundos para projetos como aqueles para manter o SGS
em operação.
4.4.1.2 Aprovação dos recursos
Convém que existam procedimentos para aprovar o uso dos recursos acordados, como pessoas,
infraestrutura, ferramentas e fundos. Isso inclui:
a) fundos a serem acordados e orçados antes da implementação do plano de gerenciamento

de serviço;
b) alocação de pessoas requeridas para o projeto de implementação do plano de gerenciamento

de serviço, para as melhorias contínuas de longo prazo e para a operação dos processos no dia
a dia;
c) identificação e desenvolvimento de habilidades de recrutamento aprovado e/ou para treinamento

das pessoas existentes;
d) identificação, concordância e aprovação dos novos papéis e tecnologias;
e) a infraestrutura requerida que pode incluir instalações de escritório e data centers,

telecomunicações, como pontos de acesso para redes locais (LAN) e redes de longa distância
(WAN), servidores, armazenamento, refrigeração e distribuição de energia;
f) ferramentas para gerenciamento de serviços que podem incluir ferramentas para monitoramento
ou medição e geração de relatórios de serviço ou suporte a processos específicos.
EXEMPLO Procedimentos para obtenção de recursos podem ser suportados por ferramentas para
modelagem de capacidade ou por informações extraídas de um BDGC. Embora as ferramentas não
sejam um requisito para a ABNT NBR ISO/IEC 20000-1, elas podem tornar os processos mais eficazes
e eficientes. As ferramentas podem auxiliar, fornecendo evidências da conformidade com os requisitos
da ABNT NBR ISO/IEC 20000-1.
4.4.2 Recursos humanos
4.4.2.1 Geral
Convém que o compromisso do provedor de serviços em disponibilizar os recursos inclua a definição

das contribuições individuais e as de cada papel para o SGS e o serviço. Convém que o provedor
de serviços também defina e acorde os níveis de autoridade e de responsabilidade para cada tipo
de papel. Isso inclui a competência, educação, treinamento, habilidades e experiência requerida para
cada papel. Convém que o provedor de serviços defina, acorde e comunique esta informação em sua
organização. Convém que, sempre que considerado relevante, o provedor de serviços comunique esta
informação também a outras partes.
Convém que o provedor de serviços compreenda os riscos decorrentes da incerteza sobre quais
papéis e, portanto, quais indivíduos têm determinados níveis e tipos de autoridade, responsabilidade
e de prestação de contas. Quando os níveis de autoridade, de prestação de contas e de responsabilidade
para cada papel forem definidos, convém que estas informações façam parte integrante do SGS.
O provedor de serviços pode achar útil adotar uma matriz de responsabilidade, como, por exemplo,

uma matriz RACI, para documentar autoridade, prestação de contas e responsabilidade. Uma vez
que essa informação venha a ser um componente do SGS, convém que ela seja incluída nas análises
críticas periódicas do SMS.
Convém que os recursos incluam a alta direção, que possui a responsabilidade geral e presta contas
pelo SGS e serviços fornecidos pelo SGS. Convém que o requisito de recursos seja definido de forma
contínua após o projeto de implementação do SGS.
Convém que as autoridades e responsabilidades para cada processo de gerenciamento de serviço

no SGS incluam:
a) um dono do processo, responsável pelo(a):
1) desenho do processo;
2) garantia de aderência ao processo;
3) medição e melhoria do processo;
b) um gerente do processo, responsável pela operação do processo e pela gestão dos recursos
dos processos de gerenciamento de serviços;
c) pessoal que executa os procedimentos do processo.
Outros papéis que são específicos a um determinado processo de gerenciamento de serviços estão
descritos nas Seções 5 e 9 desta parte da ABNT NBR ISO/IEC 20000.
NOTA É uma prática aceitável para um indivíduo ter mais de um papel de gerente de serviços,
particularmente em organizações menores.
4.4.2.2 Competência, habilidades, treinamento e experiência
Convém que a competência requerida para um papel seja baseada na análise de características
específicas e dos requisitos para aquele papel. Convém que isso inclua, mas não se limite a: instrução,
treinamento, habilidades e experiência.
Convém que a competência requerida para cada papel relevante para o cumprimento da Seção 4.4.2
da ABNT NBR ISO/IEC 20000-1:2011 seja identificada. Convém que o nível e o tipo de responsabilidade
e autoridade de um papel também sejam considerados. Isso inclui os papéis da alta direção.
Convém que o provedor de serviços também leve em consideração a carga de trabalho envolvida
em cada papel e como ela muda ao longo do tempo. Convém que a atribuição de papéis
e responsabilidades para os indivíduos leve em conta os aspectos do papel na ocasião da sua alocação.
Convém que o provedor de serviços aloque papéis a indivíduos que atendam ao critério de capacitação
para que aquele papel seja executado com sucesso.
Convém que a decisão sobre a aptidão de um indivíduo para um papel seja baseada na comparação
entre a competência real e a competência requerida para aquele papel. Onde houver disparidade
entre os requisitos acordados para a competência e as competências do indivíduo a ser considerado
para, ou já no papel, convém que o provedor de serviço assegure que a disparidade seja corrigida.

Disparidades podem ser corrigidas por meio de vários métodos como, por exemplo, proporcionando
ao indivíduo a instrução e o treinamento necessários para corrigir a disparidade. Alternativamente,
o provedor de serviços pode permitir que as habilidades, ou a experiência, que faltam possam
ser transferidas por uma pessoa que trabalha com outra e que possua as habilidades corretas
e a experiência necessária. Depois que essa ação corretiva tenha sido tomada, convém que o provedor
de serviços reavalie a competência do indivíduo ou indivíduos para checar se as ações tomadas
corrigiram a disparidade.
Convém que provedores de serviços alinhem os indicadores-chave de desempenho (KPI) e/ou
as áreas-chave de pessoal para realizar os objetivos do gerenciamento de serviços. Ao fazer isso,
o pessoal não só terá ciência de suas obrigações como terá um melhor entendimento de como pode
contribuir para os resultados de serviço desejados.
Convém que o provedor de serviços estabeleça e mantenha registros atualizados de competência,
incluindo instrução, treinamento, habilidades e experiência. Convém que o provedor de serviços
assegure que seu pessoal está consciente de como contribuir para a realização dos objetivos
relacionados ao gerenciamento de serviços.
Convém que haja um procedimento documentado para assegurar que os registros de pessoal são
mantidos atualizados.
4.5 Estabelecimento e melhoria do SGS

4.5.1 Definição do escopo
Convém que o provedor de serviços estabeleça se a ABNT NBR ISO/IEC 20000-1 é aplicável às suas
circunstâncias na fase inicial do estágio de planejamento. De forma similar, convém que o provedor
de serviços esteja ciente de que negligenciar quaisquer destas atividades pode levar a falha
ou ineficiência do SGS em cumprir os requisitos da ABNT NBR ISO/IEC 20000-1.
Para que o SGS seja efetivo, convém que o provedor de serviços melhore continuamente o SGS
e os serviços utilizando a metodologia do PDCA. Convém que o escopo do SGS seja compreendido
antes de melhorar o SGS.
Ao definir o escopo do SGS, convém que sejam considerados os parâmetros a seguir:
a) unidades organizacionais provedoras de serviços, como, por exemplo, um único departamento,
grupo de departamentos ou todos os departamentos;
b) serviços oferecidos, como, por exemplo, um único serviço, um grupo, ou todos os serviços,
serviços financeiros, serviços de varejo, serviços de correio eletrônico;
c) localização geográfica a partir da qual o provedor de serviços entrega os serviços, como,
por exemplo, um único escritório, um grupo de escritórios, regional, nacional ou global;
d) tecnologia utilizada para prover os serviços.
Não convém que a declaração de escopo inclua os nomes de outras partes que contribuem para
entrega dos serviços.
Convém que o provedor de serviços leve em conta as orientações do ABNT ISO/IEC TR 20000-3
ao planejar como atender aos requisitos da ABNT NBR ISO/IEC 20000-1, nas circustâncias
do provedor de serviços.

4.5.2 Planejar o SGS (Planejar)
4.5.2.1 Aspectos importantes do planejamento
Convém que o planejamento para o SGS cubra todos os aspectos do gerenciamento e da entrega
de serviços e inclua, mas não se limite a, os aspectos relacionados a seguir:
a) Os objetivos do gerenciamento de serviços. Convém que os objetivos priorizados pelo provedor

de serviços, na implementação das mudanças e melhorias, não sejam ambíguos.
b) O plano de gerenciamento de serviços. Convém que, quando possível, o plano seja subdivido
em estágios, com benefícios identificados para cada estágio.
c) A política de gerenciamento de serviços do provedor de serviços. Por exemplo, políticas

relacionadas a todos os subplanos, como políticas de gerenciamento de mudanças, políticas
de segurança da informação, políticas de continuidade de serviço. A definição das políticas
no estágio inicial do planejamento do SGS habilita a verificação do escopo do SGS e torna possível
identificar considerações importantes.
d) Convém que requisitos de serviço, políticas, normas e indicadores-chave de desempenho

de negócio sejam compatíveis com os requisitos do serviço e convém que atendam aos requisitos
dos clientes e às necessidades do negócio. Por exemplo, não convém que requisitos de serviço
ocasionem não conformidades à política de segurança da informação, o que colocaria o negócio
em risco.
e) Limitações conhecidas que podem impactar o SGS. Por exemplo, o pessoal do provedor de serviços
com habilidades insuficientes em implementar e gerenciar o SGS. Convém que o plano identifique
as ações apropriadas, como o fornecimento de treinamento e conscientização, contratação
de pessoal novo com as habilidades e experiências relevantes e o uso da expertise de outras
partes para orientação de pessoal.
4.5.2.2 Alinhamento do planejamento e acordos
Convém que o plano de gerenciamento de serviços inclua o acordo e a documentação dos requisitos
de serviço. Convém que as metas de serviço sejam documentadas, tanto no plano como nos acordos
entre o provedor de serviços e grupos relevantes. Convém que os acordos levem em consideração os
aspectos relacionados a seguir:
a) Cliente, como, por exemplo, ANS, e requisitos de serviços novos ou modificados. Convém que
isso seja considerado mesmo que um acordo documentado com um cliente não seja juridicamente
válido.
b) Grupos internos, como, por exemplo, acordos de nível operacional com um grupo responsável
pelas instalações físicas, grupo de desenvolvimento de sistemas, grupo de recursos humanos ou
grupo financeiro. Não é permitido que isso seja um contrato juridicamente válido porque o provedor
de serviços e os grupos internos são parte da mesma entidade legal. No entanto, os grupos
internos podem não fazer parte da mesma estrutura de gestão (ou unidade, ou departamento)
do provedor de serviços. Grupos internos podem ser um aspecto importante para definição do
escopo do SGS, tendo em vista que eles podem contribuir com uma parte significativa do serviço
global.
c) Fornecedores e fornecedores líderes, como, por exemplo, subcontratos de serviços ou de recursos.

d) Outras normas, requisitos regulatórios ou legais, como, por exemplo, os específicos de segmentos
industriais, como médico, automotivo, telecomunicações ou conformidade com as leis para
licenciamento de software de cada país.
4.5.2.3 Papéis, autoridades e responsabilidades do gerenciamento

Convém que os papéis, autoridades e responsabilidades do gerenciamento que se encontram

no escopo do SGS sejam documentados, tanto no plano de gerenciamento de serviços como
na documentação dos processos e nos acordos relevantes, incluindo:
a) todos os papéis para os quais a gerência, individual ou coletivamente, presta contas ou é

responsável;
b) representante da direção, incluindo quaisquer limites na autoridade deste papel e o relacionamento

com a alta direção que esta pessoa representa;
c) donos de serviço ou de processo.
Convém que as autoridades e responsabilidades para os papéis no SGS sejam checadas para
garantir que não há conflitos de interesse, como, por exemplo, o mesmo papel, propondo e também
aprovando uma mudança. Convém que a definição da estrutura de autoridades, responsabilidades
e papéis em processo no plano inclua os detalhes de qual papel presta contas e é responsável
por todos os componentes do SGS.
4.5.2.4 Interfaces de processo
Convém que a informação das interfaces entre processos inclua o tipo, método e frequência
de informações passadas de um processo a outro processo. Convém que o provedor de serviços
esteja ciente de que isso é uma parte importante da definição do processo e garante que o processo
e o SGS irão operar com eficiência e eficácia.
A Seção 5 da ABNT NBR ISO/IEC 20000-1:2011 inclui requisitos para interfaces entre os processos
das Seções 6 a 9 e o desenho e a transição de serviços novos ou modificados.
Requisitos para serviços novos ou modificados incluem o estágio do projeto em que os requisitos
do serviço são definidos e quando o serviço é desenhado e passa pela transição. Convém que
o provedor de serviços esteja ciente de que uma gestão efetiva do projeto é importante para gerenciar
certas interfaces. Convém que a interface entre o SGS e quaisquer projetos seja definida, acordada
e registrada no plano.
Convém que os componentes integrados do SGS, incluindo processos, políticas, objetivos e planos,
sejam medidos para que a eficiência do SGS e os serviços possam ser identificados, gerenciados
e melhorados.
De modo a facilitar a integração e a interoperabilidade entre o cliente e o provedor de serviços,

o provedor de serviços pode estabelecer descrições de processos padronizadas. Descrições
de processo definem a finalidade, propósito, resultados, atividades, políticas, papéis e responsabilidades,
itens de informação e interfaces para cada processo de gerenciamento de serviços do SGS. Cada
processo pode requerer, também, procedimentos, documentos ou instruções de trabalho, para definir
como realizar as atividades.
Convém que o prestador de serviços esteja ciente de que a gestão global e coordenação do SGS é
particularmente importante quando se está sendo melhorado ou alterado por qualquer outra razão.

Convém que as mudanças nos processos que fazem parte do SGS só sejam realizadas depois
do impacto nos outros processos ou na capacidade de entrega de serviços pela organização.
EXEMPLO Mudanças em parâmetros ou metas utilizados nos processos de gerenciamento de incidentes

e solicitações de serviço podem ter um efeito não intencional e prejudicial em outros processos, como
os processos de gerenciamento de nível de serviço, relatos de serviço e gerenciamento da segurança
da informação.
Compreender as interdependências entre processos e entre todos os componentes do SGS pode

reduzir riscos e habilitar o gerenciamento efetivo do SGS. Exemplos de interfaces entre os processos
de gerenciamento de serviços e a integração com o SGS podem ser encontrados como Anexo A desta
parte da ABNT NBR ISO/IEC 20000.
4.5.3 Implementar e operar o SGS (Fazer)
Convém que o provedor de serviços implemente e opere o SGS em alinhamento com o plano
de gerenciamento de serviços e como meio de alcançar os objetivos do gerenciamento de serviços.
Convém que o provedor de serviços esteja ciente dos benefícios em assegurar que as autoridades
e responsabilidades, tanto do provedor de serviços como do cliente, estão documentadas e acordadas
para as atividades que impactam ambas as partes.
Convém que o provedor de serviços esteja ciente de que a pessoa aproriada para o planejamento
e implementação inicial nem sempre é a adequada para a operação do SGS. São requeridas diferentes
habilidades para o planejamento, implementação e operação.
4.5.4 Monitorar e analisar criticamente o SGS (Checar)
4.5.4.1 Geral
Convém que o provedor de serviços monitore, meça e analise criticamente os objetivos do gerenciamento
de serviços e planeje as atividades necessárias para assegurar que eles estão sendo alcançados.
Convém que a alta direção esteja ciente dos resultados das análises críticas. Se mudanças no plano
e nos objetivos do gerenciamento de serviços forem consideradas necessárias, convém que estas
mudanças sejam aprovadas de acordo com o processo de gerenciamento de mudanças.
Convém que, de acordo com a metodologia PDCA, o provedor de serviços, periodicamente, identifique,
colete, analise e reporte informações sobre os processos e serviços entregues. Convém que estas
atividades suportem o gerenciamento efetivo do SGS e dos serviços e convém que viabilizem
a capacidade de demonstrar, objetivamente, a qualidade e o valor do serviços entregues.
NOTA Consultar a ISO/IEC 15939 para demais informações sobre medição, a ABNT NBR ISO/IEC
15504 sobre avaliação de processo e avaliação de desempenho, ISO/IEC 14598 para avaliação de produto
e ISO/IEC 9126 Partes 2 e 3, para exemplos de métricas em produtos de software.
4.5.4.2 Auditoria interna
Convém que o provedor de serviços assegure que auditorias internas são executadas de acordo
com procedimentos documentados que incluem autoridades e responsabilidades para as auditorias.
Convém que os responsáveis pela realização de auditorias internas tenham o conhecimento adequado
e independente das áreas que estão sendo auditadas. Por exemplo, convém que eles não auditem
o seu próprio trabalho. Eles podem incluir um gerente de projeto, o patrocinador, o comitê diretivo,
outras partes interessadas e os auditores independentes.

Convém que haja um programa interno de auditoria identificando quando cada serviço e quais
seções da ABNT NBR ISO/IEC 20000-1 devem ser auditados. Convém que haja uma justificativa para
as decisões de planejamento, incluindo porque serviços ou seções da ABNT NBR ISO/IEC 20000-1
são incluídos ou excluídos em cada auditoria interna. Convém que fatores a serem levados em conta
incluam o grau de risco envolvido em um processo, sua frequência de operação e seu histórico.
Convém que as auditorias internas ocorram em intervalos planejados e não somente executadas
quando há riscos conhecidos ou outros problemas. Convém que o internvalo definido leve em conta
a taxa da mudança de:
a) SGS e dos serviços;
b) requisitos do cliente e organização do cliente;
c) organização e pessoal do provedor de serviços;
d) mudanças relevantes nas ferramentas de gerenciamento do serviço, quando há utilização de

ferramentas.
Convém que a gerência assegure que as auditorias sejam concluídas conforme o plano, a não ser que
sejam remarcadas por razões documentadas.
Convém que as auditorias internas do SGS incluam uma avaliação do escopo do SGS e que o SGS
ainda seja efetivo para a entrega dos serviços acordados com o cliente. Convém que isto inclua
a verificação de que a política de gerenciamento de serviço ainda fornece a orientação correta
de gestão e que os objetivos são alcançados dentro dos prazos separados. Convém que a auditoria
interna analise os planos e relatórios em relação ao desempenho do SGS.
Convém que, usando um calendário compatível com a frequência das auditorias, os auditores
internos forneçam detalhes sobre as não conformidades. Convém que o provedor de serviços utilize
os resultados da auditoria interna para identificar e priorizar ações.
Convém que todos os resultados de auditorias anteriores sejam levados em consideração.

Por exemplo, onde uma preocupação foi identificada, convém que os planos incluam a garantia
de que a causa desta preocupação seja auditada novamente na próxima auditoria interna. Convém
que a auditoria interna cheque que quaisquer ações corretivas ou preventivas identificadas tenham
sido implementadas nos prazos acordados. Convém que a auditoria interna verifique, também,
se as ações acordadas resultaram nas melhorias previstas.
Convém que não conformidades sejam analisadas para determinar qualquer causa-raiz. Convém que
as ações resultantes das auditorias incluam ações preventivas em relação a quaisquer causas-raiz
identificadas. Convém que as ações tenham proprietários e prazos claros e acordados para ajudar
a garantir que elas sejam concluídas de forma efetiva e no prazo. Convém que o acompanhamento
das atividades das não conformidades identificadas incluam a verificação de ações que foram tomadas.
Convém que os resultantes das ações tomadas sejam reportados à alta direção.
4.5.4.3 Análise crítica pela direção
Convém que o SGS seja analisado criticamente a intervalos planejados, para verificar se o SGS
continua a permitir o cumprimento de novas necessidades de negócio e requisitos de serviço. Convém
que isso seja feito pelo menos anualmente. No entanto, alguns provedores de serviços operam em
ambientes que se encontram em rápida mutação e convém que avaliem o SGS com maior frequencia.
Convém que a análise crítica inclua o escopo vigente em relação ao escopo definido do SGS
e a adequação dos planos atuais comparados às necessidades atuais do cliente do negócio.

Especificamente, a análise crítica pode ser efetuada em relação a:
a) desempenho do SGS em relação a políticas, planos e objetivos;
b) medição dos indicadores-chave de desempenho de processo (KPI);

c) resultados das auditorias internas e externas;
d) avaliação das atividades de melhoria contínua alinhada com os objetivos de negócio;
e) avaliação pós-implementação das mudanças;
f) melhores práticas da indústria;
g) resultados das pesquisas de satisfação com os clientes;
h) resultados desejados pelo negócio.
NOTA Consultar a ABNT NBR ISO/IEC 15504, Partes 2 e 3, para requisitos e guias para avaliação
de processos.
4.5.5 Manter e melhorar o SGS (Agir)
4.5.5.1 Geral
Convém que a abordagem estrtégica para a melhoria dos serviços seja feita estabelecendo-se uma
política de melhoria contínua do SGS e dos serviços. Convém que a política inclua uma definição dos
critérios de avaliação acordados para aceitar e priorizar oportunidades de melhoria.
Convém que todos os serviços entregues ao cliente, os processos de gerenciamento de serviços

e o SGS em sua totalidade sejam submetidos à melhoria contínua. Para facilitar sua obtenção
de modo mais rápido, o provedor de serviços pode achar útil realizar atividades de melhoria contínua
no processo de documentação do gerenciamento de serviços. O provedor de serviços pode achar
útil, também, alinhar a medição dos componentes do SGS e as metas de desempenho de pessoal
em relação à realização das melhorias contínuas.
Convém que toda não conformidade identificada por meio das avaliações, auditorias e outros meios seja
direcionada e que medidas sejam tomadas para eliminar as causas de ambas as não conformidades
identificadas e potenciais.
4.5.5.2 Gerenciamento de melhorias
Melhoria contínua é um dos conceitos centrais da ABNT NBR ISO/IEC 20000. Convém que
um procedimento documentado identificando as autoridades e responsabilidades para todas as
atividades de melhoria seja usado. Convém que este procedimento assegure que oportunidades para
melhoria sejam identificadas, avaliadas, aprovadas, gerenciadas e medidas efetivamente.
Convém que entradas para gerenciar a melhoria contínua incluam:
a) diretrizes relevantes da alta direção;
b) causas-raiz identificadas como resultados de auditorias e análises, tanto do SGS como de serviços
individuais;

c) sugestões do cliente, de outras partes e da organização do provedor de serviços;
d) registros de problemas;
e) teste dos planos, como, por exemplo, testes de continuidade;
f) entrega de requisitos de valor/serviço, como, por exemplo, priorização de atividades de melhoria

com base na criticidade dos serviços para o negócio;
g) utilização de recursos otimizados ou redução de risco, como, por exemplo, oportunidades para
aumento na eficiência ou melhoria na automação.
NOTA 1 Maiores orientações podem ser encontradas no ISO/IEC TR 20000-4.
NOTA 2 Um modelo de processo e método de avaliação de engenharia de sistemas e desenvolvimento

de software está na ABNT NBR ISO/IEC 15504, Partes 5 e 6.
5 Desenho e transição de um serviço novo ou modificado

5.1 Geral
5.1.1 Intenção dos requisitos
Convém que o processo de desenho e transição de um serviço novo ou modificado estabeleça

e implemente planos para controlar a entrega destes serviços. Convém que o processo seja aplicado
em serviços novos ou modificados que representem alto risco ou alto impacto potencial aos serviços
já prestados aos clientes.
5.1.2 Conceitos
Convém que este processo forneça mecanismos para o gerenciamento do desenho e transição
de serviços novos ou modificados. O processo opera em sincronia com o processo de gerenciamento
de mudanças. Convém que IC desenvolvidos ou modificados pelo processo sejam controlados pelo
processo de gerenciamento de configuração por meio do processo de gerenciamento de mudanças.
Convém que o serviço novo ou modificado seja implantado pelo processo de liberação e implementação.
Convém que requisitos dos serviços novos ou modificados sejam identificados pelos clientes ou partes
interessadas no serviço, de forma a atender a uma necessidade de negócio ou obter uma melhoria
na forma como o serviço é entregue ao cliente. Convém que o provedor de serviço decida quando
usar este processo, seguindo as políticas de gerenciamento de mudanças onde os critérios de uso
do processo estão especificados. Cada provedor de serviço pode ter políticas distintas e uso
de diferentes critérios para determinar a quais mudanças a Seção 5 pode ser aplicada. Convém que
a remoção, transferências e introdução de serviços novos ou mudanças que apresentem um alto
potencial de causar impacto significativo sejam gerenciados pelos processos de desenho e transição
de serviços novos ou modificados. Convém que o provedor de serviços entenda os riscos associados
a cada proposta de serviço novo ou modificado. Convém que riscos levem em consideração
as circunstâncias levantadas pelo provedor de serviços e o cliente, incluindo as atividades de negócio
do cliente. Convém que ações sejam tomadas de forma a minimizar riscos associados a serviços
novos ou modificados.
5.1.3 Explicação sobre os requisitos
O processo de desenho e transição de serviços novos ou modificados se destina a mudanças que

requeiram níveis adicionais de visibilidade e controle onde se faz necessário a gestão de riscos

e impactos elevados. Os três processos de controle, gerenciamento de configuração, gerenciamento

de mudanças e gerenciamento de liberação e implementação são a essência do gerenciamento
de todas as mudanças do SGS e dos serviços. Entretanto, um projeto complexo com interfaces para
o SGS e tarefas ou entregáveis que estão fora do escopo do SGS podem, constantemente, requerer
uma camada adicional de controle do desenho e da transição de serviços novos ou modificados.
Para cada provedor de serviços, os critérios usados para determinar que tipos de mudança são
suscetíveis a serem gerenciadas por meio do desenho e da transição de serviços novos ou modificados
são, provavelmente, distintos. Por exemplo, o critério pode incluir uma mudança em um serviço que
impacte mais de um número específico de usuários ou localidades. Outro exemplo pode incluir qualquer
mudança que possa colocar o provedor de serviços em risco de ser penalizado pela legislação
de proteção aos dados.
Convém que os processos de desenho e transição de serviços novos ou modificados definam

e gerenciem as interfaces relevantes com os processos de controle na Seção 9. Convém que
os processos de desenho e transição de serviços novos ou modificados operem em conjunto com
os processos de controle da Seção 9 para assegurar um gerenciamento de risco otimizado e a entrega
de uma solução que atenda a todos os requisitos de negócio. Convém que os IC afetados pelo serviço
novo ou modificado sejam controlados pelo processo de gerenciamento de configuração. Convém que
a avaliação, aprovação, agendamento e a análise crítica dos serviços novos ou modificados sejam
controlados pelo processo de gerenciamento de mudanças. Convém que todos os serviços novos
ou modificados sejam introduzidos no ambiente de produção por meio do processo de liberação
e implementação.
5.2 Planejar serviços novos ou modificados
5.2.1 A necessidade de serviços novos ou modificados
A necessidade de serviços novos ou a mudança em um serviço pode ser originada pelo cliente,
o provedor de serviços, grupos internos ou fornecedores. O propósito de um serviço novo ou modificado
pode ser o de satisfazer necessidades de negócio e requisitos de clientes ou melhorar a efetividade
de um serviço.
5.2.2 Mudanças com impacto significativo a um serviço ou cliente
Convém que este processo seja aplicado àquelas mudanças que tenham potencial de causar impacto
significativo em serviços e, consequentemente, no cliente. Tais mudanças em serviços demandam
atividades adicionais providas pela aplicação da Seção 5, para reduzir o risco associado à mudança.
Uma mudança em que o impacto em serviços ou no cliente seja suficientemente baixo pode ser
gerenciada apenas por meio dos processos de controle. Convém que a maioria das mudanças
coordenadas pelos provedores de serviços se encaixe nesta última categoria.
5.2.3 Política em mudanças com impacto significativo
Convém que as mudanças que estejam no escopo da Seção 5 sejam identificadas usando a política
de gerenciamento de mudanças desenvolvida como parte do processo de gerenciamento
de mudanças. Convém que a política inclua critérios para identificação de mudanças de alto risco que
tenham o potencial de causar impacto significativo nos serviços ou no cliente. Convém que a política
seja baseada nas necessidades específicas do provedor de serviços e em uma avaliação dos riscos
em seus serviços. Convém que tais políticas levem em consideração que a proposição para um serviço
novo ou modificado possa ter sido originada a partir de diversas fontes e por uma variedade de razões.

Convém que a política seja documentada e acordada pela alta direção e os donos do processo mais
diretamente envolvidos no processo de serviços novos ou modificados.
Convém que o critério na política de gerenciamento de mudanças sempre inclua tanto a remoção
de um serviço existente quanto a transferência de um serviço a ser provido por outra parte. Para cada
provedor de serviços, outros critérios podem ser provavelmente diferentes.
Mudanças com impacto significativo podem incluir:
a) uma mudança em um serviço que impacte mais de um número específico de usuários

ou localidades;
b) uma mudança que possa colocar o provedor de serviços em risco de ser penalizado pela legislação
de proteção de dados;
c) um novo serviço ou um novo cliente para um serviço existente;
d) uma diferença significativa em como convém que o serviço seja provido ou entregue, por exemplo,
localização, plataforma de hardware;
e) introdução de um novo sistema operacional, sistema, ou aplicação de software ou uma atualização

significativa em um software existente.
Convém que o provedor de serviços leve em consideração, também, mudanças que possam ser
requeridas pelo SGS, incluindo mudanças no escopo do SGS como resultado de serviços novos
ou modificados. Por exemplo, identificação de riscos associados a metas de serviços acordadas com
clientes, mudanças em procedimentos de gerenciamento de fornecedores ou acordos documentados
com outras partes que tenham um impacto nos serviços existentes ou planejados.
5.2.4 Gerenciando mudança como um projeto
Convém que quaisquer serviços novos ou modificados em que se aplica a Seção 5 sejam gerenciados
como um projeto devido ao tamanho, riscos e escopo das mudanças. Convém que o provedor
de serviços considere os potenciais impactos financeiros, organizacionais e técnicos do serviço novo
ou modificado mais o impacto potencial no SGS.
Convém que o provedor de serviços garanta uma forte coordenação entre o processo de gerenciamento
de mudanças e os papéis e autoridades do gerenciamento de projeto, se possível desde as primeiras
fases do projeto.
Convém que o provedor de serviços garanta que os projetos levem em consideração:
a) o impacto nas combinações de suporte existentes, por exemplo, procedimentos operacionais

dos provedores de serviços;
b) o impacto em níveis de serviço existentes e a habilidade do provedor de serviços em gerenciar

o impacto;
c) acordos de suporte com fornecedores, contratos e acordos documentados com outras partes que
possam ser afetadas pelas mudanças ou inclusões em serviço;
d) requisitos do cliente do serviço existente, incluindo resultados como os relatórios que podem
ser afetados pelas mudanças ou inclusões ao serviço;
e) ferramentas de implementação e métodos.

5.2.5 Contribuições de outras partes
Outra parte pode prover componentes de serviço para serviços novos ou modificados. Um serviço
novo ou modificado pode envolver a aquisição de software, infraestrutura, habilidades especializadas
ou outros componentes de serviços.
Quando outra parte é envolvida em um serviço novo ou modificado, convém que o provedor de serviços
execute uma revisão completa. Convém que a revisão avalie a capacidade de outra parte em cumprir
com seus compromissos, incluindo os requisitos de serviço acordados. Convém que a revisão avalie
também o risco aos serviços existentes e o ambiente de suporte.
De forma a aceitar a introdução de um serviço no ambiente de produção, pode ser necessário

especificar requisitos, como o número de pessoal de suporte, tecnologia, testes e documentação.
5.2.6 Análise de risco
Convém que o provedor de serviços esteja ciente da importância de avaliar riscos, questões e
esforços de mitigação no estágio inicial do processo e, então, em cada um dos estágios do processo,
do planejamento à aceitação no ambiente de produção.
Convém que os resultados das avaliações de risco sejam usados para desenvolver critérios
de aceitação durante a fase de planejamento.
5.2.7 Critério para aceitação de serviços
Convém que os critérios para aceitação de serviços contidos no plano incluam:
a) requisitos do provedor de serviços a serem cumpridos para que o provedor de serviços aceite
os serviços novos ou modificados resultantes do projeto;
b) uma lista de verificação para passagem de serviços novos ou modificados, por exemplo,
transferência de conhecimento, documentação, capacidade, disponibilidade, continuidade
e segurança requeridos ao suporte do serviço novo ou modificado;
c) os requisitos do cliente, como programações de comunicação, treinamentos de conscientização

e documentação.
Convém que um serviço novo ou modificado seja rejeitado onde riscos a um serviço, SGS
ou às atividades de negócio do cliente sejam inaceitáveis ou não possam ser mitigados.
5.2.8 Remoção de serviço
Se houver um serviço a ser removido, convém que isso seja planejado e documentado em um plano
de remoção de serviço. Convém que o plano inclua:
a) as condições em que a remoção se aplica;
b) os objetivos e os fatores de sucesso da remoção;
c) governança de processos operados por outras partes;
d) papéis e responsabilidades para todas as partes interessadas, por exemplo, clientes, fornecedores,
grupos internos;

e) restrições, riscos e questões;
f) marcos e entregáveis;
g) detalhamento das atividades e descrição de cada atividade;

h) critérios acordados para conclusão da remoção e o fim da responsabilidade do provedor

de serviços;
i) a data de quando o serviço não estará mais disponível aos usuários e a data de remoção
do serviço;
j) como as interfaces entre o serviço a ser removido e os demais serviços prestados serão tratadas
pelos outros serviços;
k) uma análise crítica das disposições de segurança da informação, incluindo a remoção

de informações confidenciais.
Convém que o provedor de serviços garanta que os detalhes marcantes de incidentes, problemas,
solicitações de usuários e solicitações de mudanças tenham sido negociados com os clientes. Convém
que este acordo com o cliente inclua todas as ações resultantes.
Convém que a propriedade de todos os dados, documentação e componentes de sistemas seja

acordada. Convém que, se necessário, acordos quanto ao acesso a dados ou outros componentes
de serviço sejam acordados, planejados e implementados. Convém que acordos para arquivamento,
descarte ou transferência também sejam acordados.
Convém que quaisquer modificações dos documentos exigidos como resultado da remoção de
serviço também sejam identificadas e essas modificações realizadas pelo processo de gerenciamento
de mudanças.
Convém que os objetivos do gerenciamento de serviços, atividades e resultados da remoção

de um serviço sejam documentados em um acordo por escrito com o cliente. Convém que este
acordo inclua a data de término do serviço e mudanças de papéis e responsabilidades. Convém que
o acordo também inclua como o provedor de serviços irá gerenciar os dados dos usuários, informações
específicas de clientes, documentação do serviço e a infraestrutura, aplicativos e licenças afetados.
O acordo escrito pode ser denominado de critério acordado para aceite de remoção de serviço.
Quando da transferência total ou parcial de um serviço à outra parte, convém que o objetivo seja
a continuidade dos serviços ao usuário sem interrupção desnecessária. Convém que o provedor
de serviços trabalhe com o cliente e a outra parte para identificar previamente quaisquer riscos que
a transferência ofereça a continuidade ou qualidade do serviço. Convém que o provedor de serviços
emita uma lista de atividades com os passos requeridos, seguida por uma avaliação documentada
do resultado.
5.3 Desenho e desenvolvimento de serviços novos ou modificados
5.3.1 Atividades executadas pelo provedor de serviços, cliente e outras partes
Convém que o provedor de serviços seja envolvido desde o início no projeto que irá entregar
serviços novos ou modificados. O envolvimento desde o início pode evitar decisões de desenho que
resultem em serviços que apresentem funções e funcionalidades que não sejam apropriadas quando
entrarem em operação. Convém que o envolvimento, desde o início, do provedor de serviços garanta

que os requisitos acordados com o cliente incluam critérios de qualidade para os serviços novos
ou modificados, incluindo, pelo menos:
a) níveis de serviço, resposta e outros aspectos de desempenho;
b) confiabilidade e resiliência do serviço;

c) controles de segurança;
d) adequações requeridas para a continuidade do serviço;
e) critérios de custo-benefício para mudanças ou para uma nova versão a ser liberada e implantada;
f) facilidade de uso.
5.3.2 Gerenciamento de risco
Convém que, durante a fase de desenho, o provedor de serviços considere os resultados da avaliação
de risco inicial, feita durante a fase de planejamento. Convém que o desenho seja influenciado pelos
riscos identificados naquela análise. Convém que, durante a fase de desenho, o provedor de serviços
considere quais dos riscos identificados serão aceitáveis quando o serviço novo ou modificado
for transferido para o ambiente de produção. Convém que isto leve em consideração o impacto potencial
de um risco em particular, incluindo:
a) o serviço que está sendo desenhado;
b) o impacto potencial do risco nos demais serviços do provedor de serviços;
c) os clientes que dependem dos serviços novos ou modificados.
Quando uma não conformidade potencial na qualidade acordada e nos requisitos funcionais do serviço
é identificada, convém que o provedor de serviços mitigue o risco. Por exemplo, pela modificação
no desenho ou garantindo que os riscos são compreendidos e aceitos por todas as partes interessadas.
Convém que a aceitação do serviço no ambiente de produção seja baseada no entendimento

do impacto potencial de um serviço que não atinja os critérios de aceitação. Convém que isto inclua
o entendimento do impacto nos demais serviços. Convém que as diretrizes de análise de risco
e de gerenciamento de risco apresentadas nas seções 5.2.6 e 5.3.2 influenciem o desenvolvimento
do critério de aceitação. Convém que se considere o seguinte:
Exemplo 1 Corrija agora: um atraso na transição para o ambiente operacional para permitir correções
nas deficiências.
Exemplo 2: Corrija depois: aceitação com ressalvas de forma que as correções das deficiências sejam
executadas posteriormente em prazo acordado.
Exemplo 3: Não corrija: aceitação em conjunto com mudanças em outros serviços para acomodar
as deficiências do serviço novo ou modificado.
Exemplo 4: Não é possível ser corrigido: aceitação, mediante acordo, de que as deficiências não precisam
ser corrigidas ou não é possível que sejam corrigidas.
NOTA Consultar a ABNT NBR ISO 31000 para mais informações sobre gerenciamento de risco.

5.3.3 Atividades do Desenho de Serviço
5.3.3.1 Planejando o desenho
Convém que o desenho de um serviço novo ou modificado também seja planejado, levando
em consideração o seguinte:
a) foco no cumprimento das necessidades de negócio e requisitos do cliente acordados, que convém
que estejam documentados como parte dos requisitos constantes no escopo do projeto;
b) convém que seja vinculado ao processo de gerenciamento de mudanças para garantir que
os planos sejam comunicados e aprovados pelas partes interessadas e que quaisquer impactos
em IC sejam compreendidos e aceitos;
c) garantir que os IC para os serviços novos ou modificados sejam planejados e controlados;
d) garantir que os prazos para o projeto sejam levados em consideração pela programação
de mudanças;
e) levar em consideração o custo de entrega e gerenciamento contínuo do serviço, por exemplo,

convém que o desenho de serviço resulte em um suporte efetivo sem recursos em excesso
ou exageros técnicos;
f) levar em consideração os impactos organizacionais, técnicos e comerciais de se entregar serviços

g) garantir que o desenho de serviço faça o melhor uso da organização e das tecnologias existentes
e cause a mínima interrupção nas disposições comerciais existentes;
h) ser executado de forma que o desenho habilite os níveis de serviços acordados para o serviço
novo ou modificado, de forma que possa ser gerenciado pela organização do provedor de serviços;
i) analisar a adequação do serviço novo ou modificado aos processos existentes em uso pela
organização do provedor de serviços para o gerenciamento, medição e relato de níveis de serviço.
Convém que o plano do provedor de serviços para um serviço novo ou modificado inclua
as dependências, tempos e limitações de recursos que possam afetar alguma das atividades
requeridas. Quando o provedor de serviços depende de atividades a serem executadas por partes
externas, convém que o plano observe estas dependências. Atividades que possam ser executadas
como dependentes incluem testes e validação. Convém que os planos também forneçam contingências
nos casos em que os prazos não são cumpridos.
Convém que o provedor de serviços garanta que os recursos humanos, técnicos, de informação,
financeiros e as competências de gerenciamento de serviços requeridas para conduzir todas
as atividades previstas estejam identificados e possam ser fornecidos. Quando estes recursos
e competências não existirem na organização do provedor de serviços, convém que se entenda quais
passos são necessários para provê-los, incluindo os tempos de processamento para sua entrega.
Convém que o escopo do planejamento inclua o desenho inicial e as atividades de desenvolvimento
e transição para entrega do serviço novo ou modificado.
5.3.3.2 Desenho e desenvolvimento de serviços
Convém que o desenho de serviços seja documentado e acordado anteriormente ao seu

desenvolvimento. Convém que o desenho leve em consideração os requisitos dos serviços atuais,

considerações sobre segurança da informação, resiliência do serviço e projeções de capacidade

dos recursos para o crescimento durante a vida esperada para o serviço.
Convém que o desenho e o desenvolvimento de serviços novos ou modificados adotem métodos

e técnicas de gerenciamento de projetos. Convém que haja rastreabilidade entre os requisitos,
o desenho e os testes para serviços novos ou modificados.
Convém que o desenho do serviço seja acordado entre todas as partes afetadas ou interessadas antes
do início do desenvolvimento. Convém que tais partes incluam aquelas responsáveis pelo provimento
dos serviços existentes que possam ser impactados, e aquelas responsáveis por prover quaisquer
dos recursos requeridos.
Durante o andamento do projeto, se quaisquer mudanças forem acordadas, convém que o desenho
seja atualizado e aprovado. Anteriormente à entrada em operação, convém que o serviço seja testado
em relação a cada requisito da especificação, e os resultados registrados.
Convém que o desenho e o desenvolvimento incluam os seguintes itens, conforme o caso:
a) as atividades de desenho e implementação, transição, operação e manutenção para a aceitação

dos serviços, incluindo a identificação de, ou referência para:
1) desenvolvimento de atividades a serem executadas;
2) entradas requeridas para cada atividade;
3) saídas requeridas de cada atividade;
4) atividades de gerenciamento e suporte a serem executadas;
5) treinamento necessário para a equipe;
6) planejamento para o controle do produto e provisionamento do serviço;
b) a organização dos recursos do projeto, incluindo a estrutura da equipe, responsabilidades,

utilização de fornecedores e recursos a serem empregados;
c) interfaces técnicas e organizacionais entre os diferentes indivíduos ou grupos, como subequipes

de projeto, fornecedores, parceiros, usuários, representantes do cliente e representantes
da garantia da qualidade;
d) a análise dos possíveis riscos, suposições, dependências e desafios associados ao desenho

e desenvolvimento;
e) a programação, identificando:
1) estágios da mudança e as atividades a serem executadas;
2) recursos e prazos associados;
3) dependências associadas;
4) metas do cronograma;
5) atividades de verificação e validação;

f) identificação de padrões, regras, práticas e convenções, metodologias, modelo de ciclo de vida,

requisitos estatutários e regulatórios, obrigações contratuais e outras restrições;
g) ferramentas e técnicas para o desenvolvimento do serviço;
h) instalações como hardware e software usados para apoiar o desenvolvimento do serviço;

i) práticas de gerenciamento de configuração;
j) método de controle de não conformidades de produtos de hardware e software;
k) métodos de controle para software e hardware usados para apoiar o desenvolvimento do serviço;
l) procedimentos para arquivamento, backup, recuperação e controle de acesso a produtos

de software e métodos de controle para proteção contra vírus.
Se o provedor de serviços não conseguir controlar o desenho e o desenvolvimento do serviço

ou do componente de serviço, convém que o provedor de serviços conduza uma análise para garantir
que as expectativas sejam alcançadas. Por exemplo, convém que as características funcionais
e não funcionais de um produto comercial de prateleira sejam avaliadas em relação aos requisitos
e expectativas. Convém que qualquer instalação ou customização do produto seja planejada
e desenhada.
Um documento usado para o planejamento do desenho e do desenvolvimento pode ser um único

documento, uma parte de outro documento, ou composto de vários documentos.
Convém que o planejamento seja revisado periodicamente e quaisquer planos alterados, se for o caso.
5.4 Transição de um serviço novo ou modificado
Convém que a transição de um serviço novo ou modificado seja coordenada com o processo
de gerenciamento de mudanças, o processo de gerenciamento de liberações e implementação
e o processo de gerenciamento de configuração. Convém que, adotando esta abordagem, assegure-se
que o controle de mudanças se aplica à transição dos serviços novos ou modificados.
Convém que a transição de serviços inclua a construção, teste e aceitação de serviços novos
ou modificados, e que, em seguida, os serviços novos ou modificados operacionais sejam feitos
por meio do processo de liberação e implementação.
Convém que a transição seja revisada com o cliente e as partes interessadas para verificar se está
pronta para a operação. Convém que a decisão resultante seja registrada, em conjunto com a aceitação
do cliente para os serviços novos ou modificados para a operação em produção. Convém que
a transição continue até que toda e qualquer atividade remanescente faça parte da operação normal.
Convém que, seguindo a finalização da transição, o provedor de serviços reporte às partes interessadas
os resultados atingidos pelos serviços novos ou modificados frente aos resultados planejados.
Convém que os critérios de aceitação sejam revistos pelo provedor de serviços e pelas outras
partes interessadas. Onde houver um critério de aceitação importante e que não foi cumprido antes
da transição do serviço, convém que seja decidido se a ausência deste critério representa um risco
significativo para o serviço. Onde o risco for significativo, convém que a transição seja postergada.
Entretanto, onde houver mitigação do risco ou o risco não seja significativo, convém que seja decidida
a continuação da transição. Nesta instância, convém que a ação resultante e seus proprietários sejam
registrados na declaração do critério e convém que sejam dados passos para assegurar que estas
ações sejam cumpridas.

Convém que o provedor de serviços registre a aceitação pelo cliente e pela parte interessada
do serviço novo ou modificado frente ao critério de aceitação combinado.
5.5 Documentos e registros

Recomenda-se que os documentos e registros, que convém serem produzidos e retidos pelo desenho
e transição de serviços novos ou modificados, incluam:
a) os requisitos do serviço para os serviços novos ou modificados;
b) avaliação de riscos para cada pedido de um serviço novo ou modificado;
c) plano para o desenho, desenvolvimento e transição para um serviço novo ou modificado;
d) plano para qualquer serviço que será removido;
e) um relatório de avaliação das outras partes que contribuem para os serviços novos ou modificados;
f) especificações de desenho para serviços novos ou modificados;
g) critérios de aceitação de serviços;
h) relatórios de transição descrevendo objetivos atingidos em relação aos objetivos esperados.
É crítico que o processo tenha acesso à política de serviços novos ou modificados no escopo
da Seção 5, desenvolvida e mantida como parte do processo de gerenciamento de mudanças.
5.6 Autoridades e responsabilidades

Adicionalmente ao dono do processo, o gerente do processo e o pessoal que executa os procedimentos
do processo descrito na Seção 4.4.2.1, autoridades e responsabilidades requeridos no desenho
e na transição de serviços novos ou modificados, convém que se inclua:
a) um gerente de serviços novos ou modificados, usualmente um gerente de projetos, responsável

por entregar e gerenciar as entregas e garantir o atendimento dos critérios de aceitação;
b) um grupo que possa avaliar o impacto da proposta para os serviços novos ou modificados
no sistema de gerenciamento de serviços sob múltiplas perspectivas, incluindo políticas, objetivos
e processos;
c) um grupo, podendo ser o mesmo do item anterior, que possa ser envolvido no planejamento dos
requisitos para todos os serviços novos ou modificados e a aceitação da entrega dos serviços
d) clientes e representantes do negócio responsáveis pela documentação e acordos de todos

os requisitos e aceitação dos serviços novos ou modificados.
6 Processos de entrega de serviço

6.1 Gerenciamento de nível de serviço
Convém que o processo de GNS assegure que o serviço acordado seja fornecido e que as metas
de serviço sejam atendidas. Convém que metas específicas e mensuráveis sejam desenvolvidas para
todos os serviços. O processo de GNS garante que os serviços acordados e as metas de serviço
sejam documentados de forma que possam ser facilmente compreendidos pelo cliente.

6.1.2 Conceitos
Convém que o processo de GNS defina, acorde, documente, monitore, reporte e analise criticamente
os serviços entregues. A fim de garantir que a entrega dos serviços seja alcançável, gerenciada
e alinhada com os requisitos do cliente e as necessidades do negócio, o processo de GNS opera
em estreita colaboração com o processo (GRN) – “Gerenciamento de relacionamento com o negócio”
e o processo de gestão de fornecedores.
Convém que o processo de GNS permita a integração entre o processo de gestão de fornecedores
entregando serviços para o provedor de serviços, e o processo GRN.
O processo de GNS trabalha em conjunto tanto com o processo de gerenciamento de fornecedores

como com o processo GRN, para assegurar que os serviços entregues e as metas de serviço estejam
alinhadas com as necessidades do negócio e os requisitos do cliente.
Convém que o processo de gestão de fornecedores garanta que as metas de serviço acordadas
com os fornecedores estejam alinhadas com o processo GNS, bem como com outras informações
de gerenciamento, para garantir que as revisões de serviço possam ser realizadas.
Convém que o processo GNS também forneça ao processo de gerenciamento de fornecedores

detalhes sobre as mudanças que afetam qualquer acordo com os fornecedores. Por exemplo, novos
requisitos de serviços que signifiquem que o contrato com o fornecedor tem que ser modificado. Outros
exemplos incluem alterações nos processos e procedimentos que afetem a interface entre o provedor
de serviços que é responsável pela governança dos processos e fornecedores que operam processos
em nome do provedor de serviços.
Convém que o processo de GNS forneça ao processo de GRN as metas de serviços acordadas para
atender às necessidades dos clientes, bem como outras informações gerenciais necessárias para
garantir que as revisões de serviço ao cliente possam ser realizadas.
Convém que o processo GNS negocie, acorde e documente requisitos para serviços novos
ou modificados por meio de documentos de requisitos de nível de serviços, e convém que,
então, gerencie-os e revise-os por meio do ciclo de vida do serviço, criando acordos de nível
de serviços (ANS) assinados para os serviços em operação.
NOTA Exemplos de interfaces entre o processo de GNS e outros processos no SGS estão descritos
no Anexo A desta parte da ABNT NBR ISO/IEC 20000.
6.1.3 Explicação dos requisitos
6.1.3.1 Documentação dos compromissos de serviços
ANS podem precisar ser apoiados por acordos com fornecedores externos à organização do provedor
de serviços ou com grupos internos. Estes acordos de apoio com fornecedores podem ser denominados
contratos de apoio.
Acordos de apoio com grupos internos podem ser conhecidos como acordos de nível operacional.
Estes não podem ser vinculados legalmente entre ambas as partes, mas podem ser tratados como
se fossem. Convém que seja considerada a combinação das restrições de todos os acordos de apoio
a um ANS antes que o ANS seja finalizado.
Convém que o provedor de serviços monitore e meça o desempenho do serviço e o atendimento

de todos os serviços operacionais frente aos objetivos dos ANS, acordos de nível operacional,

ou acordos de desempenho, ou outros acordos de desempenho, e produza relatórios de serviço.

Convém que revisões de serviços sejam realizadas e planos de melhoria de serviços sejam criados
em intervalos regulares, pelo menos anualmente.
6.1.3.2 Catálogo de serviços

Convém que o provedor de serviços defina todos os serviços em um catálogo, usando termos que
estejam alinhados com a visão do cliente dos serviços e seja compreensível por aqueles sem uma
compreensão técnica detalhada. Convém que o catálogo de serviços detalhe e apresente todas
as definições do serviço. Convém que o escopo de cada serviço definido seja relevante para
as atividades de negócio do cliente. Convém que o catálogo contenha informações comuns a todos
os serviços, a fim de simplificar os ANS, conforme descrito na Seção 6.1.3.4 desta parte
da ABNT NBR ISO/IEC 20000. Convém que o catálogo do serviço inclua uma variedade
de informações, como:
a) o nome e a descrição do serviço;
b) metas do serviço, por exemplo, tempo para atender a uma requisição de serviço, tempo para criar
um serviço para um novo usuário, tempo para restabelecer o serviço após uma falha crítica;
c) pontos de contato;
d) horas de serviços, horas de suporte e exceções;
e) acordos de segurança;
f) serviços atuais;
g) dependência entre o serviço e os componentes dos serviços. Por exemplo, o serviço de suporte
a um usuário de laptop inclui suporte a aplicações, suporte de acesso à internet e suporte
a hardware, cada um deles pode ser provido por diferentes fornecedores ou grupos internos.
NOTA Esta lista não é exaustiva.
Convém que o provedor de serviços assegure que o catálogo de serviços é desenvolvido de modo que
as informações sejam fáceis de serem mantidas. O agrupamento lógico e eficiente das informações
é particularmente importante para a informação que é sujeita à mudança relativamente rápida. Isso
minimiza a sobrecarga do processo de gerenciamento de mudanças conforme descrito na Seção
6.1.3.4 desta parte da ABNT NBR ISO/IEC 20000.
Convém que o catálogo de serviços também mostre as dependências entre os serviços de apoio.
Por exemplo, quando um serviço de negócio é dependente de uma série de serviços de apoio, como
e-mail, segurança ou serviços de rede. Outros exemplos incluem um serviço que é dependente
de componentes de serviço que são providenciados por fornecedores ou grupos internos fora
do controle direto do provedor do serviço.
O catálogo de serviços é um documento essencial para definir as expectativas do cliente e convém

que ele esteja amplamente disponível para o cliente e a equipe de suporte.
6.1.3.3 Acordos de nível de serviço
Convém que o cliente e o provedor de serviços concordem sobre os termos e metas para o serviço
a ser entregue, documentando estes termos em um ANS (Acordo de Nível de Serviços). O ANS

é um documento que descreve o serviço e suas metas. Um ANS também especifica as responsabilidades
do provedor de serviços e do cliente. Um ANS simples pode cobrir múltiplos serviços ou múltiplos
clientes. Convém que ANS cubram todos os componentes requeridos para entregar o serviço.
Convém que os requisitos dos clientes, as necessidades do negócio e as capacidades do provedor

de serviços sejam a força determinante para o conteúdo, estrutura e as metas do ANS. Convém que
as metas, frente aos quais o serviço seja mensurado, sejam definidas na perspectiva do cliente.
Convém que o provedor de serviços esteja ciente de que muitas metas em um ANS podem criar
confusão e levar a gastos excessivos sem alcançar os benefícios esperados. Convém que os ANS
incluam apenas o subconjunto apropriado de metas, focando os aspectos mais importantes do serviço
para o negócio e para o cliente.
Convém que o conteúdo mínimo em um ANS ou a ele referenciado em um catálogo de serviço

consista em:
a) breve descrição do serviço;
b) período de validade do ANS e/ou mecanismos de controle de mudanças;
c) detalhes de aprovação de mudança;
d) breve descrição das comunicações, incluindo os relatórios de frequência da revisão e cronogramas;
e) horários dos serviços, por exemplo, 09:00 h até 17:00 h, data de exceções, por exemplo, fim
de semana, feriados públicos, períodos críticos de negócio e coberturas fora do horário comercial;
f) interrupções programadas e acordadas nos serviços, incluindo pré-aviso e números por período;
g) responsabilidades dos clientes, por exemplo, uso correto de sistemas, aderência às políticas
de segurança da informação;
h) responsabilidades do provedor de serviços e suas obrigações, por exemplo, segurança;
i) impacto e orientações prioritárias;
j) processos de notificação e escalação;
k) procedimentos para reclamações;
l) metas do serviço;
m) limites superiores e inferiores de carga de trabalho, por exemplo, a capacidade do serviço para
suportar o número de usuários, o volume de trabalho, rendimento do sistema;
n) alto nível de detalhes financeiros de gestão, por exemplo, código de carga;
o) ações a serem tomadas quando do evento de uma interrupção do serviço, incluindo incidentes
e desastres, são normalmente referenciadas em um ANS;
p) glossário de termos;
q) suporte e serviços relacionados;
r) quaisquer exceções aos termos dados no ANS;

Informações que mudam frequentemente ou informações comuns a muitos ANS podem ser fornecidas
via referência no ANS para documentos como número de telefone, relação de e-mails e diagramas
da estrutura organizacional. Isto simplifica o gerenciamento das mudanças dos ANS sem impactar
a qualidade do processo de GNS. Convém que um glossário de termos, normalmente guardados
em um único lugar, seja comum a todos os documentos, incluindo o catálogo do serviço. Isto somente
é viável se os documentos referenciados estão também sob o controle do gerenciamento de mudanças.
Convém que ambos os ANS e cada um dos serviços que o ANS descreve estejam sujeitos ao processo
de gerenciamento de mudanças.
6.1.3.4 Gerenciando o catalogo de serviços e a entrega do serviço
Convém que o provedor de serviços tenha um procedimento para tornar o catálogo de serviços
disponível para aqueles que necessitam dele para desempenhar suas funções de forma eficaz.
Convém que o procedimento também garanta que o catálogo seja mantido atualizado e de fácil
manutenção, sem a necessidade de conhecimentos especializados fora do escopo do pessoal que
usa o catálogo. Convém que verificações regulares sejam efetuadas na veracidade das informações
contidas no catálogo.
Mudanças importantes nos negócios, como, por exemplo, devido ao crescimento, reorganizações
ou fusões empresariais, ou mudanças nos requisitos dos clientes, podem requerer que os níveis
de serviços sejam ajustados, refinados, ou mesmo temporariamente suspensos.
Convém que mudanças no catálogo de serviços ou nos ANS sejam iniciadas e gerenciadas por meio
do processo de gerenciamento de mudanças, para assegurar que mudanças sejam implantadas sem
o gerenciamento de seu impacto.
Convém que o processo de GNS – Gerenciamento de Nível de Serviço seja suficientemente

flexível para acomodar todas estas mudanças. Convém que o processo de GNS assegure que o
provedor de serviços mantenha foco no cliente durante o processo de planejamento, implementação
e gerenciamento contínuo da entrega do serviço. Convém que o provedor de serviços trabalhe com
o processo GRN e clientes para obter o entendimento dos impulsionadores do negócio e seus requisitos.
Convém que o processo de GNS gerencie e coordene os contribuintes dos níveis de serviços para
identificar:
a) acordo nos requisitos de serviços e as características da carga de trabalho esperada para

o serviço;
b) acordo nas metas dos serviços;
c) medidas e relatórios dos níveis de serviços atingidos, cargas de trabalho e explicações

se as metas não foram atingidas, veja Seção 6.2, desta parte da ABNT NBR ISO/IEC 20000;
d) análise crítica do desempenho do serviço com o cliente para confirmar o desempenho relatado
e a satisfação do cliente;
e) início de ação corretiva ou preventiva;
f) entradas para um plano de melhoria do serviço;
g) análise crítica para a adequação e o alinhamento dos níveis de serviço e o catálogo de serviços
com os requisitos do negócio em consonância com o plano de atividades, no mínimo anualmente.

Convém que o processo incentive tanto o provedor de serviços como o cliente a desenvolver em
uma atitude proativa para a melhoria dos serviços e garanta que eles tenham uma responsabilidade
conjunta pelo serviço.
A satisfação do cliente é uma parte importante do processo de Gerenciamento de Nível de Serviços,

mas convém que ela seja reconhecida como uma medição subjetiva, enquanto convém que o alvo
do serviço dentro do ANS sejam medidas objetivas. Convém que o processo de GNS se alinhe com
o relacionamento do negócio e o processo de gerenciamento de fornecedores, visando gerenciar
a satisfação do cliente e atingir os objetivos do serviço.
Convém que o catálogo de serviço e o ANS sejam revistos com o cliente de acordo com as atividades
de planejamento acordadas.
6.1.3.5 Gerenciando outras partes
Convém que o provedor de serviços reconheça que o cliente pode agir tanto como fornecedor
quanto como cliente. Por exemplo, um grupo de especialistas na organização do cliente pode prover
um componente do serviço, mas também pode receber um serviço do provedor de serviços. Se este
for o caso, convém que o provedor de serviços utilize um processo de GNS para gerenciar o cliente
agindo como um provedor de serviços.
Similarmente, convém que um grupo interno que não está incluso no SGS seja gerenciado como
um provedor de serviços usando os processos de GNS.
NOTA Gerenciamento de fornecedores, por definição, externo à organização do provedor de serviços,

está sob o processo do gerenciamento de fornecedores na Seção 7.2.
6.1.4 Documentos e registros
Convém que documentos a serem produzidos e utilizados pelos clientes, provedores de serviços
e partes interessadas incluam:
a) catálogo de serviços;
b) todos os ANS e outros acordos relevantes;
c) processos e procedimentos para o processo do GNS, incluindo o gerenciamento do catálogo

de serviços e ANS;
d) entradas e saídas das revisões do processo de GNS, o catálogo de serviços e os ANS;
e) requisitos para os relatórios de serviço;
f) planejamento das atividades de revisão de serviços;
g) relatórios de monitoração e controle;
h) registros de revisão de serviços e identificação de oportunidades de melhoria;
i) planos de melhoria de serviço;

6.1.5 Autoridades e responsabilidades
Além do dono do projeto, do gestor do processo e do pessoal que executa os procedimentos

dos processos, como descrito na Seção 4.4.2.1, convém que a autoridade e responsabilidades exigidas
no âmbito do processo de GNS incluam o seguinte:
a) Convém que a operação do processo e o gerenciamento dos recursos e da comunicação sejam

de responsabilidade do gerente de nível de serviço. Este gerente também é responsável pelo
pessoal do provedor de serviços que opera os procedimentos.
b) Um representante do cliente e o gerente de nível de serviços são responsáveis pela autorização

do catálogo de serviços e cada ANS é de responsabilidade do cliente e do gerente de nível
de serviços. Convém que esses dois papéis tenham autoridade suficiente para acordar
as definições de um serviço no catálogo e as metas do serviço.
6.2 Relatos de serviço
Convém que o processo de relato de serviço garanta a produção de relatos acordados, em tempo
hábil, confiáveis e precisos, para facilitar a tomada de decisão informada e a comunicação efetiva.
6.2.2 Conceitos
O sucesso de todos os processos de gerenciamento de serviço depende do uso da informação

provida pelos relatos de serviço. Convém que monitoramento e relatos abranjam todos os aspectos
mensuráveis do serviço, provendo ambas as análises atual e histórica.
Convém que os relatos de serviços sejam apropriados para a necessidade da audiência e convém
que sejam de precisão suficiente para serem usados como uma ferramenta de suporte à decisão.
Convém que o idioma e a apresentação auxiliem a compreensão dos relatos, de modo que sejam
fáceis de assimilar, por exempo, o uso de gráficos.
Convém que os requisitos para relatos de serviço sejam acordados e registrados para os clientes
e para a gestão interna. Convém que vários tipos de relatos sejam produzidos. Isso inclui relatos
reativos e proaativos. Relatos reativos mostram o que aconteceu depois de acontecer. Relatos
proativos dão um aviso sobre eventos significativos, assim habilitam ações preventivas a serem
tomadas antecipadamente, como, por exemplo, um relato que identifica a necessidade de uma
grande redundância para um serviço crítico do negócio, para prevenir que clientes sejam impactados
pela ocorrência de incidentes. Outros tipos de relatos incluem agendas e relatos de previsão. Esses
mostram as atividades planejadas.
Convém que o provedor de serviços produza relatos para os clientes e para a gestão, incluindo
no mínimo:
a) desempenho contra metas de serviços, por exemplo, exceções ou quase exceções contra metas,
relatos de interrupção e realizações;
b) características de carga, incluindo informações sobre volume e mudanças periódicas na carga,

por exemplo, incidentes, problemas, mudanças e atividades, classificação, localização, clientes,
tendências sazonais, mistura de prioridades, número de solicitações para suporte, perfil etário
da carga de trabalho excepcional;

c) não conformidades com a ABNT NBR ISO/IEC 20000-1 identificadas durante as auditorias
internas;
d) relatos de desempenho de ações corretivas e preventivas, lições aprendidas logo após eventos,
críticos, por exemplo, incidentes críticos, desenho, transição e liberação de serviços novos
ou modificados e interrupções da continuidade de serviço ou testes e atividades de melhoria;
e) projeções de tendências atuais para ajudar na previsão do desempenho futuro;
f) rastreabilidade da resolução até a satisfação do cliente para ações corretivas ou preventivas para
resolver reclamações, feedbacks negativos de medições de satisfação e suas causas-raiz;
g) previsões e planos, por exemplo, projeções financeiras, planos de carga de trabalho, agenda
de mudanças planejadas.
Convém que onde existam múltiplos fornecedores, fornecedores-líderes e fornecedores

sub-contratados, o relato reflita as relações entre os fornecedores. Por exemplo, convém que
um fornecedor-líder reporte a totalidade do serviço que ele provê, incluindo quaisquer serviços
de fornecedores sub-contratados que eles gerenciam como parte do serviço ao cliente.
Convém que decisões relacionadas ao serviço, incluindo aquelas feitas pela alta direção e as ações
resultantes de cada um, sejam baseadas nas constatações contidas nos relatos de serviço. Convém
que o SGS inclua um procedimento que rotineiramente verifique que as decisões estão sendo
validadas pelas informações do relato de serviço. Por exemplo, priorizar relatos de disponibilidade
ou desempenho usados como base em investimentos no aumento da capacidade. Nem todas
as decisões relacionadas ao serviço conseguem ser baseadas nos relatos de serviço. Exemplos
de exceções incluem mudanças legais e regulatórias, estudos de mercados externos, mudanças
na estrutura do negócio ou avanços tecnológicos.
Convém que o provedor de serviços garanta que os relatos e resultados de cada processo estejam
sendo comunicados para todas as partes interessadas, incluindo a alta direção, donos de processo,
fornecedores e fornecedores-líderes, quando relevante.
Convém que, em adição ao dono do processo, o gerente do processo e o pessoal que executa
os procedimentos descritos na Seção 4.4.2.1, autoridades e responsabilidades requeridas pelo
processo de relato de serviço sejam incluídos:
a) pessoal responsável pela produção e distribuição em tempo hábil e preciso dos relatos de serviço
para os recipientes relevantes;
b) pessoal responsável pela definição do conteúdo de cada relato, incluindo seu formato, conteúdo,
estilo e frequência;
c) donos de processos de outros processos de gerenciamento de serviço, donos de serviço, grupos

técnicos e outras partes interessadas, a quem convém analisar os relatos e identificar, priorizar
e acionar melhorias.
6.3 Gerenciamento de continuidade e disponibilidade de serviço

Convém que o processo de gerenciamento de continuidade e disponibilidade garanta que

os comprometimentos de continuidade e disponibilidade do serviço acordados possam ser atingidos,
nas metas acordadas.

6.3.2 Conceitos
Ambos os processos de gerenciamento de continuidade e disponibilidade incluem um foco

na prevenção e recuperação de falhas ou desastres em serviços, como também garantem a provisão
de disponibilidade de serviço suficiente para atender aos requisitos do serviço.
Provedores de serviços podem operar o processo de gerenciamento de continuidade e disponibilidade

como dois processos separados que estão ligados. Alternativamente, o provedor de serviços pode
também operá-los como um único processo. Convém que a decisão seja baseada nas circunstâncias
do provedor de serviços e documentada como parte do SGS.
Convém que o processo de gerenciamento de continuidade e disponibilidade permita ambos

os aspectos reativos e proativos, priorizando de acordo com a criticidade do negócio dos serviços
acordados. Convém também que o processo de continuidade e disponibilidade capture dados para
permitir que os serviços sejam monitorados, gerenciados, revisados e melhorados pelo provedor
de serviços e relatados para o cliente, quando relevante.
Convém que o provedor de serviços desenvolva planos efetivos que garantam que os requisitos
acordados possam ser alcançados. Esses requisitos incluem requisitos para disponibilidade
e continuidade, ambos em circunstâncias normais e também após grandes perdas de serviço. Convém
que os planos incluam soluções para melhorias ou reduções nos níveis de serviço, picos esperados
de atividades e um entendimento dos requisitos para serviços novos ou modificados para resolver
futuras necessidades do negócio relativas à continuidade e disponibilidade do serviço.
6.3.3.1 Análise e gestão do risco
Convém que uma característica essencial do processo de gerenciamento de continuidade

e disponibilidade seja a análise de risco e a gestão do risco. Convém que a análise de risco inclua
a análise de impacto do negócio de uma grande interrupção do serviço.
Convém que os requisitos para continuidade e disponibilidade do serviço sejam identificados

e acordados com base nos requisitos do serviço, nos resultados obtidos dos exercícios de análise
de impacto no negócio, de prioridades de negócio do cliente, políticas, planos, ANS e riscos avaliados.
Convém que o provedor de serviços mantenha habilidades de serviços suficientes, junto com planos
efetivos desenhados, para garantir que os níveis acordados de serviços sejam mantidos em caso
de ocorrência de uma grande interrupção do serviço.
Convém garantir que os níveis de serviço sejam mantidos após uma grande interrupção do serviço
e que levem em consideração os elementos da operação ao vivo do serviço que estão sob o controle
de outras partes, como o cliente ou fornecedores.
Convém que a continuidade de serviço e requisitos de disponibilidade para o serviço normal, e após
uma grande interrupção do serviço, incluam pelo menos o seguinte:
a) direitos de acesso, por exemplo, quem pode ter direitos de acesso em condições normais e quem
pode ter a mais alta prioridade de acesso a um serviço limitado após uma grande interrupção
do serviço;
b) tempos de resposta, por exemplo, tempos de resposta em circunstâncias normais e também após
uma grande interrupção do serviço. Convém que seja definido e acordado com o cliente, qual
é o tempo de resposta aceitável para diferentes serviços e quais ações convém serem tomadas
para assegurar que os tempos de resposta acordados sejam alcançados;

c) disponibilidade de serviços de ponta a ponta. Por exemplo, para o serviço normal, qual
é a disponibilidade necessária de componentes necessários para fornecer um serviço completo.
Convém que, após uma grande interrupção do serviço, seja dada prioridade ao retorno de cada
serviço específico ao desempenho normal.
6.3.3.2 Política de continuidade de serviço

Pode ser útil ao provedor de serviços desenvolver e manter uma política que define a abordagem
geral para cumprimento das obrigações de continuidade de serviço. Convém que o escopo da política
de continuidade do serviço seja coerente com o escopo do SGS.
Convém que a política defina um método consistente para determinar a resiliência necessária versus
a real, para cada serviço, e priorizar efetivamente as oportunidades de melhoria em alinhamento
com a importância do negócio de serviços.
Convém que a política de continuidade do serviço conduza as atividades do provedor de serviços

de planejamento de continuidade no âmbito do plano de continuidade de serviços.
Convém que a política aborde os papéis, atividades e responsabilidades exigidas para atender
às exigências de serviço acordadas.
Convém que a política defina as interfaces entre oo processo de continuidade e disponibilidade

de serviço e outros processos de gerenciamento de serviços. O Anexo A desta parte da
ABNT NBR ISO/IEC 20000 inclui informações sobre as interfaces entre a continuidade de serviço
e processo de gerenciamento de disponibilidade e outros componentes do SGS.
Convém que a política leve em conta as horas de serviço acordadas e os períodos críticos de negócio.
Convém que o provedor de serviços identifique os requisitos separadamente para cada grupo
de clientes e serviços, incluindo:
a) o período máximo aceitável de serviço contínuo interrompido;
b) os períodos máximos aceitáveis de degradação do serviço;
c) os níveis de serviço degradados aceitáveis, durante um período de recuperação de serviços.
Convém que as horas de serviço acordadas e os períodos críticos de negócio sejam definidos em
relação aos ciclos de negócio específicos e sua criticidade associada. Por exemplo, final do mês, final
de ano, períodos de férias.
Se o provedor de serviços se baseia em uma política de continuidade de serviço para dirigir o processo,
convém que a política de continuidade do serviço seja revista em intervalos acordados, pelo menos
anualmente. Convém que quaisquer alterações à política seja formalmente acordada entre o provedor
de serviços e o cliente.
6.3.3.3 Planos de continuidade e disponibilidade de serviço
Se uma política de continuidade de serviço está aplicada, o provedor de serviços pode alinhar
a política com uma estratégia de continuidade de serviço. Convém que esta seja apropriada à criticidade
dos serviços com base na análise de impacto nos negócios dos serviços. Convém que o provedor
de serviços também colete informação relevante de outros processos de gerenciamento de serviços
como entrada para estratégia de continuidade de serviço.

Uma vez que a estratégia é definida, convém que uma análise de risco seja realizada para identificar
riscos de continuidade que conflitem com a estratégia e, onde o nível de risco é inaceitável, definir
controles para gerenciá-los ou instigar ações mitigadoras.
Convém que o provedor de serviços mantenha capacidade de serviço suficiente em conjunto com
planos viáveis destinados a assegurar que os requisitos acordados podem ser cumpridos.
Convém que o provedor de serviços desenvolva planos de continuidade e disponibilidade de serviços,

planos e procedimentos de recuperação e uma política de teste de continuidade de serviços. Convém
que os planos de continuidade de serviços e políticas de teste sejam projetados para reduzir o impacto
de grandes perturbações nas funções-chave de negócios e processos.
Convém que o plano de continuidade de serviço seja com base nos requisitos definidos na política
de continuidade de serviço, na análise de impacto do negócio e avaliações de risco.
Convém que a operação em curso defina os requisitos para conscientização em continuidade

de serviços, educação e formação, avaliação e auditoria, teste de continuidade de serviço e coordena-
ção com o processo de gestão de mudança. Convém que os planos de continuidade de serviço sejam
testados regularmente e que a responsabilidade para invocá-los seja claramente definida. Convém
que testes de continuidade de serviço sejam realizados pelo menos anualmente, ou depois de uma
grande mudança no negócio. Convém que sessões de formação regulares sejam realizadas com
todas as partes relevantes. Convém que exista uma política para o armazenamento de continuidade
de serviço e planos de recuperação de gerenciamento de liberação, definida e gerenciada, e convém
que outras mídias de backup críticas, documentação e outros recursos necessários para a recupera-
ção sejam armazenados externamente.
Convém que o provedor de serviços assegure que:
a) planos de continuidade de serviço levem em conta as dependências entre os serviços

e componentes de serviços;
b) planos de continuidade de serviço e outros documentos necessários para suportar a continuidade

de serviço sejam registrados e mantidos;
c) a responsabilidade para invocar planos de continuidade de serviço esteja claramente atribuída,

e que haja planos claros para alocação de responsabilidade para tomar medidas contra cada
exigência da política de recuperação;
d) backups de dados, documentos e software, e de qualquer equipamento e pessoal necessário

para a restauração do serviço estejam rapidamente disponíveis após a ocorrência de uma falha
do serviço ou acidente crítico;
e) documentos de continuidade de serviços, por exemplo, planos de continuidade de serviços

e cronogramas, listas de contato e o BDGC, permaneçam acessíveis durante uma interrupção;
f) as pessoas compreendam o seu papel na invocação e/ou execução dos planos;
g) acordos de recuperação com fornecedores e provedores de recuperação do local existam,

quando apropriado.
Convém que os planos de continuidade de serviço e documentos relacionados, por exemplo, contratos,
sejam avaliados antes que sistemas ou mudanças sejam aprovadas e antes que requisitos novos
ou modificados do cliente sejam aprovados. Convém também que os planos de continuidade de serviço
e documentos relacionados sejam revisados e testados pelo menos anualmente.

Convém que um plano de disponibilidade seja desenvolvido e publicado. Convém que o plano
de disponibilidade identifique as necessidades de negócio e requisitos do cliente, requisitos
de projeto, especificações técnicas e atividades de planejamento de projetos necessários para
atender aos requisitos de disponibilidade de negócios, atuais e futuros. Convém que as previsões
sobre a disponibilidade futura, documentada no plano de disponibilidade, incluam propostas de ações
preventivas para minimizar a probabilidade de não disponibilidade não planejada. Convém que o plano
de disponibilidade seja analisado e revisto regularmente, pelo menos anualmente e após qualquer
alteração importante.
Convém que o planejamento e projeto da disponibilidade de serviços novos ou modificados seja

baseado na criticidade dos serviços para a empresa, e convém equilibrar custo contra o risco aceitável
do negócio.
Convém que todas as não disponibilidades dos serviços e componentes de serviço sejam registradas,
investigadas e ações apropriadas sejam tomadas para reduzir o impacto e/ou a probabilidade
de qualquer acontecimento futuro.
6.3.4 Continuidade do serviço e monitoramento da disponibilidade e testes
6.3.4.1 Testes de continuidade de serviço
Convém que os testes de continuidade do serviço sejam realizados após cada mudança de negócios
e mudança no ambiente do serviço. Convém que a frequência seja com base nas circunstâncias
do provedor de serviços. Convém que a frequência seja suficiente para obter a certeza de que
os planos de continuidade de serviço são eficazes, e que permaneçam assim por meio da evolução
das mudanças dos sistemas, processos, pessoal e necessidades comerciais. Convém que o escopo
dos testes de continuidade do serviço inclua o retorno da operação do serviço à normalidade,
após uma interrupção.
Convém que os testes de continuidade do serviço envolvam a participação conjunta do cliente

e o provedor do serviço, com base em um conjunto de objetivos acordados. Se for necessário, convém
também incluir outras partes. Convém que falhas nos testes sejam documentadas e analisadas como
entrada em um plano para melhorar o serviço.
Convém que seja realizada uma revisão após um teste de continuidade do serviço, para avaliar
a realização das metas e objetivos do teste e para identificar eventuais áreas de fraqueza
ou oportunidades de melhoria.
6.3.4.2 Monitoramento de disponibilidade e testes
Convém que a continuidade de serviço e o gerenciamento de disponibilidade tenham acordado

no plano de disponibilidade:
a) monitorar e registrar a disponibilidade do serviço;
b) manter a precisão dos dados históricos sobre a disponibilidade dos serviços;
c) fazer comparações com os requisitos definidos em ANS para identificar qualquer não conformidade
com as metas de disponibilidade acordadas;
d) documentar e revisar não conformidades;
e) prever requisitos de disponibilidade futura.

Convém que um cronograma de testes regulares de disponibilidade confirme que a disponibilidade das
soluções são realizáveis e adequadamente resilientes. Convém que mecanismos de confiabilidade,
disponibilidade e resiliência sejam revisados e testados após qualquer grande mudança.
Convém que, sempre que possível, potenciais problemas sejam previstos e medidas preventivas sejam
tomadas. Convém que a continuidade de serviço e gerenciamento de disponibilidade se esforcem
para atingir e melhorar os níveis definidos de confiabilidade para todos os componentes do serviço,
com ações preventivas e corretivas identificadas, registradas e implementadas.
6.3.4.3 Gestão de risco para a disponibilidade
Convém que a avaliação dos riscos identifique funções vitais do negócio, requisitos de disponibilidade
e os riscos acordados com o negócio.
Convém que a gestão de riscos produza soluções para permitir a entrega de níveis necessários
de disponibilidade e para mitigar os riscos identificados, pela implementação de contramedidas
de custos justificáveis, sempre que possível. Não é aconselhável exceder aos requisitos por meio
de grandes investimentos financeiros que custam muito mais do que os benefícios de melhoria
na disponibilidade.
Convém que o planejamento e desenho da disponibilidade de serviços novos ou modificados seja

baseado na criticidade do negócio e importância para o serviço, em diferentes períodos para o negócio
e horas de serviço exigidos.
Convém que o monitoramento regular, a medição, a análise de relatórios e as análises de serviço

e disponibilidade de componentes sejam aspectos essenciais do processo. Convém que todos
os dados relevantes referentes à disponibilidade e indisponibilidade de serviços sejam mantidos.
Convém que os relatórios de metas de disponibilidade alcançadas utilizem dados reais históricos
e o foco de medição e que os relatórios estejam alinhados com as metas acordadas.
Convém que a avaliação de solicitações de mudanças para todos os serviços novos ou modificados
levem em consideração os impactos potenciais de riscos para metas acordadas de disponibilidade.
Convém que mecanismos de confiabilidade, disponibilidade e resistência sejam regularmente revistos
e testados após qualquer alteração importante.
Convém que os critérios de desenho definam a disponibilidade de produtos de base, tecnologia

e componentes que proporcionam a confiabilidade necessária.
6.3.4.4 Revisão após a invocação do plano de continuidade de serviço
Convém que a revisão seja realizada após a invocação do plano de continuidade de serviço para:
a) identificar a natureza e a causa da interrupção do serviço que iniciou a ativação do plano;
b) avaliar a adequação da resposta da administração;
c) avaliar a eficácia da organização em atingir seus objetivos de tempo de recuperação;
d) avaliar a adequação do plano de continuidade de serviço e testes na preparação de pessoal

para a ativação do plano;
e) identificar melhorias a serem feitas para o plano de continuidade de serviço e testes.

Convém que os documentos e registros que sejam produzidos e retidos para continuidade de serviço
e processo de gerenciamento de disponibilidade incluam, mas não se limitem a:
a) continuidade dos serviços e políticas de gerenciamento de disponibilidade;

b) análise de impacto nos negócios;
c) relatórios de avaliação de risco;
d) continuidade de serviço e planos de disponibilidade;
e) continuidade de serviço e requisitos de disponibilidade do cliente;
f) restrições de componentes de serviço e os dados de disponibilidade;
g) continuidade dos serviços e desenho da disponibilidade;
h) a continuidade de serviço e planos de teste de disponibilidade;
i) continuidade de serviço e relatórios de teste de disponibilidade;
j) processos e procedimento para o gerenciamento de continuidade e disponibilidade;
k) requisitos e registros de treinamento para conscientização;
l) banco de dados de gerenciamento de disponibilidade;
m) relatórios de monitoramento de disponibilidade;
n) manutenção e os horários de interrupção previstos para os serviços.
Convém que o pessoal compreenda o seu papel na invocação e/ou execução dos planos e seja capaz
de rapidamente acessar documentos de continuidade de serviço.
Convém que planos de continuidade de serviço e documentos relacionados com, por exemplo,
contratos, sejam avaliados para o potencial impacto como parte do processo de gestão da mudança,
do processo GNS e do processo de gestão de fornecedores. Por exemplo, antes de aceitar serviços
novos ou modificados ou acordar requisitos de serviço.
Convém que, além do dono do processo, do gestor do processo e do pessoal que executa os
procedimentos do processo, como descrito na Seção 4.4.2.1, as autoridades e responsabilidades
necessárias relativas à continuidade de serviço e do processo de gestão de disponibilidade incluam:
a) o administrador da disponibilidade, responsável por garantir que o monitoramento de infraestrutura

e a captura de dados relativos à disponibilidade de componentes e de serviços ocorram
corretamente e conforme necessário;
b) uma equipe de recuperação técnica, responsável pelo planejamento de recuperação de desastres,

testes e restauração de serviços;

c) o cliente, o pessoal do provedor de serviços e partes interessadas que necessitam de acesso

para o gerenciamento da informação de continuidade e disponibilidade participem nos testes
e aceitação dos requisitos de continuidade de serviço;
d) o analista de disponibilidade, responsável pela revisão e análise de relatórios de disponibilidade

e de dados para identificar problemas de disponibilidade reais e potenciais, para que sejam
identificadas soluções apropriadas para a melhoria da disponibilidade;
e) o pessoal de continuidade de serviços, responsável pela manutenção da capacidade

de monitoramento e gatilhos.
6.4 Orçamento e contabilização para serviços
Convém que o processo de orçamento e contabilização apoie o entendimento do provedor de

serviços na capacidade de gerenciar o custo total dos serviços. Para atingir esse objetivo, convém que
o processo assegure que:
a) o custo de serviços individuais, prestação de serviços em geral e orçamento do provedor

de serviços são compreendidos;
b) uma previsão confiável dos custos e orçamento é atingível;
c) um orçamento é desenvolvido e utilizado por processos de gerenciamento de serviços;
d) variações inesperadas de custos ou de orçamento são identificadas e administradas;
e) o orçamento é respeitado para que a prestação de serviços seja financiada adequadamente

durante o período de orçamento;
f) previsões, orçamentos e custos são revistos regularmente para garantir que o processo
e procedimentos permaneçam eficazes.
6.4.2 Conceitos
Convém que o processo de orçamento e contabilização controle os aspectos financeiros de serviços

e componentes de serviço. Convém que o processo de orçamento e contabilização de serviços forneça
informações que suportem tanto a operação dos serviços quanto do financiamento das mudanças
de serviços e melhorias. Convém que o processo de orçamento e contabilização de serviço assegure
que os custos da prestação do serviço são rastreados e os próprios serviços são acessíveis e estão
de acordo com os orçamentos.
A responsabilidade por muitas das decisões financeiras pode estar fora do alcance do SGS.
Os requisitos quanto ao nível de detalhe das informações financeiras a prestar, em que forma e
em quais frequências podem ser ditadas por entidades externas ao provedor de serviços. Convém
que requisitos específicos de outros reguladores ou organizações sejam também levados em conta
no que diz respeito a como eles vão afetar algumas das políticas e procedimentos definidos. Convém
que todas as práticas contábeis utilizadas estejam alinhadas com as práticas contábeis mais amplas
da organização do provedor de serviços.
Convém que o processo de orçamento e contabilização de serviços seja feito pelo provedor de serviços,
independentemente de outros aspectos da gestão financeira que sejam realizadas por outras partes

da organização. Convém que o processo de orçamento e contabilização de serviços seja alinhado

e receba informações dos processos financeiros da organização do provedor de serviços.
6.4.3.1 Política
Convém que o provedor de serviços tenha uma política documentada e procedimentos para a gestão
financeira dos serviços. Convém que a política defina os objetivos a serem cumpridos pelo processo
de orçamento e contabilização de serviços. Convém também que a política defina os detalhes
necessários para assegurar que os objetivos sejam cumpridos. Para fazer isso, convém que a política
inclua os tipos de custo utilizados no orçamento para alocação de custos e uma explicação de como
os custos indiretos são distribuídos.
Convém que os critérios sejam definidos para permitir uma análise do orçamento e contabilização
para cada serviço. Quando definido, esses critérios podem ser aplicados para os itens do orçamento
e lançamentos contábeis para garantir que algum acompanhamento periódico e visibilidade estejam
disponíveis sobre os custos dos serviços. Isto pode ser usado para controlar os custos de um serviço
e permitir a comparação com os custos de aquisição do mesmo serviço em outro mercado.
Convém que os recursos previstos para o processo de orçamento e contabilização de serviços

sejam baseados nas necessidades do cliente, provedor de serviços, fornecedores e outras partes
interessadas, para detalhe financeiro, conforme definido na política.
6.4.3.2 Tipos de custos
Convém que o provedor de serviços selecione as categorias para as entradas de custo no orçamento
que são úteis para o gerenciamento de serviços. Por exemplo, convém que provedores de serviços
definam modelos de custos alinhados com os serviços e seus componentes, como definido
no catálogo de serviços, Seção 6.1. Convém que um tipo de custo seja atribuído a cada custo que faz
parte de um serviço. Modelos de custos são úteis porque permitem ao provedor de serviços prever,
com mais precisão, o custo/benefício de diferentes níveis de qualidade do serviço, ou de opções
de serviços diferentes. Convém que modelos de custos sejam capazes de demonstrar o custo total
da prestação de cada serviço.
Convém que o provedor de serviços também considere os tipos de custos, como:
a) bens utilizados para prestar os serviços;
b) recursos compartilhados, como uma central de serviço, também conhecidas como suporte de
nível 1;
c) despesas gerais, como espaço de escritório;
d) serviços prestados pelos fornecedores;
e) o custo de empregar o pessoal de gerenciamento de serviços.
Ao identificar os tipos de custos adequados, convém que exista um equilíbrio entre os benefícios
da informação contábil detalhada derivada de tipos de custos e os desafios de coleta e a gestão
dos grandes volumes de informação necessários. Convém que os tipos de custos sejam baseados
em categorias que podem ser medidas facilmente e de forma confiável. Os exemplos incluem
os custos de hardware, custos de manutenção de software e custos de pessoal.

6.4.3.3 Repartição de despesas gerais e de alocação de custos diretos
O rateio das despesas gerais pode ser baseado em uma variedade de mecanismos, como uma taxa
fixa de custo, uma porcentagem fixa, ou com base no tamanho acordado de um elemento variável
de serviços prestados.
Convém que o provedor de serviços utilize métodos de rateio das despesas gerais e alocação
de custos diretos que são apropriados para a sua organização, equilibrando o custo do gerenciamento
do rateio com o benefício de ser capaz de repartir os custos em detalhes. Outros fatores que podem
ser considerados incluem:
a) natureza, alcance e consumo, ou utilização dos serviços;
b) granularidade da organização do cliente, por exemplo, uma unidade de negócios como uma
unidade, subdivididas em departamentos, ou por locais;
c) ANS e o rateio dos custos dos serviços e níveis de serviço;
d) serviços prestados pelos fornecedores.
6.4.3.4 Orçamento
Convém que a previsão de custos e receitas para o orçamento leve em conta as alterações previstas
para os serviços durante o período orçamental. Quando aplicável, convém que variações sazonais
e mudanças de curto prazo planejadas para os custos de serviços e encargos sejam entendidas
e incluídas dentro dos orçamentos previstos. Convém que o orçamento e controle de custos apoiem
o planejamento para operar e melhorar os serviços para que os níveis de serviço possam ser mantidos
durante todo o ano. Convém que haja previsão de despesas suficiente para cobrir os recursos
necessários para suportar os níveis de serviço acordados para o período acordado. Convém que
um procedimento para identificar e gerenciar as variações do real frente a despesas orçadas também
seja estabelecido.
6.4.3.5 Contabilidade
Convém que as atividades contábeis sejam usadas para controlar os custos a um nível acordado
de detalhe ao longo de um período de tempo acordado. Convém que as decisões sobre a prestação
de serviços sejam baseadas em comparações de custo-efetividade. Convém que os modelos
de custos sejam capazes de demonstrar os custos totais de prestação de serviços.
Convém que os relatórios de contabilidade demonstrem a sobreutilização e a subutilização. Idealmente,

convém também que relatórios contábeis forneçam informações suficientes para calcular os custos
de níveis baixos de serviço ou custos resultantes de uma interrupção do serviço. Para calcular
os custos de níveis baixos de serviço ou interrupção do serviço, convém que o provedor de serviços
tenha uma compreensão clara dos custos dos recursos necessários para realizar o serviço. Convém
incluir pessoal, componentes, instalações e quaisquer aspectos relativos ao serviço prestado
por terceiros. Convém também que o provedor de serviços tenha uma compreensão clara do impacto
nos negócios da interrupção do serviço, dependendo da duração, hora do dia /semana/mês ou ano e
do serviço em questão. Esta informação pode ser fornecida por uma análise de impacto nos negócios.
Os relatórios de contabilidade podem também utilizar as informações do BDGC sobre o estado

e ciclo de vida dos IC para calcular o custo total de propriedade e depreciação dos IC que suportam
um determinado serviço. Esta informação pode, por sua vez, ser usada para entender e planejar
os custos do ciclo de orçamento seguinte.

6.4.3.6 Cobrança
A cobrança não está incluída na ABNT NBR ISO/IEC 20000-1, mas recomenda-se que, quando
a cobrança estiver em utilização, o mecanismo de cobrança esteja definido e compreendido por todas
as partes.
Documentos e registros a serem produzidos e utilizados pelo cliente, provedor de serviços e as partes
interessadas incluem:
a) políticas, processos e procedimentos para orçamento e contabilização;
b) orçamentos históricos, projeto de orçamento para o próximo ano e orçamento real para o ano
em curso;
c) as previsões de gerenciamento de cargas de trabalho de serviços, capacidade (incluindo pessoal),

custos unitários de itens de receita; despesas de capital previstas;
d) o calendário para a produção de orçamento;
e) relatórios financeiros que comprovem despesas e receitas para cada período de tempo
no exercício orçamental, com todas as variações;
f) relatórios sobre as causas das variações e como eles serão geridos;
g) esforço financeiro para projetos de melhoria contínua do serviço;
h) os modelos de custos que mostram como os elementos de custo são utilizados para prestação
de serviços e criação de valor;
i) os relatórios necessários para fins legais ou regulatórios.
Convém que, além do dono do processo, gerente de processo e pessoal que executa os procedimentos
do processo, conforme descrito na Seção 4.4.2.1, autoridades e responsabilidades exigidas dentro
do orçamento e contabilização incluam o seguinte:
a) um gerente de orçamento e contabilização, responsável pela gestão dos recursos financeiros;
b) gerentes com responsabilidade para um orçamento específico na organização do provedor

de serviços.
6.5 Gerenciamento da capacidade
Convém que o processo de gerenciamento da capacidade assegure que capacidade suficiente seja
fornecida para atender aos requisitos atuais acordados de capacidade e desempenho. Convém que
o provedor de serviços crie e implemente um plano de capacidade que atenda aos requisitos futuros
de capacidade e desempenho acordados.

6.5.2 Conceitos
Convém que os recursos sejam equilibrados para preencher os requisitos de desempenho

de capacidade atuais e futuros e para que estejam preparados para cumprir requisitos futuros.
Convém que o processo de gerenciamento da capacidade inclua tanto atividades reativas como
proativas. Convém que as atividades reativas tenham enfoque no monitoramento constante, ajustes,
análises e melhoria da capacidade operacional. Convém que o aspecto proativo do processo tenha
enfoque no planejamento para cumprir demandas futuras acordadas.
Convém que sejam desenvolvidos planos durante o processo de gerenciamento da capacidade para
assegurar que os requisitos acordados relativos à capacidade possam ser acordados, previstos
e cumpridos. Convém que estes planos transformem as previsões de negócios e estimativas de
carga de trabalho em requisitos específicos de capacidade. Convém que isto seja facilitado por meio
da incorporação das seguintes três áreas de enfoque do processo de gerenciamento da capacidade:
a) gerenciamento da capacidade do negócio com enfoque na quantificação dos planos de negócios

e necessidades dos clientes e do provedor de serviços, para requisitos de serviços futuros;
b) gerenciamento da capacidade do serviço com enfoque no planejamento e gerenciamento

dos serviços e recursos de suporte para assegurar que eles atinjam todas as metas acordadas
do gerenciamento de serviços;
c) gerenciamento da capacidade do componente, com enfoque no planejamento e gerenciamento

operacionais dos recursos para assegurar que eles apoiam os serviços de forma efetiva e atingem
as metas acordadas para o componente.
6.5.3.1 Atividades do gerenciamento da capacidade
As atividades de gerenciamento da capacidade envolvem atividades operacionais, como

o monitoramento do uso da capacidade e a análise de dados sobre capacidade, o gerenciamento
do desempenho versus metas de serviço e planejamento de requisitos de capacidade futura.
As atividades do processo de gerenciamento de capacidade incluem as listadas abaixo.
a) Avaliar, documentar e acordar os requisitos de capacidade, definir a carga de trabalho, linhas

de base de desempenho e definir os limites e gatilhos da carga de trabalho e desempenho.
b) Avaliar, documentar e acordar quais os requisitos de capacidade para serviços novos

ou modificados.
c) Convém que o processo de gerenciamento de capacidade seja envolvido nos projetos de serviços
novos ou modificados e que faça recomendações para a aquisição de componentes e recursos,
onde estes são fatores para desempenho e/ou capacidade. Convém que, no interesse de equilibrar
custo e capacidade, o processo de gerenciamento da capacidade obtenha custos de propostas
e soluções alternativas e recomende a solução mais adequada de custo-benefício.
d) Convém que as atividades relacionadas a novos requisitos sejam baseadas nas entradas para
planejamento, equipes de suporte e grupos de negócio. Convém que isto inclua o planejamento
da implementação da infraestrutura de projetos novos e previsão de substituição dos componentes
da infraestrutura antigos.

e) Definir, monitorar e usar os limites de capacidade, avisos e alarmes para gerenciar e melhorar
automaticamente a utilização dos componentes e o desempenho dos serviços.
f) Manter dados e informações utilizadas pelo processo de gerenciamento de capacidade em um

repositório, a que muitas vezes nos referimos como o banco de dados da capacidade. Convém
que esse repositório seja um elemento-chave do processo de gerenciamento de capacidade.
Os dados e informações contidos no banco de dados de capacidade são analisados por todas
as atividades de gerenciamento de capacidade e convém que inclua negócios, serviços, recursos
ou utilização e dados financeiros de todas as áreas de tecnologia, conforme abaixo:
1) Dados comerciais: informações confiáveis sobre as necessidades atuais e futuras do negócio.
2) Dados do serviço, incluindo, mas não limitado a: tempos de resposta da transação, taxas de
transação e volumes de carga de trabalho.
3) Dados de utilização do componente: convém que limitações dos componentes sobre o nível em
que eles são utilizados sejam documentadas. Se passar desse nível de utilização, o recurso
será sobrecarregado e o desempenho dos serviços que utilizam o recurso será prejudicado.
4) Outros dados a serem utilizados pelo processo de gerenciamento de capacidade incluem os

de gargalos e de pontos fracos identificados; redundância e capacidade reserva; recursos,
componentes e limites e tolerâncias do serviço; previsões corrente, passada e futura de
produtividade e desempenho; comparações de realizações reais versus realizações previstas.
g) Produção de relatórios de capacidade e desempenho, que forneçam informações valiosas para

muitos processos de gerenciamento de serviço. Convém que os relatórios de capacidade sejam
consolidados e armazenados dentro do banco de dados de capacidade, para que as partes
interessadas possam se referir a eles. Convém que estes relatórios incluam os listados abaixo:
1) Relatórios baseados no componente e informações ilustrativas de como os componentes

estão desempenhando e quanto de suas capacidades estão sendo utilizadas.
2) Relatórios baseados no serviço e informações que ilustrem como está o desempenho

do serviço e de seus componentes, em relação às metas e restrições totais do serviço.
Esses relatórios fornecem a base de relatórios de serviço de clientes e Acordos de Níveis
de Serviço – ANS que informam capacidade e desempenho.
3) Também convém que sejam produzidos relatórios de exceção, que mostram, para as áreas de
gerenciamento e pessoal técnico, quando a capacidade e o desempenho de um determinado
componente ou serviço se tornaram inaceitáveis. Convém que, em particular, relatórios
de exceção sejam de interesse do processo de Gerenciamento de Níveis de Serviço – GNS
para determinar se as metas em ANS foram alcançadas ou violadas. Os processos de
gerenciamento de incidente, de requisições de serviço e de gerenciamento de problemas
podem, então, usar os relatórios de exceção na resolução de incidentes e problemas.
h) Convém que as previsões futuras de capacidade e desempenho de componente e de serviço

sejam feitas de várias maneiras, dependendo da técnica e da tecnologia utilizadas. Exemplos
disso estão abaixo:
1) Modelagem de linha de base é o primeiro estágio da modelagem. É usada para criar

um modelo de linha de base que reflete com precisão o desempenho que está sendo alcançado.
Quando este modelo de linha de base é utilizado, é possível desenvolver modelagem preditiva.

2) Análise de tendências é concluída usando as informações de utilização de recursos

e de desempenho do serviço que foram coletadas.
3) A modelagem analítica usa técnicas matemáticas para analisar o desempenho de sistemas

informatizados.
4) Modelagem de simulação envolve a modelagem de eventos discretos, como, por exemplo,

taxas de recebimento de transação versus uma determinada configuração do sistema.
6.5.3.2 Plano da capacidade
Convém que o plano de capacidade documente o desempenho real, as necessidades projetadas

de capacidade do negócio e os requisitos de serviço. Convém que ele seja produzido no mínimo
anualmente, ou com mais frequência, se taxas de alteração dos serviços e volumes de serviço assim o
exigirem. Convém que o plano documente as soluções recomendadas para atingir as metas de serviço
acordadas e opções para satisfazer as necessidades de custo do negócio.
Convém que o plano da capacidade inclua:
a) uso atual e previsto do serviço, incluindo, idealmente, recomendações de oportunidades que

influenciem a demanda de capacidade;
b) uso atual e previsto de recursos e de desempenho, incluindo o entendimento sobre que recursos
apoiam quais serviços;
c) o impacto sobre a capacidade e desempenho de requisitos acordados na disponibilidade,

continuidade e metas do serviço, por exemplo, estimativas da carga de trabalho e requisitos de
capacidade em caso de desastre;
d) escalas de tempo, limites e custos de atualização da capacidade de serviço, por exemplo, datas
necessárias e custos para a entrega de um aumento da capacidade de serviço como resultado
de uma fusão de negócios;
e) resumos de planos de negócios relevantes, cenários e padrões de atividade de negócios;
f) resumo das alterações na atividade de negócios, incluindo perfis de usuário, se disponíveis;
g) detalhes dos métodos, hipóteses e informações utilizadas no cálculo dos detalhes do plano
da capacidade;
h) impacto potencial das novas tecnologias na capacidade e no desempenho;
i) dados e procedimentos para capacitar análise preditiva, como, por exemplo, técnicas de
modelagem.
j) impacto potencial dos requisitos legais, regulatórios, contratuais e organizacionais, por exemplo,
um plano para sustentar armazenamento suficiente, com capacidade extra para registros médicos
eletrônicos, para satisfazer a regulamentação.
Convém que os documentos e registros produzidos e mantidos pelo processo de gerenciamento

da capacidade incluam:
a) plano de capacidade;

b) procedimentos de gerenciamento de capacidade;
c) linhas de base e perfis;
d) banco de dados de gerenciamento de capacidade;
e) especificações com os limites de recursos e serviço, e os limites para eventos e alarmes;

f) relatórios de desempenho do serviço;
g) níveis de utilização e cronogramas;
h) avaliações de eficácia;
i) análise de carga de trabalho;
j) relatórios de exceção do gerenciamento de capacidade;
k) análise crítica de registros de incidentes relativos à capacidade e desempenho.
Convém que os documentos e registros analisados criticamente pelo processo de gerenciamento

de capacidade incluam requisitos, a demanda atual e futura do negócio e dos clientes e os requisitos,
incluindo os ANS e níveis de serviço exigidos e relatórios de auditoria. Convém que as alterações
no plano de capacidade sejam gerenciadas por meio do processo de gerenciamento de mudanças.
Convém que, além do dono do processo, do gerente do processo e do pessoal que executa
os procedimentos do processo, conforme descrito na Seção 4.4.2.1, as autoridades e responsabilidades
exigidas no processo de gerenciamento de capacidade incluam o seguinte.
a) Analista da capacidade, responsável pela análise e revisão de dados de desempenho

da capacidade, para identificar problemas de capacidade real e potencial, de forma que as soluções
para remover essas questões e manter o desempenho do serviço possam ser identificadas.
O analista de capacidade auxilia na identificação de opções e análise e recomendação das
soluções preferidas para atender à demanda de capacidade corrente.
b) Clientes e representantes do negócio, responsáveis pela documentação e acordo para todos

os requisitos de capacidade.
6.6 Gerenciamento da segurança da informação
Convém que o processo de gerenciamento da segurança da informação (GSI) verifique se os controles

de segurança para proteger os ativos de informações e os requisitos da segurança da informação
sejam incorporados no desenho e na transição de serviços novos ou modificados.
6.6.2 Conceitos
Convém que a segurança da informação seja o resultado de um sistema de políticas e procedimentos

destinados a identificar, controlar e proteger as informações da organização e os recursos utilizados
em conexão com o seu armazenamento, transmissão e processamento.

Convém que os gestores assegurem que os objetivos do gerenciamento da segurança de informação

sejam claramente definidos, implementados e alinhados com as necessidades do negócio.
Convém que o provedor de serviços e o cliente categorizem os ativos de informação de acordo com
seu valor, a confidencialidade ou impacto nos negócios. Convém que, para cada categoria, o provedor
de serviços e o cliente definam e concordem com um nível aceitável de risco.
6.6.3.1 Política de segurança da informação
Convém que os requisitos de serviço, requisitos estatutários e regulatórios e obrigações contratuais

forneçam a base de uma política de segurança da informação. Convém que a política direcione o uso
de controles de segurança física, administrativa e técnica de informações projetados para preservar
a segurança dos ativos de informação, por exemplo, a confidencialidade, a integridade e a acessibilidade.
Convém que a política seja aprovada pelos gestores responsáveis pelo SGS e os serviços.
Convém que o escopo da política de segurança da informação inclua, mas não seja limitado por,
controles físicos, administrativos e técnicos exigidos para assegurar a confidencialidade, integridade
e acessibilidade de ativos da informação no escopo do SGS. O escopo da política de segurança
da informação pode exceder o escopo do SGS para acomodar as necessidades do negócio.
Convém que a direção assegure que funcionários, clientes, fornecedores e grupos internos têm
tanto a compreensão adequada do conteúdo da política como uma apreciação sobre a importância
de aderir a ela.
Convém que a direção garanta também que a diretriz de segurança da informação seja usada como
parte das avaliações de risco e durante as auditorias de segurança da informação.
Convém que a política forneça orientações sobre os critérios para a aceitação de riscos e a abordagem
de gestão para os riscos de segurança da informação identificados, por exemplo, gerenciamento
de senhas.
Convém que a política garanta que as auditorias internas de segurança da informação sejam
conduzidas em intervalos regulares, por exemplo, após uma violação de segurança da informação,
ou após a implementação de um serviço novo ou modificado.
Convém que a política garanta que os resultados de auditoria de segurança da informação sejam
periodicamente revistos e usados para identificar oportunidades de melhoria na segurança
da informação. Por exemplo, corrigindo vulnerabilidades identificadas durante uma auditoria
de segurança da informação.
NOTA Pode ser útil ao pessoal com funções de segurança de informação especializada familiarizar-se
com a ABNT NBR ISO/IEC 27002, Tecnologia da Informação – Técnicas de segurança – Código de prática
para gestão de segurança da informação. Esta Norma inclui orientação sobre o conteúdo de uma política
de segurança.
6.6.3.2 Controles de segurança da informação
Convém que os controles de segurança da informação garantam que os objetivos do gerenciamento

de segurança de informação sejam alcançados e os riscos de segurança da informação sejam
gerenciados. Controles de segurança da informação podem ser físicos, administrativos ou técnicos.

Convém que o provedor de serviços assegure que os controles estão documentados, descrevendo
seus riscos e a estratégia de mitigação de risco. Convém também que o provedor de serviços defina
as autoridades e responsabilidades para analisar criticamente os controles e a frequência de realização
da análise crítica.
Convém que o provedor de serviços também defina controles de segurança da informação para
gerenciar outras organizações externas e indivíduos que precisam acessar, usar ou gerenciar
informações ou serviços da organização.
6.6.3.3 Avaliação de riscos
Convém que o processo de GSI realize avaliações de risco regulares para identificar riscos
de segurança da informação para o ambiente de produção e, em seguida, documentar e colocar
controles em lugares específicos para evitar ou minimizar o impacto dos riscos identificados.
Adicionalmente, convém que o processo de GSI execute ou certifique-se de que avaliações de risco
adequadas foram executadas como parte do desenho e transição de serviços novos ou modificados.
Convém que a política de segurança da informação garanta que avaliações de risco de segurança
da informação:
a) sejam realizadas em intervalos acordados, incluindo serviços novos ou modificados;
b) sejam registradas e visíveis apenas ao pessoal autorizado;
c) sejam mantidas durante as mudanças nas necessidades de negócios, processos e configurações;
d) ajudem a compreender o que poderia impactar um serviço;
e) definam requisitos para auditorias de segurança da informação;
f) informem decisões sobre os tipos de controles a serem operados.
Convém que riscos para ativos de informações sejam avaliados de acordo com a natureza do risco
e o impacto potencial nos negócios.
NOTA Pode ser útil ao pessoal com responsabilidades de segurança de informação especializada
familiarizar-se com a ABNT NBR ISO/IEC 27005, Tecnologia da informação – Técnicas de segurança –
Gestão de riscos de segurança da informação.
6.6.3.4 Gerenciando riscos da segurança da informação
Convém que os controles de segurança da informação garantam que o provedor de serviço é capaz
de alcançar os objetivos de gestão de serviço e os requisitos da diretriz de segurança. Convém
também que os controles permitam ao provedor de serviços gerenciar todos os riscos de segurança
da informação identificados.
São exemplos de controles de segurança da informação os seguintes:
a) convém que a política de segurança da informação seja estabelecida, implementada

e comunicada aos funcionários, fornecedores e clientes;
b) convém que as autoridades e responsabilidades para o processo de gerenciamento

de segurança da informação sejam definidas e alocadas;

c) convém que a eficácia da política de segurança da informação seja monitorada, medida e avaliada;
d) convém que o pessoal com funções de segurança da informação significativas receba treinamento
de segurança da informação;
e) convém que a ajuda de especialistas em implementação de avaliação e controle de risco esteja

disponível;
f) convém que alterações não comprometam o funcionamento eficaz dos controles;
g) convém que informações de incidentes de segurança sejam relatadas em consonância com

o incidente e com o processo de gerenciamento de requisições de serviço e que seja atribuída
uma prioridade adequada;
h) convém que um incidente de segurança da informação seja escalado para o pessoal com
autorização adequada para resolvê-lo, dependendo da prioridade e do nível de autorização
necessário para acessar o registro do incidente de segurança;
i) convém que os detalhes de incidentes de segurança da informação sejam apenas visíveis

ao pessoal com autorização adequada;
j) convém que as avaliações de risco regulares sejam completadas de forma a identificar mudanças
à prontidão para tolerar o risco da organização;
k) convém que auditorias regulares sejam realizadas para garantir a conformidade das diretrizes
de segurança da informação estabelecidas e controles;
l) convém que linhas de base de segurança da informação sejam definidas e aplicadas de forma
efetiva;
m) convém que os resultados das auditorias de segurança da informação sejam analisados,

culminando na priorização de planos de ação;
n) convém que planos de formação e treinamento em segurança da informação tenham seus

registros criados e mantidos atualizados.
Convém que o provedor de serviços trabalhe com o processo de gerenciamento do fornecedor

para garantir que as informações de controles de segurança são identificadas, documentadas
e gerenciadas com qualquer organização externa que tenha acesso ou utiliza informações
do provedor de serviços.
6.6.3.5 Segurança da informação, mudanças e incidentes
Convém que incidente e mudanças de segurança da informação sejam processadas em conformidade

com o processo de gerenciamento de mudanças do processo de requisições de serviço.
Convém que as solicitações de mudanças sejam avaliadas para identificar os riscos de segurança
da informação novas ou modificadas como resultado da mudança proposta. Convém que o pedido
de mudança também seja avaliado frente a qualquer impacto potencial sobre serviços existentes,
processos, políticas ou controles de segurança da informação existentes.
Convém que o provedor de serviços use os resultados de análises de registros de incidentes

de segurança da informação, bem como as avaliações de segurança da informação de auditorias para
identificar possíveis deficiências e oportunidades de melhoria.

Convém que documentos e registros que sejam produzidos e mantidos pelo processo do GSI incluam:
a) uma estratégia de segurança da informação;
b) política de segurança da informação;

c) plano de segurança da informação;
d) procedimento de gerenciamento da segurança da informação;
e) relatórios de segurança da informação;
f) relatórios sobre a eficiência e eficácia da gestão do processo de segurança da informação;
g) registro de incidentes de segurança da informação;
h) avaliações de risco da segurança da informação;
i) inventário de ativos da informação.
Convém que os documentos e registros sejam analisados periodicamente para fornecer à direção
informações sobre a eficácia da política de segurança da informação. Outras características
interessantes incluem tendências de incidentes de segurança da informação, entradas para o plano
de melhoria do serviço e controle sobre o acesso aos ativos da informação e sistemas.
Convém que, além do dono do processo, gerente do processo e pessoal desempenhando procedimentos
do processo conforme descrito na Seção 4.4.2.1, autoridades e responsabilidades para o processo
de gerenciamento da segurança da informação incluam:
a) cliente, pessoal do provedor de serviços e partes interessadas que requerem acesso aos IC
e dados do gerenciamento da segurança da informação;
b) pessoal que mantém os controles de segurança da informação.
7 Processo de relacionamento
7.1 Processo de gerenciamento de relacionamento do negócio
Convém que o processo de GRN assegure que mecanismos sejam estabelecidos para gerenciar
o relacionamento entre o provedor de serviços e o(s) cliente(s). Convém que o resultado do processo
seja a melhoria da satisfação do cliente e entrega de valor agregado por meio de resultados alcançáveis.
Convém que as responsabilidades tanto do cliente como do provedor de serviços para a identificação
e priorização dos requisitos do serviço sejam claramente definidas. Convém que procedimentos sejam
definidos e seguidos para gerenciar o relacionamento contínuo entre o cliente e o provedor de serviços.
Convém que os mecanismos para gerenciar o relacionamento entre o provedor de serviços e o cliente
incluam:
a) um indivíduo designado que é responsável por gerenciar o relacionamento com o cliente

e a satisfação do cliente;

b) comunicações regulares com o cliente para permitir que o provedor de serviços compreenda
o ambiente, as necessidades e as prioridades do negócio, e os requisitos para serviços novos
ou modificados;
c) análises críticas de desempenho do serviço com o cliente em ambiente de produção.

7.1.2 Conceitos
Convém que o GRN seja um ativador-chave com relação ao desenvolvimento de um alinhamento

estratégico entre o provedor de serviços e o cliente. Convém que seja por meio do alinhamento
das necessidades e objetivos do negócio do cliente e os objetivos do provedor de serviços que o valor
agregado ao negócio seja alcançado. Convém que o processo de GRN contribua para a redução
de quaisquer barreiras percebidas ou reais entre o provedor de serviços e o seu cliente.
Convém que exista uma conexão forte entre o processo de GRN e o processo de GNS. Convém que
o processo de GNS defina e use métricas para avaliar o desempenho do nível de serviço. Convém que
o processo de GNS gerencie serviços entregues no momento e níveis de serviço no nível operacional.
Convém, por outro lado, que o processo de GRN procure trabalhar de forma aproximada com o cliente
para entender objetivos e direção futuros do cliente. Convém que, ao fazer isso, o processo de GRN
assegure que mudanças nos serviços sejam planejadas antes da necessidade do cliente. Convém que
uma boa compreensão dos objetivos do cliente permita também que o provedor de serviços ofereça
soluções alinhadas com a necessidade do negócio.
Quando grandes serviços comerciais são entregues para muitos clientes, pode ser difícil ter
um relacionamento individual com cada cliente. Por exemplo, serviços de internet usados por famílias
individuais. Neste caso, convém dar atenção à maneira que o provedor de serviço interage com vários
clientes. Pode ser usada a medição da satisfação do cliente para garantir que os serviços planejados
e entregues estejam alinhados aos requisitos do cliente.
7.1.3.1 Geral
Convém que o provedor de serviços identifique e documente seus clientes, outras partes interessadas,
fornecedores-líderes e fornecedores subcontratados de forma a compreender as dependências entre
os serviços. Por exemplo, um serviço baseado na internet é dependente de um serviço de fornecimento
seguro de um portal web com capacidade de criptografia. As partes interessadas podem incluir grupos
de usuários e unidades de negócio.
Convém que o provedor de serviços classifique seus clientes de acordo com o tipo de serviço entregue.
Clientes com características similares podem ser agrupados de forma semelhante para melhorar
eficiência e eficácia. Os processos definidos pelo provedor de serviços podem ser diferentes para
cada tipo de cliente no nível detalhado.
Convém que o provedor de serviços identifique e nomeie um indivíduo, como ponto único de contato,
responsável pelo gerenciamento do relacionamento e satisfação de cada cliente. Este indivíduo pode
ser escolhido para gerenciar o relacionamento com o cliente de forma integral ou pode ter esta função
combinada com outra função, se apropriado.
É possível à mesma pessoa desempenhar o papel de gerente do relacionamento do negócio e gerente

de níveis de serviço, devido à proximidade no relacionamento entre os processos de GRN e GNS.
Se a mesma pessoa tem os dois papéis, convém que as descrições de cargo distingam a natureza

dos dois papéis: o processo de GRN é estratégico enquanto o processo de GNS é tático. Convém que
os riscos de ter uma pessoa desempenhando dois papéis, com perspectivas tão diferentes, sejam
também gerenciados.
Convém que os mecanismos de comunicação estabelecidos com o cliente incluam reuniões ad hoc
e informais, além de reuniões formalizadas e documentadas. Convém que estas comunicações criem
um relacionamento com o cliente, identifiquem mudanças nas prioridades e objetivos do negócio

e, então, deem início à retroalimentação para o provedor de serviços para que ações sejam tomadas.
Convém que os mecanismos de comunicação ajudem na compreensão do ambiente de negócios

no qual o serviço opera, incluindo as necessidades de negócio, requisitos de clientes e mudanças
críticas. Convém que o provedor de serviços use essa informação para responder às necessidades
encontradas.
7.1.3.2 Gestão do serviço ao cliente
Convém que o provedor de serviços mantenha reuniões formais com o cliente para analisar sua
satisfação, direção estratégica e exceções importantes para o desempenho dos serviços. Convém
que estas reuniões incluam revisões dos ANS e desempenho, mudanças na organização do provedor
de serviços e mudanças na organização do cliente.
Convém que estejam presentes nas reuniões representantes de todas as partes. Convém que
as reuniões sejam agendadas com antecedência e realizadas regularmente, pelo menos anualmente.
Convém que a frequência real seja influenciada pela taxa de mudança de requisitos de serviço, grandes
projetos, como os novos serviços e a qualidade do serviço entregue. Convém que as reuniões sejam
mais frequentes do que o mínimo anual quando o provedor de serviços e o cliente estão gerenciando
uma alta taxa de mudanças ou quando existem preocupações sobre a qualidade dos serviços.
Por exemplo, um ritmo rápido de mudanças de requisitos de serviço, grandes projetos, como
os serviços novos ou modificados. Realizar reuniões de avaliação do cliente por mais de quatro
vezes por ano pode ser contraproducente quando há conteúdo suficiente para a reunião para
os representantes de gerenciamento envolvidos.
Os resultados das análises do cliente podem resultar na identificação de novos serviços ou mudanças
necessárias para os serviços existentes ou níveis de serviço. Convém que o provedor de serviços garanta
que as alterações nos ANS e contatos sejam gerenciados por meio do processo de gerenciamento
de mudança, e que sigam o processo GNS estabelecido.
Convém que seja estabelecida a rastreabilidade das exigências do cliente para mudanças de serviço.
7.1.3.3 Satisfação do cliente
Convém que o provedor de serviços estabeleça um mecanismo formal para registrar a satisfação
do cliente. Convém que a frequência e escala de qualquer medição seja acordada com o cliente
antecipadamente, e convém incluir uma amostra de usuários a serem pesquisados. Tais atividades
muitas vezes podem ser conduzidas pela central de serviço, também conhecida como suporte
de nível 1, que acompanha a solução de incidente/problema. Entretanto, para medir a satisfação
do cliente, convém que uma medida mais abrangente seja adotada, que inclua, por exemplo, número
e tipo de requisição de serviços, custo real, valor percebido e valor dos serviços entregues ao negócio.
Convém que os resultados sejam identificados, analisados e revisados, para identificar oportunidades
de melhoria.
Convém que os resultados da pesquisa de satisfação sejam medidos ao longo do tempo, de modo que
as tendências de satisfação possam ser rastreadas e quaisquer problemas ou melhorias identificados.

Convém que o procedimento documentado de atendimento de reclamações inclua registro,

investigação, ação, relatório e fechamento de quaisquer reclamações de serviço recebidas. Convém
incluir procedimentos em escala a serem usados se o cliente não concordar em aceitar as ações
propostas ou as soluções. Convém que a reclamação permaneça aberta até que o cliente concorde
formalmente que ela pode ser fechada.
Convém que o provedor de serviço entenda, defina e acorde com o cliente sobre o que constitui
uma reclamação formal de serviço. Uma reclamação formal de serviço é normalmente muito séria
e apresentada por escrito, em vez de verbalmente. Convém que uma reclamação formal de serviço
seja enviada por um gerente do cliente para um gerente do provedor de serviço. Um incidente,
ou problema, pode ser a causa de reclamações, mas não ser propriamente a reclamação.
Convém que o resultado da revisão de uma reclamação seja resumida e transmitida ao cliente,
de modo que possam ver que sua opinião foi levada a sério e ações foram tomadas.
Convém que a documentação para o processo GRN inclua;
a) uma descrição do cliente/partes interessadas, incluindo informações básicas de contato, papéis

principais, serviços consumidos;
b) uma especificação-chave para o indivíduo designado compartilhar com o cliente;
c) agenda e minutas de quaisquer reuniões entre o cliente e o provedor de serviço;
d) notas de quaisquer reuniões informais entre o cliente e o provedor de serviços;
e) resumo das métricas de serviço, mostrando o desempenho geral do provedor de serviços;
f) procedimento de atendimento a reclamações;
g) registros das reclamações e providências tomadas;
h) pesquisa e cálculo da satisfação do cliente;
i) revisão dos registros de satisfação, análise e ação;
j) resumo dos resultados da satisfação do cliente, para feedback ao cliente.
Convém que além do dono do processo, gerente do processo e pessoal que desempenha
os procedimentos do processo, como descrito na Seção 4.4.2.1, as autoridades e responsabilidades
requeridas dentro do processo GRN incluam:
a) um papel de analista de negócio, responsável por desempenhar atividades globais de satisfação

do cliente, incluindo coleta e análise de reclamações, e dados da satisfação do cliente;
b) um papel de gerente de relações do negócio, para:
1) melhorar a satisfação de cada cliente;
2) agir em nome do cliente dentro da organização do provedor de serviços;

3) estabelecer mecanismos de comunicação eficazes e eficientes entre provedor de serviços

e cliente(s);
4) conduzir as revisões de serviço com o cliente e assegurar que aperfeiçoamentos ou ações

sejam implementadas;
5) assegurar que quaisquer mudanças nas exigências do cliente se reflitam nos ANS
e em outros documentos, pelo processo de GNS;
6) ligação com o processo GNS:
7) gerenciamento de reclamações formais de serviço, para garantir que sejam resolvidas para
a satisfação do cliente;
8) assegurar que a medição da satisfação do cliente seja realizada rotineiramente e que

os resultados sejam analisados, revisados, e que sejam tomadas providências;
9) comunicar os resultados da satisfação do cliente e transmitir as ações resultantes para

o cliente, em tempo hábil;
10) assegurar que quaisquer escaladas do cliente sejam tratadas de uma maneira oportuna
e eficaz;
11) entender e planejar-se para futuras exigências do negócio.
O nome desse papel pode variar, apesar de Gerente de Relacionamento com o Negócio ser comum.
Outros possíveis títulos são gerente de relações com o cliente ou gerente de conta. Convém que
o provedor de serviços esteja ciente de que esse papel pode se fundir com outro, ou ser desempenhado
por toda uma equipe, dependendo das circunstâncias.
A fim de desempenhar esse papel de forma eficaz, convém que o provedor de serviços reconheça
a necessidade de expertise no seu próprio negócio de provedor de serviço, na tecnologia e nos
requisitos e prioridades do negócio do cliente. Convém que essa expertise também seja usada
para comunicar as exigências do cliente aos especialistas em tecnologia do provedor de serviço.
A complexidade desse papel significa atenção para detalhar e habilidade para unir múltiplas partes
e convém que sejam reconhecidas como um importante aspecto do papel. Convém que o provedor
de serviços também reconheça que essas responsabilidades estão além das capacidades de uma
posição junior no nível de admissão.
7.2 Gerenciamento de fornecedor

Convém que o propósito do processo de gerenciamento de fornecedor seja o de gerenciar

os fornecedores para garantir a provisão de serviços contínuos de qualidade. Provedores de serviços
podem usar fornecedores para operar algumas partes dos processos ou serviços, ou para suprir
componentes como hardware e software. Convém que o processo de gerenciamento de fornecedor
seja usado para todos os fornecedores. Isso inclui fornecedores que operam processos, ou partes
dos processos, para o fornecedor de serviço. O processo de gerenciamento de fornecedor também
pode ser um complemento útil para a processo GNS, para gerenciamento de grupos internos e clientes
atuando como fornecedores.
7.2.2 Conceitos
Convém que os procedimentos do gerenciamento de fornecedor assegurem que:
a) os fornecedores entendam suas obrigações para com o provedor de serviços;

b) as exigências acordadas sejam alcançadas dentro dos níveis de serviço e escopo acordados;
c) mudanças nas exigências e obrigações sejam gerenciadas;
d) transações de negócio entre todas as partes sejam registradas;

e) informação do desempenho de todos os fornecedores possa ser observada e cumprida.
f) os ANS do provedor de serviços com o cliente estejam alinhados com os contratos do fornecedor.
7.2.3.1 Gerenciamento de contratos
Convém que o provedor de serviços designe uma pessoa de contato responsável pelo relacionamento
com cada fornecedor. Convém que também sejam designados contatos entre fornecedores onde
serviços ou componentes de serviços tenham dependências.
Convém que o contrato inclua as exigências e os níveis de serviço exigidos do fornecedor. Convém
que as metas de serviço acordadas no contrato do fornecedor sejam articuladas para garantir que
os ANS do provedor de serviços com o cliente sejam cumpridos. Se os níveis do provedor de serviços
não estiverem alinhados com os ANS, convém que isso seja gerenciado como um risco, com planos
desenvolvidos para resolver o risco em tempo hábil.
Convém que todos os contratos de fornecedores contenham um programa de revisão. Convém

que pelo menos uma revisão anual seja programada. Convém que a revisão avalie se os objetivos
do negócio para terceirizar um serviço, ou um componente de serviço, permanecem válidos,
e se o fornecedor está atingindo o desempenho acordado frente às metas de serviço constantes
no contrato.
Convém que haja um processo claramente definido para gerenciamento de cada contrato. Convém que
o processo para alteração de contrato esteja também bem definido. Convém que quaisquer mudanças
nesses procedimentos sejam formalmente notificadas para todos os fornecedores afetados.
Se um contrato inclui penalidades ou bônus, convém que suas bases estejam claramente estabelecidas,
e o cumprimento das exigências e metas de serviço medido e registrado.
Quando um fornecedor está para prover parte de um serviço, convém que o provedor de serviços
garanta que o contrato com o fornecedor inclui tudo que é necessário para capacitar o cumprimento
das exigências relevantes do cliente. Convém que isso seja assegurado e documentado, antes
de assumir o compromisso com o cliente. Convém que o fornecedor também aceite que o provedor
de serviços tenha a governança dos processos de gerenciamento de serviço operados pelo fornecedor,
como descrito na Seção 4.2.
Convém que o provedor de serviços, em intervalos planejados, obtenha evidência de que o fornecedor
está cumprindo todas as exigências do contrato e de que tem processos de qualidade que efetivamente
garantem que essas exigências serão cumpridas consistentemente. Isso pode ser alcançado por meio
de auditoria do fornecedor, feita pelo provedor de serviço.
Convém que todos os resultados de reuniões, revisões e auditorias, relativos a serviço subcontratado,
sejam revisados, para identificar oportunidades de melhoria. Onde mudanças são requeridas, convém
que essas sejam controladas usando o processo de gerenciamento de mudança.

7.2.3.2 Detalhes do fornecedor
Convém que o provedor de serviços mantenha o seguinte, para cada serviço e fornecedor, mesmo
se essa informação não estiver incluída no contrato:
a) uma definição de serviços, papéis e responsabilidades;

b) escopo e capacidade do serviço;
c) exigências a serem preenchidas pelo fornecedor;
d) metas de serviço definidas e acordadas, penalidades ou consequências para metas de serviço

não cumpridas;
e) características da carga de trabalho, como número de transações, número de servidores,

ou tamanho do banco de dados;
f) critérios de exceções acordados para o ANS;
g) processo de gerenciamento de contrato, os níveis de autorização e um plano para terminar

o contrato;
h) termos de pagamento, se relevante;
i) parâmetros acordados para relatos e registros de desempenho alcançado.
7.2.3.3 Gerenciando fornecedores subcontratados
Convém que fique claro se o provedor de serviços está lidando, diretamente, com todos os fornecedores,
ou com os fornecedores principais, cada um assumindo a responsabilidade pelos fornecedores
subcontratados.
Convém que o provedor de serviços obtenha evidencia dos fornecedores principais de que esses
estão gerenciando os fornecedores subcontratados. Convém que essa relação seja orientada pelos
requisitos da ABNT NBBR ISO/IEC 20000-1. Convém que o fornecedor principal registre os nomes
de todos os fornecedores subcontratados, suas responsabilidades e relacionamentos. Convém
que essa informação esteja disponível para o provedor de serviços, se necessário. Um exemplo
de fornecedores e fornecedores subcontratados que forneçam parte de um serviço está demonstrado
na Figura 3, tirada da ABNT ISO/IEC TR 20000-3.

Organização X Organização X
Cliente A Cliente B
Provedor de serviços externo Provedor de serviços interno
Fornecedor líder Fornecedor Fornecedor líder Fornecedor
Fornecedor Fornecedor Fornecedor Fornecedor Fornecedor Fornecedor

subcontratado subcontratado subcontratado subcontratado subcontratado subcontratado
Figura 3 – Exemplo de relacionamento entre fornecedor-líder e fornecedor subcontratado
7.2.3.4 Gestão de disputas contratuais
Convém que ambos, o provedor de serviços e o fornecedor, estejam de acordo em um processo

de gerenciamento de disputas. Convém que isso seja definido ou mencionado no contrato
e implementado, se necessário. Convém que um escalonamento esteja disponível para disputas que
não possam ser resolvidas por vias normais de comunicação. Convém que o processo garanta que
disputas sejam registradas, investigadas, implementadas e encerradas formalmente.
7.2.3.5 Término de contrato
Convém que o processo de gerenciamento de contrato preveja a possibilidade de rescisão de contrato,

tanto no final previsto, como prematuramente. Convém também prever a transferência do serviço para
outra organização, ao final do contrato. Convém que as cláusulas de término de contrato deixem claras
as responsabilidades pelo encerramento ou transferência de serviço, custos, posse da propriedade
intelectual, licenças de hardware, software e dados.
Convém que uma cópia aprovada de todos os contratos do fornecedor seja mantida pelo provedor de
serviços e pelo fornecedor. Convém que os contratos incluam ou mencionem uma definição do serviço
e identifiquem os processos de gerenciamento de serviço que cobrem todos os serviços entregues pelo
fornecedor. Convém que a interface entre processos operados por múltiplas partes seja documentada.
Convém que o provedor de serviços também mantenha:
a) os nomes, responsabilidades e relacionamentos, dentro da organização de todas as partes

interessadas, incluindo o cliente, o provedor de serviços, o fornecedor principal e quaisquer
fornecedores subcontratados;
b) prova de que o provedor de serviços está formalmente gerenciando o fornecedor, incluindo

registros e ações das reuniões de revisão de contrato periódica e relatórios de quaisquer auditorias
de subcontratos;
c) prova, similar à acima, de que os fornecedores principais estão gerenciando formalmente

os fornecedores subcontratados.

Convém que, além do dono do processo, gerente do processo e pessoal desempenhando

os procedimentos do processo, como descrito na Seção 4.4.2.1, autoridades e responsabilidades
exigidas dentro do processo de gerenciamento de fornecedor incluam o seguinte:
a) Gerente de relacionamento com fornecedor, um indivíduo designado como responsável pelo

gerenciamento do relacionamento do provedor de serviço com um fornecedor específico. Isso
inclui gerenciamento do contrato e do desempenho. Convém que, quando muitas pessoas são
contratadas para essas atividades, um procedimento para assegurar que a informação sobre
o desempenho do fornecedor seja consistente, comparável, observado e posto em prática;
b) Uma pessoa de contato, definida dentro de cada fornecedor.
8 Processos de resolução
8.1 Gerenciamento de incidente e requisição de serviço
Convém que o processo de incidente e requisição de serviço gerencie incidentes e requisições

de serviço consistentemente, para garantir que a resolução de incidente ou cumprimento da requisição
sejam alcançados dentro das metas de serviço e prazos acordados.
8.1.2 Conceitos
Convém que o processo de gerenciamento de incidente e requisição de serviço possibilite

o gerenciamento eficaz e eficiente de todos os incidentes e requisições de serviço, em alinhamento
com as prioridades do negócio e cliente. Convém que os dados coletados como parte do incidente
e do processo de requisição de serviço sejam utilizados para monitorar o desempenho versus
as metas de serviço relevante. Esse dado pode ser incluído nos relatórios de serviço para o cliente.
Um incidente é considerado uma interrupção do serviço não planejada, uma redução na qualidade
de um serviço, ou uma falha de um item de configuração que não tinha ainda causado impacto
no serviço. Exemplos de requisições de serviço podem incluir mudanças-padrão, isto é, mudanças
de baixo risco, bem definidas e pré-aprovadas, pedidos de informação, pedidos de orientação
ou pedidos de acesso a serviços-padrão.
Convém que o processo de gerenciamento de incidente e requisição de serviço tenha suporte

de dois procedimentos documentados separados. O primeiro é para o gerenciamento de incidentes;
o segundo, para o gerenciamento de requisições de serviço. Convém que os dois procedimentos
definam o seguinte:
a) um registro consistente dos incidentes e requisições de serviço;
b) a prioridade e a classificação de incidentes e requisições de serviço baseadas nas metas

e serviços documentados e acordados;
c) atividades necessárias para resolver incidentes e cumprir as requisições de serviço, como

detalhado nos parágrafos abaixo;
d) as ações necessárias para atualizar e fechar incidente e registros de requisição de serviço, quando
da confirmação do usuário de que o incidente foi resolvido ou a requisição de serviço cumprida;

e) escalonamento, se apropriado, para assegurar a resolução ou cumprimento de cada incidente

ou requisição de serviço, de acordo com os níveis de serviço acordados.
Convém que os procedimentos para incidente e requisições de serviço incluam a comparação
de incidentes versus erros e problemas conhecidos, e das requisições de serviço versus o catálogo
de serviços.

8.1.3.1 Recebimento e registro de incidentes e requisições de serviço
Convém que os procedimentos para o processo de gerenciamento de incidente e requisição de serviço
definam o mecanismo de recebimento e registro de incidentes e requisições de serviço. Convém que
isto assegure:
a) uma abordagem consistente para execução;
b) o armazenamento e a recuperação de dados como exigido por uma organização;
c) que os canais de comunicação e os métodos apropriados sejam usados e estejam disponíveis,
tanto dentro das horas de serviço acordadas como fora desse horário.
Convém que todos os incidentes e requisições de serviço sejam classificados de modo que sejam
colocados em prática, de acordo com a prioridade e com o compromisso de meta de serviço. Convém
que a classificação por incidente ou tipo de requisição de serviço inclua a determinação de quais
IC são impactados, o que, por sua vez, pode ajudar a identificar o pessoal que talvez precise ser
envolvido na resolução ou realização.
Convém que a prioridade seja acordada com o cliente no recebimento do incidente ou da requisição
de serviço, ou logo que possível. Convém que a determinação de prioridade seja baseada na avaliação
do impacto e urgência do incidente ou da requisição do serviço em questão.
Convém que incidentes e requisições de serviço sejam avaliados por possíveis implicações
de segurança e determinação sobre se convém que sejam implementados procedimentos de
resposta a incidentes de segurança, além da resposta operacional normal. Por exemplo, convém que
o pessoal operacional tenha procedimentos estabelecidos para determinar se convém que o pessoal
de segurança da informação ou autoridade legal sejam contactados.
Convém que uma matriz de prioridades, baseada em impacto e urgência, seja desenvolvida tanto
para incidentes como para requisições de serviço, como parte das discussões e acordo das metas
de serviço. Um exemplo da meta de prazo para resolução de incidentes baseada em prioridade está
demonstrado na Tabela 1. Convém que os princípios gerais de metas, que se baseiam em cada uma
das diversas categorias sejam adotados tanto para incidentes como para requisições de serviço.
Tabela 1 – Matriz-exemplo de resolução de incidentes resolvidos nos prazos baseada

em prioridades
Impacto
Urgência Crítico Alto Médio Baixo
P1: Resolução P2: Resolução P3: Resolução P4: Resolução
Alta
em 2 horas em 4 horas em 1 dia em 2 dias
Média
em 4 horas 1 dia 2 dias em 3 dias
Baixa
em 1 dia em 2 dias em 3 dias em 5 dias

A Tabela 1 é para incidentes, porém requisições de serviço podem ter prazos diferentes e exigir uma
tabela separada.
8.1.3.2 Ciclo de vida de incidente e requisição de serviço, e uso de dados
Convém que o que se segue seja definido como parte do processo de gerenciamento de incidente
e requisição de serviço:
a) identificação das fontes de entrada de incidentes e requisições de serviço;
b) responsabilidades pela criação e atualização de registros de incidentes e requisições de serviço;
c) uso de fontes de informação apropriadas, por exemplo, o BDGC, um banco de dados de erros
conhecidos, o catálogo de serviços ou outros documentos e registros relevantes;
d) relacionamento/interface com o processo de gerenciamento de problema;
e) regras para escalonamento, incluindo gatilhos, do tipo funcional e hierárquico, e autoridade

a ser invocada;
f) interface com processo de gerenciamento de mudança, quando uma requisição de mudança

for usada para permitir a resolução de incidentes ou para cumprir requisições de serviço;
g) responsabilidade pela verificação da resolução do incidente, ou cumprimento da requisição

de serviço;
h) a política e abordagem para fechamento do incidente ou requisição de serviço, isto é, convém

que o processo busque uma confirmação, do usuário ou cliente, da recuperação efetiva e, então,
atualizar o registro e, finalmente, registrar um status de fechamento.
Sem confirmação da recuperação efetiva, pelo usuário ou cliente, o provedor de serviços pode fazer
uma suposição inadequada de que o incidente foi resolvido ou que a requisição de serviço foi cumprida.
8.1.4 Procedimento para incidente crítico
Convém que o processo de gerenciamento de incidente e requisição de serviço inclua um procedimento

documentado especificamente para lidar com incidentes críticos. Um incidente crítico geralmente
impõe maior impacto e atenção especial para resolvê-lo.
Convém que os procedimentos para incidentes crítico s definam:
a) o que constitui um incidente crítico;
b) quem tem autoridade para declarar que se trata de um incidente crítico e como será declarado;
c) quem convém coordenar e controlar as atividades e quem convém estar envolvido;
d) como os esforços para resolução serão conduzidos.
e) quais comunicações convém serem fornecidas durante os incidentes críticos;
f) qual o formato, prazo e participantes necessários para uma revisão de incidente crítico, após
a resolução;
g) as interfaces com o processo de gerenciamento de continuidade de serviço e de disponibilidade,

caso seja necessário invocar continuidade de serviço.

Convém que os documentos e registros que sejam produzidos e retidos pelo processo de gerenciamento
de incidente e requisição de serviço incluam:
a) procedimentos de gerenciamento de incidente e requisição de serviço;

b) registros de incidente;
c) registros de requisição de serviço;
d) registros de incidente, incluindo avaliação dos incidentes críticos e planos de ação;
e) relatos sobre incidente e requisições de serviço ao longo de um determinado período de tempo;
f) relatos de desempenho para resolução de incidente e cumprimento de requisição de serviço,

incluindo casos em que as metas tenham sido excedidas ou não cumpridas;
g) relatos estatísticos sobre os tipos de chamados, fechamento de chamados, classificações, volume

de falhas;
h) relatos de exceções para incidentes e requisições de serviço manejados de forma incorreta, onde
fatores de qualidade podem incluir categorias como as classificadas incorretamente, ajustes de
prioridades, escalonamentos, reabertura de incidentes e registros de requisição de serviço com
dados incorretos;
i) incidentes passados para o processo de gerenciamento de problema, para investigação

do problema;
j) quaisquer possíveis melhorias que tenham sido identificadas, ou onde uma ação tenha sido
tomada.
Convém que além do dono do processo, gerente do processo e do pessoal que desempenha
os procedimentos do processo, como descrito na Seção 4.4.2.1, autoridades e responsabilidades
necessárias dentro do processo de gerenciamento de incidente e requisição de serviço incluam
as listadas abaixo:
a) Gerente de incidente crítico, responsável pela invocação do processo de gerenciamento

de incidente crítico, a equipe de resposta e identificação de papéis e pessoal necessário para
cada incidente crítico;
b) Suporte de nível 1, que atua no papel de comunicador, para reunir dados do sintoma inicial,
e das comunicações contínuas com o usuário final;
c) Grupos de resolução, que podem ser designados como suporte de nível 2 e nível 3. Para esses
grupos seriam designados os incidentes escalados para diagnóstico e resolução, e tipicamente
teriam capacidade técnica e experiência superior a do pessoal de suporte nível 1;
d) Grupos de fornecimento de serviços, para os quais podem ser designadas tarefas que ajudem
na conclusão de cada requisição de serviço;

e) Fornecedores externos e vendedores que possam oferecer serviços como os definidos

nos contratos de apoio e acordos.
8.2 Gerenciamento de problema

O processo de gerenciamento de problema identifica o desconhecido, subjacente à causa-raiz

dos incidentes, e propõe resoluções permanentes por meio do processo do gerenciamento
de mudança. O processo de gerenciamento de problema também previne a ocorrência de incidentes
proativamente mediante análise de tendência e recomendações de ações preventivas.
8.2.2 Conceitos
Convém que o processo de gerenciamento de problema investigue a causa-raiz de incidentes. Convém

que o processo de gerenciamento de problema minimize ou evite o impacto de incidentes e problemas
por meio da proposição permanente de soluções mediante processo de gerenciamento de mudança.
Convém que o processo de gerenciamento de problema também produza e monitore os registros

de erros conhecidos, incluindo resoluções temporárias, uma vez que a causa-raiz subjacente tenha
sido identificada. Os registros de erros conhecidos podem ser usados para garantir a eficiência,
a resolução de incidentes e o aprendizado organizacional.
Convém que o processo de gerenciamento de problema tenha um escopo definido e que determine
os métodos do gerenciamento de problema usados. Pode ser útil ter uma política de gerenciamento
de problema que possa definir os critérios para a priorização e investigação de problemas.
O foco primário do processo do gerenciamento de problema para muitas organizações é baseado

em incidentes que já tenham ocorrido. Pode haver um grande benefício para a organização
em encontrar resoluções permanentes para os problemas de alto impacto e alto risco, e que, por sua,
vez podem habilitar os serviços a serem mais confiáveis, de custos efetivos e eficientes.
Uma vez que o ambiente tenha ficado mais confiável como resultado das atividades do gerenciamento
de problemas, pode ser possível que o pessoal gaste mais tempo no gerenciamento proativo
de problemas. Convém que as atividades proativas do gerenciamento de problemas foquem
em prevenir incidentes e a sua recorrência, em primeiro lugar. Por exemplo, identificar um ponto único
de falha para um serviço crítico para o negócio e propor uma redundância para prevenir que qualquer
incidente futuro impacte o cliente.
Convém que o processo de gerenciamento de problema inclua os procedimentos listados abaixo.
a) Identificação do problema, incluindo:
1) detecção de uma causa-raiz desconhecida de um ou mais incidentes;
2) a análise de um ou mais incidentes revelando um problema subjacente;
3) uma notificação de um fornecedor ou de um grupo interno referente a um problema com

um componente do serviço.
b) Registro de problemas, para assegurar que cada problema é registrado. Convém que os registros
incluam detalhes relevantes do problema, incluindo data e hora, e uma referência cruzada ao(s)
incidente(s) que iniciou(ram) o registro do problema.

c) Convém que a classificação e a priorização de problemas assegurem que:
1) cada problema seja categorizado para ajudar a determinar sua natureza e para prover
informações significativas, fazendo uso dos mesmos critérios de classificação que são
utilizados nos processos de gerenciamento de incidentes e solicitações de serviço;
2) a cada problema, seja dada uma prioridade para a resolução de acordo com a urgência
e o impacto dos incidentes relacionados;
3) tempo e recursos para investigação do problema e a identificação das melhores opções para
resolução sejam alocados de acordo com a prioridade do problema;
4) para a resolução do problema, tempo e recursos são alocados de acordo com a prioridade do
problema e o benefício de efetuar a mudança de modo que satisfaça os requisitos de serviço.
d) Convém que a investigação e o diagnóstico de problemas assegurem que:
1) cada problema seja investigado para diagnosticar a causa-raiz;
2) um método de resolução possa ser identificado, o que depende do impacto do(s) incidente(s)
relacionado(s) e potenciais incidentes, se existem ou não soluções temporárias e o custo
estimado da resolução;
3) uma decisão de resolver o problema depende do impacto dos incidentes relacionados,

se uma solução temporária existe e o custo da resolução;
4) uma decisão de não resolver o problema seja gerenciada de acordo com a política
de gerenciamento de problemas;
5) o processo de gerenciamento de problema seja capaz de suportar os processos

de gerenciamento de incidentes e solicitações de serviço, mesmo antes do erro conhecido
ser encontrado, por meio da identificação de uma solução temporária;
6) o diagnóstico de problemas estará completo quando a causa-raiz for identificada e um método

de resolução do problema tenha sido identificado.
f) Convém que o progresso de todos os problemas seja registrado para:
NOTA BRASILEIRA Foi mantida a letra f), que deveria ser e) de forma a manter fidelidade ao documento
original ISO/IEC 20000-2:2012.
1) acompanhar o progresso por meio do processo de gerenciamento de problema, incluindo

detalhes da pessoa responsável atualmente por progredir o problema;
2) registrar todos os recursos utilizados e as ações tomadas.
g) convém que o escalonamento do problema assegure que todas as dificuldades sejam escaladas
para as partes apropriadas, incluindo:
1) identificação de incidente(s) relacionado (s) que esteja(m) violando metas de serviço;
2) informações progressivas para o cliente, para que eles possam tomar as ações apropriadas
para minimizar o impacto do problema não resolvido;

3) permitir à central de serviços ou ao nível 1 de suporte prover atualizações regulares para

os usuários ou clientes afetados;
4) definir os pontos de escalonamento.
h) Convém que, ao documentar erros conhecidos, se assegure que:

1) quando a causa-raiz e o método proposto de resolução do problema for identificado,

um erro conhecido seja gravado no banco de dados de erros conhecidos, juntamente com detalhes
de qualquer solução temporária;
2) um registro de erro conhecido não seja fechado até que a solução definitiva seja implementada
com sucesso por meio do processo de gerenciamento de mudanças;
3) registros de erros conhecidos estejam disponíveis para todo o pessoal relevante e que estes
sejam regularmente avisados de qualquer registro de erro conhecido novo ou atualizado;
4) se um registro de erro conhecido permanece aberto por um período definido de tempo,

ele precisa ser revisado e mantido atualizado, para que nenhuma informação obsoleta seja
mantida no banco de dados de erros conhecidos;
5) todos os erros conhecidos sejam registrados e associados aos serviços atuais, aos
potencialmente afetados e ao item de configuração suspeito de estar em falha.
i) Convém que o fechamento do registro de problemas, quando o erro conhecido tiver sido identificado
e registrado, assegure que:
1) detalhes da resolução foram registradas precisamente;
2) o registro do problema foi comparado com quaisquer incidentes relacionados para facilitar
a análise;
3) a causa-raiz foi categorizada para facilitar análises.
j) Convém que as revisões de problemas críticos realizadas para investigar problemas não resolvidos,
incomuns ou problemas de alto impacto, assegurem que:
1) riscos para o negócio, o cliente ou fornecedor de serviços sejam identificados e gerenciados;
2) existe visibilidade de gerenciamento para as causas dos problemas não resolvidos, bem como
seu impacto nos negócios em andamento.
k) Convém que as revisões de problemas sejam registradas e que incluam recomendações

apropriadas para melhorias no serviço. Convém que elas examinem:
1) oportunidades para melhorar o processo de gerenciamento de problema;
2) oportunidades para melhorar outros processos, serviços ou o SGS;
3) como prevenir a recorrência ou um tipo particular de problema;
4) se convém que o treinamento ou a conscientização sejam providos para corrigir ou prevenir

incidentes causados por falha humana;

5) se houve qualquer responsabilidade por parte de fornecedores, clientes ou grupos internos

pelos problemas que ocorreram e se quaisquer ações de acompanhamento são requeridas.
l) Convém que o gerenciamento proativo de problemas assegure que:
1) dados de incidentes e problemas, o BDGC e outras fontes de informação relevantes sejam

analisados para identificar tendências;
2) dados de incidentes e problemas, o BDGC e outras fontes de informação relevantes possam

ser usados para melhorar a tomada de decisão e auxiliar a prever possíveis degradações
do serviço;
3) o conhecimento adquirido a partir de uma revisão de um problema seja comunicado

ao cliente, para garantir que o cliente esteja ciente das medidas tomadas e as recomendações
de melhorias de serviço identificadas;
4) medições-chave que demonstrem que o valor para o negócio na gestão proativa de problemas
estão definidas;
5) potenciais pontos únicos de falhas, tendências e riscos emergentes são identificados e opções
são propostas por meio do processo de gerenciamento de mudança.
Convém que os documentos e registros, que são produzidos e retidos pelo gerenciamento de problema,
incluam:
a) procedimentos do gerenciamento de problema;
b) registros de problemas;
c) registros de erros conhecidos;
d) detalhes de resoluções temporárias;
e) links com mudanças que resultem em resoluções permanentes;
f) registros de revisões de problemas, incluindo minutas de reuniões de revisão de problemas;
g) relatos de gerenciamento, incluindo informações de tendência de incidente e problema;
h) recomendações para melhoria no serviço.
Uma política de gerenciamento de problema pode ser útil para facilitar e suportar o gerenciamento
de problema.
Convém que, além do dono do processo, gerente do processo e do pessoal que executa
os procedimentos do processo, conforme descrito na Seção 4.4.2.1, autoridades e responsabilidades
requeridas no processo de gerenciamento de problemas incluam:
a) o pessoal que realiza a análise de causa-raiz dos problemas, determina a resolução e/ou solução
temporária e cria o registro de dados do erro conhecido associado;
b) fornecedores, clientes ou grupos internos envolvidos em prover soluções, resoluções temporárias,

informações de erros conhecidos, aconselhamentos e revisões.

9 Processos de controle
9.1 Gerenciamento de configuração

Convém que o processo de gerenciamento de configuração inclua identificação, controle, registro,

rastreamento, relatórios e verificação de itens de configuração e o gerenciamento das informações
dos IC no BDGC. Convém que o processo de gerenciamento de configuração estabeleça e mantenha
a integridade de informações sobre serviços identificados, componentes dos serviços e IC ao longo
de todo o ciclo de vida do serviço. Convém, também, que o processo de gerenciamento de configuração
identifique, gerencie e verifique as informações sobre os relacionamentos entre IC, bem como
os relacionamentos entre os IC e os serviços que eles suportam.
Convém que o escopo do processo de gerenciamento de configuração exclua o gerenciamento

de ativos financeiros, mas inclua uma interface para o processo de gerenciamento de ativos financeiros.
9.1.2 Conceitos
Convém que o processo de gerenciamento de configuração forneça um ponto focal para o gerenciamento
e controle dos ativos de serviço envolvidos e configurações, bem como seus relacionamentos. Convém
que inclua atividades para planejar e executar o processo de gerenciamento de configuração.
Convém que o gerenciamento de configuração documente a definição de cada tipo de IC e identifique

cada IC de acordo com a política de gerenciamento de configuração e procedimentos. Convém
que a informação registrada para cada IC garanta o controle efetivo de cada IC e suas informações
de configuração associadas.
Informações de configuração são registradas em um BDGC que inclui dados sobre os itens
de configuração, versões, relacionamentos, linhas de base e liberações. Convém que a informação
de cada IC inclua um identificador, descrição, estado, localização, seus relacionamentos e
registros associados, como solicitações de mudanças, incidentes, problemas e registros de erros
conhecidos. Convém que as informações de configuração sejam mantidas por indivíduos autorizados
e disponibilizadas apenas para as partes interessadas autorizadas.
9.1.3.1 Atividades do Gerenciamento de Configuração
Convém que o planejamento para o processo de gerenciamento de configuração permita ao provedor

de serviços alcançar um grau de controle que seja suficiente para:
a) cumprir os requisitos acordados com o cliente, usuário, provedor de serviços e outras partes
interessadas;
b) assegurar que os ativos, incluindo licenças, usados para fornecer serviços são gerenciados de
acordo com os requisitos estatutários e regulatórios e as obrigações contratuais;
c) assegurar que a integridade da informação sobre serviços e componentes de serviços seja

mantida;
d) manter as informações de configuração registradas para assegurar a sua confiabilidade e exatidão.

9.1.3.2 Recursos e capacidades
Convém que o processo de gerenciamento de configuração seja planejado para assegurar que haja
recursos e capacidades suficientes para implementação e manutenção dos registros dos IC envolvidos.
Convém que o escopo da política e do processo de gerenciamento de configuração inclua:
a) planejamento do escopo do processo de gerenciamento de configuração alinhado com o SGS

e o escopo do processo de gerenciamento de mudanças;
b) a definição de cada tipo de IC e seus relacionamentos com outros IC e componentes de serviço;
c) autorização para acessar e controlar mudanças nos IC;
d) procedimentos documentados para identificar, registrar, controlar e rastrear as versões e o status

dos IC;
e) a localização e condições de armazenamento para os IC físicos e, no caso de informação, meios

de armazenamento, em conformidade com os níveis designados de integridade e segurança;
f) os critérios ou eventos para iniciar o controle de configuração e manutenção de linhas de base

das configurações envolvidas;
g) um procedimento documentado, incluindo as autoridades e responsabilidades para planejamento

e condução de auditorias, que relate os resultados e mantenha registros de auditoria;
h) planejamento para a remoção, arquivamento, cessão ou transferência de dados relativos aos IC,
em conformidade com os requisitos estatutários e regulatórios e as obrigações contratuais;
i) automação suficiente para garantir um controle eficaz, por exemplo, para reduzir as oportunidades
de erro humano.
9.1.3.3 Identificação e definição dos IC
Convém que o planejamento inclua a identificação e definição dos tipos de IC que estão sujeitos
ao controle do processo de gerenciamento de configuração. Convém que os IC sejam escolhidos
usando critérios de seleção estabelecidos, agrupados, classificados e identificados de tal maneira que
eles sejam gerenciáveis e rastreáveis em todo o seu ciclo de vida.
Convém que cada serviço seja classificado ou segregado em grupos logicamente relacionados
e subordinados dos componentes constituintes de serviços que permitam:
a) a partes interessadas encontrar e utilizar as informações de configuração que elas estão

autorizadas a utilizar;
b) um entendimento comum entre as partes interessadas de como as informações sobre IC e seus

relacionamentos são gerenciados;
c) que o pessoal envolvido em todos os processos de gerenciamento de serviços tenha acesso

ao BDGC, à política de gerenciamento de configuração e a procedimentos que sejam requeridos
ou úteis para ajudá-lo a cumprir seu papel;
d) ao provedor de serviços implementar acesso de edição ao BDGC exclusivamente para o pessoal

com os níveis corretos de autoridade e prover acesso de leitura a todos os outros.

Convém que IC sejam claramente identificados por identificadores únicos, duráveis ou marcações,
se for o caso. Convém que os identificadores estejam em conformidade com os padrões e convenções
relevantes, de modo que todos os itens de configuração sob o controle do processo de gerenciamento
de configuração sejam rastreáveis, de forma inequívoca, com as suas especificações, ou equivalentes,
descrições documentadas. Convém que haja uma lista dos IC e uma definição da informação a ser
registrada para cada IC. Convém que relacionamentos apropriados e dependências entre os IC sejam
identificados para prover o grau necessário de visibilidade e controle.
9.1.3.4 Tipos de IC
Convém que os tipos de IC incluam:
a) serviços constantes no catálogo de serviços e as suas informações e documentos relacionados,

por exemplo, ANS, acordos, contratos, requisitos de serviço, especificação de desenho de serviço;
b) componentes de serviços, incluindo hardware, software e licenças, ferramentas, aplicações,

documentação, serviços de apoio;
c) todas as questões e liberações de serviços, sistemas e bases de referência de configuração

de software ou criar instruções para cada ambiente aplicável e hardware padronizado
de construção, por exemplo, imagem de uma configuração de hardware;
d) cópias originais de IC armazenados em bibliotecas físicas e/ou eletrônicas, o BDGC e ferramentas

utilizadas;
e) informação de segurança dos ativos;
f) ativos que precisam ser rastreados pelo gerenciamento de ativos financeiros ou em razões
de negócio, por exemplo, mídias magnéticas seguras, equipamentos;
g) documentação do SGS, por exemplo, políticas, documentação de processos, procedimentos

e planos.
h) Convém que cada tipo de IC tenha a informação associada no BDGC ou em documentos

integrados ou registros.
9.1.3.5 Manutenção dos IC
Convém que a execução de atividades do gerenciamento de configuração inclua manter informações

sobre os IC e seus relacionamentos com um nível apropriado de integridade e segurança.
Convém que os procedimentos de controle de configuração assegurem que somente tipos

de IC acordados e identificáveis e registros sejam aceitos e mantidos em um ambiente adequado
e seguro. Convém que nenhum IC seja adicionado, modificado, substituído ou removido/retirado, sem
documentação de controle apropriada, por exemplo, uma requisição de mudanças aprovada. Convém
que o estado de evolução do IC ao longo de seu ciclo de vida seja documentado como uma linha
de base em tempos ou em circunstâncias definidos. Convém que a justificativa para a linha de base
seja registrada. Convém que registros de configuração sejam mantidos durante todo o ciclo de vida
de um IC e arquivados ou removidos de acordo com a política de gerenciamento de configuração.
Convém que, para proteger a integridade dos sistemas, serviços e infraestrutura, os registros dos IC
e o BDGC sejam guardados em um ambiente adequado e seguro. Convém que este ambiente os proteja
de acesso não aprovado, mudanças ou corrupção do BDGC. Também convém que haja um meio para

recuperação de desastres do BDGC e um método que permita a recuperação controlada de uma

cópia-mestra controlada, por exemplo, software, mídia eletrônica.
Convém que as atividades de auditoria de configuração sejam realizadas a intervalos planejados

e em resposta a eventos específicos. Convém que procedimentos e recursos adequados estejam
no local para:
a) verificar se o provedor de serviços tem o controle da informação sobre todos os IC e seus

relacionamentos dentro do escopo do processo;
b) verificar se o provedor de serviços tem o controle de informações sobre a localização

e a quantidade de licenças de software;
c) assegurar que as informações de configuração estão precisas, controladas e visíveis para

o pessoal autorizado;
d) identificar a causa de discrepâncias entre as informações de configuração atuais e esperadas

e resolver, em coordenação com o processo de gerenciamento de mudanças;
e) assegurar que uma linha de base de configuração seja feita a intervalos regulares e pelo menos
antes da implementação de uma liberação no ambiente de produção;
f) garantir a confidencialidade e acessibilidade da informação no CMDB.
Convém que os documentos e registros produzidos e mantidos pelo processo de gerenciamento

de configuração incluam:
a) uma política de gerenciamento de configuração;
b) procedimentos para o processo de gerenciamento de configuração;
c) informação atualizada e exata sobre os IC e seus relacionamentos com outros IC, componentes
de serviço e serviços;
d) definições de tipo de IC;
e) linhas de base de configuração;
f) relatórios de gerenciamento de configuração;
g) relatórios de auditoria de configuração;
h) um procedimento documentado especificando frequência e teste de backups do BDGC.
Convém que, além do dono do processo, gerente do processo e pessoal que executa os procedimentos
do processo, conforme descrito na Seção 4.4.2.1, as autoridades e responsabilidades requeridas para
o processo de gerenciamento de configuração incluam:
a) o cliente, os usuários, pessoal do provedor de serviços e partes interessadas com acesso

autorizado à informação de configuração;

b) o pessoal que mantém o BDGC;

c) responsável ativo ou proprietário do IC que assegure que as atualizações referentes à situação
dos IC sejam providas;
d) fornecedores internos e externos de ativos e IC.
9.2 Gerenciamento de mudanças

Convém que o processo de gerenciamento de mudanças gerencie as mudanças durante todo o seu
ciclo de vida, assegurando que todas as mudanças sejam avaliadas, aprovadas, implementadas
e revisadas de forma controlada.
9.2.2 Conceitos
O processo de gerenciamento de mudanças provê uma abordagem estruturada para a efetiva
implementação das mudanças, minimizando o risco e, idealmente, prevenindo incidentes causados
por mudanças não gerenciadas ou mal gerenciadas.
Convém que, para permitir a visibilidade e o controle requeridos, todas as solicitações de mudanças
sejam registradas e classificadas. Convém que uma programação de mudanças, contendo detalhes
sobre as mudanças aprovadas para desenvolvimento e as suas datas propostas para implementação,
seja estabelecida e comunicada às partes interessadas e atualizada conforme necessário.
Exemplos típicos de tipos de solicitações de mudanças são dados abaixo.
a) Mudança emergencial: uma mudança que convém ser implementada o mais rápido possível. Por
exemplo, para resolver um incidente crítico ou implementar um pacote de segurança da informação.
b) Mudança normal: qualquer mudança de serviço planejada, que não é uma mudança-padrão ou
uma mudança emergencial.
c) Mudança-padrão: uma mudança pré-autorizada que é de baixo risco, relativamente comum e que
segue um procedimento ou instrução de trabalho.
Mudanças normais podem ser categorizadas como principais, significativas e menores, dependendo
do nível de custos e riscos envolvidos. Esta categorização pode ser relacionada a e utilizada para
identificar uma autoridade de mudança apropriada, uma pessoa com autoridade para essa categoria
de mudança.
Convém que procedimentos sejam documentados e usados para controlar o registro, a classificação,
avaliação, aprovação, o planejamento, desenvolvimento, teste e a implementação de todas
as mudanças.
Após o sucesso da implementação de mudanças, convém que o processo de gerenciamento de
mudanças informe ao processo de gerenciamento de configuração que o BDGC deve ser atualizado
para refletir a mudança no ambiente.
9.2.3.1 Política de gerenciamento de mudanças
Convém que uma política de gerenciamento de mudanças que defina os IC sob o controle do processo
de gerenciamento de mudanças seja estabelecida e documentada. Convém que todas as solicitações
de mudanças de IC, definidas na política de gerenciamento de mudanças dentro do escopo
do processo de gerenciamento de mudanças, sejam gerenciadas pelo processo.

Convém que mudanças com o potencial de causar um grande impacto nos serviços ou no cliente
sejam classificadas de acordo com critérios definidos em uma política de gerenciamento de mudanças.
Convém que essas mudanças sejam gerenciadas usando o processo de desenho e transição
de serviços novos ou modificados e coordenadas com o processo de gerenciamento de mudanças.
Convém que a política de gerenciamento de mudanças defina critérios para determinar quais
mudanças convêm ser gerenciadas por meio do processo de gerenciamento de mudanças e quais
mudanças convêm ser gerenciadas por meio do processo de desenho e transição de serviços novos
ou modificados.
Convém que os critérios utilizados para determinar as mudanças a serem gerenciadas por meio
do processo de desenho e transição de serviços novos ou modificados incluam mudanças para
a remoção de um serviço e mudanças para a transferência de um serviço do provedor de serviços
para outra parte. A outra parte pode ser o cliente ou um fornecedor.
9.2.3.2 Planejamento e implementação
Convém que as solicitações de mudanças tenham um escopo documentado e sejam classificadas

de acordo com critérios definidos e acordados. Convém que solicitações de mudanças sejam avaliadas
e aprovadas antes do desenvolvimento ou construção, levando em conta os riscos, impactos para
os serviços e o cliente, ramificações financeiras, benefícios de negócio e viabilidade técnica.
Convém que o gerenciamento da construção, teste e implementação de mudanças seja coordenado

com o processo de gerenciamento de configuração e o processo de gerenciamento de liberação
e implementação.
Convém que as atividades necessárias para reverter ou remediar uma mudança mal sucedida sejam
planejadas e testadas. Convém que a mudança seja revertida ou remediada se malsucedida. Convém
que mudanças malsucedidas sejam investigadas e ações adequadas sejam tomadas.
Convém que uma programação de mudanças, com detalhes sobre as mudanças aprovadas para
desenvolvimento e as suas datas propostas para implementação, seja estabelecida e comunicada
às partes interessadas, por exemplo, suporte nível 1; gerenciamento de relacionamento com o negócio,
gerenciamento de fornecedores.
Convém que o processo e os procedimentos de gerenciamento de mudanças assegurem que:
a) mudanças tenham um escopo claramente definido e documentado, que identifique os itens

de configuração impactados;
b) a tomada de decisão sobre a aceitação e aprovação de solicitações de mudanças leve

em consideração os riscos, prioridades, impactos potenciais para os serviços ou cliente,
os requisitos do serviço, benefícios de negócio, viabilidade técnica e impacto financeiro;
c) uma programação de mudanças, que contenha detalhes das mudanças aprovadas e suas datas
propostas de implementação, seja estabelecida;
d) a programação de mudanças seja comunicada às partes interessadas;
e) a programação de mudanças seja usada para planejar a implementação das liberações;

f) mudanças aprovadas para os serviços identificados e itens de configuração sejam desenvolvidos

e testados de acordo com a programação de mudanças;
g) mudanças sejam implantadas de acordo com a programação de mudanças;
h) atividades para reverter ou remediar uma mudança malsucedida sejam planejadas e testadas;
i) mudanças malsucedidas sejam revertidas ou remediadas e as razões para o insucesso

da mudanças sejam documentadas e investigadas;
j) o BDGC seja atualizado após a implementação, independentemente do sucesso ou fracasso
dessa mudança.
9.2.3.3 Revisão da requisição de mudança
Convém que solicitações de mudanças registradas sejam analisadas a intervalos planejados para
identificar os níveis crescentes de mudanças, tipos que se repetem com frequência, tendências
emergentes e outras informações relevantes. Convém que os resultados e conclusões retiradas
da análise das mudanças sejam registrados e usados para identificar oportunidades de melhoria.
Convém que qualquer não conformidade seja registrada e ações sejam tomadas.
Convém que quaisquer deficiências ou fraquezas identificadas no processo de gerenciamento
de mudanças como resultado de uma análise de uma requisição de mudança individual sejam
incorporadas aos planos de melhoria.
Convém que, depois que a alteração tenha sido implantada e aceita a requisição de mudança seja
fechada. A requisição de mudança também pode ser fechada quando a decisão de não realizar
a mudança for tomada. Convém que, quando a requisição de mudança for fechada, o resultado
da mudança seja relatado ao iniciador da requisição de mudança e a outras partes interessadas.
9.2.3.4 Mudanças emergenciais
Convém que mudanças emergenciais sejam diferenciadas de outras mudanças, devido ao risco
ampliado e ao aumento frequente nos custos de aprovação e execução.
Convém que, para mudanças emergenciais, haja um processo definido que inclua disposições para
aprovação e pós-implementação de documentação e análise. Convém que mudanças emergenciais
sejam aprovadas por uma autoridade de mudança apropriada e, se possível, comunicadas às partes
interessadas.
Mudanças emergenciais podem ser usadas para resolver situações emergenciais onde não há tempo
suficiente para aderir aos procedimentos de uma mudança normal. Quando possível, convém que
o processo completo de mudança seja seguido. Entretanto, de acordo com a urgência de se implementar
uma mudança emergencial, alguns detalhes podem ser documentados retrospectivamente e alguns
testes podem não ser possíveis. Mesmo que alguns desses passos sejam evitados para comportar
a urgência dessa emergência, convém que haja um plano de remediação ou reversão da mudança
emergencial, caso não haja sucesso. Onde o procedimento de emergência se desviar de outros
requisitos do gerenciamento de mudança, por exemplo, testes incompletos anteriores a implementação,
convém que a mudança esteja de acordo com esses requisitos assim que possível. Convém que
mudanças emergenciais sejam justificadas pelo implementador e analisadas após a mudança, para
verificar se essa era realmente uma mudança emergencial necessária.
Convém que os documentos, incluindo registros, produzidos e retidos sejam:
a) política de gerenciamento da mudança;

b) documentação e procedimentos do processo de gerenciamento de mudança, incluindo

o procedimento de mudança emergencial e padrão;
c) uma lista de mudanças-padrão aprovadas;
d) uma agenda de mudanças;

e) registros de solicitações de mudanças e outras informações relacionadas, por exemplo, avaliação

de risco, plano de remediação, plano de liberação;
f) relatos de eficiência e efetividade do processo de gerenciamento de mudança;
g) relatos de gerenciamento de mudança, incluindo avaliações pós-implementações.
Convém que os registros de mudanças associados a cada requisição de mudança sejam registrados
em um log de mudanças. Se a organização tem um BDGC, convém que o registro de mudanças seja
associado ao IC relevante por meio de um link para o registro do IC. Idealmente, convém que esse
link entre o registro de mudança e o IC relevante ou IC seja visível no momento em que a requisição
de mudança é registrada, até sua aprovação e implementação.
Convém que, além do dono do processo, gerente do processo e o pessoal que desempenha
os procedimentos do processo, como descrito na Seção 4.4.2.1 autoridades e responsabilidades
requeridas para o processo de gerenciamento de mudança inclua os listados abaixo.
a) os papéis e indivíduos que podem registrar e classificar uma requisição de mudança;
b) um dono que seja responsável pelo gerenciamento do ciclo de vida de cada requisição
de mudanças, por exemplo, dono do serviço e dono do processo.
c) representantes nomeados para assessorar quanto ao impacto das mudanças. Isso pode ser
o comitê consultivo de mudanças, que tipicamente inclui representantes do provedor de serviços,
clientes e partes interessadas, dependendo do escopo e impacto da mudança nos serviços
e no ambiente de negócios.
d) uma autoridade de mudança, para tomar de decisões da aceitação e aprovação de mudanças.

Convém que uma autoridade de mudança seja relevante para o tipo de mudança e pode ser
um papel nominativo, um indivíduo ou o comitê consultivo de mudanças e o comitê consultivo
de mudança emergencial.
9.3 Gerenciamento de liberação e implementação
Convém que o processo de gerenciamento de liberação e implementação assegure que todas

as liberações sejam implantadas de maneira efetiva dentro do ambiente de produção, de modo que
a integridade do hardware, software e componentes de serviço seja mantida. Convém que o processo
de gerenciamento de liberação e implementação coordene todos os aspectos da liberação. Isto convém
incluir funcionalidade técnica, integração com o ambiente, alocação de recursos para desenvolver,
testar e implantar a liberação, treinamento, suporte e documentação da liberação. Convém que todos
os aspectos sejam considerados em conjunto para assegurar que a liberação seja bem-sucedida.

Convém que a integridade do ambiente de produção seja protegida e convém que interrupções
sejam minimizadas por meio de planejamento adequado, teste e coordenação com o processo
de gerenciamento de mudança.
9.3.2 Conceitos
O processo de gerenciamento de liberação e implementação é responsável por coordenar liberações

grandes ou complexas, bem como liberações menores. Convém, portanto, que o processo
de gerenciamento de liberação e implementação seja desenhado para possibilitar o gerenciamento
e a coordenação eficaz das liberações com diferentes escopo, complexidade e graus de risco.
Uma liberação pode ser uma ou mais mudanças para um serviço, que são construídas, testadas
e implementadas em conjunto. Mudanças múltiplas podem ser empacotadas e agrpadas em uma
ou mais liberações para ajudar a gerenciar dependências e para eficiência. Convém que um pacote
de liberação inclua um conjunto de IC que sejam implementados em conjunto, como uma
liberação única.
Convém que o processo de gerenciamento de liberação e implementação assegure que as mudanças

dentro de cada liberação sejam compatíveis entre si.
Convém que a implementação seja responsável por distribuir e entregar o serviço e os componentes
de serviço, no tempo e local corretos, no ambiente-alvo.
Convém que o provedor de serviços coordene as atividades de liberação e implementação com

os clientes, usuários e partes interessadas. Convém que, em muitos casos, as liberações sejam
coordenadas com projetos de mudanças de negócio e com gerenciamento de mudanças de
negócios, para assegurar o alinhamento com programas relevantes de conscientização, comunicação
e treinamento.
Convém que o processo de gerenciamento de liberação e implementação planeje e gerencie liberações

individuais para serviços novos ou modificados em coordenação com o processo de desenho e transição
de processos de serviços novos ou modificados e o processo de gerenciamento de mudanças.
Quando possível, convém que liberações usem métodos padronizados ou consistentes para assegurar
a integridade dos IC. Liberações podem ser obtidas com custo mais eficaz ao buscar eficiência
em escala por meio do uso de métodos-padrões e, quando possível, ao usar automação.
9.3.3.1 Política de liberação
Convém que o provedor de serviços, em conjunto com o cliente e as partes interessadas, desenvolva
e concorde com uma política de liberação para ajudar a especificar a frequência de liberações
e a abordagem para cada tipo de liberação. Uma política de liberação pode tipicamente incluir:
a) definição de cada tipo de liberação, incluindo uma liberação de emergência. Outros exemplos são:
grande, significativa, menor;
b) a frequência de cada tipo de liberação;
c) definição de papéis-chave e responsabilidades para todas as atividades de processo

de gerenciamento de liberação e implementação;

d) níveis de autoridade para aceitação da liberação e aprovações das implementações;
e) regras sobre verificação e aceitação de liberações;
f) esquemas de identificação para liberações;
g) regras para nomear versões de liberações;

h) construção e empacotamento de liberações;
i) abordagem de liberação e implementação para cada tipo de liberação, inclusive métodos e

ferramentas de implementação automatizados, quando aplicáveis;
j) uma abordagem de teste consistente e predefinida.
9.3.3.2 Planejamento de liberação e implementação
Convém que o processo de gerenciamento de liberação e implementação planeje a liberação

e implementação de um serviço novo ou modificado no ambiente de produção com o cliente
e as partes interessadas. Convém que métodos e técnicas de gerenciamento de projeto sejam
utilizados para dar suporte ao planejamento de liberação e implementação. Convém que a informação
mínima para planos de liberação e implementação seja definida pelo provedor de serviços, e esta
pode diferir de acordo com o tipo de liberação.
Convém que os planos de liberação e implementação sempre assegurem que todas as mudanças
sejam coordenadas com o processo de gerenciamento de mudanças. Convém que o planejamento
de liberação e implementação inclua uma avaliação do impacto da liberação, riscos associados
e a identificação de quaisquer medidas de mitigação que podem ser empregadas para minimizar
quaisquer riscos inaceitáveis.
Convém que os fatores típicos a serem considerados quando do planejamento de uma liberação
e sua implementação sejam o volume de negócios, técnicos e outras mudanças necessárias para
implementar uma liberação. Por exemplo, novas habilidades, processos novos ou modificados e novas
ferramentas. Outros fatores incluem dependências e o tempo e recursos necessários para construir,
testar e implementar uma liberação.
Convém que os planos de liberação e implementação incluam os seguintes componentes:
a) escopo e conteúdo da liberação, incluindo os entregáveis;
b) serviços e componentes de serviços para transferir, desativar ou tornar obsoletos, incluindo

licenças;
c) cronograma para o empacotamento e implementação da liberação com datas determinadas

mediante consultas junto ao cliente para cada local nomeado;
d) papéis e responsabilidades para planejamento, coordenação, construção, teste, implementação

e análise da liberação;
e) os procedimentos e métodos para liberação e implementação que assegurem a integridade

do software, hardware e outros componentes de serviço durante a implementação;
f) planos para atividades de comunicação que forneçam a informação necessária para usuários
na organização do cliente, do pessoal no provedor de serviços e quaisquer fornecedores
relevantes;

g) a abordagem para identificar, rastrear e gerenciar quaisquer problemas detectados durante

a liberação;
h) planos de teste, inclusive itens, como critérios de aceitação, método de teste, scripts e planilhas
de registro de resultado;
i) abordagem para gerenciar ambientes de teste controlados, quando apropriado, para assegurar que
liberações possam ser suficientemente testadas antes do piloto, experimento e/ou implementação;
j) abordagem para gerenciar ativos e IC de acordo com políticas e procedimentos aplicáveis,

por exemplo, gerenciamento de ativos, gerenciamento de configuração, saúde e segurança,
ambiental, gerenciamento da segurança da informação;
k) o critério frente ao qual convém que a liberação e a implementação sejam verificadas, juntamente
com qualquer critério apropriado e com a abordagem aprovada para ser utilizada para reverter
ou remediar liberações falhas;
l) referências ou requisitos definidos nos planos para:
1) liberar e implementar instruções de trabalho, independentemente do uso de recursos internos

ou externos;
2) ferramentas que são necessárias para efetivar a liberação, inclusive o uso de ferramentas
e técnicas para instalação remota ou sem supervisão de software;
3) a implementação de mudanças-padrão que são aprovadas para liberação por meio

do processo de gerenciamento de mudanças;
4) atualização dos detalhes de configuração de qualquer serviço, componentes de serviços

e IC afetados pela liberação.
9.3.3.3 Práticas de liberação e implementação
Convém que cada liberação contenha um conjunto de IC. Convém que o processo de gerenciamento
de liberação e implementação trabalhe junto ao processo de gerenciamento de configuração para
assegurar que os IC estejam corretamente definidos de acordo com:
a) tipos de IC acordados, por exemplo, uma política de gerenciamento de configuração;
b) relacionamentos com outros IC;
c) nomeação e convenção para nomear versionamento;
d) hardware técnico e construções de ambiente;
e) imagens de softwares;
f) instruções de trabalho.
Convém que isto assegure a integridade da informação sobre serviços e componentes de serviços,
durante a implementação.
Convém que o conteúdo de uma liberação assegure a adequação da liberação para implementação.

Convém que o conteúdo de uma liberação defina os ativos e os IC a serem adquiridos e montados como
componentes de liberação. Isto pode incluir licenças master de software que necessitem aquisição
e subsequente armazenagem na biblioteca de software. Pode incluir também a aquisição de itens
de hardware que convém serem mantidos em um depósito de hardware identificado.
Convém que práticas de trabalho consistentes e procedimentos definidos que foram comprovados,
por meio de testes, pilotos e experimentação, sejam utilizados. Exemplos de tais práticas de trabalho
e procedimentos incluem: liberação, construção, teste, distribuição de liberação, instalação de liberação,
verificação e, se necessário, a reversão ou remediação da liberação.
Convém que o processo de gerenciamento de liberação e implementação defina os métodos

e práticas a serem empregados para liberações de emergência em coordenação com a interface para
o procedimento de gerenciamento de mudanças emergenciais.
9.3.3.4 Teste das liberações
Convém que as atividades de teste incluam:
a) criação de um plano de teste;
b) criação de rotinas de teste e a preparação do ambiente de teste para a liberação;
c) atividades de teste a serem conduzidas no ambiente de teste;
d) teste de aceitação do usuário;
e) registros dos resultados dos testes, incluindo versões, problemas e hora e data em que o problema
foi encontrado;
f) produção de um relato de teste;
g) assinatura para a liberação, desde que atenda aos critérios e esteja apta ao seu propósito.
9.3.3.5 Atividades e procedimentos para implementação
Convém que as atividades e procedimentos para a implementação incluam o seguinte:
a) distribuição e entrega de itens de configuração que suportem o serviço e componentes do serviço

no local e momento corretos;
b) construção, instalação e configuração de IC com quaisquer informações e dados convertidos

ou novos;
c) verificação de que os serviços e componentes de serviço foram testados de acordo com os testes
de aceitação, produzindo a instalação e relatórios de teste;
d) atualização de registros para o novo lançamento e qualquer IC ou serviços removidos durante

a transição;
e) gravar quaisquer incidentes, problemas, erros conhecidos, eventos inesperados ou desvios

dos planos;
f) implementar ações corretivas durante a implementação;
g) reverter ou tomar medidas corretivas para corrigir uma liberação malsucedida.

Convém que os documentos e registros a serem produzidos e retidos pelo processo de gerenciamento
de liberação e implementação incluam:
a) política de liberação;
b) plano de liberação;
c) o conteúdo de cada liberação, incluindo alterações relacionadas aprovadas pelo processo

de gestão de mudanças;
d) o conteúdo de cada liberação, incluindo novos componentes, componentes alterados resultantes

das atividades de liberação e implementação, componentes retirados, sendo recuperados
ou tornados obsoletos durante a implementação;
e) projeto de implementação, notas de implementação e guias de instalação para a liberação;
f) plano de implementação, que pode ser sob a forma de um plano de projeto;
g) um cronograma de liberações e implementações que indique a existência dos períodos de quando

não é possível programar as liberações, devido ao risco elevado para o cliente nesse período,
por exemplo, final do exercício financeiro;
h) avaliação do impacto do usuário e avaliação de impacto da mudança nos negócios;
i) plano de comunicação;
j) plano de treinamento que abranja os usuários, pessoal do provedor de serviços e partes

interessadas;
k) planos de teste de liberação e implementação e resultados de testes;
l) aceitação da liberação e a assinatura do cliente;
m) registros de sucesso e fracasso, juntamente com listas de ação de acompanhamento ou registros

de incidentes;
n) incidentes, problemas e registros de erros conhecidos para eventuais falhas de liberação,

reversões ou trabalho de remediação;
o) informações de IC para cada liberação:
1) identificador de liberação e versão;
2) descrição da libertação;
3) a relação entre a liberação e seus IC constituintes;
4) localização do pacote de liberação e instalação;
5) solicitações de mudanças associadas;
6) incidentes associados, problemas e erros conhecidos, incluindo aqueles que foram corrigidos
pela liberação.

Convém que, além do dono do processo, gerente do processo e do pessoal que executa os procedimentos
do processo, como descrito na Seção 4.4.2.1, autoridades e responsabilidades necessárias dentro
do processo de gerenciamento de libertação e implementação incluam:
a) o cliente ou representante do cliente, responsável pelo planejamento e coordenação de liberações

e de implementação com atividades de mudanças de negócios;
b) o usuário, responsável pela operação do serviço novo ou alterado ou componente de serviços

e realização de testes de usuário, quando aplicável;
c) o pessoal do provedor de serviços, responsável por testar as atividades operacionais para

o serviço novo ou modificado ou componente de serviço.

Anexo A
(informativo)
Interfaces entre processos e integração de processos com SGS

Os exemplos referenciados em todas as tabelas deste Anexo não são exaustivos.
Tabela A.1 – Interfaces e integração entre desenho e transição de serviços novos

ou modificados
Exemplos de interfaces entre desenho e transição de serviços novos ou modificados

e o resto do sistema de gestão de serviços (SGS) incluem:
Convém que o processo de GNS forneça requisitos de níveis de serviços do serviço novo
ou modificado.
Convém que o processo de gerenciamento de requisitos do negócio forneça todos os requisitos
de negócio para serviços novos ou modificados, para assegurar que eles sejam identificados,
documentados e entregues.
Convém que o processo de gerenciamento de incidentes e requisições de serviços forneça detalhes
do impacto da introdução do serviços novos ou modificados após a transição para a produção.
Convém que o processo de liberação e implementação forneça o cronograma e a metodologia
de desdobramento.
Convém que o processo de orçamento e contabilidade receba um relatório de provisão de custos
para serviços modificados.
Convém que o gerenciamento de mudanças receba requisições de mudanças introduzidas para
serviços novos ou modificados.
Exemplos de integração entre desenho e transição de serviços novos ou modificados
e o resto do SGS incluem:
Convém que desenho e transição de serviços novos ou modificados sejam auditados e os resultados
de não conformidades registrados para servir como entradas para identificar requisitos potenciais
para serviços novos ou modificados.
Convém que desenho e transição de serviços novos ou modificados recebam relatórios de análises
de satisfação de cliente como entradas para identificar requisitos potenciais para serviços novos ou
modificados, para endereçar à satisfação do cliente

Tabela A.2 − Interfaces e integração para GNS
Exemplos de interfaces entre GNS e o restante do SGS incluem:

Convém que a continuidade de serviço e o processo de gerenciamento de disponibilidade
forneçam requisitos de disponibilidade ou continuidade como entrada para o ANS, e reduzam
o não cumprimento do ANS devido à descontinuidade ou indisponibilidade.
Convém que o processo de gerenciamento de capacidade forneça requisitos de desempenho como

entrada para o ANS, para reduzir o não cumprimento do ANS devido ao fraco desempenho.
Convém que o processo de gerenciamento de fornecedor forneça detalhes de contratos com
fornecedores, de modo que as metas contratuais dos fornecedores se alinhem com os ANS.
Convém que o processo de GSI forneça a política de segurança da informação, de modo que ANS
sejam desenvolvidos para se alinhar com a política de segurança.
Convém que o processo de gerenciamento de requisição de serviço e incidente forneça dados
relevantes sobre incidentes.
Convém que o processo de gerenciamento de solicitações de serviço e incidentes receba ANS,
de modo que incidentes e solicitações sejam priorizados e solucionados ou realizados de forma
alinhada com períodos acordados para resposta e resolução.
Convém que o processo de gerenciamento de mudanças receba solicitações para mudanças para
ANS, e identifique interrupções de serviço projetadas, detalhando variações planejadas dos ANS.
Exemplos de integração entre GNS e o restante do SGS incluem:
Convém que o processo de GNS mantenha as definições acordadas de serviço entre a direção,
o cliente, os usuários e o gerente de nível de serviço.
Convém que o processo GNS defina as habilidades e os recursos do provedor de serviço necessários
para a entrega do serviço.
Convém que o processo GNS interaja com fornecedores de serviços que apoiam os grupos de
solucionadores de serviço tais como suporte de nível 2 e nível 3, e a realização de provisionamento
para requisição de serviços.
Tabela A.3 – Interfaces e integração para relatos de serviço
Exemplos de interfaces entre relatório de serviço e o restante do SGS incluem:

Convém que o processo de GNS forneça informação correspondente aos ANS, para definir
as políticas apropriadas e regras sobre relatório de serviço.
Convém que o processo de gerenciamento de requisição de serviço e incidente forneça dados
relevantes sobre incidentes ao relatório de serviço, de modo que todas as partes interessadas
possam compreender o impacto e tomem as ações acordadas.
Convém que o processo de gerenciamento de disponibilidade e continuidade de serviço forneça
informação de disponibilidade de componente e serviço.
Convém que o processo de gerenciamento de capacidade forneça informação de relatórios
de carga de trabalho, inclusive contra limiares predefinidos.

Tabela A.3 (continuação)
Exemplos de interfaces entre relatório de serviço e o restante do SGS incluem:

Convém que o processo GRN receba o nível certo de informação, a fim de possibilitar a entrega
de ótimos níveis de serviço e a melhoria da satisfação do cliente.
Exemplos de integração entre relatos de serviço e o restante do SGS incluem:

Convém que o processo de relatos de serviço forneça relatórios para as partes interessadas
sobre a qualidade, custos e riscos do serviço, para possibilitar a tomada de decisões e realização
de ações relativas ao serviço.
Convém que o processo de relatório de serviço receba dados de todo o processo de gerenciamento
de serviço para possibilitar a comunicação e visibilidade necessárias para gerenciar e melhorar
o SGS.
Tabela A.4 – Interfaces e integração para gerenciamento de disponibilidade e continuidade

do serviço
Exemplos de interfaces entre gerenciamento de disponibilidade e continuidade do serviço

e o restante do SGS incluem:
Convém que o processo GNS forneça:
— obrigações de disponibilidade e continuidade de serviço nos ANS;
— níveis de serviço que poderiam ser aceitáveis ao negócio no caso de um desastre;
— ajuda para determinar as metas de disponibilidade e a investigação e resolução de violações
de serviços e componentes.
Convém que o processo de gerenciamento de capacidade forneça:
— plano de capacidade para possibilitar alinhamento com o plano de disponibilidade;
— informação de modelagem, de modo que possa haver recursos suficientes, por exemplo,
armazenamento de dados para possibilitar recuperação após um desastre, com o provisiona-
mento de resiliência e capacidade de reserva.
Convém que o processo GSI forneça definição de quando um incidente de segurança de informa-
ção pode ser considerado um desastre.
Convém que o processo de gerenciamento de configuração forneça informação sobre os com-
ponentes que constroem a infraestrutura, para possibilitar todas as atividades de processo de
gerenciamento de disponibilidade e continuidade de serviço, bem como a manutenção de planos
e recursos de recuperação.
Convém que o processo de gerenciamento de mudanças forneça informação sobre todas as
mudanças com impacto potencial nos planos de disponibilidade e continuidade de serviço.
Convém que o processo GNS receba requisitos e opções de recuperação, de modo que eles
possam ser acordados e documentados nos ANS.
Convém que o processo de gerenciamento de problemas e gerenciamento de requisição

de serviços e incidentes recebam critérios claros, acordados e documentados para a invocação
dos planos de disponibilidade e continuidade do serviço.

Exemplos de integração entre gerenciamento de disponibilidade e continuidade de serviço

e o restante do SGS
Convém que o processo de gerenciamento de disponibilidade e continuidade de serviço receba
informação sobre planos de negócio do cliente e partes interessadas, para identificar requisitos
novos ou modificados para continuidade de serviço ou disponibilidade.

análise de impacto do negócio para a direção e todas as partes interessadas, para assegurar que
decisões de gerenciamento de serviço sejam baseadas em um claro entendimento do impacto no
negócio devido à falta de disponibilidade.
Tabela A.5 – Interfaces e integração para serviços de contabilidade e orçamento
Exemplos de interfaces entre serviços de contabilidade e orçamento e o restante do

SGS incluem:
Convém que desenho e transição de processo de serviços novos ou modificados forneçam planos
de serviço novos ou modificados, incluindo orçamentos e cronogramas.
Convém que o processo GNS forneça o catálogo de serviços como uma base para a construção
de modelos de custo para serviços fornecidos pelo provedor de serviços.
Convém que o processo de gerenciamento de capacidade forneça o plano de capacidade, incluindo
opções de custo para atender aos requisitos do negócio.
Convém que o processo de gerenciamento de fornecedor forneça detalhes de mudanças para
custos, tanto para curto prazo quanto para o restante da vida do contrato.
Convém que o processo de gerenciamento de configuração forneça detalhes para todos os itens
de configuração.
Convém que o processo de gerenciamento de capacidade receba orçamento para upgrades de
infraestrutura e serviços ou para a compra de novos componentes.
Convém que o processo de gerenciamento de mudanças receba aprovação financeira, quando
necessário.
Exemplos de integração entre serviços para contabilidade e orçamento e o restante
do SGS incluem:
Convém que o processo de serviços para contabilidade e orçamento receba informação suficiente
do gerenciamento de finanças da organização do provedor de serviços, para possibilitar uma
previsão e alocação de custos confiáveis.
Convém que o processo de serviços para contabilidade e orçamento forneça uma política
de serviços para contabilidade e orçamento, para possibilitar à organização o alinhamento com
a política de gerenciamento financeiro, bem como com os requisitos regulatórios.
Convém que recursos financeiros sejam orçados ao nível de detalhe adequado para gerenciar
a implementação, operação e melhorias para o SGS, o qual requisitará a coordenação do processo
de serviços para contabilidade e orçamento.

Tabela A.6 – Interfaces e integração entre gerenciamento da capacidade e o resto do SGS
Exemplos de interfaces entre gerenciamento de capacidade e o restante do SGS incluem:

Convém que o processo GNS forneça ANS e níveis de serviços necessários em adição às metas
do gerenciamento de capacidade.
Convém que os serviços de contabilidade e orçamento forneçam informações sobre ganhos

de eficácia no fornecimento de serviços, resultando em baixos custos de capacidade, ou melhor
utilização de recursos de capacidade.
Convém que o processo de gerenciamento de requisição de serviço e incidente forneça informação
sobre incidentes relativos à capacidade e ao desempenho.
Convém que o processo de gerenciamento de configuração forneça dados de negócio e finanças,
de utilização, de serviços e técnicos sobre IC mantidos no BDGD.
Convém que o processo GNS receba relatórios regulares para assegurar que metas de capacidade
e desempenho para requisitos de mudanças ou novos possam ser obtidos. Desempenho depende
de uma determinada carga de trabalho, portanto, ambos são necessários em um ANS com meta
de desempenho específica. De modo similar, pode haver uma requisição para o processo de gerencia-
mento de capacidade para ajudar o processo GNS a delinear e revisar os acordos de nível operacional
e contratos externos, onde problemas sobre desempenho e capacidade estejam envolvidos.
modelagem de dados para determinar a capacidade necessária para todas as opções de recuperação
utilizadas. A configuração mínima de hardware e software necessária é definida para fornecer o
desempenho necessário e níveis de taxa de transferência seguidos de uma invocação.
Convém que o processo de gerenciamento de problema receba opiniões de especialista para auxiliar
na capacidade de identificação, diagnóstico e resolução relacionada a problemas.
Convém que o processo de gerenciamento de mudanças receba informação do processo de
gerenciamento de capacidade sobre o efeito cumulativo de mudanças sobre capacidade. Processo
de gerenciamento de capacidade é também representado no comitê consultivo de mudanças para
avaliar o impacto de mudanças na capacidade existente e para identificar mudanças nos requisitos
de capacidade.
Convém que o processo de gerenciamento de liberação e implementação receba informações para
auxiliar na determinação da política de distribuição para liberações, particularmente onde a rede é
utilizada para distribuição. Convém que fatores como o tamanho da banda da rede, capacidade de
alvo e hospedagem, janela de distribuição e número de metas sejam considerados como partes de
uma política de distribuição para liberação.
Exemplos de integração entre gerenciamento de capacidade e o restante do SGS incluem:
Convém que o processo de gerenciamento de capacidade receba os resultados de auditorias,
identificando não conformidades e oportunidades para melhorias.
Convém que o processo de gerenciamento de capacidade forneça requisitos para competência,
conscientização e treinamento, para assegurar que o provedor de serviços tenha habilidades
suficientes e níveis de habilidade para suportar o processo de gerenciamento de capacidade.

Tabela A.7 – Interfaces e integração para GSI
Exemplos de interfaces entre GSI e o restante do SGS incluem:

Convém que o processo para contabilidade e orçamento de serviços forneça informação sobre
os custos associados aos controles de segurança.
Convém que o processo de gerenciamento de capacidade forneça o impacto de capacidade dos

controles de segurança (controles de segurança frequentemente impactam no desempenho de
serviços).
Convém que o processo de gerenciamento de fornecedor forneça relatórios medindo se fornecedo-
res estão aderindo e mantendo a política de segurança de informação.
Convém que o processo de gerenciamento de requisição de serviço e incidente forneça detalhes
de todos os incidentes de segurança da informação para atender aos requisitos da política de
segurança da informação e impedir repetição.
Convém que o processo de gerenciamento de problema forneça a causa-raiz de incidentes identifi-
cados de segurança da informação para o GSI.
Convém que o processo de gerenciamento de configuração forneça detalhes de itens de configu-
ração mantidos no BDGD associados com alto risco de segurança e forneça informação no BDGD
que possa determinar o impacto nos problemas e resoluções de segurança da informação.
Convém que o processo de gerenciamento de mudanças forneça detalhes de resolução e conser-
tos temporários de segurança da informação.
Convém que o processo GNS receba requisitos de segurança para serem incluídos nos ANS.
Convém que o processo de gerenciamento de disponibilidade e continuidade de serviços rece-
ba detalhes de resoluções, problemas e incidentes de segurança da informação para assegurar
a continuidade e disponibilidade dos serviços.
Convém que o processo GRN receba alertas sobre ameaças de segurança da informação.
Convém que o processo de gerenciamento de requisição de serviço e incidente receba orientação
sobre como lidar com incidentes de segurança da informação.
Exemplos de integração entre GSI e o restante do SGS incluem:
Convém que o processo GSI forneça a política de segurança da informação para o gerenciamento
de documentação, para assegurar que todas as informações sejam protegidas e controladas em
alinhamento com o valor do negócio, requisitos regulatórios e níveis necessários de confidencialidade,
integridade e disponibilidade.
Convém que o processo GSI forneça a política de segurança da informação para o gerenciamento
de risco, para assegurar que riscos de segurança sejam avaliados e gerenciados.

Tabela A.8 – Interfaces e integração para GRN
Exemplos de interfaces de entre GRN e o restante do SGS incluem:

Convém que o processo GNS forneça ANS ou contratos, inclusive escopo de serviços.
Convém que o processo de relatório de serviço forneça relatórios de serviços, inclusive
necessidades identificadas e requisitos de clientes.

Convém que o processo de gerenciamento de disponibilidade e continuidade do serviço
forneça detalhes dos planos de continuidade de serviços.
Convém que o processo GSI forneça alerta de ameaças que possam afetar o relacionamento
com clientes.
Convém que os processo de gerenciamento de requisição de serviço e incidentes forneça
detalhes formais de queixas e cumprimentos do cliente.
Convém que o processo de gerenciamento de mudanças receba quaisquer ações
de melhoria e remediação decorrentes de queixas e pesquisas de satisfação do cliente.
Exemplos de integração entre GRN e o restante do SGS incluem:
Convém que o processo GRN forneça estes resultados ao cliente, levando à melhoria
da comunicação e satisfação do cliente.
Convém que o processo de reclamações de clientes e as pesquisas de satisfação
de clientes forneçam entradas para revisões do SGS.
Tabela A.9 – Interfaces e integração para gerenciamento de fornecedores
Exemplos de interfaces entre gerenciamento de fornecedores e o restante do SGS incluem:

Convém que o processo GNS forneça metas, requisitos e responsabilidades, assegurando
sua inclusão nos acordos e contratos de apoio, de modo que estas metas suportem os requisitos
de serviço, incluindo aqueles especificados nos ANS.
requisitos de disponibilidade e continuidade para serviços sendo fornecidos por outras partes.
Convém que o processo de serviços para contabilidade e orçamento forneça fundos adequados
para financiar contratos e requisitos de gerenciamento de fornecedores, e para fornecer conselho
e orientação na compra e aquisição de materiais.
Convém que o processo de GSI forneça políticas e procedimentos sobre o acesso dos fornecedores
aos serviços e sistemas, e suas responsabilidades em relação à conformidade com políticas
e requisitos do SGI.
Exemplos de integração entre gerenciamento de fornecedores e o restante do SGS incluem:
Convém que o processo de gerenciamento de fornecedor receba dados do desempenho do forne-
cedor e avalie-os com relação a alternativas disponíveis para negociar o melhor valor monetário
para suportar os requisitos e o plano de negócio do cliente.
Convém que o processo de gerenciamento de fornecedor forneça requisitos para competência
do fornecedor, conscientização e treinamento e avaliação dos resultados do treinamento
do fornecedor para assegurar que o fornecedor esteja continuadamente alinhado com os requisitos
de capacidade do negócio.

Exemplos de integração entre gerenciamento de fornecedores e o restante do SGS incluem:

Convém que o processo de mudanças em contratos, acordos documentados ou outros documentos
acordados pelas partes interessadas, inclusive mudanças no comprometimento de serviços, sejam
gerenciados pelo processo de gerenciamento de mudança.
Convém que o processo de gerenciamento de mudanças assegure, conforme solicitado, que

o fornecedor atenda às práticas de gerenciamento de mudanças da organização e que fornecedores
sejam incluídos nas revisões, avaliações e autorizações de mudanças propostas que irão impactar
nos serviços fornecidos pelo fornecedor.
Tabela A.10 – Interfaces e integração para gerenciamento de requisição de serviço e incidente
Exemplos de interfaces entre gerenciamento de requisição de serviço e incidente e o restante

do SGS incluem:
Convém que o processo GNS forneça metas acordadas de requisição de serviços e incidentes.
Convém que o processo de gerenciamento de problema forneça registro de erros conhecidos
e detalhes de consertos temporários para minimizar o impacto de incidentes.
Convém que o processo de gerenciamento de configuração forneça informação sobre
IC impactados por incidentes ou requisição de serviços para o processo de gerenciamento
de requisição de serviço e incidente para possibilitar avaliações de impacto mais precisas.
detalhes dos incidentes e incidentes críticos que estão tendo alto impacto na disponibilidade
ou continuidade do serviço.
Convém que o processo de gerenciamento de capacidade receba detalhes de incidentes
e incidentes críticos que são relacionados à deficiência de capacidade.
Convém que o processo de gerenciamento de problema receba registros de requisição de serviços
e incidentes para análise de tendência.
Convém que o processo de gerenciamento de mudanças receba relatório sobre o impacto
de mudanças malsucedidas que resultaram em novos incidentes.
Exemplos de integração entre gerenciamento de requisição de serviço e incidente e o restante
do SGS incluem:
Os processos de gerenciamento de requisição de serviço e incidentes necessitam competências
de pessoal especializado para diferentes papéis. Convém que estes requisitos de competência
de gerenciamento de serviço sejam claramente definidos. Quando há um déficit ou outra deficiência
na pessoa que está sendo considerada ou já está no papel, convém assegurar que este déficit
esteja corrigido e convém que o provedor de serviço assegure que este déficit seja corrigido.
Convém que solicitações de serviço e registro de incidentes sejam analisadas criticamente para
identificar oportunidades para melhoria de processo e economia de custos.

Tabela A.11 – Interfaces e integração para gerenciamento de problemas
Exemplos de interfaces entre gerenciamento de problema e o restante do SGS incluem:
Convém que o processo GNS forneça ANS e acordos incluindo metas acordadas de
gerenciamento de problemas.
Convém que o gerenciamento de disponibilidade e continuidade de serviço forneça detalhes

de problemas que estão tendo alto impacto na disponibilidade ou continuidade do serviço.
Convém que o processo de gerenciamento de capacidade forneça quaisquer tendências

em capacidade.
Convém que o processo de gerenciamento de requisição de serviço e incidente forneça:
— detalhes dos incidentes, para os quais existe um causa-raiz desconhecida, para o gerencia-
mento de problema.
— dados do incidente para gerenciamento de problemas proativo, como a análise de tendência.
Convém que o processo de gerenciamento de configuração forneça informação sobre

os relacionamentos entre IC, que pode auxiliar na determinação do impacto de problemas
e resoluções.
Convém que o processo de gerenciamento de requisição de serviço e incidentes receba:
— detalhes de erros conhecidos para serviços modificados ou novos sendo introduzidos

no ambiente de produção;
— registros de erros conhecidos e detalhes de consertos temporários, de modo a minimizar
impacto de incidentes.
Convém que o processo de gerenciamento de mudanças receba solicitações de mudanças para

implementar soluções permanentes para os erros conhecidos.
Exemplos de integração entre gerenciamento de problemas e o restante do SGS incluem:
Convém que o processo de gerenciamento de problemas receba informações sobre problemas

com o SGS.
Convém que o processo de gerenciamento de problemas identifique a causa-raiz do problema

com o SGS resolvendo-a por meio do processo de gerenciamento de mudança.
Convém que o banco de dados de erros conhecidos esteja em conformidade com procedimentos
e políticas de gerenciamento de documentação.

Tabela A.12 – Interfaces e integração para gerenciamento de configuração
Exemplos de interfaces entre gerenciamento de configuração e o restante do SGS incluem:
Convém que o processo de gerenciamento de configuração forneça informação sobre os

relacionamentos entre IC que possa auxiliar na análise de impacto e causa-raiz de problemas.
Convém que o gerenciamento de configuração forneça informações sobre quais IC serão impactados
pelas mudanças propostas.
Convém que o gerenciamento de configuração forneça informações sobre os IC que suportam

serviços listados no catálogo de serviços.
Convém que o processo de desenho e transição de serviços novos ou modificados forneça detalhes
de todos os planos e desenhos para novos ou modificados, de modo que os impactos nos IC
existentes possam ser avaliados pelas partes interessadas.
Convém que os processos de gerenciamento de incidentes e cumprimento de solicitações

forneçam detalhes de todos os incidentes e solicitações de serviços relacionados aos itens
de configuração.
Convém que o processo de gerenciamento de problemas forneça uma ligação entre os erros
conhecidos, as soluções temporárias e os itens de configuração.
Convém que o processo de gerenciamento de mudanças forneça detalhes de mudanças nos itens
de configuração e a aprovação para refletir essas mudanças no BDGC.
Convém que o processo de gerenciamento de liberação e implementação forneça uma base

de referência de configuração dos itens liberados e do ambiente de destino antes e depois das
liberações
Convém que todos os processos recebam informações atualizadas e exatas sobre todos os itens
de configuração dentro do escopo do seu processo
Convém que o processo de orçamento e contabilização de serviços receba detalhes de qualquer

ativo, incluindo licenças, usadas para prover os serviços.
Exemplos de integração entre o gerenciamento de configuração e o resto do SGS incluem:
A alta direção é responsável por assegurar que todos os ativos, incluindo licenças, usadas para
fornecer serviços, sejam geridos de acordo com os requisitos estatutários e regulatórios, e as
obrigações contratuais. O gerenciamento de configuração é um meio primário pelo qual este
requisito é alcançado.
O processo de gerenciamento de configuração não inclui contabilidade de ativos financeiros, mas

convém que inclua a interface para o processo de contabilização de ativos financeiros.

Tabela A.13 – Interfaces e integração para gerenciamento de mudanças
Exemplo de interfaces entre gerenciamento de mudanças e o resto do SGS inclui:

Convém que o processo de gerenciamento de continuidade e disponibilidade de serviços forneça:
— solicitações de mudança, para atualizar procedimentos e planos de continuidade de serviços,
isso vai garantir que os procedimentos e planos de continuidade de serviços permaneçam

precisos, atualizados e que as partes interessadas sejam mantidas cientes das mudanças;
— o potencial impacto de uma mudança proposta na disponibilidade de um serviço ou componente
para gerenciamento da mudança.
Convém que o processo de gerenciamento de capacidade forneça uma avaliação das mudanças
propostas, incluindo não só o impacto individual da mudança, mas também o impacto total de
mudanças nos recursos e capacidade do serviço ou capacidade de componentes.
Convém que o processo de gerenciamento de segurança de informação forneça avaliação do
impacto potencial das mudanças propostas na política de segurança da informação e seus controles.
Convém que o processo de gerenciamento de incidentes e cumprimento de solicitações forneça
informações de incidentes associados às mudanças implementadas.
Convém que o processo de gerenciamento de problemas forneça informações de problemas
associados às mudanças implementadas.
Convém que o processo de gerenciamento de configuração forneça um acesso confiável, rápido e
fácil às informações de configuração exatas, para proporcionar ao pessoal e às partes interessadas
uma análise de impacto das mudanças propostas.
Convém que o processo de gerenciamento de liberação e implementação forneça informações
sobre mudanças aprovadas que serão implementadas por meio do processo de liberação.
Exemplo de integração entre gerenciamento de mudanças e o resto do SGS inclui:
Convém que todas as mudanças no SGS passem pelo processo de gerenciamento de mudanças.
Convém que o processo de gerenciamento de mudanças forneça detalhes de todas as mudanças no
SGS, catálogo de serviços, serviços, políticas, objetivos e planos, requisitos de negócios, requisitos
de serviços e requisitos de fornecedores.
O escopo do SGS tem implicações para o tempo e custo de melhorias e outras mudanças, o que
traz implicações para o processo de gerenciamento de mudanças.

Tabela A.14 – Interfaces e integração para gerenciamento de liberação e implementação
Exemplo de interfaces entre gerenciamento de liberação e implementação e o resto do

SGS inclui:
Convém que o processo de gerenciamento de continuidade e disponibilidade de serviços forneça
avaliação de qualquer desenho técnico para assegurar que os serviços continuem a cumprir as
metas de disponibilidade particulares quando a capacidade global puder aumentar. Convém que
a revisão antecipada e a atualização do plano de gerenciamento de continuidade forneçam qualquer
nova e significativa liberação. Convém que a programação de testes e revisões de continuidade,
apropriados, seja realizada antes da liberação e implementação.
Convém que o processo de gerenciamento de capacidade forneça informações e apoio em relação
à compra e instalação de capacidade adicional para apoiar a liberação. Isso pode incluir a reserva
de capacidade para ambientes de desenvolvimento e teste.
Convém que os processos do sistema de gestão de serviços forneçam um plano de segurança
atualizado em conformidade com a adoção de novas políticas, práticas e ferramentas que resultam
da liberação.
Convém que o processo de gerenciamento de fornecedores forneça os contratos e acordos
necessários que estão em vigor ou são atualizados antes da aquisição e suporte dos componentes
técnicos dentro de uma liberação. Isso contribui para a liberação estar em produção.
Convém que o processo de gerenciamento de mudanças forneça a requisição de mudanças
aprovada para o gerenciamento de liberação e implementação.
Convém que o processo de gerenciamento de nível de serviços receba atualizações referentes a
qualquer mudança de serviços ou documentação de nível de serviços e contatos-chaves.
Convém que o processo de gerenciamento de problemas receba avisos e registros de qualquer
defeito e as correspondentes soluções temporárias que serão promovidas para o ambiente de
produção com a liberação.
Convém que o processo de gerenciamento de configuração receba informações refletindo as
mudanças no ambiente de produção após as liberações. Esta informação assegurará a exatidão do
BDGC. Informações adicionais relevantes sobre as liberações para o BDGC irão incluir atualizações
de itens de configuração modificados ou retirados e serviços novos que substituem serviços legados.
Exemplo de integração entre gerenciamento de liberação e implementação e o resto do
SGS inclui:
Convém que o processo de gerenciamento de liberação e implementação leve em conta qualquer
treinamento, contratação ou operação assistida requerida como parte da liberação.
Convém que a alta direção assegure que a quantidade e as habilidades dos recursos de pessoal
contratados ou utilizados pelo provedor de serviço são suficientes para construir, testar e implantar
a liberação, assim como suportar e operar a nova liberação uma vez na produção.

Bibliografia
[1] ABNT ISO/IEC TR 20000-3, Tecnologia da informação – Gerenciamento de serviços – Parte 3:

Direcionamento para a definição de escopo e aplicabilidade da ABNT NBR ISO/IEC 20000-1
[2] ABNT ISO/IEC TR 20000-5, Tecnologia da informação – Gerenciamento de Serviços – Parte 5:

Exemplo de um plano de implementação da ABNT NBR ISO/IEC 20000-1
[3] ABNT NBR ISO 9000, Sistemas de gestão da qualidade – Fundamentos e vocabulário
[4] ABNT NBR ISO 9001, Sistemas de gestão da qualidade – Requisitos
[5] ABNT NBR ISO 9004, Gestão para o sucesso sustentado de uma organização – Uma abordagem
da gestão da qualidade
[6] ABNT NBR ISO 10002, Gestão da qualidade – Satisfação do cliente – Diretrizes para o tratamento
de reclamações nas organizações
[7] ABNT NBR ISO/IEC 12207, Engenharia de sistemas e software – Processos de ciclo de vida
de software
[8] ABNT NBR ISO/IEC 15288, Engenharia de sistemas e software – Processos de ciclo de vida
de sistema
[9] ABNT NBR ISO/IEC 15504-1, Tecnologia da informação – Avaliação de processo – Parte 1:
Conceitos e vocabulário
Realização de uma avaliação
Orientações para realização de uma avaliação
Orientação no uso para melhoria do processo e determinação da potencialidade do processo
[13] ABNT NBR ISO/IEC 15939, Engenharia de sistemas e de software – Processo de medição
[14] ABNT NBR ISO 19011, Diretrizes para auditoria de sistemas de gestão
[15] ABNT NBR ISO/IEC 27001, Tecnologia da informação – Técnicas de segurança – Sistemas
de gestão de segurança da informação – Requisitos
[16] ABNT NBR ISO 31000, Gestão de riscos – Princípios e diretrizes

[17] ABNT NBR ISO/IEC 38500, Governança corporativa de tecnologia da informação
[18] ISO/IEC TR 20000-4, Information technology – Service management – Part 4: Process reference
model
[19] ISO/IEC TR 9126-2, Software engineering – Product quality – Part 2: External metrIC
[20] ISO/IEC TR 9126-3, Software engineering – Product quality – Part 3: Internal metrIC
[21] ISO 10007, Sistemas de gestão da qualidade – Diretrizes para gestão de configuração
[22] ISO/IEC 14598 (all parts), Software engineering – Product evaluation
[23] ISO/IEC 15504-5, Information technology – Process assessment – Part 5: An exemplar Process
Assessment Model
[24] ISO/IEC 19770-1, Information technology – Software asset management – Processes
[25] ISO/IEC TR 24748-2, Systems and software engineering – Life cycle management – Part 2: Guide
to the application of ISO/IEC 15288 (System life cycle processes)
[26] ISO/IEC TR 24748-3, Systems and software engineering – Life cycle management – Part 3: Guide
to the application of ISO/IEC 12207 (Software life cycle processes)
[27] ISO/IEC 27002, Information technology – Security techniques – Code of practice for information
security management
[28] ISO/IEC 27005, Information technology – Security techniques – Information security risk
management
[29] ISO/IEC 90003, Software engineering – Guidelines for the application of ISO 9001:2000
to computer software

Iso20000 2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Iso20000 2

Enviado por

Direitos autorais:

Formatos disponíveis

NORMA ABNT NBR

Tecnologia da informação — Gerenciamento

ICS 03.080.99; 35.020 ISBN 978-85-07-04374-4

© ISO/IEC 2012 - © ABNT 2013

ii © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

Prefácio Nacional ...............................................................................................................................iv

1.1 Geral ....................................................................................................................................1

© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados iii

5.2.3 Política em mudanças com impacto significativo .........................................................30

5.2.8 Remoção de serviço ........................................................................................................32

iv © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

6.5.5 Autoridades e responsabilidades ...................................................................................59

6.6.4 Documentos e registros ..................................................................................................63

© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados v

9.2.2 Conceitos ..........................................................................................................................83

9.3.1 Intenção dos requisitos ...................................................................................................86

vi © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

A Associação Brasileira de Normas Técnicas (ABNT) é o Foro Nacional de Normalização. As Normas

Esta Norma é uma adoção idêntica, em conteúdo técnico, estrutura e redação, à

— mudanças na terminologia para refletir o uso internacional;

— mais guias sobre a definição do escopo de aplicação do SGS;

— mais guias sobre a melhoria contínua do SGS e serviços;

— mais guias sobre o desenho e transição de serviços novos ou modificados.

— Parte 1: Requisitos do sistema de gerenciamento de serviços;

— Parte 2: Guia de aplicação do Sistema de gestão de serviços;

— Parte 3: Direcionamento para a definição de escopo e aplicabilidade da

— Parte 5: Exemplo de um plano de implementação da ABNT NBR ISO/IEC 20000-1.

© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados vii

O Escopo desta Norma Brasileira em inglês é o seguinte:

Customers Service Management System (SMS) Customers

Service Design and transition of new or changed services Services

Service delivery processes

Resolution processes Relationship processes

Figure – Service management system

viii © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados ix

A implementação e integração de um SGS, coordenadas, fornecem controle do andamento, uma

Planejar: estabelecer, documentar e acordar o SGS, incluindo as políticas, objetivos, planos

x © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

de gerenciamento de serviços e os serviços.

a) compreender e cumprir os requisitos de serviço para atingir a satisfação do cliente;

b) estabelecer a política e os objetivos para o gerenciamento do serviço;

d) monitorar, medir e analisar o desempenho do SGS e dos serviços;

e) melhorar continuamente o SGS e os serviços baseados em medições objetivas.

Figura 1 – Metodologia PDCA aplicada ao gerenciamento de serviços

© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados xi

Como indicado na ABNT NBR ISO/IEC 20000-1:

ABNT NBR ISO/IEC 20000 pode ser utilizada por:

c) um provedor de serviços que se propõe a demonstrar a sua capacidade para o desenho,

d) um provedor de serviços para monitorar, medir e analisar criticamente os seus processos

xii © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados

Tecnologia da informação — Gerenciamento de serviços

Consumidor Sistema de gerenciamento de serviços (SGS) Consumidor

Desenho e transição de serviços novos ou modificados

Processos de Resolução Processos de relacionamento

Figura 2 – Sistema de gestão de serviços

A Figura 2 mostra os processos das seções de 6 a 9 no retângulo central. A Seção 5, desenho

As interfaces entre os processos de gerenciamento de serviços e as relações entre diferentes

© ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados 1

O provedor de serviços pode mostrar evidências de cumprimento de todos os requisitos, ou pode

A prestação de contas, as autoridades e as responsabilidades acordadas, definidas e documentadas,

ABNT NBR ISO/IEC 20000-1, Tecnologia da informação – Gerenciamento de serviço – Parte 1:

2 © ISO/IEC 2012 - © ABNT 2013 - Todos os direitos reservados