ES2408112A2

ES2408112A2 - Método y sistema para la optimización y agilización de la resolución de incidencias

Info

Publication number: ES2408112A2
Application number: ES201131470A
Authority: ES
Inventors: Carolina VAZQUEZ GARCIA; Pedro GARCIA PARRA; Francisco Javier MOLINERO VELASCO; Anabel MONTERO CARRALAFUENTE
Original assignee: Telefonica SA
Current assignee: Telefonica SA
Priority date: 2011-09-07
Filing date: 2011-09-07
Publication date: 2013-06-18
Anticipated expiration: 2031-09-07
Also published as: ES2408112B1; ES2408112R1; WO2013034448A1

Abstract

Método para la optimización y agilización de la resolución de incidencias. En el método, las incidencias se indican en unos tiques generados por un sistema de gestión de tiques, y usando un módulo paralelo a dicho sistema de gestión de tiques para: recoger dichos tiques; resolver el tipo de incidencia por medio de modelos predictivos construidos a partir de datos históricos almacenados en dicho sistema de gestión de tiques; lanzar una sugerencia de actuación y/o notificar al sistema de gestión de tiques la actuación a realizar y/o lanzar automáticamente una tarea en función de una predicción obtenida; y reconstruir dichos modelos predictivos en función de validaciones o correcciones sobre la decisión final adoptada para cada incidencia, en donde los datos del sistema de gestión son extraídos mediante: una base de datos, servicios web, o un interfaz vía fichero. El sistema está dispuesto para implementar el método de la presente invención.

Description

Método y sistema para la optimización y agilización de la resolución de incidencias.

Sector de la técnica

La presente invención concierne, en un primer aspecto, a un método para la optimización y agilización de la resolución de incidencias, en el que dichas incidencias están indicadas en unos tiques generados por un sistema de gestión de tiques, y más concretamente a un método que comprende mediante el uso de un módulo paralelo a dicho sistema de gestión de tiques recoger dichos tiques, resolver en tiempo real el tipo de incidencia por medio de modelos predictivos construidos al menos a partir de datos históricos almacenados en dicho sistema de gestión de tiques y realizar al menos una de las acciones siguientes: lanzar una sugerencia de actuación, notificar al sistema de gestión de tiques la actuación a realizar y/o lanzar automáticamente una tarea en función de una predicción obtenida mediante dichos modelos predictivos.

Un segundo aspecto de la invención concierne a un sistema dispuesto para la implementación del método del primer aspecto.

Estado de la técnica anterior

Desde hace tiempo, las grandes compañías de telecomunicaciones vienen persiguiendo agilizar y automatizar, en la medida de lo posible, los procesos de mantenimiento, implementando sistemas que detecten los problemas en su red para poder solucionarlos cuanto antes o que gestionen de un modo más eficiente sus recursos. De esta forma se consigue tanto una reducción de costes como un aumento de la satisfacción de los clientes.

Para mejorar la eficiencia de la gestión de estos procesos se utilizan los sistemas de trouble ticketing, que básicamente se encargan de la gestión de los tiques desde el momento de su creación hasta que se consiguen solucionar y se cierran. Los tiques generalmente se crean de forma manual por el operador o de forma automática mediante sistemas automáticos de detección de alarmas. Una vez creado el tique, el técnico se encarga de realizar un análisis y un diagnóstico del problema, tomar la decisión de la acción o acciones a realizar para solucionarlo o bien derivarlo a otro grupo especializado si él no está capacitado para hacerlo.

Durante el ciclo de vida del tique, el operador puede realizar acciones como la derivación del tique a otra área de operación, establecimiento de prioridades de tratamiento de tiques, decisión de envío o no de un técnico al lugar de la avería para la solución del problema in-situ, etc.

Para dotar a estos sistemas de inteligencia y aprovechar el conocimiento de los técnicos, hasta ahora se estaban dirigiendo estos trabajos a soluciones basadas en sistemas propietarios y sistemas expertos, que necesitaban alimentarse del conocimiento adquirido por técnicos experimentados que tuviesen una amplia visión del negocio.

Desde el punto de vista de los sistemas de trouble ticketing (TT), se está intentando automatizar la gestión de los tiques, comenzando por la creación automática de los mismos [11] y siguiendo por la automatización de determinadas operaciones [7].

En los últimos años se están empezando a utilizar técnicas de Machine Learning y de Inteligencia Artificial en multitud de ámbitos. Ejemplos de ellos pueden ser los diagnósticos de averías de dispositivos, diagnósticos médicos, análisis de mercados, reconocimiento de voz y de imágenes, optimización de parámetros en procesos industriales, aplicaciones publicitarias, detección de fraude, seguridad informática, predicción de la demanda de energía eléctrica [1] [4].

Casos más concretos, y más relacionados con el ámbito de las telecomunicaciones son la optimización de las llamadas de un Call Center [2], detección del churn [3], predicción del tráfico de una red [4] y la detección de fallos hardware dentro de una red, correlando las distintas alarmas recogidas [5].

Dentro de las técnicas de Machine Learning, existen algoritmos de aprendizaje supervisado donde se cuenta con unas entradas y unas salidas deseadas y son los modelos los que se encargan de establecer una correspondencia entre ambas. Un ejemplo claro de estos tipos de técnicas son los problemas de clasificación, donde el sistema intenta etiquetar cada una de las muestras o ejemplos que le llegan en uno de los valores incluidos entre las categorías o clases posibles. El conocimiento adquirido por estos sistemas se basa en ejemplos previamente etiquetados y validados.

Se está trabajando en implementaciones y métodos que generalicen la aplicación del análisis predictivo a la solución del mayor número de problemas [9], en la actualización automática de modelos predictivos utilizados en un entorno de producción [10] así como en el refuerzo de los módulos de aprendizaje [8]. Son ejemplos de la problemática que está apareciendo a la hora de integrar todas estas técnicas a los entornos de producción.

Uno de los métodos que actualmente se están utilizando para decidir el modelo óptimo es la comparación de ciertos estadísticos de estos modelos. El estudio del área bajo la curva ROC, también denominado AUC (Area Under Curve), se basa en la relación entre la Sensibilidad y Especificidad del modelo, que representan la fracción de verdaderos positivos de un experimento frente a la fracción de verdaderos negativos del mismo experimento, respectivamente.

Entre los algoritmos que más se están utilizando para la resolución de problemas de clasificación están los algoritmos basados en árboles de decisión, algoritmos basados en la teoría de Bayes, redes neuronales, SVM, algoritmos basados en reglas (JRip), así como los métodos de Bagging [12] y Boosting [13] para conseguir unos modelos más robustos y estables.

Estudiando otro tipo de soluciones propietarias, se observa dificultad a la hora de integrarlas en el flujo de trabajo del sistema TT en tiempo real e ir recibiendo la información, sin necesidad de abordar adaptaciones, en la mayoría de los casos bastante costosas, sobre los sistemas TT.

Del mismo modo, se observa costoso y lento el desarrollo e inclusión de una solución similar para cada nuevo problema parecido que sea necesario resolver mediante técnicas de análisis predictivo. No se dispone de un mecanismo que agilice la construcción y selección de los modelos óptimos para cada problema y que permita incorporarlos al flujo de trabajo del sistema TT minimizando las adaptaciones del mismo.

A pesar de disponer de algoritmos ya diseñados que se podrían utilizar sobre los datos de sistemas TT, no es tan sencilla la aplicación de los mismos sobre ciertos datos. Estos datos pueden variar bastante debido a cambios en el negocio, que obligan a disponer de un mecanismo que permita chequear la validez de las predicciones a lo largo del tiempo. En el ámbito de aplicación es muy fácil que aparezcan efectos de degradación de los modelos por la variabilidad de los datos y debería ser posible interactuar con la plataforma, automatizando todo lo posible el proceso.

Ya que la solución está orientada al uso de históricos de operaciones realizadas sobre los tiques, hay que tener en cuenta que no todo el conocimiento que extraemos es válido, ya que en algunas ocasiones incluso se puede estar forzando a los modelos a aprender procedimientos erróneos de resolución de los tiques. Por este motivo, la aplicación directa de los algoritmos de clasificación sobre los datos del sistema TT, puede llevar a generar unos modelos predictivos que en lugar de agilizar y mejorar la gestión de los tiques, la ralentice debido a la acumulación de errores. Es necesario algún mecanismo para ser capaces de corregir esos casos, que a priori, estos algoritmos no proporcionan, dando la posibilidad al técnico de validar o corregir las predicciones de los modelos.

Explicación de la invención

Es necesario encontrar una alternativa al estado de la técnica que permita suplir las carencias detectadas, particularmente relacionadas a la falta de propuestas que puedan integrarse en el flujo de trabajo de un sistema TT en tiempo real y que reciban información sin necesidad de abordar adaptaciones así como la falta de un mecanismo que agilice la construcción y selección de modelos óptimos para cada problema presentado.

Por ello, la presente invención propone, un primer aspecto, un método para la optimización y agilización de la resolución de incidencias, en el que dichas incidencias están indicadas en unos tiques generados por un sistema de gestión de tiques.

Al contrario de las propuestas ya conocidas, el método de la invención, de una forma característica, comprende mediante el uso de un módulo paralelo a dicho sistema de gestión de tiques:

-: recoger dichos tiques;

-: resolver en tiempo real el tipo de incidencia por medio de modelos predictivos construidos al menos a partir de datos históricos almacenados en dicho sistema de gestión de tiques; y

-: realizar al menos una de las acciones siguientes: lanzar una sugerencia de actuación, notificar a dicho sistema de gestión de tiques la actuación a realizar y/o lanzar automáticamente una tarea en función de una predicción obtenida mediante dichos modelos predictivos.

Otros aspectos del método del primer aspecto de la invención son descritos según las reivindicaciones adjuntas de la 2 a la 13.

La presente invención propone, en un segundo aspecto, un sistema para la optimización y agilización de la resolución de incidencias dispuesto para la implementación del método del primer aspecto.

Otras características del sistema del segundo aspecto de la invención son descritas según las reivindicaciones adjuntas 14 y 15.

Breve descripción de los dibujos

Las anteriores y otras ventajas y características se comprenderán más plenamente a partir de la siguiente descripción detallada de unos ejemplos de realización con referencia a los dibujos adjuntos, que deben tomarse a título ilustrativo y no limitativo, en los que:

La Figura 1 ilustra el contexto en el que se engloba la presente invención.

La Figura 2 muestra los submódulos principales de la plataforma propuesta en la presente invención.

La Figura 3 muestra un esquema detallado de los bloques integrantes de cada submódulo de la plataforma propuesta en la presente invención.

La Figura 4 muestra los submódulos y bloques que soporta la Running Framework (o plataforma de ejecución), los de la Database (o base de datos) y los del Web Server (o servidor web) según una posible implementación de la arquitectura de la plataforma propuesta en la presente invención.

La Figure 5 muestra los submódulos y bloques que intervienen en la generación de los modelos predictivos en la plataforma de la presente invención.

La Figura 6 detalla el flujo de información que intercambian los submódulos y bloques que intervienen en la generación de los modelos predictivos en la plataforma de la presente invención.

La Figura 7 muestra los submódulos y bloques que intervienen en la clasificación del tique que llega a la plataforma de la presente invención.

La Figura 8 detalla el flujo de información que intercambian los submódulos y bloques que intervienen en la clasificación del tique que llega a la plataforma de la presente invención.

La Figura 9 muestra los submódulos y bloques que intervienen en la recuperación del feedback tanto de los técnicos entendidos como usuarios de la plataforma como el derivado de las acciones realizadas sobre los tiques para intentar conocer el valor real de respuesta al problema que se intenta predecir en la plataforma de la presente invención.

La Figura 10 detalla el flujo de información que intercambian los submódulos y bloques que intervienen en la recuperación del feedback tanto de los técnicos como el derivado de las acciones realizadas sobre los tiques para intentar conocer el valor real de respuesta al problema que se intenta predecir en la plataforma de la presente invención.

Descripción detallada de unos ejemplos de realización

Se trata de un método y sistema que trabaja en tiempo real para optimizar y agilizar la resolución de tiques, en principio de cualquier tipo, pero particularizado al mundo de las operaciones de mantenimiento de una operadora de telecomunicaciones. Para ello, se basa en sugerencias de actuación integrables en el sistema de TT o automatización de determinadas tareas, apoyándose en técnicas de aprendizaje supervisado.

Está basado en modelos predictivos construidos a partir de los datos históricos almacenados en el sistema de trouble ticketing. Estos modelos pueden ser reconstruidos automáticamente en aquellos casos en los que la herramienta detecte que el modelo deja de ser fiable. Contiene una funcionalidad de obtención de feedback tanto por parte de los técnicos, como del propio sistema de trouble ticketing, para corregir o reforzar, según el caso, el conocimiento previamente generado.

Es fácilmente integrable en el flujo de trabajo del sistema de TT ya que puede recoger los datos en el momento en que llegan al sistema, mediante varios tipos de interfaz. Procesa la información y calcula las predicciones en un servidor externo al sistema origen de los datos. Finalmente, en función de la configuración, puede enviar una notificación con la actuación sugerida, o lanzar automáticamente una tarea determinada según el valor de la predicción.

Es un método o mecanismo para la optimización y agilización de la resolución de tiques, recomendando en tiempo real el mejor uso de los recursos en términos de reducción de costes y aumento de la satisfacción del cliente. Se utilizan técnicas de aprendizaje supervisado integrables en sistemas TT que están ya en funcionamiento.

Se parte de datos históricos almacenados en los sistemas TT, siendo aplicable a cualquier problema asociado a tiques que se pueda resolver mediante técnicas de clasificación.

Como casos concretos de aplicación del mecanismo propuesto tenemos la integración de este sistema con un sistema de gestión de reclamaciones de una operadora de telecomunicaciones para intentar anticiparse a la repetición de una avería de un cliente. Es decir, intentar predecir si una determinada reclamación no se va a resolver satisfactoriamente originando, en un plazo determinado, la reaparición de la avería. Un caso similar sería la detección de aquellas instalaciones de un servicio que van a provocar una avería en un plazo relativamente corto tras la finalización de la instalación.

Aplicado a otro sistema de TT encargado de gestionar incidencias de elementos de la planta instalada, en el momento de la creación del tique, el sistema es capaz de decidir si se debe enviar un técnico para solucionar el problema o si éste se puede solucionar de forma remota, evitando desplazamientos de técnicos innecesarios. Es posible también determinar si ese tique realmente necesita atención o se podría cerrar automáticamente porque realmente no se trataba de un problema.

La plataforma es capaz de interactuar en tiempo real con el sistema de TT e ir enriqueciendo la información del tique a lo largo de su ciclo de vida en el sistema. En el momento de la creación del tique, este llega tanto al sistema TT como a nuestra plataforma, tal y como se mostró en la Figura 1.

Como se ha comentado, se trata de una plataforma externa al sistema de TT , compuesta de un conjunto de módulos que recogen la información de los sistemas de TT, la preparan para aplicarles los modelos predictivos, lanzan la predicción correspondiente sobre los problemas a abordar y disparan una acción preconfigurada (lanzamiento de una notificación, ejecución de una determinada operación sobre el tique,…)

La plataforma se compone de una serie de módulos que se comunican entre sí. Estos módulos automatizan la recolección de datos de los sistemas origen, realizan una preparación de los mismos y lanzan una predicción con una probabilidad determinada del problema en cuestión. Esta predicción se puede materializar en una notificación, una sugerencia de actuación o en el lanzamiento de un automatismo de una determinada tarea sujeto a una configuración previa.

Otro grupo de módulos se encargan de chequear si los modelos predictivos siguen siendo válidos o no. Si no lo son, automáticamente los reconstruyen y los dejan disponibles para que el administrador que gestiona la plataforma realice los tests oportunos y los incluya en la herramienta. Existe la posibilidad de que la herramienta automáticamente, en base a unos umbrales establecidos de la tasa de error permitida, los incorpore a los módulos clasificadores, responsables de lanzar las predicciones.

Existen tres módulos principales: Knowledge Generator, Online Engine y Feedback Collector, tal y como se mostró en la Figura 2.

Knowledge Generator recoge los datos del sistema TT para generar los training sets y test sets necesarios y con ellos construye los modelos predictivos. Además utiliza las validaciones o correcciones de casos recuperadas desde el Feedback Collector para corregir o reforzar los modelos generados previamente.

Online Engine trabaja en tiempo real recibiendo los tiques en el momento de creación de los mismos en el sistema TT, los prepara y les aplica los modelos predictivos para obtener el resultado de la predicción. Este resultado podría traducirse en una sugerencia de actuación a través de una consola web, una notificación sobre el sistema de TT

o una acción preconfigurada sobre un tique concreto en el sistema TT. Los dos últimos casos necesitan que el sistema de TT soporte ese tipo de operaciones, vía algún tipo de interfaz estandarizada.

Feedback Collector es un módulo que recupera información sobre la decisión final tomada para cada caso, bien porque los técnicos la introducen directamente en la plataforma o porque la misma plataforma se encarga de buscar la acción que finalmente realizó el técnico. Esta información se utilizará para corregir o reforzar los modelos.

Existe un mecanismo de entrada de información al sistema para proporcionarle capacidades de parada, arranque y configuración de todos los módulos, así como funcionalidades más concretas para la monitorización del comportamiento de los modelos predictivos. Ejemplos de acciones que se pueden realizar utilizando las capacidades de configuración de los módulos son:

-: Determinar los tipos de algoritmos, de entre los contemplados por la plataforma, que se utilizarán para la reconstrucción y comparación de varios modelos seleccionando después los modelos con los algoritmos óptimos.

-: Definir un rango de tiques a utilizar en el training set y en test set para la reconstrucción de modelos tanto de forma manual como automática.

-: Establecer el carácter manual o automático de sustitución de los modelos predictivos antiguos por los recién generados.

-: Configurar las acciones a realizar según el resultado de la predicción (visualización del resultado en la consola web, sugerencia de actuación, notificación, ejecución de un automatismo,...)

En la Figura 3 se mostró el esquema de los submódulos dentro de los módulos principales:

Data Collector: Módulo que recupera la información del TT System para poder empezar a trabajar con ella en la plataforma. El mecanismo de extracción de información del sistema origen puede ser mediante sondeo a la Database (o base de datos), servicios web, interfaz vía fichero, según los requerimientos del sistema. Es posible configurar esta recuperación de información para trabajar en tiempo real como se utiliza en el Online Engine o para recuperar datos para la construcción de los modelos en el Knowledge Generator.

Preprocessing Data: Módulo que realiza las operaciones necesarias para preparar las instancias de entrada a los algoritmos. Se utiliza tanto en el Online Engine para generar las entradas necesarias para los modelos predictivos, como en el Knowledge Generator para preparar los training sets y test sets para la construcción de los modelos.

Predictive Engine: Módulo clasificador que lleva embebido el modelo predictivo, recibe los datos de los tiques preprocesados, les aplica el modelo y obtiene el resultado de la clasificación para el problema propuesto.

Effector: Módulo encargado de ejecutar las acciones configuradas en la plataforma sobre el sistema TT, que van desde el envío de una notificación con una sugerencia de actuación a una actuación directa sobre el sistema, realizando automáticamente una operación sobre el tique.

Models Builder: Generador de modelos predictivos, que partiendo de una serie de tiques de entrenamiento, configurables por el administrador, automáticamente va construyendo y testeando una lista prefijada de algoritmos, tanto de clasificación como de selección de atributos. Automáticamente se establece la mejor opción basada en comparación de las curvas ROC de los distintos modelos generados. Tanto los modelos como los resultados de sus estadísticos se almacenan en el Models Repository. El administrador puede ver estos resultados mediante alguna herramienta de visualización de la salida y realizar testeos configurables con distintos juegos de datos o tener preconfigurada la inserción automática del modelo en el Predictive Engine.

Models Checker: Módulo que automáticamente comprueba la bondad de los modelos, utilizando los estadísticos del mismo. En el momento en que el modelo comienza a arrojar resultados peores a los establecidos en el umbral configurable por el administrador, se lanza una alarma.

Models Repository: Repositorio que almacena los modelos predictivos que se han ido construyendo mediante el Models Builder. Guarda también información sobre los estadísticos de los modelos y las comparativas calculadas mediante el Models Checker.

User Feedback Collector: Módulo mediante el que el técnico introduce feedback a la plataforma, validando o corrigiendo el valor de las predicciones, ayudando a reforzar o corregir las decisiones para conseguir una mejora de los modelos.

System Feedback Collector: Módulo mediante el que se recupera feedback del propio TT System, descubriendo las decisiones que finalmente se tomaron sobre los tiques, comparando éstas con la predicción de la plataforma y utilizándolas para reforzar o corregir el conocimiento almacenado en los modelos.

Feedback Selector: Este módulo selecciona el feedback a enviar al Models Builder o al Models Checker en función de lo que se haya configurado previamente (si están activos ambos métodos de recuperación de feedbak, mediante configuración se decide cuál de los dos tiene mayor peso en caso de inconsistencia).

• Arquitectura

Una posible implementación software del sistema podría ser la siguiente, aunque no está sujeta a ninguna restricción.

Framework (o Plataforma de ejecución): Contenedor sobre el que se ejecutan los distintos procesos, con algún mecanismo de comunicación entre ellos.

Database (o Base de datos): Permite la persistencia de información necesaria para la recuperación ante posibles errores, así como del modelo de datos genérico que almacena la información de configuración y administración de los distintos módulos. Almacena los resultados de las predicciones, los estadísticos de los modelos y el resto de información necesaria para la visualización. También mantiene el repositorio de modelos, por si es necesaria la recuperación de alguno de ellos en cualquier momento.

Servidor Web: Sobre el servidor web se despliegan las herramientas accesibles por el técnico para la introducción de entradas al sistema y visualización de las salidas.

Para cada uno de los módulos principales se mostraron en la Figura 4 los submódulos que podrían soportarse en la Framework o Plataforma de Ejecución, los que podrían utilizar la capa de Database o Base de Datos y los que se podrían desplegar sobre un Web Server o Servidor Web.

• Funcionamiento e interconexión de los módulos

A continuación se detalla la interconexión entre submódulos y su funcionamiento dentro de los módulos principales, según el modo de operación en el que se encuentre el sistema. Hay que tener en cuenta que la operativa normal comprende la ejecución simultánea de todos los módulos principales, pero es posible mediante configuración activar o desactivar los que se consideren oportunos.

-: Operativa de construcción de los modelos predictivos

El Knowledge Generator se encarga de generar los modelos predictivos que componen el módulo de aprendizaje del sistema. En la Figura 5 se mostraron los módulos que intervienen y los pasos que detallan esta funcionalidad. En la Figura 6 se mostró un diagrama de bloques con el flujo de información:

1.: El módulo Data Collector se conecta al TT System para recuperar los datos con los que se generarán los training set y test set con los que posteriormente generar los modelos predictivos.

2.: Si el Feedback Collector está activado y tiene feedback, corrige los tiques recuperados del TT System para mejorar los datos con los que generar los modelos.

3.: Se pasan las instancias al módulo Preprocessing Data para prepararlas y generar el training set y los test sets.

4.: El Preprocessing Data pasa el training set y los test set al Models Builder, que va probando distintas combinaciones de atributos, seleccionados mediante métodos InfoGain, GreedyStepwise o BestFirst, sobre distintos tipos de algoritmos (Naive Bayes, Bayes Net, C.45, AdaBoost, Bagging, JRip, SVM). Se optimizan heurísticamente los parámetros de estos algoritmos, hasta encontrar el que aporte un mejor comportamiento mediante comparaciones de sus estadísticos (área ROC, accuracy and error percentage).

5. El Models Builder envía los modelos generados, sus estadísticos y las comparativas al Models Repository.

6.: El Models Checker realiza los tests sobre el modelo elegido y comprueba que los estadísticos cumplan un umbral predefinido que dé como bueno el modelo.

7.: Se envía el nuevo modelo desde el Models Repository al Predictive Engine, Se permite mandar la orden de sustitución del modelo, manualmente o de manera automática.

8.: Se reinicia de forma manual o automática, según la configuración, el Predictive Engine que reanuda su funcionamiento con el nuevo modelo.

-: Operativa de clasificación en tiempo real

En el Online Engine, partimos de que anteriormente se ha utilizado el Knowledge Generator para la construcción del modelo que optimiza el problema y se ha incrustado en el Predictive Engine. En la Figura 7 se mostraron los módulos que intervienen y en la Figura 8 un diagrama de bloques con el flujo de información:

1.: El Data Collector recupera los tiques del sistema TT pendientes de procesar por el sistema. En función de los requisitos del sistema, la recuperación se implementará mediante distintos mecanismos (bases de datos, servicios web o ficheros). El Data Collector persiste los tiques en un repositorio temporal para hacer frente a posibles errores de comunicación con el sistema.

2.: El Data Collector, informa al Preprocessing Data del siguiente tique a procesar, y lo prepara para pasarlo al Predictive Engine y ajustarlo al formato que espera recibir el modelo predictivo.

3.: El Predictive Engine pasa la instancia por el modelo y lanza la predicción (clasificación con valores de clase SI/NO en respuesta al problema propuesto)

4.: El Effector, según se haya configurado, puede devolver un mensaje de salida o ejecutar una acción automáticamente sobre el TT System

5. La salida generada por el Predictive Engine se pasa al Models Checker.

6.: Se recoge el feedback manual o automático y se pasa al Models Checker para que lo compare con las salidas del Predictive Engine y compruebe la validez del modelo.

7.: Se calcula el área ROC del modelo enfrentando las predicciones lanzadas por el Predictive Engine con el Feedback recuperado manual o automáticamente

8. Si el área ROC del modelo está por debajo del valor permitido, se dispara la reconstrucción de los modelos.

-: Operativa de recuperación de feedback

Feedback Collector recupera el feedback tanto de los técnicos como el derivado de las acciones realizadas sobre los tiques, para conocer el valor real de respuesta al problema que se intenta predecir. Esta información sirve para realimentar tanto el Models Builder como el Models Checker.

En la Figura 9 se mostraron los módulos que intervienen y en la Figura 10 el diagrama de bloques con el flujo de información:

1.: Es posible configurar el modo de recuperación de Feedback, pudiendo activar sólo el User Feedback Collector, sólo el System Feedback Collector o ambos, ponderando el resultado mediante el Feedback Selector.

2.: El System Feedback Collector recupera del sistema de TT las acciones que realmente se realizaron sobre cada tique.

3. El System Feedback Collector envía el feedback recuperado al Feedback Selector

4.: El User Feedback Collector recupera las validaciones o correcciones de las predicciones que introduce el técnico y se las envía al Feedback Selector.

5.: El Feedback Selector envía el feedback final al Models Checker para que este pueda realizar las validaciones de la precisión de los modelos

6.: Según los resultados extraídos del Models Checker, se envía la orden para que el Models Builder regenere el modelo utilizando como entrenamiento y test los datos que llegan del Preprocessing Data enriquecidos con los que llegan del Feedback Collector.

• Casos de uso

Para cualquiera de los casos de uso expuestos a continuación el funcionamiento se puede describir como sigue.

Un usuario experto con permisos de administración de la plataforma, es capaz de conectarse al histórico de tiques del sistema y recuperar un rango dado de datos para usar como entrenamiento. Con ellos se genera el modelo mediante el módulo Models Builder, que automáticamente construye el modelo óptimo entre los propuestos (Naive Bayes, BayesNet, Adaboost, Bagging, SVM, Comité, C.45, JRip). Realiza una selección de atributos de entrada para los que mejor funcione (InfoGain, GreedyStepwise, BestFirst) y una búsqueda heurística de los parámetros que lo optimizan.

El administrador, una vez construido el modelo, es capaz de seleccionar distintos conjuntos de test conectándose al sistema de TT y validar las salidas. Una vez que los estadísticos del modelo superan los umbrales admitidos, es capaz de sustituirlo en el Predictive Engine, que mediante un reinicio del módulo, empezaría a trabajar con el nuevo modelo.

Una vez que está listo el Predictive Engine, van entrando los nuevos tiques recuperados por el Data Collector. Son procesados por el módulo Preprocessing Data y el Predictive Engine decide, en base al conocimiento integrado en el modelo predictivo, genera la predicción para la problemática particularizada.

De acuerdo a lo configurado, esta predicción se envía a la salida para que un técnico lo analice. Si lo cree oportuno, puede introducir feedback, reforzando la decisión en caso de que haya sido un acierto o corrigiéndola en caso de haber fallado, para en el futuro utilizarla en la siguiente reconstrucción del modelo.

Además se pueden enviar mensajes directamente al TT System, mediante un sistema de notificaciones adecuado a la interfaz diseñada entre ambos sistemas. También es posible lanzar un automatismo que simule una determinada acción de un técnico sobre el tique.

A continuación se describen varios casos de uso de la plataforma en el ámbito de problemas específicos de sistemas de TT.

-: Detección de reaparición de una misma avería en un sistema de TT de reclamaciones de cliente

Se trata de un caso de aplicación a un sistema de TT de reclamaciones de una operadora de telecomunicaciones. El problema a resolver es determinar si una reclamación dada va a reaparecer en el sistema tras un período dado porque no se haya solucionado correctamente en una primera actuación del técnico.

La plataforma es capaz de anticipar si se va a producir o no en el futuro una repetición de cada una de las averías. Esta predicción se muestra a los operadores, además de recomendarles un conjunto de acciones a realizar sobre el tique, como por ejemplo, un marcado del cliente en cuestión para hacerle un seguimiento especial o establecer llamadas de control para comprobar si tiene algún problema con la resolución del tique.

-: Detección de aparición de averías de infancia tras la instalación de un servicio

Un caso similar sería el aplicado a la detección de posibles averías de infancia tras la instalación de un servicio. Estas averías son las que aparecen en un período muy temprano posterior a la instalación, y que pueden tener que ver con una instalación incorrecta del servicio.

Nuestra plataforma se conecta al sistema de TT que recoge las peticiones de instalación. En tiempo real, la plataforma recibe la petición y se lanza la predicción. Según se decida si va a provocar o no avería de infancia, las posibles acciones a llevar a cabo, pueden ser similares al caso anterior, un marcado de clientes para hacerles un seguimiento especial, un marcado del tique para hacer un análisis postinstalación o algún otro tipo de operación definida por el administrador.

-: Detección de la necesidad de enviar un técnico a resolver una avería o posibilidad de resolverla de forma remota.

En este caso, la plataforma se conecta a un sistema de TT encargado de gestionar incidencias de la planta instalada de una compañía de telecomunicaciones.

Con el sistema propuesto se consigue predecir en qué casos es necesario el desplazamiento de un técnico hasta el lugar indicado de la avería o si, por el contario, es un problema que va a ser solucionable de forma remota. Los gastos asociados a uno y otro caso son muy diferentes.

-: Detección de la productividad de la resolución de la avería

En este caso, mediante la utilización de este sistema, se puede predecir si el trabajo que en teoría debería hacerse para resolver la avería asociada a un tique, va a ser productivo o no, es decir si es necesario asociársela a un trabajador (de atención localizada o en remoto) o si lo mejor es cerrar directamente el tique porque no se va a producir ningún error en el sistema.

• Ventajas de la invención

Mediante el sistema, la adaptación a nuevos escenarios se realiza de manera muy sencilla. Es un mecanismo muy flexible para este tipo de problemas, resolviendo la comunicación con el sistema de TT para la recuperación de tiques mediante interfaces preparadas de lectura de ficheros, sondeo a la Database (o base de datos) o utilizando el conector necesario.

Simplemente habría que realizar adaptaciones mínimas en los módulos Data Collector y Preprocessing Data. Se debería adaptar además el Effector, en los casos en que se configura la actuación directa sobre el sistema de TT. El resto son módulos genéricos que no dependen de la arquitectura del sistema de TT.

El Knowledge Generator permite automatizar el proceso de búsqueda del modelo óptimo para cada problema determinado. Este módulo se puede ir ampliando para que contemple un mayor número de algoritmos permitidos. Desde aquí se pueden ir validando los modelos que están trabajando en tiempo real y almacenando sus estadísticos, comprobando si la desviación de los resultados está dentro del rango permitido. En caso de que no esté dentro de este rango, automáticamente se reconstruyen los modelos. Con este mecanismo, conseguimos corregir o disminuir las desviaciones temporales de los resultados de nuestras predicciones.

El Feedback Collector, facilita un mecanismo de corrección o refuerzo de los modelos predictivos, basado en la experiencia de técnicos expertos que validan o corrigen nuestras predicciones y en la experiencia de técnicos que sin validar o corregir explícitamente los resultados, han dejado reflejadas sus actuaciones en el sistema de TT.

Mediante configuración, se pueden establecer los tipos de algoritmos que se van a lanzar para la generación automática de modelos, así como la selección automática de atributos y la búsqueda heurística de parámetros que optimizan el resultado de los algoritmos. No es necesario el paso por todos los tipos de algoritmos si ya son conocidos los que ofrecen un mejor comportamiento. Se pueden establecer los umbrales de los estadísticos de los modelos que deciden si estos siguen siendo válidos o no según van entrando nuevos tiques a lo largo del tiempo en la plataforma. Se pueden chequear estos valores y decidir si reemplazar o no el modelo antiguo por el que se acaba de generar. Se puede testear este modelo con test sets configurables por el administrador. En caso de que todo vaya bien se puede enviar la orden de sustitución de los modelos, parando los módulos, sustituyendo el modelo y volviéndolos a reiniciar. Se puede configurar la acción a realizar tras el lanzamiento de la predicción, envío de mensajes visibles desde el sistema de TT, mensajes a la salida, ejecución de acciones directamente sobre el sistema de TT, mediante una interfaz para interactuar como un usuario del sistema y que pueda realizar acciones.

Desde el punto de vista comercial, la aplicación de esta plataforma de Analítica Predictiva, consigue aportar a la operadora beneficios en términos de reducción de OPEX, ya que con ella se gana en eficiencia, optimizando la 5 gestión de los recursos. También se traduce en un aumento de la satisfacción del cliente, ya que se logra reducir el

tiempo de resolución de los tiques además de ayudar a encontrar la mejor solución de los mismos.

Un experto en la materia podría introducir cambios y modificaciones en los ejemplos de realización descritos sin salirse del alcance de la invención según está definido en las reivindicaciones adjuntas. ACRÓNIMOS 10 AUC Area Under Curve ROC Receiver Operating Characteristic SVM Support Vector Machine TT Trouble Ticket

REFERENCIAS

[1] Fabien Girardin, Josep Blat, Francesco Calabrese, Filippo Dal Fiore, and Carlo Ratti. Digital footprinting: Uncovering tourists with user-generated content. IEEE Pervasive Computing, 7(4):36Ð43, 2008

[2] Tye Rattenbury, Nathaniel Good, Mor Naaman: Towards automatic extraction of event and place semantics from flickr tags. SIGIR 2007: 103-110

Claims

REIVINDICACIONES

1.- Método para la optimización y agilización de la resolución de incidencias, estando dichas incidencias indicadas en unos tiques generados por un sistema de gestión de tiques, caracterizado porque comprende mediante el uso de un módulo paralelo a dicho sistema de gestión de tiques:

-

recoger dichos tiques;

-

resolver en tiempo real el tipo de incidencia por medio de modelos predictivos construidos al menos a partir de datos históricos almacenados en dicho sistema de gestión de tiques;

-

realizar al menos una de las acciones siguientes: lanzar una sugerencia de actuación, notificar a dicho sistema de gestión de tiques la actuación a realizar y/o lanzar automáticamente una tarea en función de una predicción obtenida mediante dichos modelos predictivos; y

-

reconstruir de forma manual o automática dichos modelos predictivos en función de validaciones o correcciones sobre la decisión final adoptada para cada incidencia indicada en dichos tiques, dichas validaciones o correcciones provenientes de un técnico o de dicho sistema de gestión de tiques,

en donde los datos de dicho sistema de gestión de tiques son extraídos mediante: una base de datos, servicios web, o un interfaz vía fichero.

2- Método según la reivindicación 1, en el que dichos sistemas predictivos comprenden una clasificación de dichos tiques en función del tipo de incidencia que indican.
3.- Método según la reivindicación 3, que comprende generar dichos modelos predictivos testeando una lista prefijada de algoritmos mediante tiques configurables de entrenamiento, escogiendo aquellos modelos predictivos que presenten mejores características en función de curvas “Receiver Operating Characteristic”, o curvas ROC.
4.- Método según la reivindicación 1, que comprende emplear dichos datos en tiempo real para aplicarlos a dichos modelos predictivos o emplear dichos datos para dicha reconstrucción de dichos modelos de predicción, dichos datos comprendiendo dichos tiques.
5.- Método según cualquiera de las reivindicaciones anteriores, que comprende calcular los estadísticos de dichos modelos predictivos y comprobar la bondad de dichos modelos predictivos en función de al menos un umbral configurable.
6.- Método según la reivindicación 5, en el que dicha generación de dichos modelos predictivos comprende:

-

realizar dicha extracción de datos de dicho sistema de gestión de tiques;

-

corregir tiques asociados a dichos datos mediante dichas correcciones provenientes de técnicos o de dicho sistema de gestión de tiques;

-

generar dichos tiques configurables de entrenamiento mediante la preparación de dichos datos y/o tiques corregidos;

-

realizar combinaciones de dichos tiques configurables con dichos algoritmos;

-

optimizar heurísticamente parámetros de dichos algoritmos en función de estadísticos obtenidos de dichas combinaciones;

-

escoger al menos un modelo predictivo en función de dichos estadísticos; y

-

realizar dicha comprobación de bondad de dicho modelo predictivo. 7.- Método según la reivindicación 6, en el que dichos algoritmos son del tipo Naive Bayes, Bayes Net, C.45,

AdaBoost, Bagging, JRip o Support Vector Machine. 8.- Método según la reivindicación 5, 6 ó 7, en el que dicha clasificación de dichos tiques comprende:

-

realizar dicha extracción de datos de dicho sistema de gestión de tiques;

-

ajustar tiques asociados a dichos datos al formato requerido por dichos modelos predictivos;

-

lanzar una clasificación de una incidencia asociada a uno de dichos tiques como resultado de aplicar dichos modelos predictivos sobre dicho tique; y

-

dar un mensaje de salida o ejecutar una acción automáticamente en función de dicha clasificación.
9.- Método según cualquiera de las reivindicaciones anteriores, que comprende predecir la repetición de una incidencia asociada a dichos tiques si una actuación previa para solucionar dicha incidencia resulta insatisfactoria.
10.- Sistema para la optimización y agilización de la resolución de incidencias, estando dichas incidencias 5 indicadas en unos tiques generados por un sistema de gestión de tiques, caracterizado porque comprende un módulo paralelo a dicho sistema de gestión de tiques que contiene los siguientes sub-módulos:

-

submódulo generador, que recoge dichos tiques de dicho sistema de gestión de tiques y crea modelos predictivos;

-

submódulo predictor, que resuelve en tiempo real el tipo de incidencia por medio de dichos modelos

10 predictivos construidos al menos a partir de datos históricos almacenados en dicho sistema de gestión de tiques y realiza al menos una de las acciones siguientes: lanza una sugerencia de actuación, notifica a dicho sistema de gestión de tiques la actuación a realizar y/o lanza automáticamente una tarea en función de una predicción obtenida mediante dichos modelos predictivos; y

-

submódulo colector de feedback, que corrige o refuerza dichos modelos predictivos en función de información

15 introducida por un técnico o de información extraída de dicho sistema de gestión de tiques, dicha información referente a la decisión final tomada para resolver dichas incidencias,

en el que dichos submódulos de dicho módulo paralelo a dicho sistema de gestión de tiques disponen de un mecanismo de comunicación entre sí.
11.- Sistema en el que dichos submódulos implementan el método según cualquiera de las reivindicaciones 20 anteriores de la 1 a la 9.

Figura 1

Figura 2 Figura 3 Figura 4 Figura 5

Figura 7

Figura 8 Figura 9