Se você gerencia um ambiente de T.I. provavelmente já se viu atraído por “organizar as demandas a partir da abertura de chamados por seus clientes”. Ambientes em que anteriormente a equipe de T.I. era abordada de maneira informal (puxando o técnico pelo braço nos corredores da empresa ou até mesmo uma chuva de telefonemas pedindo ajuda em problemas simplórios) hoje necessitam de algumas regras para operar de forma racional.
Convido os Senhores a considerarem 2 variáveis:
Variável 01: Todo o software para gerenciamento de Incidentes (em um nível básico de implementação) é muito similar em termos de recursos e funcionalidades. As operações básicas devem ser muito parecidas entre as mais diversas soluções de mercado considerando: abertura de incidentes, redirecionamento de incidentes, controle e alertas mediante o SLA e geração de relatórios.
Em um nível de implementação posterior, será necessário mais integração com outras ferramentas permitindo até que um Serviço (O Serviço de Firewall de um Servidor por exemplo) ao falhar provoque a abertura de um Incidente. Entendi certo? O Serviço vai abrir um “Chamado” para um Analista “pedindo ajuda”? É isso mesmo. Podemos abordar estes recursos em um outro momento.
Variável 02: Apesar de ser um departamento de Tecnologia o seu problema não é Tecnologia. Assim como “OS OUTROS” você vai usar a Tecnologia para solucionar um problema, ela é uma ferramenta eficiente (nem mais, nem menos). Polêmico não? Desprenda energia para: definir o Catálogo de Serviços (Comece respondendo: O que você vai atender como serviço? O que você não vai atender? Como serão atendidos? Em quanto tempo? Quais são os possíveis solicitantes? Quem serão os possíveis executores?). Neste momento você já possui uma ideia que represente uma matriz de responsabilidades relacionada aos serviços de T.I.. Não vou estender demasiadamente este momento inicial de implementação das ferramentas nem tão pouco o modelo de Governança adotado pois o foco deste artigo é o que está presente em um segundo momento.
Tudo bem, mas depois de instalar a ferramenta de Gerenciamento de Incidentes qual seria nossa próxima missão? Vamos supor que sua equipe é composta por Analistas de Suporte (com uma folha de pagamento girando em torno de algumas centenas de milhares de reais por ano). Como mensurar o volume de trabalho desta equipe? No que esta equipe investe grande parte do seu esforço e tempo? Quem é o principal cliente desta equipe? Consegue avaliar a produtividade da equipe? Ela requer treinamento? Investe-se muita energia em incidentes de grande impacto para o negócio? É praticamente obrigatório mensurarmos o cenário evitando superestimar ou subestimar qualquer variável. Concordam?
O segundo momento da implementação do nosso projeto de Gerenciamento de Incidentes consiste em extrair informações do ambiente atendido: Qual o departamento que mais gera Incidentes? Qual Incidente mais frequente? Qual a causa raiz dos Incidentes mais frequentes? Qual o Analista mais solicitado? Existem datas e horários que demandam mais atendimentos? Enfim, ao analisar os relatórios gerados começamos a suspeitar do comportamento do ambiente atendido e consequentemente imaginar e traçar ações para reduzir a ocorrência de incidentes.
Alguns gestores comemoram e estampam em seus relatórios altos volumes de Incidentes de forma perigosa e equivocada. Se cada Incidente gerado por um usuário significa indisponibilidade de serviços ou evento que prejudicou ou impediu o funcionamento de algo, então o inimigo número um da produtividade é o Incidente. Incidente aberto pode significar (na melhor das hipóteses) alguém impedido de realizar alguma tarefa, afetando assim diretamente a produtividade dos funcionários.
Imagine a seguinte situação, no primeiro mês registramos 1,8 mil Incidentes relacionados a um Sistema Interno, no segundo mês 2,3 mil Incidentes, no terceiro 1,9 mil Incidentes, algumas perguntas merecem ser respondidas: São Incidentes relacionados à instalação? Relacionados à configuração? Alguma mudança provocou a redução de Incidentes do segundo para o terceiro mês? Algum processo do negócio que ocorreu do primeiro para o segundo mês fez com que os usuários abrissem chamados de suporte com receio de realizar algum procedimento equivocado? Ministrar treinamentos para estes usuários reduziria o número de Incidentes? Melhorar a usabilidade do Sistema traria mais segurança para os usuários? Ou podemos finalizar concluindo que no segundo mês é uma data já prevista de maior utilização do Sistema ou simplesmente coincidiu com o momento de aquisição de outra empresa trazendo assim novos usuários que não possuíam experiência com o novo ambiente?
Longe de especulações, os Gestores precisam entender as causas dos Incidentes para combate-las e se antecipar aos eventos que por menores que sejam, podem afetar o fluxo normal das tarefas corporativas. Lembre-se que Incidente aberto é “usuário parado” (ou com tarefa interrompida). Conseguiria um dia você Gestor mensurar o custo de um Incidente? Qual o valor estimado envolvendo um usuário aguardando a solução de um Incidente por 4 horas? Qual o impacto desta espera? Quais os valores envolvidos em um Incidente relacionado à solução de Correio Eletrônico? Qual o custo médio para a empresa se um usuário não consegue utilizar o correio eletrônico por 4 horas? Qual o impacto que a indisponibilidade deste serviço gera? O negócio necessita de 99,9% de disponibilidade do Correio Eletrônico mas os investimentos foram realizados de forma proporcional à importância e dependência deste serviço?
Muitos ao ler este artigo provavelmente irão se enxergar mas não se desanimem, o primeiro passo é identificar as arestas para posteriormente minimizá-las. Amadurecer o modelo de Governança é um ciclo que merece ser repensado sem interrupção uma vez que as necessidades do negócio também se comportam em uma ascendente constante. Até o próximo artigo…..
Jordano Mazzoni
Twitter: https://twitter.com/jordanomazzoni
Canal de Videos no Youtube: youtube.com/jmazzoniaju
LinkedIn: br.linkedin.com/in/jordanomazzoni
