8 Change Management

8.1 Goal of Change Management

As mudanças surgem em conseqüência dos problemas, mas muitas mudanças podem vir dos benefícios procurando a proatividade do negócio tais como reduzir custos ou melhorar serviços. O objetivo do processo da gerência da mudança é assegurar-se de que os métodos e os procedimentos padronizados estejam sendo usados para a manipulação eficiente e alerta de todas as mudanças, a fim minimizar o impacto de incidentes Mud-relacionados em cima da qualidade do serviço, e melhorar conseqüentemente as operações cotidianas da organização. Fazer uma resposta apropriada a um pedido da mudança envolve uma aproximação considerada à avaliação da continuidade do risco e do negócio, do impacto da mudança, das exigências de recurso e da aprovação da mudança. Isto aproximação considerada é essencial manter um contrapeso apropriado entre a necessidade para a mudança de encontro ao impacto da mudança. É particularmente importante que os processos da gerência da mudança têm a visibilidade elevada e as canaletas abertas de uma comunicação a fim promover transições lisas quando as mudanças ocorrem.

8.1.1 Purpose (Finalidade)

A finalidade deste capítulo é fornecer a informação em como estabelecer um processo da gerência da mudança, including os procedimentos, as ferramentas e as dependências que seja necessário para planear para, executar e funcionar a gerência da mudança. O capítulo descreve também os benefícios que as organizações podem esperar receber.

8.1.2 Best practice

A definição da mais melhor prática na área de gerência da mudança é inevitàvel controversa; , entretanto, aceita-se geralmente que a gerência da gerência e da configuração da mudança melhor está planeada e executada simultaneamente. Executar a gerência da mudança e da configuração permite simultaneamente que a organização pese os riscos de não executar um ou outro processo corretamente nos estágios de planeamento.

8.1.3 Program/project management and Change Management

A fim poder definir limites desobstruídos, as dependências e as réguas, mudam a gerência devem ser integradas com os processos usados controlar programas ou projetos organisational muito grandes. Um exemplo de como os processos poderiam ser integrados é mostrado em figura 8.1.

Figure 8.1 – Boundaries between Change Management and program managementClick here to view a larger version in a new browser window.

8.2 Scope of Change Management

A gerência da mudança é responsável para controlar o envolvimento dos processos da mudança: o · vivo do software de aplicações do ` do · do equipamento de comunicações do · da ferragem do · e do software de sistema do · do software ' toda a documentação e procedimentos associou com o corredor, a sustentação e a manutenção de sistemas vivos. Isto significa que as mudanças a nenhuns componentes que estiverem sob o controle de um projeto do desenvolvimento das aplicações - para o exemplo, o software de aplicações, a documentação ou os procedimentos - não vêm sob a gerência da mudança mas seria sujeito aos procedimentos da gerência da mudança do projeto. A equipe da gerência da mudança, entretanto, esperar-se-á liaise pròxima com os gerentes de projeto da gerência de aplicação para assegurar a execução e a consistência lisas dentro dos ambientes em mudança da gerência. É o processo da gerência da mudança que produz a aprovaçã0 (ou de outra maneira), para toda a mudança proposta. Quando a gerência da mudança fizer o processo acontecer, a autoridade da decisão é a placa consultiva da mudança (CAB), que é compensada a maioria de parte dos povos de outras funções dentro da organização. Anote também que é a gerência da configuração que é responsável para se assegurar de que a informação a respeito das implicações possíveis de uma mudança proposta esteja feita disponível, e que estes impactos possíveis estão detectados e apresentados apropriadamente. Haverá umas ocasiões quando uma mudança proposta do infrastructure terá potencial um impacto mais largo em cima de outras partes da organização (por exemplo projetos do desenvolvimento das aplicações ou operações de negócio), ou versa vice. Mitigate impactos negativos possíveis de um ou outro sentido, é imperativo que o infrastructure e outros sistemas de gerência da mudança estão conectarados apropriadamente (veja figura 8.1). As entradas ao processo da gerência da mudança compreenderão: programação para diante do · do · CMDB de RFCs do · das mudanças (FSC). As atividades empreendidas envolverão: mudanças controlando filtrando do · das mudanças do · e o · do processo da mudança que chairing o CAB e o · do comitê de CAB/Emergency (veja o parágrafo 8.3.2) que revê e que fecha o relatório da gerência do · de RFCs. As saídas do processo serão: o · dos minutos e das ações do CAB do · de RFCs do · do · FSC muda relatórios da gerência. A gerência da mudança não é responsável para identificar os componentes afetados pela mudança ou atualizar os registros da mudança (o domínio da gerência da configuração), nem é responsável

para a liberação de novo dos componentes mudados (o domínio da gerência da liberação). Os relacionamentos entre a gerência da capacidade, a gerência da mudança, a gerência da configuração, e a gerência da liberação são ilustrados em figura 8.2.

Figure 8.2 – Relationship between Capacity Management, Change Management, Configuration Management and Release Management.Click here to view a larger version in a new browser window.

Como um exemplo do scoping, o seguinte é extraído do ` um código de prática para TI a gerência do serviço - PD0005 - do BSI: A gerência da mudança compreende: o · que levanta e que grava muda o · que avalia o impacto, o custo, os benefícios e o risco do · das mudanças desenvolvendo a justificação do negócio e obtendo a gerência do · da aprovaçã0 e a coordenação do · da execução da mudança que monitora e que relata no · da execução que fecha e que revê os pedidos da mudança. As mudanças da emergência são requeridas às vezes e as empresas devem planear para estes com cuidado. Seguem geralmente o processo da mudança mas alguns detalhes podem ser documentados retrospectively. Os registros da mudança devem ser revistos regularmente para identificar tendências e ajudar à organização a melhorar o serviço identificando componentes high-risk. Pode ser difícil assegurar-se de que os representantes dos contratantes, tais como coordenadores da ferragem, adiram aos procedimentos da gerência da mudança da organização. Recomenda-se que os contratos com fornecedores devem, onde possível, para incluir a necessidade para tal conformidade. A condição 12 do contrato padrão de CCTA CC88, parte 2-C lê: Se o CONTRATANTE propuser modificar qualquer peça da ferragem contractually mantida (CMH) o CONTRATANTE notificará a AUTORIDADE e pedirá o acordo da autoridade à modificação proposta, tal acordo não ser retido unreasonably. Se tal acordo for dado, a seguir a modificação estará realizada em uma estadia mutuamente conveniente.

8.2.1 Why Change is important

a mudança do ` ' tem muitas definições erudite mas possivelmente o mais apt é o mais simples:

A mudança é o processo de mover-se de um estado definido para outro. Tudo muda e, no negócio, onde a vida é suficientemente complexa já, o reliance em sistemas de informação e a gerência das causas da tecnologia para gastar uma quantidade astonishing de · do tempo que avalia o impacto da mudança do negócio ncEla · que analisa o impacto dcEla mudança no · do negócio que identifica os problemas que se levantam continuamente isso requer mais · da mudança que introduz as idéias e os dispositivos novos que causam mesmo mais mudança. A mudança controlando transformou-se uma ocupação a tempo completo. Se as mudanças puderem ser controladas optimise a exposição do risco, a severidade do impacto e o rompimento, e naturalmente ser bem sucedidas na primeira tentativa, a linha inferior para o negócio é o realisation adiantado dos benefícios (ou da remoção de risco), com um saving do dinheiro e do tempo. Embora focalizado na marca do mid-range na escala das coisas, a orientação neste capítulo é adaptable - apesar de tudo, o planeamento, risco controlando, controlar, rompimento minimizando, comunicando-se, executando e medindo é mal exclusivo a qualquer amável ou ao tamanho da organização ou do infrastructure. Este capítulo fornece a orientação em mudanças controlando que é scaleable para: o · pequeno e grande do · das mudanças muda com mudanças principais ou menores do · do impacto em um · requerido do timeframe para custar a · tipos e tamanhos diferentes das organizações.

8.2.2 Boundaries between Incident resolution and Change Management

O capítulo 5 deste livro discute o life-cycle do incident e conjuntamente com o capítulo 6, gerência do problema, jogos a cena para o inclusion da gerência da mudança nestes processos. Não obstante, é de valor considerar os limites entre a definição do incident e a mudança. Um incident não é uma mudança e um problema não pode conduzir a uma mudança. Uma

mudança em termos da gerência do infrastructure é o resultado do problema que repara onde há um ` um o estado diferente de uma condição previamente definida '. Isto pode ser manifestado em um número de maneiras, visíveis e invisíveis ao olho despido. Está aqui um exemplo: Um PC quebra para baixo e assim que é removido e substituído com um novo. A gerência do infrastructure exige o esse, seguindo o atendimento técnico e registrar, definição e reparar do incident, registros de gerência da configuração foram atualizados corretamente. Os procedimentos da mesa do serviço assegurar-se-ão de que a pessoa que relatou o incident no primeiro lugar saiba que o PC novo, e todos os artigos do treinamento e os subordinados que puderem necessitar ir com ele, estiveram requisitados, e quando pode se esperar. É importante saber a distinção entre um pedido da mudança e um pedido do serviço. Muitas organizações mis-classify pedidos do serviço, tais como o desejo mudar uma senha ou talvez estender horas do serviço, como pedidos da mudança; isto resulta em um processo swamped da gerência da mudança. Os exemplos dados são mudanças, mas mudanças que podem ser filtradas e controlado mais eficientemente do que usando todos os processos descritos neste livro. Uma área que até que relativamente recentemente uniforme gerência do infrastructure negligenciada estêve estratégia da regressão ou do back-out. As guias originais mencionaram certamente a introdução de suportar para fora mudanças do problema do ` ', mas é mais e mais importante pensar bem sobre o back-out antes da execução. Muito frequentemente, o back-out é a última coisa a ser considerada; os riscos podem ser avaliados, as plantas do mitigation moldadas na pedra, mas como começar para trás ao ponto original do começo frequentemente é ignorado ou considerado somente quando a regressão é a última opção restante. O processo da gerência da mudança deve assegurar-se de que todas as plantas da mudança incluam plantas para o back-out no evento de problemas unforeseen sérios.

8.2.3 Application development and Change Management

Se você informar meramente colaboradores de aplicações e analistas de sistemas que toda a mudança está agora sob o controle de um único processo da gerência da mudança, você é improvável receber a sustentação entusiástica. Há muitas razões boas para um processo tão único da gerência da mudança. Entretanto, a dinâmica da mudança aos projetos dos sistemas e aos programas faz-lhe impossível nigh bom fazer exame do controle das mudanças ao software em em qualquer altura que até versões sistema-testadas de programas originais, e às vezes os suites dos programas, realizam-se na fase testando de aceitação do cliente. Nos termos do progresso do desenvolvimento de programa, faz o sentido para que a gerência da mudança saiba o que está indo sobre, mas o controle cotidiano da versão e assim por diante é deixado mais sensibly à equipe do desenvolvimento das aplicações, com a ênfase em comunicações boas e rápidas. Financiar da gerência da gerência e da configuração da mudança no desenvolvimento do software de aplicações pode levantar-se dos orçamentos de program/project (certamente, se considera a mais melhor prática em muitas organizações). A liberação dos produtos ao ambiente operacional é também melhor financiou esta maneira, a fim estender o espaço dos processos sem ballooning o orçamento da gerência do serviço. Para mais informação, veja o capítulo 9, gerência da liberação. Considere as implicações para a gerência da configuração. Poucas ferramentas do software da gerência do infrastructure são projetadas muito para o desenvolvimento controlando do software de aplicações. Em de tamanho médio à organização grande, podia haver um número significativo dos povos que escrevem aplicações novas. Em que nível você quer começar com gerência da configuração? Algumas opções puderam incluir: o · a linha do código do programa que é (regularmente) · mudado do · comum dos módulos do · do módulo do software o · completo dos programas ligou suites do · dos programas dos programas. as recomendações Duro-e-rápidas não são apropriadas. Você deve decidir-se para yourself na luz do conhecimento de seus excitadores, sistemas e recursos do negócio. Uma organização necessita fazer as decisões sensible baseadas em excitadores do negócio, em risco, em manpower, em potencialidade das ferramentas, no competence organisational e na equação cost-benefit no micro-nível da gerência da mudança e da gerência da configuração. Se a decisão for feita exame para controlar centralmente todas as mudanças, necessitará estar um investimento principal em ferramentas apropriadas e em treinamento do software. Consulte por favor à seção 8.8 para mais informação. A escala do problema da gerência da configuração está desobstruída; a escala do problema da gerência da mudança é talvez mesmo mais má, desde que o impacto da mudança do negócio deve também ser feito exame no cliente onde filtrará eventualmente para baixo à gerência operacional da mudança.

8.2.4 Business change and Change Management.

O processo da gerência da mudança controla mudanças ao dia à operação do dia do negócio. Não é nenhum substituto para o uso organização-largo dos métodos tais como PRINCE2 controlar e controlar projetos. Em umas seções mais atrasadas deste capítulo, você lerá sobre CABs e seu papel ocasional em avaliar a necessidade para a mudança, e o timescale e a importância das mudanças. Onde apropriado, o CAB deve ser envolvido com as equipes da gerência do programa e de projeto para se assegurar de que a mudança emita, alvos, impactos e os desenvolvimentos são sidos conectados em cascata durante todo a organização. O one-way em que a gerência da mudança pode ajudar mudar planners é construindo modelos das mudanças e liaising com planners da capacidade para avaliar o impacto dos modelos.

8.3 Basic concepts

Os conceitos básicos da gerência da mudança são principalmente processo-relacionados e managerial, melhor que técnicos (visto que a gerência do incident é primeiramente técnica, com uma ênfase forte na natureza mecânica de alguns dos processos). Esta seção focaliza conseqüentemente em fornecer a informação que você necessitará identificar os componentes os mais importantes para sua organização. As figuras 8.3a e 8.3b representam um fluxograma de procedimentos básicos da gerência da mudança. Figura 8.4 ilustra o uso de procedimentos padrão da gerência da mudança (modelos da mudança) dentro do life-cycle da mudança.

Figure 8.3a – Basic Change Management procedures – part 1.Click here to view a larger version in a new browser window.

Figure 8.3b – Basic Change Management procedures – part 2.Click here to view a larger version in a new browser window.

Figure 8.4 – An approach for standard Change Management procedures.Click here to view a larger version in a new browser window.

Uma mudança padrão é uma mudança ao infrastructure que segue um trajeto estabelecido, é relativamente comum, e é a solução aceitada a uma exigência ou a um jogo específico das exigências. Os exemplos puderam incluir um melhoramento de um PC a fim empregar o software específico, acionadores de partida novos dentro de uma organização, e conexões do PC, do software e de rede para mudanças provisórias ou seasonal às exigências. Os elementos cruciais de uma mudança padrão são aquele: o · as tarefas é well-known e a autoridade provada do · é dada eficazmente adiantado o · que o trem dos eventos pode geralmente ser iniciado pelo · da mesa do serviço a aprovaçã0 budgetary será tipicamente preordained ou dentro do controle do requester da mudança. Uma vez a aproximação foi estabelecida e documentada, um processo padrão da mudança deve ser desenvolvido e promulgado para assegurar-se de que tais mudanças estejam processadas eficientemente para suportar as necessidades do negócio da organização.

8.3.1  Requests for Change

Os pedidos para a mudança (RFCs) são provocados para uma variedade larga das razões, de uma variedade larga das fontes. As razões incluem: o · requereu a definição descontentamento do usuário ou do cliente do · de um relatório do incident ou do problema expressado através da ligação do cliente ou do · da gerência do nível de serviço a introdução ou a remoção proposta de um · novo do CI um melhoramento proposto a algum componente das exigências do negócio do infrastructure ou do · mudado · do sentido novo ou mudou mudanças do produto ou do serviço do · da mudança da posição do · da legislação dos vendedores ou dos contratantes. RFCs pode ser concernido com a qualquer parte do infrastructure ou com todo o serviço ou atividade. Estão aqui alguns exemplos: · dos cursos de treinamento do · da tampa da engenharia do · das facilidades de telecomunicações do · da documentação do · do software do · da ferragem do · TI do · tático das plantas do · dos procedimentos da gerência do infrastructure infrastructure ambiental. A lata de RFCs, naturalmente, esteja no formulário de papel, ou - como é cada vez mais o caso - seja prendido eletronicamente, talvez no Intranet da companhia. Os seguintes artigos devem ser incluídos em um formulário do RFC, se papel ou eletrônico: a descrição do · do número do RFC do · (mais a referência transversal ao número do relatório do problema, onde necessário) e a identidade do item(s) a ser (identification(s) including do CI se o sistema de gerência da configuração estiver no uso) razão mudada do · para o efeito do · da mudança de não executar a versão do · da mudança do artigo para ser nome do ·, posição mudada e número de telefone da pessoa que propõe o · da mudança datam que a mudança era as recomendações propostas do CAB do · do impacto do · da prioridade da mudança do · e da avaliação do recurso (que pode ser nos formulários separados onde conveniente) onde (que podem ser prendidas separada, com avaliações do impacto e do recurso, onde conveniente) a assinatura apropriada da autorização do · (poderia ser eletrônico) a data da autorização do · e o · do tempo programaram a posição do · da execução (identificação da liberação e/ou data e hora) de detalhes do · da planta de Release/implementation da data real da execução do · da planta do back-out do · da mudança builder/implementer e a avaliação de risco do · dos

resultados da revisão do · da data da revisão do · do tempo (cross-reference including ao RFC novo onde necessário) e o · da gerência impactam na continuidade do negócio e no status do · das plantas de contingência do RFC - isto é o ` registrado ', ` avaliou ', ` rejeitado ', ` aceitado ', ` que dorme '. Uma planta da liberação ou da execução deve ser fornecida para tudo mas o mais simples das mudanças e dela deve documentar como suportar para fora da mudança se falhar. Na conclusão da mudança, os resultados devem ser relatados para a avaliação àqueles responsáveis para controlar mudanças, e então ser apresentados como uma mudança terminada para o acordo do cliente (fechamento including de incidents relacionados, de problemas ou de erros sabidos). Claramente, porque mudanças principais haverá mais cliente input durante todo o processo inteiro, mas o ponto principal é que, não importa como pequeno a mudança, o cliente deve ser consultada antes que toda a mudança esteja executada. Enquanto a mudança prosegue com seu life-cycle, o pedido da mudança e o CMDB devem ser updated, de modo que a pessoa que inicíam a mudança esteja ciente de seu status. Os recursos reais usados e os custos incorridos devem ser gravados como a parte do registro. Uma revisão da Borne-Execução (PIR) deve ser realizada para confirmar que a mudança se encontrou com seus objetivos, esse clientes é feliz com os resultados; e aquele lá não foi nenhum side-effects inesperado. As lições aprendidas devem ser sidas realimentadas nas mudanças futuras. As organizações pequenas podem opt usar verificar do ponto das mudanças melhor que PIR em grande escala; em organizações maiores, ponto-verificar terá um valor quando há ocorrer similar de muitas mudanças.

8.3.2  Change Advisory Board

A placa consultiva da mudança (CAB) é um corpo que exista para aprovar mudanças e para ajudar à gerência da mudança na avaliação e no prioritisation das mudanças. Concoante que um CAB é reunido, seus membros devem ser escolhidos quem são capazes de se assegurar de que todas as mudanças estejam avaliadas adequadamente de um negócio e de um viewpoint técnico. Para conseguir esta mistura, o CAB necessita incluir povos com uma compreensão desobstruída das necessidades do negócio do cliente e da comunidade de usuário, assim como as funções técnicas do desenvolvimento e da sustentação. Veja também o parágrafo 8.5.5. Sugere-se que sociedade do CAB, quando necessitado, deve compreender: os serviços do · dos consultantes do · experts/technical das aplicações developers/maintainers do · do representative(s) do grupo de usuário do · do manager(s) do usuário do · de Customer(s) do · do gerente da mudança do · (onde apropriado) staff (como necessário) o contratante do · da equipe de funcionários dos serviços do escritório do · (onde as mudanças podem afetar a acomodação e o versa vice) ou os representantes de terceiros partidos (como necessário - por exemplo em situações do outsourcing). É importante emfatizar que o CAB: o · será composto de acordo com as mudanças que estão sendo consideradas · pode variar consideravelmente na composição uniforme através da escala de um único · da reunião deve envolver fornecedores quando aquele seria · útil deve refletir o usuário e · das opiniões do cliente é provável incluir a equipe de funcionários das relações do gerente do problema e do gerente e de cliente do nível de serviço para ao menos a parte do tempo. Quando os problemas principais se levantam, não pode haver uma hora de reunir o CAB cheio, e é conseqüentemente necessário identificar uma organização menor com autoridade para fazer decisões da emergência. Tal corpo é sabido como o comitê de emergência do CAB (CAB/EC). Os procedimentos da mudança devem especificar como a composição do CAB e do CAB/EC será determinada em cada exemplo, baseado nos critérios alistados acima e em todos os outros critérios que puderem ser apropriados ao negócio. Isto é pretendido assegurar-se de que a composição do CAB seja flexível, a fim representar corretamente interesses de negócio quando as mudanças principais são propostas. Assegurar-se-á de também que a composição do CAB/EC forneça a abilidade, de um perspective do negócio e de um ponto de vista técnico, para fazer decisões apropriadas em todo o eventuality concebível. Uma ponta prática worth ter é que o CAB deve ter indicado e critérios concordados da avaliação. Isto ajudará no processo da avaliação da mudança, em agir como um molde ou na estrutura por que os membros podem avaliar cada mudança.

8.3.3 Change metrics

Necessidades da gerência da mudança (idealmente no consultation com gerentes de negócio) pensar sobre as medidas que têm o meaning específico. Quando for relativamente fácil contar o número dos incidents que se transformam os problemas que se transformam mudanças, é infinita mais valioso ao olhar na causa subjacente de tais mudanças, e para identificar tendências. Melhore ainda para poder medir o impacto das mudanças e demonstrar o rompimento reduzido sobre o tempo por causa da introdução da gerência da mudança, e medir também a velocidade e a eficácia com que infrastructure respondem às necessidades identificadas do negócio. As medidas feitas exame devem ser ligadas aos objetivos de negócio wherever práticos - e ao custo, à disponibilidade do serviço, e à confiabilidade. Todas as predições devem ser comparadas com as medidas reais. A seção 8.7, o metrics e a gerência que relatam, fornecem mais informação.

8.3.4  The Forward Schedule of Change, and Change models

Uma área de gerência da mudança que se moveu em mais ràpidamente do que qualquer outra é o conceito de modelos da mudança do edifício antes da execução. Estes são aplicados na maior parte às mudanças padrão menores tais como o equipamento desktop novo ou promovido. A gerência da capacidade pode ajudar também, para construir modelos grandes de mudanças complexas a fim avaliar o impacto provável antes da coisa real. No general, o model-building da capacidade ocorre para as mudanças que são fora do ordinário, nos termos da complexidade ou a escala - ou ambos. Veja também o

