Pos UNIP - Gestão Estratégica de Serviços de TI - Unidade VI

Prévia do material em texto

Livro Texto 
 
Disciplina: Gestão Estratégica de Serviços de TI Unidade: VI 
Professor: Valdir Morales 
 
 
6 OPERAÇÃO E MELHORIA DE SERVIÇO EM TI 
 
6.1 Introdução 
 
 
O livro Operação de Serviço (Service Operation) envolve a descrição de práticas 
de Gerenciamento de Serviço em Operação. 
 
Provê direcionamento em como entregar e suportar serviços de forma efetiva e 
eficiente, garantindo a entrega de valor para o cliente. 
 
Processos do Livro Operação de Serviço: 
 Gerenciamento de Evento. 
 Gerenciamento de Incidente. 
 Cumprimento de Requisição. 
 Gerenciamento de Problema. 
 Gerenciamento de Acesso. 
 
 
Funções: 
 Central de Serviço (Service Desk). 
 Gerenciamento Técnico (Technical Management). 
 Gerenciamento de Operações de TI (IT Operations Management): 
 Controle de Operações de TI. 
 Gerenciamento das instalações. 
 Gerenciamento de Aplicativo (Application Management). 
 
 
Metas e Objetivos 
 
O propósito da Operação de Serviço é entregar e gerenciar Serviços de TI em 
níveis acordados para usuários e clientes do negócio. 
 
 
Valor para o Negócio 
 
 
Em termos de agregar valor ao negócio, é na fase da Operação de Serviço que o 
valor do serviço é, na prática, percebido pelos clientes. 
 
 
 
 
 
Balanceamento de Conflitos 
 
A Operação de Serviço é mais que a execução repetitiva de um padrão de 
procedimentos ou atividades. 
Todas as funções, processos e atividades são definidas para entregar serviços 
específicos e acordados com seus respectivos níveis, porém devem ser entregues 
em ambientes de constantes mudanças. 
O potencial conflito de papéis entre as visões externas e internas relacionadas 
aos serviços de TIC é resultado de muitas variáveis, incluindo a maturidade da 
Organização, a cultura de gerenciamento, sua história. 
 
 
Serviços de TI x Componentes Tecnológicos 
 
A visão do cliente (externa) corresponde a forma como ele utiliza (ou percebe) o 
serviço. 
A visão da TI (interna) corresponde a maneira como sistemas e componentes são 
administradas. 
 
 
Estabilidade x Capacidade de Resposta 
 
Não importa quão boa seja a funcionalidade de um serviço de TI e não importa o 
quão bem ele foi projetado, ele valerá muito pouco se os componentes de serviço 
não estiverem disponíveis ou não funcionarem de forma consistente. 
Isto significa que a Operação de Serviço deve garantir que a Infraestrutura de TI 
seja estável e esteja disponível conforme projetada e, ao mesmo tempo, precisa 
reconhecer que o Negócio e os requisitos de TI mudam. 
 
 
Qualidade x Custo 
 
A operação de serviço é requerida constantemente a entregar níveis de serviço 
para seus clientes e usuários, enquanto que ao mesmo tempo deve manter os custos 
e utilização de recursos em nível otimizado. 
 
 
 
Reatividade X Pró-atividade 
 
Uma organização reativa é aquela que agre quando é requerida alguma ação sua 
por um direcionador externo. 
Exemplos: 
 Um novo requisito de negócio. 
 Uma aplicação que foi desenvolvida. 
 Escalação realizada devido a reclamações feitas por usuários e clientes. 
 
Uma Organização proativa procura sempre maneiras para melhorar a situação 
atual, procurando por sinais de mudanças que possam potencialmente impactar 
positivamente a Organização. 
 
O comportamento proativo é geralmente visto como positivo, especialmente 
quando habilita a Organização a manter uma vantagem competitiva e um gerente de 
mudanças. 
 
 
6.1 Gerenciamento de Evento (Event Management) 
 
É responsável por monitorar o Serviço de TI e detectar quando o desempenho cai 
abaixo de limites aceitáveis. 
 
Desenvolver habilidade para detectar eventos, determinar como um evento faz 
sentido em relação a outros (correlacionamento entre eventos) e determinar a ação 
de controle apropriada. 
 
Comparar o comportamento e desempenho atuais do serviço contra os padrões 
do desenho de serviço e ANSs. 
 
Um evento pode ser definido como qualquer ocorrência detectável ou discernível 
que tem importância para a gestão do Infraestrutura de TI ou a entrega de serviços 
de TI e avaliação do impacto um desvio poderá causar aos serviços. Os eventos são 
tipicamente notificações criadas por um serviço de TI, Item de Configuração (CI) ou 
monitoramento ferramenta. 
 
