Gustavo, Muito bom seu posicionamento. Seu exemplo foi de extremo valor e, com certeza, será um parâmetro para a implementação de nosso processo de Gestão de Problemas.
A propósito, sua apresentação também ficou muito interessante. Obrigado, Jorge Guimarães Coordenador de Suporte http://twitter.com/jpguima http://br.linkedin.com/in/jpguima --- In [email protected], "Gustavo Lens Minarelli, CGEIT, CISM" <gminare...@...> wrote: > > > > Jorge, > > > > Concordo com você e endosso com um exemplo prático, de um projeto que > liderei a uns quatro anos atrás, junto com o Cesar Monteiro da IT Partners > (Grande Cesar!). > > Em uma grande corretora, que posteriormente passou por uma fusão com uma > outra grande, gerenciei o projeto que foi case do ITSMf: > > Propus a implementação de um processo que integrasse bem as equipes da > central de serviços com as equipes de infra e sistemas. Existiam mais de 30 > sistemas espalhados e desenvolvidos por 4 diferentes equipes. > > A primeira coisa que fizemos foi unificar a gestão de incidentes (boa > prática básica que serviu bem para aquela empresa). Aproveitando a > iniciativa concomitante do RH, de criação de um programa de gestão por > competências, incluímos nas competências avaliadas nos desenvolvedores e nos > especialistas de infra, e nas suas obrigações, a responsabilidade por passar > conhecimentos técnicos para o pessoal do primeiro atendimento. > > O pessoal do primeiro atendimento, por sua vez, foi instruído a passar o > chamado para o nível especialista, mas acompanhar o seu tratamento do início > ao fim, e o principal, anotando em seu caderninho como este chamado era > tratado! > > O pessoal do primeiro nível foi instruído para que ao final do processo > registrasse todas as suas anotações em uma base de dados (ainda > desestruturada). Se não era registrado imediatamente, as duas últimas horas > da semana daquele analista deveriam ser utilizadas para registrar as suas > anotações na base de conhecimento. O "coaching" conjunto da consultoria com > o líder da central de serviços foi muito importante para garantir que isso > acontecesse. > > O fato é que cada pessoa tem um jeito de escrever, um nível próprio de > detalhar, etc... no primeiro momento da implantação e sempre que alguém > novo interar a equipe o líder da central de serviços deve ter olhos e > atitude focada em ensinar os atendentes a escrever detalhes, inclusive > técnicos, sobre o atendimento de uma forma padronizada (não só do que foi > dito pelo cliente, mas também do que foi feito pelos especialistas de > segundo nível) > > Sim, nossa opção foi por provocar os atendentes de primeiro nível a buscar o > conhecimento e aumentar a integração entre as duas equipes, pois > dificilmente o especialista de segundo nível iria mudar o seu hábito de > resolver tudo sem documentar, mesmo que incluíssemos aquilo nas obrigações e > indicadores de performance deles. Alias, isso foi feito, posteriormente. > > > > (Tempo para uma reflexão sobre a afirmação: Não é só desenhar processo e > implementar ferramentas J) > > > > A flexibilidade dada ao processo possibilitou que contornássemos o problema > freqüentemente encontrado em todas as empresas, que não era diferente > naquela empresa: o primeiro nivel não tinha tempo para registrar os > incidentes imediatamente. > > Assim, era obrigação dos "jovens atendentes de primeiro nível" , aspas pois > isto é uma realidade no mercado, realizar o registro, com o mínimo de ordem > e padrão possível, em uma base de dados. > > Processo amadurecido, destacamos um membro da equipe especialista, que > navegava bem entre as duas equipes, de infra e de sistemas, para utilizar > todo o seu tempo garimpar nos registros passados e atuais as soluções mais > freqüentes (definitivas ou não), o ITIL dá um nome para isso, vocês lembram? > > Também incumbimos este especialista de criar um padrão de registro dos > incidentes que melhor o ajudassem propondo alterações para o gerente da > central de serviços (com isso criamos a parceria que queríamos)... > > Como segundo passo, acrescentamos em suas responsabilidades o dever de > analisar estes registros e as soluções mais frequentes, propondo mudanças > para aquelas soluções de maior impacto e probablidade de ocorrer.. > > Bom, o exemplo que dei mostra que um fio puxa o outro, uma necessidade puxa > a outra, e se bem orquestradas, a empresa não para de melhorar o seu sistema > de gestão e a qualidade dos serviços de TI.. e os resultados do seu > negócio.. > > Muita coisa veio depois do que descrevi acima e o resumo dos resultados > iniciais, alcançados em apenas 2 meses, podem ser vistos na apresentação, do > seguinte link: http://slidesha.re/aLjWpC > > > > Um grande abraço > > Gustavo Lens Minarelli > > Gerente de Projetos Estratégicos > > governança-riscos-compliance > > 011 9393 3832 > > 021 9486 6505 > > > > > > From: [email protected] [mailto:[email protected]] On Behalf Of > Roberto Cohen > Sent: quarta-feira, 30 de junho de 2010 09:10 > To: [email protected] > Subject: Re: [itsm_br] Re: Gerenciamento de Problemas > > > > > > Jorge, > > > > Pitacos na questão da documentação. > > > > É preciso ter um administrador da base de conhecimento. > > > > Em tempo integral, parcial, sei lá, mas alguém tem que "tomar conta da > garrafa", > > como dizia uma antiga propaganda. > > > > E, claro, ele precisa seguir um método, um processo. Que vai desde a captura > > de algo novo até a divulgação. > > > > E que envolve também debate com os usuários da mesma, caso contrário ele > fica > > feito uma maquineta publicando soluções e todo mundo na outra ponta fazendo > > malabarismos pra encontrá-las. > > > > Abraços > > > Cohen > > > > > > > > 2010/6/29 jperussi78 <jperuss...@...> > > > > 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] <mailto:itsm_br%40yahoogroups.com> , Aldo > Silva <aldo.rj@> 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 <http://securityofficer.wordpress.com/> * > > > > > > > > Em 26 de junho de 2010 09:57, Roberto Cohen > > > <roberto.cohen.4hd@>escreveu: > > > > > > > > > > > > > Pô, > > > > > > Mas aí é sacanagem. > > > > > > Por isso que formamos uma lista: para COMPARTILHAR > > > experiências, conhecimentos etc. > > > > > > EL Cohen > > > > > > > > > > > > > 2010/6/25 DANIEL FILHO <dmsfilho@> > > > > > > > > >> > > >> Jorge, > > >> > > >> se vc podemos trocar informações em particular: dmsfilho@ > > >> > > >> --- Em *qui, 24/6/10, jperussi78 <jperussi78@>* escreveu: > > >> > > >> > > >> De: jperussi78 <jperussi78@> > > > > >> Assunto: [itsm_br] Gerenciamento de Problemas > > >> > > >> Para: [email protected] <mailto: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 > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > >
