Visão Geral da Análise de Iniciação de Alterações Microsoft Operations Framework White Paper Publicado em Outubro de 2006

Transcrição

1 Visão Geral da Alterações Microsoft Operations Framework White Paper Publicado em Outubro de 2006 Sumário Este manual fornece informações detalhadas sobre a análise do gerenciamento de operações (OMR - Operations Management Review) da Alterações para organizações que implantaram, ou estão considerando a hipótese, tecnologias Microsoft em um centro de dados ou outro tipo de ambiente de computação empresarial. A Análise de Iniciação de Alterações é um dos quatro OMRs definidos e descritos no Modelo de Processo do Microsoft Operations Framework (MOF). O manual presume que o leitor seja familiarizado com a intenção, as funções de gerenciamento de serviços (SMFs - Service Management Functions) do MOF, bem como com as tecnologias abordadas da Microsoft. Informações detalhadas sobre os conceitos e princípios do MOF e do Microsoft Solutions Framework (MSF), estão contidas em informes técnicos, disponíveis em Informações sobre os OMRs e SMFs definidos no MOF também estão disponíveis em

2 O presente documento analisa uma versão preliminar de um produto de software que pode ser substancialmente alterado antes do aparecimento da versão comercial definitiva. O presente documento é publicado exclusivamente com fins informativos e a MICROSOFT NÃO OFERECE GARANTIAS, EXPLÍCITAS OU IMPLÍCITAS, NO PRESENTE DOCUMENTO. As informações contidas no presente documento, inclusive URL e outras referências a sites da Internet, estão sujeitas a alterações sem aviso prévio. A responsabilidade relativa aos riscos decorrentes do uso ou das conseqüências do uso do presente documento recai por completo sobre o usuário. Salvo indicações em contrário, as empresas usadas a título de exemplo, organizações, produtos, nomes de domínio, endereços de correio eletrônico, logomarcas, pessoas, lugares e acontecimentos comentados aqui são fictícios, e não se procura traçar, nem se deve deduzir, qualquer associação com empresas, organizações, produtos, nomes de domínio, endereços de correio eletrônico, logomarcas, pessoas, lugares ou acontecimentos do mundo real. O cumprimento de todas as leis aplicáveis em matéria de copirraite é responsabilidade do usuário. Sem limitação dos direitos protegidos por copirraite, nenhuma parte do presente documento pode ser reproduzida, armazenada ou introduzida em um sistema de recuperação, ou transmitida em qualquer formato ou por qualquer meio (eletrônico, mecânico, fotocópia, gravação ou qualquer outro) para qualquer finalidade, sem a permissão expressa e por escrito da Microsoft Corporation. A Microsoft pode ter patentes, patentear aplicativos, marcas comerciais, copirraites ou outros direitos de propriedade intelectual incidentes sobre a matéria analisada no presente documento. Exceto se assim disposto por escrito em algum documento de licença da Microsoft, a modificação do presente documento não oferece qualquer licença sobre tais patentes, marcas, copirraites ou outra propriedade intelectual Microsoft Corporation. Todos os direitos reservados. Microsoft, Active Directory, Word, Excel, PowerPoint, Outlook, Visual Basic e Windows são marcas registradas ou marcas comerciais de Microsoft Corporation nos Estados Unidos e/ou em outros países. Os nomes de empresas e produtos mencionados no presente documento podem ser marcas de seus respectivos proprietários.

3 Índice Índice... 3 Visão Geral Executiva... 4 Processos e Atividades de Análise... 5 Apêndices... 15

4 Visão Geral Executiva A Alterações é o ponto de gerenciamento inicial antes de aprovar uma mudança em um ambiente de produção. Ela também é um ponto de integração importante entre o Microsoft Solutions Framework (MSF) orientado aos projetos e o MOF orientado às operações, uma vez que sincroniza com o Project Plans Approved Milestone (Marco de Planos de Projeto Aprovados) no MSF. A Alterações considera a aceitação de uma mudança para implantação e a aprovação de planos para operar e suportar essa mudança. Ela considera também a aprovação de planos exigidos para a preparação de um ambiente de produção operar e suportar a mudança implantada. Essa Análise resulta em uma decisão de sim ou não a respeito da solicitação de mudança (RFC - request for change) e iniciar o gasto com o desenvolvimento da solução. Por meio do processo de Alterações, os principais atributos de uma mudança como especificados no processo de aprovação são feitos de acordo com padrões, políticas e métricas de qualidade. Além dessas verificações, os analistas validam a conformidade com outros critérios. Eles também avaliam os planos para seu impacto no ambiente de produção, qualquer pacote de alteração de suporte e a conclusão das funções preliminares, treinamento, suporte e planos de custo-benefício. Depois que as mudanças são aprovadas, elas procedem por um processo de gerenciamento no desenvolvimento. Dependendo do tamanho e origem da mudança, o MSF, ou outra disciplina de desenvolvimento, deve estar envolvido no processo. Encontre mais informações sobre o processo de gerenciamento de mudanças e métodos de aprovação na página A tabela que segue compara as principais características da Alterações e o OMR subseqüente, a Análise de Preparação da Versão. Tabela 1. Comparação de Análises Timing Alterações Ocorre quando uma mudança é enviada para aprovação e autorização para entrar na fase de Desenvolvimento, antes de começar os investimentos. Análise de Preparação da Versão Ocorre depois da mudança projetada, monitorada e testada, e antes disso, é introduzida no ambiente de produção. Objetivo Garantir que as alterações potenciais alcancem aprovação para mais investimento desenvolvimento apenas se forem alinhadas com os requisitos de usuário e padrões e políticas de TI estabelecidos (ou exceções aprovadas). Garantir que as operações implantam uma mudança apenas quando ela encontra totalmente os requisitos de TI para operabilidade e suportabilidade no ambiente de produção. Entrega Documentação que afirma ou nega autorização da mudança para iniciar a Fase de Desenvolvimento. Documentação que suporta a decisão de implantar a mudança ou adiar ou cancelar uma mudança. Participantes Representantes de usuários, clientes e várias equipes operacionais que representem cada um dos grupos de funções do Modelo de Equipe do MOF. Representantes de usuários, clientes e várias equipes operacionais que representem cada um dos grupos de funções do Modelo de Equipe do MOF.

5 Processos e Atividades de Análise Depois de a necessidade de uma alteração ter sido reconhecida e o iniciante da mudança ter chegado a uma RFC, a mudança é categorizada e priorizada com base nas informações iniciais disponíveis. Como resultado, o caminho para a mudança é definido e o processo de autorização continua deste ponto até a Alterações. Se a mudança for autorizada, ela continuará na implantação. Se não, é retornada para o iniciante para obter mais informações e ser novamente trabalhada antes de reenviada. Os processos detalhados para os passos do gerenciamento da mudança em direção à Alterações e o processo de aprovação são encontrados no SMF de Gerenciamento de Alterações, disponível em O gerente de mudanças e o iniciante são os primeiros participantes na discussão da Alterações, mas uma discussão formalizada pode também incluir representantes de outros grupos interessados. Este quadro é chamado de consultoria para mudanças (CAB - change advisory board) no SMF de Gerenciamento de Alterações. Dependendo da origem e impacto potencial da mudança e as políticas estabelecidas, a aprovação pode pedir uma discussão em diversos níveis: Autorização unilateral pelo gerente de mudanças Aprovação pela representação total no CAB Análise e validação pela comunidade de usuários Escalação de um comitê de emergência do CAB (CAB/EC) ou tecnologia de informação (TI) Esses diferentes níveis de autorização são definidos no SMF de Gerenciamento de Alterações. O manual de OMR de Alterações abordado aqui se refere à melhor maneira de desempenhar e utilizar o processo de análise para benefício máximo ao ambiente de TI e à organização em geral. MSF e MOF Como afirmado antes, a Alterações são um ponto principal de integração entre o MSF e o MOF. Ela corresponde ao Marco Aprovado de Planos de Projetos, no Modelo de Processo do MSF, e ocorre no final da Fase de Planejamento do MSF. Figura 1. Marcos e Fases do MSF

6 Processo de Quatro Passos da Alterações O processo de Alterações contém quatro passos essenciais: Análise de planejamento Análise da preparação Análise de conduta Análise de acompanhamento Como mostra a próxima figura, a saída da Alterações é a decisão para aprovar ou rejeitar uma RFC em particular. Figura 2. Processo de quatro passos da Alterações Na Alterações, o gerente de mudanças, CAB ou CAB/EC, avalia a probabilidade de aceitação da mudança para os ambientes de produção. Isso inclui análise e aprovação de: Planos para reduzir os impactos potenciais no ambiente de produção (por exemplo, aquisição de hardware ou recursos humanos necessários). Planos de preparação para preparar operações de TI para aceitar e operar a mudança. Planos de operação e suporte, alinhados com os requisitos de infra-estrutura, padrões e políticas. Orçamentos de projetos, com custos e benefícios comparativamente bem sucedidos e implementação da mudança no ambiente de produção (organização e infra-estrutura). Se aprovado, o RFC é atribuído a um proprietário e vai para as preparações de desenvolvimento, conduzido pelas equipes de mudança e desenvolvimento. Senão, o RFC é rejeitado e retornado ao iniciador da mudança até as melhorias necessárias na solicitação que foi feita, ou então é cancelado. A Alterações é alinhada com a autorização no processo de gerenciamento de mudanças, como mostra a figura que segue.

7 Figura 3. O lugar da Alterações dentro do processo de gerenciamento de mudanças Reunião de Análise de Planejamento Antes da Alterações, há aspectos importantes de planejamento que devem ser considerados, pois contribuem para um processo efetivo e eficiente de iniciação e aprovação. Diferentes grupos de funções, dentro do MOF, podem enviar RFCs para aprovação na Alterações por uma variedade de motivos, como mostra a tabela que segue. Tabela 2. Solicitações Comuns de Mudança de Acordo com o Grupo de Função do MOF Grupo de Função Infra-estrutura Operações Parceiro Versão Segurança Serviço Tipo de Solicitação para Mudança Novos sistemas e melhorias aos sistemas e infra-estruturas existentes. Mudanças que afetam ou melhoram as operações diárias da tecnologia. Mudanças referentes a terceiros ou fornecedores por exemplo, mudanças a um sistema terceirizado que afeta os sistemas internos. Mudanças nos sistemas e processos de gerenciamento de versão, configuração e alterações. Mudanças nos processos de segurança por exemplo, melhorias na segurança de rede ou autenticação. Mudanças conduzidas por novos requisitos de serviços, projetos de melhorias nos serviços ou estratégia corporativa.

8 Grupo de Função Suporte Tipo de Solicitação para Mudança Mudanças que permitam a resolução de incidentes e problemas para o sistema de help desk. Além dos grupos de funções, outros grupos que não sejam operacionais podem enviar uma RFC (por exemplo, um grupo de produção gráfica), embora também possam trabalhar em conjunto com uma função específica do MOF para iniciar uma solicitação de alterações. A análise pode ser controlada em formatos diferentes, dependendo do tipo de mudança que tenha sido aprovada ou enviada. O tipo de análise selecionada também pode ser afetado pelo tamanho do grupo criado e os locais geográficos dos membros. Selecionando um Líder da Equipe de Análise O líder da equipe para este OMR é geralmente o gerente ou representante do gerenciamento de mudanças, selecionado pelo gerente ou CAB. Outra opção é selecionar um líder da área funcional ou grupo de função para a solução proposta. Por exemplo, um representante da segurança poderia ser um líder adequado para uma RFC centralizada na segurança, uma vez que ele teria conhecimento profundo da mudança e seus requisitos, políticas e padrões em uso. O líder conduz o processo de Alterações a uma decisão de sim ou não. No caso das alterações padrões ou menores, se o gerente for o analista líder, ele pode apenas autorizar a mudança sob os critérios definidos no processo de gerenciamento da mudança. O líder selecionado é responsável por controlar as atividades do planejamento, liderando a Alterações, incluindo a definição de parâmetros para a análise, desenvolvimento da programação e comunicação dos detalhes em reuniões. O líder analista também convida os participantes, incluindo o iniciador da mudança, o proprietário e os membros do CAB. Se a análise começar a tomar o formato de um CAB, um comitê emergencial de CAB ou uma reunião do quadro de TI, então as atividades preparatórias devem incluir os requisitos descritos no processo de gerenciamento para esses métodos de aprovação. O CAB deve conter, no mínimo, um membro de cada grupo de função definido no Modelo de Equipe do MOF. O CAB possui diversos membros que sempre participam (ou que o substituem na sua ausência) e analisam todas as RFCs enviadas. Além desses membros regulares, o CAB deve incluir uma equipe e especialistas, vindos de departamentos afetados pela mudança, ou que possam agregar valor na discussão da mudança. Esses membros adicionais são selecionados dependendo do caso. O processo de selecionar membros de equipe de análise pode ser simplificado ao se elaborar uma lista de membros do CAB para cada tipo de mudança por exemplo, mudança na infra-estrutura de rede, nas dependências, novas aplicações, novos dados, conserto/atualização de sistema operacional e etc. Para cada mudança analisada, os membros do CAB podem ser selecionados a partir da lista fixa e das opcionais. Os indivíduos podem ser adicionados ou removidos de acordo com o necessário. O número total de membros do CAB ainda deve ser limitado para tornar as reuniões mais eficientes e gerenciáveis. Como regra geral, as atividades da análise são as seguintes. Líder da Equipe Define Parâmetros da Análise Os parâmetros básicos de análise incluem membros da equipe, número de RFC, detalhes da mudança, data da análise, hora, local, tecnologia e escopo da análise. (Um modelo de Definição de Alterações é fornecido no Apêndice B: Modelo de Alterações. ) O líder seleciona os membros da equipe de análise. Eles podem ser representantes de grupos de funções selecionados no Modelo de Equipe do MOF, ou representantes de equipes de desenvolvimento e testes, o cliente e os usuários finais da mudança ou solução proposta. Para que a Alterações seja efetiva, é fundamental que os membros tenham o conhecimento e a autoridade de tomar decisões sobre a adequação do RFC, sendo capazes de se comprometer com qualquer ação de suas áreas funcionais do grupo de trabalho. No

9 caso de fornecedores de serviços de TI emergentes, como provedores de serviços de aplicação (ASPs -application service providers) e fornecedores de business-to-business (B2Bs), um cliente real não deve ser acessível; neste caso, o líder é responsável por garantir que um advogado do cliente seja introduzido para representar seu ponto de vista. Durante este passo, o líder da Alterações: Define a data, a hora, a origem e a extensão da reunião da Alterações. O CAB geralmente se reúne quase que mensalmente. Os membros fixos sempre comparecem ou mandam um substituto, que está autorizado a tomar decisões em seu lugar. Quando a autorização para a iniciação precisa ser apressada, o gerente ou CAB/EC pode autorizar. Encontre mais informações sobre o SMF de Gerenciamento de Alterações em A duração da reunião depende da origem e complexidade das mudanças a serem discutidas. Por exemplo, a Alterações para uma mudança padrão ou menor pode nem exigir uma reunião. O gerente e o iniciador podem confirmar este tipo de mudança, uma vez que o iniciador tenha reunido as informações corretas no formulário do RFC. As mudanças maiores, mais complexas e de alto impacto podem exigir maiores discussões do material enviado. Lembre-se de que, ao programar uma Alterações, as mudanças maiores geralmente exigem comparecimento e autorização pelos tomadores de decisões de mais alto nível ou analistas de orçamentos, cujas agendas são geralmente mais fáceis de acomodar. O gerente de mudanças deve poder escalar qualquer problema ao garantir a adequação das pessoas envolvidas. Seleciona e reserva a tecnologia e o local da reunião, como os locais físicos, vídeo-conferência, Microsoft NetMeeting, tele-conferência ou todos os recursos em conjunto. O líder também obtém os equipamentos e recursos para a reunião, como um sistema de projeção de PC e quadros negros. Comunica a lógica de aprovação para conseguir a aprovação de mudança. Isso requer aprovação unânime para cada participante; essa lógica deve ser definida antes da reunião. Mais informações sobre a lógica de votação estão contidas na seção de Análise de Conduta, mais adiante neste documento, e no SMF de Gerenciamento de Alterações em Define o escopo da análise, que ajuda a equipe a se concentrar no produto. O escopo da análise depende do escopo da mudança, que inclui: Funcionalidade. A funcionalidade fornecida pela mudança. Geografia. Os locais físicos afetados pela mudança. Infra-estrutura. A infra-estrutura afetada pela mudança. Organização. As partes da organização afetadas pela mudança. O líder deve analisar o log de alterações para as mudanças semelhantes que possam ter sido aprovadas antes. Por todo o ciclo de vida da mudança, pela iniciação até o desenvolvimento e culminação na implantação, todos os envolvidos na mudança (sendo ou não parte da equipe) devem analisar o log para garantir que: Identifiquem e gerenciem os riscos encontrados em mudanças semelhantes. Repitam as práticas descobertas em associação com as alterações anteriores; essas melhores práticas são geralmente adicionadas aos padrões e políticas gerenciadas pela engenharia de infra-estrutura. Evitem erros repetidos em associação com as mudanças anteriores. Líder da Equipe Define Programação da Análise Uma programação escrita geralmente melhora a efetividade de uma reunião; isso é verdade na reunião da Análise de Iniciação de Alterações, principalmente se houver mais de um RFC para ser discutido ou autorizado. Comunicar

