Problemas, sejam bem-vindos!

Transcrição

1 Problemas, sejam bem-vindos! Heinz Nevermann Zamorano ITIL Expert Ícaro Technologies 1: INTRODUÇÃO No contexto cotidiano provavelmente ninguém goste de problemas, seja na vida pessoal, amorosa, profissional ou até mesmo dentro do mundo corporativo. Os problemas no geral são definidos como algo indesejável, e se gostar, o senso comum já nos adverte um sentido anormal. A convivência freqüente com problemas, no geral nos expõe a tensões, algum sofrimento ou estresse, um caminho inverso a uma vida saudável, tranqüila e equilibrada. Seja como for, a convivência continua com problemas não é de nenhuma forma estimulada no ideal cultural atual. Na construção e significação da realidade, de uma ou outra maneira se idealiza e estimula um mundo sem problemas. Por outro lado, as boas práticas do mundo ITIL (Information Technology Infrastructure Library) apresentam uma visão que a primeira vista poderia parecer até contraditória, irreconciliável com o ideal cultural do cotidiano. Inserida no Ciclo de Vida do Serviço de TI, na fase de Operação do Serviço, o processo de Gerenciamento de Problemas tenta equilibrar e estabilizar a infra-estrutura de TI (Tecnologia da Informação), com uma estratégia que poderia ser chamada de paradoxal. Para evitar problemas (como se diria no contexto cotidiano), indisponibilidades indesejadas, quedas de performance, ou qualquer outro impacto direto ou indireto para o negócio, o processo fomentaria, estimularia problemas através de uma serie de atividades focadas na investigação. A aparente direção na contramão até parece receita de homeopatia: usar o próprio veneno para obter a cura. Mas muito pelo contrario, o que está em jogo é realizar de forma dirigida, atividades investigativas que são chamadas de Problema. Ou seja, se estimulam problemas como um barômetro positivo, um controle da pressão do negócio frente aos serviços de TI, focando no equilibro da saúde dos serviços de TI frente ao negócio. Este incentivo tem um sentido de conhecer os pontos sensíveis, as fortalezas e as fragilidades dos ativos que suportam os serviços, e assim, tomar ações para estabilizar e melhorar os serviços de TI. Onde está o ponto desta lógica aparentemente contraditória, entre estas visões de mundos de TI e do contexto cotidiano, onde um estimula e o outro repudia? Com certeza na sobreposição conceitual da palavra problema. Esta justaposição sob o termo problema, pode ser a causa de algumas resistências vistas na prática na implementação do processo de Gerenciamento de Problemas do ITIL. Como conseqüência se gera uma subutilização do que poderiam ser grandes benefícios que esta prática se propõe a trazer. A proposta deste artigo está focada em esclarecer algumas possíveis confusões que este termo possa ter causado na implementação do Gerenciamento de Problemas do mundo ITIL, e destacar a importância que o Gerenciamento de Problemas tem no Gerenciamento de Serviços de TI.

2 2. SÓ TEM PROBLEMAS QUEM OS QUER! Sabemos que o Gerenciamento de Incidentes tem como objetivo resolver incidentes em um prazo relativamente curto, especificamente dentro do período negociado e predefinido nos acordos de nível de serviço. Quanto maior a gravidade do incidente, menor também é o tempo de resolução exigido. A gravidade é entendida como o nível de comprometimento com o negócio, uma relação de impacto e urgência. Entende-se que a origem dos incidentes está relacionada a eventos, que na sua grande maioria são inesperados e reativos. Se agora tentássemos fazer o contrario, procurar um termo do ITIL que melhor se enquadre no conceito de problema no contexto cotidiano, a candidata será com certeza a palavra incidente. No incidente há uma convocação a agir frente a algo que aparece, surge quase inesperadamente, e dependendo da sua gravidade, é preciso resolver de maneira imediata. Exemplos poderiam ser os seguintes: o carro não deu partida cedo de manhã; o carro está perdendo óleo; que o bebe caiu do sofá e se machucou; o celular deixou de funcionar. Alguns destes incidentes (ou problemas como seriam chamados), poderiam não ser resolvidos de maneira definitiva: podemos completar o óleo do motor do carro e continuar dirigindo até levá-lo definitivamente ao mecânico. Poderíamos até conviver com isso, e não levar nunca o carro à oficina. Essa liberdade de escolha, de querer saber ou não qual é a causa da perda de óleo e eventualmente resolver definitivamente a situação, para evitar ter que completar freqüentemente (e provavelmente evitar problemas maiores no futuro), é um dos objetivos do Gerenciamento de Problemas em ITIL: evitar novos incidentes, principalmente os graves. A possibilidade de investigar o porquê do incidente, como foi que aconteceu e o quê fazer para evitar novas ocorrências, têm como base o conceito de problema em ITIL, implementado no processo Gerenciamento de Problemas, gestão separada do Gerenciamento de Incidentes. Entende-se aqui como uma vontade, um desejo ou uma necessidade de ir atrás das causas. Esta atividade fica quase impossível para o dia a dia do Gerenciamento de Incidentes, devido ao posicionamento ativo frente à resolução imediata de eventos e à grande pressão sob prazo. Incidente Gerenciamento de Incidentes Registro Base de Comparaçã Incidentes Comparaçã Soluções e Reparações temporais Gerenciamento de Problemas Base de Problemas e Erros Conhecidos Problem Investigação e Erro conhecido Figura 1: relacionamentos entre os Gerenciamentos de Incidentes e Problemas

3 A decisão de investigar causas de um incidente é opcional. Depende da gravidade, dos recursos disponíveis, das políticas, das prioridades dos Gestores, do próprio Gerenciamento de Problemas e da relação com o Gerenciamento de Incidentes. Os incidentes têm uma origem involuntária e na grande maioria das vezes são reativos. Os problemas sempre têm uma origem associada a uma vontade de investigar e de investir recursos para obter um resultado de melhoria. É por esta razão que existe a rigor uma atividade chave, no inicio do processo, logo após o registro, cujo objetivo é a aprovação da execução investigação. Esta atividade de aprovação foca principalmente na priorização por importância, na analise dos recursos, dos custos, do impacto ao negócio. A partir destas variáveis, define a estratégia e plano de investigação com focos no retorno, nos benefícios com o uso de recursos limitados. 3. RELAÇÕES E DESCONEXÕES ENTRE O GERENCIAMENTO DE PROBLEMAS E DE INCIDENTES Com o intuito de desenvolver estes argumentos, a continuação serão citados alguns pontos de atenção, que observados em diferentes contexto de projetos ITIL, comprometeram de alguma maneira os objetivos desejados do Gerenciamento de Problemas. Não é objetivo esgotar sua extensão e sim sensibilizar com relação a sua implementação, melhoria continuada dos serviços e os ganhos de maturidade do Gerenciamento de Serviços de TI. 3.1 RELAÇÕES ENTRE O GERENCIAMENTO DE INCIDENTES E PROBLEMAS: Antes de analisar os possíveis desvios, é importante mencionar o posicionamento que cada um destes dois processos tem frente ao Gerenciamento de Serviços e como estes dois processos se relacionam. O gerenciamento de incidentes é reativo e precisa agir rápido. Para conseguir tal agilidade se utiliza de varias ferramentas, algumas delas são fornecidas pelo processo de gerenciamento de problemas: 1. Soluções de Contorno são receitas de rápida execução que se aplicadas, podem resolver incidentes em forma eficiente, mesmo que temporariamente. Reiniciar a aplicação ou o computador, apagar os arquivos temporais e lixo da máquina, matar(kill) algum processo travado. o Quem poderia propor Soluções de Contorno? Em principio, qualquer analista do processo de Gerenciamento de Problemas ou do Gerenciamento de Incidentes ou de qualquer outro processo do Gerenciamento de Serviços. o Quando uma Solução de Contorno pode ser utilizada? Toda Solução proposta deveria passar por uma aprovação explicita da equipe de problemas com a finalidade de garantir que seja realmente uma solução viável, efetiva, repetível, confiável e segura. Deve-se garantir a existência de mecanismos de classificação que permitam realizar buscas sem ambigüidade. Deve-se garantir que o pessoal que vai aplicar a Solução esteja treinado, com os acessos e os privilégios adequados para sua execução. Daí a necessidade de planificar a implantação da solução. 2. Script ou roteiros: A Central de Serviços (Service Desk) deve ser munida de recursos que permitam se aproximar ao foco do incidente para classificá-lo e assim circunscrevê-lo de maneira a ter um contexto preciso, fonte fundamental para procurar Soluções de Contorno adequadas e escalamentos às equipes certas. É importante que estes roteiros estejam em constante manutenção para refinar a aprimorar a precisão dos resultados. As equipes de problema são por