Eficaz Operação de Serviço é dependente de saber o estado da infraestrutura e 
detectar qualquer desvio do normal ou esperado operação. Isto é proporcionado pelo 
bom monitoramento e controlar sistemas, que são baseados em dois tipos de 
ferramentas: 
• monitoramento ativo ferramentas que CIs enquete chave para determinar o seu 
estado e disponibilidade. Qualquer exceção irá gerar um alertar que precisa ser 
comunicada para a ferramenta apropriada ou equipe para a ação. 
 
• monitoramento passivo ferramentas que detectam e correlacionar operacional 
alertas ou comunicações geradas pela CEI. 
 
 
 
Alerta (Alert) 
 
É um aviso de que um limiar (threshold) foi atingido, que algo mudou ou uma falha 
ocorreu. 
Alertas são frequentemente criados e gerenciados por sistemas de 
gerenciamento (ferramentas) e são tratados no processo Gerenciamento de Evento. 
 
 
Evento (Event) 
 
Qualquer mudança de estado que tenha significado par ao gerenciamento de um 
item de configuração ou serviço de TI. 
O termo evento é também utilizado para identificar um alerta ou notificação criado 
por qualquer serviço de TI, Item de configuração ou ferramenta de Monitoração; 
Eventos, tipicamente requerem profissionais de operação de ti na tomada de 
decisões e frequentemente requerem a abertura e registro de incidentes. 
 
 
 
Categorias de Eventos 
 
• Informacional: Eventos que significam uma operação regular. Exemplo: Login 
de um usuário. 
• Exceção: Eventos que significam uma exceção: Exemplo: Consumo de 
recursos além do esperado. 
• Aviso: Eventos que significam operação não usual (alertas), porém não são 
exceções: Exemplo: Consumo de memória 5% acima do esperado por um 
breve espaço de tempo. 
 
 
Diferença entre Monitoração e Gerenciamento de Evento 
 
Gerenciamento de Evento é focado na geração e detecção de notificações 
significativas a respeito do estado da infraestrutura e serviços de TI. 
Monitoração é mais amplo que o Gerenciamento de Evento. Por exemplo, 
ferramentas de monitoração verificarão o estado de um dispositivo para garantir que 
ele esteja operando dentro dos limites aceitáveis, mesmo que aquele dispositivo não 
esteja gerando eventos. 
 
 
 
 
 
6.2 Gerenciamento de Incidente (Incident Management) 
 
Os principais objetivos do processo Gerenciamento de Incidente são: 
• Restaurar a operação normal do serviço o mais rápido possível. 
• Minimizar o impacto adverso nas operações do negócio. 
 
Gerenciamento de Incidente é o processo para tratar todos os incidentes, os quais 
podem incluir: 
• Eventos que são comunicados diretamente pelos usuários através da central 
de serviço. 
• Identificados através da ferramenta de monitoração de eventos com interface 
para o Gerenciamento de Incidente. 
• Incidentes reportados pelo pessoal técnico. 
 
Incidente ‘É definido como: Uma interrupção não planejada a um execução de 
serviços de TI ou redução do qualidade de um serviço de TI. É também um incidente, 
por exemplo falha de um disco a partir de um conjunto de espelho. 
 
O principal objetivo do processo de Gerenciamento de Incidentes é restaurar 
normal operação de serviço o mais rapidamente possível e minimizar os efeitos 
adversos impacto em operações comerciais, garantindo assim que os melhores 
níveis possíveis de qualidade de serviço e disponibilidade são mantidos. 'Operação 
de serviço Normal' é definida aqui como operação de serviço dentro SLA limites. 
 
 
Incidente (Incident) 
É uma interrupção não planejada ou redução na qualidade de um serviço de TI. 
A falha de um Item de Configuração que ainda não afetou o Serviço de TI poderágerar um incidente. 
Por exemplo, uma falha em uma unidade de disco espelhado. 
 
Impacto (Impact) 
E a medida do efeito de um incidente, problema ou mudança nos processos de 
negócios. O impacto é sempre baseado em como os níveis de serviço serão 
afetados. 
 
Urgência (Urgency) 
E uma medida de quão longo será o tempo até que um Incidente, Problema ou 
Mudança tenha um impacto significativo para o Negócio. 
Exemplo: um incidente de alto impacto pode ter uma urgência baixa se o impacto 
não afetar o negócio até o final do ano financeiro. 
 
Impacto e Urgência devem ser utilizados para definir a Prioridade. 
 
 
Prioridade (Priority) 
É uma categoria utilizada para identificar a importância relativa de um Incidente, 
Problema ou Mudança. 
 