10 a programação de maneira antecipada ajuda os participantes a se preparar para a reunião, permitindo discussões otimizadas durante a análise. Embora pareça óbvio, é importante que todos os participantes entendam claramente suas funções, assim como a de todas as pessoas. Além disso, o facilitador da tarefa geralmente o gerente é ajudado se outros por exemplo, o administrador de mudanças agir como controlador do tempo. Líder da Equipe Anuncia Detalhes da Reunião O anúncio da reunião de análise contém detalhes que geralmente incluem: Uma definição que descreva os parâmetros básicos que o líder definiu anteriormente, como os participantes, dados da análise, hora, local e escopo. Formato de reunião previamente selecionado. Como alternativa para as reuniões cara a cara, as reuniões de CAB podem ser controladas usando a tecnologia NetMeeting ou chamadas de conferência telefônica. Links para o log de mudança para todos os RFCs a serem analisados. A ordem em que os RFCs serão analisados (agenda). Os membros do CAB podem estar interessados apenas em uma quantidade pequena de mudanças propostas, reunindo-se apenas se for necessário realmente. Regras e diretrizes importantes para a reunião. Modelos de pré-projeto para cada função na análise. Uma cópia da programação para planejamento e discussão. Conforme mencionado, os modelos para todos esses itens estão incluídos no Apêndice B: Modelos de Análise de Iniciação de Alterações. Nota A notificação de reunião deve ser enviada aos participantes com bastante antecedência, para permitir que eles analisem o RFC antes da reunião. Ao marcar uma reunião, a equipe de análise deve considerar um contexto maior. Por exemplo, essa pode ser uma excelente oportunidade para estabelecer novas relações, reparar outras que foram perdidas ou reconhecer um objetivo. Sugestões para usar as reuniões de OMR para concluir mais de um objetivo estão contidas no Apêndice C: O Efeito do Contexto Corporativo. Prepare-se para a Análise Iniciador da Mudança No mínimo, ao criar um RFC para a Alterações, o iniciador deve recorrer ao Apêndice B: Modelos da Alterações e concluir a Solicitação para o modelo de Mudança da forma mais clara possível. A fim de levar em consideração os dados mais relevantes durante a análise, é importante que todos os membros da equipe de Alterações recebam essas informações no link para mudar o log nos detalhes antes da análise. Embora novas informações ou itens adicionais possam afetar a decisão final de um membro da equipe, essa preparação é essencial para uma reunião de análise efetiva. As informações apresentadas pelo iniciador, além daquelas preparadas por outros participantes, serão a base sobre a qual as decisões serão tomadas. Participantes Os participantes no processo de análise devem se preparar para comentar ou mudar a iniciação com informações específicas a partir de cada uma das suas respectivas áreas funcionais. Essas informações devem incluir perguntas e comentários sobre detalhes específicos da mudança, políticas e padrões de infra-estrutura aplicáveis, casos de negócios, justificativas de custo, análise de impacto, itens afetados de configuração (CIs) e requisitos de operações e suporte. Se for necessário um CAB, cada membro deve preparar uma recomendação para discutir na Análise de Iniciação de Alterações.

11 Cada membro da equipe de análise também completa o modelo para a área funcional requerida. Ou o membro da equipe pode consultar as informações do RFC e levar em conta onde mais esclarecimentos são necessários antes de a mudança ser autorizada. (Veja a Solicitação para Mudança no Apêndice B: Modelos da Análise de Iniciação de Alterações. ) Os modelos fornecem uma estrutura para determinar se: A mudança é economicamente viável e tem justificativa corporativa. Os detalhes da mudança e os planos são abrangentes e completos. O ambiente de produção (organização e infra-estrutura) é capaz de receber, suportar e operar a mudança. Os membros da equipe preenchem o modelo, incluindo suas razões para autorizar ou rejeitar a mudança, assim como sua decisão preliminar na autorização. Para concluir, eles devem reunir evidências para dar suporte à decisão. A tabela que segue relaciona alguns dos possíveis exemplos. Tabela 3. Indicadores de Sim ou Não Elemento Indicadores Sim Indicadores Não Mudança A mudança é importante para os negócios. A mudança é um requisito legal. A mudança exigirá serviço aprimorado. A mudança é apropriada. A mudança não está de acordo com a estratégia. Não há casos de negócios. Custo/benefício não está adequadamente preparado. A mudança não é apropriada. Ambiente de infra-estrutura A mudança se alinha com os padrões e políticas estabelecidos. A mudança se alinha com a estratégia de infra-estrutura atual. Os membros da equipe são especializados na tecnologia da solução. Padrões e políticas estabelecidos e não considerados. Software sugerido para a solução não é suportado (muito novo, muito antigo) no ambiente atual. Não há planejamento para treinamento da equipe de suporte. CMDB Análise de impacto indica implantação de mudança gerenciável. Serviços críticos afetados são gerenciados para o risco. Análise de impacto inadequada. A mudança não afetará muitos sistemas importantes.

12 Análise de Conduta O líder (novamente, geralmente o gerente) facilita a reunião da Alterações com assistência do controlador de tempo, muito provavelmente o administrador da mudança. Para cada RFC analisado na Análise de Iniciação de Alterações, o gerente deve garantir que o quorum exigido de eleitores esteja presente na reunião. Ou seja, todos os eleitores (ou substitutos) e o número mínimo de eleitores deve estar presente, conforme definido pela lógica de votação para cada tipo de RFC em questão. Se não houver acionistas suficientes para validar a votação, o gerente deve remarcar a análise, e o RFC é colocado como em estado pendente até então. A análise pode ser adiada para a próxima reunião, se o tempo permitir. Se não (por exemplo, se a mudança deve ser iniciada antes da próxima reunião), o gerente deve organizar uma reunião extra para analisar o RFC e então aumentar sua prioridade. Os iniciadores de mudanças estão geralmente presentes na sessão da Alterações que considera a autorização de sua mudança proposta. Pode-se pedir que eles obtenham mais informações e reapresentem o RFC. Ou informações adicionais de suporte podem ser exigidas por outros membros da equipe da Alterações. Por exemplo, informações mais detalhadas sobre as implicações de segurança da mudança podem ser necessárias pelo gerente de segurança, ou detalhes sobre um impacto maior nos níveis de serviço podem ser exigidos pelo gerente de segurança. O CAB então marca uma nova reunião para analisar a nova evidência e coloca o RFC em estado pendente, enquanto as informações estão sendo obtidas. O gerente atualiza o log de mudanças com a solicitação de mais informações e a data e hora da próxima análise. O CAB também pode fazer alterações no RFC. Como os iniciadores devem concordar com quaisquer alterações, sua presença na reunião irá acelerar a decisão sobre o RFC quanto a esse assunto. Durante a análise, cada membro da equipe precisa apresentar sua decisão, a razão por trás dela e quaisquer assuntos a serem resolvidos nas seguintes áreas: O impacto que a mudança terá na operação corporativa. O efeito sobre a infra-estrutura e serviços ao cliente, como definido no acordo de nível de serviço (SLA) e sobre a capacidade e desempenho, confiabilidade e resiliência, recursos, planos de contingência e segurança. Os padrões e políticas na infra-estrutura afetada. Quaisquer requisitos orçamentários. A necessidade corporativa e justificativa de custo da mudança. O impacto em outros serviços executados na mesma infra-estrutura (ou em projetos de desenvolvimento de software). O impacto em infra-estruturas que não são de TI dentro da organização por exemplo, segurança, serviços administrativos, transporte e help desks que servem como clientes corporativos. As conseqüências em não se implementar a mudança. Os recursos corporativos de TI e outros recursos requeridos para implementar a mudança, incluindo os custos prováveis, o número de disponibilidade de pessoas necessárias, o tempo a ser gasto e os novos componentes de infra-estrutura. Recursos contínuos adicionais requeridos caso a mudança seja implementada. Com base nessas análises e benefícios potenciais da mudança, cada um dos membros de Alterações deve poder decidir se aprova a mudança iniciada para desenvolvimento e implantação eventual. Decisão Geral Sim/Não O processo da Alterações deve ser baseado na mesma lógica de aprovação pré-definida usada pelo CAB para aprovar mudanças.

13 O gerente de mudanças pré-determina se a lógica padrão está adequada e se uma lógica diferente ou adicional deve ser aplicada. A pessoa nesta função informa os membros sobre a lógica antes da reunião. A Tabela 4 oferece uma visão geral das abordagens de votação. Tabela 4. Tipos de Lógica de Aprovação Tipo de Lógica de Aprovação Unânime Maioridade Abstenções Vetadores Quorum/eleitores exigidos Descrição Todos os participantes votam em Sim para a aprovação. Uma grande maioria ou porcentagem pré-definida de participantes devem votar em Sim para a aprovação. Um participante deve se abster devido à falta de impacto da mudança em sua área de responsabilidade. Um participante pode ter a capacidade de dizer Não, resultando na rejeição da mudança. Por exemplo, o membro da segurança pode vetar uma mudança de impacto potencial no Domain Name System (DNS) ou em um firewall. Define um número mínimo de pessoas para formar um quorum ou porcentagem mínima de votos requeridos para constituir o status da maioria. Encontre mais informações sobre a lógica de votação do CAB no manual do MOF Change Management Service Management Function, disponível em Uma vez que a votação tenha sido concluída para o RFC em análise e a mudança está pronta para proceder, pode-se entrar na fase de desenvolvimento. Se os membros da equipe votaram na não aprovação da mudança, mais trabalho ou retrabalho poderá ser necessário para satisfazer os requisitos do participante referido ou grupo, a fim de que a mudança seja reenviada. Os ajustes são itens de ação comprometidos. Se forem necessários itens de ação, cada um deve incluir: Uma descrição da ação. O proprietário da ação. O prazo para conclusão. Os critérios de conclusão. Possíveis itens de ação incluem: Mais planejamento requerido. Documentação adicional. O timing deve ser cumprido. As políticas de infra-estrutura devem ser seguidas e o planejamento deve ser modificado. As políticas de infra-estrutura devem ser seguidas e o planejamento deve ser modificado. Se os itens de ação exigirem mais mudanças ao RFC ou ambiente de TI, é importante usar o processo formal de gerenciamento de mudanças da organização e atualizar o log de mudanças. Acompanhamento da Análise Depois que a reunião da Alterações tiver sido feita, o gerente de mudanças circula os minutos detalhados e a programação atualizada a todos os membros. Links para os RFCs aprovados e o log de mudança também são fornecidos, com um prazo para análise e comentários, geralmente antes de a próxima Alterações ou CAB ser agendada. Os membros da equipe analisam esses minutos e,

14 quando apropriado, enviam comentários de volta ao gerente. Um modelo de Minutos de Reunião da Análise de Iniciação de Alterações é fornecido no Apêndice B: Modelos da Alterações. Uma vez que a decisão de Sim ou Não tenha sido tomada, o gerente a comunica, incluindo qualquer requisito dos itens de ação, a todos os acionistas do RFC. Eles então incluem os membros da análise e os representantes do cliente e comunidade de usuários, divulgando que o RFC começará a vigorar. Essa comunicação deve incluir: A decisão final (sim ou não). Se a mudança é aprovada, confirmar a conclusão de qualquer ajuste ao RFC e estrutura de tempo para a conclusão do desenvolvimento e versão. Se a mudança não é aprovada, descrever em detalhes as razões da rejeição, juntamente com os passos seguintes (como planos para ajustes, datas revisadas e etc). O líder da equipe da Alterações seleciona o modo de comunicação como , reuniões presenciais ou por telefone que é mais efetivo para uma organização e para o cliente e comunidades de usuários. Para permitir que todos os acionistas tenham a chance de prosseguir, o líder comunica a decisão com antecedência à data de implantação. No caso de uma rejeição, o líder comunica a decisão logo que ela estiver finalizada. No caso de uma aprovação, a comunicação inclui, no mínimo, um resumo de: Alterações a serem feitas, quando e por quê. Os riscos envolvidos e o que se está fazendo para reduzi-los. A função do destinatário quando a mudança acontecer, por exemplo, aprovação de planos e elaboração. Geralmente se considera uma das melhores práticas o envio de duas versões de comunicações: uma para usuários e clientes e outra para a equipe de TI. Esta forma de comunicação pode ser criada para o público alvo ter a garantia de uma comunicação segura. Uma comunicação modelo de ao pessoal de TI é fornecida no Apêndice B: Modelos da Alterações. O líder também é responsável por coordenar a conclusão de qualquer item de ação resultante da reunião de Alterações. Isso inclui a decisão de como proceder se os itens de ação são concluídos ou não satisfazem os critérios de conclusão. Próximos Passos Conforme estabelecido, se a análise resultar em uma decisão para aprovação da mudança, vai-se para a fase de desenvolvimento, cuja extensão depende da origem do RFC.

15 Apêndices Apêndice A: Matriz de Funções da Equipe da Alterações A tabela que segue estabelece cada responsabilidade da função da equipe durante a Alterações. Cada linha representa uma função, e, dentro dela, as responsabilidades são organizadas por prétrabalho e contribuição com a Alterações. Grupo de Funções do Modelo de Equipe Equipe de Análise (líder) Responsabilidades Pré-trabalho Analisar as lições que os líderes anteriores aprenderam nas outras reuniões de Alterações. Definir escopo, parâmetros e agenda da análise. Comunicar os detalhes da reunião aos membros da equipe. Alterações Facilitar a análise. Ter conhecimento e autoridade para tomar decisões com relação à mudança (e autorizar as mudanças menores e padrões). Fornecer compromisso com os itens de ação para a área funcional que ele representa. Segurança Rede de Proteção à Propriedade Intelectual e Detecção de Intrusão na Segurança Proteção contra Vírus Auditoria e Conformidade Administração Planejamento de Contingência Pré-trabalho Analisar as mudanças em termos de requisitos de segurança, padrões e políticas para a infra-estrutura ou serviço afetado. Alterações Garantir que toda a documentação relativa à função da segurança esteja adequada. Garantir que os planos de mudanças incluam o alinhamento aos padrões de segurança da organização, políticas e procedimentos. Versão Gerenciamento de Alterações Engenharia de Mudanças/Sistemas Gerenciamento de Configuração Licenciamento/Distribuição de Software Controle de Qualidade Ligação entre Desenvolvimento de Mudanças/MSF Pré-trabalho Analisar os RFCs considerados na Alterações para conformidade com a versão. Garantir análise de impacto concluída. Alterações Garantir que o RFC será projetado de acordo com os padrões, políticas e procedimentos da organização. Por exemplo, no caso de migração dos componentes do software, do desenvolvimento para a operação, a segurança de migração definitiva da biblioteca

16 Grupo de Funções do Modelo de Equipe Responsabilidades de software (DSL) e os padrões devem ser implementados. Fornecer a documentação sobre planejamento para elaboração, versão, funcionalidade e configuração do RFC. Fornecer a documentação dos requisitos de RFC para planejamento, suporte e operações. Aplicar lições de mudanças anteriores na Alterações para aplicação aos RFCs atuais sob análise. Serviço Service Desk Gerenciamento de Nível de Serviço Pré-trabalho Assegurar que o RFC esteja de acordo com padrões, políticas e procedimentos para as áreas da equipe de serviço da responsabilidade. Alterações Confirmar que os planos para o RFC incluem o nível de serviço exigido para o serviço afetado. Garantir a aceitação da mudança para a Alterações a partir de uma perspectiva comercial. Suporte Service Desk/Help Desk Gerenciamento de Incidentes Suporte ao Produto/Produção Gerenciamento de Problemas Gerenciamento de Nível de Serviço Pré-trabalho Analisar os requisitos de suporte do RFC enviado para aprovação. Alterações Garantir a aceitação dos planos de suporte para o RFC. Garantir que os documentos de problemas referenciados no RFC estejam disponíveis. Garantir que os padrões e políticas para suportabilidade da solução proposta estejam aplicados. Infra-estrutura Arquitetura Empresarial Engenharia de Infra-estrutura Gerenciamento de Capacidade Gerenciamento de Custo/TI Planejamento de Recursos e Prazos Longos Pré-trabalho Analisar os RFCs para aprovação; confirmar os componentes da infra-estrutura afetada e as políticas e padrões exigidos. Alterações Fornecer provas de que os planos incluem escolhas estratégicas para que os componentes de infra-estrutura sejam alterados. Fornecer provas de que os planos estipulam que o RFC satisfaça os requisitos existentes de padrões e políticas do ambiente de infra-

17 Grupo de Funções do Modelo de Equipe Responsabilidades estrutura. Garantir que as exceções que chegam à Alterações seguem o processo de engenharia de infra-estrutura para exceções. Operações Monitoramento e Controle do Serviço Administração dos Serviços de Diretório Gerenciamento de Disponibilidade Operações de Mensagens Operações de Banco de Dados Administração de Rede Gerenciamento de Armazenamento Gerenciamento de Disponibilidade Agendamento de Tarefas Gerenciamento de Impressão/Saída Parceiro Fornecedores de Manutenção Suporte ao Ambiente Serviços Gerenciados, Terceirizados, Parceiros e Fornecedores de Software e Hardware Pré-trabalho Garantir que os RFCs a ser analisados permitam a operabilidade da solução alterada. Alterações Garantir que todo o planejamento para o RFC inclua operabilidade e planos para o serviço afetado (como a capacidade e administração). Esses planos devem estar alinhados com as políticas e padrões das operações. Pré-trabalho Analisar os RFCs para aprovação em alinhamento com as políticas, procedimentos e padrões dos parceiros. Alterações Garantir que toda a documentação requerida do parceiro, procedimentos, contatos e caminhos de escalação para a mudança estejam no planejamento. Garantir que todos os parceiros externos necessários para a mudança sejam reconhecidos e estratégicos, ou que se enquadrem na política de exceções. Garantir que o plano de mudança analise a necessidade de recursos de parceria adicionais para desempenhar tarefas específicas.

