Olá Sim , todos os chamados voltam com a solução e o próprio sistema da central armazena no banco de conhecimento, A central é responsável pelo acompanhamento do chamado até ele ser fechado.
Quando existe um incidente grave (IG) a central não atua, informa diretamente para o nível 1, que aplica a solução e descreve o que foi feito (ex: restart do apache do server tal), e quando esse chamado é encerrado (IG) automaticamente abre-se o ANALISE DE Incidente, que é enviado para fila do Nível 2 (Gerencia de Problema) para saber porque os apaches caíram e tornou uma indisponibilidade. (exemplo : Alto load , Alto CPU ) descobriu a causa !! ai solicita uma mudança na aplicação que gera um RMI (janela), que é enviado para Suporte Mudanças, enquanto isso o analise de incidente fica na fila esperando a aplicação do RMI. Depois da aplicação do RMI (janela) o Gerencia de Problema efetua novos teste para que não ocorra novamente. e manda para Central que encerra o chamado. A aqui na empresa a Gerencia de Problema tem que garantir a entrega do serviço. Depois de um incidente grave , faz- se um check list em outras homes para verificar se vai acontecer com outros clientes , eles tem que fuçar , fazer teste , teste de carga etc.. A central atua nos chamados que não causa impacto. o Sistema da Central de Serviços tem que ser bem desenvolvido para suportar o banco de conhecimento. Incidente , Incidente grave, RMI, analise de incidente. Não sei se consegui esclarecer a sua dúvida, O gerenciamento de serviço varia de empresa a empresa , levamos dois anos para efetuar essa implantação Grande abraços *Aldo Silva* *Globo.com** :: Tecnologia* *(21) 9129 4317- yahoo:aldorj2003* *securityofficer.wordpress.com* Em 29 de junho de 2010 14:10, jperussi78 <[email protected]> escreveu: > > > Aldo, > > Tenho uma dúvida, como a solução (de contorno ou difinitiva) volta para a > Central de Serviços? Os grupos solucionadores tem um processo de alimentação > contínuo da Base de Conhecimentos? Para que, em um próximo atendimento, a > Central de Serviços tenha a solução em mãos e não precise repassar o > chamado? > > Vejo que a documentação das soluções adotadas é o grande dificultador, já > que o chamado é encerrado e não há um registro de fácil acesso para ser > consultado posteriormente. > > Jorge Guimarães > > > --- In [email protected] <itsm_br%40yahoogroups.com>, Aldo Silva > <aldo...@...> wrote: > > > > Também concordo vou dar um resumo o que acontece aqui no trabalho, vou me > > basear em incidente grave. > > > > Quando a Central de serviços recebe um chamado de indisponibilidade, uma > > Home fora por exemplo (que causa impacto). A Central de Serviços informa > a > > equipe de operações abrindo um registro que chamamos de Incidente Grave , > A > > equipe de operações identifica o problema e aplica a solução ou não, se > não > > consegue identificar aciona a equipe 2 nível, independente de resolver ou > > não a Central de Serviços tem obrigação de abrir um outro registro que > > chamamos de Analise de Incidente , na qual é direcionado para Gerencia de > > Problemas nele vai ser analisado o porque a Home saiu do Ar, Se é > problema > > na aplicação , Hardware ou infra, Identificado o erro (ex: bug weblogic) > , é > > direcionado para gerencia de mudança agendar uma atualização, por ai vai > , > > Neste processo está voltado a encontrar os erros conhecidos, identificar > > soluções alternativas para eliminar os erros conhecidos, levantar as > > solicitações de alteração no caso de ser necessária uma alteração para a > > solução dos problemas identificados , Verificar se após executar a > solução > > de um problema o erro desaparece. > > > > O gerenciamento de problemas também é um processo pró-ativo, ou seja, os > > problemas são identificados para serem solucionados antes de ocorrer o > erro. > > > > Esse processo variam de empresa para empresa , não significa o que é > > implementado na minha vai funcionar na sua. > > > > > > > > Abraços > > *Aldo Silva* > > > > *Globo.com** :: Tecnologia* > > *(21) 2125-2023 - yahoo:aldorj2003* > > *securityofficer.wordpress.com* > > > > > > > > Em 26 de junho de 2010 09:57, Roberto Cohen > > <roberto.cohen....@...>escreveu: > > > > > > > > > > > > Pô, > > > > > > Mas aí é sacanagem. > > > > > > Por isso que formamos uma lista: para COMPARTILHAR > > > experiências, conhecimentos etc. > > > > > > EL Cohen > > > > > > > > > > > > 2010/6/25 DANIEL FILHO <dmsfi...@...> > > > > > > > > >> > > >> Jorge, > > >> > > >> se vc podemos trocar informações em particular: dmsfi...@... > > >> > > >> --- Em *qui, 24/6/10, jperussi78 <jperuss...@...>* escreveu: > > >> > > >> > > >> De: jperussi78 <jperuss...@...> > > > >> Assunto: [itsm_br] Gerenciamento de Problemas > > >> > > >> Para: [email protected] <itsm_br%40yahoogroups.com> > > >> Data: Quinta-feira, 24 de Junho de 2010, 14:53 > > >> > > >> > > >> > > >> Sou coordenador de equipes de suporte a mais de 5 anos e atualmente > > >> coordeno um Service Desk que atua para uma empresa aérea e nós, eu e > meu > > >> cliente, estamos procurando maiores informações sobre o processo de > > >> gerencimento de problemas. Já que consideramos que o Gerenciamento de > > >> Incidentes está implementado. > > >> Vocês teriam algum "case" para servir de benchmarking para nossa > operação? > > >> Estou recorrendo a um grupo de discussão pois vejo que poucas empresas > > >> possuem um gerenciamento de problemas ativo e funcional. > > >> > > >> Agradeço a todos pela atenção. > > >> > > >> obrigado, > > >> > > >> Jorge Guimarães > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > >
