A precisão de classificação dos incidentes em bug determinístico e não determinístico alcançou 100% com o experimento manual em ambos os clientes “X” e “Y”. Este resultado de 100%, com o experimento manual, baseia-se no fato de que os tipos de bug dos incidentes foram corretamente classificados a partir de uma classificação correta do Gatilho ODC, porque há um mapeamento direto entre estas variáveis. No experimento automático depende totalmente da acurácia de acerto do ODC gatilho onde alcançou uma precisão em torno de 90%. Os outros atributos ODC alcançaram uma precisão de 50% a 67,3% com o experimento automatizado.
Houve resultados diferentes para o cliente “Y” em relação ao cliente “X”, quando se analisaram as amostras após a aplicação do experimento manual. Uma das causas possíveis para isso pode estar relacionada ao fato de que o cliente “X” é totalmente externo à Empresa “A”, com outra infra estrutura de atendimento, enquanto que o cliente “Y” faz parte da estrutura interna da Empresa “A”, o que pode tornar a avaliação dos incidentes mais difícil em relação ao cliente “X” do que em relação ao cliente “Y”.
A redução do número de transferências para o cliente “Y” foi de somente 8 a 16% dos incidentes. Por outro lado, para o mesmo cliente “Y”, em diversas ordens de serviço, foi observado que, quando o Suporte de Primeiro Nível (ver a Figura 2) trabalhou no problema, o mesmo não encontrou a causa raíz, somente realizando uma reinicialização para restaurar o serviço assim que possível, não transferindo o problema para um nível mais especializado a fim de realizar uma investigação. Portanto, mesmo havendo o mesmo número de transferências com o processo atual utilizado pela Empresa “A” e com o método proposto neste trabalho, a qualidade nas transferências (para o time de suporte correto) com o processo proposto foi maior. A maior qualidade está aqui relacionada com a transferência para o time correto. Quando o incidente foi transferido para o Suporte de Primeiro Segundo Nível, quando deveria ter sido transferido para os Suportes de Terceiro Nível (ver a Figura 2), o problema não foi resolvido corretamente. Neste caso, o incidente somente foi apenas remediado, o que ocasionou a repetição do mesmo tipo de incidente por diversas vezes. Indiretamente, o método proposto diminuiria o tempo pois, quando o primeiro problema ocorresse, seria resolvido sem gerar mais novos incidentes no futuro. Isto foi observado por meio de experimentos de pesquisa com as mesmas aplicações envolvidas nas ordens de serviço das amostras.
Vários incidentes no cliente “X” mostram que o Suporte de Segundo Nível tentou resolver problemas direcionados para times mais especializados, tais como os bugs não determinísticos (Mandel bugs). No cliente “X”, que teve um número de transferências por incidente muito maior que o cliente “Y”.
No cliente “X”, comparando o processo atual com o processo proposto, mesmo que uma transferência somente fosse diminuída com o processo proposto, poderia-se economizar muito tempo, pois quando um chamado vai para uma fila de suporte, pode haver uma demora considerável, em função da carga de trabalho para as equipes, para que um recurso humano acesse o registro do incidente e comece a trabalhar. Além disso, dependendo do provedor de serviço, pode-se ter filas de suporte especializadas para cada produto de software, aumentando-se o tempo de recepção do incidente e atuação.
Analisando os bugs determinísticos (Bohr bugs) para o cliente “X”, observou-se que, em várias amostras, não havia uma descrição correta de resoluções de incidentes comuns, fazendo com que o Suporte de Primeiro Nível tivesse que transferir o incidente para o nível mais especializado. Se o primeiro nível consultasse na própria base do provedor pela aplicação “Z”, em muitos casos vieram procedimentos de resolução incompletos.
Utilizando-se o processo proposto, poderia-se definir procedimentos específicos voltados para cada aplicação de negócios. Esse tipo de característica é muito necessária, principalmente em provedores que possuem times distribuídos em diversos locais, de forma regional e internacional, e em provedores de computação em nuvem. Procedimentos pré- definidos poderiam ser colocados no data warehouse a partir da interação com experts no domínio do conhecimento, e estes poderiam ser executados pelo Suporte de Primeiro ou Segundo Níveis, evitando transferências desnecessárias para os níveis mais especializados de suporte.
Os níveis especializados de suporte, em algumas amostras de ordens de serviços, quando se analisa conjuntamente o histórico (log) de chamados do cliente, não encontraram facilmente a solução de vários incidentes que tinham uma ocorrência praticamente idêntica. Isto é consequência do conhecimento técnico não ser compartilhado entre turnos de trabalho diferentes de um mesmo time de suporte. As experiências de um recurso humano técnico são pouco compartilhadas entre os outros integrantes de time de suporte.
Em outras amostras, o nível especializado não notou que o problema era alinhado com o seu nível de conhecimento, transferindo novamente o problema para o nível menos
especializado, aumentando o tempo de resolução do incidente. Com o método proposto, esses problemas poderiam ser minimizados com um compartilhamento melhor do conhecimento e com a confirmação de que um determinado problema corresponde a um determinado nível de suporte.
O método proposto apresentou problemas relacionados a dados de entrada incompletos e muitas vezes em branco. Esses dados deveriam ser preenchidos pelos recursos humanos técnicos envolvidos nas ordens de serviço. Isto indica que a qualidade dos dados é fundamental para se alcançar bons resultados com o método proposto. Alguns campos em branco criaram dificuldades para a análise dos dados. A fase de limpeza dos dados foi importante para eliminar entradas que não agregariam nenhuma informação para o data warehouse. Esse problema poderia ser minimizado com um treinamento dos recursos humanos técnicos e uma contínua verificação da qualidade dos dados de entrada no sistema de ordens de serviço. Qualquer sistema de tomada de decisão se beneficiaria com essas ações.
Outro ponto importante a mencionar, é que os registros das ordens de serviço não foram suficientes em vários casos para suprir uma correta classificação, e que a base de dados de registros do cliente foi necessária para o método proposto ser utilizado. Outras bases de dados poderiam ser integradas para melhorar a eficácia do método proposto, como por exemplo, bases de conhecimento de produtos de softwares (Bancos de dados, Middlewares, Sistemas Operacionais, etc.).
O método proposto obteve uma redução de tempo em 71% dos incidentes para o cliente “Y”e 92,5% dos incidentes para o cliente “X”. Baseado nessas amostras, o método proposto foi mais rápido do que o método de gerenciamento de incidentes atual quando aplicado a estes mesmos clientes,
O experimento automatizado teve um desempenho mais rápido que o experimento manual. Considerando um mundo real, com uma empresa de suporte com alto volume de incidentes ocorrendo diariamente, em turnos de vinte horas, sete dias por semana (24 x 7), a solução automatizada seria a mais recomendada para implementar o método proposto.
Comparando como outros trabalhos como o AutoODC (HUANG et al. 2011), o processo proposto nesta pesquisa, possui uma parte de pré-processamento bem mais elaborada. No modelo AutoODC é aplicado o algoritmo de mineração de dados diretamente aos dados de texto puros sem uma estruturação prévia dos dados.
Em relação a pesquisa de Wang, Akella e Ramachandran (2010) onde temos sistema de análise de texto chamado Analisador e Recomendador de Requisições de Serviço ou Service Request Analyzer and Recommended (SRAR), que extrai informação crítica e pertinente a partir de documentos em texto de requisições de serviço de bases de dados de uma empresa de software usando técnicas de mineração, mas com uma inteligência de dados possui uma parte de pre-processamento bem mais completa com contextualização da palavra pesquisada utilizando o mecanismo de mala de palavras (Bag of words), porém não tem uma classificação de defeitos e funciona em um conjunto de problemas mais restrito (Serviço de redes). O processo proposto possui uma abordagem mais ampla por abordar problemas mais diversos.