Quando a infraestrutura ou os sistemas falham ou travam inesperadamente, o tempo de inatividade de TI pode ter um impacto direto nos resultados financeiros e nas operações de negócio.
De acordo com o Gartner, o custo médio do tempo de inatividade de TI pode chegar a US $5.600 por minuto em operações complexas onde a TI é extremamente crítica (ex: operadoras de cartão, e-commerce, redes sociais, etc).
Embora a prática de gestão de incidentes contribua para uma resposta rápida e eficiente às falhas de TI, é no gerenciamento de problema que existe uma oportunidade de reduzir significativamente a recorrência de incidentes ou até mesmo evitar que eles aconteçam.
Se quiser conhecer mais sobre essa prática e descobrir o quanto ela pode transformar os resultados das operações de TI, continue lendo este artigo.
O que é gerenciamento de problemas?
O gerenciamento de problemas (também conhecido como gestão de problemas) é uma das 34 práticas descritas pelo ITIL e consiste em uma abordagem sistemática para identificar a causa de incidentes de TI atuais ou potenciais.
Em resumo, o objetivo é eliminar a causa raiz e evitar que o problema se repita. E caso isso seja inevitável, ao menos minimizar o seu impacto.
É importante entender que os problemas causam incidentes, e não o contrário. Os incidentes nada mais são do que a pior consequência possível de problemas que não foram resolvidos em tempo hábil.
A prática de gerenciamento de problemas é sempre reativa aos problemas: não os previne
de ocorrer pela primeira vez.
A distinção proativo/reativo refere-se a como a investigação do problema se relaciona com os incidentes:
- A gestão proativa de problemas ajuda a evitar que incidentes ocorram na primeira vez
- A gestão reativa de problemas ajuda a evitar a recorrência de incidentes e pode ajudar a resolver incidentes abertos.
Qual é o objetivo da prática de gerenciamento de problemas?
O objetivo principal do gerenciamento de problemas é reduzir a probabilidade e o impacto dos incidentes, identificando as causas reais e potenciais dos incidentes, gerenciando soluções alternativas e erros conhecidos.
É importante assumir a premissa de que nenhum serviço é perfeito.
Todo serviço tem erros ou falhas que podem causar incidentes. E estas falhas ou erros podem ter origens das mais variadas possíveis.
Por exemplo, um erro em um contrato de terceiros tem tanta probabilidade de causar um incidente quanto a de um dispositivo de rede.
Muitos erros são identificados antes de um serviço entrar em operação e são resolvidos durante o design, desenvolvimento ou teste. No entanto, alguns permanecerão desconhecidos e seguirão até o ambiente de produção, podendo causar incidentes que serão percebidos pelos usuários e clientes de um serviço.
Portanto, em última instância, a prática de gestão de problemas visa identificar e analisar erros nos produtos da organização, a fim de minimizar seus impactos negativos nos serviços prestados.
Qual a diferença entre gestão de incidentes e gestão de problemas?
Não dá pra seguirmos adiante neste texto antes de assegurar o seu entendimento sobre estes dois conceitos: problemas e incidentes.
Para explicar a diferença entre estes dois, destaco abaixo um trecho do meu livro ITIL® na Prática: Gerenciando Problemas de Infraestrutura e Serviços de TI.
Para entender melhor o contexto do Gerenciamento de Problemas, vamos refletir sobre uma situação bem cotidiana:
Quando contraímos uma gripe, um resfriado ou alguma outra doença mais séria, nós sofremos reações, como tosse, febre, vômito, dores de cabeça, etc.
São sintomas que apresentamos quando nosso organismo não está funcionando como deveria, e que podem prejudicar a nossa saúde e as nossas atividades rotineiras de alguma forma.
De acordo com a frequência e a gravidade dos sintomas, muitas vezes é necessário buscar a sua causa, para assim poder combater a origem, evitar a recorrência ou consequências mais graves. Nestes casos, normalmente procuramos um médico especialista e somos submetidos a uma série de exames e diagnósticos.
Quando finalmente a causa do(s) sintoma(s) é identificada, temos duas possibilidades:
- Tratar a causa de forma definitiva (antibiótico, cirurgia, etc.);
- Quando o tratamento definitivo da causa não é possível, como uma doença sem cura, ou mesmo quando o tratamento não seja viável, os sintomas podem ser aliviados ou controlados através de soluções temporárias (medicamentos, terapia, etc.) que são indicadas pelo médico especialista.
No contexto dos Serviços de TI também funciona assim.
A diferença é que os sintomas são as falhas que ocorrem na operação normal de um serviço de TI (ex.: uma aplicação apresentando erro, internet lenta, um e-mail que não sai da caixa de saída).
Com isso, podemos chegar ao consenso de que um incidente nada mais é do que um sintoma. E à causa não identificada de um ou vários incidentes (sintomas, falhas), dá- se o nome de ‘Problema’.
Veja na tabela abaixo as principais diferenças entre a gestão de incidentes e a gestão de problemas.
| Gestão de Incidentes | Gestão de Problemas | |
| Objetivo | Resolver os incidentes para restabelecer a operação normal do serviço | Encontrar a causa raiz dos incidentes para evitar que ocorram novamente |
| Foco | Curtíssimo prazo – Resolver imediatamente o incidente | Médio-longo prazo – investigar, analisar e encontrar uma correção para a causa raiz do problema |
| Exemplo | Servidor travado – Corrigir o erro de configuração e reiniciar o servidor | Servidor travado – Corrigir as falhas do sistema ou do processo que causaram o erro de configuração |
| Reincidências | Seguir a modelos de incidentes para responder a incidentes repetidos de forma consistente | Analisar tendências e padrões em incidentes repetidos para impedir que eles ocorram novamente |
Quais são os benefícios da gestão de problemas?
Uma gestão de problemas, quando bem executada, pode trazer uma série de benefícios – inclusive financeiros – para a empresa.
Otimização do tempo
Uma das principais contribuições da prática de gestão de problemas é o mapeamento dos erros conhecidos e a documentação das soluções de contorno. O que consequentemente reduz o tempo de resposta aos incidentes.
Um erro conhecido se trata de um problema que foi analisado e, embora ainda não resolvido, já possui uma solução de contorno.
Uma solução de contorno reduz ou elimina o impacto de um incidente ou problema para o qual uma resolução completa ainda não esteja disponível. Algumas soluções de contorno também podem reduzir a probabilidade de incidentes.
Redução de custos
A base de erros conhecidos e as soluções de contorno também favorecem a redução de custos, uma vez que a atuação de equipes especializadas se tornam cada vez menos necessárias em casos já conhecidos e mapeados anteriormente.
Produtividade
Ao endereçar os problemas e evitar todo o retrabalho em torno das reincidências, a produtividade das equipes de TI aumenta. Isso permite que possam se dedicar mais aos projetos e inovações.
Uma vez que os serviços estejam com estabilidade e disponíveis, isso também favorece a produtividade de clientes e usuários do serviço, que muitas vezes são os próprios colaboradores da empresa.
Colaboração
A gestão de problemas envolve interação entre equipes multidisciplinares e investigação profunda da causa dos problemas. Por conta disso, uma cultura forte de colaboração e blameless é extremamente importante para que as equipes se sintam confortáveis para atuarem nos problemas.
Melhoria contínua do serviço
A gestão de problemas contribui para a melhoria contínua dos serviços, podendo ir além do tratamento de problemas de infraestrutura. Isso é especialmente possível quando a gestão de problemas é incorporada como uma competência e não como uma área especializada dentro da empresa.
Por exemplo, se uma organização decide tratar cada não conformidade de seu sistema de gestão como um problema, terá segurança de que o processo de tratamento das não conformidades passará por atividades criteriosas de diagnóstico e investigação da causa raiz, trazendo mais eficiência para as atividades de melhoria contínua.
Satisfação do cliente
Sabemos que a percepção de valor e a satisfação do cliente são influenciadas pela experiência como um todo e não somente por indicadores mais tácitos, como disponibilidade de serviços.
Mas certamente a satisfação dos clientes e a confiança na TI será positivamente influenciada se houver menos incidentes.
O processo de gerenciamento de problemas
Existe um conjunto de atividades e abordagens que favorecem os resultados esperados pela prática do gerenciamento de problemas. A seguir você irá conhecer a anatomia de um bom processo para gerenciar problemas.
Abordagem proativa vs reativa
Existem duas abordagens para a gestão de problemas:
Gestão de Problemas reativa: Analisa incidentes que já acontecem, ajudando a resolvê-los e evitando que voltem a ocorrer
Gestão de Problemas proativa: Previne a ocorrência de incidentes pela primeira vez descobrindo desvios no desempenho dos serviços pelos alertas da infraestrutura de monitoramento, vulnerabilidades e bugs relatados por fornecedores, resultados de auditorias, etc.
De forma mais prática, a abordagem reativa espera por um problema e depois o corrige. Normalmente essa manifestação acontece por meio de um incidente. Imagine, por exemplo, a instalação de um alarme contra roubo após uma casa ser roubada.
Por outro lado, a abordagem proativa identifica estratégias para evitar a ocorrência de problemas. É como instalar uma segurança doméstica inteligente antes que o roubo (incidente) ocorra.
Na tabela abaixo há um resumo das diferenças:
| Gestão de problemas reativa | Gestão de problemas proativa | |
| Abordagem | Resolver problemas que causam incidentes | Tomar medidas para prevenir futuros problemas (e seus incidentes resultantes) |
| Objetivo | Reduzir a frequência e a repetição de incidentes | Assegurar a melhoria contínua de todo o sistema |
| Desencadeador | Incidentes existentes | Riscos potenciais |
| Implementação | Analisar a causa por trás de um incidente, e corrigir | Analisar futuros riscos e implementar medidas proativamente |
Atividades da gestão de problemas
As principais atividades envolvidas na gestão de problemas são descritas a seguir.
1. Identificação do problema
Dependendo da abordagem utilizada (proativa, reativa, ou ambas) um problema pode ser identificado a partir da seguintes fontes:
- Informações sobre incidentes em andamento
- Registros e relatórios de incidentes
- Dados de monitoramento
- Dados de configuração do serviço
- Vulnerabilidades notificadas por fornecedores
- Descoberta de erros no ambiente de produção por parte de desenvolvedores, designers ou testers
- experiências compartilhadas por usuários e comunidades especializadas
- eventos da monitoração da infraestrutura, descobrir desvios no desempenho dos sistemas que ainda não se qualificam como incidentes
- auditorias técnicas e outras avaliações.
2. Registro, priorização e atribuição do problema
Uma vez identificado, o problema deve ser registrado, priorizado é atribuído.
A categorização inicial de um problema geralmente inclui algumas das seguintes informações (se conhecidas ou razoavelmente presumidas) :
- Descrição
- Incidentes associados e suas soluções
- Itens de configurações e/ou classes de Itens de Configurações associados
- Impacto estimado e probabilidade de incidentes futuros
- Serviços associados e potencialmente afetados
- Impacto na organização e nos clientes
- Impacto estimado e probabilidade de incidente
Cada organização define a forma que irá priorizar os problemas. Mas é recomendável seguir algumas diretrizes, como:
- Avaliar o impacto e a urgência de um problema
- Priorizar apenas apenas quando há um conflito de recursos
- Considerar a possibilidade dos problemas serem planejados usando um único backlog, juntamente com outras tarefas (planejadas e não planejadas).
- Se um problema for tratado por várias equipes, ele será priorizado dentro de cada equipe, dependendo da disponibilidade de recursos, tempo de conclusão desejado e tempo de processamento estimado.
- Ferramentas de visualização, como Kanban, e princípios Lean, como a limitação do trabalho em andamento, são úteis para uma priorização eficaz.
3. Investigação e determinação da causa raiz
A análise de causa raiz não deve se limitar ao item de configuração, mas incluir todas as dimensões, como comportamento do usuário, erros humanos, etc.
Várias técnicas de determinação de problemas podem ser empregadas nesta etapa. A tabela a seguir apresenta algumas delas e em quais situações são mais aplicáveis.
| Situação | Abordagens e técnicas sugeridas |
| Problemas complexos onde uma sequência de eventos deve ser elaborada para determinar exatamente o que ocorreu |
|
| Incerteza sobre quais problemas devem ser endereçados primeiro |
|
| Incerteza se a causa raiz apresentada é, de fato, a causa raiz |
|
| Problemas intermitentes que não podem ser recriados ou repetidos em um ambiente de teste |
|
| Incerteza sobre onde começar para problemas que aparentam ter múltiplas causas |
|
| Buscando identificar o exato ponto de falha para um problema |
|
| Incerteza por onde começar na tentativa de encontrar a causa raiz |
|
4. Desenvolvimento de um plano de resolução
Quando um problema é analisado (ou seja, os erros nos produtos foram localizados e seu impacto nos serviços foi avaliado), ele assume um status de erro conhecido.
Soluções definitivas para problemas podem desencadear a necessidade de projetos. Algumas soluções corrigem erros, mas outras podem introduzir soluções de contorno.
As soluções de contorno são procedimentos que não corrigem a raiz do problema, mas podem reduzir a probabilidade dos incidentes resultantes do problema ocorrerem. Além disso, as soluções de contorno também podem ajudar a resolver os incidentes mais rápido e melhor quando eles ocorrem.
De toda forma, soluções de contorno que se tornam definitivas devem ser evitadas sempre que possível.
Muitos erros conhecidos permanecem abertos por muito tempo se não puderem ser resolvidos com eficiência e continuam afetando os serviços. Nesses casos, a organização pode se concentrar em maximizar a eficácia e a eficiência do tratamento de incidentes (às vezes até o nível de detecção e resolução totalmente automatizadas), mas os registros de problemas devem permanecer abertos e revisados periodicamente.
5. Resolver e encerrar
Os registros de problemas podem ser fechados somente se uma das seguintes condições for atendida:
- O problema é resolvido: o risco de incidentes associados ao problema é removido ou reduzido a um nível aceitável.
- O problema não afeta mais a organização.
Por onde começar o gerenciamento de problemas?
Uma das perguntas mais frequentes sobre a gestão de problemas é: por onde começar?
Não há respostas certas a respeito disso. Em geral, organizações que nunca fizeram gestão de problemas provavelmente irão iniciar por uma abordagem reativa, mirando em incidentes críticos e reincidentes.
A partir do momento em que a gestão de problemas vai sendo incorporada no dia-a-dia das equipes, é possível iniciar abordagens proativas, olhando para dados de monitoramento ou até mesmo ampliando o escopo para questões dos serviços como um todo e mais próximas do negócio
Quais são os fatores de sucesso do gerenciamento de problemas e como mensurar?
A prática de gestão de problemas deve se preocupar com os seguintes fatores de sucesso
Identificar e compreender os problemas e seu impacto nos serviços
As organizações devem entender os erros em seus produtos, pois podem causar incidentes e afetar a qualidade do serviço e a satisfação do cliente. A prática de gestão de problemas garante a identificação de problemas e, assim, contribui para a melhoria contínua de produtos e serviços. Isso é mais eficaz se executado de forma proativa em vez de reativa.
As métricas-chave para mensurar este fator de sucesso são:
- Número dos problemas identificados ao longo do período
- Número de incidentes que não estão associados a erros conhecidos
- Número de incidentes que exigem investigação urgente de problemas
Otimizar a resolução e mitigação de problemas
Quando os problemas são identificados, eles devem ser tratados de forma eficaz e eficiente. Raramente é possível corrigir (remover) todos os problemas nos produtos e serviços de uma organização, mas a identificação sem resolução é significativamente menos valiosa para a organização e seus clientes.
Deve ser definida uma abordagem equilibrada para a mitigação de problemas, que considere os custos associados, riscos e impactos na qualidade do serviço.
As métricas-chave para mensurar este fator de sucesso são:
- Número de incidentes evitados pela resolução de problemas
- Número de incidentes resolvidos com soluções fornecidas pela investigação de problemas
- Número de erros conhecidos que permanecem abertos
A atuação da TI na gestão de problemas
Não há prescrição sobre como a TI deve se organizar para fazer a gestão de problemas.
Em geral, há dois papéis específicos desta prática que podem ser encontrados nas organizações: gerente de problemas e coordenador de problemas.
Esses papéis são frequentemente introduzidos em organizações onde o número de problemas é alto. Em outras organizações, as atividades de gestão de problemas são coordenadas por uma pessoa ou equipe responsável pelos itens de configuração, serviço ou produto ao qual o problema está associado. Pode ser o proprietário do recurso, proprietário do serviço ou proprietário do produto, respectivamente.
Conclusão
Problemas e seus incidentes resultantes podem causar uma enorme pressão sobre as organizações de TI e as empresas. O uso da prática de gestão de problemas oferece uma abordagem estruturada para reduzir esses problemas.
Se você implementar abordagens reativas e proativas, estará sempre um passo à frente dos problemas. E esse é o único caminho para evitar uma TI cujo trabalho é apenas enxugar gelo.
Aqui no ITSM na Prática temos diversos treinamentos para certificações na área de ITSM , inclusive uma especialização em Gerenciamento de Problemas.
um mouse que não funciona perfeitamente, ou seja, um dia funciona outro não. E o usuário reclama para o Service Desk. Este tipo de reclamação é considerado um incidente ou um problema? Porque ?
Olá Ines!
Vai depender muito do impacto que o não funcionamento deste mouse exerce sobre o negócio, alguns exemplos:
– o fechamento do mês pode ser impactado pelo não funcionamento do mouse (no caso de o usuário ser o responsável por essa atividade)?
– o mouse pertence a algum executivo senior, que deixa realizar atividades importantíssimas pelo não funcionamento do mouse?
– o trabalho de arrumar todo dia uma solução de contorno impacta o rendimento da equipe de ti?
Se uma das respostas for SIM, muito provavelmente vc deva considerá-lo como um problema. Existem N outros exemplos. O que é importante saber é que você precisa de critérios pré-estabelecidos e validados para eleição de um problema, senão tudo acaba virando problema, e não é esse o objetivo. Capisce?
Abraços e obrigado por nos acompanhar!
Olá… tenho algumas duvidas quanto a gestao de problemas….. O caso do mouse acima… Nesse caso o mouse nao pertence a nenhum diretor e muito menos a alguem do negocio mas, está atrapalnado um usuário… No caso de uma solução de contorno, colocaríamos um mouse BKP mas, para enviar o mouse atual, precisariamos abrir uma GMUD para a substituição desse item de configuração? Impressora parou de funcionar e muitos usuários estão parados…. O incidente é aberto e a solução de contorno ´´e enviar para outra impressora… Nesse caso o Incidente é finalizado e aberto um como problema? No caso de gestao de problemas identificar que precisa substituir a impressora, é gerado uma GMUD?
Olá Flávio!
Faz mais sentido, e é bem mais comum, considerar apenas componentes mais críticos como itens de configuração. Um mouse dificilmente vai ser considerado como um IC(acho que o exemplo dado com um mouse não foi muito feliz rs).
Quando você elege um componente como item de configuração, esse item passa a ser de dominio da gestão de configuração, e portanto todas as mudanças neste componente devem ser controladas. Quanto maior a abrangência do seu banco de dados de configuração, maior a complexidade em controla-lo.
Quanto ao exemplo da impressora, você está certo quanto a finalização de um incidente, ele deve ser fechado quando o serviço retornou ao seu estado normal de funcionamento. Mas não é necessário aguardar a finalização de um incidente para registrar um problema. Eles podem inclusive andar em paralelo (são registros distintos e cada um tem o seu próprio ciclo de vida).
Sim, após identificar uma solução estruturada, ela deve ser aplicada através de uma mudança.
Abraços e obrigado por nos acompanhar!
Grande Renê, excelente post. Primeiramente gostaria de parabenizar toda equipe do ITIL na Prática pelo excelente conteúdo postado. É a primeira vez que visito o site e sem sombra de dúvidas me tornarei um leitor assíduo.
Bom, diante do ambiente exposto pelo Fávio, me surgiu uma dúvida. falou-se em finalizar o incidente e gerar um novo quando o processo de Ger. de Problemas é acionado. O incidente é mesmo finalizado ou apenas tem sua “responsabilidade transferida”. No meu entendimento seria: Service Desk identifica o problema e aplica as atividades pertinentes, caso não seja resolvido há a escalada funcional para áreas do Ger. de Problemas, onde esse processo identifica a causa raiz, gera um erro conhecido e sua solução de contorno e registra do BDGC, levando em consideração a não necessidade de envolver outras áreas. Neste ponto, o Ger. de Problema gera uma saída que servirá de entrada novamente ao Ger. de Incidentes informando a atualização das informações no BDGC, capacitando assim a central de serviços para determinado evento. Este meu entendimento é incorreto?
Olá Rene,
Parabéns pelo Post. Tenho uma dúvida. Trabalho em uma empresa que provém soluções de internet. Temos uma equipe de operações (dividida em vários nichos Windows, Linux, Banco de Dados, Redes, etc) essa equipe por sua vez responde por tudo que está em produção.
Existe outra equipe que trabalha com desenvolvimento e engenharia dos produtos que são colocados em produção. Por convenção todas as atividades dessa segunda são de forma macro e eles não atendem pelo Ger. de Incidentes. Porém incidentes que são gerados dentro da operação (estão em produção), muitas vezes depende de um Workaround do lado deles para resolver. No entanto, diferente da operação, esse time não possui OLA, responsáveis operacionais ou quem acompanhe o Ger. de Problemas. A prioridade sempre passa a ser a entrega de novas features ao invês da correção na raiz de problemas que ocorreram por falta de QA, testes de capacidade e a passagem de bastão entre Tecnologia e Operação.
Você já viu este cenário em outras empresas ? Vou começar a estruturar o Ger. de Problemas, porém minha experiência maior vem do Ger. de Incidentes, penso em seguir com:
– Análise do modo operante da área.
– Atribuição de papéis
– Acordo entre gestores de tecnologia e POs (Product Owners) para que não ocorra conflitos entre entrega de novas features e entrega de correções que irão envolver uma RDM.
– Fechar o Workflow na mesma ferramenta que utilizamos para o Ger. de Inc.
– Proporcionar regras do tipo, X incidentes críticos, obrigam a criação de um problema para investigação.
– Sugerir o Ger. de Problemas Pró Ativo para dentro da operação, ocasionando assim a descoberta de problemas de infra (engenharia de um produto) ou software (desenvolvimento de um produto) para que esse problema seja passado aos devidos donos e saia da operação.
Estou no caminho certo ?
Desculpe a exposição deste cenário, mas com sua experiência acredito que tenha visto algo similar pelo mercado e possa ajudar.
Grato.
Abs
Olá Diego, obrigado pelo seu feedback!
Se lhe servir de consolo, eu diria que mais de 90% das empresas por onde passei têm o mesmo problema. Infelizmente fica um pouco difícil dissertar com tantos detalhes por aqui, mas acho que você está sim no caminho certo.
Três dicas:
-Não arrisque partir para gerenciamento de problemas enquanto não tiver o gerenciamento de incidentes bem maduro (registros confiáveis).
-Trate as regras para “eleição” de um problema com bastante carinho.
-Consulte a literatura ITIL (livro Service Operation) sobre as funções da Operação de Serviços. Acho que será um embasamento para definir melhor os papéis e responsabilidades, e melhorar o nível de relacionamento entre a equipe de operações e desenvolvimento. Achei uma
pornografiaabsurdo o fato da equipe de desenvolvimento não ter um OLA definido. Como ficam os clientes?Abraços e boa sorte!
Renê,
Eu que agradeço a rápida resposta, não pensava que seria tão rápido e pode ter certeza que me ajudou.
Respondendo sua dúvida, mesmo sem a definição de um OLA (documentado, acordando o NS entre a gestão de Tecnologia e Operações) eles tem a preocupação de entregar produtos de qualidade aos clientes, mas a falta de dados (que seria dada se tivêssemos algum nível júnior se envolvendo com incidentes ou uma parcela da equipe se envolvendo com problemas) faz com que pensem que a qualidade do software está saindo muito bem e que a falha provocada pós publicação veio de mudanças mal planejadas de dentro da operação. Sintoma esse que pode até ocorrer, desde que seja investigado como um problema.
No meio desse conflito entra a figura do PO, cobrança da gestão de atendimento e operações que mostram os problemas para os desenvolvedores. POs acabam priorizando o que precisa ser visto, porém tudo isso corre por fora de um processo estruturado (Ger. de Problemas) causando assim atraso, entrega de correções que não resolvem o problema 100%, entre outras coisas que você já conhece.
Eu mesmo não admitiria trabalhar em uma empresa que colocasse o cliente em segundo plano, com processo, existente, falho ou inexistente a empresa trabalha em prol dessas pessoas que colocam o dinheiro no nosso bolso 🙂 e queremos fazer o melhor por elas.
Abs
Excelente Diego! Agora ficou mais claro o contexto da sua empresa, e também uma necessidade bastante latente por algumas práticas de gerenciamento de problemas. 🙂
Abraços!
Renê,
Artigo espetacular, como sempre!
Abraços
Olá Alberto,
Obrigado pelo feedback. Estamos no aguardo de outros de seus ótimos artigos também. 🙂
Grande abraço!
Olá Renê!
Bom, estou desenvolvendo o TCC para o curso de Pós Graduação em Engenharia de Software. Posso citar esse artigo no meu trabalho (Claro, citação direta e com referência)
Abraço
Luan M
Renê, boa tarde, estou fazendo uma produção temática afim de crescimento funcional e gostaria muito de sua ajuda. Resumidamente preciso responder 3 perguntas: Melhorar o desempenho das investigações de problemas concluídas em até 7 dias de 50% para 90%. Manter o desempenho de 95% de mudanças implantadas com sucesso (implantação no prazo planejado e sem causar incidentes). Reduzir o tempo médio mensal de resolução de incidentes de 5 horas para 2 horas. — Com essas 03 metas, apresentar um plano de trabalho pratico, contendo pelo menos as atividades que devem ser realizadas por você e sua equipe, os marcos e mecanismos de controle mensais.
Olá Pablo,
Não sei como conseguiria te ajudar, exceto via um trabalho de consultoria. As três perguntas que você precisa responder são simples e objetivas, mas longe de terem respostas simples.
Podemos sobre isso em pvt. Me manda um e-mail no rene @ itsmnapratica.com.br
Abração!
Renê, ola! Trabalho (como SDM) em um grande companhia de TI que presta serviços de tecnologia para diversos clientes, estou focado em um desafio: fazer gestão de problemas de Infraestrutura de TI de forma proativa através da análise de relatórios do Gerenciamento de Eventos. Adquiri seu livro (ITIL na prática – Ger. Problemas de Infraestrutura e Serviços de TI) e gostaria de receber dicas de referências bibliográficas ou artigos com sugestões práticas para aprimorar o conhecimento e fazer funcionar na prática. Me ajuda com esta missão? Desde já, agradeço! Abraços!
Olá Marwin, tudo bem?
Agradeço pela aquisição do livro e espero que tenha encontrado resposta para algumas dúvidas. Minha sugestão para você mergulhar de cabeça no tema gerenciamento de problemas é fazer o curso ITIL Intermediate OSA. Este é um curso que o torna um especialista nos processos de suporte à operações, dos quais inclui-se o gerenciamento de problemas.
Na área de cursos aqui do site você vai poder conhecer melhor a proposta do curso ITIL OSA. Me avisa se tiver qualquer dúvida – https://dev.smmind.com.br/teste123/cursos/
Grande abraço e sucesso na sua missão!
Não encontrei seu livro (ITIL na prática – Ger. Problemas de Infraestrutura e Serviços de TI) para comprar. Como faço?
oi Sabrina
Segue link – https://dev.smmind.com.br/teste123/ebook-itil-na-pratica-gerenciando-problemas-de-infraestrutura-e-servicos-de-ti/
abco
Boa Noite!!
Renê, estou montando uma apresentação, que será discutida em uma aula da faculdade, sobre Gerencia de Capacidade. Você tem algum artigo onde explica sobre essa gerencia, poderia entrar em contato comigo para me ajudar com conteúdo? Afinal, estou com dificuldade de achar conteúdo, digamos, não tão superficial sobre o assunto. Desde já agradeço. Att, Alana Oliveira
Olá Alana. Realmente não existe muito material completo disponível. Recomendo olhar a literatura abaixo:
http://www.vanharen.net/shop/capacity-management-a-practitioner-guide/?___store=vanharen_net_en&___from_store=vanharen_net_nl
https://www.amazon.com/ITIL-Capacity-Management-IBM-Press-ebook/dp/B004TDU6Y4
Abraços!