4 definição, analistas especialistas, que pela importância do trabalho na infraestrutura da organização, são os maiores conhecedores das fragilidades e fortalezas de TI. Junto a eles, estes roteiros poderiam ser mais efetivos. 3. Atividades e tratamento: Existem habilidades bem diferentes entre os dois papeis de analistas nos processos de Gerenciamento de Problemas e Gerenciamento de Incidentes. No processo de Incidentes o analista foca no sintoma, nos efeitos e intenta o restabelecimento usando técnicas de curto prazo, geralmente simples como executar um script, reset de máquina, levantar uma aplicação, etc. Não se preocupa no desenvolvimento de uma analise de causa raiz, que é o foco do analista do processo de Problemas, cujo objetivo é a investigação podendo utilizar técnicas como por exemplo, o método Hishikawa, o método George Polya, o método Kepner Tregoe, o método Hitoshi Kume, ou qualquer outro. Muitas vezes as mesmas equipes desenvolvem tanto papeis de um processo quanto do outro. Um efeito negativo deste acumulo de função, é a tendência a igualar as atividades de ambos os processos, sendo necessário reforçar constantemente o processo e seus objetivos. 3.2 DESCONEXÕES ENTRE O GERENCIAMENTO DE INCIDENTES E PROBLEMAS: Algumas implementações do Gerenciamento de Serviços baseadas em ITIL tem se afastado consideravelmente desta visão original. Cria-se algumas práticas que até usam os mesmos termos, mas a implementação é diferente. A lista a continuação, aponta no sentido de destacar estas diferenças encontradas em vários projetos encontradas no mercado. 1. Problemas e Incidentes graves: Em algumas organizações, há um tratamento diferenciado para incidentes graves ou incidentes de altíssimo impacto. São incidentes que, pelos efeitos sensíveis frente ao negócio, são escalados, acompanhados, monitorados pelos próprios diretores de TI. Isso está contemplado dentro das boas práticas do ITIL. É até recomendado. Diretores têm telas de monitoração nas suas salas com holofotes apontando a este grupo de incidentes (incidentes que em alguns lugares são nomeados de problemas ). Como há prioridade e facilidade para obter recursos para este grupo de problemas, se multiplica também o interesse por parte da comunidade de usuários e equipes técnicas, de intentar negociar a promoção ao estagio de problemas, com a finalidade de ganharem visibilidade e foco para a resolução. Até projetos de melhoria não escapam da tentativa de ganhar espaço e prioridade dentre esta elite de problemas. Para conseguir realizar alguma filtragem neste funil, é definido um comitê ad-hoc que recebe as propostas de incidentes comuns, com a finalidade avaliar os argumentos e prioridades do momento, para transformá-los em problemas. o O que aparece como conflitante, é que a partir da categorização sejam chamados de problemas, sem ainda ter restaurado o serviço. Não foi ainda aplicada alguma solução de contorno, ou seja, no fundo continuam sendo incidentes abertos, só que gerenciados pelo Gerenciamento de Problemas. o Não há gerenciamento de melhoria pro-ativa: neste cenário, fica claro que nos afastamos bastante da origem do conceito ITIL de problema, operando numa organização de TI do tipo bombeiro, onde o foco que é dado da diretoria é continuamente apagar incêndios.

5 2. Incidentes viram Problemas: Outra situação observada tem relação com a necessidade de envolver outros especialistas quando não se consegue achar e/ou aplicar uma Solução de Contorno para resolver o Incidente. Ou seja, algumas vezes, se envolvem pessoas que trabalham no Gerenciamento de Problemas para ajudá-los a restaurar os serviços parados. Até ai, é esperado chamar especialistas, mas todos nesse instante atuam com o chapéu de Grupo de Suporte de Incidentes. O contraditório é que seja registrado um Problema e associado ao incidente, com a finalidade de passar o bastão a outra equipe, a outro Gerenciamento neste caso, para que assuma a resolução do Incidente. Para realizar isso, é possível fazer o escalamento funcional do Incidentes a outras equipes, mas sempre dentro do escopo do Gerenciamento de Incidentes. Um Incidente nunca vira um Problema. Geralmente após a Resolução do Incidente, pela aplicação de uma Solução de Contorno, pode existir a necessidade de investigar a Causa Raiz e posteriormente desenvolver uma Solução Definitiva, mas estes passos são num outro espaço, numa outra velocidade, num outro objetivo, muito longe de restaurar o serviço imediatamente. 3. Fechamento automático de Incidentes na Resolução do Problema: Um outro erro comum que é sugerido para automatizar em ferramentas de Gerenciamento de Serviços ITSM (Information Technology System Management) é que uma vez resolvido o problema, exista algum mecanismo que em cascata, resolva seus incidentes. Os Gerentes devem estar muito alerta com este tipo de sugestões, que de alguma maneira manifestam a materialização de procedimentos de delegação de responsabilidade mencionados no item anterior. Não se deve esquecer que o objetivo do problema é investigar a Causa Raiz para evitar que novos Incidentes voltem a acontecer. Posteriormente, implementar uma Solução definitiva, a qual não deveria ter incidentes pendurados sob a sua responsabilidade. 4. Restringir o registro de Problemas?: Pelo geral, restringir o registro de Problemas a somente um pequeno grupo de pessoas, é também limitar a organização de TI na capacidade de coletar e assim conhecer pontos de melhoria que podem surgir a partir dos grupos técnicos e operacionais que trabalham de perto com a infra-estrutura e sistemas em operação. Uma argumentação para este tipo de medida é a incapacidade de administrar uma demanda alta de pedidos. Ferramentas atuais têm mecanismos de categorizar, priorizar e se espera que até consigam recusar Solicitações de Investigação, antes de serem formalizados em Problemas. Diversificar as fontes de registro de Problemas é também estimular a criatividade do pessoal técnico e da operação para encontrar melhores opções para a configuração existente da infra-estrutura de TI. 5. Exigir SLA no Gerenciamento de Problemas: Exigir tempo de resolução de problemas dentro do mesmo contexto de incidentes, pode ser contraditório com a própria proposta de investigar a Causa Raiz. Investigação é um ato que pode demorar se utilizam de técnicas especificas ou muito especialistas. É recomendado que sejam estimulados aspectos criativos para encontrar soluções, algo não compatível com a pressão de um resultado imediato. Exigir resultado imediato, peca em qualidade. É ai que há um balanceamento que precisa ser equilibrado: velocidade versus qualidade, custos versus benefícios, foco no negocio versus o foco técnico. Do ponto de vista de solicitar prazo, uma vez descoberta a Causa Raiz, é possível planejar a implementação: compra de

6 nova maquina, aquisição de uma nova versão, implementar novas funcionalidades que evitem situações não desejadas, etc. A exigência de um prazo até para definir a Causa Raiz pode comprometer a qualidade do achado. 4. BENEFÍCIOS DO GERENCIAMENTO DE PROBLEMAS Na medida em que estes dois processos, Gerenciamento de Incidentes e Gerenciamento de Problemas, trabalhem de forma alinhada a seus objetivos, podemse obter alguns benefícios significativos para ganhar amadurecimento e estabilidade no Gerenciamento de Serviços de TI. Se espera que o Gerenciamento de Problemas gere Soluções de Contorno para que o Gerenciamento de Incidentes possa trabalhar em forma rápida e eficiente; Também que investigue a Causa Raiz dos incidentes, mas priorizando naqueles que tem maior relevância para o negócio, para assim poder direcionar os esforços justificando custos, para obter finalmente uma TI mais eficaz. Espera-se também que o Gerenciamento de Incidentes utilize e alinhe os mecanismos que lhe permitam a resolução rápida de Incidentes, de maneira a refinar as Soluções de Contorno. Desta maneira, o Gerenciamento de Problemas proporciona um caminho de estabilizar a organização de TI, que parte de foco primário de apagar incêndios a uma estabilidade frente ao negócio, contribuindo na melhoria a imagem de TI, e na participação de agregar valor frente à organização. 5. CONCLUSÃO O Gerenciamento de Problemas é um processo amplamente implantado nas organizações de TI. No geral, é um dos primeiros processos a ser implementado junto ao Gerenciamento de Incidentes, Gerenciamento da Configuração e o Gerenciamento da Mudança. Tem se observado que é também um dos processos bem mais incompreendido na fase da implantação, deixando várias seqüelas dentro do Gerenciamento de Serviço de TI, inclusive uma rejeição interna dos próprios grupos de suporte. Exigências vindas de diretores com foco na velocidade de resolução, já indicam que até os gestores não conseguem ter uma visão de melhoria, ficando presos em posições reativas, numa TI que não consegue amadurecer. Através deste artigo, foram abordados alguns destes mal-entendidos que podem causar esta situação. São confrontados e questionados estes enfoques apresentando os benefícios perdidos quando não adotados. 6. REFERENCIAS ITIL Lifecycle Publication Suite V3 Office of Government Commerce (OGC) ITIL Managing IT services. ITIL V3 Service Operation, Office of Government Commerce (OGC) ITIL Managing IT services.