A prioridade deve ser baseada no Impacto e Urgência. É utilizada para identificar 
os tempos requeridos para a realização das respectivas ações. 
Exemplo: Um Acordo de Nível de Serviço (ANS) pode declarar que os Incidentes 
com Prioridade do tipo 2 devem resolvidos dentro de 90 minutos. 
 
Solução de Contorno (Workaround) 
É a redução ou eliminação do impacto de incidente ou problema no qual a 
resolução completa ainda não está disponível. Por exemplo reiniciar um item de 
configuração falho. 
 
 Soluções de Contorno para problemas devem ser documentadas nos registros 
de Erros Conhecidos. 
 
As soluções de contorno para incidentes que não possuem registros de 
problemas associados devem ser documentadas nos registros de incidentes. 
 
 
Modelo de Incidente (Incident Models) 
 
Um Modelo de Incidente é uma forma de pré-definir os passos que devem ser 
seguidos para manusear um incidente, de uma maneira acordada. 
Ferramenta de suporte podem ser utilizadas para gerenciar o processo requerido. 
 
Definem: 
• Passos a serem executados. 
• Ordem cronológica dos passos. 
• Responsabilidades. 
• Tempo de execução. 
• Procedimentos de escalonamento. 
• Geração de evidências. 
 
 
Incidentes Graves (Major Incidents) 
 
Incidente grave tem uma alta prioridade ou alto impacto no negócio. 
Incidentes Grave requerem: 
 
 Procedimentos específicos e separados, com prazo de execução menor e 
urgência maior. 
 Uma definição do que constitui um incidente grave acordada e mapeada no 
mecanismo de priorização de incidente. 
 
 
 
Atividades do Gerenciamento de Incidentes 
 
 Identificar Incidente 
 
Corresponde a percepção de que um incidente ocorreu. 
Todos os componentes-chave deveriam ser monitorados para que falhas (ou 
falhas em potencial) possam ser detectadas rapidamente, de forma que o processo 
de Gerenciamento de incidente possa ser iniciado. 
 
 
 Registrar Incidente 
 
Incidentes podem ser comunicados por qualquer um que detecte uma interrupção 
ou potencial interrupção na operação normal do serviço. Isto inclui a equipe técnica 
ou, automaticamente através de uma ferramenta de detecção de eventos. 
 Número de identificação. 
 Categorização. 
 Urgência, Impacto e Priorização. 
 Data e horário. 
 Sintomas. 
 Itens de Configuração associados. 
 Erros conhecidos associados. 
 
 
 Categorizar Incidentes 
 
 Parte do registro inicial. 
 Identifica o tipo de incidente. 
 Solicitações de Serviço são algumas vezes incorretamente registradas 
como incidentes. Essa verificação detectará qualquer solicitação e 
garantirá que elas sejam passadas ao processo de Cumprimento de 
Requisição. 
 Categorização de múltiplos níveis está disponível nas principais 
ferramentas – usualmente de três a quatro níveis de granularidade. 
 
 
 
 Priorizar Incidente 
 
Priorização pode normalmente ser determinada, levando em conta ambos, a 
urgência do incidente (o quão rapidamente o negócio necessita de uma resolução) e 
o nível de impacto que ele está causando. 
 
 
 Diagnosticar inicialmente 
 
Se o incidente iniciou via Central de Serviço, o Analista de Central de Serviço 
precisa executar o diagnóstico inicial, tipicamente enquanto o usuário permanece ao 
telefone, para tentar descobrir todos os sintomas do incidente e determinar 
exatamente o que está errado (scripts de diagnóstico) e a forma de resolução (erros 
conhecidos). 
 
 
 Escalonar Incidente 
 
É a atividade que auxilia na resolução oportuna de um incidente. 
 
 Funcional (Funcional Escalation) - necessidade de competência. 
 Hierárquica (Hierarchic Escalation) - necessidade de autoridade. 
 
 
 Investigar e Diagnosticar 
 
 Identificar o que está errado. 
 Entender a ordem cronológica dos eventos. 
 Identificar os eventos que podem ter gerado o incidente. 
 Identificar possíveis soluções ou eventos semelhantes nas bases de erros 
conhecidos e de incidentes. 
 
 
 Resolver e Recuperar 
 
Quando uma resolução em potencial tiver sido identificada, esta deve ser aplicada 
e testada. As ações específicas a serem tomadas e as pessoas que estarão 
envolvidas nas ações de recuperação podem variar, dependendo da natureza da 
falha. 
 
 
 Fechar Incidente 
 
 
A central de serviços deve verificar se o incidente está completamente resolvido, 
se os usuários estão satisfeitos e se concordam que o incidente pode ser fechado. 
Categorização de fechamento. 
Pesquisa de satisfação do usuário. 
Documentação do Incidente. 
Encerramento formal. 
 
 
Indicadores-Chave de Desempenho (Key Performance Indicator – KPI) 
 
 Quantidade total de incidentes (como uma medida de controle). 
 Avaliação dos incidentes em cada estágio (por exemplo, registrado, trabalho 
em andamento, encerrado, etc). 
 Quantidade de incidentes abertos e não resolvidos (backlog). 
 Número e porcentagem dos incidentes principais. 
 Tempo Médio decorrido para conseguir a resolução ou contorno, quebrado por 
código de impacto. 
 Porcentagem de incidentes manuseados dentro do tempo de resposta 
acordado (objetivos de tempo de resposta a incidentes podem ser 
especificados nos ANS). 
 
 
6.3 Cumprimento de Requisição (Request Fulfilment) 
 
 É o processo responsável pela obtenção e entrega de componentes de 
serviços padrão requisitados. 
 Prover um canal para os usuários solicitarem e receberem serviços padrão para 
o quais existe uma aprovação predefinida e processo de qualificação. 
 Prover informação aos usuários e clientes sobre a disponibilidade dos serviços 
e os procedimentos para obtê-los. 
 Dar origem a distribuir os componentes dos serviços padrão requisitados; como 
exemplo, licenças de softwares. 
 Dar assistência com informação geral, reclamação ou comentários. 
 Fornecer informações para comparar o desempenho atual com os padrões de 
desenho não é uma tarefa do Cumprimento de Requisição. O processo de 
Cumprimento de Requisição fornece serviços/produtos aos usuários finais. 
 
 
Requisição de Serviço (Service Request) 
 
Uma requisição de um usuário por uma informação, orientação ou para uma 
Mudança Padrão. 
Exemplos: 
 Um Reset de senha. 
 
 Provisionamento de um Serviço de TI padrão para um novo usuário. 
 Requisições de Serviços são geralmente tratadas pela Central de Serviço e não 
requerem a submissão de uma Requisição de Mudanças (RDM). 
 
 
6.4 Gerenciamento de Problema (Problem Management) 
 
São objetivos válidos do Gerenciamento de Problema: 
 Prevenir Problemas e seus incidentes resultantes. 
 Gerenciar Problemas durante tudo o seu ciclo de vida. 
 Eliminar incidentes recorrentes. 
 Encontrar a causa raiz do problema e aplicar uma solução definitiva para a 
resolução do problema. 
 Minimizar o impacto de incidentes que não podem ser prevenidos. 
 
A ITIL define um "problema' Como a causa de um ou mais incidentes. 
Gerenciamento de Problemas é o processo responsável pela gestão do ciclo de vida 
de todos os problemas. Os objetivos de Gerenciamento de Problemas são para evitar 
problemas e incidentes resultantes de acontecer, para eliminar incidentes 
recorrentes e minimizar o impactode incidentes que não podem ser evitados. 
 
Gerenciamento de Problemas inclui as atividades necessárias para diagnosticar 
a causa raiz de incidentes e determinar a resolução para aqueles problemas. 
Também é responsável por assegurar que a resolução é implementada através da 
adequada controlar procedimentos, especialmente Gestão da Mudança e 
Gerenciamento de Liberação. 
 
 
Problema (Problem) 
É a causa não conhecida de um ou mais incidentes. 
A causa não é conhecida no momento que o registro do Problema é criado e o 
processo Gerenciamento de Problema é responsável pelas investigações adicionais. 
 
Erro Conhecido (Know Error) 
É um problema que possui a sua causa-raiz identificada e uma solução de 
contorno documentada. Erros conhecidos são criados após a solução de contorno 
ter sido encontrada e gerenciados através de seu ciclo de vida pelo Gerenciamento 
de Problema. 
 
 
6.5 Gerenciamento de Acesso (Access Management) 
 
O Gerenciamento de Acesso é responsável por fornecer os direitos de uso a um 
serviço de TI ou grupo de serviços. 
 
O processo corresponde à execução de políticas e ações definidas nos processos 
de Gerenciamento de Segurança e Gerenciamento da Disponibilidade. 
Gerenciamento de Acesso é o processo de concessão de autorização usuário 
direito de usar um serviço, enquanto impedindo o acesso a usuários não-autorizados. 
Também tem sido referido como Direitos Gestão ou Gestão de Identidade em 
diferentes organizações. 
 
Objetivo 
 
