A Tipacti_Trabajo_de_Suficiencia_Profesional_Titulo_Profesional_2021

Vista previa del material en texto

Facultad de Ingeniería 
Carrera de Ingeniería de Sistemas e Informática 
Programa Especial de Titulación 
“Implementación de una Automatización 
Robótica de Procesos para la mejora del 
procesamiento de las Cuentas por Pagar en 
Corporación Sapia” 
 
Bachiller: 
Tipacti García, Armando 
 
Para obtener el Título Profesional de 
Ingeniero de Sistemas e Informática 
 
Asesor: Andrade Arenas, Laberiano Matías 
 
Lima, agosto 2021 
I 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DEDICATORIA 
A mis padres Luis y Luzmila quienes 
siempre me brindan su apoyo 
incondicional, sacrificaron mucho de 
sus vidas para que yo pudiera construir 
la mía y son los pilares del 
cumplimiento de mis metas, es por ello 
les dedico todos mis triunfos. 
Armando Tipacti García 
II 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AGRADECIMIENTO 
Mi total agradecimiento al Ing. 
Andrade Arenas, Laberiano Matías, mi 
asesor, por brindarme su apoyo y guía 
para la elaboración y culminación del 
presente informe. 
Armando Tipacti García 
 
III 
 
RESUMEN 
 
El presente trabajo es sobre la implementación de una automatización robótica de proceso 
(RPA) de las cuentas por pagar en el área contable de Corporación Sapia. La herramienta 
seleccionada para el desarrollo del robot es Uipath por ser muy intuitiva para la elaboración del 
robot y fácil en aprendizaje. Se utiliza la metodología hibrida que es la integración de las mejores 
prácticas de la sexta edición del PMBOK para la gestión del proyecto y bajo el marco ágil de 
Scrum para la ejecución del producto. La implementación tiene un impacto favorable por que se 
logra reducir el tiempo en los registros, aumentar el porcentaje de aceptación de los documentos 
registrados y ahorros de los costos en trabajos operativos, en las cuales el recurso humano podrá 
invertir el tiempo destinado a la operativa y trabajo repetido hacia una labor de mayor análisis o 
de alta trascendencia para la organización. 
 
IV 
 
ABSTRACT 
 
This job is about the implementation of a robotic process automation (RPA) of accounts 
payable in the accounting area in the Sapia Corporation. The selected tool is the Uipath for being 
very intuitive and easy to learn. The hybrid methodology is used that are under the good 
practices of the PMBOK 6th edition for the management of the project and under the agile 
framework of Scrum for the execution of the product. The implementation has a favorable 
impact because it is possible to reduce the time in the records, increase the acceptance percentage 
of the registered documents and cost savings in operational work, in which the human resource 
will be able to invest the time allocated to the operation, repeated work towards a major or highly 
significant analysis work. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
V 
 
INDICE 
INTRODUCCION ................................................................................................................ XV 
1. CAPÍTULO I ASPECTOS GENERALES .................................................................. 10 
1.1. Diagnóstico de la organización .............................................................................. 10 
1.1.1. Datos de la organización .................................................................................... 10 
1.1.2. Localización de la institución ............................................................................. 11 
1.1.3. Diagnóstico estratégico ...................................................................................... 12 
1.2. Definición del problema ......................................................................................... 14 
1.2.1. Planteamiento y descripción del problema .......................................................... 14 
1.2.2. Formulación del problema general ..................................................................... 15 
1.2.3. Formulación de los problemas específicos .......................................................... 15 
1.3. Objetivos del proyecto ........................................................................................... 15 
1.3.1. Objetivo general ................................................................................................. 15 
1.3.2. Objetivos específicos ......................................................................................... 15 
1.4. Justificación de la investigación............................................................................. 16 
1.4.1. Justificación técnica ........................................................................................... 16 
1.4.2. Justificación económica ..................................................................................... 17 
1.4.3. Justificación social ............................................................................................. 17 
1.5. Alcances y limitaciones .......................................................................................... 18 
2. CAPÍTULO II MARCO TEÓRICO .......................................................................... 19 
2.1. Fundamento Teórico .............................................................................................. 19 
2.1.1. Estado del Arte .................................................................................................. 19 
2.1.2. Base Teórica ...................................................................................................... 21 
2.2. Marco Conceptual ................................................................................................. 60 
VI 
 
2.2.1. Bot ..................................................................................................................... 60 
2.2.2. Bots atendidos .................................................................................................... 61 
2.2.3. Bots desatendidos............................................................................................... 61 
2.2.4. Interfaz de sistema ............................................................................................. 61 
2.2.5. Asistente Uipath ................................................................................................. 61 
2.2.6. RPA ................................................................................................................... 61 
2.2.7. Inteligencia artificial .......................................................................................... 62 
2.2.8. Licencia ............................................................................................................. 62 
2.2.9. Orden de Compra ............................................................................................... 62 
2.2.10. Buenas prácticas ............................................................................................. 62 
2.2.11. Requisición de compra ................................................................................... 62 
2.2.12. Facturas.......................................................................................................... 63 
2.2.13. Boleta............................................................................................................. 63 
2.2.14. Notas de Debito.............................................................................................. 63 
2.2.15. Historias de usuario ........................................................................................ 63 
2.2.16. Stakeholders ................................................................................................... 63 
2.2.17. Planning Pocker ............................................................................................. 63 
2.2.18. Criterios de aceptación ................................................................................... 64 
2.3. Marco Metodológico ..............................................................................................64 
2.3.1. Selección de la metodología ............................................................................... 64 
2.3.2. Desarrollo de la metodología mixta .................................................................... 71 
3. CAPITULO III: DESARROLLO DE LA SOLUCIÓN ............................................. 79 
3.1. Fase de Inicio ........................................................................................................ 79 
VII 
 
3.1.1. Análisis de la problemática ................................................................................ 79 
3.1.2. Definición del acta de constitución ..................................................................... 80 
3.1.3. Identificación de interesados .............................................................................. 86 
3.2. Fase de Planificación ............................................................................................ 89 
3.2.1. Entrevista a los interesados ................................................................................ 89 
3.2.2. Análisis del alcance ............................................................................................ 89 
3.2.3. Análisis de los riesgos ........................................................................................ 97 
3.2.4. Elaboración del cronograma de actividades ........................................................ 98 
3.3. Fase de Ejecución .................................................................................................. 99 
3.3.1. Sprint 0 .............................................................................................................. 99 
3.3.2. Sprint 1 ............................................................................................................ 112 
3.3.3. Sprint 2 ............................................................................................................ 143 
3.3.4. Sprint 3 ............................................................................................................ 154 
3.3.5. Certificación general QA.................................................................................. 166 
3.3.6. Lanzamiento .................................................................................................... 168 
3.4. Fase de Cierre ..................................................................................................... 171 
3.4.1. Acta de Cierre de Proyecto ............................................................................... 171 
4. CAPITULO IV: RESULTADOS Y PRESUPUESTO ............................................. 173 
4.1. Resultados ........................................................................................................... 173 
4.1.1. Objetivos específicos ....................................................................................... 173 
4.2. Presupuesto ......................................................................................................... 176 
4.2.1. Recursos Humanos ........................................................................................... 176 
4.2.2. Software........................................................................................................... 177 
VIII 
 
4.2.3. Hardware ......................................................................................................... 177 
4.2.4. Presupuesto ...................................................................................................... 177 
4.2.5. Análisis de beneficios ...................................................................................... 178 
CONCLUSIONES ................................................................................................................. 181 
RECOMENDACIONES ....................................................................................................... 183 
BIBLIOGRAFÍA ................................................................................................................... 184 
ANEXOS ............................................................................................................................... 187 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
IX 
 
INDICE DE TABLAS 
Tabla 1 Cuadro comparativo basado en características de las herramientas de RPA .................. 25 
Tabla 2 Cuadro comparativo en aspectos técnicos de las herramientas del RPA ........................ 27 
Tabla 3 Resumen de los procesos fundamentales de Scrum ...................................................... 52 
Tabla 4 Comparativa de grupo de criterios según procesos (1). ................................................. 65 
Tabla 5 Comparativa de grupo de criterios según procesos (2). ................................................. 66 
Tabla 6 Comparativa de grupo de criterios según personas ....................................................... 67 
Tabla 7 Comparativa de grupo de criterios según organización y proyectos. ............................. 68 
Tabla 8 Actividades de la fase de inicio .................................................................................... 72 
Tabla 9 Actividades de la fase de planificación......................................................................... 74 
Tabla 10 Fase de ejecución ....................................................................................................... 76 
Tabla 11 Fase de Cierre ............................................................................................................ 79 
Tabla 12 Acta de constitución del proyecto .............................................................................. 80 
Tabla 13 Registro de StakeHolders ........................................................................................... 86 
Tabla 14 Matriz de registro de interesados ................................................................................ 89 
Tabla 15 Plan de gestión del alcance ........................................................................................ 89 
Tabla 16 Diccionario de la EDT del proyecto ........................................................................... 96 
Tabla 17 Matriz de historias de usuario .................................................................................. 102 
Tabla 18 Planing poker ........................................................................................................... 105 
Tabla 19 Matriz del product backlog ...................................................................................... 105 
Tabla 20 Matriz de tareas de historias de usuario del Sprint 1 ................................................. 106 
Tabla 21 Matriz tareas de historias de usuario del Sprint 2...................................................... 108 
Tabla 22 Matriz de tareas de historias de usuario del Sprint 3 ................................................. 110 
X 
 
Tabla 23 Criterios de aceptación HU-001 - Ingresar al sistema contable ................................. 112 
Tabla 24 Criterios de aceptación HU-002 - Ingresar a la empresa de Corporación Sapia ......... 113 
Tabla 25 Criterios de aceptación. HU-003 - Registrar las facturas de los proveedores ............. 114 
Tabla 26 Criterios de aceptación. HU-007 - Notificar las facturas registradas con éxito .......... 116 
Tabla 27 Criterios de aceptación. HU-008 - Notificar las facturas que no son registradas ....... 117 
Tabla 28 Consolidado de pruebas del Sprint 1 ........................................................................ 138 
Tabla 29 Acta de retrospectiva del sprint 1 ............................................................................. 142 
Tabla 30 Criterios de aceptación HU-004 - Registrar las boletas de los proveedores ............... 143 
Tabla 31 Criterios de aceptación HU-009 - Notificar las boletas registradas con éxito ............ 145 
Tabla 32 Criteriosde aceptación. HU-010 - Notificar las boletas que no son registradas ......... 146 
Tabla 33 Consolidado de pruebas del Sprint 2 ........................................................................ 150 
Tabla 34 Acta de retrospectiva del sprint 2 ............................................................................. 153 
Tabla 35 Criterios de aceptación. HU-005 - Registrar las notas de débito de los proveedores.. 154 
Tabla 36 Criterios de aceptación. HU-011 - Notificar las notas de débito registradas con éxito
 ............................................................................................................................................... 156 
Tabla 37 Criterios de aceptación HU-012 - Notificar las notas de débito que no son registradas
 ............................................................................................................................................... 157 
Tabla 38 Consolidado de pruebas del Sprint 3 ........................................................................ 160 
Tabla 39 Acta de la retrospectiva del sprint 3 ......................................................................... 164 
Tabla 40 Acta de puesta en producción ................................................................................... 169 
Tabla 41 Acta del cierre del proyecto ..................................................................................... 171 
Tabla 42 Detalle de la comparación entre el trabajo manual vs el RPA ................................... 173 
Tabla 43 Métrica Tiempo de ejecución del proceso ................................................................ 175 
XI 
 
Tabla 44 Presupuesto de recursos humanos ............................................................................ 176 
Tabla 45 Presupuesto de Software .......................................................................................... 177 
Tabla 46 Presupuesto hardware .............................................................................................. 177 
Tabla 47 Presupuesto general ................................................................................................. 177 
Tabla 48 Beneficio tangible .................................................................................................... 178 
Tabla 49 Costos variables después de la implementación........................................................ 179 
Tabla 50 Flujo de Caja por 12 meses, expresado en moneda soles .......................................... 179 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
XII 
 
INDICE DE FIGURAS 
Figura 1 Ubicación geográfica de Corporación Sapia. .............................................................. 11 
Figura 2 Organigrama Sapia. .................................................................................................... 13 
Figura 3 Grupo de procesos de inicio ....................................................................................... 30 
Figura 4 Grupo de procesos de planificación ............................................................................ 31 
Figura 5 Grupo de procesos de ejecución ................................................................................. 32 
Figura 6 Grupo de procesos de monitoreo y control.................................................................. 34 
Figura 7 Grupo de procesos de cierre ....................................................................................... 35 
Figura 8 Relación del grupo de procesos y áreas del conocimiento ........................................... 36 
Figura 9 Descripción general de la gestión de integración ........................................................ 38 
Figura 10 Descripción general de la gestión del alcance ........................................................... 41 
Figura 11 Descripción general de la gestión del cronograma .................................................... 44 
Figura 12 Descripción general de la gestión de los riesgos ....................................................... 48 
Figura 13 Estructura de la organización del Scrum ................................................................... 51 
Figura 14 Los cinco flujos de trabajo de RUP........................................................................... 55 
Figura 15 Rangos de Criticidad por metodología ...................................................................... 70 
Figura 16 Macroproceso de la metodología para el proyecto .................................................... 72 
Figura 17 Proceso actual del registro de las cuentas por pagar .................................................. 80 
Figura 18 Matriz Poder - Interés ............................................................................................... 87 
Figura 19 Matriz de Prominencia ............................................................................................. 88 
Figura 20 Matriz de involucramiento de interesados ................................................................. 88 
Figura 21 EDT del proyecto ..................................................................................................... 95 
Figura 22 Matriz de probabilidad e impacto ............................................................................. 97 
Figura 23 Matriz de riesgos del proyecto .................................................................................. 98 
XIII 
 
Figura 24 Arquitectura de la solución ..................................................................................... 100 
Figura 25 Nuevo proceso de las cuentas por pagar.................................................................. 101 
Figura 26 IDE del UIpath, para crear la solución .................................................................... 119 
Figura 27 IDE de la herramienta UIPath ................................................................................. 119 
Figura 28 Diagrama de actividades de ingresar al sistema contable ........................................ 120 
Figura 29 Desarrollo del ingreso al sistema contable – Parte 1 ................................................ 121 
Figura 30 Desarrollo del ingreso al sistema contable – Parte 2 ................................................ 122 
Figura 31 Diagrama de actividades de seleccionar empresa .................................................... 123 
Figura 32 Desarrollo de seleccionar empresa .......................................................................... 124 
Figura 33 Diagrama de actividades registrar factura – Parte I ................................................. 125 
Figura 34 Diagrama de actividades registrar factura – Parte I ................................................. 126 
Figura 35 Desarrollo del registro de factura en Uipath – Parte 1 ............................................. 127 
Figura 36 Desarrollo del registro de factura en Uipath – Parte 2 ............................................. 128 
Figura 37 Desarrollo del registro de factura en Uipath – Parte 3 ............................................. 129 
Figura 38 Desarrollo del registro de factura en Uipath – Parte 4 ............................................. 130 
Figura 39 Desarrollo del registro de factura en Uipath – Parte 5 ............................................. 131 
Figura 40 Desarrollo del registro de factura en Uipath – Parte 6 ............................................. 132 
Figura 41 Desarrollo del registro de factura en Uipath – Parte 7 ............................................. 133 
Figura 42 Desarrollo del registro de factura en Uipath – Parte 8 ............................................. 134 
Figura 43 Desarrollo notificar registro de factura ................................................................... 135 
Figura 44 Desarrollo notificar error del registro de factura – Parte 1 ....................................... 136 
Figura 45 Desarrollonotificar error del registro de factura – Parte 2 ....................................... 137 
Figura 46 Burndown chart del sprint 1 ................................................................................... 138 
XIV 
 
Figura 47 Burndown chart del sprint 2 ................................................................................... 149 
Figura 48 Burndown chart del sprint 3 ................................................................................... 159 
Figura 49 Registro de factura de servicios ............................................................................. 166 
Figura 50 Registro de facturas de bienes ................................................................................ 167 
Figura 51 Registro de factura del exterior .............................................................................. 168 
Figura 52 Comparación de RPA vs Registro manual de las cuentas por pagar ........................ 174 
Figura 53 Cantidad de recursos humanos vs el RPA ............................................................... 175 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
XV 
 
INTRODUCCION 
 
El presente proyecto se centra en la automatización robótica de procesos denominada 
RPA que se puede definir como una tecnología de la informática que permite crear robots de 
software que aprenden y emiten las mismas acciones que realiza el ser humano con los sistemas 
digitales. 
La característica principal del RPA es que interactúa con interfaces gráficas de los 
sistemas y aplicaciones, pueden operar las 24 horas, cero márgenes de error en sus procesos, 
costos muy favorables en su implementación y un retorno de inversión a corto plazo, es una 
tecnología necesaria para toda organización porque es la fuerza de trabajo digital. 
En Corporación Sapia en el área contable tienen la problemática que existe mucho trabajo 
operativo en el registro de las cuentas por pagar, pérdida de tiempo con los registros que al 
realizarlo de forma manual toma un aproximado de 10 min por registro, es por ello el presente 
proyecto tiene el objetivo general de implementar la automatización robótica de procesos para 
mejorar el procesamiento de las cuentas por pagar de Corporación Sapia. 
La metodología que se usará es la hibrida que consiste en la utilización de las mejores 
prácticas del Pmbok 6ta edición y se realizó una selección de la metodología para la fase de 
ejecución, según el autor Espinoza (2013), es posible seleccionar con mayor certeza el marco 
Scrum para la fase de ejecución y desarrollo del producto. 
Para el desarrollo del robot se utilizará la herramienta Uipath por ser una plataforma que 
es muy intuitiva para el desarrollo, fácil en su aprendizaje, escalable y permite reducir el tiempo 
de implementación.
10 
 
1. CAPÍTULO I 
ASPECTOS GENERALES 
1.1. Diagnóstico de la organización 
1.1.1. Datos de la organización 
A. Razón Social: Corporación Sapia S.A. 
B. Nombre Comercial: Sapia. 
C. Tipo de empresa: Sociedad anónima. 
D. Giro del Negocio: Actividades relacionadas con los servicios de tecnologías de la 
información. 
E. RUC: 20100083362 
F. Teléfono: 012154530 
G. Ubicación: Av. Ricardo Rivera Navarrete Nro.501 Int. 23 
H. Fecha de inicio de actividades: 15/03/1984 
I. Reseña histórica: 
En 1984 Cosapi S.A. funda Cosapi Data S.A. que se convierte en el primer distribuidor 
de computadoras personales de IBM. 
En el 2013 Cosapi vende Cosapi Data al grupo inversor Altra Investments. 
En el 2017 la empresa peruana Cosapi Data cambia de nombre a Sapia. El nombre Sapia 
proviene de la palabra latina sapiencia o sabiduría. El nuevo nombre de la empresa encarna los 
factores de éxito de la empresa pues son 37 años de experiencia en la vida organizacional, 
ingenio e innovación para desarrollar soluciones integradas con alto valor agregado. 
Cosapi Data ha evolucionado de ser un integrador de hardware y software, para 
convertirse hoy en un proveedor de soluciones comerciales en la actualidad. La transición 
11 
 
comenzó en 2013 luego de que el grupo de inversión Altra adquiriera Cosapi Data. Desde 
entonces, los modelos económicos se han innovado, desarrollado y mejorado gracias a diversas 
capacidades tecnológicas y organizativas. Es un proceso continuo, no una transacción completa, 
pero hay mucho que decir. 
1.1.2. Localización de la institución 
Corporación Sapia tiene su sede en av. Ricardo Rivera Navarrete N° 501, piso 23, San 
Isidro, Lima, Perú. 
Figura 1 
Ubicación geográfica de Corporación Sapia. 
 
Nota: Ubicación geográfica de la sede central de Corporación Sapia. Fuente: Google Maps. 
 
12 
 
1.1.3. Diagnóstico estratégico 
1.1.3.1. Misión 
Mejorar la competitividad de los clientes brindando soluciones y servicios innovadores de 
alto valor agregado en tecnologías de la información y las comunicaciones basados en los más 
altos estándares de calidad, excelencia y perfección. 
1.1.3.2. Visión 
Ser reconocidos por el mercado y nuestros clientes como el socio estratégico más 
relevante para innovar y transformar sus negocios, atrayendo y desarrollando al mejor talento, 
asegurando un crecimiento rentable y sostenible para los accionistas. 
13 
 
1.1.3.3. Organigrama estructural de Sapia 
Figura 2 
Organigrama Sapia. 
 
Nota: Organigrama Sapia. Fuente: (Sapia,2020). 
 
14 
 
1.2. Definición del problema 
1.2.1. Planteamiento y descripción del problema 
En la actualidad el mundo empresarial es cada vez más competitivo, Silva (2017) señala 
que las empresas que logren un mejor posicionamiento y conquista del mercado son las que 
entreguen un valor agregado a las soluciones que cubren las necesidades de sus clientes. 
Corporación Sapia está siempre buscando desarrollar, incrementar y adquirir nuevas 
tecnologías para el mejoramiento de sus procesos internos, para este informe de estudio se está 
considerando uno de los procesos del área contable que es las cuentas por pagar donde se realiza 
el registro de las facturas, boletas y notas de débitos de proveedores en el software de 
contabilización de Sapia y que a menudo ocurren situaciones perjudiciales e inesperadas en 
ciertas etapas del proceso del registro de las cuentas por pagar. 
Estas situaciones inesperadas provocan efectos negativos, por ejemplo, no realizar los 
pagos a proveedores en tiempo y forma, generando intereses innecesarios. Al existir una mala 
relación con los proveedores que nos brindan su servicio o bien pues no se podrá negociar las 
mejores condiciones de pago por lo cual no se podrá obtener ese beneficio para la organización. 
Generalmente, los proveedores envían las facturas, boletas, notas de débito de los bienes 
vendidos o servicios prestados para Sapia mediante el portal de proveedores que es una 
aplicación web elaborado por Sapia, mesa de partes evalúa el registro de los documentos y los 
que son observados el portal de proveedores le notifica al proveedor para que pueda levantar la 
observación y los aprobados están listos para ser registrados por los asistentes contables de 
Sapia. 
En el transcurso del registro de las cuentas por pagar, los documentos aprobados por 
mesa de partes, el personal debe realizar el registro de los datos de forma manual en el sistema 
15 
 
contable de Sapia, esta tarea es repetitiva, lenta y propensa a errores producto del cansancio 
humano por realizar tareas rutinarias durante todo el día laboral y por consecuente Sapia está 
presentando inconvenientes en la gestión de las cuentas por pagar tales como retrasos de realizar 
los pagos de proveedores e impactos negativos en desarrollo del flujo de caja. 
1.2.2. Formulación del problema general 
¿Cómo se debe implementar una automatización robótica de procesos para la mejora del 
procesamiento de las cuentas por pagar en Corporación Sapia? 
1.2.3. Formulación de los problemas específicos 
P.E.1: ¿De qué manera se debe analizar el proceso del negocioy del sistema donde se 
realiza el procesamiento de las cuentas por pagar? 
P.E.2: ¿Cómo se debe de diseñar la propuesta que permita automatizar el procesamiento 
de las cuentas por pagar de manera eficiente? 
P.E.3: ¿De qué manera se debe desarrollar el proceso establecido en la propuesta para la 
automatización robótica del procesamiento de las cuentas por pagar? 
P.E.4: ¿Cómo se debe evaluar el desarrollo de la automatización robótica del 
procesamiento de las cuentas por pagar? 
1.3. Objetivos del proyecto 
1.3.1. Objetivo general 
Implementar una automatización robótica de procesos para la mejora del procesamiento 
de las cuentas por pagar en Corporación Sapia. 
1.3.2. Objetivos específicos 
O.E.1: Analizar el proceso del negocio y del sistema donde se realiza el procesamiento 
de las cuentas por pagar. 
16 
 
O.E.2: Diseñar la propuesta que permita automatizar el procesamiento de las cuentas por 
pagar de manera eficiente. 
O.E.3: Desarrollar el proceso establecido en la propuesta para la automatización robótica 
del procesamiento de las cuentas por pagar. 
O.E.4: Evaluar el desarrollo de la automatización robótica del procesamiento de las 
cuentas por pagar. 
1.4. Justificación de la investigación 
Este proyecto se realizó con el objetivo de mejorar el proceso de las cuentas por pagar 
que involucra una cantidad importante de tareas manuales con poco o ningún juicio de valor, 
eliminar el trabajo manual, aumentar la eficiencia y mitigar los riesgos que pueden ocurrir 
durante el proceso de las cuentas por pagar, evitando costos innecesarios, retrasos y fallas que 
impactan directamente en las etapas de la vida del proceso. De esta manera, el equipo contable, 
especialmente el auxiliar contable que realiza el registro de los documentos puede ejercer una 
mejor gestión sobre las cuentas por pagar. 
Además, el logro de esta investigación sobre el software RPA es que a futuro puede 
iniciar próximas automatizaciones de procesos en otros departamentos de la Corporación Sapia 
de las cuales se pueden encontrar tareas repetitivas en sus procedimientos y trabajos con 
excesivos datos. 
1.4.1. Justificación técnica 
Este software RPA consiste en reemplazar al trabajador humano por un robot de software 
en la que puede trabajar durante las 24 horas del día, procesar mucha información minimizando 
riesgos de error, aumentando la velocidad de respuesta e interactuando directamente con los 
softwares de la empresa a nivel de código y a nivel de interfaz. 
17 
 
No se requiere de modificaciones ni sustituciones del actual sistema contable que utiliza 
Sapia, pues este software RPA será fácilmente adaptable a las herramientas que se utilicen 
durante el proceso de las cuentas por pagar. 
Uno de los principales beneficios del software RPA es que es flexible y simple porque no 
necesita invertir muchas horas codificando en algún tipo de lenguaje de programación, eso quiere 
decir que no es necesario tener alto grado de conocimientos de programación para dominar las 
herramientas de RPA. Cualquier proceso de poco a muy complejo que exista en las 
organizaciones se puede realizar la automación en software RPA con poco esfuerzo. 
1.4.2. Justificación económica 
Implementar el sistema de automatización que emule el trabajo humano permitirá la 
reducción de costos ya que se requiere menos personal en tareas repetitivas y tediosas en el 
registro de las cuentas por pagar permitiendo direccionar el talento humano en actividades de 
mayor valor para la empresa. 
El software RPA tiene la cualidad de generar una progresiva disminución de errores, al 
no ser invasiva no existe el riesgo de afectar a la operatividad y al mismo tiempo incide sobre un 
ahorro de los costos económicos que provienen de los errores manuales. 
1.4.3. Justificación social 
Las automatizaciones basadas en RPA son consideradas parte de la cuarta revolución 
industrial porque es la evolución de la fuerza laboral dentro de las organizaciones. Implementar 
un software robótico significará extraer la parte robotizada del ser humano para trasladar esa 
secuencia de actividades a un computador donde se encuentre instalado el robot y que este 
ejecute estrictamente de acuerdo las reglas establecidas y bajo las mejores prácticas. 
18 
 
Los empleados de Sapia se interesan e involucran más con los objetivos de la 
organización cuando pueden enfocarse en actividades de alto valor agregado, lejos de actividades 
aburridas y repetitivas. 
1.5. Alcances y limitaciones 
Dentro del alcance del proyecto de automatización robótica de procesos cumple con los 
siguientes criterios: 
• El proyecto contemplará el registro de las facturas, boletas, notas de débito de 
proveedores provenientes de proyectos de la empresa Sapia. 
• Tendrá cambios en el proceso, pero no aumentará la complejidad. 
• La propuesta de automatización robótica de procesos hará uso de las aplicaciones 
corporativas de Sapia como el sistema contable, correos electrónicos y el portal de proveedores 
donde se encuentra los documentos cargados por los proveedores tales como facturas, boletas 
notas de débito, orden de compra y sustentos. 
Dentro de los límites del software robótica de procesos se indican las siguientes: 
• El único medio de comunicación para realizar el registro de las cuentas por pagar 
por parte del proveedor y Sapia será mediante el portal de proveedores de Sapia. 
 
 
 
 
 
 
 
19 
 
2. CAPÍTULO II 
MARCO TEÓRICO 
2.1. Fundamento Teórico 
2.1.1. Estado del Arte 
Es importante entender que es RPA y para ello Vajgel et al. (2021) en su trabajo sostiene 
que la automatización robótica de procesos (RPA) automatiza a las aplicaciones tradicionales de 
tecnologías de la información en base a un software de robot con capacidad de capturar e 
interpretar los procesos puntuales de las organizaciones, reduciendo los recursos y optimizando 
los procesos eficazmente. Además, Malathi et al. (2021) indica que la implementación de las 
automatizaciones de procesos organizacionales es una tecnología basada en robots de software 
instaladas en las computadoras de los empleados. 
Los problemas que el RPA pueden resolver son variados, Vajgel et al. (2021) en su 
trabajo plantea que en una empresa del sector de energía eléctrica de Brasil existe muchas 
llamadas sobre quejas por cortes de energía, esto genera mucho tiempo invertido por el personal 
de gestionar las llamadas de los clientes en el centro de contacto de la empresa. Además, Malathi 
et al. (2021) sostiene que a mucha gente no le toma mucho tiempo en descargar uno o dos 
archivos de Internet, pero ¿Qué pasaría si hay la necesidad de descargar más archivos 
manualmente? Sumado a lo anterior, Qiu y Xiao (2020) exponen que los problemas de datos 
actuales entre sistemas no se pueden recopilar automáticamente, la contabilidad sobre los costos 
no es oportuna y el informe de análisis de costos es constantemente arreglado manualmente. 
La implementación de la automatización robótica de procesos se puede aplicar a 
cualquier proceso, pero en cuanto a el diseño puede diferir, en este sentido, Vajgel et al. (2021) 
propone en su trabajo un robot de notificaciones proactivas inteligentes para clasificar y priorizar 
20 
 
a los clientes con mayor probabilidad de quejas. Qiu y Xiao (2020) en su trabajo diseñan el robot 
que principalmente proporciona optimización a partir de la recopilación automática de datos del 
sistema gestión de inventarios a través del escaneo y reconocimiento de imágenes para realizar la 
indexación de datos de la información del documento e interconectado con el software de 
procesamiento financiero para realizar la recopilación y acoplamiento perfecto de los datos entre 
sistemas, formando un ciclo cerrado completo de los datos contables. Wojciechowska-Filipek 
(2019) en su texto plantea la automatización en registrar la consulta de secreto bancario en el 
sistema relacionado con elprocesamiento de datos y tramitación de la propia solicitud (cesión, 
análisis formal y legal, envíos de respuesta de solicitud). 
Las etapas de desarrollo que ha considerado Vajgel et al. (2021) en su proyecto consistió 
en la gestión de datos, modelos predictivos y pruebas de los componentes periféricos para enviar 
SMS y realizar llamadas. Además, Wojciechowska-Filipek (2019) ha considerado las etapas 
análisis de la situación actual y propuesta, construcción, implementación y pruebas. 
Los resultados indican según Vajgel et al. (2021) que los clientes llamados 
anticipadamente por un corte de energía no volvieron comunicarse con el centro de atención de 
telefonía de la empresa de energía eléctrica concluyendo que el robot es capaz de predecir 
problemas y de realizar envío de notificaciones proactivamente a los clientes con alta 
probabilidad de realizar las quejas. Los resultados según Malathi et al. (2021) indican que el uso 
de la automatización de excel para la descarga de archivos PDF es más eficiente que los otros 
tres métodos. El RPA es más eficaz en actividades operativas de ventas, extracción de datos, 
conciliaciones, comparación de precios, gestión de datos, etc. Wojciechowska-Filipek (2019) 
concluye que RPA permitió optimizar el proceso de divulgación de información constitutiva de 
secreto bancario a solicitud de autoridades e instituciones autorizadas. La aplicación de RPA no 
21 
 
solo acortó el tiempo de procesamiento de consultas en más del 80%, sino que también mitigó el 
riesgo de recibir sanciones por el cumplimiento no confiable o inoportuno de las obligaciones 
legales o la falta de protección adecuada de la información que constituye un secreto bancario. 
2.1.2. Base Teórica 
2.1.2.1. Automatización Robótica de Procesos 
Aguirre y Rodriguez (2017) afirman que la automatización robótica de procesos tiene 
como objetivo de entregar una solución de software que automatiza algún proceso de negocio de 
la organización en base a una serie de pasos secuenciados y ordenados que involucran las tareas 
rutinarias. 
Willcocks y Lacity (2015) sostiene que el RPA “es ideal para reemplazar a los humanos 
en los procesos denominados de silla giratoria; procesos donde los humanos toman entradas de 
un conjunto de sistemas (por ejemplo, correo electrónico), procesan esas entradas usando reglas, 
y luego ingrese los resultados en los sistemas de registro”. 
2.1.2.1.1. Beneficios de la Automatización Robótica de Procesos 
Los beneficios para las organizaciones son enfocados en primer lugar la calidad, el 
segundo beneficio es el incremento de la productividad y tercero es el ahorro de costos (ISACA, 
2019). 
A. Mayor calidad. 
Al realizar una ejecución consistente ayuda a reducir el error humano en los procesos 
(ISACA, 2019). 
Se incrementa la capacidad de procesamiento ya que los robots pueden ejecutar 
actividades 24x7 (DELOITTE, 2017). 
B. Reducción de costos 
22 
 
El tiempo de los recursos humanos puede ser liberado para realizar otras actividades e 
incrementar la productividad del negocio (DELOITTE, 2017). 
C. Ventajas Competitivas 
La implementación de un RPA tiene un periodo de recuperación de la inversión bajo y un 
retorno sobre la inversión (ROI) alto, el cual puede generar un cambio de iniciativas estratégicas 
en todas las empresas (DELOITTE, 2017). 
2.1.2.1.2. Tipos de RPA 
Existen tres tipos de RPA básicos que se pueden desarrollar en las organizaciones y ellos 
son el RPA asistido, no asistido e híbrido. 
A. RPA asistido 
Sotelo (2018) sostiene que los bots están instalados en los pc o laptops del personal y 
comenzará a ejecutarse cuando el empleado ejecute una opción donde realizará el llamado del 
robot y se desencadenará el trabajo operativo del robot, pero previo a ello se realizó algún trabajo 
manual y que el robot no podrá realizarlo como por ejemplo la toma de decisión del personal 
frente a algún evento. 
B. RPA no asistido 
Este tipo de RPA trabajan activándose de forma automática cuando el empleado ingrese 
algún dato en el sistema, otra forma de activarse es mediante un orquestador ya que este ordenará 
a ejecutarse el robot según el escenario o también se puede ejecutar por intervalos de tiempo de 
un determinado horario, de cualquier forma, que sea el escenario se ejecutará en un segundo 
plano de la pc o laptop (Sotelo, 2018). 
C. RPA hibrida 
23 
 
Según Sotelo (2018), este tipo de RPA híbrida es un trabajo mixto entre el RPA asistido y 
no asistido. Este tipo de RPA son para cubrir los procesos de principio a fin. 
2.1.2.1.3. Herramientas para el desarrollo del RPA 
En la actualidad existen diferentes plataformas que son las herramientas para la 
construcción del robot. 
A. UiPath 
Issac et al. (2018) sostienen que en el año 2005 era una empresa que subcontrataba 
empleados a sus clientes y tenían una fuerte demanda en un mercado exigente, es por ello que 
vieron la necesidad automatizar ciertos procesos de sus clientes por lo que tomaron la decisión 
de desarrollar una plataforma estándar que sea útil para la construcción de robots en formato de 
software que sean instalados en los ordenadores de las empresas. 
Uipath tiene las siguientes plataformas. 
• Uipath Studio: Es la herramienta que permite el modelamiento con interfaz 
gráfica en donde se puede visualizar mediante flujos la automatización de los 
procesos. Tiene una amplia librería y paquetes que se instalan y permiten que el 
robot pueda relacionarse con diversas aplicaciones como el paquete de office, 
correos electrónicos, páginas web, servidores de base de datos, etc y tiene las 
utilidades de reconocerlos elementos de la presentación de usuario de las páginas 
web, aplicaciones de escritorio por sus respectivos ID de cada elemento o con otra 
alternativa que es del reconocimiento de la imagen de cada componente, lectura 
de documentos escaneados mediante el reconocimiento inteligente de caracteres 
por sus siglas en inglés (ICR). 
24 
 
• Uipath Orchestrator: Esta plataforma es un sistema web que realiza la 
centralización de los bots que se han implementado en una organización. 
B. Automation Anywhere 
Issac et al. (2018) indica que, en el año 2010, la empresa, Tethys Solutions, LLC, cambió 
de marca a sí misma como Automation Anywhere, Inc. Las soluciones y productos de esta 
empresa están diseñados para ejecutar automatizaciones de los procesos comerciales y de 
tecnología informática en múltiples ordenadores, adaptándose a los tiempos de carga de las 
aplicaciones empresariales y a las velocidades de internet. Está disponible una edición de 
servidor que permite a los usuarios desarrollar procesos de automatización con seguridad 
centralizada, gestión de usuarios, colaboración e implementación con respaldo. 
C. Blue Prism 
Issac et al. (2018) sostiene que Blue Prism fue fundada en el año 2001 por un equipo de 
expertos en desarrollar tecnologías que mejoren la eficiencia y efectividad de los procesos de las 
empresas. Inicialmente, su atención se centró en los trabajadores de cuello blanco, back office, 
donde reconocieron una enorme insatisfacción necesidad de automatización. 
A continuación, se realiza la comparación entre las tres herramientas, según Issac et al. 
(2018), los factores más importantes que las herramientas del RPA deben de destacarse es que 
debe ser posible la automatización dentro del back office como el front office, otro requisito es 
que la herramienta tenga la interfaz gráfica de usuario para el desarrollo de los robots, otro punto 
a analizarse es que las herramientas sean accesible a su documentación para lograr el aprendizaje 
y utilizarla en diferentes aplicaciones, otra opción a evaluar las herramientas del RPA es que 
tengan la opción de grabar los procesos que ayuden a la implementación del diseño y 
codificación más rápida, el criterio de control a través de la codificación es importante ya que 
25 
 
sugieren que tanto soneficientes para controlar por un usuario la función de la herramienta y los 
bots que implementa, si la ejecución de casos de prueba automatizados en máquinas remotos es 
posible o no, la posibilidad que sea una herramienta segura y que pueda cumplir con los criterios 
mencionados anteriormente y por último el parámetro del alcance a futuro de una herramienta 
determina que tan útil sería en un largo plazo cunado otras tecnologías estarían muy por delante. 
La herramienta Uipath es la que lleva ventaja en varias de las categorías mencionadas 
anteriormente ya que siempre es adaptable en cualquier proceso de la industria u organización 
que se desee implementar un bot, los algoritmos codificados hacen posible un alcance futuro e 
infinito. 
Tabla 1 
Cuadro comparativo basado en características de las herramientas de RPA 
Parámetros 
Uipath Blue Prism Automation 
Anywhere 
Front Office / 
Automatización 
atendido 
Si Si Si 
Back Office / 
Automatización no 
atendido 
Si Si Si 
Diseño basado en Script No No Si 
Diseño visual del 
proceso 
Si Si Si, pero es más basado 
en script. 
26 
 
Plataforma abierta 
Si, tiene libre fórums y 
tutoriales. 
Si, pero todos sus 
fórums son comerciales. 
Si, pero todos los 
fórums son comerciales. 
Grabador de procesos 
Si No, debido que 
es una tecnología 
anticuada. 
Si 
Control a través de la 
codificación 
No Si Si 
Ejecución de casos 
prueba automatizada 
en máquinas remotas 
No No Si 
Futuro alcance 
Indefinido Relativamente 
menos 
Relativamente 
menos 
Nota: Tomado de Análisis delineado de herramientas robóticas de automatización de procesos (p. 2), por 
Issac et al. (2018). 
Issac et al. (2018) indica que para realizar el cuadro comparativo en aspectos técnicos de 
las plataformas del RPA ha obtenido los datos en base a expertos en las herramientas y sus 
propias implementaciones en Uipath. Los criterios para usarse son: panel de gestión del 
contenido, analíticas de RPA, en arquitectura, en desarrollo, administración y seguridad. 
En general Uipath logra buen puntaje sobre todos los criterios de desarrollos de robots y 
funciones centralizadas por su versatilidad de implementar los robots por su amplia librería que 
sirven para sincronizar con otros sistemas o programas informáticos. 
 
27 
 
Tabla 2 
Cuadro comparativo en aspectos técnicos de las herramientas del RPA 
Categoría 
Uipath Blue Prism Automation 
Anywhere 
Funciones core y 
desarrollo de los bots. 
3.25 2.50 3.70 
Sala de control, sistema 
de gestión, informes y 
resiliencia 
3.80 3.80 2.80 
Analítica RPA 3.66 2.00 3.66 
Arquitectura 3.99 3.66 1.33 
Implementación, 
gobernanza y seguridad 
3.66 4.00 3.66 
Total, RPA 3.67 3.19 3.63 
Nota: Tomado de Análisis delineado de herramientas robóticas de automatización de procesos (p. 2), por 
Issac et al. (2018). 
2.1.2.2. Procesamiento de las Cuentas por Pagar. 
Villamizar (2011) sostiene que representan el monto pendiente de pago al proveedor por 
la transacción actual a corto plazo. 
Fierro (2009) indica que las cuentas por pagar representan una obligación asumida por un 
actor económico por los bienes o servicios recibidos. 
Arens (2017) sostiene que el ciclo de las cuentas por pagar inicia con una orden de 
compra por parte de algún colaborador autorizado por la jefatura de la organización que necesita 
28 
 
la adquisición de algún bien o servicio y termina con la cancelación del pago pendiente al 
proveedor por lo recibido. 
2.1.2.2.1. Control de las cuentas por pagar 
Las cuentas por pagar se deben de realizar el control en las autorizaciones de compras, la 
custodia de los bienes y servicios recibidos, el registro y revisión en su debido momento y la 
autorización del pago a proveedores según el cronograma planificado (Gomez, 2018). 
A. Autorización adecuada para las compras. 
Según Arens et al. (2017), la autorización adecuada es esencial para garantizar que los 
bienes y servicios adquiridos se utilicen para los fines del negocio y evitar recompras excesivas o 
innecesarias. Esto quiere decir que debe existir unas políticas de autorización en la organización 
para evitar el caos y compras excesivas e innecesarias. 
Luego de que se ha aprobado la solicitud o la requisición debe de realizar un pedido para 
comprar un producto o servicio (Arens et al., 2017). Lo indicado en la cita anterior hace mención 
que se debe de realizar y enviar una orden de compra a un proveedor por uno o más artículos de 
forma legal, cada organización tiene su propia área de compras pero que a su vez no pueden ser 
juez y parte es decir no debe ser responsable de la autorización de la compra. 
B. La custodia de activos debe estar separada de otras funciones. 
Según Arens et al. (2017), en las organizaciones dentro de sus áreas de recepción de los 
bienes generan un informe como evidencia de la recepción y así evitar los robos o pérdidas de 
los artículos. 
C. Registro oportuno y revisión de las operaciones. 
Arens et al. (2017) sostiene que el área de contabilidad es responsable de confirmar la 
propiedad de los productos adquiridos y esto se realiza comparando tres documentos que son la 
29 
 
orden de compra que se genera en la misma empresa, el documento que se declara la recepción 
de los bienes y la factura o boleta que emitió el proveedor. Esto quiere decir que el responsable 
del área de las cuentas por pagar realiza una revisión de los documentos como la orden de 
compra, la solicitud de compra aprobada, la guía de remisión y la factura del proveedor para que 
posteriormente se realice el registro con las cantidades correctas y la información de los estados 
financieros sea real y se realice una toma de decisión eficiente. 
D. Autorización de pago. 
Arens et al. (2017) sostiene que la gestión más importante de los pagos es la firma de los 
cheques por parte del personal autorizado, separando la responsabilidad de firmar los pagos de la 
gestión del registro de las cuentas por pagar y de las funciones de auditoría. Lo citado 
anteriormente quiere decir que los pagos por los bienes y servicios que brinda los proveedores 
deben ser debidamente autorizadas. 
2.1.2.3. Marco de trabajo PMBOK 
La organización líder en el mundo en la gestión de proyectos es Project Management 
Institute (PMI) y está brindando las herramientas confiables a los profesionales basado en 
estándares y en constante evolución. PMI indica que la guía el PMBOK define un conjunto de 
mejores prácticas para gestionar un mayor porcentaje de los proyectos. (Project Management 
Institute, 2017, p. 2). 
La guía del PMBOK 6ta edición, tiene cinco grupos de procesos de la dirección de 
proyectos que son de inicio, planificación, ejecución monitoreo y control y cierre, mientras que 
las áreas del conocimiento que nos indica en la guía son diez y son denominadas gestión de la 
integración, gestión del alcance, gestión del cronograma, gestión del costo, gestión de la calidad, 
30 
 
gestión de recursos humanos, gestión de comunicaciones, gestión de los riesgos, gestión de las 
adquisiciones y gestión de los interesados. 
Los grupos de procesos y áreas de conocimiento mencionados serán detallados a 
continuación. 
2.1.2.3.1. Grupo de procesos 
A. Grupo de procesos de inicio 
El grupo de procesos de inicio se encarga de contar con la autorización para iniciar con el 
proyecto, alinear las expectativas entres los interesados y definir un nuevo proyecto o una nueva 
fase de este (PMI, 2017). 
Figura 3 
Grupo de procesos de inicio 
 
Nota: Tomado de Guía del PMBOK (p. 562), 2017, PMI. 
B. Grupo de procesos de planificación 
Consiste en aquellos procesos que establecen el alcance en su totalidad, definir, esclarecer 
y desarrollar los lineamientos que se van a realizar para alcanzar los objetivos (PMI, 2017). 
31 
 
Figura 4 
Grupo de procesos de planificación 
 
Nota: Tomado de Guía del PMBOK (p. 566), 2017, PMI. 
 
32 
 
C.Grupo de procesos de ejecución 
El grupo de procesos de ejecución se encarga de completar las actividades definidas en la 
planificación con el objetivo de satisfacer los requisitos del proyecto involucrando la gestión de 
los recursos y la gestión de los interesados (PMI, 2017). 
Figura 5 
Grupo de procesos de ejecución 
 
33 
 
Nota: Tomado de Guía del PMBOK (p. 596), 2017, PMI. 
D. Grupo de procesos de monitoreo y control 
El grupo de procesos de monitoreo y control consiste en aquellos procesos requeridos para 
realizar el rastreo, revisar y regular el progreso y desempeño de cada proyecto, con la finalidad 
de corregir las variantes en la planificación del proyecto (PMI, 2017). 
34 
 
Figura 6 
Grupo de procesos de monitoreo y control 
 
Nota: Tomado de Guía del PMBOK (p. 614), 2017, PMI. 
E. Grupo de procesos de cierre 
35 
 
Consiste en los procesos para realizar el cierre formalmente de un proyecto o fase. Si bien 
es cierto que en este grupo solo existe un proceso pues las organizaciones pueden generar más de 
un proceso personalizando sus respectivos cierres (PMI, 2017). 
Figura 7 
Grupo de procesos de cierre 
 
Nota: Tomado de Guía del PMBOK (p. 633), 2017, PMI. 
2.1.2.3.2. Áreas del conocimiento 
De acuerdo con la guía del PMBOK las áreas del conocimiento tiene una relación con los 
grupos de procesos, este detalle se mencionará a continuación. 
36 
 
Figura 8 
Relación del grupo de procesos y áreas del conocimiento 
 
Nota: Tomado de Guía del PMBOK (p. 25), 2017, PMI. 
A. Gestión de la integración del proyecto 
37 
 
El área del conocimiento de gestión de la integración tiene el objetivo de ejecutar y 
entregar el proyecto de inicio a fin con éxito. Es el área de conocimiento que tiene procesos en 
cada uno de los cinco grupos de procesos (PMI, 2017). 
Esta área contiene 7 procesos de los cuales se aplicarán para el presente proyecto de 
investigación los siguientes procesos: El primero es desarrollar el acta de constitución del 
proyecto, el segundo es monitorear y controlar el trabajo del proyecto y por último cerrar el 
proyecto o fase. 
38 
 
Figura 9 
Descripción general de la gestión de integración 
 
Nota: Tomado de Guía del PMBOK (p. 25), 2017, PMI. 
39 
 
a) Desarrollar el acta de constitución del proyecto 
El proceso de desarrollar el acta de constitución es entregar un documento que tiene la 
autorización formal del comienzo del proyecto o fase. Se nombra al director de proyecto con su 
respectiva autoridad (PMI, 2017). 
Entradas 
➢ Caso de negocio 
➢ Acuerdos 
➢ Factores ambientales 
➢ Activos de los procesos de la organización 
Salidas 
➢ Acta de constitución del proyecto 
Herramientas y técnicas 
➢ Juicio de experto 
➢ Recopilación de datos 
➢ Habilidades interpersonales y de equipo 
➢ Reuniones 
b) Cerrar el proyecto o fase 
El proceso de cerrar el proyecto o fase es finalizar formalmente todas las actividades de 
una fase o de un proyecto, proyecto que termina siempre debe de cerrarse. (PMI, 2017). 
Entradas 
➢ Acta de constitución 
40 
 
➢ Documentos: Dentro del proyecto se consideran los documentos como el registro 
de supuestos, registro de estimaciones, registro de cambios, lecciones aprendidas, 
hitos, registro de incidentes, etc. 
➢ Entregables aceptados. 
➢ Casos de negocio. 
➢ Acuerdos. 
Salidas 
➢ Documento del registro de las lecciones aprendidas. 
➢ Transferencia del producto. 
Herramientas y técnicas 
➢ Análisis de datos 
B. Gestión del alcance del proyecto 
El área del conocimiento de gestión del alcance del proyecto se encarga de asegurar que 
se contemple todo el trabajo requerido (PMI, 2017). 
La gestión del alcance del proyecto contiene 6 procesos de los cuales se aplicarán para el 
proyecto los siguientes procesos: Planificar la gestión del alcance, definir el alcance, crear el 
EDT. 
41 
 
Figura 10 
Descripción general de la gestión del alcance 
 
Nota: Tomado de Guía del PMBOK (p. 130), 2017, PMI. 
42 
 
a) Planificar la gestión del alcance 
El proceso de planificar el alcance del proyecto es la elaboración de un plan que sirva de 
guía para la gestión del alcance definiendo cómo llevaremos los procesos, cubriendo las 
expectativas de los interesados y solo debe de incluir el trabajo necesario para culminar con éxito 
el proyecto (PMI, 2017). 
Entradas 
➢ Acta de constitución 
Salidas 
➢ Plan de gestión del alcance 
Herramientas y técnicas 
➢ Análisis de alternativas 
b) Definir el alcance 
El proceso de definir el alcance consiste en describir el alcance del producto como del 
proyecto. La elaboración del enunciado es a partir de una descripción de alto nivel que se 
encuentra en al acta de la constitución y en la planificación se realiza de manera más específica 
(PMI, 2017). 
Entradas 
➢ Acta de constitución 
➢ Plan para la dirección del proyecto 
➢ Activos de los procesos de la organización 
Salidas 
➢ Enunciado del alcance del proyecto 
Herramientas y técnicas 
43 
 
➢ Juicio de experto 
➢ Análisis de datos 
➢ Habilidades interpersonales y de equipo 
c) Crear el EDT 
El proceso de crear Estructura de desglose del trabajo más conocido por las siglas EDT, 
trata de desglosar los entregables de cada proyecto hasta cierto nivel que facilite la planificación 
del proyecto (PMI, 2017). 
Entradas 
➢ Plan de la gestión del alcance 
➢ Enunciado del alcance 
➢ Documento de requisitos 
Salidas 
➢ Línea base del alcance 
Herramientas y técnicas 
➢ Descomposición 
➢ Juicio de experto 
C. Gestión del cronograma del proyecto 
El área del conocimiento de gestión del cronograma del proyecto se encarga de 
determinar las actividades, determinar y administrar la terminación del proyecto a tiempo (PMI, 
2017). 
La gestión del alcance del cronograma contiene 6 procesos de los cuales se aplicarán para 
el proyecto los siguientes procesos: definir las actividades, secuenciar las actividades, estimar la 
duración de las actividades, desarrollar cronograma. 
44 
 
Figura 11 
Descripción general de la gestión del cronograma 
 
Nota: Tomado de Guía del PMBOK (p. 174), 2017, PMI. 
45 
 
a) Definir las actividades 
El proceso de definir las actividades se encarga de identificar las actividades a un detalle 
más específico que se deben de ejecutar por cada entregable del proyecto (PMI, 2017). 
Entradas 
➢ Acta de constitución: hitos 
➢ Planes: gestión del alcance 
Salidas 
➢ Lista de actividades 
➢ Línea base del cronograma 
Herramientas y técnicas 
➢ Juicio de expertos 
➢ Descomposición 
➢ Reuniones 
b) Secuenciar las actividades 
El proceso de secuenciar las actividades trata de relacionar de manera lógica las 
actividades del proyecto. Este proceso entregará un diagrama de actividades (PMI, 2017). 
Entradas 
➢ Plan de gestión del cronograma 
➢ Lista de actividades 
➢ Registro de supuestos 
➢ Activos de los procesos de la organización 
Salidas 
➢ Diagrama de red del cronograma 
46 
 
