Objetivos do negócio

Conforme referido, a dependência do negócio do seu SI faz com que qualquer anomalia tenha um impacto na produtividade e consequentemente no seu resultado financeiro, incidentes de menor impacto ou de resolução breve, são fáceis de gerir (o utilizador pode dedicar-se temporariamente a outra função, ou pedir a um cliente para “ligar mais tarde”), já incidentes com resoluções mais longas (mesmo os menos críticos, acabam por se tornar críticos com o tempo) colocam problemas mais graves e com maior impacto. Como tal a previsão do tempo de resolução de um incidente é a chave para gerir corretamente expetativas, evitar atritos e decidir atempadamente a ativação de medidas de contingência. Neste sentido o objetivo do negócio é conseguir saber, no momento do registo de um novo incidente, qual o prazo previsto para a sua resolução.

Para responder a este objetivo, será efetuada a descoberta de comportamentos e padrões existentes no histórico de incidentes, com recurso a técnicas de data mining, sendo o critério de sucesso a criação de um modelo preditivo que ajude a prever o tempo de resolução de um novo incidente, com uma taxa de sucesso superior a 60%.

No que respeita aos recursos disponíveis, será analisada informação de histórica composta por 44.000 registos de incidentes recolhidos ao longo de 5 anos e meio (entre 2010 e 2015). Ao nível de recursos de software, são utilizadas ferramentas open source (Weka) e o software comercial IBM SPSS Statistics (SPSS).

O Weka (Waikato Environment for Knowledge Analysis) teve início em 1993, na Universidade de Waikato Nova Zelândia, sendo depois adquirido por uma empresa no final de 2006. O Weka

43 encontra-se licenciado sob o abrigo da General Public License, sendo portanto possível aceder e alterar o respetivo código fonte.

O Weka tem como objetivo agregar algoritmos de data mining provenientes de diferentes abordagens/paradigmas, dedicada ao estudo da aprendizagem por máquinas (machine learning), disponibiliza um interface gráfico muito intuitivo, composto por uma vasto leque de algoritmos de data mining e uma performance e estabilidade excelentes para uma ferramenta não comercial.

O IBM SPSS Statistics é uma ferramenta proprietária da IBM vocacionada para a análise estatística, embora seja complementada por um produto da família SPSS, dedicado ao data mining (o SPSS Modeler), o SPSS Statistics dispõe de várias funcionalidades nesta área tornando-o uma ferramenta muito versátil e poderosa em análise de mineração de dados. Embora não seja uma ferramenta open-source, uma vez que a sua principal função é o estudo estatístico, já tem presença em muitas organizações, com um custo muito inferior a ferramenta comerciais dedicas exclusivamente ao data mining.

A amostra de dados para o presente estudo foi extraído da base de dados da ferramenta de gestão de incidentes, via SQL (Structured Query Language), sendo os dados depois exportados para formato Microsoft Excel. Esta extração permitiu recolher todos os registos de incidentes entre 2010 até ao presente (2015). Embora a ferramenta contenham variada informação (atributos) relacionados com o tratamento de incidentes, neste estudo apenas são considerados os dados recolhidos durante o tempo de assinação (Figura 19), ou seja, os dados disponíveis no momento do registo do incidentes e com os quais se pretende prever o tempo de resolução.

O tempo de resolução foi calculado no processo de extração e considera o tempo decorrido na perspetiva do utilizador, ou seja, desde o momento que o utilizador submete o incidente, até ao momento que o considera resolvido, de acordo com a Figura 19, este tempo representa o somatório do tempo de assignação com o tempo de resolução, tendo sido excluídos horários e dias não uteis (fins de semanas e feriados).

44

3.3. CRISP-DM Fase 2: Compreensão dos Dados

Esta fase inicia-se com a preparação e análise dos dados recolhidos, e procura identificar problemas de qualidade dos dados (valores discrepantes, omissos, etc.), identificar potenciais relações entre os dados e a deteção de subconjuntos interessantes.

Conforme já descrito, a ferramenta contêm dados relativos a todo o ciclo de tratamento do incidente (Registo, Categorização, Priorização, Investigação e diagnóstico, Resolução e recuperação, Encerramento do incidente), contudo para este estudo apenas são considerados os dados recolhidos (e conhecidos) no momento do registo e o tempo final de resolução (que corresponde à variável dependente).

A Tabela 3 apresenta cada um dos atributos extraídos (coluna atributo), descreve-os (coluna descrição) e apresenta o seu método de registos (coluna Tipo de registo)

