ISO/IEC 20000 Foundation – Relacionamento entre os Processos de Controle

Relacionamento entre os Processos de Controle

Papel dos processos na implantação de um novo serviço:

Papel dos processos na implantação de um novo serviço

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Gerenciamento de Liberação e Implantação

Tem por objetivo distribuir uma ou mais mudanças em uma liberação dentro do ambiente de produção incluindo planejamento e documentação.

Gerenciamento de Liberação e Implantação

É importante que este processo esteja integrado aos processos de gerenciamento de configuração e gerenciamento de mudanças para que as liberações sejam coordenadas.

Termos e definições

Liberação – Agrupamento de um ou mais itens de configuração, novos ou modificados, implantados no ambiente de produção como resultado de uma ou mais mudanças.

Liberação

Principais atividades

Politica e planejamento de liberação – Desenvolvimento do plano de liberação, estratégia e orientações para as atividades seguintes.

Construção de liberação – Construção dos pacotes de liberação incluindo todas as ferramentas e documentos para a distribuição da liberação

Testes de aceitação – teste da liberação em um ambiente de produção simulado.

Revisão de prontidão da liberação – Avaliação dos resultados dos testes e decisão ir ou não ir a relação à liberação.

Informação para o gerenciamento de mudanças – Se não estiver pronto para a liberação, avisa o gerenciamento de mudanças.

Planejamento de distribuição (rollout):

• Detalhes da liberação física no ambiente de produção.
• Verificação se o ambiente está pronto para liberação.
• Prazos para distribuição e períodos para alocação de recursos.
• Comunicação e treinamento.
• Planos separados para diferentes locais (opcional).

Preparação para distribuição (rollout):

• Assegurar que todos os recursos incluídos no plano de liberação estão disponíveis.
• Pré-requisitos para o plano de remediação (back-out) precisam ser atendidos.

Distribuição (rollout) / instalação:

• Coordenação, documentação e fornecimento final das liberações.

Requisitos mínimos

O provedor de serviço deve estabelecer e entrar e acordo com o cliente sobre uma política de liberação que declare a frequência e os tipos de liberações.

O provedor de serviço deve planejar com o cliente e as partes interessadas a implantação de serviços ou componentes de serviço novos ou modificados no ambiente de produção.

O planejamento deve ser coordenado com o processo de gerenciamento de mudanças e incluir referência às requisições de mudanças, a erros conhecidos e problemas que estão sendo encerrados através da mudança.

O planejamento deve incluir as datas de implantação de cada liberação, assim como entregáveis e métodos de implantação.

O provedor de serviço deve documentar e entrar em acordo com o cliente acerca da definição de uma liberação emergencial. Liberações emergenciais devem ser gerenciadas de acordo com um procedimento de liberação documentado que possua interface com o procedimento de mudanças emergenciais.

Liberações devem ser construídas e testadas antes da implantação. Um ambiente de teste de aceitação controlado deve ser usado para criação e testes de liberação.

Os critérios de aceitação para liberação devem ser acordados com o cliente e as partes interessadas.

A liberação deve ser implantada no ambiente de produção de forma que a integridade do hardware, do software e de outros componentes do serviço seja mantida durante a implantação da liberação.

As atividades necessárias para reverter ou remediar uma implantação de liberação sem sucesso devem ser planejadas, e onde possíveis testadas. A implantação de uma liberação deve ser revertida ou remediada se não tiver sucesso. Liberações sem sucesso devem ser investigadas e ações acordadas tomadas.

O sucesso ou falha das liberações deve ser monitorado e analisado. As mensurações devem incluir incidentes relacionados com uma liberação no período seguinte a sua implantação.

As analises devem incluir avaliações do impacto da liberação no cliente. Os resultados devem incluir avaliações do impacto da liberação no cliente. Os resultados e conclusões derivados das analises devem ser registrados e analisados criticamente para identificar oportunidades de melhorias.

Informações sobre o sucesso ou falhas nas liberações e datas de liberações futuras devem ser fornecidas ao processo de gerenciamento de mudanças e ao processo de gerenciamento de incidentes e requisição de serviço.

Informações devem ser fornecidas para o processo de gerenciamento de mudanças para apoiar as avaliações de impacto de requisições de mudanças para liberações e planos de implantação.

Práticas recomendadas

Politica de liberação

Convém que uma politica de liberação cubra pelo menos os seguintes aspectos:

• Frequência e natureza da liberação.
• Papéis e responsabilidades neste processo.
• Corpo para tomada de decisão para transferir do ambiente de teste de aceite para o de produção.
• Identificação e descrição das liberações de forma clara.
• Abordagem para construção de mudanças em forma de uma liberação.
• Abordagem para automatização dos processos de construção, liberação e instalação da liberação para apoiar a repetitividade e eficiência.
• Verificação e aceitação da liberação.

Planejamento da liberação e da implantação

Convém assegurar que os itens de configuração que estão para ser liberados sejam compatíveis uns com os outros e com itens de configuração no ambiente de produção.

Os seguintes aspectos convêm ser considerados:

• Data de liberações e descrição do trabalho relacionado.
• Mudanças, problemas, erros conhecidos associados e novos erros conhecidos descobertos durante os testes.
• Processos associados para implementar a liberação através de todas as unidades da organização.
• Processo de verificação e aceitação.
• Comunicação, preparação, documentação e treinamento para os cliente e pessoal de suporte.
• Logística e processo para compra, armazenamento, descarte, etc.
• Recursos de suporte necessários.
• Identificação de dependências e riscos associados.
• Encerramento formal de liberação.
• Planejamento de possíveis auditorias.

Desenho, construção e configuração de liberação.

Convém que a liberação e distribuição sejam desenhadas e implementadas para alcançar os seguintes objetivos:

• Estar em conformidade com os padrões do provedor de serviços.
• Assegurar a integridade durante todas as fases da liberação.
• Usar bibliotecas de software autorizadas (BMDs) e repositórios de peças.
• Identificar claramente os riscos e implementar medidas de remediação.
• Verificar a plataforma de destino de uma liberação.
• Verificar que uma liberação está completa após a transferência.

Os processos de construção, instalação, liberação e distribuição podem ser automatizados para reduzir erros, assegurar que o processo é reproduzível e que novas liberações possam ser implementadas rapidamente.

Verificação e aceitação da liberação

Convém que cada liberação receba um aceite formal por parte de uma pessoa autorizada.

Convém que o processo de verificação e aceitação:

• Verifique que o ambiente de teste corresponde ao ambiente de produção.
• Assegure que a liberação foi criada a partir de ICs controlados.
• Verifique a execução de testes apropriados.
• Assegure que os testes foram conduzidos para satisfazer o negocio e a TI.
• Assegure que uma autoridade de liberação aprova cada estágio de testes de aceitação.
• Verifique, antes da instalação, que a plataforma de destino atende aos requisitos de hardware e software.
• Verifique que uma liberação está completa após a implantação.

Documentação

Convém fornecer documentação adequada sob o controle do gerenciamento da configuração. Esta documentação inclui:

• Documentação de apoio, como por exemplo, Acordos de nível de serviço.
• Procedimentos de instalação e suporte, ferramentas de diagnostico, instruções de operação e administração.
• Procedimentos de construção, liberação, instalação e implantação.
• Planos de contingencia e retorno.
• Planos de treinamento para TI e negocio.
• Linha de base de configuração, com ICs associados.
• Mudanças, problemas e erros conhecidos associados.
• Evidência de autorização para liberação.
• Evidência relacionada à verificação e à aceitação.

Convém que detalhes de erros conhecidos sejam comunicados para o gerenciamento de incidentes.

Se a liberação for rejeitada, postergada ou cancelada, convém que o gerenciamento de mudanças seja informado.

Implantação, distribuição e instalação.

Convém que os processos de implantação, distribuição e instalação assegurem que:

• Todas as áreas de armazenamento de hardware e software são seguras.
• Existam procedimentos apropriados para armazenamento, entrega recepção e descarte.
• Sejam planejadas e conduzidas verificações nas instalações, equipamentos e sistemas elétricos.
• Todas as partes interessadas sejam informadas sobre novas liberações.
• Produtos, serviços e licenças redundantes sejam desativados.

Após a distribuição de software na rede, é essencial verificar se a liberação está completa e operacional.

Convém que após completar com sucesso a instalação, todos os ICs sejam atualizados com local e proprietário.

Convém que os resultados do aceite e questionários de avaliação de satisfação sejam realimentados para o gerenciamento de relações de negócio.

Pós-liberação e implantação

Convém que incidentes relacionados a liberações sejam após a implementação.

Convém que o gerenciamento de mudanças realize uma revisão pós-implementação.

Recomendações a partir desta revisão podem ser incluídas no plano de melhoria de serviço (PMS).

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Gerenciamento de Mudanças

Tem como objetivo assegurar que todas as mudanças sejam avaliadas, aprovadas, implementadas e revisadas de maneira controlada.

Gerenciamento de Mudanças

Termos e definições

Requisição de mudança (RDM) – Proposta para uma mudança a ser feita em um serviço, componente de serviço ou sistema de gestão de serviços. Uma mudança para um serviço inclui a provisão de um serviço novo ou a remoção de um serviço que não é mais requerido.

Registro de mudança – Um registro contendo os detalhes de uma mudança.

Mudança emergencial – Uma mudança que deve ser introduzida assim que possível, por exemplo, para resolver um incidente grave ou implementar uma correção de segurança.

Risco – Um evento possível que pode causar perdas ou danos, ou afetar a habilidade de atingir objetivos.

Cronograma de mudanças – Um documento que lista todas as mudanças autorizadas e as suas datas de implementação planejada, além das datas estimadas para mudanças de longo prazo.

Principais atividades

• Registrar – Todas as RDMs.
• Revisar e filtrar – Decidir sobre aceitar uma RDM por meio de um critério formal definido.
• Classificar – Prioridade (impacto x urgência) / Categoria (com base nos riscos).
• Autorizar e planejar – Autorizar para desenvolvimento, orçamento e planejamento de recursos.
• Coordenar – Coordenar o desenvolvimento e liberação de mudanças.
• Avaliar e encerrar – Revisão pós-implementação e encerramento formal da mudança.

Requisitos mínimos

Uma politica de gerenciamento de mudanças deve ser estabelecida definido:

• ICs que estão sob o controle do gerenciamento de mudanças.
• Critérios para determinar mudanças com potencial para causar um impacto significativo nos serviços ou no cliente.

A remoção de um serviço deve ser classificada como uma mudança com potencial de impacto significativo.

A transferência de um serviço do provedor de serviço para o cliente ou para outra parte deve também ser classificada como uma mudança com potencial para um impacto significativo.

Deve haver um procedimento documentado para registrar, classificar, avaliar e aprovar requisições de mudanças.

O provedor de serviço deve documentar e entrar em acordo com o cliente acerca da definição de uma mudança emergencial.

Deve haver um procedimento documentado para gerenciar mudança emergencial.

Todas as mudanças em um serviço ou componente de um serviço devem ser criadas utilizando uma requisição de mudança. As requisições de mudança devem ter um escopo definido.

Todas as requisições de mudança devem ser registradas e classificadas.

Requisições de mudanças classificadas com potencial para causar um impacto significativo nos serviços e no cliente devem ser gerenciadas utilizando o processo de desenho e transição de serviços novos ou modificados. Todas as outras requisições de mudança em ICs definidos na politica de gerenciamento de mudanças devem ser gerenciadas através do processo de gerenciamento de mudanças.

Requisições de mudança devem ser avaliadas utilizando informações sobre o processo de gerenciamento de mudanças e outros processos.

O provedor de serviço e as partes interessadas devem tomar decisões com respeito à aceitação das requisições de mudança.

A tomada de decisão deve levar em consideração os riscos, impactos, potenciais no serviço e no cliente, requisitos do serviço, benefícios para o negocio, viabilidade técnica e impacto financeiro.

Mudanças aprovadas devem ser desenvolvidas e testadas.

Um cronograma de mudanças contendo os detalhes das mudanças aprovadas e as datas propostas para implantação devem ser estabelecidas e comunicadas para as partes interessadas. O cronograma de mudanças deve ser usado como base para planejamento e implantação de liberações.

As atividades necessárias para reverter ou remediar uma mudança sem sucesso devem ser planejadas e onde possível testada. A mudança deve ser revertida ou remediada quando não tiver sucesso. Mudanças sem sucesso devem ser investigadas e ações acordadas devem ser tomadas.

Os registros da DBGC devem ser atualizados apis a implantação bem sucedida das mudanças.

O provedor de serviço deve analisar criticamente a eficácia das mudanças e tomar ações em comum acordo com as partes interessadas.

Requisições de mudança devem ser analisadas em intervalos planejados para detectar tendências. Os resultados  e conclusões derivados dessas analises devem ser registrados e analisados criticamente para identificar oportunidades de melhoria.

Práticas recomendadas

Planejamento e implementação

Convém que o processo e procedimento de gerenciamento de mudanças assegurem que:

• Mudanças tenham um escopo claramente definido e documentado.
• Apenas mudanças com beneficio para o negocio sejam aprovadas.
• Mudanças sejam planejadas com base na prioridade e no risco potencial.
• Mudanças na infraestrutura sejam verificadas tecnicamente e qualitativamente durante a sua implementação.

Convém que a situação e datas da programação de implementação sejam utilizadas como base para a programação de mudanças e liberações.

Convém que a informações sobre programação esteja disponível para as pessoas afetadas pela mudança.

Onde uma parada pode acontecer, durante o horário normal de serviço, convém que as pessoas concordem com a mudança antes da implementação.

Encerramento e análise crítica da requisição de mudanças

Convém que uma análise critica pós-implementação seja feita para todas as mudanças significativas para verificar se:

• A mudança atingiu seus objetivos.
• Os clientes estão satisfeitos com os resultados.
• Não houve efeitos colaterais inesperados.

Mudanças emergenciais

Sempre que possível seguir o fluxo normal deste processo.

Certos aspectos podem ser documentados posteriormente.

Se porventura uma mudança emergencial não cumprir os requisitos obrigatórios deste processo, é necessário coloca-la em conformidade com estes requisitos assim que seja possível.

Convém que estas mudanças sejam justificadas pelo implementador e testadas após a mudança.

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Gerenciamento da Configuração

Tem como objetivo definir e controlar os componentes de serviços e infraestrutura e manter informação precisa da configuração.

Gerenciamento da Configuração

Visão da infraestrutura

A partir das informações levantadas pelo gerenciamento da configuração será possível ter uma visão dos diversos componentes que sustentam um serviço de TI oferecido a um determinado cliente e como estes componentes se relacionam entre si.

Interfaces principais

Muitos processos se beneficiam das informações fornecidas pelo gerenciamento da configuração, principalmente:

Gerenciamento de mudanças: para avaliar impactos.

Gerenciamento de liberação e implantação: para fazer rollout (distribuição) e o rollback (retrocesso).

Termos e definições

Item de configuração (IC) – É um elemento que necessita ser controlado para entregar um serviço ou serviços.

Atributo – Uma informação sobre um item de configuração. Exemplos: nome, localização, número de versão e custos.

Componente de serviço – Unidade de um serviço que, quando combinada com outras unidades, entregará um serviço completo.

Exemplos: hardware, software, ferramentas, solicitações, documentações, informação, processos ou serviços de suporte. Um componente do serviço pode consistir de em um ou mais itens de configuração.

Base de dados de gerenciamento de configuração (BDGC) – Dados armazenados para registrar atributos de itens de configuração e os relacionamentos entre itens de configuração durante o seu ciclo de vida.

Base de referencia de configuração – Informação de configuração formalmente designada em um momento específico durante a vida do serviço ou componente do serviço. Bases de referencia de configuração, mais mudanças aprovadas para estas bases de referência, constituem a informação de configuração atual.

Biblioteca de mídia definitiva (BMD) – Uma ou mais localidades em que as versões definitivas e autorizadas de todos os itens de configuração de software são armazenadas de maneira segura. A biblioteca de mídia definitiva também pode conter itens de configuração associados, como licenças e documentação.

Principais atividades

Planejamento:

• Objetivos para a BDGC (por exemplo: quais processos precisam ser suportados e como?)
• Escopo da BDGC.

Identificação de IC:

• Definir tipos de IC, convenções de nome, versionamento.

Registro e controle:

• Registrar novos ICs.
• Atualizar ICs existentes.

Acompanhamento de status (reporte):

• Registrar/atualizar status do ciclo de vida de cada IC.

Verificação/Auditoria:

• Verificar em intervalos planejados se as informações condizem com a realidade.

Requisitos mínimos

Deve haver uma definição documentada de cada tipo de IC. A informação registrada para cada IC deve assegurar um controle eficaz e incluir no mínimo:

• Descrição do IC
• Relacionamento entre IC e outros ICs.
• Relacionamento entre o IC e componentes do serviço.
• Situação.
• Versão.
• Requisições de mudanças associadas.
• Problemas e erros conhecidos associados.

Os ICs devem ser identificados de forma única, e ser registrados na BDGC.

Deve haver um procedimento documentado para o registro, controle e rastreamento de versões dos ICs.

O provedor de serviço deve auditar os registros armazenados na BDGC, em intervalos planejados.

