Contracts and agreements

A terminologia usada nesta publicação é expressa do ponto de vista do provedor de

serviços de TI, especialmente no que se refere a contratos e acordos subjacentes.
Quando um fornecedor de serviços de TI contrata um fornecedor terceirizado para
fornecer bens e / ou serviços que são necessários para a prestação de serviço ao (s)
cliente (s) de TI, é importante que ambas as partes tenham expectativas claras e
inequívocas sobre como o fornecedor deve atender aos requisitos do provedor de
serviços de TI. Isso é feito documentando-se os termos de compromisso em um contrato
de algum tipo e esse contrato apóia ou "sustenta" as metas de nível de serviço no SLA
com o cliente. Se o acordo for juridicamente vinculativo, é referido como «contrato» ou,
mais precisamente, como «contrato de apoio». Quando o documento em questão
simplesmente descreve o entendimento formal entre as duas partes, mas não é
juridicamente vinculativo, o termo mais genérico "acordo" pode ser usado.

Deve-se notar que, embora não seja referido como um SLA, o contrato ou acordo com
um fornecedor incluirá tipicamente níveis de serviço especificados a serem entregues
pelo fornecedor em relação aos serviços contratados e pode ser considerado pelo
fornecedor como sendo ou incluir um SLA.

Também deve ser observado que o próprio SLA entre o provedor de serviços de TI e o (s)
cliente (s) será de natureza variável, dependendo do tipo de provedor de serviços. Por
exemplo, se o provedor de serviços de TI for Tipo I ( Um provedor de serviços interno
que é incorporado em uma unidade de negócios. Pode haver vários provedores de
serviços Tipo I em uma organização) ou Tipo II (Um provedor de serviços interno que
fornece serviços de TI compartilhados para mais de uma unidade de negócios. Os
provedores de serviços do tipo II também são conhecidos como unidades de serviço
compartilhado), o SLA provavelmente será um documento interno e não será
juridicamente vinculado; no entanto, se o provedor de serviços de TI for Tipo III (Um
provedor de serviços que fornece serviços de TI para clientes externos), o SLA terá mais
probabilidade de ser incluído como um cronograma ou especificação em um contrato
legalmente vinculante com o cliente.

Além da relação formal entre o fornecedor de serviços de TI e o fornecedor, também é

importante que os colaboradores internos da prestação de serviços de TI tenham
expectativas claras de suas responsabilidades e compromissos. Essas responsabilidades
podem ser documentadas em OLAs, que são definidos como acordos entre um provedor
de serviços de TI e outra parte da mesma organização. Eles suportam a entrega de
serviços de TI do fornecedor de serviços de TI aos clientes e definem os bens ou serviços
a serem fornecidos e as responsabilidades de ambas as partes.
Para fins de simplicidade, o termo "contrato de apoio" é usado aqui para se referir a
qualquer tipo de acordo ou contrato entre um provedor de serviços de TI e um
fornecedor que suporte a entrega de serviços ao cliente. O termo SLA é usado para se
referir a um contrato entre o provedor de serviços de TI e o (s) cliente (s) apenas.
"Contratos subjacentes" é um termo mais genérico usado para se referir a todos os OLAs
e contratos ou outros acordos que sustentam os SLAs do cliente.

Process activities, methods and techniques

