OSA - Suporte Operacional e Análise

Suporte Operacional e Análise

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Rocket clouds
OSA - Suporte Operacional e Análise por Mind Map: OSA - Suporte Operacional e Análise

1. Gerenciamento de Serviço

1.1. Serviço

1.1.1. Uma forma de entregar valor ao cliente, sem que o mesmo tenha que se preocupar com os custos e riscos associados

1.2. Gestão de Serviço

1.2.1. Conjunto especializado de capacidades operacionais para fornecimento de valor aos clientes na forma de serviço.

1.3. Capacidades

1.3.1. Tomar a forma de funções e processos para gerenciar os Serviços sobre um Ciclo de Vida

1.3.2. Especializados nas funções e processos nas diferentes fases do Ciclo de Vida do Serviço

1.3.3. Representa a capacidade, competência e confiança de uma organização para a ação

1.4. Gerenciamento de Serviço

1.4.1. É uma prática profissional suportada mundialmente por normas e esquemas de qualificação

1.5. Ativos de Serviço

1.5.1. Habilidades

1.5.2. Recursos

1.5.3. Exemplo do Funcionário que após alguns meses tem a capacidade de entregar valor para a organização

1.5.4. Gerenciamento do Serviço é a arte de transformar os recursos disponíveis (funcionários) em Serviços com valor pela utilização máxima das capacidades da organização.

1.6. Funções

1.6.1. Grupo de pessoas e as ferramentas que eles utilizam para executar um ou mais processos ou atividades

1.6.2. Fornecem estrutura e estabilidade para as organizações

1.6.3. São unidades independentes de organizações, com suas próprias habilidades e recursos

1.6.4. Confiam em processos para coordenação e controle multifuncional

1.6.5. Possuem sua própria base de conhecimento, construída pelas experiências

1.7. Processos

1.7.1. Conjunto de atividades estruturadas que foram desenhadas para alcançar um objetivo específico

1.7.2. Processos com a Gestão de Serviços são o núcleo de criação de valor para os envolvidos na organização.

1.7.3. Possui uma ou mais entradas e as transforma em saída definidas

1.7.4. Inclui todos os papéis, responsabilidades, ferramentas e controles de gerenciamento (medidas e métricas) necessárias para entregar as saídas

1.7.5. O ITIL é muito específico acerca do conceito de processo de ciclo fechado. O que define o sistema de ciclo fechado é que este é auto-corretivo e se auto-reforça.

1.7.6. Processos de ciclo aberto são desenhados para um propósito e não respondem bem a mudanças, enquanto a parte de feedback nos processos de ciclo fechado permitem correções.

1.7.7. Processo de ciclo aberto é um processo de controle em que o valor da saída não tem influência na entrada do processo

1.7.8. Processo de ciclo fechado é um processo de controle em que o valor da saída infuencia a entrada do processo de uma maneira que mantém o valor desejado

1.8. Papéis

1.8.1. Conjunto de responsabilidades, atividades e autoridades definidos em um processo e atribuído a uma pessoa ou equipe

1.8.2. Papéis existem nas funções

1.9. Matriz RACI

1.9.1. Utilizada para indicar papéis e responsabilidades em relação aos processos e atividades

1.9.2. Pode também ser utilizada para identificar sobreposição e lacunas nos processos ITIL documentado

1.10. Papéis específicos no processo

1.10.1. Dono do Serviço

1.10.1.1. Responsável por entregar um serviço particular conforme os acordos de nível de serviço

1.10.2. Dono do Processo

1.10.2.1. Garante que o processo esteja apto a produzir as saídas desejadas

1.10.2.2. Responsável por patrocinar, desenhar, buscar a melhoria contínua do processo e suas métricas

1.10.3. Gerente de Processo

1.10.3.1. Responsável por coordenar todas as atividades do gerenciamento do processo

1.10.3.2. Também coordenar todas as mudanças no processo

1.10.4. Gerente do Serviço

1.10.4.1. Responsável pela gestão contínua de produtos novos e existentes no processo e no serviço

1.11. Escopo do OSA

1.11.1. Fornece direcionamento em alcançar a eficiência e eficácia na entrega e suporte dos serviços para assegurar valor aos clientes e Provedor de Serviço.

1.11.2. Objetivos estratégicos são realizados através da Operação de Serviço, tornando-a uma habilidade crítica

1.11.3. Escopo inclui:

1.11.3.1. Serviços

1.11.3.1.1. Qualquer atividade que forma parte de um serviço está inclusa na Operação de Serviço

1.11.3.2. Processos de Gerenciamento de Serviço

1.11.3.2.1. O gerenciamento contínuo e execução de alguns processos de Gerenciamento de Serviço são executados na Operação de Serviço

1.11.3.3. Tecnologia

1.11.3.3.1. Todos os serviços requerem uma forma de tecnologia para serem entregues

1.11.3.4. Pessoas

1.11.3.4.1. São as pessoas que gerenciam processos, tecnologia e serviços

2. Gerenciamento de Evento

2.1. Visão Geral

2.1.1. Monitora todos os eventos que ocorrem na infraestrutura de TI

2.1.2. Ajuda a monitorar as operações normais e a detectar e escalar condições excepcionais

2.1.3. Evento

2.1.3.1. Qualquer ocorrência perceptível ou notada que tenha Impacto no gerenciamento da infraestrutura de TI ou na entrega de Serviços de TI

2.1.3.2. São notificações criadas por um Serviço de TI, Item de Configuração ou ferramenta de monitoração

2.2. Definição ITIL de Evento

2.2.1. Qualquer ocorrência perceptível ou detectável que tenha significância para o gerenciamento da infraestrutura de TI ou a entrega de serviço de TI e avaliação do impacto que um desvio possa ter causado nos Serviços

2.3. Objetivos

2.3.1. Rastrear Eventos

2.3.2. Entender o significado dos eventos

2.3.3. Determinar as ações apropriadas para gerenciar os Eventos

2.3.4. Automatizar atividades de rotina do Gerenciamento de Operações

2.3.5. Comparar o comportamento e desempenho reais com os padrões de desenho e Acordos de Nível de Serviço (ANS)

2.3.6. Usos adicionais do Ger. de Eventos

2.3.6.1. Comunicar informações operacionais, alertas e exceções

2.3.6.2. Automação

2.3.6.2.1. Execução de Scripts em dispositivos remotos

2.3.6.2.2. Envio de tarefas para processamento

2.3.6.2.3. Balanceamento da demanda para um serviço em vários dispositivos, visando melhorar o desempenho

2.3.7. Ger, de Eventos

2.3.7.1. É a base do Controle e Monitoração Operacional, Garantia do Serviço e Relatórios e Melhoria do Serviço

2.3.7.2. Principal processo onde os outros processos operacionais são construídos

2.4. Escopo

2.4.1. Aplica-se a qualquer parte do Ger. do Serviço que se queira automatizar e ter o controle

2.4.1.1. ICs

2.4.1.2. Condições Ambientais

2.4.1.3. Monitoração da utilização de Licenças de Software

2.4.1.4. Segurança

2.4.1.5. Atividades normais

2.4.2. Questões do Escopo do Ger. de Eventos na gestão do serviço

2.4.2.1. Já monitoramos nossos Serviços, o que há mais para ser feito?

2.4.2.2. Gerenciamento de Incidente não é a mesma coisa que Gerenciamento de Evento?

2.4.2.3. Já suportamos e gerenciamos aplicativos. Temos que fazer algo mais?

2.4.3. Diferença entre Monitoração e Gerenciamento de Evento

2.4.3.1. Duas áreas fortemente relacionadas

2.4.3.2. Foco do Ger. de Eventos é gerar e detectar notificações significativas sobre o status da infra e serviços de TI

2.4.3.3. Monitoração é mais amplo que o Ger. de Eventos

2.4.3.4. Ger. de Eventos trabalha com ocorrências geradas especificamente para serem monitoradas

2.4.3.5. Monitoração rastreia tais ocorrências, mas também irá atrás das condições que não geram eventos

2.5. Valor para o Negócio

2.5.1. Detecção antecipada dos Incidentes

2.5.2. Atividades automatizadas requerem monitoração em tempo real, utilizam muitos recursos e são caras. Ger. de Eventos monitora essas atividades utilizando exceções reduzindo o tempo de parada

2.5.3. Quando integrado com outros processos de Ger. de Serviço ajuda a sinalizar alterações de status ou exceções, permitindo uma resposta rápida

2.5.4. Possibilita automação das operações, o que contribui para melhor eficiência do sistema

2.6. Políticas, Princípios e Conceitos Básicos

2.6.1. Categorização de Eventos

2.6.1.1. Normal

2.6.1.1.1. Usuário logando na aplicação

2.6.1.1.2. E-mail chegando no devido destinatário

2.6.1.1.3. Notificação de conclusão de uma tarefa programada

2.6.1.2. Exceção

2.6.1.2.1. Não ocorrem regularmente

2.6.1.2.2. Necessitam intervenção

2.6.1.2.3. Dependendo da exceção, o controle poderá ser passado para

2.6.1.2.4. Usuários logando na aplicação com senha inválida

2.6.1.2.5. Utilização da CPU de um dispositivo acima da taxa aceitável

2.6.1.2.6. Um scan no PC revelando a instalação de um software não autorizado

2.6.1.3. Não Habituais, mas não exceções

2.6.1.3.1. Requer uma monitoração bem próxima

2.6.1.3.2. Geralmente a situação se resolve sozinha

2.6.1.3.3. Memória do servidor está próxima de 5% do seu nível mais alto de utilização

2.6.1.3.4. O tempo para concluir uma tarefa está 10% acima do normal

2.7. Ocorrência, Notificação e Detecção do Evento

2.7.1. Ocorrência do Evento

2.7.1.1. Nem todos os eventos são registrados ou detectados, embora ocorram continuamente. É importante para os envolvidos no processo para identificar e reconhecer os eventos que devem ser detectados

2.7.2. Notificação do Evento

2.7.2.1. Método pelo qual o ICs comunicam alguma informação

2.7.2.2. Geralmente os ICs utilizam o protocolo SNMP para gerar notificação

2.7.2.3. Definição de Eventos não devem ser gerada por tentativa e erro

2.7.2.3.1. Leva em consideração somente as necessidades imediatas da equipe que está gerenciando o dispositivo

2.7.2.3.2. Não facilita o bom planejamento nem a melhoria

2.7.2.3.3. Dificulta a monitoração e o ger. do serviço com relação aos dispositivos e à equipe

2.7.2.4. Revisar o conjunto de eventos como parte das atividades da MSC é uma abordagem melhor

2.7.2.5. Durante a transição do serviço pode configurar e testar as opções de geração de eventos.

2.7.2.5.1. Fica mais fácil de identificar se a notificação do evento possui dados relevantes e as pessoas notificadas são mais precisas

2.7.2.6. Durante o Desenho do serviço e a transição do serviço dados de notificação mais significativos e papéis necessitam ser definidos claramente e documentados para evitar o esquecimento de alguma etapa ou esforços duplicados

2.7.3. Detecção do Evento

2.7.3.1. Pode ocorrer

2.7.3.1.1. O agente que está executando no dispositivo irá detectá-lo

2.7.3.1.2. O Evento será transmitido diretamente para uma ferramenta de gerenciamento para ler e interpretar o significado do Evento

2.8. Filtragem e Importância do Evento

2.8.1. Filtragem do Evento

2.8.1.1. Porque é necessária?

2.8.1.1.1. Para decidir se o Evento deverá ser comunicado para uma ferramenta de gerenciamento ou será ignorado

2.8.1.1.2. Para evitar a geração do mesmo tipo de Evento

2.8.1.1.3. Não é necessária em alguns ICs onde todos os eventos são significativos

2.8.1.1.4. Não necessária quando são desativadas as notificações

2.8.1.1.5. Ajuda a determinar a importância do Evento

2.8.2. Importância do Evento

2.8.2.1. Informativo

2.8.2.1.1. Não requerem nenhuma ação e também não são exceções

2.8.2.1.2. Checar status dos dispositivos ou Serviços

2.8.2.1.3. Bons para gerar estatísticas

2.8.2.1.4. Exemplos

2.8.2.2. Aviso

2.8.2.2.1. Quando o Serviço ou dispositivo está próximo do limite aceitável

2.8.2.2.2. Notificam pessoas, processos ou ferramentas sobre uma situação que pode gerar uma exceção

2.8.2.2.3. Não são gerados quando um dispositivo falha

2.8.2.2.4. Exemplo

2.8.2.3. Exceção

2.8.2.3.1. Podem ser entradas para os processos de Gestão de Incidentes ou Gestão de Mudanças

2.8.2.3.2. Quando ocorre significa que o Serviço ou dispositivo está funcionando fora da normalidade.

2.8.2.3.3. Exceções significam que o ANS e o ANO já foram violados

2.8.2.3.4. Indícios

2.9. Correlação de Evento, Gatilhos e Seleção da Resposta

2.9.1. Correlação do Evento

2.9.1.1. Se refere à análise de um Evento significativo e à decisão sobre a medida a ser tomada, um procedimento realizado usando um mecanismo de correlação

2.9.1.2. O mecanismo de correlação é programado para comparar o Evento ao critério predefinido conhecido como regra de negócio

2.9.1.3. É definido baseado nos padrões de desempenho durante o Desenho do Serviço

2.9.1.4. Exemplos

2.9.1.4.1. Número de ICs gerando eventos similares

2.9.1.4.2. Quando um evento representa uma exceção

2.9.2. Geração do Gatilho do Evento

2.9.2.1. Após a categorização, o Evento deve ser correlacionado para determinar se precisa de alguma resposta ou gatilho

2.9.2.2. Um gatilho é o mecanismo empregado para iniciar uma resposta a um Evento reconhecido pela atividade de correlação

2.9.2.3. Exemplos

2.9.2.3.1. Gatilhos de incidentes que geram um registro no Ger. de Incidentes

2.9.2.3.2. Gatilhos de mudança que geram um RDM

2.9.3. Seleção da Resposta ao Evento

2.9.3.1. É o estágio que necessita escolher qual a resposta apropriada entre as opções disponíveis

2.9.3.1.1. Registro do Evento

2.9.3.1.2. Resposta Automática

2.9.3.1.3. Alerta e Intervenção Humana

2.9.3.1.4. Incidente, Problema ou Mudança

2.9.3.1.5. Abrir uma RDM

2.9.3.1.6. Abrir um registro de incidente

2.9.3.1.7. Abrir ou criar um link para um registro de Problema

2.9.3.1.8. Incidentes especiais

2.10. Revisão de Ações e Fechamento

2.10.1. Revisão

2.10.1.1. Checar e verificar eventos que foram gerados

2.10.2. Fechamento do Evento

2.10.2.1. Eventos com resposta automática são fechados quando um segundo evento é gerado

2.10.2.2. Eventos gerados por um Incidente, Problema ou Mudança devem ser fechados com o link para o devido processo envolvido

2.11. Gatilhos, Entradas e Saídas

2.11.1. Qualquer tipo de ocorrência pode gerar um evento, mas deve-se definir a importância e a ação a ser tomada

2.11.2. Importante definir gatilhos que incluem as entradas e saídas

2.11.2.1. Exceções de performance que afetam os ICs conforme as especificações, ANOs ou procedimentos padrão

2.11.2.2. Exceção no processo de negócio que está sendo monitorado pelo Ger. de Evento

2.11.2.3. O término de uma tarefa automatizada

2.11.2.4. Mudança de status de um dispositivo ou registro do banco de dados

2.12. Interfaces dos Processos

2.12.1. Exigem monitoração e controle

2.12.1.1. Aplicativos e processos de negócio

2.12.1.1.1. Aplicativo de negócio que reporta uma atividade anormal na conta do cliente pode ser uma fraude ou invasão

2.12.1.2. Sistema de Gerenciamento da Configuração (SGC)

2.12.1.2.1. Compara os eventos com a linha base padrão para determinar que qualquer mudança é oriunda de uma linha base autorizada

2.12.1.3. Gerenciamento de Ativos

2.12.1.3.1. Determinar o status do ciclo de vida do ativo

2.12.1.4. Gerenciamento do Conhecimento

2.12.1.4.1. Utiliza as informações geradas pelo Evento para decisões futuras sobre estratégias e desenho

2.13. Medição do Processo

2.13.1. Medir a eficiência e eficácia do processo de Ger. de Eventos

2.13.1.1. Identificando o número de eventos por categoria

2.13.1.2. Identificando o número de eventos por importância

2.13.1.3. Identificando o número e a porcentagem de eventos onde foi necessária a intervenção humana

2.13.1.4. Identificando o número e a porcentagem de eventos que resultaram em Incidentes ou Mudanças

2.13.1.5. Identificando o número e a porcentagem de Eventos resultantes de questões existentes ou Erros conhecidos que podem mudar a prioridade do trabalho ao qual se referem

2.13.1.6. Identificando o número e a porcentagem de eventos duplicados e repetidos, o que irá ajudar na geração desnecessária

2.13.1.7. Identificando o número e a porcentagem de eventos que indicam problemas de desempenho, como o aumento do número de instâncias quando um aplicativo excede o limite de transações

2.13.2. PID Importante

2.13.2.1. Redução do tempo médio para reparo, o que poderia ser medido por nível de prioridade e não cumulativamente

2.13.2.2. Ajuda na criação do ANO

2.13.3. Como um evento é gerado?

2.13.3.1. Pelas ferramentes de monitoração sempre que um limite é atingido ou uma condição de erro é detectada

2.13.3.2. Software captura e avalia Eventos usando

2.13.3.2.1. Tecnologias baseadas em regras

2.13.3.2.2. Tecnologias baseadas em modelos

2.13.3.2.3. Tecnologias baseadas em políticas

2.14. Desafios, Riscos e Fatores Críticos de Sucesso

2.14.1. Desafios

2.14.1.1. Obter verba para aquisição da ferramenta

2.14.1.2. Definir o nível correto de filtragem

2.14.1.3. Implementar agentes de monitoração em toda a infraestrutura de TI

2.14.1.4. Conseguir pessoas devidamente capacitadas

2.14.2. Fator Crítico de Sucesso

2.14.2.1. O mais crítico é o nível correto de filtragem

2.14.2.2. Para alcançar o nível correto é necessário:

2.14.2.2.1. Integrar o Ger. de Eventos a todos os processos de Ger. de Serviço, para comunicar apenas os eventos importantes

2.14.2.2.2. Na definição de novos Serviços garantir a aderência com os princípios do Ger. de Eventos

2.14.2.2.3. Incluir um processo formal para avaliação da eficácia da filtragem

2.15. Como desenhar para um Ger. de Evento efetivo

2.15.1. Ger. de Evento forma a base da monitoração da performance e disponibilidade do Serviço

2.15.2. Ger. de Eventos efetivo não será desenhado depois de colocar o serviço em produção

2.15.3. Contém a seguintes áreas de desenho

2.15.3.1. Instrumentação

2.15.3.1.1. Processo para definir e desenhar para controlar e monitor a infra de TI e os Serviços

2.15.3.2. Mensagens de Erro

2.15.3.2.1. Envolve a geração de mensagens de erro com informações úteis que indicam a localização específica e a causa provável da falha

2.15.3.3. Identificando Limites

2.15.3.3.1. A etapa final é a definição dos limites (thresholds)

3. Gerenciamento de Incidentes

3.1. Visão Geral

3.1.1. O objetivo do processo é restabelecer a Operação do Serviço aos níveis normais, o mais rápido possível, após um comunicado de Incidente.

3.1.2. Isto minimiza o impacto no Serviço de Negócio

3.1.3. A Operação Normal do Serviço é definida pelos limites dos ANS

3.1.4. Reduzir qualquer efeito adverso nas operações do negócio.

3.2. Meta

3.2.1. Restabelecer a Operação de Serviços aos níveis normais, o mais rápido possível e minimizar qualquer impacto negativo sobre as operações.

3.2.2. Incidente

3.2.2.1. Uma interrupção não planejada de um Serviço de TI, ou redução na qualidade de um Serviço de TI.

3.2.2.2. Falhas nos ICs

3.2.3. Definição

3.2.3.1. O processo para lidar com todos os incidentes; Inclui falhas, dúvidas ou consultas de usuários

3.3. Escopo

3.3.1. Inclui os eventos que interrompem ou podem interromper o Serviço

3.3.2. Ger. de Incidentes inclui:

3.3.2.1. Eventos comunicados pelos usuários

3.3.2.2. Incidentes reportados ou registrados pela equipe técnica

3.3.3. Embora o Ger. de Incidentes inclua qualquer evento que interfira um Serviço, não significa que todos os eventos sejam incidentes

3.3.4. Comparação

3.3.4.1. Incidentes

3.3.4.1.1. São comunicados à Central de Serviço

3.3.4.1.2. Representam uma interrupção em um serviço acordado

3.3.4.1.3. Não são planejados

3.3.4.1.4. São atendidos pelo processo de Ger. de Incidentes

3.3.4.2. Requisições de Serviço

3.3.4.2.1. São comunicados à Central de Serviço

3.3.4.2.2. Não representam uma interrupção a um serviço acordado

3.3.4.2.3. São uma forma de atender as necessidades dos clientes

3.3.4.2.4. São planejados

3.3.4.2.5. São atendidos pelo processo de Cumprimento de Requisições

3.4. Valor para o Negócio

3.4.1. Em virtude da visibilidade, é um dos primeiros processos a serem implantados em projetos de Gestão de Serviços

3.4.2. Valores

3.4.2.1. Habilidade para identificar e resolver incidentes

3.4.2.1.1. Ajuda a reduzir o tempo de interrupção

3.4.2.1.2. Menos interrupção, maior disponibilidade do Serviço para os clientes

3.4.2.1.3. Maior satisfação do cliente e credibilidade na TI

3.4.2.2. Habilidade de alinhar as atividades de TI com as prioridades em tempo real do negócio

3.4.2.3. Habilidade para identificar melhorias em potencial para os Serviços

3.4.2.4. Habilidade para identificar os requisitos de treinamento

3.5. Políticas, Princípios e Conceitos Básicos

3.5.1. Durante a formulação do processo de Ger. de Incidentes considerar:

3.5.1.1. Calendários de Atuação

3.5.1.1.1. Todos os envolvidos devem estar de acordo em relação aos calendários de atuação referentes à resolução de incidentes

3.5.1.1.2. Precisam estar associados com cada estágio do tratamento de Incidentes

3.5.1.1.3. Irão variar de acordo com a Prioridade do Incidente e as metas de reposta e resolução nos ANSs

3.5.1.1.4. Utilizar ferramentas de Ger. de Serviços para automatizar o calendário e o escalonamento do Incidente, quando necessário

3.5.1.2. Modelo de Incidentes

3.5.1.2.1. Passos predefinidos necessário para tratar o processo de uma forma pré-acordada

3.5.1.2.2. Útil para resolver incidentes repetitivos

3.5.1.2.3. Conteúdo dos Modelos

3.5.1.3. Incidentes Graves

3.5.1.3.1. Categoria especial de Incidentes

3.5.1.3.2. Todos as partes interessadas deve ter um acordo na definição de Incidentes Graves

3.5.1.3.3. Deve-se definir um modelo separado para estes tipos de Incidentes

3.5.1.3.4. Pode haver confusão entre Incidente Grave e Problema

3.5.1.3.5. Procedimento

3.6. Atividades, Métodos e Técnicas do Processo

3.6.1. Atividades

3.6.1.1. Identificação

3.6.1.1.1. Utiliza-se ferramentas de monitoração, para identificação de falhas o quanto antes de impactar os usuários

3.6.1.2. Registro

3.6.1.2.1. Deve ser juntamente com a data e o horário

3.6.1.2.2. Todos os incidentes devem ser registrados

3.6.1.2.3. Informações registradas

3.6.1.3. Categorização

3.6.1.3.1. O Incidente é categorizado quando é registrado

3.6.1.3.2. Necessário checar se é uma Requisição de Serviço, pois os usuários podem registrar uma Requisição como um Incidente

3.6.1.3.3. Exemplos:

3.6.1.3.4. Passos para categorizar

3.6.1.4. Priorização

3.6.1.4.1. Deve-se assinalar um código de priorização ao Incidente

3.6.1.4.2. Geralmente pode assinalar esse código julgando-o pela:

3.6.1.4.3. Outros fatores para definição do Impacto

3.6.1.4.4. Alteração da Priorização

3.6.1.5. Diagnóstico Inicial

3.6.1.5.1. Importante registrar todos os sintomas para diagnosticar rapidamente o problema e corrigi-lo

3.6.1.5.2. Deve acontecer enquanto o usuário ainda estiver no telefone

3.6.1.5.3. Scripts de diagnóstico e informações de Erros Conhecidos auxiliam bastante

3.6.1.6. Escalonamento

3.6.1.6.1. Funcional

3.6.1.6.2. Hierárquica

3.6.1.7. Investigação

3.6.1.7.1. Deve manter registrado juntamente com o incidente todo o processo de diagnóstico e investigação do problema

3.6.1.7.2. Inclui

3.6.1.7.3. Realizar a investigação e diagnóstico em paralelo para não perder informação valiosa

3.6.1.8. Resolução

3.6.1.8.1. Quando identificar uma resolução em potencial, deve aplicá-la e testá-la

3.6.1.8.2. As atividades são coordenadas se vários grupos estão envolvidos na solução, e toda a informação será documenta

3.6.1.8.3. O grupo de resolução passa o Incidente de volta para a Central de Serviço para fechamento

3.6.1.8.4. A Central de Serviços checa se o usuário está satisfeito com a solução antes de fechar o Incidente

3.6.1.8.5. O Incidente somente poderá ser fechado com o consentimento dos usuários

3.6.1.8.6. A Central de Serviço deve checar também:

3.6.1.8.7. Haverá casos em que os incidentes voltam a ocorrer, mesmo depois de formalmente encerrados.

3.7. Gatilhos

3.7.1. Usuário ou membro da equipe técnica pode abrir incidentes

3.7.2. Comunicar pela Central de Serviços ou no local adequado na rede

3.7.3. A equipe técnica pode levantar os Incidentes

3.7.4. Ferramentas de Ger. de Evento.

3.7.5. Fornecedores também pode abrir, enviando um alerta ou comunicado sobre uma possível dificuldade que merece atenção

3.8. Entradas

3.8.1. Informações de configuração do BDGC

3.8.2. Níveis acordados de serviço

3.8.3. Resposta de Incidentes similares

3.8.4. Soluções de contorno de outras fontes

3.8.5. Scripts de diagnósticos

3.8.6. Detalhes das resoluções

3.8.7. Resposta da RDM

3.8.8. Programação das Futuras Mudanças (PFM)

3.8.9. Disponibilidade projetada do serviço (DPS)

3.8.10. Planos de implementação de Liberações

3.8.11. Catálogo de serviço

3.8.12. Restrições financeiras e de recursos

3.9. Saídas

3.9.1. Serviço restaurado/Incidentes fechados

3.9.2. RDM para resolução do incidente

3.9.3. Registros completos e atualizados do Incidente

3.9.4. Soluções de contorno propostas

3.9.5. Erros no BDGC reportados

3.9.6. Informações sobre gerenciamento

3.9.7. Comunicação aos Usuários/Clientes

3.10. Interfaces com outros processos

3.10.1. Gestão de Problemas

3.10.2. Gestão de Configuração

3.10.2.1. Identifica dispositivos com falha

3.10.2.2. Impacto do Incidente

3.10.2.3. Usuários afetados pelos Problemas

3.10.2.4. SGC oferece informações utilizadas na identificação e rastreio dos Incidentes

3.10.2.5. Mapeamento da categoria do Incidente e o grupo de suporte que poderá tratar

3.10.3. Gestão de Mudança

3.10.3.1. Na resolução de um incidente, uma mudança pode ser requerida

3.10.3.2. Ger. de Incidente é capaz de detectar e resolver incidentes nos casos em que mudanças não foram com sucesso

3.10.4. Gestão de Capacidade

3.10.4.1. Nos casos de problema de desempenho o Ger. de Capacidade oferece um gatilho para a monitoração do desempenho

3.10.5. Gestão de Disponibilidade

3.10.5.1. Utiliza os dados para definir a disponibilidade dos Serviços de TI

3.10.5.2. Utiliza os mesmos dados para otimizar o ciclo de vida do Incidente

3.10.6. Gestão de Nível de Serviço

3.10.6.1. Como parte do ANS, incidentes deve ser resolvidos dentro de um período específico

3.11. Gerenciamento de Informações para o Ger. de Incidente

3.11.1. No Ger. de Incidentes pode-se obter informações das seguintes fontes:

3.11.1.1. Ferramentas do Ger. de Incidente

3.11.1.1.1. O incidente e o histórico do Problema

3.11.1.1.2. Várias categorias do incidente

3.11.1.1.3. Etapas realizadas para resolver o incidente

3.11.1.1.4. Uma lista guia das medidas que deve ser tomadas para resolver os Incidentes

3.11.1.2. Registros de Incidentes

3.11.1.2.1. Número do Incidente

3.11.1.2.2. Classificação do Incidente

3.11.1.2.3. Data/Horário

3.11.1.2.4. Contato

3.11.1.2.5. Etc....

3.12. Medição do Processo

3.12.1. Principais Indicadores de Desempenho (PID)

3.12.1.1. Total de Incidentes que atuaram como medida de controle

3.12.1.2. Incidentes divididos por cada estágio (registrado, em andamento, fechado)

3.12.1.3. Tamanho da fila de processamento dos Incidentes

3.12.1.4. Número e % de Incidentes graves e % de Incidentes tratados dentro de um prazo determinado

3.12.1.5. Tempo médio para se chegar a resolução do Incidente

3.12.1.6. Integração com o processo GNS

3.12.1.7. Custo médio por Incidente

3.12.1.8. Número de Incidentes reabertos e porcentagem do total

3.12.1.9. Número e % de incidentes atribuídos incorretamente

3.12.1.10. Número e % de incidentes cuja categoria foi definida incorretamente

3.12.1.11. % de Incidentes resolvidos pela Central de Serviços sem precisar escalar

3.12.1.12. Número e % de incidentes processados por agente da CS

3.12.1.13. Número e % de incidentes resolvidos remotamente

3.12.1.14. Número de Incidentes tratados por Modelo de Incidentes

3.12.1.15. Divisão dos Incidentes por período do dia, ajuda a identificar picos e garantir os devidos recursos

3.12.2. Papel do Ger. de Incidente no contexto das atividades do MSC

3.12.2.1. Monitoração e coleta dos dados

3.12.2.2. Medição dos Dados

3.12.2.3. Análise dos Dados

3.12.2.4. Pré-configuração e uso das informações

3.13. Desafios

3.13.1. Detectar incidentes o mais cedo possível.

3.13.2. Fazer o pessoal registrar os Incidentes e usar os recursos de auto-auda via web

3.13.3. Disponibilidade das informações sobre Problemas e Erros Conhecidos

3.13.4. Integração com o SGC para definição dos relacionamentos entre os ICs

3.13.5. Integração com o processo GNS.

3.13.5.1. Auxilia no levantamento do Impacto e da Prioridade dos Incidentes

3.14. Riscos

3.14.1. Indisponibilidade de recursos treinados quando se tem um grande número de incidentes que não poderão ser atendidos dentro dos prazos aceitáveis

3.14.2. Incidentes sendo ignorados e cujo andamento não esta ocorrendo devidamente por causa de ferramentas inadequadas de suporte para apresentar os alertas e comunicar o andamento dos mesmos

3.14.3. Falta de informações adequadas e/ou em tempo hábil por falta de integração ou uso de ferramentas inadequadas

3.14.4. Disparidade entre os objetvios ou ações resultados do não alinhamento entre os ANOs e/os CA

3.15. Fatores Críticos de Sucesso

3.15.1. Uma boa Central de Serviço

3.15.2. Metas claramente definidas

3.15.3. Pessoas treinadas, capacitadas e com foco no cliente

3.15.4. Ferramentas de suporte integradas

3.15.5. Acordos de Nível de Operação e Contratos de Apoio

4. Cumprimento de Requisição

4.1. Visão Geral

4.1.1. Parte integrante da Operação do Serviço

4.1.2. A proporção de Requisições para Incidentes é de 60:40

4.1.3. Gerenciar as Requisições de Serviço é função da Central de Serviços

4.2. Objetivos

4.2.1. Requisição de Serviço

4.2.1.1. É uma requisição feita por um usuário para alguma informação ou conselho, ou uma mudança padrão ou para acesso ao serviço de TI

4.2.2. Canalizar os usuários para a Requisição e receber os Serviços padrão para os quais existe um processo de qualificação e aprovação definido

4.2.3. Oferecer informações aos usuários e clientes sobre a disponibilidade de Serviços e sobre o procedimento para obtê-los

4.2.4. Oferecer os componentes dos Serviços padrão solicitados

4.2.5. Ajudar com informações, ouvir as reclamações e os comentários

4.3. Escopo do Processo

4.3.1. Diferenças entre

4.3.1.1. Incidente

4.3.1.1.1. Não pode ser planejado

4.3.1.1.2. Relaciona-se a questões de baixo risco e baixo custo

4.3.1.2. Requisição de Serviço

4.3.1.2.1. Deve ser planejada

4.3.1.2.2. Está mais relacionada a questões frequentes de baixo risco e baixo custo

4.3.2. Qual a vantagem de ter um processo específico para cuidas das Requisições de Serviço?

4.3.2.1. Permite ao Ger. de Incidente focar apenas em incidentes que indicam falha no serviço, ao invés de se preocupar com questões e requisições em geral

4.3.2.2. Requisições possuem saídas e aprovações que são diferentes para Incidentes e Mudanças

4.3.2.2.1. Quando estes são misturados pode distorcer a imagem da qualidade operacional

4.3.2.2.2. Como resultado, não será possível medir a efetividade dos processos de Incidente e Mudança.

4.4. Valor para o Negócio

4.4.1. Os usuários podem utilizar o processo para acessar Serviços padrão rapidamente

4.4.2. Beneficia a organização como um todo reduzindo a burocracia envolvida na requisição e recebimento do acesso aos Serviços novos ou existentes

4.4.3. Reduz os custos de oferta desses Serviços

4.4.4. O atendimento centralizado reforça o controle sobre esses Serviços, reduz os custos graças à "negociação centralizada com fornecedores e o custo do suporte".

4.5. Políticas, Princípios e Conceito Básico

4.5.1. O Provedor de Serviço define um processo para entregar Requisições de Serviço recorrentes

4.5.2. É implementado um processo padronizado chamado Modelo de Requisição de Serviço

4.5.2.1. Este modelo irá incluir algumas pré-aprovações do Ger. de Mudança

4.5.3. Qual a vantagem de criar um Modelo de Requisição?

4.5.3.1. O Modelo de Requisição é uma forma de predefinir as etapas que a Central de Serviços deve seguir para tratar o processo de forma acordada previamente

4.5.3.2. Utiliza-se então ferramentas para gerenciar o processo

4.5.3.2.1. Isso garante que as Requisições Padrão serão tratadas de uma forma predefinida e dentro de um prazo determinado

4.5.4. Modelo de Requisição de Serviço

4.5.4.1. As etapas necessárias para atender a Requisição

4.5.4.2. As pessoas ou grupos de suporte envolvidos

4.5.4.3. Os prazos estimados

4.5.4.4. Os caminhos de escalada

4.6. Atividades, métodos e Técnicas do processo em relação ao ciclo de vida do Serviço

4.6.1. Ciclo de Vida da Requisição do Serviço

4.6.1.1. Seleção do Menu

4.6.1.1.1. Práticas de Autoajuda

4.6.1.1.2. Ferramentas especializadas na web

4.6.1.1.3. Benefícios

4.6.1.2. Aprovação Financeira

4.6.1.2.1. Algumas requisições tem algum tipo de implicação financeira, independente do tipo de contrato em vigor

4.6.1.2.2. É necessário estimar o custo da Requisição

4.6.1.2.3. Fixar valores para as requisições padrão

4.6.1.3. Preenchimento da Requisição

4.6.1.3.1. Algumas requisições podem ser tratadas pela Central de Serviços, enquanto outras devem ser encaminhadas a grupos especializados

4.6.1.3.2. Grupos especiais cuidam da coleta, solução e entrega da Requisições de Serviço

4.6.1.3.3. O papel da Central de Serviços é monitorar, rastrear o progresso e manter os usuários informados

4.6.1.4. Fechamento

4.6.1.4.1. A Central de Serviço confirma se a Requisição foi atendida, se os usuários ficaram satisfeitos e se concordam em dá-la por encerrada

4.6.1.4.2. A CS pode checar também:

4.6.1.4.3. A CS deve checar se o usuário está satisfeito com o resultado

4.7. Gatilhos

4.7.1. Quando o usuário liga para a Central de Serviços

4.7.2. Preenche as informações da requisição na interface web de autoajuda

4.8. Interfaces com outros Processos

4.8.1. CS/Ger. de Incidentes

4.8.1.1. Muitas Requisições de Serviço são atendidas inicialmente pela Ger. de Incidentes.

4.8.1.2. Algumas organizações implementam um processo distinto para atender as Requisições

4.8.2. Ger. de Liberação, Ativos e Configuração

4.8.2.1. Algumas requisições são para implantar componentes novos ou atualizar os já existentes automaticamente.

4.8.2.2. Nesses casos, a Liberação pode ser predefinida, formatada e testada, mas implementada somente mediante uma Requisição de Liberação

4.8.2.3. Após a implantação o Provedor deverá atualizar o SGC para refletir a mudança.

4.8.2.4. Deve checar também para as licenças de software apropriadas e requisições de incidentes ou problemas relacionadas à Serviços de TI que iniciou a requisição

4.9. Ger. de Informações para Cumprimento de Requisição

4.9.1. Para funcionar corretamente, o Cumprimento de Requisições requer informação

4.9.2. As fontes são:

4.9.2.1. Requisições de Serviços

4.9.2.1.1. Contém informações sobre

4.9.2.2. RDMs

4.9.2.2.1. Iniciam o cumprimento da requisição

4.9.2.3. Portfólio de Serviços

4.9.2.3.1. Identifica o escopo da Requisição de Serviço acordada

4.9.2.4. Políticas de Segurança

4.9.2.4.1. Estabelecem os controles que serão observados e que terão que ser atendidos no fornecimento do Serviço como licença de software ou autorização para o serviço

4.10. Medição do Processo

4.10.1. PID

4.10.1.1. Número total de Requisições de Serviço atuando como medida de controle

4.10.1.2. Requisições de Serviço em cada estágio (Requisições registradas, em andamento, encerradas)

4.10.1.3. Um relatório das Requisições de Serviço atuais e pendentes

4.10.1.4. Número e porcentagem das Requisições encerradas dentro do prazo especificado

4.10.1.5. Tempo médio para atender cada tipo de Requisição de Serviço

4.10.1.6. Nível de satisfação do cliente com a Requisição de Serviço, avaliando em pesquisa de satisfação do cliente

4.10.2. Cumprimento da Requisição e o MSC

4.10.2.1. Ferramentas especializadas ajudam a definir serviços na estrutura de catálogo em conjunto com os clientes do negócio e criam o Portal de Serviço baseado em Web para os usuários solicitarem os serviços

4.10.2.2. Depois que isso é feito a requisição de serviço é gerenciada através de um mecanismo de fluxo de trabalho

4.10.2.3. Cada requisição é designada aos recursos de acordo com o processo definido de atividades e tarefas

4.10.2.4. Estas ferramentas também registram os custos relacionados que os sistemas financeiros utilizam

4.10.2.5. O grande benefício é:

4.10.2.5.1. Os dados coletados e reportados relacionam-se à qualidade dos serviços entregues

4.10.2.5.2. Qualquer problema encontrado

4.10.2.5.3. Habilidade de rastrear os níveis de serviço acordados

4.11. Desafios

4.11.1. Definir e documentar os tipos de Requisição que o Cumprimento de Requisição poderá atender

4.11.2. Desenvolver sistemas de interface com o usuário eficazes e de autoajuda que permitem que os usuários façam parte do processo de Cumprimento de Requisição

4.12. Fatores Críticos de Sucesso

4.12.1. Chegar a um acordo sobre os Serviços que devem ser padronizados

4.12.2. Publicar os Serviços no Catálogo de Serviço

4.12.3. Definir um procedimento de atendimento padrão para cada Requisição de Serviço

4.12.4. Estabelecer um ponto comun de contato para solicitação de serviço

4.12.5. Oferecer ferramentas de autoatendimento para os clientes

4.13. Riscos

4.13.1. Se o escopo não for bem definido o processo pode ser mal entendido

4.13.2. Se a interface do usuário não for bem desenvolvida e implementada é bem provável que os usuários encontrem dificuldade em fazer as Requisições e tentem encontrar outros métodos

4.13.3. Recursos inadequados de monitoramento podem dificultar a coleta de métricas precisas

5. Gerenciamento de Problema

5.1. Visão Geral

5.1.1. Gerencia o Ciclo de Vida de todos os problemas

5.1.2. Ger. de Problema resolve problemas de forma permanente e evita incidentes

5.2. Objetivo

5.2.1. O que é Problema?

5.2.1.1. A causa desconhecida de um ou mais incidentes

5.2.2. A causa de um ou mais Incidentes não é geralmente conhecida no momento em que o registro de Problema é criado.

5.2.3. E o processo de Ger. de Problema é responsável para investigação e resolução futura

5.2.4. Prevenir problemas e os Incidentes resultantes dele

5.2.5. Eliminar a causa raiz dos Incidentes

5.2.6. Reduzir o Impacto dos incidentes

5.2.7. Melhorar a produtividade na utilização dos recursos

5.3. Escopo do Processo