capítulo 9 (gerência da liberação). A introdução da responsabilidade para a avaliação do impacto da mudança principal deve ser definida. Não é uma edição da melhor-prática que as organizações são assim diversas no tamanho, estrutura e a complexidade que não há um tamanho do ` um cabe toda a ' solução. , entretanto, recomenda-se que a mudança principal está discutida no outset com todos os partidos - gerência de program/project e gerência da mudança - a fim chegar em limites sensible da responsabilidade e melhorar comunicações. Embora a gerência da mudança seja responsável para se assegurar de que as mudanças estejam avaliadas e, se aprovadas, desenvolvidas subseqüentemente, testadas, executadas e revistas, responsabilidade claramente final para serviço - including mudanças a ele - descansá-lo-á com diretor, TI gerente de serviços e os clientes que controlam financiar disponível. O CAB recomendará o adoption (ou não) de umas mudanças mais significativas, mas seu impacto deve ser discutido em um estágio suficientemente largo e este pode jorrar tomada a responsabilidade final além daquela da gerência do serviço, ou certamente TI, processo da mudança. a responsabilidade do ` ' cobre aqui o espaço inteiro do processo da mudança e das considerações associadas do risco e as budgetary. Um conceito no extremo oposto da escala da gerência da gerência e da configuração da mudança é aquele da mudança small-scale que pode ser satisfeita pelo uso de modelos padrão da mudança do ` ' - para o exemplo, uma troca do PC ou um update regular do software. Como uma programação predefinida tem sido cumprido assim por muito tempo, junto com todos os critérios (talvez critérios que se relacionam aos processos da configuração ou do teste, para o exemplo), gerência da mudança pode autorizar tais mudanças sem referência aos processos cheios da gerência da mudança. Figura 8.4 ilustra como um processo de usar os modelos padrão da mudança, predefinidos pela gerência da mudança com o acordo dos outros gerentes da sustentação de serviço, pode ser integrado dentro dos processos usuais da mudança. Anote que a definição do espaço ou da severidade das mudanças que se relacionam ao uso do modelo é o específico da organização. O conceito de mudanças programando para a constante do remains da execução, porém se recomenda muito fortemente que a gerência da mudança o instala mudanças às programações do negócio da reunião melhor que programações. Não era uncommon para ELA gerência programar mudanças principais sobre o fim de semana para minimizar o rompimento aos serviços, mas aqueles mesmos gerentes eram também prováveis programar o downtime durante horas de funcionamento para a manutenção essencial. Hoje em dia, a maioria de gerentes ativamente evitam todo o downtime programado dentro das horas do serviço e asseguram-se de que a maioria das mudanças esteja programada na mesma maneira, com a permissão feita qualquer um para os problemas principais que podem se levantar com a execução atrasada ou para mudanças muito urgentes. A fim facilitar este processo, mude a gerência deve coordenar a produção e a distribuição de uma programação do ` para a frente das mudanças (FSC) e de uma disponibilidade projetada ` do serviço ' (PSA). As versões as mais atrasadas destes originais devem estar disponíveis a todos dentro da organização, contida preferivelmente dentro de um Internet geralmente disponível ou do usuário do Intranet. O FSC contem detalhes de todas as mudanças aprovadas para a execução e suas datas propostas da execução. O PSA contem detalhes das mudanças a SLAs concordado e disponibilidade do serviço por causa do FSC atualmente de planeamento. Estes originais devem ser concordados com os clientes relevantes dentro do negócio, com a gerência do nível de serviço, com a mesa do serviço e com a gerência da disponibilidade. Uma vez que concordada, a mesa do serviço deve comunicar todo o downtime adicional de planeamento à comunidade de usuário em grande, usando os métodos os mais eficazes disponíveis. Se sua organização extrair acima dos modelos process do processo da gerência da mudança e integrar aqueles modelos dentro de um modelo total da sustentação de serviço, é uma tarefa simples avaliar o efeito de uma mudança sem o risco e a despesa de mudar o processo na vida real. Similarmente, se você puder construir um modelo de uma mudança principal, você pode eliciar a ajuda da gerência da capacidade, gerência da continuidade do negócio, gerência da disponibilidade e gerência do nível de serviço para avaliar o impacto da mudança em serviços, níveis de serviço e plantas da continuidade do negócio. Com o dae (dispositivo automático de entrada) de tal modelo, você pode avaliar a mudança para a integralidade e construir uma programação, talvez das mudanças phased dentro se necessário, ou simplesmente assegurar-se de que tudo que deve estar no lugar para fazer a mudança bem sucedida esteja no lugar. Esteja ciente que há uma diferença considerável entre fluxogramas e modelos do processo. Os fluxogramas (alguns exemplos úteis de que são fornecidos nesta guia), permitem a gerência da mudança aos fluxos de informação simples da vista mas não abstraem a vida real do ` '. Um modelo process, entretanto, fornece um retrato que seja capaz de avaliação detalhada e engenders a confiança. Um estudo de caso no apêndice B (baseado em dados anonymised de uma organização principal do outsourcing que encontre problemas em uma execução europe-wide dcTI a biblioteca do infrastructure processa) ajudar-lhe-á avaliar o uso dos fluxogramas e dos modelos do processo. Planeando uma mudança usando modelos e programações às plantas do projeto de sustentação, é possível predizer o impacto da mudança. Você pode também olhar a execução das plantas para comparar predições com a realidade, para melhorar o planeamento futuro e para assegurar-se de que a mudança prosiga lisamente. Veja o parágrafo 8.5.9 para a informação sobre mudanças do edifício.

8.3.5 Outsourcing and Change Management

No exemplo do outsourcing da provisão do serviço, tenha que aqueles que fornecem outsourced serviços fazem frequentemente economias da escala usando mainframes gigantes e organizações operacionais grandes do networking, ou talvez têm o poder comprando maciço por causa da escala de sua compra. Neste caso, o adoption da orientação de ITIL está indo claramente ter um impacto principal nos termos de reduzir o custo de fornecer serviços, de fazer a provisão do serviço mais de confiança, e de melhorar a eficiência. Quando o outsourcing estiver sob a consideração, o receptor de necessidades dos serviços fazer exame no cliente das seguintes edições a respeito do processo da gerência da mudança: · quem é responsável para controlar as mudanças cotidianas que se levantam de RFCs, de o que fontes (veja o parágrafo 8.3.1)? · que controle mim tem sobre o fornecedor de serviço de modo que eu não esteja sendo feito para pagar por

mudanças unreasonable? · como eu sei que as mudanças não são piecemeal aprovado, com um impacto conseqüente no serviço e no custo do serviço? · quem é responsável para se assegurar de que as mudanças principais do negócio estejam custadas corretamente, aprovado, de planeamento, controlado e executado? · quem é responsável para a integridade dos sistemas e dos serviços que seguem mudanças? o · segurança dos sistemas foi considerado corretamente? · quem deve se sentar no CAB? Não é prático fornecer o conselho geral porque os contratos do outsourcing variam assim muito nos termos de: o · custou a posse do · da ferragem e o · do software o grau a que o negócio incorpora em uma parceria com o · do fornecedor (melhor que um relacionamento simples do fornecedor-consumidor) a natureza dos serviços forneceu o · o espaço daqueles serviços (infrastructure, mesas de service/help, desenvolvimento do software de aplicações, etc.). É assim até você para assegurar-se de que os fornecedores de serviço (outsourced ou na casa) forneçam a função e os processos da gerência da mudança que combinam as necessidades de sua organização. Algumas organizações em situações do outsourcing consultam RFCs a seus fornecedores para estimativas antes da aprovaçã0 das mudanças. Talvez a parte de conselho a mais sensible é a mais óbvia: assegure-se de que você coordene os processos da gerência da gerência da mudança, da gerência do incident, da gerência da liberação e da configuração através de todas as organizações envolvidas na sustentação, na entrega e na gerência de serviço. Pode ser necessário modelar os processos a fim fazer comparações significativas.

Change Management should consider:

o · o que deve ser no · da circulação do · da posse do · da planta que negócios chaves devem ser · suportado como aqueles negócios são suportados por TI as ligações do · à continuidade do negócio e · das plantas de contingência o · crítico dos timescales do · dos componentes arrisca o invocation do · da estratégia da regressão do ·.

8.3.6 Critical outage plan

Embora planear para a recuperação de sistemas críticos do negócio não seja uma tarefa que seja a responsabilidade direta da gerência da mudança, sua participação é não meramente sensible mas essencial. Isto é porque todas as plantas para o recuperar os sistemas e os serviços que são fundamentais ao negócio serão sujeitas à mudança e devem ser controladas para assegurar a operação lisa. É, naturalmente, também necessário considerar o que deve ser feito no evento das plantas que vão awry - ou mesmo se você necessita suportar para fora das mudanças resultando do uso das plantas. Nestes exemplos, o conselho mais adiantado sobre planear para para trás-saídas muito cedo na fase do planeamento transforma-se particularmente germane. Claramente, deve haver uma ligação para mudar processos programando.

8.4 Benefits, costs and possible problems

8.4.1 Benefits

A gerência eficiente do serviço requer uma abilidade de mudar coisas em uma maneira em ordem, sem fazer erros e fazer exame de decisões erradas. A gerência eficaz da mudança é indispensable à provisão satisfatória dos serviços, e requer uma abilidade de absorver um nível elevado da mudança. Os benefícios específicos de um sistema de gerência eficaz da mudança incluem: o alinhamento melhor do · dcTI serviços à visibilidade aumentada · das exigências do negócio e uma comunicação das mudanças ao negócio e serviço-suportam o · melhorado · da avaliação de risco da equipe de funcionários um impacto adverso reduzido das mudanças na qualidade dos serviços e na avaliação do · de SLAs mais melhor do custo de mudanças propostas antes que esteja · incorrido poucas mudanças que têm que ser suportadas-para fora, junto com uma abilidade aumentada de fazer mais fàcilmente o este quando o · necessário melhorou o problema e gerência da disponibilidade com o uso da informação valiosa da gerência que se relaciona às mudanças acumuladas através do · do processo da gerência da mudança aumentou a produtividade dos usuários - com menos rompimento e, um · mais de alta qualidade dos serviços aumentou a produtividade do pessoal chave com menos necessidade para diversão dos deveres de planeamento para executar mudanças urgentes ou do · errôneo das mudanças do back-out a abilidade mais grande de absorver um volume grande do · das mudanças uma percepção realçada do negócio dcEla com uma qualidade melhorada do serviço e de uma aproximação profissional.

8.4.2 Costs

Os dois custos principais da gerência da mudança são para a sustentação das ferramentas da equipe de funcionários e do software.

Staff costs

Os custos da equipe de funcionários incluem custos para o papel e a equipe da gerência da mudança, membros do CAB, e construtores da mudança, including a configuração e a gerência da liberação. Estes custos devem naturalmente ser

compensados pelos benefícios que são, ou serão, ganho. Na prática, a maioria de organizações têm já um número de povos que são tempo da despesa em segurar mudanças. Embora o adherence à orientação neste capítulo possa parecer aumentar a quantidade de tempo da gerência gastada em mudanças, na prática você encontrará que a gerência gastará menos tempo em mudanças como a necessidade segurar as edições que se levantam da gerência ineficaz da mudança é eliminada.

Support tools