Gerenciamento de Acesso prevê o direito de que os usuários possam usar um 
serviço ou grupo de serviços. É, portanto, a execução de políticas e ações definidas 
no Segurança e Gerenciamento de Disponibilidade. 
 
Gerenciamento de Acesso é efetivamente a execução de disponibilidade e 
Gestão de Segurança da Informação, na medida em que permite que a organização 
para administrar o confidencialidade, disponibilidade e integridade de dados da 
organização e de propriedade intelectual. 
 
Gerenciamento de Acesso garante que os usuários têm o direito de usar um 
serviço, mas não garante que esse acesso está disponível em todos os momentos 
acordados - esta é fornecida pelo Gerenciamento de Disponibilidade. 
 
Gerenciamento de Acesso é um processo que é executado por todos os técnicos 
e Aplicação de Gestão de funções e não é geralmente uma função separada. No 
entanto, não é provável que seja um único controlar ponto de coordenação, 
geralmente em TI Gestão de Operações ou sobre o Service Desk. 
 
Gestão de acesso pode ser iniciada por um Solicitação de Serviço através do 
Service Desk. 
 
 
Acesso (Access) 
Refere-se ao nível e extensão da funcionalidade de um serviço ou dado que é 
permitido a um usuário utilizar. 
 
Identidade (Identity) 
Refere-se a informação sobre o usuário, que o distingue dos demais e que 
demonstra sua situação dentro da Organização. Por definição, a identidade de um 
usuário é exclusiva. 
 
Direitos ou Privilégios (Rights) 
Referem-se a regulamentação definida, que determina o acesso a ser oferecido 
ao usuário para um usuário para um serviço ou grupo de serviços. Os direitos típicos 
(ou níveis de acesso) incluem leitura, gravação, execução, alteração e remoção. 
 
 
 
6.6 Funções 
 
Central De Serviço (Service Desk) 
 
Prover um ponto único de contato para os clientes e usuários a fim de gerenciar 
a Resolução de Incidentes e assuntos relacionados ao suporte. 
 
Facilitar a resolução da operação normal do serviço com o mínimo de impacto 
para os Negócios dos Clientes, dentro dos requisitos e prioridades definidos nos 
Acordos de Nível de Serviços (ANS). 
 
É fato que a Central de Serviço desempenha um papel importante no 
Gerenciamento de Incidentes, pois ela vai receber os incidentes e fazer registro, 
classificação e primeiro nível de atendimento. Entretanto, ela não é a proprietária 
deste processo. 
 
Para cada processo na ITIL há um Process Owner, alguém na organização 
assume este papel. As funções, como a Central de Serviço, não são proprietárias de 
processos. 
 
Atividades que normalmente são executadas por uma Central de Serviço: 
 Registra detalhes de incidentes e de requisições de serviços. 
 Fornece investigação e diagnóstico em primeiro nível. 
 Restaurar Serviço. 
 
O Service Desk é uma unidade funcional formada por um número específico de 
pessoal responsável pelo tratamento de uma variedade de serviços eventos, muitas 
vezes feita através de chamadas telefónicas, interface web, ou eventos de 
infraestrutura automaticamente notificados. 
 
O Service Desk é uma parte vital do Departamento de TI de uma organização e 
deve ser o único ponto de contato para TI usuários em uma base dia-a-dia - e irá lidar 
com todos os incidentes e solicitação de serviços, geralmente usando ferramentas 
de software especializados para registrar e gerenciar todos esses eventos. 
 
O valor de um Service Desk eficaz não deve ser subestimado - um Service Desk 
bom muitas vezes pode compensar deficiências em outras partes da organização de 
TI, mas um Service Desk pobres (ou a falta de um Posto de Serviço) pode dar uma 
má impressão de uma outra maneira muito organização de TI eficaz. 
 
 
A natureza exata, tipo, tamanho e localização de um Service Desk pode variar, 
dependendo do tipo de negócio, número de usuários, a geografia, a complexidade 
das chamadas, escopo de serviços e de muitos outros fatores. 
 
Em alinhamento com cliente e de negócios exigências, os gerentes seniores da 
organização de TI, deve decidir a natureza exata de seu Service Desk necessária (e 
se deve ser interna ou terceirizada para uma terceiro) Como parte de sua ITSM geral 
estratégia e posterior planejamento deve ser feito para preparar e implementar o 
Service Desk apropriado a função. 
 
Central de Atendimento (Call Center) 
Manipula, profissionalmente, grandes volumes de ligações telefônicas para 
suportar serviços de televendas. 
 
Central De Suporte (Help Desk) 
Gerenciar, coordenar e resolver incidentes o mais rápido possível e assegurar 
que nenhum pedido seja perdido, esquecido ou ignorado. 
 
