Quem responde a essa pergunta nao é a TI, é o negocio. 2009/6/17 Gisely <[email protected]>
> > > "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 >> > >> >> > >