As principais atividades do processo SLM devem incluir:
■■ Determinar, negociar, documentar e aprovar requisitos para serviços novos ou
alterados em SLRs e gerenciar e analisá-los por meio do ciclo de vida do serviço em SLAs
para serviços operacionais.
■■ Monitorar e medir as conquistas de desempenho de serviços de todos os serviços
operacionais em relação a metas dentro dos SLAs
■■ Produzir relatórios de serviço
■■ Realização de revisões de serviços, identificação de oportunidades de melhoria para
inclusão no registro de CSI e gerenciamento de SIPs apropriados.
■■ Coletar, medir e melhorar a satisfação do cliente, em cooperação com o
gerenciamento de relações comerciais
■■ Revisão e revisão de SLAs, escopo de serviço e OLAs
■■ Auxiliar a gestão de fornecedores a revisar e revisar contratos ou acordos
subjacentes
■■ Desenvolver e documentar contatos e relacionamentos com os negócios, clientes e
outras partes interessadas, em cooperação com o processo de gerenciamento de
relacionamento comercial.
■■ Registrando e gerenciando reclamações e elogios, em cooperação com empresas
gestão de relacionamento
■■ Fornecer informações de gerenciamento apropriadas para auxiliar o gerenciamento
do desempenho e demonstrar a realização do serviço.
Essas outras atividades dentro do processo SLM suportam a execução bem-sucedida das
principais atividades:
■■ Projetando estruturas de SLA
■■ Desenvolver, manter e operar procedimentos SLM, incluindo procedimentos para
registro, ação e resolução de todas as reclamações, e para registrar e distribuir elogios
■■ Disponibilizar e manter modelos e modelos atualizados de documentos SLM
■■ Auxiliar no projeto e manutenção do catálogo de serviços.
Designing SLA frameworks
Usando o catálogo de serviços como um auxílio, o SLM deve projetar a estrutura de SLA
mais apropriada para garantir que todos os serviços e todos os clientes sejam cobertos
da maneira mais adequada às necessidades da organização. Há várias opções possíveis,
incluindo as seguintes.
Service-based SLA
É nesse ponto que um SLA cobre um serviço para todos os clientes desse serviço. Por
exemplo, um SLA pode ser estabelecido para o serviço de e-mail de uma organização,
abrangendo todos os clientes desse serviço. Isso pode parecer bastante simples. No
entanto, podem surgir dificuldades se os requisitos específicos de diferentes clientes
variarem para o mesmo serviço ou se as características da infraestrutura significarem
inevitáveis níveis de serviço diferentes (por exemplo, funcionários da sede podem estar
conectados por uma LAN de alta velocidade, enquanto use uma linha WAN de baixa
velocidade). Em tais casos, alvos separados podem ser necessários dentro do acordo.
Dificuldades também podem surgir na determinação de quem deve ser o signatário de
tal acordo. No entanto, quando níveis comuns de serviço são fornecidos em todas as
áreas da empresa (por exemplo, email ou telefonia), o SLA baseado em serviço pode ser
uma abordagem eficiente para uso. Várias classes de serviço (por exemplo, ouro, prata e
bronze) também podem ser usadas para aumentar a eficácia dos SLAs baseados em
serviço.
Customer-based SLA
Este é um contrato com um grupo de clientes individual, abrangendo todos os serviços
que eles usam. Por exemplo, os acordos podem ser alcançados com o departamento
financeiro de uma organização cobrindo, digamos, o sistema financeiro, o sistema
contábil, o sistema de folha de pagamento, o sistema de cobrança, o sistema de compras
e quaisquer outros sistemas de TI que eles usam. Os clientes geralmente preferem esse
tipo de contrato, pois todos os seus requisitos são abordados em um único documento.
Apenas um signatário é normalmente necessário, o que simplifica esse problema.
Multi-level SLAs
Algumas organizações optaram por adotar uma estrutura de SLA multinível. Por
exemplo, uma estrutura de três camadas pode ter a seguinte aparência:
■■ Nível corporativo - Isso abrangerá todos os problemas genéricos de SLM
apropriados para cada cliente em toda a organização. É provável que esses problemas
sejam menos voláteis, portanto, as atualizações são menos necessárias.
■■ Nível do cliente - Isso abrangerá todos os problemas do SLM relevantes para o
grupo ou unidade de negócios específica, independentemente do serviço utilizado.
■■ Nível de serviço - Isso abrangerá todos os problemas de SLM relevantes para o
serviço específico, em relação a um grupo de clientes específico (um para cada serviço
coberto pelo SLA).

Conforme mostrado na Figura 4.7, essa estrutura permite que os SLAs sejam mantidos
em um tamanho gerenciável, evitando a duplicação desnecessária e reduzindo a
necessidade de atualizações freqüentes. No entanto, isso significa que é necessário um
esforço extra para manter os relacionamentos e links necessários no catálogo de serviços
e no CMS.

Muitas organizações descobriram que é importante produzir padrões e um conjunto de

pro-formas ou modelos que podem ser usados como ponto de partida para todos os
SLAs, SLRs e OLAs. O pro-forma pode muitas vezes ser desenvolvido ao lado do SLA de
rascunho. O desenvolvimento de padrões e modelos garantirá que todos os contratos
sejam desenvolvidos de maneira consistente, o que facilitará seu uso, operação e
gerenciamento subsequentes. Orientação sobre os itens a serem incluídos em um SLA é
fornecida no Apêndice F.

