1 / 64

Gestão de Serviços de TI com ITIL Versão 3 3. Transição de Serviços

Gestão de Serviços de TI com ITIL Versão 3 3. Transição de Serviços. Márcio Moreira & Mário Peixoto marcio.moreira@pitagoras.com.br http:// si.lopesgazzani.com.br/docentes/marcio/. 1ª Parte. Transição de Serviços. Processos de Transição: Planejamento e Suporte da Transição (novo)

Download Presentation

Gestão de Serviços de TI com ITIL Versão 3 3. Transição de Serviços

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gestão de Serviços de TIcom ITIL Versão 33. Transição de Serviços Márcio Moreira & Mário Peixoto marcio.moreira@pitagoras.com.br http://si.lopesgazzani.com.br/docentes/marcio/

  2. 1ª Parte

  3. Transição de Serviços • Processos de Transição: • Planejamento e Suporte da Transição (novo) • Validação e Testes de Serviços (novo) • Gestão de Versões e Distribuição • Avaliação (novo) • Processos de Suporte à Transição: • Gestão de Mudanças • Gestão de Configuração e Ativos de Serviços • Gestão de Conhecimento (novo) • Conceitos chaves: • Mudanças • Ativos • Itens de Configuração • Versão (Liberação) • Distribuição • Validação • Testes • Informação: • SKMS: Service Knowledge Management System • Sistema de Gestão do Conhecimento do Serviço

  4. Propósitos da transição • Propósito: • Planejar e gerenciar capacidades e recursos necessários para empacotar, construir, testar e distribuir uma versão (release), de um serviço novo ou alterado, em produção e estabelecer o serviço especificado em termos de requisitos dos clientes e dos patrocinadores. • Minimizar o impacto não previsto de mudanças no ambiente de produção. • Situações críticas típicas: • Inclusão ou alteração de serviços • Terceirização (outsourcing ou off-shoring) • Internalização (insourcing) • Mudança de fornecedor • Mudança para uma central de serviços compartilhada • Divisão do trabalho entre fornecedores (smart-sourcing, joint venture, etc.) • Down-sizing ou up-sizing • Fusões ou aquisições

  5. Importância & benefícios da transição • Importância da Transição: • Alinhar serviços novos ou modificados com os requisitos e operação de negócio dos clientes • Garantir que clientes e usuários podem usar o serviço • Benefícios da Transição: • Melhora a previsibilidade das variáveis de projeto (custo, prazo, recursos, etc.) • Melhora a taxa de sucesso de mudanças • Habilidade de adaptar-se rapidamente à evoluções e novos requisitos de mercado • Facilita o compartilhamento e o reuso de ativos entre projetos e serviços • Reduzir os atrasos de questões inesperadas e dependências, por exemplo: de ambientes de teste, mudanças de negócio, etc • Reduz o esforço gasto na transição, testes na gestão dos serviços de TI • Melhora a gestão de expectativas dos interessados (clientes, usuários e parceiros) • Melhora a adequação aos requisitos, níveis de governança e legislação • Habilita o custo efetivo

  6. Processo de Transição • Gestão de Mudanças • Gestão de Ativos e Configuração de Serviços • Planejamento e Suporte da Transição • Avaliação (geral) • Gestão de Versões e Distribuição • Validação e Testes de Serviços • Gestão de Conhecimento

  7. Princípios da transição(última chance antes da produção) • Definição do serviço: • Com a estratégia publicada, revise a definição do serviço • Garantias e utilidade dos serviços: • Se os resultados de negócio do cliente forem atendidos pelo serviço, as restrições dele serão removidas • ROA (Return On Assets) = Compensação / Custo de servir

  8. Política de Transição • Defina e implemente uma política formal de transição • Implemente todas as mudanças através da Transição (exemplo) • Adote um framework padrão comum • Maximize o reuso de processos e sistemas • Alinhe os planos de transição com as necessidades de negócio • Estabeleça e mantenha relacionamentos com os interessados • Estabeleça controle e disciplinas efetivos • Forneça sistemas para transferência de conhecimento e suporte a decisão • Planeje os pacotes de versões e a distribuição • Antecipe e gerencie as ações corretivas • Faça gestão proativa de recursos durante toda a transição • Envolva a transição o mais cedo possível no ciclo de vida do serviço • Garanta a qualidade dos serviços novos ou modificados • Melhore a qualidade da transição

  9. Planejamento e Suporte daTransição • Propósito: • Planejar e coordenar recursos para garantir os requisitos definidos na Estratégia, implementados no Projeto, sejam realizados na Operação do Serviço • Identificar, gerenciar e controlar os riscos de falhas e interrupções nas atividades de transição • Objetivos: • Planejar e coordenar recursos para colocar com sucesso um serviço novo ou modificado em produção com previsibilidade de custo, qualidade e prazo • Garantir que todos os parceiros adotem um framework comum de padrões reutilizáveis de processos e sistemas de suporte • Fornecer planos claros e compreensíveis que habilitam o cliente e os projetos de mudança do negócio alinharem suas atividades

  10. Localização da Transição Ideias (Estratégia) Plataforma de Entrega do Serviço Equipe de Projeto Equipe de Operação • Transição • Requisitos • Análise & Projeto • Implementação • Testes de Sistema • Como entregar ao cliente? • Como suportar? • Como gerir? • Testes de aceitação • Entrega do Serviço • Incidentes • Requisições de Serviço • Gestão de Indicadores • Projeto • Operação Clientes Serviço Implementado

  11. Atividades do processo Planejamento da Transição Suporte à Transição

  12. Defina a estratégia da transição • Aspectos a considerar: • Propósito, objetivos e metas da transição (perseguir custo efetivo) • Contexto, exemplo: serviços do cliente, portfólio de contratos • Escopo: inclusões e exclusões • Padrões aplicáveis, acordos, leis, normas e requisitos contratuais • Organizações e principais envolvidos na transição • Framework para a Transição de Serviços • Critérios, pessoas e abordagem • Requisitos e conteúdo dos serviços (novo/modificado) • Entregáveis das atividades de transição, incluindo documentação obrigatória e opcional de cada estágio • Marcos do cronograma • Requisitos financeiros: orçamentos e fundos

  13. Prepare a transição do serviço • Aspectos a considerar: • Reveja e valide as entradas das fases anteriores do ciclo de vida. • Reveja e verifique os entregáveis recebidos. Por exemplo: SDP (Service Design Package ou Pacote de Projeto de Serviço), Critérios de Aceitação do Serviço e relatório de avaliação. • Identifique, crie e programe as mudanças (RFCs) • Verifique quais linhas de base de configuração estão registrados na Gestão Configuração antes do início da Transição de Serviço • Verificar se está tudo pronto para a transição.

  14. Planeje e coordene a transiçãode um serviço 1/2 • Planejando a transição de um serviço: • Fazer planos de transição contendo: • Ambiente de trabalho e infraestrutura para transição • Cronograma de marcos, entrega e prazos de entrega • Atividades e tarefas a executar • Recursos, requisitos, orçamentos e linha do tempo para cada fase • Riscos e assuntos a gerir • Lead times (janelas de mudanças) e contingências (durante as mudanças e plano de roll-back) • Planejamento Integrado: • Além do detalhamento dos planos é preciso integrá-lo ao calendário de mudanças, versões e distribuição da empresa como um todo • Avaliar e melhorar pro ativamente o serviço preparando o suporte inicial

  15. Planeje e coordene a transiçãode um serviço 2/2 • Adotando as melhores práticas de gestão de programas e projetos: • Gerir a versões (releases) e distribuições como um programa • Cada distribuição como um projeto (parte do programa) • É preciso ter pessoas competentes para isto. Considere: • Pessoas, aplicações, hardware, software, documentação e conhecimento • Revendo os Planos: • Antes de começar a execução da transição de um serviço: • Os planos estão atualizados? • Os planos foram aceitos pelos envolvidos? • Os planos estão alinhados com: datas, entregáveis, Mudanças, Erros Conhecidos ou Problemas? • Os impactos (custos, organização, técnicos e comerciais) foram checados? • Todos os componentes (elementos da versão) estão prontos? Etc.

  16. Atividades de Suporte à Transição • Aconselhamento: • O responsável pela transição deve orientar, o mais cedo possível, os GPs a usar os padrões, políticas e procedimentos de transição • Administração: • Gerir: • Mudanças, ordens de trabalho, riscos, problemas, desvios, ferramentas, processos, comunicações, etc. • Performance do processo de transição • Monitoramento do progresso e geração de relatórios: • Monitorar o progresso e gerar os relatórios de desempenho do programa de transição

  17. Gestão de Mudanças • Mudança: • Mudança é o processo de movimentação (inclusão, alteração ou exclusão) autorizada de um serviço ou componente (CI), planejado ou em operação, e de sua documentação associada. • As RFC (Request For Change) são registradas no CMS (Configuration Management System) • Propósitos: • Atender as mudanças de requisitos de negócios de nossa empresa e de nossos clientes, enquanto minimiza incidentes, interrupções e retrabalho, promovendo alinhamento da TI aos negócios. • Objetivos: • Economizar tempo e dinheiro, gerenciando e otimizando a exposição à riscos, moderando os impactos e as indisponibilidades e obtendo sucesso na primeira tentativa, convertendo estes em benefícios. • Garantir padronização de: métodos, processos e procedimentos. • Facilitar pronta e eficientemente a gestão de todas as mudanças. • Balancear a relação entre as necessidades e os impactos das mudanças.

  18. Conceitos relacionados a mudanças • CAB (Change Advisory Board): • Comitê Consultivo de Mudanças • Aprova (ou não) e prioriza as mudanças • Membros: • Gerente de Mudança (mediador) • Clientes (responsabilizado) • Gerentes e representantes de usuários (impactados) • Desenvolvedores de aplicação • Especialistas e consultores • Gerentes: Service Desk, Testes, Segurança, etc. • Representantes do fornecedor (quando necessário) • Etc. • Baseline (linha de base): • Situação da infraestrutura de TI num determinado momento no tempo. • As Mudanças autorizadas levam de uma BL1 (versão 1) para uma BL2 (versão 2) • Avaliação (extensão do PIR Post Implementation Review) : • Processo utilizado para mudanças de grande impacto • Este processo é consultado antes da mudança (para definir objetivos) e é executado após a mudança (para atestar a eficácia dela)

  19. Níveis de CAB

  20. Escopo e riscos das mudanças • Gerindo as mudanças, gerimos os riscos que elas introduzem. • 5 sinais de Gestão de Mudanças pobres: • Ocorrem mudanças sem autorização • Alto volume de mudanças emergenciais • Atraso na execução de mudanças • Baixa taxa de sucesso • As mudanças causam resultados inesperados • Tipos de Mudanças: • Estratégicas: afetam o negócio • Táticas: afetam o processo de negócio (o portfólio ou um serviço) • Operacionais: afetam operações (corretivas)

  21. Requisitos e atividades das mudanças Os 7 R das mudanças Atividades da G. Mudanças Usar Plano de Roll-back CS (Change Schedule ou Cronograma de Mudanças) Antigo PIR parte da Avaliação

  22. Políticas de mudanças e dicas de fechamento com sucesso Políticas de Mudanças Fechamento de Mudanças Coordenar e controlar as atividades de pós Implementação da Mudança (acompanhar o ambiente pós mudança) O Gerente de Mudanças deve fazer uma revisão das mudanças mais críticas após a sua implementação (Avaliação antigo Post ImplementationReview - PIR) para ver se ela foi efetiva (vide questões abaixo) e buscar pontos de melhoria. Objetivo atingido? Usuários e clientes estão satisfeitos? Surtiu efeitos colaterais? Recurso consumido de forma devida? Tempo e custos de acordo? O Gerente de Mudança poderá solicitar a ajuda ao CAB para fazer a Avaliação (PIR), caso julgue necessário. • Criar a cultura da Gestão de Mudanças: • Tolerância zero p/ mudanças não aprovadas • Alinhar mudanças com negócios, processos, projetos e envolvidos • Priorizar as mudanças: • Ex: Inovativas x Preventivas x Detectivas x Corretivas • Medirresultados e responsabilizar • Criar um ponto focal único de mudanças • Evitar que pessoas não autorizadas executem mudanças ou tenham acesso ao ambiente de produção • Integrar e estabelecer rastreabilidade para as mudanças • Criar janelas de mudanças e exigir autorização fora dela

  23. Categorias de mudanças

  24. Processo de mudanças normal

  25. Processos emergencial e padrão

  26. Papel do Gerente de Mudanças

  27. Interfaces • Gestão de Mudanças: Aprovação e Coordenação • Gestão de V. e Distribuição: Execução das Mudanças • Gestão de Incidentes: Detecção e pede Mudanças • Gestão de Problemas: Pede Correções • Gestão de Configuração: Registra as Mudanças

  28. KPIs • MTRS: • Mean Time To Restore Service • Tempo médio para restaurar o serviço • % de mudanças bem sucedidas • % de redução de interrupções • % de mudanças não planejadas • % de mudanças emergenciais • % de roll-back necessários • % de incidentes de mudanças • % de retrabalho de mudanças • Tipos de medidas: • Medidas de saídas: • Nº de interrupções causadas pelas mudanças ou liberações • Falta de precisão na especificação das mudanças • Avaliação de impacto incompleta • Mudanças não autorizadas pelo negócio ou cliente • Carga de trabalho: • Freqüência de mudanças • Volume de mudanças • Medidas de processos: • Satisfação das pessoas com velocidade, clareza e facilidade • % de mudanças normais Total Downtime (horas) MTRS = –––––––––––––––––– Nº Serviços Parados

  29. Questões de prova • 1) De acordo com o processo de Gestão de Mudanças ITIL, quem é responsável por categorizar uma mudança? • A. Gerente de Mudanças. • B. Comitê de Mudanças (CAB). • C. Requisitante da Mudança. • D. Implementador da Mudança. • 2) De acordo com o ITIL, uma vez que a mudança foi construída, quem é responsável por testá-la? • A. O Desenvolvedor da Mudança. • B. O Gerente de Mudanças. • C. O Comitê de Mudanças (CAB). • D. Um testador independente.

  30. Questões de prova • 3) Qual a principal razão para o estabelecimento de uma Linha de Base (Baseline)? • A. Para padronizar a operação • B. Para conhecer os custos dos serviços fornecidos • C. Para esclarecer os papéis e responsabilidades • D. Para comparação posterior • 4) Qual o papel do Comitê Consultivo de Mudança Emergencial (ECAB)? • A. Apoiar o Gerente de Mudança a garantir que nenhuma Mudança urgente é realizada durante períodos particularmente voláteis para o negócio • B. Apoiar o Gerente de Mudança na Implementação de Mudanças Emergenciais • C. Apoiar o Gerente de Mudança a avaliar Mudanças Emergenciais e decidir se a Mudança deve ser aprovada ou não • D. Apoiar o Gerente de Mudança a aumentar a rapidez do Processo de Mudança Emergencial para que atrasos inaceitáveis não ocorram

  31. Questões de prova • 5) Qual item abaixo NÃO é um tipo de mudança? • A. Mudança Padrão • B. Mudança Normal • C. Mudança Crítica • D. Mudança Emergencial • 6) Quais das afirmações abaixo são exemplos de ferramentas que podem suportar a Transição do Serviço? • 1. Uma ferramenta que armazena as versões definitivas de Software • 2. Uma ferramenta de Workflow para o gerenciamento de mudanças • 3. Uma ferramenta automatizada de distribuição de software • 4. Ferramentas de teste e validação • A. 1, 3 e 4 somente • B. 1, 2 e 3 somente • C. 2, 3 e 4 somente • D. Todas acima

  32. 2ª Parte

  33. Gestão de Configuração eAtivos de Serviços (SACM) • SACM (Service Asset and Configuration Management): • O processo Gestão de Configuração e Ativos de Serviços (antigo Gestão de Configuração) gerencia os ativos de serviços e Itens de Configuração (CI) para suportar a Gestão de Serviços e controlar requisitos de negócio e do cliente, otimizando a performance, custos e riscos. • Propósitos: • Fornecer um modelo lógico para identificar, controlar, registrar, reportar, auditar e verificar ativos de serviços e itens de configurações, incluindo versões, linha de base, componentes, atributos e relacionamentos. • Contabilizar para gerenciar e proteger a integridade dos ativos e CI • Estabelecer e manter um CMS (Configuration Management System ou Sistema de Gestão de Configuração) garantindo o controle necessário para os serviços e a infraestrutura de TI. • Prover bases sólidas de informações para a gestão de: Incidentes, Problemas, Mudanças e Liberações. • Verificar os registros contra a infraestrutura e corrigir as exceções.

  34. Conceitos e Objetivos do SACM • Conceitos: • Item de Configuração (CI = Configuration Item): • Componentes da infraestrutura que são controlados por este processo. • Ex.: Servidor, switch, ERP, documento de requisitos, manual de configuração, etc. • Ativo (Asset): • Qualquer recurso ou habilidade utilizado para fornecer o serviço. Podem ser: gestão, organização, processos, conhecimento, pessoas, informações, aplicações, etc. • CMDB (Configuration Management Database): • Base de dados contendo todos os detalhes relevantes de cada CI e detalhes do relacionamento entre eles. Pode ser um conjunto de bases de dados. • Base Level (Nível Base = granularidade do CMDB): • Nível mais baixo de identificação de um CI como único (decisão mais importante do SACM). • Base Line (Linha de Base): • Situação (snapshot) da infraestrutura (infra, aplicação e serviço) num determinado momento. • Objetivos: • Melhorar a capacidade de planejamento e definição de metas (forecast) • Apoiar a entrega do nível de serviço e garantias combinadas • Melhorar a aderência a padrões, normas, leis e obrigações contratuais

  35. Ciclo de vida e categorias dos CIs • Registrado: • Inserido no CMS pela Gestão de Configuração • Aceito: • Verificado pela Gestão de Versões e Distribuição • Instalado: • Instalado pela Gestão de Versões e Distribuição • Removido: • Removido pela Gestão de Versões e Distribuição • Categorias dos CIs: • Do Ciclo de Vida: • Caso de Negócio, Planos, SDP e versões. • Do Serviço: • Habilidades e recursos. • Da Organização: • Estratégia, políticas e leis. • Internos: • Hardware e software. • Externos: • Requisitos, SLA, versões de fornecedores e serviços externos • De Interface: • Serviços sobre uma SPI (Service Provider Interface)

  36. Modelo lógico exemplo e atributos • Atributos básicos: • Identificador único • Tipo, Situação e Proprietário • Nome ou descrição • Data de recepção e expiração • Fornecedor ou fonte • Documentos relacionados • Softwares relacionados • Trilha de auditoria • SLA aplicável

  37. CMS: Configuration Management SystemSistema de Gestão de Configuração Camada de Apresentação: Apresenta informações nas várias visões necessárias Camada de processamento de conhecimento: Consultas, análises, relatórios, gestão de performance, modelagem e indicadores Camada de integração de informação: Coleta, estruturação e armazenamento de informações. Dados, fontes e ferramentas: Contém os bancos de dados físicos, as bibliotecas de mídias, plataformas de configuração, etc.

  38. Armazenamento de CIs • Biblioteca Segura (Secure Library): • Conjunto de softwares, documentos ou CIs eletrônicos confiáveis • Armazém Seguro (Secure Store): • Local onde os ativos de TI são armazenados • Biblioteca Definitiva de Mídia (DML: Definitive Media Library): • Local seguro onde as versões finais autorizadas de todas as mídias são armazenadas e protegidas • Peças Sobressalentes Confiáveis (Definitive Spares): • Área reservada para o armazenamento seguro de peças de reposição confiáveis

  39. Atividade do SACM

  40. Apoio do SACM a outros processos • Service Desk: • Informa: impactos das falhas, SLA associado, proprietário, etc. • Gestão de Eventos: • Tendências dos CIs • Gestão de Incidentes: • Falhas dos CIs e impactos • Gestão Financeira: • Informações dos ativos • Disponibilidade e Continuidade: • Pontos de falhas e relações entre CIs • Gestão do Nível de Serviços: • Identificação das dependências e relações entre os CIs • Gestão de Mudanças: • Impacto das mudanças

  41. Gestão de Versões eDistribuição (R&DM) • Propósito (Release and Deploy Management): • Distribuir uma versão (release), nova ou modificada do serviço, no ambiente de produção, habilitando o uso efetivo e entregando valor. • Objetivos: • Entregar mudanças rápidas, com custo efetivo e minimizar riscos. • Garantir que os clientes e usuários possam usar o serviço para atingir as metas de negócio. • Melhorar a consistência da implementação através das mudanças de negócio, equipes de serviços, fornecedores e clientes. • Contribuir para atingir os requisitos de rastreabilidade da transição. • Responsabilidades: • Garantir a integridade do CMDB após a realização das mudanças. • Obs.: R&DM  Distribuição (instalação). G. Mudanças  Verificação. • Gerenciar as expectativas dos clientes e usuários sobre a versão.

  42. Versões ou releases • Conceito: • Uma liberação se refere a uma ou várias atividades de mudanças autorizadas em TI • Tipos (exemplos): • Maior (major): • Normalmente contem uma grande quantidade de novas funcionalidades que encapsulam todas as atualizações, liberações e correções emergenciais anteriores • Ex.: Office 2010 • Menor (minor): • Normalmente contem pequenas melhorias e encapsulam correções anteriores • Ex.: Office 2010 SP1 • Emergenciais (emergency): • Normalmente contem correções de um pequeno número de erros conhecidos algumas vezes alguma pequena melhoria crítica para o negócio • Ex.: Office 2010 SP1 KB2800779

  43. Abordagens de distribuição • Big Bang ou Faseado (Phased): • Big bang: o serviço é distribuído para todas as áreas usuárias de uma vez • Faseado: o serviço é distribuído em fases • Empurrada (push) ou puxada (pull): • Empurrada: o servidor distribui • Puxada: o usuário tem que baixar • Automatizado (automation) ou manual (manual): • A distribuição pode ser feita de forma automática ou manual

  44. Atividades de R&DM

  45. Pacote de versão • A chave do R&DM é a definição apropriada do pacote • Fatores de empacotamento: • Facilidade de instalação • Quantidade de mudanças e de recursos necessários • Complexidade das interfaces • Disponibilidade de storage

  46. Coordenando uma distribuição

  47. Validação e testesde serviços • Propósito: • Garantir que o serviço (novo ou alterado) esteja apto para o uso, e portanto, fornecerá o valor esperado pelo cliente e por nossa área de negócio. • Objetivos: • Garantir que a versão entrega os resultados esperados atendendo aos custos, capacidade, performance e restrições projetados. • Assegurar a Utilidade e Garantia do serviço. • Confirmar se os requisitos projetados dos clientes e do nosso negócio foram corretamente atendidos

  48. Restrições e políticas • Políticas: • Qualidade do serviço: • Define praticamente a qualidade do serviço • Requer alta senioridade • Riscos: • Níveis de riscos por: segmentos de clientes, empresas, unidades de negócio e de serviço • Transição do serviço • Versões e distribuição • Gestão de Mudanças

  49. Modelo V de testes Atividades de Validação Verificação Requisitos Cliente & Negócio Validar Ofertas, Pacotes, etc. Planos e Critérios de Revisão do Serviço Contratos, Pacote de Serviço, SLP, SPI Requisitos do Serviço Testar a Aceitação P&C de Aceitação do Serviço SLR e Rascunho do SLA Projeto da Solução Testar Operação do Serviço Planos e Critérios de Operação SDP, M. Serviço, Capacidade e Recursos Projeto da Versão do Serviço Testar o Pacote da Versão P&C de Teste de Versão Planos & Projetos Desenvolver a Solução Montar e Testar Componente Construir e Testar Componente

  50. Atividades de Validação e Testes

More Related