Informações da BDGC devem ser fornecidas ao processo de gerenciamento de mudanças para dar apoio à avaliação de requisições de mudança.

Mudanças nos ICs devem ser rastreáveis e auditáveis.

Uma base de referencia de configuração dos ICs afetados deve ser extraída antes da implantação de uma liberação no ambiente de produção.

Cópias-mestre dos ICs registrados na BDGC devem ser armazenadas em bibliotecas físicas ou eletrônicas seguras.

Deve haver uma interface definida entre o processo de gerenciamento de configuração e o processo de gerenciamento dos ativos financeiros.

Práticas recomendadas

Convém que todos os ativos e configurações mais importantes sejam atribuídos a um gerente responsável, que assegure segurança e controle adequados. Isto irá assegurar que, antes da implementação de mudanças no IC, à permissão seja concedida.

Para atender aos requisitos obrigatórios do processo de gerenciamento de configuração, as seguintes recomendações podem ser adotadas:

Planejamento e implementação

• Convém estabelecer uma integração com os processos de gerenciamento de mudanças e gerenciamento de liberação e implementação.
• Convém elaborar um plano de configuração considerando:
• Escopo, objetivos, politicas, papeis, padrões e responsabilidades.
• Descrição dos processos para definição e controle de mudanças dos ICs.
• Requisitos para responsabilidade final, rastreabilidade e capacidade de ser passível de auditoria – por exemplo, para fins de segurança, legais, regulatórios ou de negócios.
• Controle de configuração (controles de acessos, proteção, versão, etc.).
• Interfaces nos processos de controle entre organizações participantes (fornecedores, clientes).
• Planejamento e estabelecimento de recursos para manter os ativos sob o controle e manter o sistema de gerenciamento da configuração.
• Gerenciamento de fornecedores que realizam gerenciamento de configuração.

Identificação da configuração

Convém que todos os itens de configuração sejam identificados de forma única.

Convém que os itens a serem gerenciados sejam identificados utilizando critérios selecionados e que incluam:

• Documentação relacionada aos sistemas e softwares (especificações, desenho, revisões, etc.).
• Bases de referência e descrições de construção por ambiente.
• Biblioteca eletrônica (BMD) na qual estão salvas as cópias-mestre.
• Licenças.
• Componentes de segurança (por exemplo: firewalls).
• Ativos físicos que precisam ser rastreados pelo gerenciamento de ativos da organização.
• Documentação relacionada ao serviço, como ANSs e procedimentos.
• Instalações de apoio, como eletricidade para o CPD.
• Relacionamentos e dependências entre ICs.

Para cada tipo de IC, o desenvolvimento detalhado da BDGC, seus atributos e relacionamentos precisam ser definidos. Atributos são usados para armazenar informações relevantes para aquele tipo de IC.

Exemplos de atributos:

• ID
• Número de série
• Modelo
• Fabricante
• Categoria/tipo
• Local
• Versão
• Proprietário responsável
• Licença
• Data de aquisição
• Data de expiração da garantia
• Fornecedor
• Data de aceitação
• Status
• Custo aquisição
• Valor após depreciação
• Comentários

Controle da configuração

A informação de configuração deve ser atualizada constantemente para que ela possa ser útil para a tomada de decisões no gerenciamento de mudanças.

Este processo deve garantir que apenas ICs identificados e autorizados sejam aceitos e registrados, desde o recebimento até o descarte.

Acompanhamento do status

Convém que registros de configuração reflitam as mudanças (status, localização e versão).

Convém que o registro de status forneça informações sobre o histórico atual e passado, relacionando a cada item de configuração durante o seu ciclo de vida.

Convém que relatórios de configuração sejam disponibilizados para todas as partes.

Verificação e auditoria

Convém que processos de verificação e auditoria da configuração, tanto física como funcional, sejam programados – e que uma verificação seja feita para assegurar que existem processos e recursos adequados para:

• Proteger as configurações físicas e o capital intelectual da organização.
• Assegurar que o fornecedor de serviços tem controle de suas configurações, cópias dos originais e licenças.
• Fornecer confiança de que a informação de configuração é exata, controlada e visível.
• Assegurar que uma modificação, uma liberação, um sistema ou um ambiente estão em conformidade com seus requisitos contratados ou especificados, e que os registros são exatos.

Convém que auditorias de configuração sejam feitas regularmente, antes e depois de mudanças significativas, depois de desastres e em intervalos aleatórios.

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Processos de Controle

Os processos de controle servem para gerenciar as informações relacionadas à configuração (ICs) e a mudança de forma que mudanças possam ser implementadas no ambiente de produção de maneira adequada e com menos riscos para a organização.

Processos de Controle

Os processos de controle criam condições essenciais para uma operação de serviço de TI estável e segura, por meio de um bom gerenciamento de inventário de TI e assegurando que mudanças sejam bem coordenadas dentro da TI.

Processos de Controle

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Gerenciamento de Problemas

Tem por objetivo minimizar a interrupção da organização através da identificação e análise proativa da causa de incidentes e através do gerenciamento dos problemas até seu encerramento.

Gerenciamento de Problemas

Este processo previne pro ativamente a recorrência de incidentes.

Abaixo, alguns termos e definições:

Problema: Causa raiz de um ou mais incidentes. A causa raiz não é usualmente conhecida na hora de um registro do problema é criado, e o processo de gerenciamento de problemas é responsável por futuras investigações.

Registro de problema: Um registro contendo os detalhes de um problema. Cada registro de problema documenta o ciclo de vida de um único problema.

Erro conhecido: Um problema que possui causa raiz e solução de contorno documentado. Podem ser criados por este processo e também são identificados por desenvolvedores e fornecedores.

Principais atividades para o processo de gerenciamento de problemas:

• Detecção de problemas.
• Registro de problema.
• Categorização.
• Priorização.
• Investigação e diagnostico.
• Determinação de soluções de contorno, se possível.
• Criação de registro de erro conhecido.
• Abertura de requisição de mudança, se requerida.
• Resolução.
• Revisão de problema grave.

Análise de tendências

Uma análise de dados é feita para identificar padrões ao longo do tempo.

A análise de tendência é usada no gerenciamento de problemas para identificar falhas frequentes ou itens de configuração que deixam de funcionar com facilidade e, em gerenciamento de capacidade, como uma ferramenta de modelagem para prever comportamento futuro.

Exemplos de dados analisados:

• Sistema de ticket: numero de incidentes similares.
• Ferramentas de monitoração: picos de utilização de recursos.

Exemplos de padrões ao longo do tempo:

Toda segunda feira entre as 7h e 9h há um acúmulo notável de registros de incidentes de rede. Identificação de problema (gerenciamento de reativo de problemas a partir da existência de incidentes).

Todos os dias entre 2h e 5h há um pico de uso do processador de um determinado aplicativo critico para o negócio. Identificação de problema (gerenciamento proativo de problemas para evitar que incidentes ocorram).

Requisitos mínimos:

Deve haver um procedimento documentado para identificação de problemas e minimizar ou evitar o impacto de incidentes e problemas. O procedimento para os problemas deve definir:

• Identificação
• Registro
• Alocação de prioridade
• Classificação
• Atualização dos registros
• Escaladas
• Resolução
• Fechamento

Problemas devem ser gerenciados de acordo com o procedimento.

O provedor de serviço deve analisar dado e tendências de incidentes e problemas para identificar causa-raiz e suas potenciais ações preventivas.

Problemas que exigem mudanças em um IC devem ser resolvidos por meio de uma requisição de mudança.

Onde a causa raiz tenha sido identificada, mas o problema não tenha sido resolvido permanentemente, o provedor de serviço deve identificar as ações para reduzir ou eliminar o impacto do problema sobre os serviços. Erros conhecidos devem ser registrados.

A eficácia da resolução do problema deve ser monitorada, analisada criticamente e reportada.

Informações atualizadas sobre erros conhecidos e resoluções de problemas devem ser fornecidas ao processo de gerenciamento de incidentes e requisições de serviço.

Escopo do processo – Práticas recomendadas

• Recomenda-se que processo identifique as causas raiz de incidentes e pro ativamente previna sua recorrência.
• Os incidentes devem ser classificados para ajudar a determinar as causas dos problemas. A classificação pode referenciar problemas existentes e futuras mudanças.

Encerramento de problemas – Práticas recomendadas

Recomenda-se fazer as seguintes verificações ao encerrar o registro de problema:

• Os detalhes da resolução foram documentados de forma correta?
• A causa foi categorizada para facilitar análise futura?
• O cliente e a equipe de suporte foram informados da resolução do problema?
• O cliente foi informado se nenhuma resolução foi alcançada?

Resoluções finalizadas precisam ser verificadas em relação a sua eficácia. Em particular:

• Identificar tendências, tais como problemas e incidentes recorrentes, defeitos, erros.
• Erros conhecidos em liberações planejadas.
• Compromisso das equipes envolvidas em resolver incidentes e problemas.

Gerenciamento proativo de problemas – Práticas recomendadas:

• Com medidas proativas, a ocorrência de incidentes e problemas pode ser reduzida. A prevenção de problemas pode levar a medidas preventivas de incidentes individuais, tais como dificuldades repetidas em uma funcionalidade particular de um sistema, até decisões estratégicas.
• As medidas preventivas no contexto do gerenciamento de problemas podem incluir o treinamento de usuários, os quais podem causar incidentes devido à falta de conhecimento no uso de um serviço.

A figura abaixo apresenta as principais interfaces do gerenciamento de problemas:

Principais interfaces do gerenciamento de problemas

Identificando as possíveis principais diferenças entre os processos de gerenciamento de incidente e gerenciamento de problemas utilizando como apoio a seguinte tabela:

Diferença	Gerenciamento de incidentes	Gerenciamento de problemas
Intenção do processo	Restaurar a operação normal do serviço o mais rápido possível	Minimizar/evitar incidentes (e problemas) e seus impactos
Foco (reativo ou proativo)	Mais reativo	Reativo e proativo
Escalas de tempo requeridas para resolução e encerramento (menor ou maior?).	Menor	Geralmente são maiores
Principais responsáveis além do dono e gerente de processo	Central de serviço (registro, diagnóstico inicial, comunicação), grupos de resolução (nível 2 e 3), fornecedores externos	Central de serviço (pode registrar o problema), grupos técnicos (análise da causa raiz e desenvolvimento de soluções)
Impacto na satisfação do cliente	Pode impactar negativamente a satisfação do cliente se não resolver prontamente	Pode impactar positivamente a satisfação do cliente se incidentes repetitivos forem removidos

 

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Gerenciamento de Incidentes e Requisições de Serviço

Tem por objetivo restaurar o mais rápido possível os serviços acordados com a organização, ou responder às requisições de serviço.

Gerenciamento de Incidentes e Requisições de Serviço

Este processo pode ser entregue pela central de serviços, que funciona como ponto de contato do dia a dia com os usuários.

Abaixo, alguns termos e definições:

Incidentes: interrupção não planejada de um serviço, uma redução na qualidade do serviço ou um evento que ainda não impactou o serviço do cliente.

Requisição de serviço: requisição de informação, aconselhamento, acessa a um serviço ou uma modificação pré-aprovada.

Registro de incidente: um registro contendo detalhes de um incidente. Cada registro documenta o ciclo de vida de um incidente único.

Prioridade: determina a velocidade da resolução e é baseada em impacto e urgência.

Impacto: uma medida do efeito de um incidente, problema ou mudança em um processo do negócio.

Urgência: uma medida de quanto tempo um incidente ou problema irá levar até que tenha um impacto significativo no negocio. Por exemplo, um incidente de alto impacto pode ter urgência baixa se o impacto não afetar o negocio até o final do ano financeiro.

Escalação ou escalada: procedimento para encaminhar um incidente ou problema para outro nível. Pode ser funcional ou hierárquica.

Solução de contorno: serve para reduzir ou eliminar o  impacto de um incidente para o qual a resolução completa não é ainda possível. Soluções de contorno para incidentes que não estão associadas aos registros de problema são documentadas no registro de incidente.

Principais atividades:

É importante que o processo de gerenciamento de incidentes e requisições de serviço seja suportado por procedimentos separados: um para lidar com incidentes e outro para requisições de serviço. Convém que estes procedimentos considerem as atividades abaixo:

Registro: descrição de sintomas/detalhes de incidentes ou requisições de serviço, criação do ticket (registro).

Priorização e classificação: priorização e classificação de incidentes e requisições de serviço são baseadas em metas de serviço documentadas.

Resolver ou atender/atualização de registros: se possível resolver no primeiro nível de suporte (central de serviço). Atualizar registros durante o progresso.

Escalar: escalar conforme apropriado para assegurar a resolução ou atendimento de cada incidente ou requisição de serviço.

Encerrar: atualizar e encerrar os registros de incidente ou requisição de serviço após a confirmação do usuário.

Requisitos mínimos:

Deve existir um procedimento documentado para todos os incidentes, que defina:

• Registro
• Definição de prioridade
• Classificação
• Atualização dos registros
• Escaladas
• Resolução
• Encerramento

Deve existir um procedimento documentado para gerenciar o cumprimento das requisições de serviço desde seu registro até o seu encerramento.

Ao priorizar incidentes e requisições de serviços, o provedor de serviço deve levar em consideração o impacto e urgência dos incidentes e requisições de serviço.

O provedor de serviço deve garantir que o pessoal envolvido no gerenciamento dos processos de incidentes e requisições de serviço tenha acesso e utilize informações relevantes. Informações relevantes devem incluir procedimentos de gerenciamento de requisições de serviços, erros conhecidos, resolução de problemas e BDGC.

Informações sobre o sucesso ou falha das liberações e sobre as futuras datas de liberações, provenientes do processo de gerenciamento de liberação e implantação, devem ser utilizadas pelos processos de gerenciamento de incidentes e requisições de serviço.

O provedor de serviço deve manter o cliente informado do progresso dos seus incidentes relatados ou requisições de serviço. Se as metas de serviço não puderem ser alcançadas, o provedor de serviço deve informar o cliente e partes interessadas e escalar de acordo com o procedimento.

O provedor de serviço deve documentar e acordar com o cliente a definição de um incidente grave. Incidentes graves devem ser classificados e gerenciados de acordo com um procedimento documentado. A alta direção deve assegurar que uma pessoa seja designada como responsável pelo gerenciamento dos incidentes graves. Depois que o servi acordado for restaurado, incidentes graves devem ser analisados criticamente para identificar oportunidades de melhoria.

Práticas recomendadas:

Convém que os procedimentos para o processo gerenciamento de incidentes e requisições de serviço definam mecanismos para receber incidentes e requisições de serviço.

Convém que todos os incidentes sejam classificados para que possam ser tomadas as providências de acordo com as suas prioridades e metas de serviço assumidas. A classificação pode incluir quais ICs foram impactados, os quais podem ajudar a identificar o pessoal que precisa ser envolvido na resolução ou atendimento.

Convém que a prioridade seja acordada com o cliente no recebimento de um incidente ou requisição de serviço ou no decorrer da sua resolução/atendimento.

Uma matriz de prioridades pode ser desenvolvida tanto para incidentes como para requisições de serviços.

Convém que os seguintes sejam definidos como parte do processo gerenciamento de incidentes e requisições de serviço:

• Fontes de entrada
• Responsabilidades para criação e atualização dos registros
• Fontes de informação
• Interface com o processo gerenciamento de problemas
• Regras para escalação
• Interface com o gerenciamento de mudanças
• Responsabilidades para resolução ou atendimento e encerramento dos registros

Sem a confirmação efetiva do serviço por parte do usuário ou cliente, o provedor de serviço pode presumir de forma equivocada que o incidente ou resolvido ou que a requisição de serviço foi atendida.

Incidentes Graves – Práticas recomendadas:

Convém que o processo de gerenciamento de incidentes e requisições de serviço inclui um procedimento documentado para tratar incidentes graves. Um incidente grave geralmente implica em alto impacto e atenção especial requerida para resolvê-lo.

Este procedimento pode definir:

• Definição do que constitui um incidente grave.
• Quem tem autoridade para declarar um incidente grave e como isto será feito.
• Quem coordenará as atividades e em que será envolvido.
• Como os esforços de resolução serão conduzidos.
• Quais comunicações precisam ser fornecidas durante estes incidentes.
• Formato, prazos e participantes requeridos para a revisão após a resolução.

 

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Processos de Resolução

Os processos de resolução têm por objetivo incluir o gerenciamento de incidentes e requisições de serviço e o gerenciamento de problemas. São processos separados, no entanto intimamente ligados.

O gerenciamento de incidentes e requisições de serviços lida com a restauração dos serviços e/ou atendimento de requisições de serviço de usuários, enquanto o gerenciamento de problemas procura determinar e remover a causa de incidentes, assegurando assim uma infraestrutura mais estável e confiável.

Processos de Resolução

A ISO/IEC 20000-1 não especifica a função central de serviço como um requisito obrigatório, mas o seu estabelecimento é uma boa pratica na ISO/IEC 20000-2.

Central de Serviços: é o ponto único de contato entre o provedor de serviço e os usuários. Uma central de serviço típica gerencia incidentes, requisições de serviço e também a comunicação com os usuários.

A central de serviços pode apoiar várias atividades, como:

• Registrar detalhes relevantes para incidentes e requisições de serviço, alocar códigos de categorização e priorização.
• Fornecer investigação e diagnósticos de primeiro nível.
• Resolver incidentes e requisições de serviço para os quais estiver habilitada.
• Escalar incidentes e requisições de serviço que não puderem ser resolvidas dentro de tempos acordados.
• Manter usuários informados do progresso.
• Encerrar todos incidentes e requisições de serviço resolvidas e outras chamadas.
• Conduzir pesquisas de satisfação de cliente/usuários.
• Manter comunicação com usuários (notificar mudanças agendadas, por exemplo).
• Atualizar a BDGC sob aprovação do gerenciamento de configuração, se isto for acordado.

 

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Gerenciamento de Fornecedores

Seu objetivo é gerenciar os fornecedores para assegurar a provisão e a qualidade de serviços de forma transparente e com qualidade.

Gerenciamento de Fornecedores

Segue abaixo alguns termos e definições:

• Fornecedor – Organização ou parte de uma organização que externa à organização do provedor de serviço, regida por um contrato com o provedor de serviço para contribuir com desenho, transição, entrega e melhoria de um serviço ou serviços ou processos.
• Fornecedor-líder: Um fornecedor que obtém partes de serviços entregues a partir de um terceiro.
• Fornecedor subcontratado: Fornecedores de um fornecedor-líder.
• Contrato: Documento que estabelece as obrigações entre as partes.

Principais atividades:

• Identificar um responsável para cada contrato.
• Alinhar contratos com ANSs.
• Acordar e gerenciar contratos.
• Gerenciar o relacionamento com fornecedores.
• Revisar o desempenho dos fornecedores.

Gerenciamento de Fornecedores – Requisitos mínimos:

• Para cada fornecedor, o provedor de serviço deve designar um individuo (gerente de contrato) para ser o responsável pelo gerenciamento de relacionamento, contrato e desempenho do fornecedor.
• O provedor de serviço deve acordar com os níveis de serviço do fornecedor para dar suporte e alinhar com os ANSs entre o provedor de serviço e o cliente.
• O provedor de serviço deve garantir que os papéis e relações entre fornecedores líderes e subcontratados estejam documentados. O provedor de serviço deve verificar se os fornecedores líderes estão gerenciando seus fornecedores subcontratados para que cumpram suas obrigações contratuais.
• O provedor de serviço deve monitorar o desempenho do fornecedor em intervalos planejados. O desempenho deve ser medido em relação às metas de serviços e outras obrigações contratuais. os resultados devem ser registrados e analisados criticamente para identificar as causas de não conformidade e as oportunidades de melhoria. A revisão deve também garantir que o contrato reflita os requisitos atuais.
• Mudanças no contrato devem ser controladas pelo processo de gerenciamento de mudanças.
• Deve existir um procedimento documentado para gerenciar os desacordos contratuais entre o provedor de serviço e o fornecedor.

O provedor e o fornecedor devem entrar em acordo sobre um contrato documentado. O contrato deve conter ou incluir uma referencia para:

• O escopo dos serviços a serem entregues pelos fornecedores.
• As dependências entre serviços, processos e partes.
• Os requisitos a serem cumpridos pelo fornecedor.
• As metas dos serviços.
• As interfaces com o fornecedor.
• A integração das atividades do fornecedor com o SGS.
• As características de carga de trabalho.
• As exceções de contrato e como devem ser trabalhadas.
• As autoridades e as responsabilidades.
• Os relatos e comunicações a serem providos pelo fornecedor.
• As bases para cobrança.
• Os procedimentos para término normal ou antecipado do contrato e a transferência dos serviços para outras partes.

Gerenciamento de Contratos – Práticas Recomendadas:

• Convém que o provedor de serviço indique uma pessoa de contato para o relacionamento com cada fornecedor.
• Convém que o contrato inclua requisitos e níveis de serviço requeridos do fornecedor. Convém que as metas de serviço acordadas no contrato do fornecedor estejam alinhadas com os ANSs com clientes do provedor de serviço.
• Convém que todos os contratos de fornecedor contenham uma programação de revisões para avaliar se os objetivos da organização para a terceirização do serviço continuam válidos. Pelo menos uma revisão anual convém ser programada.
• Convém que seja definido um processo claro para gerenciar cada contrato. O processo para alteração do contrato convém ser formalmente notificado para todos os fornecedores afetados.
• Se um contrato incluir penalidades ou bônus, convém que a base para tal esteja claramente estabelecida e em conformidade com os requisitos preestabelecidos.

Detalhes do fornecedor – Práticas recomendadas:

Convém que provedor de serviço mantenha a seguinte lista para cada serviço e fornecedor, ainda que estas informações não estejam no contrato:

• Uma definição dos serviços, papéis e responsabilidades.
• Escopo do serviço que será entregue pelo fornecedor.
• Requisitos a serem atendidos pelo fornecedor.
• Metas de serviço definidas e acordadas.
• Características de carga de trabalho, tais como números de transações, numero de serviço ou tamanho de banco de dados.
• Critérios de exceções para ANS acordados.
• Processo de gerenciamento de contrato, níveis de autorização.
• Condições de pagamento.
• Parâmetros para relatório e registros de desempenho realizado.

Gerenciamento de disputas contratuais – Práticas recomendadas:

• Convém que tanto o provedor de serviços quanto o fornecedor operem um processo de gerenciamento de disputas e que esse processo seja definido ou referenciado dentro do contrato.
• Convém que uma rota de escalada esteja disponível para disputas que não possam ser resolvidas através da rota normal.
• Convém que o processo assegure que disputas sejam registradas, investigadas, resolvidas apropriadamente e formalmente encerradas.

Encerramento de Contrato – Práticas recomendadas:

• Convém que o processo de gerenciamento de contratos inclua definições quanto ao término do contrato – seja este um término esperado ou antecipado.
• Convém que também haja definições para a transferência do serviço para outra organização no término do contrato.
• As cláusulas de término do contrato podem esclarecer as responsabilidades para término ou transferências de serviços, custos, direito de propriedade intelectual, hardware, licenças de software e dados.

 

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).

ISO/IEC 20000 Foundation – Gerenciamento de Relações de Negócio

Tem por objetivo estabelecer e manter um bom relacionamento entre o provedor de serviço e o cliente, com base no entendimento do cliente e de suas diretrizes de negócio.

Gerenciamento de Relações de Negócio

Satisfação do cliente – percepção do cliente do grau em que os seus requisitos foram atendidos.

Reclamação – Expressão de insatisfação feita a uma organização, relativa a seus produtos, ou ao próprio processo de tratamento de reclamações, para a qual explicitamente ou implicitamente espera-se uma resposta ou resolução.

Escalada – Uma atividade que obtém recursos adicionais quando necessário para atingir as metas de nível de serviço ou expectativa dos clientes.

Deve-se designar um indivíduo responsável pelo gerenciamento do cliente e pela satisfação do cliente.

Entendimento das necessidades de negócio:

• Identificar clientes, usuário e partes interessadas;
• Estabelecer mecanismos de comunicação;
• Promover o entendimento de requisitos que estão em constante mudança no lado do cliente;
• Realizar revisões de desempenho;

Gerenciamento de reclamações:

• Definir um procedimento formal para lidar com as reclamações;
• Registrar e gerenciar todas as reclamações;
• Fazer a escalação quando a reclamação não for resolvida;

Gerenciamento da satisfação:

• Medir a satisfação;
• Comparar o desempenho com as metas do cliente e pesquisas anteriores;
• Investigar e entender variações significativas;
• Discutir resultados de pesquisa com cliente;
• Registrar oportunidades de melhoria;
• Reportar progresso das melhorias para o cliente;

Requisitos Mínimos:

• O provedor de serviço deve identificar e documentar os clientes, usuário e partes interessadas no serviço.
• Para cada cliente, o provedor de serviço deve designar um individuo responsável pelo gerenciamento do cliente e pela satisfação do cliente.
• O provedor de serviço deve estabelecer os mecanismos de comunicação com o cliente. O mecanismo de comunicação deve promover o entendimento do ambiente de negócios sob o qual os serviços operam e os requisitos para novos ou modificados.
• O provedor de serviço, juntamente com o cliente, deve analisar criticamente o desempenho dos serviços em intervalos planejados.
• Mudanças efetuadas nos requisitos documentados do serviço devem ser controladas pelo processo de gerenciamento de mudanças.
• Mudanças nos ANSs devem ser coordenadas com o processo de nível de serviço.

A definição de uma reclamação contra um serviço deve ser acordada com o cliente:

• Deve ser documentado o procedimento para gerenciar as reclamações contra serviço emitidas pelo cliente.
• O provedor de serviço deve registrar investigar, agir sobre, relatar e fechar as reclamações contra os serviços.
• Quando uma reclamação não for resolvida pelos canais normais, o escalonamento deve ser oferecido ao cliente.

O provedor de serviço deve medir a satisfação do cliente em intervalos planejados, com base em uma amostra representativa dos clientes e usuários dos serviços. Os resultados devem ser analisados e revisados para identificar oportunidades de melhoria.

Práticas recomendadas:

• Convém que os clientes sejam classificados por tipo de serviço oferecido. Clientes com características similares podem ser agrupados de forma similar para melhorar a eficiência e eficácia deste processo.
• O individuo que ficará responsável por este processo pode ficar alocado em tempo integral ou ter seu papel combinado com outros papéis.
• É possível que os papéis de gerente de nível de serviço e gerente de relações de negocio ser assumidos pela mesma pessoa.
• Convém que os mecanismos de comunicação estabelecidos com o cliente incluam reuniões não estruturadas e encontros informais, além de reuniões formalizadas e documentadas.
• O provedor de serviço pode usar uma ferramenta ( por exemplo, de CRM) para gerenciar informações sobre os clientes.

Análise crítica do serviço ao cliente – Práticas recomendadas:

• Convém que as reuniões com o cliente sejam realizadas para revisar a satisfação do cliente, direção estratégica e exceções mais graves referentes ao desempenho dos serviços. Estas reuniões podem incluir revisões de ANS e desempenho, mudanças dentro da organização do provedor de serviço e mudanças na organização do cliente.
• Convém que as reuniões sejam agendadas com antecedência e realizadas regularmente, pelo menos anualmente.
• Os resultados das analises criticas podem resultar na identificação de novos serviços ou mudanças necessidades nos serviços existentes ou nos níveis de serviço.

Satisfação do cliente – Práticas recomendadas:

• Convém que o provedor de serviço estabeleça um mecanismo para registrar a satisfação do cliente.
• Convém que a frequência e escala de qualquer medição seja acordada com o cliente com antecedência e esta pode incluir uma amostra de usuários para pesquisas de satisfação. Esta atividade pode ser conduzida pela central de serviços durante a resolução de incidentes/problemas.
• Convém que pesquisas de satisfação sejam medidas ao longo do tempo, assim como as tendências na satisfação sejam acompanhadas.
• Convém que o procedimento pode tratar reclamações inclua um procedimento de escalada para ser usado se o cliente não concordar ou não aceitar as ações propostas ou solução. Convém que a reclamação fique aberta até que o cliente forneça um aceite formal para que ela seja fechada.
• Convém que reclamações de serviço sejam enviadas por um gerente do cliente para um gerente do provedor de serviço.

Texto adaptado por Gustavo, com base no material – ISO/IEC 20000 Foundation (TI Exames).