18 Apêndice B: Modelos da Alterações Os modelos a seguir fornecem assistência na condução de cada um dos quatro passos da Alterações. Planejar Reunião de Análise Lista de Verificação de Iniciação de Alterações Esta lista de verificação descreve, em alto nível, os itens a serem considerados para garantir que as informações adequadas estejam disponíveis para autorizar a mudança para mais investimento: Nome do iniciador da mudança, posição e informações de contato. Razão para a mudança. Nome do proprietário da mudança, posição e informações de contato. Descrição da mudança ou seja, uma descrição completa da origem da mudança. Descrição e identidade dos itens a serem modificados, incluindo a identificação dos itens de configuração (CIs configuration items). A prioridade e categoria da mudança com base nas informações disponíveis. Número do relatório de problemas (PR problem report) de qualquer problema que se relacione com a mudança, ou números de incidentes. Quaisquer políticas ou padrões de infra-estrutura existentes para os CIs afetados. Uma análise de custo/benefício da mudança e aprovação orçamentária, se necessário. Implicações da não implementação da mudança, incluindo qualquer acordo de nível de serviço (SLA) que seja um risco. Análise de impacto e recursos ou seja, que usuários serão afetados e quão intenso será este impacto. Local de versão e um plano de implementação sugerido com as estruturas de tempo. Plano de retorno incluindo gatilhos e detalhes de contato do tomador de decisões. Impacto na continuidade dos negócios e planos de contingência. Risco envolvido ao se fazer a mudança.

19 Modelo de Definição da Alterações Prepare-se para a Análise Anúncio da Reunião da Alterações Segue um exemplo de mensagem usada como convite e instrução para os membros da equipe da Análise de Iniciação de Alterações. Joe: Você foi selecionado a representar o Grupo de Função de Suporte, na reunião de Alterações, da Contoso Ltd., mudança de software, RFC: A reunião está marcada para 28 de Fevereiro, a partir das 9h até o período da tarde, na Sala de Conferência 10. A finalidade desta reunião é analisar as mudanças detalhadas no cronograma de mudanças abaixo. RFC Detalhes Iniciador Prioridade Categoria Data Implementação Planejada Mudança de software da Contoso Ltd.e Consolidação do servidor de Novo protetor de tela de PC corporativo Jeff Hay Alta Principal Adam Barr Média Principal Doris Hartwig Média Principal

20 RFC Detalhes Iniciador Prioridade Categoria Data Implementação Planejada Patch de Segurança # Atualização para o banco de dados do CRM Liz Keyser Alta Principal Paul Singh Baixa Significante Em anexo a esta mensagem, há três itens: Uma cópia da agenda para a reunião de análise. Um modelo de pré-trabalho para a sua função. Instruções para uma chamada telefônica para uma reunião (caso você não possa ir pessoalmente). Use este pré-trabalho como um guia na preparação da análise. Isso descreve as informações e evidências para as quais você deve se preparar para a análise. Confirme a sua participação o mais rápido possível. Notifique-me se houver conflitos de horário para que eu possa coordenar as mudanças adequadamente. Agradeço a sua participação, e favor entre em contato comigo se houver perguntas. Chris Gerente de Mudanças

21 Solicitação para o Modelo de Mudança Versão do Documento: Modelo Qualquer iniciador de mudanças que deseja que uma modificação seja feita a uma parte da infra-estrutura de TI começa o processo de iniciação, concluindo este RFC. Nenhuma alteração será feita sem um documento de RFC totalmente preenchido e autorizado. Os documentos de RFC incompletos serão imediatamente REJEITADOS pela função de gerenciamento de mudança. Agenda de Reunião da Alterações Reunião de Alterações Data da Reunião Horário da Reunião

22 Reunião de Alterações Local da Reunião Líder da Equipe de Análise/Facilitador Participantes da Reunião Controlador de Minutos Cronômetro Modelos de Pré-trabalho da Alterações Os modelos que seguem devem ser distribuídos aos participantes de cada grupo de função. Os participantes devem capturar as informações relevantes para cada mudança enviada à Alterações em termos da sua área de conhecimento. Os exemplos de dados estão incluídos em itálico.

23 Serviço Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Representantes corporativos que patrocinam e lançam o desenvolvimento da mudança # Atributos físicos da área afetada, tal como o prédio Equipe afetada Área comercial afetada Gerenciamento de Nível de Serviço # Irá afetar o SLA para o serviço de Pode gerar problemas para áreas em que o é fundamental, como o serviço de atendimento ao cliente. Service Desk # Irá impactar potencialmente as novas alterações de senhas dos e- mails A mudança sugerida é controlada até que a alteração de senha seja integrada na organização para prevenir picos de chamadas desnecessários e degradação no serviço Infra-estrutura Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Arquitetura Empresarial Engenharia de Infraestrutura Gerenciamento de Capacidade Gerenciamento de Custo/Orçamento de TI Gerenciamento de Dados Compartilhados Planejamento de Recursos e Prazos Longos Gerenciamento do Centro de Dados Gerenciamento de

24 Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Ambientes Físicos e Ferramentas de Infraestrutura Padrões de Hardware/Software Suporte Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Service Desk/ Help Desk Gerenciamento de Incidentes Suporte à Produção/Produto Gerenciamento de Problemas Gerenciamento de Nível de Serviço Suporte ao Cliente Gerenciamento da Força de Trabalho Operações Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Operações de Mensagens Operações de Banco de Dados Administração de Rede Monitoramento/Métricas Gerenciamento de Disponibilidade Administração de Sistema

25 Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Administração dos Serviços de Diretório Administração de Segurança Falhas e Recuperação Gerenciamento da Força de Trabalho Parceiro Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Fornecedores de Manutenção Suporte ao Ambiente Fornecedores de Serviço Serviços Gerenciados, Terceirização, Parceiros Comerciais Fornecedores de Software/Hardware Segurança Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Proteção à Propriedade Intelectual Segurança da Rede e do Sistema Detecção de Intrusos Proteção contra Vírus Administração de Auditoria e Conformidade Planejamento de

26 Função do Processo de Desenvolvimento Alterações (Mudança) Alterações (Infraestrutura) Alterações (Organização) Contingência Minutos de Reunião da Alterações Reunião de Alterações Data da Reunião Hora da Reunião Local da Reunião Líder da Equipe de Análise/Facilitador Participantes da Reunião Controlador de Minutos Cronômetro

27 Itens de Ação desta Reunião Área Funcional Número do RFC Itens de Ação Data de Conclusão Definida Proprietário Critérios de Conclusão Infra-estrutura Versão Operações Parceiro Serviço Suporte Segurança Análise de Conduta A fase de Análise de Conduta utiliza os modelos das duas fases de análise anteriores: Reunião de Análise de Planejamento e Preparação para a Análise. Análise de Planejamento Com exceção do modelo de Comunicação apresentado aqui, a Análise do Acompanhamento utiliza os modelos das três fases anteriores: Reunião de Análise do Planejamento, Preparação para a Análise e Análise de Conduta.

28 Modelo de Comunicações Prezado Acionista: Essa mensagem é para informá-lo que o novo sistema de software da Contoso Ltd., número de RFC ***** foi aprovado para desenvolvimento de mudança. A equipe de Alterações recentemente concluiu a análise para esta mudança e todos os membros a certificaram como preparada para desenvolvimento em preparação da mudança ao ambiente de produção. O sistema de software da Contoso Ltd. foi selecionado para aprimorar a forma como nossa força de vendas gerencia as relações com clientes. Ele se integra facilmente com nossas configurações padrões existentes e utiliza a infra-estrutura existente para alcançar seus objetivos. Os planos de desenvolvimento de mudanças estão sendo finalizados. Os membros das equipes de mudança e configuração estão trabalhando com os intermediários dos departamentos a fim de garantir que possam minimizar qualquer efeito negativo aos serviços disponíveis, e que otimizem a funcionalidade, desempenho, suporte e operação da mudança de software. Quando esses planos forem finalizados, um planejamento formalizado e uma agenda de versão serão comunicados ao senhor e aos nossos usuários. As agendas de treinamento também estão sendo criadas a fim de que nossos usuários estejam preparados para tirar vantagem das melhorias fornecidas por esta mudança. A implementação está programada para iniciar na primeira semana de Maio e prosseguir até Junho. Iremos aguardá-lo para ajudar a comunicar as agendas finais e suportar a aceitação desta mudança na função corporativa. Favor enviar perguntas ao nosso endereço ContosoChangeTeam@XYZ <mailto:contosochangeteam@xyz> e um membro de nossa equipe irá responder ao senhor dentro de um dia útil. Agradecemos seu apoio. Esperamos trabalhar com o senhor para fornecer aos nossos usuários uma mudança que atenda as suas necessidades. Gerente de Mudanças Equipe de Alterações

29 Apêndice C: O Efeito do Contexto Corporativo A Alterações muda de posição dependendo do contexto dentro do qual está sendo conduzida, assim como o tamanho e a complexidade da alteração no ambiente de TI. As diferenças podem ser rigorosas, principalmente entre a TI emergente por exemplo, o provedor de serviço de aplicações (ASP) e business-to-business (B2B) e ambientes tradicionais corporativos. Isso se deve às diferenças nos contextos corporativos, que estão resumidas na tabela que segue. Contexto Corporativo TI Emergente TI Tradicional Local da Mudança Inter-empresarial Intra-empresarial Cliente Cliente final Cliente interno Prazos Contrato Acordo Tipo de Mercado Terceirizado, mercado, alternativas Interno, monopólio, vinculado Conteúdo de TI Relativo de Produtos Superior Inferior Dependência Relativa dos Negócios na TI Superior Inferior As mudanças nos ambientes emergentes de TI são geralmente de serviços fornecidos de negócios, enquanto as mudanças nos ambientes tradicionais de TI são geralmente de serviços fornecidos aos clientes dentro dos negócios. Sendo assim, a origem das mudanças e suas Análises de Iniciação de Alterações podem diferir. Dentro de cada ambiente, o escopo da análise pode variar amplamente, uma vez que cada ambiente pode implantar uma mescla variada de mudanças grandes e pequenas. Nos ambientes emergenciais, as mudanças podem variar totalmente as novas aplicações e serviços para atualizações sofisticadas em recursos e funcionalidades. Nos ambientes tradicionais, as alterações podem variar de soluções empresariais, como uma atualização do sistema operacional ou planejamento de recursos empresariais (ERP) até a implementação de aplicações localizadas de linha de negócios (LOB). A Alterações e o processo de autorização associado trabalham com a mudança sob análise, sua categoria e prioridade. Para mais informações sobre como determinar uma categoria de mudanças e a prioridade, veja o manual do MOF Change Management Service Management Function, disponível em Há geralmente mais riscos nos negócios com as mudanças em ambientes de TI emergentes. Essas mudanças envolvem comprometimentos com consumidores finais; as mudanças são raramente flexíveis e têm conseqüências financeiras diretas negativas caso não sejam obtidas. Esses clientes tendem a ter menos paciência com os problemas de serviço, uma vez que há muitas opções no mercado. A Alterações é importante uma vez que define logo o processo de custo/benefício da mudança nesses ambientes e assegura que a comunicação, compras e aprovação de orçamento sejam obtidas dos acionistas. Grandes mudanças em ambientes tradicionais podem ser extremamente complexas, principalmente em casos em que os clientes e usuários são distribuídos entre diferentes unidades corporativas pelo mundo todo. As questões logísticas, culturais e políticas geralmente criam desafios adicionais. A Alterações, nestes casos, é geralmente mais difícil de se gerenciar e acaba tendo repercussões organizacionais mais intensas. Elas geralmente trazem um grupo diverso de pessoas e são excelentes oportunidades para preencher lacunas e solidificar relações.