Caro Sérgio
Bom feriado...
Sem dúvida alguma não tem como não concordar com que vc.disse.
Nesta questão, o "cliente" deve ser satisfeito dentro de suas expectativas e
percepção da "solução" (contorno ou não) de sua necessidade.
O que é "acordado" não é caro, nem para o cliente, nem para a equipe de TI
ou até mesmo para as métricas administrativas de TI.
O que devemos evitar é que a nossa mente "justificadora", a possibilidade de
"amenizar" tentando justificar qualquer ação ou atitude que ainda não tenha
um parâmetro claramente definido.
Como humanos que somos, desde o princípio, procuraramos "jogar" a "culpa"
nos outros, o problema é se formos o último da fila.
Abraços e grato por sua brilhante explanação.
Paulo Roberto Ximenes Costa
Governança em TI
ITIL® Foundation Certified
"...enquanto vivemos continuamos a aprender e
enquanto aprendemos continuamos a viver."
Howard Hendrick.
________________________________
De: Sergio Rubinato Filho <[email protected]>
Para: [email protected]; [email protected]
Enviadas: Quarta-feira, 10 de Junho de 2009 10:07:27
Assunto: RE: [itsm_br] Ainda incidente?
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
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