Central de Serviço (Service Desk) 
Aumenta o alcance dos serviços, lidando com incidentes, falhas e dúvidas, 
licenças de softwares, demanda de usuários, etc. 
Representa o fornecedor de serviço para o cliente e para o usuário (interno ou 
externo). 
Opera baseado no princípio de que a satisfação e a percepção do cliente são 
críticas. 
Depende da combinação de pessoas, processos e tecnologia para entregar o 
Serviço de Negócio. 
 
 
Estrutura Organizacional 
 
Natureza da Central de Serviço e Alinhamento com o negócio. Antes de desenhar 
a função Central de Serviço, a alta gerência precisa entender sobre a sua exata 
natureza e buscar alinhamento com o negócio. 
Tipo de negócio. 
Requisitos de Negócio e do Cliente: Tamanho, tipo e localização da Central de 
Serviço depende do tipo de negócio. 
Número de usuários, situação geográfica, complexidade dos chamados, 
linguagem e outros fatores. 
 
Tipos de Estrutura Organizacional: 
 
1. Central de Serviço Local 
 
Tradicionalmente, as Organizações criaram Centrais de Serviços locais para 
suportar as necessidades locais dos negócios. 
Considerações para implementação: 
 Estabelecer processos comuns através de todas as Centrais de Serviços e, 
onde for possível, procedimentos comuns. 
 Disponibilizar skills conhecimentos (localizados) para todas a centrais de 
serviços. 
 Utilizar o mesmo processo de escalonamento, código de impacto, severidade, 
prioridade e estados em todas as Centrais de Serviços. 
 Utilizar métricas comuns de desempenho. 
 
2. Central de Serviço Centralizada 
Todos os serviços requisitados são registrados em uma localidade física central; 
Considerações para implementação: 
 Custos operacionais reduzidos. 
 Visão gerencial consolidada. 
 Melhor uso de recursos disponíveis. 
 
3. Central de ServiçoVirtual 
Múltiplas Centrais de Serviços percebidas como uma. É utilizada pelos 
Usuários/Clientes em qualquer parte do mundo. 
Considerações para implementação: 
 Utilização de processos, procedimentos e terminologias comuns. 
 Utilização de idioma comum. 
 As ferramentas de suporte devem permitir visões, de acordo com região, perfil, 
etc. 
 
4. Central de Serviço Ininterrupta ou Siga o Sol (Follow the sun) 
Central de Serviços em diferentes fusos horários para cobertura 24 horas, as 
chamadas são transferidas para o local onde houver uma equipe trabalhando. 
 
 
 
Métricas da Central de Serviço 
 
Avaliação do desempenho da Central de Serviço em intervalos regulares. 
 
Alguns KPIs que podem ser estabelecidos: 
 Aumento da satisfação dos clientes e usuários. 
 Incidentes resolvidos durante o primeiro contato. 
 Custo médio de tratamento dos incidentes. 
 Tempo médio de resolução (no Service Desk). 
 O processo e procedimento em uso. 
 Tecnologia disponível de suporte à central de Serviço e outros. 
 
 Número adequado de pessoas para atender a demanda: 
 Quantidade e perfil da entrada de chamados. 
 Recursos que podem ser usados em períodos de pico: 
 Contratação de pessoas para serviços avulsos ou meio período. 
 Terceiros. 
 
 
Níveis de Conhecimento da Central de Serviço. 
 
A definição dos níveis de conhecimento necessários depende de: 
 Escopo e estrutura da Central de Serviço. 
 Voltada para atender e registrar chamados pouco conhecimento técnico. 
 Central de Serviço Técnica maior nível de conhecimento técnico. 
 Objetivos do nível de serviço. 
 Complexidade dos sistemas suportados. 
 Além de conhecimentos técnicos, sobre os serviços e negócios é necessário 
possuir habilidades interpessoais. 
 Treinamento. 
 Conscientização sobre os negócios, serviços de negócios suportados. 
 Conhecimento técnicos; conhecimentos sobe sistemas e serviços. 
 Retenção de pessoas. 
 Autoajuda – habilidade dos usuários resolverem as suas dificuldades sozinhas 
por meio: Da interface Web e da lista de opções tipo menu para autoajuda e 
requisições de serviço e uma interface direta para o software de tratamento 
dos processos de retaguarda. 
 
 
Gerenciamento Técnico (Technical Management) 
 
Apoiar o planejamento, implementar e manter a infraestrutura técnica para 
suportar os Processos de Negócio através de: 
 Topologia técnica bem projetada, resiliente e com custos efetivos. 
 Utilização adequada do conhecimento técnico para manter a infraestrutura em 
