Sistema de Información de Gestión de

Despacho de Pedidos para Empresas Retail

Item Type info:eu-repo/semantics/bachelorThesis

Authors Bravo Coronel, Harry Frank; Bonarriva Tenorio, James Omar

Hortencio

Publisher Universidad Peruana de Ciencias Aplicadas (UPC)

Rights info:eu-repo/semantics/openAccess; Attribution-

NonCommercial-ShareAlike 4.0 International

Download date 20/03/2023 [Link]

Item License [Link]

Link to Item [Link]

 UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

FACULTAD DE INGENIERÍA

PROGRAMA ACADÉMICO DE INGENIERÍA DE SISTEMAS

Sistema de Información de Gestión de Despacho de Pedidos para Empresas

Retail

TESIS

Para optar el título profesional de Ingeniero de Sistemas

AUTORES

Bravo Coronel, Harry Frank (0000-0001-6512-9436)

Bonarriva Tenorio, James Omar Hortencio (0000-0002-2079-4165)

ASESORES

Perona Galluccio, Sandra Guisella (0000-0003-3483-8867)

Ocampo Tello, Ernesto (0000-0001-6580-8404)

Lima, 31 de Marzo de 2021

 DEDICATORIA

A nuestros padres y familiares que nos apoyaron en todo momento.

I
 AGRADECIMIENTOS

A los profesores Héctor Saira, Mercedes Bustos, Sandra Perona y Ernesto Ocampo por su
asesoramiento en este proyecto.

II
 RESUMEN

En un mundo en el que la globalización representa una puerta abierta para las exigencias del
público consumidor, respecto a los niveles de servicio, y las formas en que estas se
satisfacen, se han descuidado aspectos fundamentales que se convierten en obstáculos para
alcanzar los niveles de servicios esperados. Esto se convierte en uno de los principales
problemas dentro de la logística.

Es por eso, que el sistema de información de gestión de despacho de pedidos tiene como
principal objetivo ser una herramienta de gestión sostenible en el tiempo, que permita
optimizar la administración de los procesos involucrados en la atención de pedidos, a fin de
satisfacer las necesidades de los clientes.

El actual documento abarca el fundamento teórico, que permite ubicar la solución propuesta
dentro de un marco conceptual, también se detalla el objeto de estudio y campo de acción,
en el que se detallan los procesos que involucra el sistema propuesto, un análisis a la
problemática de la empresa, los objetivos y beneficios que tiene el proyecto.

También se presenta el modelado de negocio, requerimientos funcionales y no funcionales,

modelado de casos de uso del sistema, modelo conceptual, arquitectura del software, calidad
y pruebas del software, y su construcción. Por último, se desarrolla el capítulo de la gestión
del proyecto, donde se detallan la lista de interesados, la EDT, la gestión de riesgos, las actas
de aceptación y el cronograma de ejecución.

Finalmente, se presentan conclusiones, glosario, siglario, referencias y anexos que respaldan

el desarrollo del presente proyecto.

Palabras clave: Niveles de servicio; logística; despacho de pedidos; optimización de rutas;

administración de stocks.

III
 Information System of Management of Dispatch of Orders for Retail Companies

ABSTRACT

In a world in which globalization represents an open door for the demands of the consumer,
regarding service levels and the ways in which they get satisfied, fundamental aspects that
become obstacles to reaching the expected levels of service have been neglected. This
becomes one of the main problems within logistics.

That is why; the order delivery management information system has as its main objective to
be a sustainable management tool over time, which allows optimizing the administration of
the processes involved in order service, to meet customer needs.

The current document covers the theoretical basis, which allows locating the proposed
solution within a conceptual framework, also the object of study and field of action, which
details the processes involved in the proposed system, an analysis of the company's
problems, the objectives, and benefits of the project.

We also present a Business modeling, functional and non-functional requirements,

conceptual model, software architecture, software quality, testing, and its construction.
Finally, we develop the chapter on project management, detailing the list of stakeholders,
the EDT, risk management, acceptance certificates and the execution schedule.

Finally, it is also including conclusions, glossary, signatures, references, and annexes that
support the development of this project.

Keywords: Service levels; Logistics; order dispatch; route optimization; Stock

management.

IV
 TABLA DE CONTENIDOS

1 INTRODUCCIÓN ......................................................................................................... 1
2 CAPÍTULO 1: FUNDAMENTOS TEÓRICOS ............................................................ 3
2.1 Introducción ............................................................................................................ 3
2.2 Marco Teórico ......................................................................................................... 3
2.2.1 Fundamentos Teóricos sobre el Negocio ........................................................ 3
2.2.2 Fundamentos Teóricos sobre las Tendencias y Tecnologías Actuales ............ 9
2.3 Objeto de Estudio.................................................................................................. 20
2.3.1 Organización Objetivo ................................................................................... 20
2.3.2 Misión ............................................................................................................ 21
2.3.3 Visión ............................................................................................................ 21
2.3.4 Objetivos Estratégicos ................................................................................... 21
2.3.5 Organigrama .................................................................................................. 22
2.3.6 Mapa de Procesos .......................................................................................... 23
2.4 Campo de Acción .................................................................................................. 24
2.4.1 Breve Descripción ......................................................................................... 24
2.4.2 Procesos del Negocio .................................................................................... 25
2.4.3 Sistemas Automatizados Vinculados con el Campo de Acción .................... 50
2.5 Análisis Crítico de los Problemas de Información ............................................... 52
2.5.1 Situación Problemática .................................................................................. 52
2.5.2 Problemas a Resolver .................................................................................... 53
2.6 Conclusiones ......................................................................................................... 53
3 CAPÍTULO 2: PROPUESTA DE SOLUCIÓN .......................................................... 55
3.1 Introducción .......................................................................................................... 55
3.2 Objetivos del Proyecto .......................................................................................... 55
3.2.1 Objetivo General............................................................................................ 55
3.2.2 Objetivos Específicos .................................................................................... 55
3.2.3 Fundamentación de los Objetivos ................................................................. 57
3.2.4 Indicadores de Logro de los Objetivos .......................................................... 58
3.3 Beneficios del Proyecto ........................................................................................ 59
3.3.1 Beneficios Tangibles ..................................................................................... 59
3.3.2 Beneficios Intangibles ................................................................................... 59
3.4 Antecedentes ......................................................................................................... 59
3.4.1 Soluciones Encontradas ................................................................................. 59

V
 3.4.2 Análisis Comparativo .................................................................................... 62
3.4.3 Evaluación de la Mejor Solución................................................................... 63
3.5 Tendencias y Tecnologías Propuestas .................................................................. 64
3.5.1 Google Maps ................................................................................................. 64
3.5.2 Firebase Realtime Database .......................................................................... 65
3.5.3 Textlocal API................................................................................................. 67
3.6 Conclusiones ......................................................................................................... 67
4 CAPÍTULO 3: MODELADO DEL NEGOCIO .......................................................... 69
4.1 Introducción .......................................................................................................... 69
4.2 Reglas del Negocio ............................................................................................... 69
4.3 Modelo de Casos de Uso del Negocio .................................................................. 73
4.3.1 Actores del Negocio ...................................................................................... 73
4.3.2 Casos de Uso del Negocio ............................................................................. 73
4.3.3 Diagrama de Casos de Uso del Negocio ....................................................... 76
4.4 Modelo de Análisis del Negocio ........................................................................... 77
4.4.1 Trabajadores del Negocio .............................................................................. 77
4.4.2 Entidades del Negocio ................................................................................... 79
4.4.3 Diagrama de Clases de Negocio .................................................................. 104
4.5 Realización de los Casos de Uso del Negocio .................................................... 109
4.5.1 Especificación de los Casos de Uso del Negocio ........................................ 109
4.5.2 Diagramas de Proceso ................................................................................. 129
4.5.3 Lista de las Actividades a Automatizar ....................................................... 136
4.6 Conclusiones ....................................................................................................... 138
5 CAPÍTULO 4: REQUERIMIENTOS ........................................................................ 139
5.1 Introducción ........................................................................................................ 139
5.2 Especificación de los Requerimientos del Software ........................................... 139
5.2.1 Requerimientos Funcionales........................................................................ 139
5.2.2 Requerimientos No Funcionales .................................................................. 147
5.3 Modelo de Casos de Uso del Sistema ................................................................. 151
5.3.1 Especificación de los Actores del Sistema .................................................. 151
5.3.2 Diagrama de Actores del Sistema................................................................ 153
5.3.3 Diagrama de Paquetes del Sistema .............................................................. 153
5.3.4 Diagramas de Casos de Uso del Sistema por Paquete ................................. 154
5.4 Atributos de los Casos de Uso del Sistema......................................................... 156

VI
 5.5 Especificaciones Alto Nivel de los Casos de Uso del Sistema ........................... 158
5.6 Especificaciones Detalladas de los Casos de Uso del Núcleo Central ............... 174
5.7 Modelo Conceptual ............................................................................................. 214
5.7.1 Diagrama del Modelo Conceptual ............................................................... 214
5.7.2 Diccionario del Modelo Conceptual ............................................................ 215
5.8 Conclusiones ....................................................................................................... 231
6 CAPÍTULO 5: ARQUITECTURA DE SOFTWARE ............................................... 232
6.1 Introducción ........................................................................................................ 232
6.2 Diagrama de los Casos de Uso más significativos para la Arquitectura del
Software ......................................................................................................................... 232
6.3 Metas de la Arquitectura de Software ................................................................. 233
6.4 Restricciones de la Arquitectura de Software ..................................................... 234
6.5 Mecanismos Arquitecturales ............................................................................... 235
6.6 Tácticas de Arquitectura ..................................................................................... 237
6.7 Vista Lógica de la Arquitectura de Software ...................................................... 239
6.7.1 Capa de Presentación ................................................................................... 243
6.7.2 Capa de Tareas Programadas ....................................................................... 243
6.7.3 Capa del Servicio ......................................................................................... 244
6.7.4 Capa de Negocio .......................................................................................... 244
6.7.5 Capa de Datos .............................................................................................. 244
6.8 Vista de Implementación de la Arquitectura de Software .................................. 245
6.9 Vista de Despliegue de la Arquitectura de Software .......................................... 248
6.9.1 Servidor Lenovo System x3550 M4 ............................................................ 249
6.9.2 Servidor Lenovo System x3650 M5 (Servidor de Aplicaciones Web) ....... 249
6.9.3 Servidor Lenovo System x3650 M5 (Servidor de Servicios) ...................... 249
6.9.4 Google Cloud ............................................................................................... 250
6.9.5 Textlocal Cloud ........................................................................................... 250
6.9.6 PC-Interna.................................................................................................... 251
6.9.7 Smartphone .................................................................................................. 251
6.9.8 Servidor NAS - Netgear RN31441E ........................................................... 251
6.9.9 Balanceador de Carga .................................................................................. 251
6.9.10 Servidor Lenovo ThinkServer TS150.......................................................... 251
6.10 Conclusiones ....................................................................................................... 251
7 CAPÍTULO 6: CALIDAD Y PRUEBAS DEL SOFTWARE ................................... 253
7.1 Introducción ........................................................................................................ 253

VII
 7.2 Plan de la Calidad del Software .......................................................................... 253
7.2.1 Política de Calidad ....................................................................................... 253
7.2.2 Objetivos de Calidad ................................................................................... 254
7.2.3 Normatividad Aplicable .............................................................................. 255
7.2.4 Métricas de Calidad del Software ................................................................ 257
7.2.5 Análisis de Resultados de la Medición ........................................................ 264
7.3 Pruebas del software ........................................................................................... 267
7.3.1 Plan de Pruebas ............................................................................................ 267
7.3.2 Caso de Pruebas del CUS07_Generar Hojas de Ruta.................................. 275
7.3.3 Caso de Pruebas del CUS18_Monitorear Despacho de Pedidos ................. 281
7.4 Conclusiones ....................................................................................................... 312
8 CAPÍTULO 7: CONSTRUCCIÓN ............................................................................ 313
8.1 Introducción ........................................................................................................ 313
8.2 Patrones de la Solución Propuesta ...................................................................... 313
8.2.1 Diagrama de Patrones del Sistema .............................................................. 313
8.2.2 Especificación Detallada de los Patrones Seleccionados ............................ 317
8.3 Modelo de Datos ................................................................................................. 330
8.3.1 Modelo de Datos Físico del Sistema ........................................................... 330
8.3.2 Diccionario de Datos ................................................................................... 331
8.4 Análisis de Resultados del Proyecto ................................................................... 340
8.5 Conclusiones ....................................................................................................... 343
9 CAPÍTULO 8: GESTIÓN DEL PROYECTO ........................................................... 344
9.1 Introducción ........................................................................................................ 344
9.2 Registro de Interesados ....................................................................................... 345
9.3 EDT ..................................................................................................................... 346
9.4 Cronograma de Ejecución ................................................................................... 349
9.5 Acta de Aceptación de Entregable ...................................................................... 356
9.6 Gestión de Riesgos .............................................................................................. 362
9.7 Conclusiones ....................................................................................................... 364
10 CONCLUSIONES .................................................................................................. 365
11 GLOSARIO DE TÉRMINOS ................................................................................ 367
12 SIGLARIO ............................................................................................................. 370
13 REFERENCIAS ..................................................................................................... 371
14 ANEXOS ................................................................................................................ 373

VIII
14.1 Matriz de Trazabilidad ........................................................................................ 373
14.2 Misceláneas ......................................................................................................... 377

IX
 ÍNDICE DE TABLAS

Tabla 1. Matriz de Trazabilidad de Problemas con Objetivos Específicos ......................... 57

Tabla 2. Criterios de Evaluación ......................................................................................... 63
Tabla 3. Cuadro Comparativo de Soluciones Encontradas vs. Solución Propuesta ............ 63
Tabla 4. Reglas de negocio .................................................................................................. 69
Tabla 5. Descripción de CUN01_Preparar Pedidos ............................................................ 73
Tabla 6. Descripción de CUN02_Atender Pedidos ............................................................. 74
Tabla 7. Descripción de CUN03_Reprogramar Pedido ...................................................... 74
Tabla 8. Descripción de CUN04_Cancelar Pedido ............................................................. 74
Tabla 9. Descripción de CUN05_Controlar Atención de Pedidos ...................................... 75
Tabla 10. Descripción de CUN06_Reservar Inventario ...................................................... 75
Tabla 11. Descripción de CUN07_Monitorear Atención de Pedidos ................................. 76
Tabla 12. Atributos de EN01_Pedido .................................................................................. 79
Tabla 13. Atributos de EN02_Hoja de Ruta ........................................................................ 80
Tabla 14. Atributos de EN03_Producto .............................................................................. 81
Tabla 15. Atributos de EN04_Sticker de Despacho ............................................................ 82
Tabla 16. Atributos de EN05_Notificación de Nota de Crédito.......................................... 82
Tabla 17. Atributos de EN06_Solicitud de Unidades de Transporte .................................. 83
Tabla 18. Atributos de EN07_Orden de Pedido .................................................................. 83
Tabla 19. Atributos de EN08_Informe de Estado de Pedidos ............................................. 84
Tabla 20. Atributos de EN09_Informe de Ranking de Proveedores de Transporte ............ 85
Tabla 21. Atributos de EN10_Destinatario ......................................................................... 86
Tabla 22. Atributos de EN11_Proveedor ............................................................................ 87
Tabla 23. Atributos de EN12_Informe de Productos de Mayor Rotación .......................... 88
Tabla 24. Atributos de EN13_Chofer .................................................................................. 89
Tabla 25. Atributos de EN14_Unidad de Transporte .......................................................... 89
Tabla 26. Atributos de EN15_Ubigeo ................................................................................. 90
Tabla 27. Atributos EN16_Familia de Producto ................................................................. 91
Tabla 28. Atributos EN17_Tipo de Producto ...................................................................... 91
Tabla 29. Atributos EN18_Motivo de Pedido ..................................................................... 92
Tabla 30. Atributos EN19_Cubicación ............................................................................... 92
Tabla 31. Atributos EN20_Ventana Horaria ....................................................................... 93
Tabla 32. Atributos EN21_Fuente de Abastecimiento ........................................................ 93
Tabla 33. Atributos EN22_Notificación de Devolución de Producto ................................. 94
Tabla 34. Atributos EN23_Notificación de Compra de Producto ....................................... 95
Tabla 35. Atributos EN24_Notificación de Reposición de Producto .................................. 95
Tabla 36. Atributos EN25_Notificación de Cancelación de Pedido ................................... 96
Tabla 37. Atributos EN26_Notificación de Reprogramación de Pedido ............................ 97
Tabla 38. Atributos EN27_Kardex ...................................................................................... 97
Tabla 39. Atributos EN28_Item de Pedido ......................................................................... 98
Tabla 40. Atributos EN29_Informe de Abastecimiento de Productos ................................ 99
Tabla 41. Atributos EN30_Mapa ........................................................................................ 99
Tabla 42. Atributos EN31_GPS ........................................................................................ 100
Tabla 43. Atributos EN32_Pickeador ................................................................................ 101
Tabla 44. Atributos EN33_Cuadrilla ................................................................................. 101

X
Tabla 45. Atributos EN34_Asignación de Cuadrilla a Unidad de Transporte .................. 102
Tabla 46. Atributos EN35_Informe de Productividad de Picking..................................... 102
Tabla 47. Atributos EN36_Notificación de Producto sin Stock........................................ 103
Tabla 48. Especificación de CUN01_Preparar Pedidos .................................................... 109
Tabla 49. Especificación de CUN02_Atender Pedidos ..................................................... 113
Tabla 50. Especificación de CUN03_Reprogramar Pedido .............................................. 116
Tabla 51. Especificación de CUN04_Cancelar Pedido ..................................................... 120
Tabla 52. Especificación de CUN05_Controlar Atención de Pedidos .............................. 122
Tabla 53. Especificación de CUN06_Reservar Inventario ................................................ 124
Tabla 54. Especificación de CUN07_Monitorear Atención de Pedidos ........................... 126
Tabla 55. Requerimientos Funcionales asociados a los Casos de Uso .............................. 139
Tabla 56. Requerimientos Funcionales Generales ............................................................ 146
Tabla 57. Requerimientos No Funcionales........................................................................ 147
Tabla 58. Atributos de los Casos de Uso del Sistema ....................................................... 156
Tabla 59. Especificación de Alto Nivel de CUS01_Actualizar Usuarios ......................... 158
Tabla 60. Especificación de Alto Nivel de CUS02_Actualizar Perfiles ........................... 158
Tabla 61. Especificación de Alto Nivel de CUS03_Administrar Permisos ...................... 158
Tabla 62. Especificación de Alto Nivel de CUS04_Validar Acceso al Sistema ............... 159
Tabla 63. Especificación de Alto Nivel de CUS05_Cambiar Contraseña ........................ 159
Tabla 64. Especificación de Alto Nivel de CUS06_Reservar Pedido ............................... 160
Tabla 65. Especificación de Alto Nivel de CUS07_Generar Hojas de Ruta ..................... 160
Tabla 66. Especificación de Alto Nivel de CUS08_Notificar Unidades Requeridas ........ 161
Tabla 67. Especificación de Alto Nivel de CUS09_Generar Pedidos ............................... 162
Tabla 68. Especificación de Alto Nivel de CUS10_Generar Cubicaciones ...................... 162
Tabla 69. Especificación de Alto Nivel de CUS11_Notificar Ventanas Horarias ............ 163
Tabla 70. Especificación de Alto Nivel de CUS12_Notificar Abastecimiento de Productos
........................................................................................................................................... 164
Tabla 71. Especificación de Alto Nivel de CUS13_Asignar Cuadrillas a Hoja de Ruta .. 164
Tabla 72. Especificación de Alto Nivel de CUS14_Actualizar Productos No Ubicados.. 165
Tabla 73. Especificación de Alto Nivel de CUS15_Confirmar Despacho de Pedidos ..... 166
Tabla 74. Especificación de Alto Nivel de CUS16_Actualizar Atención de Pedidos ...... 166
Tabla 75. Especificación de Alto Nivel de CUS17_Programar Devolución de Productos167
Tabla 76. Especificación de Alto Nivel de CUS18_Monitorear Despacho de Pedidos .... 168
Tabla 77. Especificación de Alto Nivel de CUS19_Generar Informe de Estado de Pedidos
........................................................................................................................................... 169
Tabla 78. Especificación de Alto Nivel de CUS20_Generar Informe de Ranking de
Proveedores de Unidades................................................................................................... 170
Tabla 79. Especificación de Alto Nivel de CUS21_Generar Informe de Productos de
Mayor Rotación ................................................................................................................. 170
Tabla 80. Especificación de Alto Nivel de CUS22_Generar Informe de Productividad de
Picking ............................................................................................................................... 171
Tabla 81. Especificación de Alto Nivel de CUS23_Generar Informe de Abastecimiento de
Productos ........................................................................................................................... 172
Tabla 82. Especificación de Alto Nivel de CUS27_Validar Stock de Productos ............. 173
Tabla 83. Especificación de Alto Nivel de CUS28_Consultar Productos sin Stock ......... 173
Tabla 84. Especificación de Alto Nivel de CUS29_Cargar Productos a Bodega o Nodo 174

XI
Tabla 85. Especificación Detallada de CUS11_Notificar Ventanas Horarias ................... 175
Tabla 86. Especificación Detallada de CUS06_Reservar Pedido ..................................... 178
Tabla 87. Especificación Detallada de CUS07_Generar Hojas de Ruta ........................... 179
Tabla 88. Especificación Detallada de CUS18_Monitorear Despacho de Pedidos .......... 182
Tabla 89. Especificación Detallada de CUS15_Confirmar Despacho de Pedidos ............ 194
Tabla 90. Especificación detallada de CUS12_Notificar Abastecimiento de Productos .. 203
Tabla 91. Especificación detallada de CUS29_Cargar Productos a Bodega o Nodo ........ 205
Tabla 92. Atributos de ES01_Proveedor ........................................................................... 215
Tabla 93. Atributos de ES02_Unidad ................................................................................ 215
Tabla 94. Atributos de ES03_Chofer ................................................................................ 216
Tabla 95. Atributos de ES04_Cuadrilla............................................................................. 217
Tabla 96. Atributos de ES05_Pickeador ........................................................................... 217
Tabla 97. Atributos de ES06_TipoProducto ..................................................................... 218
Tabla 98. Atributos de ES07_FamiliaProducto ................................................................. 218
Tabla 99. Atributos de ES08_Producto ............................................................................. 219
Tabla 100. Atributos de ES09_Bodega ............................................................................. 219
Tabla 101. Atributos de ES10_Zona ................................................................................. 220
Tabla 102. Atributos de ES11_Cliente .............................................................................. 220
Tabla 103. Atributos de ES12_Tienda .............................................................................. 221
Tabla 104. Atributos de ES13_ControllerTienda .............................................................. 221
Tabla 105. Atributos de ES14_Distrito ............................................................................. 222
Tabla 106. Atributos de ES15_MotivoPedido................................................................... 222
Tabla 107. Atributos de ES16_VentanaHoraria ................................................................ 223
Tabla 108. Atributos de ES17_Pedido .............................................................................. 223
Tabla 109. Atributos de ES18_DetallePedido ................................................................... 224
Tabla 110. Atributos de ES19_HojaRuta .......................................................................... 225
Tabla 111. Atributos de ES20_Kardex .............................................................................. 225
Tabla 112. Atributos de ES21_CubicacionPedido ............................................................ 226
Tabla 113. Atributos de ES22_Provincia .......................................................................... 227
Tabla 114. Atributos de ES23_Departamento ................................................................... 227
Tabla 115. Atributos de ES24_DetalleHojaRuta ............................................................... 227
Tabla 116. Atributos de ES25_TipoUnidad ...................................................................... 228
Tabla 117. Atributos de ES26_UnidadChofer ................................................................... 229
Tabla 118. Atributos de ES27_Abastecimiento ................................................................ 229
Tabla 119. Atributos de ES28_Reposicion ....................................................................... 230
Tabla 120. Metas de la Arquitectura de Software ............................................................. 233
Tabla 121. Restricciones de la Arquitectura de Software ................................................. 234
Tabla 122. Mecanismos Arquitecturales ........................................................................... 235
Tabla 123. Tácticas de Arquitectura .................................................................................. 237
Tabla 124. Métricas de Calidad de Software ..................................................................... 257
Tabla 125. Aplicación de métrica de calidad METR_1 Exactitud de datos ...................... 258
Tabla 126. Aplicación de métrica de calidad METR_2 Tiempo de Respuesta ................. 259
Tabla 127. Aplicación de métrica de calidad METR_3 Tiempo de Espera ...................... 259
Tabla 128. Aplicación de métrica de calidad METR_4 Claridad del Mensaje ................. 261
Tabla 129. Roles y Responsabilidades del Equipo de Pruebas ........................................ 267
Tabla 130. Lista de Escenarios del CUS07_Generar Hojas de Ruta ................................. 270

XII
Tabla 131. Lista de Escenarios del CUS18_Monitorear Despacho de Pedidos ................ 270
Tabla 132. Resumen de CP_CUS07_Generar Hojas de Ruta ........................................... 275
Tabla 133. Lista de Escenarios de CP_CUS07_Generar Hojas de Ruta ........................... 275
Tabla 134. Escenario 1 de CP_CUS07_Generar Hojas de Ruta ....................................... 275
Tabla 135. Pasos de Escenario 1 de CP_CUS07_Generar Hojas de Ruta ........................ 276
Tabla 136. Escenario 2 de CP_CUS07_Generar Hojas de Ruta ....................................... 278
Tabla 137. Pasos de Escenario 2 de CP_CUS07_Generar Hojas de Ruta ........................ 278
Tabla 138. Resumen de CP_CUS18_Monitorear Despacho de Pedidos........................... 281
Tabla 139. Lista de Escenarios de CP_CUS18_Monitorear Despacho de Pedidos .......... 281
Tabla 140. Escenario 1 de CP_CUS18_Monitorear Despacho de Pedidos ....................... 282
Tabla 141. Pasos de Escenario 1 de CP_CUS18_Monitorear Despacho de Pedidos ........ 283
Tabla 142. Escenario 2 de CP_CUS18_Monitorear Despacho de Pedidos ....................... 286
Tabla 143. Pasos de Escenario 2 de CP_CUS18_Monitorear Despacho de Pedidos ........ 287
Tabla 144. Escenario 3 de CP_CUS18_Monitorear Despacho de Pedidos ....................... 291
Tabla 145. Pasos de Escenario 3 de CP_CUS18_Monitorear Despacho de Pedidos ........ 291
Tabla 146. Escenario 4 de CP_CUS18_Monitorear Despacho de Pedidos ....................... 297
Tabla 147. Pasos de Escenario 4 de CP_CUS18_Monitorear Despacho de Pedidos ........ 297
Tabla 148. Escenario 5 de CP_CUS18_Monitorear Despacho de Pedidos ....................... 305
Tabla 149. Pasos de Escenario 5 de CP_CUS18_Monitorear Despacho de Pedidos ........ 306
Tabla 150. Tabla tb_actividad ........................................................................................... 331
Tabla 151. Tabla tb_bodega .............................................................................................. 331
Tabla 152. Tabla tb_bodega_zona ..................................................................................... 331
Tabla 153. Tabla tb_chofer ................................................................................................ 331
Tabla 154. Tabla tb_cliente ............................................................................................... 332
Tabla 155. Tabla tb_controller_tienda............................................................................... 332
Tabla 156. Tabla tb_cuadrilla ............................................................................................ 332
Tabla 157. Tabla tb_cubicacion_pedido ............................................................................ 332
Tabla 158. Tabla tb_departamento .................................................................................... 333
Tabla 159. Tabla tb_detalle_hoja_ruta .............................................................................. 333
Tabla 160. Tabla tb_detalle_pedido .................................................................................. 333
Tabla 161. Tabla tb_distrito .............................................................................................. 334
Tabla 162. Tabla tb_familia_producto .............................................................................. 334
Tabla 163. Tabla tb_hoja_ruta ........................................................................................... 334
Tabla 164. Tabla tb_kardex ............................................................................................... 334
Tabla 165. Tabla tb_motivo_pedido .................................................................................. 335
Tabla 166. Tabla tb_abastecimiento .................................................................................. 335
Tabla 167. Tabla tb_reposicion ......................................................................................... 335
Tabla 168. Tabla tb_parametro .......................................................................................... 335
Tabla 169. Tabla tb_pedido ............................................................................................... 336
Tabla 170. Tabla tb_pickeador .......................................................................................... 336
Tabla 171. Tabla tb_proceso ............................................................................................. 336
Tabla 172. Tabla tb_producto ............................................................................................ 337
Tabla 173. Tabla tb_proveedor .......................................................................................... 337
Tabla 174. Tabla tb_provincia ........................................................................................... 337
Tabla 175. Tabla tb_tienda ................................................................................................ 337
Tabla 176. Tabla tb_tipo_producto ................................................................................... 338

XIII
Tabla 177. Tabla tb_tipo_unidad ....................................................................................... 338
Tabla 178. Tabla tb_unidad ............................................................................................... 338
Tabla 179. Tabla tb_unidad_chofer ................................................................................... 338
Tabla 180. Tabla tb_ventana_horaria ................................................................................ 338
Tabla 181. Tabla tb_zona .................................................................................................. 339
Tabla 182. Registro de interesados .................................................................................... 345
Tabla 183. Lista de Riesgos ............................................................................................... 362
Tabla 184. Matriz de Riesgos ............................................................................................ 363
Tabla 185. Glosario de Términos ...................................................................................... 367
Tabla 186. Siglario ............................................................................................................ 370
Tabla 187. Matriz de Trazabilidad .................................................................................... 373

XIV
 ÍNDICE DE FIGURAS

Figura 1. Esquema del Sistema Logístico ............................................................................. 5

Figura 2. ¿Qué es logística? ................................................................................................... 5
Figura 3. Proceso de preparado de pedido ............................................................................. 8
Figura 4. Google Maps ........................................................................................................ 10
Figura 5. OpenStreetMap .................................................................................................... 10
Figura 6. Map Compare Geofabrik...................................................................................... 11
Figura 7. Sistema de Tracking de Vehículos ....................................................................... 12
Figura 8. Live Map de Waze ............................................................................................... 12
Figura 9. Planificación de Rutas con Paradas ..................................................................... 14
Figura 10. Línea de tiempo de la empresa Retail ................................................................ 20
Figura 11. Organigrama de la empresa Retail de Perú ........................................................ 22
Figura 12. Mapa de procesos corporativo de la empresa Retail .......................................... 23
Figura 13. Flujo del Campo de Acción................................................................................ 25
Figura 14. Proceso AS-IS de Preparación de Pedidos ......................................................... 30
Figura 15. Proceso AS-IS de Atención de Pedidos ............................................................. 34
Figura 16. Proceso AS-IS de Reprogramación de Pedido ................................................... 38
Figura 17. Proceso AS-IS de Cancelación de Pedido .......................................................... 42
Figura 18. Proceso AS-IS de Control de Atención de Pedidos ........................................... 46
Figura 19. Diagrama de Árbol del Problema de Incumplimiento de Entrega de Pedidos ... 52
Figura 20. Sincronización de Datos Firebase Realtime Database ....................................... 66
Figura 21. Consola de Firebase ........................................................................................... 66
Figura 22. Panel de Control de Textlocal ............................................................................ 67
Figura 23. Diagrama de Casos de Uso de Negocio ............................................................. 76
Figura 24. DCN de CUN01_Preparar Pedidos .................................................................. 104
Figura 25. DCN de CUN02_Atender Pedido .................................................................... 105
Figura 26. DCN de CUN03_Reprogramar Pedido ............................................................ 105
Figura 27. DCN de CUN04_Cancelar Pedido ................................................................... 106
Figura 28. DCN de CUN05_Controlar Atención de Pedidos ............................................ 107
Figura 29. DCN de CUN06_Reservar Inventario ............................................................. 108
Figura 30. DCN de CUN07_Monitorear Atención de Pedidos ......................................... 109
Figura 31. Proceso TO-BE de CUN01_Preparar Pedidos ................................................. 129
Figura 32. Proceso TO-BE de CUN02_Atender Pedidos ................................................. 130
Figura 33. Proceso TO-BE de CUN03_Reprogramar Pedido ........................................... 131
Figura 34. Proceso TO-BE de CUN04_Cancelar Pedido .................................................. 132
Figura 35. Proceso TO-BE de CUN05_Controlar Atención de Pedidos ........................... 133
Figura 36. Proceso TO-BE de CUN06_Reservar Inventario ............................................ 134
Figura 37. Proceso TO-BE de CUN07_Monitorear Atención de Pedidos ........................ 135
Figura 38. Diagrama de Actores del Sistema .................................................................... 153
Figura 39. Diagrama de Paquetes del Sistema .................................................................. 153
Figura 40. DCUS de Planificación de Pedidos .................................................................. 154
Figura 41. DCUS de Atención de Pedidos ........................................................................ 154
Figura 42. DCUS de Control y Monitoreo de Pedidos ...................................................... 155
Figura 43. DCUS de Seguridad ......................................................................................... 155
Figura 44. Notificación de Ventana Horaria a Cliente ...................................................... 177

XV
Figura 45. Notificación de Ventana Horaria a Controller de Tienda ................................ 177
Figura 46. Hoja de Ruta ..................................................................................................... 182
Figura 47. Monitoreo de Despacho de Pedido .................................................................. 187
Figura 48. Selección de Unidad a Monitorear ................................................................... 188
Figura 49. Dashboard de Pedidos ...................................................................................... 189
Figura 50. Ubicación Actual de la Unidad Monitoreada ................................................... 190
Figura 51. Ubicación del Pedido Atendido ....................................................................... 191
Figura 52. Validación de Unidad Monitoreada ................................................................. 191
Figura 53. Ruta Completa .................................................................................................. 192
Figura 54. Alerta de pedidos que están a punto de sobrepasar su ventana horaria ........... 193
Figura 55. Hoja de Ruta Móvil .......................................................................................... 198
Figura 56. Detalle de Pedido ............................................................................................. 199
Figura 57. Atención de Pedido .......................................................................................... 200
Figura 58. Pedido No Atendido ......................................................................................... 201
Figura 59. Activación de la Cámara .................................................................................. 202
Figura 60. Número de Verificación Incorrecto ................................................................. 203
Figura 61. Notificación de Abastecimiento de Productos ................................................. 205
Figura 62. Pantalla Inicial de Abastecimiento de Productos ............................................. 209
Figura 63. Tipo de Abastecimiento Compra ..................................................................... 209
Figura 64. Popup de Carga de Archivo CSV .................................................................... 210
Figura 65. Plantilla CSV.................................................................................................... 210
Figura 66. Proceso Satisfactorio de Compra ..................................................................... 211
Figura 67. Excel de Lista de Errores en la Carga de Datos ............................................... 211
Figura 68. Validación de Archivo CSV............................................................................. 212
Figura 69. Proceso Satisfactorio de Reposición ................................................................ 212
Figura 70. Lista de Errores en la Carga de Datos .............................................................. 213
Figura 71. Modelo Conceptual .......................................................................................... 214
Figura 72. Diagrama de CUS del Núcleo Central ............................................................. 233
Figura 73. Susbsistemas del Sistema de Gestión de Despacho de Pedidos ....................... 240
Figura 74. Vista Lógica del Sistema Web ......................................................................... 241
Figura 75. Vista Lógica del Web Service .......................................................................... 242
Figura 76. Vista Lógica del Sistema Móvil ....................................................................... 243
Figura 77. Vista de Implementación del CUS18_Monitorear Despacho de Pedidos ........ 245
Figura 78. Vista de Implementación del CUS06_Reservar Pedido................................... 246
Figura 79. Vista de Implementación del CUS15_Confirmar Despacho de Pedido........... 247
Figura 80. Vista de Despliegue de la Arquitectura de Software ....................................... 248
Figura 81. Métrica de Calidad de Exactitud de Datos ....................................................... 264
Figura 82. Métrica de Calidad de Tiempo de Respuesta ................................................... 265
Figura 83. Métrica de Calidad de Tiempo de Espera ........................................................ 266
Figura 84. Métrica de Calidad de Claridad del Mensaje ................................................... 267
Figura 85. Diagrama de Clases de Intercepting Filter ....................................................... 313
Figura 86. Diagrama de Secuencia de Intercepting Filter ................................................. 314
Figura 87. Diagrama de Clases Composite View .............................................................. 314
Figura 88. Diagrama de Secuencia Composite View ........................................................ 315
Figura 89. Diagrama de Clases de View Helper ............................................................... 315
Figura 90. Diagrama de Secuencia de View Helper .......................................................... 316

XVI
Figura 91. Diagrama de Clases de Dependency Injection ................................................. 316
Figura 92. Filtro Java CorsFilter ....................................................................................... 318
Figura 93. Estructura de Página Web con Composite View ............................................. 320
Figura 94. Archivo de configuración de páginas [Link] ................................................ 321
Figura 95. Plantilla [Link]............................................................................ 321
Figura 96. Página cabecera [Link] ............................................................... 322
Figura 97. Declaración de custom tags en JSP .................................................................. 324
Figura 98. Uso de custom tags en JSP ............................................................................... 324
Figura 99. Configurador de instancias de Spring .............................................................. 326
Figura 100. Interfaz PedidoDao ........................................................................................ 326
Figura 101. Clase implementadora PedidoDaoImpl ......................................................... 327
Figura 102. Clase implementadora AdminBLImpl ........................................................... 327
Figura 103. Archivo [Link] de la Móvil ........................................................... 328
Figura 104. Archivo [Link] de la Móvil ....................................................... 329
Figura 105. Modelo Físico de Base de Datos .................................................................... 330
Figura 106. Indicador de Ahorro por Costo de Flete (Empresa Retail Perú, 2018) .......... 340
Figura 107. Indicador de Ahorro en Capacidad de Personal (Empresa Retail Perú, 2018)
........................................................................................................................................... 341
Figura 108. Indicador de Ahorro en Horas de Planificación (Empresa Retail Perú, 2018)
........................................................................................................................................... 342
Figura 109. Indicador de Disminución de Incumplimiento de Entrega (Empresa Retail
Perú, 2018) ........................................................................................................................ 342
Figura 110. EDT de Proyecto Informático 1 ..................................................................... 346
Figura 111. EDT de Proyecto Informático 2 ..................................................................... 347
Figura 112. EDT de Proyecto Informático 3 ..................................................................... 348
Figura 113. Cronograma de ejecución de Proyecto Informático 1 – Página 1 .................. 349
Figura 114. Cronograma de ejecución de Proyecto Informático 1 – Página 2 .................. 350
Figura 115. Cronograma de ejecución de Proyecto Informático 1 – Página 3 .................. 351
Figura 116. Cronograma de ejecución de Proyecto Informático 2 - Página 1................... 352
Figura 117. Cronograma de ejecución de Proyecto Informático 2 - Página 2................... 353
Figura 118. Cronograma de ejecución de Proyecto Informático 3 - Página 1................... 354
Figura 119. Cronograma de ejecución de Proyecto Informático 3 - Página 2................... 355
Figura 120. Acta de Aceptación Proyecto Informático 1 .................................................. 356
Figura 121. Acta de Aceptación Proyecto Informático 2 – Requerimientos del Sistema . 357
Figura 122. Acta de Aceptación Proyecto Informático 2 – Arquitectura de Software y
Prueba de Concepto ........................................................................................................... 358
Figura 123. Carta de Aprobación de Tema de Tesis ......................................................... 359
Figura 124. Acta de Aceptación Proyecto Informático 3 – Calidad y Prueba de Software
........................................................................................................................................... 360
Figura 125. Acta de Aceptación Proyecto Informático 3 – Patrones de la Solución y
Modelo de Datos ................................................................................................................ 361
Figura 126. Web de Consulta de Pedidos .......................................................................... 377
Figura 127. Web de Detalle de Pedidos ............................................................................ 377
Figura 128. Web de Orden de Pedido................................................................................ 378
Figura 129. Web de Cubicaciones de Productos ............................................................... 378
Figura 130. Sticker de Despacho ....................................................................................... 379

XVII
Figura 131. Hoja de Ruta ................................................................................................... 379

XVIII
1 INTRODUCCIÓN
En este proyecto de tesis se presenta el tema segmentado en siete capítulos. Capítulo 1,
fundamentos teóricos, capítulo 2, propuesta de solución, capítulo 3, modelado del negocio,
capítulo 4, requerimientos, capítulo 5, arquitectura de software, capítulo 6, calidad y pruebas
de software, capítulo 7, construcción y finalmente, en el capítulo 8, la gestión del proyecto.

En el presente proyecto la propuesta son las automatizaciones de algunos procesos ya

existentes además de proponer nuevos procesos que permitan mejorar y controlar la gestión
de despacho de pedidos de la empresa Retail.

El no tener control sobre la operación logística, se convirtió en uno de los factores críticos
de la operación, la misma que no permitía conseguir los niveles de atención esperados. La
gestión de pedidos es uno de los procesos más importantes de la empresa, ya que este es un
acuerdo y compromiso entre el cliente y la empresa que provee productos y servicios, en el
que el cliente espera lo solicitado, en el tiempo, lugar y precio adecuado.

El principal problema de la empresa Retail es la ineficiencia que se tiene en la gestión de

despacho de pedidos, lo que conlleva a una mala imagen y pérdida de potenciales clientes
por la demora en la entrega de pedidos, por el incumplimiento en las horas acordadas y por
las equivocaciones en las entregas por el ineficiente control de stock.

Es por estas razones que la empresa Retail, se ve en la necesidad de poder contar con una
solución sistémica que permita tener el control de la operación en tiempo real, con el uso de
tecnología y manejo de información la cual facilite el control de toda la operación, desde el
preparado de pedido, hasta la entrega en el punto final, permitiendo así la disminución en
los tiempos de proceso, optimación de recursos, reducción de costos, lo que dará como
resultado el mejoramiento en los niveles de servicio.

Las empresas del tipo retail, tienen en común que la situación problemática del proceso de
preparación de pedidos se vuelve un proceso bastante complejo. Esto se ve reflejado en todas
las actividades en las cuales se generan gran cantidad de información, como por ejemplo la
entrada de los pedidos al sistema, disponibilidad de stock, preparación de pedidos, y por
último la carga y envío del producto al punto final, todos estos datos son vitales para el
correcto funcionamiento del proceso.

1
Para la presente propuesta, se trabajó con la empresa Retail, que es la empresa líder en el
mundo retail (productos de mejoramiento para el hogar) de Latinoamérica. Los procesos, en
su mayoría manuales que se adecuaban en gran medida a las necesidades del negocio, están
volviéndose ineficientes, lo cual está generando retraso en las entregas de los pedidos,
reclamos y molestias por parte de los clientes.

Se evidencia como problemática, los ineficientes procesos de preparación de pedidos,

control de pedidos no atendidos, para la gestión de despacho en la empresa Retail.

El objetivo aparte de automatizar los procesos existentes es la de proponer nuevos procesos

que ayuden a complementar el sistema propuesto, permitiendo así tener el control total de la
operación, para poder encaminar los resultados al mejoramiento de los niveles de servicio.

Como objetivos específicos se presentan, la optimización de rutas de despacho de pedidos,

cálculo automático de la demanda de unidades de transporte, optimización de carga, cálculo
de ventana horaria, actualización en línea de los estados de los pedidos.

Así mismo, incrementar la eficiencia en los procesos de picking y despacho de productos, y

asegurar la confiabilidad del stock de inventarios.

Por los motivos expuestos, se propone un sistema de información que permita la

optimización de los procesos de generación de hojas de ruta, disminución en los tiempos del
proceso de picking y despacho, control del stock de la compañía, aumento en los niveles de
servicio, disminución de las devoluciones y reclamos, y así satisfacer los objetivos
específicos del presente proyecto.

2
2 CAPÍTULO 1: FUNDAMENTOS TEÓRICOS
2.1 Introducción
En este capítulo se presenta el marco teórico, objeto de estudio, campo de acción, análisis
crítico de los problemas de información.

Se desarrollan cada uno de los puntos mencionados anteriormente con la finalidad de poder
tener un claro entendimiento, tanto del negocio, como de las tecnologías a usar en el
desarrollo de la solución propuesta. Es por eso que se describen muy a detalle los
fundamentos teóricos del negocio y tecnologías actuales, lo que permite tener un claro
entendimiento del escenario en el que se desenvuelve la solución propuesta.

Así mismo, conocer la organización objetivo, visión, misión, objetivos estratégicos, el

organigrama y finalmente el mapa de procesos, de la empresa Retail, permite centrarse en el
conocimiento de la empresa, que es fundamental para el entendimiento de la problemática
actual, y la necesidad de una inmediata solución.

También se detalla el campo de acción, a fin de poder entender cuál es el espectro que cubre
la solución propuesta, se describen los procesos del negocio que se encuentran relacionados
al objeto de estudio, y descripción de los sistemas vinculados al campo de acción.

Finalmente, en el análisis crítico de los problemas de información, se describirá la situación

problemática y los problemas a resolver. Hacer énfasis en la importancia del correcto
desarrollo de este punto, puesto que es el punto de partida de todo el proyecto, y el motivo
por el cual, se hace necesaria la propuesta de solución y su implementación.

2.2 Marco Teórico

2.2.1 Fundamentos Teóricos sobre el Negocio
[Link] Retrospectiva y Evolución de la Logística
El concepto de logística en lo que respecta al mundo de los negocios no tiene más de dos
décadas, aunque hay que indicar que su aplicación viene vinculada con la historia militar,
mejor dicho, a partir de la segunda guerra mundial (Mora García, 2010).

Se puede definir también la logística como una actividad que añade valor mediante la gestión
eficiente entre los flujos de abastecimiento y distribución de los productos (Ragàs Prat,
2012).

3
La misión básica de la logística consiste en poder trasladar los productos que pudieran ser
bienes o servicios, en el lugar idóneo, en el momento preciso, bajo las condiciones
solicitadas, procurando con esto la máxima contribución posible a la rentabilidad de la
empresa.

La tendencia creciente en el uso de la palabra logística deviene del impulso de una de las
funciones más importantes del marketing, que es el énfasis en su enfoque de satisfacción al
cliente. La idea que acompaña esta tendencia es el de time to market, o mejor dicho tiempo
de demora entre la recepción del producto en las fuentes de abastecimiento y su distribución
física.

Es muy importante poder hacer la diferenciación entre dos conceptos que muy comúnmente
se confunde entre sí, y son los de distribución física o también llamado reparto, y logística.

La distribución física es un concepto originado en el marketing e introducido por los Estados

Unidos a finales de los años sesenta, y refiere a la unión de 5 grandes subsistemas que son:
transporte, almacenaje, embalaje, carga/descarga y distribución, soportado por un sistema
de información.

Mientras que la logística, está más ligada a los procesos de obtención, producción y ventas
(Mora García, 2010).

Para un mejor entendimiento del trabajo desarrollado, será muy importante basarnos en los
conceptos básicos de la logística, pero por, sobre todo, el entendimiento del proceso de
distribución física, que es un símil al concepto de atención de pedidos utilizado en el
proyecto desarrollado.

4
 Figura 1. Esquema del Sistema Logístico
(Mora García, 2010)
En base a los conceptos expresados, se puede definir a la logística como el proceso de
gerencia de toda la cadena de abastecimiento iniciando desde la materia prima, hasta el punto
donde finalmente es entregado para su consumo o uso (Ragàs Prat, 2012).

Para efecto de este proyecto desarrollado, la propuesta es para todas las empresas retail que
comercializan productos que se adquieren mediante los proveedores, la empresa Retail no
es una empresa productora, no hace transformación de materia prima, y el punto final es la
entrega del pedido al cliente.

Figura 2. ¿Qué es logística?

(Mora García, 2010)

5
[Link] Objetivos de la Logística
Uno de los objetivos de la logística, es que, mediante su correcta administración, permita
aumentar las ventajas competitivas de cara a los competidores, permitiendo la captación de
nuevos clientes y fidelizando a los propios. Este proceso debe de generar un importante
ingreso económico a la empresa, obtenido de la venta de productos y servicios, esto se va a
lograr siempre y cuando se lleve una correcta sincronización con las actividades de
abastecimiento de productos, distribución física, manejo de información brindada por los
sistemas vinculados, tiempos de respuesta, administración de stock de productos, estudio de
la demanda y servicio al cliente.

Otro de los objetivos fundamentales de la logística, es que, mediante la correcta

administración de los recursos, se genere utilidades a la compañía producto de la reducción
de costos. Es muy importante remarcar que, aunque la racionalización de recursos pueda
parecer una buena práctica en esta parte del proceso, esta no deberá poner en peligro la
satisfacción del cliente.

Es por eso que es muy importante tener una sensibilización respecto a los costos que engloba
todo el proceso de atención de pedido, puesto que el precio de los productos en un mundo
globalizado como el nuestro lo pone el cliente, más no la empresa (Mora García, 2010).

Se tiene lo siguiente: PRECIO MERCADO – COSTO = UTILIDAD.

[Link] Gestión de Transporte y Distribución Física de Carga

Hablar de la gestión de transporte hace referencia a todas las actividades que intervienen de
forma directa o indirecta en la consecución del traslado de productos o servicios desde el
punto de partida, bodegas o almacenes, hasta los puntos de entrega correspondientes, esto
bajo las condiciones establecidas en los acuerdos de servicio, costo y seguridad.

Es muy importante resaltar, que la gestión del transporte cumple una función más que
importante en el desarrollo del proceso de distribución, ya que finalmente, es la imagen que
representa a la empresa de cara al cliente, y sobre este proceso recaen muchos aspectos
sensibles de la calidad de servicio, de los costos de la operación, y los cálculos para las
inversiones de la empresa.

Hay que precisar, que si bien, la idea que se tiene respecto a la palabra transporte es la de
trasladar un producto o servicio de un punto de partida, almacenes, hacia los puntos de
destino, se hace imprescindible poder realizar un par de aclaraciones:

6
 Los tiempos de transporte no solo involucran en tiempo propio del traslado, sino que
abarca desde que los productos se encuentren listos en el muelle de carga de cada
almacén, hasta la descarga final en los puntos de destino, lo que conlleva a contemplar
aspectos tales como carga y descarga de las unidades de transporte, tiempos de espera a
los clientes, transbordos, etc.
 Para que la gestión de transporte tenga éxito, es muy importante que el responsable, no
solo cumpla con sus actividades cotidianas, sino que sea capaz de poder involucrarse en
los planes estratégicos que defina la empresa, para que pueda adaptarse a las necesidades
en el corto plazo.

Es de conocimiento que la calidad de servicio se rige de acuerdo con las exigencias del
mercado, relacionado a los siguientes aspectos:

 Rapidez y puntualidad en la entrega.

 Fiabilidad en los tiempos comprometidos.
 Seguridad e higiene en el transporte.
 Cumplimiento de las condiciones establecidas con el cliente (fechas de entrega, tiempos
de entrega, etc.).
 Información y control permanente del transporte (Mora García, 2010).

[Link] Preparación de Pedidos

Junto con el proceso de logística y distribución, se hace fundamental hablar de un proceso
que complementa el proceso de distribución, llamado preparado de pedido, conocido
también como picking de productos.

Este proceso, es realizado previo al proceso de distribución, y se considera uno de los más
críticos dentro de la atención de pedidos, sobre este también recae el factor crítico de
satisfacción al cliente, cualquier demora en este, impactará directamente en la consecución
del éxito del proceso.

El proceso de preparación de pedidos se describe como la actividad de recolectar productos

de una ubicación física dentro de un almacén, y trasladarlos a un lugar de consolidado para
proceder a armar el pedido, y que este sea transportado al lugar de destino.

Este proceso es uno de los que genera más costos dentro de la operación logística, por los
siguientes factores: es necesaria de acuerdo con la demanda de pedidos, la intervención de

7
gran cantidad de recurso humano cualificado (operarios), el tiempo de demora en la
ejecución de esta actividad, puesto que demanda desplazamientos dentro del almacén, y el
bajo nivel de automatización que se pueden realizar en este proceso.

Es por eso, que se puede deducir que este proceso impacta de forma directa la productividad
de toda la cadena logística, convirtiéndose muchas veces en el cuello de botella. Es por eso,
que se hace necesario que las personas que administran estos procesos enfoquen sus
esfuerzos en la reducción de tiempos y eficiencia en los procesos para reducir los costos de
la operación, haciendo uso de la tecnología, mejorando la productividad, y por sobre todo
aumentando la calidad del servicio.

Figura 3. Proceso de preparado de pedido

(Carro Lupardo, 2015)
Finalmente, hay que tener en cuenta que el proceso de preparación de pedido no aporta valor
alguno al producto, no obstante, influye en mantener la satisfacción del cliente. Este último
se constituye en un factor estratégico para las empresas, ya que de dicha satisfacción va a
depender la captación y fidelización de nuevos clientes, que es la meta de toda empresa. La
satisfacción del cliente no solo dependerá de la ofrecer de productos en categorías y
cantidades, sino también a su disposición inmediata, su empaquetado, etiquetado y correcta
documentación (Carro Lupardo, 2015).

8
2.2.2 Fundamentos Teóricos sobre las Tendencias y Tecnologías Actuales
[Link] Geolocalización
La geolocalización es un término que se confunde con localización, georreferenciación,
GPS, información geográfica y mapas, lo cual se va a aclarar.

La localización consiste en que todo objeto tiene una ubicación específica en el espacio
geográfico.

La información geográfica consiste en la información asociada con una localización

relacionada al terreno.

El mapa es una representación abstracta de la superficie terrestre de manera impresa o digital.

La georreferenciación consiste en la técnica de posicionamiento espacial (GPS, redes Wi-fi,

redes móviles y dirección IP) para localizar un objeto en una zona geográfica definida por
un sistema de coordenadas y datum específico.

Finalmente, la geolocalización consiste en un conjunto de tecnologías que permiten localizar

un objeto en el espacio físico con su información obtenida de Internet que se visualizan en
el mapa mediante una técnica de georreferenciación y se analizan mediante el uso de
instrumentos cartográficos y herramientas de la estadística espacial (Beltrán López, 2016).

[Link] Herramientas de Geolocalización

A continuación, se mencionarán las principales herramientas que permiten desarrollar webs
geoespaciales:

[Link].1 Mapas Privados y Comerciales

Son mapas creados por empresas privadas que los comercializan como geo portales donde
se puede ver la Tierra en 3D, vista de calles, etc. Entre las principales empresas se mencionan
a Google Maps y Bing Maps.

9
 Figura 4. Google Maps
(Google LLC, 2018)

[Link].2 Mapas Públicos y Oficiales

Son mapas realizados por la administración pública a escala regional o estatal que los ponen
al servicio de todos los ciudadanos. Estos portales permiten importar rutas o generar rutas
nuevas en un Web Map Server.

[Link].3 Mapas Sociales y Ciudadanos

Son los mapas elaborados por los ciudadanos de manera colaborativa y que es actualizada al
minuto como por ejemplo OpenStreetMap.

Figura 5. OpenStreetMap
(OpenStreetMap, 2018)

10
[Link].4 Comparadores de Mapa
Permite integrar en una pantalla divida en cuatro cuadrantes diferentes bases de datos
geoespaciales. Son útiles para identificar la información que ofrece cada mapa sobre una
zona concreta. El más conocido es Geofabrik.

Figura 6. Map Compare Geofabrik

(OpenStreetMap, 2017)

[Link].5 Servicios para hacer Mapas

Son herramientas que permiten realizar mapas online en Internet de forma gratuita o pagada.
Estos servicios permiten la publicación de datos cartográficos en la nube. Entre los más
populares se mencionan a My Maps de Google Maps, Wikiloc, ArcGis Online y Carto DB.

[Link].6 Mapas que cuentan Historias (storymaps)

Son mapas que se convierten en una herramienta de comunicación que combina mapas con
texto narrativo, imágenes y contenido multimedia con la finalidad de contar tu historia. La
empresa más popular que implementa este tipo de mapas es ESRI.

[Link].7 Mapa a Tiempo Real

Actualmente hay diversas compañías que incorporan mapas que geolocalizan en tiempo real
la ubicación del usuario para mostrarle los establecimientos cercanos a su posición como lo
realiza la aplicación Foursquare.

También existe la geolocalización de vehículos por medio de GPS (Sistema de

Posicionamiento Global), GSM (Sistema Global para las Comunicaciones Móviles) o GPRS

11
(Servicio General de Paquetes Vía Radio) sobre un mapa en tiempo real, mostrando
información de los mismos, así como las rutas que está realizando.

Figura 7. Sistema de Tracking de Vehículos

(Skylabs Solution, 2018)
Por último, aplicaciones de tráfico y navegación como Waze donde los conductores
comparten información en tiempo real de las carreteras y el tráfico, lo que permite adaptar
la trayectoria en función de los cambios que se producen por accidentes, vías bloqueadas,
cogestión vehicular, etc. (Beltrán López, 2016).

Figura 8. Live Map de Waze

(Waze Mobile, 2018)

12
[Link] Base de Datos de Tiempo Real
En un sistema de tracking de unidades, el aplicativo móvil de cada unidad almacena
constantemente su ubicación actual GPS en una instancia de la base de datos de tiempo real
la cual puede estar alojada en la nube o en un servidor. Por ende, la Base de Datos de tiempo
real recibe dichos datos y los sincroniza enviándole las actualizaciones de la ubicación de
cada unidad a la aplicación de monitoreo, las cuales se pueden presentar en un mapa.

Hoy en día el mercado está requiriendo que las aplicaciones móviles manejen e interactúen
con información en tiempo real como por ejemplo un chat, la actualización constante de la
ubicación GPS de un usuario, interacción en redes sociales, etc.

Cabe resaltar, que este tipo de Base de Datos tiene la particularidad de usar la tecnología de
Websockets donde se crear un canal de comunicación bidireccional entre el cliente y el
servidor, estableciendo reglas para detectar cambios en los datos, y sincronizarlos entre los
clientes, otorgándole de esta forma la funcionalidad de tiempo real. En el mercado existen
las Base de Datos de tiempo real como Firebase Realtime Database (versión estable) y
Firebase Cloud Firestore (versión beta), ambas de Google (Google LLC, 2018).

[Link] Problemas de Enrutamiento

Es necesario considerar que el problema de la distribución de los pedidos afecta
considerablemente los costos logísticos y la satisfacción del cliente, por lo que han ido
ganando importancia debido a la gran cantidad de productos a distribuir, el incremento de la
congestión vehicular y la incertidumbre de los clientes al no saber a qué hora llegará su
pedido. A continuación, se describe los principales problemas de enrutamiento:

[Link].1 Problema del Agente Viajero (TSP)

Este problema consiste en asignar una ruta de entrega de mercancías a un vehículo que parte
y retorna al almacén con una capacidad ilimitada, cuyo objetivo es minimizar la distancia
total recorrida.

[Link].2 Problema de Enrutamiento de Vehículos (VRP)

Este problema es una extensión del TSP con la diferencia que hay una flota de vehículos con
la misma capacidad, cuyo objetivo es minimizar los costos de transportación tales como la
distancia total recorrida, el número de vehículos y el tiempo total de transporte.

13
[Link].3 VRP con Ventanas de Tiempo (VRPTW)
En este problema las mercancías deben entregarse a cada cliente dentro de ventanas de
tiempo definidas, la cual debe ser satisfecha, sino se considera una penalización al no
cumplirse dicha restricción.

[Link].4 VRP con una Flota Heterogénea y Ventanas de Tiempo (HFVRPTW)

En este problema se considera una flota de vehículos con diferentes capacidades, además
debe de satisfacer las ventanas de tiempo para la entrega de mercancías en cada punto, y la
demanda de los clientes en una ruta que no debe exceder la capacidad del vehículo (Journal
Of Industrial Engineering & Management, 2017).

Finalmente, existe una gran gama de algoritmos que resuelven estos tipos de problema de
enrutamiento y tomando en cuenta el objetivo que se quiere lograr alcanzar como minimizar
la distancia recorrida para el ahorro de combustible, minimizar el tiempo de entrega o
maximizar la carga de productos. Por ejemplo, Google Maps Direction API cuenta con un
algoritmo que resuelve el problema de enrutamiento VRP (Google LLC, 2018).

Figura 9. Planificación de Rutas con Paradas

(Google LLC, 2018)

14
[Link] Investigación y Análisis de Plataformas Tecnológicas
El desarrollo del presente documento se sustenta en la investigación y análisis del uso de las
plataformas tecnológicas que permiten dar seguimiento en línea a la entrega de los pedidos,
este ha sido uno de los principales problemas en la logística de las empresas retail en los
últimos años. Sin embargo, existen soluciones que resuelven estos problemas, permitiendo
tener control total de esta parte de la operación, y así mejorar la experiencia del usuario, los
procesos logísticos, los indicadores de entrega y ahorro en los costos.

Empresas top de la región tales como Paraíso, Promart, Grupo Gloria, Costeño, Santa Elena,
Linio, Ripley, El Tigre, Ransa se han visto beneficiadas con el uso de estas plataformas
tecnológicas, mejorando considerablemente los indicadores y la relación con sus clientes.

Se analizaron los beneficios de varias plataformas que actualmente operan en el mercado,

no obstante, se optó por dos de las mejores respecto a sus funcionalidades, beneficios,
implementación e historias de éxito.

En primer lugar, tenemos la plataforma Beetrack, que es un referente en los procesos de

despacho de la logística, teniendo como principal foco la última milla, es por eso que según
algunas estadísticas el uso de la plataforma generará un aumento del 5% en la retención de
sus clientes, que permitirá mejorar los resultados en el futuro hasta en un 75%.

Otros de los beneficios importantes a mencionar son que, en un tiempo no mayor a 90 días,
se evidencia una disminución hasta de un 50% en el tráfico de llamadas dirigidas al Call
Center por parte del cliente, esto se ha logrado mediante el envío de notificaciones y SMS
con los tiempos aproximados de entrega de los pedidos.

Por ejemplo, PROMART una de las más grandes cadenas de Retail a nivel nacional cuenta
con 25 tiendas distribuidas estratégicamente, pertenece al grupo INTERCORP, que a su vez
cuenta con 34 empresas que ayudan a la consolidación de un grupo empresarial fuerte que
busca el bienestar de las familias peruanas.

En el 2016 PROMART realiza una gran inversión en tecnología, se implementa un nuevo

canal de venta, que es la venta por e-commerce, y los resultados han sido bastante favorables
hasta la actualidad con un crecimiento sostenible, no obstante, la necesidad de poder contar
con un sistema confiable de tracking de pedidos hizo que se tome la decisión de adquirir
Beetrack.

15
Beetrack es el sistema encargado del tracking de las unidades de transporte de mercadería,
viene operando con PROMART dos años y medio convirtiéndose en un gran socio
estratégico para poder canalizar mejor las ventas, y mejorar el servicio de despacho a
domicilio. La gran ventaja que les permite el uso de esta plataforma es que no solo tienen
trazabilidad de las unidades de despacho, sino que además han incluido una trazabilidad al
servicio técnico o armado de muebles dentro de la cadena de suministros, con lo que se
consigue que el cliente sepa todo el tiempo el estado de su entrega y adicionalmente del
servicio técnico o armado, con esto, las consultas y reclamos al call center, han disminuido
considerablemente.

El uso de Beetrack no solo ha mejorado la experiencia del cliente, sino que además ha
incrementado el indicador de efectividad de despachos a un 98.5% en el periodo 2019 (9 de
cada 10 entregas se realizan a tiempo), eso contribuye a que el cliente sepa que con esta
herramienta son más confiables y seguros al momento de la entrega.

Paraíso del Perú es la empresa número uno en la fabricación y entrega de colchones, y una
de sus principales características es buscar constantemente la calidad y el descanso
placentero de sus clientes. Tiene 50 años de operación en el Perú y cuenta con 1500
trabajadores, tienen un solo centro de distribución ubicado en la Provincia Constitucional
del Callao, desde donde realiza los despachos a domicilio a nivel nacional, así como a las
cadenas retail de distribución.

El Gerente de TI y Distribución indica que diariamente la operación soporta un promedio

de 300 despachos, y uno de los más grandes problemas que tenían es que no podían brindarle
al cliente la hora exacta de la entrega del producto.

Es a partir de la adquisición de Beetrack, que el problema se superó ampliamente, refiere el

Gerente de TI y Distribución. Este rol al estar a cargo de dos unidades que intervienen en el
proceso de despacho puede dar fe de que la integración con los sistemas de información
propios de la compañía ha sido totalmente transparente.

El uso de Beetrack es sencillo no solo para la empresa, sino también para el usuario final,
gracias a la integración con el sitio web, siendo su usabilidad bastante intuitiva.

Por otro lado, el Gerente Comercial comenta que el uso del Beetrack en la compañía ha sido
sumamente provechosa, el número total de llamadas por consultas de los clientes ha
disminuido en un 50% en el periodo 2019, eso demanda mucho menor tiempo a nivel

16
operativo, porque el cliente puede realizar sus consultas de pedidos a través de la Web pero
siempre soportado por Beetrack, con lo que la capacidad del call center queda liberada, para
que puedan ser asignada a otro tipo de funciones (Logística 360 "The Supply Chain
Magazine", 2019).

En segundo lugar, tenemos DRIVIN, otro referente a nivel LATAM de la logística de última
milla, esta plataforma al igual que la anterior, muestra beneficios bastantes considerables en
el tema de los despachos y controles de entregas de productos a los clientes finales. Al igual
que nuestra propuesta, esta plataforma se respalda en el uso de tecnología de geolocalización
para poder tener un control en tiempo real de toda la operación, la misma que permite realizar
ofertas de valor tales como la reducción de ventanas horarias, gestión de choferes de las
unidades de transporte, reducción de costos de transporte hasta de un 30% al gestionar rutas
optimas de despacho.

Una de las empresas que utiliza la plataforma es RANSA, operador logístico con 80 años de
trayectoria a nivel LATAM, tiene presencia en 7 países y 34 ciudades de la región. Sus
operaciones cuentan con una fuerza de más de 6.500 colaboradores altamente calificados y
especializados en brindar servicios a la medida a cada uno de sus clientes, generándole
ventaja competitiva y permitiéndoles diferenciarse en su sector.

El brindar a sus clientes la posibilidad de realizar seguimiento en tiempo real a sus

operaciones, disminuir y estimar con exactitud los tiempos de entrega, así como la
inmediatez para resolver requerimientos con visión de negocio fueron los puntos clave para
que RANSA eligiera a DRIVIN como su partner tecnológico en la digitalización de sus
procesos de planificación, gestión en vivo y monitoreo de entregas.

Esta iniciativa surge como parte de las acciones que la compañía está implementando para
digitalizar su cadena de valor y brindar a sus clientes la misma experiencia de trazabilidad,
visibilidad y conexión que hoy en día tiene el mercado para usuarios finales, apuntando así
a brindar servicios ágiles, eficientes y adaptables.

Como ejemplo aprovechando la integración entre WAZE y Google Maps para la conducción,
se logró reducir los tiempos de entrega y estimar la hora exacta de llegada del pedido.

Tras la implementación de DRIVIN, RANSA logró el objetivo esperado: optimizar las rutas
de los despachos y visibilizar en tiempo real su flota.

17
Hoy, en su portal R360, RANSA permite la visualización de operaciones de entrega de los
clientes que utilizan esta herramienta. Además, consiguió que en menos de dos meses el 90%
de su flota se conecte diariamente a la plataforma. Sumado a esto, se ha podido reconocer
las eficiencias tangibles que brinda DRIVIN, por ejemplo, las horas acumuladas
identificadas en esperas durante las entregas, KPI que es medible y del cual se tiene
visibilidad en el cumplimiento del proceso de entregas con tiempos exactos. Estos
indicadores permiten trabajar a futuro en mejoras continuas.

Otra empresa beneficiada con DRIVIN es Tigre, multinacional brasileña creada en 1941 y
con fuerte presencia internacional. Líder en soluciones para la construcción civil y cuidado
del agua, sus productos atienden mercados tales como predial, infraestructura, riego e
industrial, además de retail, todo lo relacionado a fabricación de tubos y conexiones en PVC.
Este grupo tiene presencia en 30 países, con más de 6000 funcionarios, 11 plantas en Brasil,
y 9 en el exterior.

Motivados por la búsqueda de mejorar los servicios a sus clientes, en destacar por sobre los
competidores directos y estandarizar su proceso de despacho, es que Tigre confió en
DRIVIN como solución tecnológica. Fue en el año 2017 que se realizó la primera
implementación de la plataforma en Chile, y hoy ya se encuentra desplegada y operando en
Argentina, Perú, Bolivia, Uruguay, Colombia, Ecuador y Paraguay.

La confianza en DRIVIN fue generada porque encontraron en ellos el compromiso que

necesitaban. Trabajar con un equipo capaz de adaptar el software a las diversas necesidades,
que propone mejoras y nuevas funcionalidades de forma permanente es lo ideal, además es
un producto versátil de fácil adaptación y adecuación y que ofrece muchas ventajas en el
proceso logístico, lo mejor de todo es el fortalecimiento de la relación Empresa-Cliente,
comenta la Gerenta de Logística Internacional de la compañía Tigre.

Antes de DRIVIN, Tigre realizaba sus operaciones logísticas de manera manual, desde la
asignación de unidades, mercadería dentro de las unidades, incluso el orden de las entregas.
En todos los países que se ha implementado DRIVIN, se ha generado un ahorro de costos,
debido a la eficiencia en los procesos, por ejemplo, las mejoras en la optimización de las
rutas y el aumento de la tasa ocupacional de los camiones que en líneas generales ha crecido
en un 5%.

18
Hoy notablemente, Tigre ha mejorado en el servicio a sus clientes, y transparentando toda la
información del proceso de entregas. Los clientes de Tigre se sienten 100% informados
sobres sus pedidos, tiempos de entrega y datos del transporte, permitiéndole coordinar mejor
sus tiempos y espacios para la recepción (The Founders Systems, 2019).

Según lo expuesto, las tecnologías utilizadas en la mejora de los procesos de entrega de

pedidos han demostrado ser exitosas en empresas referentes del mundo logístico.

Por todo lo anterior expuesto, y teniendo evidencia del éxito en las empresas top a nivel
LATAM, nuestra propuesta emula el desarrollo de las plataformas tecnológicas descritas
anteriormente, en función al uso de la tecnología, por ejemplo, para la geolocalización y
trazado de ruta óptima se utilizó Google Maps Direction, para las notificaciones desde los
GPS de las unidades de transporte se hizo uso de Firebase Real Time Database, y finalmente
para el tema de la mensajería hacia los clientes se hizo uso del Text Local. Estas tecnologías
nos han permitido ofrecer una serie de beneficios tales como el trazado de ruta óptima,
trazabilidad del pedido en tiempo real, asignación de unidades de transporte, reducción de
ventanas horarias, envío de mensajería, ahorro en costos entre otros.

Pero adicionalmente a todos estos beneficios que se ofrecen de manera tradicional, hemos
complementado nuestra propuesta con un nuevo proceso que permite el control integro en
el manejo de los inventarios de la compañía, generando así valor directo en las operaciones
de cara al cliente final. En esta etapa, se trabaja con umbrales desde los que se generan alertas
que notifican la necesidad de la reposición de un producto en particular, esto prevé el quiebre
de stock, permitiendo así mantener los inventarios sincerados disponibles para el cliente
final. No solo se manejará el control de la falta de stock, sino que además se ha implementado
un módulo que permite la carga de nuevo inventario ya sea por proceso de reposición o
compra directa al proveedor, con lo que el control y movimiento de inventario se tiene
controlado en su totalidad en tiempo real, elevando así el indicador de disponibilidad de
productos, lo que mejora considerablemente la experiencia de compra del cliente, teniendo
como resultado la disminución en los reclamos, la disminución del porcentaje de tasa de
abandono en las compras Web, y potenciando unos de los indicadores más importantes en
el mundo retail como el NPS (Net Promoter Score) que permite medir la lealtad de los
clientes de una empresa basándose en las recomendaciones.

19
2.3 Objeto de Estudio
2.3.1 Organización Objetivo
La empresa Retail1 objeto de estudio, es la cadena más grande de materiales para el
mejoramiento del hogar de Latinoamérica fundada en Chile en 1952, que opera en el sector
retail donde ha alcanzado una posición de liderazgo en el mercado de tiendas para el
mejoramiento del hogar (Empresa Retail S.A., 2018).

La empresa Retail se focaliza en desarrollar y proveer soluciones a los proyectos de

construcción de sus clientes, además de satisfacer las necesidades de mejoramiento y
decoración de sus hogares, ofreciendo excelencia en el servicio, integridad en su trabajo y
un fuerte compromiso con la comunidad (Empresa Retail Perú S.A., 2018).

Actualmente, la empresa Retail se encuentra presente en países como Brasil, Uruguay, Chile,
Colombia, Argentina y Perú, contando con una fuerza laboral de 20,000 empleados
(Empresa Retail S.A., 2018).

Por último, para comprender el crecimiento y evolución de la empresa Retail se muestra un

resumen de su historia en la siguiente figura.

Figura 10. Línea de tiempo de la empresa Retail

(Empresa Retail Perú S.A., 2018)

1
Por motivos de confidencialidad no se hace referencia al nombre de la empresa.

20
2.3.2 Misión
“Desarrollarnos con innovación y sostenibilidad, ofreciendo los mejores productos, servicios
y asesoría, al mejor precio del mercado, para inspirar y construir los sueños y proyectos de
nuestros clientes” (Empresa Retail S.A., 2018).

2.3.3 Visión
“Ser la empresa líder de proyectos para el hogar y construcción que, mejorando la calidad
de vida, sea la más querida, admirada y respetada por la comunidad, clientes, trabajadores y
proveedores en América” (Empresa Retail S.A., 2018).

2.3.4 Objetivos Estratégicos

Tal como señala la empresa Retail (2016), sus objetivos estratégicos son:

 Desarrollo de nuevos diseños para distinguirlos de la competencia.

 Formar alianzas estratégicas con las constructoras de viviendas.

 Mantener un excelente nivel de recordación de la marca.

 Atender un porcentaje de la demanda insatisfecha.

 Asegurar la calidad de los productos.

 Focalización de la promoción de nuestros productos y servicios.

 Establecer alianzas estratégicas con la competencia directa para formar barreras de

entrada.

 Modernizar e incorporar más activamente la tecnología e internet en toda su

operación.

 Implementar un sistema de control de calidad en los ingresos de nuestros productos a

vender.

 Incorporar la mejor gente para mejorar posición competitiva.

 Mejorar el servicio de entrega de pedidos al cliente.

Asimismo, se muestran resaltados los objetivos estratégicos involucrados con el campo de

acción.

21
2.3.5 Organigrama
En la siguiente figura se muestran resaltadas las áreas involucradas con el campo de acción de la Gerencia General de la empresa Retail de Perú.

Figura 11. Organigrama de la empresa Retail de Perú

(Empresa Retail Perú S.A., 2013)

22
2.3.6 Mapa de Procesos
En la siguiente figura se muestran resaltados los procesos operativos involucrados con el
campo de acción.

Figura 12. Mapa de procesos corporativo de la empresa Retail

(Elaboración propia, 2018)

[Link] Gestión de Recepción de Pedidos

Proceso encargado de recibir los pedidos que solicitan despacho a domicilio por parte del
cliente. Estos se atenderán desde los nodos de Lurín, Angamos y San Miguel, de acuerdo
con la ubicación geográfica de la dirección del cliente y a la cobertura de entrega asignada a
cada nodo. Cabe resaltar que, dentro de este gran proceso, se tiene un gran reto, y es el
mejoramiento y desarrollo del proceso de control de stock de mercadería en tiempo real.

[Link] Gestión de Atención de Pedidos

Proceso encargado del armado y atención del pedido de clientes desde los nodos. El proceso
de armado consiste en la ubicación física del producto dentro del nodo, apilarlo en un pallet,
y dejarlo listo en el muelle, para su posterior carga en las unidades de transporte.

[Link] Gestión de Distribución de Pedidos

Proceso encargado de realizar a partir del armado de pedidos, el transporte de los mismos
hacia la dirección de despacho consignada por el cliente.

23
[Link] Gestión de Compras
Proceso encargado de solicitar las cotizaciones a los diversos proveedores, para gestionar la
compra de productos.

[Link] Gestión de Reposición de Productos

Proceso encargado de reponer los productos faltantes desde la bodega a las diversas tiendas
de lima y provincia.

[Link] Gestión de Atención al Cliente

Proceso encargado de la atención telefónica de las consultas y pedidos de los clientes en el
proceso atención de pedido.

2.4 Campo de Acción

2.4.1 Breve Descripción
El campo de acción abarca todo el flujo completo del proceso de atención del pedido del
cliente. Este proceso inicia, con la recepción de las órdenes de pedidos, que son producto de
las ventas generadas por los clientes desde la web, o diferentes tiendas. Estas, son atendidas
por etapas. Una vez que se tiene el consolidado de las órdenes de pedidos generadas, estas
se dividen según el distrito de entrega, para poder generar una ruta óptima y orden de entrega,
este proceso dentro de la logística es conocido como pre-ruteo. Luego de esto, los pedidos
son asignados a una unidad de transporte según su volumetría y destino. Paralelamente a este
proceso de asignación, se trabaja en el picking de productos, que no es más que la extracción
de productos desde sus ubicaciones físicas en bodega (cubicación), para que pasen a ser parte
de la preparación de pedidos. Este proceso se repite con cada uno de los productos que
forman parte del pedido. Luego estos pedidos son trasladados a un espacio físico (muelle)
para la carga respectiva a las unidades de transporte. Se le informa al transportista, que su
unidad ya ha sido cargada con todos los pedidos asignados, y se le hace entrega de la hoja
de ruta que él debe seguir para garantizar la entrega de cada uno de los pedidos. Cabe
mencionar que, dentro de todo este flujo, existen dos procesos adicionales, que son el de
reprogramación y cancelación de pedidos, los mismos que son detallados más adelante en el
presente documento. Finalmente, el transportista verifica la carga de la unidad de transporte
y procede a partir desde la fuente de abastecimiento para realizar la ruta programada y las
entregas pactadas.

24
Es muy importante mencionar, que las empresas que brindan el servicio de transporte de
pedidos son tercerizadas, lo cual, en ocasiones, se vuelve un limitante para el control de la
operación.

Figura 13. Flujo del Campo de Acción

(Elaboración propia, 2018)

2.4.2 Procesos del Negocio

[Link] Proceso de Preparación de Pedidos (AS-IS)
Este proceso es iniciado por el coordinador DAD, que es el encargado de solicitar la
preparación de cada uno de los pedidos, para que estos sean posteriormente despachados a
cada destinatario.

Luego según la volumetría del total de pedidos, el despachador haciendo uso de la

experiencia adquirida en sus años de servicio y con riesgo de poder incurrir en un error,
realiza la solicitud de unidades de transporte para que estas puedan ser cargadas con la
mercadería y salgan a su ruta programada. Es necesario indicar, que actualmente no se cuenta
con una herramienta que permita generar de forma automática una ruta óptima considerando
el tráfico promedio, el sentido de las vías, la distancia y el tiempo más corto que puedan
impactar en el proceso de la atención del pedido. Este proceso básicamente es controlado

25
por la empresa proveedora de transporte, lo que conlleva a depender del músculo logístico
del proveedor para alcanzar el objetivo de la empresa.

Se procede con la impresión de las órdenes de pedido, que no es más que el detalle de los
pedidos de los destinatarios, además, se imprime la cubicación de cada producto contenido
en los pedidos.

Posteriormente el pickeador procede a consultar las órdenes de pedido a preparar, prepara el

pallet que contendrá cada uno de los pedidos preparados. Consultará la ubicación del
producto dentro de la bodega y retira el producto de su posición, mediante el uso de la pistola
de radiofrecuencia, descuenta el stock del producto en un proceso conocido como Picking.
Este producto es colocado en el carrito de almacén, y se repite el proceso hasta completar el
total de productos solicitados. Es recién en esta parte del proceso donde se hace la reserva
de los productos para los destinatarios, mientras estos no sean pickeados, se corre el riesgo
de poder disponer en la web o en la tienda ese stock a otro potencial comprador. Por lo que
realizar este proceso lo más inmediatamente posible desde que se realiza la venta se vuelve
en una actividad crucial.

Una vez que el pallet se encuentra al tope de su capacidad (medida definida por el negocio),
se sella el bulto con film de seguridad, y se elabora un sticker de despacho, este es colocado
en la parte superior del bulto para poder identificarlo con facilidad.

Este bulto soportado por el pallet es trasladado al muelle de despacho, que es el lugar donde
se acopian los bultos antes de ser cargados a la unidad de transporte, los estibadores cargan
los bultos a la unidad de transporte, hasta lograr la capacidad de la unidad previamente
definida (variable definida por el negocio).

Ahora, se verifica si no se tiene más bultos por cargar, esta verificación es fundamental,
porque de no cargar la totalidad de pedidos, se incurriría en un retraso con el destinatario
final.

En el caso de que los pickedores no encuentren un producto dentro del almacén, estos se
informan, para que puedan ser comunicados al cliente, a fin de saber si aún desea la entrega
del pedido por los productos con los que si se cuenta con stock.

En esta parte del proceso cuando el 100% de los pedidos se encuentran cargados en la unidad
de transporte, y si el destinatario previamente no ha elegido un rango horario, se procede a

26
enviarle la ventana horaria al destinatario, la que está comprendida entre 8 y 9 horas. La
ventana horaria es el rango horario propuesto al destinatario en el que está programado que
le llegue su pedido.

Finalmente se procede a informar al despachador que los pedidos han sido preparados en su
totalidad, y se encuentran listos para salir a la ruta programada, quedando solo la
conformidad del Coordinador DAD.

[Link] Proceso de Preparación de Pedidos (TO-BE)

En esta parte del documento, se detallará el proceso de preparar pedido, pero con mayor
énfasis en las actividades a automatizar y las nuevas propuestas, que son las que finalmente
le darán el valor agregado a la propuesta presentada.

En el proceso de preparación de pedido (AS-IS), se indica que la solicitud de las unidades

de transporte destinadas para el despacho de los pedidos se hace en base a la experiencia del
despachador, pero también se hace hincapié en que este cálculo es susceptible a errores. No
obstante, en esta parte, el proceso de preparar pedido (TO-BE), presenta una considerable
mejora respecto al proceso vigente (AS-IS), y es que los cálculos para poder determinar la
demanda de unidades para cada jornada laboral de trabajo se hacen de forma automática.

Y es que, en primer lugar, se tiene una base de datos con todas las unidades disponibles de
los diversos proveedores de transporte con las que se cuentan para el proceso de atención de
pedido, estas deben estar debidamente segmentadas por capacidad de carga y tipo de carga.
Para realizar un cálculo preciso de las unidades que se requieren, es muy importante contar
con la información de las variables logísticas de cada uno de los productos. Las variables
logísticas no son más que las características en peso, ancho, altura y profundidad de cada
uno de los productos que forman parte del stock de la compañía.

Teniendo ambos datos, las unidades de transporte disponibles y las variables logísticas de
los productos, se construye un algoritmo que permita calcular de forma automática la
demanda de unidades de transporte por jornada laboral. Cabe resaltar que este algoritmo
propuesto, estará en la capacidad, por su flexibilidad, de poder realizar cálculos precisos aun
interactuando con otras configuraciones del sistema, tales como % de capacidad de carga de
unidades, cantidad de pedidos máximos por unidad (a solicitud por ruta extensa). Existe la
posibilidad que se requiera el uso específico de una unidad de transporte, por ejemplo, una
unidad de 2 TN de capacidad para un determinado distrito, esta está sujeta a las

27
configuraciones definidas por el usuario, sin embargo, el algoritmo permite el cálculo
preciso de las unidades de transporte. Considerar que cada unidad de transporte requerida
tiene asignada una cuadrilla, que no es más que un conjunto de cuatro (4) pickeadores,
encargados de la ubicación física de los productos en el almacén.

Con esta mejora propuesta, al tener un cálculo automatizado, por ende más exacto, no solo
existe un ahorro en el tiempo del cálculo en las unidades de transporte, sino que también hay
un ahorro en el costo incurrido en este proceso, toda vez que se parte de la premisa, que ante
un mal cálculo en la solicitud de unidades de transporte, aun cuando no des uso de alguna
de ellas, el costo en el que se incurre es por la totalidad del pedido, el proveedor de transporte
te ofrece un servicio, no te exime de los riesgos.

Otra mejora propuesta dentro de este proceso es la automatización de la actividad de

elaboración de hojas de ruta, de igual manera, en el (AS-IS) de este proceso, se hace énfasis
en que, en la actualidad, no se cuenta con una herramienta que permitiera de forma
automática y complementada con la información del cliente, poder trazar la ruta óptima que
permita llegar en el tiempo prometido al lugar de destino.

Es por eso que, soportado por el uso de una de una herramienta de geolocalización, se puede
elaborar las hojas de ruta de forma automática, generando una mejora significativa en este
proceso, disminuyendo así, considerablemente el margen de error en el trazado de rutas
programadas. Adicionalmente, el beneficio de tener el orden de carga de pedidos a la unidad
de transporte, producto de la información obtenida en la actividad anterior descrita.

Continuando con las mejoras propuestas, se tiene el control de los productos sin stock, para
este caso, todos los productos no encontrados en el almacén son ingresados por los
pickeadores a una base de datos, la que tendrá vinculado el producto a un pedido. Este
registro, genera una tarea al call center, donde estos, son los encargados de realizar el
contacto con el cliente con el fin de informar que el producto solicitado no se encuentra
disponible. Una vez informado esto, se envía la notificación a contabilidad para que emitan
la nota de crédito por los productos no encontrados.

En la secuencia del proceso, otra actividad automatizada es la del envío de ventana horaria
de entrega de pedido, en el proceso actual (AS-IS) se indicaba que el promedio de espera en
la entrega del pedido es de 9 horas, ahora, gracias al uso de la herramienta de geolocalización
google maps direction que permite la optimización de ruta en tiempo y distancia tomando

28
en cuenta el tráfico histórico, se está en capacidad de prometer un tiempo de espera de 4
horas para la entrega de los pedidos.

Sabiendo de la importancia de la información con la que se cuenta, gracias al uso de la

herramienta de geolocalización, se pueden establecer configuraciones al sistema propuesto
que permitan cada vez mejorar la administración del proceso. Esta última parte es
fundamental de cara al crecimiento de las organizaciones, puesto que el constante
aprendizaje de un proceso generará el músculo logístico que toda empresa retail desearía
administrar.

Finalmente, el resto de las actividades no automatizadas dentro de este gran proceso

complementan de manera precisa la propuesta innovadora planteada.

29
Figura 14. Proceso AS-IS de Preparación de Pedidos
(Elaboración propia, 2018)

30
[Link] Proceso de Atención de Pedidos (AS-IS)
Este proceso es iniciado por el coordinador DAD, quien solicita la atención de los pedidos,
luego el chofer que es el encargado de llevar cada uno de los pedidos a su lugar de destino
consulta su hoja de ruta, a cada uno de los transportistas de manera impresa se le entrega una
hoja de ruta que tiene de manera detallada los pedidos asignados, las direcciones
programadas, así como el orden de entrega sugerido (esto último no siempre se respeta).

En primera instancia se dirige al primer punto programado en su ruta, una vez que llegue al
destino, va a verificar la presencia del destinatario, si este se encontrara, lo primero que
realizará es validar si se trata de una entrega programada, o un recojo, esto se puede dar en
caso se tratase de una queja o requerimiento del destinatario. Si se tratase de lo primero, con
la ayuda de los estibadores se descargará el pedido de la unidad, y se le entregará al
destinatario. El chofer solicitará la firma de conformidad de la entrega en la orden de pedido,
le entregará una copia al destinatario, y se procede a cerrar el pedido como atendido. Esto
último es un control manual en la hoja de ruta del transportista, puesto que el pedido es recién
cerrado como atendido en el sistema una vez que el transportista verifique que no tiene más
pedidos por entregar y retorne al punto de partida, que en este caso es la bodega ubicada en
Lurín.

En caso el destinatario no se encuentre en la dirección destino, el transportista procederá de

manera manual a marcar la orden de pedido como no atendida, esperando una futura
reprogramación, y continuará con su ruta programada.

Cabe resaltar que para los métodos de entrega de pedido existen dos modalidades, una la que
se ha descrito líneas arriba llamada despacho a domicilio, y la segunda llamada retiro en
tienda, ambos son seleccionados por los clientes al momento de la compra.

El método de retiro en tienda se caracteriza porque el cliente hace la compra ya sea vía web
o en tienda y selecciona, no que le lleven el pedido a casa, sino que selecciona una tienda
para que este finalmente lo recoja. Hay que mencionar además que en el despacho a
domicilio existe un recargo por concepto de flete, muy por el contrario, en el RT es
totalmente gratuito.

Este proceso consiste básicamente en el mismo proceso de preparado de pedido, el

tratamiento de la mercadería y la carga a las unidades de transporte es similar, lo único que
va a diferenciarlas, es que, en el primer caso, el pedido va con destino hacia la casa del

31
cliente, mientras que, en este último, se deja el pedido en la tienda seleccionada por el
destinatario. Hacer mención que los pedidos llegados a tienda son recibidos por el controller
de la tienda, para ubicarlos en el lugar de despacho, y sean entregados a los destinatarios en
los días pactados de recojo. Una vez que la unidad de transporte deja los pedidos en la tienda,
se procede a marcar las órdenes de pedido de forma manual como entregado a tienda.

El destinatario o aceptante tiene que firmar la conformidad de la entrega del pedido, esta
información es enviada a bodega mediante mail para que pueda darse por atendida la entrega
del pedido, en ocasiones esta finalización la puede realizar la misma tienda con autorización
del gerente de tienda.

[Link] Proceso de Atención de Pedidos (TO-BE)

Inicia este proceso de atención de pedidos el coordinador DAD, quién es, el que solicita la
atención de pedidos. Una vez concluido el proceso de preparación de pedido, el chofer
consulta la hoja de ruta asignada a la unidad de transporte, luego, según el orden de entrega
calculado, se dirige a punto de contacto, y verificará in situ, la presencia del destinatario.

Si el destinatario está en el punto de contacto, el chofer revisará en la hoja de ruta, si el caso

se trata de una entrega o de un recojo (esto aplica en caso de reprogramación o cancelación,
procesos que se detallan más adelante). Si es un recojo, los estibadores proceden a cargar los
productos a la unidad de transporte, y el chofer en su aplicativo móvil, registra el pedido
como recogido, de tratarse de una entrega, se procederá a realizar la descarga del producto,
para que sea recibido por el destinatario, luego, se le solicita al aceptante la firma en señal
de conformidad, y se le hace entrega de una copia de la orden de pedido.

Tener presente, que existen dos tipos de atención de pedidos, unos es la entrega en casa del
cliente, y la segunda retiro en tienda, que es una modalidad de compra, donde se le dispone
al cliente el mix de tiendas, para que este pueda seleccionar el lugar de recojo de su pedido,
evitando así, el pago por flete.

Es muy importante remarcar, que el tratamiento de los dos tipos de atención de pedidos es
similar, la diferencia recae en los estados de la reserva que actualiza el chofer. Si el pedido
es entregado en casa del cliente, se actualiza en el aplicativo móvil como pedido atendido,
de ser la de tipo retiro en tienda, el chofer cuando llegue al punto de contacto, que en este
caso es una tienda, actualiza el estado del pedido como entregado a tienda. Esto solo en caso

32
de que la tienda elegida por el cliente no cuente con el stock del producto seleccionado, y
este, tenga que ser atendido desde otra fuente de abastecimiento, como la bodega.

Si el destinatario no se encuentra en el punto de contacto, el chofer registrará en el aplicativo

móvil el pedido como no atendido. Esta información es leída por el call center en un proceso
llamado reprogramación de pedidos (proceso que se detalla más adelante). Importante
mencionar que el transportista está en la capacidad de poder hacer más de una visita al cliente
que no encontró en la primera vuelta programada. Esto está sujeto a los tiempos de entrega
programados previamente.

Finalmente, el coordinador DAD recibe la conformidad de la atención del pedido,

indistintamente de cuál sea la modalidad de atención.

33
Figura 15. Proceso AS-IS de Atención de Pedidos
(Elaboración propia, 2018)

34
[Link] Proceso de Reprogramación de Pedido (AS-IS)
El proceso de reprogramación de pedido es iniciado siempre por una solicitud del cliente,
este puede llamar desde su domicilio, o desde cualquiera de las tiendas a nivel nacional, para
solicitar la reprogramación de su pedido.

La solicitud de reprogramación de pedido es atendida por el call center, este verifica todos
los pedidos del cliente, y se valida el seleccionado para la reprogramación. Si el pedido tiene
fecha de entrega hoy, entonces el pedido está en ruta, por lo que se tendrá que contactar vía
llamada telefónica con el chofer de la unidad de transporte, para indicarle que no debe
realizar la entrega, y continuar con su recorrido.

Ahora, si el caso fuera que la entrega del pedido es con fecha posterior, el call center tiene
que validar ciertos parámetros para poder aceptar la nueva fecha de entrega solicitada por el
cliente.

La reprogramación del pedido tiene que ser como mínimo 24 horas posteriores a la llamada
del cliente.

La reprogramación del pedido si implica cambio de dirección a otra ciudad, el tiempo de

entrega estará sujeto a la cantidad de días de viaje hacia esa provincia que se configuren en
el sistema.

La reprogramación de pedido no implica ningún cambio de productos, ni adición, ni

disminución del total.

Una vez concluida la validación, se procede a registrar la nueva fecha de entrega solicitada
por el cliente, y se le informa que el proceso ha concluido de forma exitosa.

Según la nueva fecha programada, el pedido seguirá su flujo normal de despacho, hasta la
entrega final al cliente.

Una gran deficiencia en esta parte del proceso es que no se cuenta con un histórico de
reprogramaciones por motivos, los que permitirían identificarlos y trabajar sobre ellos, con
la finalidad de mejorar la experiencia de compra de cada uno de los clientes.

35
[Link] Proceso de Reprogramación de Pedido (TO-BE)
Este proceso de reprogramar pedido en el (TO-BE), de igual forma que en el (AS-IS), se
inicia con la participación del cliente, quién solicita que su pedido sea reprogramado para
una fecha futura.

De la misma manera que en el proceso de cancelación de pedido, es el call center el

encargado de atender cada uno de los requerimientos del cliente. En este caso, que el call
center consultará los pedidos que tiene el cliente. Una vez seleccionado el pedido a
reprogramar, se ingresa al sistema la nueva fecha de entrega elegida, tener en cuenta que no
hay posibilidad de poder elegir una fecha de reprogramación, que no sea posterior a hoy. El
sistema cuenta con las validaciones respectivas para eliminar este tipo de inconsistencias.

Una vez actualizada la fecha en el sistema, se valida si el pedido ha sido entregado, esto
quiere decir que se revisará si el pedido está en ruta. En caso fuera así, se envía un aviso al
chofer mediante el aplicativo móvil para que no realice la entrega de ese punto de contacto,
y que continúe con la ruta programada.

De la misma manera, por seguridad, se valida si la reprogramación del pedido es porque el

producto pueda estar en mal estado (esto solo aplica en caso la entrega coincida con la
llamada de reprogramación). En caso el producto tenga algún defecto, se actualizará el
estado del producto, como defectuoso.

Como el ámbito de este proceso, incluye el movimiento de stock de productos, es necesario

la evaluación de umbrales, para la toma de decisiones, según sea el caso (recordar que los
umbrales, según configuración, envían alertas a los responsables sobre los saldos
actualizados).

Esta información que se obtiene a partir del cálculo de umbrales permite tomar acciones
tanto para la reposición en tienda, como para compra de productos a bodega, sobre aquellos
productos a los que se les está agotando el stock, el seguimiento de esta actividad es de vital
importancia de cara a la experiencia de compra que tienen los clientes.

También existe la posibilidad de programar recojo de productos en casa del cliente, o la

entrega de estos en tienda, solo en caso lo amerite. Por ejemplo, que el cliente, no quiere un
producto por un tema de matices (el físico no es del mismo color que se exhibe en la web),
solo ahí se registra una reprogramación con recojo.

36
Solo a manera de comentario, explicar, que en caso un pedido sea reprogramado, el
tratamiento que recibe para la entrega de la fecha pactada es el mismo que sufre todas las
reservas en el ciclo regular. Solo que se evitará el proceso de preparar pedido, puesto que el
pedido ya se encuentra separado en una zona especial dentro de la bodega o tienda, para una
futura entrega.

Las reprogramaciones, no contemplan aumento o disminución de las cantidades de

productos ya comprometidas, es decir, el cliente, solo podrá cambiar las fechas de entrega,
más no los productos.

Finalmente, una vez concluida cada una de las actividades que conforman este proceso, se
procede a informar al cliente que su reprogramación ha sido exitosa.

37
Figura 16. Proceso AS-IS de Reprogramación de Pedido
(Elaboración propia, 2018)

38
[Link] Proceso de Cancelación de Pedido (AS-IS)
El proceso de cancelación de pedido siempre es iniciado por una solicitud del cliente y puede
presentarse en dos escenarios los que se procede a describir más adelante.

El proceso inicia con la solicitud del cliente mediante una llamada telefónica, esta puede
darse desde su domicilio o desde cualquiera de las tiendas de la empresa Retail a nivel
nacional, solicitando la cancelación de su pedido. El call center es el encargado de recibir la
llamada, este buscará todos los pedidos que pueda tener el cliente, en esta parte hacer un
paréntesis para explicar el motivo por el cual se buscan todos los pedidos del cliente, y va
relacionado justamente con los dos escenarios que se mencionan al inicio, este refiere a que
la cancelación del pedido, el cliente la puede realizar aun cuando no haya recibido los
productos, o bien, cuando el cliente ya recibió la totalidad de los productos.

Siguiendo con el flujo, se verifica si pedido está en ruta, si la respuesta es positiva,

inmediatamente se dará aviso al chofer vía telefónica para que cancele la entrega del pedido,
y pueda continuar con los demás puntos de entrega.

En caso la respuesta sea negativa, se valida si el cliente recibió o no el producto, si fue

recibido, se cancela el pedido, se envía la notificación a contabilidad para generar la nota de
crédito (proceso dura aproximadamente 15 días). Paralelamente el call center programa el
recojo de los productos desde la casa del cliente, en caso así lo solicite, puede el cliente
también llevarlo directamente a la tienda más cercana. En este punto se tiene que consultar
a la tienda si el producto ha sido entregado y en qué condiciones, para posteriormente generar
una transferencia desde la tienda a la bodega, recién al llegar el producto a la bodega se
evaluará si es apto para pasar al disponible. Finalmente, esta parte del flujo culmina
confirmándole al cliente la cancelación de su pedido e indicándole la fecha del recojo
programada.

Para el caso del recojo, se va a tener que esperar hasta el final del día que el transportista
retorne de toda su ruta programada para poder evaluar si el producto recogido está apto para
ingresar al disponible de la bodega.

En caso el cliente no tenga el pedido en su poder, el call center cancela el pedido, se envía
la notificación de nota de crédito a contabilidad, en automático al cancelar el pedido, se
liberan los productos del reservado, y pasan a formar parte del disponible.

39
Una de las grandes deficiencias de este proceso es que no se tiene un registro de los recojos
que se tienen programados, estos son solicitados mediante correos, o SharePoint generando
tareas manuales propensas al error e incumplimiento con el cliente.

[Link] Proceso de Cancelación de Pedido (TO-BE)

Este proceso es iniciado por el cliente, quien solicita la cancelación de su pedido.

Para atender este requerimiento, el cliente se comunica con el call center vía telefónica, los
mismos, que verifican los pedidos del cliente. Una vez seleccionado el pedido a cancelar, se
registra el cambio de estado de la reserva en el sistema, como pedido cancelado. Es muy
importante el seguimiento a los cambios de estado en cada uno de los procesos, puesto que
es lo que permite, tener información precisa de cada pedido.

Una vez que se actualiza el estado de la reserva en el sistema, se válida para cuando está
programada la entrega (puede darse el caso que el cliente decida cancelar su pedido posterior
a su entrega). En caso la programación sea para el día actual, se envía un aviso mediante el
aplicativo móvil del chofer para que no realice la atención de ese punto de contacto, y
continúe con la ruta programada, si la entrega del pedido es posterior al día de hoy, se afirma
que el pedido no es entregado aún, en ambos casos, se envía una notificación al área de
contabilidad para generar la nota de crédito respectiva. Previamente el call center intentará
poder salvar la venta, ofreciendo diferentes alternativas.

Ahora, si el pedido ya fue entregado, y aun así el cliente decide cancelarlo, se aceptará la
solicitud y se procederá a programar el recojo del producto, en caso así se requiera.

Es en este momento, donde se valida si el producto a recoger se encuentra en óptimas

condiciones para poder ingresarlo al stock disponible de la compañía, de ser este el caso,
aumentará el stock según la cantidad de productos recogidos, caso contrario, el producto
pasará a estado defectuoso.

Ahora, el call center coordina y programa el recojo del producto en el mismo punto, donde
este fue entregado (no se acepta un lugar de recojo distinto al lugar inicial de entrega). Tener
en cuenta que existe la posibilidad de que el cliente pueda entregar el producto en cualquiera
de las tiendas de la compañía.

En los dos casos, se debe comunicar al call center la entrega o recojo del producto para
confirmar la cancelación del pedido.

40
Finalmente, el cliente es informado de que su pedido es cancelado de forma exitosa.

41
Figura 17. Proceso AS-IS de Cancelación de Pedido
(Elaboración propia, 2018)

42
[Link] Proceso de Control de Atención de Pedidos (AS-IS)
Este proceso está enfocado en obtener KPIs de la operación de atención de pedidos, esto
generando un control limitado de cada una de las actividades que conforman este gran
proceso. Se indica un control limitado, puesto que actualmente no se tiene un sistema que
permita un monitoreo (tracking) en línea de todo el proceso, solo se cuenta con reportes
entregados por el mismo proveedor de transporte, convirtiéndose estos últimos en juez y
parte de la operación.

Bajo este esquema de trabajo, el Gerente de Abastecimiento, periódicamente

(semanalmente) solicita un informe general de todas las atenciones de pedidos de la
compañía (despachos a domicilios).

Estos informes son elaborados por el analista de abastecimiento, y constan de tres grandes
reportes:

 Estado actual de los pedidos programados por semana.

 Elaborar un ranking de atenciones por proveedor de servicio de transporte (en ocasiones

se trabaja hasta con 4 diferentes proveedores por día), y clasificarlos por despachos
atendidos, despachos truncos, reprogramaciones, atenciones fuera de ventana horaria.

 En base a las atenciones de pedidos que se tienen programadas, se puede elaborar un

control de los productos de alta rotación, estos resultados puedes ser segmentados por
tienda y por zona geográfica de despacho.

Esta información es de mucha utilidad en la administración de la bodega, puesto que como

el proceso de atención de pedidos implica hacer el Picking de cada producto solicitado, y al
tener la información de los productos de mayor rotación, se estará en capacidad de poder
modificar constantemente las posiciones de encasillado de los productos, esto para optimizar
en tiempo el proceso de Picking. También será de mucha utilidad de cara al proceso de
reposición de productos a cada tienda, puesto que se tendrá la capacidad de proyectar la
demanda de cada tienda.

La información para la elaboración de cada uno de estos tres reportes es extraída de los
propios sistemas de ventas. No obstante, las mediciones que se realizan son a nivel de
volúmenes más no de niveles de satisfacción del usuario, puesto que esa información
sensible es propia de las empresas de transporte.

43
Como se mencionaba anteriormente, una de las grandes deficiencias que se tiene en el tema
de reportarías y KPIs, es la poca información con la se cuenta respecto al desempeño de cada
una de las unidades de transporte, no se tiene control de las rutas utilizadas, no se cuenta con
un control en los tiempos de viajes, en los tiempos de descarga, en los tiempos de recojo, no
se está en capacidad de poder hacer una segunda visita al cliente en caso no se le encontró
en la primera. Adicional a esto, no se puede generar rutas óptimas usando la tecnología de
punta, puesto que este proceso también está bajo el control de los proveedores de transporte.

Todo esto impide poder realizar una buena programación de atención de pedidos, generando
finalmente muchas reprogramaciones o cancelaciones de pedidos, lo cual solo genera
insatisfacción del cliente y grandes gastos de transporte.

Finalmente, este informe es enviado al gerente de abastecimiento para la toma de decisiones.

[Link] Proceso de Control de Atención de Pedidos (TO-BE)

Una de las automatizaciones incorporadas en este proceso recae en la actividad de elaborar
el informe de estado de pedidos, puesto que, como se describe en el (AS-IS) de esta
actividad, la forma de obtener información del estado de las reservas es mediante un reporte
realizado por el proveedor de transporte, que está elaborado en función a la información
brindada por sus transportista, para cuando se tiene el dato solicitado, ya es tarde, se requiere
inmediatez de respuesta en las consultas de los estados de las reservas, puesto que de esta
información, depende el poder brindar alternativas de solución a problemas que se presenten
en el proceso.

Es por eso que, en la automatización de esta actividad, se propone extraer el reporte del
sistema y contar con información en tiempo real del estado de las reservas, permitiendo la
toma de decisiones de manera inmediata, asegurando por, sobre todo, la atención del pedido
en los tiempos prometidos.

A manera de detalle, es preciso mencionar que, para poder obtener los estados en tiempo
real, el sistema debe estar actualizándose de manera permanente con la información brindada
por cada actividad que conforme el proceso de atención de pedidos. Importante asegurar la
actualización de estados, en cada etapa del proceso, esto a bien de contar con la información
precisa y oportuna.

Asimismo, otro de los informes que se añaden a este sistema es el de productividad de

Picking, que mostrará el resultado de todos los productos que el cliente solicita versus los

44
productos encontrados en bodega. En esta parte se tiene visibilidad de uno de los grandes
problemas que adolece la empresa que es la venta de productos sin stock, por un mal manejo
del inventario.

Finalmente, el resto de las actividades no automatizadas dentro de este gran proceso

complementan de manera precisa la propuesta planteada.

45
Figura 18. Proceso AS-IS de Control de Atención de Pedidos
(Elaboración propia, 2018)

46
[Link] Proceso de Reserva Inventario (TO-BE)
Este proceso es una nueva propuesta en el TO-BE, ya que a nivel de proceso no cuenta con
un símil en el AS-IS, esta funcionalidad en el sistema actual se realiza mediante el uso de la
pistola de radiofrecuencia que es una actividad comprendida dentro del proceso de
preparación de pedido, siendo la forma con la que se descuenta el inventario de productos
en la bodega. Pero esto al ser una actividad manual esta propensa a errores, tanto en las
cantidades que se descuentan, como en la posición física del producto que se escanea
denominada cubicación.

Es por esta razón que se propone un nuevo proceso automatizado, el cual contempla poder
realizar el descuento del inventario desde el momento de la validación de la venta, este
descuento es a nivel sistémico, pero al ser inmediato, se minimiza el riesgo de poder disponer
el stock (ya cancelado por el cliente) para futuras compras de clientes distintos.

El proceso es iniciado por el coordinador DAD, quién solicita reservar el inventario una vez
la venta haya sido validada. El proceso de validación de venta aplica solo para el pago con
tarjeta, y consiste en enviar desde la web los datos de la tarjeta a la entidad bancaria, para
que esta, de conformidad y validación del pago. Al ingresar el pedido al sistema, de manera
automática se descontará el stock del producto, para que posteriormente sea extraído desde
su ubicación.

Como se mencionó anteriormente, se incorpora una nueva funcionalidad, y es la de evaluar

un umbral de stock, esto refiere a que, en base a una configuración de cantidades o
porcentajes, el sistema propuesto está en la capacidad de informar el quiebre de stock de
cada producto de la compañía, para así, poder sugerir la reposición en caso sea tienda, o
compra en caso sea bodega de los productos sin stock. El concepto de umbral obedece a un
parámetro configurado para poder dar aviso de la falta de stock de los productos que se
ofrecen para la venta. Como ejemplo lo siguiente, se cuenta con un stock de 100 unidades
de roperos almacenados en la bodega, si se configura para que el umbral sea del 10% de los
productos, este obedecerá a que cuando se haya vendido 90 unidades el sistema informará
que cuentas solo con 10 unidades disponibles, alertando para la toma inmediata de
decisiones. Una empresa retail, nunca debe quedarse sin stock de un producto exhibido, tanto
en tienda como en web.

47
Este manejo de stock en base a umbrales es de gran beneficio, puesto, que permite un tiempo
de reacción inmediato en la compra o reposición de productos, sobre todo a los de gran
demanda por el público, teniendo como resultado, no quedarse nunca desabastecido de los
productos ofrecidos, que finalmente crea una mala experiencia de compra al usuario.
Imaginen el escenario de tener un producto de exhibición en una tienda, y que ya no se cuente
con stock del mismo, al no tener la información precisa y oportuna, no se tiene un proceso
de reposición oportuna, por lo que el cliente solo podrá ver el producto más no adquirirlo, o
en peor de los casos prometerle que el producto le llegará a su domicilio, cuando en realidad
no se cuenta con el stock disponible, el manejo de umbrales elimina esta deficiencia,
generando alarmas configuradas previamente de acuerdo a la necesidad del negocio.

Estas alarmas, no solo van a funcionar como avisos constantes, sino que además van a
generar una comunicación automática que obliga a una toma inmediata de decisión para la
compra o reposición de un producto según sea el caso. Es por eso que es importante resaltar
que se contemplan dos escenarios, reposición a nodo, y compra desde bodega, y esto es
porque los productos para atender un pedido de cliente pueden tener diferentes fuentes de
abastecimiento, esto quiere decir que el producto puede ser despachado tanto desde un nodo
como desde la bodega, o un mix de ellas, esto de acuerdo con donde se tiene almacenado el
stock del producto seleccionado.

Respecto a lo anterior mencionado, existen dos escenarios claramente identificados y

diferentes entre sí. Uno involucra la compra de mercadería directamente desde la compañía
hacia un proveedor (compra desde bodega), mientras que el segundo permite la reposición
de productos desde bodega a nodos (reposición a nodo).

El primero de los escenarios es la compra de productos al proveedor. Para este proceso, el

proveedor primero tiene que llevar la mercadería solicitada previamente mediante una orden
de compra hacia la bodega, con ello, obtiene una guía sellada por el personal de la compañía
que valida la recepción de los productos. Con esta guía, el proveedor procede a preparar el
archivo CSV, plantilla que ha sido descargada previamente. Con la guía sellada, y el archivo
CSV elaborado (información obligatoria para el proceso de carga), el proveedor envía ambos
archivos vía correo electrónico al coordinador DAD de bodega. Este último valida la
información enviada y procede con la carga del archivo CSV al sistema, con lo que se
actualiza el stock en línea, quedando finalmente los productos disponibles para la venta.

48
El segundo escenario detalla el proceso de reposición de productos desde la bodega hacia
los nodos. Para este caso, es el coordinador DAD de bodega el que prepara el archivo CSV
en base a un requerimiento previo. Junto al archivo, coordina el envío de mercadería hacia
el nodo que solicitó la reposición. El coordinador DAD de nodo valida la llegada de
mercadería y lo constata con el archivo CSV previamente enviado (para este escenario la
guía sellada no es un documento obligatorio). Con esta validación realizada, se procede con
la carga al sistema, quedando automáticamente los productos disponibles para la venta en el
nodo.

Continuando con el proceso, y luego de la validación del umbral de los productos solicitados,
se informa tanto a tienda como a bodega, la reposición o compra de productos en caso lo
amerite. Como se menciona anteriormente, esta es una nueva funcionalidad propuesta,
aprovechando la información que se obtiene del proceso de reserva de inventario.

Finalmente, se informa la actualización de la reserva de inventario, y se da conformidad a

este proceso. Remarcar que las actividades no automatizadas que están contempladas en este
proceso complementan de manera precisa la propuesta planteada.

[Link] Proceso de Monitoreo de Atención de Pedidos (TO-BE)

Este proceso también es una nueva propuesta en el flujo de la atención de pedidos. A
diferencia del (AS-IS), en el que este proceso no existe, ahora en el (TO-BE), se propone
contar con un proceso que permite el monitoreo permanente en línea de las unidades de
transporte desde el inicio de las operaciones, esto soportado por la herramienta de
geolocalización.

Este consiste básicamente, en tener un control total en todo momento de las unidades de
transporte, que se encuentran involucradas en proceso de atención de pedidos. Permitiendo
fundamentalmente la resolución de problemas en tiempo de real que puedan presentarse en
el proceso, y que pongan en riesgo la entrega del pedido. Además, mencionar, que el proceso
de monitoreo es bastante visual, porque en un monitor se tiene visibilidad de cada una de las
unidades en ruta, y su trazabilidad.

El proceso es iniciado por el coordinador DAD, el mismo que es el encargado de solicitar el

monitoreo permanente de cada una de las unidades de transporte. Luego, el monitoreador
comienza a monitorear cada una de las unidades que tenga asignado para su seguimiento y
control. Esta actividad de monitoreo inicia desde la carga de pedidos en las unidades de

49
transporte, controlando las horas de salida de cada unidad. Este parte de la actividad es
importante, porque, cualquier retraso que pueda presentarse, impactará directamente en el
cumplimiento de la programación de rutas óptimas.

El proceso de monitoreo como ya se explicó, es constante, en lo que dure todo el flujo de la

atención de pedidos, es justamente por eso que se podrá hacer un control de la adherencia a
la ruta programada en el proceso de preparar pedido. Esto significa que el monitoreador,
controlará que todos los choferes cumplan el recorrido programado que se les asigna, en
función a los resultados obtenidos de la programación de rutas y la adherencia a esta, el
sistema podrá estar en la capacidad de afinar futuras programaciones de rutas optimas, a fin
de mejorar constantemente el músculo logístico que se administra.

Como ya se ha mencionado, una de las actividades involucradas en este proceso, es la de

resolución de problemas presentados, pero se habla de una resolución en tiempo real,
permitiendo la toma de decisiones en el momento oportuno, garantizando así, el
cumplimiento de la entrega de los pedidos en los tiempos prometidos.

En caso el destinatario solicite información de llegada de su pedido, el área de monitoreo, a

través del monitoreador, responderá en línea sobre los tiempos de llegada al destino
consultado, a diferencia del proceso (AS-IS), no es necesaria la comunicación con el
transportista.

Es fundamental poder controlar los cambios de estado de las reservas en cada parada de los
transportistas. También es importante poder controlar las horas de salida y las horas de
llegada de las unidades de transporte, esto permite ir mejorando los cálculos realizados en el
proceso, y poder contar con indicadores reales.

Finalmente, este proceso concluye cuando al cierre de la atención de todos los pedidos
asignados a la unidad de transporte, se le informa al coordinador DAD, la conformidad del
monitoreo de la ruta programada.

2.4.3 Sistemas Automatizados Vinculados con el Campo de Acción

[Link] Sistema de Despacho
Es un sistema web implementado en la empresa Retail que permite gestionar los pedidos de
los clientes que compran los productos ofrecidos por los diferentes canales de venta de la
compañía. Entre sus principales funcionalidades se tiene:

50
 Registro de pedidos.

 Reprogramación de pedidos.

 Cancelación de pedidos.

 Confirmación de entrega de pedidos.

 Generación de hojas de ruta.

 Generación de órdenes de pedido.

 Seguimiento de estados del pedido.

 Control de inventario.

 Ubicación física de productos.

 Registro de unidades de transporte.

 Reportes del proceso de despacho de pedidos.

Por lo tanto, las funcionalidades del Sistema de Despacho son utilizadas en el proceso de
despacho de la siguiente manera:

 Extrayendo las órdenes de pedido registradas que están pendientes a entregar.

 Asignando a los pedidos a entregar una unidad de transporte a través de la generación de

hoja de ruta.

 Realizando el picking de los productos mediante el escaneo de la pistola de

radiofrecuencia que actualiza el stock de los mismos ubicados en los anaqueles del nodo.

 Generando el sticker de despacho con códigos de barra identificadoras de los pedidos.

 Actualizando los estados del pedido a pendiente, reprogramado, cancelado, entregado y

no entregado.

Por último, es importante indicar que el Sistema de Despacho expone servicios web para que
otros sistemas de la compañía puedan obtener y transferir información, tal como el Sistema
de Contabilidad, el Sistema Comercial y el Sistema de Atención de Cajas, con la finalidad
de unificar los diversos procesos realizados por la compañía.

51
2.5 Análisis Crítico de los Problemas de Información
2.5.1 Situación Problemática
A continuación, se muestra el diagrama de árbol del problema principal:

Figura 19. Diagrama de Árbol del Problema de Incumplimiento de Entrega de Pedidos

(Elaboración propia, 2020)

52
2.5.2 Problemas a Resolver
 No se cuenta con una herramienta para calcular la ruta óptima por distancia y tiempo
para la entrega de pedidos.

 Falta de información para el cálculo de una ventana horaria más reducida que la ofrecida.

 Falta de información para el control de las atenciones de los pedidos, reprogramación y

cancelación.

 No se cuenta con información oportuna de los estados de las atenciones de los pedidos
en tiempo real.

 No se cuenta con información real de las variables logísticas de los productos (peso y
volumen) para el cálculo de las unidades de transporte requeridas para la atención de
pedidos.

 No se cuenta con una herramienta que permita la asignación de productos a las unidades
de transporte considerando parámetros como ventana horaria, variables logísticas y
priorización de atenciones.

 No se cuenta con alertas que den aviso de los productos sin stock.

 No se cuenta con una herramienta que permita tener el kardex actualizado de la compañía
en tiempo real, convirtiéndose en un problema crítico.

2.6 Conclusiones
 Una profunda investigación para la explicación de los fundamentos teóricos tanto del
negocio como de las tendencias y tecnologías actuales permiten, al lector un claro y fácil
entendimiento de tema desarrollado.

 El tener bien definido el campo de acción, así como la identificación correcta de los
procesos involucrados y el conocimiento de los sistemas vinculados al campo de acción,
nos permite tener un amplio panorama para definir el dimensionamiento del alcance del
sistema propuesto.

 No solo se han hecho automatizaciones en los procesos existentes, sino que, además, ha
sido necesario realizar nuevas propuestas en mucho de los casos.

53
 A partir de tener bien identificada la situación problemática, como los problemas a
resolver, se podrá desarrollar una solución a medida de acuerdo a las necesidades del
negocio.

54
3 CAPÍTULO 2: PROPUESTA DE SOLUCIÓN
3.1 Introducción
En este capítulo se presentan los objetivos del proyecto, beneficios del proyecto,
antecedentes, y tendencias y tecnologías propuestas de la solución.

Se desarrolla este capítulo con la finalidad de demostrar el porqué de la propuesta de

solución. Se presenta el objetivo general y los objetivos específicos, los mismos que están
alineados con la propuesta, la fundamentación de los objetivos, e indicadores de logro de los
objetivos, estos últimos, permiten la medición de lo requerido versus lo propuesto.

En los beneficios del proyecto se detallan los beneficios tangibles e intangibles.

Finalmente, los antecedentes describen las soluciones encontradas, se hace un análisis

comparativo de estas versus la propuesta, además de la evaluación de la mejor solución, esto
bajo un criterio de medición respecto a los requerimientos ya mencionados. Cabe resaltar
que en el benchmarking se hace la comparativa contra empresas con años de experiencia, y
con un musculo logístico bastante desarrollado, no obstante, se asegura que la solución
propuesta es la mejor alternativa para dar solución a los problemas detectados en el proceso
de atención de pedidos de la empresa Retail.

3.2 Objetivos del Proyecto

3.2.1 Objetivo General
Desarrollar un sistema de información para la gestión de despacho de pedidos para empresas
retail que permita maximizar el cumplimiento de entrega de pedidos.

3.2.2 Objetivos Específicos

 Desarrollar un sistema de información que permita optimizar por tiempo y distancia la
ruta de entrega de los pedidos tomando en cuenta el tráfico histórico, mediante el uso de
una herramienta de geolocalización, la misma, que tomará las direcciones de entrega de
los pedidos para generar la hoja de ruta óptima, esto con la finalidad de tener un orden
en la entrega de los pedidos a los puntos de destino.

 Desarrollar un sistema de información que permita calcular de manera automática la

demanda de unidades de transporte requeridas para el proceso de atención de pedidos.

 Desarrollar un sistema de información que permita maximizar la carga de los pedidos en

la unidad de transporte, con la finalidad de optimizar la carga, evitando así superar la

55
 capacidad máxima del transporte, o caso contrario, desaprovechar el espacio que brinda
el transporte.

 Desarrollar un sistema de información que permita el cálculo de la ventana horaria de

entrega de cada pedido, la misma que será enviada mediante SMS al cliente, con la
finalidad de reducir la amplia ventana horaria que la empresa Retail brinda a todos los
clientes (de 9 am. a 9 pm).

 Desarrollar un sistema de información que permita registrar en línea el estado de los

pedidos en cada punto de entrega, con la finalidad de poder tomar acciones oportunas
que aseguren la entrega del pedido.

 Desarrollar un sistema de información que permita registrar los motivos de

reprogramación, cancelación y no entrega de los pedidos, con la finalidad de tomar las
mejores decisiones para cada una de las casuísticas presentas.

 Desarrollar un sistema de información que permita generar indicadores de control en el

proceso de atención de pedidos, con la finalidad de tener la capacidad para tomar las
mejores decisiones, apuntando a minimizar el impacto en la insatisfacción del cliente,
incumplimiento en el tiempo de entrega y aumento en el costo del flete.

 Desarrollar un sistema de información que genere alertas, para dar aviso de la falta de
stock de los productos ofrecidos para la venta.

 Desarrollar un sistema de información que realice la reserva del pedido una vez que el
pago haya sido confirmado por la entidad bancaria.

 Desarrollar un sistema de información que realice el abastecimiento de productos a

bodega o nodo.

56
3.2.3 Fundamentación de los Objetivos
Tabla 1.
Matriz de Trazabilidad de Problemas con Objetivos Específicos

parámetros como ventana horaria, variables logísticas y

No se cuenta con información oportuna de los estados de las
No se cuenta con una herramienta para calcular la ruta óptima

No se cuenta con información real de las variables logísticas

Falta de información para el cálculo de una ventana horaria

Falta de información para el control de las atenciones de los

de productos a las unidades de transporte considerando

actualizado de la compañía en tiempo real, convirtiéndose en

de los productos (peso y volumen) para el cálculo de las

No se cuenta con una herramienta que permita tener el kardex

No se cuenta con una herramienta que permita la asignación

No se cuenta con alertas que den aviso de los productos sin

unidades de transporte requeridas para la atención de
Problemas a Resolver

por distancia y tiempo para la entrega de pedidos.

atenciones de los pedidos en tiempo real.

pedidos, reprogramación y cancelación.
más reducida que la ofrecida.

priorización de atenciones.

un problema crítico.
pedidos.

stock.
Objetivos Específicos
Desarrollar un sistema de información que permita optimizar por tiempo y distancia la ruta de entrega de pedidos. X
Desarrollar un sistema de información que permita calcular las unidades de transporte requeridas para la atención de
X
pedidos.
Desarrollar un sistema de información que permita maximizar la carga de los pedidos en la unidad de transporte. X
Desarrollar un sistema de información que permita calcular la ventana horaria de entrega de cada pedido el cual será
X
enviando mediante SMS al cliente.
Desarrollar un sistema de información que permita registrar en línea los estados de los pedidos en cada punto de entrega. X
Desarrollar un sistema de información que permita registrar los motivos de reprogramación, cancelación y no entrega de
X
los pedidos.
Desarrollar un sistema de información que permita generar un informe de control de atención de los pedidos. X
Desarrollar un sistema de información que genere alertas, para dar aviso de la falta de stock de los productos ofrecidos
X
para la venta.
Desarrollar un sistema de información que realice la reserva del pedido una vez que el pago haya sido confirmado por la
X
entidad bancaria.
Desarrollar un sistema de información que realice el abastecimiento de productos a bodega o nodo. X

57
3.2.4 Indicadores de Logro de los Objetivos
Los indicadores de logro de los objetivos a cumplir son:

 Presentación y desarrollo de la primera versión del sistema, la misma que cuenta con la
aceptación de la empresa, representada por el gerente de omnicanal. Se incluye los
siguientes casos de uso desarrollados en el sistema:

o Reservar Pedido.
o Generar Hojas de Ruta.
o Notificar Ventanas Horarias.
o Confirmar Despacho de Pedido.
o Monitorear Despacho de Pedidos.
o Cargar Productos a Bodega o Nodo.
o Notificar Abastecimiento de Productos.
 Presentación de la documentación que incluirá:
o Modelo de procesos del negocio.
o Modelo de casos de uso del negocio
o Modelo de análisis del negocio.
o Realización de los casos de uso del negocio.
o Modelo de casos de uso del sistema.
o Modelo conceptual.
o Diagrama de casos de uso más significativos para la arquitectura de software.
o Vista lógica de la arquitectura de software.
o Vista de implementación de la arquitectura de software.
o Vista de despliegue de la arquitectura de software.
o Calidad y pruebas del software.
o Diagrama de patrones del sistema.
o Modelo de datos físico del sistema.
 Presentación de carta expedida por el beneficiario del proyecto, que certifique su
conformidad con la calidad de la solución propuesta y el valor de ésta para la solución
de la problemática actual, la misma que debe de resolver los problemas existentes en la
operación de logística, al menor costo posible, soportado por el uso de la tecnología
actual.

58
3.3 Beneficios del Proyecto
3.3.1 Beneficios Tangibles
Entre los beneficios tangibles se tiene:

 Ahorro en los costos de flete.

 Reducción de costo de la planilla del personal.

 Reducción de los pedidos devueltos.

 Aumento de las ganancias.

 Aumento en la capacidad para gestionar pedidos.

 Disminución en los tiempos de planificación.

 Disminución de los incumplimientos de entrega.

 Reducción de la ventana horaria de 9 a 4 horas.

 Incremento de los indicadores de satisfacción del cliente.

3.3.2 Beneficios Intangibles

Entre los beneficios intangibles se tiene:

 Mejora de la imagen corporativa de la empresa.

 Mejora del clima laboral.

 Mejora de la experiencia de compra del cliente.

3.4 Antecedentes
3.4.1 Soluciones Encontradas
[Link] DRIVIN
Es un software desarrollado por una empresa chilena que permite la planificación óptima de
la logística de una empresa que debe realizar despachos a distintos clientes durante una
jornada laboral.

Entre los beneficios ofrecidos de este sistema se tiene:

 Disminución en los costos de transporte.

 Reduce el tiempo de planificación.

59
 Mejora el nivel de servicio de los clientes.

 Estructura el proceso de planificación.

Entre los principales clientes que hacen uso de esta solución están BRIGHSTAR, SDA,
FRIGOSORNO, ECOLAB, CIC y DGA, las cuales son empresas mundiales con más de 20
años de participación en operaciones logísticas. Además, DRIVIN tiene operaciones en
USA, México, Perú y Chile.

Los módulos que constituyen este sistema son básicamente 3:

[Link].1 Optimización
DRIVIN entrega el listado optimizado de órdenes asignadas a cada vehículo y la secuencia
de entrega más eficiente. Ofreciendo en este módulo:

 Diferentes tipos de vehículos en la flota.

 Ventanas horarias.

 Tiempos de servicio.

[Link].2 Monitoreo
Monitorea la flota en tiempo real, recibe alertas accionables que permiten mejorar el
desempeño de las unidades de transporte que proveen el servicio. Ofrece:

 Control de ruta.

 Centro de control lifeview (control en tiempo real).

[Link].3 Gestión y Reportes

A través de indicadores de gestión, se puede medir objetivamente el desempeño de la flota
y mejorar los resultados del negocio. Este módulo ofrece, indicadores claves que permiten
evaluar y tomar decisiones estratégicas para poder gestionar de mejor manera los recursos.
Con DRIVIN podrás medir objetivamente si los resultados obtenidos están siendo los
esperados o si debes tomar acciones sobre ellos.

[Link] BEETRACK
Es un Sistema desarrollado para la planificación de rutas óptimas, seguimiento de entregas,
notificaciones a clientes y más. Entre los principales usuarios que utilizan el sistema son:

60
CENCOSUD, RIPLEY, 3M, KOMATSU, CIC, LINIO, TELEMOECADOS CL, WATTS,
PETSY, BEETRACK que tiene operaciones en Chile, México, Perú y EEUU.

Las funcionalidades ofrecidas por esta solución son:

 Planificar rutas.

 Reducir la incertidumbre.

 Resolver problemas proactivamente.

Todas estas funcionalidades se dividen en 4 grandes módulos:

[Link].1 Aumento y Visibilidad en toda la Logística de Entregas de Pedidos

Control de gestión en línea de la flota, mantiene al tanto de todos los detalles de las entregas
en tiempo real con el software para transportes.

[Link].2 Trazabilidad en Tiempo Real de las Entregas de Pedidos

 Asignación, control y trazabilidad de entregas: Carga e integra al sistema las órdenes de
compras de los clientes. Realiza las gestiones de flota de vehículos de forma rápida y
sencilla. Mantiene un control constante en las rutas, tiempos de envío y tasa de éxito de
las entregas.

 Análisis de rendimiento: BEETRACK entrega reportes diarios o semanales con la

información de todos los despachos realizados o por realizar vía e-mail. Analiza toda la
información relevante para el negocio de manera instantánea en la web.

 Conoce la experiencia de los clientes: Transforma la manera en que se realizan los

seguimientos de envíos. Con BEETRACK los clientes evalúan su experiencia al recibir
su entrega, teniendo la opción de agregar comentarios o sugerencias que pueden ser
claves para mejorar el negocio.

[Link].3 Monitoreo en Línea de todas las Entregas de Pedidos

 Planificación de rutas de entrega: Planificar rutas de envíos desde BEETRACK no puede
ser más sencillo. Implementa y optimiza toda la logística de rutas o la trazabilidad de un
producto. Asigna responsables, horas y número de entregas.

 Información y data en tiempo real: Los transportistas, además de planificar rutas y

horarios de despachos a través de la aplicación, pueden enviar y actualizar en tiempo real

61
 información importante para la empresa como fotografías, firmas de conformidades,
feedback del cliente y otras actividades adaptables a los requerimientos de la industria.

 Acceso en línea a tus entregas: BEETRACK permite controlar y modificar el detalle de

todas las guías de entregas, configurar destinatarios, estados y planificar rutas. El sistema
de trazabilidad permite gestionar y actualizar toda la información de forma online.

 Gestión de productos y despachos: La aplicación móvil muestra toda la información

correspondiente a la trazabilidad de un producto; desde la logística de rutas hasta los
tiempos de entrega, permitiendo a cada empleado configurar y actualizar el estatus de
los despachos in-situ.

[Link].4 Percepción del Cliente

 Widget de seguimiento y trazabilidad: Utiliza el Widget de BEETRACK en tu sitio web
o página de Facebook para que los clientes puedan hacer el seguimiento de sus envíos
en tiempo real y saber sobre el estado de sus entregas.

 Comunicación de principio a fin con tus clientes: Utiliza la opción de SMS personalizado
para informar en tiempo real a los clientes sobre el seguimiento de envíos, el tiempo
aproximado de llegada y cuando se encuentren fuera de su domicilio.

 Obtén la opinión de tus clientes: Obtiene comentarios y sugerencias de primera mano a

los clientes una vez realizada la entrega de sus productos. Evalúa la calidad de la gestión
logística, amabilidad del transportista y estado del producto recibido con el software para
transporte. Te permite realizar encuestas de Net Promoter Score sobre tu empresa.

3.4.2 Análisis Comparativo

En el cuadro siguiente se realiza el análisis comparativo de los requerimientos funcionales
de los siguientes sistemas:

 S1: DRIVIN.

 S2: BEETRACK.

 SP: Solución propuesta (Sistema de Gestión de Despacho de Pedidos).

Para realizar el análisis comparativo se utiliza una tabla de puntuación detallada líneas abajo,
que calificaran cada una de las funcionalidades de los sistemas evaluados:

62
Tabla 2.
Criterios de Evaluación
Valor Descripción
6 Cumple
3 Cumple parcialmente
0 No cumple

Tabla 3.
Cuadro Comparativo de Soluciones Encontradas vs. Solución Propuesta
Sistemas de Información S1 S2 SP
Requerimientos Funcionales
Planificación de ruta óptima por tiempo y distancia 6 6 6
Planificación de ventana horaria 3 6 6
Seguimiento y control permanente de los pedidos 6 6 6
Manejo de estados de los pedidos en tiempo real 6 6 6
Administración de las variables logísticas de los productos 0 6 6
Planificación de carga a las unidades de transporte 6 0 6
Manejo de alarmas 3 3 6
Seguimiento de los pedidos no entregados 0 0 6
Administración de stock (umbrales) 0 0 6
Requerimiento de unidades de transporte 3 0 6
Reporte de atenciones de pedidos 6 3 6
Administración de cubicación de productos en bodega 0 0 3
Reporte de informe para la reposición y compra de productos 0 0 3
50% 46% 92%
Totales
39 36 72

3.4.3 Evaluación de la Mejor Solución

Basados en el análisis realizado de las tres soluciones, se concluye que la solución propuesta,
contempla en su desarrollo todos los requerimientos funcionales identificados, en
comparación con las otras dos soluciones.

63
Entre las funcionalidades más importantes que incorpora el sistema a desarrollar destacan la
planificación de ruta óptima, solicitud de unidades de transporte, cargas óptimas a las
unidades de transporte, manejo de inventarios y seguimiento de pedidos no entregados.

Es por eso, que se concluye que el sistema propuesto es el ideal para poder implementarse
en la empresa Retail, el mismo que logrará solucionar todos los problemas de información
que se han identificado a lo largo del desarrollo de este proyecto.

3.5 Tendencias y Tecnologías Propuestas

A continuación, se presenta las tecnologías propuestas que se usarán en el proyecto:

3.5.1 Google Maps

Google Maps es un servicio de mapas que brinda Google en la web, el cual es muy
reconocido y usado a nivel mundial, ofreciendo imágenes de mapas desplazables, fotografías
por satélite del mundo y posibles rutas para dirigirnos a un destino mediante un medio de
transporte.

Entre el conjunto de APIs que ofrece Google Maps las cuales están disponibles en Android,
iOS, navegadores web y servicios web HTTP se usan las siguientes:

[Link] Maps JavaScript API

Esta API ofrece un conjunto de clases en JavaScript para construir mapas en una aplicación
web.

[Link] Directions API

Esta API devuelve indicaciones para ir de una ubicación a otra a través de diferentes medios
de transporte. Además, planifica y optimiza una ruta en base a una serie de ubicaciones,
tomando como factor importante el tiempo y la distancia, según las condiciones de tráfico
históricas y actuales.

[Link] Distance Matrix API

Esta API es un servicio web HTTP que proporciona distancia y tiempo de viaje para una
matriz de orígenes y destinos.

[Link] Geocoding API

Esta API es un servicio web HTTP que permite convertir direcciones en coordenadas
geográficas como latitud y longitud.

64
Google Maps tiene disponible el plan estándar y Premium (Google LLC, 2018). Para este
proyecto se propone el plan estándar que ofrece:

 Implementaciones gratuitas, externas y disponibles de forma pública.

 Se pagan los incrementos por sobre los límites de uso.

 Tarifas individuales de API y límites de uso.

3.5.2 Firebase Realtime Database

Firebase Realtime Database es una base de datos NoSQL alojada en la nube, que almacena
y sincroniza los datos en tiempo real entre las diferentes aplicaciones clientes que comparten
una instancia de dicha de base de datos. Los datos se almacenan en formato JSON. Sus
principales características son:

[Link] Actualizaciones de Datos en Tiempo Real

En vez que las aplicaciones cliente envíen constantemente solicitudes HTTP para verificar
si hay cambio en los datos, Firebase Realtime Database envía actualizaciones de datos en
cada milisegundo a las aplicaciones clientes que comparte la misma instancia de base de
datos, proporcionando una experiencia colaborativa.

[Link] Funciona sin Conexión

Las aplicaciones clientes de Firebase Realtime Database continúan funcionando a pesar de
no tener conexión, esto es posible debido a que la persistencia de datos de la aplicación
cliente no conectada se almacena localmente en disco, sin embargo, cuando la conexión es
restablecida, la aplicación cliente recibe los cambios de los datos del servidor y el servidor
sincroniza los datos locales de la aplicación cliente, distribuyendo los cambios de datos con
el resto de aplicaciones clientes que comparten la misma instancia.

[Link] Acceso desde Dispositivos Cliente

Con Firebase Realtime Database se puede acceder directamente desde un dispositivo móvil
o navegador web sin la necesidad de un servidor de aplicaciones, ya que dicho servicio está
alojado en la nube. Asimismo, Firebase Realtime Database permite establecer reglas de
seguridad basada en expresiones, las cuales son ejecutadas cuando se leen o escriben datos.

[Link] Escalamiento en varias Base de Datos

Con el plan de precios Blaze (pago por uso) de Firebase Realtime Database permite dividir
la información en varias instancias de Base de Datos dentro del mismo proyecto de Firebase.

65
Adicionalmente, con el Firebase Authentication permite autenticar a usuarios en varias
instancias de la base de datos y controlar el acceso a la información de cada Base de Datos
usando reglas personalizadas en cada una de las instancias de la Base de Datos (Google LLC,
2018).

Figura 20. Sincronización de Datos Firebase Realtime Database

(Google LLC, 2018)

Figura 21. Consola de Firebase

(Google LLC, 2018)

66
3.5.3 Textlocal API
Es una API gratuita que permite integrarse con su aplicación para enviar SMS o MMS
simples y masivos, además de recibir SMS o MMS en una bandeja de entrada de la API y
ser reenviados como JSON o XML para incluirlos en su aplicación. Esta API soporta
lenguajes como PHP, NET, Java, Python y Ruby (Txtlocal Ltd., 2018).

Adicionalmente, la API brinda documentación detallada y ejemplos de código para

desarrolladores con la finalidad de poder integrarla a tu aplicación.

Finalmente, esta API permite gestionar los contactos, crearlos o eliminarlos y obtener
informes históricos de un número individual o de un grupo con el uso de tu cuenta Textlocal
(Txtlocal Ltd., 2018).

Figura 22. Panel de Control de Textlocal

(Txtlocal Ltd., 2018)

3.6 Conclusiones
 El Análisis comparativo de la solución nos permite evaluar las diferencias en base a las
funcionalidades de la solución propuesta versus las funcionalidades de otros productos
ofrecidos en el mercado con la finalidad de definir funcionalidades adicionales que deben
considerarse para lograr ventaja, competitividad y satisfacción de las demandas del
mercado.

67
 A partir del análisis comparativo se concluye que resultaría de gran beneficio tanto
funcional como económico optar por la solución propuesta, ya que permite satisfacer las
necesidades particulares de la empresa Retail y poder alcanzar los objetivos del proyecto
planteados.

68
4 CAPÍTULO 3: MODELADO DEL NEGOCIO
4.1 Introducción
En este capítulo se presenta las reglas del negocio, el modelo de casos de uso del negocio,
el modelo de análisis del negocio y la realización de los casos de uso del negocio.

Este capítulo tiene como finalidad poder visualizar la solución propuesta de una manera
gráfica, mediante el modelo de casos de uso del negocio donde se describen a los actores del
negocio y casos de uso del negocio, y se muestra el diagrama de casos de uso del negocio.

En el modelo de análisis del negocio se describen a los trabajadores del negocio y entidades
del negocio, y se muestra el diagrama de clases del negocio.

Finalmente, en la realización de casos de uso del negocio se especifica los casos de uso del
negocio, se muestran los diagramas de proceso y la lista de actividades a automatizar. El
desarrollo de este punto es bastante importante, toda vez que permite plasmar de forma
gráfica los procesos involucrados, el flujo entre estos, las actividades a automatizar, así como
los nuevos procesos propuestos. La correcta elaboración gráfica de la propuesta de solución
da una sólida base para el proceso de construcción del sistema a desarrollar.

4.2 Reglas del Negocio

A continuación, se tiene las reglas del negocio mostradas en la siguiente tabla:

Tabla 4.
Reglas de negocio
Reglas de operación simple
RN01 Constancia de entrega del pedido
Si el pedido fue entregado al Cliente, entonces el Chofer debe solicitar al
Cliente el código de verificación para finalizar la orden del pedido.
RN02 Capacidad de carga de unidades de transporte
La carga de pedidos no debe exceder en peso o volumen la capacidad
máxima de la unidad de transporte.
RN03 Preparación de pedidos a entregar
Todos los pedidos a entregar deben ser preparados un día antes de la
entrega.
RN04 Atención de pedidos de cada nodo
Cada nodo debe atender los pedidos asignados a su zona de cobertura.

69
RN05 Cambio de cantidades de productos en la reprogramación
La reprogramación de un pedido no debe aumentar o disminuir las
cantidades de productos ya comprometidas.
RN06 Programación de Recojo de pedidos a domicilio
Para la programación de recojo de un pedido a domicilio no se debe aceptar
un lugar de recojo distinto al lugar inicial de entrega del pedido.
RN07 Productos defectuosos
Los productos defectuosos no deben incluirse en el stock de productos.
RN12 Pedidos pendientes de monitorear
Los pedidos que se despachan hoy por las unidades son los únicos que
pueden monitorearse en tiempo real.
Reglas de estímulo – respuesta
RN08 Cobro del flete por reprogramación
A partir de la segunda reprogramación del pedido se cobra el costo del flete.
RN09 Pedido no entregado
Si el Cliente no se encuentra en el punto destino, entonces el pedido es
actualizado como No Atendido indicando el motivo.
RN10 Pedido entregado al cliente dentro de la ventana horaria
Si el pedido es entregado al Cliente dentro de la ventana horaria, entonces
el pedido es actualizado como Atendido.
RN11 Pedido entregado a tienda dentro de la ventana horaria
Si el pedido es entregado a tienda dentro de la ventana horaria, entonces el
pedido es actualizado como Entregado a Tienda.
RN13 Pedidos que están a punto de sobrepasar su ventana horaria
Si el pedido está a 10 minutos de sobrepasar su ventana horaria, entonces
debe alertar mediante un mensaje indicando la bodega o nodo, así como las
unidades donde sus pedidos están a punto de sobrepasar la ventana horaria.
RN14 Pedido cancelado
Si el pedido es cancelado en ruta, entonces se notificará al Chofer que el
pedido fue cancelado.
RN15 Pedido reprogramado

70
 Si el pedido es reprogramado en ruta, entonces se notificará al Chofer que
el pedido fue reprogramado.
RN16 Sellado de bulto
Si el pallet está lleno, entonces el bulto debe ser sellado con el film de
seguridad.
RN17 Envío de notificación de nota de crédito
Si el pedido ha sido cancelado, entonces se debe enviar una notificación de
nota de crédito a contabilidad.
RN18 Pallet enviado al muelle de carga
Todo bulto que cuenta con el sticker de despacho debe ser enviado
inmediatamente al muelle de carga.
RN19 Envío de ventana horaria
Si no hay más órdenes de pedido a preparar en el nodo, entonces se envía
la ventana horaria de entrega a cada Destinatario.
RN20 Gestión de pedidos no entregados
Si el pedido no ha sido entregado, entonces se debe comunicar
inmediatamente con el Cliente para su reprogramación o cancelación.
RN21 Stock de producto en bodega
Si el stock de producto es menor al umbral en bodega, entonces se debe
enviar una notificación de compra de producto.
RN22 Stock de producto en nodo
Si el stock de producto es menor al umbral en nodo, entonces se debe enviar
una notificación de reposición de producto.
RN23 Productos defectuosos o cancelados en un pedido
Los productos defectuosos o cancelados en un pedido pueden ser devueltos
a tienda o recogidos a domicilio a solicitud del cliente.
RN35 Abastecimiento de Productos
Si se realiza un abastecimiento de productos del proveedor a la bodega,
entonces los productos son sumados al stock de la bodega correspondiente.
RN36 Reposición de Productos

71
 Si se realiza una reposición de productos de la bodega al nodo, entonces
los productos son restados del stock de la bodega y sumandos al stock del
nodo correspondiente.
Reglas de dominio de datos
RN24 Fecha mínima de reprogramación de pedido
Si la solicitud de reprogramación del pedido es hasta las 16:00 horas,
entonces la fecha mínima de reprogramación es a 24 horas, en caso
contrario la fecha mínima de reprogramación es a 48 horas.
RN25 Fecha máxima de reprogramación de pedido
El pedido tendrá como fecha máxima 7 días adicionales a partir de la fecha
mínima de reprogramación para ser entregado.
Reglas de relación
RN26 Productos de una orden de pedido
Una orden de pedido está asociada a uno o más productos.
RN27 Órdenes de pedido de un destinatario
Un destinatario está asociado a uno o más órdenes de pedido.
RN28 Pedidos de una unidad de transporte
Una unidad de transporte está asignada a uno o más pedidos.
RN29 Unidades de transporte de un proveedor
Una unidad de transporte está asociada a un proveedor.
RN30 Chofer de una unidad de transporte
Una unidad de transporte está asociada a un chofer.
RN32 Pickeadores de una cuadrilla
Una cuadrilla está asociada a uno o varios pickeadores.
RN33 Cuadrillas de una unidad de transporte
Una unidad de transporte se le asigna una o varias cuadrillas para la
preparación de pedidos.
Reglas de inferencia
RN31 Pedido está en ruta
Si el pedido está en proceso de ser enviado al domicilio del Cliente
entonces el pedido está en ruta.
RN34 Pedidos que son actos para el despacho

72
 Si el pago de un pedido es validado por la entidad bancaria entonces el
pedido es acto para el despacho.

4.3 Modelo de Casos de Uso del Negocio

4.3.1 Actores del Negocio
[Link] AN01_Coordinador DAD
Actor de negocio que solicita y se beneficia de la reserva de inventario, preparación de
pedidos, atención de pedidos y monitoreo de atención de pedidos.

[Link] AN02_Cliente
Actor de negocio que solicita y se beneficia de la reprogramación del pedido y cancelación
del pedido.

[Link] AN03_Gerente de Abastecimiento

Actor del negocio que solicita y se beneficia del informe de control de atención de pedidos.

4.3.2 Casos de Uso del Negocio

Tabla 5.
Descripción de CUN01_Preparar Pedidos
Nombre CUN01_Preparar Pedidos
Actor de Negocio AN01_Coordinador DAD.
Propósito Preparar los pedidos de los destinatarios para ser cargados a las
unidades de transporte.
Breve El caso de uso inicia cuando el Coordinador DAD solicita la
Descripción preparación de pedidos. Luego el despachador notifica la solicitud de
unidades de transporte, elabora las hojas de ruta, imprime las órdenes
de pedido, asigna las unidades de transporte a cuadrilla e imprime las
cubicaciones, para que el pickeador coloque los pedidos en el pallet
y los selle con el film de seguridad, para luego ser cargados a la
unidad de transporte. El caso de uso finaliza cuando el Coordinador
DAD recibe la conformidad de preparación de pedidos concluida.

73
Tabla 6.
Descripción de CUN02_Atender Pedidos
Nombre CUN02_Atender Pedidos
Actor de Negocio AN01_Coordinador DAD.
Propósito Entregar pedido, recoger productos e intercambiar productos
defectuosos al domicilio del cliente o tienda de la empresa Retail.
Breve El caso de uso inicia cuando el Coordinador DAD solicita la atención
Descripción de pedidos. Luego el Chofer consulta la hoja de ruta para dirigirse al
punto destino para la entrega del pedido, recojo de productos o
intercambio de productos a domicilio del cliente o tienda de la
empresa Retail. El caso de uso finaliza cuando el Coordinador DAD
recibe la conformidad de atención de pedidos.

Tabla 7.
Descripción de CUN03_Reprogramar Pedido
Nombre CUN03_Reprogramar Pedido
Actor de Negocio AN02_Cliente.
Propósito Reprogramar la entrega del pedido e intercambio de productos
defectuosos al Cliente.
Breve El caso de uso inicia cuando el Cliente solicita la reprogramación de
Descripción su pedido. Luego Call Center reprograma fecha de entrega de pedido,
programa recojo de productos defectuosos a domicilio o registra
fecha de devolución de productos defectuosos a tienda en caso
hubiera productos con defectos. El caso de uso finaliza cuando el
Cliente recibe la conformidad de reprogramación de su pedido.

Tabla 8.
Descripción de CUN04_Cancelar Pedido
Nombre CUN04_Cancelar Pedido
Actor de Negocio AN02_Cliente.
Propósito Cancelar pedido del Cliente, y programar recojo de productos a
domicilio o devolución de productos a tienda.

74
 Breve El caso de uso inicia cuando el Cliente solicita la cancelación de su
Descripción pedido. Luego Call Center cancela el pedido al Cliente, programa
recojo de productos a domicilio o registra fecha de devolución de
productos a tienda. El caso de uso finaliza cuando el Cliente recibe
la conformidad de cancelación de su pedido.

Tabla 9.
Descripción de CUN05_Controlar Atención de Pedidos
Nombre CUN05_Controlar Atención de Pedidos
Actor de Negocio AN03_Gerente de Abastecimiento
Propósito Elaborar el informe de control de atención de pedidos.
Breve El caso de uso inicia cuando el Gerente de Abastecimiento solicita el
Descripción informe de control de atención de pedidos. Luego el Analista de
Abastecimiento elabora el informe de estado de pedidos, el informe
de ranking de proveedores de transporte, el informe de productos de
mayor rotación, el informe de abastecimiento de productos y el
informe de productividad de picking. El caso de uso finaliza cuando
el Gerente de Abastecimiento recibe el informe de control de
atención de pedidos.

Tabla 10.
Descripción de CUN06_Reservar Inventario
Nombre CUN06_Reservar Inventario
Actor de Negocio AN01_Coordinador DAD
Propósito Reservar inventario para un pedido de venta concreto.
Breve El caso de uso inicia cuando el Coordinador DAD solicita reserva de
Descripción inventario. Luego el Despachador registra el pedido cuyo pago ha
sido validado por la entidad bancaria y resta al stock de productos.
El caso de uso finaliza cuando el Coordinador DAD recibe la
conformidad de reserva de inventario.

75
Tabla 11.
Descripción de CUN07_Monitorear Atención de Pedidos
Nombre CUN07_Monitorear Atención de Pedidos
Actor de Negocio AN01_Coordinador DAD
Propósito Monitorear la atención de pedidos de las unidades de transporte
desde su salida de la bodega, durante su trayectoria a cada punto
destino, hasta su llegada a la bodega.
Breve El caso de uso inicia cuando el Coordinador DAD solicita monitoreo
Descripción de atención de pedidos. Luego el Monitoreador monitorea la salida
de las unidades de transporte de la bodega, monitorea la adherencia
a la ruta programada, monitorea los cambios en los estados de los
pedidos y monitorea la llegada de las unidades de transporte a la
bodega. El caso de uso finaliza cuando el Coordinador DAD recibe
la conformidad de monitoreo de atención de pedidos concluida.

4.3.3 Diagrama de Casos de Uso del Negocio

Figura 23. Diagrama de Casos de Uso de Negocio

(Elaboración propia, 2018)

76
4.4 Modelo de Análisis del Negocio
4.4.1 Trabajadores del Negocio
[Link] TN01_Despachador
Encargado de notificar la solicitud de unidades de transporte, elaborar hojas de ruta, imprimir
órdenes de pedido, imprimir cubicación, verificar productos sin stock, notificar ventana
horaria de entrega de pedido al destinatario, registrar pedido con número de reserva, restar
al stock de productos, notificar compra de productos y notificar reposición de productos.

[Link] TN02_Pickeador
Encargado de consultar la orden de pedido a preparar, preparar pallet, consultar ubicación
del producto, retirar producto de anaquel si es encontrado en anaquel, notificar producto sin
stock a Call Center si no está en anaquel, agregar producto al carrito de almacén, actualizar
orden de pedido como “Validada” si ya no hay productos en orden de pedido, cargar pedido
al pallet si no está lleno, sellar bulto con film de seguridad si el pallet está lleno, elaborar
sticker de despacho, colocar sticker de despacho en bulto, designar pallet a muelle de carga
y verificar si hay órdenes de pedido a preparar.

[Link] TN03_Chofer
Encargado de consultar la hoja de ruta, dirigirse a la dirección destino, registrar pedidos
como “No Atendido” si el destinatario no se encuentra en el punto destino, registrar los
productos recogidos del punto destino en caso de verificar existencia de recojo de productos,
solicitar firma del destinatario en caso de verificar existencia de entrega de pedidos, entregar
copia de órdenes de pedido firmada al destinatario, registrar pedidos como “Entregado a
Tienda” si el destinatario es una tienda de la empresa Retail o registrar pedidos como
“Atendido” si el destinatario es un cliente, y regresar a bodega si ya no existen más pedidos
a atender.

[Link] TN04_Call Center

Encargado de informar al destinatario producto sin stock, notificar emisión de nota de crédito
de producto a contabilidad, consultar pedido del cliente, reprogramar o cancelar pedido,
notificar reprogramación o cancelación de pedido al chofer si el pedido está en ruta, registrar
productos defectuosos en caso exista, restar al stock de productos a intercambiar, notificar
compra de productos si es bodega, notificar reposición de productos si es tienda, programar
recojo de productos a domicilio, registrar devolución de productos en tienda, notificar

77
emisión de nota de crédito de pedido a contabilidad y sumar al stock de productos devueltos
en buen estado.

[Link] TN05_Aceptante
Es un rol que asume el Cliente o Controlador de Tienda cuando firma la orden de pedido
como constancia de que su pedido fue aceptado.

[Link] TN06_Maquinista
Encargado de trasladar el pallet al muelle de carga.

[Link] TN07_Estibador
Encargado de cargar pedidos a unidad de transporte, descargar pedidos de unidad de
transporte, cargar productos devueltos o defectuosos a unidad de transporte y entregar pedido
al destinatario.

[Link] TN08_Analista de Abastecimiento

Encargado de elaborar el informe de estado de pedidos, elaborar el informe de ranking de
proveedores de transporte, elaborar el informe de productos de mayor rotación, elaborar el
informe de abastecimiento de productos y elaborar el informe de productividad de picking.

[Link] TN09_Monitoreador
Encargado de monitorear la salida de unidades de transporte de la bodega, monitorear la
adherencia a la ruta programada de las unidades de transporte, solucionar problemas que se
presenten en las unidades de transporte (por ejemplo, vías bloqueadas, retraso en la carga y
descarga de pedidos a unidad de transporte, etc.), calcular tiempo aproximado de llegada del
pedido a solicitud del cliente, monitorear estados de pedidos (pendiente, reprogramado,
cancelado, atendido, entregado a tienda, no atendido) asignados a cada unidad de transporte
y monitorear llegada de unidades de transporte a la bodega.

78
4.4.2 Entidades del Negocio
[Link] EN01_Pedido
Representa la información del pedido del destinatario.

Tabla 12.
Atributos de EN01_Pedido
Nombre Descripción Tipo Valor Inicial
codigoPedido Código de pedido String
fechaSolPedido Fecha de solicitud del pedido Date Today()
direccionEntrega Dirección de entrega del pedido String
fechaEntrega Fecha de entrega del pedido Date
fechaSolReprog Fecha de solicitud de reprogramación del pedido Date
fechaReprogramacion Fecha de reprogramación de entrega de pedido Date
fechaCancelacion Fecha de cancelación del pedido Date
fechaRecojoProd Fecha de recojo de productos a domicilio. Date
fechaDevolProd Fecha de devolución de productos a tienda. Date
formaPago Forma de pago (EF: Efectivo, CR: Crédito) String
totalBrutoPedido Total bruto de pedido (sin IGV) Double
totalNetoPedido Total neto de pedido (con IGV) Double
estadoPedido Estado del pedido (PEN: Pendiente, REP: Reprogramado, CAN: Cancelado, String
EAT: Entregado a Tienda, ATE: Atendido, NAT: No Atendido)

79
 Destinatario Datos del destinatario al que se le entrega o recoge el pedido Object
Ubigeo Datos de la ubicación geográfica Object
motivo Pedido Datos del motivo de pedido Object
fuenteAbastecimiento Datos de la bodega o tienda Object

[Link] EN02_Hoja de Ruta

Representa la información de los pedidos asignados a una unidad de transporte para su entrega o recojo en los puntos destinos.

Tabla 13.
Atributos de EN02_Hoja de Ruta
Nombre Descripción Tipo Valor Inicial
codigoHojaRuta Código de hoja de ruta String
fechaHojaRuta Fecha de generación de hoja de ruta Date Today()
Pedidos Lista de pedidos asignados a una hoja de ruta List
Destinatario Lista de destinatarios al que se le entrega o recoge el pedido List
Proveedor Datos del proveedor de la unidad de transporte Object
Chofer Datos del chofer de la unidad de transporte Object
unidadTransporte Datos de la unidad de transporte Object
Ubigeos Datos de la ubicación geográfica de cada pedido List
ventanasHorarias Datos de ventana horaria de cada pedido List

80
[Link] EN03_Producto
Representa la información del producto.

Tabla 14.
Atributos de EN03_Producto

Nombre Descripción Tipo Valor Inicial

codigoProducto Código de producto String
nombreProducto Nombre de producto String
precioUnitario Precio unitario de producto Double
Peso Peso de producto Double
Ancho Ancho de producto Double
Altura Altura de producto Double
Profundidad Profundidad de producto Double
fechaFabricacion Fecha de fabricación de producto Date
fechaVencimiento Fecha de vencimiento de producto Date
familiaProducto Datos de familia de producto Object
tipoProducto Datos de tipo de producto Object

[Link] EN04_Sticker de Despacho

Representa la información de los pedidos armados en un bulto que serán asignadas a una unidad de transporte.

81
Tabla 15.
Atributos de EN04_Sticker de Despacho
Nombre Descripción Tipo Valor Inicial
nroSticker Número de sticker de despacho String
cantidadPedidos Cantidad de pedidos Integer
Pedidos Lista de pedidos de un bulto List

[Link] EN05_Notificación de Nota de Crédito

Representa una notificación que se envía a contabilidad para la emisión de la Nota de Crédito de un cliente por el concepto de cancelación de
su pedido.

Tabla 16.
Atributos de EN05_Notificación de Nota de Crédito
Nombre Descripción Tipo Valor Inicial
emailContabilidad Email del área de contabilidad String
asuntoNotificacion Asunto de notificación de nota de crédito String
Concepto Concepto de emisión de nota de crédito String
mensajeNotificacion Mensaje de notificación de nota de crédito String
fechaNotificacion Fecha de envío de notificación Date Today()
Pedido Datos del pedido Object
Destinatario Datos del destinatario Object

82
[Link] EN06_Solicitud de Unidades de Transporte
Representa la información de las unidades de transporte que se requieren para el traslado de los pedidos a los puntos destinos.

Tabla 17.
Atributos de EN06_Solicitud de Unidades de Transporte
Nombre Descripción Tipo Valor Inicial
nroSolicitud Número de solicitud de unidad de transporte String
fechaSolicitud Fecha de solicitud de unidad de transporte Date Today()
totalUnidTransporte Total de unidades de transporte Integer
fechaEnvioUnidades Fecha de envío de unidades de transporte Date
Proveedor Datos del proveedor de la unidad de transporte Object
unidadTransporte Datos de la unidad de transporte Object
fuenteAbastecimiento Datos de la fuente de abastecimiento (bodega o nodo) Object

[Link] EN07_Orden de Pedido

Representa la información de la orden del pedido que se le entrega al cliente por su compra realizada.

Tabla 18.
Atributos de EN07_Orden de Pedido
Nombre Descripción Tipo Valor Inicial
nroOrdenPedido Número de orden de pedido String
fechaOrdenPedido Fecha de generación de orden de pedido Date Today()

83
 Pedido Datos del pedido Object
Destinatario Datos del destinatario Object
Ubigeo Datos de la ubicación geográfica Object

[Link] EN08_Informe de Estado de Pedidos

Representa la información consolidada y detallada de los estados del pedido, y los motivos de su reprogramación, cancelación y no atención de
los pedidos.

Tabla 19.
Atributos de EN08_Informe de Estado de Pedidos
Nombre Descripción Tipo Valor Inicial
fechaIniConsulta Fecha inicial de consulta Date FirstDayMonth()
fechaFinConsulta Fecha final de consulta Date Today()
nroPedidosAtendidos Número de pedidos atendidos (recojo y/o entrega) Integer
nroPedidosNoAtendidos Número de pedidos no atendidos Integer
nroPedidosReprogramad Número de pedidos reprogramados Integer
os
nroPedidosCancelados Número de pedidos cancelados Integer
nroPedidosPendEntr Número de pedidos pendientes de entrega. Integer
nroPedidosPendReco Número de pedidos pendientes de recojo a domicilio. Integer
nroPedidosPendDevo Número de pedidos pendientes de devolución en tienda. Integer

84
 nroPedidosEntregados Número de pedidos entregados. Integer
nroPedidosRecogidos Número de pedidos recogidos a domicilio. Integer
nroPedidosDevueltos Número de pedidos devueltos a tienda Integer
nroPedidosEntrFueraVen Número de pedidos entregados fuera de la ventana horaria Integer
tHora
porcMotivosPorEstPedid Porcentaje de motivos por estado del pedido (Reprogramado, Cancelado, No Double
o Atendido y Atendido fuera de la ventana Horaria)
Pedidos Lista de pedidos List
motivosPedido Lista de motivos de pedido List
Destinatarios Lista de destinatarios List
Choferes Lista de choferes List
hojasRuta Lista de hojas de ruta List
fuentesAbastecimiento Lista de fuentes de abastecimiento List

[Link] EN09_Informe de Ranking de Proveedores de Transporte

Representa la información del ranking de cumplimiento de pedidos entregados por los proveedores de transporte.

Tabla 20.
Atributos de EN09_Informe de Ranking de Proveedores de Transporte
Nombre Descripción Tipo Valor Inicial
fechaIniConsulta Fecha inicial de consulta Date FirstDayMonth()

85
 fechaFinConsulta Fecha final de consulta Date Today()
porcPedEntrPorProvEnV Porcentaje de pedidos atendidos por proveedor dentro de la ventana horaria Double
entHor
porcPedEntrPorProvFue Porcentaje de pedidos atendidos por proveedor fuera de la ventana horaria Double
VentHor
porcPedEntrTiendaPorPr Porcentaje de pedidos entregados a tienda por proveedor Double
ov
porcPedNoEntrPorProv Porcentaje de pedidos no atendidos por proveedor Double
hojasRuta Lista de hojas de ruta List
Proveedores Lista de proveedores List
Pedidos Lista de pedidos List
motivosPedido Lista de motivos de pedido List
ventanasHorarias Lista de ventanas horarias List
fuentesAbastecimiento Lista de fuentes de abastecimiento List

[Link] EN10_Destinatario
Representa la información del destinatario que se le atiende su pedido.

Tabla 21.
Atributos de EN10_Destinatario
Nombre Descripción Tipo Valor Inicial

86
 codigoDestinatario Código de destinatario String
nombreDestinatario Nombre del destinatario String
apellidoDestinatario Apellido del destinatario String
tipoDocIdentidad Tipo de documento de identidad (DNI: Documento nacional de identidad, String
RUC: Registro único de contribuyente, CEX: Carnet de extranjería, PAS:
Pasaporte)
nroDocIdentidad Número de documento de identidad String
telefonoFijo Teléfono fijo del destinatario String
telefonoMovil Teléfono móvil del destinatario String
emailDestinatario Email del destinatario String
tipoDestinatario Tipo de destinatario. (CLI: Cliente, CTI: Controller de Tienda) String

[Link] EN11_Proveedor
Representa la información del proveedor.

Tabla 22.
Atributos de EN11_Proveedor
Nombre Descripción Tipo Valor Inicial
codigoProveedor Código de proveedor String
razonSocial Razón social de proveedor String
nroRUC Número de RUC String

87
 telefonoFijoProveedor Teléfono fijo del proveedor String
emailProveedor Email del proveedor String

[Link] EN12_Informe de Productos de Mayor Rotación

Representa la información de los productos más vendidos en base a la familia y tipo de productos.

Tabla 23.
Atributos de EN12_Informe de Productos de Mayor Rotación
Nombre Descripción Tipo Valor Inicial
fechaIniConsulta Fecha inicial de consulta Date FirstDayMonth()
fechaFinConsulta Fecha final de consulta Date Today()
porcVentProductPorFam Porcentaje de venta de productos por familia de producto Double
Prod
porcVentProductPorFam Porcentaje de venta productos por familia y tipo de producto Double
TipoProd
Pedidos Lista de productos List
itemsPedidos Lista de ítems de pedidos List
Productos Lista de productos List
tiposProducto Lista de tipos de producto List
familiasProducto Lista de familias de producto List

88
[Link] EN13_Chofer
Representa la información del chofer.

Tabla 24.
Atributos de EN13_Chofer
Nombre Descripción Tipo Valor Inicial
codChofer Código de chofer String
nombreChofer Nombre de chofer String
apellidoChofer Apellido de chofer String
telefonoMovilChofer Teléfono móvil de chofer String
Proveedor Datos del proveedor Object

[Link] EN14_Unidad de Transporte

Representa la información de la unidad de transporte.

Tabla 25.
Atributos de EN14_Unidad de Transporte
Nombre Descripción Tipo Valor Inicial
nroPlaca Número de placa String
modeloUnidTransporte Modelo de unidad de transporte String
marcaUnidTransporte Marca de unidad de transporte String
volumenMaxCarga Volumen máximo de carga Double

89
 pesoMaxCarga Peso máximo de carga Double
flagDisponibilidad Flag de disponibilidad Boolean
Chofer Datos del chofer Object
Proveedor Datos del proveedor Object

[Link] EN15_Ubigeo
Representa la información de las ubicaciones geográficas.

Tabla 26.
Atributos de EN15_Ubigeo
Nombre Descripción Tipo Valor Inicial
codUbigeo Código de ubigeo String
codDepartameto Código de departamento String
nomDepartamento Nombre de departamento String
codProvincia Código de provincia String
nomProvincia Nombre de provincia String
codDistrito Código de distrito String
nomDistrito Nombre de distrito String

[Link] EN16_Familia de Producto

Representa la información de la familia de productos como por ejemplo los productos de línea blanca.

90
Tabla 27.
Atributos EN16_Familia de Producto
Nombre Descripción Tipo Valor Inicial
codFamProducto Código de familia de producto String
nomFamProducto Nombre de la familia de producto String
descFamProducto Descripción de la familia de producto String

[Link] EN17_Tipo de Producto

Representa la información de tipo de productos como por ejemplo refrigeradoras, televisores, etc.

Tabla 28.
Atributos EN17_Tipo de Producto
Nombre Descripción Tipo Valor Inicial
codTipoProducto Código de tipo de producto String
nomTipoProducto Nombre de tipo de producto String
descTipoProducto Descripción de tipo de producto String

[Link] EN18_Motivo de Pedido

Representa la información de los motivos de reprogramación, cancelación, no atendido y entrega fuera de la ventana horaria de los pedidos.

91
Tabla 29.
Atributos EN18_Motivo de Pedido
Nombre Descripción Tipo Valor Inicial
codMotivPedido Código de motivo del pedido String
descMotivPedido Descripción de motivo del pedido String
estadoPedido Estado del pedido String

[Link] EN19_Cubicación
Representa la información de las ubicaciones de los productos dentro de la bodega.

Tabla 30.
Atributos EN19_Cubicación
Nombre Descripción Tipo Valor Inicial
nombreBodega Nombre de bodega String
areaBodega Área de bodega String
pasilloBodega Pasillo de bodega String
ladoBodega Lado de bodega String
alturaBodega Altura de bodega String
profundidadBodega Profundidad de bodega String
Producto Datos del producto Object

92
[Link] EN20_Ventana Horaria
Representa la información del rango de horas disponibles para la entrega de los pedidos.

Tabla 31.
Atributos EN20_Ventana Horaria
Nombre Descripción Tipo Valor Inicial
fecEnvioPedido Fecha de envío de pedido String
horaIniEnvioPedido Hora de inicio de envío de pedido String
horaFinEnvioPedido Descripción de tipo de producto String
Pedido Datos del pedido Object
destinatario Datos del destinatario Objet

[Link] EN21_Fuente de Abastecimiento

Representa la información de las bodegas, nodos y tiendas.

Tabla 32.
Atributos EN21_Fuente de Abastecimiento
Nombre Descripción Tipo Valor Inicial
codFuenAbast Código de fuente de abastecimiento String
nomFuenAbast Nombre de fuente de abastecimiento String
direcFuenAbast Dirección de Fuente de abastecimiento String
tipoFuenAbast Tipo de fuente de abastecimiento (BOD: Bodega, NOD: Nodo, TIE: Tienda) String

93
 Ubigeo Datos de la ubicación geográfica Object

[Link] EN22_Notificación de Devolución de Producto

Representa una notificación que se envía al cliente para la devolución de productos a la tienda.

Tabla 33.
Atributos EN22_Notificación de Devolución de Producto
Nombre Descripción Tipo Valor Inicial
emailCliente Email del cliente String
asuntoNotificacion Asunto de notificación de devolución de producto a tienda String
mensajeNotificacion Mensaje de devolución de producto a tienda. Incluye la fecha de devolución. String
fechaNotificacion Fecha de envío de notificación Date Today()
Pedido Datos del pedido Object
productos Lista de productos List
destinatario Datos del destinatario Object
fuenteAbastecimiento Datos de la fuente de abastecimiento Object

[Link] EN23_Notificación de Compra de Producto

Representa una notificación que se envía al proveedor para la compra de productos que requiere la bodega.

94
Tabla 34.
Atributos EN23_Notificación de Compra de Producto
Nombre Descripción Tipo Valor Inicial
emailProveedor Email del proveedor String
asuntoNotificacion Asunto de notificación de compra de producto String
mensajeNotificacion Mensaje de compra de producto a proveedor. Incluye la cantidad de String
productos a solicitar.
fechaNotificacion Fecha de envío de notificación Date Today()
productos Lista de productos List
proveedor Datos del proveedor Object
fuenteAbastecimiento Datos de la fuente de abastecimiento (bodega o nodo) Object

[Link] EN24_Notificación de Reposición de Producto

Representa una notificación que se envía a la bodega para la reposición de productos a tienda.

Tabla 35.
Atributos EN24_Notificación de Reposición de Producto
Nombre Descripción Tipo Valor Inicial
emailBodega Email de la bodega String
asuntoNotificacion Asunto de notificación de reposición de producto String

95
 mensajeNotificacion Mensaje de reposición de producto. Incluye la cantidad de productos a String
solicitar.
fechaNotificacion Fecha de envío de notificación Date Today()
Productos Lista de productos List
fuenteAbastecimiento Datos de la fuente de abastecimiento (tienda) Object

[Link] EN25_Notificación de Cancelación de Pedido

Representa una notificación que se envía al chofer para informar que un pedido que está transportando ha sido cancelado.

Tabla 36.
Atributos EN25_Notificación de Cancelación de Pedido
Nombre Descripción Tipo Valor Inicial
emailChofer Email del chofer String
asuntoNotificacion Asunto de notificación de cancelación de pedido String
mensajeNotificacion Mensaje de cancelación de pedido String
fechaNotificacion Fecha de envío de notificación Date Today()
hojaRuta Datos de la hoja de ruta Object
unidadTransporte Datos de la unidad de transporte Object
Chofer Datos del chofer Object
Pedido Datos del pedido Object

96
[Link] EN26_Notificación de Reprogramación de Pedido
Representa la información de reprogramación de un pedido. Esta entidad se relaciona con las entidades Hoja de Ruta, Unidad de Transporte,
Chofer y Pedido.

Tabla 37.
Atributos EN26_Notificación de Reprogramación de Pedido
Nombre Descripción Tipo Valor Inicial
emailChofer Email del chofer String
asuntoNotificacion Asunto de notificación de reprogramación de pedido String
mensajeNotificacion Mensaje de reprogramación de pedido String
fechaNotificacion Fecha de envío de notificación Date Today()
hojaRuta Datos de la hoja de ruta Object
unidadTransporte Datos de la unidad de transporte Object
Chofer Datos del chofer Object
Pedido Datos del pedido Object

[Link] EN27_Kardex
Representa la información del stock de los productos en una fuente de abastecimiento.

Tabla 38.
Atributos EN27_Kardex
Nombre Descripción Tipo Valor Inicial

97
 stockMinimo Stock mínimo de producto Integer
stockActual Stock actual de producto Integer
Producto Datos del producto Object
fuenteAbastecimiento Datos de la fuente de abastecimiento Object

[Link] EN28_Item de Pedido

Representa la información del detalle del pedido.

Tabla 39.
Atributos EN28_Item de Pedido
Nombre Descripción Tipo Valor Inicial
cantProducto Cantidad de productos Integer
montoProducto Monto de producto Double
cantProductoDefect Cantidad de productos defectuosos Integer
obsProductoDefect Observación de productos defectuosos String
Pedido Datos del pedido Object
Producto Datos del producto Object

[Link] EN29_Informe de Abastecimiento de Productos

Representa la información consolidada de los productos abastecidos o pendientes de abastecer a las tiendas.

98
Tabla 40.
Atributos EN29_Informe de Abastecimiento de Productos

Nombre Descripción Tipo Valor Inicial

fechaIniConsulta Fecha inicial de consulta Date FirstDayMonth()
fechaFinConsulta Fecha final de consulta Date Today()
totalProdAbast Total de productos abastecidos Integer
totalProdPendAbast Total de productos pendientes a abastecer Integer
productos Lista de productos List
Kardex Lista de Kardex List
fuenteAbastecimiento Lista de fuentes de abastecimiento List

[Link] EN30_Mapa
Representa la información del mapa.

Tabla 41.
Atributos EN30_Mapa
Nombre Descripción Tipo Valor Inicial
direcLugar Dirección del lugar String
imgMapa Imagen del mapa Image

99
[Link] EN31_GPS
Representa la información de la ubicación geográfica de la unidad de transporte.

Tabla 42.
Atributos EN31_GPS
Nombre Descripción Tipo Valor Inicial
Longitud Longitud en el mapa Integer
Latitud Latitud en el mapa Integer
profundidad Profundidad en el mapa Integer
distanciaRecorrida Distancia recorrida Double
Rumbo Rumbo a recorrer Double
velocidad Velocidad del objeto Double
Altura Altura Double
tiempoEstimLlegada Tiempo estimado de llegada en minutos Double
precision Precisión Double
fechaHoraActual Fecha y hora actual Date

[Link] EN32_Pickeador
Representa la información del pickeador.

100
Tabla 43.
Atributos EN32_Pickeador
Nombre Descripción Tipo Valor Inicial
codPickeador Código de pickeador String
nomPickeador Nombre de pickeador String
apePickeador Apellido de pickeador String
fecNacimiento Fecha de nacimiento Date
fecIngreso Fecha de ingreso Date

[Link] EN33_Cuadrilla
Representa la información de cuadrilla que conforma un grupo de pickeadores.

Tabla 44.
Atributos EN33_Cuadrilla
Nombre Descripción Tipo Valor Inicial
codCuadrilla Código de cuadrilla String
nomCuadrilla Nombre de cuadrilla String
pickeadores Lista de pickeadores List

[Link] EN34_Asignación de Cuadrilla a Unidad de Transporte

Representa la información de las cuadrillas asignadas a una unidad de transporte en cada turno de preparación de pedidos.

101
Tabla 45.
Atributos EN34_Asignación de Cuadrilla a Unidad de Transporte
Nombre Descripción Tipo Valor Inicial
turnoAsignación Turno de asignación (MAN: mañana, TAR: tarde, MAD: madrugada) String
fechaAsignación Fecha de asignación Date
unidadTransporte Datos de la unidad de transporte Object
cuadrillas Lista de cuadrillas List

[Link] EN35_Informe de Productividad de Picking

Representa la información de la productividad de las cuadrillas durante el picking de productos para preparar los pedidos que serán asignados a
la unidad de transporte.

Tabla 46.
Atributos EN35_Informe de Productividad de Picking

Nombre Descripción Tipo Valor Inicial

fechaIniConsulta Fecha inicial de consulta Date FirstDayMonth()
fechaFinConsulta Fecha final de consulta Date Today()
Cuadrillas Lista de cuadrillas List
nroPickeadores Número de pickeadores por cuadrilla Integer
porcProductPick Porcentaje de productos pickeados por cuadrilla Double
porcProductNoPick Porcentaje de productos no pickeados por cuadrilla Double

102
 totalProductPorCuad Total de productos por cuadrilla Integer
flagMejorCuadrilla Flag de selección de mejor cuadrilla Boolean

[Link] EN36_Notificación de Producto sin Stock

Representa la información del producto sin stock físico en la bodega o nodo.

Tabla 47.
Atributos EN36_Notificación de Producto sin Stock
Nombre Descripción Tipo Valor Inicial
emailCallCenter Email del call center String
asuntoNotificacion Asunto de notificación de producto sin stock String
mensajeNotificacion Mensaje de notificación de producto sin stock. String
fechaNotificacion Fecha de envío de notificación Date Today()
productosSinStock Lista de productos sin stock List
destinatario Datos del destinatario Object

103
4.4.3 Diagrama de Clases de Negocio

Figura 24. DCN de CUN01_Preparar Pedidos

(Elaboración propia, 2018)

104
 Figura 25. DCN de CUN02_Atender Pedido
(Elaboración propia, 2018)

Figura 26. DCN de CUN03_Reprogramar Pedido

(Elaboración propia, 2018)

105
Figura 27. DCN de CUN04_Cancelar Pedido
(Elaboración propia, 2018)

106
Figura 28. DCN de CUN05_Controlar Atención de Pedidos
(Elaboración propia, 2018)

107
Figura 29. DCN de CUN06_Reservar Inventario
(Elaboración propia, 2018)

108
 Figura 30. DCN de CUN07_Monitorear Atención de Pedidos
(Elaboración propia, 2018)

4.5 Realización de los Casos de Uso del Negocio

4.5.1 Especificación de los Casos de Uso del Negocio
Tabla 48.
Especificación de CUN01_Preparar Pedidos
Nombre CUN01_Preparar Pedidos
Actor de Negocio AN01_Coordinador DAD.
Propósito Preparar los pedidos de los destinatarios para ser cargados a las
unidades de transporte.
Breve El caso de uso inicia cuando el Coordinador DAD solicita la
Descripción preparación de pedidos. Luego el despachador notifica la solicitud de
unidades de transporte, elabora las hojas de ruta, imprime las órdenes
de pedido, asigna las unidades de transporte a cuadrilla e imprime las

109
 cubicaciones, para que el pickeador coloque los pedidos en el pallet
y los selle con el film de seguridad, para luego ser cargados a la
unidad de transporte. El caso de uso finaliza cuando el Coordinador
DAD recibe la conformidad de preparación de pedidos concluida.
Precondiciones EN01_Pedido
Debe existir información de pedidos pendientes de entrega o recojo.
EN03_Producto
Debe existir información de productos.
EN10_Destinatario
Debe existir información de destinatarios [RN27].
EN11_Proveedor
Debe existir información de proveedores.
EN13_Chofer
Debe existir información de choferes.
EN14_Unidad de Transporte
Debe existir información de unidades de transporte [RN28] [RN29]
[RN30].
EN15_Ubigeo
Debe existir información de ubicaciones geográficas.
EN21_Fuente de Abastecimiento
Debe existir información de fuentes de abastecimiento.
EN27_Kardex
Debe existir información de stock de productos.
EN28_Item de Pedido
Debe existir información de ítems de pedidos.
EN33_Cuadrilla
Debe existir información de la cuadrilla [RN32].

110
Postcondiciones EN02_Hoja de Ruta
Se elaboró la hoja de ruta.
EN04_Sticker de Despacho
Se elaboró sticker de despacho.
EN05_Notificación de Nota de Crédito
Se notificó la emisión de nota de crédito de producto a contabilidad.
EN06_Solicitud de Unidades de Transporte
Se elaboró la solicitud de unidades de transporte.
EN07_Orden de Pedido
Se elaboró las órdenes de pedido [RN26] y se actualizará como
validada.
EN19_Cubicación
Se elaboró las cubicaciones de los productos en la bodega.
EN20_Ventana Horaria
Se elaboró las ventanas horarias de entrega de pedidos.
EN23_Notificación de Compra de Producto
Se notificó compra de producto.
EN34_Asignación de Cuadrilla a Unidad de Transporte
Se asignó cuadrillas a unidad de transporte [RN33].
EN36_Notificación de Producto sin Stock
Se notificó productos sin stock.
Flujo Normal de Eventos
1. El Coordinador DAD solicita la preparación de pedidos [RN03].
2. El Despachador notifica la solicitud de unidades de transporte al proveedor.
3. El Despachador elabora las hojas de ruta que incluye los pedidos que se van a entregar
como los pedidos que se van a recoger en el punto destino para cada unidad de
transporte [RN04].
4. El Despachador imprime las órdenes de pedido.
5. El Despachador asigna cuadrilla a unidad de transporte.
6. El Despachador imprime las cubicaciones de los productos.
7. El Pickeador consulta la orden de pedido a preparar.
8. El Pickeador prepara el pallet.
9. El Pickeador consulta la ubicación de producto.

111
10. El Pickeador verifica existencia de producto en anaquel.
11. El Pickeador retira el producto de anaquel.
12. El Pickeador agrega el producto al carrito de almacén.
13. El Pickeador verifica si no hay más productos en la orden de pedido.
14. El Pickeador actualiza la orden de pedido como Validada.
15. El Pickeador verifica si el pallet está lleno.
16. El Pickeador sella el bulto con el film de seguridad [RN16].
17. El Pickeador elabora el sticker de despacho.
18. El Pickeador coloca el sticker de despacho en bulto.
19. El Pickeador designa el pallet a muelle de carga [RN18].
20. El Maquinista traslada pallet al muelle de carga.
21. El Estibador carga los pedidos a la unidad de transporte [RN02].
22. El Pickeador verifica si ya no hay órdenes de pedido a preparar.
23. El Despachador verifica si no hay productos sin stock.
24. El Despachador notifica ventana horaria de entrega de pedido al destinatario [RN19].
25. El Despachador comunica preparación de pedidos concluida al Coordinador DAD.
26. El Coordinador DAD recibe conformidad de preparación de pedidos concluida y el
caso de uso finaliza.

112
 Flujos Alternativos
El Pickeador verifica que el producto no está en anaquel
10.1. Si en [10.] el Pickeador verifica que el producto no está en anaquel entonces el
Pickeador notifica producto sin stock a Call Center.
10.2. El Call Center informa al Destinatario el producto sin stock.
10.3. El Call Center notifica emisión de nota de crédito de producto a contabilidad y el
caso de uso continúa en [13.].

El Pickeador verifica que hay más productos en la orden de pedido

13.1. Si en [13.] el Pickeador verifica que hay más productos en la orden de pedido
entonces el caso de uso continúa en [9.].

El Pickeador verifica que pallet no está lleno

15.1. Si en [15.] el Pickeador verifica que pallet no está lleno entonces el Pickeador carga
pedido al pallet.
15.2. El Pickeador verifica que no hay órdenes de pedido a preparar y el caso de uso
continúa en [16.].

El Pickeador verifica que hay órdenes de pedido a preparar

22.1. Si en [22.] o en [15.2.] el Pickeador verifica que hay órdenes de pedido a preparar
entonces el caso de uso continúa en [7.].

El Despachador verifica que hay productos sin stock

23.1. Si en [23.] el Despachador verifica que hay productos sin stock entonces notifica
compra de productos y el caso de uso continúa en [24.].

Tabla 49.
Especificación de CUN02_Atender Pedidos
Nombre CUN02_Atender Pedidos
Actor de Negocio AN01_Coordinador DAD.
Propósito Entregar pedido, recoger productos e intercambiar productos
defectuosos al domicilio del cliente o tienda de la empresa Retail.

113
Breve El caso de uso inicia cuando el Coordinador DAD solicita la atención
Descripción de pedidos. Luego el Chofer consulta la hoja de ruta para dirigirse al
punto destino para la entrega del pedido, recojo de productos o
intercambio de productos a domicilio del cliente o tienda de la
empresa Retail. El caso de uso finaliza cuando el Coordinador DAD
recibe la conformidad de atención de pedidos.
Precondiciones EN01_Pedido
Debe existir información de pedidos pendientes de entrega o recojo.
EN02_Hoja de Ruta
Debe existir información de hojas de ruta.
EN03_Producto
Debe existir información de productos.
EN07_Orden de Pedido
Debe existir información de órdenes de pedido [RN26].
EN10_Destinatario
Debe existir información de destinatarios [RN27].
EN15_Ubigeo
Debe existir información de ubicaciones geográficas.
EN18_Motivo de Pedido
Debe existir información de motivos de pedido.
EN20_Ventana Horaria
Debe existir información de ventanas horarias.
EN28_Item de Pedido
Debe existir información de ítems de pedidos.
Postcondiciones EN01_Pedido
Se actualizó pedido como atendido, no atendido o entregado a tienda.
EN07_Orden de Pedido
Se firmó la orden de pedido por el cliente.
EN28_Item de Pedido
Se actualizó los productos recogidos de un pedido.
Flujo Normal de Eventos
1. El Coordinador DAD solicita atención de pedidos.
2. El Chofer consulta la hoja de ruta.

114
3. El Chofer se dirige a la dirección destino.
4. El Chofer verifica si el Destinario se encuentra en el punto destino.
5. El Chofer verifica existencia de recojo de productos en la hoja de ruta.
6. El Estibador carga productos a la unidad de transporte.
7. El Chofer registra productos recogidos.
8. El Chofer verifica existencia de entrega de pedidos en la hoja de ruta.
9. El Estibador descarga pedidos de la unidad de transporte.
10. El Estibador entrega los pedidos al Destinatario.
11. El Chofer solicita la firma del Destinatario [RN01].
12. El Aceptante firma las órdenes de pedido.
13. El Chofer entrega copia de órdenes de pedido firmada al Destinatario.
14. El Chofer verifica si el Destinatario es un Cliente.
15. El Chofer registra pedidos como Atendido [RN10].
16. El Chofer verifica que no hay pedidos a atender.
17. El Chofer regresa a la bodega.
18. El Chofer comunica atención de pedidos concluida.
19. El Coordinador DAD recibe la conformidad de atención de pedidos y el caso de uso
finaliza.

115
 Flujos Alternativos
El Chofer verifica que Destinario no se encuentra en el punto destino
4.1. Si en [4.] el Chofer verifica que Destinatario no se encuentra en el punto destino
entonces el Chofer actualiza pedido como no atendido [RN09] [RN20] y el caso de uso
continúa en [16.].

El Chofer verifica que no hay recojo de productos en la hoja de ruta

5.1. Si en [5.] el Chofer verifica que no hay recojo de productos en la hoja de ruta entonces
el caso de uso continúa en [8.].

El Chofer verifica que no hay entrega de pedidos en la hoja de ruta

8.1. Si en [8.] el Chofer verifica que no hay entrega de pedidos en la hoja de ruta entonces
el caso de uso continúa en [16.].

El Chofer verifica que el Destinatario es una tienda

14.1. Si en [14.] el Chofer verifica que el Destinatario es una tienda de la empresa Retail
entonces el Chofer registra el pedido como entregado a tienda [RN11] y el caso de uso
continúa en [16.].

El Chofer verifica que hay órdenes de pedido a atender

16.1. Si en [16.] el Chofer verifica que hay órdenes de pedido a atender entonces el caso
de uso continúa en [2.].

Tabla 50.
Especificación de CUN03_Reprogramar Pedido
Nombre CUN03_Reprogramar Pedido
Actor de Negocio AN02_Cliente.
Propósito Reprogramar la entrega del pedido e intercambio de productos
defectuosos al Cliente.
Breve El caso de uso inicia cuando el Cliente solicita la reprogramación de
Descripción su pedido. Luego Call Center reprograma fecha de entrega de pedido,
programa recojo de productos defectuosos a domicilio o registra

116
 fecha de devolución de productos defectuosos a tienda en caso
hubiera productos con defectos. El caso de uso finaliza cuando el
Cliente recibe la conformidad de reprogramación de su pedido.
Precondiciones EN01_Pedido
Debe existir información de pedidos pendientes de entrega o que
hayan sido entregados para la reprogramación de su entrega o
intercambio de productos defectuosos.
EN03_Producto
Debe existir información de productos.
EN10_Destinatario
Debe existir información de destinatarios [RN27].
EN18_Motivo de Pedido
Debe existir información de motivos de pedido.
EN21_Fuente de Abastecimiento
Debe existir información de fuentes de abastecimiento.
EN27_Kardex
Debe existir información del stock de productos.
EN28_Item de Pedido
Debe existir información de ítems de pedidos.

117
Postcondiciones EN01_Pedido
Se actualizó pedido como reprogramado, se programará recojo de
productos a domicilio o se registrará devolución de productos en
tienda.
EN23_Notificación de Compra de Producto
Se notificó compra de productos.
EN24_Notificación de Reposición de Producto
Se notificó reposición de productos en tienda a la bodega.
EN26_Notificacion de Reprogramación de Pedido
Se notificó la reprogramación del pedido que el chofer está
transportando.
EN27_Kardex
Se actualizó el stock de los productos.
EN28_Item de Pedido
Se registró productos defectuosos en los ítems de pedido.
Flujo Normal de Eventos
1. El Cliente solicita reprogramación de pedido [RN08].
2. El Call Center consulta pedido del Cliente.
3. El Call Center reprograma pedido [RN05] [RN24] [RN25].
4. El Call Center verifica que pedido no está en ruta.
5. El Call Center valida si no existen productos defectuosos [RN07].
6. El Call Center comunica reprogramación de pedido concluida.
7. El Cliente recibe conformidad de reprogramación de pedido y el caso de uso finaliza.

118
Flujos Alternativos
El Call Center verifica que pedido está en ruta
4.1. Si en [4.] el Call Center verifica que pedido está en ruta [RN31] entonces el Call
Center notifica reprogramación de pedido al Chofer [RN15] y el caso de uso continúa en
[6.].

El Call Center valida que existen productos defectuosos

5.1. Si en [5.] el Call Center valida que existen productos defectuosos entonces el Call
Center registra productos defectuosos.
5.2. El Call Center resta al stock de productos a intercambiar.
5.3. El Call Center valida si el stock actual del producto es mayor o igual al umbral.
5.4. El Call Center valida que hay recojo de productos.
5.5. El Call Center programa recojo de productos a domicilio [RN06] [RN23] y el caso
de uso continúa en [6.]

El Call Center valida que el stock actual del producto es menor al umbral
5.3.1. Si en [5.3.] el Call Center valida que el stock actual del producto es menor al umbral
entonces el Call Center verifica si la fuente de abastecimiento es bodega.
5.3.2. El Call Center notifica compra de productos [RN21] y el caso de uso continúa en
[5.4.].

El Call Center verifica que fuente de abastecimiento es una tienda de la empresa

Retail
[Link]. Si en [5.3.1.] el Call Center verifica que fuente de abastecimiento es una tienda de
la empresa Retail entonces el Call Center notifica reposición de productos [RN22] y el
caso de uso continúa en [5.4.].

El Call Center valida que no hay recojo de productos

5.4.1. Si en [5.4.] el Call Center valida que no hay recojo de productos entonces el Call
Center registra devolución de productos en tienda [RN23] y el caso de uso continúa en
[6.]

119
Tabla 51.
Especificación de CUN04_Cancelar Pedido
Nombre CUN04_Cancelar Pedido
Actor de Negocio AN02_Cliente.
Propósito Cancelar pedido del Cliente, y programar recojo de productos a
domicilio o devolución de productos a tienda.
Breve El caso de uso inicia cuando el Cliente solicita la cancelación de su
Descripción pedido. Luego Call Center cancela el pedido al Cliente, programa
recojo de productos a domicilio o registra fecha de devolución de
productos a tienda. El caso de uso finaliza cuando el Cliente recibe
la conformidad de cancelación de su pedido.
Precondiciones EN01_Pedido
Debe existir información de pedidos pendiente de entrega o
entregado para su cancelación.
EN03_Producto
Debe existir información de productos.
EN10_Destinatario
Debe existir información de destinatarios [RN27].
EN18_Motivo de Pedido
Debe existir información de motivos de pedido.
EN21_Fuente de Abastecimiento
Debe existir información de fuentes de abastecimiento.
EN27_Kardex
Debe existir información de stock de productos.
EN28_Item de Pedido
Debe existir información de ítems de pedidos.

120
Postcondiciones EN01_Pedido
Se actualizó pedido como cancelado, se programará recojo de
productos a domicilio o se registrará devolución de productos en
tienda.
EN05_Notificacion de Nota de Crédito
Se notificó emisión de nota de crédito de pedido a contabilidad.
EN22_Notificacion de Devolución de Producto
Se notificó devolución de producto a tienda al cliente.
EN25_Notificacion de Cancelación de Pedido
Se notificó cancelación de pedido al chofer que lo transporta.
EN27_Kardex
Se actualizó stock de productos.
EN28_Item de Pedido
Se actualizó los productos defectuosos.
Flujo Normal de Eventos
1. El Cliente solicita cancelación de pedido.
2. El Call Center consulta pedido del Cliente.
3. El Call Center cancela pedido.
4. El Call Center verifica que pedido no está en ruta.
5. El Call Center notifica emisión de nota de crédito de pedido a contabilidad [RN16].
6. El Call Center verifica si el pedido fue entregado al cliente.
7. El Call Center valida si no hay productos defectuosos.
8. El Call Center suma al stock de productos.
9. El Call Center valida si hay recojo de productos.
10. El Call Center programa recojo de productos a domicilio [RN06] [RN23].
11. El Call Center comunica cancelación de pedido concluida.
12. El Cliente recibe conformidad de cancelación de pedido y el caso de uso finaliza.

121
 Flujos Alternativos
El Call Center verifica que pedido está en ruta
4.1. Si en [4.] el Call Center verifica que pedido está en ruta [RN31] entonces el Call
Center notifica cancelación de pedido al Chofer [RN14] y el caso de uso continúa en [5.].

El Call Center verifica que pedido no fue entregado al Cliente

6.1. Si en [6.] el Call Center verifica que pedido no fue entregado al Cliente entonces el
caso de uso continúa en [11.].

El Call Center valida que hay productos defectuosos

7.1. Si en [7.] el Call Center valida que hay productos defectuosos [RN07] entonces el
Call Center registra productos defectuosos y el caso de uso continúa en [9.].

El Call Center valida que no hay recojo de productos

9.1. Si en [9.] el Call Center valida que no hay recojo de productos entonces el Call Center
registra devolución de productos en tienda [RN23] y el caso de uso continúa en [11.].

Tabla 52.
Especificación de CUN05_Controlar Atención de Pedidos
Nombre CUN05_Controlar Atención de Pedidos
Actor de Negocio AN03_Gerente de Abastecimiento
Propósito Elaborar el informe de control de atención de pedidos.
Breve El caso de uso inicia cuando el Gerente de Abastecimiento solicita el
Descripción informe de control de atención de pedidos. Luego el Analista de
Abastecimiento elabora el informe de estado de pedidos, el informe
de ranking de proveedores de transporte, el informe de productos de
mayor rotación, el informe de abastecimiento de productos y el
informe de productividad de picking. El caso de uso finaliza cuando
el Gerente de Abastecimiento recibe el informe de control de
atención de pedidos.

122
Precondiciones EN01_Pedido
Debe existir información de pedidos.
EN02_Hoja de Ruta
Debe existir información de hojas de ruta.
EN03_Producto
Debe existir información de productos.
EN10_Destinatario
Debe existir información de destinatarios [RN27].
EN11_Proveedor
Debe existir información de proveedores.
EN13_Chofer
Debe existir información de choferes.
EN16_Familia de Producto
Debe existir información de familias de producto.
EN17_Tipo de Producto
Debe existir información de tipos de producto.
EN18_Motivo de Pedido
Debe existir información de motivos de pedido.
EN20_Ventana Horaria
Debe existir información de ventanas horaria.
EN21_Fuente de Abastecimiento
Debe existir información de fuentes de abastecimiento.
EN27_Kardex
Debe existir información de stock de productos.
EN28_Item de Pedido
Debe existir información de ítems de pedidos.
EN32_Pickeador
Debe existir información de pickeadores.
EN33_Cuadrilla
Debe existir información de cuadrillas.
EN34_Asignación de Cuadrilla a Unidad de Transporte
Debe existir información de cuadrillas asignadas a unidad de
transporte.

123
 Postcondiciones EN08_Informe de Estado de Pedidos
Se elaboró informe de estado de pedidos.
EN09_Informe de Ranking de Proveedores de Transporte
Se elaboró informe de ranking de proveedores de transporte.
EN12_Informe de Productos de Mayor Rotación
Se elaboró informe de productos de mayor rotación.
EN29_Informe de Abastecimiento de Productos
Se elaboró informe de abastecimiento de productos.
EN35_Informe de Productividad de Picking
Se elaboró informe de productividad de picking.
Flujo Normal de Eventos
1. El Gerente de Abastecimiento solicita el informe de control de atención de pedidos.
2. El Analista de Abastecimiento elabora el informe de estado de pedidos.
3. El Analista de Abastecimiento elabora el informe de ranking de proveedores de
transporte.
4. El Analista de Abastecimiento elabora el informe de productos de mayor rotación.
5. El Analista de Abastecimiento elabora el informe abastecimiento de productos.
6. El Analista de Abastecimiento elabora el informe de productividad de picking.
7. El Gerente de Abastecimiento recibe el informe de control de atención de pedidos y el
caso de uso finaliza.
Flujos Alternativos
No aplica.

Tabla 53.
Especificación de CUN06_Reservar Inventario
Nombre CUN06_Reservar Inventario
Actor de Negocio AN01_Coordinador DAD
Propósito Reservar inventario para un pedido de venta concreto.
Breve El caso de uso inicia cuando el Coordinador DAD solicita reserva de
Descripción inventario. Luego el Despachador registra el pedido cuyo pago ha
sido validado por la entidad bancaria y resta al stock de productos.

124
 El caso de uso finaliza cuando el Coordinador DAD recibe la
conformidad de reserva de inventario.
Precondiciones EN01_Pedido
Debe existir información de pedidos con número de reserva.
EN03_Producto
Debe existir información de productos.
EN21_Fuente de Abastecimiento
Debe existir información de fuentes de abastecimiento.
EN27_kardex
Debe existir información de stock de productos.
Postcondiciones EN01_Pedido
Se registró el pedido en estado pendiente.
EN23_Notificación de Compra de Producto
Se notificó compra de producto al proveedor.
EN24_Notificación de Reposición de Producto
Se notificó reposición de producto en tienda a la bodega.
EN27_Kardex
Se actualizó el stock de productos.
Flujo Normal de Eventos
1. El Coordinador DAD solicita reserva de inventario.
2. El Despachador consulta pedido con número de reserva.
3. El Despachador registra pedido en estado pendiente.
4. El Despachador resta al stock de productos.
5. El Despachador valida si el stock actual es menor al umbral.
6. El Despachador verifica si fuente de abastecimiento es bodega.
7. El Despachador envía notificación de compra de producto [RN21].
8. El Despachador comunica actualización de reserva de inventario.
9. El Coordinador DAD recibe conformidad de reserva de inventario y el caso de uso
finaliza.

125
 Flujos Alternativos
El Despachador valida si el stock actual es mayor o igual al umbral
5.1. En [5.] el Despachador valida si el stock actual es mayor o igual al umbral entonces
el caso de uso continúa en [8.].

El Despachador verifica si fuente de abastecimiento es tienda

6.1. En [6.] el Despachador verifica si fuente de abastecimiento es tienda entonces el
Despachador envía notificación de reposición de productos a bodega [RN22] y el caso de
uso continua en [8.].

Tabla 54.
Especificación de CUN07_Monitorear Atención de Pedidos
Nombre CUN07_Monitorear Atención de Pedidos
Actor de Negocio AN01_Coordinador DAD
Propósito Monitorear la atención de pedidos de las unidades de transporte
desde su salida de la bodega, durante su trayectoria a cada punto
destino, hasta su llegada a la bodega.
Breve El caso de uso inicia cuando el Coordinador DAD solicita monitoreo
Descripción de atención de pedidos. Luego el Monitoreador monitorea la salida
de las unidades de transporte de la bodega, monitorea la adherencia
a la ruta programada, monitorea los cambios en los estados de los
pedidos y monitorea la llegada de las unidades de transporte a la
bodega. El caso de uso finaliza cuando el Coordinador DAD recibe
la conformidad de monitoreo de atención de pedidos concluida.

126
Precondiciones EN01_Pedido
Debe existir información de pedidos pendientes de entrega o recojo.
EN02_Hoja de Ruta
Debe existir información de hojas de ruta.
EN10_Destinatario
Debe existir información del destinatario [RN27].
EN13_Chofer
Debe existir información del chofer.
EN14_Unidad de Transporte
Debe existir información de unidades de transporte [RN28] [RN29]
[RN30].
EN30_Mapa
Debe existir información de las calles, avenidas e imágenes del mapa.
EN31_GPS
Debe existir información de la señal GPS capturada de la unidad de
transporte.
Postcondiciones EN30_Mapa
Se mostró información del punto de ubicación de la unidad de
transporte en el mapa, así como la distancia y tiempo de llegada al
punto destino.
Flujo Normal de Eventos
1. El Coordinador DAD solicita monitoreo de atención de pedidos.
2. El Monitoreador monitorea salida de unidades de transporte de la bodega [RN12].
3. El Monitoreador monitorea adherencia a la ruta programada de las unidades de
transporte.
4. El Monitoreador soluciona problemas que se presenten en las unidades de transporte
[RN13].
5. El Monitoreador calcula el tiempo aproximado de llegada del pedido a solicitud del
Cliente.
6. El Monitoreador monitorea los estados de los pedidos asignados a cada unidad de
transporte.
7. El Monitoreador monitorea llegada de unidades de transporte a la bodega.
8. El Monitoreador informa que el monitoreo de atención de pedidos ha concluido.

127
9. El Coordinador DAD recibe conformidad de monitoreo de atención de pedidos
concluida y el caso de uso finaliza.
Flujos Alternativos
No aplica.

128
4.5.2 Diagramas de Proceso

Figura 31. Proceso TO-BE de CUN01_Preparar Pedidos

(Elaboración propia, 2018)

129
Figura 32. Proceso TO-BE de CUN02_Atender Pedidos
(Elaboración propia, 2018)

130
Figura 33. Proceso TO-BE de CUN03_Reprogramar Pedido
(Elaboración propia, 2018)

131
Figura 34. Proceso TO-BE de CUN04_Cancelar Pedido
(Elaboración propia, 2018)

132
Figura 35. Proceso TO-BE de CUN05_Controlar Atención de Pedidos
(Elaboración propia, 2018)

133
Figura 36. Proceso TO-BE de CUN06_Reservar Inventario
(Elaboración propia, 2018)

134
Figura 37. Proceso TO-BE de CUN07_Monitorear Atención de Pedidos
(Elaboración propia, 2018)

135
4.5.3 Lista de las Actividades a Automatizar
[Link] Actividades a Automatizar de CUN01_Preparar Pedidos
 Notificar solicitud de unidades de transporte.
 Elaborar hojas de ruta.
 Imprimir órdenes de pedido.
 Asignar cuadrilla a hoja de ruta.
 Imprimir cubicación.
 Notificar producto sin stock a Call Center.
 Notificar emisión de nota de crédito de producto a Contabilidad.
 Verificar productos sin stock.
 Notificar compra de productos.
 Notificar ventana horaria de entrega de pedido al destinatario.

[Link] Actividades a Automatizar de CUN02_Atender Pedidos

 Consultar hoja de ruta.
 Registrar pedidos como No Atendido.
 Verificar existencia de recojo de productos.
 Registrar productos recogidos.
 Verificar existencia de entrega de pedidos.
 Firmar órdenes de pedido.
 Verificar tipo de destinatario.
 Registrar pedidos como Entregado a Tienda.
 Registrar pedidos como Atendido.
 Verificar existencia de pedidos a atender.

[Link] Actividades a Automatizar de CUN03_Reprogramar Pedido

 Consultar pedido del cliente.
 Reprogramar pedido.
 Verificar pedido en ruta.
 Validar existencia de productos defectuosos.
 Registrar productos defectuosos.
 Notificar reprogramación de pedido al chofer.
 Restar al stock de productos a intercambiar.

136
 Validar umbral de stock de productos.
 Verificar fuente de abastecimiento.
 Notificar compra de productos.
 Notificar reposición de productos.
 Validar recojo de productos.
 Programar recojo de productos a domicilio.
 Registrar devolución de productos en tienda.

[Link] Actividades a Automatizar de CUN04_Cancelar Pedido

 Consultar pedido del cliente.
 Cancelar pedido.
 Verificar pedido en ruta.
 Notificar cancelación de pedido al chofer.
 Notificar emisión de nota de crédito de pedido a contabilidad.
 Validar existencia de productos defectuosos.
 Registrar productos defectuosos.
 Sumar al stock de productos.
 Verificar entrega de pedido.
 Validar recojo de productos.
 Programar recojo de productos a domicilio.
 Registrar devolución de productos en tienda.

[Link] Actividades a Automatizar de CUN05_Controlar Atención de Pedidos

 Elaborar informe de estado de pedidos.
 Elaborar informe de ranking de proveedores de transporte.
 Elaborar informe de productos de mayor rotación.
 Elaborar informe de abastecimiento de productos.
 Elaborar informe de productividad de picking.

[Link] Actividades a Automatizar de CUN06_Reservar Inventario

 Consultar pedido con número de reserva.
 Registrar pedido.
 Restar al stock de productos.
 Validar umbral de stock.

137
 Verificar fuente de abastecimiento.
 Notificar compra de producto.
 Notificar reposición de producto.

[Link] Actividades a Automatizar de CUN07_Monitorear Atención de Pedidos

 Monitorear salida de unidades de transporte de la bodega.
 Monitorear adherencia a la ruta programada de las unidades de transporte.
 Calcular tiempo aproximado de llegada del pedido a solicitud del cliente.
 Monitorear estados de pedidos asignados a cada unidad de transporte.
 Monitorear llegada de unidades de transporte a la bodega.

4.6 Conclusiones
 A partir de los objetivos del proyecto, el campo de acción y la descripción de sus procesos
AS-IS se logran identificar los actores, trabajadores, entidades y casos de uso del
negocio.

 A partir de la identificación de los casos de uso de negocio se logra modelar los

diagramas de casos de uso de negocio, además del flujo de actividades TO-BE que se
realiza en cada caso de uso de negocio.

 En el diagrama de procesos TO-BE nos permite señalar las actividades candidatas que
se van a automatizar, además de conocer los trabajadores del negocio que las ejecutan y
las entidades del negocio que se manipulan.

138
5 CAPÍTULO 4: REQUERIMIENTOS
5.1 Introducción
Se desarrolla el presente capítulo a fin de poder definir los requerimientos del Software,
tantos los funcionales, como los no funcionales, para determinar los problemas a resolver.

Se realiza la identificación de los actores del sistema, el diagrama de los actores del sistema,
diagrama de paquete del sistema, y su relación entre ellos y el diagrama de casos de uso de
sistema por paquete.

También en este capítulo se desarrolla la especificación de los CUS, y la especificación alto

nivel del núcleo central.

Finalmente se desarrolla el modelo conceptual y su respectivo diccionario, que ayuda a la

elaboración de prototipos del sistema propuesto.

5.2 Especificación de los Requerimientos del Software

5.2.1 Requerimientos Funcionales
Tabla 55.
Requerimientos Funcionales asociados a los Casos de Uso
Requerimientos Funcionales asociados a los Casos de Uso
Código Descripción
RF06 Reservar Pedido
El sistema debe permitir exponer un servicio web que realice la reserva del
pedido recibiendo como parámetros el código, número de reserva, fecha de
solicitud y fecha de despacho del pedido, asimismo el código, número de
documento de identidad, apellido, nombre y dirección del cliente, y la lista
detallada del pedido con los campos código, nombre, precio unitario y cantidad
de producto.

139
 Requerimientos Funcionales asociados a los Casos de Uso
RF07 Generar Hojas de Ruta
El sistema debe permitir generar las hojas de ruta en PDF sobre un directorio
mostrando el nombre de la bodega, el código, fecha de generación y fecha de
despacho de la hoja de ruta, además el número de placa, número SOAT, peso
y volumen máximo de carga de la unidad, el apellido, nombre y brevete del
chofer, asimismo la lista detallada de la hoja de ruta con el campo orden de
despacho de pedidos obtenido en base a la ruta optimizada por tiempo y
distancia, el rango horario, el código de pedido, el apellido y nombre del
cliente o el nombre de la tienda, la modalidad del pedido (entrega o recojo) y
la dirección de despacho.
RF08 Notificar Unidades Requeridas
El sistema debe permitir notificar por email las unidades de transporte
asignadas en las hojas de ruta a los proveedores mostrando la fecha de
solicitud, el nombre de la bodega o nodo que lo solicita, la fecha y hora de
envío de las unidades de transporte, la lista de las unidades de transporte
requeridas con los campos número de placa, marca, modelo, peso y volumen
máximo de carga de la unidad de transporte.
RF09 Generar Pedidos
El sistema debe permitir generar los pedidos en PDF sobre un directorio
mostrando el código, la fecha de solicitud y la fecha de despacho del pedido,
el apellido, nombre del cliente o nombre de la tienda, la dirección de despacho,
la lista detallada del pedido con los campos código, nombre, precio unitario y
cantidad de productos, el subtotal, el total bruto (sin IGV) y el total neto (con
IGV) del pedido. Los campos precio unitario, subtotal, total bruto y neto del
pedido solo se mostrarán cuando el destinatario sea un cliente, en caso sea una
tienda se ocultarán dichos campos.
RF10 Generar Cubicación de Pedidos
El sistema debe permitir generar las cubicaciones de los pedidos en PDF sobre
un directorio mostrando el nombre de la bodega o nodo y un listado de las
ubicaciones de los productos del pedido con los campos área de la bodega,
pasillo del área, lado del pasillo, altura del lado y profundidad de la altura,
además del código y nombre del producto.

140
 Requerimientos Funcionales asociados a los Casos de Uso
RF11 Notificar Ventanas Horarias
El sistema debe permitir notificar las ventanas horarias de los pedidos al cliente
o controller de tienda mostrando el número de verificación, el código de
pedido, la fecha y rango horario de despacho.
RF12 Notificar Abastecimiento de Productos
El sistema debe permitir notificar por email a los Coordinadores DAD la
necesidad de abastecimiento de productos que se hace necesario tanto en
bodegas como en nodos, mostrando el código, nombre, marca, stock mínimo,
stock actual, fecha máxima de abastecimiento y estado de abastecimiento del
producto.
RF13 Asignar Cuadrillas a Hoja de Ruta
El sistema debe permitir asignar las cuadrillas a la hoja de ruta registrando la
hoja de ruta y las cuadrillas a asignar con los campos código, nombre y total
de pickeadores.
RF14 Registrar Productos No Ubicados
El sistema debe permitir registrar los productos no ubicados ingresando la
bodega, el pickeador que lo registra, el código de pedido, y la lista de productos
no ubicados con su respectiva cantidad y notificarlos por email a Call Center
mostrando el código de pedido, el nombre, apellido y teléfono del destinatario,
además del listado de productos no ubicados con los campos código, nombre
y cantidad no ubicada de productos.
RF15 Consultar Hoja de Ruta
El sistema debe de permitir consultar la hoja de ruta al chofer desde su
smartphone mostrando el nombre de la bodega, el código, fecha de generación
y fecha de despacho de la hoja de ruta, además el número de placa, número
SOAT, peso y volumen máximo de carga de la unidad, el apellido, nombre y
brevete del chofer, asimismo la lista detallada de la hoja de ruta con el campo
orden de despacho de pedidos obtenido en base a la ruta optimizada por tiempo
y distancia, el rango horario, la fecha real de despacho, el código de pedido, el
apellido y nombre del cliente o el nombre de la tienda, la dirección de despacho
y el estado del pedido.

141
 Requerimientos Funcionales asociados a los Casos de Uso
RF16 Registrar Despacho de Pedido
El sistema debe permitir registrar el despacho del pedido actualizando la fecha
pactada del despacho, el estado del pedido como atendido, entregado a tienda
o no atendido, el número de verificación en el caso de despacho atendido o
entregado a tienda, y el motivo en el caso de despacho no atendido.
RF17 Consultar pedidos
El sistema debe permitir consultar los pedidos del cliente de hace 30 días
ingresando el número de DNI del cliente mostrando el nombre y apellido del
cliente, y un listado de pedidos con los campos código, fecha de solicitud,
fecha de entrega, fecha de reprogramación, fecha de cancelación, fecha de
devolución y estado del pedido.
RF18 Registrar Reprogramación de Pedido
El sistema debe permitir registrar la reprogramación del pedido ingresando la
fecha de reprogramación y el motivo del pedido reprogramado, además de
notificar por SMS la reprogramación del pedido al chofer si el pedido se
encuentra en ruta mostrando el código del pedido, además del nombre y
apellido del cliente.
RF19 Registrar Cancelación de Pedido
El sistema debe permitir registrar la cancelación del pedido ingresando la fecha
de cancelación y el motivo del pedido cancelado, además de notificar por SMS
la cancelación del pedido al chofer si el pedido se encuentra en ruta mostrando
el código del pedido, además del nombre y apellido del cliente.
RF20 Notificar Emisión de Nota de Crédito
El sistema debe permitir notificar por email la emisión de nota de crédito a
contabilidad en caso de cancelación de pedido o productos no ubicados en
bodega o nodo, mostrando el nombre, apellido, email y teléfono del cliente,
además del código del pedido, y el listado de productos a anularse con los
campos código, nombre, precio, cantidad, subtotal de producto, así como el
monto total de anulación.

142
 Requerimientos Funcionales asociados a los Casos de Uso
RF21 Registrar Productos Defectuosos
El sistema debe permitir registrar productos defectuosos de un pedido
seleccionando el producto del detalle del pedido e ingresando la cantidad de
productos defectuosos y una breve descripción del defecto.
RF22 Programar Devolución de Productos
El sistema debe permitir programar la devolución de productos de un pedido
ingresando la opción recojo a domicilio o devolución en tienda, la fecha de
devolución del pedido, el nombre de la tienda en caso de escoger la opción
devolución a tienda, además de seleccionar los productos a devolver de un
pedido.
RF23 Monitorear Despacho de Pedidos
El sistema debe permitir monitorear el despacho de los pedidos en tiempo real
a través de un dashboard que se actualiza periódicamente indicando el
porcentaje de los pedidos pendientes, atendidos, no atendidos, reprogramados
y cancelados de una unidad seleccionada, asimismo se mostrará el detalle de
cada uno de los estado de los pedidos para dicha unidad, y la ubicación actual
de la unidad con respecto al siguiente pedido a despachar mostrando la
distancia y tiempo estimado de llegada al punto de despacho.
RF24 Generar Informe de Estado de Pedidos
El sistema debe permitir consultar por el rango de fecha de despacho de hoja
de ruta, además de la bodega o nodo, y generar en PDF el informe de estado
de pedidos mostrando la fecha inicial y final de la consulta, la bodega o nodo,
el total de pedidos atendidos, el total de pedidos no atendidos, el total de
pedidos entregados a tienda, el total de pedidos reprogramados, el total de
pedidos cancelados, el total de pedidos entregados fuera de la ventana horaria
y el porcentaje de motivos por estados del pedido (no atendido, reprogramado
y cancelado).

143
 Requerimientos Funcionales asociados a los Casos de Uso
RF25 Generar Informe de Ranking de Proveedores de Unidades
El sistema debe permitir consultar por el rango de fecha de despacho de hoja
de ruta, además de la bodega o nodo, y generar en PDF el informe de ranking
de proveedores de unidades en PDF mostrando la fecha inicial y final de la
consulta, la bodega o nodo, el porcentaje de pedidos despachados por
proveedor dentro y fuera de la ventana horaria, y el porcentaje de pedidos no
despachados por proveedor.
RF26 Generar Informe de Productos de Mayor Rotación
El sistema debe permitir consultar por el rango de fecha de venta del pedido,
además de los distritos de despacho de los pedidos al cliente, y generar en PDF
el informe de productos de mayor rotación mostrando la fecha inicial y final
de la consulta, el porcentaje de venta de productos por familia de producto, y
el porcentaje de venta de productos por familia y tipo de producto.
RF27 Generar Informe de Abastecimiento de Productos
El sistema debe permitir consultar por rango de fechas de notificación de
abastecimiento de productos, además de la bodega o tienda, y generar en PDF
el informe de abastecimiento de productos mostrando la fecha inicial y final
de la consulta, el tipo de abastecimiento (compra o reposición de productos),
el nombre de la bodega o nodo que abastece a tienda o que solicita compra de
producto, el nombre de la tienda a abastecer en caso de reposición de
productos, además de la lista de productos a abastecer con los campos código,
nombre, stock mínimo, stock actual y cantidad a abastecer del producto,
asimismo el total de productos abastecidos y el total de productos pendientes
a abastecer.

144
 Requerimientos Funcionales asociados a los Casos de Uso
--RF28 Generar Informe de Productividad de Picking
El sistema debe permitir consultar por rango de fechas de despacho de hoja de
ruta, además de la bodega o nodo, y generar en PDF el informe de
productividad de picking mostrando la fecha inicial y final de la consulta, el
nombre de la bodega o nodo, además de la lista de cuadrillas asignadas a la
hoja de ruta, con los campos código de hoja de ruta, número de placa de la
unidad, nombre de la cuadrilla, cantidad de pickeadores por cuadrilla, total de
productos asignados por cuadrilla, porcentaje de productos pickeados,
porcentaje de productos no pickeados, además del indicador de mejor cuadrilla
que es calculado por la cuadrilla que tiene mayor porcentaje de pedidos
preparados en función al total de pedidos asignados y a la cantidad de
pickeadores de la cuadrilla.
RF29 Actualizar Proveedor
El sistema debe permitir crear y modificar la información del proveedor.
RF30 Actualizar Choferes
El sistema debe permitir buscar, crear, modificar, activar y desactivar los
choferes.
RF31 Actualizar Unidades Disponibles
El sistema debe permitir buscar, crear, modificar, activar y desactivar las
unidades disponibles.
RF32 Validar Stock de Productos
El sistema debe permitir exponer un servicio web que valide si los productos
de un pedido cuentan con stock disponible, recibiendo como parámetro el
detalle del pedido.
RF33 Consultar Productos sin Stock
El sistema debe permitir exponer un servicio web que retorne los productos sin
stock en determinadas bodegas o nodos, recibiendo como parámetro el tipo de
producto.

145
 Requerimientos Funcionales asociados a los Casos de Uso
RF34 Cargar Productos a Bodega o Nodo
El sistema debe permitir actualizar el kardex de los productos que son
abastecidos a las bodegas o nodos, ingresando el proveedor o bodega que
abastece de productos, la bodega o nodo que recibe los productos, la fecha de
abastecimiento y el archivo CSV de productos con sus respectivas cantidades
a abastecer, mostrando finalmente el “Resumen de Carga de Datos” y la “Lista
de Errores en la Carga de Datos” en caso los hubiera.
RF01 Actualizar Usuarios
El sistema debe permitir buscar, crear, modificar, activar y desactivar los
usuarios del sistema.
RF02 Actualizar Perfiles
El sistema debe permitir buscar, crear, modificar, activar y desactivar perfiles,
además de asignar los usuarios al perfil.
RF03 Administrar Permisos
El sistema debe permitir administrar los permisos del perfil asignando las
opciones de menú que tendrá acceso, además de crear y eliminar las opciones
de menú.
RF04 Validar Acceso al Sistema
El sistema debe permitir validar el acceso del usuario al sistema.
RF05 Cambiar Contraseña
El sistema debe permitir cambiar la contraseña del usuario del sistema.

Tabla 56.
Requerimientos Funcionales Generales
Requerimientos Funcionales Generales
Código Descripción
RFG01 Frecuencia de Cambio de Contraseña
El sistema debe permitir obligar al usuario a cambiar su contraseña cada 60
días.

146
 Requerimientos Funcionales Generales
RFG02 Longitud de Contraseña
El sistema debe permitir registrar contraseñas con una longitud mínima de 8
caracteres y máxima de 15 caracteres.
RFG03 Caracteres de Contraseña
El sistema debe permitir registrar contraseñas que contengan al menos un
caracter mayúscula, un caracter minúscula, un caracter numérico y un caracter
especial.
RFG04 Registrar Tareas de Procesos por Lotes
El sistema debe permitir registrar las tareas realizadas en los procesos por lotes
ejecutados en el sistema indicando el número de proceso, la fecha y hora de
inicio de ejecución del proceso, la fecha y hora fin de ejecución del proceso,
el nombre del proceso, el estado del proceso (satisfactorio o error), la lista de
tareas indicando la fecha y hora de inicio de ejecución de la tarea, la fecha y
hora fin de ejecución de la tarea, el nombre de la tarea, el código de respuesta,
el mensaje de respuesta, el detalle técnico del error y el estado de la tarea
(satisfactorio o error).
RFG05 Generar Log de Errores
El sistema debe permitir generar log de errores indicando el código,
descripción, fecha y hora del error.
RFG06 Exportación de Informes y Documentos
El sistema debe permitir exportar informes y documentos a formato PDF.

5.2.2 Requerimientos No Funcionales

Tabla 57.
Requerimientos No Funcionales
Requerimientos No Funcionales
Requisitos de Usabilidad
RNF01 Perfil de Usuarios que usan el Sistema
El sistema debe ser usado por usuarios de logística y despacho de pedidos con
entrenamiento previo especializado.

147
 Requerimientos No Funcionales
RNF02 Colores del Mensajes del Sistema
En caso de error el sistema debe mostrar el mensaje en color rojo, en caso de
validación de datos el sistema debe mostrar el mensaje en color verde y en caso
de proceso satisfactorio el sistema debe mostrar el mensaje en color azul.
RNF20 Manejo de Errores
Los mensajes de error deben ser reportados por la propia aplicación en la
medida de las posibilidades y no por el Sistema Operativo. Los mensajes del
sistema deben estar en el idioma español.
Requisitos de Confiabilidad
RNF03 Disponibilidad del Sistema
El sistema debe estar disponible 24x7 (24 horas diarias, 7 días a la semana) al
90%.
RNF04 Tiempo Promedio entre Fallas
El tiempo promedio entre fallas (MTBF) del sistema debe ser de 90 días.
RNF05 Duración Promedio de una Reparación
La duración promedio de una reparación (MTTR) del sistema no debe ser
mayor de 2 horas.
RNF21 Confidencialidad de Contraseñas de Usuario
El sistema deberá almacenar las contraseñas de usuario encriptadas en la base
de datos.
RNF28 Confidencialidad de Datos almacenados en Firebase Realtime Database
El sistema deberá proteger los datos almacenados en Firebase Realtime
Database contra el acceso no autorizado.
RNF29 Protección de Acceso a Recursos en Servicios REST
El sistema deberá proteger los servicios REST del acceso no autorizado a los
recursos.
Requisitos de Rendimiento
RNF06 Promedio de Transacciones por Minuto
El sistema debe de soportar un promedio de 100 transacciones por minuto de
base de datos.

148
 Requerimientos No Funcionales
RNF07 Concurrencia de Usuarios
El sistema debe soportar una concurrencia de 100 usuarios.
RNF08 Tiempo Promedio de Respuesta del Sistema
El tiempo promedio de respuesta del sistema debe ser de 3 segundos.
Requisitos de Soporte
RNF09 Navegadores Soportados
El cliente web del sistema debe soportar el navegador Chrome versión 66.0 o
superior.
RNF22 Sistema Operativo Móvil Soportado
El sistema móvil debe soportar el sistema operativo Android 7.0 Nougat o
superior.
Restricciones de Diseño, Interfaz, Físicas y de Implementación
RNF23 Formato de Exportación de Reporte
Los reportes del sistema deben ser exportados en formato PDF.
RNF24 Lenguaje de Programación
El sistema debe ser desarrollado sobre el lenguaje de programación Java
usando el JDK 1.8.
RNF25 Motor de Base de Datos
El sistema debe usar el motor de base de datos de MySQL 5.7.
RNF26 Servidor de Aplicaciones
El sistema web y web services debe ser desplegado sobre el servidor de
aplicaciones GlassFish 5.0.
RNF10 Colores Institucionales de la Interfaz de Usuario
Las interfaces de usuario deben estar basadas en un diseño web responsive en
el que predominará los colores institucionales de la empresa Retail, según la
imagen adjunta:

149
 Requerimientos No Funcionales
RNF11 Logotipo de la Empresa
El logotipo de la empresa Retail debe estar presente en la parte superior
izquierda de las interfaces desktop web y reportes del sistema y en la parte
superior central de las interfaces mobile web del sistema.
RNF12 Distribución del Contenido Desktop Web de la Página del Sistema
La interfaz desktop web del sistema debe abarcar el ancho de la pantalla donde
el logo y el menú debe ser el 20% del ancho total de la página y el 80% restante
corresponde al título y cuerpo de la página, según la imagen adjunta:

RNF13 Distribución del Contenido Mobile Web de la Página del Sistema

La interfaz mobile web del sistema debe abarcar el ancho de la pantalla donde
el menú y el logo debe ser el 10% de la altura total y el 90% restante
corresponde al cuerpo de la página, según la imagen adjunta:

RNF14 Interfaz con el Proceso Batch de Validación de Pagos

El sistema debe proveer el servicio web de reserva de pedido al proceso batch
de validación de pagos existente en la empresa.

150
 Requerimientos No Funcionales
RNF15 Interfaz con el Servicio de Enrutamiento
El sistema debe invocar el servicio web de enrutamiento de Google Maps
Directions.
RNF16 Interfaz con el Servicio de Tracking de Unidades
El sistema debe invocar el servicio web de tracking de unidades que usa el API
de Firebase Realtime Database.
RNF17 Interfaz con el Servicio de Envío SMS
El sistema debe invocar el servicio web de envío SMS de Text local.
RNF18 Interfaz con el GPS del Smartphone
El sistema debe capturar las coordenadas GPS del smartphone.
RNF19 Interfaz con la Cámara del Smartphone
El sistema debe conectarse con la cámara del smartphone.
RNF27 Interfaz con el Sistema Web de Ventas
El sistema debe proveer los servicios web de validación de stock de productos
y consultar productos sin stock al sistema web de ventas.

5.3 Modelo de Casos de Uso del Sistema

5.3.1 Especificación de los Actores del Sistema
[Link] AS01_Temporizador
Rol que solicita al sistema generar hojas de ruta, notificar unidades requeridas al proveedor,
generar pedidos, generar cubicaciones, notificar ventanas horarias a los destinatarios y
notificar abastecimiento de productos al proveedor o bodega.

[Link] AS02_Usuario
Rol que solicita al sistema validar el acceso del usuario y cambiar contraseña. Este rol
generaliza a todos los actores del sistema.

[Link] AS03_Despachador
Rol que solicita al sistema asignar las cuadrillas a las unidades.

[Link] AS04_Pickeador
Rol que solicita al sistema actualizar los productos no ubicados en los pedidos.

151
[Link] AS05_Chofer
Rol que solicita al sistema actualizar el despacho de pedido.

[Link] AS06_Call Center

Rol que solicita al sistema actualizar la atención de pedido (reprogramación o cancelación
de pedido), además de programar la devolución de productos.

[Link] AS07_Analista de Abastecimiento

Rol que solicita al sistema generar el informe de estado de pedidos, generar el informe de
ranking de proveedores de unidades, generar el informe de productos de mayor rotación,
generar el informe de productividad de picking y el informe de abastecimiento de productos.

[Link] AS08_Monitoreador
Rol que solicita al sistema monitorear las unidades en tiempo real.

[Link] AS09_Administrador del Sistema

Rol que solicita al sistema actualizar usuarios, actualizar perfiles y administrar permisos.

[Link] AS10_Batch de Validación de Pagos

Este rol es un proceso batch externo que invoca al servicio de reserva de pedido.

[Link] AS11_Proveedor
Rol que solicita al sistema actualizar la información del proveedor, choferes y unidades
disponibles.

[Link] AS12_Servicio de Enrutamiento

Este rol es un servicio web de enrutamiento de Google Maps que se encarga de optimizar
los puntos de despacho de pedidos en base a tiempo y distancia.

[Link] AS13_Servicio de Tracking

Este rol es un servicio web de tracking que usa el API de Firebase Realtime Database que se
encarga de notificar en tiempo real las coordenadas GPS de las unidades.

[Link] AS14_Servicio de Mensajería SMS

Este rol es un servicio web de mensajería SMS de Textlocal que se encarga de conectarse
con los servidores de los proveedores móviles para el envío de mensaje de texto en los
equipos celulares o smartphones.

152
[Link] AS17_Sistema Web de Ventas
Este rol es el sistema web externo que realiza la venta de los pedidos del cliente y se encarga
de invocar el servicio de validar stock de productos y consultar productos sin stock.

5.3.2 Diagrama de Actores del Sistema

Figura 38. Diagrama de Actores del Sistema

(Elaboración propia, 2018)

5.3.3 Diagrama de Paquetes del Sistema

Figura 39. Diagrama de Paquetes del Sistema

(Elaboración propia, 2018)

153
5.3.4 Diagramas de Casos de Uso del Sistema por Paquete

Figura 40. DCUS de Planificación de Pedidos

(Elaboración propia, 2018)

Figura 41. DCUS de Atención de Pedidos

(Elaboración propia, 2018)

154
Figura 42. DCUS de Control y Monitoreo de Pedidos
(Elaboración propia, 2018)

Figura 43. DCUS de Seguridad

(Elaboración propia, 2018)

155
5.4 Atributos de los Casos de Uso del Sistema
Tabla 58.
Atributos de los Casos de Uso del Sistema
Nombre del Caso de Uso Complejidad Estado Dificultad Responsable Prioridad
CUS06_Reservar Pedido Primario Definido Alta Harry Bravo Coronel Ciclo 0
CUS07_Generar Hojas de Ruta Primario Definido Alta Harry Bravo Coronel Ciclo 0
CUS11_Notificar Ventanas Horarias Primario Definido Alta Harry Bravo Coronel Ciclo 0
CUS15_Confirmar Despacho de Pedido Primario Definido Alta Harry Bravo Coronel Ciclo 0
CUS18_Monitorear Despacho de Pedidos Primario Definido Alta Harry Bravo Coronel Ciclo 0
CUS12_Notificar Abastecimiento de Productos Primario Definido Media Harry Bravo Coronel Ciclo 0
CUS29_Cargar Productos a Bodega o Nodo Primario Definido Media Harry Bravo Coronel Ciclo 0
CUS27_Validar Stock de Productos Primario Definido Baja Harry Bravo Coronel Ciclo 1
CUS28_Consultar Productos sin Stock Primario Definido Baja Harry Bravo Coronel Ciclo 1
CUS08_Notificar Unidades Requeridas Primario Definido Media Harry Bravo Coronel Ciclo 1
CUS09_Generar Pedidos Primario Definido Media Harry Bravo Coronel Ciclo 1
CUS10_Generar Cubicación de Pedidos Primario Definido Media Harry Bravo Coronel Ciclo 1
CUS13_Asignar Cuadrillas a Hoja de Ruta Secundario Definido Baja Omar Bonarriva Tenorio Ciclo 1
CUS14_Actualizar Productos No Ubicados Secundario Definido Media Omar Bonarriva Tenorio Ciclo 1
CUS16_Actualizar Atención de Pedido Secundario Definido Alta Omar Bonarriva Tenorio Ciclo 1
CUS17_Programar Devolución de Productos Secundario Definido Alta Omar Bonarriva Tenorio Ciclo 1

156
CUS24_Actualizar Proveedor Secundario Definido Baja Omar Bonarriva Tenorio Ciclo 1
CUS25_Actualizar Choferes Secundario Definido Baja Omar Bonarriva Tenorio Ciclo 1
CUS26_Actualizar Unidades Disponibles Secundario Definido Baja Omar Bonarriva Tenorio Ciclo 1
CUS01_Actualizar Usuarios Secundario Definido Baja Omar Bonarriva Tenorio Ciclo 2
CUS02_Actualizar Perfiles Secundario Definido Baja Omar Bonarriva Tenorio Ciclo 2
CUS03_Administrar Permisos Secundario Definido Media Omar Bonarriva Tenorio Ciclo 2
CUS04_Validar Acceso al Sistema Secundario Definido Baja Harry Bravo Coronel Ciclo 2
CUS05_Cambiar Contraseña Secundario Definido Baja Harry Bravo Coronel Ciclo 2
CUS19_Generar Informe de Estado de Pedidos Opcional Definido Alta Harry Bravo Coronel Ciclo 2
CUS20_Generar Informe de Ranking de Proveedores Opcional Definido Alta Harry Bravo Coronel Ciclo 2
de Unidades
CUS21_Generar Informe de Productos de Mayor Opcional Definido Alta Harry Bravo Coronel Ciclo 2
Rotación
CUS22_Generar Informe de Productividad de Picking Opcional Definido Alta Omar Bonarriva Tenorio Ciclo 2
CUS23_Generar Informe de Abastecimiento de Opcional Definido Media Omar Bonarriva Tenorio Ciclo 2
Productos

157
5.5 Especificaciones Alto Nivel de los Casos de Uso del Sistema
Tabla 59.
Especificación de Alto Nivel de CUS01_Actualizar Usuarios
Caso de uso CUS01_Actualizar Usuarios
Actor AS09_Administrador del Sistema
Propósito El caso de uso tiene como objetivo actualizar los usuarios del
sistema.
Descripción El caso de uso comienza cuando el Administrador del
Sistema solicita al sistema actualizar los usuarios (buscar,
crear, modificar, activar y desactivar un usuario). El caso de
uso termina cuando los usuarios del sistema son
actualizados.
Requerimientos RF01_Actualizar Usuarios
Casos de uso asociados Ninguno

Tabla 60.
Especificación de Alto Nivel de CUS02_Actualizar Perfiles
Caso de uso CUS02_Actualizar Perfiles
Actor AS09_Administrador del Sistema
Propósito El caso de uso tiene como objetivo actualizar los perfiles del
sistema, asignando usuarios a estos.
Descripción El caso de uso comienza cuando el Administrador del
Sistema solicita al sistema actualizar los perfiles (buscar,
crear, modificar, activar y desactivar perfiles, así como
asignar usuarios a los perfiles). El caso de uso termina
cuando los perfiles del sistema son actualizados.
Requerimientos RF02_Actualizar Perfiles
Casos de uso asociados Ninguno

Tabla 61.
Especificación de Alto Nivel de CUS03_Administrar Permisos
Caso de uso CUS03_Administrar Permisos

158
 Actor AS09_Administrador del Sistema
Propósito El caso de uso tiene como objetivo administrar los permisos
del perfil, asignando opciones del menú a las que tendrá
acceso.
Descripción El caso de uso comienza cuando el Administrador del
Sistema solicita al sistema administrar los permisos del perfil
(asignar opciones del menú al que tendrá acceso, además de
crearlas y eliminarlas). El caso de uso termina cuando los
permisos del perfil son administrados.
Requerimientos RF03_Administrar Permisos
Casos de uso asociados Ninguno

Tabla 62.
Especificación de Alto Nivel de CUS04_Validar Acceso al Sistema
Caso de uso CUS04_Validar Acceso al Sistema
Actor AS02_Usuario
Propósito El caso de uso tiene como objetivo validar el acceso del
usuario al sistema.
Descripción El caso de uso comienza cuando el Usuario solicita al
sistema validar el acceso. El caso de uso termina cuando el
usuario valida el acceso, accediendo al sistema.
Requerimientos RF04_Validar Acceso al Sistema
Casos de uso asociados Ninguno

Tabla 63.
Especificación de Alto Nivel de CUS05_Cambiar Contraseña
Caso de uso CUS05_Cambiar Contraseña
Actor AS02_Usuario
Propósito El caso de uso tiene como objetivo cambiar la contraseña de
acceso al sistema.

159
 Descripción El caso de uso comienza cuando el Usuario solicita al
sistema cambiar la contraseña de acceso. El caso de uso
termina cuando la contraseña es cambiada.
Requerimientos RF05_Cambiar Contraseña
Casos de uso asociados Ninguno

Tabla 64.
Especificación de Alto Nivel de CUS06_Reservar Pedido
Caso de uso CUS06_Reservar Pedido
Actor AS10_Batch de Validación de Pagos
Propósito El caso de uso tiene como objetivo reservar el pedido del
cliente mediante la invocación de un servicio web.
Descripción El caso de uso comienza cuando el Batch de Validación de
Pago invoca al servicio web de reserva del pedido, el mismo
que recibirá parámetros tales como código de pedido, datos
del cliente, código de la tienda (si es retiro en tienda), fecha
de solicitud, número de reserva, fecha de venta, fecha de
despacho, dirección de despacho, datos del cliente, y la lista
detallada del pedido con los datos del código de producto,
cantidad de producto y código de bodega. El caso de uso
termina cuando el pedido del cliente es reservado.
Requerimientos RF06_Reservar Pedido
Casos de uso asociados Ninguno

Tabla 65.
Especificación de Alto Nivel de CUS07_Generar Hojas de Ruta
Caso de uso CUS07_Generar Hojas de Ruta
Actor AS01_Temporizador
AS12_Servicio de Enrutamiento
Propósito El caso de uso tiene como objetivo generar las hojas de ruta
para la entrega de pedidos, las mismas que son creadas bajo

160
 una lógica automática de optimización de rutas en tiempo y
distancia.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema generar las hojas de ruta en formato PDF, mostrando
el nombre de la bodega, el código, fecha de generación y
fecha de despacho de la hoja de ruta, además el número de
placa, número SOAT, peso y volumen máximo de carga de
la unidad, el apellido, nombre y brevete del chofer, asimismo
la lista detallada de la hoja de ruta con el campo orden de
despacho de pedidos obtenido en base a la ruta optimizada
por tiempo y distancia, el rango horario, el código de pedido,
el apellido y nombre del cliente o el nombre de la tienda, la
modalidad del pedido (entrega o recojo) y la dirección de
despacho. El caso de uso termina cuando se generan las hojas
de ruta y son almacenadas dentro del repositorio definido.
Requerimientos RF07_Generar Hojas de Ruta
Casos de uso asociados Ninguno

Tabla 66.
Especificación de Alto Nivel de CUS08_Notificar Unidades Requeridas
Caso de uso CUS08_Notificar Unidades Requeridas
Actor AS01_Temporizador
Propósito El caso de uso tiene como objetivo notificar a las empresas
proveedoras de servicio, las unidades de transporte
requeridas para la atención de pedidos por jornada laboral.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema notificar a los proveedores de servicio vía email las
unidades de transporte requeridas para la atención de los
pedidos, la misma que tiene como información la fecha de
solicitud, nombre de bodega o nodo solicitante, fecha y hora
de envío del requerimiento, y los datos básicos de las

161
 unidades. El caso de uso termina cuando se notifican las
unidades requeridas a los proveedores vía email.
Requerimientos RF08_Notificar Unidades Requeridas
Casos de uso asociados Ninguno

Tabla 67.
Especificación de Alto Nivel de CUS09_Generar Pedidos
Caso de uso CUS09_Generar Pedidos
Actor AS01_Temporizador
Propósito El caso de uso tiene como objetivo generar los pedidos
solicitados por el cliente, para su atención y despacho.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema generar los pedidos en formato PDF depositándolas
en una ruta previamente definida, mostrando información tal
como el código, fecha de solicitud y entrega, datos del
destinatario que puede ser cliente o tienda (proceso de Retiro
en Tienda), la lista detallada del pedido (código, nombre,
precio unitario, cantidad de productos, subtotal, total bruto y
total neto), esto último sólo se visualizará en caso el
destinatario sea un cliente. El caso de uso termina cuando las
órdenes de pedido son generadas y almacenadas dentro del
repositorio definido.
Requerimientos RF09_Generar Pedidos
Casos de uso asociados Ninguno

Tabla 68.
Especificación de Alto Nivel de CUS10_Generar Cubicaciones
Caso de uso CUS10_Generar Cubicación de Pedidos
Actor AS01_Temporizador
Propósito El caso de uso tiene como objetivo generar las cubicaciones
de los productos, siendo esta una actividad importante,

162
 puesto que se convierte en el mapa físico de las posiciones
de los productos dentro de la bodega o nodo.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema generar las cubicaciones de los productos en formato
PDF depositándolas en una ruta previamente definida,
mostrando información como el nombre de la bodega o
nodo y un listado de los productos con sus ubicaciones, que
comprenderán información tal como pasillo del área, lado
del pasillo, altura y profundidad, además del código y
descripción del producto. El caso de uso termina cuando las
cubicaciones son generadas y almacenadas dentro del
repositorio definido.
Requerimientos RF10_Generar Cubicaciones
Casos de uso asociados Ninguno

Tabla 69.
Especificación de Alto Nivel de CUS11_Notificar Ventanas Horarias
Caso de uso CUS11_Notificar Ventanas Horarias
Actor AS01_Temporizador
AS14_Servicio de Mensajería SMS
Propósito El caso de uso tiene como objetivo notificar las ventanas
horarias del despacho de pedidos tanto a clientes como
controllers de tienda.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema notificar las ventanas horarias al cliente o controller
de tienda, mostrando el número de verificación (código de
seguridad enviado al destinatario para el despacho de su
pedido), código de pedido, fecha de despacho y rango
horario. El caso de uso termina cuando las ventanas horarias
son notificadas al cliente mediante SMS o al controller de
tienda mediante email.
Requerimientos RF11_Notificar Ventanas Horarias

163
 Casos de uso asociados Ninguno

Tabla 70.
Especificación de Alto Nivel de CUS12_Notificar Abastecimiento de Productos
Caso de uso CUS12_Notificar Abastecimiento de Productos
Actor AS01_Temporizador
Propósito El caso de uso tiene como objetivo notificar a los
Coordinadores DAD la necesidad de abastecimiento de
productos que se hace necesario tanto en bodegas como en
nodos.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema notificar vía email la necesidad de abastecimiento de
productos, tanto en bodegas como en nodos, estas
notificaciones contienen información tal como el código,
nombre, marca, stock mínimo, stock actual, fecha máxima
de abastecimiento y estado de abastecimiento del producto.
El caso de uso termina cuando las necesidades identificadas
de abastecimiento de productos son notificadas al
Coordinador DAD.
Requerimientos RF12_Notificar Abastecimiento de Productos
Casos de uso asociados Ninguno

Tabla 71.
Especificación de Alto Nivel de CUS13_Asignar Cuadrillas a Hoja de Ruta
Caso de uso CUS13_Asignar Cuadrillas a Hoja de Ruta
Actor AS03_Despachador
Propósito El caso de uso tiene como objetivo asignar cuadrillas de 4
personas cada una, a cada hoja de ruta generada.
Descripción El caso de uso comienza cuando el Despachador solicita al
sistema asignar cuadrillas a las hojas de ruta generadas
previamente. Las cuadrillas están compuestas por un equipo
de cuatro pickeadores. Esta asignación cuenta con la

164
 información de código, nombre y total de pickeadores para
un mayor control de este proceso. El caso de uso termina
cuando las cuadrillas de pickeadores son asignadas a las
hojas de ruta.
Requerimientos RF13_Asignar Cuadrillas a Hoja de Ruta
Casos de uso asociados Ninguno

Tabla 72.
Especificación de Alto Nivel de CUS14_Actualizar Productos No Ubicados
Caso de uso CUS14_Actualizar Productos No Ubicados
Actor AS04_Pickeador
Propósito El caso de uso tiene como objetivo actualizar los productos
no encontrados por los pickeadores en el proceso de Picking,
a fin de dar aviso inmediato al cliente.
Descripción El caso de uso comienza cundo el Pickeador solicita al
sistema registrar la cantidad de productos no ubicados dentro
del proceso de Picking. Los campos por registrar en esta
actualización son bodega, código del pickeador, código del
pedido y la lista de productos no ubicados con su respectiva
cantidad. Este registro es notifica vía email al Call Center,
para que proceda a informar al destinatario, la información
con la que contará el Call Center para esta actividad es el
código de pedido, nombre, apellido y teléfono del
destinatario, así como el listado de productos no ubicados,
su descripción y las cantidades. El caso de uso termina
cuando el registro de productos no ubicados es ingresado al
sistema.
Requerimientos RF14_Registrar Productos No Ubicados
Casos de uso asociados Ninguno

165
Tabla 73.
Especificación de Alto Nivel de CUS15_Confirmar Despacho de Pedidos
Caso de uso CUS15_Confirmar Despacho de Pedidos
Actor AS05_Chofer
Propósito El caso de uso tiene como objetivo confirmar los pedidos
despachados y no despachados desde el aplicativo móvil.
Descripción El caso de uso comienza cuando el Chofer solicita al sistema
confirmar el despacho del pedido. El sistema consultará la
hoja de ruta mostrando los datos de la bodega o nodo, hoja
de ruta, unidad, chofer, datos de los pedidos a despachar con
su respectivo orden de despacho. El caso de uso finaliza
cuando se confirma los datos del pedido despachado o no
despachado en el detalle de hoja de ruta.
Requerimientos RF15_Consultar Hoja de Ruta
RF16_Registrar Despacho de Pedido
Casos de uso asociados Ninguno

Tabla 74.
Especificación de Alto Nivel de CUS16_Actualizar Atención de Pedidos
Caso de uso CUS16_Actualizar Atención de Pedidos
Actor AS06_Call Center
AS14_Servicio de Mensajería SMS
Propósito El caso de uso tiene como objetivo actualizar la atención de
los pedidos como cancelación y reprogramación desde el
Call Center.
Descripción El caso de uso comienza cuando el Call Center solicita al
sistema actualizar los pedidos como la cancelación y la
reprogramación en coordinación con el cliente. Para esto el
Call Center, consultará los pedidos del último mes (en caso
tenga más de uno) que tiene el cliente, esta búsqueda será
mediante el DNI, con lo que se obtiene la lista de los pedidos,
y en base a unas reglas de negocio se procede a reprogramar
el pedido o a cancelarlo, según sea el requerimiento. En caso

166
 se tratase de una reprogramación, esta deberá contener
información tal como fecha de reprogramación, motivo, en
caso el pedido este en ruta, se le notificará al chofer, para que
no realice la entrega. Si el caso es una cancelación, de igual
modo la información a ingresar será fecha de cancelación,
motivo y de igual forma si el pedido está en ruta, se le
notificará al chofer vía SMS, para que no realice la entrega.
Solo en caso de cancelación, el Call Center, enviará una
notificación vía email a Contabilidad para la emisión de la
Nota de Crédito por el total de los productos cancelados. El
caso de uso termina cuando la atención de los pedidos ha
sido actualizada.
Requerimientos RF17_Consultar Pedidos
RF18_Registrar Reprogramación de Pedidos
RF19_Registrar Cancelación de Pedidos
RF20_Notificar Emisión de Nota de Crédito
Casos de uso asociados CUS17_Programar Devolución de Productos (Extend)

Tabla 75.
Especificación de Alto Nivel de CUS17_Programar Devolución de Productos
Caso de uso CUS17_Programar Devolución de Productos
Actor AS06_Call Center
Propósito El caso de uso tiene como objetivo programar la devolución
de los productos, mediante un recojo o entrega directa a
tienda por parte del cliente.
Descripción El caso de uso comienza cuando el Call Center solicita al
sistema programar la devolución de productos. Para esto en
primer lugar se hará el registro en el sistema del detalle de
los productos devueltos, seleccionando el producto del
detalle del pedido e ingresando la cantidad de productos
defectuosos y una pequeña descripción del defecto. Posterior
al paso mencionado anteriormente, se procede a registrar el

167
 recojo de productos en coordinación con el cliente, debiendo
ingresar la opción de recojo o entrega a tienda del/los
productos defectuosos, fecha de devolución, nombre de la
tienda en caso se opte por la opción entrega a tienda, además
de seleccionar los productos a devolver de un pedido. El caso
de uso termina cuando la devolución de los productos ha sido
programada.
Requerimientos RF21_Registrar Productos Defectuosos
RF22_Programar Devolución de Productos
Casos de uso asociados Ninguno

Tabla 76.
Especificación de Alto Nivel de CUS18_Monitorear Despacho de Pedidos
Caso de uso CUS18_Monitorear Despacho de Pedidos
Actor AS08_Monitoreador
AS13_Servicio de Tracking
Propósito El caso de uso tiene como objetivo monitorear el despacho
de los pedidos en tiempo real a través de un dashboard que
se actualiza constantemente, mostrando el porcentaje de
atención de los pedidos por estados, y el detalle de estos.
Descripción El caso de uso comienza cuando el Monitoreador solicita al
sistema monitorear en tiempo real los pedidos que se están
despachando, para esto, el Monitoreador seleccionará la
bodega o nodo y la unidad que desea monitorear, se
visualizará el monitoreo a través de un dashboard que
mostrará el porcentaje de atención de los pedidos por
estados, tales como, pendientes, atendidos, no atendidos,
reprogramados y cancelados, asimismo se mostrará el detalle
de los pedidos categorizado por estados, y permite
determinar la ubicación actual de la unidad con respecto al
siguiente pedido a despachar mostrando la distancia y
tiempo estimada de llegada. Este monitoreo en tiempo real

168
 permite la toma de acciones en el momento oportuno,
disminuyendo el riesgo de incumplimiento de despacho a los
clientes o controllers de tienda. El caso de uso termina
cuando el Monitoreador recibe la información actualizada en
tiempo real de los estados de los pedidos despachados con
su respectivo detalle.
Requerimientos RF23_Monitorear Despacho de Pedidos
Casos de uso asociados Ninguno

Tabla 77.
Especificación de Alto Nivel de CUS19_Generar Informe de Estado de Pedidos
Caso de uso CUS19_Generar Informe de Estado de Pedidos
Actor AS07_Analista de Abastecimiento
Propósito El caso de uso tiene como objetivo generar un informe sobre
el estado de los pedidos, a fin de determinar los niveles de
servicio, e identificar las oportunidades de mejora.
Descripción El caso de uso comienza cuando el Analista de
Abastecimiento solicita al sistema generar un informe de los
estados de los pedidos en formato PDF. El mismo que
contiene la siguiente información: fecha inicial y final de la
consulta (periodo a demanda), pedidos atendidos, pedidos no
atendidos, total de pedidos entregados a tienda, total de
reprogramaciones y cancelaciones, pedidos entregados
dentro y fuera de la ventana horaria y el porcentaje de
motivos por estado del pedido (atendido, no atendido,
reprogramado y cancelado). Esto dará una amplia visión de
los niveles de atención y las oportunidades de mejora. El
caso de uso termina cuando el informe de estados de pedidos
es generado en formato PDF.
Requerimientos RF24_Generar Informe de Estado de Pedidos
Casos de uso asociados Ninguno

169
Tabla 78.
Especificación de Alto Nivel de CUS20_Generar Informe de Ranking de Proveedores de
Unidades
Caso de uso CUS20_Generar Informe de Ranking de Proveedores de
Unidades
Actor AS07_Analista de Abastecimiento
Propósito El caso de uso tiene como objetivo generar un informe de
atenciones de pedidos por parte de las empresas proveedoras
del servicio de transporte, a fin de conocer el nivel de
servicio ofrecido.
Descripción El caso de uso comienza cuando el Analista de
Abastecimiento solicita al sistema generar un informe de
ranking de proveedores de transporte en formato PDF, el
mismo que contiene la siguiente información: fecha inicial y
final de la consulta (periodo a demanda), porcentaje de
pedidos despachados por proveedor, pedidos entregados
dentro y fuera de la ventana horaria y el porcentaje de
pedidos no entregados por proveedor. Esto dará información
básica para medir los niveles de servicio ofrecido por las
empresas proveedoras del transporte. El caso de uso termina
cuando el informe de ranking de proveedores de transporte
es generado en formato PDF.
Requerimientos RF25_Generar Informe de Ranking de Proveedores de
Unidades
Casos de uso asociados Ninguno

Tabla 79.
Especificación de Alto Nivel de CUS21_Generar Informe de Productos de Mayor Rotación
Caso de uso CUS21_Generar Informe de Productos de Mayor Rotación
Actor AS07_Analista de Abastecimiento

170
 Propósito El caso de uso tiene como objetivo generar un informe de los
productos de mayor rotación para poder administrar de
manera óptima la distribución física de las cubicaciones.
Descripción El caso de uso comienza cuando el Analista de
Abastecimiento solicita al sistema generar un informe de
productos de mayor rotación en formato PDF, el que
contiene la siguiente información: fecha inicial y final de la
consulta (periodo a demanda), porcentaje de ventas de
productos clasificados por familia de productos, el
porcentaje de venta de productos por tipo de producto. Esto
permite mejorar el proceso de la distribución física de los
productos TOP de ventas. El caso de uso termina cuando el
informe de productos de mayor rotación es generado en
formato PDF.
Requerimientos RF26_Generar Informe de Productos de Mayor Rotación
Casos de uso asociados Ninguno

Tabla 80.
Especificación de Alto Nivel de CUS22_Generar Informe de Productividad de Picking
Caso de uso CUS22_Generar Informe de Productividad de Picking
Actor AS07_Analista de Abastecimiento
Propósito El caso de uso tiene como objetivo generar un informe de la
productividad del proceso de Picking, a fin de tener una
mayor visibilidad y realizar las correcciones respectivas.
Descripción El caso de uso comienza cuando el Analista de
Abastecimiento solicita al sistema generar un informe de
productividad de picking en formato PDF, el que contiene la
siguiente información: fecha inicial y final de la consulta
(periodo a demanda), nombre de bodega o nodo, cuadrilla
asignada a la hoja de ruta, cantidad de productos asignados
por cuadrilla, porcentaje de productos encontrados y no
encontrados. Esto con la finalidad de reconocer el trabajo

171
 realizado por cada equipo de trabajo e ir fortaleciendo
mediante incentivos la mejora del proceso. El caso de uso
termina cuando el informe de productividad de picking es
generado en formato PDF
Requerimientos RF28_Generar Informe de Productividad de Picking
Casos de uso asociados Ninguno

Tabla 81.
Especificación de Alto Nivel de CUS23_Generar Informe de Abastecimiento de Productos
Caso de uso CUS23_Generar Informe de Abastecimiento de Productos
Actor AS07_Analista de Abastecimiento
Propósito El caso de uso tiene como objetivo generar un informe de
abastecimiento de productos tanto para la bodega, como para
las tiendas. Para el caso del nodo se sugiere los productos a
comprar, para la tienda, los productos a reponer
Descripción El caso de uso comienza cuando el Analista de
Abastecimiento solicita al sistema seleccionando mediante
filtros la tienda o nodo y rango de fechas, generar un informe
de abastecimiento de productos en formato PDF, el que
contiene la siguiente información: fecha inicial y final de la
consulta (periodo a demanda), el tipo de abastecimiento
(reposición para tienda o nodo, compra para bodega), datos
de la bodega o tienda, lista de productos a abastecer, stock
mínimo, stock actual y cantidad de productos a abastecer,
total de productos abastecidos, y pendientes de abastecer.
Este informe se envía para que sea finalmente el responsable
el que determine la reposición o compras de productos y las
cantidades. El caso de uso termina cuando el informe de
abastecimiento de productos es generado en formato PDF y
enviado el responsable para la decisión final.
Requerimientos RF27_Generar Informe de Abastecimiento de Productos
Casos de uso asociados Ninguno

172
Tabla 82.
Especificación de Alto Nivel de CUS27_Validar Stock de Productos
Caso de uso CUS27_Validar Stock de Productos
Actor AS17_Sistema Web de Ventas
Propósito El caso de uso tiene como objetivo validar si los productos
de un pedido solicitado desde la web cuentan con stock
suficiente en alguna determinada bodega o nodo.
Descripción El caso de uso comienza cuando el Sistema Web de Ventas
solicita validar si el stock actual es suficiente para satisfacer
la solicitud de un pedido determinado, el Sistema validará
entre las bodegas y nodos el stock y solo en caso no se cuente
con el saldo suficiente, el sistema enviará el mensaje “El
producto X del pedido Y no cuenta con stock en bodegas o
nodos”, este proceso se repite por cada uno de los productos
solicitados en el pedido. En caso todos los productos
solicitados desde la web cuenten con stock suficiente. El
caso de uso termina cuando el sistema envía el mensaje “Los
productos del pedido Y cuentan con stock”.
Requerimientos RF32_ Validar Stock de Productos
Casos de uso asociados Ninguno

Tabla 83.
Especificación de Alto Nivel de CUS28_Consultar Productos sin Stock
Caso de uso CUS28_Consultar Productos sin Stock
Actor AS17_Sistema Web de Ventas
Propósito El caso de uso tiene como objetivo informar acerca de los
productos que no cuenten con stock en ninguna bodega o
nodo, para que estos sean despublicados de la web, y no se
ofrezcan como disponibles para la venta.
Descripción El caso de uso comienza cuando el Sistema Web de Ventas
a partir de la materialización de la venta disminuye el stock
actual de cada uno de los productos involucrados en el

173
 pedido. En caso el saldo actual del producto sea igual a 0
(validación en bodegas y nodos), entonces el sistema lo
reporta.
El caso de uso termina cuando el sistema genera la lista de
productos sin stock.
Requerimientos RF33_Consultar Productos sin Stock
Casos de uso asociados Ninguno

Tabla 84.
Especificación de Alto Nivel de CUS29_Cargar Productos a Bodega o Nodo
Caso de uso CUS29_Cargar Productos a Bodega o Nodo
Actor AS03_Despachador
Propósito El caso de uso tiene como objetivo mantener actualizado el
kardex de los productos que son abastecidos a las bodegas o
nodos.
Descripción El caso de uso comienza cuando el Despachador solicita al
sistema cargar productos a bodega o nodo. Luego el sistema
muestra un formulario de Abastecimiento de Productos.
Luego, el Despachador ingresa los datos del formulario y
adjunta el archivo CSV de productos a abastecer para ser
posteriormente procesados por el sistema. El caso de uso
termina cuando el sistema actualiza el kardex sumando las
cantidades cargadas al stock actual de los productos de las
bodegas o nodos mostrando el “Resumen de Carga de Datos”
y la “Lista de Errores en la Carga de Datos” en caso los
hubiera.
Requerimientos RF34_Cargar Productos a Bodega o Nodo
Casos de uso asociados Ninguno

5.6 Especificaciones Detalladas de los Casos de Uso del Núcleo Central

174
Tabla 85.
Especificación Detallada de CUS11_Notificar Ventanas Horarias
Caso de uso CUS11_Notificar Ventanas Horarias
Actor AS01_Temporizador
AS14_Servicio de Mensajería SMS
Propósito El caso de uso tiene como objetivo notificar las ventanas
horarias del despacho de pedidos tanto a clientes como
controllers de tienda.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema notificar las ventanas horarias al cliente o controller
de tienda, mostrando el número de verificación (código de
seguridad enviado al destinatario para el despacho de su
pedido), código de pedido, fecha de despacho y rango
horario. El caso de uso termina cuando las ventanas horarias
son notificadas al cliente mediante SMS o al controller de
tienda mediante email.
Requerimientos RF11_Notificar Ventanas Horarias
Casos de uso asociados Ninguno
Precondiciones Ventana Horaria
Debe estar previamente registrada la información de la
ventana horaria.
Cliente
Debe estar previamente registrada la información de los
clientes.
Tienda
Debe estar previamente registrada la información de las
tiendas.
Unidad
Debe estar previamente registrada la información de las
unidades.
Controller de Tienda
Debe estar previamente registrada la información de los
controllers de tienda.

175
 Pedido
Debe estar previamente registrada la información de los
pedidos.
Hoja de Ruta
Debe estar previamente registrada la información de las
hojas de ruta.
Detalle de Hoja de Ruta
Debe estar previamente registrada la información del detalle
de las hojas de ruta.
Postcondiciones Notificación de Ventana Horaria
Se envió una notificación de ventana horaria al cliente o
controller de tienda.
Flujo Básico
1. El caso de uso inicia cuando el temporizador solicita al sistema notificar las ventanas
horarias de entrega de pedidos a los destinatarios.
2. El sistema verifica que el pedido es despacho a domicilio notificando las ventanas
horarias mediante SMS a todos los clientes que tienen un despacho programado
[RN19] (ver Figura 45), conectándose al servicio de mensajería SMS.
3. El servicio de mensajería SMS envía el resultado de las notificaciones de la ventana
horaria.
4. El sistema registra el resultado del envío en las tablas de auditoría de procesos
automáticos.
5. El caso de uso termina.
Subflujo
No aplica.
Flujo Alterno 1: El pedido es de retiro en tienda
Si en el punto [2.] del flujo básico el sistema verifica que el pedido es de retiro, entonces
notifica las ventanas horarias mediante email a todos los controllers de tienda que tienen
un despacho programado [RN19] (ver Figura 46). Luego el caso de uso continúa en el
punto [4.] del flujo básico.
Información Adicional

176
 Figura 44. Notificación de Ventana Horaria a Cliente
(Elaboración propia, 2018)

Figura 45. Notificación de Ventana Horaria a Controller de Tienda

(Elaboración propia, 2018)

177
Tabla 86.
Especificación Detallada de CUS06_Reservar Pedido
Caso de uso CUS06_Reservar Pedido
Actor AS10_Batch de Validación de Pagos
Propósito El caso de uso tiene como objetivo reservar el pedido del
cliente mediante la invocación de un servicio web.
Descripción El caso de uso comienza cuando el Batch de Validación de
Pago invoca al servicio web de reserva del pedido, el mismo
que recibirá parámetros tales como código de pedido, datos
del cliente, código de la tienda (si es retiro en tienda), fecha
de solicitud, número de reserva, fecha de venta, fecha de
despacho, dirección de despacho, datos del cliente, y la lista
detallada del pedido con los datos del código de producto,
cantidad de producto y código de bodega. El caso de uso
termina cuando el pedido del cliente es reservado.
Requerimientos RF06_Reservar Pedido
Casos de uso asociados Ninguno
Precondiciones Distrito
Debe estar previamente registrada la información de los
distritos.
Tienda
Debe estar previamente registrada la información de las
tiendas.
Producto
Debe estar previamente registrada la información de los
productos.
Bodega
Debe estar previamente registrada la información de las
bodegas.
Kardex

178
 Debe estar previamente registrada la información del kardex
de productos.
Postcondiciones Reserva de Pedidos
Se reservó el pedido solicitado por el cliente.
Kardex
Se actualizó el kardex de productos.
Flujo Básico
1. El caso de uso comienza cuando el Batch de Validación Pagos solicita al sistema la
invocación del servicio web reservar pedido.
2. El servicio web de reservar pedido verifica que el pedido tiene número de reserva
[RN34] y registra la reserva del pedido y actualiza el kardex de los productos del
pedido de acuerdo a la bodega o nodo asignados previamente en la venta.
3. El caso de uso termina.
Subflujo
No aplica.
Flujo Alterno 1: El pedido no cuenta con la confirmación de pago
Si en el punto [2.] del flujo básico el sistema verifica que el pedido no cuenta con un
número de reserva (indicador de que el pago ha sido validado por la entidad bancaria),
entonces muestra el mensaje “El pedido no cuenta con la confirmación de pago”. Luego
el caso de uso continúa en el punto [3.] del flujo básico.
Información Adicional
No aplica.

Tabla 87.
Especificación Detallada de CUS07_Generar Hojas de Ruta
Caso de uso CUS07_Generar Hojas de Ruta
Actor AS01_Temporizador
AS12_Servicio de Enrutamiento
Propósito El caso de uso tiene como objetivo generar las hojas de ruta
para la entrega de pedidos, las mismas que son creadas bajo
una lógica automática de optimización de rutas en tiempo y
distancia.

179
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema generar las hojas de ruta en formato PDF, mostrando
el nombre de la bodega, el código, fecha de generación y
fecha de despacho de la hoja de ruta, además el número de
placa, número SOAT, peso y volumen máximo de carga de
la unidad, el apellido, nombre y brevete del chofer, asimismo
la lista detallada de la hoja de ruta con el campo orden de
despacho de pedidos obtenido en base a la ruta optimizada
por tiempo y distancia, el rango horario, el código de pedido,
el apellido y nombre del cliente o el nombre de la tienda, la
modalidad del pedido (entrega o recojo) y la dirección de
despacho. El caso de uso termina cuando se generan las
hojas de ruta y son almacenadas dentro del repositorio
definido.
Requerimientos RF07_Generar Hojas de Ruta
Casos de uso asociados Ninguno
Precondiciones Chofer
Debe estar previamente registrada la información de los
choferes.
Unidad
Debe estar previamente registrada la información de las
unidades.
Tipo de Unidad
Debe estar previamente registrada la información de los
tipos de unidades.
Bodega
Debe estar previamente registrada la información de las
bodegas o nodos.
Cliente
Debe estar previamente registrada la información de los
clientes.
Ventana Horaria

180
 Debe estar previamente registrada la información de las
ventanas horarias.
Pedido
Debe estar previamente registrada la información de los
pedidos pendientes a despachar mañana.
Detalle de Pedido
Debe estar previamente registrada la información del detalle
de los pedidos pendientes a despachar mañana.
Postcondiciones Hoja de Ruta
Se generó la hoja de ruta en formato PDF.
Flujo Básico
1. El caso de uso comienza cuando el Temporizador solicita al sistema generar las hojas
de ruta en formato PDF.
2. El sistema asigna los pedidos a la unidad correspondiente [RN02], e invoca el servicio
web de enrutamiento enviándole la dirección origen que corresponde a la dirección de
la bodega o nodo, la dirección del último destino que corresponde a la dirección del
punto de despacho más distante a la dirección origen, y finalmente las direcciones
intermedias de despacho de los pedidos.
3. El servicio web de enrutamiento recibe todas estas direcciones buscando la ruta óptima
en tiempo y distancia para el despacho de los pedidos, tomando en cuenta el tráfico
histórico promedio y el sentido de las vías retornando el orden de despacho de los
pedidos, así como el tiempo y distancia estimado entre cada punto de despacho.
4. El sistema registra el orden de despacho con el tiempo y distancia estimado entre cada
punto, además de calcular y asignar la ventana horaria a cada pedido, y registrar los
datos de la hoja de ruta [RN02], generando en disco el PDF de hojas de ruta (ver Figura
47) para cada bodega o nodo [RN04].
5. El caso de uso termina.
Subflujo
No aplica.
Flujo Alterno
No aplica.
Información Adicional

181
 Figura 46. Hoja de Ruta
(Elaboración propia, 2018)

Tabla 88.
Especificación Detallada de CUS18_Monitorear Despacho de Pedidos
Caso de uso CUS18_Monitorear Despacho de Pedidos
Actor AS08_Monitoreador
AS13_Servicio de Tracking
Propósito El caso de uso tiene como objetivo monitorear el despacho
de los pedidos en tiempo real a través de un dashboard que
se actualiza constantemente, mostrando el porcentaje de
atención de los pedidos por estados, y el detalle de estos.
Descripción El caso de uso comienza cuando el Monitoreador solicita al
sistema monitorear en tiempo real los pedidos que se están
despachando, para esto, el Monitoreador seleccionará la
bodega o nodo y la unidad que desea monitorear, se
visualizará el monitoreo a través de un dashboard que
mostrará el porcentaje de atención de los pedidos por
estados, tales como, pendientes, atendidos, no atendidos,
reprogramados y cancelados, asimismo se mostrará el detalle
de los pedidos categorizado por estados, y permite
determinar la ubicación actual de la unidad con respecto al
siguiente pedido a despachar mostrando la distancia y

182
 tiempo estimada de llegada. Este monitoreo en tiempo real
permite la toma de acciones en el momento oportuno,
disminuyendo el riesgo de incumplimiento de despacho a los
clientes o controllers de tienda. El caso de uso termina
cuando el Monitoreador recibe la información actualizada en
tiempo real de los estados de los pedidos despachados con
su respectivo detalle.
Requerimientos RF23_Monitorear Despacho de Pedidos
Casos de uso asociados Ninguno
Precondiciones Bodega
Debe estar previamente registrada la información de las
bodegas.
Unidad
Debe estar previamente registrada la información de las
unidades.
Chofer
Debe estar previamente registrada la información de los
choferes.
Pedido
Debe estar previamente registrada la información de los
pedidos.
Motivo de Pedido
Debe estar previamente registrada la información de los
motivos de pedido.
Ventana Horaria
Debe estar previamente registrada la información de las
ventanas horarias.
Hoja de Ruta
Debe estar previamente registrada la información de las
hojas de ruta para despachar hoy.
Detalle de Hoja de Ruta
Debe estar previamente registrada la información del detalle
de las hojas de ruta para despachar hoy.

183
Postcondiciones Detalle de Hoja de Ruta
Se actualizó la fecha pactada de despacho o la fecha de no
cumplimiento de despacho con su respectivo motivo, y la
latitud y longitud GPS de la ubicación del punto de
despacho.
Pedido
Se actualizó la fecha de reprogramación o cancelación de los
pedidos con su respectivo motivo.
Mapa
Se actualizó la latitud y longitud GPS en la base de datos
Firebase de Google para determinar la ubicación en tiempo
real de la unidad en el mapa.
Flujo Básico
1. El caso de uso comienza cuando el usuario selecciona del menú de opciones de la
aplicación “Monitoreo de Despacho de Pedidos”.
2. El sistema muestra un formulario de “Monitoreo de Despacho de Pedidos” con
opciones (ver Figura 48).
3. El usuario selecciona la siguiente opción:
 “Seleccionar Bodega o Nodo”, para ubicar una bodega o nodo previamente registradas
(ver subflujo Seleccionar Bodega o Nodo) y mostrará todas las unidades que se tienen
asignadas en las hojas de ruta a despachar.
4. El caso de uso termina.
Subflujo Seleccionar Bodega o Nodo
1. El usuario selecciona la bodega o nodo.
2. El sistema muestra el listado de unidades [RN12] (ver Figura 49).
3. El usuario selecciona la siguiente opción:
 “Seleccionar Unidad”, para monitorear el despacho de sus pedidos mediante un
dashboard y mostrará la información de los pedidos categorizados por estados del
pedido (ver subflujo Seleccionar Unidad).
4. El caso de uso continúa en el punto [2.] del Subflujo Seleccionar Bodega o Nodo.
Subflujo Seleccionar Unidad
1. El usuario selecciona la unidad a monitorear (ver Figura 50).

184
2. El sistema muestra el dashboard principal de todos los pedidos asignados a la bodega
o nodo y un segundo dashboard con del porcentaje por estado de pedidos y la lista de
pedidos categorizados por estado del pedido.
3. El usuario selecciona una de las siguientes opciones:
 “Ver Ubicación de Despacho de Pedido”, para visualizar la ubicación donde fue
realizado el despacho del pedido en el mapa (ver subflujo Visualizar Ubicación de
Despacho de Pedido).
 “Ver Ubicación Actual de la Unidad”, para visualizar la ubicación de la unidad en
tiempo real en el mapa con respecto al siguiente punto de despacho mostrando el
tiempo y distancia estimada de llegada (ver subflujo Visualizar Ubicación Actual de
la Unidad).
4. El caso de uso continúa en el punto [2.] del Subflujo Seleccionar Unidad.
Subflujo Visualizar Ubicación de Despacho de Pedido
1. El usuario selecciona el icono de ubicación de despacho de pedido que se encuentra
en el listado de pedidos atendidos y no atendidos (ver Figura 50).
2. El sistema muestra un popup con la ubicación del despacho realizado del pedido en el
mapa el cual debe coincidir con la dirección de despacho del pedido del cliente o tienda
(ver Figura 51), además del botón salir (ver subflujo Salir).
3. El caso de uso continúa en el punto [2.] del Subflujo Visualizar Ubicación de Despacho
de Pedido.
Subflujo Visualizar Ubicación Actual de la Unidad
1. El usuario selecciona el icono de ubicación actual de la unidad que se encuentra activo
en el siguiente pedido a despachar en el listado de pedidos pendientes (ver Figura 50).
2. El sistema invoca el servicio web de tracking.
3. El servicio web de tracking devuelve la latitud y longitud GPS de la ubicación de la
unidad al sistema.
4. El sistema muestra un popup con la ubicación en tiempo real de la unidad en el mapa
con respecto a la siguiente dirección de despacho del pedido del cliente o tienda
mostrando el tiempo y la distancia estimada de llegada (ver Figura 52), además del
botón salir (ver subflujo Salir).
5. El caso de uso continúa en el punto [4.] del Subflujo Visualizar Ubicación Actual de
la Unidad.

185
Subflujo Visualizar Ruta Completa
1. El usuario selecciona el link de ruta completa que se encuentra en el Dashboard (ver
Figura 50)
2. El sistema muestra un popup con el mapa que muestra la ruta completa y ordenada por
puntos de entrega que tiene asignada una unidad de transporte (ver Figura 54), además
del botón salir (ver subflujo Salir).
3. El caso de uso continúa en el punto [1.] del Subflujo Seleccionar Unidad.
Subflujo Salir
1. El usuario selecciona el botón salir del popup (ver Figura 51, Figura 52 y Figura 54).
2. El sistema cierra el popup.
3. El caso de uso continúa en el punto [2.] del Subflujo Seleccionar Unidad.
Flujo Alterno 1: Bodega o Nodo no tiene Unidades asignadas a Hojas de Ruta
Si en el punto [2.] del subflujo Seleccionar Bodega o Nodo el sistema determina que la
bodega o nodo no tiene unidades asignadas a hojas de ruta, entonces muestra la lista de
unidades vacía con el mensaje “No existe unidades asignadas a hojas de ruta” (ver Figura
53). Luego el caso de uso continúa en el punto [2.] del subflujo Seleccionar Bodega o
Nodo.
Flujo Alterno 2: Despacho de pedidos que están a punto de sobrepasar “n” minutos
su ventana horaria
Si en el punto [2.] del subflujo Seleccionar Unidad el sistema determina que existen
pedidos que están a punto de sobrepasar “n” minutos su ventana horaria, entonces muestra
el mensaje de alerta “En el [Nodo San Miguel], la unidad [ABC-228, RTC-234 y XYZ-
568] tienen pedidos a punto de sobrepasar la ventana horaria” [RN13], donde los valores
entre corchetes son dinámicos, además de la lista de pedidos pendientes donde se remarcan
con letra roja solo los pedidos que están a punto de sobrepasar “n” minutos su ventana
horaria, donde “n” es el tiempo en minutos y es configurable (ver Figura 55).
Información Adicional

186
Figura 47. Monitoreo de Despacho de Pedido
(Elaboración propia, 2018)

187
Figura 48. Selección de Unidad a Monitorear
(Elaboración propia, 2018)

188
Figura 49. Dashboard de Pedidos
(Elaboración propia, 2018)

189
Figura 50. Ubicación Actual de la Unidad Monitoreada
(Elaboración propia, 2018)

190
 Figura 51. Ubicación del Pedido Atendido
(Elaboración propia, 2018)

Figura 52. Validación de Unidad Monitoreada

(Elaboración propia, 2018)

191
Figura 53. Ruta Completa
(Elaboración propia, 2018)

192
Figura 54. Alerta de pedidos que están a punto de sobrepasar su ventana horaria
(Elaboración propia, 2018)

193
Tabla 89.
Especificación Detallada de CUS15_Confirmar Despacho de Pedidos
Caso de uso CUS15_Confirmar Despacho de Pedidos
Actor AS05_Chofer
Propósito El caso de uso tiene como objetivo confirmar los pedidos
despachados y no despachados desde el aplicativo móvil.
Descripción El caso de uso comienza cuando el Chofer solicita al sistema
confirmar el despacho del pedido. El sistema consultará la
hoja de ruta mostrando los datos de la bodega o nodo, hoja
de ruta, unidad, chofer, datos de los pedidos a despachar con
su respectivo orden de despacho. El caso de uso finaliza
cuando se confirma los datos del pedido despachado o no
despachado en el detalle de hoja de ruta.
Requerimientos RF15_Consultar Hoja de Ruta
RF16_Registrar Despacho de Pedido
Casos de uso asociados Ninguno
Precondiciones Hoja de Ruta
Debe existir información de hoja de ruta.
Pedido
Debe existir información de pedidos.
Producto
Debe existir información de productos.
Motivo de Pedido
Debe existir información de motivos de pedido.
Postcondiciones Detalle de Hoja de Ruta
Se actualizó el detalle de la hoja de ruta con la fecha pactada
de despacho, la longitud y latitud GPS y la foto del despacho
atendido o se actualizó la fecha de despacho no cumplido
con su respectivo motivo.
Flujo Básico

194
1. El usuario inicia el caso de uso seleccionado del menú de opciones de la aplicación
“Consultar Hoja de Ruta”.
2. El sistema muestra el prototipo de “Consulta Hoja de Ruta” con opciones (ver Figura
56).
3. El usuario selecciona la siguiente opción:
 “Consultar Pedido”, para ubicar el pedido previamente registrado (ver subflujo
Consultar Pedido).
4. El caso de uso termina.
Subflujo Consultar Pedido
1. El usuario selecciona “Consultar Pedido”.
2. El sistema muestra el prototipo de “Consulta de Pedido” con opciones (ver Figura 57).
3. El usuario selecciona una de las siguientes opciones:
 “Despachar Pedido”, para visualizar el popup de despacho del pedido (ver subflujo
Despachar Pedido).
 “Salir”, para retornar al prototipo de “Consulta Hoja de Ruta” (ver subflujo Salir).
4. El caso de uso continúa en el punto [2.] del subflujo Consultar Pedido.
Subflujo Despachar Pedido
1. El usuario selecciona “Despachar Pedido”.
2. El sistema muestra el popup de Despacho de Pedido con opciones (ver Figura 58).
3. El usuario selecciona las siguientes opciones:
 “Seleccionar Estado Atendido”, para mostrar los campos necesarios del despacho
atendido (ver subflujo Seleccionar Estado Atendido).
 “Seleccionar Estado No Atendido”, para mostrar los campos necesarios del despacho
no atendido (ver subflujo Seleccionar Estado No Atendido).
 “Grabar Despacho”, para grabar el despacho atendido o no atendido del pedido (ver
subflujo Grabar Despacho).
 “Cerrar Popup”, para cerrar popup de Despacho de Pedido (ver subflujo Salir).
4. El caso de uso continúa en el punto [2.] del subflujo Despachar Pedido.
Subflujo Seleccionar Estado de Despacho Atendido
1. El usuario selecciona el estado del despacho “Atendido”.
2. El sistema muestra las cajas de entrada de número de verificación y foto de despacho
(ver Figura 58), con su botón de tomar foto (ver subflujo Tomar Foto).

195
3. El caso de uso continúa en el punto [2.] del subflujo Seleccionar Atendido.
Subflujo Tomar Foto
1. El usuario selecciona tomar foto.
2. El sistema se conecta con la cámara del smartphone (ver Figura 60).
3. El usuario toma la foto con la cámara del smartphone.
4. El sistema adjunta la imagen de la foto en el campo foto de despacho.
5. El caso de uso continúa en el punto [2.] del subflujo Estado Atendido.
Subflujo Estado de Despacho No Atendido
1. El usuario selecciona el estado del despacho “No Atendido”.
2. El sistema muestra la lista desplegable del motivo del pedido (ver Figura 59).
3. El caso de uso continúa en el punto [2.] del subflujo Estado No Atendido.
Subflujo Grabar Despacho
1. El usuario selecciona “Grabar Despacho”.
2. El sistema solicita las coordenadas GPS del smartphone.
3. El GPS del smartphone devuelve la latitud y longitud GPS del smartphone.
4. El sistema valida que el número de verificación sea correcto, registra las coordenadas
GPS, la foto del pedido tomada con la cámara del smartphone y la fecha pactada actual
de despacho del pedido en caso del despacho atendido, o registra la fecha de no
cumplimiento de despacho, las coordenadas GPS y el motivo del pedido en caso de
despacho no cumplido.
5. El caso de uso continúa en el punto [2.] del Flujo Básico con el estado del pedido
actualizado.
Subflujo Cerrar Popup
1. El usuario selecciona “Cerrar Popup” (ver Figura 58 y Figura 59).
2. El sistema cierra el popup de Despacho de Pedido.
3. El caso de uso continúa en el punto [2.] del subflujo Consultar Pedido.
Subflujo Salir
1. El usuario selecciona “Salir”.
2. El sistema retorna al prototipo “Consultar Hoja de Ruta” (ver Figura 56).
3. El caso de uso continúa en el punto [2.] del Flujo Básico.
Flujo Alterno 1: Número de Verificación Incorrecto

196
Si en el punto [4.] del subflujo Grabar Despacho el sistema determina que el número de
verificación es incorrecto, entonces muestra el mensaje “Número de verificación
incorrecto” (ver Figura 61). Luego el caso de uso continúa en el punto [2.] del subflujo
Despachar Pedido.
Información Adicional

197
Figura 55. Hoja de Ruta Móvil
(Elaboración propia, 2018)

198
Figura 56. Detalle de Pedido
(Elaboración propia, 2018)

199
Figura 57. Atención de Pedido
(Elaboración propia, 2018)

200
Figura 58. Pedido No Atendido
(Elaboración propia, 2018)

201
Figura 59. Activación de la Cámara
(Elaboración propia, 2018)

202
 Figura 60. Número de Verificación Incorrecto
(Elaboración propia, 2018)

Tabla 90.
Especificación detallada de CUS12_Notificar Abastecimiento de Productos
Caso de uso CUS12_Notificar Abastecimiento de Productos
Actor AS01_Temporizador
Propósito El caso de uso tiene como objetivo notificar a los
Coordinadores DAD la necesidad de abastecimiento de
productos que se hace necesario tanto en bodegas como en
nodos.
Descripción El caso de uso comienza cuando el Temporizador solicita al
sistema notificar vía email la necesidad de abastecimiento de
productos, tanto en bodegas como en nodos, estas

203
 notificaciones contienen información tal como el código,
nombre, marca, stock mínimo, stock actual, fecha máxima
de abastecimiento y estado de abastecimiento del producto.
El caso de uso termina cuando las necesidades identificadas
de abastecimiento de productos son notificadas al
Coordinador DAD.
Requerimientos RF12_Notificar Abastecimiento de Productos
Casos de uso asociados Ninguno
Precondiciones Bodega
Debe estar previamente registrada la información de las
bodegas y nodos.
Producto
Debe estar previamente registrada la información de los
productos.
Kardex
Debe estar previamente registrada la información del kardex
de productos.
Postcondiciones Notificación de Abastecimiento de Productos
Se envió la notificación de productos que necesitan ser
abastecidos en las bodegas y nodos.
Flujo Básico
1. El caso de uso comienza cuando el temporizador solicita al sistema notificar vía email
la necesidad de abastecimiento de productos, tanto en bodegas como en nodos.
2. El sistema consulta los productos de bodegas y nodos, cuyo stock actual es menor al
stock mínimo de productos [RN21] [RN22].
3. El coordinador DAD de bodega o nodo recibe la notificación de abastecimiento de
productos (ver Figura 62).
4. El caso de uso termina.
Subflujo
No aplica.
Flujo Alterno 1: El producto no ha sido abastecido dentro del plazo máximo
establecido.

204
 Si en el punto [2.] del flujo básico el sistema verifica que el producto ya ha sido notificado
anteriormente para ser abastecido en cierta bodega o nodo, y superan su fecha máxima de
abastecimiento, entonces, se volverá a notificar, pero en este caso se marcará el registro
con letra roja y en la columna estado se indicará la cantidad de días sin abastecerse (ver
Figura 62). Luego el caso de uso continúa en el punto [3.] del flujo básico.
Información Adicional

Figura 61. Notificación de Abastecimiento de Productos

(Elaboración propia, 2018)

Tabla 91.
Especificación detallada de CUS29_Cargar Productos a Bodega o Nodo
Caso de uso CUS29_Cargar Productos a Bodega o Nodo
Actor AS03_Despachador
Propósito El caso de uso tiene como objetivo mantener actualizado el
kardex de los productos que son abastecidos a las bodegas o
nodos.

205
Descripción El caso de uso comienza cuando el Despachador solicita al
sistema cargar productos a bodega o nodo. Luego el sistema
muestra un formulario de Abastecimiento de Productos.
Luego, el Despachador ingresa los datos del formulario y
adjunta el archivo CSV de productos a abastecer para ser
posteriormente procesados por el sistema. El caso de uso
termina cuando el sistema actualiza el kardex sumando las
cantidades cargadas al stock actual de los productos de las
bodegas o nodos mostrando el “Resumen de Carga de Datos”
y la “Lista de Errores en la Carga de Datos” en caso los
hubiera.
Requerimientos RF34_Cargar Productos a Bodega o Nodo
Casos de uso asociados Ninguno
Precondiciones Proveedor
Debe estar previamente registrada la información del
proveedor de mercadería.
Bodega
Debe estar previamente registrada la información de las
bodegas y nodos.
Producto
Debe estar previamente registrada la información de los
productos.
Kardex
Debe estar previamente registrada la información del kardex
de productos.
Postcondiciones Abastecimiento
Se registró el abastecimiento de productos de la bodega, ó.
Reposición
Se registró la reposición de productos del nodo.
Kardex
Se actualizó el kardex de productos de la bodega o nodo.
Flujo Básico

206
1. El caso de uso comienza cuando el usuario selecciona del menú de opciones de la
aplicación “Abastecimiento de Productos”.
2. El sistema muestra un formulario de “Abastecimiento de Productos” con opciones (ver
Figura 63).
3. El usuario selecciona la siguiente opción:
 “Seleccionar Tipo de Abastecimiento”, ver subflujo Seleccionar Tipo de
Abastecimiento.
 “Seleccionar Archivo CSV”, ver subflujo Seleccionar Archivo CSV.
 “Descargar Plantilla CSV”, ver subflujo Descargar Plantilla CSV.
 “Procesar”, ver subflujo Procesar.
 “Exportar”, ver subflujo Exportar.
4. El caso de uso termina.
Subflujo Seleccionar Tipo de Abastecimiento
1. El usuario selecciona el tipo de abastecimiento “Compra”.
2. El sistema muestra la lista desplegable de proveedores de mercadería, la lista
desplegable de bodegas y la caja de texto de fecha de abastecimiento (ver Figura 64).
3. El caso de uso continúa en el punto [2.] del Flujo Básico.
Subflujo Seleccionar Archivo CSV
1. El usuario presiona el botón “Seleccionar archivo”.
2. El sistema muestra el popup para seleccionar el archivo del disco duro (ver Figura 65).
3. El usuario selecciona el archivo CSV del disco duro.
4. El sistema asigna el archivo CSV en la caja de texto de archivo CSV a cargar.
5. El caso de uso continúa en el punto [2.] del Flujo Básico.
Subflujo Descargar Plantilla CSV
1. El usuario presiona el link “Descargar Plantilla CSV”.
2. El sistema descarga la plantilla CSV a disco la cual contiene como campo el código
de producto, el nombre de producto y la cantidad de productos (ver Figura 66).
3. El caso de uso continúa en el punto [2.] del Flujo Básico.
Subflujo Procesar
1. El usuario presiona el botón “Procesar”.

207
2. El sistema registra el abastecimiento de productos y actualiza el Kardex sumando la
cantidad de productos que ingresan a la bodega [RN36] mostrando el Resumen de
Carga de Datos (ver Figura 67).
3. El caso de uso continúa en el punto [2.] del Flujo Básico.
Subflujo Exportar
1. El usuario presiona el botón “Exportar”.
2. El sistema exporta la Lista de Errores en la Carga de Datos en formato Excel (ver
Figura 68).
3. El caso de uso continúa en el punto [2.] del Flujo Básico.
Flujo Alterno 1: Tipo de Abastecimiento Reposición
Si en el punto [1.] del Subflujo Tipo de Abastecimiento, el usuario selecciona
“Reposición”, entonces el sistema muestra la lista desplegable de bodegas, la lista
desplegable de nodos y la caja de texto de fecha de reposición (ver Figura 63). Luego el
caso de uso continúa en el punto [2.] del Flujo Básico.
Flujo Alterno 2: El archivo cargado no tiene extensión CSV
Si en el punto [3.] del Subflujo Seleccionar Archivo CSV, el usuario selecciona un archivo
con un formato diferente a CSV, entonces el sistema muestra el mensaje de validación
“Debe adjuntar un archivo con formato y extensión CSV” (ver Figura 69). Luego el caso
de uso continúa en el punto [2.] del Flujo Básico.
Flujo Alterno 3: Procesar Reposición
Si en el punto [2.] del Subflujo Procesar, el sistema verifica que el tipo de abastecimiento
seleccionado es “Reposición”, entonces el sistema registra la reposición de productos y
actualiza el Kardex restando la cantidad de productos a la bodega que repone al nodo, y
sumando la cantidad de productos al nodo que se repone [RN36] mostrando el Resumen
de Carga de Datos (ver Figura 70). Luego el caso de uso continúa en el punto [2.] del Flujo
Básico.
Flujo Alterno 4: Registros con Errores en la Carga
Si en el punto [2.] del Subflujo Procesar, el sistema encontró errores en el proceso de carga
de datos del archivo CSV, entonces el sistema muestra en el Resumen de Carga de Datos
la cantidad de registros erróneos y la Lista de Errores en la Carga de Datos con su
paginación y botón de Exportar (ver Figura 71). Luego el caso de uso continúa en el punto
[2.] del Flujo Básico.

208
Información Adicional

Figura 62. Pantalla Inicial de Abastecimiento de Productos

(Elaboración propia, 2018)

Figura 63. Tipo de Abastecimiento Compra

(Elaboración propia, 2018)

209
Figura 64. Popup de Carga de Archivo CSV
(Elaboración propia, 2018)

Figura 65. Plantilla CSV

(Elaboración propia, 2018)

210
 Figura 66. Proceso Satisfactorio de Compra
(Elaboración propia, 2018)

Figura 67. Excel de Lista de Errores en la Carga de Datos

(Elaboración propia, 2018)

211
 Figura 68. Validación de Archivo CSV
(Elaboración propia, 2018)

Figura 69. Proceso Satisfactorio de Reposición

(Elaboración propia, 2018)

212
Figura 70. Lista de Errores en la Carga de Datos
(Elaboración propia, 2018)

213
5.7 Modelo Conceptual
5.7.1 Diagrama del Modelo Conceptual

Figura 71. Modelo Conceptual

(Elaboración propia, 2018)

214
5.7.2 Diccionario del Modelo Conceptual
[Link] ES01_Proveedor
Entidad que contiene los datos del proveedor.

Tabla 92.
Atributos de ES01_Proveedor
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoProveedor Código del proveedor String N/A Privado
razonSocial Razón social del proveedor String N/A Privado
numeroRUC Número de RUC del proveedor String N/A Privado
telefonoProveedor Teléfono del proveedor String N/A Privado
emailProveedor Email del proveedor String N/A Privado
tipoProveedor Tipo de proveedor (UNID: Proveedor de unidades, MERC: String N/A Privado
Proveedor de mercadería)

[Link] ES02_Unidad
Entidad que contiene los datos de la unidad de transporte.

Tabla 93.
Atributos de ES02_Unidad
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
numeroPlaca Número de Placa de la unidad String N/A Privado

215
 modeloUnidad Modelo de la unidad String N/A Privado
marcaUnidad Marca de la unidad String N/A Privado
numeroSOAT Número SOAT de la unidad String N/A Privado
flagActivUnidad Flag de activación de unidad Boolean true Privado

[Link] ES03_Chofer
Entidad que contiene los datos del chofer.

Tabla 94.
Atributos de ES03_Chofer
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
numeroBrevete Número de brevete del chofer String N/A Privado
nombreChofer Nombre del chofer String N/A Privado
apellidoChofer Apellido del chofer String N/A Privado
telefonoChofer Teléfono del chofer String N/A Privado
emailChofer Email del chofer String N/A Privado
flagActivChofer Flag de activación de chofer Boolean true Privado

[Link] ES04_Cuadrilla
Entidad que contiene los datos de la cuadrilla.

216
Tabla 95.
Atributos de ES04_Cuadrilla
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoCuadrilla Código de cuadrilla String N/A Privado
nombreCuadrilla Nombre de cuadrilla String N/A Privado
fechaIniAsignación Fecha inicio de asignación Date N/A Privado
fechaFinAsignación Fecha fin de asignación Date N/A Privado
totalPickeadores Total de pickeadores Integer N/A Privado

[Link] ES05_Pickeador
Entidad que contiene los datos del pickeador.

Tabla 96.
Atributos de ES05_Pickeador
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoPickeador Código de pickeador String N/A Privado
nombrePickeador Nombre del pickeador String N/A Privado
apellidoPickeador Apellido del pickeador String N/A Privado
fechaNacimiento Fecha de nacimiento del pickeador Date N/A Privado
fechaIngreso Fecha de ingreso del pickeador Date N/A Privado

217
[Link] ES06_TipoProducto
Entidad que contiene los datos del tipo de producto.

Tabla 97.
Atributos de ES06_TipoProducto
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoTipoProducto Código de tipo de producto String N/A Privado
nombreTipoProducto Nombre de tipo de producto String N/A Privado

[Link] ES07_FamiliaProducto
Entidad que contiene los datos de la familia de producto.

Tabla 98.
Atributos de ES07_FamiliaProducto
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoFamiliaProducto Código de familia de producto String N/A Privado
nombreFamiliaProducto Nombre de familia de producto String N/A Privado

[Link] ES08_Producto
Entidad que contiene los datos del producto.

218
Tabla 99.
Atributos de ES08_Producto
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoProducto Código de producto String N/A Privado
nombreProducto Nombre de producto String N/A Privado
marcaProducto Marca de producto String N/A Privado
precioUnitario Precio unitario de producto en soles Double N/A Privado
volumenProducto Volumen de producto en metros cúbicos Double N/A Privado
pesoProducto Peso de producto en kilos Double N/A Privado

[Link] ES09_Bodega
Entidad que contiene los datos de la bodega o nodo.

Tabla 100.
Atributos de ES09_Bodega
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoBodega Código de bodega String N/A Privado
nombreBodega Nombre de bodega String N/A Privado
tipoBodega Tipo de bodega (BOD: Bodega, NOD: Nodo) String N/A Privado
direccionBodega Dirección de bodega String N/A Privado
emailBodega Email de bodega String N/A Privado

219
[Link] ES10_Zona
Entidad que contiene los datos de la zona.

Tabla 101.
Atributos de ES10_Zona
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoZona Código de zona String N/A Privado
nombreZona Nombre de zona String N/A Privado

[Link] ES11_Cliente
Entidad que contiene los datos del cliente.

Tabla 102.
Atributos de ES11_Cliente

Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad

codigoCliente Código de cliente String N/A Privado
nombreCliente Nombre del cliente String N/A Privado
apellidoCliente Apellido del cliente String N/A Privado
numeroDNI Número de DNI del cliente String N/A Privado
telefonoCliente Teléfono del cliente String N/A Privado
emailCliente Email del cliente String N/A Privado
direccionCliente Dirección del cliente String N/A Privado

220
[Link] ES12_Tienda
Entidad que contiene los datos de la tienda.

Tabla 103.
Atributos de ES12_Tienda
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoTienda Código de la tienda String N/A Privado
nombreTienda Nombre de la tienda String N/A Privado
direccionTienda Dirección de la tienda String N/A Privado

[Link] ES13_ControllerTienda
Entidad que contiene los datos del controller de tienda.

Tabla 104.
Atributos de ES13_ControllerTienda
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoControllerTienda Código del controller de tienda String N/A Privado
nombreControllerTienda Nombre del controller de tienda String N/A Privado
apellidoControllerTienda Apellido del controller de tienda String N/A Privado
telefonoControllerTienda Teléfono del controller de tienda String N/A Privado

221
 emailControllerTienda Email del controller de tienda String N/A Privado

[Link] ES14_Distrito
Entidad que contiene los datos del distrito.

Tabla 105.
Atributos de ES14_Distrito
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoDistrito Código del distrito String N/A Privado
nombreDistrito Nombre del distrito String N/A Privado

[Link] ES15_MotivoPedido
Entidad que contiene los datos de los motivos de pedido para una reprogramación, cancelación, y pedido no despachado al cliente.

Tabla 106.
Atributos de ES15_MotivoPedido
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoMotivo Código de motivo de pedido String N/A Privado
descripcionMotivo Descripción de motivo de pedido String N/A Privado
categoriaMotivo Categoría de motivo de pedido (REP: Reprogramación, CAN: String N/A Privado
Cancelación, NAT: No Atendido)

222
[Link] ES16_VentanaHoraria
Entidad que contiene los datos del rango horario de despacho de los pedidos.

Tabla 107.
Atributos de ES16_VentanaHoraria
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoVentHoraria Código de ventana horaria String N/A Privado
horaInicio Hora inicio en formato HH:mm:ss String N/A Privado
horaFin Hora fin en formato HH:mm:ss String N/A Privado
tipoVentHoraria Tipo de ventana horaria (LOC: Local, PROV: Provincial) String N/A Privado
flagActivVentHoraria Flag de activación de ventana horaria Boolean N/A Privado

[Link] ES17_Pedido
Entidad que contiene los datos del pedido.

Tabla 108.
Atributos de ES17_Pedido
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoPedido Código de pedido String N/A Privado
fechaSolicitud Fecha de solicitud de pedido Datetime N/A Privado
numeroReserva Número de reserva de pedido que es el equivalente al número Integer N/A Privado
de operación bancaria del pago realizado

223
 fechaVentaPedido Fecha de venta del pedido Datetime N/A Privado
numeroVerificacion Número de verificación de confirmación de despacho Integer N/A Privado
fechaDespacho Fecha de despacho de pedido Date N/A Privado
direccionDespacho Dirección de despacho de pedido String N/A Privado
fechaRetiroEnTienda Fecha de retiro en tienda del pedido Date N/A Privado
fechaRecojoEnTienda Fecha de recojo en tienda del pedido Datetime N/A Privado
fechaReprogramacion Fecha de reprogramación de pedido Date N/A Privado
fechaCancelacion Fecha de cancelación de pedido Datetime N/A Privado
fechaDevolucion Fecha de devolución de productos del pedido Date N/A Privado
totalBruto Total bruto del pedido (Sin IGV) Double N/A Privado
totalNeto Total neto del pedido (Con IGV) Double N/A Privado

[Link] ES18_DetallePedido
Entidad que contiene los datos del detalle del pedido.

Tabla 109.
Atributos de ES18_DetallePedido
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
cantidadProducto Cantidad de producto Integer N/A Privado
subtotalProducto Subtotal de producto Double N/A Privado
cantProductDefectuosos Cantidad de productos defectuosos Integer N/A Privado

224
 obsProductDefectuosos Observación de productos defectuosos String N/A Privado
cantProductNoUbicados Cantidad de productos no ubicados Integer N/A Privado

[Link] ES19_HojaRuta
Entidad que contiene los datos de la hoja de ruta.

Tabla 110.
Atributos de ES19_HojaRuta
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoHojaRuta Código de hoja de ruta String N/A Privado
fechaGenHojaRuta Fecha de generación de hoja de ruta Datetime today() Privado
fechaDespHojaRuta Fecha de despacho de hoja de ruta Date N/A Privado

[Link] ES20_Kardex
Entidad que contiene los datos del kardex relacionado con el stock de los productos en la bodega.

Tabla 111.
Atributos de ES20_Kardex
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
stockMinimo Stock mínimo de producto Integer N/A Privado
stockActual Stock actual de producto Integer N/A Privado

225
 fechaActualRegistro Fecha actual de registro Datetime N/A Privado
fechaNotificacionAbast Fecha de notificación de abastecimiento de productos Date N/A Privado
fechaMaximaAbast Fecha máxima de abastecimiento de productos Date N/A Privado

[Link] ES21_CubicacionPedido
Entidad que contiene los datos de la ubicación de los productos del pedido en la bodega o nodo.

Tabla 112.
Atributos de ES21_CubicacionPedido
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
Área Área de la bodega String N/A Privado
Pasillo Pasillo de la bodega String N/A Privado
Lado Lado del pasillo String N/A Privado
Altura Altura del lado String N/A Privado
Profundidad Profundidad de la altura String N/A Privado

[Link] ES22_Provincia
Entidad que contiene los datos de la provincia.

226
Tabla 113.
Atributos de ES22_Provincia
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoProvincia Código de provincia String N/A Privado
nombreProvincia Nombre de provincia String N/A Privado

[Link] ES23_Departamento
Entidad que contiene los datos del departamento.

Tabla 114.
Atributos de ES23_Departamento
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoDepartamento Código de departamento String N/A Privado
nombreDepartamento Nombre de departamento String N/A Privado

[Link] ES24_DetalleHojaRuta
Entidad que contiene los datos del detalle de hoja de ruta.

Tabla 115.
Atributos de ES24_DetalleHojaRuta
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
ordenDespacho Orden de despacho de pedido Integer N/A Privado

227
 tiempoPromDespacho Tiempo promedio de despacho de pedido en minutos Integer N/A Privado
fechaEstimPartida Fecha estimada de partida Datetime N/A Privado
tiempoEstimLlegada Tiempo estimado de llegada en minutos Integer N/A Privado
fechaEstimLlegada Fecha estimada de llegada Datetime N/A Privado
distanciaEstimada Distancia estimada en metros Integer N/A Privado
fechaPactadaDespacho Fecha pactada de despacho de pedido Datetime N/A Privado
fechaNoCumplDespacho Fecha de no cumplimiento de despacho de pedido Datetime N/A Privado
latitudGpsDespacho Latitud GPS de despacho Double N/A Privado
longitudGpsDespacho Longitud GPS de despacho Double N/A Privado
fotoDespachoPedido Foto de despacho de pedido Byte N/A Privado
flagEnvioVentHoraria Flag de envío de ventana horaria Boolean false Privado

[Link] ES25_TipoUnidad
Entidad que contiene los datos del tipo de unidad.

Tabla 116.
Atributos de ES25_TipoUnidad
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
codigoTipoUnidad Código de tipo de unidad String N/A Privado
nombreTipoUnidad Nombre de tipo de unidad String N/A Privado
pesoMaxCarga Peso máximo de carga de la unidad Double N/A Privado

228
 volumenMaxCarga Volumen máximo de carga de la unidad Double N/A Privado

[Link] ES26_UnidadChofer
Entidad que contiene los datos de la asignación de la unidad con el chofer.

Tabla 117.
Atributos de ES26_UnidadChofer
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
fechaAsignacion Fecha de asignación de unidad con chofer Datetime N/A Privado

[Link] ES27_Abastecimiento
Entidad que contiene los datos del abastecimiento de productos que el proveedor realiza a la bodega.

Tabla 118.
Atributos de ES27_Abastecimiento
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
fechaAbastecimiento Fecha en que fue realizado el abastecimiento de productos Date N/A Privado
cantidadProducto Cantidad de productos abastecidos por el proveedor Integer N/A Privado
fechaRegistro Fecha y hora en que fue realizado el registro Datetime N/A Privado

229
[Link] ES28_Reposicion
Entidad que contiene los datos de la reposición de productos que la bodega realiza al nodo.

Tabla 119.
Atributos de ES28_Reposicion
Nombre del Atributo Descripción Tipo de Dato Valor Inicial Visibilidad
fechaReposicion Fecha en que fue realizado la reposición de productos Date N/A Privado
cantidadProducto Cantidad de productos que la bodega repone al nodo Integer N/A Privado
fechaRegistro Fecha y hora en que fue realizado el registro Datetime N/A Privado

230
5.8 Conclusiones
 Los casos de uso del sistema seleccionados como ciclo 0 en el presente proyecto son
aquellos que incorporan complejidad, tecnología innovadora y que son diferenciadores
con respecto a otras soluciones especificadas en el análisis comparativo de las
soluciones.

 Los requerimientos funcionales principales que son diferenciadores de otras soluciones

que se incluye en el presente proyecto son los que manejan el control de stocks como
reservar pedido.

 Los requerimientos funcionales principales que incorporan complejidad y tecnología

innovadora son aquellos relacionados con el manejo de la ruta óptima para realizar el
orden de atención de los despachos de los pedidos, el monitoreo de los despachos de los
pedidos en tiempo real y el cálculo de la ventana horaria reducida para ser enviada a los
clientes por SMS.

 Finalmente, la importancia del prototipo es que brinda los detalles del sistema
permitiendo al usuario detectar tempranamente si es en realidad lo que necesita en el
sistema, evitando de esta forma realizar modificaciones sobre un sistema ya instalado.

231
6 CAPÍTULO 5: ARQUITECTURA DE SOFTWARE
6.1 Introducción
Se desarrolla el presente capítulo con la finalidad de poder diagramar los casos de uso más
significativos para la arquitectura de software, que permite ver la manera de cómo construir
el software.

Se desarrolla respecto a los requerimientos no funcionales tres temas asociados. En primer

lugar, las metas de la arquitectura de software, las restricciones de la arquitectura de
software, los mecanismos arquitecturales y por último las tácticas de arquitectura que
trazarán el camino para poder lograr las metas.

Los requerimientos no funcionales son seleccionados y ordenados de acuerdo al impacto en

la implementación de la solución.

Finalmente, el desarrollo de las vistas a nivel de arquitectura, vista lógica de la arquitectura

de software, vista de implementación de la arquitectura de software, vista de implementación
de la arquitectura de software.

6.2 Diagrama de los Casos de Uso más significativos para la Arquitectura del
Software
A continuación, se muestra en la siguiente figura los casos de uso más significativos de la
arquitectura del software, el cual corresponde con los casos de uso del ciclo 0 indicados en
el subcapítulo de atributos de los casos de uso del sistema considerados como los casos de
uso del núcleo central.

232
 Figura 72. Diagrama de CUS del Núcleo Central
(Elaboración propia, 2018)

6.3 Metas de la Arquitectura de Software

Tabla 120.
Metas de la Arquitectura de Software
Requerimiento No Funcional Meta
[RNF03] - Disponibilidad del El sistema debe estar disponible 24x7 (24 horas diarias,
Sistema 7 días a la semana) al 90%.

233
 [RNF06] - Promedio de El sistema debe de soportar un promedio de 100
Transacciones por Minuto transacciones por minuto de base de datos.
[RNF07] - Concurrencia de El sistema debe soportar una concurrencia de 100
Usuarios usuarios.
[RNF08] - Tiempo Promedio El tiempo promedio de respuesta del sistema debe ser
de Respuesta del Sistema de 3 segundos.
[RNF09] - Navegadores El cliente web del sistema debe soportar el navegador
Soportados Chrome versión 66.0 o superior.
[RNF20] - Manejo de Errores Los mensajes de error deben ser reportados por la
propia aplicación en la medida de las posibilidades y no
por el Sistema Operativo. Los mensajes del sistema
deben estar en el idioma español.
[RNF21] - Confidencialidad de El sistema deberá almacenar las contraseñas de usuario
Contraseñas de Usuario encriptadas en la base de datos.
[RNF28] - Confidencialidad de El sistema deberá proteger los datos almacenados en
Datos almacenados en Firebase Firebase Realtime Database contra el acceso no
Realtime Database autorizado.
[RNF29] - Protección de
El sistema deberá proteger los servicios REST del
Acceso a Recursos en Servicios
acceso no autorizado a los recursos.
REST
[RNF23] - Formato de Los reportes del sistema deben ser exportados en
Exportación de Reporte formato PDF.

6.4 Restricciones de la Arquitectura de Software

Tabla 121.
Restricciones de la Arquitectura de Software
Requerimiento No Funcional Restricciones
[RNF22] - Sistema Operativo El sistema móvil debe soportar el sistema operativo
Móvil Soportado Android 7.0 Nougat o superior.
[RNF24] - Lenguaje de El Sistema debe estar desarrollado en el lenguaje de
Programación programación JAVA versión 8.0.

234
 [RNF25] - Base de Datos El Sistema debe estar desarrollado en la Base de Datos
MySql 5.7.

6.5 Mecanismos Arquitecturales

Tabla 122.
Mecanismos Arquitecturales
RNF Mecanismo Solución
 Clustering Redundante, en el que los
servidores se clasifican en primarios y
secundarios, las mismas que realizan las
tareas de manera redundante. Si un servidor
falla el otro servidor continúa con el trabajo
sin interrupción. Las sesiones de trabajo
[RNF03] Sistemas Redundantes
atendidas por el servidor caído continúan su
actividad sin interrupción. Tiempo de
recuperación de 0 a 3 segundos.
 Generadores Eléctricos.
 Disponibilidad de al menos dos proveedores
de Internet.
 Manejador de transacciones. El Monitor de
Ejecución Distribuida, consiste en dos
módulos, el administrador de transacciones
(AT) y el despachador (D). El AT es el
responsable de coordinar la ejecución en la
[RNF06] Manejo de Transacciones base de datos de las operaciones que realiza
una aplicación, el D, es el responsable de
implementar el algoritmo específico de
control de concurrencias (Round-Robin)
para sincronizar los accesos a la base de
datos.
 Balanceador, usando el algoritmo Round-
[RNF07] Manejo de Concurrencia
Robín, algoritmo de planificación de

235
 procesos de simple implementación.
Asignando a cada proceso una porción de
tiempo equitativa y ordenada, teniendo
todos los procesos la misma prioridad, la
lista de procesos se clasifica por FIFO
(primero en entrar, primero en salir).
 Imágenes Ligeras en las pantallas menores a
500 k (SW).
 Optimización de Querys y medirlos con plan
[RNF08] Tiempo de Respuesta de ejecución (SW).
 Ancho de Banda (HW).
 Disco Duro (HW).
 Memoria RAM (HW).
 Implementación de Bootstrap en la
aplicación web (librería para construir
[RNF09] Navegador Web aplicaciones responsivas usando HTML5,
CSS3, JS, la cual es soportada por la versión
de Chrome 66.0)
 Manejo de control de errores mediante el
TRY CATCH que permite capturar el error
causado por una excepción en la lógica de
[RNF20] Manejo de Errores programación o por la caída en la ejecución
de un Store Procedure en Base de Datos,
además de registrar los errores en un log,
usando la librería de Log4j.
 Creación de una clase que permita realizar el
Confidencialidad de hashing de la contraseña usando el algoritmo
[RNF21]
Contraseña BCRYPT que se encuentra implementado en
Spring Security.
 Configuración de reglas de seguridad en la
Confidencialidad de
[RNF28] consola de Firebase que permita otorgar a
Datos almacenados en
los usuarios autenticados el acceso de lectura

236
 Firebase Realtime y/o escritura sobre los datos almacenados en
Database la base de datos de Firebase.
 Implementación de la seguridad de los
Protección de Acceso a
servicios REST con el framework Spring
[RNF29] Recursos en Servicios
Security, oauth 2.0 para la autorización y
REST
OpenID Connect para la autenticación.
 Uso del Framework IONIC para construir
aplicaciones móviles híbridas usando
Sistemas Operativos
[RNF22] tecnología web JS, CSS, HTML5, SASS, las
Soportados
cuales se puede empaquetar como una
aplicación nativa APK de Android.
 Uso de la librería JasperReports para la
generación y exportación de reportes a PDF,
[RNF23] Emisión de Reportes
además de la herramienta IReport para
diseñar reportes.

6.6 Tácticas de Arquitectura

Tabla 123.
Tácticas de Arquitectura
Atributo de
Táctica Solución
Calidad
Redundancia Activa:
 Clustering Redundante, en el que los
servidores se clasifican en primarios y
secundarios, las mismas que realizan las
tareas de manera redundante. Si un
Disponibilidad Recuperación de Fallas servidor falla el otro servidor continúa
con el trabajo sin interrupción. Las
sesiones de trabajo atendidas por el
servidor caído continúan su actividad sin
interrupción. Tiempo de recuperación de
0 a 3 segundos.

237
  Generadores Eléctricos.
 Disponibilidad de al menos dos
proveedores de Internet.
 Manejo de Transacciones: El Monitor
de Ejecución Distribuida, consiste en dos
módulos, el administrador de
transacciones (AT) y el despachador (D).
El AT es el responsable de coordinar la
Rendimiento Gestión de Recursos ejecución en la base de datos de las
operaciones que realiza una aplicación, el
D, es el responsable de implementar el
algoritmo específico de control de
concurrencias (Round-Robin) para
sincronizar los accesos a la base de datos.
 Manejo de Concurrencia: Balanceador,
usando el algoritmo Round-Robin,
algoritmo de planificación de procesos de
simple implementación. Asignando a
Rendimiento Gestión de Recursos cada proceso una porción de tiempo
equitativa y ordenada, teniendo todos los
procesos la misma prioridad, la lista de
procesos se clasifica por FIFO (primero
en entrar, primero en salir).
Tiempo de Respuesta:
 Imágenes Ligeras en las pantallas
menores a 500 k (SW).
 Optimización de Querys y medirlos con
Rendimiento Demanda de Recursos
plan de ejecución (SW).
 Ancho de Banda (HW).
 Disco Duro (HW).
 Memoria RAM (HW).

238
  Manejo de Excepciones: Manejo de
control de errores mediante el TRY
CATCH que permite capturar el error
causado por una excepción en la lógica de
Disponibilidad Detección de Fallas
programación o por la caída en la
ejecución de un Store Procedure en Base
de Datos, además de registrar los errores
en un log, usando la librería de Log4j.
 Confidencialidad de Contraseña:
Creación de una clase que permita
realizar el hashing de la contraseña
Seguridad Resistencia de Ataques
usando el algoritmo BCRYPT que se
encuentra implementado en Spring
Security.
 Confidencialidad de Datos
almacenados en Firebase Realtime
Database: Configuración de reglas de
seguridad en la consola de Firebase que
Seguridad Resistencia de Ataques
permita otorgar a los usuarios
autenticados el acceso de lectura y/o
escritura sobre los datos almacenados en
la base de datos de Firebase.
 Protección de Acceso a Recursos en
Servicios REST: Implementación de la
seguridad de los servicios REST con el
Seguridad Resistencia de Ataques
framework Spring Security, oauth 2.0
para la autorización y OpenID Connect
para la autenticación.

6.7 Vista Lógica de la Arquitectura de Software

A continuación, se muestra en la figura los subsistemas del Sistema de Gestión de Despacho
de Pedidos:

239
 <Sistema>
Software de Gestión
de Despacho de
Pedidos

<Web> <Web Service> <Móvil>

Aplicación web para la Aplicación para Aplicación móvil para
planificación, exponer los servicios el registro del
monitoreo y control de web que consumirá el despacho de pedidos
los pedidos sistema batch de en el domicilio del
validación de pagos, cliente o en la tienda
el sistema web de
ventas y la aplicación
móvil.

Figura 73. Susbsistemas del Sistema de Gestión de Despacho de Pedidos

(Elaboración propia, 2018)

A continuación, se muestran en las siguientes figuras la vista lógica de cada uno de los
subsistemas mencionados:

240
Figura 74. Vista Lógica del Sistema Web
(Elaboración propia, 2018)

241
Figura 75. Vista Lógica del Web Service
(Elaboración propia, 2018)

242
 Figura 76. Vista Lógica del Sistema Móvil
(Elaboración propia, 2018)

En base a la vista lógica de cada subsistema, se describe cada una de las siguientes capas:

6.7.1 Capa de Presentación

Esta capa está compuesta por las interfaces de usuario que corresponde a la vista de la
aplicación, además del controlador web que se encarga de manejar las peticiones, delegar el
procesamiento de negocio y dirigirse a la vista apropiada.

6.7.2 Capa de Tareas Programadas

Esta capa está compuesta por las clases Jobs que se ejecutarán de manera automática en un
tiempo establecido.

243
6.7.3 Capa del Servicio
Esta capa está compuesta por las clases del servicio web y sus mensajes del servicio (clases
request y response) las cuales exponen su interfaz con la finalidad que otros sistemas puedan
comunicarse, tal como, el Sistema Batch de Validación de Pagos y el Sistema Móvil de
Despacho de Pedidos.

6.7.4 Capa de Negocio

Esta capa está compuesta por las clases que implementan la lógica de negocio y hacen uso
de las entidades de negocio.

6.7.5 Capa de Datos

Esta capa está compuesta por las clases de Acceso a Datos que implementan la lógica de
invocación de los procedimientos almacenados de la base de datos, además de las clases de
Servicios Externos encargadas de invocar los servicios de Google Maps Directions, Firebase
Realtime Database y el Textlocal SMS.

244
6.8 Vista de Implementación de la Arquitectura de Software
A continuación, se muestran en las siguientes figuras la vista de implementación de cada uno de los casos de uso más importantes pertenecientes
a la aplicación web, web services y aplicación móvil con su respectiva leyenda que indica las capas que pertenecen cada uno de los componentes
de la aplicación. Asimismo, se muestran la dependencia entre los componentes de la aplicación y los componentes externos que se detallarán en
el siguiente subcapítulo.

Figura 77. Vista de Implementación del CUS18_Monitorear Despacho de Pedidos

(Elaboración propia, 2018)

245
Figura 78. Vista de Implementación del CUS06_Reservar Pedido
(Elaboración propia, 2018)

246
Figura 79. Vista de Implementación del CUS15_Confirmar Despacho de Pedido
(Elaboración propia, 2018)

247
6.9 Vista de Despliegue de la Arquitectura de Software
A continuación, se muestra en la siguiente figura la vista de despliegue de la arquitectura de software, donde se representa los elementos de hardware (nodos), la ruta de comunicación entre ellos, y los artefactos de
software y componentes alojados en dichos nodos.

Figura 80. Vista de Despliegue de la Arquitectura de Software

(Elaboración propia, 2018)

248
En base a la figura anterior, se explica cada uno de sus elementos:

6.9.1 Servidor Lenovo System x3550 M4

En este servidor se encuentra instalado el motor de base de datos MySQL 5.7 donde se
aloja la base de datos de Gestión de Despacho de Pedidos “BD_GESATEPED.dbf”.

6.9.2 Servidor Lenovo System x3650 M5 (Servidor de Aplicaciones Web)

En este servidor se encuentra instalado el servidor de aplicaciones Glassfish 5.0 donde se
despliega la aplicación web “[Link]”. Este nodo se conecta con los servicios
de Google Cloud, el servicio de Textlocal Cloud, el servidor de base de datos, el servidor
NAS y el servidor de correo. Entre los artefactos jars desplegados en este nodo se
mencionan los siguientes:

 JasperReports: Es una librería de código abierto para la creación de informes capaz

de utilizar datos de diferentes fuentes y producir documentos que se exporten a
formatos HTML, PDF, XLS, CSV, RTF y XML.

 Quartz: Es un framework de scheduling de código abierto que provee funcionalidad

para ejecutar procesos en Java de manera automática en un tiempo determinado.

 Spring: Es un framework de Java de código abierto que permite crear aplicaciones

escalables de forma sencilla, con menos líneas de código, además de permitir la
integración con otros frameworks y librerías. También tiene como módulo el Spring
Security para el manejo de la seguridad del sistema. Este framework es usado en todas
las capas del sistema.

 JCIFS: Es una librería de código abierto en Java que permite conectarse a un servidor
de archivos compartidos para leer o almacenar archivos usando el protocolo SMB.

 Java Mail API: Es una librería de código abierto en Java que permite el envío de
correos electrónicos.

 Log4j: Es una librería de códigdegrao abierto en Java que permite escribir mensajes
en un archivo log, cuyo propósito es dejar constancia de una determinada transacción
en tiempo de ejecución.

6.9.3 Servidor Lenovo System x3650 M5 (Servidor de Servicios)

En este servidor se encuentra instalado el servidor de aplicaciones Glassfish 5.0 donde se
despliega el web services “[Link]”. Este nodo se conecta con los servicios
de Google Cloud (específicamente el servicio Firebase Realtime Database), servidor de
base de datos y servidor de correo. Entre los artefactos jars desplegados en este nodo se
mencionan los siguientes:

 JAX-RS: Es un API de Java que proporciona soporte para la creación de servicios

web REST.

 Mybatis: Es un framework de persistencia de código abierto que se encarga de

mapear sentencias SQL y procedimientos almacenados con objetos JavaBeans a partir
de ficheros XML o anotaciones.

 MySQL Conector Java: Es una librería de código abierto que proporciona el driver
JDBC para conectarse al motor de Base de Datos de MySQL.

6.9.4 Google Cloud

Es el conjunto de servicios que provee Google en la nube. Entre los servicios que la
aplicación invoca son:

 Google Maps Services: Es un servicio que proporciona las funcionalidades de las

APIs de Google Maps. La aplicación usa la funcionalidad de mapa y de direcciones
para el cálculo de las rutas óptimas, además de la distancia y tiempo aproximado de
llegada a un punto determinado.

 Firebase Realtime Database: Es una base de datos NoSQL alojada en la nube. Los
datos se almacenan en formato JSON y se sincronizan en tiempo real con cada cliente
conectado. Esta base de datos es consultada constantemente en tiempo real por la
aplicación web para obtener los datos del GPS de la unidad que fueron previamente
registrados por el aplicativo móvil.

6.9.5 Textlocal Cloud

Es el conjunto de servicios que provee Textlocal en la nube. Entre los servicios que la
aplicación invoca son:

 Txtlocal SMS Services: Es un servicio que proporciona las funcionalidades de

mensajería SMS. La aplicación usa el envío de mensajes SMS.

250
6.9.6 PC-Interna
Representa las PCs que se usan dentro del entorno de la empresa Retail y tiene instalado
el navegador web Chrome donde se ejecuta la aplicación web desplegada en el Servidor
de Aplicaciones Web.

6.9.7 Smartphone
Representa el equipo móvil con Sistema Operativo Android 7.0 Nougat o superior donde
se encuentra instalada la aplicación móvil [Link]. Esta aplicación móvil
consume los servicios REST desplegados en el Servidor de Aplicaciones de Glassfish,
además de consumir el servicio de Firebase Realtime Database para grabar los datos de
la placa de la unidad y el GPS del smartphone constantemente en tiempo real.
Adicionalmente, la aplicación móvil se conectará con la cámara para tomar la foto del
pedido despachado.

6.9.8 Servidor NAS - Netgear RN31441E

Es un servidor de almacenamiento conectado a la red que permite compartir archivos a
otras computadoras en la red. En este servidor se almacenarán en un directorio los
archivos PDF generados por la aplicación web, para que puedan ser impresos por el
despachador.

6.9.9 Balanceador de Carga

Es el dispositivo de hardware encargado de distribuir las solicitudes de los usuarios de la
aplicación web y móvil entre los servidores de aplicaciones con la finalidad de evitar la
saturación del servidor, mejorar el desempeño del servicio y minimizar los tiempos de
respuesta.

6.9.10 Servidor Lenovo ThinkServer TS150

En este servidor se encuentra instalado el servidor de correo Microsoft Exchange Server
2016 donde la aplicación web se conectará al servidor de correo para el envío de mensajes
de correo electrónico.

6.10 Conclusiones
 En el diseño de la arquitectura del presente proyecto se ha propuesto crear un
subsistema de servicios web, el cual será consumido por el sistema móvil de despacho
de pedidos y por los sistemas externos como el sistema batch de validación de pagos
y el sistema web de ventas.

251
 En el diseño de la arquitectura del presente proyecto se descartó el uso de un sistema
web mobile, debido a que la aplicación móvil va a hacer uso de componentes nativos
como la cámara y el GPS del smartphone, el cual es una limitación en los sistemas
web mobile.

 Para que el sistema móvil use los componentes nativos del smartphone se tiene dos
alternativas, una de ellas es desarrollar en Android para aplicaciones móviles nativas
y la otra es el desarrollo con Ionic Framework para aplicaciones móviles híbridas, por
lo que se optó por Ionic Framework debido a que permite desarrollar con lenguajes
de programación web como HTML5, CSS3 y JS, además de generar a partir de dicho
código fuente un ejecutable para Android, iOS, entre otros.

 Finalmente, para minimizar los tiempos de respuesta, mejorar el desempeño del

servicio y evitar la saturación del servidor de aplicaciones, se plantea usar el
balanceador de carga en el servidor de aplicaciones web y en el servidor de servicios.

252
7 CAPÍTULO 6: CALIDAD Y PRUEBAS DEL SOFTWARE
7.1 Introducción
El presente capítulo se desarrolla con la finalidad de poder definir el plan de la calidad del
software. Para esto se desarrollan los siguientes puntos, en primer lugar, las políticas de la
calidad, adicionalmente se desarrollan los objetivos de la calidad, que deben de ser aplicados
en la organización objetivo. Otros de los puntos a desarrollar es el detalle de la
normatividad(s) que se aplica al proyecto, son finalmente las normas en las que se soportó
el desarrollo del software.

Otro punto a desarrollar es la elección de las métricas de calidad de software que se

desarrollan para la medición de los CUS seleccionados, así como un análisis e interpretación
de los resultados obtenidos de estas mediciones.

Finalmente, se detalla el plan de pruebas, así como los casos de prueba, los mismos que
contemplan los escenarios más significativos de las especificaciones de los CUS.

7.2 Plan de la Calidad del Software

7.2.1 Política de Calidad
La organización objetivo, al menos en su operación en Perú, no cuenta con una política de
calidad orientada al desarrollo de software. Estas políticas son suplidas por un comité de
evaluación que revisa, analiza y califica cada iniciativa solicitada por el cliente interno. En
base a la experiencia de los miembros de esta área de calidad, así como la evaluación del
impacto en el negocio, es que estas iniciativas llegan a convertirse en un proyecto, o en una
propuesta rechazada.

Es por este motivo que se propone una política de calidad de software, que se alinea a la
misión y valores corporativos de la organización objetivo. Esta propuesta tiene como
objetivo poder ver la aplicabilidad de estas políticas al software.

 Cumplimento de la legislación nacional vigente aplicable, así como los compromisos

que adopten voluntariamente.

 Mantener una filosofía de creatividad e innovación, y estar constantemente trabajando

en la mejora continua, para una mejor adaptación a un sector que está en constante
evolución tecnológica.

253
 Trabajar siempre bajo un marco de gestión de calidad para que permita alinear la forma
de trabajo respecto a la calidad de nuestro producto software, estableciendo así, metas y
objetivos que contribuyan a una mejora constante, así como colaborando en la asignación
de recursos humanos y económicos para el logro de los objetivos.

 Implicar a los trabajadores a través de la comunicación de la política de calidad y su

entendimiento, fomentando la participación, involucramiento, el sentido y
responsabilidad de cumplir esta política y sus procedimientos según aplique a cada
puesto de trabajo.

 Revisar de manera periódica el sistema de gestión, con la finalidad de poder determinar

su eficiencia y mejora continua.

 Mantener una buena relación con nuestros proveedores, transportistas y colaboradores.

7.2.2 Objetivos de Calidad

Los objetivos de calidad tienen ciertos requisitos, y deben de ser:

 Adecuados.

 Exigentes.

 Cuantificables.

 Comprensibles.

 Medibles.

Es muy importante poder recalcar que los objetivos no tienen que estar definidos en su
totalidad en el mismo período de tiempo, esto va a depender mucho de los recursos y
disponibilidad de los mismos. Una buena práctica es realizar un monitoreo de manera
trimestral de los objetivos definidos, y de los que quedan por definir.

Por ello, se citan algunos objetivos propuestos para el desarrollo de este capítulo:

 Mejorar el nivel de satisfacción del cliente, disminuir el 11% de insatisfacción que

presenta la compañía en este momento.

254
 Reducción del número de NO conformidades del Sistema propuesto, o proceso
involucrado en un máximo de 4 semanas (tiempo establecido de acuerdo con el lead time
de los desarrollos).

 Desarrollar las oportunidades de mejora, teniendo como objetivo la integración de

inteligencia sistémica en cada propuesta.

 Mejorar el ambiente de trabajo, lo cual finalmente contribuirá en la mejora del

compromiso y motivación de los trabajadores.

 Reducir el número de NO conformidades asociadas a los proveedores (productos,

transporte y servicios).

7.2.3 Normatividad Aplicable

Se propone para una gestión de calidad de software la normativa ISO 25000:2005.

[Link] ISO 25000:2005

Esta norma conocida como SQuaRE (System and Software Quality Requirements and
Evaluation) familia de normas cuyo principal objetivo es la creación de un marco de trabajo
común con la finalidad de poder evaluar la calidad de un producto final como un software.
Esta norma es la evolución de la 9126 entre otras. Describe todas las particularidades, así
como el proceso de evaluación de productos software.

[Link] ISO/IEC 2502n: Medición de Calidad

Para este capítulo y para la elaboración de las métricas se utilizó la ISO 2502n, toda vez que
es la división de medición de la calidad de la norma ISO 25000. Esta norma permite el uso
de un modelo de referencia para la medición de la calidad del producto de software, así como
definiciones de medidas de calidad, tanto las medidas internas como externas y en uso, así
como guías prácticas para su debida aplicación. Esta división mencionada se encuentra
conformada por:

 ISO/IEC 25020: Modelo de referencia para la medida con guía. Esta ISO, presenta los
elementos de medición de la calidad, adicionalmente proporciona una guía para
seleccionar, desarrollar y aplicar medidas propuestas por la ISO.

 ISO/IEC 25021: Elementos de medición de calidad. Define y especifica métricas base

y derivadas que podrían ser usadas a lo largo de toda la vida del desarrollo software.

255
 ISO/IEC 25022: Medición de la calidad en uso. Define específicamente un conjunto de
métricas para poder realizar la medición de la calidad en uso del producto software.

 ISO/IEC 25023: Medición de la calidad de la calidad de software como producto. Define

un específicamente un conjunto de métricas para poder realizar la medición de la calidad
de productos y sistema software.

 ISO/IEC 25024: Medición de la calidad de los datos. Define específicamente un

conjunto de métricas para poder realizar la medición de la calidad de datos con los que
finalmente trabajará el sistema propuesto.

[Link] ISO/IEC 25010

Esta norma se determinan las características de la calidad que se van a tomar en cuenta a la
hora de evaluar las propiedades de un producto de software determinado.

En este contexto, la calidad se puede interpretar como el grado en que dicho producto
satisface los requisitos definidos por el usuario, aportando un valor a la organización. Son
estos requisitos (funcionalidad, rendimiento, seguridad, mantenibilidad), los que representan
el modelo de calidad (ISO 25000, 2018).

[Link] IEEE std 830-1998

En la presente propuesta, se determina que la correcta definición de los requerimientos se
convierte en una actividad fundamental, por lo que, para la propuesta presentada, los
requerimientos han sido establecidos conforme a los principios planteados en la normativa
IEEE std 830-1998. Todo requerimiento bien definido deberá ser: Correcto, Completo,
Consistente, No ambiguo, Clasificado por importancia y/o estabilidad, Verificable,
Modificable y tener Trazabilidad ([Link], 2018).

256
7.2.4 Métricas de Calidad del Software
A continuación, se detallan las métricas de calidad de software, las que se han seleccionado en base a las características más importantes del software.

Tabla 124.
Métricas de Calidad de Software
Fase del ciclo de
Propósito de la
Característica Subcaracterística Métrica vida de calidad Métrica de aplicación Fórmula Valor deseado Tipo de medida Recursos utilizados
métrica de calidad
del producto
Adecuación Corrección Exactitud Interna/Externa ¿Cuál es el Cálculo de la X = 1 – A 0 <= X <= 1 X = Contable / Contable Especificación de
funcional funcional de datos porcentaje de probabilidad de que los X = Probabilidad de que El más cercano a 1 = Contable. requerimientos,
exactitud de los datos sean correctos los datos sean correctos. 1 es el mejor. A = Contable. código fuente,
datos? cuando se ejecuta un A = Probabilidad de que desarrollador y
cálculo. haya un error en los datos. tester.
Eficiencia en Comportamiento Tiempo Interna/Externa ¿Cuál es el tiempo Tomar la media del X = A / B 0 <= X <= 1 X = Tiempo / Tiempo Especificación de
desempeño del tiempo de estimado de tiempo desde que se A = Media del tiempo de El más cercano a A = Tiempo. requerimientos,
respuesta respuesta a una envía a petición hasta respuesta al envió a 0 es el mejor. B = Tiempo. código fuente,
petición? obtener la respuesta petición. desarrollador y
sobre el tiempo de B = Tiempo de respuesta tester.
respuesta especificado. especificado.
Eficiencia en Comportamiento Tiempo Interna/Externa ¿Cuál es el tiempo Sumatoria de los X = A / B 0 <= X <= 1 X = Tiempo / Contable Especificación de
desempeño del tiempo de espera desde que se inicia un tiempos que dura A = Sumatoria de tiempos El más cercano a A = Tiempo. requerimientos,
trabajo, hasta que lo completar un trabajo que dura completar un 0 es el mejor. B = Contable. código fuente,
completa? sobre la cantidad de trabajo. desarrollador y
mediciones. B = Número de tester.
mediciones.
Facilidad de Operatividad Claridad Interna/Externa ¿Qué cantidad de Contar el número de X = A / B 0 <= X <= 1 X = Contable / Contable Especificación de
Uso del mensajes son auto mensajes A = Número de mensajes El más cercano a A = Contable. requerimientos,
mensaje explicativo? implementados con implementados con 1 es el mejor. B = Contable. código fuente,
explicaciones claras y el explicaciones claras. desarrollador y
número total de B = Número total de tester.
mensajes mensajes implementados.
implementados. Donde:
B>0
Tabla 125.
Aplicación de métrica de calidad METR_1 Exactitud de datos
ISO 25010
Característica Subcaracterística Categoría Indicador Código
Adecuación funcional Corrección funcional Métrica Interna/Externa METR_1
Descripción de la métrica Responsable Unidad de medida Fuente de Información
Especificaciones de requerimiento.
Exactitud de datos Omar Bonarriva Tenorio Unidades (%) Monitoreo de aplicación en el momento que se ejecuta una petición
(Dashboard).
Objetivo Frecuencia de medición Meta
Obtener el porcentaje de exactitud de los datos. A demanda, después de un cambio en el sistema. 100%
Forma de cálculo ISO 25010 Tipo de medida
X=1-A X = Contable / Contable
Validación.
X = Probabilidad de que los datos sean correctos. 1 = Contable
Revisión conjunta.
A = Probabilidad de que haya un error en los datos. A = Contable
Fecha de prueba Interpretación SLA (Service Level Agreement)
0 <= X <= 1 No Aceptable: X < 1
25/08/2018
El más cercano a 1 es el mejor. Aceptable: X = 1
Errores obtenidos en las
pruebas de exactitud de
Casos de uso de sistema datos (actualizaciones Errores en los datos (a) Constante (1) Resultado (x) Análisis
dashboard)
1 2 3 4 5
Según definición, se establece
CUS07_Generar Hojas de Ruta 0 0 1 0 0 0.2 1 0.8 que un resultado menor al 80% es considerado
cómo No Aceptable.
Sin error en la data resultante, se considera
CUS18-Monitorear Despacho de Pedidos 0 0 0 0 0 0 1 1
que el resultado es Aceptable.

258
Tabla 126.
Aplicación de métrica de calidad METR_2 Tiempo de Respuesta
ISO 2502n
Característica Subcaracterística Categoría Indicador Código
Eficiencia en desempeño Comportamiento del tiempo Métrica Interna/Externa METR_2
Descripción de la métrica Responsable Unidad de medida Fuente de Información

Especificación de requerimiento.
Tiempo de respuesta Omar Bonarriva Tenorio Segundos
Monitoreo de aplicación en el momento que se ejecuta una petición.

Objetivo Frecuencia de medición Meta

Obtener el tiempo estimado de respuesta a una petición. A demanda, después de un cambio en el sistema. 3 segundos
Forma de cálculo ISO 2502n Tipo de medida
X=A/B X = Tiempo / Tiempo
Validación.
A = Media del tiempo de respuesta al envió a petición. A = Tiempo
Revisión conjunta.
B = Tiempo de respuesta especificado B = Tiempo
Fecha de prueba Interpretación SLA (Service Level Agreement)
0 <= X <= 0.6 No Aceptable: 0.6 < X
25/08/2018
El más cercano a 0 es el mejor. Aceptable: 0 < X < = 0.6
Tiempo de respuesta a una Media del tiempo de
Tiempo de respuesta
Casos de uso de sistema petición al software respuesta al envió a Resultado (x) Análisis
especificado (b)
1 2 3 4 5 petición (a)
Según las reglas establecidas, el resultado
CUS07_Generar Hojas de Ruta 4.12 3.52 3.98 3.76 4.02 3.88 6.00 0.647 tiene una respuesta resultante como
No Aceptable.

CUS18-Monitorear Despacho de Pedidos 2.02 1.98 2.14 2.21 2.01 2.07 6.00 0.345 Aceptable.

Tabla 127.
Aplicación de métrica de calidad METR_3 Tiempo de Espera
ISO 2502n
Característica Subcaracterística Categoría Indicador Código
Eficiencia en desempeño Comportamiento del tiempo Métrica Interna/Externa METR_3
Descripción de la métrica Responsable Unidad de medida Fuente de Información

259
 Especificación de requerimientos.
Monitoreo de los usuarios al realizar tareas en la aplicación.

Tiempo de Espera del CUS07_Generar Hojas de Ruta

Tareas Prueba1 Prueba2 Prueba3 Prueba4 Prueba5
Solicitud de
Generación de Hoja de 1.02 0.95 0.87 0.99 1.04
Ruta
Asignación de Pedidos
a Unidades 2.21 2.12 2.45 2.73 2.07
Disponibles
Generación de Ruta
2.87 2.76 2.90 2.37 2.77
Óptima
Generación de PDF en
0.98 1.21 0.89 1.01 1.14
Disco Duro
Tiempo de espera Omar Bonarriva Tenorio Minutos Sumatoria de tiempos
35.35
(A)
Número de
20
mediciones (B)
Resultado (X) 1.77

Tiempos de Espera de CUS18_Monitorear Despacho de Pedidos

Tareas Prueba1 Prueba2 Prueba3 Prueba4 Prueba5
Seleccionar Bodega o
1.01 1.12 0.98 0.93 1.03
Nodo
Seleccionar Unidades
1.11 1.17 1.03 1 1.01
a Monitorear
Actualizar Estados de
1.54 1.61 1.48 1.55 1.51
Pedidos
Sumatoria de tiempos 18.08
(A)

260
 Número de 15
mediciones (B)
Resultado (X) 1.21

Objetivo Frecuencia de medición Meta

Obtener el tiempo promedio que un usuario puede completar un trabajo A demanda, después de un cambio en el sistema. 5 segundos
Forma de cálculo ISO 2502n Tipo de medida
X=A/B X = Tiempo / Contable
Validación.
A = Sumatoria de tiempos que dura completar un trabajo. A = Tiempo
Revisión conjunta.
B = Número de mediciones B = Contable
Fecha de prueba Interpretación SLA (Service Level Agreement)
Baja: X <= 2 SLA\Complejidad Baja Media Alta
En trabajos de complejidad baja, un valor menor igual a 2 es considerado como
aceptable, un valor mayor a este es considerado como no aceptable. Aceptable X <= 2 X <= 4 X <= 6
Media: X <= 4
25/08/2018 En trabajos de complejidad media, un valor menor igual a 4 es considerado como
aceptable, un valor mayor a este es considerado como no aceptable.
Alta: X <= 6 No Aceptable X>2 X>4 X>6
En trabajos de complejidad alta, un valor menor igual a 6 es considerado como
aceptable, un valor mayor a este es considerado como no aceptable.
Sumatoria de tiempos que dura Número de
Casos de uso de sistema Complejidad Resultado (x) Análisis
completar un trabajo (a) mediciones (b)

CUS07_Generar Hojas de Ruta Alta 35.35 20 1.77 Aceptable

CUS18-Monitorear Despacho de Pedidos Media 18.08 15 1.21 Aceptable

Tabla 128.
Aplicación de métrica de calidad METR_4 Claridad del Mensaje
ISO 2502n
Característica Subcaracterística Categoría Indicador Código

261
Facilidad de Uso Operatividad Métrica Interna/Externa METR_4
Descripción de la métrica Responsable Unidad de medida Fuente de Información
Especificación de requerimientos.
Diseño de interfaces del sistema.

Mensajes de CUS07_Generar Hojas de Ruta Prueba

No existen pedidos para despachar mañana. OK
Las hojas de rutas se construirán para los pedidos OK
a despachar mañana.
Ya se generaron las hojas de ruta, para descargar, OK
por favor elija una bodega.
Número de mensajes implementados con 3
explicaciones claras (A)
Número total de mensajes implementados (B) 3
Resultado (X) 1.00

Mensajes de CUS18_Monitorear Despacho Prueba

Claridad del mensaje Omar Bonarriva Tenorio Unidades
de Pedidos
No existen pedidos para despachar hoy. OK
Esta bodega no tiene pedidos para ser OK
despachados hoy.
En Nodo San Miguel, la unidad A5F-746 tiene OK
pedidos a puntos de sobrepasar la ventana
horaria.
En Bodega Lurín, las unidades A3N-877, A4S- OK
923 y RIH-166 tienen pedidos a puntos de
sobrepasar la ventana horaria.
Lista de unidades activas para el 25/05/2019, por OK
favor seleccione la unidad a monitorear.
No se encontraron pedidos no atendidos. NO OK
No se encontraron pedidos reprogramados. OK
No se encontraron pedidos atendidos. OK

262
 No se encontraron pedidos cancelados. OK
Número de mensajes implementados con 8
explicaciones claras (A)
Número total de mensajes implementados (B) 9
Resultado (X) 0.88

Objetivo Frecuencia de medición Meta

Obtener la proporción entre el número de mensajes implementados con explicaciones claras versus el total de mensajes
implementados por caso de uso.
A demanda, después de un cambio en el sistema. 1
(Mensaje Claro: Debe ser fácilmente entendible, no palabras complicadas o tecnicismos. Deberá ser concreto con el
uso de pocas palabras.)
Forma de cálculo ISO 2502n Tipo de medida
X=A/B
X = Contable / Contable
A = Número de mensajes implementados con explicaciones claras. Validación.
A = Contable
B = Número total de mensajes implementados. Revisión conjunta.
B = Contable
Dónde: B > 0
Fecha de prueba Interpretación SLA (Service Level Agreement)
0 <= X <= 1 X < 0.90 No Aceptable
25/08/2018
El más cercano a 1 es el mejor. X >= 0.90 Aceptable
Número de mensajes
Número total de mensajes
Casos de uso de sistema implementados con explicaciones Resultado (x) Análisis
implementados (b)
claras (a)

CUS07_Generar Hojas de Ruta 3 3 1.00 Aceptable

CUS18-Monitorear Despacho de Pedidos 8 9 0.88 No Aceptable

263
7.2.5 Análisis de Resultados de la Medición
Una vez que se ha aplicado las métricas respectivas a los casos de uso que forman parte
de la prueba de concepto, se hace un análisis de interpretación de los resultados obtenidos,
a fin de poder determinar si es correcta la métrica utilizada, hay que hacer correcciones
en el proceso de medición, e identificar oportunidades de mejora para el software
propuesto.

[Link] METR_1 Exactitud de Datos

En este gráfico de barras queda evidenciado el resultado de la métrica que se aplicó a los
dos CUS que corresponden a la prueba de concepto, en los que se puede apreciar que sólo
en el CUS18_Monitorear Despacho de Pedidos cumple con el criterio de aceptación
definido previamente. Si el resultado es menor a 1 o 100%, el criterio de evaluación es
no aceptable.

Se recomienda poder evaluar el impacto sobre el proceso de un resultado no aceptable,

toda vez que dependiendo de la criticidad del proceso, los datos y la exactitud de los
mismos se pueden volver un factor vital.

Exactitud de Datos
1.2

1
1

0.8
0.8

0.6

0.4

0.2
0.2

0
0
Promedio de Errores RESULTADO

CUS07_Generar Hojas de Ruta CUS18_Monitorear Despacho de Pedidos

Figura 81. Métrica de Calidad de Exactitud de Datos

(Elaboración propia, 2018)
[Link] METR_2 Tiempo de Respuesta
En este gráfico de barras, se demuestra los tiempos de respuesta que tiene cada uno de los
CUS correspondientes a la prueba de concepto, sólo el CUS18_Monitorear Despacho de
Pedidos cumple con el criterio de aceptable, toda vez que la medida es menor a 0.6
definido previamente como tiempo óptimo de respuesta.

Se recomienda evaluar constantemente si los valores definidos dentro del rango de

aceptación se ajustan a las necesidades del negocio. Este tema, es muy dinámico en un
mundo donde el tiempo en las atenciones de las necesidades es un factor altamente
diferencial.

Tiempo de Respuesta
0.7 0.647

0.6

0.5

0.4
0.345

0.3

0.2

0.1

0
Tiempo de Respuesta

CUS07_Generar Hojas de Ruta CUS18_Monitorear Despacho de Pedidos

Figura 82. Métrica de Calidad de Tiempo de Respuesta

(Elaboración propia, 2018)

[Link] METR_3 Tiempo de Espera

En este gráfico elaborado según la complejidad, se puede apreciar el promedio de tiempo
en el que un usuario completaría un trabajo. En este caso para el CUS18_Monitoreo de
Despacho de Pedidos, cumple con la condición de aceptable definidos en las métricas,
según su complejidad (Media) si el valor es menor igual a 4, el resultado es aceptable.
También se puede visualizar que para el CUS07_Generar Hojas de Ruta, según su
complejidad (Alta), el valor aceptable es menor igual a 6, para esta medición el valor se
encuentra dentro de la escala de aceptabilidad.

265
Algo adicional que se puede visualizar y es casi lógico, es que el CUS con mayor
complejidad cuenta con un tiempo mayor respecto al tiempo del CUS de menor
complejidad.

Se recomienda estar evaluando de manera constante si los valores definidos como

aceptables se ajustan a las necesidades del negocio.

Tiempo de Espera

Media 1.21
CUS18_Monitorear Despacho de Pedidos

Alta 1.77
CUS07_Generar Hojas de Ruta

0 0.5 1 1.5 2

Tiempo en minutos

Figura 83. Métrica de Calidad de Tiempo de Espera

(Elaboración propia, 2018)

[Link] METR_4 Claridad del Mensaje

En este gráfico elaborado, se puede apreciar la comparativa entre los mensajes claros del
software de los dos CUS del ciclo de pruebas respecto al total de mensajes. Asimismo, se
puede visualizar que solo uno de los casos cumple con el 100%, es el caso del
CUS07_Genera Hoja de Ruta, por tener un valor de conversión de 1.0, es considerado
como aceptable. Por el contrario, el CUS18_Monitorear Despacho de Pedidos, al tener
un valor de conversión de 0.88, el valor es no aceptable. Para este último caso, se corrigió
el mensaje, con la finalidad de tener un mejor resultado.

Recomendación para esta medición es involucrar a la mayor cantidad de personas

estratégicas del negocio que puedan dar aportes desde diferentes enfoques.

266
 Claridad del Mensaje

9
8
9
8
7
6
5
3 3
4
3
2
1
0
CUS07_Generar Hojas de Ruta CUS18_Monitorear Despacho de
Pedidos

Mensajes Claros Total de Mensajes

Figura 84. Métrica de Calidad de Claridad del Mensaje

(Elaboración propia, 2018)

7.3 Pruebas del software

7.3.1 Plan de Pruebas
[Link] Propósito del Plan
El presente plan de pruebas tiene como propósito organizar los recursos y las actividades
necesarias para la ejecución de la estrategia de pruebas a fin de asegurar la calidad del
sistema.

[Link] Objetivo
El presente plan de pruebas tiene como objetivo la certificación de las funcionalidades de
los casos de uso del sistema de la prueba de concepto del "Sistema de Información de
Gestión de Despacho de Pedidos para Empresas Retail".

Adicionalmente, se ejecutarán las pruebas que aseguren que el sistema cumple con los
requerimientos especificados previamente.

[Link] Roles y Responsabilidades del Equipo de Pruebas

Tabla 129.
Roles y Responsabilidades del Equipo de Pruebas

Cargo Recurso Responsabilidades Específicas

267
 Líder de Omar  Gestionar la implementación del sistema de gestión de
Calidad Bonarriva calidad.
 Controlar periódicamente el funcionamiento del sistema
de gestión de calidad.
 Proveer los recursos necesarios para la implementación,
difusión y mantenimiento del sistema de gestión de
calidad.
Analista de Harry  Elaborar la documentación del plan de pruebas.
Calidad Bravo  Elaborar la documentación detallada de los casos de
prueba.
 Estimar el esfuerzo de la ejecución de las pruebas.
Ejecutor de Harry  Ejecutar las pruebas del sistema en base a los casos de
Pruebas Bravo prueba especificados.
 Registrar la evidencia de las pruebas del sistema.
 Detectar, documentar y enviar al desarrollador los
defectos encontrados durante las pruebas del sistema.
Gestor de Harry  Ejecutar los scripts de Base de Datos de la aplicación en
Ambiente Bravo el ambiente de pruebas.
de Calidad  Desplegar la aplicación en el servidor de aplicaciones
del ambiente de pruebas.
 Administrar los datos de prueba.

[Link] Pruebas de Certificación

[Link].1 Prerrequisitos
Los requisitos necesarios para la ejecución de las pruebas del sistema son:

 La especificación de los casos de uso del sistema.

 La documentación de análisis y diseño del sistema.

 La especificación detallada de los casos de prueba.

 El Sistema de Gestión de Despacho de Pedidos instalado en el ambiente de pruebas.

 El acceso habilitado al sistema del equipo de pruebas.

268
[Link].2 Alcances
El alcance de las pruebas abarca el correcto funcionamiento de los dos casos de uso de la
prueba del concepto del sistema de Gestión de Despacho de Pedidos, los cuales son el
CUS07_Generar Hojas de Ruta y el CUS18_Monitorear Despacho de Pedidos.

[Link].3 Estrategia de Pruebas

La ejecución de las pruebas del sistema se realizará de manera manual siguiendo los flujos
especificados en los casos de prueba. Adicionalmente, se registrará en Word la evidencia
de los resultados de la prueba, así como los defectos encontrados en cada escenario de
pruebas. Finalmente, para gestionar la atención de los defectos se utilizará la herramienta
Mantis Bug Tracker.

269
[Link].4 Casos de Pruebas
A continuación, se muestra el listado de escenarios de los casos de uso de la prueba de concepto:

Tabla 130.
Lista de Escenarios del CUS07_Generar Hojas de Ruta
N° Descripción del Escenario Resultado Esperado Responsable de Prueba Fecha de Prueba
1 Generar hoja de ruta de pedidos de Muestra el PDF de la hoja de ruta con los pedidos Harry Bravo Coronel. 25/08/2018
despacho a domicilio con el orden de de despacho a domicilio optimizados con el API de
despacho optimizado. Google Maps Directions.
2 Generar hoja de ruta de pedidos de retiro Muestra el PDF de la hoja de ruta con los pedidos Harry Bravo Coronel. 25/08/2018
en tienda con el orden de despacho de retiro en tienda optimizados con el API de
optimizado. Google Maps Directions.

Tabla 131.
Lista de Escenarios del CUS18_Monitorear Despacho de Pedidos
N° Descripción del Escenario Resultado Esperado Responsable de Prueba Fecha de Prueba
1 Consultar ruta completa de los Muestra el popup de ruta completa de los Harry Bravo Coronel. 25/08/2018
despachos de pedidos a domicilio de una despachos de los pedidos a domicilio de una
unidad. unidad donde se visualiza cada pedido marcado en
el mapa con su orden de despacho, además de la
ruta trazada y el orden de despacho de los pedidos
 con distancia y tiempo estimado entre punto y
punto.
2 Consultar ruta completa de los Muestra el popup de ruta completa de los Harry Bravo Coronel. 25/08/2018
despachos de los pedidos de retiro en despachos de los pedidos de retiro en tienda de una
tienda de una unidad. unidad donde se visualiza cada pedido marcado en
el mapa con su orden de despacho y la ruta trazada
del despacho de los pedidos con distancia y tiempo
estimado entre punto y punto.
3 Simular el tracking de la unidad Muestra el popup de la ubicación de la unidad Harry Bravo Coronel. 25/08/2018
moviéndose a través de la ruta para donde se visualiza la unidad moviéndose a través
llegar al punto destino de despacho. de la ruta modificando su tiempo y distancia
restante para llegar al punto destino y comprobar
cómo se actualiza las coordenadas en el Firebase
Realtime Database.
4 Actualizar en tiempo real los dashboards Muestra la pantalla de monitoreo de despacho de Harry Bravo Coronel. 25/08/2018
y las tablas de pedidos por estado en la pedidos con las tablas de pedidos por estado, y el
pantalla de monitoreo de despacho de dashboard de la bodega y de la unidad actualizada.
pedidos.

271
5 Alertar cuando un pedido pendiente está Muestra la pantalla de monitoreo de despacho de Harry Bravo Coronel. 25/08/2018
a punto de sobrepasar su rango horario pedidos con los mensajes de alertar indicando que
de despacho. en la bodega las unidades tienen pedidos que están
a punto de sobrepasar su rango horario de
despacho.

272
[Link] Ambiente de Pruebas
[Link].1 Requisitos de Hardware y Software
Para la ejecución de los casos de prueba, se tendrá en cuenta los requisitos de hardware y
software de los siguientes equipos en el ambiente de pruebas:

[Link].1.1 PC de escritorio
 Procesador Intel Core i5 de 3.3 GHz.

 Memoria RAM de 4GB.

 Pantalla LED de 21 pulgadas con resolución de 1366 x 768 píxeles.

 Sistema Operativo Windows 10.

 Navegador Chrome versión 68.0 o superior.

 Herramienta SoapUI.

 Contar con conexión a Internet.

 Contar con acceso a los servicios de Google Maps Directions y Firebase Realtime
Database alojados en la nube.

[Link].1.2 Servidor de Aplicaciones

 Procesador Intel Xeon E5-2609 de 6 núcleos de 1.90 GHz.

 Memoria RAM de 8 GB.

 Disco Duro de 500 GB.

 Sistema Operativo CentOS Linux 7.

 Servidor de Aplicaciones GlassFish 5.0.

 Java Development Kit 1.8.

[Link].1.3 Servidor de Base de Datos

 Procesador Intel Xeon E5-2640 de 8 núcleos de 2.0 GHz.

 Memoria RAM de 16 GB.

 Disco Duro de 4 TB.

273
 Sistema Operativo CentOS Linux 7.

 Motor de Base de Datos MySQL 5.7.

[Link] Pruebas de Aceptación

Las pruebas de aceptación deben ser realizadas por el usuario final del aplicativo, en el cual
Producción se compromete a sugerir el Set de Casos de Pruebas, quedando finalmente a
criterio del Líder de Proyecto y el usuario final el alcance de las mismas. Asimismo, al
finalizar las pruebas, el usuario final debe emitir un informe garantizando la conformidad de
las pruebas realizadas.

[Link] Tiempo y Recursos Requeridos

 El tiempo estimado para completar las pruebas es de 2 días.

 Se requerirá 1 persona asignada al 100% para completar la ejecución de las pruebas.

274
7.3.2 Caso de Pruebas del CUS07_Generar Hojas de Ruta
Tabla 132.
Resumen de CP_CUS07_Generar Hojas de Ruta
Nombre del Caso de Prueba CP_CUS07_Generar Hojas de Ruta
Número de Escenarios 2
Número de Escenarios Probados 2

Tabla 133.
Lista de Escenarios de CP_CUS07_Generar Hojas de Ruta
Lista de Escenarios
N° Cód. CUS Descripción del Escenario Resultado Esperado Responsable de Prueba
1 CUS07 Generar hoja de ruta de pedidos de despacho a Muestra el PDF de la hoja de ruta con los pedidos de Harry Bravo Coronel.
domicilio con el orden de despacho optimizado. despacho a domicilio optimizados con el API de
Google Maps Directions.
2 CUS07 Generar hoja de ruta de pedidos de retiro en tienda Muestra el PDF de la hoja de ruta con los pedidos de Harry Bravo Coronel.
con el orden de despacho optimizado. retiro en tienda optimizados con el API de Google
Maps Directions.

Tabla 134.
Escenario 1 de CP_CUS07_Generar Hojas de Ruta
Nombre del Caso de Prueba CP_CUS07_Generar Hojas de Ruta
Número de Escenario 1
Descripción del Escenario Generar hoja de ruta de pedidos de despacho a domicilio con el orden de despacho optimizado.
Precondiciones Debe estar previamente registrada la información de los choferes.
Debe estar previamente registrada la información de las unidades.
Debe estar previamente registrada la información de los tipos de unidades.
Debe estar previamente registrada la información de las bodegas o nodos.
Debe estar previamente registrada la información de los clientes.
Debe estar previamente registrada la información de las ventanas horarias.
Debe estar previamente registrada la información de los pedidos pendientes a despachar mañana.
Debe estar previamente registrada la información del detalle de los pedidos pendientes a despachar mañana.

275
Tabla 135.
Pasos de Escenario 1 de CP_CUS07_Generar Hojas de Ruta
Paso Descripción Entrada Resultado Esperado Evidencia
1 Verificar que Muestra el resultado de la
existan pedidos de consulta en Base de
despacho a Datos.
domicilio para
despachar mañana
en el nodo de San
Miguel.

2 Actualizar la hora Muestra la respuesta de la

de ejecución del base de datos.
proceso
automático.

3 Verificar el Muestra el resultado de la

directorio donde se consulta en Base de
genera la hoja de Datos.
ruta.
4 Comprobar que los N/A Muestra los archivos PDF
archivos PDF de de hoja de ruta generados
hoja de ruta estén en disco y separados por
generados en disco bodega o nodo.
separados por
bodega o nodo.
5 Comprobar que el URL: Comparar el orden Response del API de Google Maps Directions
orden de despacho [Link] optimizado de las
de los pedidos de la Mode: Driving direcciones de la hoja de
hoja de ruta sea Origin: Av. de la Marina 2355, San Miguel, Perú ruta con respecto al orden
equivalente al Destination: Ignacio Mariategui 105, Barranco, Perú generado por el API de
ordenamiento Waypoints: Google Maps Directions.
óptimo que retorna Direcciones

276
el API de Google Av. Las Leyendas 580, San Miguel, Perú
Maps Directions. Av. Antonio José de Sucre 175, Magdalena del
Mar, Perú
Av. Gral. Salaverry 2370, Jesús María, Perú
Av. Universitaria 1921, Pueblo Libre, Perú

Explicación del ordenamiento del API de Google Maps Directions:

Posición de waypoints ingresados en request: “Waypoint order” de Google Maps Directions:

Pos. Direcciones Pos. Direcciones
0 Av. de los Precursores 164, San 0 Av. de los Precursores 164, San
Miguel, Perú Miguel, Perú
1 Av. Antonio José de Sucre 175, 3 Av. Universitaria 1921, Pueblo Libre,
Magdalena del Mar, Perú Perú
2 Av. Gregorio Escobedo 895, Jesús 2 Av. Gregorio Escobedo 895, Jesús
María, Perú María, Perú
3 Av. Universitaria 1921, Pueblo Libre, 1 Av. Antonio José de Sucre 175,
Perú Magdalena del Mar, Perú
Fin Ignacio Mariategui 105, Barranco, Fin Ignacio Mariategui 105, Barranco,
Perú Perú

Por lo tanto, el ordenamiento del API de Google Maps Directions es equivalente al orden de despacho
de pedidos de la hoja de ruta:

277
Tabla 136.
Escenario 2 de CP_CUS07_Generar Hojas de Ruta
Nombre del Caso de Prueba CP_CUS07_Generar Hojas de Ruta
Número de Escenario 2
Descripción del Escenario Generar hoja de ruta de pedidos de retiro en tienda con el orden de despacho optimizado.
Precondiciones Debe estar previamente registrada la información de los choferes.
Debe estar previamente registrada la información de las unidades.
Debe estar previamente registrada la información de los tipos de unidades.
Debe estar previamente registrada la información de las bodegas o nodos.
Debe estar previamente registrada la información de los clientes.
Debe estar previamente registrada la información de las ventanas horarias.
Debe estar previamente registrada la información de los pedidos pendientes a despachar mañana.
Debe estar previamente registrada la información del detalle de los pedidos pendientes a despachar mañana.

Tabla 137.
Pasos de Escenario 2 de CP_CUS07_Generar Hojas de Ruta
Paso Descripción Entrada Resultado Esperado Evidencia
1 Verificar que Muestra el resultado de la
existan pedidos de consulta en Base de
retiro en tienda para Datos.
despachar mañana

278
 en la bodega de
Lurín.

2 Actualizar la hora Muestra la respuesta de la

de ejecución del base de datos.
proceso
automático.

3 Verificar el Muestra el resultado de la

directorio donde se consulta en Base de
genera la hoja de Datos.
ruta.
4 Comprobar que los N/A Muestra los archivos PDF
archivos PDF de de hoja de ruta generados
hoja de ruta estén en disco y separados por
generados en disco bodega o nodo.
separados por
bodega o nodo.
5 Comprobar que el URL: Comparar el orden
orden de despacho [Link] optimizado de las Response del API de Google Maps Directions
de los pedidos de la Mode: Driving direcciones de la hoja de
hoja de ruta sea Origin: Almacén Empresa Retail, Lurín, Perú ruta con respecto al orden
equivalente al Destination: Av. Oscar R. Benavides 3866, generado por el API de
ordenamiento Bellavista, Perú Google Maps Directions.
óptimo que retorna Waypoints:
el API de Google Direcciones
Maps Directions. Av. Javier Prado Este 4200, Santiago de Surco,
Perú

279
Av. Circunvalación 1803, San Juan de Miraflores,
Perú
Av. Oscar R. Benavides 3866, Bellavista, Perú
Av. Circunvalación 1803, San Juan de Miraflores,
Perú

Explicación del ordenamiento del API de Google Maps Directions:

Posición de waypoints ingresados en request: “Waypoint order” de Google Maps

Pos. Direcciones Directions:
0 Av. Javier Prado Este 4200, Santiago de Pos. Direcciones
Surco, Perú 1 Av. Circunvalación 1803, San Juan
1 Av. Circunvalación 1803, San Juan de de Miraflores, Perú
Miraflores, Perú 3 Av. Circunvalación 1803, San Juan
2 Av. Oscar R. Benavides 3866, de Miraflores, Perú
Bellavista, Perú 0 Av. Javier Prado Este 4200,
3 Av. Circunvalación 1803, San Juan de Santiago de Surco, Perú
Miraflores, Perú 2 Av. Oscar R. Benavides 3866,
Fin Av. Oscar R. Benavides 3866, Bellavista, Perú
Bellavista, Perú Fin Av. Oscar R. Benavides 3866,
Bellavista, Perú

Por lo tanto, el ordenamiento del API de Google Maps Directions es equivalente al orden de despacho
de pedidos de la hoja de ruta:

280
7.3.3 Caso de Pruebas del CUS18_Monitorear Despacho de Pedidos
Tabla 138.
Resumen de CP_CUS18_Monitorear Despacho de Pedidos
Nombre del Caso de Prueba CP_CUS18_Monitorear Despacho de Pedidos
Número de Escenarios 5
Número de Escenarios de 5
Probados

Tabla 139.
Lista de Escenarios de CP_CUS18_Monitorear Despacho de Pedidos
Lista de Escenarios
N° Cód. CUS Descripción del Escenario Resultado Esperado Responsable de Prueba
1 CUS18 Consultar ruta completa de los despachos de Muestra el popup de ruta completa de los despachos Harry Bravo Coronel.
pedidos a domicilio de una unidad. de los pedidos a domicilio de una unidad donde se
visualiza cada pedido marcado en el mapa con su
orden de despacho, además de la ruta trazada y el
orden de despacho de los pedidos con distancia y
tiempo estimado entre punto y punto.
2 CUS18 Consultar ruta completa de los despachos de los Muestra el popup de ruta completa de los despachos Harry Bravo Coronel.
pedidos de retiro en tienda de una unidad. de los pedidos de retiro en tienda de una unidad donde
se visualiza cada pedido marcado en el mapa con su

281
 orden de despacho y la ruta trazada del despacho de
los pedidos con distancia y tiempo estimado entre
punto y punto.
3 CUS18 Simular el tracking de la unidad moviéndose a Muestra el popup de la ubicación de la unidad donde Harry Bravo Coronel.
través de la ruta para llegar al punto destino de se visualiza la unidad moviéndose a través de la ruta
despacho. modificando su tiempo y distancia restante para llegar
al punto destino y comprobar cómo se actualiza las
coordenadas en el Firebase Realtime Database.
4 CUS18 Actualizar en tiempo real los dashboards y las Muestra la pantalla de monitoreo de despacho de Harry Bravo Coronel.
tablas de pedidos por estado en la pantalla de pedidos con las tablas de pedidos por estado, y el
monitoreo de despacho de pedidos. dashboard de la bodega y de la unidad actualizada.
5 CUS18 Alertar cuando un pedido pendiente está a punto Muestra la pantalla de monitoreo de despacho de Harry Bravo Coronel.
de sobrepasar su ventana horaria de despacho. pedidos con los mensajes de alertar indicando que en
la bodega las unidades tienen pedidos que están a
punto de sobrepasar su ventana horaria de despacho.

Tabla 140.
Escenario 1 de CP_CUS18_Monitorear Despacho de Pedidos
Nombre del Caso de Prueba CP_CUS18_Monitorear Despacho de Pedidos
Número de Escenario 1
Descripción del Escenario Consultar ruta completa de los despachos de pedidos a domicilio de una unidad.
Precondiciones Debe estar previamente registrada la información de las bodegas o nodos.
Debe estar previamente registrada la información de las unidades.
Debe estar previamente registrada la información de los choferes.
Debe estar previamente registrada la información de los clientes.
Debe estar previamente registrada la información de las ventanas horarias.
Debe estar previamente registrada la información de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información de las hojas de ruta pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de las hojas de ruta pendientes a despachar hoy.

282
Tabla 141.
Pasos de Escenario 1 de CP_CUS18_Monitorear Despacho de Pedidos
Paso Descripción Entrada Resultado Esperado Evidencia
1 Verificar que Muestra los datos de la
existan hojas de consulta de Base de
ruta a despachar Datos.
hoy para el nodo de
San Miguel.
2 Ingresar a la opción N/A Muestra la pantalla de
de menú de monitoreo de despacho de
“Monitoreo”. pedidos con la bodega a
seleccionar.

3 Seleccionar la Bodega: Nodo San Miguel Muestra la pantalla de

bodega o nodo. monitoreo de despacho de
pedidos con el dashboard
y la lista de unidades de la
bodega seleccionada.

283
4 Seleccionar la Unidad: A5F-746 Muestra la pantalla de
unidad. monitoreo de despacho de
pedidos con el dashboard
y la lista de pedidos por
estados de la unidad
seleccionada.

5 Seleccionar el URL: Comparar el orden Response del API de Google Maps Directions
enlace “Ver ruta [Link] optimizado de las
completa”. Mode: Driving direcciones del mapa con
Origin: Av. de la Marina 2355, San Miguel, Perú respecto al orden
Destination: Ignacio Mariategui 105, Barranco, Perú generado por el API de
Waypoints: Google Maps Directions.
Direcciones
Av. Las Leyendas 580, San Miguel, Perú
Av. Antonio José de Sucre 175, Magdalena del
Mar, Perú
Av. Gral. Salaverry 2370, Jesús María, Perú
Av. Universitaria 1921, Pueblo Libre, Perú

284
Explicación del ordenamiento del API de Google Maps Directions:

Posición de waypoints ingresados en request: “Waypoint order” de Google Maps Directions:

Pos. Direcciones Pos. Direcciones
0 Av. de los Precursores 164, San Miguel, 0 Av. de los Precursores 164, San Miguel,
Perú Perú
1 Av. Antonio José de Sucre 175, 3 Av. Universitaria 1921, Pueblo Libre,
Magdalena del Mar, Perú Perú
2 Av. Gregorio Escobedo 895, Jesús 2 Av. Gregorio Escobedo 895, Jesús
María, Perú María, Perú
3 Av. Universitaria 1921, Pueblo Libre, 1 Av. Antonio José de Sucre 175,
Perú Magdalena del Mar, Perú
Fin Ignacio Mariategui 105, Barranco, Perú Fin Ignacio Mariategui 105, Barranco, Perú

Por lo tanto, el ordenamiento del API de Google Maps Directions es equivalente al orden de despacho
que se muestra en el mapa del popup de ruta completa de los despachos de los pedidos a domicilio de
una unidad:

285
Tabla 142.
Escenario 2 de CP_CUS18_Monitorear Despacho de Pedidos
Nombre del Caso de Prueba CP_CUS18_Monitorear Despacho de Pedidos
Número de Escenario 2
Descripción del Escenario Consultar ruta completa de los despachos de los pedidos de retiro en tienda de una unidad.
Precondiciones Debe estar previamente registrada la información de las bodegas o nodos.

286
 Debe estar previamente registrada la información de las unidades.
Debe estar previamente registrada la información de los choferes.
Debe estar previamente registrada la información de los clientes.
Debe estar previamente registrada la información de las ventanas horarias.
Debe estar previamente registrada la información de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información de las hojas de ruta pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de las hojas de ruta pendientes a despachar hoy.

Tabla 143.
Pasos de Escenario 2 de CP_CUS18_Monitorear Despacho de Pedidos
Paso Descripción Entrada Resultado Esperado Evidencia
1 Verificar que Muestra los datos de la
existan hojas de consulta de Base de
ruta a despachar Datos.
hoy para la bodega
Lurín.
2 Ingresar a la opción N/A Muestra la pantalla de
de menú de monitoreo de despacho de
“Monitoreo”. pedidos con la bodega a
seleccionar.

3 Seleccionar la Bodega: Bodega Lurín. Muestra la pantalla de

bodega o nodo. monitoreo de despacho de
pedidos con el dashboard
y la lista de unidades de la
bodega seleccionada.

287
4 Seleccionar la Unidad: W1X-547 Muestra la pantalla de
unidad. monitoreo de despacho de
pedidos con el dashboard
y la lista de pedidos por
estados de la unidad
seleccionada.

288
5 Seleccionar el URL: Comparar el orden Response del API de Google Maps Directions
enlace “Ver ruta [Link] optimizado de las
completa”. Mode: Driving direcciones del mapa con
Origin: Almacén Empresa Retail, Lurín, Perú respecto al orden
Destination: Av. Oscar R. Benavides 3866, generado por el API de
Bellavista, Perú Google Maps Directions.
Waypoints:
Direcciones
Av. Javier Prado Este 4200, Santiago de Surco,
Perú
Av. Circunvalación 1803, San Juan de Miraflores,
Perú
Av. Oscar R. Benavides 3866, Bellavista, Perú
Av. Circunvalación 1803, San Juan de Miraflores, Explicación del ordenamiento del API de Google Maps Directions:
Perú

289
 Posición de waypoints ingresados en request: “Waypoint order” de Google Maps Directions:
Pos. Direcciones Pos. Direcciones
0 Av. Javier Prado Este 4200, Santiago de 1 Av. Circunvalación 1803, San Juan de
Surco, Perú Miraflores, Perú
1 Av. Circunvalación 1803, San Juan de 3 Av. Circunvalación 1803, San Juan de
Miraflores, Perú Miraflores, Perú
2 Av. Oscar R. Benavides 3866, 0 Av. Javier Prado Este 4200, Santiago de
Bellavista, Perú Surco, Perú
3 Av. Circunvalación 1803, San Juan de 2 Av. Oscar R. Benavides 3866,
Miraflores, Perú Bellavista, Perú
Fin Av. Oscar R. Benavides 3866, Fin Av. Oscar R. Benavides 3866,
Bellavista, Perú Bellavista, Perú

Por lo tanto, el ordenamiento del API de Google Maps Directions es equivalente al orden de despacho
que se muestra en el mapa del popup de ruta completa de los despachos de los pedidos de retiro en tienda
de una unidad:

290
Tabla 144.
Escenario 3 de CP_CUS18_Monitorear Despacho de Pedidos
Nombre del Caso de Prueba CP_CUS18_Monitorear Despacho de Pedidos
Número de Escenario 3
Descripción del Escenario Simular el tracking de la unidad moviéndose a través de la ruta para llegar al punto destino de despacho.
Precondiciones Debe estar previamente registrada la información de las bodegas o nodos.
Debe estar previamente registrada la información de las unidades.
Debe estar previamente registrada la información de los choferes.
Debe estar previamente registrada la información de los clientes.
Debe estar previamente registrada la información de las ventanas horarias.
Debe estar previamente registrada la información de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información de las hojas de ruta pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de las hojas de ruta pendientes a despachar hoy.

Tabla 145.
Pasos de Escenario 3 de CP_CUS18_Monitorear Despacho de Pedidos
Paso Descripción Entrada Resultado Esperado Evidencia

291
1 Verificar que Muestra los datos de la
existan hojas de consulta de Base de
ruta a despachar Datos.
hoy para la bodega
Lurín.
2 Ingresar a la opción N/A Muestra la pantalla de
de menú de monitoreo de despacho de
“Monitoreo”. pedidos con la bodega a
seleccionar.

3 Seleccionar la Bodega: Bodega Lurín. Muestra la pantalla de

bodega o nodo. monitoreo de despacho de
pedidos con el dashboard
y la lista de unidades de la
bodega seleccionada.

292
4 Seleccionar la Unidad: A7V-510 Muestra la pantalla de
unidad. monitoreo de despacho de
pedidos con el dashboard
y la lista de pedidos por
estados de la unidad
seleccionada.

5 Pulsar el ícono que N/A Muestra el popup de

está al costado del ubicación actual de la
pedido pendiente. unidad.

293
6 Pulsar el ícono de Ingresar a la consola de Firebase con una cuenta de Comparar que la distancia
simulación. Gmail. y el tiempo restante que Partida Viaje
Base de Datos: [Link] muestra en la pantalla
[Link]/ web desde la partida, el
viaje y el destino sea
equivalente a la distancia
y tiempo restante
mostrado en el Firebase
Realtime Database.
Además, de verificar que
la longitud y latitud vaya
variando en Firebase
Realtime Database
conforme la unidad vaya
avanzando a través de la
ruta trazada en el mapa.

294
Distancia Restante = distanceleft / 1000. Distancia Restante = distanceleft / 1000.
Distancia Restante = 28413 m / 1000 m = 28.413 Distancia Restante = 14025 m / 1000 m = 14.025
km. km.
La distancia restante en la partida es equivalente a La distancia restante en la partida es equivalente a
28 km. 14 km.
Tiempo Restante = timeleft / 60. Tiempo Restante = timeleft / 60.
Tiempo Restante = 1773 seg / 60 seg = 29.55 min. Tiempo Restante = 723 seg / 60 seg = 12.05 min.
El tiempo restante en la partida es equivalente a El tiempo restante en la partida es equivalente a
29 min. 12 min.

Destino

295
Distancia Restante = distanceleft / 1000.
Distancia Restante = 0 m / 1000 m = 0 km.
La distancia restante en la partida es equivalente a 0 km.
Tiempo Restante = timeleft / 60.
Tiempo Restante = 0 seg / 60 seg = 0 min.
El tiempo restante en la partida es equivalente a 0 min.

296
 En Firebase Realtime Database se observa que los atributos distanceleft y timeleft van disminuyendo
conforme se acerca al punto destino. Asimismo, la latitud y longitud varía conforme la unidad recorre la
ruta trazada.

Tabla 146.
Escenario 4 de CP_CUS18_Monitorear Despacho de Pedidos
Nombre del Caso de Prueba CP_CUS18_Monitorear Despacho de Pedidos
Número de Escenario 4
Descripción del Escenario Actualizar en tiempo real los dashboards y las tablas de pedidos por estado en la pantalla de monitoreo de despacho de pedidos.
Precondiciones Debe estar previamente registrada la información de las bodegas o nodos.
Debe estar previamente registrada la información de las unidades.
Debe estar previamente registrada la información de los choferes.
Debe estar previamente registrada la información de los clientes.
Debe estar previamente registrada la información de las ventanas horarias.
Debe estar previamente registrada la información de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información de las hojas de ruta pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de las hojas de ruta pendientes a despachar hoy.

Tabla 147.
Pasos de Escenario 4 de CP_CUS18_Monitorear Despacho de Pedidos
Paso Descripción Entrada Resultado Esperado Evidencia
1 Verificar que Muestra los datos de la
existan hojas de consulta de Base de
ruta a despachar Datos.
hoy para la bodega
Lurín.
2 Ingresar a la opción N/A Muestra la pantalla de
de menú de monitoreo de despacho de
“Monitoreo”. pedidos con la bodega a
seleccionar.

297
3 Seleccionar la Bodega: Bodega Lurín. Muestra la pantalla de
bodega o nodo. monitoreo de despacho de
pedidos con el dashboard
y la lista de unidades de la
bodega seleccionada.

4 Seleccionar la Unidad: A3N-877 Muestra la pantalla de

unidad. monitoreo de despacho de
pedidos con el dashboard
y la lista de pedidos por
estados de la unidad
seleccionada.

298
299
5 Actualizar los Muestra la respuesta de la
estados de los Base de Datos.

300
 pedidos en Base de
Datos.

6 Obtener los datos Muestra los datos de las Porcentaje de cada estado de pedido por la bodega Lurín:
necesarios de Base consultas de Base de
de Datos con la Datos.
finalidad de Porcentaje de cada estado de pedido por la unidad A3N-877:
compararlos con
los datos que
muestra la pantalla Pedido Atendido:
de monitoreo de
despacho de
pedidos.
Pedido No Atendido:

Pedido Reprogramado:

Pedido Cancelado:

301
Pedidos Pendientes:

302
7 Visualizar la N/A Comparar la equivalencia
actualización en de los datos actualizados
tiempo real de la de la pantalla de
pantalla de monitoreo de despacho de
monitoreo de pedidos con los datos
despacho de esperados en el paso
pedidos. anterior.

303
304
Tabla 148.
Escenario 5 de CP_CUS18_Monitorear Despacho de Pedidos
Nombre del Caso de Prueba CP_CUS18_Monitorear Despacho de Pedidos
Número de Escenario 5
Descripción del Escenario Alertar cuando un pedido pendiente está a punto de sobrepasar su ventana horaria de despacho.
Precondiciones Debe estar previamente registrada la información de las bodegas o nodos.
Debe estar previamente registrada la información de las unidades.
Debe estar previamente registrada la información de los choferes.
Debe estar previamente registrada la información de los clientes.
Debe estar previamente registrada la información de las ventanas horarias.
Debe estar previamente registrada la información de los pedidos pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de los pedidos pendientes a despachar hoy.

305
 Debe estar previamente registrada la información de las hojas de ruta pendientes a despachar hoy.
Debe estar previamente registrada la información del detalle de las hojas de ruta pendientes a despachar hoy.

Tabla 149.
Pasos de Escenario 5 de CP_CUS18_Monitorear Despacho de Pedidos
Paso Descripción Entrada Resultado Esperado Evidencia
1 Verificar que Muestra los datos de la
existan hojas de consulta de Base de
ruta a despachar Datos.
hoy para la bodega
Lurín.
2 Ingresar a la opción N/A Muestra la pantalla de
de menú de monitoreo de despacho de
“Monitoreo”. pedidos con la bodega a
seleccionar.

3 Seleccionar la Bodega: Bodega Lurín. Muestra la pantalla de

bodega o nodo. monitoreo de despacho de
pedidos con el dashboard
y la lista de unidades de la
bodega seleccionada.

306
4 Seleccionar la Unidad: A3N-877 Muestra la pantalla de
unidad. monitoreo de despacho de
pedidos con el dashboard
y la lista de pedidos por
estados de la unidad
seleccionada.

307
308
5 Verificar la Muestra los datos de la
cantidad de consulta de Base de
minutos de Datos.
advertencia cuando
un pedido está a
punto de sobrepasar
la ventana horaria.
6 Visualizar el N/A Verificar que existan Hora de Advertencia = Hora fin de la ventana horaria – Minutos de Advertencia.
mensaje de alerta pedidos que están a 10
cuando los pedidos minutos de sobrepasar la Ejemplo: ventana horaria de 8:00 am a 12:00 pm.
están a punto de hora fin de su ventana

309
sobrepasar su horaria de acuerdo con la Hora de Advertencia = 12:00 pm – 10 min = 11:50 am.
ventana horaria, es bodega y unidad indicada
decir, avisará con en el mensaje de alerta. Hora actual del sistema
10 minutos de
anticipación
(configurable).
Es decir, que el primer mensaje de alerta se visualizará a las 11:50 am y se remarcará de color rojo los
pedidos que están a punto de sobrepasar su ventana horaria.

310
311
7.4 Conclusiones
 En los casos de pruebas de Generación de Hojas de Ruta y Monitoreo de Despacho de
Pedidos se ha recopilado los escenarios más importantes que agregan valor y hacen uso
de la tecnología innovadora demostrando la veracidad de los resultados obtenidos del
aplicativo con respecto a los resultados obtenidos del API de Google Maps Directions y
Firebase Realtime Database.

 Las métricas de calidad de software son de vital importancia porque nos permite medir
la calidad del producto del software en base a los objetivos de calidad que se han
establecido y se desean alcanzar, por lo tanto, brinda una oportunidad de mejora del
producto de software.

 En algunos escenarios de los casos de pruebas de Generación de Hojas de Ruta y

Monitoreo de Despacho de Pedidos es necesario que el ejecutor de pruebas esté
capacitado en el uso de la herramienta SoapUI para ejecutar el API de Google Maps
Directions, además de la consola de Firebase Realtime Database con el objetivo de
comprobar los resultados obtenidos de dichos servicios con respecto a los resultados
obtenidos en la aplicación.

312
8 CAPÍTULO 7: CONSTRUCCIÓN
8.1 Introducción
El presente capítulo tiene como finalidad desarrollar los patrones elegidos para solución
propuesta. Se desarrollarán los siguientes puntos, inicialmente el diagrama de los patrones
del sistema, una especificación detallada de los patrones seleccionados.

Otro de los puntos a desarrollar dentro de este capítulo es el modelo de datos, en este, están
contenidos dos temas relevantes, el modelo de datos físicos del sistema y el diccionario de
datos detallado. Por último, se muestra el análisis de resultados del proyecto.

Cabe resaltar que todos los puntos desarrollados en el presente capítulo están orientados a la
solución propuesta.

8.2 Patrones de la Solución Propuesta

8.2.1 Diagrama de Patrones del Sistema
[Link] Diagramas del Patrón Intercepting Filter
A continuación, se muestran los diagramas del patrón Intercepting Filter, el cuál es usado en
el proyecto de Servicios REST para filtrar el intercambio de recursos de origen cruzado
(CORS), es decir, permite que recursos restringidos puedan ser solicitados a través de
peticiones Ajax por la aplicación móvil, la cual se encuentra en un dominio diferente.

Figura 85. Diagrama de Clases de Intercepting Filter

(Alur, Crupi, & Malks, 2003)

313
 Figura 86. Diagrama de Secuencia de Intercepting Filter
(Alur, Crupi, & Malks, 2003)

[Link] Diagramas del Patrón Composite View

A continuación, se muestran los diagramas del patrón Composite View, el cuál es usado en
el proyecto Web con el uso del framework Apache Tiles que permite definir fragmentos que
se ensamblan en páginas completas en tiempo de ejecución.

Figura 87. Diagrama de Clases Composite View

(Alur, Crupi, & Malks, 2003)

314
 Figura 88. Diagrama de Secuencia Composite View
(Alur, Crupi, & Malks, 2003)

[Link] Diagramas del Patrón View Helper

A continuación, se muestran los diagramas del patrón View Helper, el cuál es usado en el
proyecto Web con el uso de JSTL y custom tags de Spring en las páginas jsp.

Figura 89. Diagrama de Clases de View Helper

(Alur, Crupi, & Malks, 2003)

315
 Figura 90. Diagrama de Secuencia de View Helper
(Alur, Crupi, & Malks, 2003)

[Link] Diagrama del Patrón Dependency Injection

A continuación, se muestra el diagrama del patrón Dependency Injection, el cuál es usado
en el proyecto Web, Web Service y Mobile con el uso de frameworks como Spring y
Angular.

Figura 91. Diagrama de Clases de Dependency Injection

(Fowler, 2004)

316
8.2.2 Especificación Detallada de los Patrones Seleccionados
[Link] Especificación Detallada del Patrón Interceptor Filter
[Link].1 Propósito
Interceptar y manipular una petición del cliente web antes y después de que sea procesada,
con la finalidad de tomar acciones que determinen si el procesamiento de la petición debe
continuar o no.

[Link].2 Clasificación
Patrón J2EE de la Capa de Presentación.

[Link].3 Motivación
 Se requiere un procesamiento centralizado y común entre peticiones, como comprobar
si la sesión del cliente es válida, si el tipo de petición viola algunas restricciones, si el
browser soporta el tipo de cliente, si el encoding que usa el cliente es el adecuado para
enviar los datos, etc.

 Se requiere que los componentes de preprocesamiento y postprocesamiento estén

ligeramente acoplados con los servicios básicos de manejo de peticiones para facilitar la
adición y eliminación transparente.

 Se requiere que los componentes de preprocesamiento y postprocesamiento sean

independientes entre sí y autónomos para facilitar la reutilización.

[Link].4 Solución
Usar el patrón Intecepting Filter como un filtro conectable para el preprocesamiento y
postprocesamiento de las peticiones. Asimismo, los filtros son independientes del código de
la aplicación principal, por lo que se pueden agregar o eliminar declarativamente utilizando
un descriptor de despliegue sin necesidad de cambiar el código existente. Según la
especificación del Servlet 2.3 provee un mecanismo estándar para construir cadenas de
filtros permitiendo agregar y eliminar filtros de esas cadenas.

[Link].5 Participantes y Responsabilidades

 Client: Envía una petición al FilterManager.

 Filter Manager: Administra el procesamiento del filtro. Crea el FilterChain con los
filtros apropiados, en el orden correcto e inicia el procesamiento.

317
 FilterChain: Es una colección ordenada de filtros independientes.

 FilterOne, FilterTwo: Representan filtros individuales que se asignan a un Target. El

FilterChain coordina el procesamiento de filtros.

 Target: Es el recurso solicitado por el cliente.

[Link].6 Implementación
En el proyecto de Servicios REST se implementó una clase CorsFilter encargada de validar
el control de acceso de los métodos HTTP de las peticiones provenientes de la aplicación
móvil que se encuentra en un dominio diferente al de los Servicios REST.

A continuación, se agrega el fragmento de código fuente donde se hace uso del patrón
Intercepting Filter:

Figura 92. Filtro Java CorsFilter

(Elaboración propia, 2018)

318
[Link].7 Consecuencias
 Centraliza el control con manejadores ligeramente acoplados.

 Mejora la reutilización.

 Configuración declarativa y flexible.

 El intercambio de grandes cantidades de información entre filtros puede ser ineficiente

(Alur, Crupi, & Malks, 2003).

[Link] Especificación Detallada del Patrón Composite View

[Link].1 Propósito
Crear una vista a partir de componentes modulares y atómicos que se combinan para crear
un conjunto compuesto, a la vez que se administra el contenido y el diseño
independientemente.

[Link].2 Clasificación
Patrón J2EE de la Capa de Presentación.

[Link].3 Motivación
 Se requiere subvistas comunes, como encabezados, pies de página y menús reutilizados
en varias vistas, que pueden aparecer en diferentes ubicaciones dentro de cada diseño de
página.

 Se tiene contenido en las subvistas que pueden cambiar con frecuencia o estar sujetas a
controles de acceso, como limitar el acceso a los usuarios en determinadas funciones.

 Se requiere evitar la incrustación y duplicación de subvistas en múltiples vistas, lo que

dificulta el mantenimiento de los cambios en el diseño de las vistas.

[Link].4 Solución
Usar el patrón Composite View la cual permite componer múltiples subvistas atómicas. Cada
subvista de la plantilla general puede incluirse dinámicamente en el conjunto, y el diseño de
la página puede administrarse independientemente del contenido. A continuación, se
muestra de forma gráfica la solución descrita.

319
 Figura 93. Estructura de Página Web con Composite View
(Apache Software Foundation, 2017)

[Link].5 Participantes y Responsabilidades

 Client: Despacha una vista.

 View: Representa la página.

 SimpleView: Representa un segmento de vista o subvista.

 CompositeView: Se compone de múltiples vistas, donde cada una de estas vistas puede
ser una subvista o una vista compuesta.

 Template: Representa el diseño de la vista.

 ViewManager: Usa un Template para imponer un diseño en el que coloca el contenido

apropiado, lo que permite que ViewManager administre el contenido y el diseño de
forma independiente. Asimismo, un ViewManager debería usar el tag
<tiles:insertAttribute /> para incluir un segmento de vista dentro de un Template.

[Link].6 Implementación
A continuación, se agrega los fragmentos de código fuente donde se hace uso del patrón
Composite View:

320
Figura 94. Archivo de configuración de páginas [Link]
(Elaboración propia, 2018)

Figura 95. Plantilla [Link]

(Elaboración propia, 2018)

321
 Figura 96. Página cabecera [Link]
(Elaboración propia, 2018)

[Link].7 Consecuencias
 Mejora la modularidad y el reúso.

 Agrega control basado en roles o políticas, es decir, una vista compuesta puede incluir
de forma condicional fragmentos de plantilla en función del rol del usuario o políticas de
seguridad.

 Mejora la capacidad de mantenimiento.

 Reduce el rendimiento, debido a que la inclusión en tiempo de ejecución de las subvistas

tendrá como resultado un retraso cada vez que se le envíe la página al cliente (Alur,
Crupi, & Malks, 2003).

[Link] Especificación Detallada del Patrón View Helper

[Link].1 Propósito
Separar la vista de su lógica de procesamiento.

[Link].2 Clasificación
Patrón J2EE de la Capa de Presentación.

[Link].3 Motivación
 Se requiere usar vistas basadas en plantillas, como JSP.

 Se requiere evitar incrustar la lógica del programa en la vista.

 Se requiere separar la lógica de programación de la vista para facilitar la división del

trabajo entre los desarrolladores de software y los diseñadores de páginas web.

322
[Link].4 Solución
Usar Views para encapsular el código de formateo y Helpers para encapsular la lógica de
procesamiento de la vista. Una Vista delega sus responsabilidades de procesamiento a sus
clases de Helper, implementadas como JavaBeans, custom tags o tag files. Los helpers sirven
como adaptadores entre la vista y el modelo, y realizan el procesamiento relacionado con la
lógica de formateo, como por ejemplo la generación de una tabla HTML.

Actualmente, el JavaServer Pages Standard Tag Library (JSTL) proporciona un conjunto

estándar de tags que soportan la iteración, la lógica condicional, el formato de fechas entre
otros, con el objetivo de evitar incrustar la lógica de procesamiento en forma de código
scriptlet en el JSP.

[Link].5 Participantes y Responsabilidades

 Client: Despacha la vista.

 View: Representa y muestra información al Client.

 Helper1, Helper2: Encapsula la lógica de procesamiento para generar y formatear un

View. Un helper adapta un PresentationModel para una vista o proporciona acceso a los
datos brutos del PresentationModel. Una vista funciona con cualquier cantidad de
helpers, generalmente implementados como JavaBeans, custom tags o tag files.

 PresentationModel: Contiene los datos recuperados del servicio de negocio, utilizados

para generar la Vista.

[Link].6 Implementación
A continuación, se agrega los fragmentos de código fuente donde se hace uso del patrón
View Helper:

323
 Figura 97. Declaración de custom tags en JSP
(Elaboración propia, 2018)

Figura 98. Uso de custom tags en JSP

(Elaboración propia, 2018)

[Link].7 Consecuencias
 Mejora la modularidad, reutilización y mantenimiento de la aplicación, al separar el
HTML de la lógica de procesamiento.

 Facilita las pruebas, ya que probar un fragmento de código que está incrustado dentro de
un JSP es mucho más difícil que probar código que está encapsulado dentro de una clase
separada.

 El uso de helpers refleja scriptlets, es decir, una razón importante para extraer la lógica
de procesamiento de una página es reducir los detalles de implementación que están
integrados directamente en la página. Sin embargo, el uso de ciertos helpers genéricos

324
 solo reemplaza el código embebido de Java produciendo el mismo problema de exponer
los detalles de implementación, como por ejemplo un tag personalizado que modela la
lógica condicional de una instrucción “if” reflejando el código scriptlet que se pretende
reemplazar, por lo tanto, usar helpers como scriptlets es una mala práctica, aunque a
menudo se hace un intento de aplicar View Helper (Alur, Crupi, & Malks, 2003).

[Link] Especificación Detallada del Patrón Dependency Injection

[Link].1 Propósito
Mantener los componentes de una aplicación lo más desacoplados posibles.

[Link].2 Clasificación
Patrón de diseño derivado del “Principio de Inversión de Dependencia” introducido por
Martin Fowler.

[Link].3 Concepto
Dependency Injection es un patrón de diseño que tiene como finalidad mantener los
componentes de una aplicación lo más desacoplados posibles, permitiendo que sea mucho
más sencillo reemplazar la implementación de un componente por otro, evitando de esta
forma un gran cambio o impacto que pueda originar fallas en la aplicación.

Es por ello, que nos permite inyectar comportamientos a componentes haciendo que las
piezas de software sean independientes y se comuniquen únicamente a través de su interfaz.

Al aplicarse este patrón, las clases no crean la instancia de los objetos que necesitan, sino
que lo realiza otra clase contenedora que se encargará de inyectar la implementación
requerida a la interfaz.

Sin embargo, no hay necesidad de crear un contenedor de inyección en el código fuente,

debido a que este se encuentra implementado en frameworks como Spring y Angular.

[Link].4 Solución
 Usar interfaces que expongan las operaciones que es responsable un componente,
ocultando los detalles de su implementación.

 Eliminar la instanciación de objetos, en los componentes que la usan.

 Usar un configurador que indique las clases que se instanciarán en el caso de solicitarlo.

325
[Link].5 Participantes y Responsabilidades
 MovieLister: Clase cliente que invoca la interfaz MovieFinder, para acceder a sus
métodos.

 MovieFinder: Interfaz de ejemplo donde se declara los métodos a usar.

 MovieFinderImpl: Clase de ejemplo que implementa los métodos declarados en la

interfaz MovieFinder.

 Assembler: Componente encargado de instanciar la implementación MovieFinderImpl

a la interfaz MovieFinder, e inyectarlo dicha instancia a la clase MovieLister. Este
componente puede realizar este mecanismo a través de un XML o por anotaciones.

[Link].6 Implementación
A continuación, se muestra el fragmento de código fuente del proyecto web, web service y
móvil donde se hace uso del patrón Dependency Injection.

Figura 99. Configurador de instancias de Spring

(Elaboración propia, 2018)

Figura 100. Interfaz PedidoDao

(Elaboración propia, 2018)

326
Figura 101. Clase implementadora PedidoDaoImpl
(Elaboración propia, 2018)

Figura 102. Clase implementadora AdminBLImpl

(Elaboración propia, 2018)

327
Figura 103. Archivo [Link] de la Móvil
(Elaboración propia, 2018)

328
 Figura 104. Archivo [Link] de la Móvil
(Elaboración propia, 2018)

[Link].7 Consecuencias
 El código se vuelve más modular y menos acoplado, ya que los componentes no
necesitan saber detalles de la implementación de otros componentes.

 Posibilidad de reemplazar la implementación de un componente por otro, sin necesidad

de modificar las clases que lo usan.

 Las pruebas unitarias automáticas son más fáciles debido a su modularidad, permitiendo
aislar cada parte del programa para realizar pruebas sin tener que proveer a los programas
las referencias reales, sino que pueden ser simuladas mediante mocks.

 Quita la responsabilidad al programador de instanciar objetos en la aplicación,

permitiendo escribir código más rápido (Fowler, 2004).

329
8.3 Modelo de Datos
8.3.1 Modelo de Datos Físico del Sistema

Figura 105. Modelo Físico de Base de Datos

(Elaboración propia, 2018)

330
8.3.2 Diccionario de Datos

Tabla 150.
Tabla tb_actividad
Nombre de la Tabla tb_actividad
Descripción de la Tabla Tabla que almacena la información de las actividades que realiza el proceso automático.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
num_proc Número de proceso. INT No No Si
num_activ Número de actividad. INT No No Si
nom_activ Nombre de actividad. VARCHAR(100) No No No
fec_ini_ejec_activ Fecha inicio de ejecución de actividad. DATETIME No No No
fec_fin_ejec_activ Fecha fin de ejecución de actividad. DATETIME Si No No
msg_inf_activ Mensaje informativo de la actividad. VARCHAR(300) Si No No
err_tec_activ Error técnico de actividad. VARCHAR(250) Si No No
est_activ Estado de actividad (SUCCESS: Satisfactorio, ERROR: Error). VARCHAR(7) Si No No

Tabla 151.
Tabla tb_bodega
Nombre de la Tabla tb_bodega
Descripción de la Tabla Tabla que almacena la información de las bodegas o nodos donde se almacenan los productos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_bod Código de bodega. VARCHAR(10) No No Si
nom_bod Nombre de bodega. VARCHAR(80) No Si No
tip_bod Tipo de bodega (BOD: Bodega, NOD: Nodo) VARCHAR2(3) No No No
dir_bod Dirección de bodega. VARCHAR(100) No No No
email_bod Email de bodega. VARCHAR(50) No No No
cod_dist Código de distrito de bodega. VARCHAR(10) No No No

Tabla 152.
Tabla tb_bodega_zona
Nombre de la Tabla tb_bodega_zona
Descripción de la Tabla Tabla que almacena la información de las zonas de cobertura de despacho de las bodegas.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_bod Código de bodega. VARCHAR(10) No No Si
cod_zon Código de zona. VARCHAR(10) No No Si

Tabla 153.
Tabla tb_chofer
Nombre de la Tabla tb_chofer
Descripción de la Tabla Tabla que almacena la información de los choferes que conducen las unidades que transportan los productos a
los puntos destinos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
num_brev_chof Número de brevete del chofer. VARCHAR(10) No Si Si
nom_chof Nombre del chofer. VARCHAR(50) No No No
ape_chof Apellido del chofer. VARCHAR(50) No No No
telf_chof Teléfono del chofer. VARCHAR(9) No No No
email_chof Email del chofer. VARCHAR(50) No No No
flag_activ_chof Flag de activación de chofer. TINYINT No No No

331
 cod_prv Código de proveedor. VARCHAR(10) No No No

Tabla 154.
Tabla tb_cliente

Nombre de la Tabla tb_cliente

Descripción de la Tabla Tabla que almacena la información de los clientes consumidores.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_cli Código de cliente. VARCHAR(10) No Si Si
nom_cli Nombre de cliente. VARCHAR(50) No No No
ape_cli Apellido de cliente. VARCHAR(50) No No No
num_dni_cli Número de DNI de cliente. VARCHAR(8) No Si No
telf_cli Teléfono de cliente. VARCHAR(9) No No No
email_cli Email de cliente. VARCHAR(50) No No No
dir_cli Dirección de domicilio de cliente. VARCHAR(100) No No No
cod_dist Código de distrito de domicilio de cliente. VARCHAR(10) No No No

Tabla 155.
Tabla tb_controller_tienda
Nombre de la Tabla tb_controller_tienda
Descripción de la Tabla Tabla que almacena la información de los controllers de tienda que son los encargados de supervisar las
operaciones de su tienda.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_contr_tiend Código del controller de tienda. VARCHAR(10) No Si Si
nom_contr_tiend Nombre del controller de tienda. VARCHAR(50) No No No
ape_contr_tiend Apellido del controller de tienda. VARCHAR(50) No No No
telf_contr_tiend Teléfono del controller de tienda. VARCHAR(9) No No No
email_contr_tiend Email del controller de tienda. VARCHAR(50) No No No

Tabla 156.
Tabla tb_cuadrilla
Nombre de la Tabla tb_cuadrilla
Descripción de la Tabla Tabla que almacena la información de las cuadrillas que conforman un grupo de pickeadores asignados para
preparar los pedidos de una unidad de transporte.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_cuad Código de cuadrilla. VARCHAR(10) No Si Si
nom_cuad Nombre de cuadrilla. VARCHAR(50) No Si No
fec_ini_asig_cuad Fecha inicio de asignación de cuadrilla. DATE No No No
fec_fin_asig_cuad Fecha fin de asignación de cuadrilla. DATE No No No

Tabla 157.
Tabla tb_cubicacion_pedido
Nombre de la Tabla tb_cubicacion_pedido
Descripción de la Tabla Tabla que almacena la información de las ubicaciones del producto de un pedido en la bodega o nodo.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_bod Código de bodega. VARCHAR(10) No No Si
cod_ped Código de pedido. VARCHAR(10) No No Si
cod_prod Código de producto. VARCHAR(15) No No Si
area_bod Área de la bodega. VARCHAR(15) No No No

332
 pasi_area Pasillo del área de la bodega o nodo. VARCHAR(15) No No No
lado_pasi Lado del pasillo. VARCHAR(15) No No No
altu_lado Altura del lado. VARCHAR(15) No No No
prof_altu Profundidad de la altura. VARCHAR(15) No No No

Tabla 158.
Tabla tb_departamento
Nombre de la Tabla tb_departamento
Descripción de la Tabla Tabla que almacena la información de los departamentos del Perú.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_dep Código de departamento. VARCHAR(10) No No Si
nom_dep Nombre de departamento. VARCHAR(100) No No No

Tabla 159.
Tabla tb_detalle_hoja_ruta
Nombre de la Tabla tb_detalle_hoja_ruta
Descripción de la Tabla Tabla que almacena la información del detalle de las hojas de ruta.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_hoj_rut Código de hoja de ruta. VARCHAR(10) No No Si
cod_ped Código de pedido. VARCHAR(10) No No Si
ord_desp_ped Orden de despacho de pedido. INT Si No No
tiemp_prom_desp Tiempo promedio de despacho de pedido. INT Si No No
fec_estim_part Fecha y hora estimada de partida. DATETIME Si No No
tiemp_estim_lleg Tiempo estimado de llegada en minutos. INT Si No No
fec_estim_lleg Fecha y hora estimada de llegada. DATETIME Si No No
distancia_estim Distancia estimada de llegada en metros. INT Si No No
fec_pact_desp Fecha y hora pactada de despacho. DATETIME Si No No
fec_no_cump_desp Fecha y hora de no cumplimiento de despacho. DATETIME Si No No
lat_gps_desp_ped Latitud GPS de despacho de pedido. DECIMAL(10, 7) Si No No
long_gps_desp_ped Longitud GPS de despacho de pedido. DECIMAL(10, 7) Si No No
fot_desp_ped Foto del pedido que ha sido entregado al cliente o Controller de MEDIUMBLOB Si No No
Tienda.
cod_vent_hor Código de ventana horaria. VARCHAR(10) Si No No
cod_mot_ped Código de motivo de pedido en caso de no cumplimiento de VARCHAR(10) Si No No
despacho de pedido.
flag_env_vent_hor Flag de envío de ventana horaria al cliente o Controller de Tienda. TINYINT No No No

Tabla 160.
Tabla tb_detalle_pedido
Nombre de la Tabla tb_detalle_pedido
Descripción de la Tabla Tabla que almacena la información del detalle de los pedidos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_ped Código de pedido. VARCHAR(10) No No Si
cod_prod Código de producto. VARCHAR(15) No No Si
cant_prod Cantidad de producto. INT No No No
cant_prod_defect Cantidad de productos defectuosos. INT Si No No
obs_prod_defect Observación de productos defectuosos. VARCHAR(200) Si No No
cant_prod_no_ubic Cantidad de productos no ubicados en bodega o nodo. INT Si No No

333
 cod_bod Código de bodega. VARCHAR(10) No No No

Tabla 161.
Tabla tb_distrito
Nombre de la Tabla tb_distrito
Descripción de la Tabla Tabla que almacena la información de los distritos del Perú.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_dist Código de distrito. VARCHAR(10) No Si Si
nom_dist Nombre de distrito. VARCHAR(100) No No No
cod_prov Código de provincia. VARCHAR(10) No No No
cod_zon Código de la zona geográfica que pertenece el distrito. VARCHAR(10) No No No

Tabla 162.
Tabla tb_familia_producto
Nombre de la Tabla tb_familia_producto
Descripción de la Tabla Tabla que almacena la información de la familia o categoría que pertenece un grupo de productos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_fam_prod Código de familia de producto. VARCHAR(10) No Si Si
nom_fam_prod Nombre de familia de producto. VARCHAR(50) No No No

Tabla 163.
Tabla tb_hoja_ruta
Nombre de la Tabla tb_hoja_ruta
Descripción de la Tabla Tabla que almacena la información de las hojas de ruta.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_hoj_rut Código de hoja de ruta. VARCHAR(10) No Si Si
fec_gen_hoj_rut Fecha y hora de generación de hoja de ruta. DATETIME No No No
fec_desp_hoj_rut Fecha de despacho de hoja de ruta. DATE No No No
cod_bod Código de bodega. VARCHAR(10) No No No
cod_unid_chof Código de la asociación de la unidad con chofer. VARCHAR(10) No No No
cod_cuad Código de cuadrilla. VARCHAR(10) No No No

Tabla 164.
Tabla tb_kardex
Nombre de la Tabla tb_kardex
Descripción de la Tabla Tabla que almacena la información del Kardex, es decir, la existencia de los productos en la bodega o nodo.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_bod Código de bodega o nodo. VARCHAR(10) No No Si
cod_prod Código de producto. VARCHAR(15) No No Si
stk_min Stock mínimo. INT No No No
stk_act Stock actual. INT No No No
fec_act_reg Fecha y hora de registro. DATETIME No No No
fec_notif_abast Fecha de notificación de abastecimiento de productos. DATE Si No No
fec_max_abast Fecha máxima de abastecimiento de productos. DATE Si No No

334
Tabla 165.
Tabla tb_motivo_pedido
Nombre de la Tabla tb_motivo_pedido
Descripción de la Tabla Tabla que almacena la información de los motivos de reprogramación, cancelación e incumplimiento de entrega
de pedido.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_mot_ped Código de motivo de pedido. VARCHAR(10) No Si Si
desc_mot_ped Descripción de motivo de pedido. VARCHAR(100) No No No
cat_mot_ped Categoría de motivo de pedido (NATE: No atendido, REPR: VARCHAR(4) No No No
Reprogramación, CANC: Cancelación).

Tabla 166.
Tabla tb_abastecimiento
Nombre de la Tabla tb_abastecimiento
Descripción de la Tabla Tabla que almacena información del abastecimiento de productos que el proveedor realiza a la bodega.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
fec_abast Fecha de abastecimiento de producto. DATE No No Si
cod_prv Código de proveedor que abastece de productos. VARCHAR(10) No No Si
cod_bod Código de bodega que recibe los productos. VARCHAR(10) No No Si
cod_prod Código de producto a abastecer. VARCHAR(15) No No Si
cant_prod Cantidad de producto a abastecer. INT No No No
fec_reg Fecha y hora de registro. DATETIME No No No

Tabla 167.
Tabla tb_reposicion
Nombre de la Tabla tb_reposicion
Descripción de la Tabla Tabla que almacena información de la reposición de productos que la bodega realiza al nodo.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
fec_repo Fecha de reposición de producto. DATE No No Si
cod_bod Código de bodega que repone productos. VARCHAR(10) No No Si
cod_nod Código de nodo que recibe los productos. VARCHAR(10) No No Si
cod_prod Código de producto a reponer. VARCHAR(15) No No Si
cant_prod Cantidad de producto a reponer. INT No No No
fec_reg Fecha y hora de registro. DATETIME No No No

Tabla 168.
Tabla tb_parametro
Nombre de la Tabla tb_parametro
Descripción de la Tabla Tabla que almacena la información de parámetros de configuración del sistema.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_param Código de parámetro. INT No Si Si
nom_param Nombre de parámetro. VARCHAR(25) No No No
desc_param Descripción de parámetro. VARCHAR(100) No No No
val_param Valor de parámetro. VARCHAR(100) No No No

335
Tabla 169.
Tabla tb_pedido
Nombre de la Tabla tb_pedido
Descripción de la Tabla Tabla que almacena la información del pedido.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_ped Código de pedido. VARCHAR(10) No Si Si
cod_cli Código de cliente a despachar. VARCHAR(10) No No No
cod_tiend_desp Código de tienda a despachar. VARCHAR(10) Si No No
fec_sol_ped Fecha y hora de solicitud de pedido. DATETIME No No No
num_reserv_ped Número de reserva de pedido equivalente al número de INT No Si No
operación bancaria del pago realizado por el cliente.
fec_vent_ped Fecha y hora de venta de pedido. DATETIME No No No
num_verif_ped Número de verificación de pedido usado para confirmar que el INT No No No
pedido se ha despachado en el domicilio del cliente o en la
tienda.
fec_desp_ped Fecha de despacho de pedido. DATE No No No
dir_desp_ped Dirección de despacho de pedido. VARCHAR(100) No No No
cod_dist_desp_ped Código de distrito de despacho de pedido. VARCHAR(10) No No No
fec_ret_tiend Fecha de retiro en tienda del pedido. DATE Si No No
fec_recoj_tiend Fecha y hora de recojo del pedido en tienda por parte del DATETIME Si No No
cliente.
fec_repro_ped Fecha de reprogramación de pedido. DATE Si No No
fec_canc_ped Fecha y hora de cancelación de pedido. DATETIME Si No No
fec_devo_ped Fecha de devolución de pedido. DATE Si No No
cod_tiend_devo Código de tienda donde el cliente devolverá el pedido. VARCHAR(10) Si No No
cod_mot_ped Código de motivo de pedido. VARCHAR(10) Si No No
cod_pick Código de pickeador. VARCHAR(10) Si No No

Tabla 170.
Tabla tb_pickeador
Nombre de la Tabla tb_pickeador
Descripción de la Tabla Tabla que almacena la información de los pickeadores que son los encargados de la preparación de los pedidos
para su despacho.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_pick Código de pickeador. VARCHAR(10) No Si Si
nom_pick Nombre de pickeador. VARCHAR(50) No No No
ape_pick Apellido de pickeador. VARCHAR(50) No No No
fec_nac_pick Fecha de nacimiento de pickeador. DATE No No No
fec_ing_pick Fecha de ingreso de pickeador. DATE No No No
cod_cuad Código de cuadrilla. VARCHAR(10) No No No

Tabla 171.
Tabla tb_proceso
Nombre de la Tabla tb_proceso
Descripción de la Tabla Tabla que almacena la información de los procesos automáticos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
num_proc Número de proceso. INT No Si Si
nom_proc Nombre de proceso automático. VARCHAR(20) No No No
fec_ini_ejec_proc Fecha y hora de inicio de ejecución de proceso automático. DATETIME No No No

336
 fec_fin_ejec_proc Fecha y hora fin de ejecución de proceso automático. DATETIME Si No No
est_proc Estado del proceso automático (SUCCESS: Satisfactorio, VARCHAR(7) Si No No
ERROR: Error).

Tabla 172.
Tabla tb_producto
Nombre de la Tabla tb_producto
Descripción de la Tabla Tabla que almacena la información de los productos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_prod Código de producto. VARCHAR(15) No Si Si
nom_prod Nombre de producto. VARCHAR(150) No No No
marc_prod Marca de producto. VARCHAR(50) No No No
prec_unit_prod Precio unitario de producto en soles. DECIMAL(9, 2) No No No
vol_prod Volumen de producto en metros cúbicos. DECIMAL(12, 6) No No No
pes_prod Peso de producto en kilogramos. DECIMAL(12, 2) No No No
cod_tip_prod Código de tipo de producto. VARCHAR(10) No No No

Tabla 173.
Tabla tb_proveedor
Nombre de la Tabla tb_proveedor
Descripción de la Tabla Tabla que almacena la información de los proveedores de mercadería y de unidades.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_prv Código de proveedor. VARCHAR(10) No Si Si
raz_soc_prv Razón social del proveedor. VARCHAR(100) No Si No
num_ruc_prv Número de RUC del proveedor. VARCHAR(11) No Si No
telf_prv Teléfono del proveedor. VARCHAR(10) No No No
email_prv Email del proveedor. VARCHAR(50) No No No
tip_prv Tipo de proveedor (UNID: Proveedor de unidades, MERC: VARCHAR(4) No No No
Proveedor de mercadería).

Tabla 174.
Tabla tb_provincia
Nombre de la Tabla tb_provincia
Descripción de la Tabla Tabla que almacena la información de las provincias del Perú.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_prov Código de provincia. VARCHAR(10) No Si Si
nom_prov Nombre de provincia. VARCHAR(100) No No No
cod_dep Código de departamento. VARCHAR(10) No No No

Tabla 175.
Tabla tb_tienda
Nombre de la Tabla tb_tienda
Descripción de la Tabla Tabla que almacena la información de las tiendas que comercializan los productos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_tiend Código de la tienda. VARCHAR(10) No Si Si
nom_tiend Nombre de la tienda. VARCHAR(80) No Si No
dir_tiend Dirección de la tienda. VARCHAR(100) No No No
cod_contr_tienda Código del controller de tienda. VARCHAR(45) No No No

337
 cod_dist Código de distrito de la tienda. VARCHAR(10) No No No

Tabla 176.
Tabla tb_tipo_producto
Nombre de la Tabla tb_tipo_producto
Descripción de la Tabla Tabla que almacena la información de los tipos de producto que hay dentro de cada familia de productos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_tip_prod Código de tipo de producto. VARCHAR(10) No Si Si
nom_tip_prod Nombre de tipo de producto. VARCHAR(50) No Si No
cod_fam_prod Código de familia de producto. VARCHAR(10) No No No

Tabla 177.
Tabla tb_tipo_unidad
Nombre de la Tabla tb_tipo_unidad
Descripción de la Tabla Tabla que almacena la información de los tipos de unidad clasificado por su capacidad de carga.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_tip_unid Código de tipo de unidad. VARCHAR(10) No Si Si
nom_tip_unid Nombre de tipo de unidad. VARCHAR(80) No Si No
pes_max_carg Peso máximo de carga de unidad en kilogramos. DECIMAL(12, 2) No No No
vol_max_carg Volumen máximo de carga en metros cúbicos. DECIMAL(12, 2) No No No

Tabla 178.
Tabla tb_unidad
Nombre de la Tabla tb_unidad
Descripción de la Tabla Tabla que almacena la información de las unidades que transportan los pedidos de los clientes para su despacho.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
num_plac_unid Número de placa de la unidad. VARCHAR(10) No Si Si
mod_unid Modelo de la unidad. VARCHAR(50) No No No
marc_unid Marca de la unidad. VARCHAR(50) No No No
num_soat_unid Número SOAT de la unidad. VARCHAR(15) No Si No
flag_activ_unid Flag de activación de la unidad. TINYINT No No No
cod_tip_unid Código de tipo de unidad. VARCHAR(10) No No No
cod_prv Código de proveedor. VARCHAR(10) No No No

Tabla 179.
Tabla tb_unidad_chofer
Nombre de la Tabla tb_unidad_chofer
Descripción de la Tabla Tabla que almacena la información de asignación de la unidad con el chofer.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_unid_chof Código de unidad con chofer. VARCHAR(10) No Si Si
cod_bod Código de bodega. VARCHAR(10) No No No
num_placa_unid Número de placa de unidad. VARCHAR(10) No No No
num_brev_chof Número de brevete de chofer. VARCHAR(10) No No No
fec_asig_unid_chof Fecha de asignación de unidad con chofer. DATETIME No No No

Tabla 180.
Tabla tb_ventana_horaria
Nombre de la Tabla tb_ventana_horaria

338
 Descripción de la Tabla Tabla que almacena la información de las ventanas horarias de despacho de pedidos.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_vent_hor Código de ventana horaria. VARCHAR(10) No Si Si
hor_ini_vent_hor Hora inicio de ventana horaria. VARCHAR(5) No No No
hor_fin_vent_hor Hora fin de ventana horaria. VARCHAR(5) No No No
tip_vent_hor Tipo de ventana horaria (LOC: Local, PROV: Provincial). VARCHAR(4) No No No
flag_activ_vent_hor Flag de activación de ventana horaria. TINYINT No No No

Tabla 181.
Tabla tb_zona
Nombre de la Tabla tb_zona
Descripción de la Tabla Tabla que almacena la información de la zona geográfica del Perú.
Nombre de la Columna Descripción Tipo de Dato Nulo Único Llave
cod_zon Código de zona geográfica. VARCHAR(10) No Si Si
nom_zon Nombre de zona geográfica. VARCHAR(80) No Si No

339
8.4 Análisis de Resultados del Proyecto
A continuación, se muestran los indicadores que evidencian los resultados del proyecto:

Indicador de Ahorro por Costo de Flete

Tomando como referencia la operación del Nodo San Miguel (Semana 33, año 2018), se puede evidenciar en este indicador a manera detallada la cantidad de pedidos por día, unidades totales, destinos de entrega,
cantidad de distritos, y la cantidad de unidades de transporte que permitirá satisfacer la demanda para la atención de los pedidos.

Es así, que en la primera parte de este indicador se muestra la demanda de unidades de transporte que se hace en base a la experiencia del personal encargado de este proceso en el nodo. Teniendo como resultado del
análisis, un requerimiento semanal de 115 unidades de transporte de diferente cubicaje que permitirán satisfacer la demanda para la atención de la totalidad de los pedidos, esto representa un gasto de S/ 54,770.

Sin embargo, haciendo una corrida con el sistema propuesto, bajo el mismo escenario de pedidos, de manera óptima y automática podemos calcular la cantidad real de unidades que se requieren para satisfacer la
demanda de entregas. Obteniendo así un resultado de 98 unidades de transporte, que equivale a un gasto de S/ 45,511.

Este comparativo de unidades requeridas por semana, representa un ahorro del 17%.

Figura 106. Indicador de Ahorro por Costo de Flete

(Empresa Retail Perú, 2018)

Indicador de Ahorro en Capacidad de Personal

En este indicador se detalla el personal que se requiere para poder atender la demanda de picking, packing, cierre de reservas de manera manual, recepción de unidades y la atención de logística inversa. Bajo ese mismo
período de tiempo del primer indicador, se obtiene un promedio de 27 personas por día para poder cubrir cada actividad de este proceso.

340
Ahora, haciendo la corrida con el sistema propuesto, bajo la misma cantidad de pedidos, se obtiene un resultado de 21 personas para cubrir el mismo proceso, esto debido a que el sistema automatiza algunas actividades
como es el caso del cierre de reservas de pedidos en línea por parte del transportista, eliminando la actividad manual del cierre de reservas.

Esta optimización, permite un ahorro del 19% de personal, incrementando así la capacidad para gestionar los pedidos.

Figura 107. Indicador de Ahorro en Capacidad de Personal

(Empresa Retail Perú, 2018)

Indicador de Ahorro en Horas de Planificación

En este indicador se detalla la cantidad de horas que se requieren para poder atender todas las actividades que forman parte del proceso de planificación para la atención de pedidos. En este caso, se detallan las horas
que demandan las actividades como la preparación de data, tiempo de ruteo, tiempo de planificación y el tiempo de plaqueo. Se debe tener en consideración, que la actividad de ruteo se hace en base a la experiencia
del encargado de este proceso, estando susceptible a errores. Como se puede apreciar, en la primera parte del indicador, vemos que hay un promedio de 5 horas diarias para atender este proceso.

Sin embargo, al hacer una corrida con el sistema propuesto, tenemos que el promedio es de 3 horas diarias, esto debido a la automatización de la actividad del tiempo de ruteo.

Esta disminución en los tiempos de planificación representa un 24% de ahorro en horas hombre por día.

341
 Figura 108. Indicador de Ahorro en Horas de Planificación
(Empresa Retail Perú, 2018)

Indicador de Disminución de Incumplimiento de Entrega

Este indicador muestra el ratio de pedidos no entregados entre el total de pedidos por día. Al igual que los anteriores indicadores, se toma como referencia la semana 33 del 2018 para el análisis respectivo. En este
caso, en la primera parte del indicador se visualiza que el promedio de pedidos no entregados bordea el 6% diarios entre el total de pedidos.

Al hacer una corrida con el sistema propuesto, el indicador disminuye al 5% por día, esto da como resultado una disminución del 20% de pedidos no entregados en comparación de los dos escenarios.

Figura 109. Indicador de Disminución de Incumplimiento de Entrega

(Empresa Retail Perú, 2018)

342
8.5 Conclusiones
 En el sistema propuesto se han encontrado varios patrones de diseño a nivel de los
frameworks utilizados como Apache Tiles, Mybatis, Spring, Ionic y Angular, así como
en el código fuente desarrollado, tal como el patrón Filter y DAO, de los cuales se
seleccionaron los más relevantes en el desarrollo como el Intercepting Filter, Composite
View, View Helper y Dependency Injection que es el más usado en el código fuente.

 En el subcapítulo de patrones no se profundizó en patrones de arquitectura, ya que el

patrón usado es programación por capas, los cuales se detallan y visualizan en los
diagramas de la vista lógica e implementación de la arquitectura de software.

 La aplicación de los patrones de diseño es de vital importancia, porque gracias a ellos

resuelven los problemas comunes de programación permitiendo lograr desarrollar
componentes de software reutilizables, mantenibles, flexibles ante cambios, con bajo
acoplamiento y alta cohesión.

 En el modelo físico del sistema hay algunas tablas que no son parte de las entidades del
negocio, sino que son tablas de soporte al sistema desarrollado, como la tabla proceso y
actividad que registran las actividades de los procesos automáticos, o la tabla de
parámetros en donde se configuran los parámetros del sistema.

343
9 CAPÍTULO 8: GESTIÓN DEL PROYECTO
9.1 Introducción
En este capítulo, se presentan el registro de interesados, la EDT del proyecto, el cronograma
de ejecución de las tareas realizadas del proyecto, el acta de aceptación del entregable, y por
último la gestión de riesgos.

El desarrollo de este capítulo permite clarificar las responsabilidades de las personas

involucradas en el proyecto, en función a los niveles de interés e influencia. Importante tener
bien identificados a los interesados del proyecto y el grado de su participación.

La elaboración de la EDT (Estructura de Descomposición del Trabajo), tiene como objetivo

poder definir el alcance del proyecto debido a los entregables y la descomposición de estos,
en estructuras de trabajo.

Se cuenta con un cronograma de ejecución de tareas, el mismo, que permite el seguimiento

y medición del avance del proyecto en base a una programación previamente definida. Esta
medición es muy importante en el proyecto, ya que identifica las etapas en las que existieron
desviaciones de tiempo y/o recursos no planificados.

Se cuenta además con la carta de aceptación del entregable, en señal de que se otorga el
permiso del uso del tema y dejar constancia que empresa Retail acepta el contenido.

Finalmente se elabora una base de riesgos, identificando todos los posibles riesgos que
puedan presentarse durante todo el ciclo del proyecto, esto a fin de tomar acción para mitigar
cada uno de estos, y así evitar bloqueantes en el curso del desarrollo.

344
9.2 Registro de Interesados
En la siguiente tabla se lista los interesados que benefician o se ven afectados por la solución propuesta.

Tabla 182.
Registro de interesados
Nombre del Interesado Organización a que Categoría de Nivel de interés Nivel de influencia
pertenece interesado (Bajo, Medio, Alto) (Bajo, Medio, Alto)
Juan Kalenikoff Mandriotti Empresa Retail Patrocinador Alto Alto
Piero Rabanal Empresa Retail Cliente Alto Alto
Alan del Castillo Empresa Retail Usuario Alto Medio
Logística y Abastecimiento Corporativo Empresa Retail Chile Alta Dirección Alto Alto
ADESSA Falabella Entidad reguladora Alto Alto
NTP Indecopi Entidad reguladora Alto Alto
Proveedores de Transporte Terceros Proveedor Alto Medio
Coordinador / Asesor de Tesis UPC Entidad universitaria Alto Alto
Omar Bonarriva UPC / Empresa Retail Director Proyecto Alto Bajo
Omar Bonarriva UPC / Empresa Retail Miembro proyecto Alto Bajo
Harry Bravo UPC Miembro proyecto Alto Bajo

345
9.3 EDT

Figura 110. EDT de Proyecto Informático 1

(Elaboración propia, 2018)

346
Figura 111. EDT de Proyecto Informático 2
(Elaboración propia, 2018)

347
Figura 112. EDT de Proyecto Informático 3
(Elaboración propia, 2018)

348
9.4 Cronograma de Ejecución

Figura 113. Cronograma de ejecución de Proyecto Informático 1 – Página 1

(Elaboración propia, 2018)

349
Figura 114. Cronograma de ejecución de Proyecto Informático 1 – Página 2
(Elaboración propia, 2018)

350
Figura 115. Cronograma de ejecución de Proyecto Informático 1 – Página 3
(Elaboración propia, 2018)

351
Figura 116. Cronograma de ejecución de Proyecto Informático 2 - Página 1
(Elaboración propia, 2018)

352
Figura 117. Cronograma de ejecución de Proyecto Informático 2 - Página 2
(Elaboración propia, 2018)

353
Figura 118. Cronograma de ejecución de Proyecto Informático 3 - Página 1
(Elaboración propia, 2018)

354
Figura 119. Cronograma de ejecución de Proyecto Informático 3 - Página 2
(Elaboración propia, 2018)

355
9.5 Acta de Aceptación de Entregable

Figura 120. Acta de Aceptación Proyecto Informático 1

(Empresa Retail Perú, 2017)

356
Figura 121. Acta de Aceptación Proyecto Informático 2 – Requerimientos del Sistema
(Empresa Retail Perú, 2018)

357
Figura 122. Acta de Aceptación Proyecto Informático 2 – Arquitectura de Software y Prueba de Concepto
(Empresa Retail Perú, 2018)

358
Figura 123. Carta de Aprobación de Tema de Tesis
(Empresa Retail Perú, 2020)

359
Figura 124. Acta de Aceptación Proyecto Informático 3 – Calidad y Prueba de Software
(Empresa Retail Perú, 2018)

360
Figura 125. Acta de Aceptación Proyecto Informático 3 – Patrones de la Solución y Modelo de Datos
(Empresa Retail Perú, 2018)

361
9.6 Gestión de Riesgos
Tabla 183.
Lista de Riesgos
N° Fecha de Riesgo Descripción del Riesgo Probabilidad Impacto Exposición Trigger del Riesgo Respuesta Estrategia Estado
Registro (a) (b) (a * b)
1 07/06/2018 Falta de experiencia en el Debido al escaso tiempo con el 0.6 8 4.80  Solicitud de entregables por Transferir  Investigación de sistemas Activo
uso de la tecnología para su que se cuenta para el desarrollo parte de la UPC. ya desarrollados con el uso
implementación en la de la solución propuesta, existe  Asesorías semanales. de esta tecnología.
solución propuesta. la posibilidad de que el  Desarrollo concienzudo
conocimiento adquirido para el del Benchmarking.
uso de la tecnología propuesta
sea insuficiente.
2 07/06/2018 Retrasos de los entregables Debido al poco tiempo con el 0.4 8 3.20  Solicitud de entregables por Mitigar  Desarrollo de la EDT con Activo
en las fechas planificadas que se cuenta para enviar los parte de la UPC. fechas de entrega.
por mala estimación de entregables, existe la  Asesorías semanales.  Cronograma de ejecución
esfuerzo. posibilidad de que no se actualizado.
dimensione bien los tiempos
requeridos para el desarrollo
total de los puntos a entregar.
3 07/06/2018 Cambios en el alcance del Debido a la cantidad de 0.4 8 3.20  Asesorías semanales. Transferir  Definición inmediata y Activo
proyecto. documentación a desarrollar, clara de las nuevas
así como las pruebas de definiciones y/o alcances,
software previas que se tienen para el desarrollo de las
que realizar, existe la especificaciones y
posibilidad de que haga falta posterior desarrollo.
recursos para el desarrollo del  Aumento en el presupuesto
sistema. de horas hombre para el
desarrollo de módulos
adicionales en el software
propuesto.
4 07/06/2018 Falta de personal para el Debido a la extensa 0.4 6 2.40  Solicitud de entregables por Evitar  Definiciones claras, no da Activo
desarrollo del proyecto. información con la que se parte de la UPC. lugar a supuestos.
trabaja y teniendo en cuenta

362
 que esta se tiene que procesar  Desarrollo concienzudo
en función a fechas de del alcance del proyecto.
entregables, existe la  Tener preparado una
posibilidad de que se tenga que programación con
reducir o aumentar el alcance anticipación.
del proyecto.
5 07/06/2018 Falta de disponibilidad del Debido a la poca información 0.2 10 2.00  Ausencia del cliente en las Evitar  Tener preparado un Activo
cliente en toda la gestión que se le brinda al cliente reuniones programadas. informe detallado del
del proyecto. respecto a los avances del  Solicitud de firma para la avance del proyecto.
desarrollo del proyecto, existe aceptación de los nuevos  Reunirse
la posibilidad de que se pierda entregables. permanentemente con el
el interés por parte del cliente, cliente para conocer su
y en consecuencia hacer expectativa y activar
peligrar la aceptación de los planes correctivos.
próximos entregables.  Informar las calificaciones
obtenidas en el proyecto
dadas por la UPC.

Tabla 184.
Matriz de Riesgos
10 2 4 6 8 10
8 1.6 3.2 4.8 6.4 8
Impacto

6 1.2 2.4 3.6 4.8 6

4 0.8 1.6 2.4 3.2 4
2 0.4 0.8 1.2 1.6 2
0.2 0.4 0.6 0.8 1
Probabilidad

363
9.7 Conclusiones
 Se tuvo un seguimiento y control de las actividades del cronograma de ejecución a
medida que se iba realizando los avances del proyecto, esto permitió detectar a tiempo
un desvío en tiempos, por lo que se tuvo la capacidad de hacer las correcciones necesarias
para no impactar las fechas de entrega.

 La gestión de riesgo permitió visualizar de manera constante y dinámica los posibles

riesgos que puedan impactar en el desarrollo del sistema propuesto, medir el impacto, y
tener a mano una estrategia que permita según sea el caso, mitigar, evitar o transferir el
riesgo de manera oportuna.

 La EDT permitió descomponer de manera detallada los entregables, mantener un orden

y tener una fácil trazabilidad de cada avance que se presenta en el proyecto.

 Las actas de aceptación firmadas por la empresa objeto de estudio han sido pieza clave
para continuar con total confianza y seguridad el desarrollo de los entregables del
proyecto.

364
10 CONCLUSIONES
 El tener bien definido el campo de acción, así como la identificación correcta de los
procesos involucrados y el conocimiento de los sistemas vinculados al campo de acción
nos permitió tener un amplio panorama para poder definir el dimensionamiento que tiene
como alcance el sistema propuesto.

 El Análisis comparativo de la solución nos permite evaluar las diferencias en base a las
funcionalidades de la solución propuesta versus las funcionalidades de otros productos
ofrecidos en el mercado con la finalidad de definir funcionalidades adicionales que deben
considerarse para lograr ventaja, competitividad y satisfacción de las demandas del
mercado.

 A partir del análisis comparativo se concluye que resultaría de gran beneficio tanto
funcional como económico optar por la solución propuesta, ya que permite satisfacer las
necesidades particulares de la empresa Retail y poder alcanzar los objetivos del proyecto
planteados.

 En el diagrama de procesos TO-BE se señalan las actividades candidatas a automatizar,

además de conocer los trabajadores del negocio que las ejecutan y las entidades del
negocio que se manipulan, todo esto colabora con la trazabilidad que debe tener el
proyecto.

 Es necesario tener un seguimiento y control de las actividades del cronograma de

ejecución a medida que se van realizando los avances del proyecto, esto a fin de poder
controlar cualquier desvío en tiempo y recursos dividido por etapas del proyecto.

 La gestión de riesgos es de vital importancia en el desarrollo de un sistema, porque

permite el desarrollo de estrategias a fin de tener los resultados en los tiempos
establecidos.

 La importancia del prototipo es que brinda los detalles del sistema permitiendo al usuario
detectar tempranamente si es en realidad lo que necesita en el sistema, evitando de esta
forma realizar modificaciones sobre un sistema ya instalado.

 Se eligieron las métricas adecuadas para la medición de la calidad de software. Fue

necesario el uso de varias ISO/IEC para poder complementar el plan de calidad de
software.

365
 Al no contar la organización objetivo con una política de calidad, se planteó la necesidad
de proponer un marco que permita elaborar un plan de calidad para que pueda ser
implementado en la organización materia de estudio.

 El trabajo en equipo en el desarrollo de un sistema no es productivo, sino se tiene claro

los objetivos, sino se tienen definidas las responsabilidades, sino se cumplen con el
desarrollo de las actividades asignadas, sino se cumplen los tiempos establecidos, pero,
sobre todo, sino existe un compromiso de todas las partes involucradas con el proyecto.

366
11 GLOSARIO DE TÉRMINOS
Tabla 185.
Glosario de Términos
Nombre Descripción
B
Bulto Conjunto de productos que conforman un pedido armado sobre un
pallet.
C
Carrito de almacén Es el carrito que te permite movilizar la mercadería dentro de la
bodega o nodo.
Controller de tienda Es el encargado de recibir la mercadería que llega a la tienda.
Cuadrilla Es la conformación de un grupo de pickeadores asignados para
preparar los pedidos de una unidad de transporte.
Cubicación Es la ubicación física de los productos dentro de la bodega, nodo
o tienda.
D
Destinatario Es la persona que se le entrega el pedido. Un destinatario puede
ser el cliente o el controller de tienda.
E
Estibadores Es el personal que permite la carga y descarga de mercadería de
las unidades de transporte.
F
Film de seguridad Plástico utilizado en el embalaje de productos.
H
Hoja de ruta Documento en el que constan las instrucciones e incidencias de un
viaje o transporte de pedidos.
L
Logística inversa Proceso de mover mercadería que ha llegado a su destino final a
su punto de origen, con el objetivo de conseguir valor con la
devolución de la mercadería o desecharlo adecuadamente.
M

367
 Nombre Descripción
Muelle de carga Espacio en un edificio o instalación donde se cargan y se
descargan camiones.
Multicanal Se refiere al uso de una pluralidad de canales (tanto tradicionales
como innovadores), variados, interconectados y coherentes entre
sí, utilizados por las empresas para sus actividades de
comunicación, comercialización y servicio a los clientes.
N
Nota de crédito Comprobante que una empresa envía a su cliente para acreditar la
devolución de un valor determinado por el concepto que se indica
en la misma nota.
Nodo Es una tienda que puede cumplir las características de una bodega.
O
Orden de Pedido Es un documento que emite el comprador para pedir mercaderías
al vendedor; indica cantidad, detalle, precio y condiciones de
pago, entre otras cosas.
P
Packing Es el proceso de embalado, empaquetado y envasado de un
producto.
Pallet Es un armazón de madera, plástico u otro material empleado en el
movimiento de carga, ya que facilita el levantamiento y manejo
con grúas hidráulicas, llamadas carretillas elevadoras.
Pickeador Es el personal de la bodega o nodo que se encarga de la
preparación de los pedidos para su despacho.
Picking Es un proceso llevado a cabo en el almacén, cuyo fin es seleccionar
y extraer una serie de productos del almacén y organizarlos en un
lugar específico antes del empaquetado y la entrega de estos a sus
destinatarios.
Pistola de Es un dispositivo periférico que te permite el descuento o aumento
radiofrecuencia de stock de productos.
Plaqueo Proceso de cargar los pedidos a una unidad de transporte que está
identificado con una placa.

368
 Nombre Descripción
Q
Quiebre de stock Es cuando el stock actual del producto es igual a cero.
R
Retail Sector económico que engloba a las empresas especializadas en la
comercialización masiva de productos o servicios uniformes a
grandes cantidades de clientes.
Ruta programada Es el orden de los puntos de entrega y recojo de cada pedido.
S
Sticker de despacho Sticker con código de barra que almacena información de los
pedidos.
T
Tracking de unidades Seguimiento en tiempo real y online del movimiento de las
de transporte unidades de transporte a los puntos destinos.

369
12 SIGLARIO
Tabla 186.
Siglario
Nombre Descripción
D
DAD Despacho a Domicilio.
N
NTP Normas Técnicas Peruanas.
T
TN Toneladas.

370
13 REFERENCIAS
Alur, D., Crupi, J., & Malks, D. (2003). Core J2EE Patterns Best Practices and Design
Strategies (Segunda ed.). California, U.S.A: Prentice Hall.
Apache Software Foundation. (31 de Octubre de 2017). The Composite View Pattern.
Obtenido de [Link]
Beetrack S.A. (2017). Funcionalidades de Beetrack. Obtenido de sitio web de Beetrack:
[Link]
Beltrán López, G. (2016). Geolocalización online: la importancia del dónde. Barcelona:
Editorial UOC.
Blogística. (2020, Junio 7). Etiquetado de Bultos. Retrieved from
[Link]
pallets/
Carro Lupardo, E. (2015). Preparación de pedidos (Transversal). Madrid: Editorial CEP.
Drivin. (2016). [Link] Smart Deliveries: Una solución inteligente para gestionar de manera
óptima tu flota de despachos. Obtenido de sitio web de Drivin:
[Link]
Empresa Retail Perú S.A. (2013). Reporte de Sostenibilidad 2013. Retrieved from Sitio web
de Empresa Retail Perú: [Link]
came_v2.pdf
Empresa Retail Perú S.A. (2018). Nuestra Empresa. Obtenido de sitio web de Empresa
Retail Perú S.A.: [Link]
pe/content/a50057/Informacion-de-nuestra-empresa
Empresa Retail S.A. (2018). ¿Quiénes Somos? Obtenido de sitio web de Empresa Retail:
[Link]
peru
Fowler, M. (23 de Enero de 2004). Inversion of Control Containers and the Dependency
Injection pattern. Obtenido de [Link]
Google LLC. (2018). Firebase. Retrieved from [Link]
Google LLC. (2018). Google Maps API. Obtenido de sitio web de Google Maps Developers:
[Link]
Google LLC. (2018). Mapa de Google. Retrieved from sitio web de Google Maps:
[Link]

371
[Link]. (2018). Retrieved from [Link]:
[Link]
ISO 25000. (2018). Retrieved from [Link]: [Link]
Journal Of Industrial Engineering & Management. (2017). A Granular Tabu Search
Algorithm for a Real Case Study of a Vehicle Routing Problem with a Heterogeneous
Fleet and Time Windows. Journal Of Industrial Engineering & Management, 647-
648.
Logística 360 "The Supply Chain Magazine". (2019, Enero 4). Beetrack: La empresa que
vino a conquistar la última milla. Retrieved from [Link]
empresa-que-vino-a-conquistar-la-ultima-milla/
Luz. (2021). Control de Jornada de Conductor. Retrieved from
[Link]
en-excel-4-0
Mora García, L. A. (2010). Gestión logística integral: las mejores prácticas en la cadena de
abastecimientos. Bogotá: Ecoe Ediciones.
OpenStreetMap. (2017). Map Compare. Retrieved from sitio web de Geofabrik Tools:
[Link]
OpenStreetMap. (2018). Mapa de OpenStreetMap. Retrieved from sitio web de
OpenStreetMap: [Link]
Ragàs Prat, I. (2012). Centros logísticos: planificación, promoción y gestión de los centros
de actividades logísticas. Barcelona: Marge Books.
Retail CRM. (2021, Enero 25). Pedidos. Retrieved from [Link]
Skylabs Solution. (2018). Vehicle Tracking Solution. Obtenido de sitio web de Skylabs
Solution: [Link]
The Founders Systems. (2019, Setiembre 4). Artículo: Entrevista a Fundador de DRIVIN.
Retrieved from [Link]
Txtlocal Ltd. (2018). API SMS. Obtenido de sitio web de Textlocal:
[Link]
Waze Mobile. (2018). LiveMap de Waze. Obtenido de sitio web de Waze:
[Link]
Westfalia Technologies. (2021). Cubicaciones. Retrieved from
[Link]
sistema-de-control-de-almacenes

372
14 ANEXOS
14.1 Matriz de Trazabilidad
A continuación, se presenta la matriz que mapea la trazabilidad de los casos de uso del negocio, la actividad a automatizar, el trabajador del negocio, el requerimiento funcional y el actor del sistema.

Tabla 187.
Matriz de Trazabilidad
Caso de Uso del Actividad a Automatizar Trabajador Requerimiento Funcional Caso de Uso del Sistema Actor del Sistema
Negocio
CUN01_Preparar Notificar solicitud de unidades de TN01_Despachador RF29_Actualizar Proveedor CUS24_Actualizar Proveedor AS11_Proveedor
Pedidos transporte RF30_Actualizar Choferes CUS25_Actualizar Choferes
RF31_Actualizar Unidades Disponibles CUS26_Actualizar Unidades Disponibles
RF08_Notificar Unidades Requeridas CUS08_Notificar Unidades Requeridas AS01_Temporizador

Elaborar hojas de ruta TN01_Despachador RF07_Generar Hojas de Ruta CUS07_Generar Hojas de Ruta AS01_Temporizador
AS12_Servicio de Enrutamiento
Imprimir órdenes de pedido TN01_Despachador RF09_ Generar Pedidos CUS09_Generar Pedidos AS01_Temporizador
Asignar cuadrilla a unidad a hoja de TN01_Despachador RF13_Asignar Cuadrillas a Hoja de Ruta CUS13_Asignar Cuadrillas a Hoja de Ruta AS03_Despachador
ruta
Imprimir cubicación TN01_Despachador RF10_Generar Cubicación de Pedidos CUS10_Generar Cubicación de Pedidos AS01_Temporizador
Notificar producto sin stock a Call TN02_Pickeador RF14_Registrar Productos No Ubicados CUS14_Actualizar Productos No Ubicados AS04_Pickeador
Center
Notificar emisión de nota de crédito TN04_Call Center RF20_Notificar Emisión de Nota de CUS16_Actualizar Atención de Pedido AS06_Call Center
de producto a Contabilidad Crédito
Verificar productos sin stock TN01_Despachador RF12_Notificar Abastecimiento de CUS12_Notificar Abastecimiento de AS01_Temporizador
Notificar compra de productos Productos Productos
Notificar ventana horaria de entrega TN01_Despachador RF11_Notificar Ventanas Horarias CUS11_Notificar Ventanas Horarias AS01_Temporizador
de pedido al destinatario AS14_Servicio de Mensajería
SMS
CUN02_Atender Consultar hoja de ruta TN03_Chofer RF15_Consultar Hoja de Ruta CUS15_Confirmar Despacho de Pedido AS05_Chofer
Pedidos Registrar pedidos como No Atendido TN03_Chofer RF16_Registrar Despacho de Pedido
Verificar existencia de recojo de TN03_Chofer
productos

373
 Caso de Uso del Actividad a Automatizar Trabajador Requerimiento Funcional Caso de Uso del Sistema Actor del Sistema
Negocio
Registrar productos recogidos TN03_Chofer
Verificar existencia de entrega de TN03_Chofer
pedidos
Firmar órdenes de pedido TN05_Aceptante
Verificar tipo de destinatario TN03_Chofer
Registrar pedidos como Entregado a TN03_Chofer
Tienda
Registrar pedidos como Atendido TN03_Chofer
Verificar existencia de pedidos a TN03_Chofer
atender
CUN03_Reprogramar Consultar pedido del cliente TN04_Call Center RF17_Consultar pedidos CUS16_Actualizar Atención de Pedido AS06_Call Center
Pedido Reprogramar pedido TN04_Call Center RF18_Registrar Reprogramación de AS14_Servicio de Mensajería
Verificar pedido en ruta TN04_Call Center Pedido SMS
Validar existencia de productos TN04_Call Center RF21_ Registrar Productos Defectuosos
defectuosos
Registrar productos defectuosos TN04_Call Center
Notificar reprogramación de pedido al TN04_Call Center
chofer
Restar al stock de productos a TN04_Call Center
intercambiar
Validar umbral de stock de productos TN04_Call Center
Verificar fuente de abastecimiento TN04_Call Center
Notificar compra de productos TN04_Call Center
Notificar reposición de productos TN04_Call Center
Validar recojo de productos TN04_Call Center RF22_Programar Devolución de CUS17_Programar Devolución de AS06_Call Center
Programar recojo de productos a TN04_Call Center Productos Productos AS14_Servicio de Mensajería
domicilio SMS
Registrar devolución de productos en TN04_Call Center
tienda
Consultar pedido del cliente TN04_Call Center RF17_Consultar pedidos CUS16_Actualizar Atención de Pedido AS06_Call Center

374
 Caso de Uso del Actividad a Automatizar Trabajador Requerimiento Funcional Caso de Uso del Sistema Actor del Sistema
Negocio
Cancelar pedido TN04_Call Center RF19_Registrar Cancelación de Pedido AS14_Servicio de Mensajería
Verificar pedido en ruta TN04_Call Center SMS
Notificar cancelación de pedido al TN04_Call Center
chofer
Notificar emisión de nota de crédito TN04_Call Center RF20_Notificar Emisión de Nota de
de pedido a contabilidad Crédito
Validar existencia de productos TN04_Call Center RF21_Registrar Productos Defectuosos
CUN04_Cancelar defectuosos
Pedido Registrar productos defectuosos TN04_Call Center
Sumar al stock de productos TN04_Call Center
Verificar entrega de pedido TN04_Call Center
Validar recojo de productos TN04_Call Center RF22_Programar Devolución de CUS17_Programar Devolución de AS06_Call Center
Programar recojo de productos a TN04_Call Center Productos Productos AS14_Servicio de Mensajería
domicilio SMS
Registrar devolución de productos en TN04_Call Center
tienda
CUN05_Controlar Elaborar informe de estado de pedidos TN08_Analista de RF24_Generar Informe de Estado de CUS19_Generar Informe de Estado de AS07_Analista de
Atención de Pedidos Abastecimiento Pedidos Pedidos Abastecimiento
Elaborar informe de ranking de TN08_Analista de RF25_Generar Informe de Ranking de CUS20_Generar Informe de Ranking de AS07_Analista de
proveedores de transporte Abastecimiento Proveedores de Unidades Proveedores de Unidades Abastecimiento
Elaborar informe de productos de TN08_Analista de RF26_Generar Informe de Productos de CUS21_Generar Informe de Productos de AS07_Analista de
mayor rotación Abastecimiento Mayor Rotación Mayor Rotación Abastecimiento
Elaborar informe de abastecimiento TN08_Analista de RF27_Generar Informe de CUS23_Generar Informe de AS07_Analista de
de productos Abastecimiento Abastecimiento de Productos Abastecimiento de Productos Abastecimiento
Elaborar informe de productividad de TN08_Analista de RF28_Generar Informe de Productividad CUS22_Generar Informe de Productividad AS07_Analista de
picking Abastecimiento de Picking de Picking Abastecimiento
CUN06_Reservar Consultar pedido con número de TN01_Despachador RF06_Reservar Pedido CUS06_Reservar Pedido AS10_Batch de Validación de
Inventario reserva Pagos
Registrar pedido TN01_Despachador
Restar al stock de productos TN01_Despachador

375
 Caso de Uso del Actividad a Automatizar Trabajador Requerimiento Funcional Caso de Uso del Sistema Actor del Sistema
Negocio
Validar umbral de stock TN01_Despachador RF32_Validar Stock de Productos CUS27_Validar Stock de Productos AS17_Sistema Web de Ventas
RF33_Consultar Productos sin Stock CUS28_Consultar Productos sin Stock AS17_Sistema Web de Ventas
Verificar fuente de abastecimiento TN01_Despachador RF34_Cargar Productos a Bodega o CUS29_Cargar Productos a Bodega o AS03_Despachador
Notificar compra de producto TN01_Despachador Nodo Nodo
Notificar reposición de producto TN01_Despachador
CUN07_Monitorear Monitorear salida de unidades de TN09_Monitoreador RF23_Monitorear Despacho de Pedidos CUS18_Monitorear Despacho de Pedidos AS08_Monitoreador
Atención de Pedidos transporte de la bodega AS13_Servicio de Tracking
Monitorear adherencia a la ruta TN09_Monitoreador
programada de las unidades de
transporte
Calcular tiempo aproximado de TN09_Monitoreador
llegada del pedido a solicitud del
cliente
Monitorear estados de pedidos TN09_Monitoreador
asignados a cada unidad de transporte
Monitorear llegada de unidades de TN09_Monitoreador
transporte a la bodega

376
14.2 Misceláneas

Figura 126. Web de Consulta de Pedidos

(Retail CRM, 2021)

Figura 127. Web de Detalle de Pedidos

(Retail CRM, 2021)

377
 Figura 128. Web de Orden de Pedido
(Elaboración Propia, 2021)

Figura 129. Web de Cubicaciones de Productos

(Westfalia Technologies, 2021)

378
Figura 130. Sticker de Despacho
(Blogística, 2020)

Figura 131. Hoja de Ruta

(Luz, 2021)

379