Está en la página 1de 242

UNIVERSIDAD RICARDO PALMA

ESCUELA DE POSGRADO

MAESTRÍA EN INGENIERÍA INFORMÁTICA CON MENCIÓN EN


INGENIERÍA DE SOFTWARE

LA ROBOTIC PROCESS AUTOMATION Y LA PRODUCTIVIDAD


DEL ÁREA DE PAGOS – EMPRESA DEL SECTOR RETAIL

TESIS

PARA OPTAR EL GRADO ACADÉMICO DE MAESTRO EN


INGENIERÍA INFORMÁTICA CON MENCIÓN EN INGENIERÍA DE
SOFTWARE

AUTOR

AVILA GALINDO, RUBEN

(ORCID: 0009-0009-7701-3399)

ASESOR

SAITO SILVA, CARLOS AGUSTIN

(ORCID: 0000-0002-8328-5157)

LIMA, PERÚ

2023
Metadatos Complementarios
Datos de autor
Avila Galindo, Ruben
Tipo de documento de identidad del AUTOR: DNI
Número de documento de identidad del AUTOR: 42229478

Datos de asesor
Saito Silva, Carlos Agustin
Tipo de documento de identidad del ASESOR: DNI
Número de documento de identidad del ASESOR: 07823525

Datos del jurado


JURADO 1: Marticorena Ramos, Walter Edwin, DNI N° 20082621,
ORCID 0000-0001-8718-0435

JURADO 2: Velazquez Nuñez, Angel Augusto, DNI N° 09641061, ORCID


0000-0001-9668-6972

JURADO 3: Suarez Avelino, Olga Dina, DNI N° 08585872, ORCID 0000-


0001-9532-1461

Datos de la investigación
Campo del conocimiento OCDE: 612357
Código del Programa: 1.02.00
Dedicatoria

A Dios, a mi madre por siempre darme un


ejemplo de superación y constancia para
salir de las adversidades, a mi esposa y mi
hijo quiero decirles que este logro también
es suyo por ser mi fuente de inspiración y
motivación, a mi asesor y jurados por
compartir su tiempo y conocimiento,
muchas gracias.

Por: Ruben Avila Galindo


Agradecimientos

Quiero expresar mi agradecimiento a mi


asesor Mg. Carlos Saito Silva, por su
invaluable apoyo y orientación durante todo
el proceso de investigación para concluir
con el presente trabajo de investigación.

Además, agradecer a los miembros del


jurado que con sus recomendaciones y
observaciones permitieron corregir y
culminar el presente trabajo de
investigación.
ÍNDICE

RESUMEN....................................................................................................7
ABSTRACT..................................................................................................8
INTRODUCCIÓN........................................................................................9
CAPÍTULO I: PLANEAMIENTO DEL ESTUDIO..................................11
1.1. Descripción del problema.......................................................................11
1.2. Formulación del problema......................................................................17
1.2.1 Problema General................................................................17
1.2.2 Problemas Específicos.........................................................17
1.3. Importancia y Justificación del estudio...................................................18
1.4. Delimitación del estudio.........................................................................24
1.5. Objetivos generales y específicos...........................................................25
1.5.1 Objetivo general...................................................................25
1.5.2 Objetivos específicos...........................................................25
CAPÍTULO II: MARCO TEÓRICO..........................................................26
2.1. Marco histórico.......................................................................................26
2.2. Investigaciones relacionadas con el tema...............................................45
2.3. Estructura teórica y científica que sustenta el estudio............................57
2.4. Definición de términos básicos.............................................................133
2.5. Fundamentos teóricos que sustentan las hipótesis................................138
2.6. Hipótesis...............................................................................................139
2.6.1 Hipótesis general...............................................................139
2.6.1 Hipótesis especificas..........................................................139
2.7. Variables................................................................................................140
CAPÍTULO III: MARCO METODOLÓGICO........................................141
3.1. Tipo, método y diseño de la investigación............................................141
3.2. Población y muestra..............................................................................146
3.3. Técnicas e instrumentos de recolección de datos.................................149
3.4. Descripción de procedimientos de análisis...........................................152
Capítulo IV: RESULTADOS Y ANÁLISIS DE RESULTADOS...........153
4.1. Resultados.............................................................................................153
4.2. Análisis de resultados...........................................................................192
CONCLUSIONES Y RECOMENDACIONES........................................213
REFERENCIA..........................................................................................217
ANEXOS...................................................................................................221
Anexo 1: Declaración de Autenticidad.........................................................221
Anexo 2: Autorización de consentimiento para realizar la investigación.....222
Anexo 3: Matriz de consistencia...................................................................223
Anexo 4: Matriz de Operacionalización........................................................224
Anexo 5: Tema de Tesis en su idioma original, Implementation of Robotic
Process Automation to a Target Process – a Case Study)....................225
Anexo 6: Protocolos o Instrumentos utilizados.............................................226
Anexo 7: Formatos de Instrumentos utilizados o protocolos utilizados.......227
Anexo 8: Tablas de validez y confiabilidad..................................................228

1
ÍNDICE DE TABLAS

Tabla 01: Etapas del proyecto y sus contenidos resumidos............................................70


Tabla 02: Etapas de un proyecto de TI, basado en Cooper y Zmud (1990)....................71
Tabla 03: Resumen de los factores críticos de éxito más comunes.................................77
Tabla 04: Lista de factores clave de RPA. Adaptado por Willcocks (2015B).................80
Tabla 05: Roles en el proceso de RPA.............................................................................82
Tabla 06: CSF relevantes para RPA y sus fases del ciclo de vida..................................93
Tabla 07: Los Costos Anuales del Sistema RPA............................................................102
Tabla 08: Diseño de Investigación Cuasi-Experimental...............................................144
Tabla 09: Diseño Cuasi-Experimental..........................................................................144
Tabla 10: Población y Muestra PRE y POST por cada una de las variables...............148
Tabla 11: Técnicas e instrumentos................................................................................151
Tabla 12: Matriz de Análisis de datos...........................................................................152
Tabla 13: Muestra Pre Test Tiempo de transacción por factura en promedio............156
Tabla 14: Muestra Post Test Tiempo de transacción por factura (usando Tarea con
RPA)............................................................................................................168
Tabla 15: Muestra Pre Test Tiempo de Validación por factura....................................171
Tabla 16: Muestra Post Test Validación por factura (usando Controles avanzados con
RPA)............................................................................................................179
Tabla 17: Muestra Pre Test de Horas trabajadas por Mes...........................................182
Tabla 18: Muestra Post Test Horas Trabajadas por mes..............................................189
Tabla 19: Cálculo de valor de ahorro de tiempo..........................................................191
Tabla 20: Muestra Pre Test y Post Test de tiempo de transacción por factura............195
Tabla 21: Resumen de procesamiento de datos – tiempo de transacción por factura
muestras Pre Test y Post Test......................................................................196
Tabla 22: Estadísticas de grupo – Muestras pre y post test..........................................196
Tabla 23: Prueba de Normalidad para tiempo de transacción por factura de las
muestras Pre Test y Post Test......................................................................197
Tabla 24: Estadísticas de muestras emparejadas para tiempo de transacción por
factura en promedio....................................................................................199
Tabla 25: Prueba de hipótesis de T de Student de muestras emparejadas para tiempo
de transacción por factura en promedio.....................................................199

2
Tabla 26: Muestra Pre Test y Post Test de tiempo de validación por factura..............201
Tabla 27: Resumen de procesamiento de datos –tiempo de validación por factura
muestras Pre Test y Post Test......................................................................202
Tabla 28: Estadísticas de grupo – Muestras pre y post test..........................................202
Tabla 29: Prueba de Normalidad para tiempo de validación de facturas de las muestras
Pre Test y Post Test.....................................................................................203
Tabla 30: Estadísticas de muestras emparejadas para validación por factura en
promedio......................................................................................................205
Tabla 31: Prueba de hipótesis de T de Student de muestras emparejadas para
validación de factura en promedio..............................................................205
Tabla 32: Muestra Pre Test y Post Test de horas trabajadas por Mes.........................207
Tabla 33: Resumen de procesamiento de datos – reducir las horas de trabajo muestras
Pre Test y Post Test.....................................................................................208
Tabla 34: Estadísticas de grupo – Muestras pre y post test..........................................208
Tabla 35: Prueba de Normalidad para reducir las horas de trabajo de las muestras Pre
Test y Post Test............................................................................................209
Tabla 36: Estadísticas de muestras no paramétricas para reducir las horas de trabajo
en promedio.................................................................................................211
Tabla 37: Resumen de resultados..................................................................................212
Tabla 38: Matriz de Consistencia..................................................................................223
Tabla 39: Matriz de Operacionalización.......................................................................224
Tabla 40: Matriz de datos por cada variable PRE........................................................227
Tabla 41: Matriz de datos por cada variable POST......................................................227
Tabla 42: Matriz de Análisis de datos...........................................................................228

3
ÍNDICE DE FIGURAS

Figura 01: Constitución de nuevas MyPEs2004 – 2010 (Sunat)....................................12


Figura 02: El proceso de área de pagos. Empresa retail. Elaboración: propia...............13
Figura 03: Resultados de encuesta de áreas con carga de trabajo 2019, % de
encuestados. Empresa retail. Elaboración propia..........................................14
Figura 04: crecimiento en las ventas online en retail - INEI..........................................15
Figura 05: Cambio en el gasto familiar según nivel de ingresos, 2013-2018 - INEI.....16
Figura 06: Beneficios de RPA y Métricas mejoradas – Elaboración Propia..................20
Figura 07: Todas las organizaciones encuestadas utilizan al menos un tipo de
automatización. Estudio C-Suite del segundo trimestre de 2017 realizado por
el IBM Institute of Business Value...............................................................29
Figura 08: Las tecnologías asociadas a la IA impulsan la automatización inteligente...29
Figura 09: Los usuarios que actualmente utilizan funciones de automatización
impulsadas por la IA hablan de un impacto significativo y esperan que se
produzca. Estudio C-Suite del segundo trimestre de 2017 realizado por el
IBM Institute of Business Value...................................................................30
Figura 10: Muchas de las tareas de recopilación de información implicadas en la
gestión de un siniestro se pueden automatizar, lo que permite que el personal
se centre en tareas de investigación, decisión y resolución. Estudio realizado
por el IBM Institute for Business Value........................................................33
Figura 11: El nivel de automatización necesario para cada proceso varía en función de
la naturaleza de las tareas del proceso...........................................................34
Figura 12: Las capas de software. Adaptado por Willcocks (2015B)............................59
Figura 13: Las capas de software. Adaptado por Lacity (2015A)..................................60
Figura 14: Valor RPA entregado. Adaptado por Willcocks. (2015B)............................67
Figura 15: Ciclo de vida de un Proyecto. Adaptado por Artto (2006)...........................69
Figura 16: Fases de implementación de un proyecto.....................................................69
Figura 17: Fases de una implementación ERP. Adaptado de Parr y Shanks (2000)......70
Figura 18: Jerarquía del éxito del proyecto (adaptado por Baccarini, 1999)..................73
Figura 19: Roles y su Jerarquía......................................................................................82
Figura 20: Ciclo de vida del proyecto en forma general................................................84

4
Figura 21: Proyecto de ciclo de vida y sus etapas explicadas........................................86
Figura 22: Proyecto de ciclo de vida y CSF combinados...............................................94
Figura 23: Mapa conceptual que sustentan las hipótesis. Elaboración: propia............138
Figura 24: Diseño Cuasi experimental. Elaboración Propia.........................................145
Figura 25: Magic Quadrant for Operational Database Management Services. (Gartner,
2019)............................................................................................................150
Figura 26: Diagrama de Ishikawa para el problema general. Elaboración propia.......154
Figura 27: Tiempo de transacción por factura en promedio. Elaboración propia........156
Figura 28: Manual and automated process workflow (HerbertNathan, 2017)..............159
Figura 29: Extracción de PDF de OneDrive Microsoft 365..........................................159
Figura 30: Muestra de una Factura Electrónica de un proveedor. Elaboración propia. 160
Figura 31: Muestra de un XML de una factura electrónica. Elaboración propia.........162
Figura 32: Extracción de datos del XML y validación con el SAP Hana. Elaboración
Propia...........................................................................................................163
Figura 33: Diagrama del sistema usando RPA. Elaboración propia............................163
Figura 34: Reporte de Proveedores con sus facturas electrónicas procesados con RPA.
Elaboración Propia......................................................................................165
Figura 35: Lista de Métricas y tiempo de transacción por factura realizados por el Bot
con RPA. Elaboración propia......................................................................166
Figura 36: Listado de validaciones realizados por el RPA. Elaboración propia..........167
Figura 37: Reducción de Tiempo de transacción por factura después de implementar
tareas con RPA. Elaboración propia............................................................168
Figura 38: Tiempo de validación por factura. Elaboración propia...............................171
Figura 39: Controles avanzados de RPA para las diferentes plataformas. (Taulli, 2020)
.....................................................................................................................172
Figura 40: Control avanzado RPA para validación de datos de factura electrónica.
Elaboración Propia......................................................................................174
Figura 41: Diagrama usando Controles Avanzados de RPA. Elaboración propia.......175
Figura 42: Lista de métricas y basado en controles avanzado con RPA. Elaboración
propia...........................................................................................................177
Figura 43: Validaciones de factura electrónica por tipo documento y estado.
Elaboración propia.......................................................................................178
Figura 44: Reducción de Tiempo de validación de factura después de implementar
controles avanzados con RPA. Elaboración propia.....................................179

5
Figura 45: Horas trabajadas por mes en el proceso de registro de facturas electrónicas.
Elaboración propia.......................................................................................181
Figura 46: Proceso tradicional y el Proceso de registro con RPA. Elaboración Propia.
.....................................................................................................................184
Figura 47: Control Avanzado para el registro de factura en SAP Hana.......................185
Figura 48: Diagrama usando Controles de SAP Hana con RPA. Elaboración propia. 186
Figura 49: Registro de factura en SAP Hana con Automation Anywhere(RPA).
Elaboración propia.......................................................................................187
Figura 50: Validación y registro de una factura electrónica en SAP Hana. Elaboración
Propia...........................................................................................................188
Figura 51: Reducción de horas de trabajo después de implementar el rediseño al
proceso de registro con RPA. Elaboración propia.......................................189
Figura 53: Magic Quadrant for Operational Database Management Services. (Gartner,
2019)............................................................................................................229

6
RESUMEN

El propósito de la presente investigación es implementar la Robotic Process Automation


(RPA) y mejorar la productividad en el área de pagos en una empresa del sector retail,
evaluando los indicadores tiempo de transacción por factura, tiempo de validación de
factura y horas de trabajo.

Para el desarrollo se utilizó como base la automatización de procesos simulando robots


que reemplaza tareas operativas realizadas por el personal del área de pagos, Los robots
en este caso no son físicos, sino una evolución del software, permitiendo la
automatización de porciones de procesos que no requieran del juicio humano.

Para el desarrollo de la investigación, se obtuvieron datos del área de pagos de la


empresa retail. Para la experimentación se seleccionaron 1000 facturas electrónicas que
recibe diariamente el área de pagos del sector retail a los cuales se aplicaron a los
indicadores tiempo de transacción por factura, tiempo de validación de factura y horas
de trabajo. Se midieron los datos del antes y después de aplicar Robotic Process
Automation (RPA).

Al culminar el desarrollo de la Robotic Process Automation (RPA) en el Área de pagos,


se demostró la hipótesis que mediante la implementación de la Robotic Process
Automation se mejoró los indicadores de tiempo de transacción por factura, tiempo de
validación de factura y horas de trabajo. Pudiendo realizar los pagos de manera
oportuna.

Como resultado de la presente investigación se logró disminuir el proceso en el área de


pagos en un 80.70% agilizando todo el flujo del proceso de las facturas electrónicas
estudiados, de la misma forma, se logró reducir los errores en el registro de la factura en
un 98% aplicados al proceso, finalmente el porcentaje del costo de hora-humano que es
de 138% mayor en comparación con el costo de hora-robot se redujo en 62%.

Palabras clave: Automatización Robótica de Procesos, Facturas electrónicas, Sector


retail, Productividad.

7
ABSTRACT

The purpose of this research is to implement Robotic Process Automation (RPA) and
improve productivity in the payment area in a company in the retail sector, evaluating
the indicators transaction time per invoice, invoice validation time and working hours.

For the development, the automation of processes was used as a basis, simulating robots
that replace operational tasks carried out by the personnel of the payment area. The
robots in this case are not physical, but rather an evolution of the software, allowing the
automation of portions of processes that are not require human judgment.

For the development of the investigation, data was obtained from the payment area of
the retail company. For the experimentation, 1000 electronic invoices received daily by
the payment area of the retail sector were selected, to which the indicators transaction
time per invoice, invoice validation time and working hours were applied. The data
before and after applying Robotic Process Automation (RPA) were measured.

Upon completion of the development of the Robotic Process Automation (RPA) in the
Payment Area, the hypothesis was demonstrated that by implementing the Robotic
Process Automation the indicators of transaction time per invoice, invoice validation
time and hours of operation were improved. job. Being able to make payments in a
timely manner.

As a result of the present investigation, it was possible to reduce the process in the
payment area by 80.70%, streamlining the entire process flow of the electronic invoices
studied, in the same way, it was possible to reduce the errors in the registration of the
invoice in a 98% applied to the process, finally the percentage of the human-hour cost
that is 138% higher compared to the robot-hour cost was reduced by 62%.

Keywords: Robotic Process Automation, Electronic invoices, Retail Sector,


Productivity

8
INTRODUCCIÓN

El presente trabajo de tesis tiene como objetivo la construcción de Robotic Process


Automation (RPA) para el área de pagos aplicado a empresa del sector retail, en el cual
se establecen las directrices necesarias para mejorar los indicadores de tiempo de
transacción por factura, tiempo de validación de factura y horas de trabajo.

El marco de Robotic Process Automation (RPA) establece un flujo de trabajo para el


diseño de un bot, en el cual se establece los siguientes pasos: Establece la alineación
entre negocio y RPA, definir el diseño organizacional, formar una junta de gobierno de
RPA, acordar la metodología de entrega de RPA, establecer apoyo y definir roles y
responsabilidades. (Willcocks, Lacity y Craig, 2017).

Se siguieron los pasos para la construcción de un bot para el área de pagos, haciendo
coincidir las estrategias de la organización aplicadas a los indicadores del área de pagos.

La pregunta central del presente trabajo fue ¿cómo mejorar la productividad del área de
pagos en una empresa del sector retail en los indicadores del área de pagos de una
empresa del sector retail para el periodo 2019-2020, en la cual se plantea mejorar los
indicadores aplicado a las siguientes variables tiempo en la transacción por factura,
registro de factura, horas de trabajo, al mejorar los indicadores, lo cual se traduce en
generar un ahorro de tiempo para la empresa. Se constituye el objetivo de la presenta
investigación en implementar Robotic Process Automation (RPA) en el área de pagos
para mejorar los indicadores de una empresa del sector retail.

La hipótesis general de la investigación busca demostrar que mediante la


implementación de Robotic Process Automation se mejorara los indicadores del área de
pagos para una empresa del sector retail, de esta manera los indicadores son evaluados
desde una perspectiva distinta, evaluando el comportamiento de cada variable de la
investigación.

9
El presente trabajo de tesis se divide de la siguiente manera.

Capítulo I: Planteamiento del estudio. En la siguiente sección abarca la descripción de la


problemática, formulación del problema, importancia y justificación del estudio,
delimitación del problema y los objetivos generales y específicos, en este capítulo se
aborda la necesidad de la investigación exponiendo la problemática con respecto a los
indicadores: tiempo de transacción por factura, tiempo de validación de factura y horas
de trabajo.

Capítulo II Marco Teórico: En el presente capítulo se desarrolla la base teórica de la


investigación en lo que se expone los temas relacionados al marco Robotic Process
Automation (RPA) las buenas prácticas y la teoría necesaria para una construcción un
bot para el área de pagos, exponiendo el contexto histórico, las investigaciones
relacionadas, los fundamentos teóricos, el marco científico, las definiciones de palabras
claves, la hipótesis y la variable dependiente e independiente del estudio.

Capítulo III Marco Metodológico: En este capítulo se expone la metodología de la


investigación que se aplicará, describiendo el tipo de investigación, población, muestra
y las técnicas e instrumentos de recolección de datos.

Capítulo IV Resultados y análisis de resultados: En el presente capítulo se construye el


Robotic Process Automation en el área de pagos aplicado a las variables dependientes
tiempo en la transacción por factura, registro de factura y horas de trabajo,
posteriormente se exponen los resultados de la investigación.

Capítulo V Conclusión y Recomendación: En este capítulo se presentan las


conclusiones y recomendaciones del trabajo de investigación.

10
CAPÍTULO I: PLANEAMIENTO DEL ESTUDIO

1.1. Descripción del problema

En el Perú, las empresas están obligadas a utilizar comprobantes de pago


electrónicos, los cuales son archivos en formato XML (extensible Markup
Language) que contienen todos los datos que tendría un comprobante físico,
además están firmados digitalmente y pueden ser consultados a través del portal
web de la superintendencia nacional de aduanas y de administración tributaria
(Sunat) y también a través de un portal web habilitado por la empresa emisora del
comprobante.

Hoy en día el sector retail enfrenta un reto grande en recibir miles de comprobantes
electrónicos de distintos proveedores todos los días y debe asegurar la recepción y
la validación de cada documento sea correctamente emitida ante Sunat.

Al realizar este proceso se encuentra con problemas del gran volumen de


comprobantes que recibe 1000 facturas electrónicas diariamente el área de pagos
para realizar oportunamente los pagos de sus proveedores.

11
En la Figura 01 se aprecia que cada año se está incrementando la creación de
nuevas pymes que tendrá la misma necesidad para este trabajo de investigación de
tesis.

Figura 01: Constitución de nuevas MyPEs2004 – 2010 (Sunat)

En la actualidad la empresa retail para esta investigación el proceso inicia con la


recepción de la factura por correo y se verifica que contenga los importes de
acuerdo a la orden de compra que se le envió al proveedor.

Posteriormente se procede a validar la factura emitida ante Sunat para ver si el


proveedor no tiene alguna restricción para emitir comprobantes electrónicos, si
hubiera algunas inconsistencias en la factura electrónica se le notifica al proveedor
enviándole a un correo de contacto para que pueda subsanar en los plazos
acordados entre la empresa y el proveedor.

Después de la verificación del comprobante satisfactorio se obtiene el visto bueno


por el área de pagos, se procede a registrar la factura con sus detalles y tributos
(Subotal, Igv, Total) y su guía de remisión.

12
En esta parte del proceso al usuario para realizar estas actividades mencionadas
anteriormente le toma en tiempo promedio de 10 minutos, luego el siguiente paso
es verificar si se tiene fondos disponibles para el pago respectivo y calendarizar la
fecha de pago la cual a su vez necesita las aprobaciones de los jefes de área y
finalmente se notifica con un correo electrónico que se realizó el pago de su factura
al proveedor.

En todo el proceso descrito anteriormente se tiene la necesidad de reducir el ciclo


de vida del proceso con las actividades repetitivas que les demanda a los empleados
para cumplir con todo el proceso y en fechas de alta demanda se incrementa los
documentos y como consecuente que trabajar más horas hombre o contratar gente
externa para cumplir con todo el flujo del proceso de todos los fines de mes en todo
el año.

Para dicho proceso de la empresa retail se tiene a tres (03) personas actualmente en
el área de pagos, para ejecutar todo el proceso le toman mucho más tiempo. Al no
disponer de información precisa, exacta y confiable presenta una gran dificultad
para realizar los pagos oportunos a los proveedores en las fechas establecidas entre
la empresa retail y el proveedor. Ver Figura 02.

Figura 02: El proceso de área de pagos. Empresa retail. Elaboración: propia

13
Al terminar el proceso se encuentra con problemáticas de que del 100% de
comprobantes electrónicos registrados en el sistema, en promedio el 40% tienen
errores en el registro de la factura teniendo que reprocesar todo el proceso
nuevamente teniendo que invertir tiempo en horas extras con trabajadores externos
para poder llegar a poder corregir todo así ocasionando un retrabajo y a la empresa
gastos externos para poder contratar personal para poder regularizar los pagos a los
proveedores. Esto generaría perdidas a la empresa por no tener insumos para poder
fabricar sus productos y poder vender a los clientes.

Se realizó una encuesta a los 300 empleados de la empresa retail para saber qué
áreas de la empresa tiene la mayor carga laboral con actividades repetitivas que
demandan horas hombres y con eso detectar los cuellos de botella de trabajo. Ver
Figura 03.

Resultados de encuesta de areas con carga de trabajo 2019,


% de encuestados
Cuentas por pagar 91%
Gastos de Viaje 55%
Activos Fijos 36%
Administracion del Libro Mayor 27%
Comercializacion 18%
Servicio al Cliente 18%
Administración de Crédito 18%
Informacion Financier 18%
Compensacion 9%
Gestión de Tarjeta de Pagos 9%
Nómina 9%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Figura 03: Resultados de encuesta de áreas con carga de trabajo 2019, % de


encuestados. Empresa retail. Elaboración propia

Adicionalmente la conclusión de aquella encuesta evidencio la importancia de


automatizar el proceso porque representa el área de pagos como la más perjudicada
por tener la carga de trabajo más pesada de su proceso en poder entregar los pagos a
los proveedores en la fecha acordada y no quedarse sin insumos para elaboración de
sus productos.

14
También al ser un proceso donde interviene la parte operativa por una persona
humana existe el riesgo que puede confundir con el ingreso de datos de la factura y
conllevara a no tener una exactitud del 100% que todo registro de factura haya sido
realizado exitosamente.

Esto ocasiona como consecuencia que el sector retail pierdan oportunidades de


negocios, que no tenga el debido seguimiento y control adecuado de sus productos
o servicios que puedan ofrecer a sus clientes, como también no tener la información
disponible en el momento oportuno.

Los altos costos de adquisición o desarrollo de Sistemas de Gestión Empresarial


hacen que el sector retail no pueda adquirir herramientas de Tecnológicas de
Información y Comunicación (TIC) las cuales requieren estos sistemas generando
un monopolio solo para las grandes empresas que cuentan con el capital para
invertir en Sistemas de Gestión Empresarial y TIC.

Según un estudio de Ipsos Perú, el 61% de adultos peruanos es digital y el 43% se


conecta todos los días. El producto más pedido por Internet es la comida rápida y el
porcentaje promedio que un trabajador dependiente gasta en diversión asciende al
8%, aproximadamente de su salario mensual.

Según IPE, los productos más pedidos por Internet son comida rápida (22%), ropa
(19%), entradas para cine (16%), calzado/zapatos/ zapatillas (14%), pagar taxis
(12%). Ver Figura 04. (Instituto Nacional de Estadistica e Informatica en el Peru,
2020)

15
Figura 04: crecimiento en las ventas online en retail - INEI

En cuanto a tendencias de consumo de alimentos, según una encuesta elaborada por


Kantar Worldpanel en el 2018, el 87% de los hogares peruanos piden productos
más nutritivos. En ese sentido, el 66% de hogares por ejemplo afirmó incrementar
en su dieta las frutas y verduras mientras que el 71% de hogares disminuyó el
consumo de gaseosas.

“Hoy los consumidores peruanos están comprando más productos más nutritivos,
seguido por los más económicos, más prácticos, o mayor variedad de colores,
sabores y aromas. Sin embargo, vemos que caen el consumo de gaseosas con
(71%)”, sostuvo el economista. Ver Figura 05.

16
Figura 05: Cambio en el gasto familiar según nivel de ingresos, 2013-2018 - INEI

17
1.2. Formulación del problema

1.2.1 Problema General

¿Cómo mejorar la productividad del área de pagos en una empresa del


sector retail?

1.2.2 Problemas Específicos

a) ¿Cómo reducir las horas de trabajo?

b) ¿Cómo reducir los errores por el registro de factura?

c) ¿Cómo reducir el tiempo en la transacción por factura?

18
1.3. Importancia y Justificación del estudio

 Importancia del estudio

Teniendo el conocimiento el problema por el que está pasando el sector retail


en el Perú es que resulta de vital importancia que en la presente investigación
para lograr la aplicación de Robotic Process Automation – RPA mejorar en la
productividad y permita mejorar el proceso en el área de pagos.

El software RPA es ideal para reemplazar a los seres humanos en los llamados
procesos de "silla giratoria"; procesos en los que los seres humanos toman
información de un conjunto de sistemas, procesan esa información usando
reglas y luego introducen las salidas en sistemas de registro.

La automatización robotizada de procesos (RPA) es una tecnología emergente


y rentable que automatiza tareas repetitivas y manuales que pierden tiempo.

Utiliza robots de software y reglas empresariales inteligentes para imitar la


acción que realizan los empleados, como buscar, verificar información, copiar
y pegar entre sistemas de back-office, sitios web públicos, hojas de cálculo de
Excel y otras fuentes de datos.

Además, se obtendrán los siguientes beneficios de la automatización robotizada


de procesos:
 Ahorro de Recursos humanos.
 Cobertura del servicio las 24 horas (los robots no comen ni duermen).
 Mano de trabajo virtual flexible porque los robots pueden ser hábiles en
cualquier tarea.
 Calidad Consistente (los robots no cometen errores).
 Prestación de servicios más rápida (los robots son más rápidos que los
humanos).

19
 Despliegue más rápido de nuevas funcionalidades (RPA es más fácil de
implementar que otras soluciones de TI).
 Soluciones altamente escalables para satisfacer los aumentos en la
demanda del servicio.
 Trabajadores más felices porque las tareas aburridas son hechas por los
robots, liberándolos para centrarse en las tareas que requieren el juicio,
la empatía, y las interacciones sociales.

El simple hecho de potencialmente de automatizar el trabajo hecho por una


persona humana en el área de pagos ya está acelerando el proceso y por lo
tanto entre más rápido el registro de la factura, más rápido el proveedor tendrá
sus pagos puntuales y aumentar la productividad.

Además, no solo se reduce el tiempo en el registro de la factura, si no


tendremos una exactitud al 100% y reducir empleados en el proceso para que
sean reasignados a trabajos de analítica.

Ante el presente estudio consentirá generar productividad en el área de pagos,


repercutiendo en su eficacia y eficiencia en la empresa Retail.

Adicional a la posibilidad de agregar controles y de incrementar la eficiencia


de los procesos, hay otros beneficios que pueden ser asociados con RPA: la
estandarización, la optimización del tiempo de entrega con un bajo costo de
implementación la reducción del periodo de ROI.

Esto abre las puertas a que se utilice el “insourcing” en los procesos, lo cual
otorga mayor control sobre el modelo de entrega de servicios, mejora la calidad
y consistencia de los datos lo cual deriva en mejoras de “analytics” y en
ingresos.

Utilizar RPA es seguro ya que las actividades ejecutadas por un robot pueden
ser monitoreadas y grabadas, lo cual genera información valiosa que se puede
utilizar para mejorar los procesos o atender requerimientos de auditorías.

20
Los robots ejecutan tareas de forma precisa lo cual incrementa la capacidad y
la productividad. La automatización de procesos permite liberar tiempo de
talento humano para que puedan obtener nuevas habilidades e incrementar la
eminencia de un negocio.

El Remplazo de FTEs (Full Time Equivalents), la tasa de retorno, la


productividad, la precisión, el número de errores, el tiempo de respuesta y el
tiempo de ejecución de procesos, son tan solo algunos de los indicadores
mejorados con la implementación de RPA. Ver Figura 06.

Figura 06: Beneficios de RPA y Métricas mejoradas – Elaboración Propia

Por consiguiente, los empleados o incluso los gerentes tendrán la información


al día y de esa manera priorizar con facilidad los pagos a los proveedores y no
tener que reprocesar de nuevo todos los documentos errados en todo el ciclo
del proceso.

Otro factor que hace que este estudio sea no solo importante si no también
necesario es acerca rediseñar el proceso y corregir la problemática de la
productividad en el área de pagos.

Esta es una problemática basada en el error humano y además porque el


registro de factura es frecuentemente equivocado en su ingreso en el sistema, lo

21
cual conlleva a que no se podrá cumplir con los pagos con los proveedores
generando malestar y no tener terminada todo el proceso exitoso.

Asi mismo esta investigación contribuirá al campo el uso de RPA aplicada al


sector retail porque es una aplicación que une directamente con la
automatización del proceso con robots y tener la información oportuna.

Hasta ahora hemos hablado de RPA como una tecnología emergente, la cual ya
está siendo aplicada en algunas empresas. Pero, ¿Qué nos espera para el 2025?

Los cambios tecnológicos van a pasos agigantados, se espera que en el 2017 la


mayoría de los grandes negocios implementen RPA, así como otros procesos
de automatización, lo que generara grandes cambios para las organizaciones.

La tecnología demanda nuevos roles en las empresas y por lo tanto nuevas


habilidades de trabajo, para las cuales debe estar preparada la fuerza laboral.

Para el 2020, RPA será una herramienta común y se espera que para el 2025
sea común encontrar maquinas inteligentes con capacidad de aprendizaje en
gran parte de los negocios, sobrepasando la limitante transaccional de los
sistemas actuales.

La tecnología futura nos llevará a trabajar de la mano con máquinas


inteligentes, por lo que tendremos que desarrollar nuevas capacidades de
trabajo.

La automatización nos llevará a utilizar tecnología cognitiva avanzada con


capacidades similares a los humanos; capaz de reconocer tipografías,
identificar imágenes y procesar el lenguaje natural.

Combinado con la automatización robótica puede ejecutar tareas no rutinarias


como insumos y salidas de datos en cualquier formato, reconocimiento de
patrones en fuente de datos no estructurados, réplica de actividades basadas en
juicio y capacidad de aprendizaje básico.

22
 Justificación del estudio

Justificación Teórica

Robotic Process Automation (RPA) es el uso de herramientas de software que


funcionan como una fuerza laboral virtual. RPA puede ejecutar tareas
predeterminadas basadas en reglas, imitando la interacción humana con
aplicaciones existentes para automatizar procesos completos o actividades
específicas.

Justificación Metodológica

Actualmente hablamos de Robotic Process Automation (RPA) como un


método de automatizar procesos principalmente transaccionales, basados en
reglas específicas.

En este caso, no hablamos de un robot físico como el que se instala en una


línea de manufactura, sino nos referimos a un software que aprende de un
usuario de negocio y lo asiste con tareas relativamente sencillas.

Utiliza reglas lógicas pre-construidas para entregar resultados. Está


conformado por macros con capacidad de realizar múltiples funciones a través
de múltiples plataformas.

Es una herramienta flexible, construida de tal forma que permite adaptarse a


los procesos actuales de cada empresa, funciona al interactuar e imitar a los
seres humanos que ejecutan el proceso.

Justificación Práctica

Esta investigación tiene como objetivo aplicar controles avanzados de RPA


para automatizar el proceso de cuentas por pagar lo cual el RPA estandariza y

23
optimiza procesos, mejorando la calidad y el costo de entrega de la
información.

Justificación Económica

Los robots pueden ejecutar tareas de manera precisa 24x7, lo cual incrementa
la capacidad de procesamiento de los procesos y lo cual permitirá disminuir los
egresos por contratación de personal externo para la empresa.

Justificación Social

La automatización de procesos ayuda a liberar el tiempo del talento humano,


para que puedan desarrollar nuevas competencias e incrementar la eminencia
de un negocio.

Justificación Legal

Automation Anywhere Enterprise envía una licencia de prueba con un periodo


de evaluación de 30 días. Esto le brinda al usuario la capacidad de evaluar el
producto y tomar una decisión informada. A su vez existe licencia anual del
producto que se tiene que pagar al fabricante.

Justificación Ecológica

La presente investigación permitirá una transformación digital que conllevara


al uso de documentos electrónicos que esto beneficiara a ya no consumir papel
y así ya no se va a depredar los árboles de la amazonia que son el pulmón del
mundo.

24
1.4. Delimitación del estudio

 Delimitación espacial

La presente investigación se realizó en una empresa tipo retail en el área de


cuentas por pagar con la Aplicación de Robotic Process Automation – RPA.

Por tanto, la aplicación de robotic process automation – RPA será útil para las
empresas con características similares y como referencia para otras empresas.

La aplicación de robotic process automation por elaborar será para una empresa
retail en sede de Lima por ser la capital del país que dispone de los recursos
suficientes para tal fin. Que posiblemente no se encuentren en las provincias y
regiones.

 Delimitación temporal

Se contó con tres (03) periodos.


 El primer periodo fue de 1 año para la recolección de información que
corresponde al año 2019.
 El segundo periodo consta de 12 meses para la investigación e
implementación del sistema propuesto, en el año 2020.
 El tercer periodo fue de 1 año para la recolección y validación del
sistema implementado y los estudios post-test que fueron coordinados en
el área de pagos en el año 2020.

 Delimitación Teórica

Willcocks, Leslie, Lacity, Mary and Craig, Andrew (2017) Robotic process
automation: strategic transformation lever for global business services? Journal
of Information Technology Teaching Cases. pp. 1-12. ISSN 2043-886

25
1.5. Objetivos generales y específicos

1.5.1 Objetivo general

Aplicar la Robotic Process Automation – RPA, para mejorar la


productividad del área de pagos en una empresa del sector retail.

1.5.2 Objetivos específicos

a) Rediseñar el proceso de registro, para reducir las horas de trabajo.

b) Implementar controles avanzados con RPA, para reducir los errores por
el registro de factura.

c) Automatizar las tareas con RPA, para reducir el tiempo en la


transacción por factura.

26
CAPÍTULO II: MARCO TEÓRICO

2.1. Marco histórico

Evolución del tiempo sobre la aplicación de RPA

La evolución de la automatización de tareas abarca toda la historia de la


humanidad, desde los mayas, que automatizaron el transporte de agua a través de
acueductos, pasando por el ejemplo que propuso Adam Smith sobre el impacto de
la automatización en los fabricantes de alfileres, hasta la automatización de la línea
de ensamblaje mecánico de Henry Ford.

La reinvención digital que se está produciendo en la mayoría de las organizaciones,


junto con los recientes avances tecnológicos, marca el comienzo de una nueva era
de la automatización: la automatización inteligente.

A lo largo de la historia, la automatización ha representado una oportunidad para


generar más valor a partir del equilibrio del paradigma clásico de personas,
procesos y tecnología. En el caso de la automatización del transporte de agua, por
ejemplo, la tecnología (en este caso, los acueductos) facilitó el proceso (transporte

27
de agua) con ayuda de las personas (que construyeron los acueductos). Este mismo
equilibrio marcó el comienzo de la era industrial.

Pero este paradigma ha cambiado en la era de la información. Las tareas


relacionadas con datos requieren que las personas (mediante el uso de un teclado)
habiliten procesos (transacciones o interacciones) con ayuda de la tecnología
(teléfonos, hojas de cálculo, etc.).

La automatización de tareas empresariales basadas en datos comenzó en la década


de 1960 con la introducción de sistemas de planificación de recursos empresariales
y, en la actualidad, ha evolucionado para abarcar la automatización de procesos
robóticos (origen del término “bots”).

Pero la automatización de tareas, más allá de la simple captura del contenido de


pantalla (“screen scraping”) y la clasificación de datos, se ha visto obstaculizada
por funciones de procesamiento de datos limitadas a la ingesta de formatos
estructurados y estandarizados y de procesos operativos empresariales que no eran
digitales o contenían datos que se consideraban poco fiables. Hasta hace poco, la
automatización de tareas en estas condiciones seguía exigiendo la intervención
humana para completar con éxito un proceso basado en información.

La automatización inteligente es una nueva tecnología que permite que los procesos
se ejecuten de tal manera que optimicen el nivel necesario de intervención humana.
Este cambio, que consiste en trasladar la carga de los procesos de las personas a la
tecnología, tiene el potencial de transformar la manera de trabajar en una empresa.
A medida que cada vez más tareas, y cada vez más complejas, se llevan a cabo
mediante la automatización de procesos, las personas pueden centrarse en tareas
más importantes.

La llegada de los sistemas de archivos de alta densidad, junto con los recientes
avances en el análisis algorítmico y las herramientas de IA, crea oportunidades
completamente nuevas para la automatización de tareas basadas en datos.

28
Las plataformas de datos modernizadas son capaces de procesar volúmenes
masivos de datos en múltiples formatos de manera rápida y precisa en todos los
sistemas, interpretar anomalías, aprender patrones y recopilar grandes cantidades de
información que permanecía oculta en procesos empresariales digitalizados
recientemente.

Con la introducción de herramientas de IA para procesar y analizar los datos, el


rango de capacidades de automatización se ha ampliado rápidamente, desde las
transferencias básicas de datos de los años sesenta a los sistemas avanzados
dominantes, algunos de los cuales son capaces de realizar acciones basadas en
juicios e interacciones similares a las humanas.

La ubicuidad de los datos para gestionar los procesos de negocio permite que
analizar el uso, los comportamientos y los resultados de la automatización
inteligente sea más sencillo. Tras entrevistar a 3069 altos directivos como parte del
estudio C-Suite del segundo trimestre de 2017 realizado por el IBM Institute for
Business Value, el 91 % de los encuestados afirmaron que ya existe en sus
empresas cierto nivel de automatización inteligente, como las capturas de pantalla
transaccionales, las transacciones complejas y las interacciones basadas en IA.

Por tanto, casi cualquier empresa puede clasificarse en uno de los tres tipos de
usuarios de la automatización de la información: básico, avanzado o inteligente.

Utilizaremos estas categorías a lo largo del informe para describir el tipo de


automatización de datos que se está analizando. Para mayor claridad, omitiremos al
9 % de las organizaciones que no utilizan ningún tipo de automatización y no nos
referiremos a ellas en este informe (véase la Figura 07).

Las tecnologías que sustentan la evolución de la automatización de datos, como los


centros de datos, los sistemas de planificación de recursos empresariales (ERP) y
las operaciones empresariales complejas, están disponibles fácilmente. Los chatbots
(“búsqueda y respuesta”), el procesamiento de lenguaje natural y el aprendizaje
automático se están convirtiendo rápidamente en herramientas comunes para

29
abordar necesidades específicas dentro de los procesos de negocio (véase la Figura
08).

Figura 07: Todas las organizaciones encuestadas utilizan al menos un tipo de


automatización. Estudio C-Suite del segundo trimestre de 2017 realizado por el
IBM Institute of Business Value.

Figura 08: Las tecnologías asociadas a la IA impulsan la automatización


inteligente.

Los pioneros en la automatización inteligente basada en tecnología están adoptando


medidas estratégicas para equilibrar la eficiencia operativa obtenida con los
cambios evolutivos que están en curso para su personal. En este informe,
examinamos los pasos dados por estos primeros usuarios y ofreceremos orientación

30
para aquellos que desean explorar nuevas oportunidades con la automatización
inteligente.

Automatización de la eficiencia

La “optimización de los procesos de negocio” es una de las tres principales formas


en que la mayoría de los directivos creen que la IA puede ayudarles a competir en
los próximos dos o tres años. Las otras dos áreas principales de impacto de la IA,
“personalizar la experiencia del cliente” y “mejorar las funciones de previsión y
toma de decisiones”, solo se pueden alcanzar, en muchos de los casos, mediante el
uso eficaz de la automatización inteligente.

Los primeros en adoptar estas nuevas tecnologías y funciones de automatización


impulsadas por la IA, los usuarios avanzados e inteligentes, dicen haber observado
un impacto significativo gracias al uso de las tecnologías en numerosas funciones
empresariales. Incluso entre los usuarios básicos que actualmente solo utilizan la
automatización transaccional no modernizada, se prevé que la incorporación de
estas nuevas tecnologías a los procesos empresariales tendrá un impacto
significativo en los próximos dos o tres años (véase la Figura 09).

31
Figura 09: Los usuarios que actualmente utilizan funciones de automatización
impulsadas por la IA hablan de un impacto significativo y esperan que se produzca.
Estudio C-Suite del segundo trimestre de 2017 realizado por el IBM Institute of
Business Value.

En un primer momento podría parecer contradictorio que los usuarios más


avanzados señalen haber experimentado un impacto más considerable debido a la
IA que los usuarios inteligentes que implementan soluciones de IA
multifuncionales. Pedimos a los directivos que valoraran el impacto a partir del
nivel más alto de automatización en sus organizaciones (en función de la
complejidad).

Nuestra interpretación es que los modernos sistemas de IA multifuncionales que


utilizan los usuarios inteligentes tienen un menor recorrido que las soluciones
puntuales y de probada eficacia utilizadas por los usuarios avanzados. Como
vemos, las expectativas se equilibran con el tiempo.

El valor de la automatización reside principalmente en la eficiencia que crea. Una


organización internacional de bienes de consumo incluida en la lista Fortune 75
utilizó la automatización avanzada para resolver problemas del flujo de trabajo
(conocidos como “tiques de soporte”) hasta un 30 % más rápido y mejorar la
productividad de los empleados en más de un 50 %.7

32
Por otro lado, un banco multinacional redujo su número de tiques de soporte hasta
en un 40 %, al tiempo que aumentó la satisfacción de sus empleados en más de un
95 %. En la actualidad, este banco tiene previsto reutilizar las mismas tecnologías
para respaldar más de 25 aplicaciones corporativas en múltiples procesos
empresariales.

La simple automatización de los procesos permite eliminar errores, reducir los


sesgos y ejecutar transacciones en una fracción del tiempo que las personas tardan
en realizar esas tareas. Estas tecnologías básicas han demostrado que es posible
obtener un ahorro de costes de hasta un 75 % en tareas repetitivas en comparación
con el rendimiento humano; y los resultados declarados generalmente se sitúan
entre un 25 y un 50 %.

La incorporación de la IA a los procesos básicos de automatización no solo cambia


la velocidad a la que se puede realizar el trabajo, sino también la magnitud de
trabajo que se puede gestionar. Los procesos controlados mediante IA pueden
escanear automáticamente millones de documentos en una fracción del tiempo que
tardaría una persona (si tuviera varios cientos de vidas), lo que permite habilitar
procesos tan variados como la revisión de contratos legales, la adopción de
decisiones sobre tratamientos médicos, el análisis de reclamaciones y la gestión de
fraudes.

Los sistemas de automatización inteligentes analizan los datos hasta 25 veces más
rápido que el cerebro humano, funcionan ininterrumpidamente, y se comunican con
los empleados y los clientes mediante el uso de un lenguaje natural, todo ello con
una precisión increíble.

Una compañía de seguros de Sudamérica transformó recientemente sus procesos


manuales de conciliación de las reclamaciones entrantes de acuerdo con las
directrices de cobertura de pólizas de cada cliente mediante la creación de un
sistema de procesamiento inteligente que utiliza el procesamiento en lenguaje
natural.

33
El sistema, capaz de sintetizar miles de páginas de documentos y hojas de cálculo,
redujo en más del 90 % el tiempo necesario para procesar reclamaciones que
requerían la intervención de un agente, y redujo el fraude anual en más de un millón
de dólares estadounidenses. Consulte la Figura 10 para ver un ejemplo de cómo
cambia un proceso de seguros con tareas controladas mediante la automatización.

Los procesos operativos gestionados mediante IA, ya sean específicos para cada
caso o integrados en sistemas inteligentes, aportan “inteligencia” a las actividades
automatizadas, amplificadas por la transparencia y la naturaleza inagotable de la
automatización. Por ejemplo, un proveedor europeo de electricidad ha obtenido un
ahorro estimado de 6 millones de euros después de que tan solo los primeros ocho
de 50 bots planificados, en su mayoría chatbots de servicio al cliente, entrarán en
funcionamiento y anticiparán un ahorro de costes de dos dígitos en el curso de su
implementación.

La automatización también introduce escalabilidad en las operaciones de la


empresa de forma flexible y variable en función de la demanda estacional o de
incrementos por promociones.

34
Figura 10: Muchas de las tareas de recopilación de información implicadas en la
gestión de un siniestro se pueden automatizar, lo que permite que el personal se
centre en tareas de investigación, decisión y resolución. Estudio realizado por el
IBM Institute for Business Value.

El uso de la automatización basada en la IA está en sus inicios, pero como la


mayoría de las tecnologías, continuará evolucionando. En la actualidad, las
organizaciones utilizan principalmente la traducción en lenguaje natural, el
reconocimiento de datos no estructurados, agentes interactivos de “búsqueda y
respuesta” y acciones algorítmicas complejas (graduales) para automatizar los
procesos que reducen o eliminan la necesidad de intervención humana.

Las funcionalidades inteligentes de próxima generación incluyen sistemas capaces


de recordar (por ejemplo, mediante la automatización de futuras configuraciones de
robots) y de razonar (por medio de tareas como el procesamiento predictivo y
probabilístico), dos funcionalidades que, combinadas, crean un sistema que puede
aprender e interactuar.

35
La automatización específica del sector queda fuera de este marco. Estos usos
predominantes de la automatización basada en soluciones puntuales de IA tienden a
realizar tareas algorítmicas a velocidades que superan el nivel de capacidad humana
razonable que se puede alcanzar. (Véase el recuadro de la página 13: Apuesta por la
eficiencia y la precisión).

El nivel de automatización necesario para un proceso determinado varía en función


de la naturaleza de las tareas del proceso. La automatización básica es adecuada
para tareas repetitivas basadas en reglas con actividades bien estructuradas, reglas
claramente definidas tomadas de fuentes de datos y sistemas bien estructurados que
generan resultados visibles y cuantificables.

Idealmente, un buen candidato sería un proceso de alto volumen, con un tiempo de


ciclo elevado y alta visibilidad, como un cuello de botella o un problema actual que
se inicia con un desencadenante digital y se basa en datos digitales (véase la Figura
11).

Figura 11: El nivel de automatización necesario para cada proceso varía en función
de la naturaleza de las tareas del proceso.

36
Un proveedor de servicios financieros alemán obtuvo un aumento de la eficiencia
en el tiempo de entre el 60 y el 80 %, además de una reducción tangible de los
costes a corto plazo de hasta el 20 % tras automatizar solo el primero de los diez
procesos planificados.

Después de obtener un retorno de la inversión en menos de 12 meses, la compañía


tiene previsto automatizar más procesos de back-office, como la creación de
formularios, los cambios de nombre, el prellenado de datos, la actualización de
estados y el inicio de investigaciones.

A medida que las tareas se vuelven más complejas, se necesita automatización


avanzada. Las soluciones de IA se utilizan para automatizar tareas que se basan en
una combinación de datos estructurados y no estructurados, a menudo con
actividades que implican múltiples sistemas o cantidades ingentes de datos.

Las actividades de estos procesos a menudo se basan en grandes bases de datos de


conocimiento, pero cada acción que se lleva a cabo se basa en datos específicos y
resultados predefinidos. Los procesos óptimos para la automatización avanzada son
también aquellos que fluctúan con la demanda, ya que la automatización se puede
adaptar para dar cabida a lo que de otro modo provocaría la variabilidad de la
plantilla.

Los antecedentes de RPA, se encuentran ligados al concepto de Business Process


Management (BPM) como una práctica, y se posiciona como un nuevo enfoque
para realizar la automatización de procesos.
 1960: Se inició con la aplicación de los ecosistemas de TI para las empresas
poder aplicar en la automatización de sus procesos. La aplicación que se
utilizaban eran las siguientes:
 1990: Se inició con la aplicación de los ecosistemas de TI para las empresas
poder aplicar en la automatización de sus procesos. La aplicación que se
utilizaban eran las siguientes:
- Automatización de procesos en sistemas integrados.
- Interfaces.
- ERP (IBM-BPM ORACLE-BPM).

37
- Almacenes automatizados.
 2000: Luego empezó madurar los modelos de procesos automáticos para los
procesos tenerlos controlados y tener un panel de control para monitorearlos
respectivamente. De los cuales los más usados son los siguientes:
- Evolución de los ERP y su conectividad.
- Ambiente automatizado de control (CA-Process).
- Ambientes sistemáticos de mejora de procesos.
 2011-2018: La nueva era digital trae consigo un futuro en el cual las máquinas
empiezan a aprender de los seres humanos; y a medida que estas se vuelvan
mejor en su labor, su demanda y permeabilidad en el día a día de las empresas
será más prevalente.

Por estas épocas se empezó con la automatización de procesos con RPA para las
necesidades siguientes:
- Procesos lineales automáticos.
- Ecosistemas digitales.
- Internet de las cosas (IOT).
- Implementación de “Bots”
- Nuevos materiales y electrónica digital avanzada.
- Gestión automatizada de procesos.
- Inteligencia artificial.

Evolución en el tiempo del sector Retail

La historia del retail se remonta a los comerciantes medievales y los mercaderes.


Durante miles de años, los minoristas han operado de forma local, con mercancía
que era a menudo limitada a una sola categoría de producto. Todo esto cambió en el
mundo postindustrial.

A medida que los ingresos aumentaron y los medianos mercados emergieron,


también creció el apetito del consumidor hacia los productos de consumo. Con esto,
hemos visto las que las raíces del retail moderno fueron creciendo y empezaron a
evolucionar los canales de distribución. Desde entonces, el retail moderno se ha
disparado hasta convertirse una de las industrias más grandes en el mundo.

38
 1900 – 1945: El retail moderno emerge
En el cambio de siglo, el comercio minorista estaba dominado
principalmente por los comerciantes que hacían pedidos por correo y
ofrecían un amplio surtido de casi todo lo disponible en el mercado.

Los líderes del mercado incluían a Sears, Roebuck and Co., Montgomery
Ward y JC Penney; todos de los cuales se publicaron inmensos “libros” que
se convirtieron en un elemento básico en todos los hogares de América.

Las grandes ciudades fueron centros para las compras al por menor, como
un enorme emporio lleno de hermosas prendas de vestir, accesorios y
productos del hogar, que se convirtió en destino de compras para los
estadounidenses de una posición acomodada. Nombres como Macy,
Wanamaker, Lázaro y de Dayton estuvieron entre las más famosas de esa
época.

 1945 – 1975: “Baby boomers”, impulso del crecimiento posguerra


Después que terminó la Segunda Guerra Mundial, el mundo entró en un
período de reconstrucción y crecimiento que afectó a las necesidades de los
consumidores.

Los nuevos nacimientos, dieron lugar a la creación de un “boom” que aún


hace eco en la actualidad. Los llamados “baby boomers”, los niños nacidos
entre 1946 y 1964, fueron 79 millones de personas. Este grupo se convirtió
en la tendencia de consumo para los minoristas por una generación.

Como la demanda del consumidor se aceleró, los minoristas respondieron.


Siguieron a los consumidores a nuevos barrios y se ubicaron
convenientemente en el lugar donde ellos vivían. Estos centros comerciales
se convirtieron en el nuevo destino para el comercio minorista.

Las tiendas especializadas eran pequeñas, muy concretas y llevaban un


surtido limitado de productos. El aumento de estos centros comerciales, hizo

39
disparar a muchos de estos comerciantes, como Gap, Inc. (The Gap) y
Limited Stores, LLC (The Limited), a la prominencia nacional.

Tal vez el acontecimiento más grande en el mundo retail del siglo 20, se
produjo en 1962. Una nueva forma de venta al por menor surgió, las
denominadas “tiendas de descuento”.

En 1962, Wal-Mart Stores, Inc., Kmart, Target y Woolco, abrieron su


primera tienda, dirigidas a satisfacer las necesidades de los consumidores a
precios inferiores a los sugeridos por los fabricantes. Construyeron grandes
superficies, con grandes playas de estacionamiento.

Su estructura de bajo costo les ha permitido ser líderes en los precios y


rápidamente convertir esta ventaja, en crecimiento. Luego se convertirían en
líderes del mercado minorista.

 1975 – 2000: Fraccionamiento de la masa del mercado


Las diferencias entre hombres y mujeres se pusieron de moda,
contribuyendo al alejamiento de la “igualdad”. Este cambio comenzó a
causar grietas en el mercado de masas.

Los minoristas, una vez más respondieron al mercado que constantemente


evolucionaba. Las tiendas especializadas se adaptaron bien a la necesidad de
los consumidores. Incluso las tiendas de descuento se especializaron en
nuevas grandes superficies comerciales llenos de un amplio surtido de una
sola categoría.

Wal-Mart surgió como un claro líder del mercado en este período y obligó a
muchas tiendas de descuento tradicionales a salir del negocio. Entre las 100
tiendas de descuento que operaban en 1976, sólo 24 permanecieron en el
negocio en 1992.

Hacia el final de este periodo, se empezó a ver las primeras etapas de lo que
sería la próxima revolución en el comercio minorista. Habilitado por el

40
lanzamiento de la “World Wide Web” en 1991, el retail onlinea, o “e-
commerce”, comenzó a aparecer en el mercado.

La explosión de los ordenadores personales y la amplia disponibilidad de


Internet, marcó un cambio decisivo en la innovación no sólo en el comercio
minorista, sino también en todos los aspectos de la vida de los
consumidores.

 2000 – Al presente: Los consumidores toman cada vez más el control


El siglo 21 comenzó de manera desfavorable para los minoristas. El frenesí
del “Y2K” o “año 2000” y la prematura promesa del comercio electrónico,
crearon el boom de los puntos com.

El cambio de la bolsa de valores NASDAQ fue de 5.000 a 1.500 en dos


años, lo que lleva a muchos a creer que el comercio minorista online estaba
sobre-estimado. En definitiva, estaban equivocados.

Con una gran ventaja en términos de selección, comodidad, precios y gran


capacidad de proporcionar información experta y comparaciones de
productos en tiempo real, el Internet se convirtió rápidamente en una
alternativa comercial agradable para los retailers.

Amazon.com, Inc., lanzado en 1995, se ha convertido rápidamente en un


mercado amplio para muchas categorías de productos, ofreciendo
inigualable selección, ofertas personalizadas, disponibilidad alta de
productos, entrega a bajo costo y pago sencillo.

Amazon probablemente llegará a US$ 50 mil millones en ventas este año o


el próximo y, dada su tasa de crecimiento, podría lograr más de US $ 100
millones en el 2015.

La empresa ha alcanzado estos objetivos en la mitad del tiempo que le tomó


a Wal-Mart para alcanzarlos. En todo este tiempo, Amazon -y otros
retailers- están obligando a los minoristas tradicionales a repensar sus

41
propuestas de valor y aplicar el retail multicanal como su única manera de
sobrevivir. Los retailers tradicionales no tienen mucho tiempo para hacer las
cosas bien.

Evolución en el tiempo de la Productividad

El fenómeno del trabajo como tal existe desde que el hombre es hombre. Pero para
estudiar la historia de la productividad como disciplina objeto de análisis cabe
remontarse al siglo XVIII. Durante los inicios de la revolución industrial, desarrolla
su actividad quien puede considerarse padre de la economía moderna a Adam
Smith.

 1776 – 1890: Especialización


Adam Smith ya apuntaba la idea de que para aumentar la productividad era
necesaria la especialización. Más adelante, entre finales de siglo XIX y
principios de siglo XX, se da un hecho relevante. Por primera vez, surgen
escuelas de pensamiento que abordan de un modo científico el análisis del
fenómeno del trabajo. Es entonces cuando la historia de la productividad
toma impulso.

 1891- 1921: Administración Científica Trabajo


En este período, destacan nombres de la talla de Frederick Taylor, Henry
Fayol, George E. Mayo o Henry Gantt. Todos ellos llevaron a cabo los
primeros análisis serios sobre lo que se dio en llamar organización o
administración científica del trabajo. A través del control de tiempos,
cronometrando las operaciones, y la división de tareas se conseguía reducir
tiempos ociosos de los trabajadores y aumentar la productividad en las
factorías.

Más adelante, el matrimonio formado por Frank y Lilian Gilbreth abordó la


manera de reducir los movimientos innecesarios, diseñando mejor los flujos
de trabajo.

 1922 – 1953: Trabajo en cadena

42
Henry Ford se imbuye de este espíritu de mejora en los procesos en cadena.
Así, desarrolla una línea continua de ensamblaje para la fabricación de sus
coches. Su decidida apuesta por la mecanización le permitió reducir los
tiempos y los costes, bajar los precios y ganar competitividad para situarse
durante algunos años como líder del mercado automovilístico.

Años más tarde, otros competidores de Ford como General Motors


consiguieron introducir mejoras en los sistemas de gestión y producción
propios de lo que se había venido en llamar “fordismo”. Esto les permitió
tomar el relevo en la posición de liderazgo mundial en el sector automotriz
hasta la llegada del fenómeno Toyota.

 1954 – 1974: Management


Pero en paralelo, al tiempo que éstas siguen evolucionando, surge una nueva
línea de pensamiento. Los conocidos como “trabajadores del conocimiento”,
gestores de lo intangible, ya no encajaban bien en el concepto clásico de
productividad. Quien mejor supo entenderlo y divulgarlo fue Peter Drucker.

Durante la 2ª mitad del siglo XX, desde la publicación en 1954 “The


practice of management” hasta “Management Challenges for the 21st
Century” en 1999, fue dejando buenas muestras de ello.

 1975 – 1988: Toyota Production System


La industria de la automoción japonesa llegó tarde a esta carrera
automovilística, pero aprendió pronto y mucho. Logró afrontar la
competencia en el sector desarrollando un esquema innovador para abordar
el análisis del fenómeno del trabajo.

Taiichi Ohno, ingeniero industrial de Toyota consiguió definir un sistema


propio de mejoras de la calidad: Toyota Production System (TPS). Se
basaba en el Just-In-Time (JIT: Justo a tiempo: lo que se necesita, cuando se
necesita y en la cantidad necesaria) y en el Jidoka (detección y solución
inmediata de problemas en el proceso de producción para evitar defectos).

43
De este modo conseguía eliminar desperdicio y estandarizar los procesos
con la intención de flexibilizar su estructura para adaptarse a la demanda,
reduciendo stocks y costes. Uniendo este sistema a la filosofía kaizen
(mejora continua) se sentaron las bases de la cultura Lean manufacturing
como modelo de productividad óptimo.

 1989 – 1994: 7 hábitos altamente efectivos


Stephen Covey plantea reflexiones realmente interesantes acerca de cómo
afrontar nuestro tiempo en la vida, con intensidad e inteligencia. Nos dice
que hay que asumir responsabilidad por nuestros actos y no buscar excusas
fuera.

Esto se consigue subordinando los sentimientos a los valores, para que


nuestros comportamientos se basen en nuestras decisiones libres y
racionales, no en nuestros estados de ánimo.

Basados en “principios de la ética del carácter”, los hábitos atemporales y


universales que determina son:
1. Dependencia significa que Uds necesitan de “otros” para lograr lo
que quieren. Es la actitud del “tú”.
2. Independencia significa que estás libre de la influencia externa.
Piensas y actúas por ti mismo. Es la actitud del “yo”.
3. Interdependencia es la actitud del “nosotros”, del trabajo en equipo,
de las sinergias, es una elección que sólo la gente independiente
puede tomar.

Hasta que no somos independientes no podemos ser interdependientes. No


podemos aprender a trabajar con otros si no tenemos “automandato”
interno. Las victorias privadas deben preceder a las victorias públicas. No
podemos dirigir a otros si no nos dirigimos a nosotros mismos.

Sólo cuando dominamos los 3 primeros hábitos pasamos de la dependencia


a la independencia. Y sólo cuando dominamos los 3 siguientes conseguimos
ser interdependientes. El hábito 7 es el de la renovación continua.

44
 1995 – 2000: Scrum (Metodología Ágil)
El año 1995 se puede considerar como el año oficial de nacimiento de
Scrum. En este año Ken Schwaber describe los fundamentos del método
antes de publicarlos, junto con Mike Beedle en 2001, en su libro "Agile
Software Development With Scrum". Es necesario esperar a 2011 para que
Jeff Sutherland y Ken Schwaber publiquen la "Scrum Guide".

Pasados algunos años, el método Scrum no deja de aplicarse en las


empresas, hasta tal punto que hoy en día es el método ágil más utilizado.

En la era digital aparecieron nuevos sectores de actividad, como el


desarrollo de software, que requerían de nuevos modos de trabajar. La
progresiva implantación de sistemas como Kanban, Scrum, XP, Lean
startup en el ámbito de la programación informática desembocó en el
llamado Manifiesto Ágil (2001).

En él se marcaron distancias con las formas de trabajar tradicionales que


definía la metodología de flujos de trabajo secuenciales, en cascada
(“Waterfall”), propia de contextos simples.

En el citado Manifiesto se pusieron en común los puntos clave que definían


los nuevos usos para alcanzar la máxima productividad en contextos
complejos.

Crear equipos de trabajo autónomos y comprometidos, capaces de


adaptarse con flexibilidad e inmediatez a las exigencias del cliente en un
entorno cambiante es su principal seña de identidad. En su formulación
actual no se circunscribe a un sector ni a un tamaño de empresa concreto.

 2001 – Presente: Getting Things Done


Entre todos los métodos de productividad personal que existen, éste es el
más popular.

45
Parte de la premisa de que el tiempo no se gestiona y de que sólo se pueden
gestionar las actividades. De hecho, considera que la ausencia de
determinación para fijar las “acciones siguientes” es la principal vía de agua
de la productividad.

Considera que la capacidad de pensar, destreza clave del ser humano, está
seriamente amenazada por:
1. la dificultad creciente de mantener la concentración en un mundo
lleno de distracciones, y el mal hábito de utilizar la mente como
almacén de memoria para albergar un enorme y creciente caudal de
información.
2. El mal hábito de utilizar la mente como almacén de memoria para
albergar un enorme y creciente caudal de información.

46
2.2. Investigaciones relacionadas con el tema

 Título: Sistema que reemplaza funciones de un operador humano durante la


validación de documentos digitales en Core Andina Group
Tesis para optar el grado de Título profesional de Ingeniería de Sistemas.
Autor: Jeferson Gustavo Calva Carhuamaca
Centro de Estudio: Universidad César Vallejo
Ciudad / País: Perú 2017
http://repositorio.ucv.edu.pe/bitstream/handle/UCV/26911/Calva_CJ.pdf?
sequence=1&isAllowed=y
Fecha de captura: 06 de octubre 2019

Core Andina Group es un proveedor de servicios electrónicos


autorizado por la Sunat que recibe miles de comprobantes
electrónicos de distintas empresas peruanas todos los días; debe
asegurar la recepción y el envío de los comprobantes a los
servidores la Sunat y mantener los documentos para ser
consultados por los clientes de las empresas emisoras por lo que
debe asegurar que los comprobantes que se han enviado sean
aceptados sin problema alguno.

Al realizar este proceso ocurren algunos problemas debido al gran


volumen de comprobantes que se emiten todos los días, si un
comprobante no es enviado dentro del plazo establecido por los
especialistas la Sunat, que es siete días después de la fecha de
emisión del comprobante, este es rechazado automáticamente.
(Carhuamaca, 2017)

 Título: Plan de Negocios para determinar la viabilidad del desarrollo de un


asistente virtual de ventas (Chatbot): Caso Gamarra
Tesis para optar el grado de Título Maestro de Marketing.
Autor: María Rosario Pérez Castillo
Centro de Estudio: Universidad Esan

47
Ciudad / País: Perú 2018
https://repositorio.esan.edu.pe/bitstream/handle/ESAN/1295/2018_MAM_16-
1_02_T.pdf?sequence=1&isAllowed=y
Fecha de captura: 26 de mayo 2019

Por otro lado, el boom económico del país ha contribuido a una


población con mayor poder adquisitivo y, por ende, se favorezca el
consumo interno del país, así como el desarrollo del empresariado
local. Ejemplos de esto son:
i) el incremento en el ingreso promedio mensual de la población
a nivel nacional, pasando, según reportes de INEI (2017a), de
S/ 1, 155 a S/ 1, 370 entre el 2012 y el 2016;
ii) la expansión de la clase media con un NSE C (41%) (APEIM,
2017) abarcando cerca a la mitad la población, y
iii) la reducción constante de la pobreza monetaria en el país,
pasando de 33.9% en el 2009 a un estimado de 20.07% en el
2016 (INEI, 2017a).

Además, cabe resaltar que, dentro del consumo, la industria


tecnológica y su alcance en el hogar se han visto favorecidos,
logrando una transformación en los hábitos de consumo con
respecto a las plataformas digitales.

Asimismo, según un estudio realizado por IAB (2016): el 31% de


las compras mensuales se realizan por dispositivos móviles, a
comparación de las tiendas físicas, que representan un 40%.

Así pues, queda evidenciada la importancia y crecimiento del canal


on line con respecto a la interacción social y comercial con el
consumidor; lo cual invita a las empresas a adaptarse y
desarrollarse a otras realidades y oportunidades de
comercialización, como lo es el canal digital.

48
En este contexto de posible desarrollo comercial, se encontró,
según la investigación cuantitativa realizada para esta tesis que un
97.5% empresarios textiles de Gamarra usan plataformas digitales
(Facebook, Página Web, etc.) para la gestión de su negocio. No
obstante, estas plataformas no son administradas por un
profesional, ni capitalizan el canal para el aumento de sus ventas.

Esto detrás de una tendencia de desinformación y, como se verá en


el capítulo de marco contextual, barreras de adopción con respecto
a nuevas tecnologías en el manejo de sus compañías.

Como se apreciará en el análisis de Rivalidad de Porter, Gamarra es


un mercado desatendido en términos de desarrollo tecnológico.

Las empresas de desarrollo de software, como los Chatbots, se


enfocan principalmente en grandes corporaciones.

Considerando lo mencionado anteriormente, Gamarra se presenta


como una oportunidad de mercado interesante, en un segmento
(textil) que crece y un canal (on line) que debe ser desarrollado.

Por ende, esta tesis pretende, atacar la oportunidad de mercado de


desarrollo comercial en el canal digital para los empresarios textiles
de Gamarra a través de la prestación de un servicio de asistencia
virtual (enfocado en la red social Facebook y su plataforma de
comunicación Facebook Messenger, así como las páginas Web de
nuestros clientes). (Castillo, 2018)

 Título: Automatización en la recolección, tratamiento y envío de información


estadística médico-asistencial a la Superintendencia Nacional de Salud
(SUSALUD) basado en procesos de ETL y RPA para la clínica Adventista Ana
Stahl
Tesis para optar el grado de Título profesional de Ingeniería de Sistemas.
Autor: Rosi Mical Lizana Lozano

49
Centro de Estudio: Universidad Peruana Union
Ciudad / País: Perú 2018
https://repositorio.upeu.edu.pe/bitstream/handle/UPEU/103/
Rosi_Tesis_Licenciatura_2018.pdf?sequence=1&isAllowed=y
Fecha de captura: 19 de Mayo 2019

La clínica Adventista Ana Stahl está ubicada en el departamento de


Loreto provincia de Maynas, distrito de Iquitos, instituida desde
1927 como una institución prestadora de servicios de salud
(IPRESS) líder en la región; forma parte de la red médica de 150
hospitales y sanatorios y 330 clínicas adventistas en el mundo
Adventistas.org, (2013). En el Perú, forma parte de la red
adventista de salud-Perú conformado por las clínicas Good Hope
de Miraflores y clínica americana de Juliaca.

Según la Superintendencia Nacional de Salud - SUSALUD indica


que como IPRESS categorizada en el nivel II-2, está sujeta a
supervisiones constantes por los organismos reguladores de salud
del estado peruano, tales como SUSALUD, MINSA, DIGEMID,
etc.; teniendo obligaciones de envío de información estadística y
económica a dichos organismos. SUSALUD, (2014).

Es así, que a partir de la publicación de la ley N°29334, ley Marco


de Aseguramiento Universal en Salud, aprobado por decreto
supremo N°020-2014-SA el cual establece que es función general
de SUSALUD, regular la recolección, transferencia, difusión e
intercambio de la información generada u obtenida por las IAFAS,
IPRESS y Unidades de Gestión de IPRESS, por normativa, la
clínica debe presentar información estadística mensual de los
servicios prestados mediante el Sistema Electrónico de
Transferencia de Información - SETI.

Actualmente el envío de la información al SETI se realiza una parte


a través de los sistemas de información de la clínica, y otra parte de

50
forma manual, sobre todo en la recolección de la información, lo
cual trae consigo problemas constantes y repetitivos que afectan
negativamente a la clínica en el uso inapropiado de recursos, los
cuales se detalla a continuación:

Los procesos de recolección y verificación de la información


estadísticos médico-asistencial de la clínica no están bien definidos,
teniendo como resultado tareas duplicadas, roles no definidos,
procesos engorrosos que impiden un buen flujo de trabajo, tal como
se recomienda Apablaza, Adamo, & Kempowski,(2018).

Al tener un híbrido en las herramientas de software actuales de la


clínica (parte heredado de la clínica Good Hope, parte de desarrollo
propio, y parte manual) no se cumple con los estándares
recomendados para la obtención oportuna de información, esto trae
como resultado el excesivo uso de recursos para obtenerla, siendo
los principales el tiempo, personal asignado, equipos de cómputo,
dinero, etc.

No existen políticas de control de calidad de la información al


presentar en el SETI, según la norma emitida por SUSALUD
generando así observaciones y rechazos de la información
estadística enviados a SUSALUD.

Falta de capacitación del personal en el ingreso de la información,


esto genera una información estadística con ruido o basura de
datos, trayendo como consecuencia la falta de credibilidad ante los
organismos supervisores que según Palma Pinedo & Reyes Vega,
(2018), la calidad de la información resulta vital para el desarrollo
de la inteligencia sanitaria, ya que si los datos no son veraces ni
completos la información que se produce no permitirá tomar
decisiones efectivas ni eficientes, trayendo un alto impacto en la
imagen institucional de la clínica.

51
Debido a la problemática mencionada, la presente investigación se
justifica principalmente en el ámbito tecnológico, económico,
social y personal:

A nivel tecnológico, se usa la ingeniería de procesos, para


optimizar la recolección, tratamiento y envío de información a
SUSALUD, también el uso de procesos de ETL para asegurar una
información limpia y organizada, el uso de la ingeniería de
software para el desarrollo de una solución que automatice los
procesos ya definidos, a través de un RPA. (Lozano, 2018)

 Título: SisBot v1.0 para mejorar la gestión de contratación de personal en la


empresa MDP Consulting S.A.C., Lima 2018
Tesis para optar el grado de Título profesional de Ingeniería de Sistemas.
Autor: Karen Vanesa Del Rosario Arizabal
Centro de Estudio: Universidad Norbert Wiener
Ciudad / País: Perú 2018
http://repositorio.uwiener.edu.pe/bitstream/handle/123456789/2502/TESIS
%20Del%20Rosario%20Karen.pdf?sequence=1&isAllowed=y
Fecha de captura: 28 de Abril 2019

Para la empresa MDP Consulting SAC, actualmente en el proceso


de contratación realizan a diario nuevos contratos para los nuevos
colaboradores, atención de solicitudes, resguardo de información,
siendo estos documentación que conforman por datos que se
devalúan a cortos plazo, los cuales generan gastos administrativos,
puesto ello también son tareas repetitivas y dependen de un
colaborador quién pudiera tener la opción de obtener más tiempo
para otras funciones, permitiendo a la vez realizar actividades más
estratégicas en la organización el que conlleva mayor valor.

En este proceso es posible que surjan errores, así como la


extracción de información del colaborador, para la elaboración del
documento teniendo en cuenta que no existe un estándar y

52
especificaciones de las funciones para el cargo que se elabora cierto
contrato. Al finalizar este proceso, se lleva a un reporte el cual se
comunica mediante correo la conformidad del colaborador, la
actividad es constante teniendo en cuenta la frecuencia de nuevos
colaboradores, renovaciones de contrato y corrección de estos
mismos.

Por ello el encargado de la ejecución de este proceso, le demanda


tiempo y frustración por otras funciones necesarias para la
organización. Lo cual causa pérdidas de tiempo, retrasando la
continuidad del proceso para las respectivas activaciones.
(Arizabal, 2018)

 Título: Implementation of Robotic Process Automation to a Target Process – a


Case Study
Tesis para optar el grado de Título Maestro de Ingeniería Industrial.
Autor: Tuomas Kyheröinen
Centro de Estudio: Universidad Aalto
Ciudad / País: Finlandia 2018
https://aaltodoc.aalto.fi/bitstream/handle/123456789/31518/master_Kyher
%C3%B6inen_Tuomas_2018.pdf?sequence=1
Fecha de captura: 24 de Noviembre 2019

Desde el punto de vista de un investigador, la principal intriga con


RPA es cómo difiere de las soluciones de TI existentes,
especialmente desde la perspectiva de implementación. En pocas
palabras, todo se reduce al enfoque de diseño. RPA está diseñado
sobre otros sistemas y no funciona de forma independiente como,
p. Los sistemas de planificación de recursos empresariales (ERP)
podrían. Puede comparar RPA con una manta que cubre diferentes
sistemas, una herramienta que actúa como un pegamento y no hace
nada por sí misma.

53
El enfoque de diseño también significa que la mayoría de las
soluciones RPA, si no todas, deben adaptarse a cada sistema y
proceso. Esto le da mayor énfasis a la interacción entre los
desarrolladores y aquellos que trabajan con los procesos
subyacentes, que en casos de automatización similares que
involucran proyectos de TI tradicionales.

Con base en esta descripción, se puede argumentar que la


investigación sobre implementaciones de proyectos de TI
tradicionales no es totalmente aplicable a las implementaciones de
RPA como es, y, por lo tanto, existe una brecha en la investigación.

El objetivo principal de esta tesis es explorar esta brecha, descubrir


qué es importante en las implementaciones de RPA y cómo difieren
de las implementaciones tradicionales. El fenómeno focal en sí
mismo podría describirse como factores de éxito de la
implementación con RPA.

Sin embargo, no tiene sentido reinventar la rueda; Si bien RPA


difiere de los proyectos de TI tradicionales, es probable que haya
elementos transferibles de sus proyectos de implementación. Un
punto importante es reconocer las similitudes y diferencias con
otras implementaciones de proyectos de TI.

Después de encontrar los elementos más aplicables, ver qué tan


bien se aplican a la implementación de RPA es solo una cuestión de
prueba. Para este fin, se debe formar una plantilla para la línea de
tiempo de dicha implementación;

Esto se puede lograr examinando la investigación sobre los ciclos


de vida del proyecto y combinando los mejores elementos para
formar un modelo de ciclo de vida del proyecto para los proyectos
de implementación de RPA. Siguiendo esta lógica, las preguntas de
investigación que guían esta tesis son:

54
 RQ1 ¿Qué elementos se han reconocido como cruciales en las
implementaciones de proyectos de TI?
 RQ2 ¿Qué etapas conforman el ciclo de vida de un proyecto
que se ajusta a RPA?
 RQ3 ¿Cómo les irá a estos elementos cuando se combinen y
apliquen a las implementaciones de RPA?

Estas preguntas formarán la columna vertebral de este estudio y


serán revisadas en la sección de conclusiones. (Kyheröinen, 2018)

En el Anexo 5: Tema de Tesis en su idioma original, Implementation of


Robotic Process Automation to a Target Process – a Case Study), se muestra
este tema de tesis en su idioma original.

 Título: Robotic Process Automation A Lean Approach to RPA


Tesis para optar el grado de Título Maestría en Ciencias en Sistemas de
Información e Ingeniería Informática.
Autor: Carina Maria Gonçalves Martins
Centro de Estudio: Universidad de Lisboa
Ciudad / País: Portugal 2018
https://fenix.tecnico.ulisboa.pt/cursos/meic-a/dissertacao/1972678479054382
Fecha de captura: 28 de Noviembre 2019

La automatización no es un concepto nuevo en las organizaciones


como forma de mejorar sus procesos. Sin embargo, Robotic
Process Automation (RPA) es una forma emergente de
automatizar procesos con software, que la industria llama robots.
Estos realizan tareas repetitivas y de baja complejidad,
anteriormente realizadas por humanos frente a una computadora,
quizás el recurso más utilizado en la actualidad en una empresa.
Utilizando la metodología de investigación de la Ciencia del
Diseño para el desarrollo de esta tesis, se argumenta que RPA se
usa actualmente con pocas ventajas en comparación con lo que
podría estar usando técnicas de mejora de procesos antes de

55
aplicar la automatización en sí. Por lo tanto, esta tesis propone un
nuevo enfoque de RPA: el uso de técnicas Lean. Esta tesis analiza
dos líderes del mercado en RPA y sugiere un marco de actividad
para las organizaciones que están invirtiendo en RPA y que
quieren aprovechar al máximo las capacidades que ofrece la
tecnología en la actualidad. La mayor parte de la demostración de
la propuesta se realizó en un banco privado portugués, en tres
procesos. Finalmente se evaluó positivamente en campo o en
simulación, según los casos. Comparando los proyectos de RPA y
Lean RPA en la cantidad de recursos necesarios (tiempo y FTE)
para llevar a cabo los procesos de negocio, el último enfoque
mostró valores significativamente más bajos y, en consecuencia,
satisfactorios.

 Título: How Robotic Process Automation (RPA) Influences Firm Financial


Performance In The Netherlands
Tesis para optar el grado de Título Maestría en Ciencias en Administración de
Empresas.
Autor: Niek Gosen
Centro de Estudio: Universidad de Twente
Ciudad / País: Paises Bajos 2019
http://essay.utwente.nl/79600/1/Gosen_MA_BMS.pdf
Fecha de captura: 28 de Noviembre 2019

La investigación investigó si este marco estaba intercorrelacionado y encontró


de hecho suficiente evidencia, empleamos este marco de manera que tenga un
impacto moderador. Basado en la revisión de la literatura, tenemos pruebas
sólidas de que este marco será de moderación impacto entre la relación RPA y
el desempeño de la empresa. Moderador indica que la fuerza del efecto de la
RPA en el desempeño de la empresa se explica por el marco. Residencia en
esta información, la siguiente pregunta de investigación ha sido.

 Título: Robotic Process Automation:Dynamic Roadmap for Successful


Implementation

56
Tesis para optar el grado de Título Maestría en Ciencias en Gestión de
Ingeniería.
Autor: Guðrún Lilja Sigurðardóttir
Centro de Estudio: Universidad de Reykjavík
Ciudad / País: Islandia 2018
https://skemman.is/bitstream/1946/31385/1/MSc%20Thesis%20-
%20GudrunLiljaSigurdardottir.pdf
Fecha de captura: 29 de Noviembre 2019

El propósito de esta tesis de maestría busca descubrir la forma


eficiente de implementar Automatización robótica de procesos
(RPA) con éxito. Este estudio tiene como objetivo dar
información de las organizaciones sobre cómo implementar con
éxito la RPA y qué factores tenga cuidado para evitar fallas. La
principal literatura que respalda esta investigación es
investigación previa de RPA junto con una comparación con el
desarrollo de TI a través de Business Gestión de proceso.
Expertos en el campo que tienen experiencia en implementar
RPA fueron entrevistados para esta investigación. Los resultados
están presentes como dinámica Hoja de ruta para la
implementación de RPA con una descripción de los factores de
riesgo que son. Es necesario tener cuidado para evitar fallas.

 Título: Robotic Process Automation in Financial and Accounting Processes in


the Banking Sector
Tesis para optar el grado de Título Maestría en Administracion de Negocios.
Autor: Hannah Valgaeren
Centro de Estudio: Universidad de Ku Leuven
Ciudad / País: Belgica 2018
https://www.scriptieprijs.be/sites/default/files/thesis/2019-09/
MBA_Valgaeren_H_Final_Report1819.pdf
Fecha de captura: 29 de Noviembre 2019

Esta tesis trata sobre la evolución de la digitalización en la contabilidad y el


control de gestión. Más específicamente, tiene como objetivo proporcionar

57
nuevos conocimientos sobre el uso de la automatización robótica de procesos, o
en breve RPA, implementado en procesos financieros y contables dentro de la
banca belga sector y proporcionar una base clara y coherente para futuras
investigaciones dentro de este tema. Dado que varios años, ha aparecido un
cambio estructural en el mundo empresarial (Bygren, 2016). Este cambio puede
ser visto como la cuarta revolución industrial que obliga a múltiples empresas a
repensar y reorganizar sus estrategias (Capgemini, 2019). Más tareas manuales
se han hecho cargo de digital alternativas. Ha surgido la digitalización y aumenta
la necesidad de nuevos requisitos (Kumar, 2018).
Sin embargo, dado que el sector bancario es un sector de desarrollo bastante
lento que tiene menos experiencia en diferentes aspectos de la digitalización,
este sector será estudiado en esta tesis.

 Título: Robotic Process Automation in Financial and Accounting Processes in


the Banking Sector
Tesis para optar el grado de Título Maestría en Administracion de Negocios y
Sistemas de Información.
Autor: Hannah Valgaeren
Centro de Estudio: Universidad de Ku Leuven
Ciudad / País: Dinamarca 2019
https://research-api.cbs.dk/ws/portalfiles/portal/
59798549/644522_Robotic_Process_Automation_At_Johannes_Fog.pdf

El propósito de esta tesis es analizar los efectos del conocimiento tácito en la


actualización de los beneficios de la RPA. Para responda nuestra pregunta de
investigación, nuestro enfoque es el estudio de caso subjetivo e interpretativo.
Usamos entrevistas semiestructuradas para nuestros datos primarios y un
enfoque abductivo en nuestro intento de modificar los datos existentes.

58
2.3. Estructura teórica y científica que sustenta el estudio

La estructura teórica que soporta la presente investigación estará en función a los


siguientes términos que se han considerados como primordiales para el estudio:

Automatización robotizada de procesos

Señalaron que RPA está impulsando una transformación estratégica en distintos


sectores empresariales a nivel mundial. (Willcocks, Lacity y Craig, 2017, pág. 18)
La automatización de procesos robóticos como término tiene un tono futurista. El
concepto a menudo lleva a las personas a imaginar robots físicos rondando por el
espacio de la oficina realizando tareas al igual que los humanos. (Willcocks, Lacity
y Craig, 2015B, pág. 5).

Al igual que con toda la automatización, el concepto significa reemplazar procesos


previamente realizados por humanos, pero esta vez mediante la configuración de un
software robótico para realizar las tareas, interactuando entre diferentes sistemas
como hojas de cálculo, sistemas de Gestión de Relaciones con el Cliente (CRM) o
Planificación de Recursos Empresariales (Software ERP). (Willcocks, Lacity y
Craig, 2015, pág. 19).

En resumen, RPA proporciona las herramientas (software y plataforma) para


automatizar procesos lógicos basados en reglas que involucran datos bien definidos
y estructurados con un conjunto determinista de valores de salida. Además, las
tareas son a menudo repetitivas y menos deseables de hacer a mano. (Willcocks,
Lacity y Craig, 2016, pág. 41).

Sin todo el misticismo, esto es todo lo que hace RPA: interactúa con los sistemas
como un humano. Sin embargo, el robot debe, si se le da un proceso adecuado y
una lógica de trabajo bien definida, superar a los humanos en términos de calidad,
tiempo y costo. (Willcocks, Lacity y Craig, 2015B)

59
El objetivo cuando se usan robots no es simplemente ayudar a los humanos en los
procesos. En cambio, donde se usa, RPA debería reemplazar a los humanos por
completo. (Willcocks, Lacity y Craig, 2015).

Esta comparación es similar a las diferentes herramientas, por ejemplo, las hojas de
Excel, que es una herramienta para ayudar a los usuarios a realizar diferentes
cálculos; la presencia humana aún es necesaria. En RPA, la lógica es diferente, con
los cálculos realizados detrás del escenario, completamente por el robot, con solo
entrada y salida visibles y accesibles para un humano. (Willcocks, Lacity y Craig,
2015B).

Los robots se pueden usar a tiempo completo, pero para ejecutar, por ejemplo, 10
procesos simultáneamente, se necesitarían 10 robots o licencias.

Hay dos diferencias principales entre otros métodos de automatización y RPA,


ambos aspectos pueden describirse con "ligereza". En primer lugar, al contrario de
lo que pueda parecer, la configuración de los robots para hacer su trabajo no
requiere un vasto conocimiento de programación. (Willcocks, Lacity y Craig,
2015B)

En cambio, el software se configura más como un diagrama de flujo lógico, como


una lógica de solución para un rompecabezas. Por supuesto, de esto se trata
fundamentalmente la programación, pero RPA elimina las sintaxis y los lenguajes,
centrándose en la lógica central. En resumen, RPA se puede implementar
rápidamente sin un conjunto de habilidades pesadas. (Willcocks, Lacity y Craig,
2015)

En segundo lugar, RPA se considera TI "ligero" cuando se trata de su diseño.


(Willcocks, Lacity y Craig, 2015B)

Esto se refiere a la magnitud de los acoplamientos entre diferentes sistemas: el


robot no escribe directamente en una base de datos, sino que usa la capa de
presentación de un software, solo tiene acceso a los sistemas en un nivel de interfaz
de usuario, al igual que un humano. RPA no perturba el sistema subyacente

60
(Willcocks, Lacity y Craig, 2015) Cada acción que realiza un robot se puede
registrar fácilmente; El riesgo de incumplimiento es mínimo (Willcocks, Lacity y
Craig, 2015)

Esto es diferente a la mayoría de las automatizaciones de procesos de negocios


clásicos, que pueden manipular datos directamente en una base de datos o
"internamente". Ver Figura 12.

Figura 12: Las capas de software. Adaptado por Willcocks (2015B).

Características de RPA

Banda automatizable

Con una comprensión sólida del significado básico de RPA, es natural seguir con la
pregunta de dónde y cuándo es aplicable el concepto. Al igual que con toda la
automatización y programación, los robots necesitan reglas explícitas a seguir, que
descarta efectivamente los procesos no basados en reglas como factibles para RPA
(o cualquier otra automatización). (Willcocks, Lacity y Craig, 2015)

Definir los procesos objetivo más adecuados para la automatización para tener un
alto volumen de transacciones, un alto nivel de estandarización, una lógica
implícita bien definida y una alta madurez. Estos aspectos resultan en la mejor
recompensa para un proceso cuando se automatiza.

61
Un alto volumen significa un gran ahorro en tiempo de trabajo, la estandarización y
la lógica adecuada permiten un desarrollo sin problemas y una configuración de
robot, mientras que la madurez significa que el proceso probablemente no va a
desaparecer y, por lo tanto, anulará los recursos utilizados para desarrollar la
solución RPA. (Willcocks, Lacity y Craig, 2015A)

Agregue a esta lista, señalando que las tareas repetitivas son candidatos adecuados
porque la repetición es a menudo una causa de errores humanos.

Para ilustrar la idoneidad para la automatización, al estudiar la implementación de


RPA en Telefónica O2 en el Reino Unido, hemos introducido un concepto llamado
banda automatizable, que se ve en la Figura 13.

Figura 13: Las capas de software. Adaptado por Lacity (2015A).

Visualiza la relación entre el volumen de transacción y la duración del proceso. La


lógica subyacente es que un proceso necesita alcanzar un cierto ahorro de tiempo
para calificar como candidato para la automatización.

62
Este ahorro puede provenir de un bajo volumen de procesos largos, un alto
volumen de procesos cortos o una combinación de los dos extremos. (Willcocks,
Lacity y Craig, 2015)

Cabe señalar que la banda automatizable se aplica a toda la automatización, no


necesariamente solo a RPA. RPA es, de hecho, solo una herramienta de
automatización en el repertorio de una empresa. (Willcocks, Lacity y Craig, 2015)

RPA y la Gestión del cambio

RPA se trata de reemplazar a los humanos en la realización de tareas repetitivas, y a


menudo la implementación de robots se asocia con ahorros equivalentes a tiempo
completo (FTE). Por lo tanto, es fácil entender por qué los medios de comunicación
usan titulares que hablan de humanos que pierden su trabajo por los robots, y por
qué la gente está asustada y ansiosa por el RPA (Willcocks, Lacity y Craig, 2016)

Sin embargo, es solo una idea falsa: en realidad, los robots están destinados a
reemplazar a los humanos solo en las partes más tediosas y repetitivas del proceso,
y el FTE guardado se puede dirigir a otras tareas que los robots no pueden manejar
(Willcocks, Lacity y Craig, 2015)

Introducir RPA significa un cambio en el contenido del trabajo. Los robots se


pueden usar para amplificar y aumentar las fortalezas humanas, lo que significa que
los humanos harán lo que mejor puedan hacer: manejar todas las partes no
estructuradas de los procesos, p. datos que necesitan deducción más allá de la
lógica rudimentaria, algo que solo un humano puede hacer. (Willcocks, Lacity y
Craig, 2016)

Las tareas que requieren informes lineales y repetitivos, como las ganancias
corporativas, no fueron aceptadas entre los reporteros. Al automatizar estas tareas,
la compañía pudo cambiar el enfoque de sus reporteros para cubrir historias más
creativas.

63
Con el uso de robots, el número de informes de ganancias no solo se multiplicó por
diez, sino que se realizó sin costo adicional, los clientes estaban contentos con la
entrega acelerada y la calidad mejorada. Todos los reporteros mantuvieron sus
trabajos y pudieron concentrarse en aspectos más atractivos de sus trabajos.

Los empleados desconfían de cómo la automatización se impactará a sí mismos, y


es imperativo que los gerentes no simplemente ignoren este aspecto de RPA
(Willcocks, Lacity y Craig, 2016)

El cambio será visible especialmente en el desarrollo del talento. Considerar cómo


se puede desarrollar RPA y dónde se pueden adquirir esas habilidades es,
naturalmente, importante, pero también es importante tener en cuenta el cambio en
las capacidades de la fuerza laboral humana retenida.

Por ejemplo, si los robots realizan todas las tareas repetitivas, el contenido del
trabajo para los humanos se desplazará más hacia la creatividad y la resolución de
problemas, resolviendo casos de error. (Willcocks, Lacity y Craig, 2016)

Se debe hacer un plan para redistribuir estos recursos, de lo contrario, los posibles
ahorros de FTE no se realizarán correctamente, sin nada que hacer por los recursos
liberados por RPA (Slaby, 2012)

Como una tecnología novedosa con impactos radicales en la vida de los empleados,
RPA seguramente encontrará resistencia al cambio por parte de la organización. La
organización que implementa RPA debe estar alerta para ver posibles desajustes
con la cultura y estructura existentes de la organización.

Hay una serie de barreras que deben superarse. Las organizaciones con una cultura
más adecuada, en términos de capacidad de transformación, tienen una ventaja y
tienen más probabilidades de tener un buen desempeño en la fase de
implementación (Willcocks, Lacity y Craig, 2015A)

Pero con una gestión adecuada, estas barreras para otras organizaciones pueden
reducirse significativamente (Willcocks, Lacity y Craig, 2015B)

64
Para fortalecer la aceptación de toda la organización y habilitar adecuadamente la
automatización de servicios estratégicos, el proyecto de automatización requiere el
apoyo de la alta gerencia (Willcocks, Lacity y Craig, 2016)

No solo es suficiente desarrollar estrategias, la administración también debe


permitir la ejecución. Una forma de hacer esto es que el proyecto tenga un
patrocinador o un campeón, un portavoz visible que intente activamente vender
RPA a la organización, entre otras cosas tratando activamente de combatir los
obstáculos y reducir las barreras que amenazan el progreso. (Willcocks, Lacity y
Craig, 2016)

En un ejemplo, donde en un entorno hospitalario, el campeón de la automatización


de procesos aprendió de una tarea tediosa y lenta, buscando en línea los datos de las
especificaciones del producto. Se procedió a automatizar esta tarea con primera
prioridad.

Al hacer esto, no solo el hospital ahorró en términos de recursos liberados, sino que
también al levantar una tarea dolorosa y visible de las operaciones, los empleados
aprendieron de primera mano los beneficios que RPA puede ofrecer. Esto creó
entusiasmo y ayudó mucho a la automatización. Los patrocinadores a menudo son
personas no del departamento de TI, sino del lado comercial de las operaciones.
(Willcocks, Lacity y Craig, 2015B)

Es necesario prestar atención a la comunicación interna que rodea la


implementación de RPA (Willcocks, Lacity y Craig, 2015A)

Describa cómo: en su estrategia de comunicación, una empresa planificó con


anticipación y contrarrestó tácticamente el miedo a la RPA. El mensaje que la
administración quería transmitir era que RPA permitiría a las personas cambiar su
enfoque en el trabajo según sus propios intereses, prometiendo que todos
mantendrían sus trabajos.

65
La comunicación también se vincula con el campeón del proyecto mencionado
anteriormente; el papel es una herramienta esencial para transmitir el mensaje de
manera efectiva (Willcocks, Lacity y Craig, 2016)

Una adquisición fortalecida no solo hace que la implementación inicial sea más
fluida, sino que también ayuda a generar proyectos de seguimiento. Para combatir
la resistencia al cambio y ayudar a superar su ansiedad por la RPA, la compañía
debe ayudar a los empleados a comprender los beneficios que la automatización del
servicio traerá (Willcocks, Lacity y Craig, 2016)

Con los empleados que saben qué puede lograr la automatización de procesos y
cuáles son los beneficios, estarán encantados de dar más sugerencias para posibles
procesos objetivos (Willcocks, Lacity y Craig, 2015B)

Un ejemplo de esto muestra el autor Willcocks, muestra que en lugar de temer a


RPA, un equipo dio la bienvenida al robot como miembro del equipo, incluso
dándole el nombre de "Poppy". Finalmente, preguntaron si "Poppy" podría ser
entrenada para manejar más trabajo. (Willcocks, Lacity y Craig, 2015A)

Conjunto de Habilidades

Un aspecto notable de RPA es la facilidad de desarrollar y modelar procesos. Los


desarrolladores no requieren habilidades de programación, sino que deben estar
familiarizados con el conocimiento sobre los procesos comerciales (Willcocks,
Lacity y Craig, 2015)

En la práctica, el desarrollador no programa el robot, sino que le enseña la lógica


del proceso a seguir. Esto incluye reglas e instrucciones sobre qué teclas presionar y
cómo manejar ciertos casos de excepción (Willcocks, Lacity y Craig, 2015B)

Dado que el conjunto de habilidades no está asociado con la TI tradicional, no es


aconsejable ubicar el desarrollo a especialistas en TI, la RPA debe administrarse
como un proyecto comercial y de operaciones. (Willcocks, Lacity y Craig, 2015B)

66
RPA puede beneficiarse más de un equipo multifuncional, que involucra a los
usuarios de las operaciones, TI, desarrolladores e incluso proveedores, trabajando
juntos en el desarrollo del proceso y la solución. (Willcocks, Lacity y Craig,
2015B)

Si bien el conjunto de habilidades es diferente y algo "más ligero", no significa que


no se requiera capacitación (Willcocks, Lacity y Craig, 2015).

Las personas y sus roles dentro de la organización deben estar bien definidos y se
debe aplicar la capacitación adecuada para garantizar una funcionalidad adecuada
(Willcocks, Lacity y Craig, 2015B).

Las responsabilidades operativas incluyen manejo de excepciones, pruebas, soporte


de sistemas, soporte de procesos y soporte de productos (Willcocks, Lacity y Craig,
2015B).
Para cada tarea, debe aclararse qué función o función es responsable y cada función
debe estar debidamente capacitada (Willcocks, Lacity y Craig, 2015B).

La necesidad de enseñar y aprender es especialmente alta justo después de la


implementación (Willcocks, Lacity y Craig, 2015A), pero es importante continuar
el apoyo más allá de la implementación (Willcocks, Lacity y Craig, 2015B).

Selección de proceso objetivo

El primer paso de la automatización no debe ser la automatización en sí misma;


más bien, se debe tener cuidado al seleccionar procesos adecuados. Para este fin, la
implementación debe comenzar con preguntas como si este proceso existiera en
primer lugar.

La eliminación del proceso, la optimización y la simplificación deberían ser los


primeros pasos; Esto se hace para evitar la automatización de tareas redundantes y
permitir centrarse en las tareas que más se benefician de RPA. (Willcocks, Lacity y
Craig, 2015)

67
En general, en toda la implementación de RPA, hay tres fases principales en el
camino hacia la producción. Primero, el proceso se revisa en busca de partes que
puedan eliminarse, mejorando la eficiencia del proceso.

De esta manera, todas las demás ganancias en productividad se agotan antes de


confiar en la automatización.

A continuación, se lleva a cabo un tipo de proyecto de prueba de concepto, para ver


si RPA realmente funciona con todos los sistemas requeridos que la organización
necesita.

Finalmente, el despliegue de RPA ocurre, cubriendo todo, desde documentar el


proceso objetivo hasta entregar la solución RPA configurada a los usuarios.
(Willcocks, Lacity y Craig, 2015A)

Últimamente, ha habido avances significativos en la inteligencia artificial (IA), que


a largo plazo puede revolucionar aún más la automatización de los procesos
comerciales y cambiar los criterios de selección para qué proceso apuntar con RPA.

Esto es especialmente cierto con datos o procesos desestructurados y sin forma sin
lógica implícita para que los robots los sigan. (Willcocks, Lacity y Craig, 2015B)

Escalabilidad

Un aspecto importante de RPA es su escalabilidad. RPA es fácil de desarrollar en


comparación con las herramientas BPM tradicionales, pero además de eso, es más
fácilmente escalable. Esto es crucial para los proveedores de BPO, que ya en su
negocio buscan estrategias similares en sus procesos comerciales: la capacidad de
definir un proceso y reutilizarlo para múltiples clientes (Slaby, 2012).

Para habilitar la escalabilidad, debe incluirse en la estrategia de implementación y


desarrollo (Willcocks, Lacity y Craig, 2015B)

68
Para obtener el máximo rendimiento de los robots, deben ser expertos (Willcocks,
Lacity y Craig, 2015A)

La infraestructura interna debe crecer al ritmo de la automatización, para


mantenerse al día con la demanda en términos de recursos, y la arquitectura técnica
interna debe hacer esto posible. (Willcocks, Lacity y Craig, 2015)

De esta manera, el software se puede ampliar y reducir fácilmente para cumplir con
los cambios en la carga de trabajo (Willcocks, Lacity y Craig, 2016)

La escalabilidad debe ser una cultura y debe adoptarse en toda la organización.


(Willcocks, Lacity y Craig, 2015A)

Beneficios

En el futuro, los avances tecnológicos desempeñarán un papel importante en las


industrias de servicios. La automatización del servicio puede ofrecer múltiples
beneficios (Willcocks, Lacity y Craig, 2016), algunos de los cuales se resumen en
la Figura 14.

Figura 14: Valor RPA entregado. Adaptado por Willcocks. (2015B).

Estos no son solo beneficios financieros, sino que los robots también ayudan a
mejorar la velocidad y la calidad del servicio. Los robots pueden trabajar 24 horas

69
al día sin cansarse, lo que aumenta aún más la disponibilidad del servicio y la
entrega. Otro beneficio es una disminución en el número de errores, ya que los
robots pueden repetir tareas sin fallas de concentración.

Por ejemplo, en el caso de Telefónica O2 UK, el número de llamadas de


seguimiento debido a errores y tiempos de respuesta lentos se redujo en más del
80% (Willcocks, Lacity y Craig, 2015).

RPA puede automatizar servicios, acortando los procesos en un 60% y aumentando


la precisión. Esto, a su vez, conduce a una mayor satisfacción del cliente, mientras
que los costos también se reducen con ahorros del 25-50% reportado. (Bals, 2015)

Una cifra típica para el retorno de la inversión durante el primer año de RPA es del
30% o más (Willcocks, Lacity y Craig, 2016)

Telefónica O2, a abril de 2015, había desplegado más de 160 robots, que procesan
colectivamente de 400 000 a 500 000 transacciones mensuales. Esto produjo un
retorno de la inversión de tres años entre 650 y 800%. Si bien la RPA a menudo se
considera un método para ahorrar costos y disminuir el recuento de personal, estos
recortes no se han dado cuenta en muchos proyectos %. (Willcocks, Lacity y Craig,
2015A)

Las implementaciones exitosas muestran evidencia de que si bien los robots


reemplazan a los humanos en las áreas en las que se implementan, es posible
redirigir y reenfocar los recursos humanos a otras tareas. (Willcocks, Lacity y
Craig, 2015)

Reutilizar a los empleados en otras áreas sin la necesidad de dejar ir a nadie


(Willcocks, Lacity y Craig, 2015)

Proyectos

El desarrollo de una solución RPA es un proceso que tiene un comienzo distinto y


un final distinto. Comienza con la idea de usar RPA para un proceso objetivo, la

70
necesidad de la solución surge de las operaciones comerciales. Termina cuando la
solución RPA se ha desarrollado y puesto en uso. Por lo tanto, es razonable
considerar las implementaciones de RPA como proyectos.

Ciclo de vida del Proyecto

La definición de proyecto establece que debe tener una línea de tiempo con un final
y un comienzo (Artto, 2006)

Esta definición destaca la naturaleza temporal de los proyectos, pero a veces es


beneficioso incluir etapas de antes y después del proyecto mismo.

Esto lleva a una definición para el ciclo de vida del proyecto, con tres etapas
(visualizadas en Figura 15): etapas de trabajo que preceden al proyecto, etapas de
trabajo durante el proyecto y etapas de trabajo que siguen al proyecto. (Artto, 2006)

Figura 15: Ciclo de vida de un Proyecto. Adaptado por Artto (2006)

El proyecto actual comprende muchas fases. Varios autores se refieren a esta fase
de trabajo del proyecto como el ciclo de vida del proyecto, sin incluir las etapas
anteriores y siguientes del proyecto. (Parr, A., & Shanks, G., 2000)

El trabajo en el proyecto se divide en cuatro etapas principales: conceptualización,


planificación, ejecución y terminación, visualizadas en la Figura 16, y sus
contenidos resumidos en Tabla 01. La conceptualización es la etapa que incluye la
especificación del proyecto. Una pregunta importante en esta fase es la necesidad

71
del proyecto: por qué es necesario, qué metas y objetivos debería tener. (Pinto, J.
K., & Slevin, D. P., 1988)

Figura 16: Fases de implementación de un proyecto.

Tabla 01:
Etapas del proyecto y sus contenidos resumidos
Etapa del Proyecto Contenido
Anterior Ideación, selección de proveedor.
Conceptualización Especificaciones, alcance
Planificación Programación, plan, asignación de recursos.
Ejecución Trabajar en el proyecto
Terminación Terminar, finalizar documentación, transferir conocimiento.
Seguimiento Uso de soporte, trabajo adicional.
Elaboración: Propia

En la fase de planificación, todas las actividades requeridas en el proyecto están


definidas y programadas. Este paso describe el marco de tiempo para el proyecto,
así como también establece los requisitos de recursos.

La ejecución es cuando tiene lugar el trabajo real. Para los usuarios, esta es la parte
más visible y tangible del ciclo de vida del proyecto.

La última fase es la finalización, que comprende cerrar el proyecto y entregarlo del


equipo del proyecto a los usuarios o propietarios. Este paso incluye finalizar la
documentación del proyecto y transferir todo el conocimiento a los propietarios.

Describen con más detalle las etapas del proyecto de implementación de un ERP
(Figura 17). El trabajo durante el proyecto se divide en seis pasos, configuración,
reingeniería, diseño, configuración y prueba y finalmente instalación. Parr &
Shanks tienen, en descripción, las fases de conceptualización y planificación
fusionadas como una sola y la fase de finalización se llama mejora. (Parr, A., &
Shanks, G., 2000)

72
Figura 17: Fases de una implementación ERP. Adaptado de Parr y Shanks (2000).

Consideran que un proyecto de TI consta de seis etapas (Tabla 02). Iniciación,


adopción, adaptación, aceptación, rutina e infusión. La iniciación es la fase de
identificación de una necesidad y un área posible para implementar una solución de
TI. La adopción contiene el proceso de toma de decisiones para sentar las bases del
proyecto y decidir qué curso tomar. La adaptación, entonces, es la etapa donde la
aplicación se configura e implementa.

Tabla 02:
Etapas de un proyecto de TI, basado en Cooper y Zmud (1990).
Etapa del Proyecto Contenido
Iniciación Identificar la necesidad y el área para la implementación de la solución.
Adopción Decidir sobre la solución, el proyecto y su alcance.
Adaptación Configurar e implementar solución
Aceptación Instalar y comenzar a usar
Rutina Solución integral
Infusión Extraer beneficios con la solución
Elaboración propia

Además, esto es cuando los procesos dentro de la organización se refinan para


adaptarse a la nueva solución. A continuación, en aceptación, la aplicación
instalada se incrusta en la organización. La rutina lleva esto aún más lejos, con la
solución convirtiéndose en una parte cada vez más integral de la organización.
Finalmente, la infusión es cuando la solución comienza a mostrar sus beneficios,
apoyando las actividades organizacionales. (Cooper, R. B., & Zmud, R. W., 1990)

Proyecto Exitoso

73
Definir el éxito del proyecto es un paso necesario antes de discutir proyectos
exitosos. Aquí hay dos conceptos importantes: el éxito de la gestión de proyectos y
el éxito del producto. El éxito de la gestión de proyectos es el grado en que un
proyecto y el proceso del proyecto cumplen sus objetivos, principalmente costo,
tiempo y calidad. Además, los clientes deben aceptar el proyecto.

El éxito del producto se relaciona con los aspectos del producto final,
principalmente cómo se cumplen sus requisitos. Es importante enfatizar que estas
dos dimensiones tienen diferentes factores de éxito, y cualquiera puede fallar
mientras que la otra tiene éxito. (Pinto, J. K., & Slevin, D. P., 1988)

Estas dos dimensiones del éxito son muy similares en muchos aspectos y, por lo
tanto, fáciles de mezclar. Sin embargo, es importante distinguir la gestión de
proyectos y el éxito del producto entre sí. Según, existe una jerarquía entre los dos
tipos de éxitos: el éxito del producto es más importante que el éxito de la gestión de
proyectos.

Esto se deduce directamente de sus definiciones: el éxito del producto es lo que


piensan los usuarios del proyecto, mientras que el éxito de la gestión del proyecto
se considera cómo se siente la gestión del proyecto. Podría decirse que la opinión
de los usuarios es más importante que la del equipo de gestión, ya que son los
usuarios los que usan el producto, después de todo.

Esta jerarquía se describe en la Figura 9, donde la meta y el propósito del proyecto


se clasifican según el éxito del producto, mientras que los productos y las entradas
son herramientas para el éxito de la gestión del proyecto. (Pinto, J. K., & Slevin, D.
P., 1988)

El objetivo se define como la forma en que el proyecto podrá ayudar a la


organización a alcanzar su objetivo estratégico. Lo que proporciona el objetivo es el
razonamiento de por qué se necesita el proyecto, como parte de una imagen más
amplia. El propósito del proyecto es un objetivo a corto plazo del proyecto.

74
En términos de jerarquía, el propósito es menor que el objetivo: el propósito
proporciona las herramientas tácitas para lograr el objetivo. La salida del proyecto
es la entrega del proyecto en su sentido tradicional, es decir, la salida concreta y
tangible de un proyecto. Las entradas del proyecto son los recursos que se utilizan
para completar el proyecto.

Estos recursos pueden ser, p. monetaria y puede describirse utilizando las tres
medidas tradicionales del proyecto: alcance, cronograma y costo. Una vez más,
estos aspectos pueden organizarse como una jerarquía: los resultados sirven como
una herramienta para completar el propósito, mientras que los datos de entrada, de
manera similar, son una herramienta para completar los resultados. Esta jerarquía se
enfatiza en la Figura 18. (Pinto, J. K., & Slevin, D. P., 1988)

Figura 18: Jerarquía del éxito del proyecto (adaptado por Baccarini, 1999).

Los gerentes de proyecto se centran fácilmente en hacer que el proyecto tenga éxito
en términos de éxito en la gestión del proyecto, sin tener en cuenta el éxito del
producto. Este enfoque es comprensible: los objetivos a largo plazo, como la
felicidad del usuario, pueden ser difíciles o incluso imposibles de medir durante el
proyecto. Centrarse solo en objetivos a corto plazo, como el presupuesto, puede ser
más beneficioso para dirigir el proyecto, pero podría no conducir a
implementaciones exitosas del producto. Un proyecto puede ser un éxito incluso si
falla en términos de éxito del producto.

Factores críticos del éxito

75
En la gestión de proyectos, los factores críticos de éxito (CSF) son aspectos de un
proyecto que, si se satisfacen adecuadamente, permitirán que un proyecto se
complete con éxito. (Leidecker, J. K., & Bruno, A. V., 1984)

En general, los CSF son solo herramientas para dirigir la atención de la gerencia a
las áreas correctas del proyecto. Los proyectos tienden a tener éxito o fracasar en
función de la atención que reciben los CSF. En la investigación, existe cierto
acuerdo de que ciertos factores son más comunes y más influyentes en los
proyectos. Sin embargo, debido a la variación y las diferencias entre los proyectos,
no todos los factores son universales y, por lo tanto, es imposible componer una
lista completa de LCR. (Wateridge, 1995)

Uno de los factores más comunes es el apoyo de la alta dirección para permitir la
finalización adecuada de un proyecto, la alta dirección debe estar del mismo lado,
permitiendo la ejecución. Sin el apoyo de la parte superior, los recursos necesarios
y la autoridad para avanzar en el proyecto son difíciles de lograr. (Hartman, F., &
Ashrafi, R., 2002)

Definir metas y objetivos claros para un proyecto es crucial. Esto tiene un doble
impacto: con objetivos claros, es más fácil determinar si son factibles o no, y sirven
para guiar a los participantes hacia la dirección correcta. (Pinto, J. K., & Slevin, D.
P., 1988)

Desde una perspectiva inversa, objetivos mal definidos, a menudo en conflicto,


conducen al fracaso. (Wateridge, 1995)

Estrechamente vinculado a los objetivos está la gestión de las expectativas. Somers


y Nelson (2001) mencionan esto como un CSF separado, pero puede verse como
parte del establecimiento y la reevaluación de las metas a medida que avanza el
proyecto.

Un CSF para proyectos es la participación del usuario. Este aspecto tiene muchos
nombres, algunos más directos (participación del usuario, consulta al cliente,

76
participación del usuario que otros (consulta del propietario, cooperación
interdepartamental). (Parr, A., & Shanks, G., 2000)

La conclusión aquí es que para que un proyecto tenga éxito, los usuarios deben ser
escuchados y el proyecto debe ser guiado para satisfacer las necesidades reales de
los usuarios. Los usuarios deben participar en el diseño del sistema. (Parr, A., &
Shanks, G., 2000)

La satisfacción del usuario está estrechamente relacionada con otros CSF,


principalmente la participación del usuario y la gestión de las expectativas. La
necesidad del proyecto surge de los usuarios, por lo que un objetivo prioritario debe
ser satisfacer las necesidades y expectativas de los usuarios. (Wateridge, 1995)

Otro nombre para este CSF es la aprobación del propietario, que aunque no es
exactamente lo mismo, transmite el mismo mensaje: el proyecto debe ser
administrado para cumplir con sus requisitos y obtener la aprobación del usuario. Si
los usuarios no están satisfechos con los resultados, no es probable que los utilicen
en todo su potencial. Este CSF también se vincula con la dimensión de éxito del
producto del éxito del proyecto. (Hartman, F., & Ashrafi, R., 2002)

La aceptación del usuario está estrechamente relacionada con la satisfacción del


usuario. (Parr, A., & Shanks, G., 2000)

Si bien la satisfacción del usuario es principalmente un fenómeno pasivo, la


aceptación del usuario se puede aumentar al "vender" el proyecto a los usuarios.
(Pinto, J. K., & Slevin, D. P., 1988)

Un método de esta "venta" es utilizar un campeón del proyecto, que también puede
considerarse como su propio LCR. (Parr, A., & Shanks, G., 2000)

El campeón suele ser un miembro de la organización de usuarios, encargado de


avanzar en el proyecto y combatir cualquier obstáculo que pueda dañar el progreso.
El campeón no necesariamente debe ser una persona de autoridad, sino que debe

77
tener entusiasmo, optimismo, visión y talento para la gestión de conflictos para
impulsar el cambio organizacional. (Beath, 1991)

Si bien algunos CSF son más abstractos, hay espacio para herramientas concretas y
tradicionales, como un cronograma o plan para el proyecto. El éxito en los
proyectos se atribuye a trabajar con un plan detallado, y el fracaso puede resultar de
no tener dicho plan. (Wateridge, 1995)

La gestión del proyecto también es importante. Las acciones oportunas basadas en


información en tiempo real sobre el estado del proyecto ayudan a dirigir un
proyecto hacia el éxito. (Wateridge, 1995)

Sin un conjunto de habilidades adecuado, el resultado del proyecto no puede


utilizarse en todo su potencial. Para este fin, los usuarios deben ser educados y
entrenados. (Somers, T. M., & Nelson, K., 2001)

Además, se debe prestar atención a cualquier cambio en los procesos comerciales


subyacentes; Los usuarios deben ser conscientes de cómo este cambio afecta su
trabajo. (Somers, T. M., & Nelson, K., 2001)

Además del conjunto de habilidades de los usuarios, la competencia del equipo del
proyecto también debe estar en un nivel. (Hartman, F., & Ashrafi, R., 2002)

Esto cubre tanto las habilidades como los recursos, es decir, los miembros del
equipo deben tener las habilidades adecuadas, pero los recursos tecnológicos del
equipo y su uso también deben ser competentes. Además, los recursos deben ser
adecuados. (Pinto, J. K., & Slevin, D. P., 1988)

Esto significa tener recursos dedicados para el equipo del proyecto, para garantizar
un progreso continuo y sin problemas.

Si bien los gerentes de proyecto hacen todo lo posible para garantizar el progreso
del proyecto, es imposible evitar por completo los contratiempos. Para este fin, es
imperativo que el equipo del proyecto pueda manejar situaciones inesperadas; Esta

78
actividad se llama solución de problemas o soporte. (Somers, T. M., & Nelson, K.,
2001)

Uno de los CSF más importantes es la comunicación. (Hartman, F., & Ashrafi, R.,
2002)

La comunicación en sí misma no afecta tanto el progreso; más bien habilita otras


áreas clave. (Wateridge, 1995)

Transmitir adecuadamente, por ejemplo, las expectativas del usuario al equipo de


desarrollo son crucial y requiere suficientes prácticas de comunicación. Como
facilitador, la comunicación necesita un enfoque adecuado; los gerentes de proyecto
a menudo se centran demasiado en medidas concretas de éxito.

Un proyecto a menudo aporta algo nuevo a la organización del usuario. Para


adaptar e implementar el resultado final, se debe considerar la reingeniería de
procesos comerciales. (Somers, T. M., & Nelson, K., 2001)

Se puede lograr el mismo resultado al tener una personalización mínima en el


proyecto (Somers y Nelson, 2001) o delinear y rediseñar procesos ya previos al
proyecto (Grover et al., 1995).

La gestión del cambio, tanto en el proyecto como en la organización que lo rodea,


es importante (Grover et al., 1995; Somers y Nelson, 2001; Hartman y Ashrafi,
2002). Los proyectos especialmente grandes pueden requerir cambios significativos
en la organización y sus procesos para permitir una implementación adecuada
(Somers y Nelson, 2001). Ver el resumen de los factores de éxito en la Tabla 03.

Tabla 03:
Resumen de los factores críticos de éxito más comunes
Factor crítico de
Descripción Fuente
éxito

Apoyo adecuado de la alta Pinto & Slevin, 1988; Järvenpää & Ives,
Soporte de alta
dirección para impulsar el 1991; Parr et al., 1999; Somers &
gerencia
proyecto Nelson, 2001; Hartman & Ashrafi, 2002

79
Factor crítico de
Descripción Fuente
éxito

Definir objetivos claros para que Pinto & Slevin, 1988; Wateridge, 1995;
Metas y objetivos
el equipo del proyecto se Somers & Nelson, 2001; Hartman &
claros
esfuerce hacia Ashrafi, 2002

Gestión de
Somers & Nelson, 2001
expectativas

Pinto & Slevin, 1988; Wateridge, 1995;


Involucramiento del Involucrar a los usuarios en el
Parr et al., 1999; Somers & Nelson,
usuario proyecto y su diseño.
2001; Hartman & Ashrafi, 2002

Los usuarios deben estar


Satisfacción del Wateridge, 1995; Parr et al., 1999;
satisfechos con el resultado final
usuario Hartman & Ashrafi, 2002
del proyecto.

Aceptación de Los usuarios deben aceptar el


Pinto & Slevin, 1988; Parr et al., 1999
usuario resultado final del proyecto.

Una persona que impulsa el Beath, 1991; Parr et al., 1999; Somers
Proyecto campeón
proyecto & Nelson, 2001

Pinto & Slevin, 1988; Wateridge, 1995;


Cronograma del Calendario de actividades del
Grover et al., 1995; Hartman & Ashrafi,
proyecto proyecto
2002

Pinto & Slevin, 1988; Wateridge, 1995;


La actividad de dirigir el proyecto
Gestión de proyectos Grover et al., 1995; Somers & Nelson,
en la dirección correcta.
2001

Conjunto de habilidades del


Grover et al., 1995; Parr et al., 1999;
Equipo de proyecto equipo del proyecto y
Somers & Nelson, 2001; Hartman &
Competencia competencia tecnológica de los
Ashrafi, 2002
recursos.

Recursos adecuados y dedicados Pinto & Slevin, 1988; Parr et al., 1999;
Recursos dedicados
asignados al proyecto Somers & Nelson, 2001

Solución de Pinto & Slevin, 1988; Somers & Nelson,


Apoyo en caso de problemas.
problemas / soporte 2001

Pinto & Slevin, 1988; Wateridge, 1995;


Comunicación entre diferentes
Comunicación Somers & Nelson, 2001; Hartman &
partes interesadas del proyecto
Ashrafi, 2002

80
Factor crítico de
Descripción Fuente
éxito

Reingeniería de Rediseño de procesos para Grover et al., 1995; Somers & Nelson,
procesos de negocio adaptarse al proyecto. 2001

Gestión del cambio de Grover et al., 1995; Somers & Nelson,


Gestión del cambio
organización y procesos. 2001; Hartman & Ashrafi, 2002

Elaboración: Propia

Además de estos factores de éxito críticos comunes, hay innumerables más.


Algunos de los factores adicionales pueden incluirse en una definición más amplia
de estos factores, o son más específicos para ciertos tipos de proyectos.

Por ejemplo, han basado su lista de 22 CSF en la implementación de sistemas ERP.


Listar todos los CSF posibles y sus variaciones queda fuera del alcance de esta tesis
y, por lo tanto, esta lista no se expande más. (Somers, T. M., & Nelson, K., 2001)

Lecciones del proyecto de implementación de RPA

Esta subsección recopila lecciones relevantes para la gestión de proyectos, de


diferentes implementaciones de RPA.

Han detallado ocho pasos cruciales para implementar RPA (Tabla 6). Primero, la
organización debe alinear RPA con su negocio. Esto significa combinar estrategias
y asegurarse de que la estrategia RPA esté en línea con la estrategia corporativa.
Entonces, la organización en torno a RPA debe ser clara y bien definida,
incluyendo a alguien como responsable principal, un rol de jefe de RPA.

Esto no solo cubre los roles, sino también el diseño del proceso de implementación.
El diseño debe adaptarse a las necesidades de la organización: una organización
grande y compleja requiere un departamento de RPA más centralizado, mientras
que una organización más pequeña se beneficia más de un modelo flexible y ligero.

El tercer paso es una continuación del paso anterior; debe haber una junta de
gobierno de RPA, que es responsable de administrar la tubería de demanda de RPA.

81
De esta manera, las tareas se pueden evaluar y priorizar adecuadamente, y las que
tienen más potencial se pueden implementar primero. (Willcocks, Lacity y Craig,
2015B)

El cuarto paso comprende toda la metodología interna de entrega de RPA. Se debe


acordar un proceso, que se sigue cuando se está implementando un nuevo proceso.

Se debe implementar un modelo de participación en el servicio para respaldar los


procesos operativos. Esto incluye soporte para errores y excepciones y otro soporte
del sistema. Los roles para estas funciones deben ser interorganizacionales.

En la organización, las personas deben tener roles claramente definidos con


responsabilidades establecidas. Se debe proporcionar capacitación para permitir
operaciones eficientes.

RPA puede ampliarse fácilmente, pero para habilitarlo correctamente, debe


incluirse en el proceso de implementación desde el principio. Tienen dos aspectos
que consideran importantes para permitir la escalabilidad. En términos de entorno
técnico, se debe establecer una infraestructura escalable de bajo mantenimiento.

Por ejemplo, si establecer nuevos servidores para RPA es fácil, entonces es posible
multiplicar la capacidad en un corto plazo. Además, la escalabilidad debe incluirse
en la filosofía de diseño de la solución misma. De esta forma, las soluciones
establecidas se pueden copiar a través de diferentes procesos, disminuyendo el
tiempo de desarrollo. (Willcocks, Lacity y Craig, 2015B). Ver Tabla 04.

Tabla 04:
Lista de factores clave de RPA. Adaptado por Willcocks (2015B).
Paso Descripción

Establecer alineación de negocios-RPA Definir cuál es el papel y el significado de RPA

Definir el diseño organizacional. Estructura de organización, responsabilidades.

Formar una junta de gobierno de RPA El tablero para mantener las ruedas RPA girando

82
Acordar la metodología de entrega de RPA Define the pipeline process for RPA

Establecer soporte Apoyo a los usuarios finales en sus problemas.

Definir roles y responsabilidades.


Autoexplicativo
Autoexplicativo

Definir un entorno escalable. Autoexplicativo

El escalado es uno de los aspectos más


Plan para escalar
importantes: prepárese para aprovecharlo
Elaboración propia

Perfilar un proceso de implementación de RPA

Esta sección está dedicada a analizar y sintetizar diferentes aspectos del ciclo de
vida del proyecto y la literatura de éxito en términos de RPA, y luego usar los
resultados de ese análisis, para delinear un modelo para el proceso del proyecto de
implementación de RPA (en adelante, el proceso de RPA).

El proceso RPA se enfoca en la implementación de la solución RPA para un


proceso objetivo. En este estudio, el proceso objetivo se refiere al proceso al que se
dirige la automatización RPA.

Una suposición clave en el futuro será que el software robótico, junto con su
infraestructura, ya está instalado. Esto significa que el proceso RPA desarrollado
aquí no tratará con la configuración del software y la plataforma, sino que se
centrará solo en implementar la solución robótica para el proceso objetivo. Desde
esta perspectiva, algunos pasos en el ciclo de vida del proceso o los factores críticos
de éxito serán redundantes.

 Roles:

Se debe hacer una aclaración sobre los roles en el proceso de RPA. Si bien
la literatura de RPA no describe explícitamente los roles definitivos
involucrados en el desarrollo de RPA, hay algunos que se pueden distinguir.

83
Un desarrollador RPA es responsable de desarrollar la solución RPA para el
proceso objetivo. Este rol también debe tener un conocimiento suficiente de
lo que la RPA puede o no hacer, para poder juzgar si RPA es la solución
adecuada para el caso o no.

Puede haber un solo desarrollador RPA en el proyecto, o puede haber


varios. El segundo rol es el usuario final, el que realmente usa la solución
RPA desarrollada. No es factible involucrar a todos los usuarios finales en
el proyecto, ya que puede haber cientos de usuarios.

Por el contrario, el gerente debe seleccionar algunas personas clave para


probar primero y probar la solución. Finalmente, debe haber un
administrador del lado del usuario final, que represente a la organización
objetivo a gran escala.

El administrador y los usuarios finales combinados se denominan lado


comercial. Los roles se enumeran en la Tabla 05, y su jerarquía se visualiza
en la Figura 19.

Tabla 05:
Roles en el proceso de RPA.
Rol Descripción

Desarrollador de RPA Responsable del conocimiento y desarrollo de RPA

Usuario final Usuario del proyecto entregable

Gerente Gestiona la implementación en el lado comercial


Elaboración Propia

84
Figura 19: Roles y su Jerarquía

 Ciclo Vital

Para comenzar, el proceso necesita un ciclo de vida del proyecto, una línea
de tiempo para anclar otros nodos. Como base, el proceso de proyecto de
tres pasos abstracto a gran escala (donde el proceso se divide en el trabajo
que precede, durante y después del proyecto) descrito por (Artto, 2006)

Será utilizado. El modelo ofrece una base que es al mismo tiempo lo


suficientemente abstracta y concreta como para servir como base básica.
Las etapas anteriores y siguientes del proceso son necesarias, porque el
proceso RPA no es independiente, sino una parte dependiente de la
estrategia general de RPA.

Para detallar la etapa de implementación del proyecto, se dividirá en cuatro


sub-etapas, conceptualización, planificación, ejecución y finalización. La
conceptualización comprende todas las especificaciones del proceso, pero
también responde por qué el proyecto es necesario en primer lugar, qué
metas y objetivos tendrá.

Esta fase cubre también lo que (Cooper, 1990) llaman iniciación y partes de
la adopción, la primera trata de identificar lo que realmente se necesita. El

85
último de las dos tratas más sobre la gestión del proyecto y el alcance del
proyecto, algo que se incluye en la fase de planificación.

Esta etapa consiste en programar el proyecto y determinar su alcance,


habiendo decidido cuál será la solución. Por ejemplo, en la
conceptualización RPA.

Se verifica como la solución más viable para el proceso objetivo, luego, la


planificación se utiliza para diseñar un cronograma para desarrollar e
implementar la solución.

La terminación como fase incluye la conclusión del proyecto, también


marca la transferencia de responsabilidades del equipo del proyecto al
negocio.

De estas cuatro actividades, la conceptualización y la terminación son más


visibles para los usuarios finales, mientras que la planificación y la
ejecución son más evidentes para los desarrolladores de RPA. Estos cuatro
pasos y el ciclo de vida general del proyecto se visualizan en la Figura 20.

Figura 20: Ciclo de vida del proyecto en forma general.

Partiendo de las actividades en ejecución pueden detallarse más. Las tareas


de configuración y reingeniería pueden considerarse parte de la

86
configuración del sistema, en este caso de tesis, el software robótico y la
infraestructura requerida. Sin embargo, como la configuración del software
no se considera dentro del alcance de este modelo de proceso, no se
incluirán en el modelo.

Debe incluirse un paso para el diseño, una etapa donde se desarrolla la


solución RPA. Este paso es el más concreto de todo el proceso, ya que el
proceso objetivo se traduce en un marco que el robot puede usar para
realizar las tareas necesarias. Otro elemento clave para cualquier proyecto
de software es la fase de prueba. El desarrollo nunca es perfecto, lo que
significa que es probable que ocurran errores, por lo que las pruebas son un
paso necesario para erradicar y corregir errores.

Este paso lo realizan primero los desarrolladores de RPA, pero luego es


necesario incluir a los usuarios finales para asegurarse de que se cumplan
las especificaciones. Los pasos de diseño y prueba deben formar un bucle de
retroalimentación iterativo, que permita corregir los errores descubiertos en
las pruebas rediseñando y reconfigurando la solución. (Parr, A., & Shanks,
G., 2000)

Una etapa describe como instalación y como aceptación, la actividad en la


que la solución se utiliza realmente, debe incluirse en el proceso. En el
proceso RPA, este elemento se llamará despliegue. El nombre se refiere a
que la fase es gradual y interdependiente, un ciclo iterativo en lugar de una
tarea única. En esta etapa, la solución RPA se presenta a los usuarios finales
y primero se pone a prueba mediante una pequeña muestra para verificar
que todo funcione como se esperaba.

Luego, si los usuarios lo aceptan, el proceso se implementa gradualmente


para todos los usuarios, sin dejar de estar atento a los problemas y
solucionarlos en el camino. La razón por la cual se requiere este tipo de
prueba iterativa de etapas múltiples es porque RPA está muy unido a los
procesos comerciales subyacentes. Con procesos más sensibles,
simplemente no hay margen de error.

87
Además de eso, para permitir la aceptación del usuario, el proceso debe
ajustarse para adaptarse a los requisitos del usuario; La naturaleza iterativa
de las pruebas asegura que los usuarios hayan sido escuchados y que sus
requisitos se cumplan realmente. (Parr, A., & Shanks, G., 2000)

Los dos últimos pasos son la rutina y la infusión. Estos dos pasos continúan
integrando aún más la solución a la organización. Se podría argumentar que
estos son vitales para una implementación exitosa, pero también hay
argumentos en contra de incluirlos en el modelo. Por un lado, un proyecto
tiene una línea de tiempo clara: un inicio y un final, pero estos dos pasos son
ambiguos, lo que significa que su línea de tiempo no se define fácilmente.

Además, la responsabilidad de completar estas tareas queda fuera del


alcance del proyecto. Depende de la empresa implementar completamente la
solución RPA y cosechar todos los beneficios que pueden obtener. Este
proceso RPA tiene más que ver con el desarrollo y la entrega de la solución
RPA, no tanto con las tácticas a largo plazo. Estos dos pasos no se incluirán
en el proceso tal como están, sino que parte de su contenido se incluirá en la
fase de implementación, así como en la finalización. (Cooper, 1990)

Estos dos pasos y el ciclo de vida y sus etapas explicadas se visualizan en la


Figura 21.

88
Figura 21: Proyecto de ciclo de vida y sus etapas explicadas

 Factores de éxito

En esta sección, todos los CSF descubiertos en la revisión de la literatura


serán examinados meticulosamente, para determinar si son relevantes para
RPA o no, cómo contribuirán a un mayor éxito del proyecto, y cómo
encajan mejor en el proceso de RPA. La combinación de los conocimientos
sobre RPA de la literatura con la gestión de proyectos y los CSF es lo que
dará como resultado un modelo de proceso adecuado para los proyectos de
RPA.

Se afirman que los factores críticos de éxito son secuenciados en el tiempo e


interdependientes, y pueden establecerse como una ruta crítica. Esto
significa que los CSF no son solo valores que deben tenerse en cuenta, en

89
un segundo plano, al desarrollar la solución RPA: se pueden traducir en
acciones, etapas o puntos de control en el proyecto. Cuanto antes aparezca
un CSF en el proceso de RPA, más debe tratarse como un punto de control
donde la falla detendrá todo el proyecto.

Más tarde, se han invertido recursos y, por lo tanto, ya no es viable detener


todo el proyecto, sino que se deben observar los CSF fallidos y se deben
tomar las precauciones necesarias para prepararse para una posible falla de
implementación. Algunos de los CSF se traducirán directamente en
elementos en el proceso, mientras que otros se convertirán en definiciones o
requisitos que deben cumplirse. (Pinto, J. K., & Slevin, D. P., 1988)

El soporte de alta gerencia es imprescindible en RPA. Sin ella, hay


demasiados obstáculos en el camino, y una implementación exitosa de RPA
será casi imposible. Si bien este factor podría ser un CSF global, no se
incluirá como tal porque, supuestamente, la alta dirección de la organización
es pro-RPA y, por lo tanto, el factor quedaría fuera del alcance de esta tesis.
En cambio, el apoyo de la alta dirección debe convertirse en un punto de
control en la conceptualización, donde sin apoyo, RPA no se considera un
candidato viable.

Definir objetivos claros es importante para cualquier proyecto relacionado


con TI. Las computadoras solo pueden seguir reglas estrictamente definidas
y formateadas, por lo tanto, los objetivos también deben estar claramente
definidos. En TI, hay un término llamado definición de hecho, que significa
traducir los objetivos a una lista de requisitos que deben cumplirse para que
el proyecto se considere completado.

Esta lista puede formatearse como una lista de verificación, para ampliar
aún más su propósito como un conjunto de objetivos. Para RPA, la claridad
adicional es igualmente importante, ya que los objetivos ambiguos pueden
ser difíciles de traducir en instrucciones para el software robótico. Una
definición de hecho actuaría como una herramienta para realizar un

90
seguimiento de todas las cosas que el robot debe lograr, por ejemplo, lo que
hace que el proceso objetivo se considere completado.

La implementación de esta herramienta reduce el riesgo de que el desarrollo


se descarrile en una dirección que no impulse el proyecto hacia su
finalización. Este CSF debe incluirse como parte de la conceptualización.
(Davis, 2013)

Los proyectos de RPA tienen que ver con ayudar a los usuarios finales en su
trabajo, brindando nuevas herramientas de automatización para completar
las tareas más rápido y sin problemas. La participación del usuario es, por lo
tanto, crucial para los proyectos de RPA. Este factor también está
estrechamente relacionado con la satisfacción del usuario, que puede
satisfacerse involucrando a los usuarios finales en el proyecto.

Los usuarios finales deben participar en la traducción del proceso objetivo


al que realizan definición de hecho, que les permite opinar sobre lo que es
realmente beneficioso automatizar, al tiempo que aclara cualquier confusión
sobre lo que comprende el proceso.

Los desarrolladores de RPA no necesitan tener conocimiento del lado


comercial; Con los usuarios finales involucrados, pueden confiar en la
traducción del proceso objetivo que se les proporciona. Permitir que los
usuarios finales den su opinión también agrega un control de cordura en el
proceso; Si el proceso objetivo que se automatiza es de alguna manera
redundante, los usuarios pueden expresar su opinión.

Mirar esto desde otro punto de vista, sin incluir a los usuarios finales, sería
como automatizar algo desconocido sin ninguna idea del valor agregado
para el proceso y el proyecto. Los usuarios finales deben participar en el
proceso de RPA de principio a fin.

La aceptación del usuario es una parte crucial en cualquier proyecto, al igual


que en los proyectos RPA. Con la solución RPA desarrollada con los

91
usuarios finales involucrados, el riesgo de que el producto no se use se
reduce significativamente, pero no se anula por completo.

Para disminuir aún más este riesgo, un defensor del proyecto debe participar
en ambos RPA en general, pero también en el proyecto RPA en cuestión.
Tener una persona con un rol o responsabilidad más cercana al usuario final
le permite al campeón tener un impacto más fuerte.

Por lo tanto, el campeón debe ser elegido desde el lado comercial. En los
proyectos RPA específicamente, el campeón podría ser el gerente, ya que de
todos modos será su responsabilidad asegurarse de que la implementación
de la solución RPA sea exitosa. El campeón, con su actitud positiva de
RPA, debería ser capaz de inspirar a los usuarios finales a recibir RPA como
una herramienta positiva y beneficiosa.

Además del campeón, la aceptación del usuario se beneficiará de una forma


clara y transparente de trabajar y entregar lo que se promete, a tiempo. No
hay nada RPA específico para este enfoque, más bien es algo que la
administración del proyecto debe considerar en todos los proyectos. Sin
embargo, dado el menor tamaño de los proyectos RPA, los dos CSF
tradicionales, el cronograma y la gestión de proyectos no son tan
importantes como en los proyectos en general.

Esto se debe a que tanto el alcance del proyecto como el tamaño de la


organización son pequeños con solo unos pocos participantes, lo que
significa que no hay necesidad de un gobierno y gestión de alto nivel.
Ambos factores tradicionales están suficientemente integrados en el modelo
del ciclo de vida del proyecto y en la definición de cada etapa y se
consideran bastante evidentes, por lo que no requieren ninguna atención
adicional en los proyectos de RPA.

Las habilidades de los individuos están involucradas en dos CSF, el


conjunto de habilidades del usuario y la competencia del equipo del
proyecto. Nuevamente, la naturaleza de los proyectos RPA como pequeños

92
y ágiles significa que hay menos necesidad de una gestión formal del
proyecto y, por lo tanto, las habilidades del equipo del proyecto en el área
de gestión no son un requisito absoluto.

Cuando se trata de desarrolladores de RPA, deben tener suficiente


conocimiento de RPA para poder desarrollar la solución requerida. En más
detalle, esto implica habilidades requeridas en el uso del software RPA, así
como saber cómo funciona RPA, tanto como solución técnica como
proceso. Una solución para adquirir este conjunto de habilidades podría ser
la capacitación o el estudio para obtener certificados del software.

Para los usuarios finales, su habilidad para usar la solución RPA es un


facilitador clave. Sin una capacitación adecuada en el uso de la nueva
herramienta, el proyecto no será un éxito, la resistencia al cambio podría ser
demasiado alta con un desconocido aterrador. Además, asegurarse de que
los usuarios finales estén capacitados para comprender qué es RPA y qué no
es, ayuda a generar ideas para futuros procesos y desarrollo objetivo.

Al reunir a estos dos CSF relacionados con las habilidades, la competencia


del equipo del proyecto es parcialmente crítica, pero no cae en el alcance del
proceso RPA específicamente, mientras que el conjunto de habilidades del
usuario es un factor verdaderamente crítico que debe tenerse en cuenta.

Para los usuarios finales, debe incluirse en el lanzamiento a más tardar, pero
está mejor preparado para funcionar a lo largo de toda la fase de ejecución.
De esta manera, todavía hay tiempo suficiente para comenzar la
capacitación requerida. Para los desarrolladores, supuestamente fueron
educados antes del proyecto como parte de una implementación estratégica
más amplia de RPA, lo que significa que su capacitación solo actúa como
un punto de control desde el principio, validando la viabilidad de RPA
como método.

Los recursos dedicados pueden significar múltiples cosas. Uno, puede ser la
disponibilidad de los desarrolladores, que, por supuesto, es crítica para el

93
progreso del proyecto. Dos, pueden referirse a los usuarios finales y su
participación en el proyecto, lo que puede ser, dependiendo de la
organización, complicado.

Los usuarios finales a menudo están ocupados con su propio trabajo, e


involucrarlos en un proyecto de desarrollo puede parecer secundario en su
propia priorización. Por lo tanto, deben recibir instrucciones claras y la tarea
de participar en el proyecto RPA y, si es necesario, su otra carga de trabajo
debe aligerarse para contrarrestar este nuevo deber que tienen.

El soporte y la resolución de problemas son importantes para cualquier


tecnología nueva y desconocida, y lo mismo se aplica a RPA.
Especialmente al probar la solución, los usuarios finales encargados de la
prueba deberían recibir un soporte adecuado y fácilmente accesible.

Esto disminuirá la barrera mental que podrían tener para comunicar sus
problemas con RPA y la nueva solución al equipo del proyecto y,
especialmente, a los desarrolladores. Además, la solución rápida de
problemas permite generar una buena impresión duradera de RPA,
vendiendo aún más el concepto para el futuro.

Una vez que el proyecto ha concluido, se debe establecer un modelo de


apoyo para no separar completamente el lado comercial. Esto implica
principalmente la creación de canales para el soporte técnico de RPA, que
se ocupa de cualquier problema que surja sobre la solución RPA. El soporte
después del proyecto debe distinguirse del soporte durante las pruebas y el
desarrollo; los desarrolladores de RPA en el proyecto podrían no ser
responsables del soporte que sigue al proyecto.

Un proyecto consta de muchas partes individuales que deben realizarse


juntas para que el proyecto tenga éxito. Para habilitar esto, la comunicación
es crítica. Diferentes partes interesadas deben ser capaces, sin considerable
esfuerzo, comunicarse entre sí, transmitir información crítica a través del
equipo del proyecto.

94
La comunicación debe actuar como una columna vertebral para todo el
proyecto, siguiendo en cada etapa y cada actividad. Dado que el desarrollo
de RPA depende de la retroalimentación iterativa, solo resalta aún más la
importancia de la comunicación. Sin barreras bajas para la comunicación,
los comentarios nunca llegarán a los desarrolladores, dejando a la solución
RPA tímida de sus requisitos esperados y conduciendo aún más a una
implementación no exitosa.

Si bien la comunicación es principalmente importante durante el proyecto,


los canales deben mantenerse abiertos incluso una vez que el proyecto haya
finalizado, para permitir que nuevas ideas y cualquier problema se
comuniquen en toda la organización.

La reingeniería de procesos comerciales, como se indica en la literatura, es


importante para cualquier automatización. La esencia de estos CSF es
asegurarse de que el proceso se optimice primero para RPA, no solo
automatizar lo que se proporciona.

Por ejemplo, un proceso podría implicar mover archivos a una carpeta


temporal para una administración visual más fácil para el usuario final, pero
para un robot este paso no es necesario y debe cortarse del proceso. El
enfoque de reingeniería de procesos comerciales implica involucrar a la
producción lo más cerca posible, para asegurarse de que el desarrollador
comprenda la lógica detrás del proceso comercial.

De esta manera, en lugar de replicar rutinas desarrolladas naturalmente no


optimizadas, el proceso objetivo para la automatización RPA debe
optimizarse a la T. Es posible que al analizar el proceso objetivo con esta
mentalidad, el proceso sea completamente redundante, terminando así el
proyecto RPA temprano. Por lo tanto, este paso debe incluirse en la
conceptualización lo antes posible, para no desperdiciar recursos.

95
RPA se trata de cambiar ciertos procesos que se realizan, reemplazando el
trabajo humano por uno robótico. Por lo tanto, la gestión del cambio es un
concepto clave en los proyectos de RPA. De alguna manera, está integrado
con otros CSF, como la aceptación del usuario, pero vale la pena incluirlo
como una parte separada del proceso de RPA.

La responsabilidad de que los usuarios finales acepten el cambio recae en el


gerente. Este aspecto es especialmente importante porque los usuarios
finales pueden ver la RPA como una amenaza, y el miedo a perder sus
trabajos puede complicar la implementación. Con una adecuada
comunicación y gestión del cambio, este impacto puede mitigarse.

Concluyendo, hay algunos factores críticos de éxito que no encajan bien con
RPA, pero la mayoría de ellos son relevantes para los proyectos de RPA.
Partiendo del análisis anterior, el modelo de proceso de RPA detallado en la
sección anterior se puede elaborar aún más completando la línea de tiempo
con cada CSF. Los CSF relevantes se presentan en la Tabla 06, junto con las
fases del ciclo de vida que mejor se adaptan. La Figura 22 representa la
misma información en forma visual.

Tabla 06:
CSF relevantes para RPA y sus fases del ciclo de vida.
Factor Fase
Comunicación General
Gestión del cambio General
Proyecto campeón General
Involucramiento del usuario General
Soporte de alta gerencia Conceptualización
Objetivos claros Conceptualización
Reingeniería de procesos de negocio Conceptualización
Recursos dedicados Planificación
Satisfacción del usuario Ejecución
Aceptación de usuario Ejecución y Terminación
Soporte y solución de problemas Ejecución y seguimiento
Conjunto de habilidades del usuario Ejecución
Fuente: Elaboración Propia

96
Figura 22: Proyecto de ciclo de vida y CSF combinados

Otros Factores

Grandes porciones de la literatura de implementación de RPA giran en torno a la


configuración de las capacidades iniciales. En su mayor parte, tales lecciones caen
fuera del alcance de una automatización de procesos de un solo objetivo y, por lo
tanto, también están fuera del alcance de esta tesis. Sin embargo, hay algunas
nociones clave que deben tenerse en cuenta en el diseño del proceso de RPA.

Uno de esos aspectos es la naturaleza interorganizacional de los roles. Si bien es


mejor definir roles establecidos para el proyecto, estas definiciones no deben ser
demasiado restrictivas. Los proyectos de RPA siempre serán interorganizacionales;
Se debe evitar crear barreras adicionales definiendo roles de manera demasiado
divisiva. Es necesario dividir las responsabilidades, sin embargo, solo deben actuar
como pautas.

Por ejemplo, los desarrolladores de RPA no pueden dejar de decir que solo
desarrollan la solución basada en la descripción del proceso traducida, sino que
deben tener un papel activo para facilitar el éxito del proyecto en todas sus áreas.

97
Lo mismo ocurre con los negocios, que deben darse cuenta de que RPA es
beneficioso para ellos, en lugar de tratar de resistir el cambio.

RPA no se trata de éxito a corto plazo, sino más bien una herramienta para
ganancias a largo plazo. Este tema debe tenerse en cuenta en todo momento, y
deben tomarse decisiones para optimizar los beneficios a largo plazo, no la
optimización a corto plazo. Un ejemplo concreto de esta mentalidad es la
escalabilidad, que es otro tema esencial para incluir en el proceso de RPA. Las
soluciones escalables pueden ser más exigentes de desarrollar, pero darán frutos a
largo plazo al no tener que reinventar la rueda con cada proceso objetivo.

Resumen

En esta sección, las ideas recopiladas de la literatura sobre la gestión de proyectos y


RPA se fusionaron para formar un modelo para el proceso de RPA. Hacerlo dio
como resultado un esquema del proceso que se basa en la teoría de gestión de
proyectos pero que se ha enriquecido con el conocimiento de RPA. Además, este
modelo fue aromatizado con observaciones basadas en la literatura sobre
implementaciones de RPA.

El modelo no se detalla al nivel más fino, sino que enfatiza los aspectos cruciales y
los pasos que deben considerarse para maximizar las posibilidades de éxito para el
desarrollo y la implementación de la solución RPA en el proceso objetivo.

En la actualidad el RPA para el año 2020 ha evolucionado en diferentes tecnologías


y ha cambiado la forma de implementación dentro de un área de negocio de una
empresa. De la cual empezaremos a ver los diferentes pasos a seguir a
continuación.

Construyendo una base sólida para su implementación de RPA

Ernst & Young cree firmemente en el poder de RPA. La firma no solo tiene una
práctica próspera en la industria, sino que también utiliza la tecnología para mejorar
su propia operación, a escala global. Pero esto no quiere decir que Ernst & Young

98
no esté exenta de críticas a RPA. La empresa se da cuenta que, al igual que con
cualquier tipo de sistema de software empresarial importante, hay muchos terrenos
potenciales minas Por supuesto, los consultores de Ernst & Young son buenos para
guiar a los clientes a través de ellos.

¡Curiosamente, uno de los negocios de más rápido crecimiento de la empresa


proporciona remediación servicios para implementaciones fallidas de RPA!

En un informe de la firma, hubo un análisis extenso de una amplia gama de RPA


implementaciones (que abarcan 20 países). ¿La conclusión de alto nivel? Bueno, no
fue alentador. Ernst & Young descubrió que entre el 30 % y el 50 % de los
proyectos iniciales de RPA fracasaron. (Taulli, 2020)

Ahora bien, esto no es una acusación de la tecnología. Tenga en cuenta que Ernst &
Young cree que los proveedores de RPA generalmente tienen un software sólido.
Pero como con cualquier tecnología que tiene un gran potencial impacto en una
organización, debe haber una planificación considerable. Pero desafortunadamente,
esto es algo que puede obtener escasa atención.

En este capítulo, destacaremos los pasos iniciales de RPA, para armar un plan que
proporcionará una base duradera. (Taulli, 2020)

Metodologías de proceso

Aplicación de Lean y Six Sigma a RPA

Los usos de Lean, Six Sigma y Lean Six Sigma exigen un mayor compromiso de
tiempo y recursos. Fácilmente podría significar retrasar una implementación de
RPA de seis meses a un año. Pero esto finalmente puede valer la pena. Tenga en
cuenta que muchos de los principales responsables de TI y gestión las firmas
consultoras tendrán muchos cinturones negros de Six Sigma que pueden ayudar a
rediseñar el proceso, que deberían contribuir en gran medida a que un sistema RPA
sea aún más impactante.

99
Esto no quiere decir que deba retener dicha empresa. Hay muchos ejemplos de
empresas que han adoptado un enfoque de "hágalo usted mismo" y han tenido éxito
con él. De todos modos, todavía debe haber cierto nivel de atención a los procesos
actuales y estándar de Procedimientos Operativos. ¡El hecho es que probablemente
fueron creados en un ad hoc moda, sin pensarlo mucho! Debido a esto, debe haber
ricas oportunidades para encontrar mejoras.

Pero definitivamente hay algunas conclusiones de Lean, Six Sigma y Lean Six
Sigma que puede ayudar con estas acciones preliminares. En primer lugar, es
recomendable armar algunos mapas de procesos, como con una herramienta como
Visio de Microsoft o Blueworks Live de IBM. Él software permitirá crear
rápidamente visualizaciones que resaltarán las áreas potenciales para el rediseño.
También podrá invitar a otros usuarios para obtener valiosos comentarios. Al hacer
esto, hay algunos factores a tener en cuenta:

 ¿Cuáles son los cuellos de botella y las causas fundamentales? ¿Qué se


puede hacer para mejorarlos?
 Piense en las ideas centrales de FMEA. Entonces, antes de realizar un
cambio en el proceso, necesita para hacer una lluvia de ideas sobre las
consecuencias no deseadas. ¿Dónde podrían salirse las cosas de los rieles?
En última instancia, es posible que se dé cuenta de que algunas funciones no
son buenas candidatas para automatización.
 Movimiento: No se limite a utilizar el software. Camine por la oficina y
tenga una idea de la organización. Luego repase los aspectos físicos de lo
que hace un empleado en el escritorio. Al hacer todo esto, debería tener una
idea mucho mejor de dónde están las oportunidades para mejorar los
procesos.
 Implicaciones de la automatización: dado que las personas son propensas a
cometer errores, especialmente con tareas tediosas: puede haber medidas de
seguridad establecidas. Esto puede ser algo así como tener alguien revisa un
proceso. Sin embargo, con RPA, este paso probablemente no sea necesario
ya que la automatización llevará a cabo el proceso de la misma cada vez.
Pero esto es mientras haya pruebas exhaustivas, validación, control y
auditoría del bot antes de que se lance a un entorno de producción.

100
 Autoridad: en un proceso, a menudo hay momentos en los que se necesita la
aprobación de un gerente. Esto podría ser para permitir la emisión de un
pago, por ejemplo, durante un cierto Monto. Pero con RPA, este proceso se
puede simplificar mediante el uso de excepciones que se crean en el
sistema. Además, con las tecnologías emergentes de IA, incluso puede ser
posible crear un bot que pueda tomar la decisión por sí mismo.

Una vez que tenga su mapa de procesos, estará en una posición mucho mejor para
su RPA implementación. Pero de acuerdo con los principios de Lean y Six Sigma,
también es importante tener un enfoque en la mejora continua. El mapa de procesos
debe ser simplemente el primer paso en un viaje para seguir encontrando más
formas de mejorar los procesos. (Taulli, 2020)

Planeamiento para RPA

Los Preliminares

Es cierto que RPA es relativamente fácil de usar debido a los flujos de trabajo
interactivos y las capacidades de arrastrar y soltar. Pero esto puede conducir a un
problema persistente, es decir, es tentador simplemente apresurarse y comenzar con
una implementación de RPA, por ejemplo, mediante la creación de muchos bots
para automatizar procesos.

En la superficie, este enfoque tiene algunas ventajas intuitivas. Oye, después de


todo, ¿no debería un ser ágil la organización? ¿No es una buena idea experimentar
y probar ideas innovadoras? Todos estos son importantes. Pero si está demasiado
ansioso por implementar RPA, el resultado puede ser fácilmente el caos y el
fracaso.

Más bien, un enfoque preferido es redactar un plan de acción por escrito, que
proporciona la clave prioridades, objetivos y roles para la implementación de RPA.
También debería haber una mirada a la seguridad, el impacto en TI, el gobierno y el
cumplimiento.

101
Como no debería sorprender, un buen ejercicio para comenzar es la lluvia de ideas.
En esta etapa, ser libre y no criticar las ideas. El objetivo es dar rienda suelta a la
creatividad y el ingenio. Como tanto como sea posible, intente obtener
retroalimentación de diferentes partes de la organización, como marketing,
finanzas, recursos humanos, legal, TI y ventas.

Algunas de las preguntas a considerar incluyen las siguientes:


 ¿Cuál es el grado de automatización en su departamento?
 ¿Qué funciona ya? ¿Por qué?
 ¿Qué se está quedando corto?
 ¿Qué procesos se pueden mejorar? ¿Y puede ayudar la automatización?
 ¿Cuáles son los procesos que son repetitivos y rutinarios? ¿Cuántas
personas están implicadas?
 ¿El tiempo dedicado a los procesos?
 ¿Qué tecnologías no han funcionado en el pasado? ¿Por qué?
 ¿Cuál es el sentimiento general sobre la automatización? ¿Hay resistencia a
esto? ¿Puede que empleados temen por sus puestos de trabajo?

Básicamente estarás en un modo de descubrimiento. Así que asegúrese de tener una


aplicación que pueda rastrear las ideas y permitir comentarios. Algo tan simple
como armar un documento puede ayudar con el proceso.
Para algunas empresas, establecerán un taller, digamos, durante unos días. será un
atención intensiva a la ideación. Pero también es una oportunidad para proporcionar
algo de formación, que incluiría tutoriales sobre los fundamentos de RPA, los
beneficios de la tecnología y cómo cambiará el trabajo diario. (Taulli, 2020)

Para obtener un ejemplo del mundo real de un taller, considere CloudStorm. la


empresa es un proveedor de servicios para ayudar al software RPA, sino que
también organiza talleres de un día para su clientela.

Esta es la estructura:

 Introducción a los bots de software y la automatización: este es un manual


general sobre RPA y cómo esta usado. También hay cobertura de diferentes

102
casos de uso que son relevantes para el cliente en esta industria. Finalmente,
CloudStorm repasa qué tareas son las mejores para la automatización, así
como algunas de las trampas para evitar.
 Identificación y Elaboración de Automatización de Procesos: Implica
actividades grupales para proponer ideas para identificar áreas para
automatizar. Al hacer esto, usted puede tener un blanco tablero o pared
donde los pines. Después de un poco de discusión, el equipo puede anotar
ideas (en términos de factibilidad, costo y rendimiento potencial), como por
ejemplo votando.
 Discusión y Validación: Esta es otra discusión interactiva. Puedes dividir el
agrupar en diferentes equipos y luego presentar y validar las ideas. (Taulli,
2020)

¿Qué automatizar?

Parece fácil seleccionar lo que necesita ser automatizado, ¿verdad? Bueno, esto es
cierto en algunos casos. Pero como ya hemos visto en este capítulo, es necesario
que haya algún análisis de los procesos: para obtener una visión holística del flujo
de trabajo. A partir de esto, estarás en una situación mucho mejor. Posición para
ver lo que necesita ser automatizado.

Pero también es fundamental comprender que RPA es adecuado para ciertos tipos
de automatización. Su no es una solución única para todos. Además, al evaluar qué
automatizar, debe haber un grupo de personas con antecedentes diversos: en
términos de tecnología, experiencia comercial y conocimiento de las operaciones
diarias de un departamento. Entonces, ¿cuáles son las áreas adecuadas para RPA?
He aquí un vistazo a algunos factores clave:

 Trabajo tedioso: Es el tipo de actividad que requiere poco conocimiento.


Esto podría ser cortar y pegar y hacer clic en una variedad de botones.
Seamos realistas, ¿quieres pagarle a un talentoso empleado hacer cosas tan
comunes?

103
 Consume mucho tiempo: ¿Qué tipos de procesos dan como resultado
resultados tardíos? Esto podría ser, digamos, para crear un informe o hacer
el procesamiento de fin de trimestre.
 Repetitivo: el proceso tiene un conjunto de pasos que rara vez cambian.
Esto es ideal para el enfoque mecánico de RPA.
 Frecuencia: Para obtener valor real, el proceso es algo recurrente. Esto
podría ser donde una persona se involucra en la actividad algunas veces a la
semana.
 Basado en reglas: esto se debe a que RPA le permite crear fácilmente flujos
de trabajo, que tienen características como la lógica IF / Then para llevar a
cabo acciones de manera consistente.
 Procesos claramente definidos: desea asegurarse de tener algunas métricas
básicas, como el número de pasos o un diagrama de flujo.
 Gran volumen: Tales actividades pueden ser problemas para los
trabajadores. Pero, por supuesto, el software es correcto para el manejo de
procesos de alta velocidad.
 Propenso al error: ¿Hay áreas donde los errores de entrada de datos son
comunes?
 API: si una API no está disponible, entonces el proceso podría ser un buen
candidato para RPA automatización.
 Personalización: Cierto, sus aplicaciones pueden permitir esto. Pero es
costoso. Puede que tengas que pagar honorarios para el vendedor, así como
para la contratación de terceros. En otras palabras, la opción RPA podría ser
más rentable.
 Datos sensibles: El acceso a los empleados es sin duda un riesgo. Pero con
parte de un bien definido Bot RPA, debería tener una protección mucho
mejor de los datos.
 Escala: si no desea contratar a más personas para aumentar las operaciones,
porque la configuración de TI actual es bastante rígida, entonces RPA
podría ser una buena opción.
 Organización: busque áreas dentro de una empresa donde haya silos
persistentes y cuellos de botella. (Taulli, 2020)

Retorno sobre la Inversión (ROI) para RPA

104
Tener una idea del ROI es difícil en las primeras etapas de una implementación de
RPA. Pero es importante inventar algo. Esto ayudará a establecer algunos hitos para
lograr y también proporcionan una forma de realizar un seguimiento del proyecto
en general. Pero para obtener una buena medida de la ROI, es probable que deba
esperar al menos un año.

¿Qué es parte del cálculo entonces? La parte de "retorno" de la ecuación es


generalmente los costos que se ahorran del proyecto RPA, como por la menor
necesidad de equivalente a tiempo completo empleados (ETC).

Ejemplo: suponga que desea automatizar el proceso de facturación y requiere


cuatro FTE a quienes se les paga $ 20 por hora. Trabajan en el proceso 40 horas a la
semana. Así, el trabajo total los costos llegarán a $ 166.400 por año.

Como parte del sistema RPA, ha reducido los costos en un 60% a $ 58,240 por año,
lo que pone la ganancia neta en $ 108,160 ($ 166,400 menos $ 58,240)
En continuación, los costos anuales del sistema RPA son de $ 80.000. Significa que
el ROI es como sigue, ver Tabla 07:

Tabla 07:
Los Costos Anuales del Sistema RPA.
Año Cantidad Ahorrada ROI

1 $108,160 35.2%

2 $216,320 170%

3 $324,480 306%

En este ejemplo, este proyecto sin duda sería un gran ganador. Sin embargo, al
mirar el ROI, es posible que desee tener una mirada más amplia.

Para el lado de retorno, podría rastrear áreas como las siguientes:

105
 Precisión: ¿Cuál ha sido la disminución de errores en comparación con el
manejo del proceso en una manera manual? Además, la calidad de los datos
es mejor porque hay menos errores con los datos. ¿aporte?
 Satisfacción del cliente: ¿Ha habido una mejora? Una métrica común para
mirar es el puntaje de satisfacción del cliente (CSAT), que es una encuesta
de clientes que pregunta "¿Cómo satisfecho quedo con su experiencia?” O
podría usar el puntaje de promotor neto (NPS). Esto muestra el interés de un
cliente en recomendar el producto de una empresa o servicio - y el índice
oscila entre –100 y 100.
 Agilidad: ¿Qué tan rápido es el proceso ahora? Después de todo, un bot
puede trabajar a alta velocidad las 24 horas del día, los 7 días de la semana.
 Satisfacción de los empleados: puede enviar una encuesta periódica para ver
si ha habido una mejora. Además, observe si las tasas de ausentismo y
rotación han disminuido.
 Innovación: ¿con el RPA manejando tareas comunes, ha habido más tiempo
para empleados para proporcionar un mayor valor añadido? ¿Están creando
nuevos enfoques o innovaciones?
 Análisis: puede obtener un mejor seguimiento de sus procesos, lo que puede
proporcionar aún más ideas sobre qué áreas mejorar.

Puede observar algunos de los beneficios cualitativos. ¿Ha habido más


confiabilidad en el ¿proceso? ¿Se mejora el cumplimiento en general? Con tales
cosas, puedes incluirlas en un informe, que debería ayudar con la aceptación del
proyecto RPA.

En cuanto a los costos, el elemento principal, por supuesto, es la tarifa de licencia o


suscripción para el software. También puede haber otros gastos de TI, como la
compra de bots preconstruidos, servidores, servicios de alojamiento y otro software.
Luego, tendrá que dar cuenta de la mano de obra.

Costos de implementación, desarrollo de bots y monitoreo, que pueden incluir la


contratación de una empresa consultora. Es por eso que muchas empresas y
consultores han utilizado una medida más integral llamada costo total de propiedad,

106
que analiza los costos indirectos durante el ciclo de vida de la automatización, así
como los costos directos (es decir, licencias de software).

La buena noticia es que, con el tiempo, debería haber economías de escala. En otras
palabras, ciertas líneas de pedido, como las de capacitación, pueden rechazarse.
Pero, de nuevo, también habrá declina con el retorno porque habrá menos
oportunidades para la “fruta al alcance de la mano” para la automatización. (Taulli,
2020)

El Plan

Hasta ahora, hemos analizado las formas de comprender y prepararse para una
implementación de RPA. A medida que perfecciona las áreas clave del proyecto,
será el momento de elaborar un informe escrito. Plan no necesariamente tiene que
ser largo o detallado. En cambio, el enfoque debe estar en desarrollar una hoja de
ruta clara y efectiva. Puede comenzar con los objetivos y metas de alto nivel. Las
sugerencias incluyen:
 Reducir el tiempo FTE trabajado en los procesos
 Mejore los tiempos de ciclo y de respuesta.
 Reducir el número de errores

Una vez más, la estimación de estos, en la mayoría de los casos, estará lejos de ser
precisa. Pero es importante establecer hitos claros para alcanzar. Y si resultan
demasiado onerosos o no particularmente desafiante, luego puede hacer ajustes a
mitad de camino.

El plan RPA también debe ser coherente con los objetivos de transformación digital
de la empresa. Esto también debe estar respaldado por un campeón o patrocinador
del proyecto, esperemos que de las filas ejecutivas. Esto será una indicación de la
importancia y compromiso con el proyecto RPA.

A continuación, el plan debe establecer los miembros del equipo central. A menudo
se trata de una diversidad grupo, incluyendo personas de diferentes departamentos.

107
También tendrá que haber un fuerte líder ya que es probable que los miembros del
equipo no trabajen en el proyecto RPA a tiempo completo.

Sin duda, el plan debe ser claro en los roles y tareas de cada miembro del equipo
(en capítulo 6, veremos cómo formar un CoE, que puede servir como equipo). Y
luego es una buena idea involucrar al departamento de TI en el proceso para
asegurarse de que no haya problemas de integración, seguridad y gobernabilidad.

Luego, el plan puede analizar los factores para la evaluación del proveedor de RPA.
En el Capítulo 5, vamos a Mira esto con mucho más detalle. Finalmente, el plan
debe tener una hoja de ruta del proyecto que muestre los plazos y los entregables.
Por lo general, esto comenzará con el piloto o la prueba de concepto. Como se
señaló anteriormente en el capítulo, el primer proyecto será más limitado, lo que
debería permitir un mayor aprendizaje y llegar a resultados más rápidos. Pero el
plan también puede cubrir los objetivos a más largo plazo para los esfuerzos de
RPA, en términos de áreas a automatizar y departamentos a cubrir. (Taulli, 2020)

Evaluación de proveedores de RPA

Los factores correctos a considerar dependiendo de cómo defina RPA, que puede
ser algo confuso, hay más de 70 vendedores de software una de las razones es que
el mercado aún se encuentra en las primeras fases y está en evolución, como con
tecnologías como la IA.

Por supuesto, con el reciente aumento de la financiación en la categoría, esto ha


incentivado a muchos emprendedores a crear sus propias empresas emergentes. Ah,
y crear software RPA no es necesariamente difícil (al menos cuando se trata de
funcionalidad como raspado de pantalla).

De todos modos, la profusión de proveedores de RPA significa que no es práctico


tener una evaluación comprensiva. Más bien, deberá crear una lista breve que, por
lo general, se ajusta a sus requisitos. Esto es lo que cubriremos en este capítulo.
Veremos los factores clave para tomar la decisión correcta de una selección de un
proveedor de RPA.

108
Ser Realista

La evaluación del software puede ser tediosa y llevar mucho tiempo. También es
difícil pasar por la exageración inevitable. ¿Qué es real vs. la pelusa? Puede ser
difícil saberlo. Pero la decisión requiere mucho cuidado y diligencia. Y no se trata
sólo de los gastos.

“Una relación con un proveedor de RPA podría ser similar a un matrimonio que no
termina bien”, dijo Thomas Phelps, quien es el CIO en Laserfiche.
“Desafortunadamente, es relativamente emocionante entrar, pero es muy difícil y
doloroso salir. El bloqueo de proveedores es inevitable. Tú no puede hacer clic en
un botón para descargar todas las automatizaciones de procesos que creó y
reutilizarlas en la plataforma de otro proveedor. Los costos de cambio serán altos si
cambia a otro proveedor.”

Además, las capacidades de un sistema RPA pueden variar ampliamente y muchas


de ellas probablemente no tengan mucha relevancia para su negocio. El hecho es
que no hay perfecta solución. En otras palabras, habrá ciertas áreas en las que
necesitará hacer compromisos

Echa un vistazo a terceros

Una buena manera de comenzar con la creación de una lista corta es consultar las
encuestas y la investigación de organizaciones de analistas como Forrester y
Gartner. Tienen los recursos y la experiencia para hacer inmersiones profundas en
el software RPA. “Observe Gartner Peer Insights, que son revisiones validadas de
usuarios, para obtener perspectivas de usuarios reales, desde el nivel de CIO hasta
el arquitecto empresarial”, dijo Phelps.

“Peer Insights proporciona una gran cantidad de información de alto nivel sobre el
cliente en general satisfacción con un proveedor, evaluación del proveedor y
proceso de negociación, implementación, soporte técnico y otras áreas.” Otra buena
fuente es buscar sitios de revisión de software. Tendrán los suyos análisis y

109
valoraciones y comentarios generados por los usuarios. Cierto, parte del contenido
puede ser sesgado, pero aun así debería tener una buena idea de los temas
principales. Estos son los sitios a considerar:
G2.com (www.g2.com/categories/robotic-process-automation-rpa): Desde
2012, el sitio ha acumulado más de 843 500 reseñas. En cuanto a su apartado
RPA, el mejor valorado los proveedores incluyen UiPath, Automation
Anywhere, WinAutomation by Softomotive, y Blue Prism.
 Gartner (www.gartner.com/reviews/market/robotic-processautomation-
software): El sitio tiene los siguientes como los proveedores mejor
calificados: UiPath, Automation Anywhere, Blue Prism, y TruBot.
 TrustRadius (www.trustradius.com/robotic-process-automation-rpa):
Lanzado en 2014, el sitio tiene más de 211,000 reseñas. El software RPA
mejor clasificado los proveedores son UiPath, Automation Anywhere, Blue
Prism, and WorkFusion.
 HFS Research (www.horsesforsources.com): La firma fue la primera en
reconocer RPA como una categoría de tecnología emergente en 2012. La
investigación es de alta calidad y mucho de eso es gratis. (Taulli, 2020)

Capacidades mínimas

Debido al ferviente interés en RPA, algunas empresas de software han utilizado el


término para describirse a sí mismos, ¡incluso si hay poca conexión! No hay nada nuevo
acerca de esto. Pero por supuesto, podría significar resultados terribles para el cliente.

Es por eso que desea asegurarse de que el software tenga funciones básicas de RPA.
Como mínimo esto quiere decir que debe existir la creación y despliegue de bots, que
realicen la automatización. Si bien una parte clave de esto es el raspado de pantalla,
también es importante tener incorporado integraciones para aplicaciones comunes. Y
debería haber una consola de administración robusta para los bots (como permitir el
seguimiento, la orquestación y el análisis), así como formas de manejar excepciones
comerciales (aquí es cuando una persona necesita intervenir porque el bot no trabajo).

La primera etapa de la evaluación también debe incluir una prueba de concepto (POC).
Después de todo, Los proveedores de RPA a menudo tienen períodos de prueba para su

110
software. Entonces, ¿por qué no iniciar un pequeño proyecto para obtener una idea de
las características y capacidades? Esto a menudo se confunde con un programa piloto.
Pero hay claras diferencias. Un POC suele ocurrir en las primeras etapas y es para un
entorno de desarrollo. El piloto, en el por otro lado, es para una aplicación del mundo
real que entrará en producción.

¿Quién es el usuario?

Sí, esta pregunta parece un poco simplista. Pero la realidad es que, al hacer la decisión
de comprar software RPA: fácilmente podría no prestarse suficiente atención a las
necesidades del usuario final. Con todo, esto significa que habrá un riesgo de falta de
adopción. “Al evaluar el software RPA, asegúrese de seleccionar la herramienta
adecuada para la audiencia adecuada”, dijo Niraj Patel, quien es el director gerente de
inteligencia artificial en DMI. "Por ejemplo, para la RPA de front-end, que conecta a los
consumidores con los bots, deberá seleccionar tecnologías conversacionales, a
diferencia del RPA de back-end, que está orientado al software del sistema central.

Además, para la RPA de front-end, es posible que desee hacer que los agentes de su
centro de llamadas sean bot dueños Las plataformas pueden permitirles medir y
monitorear el rendimiento de los bots con back-end gerencia, el personal técnico debe
administrar y evaluar la calidad del trabajo que se realiza.” En su mayor parte, el
usuario final no será una persona técnica, sino que será una persona administrativa o
comercial.

“Hay un truco para evaluar a los proveedores de RPA, y es importante, porque se desvía
mucho de, digamos, la selección de proveedores de ERP”, dijo David Lee, quien es
analista senior de investigación de aplicaciones - Datos y análisis en Info-Tech Grupo
de investigación.

“La participación empresarial activa es muy importante y, de hecho, TI no será el único


probando la creación de bots: el negocio debe ser el que construya los bots. esto se pone
se perdió mucho, porque con demasiada frecuencia las empresas ven esto como otra
solución tecnológica, y espere que TI se lo lleve y regrese con una recomendación. Esto
no funciona."

111
Fondos

Durante la primera mitad de 2019, la financiación de riesgo se mantuvo a un ritmo


vertiginoso, con 62.000 millones de dólares en inversiones en empresas emergentes de
EE. UU.4 Suponiendo que el ritmo continúe, será un récord histórico para el año. Los
mercados extranjeros también han sido fuertes en alrededor de $ 104 mil millones. Sin
embargo, los mercados de financiación tienden a centrarse en un número relativamente
pequeño de operaciones porque los montos de inversión han aumentado
significativamente. En otras palabras, aunque una categoría como RPA puede estar al
rojo vivo, aún podría ser difícil para muchos de los jugadores obtener suficientes
fondos.
Sin duda, esto es algo a tener en cuenta cuando se trata de evaluar el software de un
proveedor. ¿Tendrá la empresa los recursos para invertir en I+D, infraestructura y
soporte? También, ¿Puede una pequeña empresa competir cuando se trata de contratar
talento? ¿Y habrá suficiente? recursos para llevar a cabo adquisiciones?

Ecosistema

Incluso los grandes jugadores de RPA no tienen los recursos para construir una
verdadera solución de extremo a extremo. En la mayoría de los casos, es probable que
un cliente necesite otro software para llenar algunos de los vacíos (y algunos se pueden
ser bastante evidentes). Debido a esto, desea una plataforma RPA que tenga un
ecosistema próspero de socios y integraciones.

Una indicación clara de esto es cuando hay una tienda de bots (es decir, una tienda de
aplicaciones para descargar aplicaciones). Esto reducirá en gran medida el tiempo de
desarrollo y también debería mejorar el rendimiento general del bot. Según Automation
Anywhere, su Bot Store ha logrado ahorros de costos del 50 % y del 70 % gracias a una
automatización más rápida de los procesos.

Costos

112
Por supuesto, esta suele ser la consideración más importante cuando se trata de
seleccionar un sistema RPA. Pero si hay demasiado enfoque en esto, en última
instancia, puede comprar el mal plataforma, lo que podría obstaculizar gravemente su
proyecto. Tenga en cuenta que el precio entre los proveedores de RPA son bastante
competitivos. Así que, en última instancia, la parte principal del análisis es si el
software puede resolver sus problemas.

Es realmente así de simple. Pero cuando se trata de los costos, hay campos de minas
notables. Algunas plataformas requieren una gran cantidad de consultoría para la
instalación. Estos costos pueden ser de dos a tres veces la cantidad para el programa
Para las grandes empresas, puede gastar fácilmente varios millones en consultoría.

Esto no quiere decir que el dinero se desperdicie. En determinadas circunstancias, puede


ser necesario hay que hacer mucha reingeniería. Y esto está bien. Pero la clave es que
los proveedores de servicios deben ser claro sobre qué esperar. En términos de los
costos del software, aquí hay algunas cosas en las que pensar:
 Escala: muchos proyectos de RPA aún no están generalizados en todas las
organizaciones. Pero ¿cuál será el costo ser si escalas la tecnología? ¿Será
suficiente el ROI? Para responder a estas preguntas, debe modelar el
escenario de una gran implementación (y asegurarse de que el cálculo
incluye los costos de consultoría y los requisitos de hardware y servidor,
que pueden escalar como las escalas del proyecto). Así, al evaluar todo esto,
notarás importantes discrepancias entre los proveedores. Sin embargo, esto
no significa que deba evitar el proveedor si los costos son altos. En su lugar,
podría usar esto como una oportunidad para negociar descuentos basados en
niveles de volumen y acuerdos plurianuales.
 Acceso RPA no humano: esto puede ser un problema, lo que conduce a
costos futuros más altos. "Algunos Los proveedores de RPA buscan crear
nuevas métricas de precios, como licencias no humanas acceso o cobro por
transacciones realizadas usando su sistema – para recuperar el potencial
pérdidas por disminuciones esperadas en el software basado en el usuario y
los ingresos por suscripción”, dijo Thomas Phelps.

113
El precio por bot también puede estar lejos de ser sencillo. El hecho es que los bots
entre las diferentes plataformas de software son diferentes, lo que hace que sea difícil
hacer realidad comparaciones Como resultado, debe hacer preguntas sobre los precios y
ver lo que está realmente pagando. En todo caso, esto podría conducir a una discusión
sobre precios más bajos, especialmente si usted menciona características de bots de
empresas rivales.

Pero algunos proveedores de RPA, especialmente aquellos que se enfocan más en el


proceso comercial mercado de gestión (PBM) – puede tener otros modelos de fijación
de precios. Uno sería para entradas como el número de empleados equivalentes a tiempo
completo (FTE) o el tiempo y los materiales. y si, hay el modelo de salida, que se basa
en el volumen de transacciones. Aunque, al final, el modelo de precios por bot es el
enfoque principal en el mundo de RPA.

Capacitación y Entrenamiento

Una buena manera de evaluar un sistema RPA es tomar algunos de los cursos. ¿Es fácil
el software? ¿usar? ¿Tiene las características que necesitas? Algunos proveedores de
RPA también tienen descargas gratuitas del software o ediciones comunitarias.
Definitivamente vale la pena mirar tales opciones. Luego verifique si hay un foro en
línea. ¿Qué son los comentarios? ¿Hay una comunidad próspera? ¿O hace tiempo que
nadie participa? ¿O hay muchas quejas sobre el software?

Soporte

Desea un proveedor de RPA que brinde soporte completo. Esto incluiría el autoservicio
opciones como videos, foros, cursos, libros blancos, documentación y blogs. ¿También
que es el nivel de soporte técnico? ¿Puedes llamar 24/7? Luego está el SLA o acuerdo
de nivel de servicio, que es un contrato que establece los niveles de servicios que
entregará el proveedor.

Lo mejor de su clase frente a extremo a extremo

114
El debate aparentemente interminable con el software comercial y empresarial es la
diferencia entre las mejores soluciones de su clase y de extremo a extremo. Cierto, lo
bueno de un extremo a extremo la solución es que suele haber menos formación y los
costes son menores. Pero, por supuesto, el gran el inconveniente es que algunas de las
características serán inferiores. Incluso la mejor tecnología del mundo las empresas
tienen grandes deficiencias en sus plataformas.

Es inevitable. Con RPA, no es realista tener una verdadera solución de extremo a


extremo. Este es definitivamente el caso para empresas globales, que tienen necesidades
extremadamente complejas. En realidad, no es raro que dichas empresas tengan varias
soluciones RPA. Sin embargo, como se señaló anteriormente en el capítulo, es una
buena idea mirar esas plataformas que tienen un rico ecosistema de socios que ofrecen
tecnologías complementarias dicen para OCR, ML y NLP.

Liderazgo de pensamiento y visión

Sí, esas cosas son nebulosas. Pero cuando se trata de software comercial, desea ver si la
visión está en línea con la tuya. Cuando lo es, los resultados pueden ser muy poderosos.

Para tener una idea de la visión, puede consultar la página de Twitter, el blog y canal de
YouTube (ver los videos de conferencias de la empresa puede ser particularmente útil).

Curiosamente, puede darse cuenta de que, con este proceso, ¡la visión de una empresa
es confuso! y en algunos casos, la visión de una empresa puede estar al borde de la
exageración. Es como si la tecnología también buena para ser verdad. Si un proveedor
de RPA afirma que su software puede hacer casi todo, por un precio bajo, y hay poco
esfuerzo - ¡entonces tenga cuidado!

Esta puede ser solo una forma de generar más relaciones públicas y ventas “RPA no es
una fórmula mágica para hacer todas las tareas de baja categoría que asume un
empleado”, dijo Arvind. Jagannath, director de gestión de productos en AI Foundry.
“Tomará algún retocando y ajustando en las primeras etapas antes de que los errores
comiencen a desaparecer. También requerirá una inversión de tiempo inicial para
familiarizarse con la herramienta”. (Taulli, 2020)

115
Experiencia en la industria

Aunque muchos proveedores de RPA afirman que sus plataformas son adecuadas para
muchas industrias, en la realidad suele ser algo muy diferente. En cambio,
probablemente haya concentraciones en ciertas verticales. Así que tienes que investigar
un poco sobre esto.

Seguridad, monitoreo e implementación

Como entraremos en más detalles en el Capítulo 8, existen varios riesgos potenciales de


seguridad con RPA software. Esta es otra razón por la que TI debe incorporarse al
proceso de RPA desde el principio. Al hacerlo, puede minimizar en gran medida los
problemas. Un sistema sólido de RPA también debe contar con un control sólido, ya
que los bots pueden ser frágiles. También quieren una forma de detectar los problemas.
Además, ¿cómo se implementará el software? ¿Requerirá una configuración en las
instalaciones? ¿O puede alojar el software desde la nube?

¿Qué tipo de RPA?

¿Los procesos que desea automatizar requieren intervención humana? O funcionan


¿entre bastidores? Tales preguntas son fundamentales al evaluar el software RPA. Por
ejemplo, sus necesidades pueden requerir solo un tipo de automatización, como
atendida o desatendida. Por supuesto, es posible que desee bots atendidos y
desatendidos (que, por cierto, es común). Por otra parte, la clave es que comprenda esto
al principio de la implementación de RPA proceso para que pueda hacer una mejor
elección en el software.

El Diseño

Una de las claves del gran éxito de Steve Jobs fue la obsesión por el diseño de
vanguardia. Él una vez dijo: “El diseño es una palabra graciosa. Algunas personas
piensan que el diseño significa cómo se ve por supuesto, si profundizas más, así es
como funciona.”

116
Es una distinción crucial, y algo en lo que pensar al seleccionar una solución RPA.
Seamos realistas, todos ellos presumirán que su diseño es intuitivo y fácil.

¡Casi mágico! Pero si lo prueba, a menudo tendrá una experiencia muy diferente. El
triste hecho es que mucho de software empresarial se queda muy corto cuando se trata
de diseño. Debido a esto, es necesario dedicar algo de tiempo a evaluar el flujo de
trabajo, la interfaz de usuario (interfaz de usuario) y UX (experiencia de usuario). ¿Es
algo que los trabajadores pueden aprender rápidamente? ¿Y el software requiere
habilidades técnicas, por ejemplo, algo de codificación?

Tecnologías de última generación

Una empresa de RPA no proporcionará una visión detallada de la hoja de ruta del
producto. Parte de esto es por razones de competencia. Pero una empresa tampoco
quiere comprometerse con duras plazos Si hay demoras continuas, los clientes
eventualmente dejarán de escuchar y podrían ir a otro lado A pesar de todo esto, todavía
hay ciertas áreas en las que una empresa de RPA debe centrarse. Quizás el más
importante sea AI o ML. Estas tecnologías son tremendamente prometedoras en
términos de impulsar el impacto de la automatización, como con el manejo de datos no
estructurados. “Los bots, tal como los conocemos hoy en día, son los más adecuados
para datos estructurados altamente repetibles”.

Dijo Bill Galusha, quien dirige la estrategia de productos para RPA e inteligencia de
contenido en ABBYY. “Pero más del 80 % del contenido empresarial no está
estructurado. Lo que requieren las empresas para sus proyectos de transformación
digital es tecnología de IA que complementa a los bots, haciéndolos más inteligente y
capaz de transformar documentos no estructurados en contenido estructurado. Este
elimina la fricción del proceso y accede a más valor del contenido empresarial.

Cualquier tipo de uso caso de contenido es un candidato principal y muchos de estos


procesos tienen cliente puntos de contacto, ya sea la incorporación de un cliente, la
presentación de un reclamo de seguro o la solicitud de un préstamo o línea de crédito. El
concepto de una 'habilidad' es algo que resuena con los negocios usuarios

117
Aquí es donde una empresa que utiliza una herramienta RPA u otra herramienta de
automatización podría fácilmente agregue una habilidad a un trabajador digital para
darle a ese bot una capacitación y comprensión más avanzadas para procesar el
contenido. Vemos que esto crece en popularidad a medida que los mercados se vuelven
más establecido y ofrecer cientos de estas habilidades potenciales que cada vez más
hacen que el digital bot más inteligente”.

Centro de Excelencia (CoE)

¿Qué es el CoE?

Según UiPath: “Un Centro de Excelencia (CoE) es esencialmente la forma de integrar


RPA profundamente y con eficacia en la organización, y para redistribuir el
conocimiento acumulado y recursos en implementaciones futuras. Esta es una buena
definición de alto nivel. Pero hay diferentes variaciones y enfoques para el CoE. Podría
ser un equipo pequeño, digamos, dos o tres personas, o mucho más grande. O podría
incluso ser un CoE para diferentes divisiones en una empresa o departamentos.
Independientemente de la estructura, el enfoque principal debe estar en la "E" de CoE.
en un blog de Automation Anywhere: “Todos los negocios requieren enfoque y
alineación para que RPA sea implementado con éxito.

Establecer un CoE proporcionará liderazgo, mejores prácticas, investigación y enfoque


en áreas para una mayor eficiencia comercial. Por supuesto, hay muchas razones para
implementar RPA, como cumplimiento, reducción de costos, niveles de servicio
mejorados, ingresos y reducción de errores. Es posible que tenga 200 ideas en proceso,
pero necesita un enfoque dedicado para implementar algunos de ellos con
automatización.”

De hecho, como indicación de la importancia del CoE, Automation Anywhere ha


creado su propio tablero para esto (es accesible desde una aplicación móvil). Con él,
puedes ver fácilmente el ROI, el ahorro de tiempo y otras métricas clave del sistema
RPA. Finalmente, un CoE puede ser ejecutado completamente por la empresa que está
implementando el RPA sistema. O, en algunos casos, podría subcontratarse a una firma

118
consultora (sin embargo, habrá probablemente sean miembros de la empresa cliente en
el CoE).

¿Por qué tener un CoE?

Realmente hay pocos inconvenientes al crear un CoE. Quizá la más razonable sea que,
si está probando principalmente la tecnología RPA, probablemente no sea necesario
obtener formal. Sin embargo, si está comprometido a hacer que la tecnología funcione a
largo plazo, entonces una CoE debe ser parte del proceso. Es una clara señal de que su
organización se toma en serio RPA. El CoE demuestra que está dispuesto a realizar las
inversiones de tiempo y dinero. Y sí, los empleados se darán cuenta, lo que ayudará con
la capacitación y la adopción. Este es destaca aún más si algunos o todos los miembros
del CoE son de tiempo completo. Pero definitivamente hay otras ventajas en las que
pensar, incluidas las siguientes:
 Un CoE proporciona una forma de obtener una vista de 360 grados del proyecto
RPA. Esto hace que sea más fácil obtenga el valor completo de la tecnología, ya
que no habrá problemas con los silos y múltiples sistemas RPA. También
debería haber una implementación más rápida, una mejor creación de bots y un
seguimiento más diligente.
 Si el CoE es autogestionado, entonces podría haber costos más bajos. Pero, por
supuesto, habrá mucho más control sobre el proyecto RPA, ya que su
organización estará en una mejor posición para experimentar e innovar.
 Las primeras fases de RPA tienden a ser exitosas. Sin embargo, el problema real
es cuando la tecnología es escalable. Pero con un CoE, tienes una mejor
oportunidad con esto porque hay se concentrará el esfuerzo en el sistema RPA.
 El CoE permite la aceptación. Esto significa obtener la participación de la alta
dirección (por ejemplo, el ejemplo de Adobe, hubo colaboración entre el CIO y
el CFO). pero debería también involucrarse con aquellos en primera línea que
usan la tecnología.

“La implementación de un Centro de Excelencia (CoE) para la automatización es


crucial para mantener la RPA éxito”, dijo Agustín Huerta, VP de Tecnología, IA y
Automatización de Procesos Estudios en Globant. “Un CoE adecuado es necesario para
servir como guardián de la tecnología estándares e imponer una metodología única para

119
abordar la automatización, a fin de garantizar que la tecnología puede funcionar de
manera más efectiva en toda la organización una vez implementada. El CoE también
debe actuar como guardián de los procesos que se automatizarán, a fin de asegurarse de
que tengan un ROI adecuado, junto con la gobernanza de la nueva fuerza laboral
digital."

Formando el equipo

Cuando se trata de formar el CoE, por lo general es de cuatro a seis meses después del
inicio del proyecto. Esto tiene sentido porque el tiempo permite aprendizajes, como
experimentar con prueba de conceptos. Pero durante este período, es una buena idea
pensar en el CoE, como como identificando a los miembros potenciales y considerando
las metas. Esto sin duda permitirá para una transición mucho más suave.

Entonces, ¿cuáles son los diferentes roles para un CoE? Bueno, en general, usted quiere
obtener una amplia representación de la organización afectada por la implementación de
RPA. “A menudo, la firma se asociará con expertos para apoyar a parte del equipo que
entiende cómo funciona RPA”, dijo Pat Geary, quien es el principal evangelista de Blue
Prism. "El tema de expertos en la materia (PYMES) trabajan junto con aquellos que
entienden la automatización y el proceso roles de gestión para ayudarlos a unirse y
priorizar la automatización más efectiva estrategias. El equipo de tecnología también
debe ser parte del CoE desde el principio. Mientras el trabajo basado en procesos puede
no ser una segunda naturaleza para el equipo de TI, la tecnología para respaldar la
automatización ciertamente lo es. Al involucrar a los equipos de TI desde el principio,
pueden obtener una mejor comprensión de la plataforma y puede proporcionar
orientación adicional al configurar trabajadores digitales, siguientes requisitos únicos de
seguridad, cumplimiento y auditoría.

A medida que los equipos de TI se vuelven más familiarizados con la plataforma, a


menudo adoptan trabajadores digitales para apoyar a sus propios procesos. Este trabajo
en equipo permite que una fuerza de trabajo digital se integre más fácilmente en un
tejido central de la organización. (Taulli, 2020)

120
En un nivel más granular, puede observar el propio enfoque de UiPath para configurar
un CoE. En realidad, es bastante extenso, ¡involucra una larga lista de roles! Sin
embargo, al iniciar un Proyecto RPA, se recomienda comenzar poco a poco y construir
con el tiempo.

A pesar de esto, todavía es bueno ver los roles potenciales de UiPath


(independientemente de si son parte del CoE o no). En este modelo, hay uno que ya
hemos mencionado en este capítulo: El patrocinador RPA. Sí, esta es alguien del lado
comercial de la organización, como un ejecutivo.

A continuación, aquí están algunos de los otros:

 RPA Champion: Este es el evangelista. Es decir, él o ella será la persona que


levante entusiasmo por el proyecto RPA, por ejemplo, mediante la creación de
videos, talleres y blogs publicaciones.
 Administrador de cambios de RPA: esta persona es similar a un campeón. En
otras palabras, él o ella busque formas de obtener la aceptación del proyecto
RPA. Una gran parte de esto es a través de la creación de un plan de
comunicación
 RPA Servicio de Soporte: esta persona será la primera línea de asistencia para el
proyecto RPA.
 Ingeniero de infraestructura RPA: esta persona ayuda con la instalación del
servidor y vigilancia. Él o ella también puede ayudar con la arquitectura de la
implementación de RPA. El puesto requiere habilidades técnicas profundas,
como protocolos de red y administración, seguridad, sistemas en la nube,
diseños de servidores, tecnología de bases de datos y virtualización (por
ejemplo, con VMWare, Citrix o Hyper-V).

Si bien todos estos son importantes, lo notará, al menos cuando revise los trabajos en
línea. Publicaciones: que las funciones principales incluyen las del analista comercial,
desarrollador, arquitecto de soluciones y supervisor de RPA. (Taulli, 2020)

Despliegue y Monitoreo

121
Pruebas

En 2002, el estado de Washington cambió su sentencia de prisión para permitir créditos


por buen comportamiento. Esto se implementó en un sistema de software que determinó
la fecha del lanzamiento. Suena como una buena idea, ¿verdad? Esto es verdad. Pero el
software tenía un error. ¡En promedio, permitió la liberación de presos 49 días antes! En
algunos casos, fue más de 600 días. No fue hasta 2015 que una persona de TI se dio
cuenta del error y lo corrigió.

Aún más de 3.200 presos habían sido liberados antes de lo requerido por la ley. Esté
ejemplo ciertamente destaca la importancia crítica de las pruebas de software. Cierto,
puede ser un proceso tedioso y aburrido, pero es absolutamente crítico. Lo mismo
ocurre con el bot desarrollo, que puede implicar algunos temas espinosos. Incluso un
ligero cambio en un subyacente el proceso puede hacer que un bot se vuelva loco.

Ahora la tentación es que los desarrolladores o los técnicos se encarguen de las pruebas.
Pero esto es un error. Quiere a alguien que tenga experiencia en aseguramiento de la
calidad para software y tiene experiencia con herramientas de automatización de
pruebas (como Selenium, Eggplant, WebTest, Mercury QTP o Watir).
Cuando se trata de pruebas, existen varios enfoques, que incluyen lo siguiente:
 Prueba de caja negra: aquí es donde la estructura interna y el diseño del bot no
son conocido por el probador. Esto implica configurar ciertas entradas y casos
de prueba, y luego para ver si los resultados son correctos.
 Prueba de caja blanca: esto implica probar la estructura interna y el diseño del
bot. En otras palabras, el evaluador analizará el código fuente e intentará
detectar cualquier problema, por ejemplo, riesgos de seguridad, procesos
deficientes o caminos complicados.
 Pruebas de caja gris: aquí tiene una combinación de los enfoques de prueba de
caja blanca y negra. Cuando se trata de probar bots, generalmente existen
técnicas manuales y automatizadas. Con el primero, hará que un probador
pruebe muchas opciones diferentes y las registre (esto a menudo requiere mirar
los archivos de registro, las entradas de la base de datos, etc.). Esto puede llevar
mucho tiempo, pero sigue siendo útil. Existe el beneficio de la creatividad y la

122
imaginación. En cuanto a las pruebas automatizadas, configurará scripts que
tienen diferentes valores y luego ejecutará ellos en el software. Esto es
ciertamente más rápido y puede probar muchas posibilidades. Pero las pruebas
automatizadas ciertamente están limitadas.

A la luz de todo esto, suele haber una combinación de pruebas manuales y


automatizadas.

También se recomienda que haya una revisión detallada de los procesos subyacentes
que el sistema RPA se está automatizando. De lo contrario, es probable que un probador
pase por alto muchos problemas.

Entonces él o ella deben revisar la documentación como el Documento de Definición de


Proceso (PDD) o el documento de diseño de solución (SDD). ¿Y si estos materiales no
son especialmente claros? Bien, entonces es crítico renovarlos.

Finalmente, debe haber un análisis de los datos para los scripts de prueba (la
información es generalmente en una hoja de cálculo de Excel). ¿Es completo? ¿Refleja
los casos de uso reales? Tenga en cuenta que para los sistemas RPA, tendrá
herramientas de depuración para ayudar con las pruebas. Y En algunos casos, hay
desarrolladores externos que han creado sistemas de automatización de pruebas.

Pases a Producción

Una vez que se completa la prueba, llega el momento de la implementación o la


producción. Un buen enfoque es comenzar con un caso de uso limitado. Esto podría, por
ejemplo, significar simplemente tener el bot en un escritorio. Después de una
evaluación, puede dar una distribución más amplia dentro del Departamento. Luego,
con el tiempo, podría considerarse la posibilidad de abarcar toda la empresa, según del
tipo de automatización involucrada. “Durante la implementación, es importante crear un
mapa de proceso completo y llamar determinar las tareas específicas que se van a
automatizar”, dijo Asheesh Mehra, cofundador y director ejecutivo de AntWorks.

123
“Aquellos que implementen la solución definirán los roles de los bots en el proceso.
También deben mantener la confidencialidad de los miembros del equipo afectados,
iterar el proceso para verificar la infraestructura y el software, y desarrollar un plan
alternativo”. El plan alternativo es particularmente importante. Seamos realistas, es
probable que sea necesario ajuste del Bot. También es recomendable centralizar el
proceso de implementación, por ejemplo, a través del CoE.

Monitoreo

Una vez que un bot se activa, debe monitorearlo. La buena noticia es que la
orquestación de un RPA el sistema generalmente tendrá paneles útiles para esto. Sin
embargo, es posible que desee configurar sus propias métricas únicas y KPI a seguir.

“El monitoreo de la implementación de una RPA debe incluir la medición contra el


éxito criterios”, dijo Mehra. “Desea saber si su implementación cumplió con esos
criterios o se quedó corto. También es importante configurar los bots para manejar
cambios y monitorear el impacto de eso. Considerar eficiencias más amplias y
requisitos de cumplimiento también deben sea parte de su esfuerzo de monitoreo.

Idealmente, querrá medir para ver si el empleado la eficiencia ha aumentado y


definitivamente necesitará analizar los requisitos de cumplimiento del robot.” También
considere armar un plan de continuidad del negocio. Este es un documento que
establece adelante los tipos de monitoreo, las metas a lograr y las acciones a tomar
cuando algo va mal.

Y sí, esto es algo que el Consejo de Europa puede redactar y hacer cumplir. También
debe haber reuniones periódicas para evaluar el desempeño de los bots. ¿Son
seguimiento de cosas? ¿Debería haber cambios? ¿Debería incluso terminarse un bot?
Además, si desea utilizar análisis más sofisticados, puede hacerlo analizando los
archivos de registro. Se pueden almacenar en una plataforma como Elasticsearch y
puedes crear visualizaciones para análisis de ubicación con una herramienta como
Kibana. También hay un módulo para aprendizaje automático (ML). (Taulli, 2020)

Seguridad

124
La ciberseguridad se está convirtiendo en un riesgo notable con RPA. Después de todo,
algunas implementaciones son hecho rápidamente, sin mucha colaboración con TI. La
atención se centra a menudo en llegar a eficiencias lo más rápido posible. Como
resultado, el departamento de TI puede ser visto como un punto de fricción innecesario.

Pero esto puede ser un gran error. RPA es en realidad bastante vulnerable a un
ciberataque. Él La razón principal es que un bot puede tener acceso a aplicaciones,
bases de datos y la red. A menudo estos pueden abarcar geografías y departamentos. De
hecho, los privilegios de acceso pueden ser mucho más potente que lo que tiene un
usuario típico.

Recursos humanos también debe participar en el proceso. Esto ayudará a lidiar con la
gestión de los identificadores de la empresa para acceder a los sistemas. Seamos
realistas, no quieres que haya ¡acceso inesperado a procesos en áreas como nómina,
seguro médico, etc.! “El software RPA interactúa directamente con los sistemas y
aplicaciones comerciales críticos, lo que pueden presentar riesgos significativos cuando
los bots automatizan y realizan tareas rutinarias”, dijo Kevin Ross, Sr., que es ingeniero
de sistemas en CyberArk.

“Los bots no necesitan derechos administrativos para realizar sus tareas, pero necesitan
acceso privilegiado para iniciar sesión en ERP, CRM y otros sistemas comerciales
empresariales para acceder a datos, copiar o pegar información o mover datos a través
de un proceso de un paso al siguiente. El acceso privilegiado sin seguridad es una receta
por desastre.

A medida que aumenta la demanda de RPA entre las líneas de negocio, el número de
privilegiados crecen las credenciales de cuenta codificadas en scripts o conservadas de
forma segura. que significativamente aumenta los riesgos asociados. Con estos
enfoques, las credenciales terminaron siendo compartidas y reutilizado repetidamente.

A diferencia de las credenciales utilizadas por los humanos, que normalmente deben ser
cambiar periódicamente, los que usan los bots permanecerán sin cambios y sin
administrar. Debido a esto, están en riesgo de los ciberdelincuentes y otros malos

125
actores que pueden leer o buscar scripts para obtener acceso a las credenciales
codificadas. También corren el riesgo de los usuarios que tener privilegios de
administrador, que puede recuperar las credenciales guardadas en permanencia no
seguras.

Entonces, si un pirata informático obtiene acceso a un bot, él o ella podrían tener acceso
a datos altamente confidenciales o participar en actividades maliciosas como un ataque
de denegación de servicio. Esto puede resultar en una empresa no poder procesar
facturas o cuentas por pagar, por ejemplo.

Dado todo esto, es imperativo que TI se involucre en las primeras etapas de la


planificación del esfuerzo de RPA. También hay algunas mejores prácticas a considerar,
como las siguientes:
 Protección de credenciales: asegúrese de almacenarlas y administrarlas de
forma segura.
 Acceso a la aplicación: tenga en cuenta lo que está haciendo el bot.
 Gobernanza: esbozar un marco para la seguridad, que debe cubrir el diseño
de la bots y el uso de datos. También debe haber una definición clara de los
roles y responsabilidades.
 Seguimiento de auditoría: desea una plataforma RPA que proporcione esto,
como con la creación de registros esto significa que tendrá una forma de
realizar investigaciones y evaluaciones.
 Seguridad RPA: observe aquellos sistemas de software RPA que tienen
altos niveles de seguridad. Para ejemplo, ¿hay un tercero que confirme que
ha cumplido con ciertos requisitos? Además, no es una buena idea utilizar
una versión gratuita de un sistema RPA en producción. En la mayoría de los
casos, la seguridad no será fuerte.
 Rotación: una forma de ayudar a proteger las credenciales es cambiar los
privilegios de acceso continuamente. Por lo tanto, si un hacker obtiene
acceso, la utilidad no durará mucho.

A pesar de los riesgos de las plataformas RPA, irónicamente, ¡la tecnología puede
ayudar a promover seguridad también! Ya aprendimos sobre esto en el Capítulo 1,
donde uno de los beneficios de la tecnología es que las tareas pueden no tener

126
intervención humana, lo que minimiza el fraude (claro, esto es siempre y cuando haya
seguridad con las credenciales).

Pero RPA también puede ser eficaz en ser ágil en la toma de acciones proactivas. Es
decir, la tecnología se puede configurar para Instale instantáneamente parches de
seguridad.

Cuando se trata de seguridad, definitivamente hay muchos enfoques y estrategias. Con


una empresa de servicios financieros, como Voya, los requisitos son bastante estrictos
(y para siempre razón, ya que la confianza del cliente es absolutamente esencial para la
empresa).

“Aplicamos lo mismo mecanismos de seguridad para RPA que usamos para cualquier
aplicación o sistema empresarial”, dijo Jeff Machols, vicepresidente del Centro de
mejora continua de Voya Financial.

"Nosotros tener revisiones de pares de código y cambio de control. También tenemos


separación de capacidades con los bots Hacemos esto, aunque signifique tener que
comprar más licencias. Además, Voya no tienen desarrolladores ciudadanos que
esencialmente pueden construir lo que quieran.

Queremos mantener el control y asegurarse de que se cumpla con la gobernanza”.


Independientemente de los requisitos generales y la demanda reglamentaria, es
importante mantener la seguridad como prioridad con RPA. (Taulli, 2020)

Escalamiento

El escalado es el santo grial de RPA. Es cuando la automatización se ha vuelto


realmente transformadora. Pero Como hemos aprendido al comienzo de este capítulo, la
escala ha demostrado ser increíblemente difícil. ¿Por qué? Bueno, hay una gran cantidad
de factores, como los siguientes:
 Planificación: Esto es absolutamente necesario para escalar RPA. Tienes que
tener detallado objetivos y documentación (en realidad, es importante enfatizar
esto en cada paso en el proceso). Si no, generalmente habrá caos y confusión

127
cuando hay muchos bots. dentro de una organización. Una forma común de
lidiar con esto es contratar consultores e incluso utilizar software de minería de
procesos. En algunos casos, el software RPA tendrá su propio proceso
aplicaciones de descubrimiento.
 ROI: si hay demasiado enfoque en esto, entonces puede ser difícil escalar RPA.
La razón por ¿este? Pongamos un ejemplo: supongamos que una empresa solo
asume la automatización de esos procesos donde el ROI es del 100% en un
período de dos años. Esto puede sonar intuitivamente como un buen enfoque,
Pero hay un problema persistente: ¿Qué pasa si solo hay unos pocos procesos
que cumplen con este criterio e impactan a una pequeña parte de la
organización? En este caso, cuando mirando una visión holística de las cosas,
realmente habrá poco impacto del esfuerzo de RPA. Más bien, si el ROI
promedio es, digamos, 20%, pero abarca muchas partes de una empresa,
entonces podría haber un gran impacto en la productividad y la eficiencia. Esto
se conoce como el “efecto cartera”. Pero para que funcione, debe haber un fuerte
énfasis en el cambio.
 CoE: Esto es absolutamente esencial para escalar. Tiene que haber algo de
disciplina, gobernanza y centralización de la implementación y monitoreo de
RPA. El CdE también debe redactar los SOP (procedimientos operativos
estándar) y recopilar cualquiera de los aprendizajes y mejores prácticas.
También debe haber capacitación y educación continuas.
 TI: Es común no involucrar a TI en las primeras fases. Y esto es comprensible
como RPA La tecnología es relativamente fácil de usar. Además, TI puede
generar fricciones en el proceso. Pero si desea escalar el sistema, debe involucrar
a este grupo. Ellos pueden ser fundamental para ayudar a construir la base
tecnológica adecuada, como con el nube o enfoques sofisticados como
Kubernetes, así como ayudar al desarrollo técnicas, tratando con actualizaciones
y parches (que, por cierto, es bastante común con RPA), integración y gestión de
credenciales.

Finalmente, a medida que escala el sistema RPA, habrá desafíos para las
organizaciones globales. Será necesario prestar atención a las normas culturales
únicas de cada país, así como a cumplimiento y requisitos reglamentarios,
preparación/confiabilidad de la infraestructura, privacidad, datos políticos de

128
retención, reglas de trabajo, etc. Este proceso llevará tiempo, pero permitirá una
amplia adopción: proporcionando el máximo impacto de la tecnología RPA.
(Taulli, 2020)

Productividad

En el estudio de la productividad, es necesario resaltar que la eficiencia con la que


se realizan las actividades productivas influye en los costos de producción. Por
tanto, se considera que la calidad con la que se elaboran los productos, reduce los
costos ya que hay menos reproceso, menos equivocaciones, menos retrasos; se
utiliza mejor el tiempo, maquinaria y los materiales.

Por consiguiente, mejora la productividad, lo que permite que se conquiste el


mercado con la mejora de calidad y el precio más bajo. Esto facilita que se
mantenga en el mercado y que se generen más fuentes de trabajo. (Deming, 1989)

Por otro lado, se destaca la importancia de que las organizaciones incrementen la


productividad para sobrevivir en las cambiantes condiciones, estableciendo que el
mejor camino para alcanzar la productividad es el logro de la calidad total, según el
presidente del Centro Americano de Productividad y Calidad Doctor Jackson
Grayson (1990), quien intervino en el Congreso Internacional de Calidad Total.

También se debe recordar cómo se entiende a la productividad, en la que se


destacan ciertos indicadores tradicionales que afecta la producción manufacturera
como: productos relacionados por horas trabajadas, horas máquina, capital
invertido entre otros, han reforzado la idea de “hacer más con menos”.

En su elaboración más reciente se define a la productividad como: “una medida de


la eficiencia económica que resulta de la capacidad para utilizar y combinar
inteligentemente los recursos disponibles”. (Combeller, 1993)

Medición de la productividad

129
La productividad en la empresa se puede evaluar mediante indicadores, que se
ajusten de acuerdo a las condiciones específicas de las mismas. Estos difieren entre
los autores, sin embargo se pueden mencionar los siguientes:

Indicadores de productividad

Sirven para cuantificar y medir la gestión realizada por la empresa. Permite saber si
las labores realizadas se ejecutan según lo planificado. Por esta razón a
continuación se mencionan los indicadores que pueden facilitar y medir cómo el
aumento de las unidades de producción influye en la competitividad de las
empresas, es decir se refleja la eficiencia con la que se manejan los recurso que se
encuentran disponibles.

Se puede calcular la productividad mediante la siguiente ecuación más


generalizada:

La productividad es el resultado que se obtiene de la relación de productos totales


obtenidos y la totalidad de los insumos utilizados.

PRODUCTIVIDAD = PRODUCTOS OBTENIDOS


INSUMOS UTILIZADOS

Así, se puede mencionar que la eficiencia está determinada por el empleo adecuado
de los recursos que permiten el logro de los resultados, y la eficiencia se mide por
los resultados alcanzados, ya que no se considera los recursos ni los medios con que
se logran. Por tanto, la efectividad es la habilidad gerencial de lograr la eficiencia y
la eficacia en relación a los recursos y objetivos dados.

Se establece una ecuación para el cálculo de la eficiencia, la misma que se la puede


obtener de la relación de la producción real obtenida y la producción estándar
esperada.

EFICIENCIA = PRODUCCIÓN OBTENIDA


PRODUCCIÓN ESTÁNDAR ESTIMADA

130
La eficacia de las operaciones productivas se la obtiene mediante la relación de los
recursos estimados y los recursos utilizados.

EFICACIA = RECURSOS ESTIMADOS


RECURSOS UTILIZADOS

La efectividad se obtiene mediante la relación que se da entre la producción real


obtenida y la producción óptima estimada. (Trabajo, 2015)

EFECTIVIDAD = PRODUCTIVIDAD OBTENIDA


PRODUCTIVIDAD ÓPTIMA

Planificación de las operaciones productivas

La planificación, control y estrategias adecuadamente establecidas permiten que una


empresa mejore continuamente y se mantenga de forma activa en el mercado ofertando
productos que satisfagan las necesidades de sus consumidores.

En el proceso productivo, la planificación y el control con el que se pueda manejar las


medianas empresa, permite reducir la inseguridad y mejorar las actividades. El manejo
adecuado de la planificación y el control de las actividades productivas manufactureras
mejora la competitividad de las medianas empresas.

Cuando una empresa no tiene una planificación, se considera que no dispone de las
bases sobre las cuales ha de asentar las acciones que puede tomar frente a un suceso y
no tiene referencia que le permita comparar al final de un período, lo que la empresa ha
logrado alcanzar con relación a lo que la empresa ha planificado. Por otro lado, el
seguimiento que se hace de las operaciones de producción suministra la información
necesaria para el control de la producción y poder efectuar las respectivas medidas
correctivas. (Gonzalez Riesco, 2006)

Planificación

131
Es indispensable establecer la planificación, siendo parte del proceso administrativo ya
que le permite a la empresa tener claro el panorama al cual debe hacer frente y cómo
debe hacerlo.

La planificación de la producción se la debe considerar como parte de un sistema


integral, enfatizándose los distintos subsistemas de gestión de recursos de una empresa
para determinar los posibles niveles de actividad que se deben realizar, optimizando el
empleo de los recursos materiales, financieros y humanos, todo sobre la base del óptimo
aprovechamiento de la capacidad instalada de la industria. (Hernandez Rodriguez, 2011)

En un proceso de planificación se deben observar ciertos principios (características),


pasos, etapas; que facilitan su presentación. Estos difieren de un autor a otro, sin
embargo se citan los que se estiman más frecuentes y que se deben observar tales como:

Principios para la planificación


 Precisión
Planteados de la manera clara ya que van a regir acciones concretas.
 Flexibilidad
Debe haber la posibilidad de realizar modificaciones o cambios.
 Unidad de Dirección
Se elaboran uno por cada función, y todos deben estar integrados de tal manera
que pueda considerarse como un solo plan general.
 Consistencia
Están integrados para lograr una coordinación entre los recursos, funciones y
actividades con el propósito de alcanzar con eficiencia los objetivos.
 Rentabilidad
Expresar que los resultados deben ser superiores a los recursos utilizados.
 Participación
Los involucrados deben sentirse comprometidos y deben participar en su
estructura.

Estrategias en la producción

132
Acciones que son necesarias en todos los niveles de las organizaciones. Pese a que estas
pueden funcionar en una empresa, es posible que por las características y a pesar de ser
homogéneas, no funciona en la siguiente ocasión que se las aplica. Sin embargo, se
puede decir que constituyen un plan que incluye las principales metas y políticas
formuladas para poner orden y asignar recursos con el fin de lograr una situación viable
y original, la aplicación de las estrategias adecuadas que son las guías, en los procesos
de la organización; garantizan con mayor fiabilidad alcanzar los objetivos planteados.
(Mintzber, 1997)

Al momento de plantearse cómo puede la empresa maximizar sus ingresos, se busca


ciertos componentes que apoyen en este proceso. Por ello, deben identificarse factores
que logren mejorar las estrategias para que la empresa prospere. Estos pueden
focalizarse en:
1. La competencia
2. El cliente
3. La gestión
4. Los costos
5. La tecnología

La competencia, considerada como una de las fuerzas que impulsa a la empresa a


innovar y desarrollarse, añadiendo valor al producto. La satisfacción del cliente conduce
a la empresa a examinar las necesidades del cliente con el enfoque de satisfacerlas, ya
que esto las direcciona ser las primeras del sector.

El sistema de gestión apropiado mejora los procedimientos de elaboración de productos


o servicios para alcanzar fundamentalmente la calidad.

La optimización de los costos es una estrategia orientada a largo plazo para mejorar la
competitividad basada en valores monetarios.

El uso de las tecnologías es la opción más viable para mejorar la productividad con
menores recursos.

133
Las estrategias que dan resultado en unas empresas puede que no sean tan viables en
otra; cada una de acuerdo a la experiencia puede aplicar las que se ajusten a su realidad,
considerando que las soluciones de otras no siempre son soluciones propias.

Control de la producción

Según el diccionario de la lengua castellana, el control es un examen u observación


cuidadosa que sirve para hacer una comprobación.

Así, el control de la producción ayuda a conocer la cantidad, la calidad y sobre todo los
costos que son utilizados de manera eficiente en las operaciones productivas. Por lo que
un sistema de control de las operaciones productivas se concentra en la obtención de la
producción deseada dentro de los límites de las fechas de entrega comprometidas con el
cliente. (D´Alesio Ipinza, 2012)

El control es una actividad que va a la par de la planificación, por lo tanto indispensable


en los procesos productivos. El control se aplica en todas las actividades que realiza el
ser humano; permite verificar el cumplimiento y la observación de las políticas vigentes
establecidas por la empresa.

En el proceso productivo, el control debe realizarse en todos los niveles y áreas de la


producción con el propósito de validar el cumplimiento de lo establecido por la
organización. Se puede realizar de forma cualitativa como cuantitativa.

El control oportuno de las actividades permite monitorear el cumplimiento de los


objetivos planteados mediante un seguimiento adecuado de las operaciones productivas
con el propósito de evitar desviaciones que pudieran darse por el propio proceso y que
afecten a los resultados esperados.

Control de la calidad

Proceso continuo que se realiza con propósito de conocer en todo momento si el


producto cumple con los estándares requeridos.

134
Control de la cantidad

Consiste en evaluar las variaciones que se pueden dar entre los volúmenes obtenidos
con relación a los volúmenes planificados.

Control de uso de tiempo

Permite el manejo de los productos en un rango de tiempo especificado garantizando su


distribución oportuna.

Control de costos

Se confirma que los costos por insumo cumplan la planificación establecida.

Control de inventarios

Verifica las existencias, en el momento y en el lugar correspondiente, para cumplir con


los pedidos de los clientes en forma oportuna

Por otro lado, los controles deben manejarse observando el control de las cantidades
operativas como: producción única, producción intermitente y producción continua.

Producción única

Se considera al producto final, con un bajo volumen de producción, períodos largos de


producción que involucra altos costos unitarios, inventarios altos por cada período de
producción.

Producción intermitente

Producto terminado medianamente estandarizado, requiere controles periódicos y


volúmenes de producción medios, costos unitarios promedio. Involucra períodos
promedios de producción y altos niveles de inventarios durante el proceso.

135
Producción continua

Producto final estandarizado, con una rutina estándar de producción, bajo costos
unitarios, altos volúmenes de producción, y períodos largos de producción, niveles de
inventarios bajos durante el proceso. (D´Alesio Ipinza, 2012)

136
2.4. Definición de términos básicos

Bot

Bot es la palabra robot recortada. Se refiere a un tipo de programa informático


autónomo que intenta llevar a cabo tareas concretas e imitar el comportamiento
humano.
 Los bots pueden estar diseñados en cualquier lenguaje de programación.
 "Robótica" es un término de la industria utilizado para describir la
digitalización de los procesos de negocios.
 En contraste con las máquinas de la revolución industrial, los 'robots' (con
respecto a la automatización de procesos), no son más que herramientas de
software que pueden automatizar un rango de actividad digital. (Isaca, 2018)

RPA

Robotic Process Automation (RPA) es el uso de herramientas de software que


funcionan como una fuerza laboral virtual. RPA puede ejecutar tareas
predeterminadas basadas en reglas, imitando la interacción humana con
aplicaciones existentes para automatizar procesos completos o actividades
específicas. Las cuales sus capacidades de RPA son las siguientes:
 Entrada automatizada de datos.
 Transferencia de datos.
 Procesamiento basado en reglas.
 Proceso de reconciliación.
 Recopilación de datos.
 Validación / calidad de datos. (Isaca, 2018)

Recopilación de Datos

La columna vertebral de la recopilación de datos para el caso de prueba consistirá


en escribir notas a medida que avance el proyecto. Detallan este método, donde el
investigador debe tomar notas de campo durante los eventos en sí, y después de

137
cada sesión deben escribir notas, esencialmente registrando el tren de pensamiento
para su posterior análisis. Esto obliga al investigador a trabajar con conceptos y
refinar el pensamiento a lo largo del proyecto. Además, esto permite una grabación
periódica del trabajo, lo que es beneficioso especialmente en un proyecto más
largo.

Los memos son una herramienta flexible: pueden tratarse tanto de la recopilación
de datos como del análisis de datos. El propósito de los datos es dar una idea de
cómo progresó realmente la implementación de RPA, y los memorandos pueden
hacer exactamente esto. (Corbin, 2008)

SDK (kits de desarrollo de software)

Estos son nuevamente diferentes al ofrecer desarrollo de TI combina la capacidad


de construir un robot de acuerdo con su propio diseño. Estos productos ofrecen la
oportunidad de desarrollar un robot localizado, asistido por agente que se centre en
guiones individuales y ofreciendo soporte de transacciones localizadas.

Los SDK utilizan un modelo de seguridad de escritorio y dependen de Roles locales


y permisos de usuario. Deben ser construidos por equipos de desarrollo
experimentados consciente de los requisitos previos en términos de metodología,
mejores prácticas y cultura componentes de un robot de servicio completo.

Los SDK están diseñados para construir robots individuales, no robots equipos o
"fuerzas de trabajo virtuales" como algunos los llaman. Por lo tanto, los SDK no
ofrecen el diseño oportunidad de sincronización, multipropósito, equilibrio de
carga, configuración múltiple, auditoría y funciones de información de gestión
necesarias para ejecutar, y disponibles a través de equipos de robots. (Willcocks,
Lacity y Craig, 2016)

El software RPA no es invasivo

138
La segunda característica distintiva es que la tecnología RPA se asienta sobre los
sistemas existentes, sin la necesidad de crear, reemplazar o desarrollar más
plataformas caras.

El software RPA accede a otros sistemas informáticos de la misma manera que un


humano sí: a través de la interfaz de usuario con un ID de inicio de sesión y
contraseña. Acceso a software RPA otros sistemas a través de la capa de
presentación, por lo que no hay lógica de programación de sistemas subyacente es
tocado.

Además, los productos RPA no almacenan ningún dato. Esto distingue RPA de
Soluciones BPM porque las soluciones BPM son invasivas, crean nuevas
aplicaciones y acceden lógica empresarial y capas de acceso a datos en la pila de
arquitectura de TI. (Willcocks, Lacity y Craig, 2016)

Productividad

La productividad manufacturera influye en el mercado y las empresas que son


eficientes en la fabricación de los productos mejoran la competitividad con relación
al sector al que pertenecen. La productividad manufacturera y competitividad no
son aspectos separados, no obstante, son complementarios y se debe tomar en
cuenta el conjunto; por lo que se revisan autores que se enfocan en esos factores
que orientan y apoyan al empresario en el camino para mejorar.

La productividad manufacturera es un objetivo estratégico de las empresas, debido


a que sin ella los productos o servicios no alcanzan los niveles de competitividad
necesarios en el mundo globalizado, por lo que la eficiencia y eficacia con la que se
realizan los productos son necesarias en las actividades empresariales, y se debe
manejar positivamente los procesos que apoyan en la generación de valor agregado
a los productos. (Soto, 2009)

Factores que afectan la Productividad

139
Hay aspectos que se debe considerar al momento de analizar la productividad de
una empresa en el área de producción, ya que estos factores afectan positiva o
negativamente, por un lado, los clásicos como capital, tierra y trabajo; por otro
lado, se citan los siguientes:
- La innovación:

Es considera la parte más importante en el desarrollo empresarial. Es el


esfuerzo que la empresa está dispuesta a realizar y las condiciones que
presenta para invertir. Este esfuerzo, direccionado a mejorar los procesos
productivos, los productos, la maquinaria necesaria entre otros; según en su
libro La ventaja competitiva de las naciones, menciona que la
competitividad de una nación, y por tanto su tejido industrial y económico,
dependen de su capacidad para innovar, enfatizando que la única ventaja
competitiva sostenible es la innovación continua. (Bermejo, 2014)

- Capacitación Laboral:

La capacitación del personal es una actividad permanente. El objetivo es


prepararlo para que aplique adecuadamente los procesos de producción,
obteniendo un mejor producto y que se mantenga la calidad en el mismo.

El propósito de la capacitación es el perfeccionamiento técnico del personal


para que se desempeñe de manera eficiente en las áreas y actividades
asignadas, logrando obtener resultados de calidad, excelente servicio y
desempeño, con un perfil ajustado a las necesidades del entorno. (Cejas
Martinez, 2012)

- Investigación y Desarrollo:

Alcanzan un mejor nivel de competitividad las empresas cuando tienen la


posibilidad de invertir fuertes cantidades de dinero en investigación y
desarrollo. Esto las coloca en la vanguardia de su sector posicionándolas
mejor en los mercados locales e internacionales.

140
En lo que se hace referencia a que las medianas empresas se encuentran
limitadas, ya que por su posición no disponen de fondos ni son sujetas a los
créditos que les permitirían incurrir en estas actividades. (Cejas Martinez,
2012)

Productividad Laboral

La Organización Internacional de Trabajo en su informe de los indicadores clave


sobre el mercado de trabajo, cita que en la economía global, la productividad
laboral está definida como producción por unidad de insumo de mano de obra.
Vista así, la productividad laboral se refiere a la eficiencia con la que un país utiliza
recursos disponibles de la economía para la producción de bienes y servicios,
ofreciendo así, una medida del crecimiento económico, la competitividad y el nivel
de vida de los habitantes de un país, de una región. (Trabajo, 2015)

141
2.5. Fundamentos teóricos que sustentan las hipótesis

En la Figura 23, se muestra el mapa conceptual que sustentan las hipótesis de la


investigación.

Figura 23: Mapa conceptual que sustentan las hipótesis. Elaboración: propia

142
2.6. Hipótesis

2.6.1 Hipótesis general

Si se aplica la Robotic Process Automation – RPA, entonces se mejorará la


productividad del área de pagos en una empresa del sector retail.

2.6.1 Hipótesis especificas

a. Si se rediseña el proceso de registro, entonces se reducirá las horas de


trabajo.

b. Si se implementa controles avanzados con RPA, entonces se reducirá


los errores por el registro de factura.

c. Si se automatiza las tareas con RPA, entonces se reducirá el tiempo en


la transacción por factura.

143
2.7. Variables

 Independiente

 Robotic Process Automation – RPA


 Proceso de registro
 Controles avanzados con RPA
 Tareas con RPA

 Dependiente

 Productividad del área de pago


 Horas de trabajo
 Registro de factura
 Tiempo en la transacción por factura

 Indicadores

 Horas de trabajo
 Tiempo de validación por factura
 Tiempo de transacción por factura

 Matriz de Operacionalización

Las variables independientes como las variables dependientes i sus indicadores,


presentadas anteriormente permitieron trasladar el marco metodológico en un
plan de acción, donde se pudo determinar en detalle el método a través del cual
cada una de las variables serán medidas y analizadas.

En el Anexo 4 se muestra la matriz de operacionalización utilizada para el


estudio de la investigación.

144
CAPÍTULO III: MARCO METODOLÓGICO

3.1. Tipo, método y diseño de la investigación

Enfoque

La presente investigación corresponde al enfoque cuantitativo porque se realizará la


recolección de datos para probar la hipótesis basándonos en la medición numérica y
el análisis estadístico.

(Hernández Sampieri, Fernádez Collado, & Baptista Lucio, 2014), definen el


enfoque cuantitativo como un conjunto de procesos secuencial y probatorio, donde
cada etapa precede a la siguiente, impidiendo así saltar u omitir pasos.

 Tipo de la investigación

La presente investigación es del tipo aplicada porque se estará haciendo uso de


diversas herramientas y técnicas para la recolección de datos tales como base
de datos, para poder así resolver un problema.

145
(Hernandez, 2010, pág. 26) Define la investigación aplicada como “la
utilización de los conocimientos en la práctica, para aplicarlos en provecho de
los grupos que participan en esos procesos y en la sociedad en general, además
del bagaje de nuevos conocimientos que enriquecen la disciplina”.

Debido a que se trata de un enfoque cuantitativo y aplicado, la implementación


será de manera inmediata, no estando orientada solo al desarrollo de teorías.
“La investigación explicativa pretende establecer las causas de los events,
sucesos, o fenómenos que se estudian” (Hernández Sampieri, Fernádez
Collado, & Baptista Lucio, 2014)

 Método de la investigación

El tipo de método elegido para esta investigación es científico, ya que se


realizará una experimentación para la comprobación de las hipótesis
planteadas. Adicionalmente, por su nivel o alcance la investigación es
explicativa ya que profundizará la causa que está originando el evento, en otras
palabras, no solo se buscará dar solución al problema, sino también a dar
explicación a sus causas.

Los estudios explicativos van más allá de la descripción de conceptos o


fenómenos o del establecimiento de relaciones entre conceptos; es decir; están
dirigidos a responder por las causas de los eventos y fenómenos físicos o
sociales. Como su nombre lo indica, su interés se centra en explicar por qué
ocurre un fenómeno y en qué condiciones se manifiesta o por qué se relacionan
dos o más variables. (Hernández Sampieri, Fernádez Collado, & Baptista
Lucio, 2014, pág. 95)

 Diseño de la investigación

146
Para dar una respuesta a las preguntas que se plantea en la investigación, lograr
los objetivos de estudio y someter a las hipótesis formuladas a prueba, se
empleará el diseño de investigación cuasi experimental. Este diseño servirá
para las tres (03) variables que se manejan en la investigación. “Este diseño
consiste en aplicar a un grupo una prueba previa al estímulo o tratamiento
experimental, para luego administrar el estímulo y luego realizar la medición.”
(Hernández Sampieri, Fernádez Collado, & Baptista Lucio, 2014).

“Los diseños cuasi-experimentales tienen el mismo propósito que los estudios


experimentales: probar la existencia de una relación causal entre dos o más
variables. Cuando la asignación aleatoria es imposible, los cuasi-
experimentales (semejantes a los experimentos) permiten estimar los impactos
del tratamiento o programa, dependiendo de si llega a establecer una base de
comparación apropiada” (Hedrick, Bickman, & Rog, 1993)

Para el diseño de la muestra será según No Probabilística, debido a que la


elección de los elementos no depende de la probabilidad, sino de causas
relacionadas con las características de la investigación o de quien hace la
muestra.

Un diseño experimental en su modalidad cuasi-experimental tiene los


siguientes argumentos:
 Las variables dependientes (problemas) de la investigación son cuantitativas
 Se aplicó el estímulo intencionalmente la variable independiente (teórica)
 El nivel o método es explicativo, o lo que es lo mismo de causalidad
 No se usó grupo de control
 El diseño muestral es no aleatorio

Para responder a las preguntas de investigación y lograr los objetivos del


estudio se sometieron las tres (03) hipótesis formuladas a pruebas, usando un
diseño cuasi experimental, se trabajó con las variables independientes (Proceso
de Registro, Controles avanzados con RPA, Tareas con RPA) para observar el
efecto en los resultados de las variables dependientes (Horas de trabajo,
Registro de factura, Tiempo en la transacción por factura)

147
Este diseño permitió la toma de mediciones antes y después de la
implementación del nuevo modelo considerando un lapso de tiempo.

“Este diseño consiste en aplicar a un grupo una prueba previa al estímulo


o tratamiento experimental, para luego administrar el estímulo y luego
realizar la medición.” (Hernández Sampieri, Fernádez Collado, &
Baptista Lucio, 2014)

A continuación, detallaremos el diseño que se utilizara para cada una de las


hipótesis, ver Tabla 08, Tabla 09 y también la Figura 24.

Tabla 08:
Diseño de Investigación Cuasi-Experimental
Nombre Esquema

Diseño de un grupo de medición antes y después G O11 O12 O13 … X O22 O23 O24 …

Fuente: (Hernández Sampieri, Fernádez Collado, & Baptista Lucio, 2014)

Donde: G: Grupo de análisis o variable experimental.


O1n; Mediciones Pre test de la variable dependiente.
O2m: Mediciones Post test de la variable dependiente.
X: Tratamiento o estimuló.

Tabla 09:
Diseño Cuasi-Experimental
Variable
Objetivo Especifico Hipótesis Especifica Indicador
Dependiente

Rediseñar el proceso de Si se rediseña el proceso de


Proceso de Horas de
registro, para reducir las registro, entonces se reducirá
Registro Trabajo
horas de trabajo las horas de trabajo.
Implementar controles Si se implementa controles
Tiempo de
avanzados con RPA, para avanzados con RPA, entonces Registro de
validación por
reducir los errores por el se reducirá los errores por el factura
factura
registro de factura. registro de factura.
Automatizar las tareas Si se automatiza las tareas
Tiempo de
con RPA, para reducir el con RPA, entonces se
Tareas con RPA transacción
tiempo en la transacción reducirá el tiempo en la
por factura.
por factura. transacción por factura.

148
Fuente: Elaboración Propia.

Figura 24: Diseño Cuasi experimental. Elaboración Propia.

149
3.2. Población y muestra

 Población General

De acuerdo a (Hernández Sampieri, Fernádez Collado, & Baptista Lucio,


2014) la población general es definida de la siguiente manera:

“Una población es el conjunto de todos los casos que concuerdan con una
serie de especificaciones. Es la totalidad del fenómeno a estudiar, donde
las entidades de la población poseen una característica común la cual se
estudia y da origen a los datos de la investigación.” (Hernández Sampieri,
Fernández Collado, & Baptista Lucio, 2014)

Para la presente investigación se tuvo una población de estudio finita y


abarca 30000 comprobantes electrónicos.

La población es la misma para todas las variables que se trabaje durante la


ejecución de la investigación. Más adelante se detallará la población y
muestra por cada una de las variables.

 Muestra General

De acuerdo a (Hernández Sampieri, Fernádez Collado, & Baptista Lucio,


2014) la muestra general es definida de la siguiente manera:

“La muestra es un subgrupo de la población un subconjunto de elementos


que pertenecen a ese conjunto definido en sus características al que
llamamos población.” (Hernández Sampieri, Fernández Collado, &
Baptista Lucio, 2014)

Para la presente investigación se tuvo una muestra del tipo no probabilístico a


juicio del investigador. A continuación, se presenta la población y la muestra

150
que se emplearan por cada una de las variables dependientes planteadas en
esta investigación.

Para las cuatro (03) variables de la investigación tenemos:


 Horas de trabajo – Horas de trabajo
 Registro de factura – Tiempo de validación por factura.
 Tiempo en la transacción por factura – Tiempo de transacción por factura

 Población

La población para la variable dependiente tiempo en la transacción tendremos una


población Pre y Post respectivamente para esta investigación.
 Pre: Para el presente estudio se tomaron 12 meses del año 2019 que está
representado por 30000 facturas electrónicas (Estudio pre-test).

 Post: Para el presente estudio se tomaron 12 meses del año 2020 que está
representado por 30000 facturas electrónicas (Estudio post-test).

 Muestra

Tanto las muestras Pre y Post de la investigación serían igual a la población.

En la Tabla 10 se muestran las poblaciones y las muestras en una situación PRE Test
y POST Test se precisa que la muestra es la misma para ambos periodos, sin
embargo se indica que para el 2019 fueron procesadas sin RPA y para el proceso
2020 se consideró la implementación realizada.

151
Tabla 10:
Población y Muestra PRE y POST por cada una de las variables

Variable Población Muestra Población Muestra


Indicador
Dependiente PRE PRE POST POST

30,000 30,000 30,000 30,000


Horas de facturas facturas facturas facturas
Horas de trabajo
trabajo electronicas electronicas electronicas electronicas
2019 2019 2020 2020

30,000 30,000 30,000 30,000


Tiempo de
Registro de facturas facturas facturas facturas
Validación por
factura electronicas electronicas electronicas electronicas
Factura
2019 2019 2020 2020

30,000 30,000 30,000 30,000


Tiempo de
Tiempo en la facturas facturas facturas facturas
transacción por
transacción electronicas electronicas electronicas electronicas
factura
2019 2019 2020 2020

Fuente: Elaboración propia

152
3.3. Técnicas e instrumentos de recolección de datos

La técnica utilizada es el conjunto de reglas y de procedimientos que permitió al


investigador a establecer la relación con el objeto o sujeto de la investigación. El
instrumento es el mecanismo que se utilizó para recolectar y registrar la
información. (Pino, 2013)

Es la etapa donde se buscó elegir el instrumento que sea confiable y que nos
garantizó que los datos que se fueron recabando han permitido interpretar la
realidad. Esto suponía que la muestra de estudio comprendía las preguntas que se
les formulo. (Pino, 2013)

En el estudio de investigación la elaboración del diseño como planteamiento


teórico, no tendría efecto si no se efectúa la elaboración y la aplicación del
instrumento. Para ello se parte de un método estratégico que sirve de guía a través
la encuesta u observación. (Ver Anexo 6)

Para las (3) Variables de la investigación tenemos:

 Variable: Horas de trabajo – Horas de trabajo

 Variable: Registro de factura – Tiempo de Validación por factura

 Variable: Tiempo en la transacción – Tiempo de transacción por


factura

a. Técnicas e instrumentos

 Técnicas

Base de datos: Esta se realizó con la ayuda de elementos técnicos, SAP Hana
DB y el Sistema de información denominados: Sistema de Finanzas y control
(SAP Fico) de la empresa retail.

153
 Instrumentos

Se utilizó el software gestor de base de datos (DBMS por sus siglas en


inglés), SAP Hana DB en su versión SAP HANA 1.0 SP11 fue extraida
mediante un comando SQL “Select * from facturas”.

b. Criterio de validez del instrumento

La validez del instrumento DBMS SAP Hana DB en su versión SAP HANA 1.0
SP11, está dado por ser el líder en los softwares de gestión de base de datos,
como se puede apreciar en la Figura 06 extraída del reporte de evaluación de
Gartner de Julio del 20.

Figura 25: Magic Quadrant for Operational Database Management Services.


(Gartner, 2019)

154
c. Criterio de confiabilidad de instrumento

SAP HANA DB se aprovecha del bajo coste de la memoria principal (RAM), la


capacidad del procesamiento de datos de los procesadores multinúcleo y el
acceso rápido a datos de unidades de estado sólido con respecto a los discos
duros tradicionales para ofrecer un mejor rendimiento de las aplicaciones
analíticas y transaccionales.

Ofrece un entorno de consulta multi-motor de procesamiento que le permite


soportar tanto datos relacionales (con tanto en fila y columna orientado a
representaciones físicas en un motor híbrido) así como el tratamiento gráfico y
de texto para la gestión de datos no estructurados y semi-dentro del mismo
sistema. HANA DB es 100% compatible con ACID.

En la Tabla 11 se muestran las técnicas a emplear en el presente estudio; así como,


los instrumentos a utilizar para cada una de ellas.

Tabla 11:
Técnicas e instrumentos
Variable
Indicador Técnica Instrumento
Dependiente

Base de Datos a través de


Horas de trabajo Horas de trabajo Base de Datos
comandos SQL

Tiempo de
Base de Datos a través de
Registro de factura Validación por Base de Datos
comandos SQL
Factura

Tiempo de
Tiempo en la Base de Datos a través de
transacción por Base de Datos
transacción comandos SQL
factura
Fuente: Elaboración propia

155
3.4. Descripción de procedimientos de análisis

Con las variables y sus indicadores ya establecidos anteriormente, permite medir,


analizar y verificar los datos, y así obtener la información suficiente y necesaria
para el análisis de los resultados de la investigación. Para ello se desarrolló la
matriz de análisis de datos que se muestra a continuación (Ver Tabla 12).

Tabla 12:
Matriz de Análisis de datos
Variable Estadísticos
Indicador Escala de medición Análisis inferencial
Dependiente descriptivos

Horas de Media
Horas de trabajo Razón T de student
trabajo Mediana

Tiempo de
Registro de Media
Validación por Razón T de student
factura Mediana
factura

Tiempo en la Tiempo de
Media
transacción transacción por Razón T de student
Mediana
por factura factura

Fuente: Elaboración propia

156
Capítulo IV: RESULTADOS Y ANÁLISIS DE RESULTADOS

4.1. Resultados

En el presente capítulo se presentan los resultados obtenidos en el PRE Test, la


aplicación de la teoría, los resultados obtenidos en el POST Test para cada objetivo
planteado en la presente investigación.

 Generalidades

La presente investigación está enfocada en el área de pagos cuya misión es el


poder validar y registrar la factura electrónica en el sistema que cuenta la
compañía para poder realizar los pagos oportunos y así poder tener los insumos
a tiempo para la elaboración de los productos y generar ventas.

Anteriormente la empresa había implementado un sistema para la


automatización del proceso y poder registrar las facturas electrónicas, sin
embargo, la información era errónea y alto tiempo del proceso.

Para poder mejorar la problemática se ha propuesto un modelo con Robotic


Process Automation con la finalidad de poder leer, validar y registrar la factura

157
electrónica para poder reducir el tiempo del proceso y por lo tanto permitir
reducir facturas electrónicas erradas para poder realizar los pagos
oportunamente en las fechas establecidas.

En la Figura 26 podemos observar las causas para el problema general de la


investigación.

Figura 26: Diagrama de Ishikawa para el problema general. Elaboración propia

Se puede ver en la Figura 26 que se identificaron las causas primordiales de las


variables dependientes (alto número de facturas electrónicas y alto tiempo de
espera de pagos) mediante el diagrama de Ishikawa y se priorizaron las causas
raíces mediante la ponderación de hallazgos que fueron recolectados de la base
de datos del área de pagos de enero a diciembre del 2017.

Se puede ver que el sistema previamente utilizado carece de un robusto motor


de RPA (Robotic Process Automation) que pueda realizar todo el proceso del
área de pagos y tener la información con alta exactitud. Y eso impide a que la
organización misma no pueda comenzar a implementar un sistema con RPA.
Debido a que carecen del skill técnico para diseñar un diseño de este tipo.

158
 Tareas con RPA: Aplicar Tareas con RPA para reducir el tiempo en la
transacción por factura.

 Situación PRE Test

El proceso de la transacción de una factura en el área de pagos se ha venido


realizando primero de manera tradicional, es decir, solamente con la
revisión visual del PDF de cada factura electrónica de cada proveedor por
parte de un personal, que, basado en el nivel de experiencia y conocimientos
en contabilidad, puede realizar dicha labor si está conforme con lo que envió
el proveedor.

En el esfuerzo de automatizar este proceso, el área de pagos adopto la


automatización de procesos con robótica para así extraer, validar y registrar
todas las facturas electrónicas. Sin embargo, para evaluar los resultados se
compararon todo el proceso por personas especialistas del área de pagos
versus todas las facturas electrónicas hechas por automatización de procesos
con robótica.

Utilizando la métrica de exactitud, se calculó el promedio de precisión del


tiempo de transacción por factura en un periodo de 1 año.

En la Figura 27: Tiempo de transacción por factura en promedio.


Elaboración propia. se detalla el tiempo de transacción por factura en
promedio hechas por las personas especialistas del área de pagos por mes
durante el 2019.

Aunque las cifras aproximan en total anual de 102.31 minutos el tiempo de


transacción por factura, esa es una cifra demasiado alta debido a la criticidad
de no poder pagar a tiempo a los proveedores.

A continuación, en la Tabla 13: Muestra Pre Test Tiempo de transacción


por factura en promedio se puede apreciar el detalle de los 12 registros
(correspondientes a los 12 meses del año 2019) de la muestra PRE Test

159
antes de la implementación de una automatización de procesos con robótica
de las tareas con RPA.

Figura 27: Tiempo de transacción por factura en promedio. Elaboración propia.

Tabla 13:
Muestra Pre Test Tiempo de transacción por factura en promedio
Mes Muestra Pre Test
Enero 7.07
Febrero 8.36
Marzo 8.59
Abril 8.33
Mayo 8.87
Junio 9.62
Julio 9.11
Agosto 8.76
Setiembre 7.80
Octubre 8.98
Noviembre 8.13
Diciembre 8.66
TOTAL 102.31
Fuente: SAP Hana DB. Área de Pagos. Elaboración propia.

160
 Aplicación de la teoría

En el presente estudio, frente a la problemática que se observaba debido al


excesivo tiempo de transacción por factura que se utiliza en el área de
pagos, se ha optado por implementar Tareas con RPA (Automatización de
Procesos con Robotica).

Tareas con RPA significa Robotic Process Automation, que se refiere al uso
de software para automatizar tareas repetitivas y de baja complejidad en un
proceso de negocio.

El término RPA se originó en la década de 1990, cuando se desarrollaron las


primeras herramientas de automatización de procesos. Sin embargo, no fue
hasta principios de los años 2000 cuando las herramientas de RPA
comenzaron a ser ampliamente utilizadas por las empresas.

Las herramientas de RPA se han desarrollado y mejorado continuamente


desde su creación inicial. Algunas de las herramientas de RPA más
populares en la actualidad incluyen Automation Anywhere, UiPath y Blue
Prism.

No hay un autor específico del concepto de RPA, ya que es el resultado de


la evolución de las herramientas de automatización de procesos. Sin
embargo, varios expertos en el campo de la automatización de procesos de
negocios han contribuido al desarrollo y popularización de RPA, incluyendo
a (Willcocks, Lacity y Craig, 2015A)

Para empezar a implementar las tareas con RPA (Robotic Process


Automation) se usó la tecnología que permite automatizar tareas repetitivas
y de baja complejidad en un proceso de negocio. Algunas de las tareas
identificadas en el proceso del área de pagos que son candidatas para
realizarlas con RPA son:

161
- Extracción y procesamiento de datos: RPA puede ser utilizado para
extraer datos de diversas fuentes, como correos electrónicos, archivos
PDF, hojas de cálculo, bases de datos, etc. Una vez extraídos, los datos
pueden ser procesados y transformados para su posterior uso.
- Procesamiento de transacciones: RPA puede ser utilizado para
automatizar tareas relacionadas con el procesamiento de transacciones,
como la creación de facturas, la gestión de pagos, la emisión de órdenes
de compra, entre otros.
- Extracción de datos: El robot puede extraer automáticamente los datos de
la factura, como el número de factura, la fecha, el importe, etc.,
utilizando tecnologías de OCR (Reconocimiento Óptico de Caracteres) y
NLP (Procesamiento de Lenguaje Natural).
- Validación de datos: El robot puede validar automáticamente los datos
extraídos de la factura con los datos del proveedor y los registros
contables del sistema.
- Creación de la factura en el sistema contable: Si los datos de la factura
son correctos, el robot puede crear automáticamente una entrada contable
en el sistema contable correspondiente.
- Notificación de errores: Si se detectan errores en los datos de la factura,
el robot puede notificar automáticamente al usuario para que revise y
corrija los errores.

En resumen, RPA puede ser utilizado para automatizar cualquier tarea


repetitiva y de baja complejidad en un proceso de negocio, lo que permite a
las empresas aumentar la eficiencia, reducir los errores y liberar a los
empleados para que puedan centrarse en tareas más importantes y
estratégicas.

Teniendo el Enfoque claro de las Tareas con RPA sirve para mejorar los
procesos porque no requiere un gran cambio en el flujo de trabajo del
proceso o una gran inversión en nuevos sistemas de TI.

162
El robot RPA puede interactuar con sistemas, interfaces y realizar tareas
operativas mediante simulando la interacción de la fuerza laboral humana
como se ve en la (HerbertNathan, 2017)Figura 28: Manual and automated
process workflow (HerbertNathan, 2017).

Figura 28: Manual and automated process workflow (HerbertNathan, 2017)

La primera fase fue la programación para la extracción de cada correo que


los proveedores enviaban al buzón de correo del área de pagos la cual estaba
conformada por un PDF y un XML por cada factura electrónica
recepcionada.

La Figura 29: Extracción de PDF de OneDrive Microsoft 365 muestra las


funciones de extracción de un PDF realizadas. Las funciones tienen el
propósito de conectarse al buzón de correo del área de pagos donde están los
PDF y XML.

163
Figura 29: Extracción de PDF de OneDrive Microsoft 365

Luego se procederá a realizar la lectura del XML para identificar el RUC


del proveedor y el número de factura para buscarlo con la Orden de Compra
de SAP Hana para poder validar la información como montos de factura y el
detalle de productos y/o servicios. (Ver Figura 30).

164
Figura 30: Muestra de una Factura Electrónica de un proveedor. Elaboración propia

Esto permite realizar el primer filtro para ver si se acepta o rechaza el correo
enviado para luego el Bot notifique al proveedor por Correo.

Cuando automatiza una tarea relacionada con PDF, RPA recupera varias
propiedades del archivo y almacena los valores de estas propiedades en una
variable de diccionario.

RPA recupera el nombre y la extensión del archivo PDF, el título, el asunto


y el autor. Las propiedades del archivo se almacenan en una variable de
diccionario dentro de las siguientes claves:
 pdfTítulo

165
 pdfNombre de archivo
 pdfAsunto
 pdfAutor

El sistema asocia automáticamente las propiedades de un PDF con las


claves de diccionario correspondientes.

Esta función permitirá que la solución tenga un tiempo de respuesta óptimo


en realizar la tarea cada vez que repite hacer el mismo proceso por cada
PDF. (Taulli, 2020)

La segunda fase fue la lectura del XML de la factura electrónica y validar la


cabecera y detalle de los ítems de acuerdo a la Orden de Compra generada
en el Sistema SAP Hana. Que se podrá apreciar en la Figura 31: Muestra de
un XML de una factura electrónica. Elaboración propia.

Figura 31: Muestra de un XML de una factura electrónica. Elaboración propia

En la Figura 32: Extracción de datos del XML y validación con el SAP


Hana. Elaboración Propia. se podrá ver mediante esta técnica, el RPA

166
realiza el proceso de extracción de datos de un archivo XML mediante RPA
la cual implica los siguientes pasos:
 Leer el archivo XML: se utiliza una actividad de lectura de
archivos para abrir el archivo XML y cargar su contenido en
memoria.
 Analizar el archivo XML: se utiliza una actividad de análisis de
texto para buscar y extraer la información deseada del archivo
XML.
 Manipular la información extraída: se utiliza una actividad de
manipulación de texto para transformar la información extraída en
un formato más legible o procesable.
 Guardar la información extraída: se utiliza una actividad de
escritura de archivos para guardar la información extraída en un
formato de archivo deseado.

Figura 32: Extracción de datos del XML y validación con el SAP Hana.
Elaboración Propia.

Para la fase de despliegue se utilizó la plataforma como servicio (PaaS)


Cloud Automation Anywhere que es una plataforma unificada para para
desplegar bots automáticamente con el entorno administrable web con git.

Como se puede visualizar en la Figura 33: Diagrama del sistema usando


RPA. Elaboración propia. se muestra cómo los componentes de Automation

167
Anywhere interactúan con el centro de datos que está en PostgreSQL. Los
objetos en naranja son componentes de Automation Anywhere Cloud donde
se desplegarán los Bots.

Figura 33: Diagrama del sistema usando RPA. Elaboración propia.

Durante el proceso al combinar ambas tecnologías, es posible automatizar la


recolección de datos de diferentes sistemas y aplicaciones, procesarlos y
presentarlos en informes y dashboard en tiempo real.

Esto permitirá a utilizar RPA para extraer datos de diferentes sistemas y


aplicaciones de la empresa y enviarlos a Power BI para que se muestren en
un dashboard en tiempo real. Ver Figura 34.

Durante la fase de evaluación de métricas y monitoreo, una vez


implementado el bot con RPA realiza el proceso por cada factura electrónica
realizando las validaciones y extracción de información para el área de
pagos.

Luego de terminado el proceso se visualiza lo siguiente:


 Tiempo promedio de ejecución del bot: Es el tiempo promedio que
tarda el bot en completar un ciclo de ejecución de un proceso de
automatización.

168
 Tiempo de ciclo de negocio: Es el tiempo que tarda el proceso
automatizado en completarse desde el inicio hasta el final.
 Porcentaje de precisión del bot: Es la precisión con la que el bot
completa las tareas asignadas. Esta métrica se puede medir
comparando los resultados del bot con los resultados de las tareas
completadas manualmente.
 Volumen de tareas completadas: Es el número total de tareas que el
bot ha completado durante un período de tiempo determinado.

Figura 34: Reporte de Proveedores con sus facturas electrónicas procesados con
RPA. Elaboración Propia

Se pudo observar que el bot obtuvo una alta exactitud de 98% en tan solo 7
minutos de procesar las facturas del periodo de un mes.

Otras métricas que el RPA puede mostrar son:


 La cantidad de error de no poder leer las facturas electrónicas, el
cual se refiere al valor de error final en algún campo de ejecución
del Bot.
 La cantidad de error de validación, el cual se refiere al valor de
error

169
Estas métricas en la Figura 35: Lista de Métricas y tiempo de transacción
por factura realizados por el Bot con RPA. Elaboración propia. pueden ser
útiles para evaluar el éxito de un proceso de automatización y para
identificar áreas de mejora.

Automation Anywhere utiliza la tecnología de procesamiento de lenguaje


natural (NLP) y aprendizaje automático para automatizar tareas de
extracción de datos y documentos.
 final alcanzado en cada época (iteración) de evaluación.

Figura 35: Lista de Métricas y tiempo de transacción por factura realizados por el
Bot con RPA. Elaboración propia.

Con IQ Bot, los usuarios pueden crear fácilmente bots que puedan leer y
comprender documentos no estructurados, como facturas, formularios,
correos electrónicos, entre otros, y extraer la información necesaria de ellos.

IQ Bot utiliza el aprendizaje automático para entrenar al bot para reconocer


patrones y comprender el contenido de los documentos. El bot aprende a
medida que se le proporcionan más datos y puede mejorar su precisión con
el tiempo.

 Situación POST Test

170
Después de la implementación del nuevo proceso realizado por un Bot, el
área de pagos pudo visualizar todos los registros de pagos de los
proveedores automatizados correctamente clasificados, lo cual fue
corroborado por 5 personas especialistas en el área de pagos.

Podemos ver en la Figura 36: Listado de validaciones realizados por el


RPA. Elaboración propia. el listado de las validaciones mostrando
específicamente cuantas facturas electrónicas fueron validados por el RPA
correctamente por cada tipo: Compras, detracciones y Diario.

Figura 36: Listado de validaciones realizados por el RPA. Elaboración propia.

En esta etapa de evaluación estamos incluyendo también 2500 facturas


electrónicas que fueron separados para evaluar al RPA (2500 de un total de
30000 facturas electrónicas), estas son imágenes no antes vistas por el
modelo.

Además, al aumentar la precisión del proceso al usar el RPA implementado,


consecuentemente el tiempo de transacción por factura fue disminuido.

171
En la Figura 37: Reducción de Tiempo de transacción por factura después
de implementar tareas con RPA. Elaboración propia se puede visualizar esta
reducción drástica del tiempo de transacción por factura.

Figura 37: Reducción de Tiempo de transacción por factura después de


implementar tareas con RPA. Elaboración propia

A continuación, en la Tabla 14, se puede apreciar el detalle de los 12


registros (correspondientes a los 12 meses del año 2020) de la muestra
POST Test después de la implementación de las tareas con RPA.

Tabla 14:
Muestra Post Test Tiempo de transacción por factura (usando Tarea con
RPA)
Mes Muestra Post Test
Enero 1.80
Febrero 1.29
Marzo 2.66
Abril 1.98
Mayo 1.92
Junio 2.03
Julio 2.24
Agosto 2.33
Setiembre 2.35
Octubre 2.18
Noviembre 1.47
Diciembre 2.44

172
TOTAL 24.69
Fuente: SAP Hana DB. Área de Pagos. Elaboración propia.

Aplicando al proceso del área de pagos basado con tareas con RPA se ha
logrado disminuir de 8.50 minutos (de 8.80 a solo 1.60 minutos) en
promedio el tiempo de transacción por factura.

Al automatizar este proceso con RPA, se puede reducir significativamente el


tiempo de transacción de factura, ya que el bot puede procesar las facturas
mucho más rápido que un humano y sin errores.

Además, el proceso se puede realizar las 24 horas del día, lo que también
mejora la eficiencia del proceso y reduce los tiempos de espera.

173
 Controles Avanzados con RPA: Aplicar Controles avanzados con RPA para
reducir los errores en el registro de factura.

 Situación PRE Test

Como anteriormente mencionado, el proceso de validar las facturas


electrónicas en el área de pagos se ha venido realizando primero de manera
tradicional, hasta la implementación de la automatización con RPA que
utiliza algoritmos internos utilizados por un software de RPA pueden variar
según el proveedor y la funcionalidad específica que se está automatizando.

A continuación, se describen algunos de los algoritmos más comunes


utilizados en el proceso de automatización de tareas mediante RPA.
 Algoritmos de OCR (Reconocimiento Óptico de Caracteres): Estos
algoritmos permiten al robot identificar y extraer información de
texto de imágenes o documentos escaneados. Los algoritmos de
OCR se basan en técnicas de visión por computadora, aprendizaje
automático y procesamiento de imágenes.
 Algoritmos de NLP (Procesamiento de Lenguaje Natural): Estos
algoritmos permiten al robot comprender y procesar el lenguaje
humano. Los algoritmos de NLP se basan en técnicas de aprendizaje
automático y procesamiento de texto, y pueden utilizarse para
extraer información de texto no estructurado, como correos
electrónicos, chats, redes sociales, etc.
 Algoritmos de aprendizaje automático: Estos algoritmos permiten al
robot aprender de los patrones y datos históricos para mejorar su
capacidad de realizar tareas específicas. Los algoritmos de
aprendizaje automático se basan en técnicas estadísticas y
matemáticas, y se utilizan para entrenar modelos de predicción y
clasificación.

Este es un gran problema debido al tiempo utilizado para validar la factura


del proveedor y no poder realizar los pagos respectivos generando malestar
y desabastecimiento de insumos y materiales para la empresa.

174
En la Figura 38, se pueden ver el tiempo de validación por factura durante el
año 2019, con un promedio mensual de alrededor de 10216 minutos, que es
bastante alto.

Figura 38: Tiempo de validación por factura. Elaboración propia.

A continuación, en la Tabla 15, se puede apreciar el detalle de los 12


registros (correspondientes a los 12 mes del año 2019) de la muestra PRE
Test antes de la implementación de controles avanzados con RPA para
reducir los errores en el registro de factura.

Tabla 15:
Muestra Pre Test Tiempo de Validación por factura
Mes Muestra Pre Test
Enero 858
Febrero 831
Marzo 862
Abril 838
Mayo 862
Junio 827
Julio 886

175
Mes Muestra Pre Test
Agosto 897
Setiembre 814
Octubre 806
Noviembre 841
Diciembre 894
TOTAL 10216
Fuente: SAP Hana DB. Área de Pagos. Elaboración propia.

 Aplicación de la teoría

Para el presente estudio, frente a la problemática que se observaba de debido


los bajos niveles de precisión de la manera tradicional de validar las facturas
para el registro, se ha optado por implementar controles avanzados con
RPA.

Automation Anywhere es una plataforma de automatización de procesos


empresariales (RPA) que proporciona una amplia gama de herramientas y
servicios para automatizar tareas repetitivas y mejorar la eficiencia y
precisión en los procesos de negocio.

El ecosistema de Automation Anywhere se compone de los siguientes


elementos (ver Figura 39)

176
Figura 39: Controles avanzados de RPA para las diferentes plataformas. (Taulli,
2020)

Los controles avanzandos con RPA para esta investigación están


clasificados de la manera siguiente:
 Studio: es la herramienta de desarrollo de Automation Anywhere,
que permite a los desarrolladores crear y personalizar los bots de
automatización.
 Bot Store: es una tienda en línea de Automation Anywhere que
ofrece una amplia gama de bots preconstruidos, plantillas y
componentes reutilizables para una amplia gama de tareas de
automatización.
 Control Room: es la consola central de Automation Anywhere, que
proporciona una interfaz de usuario para gestionar y monitorizar los
bots de automatización, así como para programar y programar las
tareas de automatización.
 IQ Bot: es una herramienta de automatización de procesamiento de
datos que utiliza inteligencia artificial y aprendizaje automático para
procesar y analizar grandes cantidades de datos no estructurados.
 Bot Insight: es una herramienta de análisis de datos que proporciona
información detallada sobre el rendimiento de los bots de
Automation Anywhere, incluyendo la eficiencia y la precisión de los
procesos automatizados.

177
 BotFarm: es un entorno de ejecución de bots alojado en la nube que
permite a los desarrolladores ejecutar y gestionar bots de
Automation Anywhere en una infraestructura de nube segura y
escalable.
 Enterprise Automation Anywhere: es la versión empresarial de
Automation Anywhere, que proporciona una amplia gama de
características y mejoras, incluyendo una interfaz de usuario
actualizada y herramientas de colaboración y gestión de tareas
mejoradas.

El ecosistema de Automation Anywhere proporciona una solución completa


y escalable para la automatización de procesos empresariales, que incluye
herramientas de desarrollo, servicios de nube y análisis de datos, lo que
permite a las empresas automatizar sus procesos de negocio y mejorar su
eficiencia y eficacia.

En el presente estudio se usó los controles de validaciones avanzados de


RPA que fue implementado con Automation Anywhere que permite validar
datos, archivos como PDF y XML de una factura electrónica y verificar su
autenticidad en el Portal de SUNAT.

Procediendo con la creación del validador de la factura electrónica (Ver


Figura 40) se empezó a decirle cual es la URL de la Sunat y las diferentes
condiciones para saber el estado de una factura electrónica.

178
Figura 40: Control avanzado RPA para validación de datos de factura electrónica.
Elaboración Propia

A su vez realizar las validaciones respectivas concernientes en el proceso de


registro en SAP Hana.

Luego se codifico en Automation Anywhere la función de validaciones de la


factura electrónica teniendo todas actividades siguientes:
 Control de excepciones: permite a los bots detectar errores y
excepciones en el proceso de automatización y tomar medidas
específicas para resolverlos.
 Manejo de errores: permite a los bots manejar errores comunes y
tomar medidas específicas para corregirlos o informarlos.
 Monitoreo en tiempo real: proporciona información en tiempo real
sobre el rendimiento de los bots y la ejecución de procesos de
automatización.
 Programación avanzada: permite a los desarrolladores programar
procesos de automatización complejos y personalizados utilizando
lenguajes de programación como Java y Python.
 Integración de sistemas: permite a los bots integrarse con sistemas y
aplicaciones externos, lo que les permite acceder a datos y
funcionalidades adicionales para mejorar el rendimiento y la
precisión de los procesos de automatización.

179
Las funciones avanzadas de control RPA de Automation Anywhere
permiten a los desarrolladores y administradores de bots tener un mayor
control y personalización sobre los procesos de automatización, lo que les
permite mejorar la calidad y la eficiencia de los procesos de negocio
automatizados. (Ver Figura 41: Diagrama usando Controles Avanzados de
RPA. Elaboración propia)

Figura 41: Diagrama usando Controles Avanzados de RPA. Elaboración propia

Para la fase de despliegue se utilizó la plataforma como servicio (PaaS)


Cloud Automation Anywhere que es una plataforma unificada para para
desplegar bots automáticamente con el entorno administrable web con git.

La implementación se hizo usando la arquitectura distribuida con alta


disponibilidad (HA) en Automation Anywhere se refiere a un enfoque para
diseñar la infraestructura de automatización de procesos robóticos (RPA)
que implica la distribución de componentes y servicios de la plataforma de
Automation Anywhere en múltiples servidores físicos o virtuales.

El objetivo principal de esta arquitectura es mejorar la escalabilidad, la


eficiencia y la disponibilidad de la plataforma de Automation Anywhere,

180
permitiendo a las organizaciones manejar cargas de trabajo más grandes y
reducir el tiempo de inactividad.

En una arquitectura distribuida con HA en Automation Anywhere, se


pueden utilizar varios componentes y servicios clave, tales como:
 Control Room: se puede desplegar en un entorno de alta
disponibilidad para garantizar la continuidad del servicio.
 Workers: se pueden distribuir en múltiples servidores para aumentar
la capacidad de procesamiento y la resiliencia del sistema.
 Base de datos: se puede utilizar una base de datos distribuida para
mejorar la escalabilidad y la disponibilidad de los datos.
 Balanceadores de carga: se pueden utilizar para distribuir la carga de
trabajo entre los Workers y evitar la sobrecarga de un servidor en
particular.
 Almacenamiento de archivos: se puede utilizar una solución de
almacenamiento compartido para permitir que los Workers accedan
a archivos y recursos compartidos de manera más eficiente.

En general, la arquitectura distribuida con HA en Automation Anywhere es


una forma efectiva de mejorar el rendimiento, la escalabilidad y la
resiliencia de la plataforma de automatización de procesos robóticos, lo que
permite a las organizaciones aprovechar al máximo sus inversiones en RPA.

Durante la fase de evaluación de métricas y monitoreo, una vez


implementado los controles Avanzados con RPA. Se pudo observar que
obtuvo una alta exactitud de 94% en tan solo 2 minutos después de haber
iniciado el Bot las validaciones y reducir el tiempo del registro. (Ver Figura
42: Lista de métricas y basado en controles avanzado con RPA. Elaboración
propia)

181
Figura 42: Lista de métricas y basado en controles avanzado con RPA. Elaboración
propia

Es decir, alta precisión tenga en la validación de datos de una factura


electrónica, se ha entrenado adecuadamente y se ha implementado de
manera efectiva, por lo que es importante realizar pruebas rigurosas y
monitorear de cerca los procesos automatizados para asegurarse de que
estén funcionando correctamente y ajustarlos en caso de ser necesario.

Otras métricas que los controles avanzados con RPA nos pueden mostrar
son:
 Precisión: La capacidad del control avanzado con RPA para realizar
tareas sin errores. Se mide en términos de precisión porcentual.
 Tiempo de ejecución: El tiempo que tarda el control avanzado con
RPA en completar una tarea. Se mide en términos de tiempo
promedio por tarea.
 Tiempo de actividad: El tiempo que el control avanzado con RPA
está en funcionamiento y realizando tareas. Se mide en términos de
tiempo de actividad por día.
 Tiempo de inactividad: El tiempo que el control avanzado con RPA
no está en funcionamiento. Se mide en términos de tiempo de
inactividad por día.

182
Es importante tener en cuenta que estas métricas pueden variar dependiendo
del entorno empresarial y los objetivos específicos de implementación de
los controles avanzados con RPA.

Esto demuestra que los controles avanzados con RPA tiene una alta
precisión de lectura de datos y validar la información que tiene cada factura
electrónica y realizar el registro exitoso en el Sistema SAP Hana para el área
de pagos.

 Situación POST Test

Después de la implementación del nuevo proceso realizado por un Bot, el


área de pagos pudo visualizar todas las facturas electrónicas que fueron
validadas ante SUNAT de los proveedores automatizados correctamente
clasificados, lo cual fue corroborado por 5 personas especialistas en el área
de pagos.

Podemos ver en la Figura 43 las validaciones de una factura electrónica


clasificados por el tipo de comprobante y estado ante SUNAT.

Figura 43: Validaciones de factura electrónica por tipo documento y estado.


Elaboración propia.

En esta etapa de evaluación estamos incluyendo también 2500 facturas


electrónicas que fueron separados para evaluar al RPA (2500 de un total de

183
30000 facturas electrónicas), estas son las facturas no antes validadas por
los controles avanzados por RPA.

Además, al aumentar la precisión del proceso al usar controles avanzados


con RPA implementado, consecuentemente el tiempo de validación por
factura fue disminuido. En la Figura 44 se puede visualizar esta reducción
drástica del tiempo de validación por factura.

Figura 44: Reducción de Tiempo de validación de factura después de implementar


controles avanzados con RPA. Elaboración propia.

A continuación, en la Tabla 16 se puede apreciar el detalle de los 12


registros (correspondientes a los 12 meses del año 2020) de la muestra
POST Test después de la implementación de controles avanzados con RPA.

Tabla 16:
Muestra Post Test Validación por factura (usando Controles avanzados con
RPA)
Mes Muestra-Post-Test
Enero 353
Febrero 334
Marzo 367
Abril 362
Mayo 324
Junio 315

184
Mes Muestra-Post-Test
Julio 378
Agosto 355
Setiembre 316
Octubre 312
Noviembre 329
Diciembre 370
TOTAL 4115
Fuente: SAP Hana DB. Área de Pagos. Elaboración propia.

Después de implementar controles avanzados de RPA, el área de pagos una


vez que se ha configurado y entrenado adecuadamente el robot de RPA para
procesar facturas, el tiempo de validación de cada factura puede ser muy
rápido, en cuestión de segundos o minutos.

Esto se debe a que el robot puede leer y extraer automáticamente la


información necesaria de la factura, compararla con los datos en los
sistemas empresariales y realizar las comprobaciones necesarias para
validarla.

185
 Proceso de Registro: Aplicar rediseño al proceso de registro para reducir
las horas de trabajo.

 Situación PRE Test

Como anteriormente mencionado, el proceso de registro de facturas


electrónicas en el área de pagos se ha venido realizando primero de manera
tradicional, hasta la implementación de rediseño el proceso de registro con
RPA.

El proceso actual como está desarrollado por el área de pagos tiene un flujo
que demanda muchas horas de trabajo para poder cumplir con los pagos
oportunos a los proveedores, en la Figura 45 se podrá ver las horas de
trabajo por mes durante el año 2019.

Figura 45: Horas trabajadas por mes en el proceso de registro de facturas


electrónicas. Elaboración propia.

A continuación, en la Tabla 17 se puede aprecia el detalle de los 12 registros


(correspondientes a los 12 meses del año 2019) de la muestra PRE Test
antes de la implementación de un rediseño de proceso en el registro basados
con RPA.

186
Tabla 17:
Muestra Pre Test de Horas trabajadas por Mes
Mes Muestra Pre Test

Enero 2973.51

Febrero 2974.86

Marzo 2973.91

Abril 2973.84

Mayo 3185.79

Junio 3149.05

Julio 3113.84

Agosto 3010.58

Setiembre 3041.63

Octubre 3134.13

Noviembre 2993.64

Diciembre 2997.92

TOTAL 36522.7
Fuente: SAP Hana DB. Área de Pagos. Elaboración propia

 Aplicación de la teoría

Para el presente estudio, frente a la problemática que se observaba de debido


los bajos niveles de precisión de la manera tradicional de validar las facturas
para el registro, se ha optado por el rediseño al proceso de registro para
reducir las horas de trabajo en el Área de Pagos.

El proceso de registro puede ser un proceso intensivo en mano de obra, ya


que implica la entrada de datos en múltiples sistemas, la verificación de la
información del usuario y la generación de documentos.

RPA puede automatizar gran parte de este proceso, lo que permite a los
trabajadores enfocarse en tareas más importantes y de mayor valor.

Para rediseñar el proceso de registro con RPA, se pueden seguir los


siguientes pasos:

187
 Identificar los procesos que se pueden automatizar: Realizar una
evaluación detallada del proceso de registro actual para identificar
tareas que se puedan automatizar con RPA.
 Crear un flujo de trabajo automatizado: Crear un flujo de trabajo
automatizado para el proceso de registro utilizando herramientas de
RPA. Este flujo de trabajo debe incluir la entrada de datos,
verificación de información, generación de documentos, y cualquier
otra tarea que sea necesaria para completar el proceso de registro.
 Configurar robots de software: Configurar robots de software para
realizar tareas específicas dentro del flujo de trabajo automatizado.
Estos robots pueden interactuar con los sistemas informáticos y
bases de datos relevantes para completar las tareas.
 Pruebas y depuración: Realizar pruebas y depurar el flujo de trabajo
automatizado para asegurarse de que funciona correctamente y
cumple con los requisitos de negocio.
 Implementación y monitoreo: Una vez que se han completado las
pruebas y depuraciones, se puede implementar el flujo de trabajo
automatizado en el entorno de producción. Se debe monitorear el
proceso para asegurarse de que está funcionando correctamente y
hacer ajustes según sea necesario.

El uso de RPA para rediseñar el proceso de registro puede reducir el tiempo


y la cantidad de trabajo manual requerido, aumentar la eficiencia y mejorar
la precisión del proceso. (Taulli, 2020)

A continuación, podremos ver en la Figura 46 como se encontró el proceso


de registro de manera tradicional en el área de pagos y ahora con el rediseño
del proceso de registro con RPA, se reducirá las actividades en cada fase
que conlleva a validar la factura electrónica ante SUNAT.

188
Figura 46: Proceso tradicional y el Proceso de registro con RPA. Elaboración
Propia.

Como se puede apreciar en la Figura 46 se puede apreciar el Rediseño del


Proceso en el área de pagos con RPA, ahora la plataforma de RPA con
Automation Anywhere se encarga de todo el proceso de registro de una
factura electrónica, así como la actualización en el Sistema Sap Hana.

Adicionalmente, La calendarización de pagos también es ejecutada por el


sistema. Solo se requerirá de una persona que dé el visto bueno respecto a la
fecha de pago; las acciones requieren de juicio.

Esto reduce el tiempo de procesamiento por factura electrónica de 10


minutos a 3 minutos, con el beneficio adicional de que la precisión del
proceso sube al 100 %.

Por otra parte, se puede visualizar que no solo habido una redistribución de
quienes ejecutan dichas tareas, si no que el proceso sufrió un rediseño. Dado
que el Bot tiene la habilidad de trabajar con datos no estructurados, que ya
no es necesario transformar la información a un formato estándar para
realizar el registro de la factura electrónica.

Adicionalmente, El Bot puede revisar el reporte de ciclo de pago en línea y


así asegurar que no se pase ninguna fecha de pago a los proveedores.

189
La automatización de SAP Hana con Metabot es uno de los métodos
sencillos y directos disponibles en la versión 11x hacia adelante de
Automation Anywhere. (Ver Figura 47: Control Avanzado para el registro
de factura en SAP Hana.). Para usar este método necesitamos seguir los
pasos dados:
 Agregue el archivo DLL de SAP al diseñador de Metabot.
 Cree la lógica de MetaBot con el archivo DLL.
 Use la opción de grabación y reproducción de SAP Gui para obtener
el ID del objeto.
 Pase el ID del objeto a Metabot Logic.
 Llame a Metabot Logic desde el cliente de Automation Anywhere.

Figura 47: Control Avanzado para el registro de factura en SAP Hana.

Algunas de las tareas que se pueden automatizar con Automation Anywhere


con la integración de SAP HANA incluyen la extracción de datos, la
transformación de datos y la carga de datos (ETL), así como la validación y
reconciliación de datos.

Además, puede utilizar Automation Anywhere para automatizar otros


procesos, como la entrada de datos, la generación de informes y la gestión
de usuarios, que están relacionados con SAP HANA.

Para integrar Automation Anywhere con SAP HANA, puede usar el


controlador ODBC de SAP HANA para conectarse a la base de datos y
automatizar las tareas requeridas usando las capacidades RPA de
Automation Anywhere.

190
Como alternativa, puede usar los conectores SAP prediseñados de
Automation Anywhere, que le permiten automatizar las tareas relacionadas
con SAP HANA mediante acciones de arrastrar y soltar sin necesidad de
conocimientos de codificación.

La integración de SAP HANA con Automation Anywhere puede ayudarlo a


mejorar la eficiencia de los procesos comerciales, reducir los costos
operativos y mejorar la precisión y consistencia de los datos.

Para la fase de despliegue se utilizó la plataforma como servicio (PaaS)


Cloud Automation Anywhere que es una plataforma unificada para para
desplegar bots automáticamente con el entorno administrable web con git.

La arquitectura de Automation Anywhere con SAP HANA depende del tipo


de integración que se desee realizar entre ambas plataformas. (Ver Figura
48: C4 Container Diagram usando Controles de SAP Hana con RPA.
Elaboración propia

Figura 48: C4 Container Diagram usando Controles de SAP Hana con RPA.
Elaboración propia

191
Una forma de integrar Automation Anywhere con SAP HANA es a través
del uso de la API de RESTful de SAP HANA. En esta arquitectura,
Automation Anywhere se comunica con SAP HANA a través de solicitudes
HTTP/HTTPS y puede enviar y recibir datos utilizando formato JSON. Esta
arquitectura es útil para tareas de integración y extracción de datos, y puede
ser escalable y flexible.

Otra forma de integración es a través del uso del conector SAP de


Automation Anywhere. En esta arquitectura, el conector SAP se comunica
directamente con SAP HANA, lo que permite la integración de las
funcionalidades de SAP HANA en los bots de Automation Anywhere.

Esta arquitectura es especialmente útil si se desea automatizar procesos de


SAP HANA, como la generación de informes y la administración de
usuarios.

En cualquier caso, es importante asegurarse de que se cumplan los


requisitos de seguridad y de rendimiento, y de que se sigan las mejores
prácticas recomendadas por SAP HANA y Automation Anywhere.

También es recomendable tener una comprensión clara de la estructura y los


requisitos de la base de datos de SAP HANA para poder diseñar una
arquitectura de integración efectiva.

192
Figura 49: Registro de factura en SAP Hana con Automation Anywhere(RPA).
Elaboración propia.

En el sistema SAP Hana se realizó el registro de la factura de la factura del


proveedor que fue enviada al buzón y posteriormente el RPA empieza el
proceso iniciando sesión para poder realizar todas las actividades de
validaciones de ítems y montos de su Orden de compra como se aprecia en
la Figura 49.

 Situación POST Test

Después de la implementación del nuevo proceso realizado por un Bot, el


área de pagos pudo visualizar el registro en SAP Hana de todas las facturas
electrónicas que fueron validadas ante SUNAT de los proveedores
automatizados correctamente clasificados, lo cual fue corroborado por 5
personas especialistas en el área de pagos.

Podemos ver en la Figura 50 las validaciones de una factura electrónica de


los proveedores ante SUNAT con sus estados de respuesta y a su vez son
registrados en SAP Hana.

193
Figura 50: Validación y registro de una factura electrónica en SAP Hana.
Elaboración Propia.

En esta etapa de evaluación estamos incluyendo también 2500 facturas


electrónicas que fueron separados para evaluar al RPA (2500 de un total de
30000 facturas electrónicas), estas son las facturas no antes validadas y que
también deben ser registradas en SAP Hana por los controles avanzados del
RPA.

Además, al aumentar la precisión del proceso de registro de las facturas


electrónicas con RPA implementado, consecuentemente el tiempo de
validación y el proceso de registro por factura fueron disminuidos. En la
Figura 51 se puede visualizar esta reducción drástica de las horas trabajadas
en el mes.

194
Figura 51: Reducción de horas de trabajo después de implementar el rediseño al
proceso de registro con RPA. Elaboración propia.

A continuación, en la Tabla 18 se puede apreciar el detalle de los 12


registros (correspondientes a los 12 meses del año 2020) de la muestra
POST Test después de la implementación del rediseño al proceso de registro
para reducir las horas de trabajo con RPA.

Tabla 18:
Muestra Post Test Horas Trabajadas por mes
Mes Muestra Post Test
Enero 699.79
Febrero 720.28
Marzo 752.15

Abril 771.72

Mayo 787.52

Junio 718.23

Julio 722.01

Agosto 723.65

Setiembre 768.89

Octubre 728.99

Noviembre 729.97

Diciembre 730.08

TOTAL 8853.28
Fuente: SAP Hana DB. Área de Radiología. Elaboración propia.

195
Es importante tener en cuenta que la empresa emplea 5 personas para el
proceso del área de pagos. Considerando un mes de sueldo para dichas
personas, nos lleva a un total de S/.12,500.00. A esto se debe adicionar el
costo de la licencia de Automation Anywhere (con un costo anual de
S/10,000.00), lo que representa mensualmente de S/.833.00.

Estos datos nos sirven para realizar el cálculo del valor de ganancia de
tiempo (VTG).
VTG = (EC – AC) /AC x 100%
EC = Costos de los procesos realizados por los empleados.
AC = Costos de procesos ejecutados por bots.

A continuación, en la Tabla 19: Cálculo de valor de ahorro de tiempo se


puede apreciar el detalle del cálculo de valor de ahorro de tiempo que consta
de un valor de costo hora-humana contra el costo hora-robot en un periodo
de 2 años.

Tabla 19:
Cálculo de valor de ahorro de tiempo
Cálculo del Valor de Ahorro de Tiempo
1 año 2 año
Empleado
Costo Persona Por Año 150000 150000
FTE 0.6 0.6

Robotic Process Automation


Costo x Licencia 10000 10000
Costo de desarrollo bot 30000 0

196
Costo de Mantenimiento 5000 5000
FTE 0.12 0.12
VTG % 1567% 4900%
Fuente: Calculo de valor de ahorro de tiempo. Elaboración propia.

El valor de ahorro de tiempo es aún mayor en el segundo año ya que no hay


costos de servicio relacionados.
Los costos anuales relacionados con los empleados incluyen un salario
promedio, pagos de impuestos y seguridad social. Los costos relacionados
con la automatización incluyen los costos promedio de software, servicio y
mantenimiento de un paquete de un solo usuario. Los costos del servicio se
pagan una vez después de la implementación, por lo que son cero para el
año 2.

VTG = (EC – AC) /AC x 100%


Durante el 1º año:
VTG = ((150000 x 0,6 – 45000 x 0,12)/45000 x 0,12) X 100% = 1567%

Para el 2º año:
VTG = ((150000 x 0,6 – 15000 x 0,12)/15000 x 0,12) X 100 % = 4900%

4.2. Análisis de resultados

Generalidades

En esta sección se presentan los planteamientos y los resultados de las pruebas de


normalidad y de las pruebas de hipótesis de esta investigación, donde se expone el
detalle de la información levantada de las muestras en situación pre test y en
situación post test, de manera que se pueda comprobar y verificar el contraste de las
muestras, a través del análisis de la estadística inferencial planteadas en la
investigación para cada una de las hipótesis específicas.

197
Para todos los resultados de las pruebas se ha utilizado el software estadístico IBM
SPSS Statistics en su versión 26. Este software ofrece análisis estadístico avanzado,
una amplia biblioteca de algoritmos de machine learning, análisis de texto,
extensibilidad de código abierto, integración con big data y un fácil despliegue en
las aplicaciones.

Su facilidad de uso, flexibilidad y escalabilidad hacen que SPSS sea accesible para
usuarios con cualquier nivel de conocimiento. Además, es adecuado para proyectos
de todos los tamaños y niveles de complejidad, y puede ayudar a los investigadores
a encontrar nuevas oportunidades, mejorar la eficiencia y minimizar el riesgo.

 Prueba de Normalidad

Para las pruebas de normalidad se plantean las siguientes hipótesis:

H0: Hipótesis Nula – Los datos de la muestra, SI son paramétricos, siguen

una distribución normal

H1: Hipótesis Alterna – Los datos de la muestra, NO son paramétricos, no

siguen una distribución normal

Nivel de significancia: Sig. = 0.05

Regla de decisión:

 Si el nivel de significancia Sig. resulta ser un valor mayor o igual al 5,00%


(Sig. ≥ 0,05), entonces, se acepta la hipótesis nula (H0.)

Por lo tanto, los datos de la muestra, SI son paramétricos, siguen una


distribución normal.

198
 Si el nivel de significancia Sig. resulta ser un valor menor al 5,00% (Sig. <
0,05), entonces, se acepta la hipótesis alterna (H1)

Por lo tanto, los datos de la muestra, NO son paramétricos, no siguen una


distribución normal.

 Prueba de Hipótesis

Para la contrastación de hipótesis se plantea la siguiente validez de la hipótesis:

H0: Hipótesis Nula – NO existe diferencia estadística significativa entre la

muestra Pre-Test y la muestra Post Test

H1: Hipótesis Alterna – SI existe diferencia significativa estadística entre la

muestra Pre-Test y la muestra Post Test (Hipótesis del Investigador)

Nivel de significancia: Sig. = 0.05

Regla de decisión:

 Si el nivel de significancia Sig. resulta ser un valor mayor o igual al 5,00%


(Sig. ≥ 0,05), entonces, se acepta la hipótesis nula (H 0.), o lo que es lo
mismo, se rechaza la hipótesis del investigador.

Por lo tanto: NO se aplica la Variable Independiente (Variable Teórica)


del investigador

 Si el nivel de significancia Sig. resulta ser un valor menor al 5,00% (Sig. <
0,05), entonces, se acepta la hipótesis alterna (H 1), o lo que es lo mismo, se
acepta la hipótesis del investigador.

Por lo tanto: SI se aplica la Variable Independiente (Variable Teórica) del


investigador

199
200
 Hipótesis especificas 01: Si se automatiza las tareas con RPA, entonces se
reducirá el tiempo en la transacción por factura.

 Pruebas de Normalidad

 Muestra Pre Test y Post Test:

De acuerdo a lo descrito en el punto 3.2 las muestras para la variable las

Tareas con RPA son relacionadas por ser las mismas facturas que han
sido analizados.

Consta de un total de 12 datos de tiempo de transacción por factura en


promedio, en la muestra antes (Pre Test) y en la muestra después Post
Test), de aplicar la variable independiente en la investigación para esta
primera hipótesis específica. Ver Tabla 20.

Tabla 20:
Muestra Pre Test y Post Test de tiempo de transacción por factura
Tiempo de transacción por factura en promedio
Muestra Pre Test Muestra Post Test
MES
2019 2020
Enero 7.07 1.80
Febrero 8.36 1.29
Marzo 8.59 2.66
Abril 8.33 1.98
Mayo 8.87 1.92
Junio 9.62 2.03
Julio 9.11 2.24
Agosto 8.76 2.33
Setiembre 7.80 2.35
Octubre 8.98 2.18
Noviembre 8.13 1.47
Diciembre 8.66 2.44
TOTAL 102.31 24.69
Fuente: SAP HANA. Empresa de la investigación
Elaboración propia

201
 Prueba paramétrica Pre Test y Post Test

En el cuadro de resumen de procesamiento de casos, obtenido mediante


el software IBM SPSS Versión 26, se verifica que, del total de 12
muestras procesadas, el 100% han sido validadas, es decir, no hubo
ningún dato perdido. Ver Tabla 21.

Tabla 21:
Resumen de procesamiento de datos – tiempo de transacción por factura
muestras Pre Test y Post Test
Resumen de procesamiento de casos
Casos
Válido Perdidos Total
N Porcentaje N Porcentaje N Porcentaje
Tiempo Promedio
12 100,0% 0 0,0% 12 100,0%
- PRE
Tiempo Promedio
12 100,0% 0 0,0% 12 100,0%
- POST
Fuente: IBM SPSS Versión 26

Estadísticos descriptivos

De la Tabla 22, podemos ver que se ha obtenido las medidas de tendencia


central, así como, como medidas de dispersión, para las muestras Pre
Test y Post Test.

Tabla 22:
Estadísticas de grupo – Muestras pre y post test
Descriptivos
Estadístico Error estándar
Tiempo Media 8,52554 ,190707
Promedio - PRE 95% de intervalo de Límite inferior 8,10580
confianza para la media Límite superior 8,94528
Media recortada al 5% 8,54514
Mediana 8,62603
Varianza ,436
Desviación estándar ,660627
Tiempo Media 2,05716 ,114848
Promedio - POST 95% de intervalo de Límite inferior 1,80438
confianza para la media Límite superior 2,30994
Media recortada al 5% 2,06623
Mediana 2,10676
Varianza ,158
Desviación estándar ,397845
Fuente: IBM SPSS Versión 26

202
 Muestra Pre Test:
o Media: 8,52554
o Mediana: 8,62603
o Varianza: 0,436
o Desviación estándar: 0,660627

 Muestra Post Test


o Media: 2,05716
o Mediana: 2,10676
o Varianza: 0,158
o Desviación estándar: 0,397845

Prueba de normalidad

Por la cantidad de datos que tenemos (12 datos) en Pre Test y Post Test
respectivamente, las muestras son sometidas a la prueba de normalidad
de Shapiro - Wilk a través programa software IBM SPSS Versión 26, a
fin de verificar si la distribución es normal, es decir, si es paramétrica.
Ver Tabla 23.

Tabla 23:
Prueba de Normalidad para tiempo de transacción por factura de las
muestras Pre Test y Post Test
Pruebas de normalidad
Kolmogorov-Smirnova Shapiro-Wilk
Estadístico gl Sig. Estadístico gl Sig.
Tiempo
Promedio - PRE
,136 12 ,200* ,967 12 ,873
Tiempo
Promedio - POST
,120 12 ,200* ,962 12 ,813
*. Esto es un límite inferior de la significación verdadera.
a. Corrección de significación de Lilliefors
Fuente: IBM SPSS Versión 26

De acuerdo a los resultados obtenidos en la prueba de normalidad de


Shapiro - Wilk podemos determinar que:

203
- Para las muestras Pre Test y Post Test del tiempo de transacción por
factura en el presente estudio, los valores de la Sig. son: 0.873. y
0.813 respectivamente
- Estos valores son mayores que el valor de la significancia 0,05, de
modo que, se acepta la Hipótesis Nula, con lo cual se concluye que los
datos de la muestra Pre Test y Post Test son de una distribución
normal.

 Prueba de Hipótesis

H0: Si se automatiza las tareas con RPA, entonces NO se reducirá el


tiempo en la transacción por factura.
H1: Si se automatiza las tareas con RPA, entonces SI se reducirá el tiempo
en la transacción por factura.

 Prueba de significancia

Dado que los datos son de naturaleza numérica; de muestras


relacionadas, debido a que es el mismo grupo de análisis para la muestra
Pre Test y Post Test; y que, además, ambas muestras provienen de una
distribución normal, se determinó utilizar la Prueba de T de Student de
muestra emparejadas, la cual es una prueba de hipótesis que permite
evaluar si en los resultados hay diferencia de manera significativa
respecto a sus medias.

T de Student de Muestras emparejadas

Para la prueba de T de Student de muestras emparejadas tenemos:


- Estadísticas de muestras emparejadas
- Correlaciones de muestras emparejadas
- Prueba de hipótesis de T de Student de muestras emparejadas

204
En las estadísticas de muestras emparejadas, se puede observar que la
desviación estándar, error promedio, de la muestra Pre Test es 0,190707
y de la muestra Post Test es 0,114848. Ver Tabla 24.

Tabla 24:
Estadísticas de muestras emparejadas para tiempo de transacción por
factura en promedio
Estadísticas de muestras emparejadas
Media N Desv. Desviación Desv. Error promedio

Tiempo Promedio -
8,52554 12 ,660627 ,190707
PRE
Par 1
Tiempo Promedio -
2,05716 12 ,397845 ,114848
POST
Fuente: IBM SPSS Versión 26

En la prueba de hipótesis de T de Student de muestras emparejadas Ver


Tabla 25, se puede observar que la significancia Sig es de 0,000, lo cual
es menor que 0,05, por lo tanto, podemos concluir que se rechaza la
hipótesis nula (H0) y se acepta la hipótesis alterna (H1).

Tabla 25:
Prueba de hipótesis de T de Student de muestras emparejadas para
tiempo de transacción por factura en promedio
Prueba de muestras emparejadas
Diferencias emparejadas
95% de intervalo de
confianza de la
Media
Desv. Desv. Error
diferencia t gl
Sig.
Desviación promedio (bilateral)
Inferior Superior

Tiempo Promedio
PRE
Par 1 6,468376 ,672615 ,194167 6,041017 6,895735 33,313 11 ,000
Tiempo
Promedio POST

Fuente: IBM SPSS Versión 26

Dado que la significancia es igual a 0.000, menor que 0,05 y respetando


el criterio de evaluación, se rechazó la hipótesis nula H 0 y se aceptó la
hipótesis alterna H1, afirmando que existe una diferencia significativa

205
entre el tiempo de transacción por factura en promedio pre test y post test
respectivamente.

Por lo tanto, se llegó a concluir que: Si se automatiza las tareas con RPA,
entonces se reducirá el tiempo en la transacción por factura.

Con lo cual, además, de todo lo antes expuesto se evidencia claramente


que la automatización de las tareas con RPA (variable independiente),
tuvo un efecto positivo y significativo en la reducción del tiempo en la
transacción por factura (variable dependiente).

206
 Hipótesis especificas 02: Si se implementa controles avanzados con RPA,
entonces se reducirá los errores por el registro de
factura.

 Pruebas de Normalidad

 Muestra Pre Test y Post Test:

De acuerdo a lo descrito en el punto 3.2 las muestras para la variable


controles avanzados con RPA son relacionadas por ser las mismas
facturas electrónicas que han sido analizados.

Consta de un total de 12 datos de porcentaje de diagnosis incorrectas en


promedio, en la muestra antes (Pre Test) y en la muestra después (Post
Test), de aplicar la variable independiente en la investigación para esta
primera hipótesis específica. Ver Tabla 26.

Tabla 26:
Muestra Pre Test y Post Test de tiempo de validación por factura
Tiempo de validación por factura en promedio
Muestra Pre Test Muestra Post Test
MES
2019 2020
Enero 858 353
Febrero 831 334
Marzo 862 367
Abril 838 362
Mayo 862 324
Junio 827 315
Julio 886 378
Agosto 897 355
Setiembre 814 316
Octubre 806 312
Noviembre 841 329
Diciembre 894 370
TOTAL 10216 4115
Fuente: SAP HANA. Empresa de la investigación
Elaboración propia

207
 Prueba Pre Test y Post Test

En el cuadro de resumen de procesamiento de casos, obtenido mediante


el software IBM SPSS Versión 26, se verifica que, del total de 12
muestras procesadas, el 100% han sido validadas, es decir, no hubo
ningún dato perdido. Ver Tabla 27.

Tabla 27:
Resumen de procesamiento de datos –tiempo de validación por factura
muestras Pre Test y Post Test
Resumen de procesamiento de casos
Casos
Válido Perdidos Total
N Porcentaje N Porcentaje N Porcentaje
Tiempo de
12 100,0% 0 0,0% 12 100,0%
validación PRE
Tiempo de
12 100,0% 0 0,0% 12 100,0%
validación POST
Fuente: IBM SPSS Versión 26

Estadísticos descriptivos

Con los estadísticos descriptivos podemos contar con un resumen


conciso de los datos para poder analizarlos por tendencia central o por
dispersión. Ver Tabla 28.

Tabla 28:
Estadísticas de grupo – Muestras pre y post test
Descriptivos
Estadístico Error estándar
Media 851,33 8,755
95% de intervalo de Límite inferior 832,06
confianza para la
media Límite superior 870,60
Tiempo de
validación PRE Media recortada al 5% 851,31
Mediana 849,50
Varianza 919,879
Desviación estándar 30,330
Media 342,92 6,879
95% de intervalo de Límite inferior 327,78
confianza para la
media Límite superior 358,06
Tiempo de
validación POST Media recortada al 5% 342,69
Mediana 343,50
Varianza 567,902
Desviación estándar 23,831
Fuente: IBM SPSS Versión 26

208
De la Tabla 28, podemos ver que se ha obtenido las medidas de
tendencia central, así como, como medidas de dispersión, para las
muestras Pre Test y Post Test.

 Muestra Pre Test:


o Media: 851,33
o Mediana: 849,50
o Varianza: 919,879
o Desviación estándar: 30,330
 Muestra Post Test
o Media: 342,92
o Mediana: 343,50
o Varianza: 567,902
o Desviación estándar: 23,831

Prueba de normalidad

Por la cantidad de datos que tenemos (12 datos) en Pre Test y Post Test
respectivamente, las muestras son sometidas a la prueba de normalidad
de Shapiro - Wilk a través del programa software IBM SPSS Versión
26, a fin de verificar si la distribución es normal, es decir, si es
paramétrica. Ver Tabla 29.

Tabla 29:
Prueba de Normalidad para tiempo de validación de facturas de las
muestras Pre Test y Post Test
Pruebas de normalidad
Kolmogorov-Smirnova Shapiro-Wilk
Estadístico gl Sig. Estadístico gl Sig.
Tiempo de
validación ,133 12 ,200* ,948 12 ,602
PRE
Tiempo de
validación ,164 12 ,200* ,910 12 ,214
POST
*. Esto es un límite inferior de la significación verdadera.
a. Corrección de significación de Lilliefors
Fuente: IBM SPSS Versión 26

209
De acuerdo a los resultados obtenidos en la prueba de normalidad de
Shapiro - Wilk podemos determinar que:
- Para las muestras Pre Test y Post Test del porcentaje de diagnosis
incorrectas en el presente estudio, los valores de la Sig. son: 0,602 y
0,214 respectivamente
- Estos valores son mayores que el valor de la significancia 0,05, de
modo que, se acepta la Hipótesis Nula, con lo cual se concluye que
los datos de la muestra Pre Test y Post Test provienen de una
distribución normal.

 Prueba de Hipótesis

H0: Si se implementa controles avanzados con RPA, entonces NO se


reducirá los errores por el registro de factura.
H1: Si se implementa controles avanzados con RPA, entonces SI se
reducirá los errores por el registro de factura.

 Prueba de significancia

Dado que los datos son de naturaleza numérica; de muestras


relacionadas, debido a que es el mismo grupo de análisis para la
muestra Pre Test y Post Test; y que, además, ambas muestras provienen
de una distribución normal.

Se determinó utilizar la Prueba de T de Student de muestras


emparejadas, la cual es una prueba de hipótesis que permite evaluar si
en los resultados hay diferencia estadística de manera significativa
respecto a sus medias.

T de Student de Muestras emparejadas

Para la prueba de T de Student de muestras emparejadas tenemos:


- Estadísticas de muestras emparejadas

210
- Correlaciones de muestras emparejadas
- Prueba de hipótesis de T de Student de muestras emparejadas

En las estadísticas de muestras emparejadas, se puede observar que la


desviación estándar, error promedio, de la muestra Pre Test es 8,755 y
de la muestra Post Test es 6,879. Ver Tabla 30.

Tabla 30:
Estadísticas de muestras emparejadas para validación por factura en
promedio
Estadísticas de muestras emparejadas
Desv. Error
Media N Desv. Desviación
promedio
Tiempo de
851,33 12 30,330 8,755
validación PRE
Par 1
Tiempo de
342,92 12 23,831 6,879
validación POST
Fuente: IBM SPSS Versión 26

En la prueba de hipótesis de T de Student de muestras emparejadas Ver


Tabla 31. Aunque se puede observar que la significancia Sig es de
0,000, debido a que el valor es tan bajo que no se puede visualizar en la
tabla mostrada en SPSS, el valor completo es 5,1867 x 10-10, el cual es
menor que 0,05.

Tabla 31:
Prueba de hipótesis de T de Student de muestras emparejadas para
validación de factura en promedio
Prueba de muestras emparejadas
Diferencias emparejadas
95% de intervalo de
Sig.
Desv. Desv. Error confianza de la t gl
Media (bilateral)
Desviaciónpromedio diferencia
Inferior Superior
Tiempo de
Par validación PRE -
508,41 18,97 5,47 496,36 520,47 92,81 11 ,000
1 Tiempo de
validación POST
Fuente: IBM SPSS Versión 26

Por lo tanto, podemos concluir que se rechaza la hipótesis nula (H 0) y se


acepta la hipótesis alterna (H1)

211
Debido a que el valor de la significancia es 5,1867 x 10 -10, el cual es
menor que 0,05, y respetando el criterio de evaluación, se rechazó la
hipótesis nula H0 y se aceptó la hipótesis alterna H 1, afirmando que
existe una diferencia estadística significativa entre el porcentaje de
diagnosis incorrectas en promedio pre test y post test respectivamente.

Por lo tanto, se llegó a concluir que: Si se implementa controles


avanzados con RPA, entonces se reducirá los errores por el registro de
factura.

Con lo cual, además, de todo lo antes expuesto se evidencia claramente


que la implementación de controles avanzados con RPA (variable
independiente), tuvo un efecto positivo y significativo en la reducción
del registro de factura en el área de pagos (variable dependiente).

212
 Hipótesis especificas 03: Si se rediseña el proceso de registro, entonces se
reducirá las horas de trabajo.

 Prueba de Normalidad

 Muestra Pre Test y Post Test:

De acuerdo a lo descrito en el punto 3.2 las muestras para la variable


rediseñan el proceso de registro son relacionadas por ser las mismas
facturas que han sido analizados.

Consta de un total de 12 datos de las horas de trabajo en promedio, en


la muestra antes (Pre Test) y en la muestra después (Post Test), de
aplicar la variable independiente en la investigación para esta primera
hipótesis específica. Ver Tabla 32.

Tabla 32:
Muestra Pre Test y Post Test de horas trabajadas por Mes
Horas Trabajadas por Mes
Muestra Pre Test Muestra Post Test
MES
2019 2020
Enero 2973.51 699.79
Febrero 2974.86 720.28
Marzo 2973.91 752.15
Abril 2973.84 771.72
Mayo 3185.79 787.52
Junio 3149.05 718.23
Julio 3113.84 722.01
Agosto 3010.58 723.65
Setiembre 3041.63 768.89
Octubre 3134.13 728.99
Noviembre 2993.64 729.97
Diciembre 2997.92 730.08
TOTAL 36522.72 8853.28
Fuente: SAP HANA. Empresa de la investigación
Elaboración propia

 Prueba Pre Test y Post Test

213
En el cuadro de resumen de procesamiento de casos, obtenido mediante
el software IBM SPSS Versión 26, se verifica que, del total de 12
muestras procesadas, el 100% han sido validadas, es decir, no hubo
ningún dato perdido. Ver Tabla 33.

Tabla 33:
Resumen de procesamiento de datos – reducir las horas de trabajo
muestras Pre Test y Post Test
Resumen de procesamiento de casos
Casos
Válido Perdidos Total
N Porcentaje N Porcentaje N Porcentaje
Horas Trabajadas -
12 100,0% 0 0,0% 12 100,0%
PRE
Horas Trabajadas -
12 100,0% 0 0,0% 12 100,0%
POST
Fuente: IBM SPSS Versión 26

Estadísticos descriptivos

Con los estadísticos descriptivos podemos contar con un resumen


conciso de los datos para poder analizarlos por tendencia central o por
dispersión. Ver Tabla 34.

Tabla 34:
Estadísticas de grupo – Muestras pre y post test
Descriptivos
Estadístico Error estándar
Horas Media 3043,5597 22,94621
Trabajad 95% de intervalo de Límite inferior 2993,0554
as - PRE confianza para la media Límite superior 3094,0639
Media recortada al 5% 3039,5498
Mediana 3004,2522
Varianza 6318,344
Desviación estándar 79,48801
Horas Media 737,7735 7,57679
Trabajad 95% de intervalo de Límite inferior 721,0971
as - confianza para la media Límite superior 754,4499
POST Media recortada al 5% 737,1200
Mediana 729,4817
Varianza 688,893
Desviación estándar 26,24678
Fuente: IBM SPSS Versión 26

214
De la Tabla 34 podemos ver que se ha obtenido las medidas de
tendencia central, así como, como medidas de dispersión, para las
muestras Pre Test y Post Test.

 Muestra Pre Test:


o Media: 3043,5597
o Mediana: 3004,2522
o Varianza: 6318,344
o Desviación estándar: 79,48801

 Muestra Post Test


o Media: 737,7735
o Mediana: 729,4817
o Varianza: 688,893
o Desviación estándar: 26,24678

Prueba de normalidad

Por la cantidad de datos que tenemos (12 datos) en Pre Test y Post Test
respectivamente, las muestras son sometidas a la prueba de normalidad
de Shapiro - Wilk a través del programa software IBM SPSS Versión
26, a fin de verificar si la distribución es normal, es decir, si es
paramétrica. Ver Tabla 35.

Tabla 35:
Prueba de Normalidad para reducir las horas de trabajo de las
muestras Pre Test y Post Test
Pruebas de normalidad
Kolmogorov-Smirnova Shapiro-Wilk

Estadístico gl Sig. Estadístico gl Sig.


Horas Trabajadas - PRE ,244 12 ,046 ,822 12 ,017
Horas Trabajadas - POST ,282 12 ,009 ,901 12 ,163
a. Corrección de significación de Lilliefors
Fuente: IBM SPSS Versión 26

215
De acuerdo a los resultados obtenidos en la prueba de normalidad de
Shapiro - Wilk podemos determinar que:
- Para las muestras Pre Test y Post Test del porcentaje de diagnosis
incorrectas en el presente estudio, los valores de la Sig. son: 0,017
y 0,163 respectivamente
- Estos valores son mayores que el valor de la significancia 0,05, de
modo que, se acepta la Hipótesis Nula, con lo cual se concluye
que los datos de la muestra Pre Test y Post Test provienen de una
distribución normal.

 Prueba de Hipótesis

H0: Si se rediseña el proceso de registro, entonces NO se reducirá las


horas de trabajo.
H1: Si se rediseña el proceso de registro, entonces SI se reducirá las
horas de trabajo.

 Prueba de significancia

Dado que los datos son de naturaleza numérica; de muestras


relacionadas, debido a que es el mismo grupo de análisis para la
muestra Pre Test y Post Test; y que, además, ambas muestras provienen
de una distribución normal.

Se determinó utilizar la Prueba de T de Student de muestras


emparejadas, la cual es una prueba de hipótesis que permite evaluar si
en los resultados hay diferencia estadística de manera significativa
respecto a sus medias.

T de Student de Muestras emparejadas

Para la prueba de T de Student de muestras emparejadas tenemos:


- Estadísticas de muestras emparejadas

216
- Correlaciones de muestras emparejadas
- Prueba de hipótesis de T de Student de muestras emparejadas

En las estadísticas de muestras no paramétricas, se puede observar que


la mediana de diferencias entre las horas trabajadas - PRE y horas
trabajadas – POST es igual a 0 Ver Tabla 36.

Tabla 36:
Estadísticas de muestras no paramétricas para reducir las horas de
trabajo en promedio
Resumen de contrastes de hipótesis
Hipótesis nula Prueba Sig. Decisión
La mediana de diferencias
entre Horas Trabajadas -
Prueba de rangos con Rechace la
1
PRE y Horas Trabajadas -
signo de Wilcoxon para ,002
POST es igual a 0.
muestras relacionadas hipótesis nula.
Se muestran significaciones asintóticas. El nivel de significación es de ,050.
Fuente: IBM SPSS Versión 26

Dado que la significancia es igual a 6,314 x 10-10, menor que 0,05 y


respetando el criterio de evaluación, se rechazó la hipótesis nula H 0 y se
aceptó la hipótesis alterna H1, afirmando que existe una diferencia
estadística significativa entre las horas trabajadas por mes en promedio
pre test y post test respectivamente.

Por lo tanto, se llegó a concluir que: Si se implementa se rediseña el


proceso de registro, entonces se reducirá las horas de trabajo.

Con lo cual, además, de todo lo antes expuesto se evidencia claramente


que la implementación se rediseña el proceso de registro (variable
independiente), tuvo un efecto positivo y significativo en la reducción
de las horas de trabajo en el área de pagos (variable dependiente).

217
 Resumen de resultados

Líneas abajo observamos el resumen de los resultados mostrados en esta


investigación Ver Tabla 37.

Tabla 37:
Resumen de resultados
Hipótesis Variables Variables
Indicador Pre- Test Post- Test Diferencia
Especifica Independiente Dependiente

Disminuyó
Proceso de Horas de Horas de 2305.7862
1 3043,5597 737,7735
registro trabajo trabajo
75.8%
Disminuyó
Controles Tiempo de
Registro de 508.41
2 avanzados con validación 851,33 342,92
factura
RPA por factura
59.7%
Disminuyó
Tiempo en la Tiempo de
6.4683
3 Tareas con RPA transacción transacción 8,5255 2,0572
por factura por factura
75.9%
Elaboración: Propia

 En la primera hipótesis se puede ver la disminución del 2305.7862 horas


de trabajo en el proceso de registro al mes al rediseñar el proceso de
registro en el área de pagos, es decir, el sistema basado en rediseñar el
proceso de registro con RPA reduce las horas de trabajo.

 En la segunda hipótesis se puede ver la disminución del 508.41 el tiempo


de validación por factura al mes al implementar controles avanzados con
RPA, es decir, el sistema basado en controles avanzados con RPA reducirá
los errores por el registro por factura.

 En la tercera hipótesis se puede ver la disminución del 6.4683 el tiempo


por transacción por factura al mes al implementar la automatización de
tareas con RPA, es decir, el sistema basado en automatizar las tareas con
RPA reducirá el tiempo en la transacción por factura.

218
CONCLUSIONES Y RECOMENDACIONES

 Conclusiones

1. La aplicación de un sistema de Automatización Robótica de Procesos ha


brindado un gran aporte al área de pagos frente a la creciente cantidad de
facturas electrónicas que procesaban para realizar los pagos a los proveedores
de manera oportuna. El beneficio no solo fue para validar y registrar de manera
automática con alta precisión, si no también se logró reducir el tiempo y el
error humano en la ejecución de las tareas.

2. Con la automatización de las tareas con RPA, se logró reducir el tiempo en la


transacción por factura en 6,68 minutos, representando un ahorro en el tiempo
de transacción por factura de 75.9%.

3. La implementación de controles avanzados con RPA, se logró reducir los


errores por el registro de factura en 508,41 minutos, representando un ahorro
en el tiempo de validación por factura de 59.7%.

4. Al rediseñar el proceso de registro, se logró reducir las horas de trabajo en


2305,79 horas, representando un ahorro en las horas de trabajo de 75.8%

5. Se encontró que esta investigación también ha contribuido a crear un sistema


aplicable a validar facturas electrónicas de los proveedores, además de reducir
el error humano en el proceso, de esa manera el área de pagos puede realizar
los cronogramas de pagos con mayor rapidez.

6. La implementación de diversas arquitecturas de Automatización robótica de


procesos has contribuido a la reducción de facturas electrónicas incorrectas en
más de 80%, y cada algoritmo contribuyo en la precisión de las facturas en
niveles diferentes.

219
7. Se encontró que la arquitectura implementada en la Automatización robótica de
procesos benefició en la reducción de tareas repetitivas y de baja complejidad
que logro reducir la mayor cantidad de facturas electrónicas incorrectos con
una reducción total de 80.70%. Esto demuestra que es la simpleza de su
arquitectura con la inclusión de reconocimiento óptico de caracteres (OCR) que
involucran el procesamiento de documentos y la extracción de información
relevante de ellos con una exactitud del 98%.

8. La implementación de RPA ha tenido un impacto positivo en el ahorro de


tiempo, precisión y consistencia de los procesos empresariales del área de
pagos. Los robots automatizaron tareas repetitivas y manuales, reduciendo el
tiempo y el error humano en la ejecución de las tareas.

9. RPA genero ahorros significativos en términos de costo y tiempo en


comparación con los procesos manuales o la implementación de sistemas
complejos. La automatización robótica de procesos permitió una mayor
productividad y la liberación de recursos humanos para tareas más creativas y
de mayor valor agregado.

10. El porcentaje del costo de hora-humano es de 138% mayor en comparación con


el costo de hora-robot, verificando así que la implementación basada en
Robotic Process Automation genera un ahorro en tiempo para la empresa en
relación al proceso de Validación de facturas electrónicas en el área de pagos.

11. Finalmente se concluye que, RPA es una tecnología en evolución y el


monitoreo continuo y la evaluación del desempeño de los robots son esenciales
para garantizar la eficiencia y la precisión de los procesos empresariales en el
área de pagos.

220
 Recomendaciones

1. En el estudio realizado se demostró que la integración del estado del arte en


Automatización de procesos con robótica orientado a validar y registrar las
facturas electrónicas para el área de pagos. Sin embargo, una vez que se ha
introducido elementos de RPA. En un sistema informático, se enfatiza la
necesidad de una capacitación del personal del área de pagos. En términos de
Skill técnico se recomienda una capacitación al área de T.I. para conocer los
retos presentados en la operación de sistemas con RPA.

2. Con esta solución implementada se recomienda usar este mismo sistema para
la investigación de otros procesos en el área de pagos similares, es decir,
procesos donde la validación pueda ser inferido basado en documentos
electrónicos, por ejemplo, La conciliación bancaria es un proceso importante
para cualquier empresa que desea asegurarse de que sus registros contables
coincidan con los registros bancarios. Es un proceso que implica la
comparación de los saldos de la cuenta bancaria con los registros contables
para garantizar que los saldos sean iguales.

3. Se recomienda expandir la Automatización de procesos con robótica a las


diferentes áreas de la empresa del sector retail como RR.HH., Logística y
Contabilidad quienes también realizan tares repetitivas que les conlleva tiempo
significativos en sus procesos.

4. Se recomienda seguir el marco de trabajo o buenas prácticas para la


implementación de Automatización de Procesos con robótica.

5. Se recomienda que antes de implementación se realice la identificación las


tareas repetitivas y relevantes para la empresa implementar del RPA que
incluye son:

221
 Identificar los procesos adecuados: es importante identificar los
procesos que son adecuados para la automatización mediante la RPA en
dispositivos móviles, teniendo en cuenta factores como la repetitividad
y la cantidad de trabajo manual involucrado.

 Selección de la herramienta adecuada: es importante seleccionar la


herramienta de RPA adecuada para las necesidades específicas de la
empresa y los procesos que se desean automatizar en los dispositivos
móviles.

 Diseñar una interfaz de usuario fácil de usar: se debe diseñar una


interfaz de usuario fácil de usar y optimizada para dispositivos móviles,
lo que ayudará a garantizar una mayor adopción de la RPA por parte de
los trabajadores.

 Asegurar la seguridad de los datos: es importante implementar medidas


de seguridad adecuadas para proteger los datos procesados por la RPA
en los dispositivos móviles.

222
REFERENCIA

Bibliografía

Arizabal, K. V. (2018). SisBot v1.0 para mejorar la gestión de contratación de


personal en la empresa MDP Consulting S.A.C. Peru.

Artto, K. A. (2006). Projektiliiketoiminta (Vol. 2). WSOY.

Bals, L. D. (2015). From offshoring to rightshoring: focus on the backshoring


phenomenon. AIB Insights.

Beath, C. M. (1991). Supporting the information technology champion. MIS quarterly.

Bermejo, J. &. (2014). Innovacion continua al exito empresarial. Madrid: Editorial


digital de la universidad nacional a distancia.

Carhuamaca, J. G. (2017). Sistema que reemplaza funciones de un operador humano


durante la validación de documentos digitales en Core Andina Group. Lima,
Peru.

Castillo, M. R. (2018). Plan de Negocios para determinar la viabilidad del desarrollo


de un asistente virtual de ventas (Chatbot): Caso Gamarra. Lima, Peru.

Cejas Martinez, M. &. (2012). La capacitacion Laboral:Alcances y perspectivas en


tiempos complejos. Universidad de Carabobo.

Chao, G. (2018). La evolución de la automatización de procesos.

Combeller, C. (1993). El nuevo escenario: la cultura de calidad y productividad en las


empresas. Juadalajara: ITESO.

Cooper, R. B. (1990). Information technology implementation research: a


technological diffusion approach. Management science.

Cooper, R. B., & Zmud, R. W. (1990). Information technology implementation


research: a technological diffusion approach. Management science.

Corbin, J. &. (2008). Basics of qualitative research.

223
D´Alesio Ipinza, F. (2012). Administración de las Operaciones Productivas. Mexico:
Pearson.

Davis, N. (2013). Driving quality improvement and reducing technical debt with the
definition of done. In Agile Conference (AGILE),August 2013 (pp. 164-168).
IEEE.

Deming, W. (1989). Calidad, Productividad y competividad: la salida de la crisis.


Madrid: Ediciones Diaz de Santos.

Gonzalez Riesco, M. (2006). Gestion de la Produccion. España.

Hartman, F., & Ashrafi, R. (2002). Project management in the information systems and
information technologies. Project Management Journal.

Hedrick, T. E., Bickman, L., & Rog, D. J. (1993). Applied Research Design: A
Practical Guide. California: Sage Publications Ltd.

HerbertNathan. (2017). Manual and automated process workflow.

Hernandez Rodriguez, S. (2011). Introduccion a la Administracion, origen,evolucion y


vanguardia. Mexico: Mc Graw Hill.

Hernández Sampieri, Fernández Collado, & Baptista Lucio. (2014). Metodología de la


investigación.

Hernández Sampieri, R., Fernádez Collado, C., & Baptista Lucio, P. (12 de 09 de
2014). Metodología de la investigación (Quinta ed.). (M. G. S.A., Ed.) Mexico,
Mexico: Mcgraw Hill.

Hernandez, R. (2010). Metodologìa de la Investigacion.

Instituto Nacional de Estadistica e Informatica en el Peru. (02 de Junio de 2020).


Obtenido de Instituto Nacional de Estadistica e Informatica en el Peru:
https://www.inei.gob.pe/media/MenuRecursivo/boletines/boletin_tics.pdf

Isaca. (2018). Robotic Process Automation(RPA) y la practica de auditoria interna.


Monterrey, Mexico.

Kyheröinen, T. (2018). Implementation of Robotic Process Automation to a Target


Process – a Case Study. Finlandia.

Leidecker, J. K., & Bruno, A. V. (1984). Identifying and using critical success factors.
Long range planning.

224
Lozano, R. M. (2018). Automatización en la recolección, tratamiento y envío de
información estadística médico-asistencial a la Superintendencia Nacional de
Salud (SUSALUD) basado en procesos de ETL y RPA para la clínica
Adventista Ana Stahl. Peru.

Mintzber, H. y. (1997). El proceso Estratégico. Mexico: Karen Bernhaut.

Ñaupas, H., Mejía, E., Novoa, E., & Villagómez, A. (2014). Metodologìa de la
Investigacion. Colombia: Ediciones de la U.

Parr, A., & Shanks, G. (2000). A model of ERP project implementation. Journal of
information Technology.

Pino, G. (2013). Metodologia de la Investigacion(tercera edicion). Lima: San Marcos.

Pinto, J. K., & Slevin, D. P. (1988). Critical Success Factors in Effective Project
implementation. Project management handbook.

Slaby, J. R. (2012). Robotic Automation Emerges as a Threat to Traditional Low-Cost


Outsourcing. HfS Research Ltd.

Somers, T. M., & Nelson, K. (2001). The impact of critical success factors across the
stages of enterprise resource planning implementations. In System Sciences,
2001, January. Proceedings of the 34th Annual Hawaii International
Conference on (pp. 10-pp). IEEE.

Soto, M. F. (2009). Modelo Integral de Productividad. Bogota: Revista EAN Digiprint


Editores.

Taulli, T. (2020). A GUIDE TO IMPLEMENTING RPA SYSTEMS. NEW YORK:


SPRINGER BUSINESS MEDIA.

Trabajo, O. I. (2015). Productividad Laboral.

Wateridge, J. (1995). IT projects: a basis for success. International journal of project


management.

Willcocks, Lacity y Craig. (2015). What knowledge workers stand to gain from
automation. Harvard Business Review.

Willcocks, Lacity y Craig. (2015A). Robotic process automation at Xchanging.

Willcocks, Lacity y Craig. (2015B). The IT function and robotic process.

225
Willcocks, Lacity y Craig. (2016). A new approach to automating services. MIT Sloan
Management Review.

Willcocks, Lacity y Craig. (2016). Robotic Process Automation:The Next


Transformation Lever for Shared Services.

Willcocks, Lacity y Craig. (2017). Robotic process automation: strategic.

226
ANEXOS

Anexo 1: Declaración de Autenticidad

A continuación se muestra el formato de autenticidad y no plagio.

227
Anexo 2: Autorización de consentimiento para realizar la investigación

A continuación se muestra el formato de autorización para realizar la investigación.

228
Anexo 3: Matriz de consistencia

A continuación, se presenta la Matriz de Consistencia utilizada en la investigación del


estudio. (Ver Tabla 38).

Tabla 38:
Matriz de Consistencia
Problemas Variables Indicador Variables
Objetivos General Hipótesis General Indicador V.D.
Principal Independiente V.I. Dependiente

Si se aplica la Robotic
Aplicar la Robotic
Process Automation –
¿Cómo mejorar la Process Automation –
RPA, entonces se
productividad del RPA, para mejorar la Robotic Process
mejorará la Productividad
área de pagos en productividad del Automation – --.-- --.--
productividad del área del área de pago
una empresa del área de pagos en una RPA
de pagos en una
sector retail? empresa del sector
empresa del sector
retail.
retail.

Problemas
Objetivos Específicos Hipótesis Especificas
Especifico

Si se automatiza las
Automatizar las
¿Cómo reducir el tareas con RPA,
tareas con RPA, para Tiempo en la Tiempo de
tiempo en la entonces se reducirá el
reducir el tiempo en Tareas con RPA Si / No transacción por transacción
transacción por tiempo en la
la transacción por factura por factura
factura? transacción por
factura.
factura.

Si se implementa
Implementar
¿Cómo reducir controles avanzados
controles avanzados Controles Tiempo de
los errores por el con RPA, entonces se Registro de
con RPA, para reducir avanzados con Si / No validación
registro de reducirá los errores factura
los errores por el RPA por factura
factura? por el registro de
registro de factura.
factura.

Rediseñar el proceso Si se rediseña el


¿Cómo reducir
de registro, para proceso de registro, Proceso de Horas de
las horas de Si / No Horas de trabajo
reducir las horas de entonces se reducirá registro trabajo
trabajo?
trabajo las horas de trabajo.

Fuente: Elaboración Propia

229
Anexo 4: Matriz de Operacionalización

A continuación, se presenta la Matriz de Operacionalización utilizada en la


investigación del estudio. (Ver Tabla 39).

Tabla 39:
Matriz de Operacionalización
Variable
Indicador Definición Conceptual Definición Operacional
Independiente

El concepto significa reemplazar RPA proporciona las herramientas (software


procesos previamente realizados por y plataforma) para automatizar procesos
humanos, pero esta vez mediante la lógicos basados en reglas que involucran
Tareas con RPA Si / No
configuración de un software robótico datos bien definidos y estructurados con un
para realizar las tareas. (Willcocks, Lacity conjunto determinista de valores de salida.
y Craig, 2015B) (Willcocks, Lacity y Craig, 2016)
Conjunto de herramientas es lo que
llamaré herramientas profesionales de El software se configura más como un
desarrollo de software de TI, como las diagrama de flujo lógico, como una lógica de
herramientas de desarrollo de software solución para un rompecabezas. Por
Controles
(SDK) y las herramientas de gestión de supuesto, de esto se trata
avanzados con Si / No
procesos empresariales (BPM). Estas fundamentalmente la programación, pero
RPA
herramientas requieren habilidades de RPA elimina las sintaxis y los lenguajes,
programación de TI y están codificadas centrándose en la lógica central. (Willcocks,
por profesionales de TI. (Willcocks, Lacity Lacity y Craig, 2015)
y Craig, 2017)
RPA se puede combinar con otras técnicas
Un centro de control de la para crear soluciones sofisticadas de manejo
automatización proporciona una de datos. Un ejemplo es el uso de RPA para
Proceso de estructura y mecanismos de gobernanza extraer información de los documentos de
Si / No
registro para el desarrollo y uso de los activos de OCR para crear metadatos y reducir el
automatización de la información. (Chao, contenido a un formato utilizable para
2018) grandes datos o procesos de aprendizaje
automático. (Chao, 2018)

Variable
Indicador Definición Conceptual Definición Operacional
Dependiente

Es la forma de medir el tiempo de cada


Tiempo en la Tiempo de Implementar controles que permitan reducir
transacción que se demora el humano en
transacción por transacción por el proceso del tiempo de transacción por
registrar la información en el sistema.
factura factura factura pertenecientes al área de pagos.
(Fuente: Definición del autor)

Es el proceso donde la cual el humano


Implementar controles que permitan tener
Tiempo de realiza dichas acciones para recolectar la
Registro de una precisión del proceso con exactitud del
validación por información y realizar el ingreso de
factura 100% de efectividad del registro de factura
factura información en el Sistema. (Fuente:
con su información.
Definición del autor).
La jornada máxima legal prevista en la
Implementar controles que permitan reducir
Constitución Política del Perú es de ocho
el tiempo de procesamiento por factura, con
Horas de trabajo Horas de trabajo (08) horas diarias o de cuarenta y ocho
el beneficio de disminuir las horas de
(48) horas semanales. (Fuente:
sobretrabajo.
Ministerio de Trabajo).
Fuente: Elaboración propia

230
Anexo 5: Tema de Tesis en su idioma original, Implementation of Robotic Process
Automation to a Target Process – a Case Study)

Automatable band

With a solid grasp on the basic meaning of RPA, it is natural to follow with the
question where and when the concept is applicable. As with all automation and
programming, robots need explicit rules to follow, which effectively rules out non-
rule-based processes as feasible for RPA (or any other automation).

RPA and Change Management

RPA is all about replacing humans in performing repetitive tasks, and often
implementing robots is associated with Full Time Equivalent (FTE) savings.
Therefore, it is easy to understand why media uses headlines that speak of
humans losing their jobs to robots, and why people are scared and anxious about
RPA. It is, however, only a misconception: in reality, robots are meant to replace
humans only in the most tedious and repetitive parts of the process, and the
saved FTE can be directed to other tasks which robots cannot handle.

Scalability

An important aspect of RPA is its scalability. RPA is easy to develop compared to


traditional BPM tools, but on top of that, it is more easily scalable. This is crucial
for BPO providers, who already in their business are seeking similar strategies in
their business processes – the ability to define a process and reuse it for multiple
customers.

Roles

A clarification must be made about the roles in the RPA process. While the RPA
literature does not explicitly outline definitive roles involved in RPA development,
there are some that can be distinguished. A RPA developer is responsible for
developing the RPA solution for the target process.

231
Anexo 6: Protocolos o Instrumentos utilizados.

Como parte del protocolo se realizaron los siguientes pasos:

1. Identificación del modelo de datos de SAP Hana DB

2. Identificaron de las tablas y atributos de la información a extraer

3. Elaboración de sentencias sql

4. Ejecución de datos según sentencia sql (Select.)

5. Cálculo de Promedio Mensuales de Facturas.

232
Anexo 7: Formatos de Instrumentos utilizados o protocolos utilizados.

Para la investigación se utilizaron formatos con información PRE (Ver Tabla 40) y
POST (Ver Tabla 41) por cada variable y sus indicadores.

Tabla 40:
Matriz de datos por cada variable PRE
PRE
Tiempo de Tiempo de Horas
transacción validación de
Mes por factura por factura trabajo
Enero 7.07 858 2973.51
Febrero 8.36 831 2974.86
Marzo 8.59 862 2973.91
Abril 8.33 838 2973.84
Mayo 8.87 862 3185.79
Junio 9.62 827 3149.05
Julio 9.11 886 3113.84
Agosto 8.76 897 3010.58
Setiembre 7.80 814 3041.63
Octubre 8.98 806 3134.13
Noviembre 8.13 841 2993.64
Diciembre 8.66 894 2997.92
Fuente: Elaboración propia

Tabla 41:
Matriz de datos por cada variable POST
POST
Tiempo de Tiempo de
transacció validación
n por por Horas de
Mes factura factura trabajo
Enero 1.80 353 699.79
Febrero 1.29 334 720.28
Marzo 2.66 367 752.15
Abril 1.98 362 771.72
Mayo 1.92 324 787.52
Junio 2.03 315 718.23
Julio 2.24 378 722.01
Agosto 2.33 355 723.65
Setiembre 2.35 316 768.89
Octubre 2.18 312 728.99
Noviembre 1.47 329 729.97
Diciembre 2.44 370 730.08
Fuente: Elaboración propia

233
Anexo 8: Tablas de validez y confiabilidad

Con las variables y sus indicadores ya establecidos anteriormente, permite medir,


analizar y verificar los datos, y así obtener la información suficiente y necesaria para el
análisis de los resultados de la investigación. Para ello se desarrolló la matriz de análisis
de datos que se muestra a continuación. (Ver Tabla 42)

Tabla 42:
Matriz de Análisis de datos
Variable Estadísticos
Indicador Escala de medición Análisis inferencial
Dependiente descriptivos

Tiempo en la Tiempo de
Media
transacción transacción por Razón T de student
Mediana
por factura factura

Registro de Tiempo validación Media


Razón T de student
factura por factura Mediana

Horas de Media
Horas de trabajo Razón T de student
trabajo Mediana

Fuente: Elaboración propia

234
Criterio de validez del instrumento

La validez del instrumento, así como, su confiabilidad está dado por ser el líder en el
software de gestión de base de datos, como se puede apreciar en la Figura 52.

Figura 52: Magic Quadrant for Operational Database Management Services.


(Gartner, 2019)

Criterio de confiabilidad de instrumento

Este instrumento al ser válido por Gartner, nos demuestra que en SAP HANA DB se
aprovecha del bajo coste de la memoria principal (RAM), la capacidad del
procesamiento de datos de los procesadores multinúcleo y el acceso rápido a datos de
unidades de estado sólido con respecto a los discos duros tradicionales para ofrecer un
mejor rendimiento de las aplicaciones analíticas y transaccionales.

235
Ofrece un entorno de consulta multi-motor de procesamiento que le permite soportar
tantos datos relacionales (con tanto en fila y columna orientada a representaciones
físicas en un motor híbrido) así como el tratamiento gráfico y de texto para la gestión de
datos no estructurados y semi-dentro del mismo sistema. HANA DB es 100%
compatible con ACID.

Además, según lo dicho por Corral (2009) en su ensayo “Validez y confiabilidad de los
instrumentos de investigación para la recolección de datos”, afirma que para los
instrumentos como por ejemplo, unas listas de cotejos u otros por su naturaleza, no
ameritan el cálculo de la confiabilidad, sin embargo, si es necesario estimar o
comprobar la validez. (p. 241).

236

También podría gustarte