"Até que ponto é correto assumir um risco para atender um acordo de nível de serviço?"
Entendo que um risco pode ser assumido se as consequências estiverem claras para todos os envolvidos e se o resultado final, compensar os riscos. Aquela velha história de "risco calculado". Neste seu exemplo, entendo que este não é um risco que TI tem que assumir para atender um acordo de nivel de serviço. É um risco que o board gerencial tem que assumir para o bem do negócio. TI apenas apenas executará. Portanto, neste caso eu não consideraria o acordo de nível de serviço, tendo em vista que é uma situação excepcional. Abraço, Gisely Ferraz - ITQM 2009/6/17 Luciano Silveira <[email protected]> > > > E aí Felipe, quando trabalhava ao seu lado sempre gostei deste seu perfil > de grande questionador. > Têm horas que trabalhamos no automático e acabamos esquecendo de > pensar/perguntar se aquela forma de fazer é a melhor ou mais correta. > > Acredito que as respostas dadas até o momento já ajudam na reflexão da > questão, então gostaria de aproveitar para colocar um outro caso que > ocorreu: > > Certo dia durante o expediente o no-break "caiu" e com ele vários > servidores ficaram inoperantes, causando parada de diversos serviços > (incidentes). > O Diretor, também grande conhecedor de ITIL, questionando a equipe de > suporte sobre o que havia ocorrido recebeu a informação que houve queima do > fusível, como não havia outro de reserva no local (grande falha por sinal) > já estavam providenciando aquisição de outro no comércio para restabelecerem > os serviços. Porém o Diretor disse para colocar o no-break em by-pass para > que os serviços voltassem em operação o quanto antes (haviam muitos > empregados parados) e posteriormente na janela de manutenção realizarem a > troca (além de registrar o problema para investigação da capacidade do > sistema eletrico). > No final acabou-se trocando o fusível bem naquele instante(acho que > conseguiram utilizar o de outro equipamento que estava danificado). > > A princípio discordei do Diretor, já que utilizando o by-pass estaríamos > colocando em risco a proteção elétrica dos servidores e com esta solução > poderíamos causar um incidente ainda mais grave. > Os argumentos dele eram que o incidente teria que ser solucionado na menor > janela de tempo possível. > > Até que ponto é correto assumir um risco para atender um acordo de nível de > serviço? > > Luciano Silveira > [email protected] <lucianojs%40gmail.com> > MSP - Microsoft Student Partner > MCSA, MCTS, MCP > Google profile: http://www.google.com/profiles/lucianojs > > 48 3365-0930 (NET) | 48 8465-0930 (OI) | 34 3221-8550 (Fixo Voip - Atendo > em Floripa) > Florianópolis - SC > > > --- In [email protected] <itsm_br%40yahoogroups.com>, "Sergio > Rubinato Filho" <rubin...@...> wrote: > > > > 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] <itsm_br%40yahoogroups.com> [mailto: > [email protected] <itsm_br%40yahoogroups.com>] On Behalf Of > > Pablo Emanuel > > Sent: Monday, June 08, 2009 8:30 AM > > To: [email protected] <itsm_br%40yahoogroups.com> > > 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 <carlos.alme...@...> > > > > > > > > > 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 > > carlos.alme...@... > > "http://www.linkedin.com/in/carlosroberto"; > > > > 2009/6/3 Felipe Rezende Sales Barbosa <felipe...@...> > > > > > > > > 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 > > > > >
