Documentos de Académico
Documentos de Profesional
Documentos de Cultura
ESCUELA DE POSGRADO
TESIS
AUTOR
(ORCID: 0009-0009-7701-3399)
ASESOR
(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 de la investigación
Campo del conocimiento OCDE: 612357
Código del Programa: 1.02.00
Dedicatoria
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
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
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
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%.
8
INTRODUCCIÓN
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.
9
El presente trabajo de tesis se divide de la siguiente manera.
10
CAPÍTULO I: PLANEAMIENTO DEL ESTUDIO
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.
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.
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.
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.
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.
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.
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
“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
18
1.3. Importancia y Justificación del estudio
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.
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.
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.
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.
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.
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?
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.
22
Justificación del estudio
Justificación Teórica
Justificación Metodológica
Justificación Práctica
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
Justificación Legal
Justificación Ecológica
24
1.4. Delimitación del estudio
Delimitación espacial
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
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
b) Implementar controles avanzados con RPA, para reducir los errores por
el registro de factura.
26
CAPÍTULO II: MARCO TEÓRICO
27
de agua) con ayuda de las personas (que construyeron los acueductos). Este mismo
equilibrio marcó el comienzo de la era industrial.
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.
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.
29
abordar necesidades específicas dentro de los procesos de negocio (véase la Figura
08).
30
para aquellos que desean explorar nuevas oportunidades con la automatización
inteligente.
Automatización de la eficiencia
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.
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.
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.
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.
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.
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).
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.
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.
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.
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”.
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.
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.
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.
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.
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.
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".
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
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
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.
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
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:
51
Debido a la problemática mencionada, la presente investigación se
justifica principalmente en el ámbito tecnológico, económico,
social y personal:
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.
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.
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?
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.
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
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.
58
2.3. Estructura teórica y científica que sustenta el estudio
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.
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)
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.
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)
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)
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.
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)
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)
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)
Conjunto de Habilidades
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)
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).
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.
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
68
Para obtener el máximo rendimiento de los robots, deben ser expertos (Willcocks,
Lacity y Craig, 2015A)
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)
Beneficios
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.
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)
Proyectos
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.
La definición de proyecto establece que debe tener una línea de tiempo con un final
y un comienzo (Artto, 2006)
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)
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)
71
del proyecto: por qué es necesario, qué metas y objetivos debería tener. (Pinto, J.
K., & Slevin, D. P., 1988)
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
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.
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).
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
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.
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.
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)
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)
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)
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)
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)
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)
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
Una persona que impulsa el Beath, 1991; Parr et al., 1999; Somers
Proyecto campeón
proyecto & Nelson, 2001
Recursos adecuados y dedicados Pinto & Slevin, 1988; Parr et al., 1999;
Recursos dedicados
asignados al proyecto Somers & Nelson, 2001
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
Elaboración: Propia
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)
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
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
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).
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.
Tabla 05:
Roles en el proceso de RPA.
Rol Descripción
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)
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.
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.
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.
88
Figura 21: Proyecto de ciclo de vida y sus etapas explicadas
Factores de éxito
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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
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:
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)
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.
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.
Esta es la estructura:
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:
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)
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.
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.
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.
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)
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.
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.”
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
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.
111
Fondos
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.
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.
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.
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.
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.
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?
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.
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”.
¿Qué es el CoE?
118
consultora (sin embargo, habrá probablemente sean miembros de la empresa cliente en
el 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.
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.
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.
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
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.
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.
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
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.
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.
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.
“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.
Escalamiento
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
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.
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.
130
La eficacia de las operaciones productivas se la obtiene mediante la relación de los
recursos estimados y los recursos utilizados.
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.
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)
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
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)
Control de la calidad
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 costos
Control de inventarios
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
Producción intermitente
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
RPA
Recopilación de Datos
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)
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)
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.
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
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:
- Capacitación Laboral:
- Investigación y Desarrollo:
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
141
2.5. Fundamentos teóricos que sustentan las hipótesis
Figura 23: Mapa conceptual que sustentan las hipótesis. Elaboración: propia
142
2.6. Hipótesis
143
2.7. Variables
Independiente
Dependiente
Indicadores
Horas de trabajo
Tiempo de validación por factura
Tiempo de transacción por factura
Matriz de Operacionalización
144
CAPÍTULO III: MARCO METODOLÓGICO
Enfoque
Tipo de la investigación
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”.
Método de la investigación
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).
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.
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 …
Tabla 09:
Diseño Cuasi-Experimental
Variable
Objetivo Especifico Hipótesis Especifica Indicador
Dependiente
148
Fuente: Elaboración Propia.
149
3.2. Población y muestra
Población General
“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)
Muestra General
150
que se emplearan por cada una de las variables dependientes planteadas en
esta investigación.
Población
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
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
152
3.3. Técnicas e instrumentos de recolección de datos
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)
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
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.
154
c. Criterio de confiabilidad de instrumento
Tabla 11:
Técnicas e instrumentos
Variable
Indicador Técnica Instrumento
Dependiente
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
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
156
Capítulo IV: RESULTADOS Y ANÁLISIS DE RESULTADOS
4.1. Resultados
Generalidades
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.
158
Tareas con RPA: Aplicar Tareas con RPA para reducir el tiempo en la
transacción por factura.
159
antes de la implementación de una automatización de procesos con robótica
de las tareas con RPA.
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
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.
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.
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).
163
Figura 29: Extracción de PDF de OneDrive Microsoft 365
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.
165
pdfNombre de archivo
pdfAsunto
pdfAutor
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
176
Figura 39: Controles avanzados de RPA para las diferentes plataformas. (Taulli,
2020)
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.
178
Figura 40: Control avanzado RPA para validación de datos de factura electrónica.
Elaboración Propia
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)
180
permitiendo a las organizaciones manejar cargas de trabajo más grandes y
reducir el tiempo de inactividad.
181
Figura 42: Lista de métricas y basado en controles avanzado con RPA. Elaboración
propia
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.
183
30000 facturas electrónicas), estas son las facturas no antes validadas por
los controles avanzados por 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.
185
Proceso de Registro: Aplicar rediseño al proceso de registro para reducir
las horas de trabajo.
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.
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
RPA puede automatizar gran parte de este proceso, lo que permite a los
trabajadores enfocarse en tareas más importantes y de mayor valor.
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.
188
Figura 46: Proceso tradicional y el Proceso de registro con RPA. Elaboración
Propia.
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.
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.
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.
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.
192
Figura 49: Registro de factura en SAP Hana con Automation Anywhere(RPA).
Elaboración propia.
193
Figura 50: Validación y registro de una factura electrónica en SAP Hana.
Elaboración Propia.
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.
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.
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
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.
Para el 2º año:
VTG = ((150000 x 0,6 – 15000 x 0,12)/15000 x 0,12) X 100 % = 4900%
Generalidades
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
Regla de decisión:
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)
Prueba de Hipótesis
Regla de decisión:
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.
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
Tareas con RPA son relacionadas por ser las mismas facturas que han
sido analizados.
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
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
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
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
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
Prueba de significancia
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
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
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.
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
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
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
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.
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
Prueba de significancia
210
- Correlaciones de muestras emparejadas
- Prueba de hipótesis de T de Student de muestras emparejadas
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
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
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.
212
Hipótesis especificas 03: Si se rediseña el proceso de registro, entonces se
reducirá las horas de trabajo.
Prueba de Normalidad
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
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
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.
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
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
Prueba de significancia
216
- Correlaciones de muestras emparejadas
- Prueba de hipótesis de T de Student de muestras emparejadas
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
217
Resumen de resultados
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
218
CONCLUSIONES Y RECOMENDACIONES
Conclusiones
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%.
220
Recomendaciones
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.
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.
222
REFERENCIA
Bibliografía
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.
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.
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.
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.
Ñ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.
Pinto, J. K., & Slevin, D. P. (1988). Critical Success Factors in Effective Project
implementation. Project management handbook.
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.
Willcocks, Lacity y Craig. (2015). What knowledge workers stand to gain from
automation. Harvard Business Review.
225
Willcocks, Lacity y Craig. (2016). A new approach to automating services. MIT Sloan
Management Review.
226
ANEXOS
227
Anexo 2: Autorización de consentimiento para realizar la investigación
228
Anexo 3: Matriz de consistencia
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.
229
Anexo 4: Matriz de Operacionalización
Tabla 39:
Matriz de Operacionalización
Variable
Indicador Definición Conceptual Definición Operacional
Independiente
Variable
Indicador Definición Conceptual Definición Operacional
Dependiente
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 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
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.
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
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
Horas de Media
Horas de trabajo Razón T de student
trabajo Mediana
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.
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