WO2021024122A1 - Métodos para el monitoreo de asistentes automatizados - Google Patents

Métodos para el monitoreo de asistentes automatizados Download PDF

Info

Publication number
WO2021024122A1
WO2021024122A1 PCT/IB2020/057237 IB2020057237W WO2021024122A1 WO 2021024122 A1 WO2021024122 A1 WO 2021024122A1 IB 2020057237 W IB2020057237 W IB 2020057237W WO 2021024122 A1 WO2021024122 A1 WO 2021024122A1
Authority
WO
WIPO (PCT)
Prior art keywords
robot
robots
time
user interface
alert
Prior art date
Application number
PCT/IB2020/057237
Other languages
English (en)
French (fr)
Inventor
Carlos Mauricio Otalvaro Ospina
Juan Camilo Paniagua Alvarez
Original Assignee
Bancolombia S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bancolombia S.A. filed Critical Bancolombia S.A.
Publication of WO2021024122A1 publication Critical patent/WO2021024122A1/es

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B13/00—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion
    • G05B13/02—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt

Definitions

  • the present invention is directed to the technical field of desktop monitoring and automated processes by Robotics Desk Automation and Processes.
  • Robotic automation is the application of software to automate tasks and processes that humans would otherwise perform.
  • Software robots can fully automate essential business transactions through Robotic Process Automation (ARP) or optimize the way people work with Robotic Desktop Automation (ARE).
  • ARP Robotic Process Automation
  • ARE Robotic Desktop Automation
  • the goal of robotic automation is to improve customer experience and operational excellence through increased efficiency, performance, and agility in day-to-day activities across the enterprise.
  • ARE is an automation solution that assists an agent in handling simple repetitive tasks, in which the agent plays a facilitating role in the way in which automation is started and finished, depending on its work flow.
  • ARP provides automation solutions that do not require the intervention of an agent to develop and are fully self-sustaining.
  • the ARP allows to automate processes, reducing human intervention in the execution of computer applications by means of digital robots that are quickly coupled to the applications that are used in companies for repetitive and routine activities, gaining speed, reductions in operating costs and improving the quality and precision of operations and their results.
  • These ARP and ARE digital robots are a set of coded commands that inform a computer system of the tasks it must carry out and automate.
  • US2017173784 refers to the monitoring, administration and tracking of robots through the use of a robotic console module, whereby an administrator can have access to a holistic view of a plurality of robots running in various workstations of the clients. The administrator also has the ability to start and stop robots and see alerts for robots that are running.
  • the method consists of receiving from an ARP system information related to the digital robot that runs in the ARP system to carry out an assigned task, including information on incidents of an anomaly in the RPA system, which occurred while the robot would execute the assigned task, map the incident data according to a common data model, determine a solution to the anomaly based on an analysis carried out through a model trained with artificial intelligence of the mapped incident data and execute the determined resolution.
  • FR3038406 refers to a system for monitoring the performance of IT infrastructures, when an application is used, in order to anticipate necessary adjustments in the infrastructure to accelerate the response to incidents that lead to the degradation or interruption of services delivered by the application, which comprises: measurement means for tracking measurement information (may be the time during which a program has been executed); storage means for storing the measurement information; second storage means for memorizing the answers to the problems detected by the monitoring system; a rule machine; service level objective indicators; escalation rules; acceptable limits; memorized best practices; memorized activity periods; in order to establish correlations between this information to anticipate the evolution of resource consumption and thus be able to define proposals for the sizing of the infrastructure.
  • EP3451232 refers to an anomaly detection module that can include a time series analyzer that classifies current time series data into at least a plurality of classifications, based on historical data and can build a representative statistical model of current time series data based on at least one of the plurality of classifications.
  • An anomaly detector monitors current time series data and identifies statistical outliers, based on the statistical model, and can determine an outlier score by tracking a history of outliers. This document also mentions that outliers are used to report anomalies and / or remediation actions.
  • the inventors of the present application have identified in the technical field the need for new computer-implemented methods useful for monitoring and identifying failures in robots in a Robotic Process Automation and Robotic Desk Automation system, which allow the detection of incidents in the processes and automated desktops based on the times of use and the transactions carried out, applicable to robots that are executed both on demand and during regular hours, in order to be able to take corrective measures and thus ensure the correct functioning of the robots digital in time.
  • the inventors provide a computer-implemented method that addresses some of these deficiencies.
  • the method described here comprises collecting historical information about the robots' uptime and / or the number of transactions carried out; receive information in real time about the activity and inactivity time of the robots and / or the number of transactions carried out by the robots; Based on the information received, determine which robots show abnormal behavior in activity and inactivity times and / or in the number of transactions carried out with respect to historical information; and generate alerts in a user interface for those robots that present abnormal behavior.
  • FIG. 1 shows a general schematic of the automated process and desktop monitoring framework in which the method of the present invention is implemented.
  • FIG. 2 shows a general robot status validation flow chart for alert generation using a preferred embodiment of the method of the present invention.
  • FIG. 3 illustrates a flow chart of a preferred embodiment of the method of the present invention in which the validation of the robots is performed according to their run time. inactivity.
  • FIG. 4 illustrates a flow chart of a preferred embodiment of the method of the present invention in which the validation of the robots that are executed in regular hours is performed according to the activity history.
  • FIG. 5 illustrates a flow diagram of a preferred embodiment of the method of the present invention where the validation of the robots that are executed on demand is performed.
  • FIG. 6 shows a flow chart of a preferred embodiment of the method of the present invention, where the validation of the status of the robots is carried out from the history of the activity of the roles of said robots.
  • FIG. 7 illustrates a preferred embodiment of the user interface where the robot controller can view the status of the robots and a summary of all robots and machines.
  • FIG. 8 illustrates a preferred embodiment of the user interface where the robot controller can view a summary of the transactions carried out by the robots in each region.
  • FIG. 9 illustrates a preferred embodiment of the user interface where the robot controller can view information related to the effectiveness and reasonableness of the figures for each of the Iso robots.
  • FIG. 10 illustrates a preferred embodiment of the user interface where the robot controller can view the percentage of successful and failed transactions by region and per day carried out by digital robots.
  • the present invention is directed with a computer-implemented method for monitoring robots in a Robotic Process Automation (ARP) and Robotic Desk Automation (ARE) system.
  • ARP Robotic Process Automation
  • ARE Robotic Desk Automation
  • the method can be implemented in systems that comprise one or more processors, computer-readable storage media coupled to the one or more processors, these storage devices having stored instructions that when executed by the one or more processors make the one or more processors execute the different stages of the method that include: collecting historical information on the activity / inactivity time of the robots and / or the number of transactions carried out; receive information in real time about the activity / inactivity time of the robots and / or the number of transactions carried out by the robots; Based on the information received, determine which robots show abnormal behavior in activity / inactivity times and / or in the number of transactions carried out with respect to historical information; and generate alerts in a user interface for those robots that present abnormal behavior.
  • the implementation of the method is supported in a database (2) which can preferably be a SQL server, in which the robots (1) or assistants to be monitored are registered .
  • the robots and the database can be connected via a network.
  • Robots automatically enter data into the database. These data are preferably related to the execution time of the desktops and processes automated by the robots, even more preferably with the start or execution time of the processes and with the end time of the executed processes. Likewise, the data can be related to the number of transactions made by the robots.
  • the data that is registered in the database is processed, in order to determine anomalies in the activity and / or in the number of transactions carried out by the robots through logical rules that generate alerts in a user interface (3), allowing a robot controller to display the status of all robots being monitored.
  • a first rule consists of determining from the information received from the digital robots, which robots are not in a maintenance state and / or in a pre-production state and for those that have any of these states, not to generate any alert , keeping the state as initial, as exemplified in FIG. 2.
  • a robot when a robot is in the pre-production stage, it is possible to generate a color alert on the user interface that can preferably be orange.
  • a maintenance state it can be generate a color alert in the user interface that can preferably be white.
  • the wizards controller can in the user interface assign any of these states to the digital robots being monitored.
  • Another possible rule comprises validating the status of the robot according to idle time, as exemplified in FIG. 3.
  • this rule can be applied after determining which wizards are in maintenance and / or pre-production status and discarding them.
  • the first measure it is determined, of the robots that are not in maintenance and / or pre-production, which are inactive and whether or not they have started activity on the day. If they have started activity, the time they have been inactive is compared to a predetermined threshold value. If the idle time is greater than the preset threshold, an alert is generated in the user interface, which is preferably a visual alert of one color, which is even more preferably red.
  • an alert is generated in the user interface, which is preferably a visual color alert, which is even more preferably green.
  • an alert is generated in the interface, which preferably is a visual color alert, which is, even more preferably, blue.
  • a further validation may be carried out which involves checking the wizard's activity based on the historical activity data, as illustrated in FIG. 4.
  • This additional validation is carried out for robots or assistants that are not executed on demand, that is, they are not activated by a user; they run on a regular schedule.
  • the process is not on demand but there is information that indicates that activity started on the day (for example, it is evidenced that at least one transaction ended) even though its current status is inactive, the number of transactions carried out by the robot in the day with the average number of daily transactions made by the robot.
  • an alert is generated in the user interface that preferably can be a visual color alert, which is, even more preferably , blue. If, on the other hand, the number of transactions carried out by the robot on the day is less than the average number of daily transactions carried out by the robot, it is verified if the time in which the robot has been inactive on the day is less than or equal to the historical average idle time of the robot. In case the robot's idle time in the day is less than or equal to the historical average idle time of the robot, an alert is generated in the user interface that preferably can be a visual color alert, which is, even more preferably green. On the contrary, if the idle time of the robot in the day is greater At the historical average idle time of the robot, an alert is generated in the user interface which can preferably be a visual alert in color, which is, even more preferably red.
  • an alert is generated which can preferably be a visual color alert, which is, even more preferably red, to the user interface. If the verification is positive, a color alert, which is, even more preferably blue, can be sent to the user interface.
  • an alert is generated in the user interface that preferably can be a visual alert in color, which is, even more preferably, red. If the number of transactions made by the robot on the day is greater than the average number of daily transactions made by the robot, an alert is generated in the user interface that preferably can be a visual color alert, which is, even more preferably , blue.
  • robots that run on a regular schedule are preferably validated from the rules exemplified in FIG. 4.
  • Robots that run on demand are preferably validated from the rules exemplified in FIG. 5.
  • the validation of both types of robots can be carried out simultaneously or independently.
  • a validation of the internal machines that run the robots that are active can be performed, in order to determine if any are off, as illustrated in FIG. 6.
  • this validation is done to the robots that operate both on demand and in regular hours and that have been verified using the rules previously described.
  • First of all it is verified that the robots are not turned off.
  • For robots that are not turned off it is verified that all robot roles are being executed. If all the roles are running, it is checked if there are idle machines, and if there are, an alert for inactivity of one or more machines is generated to the user interface. If all the robot roles are not running, the activity history of the robot roles is checked. If the behavior of the roles is not normal according to the history, an alert is generated in the user interface that preferably can be a visual color alert, which is, even more preferably, red, and an alert for inactivity of one or more machines.
  • the number of transactions carried out by a robot in one hour is compared with the average and that their status is completed satisfactorily and not with errors .
  • the validation of the machines is carried out taking into account that a single machine can execute more than one role in different periods of time and that different machines can execute different roles simultaneously.
  • the user interface can graphically display the number of automated operations that are carried out in certain historical periods of time (last 30 days, last 12 months, etc.) by a single robot, per region. Likewise, it is possible to graphically display the number of operations performed by all the robots in each region on the user interface. Likewise, it is possible to graphically display in the user interface the percentage of successful transactions versus failed transactions, by region, as exemplified in FIG. 10. For each of the robots, depending on the number of successful and failed transactions, the total number of transactions and the average number of executions in a historical period of time, it is possible to calculate a “reasonableness” value, dividing the total number of transactions per day in the average of the executions in a certain period of time.
  • a colored alert When the reasonableness value is greater than or equal to 90%, a colored alert will be displayed on the user interface, which is preferably green; When the value of reasonableness is greater than or equal to 85% and less than 90%, a colored alert will be displayed on the user interface, preferably yellow; and when the reasonableness value is less than 85%, a colored alert will be displayed on the user interface, which is preferably red, as exemplified in FIG. 9.
  • These parameters are mentioned as an example, since it is possible to carry out the calculation of any parameter (based on the information available in the database) to measure the performance of the robots, to later send them and display them in a user interface to provide information to the robot controller about their operation, as exemplified in figures 7 to 10.
  • the present invention is directed to the computer-readable storage medium, coupled to one or more processors, that has stored instructions that when executed by the one or more processors, cause the one or more processors execute any of the operations or rules described above.
  • the invention in a third aspect, relates to a system comprising one or more processors, and a computer-readable storage medium, coupled to the one or more processors, which has stored instructions that when executed by the one or more more processors, cause the one or more processors to execute any of the operations or rules described above.
  • the described method can be implemented in digital electronic circuits, or in computer hardware, firmware, software, or combinations thereof.
  • the apparatus may be implemented in a computer program product tangibly embodied in an information carrier, for example, in a machine-readable storage device for execution by a programmable processor; and the steps of the method can be performed by a programmable processor that executes an instruction program to perform the functions of the described implementations by operating on the input data and generating the output.
  • the features described can be advantageously implemented in one or more computer programs that are executable in a programmable system that includes at least one programmable processor coupled to receive data and instructions from and to transmit data and instructions to a data storage system, at least one input device, and at least one output device.
  • a computer program is a set of instructions that can be used, directly or indirectly, on a computer to perform a certain activity or achieve a certain result.
  • a computer program can be written in any form of programming language, including compiled or interpreted languages, and can be implemented in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use. in a computing environment.
  • processors suitable for executing an instruction program include, by way of example, general and special purpose microprocessors, and the single processor or one of multiple processors of any type of computer.
  • a processor will receive instructions and data from read-only memory or random access memory, or both.
  • the essential elements of a computer are a processor to execute instructions and one or more memories to store instructions and data.
  • a computer will also include, or be operably coupled to communicate with, one or more mass storage devices for storing data files; Such devices include magnetic drives, such as internal hard drives and removable drives; magneto-optical discs; and optical discs.
  • Storage devices suitable for tangibly incorporating instructions and data from computer programs include all forms of non-volatile memory, including by way of example semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic drives such as internal hard drives and removable drives; magneto-optical discs; and CD-ROM and DVD-ROM discs.
  • semiconductor memory devices such as EPROM, EEPROM, and flash memory devices
  • magnetic drives such as internal hard drives and removable drives
  • magneto-optical discs and CD-ROM and DVD-ROM discs.
  • Processor and memory can be supplemented or incorporated into ASICs (Application Specific Integrated Circuits).
  • the methods can be implemented in a computer that has a display device such as a CRT monitor (ray tube cathodic) or LCD (liquid crystal display) to display information to the user and a keyboard and pointing device, such as a mouse or trackball, by which the user can provide information to the computer.
  • a display device such as a CRT monitor (ray tube cathodic) or LCD (liquid crystal display) to display information to the user and a keyboard and pointing device, such as a mouse or trackball, by which the user can provide information to the computer.
  • a keyboard and pointing device such as a mouse or trackball

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Artificial Intelligence (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Automation & Control Theory (AREA)
  • Robotics (AREA)
  • Mechanical Engineering (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

La presente invención se refiere a un método para monitorear sistemas de Automatización de Escritorios y Procesos por Robótica que comprende: recopilar información histórica sobre el tiempo de actividad de los robots y/o el número de transacciones realizadas; recibir información en tiempo real sobre el tiempo de inactividad de los robots y/o el número de transacciones realizadas por los robots; con base en la información recibida determinar cuáles robots presentan un comportamiento anormal en los tiempos de inactividad y/o en el número de transacciones realizadas con respecto a la información histórica; y generar alertas en una interfaz de usuario para aquellos robots que presenten un comportamiento anormal (conocer el estado de finalización de las transacciones para tomar desiciones, identificar errores reportados por los operadores, obtener información agrupada que permita automáticamente ejecutar soluciones masivas dependiendo del comportamiento anormal, entre otros).

Description

MÉTODOS PARA EL MONITOREO DE ASISTENTES AUTOMATIZADOS
CAMPO DE LA TÉCNICA
[0001] La presente invención se encuentra dirigida al campo técnico del monitoreo de escritorios y procesos automatizados mediante Automatización de Escritorios y Procesos por Robótica.
ESTADO DE LA TÉCNICA
[0002] La automatización robótica es la aplicación de software para automatizar tareas y procesos que de otra forma realizarían los humanos. Los robots de software pueden automatizar completamente las transacciones comerciales esenciales a través de Automatización Robótica de Procesos (ARP) u optimizar la forma en que las personas trabajan con Automatización Robótica de Escritorios (ARE). El objetivo de la automatización robótica es mejorar la experiencia del cliente y la excelencia operativa a través de una mayor eficiencia, rendimiento y agilidad en las actividades del día a día en toda la empresa.
[0003] La ARE es una solución de automatización que asiste a un agente en manejar tareas sencillas repetitivas, en la que el agente juega un rol facilitador en la forma en la que la automatización es iniciada y terminada, dependiendo de su flujo de trabajo. La ARP proporciona soluciones de automatización que no requieren de la intervención de un agente para su desarrollo y que son autosostenibles en su totalidad.
[0004] La ARP permite automatizar procesos, disminuyendo la intervención humana en la ejecución de aplicaciones informáticas mediante robots digitales que se acoplan rápidamente a las aplicaciones que se usan en las empresas para las actividades repetitivas y rutinarias, ganando velocidad, reducciones en costos operativos y mejorando la calidad y la precisión de las operaciones y sus resultados. Estos robots digitales ARP y ARE son un conjunto de comandos codificados que informan a un sistema computacional las tareas que debe llevar a cabo y automatizar.
[0005] Entre los procesos y escritorios que se automatizan mediante ARP y ARE, se encuentran aquellos relacionados con peticiones, quejas y reclamos, procesos de compras, contables, entre otros, que son extremadamente repetitivos y manuales y presentan frecuentemente un sinnúmero de errores. Los robots digitales (o asistentes automatizados), pueden trabajar durante la noche, los fines de semana y en días festivos y ofrecen máxima flexibilidad para adaptarse y cubrir un alto volumen de operación. Debido a que los asistentes automatizados deben operar de forma continua durante largos periodos de tiempo, el monitoreo de los mismos cobra una gran importancia, con el fin de asegurar su correcto funcionamiento. Como se podrá ver a continuación, existe en el estado de la técnica algunas metodologías para monitorear e identificar fallas en sistemas de este tipo.
[0006] US2017173784 se refiere al monitoreo, administración y seguiento de robots mediante el uso de un módulo de consola robótica, mediante el cual un administrador puede tener acceso a una vista holística de una pluralidad de robots que se ejecutan en varios puestos de trabajo de los clientes. El administrador también tiene la habilidad de iniciar y parar los robots y ver alertas de los robots que se ejecutan.
[0007] US2019155225 menciona métodos, sistemas y aparatos que proporcionan soluciones de administración de robots de un sistema de Automatización Robótica de Procesos. Particularmente, el método consiste en recibir desde un sistema ARP información relacionada con el robot digital que se ejecuta en el sistema ARP para llevar a cabo una tarea asignada, incluyendo la información datos sobre incidentes de una anomalía en el sistema RPA, que sucedieron mientras el robot ejecutaba la tarea asignada, mapear los datos de incidente de acuerdo con un modelo de datos común, determinar una solución a la anomalía con base en un análisis realizado a través de un modelo entrenado con inteligencia artifical de los datos de incidente mapeados y ejecutar la resolución determinada.
[0008] FR3038406 se refiere a un sistema para monitorear el desempeño de infraestructuras de TI, cuando se utiliza una aplicación, con el fin de anticipar ajustes necesarios en la infraestructura para acelerar la respuesta a incidentes que llevan a la degradación o interrupción de los servicios entregados por la aplicación, el cual comprende: medios de medición para rastrear información de medición (puede ser el tiempo durante el cual un programa ha sido ejecutado); medios de almacenamiento para almacenar la información de medición; segundos medios de almacenamiento para memorizar las respuestas a los problemas detectados por el sistema de monitoreo; una máquina de reglas; indicadores de objetivos de nivel de servicio; reglas de escalamiento; límites aceptables; mejores prácticas memorizadas; periodos de actividad memorizados; con el fin de establecer correlaciones entre esta información para anticipar la evolución del consumo de recursos y así poder definir propuestas para el dimensionamiento de la infraestructura.
[0009] EP3451232 se refiere a un módulo de detección de anomalías que puede incluir un analizador de series de tiempo que clasifica datos actuales de series de tiempo en al menos una pluralidad de clasificaciones, con base en datos históricos y puede construir un modelo estadístico representativo de los datos actuales de series de tiempo con base en al menos una de la pluralidad de clasificaciones. Un detector de anomalías monitorea los datos actuales de series de tiempo e identifica valores estadísticos atípicos, con base en el modelo estadístico y puede determinar un puntaje anómalo para los valores atípicos al hacer seguimiento de un histórico de los valores atípicos. Este documento menciona también que los valores atípicos son utilizados para reportar anomalías y/o acciones de remediación.
RESUMEN DE LA INVENCIÓN
[0010] Los inventores de la presente solicitud han identificado en el campo técnico la necesidad de nuevos métodos implementados por computador útiles para el monitoreo e identificación de fallas en los robots en un sistema de Automatización Robótica de Procesos y de Automatización Robótica de Escritorios, que permitan detectar incidentes en los procesos y escritorios automatizados con base en los tiempos de utilización y en las transacciones realizadas, aplicables a robots que se ejecutan tanto por demanda como en horario regular, para poder tomar medidas correctivas y así asegurar el correcto funcionamiento de los robots digitales en el tiempo.
[0011] Así pues, los inventores proporcionan un método implementado por computador que soluciona algunas de estas deficiencias. Particularmente, el método aquí descrito comprende recopilar información histórica sobre el tiempo de actividad de los robots y/o el número de transacciones realizadas; recibir información en tiempo real sobre el tiempo de actividad e inactividad de los robots y/o el número de transacciones realizadas por los robots; con base en la información recibida determinar cuáles robots presentan un comportamiento anormal en los tiempos de actividad e inactividad y/o en el número de transacciones realizadas con respecto a la información histórica; y generar alertas en una interfaz de usuario para aquellos robots que presenten un comportamiento anormal.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
FIG. 1 muestra un esquema general del marco de monitoreo de escritorios y procesos automatizados en el que se implementa el método de la presente invención.
FIG. 2 muestra un diagrama de flujo general de validación de estado de robots para la generación de alertas empleando una modalidad preferente del método de la presente invención.
FIG. 3 ilustra un diagrama de flujo de una modalidad preferente del método de la presente invención en donde se realiza la validación de los robots de acuerdo con su tiempo de inactividad.
FIG. 4 ilustra un diagrama de flujo de una modalidad preferente del método de la presente invención en donde se realiza la validación de los robots que se ejecutan en horario regular de acuerdo con el histórico de actividad.
FIG. 5 ilustra un diagrama de flujo de una modalidad preferente del método de la presente invención en donde se realiza la validación de los robots que se ejecutan por demanda.
FIG. 6 muestra un diagrama de flujo de una modalidad preferente del método de la presente invención, en donde se realiza la validación del estado de los robots a partir del histórico de la actividad de los roles de dichos robots.
FIG. 7 ilustra una modalidad preferente de la interfaz de usuario en donde el controlador de robots puede ver el estado de estos y un resumen de todos los robots y las máquinas.
FIG. 8 ilustra una modalidad preferente de la interfaz de usuario en donde el controlador de robots puede ver un resumen de las transacciones llevadas a cabo por los robots en cada región.
FIG. 9 ilustra una modalidad preferente de la interfaz de usuario en donde el controlador de robots puede ver información relacionada con la efectividad y razonabilidad de las cifras de cada uno de Iso robots.
FIG. 10 ilustra una modalidad preferente de la interfaz de usuario en donde el controlador de robots puede ver el porcentaje de transacciones exitosas y fallidas por región y por día que llevan a cabo los robots digitales.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
[0012] En un primer aspecto, la presente invención se encuentra dirigida con un método implementado por computador para el monitoreo de robots en un sistema de Automatización Robótica de Procesos (ARP) y de Automatización Robótica de Escritorios (ARE). Este método logra llevar a cabo el monitoreo en tiempo real de los robots digitales, recopilando información acerca de sus tiempos de actividad e inactividad y del número de transacciones que estos realizan, permitiendo que se identifiquen incidentes sin la intervención de un usuario, para asegurarse que los robots se ejecuten de forma adecuada. [0013] El método puede ser implementado en sistemas que comprenden uno o más procesadores, medios de almacenamiento legibles por un computador acoplados al uno o más procesadores, teniendo estos dispositivos de almacenamiento instrucciones almacenadas que cuando se ejecutan por el uno o más procesadores hacen que el uno o más procesadores ejecuten las diferentes etapas del método que incluyen: recopilar información histórica sobre el tiempo de actividad/inactividad de los robots y/o el número de transacciones realizadas; recibir información en tiempo real sobre el tiempo de actividad/inactividad de los robots y/o el número de transacciones realizadas por los robots; con base en la información recibida determinar cuáles robots presentan un comportamiento anormal en los tiempos de actividad/inactividad y/o en el número de transacciones realizadas con respecto a la información histórica; y generar alertas en una interfaz de usuario para aquellos robots que presenten un comportamiento anormal.
[0014] Como se puede ver en la FIG.1 , la implementación del método está soportada en una base de datos (2) que puede ser preferentemente un servidor SQL, en la cual se registran los robots (1) o asistentes a ser monitoreados. Preferentemente, los robots y la base de datos pueden estar conectados a través de una red. Los robots ingresan datos de manera automática en la base de datos. Estos datos se encuentran relacionados preferentemente con el tiempo de ejecución de los escritorios y procesos automatizados por los robots, aún más preferentemente con la hora de inicio o ejecución de los procesos y con la hora de finalización de los procesos ejecutados. Igualmente, los datos pueden estar relacionados con el número de transacciones realizadas por los robots. Los datos que se registran en la base de datos son procesados, con el fin de determinar anomalías en la actividad y/o en el número de transacciones realizadas por los robots mediante reglas lógicas que generan alertas en una interfaz de usuario (3), permitiendo que un controlador de robots visualice el estado de todos los robots que se están monitoreando.
[0015] Para determinar cuáles robots presentan un comportamiento anormal en los tiempos de actividad e inactividad y/o en el número de transacciones realizadas con respecto a la información histórica, se pueden aplicar varias reglas.
[0016] Una primera regla consiste en determinar a partir de la información recibida de los robots digitales, cuáles robots no se encuentran en estado de mantenimiento y/o en estado de preproducción y para aquellos que tienen alguno de estos estados, no generar ninguna alerta, manteniendo el estado como el inicial, como se ejemplifica en la FIG. 2. En una modalidad de la invención, cuando un robot está en etapa de preproducción, es posible generar una alerta de color en la interfaz de usuario que puede ser preferentemente de color naranja. Preferentemente, cuando un asistente o robot está en estado de mantenimiento, se puede generar una alerta de color en la interfaz de usuario que puede ser preferentemente de color blanco. El controlador de los asistentes puede en la interfaz de usuario asignar cualquiera de estos estados a los robots digitales que se monitorean.
[0017] Otra posible regla comprende validar el estado del robot de acuerdo con el tiempo de inactividad, como se ejemplifica en la FIG. 3. Preferentemente, esta regla se puede aplicar después de determinar cuáles asistentes están en estado de mantenimiento y/o preproducción y descartándolos. Para esto, en primer medida se determina, de los robots que no están en mantenimiento y/o preproducción, cuáles están inactivos y si han iniciado o no actividad en el día. Si han iniciado actividad, se compara el tiempo que llevan inactivos con un valor umbral predeterminado. Si el tiempo de inactividad es mayor al umbral preestablecido, se genera en la interfaz de usuario una alerta, que preferentemente es una alerta visual de un color, que es, aún más preferentemente, rojo. Si el tiempo de inactividad no es mayor al umbral preestablecido, se genera en la interfaz de usuario una alerta, que preferentemente es una alerta visual de color, que es, aún más preferentemente, verde. Para los robots que no han iniciado actividad en el día y que están inactivos, se genera en la interfaz una alerta, que preferentemente es una alerta visual de color, que es, aún más preferentemente, azul.
[0018] Con el fin de complementar las reglas anteriormente descritas, se puede llevar a cabo una validación adicional que implica comprobar la actividad del asistente con base en los datos históricos de actividad, como se ilustra en la FIG. 4. Preferentemente, es posible hacer la comprobación de la actividad de robots con base en la información histórica de los últimos dos meses. Esta validación adicional se lleva a cabo para los robots o asistentes que no se ejecutan por demanda, es decir, que no se accionan por un usuario; se ejecutan en horario regular. Cuando el proceso no es por demanda pero existe información que indica que inició actividad en el día (por ejemplo, se evidencia que terminó al menos una transacción) aunque su estado actual es inactivo, se compara el número de transacciones realizadas por el robot en el día con el número promedio de transacciones diarias realizadas por el robot. Si el número de transacciones realizadas por el robot en el día es mayor al número promedio de transacciones diarias realizadas por el robot, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, azul. Si por el contrario, el número de transacciones realizadas por el robot en el día es menor al número promedio de transacciones diarias realizadas por el robot, se verifica si el tiempo en el que el robot ha estado inactivo en el día es menor o igual al tiempo de inactividad promedio histórico del robot. En caso de que el tiempo de inactividad del robot en el día sea menor o igual al tiempo de inactividad promedio histórico del robot, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, verde. Por el contrario, si el tiempo de inactividad del robot en el día es mayor al tiempo de inactividad promedio histórico del robot, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente rojo.
[0019] Para los robots nuevos o en proceso de producción, se determina si las transacciones que llevaron a cabo fueron iniciadas y terminadas. En caso de ser negativa la verificación, se genera una alerta que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente rojo, a la interfaz de usuario. Si la verificación es positiva, se puede enviar una alerta de color, que es, aún más preferentemente azul, a la interfaz de usuario.
[0020] Para los robots que se ejecutan por demanda (accionados por usuario) que se encuentran inactivos, se pueden aplicar las reglas ilustradas en la FIG. 5. Si el robot registró un tiempo de ejecución o una hora de finalización y si existe información que indica que inició actividad en el día, se verifica si el robot que se ejecuta por demanda tiene un tiempo de ejecución. Si tiene tiempo de ejecución, se compara el número de transacciones realizadas por el robot en el día con el número promedio de transacciones diarias realizadas por el robot. Si el número de transacciones realizadas por el robot en el día es menor al número promedio de transacciones diarias realizadas por el robot, se verifica si el robot estuvo inactivo por un tiempo menor a un valor umbral predeterminado y si lo es, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, verde. Si por el contrario, el robot estuvo inactivo por un tiempo mayor al umbral predeterminado, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, rojo. Si el número de transacciones realizadas por el robot en el día es mayor al número promedio de transacciones diarias realizadas por el robot, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, azul.
[0021] Para los robots que se ejecutan por demanda que no tienen tiempo de ejecución, se verifica si tienen hora de finalización predeterminada. Si tienen hora de finalización, se verifica si la hora actual se encuentra entre la hora de inicio y la hora de finalización y si lo está, se verifica si el robot estuvo inactivo por un tiempo menor a un valor umbral predeterminado y si lo es, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, verde. Si por el contrario, el robot estuvo inactivo por un tiempo mayor al umbral predeterminado, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, rojo. Si la hora actual no se encuentra entre la hora de inicio y la hora de finalización, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, azul. [0022] Así pues, los robots que se ejecutan en horario regular, preferentemente se validan a partir de las reglas ejemplificadas en la FIG. 4. Los robots que se ejecutan por demanda, preferentemente se validan a partir de las reglas ejemplificadas en la FIG. 5. La validación de ambos tipos de robots (ejecución en horario regular y por demanda), se puede llevar a cabo de manera simultánea o independiente.
[0023] Adicionalmente, se puede realizar una validación de las máquinas internas que ejecutan los robots que están activos, con el fin de determinar si alguna está apagada, como se ilustra en la FIG. 6. Preferentemente, esta validación se hace a los robots que operan tanto por demanda como en horario regular y que han sido verificados mediante las reglas anteriormente descritas. En primer lugar se verifica que los robots no estén apagados. Para los robots que no estén apagados, se verifica que se estén ejecutando todos los roles del robot. Si se están ejecutando todos los roles, se revisa si hay máquinas inactivas, y si las hay, se genera una alerta por inactividad de una o más máquinas a la interfaz de usuario. Si todos los roles del robot no se están ejecutando, se comprueba el histórico de la actividad de los roles del robot. Si el comportamiento de los roles no es normal según el histórico, se genera una alerta en la interfaz de usuario que preferentemente puede ser una alerta visual de color, que es, aún más preferentemente, rojo, y una alerta por inactividad de una o más máquinas.
[0024] Preferentemente, para determinar si el comportamiento de los roles no es normal según el histórico, se compara la cantidad de transacciones realizadas por un robot en una hora con el promedio y que el estado de las mismas sea finalizado satisfactoriamente y no con errores.
[0025] La validación de las máquinas se lleva a cabo teniendo en cuenta que una sola máquina puede ejecutar más de un rol en diferentes periodos de tiempo y que diferentes máquinas pueden ejecutar diferentes roles de forma simultánea.
[0026] Cuando los asistentes automatizados se llevan a cabo en varias regiones (países, estados, departamentos, ciudades, etc.) a partir de la información de la base de datos que es procesada, y sabiendo en qué zonas geográficas se ejecuta cada uno de los robots, particularmente para aquellos automatizados mediante ARE, es posible calcular el número de transacciones fallidas o exitosas por región, y enviar dicha información a la interfaz de usuario, donde se indican con un primer color, que es preferentemente verde, los robots exitosos y con un segundo color, que es preferentemente rojo, los robots fallidos, como se ejemplifica en la FIG. 8
[0027] De manera similar, en la interfaz de usuario se pueden mostrar gráficamente el número de operaciones automatizadas que se llevan a cabo en determinados periodos históricos de tiempo (últimos 30 días, últimos 12 meses, etc.) por un único robot, por región. Igualmente, es posible presentar en la interfaz de usuario gráficamente el número de operaciones realizadas por todos los robots, en cada región. Igualmente, es posible mostrar de forma gráfica en la interfaz de usuario el porcentaje de transacciones existosas versus transacciones fallidas, por región, como se ejemplifica en la FIG. 10. Para cada uno de los robots, dependiendo del número de transacciones exitosas y fallidas, del número total de transacciones y el promedio de ejecuciones en un lapso histórico de tiempo, es posible calcular un valor de “razonabilidad”, dividiendo el total de transacciones al día en el promedio de las ejecuciones en determinado periodo de tiempo. Cuando el valor de razonabilidad sea mayor o igual al 90% se mostrará en la interfaz de usuario una alerta de color que es, preferentemente de color verde; cuando el valor de la razonabilidad sea mayor o igual a 85% y menor a 90%, se mostrará en la interfaz de usuario una alerta de color que es, preferentemente, de color amarillo; y cuando el valor de la razonabilidad sea menor al 85% se mostrará en la interfaz de usuario una alerta de color, que es preferentemente de color rojo, como se ejemplifica en la FIG. 9. Estos parámetros se mencionan a manera de ejemplo, ya que es posible llevar a cabo el cálculo de cualquier parámetro (con base en la información disponible en la base de datos) para medir el desempeño de los robots, para posteriormente enviarlos y mostrarlos en una interfaz de usuario para brindar información al controlador de robots sobre el funcionamiento de los mismos, como se ejemplifica en las figuras 7 a 10. Adicionalmente, es posible monitorear el estado de vencimiento y bloqueo de las claves de las máquinas en las que se ejecutan los robots digitales. Preferentemente, es posible enviar alertas a la interfaz de usuario cuando: i) la clave de la máquina está por vencerse; ii) la clave de la máquina se ha vencido; y iii) la clave de la máquina ha sido bloqueada.
[0028] En un segundo aspecto, la presente invención se encuentra dirigida al medio de almacenamiento legible por computador, acoplado a uno o más procesadores, que tiene instrucciones almacenadas que cuando se ejecutan por el uno o más procesadores, causan que el uno o más procesadores ejecuten cualquiera de las operaciones o reglas anteriormente descritas.
[0029] En un tercer aspecto, la invención se refiere a un sistema que comprende uno o más procesadores, y un medio de almacenamiento legible por computador, acoplado al uno o más procesadores, que tiene instrucciones almacenadas que cuando se ejecutan por el uno o más procesadores, causan que el uno o más procesadores ejecuten cualquiera de las operaciones o reglas anteriormente descritas.
[0030] El método descrito puede implementarse en circuitos electrónicos digitales, o en hardware de computadora, firmware, software o en combinaciones de ellos. El aparato puede implementarse en un producto de programa informático incorporado de forma tangible en un soporte de información, por ejemplo, en un dispositivo de almacenamiento legible por máquina para su ejecución por un procesador programable; y los pasos del método se pueden realizar mediante un procesador programable que ejecuta un programa de instrucciones para realizar las funciones de las implementaciones descritas al operar en los datos de entrada y generar la salida. Las características descritas pueden implementarse ventajosamente en uno o más programas de computadora que son ejecutables en un sistema programable que incluye al menos un procesador programable acoplado para recibir datos e instrucciones desde y para transmitir datos e instrucciones a un sistema de almacenamiento de datos, al menos uno dispositivo de entrada, y al menos un dispositivo de salida. Un programa de computadora es un conjunto de instrucciones que se pueden utilizar, directa o indirectamente, en una computadora para realizar una determinada actividad o lograr un cierto resultado. Un programa de computadora se puede escribir en cualquier forma de lenguaje de programación, incluidos los lenguajes compilados o interpretados, y se puede implementar en cualquier forma, incluso como un programa independiente o como un módulo, componente, subrutina u otra unidad adecuada para su uso en un entorno informático.
[0031] Los procesadores adecuados para la ejecución de un programa de instrucciones incluyen, a modo de ejemplo, microprocesadores de propósito general y especial, y el único procesador o uno de los múltiples procesadores de cualquier tipo de computadora. En general, un procesador recibirá instrucciones y datos desde una memoria de sólo lectura o una memoria de acceso aleatorio o ambos. Los elementos esenciales de una computadora son un procesador para ejecutar instrucciones y una o más memorias para almacenar instrucciones y datos. En general, una computadora también incluirá, o estará acoplada operativamente para comunicarse con, uno o más dispositivos de almacenamiento masivo para almacenar archivos de datos; tales dispositivos incluyen discos magnéticos, tales como discos duros internos y discos extraíbles; discos magneto- ópticos; y discos ópticos. Los dispositivos de almacenamiento adecuados para incorporar de manera tangible las instrucciones y los datos de los programas informáticos incluyen todas las formas de memoria no volátil, incluso a modo de ejemplo, dispositivos de memoria de semiconductores, como EPROM, EEPROM y dispositivos de memoria flash; discos magnéticos tales como discos duros internos y discos extraíbles; discos magneto-ópticos; y discos CD-ROM y DVD-ROM. El procesador y la memoria pueden complementarse o incorporarse en ASIC (circuitos integrados específicos de la aplicación).
[0032] Para que exista interacción con un usuario, los métodos pueden implementarse en una computadora que tenga un dispositivo de visualización como un monitor CRT (tubo de rayos catódicos) o LCD (pantalla de cristal líquido) para mostrar información al usuario y un teclado y un dispositivo señalador, como un ratón o una bola de seguimiento, mediante el cual el usuario puede proporcionar información a la computadora. Además, estas actividades se pueden implementar a través de pantallas táctiles de pantalla plana y otros mecanismos apropiados.

Claims

REIVINDICACIONES
1. Un método implementado por computador, para el monitoreo de robots digitales, ejecutado por uno o más procesadores, que comprende: recopilar información histórica sobre el tiempo de inactividad de los robots y/o el número de transacciones realizadas por estos; recibir información en tiempo real sobre el tiempo de inactividad de los robots y/o el número de transacciones realizadas por los robots; con base en la información recibida determinar cuáles robots presentan un comportamiento anormal en los tiempos de inactividad y/o en el número de transacciones realizadas con respecto a la información histórica; y generar alertas en una interfaz de usuario.
2. El método de acuerdo con la reivindicación 1 , en donde para determinar cuáles robots presentan un comportamiento anormal se determina cuáles están inactivos y han iniciado actividad; se compara el tiempo que llevan inactivos con un valor umbral predeterminado; si el tiempo de inactividad es mayor al umbral preestablecido, se genera en la interfaz de usuario una alerta de un primer color; y si el tiempo de inactividad no es mayor al umbral preestablecido, se genera en la interfaz de usuario una alerta de un segundo color.
3. El método de acuerdo con cualquiera de las reivindicaciones precedentes, en donde para determinar cuáles robots presentan un comportamiento anormal, se determina cuáles robots inactivos han iniciado actividad en el día; se compara el número de transacciones realizadas por el robot en el día con el número promedio de transacciones diarias realizadas por el robot; si el número de transacciones realizadas por el robot en el día es mayor al número promedio de transacciones diarias realizadas por el robot, se genera una alerta de un primer color a la interfaz de usuario; si el número de transacciones realizadas por el robot en el día es menor al número promedio de transacciones diarias realizadas por el robot, se verifica si el tiempo en el que el robot ha estado inactivo en el día es menor o igual al tiempo de inactividad promedio histórico del robot; si el tiempo de inactividad del robot en el día es menor o igual al tiempo de inactividad promedio histórico del robot, se genera una alerta de un segundo color en la interfaz de usuario; y si el tiempo de inactividad del robot en el día es mayor al tiempo de inactividad promedio histórico del robot, se genera una alerta de un tercer color en la interfaz de usuario.
4. El método de acuerdo con cualquiera de las reivindicaciones precedentes, en donde para determinar cuáles robots presentan un comportamiento anormal, se determina cuáles robots registraron un tiempo de ejecución o una hora de finalización y si existe información que indica que inició actividad en el día; se verifica si el robot tiene un tiempo de ejecución; si tiene tiempo de ejecución, se compara el número de transacciones realizadas por el robot en el día con el número promedio de transacciones diarias realizadas por el robot; si el número de transacciones realizadas por el robot en el día es menor al número promedio de transacciones diarias realizadas por el robot, se verifica si el robot estuvo inactivo por un tiempo menor a un valor umbral predeterminado y si lo es, se genera una alerta de un primer color en la interfaz de usuario; si el robot estuvo inactivo por un tiempo mayor al umbral predeterminado, se genera una alerta de un segundo color en la interfaz de usuario; y si el número de transacciones realizadas por el robot en el día es mayor al número promedio de transacciones diarias realizadas por el robot, se genera una alerta de un tercer color en la interfaz de usuario.
5. El método de acuerdo con cualquiera de las reivindicaciones precedentes, en donde para determinar cuáles robots presentan un comportamiento anormal, se determina cuáles robots no tienen tiempo de ejecución, se verifica si tienen hora de finalización predeterminada; si tienen hora de finalización, se verifica si la hora actual se encuentra entre la hora de inicio y la hora de finalización y si lo está, se verifica si el robot estuvo inactivo por un tiempo menor a un valor umbral predeterminado y si lo es, se genera una alerta de un primer color en la interfaz de usuario; si el robot estuvo inactivo por un tiempo mayor al umbral predeterminado, se genera una alerta de un segundo color en la interfaz de usuario; si la hora actual no se encuentra entre la hora de inicio y la hora de finalización, se genera una alerta de un tercer color en la interfaz de usuario.
6. El método de acuerdo con cualquiera de las reivindicaciones precedentes, que además comprende validar las máquinas internas que ejecutan los robots que están activos, determinando si alguna está apagada y si lo está, generar una alerta en la interfaz del usuario.
7. El método de acuerdo con cualquiera de las reivindicaciones precedentes, que adicionalmente comprende calcular parámetros de desempeño de los robots, que se muestran en la interfaz de usuario.
8. El método de acuerdo con cualquiera de las reivindicaciones precedentes, que adicionalmente comprende determinar cuáles robots están en mantenimiento y/o en preproducción para descartarlos.
9. El método de acuerdo con cualquiera de las reivindicaciones precedentes, que además comprende verificar el estado de la clave de la una o más máquinas en las que se ejecutan los robots digitales y generar una alerta en la interfaz de usuario cuando la clave se haya vencido, cuando la clave esté próxima a vencerse, o cuando la clave se haya bloqueado.
10. El método de acuerdo con cualquiera de las reivindicaciones precedentes, que además comprende, determinar cuáles robots están en etapa de preproducción o mantenimiento y generar para estos alertas en la interfaz de usuario.
11. Un medio de almacenamiento legible por computador, acoplado a uno o más procesadores, que tiene instrucciones almacenadas que cuando se ejecutan por el uno o más procesadores, causan que el uno o más procesadores ejecuten el método de cualquiera de las reivindicaciones 1 a 8.
12. Un sistema que comprende uno o más procesadores, y un medio de almacenamiento legible por computador, acoplado al uno o más procesadores, que tiene instrucciones almacenadas que cuando se ejecutan por el uno o más procesadores, causan que el uno o más procesadores ejecuten el método de cualquiera de las reivindicaciones 1 a 8.
PCT/IB2020/057237 2019-08-02 2020-07-31 Métodos para el monitoreo de asistentes automatizados WO2021024122A1 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CONC2019/0008485 2019-08-02
CONC2019/0008485A CO2019008485A1 (es) 2019-08-02 2019-08-02 Métodos para el monitoreo de asistentes automatizados

Publications (1)

Publication Number Publication Date
WO2021024122A1 true WO2021024122A1 (es) 2021-02-11

Family

ID=67733384

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2020/057237 WO2021024122A1 (es) 2019-08-02 2020-07-31 Métodos para el monitoreo de asistentes automatizados

Country Status (2)

Country Link
CO (1) CO2019008485A1 (es)
WO (1) WO2021024122A1 (es)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015006246A1 (en) * 2013-07-06 2015-01-15 Cyara Solutions Corp. System and method for automated chat testing
US10307906B2 (en) * 2015-12-22 2019-06-04 Tata Consultancy Services Limited System and method for providing a proactive process automation among a plurality of software robotic agents in a network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015006246A1 (en) * 2013-07-06 2015-01-15 Cyara Solutions Corp. System and method for automated chat testing
US10307906B2 (en) * 2015-12-22 2019-06-04 Tata Consultancy Services Limited System and method for providing a proactive process automation among a plurality of software robotic agents in a network

Also Published As

Publication number Publication date
CO2019008485A1 (es) 2019-08-30

Similar Documents

Publication Publication Date Title
US20090138306A1 (en) Facility risk assessment systems and methods
CN108197845A (zh) 一种基于深度学习模型lstm的交易指标异常的监测方法
US11249835B2 (en) Automatic repair of computing devices in a data center
US20190027255A1 (en) Systems and methods for predicting and detecting hazardous conditions and facilitating regulatory compliance through automated communication platforms
US20130342349A1 (en) Systems and methods for hand hygiene compliance
France et al. A multicomponent fall prevention strategy reduces falls at an academic medical center
CN109791808A (zh) 远程数据分析和诊断
Oliveira et al. Managing technical debt in software projects using scrum: An action research
Odzaly¹ et al. Lightweight risk management in Agile projects
SE529228C2 (sv) Metod och system för att automatiskt bestämma vilket larm, genererat vid en industrianläggning, som skall döljas eller presenteras för en operatör
WO2016004350A2 (en) Systems and methods for monitoring product development
EP3012701A1 (en) Apparatus and method for managing operator alertness and enhancing operator effectiveness for industrial control systems
EP2954445A1 (en) Methods and apparatus for data-driven monitoring
CN108713192A (zh) 计算机系统修复的自动排序
WO2021024122A1 (es) Métodos para el monitoreo de asistentes automatizados
RU114186U1 (ru) Автоматизированная система мониторинга технического состояния и поддержки принятия управляющих решений по повышению безопасности и надежности комплексов гидротехнических сооружений гидроэлектростанций и иных объектов
Amelia et al. Optimising outpatient pharmacy staffing to minimise patients queue time using discrete event simulation
RU2460127C1 (ru) Автоматизированная система мониторинга технического состояния и поддержки принятия управляющих решений по повышению безопасности и надежности комплексов гидротехнических сооружений гидроэлектростанций и иных объектов
CN116703178A (zh) 生产产能的分析方法、分析装置、非瞬时性计算机可读介质以及计算机程序产品
Ching et al. Evaluating agile and lean software development methods from a system dynamics perspective
El-Banna Improving Patients Discharge Process in Hospitals by using Six Sigma Approach
Jones et al. Results of medical countermeasure drills among 72 Cities Readiness Initiative metropolitan statistical areas, 2008-2009
Fauzi et al. Android-Based RCSM Application for Implementation of Preventive Maintenance on CNC Production Machine
Shelton et al. Building performance-based accountability with limited empirical evidence: performance measurement for public health preparedness
US20120226508A1 (en) System and method for healthcare service data analysis

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20849091

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20849091

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 20849091

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 20.10.2022)

122 Ep: pct application non-entry in european phase

Ref document number: 20849091

Country of ref document: EP

Kind code of ref document: A1