ES2353751T3

ES2353751T3 - Procedimiento y sistema para gestionar operaciones en recursos de una red distribuida, en particular de una red de comunicaciones, y producto de programa informático correspondiente.

Info

Publication number: ES2353751T3
Application number: ES06762899T
Authority: ES
Inventors: Daniela Long; Giulio Valente; Massimo Chiappone; Danilo Gotta; Fabrizio Bobbio
Original assignee: Telecom Italia SpA
Current assignee: Telecom Italia SpA
Priority date: 2005-07-29
Filing date: 2006-07-28
Publication date: 2011-03-04
Anticipated expiration: 2026-07-28
Also published as: BRPI0520475B1; KR101295721B1; WO2007016934A1; EP1911202A1; ATE480935T1; US20090113033A1; DE602006016810D1; US8738751B2; US8452859B2; BRPI0614133A2; CN101268656B; EP1911215A1; JP5410581B2; CN101268656A; CN101273583B; ES2383307T3; EP1911215B1; ATE547864T1; BRPI0614133B1; US20090049165A1

Abstract

Un sistema de operaciones distribuido, que comprende: - una pluralidad de dispositivos terminales (TD), comprendiendo cada dispositivo terminal un agente proxy (PP), comprendiendo el agente proxy un motor de procesos (PE) basado en flujos de trabajo o basado en reglas para procesar flujos de trabajo o reglas, y una interfaz de usuario (PI) para representar al menos parte de dichos flujos de trabajo o reglas; y - al menos un recurso de gestión remoto (MM) configurado para gestionar la transmisión de dichos flujos de trabajo o reglas a dichos dispositivos terminales, - agentes operacionales (OA) configurados para coordinar operaciones de dichos agentes proxy.

Description

Campo de la invención[0001] La presente invención se refiere a técnicas que permiten generar señales de instrucciones y realizar intervenciones (o, más generalmente, operaciones) en función de dichas señales de instrucciones en redes distribuidas, tales como en los aparatos de una red de comunicaciones. [0002] La invención se ha desarrollado prestando particular atención a su posible utilización en el contexto de plataformas distribuidas para gestionar y dar soporte a las operaciones de empleados y clientes. Descripción de la técnica relacionada[0003] Los costes de los procesos operacionales, tales como los que proporcionan nuevos servicios a clientes o eliminan fallos y errores, representan un porcentaje importante de los costes que las empresas de telecomunicaciones deben afrontar cada año. De ahí la importancia de procedimientos/sistemas destinados a reducir dichos costes a través de herramientas que den soporte a actividades tanto de los empleados de la empresa como de los clientes, que puedan implicarse por tanto directamente en eliminar los problemas relacionados con los equipos en las instalaciones del cliente.[0004] El soporte a los empleados y a los clientes, quienes están directamente implicados en acciones de reparación de fallos/errores, puede proporcionarse utilizando dos herramientas principales: sistemas de gestión de conocimiento (KMs, Knowledge Management Systems), o sistemas de gestión de conocimiento operacional (OKMs, Operational Knowledge Management Systems), y plataformas de gestión avanzadas, no considerados como entidades distintas sino como componentes de una solución integrada y completa.[0005] Por “gestión de conocimiento (KM)” se entiende la actividad que permite la creación, diseminación y utilización del conocimiento de una organización. Entre los diversos enfoques a KM, las compañías prefieren generalmente el enfoque local, el cual se centra en la gestión de una parte del conocimiento y en objetivos específicos (por ejemplo, toma de decisiones, resolución de problemas, etc.). La gestión de conocimiento operacional (OKM, Operational Knowledge Management) es un enfoque local a la gestión de conocimiento enfocado a la gestión del conocimiento operacional. Este tipo de conocimiento incluye procedimientos y técnicas (prácticas operacionales) necesarios para llevar a cabo una tarea particular o una actividad específica. Usuarios típicos de un OKMS son ingenieros de asistencia 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 en el artículo de G. Valente y A. Rigallo: “Remoter: an Operational Knowledge Management System for Telecommunication Operators”, taller sobre gestión de conocimiento y memorias organizativas, décimo sexta Conferencia Europea sobre Inteligencia Artificial (ECAI, European Conference on Artificial Intelligente), 2004.[0007] Las soluciones descritas en los anteriores documentos se proponen como herramientas para dar soporte a tareas de resolución de problemas tales como las que pueden llevarse a cabo por los empleados de una empresa de telecomunicaciones (para tratar las quejas de los clientes

o satisfacer las peticiones de clientes que demandan nuevos servicios) o incluso por el propio cliente, directamente implicado en actividades relacionadas con el cuidado autónomo de los equipos en sus instalaciones.[0008] En particular, el documento US-A-2004/0044542 describe un procedimiento y un sistema para adquirir y compartir el conocimiento 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 varios dominios, entre los cuales también se incluye el dominio de los servicios de telecomunicaciones, y proporcionar soporte a tareas de resolución de problemas, utilizando 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 conocimiento operacional (OKM), denominado como Remoter, utilizándose dicho sistema en un contexto de telecomunicaciones para dar soporte a los técnicos de una empresa de telecomunicaciones durante sus actividades diarias. En particular, Remoter se ha utilizado 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 un corto periodo de tiempo y elegir la mejor solución. La finalidad del sistema es permitir que los técnicos compartan, adquieran y apliquen su conocimiento operacional para tomar decisiones óptimas en tiempo real. Dicho sistema utiliza 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 agente y con un alto grado de flexibilidad y escalabilidad para una gestión distribuida de una red de telecomunicaciones y de los servicios soportados. Los puntos clave de dicha arquitectura son: -una plataforma para una gestión de red y de servicios basada en agentes distribuidos, asociada con motores de flujos 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) utilizados no solamente para la coordinación de los componentes (de las aplicaciones), sino también para una 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 proceso y los modelos de información de recursos de red que van a distribuirse a través de la plataforma para utilizarse en los motores de procesos;

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

-utilización de técnicas de movilidad de código que permiten una distribución práctica de las aplicaciones, incluyendo los aspectos de equilibrio de carga y de tolerancia a fallos.

[0011] El artículo de Stephen Corley et al., “Communications Management Process Integration Using Software Agents: A Specification of a Framework for Agent Oriented Workflow Management Systems”, EURESCOM PROJECT P815, [Online] enero de 2001, páginas 1 a 92, XP002343307, obtenido a través de la dirección de Internet: URL: http: //www.eurescom.de/-pub-deliverables/P800series/P815/D1/p815d1vo12.pdf, 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, en 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 satisfacer la solicitud. 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 y objetos Java.[0012] El documento US 5.826.239 se refiere a un sistema y procedimiento para una 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 la 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 recurso, manejadores de eventos y proxys de recursos.[0013] El artículo de W. Sull “A Distributed Environment for Enabling Lightweight Flexible Workflows”, 1998, actas de la trigésimo primera Conferencia Internacional Anual de Hawai sobre Ciencias de Sistemas, páginas 355 a 364, XP010263096, desvela un conjunto de componentes de arquitectura distribuidos independientes del dominio para aplicaciones de flujos de trabajo. Los componentes son responsables de aislar las aplicaciones con respecto a la tarea de comunicación con el gestor de flujo de trabajo y soportan una mayor flexibilidad y escalabilidad definiendo por separado componentes independientes del dominio y componentes específicos del dominio. Con los componentes propuestos pueden utilizarse aplicaciones distribuidas en un flujo de trabajo sin un conocimiento previo de las mismas, por lo que introducir una nueva aplicación en un conjunto de aplicaciones colaborativas será más sencillo. Objeto y resumen de la invención[0014] Se ha observado que los procedimientos utilizados en los sistemas descritos en los dos primeros documentos a los que se ha hecho referencia anteriormente (US-A2004/0044542 y el artículo de Valente y Rigallo) presentan límites en lo que respecta[0015] a las funciones ofrecidas, debido a tres deficiencias. [0016] 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 utilizando las ventajas relacionadas con, por ejemplo, la comprobación en tiempo real de la correcta ejecución de las tareas realizadas por el 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. [0017] En segundo lugar, no representan el conocimiento a compartir utilizando herramientas formales (tales como los flujos de trabajo) que permitirían una reducción en los tiempos de trabajo de los técnicos a través de una descripción clara y fácilmente inteligible 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 dar lugar a la ejecución de actividades inútiles

o incluso dañinas para la red en la que están llevándose a cabo. [0018] Finalmente, 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, que se obtienen utilizando procedimientos tales como el razonamiento conversacional basado en casos. Una guía completa permitirá tanto una reducción en los tiempos de trabajo de los técnicos como una inserción más rápida de técnicos que se añaden a la tarea.[0019] En lo que respecta al artículo de Corley et al. y al documento US 5.826.239, se señala que estos documentos describen soluciones para gestionar procesos de negocio y no para gestionar un conocimiento operacional. Por lo tanto, los flujos de trabajo se utilizan para representar y ejecutar modelos de negocio y no están destinados a representar el conocimiento operacional, requerido para llevar a cabo una tarea particular o una actividad específica, ofreciéndolo para su uso interactivo por parte de operadores y usuarios.[0020] Asimismo, en el marco de sistemas/plataformas para la gestión de red/servicios, se ofrecen soluciones avanzadas que contemplan arquitecturas distribuidas basadas en agentes.[0021] A ese respecto, la arquitectura descrita en el documento WO-A-2005/018249 mencionado anteriormente es extremadamente eficaz y eficiente en la gestión de red, pero no contempla que ninguna función KM/OKM dé soporte a actividades de los empleados de una empresa de telecomunicaciones. [0022] Por consiguiente, surge claramente la necesidad de disponer de soluciones innovadoras para la gestión de actividades operacionales que, superando las desventajas intrínsecas expuestas anteriormente, presenten algunas características funcionales importantes.[0023] Una primera de estas características es la posibilidad de una interacción automática y asistida con los sistemas/plataformas responsables de la gestión de red/servicios, lo cual tiene como finalidad permitir: -una 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;

-un 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;

-una ejecución automática de las etapas, consideradas estándar, de la actividad de un operador/ingeniero de asistencia in situ: 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 requeridos.

[0024] Una segunda característica deseable es que las sugerencias suministradas a los empleados deben representarse mediante herramientas formales (tales como flujos de trabajo) que tienen las siguientes ventajas: -descripción de las actividades que van a realizarse

con el fin de llevar a cabo de manera satisfactoria una intervención dada o tratar eficazmente una solicitud de cliente de una manera clara y fácilmente inteligible;

-indicación inmediata (por ejemplo, mediante

resultados apropiados) de las mejores prácticas; y -habilitación de una gestión más sencilla del

conocimiento relacionado con las actividades de

mejora y actualización posiblemente soportadas

también mediante mecanismos automáticos. [0025] Otra característica importante adicional ciertamente deseable es que el sistema debe poder indicar de manera autónoma y completa todas las etapas específicas requeridas para llevar a cabo una intervención dada (ingenieros de asistencia in situ) 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, que se obtienen utilizando procedimientos tales como razonamiento conversacional basado en casos. [0026] Debe indicarse específicamente que las plataformas de gestión actuales, a pesar de ir 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.[0027] Por lo tanto, existe la necesidad de disponer de soluciones que puedan superar estas limitaciones. Específicamente, existe la necesidad de disponer de una solución completa para dar soporte a los empleados que, empezando a partir de avanzadas arquitecturas de gestión flexibles y escalables, introduzca funciones OKM innovadoras, en función de una representación formal de las prácticas operacionales, y garantice una integración entre el funcionamiento y la gestión de red/servicios.[0028] Por lo tanto, el objeto de la invención es proporcionar una respuesta completamente satisfactoria a las necesidades anteriores, en particular para proporcionar una técnica eficaz que dé soporte a servicios de intervención humana en sistemas distribuidos, tales como una red de aparatos distribuidos en un territorio dado. [0029] Se ha descubierto que el objeto anterior se consigue proporcionando una arquitectura distribuida de gestión de operaciones que incluye una pluralidad de agentes proxy de gestión de intervenciones asociados con dispositivos terminales de operador o de usuario respectivos, comprendiendo cada agente proxy de gestión de intervenciones un motor de procesos adecuado para procesar flujos de trabajo o reglas que definen las instrucciones para realizar las intervenciones, y un sistema para gestionar y controlar el funcionamiento de los dispositivos terminales que incluye un recurso centralizado adecuado para proporcionar a los agentes proxy de estos dispositivos diferentes flujos de trabajo o reglas dependiendo del tipo de intervención.[0030] Según un aspecto de la presente invención, se proporciona una arquitectura distribuida de agentes proxy de gestión de intervención asociados con dispositivos terminales respectivos del operador o del usuario, estando configurados dichos agentes proxy de gestión de intervenciones para interactuar con medios de gestión (que comprenden preferiblemente agentes proxy de recursos) asociados con dispositivos adicionales (tales como equipos de red) para generar señales de instrucciones (en la forma de flujos de trabajo o reglas) para realizar intervenciones en los dispositivos, por lo que las señales de instrucciones son una función del estado de los dispositivos que requieren la intervención.[0031] El dispositivo terminal es preferiblemente un dispositivo portátil tal como un teléfono celular, un asistente personal digital (PDA, Personal Digital Assistant) o un ordenador portátil, que comprende un proxy de gestión de intervenciones dotado de un motor de procesos basado en flujos de trabajo o en reglas y una interfaz personal (PI, Personal Interface) para permitir la interacción con un operador o un usuario, y que está configurado preferiblemente para descargar flujos de trabajo o reglas desde un recurso remoto. El agente proxy también está dotado preferiblemente de una interfaz para la comunicación con una aplicación software en otro equipo, dispositivo o aparato con el fin de intercambiar información con la misma durante la ejecución del flujo de trabajo o de las reglas.[0032] Se ha descubierto que la arquitectura y el dispositivo terminal anteriores pueden aplicarse para realizar intervenciones en aparatos de una red distribuida, tal como una red de telecomunicaciones o una red de distribución de energía. Sin embargo, la invención puede aplicarse ampliamente en todos los escenarios en los que se solicite su funcionamiento (por ejemplo, para solucionar fallos) en aparatos, equipos o dispositivos de características predefinidas, de una manera sistemática, utilizando procesos predefinidos de una manera flexible y preferiblemente interactiva y manteniendo un control y una gestión centralizados de las operaciones.[0033] Por lo tanto, el término “intervención” debe interpretarse de manera genérica para incluir, por ejemplo, las interacciones entre los dispositivos terminales y los dispositivos externos, aparatos o equipos de diagnóstico, modificaciones de hardware/software u operaciones de comprobación.[0034] 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 y como se utiliza en este documento, la referencia a tal producto de programa informático se entiende como equivalente a la referencia a un medio legible por ordenador que contiene instrucciones para controlar un sistema informático con el fin de coordinar la ejecución del procedimiento según la invención. La expresión “al menos un ordenador” se utiliza para 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 descripción de la invención proporcionada en este documento. [0035] Una realización particular de la solución descrita en este documento es 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 comunicaciones en la que dichos equipos están asociados a agentes proxy de recursos, siendo cada uno responsable de gestionar un único equipo en dicha red, incluyendo el procedimiento las etapas de: -proporcionar una arquitectura distribuida de primeros

agentes proxy; -generar dichas señales de instrucción mediante dichos

primeros agentes proxy de una manera interactiva con

dichos agentes proxy de recursos, por lo que dichas

señales de instrucción son una función del estado del

equipo en dicha red en la que se realizan dichas

intervenciones. [0036] Según un primer aspecto de la misma, la presente invención se refiere por tanto a un sistema de operaciones distribuido según la reivindicación 1.[0037] En particular, los motores de procesos pueden ser motores basados en flujos de trabajo, motores basados en reglas o una combinación de ambos tipos. La elección puede depender del tipo de operaciones que vayan a realizarse. Por ejemplo, las funciones de soporte relacionadas con una intervención in situ de un operador se representan mejor como un diagrama de flujo, mientras que las funciones de soporte a diagnósticos relacionados con quejas, en el contexto de un centro de atención telefónica, se representan mejor mediante un conjunto de reglas. Sin embargo, siempre que sea posible y aconsejable, se prefiere la utilización de flujos de trabajo ya que evitan la complejidad de tratar conflictos de reglas y la gestión de reglas.[0038] El agente proxy comprende preferiblemente una interfaz de interconexión para el intercambio de información con una aplicación software de un dispositivo adicional durante el procesamiento de dichos flujos de trabajo o reglas.[0039] Dicha aplicación software de dicho dispositivo adicional comprende preferiblemente un motor de procesos basado en flujos de trabajo o basado en reglas, y dicho motor de procesos de dicho dispositivo terminal está configurado para interactuar con el motor de procesos de dicho dispositivo adicional mediante dicha interfaz de interconexión. [0040] Además, el sistema también comprende preferiblemente un gestor operacional que tiene funciones de gestión y de control de dichos agentes operacionales.[0041] Los agentes operacionales y/o el gestor operacional pueden incluir respectivos motores de procesos basados en flujos de trabajo o basados en reglas.[0042] Los agentes proxy de los dispositivos terminales pueden configurarse para interactuar directamente entre sí en una relación de interfuncionamiento. [0043] El sistema también puede incluir un repositorio de procesos definidos por flujos de trabajo o reglas. Además, el sistema puede incluir un repositorio de modelos de datos. [0044] El sistema también puede incluir agentes de control para distribuir los flujos de trabajo o las reglas a los dispositivos terminales.[0045] El sistema también puede incluir una base de datos de rendimiento para almacenar datos de rendimiento relacionados con el procesamiento de los flujos de trabajo

o las reglas.[0046] El sistema también puede incluir un registro operacional para almacenar procesos llevados a cabo por los agentes proxy.[0047] El sistema puede configurarse para gestionar las intervenciones en los equipos de red. En este caso, los flujos de trabajo o las reglas son preferiblemente una función del estado de los equipos de red en los que se realizan las intervenciones. [0048] Al menos uno de la pluralidad de dispositivos terminales puede ser de manera ventajosa un dispositivo portátil para permitir, por ejemplo, intervenciones in situ. [0049] Dicha aplicación software puede comprender un agente proxy. En este caso, el agente proxy de cada dicho dispositivo terminal puede configurarse para activar automáticamente una sesión de comunicaciones con el agente proxy de la aplicación software de dicho dispositivo adicional. [0050] La interfaz de usuario gestiona preferiblemente una interfaz gráfica.[0051] Cada dispositivo terminal puede configurarse para la activación del agente proxy mediante un usuario.[0052] Según un aspecto adicional de la misma, la presente invención se refiere a un procedimiento para gestionar intervenciones en equipos de usuario o de red según la reivindicación 21.[0053] El recurso de gestión puede comprender un segundo agente proxy asociado con dicho equipo de usuario o de red y que comprende un motor de procesos basado en flujos de trabajo o basado en reglas.[0054] Cada primer agente proxy puede estar asociado con un único dispositivo terminal y puede incluir un único motor basado en flujos de trabajo o basado en reglas.[0055] El procedimiento incluye preferiblemente la etapa de asociar a dichos primeros agentes proxy interfaces personales para representar al menos parte de dichas instrucciones y para interactuar con el flujo de trabajo o regla ejecutados.[0056] Las capas jerárquicas pueden incluir una capa que comprende un gestor operacional que tiene funciones de gestión y de control y que supervisa el funcionamiento de dichos agentes operacionales.[0057] Además, el procedimiento puede incluir la etapa de asignar a dichos agentes operacionales la ejecución distribuida de intervenciones sobre una pluralidad de dichos primeros agentes proxy.[0058] El procedimiento puede incluir la etapa de asignar, a cada uno dichos primeros agentes proxy, la tarea de dar soporte a un único operador o cliente, por lo que la ejecución de dichas intervenciones está desacoplada con respecto a dichas funciones de gestión y de control.[0059] Preferiblemente, el procedimiento también incluye la etapa de proporcionar motores de procesos a dichos primeros agentes proxy.[0060] El procedimiento también puede incluir la etapa de proporcionar motores de procesos a todas dichas capas en dicha arquitectura distribuida.[0061] Dichos motores de proceso se basan preferiblemente en flujos de trabajo o en reglas.[0062] El procedimiento incluye preferiblemente la etapa de incluir en dichas capas componentes adaptados para realizar funciones respectivas basadas en información de instrucción respectiva proporcionada a los mismos.[0063] El procedimiento también puede incluir la etapa de proporcionar en dicha información de instrucción al menos uno de los siguientes elementos: -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. [0064] Preferiblemente, el procedimiento incluye la etapa de configurar dichos primeros agentes proxy para interactuar directamente entre sí en una relación de interfuncionamiento, por lo que al menos una de dichas señales de instrucción se produce mediante la interacción entre primeros agentes proxy.[0065] El procedimiento también puede incluir la etapa de configurar dichos primeros agentes proxy para una interacción de igual a igual con dichos agentes proxy de recursos. [0066] El procedimiento puede incluir la etapa adicional de proporcionar agentes de control asociados a al menos una capa de dicha arquitectura distribuida para realizar al menos una etapa seleccionada del grupo que consiste en: -distribuir definiciones de proceso 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.[0067] El procedimiento también puede incluir la etapa de proporcionar un recurso de gestión remoto para realizar al menos una etapa seleccionada del grupo que consiste en: -gestionar la distribución de definiciones de procesos

a dichas capas de dicha arquitectura distribuida mediante dichos agentes de control;

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

-supervisar el estado de dichas capas de dicha

arquitectura distribuida mediante dichos agentes de

control. [0068] La presente invención también se refiere a 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 el procedimiento anterior. Breve descripción de los dibujos adjuntos[0069] A continuación se describirá la invención, solamente a modo de ejemplo, con referencia al conjunto de dibujos adjuntos, en los que:

Figura 1. Diagrama de bloques funcional que ilustra una posible realización de una plataforma descrita en este documento. Figura 2. Otro diagrama de bloques funcional que representa la gestión de operaciones en la plataforma de la Figura 1.Figura 3. Diagrama de flujo de un primer procedimiento realizado en la solución descrita en este documento. Figura 4. Ejemplo de un flujo de trabajo generado por la solución descrita en este documento.Figuras 5 a 7. Diagramas de flujo de procedimientos adicionales realizados en la solución descrita en este documento. Figura 8. Ilustra esquemáticamente un dispositivo portátil que se utilizará en la plataforma de las Figuras 1 y 2.

Descripción detallada de realizaciones preferidas de la invención [0070] Con el fin de facilitar un entendimiento correcto de los principios subyacentes de la invención, a continuación se presenta un glosario que explica algunos términos/acrónimos utilizados en esta descripción y en las reivindicaciones adjuntas.

[0071] WFM (gestión de empleados, Work Force Management): en el contexto de una empresa de telecomunicaciones, es la aplicación software/conjuntos de aplicaciones software responsable(s) de gestionar los empleados de dicha empresa. En el contexto específico de interés se entiende como la aplicación/conjunto de aplicaciones utilizada(s) para gestionar tanto los empleados móviles (ingenieros de asistencia in situ) y los empleados de un centro de atención telefónica. [0072] Operador: es un miembro del personal de la compañía que forma parte de la plantilla, el cual se clasifica como empleado móvil (ingeniero de asistencia in situ), como empleado especializado (personal de servicios internos) y como asesor de un centro de atención telefónica. [0073] Módulo de gestión -MM: es una aplicación software que se ejecuta en un ordenador central que se comunica con los agentes distribuidos para varias 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. [0074] Agente: 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 con el fin de cumplir con sus tareas. Esta comunicación puede implementarse a través de un intercambio de mensajes asíncrono y utilizando lenguajes ampliamente conocidos (por ejemplo, el lenguaje de comunicación entre agentes, ACL) con una semántica bien definida y comúnmente acordada.[0075] Proxy: 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 dar soporte a una operación.[0076] Regla: una regla es un esquema para generar inferencias válidas. Estos esquemas establecen relaciones sintácticas de la forma "si <x> entonces <y> si no <z>” entre un conjunto de fórmulas denominadas premisas, que forman la parte “si”, y una aseveración denominada como una conclusión, que forma la parte “entonces”. La parte “si no” es opcional. Estas relaciones sintácticas se utilizan en el proceso de inferencia, por lo que se llega a nuevas aseveraciones verdaderas a partir de otras ya conocidas. [0077] Motor de reglas (o motor basado en reglas): 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 utiliza para decidir, en tiempo de ejecución, qué reglas aplicar y cómo ejecutar las mismas.[0078] Flujo de trabajo: puede definirse como la automatización de un proceso, en su totalidad o en parte, durante el cual se transmiten documentos, información o tareas desde un participante a otro para realizar una acción según un conjunto de reglas de procedimiento (Terminología & Glosario, WFMC-TC-1011, febrero de 1999, 3.0). Un flujo de trabajo puede representarse a través de un diagrama de flujo 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.[0079] Motor de flujos de trabajo (o motor basado en flujos de trabajo): es el componente que posee toda la información relacionada con los procedimientos (flujos de trabajo), etapas en 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. Dicho de otro modo, un motor de flujo de trabajo es un componente para ejecutar flujos de trabajo.[0080] El diagrama de bloques de la Figura 1 representa una realización preferida de una plataforma integrada que comprende una plataforma para la gestión distribuida de una red de telecomunicaciones y de servicios relacionados, tal y como se describe en el documento WO-A-2005/018249, y una plataforma para una gestión de operaciones distribuida. [0081] 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)(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 maestro, designada como 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 varias aplicaciones agente, una de las cuales se muestra y está designada como 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 usual de un componente de inventario de red y es la recopilación de todas las virtualizaciones (imágenes) del recurso en la red N; se actualiza periódicamente recuperando información de los RP. Detalles adicionales relacionados con la plataforma de gestión de red/servicios pueden obtenerse del documento WO-A-2005/018249.[0082] Tal y como se introduce en la Figura 1 y se presenta en mayor detalle en la Figura 2, la plataforma de gestión de operaciones comprende un gestor operacional OM (Operational Manager) que interactúa con el bus y que actúa conjuntamente con un inventario de destrezas (EI, Expertise Inventory) y con 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 asistencia in situ, personal de servicios internos, asesores de centros de atención telefónica o clientes. [0083] 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 operaciones 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 y como se describe a continuación. [0084] En una realización preferida, los PP se comunican entre sí y también están conectados de manera ventajosa a los proxys de recursos RP (utilizando el lenguaje ACL), tal y como se indica esquemáticamente por la flecha de dos sentidos PTP en la Figura 1. Esto representa normalmente 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, por lo que estas señales de instrucción dependen del estado del equipo en el que se ejecuta una intervención. Los expertos en la técnica 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 completamente y meramente indicativa, y que puede concebirse que cada una de estas entidades pueda estar presente en cualquier número.[0085] 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 las instalaciones del cliente). La imagen es una representación de la configuración del equipo según un modelo de datos definido. [0086] 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.[0087] 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, agentes operacionales y gestor operacional) incluye preferiblemente uno o más agentes de control CA, que son los módulos de software responsables de controlar y gestionar la plataforma.[0088] Tal y como se ha señalado, 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 operacional ODB (operational data base) es el único punto (lógico) de definición y almacenamiento de todos los aspectos funcionales y de los aspectos de gestión/soporte de los empleados y clientes, con relación a la plataforma. La ODB es el repositorio de las descripciones de procesos (donde una descripción de proceso es un flujo de trabajo o una regla) y de las definiciones de modelos de datos que se utilizan por los componentes de la plataforma para gestionar las operaciones (PP, OA y OM).[0089] Un módulo de gestión MM (Manager Module) distribuye mediante los agentes de control CA (Control Agents) las definiciones de procesos y las definiciones de modelos de datos a los componentes de gestión de operaciones. En primer lugar, esto permite ofrecer las prácticas operacionales más eficaces y efectivas (mejores prácticas) a todos los empleados y a los clientes. Además, a través de la difusión de las definiciones de modelos de datos se permite la coordinación entre los empleados, permitiendo de esta manera una identificación sencilla y rápida de los expertos a los que se recurrirá para obtener soporte sobre un asunto específico. Asociada con la base de datos ODB hay una GUI proporcionada intencionadamente para permitir su rellenado.[0090] La base de datos de modelos MDB (Model Data Base) almacena todas las descripciones de proceso (flujos de trabajo y reglas) y los modelos de los datos procesados (incluyendo los modelos de los equipos de red) que se utilizan por los componentes de la plataforma para la gestión de red/servicios (RP, AA y MA, tal y como se muestra en la Figura 1).[0091] La MDB proporciona a los usuarios un único punto en el que definir y administrar las funciones de la plataforma en lo que se refiere a aspectos de gestión de red/servicios.[0092] En una realización preferida, con el fin de definir los modelos de datos almacenados en las bases de datos ODB y MDB, se utiliza 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).[0093] 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 utiliza tanto para optimizar la utilización de recursos como para identificar la mejor práctica.[0094] Finalmente, 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.[0095] En una realización preferida, los procesos operacionales de la plataforma están segmentados en tres capas con funciones específicas. Esta opción está destinada a cumplir 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 modalidad centralizada. Esto implica la presencia de una capa 1 centralizada (o capa más alta, que corresponde al gestor operacional OM) y de una capa 2 totalmente distribuida (o capa intermedia, que corresponde a los agentes operacionales OA1, …, OAk), más una capa 3 de proxys independientes (o capa inferior, 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 y como se explicará posteriormente, los componentes PP, OA y OM están adaptados para realizar funciones respectivas basadas en 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.[0096] Cada proxy personal PP (en lo sucesivo, por motivos de brevedad, se omitirá 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 dar soporte a las actividades de un operador específico o de un cliente específico, tanto en lo que respecta al guiado en las diversas actividades operacionales como al soporte para la cooperación (entre diferentes operadores o entre operadores y clientes). En particular, el soporte para 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 que proviene 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.[0097] Dicho de otro modo, cada proxy personal tiene el papel de un agente proxy de gestión de intervenciones. Cada proxy personal (PP) ejecuta procesos típicos del nivel PP correspondiente utilizando 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 capa 3 constituyen los servicios que el PP ofrece a la capa superior (normalmente el agente operacional, y posiblemente otras aplicaciones externas) a través de 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 (encaminador, DSLAM, etc.), etc.; cada uno de los mismos puede incluir secuencias de actividades que se realizan en uno o más equipos. Los procesos de la capa inferior de capa 3 utilizan los servicios ofrecidos por las interfaces personales PI.[0098] 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 mediante 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 mediante sistemas externos (WFM y BSS). Nuevamente, la instanciación se realiza de una manera flexible utilizando un motor de proxy PE (Proxy Engine). De esta manera, cambios y adiciones de modelos de datos (tales como la actualización del perfil de operador/cliente, la introducción de nuevos tipos de operador, etc.) no requieren ningún cambio de software apreciable en los componentes de la plataforma, consiguiendo un alto grado de flexibilidad.[0099] Los datos de los perfiles de operador y de los perfiles de cliente se almacenan en el inventario de destrezas EI, el cual se actualiza periódicamente por el OM utilizando 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 y como se ha mencionado anteriormente, los cambios en los datos de perfil también se comunican a los proxys personales PP pertinentes.[0100] 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 un conocimiento dado y/o que tratan problemas comunes. Los equipos virtuales pueden, en general, organizarse en función de una subdivisión geográfica de los empleados con el fin de mejorar la eficacia de la resolución del problema y para optimizar las intervenciones in situ.[0101] Los proxys personales PP pueden interactuar directamente entre sí para dar soporte a la cooperación entre operadores o entre operadores y clientes, por ejemplo, para reparar un fallo complicado. Preferiblemente, los proxys personales PP también se comunican 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 ejecuciones satisfactorias, en el equipo, o 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 gestionar las interacciones entre los proxys personales y los operadores (empleados) o clientes, independientemente del tipo de dispositivo terminal que utilicen para dar soporte a sus actividades de trabajo.[0102] El dispositivo terminal puede ser de diferentes tipos, dependiendo del uso particular para el que esté diseñado. La Figura 8 muestra esquemáticamente un dispositivo terminal TD según la presente invención, que comprende un proxy personal PP, que a su vez comprende un motor de procesos PE basado en flujos de trabajo o basado en reglas. También se representa esquemáticamente la interfaz personal PI, compuesta por una pluralidad de objetos WI (componentes gráficos con los que interactúa un usuario) que permiten la interacción entre un usuario u operador y los flujos de trabajo o reglas ejecutados por el motor de procesos PE. El flujo de trabajo o la regla ejecutados por el motor de procesos (PE) es responsable de mostrar los objetos con los datos correctos. De esta manera, la interacción con los usuarios se controla completamente mediante los flujos de trabajo o las reglas ejecutados en el dispositivo terminal.[0103] El dispositivo terminal también incluye una interfaz de interconexión IN (interconnection interface) proporcionada por el proxy personal PP para la interconexión con una aplicación software de un aparato de red NA (network apparatus) para intercambiar información con la misma. Preferiblemente, la aplicación software es un proxy de recursos RP dotado de un motor de procesos PE basado en flujos de trabajo o basado en reglas. Según un aspecto de la presente invención, el dispositivo terminal es un dispositivo portátil, tal como un PDA, un ordenador portátil o un teléfono celular, por lo que es particularmente adecuado para intervenciones en situ por parte de ingenieros de asistencia in situ. Como alternativa, el dispositivo terminal puede ser un dispositivo fijo, tal como un ordenador de escritorio, como el utilizado normalmente por los empleados de un centro de atención telefónica. [0104] Cada PI ofrece, como servicios para los proxys personales, la gestión de la GUI hacia el operador/cliente, incluyendo la configuración automática de la GUI en función del tipo de dispositivo disponible.[0105] Cada agente operacional OA es responsable de coordinar un conjunto de PP y de ejecutar procesos típicos de capa 2 utilizando 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 capa 2 pueden invocarse de manera externa; por lo tanto, son 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 utilizan los servicios (es decir, invocan procesos) ofrecidos por el proxy personal PP. [0106] Un agente operacional OA no requiere actualización de software para soportar nuevas prácticas operacionales. Esto se debe a la flexibilidad de los procesos (basados en flujos de trabajo o basados en reglas) que se reciben desde el módulo de gestión MM, mediante el 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 soportar la ejecución distribuida de actividades operacionales correlacionadas entre sí tales como, por ejemplo, la creación de un circuito que necesite equipos situados en emplazamientos distribuidos geográficamente.[0107] 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 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 sencilla 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.[0108] Los motores de procesos PE para cualquier capa están destinados a ser un motor de flujos de trabajo (es decir, un diagrama de flujo), 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 diagrama de flujo, mientras que las funciones de soporte a diagnósticos relacionados con quejas, 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 la utilización de flujos de trabajo ya que evitan la complejidad de tratar conflictos de reglas y la gestión de reglas.[0109] Según la presente invención, cada proxy personal PP comprende un motor de procesos. Preferiblemente, los agentes operacionales OA también comprenden motores de procesos. Más preferiblemente, el gestor operacional OM también comprende un motor de procesos. Por lo tanto, los motores de procesos se utilizan preferiblemente por cada componente de las capas jerárquicas de la plataforma y, si es posible, se asignan al mismo ordenador central en el que reside el propio componente con el fin de mejorar los niveles de rendimiento: el gestor operacional OM, los agentes operacionales OA y los proxys personales PP tienen un comportamiento que es tanto reactivo como proactivo, reaccionando ante eventos pero también iniciando procesos de manera espontánea.[0110] 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, finalmente, 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.[0111] 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, de equilibrio de carga y de 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. Con el fin de supervisar el rendimiento, los componentes de la plataforma deben poder supervisar además 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 es útil también en una perspectiva de identificación de la mejor práctica.[0112] Tal y como se ha mencionado anteriormente, la solución descrita en este documento tiene como objetivo gestionar y dar soporte a las operaciones de los empleados y de los clientes. Esto se consigue a través de un conjunto de servicios que se ofrecen a los operadores/clientes.[0113] Con referencia al marco eTOM (documentos: TeleManagementForum GB921 y GB921D, versión 4.0, marzo de 2004, y versión 5.0 en evaluación de miembros, 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 los siguientes grupos de procesos de extremo a extremo verticales de nivel 1: -gestión del ciclo de vida de infraestructura (área de

procesos: estrategia, infraestructura y producto);

-soporte y disponibilidad de operaciones (área de

procesos: operaciones); -cumplimiento (área de procesos: operaciones); -certeza (área de procesos: operaciones);[0114] Considerando ahora la dimensión horizontal del marco eTOM, los grupos de procesos funcionales horizontales de nivel 1 en los que están las actividades de los operadores y de 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).[0115] La gestión y compartición del conocimiento operacional con expertos y clientes puede estar, a su vez, en el área de procesos denominada como gestión de empresa y, en particular, en el grupo de procesos de nivel 1 conocido como gestión de conocimiento y de investigación.[0116] El diagrama de flujo de la Figura 3 muestra, a modo de ejemplo, un procedimiento para dar soporte a ingenieros de asistencia in situ.[0117] 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; las formas operacionales con las que la plataforma ofrece dicho servicio con referencia a ingenieros de asistencia in situ se presentan en la Figura 3 y se describen a continuación.[0118] Después de que el ingeniero de asistencia in situ haya seleccionado la intervención que ha de llevarse a cabo (etapa 100), el proxy personal asociado con él muestra (etapa 110) en el dispositivo terminal del ingeniero de asistencia in situ, utilizando 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 tareas relacionada, por ejemplo, con actividades de suministro o funcionamiento (tales como actualizaciones de bases de datos, etc.). En el dispositivo del ingeniero de asistencia in situ 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 asistencia in situ realice la intervención específica, incluyendo posibles datos específicos relacionados con la propia intervención, tales como los requeridos para identificar el componente de un equipo sobre el que va a actuarse: por ejemplo, si una etapa de un flujo de trabajo guía al ingeniero de asistencia in situ en la actividad de cambiar una tarjeta de un equipo, dicha etapa también contiene la indicación que permite al ingeniero de asistencia in situ identificar de una manera sencilla y única la tarjeta que va a cambiarse. Cada flujo de trabajo se presenta indicando además el resultado que se ha asignado al mismo y que refleja una evaluación comprobada de la eficacia y eficiencia del propio flujo de trabajo con el fin de 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).[0119] Antes de decidir si seleccionar uno de los flujos de trabajo indicados, el ingeniero de asistencia in situ 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 implica un intercambio de información entre el proxy personal PP y el proxy de recursos RP, donde la solicitud del ingeniero de asistencia in situ se reenvía desde el proxy personal PP hasta el proxy de recursos RP y la respuesta correspondiente se envía por el proxy de recursos RP al proxy personal PP, presentándose en el dispositivo terminal del ingeniero de asistencia in situ utilizando la interfaz PI (toda la actividad corresponde a la etapa 120).[0120] Además, el ingeniero de asistencia in situ también puede solicitar que se muestren uno o más de los flujos de trabajo propuestos (etapa 130) para disponer de más información antes de decidir cómo proceder. Después, el ingeniero de asistencia in situ puede 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).[0121] Después de la activación de un flujo de trabajo, se inicia un proceso de registro de todas las actividades realizadas por el ingeniero de asistencia in situ (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 para generar y validar nuevos flujos de trabajo.[0122] En paralelo a la activación del flujo de trabajo en el proxy personal PP, un flujo de trabajo cooperativo que actúa conjuntamente con el del proxy personal puede activarse en el proxy de recursos RP que gestiona el equipo en el que el ingeniero de asistencia in situ debe actuar (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 proporcionan algunos ejemplos de

intercambios de información.

[0123] Por tanto 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 asistencia in situ 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 asistencia in situ, 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 asistencia in situ (en caso de fallo, comprobación de su reparación, en caso de orden de tarea de suministro, comprobación de la correcta ejecución de las actividades de configuración solicitadas).

[0124] Después de que el ingeniero de asistencia in situ

haya recibido mediante el proxy personal PP la indicación,

que proviene 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 asistencia in situ

puede seleccionar una intervención posterior.

[0125] En caso de que un ingeniero de asistencia in situ decida no seleccionar ninguno de los flujos de trabajo propuestos para él, o si no existe ningún flujo de trabajo asociado con la intervención que va a realizarse, el ingeniero de asistencia in situ 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 además un acceso remoto a la interfaz de línea de comunicaciones (CLI, Communication Line Interface) del equipo. Esto se realiza como soporte 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 asistencia in situ se registran (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.[0126] 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.[0127] La Figura 4 presenta un ejemplo de un 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 que tiene como objetivo guiar al ingeniero de asistencia in situ en una actividad de sustitución de una tarjeta de un equipo.[0128] El ingeniero de asistencia in situ, después de haber elegido el flujo de trabajo a activar según los criterios descritos anteriormente, requiere la activación, mediante la interfaz PI, del flujo de trabajo seleccionado en el proxy personal PP (etapa 1100).[0129] El flujo de trabajo en el extremo de proxy personal PP se inicia (etapa 300) y, como primera acción, activa el flujo de trabajo cooperativo relacionado en el proxy de recursos RP (etapas 310 y 500). Al ingeniero de asistencia in situ se le envía un mensaje en su dispositivo terminal, utilizando la PI, para que espere la activación del flujo de trabajo RP (etapa 1110).[0130] El flujo de trabajo de proxy personal PP procede con las actividades preliminares a la sustitución de la tarjeta, indicando al ingeniero de asistencia in situ las instrucciones para abrir el equipo (etapa 320) mediante la descripción en el dispositivo terminal del ingeniero de asistencia in situ, utilizando 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 a través de la pantalla del dispositivo terminal del ingeniero de asistencia in situ, utilizando la interfaz PI (etapa 1130), y también además mediante la ayuda de esquemas que facilitan la identificación de la tarjeta.[0131] Al mismo tiempo, el flujo de trabajo del proxy de recursos RP procede con las actividades de gestión introductorias a la sustitución de la tarjeta (etapa 510) tales como, por ejemplo, la desactivación o cambio de servicios todavía activos en la misma o hacer pasar la tarjeta a 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).[0132] El flujo de trabajo de proxy personal PP informa al ingeniero de asistencia in situ que desconecte el cableado de la tarjeta que está sustituyéndose (etapa 340), presentando información útil para la actividad manual en el dispositivo terminal del ingeniero de asistencia in situ, utilizando 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) tal como, por ejemplo, comprobar si los puertos físicos implicados señalizan el estado de cableado desconectado. Cuando se haya desconectado todo el cableado de la tarjeta que va a sustituirse, el flujo de trabajo de proxy de recursos RP informa al flujo de trabajo PP (etapa 530).[0133] El flujo de trabajo de proxy personal PP procede con la comprobación de si la tarjeta está lista para extraerse 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 asistencia in situ que verifique la señal de tarjeta liberada (etapa 1150).[0134] 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 asistencia in situ las actividades manuales que han de realizarse (etapa 1160), tales como palancas de desenganche que han de activarse e indicaciones de las acciones para extraer la tarjeta.[0135] 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) tales como, por ejemplo, el estado de ranura libre, e informa al flujo de trabajo del proxy personal PP cuando la tarjeta ya no está presente.[0136] El flujo de trabajo de proxy personal PP, después de haber recibido los mensajes de finalización de las actividades tanto del flujo de trabajo del proxy personal PP como del ingeniero de asistencia in situ mediante 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 alflujo de trabajo de proxy de recursos RP. Éste último 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 informar al flujo de trabajo de proxy personal PP de la correcta inserción de la nueva tarjeta (etapa 570).[0137] 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 asistencia in situ, mediante la interfaz PI, sobre la comprobación en curso (etapa 1180).[0138] 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 asistencia in situ en su dispositivo terminal, utilizando la interfaz PI, de las actividades manuales que han de realizarse (etapa 1190) con la ayuda de esquemas relacionados con el tipo de tarjeta y cableado.[0139] 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) tal como, por ejemplo, la reactivación de los servicios o su transición desde la configuración temporal ejecutada anteriormente (etapa 510).[0140] 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 asistencia in situ a través de la interfaz PI (etapa 1200) de que dicha actividad todavía está en curso. Una vez que haya finalizado 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 asistencia in situ a llevar a cabo el cierre de la carcasa del equipo (etapa 410) proporcionando información apropiada en el dispositivo terminal del ingeniero de asistencia in situ utilizando la interfaz PI (etapa 1210).[0141] Finalmente, el flujo de trabajo de proxy personal PP completa su ejecución (etapa 420) informando al ingeniero de asistencia in situ que está esperando la finalización 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 para el ingeniero de asistencia in situ de que la intervención ha concluido de manera satisfactoria (etapa 1230).[0142] En cambio, la Figura 5 ilustra un ejemplo de procedimiento para dar soporte a asesores de un centro de atención telefónica: de hecho, la solución descrita en este documento también permite aplicar el servicio de guiado a asesores de un centro de atención telefónica.[0143] Después de que el centro de atención telefónica haya recibido la queja de un cliente (denominada en lo sucesivo como notificación de problema: TR (Trouble Report)) o una solicitud de un nuevo servicio (denominada en lo sucesivo como orden de cliente: CO (Customer Order)) (etapa 1300), el proxy personal PP asociado con el asesor del centro de atención telefónica abre una sesión con el (los) proxy(s) de recursos RP asociado(s) con los equipos de red de interés para la solicitud de cliente y recopila información requerida para su interacción con el cliente (en caso de una notificación de problema se comprueba si hay fallos en los equipos implicados en la oferta de servicios de cliente) (etapa 1310).[0144] Después de recopilar 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 queja de un cliente (comprobación realizada en la etapa 1330), los datos recopilados se procesan con el fin de 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 para un nuevo servicio (comprobación realizada en la etapa 1330), la siguiente etapa es la creación de una orden de tareas (WO, Work Order) (etapa 1420).[0145] Después de recopilar 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), utilizando la interfaz PI correspondiente, una secuencia de preguntas destinadas a adquirir detalles adicionales sobre la TR/OC del cliente. En caso de una notificación de problema, dichas preguntas también pueden ser solicitudes para que el cliente realice comprobaciones/acciones puntuales que pueden dar lugar a la resolución del problema que es la causa de la notificación de problema, por ejemplo, solicitudes para verificar si todo el cableado de un equipo en las instalaciones del cliente (CPE, Customer Premise Equipment) está conectado adecuadamente y proceder con la correcta conexión del cableado en que se han detectado fallos de conexión. [0146] El asesor del centro de atención telefónica, interactuando con el cliente, proporciona al proxy personal PP respuestas apropiadas a las preguntas que le hacen (etapa 1350). En caso de que el cliente no pueda proporcionar los datos solicitados o con el fin de 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 que le interesa al 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 último al operador a través de la interfaz PI (toda la actividad corresponde a la etapa 1360).[0147] Al final de la secuencia de preguntas o en caso de una notificación de problema, después de la solución de la propia notificación 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.[0148] En caso de una notificación de problema (comprobación realizada en la etapa 1370) 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, utilizando un sistema basado en reglas, formula una primera hipótesis sobre la causa principal de la notificación de problema (etapa 1380).[0149] Si el cliente puede reparar el fallo (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 la notificación de problema (etapa 1400). Después, el asesor del centro de atención telefónica puede pasar a ejecutar otras actividades, siendo informado al mismo tiempo sobre el resultado de la ejecución del flujo de trabajo por parte el cliente.[0150] Tras 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 de la notificación de problema; en caso contrario, contendrá información útil para crear una o más solicitudes de tareas WR (Work Request) para los ingenieros de asistencia in situ).[0151] Si el cliente no puede resolver el fallo (comprobación realizada en la etapa 1390), la siguiente etapa es la creación de un resguardo de problema (etapa 1420). Después de recopilar los datos de la notificación de problema/orden de cliente y, en caso de una notificación de problema, después del diagnóstico de primer nivel y/o de la solución de la notificación 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 tareas que, en caso de una solicitud de cliente no satisfecha todavía, generará una o más solicitudes de tareas WR para los ingenieros de asistencia in situ (etapa 1420). Después de la creación de la TT/WO, la actividad del asesor del centro de atención telefónica finaliza (etapa 1430).

[0152] En cambio, el diagrama de flujo de la Figura 6 se refiere a un procedimiento para dar soporte a los clientes; el soporte para la ejecución de actividades operacionales descritas en este documento también se aplica al cliente.[0153] Después de que un cliente haya detectado un fallo (etapa 700), el propio cliente activa en su dispositivo (normalmente un PC o un PDA) el proxy personal PP asociado con él (etapa 710).[0154] El proxy personal PP abre una sesión con el (los) proxy(s) de recursos RP asociado(s) con los equipos ubicados en las instalaciones del cliente con el fin de identificar cualquier posible fallo en dichos equipos (etapa 720). En caso de que no haya fallos en los equipos en las instalaciones del cliente (comprobación realizada en la etapa 730), el proxy personal PP muestra en el dispositivo del cliente (etapa 740), utilizando la interfaz PI correspondiente, una secuencia de preguntas destinadas a adquirir más detalles sobre el fallo detectado. El cliente proporciona al proxy personal PP las respuestas apropiadas a las preguntas que se le hacen (etapa 750).[0155] Al final de la secuencia de preguntas, el proxy personal PP comprueba si se ha identificado la causa del error y si dicha causa puede repararse 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.[0156] Al final del flujo de trabajo el cliente realiza una comprobación acerca de la reparación del fallo (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 contacte con el centro de atención telefónica (etapa 800); después de la notificación por parte del proxy personal PP, la actividad del cliente termina (etapa 810). Si la causa del fallo no se ha identificado o si el cliente no puede solucionarlo (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).[0157] En caso de que haya fallos en equipos en las instalaciones del cliente (comprobación realizada en la etapa 730), el proxy personal PP lleva a cabo una comprobación adicional para verificar si el cliente puede reparar dichos fallos (comprobación realizada en la etapa 820). En caso de 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). En caso de un resultado positivo, el proxy personal PP activa un flujo de trabajo apropiado (etapa 770) que guía al cliente en la resolución del problema.[0158] Después de la activación del flujo de trabajo apropiado, 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 se ha mencionado anteriormente, puede procesarse con el fin de refinar flujos de trabajo existentes o para generar y validar nuevos flujos de trabajo. Al final de flujo del flujo de trabajo, el cliente comprueba si se ha reparado el fallo (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); después de la notificación por parte del proxy personal PP, la actividad de cliente termina (etapa 810).[0159] Los flujos de trabajo ejecutados en el proxy personal PP del cliente contemplan normalmente que también se informe al cliente sobre posibles acciones llevadas a cabo de manera automática por los proxys de recursos RP y que se le pueda conceder un consentimiento explícito de su ejecución.[0160] El diagrama de flujo de la Figura 7 ilustra un procedimiento de cooperación entre operadores. De hecho, la plataforma descrita en este documento proporciona un servicio adicional para dar soporte 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.

[0161]: A continuación se describen las prácticas

operacionales adoptadas para la interacción entre operadores.[0162] El proxy personal PP decide de manera autónoma (por ejemplo, después de la detección de una intervención que no haya sido satisfactoria en caso de ingenieros de asistencia in situ) o tras una notificación del operador, activar una sesión con los proxys personales PP de otros operadores (etapa 1500).[0163] En caso de una activación automática (comprobación realizada en la etapa 1510), el proxy personal PP, basándose en el conocimiento del tipo de actividad que el operador está realizando (inferido a partir de los datos disponibles u obtenido a partir de una indicación explícita del operador) y en las macrohabilidades requeridas para llevarla a cabo, intenta activar una sesión utilizando una lista ordenada de nombres de operadores con los que ponerse en contacto, organizados según las macrohabilidades (etapa 1600).[0164] 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 seguir, el proxy personal PP hace otro intento para activar una sesión con el siguiente nombre de la lista (etapa 1600) 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 1590).[0165] 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 ofrece un conjunto de herramientas para un trabajo cooperativo, tal como haciendo visible para ambos operadores todos los datos sobre la actividad que va a llevarse a cabo y sobre las etapas ya realizadas o para compartir posibles datos de red que el operador, que ha solicitado el soporte, ya ha adquirido (etapa 1620).[0166] Tras la notificación del operador, el proxy personal PP procede después con el cierre de la sesión (etapa 1570).[0167] En caso de activación bajo solicitud por parte del operador (comprobación realizada en la etapa 1510), el proxy personal PP, basándose en el conocimiento del tipo de actividad que el operador está llevando a cabo (inferido a partir de los datos disponibles u obtenido 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 automáticamente), entre los que el operador selecciona el nombre deseado (etapa 1530).[0168] Después de que el operador haya seleccionado el nombre, 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 seguir, 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).[0169] 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 ofrece un conjunto de herramientas para un trabajo cooperativo del tipo ya considerado anteriormente (etapa 1560). Tras la notificación del operador, el proxy personal procede después con el cierre de la sesión (etapa 1570).[0170] La interacción entre clientes y operadores utiliza mecanismos similares a los mencionados 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, bajo solicitud del propio cliente o de manera autónoma, establezca 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 una 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.[0171] Con el fin de ofrecer los servicios ejemplificados anteriormente, la plataforma descrita mantiene un conjunto de datos de los operadores, de los clientes y de 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, borrado de flujos de trabajo relacionados con actividades en equipos que ya no están en la red, etc.) como a cambios en las características y en el número de empleados (introducción de nuevos operadores, actualización de los datos de los perfiles de operador, etc.) y de clientes (introducción de nuevos clientes, actualización de los datos de los perfiles de cliente, etc.).[0172] Los perfiles de operador se definen en función de 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 el nivel de pericia del operador en un campo dado). El perfil también señala si el operador es un ingeniero de asistencia in situ 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 la 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 el que está asociado (cada proxy personal PP está asociado a un operador específico): el OM adquiere los datos de dicho perfil interactuando con sistemas externos apropiados (sistemas WFM); por tanto, la plataforma contempla 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). Tras 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.[0173] Los perfiles de cliente se definen en función de 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 acordado; 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 lleva a cabo en el momento apropiado 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 con el que está asociado (cada proxy personal PP está asociado a un cliente específico): el gestor operacional OM adquiere los datos de dicho perfil interactuando con sistemas externos apropiados (sistemas de soporte de negocio); por tanto, la plataforma contempla 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). Tras la activación de cada proxy personal PP, los datos de 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.[0174] En lo que respecta a flujos de trabajo que dan soporte a las operaciones de los ingenieros de asistencia in situ, 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 al que se aplica el flujo de trabajo (por ejemplo, fallo, actividades de suministro, actividades de funcionamiento, etc.), el identificador de la intervención específica que va a 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 asistencia in situ experto e ingeniero de asistencia in situ novato), etc. Dichas características se proporcionan cuando se crea/modifica el flujo de trabajo; el resultado se actualiza dinámicamente, según lo que se menciona posteriormente. La creación/modificación de los flujos de trabajo que dan soporte a las operaciones, 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 una edición en paralelo de los dos flujos de trabajo correlacionados con el fin de facilitar comprobaciones de congruencia en lo que se ha procesado.[0175] Consideraciones similares se aplican en lo que respecta a los flujos de trabajo que dan soporte a operaciones de cliente: la base de datos ODB mantiene, para cada flujo de trabajo que da soporte al cliente, un conjunto de características similares a las de los flujos de trabajo para el ingeniero de asistencia in situ y también aplicables al caso del cliente.[0176] Para los flujos de trabajo que dan soporte a los ingenieros de asistencia in situ se contemplan dos funciones de gestión.[0177] 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 con el mismo. Tras 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 tras una solicitud explícita del propio proxy personal PP: después de la suposición de una actividad dada por parte de un ingeniero de asistencia in situ y de la selección realizada por éste de un flujo de trabajo que va a llevarse a cabo o va a 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, se descarga desde la base de datos ODB mediante el agente de control CA; el flujo de trabajo permanecerá almacenado en el proxy personal PP para cualquier posible uso futuro.[0178] De manera similar, tras 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 tras una solicitud explícita 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 que dé soporte a una 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. [0179] Por tanto, se contempla 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 asistencia in situ y con el coste de los materiales utilizados para realizar estas actividades) como en las preferencias del ingeniero de asistencia in situ para un flujo de trabajo dado. Con el fin de adquirir estos datos, en cada ejecución de un flujo de trabajo, un conjunto de parámetros relacionados con dicha ejecución se recopila (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 fijos de tiempo), es necesario analizar y procesar dichos parámetros para obtener un nuevo valor del resultado de cada flujo de trabajo. Después, el nuevo resultado de los flujos de trabajo se comunica a los diversos proxys personales PP.[0180] 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 tras una solicitud del propio proxy personal PP, después de la identificación del fallo/problema que ha de tratarse con dichos flujos de trabajo, o tras la recepción de una solicitud para activar un flujo de trabajo específico que proviene 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 tenga en ese momento el mayor resultado. También para los flujos de trabajo para el cliente, se proporciona un mecanismo de gestión dinámica del resultado, calibrado apropiadamente en función de los parámetros que pueden identificarse en la parte del cliente. [0181] Tal y como se ha observado, la interacción entre el proxy personal PP y el operador o el cliente se realiza utilizando una interfaz personal PI apropiada. La interfaz PI se crea utilizando tecnologías que dependen del tipo y de la potencia computacional del dispositivo utilizado por el operador/cliente (teléfono celular, PDA, ordenador portátil, ordenador de escritorio, etc.), tales 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 fijado con la mejor efectividad, eficacia y satisfacción en todos los contextos específicos de uso. En el desarrollo de la interfaz PI se ha prestado gran atención tanto a la optimización del código, con el fin de hacer más eficaces las interacciones y las actividades que los proxys personales PP tienen que realizar en cooperación con los proxys de recursos RP, como a los aspectos de manejo y de facilidad de uso de la GUI con el fin de mejorar en gran medida la capacidad del operador/cliente para llevar a cabo la tarea asignada al mismo. [0182] En caso de un operador, tras una solicitud de actividad (intervención in situ o notificación 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 va a 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 mediante la interfaz PI correspondiente que hay que realizar una actividad.[0183] Una vez que el operador haya recibido en su interfaz PI la información de que hay que realizar 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; en función del 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;

-observa los datos de la actividad asignada al mismo y ejecuta el procedimiento de suposición de dicha actividad (por ejemplo, intervención in situ o notificación 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 en parte disponibles para y son utilizadas por todos los tipos de operadores (por ejemplo, ingenieros de asistencia in situ y asesores de centros de atención telefónica) y en parte son específicas para un tipo determinado de operador.

[0184] Estas funciones permiten:

-mostrar la ubicación del equipo (por ejemplo, en un intercambio) en el que llevar a cabo la intervención (ingenieros de asistencia in situ);

-mostrar 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 asistencia in situ);

-presentar el flujo de trabajo (con una posible operación previa de selección entre diferentes flujos de trabajo) de un modo interactivo con el fin de guiar, paso a paso, las operaciones del ingeniero (ingenieros de asistencia in situ);

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

-sugerir acciones que el cliente debe llevar a cabo con el fin de resolver una notificación de problema presentada por el propio cliente (asesores de centros de atención telefónica);

-presentar hipótesis realizadas sobre la cláusula de la notificación de problema de un cliente (asesores de centros de atención telefónica);

-mostrar la configuración de las conexiones entre el proxy personal PP y el proxy de recursos RP, y presentar las "respuestas" del proxy

[0185] de recursos RP a las acciones de configuración,

ajustes, medición, pruebas, etc. llevadas a cabo por el RP

ya sea de manera autónoma o bajo solicitud del proxy

personal PP (todos los operadores);

-acceder de manera remota, 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 asistencia in situ);

-mostrar tanta documentación en línea como sea posible para dar soporte a la actividad (todos los operadores); y

-acceder 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, conversión, pizarra compartida, etc. (todos los operadores).

[0186] En caso de un cliente, el propio cliente, tras 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 un fallo detectado por él.

[0187] Las funciones ofrecidas permiten:

-presentar el flujo de trabajo de un modo interactivo con el fin de guiar, paso a paso, las actividades del cliente;

-presentar una secuencia de preguntas de un modo interactivo con el fin de adquirir, paso a paso, la información requerida para identificar la causa del fallo detectado por el cliente;

-presentar la hipótesis de la causa principal de un fallo;

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

-informar sobre la necesidad de contactar con un operador para solucionar el fallo; -acceder a las funciones de comunicación con un

operador.[0188] Los componentes que dan soporte a las operaciones descritas anteriormente también pueden aplicarse en contextos de gestión basados en enfoques tecnológicos más tradicionales (paradigma cliente-servidor).[0189] 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, en el documento US-A-2004/0196794), las funciones que dan soporte a las operaciones (de operadores y clientes) descritas anteriormente son todavía eficaces y pueden ofrecerse utilizando una plataforma que, para la parte funcional, no cambia con respecto a lo que se ha presentado en la Figura 2 de este documento, mientras que para la parte de gestión de red y de servicios, se basa en una arquitectura diferente, tal como 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 recurso de gestión (estación/unidad 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, se llevaron a cabo a través del proxy de recursos RP), utilizando modalidades de comunicación similares a las adoptadas entre estaciones de gestión de red de capa inferior y de capa superior. Como alternativa, el proxy personal PP podrá interactuar con una estación de gestión de red de capa superior, a la cual pertenece la información topológica de las soluciones de gestión de red de capa inferior, evitando de ese modo tener que tratar dicha información directamente. En cualquier caso, excepto para las modificaciones del componente de gestión, no habrá 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 las operaciones, en la medida en que esto solo representa una posible alternativa a la realización preferida de la presente invención.[0190] Debe apreciarse que aunque el procedimiento que guía a los ingenieros de asistencia in situ en llevar a cabo una intervención dada, tal y como se describe con relación a la Figura 3, se refiere a la selección de la intervención que va a llevar a cabo un ingeniero de asistencia in situ, las modalidades con las que se realiza 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 asistencia in situ solo se hace cargo de la intervención que le muestra el proxy personal PP en su interfaz PI y que se descargó al propio proxy personal PP mediante la cadena WFM-OM. [0191] En una realización alternativa, el ingeniero de asistencia in situ selecciona una actividad de las que puede llevarse a cabo en un equipo en un emplazamiento dado; en este caso, la única indicación recibida por el ingeniero de asistencia in situ, mediante el proxy personal PP que la recibió a su vez desde la cadena WFMOM, es la relacionada con el emplazamiento al que tiene que dirigirse (el WFM solo gestiona los turnos periódicos de los ingenieros de asistencia in situ entre los diversos emplazamientos, sin indicarles qué tienen que hacer).[0192] El procedimiento descrito anteriormente con relación a la Figura 3 indica que se proponen flujos de trabajo apropiados al ingeniero de asistencia in situ. Esto se realiza mediante la interacción entre el proxy personal PP y el gestor operacional OM. Cuando un ingeniero de asistencia in situ selecciona una intervención, 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 asistencia in situ.[0193] En una primera posible realización de la presente invención, dada una intervención específica, a todos los ingenieros de asistencia in situ se les presentan los mismos flujos de trabajo, independientemente de su grado de habilidad particular.[0194] En una realización alternativa, dada una intervención específica, los flujos de trabajo presentados a un ingeniero de asistencia in situ dependen de su propio grado de habilidad. si el ingeniero de asistencia in situ es un experto, se le presentan flujos de trabajo de mayor nivel; en caso 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 asistencia in situ. En el primer caso, la selección del gestor operacional OM acerca de los flujos de trabajo que se pondrán en la lista se realiza, por tanto, considerando solamente el tipo de intervención que va a llevarse a cabo, mientras que en el segundo caso también se tiene en cuenta el perfil del ingeniero de asistencia in situ y, en particular, su grado de habilidad con referencia a la habilidad requerida para llevar a cabo la intervención en cuestión. [0195] Nuevamente, en una realización alternativa de la presente invención, la activación del flujo de trabajo en el proxy personal PP no requiere 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 con el fin de recopilar algunos datos/mediciones dados, solicitar la ejecución de actividades determinadas 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 debe pedir al proxy de recursos RP que compruebe el resultado de la intervención llevada a cabo por el ingeniero de asistencia in situ, antes de considerar que dicha innervación se ha llevado a cabo de manera satisfactoria. [0196] Tal y como se ha observado, 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 llevarse a cabo automáticamente, con una solicitud de activación por parte del proxy personal PP del operador o, en caso contrario, de manera manual con la activación del proxy personal PP mediante el cliente. En el segundo caso, el propio proxy personal PP puede estar ya en el dispositivo del cliente debiéndose activar solamente o, en caso contrario, el cliente puede descargarlo desde una ubicación remota, en particular desde un sitio de Internet proporcionado intencionadamente. 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 solo interactúa con el cliente mediante un paradigma de preguntas y respuestas, pidiéndole a lo sumo que lleve a cabo algunas acciones particulares.[0197] 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 el fallo notificado 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. [0198] En lo que respecta 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 contactar, 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 debe abrir una sesión cooperativa, pide al gestor operacional OM que cree la lista de los operadores con los que contactar, 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, crea la lista requerida (introduciendo operadores del mismo equipo virtual o de otros equipos). La lista se ordena según las habilidades de los operadores y, en caso de diferentes equipos, según los equipos[0199] (primero se introducen los operadores del mismo equipo virtual, según el grado decreciente de habilidad, y después los operadores de otros equipos, de nuevo en grado decreciente de habilidad). Finalmente, el gestor operacional OM envía la lista creada al proxy personal PP.[0200] 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.[0201] 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 que contactar, utilizada por el proxy personal PP para abrir una sesión entre clientes y operadores o, si no, presentada al cliente.[0202] 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 con el que está asociado, los datos de otros perfiles de operador (esto se realiza para motivos de rendimiento: de esta manera se reduce el tiempo para acceder a datos de otros operadores con los que contactar). En particular, una primera alternativa contempla que dichos datos deben referirse a todos los operadores del mismo equipo virtual que el del operador con el que el proxy personal PP está asociado. Una segunda alternativa también es posible, 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 con un alto grado de 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 varían 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 se indican los que se refieren al perfil del operador asociado con el propio proxy personal PP.[0203] La gestión de los perfiles de operador en una realización adicional es completamente dinámica, en el sentido que el proxy personal PP no está asociado a priori a ningún operador específico: la asociación con un operador dado se realiza cuando el operador se autentica. En este caso, tras 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 relacionados con dicho operador. El gestor operacional OM, después de comprobar previamente la validez 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 con el que está asociado, sino también los datos de otros perfiles de operador, con las mismas opciones mostradas anteriormente (datos relacionados con todos los operadores del equipo virtual del operador o con un subconjunto de los operadores del equipo virtual).[0204] En lo que se refiere al procedimiento de gestión de los flujos de trabajo para dar soporte a los operadores, con respecto a lo que se ha mencionado anteriormente, es posible contemplar realizaciones alternativas de las modalidades que han de adoptarse para descargar los flujos de trabajo.[0205] 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.[0206] 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 (dependiendo de si el proxy personal PP está asociado con un operador de una manera estática o dinámica) todos los flujos de trabajo para guiar al operador se descargan en el mismo excluyendo los posibles flujos de trabajo que solo pueden aplicarse a equipos virtuales específicos. Es posible definir flujos de trabajo que se apliquen solamente a equipos virtuales específicos, en función de las características del equipamiento gestionado por estos equipos y/o en función de las habilidades particulares de los miembros del equipo.[0207] Finalmente, según una tercera realización, en la activación del proxy personal PP o después de la autenticación del operador, solo se descargan en el mismo los flujos de trabajo que son compatibles con las habilidades del operador con el que está asociado el PP.[0208] En función de las posibles realizaciones alternativas adoptadas, las funciones de la interfaz PI también pueden cambiar: en particular, solo si la indicación recibida por el ingeniero de asistencia in situ en la interfaz PI es la relacionada con el emplazamiento al que debe dirigirse, la interfaz PI presentará al ingeniero de asistencia in situ el conjunto de intervenciones que han de realizarse en un emplazamiento dado (de manera coherente con el perfil del ingeniero de

5 asistencia in situ), y será el propio ingeniero de asistencia in situ quien seleccione la intervención que va a realizar y de la que va a ocuparse.[0209] Por consiguiente, sin perjuicio de los principios subyacentes de la invención, los detalles y las

10 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 definida por las reivindicaciones adjuntas.

15

REFERENCIAS CITADAS EN LA DESCRIPCIÓN

Esta lista de referencias citadas por el solicitante está prevista únicamente para ayudar

al lector y no forma parte del documento de patente europea. Aunque se ha puesto el

máximo cuidado en su realización, no se pueden excluir errores u omisiones y la OEP

declina cualquier responsabilidad en este respecto.

Documentos de patente citados en la descripción

•: US 20040044542 A [0006] [0008] [0014]

•: WO 2005018249 A [0010] [0021] [0082] [0083]

•: US 5826239 A [0012] [0019]

•: US 20040196794 A [0191]

Documentos de patente no citados en la descripción

•: G. Valente ; A. Rigallo. Remoter: an Operational Knowledge Management System for Telecommunication Operators. Workshop on Knowledge Management and Organizational Memories, 16th European Conference on Artificial Intelligence, 2004 [0006]

•: Stephen Corley et al. Communications Management Process Integration Using Software Agents: A Specification of a Framework for Agent Oriented Workflow Management Systems. EURESCOM PROJECT P815, January 2001, 1-92, http:// www.eurescom.de/-pub-deliverables/P800-series/ P815/D1/p815d1vo12.pdf [0011]

•: W. Sull. A Distributed Environment for Enabling Lightweight Flexible Workflows. Proceedings of the 31st Annual Hawaii International Conference on System

Sciences, 1998, 355-364 [0013]

Claims

REIVINDICACIONES

1. Un sistema de operaciones distribuido, que comprende:

-una pluralidad de dispositivos terminales (TD), comprendiendo cada dispositivo terminal un agente proxy (PP), comprendiendo el agente proxy un motor de procesos (PE) basado en flujos de trabajo o basado en reglas para procesar flujos de trabajo o reglas, y una interfaz de usuario (PI) para representar al menos parte de dichos flujos de trabajo o reglas; y

-al menos un recurso de gestión remoto (MM) configurado para gestionar la transmisión de dichos flujos de trabajo o reglas a dichos dispositivos terminales,

- agentes operacionales (OA) configurados para coordinar operaciones de dichos agentes proxy.
2.

El sistema según la reivindicación 1, en el que dicho agente proxy comprende una interfaz de interconexión para el intercambio de información con una aplicación software (RP) de un dispositivo (NA) adicional durante el procesamiento de dichos flujos de trabajo o reglas.
3.

El sistema según la reivindicación 2, en el que dicha aplicación software de dicho dispositivo adicional comprende un motor de proceso (PE) basado en flujos de trabajo o basado en reglas y en el que dicho motor de procesos de dicho dispositivo terminal está configurado para interactuar con el motor de procesos de dicho dispositivo adicional mediante dicha interfaz de interconexión.
4.

El sistema según la reivindicación 1, en el que

dicha interfaz de usuario es una interfaz interactiva.
5.

El sistema según la reivindicación 1, que comprende además un gestor operacional (OM) que tiene funciones de gestión y de control de dichos agentes operacionales.
6.

El sistema según la reivindicación 1, en el que dichos agentes operacionales incluyen respectivos motores de procesos (PE) basados en flujos de trabajo o basados en reglas.
7.

El sistema según la reivindicación 5, en el que dicho gestor operacional incluye un motor de procesos (PE) basado en flujos de trabajos o basado en reglas.
8.

El sistema según la reivindicación 1, en el que dichos agentes proxy de dichos dispositivos terminales están configurados para interactuar directamente entre sí en una relación de interfuncionamiento.
9.

El sistema según la reivindicación 1, que incluye además un repositorio de procesos definidos mediante flujos de trabajo o reglas (ODB).
10.

El sistema según la reivindicación 1, que incluye además un repositorio de modelos de datos (ODB).
11.

El sistema según la reivindicación 1, que comprende además agentes de control (CA) para distribuir dichos flujos de trabajo o reglas a dichos dispositivos terminales.
12.

El sistema según la reivindicación 1, que incluye además una base de datos de rendimiento (PDB) para

almacenar datos de rendimiento relacionados con el procesamiento de dichos flujos de trabajo o reglas.
13.

El sistema según la reivindicación 1, que incluye además un registro operacional (OL) para almacenar procesos realizados por dichos agentes proxy.
14.

El sistema según cualquiera de las reivindicaciones anteriores, caracterizado por el hecho de que está configurado para gestionar intervenciones en equipos de usuario o de red.
15.

El sistema según la reivindicación 14, en el que dichos flujos de trabajo o reglas son una función del estado de los equipos de usuario o de red en los que se realizan dichas intervenciones.
16.

El sistema según la reivindicación 1, en el que al menos uno de la pluralidad de dispositivos terminales es un dispositivo portátil.
17.

El sistema según la reivindicación 2, en el que dicha aplicación software comprende un agente proxy (RP).
18.

El sistema según la reivindicación 17, en el que dicho agente proxy de cada dicho dispositivo terminal está configurado para activar automáticamente una sesión de comunicaciones con dicho agente proxy de dicha aplicación software de dicho dispositivo adicional.
19.

El sistema según la reivindicación 1, en el que dicha interfaz de usuario gestiona una interfaz gráfica (GUI).
20.

El sistema según la reivindicación 1, en el que

cada dicho dispositivo terminal está configurado para la activación del agente proxy mediante un usuario.
21.

Un procedimiento para gestionar intervenciones en equipos de usuario o de red, incluyendo el procedimiento las etapas de:

-proporcionar una arquitectura distribuida de primeros agentes proxy (PP) para gestionar intervenciones en los equipos de usuario o de red, estando asociados dichos primeros agentes proxy a dispositivos terminales y comprendiendo motores de procesos basados en flujos de trabajo o basados en reglas;

-disponer dicha arquitectura distribuida en capas jerárquicas que incluyen una capa de agentes operacionales (OA) que coordinan el funcionamiento de dichos primeros agentes proxy (PP); y

- generar señales de instrucción para realizar una intervención en al menos un equipo de usuario o de red mediante uno de dichos primeros agentes proxy de una manera interactiva (PTP) con al menos un recurso de gestión asociado con dicho equipo de usuario o de red, por lo que dichas señales de instrucción son una función del estado de dicho equipo de usuario o de red.
22.

El procedimiento según la reivindicación 21, en el que dicho recurso de gestión comprende un segundo agente proxy (RP) asociado con dicho equipo de usuario o de red y que comprende un motor de procesos basado en flujos de trabajo o basado en reglas.
23.

El procedimiento según la reivindicación 21 ó 22, caracterizado por el hecho de que cada uno de dichos primeros agentes proxy está asociado con un único

dispositivo terminal e incluye un único motor de procesos basado en flujos de trabajo o basado en reglas.
24.

El procedimiento según la reivindicación 23, caracterizado por el hecho de que incluye la etapa de asociar con dichos primeros agentes proxy (PP) interfaces personales (PI) para representar al menos parte de dichas instrucciones y para interactuar con el flujo de trabajo o regla ejecutados.
25.

El procedimiento según la reivindicación 21, caracterizado por el hecho de que dichas capas jerárquicas de dicha arquitectura distribuida incluyen una capa que comprende un gestor operacional (OM) que tiene funciones de gestión y de control y que supervisa el funcionamiento de dichos agentes operacionales (OA).
26.

El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de asignar a dichos agentes operacionales (OA) la ejecución distribuida de intervenciones sobre una pluralidad de dichos primeros agentes proxy (PP).
27.

El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de asignar a cada uno de dichos agentes proxy (PP) la tarea de dar soporte a un único operador o cliente, por lo que la ejecución de dichas intervenciones está desacoplada con respecto a dichas funciones de gestión y de control.
28.

El procedimiento según la reivindicación 21, caracterizado por el hecho de que incluye la etapa de proporcionar motores de procesos (PE) a dichos primeros agentes proxy (PP).
29.

El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de proporcionar motores de procesos (PE) a todas dichas capas en dicha arquitectura distribuida.
30.

El procedimiento según la reivindicación 28 ó 29, caracterizado por el hecho de que dichos motores de procesos (PE) están basados en flujos de trabajo o están basados en reglas.
31.

El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de incluir en dichas capas componentes (PP, OA, OM) adaptados para realizar funciones respectivas basadas en información de instrucción respectiva proporcionada a los mismos.
32.

El procedimiento según la reivindicación 31, caracterizado por el hecho de que incluye la etapa de proporcionar en dicha información de instrucción al menos uno de lo siguiente:

- 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.

El procedimiento según la reivindicación 21, caracterizado por el hecho de que incluye la etapa de configurar dichos primeros agentes proxy (PP) 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 mediante la interacción entre los primeros agentes proxy (PP).
34.

El procedimiento según la reivindicación 21, caracterizado por el hecho de que incluye la etapa de configurar dichos primeros agentes proxy (PP) para una

interacción de igual a igual (PTP) con dichos agentes proxy de recursos (RP).
35.

El procedimiento según la reivindicación 25, caracterizado por el hecho de que 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 consiste en:

-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.
36. El procedimiento según la reivindicación 35, caracterizado por el hecho de que incluye la etapa de proporcionar un recurso de gestión remoto (MM) para realizar al menos una etapa seleccionada del grupo que consiste en:

-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); y

- supervisar el estado de dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA).
37. 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, cuando se ejecutan, todas las etapas del procedimiento según cualquiera de las reivindicaciones 21 a 36.