45 Tabela 3: Atributos registados pela ferramenta de gestão de incidentes

Atributo Descrição Tipo de registo

N_Reporte Código sequencial que identifica cada incidente

Registado de forma automática, atribuindo um número sequencial a cada novo incidente. Ano Ano de registo do incidente Registado de forma automática, de acordo

com a data do registo do incidente.

Mes Mês de registo do incidente

Registado de forma automática, de acordo com a data do momento de registo do incidente.

Dia Dia de registo do incidente

Registado de forma automática, de acordo com a data do momento de registo do incidente.

Utilizador Código do utilizador que regista o incidente

Registado de forma automática, de acordo com o identificador numérico do utilizador que submete o incidente.

Area

Código que identifica a área do negócio (departamento) onde se encontra o utilizador que regista o incidente

Registado de forma automática, de acordo com o código do departamento do utilizador que submete o incidente.

Tipo_Inc

Código que identifica o tipo de incidente (e.g. nas aplicações, no posto de trabalho, de Segurança, etc.)

Registado pelo utilizador, através da

identificação do tipo de incidente, de uma lista predefinida (drop-down list)

Servico

Código que identifica de um modo genérico o que está afetado, utilizado para identificar uma aplicação ou ferramenta (e.g., aplicação de faturação, telefone do posto de trabalho, etc.)

Registado pelo utilizador, através da identificação do serviço, de uma lista predefinida (drop-down list) populada mediante escolha do Tipo_Inc

Categoria

Código que identifica em detalhe o que está afetado, utilizado para identificar uma funcionalidade numa aplicação ou ferramenta (subcategoria de serviço) (e.g., funcionalidade X da aplicação de faturação, a opção Z no telefone, etc.)

Registado pelo utilizador, através da identificação da categoria, de uma lista predefinida (drop-down list) populada mediante escolha do Servico

Situacao

Código que identifica o comportamento anómala identificado (subcategoria da categoria) (e.g., Serviço indisponível, quebra de performance, avaria no equipamento, dados incorretos, etc.

Registado pelo utilizador, através da identificação da situação, de uma lista predefinida (drop-down list) populada mediante escolha da Categoria

Prioridade

Código que identifica a prioridade do incidente (relação entre urgência e o impacto)

A prioridade é calculada automaticamente mediante a Urgência e impacto, predefinidas de acordo com registo do serviço e da categoria

Reportado_p or

Código binário que identifica o perfil (utilizador ou agente) do utilizador que registou o incidente

Registado de forma automática, de acordo com o código do utilizador (utilizador ou agente)

Motivo

Código do motivo (aparente) do incidente (e.g., indisponibilidade de serviço, desconhecido, comportamento inesperado, utilização incorreta)

Registado pelo técnico, após uma triagem do incidente, através da identificação do motivo, de uma lista predefinida (drop-down list)

Origem

Código da origem do incidente (e.g., origem conhecida, desconhecida, problema de configuração, etc.)

Registado pelo técnico, após uma triagem do incidente, através da identificação da origem, de uma lista predefinida (drop-down list) Tempo_Res Tempo de resolução (em minutos) Registado de forma automática, após a

46 De notar que os atributos N_Report e AnoAvaria, embora presentes no momento do registo de um novo incidente, assume-se que dada a sua natureza (incremental), não tem qualquer relevância para o modelo a criar, logo não são considerados na amostra. Os restantes atributos são depois alvo de análise e tratamento.

Após extração da amostra constatou-se a existência de 44.009 registos, com a dispersão apresentada na Figura 20.

Figura 20: Histogramas dos atributos da amostra

No que respeita à relação entre atributos, foi utilizado o ETA e o Spearman, como medida de avaliação do grau de associação entre os diferentes atributos (nominais e ordinais respetivamente) e o tempo (Tabela 4).

47 Dada a reduzida quantidade de registos omissos (65 registos na atributo Area), optou-se por eliminar estes incidentes do estudo. Esta equidade nos dados, conforme referido, deve-se essencialmente à robustez da aplicação de gestão de incidentes no que respeita ao seu processo de registo, uma vez que o incidente apenas pode ser submetido quando todos os campos (atributos) estão preenchidos, e estes não são inseridos manualmente (apenas por seleção de listas previamente definidas), o que elimina o fator erro humano e se traduz numa taxa residual de dados inseridos incorretamente ou omissos.