perfeitas condições. 
 Pronto uso do conhecimento técnico para rapidamente diagnosticar e resolver 
qualquer falha técnica que venha a ocorrer. 
 O Gerenciamento Técnico possui dois papéis importantes na Organização: 
 Possui o conhecimento técnico e especializado para gerenciar a infraestrutura, 
assegurando o apoio ao projeto, teste, gerenciamento e melhorias dos 
serviços de TI. 
 Provê recursos para suportar o gerenciamento do Ciclo de Vida dos Serviços 
em todas as fases do desenvolvimento, desenho, construção, transição, 
operação e melhoria contínua. 
 
 As equipes são agrupadas de acordo com seu conhecimento técnico 
determinado pela tecnologia a ser gerenciada: 
 Equipe ou departamento de Mainframe. 
 Equipe ou departamento de Servidores. 
 Equipe ou departamento de Storage. 
 Equipe ou departamento de Rede. 
 
 
Gerenciamento de Operações de TI (IT Operations Management) 
 
Manutenção do “status quo” para atingir a estabilidade das atividades e processos 
do dia-a-dia. 
Constante análise e melhoria para obter aperfeiçoamento dos serviços e redução 
de custos, com a manutenção de estabilidade, baseada em padrões de desempenho 
definidos durante a fase de Desenho de Serviço. 
Pronta aplicação do perfil operacional para diagnóstico e resolução de qualquer 
falha de operações. 
A função Gerenciamento de Operações de TI possuí duas sub-funções: 
 Controle de Operações de TI (Operations Control): Assegurar as atividades 
de rotina operacional e prover a monitoração centralizada e o controle das 
atividades usuais em um centro de comando operacional. 
 Gerenciamento das Instalações (Facilities Management): Gerenciar o ambiente 
físico de TI, usualmente o Data Center ou sala de computadores. 
 
 
Papéis 
 
O papel da função Gerenciamento de Operações executar as atividades do dia-
a-dia e procedimentos requeridos para gerenciar e manter a infraestrutura de TI, tal 
como entregar e suportar Serviços de TI nos níveis acordados. Os papéis por sub-
função, são: 
Controle de Operações: 
 Supervisiona a execução e monitoração das atividades operacionais, além dos 
eventos na infraestrutura de TI. 
 Executa tarefas rotineiras da área técnica, tais como: Gerenciamento de 
consoles, Programação de Jobs, Backup e Restore e atividade de 
manutenção. 
 
 
Gerenciamento das Instalações 
 
O Gerenciamento das Instalações é responsável pelo gerenciamento: 
1. De um Centro de Dados ou sala de computadores. 
2. Pelos equipamentos de energia e resfriamento. 
 
3. Por locais de recuperação de desastre. 
 
 
Gerenciamento de Aplicativo 
 
Função responsável por gerenciar aplicativos durante os seus ciclos de vida. 
O Gerenciamento de Aplicativo desempenha um papel em todos os aplicativos. 
Uma das principais decisões para a qual ele contribui é se devemos comprar um 
aplicativo ou construí-lo. 
Suportar os processos de negócio ajudando na identificação funcional dos 
requisitos de aplicação e então apoiar o desenho, transição, operação e melhoria 
destas: 
• Assegurar que os requisitos funcionais estão disponíveis para atender aos 
requisitos de negócio. 
• Organizar os perfis técnicos adequados para manter as aplicações em 
condições operacionais. 
• Imediata aplicação do perfil técnico para um rápido diagnóstico e resolução de 
qualquer falha técnica que ocorra na aplicação. 
 
O Gerenciamento de Aplicativo é responsável por gerenciar as aplicações através 
do seu ciclo de vida, incluindo responsabilidades como: decidir se a aplicação será 
desenvolvida na Organização ou adquirida no mercado. 
 
Essas responsabilidades recaem sobe dois níveis de papéis: 
• Identificação, desenvolvimento e refinamento do conhecimento para o 
desenho, teste, gerenciamento e melhoria de serviços de TI (neste papel, a 
função Gerenciamento de Aplicativo trabalha junto com Gerenciamento 
Técnico). 
• Treinamento e entrega da tecnologia requerida para suportar os serviços de TI, 
nas fases de desenho, construção, transição, operação e melhoria. 
 
 
 
Melhoria de Serviço Continuada (Continual Service Improvement) 
 
O livro Melhoria de Serviço Continuada provê direcionamento na identificação e 
implementação de melhoria dos serviços de TI que suportam os processos de 
Negócio. 
 
 
Metas e Objetivos 
 