5.3.1. Ger. de Problemas inclui todas as atividades que a organização deve executar para diagnosticar a causa raiz dos Incidentes e decidir como resolver os problemas

5.3.2. Inclui:

5.3.2.1. Controle dos Problemas

5.3.2.1.1. Diagnosticar a causa raiz dos Incidentes que estão gerando o Problema

5.3.2.2. Controle de Erros

5.3.2.2.1. Determinar a solução do Problema

5.3.2.2.2. Implementar a solução desejada para resolver o Problema

5.3.2.3. Gestão Proativa de Problemas

5.3.2.3.1. Mantém informações sobre Problemas, suas soluções de contorno e resoluções.

5.3.2.3.2. O papel de manutenção destas informações faz com que o papel da gestão de problemas na organização seja mandatório, para que se tenha uma forte ligação com o processo de Ger. do Conhecimento ou ferramentas como o Banco de Dados de Erros Conhecidos

5.3.2.3.3. Estas ferramentas serão utilizadas em ambos Gestão de Problemas e Gestão do Conhecimento

5.3.2.4. Gestão Reativa de Problemas

5.3.3. Ligação entre Ger. de Problema e Ger. de Incidentes

5.3.3.1. Ambos os processos utilizam as mesmas ferramentas e tem similar a categorização, Impacto e prioridade.

5.3.3.2. Esta relação é importante para garantir uma comunicação efetiva enquanto lida com Incidentes relacionados e Problemas

5.4. Valor para o Negócio

5.4.1. Quando trabalha em conjunto com a Gestão de Incidentes e Mudança na melhoria da qualidade e disponibilidade dos Serviços

5.4.2. Quando um Incidente é resolvido, o Provedor do Serviço deverá registrar toda a informação sobre a resolução, onde esta poderá ser reutilizada no futuro

5.4.3. Valores

5.4.3.1. Correlação rápida da experiência do cliente e as medidas operacionais para rápida restauração do Serviço

5.4.3.2. Aumento da estabilidade do Serviço pela localização e eliminação dos erros de infraestrutura

5.4.3.3. Aumento da disponibilidade e qualidade do Serviço

5.4.3.4. Melhora da imagem organizacional

5.4.3.5. Melhora do aprendizado organizacional

5.4.3.6. Melhor taxa de resolução na primeira tentativa da Central de Serviços

5.4.4. O valor que o processo permite aos clientes são:

5.4.4.1. Melhoria da qualidade dos serviço de TI

5.4.4.2. Redução do volume de incidentes

5.4.4.3. Menos problemas de usuários com as aplicações de negócio

5.4.4.4. Elevados níveis de disponibilidade dos Serviços de TI

5.4.4.5. Maior visibilidade através dos relatórios do negócio e sua utilização da TI

5.4.4.6. Evita a repetição de incidentes

5.4.4.7. Maior disponibilidade e menos interrupção aos usuários pela eliminação de incidentes repetidos

5.4.5. Necessidade do Ger. de Problema

5.4.5.1. Mudança no processo de Gestão do Serviço de reativo para proativo

5.4.5.2. Mudança no processo de Gestão do Serviço de apagar incêndios para evitar incêndios

5.4.5.3. Melhora a qualidade da estrutura

5.4.5.4. Aumenta a satisfação do cliente

5.5. Políticas, princípios e o Conceito de Modelo de Problema

5.5.1. Problema Único

5.5.1.1. Organizações poderão ter Problemas únicos como repetidos.

5.5.1.2. Problemas únicos devem ser tratados individualmente quando ocorrem

5.5.1.3. Problemas repetidos poderão ser tratados utilizando o modelo de Problema

5.5.1.4. Modelo de Problema irá:

5.5.1.4.1. Tratar os problemas repetidos de uma forma predefinida

5.5.1.4.2. Tratar os problemas recorrentes dentro de um prazo determinado

5.5.1.4.3. Ajuda a manter o repositório de Problemas no registro de Erros Conhecidos na BDEC.

5.5.1.4.4. Erro Conhecido

5.6. Atividades do Processo

5.6.1. Principais Conceitos

5.6.1.1. Ger. de Problemas visa reduzir o número e a gravidade dos Incidentes e Problemas nas organizações

5.6.1.2. Ger. de Problemas é responsável por garantir que as informações estejam acessíveis a todos os grupos envolvidos

5.6.1.3. As informações sobre o Ger. de Problema podem ser indexadas e são relevantes

5.6.2. Identificação de Problemas e Erros Conhecidos

5.6.2.1. Analisando Incidentes

5.6.2.2. Analisando a infraestrutura

5.6.2.3. Consultando a base de dados de conhecimento

5.6.2.4. Coma a ajuda dos desenvolvedores e fornecedores

5.6.3. Dois processos importantes no Ger. de Problema são

5.6.3.1. Ger. Reativo de Problemas

5.6.3.1.1. Identifica a causa raiz do Incidente e sugere soluções permanentes para prevenir a recorrência do Incidente

5.6.3.1.2. Executado como parte da Operação do Serviço

5.6.3.2. Ger. Proativo de Problemas

5.6.3.2.1. Identifica e resolve Problemas e Erros Conhecidos antes que os Incidentes ocorram

5.6.3.2.2. Iniciado na Operação do Serviço e executado como parte do MSC

5.6.4. Consiste das Atividades

5.6.4.1. Detecção do Problema

5.6.4.1.1. Causa desconhecida de um ou mais incidentes podem resultar no registro de problema

5.6.4.1.2. Revisão das falhas na Infraestrutura ou aplicações detectadas por ferramentas de automação

5.6.4.1.3. Revisão das notificações dos Fornecedores

5.6.4.1.4. Analisar todos os Incidentes como parte proativa do Ger. de Problema.

5.6.4.2. Registro

5.6.4.2.1. Todos os problemas devem ser registrados juntamente com a data e o horário para que se possa ter o controle e escalá-lo quando necessário

5.6.4.2.2. Boa prática manter a referência do Incidente que iniciou o Registro do Problema

5.6.4.3. Categorização

5.6.4.3.1. Depois da detecção e Registro do Problema

5.6.4.3.2. Ajuda a:

5.6.4.4. Priorização

5.6.4.4.1. Similar aos incidentes, o Problema deve ser priorizado

5.6.4.4.2. Importante para identificar a Urgência e o Impacto para então definir a Prioridade correta.

5.6.4.5. Investigação

5.6.4.5.1. Tem um papel importante no diagnóstico da causa raiz do problema

5.6.4.5.2. A velocidade e a natureza da investigação depende da natureza do Problema, seu Impacto, severidade e urgência

5.6.4.5.3. Boa prática utilizar o SGC para determinar o impacto e diagnosticar a razão exata ou o ponto de falha no Serviço

5.6.4.5.4. Deve-se checar a BDEC antes de conduzir a investigação

5.6.4.5.5. Outra técnica útil é tentar recriar o problema

5.6.4.5.6. Técnicas de Resolução de Problemas

5.6.4.6. Soluções de Contorno

5.6.4.6.1. Boa prática é sempre encontrar a solução definitiva do Problema

5.6.4.7. Registro de Erro Conhecido de um Problema

5.6.4.7.1. Boa prática é manter um registro aberto para os problemas para os quais forma encontradas soluções de contorno

5.6.4.7.2. Além de registrar os problemas para os quais há soluções de contorno, é necessário registrá-las no banco de dados de erros conhecidos.

5.6.4.7.3. A razão para gravar no BDEC é para referência futura

5.6.4.7.4. O Erro Conhecido deve ser:

5.6.4.8. Resolução do Problema

5.6.4.8.1. Depois de encontrar uma solução de contorno e registrar um Erro Conhecido, o próximo passo é resolver e fechar o problema

5.6.4.8.2. Deve-se considerar

5.6.4.8.3. Em alguns casos a resolução de alguns problemas não podem ser justificados.

5.6.4.9. Encerramento

5.6.4.9.1. Depois que a mudança é implementada e a resolução aplicada

5.6.4.9.2. Momento também de fechar qualquer incidente relacionado que ainda estão em aberto

5.6.4.9.3. A última atividade é checar e atualizar o registro de Erro Conhecido

5.6.4.9.4. Dicas sobre o controle do Problema

5.6.4.9.5. Atividades no Controle de Problemas

5.6.4.10. Revisão de Problemas Sérios

5.6.4.10.1. O processo não finaliza após a resolução e o fechamento do problema

5.6.4.10.2. O processo inclui a revisão dos problemas graves para que a organização aprenda com os erros do passado

5.6.4.10.3. Este processo é parte do Gerenciamento Proativo de Problemas

5.6.4.10.4. Esta revisão deve examinar

5.6.5. Erros detectados no ambiente de desenvolvimento

5.6.5.1. Caso tome a decisão de liberar aplicações com erros detectados no ambiente de desenvolvimento, estas falhas precisam ser registradas nas soluções de contorno ou resoluções no BDEC

5.6.5.2. Também é importante adicionar uma etapa formal com a assinatura atestando o conhecimento destes erros

5.6.5.3. Atividades Principais no Controle de Erros

5.6.5.3.1. Identificação e Registro

5.6.5.3.2. Avaliação

5.6.5.3.3. Registro de Resolução

5.6.5.3.4. Monitoração

5.6.5.3.5. Encerramento

5.6.5.4. Dicas sobre o Controle de Erros

5.6.5.4.1. Entender que nem todos os erros conhecidos precisam ser resolvidos

5.6.5.4.2. O controle de erros é fundamental para elaboração das RDMs

5.6.5.4.3. Cirar registros de erro padrão par Incidentes de rotina

5.6.5.4.4. As falhas de hardware são corrigidas normalmente pelo Ger. de Incidentes

5.6.5.4.5. Ferramenta integrada para Incidente, Problema e Controle de Erros

5.6.5.4.6. Necessário lidar com Problemas, Erros Conhecidos e Mudanças desde o ambiente de desenvolvimento até o de produção

5.6.5.5. Atividades para controlar o Erro

5.6.5.5.1. Criar um registro de erro conhecido

5.6.5.5.2. Avaliar a viabilidade de mudança ou levantar os erros

5.6.5.5.3. Abrir uma RDM

5.6.5.5.4. Implementar a Mudança

5.6.5.5.5. Revisar a mudança de acordo com os parâmetros de sucesso definidos pelo Ger. de Problema

5.6.5.5.6. Avaliar o sucesso da Mudança

5.6.5.5.7. Atualizar e fechar os registros

5.7. Gatilhos

5.7.1. Reação a um ou mais Incidentes abertos pela Central de Serviços

5.7.2. Decisão tomada durante o teste de aceitação do usuário em ir em frente apesar das falhas no Serviço (Problema e Erro Conhecido)

5.7.3. Notificação por parte dos fornecedores

5.8. Entradas

5.8.1. Informações do BDGC

5.8.2. Evidências de preocupações, questões e Problemas existentes

5.8.3. Detecção de possíveis problemas por ferramentas de monitoração

5.8.4. Incidentes recorrentes

5.8.5. Soluções de contorno e outras fontes

5.8.6. Resultados de revisões de mudança pós-implementação

5.8.7. Reconhecimento de tendências por parte da equipe de TI, clientes e usuários

5.8.8. Requisitos de disponibilidade do serviço

5.8.9. Erros Conhecidos

5.8.10. Jornais técnicos e outras informações técnicas

5.9. Saídas

5.9.1. Causas da indisponibilidade

5.9.2. Erros conhecidos e Soluções de Contorno aprovadas

5.9.3. RDMs

5.9.4. Base de Conhecimento relacionando Incidentes, Problemas, Erros Conhecidos e Mudanças

5.9.5. Ocorrências de problemas atualizadas e já encerradas

5.9.6. Informações sobre gerenciamento

5.9.7. Redução no número de Incidentes

5.10. Interfaces do Processo

5.10.1. Transição do Serviço

5.10.1.1. Ger. de Mudança

5.10.1.1.1. Submete RDM para resolução e solução de contorno do Problema que requer mudança no IC.

5.10.1.2. Ger. de Configuração

5.10.1.2.1. Detectar ICs com falha

5.10.1.2.2. Determinar o impacto dos problemas e as resoluções

5.10.1.2.3. Formar a base da BDEC

5.10.1.2.4. Integrar com os registros de Problemas

5.10.1.3. Ger. de Liberação e Implantação

5.10.1.3.1. Garante que os erros sejam transferidos do ambiente de desenvolvimento para a BDEC

5.10.1.3.2. Ger. de Problema resolve problemas que são causados por falhas identificadas durante uma Liberação

5.10.2. Desenho do Serviço

5.10.2.1. Ger. de Disponibilidade

5.10.2.1.1. O Ger. de Problema comunica as informações de gerenciamento que ajudam a determinar a forma de aumentar o tempo de operação e reduzir paralisações

5.10.2.1.2. Atua relacionado às áreas de ger. de problema proativas

5.10.2.2. Ger. de Capacidade

5.10.2.2.1. O Ger. de Problema conta com a ajuda deste processo para investigar problemas específicos. Ex. Problemas de performance

5.10.2.3. Ger. da Continuidade do Serviço de TI

5.10.2.3.1. Atua como ponto de entrada no GCSTI

5.10.3. MCS

5.10.3.1. O Ger. de Problemas resolve incidentes e problemas que estão afetandos os ANS

5.10.3.2. O Ger. de Nível de Serviço oferece parâmetros que o Ger. de Problema precisa para trabalhar

5.10.4. Estratégia do Serviço

5.10.4.1. Relação com o Ger. Financeiro é bilateral

5.10.4.2. Ger. Financeiro

5.10.4.2.1. Oferece a análise de valor do impacto e ajuda a avaliar o impacto das resoluções propostas pelo ger. de Problema

5.10.4.2.2. Ger. de Problema oferece informações de gerenciamento relacionadas aos sistemas de orçamento e contabilidade e que ajudam a calcular o custo para resolver e evitar um Problema

5.11. Informações para o Ger. de Problema

5.11.1. Cada organização deve ter as seguintes fontes de informação

5.11.1.1. SGC

5.11.1.2. BDEC

5.11.2. SGC

5.11.2.1. Detalhes dos componentes da infraestrutura de TI e seus relacionamentos

5.11.2.2. Fonte de diagnóstico dos Problemas

5.11.2.3. Detalhes de atvidades anteriorres

5.11.2.4. Age como fonte para diagnosticar problemas

5.11.2.5. Avaliar o impacto dos problemas na Gestão da Informação

5.11.3. BDEC

5.11.3.1. Conhecimento prévio dos Problemas e Incidentes

5.11.3.2. Detalhes das falhas e os sintomas que apareceram

5.11.3.3. Propósito é armazenar informações sobre Problemas e Incidentes

5.11.3.4. Contém os detalhes das soluções de contorno ou as resoluções para restaurar os Serviços e resolver Problemas

5.11.3.5. O único que deve incluir novos registros é o Gerenge de Problemas para garantir que sejam únicos

5.11.4. Ambos os SGC e o BDEC são parte do Sistema de Gerenciamento do Conhecimento do Serviço

5.12. Medição do Processo

5.12.1. PID

5.12.1.1. Número de Problemas que são registrados num período em particuluar; Estes atuam como medidas de controle

5.12.1.2. O percentual de problemas que foram resolvidos e que são por objetivos do ANS

5.12.1.3. Número e percentual de Problemas tratados num período predeterminado

5.12.1.4. A contenção de Problemas pendentes

5.12.1.5. Número e percentual de problemas graves

5.12.1.6. Número de erros conhecidos inseridos no BDEC

5.12.2. Boa prática para a organização dividir todas as métricas por categoria, impacto, severidade, urgência, e prioridade

5.12.3. Pode a partir disso comparar as métricas atuais com as passadas

5.13. Ger. de Problema e MCS

5.13.1. MSC deve estar integrado com cada fase do ciclo de vida do Serviço

5.13.2. Atividade MCS

5.13.2.1. Analisar dados

5.13.2.1.1. Ger. de Problema

5.13.2.2. Apresentar e Usar a Informação

5.13.2.2.1. Ger. de Problema

5.14. Desafios

5.14.1. Estabelecer uma relação efetiva com as ferramentas de ger. de Incidentes e processos

5.14.2. Estabelecer interfaces formais e práticas comuns de trabalho para os processos de Ger. de Problema e Incidentes

5.14.3. Relacionar os registros dos dois processos

5.14.4. Estabelecer um bom relacionamento entre os suportes de primeiro e segundo nível

5.14.5. Explicar aos analistas o impacto no negócio do Problema

5.15. FCS

5.15.1. A habilidade do Ger. de Problema em utilizar todos os recursos da Gestão do conhecimento e configuração

5.15.2. Analistas treinados, com conhecimento e orientados ao cliente

5.16. Ger. de Problema e Ger. do Nível de Serviço

5.16.1. O objetivo do Ger. do Nível de Serviço é manter e melhorar a qualidade do Serviço de TI em um ciclo contínuo de monitoraçã, relatórios e discussões sobre os serviços de TI, promovendo ações para erradicar serviços de má qualidade, tudo sempre alinhado ao negócio e justificando os custos

5.17. Plano de Melhoria de Serviço

5.17.1. O processo de Ger. de Nível de Serviço dispara os PMS

5.17.2. Em casos ondem foi indentificada uma dificuldade subjacente que está interferindo negativamente na qualidade do serviço

6. Gerenciamento de Acesso

6.1. Visão Geral

6.1.1. Processo que garante os direitos aos usuários autorizados a utilizarem o Serviço e previnir acessso pelo bloqueio de usuário

6.1.2. Outros nomes do processo:

6.1.2.1. Ger. de Direto

6.1.2.2. Ger. de Identidade

6.1.3. Objetivo principal

6.1.3.1. Executar as políticas e ações definidas na Ger de Segurança e Disponibilidade

6.2. Objetivo

6.2.1. Conceder, aos usuários autorizados o direito de usar um Serviço e impedir o acesso de usuários não autorizados, certificando-se que as políticas e ações definidas nos processos de Ger. de Segurança e da Disponibilidade serão devidamente obedecidas

6.3. Escopo

6.3.1. Executa o Ger. de Disponibilidade e Ger. de Segurança da Informação

6.3.2. Permite que a organização gerencie a confidencialidade, disponibilidade e integridade dos dados e da propriedade intelectual

6.3.3. Garante ao usuário que estes terão acesso ao Serviço requerido, porém sem a garantia de estar disponível todo o tempo, pois esta é uma responsabilidade do Ger. de Disponibilidade

6.3.4. Pode ser iniciado por uma requisição de serviço pela Central de Serviços

6.4. Valor para o Negócio

6.4.1. Oferece aos funcionários o nível de acesso devido

6.4.2. Mantém a confidencialidade graças ao acesso controlado aos Serviços

6.4.3. Evita possíveis erros de usuários durante a entrada de dados para utilização de um Serviço crítico

6.4.4. Garante um ponot único de coordenação onde o uso dos Serviços é auditado

6.4.5. Permite revogar os direitos de acesso de um usuário, caso necessário]

6.4.6. Ajuda na conformidade com regulamentações como SOX, HIPAA e COBIT

6.5. Políticas, Princípios e Conceitos Básicos

6.5.1. Conceitos

6.5.1.1. Acesso

6.5.1.1.1. Refere-se ao nível e extensão da permissão do usuário para usar dados ou as funcionalidades de um Serviço

6.5.1.2. Identidade

6.5.1.2.1. Informações exclusivas sobre cada usuário que o distingue dos demais usuários e atesta o status do usuário dentro da empresa.

6.5.1.3. Direitos

6.5.1.3.1. Refere-se aos privilégios

6.5.1.3.2. Autorizações de um usuário quando recebe acesso a um Serviço

6.5.1.3.3. Pode ser leitura, gravação, execução, alteração e exclusão

6.5.1.3.4. Serviço

6.5.1.3.5. Serviço de Diretório

6.5.2. Atividades

6.5.2.1. Requisição de Acesso

6.5.2.1.1. Acesso ou restrição podem ser solicitados pela área de Recursos Humanos gerando uma requisição Padrão

6.5.2.1.2. Requisitar ou Restringir o acesso com a ajuda de:

6.5.2.2. Verificação

6.5.2.2.1. Ger. de Acesso precisa verificar cada Requisição de acesso a um Serviço de TI

6.5.2.2.2. Necessário conferir se um usuário que está solicitando acesso é um usuário autorizado

6.5.2.2.3. Antes de aceitar o acesso a um Serviço de TI, é verificado

6.5.2.3. Concessão de direitos

6.5.2.3.1. Ger. de Acesso não toma decisões, apenas cumpre as políticas e normas definidas durante a

6.5.2.3.2. Apenas concede ou restringe o acesso

6.5.2.3.3. Conflito de Papéis

6.5.2.4. Monitoração do Status da Identidade

6.5.2.4.1. Mudanças do tipo papel do usuário, necessidade para acessar um novo seviço requerem monitoramento e documentação

6.5.2.4.2. Mudanças nas necessidades de acesso