O texto dos SLAs deve ser claro e conciso e não deixar espaço para ambigüidade.
Geralmente, não há necessidade de acordos escritos em terminologia jurídica, e a
linguagem clara ajuda em um entendimento comum. Muitas vezes é útil ter uma pessoa
independente, que não tenha se envolvido com a redação, para fazer uma leitura final.
Isso geralmente identifica possíveis ambigüidades e dificuldades que podem ser
abordadas e esclarecidas. Por esse motivo, é recomendável que todos os SLAs
contenham um glossário, definindo quaisquer termos e fornecendo clareza para
quaisquer áreas de ambigüidade.

Também vale lembrar que os SLAs podem ter que cobrir os serviços oferecidos
internacionalmente. Nesses casos, o SLA pode ter que ser traduzido em vários idiomas.
Lembre-se também que um SLA elaborado em um único idioma pode ter que ser
revisado para adequação em várias partes do mundo (ou seja, uma versão elaborada na
Austrália pode ter que ser revisada para adequação nos EUA ou no Reino Unido),
portanto, as diferenças terminológicas , estilo e cultura devem ser levados em conta.

Quando os serviços de TI são fornecidos a outra organização por um provedor de

serviços externo, às vezes os destinos de serviço estão contidos em um contrato e, em
outros momentos, estão contidos em um SLA ou cronograma anexado ao contrato. Seja
qual for o documento usado, é essencial que as metas documentadas e acordadas sejam
claras, específicas e não ambíguas, pois fornecerão a base do relacionamento e da
qualidade do serviço prestado.

Determining, documenting and agreeing requirements for new

services and producing SLRs

Essa é uma das primeiras atividades no estágio de design de serviço do ciclo de vida do
serviço. Uma vez que o catálogo de serviços tenha sido produzido e a estrutura do SLA
tenha sido acordada, as primeiras SLRs devem ser elaboradas. Uma SLR é uma exigência
do cliente para um aspecto de um serviço de TI. As SLRs são baseadas em objetivos de
negócios e são usadas para negociar metas de nível de serviço acordadas. As SLRs
referem-se principalmente à garantia do serviço: Quais níveis de serviço são exigidos
pelo cliente para que eles possam receber o valor da utilidade do serviço? Como
disponível o serviço precisa ser? Quão seguro? Com que rapidez deve ser restaurado se
falhar?

Embora muitas organizações devam dar prioridade inicial à introdução de SLAs para
serviços existentes, também é importante estabelecer procedimentos para concordar
com os requisitos de nível de serviço para novos serviços sendo desenvolvidos ou
adquiridos. As SLRs devem ser parte integrante dos critérios gerais de projeto de serviço,
que também incluem as especificações funcionais ou de "utilidade". As SLRs devem,
desde o início, fazer parte dos critérios de teste / teste conforme o serviço progride
através das etapas de projeto e desenvolvimento ou aquisição.

É aconselhável envolver os clientes desde o início, mas em vez de abordar os clientes

com uma 'página em branco', talvez seja melhor produzir um rascunho SLR com
possíveis metas de desempenho e requisitos operacionais e de gerenciamento, como
um ponto de partida para informações mais detalhadas e detalhadas. discussão
aprofundada. Tenha cuidado, porém, para não ir longe demais e parecer apresentar ao
cliente um "fato consumado", pois isso pode limitar desnecessariamente o diálogo
aberto e produtivo. Para garantir um foco nos resultados de negócios necessários, é
importante manter a clareza na diferença entre a SLR e a (s) meta (s) de nível de serviço
específica (s) associada à realização do SLR. Por exemplo, uma SLR relacionada ao
desempenho pode ser expressa pelo cliente como "rápida o suficiente para suportar o
volume previsto de pedidos a serem colocados durante os períodos de pico de atividade
sem falhas ou atrasos", enquanto a meta de nível de serviço negociada para suportar
esse requisito definirá tempos de resposta específicos e mensuráveis e as condições em
que a meta será considerada violada.

Não se pode enfatizar o quão difícil é essa atividade de determinar os alvos iniciais para
associação com uma SLR (ou eventual inclusão em um SLA). Representantes de todos os
outros processos precisam ser consultados para opinar sobre quais alvos podem ser
realisticamente alcançados, como a consultoria de gerenciamento de incidentes em
alvos de incidentes. Os processos de gerenciamento de capacidade e disponibilidade
terão um valor particular na determinação da disponibilidade de serviços apropriados e
dos objetivos de desempenho. Se houver alguma dúvida, as metas provisórias devem
ser incluídas em um SLA piloto que seja monitorado e ajustado por meio de um período
de suporte de vida antecipada, conforme ilustrado na Figura 3.8.

