Your SlideShare is downloading. ×
Apresentacao Aula Parte3
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Apresentacao Aula Parte3

1,555
views

Published on


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,555
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
36
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Tipos de Centrais de Serviço Central de Atendimento ( Call Center ) Voltada para grandes volumes de chamadas e transações por telefone, neste caso esta central não atua sobre as transações e encaminha para a área devida dentro da organização. Central de Suporte ( Help Desk ) O principal objetivo é que nenhuma requisição seja perdida ou não atendida, mesmo depois de cadastrada, tem também como função resolver e coordenar incidentes, propiciando a interface (ou comunicação) com o Gerenciamento da Configuração. Central de Serviços ( Service Desk ) A característica principal é a abrangência dos serviços, pois o processo de negócio neste caso está integrado, não resolvendo só incidentes, mas também problemas, dúvidas e fazendo interface com as requisições de mudanças.
  • 2. Principais Benefícios
    • Aumento de acessibilidade: Ponto único de contato e suporte sempre disponível.
    • Produtividade: a equipe de 2º. Nível não é interrompida por chamadas de usuários.
    • Redução de impacto: rapidez na restauração dos serviços.
    • Disponibilidade do atendimento.
    • Percepção de qualidade e satisfação dos clientes.
    • Melhora no trabalho em equipe.
    • Melhor comunicação: a equipe da Central de Serviços terá habilidades para o relacionamento com o usuário, e será focada em dar o feedback de suas solicitações.
    • Indicadores para gestão e suporte à decisão.
  • 3. Gerenciamento de Incidentes Um Gerenciamento de Serviços de TI está orientado a entrega de níveis de serviços com qualidade e com a rapidez que o negócio exige, para isto é necessário ter um processo de tratamento de incidentes eficaz e eficiente, capaz de monitorar os níveis de serviços, escalando os incidentes quando necessário. O processo de Gerenciamento de Incidentes tem como missão restaurar os serviços o mais rápido possível com o mínimo de interrupção, minimizando os impactos negativos nas áreas de negócio.
  • 4. Gerenciamento de Incidentes
    • OBJETIVO
    • Resolver os incidentes o mais rápido possível, restabelecendo o serviço normal dentro do prazo acordado nos ANS’s (Acordo de Nível de Serviço - SLA);
    • Manter a comunicação dos status dos incidentes aos usuários.
    • Escalonar os incidentes para os grupos de atendimento para que seja cumprido o prazo de resolução.
    • Fazer avaliação dos incidentes e as possíveis causas informando ao processo de Gerenciamento de Problemas. Este processo não é responsável por fazer o diagnóstico identificando a causa raiz, apenas auxiliará o processo de Gerenciamento de Problemas que tem este foco.
  • 5. Gerenciamento de Incidentes
  • 6. Gerenciamento de Incidentes
  • 7. Gerenciamento de Incidentes Impacto = criticidade para o negócio Urgência = velocidade A prioridade poderá ser utilizada para determinar o prazo para resolução dos incidentes. Prioridade Descrição Tempo para atendimento 1 Crítica 1 hora 2 Alta 4 horas 3 Média 24 horas 4 Baixa 48 horas 5 Planejada - Definição de Impacto, Urgência e Prioridade
  • 8. Etapas – Gerenciamento de Incidentes
    • Investigação e Diagnóstico
    • Resolução e Restauração
    • Fechamento do Incidente
  • 9. Responsabilidades É importante que durante todo o ciclo de vida do incidente a Central de Serviços permaneça proprietária do incidente, sendo ela responsável pelo seu fechamento. Desta forma teremos um comprometimento maior da Central de Serviços para o cumprimento dos prazos, escalando o incidente para o grupo disponível quando necessário. Sendo assim, sempre que o usuário entrar em contato com a Central de Serviços terá uma pronta resposta sobre a situação de suas chamadas. Não é conveniente que os usuários tenham contato direto com os solucionadores finais do incidente, isto fará com que os usuários comecem a manter o contato direto com eles.
  • 10. Tipos de Escalonamento Os incidentes podem ter dois tipos de escalonamento: funcional ou hierárquico . No funcional os incidentes são escalonados para grupos com conhecimentos mais específicos sobre o assunto. No hierárquico o incidente pode ser escalonado para um chefe ou gerente da Central de Serviços, quando a situação exigir aprovação de custos ou maior poder de decisão.
  • 11. Relacionamentos
    • Gerenciamento de Configuração
    • Gerenciamento de Problemas
    • Gerenciamento de Mudanças
  • 12. Benefícios
    • Impacto dos incidentes reduzidos (devido ao tempo de resolução);
    • Suporte ao cumprimento dos ANS’s (SLA’s em inglês);
    • Eliminação de incidentes perdidos;
    • Melhor utilização da equipe de suporte, atingindo uma eficiência melhor;
    • O BDGC será mais preciso
    • Exportação de dados para o Gerenciamento de Problemas;
    • Melhora a satisfação do usuário; Menos interrupção da equipe de suporte.
  • 13. Pontos de Atenção
    • Possuir um software específico para controle de incidentes
    • O Sistema BDGC deve ser criado antes da implementação deste processo.
    • Base de Conhecimento vinculando erros conhecidos com soluções.
    • A equipe da Central de Serviços deve possuir um conhecimento suficiente.
    • É importante estabelecer níveis hierárquicos, fazendo com que o Gerente da Central de Serviços possa coordenar todos os níveis de suporte, desta forma será mais fácil exigir o cumprimento dos prazos estabelecidos nos ANS’s (Acordos de Nível de Serviço).
  • 14. Indicadores Principais indicadores deste processo: • Número total de incidentes, por área de negócio, departamento, natureza, etc. • Tempo médio entre falhas (MTBF) • Tempo médio para reparo (MTTR) • Número de incidentes resolvidos por operador • Redução do tempo médio de solução • Distribuição de solução entre os níveis de suporte • Porcentagem de incidentes resolvidos com a Base de Conhecimento
  • 15. Gerenciamento de Problemas
    • O processo é focado em encontrar relacionamentos entre os incidentes, problemas e erros conhecidos. O principal objetivo é a “análise da causa raiz”.
    • Objetivo :
    • Minimizar os efeitos adversos nos negócios;
    • Tratar as ocorrências causadas por erros em infra-estrutura;
    • Prevenir proativamente as ocorrências, problemas e erros;
    • Reduzir o número geral de incidentes;
    • Redução de Chamados para o 2º Nível
    • Definir procedimento de correção;
    • Informar demais áreas sobre a solução para a causa;
    • Banco de Dados de Erros Conhecidos;
  • 16. Conceitos
    • Problema : é a causa desconhecida de um ou mais incidentes
    • Solução de Contorno: solução não definitiva (em inglês Workaround )
    • Causa : é um erro em um Item de configuração
    • Erro Conhecido ( Known Error ): É um problema cuja causa foi diagnosticada e para qual existe uma solução
    • Solução: solução definitiva
    • Gestão de Incidentes X Problemas : foco na Solução rápida x foco na introdução de melhorias confiáveis e robustas na infra-estrutura.
  • 17. Gerenciamento de Problemas
  • 18. Entradas e Saídas
    • Entradas :
    • Registros de incidentes e detalhes sobre eles
    • Erros conhecidos
    • Informação sobre as configurações a partir do BDGC
    • Informação de outros processos
    • Saídas :
    • RMD’s (Requisições de Mudança) para começar o processo de mudança para resolver os Erros Conhecidos.
    • Informação Gerencial
    • Soluções de Contorno
    • Erros Conhecidos
    • Atualização dos registros de problemas e registro de problemas resolvidos quando o erro conhecido for resolvido.
  • 19. Controle de Problemas
  • 20. Controle de Erros
  • 21. Gerenciamento Proativo
  • 22. Revisão dos Problemas Graves
    • Ao final do ciclo de um problema grave, deve haver uma revisão para poder aprender:
    • O que deu certo?
    • O que fizemos de forma diferente?
    • Que lições podemos tirar da resolução deste problema?
  • 23. Ferramenta Análise Interface Gráfica Segurança Redes Processo Agendado Banco de Dados Erro Humano A página de pagamento não acessa no módulo da Folha de Pagamento A data de pagamento não entrada na tabela Nenhuma data de pagamento foi Comunicada a equipe O usuário conseguiu acessar a Folha de Pagamento O Cliente requisitou a próxima data de pagamento O registro não foi salvo na tabela. O Sistema não salvou o registro do próximo pagamento Módulo em não conformidade Como o layout. Nenhum erro foi exibido na chamada. Diagrama de Causa- Efeito
  • 24. Relacionamentos
    • Gerenciamento de Incidentes
    • Gerenciamento de Configuração
    • Gerenciamento de Mudanças
    • Gerenciamento Nível de Serviços
    • Gerenciamento da Capacidade
    • Gerenciamento da Disponibilidade
  • 25. Benefícios
    • Melhoria nos Serviços de TI.
    • Redução da quantidade de incidentes.
    • Soluções Permanentes, evitando ficar apenas na solução de contorno fazendo com que os mesmos incidentes continuem aparecendo novamente.
    • Melhora o aprendizado da organização através dos registros de Erro Conhecidos e Soluções de Contorno documentadas.
    • Aumento da taxa de resolução da Central de Serviços no primeiro contato com o usuário, evitando sobrecarregar o segundo nível. Este aumento deve-se ao fato de ter soluções de contorno já documentadas.
  • 26. Indicadores
    • Um Gerenciamento de Problemas com sucesso pode ser medido por:
    • Número de Problemas por status, serviços, impacto e classificação;
    • Número e impacto dos Incidentes durante a operação do processo;
    • Percentual de esforço reativo x proativo;
    • Esforço, custo e prazo dos diagnósticos;
    • Número de Requisições de Mudança geradas pelo processo de Controle de Erros;
    • Tempo para Solução de Problemas x Tempo Estimado