A.Tipacti Trabajo de Suficiencia Profesional Titulo Profesional 2021

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