• Rever, analisar e fazer recomendações sobre oportunidades de melhoria em 
todo o ciclo de vida do serviço. 
 
• Rever e analisar resultados de Acordos de Nível de Serviço (ANS); 
• Identificar e implementar atividades individuais para a melhoria da qualidade 
de Serviço de TI. 
• Melhorar custo e efetividade. 
• Garantir métodos de Gerenciamento de Qualidade aplicáveis para suportar as 
atividades de Melhoria Continuada. 
 
 
 
Modelo PDCA 
 
Edwards Deming é bastante conhecido por usa filosofia de gerenciamento que 
leva a alta qualidade, ao aumento da produtividade e a uma melhor posição 
competitiva. 
 
Este ciclo é particularmente aplicável ao processo de Melhoria de Serviço 
Continuada (MSC). Os quatros estágios deste ciclo são: Planejar (Plan), Executar 
(Do), Conferir (Check) e Atuar (Act). Após estes estágios existe uma fase de 
consolidação que objetiva evitar que se retorne à situação original. 
 
 
Processo de Melhorias - 7 Etapas 
 
1.Definir o que deve ser medido 
Os processos de Estratégia e Desenho de Serviço devem identificar o que deveser medido. 
 
2. Definir o que pode ser medido 
É a etapa “Onde nós queremos estar” do Modelo da Melhoria de Serviço 
Continuada (MSC). Nesta etapa, ocorre a definição de metas mensuráveis; 
O processo de Melhoria de Serviço Continuada pode conduzir a análise de gap 
para identificar as oportunidades para melhoria respondendo a questão “Como 
nós chegaremos lá?” 
 
3. Coleta dos dados 
Os dados são reunidos baseados em metas e objetivos identificados, de forma 
a responder adequadamente a questão “Nós chegamos onde queríamos?”. Os 
dados são coletados na Operação de Serviço. 
 
4. Processar os dados 
Os dados são processados em alinhamento com os CSFs e os KPIs 
especificados. Uma vez que os dados tenham sido racionalizados, a análise 
pode ser iniciada. 
 
 
5. Analisar os dados 
Nesta fase os dados se tornam informação identificando gaps de serviço, 
tendências e impacto no negócio. 
 
6. Apresentar e usar da informação 
É a apresentação e informação de um quadro exato dos resultados e esforços 
de melhoria aos principais interessados (stakeholders). Respondendo a 
questão “Nós chegamos lá?” 
 
7. Implementação de ação corretiva. 
São as ações que necessitam ser implementadas para melhorar o serviço, 
sendo comunicadas e explicadas para a Organização. A partir desta etapa, a 
Organização estabelece uma nova linha de base e o ciclo recomeça; 
O conhecimento adquirido é usado para otimizar, melhorar e corrigir os 
serviços. 
 
 
 Importância da Medição 
 
 Basicamente existem 4 razões para Monitorar e Medir: 
 Validar: validar decisões prévias. 
 Direcionar: direcionar um conjunto de atividades sequenciais para atingir 
um objetivo. 
 Justificar: Justificar, com uma evidência ou prova, sobe a necessidade de 
ações. 
 Intervir: Identificar ações corretivas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERÊNCIAS 
 
Textuais 
 
AKABANE, G. K. Gestão Estratégica da Tecnologia da Informação: conceitos, 
metodologias, planejamento e avaliações. São Paulo: Atlas, 2012. 
 
CMMI para Desenvolvimento – Versão 1.2. Carnegie Mellon University. Agosto de 
2006. 
 
COBIT 5 Modelo Corporativo para Governança e Gestão de TI da Organização. 
Estados Unidos da América, 2012. 
 
FERNANDES, A. A.; ABREU, V. F. de. Implantando a Governança de Ti - da 
Estratégia À Gestão Dos Processos e Serviços. Edição 3. Editora Brasport. Rio de 
Janeiro: Brasport, 2012). 
 
FITZSIMMONS, James A.; e FITZSIMMONS, Mona J. Administração de Serviços. 
São Paulo: Editora Nacional, 2005. 
 
Glossário e abreviações ITIL Português. Grown. v1.0, 29 de julho de 2011. 
 
ITIL Continual Service Improvement. Publisher TSO. 2nd edition (July 29, 2011). UK. 
 
ITIL Design Services. Publisher TSO. 2nd edition (July 29, 2011). UK. 
 
ITIL Operation Services. Publisher TSO. 2nd edition (July 29, 2011). UK. 
 
ITIL Strategy Services. Publisher TSO. 2nd edition (July 29, 2011). UK. 
 
ITIL Transation Services. Publisher TSO. 2nd edition (July 29, 2011). UK.