Herramientas y técnicas 
➢ Método de diagramación por precedencia 
c) Estimar la duración de las actividades 
El proceso de estimar la duración de las actividades se encarga de establecer la cantidad 
de periodos de trabajo necesarios para terminar las actividades con los recursos estimados (PMI, 
2017). 
Entradas 
➢ Plan de gestión del cronograma 
➢ Documentos del proyecto: lista de actividades, lista de hitos, calendario de 
recursos 
Salidas 
➢ Estimación de la duración 
➢ Base de las estimaciones 
➢ Actualizaciones de los documentos 
Herramientas y técnicas 
➢ Juicio de expertos 
➢ Estimación análoga 
➢ Reuniones 
d) Desarrollar el cronograma 
El proceso de desarrollar el cronograma trata de crear un modelo secuenciado e integrado 
de actividades con sus respectivas duraciones, recursos y restricciones. El cronograma debe de 
elaborarse con el equipo para confirmar que se estén aplicando las restricciones, disponibilidad 
de recursos, calendarios, etc.(PMI, 2017). 
47 
 
Entradas 
➢ Plan de gestión del cronograma 
➢ Documentos del proyecto 
➢ Acuerdos 
➢ Activos de los procesos de la organización 
Salidas 
➢ Línea base del cronograma 
➢ Cronograma del proyecto 
Herramientas y técnicas 
➢ Método de la ruta crítica 
➢ Optimización de recursos 
D. Gestión de riesgos 
El área del conocimiento gestión de riesgos trata de aumentar la probabilidad y el impacto 
de los riesgos positivos y disminuir la probabilidad y el impacto negativo con el objetivo de 
optimizar el éxito del proyecto (PMI, 2017). 
La gestión de riesgos contiene 7 procesos de los cuales se aplicarán para el proyecto los 
siguientes procesos: el primero es identificar los riesgos y el segundo es planificar la respuesta a 
los riesgos. 
48 
 
Figura 12 
Descripción general de la gestión de los riesgos 
 
Nota: Tomado de Guía del PMBOK (p. 396), 2017, PMI. 
a) Identificar los riesgos 
49 
 
El proceso de identificación de los riegos trata de listar los eventos riesgosos que podrían 
afectar para bien o para mal los objetivos del proyecto (PMI, 2017). 
Entradas 
➢ Planes de la dirección de proyectos 
➢ Documentos: requisitos, bases de estimación de duración y costos 
➢ Acuerdos 
Salidas 
➢ Registros de riegos 
Herramientas y técnicas 
➢ Tormento de ideas 
➢ Entrevistas 
➢ Análisis causa - raíz 
b) Planificar respuesta a los riegos 
El proceso de planificación de la respuesta al riesgo implica proponer estrategias y 
acciones para hacer frente a los riesgos que se presenten en el proyecto (PMI, 2017). 
Entradas 
➢ Planes: línea base de costos, gestión de riesgos 
➢ Documentos: cronograma, calendario de recursos, registro de riesgos. 
Salidas 
➢ Registro de riesgos actualizado 
Herramientas y técnicas 
➢ Entrevistas 
➢ Análisis de alternativas 
50 
 
2.1.2.4. Scrum 
Hirotaka Takeuchi y Ikujiro en los años 80 describieron un método que debe ser similar 
al juego del rugby, donde todos los integrantes trabajan en conjunto a medida que se desplazan 
en el campo de juego. Schwaber junto con Sutherland definieron el concepto Scrum y llevaron su 
aplicación hacia los desarrollos de software, luego muchos de los autores y expertos de la 
metodología Scrum han continuado mejorándolo hasta que es uno de los métodos más requeridos 
por las organizaciones (SCRUMstudy, 2017). 
Scrum es un conjunto de buenas prácticas y el más conocido de los framework agiles para 
trabajar de manera colaborativa, en equipo y cumplir con los objetivos planteados en un 
proyecto. Este marco de trabajo realiza entregas parciales y regulares de forma iterativa 
garantizando la transparencia en la comunicación y responsabilidad colectiva (SCRUMstudy, 
2017). 
2.1.2.4.1. Roles del Scrum 
Los roles principales dentro del marco Scrum son: 
A. Product Owner 
El product owner es el representante del cliente y responsable de entregar el más alto 
valor al negocio. 
B. Scrum Master 
El scrum master es el facilitador y guía para que el equipo scrum logre los objetivos 
propuestos, liberar los impedimentos del desarrollo del producto y asegurar que se cumpla los 
procesos de la metodología Scrum. 
C. Equipo Scrum 
51 
 
Es el grupo de personas capaz de entender las definiciones del product owner y de 
entregar el producto terminado en base a iteraciones. 
Figura 13 
Estructura de la organización del Scrum 
 
Nota: Tomado de Scrum Body of Knowledge (p.13), por Tridibesh, 2017, SCRUMstudy. 
2.1.2.4.2. Fases de Scrum 
Las fases del Scrum son inicio, planificación y estimación, implementación, revisión y 
retrospectiva y lanzamiento, dentro de estas fases se describe los procesos entradas y salidas. 
 
52 
 
Tabla 3 
Resumen de los procesos fundamentales de Scrum 
Fases Procesos 
I. Inicio 
1. Crear la visión del portafolio de proyectos 
2. Identificar al Scrum Master y Stakeholder(s) 
3. Formar Equipos Scrum 
4. Desarrollar épica(s) 
5. Crear Backlog Priorizado del Portafolio 
6. Realizar la planificación del lanzamiento. 
II. Planificación y estimación 
7. Crear historias de usuarios 
8. Estimar historias de usuario 
9. Comprometer historias de usuario 
10. Identificar tareas 
11. Estimar tareas 
12. Crear el Sprint Backlog 
 
III. Implementación 
13.Crear entregables 
14. Realizar Daily Meetings 
15. Refinar el Backlog priorizado del portafolio 
IV. Revisión y retrospectiva 
16. Demostrar y validar el sprint 
17. Retrospectiva del sprint 
V. Lanzamiento 
18. Enviar entregables 
19. Retrospectiva del proyecto 
Nota: En total hay 19 procesos que se agrupan en 5 fases de Scrum. Tomado de Scrum Body of Knowledge 
(p.16), por Tridibesh, 2017, SCRUMstudy. 
A continuación, describiremos las fases y los procesos que aplicaremos para el proyecto 
de implantación del RPA. 
A. Planificación y estimación 
La fase de planificación y estimación incluye todo lo referente a la planificación de 
actividades que se van a realizar, los procesos que aplicaremos para el proyecto son: 
53 
 
a) Crear historias de usuario 
En este proceso se elaboran las historias de usuario con sus respectivos criterios de 
aceptación. El product owner por lo general tiene la responsabilidad de generar las historias de 
usuario y debe ser creado con un lenguaje entendible para todos los stakeholders (SCRUMstudy, 
2017). 
b) Estimar de historias de usuario 
El equipo Scrum en conjunto con el Scrum Master se encarga de realizar las estimaciones 
por cada historia de usuario, para ello el producto owner clarifica las historias para un mayor 
entendimiento del equipo Scrum (SCRUMstudy, 2017). 
c) Identificar tareas 
Se realiza el listado de tareas por cada historia de usuario (SCRUMstudy, 2017). 
d) Estimar tareas 
El equipo scrum realiza la estimación de cuánto tiempo va a ser necesario para su 
finalización de cada tarea (SCRUMstudy, 2017). 
e) Crear Sprint Bakclog 
En este proceso el equipo scrum identifica las tareas que se van a desarrollar en cada 
sprint (SCRUMstudy, 2017). 
B. Implementación 
La fase de implementación hace referencia al desarrollo de las tareas que se planificaron 
para elaborar el producto (SCRUMstudy, 2017). 
Los procesos que aplicaremos para el proyecto son: 
a) Crear entregables 
54 
 
El equipo Scrum desarrolla las tareas planificadas de el sprint con el objetivo de realizar 
las entregas iterativas (SCRUMstudy, 2017). 
b) Realizar Daily Meetings 
Es una reunión que se realiza todos los días con los integrantes del equipo Scrum para 
levantar los impedimentos, que es lo que se hizo ayer y que se realizará hoy día, el timebox 
asignado es de 15 min (SCRUMstudy, 2017). 
C. Revisión y retrospectiva 
En esta fase se realiza la validación de los entregables y del trabajo que se ha realizado 
por parte del equipo scrum (SCRUMstudy, 2017). 
a) Demostrar y validar el Sprint 
El equipo scrum muestra el entregable trabajado al product owner. El objetivo es tener la 
aceptación del producto por parte de los stakeholders principales (SCRUMstudy, 2017). 
b) Retrospectiva del Sprint 
La actividad es que se realice una reunión entre el Scrum Master y equipo Scrum para 
listar las lecciones aprendidas y que serán de utilidad para futuros sprints (SCRUMstudy, 2017). 
D. Lanzamiento 
En esta fase se realiza la identificación, documentación de las lecciones aprendidas y 
sobre todo la entrega del producto al cliente que fue previamente aceptado (SCRUMstudy, 
2017). 
a) Enviar entregables 
En este proceso se realiza la entrega al cliente del producto aceptado (SCRUMstudy, 
2017). 
55 
 
2.1.2.5. Rational unified process (RUP) 
El proceso unificado es un marco de trabajo para el desarrollo de una variedad de 
softwares que utiliza el lenguaje unificado de modelo (UML) para elaborar los diagramas de un 
sistema (Rumbaugh et al., 2015). 
Figura 14 
Los cinco flujos de trabajo de RUP 
 
Nota: Tomado de El Proceso Unificado de Desarrollo de Software (p.11), por Rumbaugh,2015, Addison-
Wesley. 
2.1.2.5.1. Fases del RUP 
Las fases del proceso unificado son inicio, elaboración, construcción y transición. 
A. Inicio 
En esta fase se elabora una descripción sobre el producto terminado y se anexa el análisis 
del negocio (Rumbaugh et al., 2015). 
B. Elaboración 
56 
 
Esta fase realiza la especificación descriptiva de los casos de uso y culmina con el 
desarrollo del diseño de la arquitectura (Rumbaugh et al., 2015). 
C. Construcción 
En esta fase de construcción se realiza el desarrollo del producto. Todos los casos de uso 
se llegan especificados en la fase de inicio se llegan a desarrollar y es posible que tengan algunos 
defectos (Rumbaugh et al., 2015). 
D. Transición 
En esta fase transición el producto es una versión beta en donde el equipo se concentra en 
realizar las correcciones hasta que se logra la satisfacción del cliente y se realiza el lanzamiento 
del producto (Rumbaugh et al., 2015). 
2.1.2.6. Extreme Programming (XP) 
Extreme programming es un metodología ágil y simple para abordar desarrollos de 
software enfatizando en el trabajo en equipo y en la retroalimentación continua entre el equipo 
de desarrollo y el cliente (Joskowicz, 2008). 
2.1.2.6.1. Fases del XP 
Las etapas o fases de la metodología XP son: 
A. Fase de Exploración 
En esta fase el cliente define los requisitos del proyecto en base a historias de usuario, el 
equipo de desarrollo estima el tiempo de las actividades, pero se puede ir cambiando por cada 
iteración (Joskowicz, 2008). 
B. Fase de Planificación 
Durante esta fase de planificación, el cliente trabaja con el equipo de desarrollo para 
priorizar y acordar el orden del desarrollo de las iteraciones (Joskowicz, 2008). 
57 
 
C. Fase de iteraciones 
Durante esta fase se prioriza el desarrollo del producto por parte del equipo y con la 
participación del cliente para definir las tareas que se van a desarrollar en cada iteración 
(Joskowicz, 2008). 
D. Fase de puesta en producción 
En esta fase se logra terminar las tareas del desarrollo de cada iteración y esta listo para que se 
realice las pruebas y ajustes respectivos, al finalizar la revisión y corrreciones con la decisión del 
cliente se logra pasarlo a producción (Joskowicz, 2008). 
2.1.2.7. Crystal 
Crystal es un grupo de metodologías con una genética en común, esto quiere decir que 
enfatiza la entrega frecuente, la comunicación cercana y la mejora reflexiva. Cada organización 
genera sus propias familias de metodologías utilizando el código genético de Crystal porque cada 
proyecto tiene sus propios características, tamaño, criticidad y dimensiones (Cockburn, 2004). 
2.1.2.7.1. Las 7 propiedades de la metodología Crystal 
Crystal requiere de 7 propiedades fundamentales y son las siguientes: 
A. Entrega frecuente 
La característica importante en todos los proyectos, grande o pequeño es de entregar en 
poco tiempo producto validados y en funcionamiento a los usuarios finales. Los patrocinadores 
constantemente tienen un informe sobre el avance del equipo de desarrollo, tienen la oportunidad 
de descubrir si su solicitud original fue lo que realmente necesitan y los desarrolladores 
mantienen su enfoque, rompiendo los puntos muertos de la indecisión (Cockburn, 2004). 
B. Mejora reflexiva 
58 
 
El equipo no tiene que realizar la reflexión y mejora del producto sin tomarse mucho 
tiempo, sólo el hecho de tomarse un tiempo fuera del ajetreo del desarrollo diario para pensar en 
lo que podría funcionar mejor para ser más efectivo (Cockburn, 2004). 
C. Comunicación osmótica 
La comunicación osmótica significa que la información fluye escuchando a los miembros 
del equipo, para tener información relevante. Esto normalmente se logra sentándolos en la misma 
habitación. Luego, cuando una persona hace una pregunta, otros en la sala pueden sintonizar o 
desconectarse, contribuyendo a la discusión o continuando con su trabajo (Cockburn, 2004). 
D. Seguidad personal 
La seguridad personal es poder hablar cuando algo le molesta, sin miedo a represalias. 
Como por ejemplo puede implicar decirle al gerente que el cronograma no se asemeja a lo real, 
un colaborador que su diseño necesita mejorar, o incluso hacerle saber a un colega que necesita 
ducharse con más frecuencia. La seguridad personal es uno de los temas más importantes porque 
de esta manera el equipo de trabajo logrará identificar y corregir sus debilidades, sin embargo, la 
no aplicación de la seguridad los trabajadores no hablará y las debilidades seguirán dañando al 
equipo de desarrollo (Cockburn, 2004). 
E. Enfoque 
El enfoque es primero saber en qué trabajar y luego tener tiempo y tranquilidad para 
trabajar en ello. Saber en qué trabajar proviene de la comunicación sobre la dirección del 
objetivo y prioridades. El tiempo y la tranquilidad vienen de un entorno en el que las personas no 
se aparten de su tarea para trabajar en otras (Cockburn, 2004). 
F. Fácil acceso a usuarios expertos 
59 
 
El acceso continuo a usuarios claves y expertos proporciona al equipo de desarrollo un 
lugar para implementar y probar las entregas frecuentes, retroalimentación rápida sobre la 
calidad de su producto terminado, retroalimentación rápida sobre sus decisiones de diseño, y 
requisitos actualizados (Cockburn, 2004). 
G. Entorno técnico con pruebas automatizadas, gestión de la configuración e 
integración frecuente. 
La razón de ser es para mejorar la calidad de vida del equipo de desarrollo (Cockburn, 
2004). 
2.1.2.8. Lean Software Development (LSD) 
Poppendieck M. (2003) sostiene que esta metodología muestra al mundo de desarrolladores y 
gestores de proyectos de software el cómo alcanzar la calidad, disminuir los costos, aumentar la 
velocidad y agregar valor al producto que se le entrega al cliente aplicando estos 7 principios. 
2.1.2.8.1. Los 7 principios de LSD 
A. Eliminar el desperdicio 
Se debe de reconocer, encontrar y eliminar todo lo que no añade valor al cliente, esto se 
debe de realizar manera iterativamente incluyendo los procesos que dejaron ser esenciales 
(Poppendieck, 2003). 
B. Ampliar el aprendizaje 
Este principio trata de usar cualquier método que se ajuste para poder incrementar el 
conocimiento del producto, aumentar la capacidad del equipo para aprender rápidamente 
(Poppendieck, 2003). 
C. Decidir lo más tarde posible 
60 
 
A medida que se progresa se gana más conocimiento y las ideas cambian hacia una mejor 
opción en el proyecto, es por ello, es mejor dejar las decisiones para el ultimo, pero la 
recompensa será con la reducción del riesgo (Poppendieck, 2003). 
D. Liberar tan rápido como sea posible 
Para potenciar lo que es el aprendizaje se debe de liberar lo más pronto posible 
(Poppendieck, 2003). 
E. Potenciar el equipo 
Fomentar la capacitación e invertir en la formación del personal para crecer 
(Poppendieck, 2003). 
F. Crear integridad 
Todos los componentes del software deben de funcionar en conjunto muy bien 
(Poppendieck, 2003). 
G. Ver todo en conjunto 
Se tiene que ver el conjunto y no solo el producto aplicando la lógica (Poppendieck, 2003). 
2.2. Marco Conceptual 
2.2.1. Bot 
Un bot es una aplicación de software fundamental de la automatización robótica de 
procesos (RPA) que se puede implementar para realizar determinadas tareas repetibles, flujo de 
trabajo basadas en reglas (Suri et al., 2017). Los bots son configurados y en base una secuencia 
de reglas imitan de una manera más rápida el comportamiento de un usuario humano en un 
computador. 
61 
 
2.2.2. Bots atendidos 
Los bots atendidos pueden ser configurados para ayudar, agilizar y simplificar los 
procesos como son las ventas o atención al cliente en donde el robot se hace cargo de las tareas 
del flujo del proceso trabajando en conjunto con los demás empleados, pero dependiendo de una 
orden concreta para que pueda ejecutarse por pedido de un usuario. 
2.2.3. Bots desatendidos