Dias difíceis

Escassez de funcionários, tempo corrido, projeto grande, gerente sempre muito ocupado. hehehe... Ainda bem que nem tudo são flores né.
Este projeto começou com 2 pessoas (eu e Maiura). Uma terceira foi convidada pra ajudar (Luciano). Nós 3 conseguimos desenvolver muito bem o edital e os planejamentos para a terceirização do suporte técnico. E agora vejam só: Maiura está totalmente envolvida em outro projeto, Luciano está ao mesmo tempo estudando ITIL v.3 e me ajudando fazendo o meio de campo entre eu e outras pessoas que precisam me passar informações sobre seus setores. E adivinhem onde está nosso gargalo maior?????

- Conseguir informações necessárias pra qualidade do edital com outros setores. Penso que, por não estarem diretamente envolvidos neste projeto (redigir o edital), então não dão a devida importância. Depois vão querer cobrar da empresa e do sistema expectativas que ninguem solicitou quando o edital estava sendo feito.

Mas, ainda bem que a equipe (mesmo desfalcada e pequena..hehehe) tem corrido atrás.

Neste fim de semana teremos reunião com nosso consultor em ITIL, que já citei em outra postagem. Depois vou postar as dúvidas levantadas e o que ficou resolvido.

Por enquanto é só. Este blog tem o objetivo de dizer o dia-a-dia, as dificuldades encontradas e soluções "de contorno", até chegarmos ao obejtivo: software instalado, configurado, funcionando e todo ciclo de vida de um chamado sendo respeitado.

abraços

Gerenciamento de Incidentes

Falarei um pouco sobre a dificuldade de definirmos como seria utilizado o Gerenciamento de Incidentes na hora de compor o edital, que será publicado em breve, e também os serviços atrelados a ele.

INCIDENTE: Uma interrupção não planejada de um Serviço de TI ou uma redução da Qualidade de um Serviço de TI. Falha de um Item de Configuração que ainda não tenha impactado um Serviço de TI é também um Incidente. Por exemplo: Falha de um disco rígido de um conjunto de discos espelhados.

Este é conceito que rege nossas definições do que poderá ser considerado um Incidente pois devemos diferenciar da melhor forma possível um incidente de um problema e de uma requisição de serviços. Isso se torna possível a partir da criação de um Catálogo de Serviços e também da definição dos Acordos de Níveis de Serviços. Estes já estão caminhando pra ficarem prontos, mas o rascunho já está.


O principal problema estava em se definir tempos de atendimento para cada tipo de Incidente pois temos vários tipos de criticidades (lembrando que em uma empresa privada é mais fácil definir um único padrão ou poucos padrões, em empresa pública, isso tem que ser um pouquinho mais maleável. Então fizemos o seguinte:


1 - Separamos Minas Gerais em 13 regiões (12 no interior + Capital). Cada região tem diversas comarcas e estas foram separadas em 3 tipos de criticidades. Tudo depende da quantidade de processos de cada uma, ou seja, estamos INTEGRANDO a TI ao negócio. Quanto maior o número de processos que uma comarca julga, mais crítica ela é quando há uma falha.


2 - Separamos os problemas que causam maior impacto pro negócio e definimos alguns tipos que se encaixam nas seguintes situações:
  - 3 horas para atender
  - 3 horas para resolver
  - 10 horas para resolver
  - 20 horas para resolver
  - 50 horas para resolver
  - 50 horas para atender


3 - Separamos os usuários em 2 categorias de criticidade pro negócio:
  - usuários (todos que utilizam a informática)
  - clientes (todos os desembargadores)


4 - Separamos também os tipos de equipamentos/setores que são críticos pro negócio como Servidores, switches/hubs, nobreaks, CPD, gabinetes, salas de audiência e etc. Tudo que possa causar grande impacto caso haja falha.


Assim fechamos o ciclo pra calcular a real criticidade. O maior benefício de tantos controles é que dificilmente poderá ocorrer um erro humano e um chamado que deveria ser considerado como muito crítico acabou não sendo. Veja o exemplo:


Um usuário qualquer (não é cliente) abre um chamado dizendo que não está conseguindo abrir o word.
O atendente pede sua matrícula mas o sistema não acusa Criticidade alta pelo fato dele ser um usuário. O problema que ele relata também não é problema de alta criticidade, mas quando é solicitado o patrimônio do micro, o sistema acusa que é de Alta criticidade pois está cadastrado que sua localização é na Sala de Audiência. Nem importa qual o tamanho da comarca, se o equipamento está na Sala de audiência, é muito crítico. Imagina um Juiz não ficar esperando o computador resolver funcionar pra começar a audiência.... nem dá pra imaginar isto.


Pois bem, os Incidentes que temos aqui no nosso catálogo já estão bem definidos e cada um com sua importancia e tempo de solução. Mais pra frente mostrarei parte do nosso catálogo.




 e tudo vai depender da comarca que abriu o chamado e do tipo de problema que ela tem. Tudo precisará está ligado, ou seja, o sistema vai detectar a matrícula do usuário