No desenvolvimento de SLRs, pode ser difícil extrair verdadeiros requisitos de negócios,

pois a empresa pode não saber o que quer - especialmente se não for solicitada
anteriormente. O negócio pode precisar de ajuda para entender e definir suas
necessidades, especialmente em termos de capacidade, segurança, disponibilidade e
continuidade dos serviços de TI. Esteja ciente de que os requisitos inicialmente
expressos podem não ser os que acabam sendo acordados. O cliente pode descrever o
que é desejado / necessário, após o qual o provedor de serviços deve investigar o que é
possível, juntamente com os custos e riscos associados às opções disponíveis,
apresentando essas informações ao cliente para revisitar o requisito originalmente
estabelecido. Várias iterações de negociações podem ser necessárias antes que um
equilíbrio acessível seja alcançado entre o que é procurado e o que é viável e acessível.
Esse processo pode envolver um novo design da solução de serviço sempre que uma SLR
e as metas de nível de serviço associadas forem revisadas.
Se novos serviços forem introduzidos de maneira transparente no ambiente ao vivo,
outra área que requer atenção é o planejamento e a formalização dos arranjos de
suporte para o serviço e seus componentes. Deve-se procurar aconselhamento sobre
gerenciamento de mudanças e gestão de ativos e configurações de serviços para garantir
que o planejamento seja abrangente e abranja a implementação, a implantação e o
suporte do serviço e seus componentes. Responsabilidades específicas precisam ser
definidas e adicionadas aos contratos de suporte existentes / OLAs, ou novos precisam
ser acordados. Os arranjos de suporte e todas as rotas de escalonamento também
precisam ser adicionados ao CMS, incluindo o catálogo de serviços, quando apropriado,
para que o service desk e a equipe de suporte estejam cientes deles. Quando
apropriado, o treinamento inicial e a familiarização para o service desk e outros grupos
de suporte e a transferência de conhecimento devem ser concluídos antes que o suporte
ao vivo seja necessário.

A definição e concordância dos OLAs provavelmente será altamente iterativa,

particularmente em uma organização com SLM imaturo. Muitos grupos ou funções
diferentes podem precisar se comprometer com os OLAs. Os requisitos propostos devem
ser comparados com o que pode realmente ser entregue por cada grupo, para que os
compromissos sejam realistas. Os requisitos individuais para cada grupo, juntamente
com as contribuições dos fornecedores, conforme documentado nos contratos
subjacentes, devem resultar em uma prestação de serviços integrada e bem coordenada
que suporte adequadamente as metas gerais de SLR.

Uma vez que as SLRs claramente definidas tenham sido determinadas, as metas
associadas ao nível de serviço inicial serão gradualmente refinadas à medida que o
serviço avança pelos estágios de seu ciclo de vida, até que elas eventualmente se
tornem parte de um SLA piloto durante o período inicial de suporte de vida. Veja a seção
4.3.5.3 para uma discussão dos SLAs piloto.

Negotiating, documenting and agreeing SLAs for operational

services

Antes que um serviço novo ou alterado seja aceito na operação ao vivo, um SLA deve ser
acordado, detalhando as metas de nível de serviço a serem atingidas e especificando as
responsabilidades do provedor de serviços de TI e do cliente. Para um novo serviço, é
provável que as metas no SLA sejam originadas de SLRs desenvolvidas no início do
estágio de design do serviço. Para alterações nos serviços existentes, os destinos
também podem ser definidos dessa maneira - como parte do desenvolvimento de SLR,
especialmente se a alteração no serviço for significativa ou se os novos destinos
puderem ser simplesmente refinamentos para destinos em um SLA existente.

Se uma organização está apenas começando a estabelecer o SLM e ainda não possui
SLAs para serviços existentes, o processo de defini-los pode exigir monitoramento,
medição e relatório dos níveis atuais de serviço que estão sendo fornecidos e usar essas
informações para informar as negociações com os clientes. para estabelecer metas
aceitáveis.

Usando as SLRs ou outras informações do cliente sobre os níveis de serviço necessários,

um SLA piloto ou de rascunho deve ser desenvolvido. O SLA deve ser desenvolvido
juntamente com o desenvolvimento do próprio serviço e gradualmente refinado,
formalizado e assinado antes que o serviço seja introduzido no uso ao vivo. O
desenvolvimento e finalização do SLA é um processo iterativo que requer o alinhamento
de muitas contribuições e dependências. À medida que as metas de SLA são elaboradas,
o SLM deve trabalhar com todos os envolvidos na prestação de serviços, garantindo que
as metas sejam alcançáveis e que tanto as equipes de suporte interno quanto os
fornecedores externos tenham expectativas claras e inequívocas sobre o que será
necessário para eles. Alvos de SLA. OLAs e contratos subjacentes ou outros acordos
devem ser atualizados ou criados para garantir clareza e identificar como os esforços de
apoio serão medidos e gerenciados.

Depois que o serviço novo ou alterado tiver sido implantado, o SLA piloto com suporte a
OLAs e contratos de apoio deverá estar pronto e os mecanismos de relatórios em vigor.
Durante o período inicial de suporte à vida, as conquistas em relação às metas devem
ser medidas, confirmando que as metas podem ser atingidas ou que o ajuste é
necessário. É dada preferência, é claro, à revisão da prestação de serviços para cumprir
as metas, em vez de revisar as próprias metas, mas independentemente de qual ajuste
for realizado, ela deve ser mutuamente acordada pelo cliente e pelo provedor de
serviços antes de assinar o SLA final.

No final do processo de elaboração, negociação e pilotagem, é importante garantir que o

SLA seja efetivamente assinado pelos gerentes apropriados no lado do cliente e do
provedor de serviços de TI. Isso dá um firme compromisso por ambas as partes de que
todas as tentativas serão feitas para atender ao acordo. De um modo geral, quanto mais
seniores os signatários estão dentro de suas respectivas organizações, mais forte é a
mensagem de compromisso. Uma vez que um SLA é acordado, uma ampla publicidade
precisa ser usada para garantir que clientes, usuários e equipe de TI estejam cientes de
sua existência e dos principais alvos.

Devem ser tomadas medidas para anunciar a existência dos novos SLAs e OLAs entre o
service desk e outros grupos de suporte, com detalhes de quando eles se tornam
operacionais. Pode ser útil extrair os principais alvos desses contratos em tabelas que
podem ser exibidas em áreas de suporte, para que a equipe esteja sempre ciente das
metas para as quais está trabalhando. Se as ferramentas de suporte permitirem, essas
metas devem ser registradas dentro das ferramentas, como em um catálogo de serviços
ou CMS, para que seu conteúdo possa ser amplamente disponibilizado para todo o
pessoal. Eles também devem ser incluídos como limites e automaticamente alertados
quando um alvo é ameaçado ou realmente violado. SLAs, OLAs e as metas que eles
contêm também devem ser divulgados entre a comunidade de usuários, para que os
usuários estejam cientes do que podem esperar dos serviços que usam e saibam em que
ponto começar a expressar insatisfação.

É importante que a equipe da central de atendimento esteja comprometida com o

processo de SLM e se torne embaixadores proativos dos SLAs, adotando a cultura de
serviços necessária, pois eles são o primeiro ponto de contato para os incidentes,
reclamações e consultas dos clientes. Se a equipe da central de atendimento não estiver
totalmente ciente dos SLAs em vigor e não agir de acordo com o conteúdo, os clientes
perderão rapidamente a confiança nos SLAs.

Deve-se notar que recursos de suporte adicionais (ou seja, mais pessoal) podem ser
necessários para dar suporte a serviços novos ou significativamente modificados. Muitas
vezes há uma expectativa de que um grupo de suporte já sobrecarregado de trabalho
possa lidar magicamente com o esforço adicional imposto por um novo serviço. Se esta
expectativa não for realista, as metas de nível de serviço relacionadas ao suporte podem
ser ameaçadas ou mesmo violadas.

Monitoring service performance against SLA

Nada deve ser incluído em um SLA, a menos que possa ser efetivamente monitorado e
medido em um ponto comumente acordado. A importância disso não pode ser
superestressada, pois a inclusão de itens que não podem ser monitorados de forma
eficaz quase sempre resulta em disputas e eventual perda de confiança no processo
SLM. Muitas organizações descobriram isso da maneira mais difícil e, como resultado,
absorveram altos custos, tanto em termos financeiros quanto em termos de impactos
negativos em sua credibilidade.

Os recursos de monitoramento existentes devem ser revisados e atualizados conforme

necessário. Idealmente, isso deve ser feito antes ou em paralelo com a elaboração dos
SLAs, para que o monitoramento possa ser implementado para auxiliar na validação das
metas propostas durante o estágio de transição do serviço.

É essencial que o monitoramento corresponda à verdadeira percepção do cliente sobre

o serviço. Infelizmente isso é muitas vezes muito difícil de alcançar. Por exemplo, o
monitoramento de componentes individuais, como a rede ou o servidor, não garante
que o serviço estará disponível no que diz respeito ao cliente. A percepção do cliente é
muitas vezes que, embora uma falha possa afetar mais de um serviço, sua única
preocupação é o serviço que ele não pode acessar no momento do incidente relatado.
Como os clientes e suas perspectivas variam, é preciso cautela. Sem monitorar todos os
componentes do serviço de ponta a ponta (o que pode ser muito difícil e caro de
conseguir), não é possível obter uma imagem real. Da mesma forma, os usuários devem
estar cientes de que devem relatar incidentes imediatamente para auxiliar os
diagnósticos, especialmente se estiverem relacionados ao desempenho, para que o
provedor de serviços esteja ciente de que as metas de serviço estão sendo violadas.
Um número considerável de organizações usa seu service desk, vinculado a um CMS
abrangente, para monitorar a percepção de disponibilidade do cliente. Isso pode
envolver a realização de alterações específicas nas telas de registro de incidentes /
problemas e pode exigir conformidade rigorosa com os procedimentos de registro de
incidentes. Tudo isso precisa de discussão e concordância com o processo de
gerenciamento de disponibilidade.

A central de serviços também é usada para monitorar tempos de resposta e tempo de

resposta, mas mais uma vez as telas de registro podem precisar de alteração para
acomodar a captura de dados, e os procedimentos de registro de chamadas podem
precisar ser rigorosamente seguidos. Se o suporte estiver sendo fornecido por terceiros,
esse monitoramento também poderá sustentar o gerenciamento de fornecedores.

É essencial garantir que todos os alvos de incidentes / problemas relacionados incluídos

nos SLAs sejam os mesmos que aqueles incluídos nas ferramentas do service desk e
aqueles usados para propósitos de escalonamento e monitoramento. Quando uma
organização falha em reconhecer isso e talvez tenha usado os padrões fornecidos pelo
fornecedor da ferramenta, ela acabou resultando em uma situação em que está
monitorando algo diferente do que foi acordado nos SLAs e, portanto, é incapaz de dizer
se o SLA os objetivos foram cumpridos, sem esforço considerável para manipular os
dados. Algumas alterações podem ser necessárias para suportar ferramentas, para
incluir os campos necessários para que dados relevantes possam ser capturados.

Uma área notoriamente difícil de monitorar é o tempo de resposta das transações (o

tempo entre enviar uma tela e receber uma resposta). Frequentemente, os tempos de
resposta de ponta a ponta são tecnicamente muito difíceis de monitorar. Em tais casos,
pode ser apropriado lidar com isso da seguinte maneira:
■■ Inclua uma declaração no SLA ao longo das seguintes linhas: 'Os serviços
cobertos pelo SLA são projetados para resposta de alta velocidade e não devem
ser encontrados atrasos significativos. Se um atraso no tempo de resposta de
mais de x segundos for observado por mais de y minutos, isso deve ser
reportado imediatamente ao service desk.
■■ Concordar e incluir no SLA uma meta aceitável para o número de tais
incidentes que podem ser tolerados no período do relatório.
■■ Crie uma categoria de incidente de "resposta insatisfatória" (ou similar) e
garanta que esses incidentes sejam registrados com precisão e que estejam
relacionados ao serviço apropriado.
■■ Produza relatórios regulares de ocasiões em que as metas de tempo de
resposta da transação de SLA tenham sido violadas e instigue investigações por
meio do gerenciamento de problemas para corrigir a situação.
Essa abordagem não apenas supera as dificuldades técnicas de monitoramento,
mas também garante que os incidentes de resposta fraca sejam relatados no
momento em que ocorrem. Isso é muito importante, pois a resposta fraca é
frequentemente causada por vários eventos de interação transitória que só
podem ser detectados se forem investigados imediatamente.

