Caro Felipe Rezende,
Depois de vários comentário interessantes derivados de sua pergunta e refletindo sobre o seu caso, minha recomendação inicial é: O X da questão está na satisfação e comprometimento do usuário em função ao do serviço prestado e conseqüentemente a forma com que a TI prove suporte aos serviços que oferece. Permita transmitir o meu entendimento e idéias entorno do assunto de forma prática: o usuário, sentindo alguma degradação no serviço (sempre em função do que fora combinado ANS), está no direito de pedir auxilio e negociar o momento mais conveniente para que uma solução (de contorno ou definitiva) seja aplicada. Daí temos a questão da gestão do serviço que TI presta neste momento, que na minha opinião está buscando sair da sua condição de subdesenvolvimento no que toca os métodos de gestão por meio de aplicar as práticas correntes e supostamente mais modernas. Mais isso é um outro assunto, que alias dá pano pra manga. Voltando a vaca fria: como proceder com o gerenciamento deste registro de incidentes? (ocorrência, trouble ticket, TT, ticket, chame-se como quiser desde que esteja claro o que se pretende com o registro desta informação). Em qualquer relação (sobre tudo numa prestação de serviços) todos os elementos do sistema tem um papel a ser desempenhado que deve ser medido, possibilitando a entrega do serviço da forma mais eficiente, controlada (tirando a máxima utilidade do sistema como um todo). Com isso assumimos que o usuário também deve ser medido quando da interação com o processo, sempre na forma de esforço e disponibilidade da parte dele (o que por princípio não é linear e sim transacional). Do lado da TI a forma com que medimos a produtividade e efetividade do suporte aos serviços de TI por convenção assume períodos lineares, que na minha avaliação é uma das causas raiz do problema. Explico: não podemos responsabilizar a TI por algo que está fora do seu controle (reforço o exemplo da medicina: se um médico pede um exame ou prescreve um medicamento no sentido de tratar a condição é responsabilidade do paciente seguir as recomendações dentro dos prazos convenientes e que não ofereçam risco a sua saúde). Por isso sustento a prática de medição da nossa proficiência TÉCNICA por esforço (horas de fato trabalhadas) que alocamos para restabelecer o serviço e, separadamente mas no contexto de prestação de serviços, nossa proficiência de GERENCIAMENTO (tempo total linear que lançamos não das nossas habilidades interpessoais, confiabilidade, integridade, etc para auxiliar o nosso usuário). Quais as vantagens aqui são: 1) atribuir claramente qual recurso lançaremos não em cada etapa da prestação do serviço, 2) clareza e transparência facilitando a contabilização dos recursos utilizados pelo sistema, 3) assertividade na alocação de recursos, 4) melhor qualidade percebida na prestação do serviço, 5) facilidade de se apresentar o resultado do trabalho, 6) clareza na prestação de contas e recebimentos por conta dos serviços prestados. Além de muita comunicação e entendimento mutuo (inerente de qualquer prestação de serviço de qualidade), umas das ferramentas que você pode lançar mão é e justamente o ITIL no que diz respeito ao Gerenciamento de Incidentes. Você pode usar os STATUS do registro (aberto, em andamento, diagnosticado, solucionado, corrigido, restabelecido, encerrado, etc atenção para não se pegar na semântica) como forma de registrar a cadência linear do registro e as interações com o usuário (como se fosse o prontuário do atendimento) e SUB-RESGISTROS de Incidentes (também conhecidos como pai-filho, incidentes hierárquicos, incidentes relacionados, etc) para registras o esforço necessário para resolvermos a situação (comparando com pedidos de exames, receituários, etc). Com isso o seu registro principal de incidentes segue com o uso linear dos status, apresentando ao usuário e buscando registrar o entendimento e comprometimento dele por meio de: detalhar o que está acontecendo, apresentar solução recomendada (e os porquês), condições e prazos para evoluirmos para a próxima etapa do suporte e os acordos relativos em função do acordo de nível de serviço ao qual estamos seguindo (revisite na medicina o processo de diagnostico e tratamento de doenças que você achará muitas respostas). Posto isso, creio que atacamos o cerne da questão: organização do trabalho passando principalmente pela definição clara de papeis, responsabilidades, expectativas, forma de acompanhamento, parâmetros de medição de qualidade e método de apresentação dos resultados. Espero que com esta pequena mensagem tenha conseguido transmitir que para a correção e restabelecimento do serviço como combinado não depende somente da TI, portanto não podemos somente medir o desempenho de um todos componentes do sistema e esperar que tenhamos uma visão clara da qualidade do serviço como um tudo o que é geralmente a regra em TI). Desejo muita sorte e paciência para que você consigo desatar este nó. Cordiais, Sergio Rubinato Filho From: [email protected] [mailto:[email protected]] On Behalf Of Pablo Emanuel Sent: Monday, June 08, 2009 8:30 AM To: [email protected] Subject: Re: [itsm_br] Ainda incidente? Carlos, pelas definições do ITIL, um incidente nunca é "promovido" para problema ou mudança. Um incidente pode estar associado a um problema (ou até mesmo a mais de um) e, se não tivermos nenhuma solução de contorno, a solução do incidente pode até estar vinculada à resolução do problema (que, muito provavelmente, será uma mudança), mas nunca um vira o outro. A pergunta original pode ser generalizada para "o que fazer quando não existe workaround e a solução de um incidente depende de uma mudança?" Não me atrevo a dizer que eu tenha a solução definitiva para esta questão, mas o procedimento que eu tenho seguido nestes casos é negociar com a(s) área(s) afetada(s) - envolvendo o ponto focal da área no processo de change management (normalmente o gerente da área) - o prazo necessário para a execução da mudança (de acordo com os procedimentos de change management), e alterar o status do incidente para um status especificamente criado para este fim até a execução da mudança. Desta forma, podemos identificar este cenário nos relatórios. Se simplesmente deixássemos o íncidente como "Aberto", ele se misturaria com os incidentes em que não houve acordo com as áreas; se simplesmente encerrássemos o incidente, ele se misturaria com os casos em que a solução de contorno foi efetiva. Abraço, Pablo Emanuel 2009/6/7 Carlos Roberto Santos Almeida <[email protected]> Boa noite. Felipe, Ao me deparar com esse tipo de situação, tento sempre ponderar o seguinte: O objetivo do processo de Incident Management, segundo o book, é devolver o serviço normal no menor espaço de tempo possível. Sendo assim, Tickets cujo o atendimento pode ser "postergado" descaracteriza essa máxima, descaracterizando assim o ticket que poderá ser "promovido" de incident para problem (caso a causa raiz ainda não seja conhecida/documentada) ou ainda change (sendo agregado à janela padrão de mundaças). O book prevê que o incident pode ser reconhecido como algo que afeta parcialmente um determinado serviço. Pórem, se o impacto é tão parcial que a resolução possa esperar a próxima janela de mudanças, este ticket original deve ser fechado com as informações das tratativas executadas e com a solicitação do usuário de aguardar a próxima janela de mudança. Outro ponto de análise para se tirar da situação proposta é que, hoje em dia com a infra atual, os serviços estão todos agregados em servidores. Sendo assim, a solução para incidents que afetam (totalmente ou parcialmente) um determinado serviço, dificilmente estarão nos clients e possivelmente estarão afetando mais que um usuário no ambiente. Dessa forma, mais uma vez migraremos o ticket para a disciplina de problem e em seguida change. Lógico que toda essa colocação é do ambito teórico e que, no âmbito prático, o que vale é o acordo prévio com o cliente sobre a tratativa que será dada para esta situações. Espero ter contribuido para a discussão. -- Att.: Carlos Roberto Santos Almeida Mobile +55 11-8279-7704 [email protected] "http://www.linkedin.com/in/carlosroberto"; 2009/6/3 Felipe Rezende Sales Barbosa <[email protected]> Caros, Gostaria de uma ajuda de vocês. Sabendo que um incidente é uma interrupção total ou parcial ou ainda uma queda de qualidade de um determinado serviço de TI, tenho a seguinte dúvida: Considere o cenário em que ocorreu um incidente do tipo queda de qualidade em um determinado serviço de TI e a solução para o mesmo exige uma parada momentânea do serviço. Porém, o usuário que abriu o incidente não aceita essa parada e prefere ficar com o serviço com baixa qualidade, tendo portanto que esperar pela próxima janela de manutenção do serviço para resolver a questão. A dúvida é a seguinte: Até a próxima janela de manutenção esse incidente fica aberto? Sendo sim a resposta, essa ação impacta no indicador de tempo de resolução de incidentes. Aguardo a participação de todos. Atenciosamente, -- Felipe Rezende Sales Barbosa Consultor Invit Information Services - Uberlândia (34)9929-1109
