ES2383307T3 - Procedimiento y sistema para generar señales de instrucción para realizar intervenciones en una red de comunicación, y producto de programa informático correspondiente - Google Patents

Abstract

Un procedimiento de generación de señales de instrucción dispuestas en flujos de trabajo para realizarintervenciones en equipos de red incluidos en una red de comunicación (N), en el que dichos equipos de red tienenagentes proxy de recursos (RP1, ... , RPn) asociados, incluyendo el procedimiento las etapas de:- proporcionar una arquitectura distribuida de agentes proxy de gestión de intervenciones (PP1, ... , PPn) paragestionar intervenciones en los equipos de red, estando dichos agentes proxy de gestión de intervencionesasociados a dispositivos terminales,- acoplar con dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) interfaces personales (PI) paragenerar dichas señales de instrucción dispuestas en flujos de trabajo, y- generar señales de instrucción para realizar una intervención en al menos un equipo de red de dicha red decomunicación mediante uno de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) de una manerainteractiva (PTP) con al menos uno de dichos agentes proxy de recursos (RP1, ... , RPn) asociado con dicho equipode red, por lo que dichas señales de instrucción son una función del estado de dicho equipo de red.

Description

Procedimiento y sistema para generar señales de instrucción para realizar intervenciones en una red de comunicación, y producto de programa informático correspondiente.

Campo de la invención

[0001] La presente invención se refiere a técnicas que permiten la generación de señales de instrucción organizadas como flujos de trabajo para realizar intervenciones en una red de comunicación.

[0002] La invención ha sido desarrollada prestando particular atención a su posible uso en el contexto de plataformas distribuidas para gestionar y dar soporte a las operaciones de los empleados y de los clientes.

Descripción de la técnica relacionada

[0003] Los costes de los procesos operacionales, como los que son para proporcionar nuevos servicios a los clientes o para eliminar fallos y averías, representan un porcentaje importante de los costes que tienen que afrontar anualmente los operadores de telecomunicaciones. De ahí la importancia de los procedimientos/sistemas destinados a reducir dichos costes mediante herramientas que den soporte a las actividades tanto de los empleados del operador como de los clientes, que de este modo pueden implicarse directamente en la eliminación de problemas relacionados con los equipos del local del cliente.

[0004] El soporte a los empleados y al cliente, quienes están directamente implicados en acciones de reparación de fallos/averías, puede proporcionarse usando dos herramientas principales: sistemas de gestión de conocimientos (KMs, Knowledge Management Systems), o más precisamente sistemas de gestión de conocimientos operacionales (OKMs, Operational Knowledge Management Systems), y plataformas de gestión avanzadas, consideradas no como entidades separadas, sino como componentes de una solución integrada y completa.

[0005] Por “Gestión de conocimientos (KM)” se entiende la actividad que permite la creación, difusión y utilización de los conocimientos de una organización. Entre los diversos enfoques de la KM, las compañías generalmente prefieren el enfoque local, que se centra en la gestión de una parte de los conocimientos y en objetivos específicos (por ejemplo, toma de decisiones, resolución de problemas, etc.). La gestión de conocimientos operacionales (OKM, Operational Knowledge Management) es un enfoque local de la gestión de conocimientos, centrado en la gestión de los conocimientos operacionales. Este tipo de conocimientos incluye procedimientos y técnicas (prácticas operacionales) necesarios para llevar a cabo una tarea particular o una actividad específica. Los usuarios típicos de un OKMS son ingenieros in situ de una compañía y asesores de un centro de atención telefónica.

[0006] Los sistemas KM/OKM que representan el nivel actual de desarrollo de estas técnicas se describen, por ejemplo, en el documento US-A-2004/0044542 y el artículo de G. Valente y A. Rigallo: “Remoter: an Operational Knowledge Management System for Telecommunication Operators”, Taller sobre gestión de conocimientos y memorias organizativas, 16ª Conferencia Europea sobre Inteligencia Artificial (ECAI), 2004.

[0007] Las soluciones descritas en los documentos anteriores se proponen como herramientas para dar soporte a actividades de resolución de problemas como las que pueden ser llevadas a cabo por los empleados de un operador de telecomunicaciones (para encargarse de las reclamaciones de los clientes o para satisfacer las solicitudes de nuevos servicios por parte de los clientes) o incluso por el propio cliente, implicado directamente en actividades de cuidado autónomo de los equipos en su local.

[0008] En particular, el documento US-A-2004/0044542 describe un procedimiento y un sistema para adquirir y compartir los conocimientos entre el personal técnico de una compañía dada, entre dicho personal y los usuarios y entre los usuarios y el personal técnico de otras compañías. Dicho procedimiento y sistema puede aplicarse a diversos dominios, entre los cuales también se incluye el dominio de los servicios de telecomunicaciones, y proporcionan soporte a las actividades de resolución de problemas, usando enfoques de razonamiento basado en casos y de razonamiento basado en modelos.

[0009] En cambio, en el artículo de Valente y Rigallo se define un sistema de gestión de conocimientos operacionales (OKM) denominado como Remoter, usándose dicho sistema en un contexto de telecomunicaciones para dar soporte a los técnicos de un operador de telecomunicaciones durante sus actividades diarias. En particular, Remoter se ha usado y probado en el contexto de los procesos de suministro y garantía de servicios ADSL, en los que los técnicos deben reaccionar en poco tiempo y escoger la mejor solución. El propósito del sistema es permitir que los técnicos compartan, adquieran y apliquen sus conocimientos operacionales para tomar decisiones óptimas en tiempo real. Dicho sistema usa el enfoque de razonamiento conversacional basado en casos para dar soporte a la resolución de problemas.

[0010] El documento WO-A-2005/018249 describe una arquitectura de sistema basada en un paradigma de agentes y con un alto grado de flexibilidad y escalabilidad para gestión distribuida de una red de telecomunicaciones y de los servicios soportados. Los puntos clave de dicha arquitectura son:

-

una plataforma para gestión de red y servicios basada en agentes distribuidos, asociada a motores de flujo de trabajo y motores de reglas, y organizada en tres niveles jerárquicos;

-

motores de procesos (motores de flujo de trabajo y motores de reglas) usados no sólo para la coordinación de los componentes (de las aplicaciones), sino también para implementación flexible de todos los aspectos funcionales y de comportamiento de la plataforma;

-

un inventario de modelos centralizado (base de datos de modelos -MDB) para la definición, almacenamiento maestro (base de datos maestra) y administración de todas las descripciones de procesos y los modelos de información de recursos de red que han de distribuirse por toda la plataforma para uso dentro de los motores de procesos;

-

una capa de inventario de red distribuida que desacopla la red de las funciones de gestión del OSS y proporciona una base de datos alineada en tiempo real con la red;

-

el uso de técnicas de movilidad de código que permiten una distribución practica de las aplicaciones, incluyendo los aspectos de equilibrio de carga y tolerancia a fallos.

[0011] El artículo de Stephen Corley y col., “Communications Management Process Integration Using Software Agents: A Specification of a Framework for Agent Oriented, Workflow Management Systems” EURESCOM PROJECT P815, enero de 2001, páginas 1 – 92, XP002343307, describe un marco para un sistema de gestión de flujos de trabajo orientado a agentes. La arquitectura de coordinación entre dominios (es decir, dentro de una organización empresarial local) comprende un repositorio de procesos de negocio, un representante de dominio, agentes proveedores de recursos, agentes de usuario personales y agentes proveedores de flujos de trabajo. Los agentes proveedores de flujos de trabajo contienen motores de flujos de trabajo y son responsables del flujo de

trabajo entre dominios. El agente de usuario personal (PUA) proporciona una interfaz inteligente al usuario de un sistema de gestión de flujos de trabajo, y puede ser un PUA GUI o un PUA inteligente. En el primer caso, cuando un usuario solicita una operación de control de flujo de trabajo, la GUI reenvía la solicitud al agente PUA, y el PUA se comunica con el WPA para proceder al cumplimiento. En el segundo caso, el PUA tiene capacidades para detectar cambios en su entorno y actuar sobre los mismos según un plan que define para conseguir algunos objetivos. Este agente tiene capacidades de razonamiento, planificación y aprendizaje. Las acciones están implementadas como procedimientos de objetos Java.

[0012] El documento US 5.826.239 se refiere a un sistema y procedimiento para gestión de recursos distribuidos en una red informática que funciona bajo el control de un sistema de software de gestión de flujos de trabajo para gestionar una pluralidad de recursos para realizar un proceso de flujo de trabajo que incluye múltiples actividades de proceso. Se describe un sistema OpenPM federal para gestión de recursos (véase la Fig. 12), que incluye un software de sistema de gestión de procesos de flujo de trabajo, gestores de recursos, datos de recursos, manejadores de eventos y proxys de recursos.

Objeto y resumen de la invención

[0013] El solicitante ha observado que los procedimientos usados en los sistemas descritos en los dos primeros documentos a los que se ha hecho referencia anteriormente presentan límites en cuanto a las funciones ofrecidas, que tienen su origen en tres deficiencias.

[0014] En primer lugar, no proporcionan una interacción directa con los sistemas/plataformas responsables de la gestión de la red y de los servicios, lo que permitiría una reducción significativa en los tiempos de ejecución de actividades de resolución de problemas aprovechando las ventajas relacionadas, por ejemplo, con la comprobación en tiempo real de la correcta ejecución de las tareas por parte del personal técnico, el suministro proactivo de los datos de red necesarios y la ejecución automática de comandos estándar en la red.

[0015] En segundo lugar, no representan los conocimientos que han de compartirse usando herramientas formales (tales como los flujos de trabajo) que permitirían una reducción en los tiempos de trabajo de los técnicos mediante una descripción inequívoca y fácilmente comprensible de las actividades que han de llevarse a cabo. Tal representación formal también evitaría cualquier posible dificultad de interpretación o cualquier interpretación errónea por parte de los técnicos de las indicaciones suministradas que pueda conducir a la ejecución de actividades

que son inútiles o incluso dañinas para la red en la que están llevándose a cabo.

[0016] Por último, los sistemas en cuestión no guían al personal técnico de una manera completa, integrada y exhaustiva a través de todas las etapas que han de seguirse para realizar las actividades de resolución de problemas: proporcionan sugerencias puntuales de actividades individuales que han de realizarse o de documentos específicos que han de consultarse, obtenidas usando procedimientos tales como el razonamiento conversacional basado en casos. Una guía completa permitirá tanto una reducción en los tiempos de trabajo para los técnicos como una inserción más rápida de técnicos que son nuevos en la tarea.

[0017] Asimismo, en el marco de sistemas/plataformas para la gestión de red/servicios, se dispone de soluciones avanzadas, que prevén arquitecturas distribuidas basadas en agentes.

[0018] En ese sentido, la arquitectura descrita en el tercer documento al que se hizo referencia anteriormente es extremadamente eficaz y eficiente en la gestión de red, pero no prevé que ninguna función KM/OKM dé apoyo a actividades de los empleados de un operador de telecomunicaciones.

[0019] Por consiguiente, surge claramente la necesidad de disponer de soluciones innovadoras que, superando las desventajas inherentes expuestas anteriormente, presenten algunas características funcionales importantes.

[0020] Una primera de estas características es la posibilidad de interacción automática y asistida con los sistemas/plataformas responsables de la gestión de red/servicios, cuyo propósito es permitir:

-

la comprobación en tiempo real, en la red/servicios gestionados, de la correcta ejecución de las sugerencias suministradas, devolviendo una retroalimentación inmediata al usuario del sistema;

-

el suministro automático, sincronizado con las actividades realizadas, de los datos (datos de configuración, datos de medición, etc.) requeridos para proceder con dichas actividades;

-

la ejecución automática de las etapas, consideradas estándar, de la actividad de un operador/ingeniero de campo: por ejemplo, la configuración de una tarjeta de red según parámetros predefinidos para eliminar cualquier posibilidad de error y reducir los tiempos implicados.

[0021] Una segunda característica deseable es que las sugerencias suministradas a los empleados deberían representarse mediante herramientas formales (tales como flujos de trabajo) que tengan las siguientes ventajas:

-

descripción de las actividades que han de realizarse para llevar a cabo satisfactoriamente una intervención dada o encargarse eficazmente de una solicitud de cliente, de una manera inequívoca y fácilmente comprensible;

-

destacar inmediatamente (por ejemplo, mediante resultados apropiados) las mejores prácticas; y

-

permitir una gestión más sencilla de los conocimientos en cuanto a las actividades de mejora y actualización posiblemente soportadas también por mecanismos automáticos.

[0022] Otra característica importante adicional ciertamente deseable es que el sistema debería poder indicar de manera autónoma y completa todas las etapas específicas requeridas para llevar a cabo una intervención dada (ingenieros de campo) o para responder a una solicitud de cliente dada (asesores de un centro de atención telefónica): proporcionan sugerencias puntuales de actividades individuales que han de realizarse o de documentos específicos que han de consultarse, obtenidas utilizando procedimientos tales como el razonamiento conversacional basado en casos.

[0023] Puede indicarse específicamente que las plataformas de gestión actuales, si bien es cierto que están a la vanguardia en lo que se refiere a los aspectos de gestión, no ofrecen herramientas adecuadas para dar soporte a los empleados, a quienes se confía todavía la realización de etapas importantes de los procesos de negocio de una compañía, y no están integradas con sistemas OKM.

[0024] De ahí que se sienta la necesidad de disponer de soluciones capaces de superar estas limitaciones. Específicamente, se siente la necesidad de disponer de una solución completa para apoyar a los empleados que, empezando por avanzadas arquitecturas de gestión flexibles y escalables, introduzca funciones OKM innovadoras, basadas en una representación formal de las prácticas operacionales, y garantice una integración entre el funcionamiento y la gestión de red/servicios.

[0025] Por lo tanto, el objeto de la invención es proporcionar una respuesta completamente satisfactoria a las necesidades anteriores.

[0026] El solicitante ha descubierto que el objeto anterior se consigue proporcionando una arquitectura distribuida de agentes proxy de gestión de intervenciones asociados a dispositivos terminales de operador o de usuario respectivos, estando configurados dichos agentes proxy de gestión de intervenciones para interactuar con agentes proxy de recursos asociados con equipos de red para generar señales de instrucción (en forma de flujos de trabajo) para realizar intervenciones en los equipos de red, por lo que las señales de instrucción son una función del estado de los equipos de red que requieren la intervención.

[0027] La invención también se refiere a un producto de programa informático correspondiente que puede cargarse en la memoria de al menos un ordenador y que incluye partes de código de software para realizar las etapas del procedimiento de la invención cuando el producto se ejecuta en un ordenador. Tal como se usa en este documento, se entiende que la referencia a tal producto de programa informático es equivalente a la referencia a un medio legible por ordenador que contiene instrucciones para controlar un sistema informático con el propósito de coordinar la ejecución del procedimiento según la invención. La referencia a “al menos un ordenador” pretende destacar la posibilidad de que la presente invención se implemente de una manera distribuida y/o modular. Las reivindicaciones forman una parte integrante de la exposición de la invención proporcionada en este documento.

[0028] Una realización preferida de la solución descrita en este documento es, por lo tanto, un procedimiento de generación de señales de instrucción dispuestas en flujos de trabajo para realizar intervenciones en equipos de red incluidos en una red de comunicación en la que dichos equipos de red tienen asociados agentes proxy de recursos, incluyendo el procedimiento las etapas de:

-

proporcionar una arquitectura distribuida de agentes proxy de gestión de intervenciones para gestionar las intervenciones en los equipos de red, estando dichos agentes proxy de gestión de intervenciones asociados a dispositivos terminales,

-

acoplar con dichos agentes proxy de gestión de intervenciones interfaces personales para generar dichas señales de instrucción dispuestas en flujos de trabajo, y

-

generar señales de instrucción para realizar una intervención en al menos un equipo de red de dicha red de comunicación a través de uno de dichos agentes proxy de gestión de intervenciones de una manera interactiva con al menos uno de dichos agentes proxy de recursos asociados con dicho equipo de red, por lo que dichas señales de instrucción son una función del estado de dicho equipo de red.

Breve descripción de la invención

[0029] A continuación se describirá la invención, meramente a modo de ejemplo, con referencia a la lámina de dibujos adjuntos, en los que:

-

La Figura 1 es un diagrama de bloques funcionales que ilustra una posible realización de una plataforma descrita en este documento;

-

La Figura 2 es otro diagrama de bloques funcionales que representa la gestión de operaciones dentro de la plataforma de la Figura 1;

-

La Figura 3 es un organigrama de un primer procedimiento realizado dentro de la solución descrita en este documento;

-

La Figura 4 es un ejemplo de un flujo de trabajo tal como es generado por la solución descrita en este documento; y

-

Las Figuras 5 a 7 son organigramas de procedimientos adicionales realizados dentro de la solución descrita en este documento.

Descripción detallada de realizaciones preferidas de la invención

[0030] Para facilitar una comprensión correcta de los principios subyacentes de la invención, a continuación se presenta un glosario con la explicación de algunos términos/acrónimos usados en esta exposición y en las reivindicaciones adjuntas.

[0031] WFM (gestión de empleados, Work Force Management): en el contexto de un operador de telecomunicaciones, esta es la aplicación de software/conjuntos de aplicaciones de software responsable(s) de gestionar los empleados de dicho operador. En el contexto específico de interés, se entiende que es la aplicación/conjunto de aplicaciones usada(s) para gestionar tanto los empleados móviles (ingenieros de campo) como los empleados de un centro de atención telefónica.

[0032] Operador: este es un miembro del personal de la compañía que forma parte de los empleados, entendidos como empleados móviles (ingenieros de campo), como empleados especializados (personal de servicios internos) y como asesores de un centro de atención telefónica.

[0033] Módulo de gestión -MM: esta es una aplicación software que se ejecuta en un ordenador central que se comunica con los agentes distribuidos para diversas actividades de coordinación, tales como la distribución de descripciones de flujos de trabajo, llamadas de los agentes distribuidos para invocar una operación, controles administrativos, etc.; puede incluir una interfaz gráfica de usuario (GUI, Graphical User Interface) apropiada y especializada.

[0034] Agente: este es un proceso autónomo con un posible estado persistente y que requiere comunicación (por ejemplo, de una manera colaborativa y/o competitiva) con otros agentes para cumplir con sus tareas. Esta comunicación puede implementarse a través de un intercambio de mensajes asíncrono y usando lenguajes bien conocidos (por ejemplo, el lenguaje de comunicación entre agentes, Agent Communication Language, ACL) con una semántica bien definida y comúnmente acordada.

[0035] Proxy: este es un componente (agente) a través del cual es posible controlar o intervenir en otro objeto gestionado, por ejemplo un equipo de red o una GUI en el contexto de apoyo a una operación.

[0036] Motor de reglas: este es un sistema para separar reglas de proceso (de manera lógica y/o física) de la lógica de control y compartirlas a través de memorias de datos, interfaces de usuario y aplicaciones. Un motor de reglas es básicamente un intérprete muy sofisticado de sentencias "si/entonces". Un motor de reglas se usa para

decidir, en tiempo de ejecución, qué reglas aplicar y cómo han de ejecutarse estas.

[0037] Flujo de trabajo: este puede definirse como la automatización parcial o total de un proceso, durante el cual se transmiten documentos, información o tareas desde un participante a otro, según un conjunto de reglas de procedimiento. Un flujo de trabajo puede representarse a través de un organigrama con una secuencia de tareas y dependencias temporales y lógicas, tareas entre las que se incluyen bifurcaciones paralelas o alternativas. Existen lenguajes ad hoc, tales como XPDL (lenguaje de descripción de procesos XML, XML Process Description Language), que permiten una descripción formal de los flujos de trabajo.

[0038] Motor de flujos de trabajo: este es el componente que posee toda la información relacionada con los procedimientos (flujos de trabajo), etapas de un procedimiento y las reglas para cada etapa. El motor de flujos de trabajo determina si el proceso está listo para pasar a la siguiente etapa. En otras palabras, un motor de flujos de trabajo es un componente para ejecutar flujos de trabajo.

[0039] El diagrama de bloques de la Figura 1 representa una realización preferida de una plataforma que es una evolución de la plataforma para la gestión distribuida de una red de telecomunicaciones y los servicios relacionados, descrita en el documento WO-A-2005/018249.

[0040] La arquitectura ilustrada (que define, en sus capas superiores, un sistema de soporte de operaciones (OSS, Operations Support System)) interactúa con tres entidades básicas que comprenden otros sistemas de soporte de operaciones (OSS), sistemas de soporte de negocio (BSS, Business Support Systems) y un sistema de gestión de empleados (WFM, Work Force Management) (o posiblemente más de un WFM). En lo que respecta a los aspectos de gestión, los OSS y los BSS interactúan mediante un bus (BUS, por ejemplo, un bus TIBCO) con la aplicación maestra, designada por MA1. Esta aplicación gestiona la distribución de procesos y modelos de datos relacionados, almacenados en la base de datos de modelos (MDB, Model Data Base), a las diversas aplicaciones agente, una de las cuales se muestra y está designada por AA1, y agentes proxy de recursos RP1, … , RPn. Cada aplicación agente depende de uno o más agentes proxy de recursos RP1, … , RPn que interactúan con una red de comunicaciones N mediante adaptadores de protocolo PA (Protocol Adapters). El inventario de red NI (Network Inventory) corresponde al concepto habitual de un componente de inventario de red y es la recopilación de todas las virtualizaciones (imágenes) del recurso de la red N; se actualiza periódicamente recuperando información de los RP. Los detalles adicionales con respecto a esta solución o arquitectura conocida pueden obtenerse del documento WOA-2005/018249.

[0041] Comparados con la plataforma básica conocida anterior, los nuevos elementos introducidos en la Figura 1 y presentados en mayor detalle en la Figura 2, son un gestor operacional OM (Operational Manager) que interactúa con el bus y coopera con una base de datos de operaciones ODB (Operation Data Base), una base de datos de rendimiento (Performance Data Base), un inventario de destrezas EI (Expertise Inventory) y un archivo de registros de operaciones OL (Operation Log). El gestor operacional OM supervisa el funcionamiento de los agentes operacionales OA1, … , OAk. Cada agente operacional depende de uno o más proxys personales PP1, … , PPn, que interactúan con una pluralidad de equipos virtuales VT1, … , VTn a través de interfaces personales PI. Cada VT está formado, por ejemplo, por ingenieros de campo, personal de servicios internos, asesores de centros de atención telefónica o clientes.

[0042] Los proxys personales - PP1, PP2, … , PPn, cada uno de los cuales está equipado con una interfaz personal PI, están conectados a la capa jerárquica superior de la arquitectura que incluye o bien un conjunto de agentes operacionales OA1, OA2, … , OAk, o bien directamente un gestor operacional OM. En caso de que haya OA presentes, éstos están conectados a su vez a la capa jerárquica superior que incluye el OM. Esta arquitectura en capas garantiza la flexibilidad y la escalabilidad de las funciones, tal como se describe a continuación.

[0043] Los PP también están conectados entre sí, y a los proxys de recursos RP, tal como se indica esquemáticamente por la flecha de dos sentidos PTP en la Figura 1. Esto representa típicamente una relación de igual a igual entre los proxys personales y los proxys de recursos. Esta relación permite la posibilidad de que la arquitectura descrita en este documento genere señales de instrucción mediante los proxys de gestión de intervenciones (es decir, los proxys personales) de una manera interactiva con los proxys de recursos, de manera que estas señales de instrucción dependen del estado del equipo en el que se ejecuta una intervención. Las personas expertas en el sector apreciarán fácilmente que la referencia a la posible presencia de n proxys de recursos RP1 a RPn, de n proxys personales PP1 a PPn y de n equipos virtuales es completa y meramente indicativa, porque puede concebirse que cada una de estas entidades pueda estar presente en cualquier número.

[0044] Cada RP es responsable de la creación, mantenimiento y gestión de la denominada “imagen” de un equipo individual (ubicado en la red o en el local del cliente). La imagen es una representación de la configuración del equipo según un modelo de datos definido.

[0045] Cada agente operacional OA1, … , OAk coordina un conjunto de proxys personales; los agentes operacionales OA1, … , OAk pueden interactuar entre sí, así como con los proxys personales y el gestor operacional OM.

[0046] Cada agente que se ejecuta en un ordenador central (es decir, cada agente para la gestión de red/servicios y cada nuevo agente tal como los proxys personales, los agentes operacionales y el gestor operacional) incluye preferentemente uno o más agentes de control CA, que son los módulos de software responsables de controlar y gestionar la plataforma.

[0047] Como se ha visto, la plataforma también comprende un conjunto de bases de datos (DB, data bases) que dan soporte a las actividades realizadas por los diversos componentes. La base de datos operacionales ODB (operational data base) es el único punto (lógico) de definición y almacenamiento de todos los aspectos funcionales y los aspectos de gestión/apoyo de los empleados y clientes, relacionados con la plataforma. La ODB es el repositorio de las descripciones de procesos (en la que una descripción de proceso es un flujo de trabajo o una regla) y de las definiciones de modelos de datos que son usadas por los componentes de la plataforma para gestionar el funcionamiento (PP, OA y OM).

[0048] Un módulo de gestión MM (Manager Module), mediante los agentes de control CA (Control Agents), distribuye las definiciones de procesos y las definiciones de modelos de datos a los componentes de gestión de operaciones. En primer lugar, esto permite poner a disposición de todos los empleados y de los clientes las prácticas operacionales más eficaces y efectivas (la mejor práctica). Además, a través de una difusión de las definiciones de modelos de datos, se permite la coordinación entre los empleados, permitiendo así una identificación sencilla y rápida de los expertos a los que se recurrirá para obtener apoyo sobre un asunto específico. Asociada con la base de datos ODB hay una GUI proporcionada intencionadamente que permitirá su población.

[0049] La base de datos de modelos MDB almacena todas las descripciones de procesos (flujos de trabajo y reglas) y los modelos de los datos procesados (incluyendo los modelos de los equipos de red) que son usados por los componentes de la plataforma para la gestión de red/servicios (RP, AA y MA, tal como se muestra en la Figura 1).

[0050] Este elemento proporciona a los usuarios un único punto en el que definir y administrar las funciones de la plataforma en cuanto a los aspectos de gestión de red/servicios.

[0051] En una realización preferida, para definir los modelos de datos almacenados en las bases de datos ODB y MDB, se usa el modelo SID (modelo de datos de información compartida, conjunto de documentos del TeleManagementForum GB922, versión 4.0, agosto de 2004 y versión 4.5 en evaluación de miembros, diciembre de 2004).

[0052] La base de datos de rendimiento PDB (Performance Data Base) es un único punto (lógico) de almacenamiento de todos los datos de rendimiento relacionados con los componentes de plataforma y se usa tanto para optimizar la utilización de recursos como para identificar la mejor práctica.

[0053] Por último, en la plataforma también están presentes: el registro operacional (OL), el cual es un único punto (lógico) de almacenamiento de todos los registros de las actividades realizadas por los operadores y por los clientes; y el inventario de destrezas EI, el cual contiene los datos de los perfiles de operador y de los perfiles de cliente gestionados por los diversos PP.

[0054] Los procesos operacionales de la plataforma están segmentados en tres capas con funciones específicas. Esta opción está pensada para satisfacer dos necesidades: mantener el número de capas tan bajo como sea posible (evitando de este modo la complejidad de las arquitecturas convencionales), y permitir la libre asignación de procesos entre una modalidad distribuida y una centralizada. Esto implica la presencia de una capa 1 centralizada (que corresponde al gestor operacional OM) y de una capa 2 totalmente distribuida (que corresponde a los agentes operacionales OA1, … , OAk) más una capa 3 de proxys independientes (que corresponde a los proxys personales PP) que desacopla el funcionamiento con respecto a las funciones de gestión y de control. Esta segmentación también proporciona diferentes vistas de servicio, por ejemplo una vista de producto para el cliente final en la capa 1, una vista de servicio en la capa 2 y una vista operacional en la capa 3. Tal como se explicará posteriormente, los componentes PP, OA y OM están adaptados para realizar funciones respectivas basadas en la información de instrucción respectiva proporcionada a los mismos, información que comprende definiciones de procesos, tales como flujos de trabajo o reglas, o definiciones de modelos de datos.

[0055] Cada proxy personal PP (en lo sucesivo, por motivos de brevedad, evitaremos repetir cada vez la secuencia de sufijos 1 a N, por ejemplo, en PP1, … , PPn, y se adoptará un enfoque similar también con referencia a otras entidades presentes de forma múltiple en los diagramas de las Figuras 1 y 2) es responsable de apoyar las actividades de un operador específico o de un cliente específico, tanto en cuanto a guía en las diversas actividades operacionales como a apoyo a la cooperación (entre diferentes operadores o entre operadores y clientes). En particular, el apoyo a la cooperación se basa en los perfiles de operador y en los perfiles de cliente, estando representados estos perfiles en el modelo de datos. La instanciación de los perfiles con los datos reales y actualizados se lleva a cabo por el gestor operacional OM con la información procedente de sistemas WFM externos, en caso de perfiles de operador, o de sistemas de soporte de negocio, en caso de perfiles de cliente, y se comunica al proxy personal.

[0056] En otras palabras, cada proxy personal representa el papel de un agente proxy de gestión de intervenciones. Cada proxy personal (PP) ejecuta procesos típicos del nivel PP correspondiente usando un motor de procesos PE: estos procesos se denominan como procesos de capa 3 y pueden estructurarse en subcapas (por ejemplo, para la definición de macrooperaciones). Los procesos de la capa superior de la capa 3 constituyen los servicios que el PP ofrece a la capa superior (el agente operacional, y posiblemente otras aplicaciones externas) mediante la invocación de dichos procesos. Representan las operaciones que corresponden a una única actividad realizada por el operador/cliente al que está asociado el PP. De ahí el término, ya introducido anteriormente, de agente proxy de “gestión de intervenciones”. Ejemplos de servicios (y, por tanto, de intervenciones) proporcionados por un proxy personal son: realizar una interconexión, instalar y configurar un módem, reparar un fallo de un equipo (enrutador, DSLAM, etc.), etc.; cada uno de estos puede incluir secuencias de actividades que han de realizarse en uno o más equipos. Los procesos de la capa inferior de la capa 3 usan los servicios ofrecidos por las interfaces personales PI.

[0057] Los perfiles de operador y los perfiles de cliente gestionados por un proxy personal PP están representados en el modelo de datos. Este modelo, definido por medio de una GUI proporcionada intencionadamente, está almacenado en la base de datos ODB y se distribuye mediante el módulo de gestión MM, a través de los agentes de control CA, a los proxys personales PP, que lo cargan y lo instancian con los valores enviados por el gestor operacional OM y adquiridos por sistemas externos (WFM y BSS). De nuevo, la instanciación se realiza de una manera flexible usando un motor de proxy PE (Proxy Engine). De esta manera, los cambios y añadidos de modelos de datos (como la actualización del perfil de operador/cliente, la introducción de nuevas clases de operador, etc.) no requieren ningún cambio de software apreciable en los componentes de la plataforma, consiguiendo un alto grado de flexibilidad.

[0058] Los datos de los perfiles de operador y de los perfiles de cliente se almacenan en el inventario de destrezas EI, el cual es actualizado periódicamente por el OM usando información adquirida desde sistemas externos (sistemas WFM para el perfil de operador y sistemas de soporte de negocio para el perfil de cliente). Tal como se dijo anteriormente, los cambios en los datos de perfil también se comunican a los proxys personales PP pertinentes.

[0059] Por lo tanto, los operadores pueden agruparse de manera lógica en equipos virtuales VT1, … , VTn: un equipo virtual incluye un conjunto de operadores que comparten unos conocimientos dados y/o que trabajan en problemas comunes. Los equipos virtuales pueden, en general, organizarse en función de una subdivisión geográfica de los empleados para mejorar la eficacia de la resolución de problemas y optimizar las intervenciones in situ.

[0060] Los proxys personales PP pueden interactuar directamente entre sí para dar apoyar a la cooperación entre operadores o entre operadores y clientes, por ejemplo, para reparar un fallo complicado. Los proxys personales PP también están en comunicación con los proxys de recursos RP asociados a los diferentes recursos de red; por lo tanto, los PP pueden interactuar con los RP para enviar comandos, recopilar datos de configuración, resultados de mediciones o resultados de comprobaciones de ejecución satisfactoria, en el equipo, de algunas acciones dadas por parte del operador/cliente, y ofrecer un acceso remoto a posibles interfaces de línea de comandos. En cambio, las interfaces personales PI son responsables de la gestión de la GUI para con todos los operadores (empleados) o clientes, cualquiera que sea el tipo de dispositivo terminal que usen para apoyar a sus actividades de trabajo (PDA, ordenadores portátiles, de escritorio, etc.). Cada PI ofrece, como servicios para los proxys personales, la gestión de la GUI para con el operador/cliente, incluyendo la configuración automática de la GUI basándose en el tipo de dispositivo disponible.

[0061] Cada agente operacional OA es responsable de la coordinación de un conjunto de PP y la ejecución de procesos típicos de la capa 2 usando un motor de proxy. Estos procesos están relacionados con la ejecución distribuida de intervenciones operacionales y pueden estructurarse en subcapas. Los procesos de la capa superior de la capa 2 pueden invocarse externamente; por lo tanto, estos son los servicios ofrecidos por el agente operacional OA al gestor operacional OM u otros sistemas externos. Los procesos de la capa inferior de la capa 2 usan los servicios (es decir, invocan procesos) ofrecidos por el proxy personal PP.

[0062] Un agente operacional OA no requiere actualización de software para dar soporte a nuevas prácticas operacionales. Esto se debe a la flexibilidad de los procesos que se reciben desde el módulo de gestión MM, a través del CA, cargados y ejecutados por la capa OA. Los agentes operacionales OA pueden interactuar mediante un protocolo de comunidad (un mecanismo de interfuncionamiento basado en el intercambio de mensajes) para dar soporte a la ejecución distribuida de actividades operacionales correlacionadas entre sí como, por ejemplo, la creación de un circuito que implique equipos situados en emplazamientos distribuidos geográficamente.

[0063] El gestor operacional OM es responsable de la coordinación de primer nivel de la ejecución de los procesos típicos de un nivel de gestión. Los procesos de la capa 1 pueden estructurarse en subcapas y están caracterizados para proporcionar funciones que requieren interacción con entidades externas a la plataforma (por ejemplo, sistemas WFM o sistemas de soporte de negocio) y/o coordinación entre los agentes operacionales OA, que no pueden conseguirse de una manera fácil o eficaz solamente mediante los agentes operacionales OA. La gran flexibilidad de la arquitectura también permite una evolución uniforme; por ejemplo, una mejora del protocolo de comunidad puede permitir la migración de un proceso desde la capa 1 hasta la capa 2.

[0064] Los motores de procesos PE para cualquier capa están pensados para que sean un motor de flujos de trabajo (es decir, un organigrama), un motor de reglas o una combinación de los dos. Por ejemplo, funciones de soporte relacionadas con una intervención in situ de un operador se representan mejor como un organigrama, mientras que las funciones de apoyo a diagnósticos basándose en reclamaciones, en el contexto de un centro de atención telefónica, se representan mejor mediante un conjunto de reglas. Siempre que sea posible y aconsejable, se prefiere el uso de flujos de trabajo ya que evita la complejidad de tratar conflictos de reglas y la gestión de reglas.

[0065] Los motores de procesos son usados preferentemente por cada componente de la plataforma y, si es posible, han de asignarse al mismo ordenador central en el que reside el propio componente para mejorar los niveles de rendimiento: el gestor operacional OM, los agentes operacionales OA y los proxys personales PP presentan un comportamiento que es tanto reactivo como proactivo, reaccionando ante eventos pero también iniciando procesos espontáneamente.

[0066] Los agentes de control CA son responsables de la distribución de los flujos de trabajo y de los modelos de datos en los diversos agentes de la plataforma, de la medición del uso de los recursos y del rendimiento de los agentes locales (es decir, los que se ejecutan en el ordenador central) y, por último, de la optimización local de la gestión de recursos. Las mediciones se envían al módulo de gestión MM y a otros agentes de control CA.

[0067] La movilidad entre ordenadores centrales, gestionada por el módulo de gestión MM o por un agente de control CA de los agentes operacionales OA y de los proxys personales PP hace que los procedimientos de implantación, equilibrio de carga y tolerancia a fallos sean más eficaces y automáticos. Si por cualquier razón un agente “desciende”, la solución puede ser clonar o llevar el agente a otro ordenador central en ejecución. El módulo de gestión MM, a través del agente de control CA, controla periódicamente el estado operacional de los agentes operacionales OA y de los proxys personales PP para dichos fines. Para supervisar el rendimiento, los componentes de la plataforma también deben poder supervisar la ejecución de los diversos procesos. En el caso del proxy personal PP, la supervisión de la ejecución de los diversos procesos también es útil en una perspectiva de identificación de la mejor práctica.

[0068] Tal como ya se ha dicho, la solución descrita en este documento está pensada para gestionar y dar soporte a las operaciones de los empleados y del cliente. Esto se obtiene a través de un conjunto de servicios a disposición de los operadores/clientes.

[0069] Con referencia al marco eTOM (documentos: TeleManagementForum GB921 y GB921D, versión 4.0, de marzo de 2004, y versión 5.0 en evaluación de miembros, de abril de 2005), una primera realización de la solución descrita en la presente invención proporciona soporte a los operadores y clientes que llevan a cabo actividades relacionadas con las siguientes agrupaciones de procesos de extremo a extremo verticales de nivel 1:

-

gestión del ciclo de vida de la infraestructura (área de procesos: estrategia, infraestructura y producto);

-

soporte y disponibilidad de operaciones (área de procesos: operaciones);

-

cumplimiento (área de procesos: operaciones);

-

garantía (área de procesos: operaciones).

[0070] Considerando ahora la dimensión horizontal del marco eTOM, las agrupaciones de procesos funcionales horizontales de nivel 1 en los que están las actividades de los operadores y los clientes son:

-

desarrollo y gestión de recursos: (área de procesos: estrategia, infraestructura y producto);

-

gestión de relación con el cliente (área de procesos: operaciones);

-

gestión y operaciones de servicios (área de procesos: operaciones); y

-

gestión y operaciones de recursos (áreas de procesos: operaciones).

[0071] La gestión y compartición de los conocimientos operacional con expertos y clientes puede estar, a su vez, en el área de procesos gestión de empresa y, en particular, en la agrupación de procesos de nivel 1 conocida como gestión de conocimientos y de investigación.

[0072] El organigrama de la Figura 3 muestra, a modo de ejemplo, un procedimiento para apoyar a ingenieros de campo.

[0073] En primer lugar, la plataforma descrita anteriormente guía al operador, al que se le confía la realización de una actividad dada, mostrándole las actividades puntuales que han de realizarse; los modos operacionales con los que la plataforma ofrece dicho servicio con referencia a ingenieros de campo se presentan en la Figura 3 y se describen a continuación.

[0074] Posteriormente a la selección por parte del ingeniero de campo de la intervención que ha de llevarse a cabo (etapa 100), el proxy personal asociado a él muestra (etapa 110) en el dispositivo terminal del ingeniero de campo, usando la interfaz PI correspondiente, señales de instrucción organizadas como flujos de trabajo destinados a reparar un fallo o a ejecutar una orden de trabajo relacionada, por ejemplo, con actividades de suministro o funcionamiento (como actualizaciones de bases de datos, etc.). En el dispositivo del ingeniero de campo se muestra una selección específica de flujos de trabajo, que le guían en la ejecución de la intervención según prácticas que son alternativas entre sí. Los flujos de trabajo individuales contienen toda la información necesaria para que el ingeniero de campo realice la intervención específica, incluyendo posibles datos específicos respecto a la propia intervención, como los requeridos para identificar el componente de un equipo sobre el que actuar: por ejemplo, si una etapa de un flujo de trabajo guía al ingeniero de campo en la actividad de cambiar una tarjeta de un equipo, dicha etapa también contiene la indicación que permite al ingeniero de campo identificar de una manera fácil y única la tarjeta que ha de cambiarse. Cada flujo de trabajo se presenta indicando también el resultado que se ha asignado al mismo y que refleja una evaluación establecida de la eficacia y eficiencia del propio flujo de trabajo para conseguir de la mejor manera el objetivo de la intervención. Dicho resultado también determina el orden de presentación de los flujos de trabajo (enumerados desde el que tiene el resultado más alto).

[0075] Antes de decidir si seleccionar uno de los flujos de trabajo indicados, el ingeniero de campo puede solicitar al proxy personal PP que recopile datos de medición o que proporcione información sobre la configuración del equipo. La solicitud conlleva un intercambio de información entre el proxy personal PP y el proxy de recursos RP, con la solicitud del ingeniero de campo reenviada desde el proxy personal PP hasta el proxy de recursos RP y la respuesta correspondiente, enviada por el proxy de recursos RP al proxy personal PP, presentada al ingeniero de campo a través de la interfaz PI (toda la actividad corresponde a la etapa 120).

[0076] Además, el ingeniero de campo también puede solicitar que se muestren uno o más de los flujos de trabajo propuestos (etapa 130) para tener más información antes de decidir cómo proceder. El ingeniero de campo puede entonces decidir (etapa 140) seleccionar uno o ninguno de los flujos de trabajo presentados; en caso de selección, se activa en el PP el flujo de trabajo elegido (etapa 150).

[0077] Posteriormente a la activación de un flujo de trabajo, se inicia un proceso de registro de todas las actividades realizadas por el ingeniero de campo (etapa 160). La información recopilada se almacena en el registro operacional OL y puede procesarse después para refinar los flujos de trabajo existentes o con el fin de generar y validar nuevos flujos de trabajo.

[0078] En paralelo a la activación del flujo de trabajo en el proxy personal PP existe la activación, en el proxy de recursos RP que gestiona el equipo sobre el que debe actuar el ingeniero de campo, de un flujo de trabajo cooperativo que coopera con el del proxy personal (etapa 170). Es el flujo de trabajo en el propio proxy personal PP el que, como primera etapa, activa un flujo de trabajo 'cooperativo' específico en el proxy de recursos RP. Los dos flujos de trabajo se ejecutan de manera independiente, excepto para la coordinación en algunos puntos en los que pueden usar mecanismos de espera mutua para intercambiar resultados de procesamiento. A continuación se ofrecen algunos ejemplos de intercambios de información.

[0079] Luego puede haber intercambios de información (etapa 180) entre proxys personales PP y proxys de recursos RP para enviar, desde los proxys de recursos RP a los proxys personales PP:

-

posibles datos sobre la configuración del equipo, o resultados de mediciones en el equipo, en el que el ingeniero de campo está interviniendo, que se requieren para ejecutar las etapas posteriores del flujo de trabajo. Estos datos se envían automáticamente, sin ninguna solicitud por parte del ingeniero de campo, ya que el proxy de recursos RP está sincronizado con las actividades que están realizándose y conoce tanto los tiempos implicados como el tipo de información requerida;

-

la indicación de que se han llevado a cabo realmente las actividades de configuración realizadas de manera autónoma por el proxy de recursos RP en puntos apropiados del flujo de trabajo;

-

los resultados de la comprobación, realizada de manera autónoma por el proxy de recursos RP, de la ejecución satisfactoria de la intervención por parte del ingeniero de campo (en caso de fallo, comprobación de su reparación, en caso de orden de trabajo de suministro, comprobación de la correcta ejecución de las actividades de configuración solicitadas).

[0080] Después de la recepción por parte del ingeniero de campo a través del proxy personal PP de la indicación, procedente del RP, de la conclusión satisfactoria de la intervención (etapa 190), la intervención se considera cerrada (etapa 200), y el ingeniero de campo puede seleccionar una intervención posterior.

[0081] En caso de que un ingeniero de campo decida no seleccionar ninguno de los flujos de trabajo propuestos para él, o si no existe ningún flujo de trabajo asociado a la intervención que ha de realizarse, el ingeniero de campo puede solicitar en cualquier caso, a través del proxy personal PP que, a su vez, interactúa con el proxy de recursos apropiado RP, información, mediciones o ejecución de comandos en el equipo sobre el que debe actuar, proporcionando también un acceso remoto a la interfaz de línea de comunicación (CLI, Communication Line Interface) del equipo. Esto se hace como apoyo para la ejecución de la intervención (etapa 220) y/o como comprobación de la correcta ejecución de la misma (etapa 230), antes de cerrar la intervención (etapa 200). Además, todas las actividades realizadas por el ingeniero de campo son registradas (etapa 210), y la información recopilada se almacena en el registro operacional y puede procesarse posteriormente con el fin de generar y validar nuevos flujos de trabajo o para refinar los flujos de trabajo existentes.

[0082] El técnico que haya elegido seguir las etapas indicadas por un flujo de trabajo específico puede interrumpir en cualquier punto la ejecución del propio flujo de trabajo y continuar sin ser guiado, interactuando con el equipo (mediante la cadena entre proxys personales PP y proxys de recursos RP) para obtener información y/o para llevar a cabo acciones en el propio equipo.

[0083] Por ejemplo, la Figura 4 presenta un ejemplo de flujo de trabajo cooperativo para la sustitución de una tarjeta de un equipo. En particular, la Figura 4 en cuestión presenta un ejemplo de flujo de trabajo cooperativo con el objetivo de guiar al ingeniero de campo en una actividad de sustitución de una tarjeta en un equipo.

[0084] El ingeniero de campo, posteriormente a la elección del flujo de trabajo que ha de activarse según los criterios descritos previamente, requiere la activación, mediante la interfaz PI, del flujo de trabajo seleccionado en el proxy personal PP (etapa 1100).

[0085] El flujo de trabajo en el extremo de proxy personal PP comienza (etapa 300) y, como primera acción, comienza el flujo de trabajo cooperativo relacionado en el proxy de recursos RP (etapas 310 y 500). Al ingeniero de campo se le envía un mensaje en la interfaz PI para que espere la activación del flujo de trabajo RP (etapa 1110).

[0086] El flujo de trabajo de proxy personal PP procede con las actividades preliminares a la sustitución de la tarjeta, indicando al ingeniero de campo las instrucciones para abrir el equipo (etapa 320) mediante la descripción en la interfaz PI de las operaciones manuales que han de realizarse (etapa 1120) y las indicaciones para identificar la tarjeta dentro del equipo (etapa 330), una vez más mediante visualización en la interfaz PI (etapa 1130), también mediante la ayuda de esquemas que facilitan la identificación de la tarjeta.

[0087] Al mismo tiempo, el flujo de trabajo del proxy de recursos RP procede con las actividades de gestión preliminares a la sustitución de la tarjeta (etapa 510) como, por ejemplo, la desactivación o cambio de servicios todavía activos en la misma o poner la tarjeta en un estado no operativo. Cuando se han realizado dichas actividades, el flujo de trabajo de proxy de recursos RP notifica al flujo de trabajo de proxy personal PP que puede continuar (etapa 520).

[0088] El flujo de trabajo de proxy personal PP informa al ingeniero de campo que desconecte el cableado de la tarjeta que está siendo sustituida (etapa 340), presentando información útil para la actividad manual en la interfaz PI (etapa 1140), mientras que informa al flujo de trabajo de proxy de recursos RP que continúe con la siguiente etapa de supervisión de la actividad (etapa 530) como, por ejemplo, comprobar si los puertos físicos implicados señalan el estado de cableado desconectado. Cuando todo el cableado de la tarjeta que ha de ser sustituida ha sido desconectado, el flujo de trabajo de proxy de recursos RP informa al flujo de trabajo PP (etapa 530).

[0089] El flujo de trabajo de proxy personal PP procede con la comprobación de si la tarjeta está lista para su extracción del equipo (etapa 350), haciendo avanzar el flujo de trabajo de proxy de recursos RP hasta la actividad de liberación de la tarjeta (etapa 540) e indicando al ingeniero de campo que verifique la señal de tarjeta liberada (etapa 1150).

[0090] Cuando el flujo de trabajo de proxy de recursos RP completa las actividades de liberación de la tarjeta como, por ejemplo, desconectar la tarjeta, informa al flujo de trabajo de proxy personal PP (etapa 540), que procede con la acción de la extracción física real de la tarjeta (etapa 360), indicando al ingeniero de campo las actividades manuales que han de realizarse (etapa 1160), como las palancas de desenganche que han de activarse e indicaciones de las prácticas para extraer la tarjeta.

[0091] El flujo de trabajo de proxy de recursos RP supervisa la actividad manual, comprobando el estado y las señales que provienen del equipo (etapa 550) como, por ejemplo, el estado de ranura libre, e informa al flujo de trabajo de proxy personal PP cuando la tarjeta ya no está presente.

[0092] El flujo de trabajo de proxy personal PP, habiendo recibido los mensajes de finalización de las actividades tanto del flujo de trabajo de proxy personal PP como del ingeniero de campo a través de la interfaz PI, procede con la acción de inserción de la nueva tarjeta (etapa 370), enviando la información necesaria a la interfaz PI(etapa 1170) e informando al flujo de trabajo de proxy de recursos RP. Éste supervisa la inserción de la nueva tarjeta (etapa 560), por ejemplo, comprobando si la ranura ha pasado del estado libre al estado ocupado, hasta la notificación al flujo de trabajo de proxy personal PP de la correcta inserción de la nueva tarjeta (etapa 570).

[0093] El flujo de trabajo de proxy de recursos RP procede con las comprobaciones y la configuración de la nueva tarjeta (etapa 580), mientras que el flujo de trabajo de proxy personal PP espera la finalización de la última actividad (etapa 380) e informa al ingeniero de campo, a través de la interfaz PI, sobre la comprobación en curso (etapa 1180).

[0094] Al final de la configuración de la nueva tarjeta, el flujo de trabajo de proxy de recursos RP informa al flujo de trabajo de proxy personal PP (etapa 580) para que proceda con la conexión del cableado (etapa 390), mediante la presentación al ingeniero de campo en la interfaz PI, de las actividades manuales que han de realizarse (etapa 1190) con la ayuda de esquemas respecto al tipo de tarjeta y cableado.

[0095] Durante la conexión del cableado, el flujo de trabajo de proxy de recursos RP supervisa los puertos de la tarjeta (etapa 590), por ejemplo controlando el estado de los puertos que indica que el cableado está conectado. Solamente cuando se haya vuelto a conectar todo el cableado previsto, el flujo de trabajo de proxy de recursos RP informa al flujo de trabajo de proxy personal PP (etapa 590) y procede con la comprobación y configuración de los puertos (etapa 600) como, por ejemplo, la reactivación de los servicios o su transición desde la configuración temporal ejecutada previamente (etapa 510).

[0096] El flujo de trabajo de proxy personal PP espera la finalización de las configuraciones de los puertos de la nueva tarjeta (etapa 400) e informa al ingeniero de campo a través de la interfaz PI (etapa 1200) de que dicha actividad está en curso. Una vez que está terminada la configuración de los puertos (etapa 600), el flujo de trabajo de proxy de recursos RP informa al flujo de trabajo de proxy personal PP y finaliza (etapa 610), mientras que el flujo de trabajo de proxy personal PP guía al ingeniero de campo para llevar a cabo el cierre de la carcasa del equipo (etapa 410) proporcionando información apropiada en la interfaz PI (etapa 1210).

[0097] Finalmente, el flujo de trabajo de proxy personal PP completa su ejecución (etapa 420), informando al ingeniero de campo que está esperando el fin de los flujos de trabajo (etapa 1220) y esperando la finalización del flujo de trabajo de proxy de recursos RP. Los flujos de trabajo terminan, sincronizándose en la última acción del flujo de trabajo PP (etapa 430), con información al ingeniero de campo de una intervención concluida satisfactoriamente (etapa 1230).

[0098] En cambio, la Figura 5 ilustra un ejemplo de procedimiento para apoyar a asesores de un centro de atención telefónica: de hecho, la solución aquí descrita también permite la aplicación del servicio de guiado a asesores de un centro de atención telefónica.

[0099] Después de la recepción, por parte del asesor del centro de atención telefónica, de la reclamación de un cliente (denominada en lo sucesivo como información de problema: TR (Trouble Report)) o de una solicitud de un nuevo servicio (denominada en lo sucesivo como orden de cliente: CO (Customer Order)) (etapa 1300), el proxy personal PP asociado al asesor del centro de atención telefónica abre una sesión con el (los) proxy(s) de recursos RP asociado(s) a los equipos de red de interés para la solicitud del cliente y recopila información requerida para su interacción con el cliente (en caso de un informe de problema, se comprueba si hay fallos en los equipos implicados en la oferta de servicios de cliente) (etapa 1310).

[0100] Después de la recopilación de los datos de la red, si el proxy personal PP no requiere ninguna información adicional (comprobación realizada en la etapa 1320) y está ocupándose de la reclamación de un cliente (comprobación realizada en la etapa 1330), los datos recopilados son procesados para llevar a cabo un primer diagnóstico (etapa 1380). En cambio, si el proxy personal PP no requiere información adicional (comprobación realizada en la etapa 1320) y está ocupándose de una solicitud de un nuevo servicio (comprobación realizada en la etapa 1330), la siguiente etapa es la creación de una orden de trabajo (WO, Work Order) (etapa 1420).

[0101] Después de la recopilación de los datos de la red, si el proxy personal PP requiere información adicional (comprobación realizada en la etapa 1320), muestra en el dispositivo del asesor del centro de atención telefónica (etapa 1340), usando la interfaz PI correspondiente, una secuencia de preguntas destinadas a adquirir detalles adicionales sobre la TR/OC del cliente. En caso de un informe de problema, dichas preguntas también pueden ser solicitudes para que el cliente realice comprobaciones/acciones puntuales, que pueden conducir a resolver el problema que es la causa del informe de problema, por ejemplo, solicitudes para verificar si todo el cableado de un equipo del local del cliente (CPE, Customer Premise Equipment) está conectado correctamente y proceder a corregir la conexión del cableado en el que se detectan fallos de conexión.

[0102] El asesor del centro de atención telefónica, interactuando con el cliente, suministra al proxy personal PP las respuestas apropiadas a las preguntas que le hacen (etapa 1350). En caso de que el cliente no pueda proporcionar los datos solicitados o para integrar los datos proporcionados por él, el asesor del centro de atención telefónica puede pedir al proxy personal PP que recopile datos de medición o que le suministre la información de configuración relacionada con la parte de red de interés para el cliente específico. Esto implica un intercambio de información entre los proxys personales PP y los proxys de recursos RP que controlan dicha parte de red, con la solicitud del asesor del centro de atención telefónica reenviada por el proxy personal PP al proxy de recursos RP y las respuestas correspondientes enviadas por el proxy de recursos RP al proxy personal PP y mostradas por éste al operador a través de la interfaz PI (toda la actividad corresponde a la etapa 1360).

[0103] Al final de la secuencia de preguntas o, en caso de un informe de problema, posteriormente a la solución del propio informe de problema basada en una comprobación/acción del cliente (comprobación realizada en la etapa 1370), la siguiente etapa es la etapa 1420.

[0104] En caso de un informe de problema (comprobación realizada en la etapa 1370) por parte del cliente, al final de la etapa de recopilación guiada de los datos (del cliente y/o de la red), el proxy personal PP, usando un sistema basado en reglas, formula una primera hipótesis sobre la causa principal del informe de problema (etapa 1380).

[0105] Si el fallo puede ser reparado por el cliente (comprobación realizada en la etapa 1390), el proxy personal PP del asesor del centro de atención telefónica abre una sesión con el proxy personal PP del cliente, pidiéndole que ejecute un flujo de trabajo específico para solucionar el informe de problema (etapa 1400). El asesor del centro de atención telefónica puede entonces pasar a la ejecución de otras actividades, siendo informado al mismo tiempo sobre el resultado de la ejecución del flujo de trabajo por parte el cliente.

[0106] Al recibir el resultado del flujo de trabajo (etapa 1410), se crea un resguardo de problema (TT, Trouble Ticket) apropiado que tendrá en cuenta el resultado del flujo de trabajo (si el flujo de trabajo se ha ejecutado satisfactoriamente, el TT registrará la solución del informe de problema; de lo contrario, contendrá información útil para crear una o más solicitudes de trabajo WR (Work Request) para los ingenieros de campo).

[0107] Si el fallo no puede ser solucionado por el cliente (comprobación realizada en la etapa 1390), la siguiente etapa es la creación de un resguardo de problema (etapa 1420). Después de la recopilación de los datos del informe de problema/orden de cliente y, en caso de un informe de problema, posteriormente al diagnóstico de primer nivel y/o de la solución del informe de problema, el proxy personal PP proporciona al asesor del centro de atención telefónica todos los datos requeridos para crear un resguardo de problema o una orden de trabajo que, en caso de una solicitud de cliente no satisfecha todavía, producirá una o más solicitudes de trabajo WR para los ingenieros de campo (etapa 1420). Posteriormente a la creación de la TT/WO, la actividad del asesor del centro de atención telefónica finaliza (etapa 1430).

[0108] En cambio, el organigrama de la Figura 6 se refiere a un procedimiento para apoyar a los clientes; el apoyo para la ejecución de actividades operacionales descritas en este documento también se aplica al cliente.

[0109] Después de la detección, por parte de un cliente, de alguna avería (etapa 700), el propio cliente activa en su dispositivo (normalmente un PC o un PDA) el proxy personal PP asociado a él (etapa 710).

[0110] El proxy personal PP abre una sesión con el (los) proxy(s) de recursos RP asociado(s) con los equipos ubicados en las locales del cliente para identificar cualquier posible fallo en dichos equipos (etapa 720). En caso de que no haya fallos en los equipos en los locales del cliente (comprobación realizada en la etapa 730), el proxy personal PP muestra en el dispositivo del cliente (etapa 740), usando la interfaz PI correspondiente, una secuencia de preguntas destinadas a adquirir más detalles sobre la avería detectada. El cliente proporciona al proxy personal PP las respuestas apropiadas a las preguntas que se le hacen (etapa 750).

[0111] Al final de la secuencia de preguntas, el proxy personal PP comprueba si se ha identificado la causa de la avería y si dicha causa puede ser eliminada por el cliente (comprobación realizada en la etapa 760) y, si es así, activa un flujo de trabajo apropiado (etapa 770) que guía al cliente en la resolución del problema. El proxy personal PP también activa un proceso de registro de las actividades del cliente (etapa 780): la información recopilada se almacena en el registro operacional y puede procesarse posteriormente para refinar los flujos de trabajo existentes o para generar y validar nuevos flujos de trabajo.

[0112] Al final del flujo de trabajo se realiza una comprobación, por parte del cliente, acerca de la eliminación de la avería (etapa 790); si dicha comprobación tiene un resultado positivo, la actividad del cliente termina (etapa 810). En cambio, si la comprobación tiene un resultado negativo, el proxy personal PP informa al cliente que se ponga en contacto con el centro de atención telefónica (etapa 800); posteriormente a la notificación por parte del proxy personal PP, la actividad del cliente termina (etapa 810). Si la causa de la avería no se ha identificado o si no puede ser eliminada por el cliente (comprobación realizada por la etapa 760), el proxy personal PP informa al cliente que se ponga en contacto con el centro de atención telefónica (etapa 800). Después de dicha notificación por parte del proxy personal PP, la actividad del cliente termina (etapa 810).

[0113] En caso de que haya fallos en equipos en los locales del cliente (comprobación realizada en la etapa 730), el proxy personal PP lleva a cabo una comprobación adicional para verificar si dichos fallos pueden ser reparados por el cliente (comprobación realizada en la etapa 820) y, en caso de un resultado positivo, activa un flujo de trabajo apropiado (etapa 770), que guía al cliente en la resolución del problema.

[0114] El proxy personal PP también activa un proceso de registro de las actividades del cliente (etapa 780): la información recopilada se almacena en el registro operacional y, como ya se mencionó, puede procesarse para refinar los flujos de trabajo existentes o para generar y validar nuevos flujos de trabajo. Al final del flujo de trabajo se realiza una comprobación por parte del cliente, sobre la eliminación de la avería (etapa 790); si dicha comprobación tiene un resultado positivo, la actividad del cliente finaliza (etapa 810). En cambio, si la comprobación tiene un resultado negativo, el proxy personal PP informa al cliente que se ponga en contacto con el centro de atención telefónica (etapa 800); posteriormente a la notificación por parte del proxy personal PP, la actividad de cliente termina (etapa 810).

[0115] Los flujos de trabajo ejecutados en el proxy personal PP del cliente normalmente prevén que también se informe al cliente sobre posibles acciones llevadas a cabo automáticamente por los proxys de recursos RP y que pueda conceder un consentimiento explícito a su ejecución.

[0116] El organigrama de la Figura 7 ilustra un procedimiento para cooperación entre operadores. De hecho, la plataforma aquí descrita proporciona un servicio adicional para apoyar al operador, al que se le confía la realización de una actividad dada (por ejemplo una intervención in situ o el tratamiento de una solicitud de cliente), gestionando las interacciones con otros posibles operadores o entre un operador y un cliente.

[0117] A continuación se describen las prácticas operacionales adoptadas para la interacción entre operadores.

[0118] El proxy personal PP decide de manera autónoma (por ejemplo, posteriormente a la detección de una intervención que no haya sido satisfactoria en caso de ingenieros de campo) o en el momento de una notificación por parte del operador, activar una sesión con los proxys personales PP de otros operadores (etapa 1500).

[0119] En caso de una activación automática (comprobación realizada en la etapa 1510), el proxy personal PP, basándose en los conocimientos del tipo de actividad que el operador está realizando (inferidos a partir de los datos disponibles u obtenidos a partir de una indicación explícita del operador) y en las macrohabilidades requeridas para llevarla a cabo, intenta activar una sesión usando una lista ordenada de nombres de operadores con los que ponerse en contacto, organizados según las macrohabilidades (etapa 1600).

[0120] Si la activación no es satisfactoria (comprobación realizada en la etapa 1610), el proxy personal PP comprueba con el operador (etapa 1640) si seguir con su intento de activar una sesión, o parar. Si el operador decide continuar, el proxy personal PP hace otro intento de activar una sesión con el siguiente nombre de la lista (etapa 1600) y continúa de manera iterativa hasta que consigue activar una sesión o hasta que el operador decide interrumpir el procedimiento. En el segundo caso, el proxy personal PP finaliza el procedimiento de activación de sesión (etapa 1590).

[0121] Si la activación es satisfactoria (comprobación realizada en la etapa 1610) se inicia una sesión entre los operadores, en la que el proxy personal PP pone a disposición un conjunto de herramientas para trabajo cooperativo, como hacer visible para ambos operadores todos los datos sobre la actividad que ha de realizarse y sobre las etapas ya realizadas o compartir posibles datos de red que el operador, quien ha solicitado el apoyo, ya ha adquirido (etapa 1620).

[0122] En el momento de la notificación del operador, el proxy personal PP procede entonces a cerrar la sesión (etapa 1570).

[0123] En caso de activación en el momento de la solicitud por parte del operador (comprobación realizada en la etapa 1510), el proxy personal PP, basándose en los conocimientos del tipo de actividad que el operador está llevando a cabo (inferidos a partir de los datos disponibles u obtenidos a partir de una indicación explícita del operador) y en las macrohabilidades requeridas para llevarla a cabo, presenta (etapa 1520) una lista ordenada de nombres (el orden es el que seguiría el proxy personal PP si tuviera que activar la sesión de manera autónoma), entre los que el operador selecciona el nombre deseado (etapa 1530).

[0124] Posteriormente a la selección del nombre por parte del operador, el proxy personal PP intenta establecer una sesión con el proxy personal PP asociado a dicho nombre (etapa 1540). Si la activación no tiene éxito (comprobación realizada en la etapa 1550), el proxy personal PP comprueba con el operador (etapa 1580) si proceder con el intento de activar una sesión o parar. Si el operador decide continuar, el proxy personal PP muestra una vez más la lista de nombres, actualizados apropiadamente para tener en cuenta el (los) intento(s) no satisfactorio(s) (etapa 1520) y continúa de manera iterativa hasta que consiga activar una sesión o hasta que el operador decida interrumpir el procedimiento. En el segundo caso, el proxy personal PP finaliza el procedimiento de activación de sesión (etapa 590).

[0125] Si la activación es satisfactoria (comprobación realizada en la etapa 1550) se inicia una sesión entre los operadores, en la que el proxy personal PP pone a disposición un conjunto de herramientas para trabajo cooperativo del tipo ya considerado anteriormente (etapa 1560). En el momento de la notificación del operador, el proxy personal PP procede entonces a cerrar la sesión (etapa 1570).

[0126] La interacción entre cliente y operador usa mecanismos similares a los que se hizo referencia anteriormente para la interacción entre operadores; en este caso, es posible suponer que la cooperación implicará normalmente al cliente y a un asesor de un centro de atención telefónica y que será el proxy personal PP del cliente el que, en el momento de la solicitud del propio cliente o de manera autónoma, establecerá una sesión. También en este caso, el cliente puede decidir interrumpir el intento de establecer una sesión con un operador en cualquier momento. En caso de una solicitud de cliente, el proxy personal PP presenta al propio cliente la lista ordenada de nombres de asesores de un centro de atención telefónica y permite al cliente seleccionar el asesor con el que ponerse en contacto.

[0127] Para ofrecer los servicios ejemplificados anteriormente, la plataforma descrita mantiene un conjunto de datos sobre los operadores, sobre los clientes y sobre los flujos de trabajo, y realiza una gestión dinámica de los procesos para adaptarse tanto a cambios operacionales (introducción de nuevos flujos de trabajo tras la introducción de nuevos equipos, supresión de flujos de trabajo referentes a actividades en equipos que ya no están en la red, etc.) como a cambios de las características y del número de empleados (introducción de nuevos operadores, actualización de los datos de los perfiles de operador, etc.) y de los clientes (introducción de nuevos clientes, actualización de los datos de los perfiles de cliente, etc.).

[0128] Los perfiles de operador se definen basándose en un pequeño número de perfiles básicos estándar; dichos perfiles especifican las macrohabilidades (por ejemplo, dominios de red/servicios en los que el operador puede llevar a cabo actividades: conmutación, transmisión, acceso ADSL, etc.) de los operadores y, para cada macrohabilidad, el grado correspondiente (indica lo experto que es el operador en un campo dado). El perfil también destaca si el operador es un ingeniero de campo o un operador de servicios internos, o un asesor de centro de atención telefónica indica a qué equipo virtual pertenece y proporciona sus credenciales de autenticación. Los datos de dichos perfiles se actualizan dinámicamente para tener en cuenta, por ejemplo, nuevas macrohabilidades o cambios de grado; el modelo de los perfiles se almacena en la base de datos ODB. La actualización dinámica de las macrohabilidades se lleva a cabo en el momento oportuno para permitir que todos los servicios de la plataforma (por ejemplo, el de interacción entre operadores) utilicen datos actualizados. En lo que respecta a la carga de los datos de los perfiles de operador, cada proxy personal PP mantiene solamente el perfil del operador con quien está asociado (cada proxy personal PP está asociado a un operador específico): los datos de dicho perfil son adquiridos por el OM interactuando con sistemas externos apropiados (sistemas WFM); la plataforma contempla entonces un inventario centralizado (inventario de destrezas EI), en el que están almacenados los datos de los perfiles de todos los operadores (descargados desde el WFM). En el momento de la activación de cada proxy personal PP, los datos del perfil de operador asociado a dicho proxy personal PP se descargan automáticamente desde el inventario de destrezas EI, mediante el gestor operacional OM, al propio proxy personal PP. El inventario EI se actualiza periódicamente y, en cada actualización de los datos del propio inventario, los datos se envían al proxy personal PP correspondiente.

[0129] Los perfiles de cliente se definen basándose en un pequeño número de perfiles básicos estándar; dichos perfiles especifican el (los) servicio(s) para el (los) que el cliente puede llevar a cabo por sí mismo actividades de reparación (por ejemplo, servicio ADSL, servicio RDSI, etc.) y los credenciales de autenticación del cliente. Los datos de los perfiles se actualizan dinámicamente para tener en cuenta, por ejemplo, nuevos servicios que se hayan suscrito; el modelo de los perfiles se almacena en la base de datos ODB. La actualización dinámica de los datos de los perfiles de cliente se realiza en el momento oportuno para permitir que todos los servicios de la plataforma utilicen datos actualizados. En lo que respecta a la carga de los datos de los perfiles de cliente, cada proxy personal PP mantiene solamente el perfil del cliente al que está asociado (cada proxy personal PP está asociado a un cliente específico): los datos de dicho perfil son adquiridos por el gestor operacional OM interactuando con sistemas externos apropiados (sistemas de soporte de negocio); la plataforma contempla entonces un inventario centralizado (inventario de destrezas EI), en el que están almacenados los datos de los perfiles de todos los clientes (descargados desde los sistemas de soporte de negocio). En el momento de la activación de cada proxy personal PP, los datos del perfil de cliente asociado a dicho proxy personal PP se descargan automáticamente desde el inventario EI, mediante el gestor operacional OM, al propio proxy personal PP. El inventario EI se actualiza periódicamente y, en cada actualización de los datos del propio inventario, los datos se envían al proxy personal PP correspondiente.

[0130] En lo que respecta a flujos de trabajo para apoyar a las operaciones de los ingenieros de campo, la base de datos ODB mantiene, para cada flujo de trabajo, un conjunto de características tales como el identificador de flujo de trabajo (éste puede ser un identificador numérico progresivo generado automáticamente por la plataforma), la versión del flujo de trabajo, el resultado del flujo de trabajo, el tipo de intervención a la que se aplica el flujo de trabajo (por ejemplo, fallo, actividades de suministro, actividades de la operación, etc.), el identificador de la intervención específica que ha de realizarse (por ejemplo, en caso de fallo, es posible indicar un fallo de enlace, un fallo de tarjeta de usuario, etc.), el grado de macrohabilidades requerido para llevar a cabo la intervención, si es aplicable (por ejemplo, ingeniero de campo experto e ingeniero de campo novato), etc. Dichas características se proporcionan cuando se crea/modifica el flujo de trabajo; el resultado se actualiza dinámicamente, de acuerdo con lo que se menciona más adelante. La creación/modificación de los flujos de trabajo que apoyan a la operación, almacenados en la base de datos OBD, y de los flujos de trabajo cooperativos correspondientes, almacenados en la base de datos MDB, se realiza mediante una interfaz gráfica apropiada que permite la edición en paralelo de los dos flujos de trabajo correlacionados para facilitar las comprobaciones de congruencia en lo que se ha procesado.

[0131] Se aplican consideraciones similares en lo que respecta a los flujos de trabajo que apoyan a operaciones de cliente: la base de datos ODB mantiene, para cada flujo de trabajo para apoyar al cliente, un conjunto de características similares a las de los flujos de trabajo para el ingeniero de campo y también aplicables al caso del cliente.

[0132] Para los flujos de trabajo que apoyan a los ingenieros de campo se contemplan dos funciones de gestión.

[0133] En lo que respecta a la carga de flujos de trabajo, la descarga del flujo de trabajo en el proxy personal PP se llevará a cabo por el agente de control CA asociado al mismo. En el momento de la activación del proxy personal PP, no se descarga ningún flujo de trabajo; los flujos de trabajo se descargan en el proxy personal PP solamente en el momento de la solicitud explícita del propio proxy personal PP: posteriormente a la suposición de una actividad dada por parte de un ingeniero de campo y de la selección por su parte de un flujo de trabajo que ha de llevarse a cabo o ha de mostrarse en su dispositivo, el proxy personal PP comprueba si puede accederse directamente a dicho flujo de trabajo en la medida en que ya está presente en el área de memoria local y si está actualizado (mediante el indicador de versión asociado a los flujos de trabajo). Si el flujo de trabajo no está presente o no está actualizado, mediante el agente de control CA se descarga desde la base de datos ODB; el flujo de trabajo permanecerá almacenado en el proxy personal PP para cualquier posible uso futuro.

[0134] De manera similar, en el momento de la activación del proxy de recursos RP no se descarga ningún flujo de trabajo; los flujos de trabajo se descargan en el proxy de recursos RP solamente en el momento de una solicitud explícita por parte del propio proxy de recursos RP: en el momento en que el proxy de recursos RP recibe desde el proxy personal PP la solicitud de activar un flujo de trabajo dado en apoyo de la operación, el proxy personal PP comprueba si éste es directamente accesible en la medida en que ya está presente en el área de memoria local y si está actualizado (mediante el indicador de versión asociado a los flujos de trabajo). Si el flujo de trabajo no está presente o no está actualizado, el proxy de recursos RP lo descarga desde la base de datos MDB; el flujo de trabajo permanecerá almacenado en el proxy de recursos RP para posibles usos futuros.

[0135] Se contempla entonces un procedimiento para gestionar dinámicamente el “resultado” de los flujos de trabajo. El resultado del flujo de trabajo se basa tanto en los datos de tiempo/costes (relacionados con las actividades realizadas por el ingeniero de campo y con el coste de los materiales usados para realizar estas actividades) como en las preferencias del ingeniero de campo para un flujo de trabajo dado. Para adquirir estos datos, en cada ejecución de un flujo de trabajo se recopila un conjunto de parámetros relacionados con dicha ejecución (la recopilación de los parámetros de flujo de trabajo se lleva a cabo por los proxys personales PP) y se actualiza. Ejemplos de tales parámetros son el tiempo total de ejecución del flujo de trabajo en el proxy personal PP, la utilización de la CPU, el número de operadores que han elegido el flujo de trabajo, etc. Los datos recopilados/actualizados se almacenan en la base de datos de rendimiento PDB. Periódicamente (por ejemplo, a intervalos de tiempo fijos), es necesario analizar y procesar dichos parámetros para obtener un nuevo valor del resultado de cada flujo de trabajo. El nuevo resultado de los flujos de trabajo se comunica luego a los diversos proxys personales PP.

[0136] Se proporcionan funciones de gestión similares para flujos de trabajo que dan soporte a los clientes: los flujos de trabajo se descargan en el proxy personal PP en el momento de la solicitud por parte del propio proxy personal PP, posteriormente a la identificación del fallo/problema que ha de tratarse con dichos flujos de trabajo, o en el momento de la recepción de la solicitud para activar un flujo de trabajo específico procedente del proxy personal PP de un asesor de un centro de atención telefónica. En particular, en caso de que pueda usarse una pluralidad de flujos de trabajo para guiar al cliente, sólo se descarga en el proxy personal PP el flujo de trabajo que en ese momento tenga el resultado más alto. También para los flujos de trabajo para el cliente, se proporciona un mecanismo de gestión dinámica del resultado, calibrado apropiadamente según los parámetros que pueden identificarse en la parte del cliente.

[0137] Tal como se ha observado, la interacción entre el proxy personal PP y el operador o el cliente se realiza usando una interfaz personal PI apropiada. La interfaz PI se crea usando tecnologías que dependen del tipo y de la potencia de cálculo del dispositivo usado por el operador/cliente (PC, teléfono móvil, ordenador portátil, etc.) como, por ejemplo, tecnologías cliente-servidor basadas en web (páginas HTML, applets de Java, aplicaciones Java autónomas) o tecnologías de agentes autónomos. La interfaz PI está diseñada de manera coherente con los principios de manejo con el fin de permitir que el operador/cliente consiga el objetivo establecido con la mejor efectividad, eficacia y satisfacción en todos los contextos de uso específicos. En el desarrollo de la interfaz PI se ha prestado gran atención tanto a la optimización del código, para hacer que las interacciones y las actividades que los proxys personales PP tienen que realizar en cooperación con los proxys de recursos RP resulten más efectivas, como a los aspectos de manejo y de facilidad de uso de la GUI para mejorar en gran medida la capacidad del operador/cliente para llevar a cabo la tarea asignada al mismo.

[0138] En el caso de un operador, en el momento de una solicitud de actividad (intervención in situ o informe de problema/orden de cliente), el WFM envía al gestor operacional OM el nombre del operador elegido y los detalles de la actividad que ha de realizarse. El gestor operacional OM reenvía dichos datos al proxy personal PP asociado al operador elegido, mediante el agente operacional OA que coordina dicho proxy personal PP; a su vez, el proxy personal PP informa en la interfaz PI correspondiente de que hay que llevar a cabo una actividad.

[0139] Una vez que el operador ha recibido en su interfaz PI la información de que hay que llevar a cabo una actividad, procede de la siguiente manera:

-

inicia, desde la página inicial de la interfaz PI, el procedimiento de entrada al sistema y de autenticación; basándose en el perfil del operador, pueden mostrarse o no secciones dedicadas a funciones "privilegiadas"; los datos de autenticación se verifican con los almacenados en el inventario de destrezas EI para el operador asociado a dicho proxy personal PP;

-

muestra los datos sobre la actividad asignada al mismo y ejecuta el procedimiento de suposición de dicha actividad (por ejemplo, intervención in situ o informe de problema/orden de cliente); en este punto, el operador puede obtener acceso, a través de la interfaz PI, a entornos gráficos y de navegación como ayuda a la operación; las funciones proporcionadas por estos entornos están disponibles en parte para y son usadas por todos los tipos de operadores (por ejemplo, ingenieros de campo y asesores de centros de atención telefónica) y en parte son específicas de un cierto tipo de operador.

[0140] Estas funciones permiten:

-

la visualización de la ubicación del equipo (por ejemplo, en un intercambio) en el que llevar a cabo la intervención (ingenieros de campo);

-

la visualización de la interfaz del equipo y la identificación gráfica del componente de hardware (bastidor, tarjeta, puerto, dispositivo, etc.) sobre el que es necesario intervenir (ingenieros de campo);

-

la presentación de el flujo de trabajo (con una posible opción previa de selección entre diferentes flujos de trabajo) de un modo interactivo para guiar, paso a paso, las operaciones del ingeniero (ingenieros de campo);

-

la presentación de una secuencia de preguntas de un modo interactivo para adquirir, paso a paso, la información requerida para detallar la solicitud de un cliente (asesores de centros de atención telefónica);

-

la sugerencia de acciones que el cliente debería llevar a cabo para resolver un informe de problema presentado por el propio cliente (asesores de centros de atención telefónica);

-

la presentación de hipótesis realizadas sobre la causa del informe de problema de un cliente (asesores de centros de atención telefónica);

-

la visualización de la configuración de las conexiones entre el proxy personal PP y el proxy de recursos RP, y la presentación de las "respuestas" del proxy de recursos RP a las acciones de configuración, ajuste, medición, prueba, etc. llevadas a cabo por el RP, ya sea de manera autónoma o a solicitud del proxy personal PP (todos los operadores);

-

el acceso remoto, mediante el RP, a una CLI (interfaz de línea de comandos) en el equipo en que se está llevando a cabo la intervención (ingenieros de campo);

-

la visualización de la documentación en línea como posible apoyo a la actividad (todos los operadores); y

-

el acceso a las funciones “tradicionales” de comunicación con otros operadores (operadores de equipos virtuales, personal de administración, operadores de servicios internos, asesores de centros de atención telefónica): llamada de voz, correo electrónico, conversación, pizarra compartida, etc. (todos los operadores).

[0141] En caso de un cliente, el propio cliente, después de la activación de su proxy personal PP, ejecuta el procedimiento de entrada al sistema y de autenticación y recibe en su dispositivo todos los datos (preguntas, flujos de trabajo de guiado, etc.) requeridos para solucionar una avería detectada por él.

[0142] Las funciones ofrecidas permiten:

-

la presentación del flujo de trabajo de un modo interactivo para guiar, paso a paso, las actividades del cliente;

-

la presentación de una secuencia de preguntas de un modo interactivo para adquirir, paso a paso, la información requerida para identificar la causa de la avería detectada por el cliente;

-

la presentación de la hipótesis de la causa principal de una avería;

-

la visualización de la configuración de las conexiones entre el proxy personal PP y el proxy de recursos RP, y la presentación de las “respuestas” del proxy de recursos RP;

-

la notificación de la necesidad de contactar con un operador para solucionar la avería;

-

el acceso a las funciones de comunicación con un operador.

[0143] Los componentes que dan soporte a la operación descrita anteriormente también pueden aplicarse en contextos de gestión basados en enfoques tecnológicos más tradicionales (paradigma cliente-servidor).

[0144] Si se examinan, por ejemplo, soluciones de gestión que adoptan un enfoque jerárquico basado en la tecnología cliente-servidor (como se ejemplifica, por ejemplo, por el documento US-A-2004/0196794), las funciones para dar soporte a la operación (de operadores y clientes) descrita anteriormente todavía son eficaces y pueden ofrecerse usando una plataforma que, para la parte operacional, no cambia con respecto a lo que se presenta en la Figura 2 de este documento, mientras que para la parte de gestión de red y de servicios, se basa en la arquitectura descrita en la Figura 2 del documento US-A-2004/0196794. En particular, en este caso, si el objetivo es adoptar un enfoque conservador que no contemple la modificación del componente de gestión (estación de gestión de red de capa inferior) que gestiona directamente los dispositivos de la red, el proxy personal PP interactuará directamente con la estación de gestión de red de capa inferior correspondiente para llevar a cabo todas las interacciones desde/hacia la red (que, en la realización descrita anteriormente, eran realizadas a través del proxy de recursos RP), usando modalidades de comunicación similares a las adoptadas entre estaciones de gestión de red de capa superior y de capa inferior. Alternativamente, el proxy personal PP podría interactuar con una estación de gestión de red de capa superior, a la cual pertenece la información topológica sobre las estaciones de gestión de red de capa inferior, evitando así tener que encargarse de dicha información directamente. En cualquier caso, excepto para las modificaciones del componente de gestión, no habría un flujo de trabajo cooperativo en la estación de gestión de red correspondiente; sin embargo, esto no pone en peligro de ninguna manera la validad y efectividad de la función para dar soporte a la operación, en la medida en que esto sólo representa una posible alternativa a la realización preferida de la presente invención.

[0145] Se apreciará que, mientras que el procedimiento que guía a los ingenieros de campo en la realización de una intervención dada, tal como se describe en relación con la Figura 3, se refiere a la selección de la intervención que ha de llevar a cabo un ingeniero de campo, las modalidades con las que se hace dicha selección son diversas, y dependen del paradigma operacional adoptado y de las funciones realizadas por el sistema WFM. En una realización de la presente invención, el ingeniero de campo sólo se hace cargo de la intervención que se le presenta por el proxy personal PP en su interfaz PI, y que fue descargada al propio proxy personal PP mediante la cadena WFM-OM.

[0146] En una realización alternativa, el ingeniero de campo selecciona una actividad de las que han de llevarse a cabo en un equipo en un lugar dado; en este caso, la única indicación recibida por el ingeniero de campo, mediante el proxy personal PP que, a su vez, la recibió desde la cadena WFMOM, es la relacionada con el lugar al que tiene que ir (el WFM solo gestiona los turnos periódicos de los ingenieros de campo entre los diversos lugares, sin indicarles qué tienen que hacer).

[0147] El procedimiento descrito anteriormente en relación con la Figura 3 indica que se proponen flujos de trabajo apropiados al ingeniero de campo. Esto se hace por interacción entre el proxy personal PP y el gestor operacional OM. Cuando se selecciona una intervención por parte de un ingeniero de campo, el proxy personal PP pide al gestor operacional OM la lista de todos los flujos de trabajo para dar soporte a dicha intervención. El gestor operacional OM crea esta lista dinámicamente, basándose en la información de flujo de trabajo disponible en la base de datos ODB, y la envía al proxy personal PP, el cual la presenta al ingeniero de campo.

[0148] En una primera posible realización de la presente invención, dada una intervención específica, a todos los ingenieros de campo se les presentan entonces los mismos flujos de trabajo, independientemente de su grado de habilidad particular.

[0149] En una realización alternativa, dada una intervención específica, los flujos de trabajo presentados a un ingeniero de campo dependen de su propio grado de habilidad. Si el ingeniero de campo es un experto, se le presentan flujos de trabajo de nivel más alto; de lo contrario, los flujos de trabajo propuestos son más detallados o, en cualquier caso, permiten acceder a documentos y normas técnicas útiles para el ingeniero de campo. En el primer caso, la selección por parte del gestor operacional OM de los flujos de trabajo que han de ponerse en la lista se hace, por tanto, considerando solamente el tipo de intervención que ha de llevarse a cabo, mientras que en el segundo caso también se tiene en cuenta el perfil del ingeniero de campo y, en particular, su grado de habilidad con referencia a la habilidad requerida para llevar a cabo la intervención en cuestión.

[0150] De nuevo, en una realización alternativa de la presente invención, la activación del flujo de trabajo en el proxy personal PP no implica la activación de un flujo de trabajo cooperativo en el proxy de recursos RP: el flujo de trabajo en el proxy personal PP sólo activa de manera interactiva flujos de trabajo específicos en el proxy de recursos RP para recopilar algunos datos/mediciones dados, solicitar la ejecución de actividades dadas en el equipo, u ofrecer un acceso remoto a posibles interfaces de línea de comando. Los flujos de trabajo ejecutan lo que se solicita y devuelven el resultado al proxy personal PP. En este caso, el proxy de recursos RP no sabe qué está haciendo el operador, guiado por el proxy personal PP. Esto supone que, como última etapa, el flujo de trabajo en el proxy personal PP debería pedir al proxy de recursos RP que compruebe el resultado de la intervención llevada a cabo por el ingeniero de campo, antes de considerar que dicha intervención se ha llevado a cabo satisfactoriamente.

[0151] Tal como se ha visto, el procedimiento para dar soporte a un asesor de un centro de atención telefónica permite activar, siempre que sea necesario, un flujo de trabajo en el proxy personal PP del cliente. Esto requiere que el proxy personal PP esté activo. La activación del proxy personal PP puede producirse automáticamente, con una solicitud de activación procedente del proxy personal PP del operador o, si no, en modo manual con activación del proxy personal PP por parte del cliente. En este último caso, el propio proxy personal PP puede estar ya en el dispositivo del cliente y simplemente debe ser activado o, si no, el cliente puede descargarlo desde un sitio provisto a propósito. En una realización alternativa, dicho procedimiento no contempla la activación de un flujo de trabajo en el proxy personal PP del cliente: el asesor de un centro de atención telefónica sólo interactúa con el cliente por medio de un paradigma de pregunta-respuesta, pidiéndole a lo sumo que lleve a cabo algunas acciones particulares.

[0152] Además, el procedimiento para dar soporte al cliente contempla una realización alternativa en la que, una vez que el proxy personal PP haya detectado la necesidad de contactar con un asesor de un centro de atención telefónica para solucionar la avería notificada por el cliente, en lugar de sugerir al cliente que contacte con el centro de atención telefónica, activa directamente una sesión con el proxy personal PP de un asesor de un centro de atención telefónica.

[0153] En cuanto a la cooperación entre operadores, nuevamente puede observarse lo que se describe a continuación. El procedimiento descrito con referencia a la Figura 7 contempla la preparación de una lista ordenada de nombres de operadores con los que ha de contactarse, utilizada por el PP para abrir una sesión entre operadores o, si no, presentada al operador: dicha lista se crea de manera dinámica. En el momento en que el proxy personal PP debería abrir una sesión cooperativa, pide al gestor operacional OM que cree la lista de los operadores con los que ha de contactarse, proporcionándole las indicaciones requeridas (por ejemplo, indicación de la actividad realizada por el operador y de la habilidad requerida para dicha actividad); el gestor operacional OM consulta el inventario de destrezas EI y, basándose en la información obtenida, prepara la lista requerida (introduciendo operadores del mismo equipo virtual o incluso de otros equipos). La lista se ordena según las habilidades de los operadores y, en caso de diferentes equipos, según los equipos (primero se introducen los operadores del mismo equipo virtual, según el grado decreciente de habilidad, después los operadores de otros equipos, una vez más en grado decreciente de habilidad). Por último, el gestor operacional OM envía la lista creada al proxy personal PP.

[0154] En una realización alternativa a la presentada anteriormente, el proxy personal PP puede abrir sesiones entre un operador y otros dos o más operadores, los cuales pueden interactuar entre sí mediante varias herramientas, incluyendo herramientas para dar soporte a tareas cooperativas.

[0155] También en caso de cooperación entre clientes y operadores, se aplican las mismas modalidades de creación dinámica, mediante el gestor operacional OM, de la lista de operadores con los ha de contactarse, usada por el proxy personal PP para abrir una sesión entre cliente y operador o, si no, presentada al cliente.

[0156] Teniendo ahora en cuenta la gestión de los perfiles de operador en el proxy personal PP en una realización alternativa a la presentada anteriormente, cada PP mantiene, además del perfil del operador al que está asociado, también los datos de otros perfiles de operador (esto se hace por motivos de rendimiento: de esta manera, se reduce el tiempo para acceder a datos de otros operadores con los que ha de contactarse). En particular, una primera alternativa contempla que dichos datos deberían referirse a todos los operadores del mismo equipo virtual que el del operador al que está asociado el proxy personal PP. También es posible una segunda alternativa, según la cual los datos de los perfiles de operador almacenados en el proxy personal PP se refieren a un subconjunto de los operadores del equipo virtual de interés y, en particular, a los operadores equipados, en gran medida, con las macrohabilidades requeridas para el equipo: para cada macrohabilidad se seleccionan uno o más perfiles; estos perfiles son los perfiles de operadores que son expertos en lo que respecta a una macrohabilidad específica (es decir, cuya habilidad es la más alta entre las de un equipo virtual dado). Las maneras en que dichos datos se descargan por primera vez y se actualizan posteriormente no cambian con respecto a lo que se ha descrito para el perfil del operador asociado al proxy personal PP; sin embargo, en este caso, en los datos reenviados al proxy personal PP también está la indicación de los que se refieren al perfil del operador asociado al propio proxy personal PP.

[0157] La gestión de los perfiles de operador en una realización adicional es completamente dinámica, en el sentido de que el proxy personal PP no está asociado a priori a ningún operador específico: la asociación con un operador dado se hace cuando el operador se autentifica. En este caso, después de la autenticación por parte del operador, el proxy PP reenvía al gestor operacional OM los datos de autenticación suministrados por el operador y le pide que descargue los datos de perfil con respecto a dicho operador. El gestor operacional OM, después de la comprobación previa de la exactitud de las credenciales suministradas, descarga en el PP los datos del perfil en cuestión. También en este caso, es posible contemplar una realización alternativa en la que el gestor operacional OM envía al proxy personal PP no solamente los datos del perfil del operador al que está asociado, sino también los datos de otros perfiles de operador, con las mismas opciones vistas anteriormente (datos referentes a todos los operadores del equipo virtual del operador, o a un subconjunto de los operadores del equipo virtual).

[0158] En cuanto al procedimiento de gestión de los flujos de trabajo para dar soporte a los operadores, con respecto a lo que se mencionó anteriormente, es posible contemplar realizaciones alternativas de las modalidades que han de adoptarse para descargar los flujos de trabajo.

[0159] Una primera realización contempla que en la activación del proxy personal PP todos los flujos de trabajo para guiar al operador se descarguen en el mismo.

[0160] En cambio, según una segunda realización, en la activación del proxy personal PP o después de la autenticación del operador (según si el proxy personal PP está asociado a un operador de una manera estática o dinámica), todos los flujos de trabajo para guiar al operador se descargan en el mismo con la exclusión de los posibles flujos de trabajo que sólo son aplicables a equipos virtuales específicos. Es posible definir flujos de trabajo que se apliquen sólo a equipos virtuales específicos, en función de las características de los equipamientos gestionados por estos equipos y/o en función de las habilidades particulares de los miembros del equipo.

[0161] Por último, según una tercera realización, en la activación del proxy personal PP o posteriormente a la autenticación del operador, sólo se descargan en el mismo los flujos de trabajo que son compatibles con las habilidades del operador al que está asociado el PP.

5 [0162] En función de las posibles realizaciones alternativas adoptadas, las funciones de la interfaz PI también pueden cambiar: en particular, si la única indicación recibida por el ingeniero de campo en la interfaz PI es la relacionada con el lugar al que debe ir, la interfaz PI presentará al ingeniero de campo el conjunto de las intervenciones que han de realizarse en un lugar dado (de manera coherente con el perfil del ingeniero de campo), y será el propio ingeniero de campo quien seleccionará la intervención que ha de llevarse a cabo y de la que va a

10 encargarse.

[0163] Por consiguiente, sin perjuicio de los principios subyacentes a la invención, los detalles y las realizaciones pueden variar, incluso apreciablemente, con respecto a lo que se ha descrito en este documento simplemente a modo de ejemplo, sin apartarse del alcance de la invención tal como se define por las reivindicaciones adjuntas.

Claims (40)

1. REIVINDICACIONES

   1. Un procedimiento de generación de señales de instrucción dispuestas en flujos de trabajo para realizar intervenciones en equipos de red incluidos en una red de comunicación (N), en el que dichos equipos de red tienen agentes proxy de recursos (RP1, ... , RPn) asociados, incluyendo el procedimiento las etapas de:

   -

   proporcionar una arquitectura distribuida de agentes proxy de gestión de intervenciones (PP1, ... , PPn) para gestionar intervenciones en los equipos de red, estando dichos agentes proxy de gestión de intervenciones asociados a dispositivos terminales,

   -

   acoplar con dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) interfaces personales (PI) para generar dichas señales de instrucción dispuestas en flujos de trabajo, y

   -

   generar señales de instrucción para realizar una intervención en al menos un equipo de red de dicha red de comunicación mediante uno de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) de una manera interactiva (PTP) con al menos uno de dichos agentes proxy de recursos (RP1, ... , RPn) asociado con dicho equipo de red, por lo que dichas señales de instrucción son una función del estado de dicho equipo de red.

2. 2.

   El procedimiento de la reivindicación 1, caracterizado porque cada uno de dichos agentes proxy de recursos es responsable de gestionar un único equipo de red.

3. 3.

   El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de disponer dicha arquitectura distribuida en capas jerárquicas que incluyen:

   -

   una capa de agentes operacionales (OA1, ... , OAk) que coordinan el funcionamiento de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn), y

   -

   una capa que comprende un gestor operacional (OM) que tiene funciones de gestión y control y que supervisa el funcionamiento de dichos agentes operacionales (OA1, ... , OAk).

4. 4.

   El procedimiento de la reivindicación 3, caracterizado porque incluye la etapa de asignar a dichos agentes operacionales (OA1, ... , OAk) la ejecución distribuida de intervenciones por una pluralidad de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn).

5. 5.

   El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de disponer dicha arquitectura distribuida en capas jerárquicas, en el que una capa incluye un gestor operacional (OM) que tiene funciones de gestión y control y que coordina directamente el funcionamiento de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn).

6. 6.

   El procedimiento de la reivindicación 3 o 5, caracterizado porque incluye la etapa de asignar, a cada uno de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) la tarea de dar soporte a un único operador o cliente, por lo que la ejecución de dichas intervenciones es desacoplada con respecto a dichas funciones de gestión y control.

7. 7.

   El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de proporcionar motores de procesos (PE) a dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn).

8. 8.

   El procedimiento de la reivindicación 3 o 5, caracterizado porque incluye la etapa de proporcionar motores de procesos (PE) a todas las dichas capas de dicha arquitectura distribuida.

9. 9.

   El procedimiento de la reivindicación 7 u 8, caracterizado porque el hecho de proporcionar motores de procesos (PE) incluye la etapa de proporcionar al menos uno de un flujo de trabajo, un motor de reglas y una combinación de los mismos.

10. 10.

    El procedimiento de la reivindicación 3 o 5, caracterizado porque incluye la etapa de incluir en dichas capas componentes (PP, OA, OM) adaptados para realizar funciones respectivas basándose en la información de instrucción respectiva proporcionada a los mismos.

11. 11.

    El procedimiento de la reivindicación 10, caracterizado porque incluye la etapa de proporcionar en dicha información de instrucción al menos una de las siguientes:

    -

    una definición de procesos, que incluye al menos uno de un flujo de trabajo y una regla, y

    -

    una definición de modelos de datos.

12. 12.

    El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de configurar dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) para que interactúen directamente entre sí en una relación de interfuncionamiento, por lo que al menos una de dichas señales de instrucción se produce por interacción entre los agentes proxy de gestión (PP1, ... , PPn).

13. 13.

    El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de configurar dichos agentes proxy de gestión de intervenciones (PP1, .., PPn) para una interacción de igual a igual (PTP) con dichos agentes proxy de recursos (RP1, ... , RPn).

14. 14.

    El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de organizar una base de datos operacionales (ODB) como repositorio de definiciones de procesos y definiciones de modelos de datos de dichas intervenciones.

15. 15.

    El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de organizar una base de datos de modelos (MDB) como repositorio de definiciones de procesos y definiciones de modelos de datos para gestionar dichos equipos de red.

16. 16.

    El procedimiento de la reivindicación 3 o 5, caracterizado porque incluye la etapa de organizar una única base de datos de rendimiento (PDB) que almacena datos de rendimiento relacionados con dichas capas de dicha arquitectura distribuida.

17. 17.

    El procedimiento de la reivindicación 1, caracterizado porque incluye la etapa de organizar un registro operacional (OL) que almacena todas las actividades realizadas por usuarios de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn).

18. 18.

    El procedimiento de la reivindicación 1, caracterizado porque la etapa de organizar un inventario de destrezas (EI) que almacena perfiles de operadores o clientes gestionados por dichos agentes proxy de gestión de intervención (PP1, ... , PPn).

19. 19.

    El procedimiento de la reivindicación 3 o 5, caracterizado porque incluye la etapa de proporcionar agentes de control (CA) asociados a al menos una capa de dicha arquitectura distribuida para realizar al menos una etapa seleccionada del grupo que está constituido por:

    -

    distribuir definiciones de procesos a dichas capas de dicha arquitectura distribuida;

    -

    distribuir definiciones de modelos de datos a dichas capas de dicha arquitectura distribuida; y

    -

    supervisar el estado de dichas capas de dicha arquitectura distribuida.

20. 20. El procedimiento de la reivindicación 19, caracterizado porque incluye la etapa de proporcionar un módulo de gestión (MM) para realizar al menos una etapa seleccionada del grupo que está constituido por:

    -

    gestionar la distribución de definiciones de procesos a dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA);

    -

    gestionar la distribución de definiciones de modelos de datos a dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA);

    -

    supervisar el estado de dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA).

21. 21.

    Un sistema para generar señales de instrucción dispuestas en flujos de trabajo para realizar intervenciones en equipos de red incluidos en una red de comunicación (N), en el que dichos equipos de red tienen agentes proxy de recursos (RP1, ... , RPn) asociados, incluyendo el sistema una arquitectura distribuida de agentes proxy de gestión de intervenciones (PP1, ... , PPn) para generar dichas señales de instrucción, estando dichos agentes proxy de gestión de intervenciones asociados a dispositivos terminales, incluyendo el sistema además interfaces personales (PI) acopladas con dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) para generar dichas señales de instrucción dispuestas en flujos de trabajo, en el que dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) están acoplados de manera interactiva (PTP) con dichos agentes proxy de recursos (RP1, ... , RPn) y en el que dichas señales de instrucción son una función del estado de los equipos de red en los cuales se realizan dichas intervenciones.

22. 22.

    El sistema de la reivindicación 21, caracterizado porque cada uno de dichos agentes proxy de recursos es responsable de gestionar un único equipo de red.

23. 23.

    El sistema de la reivindicación 21, caracterizado porque dicha arquitectura distribuida comprende capas jerárquicas que incluyen:

    -

    una capa de agentes operacionales (OA1, ... , OAk) que coordinan el funcionamiento de dichos agentes proxy de gestión de intervenciones (PP1, ...., PPn), y

    -

    una capa que comprende un gestor operacional (OM) que tiene funciones de gestión y control y que supervisa el funcionamiento de dichos agentes operacionales (OA1, ... , OAk).

24. 24.

    El sistema de la reivindicación 23, caracterizado porque a dichos agentes operacionales (OA1, ... , OAk) se les asigna la ejecución distribuida de intervenciones por una pluralidad de agentes proxy de gestión de intervenciones (PP1, ... , PPn).

25. 25.

    El sistema de la reivindicación 21, caracterizado porque dicha arquitectura distribuida comprende capas jerárquicas, en el que una capa incluye un gestor operacional (OM) que tiene funciones de gestión y control y que supervisa directamente el funcionamiento de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn).

26. 26.

    El sistema de la reivindicación 23 o 25, caracterizado porque a cada uno de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) se le asigna la tarea de dar soporte a un único operador o cliente, por lo que la ejecución de dichas intervenciones es desacoplada con respecto a dichas funciones de gestión y control.

27. 27.

    El sistema de la reivindicación 21, caracterizado porque dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) se configuran para interactuar directamente entre sí en una relación de interfuncionamiento, por lo que dichas señales de instrucción incluyen señales de instrucción producidas por interacción entre agentes proxy de gestión de intervenciones (PP1, ... , PPn).

28. 28.

    El sistema de la reivindicación 21, caracterizado porque dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) incluyen motores de procesos (PE) respectivos.

29. 29.

    El sistema de la reivindicación 23 o 25, caracterizado porque cada una de dichas capas incluye motores de procesos (PE).

30. 30.

    El sistema de la reivindicación 28 o 29, caracterizado porque dichos motores de procesos (PE) comprenden al menos uno de un flujo de trabajo, un motor de reglas y una combinación de los mismos.

31. 31.

    El sistema de la reivindicación 23 o 25, caracterizado porque dichas capas de dicha arquitectura incluyen componentes (PP, OA, OM) adaptados para realizar funciones respectivas basadas en la información de instrucción respectiva proporcionada a los mismos.

32. 32.

    El sistema de la reivindicación 31, caracterizado porque dicha información de instrucción comprende al menos una de las siguientes:

    -

    una definición de procesos, que incluye al menos uno de un flujo de trabajo y una regla, y

    -

    una definición de modelos de datos.

33. 33.

    El sistema de la reivindicación 21, caracterizado porque dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn) se configuran para una interacción de igual a igual (PTP) con dichos agentes proxy de recursos (RP1, ... , RPn).

34. 34.

    El sistema de la reivindicación 21, caracterizado porque incluye una base de datos operacionales (ODB) como repositorio de definiciones de procesos y definiciones de modelos de datos de dichas intervenciones.

35. 35.

    El sistema de la reivindicación 21, caracterizado porque incluye una base de datos de modelos (MDB) como repositorio de definiciones de procesos y definiciones de modelos de datos para gestionar dichos equipos de red.

36. 36.

    El sistema de la reivindicación 23 o 25, caracterizado porque incluye una única base de datos de rendimiento (PDB) que almacena datos de rendimiento relacionados con dichas capas de dicha arquitectura distribuida.

37. 37.

    El sistema de la reivindicación 21, caracterizado porque incluye un registro operacional (OL) que almacena todas las actividades realizadas por los usuarios de dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn).

38. 38.

    El sistema de la reivindicación 21, caracterizado porque incluye un inventario de destrezas (EI) que almacena perfiles de operadores o clientes gestionados por dichos agentes proxy de gestión de intervenciones (PP1, ... , PPn).

39. 39.

    El sistema de la reivindicación 23 o 25, caracterizado porque al menos una capa de dicha arquitectura distribuida comprende agentes de control (CA) para realizar al menos una etapa seleccionada del grupo que está constituido por:

    5 - distribuir definiciones de procesos a dichas capas de dicha arquitectura distribuida;

    -

    distribuir definiciones de modelos de datos a dichas capas de dicha arquitectura distribuida; y

    -

    supervisar el estado de dichas capas de dicha arquitectura distribuida.

40. 40. El sistema de la reivindicación 39, caracterizado porque incluye un módulo de gestión (MM) para 10 realizar las etapas seleccionadas del grupo que está constituido por:

    -

    gestionar la distribución de definiciones de procesos entre dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA);

    15 - gestionar la distribución de modelos de datos entre dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA); y

    -

    supervisar el estado de dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA).

    20 41. Un producto de programa informático que puede cargarse en la memoria de al menos un ordenador y que incluye partes de código de software para realizar todas las etapas del procedimiento de cualquiera de las reivindicaciones 1 a 20 cuando el programa se ejecuta en el al menos un ordenador.