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