Práticas de mudança, liberação e melhoria contínua

Uma lista de servidores informa quais equipamentos existem. Para avaliar o que acontece quando um servidor muda, você também precisa saber o que é executado nele e quem depende dele. O gerenciamento de configuração de serviço disponibiliza informações confiáveis sobre as configurações dos serviços onde e quando as equipes precisam delas.

Decida o que precisa de controle de configuração

Um item de configuração (IC/CI) é um componente que deve ser gerenciado para entregar um serviço de TI. Os ICs podem ser equipamentos físicos, máquinas virtuais, bancos de dados, aplicações, serviços em nuvem, documentos ou os próprios serviços. A organização escolhe quais componentes precisam desse controle. Um acordo de nível de serviço pode ser um IC porque seu conteúdo acordado importa para a entrega do serviço; um teclado reserva de baixo custo geralmente não precisa de um registro de configuração.

Um registro de configuração descreve um IC. Campos úteis incluem identificador, tipo, versão, responsável, localização, status e relacionamentos. O identificador evita que dois servidores semelhantes sejam confundidos. A versão ajuda uma equipe de implantação a verificar se uma atualização planejada já chegou a um destino.

Acompanhe as dependências para avaliar o impacto

Relacionamentos como “executa em”, “usa” e “depende de” transformam registros em um mapa de serviço. Observe atentamente sua direção: uma aplicação que usa um banco de dados depende de sua disponibilidade.

Considere a aplicação de pedidos WEB-ORD. Ela é executada nos servidores virtuais VS-01 e VS-02 e usa o DB-ORD. Esse banco de dados é executado no cluster CL-02. O relatório mensal de vendas também usa o DB-ORD.

Para avaliar uma atualização do CL-02:

1. Encontre o banco de dados hospedado no cluster: DB-ORD.
2. Acompanhe os serviços que usam esse banco de dados: pedidos e relatórios de vendas.
3. Consulte os responsáveis pelos dois serviços sobre o impacto e escolha um horário fora dos períodos de maior volume de pedidos.

Verificar apenas o responsável pelo CL-02 deixaria de considerar os serviços de negócio que dependem dele. O mesmo mapa ajuda a equipe de suporte a rastrear uma falha e a equipe de segurança a localizar sistemas que precisam de uma correção. As equipes de liberação e implantação usam versões de configuração para verificar o que está instalado em cada ambiente.

Mantenha os registros ligados ao trabalho real

Atualize os registros afetados como parte das mudanças e implantações autorizadas. Caso contrário, um mapa de serviço correto se tornará enganoso após a próxima atualização. Verificações e auditorias comparam os registros com o ambiente real; a descoberta automatizada pode ajudar a encontrar diferenças. Investigue uma divergência para descobrir se o registro está errado ou se uma mudança foi feita sem autorização.

Uma linha de base de configuração é um retrato acordado e revisado dos ICs, usado como referência para mudanças posteriores. Ela ajuda as equipes a comparar um estado conhecido com o estado atual.

Colete os detalhes necessários para decisões reais. Registrar todos os atributos de todos os dispositivos cria trabalho que talvez não seja mantido. Um conjunto útil de registros apoia verificações de impacto, diagnóstico e conformidade, com responsabilidade clara pelas atualizações. Um inventário sozinho não consegue mostrar essas dependências.

Ativos de TI têm valor financeiro e podem contribuir para a entrega de um produto ou serviço de TI. Eles incluem equipamentos, licenças de software e assinaturas de serviços em nuvem. O gerenciamento de ativos de TI gerencia seu ciclo de vida completo para obter valor, controlar custos e riscos e cumprir requisitos contratuais e regulatórios.

Acompanhe o ativo durante toda a sua vida

O ciclo de vida começa antes da compra e continua depois que o ativo deixa de ser usado:

1. Planejar: estabeleça a necessidade e considere o que já está disponível.
2. Adquirir: compre, arrende ou faça uma assinatura.
3. Receber e registrar: registre o item e sua propriedade ou condições.
4. Destinar: atribua-o a um usuário ou local.
5. Operar e manter: repare, transfira, reatribua ou renove-o.
6. Retirar de uso: retire-o do uso ativo.
7. Descartar: apague os dados ou destrua o meio de armazenamento, depois recicle ou devolva o equipamento conforme apropriado.

Atualize o registro a cada evento. Uma contagem anual pode verificar essas atualizações, mas não pode substituí-las. Se um notebook mudar de usuário duas vezes entre contagens, a organização ainda precisará saber quem está com ele agora.

Um registro de ativos contém informações como etiqueta de identificação, modelo, número de série, responsável ou usuário, localização, data e custo de compra, término da garantia ou do arrendamento, termos da licença e status. O status distingue um item “em estoque” de um “em uso” ou “retirado de uso”.

Compare os direitos de software com o uso

O gerenciamento de ativos de software compara os direitos de uso com a instalação ou o uso real. Comprar poucas licenças cria risco de não conformidade; manter licenças não utilizadas desperdiça dinheiro. Verifique os termos da licença antes de reatribuir ou reduzir assinaturas.

Uma empresa paga por 500 assinaturas de uma suíte de escritório a R$ 120 por usuário por ano. Ela atribuiu 430, deixando 70 sem uso. Seu custo anual em reais é:

Quarenta novos funcionários precisam da suíte. Reatribuir 40 assinaturas não utilizadas evita comprar mais 40, evitando R$ 4.800 em gastos anuais adicionais. Trinta permanecem sem uso; cancelá-las na renovação economiza R$ 3.600 por ano. São benefícios diferentes: novos gastos evitados e redução de gastos existentes.

As contas de serviços em nuvem pertencem à mesma visão financeira. Uma assinatura de um departamento que não foi informada pode escapar tanto ao controle de renovação quanto à revisão de segurança. Essa TI não supervisionada precisa de visibilidade, mesmo que não haja um dispositivo físico para contar.

Separe as questões financeiras das de configuração

A mesma ferramenta pode conter os dois registros, mas as finalidades são diferentes. O valor de revenda não é o critério para um ativo de TI: uma assinatura de serviço em nuvem pode ter valor financeiro sem ser revendida.

A retirada de uso não conclui o descarte. Antes de o equipamento sair da organização, apague seus dados com segurança ou destrua o meio de armazenamento e registre a ação. Envie o lixo eletrônico a recicladores autorizados e devolva os dispositivos arrendados ao arrendador. O registro do ativo deve mostrar o que aconteceu com o item e quando.

Alterar um procedimento de suporte pode afetar um serviço assim como alterar um servidor. Uma mudança é a adição, modificação ou remoção de qualquer coisa que possa afetar direta ou indiretamente os serviços. Isso inclui equipamentos, aplicações, documentos, processos e arranjos com fornecedores dentro do escopo escolhido pela organização.

Torne possíveis as mudanças úteis

A habilitação de mudanças visa maximizar as mudanças bem-sucedidas em serviços e produtos. Ela faz isso por meio de três responsabilidades relacionadas:

• Avaliar os riscos adequadamente.
• Autorizar o prosseguimento das mudanças.
• Gerenciar o calendário de mudanças.

O objetivo é uma mudança bem-sucedida, com proteção adequada ao risco. Os usuários precisam de melhorias e correções prontamente. Eles também precisam que os serviços existentes continuem funcionando. Um fluxo de aprovação lento para cada tarefa pequena desperdiça tempo e pode levar as equipes a contorná-lo. Permitir que cada equipe altere sistemas compartilhados sem coordenação expõe os usuários a falhas evitáveis.

Por exemplo, substituir uma aplicação pode trazer novas funcionalidades, mas também interromper o trabalho existente. Remover um banco de dados antigo também é uma mudança: outro serviço ainda pode usar seus dados. Até mesmo uma edição de documento faz parte do escopo quando altera a forma como os funcionários prestam suporte. A questão relevante é o possível efeito sobre os serviços, não se alguém escreve código novo.

Avalie o sucesso pelo resultado

Uma mudança bem-sucedida é implementada conforme o planejado, entrega o resultado pretendido e não causa danos imprevistos, como incidentes. “A instalação terminou” responde apenas a parte dessa avaliação. Os usuários ainda podem não conseguir concluir a tarefa que a mudança pretendia melhorar.

Suponha que 240 mudanças tenham sido implementadas em um trimestre e que 12 tenham falhado ou sido revertidas. O número de mudanças bem-sucedidas é 228. Calcule a taxa usando todas as mudanças implementadas como denominador:

A taxa de falha de 5% é o complemento da taxa de sucesso de 95%. Manter tanto a contagem quanto a taxa ajuda a equipe a ver a dimensão do trabalho. Uma alta taxa de sucesso deve ser analisada junto com a rapidez com que mudanças valiosas chegam aos usuários; bloquear trabalho útil poderia produzir poucas falhas enquanto atende a poucas necessidades.

Reconheça nomes e fontes de mudanças

A ITIL 4 usa habilitação de mudanças, assim como a ITIL (Versão 5). Materiais anteriores podem usar “controle de mudanças” ou “gerenciamento de mudanças”. O gerenciamento de mudanças organizacionais é uma prática separada que trata da adoção de novas formas de trabalho pelas pessoas, incluindo comunicação e treinamento.

Requisições de mudança podem começar com correções de problemas, incidentes urgentes, atualizações de segurança, atualizações de fornecedores, novas funcionalidades ou ideias de melhoria. Sua origem não elimina a necessidade de avaliá-las, autorizá-las e coordená-las. Uma correção de fornecedor ainda precisa de um fluxo de mudança adequado; uma pequena melhoria de processo ainda exige atenção a seu efeito sobre os usuários.

As organizações definem o escopo e os fluxos de decisão adequados a seus serviços. Um fluxo útil torna visível a decisão do responsável, dá às pessoas informações suficientes para avaliar o risco e permite que a equipe execute o trabalho em um momento adequado.

O fluxo de uma mudança depende de como ela é avaliada e autorizada. Seu tamanho técnico, por si só, não decide se ela é padrão, normal ou emergencial. Uma alteração de uma linha em um roteador pode apresentar mais risco do que uma grande instalação de software já comprovada.

Escolha o fluxo adequado

Um procedimento padrão tem seu risco avaliado quando é criado e quando é modificado. Sua pré-autorização se aplica ao procedimento acordado. Uma equipe não pode chamar uma tarefa desconhecida de padrão só porque espera que ela seja fácil.

Normal não significa risco médio. Uma mudança normal de baixo risco pode precisar apenas de aprovação rápida por um colega ou de verificações automatizadas. Uma grande mudança normal pode exigir a alta direção. Os modelos de mudança definem esses fluxos para que as equipes saibam quais informações e qual autoridade cada tipo exige.

Escreva uma requisição de mudança útil

Uma mudança normal geralmente começa com uma requisição de mudança, também chamada de RFC. Forneça a quem decide as informações necessárias para avaliá-la:

• O que mudará, por quê e qual é o benefício esperado.
• Serviços e ICs afetados, com risco e impacto.
• Planos de implementação e teste.
• Um plano de remediação para restaurar o serviço em caso de falha.
• Data e horário propostos.

Para uma transferência de banco de dados, dizer “o novo armazenamento é mais rápido” explica um benefício esperado, mas não permite que a autoridade avalie quem poderia ser afetado ou como a equipe se recuperaria.

Trate a urgência real sem perder o controle

A avaliação e a autorização emergenciais acontecem mais rapidamente, muitas vezes por meio de uma autoridade menor. Mantenha os testes tão completos quanto o tempo permitir. Parte da documentação pode ser concluída depois, mas a urgência não transforma o trabalho em uma mudança não autorizada. Uma correção não testada pode criar outro incidente.

O fato de um gerente querer uma funcionalidade hoje não torna a requisição emergencial. Ameaças imediatas ao serviço ou à segurança justificam o fluxo acelerado. Em um trimestre com 18 mudanças emergenciais entre 240 mudanças, a proporção é:

Acompanhe esse valor ao longo do tempo. Trabalho urgente frequente pode revelar problemas de planejamento que merecem melhoria.

Uma mudança normal repetida pode se tornar padrão depois que a equipe documenta o procedimento comprovado, avalia seu risco e obtém aprovação. A aplicação mensal de correções em servidores de teste não críticos poderia se qualificar. A repetição, por si só, fornece experiência, não pré-autorização. Uma alteração de firewall para um novo parceiro continua normal, a menos que um procedimento padrão aprovado cubra exatamente esse tipo de alteração.

Uma aprovação é útil quando a pessoa que a concede entende o risco e consegue tomar uma decisão no momento adequado. Uma autoridade de mudança é a pessoa ou o grupo que autoriza uma mudança. Atribua a autoridade de acordo com o tipo e o risco do trabalho, mantendo as decisões rotineiras próximas das pessoas que o executam.

Avalie probabilidade e impacto separadamente

A probabilidade diz respeito à chance de falha: complexidade, testes e experiência da equipe são importantes. O impacto diz respeito às consequências: serviços e usuários afetados, perda de dados, gravidade e tempo de recuperação. Use os relacionamentos de configuração para encontrar serviços que compartilham o componente alterado.

Uma organização pode multiplicar impacto e probabilidade, cada um avaliado de 1 a 5. Neste exemplo, ela atribui pontuações de 1 a 5 à aprovação por um colega, de 6 a 12 a um gerente de mudanças e de 13 a 25 a uma autoridade de nível superior ou ao CAB. Esses são limiares locais.

Um comitê consultivo de mudanças (CCM/CAB) assessora sobre mudanças significativas. Ele não precisa aprovar toda mudança. A revisão por pares e as verificações automatizadas podem fornecer fluxos autorizados para trabalhos adequados de baixo risco.

Planeje a recuperação antes da implementação

Toda mudança normal precisa de um plano de remediação que informe como restaurar o serviço e quando iniciar a recuperação. A reversão, ou backout, retorna ao estado anterior. Corrigir e avançar aplica uma correção; outra opção é mudar para um serviço alternativo.

Um fluxo de recuperação testado pode reduzir as consequências de uma falha. Uma mudança sem recuperação testada apresenta mais risco e merece uma decisão de nível superior. Escrever apenas “reverter se necessário” deixa a equipe sem um gatilho, um responsável ou uma sequência prática.

Coordene o calendário de mudanças

O calendário apoia o planejamento, a comunicação, a verificação de conflitos e a alocação de recursos. Ele também ajuda as equipes de incidentes e problemas a identificar mudanças recentes que possam explicar uma falha. As organizações podem definir períodos de congelamento, como durante um processamento de faturamento, com exceções para emergências.

Suponha que a substituição de um switch e a atualização de uma aplicação estejam ambas programadas para sábado, das 22:00 às 02:00. Os servidores da aplicação dependem do switch. A interrupção impediria o teste da aplicação e dificultaria o rastreamento de falhas. Transfira a atualização da aplicação para domingo às 22:00 e informe a central de serviços sobre as duas janelas.

Revise o que realmente aconteceu

Após a implementação, verifique o objetivo, os incidentes e os efeitos não pretendidos antes de encerrar o registro. Revise as falhas para extrair lições. Medidas úteis incluem taxa de sucesso, mudanças que causam incidentes, proporção de emergenciais e tempo da requisição à implementação.

Uma funcionalidade pode estar instalada em produção enquanto os usuários ainda não conseguem acessá-la. O gerenciamento de liberação disponibiliza serviços e funcionalidades novos e modificados para uso. Ele planeja a prontidão e a comunicação, além do momento em que os usuários obtêm acesso.

Defina o conteúdo da liberação

Uma liberação é uma versão de um serviço ou outro IC, ou um conjunto de ICs, disponibilizado para uso. Ela pode conter código de aplicação, infraestrutura, documentação, procedimentos atualizados, treinamento e artigos de conhecimento. Se a equipe de suporte não consegue ajudar os usuários com a funcionalidade, a prontidão técnica por si só deixa uma lacuna.

O planejamento da liberação define escopo, momento e critérios de prontidão. Por exemplo, exija que os testes sejam aprovados, a equipe de suporte seja informada, o guia do usuário seja atualizado e a reversão seja testada. Esses critérios permitem que a equipe decida se há prontidão com base em evidências antes de ampliar o acesso.

Identificadores de versão distinguem o que está disponível. Em um esquema comum principal.secundária.correção, de 4.2.0 para 4.3.0 indica uma liberação secundária de funcionalidades; 5.0.0 indica uma liberação principal. As equipes acordam sua convenção de numeração para que notas de liberação, registros de suporte e versões instaladas se refiram à mesma coisa.

Separe a implantação do acesso

A implantação transfere componentes para um ambiente. A liberação os disponibiliza para uso. Um sinalizador de funcionalidade pode manter o código implantado inativo e depois ativá-lo para usuários selecionados.

Considere um aplicativo bancário que acrescenta extratos em PDF:

1. Na terça-feira, implante a versão 3.4 nos servidores de produção com a funcionalidade desativada. O código está presente, mas os clientes não podem usar a nova funcionalidade.
2. Na quinta-feira, libere-a para 10% dos usuários. Monitore a taxa de falhas do aplicativo em relação ao limite da equipe de 0,5% das sessões.
3. A taxa permanece abaixo desse limite, então, na segunda-feira, libere-a para todos os usuários.

O limite de disponibilização pertence ao plano de liberação dessa equipe. Ele não é um limiar universal de liberação. O acesso controlado fornece feedback antes que a funcionalidade chegue a toda a população de usuários.

Ajuste o planejamento ao ritmo de entrega

A entrega frequente muda a forma como o trabalho é organizado. Regras e verificações automatizadas podem apoiar decisões rápidas, enquanto uma equipe continua decidindo quem recebe cada funcionalidade e quando.

As notas de liberação explicam em linguagem clara o que mudou, o que foi corrigido e os problemas conhecidos. Para o aplicativo bancário: “Você pode baixar extratos mensais em PDF. Extratos com mais de 24 meses ainda não estão disponíveis.” Forneça essas informações à central de serviços antes que os usuários comecem a perguntar sobre elas.

Após a liberação, reúna feedback dos usuários, incidentes e dados de desempenho. Encaminhe as lições para a melhoria contínua. Apertar um botão de implantação não realiza esse trabalho de prontidão, acesso, comunicação e revisão.

O gerenciamento de implantação transfere componentes novos ou modificados para ambientes de produção e pode transferi-los para outros ambientes para teste. Os componentes incluem hardware, software, documentos e processos. A prática controla o que chega a cada destino e verifica se funciona nesse local.

Saiba para onde o componente vai

Um teste aprovado em pré-produção fornece evidências para a transferência à produção. Após a transferência, testes funcionais rápidos e monitoramento verificam o resultado real em produção. Atualize os registros de configuração para mostrar a versão instalada e os relacionamentos alterados.

Escolha uma abordagem adequada ao serviço

A implantação em fases transfere componentes para uma parte da produção por vez. Ela limita a exposição inicial e fornece feedback antes da próxima onda. Uma equipe que atualiza 2.000 notebooks escolhe quatro ondas de 500, começando pela equipe de TI, que consegue relatar problemas com clareza.

A equipe pausa se incidentes relacionados à implantação afetarem mais de 2% dos notebooks de uma onda. Na primeira onda, os incidentes afetam 25 notebooks distintos:

Cinco por cento supera o limite da equipe, então ela pausa, investiga, corrige a causa e testa novamente antes da onda 2. O denominador é a onda implantada, não os 2.000 notebooks. Conte os dispositivos afetados, pois vários chamados de incidente podem se referir ao mesmo dispositivo.

A implantação simultânea transfere componentes para todos os destinos ao mesmo tempo. Ela é adequada para uma troca única quando as versões antiga e nova não podem coexistir. Por exemplo, todas as 120 lojas recebem um novo software de ponto de venda na mesma noite porque as duas versões não podem compartilhar o sistema central. Uma falha pode afetar todas as lojas, portanto teste minuciosamente e ensaie a remediação.

A implantação por demanda coloca o software aprovado em um repositório controlado para que os usuários o instalem quando escolherem. Uma organização pode publicar uma atualização de videoconferência em seu portal de software e definir um prazo antes que a versão antiga deixe de funcionar.

A entrega contínua integra, testa e implanta componentes sempre que necessário, apoiando feedback frequente. A movimentação automatizada ainda precisa de fontes controladas, autorização, validação e registros atualizados.

Controle a fonte e a recuperação

Mantenha os componentes prontos para implantação em locais seguros e controlados, como uma biblioteca definitiva ou um repositório de artefatos. As equipes devem obter sempre a versão autorizada e testada, em vez de depender de uma cópia local não verificada.

Realize a implantação sob uma mudança autorizada. Tenha um plano de remediação pronto antes de transferir os componentes. Verifique o resultado imediatamente e aja quando as verificações falharem. Uma versão instalada pode permanecer inativa até que o gerenciamento de liberação disponibilize sua funcionalidade aos usuários; a conclusão da implantação não significa que a liberação ocorreu.

Uma entrega recorre a várias práticas porque cada uma resolve um problema diferente. Coordená-las evita uma lacuna entre uma tarefa técnica autorizada e uma funcionalidade que as pessoas podem usar com sucesso.

Faça a pergunta que cada prática responde

Essas responsabilidades podem ser executadas pela mesma equipe. Ainda assim, exigem decisões e registros distintos. Uma equipe ágil pode combinar revisão por pares, verificações automatizadas e decisões registradas sem levar cada entrega a uma reunião.

Acompanhe uma funcionalidade do portal durante a entrega

Um portal de recursos humanos permitirá que os funcionários enviem comprovantes de despesas. A requisição de mudança descreve o benefício, os ICs afetados, a implementação, os testes e a recuperação. Segundo o modelo de risco da organização, impacto 3 e probabilidade 2 resultam em uma pontuação de 6. O gerente de mudanças autoriza uma mudança normal para quarta-feira, das 20:00 às 22:00, após verificar conflitos no portal.

A equipe testa a versão 2.8 em pré-produção e depois a implanta nos servidores de produção durante essa janela. Ela mantém a funcionalidade de envio desativada. Os registros de configuração agora mostram a versão 2.8. Quaisquer assinaturas ou equipamentos adicionados também precisam de registros de ativos e de um responsável por seu ciclo de vida.

Na sexta-feira, o gerenciamento de liberação disponibiliza a funcionalidade a 150 funcionários do departamento financeiro. A central de serviços recebe notas de liberação e um guia breve antecipadamente. Uma semana depois, o acesso é ampliado para todos os 2.400 funcionários. A instalação e a disponibilidade para os usuários têm datas diferentes, então uma pergunta sobre se a funcionalidade está “em produção” exige uma resposta precisa sobre a qual evento se refere.

Revise os resultados e compartilhe as lições

Durante a primeira semana, três pessoas perguntam como usar a funcionalidade de envio. O serviço está funcionando normalmente: essas são requisições de orientação, não incidentes. A revisão verifica se os comprovantes podem ser enviados conforme pretendido e não encontra interrupção ou degradação. A mudança pode ser encerrada como bem-sucedida, com uma ideia de melhoria para adicionar uma dica no aplicativo.

Uma liberação pode exigir várias implantações, como ondas para destinos diferentes. Uma implantação pode conter várias funcionalidades liberadas em momentos diferentes por meio de sinalizadores. Não há uma relação obrigatória de um para um entre mudança, implantação e liberação.

Relacione o trabalho à entrega de valor

Na ITIL 4, essas práticas contribuem especialmente para as atividades de desenho e transição, obter/construir e entrega e suporte. A ITIL (Versão 5) descreve oito atividades do ciclo de vida de produtos e serviços: descobrir, desenhar, adquirir, construir, fazer a transição, operar, entregar e dar suporte. Construir e fazer a transição são atividades centrais para preparar e introduzir componentes modificados. A entrega ainda precisa de evidências de que o resultado pretendido do serviço chegou aos usuários.

O gerenciamento de segurança da informação protege as informações de que uma organização precisa para seu trabalho por meio da compreensão e do gerenciamento dos riscos. Ele se aplica às pessoas, aos procedimentos, aos fornecedores e à tecnologia que lidam com essas informações. A equipe de segurança coordena o trabalho especializado, mas todos têm um papel.

Identifique o que precisa de proteção

As três primeiras são frequentemente chamadas de CIA. Um serviço pode proteger a confidencialidade, mas falhar na disponibilidade se os usuários não conseguirem acessá-lo. A autenticação verifica quem é uma pessoa; por si só, ela não estabelece o que essa pessoa pode acessar. O não repúdio diz respeito à evidência de uma ação, além do evento de acesso.

Equilibre prevenção, detecção e correção

A prevenção reduz a chance de incidentes. Exemplos incluem aplicação de correções, controles de acesso, firewalls e treinamento de conscientização. A detecção identifica incidentes que conseguem ocorrer, usando monitoramento, alertas e revisão de registros. A correção limita os danos e restaura a operação normal, usando isolamento, recuperação e correções.

Para ransomware, uma abordagem equilibrada atua nessas etapas:

1. Aplique correções prontamente, filtre e-mails maliciosos, exija autenticação multifator e conceda às contas apenas o acesso necessário.
2. Gere alertas quando um software começar a criptografar muitos arquivos inesperadamente.
3. Isole computadores infectados, restaure dados de backups off-line e encontre e corrija a via de entrada.

Backups apoiam a recuperação; eles não substituem medidas que previnem ataques ou os detectam cedo. Escolha controles proporcionais ao valor das informações, às ameaças e às vulnerabilidades. Controles que dificultam desnecessariamente o trabalho comum podem incentivar soluções de contorno não oficiais.

Incorpore a segurança às práticas rotineiras

Uma política de segurança, papéis definidos e treinamento regular orientam o comportamento diário. Remova o acesso de quem está saindo da organização no último dia de trabalho. A ISO/IEC 27001 estabelece requisitos para um sistema de gestão de segurança da informação; as organizações podem buscar certificação segundo ela.

As informações de configuração ajudam a localizar sistemas afetados: uma biblioteca vulnerável em 37 de 400 servidores identifica os alvos da correção. Correções rotineiras usam fluxos de mudança padrão ou normal. Uma ameaça ativa que exige ação imediata usa avaliação e autorização emergenciais. O gerenciamento de ativos protege os dados antes do descarte, enquanto o gerenciamento de fornecedores estabelece requisitos de segurança e controla o acesso dos fornecedores.

O trabalho de um fornecedor se torna parte do serviço que os clientes experimentam. O gerenciamento de fornecedores gerencia fornecedores, relacionamentos, acordos e desempenho para que produtos e serviços de qualidade funcionem de forma integrada. Os fornecedores podem ser empresas externas ou departamentos internos.

Escolha como obter o trabalho

Essas estratégias descrevem aspectos diferentes do fornecimento: uma organização pode terceirizar para um único parceiro ou para vários fornecedores. Escolha com base na cultura organizacional, na escassez de competências, na experiência, no custo total, nas restrições externas e na previsibilidade da demanda. O menor preço cotado pode esconder esforço de coordenação ou baixa qualidade do serviço.

Torne as expectativas mensuráveis

Mantenha visibilidade sobre fornecedores, estratégia, políticas e informações contratuais. Acorde metas de serviço, tempos de resposta, requisitos de segurança e dados, relatórios, preços e compensações, como créditos de serviço. Inclua o tratamento de disputas e os arranjos de saída, especialmente a devolução dos dados.

Os contratos iniciam um gerenciamento contínuo. Acompanhe o desempenho, revise os relacionamentos e planeje renovações e saídas. Um fornecedor estratégico de serviços em nuvem precisa de planejamento conjunto e revisões regulares; um fornecedor de cabos geralmente pode ser gerenciado por condições de compra padrão.

Verifique o desempenho em relação ao acordo

Suponha que um contrato de hospedagem prometa 99,9% de disponibilidade durante um mês inteiro de 30 dias. O período de medição contém:

A indisponibilidade permitida é 0,1% desse período, ou 43,2 minutos. A indisponibilidade real é de 95 minutos. A disponibilidade é:

A meta não foi atingida. Aplique o crédito de serviço especificado no contrato e acorde um plano de melhoria na revisão com o fornecedor. Uma diferença aparentemente pequena entre porcentagens ainda pode representar um tempo adicional considerável de indisponibilidade. Use o período de medição e as regras contratuais acordados ao avaliar o desempenho.

Mantenha a responsabilidade e gerencie a dependência

A organização continua responsável perante seus próprios clientes, mesmo quando um fornecedor entrega parte do serviço. Um crédito do fornecedor trata de um acordo; ele não restaura o trabalho interrompido de um cliente. As equipes também precisam de uma resposta coordenada e de ações de melhoria.

Bons relacionamentos apoiam relatórios transparentes e resultados compartilhados. Gerencie o aprisionamento ao fornecedor, a dificuldade de deixar um fornecedor, por meio de dados portáveis e de um plano de saída testado. Com vários fornecedores, esclareça as responsabilidades e as transferências de trabalho para que uma falha seja resolvida em todo o serviço em vez de ser repassada entre contratos.

As necessidades de serviço mudam à medida que usuários, tecnologia e organizações mudam. A melhoria contínua mantém serviços e práticas alinhados a essas necessidades por meio de melhorias constantes em produtos, serviços, práticas e na forma como são gerenciados. Um formulário mais claro pode ser tão importante para uma equipe quanto uma nova plataforma para a organização.

Dê às ideias cotidianas um caminho para a ação

Todos são responsáveis pela melhoria. Uma equipe dedicada pode coordenar o trabalho, orientar as pessoas e acompanhar os resultados. Os líderes fornecem tempo e orçamento. Os funcionários que fazem o trabalho identificam dificuldades e testam formas melhores de lidar com elas.

As atividades de melhoria incluem encontrar oportunidades, registrá-las, avaliá-las e priorizá-las, elaborar justificativas de negócio, planejar ações, executá-las e avaliar os resultados. A coordenação ajuda as equipes a evitar esforços concorrentes ou mudanças que transfiram um problema para outro lugar.

As ideias podem vir de tendências de incidentes e problemas, feedback de clientes, pesquisas de satisfação, sugestões dos funcionários, auditorias, novas tecnologias, revisões de fornecedores e revisões de mudanças ou liberações. Uma equipe de suporte que observa confusão recorrente após liberações tem evidências úteis para melhoria, mesmo quando não ocorreu uma grande interrupção.

Mantenha um registro de melhoria contínua

Um registro de melhoria contínua (RMC/CIR) é um documento estruturado ou banco de dados que acompanha ideias desde a identificação até a ação final. Registre a ideia, a origem, o benefício esperado, o esforço estimado, a prioridade, o responsável e o status. Um responsável garante que alguém cuide da próxima decisão sobre uma ideia útil.

Uma organização pode manter registros em nível de equipe e de organização. O trabalho importante é gerenciar as ideias por meio da avaliação e da ação. Uma lista longa sem responsáveis ou atualizações de status pouco ajuda a escolher o que acontece em seguida.

Compare benefício e esforço

Uma equipe atribui notas de 1 a 10 ao benefício e ao esforço e usa o benefício por unidade de esforço como um auxílio à priorização:

Por essa medida, comece por C, depois A e depois B. O maior benefício total não é o mesmo que o maior benefício por unidade de esforço. Mantenha B no registro para que seu valor e suas necessidades de recursos possam ser reconsiderados. Uma razão ajuda a comparar o trabalho; a priorização ainda exige atenção aos objetivos e às restrições da organização.

Relacione a melhoria ao sistema de serviço

A ITIL 4 coloca a melhoria contínua no sistema de valor de serviço, na atividade “melhorar” da cadeia de valor e nas práticas de gerenciamento. A ITIL (Versão 5) a mantém no sistema de valor da ITIL e como prática.

A melhoria coloca “Comece de onde você está”, “Foque no valor” e “Progrida iterativamente com feedback” no trabalho cotidiano. Comece com evidências do problema atual, escolha uma ação com um resultado útil e use o feedback para decidir a próxima ação. Pequenas etapas frequentes realizadas pelas pessoas que fazem o trabalho fazem parte disso, assim como iniciativas maiores.

Comprar uma ferramenta ou reescrever um procedimento é uma ação. Para comprovar uma melhoria, relacione essa ação a um resultado necessário e meça o que mudou. O modelo de melhoria contínua fornece sete etapas para esse trabalho em qualquer escala.

Defina a direção e compreenda o ponto de partida

1. Qual é a visão? Relacione o trabalho aos objetivos da organização e explique o benefício de que as partes interessadas precisam.
2. Onde estamos agora? Avalie o estado atual objetivamente e crie uma linha de base para comparação.
3. Onde queremos estar? Compare os estados atual e desejado e estabeleça metas específicas, mensuráveis e com prazo definido.

Uma visão como “os usuários podem voltar ao trabalho rapidamente” fornece uma direção. Uma meta como “alcançar 70% de resolução no primeiro contato em seis meses” torna mensurável uma parte dessa direção. “Suporte mais rápido”, por si só, não fornece resultado nem prazo definidos.

Uma linha de base registra o estado inicial. Use uma definição de medição clara para que o resultado posterior possa ser comparado de forma significativa. Contar tipos diferentes de contatos nos dois períodos pode dificultar a interpretação de uma mudança aparente.

Planeje, aja, verifique e mantenha

4. Como chegamos lá? Escolha um plano, usando iterações quando o melhor caminho for incerto.
5. Execute a ação. Execute o plano observando riscos e efeitos colaterais.
6. Chegamos lá? Meça novamente e compare o resultado com a linha de base e a meta. Ajuste etapas anteriores se necessário.
7. Como mantemos o impulso? Compartilhe os resultados, incorpore a melhor forma de trabalho e continue a melhoria.

Essas perguntas apoiam um ciclo. Elas não exigem esperar até o fim de um grande projeto para aprender com o feedback. Uma iteração malsucedida pode mostrar o que mudar em seguida.

Acompanhe uma melhoria na central de serviços

Uma central de serviços resolve 696 de 1.200 contatos mensais no primeiro contato. Sua linha de base é:

A equipe estabelece uma meta de 70% em seis meses. Ela planeja melhores artigos de conhecimento e ferramentas de acesso remoto e depois os introduz. Após três meses, 736 de 1.150 contatos são resolvidos no primeiro contato:

Compare as taxas porque o total de contatos mudou. Sessenta e quatro por cento está acima da linha de base, mas abaixo da meta. Volte ao planejamento, examine os tipos de contato que ainda são encaminhados e acrescente treinamento direcionado. Há progresso, mas a equipe não pode informar que a meta foi alcançada.

Depois de alcançar um resultado útil, mantenha responsáveis pelos artigos, treine novos funcionários e compartilhe evidências do resultado. Isso ajuda o serviço a evitar um retorno ao estado anterior quando a equipe original de melhoria passa a outro trabalho.

Reconheça a formulação da Versão 5

A ITIL (Versão 5) mantém sete etapas. A etapa 6 pergunta “Estamos chegando lá?” e a etapa 7 pergunta “Como mantemos as melhorias relevantes?”. A formulação destaca verificações contínuas do progresso e da relevância das melhorias. A linha de base, a meta, a ação e o feedback continuam essenciais para usar o modelo.

Uma medida útil mostra se o serviço está alcançando algo de que as pessoas precisam. Contar apenas a atividade pode fazer uma equipe ocupada parecer bem-sucedida enquanto seus usuários continuam insatisfeitos. Escolha medidas que relacionem o trabalho aos resultados pretendidos.

Relacione condições de sucesso a indicadores

Um fator crítico de sucesso (FCS/CSF) é uma condição que deve ser atendida para alcançar o resultado pretendido. Um indicador-chave de desempenho (KPI) mede se um FCS está sendo atendido. Para o FCS “os usuários têm seus problemas resolvidos rapidamente”, possíveis KPIs incluem a taxa de resolução no primeiro contato e o tempo médio de resolução de incidentes.

Equilibre os indicadores para que uma meta não recompense comportamentos prejudiciais. Se os atendentes forem avaliados apenas pelo tempo de resolução, encerrar chamados cedo demais melhora a aparência dos números. Combine essa medida com a taxa de reabertura e o feedback dos usuários para verificar se os problemas foram realmente resolvidos.

Quando os relatórios técnicos estão verdes, mas os usuários têm uma experiência ruim, essa divergência é às vezes chamada de efeito melancia. Medidas de satisfação e reclamações ajudam a revelar o que os indicadores técnicos não mostram.

Compare porcentagens com precisão

Um aumento de 58% para 64% é de 6 pontos percentuais. O aumento relativo compara essa diferença com a taxa inicial:

Indique a qual comparação você se refere. Informar “melhoria de 6%” para essa mudança confunde a diferença em pontos com a variação relativa. Use populações, definições de medição e períodos consistentes ao comparar resultados.

Ao combinar grupos, some suas quantidades de sucessos e suas quantidades totais antes de calcular a taxa geral. Um canal web resolve 90 de 150 contatos e um canal telefônico resolve 20 de 50. Juntos, eles resolvem 110 de 200, ou 55%. Calcular a média das taxas de 60% e 40% com pesos iguais resultaria em 50%, mas o grupo do canal web tem três vezes mais contatos.

Escolha uma técnica para a pergunta

Uma escala de maturidade pode ir de 1, inicial, a 5, otimizado; use a escala definida pela avaliação. Uma classificação mais alta da prática e um resultado melhor para o cliente são medidas diferentes e precisam de evidências próprias.

Uma mudança normal leva 6 dias da requisição à implementação. Cinco dias são gastos esperando uma reunião semanal de aprovação. A espera representa:

A gestão enxuta direciona a atenção a essa espera. Um fluxo adequado de aprovação por colegas para trabalho de baixo risco pode reduzir o atraso, preservando a autorização. Acelerar uma tarefa curta de implementação deixaria a maior parte do tempo de atravessamento intacta.

A abordagem ágil apoia pequenos incrementos e feedback frequente. O DevOps conecta desenvolvimento e operações com automação para uma entrega rápida e segura. Ambos se encaixam na melhoria iterativa. Quando uma melhoria altera um serviço, ferramenta ou processo, encaminhe-a pela habilitação de mudanças e, quando necessário, pela implantação e liberação. Meça seu efeito em relação à linha de base.