6.5.2.4.3. Além de monitorar o status da identidade, deve também

6.5.2.5. Registro e Controle de Acesso

6.5.2.5.1. Garante que os direitos concedidos estão sendo devidamente utilizados

6.5.2.5.2. Necessário ter controle sobre os usuários que acessam os serviços disponíveis

6.5.2.5.3. Papelo do Ger. de Acesso

6.5.2.6. Remoção e restrição de direitos

6.5.2.6.1. Ger. de Acesso concede e revoga direitos em algumas situações, como saída da empresa

6.5.2.6.2. Acesso também pode ser revogado quando o usuário muda de papel ou quando não precisa mais daquele mesmo nível de acesso

6.5.2.6.3. Acesso Restrito

6.5.2.7. Requisição de Acesso

6.5.2.7.1. Realizar através

6.6. Interface

6.6.1. Ger. de Recursos Humanos

6.6.1.1. Conferir identidade dos usuários

6.6.1.2. Garantir devida aprovação do serviço solicitado

6.6.2. Ger. de Segurança da Informação

6.6.2.1. Ferramentas e políticas de segurança e proteção dos dados

6.6.3. Ger. de Mudança

6.6.3.1. Controla as solicitações de acesso feitas pelo Ger. de Acesso

6.6.4. Ger. da Configuração

6.6.4.1. Usar os sitemas de informação como o SGC, para armazenar os dados e controlar detalhes sobre os usuários

6.7. Ger. da Informação

6.7.1. Necessário registrar

6.7.1.1. A identidade de cada usuário

6.7.1.2. Os perfis dos usuários, grupos de usuários, funções e grupos de serviço

6.7.2. Direitos de Acesso a Funcionários temporários

6.7.2.1. É simples prover, porém complexo remover

6.7.2.2. O departamento de TI e RH devem trabalhar juntos para formular procedimentos bem definidos para checagem do acesso e remoção quando não mais necessário

6.7.3. Usuários, Grupos de Usuários, Papéis e Grupos de Serviços

6.7.3.1. Boa prática agrupar usuários e serviços de TI, pois estes tipos de grupos podem ser gerenciados mais facilmente

6.7.3.2. Para fornecer direitos de acesso mais facilmente, o Ger. de Acesso utiliza o catálogo com todos os papéis e Serviços que suportam cada área da organização

6.8. Medição do Processo

6.8.1. PID

6.8.1.1. Número de requisições de acesso a um Serviço, como Requisições de Serviço e RDMs

6.8.1.2. Número de Incidentes que precisam que os direitos de acesso sejam reconfigurados

6.8.1.3. Número de Incidentes causados por configurações incorretas

6.8.1.4. Instâncias quando o acesso é condedido para um Serviço, usuário ou departamento

6.8.1.5. Instâncias quando o acesso é condedido para um departamento ou pessoa

6.9. Fatores Críticos de Sucesso

6.9.1. Ter a capacidade de verificar a identidade de um usuário

6.9.2. Ter a capacidade de verificar a identidade de uma pessoa ou órgão aprovador

6.9.3. Ter a capacidade de verificar se um usuário tem o direito de acessar determinado Serviço

6.9.4. Ter a capacidade de atribuir vários direitos de acesso a um único usuário

6.9.5. Ter a capacidade de determinar o status do usuário a qualquer momento

6.9.6. Ter a capacidade de administrar mudanças nos requisitos de acesso de cada usuário

6.9.7. Ter a capacidade de restringir os direitos de acesso para os usuários não autorizados

6.9.8. Contar com uma base de dados de todos os usuários com informçaões sobre os direitos atribuídos a cada um deles

7. Central de Serviço

7.1. Visão Geral

7.1.1. Composta de um time de pessoas responsáveis por lidar com diferentes eventos de Serviço, que são geralmente via telefone ou web ou então por ferramentas

7.2. Papel

7.2.1. Deve ser o ponto único de contato para os usuários de TI no dia-a-dia

7.2.2. Deve tratar todos os Incidentes e Requisições de Serviços

7.2.3. Benefícios

7.2.3.1. Melhor serviço ao cliente, compreensão e satisfação

7.2.3.2. Melhor acessibilidade graças a um ponto comum de contato, comunicação e informação

7.2.3.3. Maior qualidade e agilidade às solicitações dos usuários

7.2.3.4. Melhor trabalho em equipe e comunicação

7.2.3.5. Maior foco e enfoque proativo à oferta de Serviços

7.2.3.6. Menor impacto sobre a empresa

7.2.3.7. Melhor gerenciamento da infraestrutura

7.2.3.8. Melhor utilização dos recursos de suporte e TI e maior produtividade do pessoal corporativo

7.2.3.9. Suporte à tomada de decisão graçcas à informações relevantes

7.3. Objetivo

7.3.1. Restabelecer os serviços, fazer com que tudo volte ao normal para o usuário, e no menor tempo possível

7.3.2. Responsabilidades específicas

7.3.2.1. Registrar todos os detalhes relevantes sobre os Incidentes e Requisições de Serviços

7.3.2.2. Fazer uma investigação de primeira linha e diagnóstico

7.3.2.3. Resolver todos os Incidentes e Requisições de Serviços que não puderem ser resolvidos

7.3.2.4. Informar aos usuários sobre o andamentos do processo

7.3.2.5. Fechar todas as Requisições, Incidentes e outras chamadas que foram solucionadas

7.3.2.6. Fazer chamadas de retorno e pesquisas de satisfação do usuário, como prometido

7.3.2.7. Atualizar o Sistema de Gerenciamento da Configuração - SGC

7.4. Tipos de Centrais de Serviços

7.4.1. Central de Serviço Local

7.4.1.1. É localizada fisicamente próxima da comunidade de usuários

7.4.1.2. Ajuda na comunicação, marca a presença e é a que os usuários mais gostam

7.4.1.3. Organizações mantém este tipo mesmo quando o volume de chamadas não justifica por causa

7.4.1.3.1. Das diferenças de idioma, políticas e culturais

7.4.1.3.2. Da diferença de fuso horário

7.4.1.3.3. Dos grupos epecializados de usuários

7.4.1.3.4. Da existência de Serviços customizados ou especializados que exigem conhecimento específico

7.4.1.3.5. Do caráter de emergência dos usuários e dos VIPs

7.4.2. Central de Serviço Centralizada

7.4.2.1. Localizada em um único local

7.4.2.2. Reduz o número de Centrais de Serviço

7.4.2.3. Reduz o número de pessoas necessárias, pois toda a equipe está concentrada em um único local

7.4.2.4. Faz com que os membros da equipe tenham um nível de habilidade mais elevado porque precisam atender um volume alto de chamados

7.4.3. Central de Serviço Virtual

7.4.3.1. Utilização da Internet e ferramentas corporativas de suporte

7.4.3.2. Têm-se a impressão de uma Central de Serviços Centralizada

7.4.4. Central de Serviço "Seguir o Sol"

7.4.4.1. Fornece suporte 24 horas aos clientes

7.4.4.2. Pela combinação de múltiplas Centrais de Serviços dispersas geograficamente

7.4.4.3. Necessário posuuir segurança nos processos comuns, nas ferramentas e nas informações compartilhadas da base de dados

7.4.4.4. Deve-se ter também processos de escalação e passagem muito bem controlados

7.4.5. Grupos Especializados da Central de Serviço

7.4.5.1. Utilizam grupos especializados dentro da estrutura da Central de Serviço

7.4.5.2. Estes grupos atendem casos relacionados a um determinado Serviço de TI

7.4.5.3. Todas as chamadas relacionadas a este serviço são direcionadas sempre a eles

7.4.5.4. Resolvem Incidentes mais rapidamente

7.4.5.5. Disponibilizar somente para os Serviços vitais

7.5. Ambiente da Central de Serviço

7.5.1. Local tranquilo e com material a prova de som

7.5.2. Mobiliário confortável

7.5.3. Sala de descanso separada para intervalos da equipe

7.6. Ponto Único de Contato

7.6.1. Fornecer um contato único para a Central de Serviço

7.6.2. Este número deve ser público e de conhecimento de todos

7.6.3. Endereço de e-mail e Página Web de contato deve ser compartilhado

7.7. Níveis de Pessoal

7.7.1. Fatores

7.7.1.1. Níveis de pessoal

7.7.1.1.1. Expectativas dos clientes com relação ao Serviço

7.7.1.1.2. Os requisitos de negócio, entre eles o orçamento disponível e os tempos de resposta

7.7.1.1.3. A idade, desenho, tamanho e complexidade da infra de TI e o Catálogo de Serviço,

7.7.1.1.4. Número de clientes e usuários que precisam ser atendidos e fatores como idiomas diferentes e nível de habilidade dos clientes

7.7.1.1.5. Tipos de Incidentes e Requisições de Serviços e tipos de RDMs

7.7.1.1.6. Ferramentas para determinar os requisitos de pessoal

7.7.1.2. Níveis de habilidades

7.7.1.2.1. Antes de contratar qualquer analista, é necessário decidir qual o nível de conhecimento que os analistas precisam ter

7.7.1.2.2. Necessário considerar

7.7.1.2.3. Estrutura em duas camadas

7.7.1.2.4. Pessoal para Serviços Customizados/Especializados

7.7.1.2.5. Central de Serviço e a MSC

7.7.1.3. Treinamento

7.7.1.3.1. Garantir que toda a equipe da Central de Serviço esteja devidamente treinada antes de entrar realmente na operação da Central de Serviço

7.7.1.3.2. Garantir que toda a equipe passe por um programa de capacitação formal

7.7.1.3.3. Garantir que o conteúdo do progrma de capacitação seja planejado de acordo com o nível de experiência e capacitação dos novos contratados

7.7.1.3.4. Garantir que os novos passem por um programa de treinamento sobre a empresa onde deverão fazer uma passagem curta por áreas críticas da empresa

7.7.1.3.5. Garantir a transferência de conhecimento dos mais experientes para os novatos

7.7.1.3.6. Uso de Mentores no Treinamento

7.7.1.4. Retenção da Equipe

7.7.1.4.1. Oferecendo pacotes de recompensa como reconhecimento pelo trabalho feito

7.7.1.4.2. Exercícios frequentes de trabalho em equipe

7.7.1.4.3. Rotação da equipe

7.7.1.5. Super Usuários

7.7.1.5.1. Meio de comunicação entre os usuários e a Central de Serviços

7.7.1.5.2. Podem filtrar as requisições e incidentes identificados pelos usuários, evitando inundar a Central de Serviços

7.7.1.5.3. É o ponto de disseminação da informação para os usuários