O método preferido, no entanto, é implementar alguma forma de

monitoramento de tempo de resposta de cliente / servidor automatizado em
estreita consulta com a operação de serviço. Sempre que possível, implemente
ferramentas e técnicas de amostragem ou "robô" para fornecer indicações de
desempenho lento ou ruim. Essas ferramentas fornecem a capacidade de medir
ou amostrar tempos de resposta reais ou muito semelhantes àqueles que estão
sendo experimentados por uma variedade de usuários, e estão se tornando cada
vez mais disponíveis e cada vez mais eficazes em termos de custo para usar.

Se o SLA incluir metas para avaliar e implementar RFCs, o monitoramento de

metas relacionadas ao gerenciamento de mudanças deve ser idealizado usando
qualquer ferramenta de gerenciamento de alterações em uso (de preferência
parte de uma ferramenta integrada de suporte ao gerenciamento de serviços) e
alterar as telas de registro e os processos de escalonamento deve apoiar isso.

Producing service reports

Imediatamente após o SLA ser acordado e aceito, o monitoramento deve ser instigado, e
os relatórios de desempenho do serviço devem ser produzidos. Os relatórios
operacionais devem ser produzidos com frequência (semanalmente ou talvez com maior
frequência) e, sempre que possível, devem ser produzidos relatórios de exceção sempre
que um SLA for quebrado (ou ameaçado, se limites apropriados forem definidos para dar
um "aviso antecipado"). Às vezes, são encontradas dificuldades para atingir as metas de
novos serviços durante o período de suporte inicial, devido ao alto volume de RFCs.
Limitar o número de RFCs processados durante o período de suporte inicial pode limitar
o impacto das alterações.

Os mecanismos de relatório de SLA, intervalos e formatos de relatório devem ser

definidos e acordados com os clientes. A frequência e o formato das reuniões de revisão
de serviço também devem ser acordados com os clientes. Intervalos regulares são
recomendados, com relatórios periódicos sincronizados com o ciclo de revisão.

Relatórios periódicos devem ser produzidos e divulgados aos clientes (ou seus
representantes) e aos gerentes de TI apropriados alguns dias antes das revisões de nível
de serviço, para que quaisquer dúvidas ou discordâncias possam ser resolvidas antes da
reunião de revisão. A reunião não é então desviada por tais questões.
Os relatórios periódicos devem incorporar detalhes de desempenho em relação a todas
as metas de SLA, juntamente com detalhes de quaisquer tendências ou ações específicas
sendo realizadas para melhorar a qualidade do serviço. Uma técnica útil é incluir um
gráfico de monitoramento de SLA (SLAM) na frente de um relatório de serviço para
fornecer uma visão geral rápida de como as conquistas foram comparadas às metas. Eles
são mais eficazes se codificados por cores (vermelho, âmbar, verde e às vezes chamados
de gráficos RAG como resultado). Outros relatórios intermediários podem ser exigidos
pelo gerenciamento de TI para o OLA ou revisões internas de desempenho e / ou
gerenciamento de fornecedores. É provável que esse seja um processo em evolução -
um primeiro esforço provavelmente não será o resultado final.

Os recursos necessários para produzir e verificar relatórios não devem ser subestimados.
Pode ser extremamente demorado e, se os relatórios não refletirem a percepção do
cliente sobre a qualidade do serviço com precisão, eles podem piorar a situação. É
essencial que informações precisas de todas as áreas e todos os processos (por exemplo,
gerenciamento de incidentes, gerenciamento de problemas, gerenciamento de
disponibilidade, gerenciamento de capacidade, gerenciamento de alterações e
gerenciamento de ativos e configurações de serviço) sejam analisadas e agrupadas em
um relatório conciso e abrangente sobre desempenho de serviços. medida em
comparação com os objetivos de negócios acordados.

O SLM deve identificar as necessidades específicas de relatórios e automatizar a

produção desses relatórios, na medida do possível. A extensão, precisão e facilidade
com que relatórios automatizados podem ser produzidos devem fazer parte dos critérios
de seleção para ferramentas de suporte integradas. Esses relatórios de serviço não
devem incluir apenas detalhes do desempenho atual em relação às metas, mas também
fornecer informações históricas sobre desempenho e tendências anteriores, para que o
impacto das ações de melhoria possa ser medido e previsto.