Olá Caros Leitores!
Vamos falar um pouco sobre um assunto que está na vida de muitos profissionais de TI, que apesar de serem parecidos tem focos diferentes, e saber quanto investir de tempo em cada processo pode ser a receita do sucesso na sua empresa: Gerenciamento de Incidentes e Gerenciamento de Problemas. O processo de gerenciamento de incidentes tem o objetivo de restaurar a operação normal de um serviço o mais rápido possível. Este processo tem grande importância para que os Acordos de Nível de Serviço sejam cumpridos. O Gerenciamento de Problemas tem por objetivo encontrar a causa de um ou mais incidentes de forma a erradicá-los da infra-estrutura, evitando a recorrência dos incidentes e melhorando o atendimento aos Níveis de Serviço. Menos incidente maior disponibilidade.
Vejo que o assunto Gerenciamento de Incidentes é padrão nos Service Desk Brasil afora, o que não vejo a respeito do Gerenciamento de Problemas. A questão custo e ter equipes geralmente enxutas contribuem para isso. Apesar de não se falar muito em gestão de problemas, esta é uma atividade que sempre fizemos. O que há hoje é que tratamos problemas dentro dos incidentes.
Ficou confuso? Vou explicar melhor. Tratar problema dentro de incidente é após você restaurar a operação do serviço, deixar o “chamado”, “ticket” ou “incidente” aberto para encontrar a causa do incidente e através deste “chamado” resolver o problema de forma a evitar novos incidentes. O que a ITIL prega é que restaurado o serviço o “Incidente” seja encerrado, e um problema seja aberto, relacionando o ID do “Incidente” com o ID do “Problema” para que seja analisada a causa. Então nós sempre tratamos problemas, apesar de não ter um processo definido certo? Sim. Mas por não existir geralmente um processo de G. de Problemas definido e separado de Incidentes, deixamos de colher informações importantes e melhorar nossa tomada de decisão. Tratar incidentes e problemas no mesmo “chamado” faz com que saber o tamanho da fila de incidentes e problemas fique “impossível”. Saber quantos incidentes e quantos incidentes que “viraram” problemas os atendentes tem na fila também. Tirar um relatório de tempo médio de resolução dos incidentes então? Fica totalmente distorcido.
Qual a solução?
A solução é separar de fato os processos de gestão de incidentes e gestão de problemas. A equipe a ser utilizada pode ser a mesma, mesmo que isto não seja o recomendado pela ITIL. A solução é que sua ferramenta de Service Desk permita que Incidentes e Problemas sejam tratados separadamente, relacionando somente os IDs e Itens de Configuração dos Incidentes aos dos Problemas de maneira simples, para poder saber quantos incidentes estão relacionados ao problema, auxiliando assim na definição de prioridade para resolução dos problemas. Se temos os processos de G. Incidente e G. Problema definidos e os resolvedores são os mesmos, quanto tempo devo dedicar para cada processo ? Vou lhe responder a lá ITIL: “O seu negócio deve definir”. Já ouvi em algum lugar que a ITIL sugere que 80% do tempo se resolvam incidentes e 20% problemas, mas nunca encontrei isto na documentação. Com processos separados e com o correr do tempo, você irá conseguir extrair informações importantes e poder analisar quanto tempo dedicar para cada processo.
Implementar o processo de Gerenciamento de Problemas é mais uma questão de organização do que “fazer mais coisas com o mesmo número de atendentes”, isso claro se sua ferramenta de Service Desk permitir de uma maneira simples, senão concordo que isto vira um pesadelo! Os benefícios desta separação para a equipe e para os tomadores de decisão são muitos, desde melhora no moral da equipe, passando aumento da maturidade do Service Desk e informações mais precisas para os tomadores de decisão.
Na sua empresa, quais processos existem no Service Desk? Incidentes? Problemas? Deixe-nos saber, traga para discussão.
Um grande abraço!
7 Comentários
O triste é saber que isso na maior parte dos casos, ou melhor, na maioria das empresas não existe. Gestão de Problemas? ITIL? WTF?
Um grande responsável por não haver padrões para anaálise/resolução de incidentes, acidentes e desastres na maioria das empresas é o custo que se tem para implantá-lo. A implantação de um framework, seja ele ITIL, Cobit, ISO e por aí vai é demasiado caro. Convencer a “Alta Gestão” da companhia que isso é importante para o negócio é uma missão possível para poucos.
Na organização onde trabalho infelizmente não trabalhamos dessa forma, nem ao menos possuímos um Service de Help Desk, vivemos trabalhando por demanda, sempre atendendo a chamados pelo telefone, nunca documentado.
Vejo com isso a necessidade urgente de se utilizar um software para documentar os chamados, incidentes e problemas. Qual o programa ideal para se utilizar para este fim, se existe algo open source?
Olá Márcio! Existem vários, entre eles OCOMON, OTRS.
Abs,
Emerson Dorow
Olá, aqui em nossa empresa já possuímos a G. de Incidentes. Agora a mesma equipe está tentando implantar a G. de problemas. Gostaria de pedir uma opinião de vocês, especialistas, quanto ao processo. Já temos o processo de G de incidentes que começa com uma ligação para o help desk até o fechamento desse incidente. E agora? Precisar ter um processo de abertura de problemas, como começo? A ferramenta que usamos é o Service Manager.
Olá Adriano!
O processo de gerenciamento de problemas tem 2 “faces”, uma mais pro-ativa e uma mais reativa. Na reativa, a idéia é você investigar os incidentes ocorridos com os ICs e identificar situações recorrentes onde uma análise mais aprofundada poderá levar vocês a resolverem definitivamente estes incidentes.
A parte pró-ativa vamos dizer você também poderá analisar relatórios gerenciais procurando tendências e que vocês possam tomar ações mesmo antes dos incidentes ocorrerem como atualização de um software, ampliação da capacidade e etc.
O problema acredito que será um “chamado” geralmente aberto pela própria equipe de TI. O interessante é você relacionar os IDs dos incidentes com o ID do problema.
Espero ter-lhe ajudado.
Abs,
Emerson Dorow
Emmerson,
na empresa que trabalho também só havia Gerenciamento de Incidentes. Após minha certificação em ITIL dei a idéia de implantarmos o processo de Gerenciamento de Problemas. A questão é que, apesar das promessas, nunca houve investimento na equipe e eu acabei assumindo todas as atividades sozinho. Além de gerenciar os chamados abertos pelo segundo nível, acabo atuando como uma espécie de suporte de terceiro nível, fazendo bastante operacional. Isso é comum de acontecer em outras empresas? Não estou mais aguentando a situação. Minha proposta era outra.
Rodrigo,
Não sei a quantidade de pessoas que tens na sua equipe. No seu caso eu diria o seguinte:
Equipe N1: pessoal responsável por atender o telefone/chat/web.
Equipe N2: Pessoal focado em trabalhar mais em projetos e mais especialistas. É este pessoal que você pode colocar para resolver os problemas
Equipe Field Support: A galera que dá suporte em campo, que vai até o usuário. Esse pessoal pode fazer parte do nível 1 até, mas tem que ter um foco maior no suporte na mesa do usuário.
O desafio de qualquer projeto da empresa, e principalmente de TI é justificar o retorno que seu projeto vai dar. O desafio é você provar por A + B que tendo gerenciamento de problemas a empresa vai economizar tanto, ter mais qualidade e todos os outros benefícios. Imagine com o dinheiro que irá investir no seu projeto o dono da empresa poderia comprar o carro. Teu projeto valerá a pena se dentro de um prazo o lucro da empresa for melhor.
Abs,
Emerson Dorow