7.7.1.5.4. Podem fornecer suporte em incidentes menores e requisições de serviço

7.7.1.5.5. O papel do super usuário deve ser informado a todos os usuários

7.7.1.5.6. Eles não são os substitutos da Central de Serviço

7.8. Métricas

7.8.1. Um aumento no número de chamadas para a Central de Serviços indica que os Serviços estão menos confiáveis naquele período

7.8.2. Entretanto isto também indica o aumento da confiança dos usuários com a Central de Serviço

7.8.3. A métricas incluem:

7.8.3.1. Percentual de chamadas resolvida na primeira ligação, sem necessidade de escalada

7.8.3.2. Tempo médio para resolução de um Incidente pelo nível 1

7.8.3.3. Tempo médio de escalada de um incidente quando não consegue resolvê-lo no primeiro nível

7.8.3.4. Custo médio da Central de Serviço por incidente

7.8.3.5. Outras medidas

7.8.3.5.1. Os clientes e usuários estão satisfeitos com o atendmiento recebido?

7.8.3.5.2. O operador da Central de Serviço foi educado e profissional?

7.8.3.5.3. A Central de Serviço transmitiu confiança para o usuário?

7.8.3.5.4. Estas medidas são melhores levantadas através de questionários

7.8.3.5.5. Tipos de Pesquisa

7.9. Terceirização da Central de Serviço

7.9.1. É uma decisão estratégica para os gerentes sêniors

7.9.2. As publicações sobre Estratégia de Serviço e Desenho de Serviço falam sobre este assunto

7.9.3. Mecanismos de Proteção

7.9.3.1. Ferramentas e processos

7.9.3.1.1. Cabe à organização garantir que as ferramentas usadas pelos terceiros sejam consistentes com as utilizadas pela organização

7.9.3.1.2. A Central de Serviços não é responsável por todos os processos e procedimentos abertos por ela

7.9.3.1.3. Acesso necessários da CS terceirizada

7.9.3.1.4. Integração de processos e ferramentas

7.9.3.2. Metas do ANS

7.9.3.2.1. Deve existir metas para tratamento e resolução de incidentes

7.9.3.2.2. Deve também coordenar e acordar com cada grupo de suporte os ANOs e CAs para que fique cientes e atentos às metas do ANS

7.9.3.3. Boa comunicação

7.9.3.3.1. Presença física próxima

7.9.3.3.2. Reuniões frequentes para análise e verificação

7.9.3.3.3. Tutoriais sobre vários assuntos para as equpes e departamentos

7.9.3.3.4. Composição de parcerias quando as equipes de ambas as empresas participam do atendimento

7.9.3.3.5. Planos de comunicação e metas de desempenho documentados de forma consistente nos ANOs e CAs

7.9.3.4. Propriedade dos dados

7.9.3.4.1. Fator extremamente importante

7.9.3.4.2. A propriedade da informação sempre deverá ser da empresa contratante

7.9.3.4.3. Todas as questões relacionadas à propriedade dos dados devem ser mencionadas no CA com a empresa que irá fornecer o serviço terceirizado

7.9.4. Terceirização com empresas no exterior

7.9.4.1. Programas de treinamento com foco na cultura do mercado local do cliente

7.9.4.2. Conhecimento do idioma, a linguagem coloquial do cliente

7.9.4.3. Cursos para uso das ferramentas e métodos de trabalho da empresa do cliente

8. Funções

8.1. Visão Geral

8.1.1. Explica as funções

8.1.1.1. Operação de Serviço de Gerenciamento Técnico

8.1.1.2. Gerenciamento das Operações de TI

8.1.1.3. Gerenciamento de Aplicativos

8.2. Papéis de Cada Função

8.2.1. Gerenciamento Técnico

8.2.1.1. Implica no gerenciamento geral da infraestrutura de TI, colocando seu conhecimento técnico à disposição de toda a organização

8.2.1.2. Conhecimento transmitido por intermédio de grupos, departamentos ou equipes

8.2.1.3. Papel Duplo

8.2.1.3.1. Detentor do conhecimento técnico

8.2.1.3.2. Fornecedor dos recursos que irão suportar o Ciclo de Vida do GSTI

8.2.1.3.3. Executando estes dois papéis, garante que a organização tenha os recursos humanos necessários para atender os objetivos do negócio

8.2.1.3.4. Fornecedor de Serviço pode definir os requisitos destes papéis durante a fase de Estratégia do Serviço

8.2.1.3.5. Expandir durante a fase de Desenho do Serviço

8.2.1.3.6. Requisitos serão validados no MCS

8.2.1.3.7. Cabe também ao Ger. Técnico chegar a um equilíbrio entre

8.2.1.4. Orientação das Operações de TI

8.2.1.4.1. Outra tarefa chave é fornecer um guia para as Operações de TI

8.2.2. Gerenciamento das Operações de TI

8.2.2.1. Responsável por gerenciar as atividades operacionais do dia-a-dia na organização

8.2.2.2. Características

8.2.2.2.1. Garante que um dispositivo, sistema ou processo esteja operando devidamente

8.2.2.2.2. Transforma planos em ações

8.2.2.2.3. Foco nas atividades diárias

8.2.2.2.4. Cria ações repetitivas e consistentes

8.2.2.2.5. Ajuda a oferecer e a avaliar o valor real de uma organização

8.2.2.2.6. Mostra que o valor gerado excede o custo do investimento e de outras sobrecargas organizacionais

8.2.2.3. É responsável pelo gerenciamento e manutenção da infraestrutura de TI da organização de forma a entregar os serviços de suporte de TI dentro dos níveis acordados

8.2.2.4. Atividades

8.2.2.4.1. Controle das Operações de TI

8.2.2.4.2. Gerenciamento das Instalações

8.2.2.5. Papel Duplo

8.2.2.5.1. Papel 1

8.2.2.5.2. Papel 2

8.2.2.5.3. As Operações de TI precisam alcançar o balançoe entre estes papéis, o que requer

8.2.3. Gerenciamento de Aplicativos

8.2.3.1. Gerenciamento dos aplicativos por todo o seu ciclo de vida

8.2.3.2. Executa um papel importante no desenho, teste e melhoria das aplicações utilizadas para entregar Serviços de TI

8.2.3.3. Gerencia todas as aplicações, sejam desenvolvidas internamente ou compradas

8.2.3.4. Papel

8.2.3.4.1. Papel 1

8.2.3.4.2. Papel 2

8.2.3.4.3. Outros papéis

8.3. Objetivos

8.3.1. Gerenciamento Técnico

8.3.1.1. Visa ajudar a organização no planejamento, implementação e manutençaõ de uma infra técnica estável

8.3.1.2. Suporta os processo de negócio da organização

8.3.1.3. São alcançados

8.3.1.3.1. Com o desenho da topologia técnica robusta pois irá economizar em custos para a organização

8.3.1.3.2. Utilizando habilidades técnicas adequadas, o que irá ajudar a manter a infraestrutura técnica da organização em boas condições

8.3.1.3.3. Usando as habilidades técnicas para diagnosticar e resolver mais rapidamente possíveis falhas

8.3.2. Gerenciamento das Operações de TI

8.3.2.1. Manter o status quo para maior estabilidade dos processos e atividades da organização

8.3.2.2. Analisar e melhorar continuamente para oferecer serviços melhores e por menor custo

8.3.2.3. Aplicar as habilidades operacionais no diagnóstico e resolução das possíveis falhas nas operações de TI

8.3.3. Gerenciamento de Aplicativos

8.3.3.1. Suportar os processos de negócio da organização pela identificação funcional e de gerenciamento para o aplicativos

8.3.3.2. Auxiliar no desenho, implantação, suporte contínuo e melhoria dos aplicativos

8.3.3.3. São alcançado através

8.3.3.3.1. Implementação de aplicativos bem desenhados, resilientes e a um custo efetivo

8.3.3.3.2. Garantia de que as funcionalidades requeridas estão disponíveis para alcançar os resultados requeridos ao negócio

8.3.3.3.3. Gerenciamento das habilidades técnicas para manter as aplicações operacionais em boas condições

8.3.3.3.4. Utilização das habilidades técnicas para diagnosticar rapidadmente e resolver qualquer falha técnica que ocorrer

8.4. Atividades

8.4.1. Gerenciamento Técnico

8.4.1.1. Identificar o conhecimento e experiência necessária para gerenciar e operar a infra de TI e entregar Serviços de TI

8.4.1.2. Documentar as habilidades existentes ou que precisam ser desenvolvidas

8.4.1.3. Iniciar programas de treinamento

8.4.1.4. Oferecer treinamentos para usuários, Central de Serviços e outros Grupos

8.4.1.5. Recrutar recursos com habilidades que não podem ser desenvolvidas internamente

8.4.1.6. Ajudar a definir as arquiteturas

8.4.1.7. Desenvolver soluções para expandir o portfólio de serviços

8.4.1.8. Envolver-se no desenho e construção de novos serviços

8.4.1.9. Envolver-se em projetos

8.4.1.10. Avaliar os riscos, identificar as dependências críticas de serviços

8.4.1.11. Elaborar e executar testes de funcionalidade, desempenho e capacidade do GSTI

8.4.1.12. Gerenciar os fabricantes e o desempenho

8.4.1.13. Definir e coordenar as ferramentas de Ger. de Eventos

8.4.1.14. Definir procedimentos de escalada pelo Ger. de Incidente

8.4.1.15. Providenciar recursos para o Ger. de Problema

8.4.1.16. Implantar as Liberações

8.4.1.17. Manger o Sistema de Gerenciamento da Configuração

8.4.1.18. Envolver-se no processo MCS

8.4.1.19. Manter a documentação dos sistemas

8.4.1.20. Ajudar no Ger. Financeiro de TI

8.4.1.21. Envolver-se na definição das atividades operacionais

8.4.2. Gerenciamento das Operações de TI

8.4.2.1. Em alguns casos recursos do Ger. Técnico e de Aplicação formam parte desta função

8.4.2.2. Isto significa que estes dois grupos também exercem atividades operacionais

8.4.3. Gerenciamento de Aplicativos

8.4.3.1. Oferecer suporte 3 nível a Incidentes relacionados a aplicativos

8.4.3.2. Envolver-se nos planos de testes das operações e assuntos de implementação

8.4.3.3. Controlar os Bugs e Patches

8.4.3.4. Envolver-se na operação e suporte de erros como erro de código, mensagens de erro e eventos

8.4.3.5. Dimensionamento das aplicações e métricas de volume

8.4.3.6. Elaboração de políticas de Liberação

8.4.3.7. Identificar melhorias necessárias nos software existentes