O custo de instrumentos de apoio, junto com todas as exigências de ferragem, necessita ser considerado. Embora as ferramentas que integram a sustentação para a gerência da mudança, a gerência da configuração, a gerência do problema e as mesas do serviço sejam prováveis ser mais caras do que ferramentas de gerência simples da mudança do ` ', o custo adicional é frequentemente justifiable. Para organizações maiores, os processos da gerência podem ser virtualmente impossíveis executar eficazmente sem os instrumentos de apoio adequados.

8.4.3 Possible problems

O processo da gerência da mudança que você executa deve ser apropriado ao tamanho de sua organização; um processo sobre-burocrático pode diminuir sua eficácia. Os sistemas paper-based (encontrados frequentemente nas organizações muito pequenas ou nas organizações que estabelecem a gerência da mudança para a primeira vez) são difíceis de administrar e resultar frequentemente nos bottlenecks; são realmente somente práticos para organizações muito pequenas. Pode haver umas dificuldades cultural em começar a equipe de funcionários, os clientes e os usuários aceitar que um único sistema de gerência da mudança deve ser usado para todos os aspectos de um infrastructure. Pode reque a instrução convencer todos que todos os componentes de um infrastructure podem, e muito frequentemente, para impactar pesadamente em cima de se, e que as mudanças a CIs individual requerem a coordenação. As tentativas podem ser feitas para executar mudanças sem referência ao processo da gerência da mudança. As medidas devem ser introduzidas para impedir e detectar tais mudanças illicit, incluindo: o · que conduz exames independentes regulares para certificar-se de que a equipe de funcionários da gerência da mudança, a outra equipe de funcionários da gerência do serviço e os usuários estejam aderindo ao · dos procedimentos da gerência da mudança instituindo controles da gerência sobre as atividades de in-house e equipe de funcionários de sustentação dos contratantes, e projeta o · que executa o controle da gerência da configuração de todo o · de CIs e de versões que detecta o acesso de usuário ao equipamento ou ao software que são desconhecidos ao sistema de gerência da configuração através do · da mesa do serviço que treina a equipe de funcionários nova e existente ncTI gerência do serviço.

Pode ser difícil assegurar-se de que os representantes dos contratantes, tais como coordenadores da ferragem, adiram aos procedimentos da gerência da mudança da organização. Recomenda-se que os contratos com fornecedores devem, onde possível, para incluir a necessidade para tal conformidade. A condição 12 do contrato padrão de CCTA CC88, parte 2-C lê:

Se o CONTRATANTE propuser modificar qualquer peça da ferragem contractually mantida (CMH) o CONTRATANTE notificará a AUTORIDADE e pedirá o acordo da autoridade à modificação proposta, tal acordo não ser retido unreasonably. Se tal acordo for dado, a seguir a modificação estará realizada em uma estadia mutuamente conveniente.

A publicação do BSI um código de prática para ELA a gerência do serviço - PD0005 - alista também pontos para considerar como problemas possíveis. Claramente dirigir-se a estes pontos transformará os problemas em benefícios. De PD0005:

Os problemas possíveis com · da gerência da mudança o espaço de uma mudança são demasiado largos para os recursos disponíveis, over-stretching a equipe de funcionários e causá-la atrasam a posse do · dos sistemas impactados são unclear, tendo por resultado atrasa e o · incompleto das avaliações se a gerência da mudança for executada sem gerência da configuração, a solução será muito menos · que eficaz o processo é desculpas dando demasiado burocráticas para nao seguinte ele · os dados inaccurate da configuração podem resultar nas avaliações pobres do impacto que conduzem aos povos errados que estão sendo consultados sobre a sincronização pobre do · da mudança dos melhoramentos entre plataformas e através das posições os makes mudam difícil ou impossível programar procedimentos do back-out do · falte ou a mudança do · untested que progride pedidos é manualmente intensive; é aconselhável começar com uma base de dados simples ou uma falta automatizada do · do sistema de suportar dos gerentes sênior e médios alongará tempos da execução, equipe de funcionários resistirá os controles que prefeririam evitar a menos que pudessem ver que o compromisso do · que do gerente o processo falha freqüentemente quando as mudanças da emergência devem ser feitas.

8.5 Activities

As.well.as controlar os processos da mudança e os procedimentos, gerência da mudança têm uma responsabilidade para controlar as relações entre se e o outro negócio e TI funciona. Um modelo do processo da amostra da mais melhor prática na gerência da mudança encapsulated nesta orientação. Entretanto, deve ser aparente que determinados processos são imperativos para a mais melhor prática - para o exemplo, mudança que registra, atualizar da gerência da configuração, e análise do impacto. A maneira em que uma organização se decide executar o processo da gerência da mudança é entretanto, a uma extensão grande dirigida pelos recursos disponíveis (tempo, prioridades, povos e, sobretudo, dinheiro).

8.5.1 Planning the implementation of operational processes

A gerência da mudança deve planear a execução de procedimentos operacionais para as atividades descritas nesta seção, ou emende todos os procedimentos existentes para conformar-se melhor a estes guidelines. Figura 8.3 fornece um fluxograma destes procedimentos. Como mencionado no parágrafo 8.3.4, os modelos process fornecem um retrato mais rico do que um fluxograma mas requerem uma compreensão mais grande e são discutidos conseqüentemente mais tarde nesta guia em um estudo de caso.

8.5.2 Change logging and filtering

Os procedimentos para documentar RFCs, usando formulários padrão, formulários do email ou telas do Intranet, devem ser decididos. Onde um instrumento de apoio por computador é usado, a ferramenta pode ditar o formato. Onde nenhum padrão está imposto por um instrumento de apoio, ou se um sistema paper-based tiver que ser usado, recomenda-se que os artigos mostrados no parágrafo 8.3.1 sejam incluídos no formulário do RFC. Recomenda-se mais mais que todos os membros da organização estejam autorizados pedir mudanças. Se não, a inovação pôde stifled ou os interesses importantes podem ir unreported. Mesmo assim, onde há um grande número usuários, sugere-se que os pedidos de usuário devem reque a assinatura por um gerente sênior do usuário antes da submissão. Isto filtrará para fora todos os pedidos que não tiverem a sustentação da comunidade de usuário mais larga, ou é pouco prático, e ajudá-los-á ordenar pedidos similares ou idênticos, assim reduzindo volumes do pedido. Entretanto, os gerentes do usuário devem também ter cuidados para não stifle a inovação ou não desanimar a equipe de funcionários de propôr mudanças. Todo o RFCs recebido deve ser registrado e alocou um número de identificação (na seqüência cronológica). Onde os pedidos da mudança são submetidos como uma definição a um registro do problema (fotorreceptor), é importante que o número original do fotorreceptor está retido de modo que a ligação entre o problema e sua definição seja prontamente aparente. Recomenda-se que registrar de RFCs está feito por meio de uma ferramenta de gerência integrada do serviço, capaz de armazenar ambos os dados em todo o CIs e também, importante, os relacionamentos entre ele. Isto ajudará extremamente ao avaliar o impacto provável de uma mudança a um componente do sistema em todos componentes restantes. Todas as ações devem ser gravadas, enquanto são realizadas, dentro do registro da gerência da mudança. Se isto não for possível para nenhuma razão, a seguir devem manualmente ser gravados para o inclusion na oportunidade possível seguinte. Os procedimentos necessitam especificar quem têm o acesso ao sistema registrando e o que os níveis do acesso serão. Normalmente, o sistema está aberto a todo o pessoal autorizado criar, ou adicione relatórios de progresso a um RFC (embora o instrumento de apoio deve manter a gerência da mudança ciente de tais ações). Entretanto, mude somente a equipe de funcionários da gerência, ou a equipe de funcionários de sustentação da gerência da configuração se a gerência da mudança for uma parte integral de um sistema de gerência da configuração, deve ser permitida fechar um RFC. Os procedimentos devem estipular que, como mudanças estão registrados, gerência da mudança devem momentaneamente considerar cada pedido e filtrar para fora alguns que forem totalmente pouco práticos. Estes devem ser retornados ao iniciador, junto com detalhes breves da razão para a rejeção, e o registro deve gravar este fato. Uma direita de apelação de encontro à rejeção deve existir, através das canaletas normais da gerência, e deve ser incorporada dentro dos procedimentos.

8.5.3  Allocation of priorities

Cada RFC deve ser alocado uma prioridade que seja baseada no impacto do problema e no urgency para o remédio. Esta avaliação da prioridade é usada decidir-se que qual muda deve ser discutido e avaliado primeiramente, pela gerência da mudança ou pelo CAB se necessário. A gerência da mudança deve ser responsável para atribuir esta prioridade. A prioridade de RFCs idealmente deve ser decidida na colaboração com o iniciador e, se necessário, com o CAB; mas não deve ser deixada ao iniciador sozinho, porque uma prioridade mais elevada do que é justificado realmente pode resultar. A avaliação de risco é da importância crucial neste estágio. O CAB necessitará a informação em conseqüências do negócio a fim avaliar eficazmente o risco de executar ou de negar a mudança. As seguintes avaliações da prioridade são fornecidas como exemplos somente. Muitas ferramentas do software permitem que uma escala larga de avaliações da prioridade seja · ajustado imediato. Causando a perda do serviço ou de problemas severos da usabilidade a um número maior dos usuários, de um sistema missão-crítico, ou de algum problema ingualmente sério. Ação imediata requerida. As reuniões urgentes do CAB ou do CAB/EC podem necessitar ser reunido. Os recursos podem necessitar ser alocado imediatamente para construir tais mudanças autorizadas. · elevado. Severamente afetando alguns usuários, ou impactá-los em cima de um grande número usuários. Para ser dado a prioridade a mais elevada para recursos do edifício, testar e da execução da mudança. meio do ·. Nenhum impacto severo, mas o rectification não pode ser adiado até que a liberação ou o melhoramento em

seguida programado. Para ser prioridade média alocada para recursos. · baixo. Uma mudança está justificada e necessária, mas pode esperar até que a liberação ou o melhoramento em seguida programado. Para ser recursos alocados conformemente. RFCs terá sido anotado já com a prioridade definida e concordada dentro da organização, que é uma função do impacto e do urgency do problema, indicar a ordem em que deve ser ` reparado '. Este código bom de severidade do ` ' deve ser revisto e (a menos que há uma razão porque não) deve ser usado como uma base para a prioridade da mudança. Timeframes para cada nível da prioridade deve ser predeterminado e os processos do escalation definidos.

8.5.4 Change categorisation

A introdução do risco ao negócio de toda a mudança deve também ser considerada antes da aprovaçã0 de qualquer mudança. A gerência da mudança deve examinar cada RFC e decidir-se como proseguir baseado na categoria (predefinida) em que o RFC cai. O processo do categorisation examina o impacto da mudança aprovada na organização nos termos dos recursos necessitados efetuar a mudança. Anote que a estrutura e a complexidade destas categorias querem muito muito dependem das necessidades do negócio, including a escala das avaliações da prioridade identificadas (veja o parágrafo 8.5.3). O processo do prioritisation acima é usado estabelecer a ordem em que as mudanças põem para a frente devem ser consideradas. Algumas das prioridades do exemplo dadas puderam aplicar-se a uma mudança que caísse em algumas das categorias da impacto-avaliação do exemplo abaixo. Onde as mudanças menores são involvidas, a gerência da mudança pode delegar a autoridade aos partidos específicos aprovados, tais como o pessoal da mesa do serviço. Entretanto, as estruturas de relatório adequadas devem ser postas no lugar; quando a autoridade puder ser delegada, o accountability não pode. As categorias do exemplo são ajustadas para fora abaixo. Espera-se que a maioria de RFCs cairá nas primeiras duas categorias do exemplo.

Minor impact only, and few ‘build’ or additional ‘runtime’ resources required.

A gerência da mudança deve ter delegado a autoridade para autorizar e programar tais mudanças, mas estes devem ser registrados de modo que: os registros do · e os testes padrões de trabalho podem ser · identificado exato e os custos completos para cada serviço, área etc. do cliente, são mudanças repetitivas do · disponível, mudanças do follow-on, e as áreas associadas de Problem/Incident podem ser identificadas. Gravando cada mudança em resumo ajudas para entregar um serviço eficaz e eficiente ao cliente permitindo que desperdiçador as tarefas repetitivas sejam manchadas e eliminadas. Se a gerência da mudança tiver quaisquer dúvidas sobre autorizar uma mudança, a mudança pode ser consultada informal aos membros do CAB para uma avaliação mais larga.

Significant impact, and/or significant build or runtime resources required.

Dependendo do urgency da mudança a ser feita, a gerência da mudança deve decidir-se se falar aos membros do CAB ou reunir um CAB/EC. Antes de toda a reunião toda a documentação deve ser circulada para o impacto e a avaliação do recurso.

Major impact, and/or very large amount of build or runtime resources required, or impact likely upon other parts of the organisation.

Onde uma mudança principal lhe pertence diretamente, o RFC deve ser consultado à placa de gerência superior da organização ou ao outro corpo apropriado para a discussão e uma decisão de política. Tais mudanças, uma vez aprovadas devem ser passadas para trás, talvez através do CAB, para programar e execução.

8.5.5  CAB meetings

Não deve ser necessário insistir em reuniões face-to-face; muito do processo do referral da avaliação pode ser segurado eletronicamente através dos instrumentos de apoio ou do email. Somente em muito complexo, os casos high-risk ou high-impact querem uma reunião formal do CAB sejam necessários. É, entretanto, uma idéia boa programar uma reunião regular - diga cada seis meses, ou quando os projetos principais são devidos entregar produtos. As reuniões podem então ser usadas fornecer uma revisão formal e sign-off das mudanças aprovadas, uma revisão de mudanças proeminentes, e, naturalmente, discutir todo o major impending mudanças. Onde as reuniões são apropriadas, devem ter uma agenda padrão.

A standard CAB agenda should include a review of:

o · falhou mudanças, suportou-para fora mudanças, ou mudanças aplicadas sem referência ao CAB por Incident Gerência, por gerência do problema ou por · RFCs da gerência da mudança a ser avaliado pelo · RFCs dos membros de CAB que foram avaliadas pelo · das revisões da mudança do · dos membros de CAB o processo da gerência da mudança, including todas as emendas feitas a ele durante o período sob a discussão, as.well.as a gerência proposta wins/accomplishments da mudança do · das mudanças para o período sob a discussão, isto é uma revisão dos benefícios do negócio resultou por o processo da gerência da mudança.

As reuniões do CAB representam umas despesas gerais potencial grandes na época dos membros. Conseqüentemente todo o RFCs, junto com o FSC e o PSA, deve ser circulado adiantado, e flexibilidade permitida aos membros do CAB sobre se atender na pessoa, emitir um deputado, ou emitir todos os comentários através da gerência da mudança. Os papéis relevantes devem ser circulados adiantado para reservar os membros do CAB (e os outros que são requeridos por membros da gerência ou do CAB da mudança) às avaliações do impacto e do recurso da conduta. Em algumas circunstâncias será desejável tabelar afastado RFCs em uma reunião do CAB para uma explanação ou um esclarecimento mais detalhado antes da tomada dos membros do CAB os papéis para a consideração, a tempo para a reunião seguinte. As revisões da mudança são discutidas mais mais no parágrafo 8.5.12.

8.5.6 Impact and resource assessment

Quando conduzir o impacto e a avaliação do recurso para RFCs lhes consultou, a gerência da mudança, o CAB, CAB/EC ou todo o outro (nomeado por membros da gerência ou do CAB da mudança) que é envolvido neste processo, devem considerar os seguintes artigos: · o impacto que a mudança fará em cima do · da operação de negócio do cliente ao efeito em cima do infrastructure e o serviço de cliente, como definido no SLA, e em cima da capacidade e o desempenho, confiabilidade e resilience, plantas de contingência, e · da segurança o impacto em outros serviços que funcionam no mesmo · do infrastructure (ou em projetos do desenvolvimento do software) o impacto nnon-ele infrastructures dentro da organização - para o exemplo, segurança, serviços do escritório, transporte, negócio - · das mesas de ajuda do cliente o efeito de não executar o · da mudança ELE, em negócio e em outros recursos requeridos para executar a mudança, cobrindo os custos prováveis, o número e a disponibilidade dos povos requeridos, o tempo decorrido, e todos os elementos novos do infrastructure requereram o · os recursos ongoing adicionais do · atual de FSC e de PSA requeridos se a mudança fosse executada. Determinadas mudanças que não afetam a especificação de CIs - para o exemplo, um reparo da ferragem - não podem necessitar ser avaliado adiantado para o impacto. Entretanto, recomenda-se que as mudanças pretendidas corrigir erros do software devem ser sujeitas à avaliação formal de RFCs e de impacto. Baseado nestas avaliações, e nos benefícios potenciais da mudança, cada um dos assessores deve indicar se suportam a aprovaçã0 da mudança. Os membros do CAB devem também decidir-se se são satisfeitos com a prioridade alocada pela gerência da mudança e para ser preparado para discutir para quaisquer alterações que vêem como necessário.

CAB recommendations

Os membros do CAB devem vir às reuniões preparadas para fazer as decisões em que as mudanças devem ir adiante, baseadas na avaliação da prioridade das mudanças. O CAB deve ser informed de todas as mudanças que forem executadas como um work-around aos incidents e deve ser dado a oportunidade de recomendar a ação de continuação a estes. Anote que o CAB é um corpo consultivo somente. Se o CAB não puder concordar a uma recomendação, a decisão final sobre se autorizar mudanças, e cometê-las à despesa envolvida, é a responsabilidade da gerência (normalmente diretor dcEla ou gerente de serviço, ou do gerente da mudança como seu representante delegado). Os procedimentos da gerência da mudança devem especificamente nomear o person(s) autorizado assinar fora RFCs. Dependendo da natureza da mudança, as referências aos acordos do nível de serviço podem ser requeridas. Em todo o evento, o cliente sign-off será requerido em algum ponto

8.5.7 Change approval

A cultura da organização em que você trabalho, a uma extensão grande, ditará a maneira em que as mudanças são aprovadas. As estruturas hierárquicas podem jorrar impõem muitos níveis da aprovaçã0 da mudança, quando umas estruturas mais lisas puderem permitir uma aproximação mais aerodinâmica.

Obtaining approval

A aprovaçã0 formal deve ser obtida para cada mudança da autoridade da mudança. A autoridade da mudança pode ser gerência da mudança, o gerente de serviço, ou algum outro pessoa ou grupo nomeado. Para mudanças baixas do risco, a autoridade da mudança pode escolher ser informado das mudanças autorizadas, melhor que seja envolvida em autorizar cada mudança individualmente. Os níveis da aprovaçã0 para uma mudança devem ser julgados pelo tamanho ou pelo risco da mudança. Para o exemplo, as mudanças em uma empresa grande que afetam diversos grupos distribuídos podem necessitar ser aprovado por uma autoridade higher-level da mudança. Há três processos principais da aprovaçã0 que devem

estar no lugar no processo da gerência da mudança: aprovaçã0 financeira, aprovaçã0 técnica, e aprovaçã0 do negócio. A aprovaçã0 financeira indica que o custo de uma mudança estêve avaliado e que está dentro dos limites budgetary aprovados ou encontra-se com o custo - beneficie os critérios que podem ter sido ajustados para a aprovaçã0 da mudança. O estágio técnico da aprovaçã0 é uma garantia que a mudança é praticável, sensible e pode ser executado sem o detriment impróprio aos serviços fornecidos ao negócio. Se os peritos técnicos estiverem requeridos fornecer estimativas de custo (como é o caso em muitas organizações), então esta fase necessita preceder a aprovaçã0 financeira. A aprovaçã0 de cliente é necessária para assegurar-se de que os gerentes de negócio sejam satisfeitos com as propostas da mudança e o impacto em suas exigências do negócio.

8.5.8 Change scheduling

Embora possa ser melhor (ou aconselhável) executar uma mudança de cada vez - para o exemplo, a fim simplificar diagnóstico se um erro ocorrer - isto não é geralmente prático. Por exemplo, uma mudança da ferragem pode reque uma mudança de sistema operando-se suportá-la; o software de aplicações pode necessitar ser mudado assim ràpidamente que uma política da mudança do ` um em um momento ' é impraticàvel lenta; ou uma mudança de software simples pode reque a introdução simultânea da documentação, de procedimentos e do treinamento novos. Considere também, como um exemplo mais adicional, o número das mudanças do concurrent inerentes na introdução de uma configuração desktop padrão nova. Onde as mudanças simultâneas ocorrem, devem ainda ser empacotadas em uma liberação de modo que a coisa inteira possa ser suportada para fora de se os problemas ocorrerem. Uma liberação empacotada deve ser considerada como uma única mudança deste ponto da vista, mesmo que possa conter muitas mudanças individuais, porque será executada ou suportada-para fora como uma única unidade da mudança. Onde quer que possível, a gerência da mudança deve programar mudanças aprovadas em liberações do alvo e recomendar o alocamento de recursos conformemente. Há uma continuidade desobstruída entre a gerência da mudança e os processos da gerência da liberação. Os processos da gerência da liberação impactam em cima do processo da gerência da mudança e, no detalhe, têm um papel nas mudanças tornando-se e mantendo do padrão que introduzem o software e a ferragem novos ou revisados no infrastructure. Como liberações é o manifestation das mudanças, novatos do processo da mudança as liberações sob concordado, documentado e a liberação mantida processa. Onde quer que possível, as mudanças de software devem ser executadas no formulário de liberações empacotadas. É muito importante ter uma estratégia claramente definida da liberação de produto do software essa relações ao sistema de gerência da mudança. Para uma informação mais adicional nisto, veja o capítulo 9, gerência da liberação. É também importante limitar o tamanho de uma liberação às proporções manageable, especial porque é improvável que qualquer liberação será completamente fault-free. Segue que maior a liberação, mais o esforço estará requerido identificar e se dirigir a todos os erros novos. Segue também que haverá um esforço correspondingly maior requerido em atividades da sustentação, tais como a mesa do serviço chama-se, seguindo uma liberação nova. Recomenda-se que a edição de gerência FSCs. da mudança FSCs deve incluir detalhes de todas as mudanças que foram autorizadas para a execução sobre (com o negócio) um período previamente concordado, e do Release(s) que estiveram alocados a. Anote que algumas organizações terão plantas desobstruídas para o termo curto e as plantas mais menos detalhadas no termo mais longo, que necessitam ser incluídas no FSC. Os detalhes breves das mudanças (provavelmente principais) de planeamento por os dois anos seguintes devem também ser incluídos. O FSC deve ser distribuído a todos os clientes e usuários ou seus representantes, colaboradores de aplicação, equipe de funcionários do serviço including a mesa do serviço, e todos os outros partidos interessados. A distribuição da gerência do serviço exterior de FSCs deve ser feita através processo da ligação da mesa ou do cliente do serviço. As programações da mudança devem extensamente ser distribuídas desde que as mudanças propostas e seu sincronismo afetarão o planeamento e as práticas em muitas áreas, dentro e gerência do serviço exterior. A gerência do serviço exterior do promulgation será geralmente através da mesa do serviço e da gerência do nível de serviço e da gerência do relacionamento do cliente. Dentro da gerência do serviço, alcance à programação deve ser fornecido a todos os processos. A gerência da mudança deve reforçar esta informação com um programa proactive da consciência onde o impacto específico possa ser detectado; como impactos antecipados em cima da gerência da capacidade, da gerência da disponibilidade ou dos outros processos. É o mais importante fazer exame na consideração das necessidades do negócio da organização na construção de toda a programação, tendo as necessidades do cliente e as necessidades do usuário da extremidade.

8.5.9  Change building, testing and implementation

RFCs autorizado deve ser passado aos grupos técnicos relevantes para o edifício das mudanças. Isto pôde envolver: · que constrói um · novo do módulo da produção que cría uma versão nova de um ou mais · dos módulos do software que compram o equipamento ou · dos serviços externamente que prepara um · da modificação da ferragem produzindo o · novo ou emendado da documentação que prepara emendas ao treinamento de usuário. A gerência da mudança tem um papel da coordenação, suportado pela gerência da liberação e pela linha normal controles da gerência, para assegurar-se de que estas atividades sejam resourced e terminem também para programar. A gerência da liberação tem um papel mais importante em mudanças menores, como quando as equipes do desenvolvimento do software de aplicações fornecem a instalação da gerência da configuração e o back-out instructions/files. É importante assegurar-se de que os mesmos padrões e métodos que foram usados para um componente original estejam usados outra vez para a mudança. Os procedimentos de Back-out devem ser preparados e documentado adiantado, para cada mudança autorizada, de modo que se os erros

ocorrerem após a execução, estes procedimentos possam rapidamente ser ativados com impacto mínimo na qualidade do serviço. Para impedir mudanças adversamente de impactar na qualidade do serviço, recomenda-se fortemente que as mudanças estejam testadas completamente adiantado (procedimentos including do back-out onde possível). Testar deve incluir aspectos da mudança como: funcionalidade do · do · reliability/availability do supportability do · do maintainability do · da segurança do · do desempenho do ·. Este conselho é particularmente relevante ao ambiente desktop, onde os updates constantes da tecnologia ocorrem. Em muitos casos, isto requererá um ambiente separado do teste do ` '. Reconhece-se que não é sempre possível ou justifiable testar inteiramente todo muda adiantado; pode ser possível em alguns exemplos, embora, usar modelar técnicas para avaliar o impacto provável de uma mudança em vez, ou além, de testar ordinário. A gerência da mudança tem um papel overseeing para assegurar-se de que todas as mudanças que podem ser, estejam testadas completamente. Em todos os casos que envolvem as mudanças que não foram testadas inteiramente, cuidado especial necessita ser tomado durante a execução. A gerência da mudança deve avaliar o risco ao negócio de toda a mudança que dever ser instalada sem ter ocorrido testando completo. Testar deve também incluir a regressão adequada que testa para assegurar-se de que outras áreas do infrastructure não estejam afetadas adversamente pela mudança. Recorde que testar não tem que parar meramente porque uma mudança ou um produto foram viva. A operação normal e o uso do serviço serão testados primeiramente e invocados no uso vivo primeiramente. É conseqüentemente ainda relevante ao desempenho do teste e ao comportamento das mudanças em situações incomuns, inesperadas ou futuras de modo que uma ação corrigindo mais adicional possa ser feita exame antes que todos os erros detectados se tornem manifestos na operação viva. A execução de tais muda deve ser programada quando menos impacto em serviços vivos é provável. A equipe de funcionários de sustentação deve estar na mão a tratar rapidamente de todos os incidents que possam se levantar. Onde é possível introduzir tais mudanças em um ambiente limitado - por exemplo para um grupo piloto dos usuários - esta aproximação deve ser considerada. A gerência da mudança tem a responsabilidade para assegurar-se de que as mudanças estejam executadas como programadas, embora este será pela maior parte um papel da coordenação porque a execução real será a responsabilidade de outra (por exemplo os coordenadores executarão mudanças da ferragem).

8.5.10 Urgent Changes

O número de mudanças propostas urgentes deve ser mantido a um mínimo absoluto, porque são geralmente mais disruptivos e prone à falha. Tudo muda provavelmente para ser requerido deve, no general, ser previsto e planeado, tendo a disponibilidade dos recursos para construir e testar as mudanças. Não obstante, as ocasiões ocorrerão quando as mudanças urgentes são essenciais e assim que os procedimentos devem ser planejados para tratar rapidamente das elas, sem sacrificar controles normais da gerência. Tais procedimentos são mostrados em figura 8.5, e descritos nos seguintes parágrafos.

Figure 8.5 – Procedure for implementing an urgent Change.Click here to view a larger version in a new browser window.

A equipe de funcionários do controle de incident, as operações de computador e a equipe de funcionários da gerência de rede podem ter delegado a autoridade para circumvent determinados tipos de incident (por exemplo falha da ferragem) sem autorização prévia pela gerência da mudança. Tais circumventions devem ser limitados às ações que não mudam a especificação de CIs e que não tentam corrigir erros do software. A rota preferida para circumventing os incidents causados por erros do software deve dever revert ao estado ou à versão confiada precedente, como relevante, melhor que tentando uma mudança unplanned e potencial perigosa. A aprovaçã0 da mudança é ainda um pré-requisito!

8.5.11 Urgent Change building, testing and implementation

As mudanças aprovadas devem ser alocadas ao grupo técnico relevante para o edifício. Onde os timescales o exigem, a gerência da mudança, na colaboração com o gerente técnico apropriado, deve assegurar-se de que a equipe de funcionários e os recursos suficientes (tempo de máquina etc.) estejam disponíveis para fazer este trabalho, mesmo se este significa a chamada da equipe de funcionários dentro do repouso. Os procedimentos e os acordos - aprovados e suportados pela gerência - devem estar no lugar para permitir este. O custo de call-outs da emergência deve ser coberto em algum lugar nos custos running aprovados da gerência do serviço. As plantas de Back-out devem ainda ser planejadas apesar do urgency da mudança. Tanto testar da mudança urgente como é possível deve ser realizado. As mudanças completamente untested não devem ser executadas se em toda avoidable. A experiência mostrou que quando as mudanças vão erradamente, o custo é geralmente mais grande do que aquele de testar adequado. Outra vez, recorde que há um mérito imóvel em testar mesmo depois que uma mudança foi viva. A gerência da mudança deve dar tanto aviso avançado como possível aos clientes e aos usuários sobre toda a mudança imminent. Isto deve ser feito através da mesa do serviço ou da outra mesa de ajuda, como disponível. Quando todas as mudanças urgentes são executadas, particularmente aquelas que não foram testadas adequadamente, gerência da mudança devem assegurar-se de que uma presença técnica adequada esteja disponível, para tackle quaisquer incidents que puderem ocorrer. Se uma mudança, uma vez que executada, não retificar o problema proeminente urgente, lá pode necessitar estar umas tentativas iterativas em reparos. A gerência da mudança deve fazer exame da responsabilidade neste momento assegurar-se de que as necessidades do negócio remanesçam o interesse preliminar. É importante que cada iteração está controlada na maneira descrita nesta seção. A gerência da mudança deve assegurar mudanças abortive é suportada rapidamente para fora de. Se demasiado muitas tentativas em uma mudança urgente forem abortive, há três perguntas que necessitam se dirigir: 1. O problema foi analisado corretamente? 2. O remédio proposto foi testado adequadamente? 3. A solução foi executada corretamente? Em tais circunstâncias, pode ser melhor fornecer um serviço parcial, com algumas facilidades do usuário retiradas, a fim permitir que a mudança seja testada completamente, para suspender temporariamente o serviço e para executar então a mudança. Não pode ser possível atualizar naquele tempo todos os registros de gerência da mudança que as ações urgentes estão sendo terminadas (por exemplo durante durante a noite ou funcionamento do fim de semana). É, entretanto, essencial que manuais estão feitos um registro durante tais períodos, e ele é a responsabilidade da gerência da mudança assegurar-se de que todos os registros estejam terminados retrospectively, na oportunidade possível a mais adiantada. Isto é vital assegurar a gerência que valiosa a informação não é perdida. Um exemplo podia ser atualizar de um atributo que define sucessos do `, falha do ` ' ou talvez a falha parcial do ` ' de uma mudança. Atualizar deve ser realizado pela pessoa responsável para aplicar a mudança, e deve acontecer não mais tarde do que a revisão da execução do borne - e talvez com a cooperação da equipe de projeto, gerente libere ou do desenvolvimento do software de aplicações.

8.5.12  Change review

A gerência da mudança deve rever todas as mudanças executadas depois que um período predefinido decorreu. Este processo pode imóvel envolver membros do CAB; A gerência da mudança pode olhar-lhes para o auxílio no processo da revisão. As revisões da mudança podem ser tabeladas em reuniões do CAB, para a informação dos membros do CAB e concordar toda a ação de continuação que puder ser needed. A finalidade de tais revisões é estabelecer isso: o · a mudança teve o efeito desejado e encontrado com seus usuários e clientes do · dos objetivos seja satisfeito com os resultados, ou para identificar todo o · dos shortcomings lá não foram nenhum side-effects inesperado ou indesejável à funcionalidade, à disponibilidade, ao capacity/performance, à segurança, ao maintainability etc.. o · os recursos usados executar a mudança era enquanto de planeamento · que a planta da execução trabalhou corretamente (assim que inclua comentários dos implementers) o · a mudança foi executada no tempo e custar a · a backout-planta funcionou corretamente, se necessitado. Todos os problemas e discrepâncias devem ser sidos realimentados aos membros do CAB (onde foram consultados ou onde um comitê foi reunido), aos assessores do impacto, às autoridades do produto e às autoridades da liberação, para melhorar os processos estimando para o futuro. Onde uma mudança não conseguiu seus objetivos, a gerência da mudança (ou o CAB) devem decidir-se que ação de continuação é requerida, que poderia envolver levantar um RFC revisado. Se a revisão for satisfatória ou a mudança original estiver abandonada, o RFC deve formalmente ser fechado no sistema registrando.

8.5.13  Reviewing the Change Management process for efficiency and effectiveness

A gerência da mudança deve instigate ações de continuação para corrigir todos os problemas ou inefficiencies que levantam-se no sistema de gerência próprio da mudança em conseqüência das mudanças ineficazes. Para o exemplo, uma reserva grande da mudança pode indicar que a gerência da mudança está sob-resourced; uma incidência elevada de mudanças mal sucedidas indica que esse avaliação da mudança ou edifício da mudança não está trabalhando satisfatoriamente. As revisões record da mudança podem também mostrar acima problemas em outros processos, tais como a gerência do problema, na confiabilidade de componentes do sistema, ou na equipe de funcionários ou os procedimentos e/ou o treinamento dos usuários. Estes problemas devem ser relatados aos gerentes concernidos e destacados nos relatórios da gerência da mudança à gerência. Recomenda-se também que revisão da gerência do serviço o processo da gerência da mudança periòdicamente para a eficiência e a eficácia. Tal revisão deve ser realizada logo depois que o processo da gerência da mudança é executado, para assegurar-se de que as plantas estejam realizadas corretamente e que o processo está funcionando como pretendido. Todos os problemas devem ser seguidos para trás à fonte e ser corrigidos o mais cedo possível. Depois disso, as revisões formais regulares do processo da gerência da mudança devem ocorrer - ao menos cada seis meses. O gerente da mudança deve também continuamente avaliar a eficiência e a eficácia do processo da gerência da mudança. Deve-se anotar, com respeito a toda a revisão, que um número elevado de RFCs não indica necessariamente um problema com o processo da gerência da mudança - pode apenas refletir sistemas temporários. Qualquer tentativa de reduzir o número de RFCs pode stifle a inovação. O indicador principal de um processo eficaz da gerência da mudança é que a mistura direita do ` ' de RFCs está mantida, não isso que o número de RFCs foi reduzido tempo excedente. Outros indicadores de um processo eficaz da gerência da mudança incluem: o · uma redução de impactos adversos na qualidade do serviço que resulta dos pobres muda o · da gerência uma redução no número dos incidents seguidos para trás ao · executado mudanças uma diminuição no número das mudanças suportadas para fora do · um número baixo de mudanças urgentes (e conseqüentemente unplanned) - este deve incluir a emergência, para fora-$$$-HORAS das mudanças consultadas para trás para o · do esclarecimento nenhuma evidência das mudanças que estão sendo feitas sem referência correlação do fim do · do system(s) à gerência da gerência e da configuração da mudança entre FSCs e a execução real do · das mudanças nenhum RFCs high-priority nas reservas, e o tamanho das reservas que não aumentam a evidência do · do recurso exato que estima, quando as estimativas do recurso são comparadas retrospectively com reais os recursos rever regular usado do · de RFCs e de mudanças executadas, e o clearing de alguma execução bem sucedida do · das reservas da revisão das mudanças que beneficiam claramente o negócio e satisfem ao · dos clientes uma incidência baixa de RFCs unjustifiably rejeitado. Estes artigos podem ser usados como o metrics medindo a eficácia e, a uma extensão, a eficiência do processo da gerência da mudança. Em medir essa eficiência, é necessário considerar, a quantidade de mudança executada com sucesso por a unidade da equipe de funcionários custa, including, para o exemplo, os custos dos assessores, construtores, e verificadores. Isto pode ser difícil de avaliar em termos absolutos, mas deve geralmente ser possível observar um aumento na eficiência sobre o tempo, especial nos dias adiantados do processo da gerência da mudança quando a curva de aprendizagem é a mais íngreme.

8.5.14  Roles and responsibilities

Claramente, o papel da gerência da mudança deve ser enchido, com as responsabilidades definidas, para o processo da gerência da mudança trabalhar eficazmente. Uma lista sugerida das responsabilidades para os papéis da gerência da mudança é esboçada abaixo:

Change Manager

Os deveres principais do gerente da mudança, algum de que pode ser delegado, são alistados abaixo do · recebem, registram e alocam uma prioridade, na colaboração com o iniciador, a toda a rejeição de RFCs. todo o RFCs que é totalmente pouco prático. a tabela do · todo o RFCs para uma reunião do CAB, emite uma agenda e circula todo o RFCs aos membros do CAB adiantado das reuniões para permitir a consideração prévia. o · decide-se que povos virão a que reuniões, que começam RFCs específico dependendo da natureza do RFC, o que deve ser mudada, e das áreas do pessoa de perícia. o · reune reuniões urgentes do CAB ou do CAB/EC para todo o RFCs urgente. cadeira do · todas as reuniões do CAB e do CAB/EC. o · após a consideração do conselho dado pelo CAB ou pelo CAB/EC, autoriza mudanças aceitáveis. edição FSCs do ·, através da mesa do serviço. o · liaise com todos os partidos necessários para coordenar o edifício, testar e a execução da mudança, de acordo com programações. update do · o registro da mudança com todo o progresso que ocorre, including algumas ações para corrigir problemas e/ou para fazer exame de oportunidades de melhorar a qualidade do serviço. revisão do · todas as mudanças executadas para assegurar-se de que se encontrassem com seus objetivos. Consulte para trás que foi suportado para fora ou falhou. revisão do · todo o RFCs proeminente que espera a consideração ou que espera a ação. o · analisam registros da mudança para determinar todas as tendências ou os problemas aparentes que ocorrem. Rectification da busca com partidos relevantes. · RFCs Próximo. relatórios regulares e exatos do produto do · da gerência.

8.5.15 Establishing a Change Advisory Board

Se um CAB for estabelecido, necessita ter termos de referência apropriados (por exemplo regularity da reunião, espaço da influência, ligações para programar a gerência). Para assegurar a respresentação apropriada, os membros desta placa

devem incluir representantes das seguintes áreas: os clientes do · afetados pelos representantes do · da mudança de todas as áreas principais dentro da gerência do serviço processam o · os usuários sênior do · das equipes do desenvolvimento da aplicação, ou os seus representantes. O gerente da mudança deve agir como a cadeira desta placa. Mude a gerência, ou a gerência da configuração, equipe de funcionários de sustentação, pode agir como a secretária.

Change advisory board (CAB)

Os deveres principais de um membro do CAB são alistados abaixo: revisão do · todo o RFCs submetido. Como apropriado, determine e forneça detalhes de seu impacto provável, dos recursos da execução, e dos custos ongoing de todas as mudanças. o · assiste a todas as reuniões relevantes do CAB ou do CAB/EC. Considere todas as mudanças na agenda e dê uma opinião em que as mudanças devem ser autorizadas. Participe em programar de todas as mudanças. · (CAB/EC somente). Esteja disponível para o consultation se uma mudança urgente for requerida. o · fornece o conselho à gerência da mudança em aspectos de mudanças urgentes propostas.

8.6 Planning and implementation

Tenha uma vez que mais o conselho que mudam os processos da gerência se for apropriado ao tamanho de sua organização e que processos fazendo vontade sobre-burocrática diminua a eficácia de suas ações.

8.6.1 Designating the Change Manager role

Onde não há sistema de nenhuma gerência existente da gerência ou da configuração da mudança, a primeira etapa deve ser alocar a responsabilidade para o papel da gerência da mudança. Uma lista das responsabilidades é dada no parágrafo 8.5.14. A equipe de funcionários de sustentação pode ser requerida. Onde a gerência da mudança é executada como a parte de um processo mais largo da gerência da configuração, os papéis do gerente da mudança e do gerente da configuração podem ser combinados se a escala reservar. A primeira tarefa do gerente da mudança é concordar com a gerência do serviço com um objetivo do processo da gerência da mudança, e uma maneira de medir suas eficiência e eficácia. Os objetivos pessoais e os alvos do gerente da mudança devem ser baseados na indicação da missão e a eficiência e a eficácia do processo da gerência da mudança. A tarefa seguinte do gerente da mudança, conjuntamente com a gerência, é concordar o espaço processo da gerência da gerência e da configuração da mudança. As plantas devem ser feitas para assegurar-se de que o infrastructure e outros sistemas de gerência da mudança se estejam conectarados eficazmente. As autoridades da gerência da mudança em outras partes da organização devem ser envolvidas em ajustar acima estas relações, e o compromisso da gerência será needed assegurá-las trabalha.

8.6.2  Deciding on a Change Management system

É necessário decidir-se cedo sobre se o sistema da gerência da mudança e de gerência da configuração deve ser um sistema paper-based ou ferramenta-baseado. Os sistemas paper-based são inadequados para tudo exceto os sistemas muito os menores, e conseqüentemente recomenda-se fortemente que algum formulário da ferramenta do software support está usado, se disponível. A nota, entretanto, que o computador alternativo ou os procedimentos de escritório serão requeridos deve o sistema ferramenta-baseado preliminar ser unavailable devido à falha etc. da ferragem. Recomenda-se que registrar e a execução das mudanças estão feitas sob o controle de um sistema de gerência integrado da configuração, ou integrado ELE sistema de gerência do serviço. É conseqüentemente desejável selecionar uma ferramenta que integre a gerência da mudança e a gerência da configuração, ou pode ser realçado ou customised para fazer assim. A obtenção de instrumentos de apoio, ajustando acima os dados (isto é dados do inventário da configuração, autoridades etc. da mudança), e treinamento e familiarização de equipe de funcionários com os instrumentos de apoio deve ser terminada antes da execução.

8.6.3 Planning system reviews

As plantas devem ser feitas para as revisões da gerência da mudança e da gerência da configuração, o metrics, os relatórios da gerência e os exames descritos nos parágrafos 8.5.12 e 8.5.13 e na seção 8.7.

8.6.4 Implementation planning

Planear executar a gerência da mudança deve ser empreendido simultaneamente com a gerência da configuração e o planeamento da gerência da liberação. (idealmente, todos os processos da sustentação de serviço devem ser considerados holistically no outset, mesmo que phased execução podem no fato ocorrer.) As plantas devem ser feitas para trazer o sistema combinado gerência da gerência e da configuração da mudança no serviço. Estas plantas devem incluir a instalação e as plantas de teste para todo o software dirigem, assim como plantas do treinamento para a equipe de funcionários da

gerência da mudança, a outra equipe de funcionários, e os usuários. O material de publicity e todos os seminários devem ser preparados na prontidão para um lançamento da gerência da mudança. A ênfase deve ser colocada em vender os benefícios da gerência da mudança à equipe de funcionários e aos usuários.

8.6.5 Guidance

Dependências

Como indicado no parágrafo 8.6.2, os sistemas de gerência paper-based da mudança são inadequados para a maioria de sistemas, e assim que os instrumentos de apoio são requeridos normalmente. A seção 8.8 descreve as exigências para ferramentas de gerência da mudança e dá alguma informação nas ferramentas atualmente disponíveis. Um número de processos suportando são requeridos também para a gerência da mudança ser inteiramente eficazes. Estes incluem a gerência da gerência, da configuração do problema, a mesa do serviço e os processos da gerência da liberação, como descritos nos outros capítulos deste livro. O compromisso da gerência é requerido para assegurar-se de que os recursos adequados estejam feitos disponíveis, e para assegurar-se de também que um nível adequado da disciplina engendered entre toda a equipe de funcionários da gerência do serviço para impedir o circumvention de procedimentos da gerência da mudança. O treinamento de equipe de funcionários será requerido nos procedimentos novos da gerência da mudança e no uso de instrumentos de apoio. Os membros do CAB necessitarão também treinar nos papéis esperados deles. As fugas de exame necessitam ser construídas nas ferramentas e nos procedimentos de gerência da mudança para simplificar o processo de examinar o processo da gerência da mudança para a conformidade com seus procedimentos especificados. Os procedimentos que é improvável ser prático paralelo-funcionam sistemas de gerência da mudança, e assim, ao executar um sistema de gerência da mudança baseado em guias de ITIL, um cutover direto de qualquer sistema precedente é recomendado. Em alguns casos, pode ser possível funcionar abaixo um sistema existente whilst introduzindo e estendendo um método novo. Todas as mudanças que sejam iniciadas através de um sistema de gerência non-ITIL-non-ITIL-compliant existente da mudança, ou sem ser sujeitado à gerência da mudança, devem ser transferidas no sistema novo no tempo da execução. Todas as dificuldades iniciais com o sistema de gerência novo da mudança devem ser identificadas tão rapidamente quanto possível após a execução e ser resolvidas. Todos os instrumentos de apoio devem completamente ser testados antes que o ` vá vivo ', mas se houver algum problema com elas após a execução, pode ser necessário temporariamente revert aos métodos manuais, mesmo que estes sejam prováveis ser lentos e inefficient. Povoe-o gerência que a sustentação é recurso needed o CAB e dê-o o nível apropriado da autoridade, para promover o sistema de gerência da mudança, e para superar toda a resistência à gerência formalised da mudança. Os usuários e a consciência da equipe de funcionários dos procedimentos da gerência da mudança são essenciais. É importante fazer-lhe o espaço livre que estes procedimentos são imperativos, e fazê-lo difícil ou impossível para que as mudanças sejam executadas fora do sistema de gerência da mudança. Uma atribuição apropriada da responsabilidade é needed assegurar a qualidade do serviço. O gerente de serviço é a cabeça da equipe do serviço, e tem a responsabilidade total para a qualidade do serviço. O gerente da mudança é diretamente responsável, e requererá a sustentação, do gerente de serviço a fim assegurar-se de que o nível correto da importância esteja dado aos procedimentos da gerência da mudança. Seguir é necessário para assegurar a conformidade. Recomenda-se que um exame independente esteja realizado regularmente (ao menos anualmente) pelo grupo do exame de computador da organização para assegurar a conformidade com procedimentos da gerência da mudança. A participação dos contratantes é requerida para assegurar o adherence. É essencial assegurar-se de que os representantes dos contratantes (equipe de funcionários por exemplo da ferragem dos coordenadores, a ambiental ou da acomodação de manutenção) estejam cientes de, e aderir a, os procedimentos da gerência da mudança da organização. A execução do sincronismo não deve começar até que o sistema esteja pronto, o CAB é ajustada acima, e todos envolvida está ciente de e treinado nos procedimentos novos. Mude a gerência, na colaboração com gerência do nível de serviço, deva então liaise com outros gerentes e gerentes do usuário para ajustar uma data e uma hora da execução que tenham menos efeito adverso potencial na qualidade do serviço (por exemplo durante períodos do throughput baixo do trabalho). A execução de um sistema de gerência novo da mudança será mais fácil se puder ser cronometrada para permitir que a atividade da mudança seja ` congelado ' imediatamente antes e durante da execução. Isto não pode ser possível, entretanto, se o sistema novo estiver sendo introduzido para neutralizar os problemas que se levantam de um sistema de gerência existente mas inadequado da mudança. Programar regular das mudanças pode ser muito importante. A consideração séria deve ser dada à introdução de entalhes regulares da mudança do ` - as épocas em que as mudanças podem ser executadas com impacto mínimo em cima do serviço do usuário (por exemplo entre 1800hrs e 2000hrs em terças-feiras e em quinta-feira). Tais entalhes devem, naturalmente, ser concordados com os clientes e o usuário. Se testar das mudanças tivesse que ser realizado em um ambiente non-dedicated, a consideração pôde também ser dada à provisão de entalhes do teste do `. A gerência do serviço deve rever a eficiência e a eficácia do processo da gerência da mudança logo depois que o sistema de gerência da mudança foi trazido no uso (palavra um a três meses em seguida). As revisões regulares devem ocorrer cada dois a quatro meses até que a confiança esteja estabelecida que o sistema está funcionando satisfatoriamente. Subseqüentemente, a gerência do serviço deve rever o processo da gerência da mudança regularmente, e ao menos cada seis meses. Entre nestas revisões mais formais e mais programadas, o gerente da mudança deve monitora continuamente a eficácia e a eficiência da gerência da mudança. A freqüência sugerida da gerência que relata no status da gerência da mudança é como segue: · ao gerente da mudança: semanal ou mais freqüentemente, dependendo da qualidade e da estabilidade do · dos serviços ao diretor dcEla e aos gerentes sênior do usuário: · mensal aos comitês sênior do cliente: trimestral.

8.7  Metrics and management reporting

Os sumários regulares das mudanças devem ser fornecidos ao serviço, à gerência do cliente e do usuário. Os níveis de gerência diferentes são prováveis reque os níveis diferentes da informação, variando do gerente de serviço, que pode reque um relatório semanal detalhado, aos comitês de gerência sênior que são prováveis reque somente um sumário trimestral da gerência. Considere incluir os seguintes fatos e statistics em relatórios da gerência: · o número das mudanças executadas no período, no total e por CI, por tipo da configuração, por serviço, por · etc. uma avaria das razões para o · da mudança (pedidos de usuário, realces, exigências do negócio, reparos do serviço call/Incident/Problem, melhoria de procedures/training, etc.) o número do · que bem sucedido das mudanças o número das mudanças suportou-para fora, junto com o · das razões (por exemplo avaliação incorreta, configuração má) o número dos incidents seguidos às mudanças (quebradas para baixo em níveis da problema-severidade) e o · das razões (por exemplo avaliação incorreta, configuração má) o número do · de RFCs (e algumas tendências nas origens) o número de mudanças executadas reviu, e o tamanho de incidências elevadas do · das reservas da revisão (quebradas para baixo tempo excedente) de RFCs/PRs que relaciona-se a um CI (estes são dignos da atenção especial), dando às figuras do · das razões (por exemplo exigência de usuário temporária, componente frágil, configuração má) dos períodos precedentes (último período, o ano passado) para o · da comparação o número de RFCs rejeitou o · a proporção das mudanças executadas que não são (em total e quebrado para baixo por CI) reservas bem sucedidas da mudança do ·, quebradas para baixo por CI e pelo estágio no processo da gerência da mudança. A consideração necessita ser dada, no consultation com o cliente, à maneira em que a informação da gerência é apresentada. Em muitos casos, as porcentagens, e as respresentações gráficas ou pictorial, são mais significativas do que dados numéricos desencapados. A informação pode ser usada como uma base avaliando a eficiência e a eficácia do processo da gerência da mudança. Que este, é necessário filtre para fora os efeitos que são parte externa o controle direto da gerência da mudança. Para o exemplo, as mudanças freqüentes que afetam um CI particular podem ser um resultado do fragility desse artigo, e não devem refletir mal na gerência da mudança como o poder no início inferred. Similarmente, as mudanças freqüentes em facilidades do usuário podem refletir uma exigência de usuário ràpidamente da mudança. Uma vez que outra vez, é de valor fazer remissão recíproca a publicação do BSI um código de prática para ELA a gerência do serviço (PD0005), onde o seguinte está indicado: Os relatórios da gerência da mudança podem incluir todo o ou algum seguinte: o número do · do número do · dos pedidos da mudança e dos % do · das mudanças rejeitou o · das mudanças da emergência do · no número do · do status da mudança das mudanças que esperam a execução, perto: número proeminente do · do tempo do · da categoria do · de mudanças executadas, perto: o · componente das reservas e dos bottle-necks da mudança do · do serviço do · da configuração do · custa por o impacto do negócio do · dos sumários da mudança e do custo de mudanças do · das mudanças pela freqüência do · da área de negócio da mudança a CIs.

8.7.1 Auditing for compliance

Este parágrafo é uma lista de verificação para as organizações que desejam examinar seu processo da gerência da mudança (que usa o grupo do exame de computador das organizações, que é independent da equipe do serviço), para a conformidade aos procedimentos e ao conselho neste capítulo. Recomenda-se que tal exame está terminado ao menos anualmente, e pode-se ser requerido mais frequentemente, inicialmente ou onde os problemas particulares são evidentes. O exame deve incluir uma examinação dos seguintes artigos: · RFCs aleatòria selecionado - a mudança do normal, a urgente e a padrão das mudanças do · grava registros da revisão do · do · FSC dos minutos do CAB do · para RFCs aleatório e mudanças executadas. As verificações devem ser feitas para assegurar isso: o · todo o RFCs corretamente foi registrado, avaliado e actioned o · FSC foi aderido a, ou há uma razão boa porque não o · todos os artigos levantados em reuniões do CAB foi seguido acima e o · resolvido todas as revisões da mudança foi realizado no · do tempo todo o documentatio

8.8  Software tools

Para tudo mas o menor das organizações, uma ferramenta gerência-baseada configuração, umas capazes de armazenar todos os artigos relevantes da configuração (CIs), e os relacionamentos importantes entre eles, devem ser usadas. Tal ferramenta deve ter as seguintes facilidades: · RFCs e fotorreceptores armazenados em cima da mesma base de dados, em um · fàcilmente acessível do formato a abilidade de identificar o relacionamento entre o · de RFCs, de fotorreceptores e de CIs a potencialidade à ligação RFCs ao · dos projetos os meios identificar fàcilmente o outro CIs que será impactado sempre que uma mudança a qualquer CI específico é produção automática proposta do · dos pedidos para o impacto e a avaliação dos recursos aos proprietários do ` do · impactado de CIs a abilidade para que todo o pessoal autorizado submeta RFCs de seu próprio · do terminal ou da posição a abilidade aos pedidos dos progressos do ` através dos estágios apropriados da autorização e da execução e mantenha claramente registros deste · do progresso a abilidade de permitir Mudam gerência equipe de funcionários, mudança construtor, verificador, etc. adicionar texto a mudança registro · espaço livre definição de back-out procedimento os avisos automáticos de um · dos problemas da causa da mudança de todo o RFCs que excedem pré-especificarem períodos de tempo durante qualquer alerta automático do · do estágio para realizar revisões da geração automática executada do · das mudanças da gerência e para tender a informação que relaciona ao · das mudanças a abilidade de construir a produção automática do · das mudanças do · de FSCs uma característica de process/workflow. Uma escala das ferramentas está disponível que aos graus variando integre todos os cinco processos da sustentação de serviço.

Um toolset integrado é a opção recomendada mas posição livre os pacotes PC-BASEADOS da base de dados e de spreadsheet podem também ser usados registrar mudanças em muitos ambientes.

8.9 Impact of new technology

8.9.1 The business domain

Melhor que focalizando imediatamente na tecnologia, é melhor considerar o papel da gerência da mudança em proteger e em realçar processos críticos do negócio. Figura 8.6, série do perspective do negócio do ` ', ilustra um dilemma principal para os negócios dependentes dcEla. A gerência da mudança no passado foi associada com o quadrante esquerdo inferior da grade, onde o negócio e são alinhados amplamente. Cada vez mais, puder causar a mudança (tecnologia nova) ou permitir a mudança, toda a dependência crescente do negócio do quando ncEla. Enquanto a mudança controlando através da organização se torna mais difícil e enquanto os métodos para controlar programas e projetos emergem e estão refinados, assim que devem os processos da gerência da mudança espoused por BSI, CCTA e outro ajuda melhoram estas edições de gerência.

Figure 8.6 – The business perspective on ChangeClick here to view a larger version in a new browser window.

Figura 8.7 representa o excesso de quatro componentes principais que nós desejamos exercitar o controle da gerência da configuração. John que Zachman (um guru americano da gerência da configuração) propôs certos anos há isso, se desejasse seguir o exemplo de peritos da gerência da configuração tais como os domínios da aviação e da engenharia, a seguir negócio e ELE processa teria que ser definido a um excruciating e nível unprecedented do detalhe a fim ser controlado hitherto.

Figure 8.7 – The scope for extending Change Management and Configuration Management controlClick here to view a larger version in a new browser window.

A influência da gerência da gerência (e conseqüentemente da mudança) da configuração estenderia durante todo o negócio e ELA os domínios, fornecendo o benefício enorme mas requerendo também um investimento estratégico de dimensões nao inconsiderable do negócio. Em conseqüência, tornar-se-á cada vez mais importante para a gerência da mudança ser integrado inteiramente e influential na gerência da mudança principal. Já nós podemos ver o investimento nos métodos para controlar os programas da mudança do negócio e os projetos (PRINCE2 para o exemplo).

8.9.2 Technology

Quando biblioteca do infrastructure foi publicado primeiramente, o foco para a gerência da mudança devia ganhar o controle do cada vez mais um grande número ELE relacionou mudanças, a uma extensão causada pelo crescimento rápido da tecnologia. Dentro de alguns anos, o negócio tinha-se tornado dependente dcEle a um grau hitherto unprecedented tais que o crescimento rápido da tecnologia causava problemas principais para o negócio e ELE lados da organização. O crescimento do Internet é um exemplo principal deste. A notícia boa, entretanto, é que os princípios da gerência da mudança remanescem unchanged. O que mudou está na necessidade fazer processos muito mais eficazes e sensíveis ao ritmo rápido da mudança do negócio e da tecnologia). A sustentação das ferramentas do software do Internet evoluiu ràpidamente para acomodar algumas das introduções da sensibilidade e da eficácia. Um número de vendedores fornecem as ferramentas que se operam em um ambiente do Internet, com atualizar remoto de bases de dados centrais. Enquanto o World Wide Web e o Internet melhoraram o acesso à informação e são permitidos o negócio e ELE para expandir sua esfera da influência, a segurança dos dados transformou-se muito mais de um problema. Isto tem conduzir a um aumento da responsabilidade de gerentes da mudança para avaliar o impacto das mudanças na segurança e encontrar-se na necessidade da orientação (veja a gerência da segurança de ITIL - ISBN 0-11-330014-X). O desenvolvimento do software de aplicações uma outra área em que a gerência da mudança está começando a influenciar é especificação do desenvolvimento e de exigência do software de aplicações. O impacto das aplicações novas que funcionam em um ambiente vivo foi uma edição para o pessoal ITIL-treinado por muitos anos. Entretanto, seu papel no life-cycle do desenvolvimento era pela maior parte desconhecido - embora a sustentação do ciclo de vida do software do livro de ITIL (ISBN 0-11-330559-1) fosse publicada para cobrir o problema, a edição não estava altamente bastante na agenda dos fornecedores de serviço e conseqüentemente não foi ignorada pela maior parte até recentemente. As atividades principais da gerência da liberação são definidas no life-cycle da mudança; como com manutenção do software, os conceitos técnicos de um processo frequentemente ignorado (ou talvez um processo que seja difícil de descrever nos termos da importância ao negócio) podem ser vistos para ser da importância particular àqueles na linha dianteira da gerência do serviço. Isto é ilustrado em figura 9.1 no capítulo da gerência da liberação desta guia. Enquanto os controles apropriados da gerência da configuração são estendidos ao desenvolvimento do software de aplicações, assim que à influência da gerência da mudança espalhou à especificação de exigências. Especificações de exigências agora (se!) faça exame em edições de gerência do infrastructure do cliente no estágio do projeto. Assim fazendo, a gerência do infrastructure melhora não somente as possibilidades de operações vivas lisas de aplicações novas, mas reduz também o problema da manutenção (e a manutenção do software foi provado custar a muitos muitas vezes mais do que o custo do desenvolvimento).