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

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