Problemas, sejam bem-vindos!

Tempo de leitura: menos de 1 minuto

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, tranquila 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.

 

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.

 

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.

 

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.

 

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.

 

  • 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.

 

  • 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 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.

 

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 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.

 

  • 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.

 

 

 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 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.

 

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, podemos 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.

 

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.

 

REFERÊNCIAS

• 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.

17 Comentários


  1. Parabéns pela ótima abordagem. Fiquei muito contente em saber que tudo o que defendo diariamente no meu ambiente de trabalho sobre esses dois processos, está totalmente coerente com este artigo. Fiquei até emocionada rsrs
    Abraços e sucesso.

    Responder

  2. Heinz, belissimo artigo e um desafio para os gestores de TI pensarem desta forma para que eles possam pensar em convencer as áreas de negocios a investirem neste processo que é primordial para qualquer organização.

    Responder

  3. Heinz, disse TUDO e mais um pouco sobre IN e PB. Parabéns!!!
    Meu ponto de obsevação é “apenas” incluirmos o conceito/aspecto da Gestão do Conhecimento (Base), a qual certamente auxilia e aperfeiçoa a operacionalização desses 02 Processos no mundo ITSM, considerando N Scripts de atendimentos, Procedimentos, Manuais, Checklists, Soluções de contorno e definitivas…

    Responder

  4. Obrigado pessoal, o tema do gerenciamento de problemas geralmente se presta a confusões, e daí que optei por escrever este artigo. Obrigado Fabiana, Samyr, Alberto, Master Daniel e Marcelo. Com relação ao Gerenciamento do Conhecimento, vou tentar escrever umas palavras num próximo artigo, já que o ITIL veio com uma proposta super interessante, abrangente e ousada para poder ser mais assertivo na tomada de decisões. Um forte abraço a todos!

    Responder

  5. Parabéns Heinz. Fanástica explanação de fácil entendimento. Aprendi muito com esse texto.

    Responder

  6. Parabéns pelo artigo. Achei muito útil, porém ainda fiquei com uma dúvida. Vejam se os colegas que leram o artigo e possivelmente o autor pode me responder.

    Como posso exigir do cliente onde tenho o gerenciamento documentado responsabilidades sobre as vulnerabilidades com hardware e serviços de servidores que podem prejudicar a empresa e seus processo, por exemplo de fechamento fiscal, folha de pagamento.

    Aguardo. Obrigado e ótimo fim de ano a todos.

    Responder

    1. Olá Roberto, tudo bem?

      Não sou o autor do artigo mas acho que posso dar um pitaco (rs).

      Existem dois possíveis caminhos, pelo pouco que entendo do seu cenário:

      1 – Esclarecer no SLA quais são as responsabilidades do cliente e como serão conduzidos os casos onde o provedor identificar vulnerabilidades que comprometam a sua entrega de serviço e/ou coloquem em risco o ambiente do cliente.
      2 – Criar algum mecanismo, como uma “carta de risco” onde o cliente compartilha os riscos sobre as vulnerabilidades identificadas no ambiente e que ainda não podem, ou não serão resolvidas por decisão exclusiva do próprio cliente.

      Espero ter ajudado. Grande abraço e boa sorte!

      Responder

      1. Olá Roberto e Renê

        Obrigado Renê pelo pitacos! Vou complementar sua resposta.

        O Gerenciamento de Problemas em um papel executor mas ele não trabalha sozinho. Quando analisamos as vulnerabilidades dos serviços e seus componentes (os ativos de serviços), estamos dentro do espaço do da GARANTIA do SERVIÇO, ou seja, os processos envolvidos são: Gerenciamento da Capacidade, Gerenciamento da Disponibilidade, Gerenciamento da Continuidade e Gerenciamento da Segurança da Informação.

        Estes processos criam e mantem PLANOS focados nos objetivos de qualidade, formalizados nos Acordos de Nível de Serviços. Nestes planos temos uma analise detalhada dos riscos e as ações necessárias, que exigem a evolução e melhorias. Isto deve fazer parte a otimização dos serviços alinhados aos patamares de qualidade dos serviços do ponto de vista estratégico. No mapeamento dos riscos, claramente estão as responsabilidades das partes interessadas. Aqui estão os pontos que entendo, é seu questionamento. As responsabilidades são definidas, comunicadas, engajadas, acotadas, limitadas, formalizadas, estabelecidas, conhecidas, transferidas, planejadas, acordadas, projetadas. Lembremos que se este trabalho de comunicação e determinação das responsabilidades não são formalizadas, sempre existirá uma “responsabilidade” do associadas ao fornecedor em apontar e atender escopos que estão baixo seus cuidados, independente se ele não tem poder de ação. Desta maneira evitamos muitos maus entendidos.

        Caso queira conversar mais ao respeito, fico a disposição. Espero ter esclarecido suas duvidas. Por favor, não duvide em questionar, caso tenha entendido errada sua colocação.

        Um forte abraço, feliz 2017.
        Heinz

        Responder

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *