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. 2. Alcances y limitaciones .......................................................................................... 18 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 Criterios de 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 Desarrollo notificar 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 negocio y 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 el procesamiento 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 son eficientes 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 Uipath Blue Prism Automation Parámetros Anywhere Front Office / Si Si Si Si Si Si Diseño basado en Script No No Si Diseño visual del Si Si Automatización atendido Back Office / Automatización no atendido proceso Si, pero es más basado en script. 26 Si, tiene libre fórums y Si, pero todos sus Si, pero todos los Plataforma abierta tutoriales. fórums son comerciales. fórums son comerciales. Si No, debido que Grabador de procesos Si es una tecnología anticuada. Control a través de la No Si Si No No Si codificación Ejecución de casos prueba automatizada en máquinas remotas Indefinido Relativamente Relativamente menos menos Futuro alcance 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 Uipath Blue Prism Automation Categoría Anywhere Funciones core y 3.25 2.50 3.70 3.80 3.80 2.80 Analítica RPA 3.66 2.00 3.66 Arquitectura 3.99 3.66 1.33 Implementación, 3.66 4.00 3.66 3.67 3.19 3.63 desarrollo de los bots. Sala de control, sistema de gestión, informes y resiliencia gobernanza y seguridad Total, RPA 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 1. Crear la visión del portafolio de proyectos 2. Identificar al Scrum Master y Stakeholder(s) I. Inicio 3. Formar Equipos Scrum 4. Desarrollar épica(s) 5. Crear Backlog Priorizado del Portafolio 6. Realizar la planificación del lanzamiento. 7. Crear historias de usuarios 8. Estimar historias de usuario II. Planificación y estimación 9. Comprometer historias de usuario 10. Identificar tareas 11. Estimar tareas 12. Crear el Sprint Backlog 13.Crear entregables III. Implementación IV. Revisión y retrospectiva V. Lanzamiento 14. Realizar Daily Meetings 15. Refinar el Backlog priorizado del portafolio 16. Demostrar y validar el sprint 17. Retrospectiva del sprint 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, AddisonWesley. 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 Los bots desatendidos no necesitan la intervención de los usuarios humanos, no interfieren con las labores de los empleados de una empresa, el uso más común es con la transferencia de archivos, generador de reportes, gestores de una gran cantidad de datos son algunos de los ejemplos que se pueden realizar bajo este escenario. 2.2.4. Interfaz de sistema Interfaz de sistema es un conjunto de controles que el usuario puede hacer uso para comunicarse con una máquina. Las interfaces de usuario deben ser amigables e intuitivas ya que son el punto de interacción entre el humano y el dispositivo. 2.2.5. Asistente Uipath El Asistente UiPath es una plataforma que se utiliza para realizar la ejecución en una máquina para ejecutar automatizaciones. Proporciona a los usuarios seleccionar fácilmente los bots desarrollado que ayudan con las tareas rutinarias (Uipath, 2021). 2.2.6. RPA RPA es la automatización de procesos mediante software de robots (Robotic Process Automation por sus siglas en inglés) cuyo objetivo es de disminuir la intervención humana con las interacciones de las aplicaciones informáticas sobre todo en tareas repetitivas en procesos muy bien definidos. 62 2.2.7. Inteligencia artificial La Inteligencia Artificial (IA) es la habilidad de los ordenadores para combinar algoritmos, aprender de cada casuística y utilizar lo aprendido con el objetivo de realizar ciertas actividades con las mismas capacidades que el ser humano (Rouhiainen, 2018). 2.2.8. Licencia Una licencia es un documento contractual en donde una persona obtiene la autorización de una entidad o de otra persona el derecho de poder utilizar un bien en original o copia, realizar una distribución y en el caso de software libe poder modificar. 2.2.9. Orden de Compra La orden de compra llamados también como el orden de pedido o nota de pedido es un documento legal por lo general de forma escrita que contiene una oferta de compra. Toda orden de compra debe ser enumerada y tener un formato en la que no se permita realizar agregados u omisiones. 2.2.10. Buenas prácticas Buenas prácticas se entienden como un grupo de tareas que optimizan la eficiencia o la eficacia aplicando los conocimientos, habilidades, herramientas y técnicas con la posibilidad de lograr el éxito en un proyecto. 2.2.11. Requisición de compra Una requisición de compra es una solicitud que presenta un colaborador de la organización a través de un formato que indica el bien o servicio que se desea realizar la compra, este formato debe de contener las aprobaciones de las respectivas jefaturas. 63 2.2.12. Facturas Una factura es un documento de naturaleza comercial que indica la compraventa de un bien o servicio. Tiene validez legal y fiscal. 2.2.13. Boleta La boleta es un documento de índole tributario que se le entrega al cliente o al último consumidor para que se realice el pago por un bien o servicio prestado, pero no involucra ningún tipo de impuesto. 2.2.14. Notas de Debito Una nota de débito es un documento en la cual el vendedor envía al cliente con la finalidad de ajustar un monto mayor a la factura que ya se ha emitido. 2.2.15. Historias de usuario Una historia de usuario es una representación sencilla de registrar los requisitos de un cliente sin tanta formalidad, obtiene los datos de quién, qué y porqué de los requerimientos de una manera concienzuda (SCRUMstudy, 2017). 2.2.16. Stakeholders El interesado, parte interesada o involucrado (del inglés stakeholder) es una persona, organización o empresa que tiene interés y participación en un proyecto de la organización. 2.2.17. Planning Pocker Planning Poker es una técnica que facilita al equipo a calcular una estimación de las tareas con mayor precisión, basada en el consenso del equipo. Es utilizado en su mayoría en la metodología de agilidad para implementación de software. 64 2.2.18. Criterios de aceptación Los criterios de aceptación son buenas prácticas a fin de determinar si cumplen con las necesidades y/o requerimientos de los usuarios interesados que se realizó en la planificación del desarrollo de un producto, es usualmente utilizado en las metodologías de agilidad. 2.3. Marco Metodológico La metodología por desarrollarse está basada en un modelo mixto que es entre el PMBOK 6ta edición porque nos permite gestionar el proyecto y Scrum para el desarrollo del producto ya que permite la comunicación continua entre los interesados minimizando los errores en la entrega del software. La adaptación de esta metodología está formada por 4 fases que son inicio, planificación, ejecución y cierre. Las fases de inicio, planificación y cierre está organizado por las áreas de conocimiento del PMBOK 6ta edición mientras que la fase de ejecución se realizará con las mejores prácticas ágiles de SCRUM. 2.3.1. Selección de la metodología La elección de la metodología para las fases de ejecución y monitoreo-control se ha llegado a elaborar cuadros comparativos proveniente del autor Espinoza, las metodologías que son incluidos en este estudio donde evalúa las semejanzas y diferencias son “Rational unified process (RUP), Scrum, Extreme Programming (XP), Crystal y Lean Software Development (LSD)” indica Espinoza, 2013. 65 Tabla 4 Comparativa de grupo de criterios según procesos (1). Grupo de Criterios Criterios SubCriterios Ítems Predicción Agilidad Frecuencia de flujos de trabajo Proceso Definición de prácticas, roles y tareas Prioridad en todas las fases del proyecto Simultaneidad en ejecución de flujos de trabajo Prácticas ¿Prácticas definidas? Orientación de prácticas RUP SCRUM XP CRYSTAL LEAN SOFTWARE DEVELOPMENT Metodología ágil. Metodología predictiva. Metodología ágil en casos excepcionales No Metodología ágil. Metodología ágil. Metodología ágil. Sí Sí Sí Sí Baja Alta Alta Alta Alta Sí Sí Sí Sí Sí Detalle de requerimientos para la creación y, mantenimiento de artefactos, que posibiliten el desarrollo de un software No Gestión para la generación directa de entregables funcionales e incrementales. Desarrollo directo de entregables funcionales e incrementales Generación de entregables funcionales e incrementales, según las características del proyecto. Optimización de los flujos de trabajo y recursos para obtener software de calidad ¿Predomina Sí Sí Sí Sí Autogestión y Auto organización de roles y tareas? Nota: Primera parte de la comparativa de grupo de criterios según procesos. Tomado del Manual para elegir una metodología de desarrollo de software dentro de un proyecto informático (p.75), por A. Espinoza, 2013, repositorio institucional PIRHUA-Universidad de Piura. 66 Tabla 5 Comparativa de grupo de criterios según procesos (2). Grupo de Criterios Criterios Definición de Prácticas, Roles y Tareas Proceso Definición de entregables/ artefactos SubCriterios Roles y Tareas Cantidad y complejidad de entregables/ artefactos Propiedad de entregables/ artefactos Ítems RUP SCRUM XP CRYSTAL Cantidad deAlta roles Baja Media Media Cantidad deAlta tareas propuestas por metodología Responsabilidad Asignada sobre roles y tareas Rotación deNo roles y tareas Alta Baja Baja Asignada Aceptada No indica Sí Baja Baja (Lo más Media a Alta. simple posible) Media LEAN SOFTWARE DEVELOPMENT No indica. Cualidades críticas del equipo mencionadas en prácticas. Baja Asignada Asignada Solo en Clear No indica Propiedad Colaboración Propiedad recae sobre el permite colectiva rol. conocer de manera general todos los entregables Baja Propiedad recae Colaboración permite sobre rol. conocer de manera Colaboración general todos los permite conocer entregables de manera general todos los entregables Nota: Segunda parte de la comparativa de grupo de criterios según procesos. Tomado del Manual para elegir una metodología de desarrollo de software dentro de un proyecto informático (p.76), por A. Espinoza, 2013, repositorio institucional PIRHUA-Universidad de Piura. 67 Tabla 6 Comparativa de grupo de criterios según personas Grupo de Criterios Criterios Sub Criterios Equipo Ítems RUP SCRUM Tamaño de proyecto Cualquier tipo 7 a 11 personas de tamaño Comunicación Tipo de entre comunicación integrantes. predominante Indirecta Formalidad de Alta reuniones Importancia de la Alta documentación Personas XP CRYSTAL LEAN SOFTWARE DEVELOPMENT 5 a 10 personas. Baja 10 a 20 personas C. Clear: 8 a 10 Personas. C. Orange: 10 a 40 personas. Cara a cara Cara a cara en Clear. Cara a Cara Aumento de comunicación indirecta en Orange Baja Media Baja Baja Baja Cara a cara Baja en Clear, Baja aumenta a media en Orange. Alta (Clear) Media Alta (Orange) Frecuencia de Baja Alta Alta retroalimentación Cambio de ¿Tratado por la Sí No integrantes metodología? Práctica utilizada Documentación No lo refiere Aprendizaje y No lo refiere No lo refiere (Retroalimentación retroalimentación (Retroalimentación (Retroalimentación es asumible) colectiva es asumible). es asumible). Clientes Participación Tipo de Interesado Miembro parcial Miembro del Miembro parcial Miembro parcial y en el proyecto participación equipo usuarios Disponibilidad a Baja Media Alta Media Media - Alta lo largo del proyecto Nota: Tomado del Manual para elegir una metodología de desarrollo de software dentro de un proyecto informático (p.77), por A. Espinoza, 2013, repositorio institucional PIRHUA-Universidad de Piura. 68 Tabla 7 Comparativa de grupo de criterios según organización y proyectos. Grupo de Criterios Criterios Criticidad de proyectos Manejo de contratos Organización SubCriterios Ítems RUP Criticidad 1 a 4 Responsabilidad delimitada en contrato Tipos de contratos a utilizar SCRUM Criticidad 1 a 2 XP Criticidad 1 a 2 CRYSTAL Criticidad 1 a 3 LEAN SOFTWARE DEVELOPMENT Criticidad 1 a 2 Responsabilidad Responsabilidad Responsabilidad Responsabilidad Responsabilidad dividida compartida. compartida. compartida compartida Contratos de costo fijo Contratos de costo-objetivo, cronogramaobjetivo o de beneficios compartidos Contratos de costo-objetivo, cronogramaobjetivo o de beneficios compartidos Contratos de costo-objetivo, cronogramaobjetivo o de beneficios compartidos Contratos de costo-objetivo, cronograma objetivo o de beneficios compartidos. Nota: Tomado del Manual para elegir una metodología de desarrollo de software dentro de un proyecto informático (p.78), por A. Espinoza, 2013, repositorio institucional PIRHUA-Universidad de Piura. 69 2.3.1.1. Paso 1: Criterio de Predicción – Agilidad. En la implementación del RPA tiene un alto valor de innovación, porque existe una nueva forma de registrar las cuentas por pagar del área contable de Sapia. La incertidumbre es alta, porque al implementar un nuevo software RPA que mejorará el proceso de registrar las cuentas por pagar según los integrantes del área contable serán de fuertes cambios. La inestabilidad prevista de los requisitos es alta porque la alta gerencia busca que la implementación del robot evolucione junto con los cambios en los próximos tres años. Los tres indicadores mencionados anteriormente son de resultados altos y se concluye que el proyecto sobre la implantación de un RPA tiene una necesidad de un método que aplique la agilidad por lo tanto las metodologías que se ajustan a estos criterios son Scrum, XP, Crystal y Lean Software Development porque son para proyectos de inestabilidad de requisitos alta y alta incertidumbre caso contrario es con la metodología predictiva RUP. 2.3.1.2. Paso 2: Criterio de tamaño del proyecto El proyecto por desarrollarse está definido por 7 personas. Las metodologías que si aplica para esta cantidad de personas son Scrum, Lean Software Development y RUP. Ilustración 1 Rangos de tamaño de personas por metodología 70 Nota: Tomado del Manual para elegir una metodología de desarrollo de software dentro de un proyecto informático (p.78), por A. Espinoza, 2013, repositorio institucional PIRHUA-Universidad de Piura 2.3.1.3. Paso 3: Criterio de criticidad Al implementar un nuevo software RPA en el área contable existe un cierto rechazo al cambio entre los usuarios y posibles fallas en sus funcionalidades del robot por lo que afectaría al nivel de criticidad de perdida de comodidad. Como se indica en la ilustración 2, esta situación puede ser abordado por las metodologías Scrum, Lean Software Development y RUP. RUP es descartado porque será solo usado cuando no aplique la agilidad que satisface sus necesidades del tamaño o criticidad, por lo tanto, Scrum y Lean Software Develepment podrían utilizarse. Figura 15 Rangos de Criticidad por metodología Nota: Tomado del Manual para elegir una metodología de desarrollo de software dentro de un proyecto informático (p.78), por A. Espinoza, 2013, repositorio institucional PIRHUA-Universidad de Piura 2.3.1.4. Paso 4: Decisión Final De los tres pasos anteriores se tiene elegido las metodologías Scrum y Lean Software Development pero se evaluará para decidir finalmente por el sub criterio de prácticas del grupo de procesos de los cuadros comparativos mencionados anteriormente es por ello que el punto de 71 orientación de prácticas indica que la metodología Scrum se basa en la creación directa de productos funcionales y la gestión de la entrega incremental mientras que Lean Software Development indica que optimiza los flujos de trabajo y los recursos de proceso para el desarrollo del software de alta calidad. En conclusión, Scrum es el que mejor se ajusta al proyecto de implementar el robot en el área contable realizando una gestión flexible del desarrollo de software con entregas incrementales de alta calidad. 2.3.2. Desarrollo de la metodología mixta La metodología por utilizarse está basada en un hibrido donde se aplicará algunas áreas del conocimiento de la guía PMBOK en 4 fases de las cuales son Inicio, Planificación, Ejecución y Cierre y se ejecutará el desarrollo del producto en tres sprint bajo el marco de trabajo Scrum. 72 Figura 16 Macroproceso de la metodología para el proyecto Nota: Elaboración propia Las fases y procesos que se adaptan al trabajo son: 2.3.2.1. Fase de Inicio En esta fase de inicio se realiza las actividades que encaminan a lograr el correcto comienzo del proyecto definiendo los objetivos y limitando el alcance de la implementación del RPA. Tabla 8 Actividades de la fase de inicio Fase Actividades Roles Entregables 73 1. Análisis de la Jefe del proyecto 1.Acta de Constitución Inicio problemática 2.Documento de 2.Definición del acta de identificación de constitución interesados 3.Identificación de interesados Nota: Elaboración propia 2.3.2.1.1. Entregables Los entregables que corresponden a la fase de inicio son: A. Acta de constitución del proyecto En este documento se define el propósito, alcance y una breve descripción del producto en construcción, que sirve para comunicar de manera concreta, sencilla y establecer un objetivo compartido. En este entregable se indica quien es el Jefe de Proyecto, el presupuesto base, alcances, interesados claves del proyecto. B. Documento de identificación de interesados En este documento de identificación de interesados se encuentra todas las personas u organizaciones afectadas por el proyecto asimismo tiene información acerca de su autoridad, los intereses y la importancia en la toma de decisiones en el proyecto. 2.3.2.2. Fase de planificación En esta fase de la planificación se prepara el plan de la dirección del proyecto que es el documento que denota como a través del alcance, costo y tiempo se obtendrá el producto. 74 Tabla 9 Actividades de la fase de planificación. Fase Actividades 1.Entrevista de Roles Jefe de Proyecto Entregables Registro de interesados interesados Análisis del alcance. Plan de la gestión del alcance. Enunciado del alcance EDT Planificación Diccionario de la EDT 3.Análisis de los Matriz de riesgos riesgos. 4.Elaboración del Cronograma de cronograma de actividades actividades Nota: Elaboración propia 2.3.2.2.1. Entregables Los entregables que corresponden a la fase de planificación son: A. Registro de interesados En este documento de identificación de interesados se encuentra toda la información de los individuos y grupos que están involucrados en el proyecto. B. Plan de gestión de alcance En este documento describe como se definirá, verificará, validará y controlará el alcance del proyecto. 75 C. Enunciado del alcance En este entregable se define en una descripción escrita el alcance, los principales entregables, supuestos y limitaciones del proyecto. D. Estructura de desglose de trabajo (EDT) El EDT es uno de los documentos que tiene la descomposición estructurada del trabajo que va a realizar el equipo y que ira creando los entregables que han solicitado. E. Diccionario de EDT El entregable diccionario de EDT contiene la definición de cada una de los ítems de la descomposición y sirve para acompañar y respaldar a la EDT. F. Matriz de riesgos En este entregable se identificará y analizará los riesgos relevantes del proyecto. G. Cronograma de actividades En esta entrega se muestra las actividades vinculadas con duraciones y fechas planificadas del proyecto. 2.3.2.3. Fase de ejecución 76 Tabla 10 Fase de ejecución Fase Actividades Sprint 0 Sprint (n) =3 Roles Entregables 1.Arquitectura de la Documento de solución arquitectura 2.Definición de Matriz de historia de historias de usuario. usuario 3.Definición Product Matriz de producto Backlog backlog 4.Definición Sprint Matriz de sprint Backlog backlog Planificación: Criterios de 1.Revisión de aceptación historias de usuario y sprint backlog 2. Definición de criterios de Ejecución aceptación Implementación: Incremento del robot 1. Desarrollo del Sprint. 2. Daily Scrum. 3.Monitoreo Sprint Revisión y Documentos de Retrospectiva pruebas de 1. Sprint Review conformidad de 2. Sprint Sprint 1 al 3 Retrospective Documento de la retrospectiva Certificación QA Pruebas QA Evidencia de pruebas 77 Lanzamiento Habilitación de Acta de puesto en ambiente a producción producción. Puesta en producción. Nota: Elaboración propia 2.3.2.3.1. Sprint 0 Contiene lo necesario para iniciar a ejecutar bajo el marco Scrum, el objetivo principal del sprint 0 es establecer los lineamientos tecnológicos y la metodología del proyecto para reducir la incertidumbre respecto al alcance, por lo tanto, aún no se genera un incremento en el producto a desarrollarse. 2.3.2.3.2. Sprint 1 a 3 Para el proyecto se ha definido tres sprint en las cuales se realizan un incremento del producto iterativamente, es decir al finalizar cada sprint el usuario podrá validar una nueva funcionalidad en el robot RPA. Durante los sprint se realizará las reuniones diarias, retrospectiva y monitoreo con la herramienta burndown chart. 2.3.2.3.3. Entregables Los entregables que corresponden a la fase de ejecución son: A. Arquitectura de la solución Se construye una arquitectura en base a la arquitectura existente en Sapia. El robot RPA al no ser una tecnología invasiva puede instalarse en una computadora con los recursos mínimos para que pueda operar teniendo acceso a la red de Sapia e instalado la aplicación del sistema contable. B. Historias de Usuario Las hitorias de usuario son el resultado de las entrevistas que se tienen con los clientes para plasmar la necesidad y requerimiento de lo que desean del producto. 78 En este entregable se tendrá un listado de los requerimientos funcionales detallada en historias de usuario, el contenido de una historia de usuario son rol, funcionalidad, razón, criterio de aceptación, evento y resultado. C. Product backlog Es el listado de los requerimientos funcionales y no funcionales que tienen como origen de las historias de usuario, esta pila de requerimientos no es necesario tenerlos identificados todos desde el inicio, puede ir incrementándose. En este entregable se realizará la estimación de puntos de historia de usuario usando la técnica del planing poker. D. Sprint Backlog Se realiza la clasificación del producto backlog de las historias de usuario que se realizaran en cada sprint. Adicional se identificará las tareas por cada historia de usuario y sprint. Al finalizar se realizará la estimación de puntos de usuario de cada tarea y nos servirá para realizar el monitoreo del sprint. E. Criterios de Aceptación El entregable criterio de aceptación es definido por el product owner en conjunto con el equipo de desarrollo. Tienen relación con las historias de usuario y es útil para evitar ambigüedades y conocer si la historia de usuario se terminó con todo lo definido. F. Evidencias de pruebas En este entregable se toman las evidencias de las pruebas del robot RPA, en la cual demuestre que se realizó con éxito cada registro. G. Acta puesta en producción El acta puesta en producción es describir que se realizó el desligue del robot con éxito y esta listo para que los usuarios finales hagan uso de la nueva herramienta en producción. 79 2.3.2.4. Fase de Cierre Tabla 11 Fase de Cierre Fase Actividades 1.Cerrar el proyecto Cierre Roles Jefe de proyecto Entregables Acta de cierre del 2. Documentar lecciones proyecto aprendidas Lecciones aprendidas Nota: Elaboración propia 3. CAPITULO III: DESARROLLO DE LA SOLUCIÓN 3.1. Fase de Inicio 3.1.1. Análisis de la problemática Actualmente en Corporación Sapia las facturas, boletas, notas de débito son enviados por el proveedor mediante el portal de proveedores de Sapia. El asistente contable ingresa al portal de proveedores, identifica los documentos que son pendientes de registrar, luego ingresa al sistema contable y registra el documento en el módulo de las cuentas por pagar. Durante el proceso del registro se suele cometer algunos errores que perjudican a la contabilización como por ejemplo al realizar una mala digitación, errores al confundir un dato por otro cuando se registra la unidad de negocio conlleva que se genere un cierre contable con información errada, fecha de emisión incorrecto genera problemas en el flujo de caja y malestar en los proveedores por sus pagos, todo ello es común que suceda por un 80 cansancio del ser humano por realizar tareas repetidas. El asistente contable finaliza cambiando de estado en el portal de proveedores al documento que ha registrado y continua con el siguiente documento para registrar en el sistema contable. Figura 17 Proceso actual del registro de las cuentas por pagar Nota: Elaboración propia 3.1.2. Definición del acta de constitución Con este documento se da inicio oficialmente a la gestión y desarrollo del proyecto, para ello se reúne la información necesaria de alto nivel para iniciar una planificación de las actividades de cada fase. 3.1.2.1. Entregable: Acta de Constitución A continuación, se da entrega del acta de constitución. Tabla 12 Acta de constitución del proyecto CONTROL DE VERSIONES 81 VERSIÓN REALIZADO POR REVISADO POR APROBADO POR FECHA MOTIVO 1.0 ATG GGC DGP 07/09/2020 Original 1.1 ATG GGC DGP 10/09/2020 Modificado 1. ACTA DE CONSTITUCIÓN DEL PROYECTO PROYECTO: Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia PATROCINADOR: Gerente de Administración y Finanzas GERENTE DEL PROYECTO: Gerente de Operaciones 2. DESCRIPCIÓN DEL PROYECTO (¿Qué?, ¿Quién?, ¿Cómo?, ¿Cuándo y Dónde?) El proyecto “Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia” consiste en la implementación de un software RPA con el fin 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. El proyecto será desarrollado por el área de Tecnología e Información de la empresa Corporación Sapia con la versión comunitaria de la herramienta UiPath. 82 El proyecto se desarrollará bajo un plan de gestión de proyecto, dividiéndose en 4 procesos básicos que son inicio, planificación, ejecución y cierre. El proyecto será realizado desde el 15 de setiembre del 2020 hasta el 15 de diciembre del 2020 El proyecto se implementará en la empresa Corporación Sapia, en el área de Contabilidad, Lima, Perú. 3. BREVE DESCRIPCIÓN DEL PRODUCTO O SERVICIO DEL PROYECTO (Características, funcionalidades, soporte entre otros) El producto 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. No se requiere de modificaciones ni sustituciones del actual sistema contable que utiliza Sapia, pues este software en sus siglas en ingles RPA (automatización robótica de procesos) será fácilmente adaptable a las herramientas que se utilicen durante el proceso de las cuentas por pagar. 4. OBJETIVOS DEL PROYECTO 83 COSTO: Cumplir con el presupuesto asignado al proyecto. TIEMPO: Ejecutar la implementación del robot en un plazo de 90 días calendario. ALCANCE: Cumplir con el alcance del proyecto conforme al expediente técnico aprobado. CALIDAD: Ejecutar el proyecto en cumplimiento con los requisitos establecidos en el expediente técnico aprobado. 5. PREMISAS INICIALES SUPUESTOS El proceso de las cuentas por RESTRICCIONES La gerencia de administración y pagar debe estar definido y estable por finanzas ha limitado el presupuesto por 25 lo cual se podrá identificar el proceso mil soles. repetitivo y manual que realiza el auxiliar contable. El robot puede interactuar con el software contable independiente con la El producto debe ser desplegada fines del año 2020. tecnología que fue creado. El sistema contable debe ser Solo un auxiliar contable será altamente estable y que no sea sometido involucrado en el proyecto para el a grandes cambios. levantamiento de la información. 84 La herramienta para crear el robot debe ser con la versión comunitaria de Uipath. 6. LISTA DE DISTRIBUCIÓN DEL ACTA DE CONSTITUCIÓN (Quien recibe el Acta de Constitución) Es un listado interno de distribución del acta de constitución a aquellos interesados que deben tener conocimiento y constancia de la misma. ● Gerentes de Administración y Finanzas. ● Gerente de Operaciones ● Jefe de Contabilidad ● Jefe de Tecnologías e Información ● Jefe de Procesos 7. INTERESADOS CLAVE (Persona u organización que está activamente participando en el proyecto o cuyos intereses pueden ser afectados positiva o negativamente por la ejecución del proyecto o por el producto que elabora) 85 1. 2. 3. 4. 5. 6. 7. Gerentes de Administración y Finanzas. Gerente de Operaciones. Jefe de Contabilidad Jede de Tecnologías e Información Jefe de Procesos Analista Contable. Auxiliar Contable 8. CRONOGRAMA DE HITOS DEL PROYECTO HITO O EVENTO SIGNIFICATIVO FECHA PROGRAMADA Inicio del proyecto 15 de setiembre del 2020 Levantamiento de la Información Del 15 de setiembre del 2020 Al 30 de setiembre del 2020 Registro de Facturas por el RPA Del 01 de octubre del 2020 Al 15 de octubre del 2020 Registro de Boletas por el RPA Del 16 de octubre del 2020 Al 31 de octubre del 2020 Registro de Notas de Débito por el RPA Del 01 de noviembre del 2020 Al 15 de noviembre del 2020 Pruebas integrales del RPA Del 16 de noviembre del 2020 Al 30 de noviembre del 2020 Pase a producción Del 01 de diciembre del 2020 Al 10 de diciembre del 2020 Fin del proyecto 15 de diciembre del 2020 86 9. PRINCIPALES AMENAZAS DEL PROYECTO Que no exista el documentado donde se defina el proceso de las cuentas por pagar. Colaboradores que se contagien por el Covid 19. 10. PRINCIPALES OPORTUNIDADES DEL PROYECTO Ser el proyecto modelo para la creación de robot de software que se aplicarían para otras áreas como recursos humanos, logística. 11. PRESUPUESTO PRELIMINAR DEL PROYECTO CONCEPTO MONTO (S/) Personal 20,000 Software 81 Hardware 1,188 Contingencia 2,000 Total 23,269 Nota: Elaboración propia 3.1.3. Identificación de interesados 3.1.3.1. Entregable: Documento de identificación de interesados Tabla 13 Registro de StakeHolders ID Interesado Registro de StakeHolders Función(proyecto) 87 A B C D E F G Gerente de Administración y Finanzas Gerente de Operaciones Jefe de Contabilidad Jefe de Tecnologías e Información Jefe de Procesos Analista Contable Auxiliar Contable Nota: Elaboración propia Figura 18 Matriz Poder - Interés Nota: Elaboración propia Beneficiario del Proyecto Colaborador del proyecto Beneficiario del Proyecto Colaborador del proyecto Regulador Beneficiario del Proyecto Beneficiario del Proyecto 88 Figura 19 Matriz de Prominencia Nota: Elaboración propia Figura 20 Matriz de involucramiento de interesados Matriz de involucramiento de Stakeholders ID Interesado Desconocedor Reticente Neutral Partidario Gerente de A Líder C, D Administración y Finanzas B C Gerente de C, D Operaciones Jefe de C, D Contabilidad Jefe de D D Tecnologías e Información E Jefe de Procesos F Analista Contable C, D G Auxiliar Contable C, D Nota: Elaboración propia C 89 3.2. Fase de Planificación 3.2.1. Entrevista a los interesados 3.2.1.1. Entregable: Registro de Interesados Tabla 14 Matriz de registro de interesados Nro Puesto/Rol en el Proyecto Poder de decisión en el Proyecto Baja Media Alta Interés en el Proyecto Baja Media Alta 1 Gerente de Administración y Finanzas x x 2 Gerente de Operaciones x x 3 Jefe de Contabilidad x x 4 Jefe de Tecnología e Información x 5 Jefe de Procesos x 6 Analista Contable x x 7 Auxiliar Contable x x Nota: Elaboración propia 3.2.2. Análisis del alcance 3.2.2.1. Entregable: Plan de gestión del alcance Tabla 15 Plan de gestión del alcance ¿Cómo será administrado el alcance del Proyecto? x x 90 ● Verificación del Alcance El “Enunciado del Alcance del Proyecto” contendrá la descripción del alcance y criterios de aceptación del producto, además de ello incluirá los objetivos, requisitos, límites, restricciones, supuestos y entregables del producto. ● Validación del Alcance Los requisitos establecidos en el enunciado del alcance deberán ser cumplidos por cada uno de los entregables. Se hará un análisis de requisitos del proyecto a fin de verificar que lo establecido en las bases integradas están correctamente definidos y son suficientes para el cumplimiento de los objetivos del proyecto. ¿Cómo manejar los cambios, la frecuencia e impacto en el alcance del Proyecto? Se seguirán los siguientes pasos: Solicitud de cambios del alcance: Por el usuario solicitante. Evaluación de cambios del alcance: Se estima y evalúa las solicitudes de cambio, todo impacto positivo o negativo en el tiempo y costo será reflejado en una nueva línea base. Aprobación de cambios del alcance: Serán responsabilidad del usuario solicitante y solo se podrán ejecutar con la emisión de la aprobación de la modificación en el alcance. Ejecución de cambios: Serán implementados de acuerdo con la matriz de responsabilidades actualizada. ¿Cómo serán clasificados los cambios en el alcance del proyecto? - Cambios Menores: no implican modificaciones de tiempo y costo, se informará al usuario solicitante con una anotación en la carta para su posterior aprobación. - Cambio Mayores: Implica modificaciones de costo y tiempo, se informará al usuario solicitante para su posterior aprobación. 91 ¿Cómo serán integrados los cambios en el alcance del proyecto? Serán integrados mediante: -Actualización de la línea Base -Actualización de la EDT 3.2.2.2. Entregable: Enunciado del alcance Nombre Del Proyecto Siglas Del Proyecto Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia. PIARP Descripción Del Alcance Del Producto Requisitos (Condiciones O Capacidades Para Cumplir Con Contratos, Normas, Especificaciones, U Otros Documentos Formalmente Impuestos). Credenciales del robot. Extracción de proveedores datos Características (Propiedades Que Son Distintivas Del Producto, Y/O Que Describen Su Singularidad). El robot debe de autenticarse con sus propias credenciales, tanto como usuario y contraseña en el sistema contable. del portal de El robot debe de conectarse a la base de datos del portal de proveedores para la extracción de los datos de las cuentas por pagar. Acceso del robot al módulo de las cuentas por pagar. El robot debe de ingresar al módulo de las cuentas por pagar del sistema contable. 92 Registro de las cuentas por pagar. El robot debe de registrar las facturas en el módulo de cuentas por pagar del sistema contable. Notificación de registro exitoso El robot debe de notificar enviando un mail al auxiliar contable si se realizó el registro de forma exitosa Notificación de registro no exitoso El robot debe de notificar enviando un mail al auxiliar contable indicando el motivo del error de registro. Sistema operativo El robot debe ser utilizado en sistema operativo Windows Acceso a la red interna. El robot debe tener acceso a la red interna de Sapia para interactuar con los sistemas. Modo de operación del robot. El robot trabajará de forma asistida ya que el asistente contable será quien le indique en qué momento procede a registrar las cuentas por pagar. Criterios De Aceptación Del Producto (especificaciones o requisitos de rendimiento, funcionalidad, etc., que deben cumplirse antes que se acepte el producto del proyecto) Conceptos Criterios De Aceptación 1.Técnicos Lo estipulado en el expediente técnico del proyecto. 2.De Calidad Según lo establecido en las pruebas, ensayos y estándares establecidos en el expediente técnico. 3. Administrati vos Resolución indicando que el proyecto está concluido en un 100%. 93 Descripción Del Alcance Del Proyecto El proyecto consiste desarrollar la automatización robótica de procesos en las cuentas por pagar de la empresa Sapia. Este proyecto solo contemplará el registro de las facturas, boletas, notas de débito que los proveedores cargan en el portal de proveedores de Sapia. El registro automatizado se realizará en el sistema contable de Sapia y notificará el estado por cada registro al analista contable. Fases Del Proyecto Fase Descripción Fase de inicio del proyecto. Fase inicial del proyecto y análisis de la problemática. Fase de planificación En esta fase se realizará el análisis del alcance, identificación de los interesados, análisis de riesgos y cronograma. Fase de ejecución Diseñar el prototipo del robot según el proceso que se realiza en el registro de las cuentas por pagar. Se diseñará la arquitectura del sistema. Construcción del robot y pruebas unitarias e integrales. Preparación e instalación del robot en el ambiente de producción y prueba para consensuar su funcionamiento. Explicación del funcionamiento del robot según el alcance definido. Fase de cierre Cierre formal del proyecto 94 Entregables del proyecto Fase del proyecto Productos entregables Fase de inicio del proyecto ● Acta de constitución ● ● ● ● ● Cronograma del proyecto Documento del alcance Documento de gestión de riesgos EDT del proyecto Documento de requerimiento infraestructura Fase de ejecución ● ● ● ● ● ● Prototipos Arquitectura de la solución Diseño de los casos de pruebas Fuente del Robot Acta de pruebas integrales Acta del despliegue Fase de cierre ● ● ● ● Acta de capacitación a usuarios Manual de usuario Manual de Instalación Acta de cierre del proyecto Fase de planificación Exclusiones Del Proyecto de 95 ● No es parte del proyecto registrar los adelantos a rendir de los colaboradores de la empresa Sapia. Elaboración propia 3.2.2.3. Entregable: Estructura de desglose del trabajo (EDT) Figura 21 EDT del proyecto Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia Fase de Inicio Fase de Planificación Fase de Ejecución Fase de Cierre Elaboración del Alcance del Proyecto Especificación de requerimientos Diseño de prototipos Configuración de PC para el RPA Elaboraicón del Cronograma Especificación del proceso Diseño de caso de pruebas Instalación Requerimientos de infraestructura Arquitectura Pruebas Flujo del proceso RPA Capacitación Codificación Cierre del proyecto Prueba Integral Nota: Elaboración propia 96 3.2.2.4. Diccionario de la EDT Tabla 16 Diccionario de la EDT del proyecto Actividad Descripción Elaboración del Alcance del Proyecto. Consiste en determinar el alcance del proyecto. Cierre del Proyecto Son las actividades que se realizan para clausurar formalmente el proyecto. Se llevará acabo el levantamiento de las necesidades del usuario sobre el proceso a automatizar. Especificación de requerimientos Especificación del proceso Se llevará acabo el análisis del proceso y revisión de la factibilidad. Requerimientos de infraestructura. Diseño de prototipos Consiste en identificar los recursos a utilizarse tanto como hardware y software. Diseño del interfaz. Diseño de caso de pruebas Diseño de los casos de prueba para el registro de facturas, boletas, notas de débito. Arquitectura Diseño de la arquitectura que tendrá como soporte para el correcto funcionamiento del robot. Flujo del proceso RPA Diseño del flujo del proceso del robot. Codificación Codificación de acuerdo con el lenguaje de programación empleado. Prueba Integral Pruebas del funcionamiento del robot de manera integrada. Manual de usuario Elaboración de manual que servirá de guía para el uso del sistema. Manual de Instalación Elaboración de manual que servirá de guía para la instalación del robot. Configuración de PC para e RPA Preparación y habilitación para adecuar el robot. Instalación Instalación del robot en el ambiente de producción. 97 Pruebas Prueba para consensuar funcionamiento Nota: Elaboración propia 3.2.3. Análisis de los riesgos 3.2.3.1. Entregable: Matriz de riesgo Figura 22 Matriz de probabilidad e impacto Matriz de Probabilidad e Impacto Impacto Probabilidad Bajo Alto Medio Alto R2 Medio R3 Bajo R1 R4 Exposición al Riesgo Importante Requiere acción inmediata, se debe determinar planes de respuestas inmediatos Moderado Debe ser administrado con procedimientos normales de control de riesgos Aceptable Debe ser administrado con procedimientos rutinarios Nota: Elaboración propia 98 Figura 23 Matriz de riesgos del proyecto Nota: Elaboración propia 3.2.4. Elaboración del cronograma de actividades 3.2.4.1. Entregable: Cronograma de actividades 99 Nota: Elaboración propia 3.3. Fase de Ejecución 3.3.1. Sprint 0 3.3.1.1. Arquitectura de la solución La arquitectura de la solución propuesta es de la creación de una maquina virtual en la nube usando del proveedor Microsoft Azure. En esta maquina virtual se instalarán el robot RPA 100 y el sistema contable, el usuario desde cualquier laptop podrá conectarse a esta máquina virtual y ejecutar el robot. La maquina virtual al existir en la nube y dentro de la red de Sapia, podrá conectarse a las bases de datos del portal de proveedores. El robot debe de contar con usuario y contraseña por seguridad de la información por lo que se creará sus credenciales en el active directory. Figura 24 Arquitectura de la solución Nota: Elaboración propia 101 Figura 25 Nuevo proceso de las cuentas por pagar Nota: Elaboración propia 3.3.1.2. Definición de historias de usuario De acuerdo con las reuniones efectuadas al inicio del proyecto con el equipo scrum, se recopilan las historias de usuarios que luego conformarán el requerimiento. 102 Tabla 17 Matriz de historias de usuario Enunciado de la Historia ID Rol Funcionalidad Razón Criterios de Aceptación # Escenario Criterio de Historia Evento Resultado Logueo al Cuando el La pantalla sistema robot ingresa del login contable usuario y muestra la contraseña selección de Aceptación Como Necesito Para poder robot ingresar al registrar las 0 sistema contable facturas, boletas HU-001 y notas de débito de los la empresa. proveedores. Como Necesito Porque los robot ingresar a la HU-002 1 Selección de Cuando el El sistema documentos a empresa en robot contable empresa de registrarse es el sistema selecciona la muestra la Corporación solo de la contable empresa Sapia empresa Sapia pantalla Corporación principal con Sapia el módulo de cuentas por pagar habilitado. Como Necesito Para que sea robot registrar las contabilizado por la factura ingreso el facturas de los en el presente en el sistema código de la muestra el proveedores mes contable HU-003 2 Consultar Cuando factura El sistema contable asiento contable con la factura registrada HU-004 Como Necesito Para que sea robot registrar las 3 Consultar por Cuando El sistema contabilizado la boleta en elingreso el contable boletas de los en el presente sistema código de la muestra el proveedores mes contable boleta asiento contable con 103 la boleta registrada Como Necesito Para que sea robot registrar las contabilizado HU-005 4 Consultar por El sistema la nota de contable notas de débito en el presente débito en el muestra el de los sistema asiento contable contable con mes proveedores la nota de débito registrado Como Necesito enviar Para que robot el reporte de lo Tesorería pueda HU-006 5 Proceso de envío de mail envió de la en el mail la registrado en el realizar la día Se ejecuta el Se visualiza notificación notificación programación de pago HU-007 Como Necesito Para que el 6 Proceso de Se ejecuta Se visualiza robot notificar las asistente envío de mail envió de la en el mail la facturas contable notificación notificación registradas con conozca el éxito estado del registro de la factura HU-008 Necesito Para que el notificar las asistente facturas no contable pueda registradas conocer el estado del documento y volver a revisar en el portal de proveedores 7 Proceso de Se ejecuta Se visualiza envío de mail envió de la en el mail la notificación notificación 104 Como Necesito Para que el robot notificar las asistente envío de mail envió de la en el mail la boletas contable notificación notificación HU-009 8 Proceso de Se ejecuta Se visualiza registradas con conozca el éxito estado del registro de la factura Como Necesito Para que el robot notificar las asistente envió de la en el mail la boletas no contable pueda notificación notificación registradas conocer el HU-010 9 Se ejecuta Se visualiza estado de la boleta y volver a revisar en el Como Necesito Para que el robot notificar las asistente envío de mail envió de la en el mail la notas de débito contable notificación notificación HU-011 10 Proceso de Se ejecuta Se visualiza registradas con conozca el éxito estado del registro de las notas de débito Como Necesito Para que el robot notificar las asistente 11 notas de débito contable pueda HU-012 no registradas Proceso de Se ejecuta Se visualiza envío de mail envió de la en el mail la notificación notificación conocer el estado de las notas de débito y volver a revisar en el Nota: Elaboración propia 3.3.1.3. Definición del Product Backlog Se realizará la definición de las historias de usuario que se desarrollarán en cada uno de los Sprints. 105 La herramienta que se utilizó para la estimación es el planing poker y en la tabla siguiente se define la unidad de medida en puntos de usuario versus horas. Se tiene en consideración que en cada sprint el equipo scrum puede realizar máximo de 60 puntos. Tabla 18 Planing poker Puntos de planing poker Pts 1 2 3 5 8 13 Nota: Elaboración propia Tabla 19 Matriz del product backlog ID Sprint Historia de Descripción Usuario SP 1 HU-001 HU-002 Estimación en Prioridad puntos Ingresar al sistema contable 5 Alta Ingresar a la empresa de 5 Alta 13 Alta 8 Media 8 Media 13 Alta 8 Media 8 Media 13 Alta Corporación Sapia Realease HU-003 Registrar las facturas de los proveedores 1 HU-007 Notificar las facturas registradas con éxito HU-008 Notificar las facturas no registradas SP 2 HU-004 Registrar las boletas de los proveedores Release HU-009 2 Notificar las boletas registradas con éxito HU-010 Notificar las boletas no registradas Release SP 3 HU-005 3 Registrar las notas de débito de los proveedores 21 106 HU-011 Notificar las notas de débito 8 Media 8 Media registradas con éxito HU-012 Notificar las notas de débito no registradas Nota: Elaboración propia 3.3.1.4. Definición del Sprint Backlog Tabla 20 Matriz de tareas de historias de usuario del Sprint 1 Historia de Descripción Nro Tareas Puntos Responsable Usuario Ingresar al 1 sistema contable Revisión y 1 Analista modificación del Product Backlog 2 Revisión y 1 modificación de historias de usuario 3 Crear el proyecto 1 en la herramienta HU-001 Especialista RPA Uipath 4 Desarrollar la 2 funcionalidad para acceder al sistema contable 5 Pruebas Unitarias 2 6 Pruebas 2 Scrum Master Funcionales Ingresar a la HU-002 1 Total 9 Desarrollar la 3 empresa de funcionalidad para Corporación seleccionar la Sapia empresa. Especialista RPA 107 2 Pruebas unitarias 2 3 Pruebas 3 Analista funcionales Registrar las 1 facturas de los proveedores Total 8 Crear base de 3 datos 2 Configuración Especialista RPA 1 cadena de conexión a la base de datos 3 Configuración de 3 los parámetros en la base de datos 4 Lógica para 2 obtener las facturas pendientes de HU-003 registrar 5 Lógica para 5 registrar los datos Especialista RPA de la factura en el sistema contable 6 Desarrollo del 5 robot siguiendo las reglas del negocio de facturas HU-007 Notificar las facturas 7 Pruebas Unitarias 2 8 Prueba Funcional 3 Total 24 Lógica para enviar 2 1 las notificaciones Especialista RPA 108 registradas con 2 éxito Construcción en 2 formato html del correo 3 Pruebas Unitarias 2 4 Pruebas 3 Analista QA Funcionales Notificar las 1 facturas no registradas Total 9 Lógica para enviar 2 las notificaciones 2 Construcción en Especialista RPA 2 formato html del HU-008 correo 3 Pruebas Unitarias 2 4 Pruebas 3 Analista QA Funcionales Total 9 Total, Sprint 1 59 Nota: Elaboración propia Tabla 21 Matriz tareas de historias de usuario del Sprint 2 Historia de Descripción Nro Tareas Puntos Responsable Usuario Registrar las HU-004 1 Revisión y boletas de los modificación del proveedores Product Backlog 2 Revisión y modificación de historias de usuario 1 1 Analista 109 3 Configuración de 3 los parámetros de Especialista RPA base de datos. 4 Lógica para 2 obtener las boletas pendientes de registrar 5 Lógica para 5 registrar los datos de la boleta en el sistema contable 6 Desarrollo del 5 robot siguiendo las reglas del negocio de boletas Notificar las 7 Pruebas Unitarias 2 8 Prueba Funcional 3 Total 22 Lógica para 2 1 boletas enviar las registradas con notificaciones éxito 2 Construcción en Analista QA Especialista RPA 2 formato html del HU-009 correo 3 Pruebas Unitarias 2 4 Pruebas 3 Analista QA Funcionales Notificar las HU-010 1 Total 9 Lógica para 2 boletas no enviar las registradas notificaciones Especialista RPA 110 2 Construcción en 2 formato html del correo 3 Pruebas Unitarias 2 4 Pruebas 3 Analista QA Funcionales Total 9 Total, Sprint 2 40 Nota: Elaboración propia Tabla 22 Matriz de tareas de historias de usuario del Sprint 3 Historia de Descripción Nro Tareas Puntos Responsable Usuario Registrar las 1 Revisión y notas de débito modificación del de los Product Backlog proveedores 2 Revisión y 1 Analista 1 modificación de historias de usuario 3 Configuración de 3 los parámetros de HU-005 RPA base de datos. 4 Lógica para 2 obtener las notas de débitos pendientes de registrar 5 Lógica para registrar los datos de la nota de Especialista 5 111 débito en el sistema contable 6 Desarrollo del 5 robot siguiendo las reglas del negocio de notas de debito Notificar las 7 Pruebas Unitarias 2 8 Prueba Funcional 3 Total 22 Lógica para 2 1 notas de débito enviar las registradas con notificaciones éxito 2 Construcción en Analista QA Especialista RPA 2 formato html del HU-011 correo 3 Pruebas Unitarias 2 4 Pruebas 3 Analista QA Funcionales Notificar las 1 Total 9 Lógica para 2 notas de débito enviar las no registradas notificaciones 2 Construcción en Especialista RPA 2 formato html del HU-012 correo 3 Pruebas Unitarias 2 4 Pruebas 3 Funcionales Nota: Elaboración propia Total 9 Total, Sprint 3 40 Analista QA 112 3.3.2. Sprint 1 3.3.2.1. Fase de planificación 3.3.2.1.1. Revisión de historias de usuario y sprint backlog En esta actividad se realizó la revisión de historias de usuario y el sprint backlog 1 y no se realizó ningún cambio. 3.3.2.1.2. Definición de criterios de aceptación Tabla 23 Criterios de aceptación HU-001 - Ingresar al sistema contable Historia de usuario HU-001 Usuario: Robot Nombre de Historia: Ingresar al sistema contable Prioridad: alta Riesgo: alta Especialista RPA: XXX Descripción: En esta historia de usuario permite realizar el ingreso al sistema contable por el robot con sus propias credenciales. Observaciones: Por seguridad de la información el robot debe de contar con sus propias credenciales, usuario y contraseña. Estas credenciales se le debe de solicitar al administrador de TI. Criterios de Aceptación Cuando Espero El robot hace click en el icóno del sistema Visualizar las opciones de conectar o cancelar. contable. 113 El robot hace click en la opción conectar Visualizar los campos de usuario y contraseña El robot ingresa su usuario y contraseña y click Visualizar la opción de seleccionar empresa. en “continuar” Nota: Elaboración propia Tabla 24 Criterios de aceptación HU-002 - Ingresar a la empresa de Corporación Sapia Historia de usuario HU-002 Usuario: Robot Nombre de Historia: Ingresar a la empresa de Corporación Sapia Prioridad: alta Riesgo: alta Especialista RPA: XXX Dependencia: HU-001 Descripción: En esta historia de usuario permite realizar que el robot seleccione la empresa habilitada para su usuario y solamente debe ser la empresa “Corporación Sapia”. Observaciones: El sistema contable por su naturaleza es multiempresa, sin embargo, el presente proyecto solo tiene por alcance de realizar los registros contables en la empresa Corporación Sapia, es por ello, por seguridad de la información el usuario del robot debe de contar solamente con acceso a la empresa de nombre “Corporación Sapia”. Esta configuración del acceso se le debe de solicitar al administrador de TI. Criterios de Aceptación Cuando Espero 114 El robot seleccione “Corporación Sapia” en Visualizar las opciones del menú. “Nombre de empresa” y click en el botón “Continuar”. El robot seleccione cualquier otra empresa en Visualizar el mensaje del sistema contable “No “Nombre de empresa” y click en el botón tiene el acceso a la empresa XXX” “Continuar” Nota: Elaboración propia Tabla 25 Criterios de aceptación. HU-003 - Registrar las facturas de los proveedores Historia de usuario HU-003 Usuario: Robot Nombre de Historia: Registrar las facturas de los proveedores Prioridad: alta Riesgo: alta Especialista RPA: Juan Dependencia: HU-002 Descripción: En esta historia de usuario permite que el robot realice el registro de las cuentas por pagar de tipo facturas. Observaciones: El robot mediante una query SQL obtiene las facturas pendientes por registrar desde el portal de proveedores. Los campos que el robot debe de registrar en el sistema contable son: • Sub diario • Operación de Finanzas 115 • Fecha contable • Tipo de documento • Nro Serie • Numero de Documento • Código de proveedor • Fecha del documento • Glosa • Días de Vencimiento • Fecha de Vencimiento • Tipo de base imponible • Nro comprobante del exterior • Código del proyecto • Numero de orden de compra • Total • Clasificación de bienes y servicios • Base imponible • IVG • Cuenta contable • Unidad de negocio • Centro de costo Criterios de Aceptación Cuando Espero 116 El robot consulte mediante una query si existe Visualizar el módulo de las cuentas por pagar factura pendiente por registrar con la opción nuevo registro habilitado. El robot registra los datos de la factura en el Visualizar el mensaje de registro éxitoso y módulo de Cuentas por pagar y hace click en genera el número de asiento. “Grabar” Nota: Elaboración propia Tabla 26 Criterios de aceptación. HU-007 - Notificar las facturas registradas con éxito Historia de usuario HU-007 Usuario: Robot Nombre de Historia: Notificar las facturas registradas con éxito Prioridad: alta Riesgo: alta Especialista RPA: Juan Dependencia: HU-003 Descripción: En esta historia de usuario permite que el robot realice la notificación por cada asiento contable registrada. Observaciones: El robot notificará los registros con éxito enviando un mail al asistente contable con los siguientes datos: • Nombre del proceso • Caso • Asiento • PC de ejecución 117 Criterios de Aceptación Cuando Espero El robot termine de registrar con éxito una Recibir una notificación de correo electrónico factura en el módulo de las cuentas por pagar indicando el número del asiento generado con el del sistema contable numero de la factura. Nota: Elaboración propia Tabla 27 Criterios de aceptación. HU-008 - Notificar las facturas que no son registradas Historia de usuario HU-008 Usuario: Robot Nombre de Historia: Notificar las facturas que no son registradas Prioridad: alta Riesgo: alta Especialista RPA: Juan Dependencia: HU-003 Descripción: En esta historia de usuario permite que el robot realice la notificación por cada error que muestre el sistema contable y sea un impedimento para continuar con el registro de la factura. Observaciones: El robot notificará al asistente contable indicado: • Nombre del proceso • Caso • Detalle del erro • PC de ejecución 118 Y adicional el robot tomará captura de pantalla del mensaje de error del sistema contable y será adjuntado en la notificación Criterios de Aceptación Cuando Espero El robot no pueda continuar con el registro en el Recibir una notificación de correo electrónico módulo de cuentas por pagar porque el sistema indicando el número de la factura, detalle del contable le muestra un mensaje de error y en adjuntos la captura de pantalla del inconsistencia de datos. mensaje de error que mostró el sistema contable. Nota: Elaboración propia 3.3.2.2. Fase de desarrollo 3.3.2.2.1. Desarrollo del sprint Construcción del proceso de registrar las facturas de los proveedores. Para este desarrollo se va a utilizar el IDE UIPATH, esta herramienta es de fácil uso, no tiene un exceso uso de codificación y para construir el robot es básicamente por flujo de procesos. 119 Figura 26 IDE del UIpath, para crear la solución Nota: Elaboración propia Figura 27 IDE de la herramienta UIPath Nota: Elaboración propia 120 HU-001 Ingresar al sistema contable Para la funcionalidad de la historia de usuario 001, ingresar al sistema contable. Se requiere que se cree un usuario y contraseña para que el robot pueda realizar el logueo. El proceso del logueo es la siguiente: Figura 28 Diagrama de actividades de ingresar al sistema contable Nota: Elaboración propia 121 Figura 29 Desarrollo del ingreso al sistema contable – Parte 1 Nota: Elaboración propia 122 Figura 30 Desarrollo del ingreso al sistema contable – Parte 2 Nota: Elaboración propia 123 HU-002 Seleccionar la empresa En Corporación Sapia se contabilizan con tres empresas diferentes. El robot debe tener solo el privilegio de ingresar solamente a la empresa de nombre Corporación Sapia. Figura 31 Diagrama de actividades de seleccionar empresa 124 Figura 32 Desarrollo de seleccionar empresa Nota: Elaboración propia HU-003 Registrar las facturas de proveedores Se realiza el registro de las facturas en el módulo de las cuentas por pagar del sistema contable. Para obtener las facturas se realizó la lógica mediante una query de SQL para obtener las facturas en estado pendiente de registrar de la base de datos del portal de proveedores. Para obtener los datos de la factura en estado pendiente de registrar se realizó una query de SQL para obtener los parámetros según el tipo de factura. Según el tipo de factura depende lo que se vaya a registrar en el campo del subdiario, operación, clasificación de bienes y servicios, cuenta contable. Los campos del centro de costo, unidad de negocio, código del proyecto dependen de la orden de compra que está asociada a la factura. Los campos como base imponible, IGV, total son obtenidos de la factura, el proveedor los registro en el portal de 125 proveedores cuando cargaron sus facturas, es por ello que existe en la base de datos y se puede extraer y ser utilizados por el robot RPA. Figura 33 Diagrama de actividades registrar factura – Parte I Nota: Elaboración propia 126 Figura 34 Diagrama de actividades registrar factura – Parte I Nota: Elaboración propia 127 Figura 35 Desarrollo del registro de factura en Uipath – Parte 1 Nota: Elaboración propia 128 Figura 36 Desarrollo del registro de factura en Uipath – Parte 2 Nota: Elaboración propia 129 Figura 37 Desarrollo del registro de factura en Uipath – Parte 3 Nota: Elaboración propia 130 Figura 38 Desarrollo del registro de factura en Uipath – Parte 4 Nota: Elaboración propia 131 Figura 39 Desarrollo del registro de factura en Uipath – Parte 5 Nota: Elaboración propia 132 Figura 40 Desarrollo del registro de factura en Uipath – Parte 6 Nota: Elaboración propia 133 Figura 41 Desarrollo del registro de factura en Uipath – Parte 7 Nota: Elaboración propia 134 Figura 42 Desarrollo del registro de factura en Uipath – Parte 8 Nota: Elaboración propia 135 HU-005 – Notificar facturas registradas Figura 43 Desarrollo notificar registro de factura Nota: Elaboración propia 136 HU-006 Notificar las facturas no registradas Figura 44 Desarrollo notificar error del registro de factura – Parte 1 Nota: Elaboración propia 137 Figura 45 Desarrollo notificar error del registro de factura – Parte 2 Nota: Elaboración propia 3.3.2.2.2. Daily Scrum En el primer sprint se realizaron las reuniones diarias con el equipo de desarrollo durante los 10 días que duró el sprint, la dinámica de las reuniones fue al iniciar la jornada laboral con un time box de 15 min. Las consultas que se realizaron fueron: ¿Que realizaste el día de ayer?, ¿Tienes algún impedimento? y ¿Que realizarás el día de hoy? El impedimento más resaltante en el primer sprint fue que durante el desarrollo del robot, tomar las capturas de los controles del sistema contable era complicado por la tecnología que fue desarrollado que es un software de escritorio en lenguaje de programación de visual basic 6.0. Este impedimento se logró corregir actualizando la versión de la herramienta UiPath. 3.3.2.2.3. Monitoreo Sprint 1 El monitoreo del sprint 1 se realizó con la actualización de las tareas que se hayan culminado según sus puntos de historia. Esta actualización del cuadro burndown se realizaba todos los días durante el daily scrum. 138 Figura 46 Burndown chart del sprint 1 Nota: Elaboración propia 3.3.2.3. Fase de revisión y retrospectiva A continuación, se lista las actividades por cada historia de usuario que se deben de realizar a modo de pruebas. 3.3.2.3.1. Sprint review Tabla 28 Consolidado de pruebas del Sprint 1 Actividad Escenario Descripción Cantidad Cantidad Resultado Porcentaje Historia de Usuario de pruebas de pruebas pruebas a realizadas de desarrollo realizar HU-001 Ingresar al Credencial El robot debe sistema propia del de ingresar con contable robot sus propias credenciales 3 3 Exitosas:3 100% Fallidas:0 139 (usuario y contraseña) Seleccionar la La empresa empresa 3 3 que debe estar contable es Corporación habilitado HU-002 El sistema Fallidas:0 multiempresa Sapia en el para el robot por lo tanto el sistema es Sapia. contable. Exitosas:3 100% robot solo debe de tener acceso a la empresa Sapia. Registrar las Existe En el portal de facturas facturas proveedores pendientes existe facturas 3 3 Exitosas:3 100% Fallidas:0 por registrar pendientes por registrar. No existe En el portal de facturas proveedores no pendientes existe ninguna 3 3 Exitosas:3 100% Fallidas:0 por registrar factura pendiente por registrar. HU-003 Registro de Cuando se facturas sin registra la ningún factura en el mensaje de sistema error que contable, este indique en creará un sistema código de contable. asiento contable, de la cual indica que fue un registro exitoso 4 4 Exitosas:4 100% Fallidas:0 140 Registro de En el portal de facturas proveedores 4 4 Exitosas:4 100% Fallidas:0 nacionales porexiste facturas venta de nacionales por bienes venta de bienes pendientes de registrar Registro de En el portal de facturas proveedores 4 4 Exitosas:4 100% Fallidas:0 nacionales porexiste facturas venta de nacionales por servicios. venta de servicios pendientes de registrar. Registro de En el portal de facturas del proveedores exterior por existe facturas venta de del exterior por bienes. venta de bienes 4 4 Exitosas:4 100% Fallidas:0 pendientes de registrar. Registro de En el portal de facturas del proveedores exterior por existe facturas venta de del exterior por servicios. venta de 4 4 Exitosas:4 100% Fallidas:0 servicios pendientes de registrar. Registro de En el portal de facturas proveedores nacionales existe facturas con IGV nacionales con 4 4 Exitosas:4 100% Fallidas:0 141 IGV pendientes por registrar en el sistema contable Registro de En el portal de Facturas proveedores 4 4 Exitosas:4 100% Fallidas:0 nacionales sin existe facturas IGV nacionales sin IGV pendientes por registrar en el sistema contable. Notificar las Envió Al finalizar un facturas registro de una automático registradas en del mail el sistema HU-007 4 4 Exitosas:4 100% Fallidas:0 factura se debe después de un de notificar contable con registro mediante envio éxito de mail al exitoso asistente contable que se registró con éxito indicando el número de asiento. Notificación El sistema El sistema de las facturas contable contable valida no registradas valida la los datos que se consistencia están HU-008 de los datos. ingresando, en caso se muestre alguna validación no continuará el proceso. Esta 4 4 Exitosas:4 100% Fallidas:0 142 validación debe ser notificado al asistente contable Nota: Elaboración propia 3.3.2.3.2. Sprint retrospective Tabla 29 Acta de retrospectiva del sprint 1 1. RETROSPECTIVA SPRINT 1 PROYECTO: Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia Hora Inicio: 9:00 a.m. Hora Fin: 13:00 p.m. 2. PARTICIPANTES NOMBRES Y APELLIDOS ASISTENCIA Jefe de Proyecto (Armando) Si Srcrum Master (Victor) Si Analista (Maria) Si Especialista RPA (Juan) Si Analista Calidad (Emerson) Si 143 3.CONSOLIDADO DE LA RETROSPECTIVA SPRINT1 Seguir haciendo Empezar a hacer Dejar de hacer La comunicación ha sido efectiva porque fue fluido y constante. Compartir el conocimiento No cumplir con el tiempo establecido en los Daily Srcrum (15 min) El Daily Scrum porque se hace un seguimiento diario y se mitiga los impedimentos. Mejorar el uso de la herramienta Uipath Olvidar de actualizar tareas en el ScrumBoard En las pruebas funcionales se involucra al usuario final por ende fue efectivo la salida del primer sprint. Mejorar la proactividad. Nota: Elaboración propia 3.3.3. Sprint 2 3.3.3.1. Fase de planificación 3.3.3.1.1. Revisión de historias de usuario y sprint backlog En esta actividad se realizó la revisión de historias de usuario y el sprint backlog 2 y no se realizó ningún cambio. 3.3.3.1.2. Definición de criterios de aceptación Tabla 30 Criterios de aceptación HU-004 - Registrar las boletas de los proveedores Historia de usuario HU-004 Usuario: Robot Nombre de Historia: Registrar las boletas de los proveedores 144 Prioridad: alta Riesgo: alta Especialista RPA: XXX Dependencia: HU-002 Descripción: En esta historia de usuario permite que el robot realice el registro de las cuentas por pagar de tipo boletas. Observaciones: El robot mediante una query SQL obtiene las boletas pendientes por registrar desde el portal de proveedores. Los campos que el robot debe de registrar en el sistema contable son: • Sub diario • Operación de Finanzas • Fecha contable • Tipo de documento • Nro Serie • Numero de Documento • Código de proveedor • Fecha del documento • Glosa • Días de Vencimiento • Fecha de Vencimiento • Tipo de base imponible • Nro comprobante del exterior 145 • Código del proyecto • Numero de orden de compra • Total • Clasificación de bienes y servicios • Base imponible • IVG • Cuenta contable • Unidad de negocio • Centro de costo Criterios de Aceptación Cuando Espero El robot consulte mediante una query si existe Visualizar el módulo de las cuentas por pagar boleta pendiente por registrar con la opción nuevo registro habilitado. El robot registra los datos de la boleta en el Visualizar el mensaje de registro exitoso y módulo de cuentas por pagar y hace click en genera el número de asiento. “Grabar” Nota: Elaboración propia Tabla 31 Criterios de aceptación HU-009 - Notificar las boletas registradas con éxito Historia de usuario HU-009 Usuario: Robot Nombre de Historia: Notificar las boletas registradas con éxito Prioridad: alta Riesgo: alta 146 Especialista RPA: XXX Dependencia: HU-004 Descripción: En esta historia de usuario permite que el robot realice la notificación por cada asiento contable registrada. Observaciones: El robot notificará los registros con éxito enviando un mail al asistente contable con los siguientes datos: • Nombre del proceso • Caso • Asiento • PC de ejecución Criterios de Aceptación Cuando Espero El robot termine de registrar con éxito una Recibir una notificación de correo electrónico boleta en el módulo de las cuentas por pagar indicando el número del asiento generado con el del sistema contable numero de la boleta. Nota: Elaboración propia Tabla 32 Criterios de aceptación. HU-010 - Notificar las boletas que no son registradas Historia de usuario HU-010 Usuario: Robot Nombre de Historia: Notificar las boletas que no son registradas Prioridad: alta Riesgo: alta 147 Especialista RPA: XXX Dependencia: HU-004 Descripción: En esta historia de usuario permite que el robot realice la notificación por cada error que muestre el sistema contable y sea un impedimento para continuar con el registro de la factura. Observaciones: El robot notificará al asistente contable indicado: • Nombre del proceso • Caso • Detalle del erro • PC de ejecución Y adicional el robot tomará captura de pantalla del mensaje de error del sistema contable y será adjuntado en la notificación Criterios de Aceptación Cuando Espero El robot no pueda continuar con el registro Recibir una notificación de correo electrónico en el módulo de cuentas por pagar porque indicando el número de la boleta, detalle del el sistema contable le muestra un mensaje error y en adjuntos la captura de pantalla del de inconsistencia de datos. mensaje de error que mostró el sistema contable. Nota: Elaboración propia 3.3.3.2. Fase de desarrollo 3.3.3.2.1. Desarrollo del sprint HU-004 Registrar las boletas de los proveedores 148 La query SQL para obtener los datos cambian en función a los parámetros de la boleta. El número del subdiario ahora es 040. 3.3.3.2.2. Daily Scrum En el segundo sprint se realizaron las reuniones diarias con el equipo de desarrollo durante los 10 días que duró el sprint, la dinámica de las reuniones es tal cual como se realizó en el sprint 1 que es al iniciar la jornada laboral con un timebox de 15 min. 149 Las consultas que se realizaron fueron: ¿Que realizaste el día de ayer?, ¿Tienes algún impedimento? y ¿Que realizarás el día de hoy? El impedimento más resaltante en el segundo sprint fue entender la integración entre el registro de las facturas que se desarrolló en el sprint 1 con el registro de las boletas que se desarrolló en el segundo sprint. El impedimento fue solucionado ya que el asistente contable durante el desarrollo pudo aclarar el flujo y así integrar el registro de los dos tipos de documentos. 3.3.3.2.3. Monitoreo Sprint 2 El monitoreo del sprint 2 se realizó mediante el cuadro Burndown, y ello era actualizado todos los días después de las reuniones diarias. Figura 47 Burndown chart del sprint 2 Nota: Elaboración propia 150 3.3.3.3. Fase de revisión y retrospectiva 3.3.3.3.1. Sprint review Tabla 33 Consolidado de pruebas del Sprint 2 Actividad Escenario Descripción Cantidad Cantidad Resultado Porcentaje Historia de Usuario de pruebas de pruebas pruebas a realizadas de desarrollo realizar Registrar las Existe boletas En el portal de boletas pendientes 3 3 proveedores Exitosas:3 100% Fallidas:0 por registrar existe boletas pendientes por registrar. No existe En el portal de boletas proveedores no pendientes existe ninguna 3 3 Exitosas:3 100% Fallidas:0 por registrar boleta pendiente por registrar. HU-004 Registro de Cuando se boletas sin registra la ningún boleta en el mensaje de sistema error que contable, este indique en creará un sistema código de contable. asiento contable, de la cual indica que fue un registro exitoso 4 4 Exitosas:4 100% Fallidas:0 151 Registro de En el portal de boletas proveedores 4 4 Exitosas:4 100% Fallidas:0 nacionales porexiste boletas venta de nacionales por bienes venta de bienes pendientes de registrar Registro de En el portal de boletas proveedores 4 4 Exitosas:4 100% Fallidas:0 nacionales porexiste boletas venta de nacionales por servicios. venta de servicios pendientes de registrar. Registro de En el portal de boletas del proveedores exterior por existe boletas venta de del exterior por bienes. venta de bienes 4 4 Exitosas:4 100% Fallidas:0 pendientes de registrar. Registro de En el portal de boletas del proveedores exterior por existe boletas venta de del exterior por servicios. venta de servicios pendientes de registrar. Registro de En el portal de boletas proveedores nacionales existe boeltas con IGV nacionales con 4 4 Exitosas:4 100% Fallidas:0 152 IGV pendientes por registrar en el sistema contable Registro de En el portal de boletas proveedores 4 4 Exitosas:4 100% Fallidas:0 nacionales sin existe boletas IGV nacionales sin IGV pendientes por registrar en el sistema contable. Notificar las Envió Al finalizar un boletas registro de una automático registradas en del mail el sistema HU-009 4 4 Exitosas:4 100% Fallidas:0 boleta se debe después de un de notificar contable con registro mediante envio éxito de mail al exitoso asistente contable que se registró con éxito indicando el número de asiento. Notificación El sistema El sistema de las boletas contable contable valida no registradas valida la los datos que se consistencia están HU-010 de los datos. ingresando, en caso se muestre alguna validación no continuará el proceso. Esta 4 4 Exitosas:4 100% Fallidas:0 153 validación debe ser notificado al asistente contable Nota: Elaboración propia 3.3.3.3.2. Sprint retrospective Tabla 34 Acta de retrospectiva del sprint 2 1. RETROSPECTIVA SPRINT 2 PROYECTO: Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia Hora Inicio: 9:00 a.m. Hora Fin: 13:00 p.m. 2. PARTICIPANTES NOMBRES Y APELLIDOS ASISTENCIA Jefe de Proyecto (Armando) Si Srcrum Master (Victor) Si Analista (Maria) Si Especialista RPA (Juan) Si Analista Calidad (Juan) Si 154 3.CONSOLIDADO DE LA RETROSPECTIVA SPRINT 2 Seguir haciendo Empezar a hacer Dejar de hacer La comunicación ha sido efectiva porque fue fluido y constante. Compartir el conocimiento No cumplir con el tiempo establecido en los Daily Srcrum (15 min) El Daily Scrum porque se hace un seguimiento diario y se mitiga los impedimentos. Mejorar el uso de la herramienta Uipath Olvidar de actualizar tareas en el ScrumBoard En las pruebas funcionales se involucra al usuario final por ende fue efectivo la salida del primer sprint. Mejorar la proactividad. Nota: Elaboración propia 3.3.4. Sprint 3 3.3.4.1. Fase de planificación 3.3.4.1.1. Revisión de historias de usuario y sprint backlog En esta actividad se realizó la revisión de historias de usuario y el sprint backlog 3 y no se realizó ningún cambio. 3.3.4.1.2. Definición de criterios de aceptación Tabla 35 Criterios de aceptación. HU-005 - Registrar las notas de débito de los proveedores Historia de usuario HU-005 Usuario: Robot Nombre de Historia: Registrar las notas de débito de los proveedores 155 Prioridad: alta Riesgo: alta Especialista RPA: Juan Dependencia: HU-002 Descripción: En esta historia de usuario permite que el robot realice el registro de las cuentas por pagar de tipo notas de débito. Observaciones: El robot mediante una query SQL obtiene las notas de débito pendientes por registrar desde el portal de proveedores. Los campos que el robot debe de registrar en el sistema contable son: • Sub diario • Operación de Finanzas • Fecha contable • Tipo de documento • Nro Serie • Numero de Documento • Código de proveedor • Fecha del documento • Glosa • Días de Vencimiento • Fecha de Vencimiento • Tipo de base imponible • Nro comprobante del exterior 156 • Código del proyecto • Numero de orden de compra • Total • Clasificación de bienes y servicios • Base imponible • IVG • Cuenta contable • Unidad de negocio • Centro de costo Criterios de Aceptación Cuando Espero El robot consulte mediante una query si existe Visualizar el módulo de las cuentas por pagar nota de débito pendiente por registrar con la opción nuevo registro habilitado. El robot registra los datos de la nota de débito Visualizar el mensaje de registro exitoso y en el módulo de cuentas por pagar y hace click genera el número de asiento. en “Grabar” Nota: Elaboración propia Tabla 36 Criterios de aceptación. HU-011 - Notificar las notas de débito registradas con éxito Historia de usuario HU-011 Usuario: Robot Nombre de Historia: Notificar las notas de débito registradas con éxito Prioridad: alta Riesgo: alta 157 Especialista RPA: Juan Dependencia: HU-005 Descripción: En esta historia de usuario permite que el robot realice la notificación por cada asiento contable registrada. Observaciones: El robot notificará los registros con éxito enviando un mail al asistente contable con los siguientes datos: • Nombre del proceso • Caso • Asiento • PC de ejecución Criterios de Aceptación Cuando Espero El robot termine de registrar con éxito una nota Recibir una notificación de correo electrónico de débito en el módulo de las cuentas por pagar indicando el número del asiento generado con el del sistema contable. numero de la nota de débito. Nota: Elaboración propia Tabla 37 Criterios de aceptación HU-012 - Notificar las notas de débito que no son registradas Historia de usuario HU-012 Usuario: Robot Nombre de Historia: Notificar las notas de débito que no son registradas 158 Prioridad: alta Riesgo: alta Especialista RPA: Juan Dependencia: HU-005 Descripción: En esta historia de usuario permite que el robot realice la notificación por cada error que muestre el sistema contable y sea un impedimento para continuar con el registro de la nota de débito. Observaciones: El robot notificará al asistente contable indicado: • Nombre del proceso • Caso • Detalle del erro • PC de ejecución Y adicional el robot tomará captura de pantalla del mensaje de error del sistema contable y será adjuntado en la notificación Criterios de Aceptación Cuando Espero El robot no pueda continuar con el registro en el Recibir una notificación de correo electrónico módulo de cuentas por pagar porque el sistema indicando el número de la nota de débito, detalle contable le muestra un mensaje de del error y en adjuntos la captura de pantalla del inconsistencia de datos. mensaje de error que mostró el sistema contable. Nota: Elaboración propia 3.3.4.2. Fase de desarrollo 3.3.4.2.1. Desarrollo del sprint HU-005 Registrar las notas de débito de los proveedores. 159 La query para obtener los datos cambian en función a los parámetros de las notas de débito. 3.3.4.2.2. Daily Scrum En el tercer sprint se realizaron las reuniones diarias con el equipo de desarrollo durante los 10 días que duró el sprint, la dinámica de las reuniones es tal cual como se realizó en el sprint 1 y 2 que es al iniciar la jornada laboral con un timebox de 15 min. Las consultas que se realizaron fueron: ¿Que realizaste el día de ayer?, ¿Tienes algún impedimento? y ¿Que realizarás el día de hoy? No existieron impedimentos, con las lecciones aprendidas en el sprint 1 y 2 se logró terminar en los tiempos establecidos del sprint 3. 3.3.4.2.3. Monitoreo Sprint 3 Se realizó la actualización del cuadro burndown después de las reuniones diarias del sprint 3. Figura 48 Burndown chart del sprint 3 Nota: Elaboración propia 160 3.3.4.3. Fase de revisión y retrospectiva 3.3.4.3.1. Sprint review A continuación, se lista las actividades por cada historia de usuario que se deben de realizar a modo de pruebas. Tabla 38 Consolidado de pruebas del Sprint 3 Actividad Escenario Descripción Cantidad Cantidad Resultado Porcentaje Historia de Usuario de pruebas de pruebas pruebas a realizadas de desarrollo realizar Registrar las Existe notas En el portal de notas de de débito proveedores débito pendientes existe notas de 3 3 Exitosas:3 100% Fallidas:0 por registrar débito pendientes por registrar. No existe En el portal de notas de proveedores no débito existe ninguna pendientes nota de débito 3 3 Exitosas:3 100% HU-005 Fallidas:0 por registrar pendiente por registrar. Registro de Cuando se notas de registra la nota 4 4 Exitosas:4 100% Fallidas:0 161 débito sin de débito en el ningún sistema mensaje de contable, este error que creará un indique en código de sistema asiento contable. contable, de la cual indica que fue un registro exitoso Registro de En el portal de notas de proveedores débito existe notas de 4 4 Exitosas:4 100% Fallidas:0 nacionales pordébito venta de nacionales por bienes venta de bienes pendientes de registrar Registro de En el portal de notas de proveedores débito existe notas de nacionales pordébito venta de nacionales por servicios. venta de servicios 4 4 Exitosas:4 100% Fallidas:0 162 pendientes de registrar. Registro de En el portal de notas de proveedores débito del existe notas de exterior por débito del venta de exterior por bienes. venta de bienes 4 4 Exitosas:4 100% Fallidas:0 pendientes de registrar. Registro de En el portal de notas de proveedores débito del existe notas de exterior por débito del venta de exterior por servicios. venta de 4 4 Exitosas:4 100% Fallidas:0 servicios pendientes de registrar. Registro de En el portal de notas de proveedores débito existe notas de nacionales débito con IGV nacionales con IGV pendientes 4 4 Exitosas:4 100% Fallidas:0 163 por registrar en el sistema contable Registro de En el portal de notas de proveedores débito existe notas de 4 4 Exitosas:4 100% Fallidas:0 nacionales sin débito IGV nacionales sin IGV pendientes por registrar en el sistema contable. Notificar las Envió Al finalizar un notas de automático registro de una débito del mail nota de débito registradas en después de un se debe de el sistema registro contable con exitoso HU-011 éxito notificar mediante envio de mail al asistente contable que se registró con éxito indicando el número de asiento. 4 4 Exitosas:4 100% Fallidas:0 164 Notificación El sistema El sistema de las notas de contable contable valida débito no valida la los datos que se registradas consistencia están 4 4 Exitosas:4 100% Fallidas:0 de los datos. ingresando, en caso se muestre alguna HU-012 validación no continuará el proceso. Esta validación debe ser notificado al asistente contable Nota: Elaboración propia 3.3.4.3.2. Sprint retrospective Tabla 39 Acta de la retrospectiva del sprint 3 1. RETROSPECTIVA SPRINT 3 PROYECTO: Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia Hora Inicio: 9:00 a.m. Hora Fin: 13:00 p.m. 165 2. PARTICIPANTES NOMBRES Y APELLIDOS ASISTENCIA Jefe de Proyecto (Armando) Si Srcrum Master (Victor) Si Analista (Maria) Si Especialista RPA (Juan) Si Analista Calidad (Emerson) Si 3.CONSOLIDADO DE LA RETROSPECTIVA SPRINT 3 Seguir haciendo Empezar a hacer Dejar de hacer La comunicación ha sido efectiva porque fue fluido y constante. Compartir el conocimiento No cumplir con el tiempo establecido en los Daily Srcrum (15 min) El Daily Scrum porque se hace un seguimiento diario y se mitiga los impedimentos. Mejorar el uso de la herramienta Uipath Olvidar de actualizar tareas en el ScrumBoard En las pruebas funcionales se involucra al usuario final por ende fue efectivo la salida del primer sprint. Mejorar la proactividad. Nota: Elaboración propia 166 3.3.5. Certificación general QA 3.3.5.1. Pruebas QA Se adjunta en imágenes las evidencias que se registraron correctamente las facturas, boletas y notas de débito. Registro de Facturas de Servicios Figura 49 Registro de factura de servicios Nota: Elaboración propia Registro de Facturas de Bienes 167 Figura 50 Registro de facturas de bienes Registro de Factura del exterior 168 Figura 51 Registro de factura del exterior 3.3.6. Lanzamiento 3.3.6.1. Habilitación de Ambiente Producción Actividad 1: Coordinaciones con el área de infraestructura para que se habilite una máquina virtual en la nube de Azure en donde se instalará y se ejecutará el robot. Las credenciales del acceso a la máquina virtual serán brindadas al área de Contabilidad. Actividad 2: Solicitud de acceso a las bases de datos del portal de proveedores para que el robot pueda conectarse directamente mediante querys de SQL y obtener los datos para registrar. Actividad 3: Solicitud de acceso de un mail corporativo para el usuario del robot, con estas credenciales el robot podrá enviar notificaciones en el ambiente de producción. 3.3.6.2. Puesta en producción Se adjunta el acta de la puesta en producción del robot RPA. 169 Tabla 40 Acta de puesta en producción 1. Acta puesta en producción PROYECTO: Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia Objetivo Desplegar en producción el software 2. PARTICIPANTES NOMBRES Y APELLIDOS ASISTENCIA Jefe de Proyecto (Armando) Si Srcrum Master (Victor) Si Analista (Maria) Si Especialista RPA (Juan) Si Analista Calidad (Emerson) Si 3.CONFORMIDAD DE LA PUESTA EN PRODUCCIÓN Historias de Usuario HU-001-Ingresar al sistema contable Estado Conforme 170 HU-002-Ingresar a la empresa de Corporación Sapia Conforme HU-003 - Registrar las facturas de los proveedores Conforme HU-004 - Registrar las boletas de los proveedores Conforme HU-005 - Registrar las notas de débito de los proveedores Conforme HU-006 - Reporte de registros Conforme HU-007 - Notificar las facturas registradas con éxito Conforme HU-008 - Notificar las facturas no registradas Conforme HU-009 - Notificar las boletas registradas con éxito Conforme HU-010 - Notificar las boletas no registradas Conforme HU-011 - Notificar las notas de débito registradas con éxito Conforme HU-012 - Notificar las notas de débito no registradas Conforme Nota: Elaboración propia 171 3.4. Fase de Cierre Se realizó el acta del cierre del proyecto. 3.4.1. Acta de Cierre de Proyecto Tabla 41 Acta del cierre del proyecto 1. Acta de cierre del proyecto PROYECTO: Implementación de una Automatización Robótica de Procesos para la mejora del procesamiento de las Cuentas por Pagar en Corporación Sapia Fecha Inicio: Octubre Fecha Fin: Diciembre 2. PRINCIPALES ENTREGABLES ENTREGABLE FASE DE PROYECTO Acta de Constitución Inicio Registro de interesados, enunciado del alcance, EDT, matriz de riesgos, cronograma Planificación Sprint del 1 al 3 Ejecución Acta de cierre Cierre 3.CONTROLES DE CAMBIO 172 No se realizaron cambios 3.CONCLUSIÓN El proyecto se terminó según el cronograma planificado. Nota: Elaboración propia. 173 4. CAPITULO IV: RESULTADOS Y PRESUPUESTO 4.1. Resultados Para cumplir con los objetivos específicos del proyecto se realizó lo siguiente: 4.1.1. Objetivos específicos O.E.1: Analizar el proceso del negocio y del sistema donde se realiza el procesamiento de las cuentas por pagar. Se ha realizado la comparación antes y después de la implementación del RPA en un periodo de tres meses de octubre a diciembre del año 2020. El resultado es de una mejora en el total de registros por tres meses de un 10% de incremento en la productividad. Los humanos cometemos errores por agotamiento, por las tareas rutinarias y manuales es por ello se refleja un porcentaje de errores en el proceso manual sin embargo con la implementación del RPA se reduce en un 10% el error en el proceso. Los errores del RPA son propios de inconsistencia de datos que son previamente registrados en el portal de proveedores. Tabla 42 Detalle de la comparación entre el trabajo manual vs el RPA Cantidad total Cantidad de Cantidad de Documentos Documentos Mejora de documentos documentos documentos Aceptados Aceptados con (%) Comparación antes vs después aceptados aceptados con manualmente manualmente RPA RPA (%) del RPA (%) Facturas 750 700 745 93% 97% 4% Boletas 250 200 245 80% 96% 4% Notas de débito 50 30 45 60% 80% 20% Total 1,050 930 105 88.5% 98.6% 10% 174 Nota: Datos obtenidos de los meses de octubre a diciembre 2020 del registro de las cuentas por pagar. Fuente: Elaboración propia Figura 52 Comparación de RPA vs Registro manual de las cuentas por pagar COMPARACIÓN DE RPA VS MANUAL Manual FACTURAS BOLETAS 30 45 245 200 700 UNIDADES 745 RPA NOTAS DE DÉBITO CUENTAS POR PAGAR - ACEPTADAS Nota: Datos obtenidos de los meses de octubre a diciembre 2020 del registro de las cuentas por pagar. Fuente: Elaboración propia O.E.2: Diseñar la propuesta que permita automatizar el procesamiento de las cuentas por pagar de manera eficiente. Comparativo de procesos del robot vs proceso del hombre. En corporación Sapia existen 5 asistentes contables que se dedican al registro de las cuentas por pagar de los cuales con la implementación del RPA fueron asignados a otras tareas donde aporten en actividades analíticas, concentrándose así el robot al trabajo operativo de las cuentas por pagar. 175 Figura 53 Cantidad de recursos humanos vs el RPA Nota: El trabajo realizado por 5 personas en el registro de las cuentas por pagar es reemplazado por un robot. Fuente: Elaboración propia. O.E.3: Desarrollar el proceso establecido en la propuesta para la automatización robótica del procesamiento de las cuentas por pagar. Con el desarrollo del RPA se ha disminuido el tiempo de ejecución de 10 min del trabajo manual por cada registro de las cuentas por pagar a 2 min, tiempo que toma el robot en realizar el registro. Tabla 43 Métrica Tiempo de ejecución del proceso Antes del RPA Después del RPA 10 min por registro 2 min por registro Nota: Elaboración propia O.E.4: Evaluar el desarrollo de la automatización robótica del procesamiento de las cuentas por pagar. Cálculo del ROI. 176 La fórmula del ROI es ROI= 23269/7700 ROI=3.022 El tiempo que se recuperará la inversión de S/ 23,269 ganando 7,700 mensuales es de 3 meses y 6 días. 4.2. Presupuesto 4.2.1. Recursos Humanos Tabla 44 Presupuesto de recursos humanos Sueldo mensual Cantidad Cargo Incio / Planificación Ejecución Cierre (Soles) Mes 1 Mes 2 Mes 3 Total Participación Soles Participación Soles Participación Soles Soles 1 Jefe de 100 % 5,000 25 % 1,250 25 % 1,250 7,500 1,000 3,000 5,000 Tecnología 4,000 1 Scrum Master 0% 0,000 50 % 2,000 25 % 3,500 1 Analista TI 50% 1,750 100 % 3,500 0% 0 5,250 1 Especialista 0% 0 100 % 3,000 0% 0 3000 0 50 % 1,250 0% 0 1250 3,000 RPA 1 Analista 0% 2,500 QA Totales Nota: Elaboración propia 6,750 11000 2,250 20,000 177 4.2.2. Software Tabla 45 Presupuesto de Software Software Cantidad Costo Mensual (soles) Meses Total (Soles) Uipath Comunity 1 0 3 0 Licencia office 365 5 27 3 81 Total (Soles) 27 81 Nota: Elaboración propia 4.2.3. Hardware Tabla 46 Presupuesto hardware Hardware Máquina virtual en Microsoft Azure Cantidad Costo Mensual (Soles) Meses 1 396 Total (Soles) Total (Soles) 3 1,188 1,188 Nota: Elaboración propia 4.2.4. Presupuesto Tabla 47 Presupuesto general Item Presupuesto (Soles) Costo Personal 20, 000 Costo Software 81 Costo Hardware 1, 188 Contingencia 2, 000 178 Total 23, 269 Nota: Elaboración propia 4.2.5. Análisis de beneficios 4.2.5.1. Beneficios tangibles Todo lo que pueda ser medido en valores monetarios después de la implementación del RPA se pude decir que es un beneficio tangible. Hay que considerar que el valor de una hora de trabajo del asistente contable es de S/ 10. Listado de beneficios tangibles ➢ Reducción en el tiempo del proceso del registro de las boletas. ➢ Reducción en el tiempo del proceso del registro de las facturas. ➢ Reducción en el tiempo del proceso del registro de las notas de débito. Tabla 48 Beneficio tangible Beneficios Sin RPA Con RPA Total, tangibles Beneficio Hora de Descripción RRHH trabajo Costo por Costo Hora de hora (1 por mes trabajo RRHH RRHH) Proceso de 160 5 S/ 10 Costo por Costo hora (1 por mes RRHH) S/ 9, 000 160 0 0 0 S/ 8, 000 registro de las cuentas por pagar (facturas, boletas, notas de débito) Total Nota: Elaboración propia S/ 8,000 179 4.2.5.2. Beneficios intangibles Los beneficios intangibles son todos los que no se puede medir en valor monetario, pero realiza mejoras en el proceso de las cuentas por pagar de la corporación Sapia. ➢ Información correcta y confiable, se reduce los errores porque comparando el robot con el ser humano, no registrará con errores por agotamiento, por las actividades rutinarias y tediosas. ➢ Satisfacción de los empleados, ya que al existir un robot que realice las tareas rutinarias y tediosas, los empleados podrán contribuir con tareas de mayor análisis, creatividad y agregue valor para la organización. 4.2.5.3. Flujo de Caja Costos Variables Tabla 49 Costos variables después de la implementación. Costos Variables Costo Total (S/) Electricidad 180 Internet 120 Total 300 Nota: Elaboración propia Tabla 50 Flujo de Caja por 12 meses, expresado en moneda soles Meses 0 1 2 3 4 5 6 7 8 9 10 11 12 Costo 23,269 - - - - - - - - - - - - desarrollo 180 Costo - 0 0 0 0 0 0 0 0 0 0 0 0 - 300 300 300 300 300 300 300 300 300 300 300 300 Personal Costo Variable Costos 23,269 23,569 23,869 24,169 24,469 24,769 25,069 25,369 25,669 25,969 26,269 26,569 26,869 Acumulados Beneficios - 7,520 7,520 7,520 7,520 7,520 7,520 7,520 7,520 7,520 7,520 7,520 7,520 Tangibles Beneficios 8,000 16,000 24,000 32,000 40,000 48,000 56,000 64,000 72,000 80,000 88,000 96,000 Acumulados Flujo de -23269 7,700 7,700 7,700 7,700 7,700 7,700 7,700 7,700 7,700 7,700 7,700 7,700 Caja (Ingreso Neto) Costo 23,269 -15,569 -7,869 -169 7,531 15,231 22,931 30,631 38,331 46,031 53,731 61,431 69,131 Beneficio Nota: Elaboración propia 4.2.5.4. VAN Tasa de descuento es el 10%, que suele considerar la inflación o el costo de un préstamo. El monto del VAN es de S/ 29,196.43, es decir, es rentable en el cuarto mes de implementado el proyecto. 4.2.5.5. TIR El porcentaje del TIR es 12.24%, esto quiere decir que la tasa de rentabilidad promedio anual que el proyecto paga a los inversionistas por invertir sus fondos es de 12.24% 181 CONCLUSIONES Las conclusiones del siguiente trabajo son los siguientes: De acuerdo con los resultados obtenidos, la implementación de una automatización robótica de procesos para la mejora del procesamiento de las cuentas por pagar tiene un impacto positivo porque se incrementó el porcentaje de documentos registrados aceptados en un 10% logrando tener 98.6% de documentos registrados a comparación con el trabajo manual que era de 88.5% de documentos registrados. Con este resultado queda evidencia que el RPA realiza una mejora en la calidad del proceso de registrar las cuentas por pagar porque el bot es más preciso en las validaciones, no presentan errores por el agotamiento del trabajo repetitivo a comparación con el ser humano. El robot es más rápido registrando las cuentas por pagar comparado con el trabajo manual. El tiempo de ejecución que realizar un robot es de 3 min a comparación el tiempo manual que es de 9 min. Al reducir el personal de 5 asistentes por un robot se estaría realizando un ahorro significativo mensual de S/ 7,700 por lo que genera un retorno rápido de la inversión. Los asistentes contables se pueden dedicar a un trabajo de mayor análisis y agregar mayor valor a la organización. El importe que se utilizó para la implementación es de S/ 23,269 y al realizar el flujo de caja proyectado a los 12 meses desde que se implementó el pryecto se obtiene una tasa interna de retorno de 12.24% con un valor actual neto de S/ 29,196.43 lo cual se puede deducir que el proyecto fue rentable. El uso de la herramienta Uipath para la automatización robótica de procesos es de fácil implementación, no es invasiva con otros softwares que existen en la empresa porque no tuvo 182 inconvenientes con las interacciones del sistema contable a pesar de ser de una tecnología antigua. Para lograr la implementación del RPA el proceso de las cuentas por pagar debe ser estable y estandarizado, es decir los bots realizan tareas con reglas de negocio claras y definidas. 183 RECOMENDACIONES Aplicar la tecnología usada en las diferentes áreas del BackOffice en diferentes tipos de organizaciones como entidades bancarias, hospitales, etc y evaluar el impacto comparando con el trabajo manual en el proceso de estudio. Mejorar las tecnologías aplicadas del RPA combinándola con las tecnologías cognitivas con el fin de extender la automatización a una mayor complejidad donde se requiera el juicio o la percepción. Implementar el proceso de las cuentas por pagar por pagar con el uso de otras herramientas como podrían ser Rockebot, Automation Anywhere, Blue Prism, WorkFusion. Mejorar el proceso de las cuentas por aplicadas utilizando el RPA no asistido. 184 BIBLIOGRAFÍA Aguirre, S., Rodriguez, A. (2017). Automation of a Business Process Using Robotic Process Automation (RPA): A Case Study [Automatización de un proceso empresarial mediante la automatización robótica de procesos (RPA): un estudio de caso]. Applied Computer Sciences in Engineering, 742(1), 65-71 https://doi.org/10.1007/978-3-319-66963-2_7 Deloitte. (2017). Automatización Robótica de Procesos (RPA). https://www2.deloitte.com/content/dam/Deloitte/mx/Documents/strategy/Automatiza cion_Rob%C3%B3tica_Procesos.pdf Isaca. (2015). Robotic Process Automation (RPA) y la Practica de Auditoría interna. https://www2.deloitte.com/content/dam/Deloitte/mx/Documents/strategy/Automatiza cion_Rob%C3%B3tica_Procesos.pdf Malathi, T., Navaneethakrishnan, P.L., Arun, E., Devakipriyadharshini, V.N. (2021). Performance analysis on automating the PDF download process using Robotics Process Automation [Análisis de rendimiento sobre la automatización del proceso de descarga de PDF utilizando la automatización robótica de procesos]. IOP Conference Series: Materials Science and Engineering, 1059(1),1-7. https://doi.org/10.1088/1757899X/1059/1/012007 Qiu, Y.L., Xiao, G.F. (2020). Research on cost management optimization of financial sharing center based on RPA [Investigación sobre la optimización de la gestión de costos del centro de intercambio financiero basado en RPA]. Procedia Computer Science, 166(1), 115-119. https://doi.org/10.1016/j.procs.2020.02.031 Tridibesh, S. (2017). Una guía para el Cuerpo de Conocimiento de Scrum (Guía SBOK) (3ª ed.). SCRUM study. 185 Vajgel, B., Correa, P. L. P., Tossoli, T., Encinas Quille, R. V., Bedoya, J. A. R., De Almeida, G. M., Mollica, D. (2021). Development of intelligent robotic process automation: A utility case study in Brazil [Desarrollo de la automatización robótica de procesos: Un estudio de caso de servicios públicos de Brasil]. IEEE Access, 9(1), 71222-71235. https://doi.org/10.1109/ACCESS.2021.3075693 Villamizar, A. (2011). Optimización del proceso de cuentas por pagar de la empresa Administradora Sevilar (Informe de Pasantía para optar el título de Técnico Superior Universitario). Universidad de Simón Bolívar, Caracas, Venezuela. Willcocks, L., Lacity, M., Craig, A., (2017). The IT Function and Robotic Process Automation, Londres. Recuperado de http://eprints.lse.ac.uk/64519/1/OUWRPS_15_05_published.pdf Wojciechowska-Filipek, S. (2019). Automation of the process of handling enquiries concerning information constituting a bank secret [Automatización del proceso de tramitar consultas concernientes a la información de un secreto bancario]. Banks and Bank Systems, 14(3), 175-186. http://dx.doi.org/10.21511/bbs.14(3).2019.15 Issac, R., Muni, R., Desai, K. (2018). Delineated Analysis of Robotic Procees Automation Tools [Análisis delineado de herramientas robóticas de automatización de procesos]. IEEE Access, 1(1), 1-4. https://ieeexplore.ieee.org/document/8479511/ Fierro Martínez, A. (2009). Contabilidad de pasivos. Ecoe Ediciones Gomez Bravo, S. (2018). El sistema de control interno de cuentas por pagar comerciales y su influencia en los egresos de fondos de la empresa Herramientas y Accesorios SAC de Lima Metropolitana año 2017 [Tesis de pregrado, Universidad Ricardo Palma]. http://repositorio.urp.edu.pe/handle/URP/1663 186 Arens, A.A., Elder, R.J., Beasley, M.S. (2007). Auditoria. Un Enfoque Integral. Pearson Educación. PMI. (2017). Guía de los Fundamentos para la Dirección de Proyectos (6a ed.). Project Management Institute, Inc. Rumbaugh J., Jacobson I. Y Booch G. (2015). El Proceso Unificado de Desarrollo de Software. Addison-Wesley. Joskowicz, José (2008). Reglas y Prácticas en extreme programming. IEEE International Engineering Management. https://iie.fing.edu.uy/~josej/docs/XP%20%20Jose%20Joskowicz.pdf Cockburn, Alistair. (2004). Crystal Clear. A. Cockburn. Poppendieck, M., Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley. Suri, V., Elia, M., Hillegersberg, J. (2017). Software Bots - The Next Frontier for Shared Services and Functional Excellence [Bots de software: la próxima frontera para los servicios compartidos y la excelencia funcional]. Springer, Cham, 1(1), 81-94. https://doi.org/10.1007/978-3-319-70305-3_5 UiPath. (2021). Give an automation launchpad to everyone. Watch results soar [Ofrezca una plataforma de lanzamiento de automatización a todos. Mira cómo se disparan los resultados]. https://www.uipath.com/product/software-robot-assistant Rouhiainen, L. (2018). Inteligencia artificial, 101 cosas que debes saber hoy sobre nuestro futuro. Editorial Planeta. 187 ANEXOS I. Carta de Autorización de la empresa. 188 II. Reporte Turnitin 189 190 191 192 193 194 195 196 197 198 199