UNIVERSIDAD ANDINA DEL CUSCO
FACULTAD DE INGENIERÍA Y ARQUITECTURA
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS
IMPLEMENTACIÓN DEL MÓDULO MRP DEL SISTEMA ERP OPEN SOURCE ODOO
EN LA EMPRESA CERÁMICAS KANTU S.A.C.
TESIS PRESENTADO POR:
BACH. MEJIA MATEUS, LUIS RODRIGO
BACH. ARCE USCACHI, BRAJEAN WALTHER
PARA OBTENER EL TÍTULO PROFESIONAL DE
INGENIERO DE SISTEMAS
ASESOR:
MG. ING. VANESSA MARIBEL CHOQUE SOTO
CUSCO – PERÚ
2020
Índice general
Índice de Figuras ............................................................................................................. 5
Índice de Tablas .............................................................................................................. 8
Introducción ................................................................................................................... 12
Resumen ....................................................................................................................... 13
Abstract ......................................................................................................................... 14
Capítulo I: Problema de investigación ........................................................................... 15
1.1. Ámbito de influencia ......................................................................................... 15
1.1.1. Ámbito de influencia teórica. ...................................................................... 15
1.1.2. Área de dominio ......................................................................................... 15
1.1.3. Línea de investigación ............................................................................... 15
1.2. Planteamiento del problema ............................................................................. 16
1.2.1. Descripción de la situación actual .............................................................. 16
1.2.1.1. Organización ....................................................................................... 16
1.2.1.2. Administración ..................................................................................... 17
1.2.1.3. Tecnología de la información .............................................................. 17
1.2.2. Descripción del problema........................................................................... 18
1.2.3. Formulación del problema.......................................................................... 18
1.2.4. Objetivos .................................................................................................... 18
Objetivo general ................................................................................................... 18
Objetivos específicos ........................................................................................... 19
1.2.5. Justificación de la investigación ................................................................. 19
1.2.6. Alcances y limitaciones .............................................................................. 20
Capítulo II: Marco Teórico ............................................................................................. 21
2.1. Antecedentes de la tesis .................................................................................. 21
1
2.1.1. Antecedentes Nacionales .......................................................................... 21
2.1.2. Antecedentes Internacionales .................................................................... 22
2.2. Bases teórico científicas ................................................................................... 24
2.2.1. Open source .............................................................................................. 24
2.2.2. ERP ........................................................................................................... 26
2.2.3. Odoo .......................................................................................................... 33
2.2.4. MRP ........................................................................................................... 35
2.2.5. Características MRP Odoo ........................................................................ 37
2.2.6. Python ........................................................................................................ 39
2.2.7. Javascript ................................................................................................... 40
2.2.8. Xml ............................................................................................................. 40
2.2.9. Arquitectura de software ............................................................................ 41
2.2.10. Programación extrema ........................................................................... 43
2.2.11. Node.js ................................................................................................... 46
2.2.12. QuaggaJS ............................................................................................... 47
2.2.13. Conceptos esenciales de desarrollo en Odoo ........................................ 48
Capítulo III: Desarrollo, Implementación o Transferencia Tecnológica .......................... 53
3.1. Configuración del entorno de desarrollo ........................................................... 53
3.2. Historias de usuario .......................................................................................... 54
3.3. Plan de entrega del proyecto ............................................................................ 60
3.4. Cronograma de implementación del proyecto .................................................... 1
3.5. Diagrama de clases ............................................................................................ 2
3.6. Ciclo de vida ....................................................................................................... 5
3.6.1. Primera iteración .......................................................................................... 5
3.6.1.1. Tareas de ingeniería ............................................................................. 5
2
3.6.1.2. Descripción tareas de ingeniería ........................................................... 5
3.6.1.3. Pruebas de aceptación .......................................................................... 7
3.6.2. Segunda iteración ...................................................................................... 14
3.6.2.1. Tareas de Ingeniería ........................................................................... 14
3.6.2.2. Descripción tareas de ingeniería ......................................................... 15
3.6.2.3. Pruebas de aceptación ........................................................................ 17
3.6.3. Tercera iteración ........................................................................................ 23
3.6.3.1. Tareas de ingeniería ........................................................................... 23
3.6.3.2. Descripción tareas de ingeniería ......................................................... 23
3.6.3.3. Pruebas de aceptación ........................................................................ 26
3.6.4. Cuarta iteración .......................................................................................... 34
3.6.4.1. Tareas de ingeniería ........................................................................... 34
3.6.4.2. Descripción tareas de ingeniería ......................................................... 35
3.6.4.3. Pruebas de aceptación ........................................................................ 39
3.6.5. Quinta iteración .......................................................................................... 48
3.6.5.1. Tareas de ingeniería ........................................................................... 48
3.6.5.2. Descripción tareas de ingeniería ......................................................... 48
3.6.5.3. Pruebas de aceptación ........................................................................ 52
3.6.6. Sexta iteración ........................................................................................... 54
3.6.6.1. Tareas de ingeniería ........................................................................... 54
3.6.6.2. Descripción tareas de ingeniería ......................................................... 54
3.6.6.3. Pruebas de aceptación ........................................................................ 56
Capítulo IV: Resultados ................................................................................................. 58
4.1. Comprobación de la prospectiva ......................................................................... 58
4.2. Cumplimiento de objetivos .................................................................................. 69
3
4.3. Contribuciones (impacto)..................................................................................... 70
Conclusiones ................................................................................................................. 72
Recomendaciones ......................................................................................................... 73
Bibliografía ..................................................................................................................... 74
Anexos........................................................................................................................... 78
4
Índice de Figuras
Ilustración 1. Una empresa donde todas las áreas saben lo que los otros hacen ......... 27
Ilustración 2. Mundo real y el modelo de negocios ........................................................ 32
Ilustración 3. Arquitectura de red de odoo ..................................................................... 33
Ilustración 4. Alcance del negocio y cuan amigable es para el usuario de diferentes
software ERP ................................................................................................................. 35
Ilustración 5. Procesos de ciclo de vida según norma ISO 12207 ................................. 42
Ilustración 6. Estructura de archivos básico de un módulo Odoo .................................. 49
Ilustración 7. Vista Lista de controles de acceso ........................................................... 52
Ilustración 8. Cronograma de implementación del proyecto ............................................ 1
Ilustración 9. diagrama de clases .................................................................................... 2
Ilustración 10: Diagrama de despliegue de odoo ............................................................. 4
Ilustración 11. Pantalla de inicio de sesión ...................................................................... 9
Ilustración 12. Vista en modo lista de los usuarios del sistema ..................................... 10
Ilustración 13. Vista formulario para la creación de un nuevo usuario ........................... 10
Ilustración 14. Vista formulario de un usuario creado y mensaje de alerta del email
enviado al correo del usuario ......................................................................................... 11
Ilustración 15. Configuración de los niveles de acceso por usuario a los módulos del ERP.
...................................................................................................................................... 11
Ilustración 16. Vista en modo kanban de los productos creados ................................... 12
Ilustración 17. Vista formulario para la creación de un nuevo producto......................... 12
Ilustración 18. Vista formulario para la configuración de las características de fabricación
de un producto ............................................................................................................... 13
Ilustración 19. Vista en modo lista de los servicios de pago .......................................... 13
Ilustración 20. Vista formulario para la creación de un nuevo servicio de pago ............ 14
Ilustración 21. Vista en modo lista de los centros de producción .................................. 20
Ilustración 22. Vista formulario para la creación de un nuevo centro de producción ..... 20
Ilustración 23. Vista en modo lista de las rutas de producción ...................................... 21
Ilustración 24. Vista formulario para la creación de una nueva ruta de producción ....... 21
Ilustración 25. Vista en modo lista de las listas de materiales ....................................... 22
Ilustración 26. Vista formulario para la creación de una nueva lista de materiales ........ 22
5
Ilustración 27. Vista modo lista de las ordenes de producción ...................................... 30
Ilustración 28. Vista modo formulario para la creación y edición de las ordenes de
producción ..................................................................................................................... 30
Ilustración 29. Ventana modal para la importación del detalle de la orden de producción
desde un archivo Excel.................................................................................................. 31
Ilustración 30. Vista modo lista con la barra de progreso del detalle de las ordenes de
producción ..................................................................................................................... 31
Ilustración 31. Vista modo calendario de las fichas de producción planificadas ............ 32
Ilustración 32. Ventana modal de la vista calendario para la planificación de una nueva
ficha de producción ....................................................................................................... 32
Ilustración 33. Vista en modo lista con la barra de progreso de las fichas de producción
planificadas .................................................................................................................... 33
Ilustración 34. Vista en modo formulario de una ficha de producción creada y planificada
...................................................................................................................................... 33
Ilustración 35. Vista lista de las ordenes de trabajo generadas por una ficha de producción
planificada ..................................................................................................................... 42
Ilustración 36. Vista formulario de una orden de trabajo generada desde una ficha de
producción planificada ................................................................................................... 42
Ilustración 37. Interfaz principal para los operarios, que permite escanear el código de
barras mediante un lector de código de barras ............................................................. 43
Ilustración 38. Interfaz que muestra las ordenes de trabajo agrupadas por centro de
producción, mostradas al escanear una ficha de producción ........................................ 43
Ilustración 39. Interfaz que permite registrar la acción a realizar en la orden de trabajo 44
Ilustración 40. Interfaz para dispositivos móviles que detecta la cámara del dispositivo
para usarlo con lector de código de barras.................................................................... 44
Ilustración 41. Interfaz para dispositivos móviles que permite enfocar y escanear el código
de barras de la ficha de producción ............................................................................... 45
Ilustración 42. Interfaz para dispositivos móviles que muestra las ordenes de trabajo
disponibles para su ejecución ........................................................................................ 45
Ilustración 43. Interfaz para dispositivos móviles que permite el registro de la acción de
una orden de trabajo...................................................................................................... 46
6
Ilustración 44. Ventana modal en las ordenes de trabajo, para el registro de merma. .. 46
Ilustración 45. Vista formulario de una orden de trabajo con una merma registrada. .... 47
Ilustración 46. Vista en modo lista de las mermas registradas en una orden de trabajo.
...................................................................................................................................... 47
Ilustración 47. Vista kanban del tablero de control que muestra la información en tiempo
real del estado de las ordenes de trabajo agrupados por centro de producción ........... 50
Ilustración 48. Vista en modo lista de las ordenes de trabajo listas para la supervisión.50
Ilustración 49. Vista formulario de una orden de trabajo lista para la supervisión. ........ 51
Ilustración 50. Vista pivot que muestra el reporte de productividad ............................... 51
Ilustración 51. Vista pivot con el reporte de pagos por centros de trabajo y personal ... 55
Ilustración 52. Vista pivot del reporte de pagos por centros de trabajo y fichas de
producción ..................................................................................................................... 56
Ilustración 53: Pregunta nro 1 ........................................................................................ 64
Ilustración 54: Pregunta nro 2 ........................................................................................ 64
Ilustración 55: Pregunta nro 3 ........................................................................................ 65
Ilustración 56: Pregunta nro 4 ........................................................................................ 65
Ilustración 57: Pregunta nro 5 ........................................................................................ 66
Ilustración 58: Pregunta nro 6 ........................................................................................ 66
Ilustración 59: Pregunta nro 7 ........................................................................................ 67
Ilustración 60: Pregunta nro 8 ........................................................................................ 67
Ilustración 61: Pregunta nro 9 ........................................................................................ 68
Ilustración 62: Pregunta nro 10 ...................................................................................... 68
Ilustración 63: Capacitacion al personal de produccion ................................................. 78
Ilustración 64: Equipo para los operarios de planta para el registro de las ordenes de
trabajo............................................................................................................................ 79
7
Índice de Tablas
Tabla 1: Resumen de las iteraciones............................................................................. 53
Tabla 2 Historia de usuario creación de permisos y grupos de usuario ........................ 55
Tabla 3 Historia de usuario gestión de productos y servicios ........................................ 55
Tabla 4 Historia de usuario gestión de centros y rutas de producción .......................... 56
Tabla 5 historia de usuario gestión de lista de materiales por producto ........................ 56
Tabla 6 historia de usuario gestión de órdenes de producción ...................................... 57
Tabla 7 historia de usuario planificación de fichas de producción ................................. 57
Tabla 8 historia de usuario registro de las ordenes de trabajo ...................................... 58
Tabla 9 historia de usuario registro de merma .............................................................. 58
Tabla 10 historia de usuario supervisión de las ordenes de trabajo .............................. 58
Tabla 11 historia de usuario reporte de productividad ................................................... 59
Tabla 12 historia de usuario reporte de pago a los operarios ........................................ 59
Tabla 13 plan de entrega del proyecto .......................................................................... 60
Tabla 14 Historias de usuario primera iteración .............................................................. 5
Tabla 15 Tareas de ingeniería primera iteración ............................................................. 5
Tabla 16 Tarea de ingeniería 1 para historia de usuario 1 .............................................. 5
Tabla 17 Tarea de ingeniería 2 para historia de usuario 1 .............................................. 6
Tabla 18 tarea de ingeniería 3 para la historia de usuario 2 ............................................ 6
Tabla 19 tarea de ingeniería 4 para la historia de usuario 2 ............................................ 6
Tabla 20. pruebas de aceptación de las historias de usuario 1 y 2 ................................. 7
Tabla 21. Caso de prueba número 1 para la historia de usuario administración de
permisos y grupos de usuario .......................................................................................... 7
Tabla 22. Caso de prueba número 2 para la historia de usuario administración de
permisos y grupos de usuario .......................................................................................... 7
Tabla 23. Caso de prueba número 3 para la historia de usuario administración de
permisos y grupos de usuario .......................................................................................... 8
Tabla 24. Caso de prueba número 4 para la historia de usuario Gestión de productos y
servicios ........................................................................................................................... 8
Tabla 25. Historias de usuario segunda iteración .......................................................... 14
Tabla 26. Tareas de ingeniería segunda iteración ......................................................... 14
8
Tabla 27. Tarea de ingeniería 5 para la historia de usuario 3........................................ 15
Tabla 28. Tarea de ingeniería 6 para la historia de usuario 3........................................ 15
Tabla 29. Tarea de ingeniería 7 para la historia de usuario 4........................................ 16
Tabla 30. Tarea de ingeniería 8 para la historia de usuario 4........................................ 16
Tabla 31. Tarea de ingeniería 9 para la historia de usuario 4........................................ 16
Tabla 32. Pruebas de aceptación segunda iteración ..................................................... 17
Tabla 33. Caso de prueba 1 para la historia de usuario 3 ............................................. 17
Tabla 34. Caso de prueba 2 para la historia de usuario 3 ............................................. 18
Tabla 35. Caso de prueba 3 para la historia de usuario 3 ............................................. 18
Tabla 36. Caso de prueba 4 para la historia de usuario 4 ............................................. 19
Tabla 37. Caso de prueba 5 para la historia de usuario 4 ............................................. 19
Tabla 38. Historias de usuario tercera iteración ............................................................ 23
Tabla 39. Tareas de ingeniería tercera iteración ........................................................... 23
Tabla 40. Tarea de ingeniería 10 para historia de usuario 5 ......................................... 23
Tabla 41. Tarea de ingeniería 11 para historia de usuario 5 ......................................... 24
Tabla 42. Tarea de ingeniería 12 para historia de usuario 5 ......................................... 24
Tabla 43. Tarea de ingeniería 13 para historia de usuario 5 ......................................... 24
Tabla 44. Tarea de ingeniería 14 para historia de usuario 6 ......................................... 25
Tabla 45. Tarea de ingeniería 15 para historia de usuario 6 ......................................... 25
Tabla 46. Tarea de ingeniería 16 para historia de usuario 6 ......................................... 25
Tabla 47. Tarea de ingeniería 17 para historia de usuario 6 ......................................... 26
Tabla 48. Pruebas de aceptación tercera iteración ....................................................... 26
Tabla 49. Caso de prueba 1 para historia de usuario 5 ................................................. 27
Tabla 50. Caso de prueba 2 para historia de usuario 5 ................................................. 27
Tabla 51. Caso de prueba 3 para historia de usuario 6 ................................................. 28
Tabla 52. Caso de prueba 4 para historia de usuario 5 ................................................. 28
Tabla 53. Caso de prueba 5 para historia de usuario 6 ................................................. 29
Tabla 54. Caso de prueba 6 para historia de usuario 6 ................................................. 29
Tabla 55. Historias de usuario cuarta iteración .............................................................. 34
Tabla 56. Tareas de ingeniería cuarta iteración ............................................................ 34
Tabla 57. Tarea de ingeniería 18 para historia de usuario 7 ......................................... 35
9
Tabla 58. Tarea de ingeniería 19 para historia de usuario 7 ......................................... 35
Tabla 59. Tarea de ingeniería 20 para historia de usuario 7 ......................................... 35
Tabla 60. Tarea de ingeniería 21 para historia de usuario 7 ......................................... 36
Tabla 61. Tarea de ingeniería 22 para historia de usuario 7 ......................................... 36
Tabla 62. Tarea de ingeniería 23 para historia de usuario 7 ......................................... 37
Tabla 63. Tarea de ingeniería 24 para historia de usuario 7 ......................................... 37
Tabla 64. Tarea de ingeniería 25 para historia de usuario 7 ......................................... 37
Tabla 65. Tarea de ingeniería 26 para historia de usuario 8 ......................................... 38
Tabla 66. Tarea de ingeniería 27 para historia de usuario 8 ......................................... 38
Tabla 67. Tarea de ingeniería 28 para historia de usuario 8 ......................................... 38
Tabla 68. Tarea de ingeniería 29 para historia de usuario 8 ......................................... 39
Tabla 69. Pruebas de aceptación cuarta iteración ......................................................... 39
Tabla 70. Caso de prueba 1 para historia de usuario 7 ................................................. 39
Tabla 71. Caso de prueba 2 para historia de usuario 7 ................................................. 40
Tabla 72. Caso de prueba 3 para historia de usuario 7 ................................................. 40
Tabla 73. Caso de prueba 4 para historia de usuario 8 ................................................. 41
Tabla 74. Historias de usuario quinta iteración .............................................................. 48
Tabla 75. Tareas de ingeniería quinta iteración ............................................................. 48
Tabla 76. Tarea de ingeniería 30 para historia de usuario 9 ......................................... 48
Tabla 77. Tarea de ingeniería 31 para historia de usuario 9 ......................................... 49
Tabla 78. Tarea de ingeniería 32 para historia de usuario 10 ....................................... 49
Tabla 79. Tarea de ingeniería 33 para historia de usuario 10 ....................................... 49
Tabla 80. Pruebas de aceptación quinta iteración ......................................................... 52
Tabla 81. Caso de prueba 1 para historia de usuario 9 ................................................. 52
Tabla 82. Caso de prueba 2 para historia de usuario 9 ................................................. 52
Tabla 83. Caso de prueba 3 para historia de usuario 10 ............................................... 53
Tabla 84. Historias de usuario sexta iteración ............................................................... 54
Tabla 85. Tareas de ingeniería sexta iteración .............................................................. 54
Tabla 86. Tarea de ingeniería 34 para historia de usuario 11 ....................................... 54
Tabla 87. Tarea de ingeniería 35 para historia de usuario 11 ....................................... 55
Tabla 88. Pruebas de aceptación sexta iteración .......................................................... 56
10
Tabla 89. Caso de prueba 1 para historia de usuario 11 ............................................... 56
Tabla 90. Tabla de factibilidad técnica........................................................................... 58
Tabla 91. Tabla de recurso humano .............................................................................. 59
Tabla 92. Tabal de recurso tecnológico ......................................................................... 60
Tabla 93. Pregunta nro. 1 .............................................................................................. 61
Tabla 94. Pregunta nro. 2 .............................................................................................. 61
Tabla 95. Pregunta nro. 3 .............................................................................................. 61
Tabla 96. Pregunta nro. 4 .............................................................................................. 62
Tabla 97. Pregunta nro. 5 .............................................................................................. 62
Tabla 98. Pregunta nro. 6 .............................................................................................. 62
Tabla 99. Pregunta nro. 7 .............................................................................................. 63
Tabla 100. Pregunta nro. 8 ............................................................................................ 63
Tabla 101. Pregunta nro. 9 ............................................................................................ 63
Tabla 102. Pregunta nro. 10 .......................................................................................... 63
11
Introducción
El entorno tan competitivo del sector empresarial, ha obligado a las empresas a tomar
decisiones drásticas con respecto a la gestión de sus operaciones y a la integración de
sus áreas funcionales. La importancia de contar con una herramienta informática que
ayude a ejecutar estas acciones, viene siendo factor de éxito para alcanzar sus metas.
Los ERP (Enterprise Resource Planning) surgen como respuesta a la necesidad de
facilitar la gestión de todos los recursos de una empresa, a través de la integración de la
información de sus distintos departamentos.
El ERP Odoo es un software de gestión para la plataforma web de código abierto, que
más allá de ser un ERP, ofrece una plataforma de desarrollo con un conjunto de
herramientas que hacen posible un desarrollo ágil, mantenible y escalable, permitiendo
su implementación y adaptación en organizaciones de distintos rubros, mediante el
desarrollo de módulos complementarios que modifican la funcionalidad original del
sistema sin la necesidad de alterar su código fuente, como también la posibilidad de
desarrollar aplicaciones completas desde cero dentro de la plataforma.
La presente investigación pretende la implementación del ERP Odoo con un enfoque
principal es su módulo de Planeación de requerimientos de materiales (MRP o Material
Requirements Planning en inglés), comprendiendo también la instalación de módulos
adicionales que se especifiquen como dependencias para su funcionamiento; tal es el
caso del módulo de Inventarios y el de Empleados; con la finalidad de integrar la
comunicación de las áreas involucradas en el proceso productivo como también llevar un
mejor control de los productos tanto materias primas como productos finales, y a su vez
poder soportar posibles cambios en las estructuras de rutas y procesos productivos de la
empresa.
12
Resumen
El proceso productivo de la empresa Cerámicas Kantu SAC es administrado por un
sistema poco amigable que no soporta todas las líneas de producción, no permite el
registro de las operaciones en cada centro de producción, tampoco existe una integración
con las áreas de ventas ni logística, áreas importantes en todo el proceso productivo.
La pregunta que la presente tesis plantea es: ¿Cómo implementar una solución integral
para los procesos de producción a través de un MRP? Tomando en cuenta esto el
objetivo del presente trabajo es implementar el ERP Odoo, específicamente el módulo
MRP y sus dependencias (Inventario, Ventas), como también el desarrollar un módulo de
personalización que nos permita adaptar las particularidades del modelo de negocio con
el fin de administrar todo el proceso productivo de manera integral y que permita al área
de producción tener la información en tiempo real para llevar un control y análisis más
optimizado.
La metodología de desarrollo seleccionada para este proyecto es la de programación
extrema ya que dicha metodología presenta más énfasis en la adaptabilidad, basándose
en la simplicidad, comunicación y la retroalimentación del código desarrollado, a través
del uso de iteraciones e historias de usuario.
En base a la investigación realizada en la presente tesis se concluye que el Mrp del ERP
Odoo es bastante flexible para adaptarse a los requerimientos de los usuarios, además
de ser multiplataforma (ya que el acceso al sistema es vía web), así los usuarios tienen
la facilidad de acceder al sistema desde cualquier dispositivo que tenga un navegador
web incluido. El Mrp muestra información en tiempo real del trabajo de producción y el
estado de estos, además de que el sistema es atractivo para los usuarios lo que facilita
la entrega de información para estos.
13
Abstract
The production process of the company Cerámicas Kantu SAC is managed by an
unfriendly system that does not support all production lines, does not allow the registration
of operations in each production center, there is also no integration with the sales or
logistics areas, important areas in the entire production process.
The question that this thesis raises is: How to implement a comprehensive solution for
production processes through an MRP? Taking this into account, the objective of this work
is to implement the ERP Odoo, specifically the MRP module and its dependencies
(Inventory, Sales), as well as developing a customization module that allows us to adapt
the particularities of the business model in order to manage the entire production process
in a comprehensive way and that allows the production area to have information in real
time to carry out more control and analysis optimized.
The development methodology selected for this project is that of extreme programming
since this methodology presents more emphasis on adaptability, based on simplicity,
communication and feedback of the developed code, through the use of iterations and
user stories.
Based on the research carried out in this thesis, it is concluded that the ERP Odoo Mrp is
quite flexible to adapt to the requirements of the users, in addition to being multiplatform
(since access to the system is via the web), so users have the ease of accessing the
system from any device that has a web browser included. The Mrp shows information in
real time of the production work and their status, in addition to the fact that the system is
attractive to users, which facilitates the delivery of information for them.
14
Capítulo I: Problema de investigación
1.1. Ámbito de influencia
1.1.1. Ámbito de influencia teórica.
La presente investigación pretende la implementación del módulo MRP Odoo y su
correcta adaptación a los procesos de la empresa, por lo que se desarrollarán
módulos complementarios que sirvan de intermediarios para su correcta integración
evitando la alteración y/o modificación del código fuente, en consecuencia, se
necesitan buenos conocimientos de los lenguajes de programación Javascript y
Python, como también tener pensamiento computacional y la capacidad de entender
y desarrollar algoritmos.
1.1.2. Área de dominio
El ámbito de desarrollo de la presente investigación se basa en la programación y
codificación de algoritmos que permitan el procesamiento correcto de los datos
generados en la empresa, por lo que se concluye que la investigación pertenece al
área de dominio de Tecnologías de la información.
1.1.3. Línea de investigación
El desarrollo modular complementario que ofrece Odoo, supone conocimientos
sólidos por parte de los desarrolladores, en patrones de diseño de software,
situando en primer lugar la programación orientada a objetos como también la
aplicación de buenas prácticas de desarrollo de software. Evaluando este contexto
se concluye que la presente investigación pertenece a la línea de investigación de
Desarrollo de Software.
15
1.2. Planteamiento del problema
1.2.1. Descripción de la situación actual
La empresa Cerámicas Kantu S.A.C. es una empresa industrial cusqueña dedicada
a la fabricación de lístelos y complementos decorativos hechos de cerámica,
porcelanato, mármol y vidrio.
Actualmente, la empresa cuenta con un sistema de producción desarrollado por el
personal interno del área de sistemas, dicho sistema está desarrollado con el
lenguaje de programación Microsoft Visual Basic bajo la plataforma ASP.Net,
persistiendo y consumiendo datos al gestor de base de datos Microsoft Mssql Server.
El sistema web desarrollado por el área de sistemas permite el registro de la
planificación de producción y la información de los procesos operacionales que se
ejecutan en las diferentes líneas productivas que siguen los productos, que en un
inicio era uno, pero con el tiempo y el crecimiento de la empresa, se comenzaron a
fabricar más productos que requerían distintas rutas y procesos a lo inicialmente
planteado, estos cambios obligaron al personal del área de sistemas adaptar estas
rutas y procesos en el sistema con lo cual el sistema fue sufriendo cambios y
evolucionando según los requerimientos operacionales del área de producción.
Conjuntamente con la planificación de producción en el sistema actual, se lleva
consigo un registro físico denominado ficha de producción, que contiene la
información de los procesos por los que pasa un determinado producto, la cantidad
de piezas a producir, el personal que trabajó en cada proceso como también las
posibles mermas que se pudieran producir en el transcurso del proceso, la
información de esta ficha solo podrá ser ingresada en el sistema cuando se haya
culminado todo el proceso productivo del producto planificado.
1.2.1.1. Organización
Los diferentes niveles y áreas de la empresa cerámicas Kantu S.A.C. crean distintos
intereses y puntos de vista. Estas opiniones a menudo entran en conflicto en cuanto a la
forma en la que debe operar la empresa y como se deben distribuir los recursos. Los
16
sistemas de información en este caso el módulo Mrp del ERP Odoo surge como solución
a las diferentes perspectivas, conflictos, compromisos y acuerdos que son parte natural
de las organizaciones.
1.2.1.2. Administración
El trabajo de la gerencia es dar sentido a las distintas situaciones a las que se enfrentan
las organizaciones, tomar decisiones y formular planes de acción para resolver los
problemas organizacionales. En este caso la gerencia de nivel superior toma la decisión
de adoptar un sistema de información que en este caso es el ERP Odoo gracias a la
recomendación de la gerencia de nivel medio por los conocimientos adquiridos, esta
tecnología puede desempeñar un rol importante para ayudar a la organización a diseñar
y ofrecer nuevos productos y servicios.
1.2.1.3. Tecnología de la información
La tecnología de la información es una de las diversas herramientas que utilizan los
gerentes para enfrentar el cambio. El hardware de computadora es el equipo físico que
se utiliza para las actividades de entrada, procesamiento y salida en un sistema de
información y consiste en lo siguiente: computadoras de diversos tamaños y formas;
varios dispositivos de entrada, salida y almacenamiento, y dispositivos de
telecomunicaciones que conectan a las computadoras entre sí.
El software de computadora, consiste en las instrucciones detalladas y reprogramadas
que controlan y coordinan los componentes de hardware de computadora en un sistema
de información. En este caso sería el módulo Mrp implementado en el área de producción.
La tecnología de administración de datos, consiste en el software que gobierna la
organización de los datos en medios de almacenamiento físico. En este caso sería el
ERP Odoo.
17
La tecnología de redes y telecomunicaciones, consiste tanto en los dispositivos físicos
como en el software, conecta las diversas piezas de hardware y transfiere datos de una
ubicación física a otra. En este caso tenemos: smartphones, lectores de barras,
computadoras de escritorio, laptops, mini PCs, monitores táctiles, etc.
1.2.2. Descripción del problema
La forma de trabajo no ofrece información en tiempo real ya que el sistema se
alimenta de esta información al final del proceso de producción, siendo imposible
saber el estado o el proceso actual de una ficha de producción, sumado a esta
carencia del sistema, el área de producción tiene la tediosa tarea de registrar los
datos de las ficha de producción que llegan a acumularse en grandes cantidades,
conduciendo a constantes errores en el registro de la información, obligando al área
de sistemas a realizar correcciones a nivel de base de datos, poniendo en riesgo la
integridad de los datos y la veracidad de los mismos.
1.2.3. Formulación del problema
¿Cómo implementar una solución integral para los procesos de producción a través
de un MRP?
1.2.4. Objetivos
Objetivo general
Implementar el módulo MRP del ERP Odoo en el área de producción de la
empresa Cerámicas Kantu S.A.C.
18
Objetivos específicos
1. Optimizar la planificación de los procesos de fabricación mediante el módulo MRP.
2. Controlar el consumo de materiales e insumos necesarios para la producción
mediante el módulo MRP.
3. Desarrollar un módulo complementario que permita la extensión y modificación de
la estructura estándar del módulo MRP, para el soporte integral de los procesos
de negocio del área de producción.
1.2.5. Justificación de la investigación
La implementación del ERP Open Source Odoo, enfocado esencialmente en su
aplicación MRP y dependencias necesarias, en conjunto con el desarrollo del módulo
adaptativo, es pertinente dentro del contexto de las acuciantes problemáticas
suscitadas en el control productivo de la empresa Cerámicas Kantu SAC, donde la
información en tiempo real de cada proceso productivo, el control de insumos y
materias primas consumidas y el registro de las operaciones llevadas a cabo por los
operarios en cada área de trabajo permitirán un mejor análisis de la eficiencia de
operaciones en la planta.
La plataforma de desarrollo ofrecida por Odoo para la construcción de nuevos
módulos para el ERP, opera como un factor relevante para su implementación, brinda
la posibilidad de modificar módulos existentes o la creación de una aplicación
completa, viabilizando su adaptación a cualquier rubro empresarial. Al ser articulada
por módulos o aplicaciones permite un crecimiento a necesidad pudiendo empezar
operaciones con una sola aplicación e ir añadiendo o eliminando otras según lo
requiera.
A través de la implementación del módulo MRP y el desarrollo de un módulo
complementario para su adaptación a los procesos productivos, se da a conocer las
características técnicas y funcionales con las que cuenta Odoo, sirviendo de
referencia base para su posible integración en todas las áreas de la empresa.
19
1.2.6. Alcances y limitaciones
El presente proyecto pretende el reemplazo integral del actual sistema de producción en
la empresa Cerámicas Kantu S.A.C., mediante la implementación del ERP Odoo, con
enfoque principal en su módulo MRP en conjunto con los módulos que son requeridos
para el funcionamiento del mismo, tales son el caso de los módulos de Inventarios y
Empleados, que forman parte del paquete gratuito de la versión community.
Mediante esta implementación de busca una administración integral de la información de
todo el proceso productivo, que parte desde la salida de materiales e insumos de los
almacenes, seguido del conjunto de operaciones realizadas por las distintas áreas de
producción, hasta el ingreso de los productos terminados a los almacenes. Dentro de
todo este proceso productivo se estarán integrando el área de ventas, encargada de
registrar las ordenes de producción, el área de logística y almacén, encargados del
suministro de materiales y almacenamiento de productos terminados y el área de
producción que involucra a todos los centros de producción existentes para la fabricación
de un producto determinado.
Para este proyecto, la implementación del módulo de Inventario abarcara únicamente la
función de control de ingreso y salida de bienes, mas no el control de stock de bienes. Se
deja a disposición al área de sistemas la posibilidad de la implementación integral del
módulo de Inventario en un futuro.
20
Capítulo II: Marco Teórico
2.1. Antecedentes de la tesis
2.1.1. Antecedentes Nacionales
(Llanos, 2017)
1. La presente investigación se realizó con el objetivo de determinar cuan efectivo es
el desempeño de los procesos de negocio de la Agroveterinaria la Fortaleza S.R.L.
de la ciudad de Cajamarca con un sistema de Planificación de Recursos
Empresariales llamado Odoo implementando bajo la metodología IPEE. Se analizó
el estado actual de la empresa, determinándose que no posee sistema de
información, así pues, todas las tareas realizadas eran manuales generando estos
inconvenientes al momento de la toma de decisiones debido a que no se tiene una
información organizada e íntegra.
Conclusión
Para determinar la efectividad que produce el sistema se comparó todos los
aspectos evaluados tanto el tiempo de ejecución de los procesos antes y después
de la propuesta aplicada, así como las encuestas en cuestión a la adaptabilidad y
de su aprendizaje del usuario respecto del sistema. Logrando determinar que el
tiempo de desempeño de los procesos se ha reducido en un 73%, un 23% más
del objetivo buscado. Asimismo, con las medidas de eficiencia y eficacia, obtenidas
se logró determinar que el sistema Odoo logro ser efectivo en el desempeño de
los procesos de negocio de la Agroveterinaria la Fortaleza SRL de la ciudad de
Cajamarca en un 64%, la cual brinda satisfacción de haber tomado un buen rumbo
en la investigación hasta alcanzar el objetivo.
(Berrospi, 2012)
2. El proyecto que se presenta en este documento tiene como objetivo exponer el
flujo de procesos o series de pasos que se realiza en un proceso de implantación
de un ERP y en un proceso algorítmico de Data Mining; se realiza lo antes
mencionado porque la empresa a la que se aplicará ambos conjuntos de procesos
21
necesita ordenar su información en el área de ventas y obtener información que
beneficie a la empresa respecto a cómo se comportan sus clientes cuando
compran en todo un periodo de tiempo.
En conclusión, el proyecto se llevó a cabo con éxito previniendo los efectos
negativos o eventos inoportunos que puedan generarse durante su ejecución
mediante un plan de riesgos ya concluido previamente en la planificación. Esta
planificación y el planteamiento de objetivos generales y específicos con sus
respectivos métodos y actividades, ayudaron a mantener una idea clara y concisa
de lo que se pretendía realizar desde los inicios del proyecto.
Conclusión
La implantación de un ERP no incluye solamente la instalación del software en la
empresa, sino que también conlleva posibles problemas por resistencia de los
usuarios al cambio, capacitación de usuarios, comprensión de las tablas de la base
de datos, etc.
2.1.2. Antecedentes Internacionales
(Mogrovejo, 2017)
1. El trabajo de investigación, tiene como principal objetivo la implementación de la
herramienta de Planificación de Recursos Empresariales (ERP) Open Source
Odoo 9, como solución que facilite la integración de los sistemas de una pequeña
y mediana empresa (PYME) de la ciudad de Guayaquil del sector Tecnológico
dedicada al mantenimiento, reparación y ventas de partes y accesorios para
computadoras, con la finalidad de mejorar la productividad de la Microempresa,
reducir los gastos innecesarios generados, eliminar la documentación duplicada
existente en las áreas, llevar un mayor orden de la información de la
microempresa, contar con un inventario actualizado de los materiales, partes,
piezas y accesorios existente en bodega y estandarizar el trabajo de los
empleados al usar una herramienta que les permita contar con toda la información
requerida para mejorar la productividad y asimismo captar más clientes al crear
22
campañas de mercadeo personalizadas que permitan formar u sentimiento de
lealtad a la microempresa.
Conclusión
Si bien es cierto, no existe una herramienta de planificación de recursos
empresariales (ERP), indicado para cada empresa, sino que existen herramientas
tecnológicas innovadoras capaces de adaptarse a las necesidades de las
empresas para optimizar los procesos, mejorar la toma de decisiones y reducir los
costos. También es cierto que las herramientas de planificación de recursos
empresariales (ERP) permite a las empresas obtener ventajas competitivas frente
a su competencia, debido a que controla y ordena los diferentes procesos en una
organización logrando mayor eficiencia en ellos, siempre que se haya realizado
una correcta implementación, considerando el tiempo y el nivel de involucramiento
que se logre en las personas de una organización.
(Dizzet, 2017)
2. AMESCO Ltda. Es una IPS (Instituto Prestador de Servicios de Salud) en pleno
proceso de crecimiento, es indispensable contar con un sistema que coordine sus
procesos administrativos. Pues a pesar de ser una entidad de salud pequeña, tiene
una lista de servicios médicos, donde la información generada de estos procesos
necesita de un control que certifique el buen funcionamiento de la entidad y
además le permita prestar un servicio de calidad. Toda esta información era
procesada en forma manual, causando retardos y perdidas de información
afectando seriamente la toma de decisiones.
Por lo anterior, se planteó como objetivo de la investigación: implementar un
sistema ERP en la IPS AMESCO para el soporte de la toma de decisiones a partir
de soluciones de código abierto existentes. Para cumplir este objetivo se utilizó
como metodología de selección del ERP la metodología MSSE (Metodología para
la Selección de un Sistema ERP en su primera etapa) y para la implementación se
utilizó la metodología ágil de desarrollo SCRUM, el cual garantiza de tener una
23
mejor visión en el momento de implementar la misma, esta consta de las siguientes
fases: Planificación, Análisis e Implementación.
Como resultado de la investigación se implementó un sistema ERP en la IPS
AMESCO, llegando a la conclusión de que sirvió para mejorar el manejo de la
información organizacional de la IPS AMESCO, logrando mayor eficiencia en la
toma de decisiones.
Conclusión
Como resultado de la investigación se concluyó que la implementación del sistema
ERP Odoo en la IPS AMESCO sirvió para mejorar el manejo de la información
organizacional de la IPS AMESCO, logrando mayor eficiencia en la toma de
decisiones, como se evidencia en la certificación emitida por esta entidad, dando
respuesta de esta forma a la pregunta de investigación planteada. En cuanto al
objetivo principal, se implementó el sistema de gestión empresarial (ERP) Odoo
de software libre en la IPS AMESCO Ltda. Perteneciente al sector de la salud en
Colombia, de la ciudad de Cartagena.
2.2. Bases teórico científicas
2.2.1. Open source
a. La historia del open source
El desarrollo basado en el intercambio y la mejora colaborativa del código fuente
del software tiene una historia esencialmente tan larga como el desarrollo del
software en sí. A fines de la década de 1990, el interés y la participación en este
fenómeno aumentaron notablemente con el reconocimiento general de Linux en
publicaciones como Forbes y el lanzamiento del código fuente del navegador
Netscape.
(initiative, 1998-2019)
Open Source Initiative (OSI) se formó en 1998 como una organización educativa,
de defensa y administración en este momento importante del desarrollo
colaborativo.
24
(initiative, 1998-2019)
La etiqueta de “código abierto” se creó en una sesión de estrategia celebrada el 3
de febrero de 1998 en Palo Alto, California, poco después del anuncio del
lanzamiento del código fuente de Netscape. La sesión estratégica creció al darse
cuenta de que la intención en torno al anuncio de Netscape había creado una
oportunidad para educar y abogar por la superioridad de un proceso de desarrollo
abierto.
(initiative, 1998-2019)
Los conferenciantes creyeron que los argumentos pragmáticos y comerciales que
motivaron a Netscape a lanzar su código ilustraron una forma valiosa de
involucrarse con los posibles usuarios y desarrolladores de software, y los
convencieron de crear y mejorar el código fuente al participar en una comunidad
comprometida. Los conferenciantes también creían que sería útil tener una etiqueta
única que identificara este enfoque y la distinguiera de la etiqueta “software libre”
enfocada filosófica y políticamente. La lluvia de ideas para esta nueva etiqueta
finalmente convergió en el término “código abierto”, originalmente sugerido por
Christine Peterson.
(initiative, 1998-2019)
Dos de los presentes en la reunión de Palo Alto (Eric Raymond y Michael Tiemann)
más tarde se desempeñan como presidentes de OSI, y otros asistentes (entre ellos
Todd Andersen, Jon “maddog” Hall, Larry Augustin y Sam Ockman) se convirtieron
en los primeros partidarios clave de la organización.
(initiative, 1998-2019)
La adopción del termino fue rápida, con el apoyo temprano de figuras de la
comunidad, como Linus Torvalds, y de una Cumbre de Software Libre de abril de
1998 a la que asistieron muchas personas clave, incluidas las figuras fundadoras
25
de sendmail, Perl, Python, Apache y representantes de EI IETF e Internet Software
Consortium.
(initiative, 1998-2019)
La historia de la computación moderna es una historia complicada sobre las
interacciones entre los seres humanos, organizaciones, y tecnología. Aquí me
enfoco en la organización social de la producción de software, como los individuos
se unen para escribir instrucciones complejas que les dicen a las computadoras
que hacer. Como ocurre con muchas historias sobre organización industrial, la
historia del software incluye enfoques alternativos para organizar la producción.
Las diferencias entre estos enfoques se basan tanto en las visiones del mundo
integradas como en los medios eficientes de transformar las entradas en salidas.
Los defensores de una forma particular de construir software pueden afirmar que
su cosmovisión es evidente y que la forma de organización que la acompaña es el
destino tecnológico, un resultado necesario de las fuerzas materiales y las
limitaciones en la informática.
(Weber, 2004)
2.2.2. ERP
a. Definición de ERP
ERP (Enterprise Resource Planning o Sistema de Planificación de Recursos
empresariales) como un sistema de planificación de los recursos y gestión de la
información que, de una forma estructurada, satisface la demanda de necesidades
de la gestión empresarial. Se trata de un programa software integrado que permite
a las empresas evaluar, controlar y gestionar más fácilmente su negocio en todos
los ámbitos.
(Muñiz, 2004)
Un sistema ERP es un conjunto de software comercial que propone la unificación
de toda la información que fluye a través de la organización, información de
26
recursos humanos, información de la cadena de abastecimiento e información de
clientes.
(Davenport, 1998)
Un sistema ERP está compuesto por varios módulos, tales como, recursos
humanos, ventas, finanzas y producción, que posibilitan la integración de datos a
través de procesos incrustados. Estos paquetes de software pueden ser
configurados para responder a las especificas necesidades de cada organización.
(Manuel Esteves & A. Pastor, 1999)
Ilustración 1. Una empresa donde todas las áreas saben lo que los otros hacen
Fuente: (Leon, SlidePlayer, s.f.)
b. Historia del ERP
Antes de la popularización de los ordenadores, los sistemas de información en las
organizaciones se basaban simplemente en técnicas de archivamiento y
recuperación de informaciones de grandes archivos. Generalmente existía la figura
del “archivador”, que era la persona responsable de la organización, registro,
catalogación y recuperación de los datos cuando era necesario.
Hubo un cambio en la tecnología usada por las organizaciones, que pasaron de
plataformas mainframe (unidad central, computadora potente y costosa) hacia las
27
plataformas cliente/servidor. En esta categoría de tecnología, destacan dos líneas
de producto:
a. Aplicaciones basadas en el navegador: donde los usuarios solo
necesitan un dispositivo con acceso a internet, por el cual acceden al
sistema. Cualquier información, o análisis queda disponible mediante el
navegador desde cualquier lugar con acceso a internet. Esa tecnología
no requiere muchas actualizaciones de pago de software en el
dispositivo del usuario.
b. Proveedores de Servicios de Aplicaciones “ASP (Aplication Services
Providers)”: son empresas que alojan software desarrollados por otros y
venden la licencia del producto a las empresas.
El ASP es responsable de la ejecución de las aplicaciones que el cliente alquila,
incluyendo sistemas ERP.
Los niveles básicos hasta entonces, estratégico, operacional entre otros, fueron
revaluados y mostraron la necesidad de un nivel más elevado, en el cual se
incluyera el “conocimiento”.
Este cambio en la estructura organizacional de las empresas trajo consigo la
necesidad de un nuevo tipo que consiguiera integrar todas las áreas funcionales
de la empresa – producción, marketing, finanzas y recursos humanos – a modo de
permitir facilitar la creación de conocimiento a partir de la información existente. Así
fue el inicio del surgimiento de los sistemas ERP.
(Valle, Puerta, & Nuñez, 2017)
c. Ciclo de vida de un ERP
El ciclo de vida de un sistema ERP se divide en 6 fases que son:
Decisión y adopción: Es las fases en la que los gestores se cuestionan la
necesidad de un sistema ERP como solución tecnológica y de gestión y
seleccionan el sistema de información que mejor responde a los desafíos
críticos del negocio, teniendo como objetivo el perfeccionamiento de la
28
estrategia organizacional. Esta fase incluye la definición de los requerimientos
del sistema, sus objetivos y beneficios, el análisis del impacto organizacional y
del negocio provocado por la obtención del sistema ERP.
Adquisición: Consiste en la selección del producto que mejor se adapta a los
requerimientos de la empresa. Normalmente, también se escoge una empresa
consultora para ayudar en las fases siguientes del ciclo de vida del sistema
ERP, en especial, en la fase de implementación. Variables como el precio,
formación de personal y servicios de mantenimiento son los que deben ser
analizados y definidos en el acuerdo contractual.
Implementación: Es en esta etapa en la que se da la cuantificación de los
costos, parámetros y obtención del paquete ERP adquirido. Esta tarea se
realiza con consultores que disponen de metodologías de implementación,
know how y formación personal. Se considerada la etapa más importante del
proceso, donde se puede suscitar la mayor parte de inconvenientes como, el
tiempo que un proyecto de esta naturaleza lleva para poder implementarse, el
riesgo del dominio del proceso del proyecto de implementación por una función
dada y la formación de naturaleza transversal en las organizaciones y los
costes y dificultades de la formación, entre otros aspectos.
Uso y mantenimiento: Corresponde al uso del producto para obtener los
beneficios esperados. Durante esta fase se debe tener en cuenta los aspectos
relacionados con la funcionalidad, usabilidad y adecuación a los procesos
organizacionales y de negocio. Después de implementado, el sistema debe
estar en mantenimiento para la corrección de errores, atención de pedidos de
usuario, y adición de posibles mejorías.
Evolución: Representa la integración de más alcances al sistema ERP para
disponer de nuevas funcionalidades, como: advanced planning and scheluding,
supply-chain managment, customer relationship managment, workflow, y
expandir las fronteras a la colaboración externa con otros partners.
Abandono: Es el estado en el que, con el aparecimiento de las nuevas
tecnologías, el sistema ERP actual o la estrategia del negocio es inadecuado y
29
debido a ello los gestores deciden sustituir el sistema existente por un producto
más adecuado a las necesidades organizacionales del momento.
(Nuñez, 2016)
d. ¿Por qué la empresa debe adquirir un ERP?
Las tendencias comerciales actuales y futuras obligan a las empresas a ser cada
vez más competitivas; para ello es necesario que estas tengan optimizados e
integrados todos sus flujos internos de información y sus relaciones comerciales
externas. Además, deben conseguirse los objetivos estratégicos como son las
mejoras de la productividad, la calidad, el servicio permitido, en gran medida, la
consecución de dichos objetivos. En este apartado, podemos reseñar la aportación
de los ERP y las ventajas del comercio electrónico, o intercambio electrónico de
información, con clientes y proveedores. Es importante conocer el potencial de este
tipo de sistemas ERP, sus ventajas, desventajas y sus principales características,
así como sus problemas de implantación y los aspectos clave que requieren una
mayor atención en el momento de tomar la decisión de instaurar un programa de
tipo ERP.
(Muñiz, 2004)
e. Beneficios del ERP
La información integrada, uniforme, relevante y actualizada es vital para la
existencia misma de una empresa. Le da el poder a la persona adecuada para
tomar decisiones en el momento adecuado. Esto solo es posible cuando toda la
organización comparte la misma información y la ve desde la misma perspectiva.
La falta de integración afecta a otros flujos como hombres, máquinas y dinero.
ERP reúne a personas que trabajan en tareas compartidas dentro de la misma
empresa o en sus relaciones con proveedores y clientes. Las empresas deben
garantizar un flujo de información más fluido en todos los niveles y entre todas las
partes de su organización; para acceder a información actualizada. Procesos de
30
negocio integrados de flujo de trabajo. Algunos de los beneficios tangibles
reportados por la industria son:
o Reducción del tiempo de entrega en un 60%
o 99% de envíos a tiempo
o Negocio duplicado
o El aumento del inventario se convierte en más del 30%
o Tiempo de ciclo reducido en 80%
o WIP (work in progress) control de trabajo en proceso reducido en 70%
Aparte de beneficios tangibles también hay beneficios intangibles como:
o Mejor satisfacción del cliente
o Rendimiento mejorado del vendedor
o Aumento de la flexibilidad
o Costos de calidad reducidos
o Utilidad de recursos mejorada
o Exactitud de la información mejorada
o Capacidad mejorada para tomar decisiones
f. ERP y la empresa moderna
Hay un dicho en China: los que miramos a las estrellas no debemos olvidar el calor
del sol. El uso de TI no significa configurar computadoras para administrar trabajos.
También no significa ser racionalizado. Crear departamentos transparentes y
mejorar el flujo de trabajo. La implementación de TI es todo esto y mucho más. Si
uno eligiera una sola palabra para definir la importancia y la relevancia de TI para
las organizaciones, es la unidad. ERP es una definición de esta gran similitud con
la que TI intenta transformar la mayoría de los procesos de negocio.
(Kumar, 2011)
31
Ilustración 2. Mundo real y el modelo de negocios
Fuente: (Leon, SlidePlayer, s.f.)
g. Riesgos de los ERP
Los beneficios de eficiencia y rentabilidad tentadores son la promesa de los
sistemas de planificación de recursos empresariales. Pero conllevan riesgos
especiales para las empresas y comprender como evitar los puntos ciegos y
capturar los beneficios prometidos puede ser muy difícil y complicado. La
implementación de sistemas ERP ha sido problemática para muchas
organizaciones. Dado los numerosos informes de fallas sustanciales, la
implementación del software ERP empaquetado y los cambios asociados en los
procesos de negocio no han sido una tarea fácil.
Los sistemas de planificación de recursos empresariales han cambiado
fundamentalmente el trabajo de las organizaciones. El tamaño y la complejidad de
las implementaciones de ERP dificulta la administración de estos proyectos.
Existen realmente tres aspectos básicos en la gestión de ERP, personas, procesos
y tecnología. Un paquete ERP afecta a toda la organización puede afectar a casi
todos los empleados.
(Leon, ENTERPRISE RESOURCE PLANNING , 2008)
32
2.2.3. Odoo
Es un software de ERP integrado. Cuenta con una versión comunitaria de código abierto
bajo licencia LGPLv3 y una versión empresarial bajo licencia comercial que complementa
la edición comunitaria con características y servicios comerciales y desarrollada por la
empresa belga Odoo S.A. El fabricante declara su producto como una alternativa de
código abierto a SAP ERP y Microsoft Dynamics. La compañía tiene sus sucursales en
varias partes del mundo.
Odoo es un software empresarial todo en uno que incluye CRM, sitio web y comercio
electrónico, facturación, contabilidad, fabricación, gestión de almacenes y proyectos, e
inventario entre otros. La misión de Odoo es ofrecer un conjunto de aplicaciones para
empresas fáciles de utilizar que forman una caja de herramientas para acompañar a
cualquier negocio que las necesite.
(Reis, 2016)
Ilustración 3. Arquitectura de red de odoo
Fuente: (Docplayer, s.f.)
33
a. Open Object
Open Object es un framework de código abierto de Python que permite crear
aplicaciones empresariales de forma extremadamente rápida y sencilla. Open
object es el framework utilizado por el software de gestión empresarial de código
abierto líder: Open ERP. Incluye un ORM, un motor de flujo de trabajo, varios
diseñadores de reportes, un motor MDX, un diseñador de paneles, un sistema de
modulos, un diseñador de procesos, un motor de migración automatizado, web-
services y mucho más.
(Object, 2011)
b. Ventajas de odoo
Posee una experiencia del usuario fluida y sencilla diseñada para asegurar una
adaptación natural.
La fluidez y la integración total cubren las necesidades de todas las empresas,
incluso de las empresas más complejas. La flexibilidad de Odoo es tal que se
pueden añadir aplicaciones dependiendo del crecimiento de su empresa,
añadiendo las aplicaciones de una en una a medida que sus necesidades
cambien y su clientela crezca.
Gracias a la comunidad de código abierto, Odoo se mantiene totalmente a
través de una gran base de desarrolladores, lo que permite responder a las
cambiantes necesidades de los clientes y ofrecer aplicaciones nuevas e
innovadoras.
(About us: Odoo, 2004-2019)
34
Ilustración 4. Alcance del negocio y cuan amigable es para el usuario de diferentes
software ERP
Fuente: (S.A., 2015)
2.2.4. MRP
Es una técnica especial para planificar los requerimientos de materiales de producción,
que se basa en que la demanda de la mayoría de artículos no es independiente,
únicamente es la de los productos terminados, y las necesidades de cada artículo y el
momento en que deben ser satisfechas estas necesidades, se pueden calcular a partir
de: las demandas pendientes y la estructura del producto.
Así pues, MRP consiste en un cálculo de necesidades netas de los artículos introduciendo
un factor nuevo, no considerado en los métodos tradicionales de gestión de stocks, que
es el plazo de fabricación o de compra de cada uno de los artículos lo que en definitiva
conduce a modular a lo largo del tiempo las necesidades, ya que indica la oportunidad
de fabricar los componentes con el debido decalaje respecto a su utilización en la fase
siguiente de fabricación.
(Companys Pascual & Fonollosa i Guardiet, 2007)
35
f. Objetivo del MRP
El objetivo de la planificación de necesidades de material en un sistema de
fabricación de varias etapas es determinar la cantidad de todos los productos que
son necesarios para producir una cantidad pronosticada de artículos finales dentro
de un horizonte de planificación determinado y determinar el calendario de las
decisiones de compra y producción correspondientes.
La planificación de materiales es un elemento central de todo el sistema de
planificación de producción de una empresa. Pertenece al corto plazo, decisiones
de producción operativa. La planificación de materiales está directamente
relacionada con la demanda y los suministros de los clientes (compra de
componentes y materias primas). Por lo tanto, las incertidumbres en la demanda y
la oferta a menudo conducen a revisiones del plan en la planificación de materiales.
g. Desconfianza en sistemas de planificación de requerimientos de materiales
En la práctica, la planificación de materiales se realiza generalmente utilizando
sistemas MRP. Hasta ahora, el uso de conceptos alternativos como LRP o FIRST
no está muy extendido. En consecuencia, el análisis del nerviosismo en los
sistemas MRP es el enfoque principal en la literatura y en el análisis posterior.
En la literatura, el nerviosismo de MRP se defina de varias maneras, en un trabajo
inicial, steele define un sistema de “MRP nervioso” como uno que causa cambios
excesivos en los requisitos de bajo nivel cuando el programa maestro no se
modifica significativamente.
Como consecuencia del aumento de la dinámica y las incertidumbres en el entorno
de las empresas, los sistemas de planificación deben poder reaccionar ante
acontecimientos inesperados. La capacidad de un sistema de hacerlo se denomina
flexibilidad, por lo que la flexibilidad es sin duda un factor decisivo importante para
la competitividad de una empresa.
(Heisig, 2002)
36
2.2.5. Características MRP Odoo
a. Gestionar
Administrar órdenes de producción, gestionar productos en líneas de
fabricación.
Gestionar órdenes de trabajo, iniciar la producción de los materiales requeridos
para la fabricación final de sus productos.
Gestionar lector de barras, uso del lector de barras para agilizar las
operaciones de manufactura.
Administrar ordenes de fabricación editables, ahora puede usar otros
materiales a pesar de lo que se había programado inicialmente, y también
editar ordenes de manufactura una vez finalizados.
Administrar ordenes no despachadas, descomponga un producto finalizado y
recupere los componentes.
b. Programación y planificación
Procedimiento de fabricación, visibilizar al detalle la planificación global y
replanificar la fabricación.
Gestionar facturas de materiales, revisar la disponibilidad de artículos en stock
y tiempo de producción.
Establecer ordenes de trabajo, acceder a todos los recursos disponibles y
planificar su posterior producción.
Capacidad del centro de trabajo, planificador MRP II que usa las capacidades
y horarios de los centros de trabajo.
c. Datos maestros flexibles
Elaborar facturas multinivel de materiales, editar una factura de materiales con
otro para producir componentes de un producto en otra factura.
Cambios de versión, permitir que los productos evolucionen, añadir opciones
editables cuando se elaboran pedidos de producción.
37
Enrutado opcional, elaborar rutas para pedidos de trabajo para enlistar en
orden su producción correspondiente a la ruta usada.
Kits, el kit de aplicaciones Odoo permite a su comercial vender un kit, pero
también entregar un lote de productos
d. PLM
Versiones, obtener fácilmente las diferencias entre versiones para monitorizar
los cambios.
Ingeniería de cambios, visualizar los cambios con la vista kanban.
PLM, seguimiento a las diferentes versiones de los productos, como también
de sus respectivos documentos. Fusionar distintas órdenes que corresponden
a la misma lista de materiales.
e. Calidad
Puntos de control, desplegar automáticamente revisiones de calidad para el
área de fabricación.
Alertas de calidad, organizar aprovechando el dinamismo de la vista kanban de
alertas de calidad.
Pruebas de calidad, desplegar el control del proceso estadístico con
comprobaciones.
f. Mantenimiento
Mantenimiento preventivo, libera solicitudes de mantenimiento establecidas
automáticamente en KPIs.
Calendario, proyectar operaciones de mantenimiento con un calendario.
Mantenimiento correctivo, liberar el mantenimiento correctivo desde el panel
del centro de control.
Estadísticas, extraer toda la estadística de mantenimiento calculada
38
g. Panel de control del centro de trabajo
Dispositivos, colocar dispositivos con acceso a internet en cada centro de
trabajo para organizar el trabajo eficiente.
Grabar producción, registrar producciones, escanear ordenes de producción,
lotes o números de serie.
Alertas, usar alertas para visualizar cambios o test de calidad al operador.
Hojas de trabajo, enseñar hojas de trabajo directamente en el centro de trabajo
con instrucciones para el operador.
Pasos en la orden de trabajo, especifique pasos en una orden de trabajo y
enlácelos a páginas de hoja de cálculo: escanear un producto, tomar una foto,
realizar el control de calidad.
h. Informes
Trazabilidad, obtenga un informe detallado de trazabilidad de los componentes
usados durante el proceso de fabricación.
Eficacia general de equipo, analice los datos de sus centros de trabajo, las
pérdidas de productividad y realice un seguimiento de la eficacia general de su
equipo.
Análisis de costo, realice un seguimiento del costo de cada orden de trabajo en
relación del costo de los componentes y del costo de sus operaciones (recurso
humano).
(Manufacturing features, 2018)
2.2.6. Python
El lenguaje principal de odoo es Python al igual que las otras tecnologías
subyacentes a odoo, el lenguaje Python es de código abierto y se ejecuta en todos
los principales sistemas operativos contemporáneos. Es un lenguaje de
programación bastante popular, que hace que sea muy fácil encontrar recursos
para ayudarlo a comenzar.
(Moss, 2015)
39
2.2.7. Javascript
Javascript es un lenguaje de programación interpretado orientado a objetos, es un
lenguaje de programación de uso general, y su uso no está restringido a los
navegadores web, javascript se diseñó para integrarse y proporcionar capacidades
de secuencia de comandos para cualquier aplicación.
Los programas de javascript se escriben utilizando el juego de caracteres Unicode,
a diferencia de la codificación ASCII de 7 bits, que es útil solo para el inglés, y la
codificación ISO Latin-1 de 8 bits, que es útil solo para el inglés y los principales
idiomas de Europa occidental, la codificación Unicode de 16 bits puede representar
prácticamente todos los idiomas escritos de uso común en el planeta. Esto es una
característica importante para la internacionalización y es particularmente
importante para los programadores que no hablan inglés
(Flanagan, 2010).
2.2.8. Xml
El lenguaje xml proporciona un formato simple y consistente que cualquier
programa que utilice cualquier lenguaje de programación puede acomodar, porque
la sintaxis de xml está bien definida, los analizadores se han vuelto rápidamente
disponibles que son fáciles de incorporar en un programa nuevo o existente, xml
permite desarrollar sistemas sofisticados y facilita el software empresarial.
Cada vista en odoo se define en documentos xml, el framework de odoo es
responsable de representar estos archivos de vista en un navegador web. Se
pueden construir vistas alternativas para renderizar la funcionalidad odoo sobre
otras plataformas como dispositivos móviles.
(Binstock, y otros, 2012)
40
2.2.9. Arquitectura de software
a. Arquitectura de software
Desde su primera mención en un informe técnico en la década de 1970 titulado
Software Engineering Tecnhiques, diversos autores se propusieron definir el
termino de arquitectura de software, esta se hace necesaria cuando el tamaño y la
complejidad de los sistemas de software crecen. Así, el problema de construir
sistemas va más allá de la elección de los algoritmos y de las estructuras de datos
correctos. Ese problema envolverá también las decisiones sobre las estructuras
que formaran el sistema, la estructura global de control que será usada, los
protocolos de comunicación, la sincronización y el acceso a datos, la atribución de
la funcionalidad a los elementos del sistema y la distribución de los elementos del
sistema. Además de eso, el problema envolverá las decisiones que impactarán en
el comportamiento del sistema en términos de escala y rendimiento, entre otros
atributos de calidad.
La visión sobre Garlan y Shaw contiene tres aspectos. El primero que estos citan
es que sean explícitos cuando debemos aplicar conocimientos de arquitectura de
software, es decir, cuando trabajamos con grandes sistemas. El segundo aspecto
que citan es ser claros en la separación entre las tareas de diseño detallado y
diseño arquitectural; el primero se preocupa de los algoritmos y de las estructuras
de datos, mientras que el segundo se preocupa de los elementos y de la
organización del sistema como un todo, estando relacionado con la estructura del
sistema, el control, la comunicación o la implantación. Y el tercero que citan es que
el proceso de diseño de la arquitectura necesita preocuparse de los atributos de
calidad del sistema, en alcanzar la escalabilidad.
b. Estándar ISO/IEEE 1471
El propósito de la creación del estándar fue la de ayudar en el consenso entre
autores, estudiantes y profesionales sobre lo que es y para qué sirve la arquitectura
de software, sino que también introduce un esquema conceptual para la
descripción arquitectural. Su definición de arquitectura de software, es la siguiente:
41
La arquitectura es la organización fundamental de un sistema incorporada en sus
componentes, sus relaciones con el entorno y los principios que conducen su
diseño y evolución.
La evolución del software es el fenómeno de cambio/modificación que sucede a lo
largo de los años y de las múltiples versiones.
(Arias & Durango, 2016)
c. Procesos del ciclo de vida del software
Ilustración 5. Procesos de ciclo de vida según norma ISO 12207
Fuente: Procesos de ciclo de vida según norma ISO 12207
42
2.2.10. Programación extrema
a. Programación extrema (xp)
Se trata de dejar de lado los hábitos y patrones que se adaptaron en el pasado,
pero que ahora nos estorban haciendo nuestro trabajo mejor. Se trata de renunciar
a las defensas que nos protegen, pero interfieren con nuestra productividad.
Es un estilo de desarrollo de software que se enfoca en una excelente aplicación
de técnicas de programación, comunicación clara y trabajo en equipo que nos
permite lograr cosas que antes ni siquiera podíamos imaginar. Esta incluye:
Una filosofía de desarrollo de software basada en la comunicación,
retroalimentación, simplicidad, coraje y respeto.
Un cuerpo de prácticas probadas útiles para optimar el desarrollo de software. Las
prácticas se complementan, extendiendo sus efectos.
Un conjunto de principios complementarios, metodologías intelectuales para
convertir los valores a la práctica, útiles cuando no hay una práctica útil para su
problema particular.
Una comunidad que comparte estos valores y muchos de la misma práctica.
Ciclos de desarrollo cortos, que resultan en una retroalimentación cariñosa,
concreta y continua.
Su enfoque de planificación incremental, que rápidamente presenta un plan
general que se espera evolucione a lo largo de la vida del proyecto.
Su capacidad para programar de manera flexible la implementación de la
funcionalidad, respondiendo a las cambiantes necesidades comerciales.
Se basa en la comunicación oral, las pruebas y el código fuente para comunicar la
estructura y la intención del sistema.
Se basa en un proceso de diseño evolutivo que dura todo el tiempo que dure el
sistema.
Se basa en prácticas que funcionan tanto con los instintos a corto plazo de los
miembros del equipo como con los intereses a largo plazo del proyecto.
(Beck & Andres, 2012)
43
b. Prácticas de la programación extrema
La programación extrema tiene prácticas que definen su uso y son las siguientes
Cliente presente: uno de los paradigmas del desarrollo de software tradicional
es que el usuario no debería estar presente durante el proceso de desarrollo.
La programación extrema busca lo contrario, haciendo que la presencia del
usuario sea muy importante para el éxito del proyecto.
Juego de la planificación: al inicio de cada iteración el usuario es invitado a
describir, a su manera, las funcionalidades que necesita en el sistema, en
tarjetas pequeñas llamadas historias de usuario, esa es la cantidad de
información que este puede detallar. Conocedor del tiempo y del coste, el
cliente debe decidir el orden en que cada historia de usuario será desarrollada,
es decir, este prioriza el desarrollo de las funcionalidades.
Programación en par: dos programadores escogen una historia de usuario y se
ponen a codificar en distintas PC una determinada funcionalidad. El
programador con menos experiencia tiene como responsabilidad el control del
teclado y llevar enérgicamente la programación del código fuente, mientras el
otro programador monitorea el código en busca de errores, deliberando las
decisiones y buscando estratégicamente las soluciones más sencillas para el
código.
Releases cortos: Esta práctica busca, por medio de releases cortos, entregar
versiones actualizadas del software al cliente a lo largo del proceso de
desarrollo.
Desarrollo guiado por las pruebas: los desarrolladores escriben pruebas para
cada funcionalidad antes de codificarlas. De esta forma las interfaces externas
de los métodos y de las clases son planeadas antes de codificación. Esta
práctica genera una masa de pruebas que puede ser usada en cualquier
momento para validar todo el sistema.
Refactoring: Es el proceso de reorganizar el código fuente de un software para
mejorar su calidad interna, facilitar la lectura y disminuir el tiempo desperdiciado
con el mantenimiento, sin perjudicar el rendimiento y modificar su
comportamiento externo.
44
Código colectivo: En la programación extrema, el sistema no está dividido en
partes. Los programadores tienen acceso a todas las partes del código y
pueden editar lo que consideren importante: el código es comunitario. Eso
provee mayor agilidad al proceso, además de proveer un mecanismo de
revisión y de verificación del código, ya que el código que es escrito por un par,
acaba siendo manipulado por otro. Si alguna línea esta confusa en el código,
pasará por el refactoring
Código estandarizado: Para los programadores puedan modificar cualquier
parte del sistema, de forma sencilla, el equipo establece normas de
codificación, que son usadas también para hacer el sistema más homogéneo,
permitiendo que cualquier mantenimiento futuro sea efectuado más fácilmente.
Integración continua: Actividad de unir el código realizado por un par de
programadores, al trabajo como un todo. Después de terminar, los
programadores deben testear y unir su código a la versión más reciente del
código colectivo.
Ritmo sustentable: Trabajar respetando los límites físicos y respeto por la
individualidad. Por esto, se recomienda que la carga horaria de trabajo no pase
de las ocho horas diarias y cuarenta horas semanales.
Metáfora: Esta práctica utiliza comparaciones que permiten al equipo transmitir
ideas de modo que todos la entiendan. El uso de metáforas posibilita transmitir
la idea de modo de aclaración para los oyentes. Esta práctica facilita la
comunicación entre desarrollador y el cliente, estableciendo un vocabulario
común entre ambos.
Stand up meeting: El equipo de programación se reúne cada mañana para
revisar el trabajo que se realizó el día anterior y priorizar aquello que será
implementado el día que se inicia.
(Lainez, 2016)
45
c. La alternativa de programación extrema
La programación extrema es una tercera vía. Para usarlo se debe aceptar las
siguientes premisas:
Las estimaciones son conjeturas, hay demasiadas variables e incógnitas en un
proyecto complejo para hacer más que estimaciones generales de cuánto
tiempo tomaran las cosas y a que costo.
El cliente no puede describir lo que se requiere en los detalles que su equipo
necesita por adelantado. El proyecto en sí mismo influirá en gran medida en
los requisitos del cliente y los clientes cambiaran de opinión a medida que
avance el proyecto.
Hay factores comerciales más allá de la previsión del gerente de proyecto o del
cliente. Los miembros del equipo se irán, el mercado en el que se lanzara el
proyecto cambiara y las prioridades fluctuarán.
(Wallace, Raggett, & Aufgang, 2012)
2.2.11. Node.js
Es una plataforma construida encima del entorno de ejecución javascript de
Chrome para fácilmente construir rápidas, escalables aplicaciones de red.
(Salas, 2018)
Node provee un entorno de ejecución para un determinado lenguaje de
programación y un conjunto de librerías básicas, o módulos nativos, a partir de las
cuales crear aplicaciones orientadas principalmente a las redes de comunicación,
aunque una parte de estas librerías permite interactuar con componentes del
sistema operativo a través de funciones.
46
Características
Node es una fina capa de software entre el sistema operativo y la aplicación
para la plataforma porque los objetos que se han perseguido con su
arquitectura son la velocidad y la eficiencia.
Interfaces ligeros, el modelo entrada/salida no bloqueante, para atender a
las peticiones REST, en combinación con JavaScript para el soporte nativo
JSON.
Aplicaciones monopagina, son aquellas que se presentan en una sola
página web, emulando a las aplicaciones de escritorio. La interacción del
usuario con el servidor a través de la interfaz de la aplicación se realiza
mediante peticiones AJAX, en lugar de recargar la página entera.
Reutilizar herramientas UNIX, la capacidad de Node de lanzar miles de
procesos hijos que ejecuten comandos y tratar su salida como streams
permiten utilizar la plataforma para reutilizar el software existente en lugar
de reinventarlo para ella.
Datos por streaming, al tratar las conexiones HTTP como streams, se
pueden procesar ficheros al vuelo, conforme se envían o reciben.
Comunicación, aplicaciones de mensajería instantánea o web en tiempo
real, e incluso juegos multijugador.
(Salas, 2018)
2.2.12. QuaggaJS
Es un escáner de código de barras totalmente escrito en Javascript que admite la
localización y decodificación en tiempo real de varios tipos de códigos de barras,
como: EAN, CODE 128, CODE 39, EAN 8, UPC-A, UPC-C, I2of5, 2of5, CODE
93 y CODABAR. La librería también es capaz de usar get user media (método de
Javascript) para obtener acceso directo a la transmisión de la cámara de usuario.
Aunque el código se basa en el procesamiento de imágenes pesadas, incluso los
teléfonos inteligentes son capaces de localizar y decodificar códigos de barras en
tiempo real.
(Oberhofer, 2017)
47
2.2.13. Conceptos esenciales de desarrollo en Odoo
a. Comprensión de Aplicaciones y módulos
Módulos (Addons). Son piezas/directorios individuales de código contenidas en
una carpeta con un nombre técnico definido. Un módulo puede agregar una nueva
lógica comercial o modificar y ampliar la lógica comercial existente. El directorio
contiene un archivo de manifiesto o descriptor, llamado __manifest__.py, más los
archivos restantes que implementan sus características.
Aplicaciones. Es una colección de módulos que usualmente implementa una
opcion de configuracion, definen la forma en que se agregan características
principales a Odoo. Proporcionan los elementos centrales para un área funcional,
como Contabilidad o RR. HH., según los módulos adicionales que modifiquen o
amplíen las características.
(Reis, 2016)
b. Modificación y ampliación de módulos
Como regla principal, se considera una mala práctica modificar el código fuente
directamente de los módulos existentes. Esto aplica principalmente para los
módulos oficiales proporcionados por Odoo. Realizarlo no permite tener una
separación clara entre el código del módulo original y las modificaciones, y dificulta
el soporte de las nuevas actualizaciones publicadas periódicamente, ya que
sobrescribirá las modificaciones realizadas. En su lugar, debemos crear módulos
de extensión que se instalarán junto a los módulos que queremos modificar,
implementando los cambios que necesitamos. De hecho, una de las principales
fortalezas de Odoo es el mecanismo de herencia, que permite a los módulos
personalizados ampliar la funcionalidad de los módulos existentes, ya sea los
oficiales o de la comunidad. La herencia es posible en todos los niveles: modelos
de datos, lógica de negocios y capas de interfaz de usuario.
(Reis, 2016)
48
c. Esqueleto básico de un módulo
Ilustración 6. Estructura de archivos básico de un módulo Odoo
Fuente: Elaboración propia
- controllers. Contiene los archivos python que definen las funciones que
manejan las solicitudes del navegador web.
- data. Contiene los archivos xml que especifican los datos a insertar en las
tablas de la base de datos al instalar o actualizar el modulo.
- models. Contiene los archivos python de definen los modelos del módulo.
- security. Contiene los archivos csv y xml que definen los aspectos de seguridad
de los grupos de usuario y los modelos.
- static. Contiene los archivos que serán entregados al navegador web, como
son los archivos de estilos CSS o LESS y los archivos javascript.
- views. Contiene los archivos xml que definen las funcionalidades relacionadas
a la vista como son los menús, las acciones y los diferentes tipos de vistas que
representan los modelos.
d. La capa del modelo
El modelo es la representación de los objetos del negocio, por ejemplo, puede ser
una orden de venta, una factura o un cliente. El modelo contiene una serie de
atributos y también pueden definir las reglas del negocio.
49
Los modelos son implementados mediante clases Python, que heredan de una
clase plantilla de Odoo, serán los responsables de la traducción de nuestros
objetos a la base de datos, y Odoo realizara esta operación automáticamente al
instalar o actualizar el modulo.
A continuación, se muestra la estructura básica de un modelo.
# -*- coding: utf-8 -*-
from odoo import models, fields
class TodoTask(models.Model):
_name = 'todo.task'
_description = 'To-do Task'
name = fields.Char('Description', required=True)
is_done = fields.Boolean('Done?')
active = fields.Boolean('Active?', default=True)
e. La capa de la vista
La capa de la vista describe la interfaz de usuario. Las vistas se definen usando
archivos XML, que es utilizado por el framework del cliente web para generar vistas
HTML con datos.
Existen elementos de menú que pueden activar acciones que pueden representar
vistas. Por ejemplo, el elemento del menú Usuarios procesa una acción también
llamada Usuarios, que a su vez genera una serie de vistas. Hay varios tipos de
vista disponibles, como las vistas de lista, formulario, kanban, calendar, graph y
pivot. Las opciones de filtro disponibles también se definen por un tipo particular
de vista, la vista de tipo búsqueda.
Las pautas de desarrollo de Odoo establecen que los archivos XML que definen la
interfaz de usuario deben colocarse dentro de un subdirectorio /views.
A continuación, se muestra la creación de una vista de menú y una acción.
Definición de una vista de tipo formulario.
To-do Task Form
todo.task
f. La capa de lógica de negocios
Procesos que describen el comportamiento de las acciones ejecutadas por el
usuario a través de la interfaz del sistema. También definen el conjunto de reglas
de lo que está y no está permitido ejecutar, la responsabilidad de operar estos
procesos queda del lado de los modelos.
@api.multi
def do_toggle_done(self):
for task in self:
task.is_done = not task.is_done
return True
g. Seguridad de control de acceso
Al desarrollar un nuevo modelo de datos este requiere la definición de reglas de
acceso por cada uno, dichas reglas definen el nivel de acceso de usuario o grupos
de usuario al modelo. El módulo proporciona la información de las listas de control
de accesos utilizando un archivo de datos (.csv) para cargar las definiciones en el
modelo ir.model.access, dicho archivo está ubicado comúnmente dentro de la
carpeta security.
51
El nombre del archivo corresponde al modelo en el que se cargan los datos, y la
primera línea del archivo corresponde a los nombres de las columnas. A
continuación, detallamos las columnas proporcionadas en nuestro archivo CSV:
id: identificador externo del registro (también conocido como XML ID). Debería ser
único en nuestro módulo.
name: es un título descriptivo. Es solo informativo y es mejor si se mantiene único.
Los módulos oficiales generalmente usan una cadena separada por puntos con el
nombre del modelo y el grupo.
model_id: es el identificador externo para el modelo al que estamos dando
acceso. Los modelos tienen XML ID generados automáticamente por el ORM.
group_id: identifica el grupo de seguridad al cual otorgar permisos. Los más
importantes los proporciona el módulo base.
perm_read, perm_write, perm_unlink, perm_create: otorgan los niveles de
acceso de lectura, escritura, creación o desvinculación (eliminación).
Ilustración 7. Vista Lista de controles de acceso
Fuente: elaboración propia
52
Capítulo III: Desarrollo, Implementación o Transferencia
Tecnológica
Como buenas prácticas de desarrollo de software se utilizará una metodología de
desarrollo ágil, la metodología de desarrollo seleccionada para este proyecto es la de
programación extrema ya que dicha metodología presenta más énfasis en la
adaptabilidad, basándose en la simplicidad, comunicación y la retroalimentación del
código desarrollado, a través del uso de iteraciones e historias de usuario. Se dividieron
las iteraciones, de acuerdo a la duración de las historias de usuario. A continuación, se
resumen las iteraciones:
Tabla 1: Resumen de las iteraciones
Iteración Resumen
Nro. 0 Iteración en la cual se vio de forma general
el proceso de producción de la empresa,
además de adquirir conocimiento de los
conceptos básicos de manufactura.
Nro. 1 – Nro. 6 Iteraciones de desarrollo e
implementación del módulo MRP que
incluye la gestión d usuarios hasta la
creación de reportes
3.1. Configuración del entorno de desarrollo
Si bien es cierto Odoo es multiplataforma y puede ejecutarse en varios sistemas
operativos, el equipo de Odoo recomienda la ejecución del servidor en entornos
Debian/Ubuntu, por lo que en este proyecto utilizaremos Ubuntu Desktop 18.04 LTS,
como sistema operativo para nuestro entorno de desarrollo.
Instalación de Odoo:
Primero se instalarán actualizaciones de sistema con el siguiente comando
$ sudo apt-get update && sudo apt-get upgrade
Instalación de git
53
$ sudo apt-get install git
Instalación de NodeJs
$ sudo apt-get install npm
Llamada a node para ejecutar nodejs
$ sudo ln –s /usr/bin/nodejs /usr/bin/node
Instalación del compilador less
$ sudo npm install –g less less-plugin-clean-css
Creación del directorio de trabajo
$ mkdir ~/odoo-dev
Accedemos al directorio creado
$ cd ~/odoo-dev
Descargamos el codigo Fuente de odoo 10
$ git clone https://github.com/odoo/odoo.git -b 10.0 --depth=1
Nos dirigimos al directorio home del usuario
$ cd ~
Instalación de virtual environment
$ sudo apt-get install python-virtualenv virtualenv
Creación del entorno virtual python para Odoo 10
$ virtualenv -p /usr/bin/python2 venv-odoo10
Activamos el entorno virtual creado
$ source venv-odoo10/bin/activate
Instalación de las dependencias python de Odoo
$ pip install --no-cache-dir -r ~/odoo-dev/odoo/requirements.txt
Instalación de Postgresql
$ ~/odoo-dev/odoo/setup/setup_dev.py setup_pg
3.2. Historias de usuario
- Creación de permisos y grupos de usuario
- Gestión de productos y servicios
- Gestión de centros y rutas de producción
54
- Gestión de lista de materiales por producto
- Gestión de órdenes de producción
- Planificación de fichas de producción
- Registro de las ordenes de trabajo
- Registro de merma
- Supervisión de las ordenes de trabajo
- Reporte de productividad
- Reporte de pago a los operarios
Tabla 2 Historia de usuario creación de permisos y grupos de usuario
Creación de permisos y grupos de usuario
Número: 1 Usuario: Administradores, Jefe de Área, Supervisor de
Planta, Operarios de Planta
Nombre de Historia: Creación de permisos y grupos de usuario
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Descripción: Los usuarios deberán estar divididos en grupos que delimiten el acceso
a las funcionalidades del sistema según el rol que desempeñen dentro de la empresa.
Observación: El administrador del sistema será el único usuario que tendrá acceso
general a todas las funcionalidades del sistema
Tabla 3 Historia de usuario gestión de productos y servicios
Gestión de productos y servicios
Número: 2 Usuario: Administradores, Jefe de Área, Supervisor de
Planta, Diseñadores
Nombre de Historia: Gestión de productos y servicios
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
55
Descripción: El sistema deberá administrar la información de los productos que se
produce en la empresa, los materiales usados para producirlos y los servicios de mano
de obra que serán utilizados para el cálculo de sueldos de los operarios.
Observación: Los servicios de pago se calculan en función a tiempos de trabajo o
cantidad de piezas producidas.
Tabla 4 Historia de usuario gestión de centros y rutas de producción
Gestión de centros y rutas de producción
Número: 3 Usuario: Administradores, Jefe de Área, Supervisor de
Planta
Nombre de Historia: Gestión de centros y rutas de producción
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Descripción: Los operarios deberán ser registrados en los centros de producción para
ser asignados a las operaciones de fabricación.
Una ruta de producción consta de una serie de operaciones que se tienen que llevar a
cabo para la fabricación de un determinado producto, estas operaciones son realizadas
en los diferentes centros de trabajo.
Observación: Dependiendo del destino al que serán enviados los productos
fabricados, pueden requerir una operación adicional.
Tabla 5 historia de usuario gestión de lista de materiales por producto
Gestión de lista de materiales por producto
Usuario: Administradores, Jefe de Área, Supervisor de
Número historia: 4
Planta
Nombre de Historia: Gestión de lista de materiales por producto
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
56
Descripción: Cada producto deberá contener una relación de materiales o insumos a
consumir, especificando la cantidad necesaria de cada material en relación a una
cantidad específica de producto terminado, esta lista deberá ser utilizada para el
abastecimiento de materiales.
Tabla 6 historia de usuario gestión de órdenes de producción
Gestión de órdenes de producción
Usuario: Administradores, Jefe de producción,
Número historia: 5
Supervisor de Planta
Nombre de Historia: Gestión de órdenes de producción
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Descripción: se requiere que el responsable del área de ventas pueda registrar una
orden de producción que contenga la cantidad de piezas por modelo que se requiere
para abastecer
Tabla 7 historia de usuario planificación de fichas de producción
Planificación de fichas de producción
Usuario: Administradores, Jefe de Área, Supervisor de
Número historia: 6
Planta
Nombre de Historia: Planificación de fichas de producción
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Descripción: como supervisor de planta deseo poder registrar las fichas de
producción en una vista calendario y generar las ordenes de trabajo para permitir el
registro del trabajo de los operarios en planta de producción.
57
Tabla 8 historia de usuario registro de las ordenes de trabajo
Registro de las ordenes de trabajo
Usuario: Administradores, Jefe de Área, Supervisor de
Número historia: 7
Planta
Nombre de Historia: Registro de las ordenes de trabajo
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 1
Descripción: se desea que los operarios puedan registrar las ordenes de trabajo
asignadas, estableciendo el inicio, pausa y el final de la operación, para notificar su
correspondiente supervisión.
Tabla 9 historia de usuario registro de merma
Registro de merma
Usuario: Administradores, Jefe de Área, Supervisor de
Número historia: 8
Planta
Nombre de Historia: Registro de merma
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 1
Descripción: Como supervisor del área de producción necesito tener una vista
donde registre la merma encontrada en el área correspondiente a la operación de la
orden de trabajo.
Tabla 10 historia de usuario supervisión de las ordenes de trabajo
Supervisión de las ordenes de trabajo
Usuario: Administradores, Jefe de Área, Supervisor de
Número historia: 9
Planta
Nombre de Historia: Supervisión de las ordenes de trabajo
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
58
Puntos Estimados: 2 Iteración Asignada: 1
Descripción: Como supervisor del área de producción necesito tener una vista
donde observe las ordenes de trabajo a supervisar, al entrar a la orden de trabajo se
debe poder registrar los operarios que realizaron el trabajo y la merma que se
hubiese producido en el proceso.
Tabla 11 historia de usuario reporte de productividad
Reporte de productividad
Usuario: Administradores, Jefe de Área, Supervisor de
Número historia: 10
Planta
Nombre de Historia: Reporte de productividad
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 1
Descripción: Como jefe del área de producción deseo visualizar un reporte en el cual
pueda analizar la cantidad de piezas producidas y la cantidad total de merma
agrupadas por centro de producción en un periodo determinado.
Tabla 12 historia de usuario reporte de pago a los operarios
Reporte de pago a los operarios
Usuario: Administradores, Jefe de Área, Supervisor de
Número historia: 11
Planta
Nombre de Historia: Reporte de productividad
Prioridad de Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 1
Descripción: Como jefe del área de producción deseo visualizar un reporte el cual
me muestre el monto a pagar a cada operario agrupados por área de producción y
por ficha de producción.
59
3.3. Plan de entrega del proyecto
Tabla 13 plan de entrega del proyecto
Historias Iteración Prioridad Esfuerzo Fecha Inicio Fecha Final
Historia 1 1 Alta 2 03/09/2018 11/09/2018
Historia 2 1 Alta 2 12/09/2018 21/09/2018
Historia 3 2 Alta 2 24/09/2018 03/10/2018
Historia 4 2 Alta 2 04/10/2018 20/10/2018
Historia 5 3 Alta 2 22/10/2018 03/11/2018
Historia 6 3 Alta 2 05/11/2018 20/11/2018
Historia 7 4 Alta 3 21/11/2018 18/01/2019
Historia 8 4 Alta 2 21/01/2019 08/02/2019
Historia 9 5 Alta 3 11/02/2019 15/02/2019
Historia 10 5 Alta 3 18/02/2019 18/03/2019
Historia 11 6 Alta 3 19/03/2019 19/04/2019
60
3.4. Cronograma de implementación del proyecto
Ilustración 8. Cronograma de implementación del proyecto
Cronograma de implementación del proecto
3/09/2018 8/10/2018 12/11/2018 17/12/2018 21/01/2019 25/02/2019 1/04/2019
Creación de permisos y grupos de usuario
Gestión de productos y servicios
Gestion de centros y rutas de produccion
Gestion de lista de materiales por producto
Gestion de ordenes de produccion
Planificacion de fichas de produccion
Registro de las ordenes de trabajo
Registro de merma
Supervision de las ordenes de trabajo
Reporte de productividad
Reporte de pago a los operarios
Fuente: elaboración propia
1
3.5. Diagrama de clases
Ilustración 9. diagrama de clases
Fuente: elaboración propia
2
Descripción de clases
Nombre de la clase Descripción
product.uom Unidades de medida para el producto
product.template Plantilla general de datos de un producto
product.category Categorías de los productos
product.product Productos reales (Materia prima,
productos terminados, servicios)
mrp.routing Rutas de producción
mrp.workcenter Centros de producción
mrp.routing.workcenter Asignación de rutas de producción en
determinados centros de producción
mrp.bom Lista de materiales de un producto
mrp.bom.line Detalle de las listas de materiales
mrp.workorder Operaciones a ejecutar
mrp.production Fichas de producción
mrp.order.production Ordenes de producción
mrp.order.line Detalle de las ordenes de producción
mrp.pago Costo mano de obra por cada operación
mrp.workcenter.productivity Tiempos de ejecución de cada operación
hr.employee Personal que labora en la empresa
stock.picking.type Tipo de movimiento de almacén
stock.location Ubicaciones de almacén
stock.move Movimientos de inventario
3
Ilustración 10: Diagrama de despliegue de odoo
Fuente: elaboración propia
4
3.6. Ciclo de vida
3.6.1. Primera iteración
Tabla 14 Historias de usuario primera iteración
Número Nombre
1 Administración de permisos y grupos de usuario
2 Gestión de productos y servicios
3.6.1.1. Tareas de ingeniería
Tabla 15 Tareas de ingeniería primera iteración
Número Número de
Nombre de la tarea
de tarea historia
1 1 Creación de los grupos de usuario necesarios
2 1 Asignación de los permisos según grupo de usuario
3 2 Adaptación del maestro de productos (terminados)
4 2 Adaptación del maestro de productos (materia prima)
3.6.1.2. Descripción tareas de ingeniería
Tabla 16 Tarea de ingeniería 1 para historia de usuario 1
Tarea de ingeniería
Número de tarea: 1 Número de historia: 1
Nombre de tarea: Creación de los grupos de usuario necesarios
Tipo de tarea: Desarrollo
Fecha inicio: 03/09/2018 Fecha fin: 05/09/2018
Descripción: Se crearán los grupos de usuario operario y supervisor mediante los
archivos de datos xml, el grupo operario incluirá los permisos de un usuario
básico de Odoo y el grupo supervisor incluirá los permisos del grupo Usuario del
módulo MRP.
5
Tabla 17 Tarea de ingeniería 2 para historia de usuario 1
Tarea de ingeniería
Número de tarea: 2 Número de historia: 1
Nombre de tarea: Asignación de los permisos según grupo de usuario
Tipo de tarea: Desarrollo
Fecha inicio: 07/09/2018 Fecha fin: 11/09/2018
Descripción: Se realizara la asignación de permisos a los grupos de usuario en
relación al acceso de los modelos del sistema
Tabla 18 tarea de ingeniería 3 para la historia de usuario 2
Tarea de ingeniería
Número de tarea: 3 Número de historia: 2
Nombre de tarea: Adaptación del maestro de productos (terminados)
Tipo de tarea: Desarrollo
Fecha inicio: 12/09/2018 Fecha fin: 17/09/2018
Descripción: Se añadirán los campos “alto, ancho, espesor y diseñador” al
modelo de productos y se modificara la vista, añadiendo una nueva pestaña
llamada “Fabricación” la cual contendrá estos nuevos campos
Tabla 19 tarea de ingeniería 4 para la historia de usuario 2
Tarea de ingeniería
Número de tarea: 4 Número de historia: 2
Nombre de tarea: Adaptación del maestro de productos (materia prima)
Tipo de tarea: Desarrollo
Fecha inicio: 18/09/2018 Fecha fin: 21/09/2018
Descripción: Para el caso de las baldosas de cerámicas que son la materia
principal de los productos terminados se añadirán los campos de “bases por
carro, número máximo de carros, metros base” y se realizara la modificación de
la vista formulario del modelo producto para añadir estos nuevos campos dentro
de la pestaña “Fabricación”
6
3.6.1.3. Pruebas de aceptación
Tabla 20. pruebas de aceptación de las historias de usuario 1 y 2
Número de la prueba Número de historia Nombre de la prueba
1 1 Acceso al sistema
2 1 Creación de usuarios
3 1 Asignación de permisos
4 2 Creación de productos
Tabla 21. Caso de prueba número 1 para la historia de usuario administración de
permisos y grupos de usuario
CASO DE PRUEBA
Código: 1 N° Historia: 1
Historia de Usuario: Administración de permisos y grupos de usuario
Condiciones de ejecución: Cada usuario debe contar con un perfil de usuario
asignado a su correo electrónico corporativo y su contraseña para poder acceder a
las funciones del sistema de acuerdo a su rol.
Entrada/pasos de jecución:
Dar clic en el enlace sesión Llenar el formulario usuario introduciendo su nombre de
usuario y contraseña Luego pulsar el botón INICIAR SESION
Resultado esperado: Acceso a las funcionalidades del sistema dependiendo del tipo
de usuario y el rol que desempeña en el mismo.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 22. Caso de prueba número 2 para la historia de usuario administración de
permisos y grupos de usuario
CASO DE PRUEBA
Código: 2 N° Historia: 1
Historia de Usuario: Administración de permisos y grupos de usuario
7
Condiciones de ejecución: El administrador tendrá que iniciar sesión en el sistema,
posteriormente proceder a la creación de un nuevo usuario
Entrada/pasos de ejecución:
Acceder al menú usuario en el módulo de configuración, darle click al botón crear y
completar los datos generales de usuario como nombre, y dirección email
Resultado esperado: Confirmar el email que se envió al correo proporcionado
creando una nueva contraseña para el acceso al sistema
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 23. Caso de prueba número 3 para la historia de usuario administración de
permisos y grupos de usuario
CASO DE PRUEBA
Código: 3 N° Historia: 1
Historia de Usuario: Administración de permisos y grupos de usuario
Condiciones de ejecución: El administrador tendrá que iniciar sesión en el sistema,
posteriormente proceder a seleccionar un usuario y habilitar los módulos
correspondientes al usuario según corresponda
Entrada/pasos de ejecución:
Acceder al menú usuario en el módulo de configuración, buscar al usuario por el
nombre, acceder a este, darle al botón de editar, y de acuerdo a las aplicaciones que
a las que tendrá acceso asignarle un rol como usuario, responsable, oficial o jefe de
área.
Resultado esperado: Acceso a las funcionalidades del sistema dependiendo del tipo
de usuario y el rol que desempeña en el mismo.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 24. Caso de prueba número 4 para la historia de usuario Gestión de productos y
servicios
CASO DE PRUEBA
Código: 4 N° Historia: 2
Historia de Usuario: Gestión de productos y servicios
8
Condiciones de ejecución: El usuario tendrá que acceder a la aplicación de
fabricación para crear un producto con los campos requeridos.
Entrada/pasos de ejecución:
El usuario tendrá que seleccionar la aplicación de fabricación, ir a la pestaña de datos
principales en el menú, seleccionar productos, hacer click en el botón de crear e
ingresar los campos como son, nombre del producto, tipo de producto, categoría
interna, referencia interna, unidad de medida
Resultado esperado: Acceso a las funcionalidades del sistema dependiendo del tipo
de usuario y el rol que desempeña en el mismo.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Ilustración 11. Pantalla de inicio de sesión
Fuente: Elaboración propia
9
Ilustración 12. Vista en modo lista de los usuarios del sistema
Fuente: Elaboración propia
Ilustración 13. Vista formulario para la creación de un nuevo usuario
Fuente: Elaboración propia
10
Ilustración 14. Vista formulario de un usuario creado y mensaje de alerta del email
enviado al correo del usuario
Fuente: Elaboración propia
Ilustración 15. Configuración de los niveles de acceso por usuario a los módulos del
ERP.
Fuente: Elaboración propia
11
Ilustración 16. Vista en modo kanban de los productos creados
Fuente: Elaboración propia
Ilustración 17. Vista formulario para la creación de un nuevo producto
Fuente: Elaboración propia
12
Ilustración 18. Vista formulario para la configuración de las características de
fabricación de un producto
Fuente: Elaboración propia
Ilustración 19. Vista en modo lista de los servicios de pago
Fuente: Elaboración propia
13
Ilustración 20. Vista formulario para la creación de un nuevo servicio de pago
Fuente: Elaboración propia
3.6.2. Segunda iteración
Tabla 25. Historias de usuario segunda iteración
Número Nombre
3 Gestión de centros y rutas de producción
4 Gestión de lista de materiales por producto
3.6.2.1. Tareas de Ingeniería
Tabla 26. Tareas de ingeniería segunda iteración
Número Número de
Nombre de la tarea
de tarea historia
5 3 Creación de relación entre centro de producción y personal
6 3 Adaptación de la vista formulario de centros de producción
14
7 4 Creación de relación entre los servicios de pago y la lista
de materiales
8 4 Adaptación del número de pasadas por serigrafía a los
servicios de pago
9 4 Modificación de la vista formulario lista de materiales
3.6.2.2. Descripción tareas de ingeniería
Tabla 27. Tarea de ingeniería 5 para la historia de usuario 3
Tarea de ingeniería
Número de tarea: 5 Número de historia: 3
Nombre de tarea: Creación de relación entre centro de producción y personal
Tipo de tarea: Desarrollo
Fecha inicio: 24/09/2018 Fecha fin: 27/09/2018
Descripción: Se heredará el modelo de centros de producción (mrp.workcenter)
para añadir la relación Many2many con el modelo del personal (hr.employee)
Tabla 28. Tarea de ingeniería 6 para la historia de usuario 3
Tarea de ingeniería
Número de tarea: 6 Número de historia: 3
Nombre de tarea: Adaptación de la vista formulario de centros de producción
Tipo de tarea: Desarrollo
Fecha inicio: 28/09/2018 Fecha fin: 03/10/2018
Descripción: Se heredará la vista formulario del modelo centros de producción
para añadir una nueva pestaña que permita agregar o eliminar el personal
15
Tabla 29. Tarea de ingeniería 7 para la historia de usuario 4
Tarea de ingeniería
Número de tarea: 7 Número de historia: 4
Nombre de tarea: Creación de relación entre los servicios de pago y la lista de
materiales
Tipo de tarea: Desarrollo
Fecha inicio: 04/10/2018 Fecha fin: 08/10/2018
Descripción: Se heredará el modelo de línea de lista de materiales (mrp.bom.line)
para agregar el servicio de pago
Tabla 30. Tarea de ingeniería 8 para la historia de usuario 4
Tarea de ingeniería
Número de tarea: 8 Número de historia: 4
Nombre de tarea: Adaptación del número de pasadas por serigrafía a los servicios
de pago
Tipo de tarea: Desarrollo
Fecha inicio: 09/10/2018 Fecha fin: 15/10/2018
Descripción: Se heredará el modelo de línea de serigrafía (mrp.serigrafia) para
agregar
Tabla 31. Tarea de ingeniería 9 para la historia de usuario 4
Tarea de ingeniería
Número de tarea: 9 Número de historia: 4
Nombre de tarea: Modificación de la vista formulario lista de materiales
Tipo de tarea: Desarrollo
Fecha inicio: 16/10/2018 Fecha fin: 20/10/2018
Descripción: Se heredará la vista de lista de materiales y se le añadirá una pestaña
de servicios de pagos.
16
3.6.2.3. Pruebas de aceptación
Tabla 32. Pruebas de aceptación segunda iteración
Número de la prueba Número de historia Nombre de la prueba
1 3 Creación de centros de
producción
2 3 Incorporación de personal a los
centros de producción
3 3 Creación de rutas de producción
4 4 Creación de la lista de
materiales
5 4 Asignación de servicios de pago
a la lista de materiales
Tabla 33. Caso de prueba 1 para la historia de usuario 3
CASO DE PRUEBA
Código: 1 N° Historia: 3
Historia de usuario: Gestión de centros y rutas de producción
Condiciones de Ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú datos principales, y acceder a
centros de producción, clic en el botón de crear y colocar el nombre del centro de
producción,
Resultado esperado: Acceso a la interfaz de centros de producción para el
mantenimiento o la creación de los centros de producción.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
17
Tabla 34. Caso de prueba 2 para la historia de usuario 3
CASO DE PRUEBA
Código: 2 N° Historia: 3
Historia de Usuario: Gestión de centros y rutas de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú datos principales, y acceder a los
centros de producción y en la vista lista clic en alguno de los centros de producción
ya creados, dentro de la vista formulario de este, en la pestaña de personal ingresar
al personal perteneciente al centro de producción para que de manera automática se
carguen estos en las ordenes de trabajo de las fichas de producción.
Resultado esperado: Añadir al personal correspondiente a los centros de
producción.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 35. Caso de prueba 3 para la historia de usuario 3
CASO DE PRUEBA
Código: 3 N° Historia: 3
Historia de Usuario: Gestión de centros y rutas de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú datos principales, y acceder a rutas
de producción clic en el botón crear y llenar los campos como son el nombre de la
ruta y las operación, en este último se debe colocar el nombre de la operación y el
centro de producción en el que ira ubicado la operación, es decir la operación está
ligada con el centro de producción.
Resultado esperado: Crear las rutas de producción, con las operaciones que
contenga esta ligadas a los centros de producción.
18
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 36. Caso de prueba 4 para la historia de usuario 4
CASO DE PRUEBA
Código: 4 N° Historia: 4
Historia de Usuario: Gestión de lista de materiales por producto
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú datos principales, y acceder a lista
de materiales, clic en crear y llenar los campos como el producto del cual se está
creando la lista de materiales, la cantidad de piezas por carro, la ruta de producción
que usara.
Resultado esperado: Crear listas de materiales de los productos.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 37. Caso de prueba 5 para la historia de usuario 4
CASO DE PRUEBA
Código: 5 N° Historia: 4
Historia de Usuario: Gestión de lista de materiales por producto
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú datos principales, y acceder a lista
de materiales, y en la vista lista seleccionar la lista de materiales a la que se le
asignaran los servicios, dentro de la vista formulario de la lista de materiales
seleccionada, en la pestaña de servicios añadir los servicios que usara la fabricación
del producto, los siguientes campos, el servicio, la cantidad (bases o piezas según
corresponda el servicio), la operación en la que aparecerá, y el número de pasadas,
solo para los servicios de pintura.
19
Resultado esperado: Asignar los servicios de pago a la lista de materiales.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Ilustración 21. Vista en modo lista de los centros de producción
Fuente: Elaboración propia
Ilustración 22. Vista formulario para la creación de un nuevo centro de producción
Fuente: Elaboración propia
20
Ilustración 23. Vista en modo lista de las rutas de producción
Fuente: Elaboración propia
Ilustración 24. Vista formulario para la creación de una nueva ruta de producción
Fuente: Elaboración propia
21
Ilustración 25. Vista en modo lista de las listas de materiales
Fuente: Elaboración propia
Ilustración 26. Vista formulario para la creación de una nueva lista de materiales
Fuente: Elaboración propia
22
3.6.3. Tercera iteración
Tabla 38. Historias de usuario tercera iteración
Número Nombre
5 Gestión de órdenes de producción
6 Planificación de fichas de producción
3.6.3.1. Tareas de ingeniería
Tabla 39. Tareas de ingeniería tercera iteración
Número Número de
Nombre de la tarea
de tarea historia
10 5 Creación del modelo ordenes de producción
11 5 Creación del menú y las vistas para las ordenes de
producción
12 5 Creación de la relación entre las fichas de producción y las
ordenes de producción
13 5 Modificación de las vistas de fichas de producción
14 6 Modificación de la vista calendario del modelo de fichas de
producción
15 6 Creación del campo unidad de medida secundaria
16 6 Creación del modelo impreso de ficha de producción
17 6 Creación de vista resumen de la ficha de producción
3.6.3.2. Descripción tareas de ingeniería
Tabla 40. Tarea de ingeniería 10 para historia de usuario 5
Tarea de ingeniería
Número de tarea: 10 Número de historia: 5
Nombre de tarea: Creación del modelo ordenes de producción
23
Tipo de tarea: Desarrollo
Fecha inicio: 22/10/2018 Fecha fin: 25/10/2018
Descripción: Se creara el modelo mrp.order.production
Tabla 41. Tarea de ingeniería 11 para historia de usuario 5
Tarea de ingeniería
Número de tarea: 11 Número de historia: 5
Nombre de tarea: Creación del menú y las vistas para las ordenes de producción
Tipo de tarea: Desarrollo
Fecha inicio: 26/10/2018 Fecha fin: 29/10/2018
Descripción: Se creará las vistas formulario de las ordenes de producción así
como la vista lista de esta
Tabla 42. Tarea de ingeniería 12 para historia de usuario 5
Tarea de ingeniería
Número de tarea: 12 Número de historia: 5
Nombre de tarea: Creación de la relación entre las fichas de producción y las
ordenes de producción
Tipo de tarea: Desarrollo
Fecha inicio: 30/10/2018 Fecha fin: 31/10/2018
Descripción: Se creará un campo que amarre las ordenes de producción a una
ficha de producción
Tabla 43. Tarea de ingeniería 13 para historia de usuario 5
Tarea de ingeniería
Número de tarea: 13 Número de historia: 5
Nombre de tarea: Modificación de las vistas de fichas de producción
Tipo de tarea: Desarrollo
Fecha inicio: 01/11/2018 Fecha fin: 03/11/2018
24
Descripción: Se modificará la vista lista para habilitar el campo estado de la ficha
de producción
Tabla 44. Tarea de ingeniería 14 para historia de usuario 6
Tarea de ingeniería
Número de tarea: 14 Número de historia: 6
Nombre de tarea: Modificación de la vista calendario del modelo de fichas de
producción
Tipo de tarea: Desarrollo
Fecha inicio: 05/11/2018 Fecha fin: 07/11/2018
Descripción: Se modificará la vista calendario de las fichas de producción para
que permita crear fichas desde esta vista
Tabla 45. Tarea de ingeniería 15 para historia de usuario 6
Tarea de ingeniería
Número de tarea: 15 Número de historia: 6
Nombre de tarea: Creación del campo unidad de medida secundaria
Tipo de tarea: Desarrollo
Fecha inicio: 08/11/2018 Fecha fin: 09/11/2018
Descripción: Se creará el campo unidad de medida secundaria para habilitar la
planificación de fichas por carros
Tabla 46. Tarea de ingeniería 16 para historia de usuario 6
Tarea de ingeniería
Número de tarea: 16 Número de historia: 6
Nombre de tarea: Creación del modelo impreso de ficha de producción
Tipo de tarea: Desarrollo
Fecha inicio: 12/11/2018 Fecha fin: 15/11/2018
25
Descripción: Se creará un reporte de la ficha de producción planificada que
incluirá el número de ficha, el producto, la cantidad en carros y piezas, el pintor,
el destino
Tabla 47. Tarea de ingeniería 17 para historia de usuario 6
Tarea de ingeniería
Número de tarea: 17 Número de historia: 6
Nombre de tarea: Creación de la vista resumen de la ficha de producción
Tipo de tarea: Desarrollo
Fecha inicio: 16/11/2018 Fecha fin: 20/11/2018
Descripción: Se creará una vista que resuma las ordenes de producción de la ficha
de producción, esta incluirá las mermas registradas y la producción total por
cada centro de producción.
3.6.3.3. Pruebas de aceptación
Tabla 48. Pruebas de aceptación tercera iteración
Número de la prueba Número de historia Nombre de la prueba
1 5 Creación de órdenes de producción
2 5 Importación de órdenes de
producción
3 6 Creación de una ficha de producción
4 5 Generación de la ficha de producción
desde la orden de producción
5 6 Impresión de la ficha de producción
6 6 Visualización del resumen por ficha
de producción
26
Tabla 49. Caso de prueba 1 para historia de usuario 5
CASO DE PRUEBA
Código: 1 N° Historia: 5
Historia de Usuario: Gestión de órdenes de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de ordenes generadas, crear una nueva orden ingresando la fecha de programación,
y el detalle de los productos con sus respectivas cantidades y el destino al que serán
enviados.
Resultado esperado: Se genera la orden de producción con un código generado por
el sistema y se crearan ordenes iniciales de los productos según su capacidad
máxima de carros.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 50. Caso de prueba 2 para historia de usuario 5
CASO DE PRUEBA
Código: 2 N° Historia: 5
Historia de Usuario: Gestión de órdenes de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de ordenes generadas, crear una nueva orden ingresando la fecha de programación,
guardar el registro y hacer clic en el botón acción e importar la orden de producción
en un archivo excel con la plantilla de órdenes de producción.
Resultado esperado: Se genera la orden de producción con un código generado por
el sistema y se crearan ordenes iniciales de los productos según su capacidad
máxima de carros.
27
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 51. Caso de prueba 3 para historia de usuario 6
CASO DE PRUEBA
Código: 3 N° Historia: 6
Historia de Usuario: Planificación de fichas de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de fichas de producción, hacer clic en uno de los cuadros de la vista calendario para
lanzar un cuadro emergente, buscar el producto, ingresar la cantidad (piezas o
carros) y elegir la lista de materiales. Hacer clic en el botón guardar.
Resultado esperado: Se generara la ficha de producción con un código generado
por el sistema y se crearan los detalles de los materiales a consumir como también
los productos terminados.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 52. Caso de prueba 4 para historia de usuario 5
CASO DE PRUEBA
Código: 4 N° Historia: 5
Historia de Usuario: Gestión de órdenes de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de líneas de op, marcar las casillas de los productos a generar la ficha de producción,
dar clic en el botón acción y dar clic en fichas de producción.
28
Resultado esperado: Se generara la ficha de producción con un código generado
por el sistema y se crearan los detalles de los materiales a consumir como también
los productos terminados por producto seleccionado.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 53. Caso de prueba 5 para historia de usuario 6
CASO DE PRUEBA
Código: 5 N° Historia: 6
Historia de Usuario: Planificación de fichas de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de producción, acceder a una de las fichas de producción generadas dar clic al botón
imprimir y dar clic a la opción ficha de producción.
Resultado esperado: Se generara un documento en formato pdf con la información
necesaria para producir el producto.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 54. Caso de prueba 6 para historia de usuario 6
CASO DE PRUEBA
Código: 6 N° Historia: 6
Historia de Usuario: Planificación de fichas de producción
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de producción, acceder a una de las fichas de producción generadas y dar clic al
botón resumen
29
Resultado esperado: Se generara una vista resumen con el estado de la operación
de los centros de producción.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Ilustración 27. Vista modo lista de las ordenes de producción
Fuente: Elaboración propia
Ilustración 28. Vista modo formulario para la creación y edición de las ordenes de
producción
Fuente: Elaboración propia
30
Ilustración 29. Ventana modal para la importación del detalle de la orden de producción
desde un archivo Excel
Fuente: Elaboración propia
Ilustración 30. Vista modo lista con la barra de progreso del detalle de las ordenes de
producción
Fuente: Elaboración propia
31
Ilustración 31. Vista modo calendario de las fichas de producción planificadas
Fuente: Elaboración propia
Ilustración 32. Ventana modal de la vista calendario para la planificación de una nueva
ficha de producción
Fuente: Elaboración propia
32
Ilustración 33. Vista en modo lista con la barra de progreso de las fichas de producción
planificadas
Fuente: Elaboración propia
Ilustración 34. Vista en modo formulario de una ficha de producción creada y planificada
Fuente: Elaboración propia
33
3.6.4. Cuarta iteración
Tabla 55. Historias de usuario cuarta iteración
Número Nombre
7 Registro de las ordenes de trabajo
8 Registro de merma
3.6.4.1. Tareas de ingeniería
Tabla 56. Tareas de ingeniería cuarta iteración
Número Número de
Nombre de la tarea
de tarea historia
18 7 Adición de campos al modelo de órdenes de trabajo
19 7 Modificación de la vista formulario del modelo ordenes de
trabajo
20 7 Diseño de interfaz para el registro de las ordenes de
trabajo
21 7 Integración de lector de código de barras
22 7 Discernir la interfaz de ficha de producción a mostrar según
el nivel de usuario
23 7 Diseño de interfaz para el registro del estado de la
operación de la orden de trabajo
24 7 Vinculación de los operarios con los servicios de pago en
las ordenes de trabajo
25 7 Mostrar campos adicionales en las ordenes de trabajo
26 8 Creación del modelo para el registro de merma
27 8 Diseñar la vista formulario para el registro de merma
28 8 Vinculación del registro de merma en la orden de
producción
34
29 8 Generar los descuentos correspondientes por las mermas
registradas
3.6.4.2. Descripción tareas de ingeniería
Tabla 57. Tarea de ingeniería 18 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 18 Número de historia: 7
Nombre de tarea: Adición de campos al modelo de órdenes de trabajo
Tipo de tarea: Desarrollo
Fecha inicio: 21/11/2018 Fecha fin: 22/11/2018
Descripción: pasadas, nro de piezas, bases, personal, estado supervisado, asignar
personal, merma
Tabla 58. Tarea de ingeniería 19 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 19 Número de historia: 7
Nombre de tarea: Modificación de la vista formulario del modelo ordenes de
trabajo
Tipo de tarea: Desarrollo
Fecha inicio: 23/11/2018 Fecha fin: 27/11/2018
Descripción: Se heredará la vista formulario del modelo de órdenes de trabajo
(mrp.workorder) para añadir los campos nuevos requeridos por el supervisor de
planta.
Tabla 59. Tarea de ingeniería 20 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 20 Número de historia: 7
Nombre de tarea: Integración de lector de código de barras
35
Tipo de tarea: Desarrollo
Fecha inicio: 28/11/2018 Fecha fin: 07/12/2018
Descripción: Se diseñará una interfaz amigable que permita la búsqueda de la
ficha de producción para el registro de la orden de trabajo correspondiente, dicha
interfaz será mostrada en los puntos de control de cada centro de trabajo
Tabla 60. Tarea de ingeniería 21 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 21 Número de historia: 7
Nombre de tarea: Integración del lector de código de barras
Tipo de tarea: Desarrollo
Fecha inicio: 10/12/2018 Fecha fin: 28/12/2018
Descripción: Desarrollar el módulo de lectura de código de barras de las fichas
de producción, con la funcionalidad de poder utilizar la cámara de los
dispositivos móviles para la lectura de los códigos de barras, haciendo uso de la
librería Quaggajs, así como instalar el periférico (lector de barras) a los diferentes
puntos de control de producción.
Tabla 61. Tarea de ingeniería 22 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 22 Número de historia: 7
Nombre de tarea: Discernir la interfaz de ficha de producción a mostrar según el
nivel de usuario
Tipo de tarea: Desarrollo
Fecha inicio: 01/01/2019 Fecha fin: 04/01/2019
Descripción: Crear grupos de acceso a las diferentes interfaces del modelo de
ficha de producción (mrp.production) según corresponda el usuario y las
operaciones que realizará.
36
Tabla 62. Tarea de ingeniería 23 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 23 Número de historia: 7
Nombre de tarea: Diseño de interfaz para el registro del estado de la operación de
la orden de trabajo
Tipo de tarea: Desarrollo
Fecha inicio: 07/01/2019 Fecha fin: 10/01/2019
Descripción: Crear los botones de iniciar, detener y finalizar para los estados de
la orden de producción, así también el escaneo de código de barras de la ficha
de producción para ir directamente a esta y no buscar de manera manual
Tabla 63. Tarea de ingeniería 24 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 24 Número de historia: 7
Nombre de tarea: Vinculación de los operarios con los servicios de pago en las
ordenes de trabajo
Tipo de tarea: Desarrollo
Fecha inicio: 11/01/2019 Fecha fin: 15/01/2019
Descripción: Relacionar a los empleados con los servicios de pago de la lista de
materiales del producto, en la vista lista de cada orden de trabajo se detallara al
empleado y el servicio por producto que le corresponde
Tabla 64. Tarea de ingeniería 25 para historia de usuario 7
Tarea de ingeniería
Número de tarea: 25 Número de historia: 7
Nombre de tarea: Mostrar campos adicionales en las ordenes de trabajo
Tipo de tarea: Desarrollo
Fecha inicio: 16/01/2019 Fecha fin: 18/01/2019
37
Descripción: Modificar por herencia de vistas, la vista formulario de las ordenes
de trabajo, para agregar los de campos de “Base”, “Piezas por base” y “cantidad
de bases”
Tabla 65. Tarea de ingeniería 26 para historia de usuario 8
Tarea de ingeniería
Número de tarea: 26 Número de historia: 8
Nombre de tarea: Creación del modelo para el registro de merma
Tipo de tarea: Desarrollo
Fecha inicio: 21/01/2019 Fecha fin: 24/01/2019
Descripción: Se desarrollara el modelo mrp.merma para el registro de merma por
cada orden de trabajo
Tabla 66. Tarea de ingeniería 27 para historia de usuario 8
Tarea de ingeniería
Número de tarea: 27 Número de historia: 8
Nombre de tarea: Diseñar la vista formulario para el registro de merma
Tipo de tarea: Desarrollo
Fecha inicio: 25/01/2019 Fecha fin: 30/01/2019
Descripción: Se desarrollara la vista wizard para el registro de merma donde se
registrara, si la merma es por piezas o base el área en que se detectó la merma,
y si esta requiere descuento o no
Tabla 67. Tarea de ingeniería 28 para historia de usuario 8
Tarea de ingeniería
Número de tarea: 28 Número de historia: 8
Nombre de tarea: Vinculación del registro de merma con la orden de producción
Tipo de tarea: Desarrollo
Fecha inicio: 31/01/2019 Fecha fin: 05/02/2019
Descripción: Se vinculara la merma a la orden de producción
38
Tabla 68. Tarea de ingeniería 29 para historia de usuario 8
Tarea de ingeniería
Número de tarea: 29 Número de historia: 8
Nombre de tarea: Generar los descuentos correspondientes por las mermas
registradas
Tipo de tarea: Desarrollo
Fecha inicio: 06/02/2019 Fecha fin: 08/02/2019
Descripción: Se registrara los descuentos al modelo mrp.pago según el servicio
de descuento de las distintas áreas
3.6.4.3. Pruebas de aceptación
Tabla 69. Pruebas de aceptación cuarta iteración
Número de la prueba Número de historia Nombre de la prueba
1 7 Generación de las ordenes de trabajo
2 7 Asignación del personal a la orden de
trabajo
3 7 Registro de la operación de la orden
de trabajo
4 8 Registro de merma
Tabla 70. Caso de prueba 1 para historia de usuario 7
CASO DE PRUEBA
Código: 1 N° Historia: 7
Historia de Usuario: Registro de las ordenes de trabajo
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
39
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de fichas de producción, dar clic en una de las fichas creadas y dar clic al botón plan
ubicado en la parte superior izquierda del formulario
Resultado esperado: Se generara los registros y las vistas con las ordenes de
trabajo según la ruta de producción
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 71. Caso de prueba 2 para historia de usuario 7
CASO DE PRUEBA
Código: 2 N° Historia: 7
Historia de Usuario: Registro de las ordenes de trabajo
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, y acceder al menú
de fichas de producción, ubicar una ficha de producción planificada, dar clic al botón
ordenes de trabajo ubicada en la parte superior derecha del formulario, seleccionar la
orden de trabajo a la cual se le asignara el personal, en la pestaña personal del
formulario orden de trabajo, dar clic agregar elemento y buscar al personal y el
servicio de pago correspondiente
Resultado esperado: Se guardara el registro del personal y el servicio de pago en la
orden de trabajo
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 72. Caso de prueba 3 para historia de usuario 7
CASO DE PRUEBA
Código: 3 N° Historia: 7
Historia de Usuario: Registro de las ordenes de trabajo
40
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario
“operario” del módulo de fabricación y se configuro previamente los equipos con la
interfaz de código de barras predeterminada para este usuario.
Entrada/pasos de ejecución:
Escanear el código de barras de la ficha de producción impresa con el lector de
códigos o con la cámara de un equipo celular, y seleccionar la operación a realizar
para el registro en la orden de trabajo
Resultado esperado: Se guardara el registro de la operación en la orden de trabajo
y se notifica en tiempo real a la interfaz de tableros de los centros de trabajo
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 73. Caso de prueba 4 para historia de usuario 8
CASO DE PRUEBA
Código: 4 N° Historia: 8
Historia de Usuario: Registro de merma
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, acceder a fichas
de producción, seleccionar una ficha de producción planificada, acceder a las
órdenes de trabajo, seleccionar una orden de trabajo, ubicar el botón de merma
ubicado en la parte superior izquierda, al hacer clic se abrirá una ventana modal,
donde se ingresara los siguientes datos, tipo de merma, la orden de trabajo, el
servicio de descuento si lo requiere, el producto (piezas o bases), y la cantidad, y dar
clic al botón guarda
Resultado esperado: Se guardará el registro de la merma en la orden de trabajo, así
como los descuentos al personal según el tipo de merma.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
41
Ilustración 35. Vista lista de las ordenes de trabajo generadas por una ficha de
producción planificada
Fuente: Elaboración propia
Ilustración 36. Vista formulario de una orden de trabajo generada desde una ficha de
producción planificada
Fuente: Elaboración propia
42
Ilustración 37. Interfaz principal para los operarios, que permite escanear el código de
barras mediante un lector de código de barras
Fuente: Elaboración propia
Ilustración 38. Interfaz que muestra las ordenes de trabajo agrupadas por centro de
producción, mostradas al escanear una ficha de producción
Fuente: Elaboración propia
43
Ilustración 39. Interfaz que permite registrar la acción a realizar en la orden de trabajo
Fuente: Elaboración propia
Ilustración 40. Interfaz para dispositivos móviles que detecta la cámara del dispositivo
para usarlo con lector de código de barras
Fuente: Elaboración propia
44
Ilustración 41. Interfaz para dispositivos móviles que permite enfocar y escanear el
código de barras de la ficha de producción
Fuente: Elaboración propia
Ilustración 42. Interfaz para dispositivos móviles que muestra las ordenes de trabajo
disponibles para su ejecución
Fuente: Elaboración propia
45
Ilustración 43. Interfaz para dispositivos móviles que permite el registro de la acción de
una orden de trabajo
Fuente: Elaboración propia
Ilustración 44. Ventana modal en las ordenes de trabajo, para el registro de merma.
Fuente: Elaboración propia
46
Ilustración 45. Vista formulario de una orden de trabajo con una merma registrada.
Fuente: Elaboración propia
Ilustración 46. Vista en modo lista de las mermas registradas en una orden de trabajo.
Fuente: Elaboración propia
47
3.6.5. Quinta iteración
Tabla 74. Historias de usuario quinta iteración
Número Nombre
9 Supervisión de las ordenes de trabajo
10 Reporte de productividad
3.6.5.1. Tareas de ingeniería
Tabla 75. Tareas de ingeniería quinta iteración
Número Número de
Nombre de la tarea
de tarea historia
30 9 Adición del botón y estado supervisado en la orden de
trabajo
31 9 Registro de personal y servicio de pago para la orden de
trabajo
32 10 Creación del modelo para el reporte de productividad
33 10 Creación de las vistas para el reporte de productividad
3.6.5.2. Descripción tareas de ingeniería
Tabla 76. Tarea de ingeniería 30 para historia de usuario 9
Tarea de ingeniería
Número de tarea: 30 Número de historia: 9
Nombre de tarea: Adición del botón y estado supervisado en la orden de trabajo
Tipo de tarea: Desarrollo
Fecha inicio: 11/02/2019 Fecha fin: 12/02/2019
Descripción: Se añadirá un botón de supervisión para validar los datos de pagos
y descuentos según corresponda en las ordenes de trabajo realizado por el
supervisor
48
Tabla 77. Tarea de ingeniería 31 para historia de usuario 9
Tarea de ingeniería
Número de tarea: 31 Número de historia: 9
Nombre de tarea: Registro de personal y servicio de pago para la orden de trabajo
Tipo de tarea: Desarrollo
Fecha inicio: 13/02/2019 Fecha fin: 15/02/2019
Descripción: Se añadirá una vista lista para que el supervisor pueda registrar al
personal y el servicio de pago según corresponda en las distintas ordenes de
trabajo
Tabla 78. Tarea de ingeniería 32 para historia de usuario 10
Tarea de ingeniería
Número de tarea: 32 Número de historia: 10
Nombre de tarea: Creación del modelo para el reporte de productividad
Tipo de tarea: Desarrollo
Fecha inicio: 18/02/2019 Fecha fin: 26/02/2019
Descripción: Se creará el modelo report.kantu.productivity con los campos
requeridos como son el centro de producción, la ficha de producción, la orden
de trabajo, la base, las piezas, nro de bases, piezas merma, bases merma, metros,
diferencia metros, todos estos campos relacionados a la vista de base de datos
creada
Tabla 79. Tarea de ingeniería 33 para historia de usuario 10
Tarea de ingeniería
Número de tarea: 33 Número de historia: 10
Nombre de tarea: Creación de las vistas para el reporte de productividad
Tipo de tarea: Desarrollo
Fecha inicio: 27/02/2019 Fecha fin: 18/03/2019
49
Descripción: Se creará las vistas del modelo report.kantu.productivity con los
campos definidos anteriormente en el modelo, se creara la vista pívot para un
manejo dinámico del reporte, así también la vista lista, y la vista de búsqueda
Ilustración 47. Vista kanban del tablero de control que muestra la información en tiempo
real del estado de las ordenes de trabajo agrupados por centro de producción
Fuente: Elaboración propia
Ilustración 48. Vista en modo lista de las ordenes de trabajo listas para la supervisión.
Fuente: Elaboración propia
50
Ilustración 49. Vista formulario de una orden de trabajo lista para la supervisión.
Fuente: Elaboración propia
Ilustración 50. Vista pivot que muestra el reporte de productividad
Fuente: Elaboración propia
51
3.6.5.3. Pruebas de aceptación
Tabla 80. Pruebas de aceptación quinta iteración
Número de la prueba Número de historia Nombre de la prueba
1 9 Supervisión de las ordenes de trabajo
2 9 Cierre de la ficha de producción
3 10 Validación del reporte de
productividad
Tabla 81. Caso de prueba 1 para historia de usuario 9
CASO DE PRUEBA
Código: 1 N° Historia: 9
Historia de Usuario: Supervisión de las ordenes de trabajo
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación, la orden de trabajo deberá de tener
el estado “terminado” y la orden que le antecede deberá estar en estado
“supervisado”.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, acceder a fichas
de producción, seleccionar una ficha de producción planificada, acceder a las
órdenes de trabajo, seleccionar una orden de trabajo, ubicar el botón de valida datos,
y hacerle clic
Resultado esperado: Se validarán los registros de pago y descuento de los
operarios.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 82. Caso de prueba 2 para historia de usuario 9
CASO DE PRUEBA
Código: 2 N° Historia: 9
Historia de Usuario: Supervisión de las ordenes de trabajo
52
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área o supervisor” del módulo de fabricación, todas las ordenes de trabajo de la
ficha de producción deben estar supervisadas.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de operaciones, acceder a fichas
de producción, seleccionar una ficha de producción planificada y supervisada, ubicar
el botón marcar como hecho ubicado en la parte superior derecha del formulario y
darle clic
Resultado esperado: El estado de la ficha de producción pasara a “realizado” y se
llevara a cabo el consumo de las materias primas y el ingreso de los productos
terminados.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
Tabla 83. Caso de prueba 3 para historia de usuario 10
CASO DE PRUEBA
Código: 3 N° Historia: 10
Historia de Usuario: Reporte de productividad
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área” del módulo de fabricación.
Entrada/Pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de informes, reporte de
productividad.
Resultado esperado: Generación del reporte en la vista pivot de productividad.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
53
3.6.6. Sexta iteración
Tabla 84. Historias de usuario sexta iteración
Número Nombre
11 Reporte de pago
3.6.6.1. Tareas de ingeniería
Tabla 85. Tareas de ingeniería sexta iteración
Número Número de
Nombre de la tarea
de tarea historia
34 11 Creación del modelo para el reporte de pago
35 11 Creación de las vistas para el reporte de pago
3.6.6.2. Descripción tareas de ingeniería
Tabla 86. Tarea de ingeniería 34 para historia de usuario 11
Tarea de ingeniería
Número de tarea: 34 Número de historia: 11
Nombre de tarea: Creación del modelo para el reporte de pago
Tipo de tarea: Desarrollo
Fecha inicio: 19/03/2019 Fecha fin: 01/04/2019
Descripción: Se creará el modelo report.mrp.production con los campos de ficha
de producción, producto, orden de trabajo, centro de producción, nro de
productos, precio, personal, servicio, pago, merma, fecha de pago, periodo, base,
nro de bases, nro de pasadas, ayudante, todos estos campos relacionados a la
vista de base de datos creada
54
Tabla 87. Tarea de ingeniería 35 para historia de usuario 11
Tarea de ingeniería
Número de tarea: 35 Número de historia: 11
Nombre de tarea: Creación de las vistas para el reporte de pago
Tipo de tarea: Desarrollo
Fecha inicio: 02/04/2019 Fecha fin: 19/04/2019
Descripción: Se crearán las vistas para el modelo anteriormente creado, como es
el caso de la vista pívot para un manejo dinámico del reporte, la vista de
búsqueda y la vista tree
Ilustración 51. Vista pivot con el reporte de pagos por centros de trabajo y personal
Fuente: Elaboración propia
55
Ilustración 52. Vista pivot del reporte de pagos por centros de trabajo y fichas de
producción
Fuente: Elaboración propia
3.6.6.3. Pruebas de aceptación
Tabla 88. Pruebas de aceptación sexta iteración
Número de la prueba Número de historia Nombre de la prueba
1 11 Validación del reporte de pago
Tabla 89. Caso de prueba 1 para historia de usuario 11
CASO DE PRUEBA
Código: 1 N° Historia: 11
Historia de Usuario: Reporte de pago
Condiciones de ejecución: El usuario deberá pertenecer al grupo de usuario “jefe
de área” del módulo de fabricación.
Entrada/pasos de ejecución:
Acceder al módulo de fabricación, ubicar el menú de informes, reporte ordenes de
producción y pagos.
56
Resultado esperado: Generación del reporte en la vista pivot de órdenes de
producción y pagos.
Evaluación de la prueba: La prueba se concluyó satisfactoriamente.
57
Capítulo IV: Resultados
4.1. Comprobación de la prospectiva
Pruebas del módulo
Las pruebas se realizaron en las áreas donde los usuarios alimentarían al sistema con
información:
- Oficina de producción
- Área de pintura de lístelos
- Área de quemado de lístelos
- Área de encajado
- Área de corte
Factibilidad técnica
Debido a que se trata de un open source, y además de no necesitar equipos potentes
para su funcionamiento, los costos son bajos, a continuación, se detalla en el siguiente
cuadro la factibilidad técnica del sistema.
Tabla 90. Tabla de factibilidad técnica
Factibilidad Técnica
Tipo de Nombre Cantidad Descripción
recurso
Humano Programadores 2 Desarrolladores de odoo
Hardware Servidor Odoo 1 - Procesador: Intel(R) Xenon(R) CPU
E31220 @ 3.10GHz, 3039 Mhz, 4
Core(s)
- Memoria RAM: 4.0 GB
- Disco: 1 TB
Computadora 2 - Procesador: Intel(R) Core(TM) i5-
7400 CPU @ 3.00GHz (4CPUs)
- Memoria RAM: 12.0 GB
- Disco: 240 GB SSD
58
Lector de 4 - Lector de código de barras USB XYL-
código de 810
barras
Monitor Táctil 4 - Monitor LED AOC E2070SWN 19.5”
HD
Mini Pcs 4 - Intel compute stick STK1AW32SC
- Procesador: Intel Atom
- Memoria RAM: 2.0 GB
- Disco: 32.0 GB
Software Servidor 1 - Ubuntu server 16.04.3 LTS
Sistema 2 - Ubuntu 18.04.4 LTS
operativo
Editor de 2 - Pycharm Community Edition 2018
código
Virtualizador de 2 - VirtualBox 5.2.26
arquitecturas
El ERP Odoo mínimamente requiere equipos de gama baja para su correcto
funcionamiento, sin embargo, considerando la escalabilidad de este en la empresa, a
futuro se están usando equipos de gama media que son aptos para la instalación de
Odoo y el desarrollo del módulo MRP Kantu.
Factibilidad Económica
Tabla 91. Tabla de recurso humano
Recurso Humano
Nombre Cantidad Costo Unitario Costo Total
Programadores 2 2000 4000
59
Tabla 92. Tabal de recurso tecnológico
Recurso Tecnológico
Hardware
Nombre Cantidad Costo Unitario Costo Total
Servidor 1 1500.00 1500.00
Computadora 2 2500.00 5000.00
Lector de código de barras 4 198.86 795.44
Monitor táctil 4 429.00 1716.00
Mini Pcs 4 596.18 2384.72
Software
Nombre Cantidad Costo Unitario Costo Total
Ubuntu server 16.04.3 LTS 1 0.00 0.00
Ubuntu 18.04.4 LTS 2 0.00 0.00
Pycharm Community Edition 2018 2 0.00 0.00
VirtualBox 5.2.26 2 0.00 0.00
El costo total del proyecto es de s/. 15,396.16 soles, esta inversión permitirá eliminar el
gasto por horas extra trabajando en la corrección de datos que se realizaba cada fin de
mes la jefatura de producción con el área de sistemas, ya que se hacían correcciones
directamente a la base de datos.
Se puede concluir que el proyecto es económicamente factible, considerando que solo
se está haciendo una inversión en hardware.
Beneficios
Los beneficios se clasificaron en dos, beneficios tangibles, beneficios intangibles.
Beneficios tangibles
Información actualizada y agilizada
Generación de reportes
Beneficios intangibles
Control adecuado de la información
Satisfacción del usuario
60
Factibilidad Operativa
Se realizó una encuesta del módulo desarrollado dirigido a los usuarios con el fin de
determinar en qué medida se cumplieron con los requerimientos y si el uso de este es
fácil, a continuación, se detallan las preguntas y los resultados de las mismas.
Tabla 93. Pregunta nro. 1
Pregunta N°1 En su opinión ¿Cuan sencillo es operar el ERP Odoo?
Alternativas
a) Muy fácil
b) Fácil
c) Indiferente
d) Difícil
e) Muy difícil
Tabla 94. Pregunta nro. 2
Pregunta N°2 ¿Qué tan satisfecho esta con los datos que muestra el
módulo MRP?
Alternativas
a) Muy satisfecho
b) Satisfecho
c) Indiferente
d) No tan satisfecho
e) Nada satisfecho
Tabla 95. Pregunta nro. 3
Pregunta N°3 A continuación encontrara los procesos más importantes de
producción, por favor señale en qué medida considera que el
módulo MRP cumplió con implementarlos
Alternativas
1. Planificación de fichas de producción 1 2 3 4 5
2. Generación de órdenes de producción 1 2 3 4 5
61
3. Registro de las ordenes de trabajo 1 2 3 4 5
4. Control de las materias primas 1 2 3 4 5
5. Reportes de productividad 1 2 3 4 5
Tabla 96. Pregunta nro. 4
Pregunta N°4 ¿Cuán satisfecho esta con el rendimiento del ERP?
Alternativas
a) Muy satisfecho
b) Satisfecho
c) Indiferente
d) No tan satisfecho
e) Nada satisfecho
Tabla 97. Pregunta nro. 5
Pregunta N°5 ¿Qué tan flexible es el módulo MRP para soportar nuevos
procesos de producción?
Alternativas
a) Muy flexible
b) Flexible
c) Indiferente
d) No tan flexible
e) Nada flexible
Tabla 98. Pregunta nro. 6
Pregunta N°6 A continuación encontrara los reportes del módulo MRP, por
favor señale en qué medida considera que el módulo MRP
cumplió con implementarlos
Alternativas
1. Reporte de productividad 1 2 3 4 5
2. Reporte de pagos 1 2 3 4 5
3. Reporte de órdenes de producción 1 2 3 4 5
4. Reporte resumen de ficha de producción 1 2 3 4 5
62
Tabla 99. Pregunta nro. 7
Pregunta N°7 ¿Recomendaría el ERP Odoo a otras organizaciones?
Alternativas
a) Si
b) No
Tabla 100. Pregunta nro. 8
Pregunta N°8 ¿Cuán satisfecho esta con la fluidez del sistema?
Alternativas
a) Muy Satisfecho
b) Satisfecho
c) Indiferente
d) No tan Satisfecho
e) Nada Satisfecho
Tabla 101. Pregunta nro. 9
Pregunta N°9 ¿Cómo valora que el ERP Odoo sea accesible desde distintos
dispositivos?
Alternativas
a) Muy bueno
b) Regular
c) Indiferente
d) No tan bueno
e) Malo
Tabla 102. Pregunta nro. 10
Pregunta N°10 ¿Qué tan satisfecho esta con el ERP Odoo en general?
Alternativas
a) Muy satisfecho
b) Satisfecho
c) Indiferente
d) No tan satisfecho
e) Nada satisfecho
63
Resultados de la encuesta
Ilustración 53: Pregunta nro 1
Fuente: Elaboración Propia
Ilustración 54: Pregunta nro 2
Fuente: Elaboración Propia
64
Ilustración 55: Pregunta nro 3
Fuente: Elaboración propia
Ilustración 56: Pregunta nro 4
Fuente: Elaboración propia
65
Ilustración 57: Pregunta nro 5
Fuente: Elaboración propia
Ilustración 58: Pregunta nro 6
Fuente: Elaboración propia
66
Ilustración 59: Pregunta nro 7
Fuente: Elaboración propia
Ilustración 60: Pregunta nro 8
Fuente: Elaboración propia
67
Ilustración 61: Pregunta nro 9
Fuente: Elaboración propia
Ilustración 62: Pregunta nro 10
Fuente: Elaboración propia
Los resultados de la encuesta demuestran que el módulo es operativamente factible al
cumplir en gran medida con los requerimientos, además de ser cómodo para los usuarios
ya que Odoo es bastante intuitivo.
68
4.2. Cumplimiento de objetivos
Objetivo 1: Optimizar la planificación de los procesos de fabricación mediante el
módulo MRP.
Las optimizaciones de la planificación de los procesos de fabricación se cumplieron
mediante las siguientes características.
Integración de áreas: integramos a todas las áreas involucradas en los procesos de
producción con el fin de tener un único canal de flujo de información y eliminar la
redundancia del registro de los datos en herramientas informáticas complementarias.
Información en tiempo real: se consideró la participación de los operarios de producción
como responsables del registro de las operaciones de producción, para de esta forma
eliminar el llenado manual de las fichas de producción por parte de los supervisores.
Control de tiempos de producción: los operarios participan en el registro de las fichas de
producción mediante el registro del inicio y fin de sus operaciones con la finalidad de
tener un control del proceso productivo y medir sus tiempos de productividad.
Objetivo 2: Controlar el consumo de materiales e insumos necesarios para la
producción mediante el módulo MRP
Mediante la implementación del módulo de inventario, como dependencia del módulo
MRP se hicieron uso de las listas de materiales las cuales permiten un mejor control sobre
las materias primas al especificar las proporciones necesarias para la producción de
cierto número de productos. Esta funcionalidad también permite llevar el control del stock
y generar provisiones anticipadas para evitar un desabastecimiento.
Mediante el módulo MRP se generan las ordenes de salida de almacén de los insumos
usados, directamente en el módulo de inventario, así como también las ordenes de
entrada de los productos terminados, manteniendo la información de la disponibilidad de
los productos e insumos al día.
69
Objetivo 3: Desarrollar un módulo complementario que permita la extensión y
modificación de la estructura estándar del módulo MRP, para el soporte integral de
los procesos de negocio del área de producción.
Las ejecuciones de las iteraciones del proyecto se enfocaron principalmente en el
desarrollo complementario al módulo MRP para el soporte de todos los procesos de
fabricación. Se logró modelar un esquema de trabajo dinámico el cual podrá contemplar
cualquier cambio en el proceso de fabricación. Adicionalmente se pudo comprobar la
flexibilidad de la estructura del ERP Odoo al permitir modificaciones en la estructura de
los modelos y el de las vistas sin alterar el código fuente.
4.3. Contribuciones (impacto)
Con la implementación del MRP Odoo logramos soportar todas las líneas de
producción (configurando las rutas de producción), integrándolos en una misma
interfaz, de esta forma facilitamos y ordenamos el trabajo de planificación y
generación de las ordenes de producción. También eliminamos el trabajo extra de
corrección de data llevado a cabo anteriormente entre el personal de supervisión
de producción y del área de sistemas.
Mediante la implementación del ERP Odoo logramos integrar las áreas
involucradas en el proceso de producción, entregando a los supervisores y jefe del
área información en tiempo real e integral de todo el proceso productivo, con el
objetivo de tener un mejor control y visión global, que permita analizar a detalle los
acontecimientos suscitados.
Mediante el módulo de stock (dependencia del módulo MRP) se permite llevar un
mejor control de los insumos utilizados para la producción, pronosticando su
abastecimiento y adquisición a tiempo.
Los reportes dinámicos desarrollados (vistas pívot) ofrecen un análisis inteligente
de las fichas de producción, pudiendo analizar en una misma vista distintas
variables como por ejemplo costos de producción de cierta cantidad de productos,
cantidad de piezas producidas por cada área, costo de mano de obra de cada
área, etc. De esta forma se brinda una herramienta poderosa al jefe de producción
que lo ayudara a tomar mejores decisiones.
70
Se dio a conocer las características de desarrollo del ERP Odoo, demostrando sus
capacidades de desarrollo ágil, que permite enfocarnos principalmente en los
procesos de negocio y facilitándonos las cuestiones técnicas como la creación de
las vistas conjuntamente con un potente motor ORM que permite modelar nuestra
aplicación.
Con la implementación del ERP Odoo se brinda la posibilidad de escalabilidad
permitiendo crecer a medida, ya que Odoo cuenta con todo un pack de módulos
gratuitos que pueden servir de base para la administración de las demás áreas de
la empresa, con el objetivo de tener toda la información centralizada para de esta
forma garantizar la integridad y disponibilidad de la información.
71
Conclusiones
El ERP Odoo tiene las herramientas y la capacidad para ser implementado en
cualquier rubro empresarial, la base de módulos ofertados gratuitamente dispone
de una funcionalidad estandarizada internacionalmente que sirven de base
principal para el desarrollo de módulos nuevos. La estructuración modular de
Odoo, permite a los desarrolladores crear aplicaciones personalizadas de gran
variedad, lo que permite tener una gran comunidad de desarrolladores dispuestos
a crear soluciones que se pueden compartir de manera gratuita, como también ser
ofertados a un costo monetario.
El módulo MRP de Odoo presentó un esquema estandarizado en la administración
de los procesos de producción, el cual ayudó a replantear la forma de trabajo
convirtiéndolo en un modelo más ordenado y controlado, con información mejor
estructurada que permite consultar la información de manera más rápida y
detallada.
El desarrollo del módulo MRP Kantu permitirá a la empresa analizar las diferentes
variables del proceso de producción, tales como: el tiempo de ejecución de cada
operación del proceso productivo, la cantidad de materia prima consumida por
cada producto, y el costo del recurso humano, para de esta forma verificar el costo
beneficio de los diferentes productos a manufacturar.
Mediante la implementación del MRP Odoo se pone a disposición la posibilidad de
configurar diferentes líneas productivas permitiendo a la empresa incluir la
producción de cualquier tipo de producto.
La implementación del sistema permitió evidenciar que el principal factor a tener
en cuenta es el humano ya que depende mucho de éste el buen funcionamiento
de cualquier sistema, y no necesariamente la tecnología usada por ello es de suma
importancia la constancia en el uso del nuevo sistema de los usuarios para que
estén más familiarizados con su funcionamiento.
72
Recomendaciones
Considerar la escalabilidad de Odoo para su implementación en todas las áreas
de la empresa, teniendo en cuenta que se tiene un conjunto de módulos y
aplicaciones que tienen un funcionamiento estandarizado que se puede
aprovechar para su extensión y personalización según los requerimientos, de esta
manera se optimiza la comunicación y el flujo de los datos entre las distintas áreas
de la empresa.
La gestión modular de Odoo, ofrece la posibilidad de extender y modificar las
aplicaciones y/o módulos existentes a través del desarrollo de nuevos módulos,
por lo que se recomienda evitar modificar el código fuente directamente de las
aplicaciones y/o módulos. No existe razón de hacer una modificación directa del
código fuente, la herencia en Odoo nos permite modificar tanto las vistas como la
lógica del negocio programadas en los módulos.
Exhortar a los usuarios a mantener el sistema constantemente alimentado de
información para que éste pueda trabajar de manera eficiente y sin errores.
Programar un backup periódico de la base de datos principal para salva guardar
la información y poder prevenir futuros inconvenientes.
73
Bibliografía
About us: Odoo. (2004-2019). Obtenido de Odoo:
https://www.odoo.com/es_ES/page/about-us
Arias G, F. (2012). EL PROYECTO DE INVESTIGACION Introduccion a la Metodologia
Cientifica (6ta Edicion ed.). Caracas: Suplidora Van, C.A.
Arias, A., & Durango, A. (2016). Ingenieria y Arquitectura del Software. IT campus
Academy.
Beck, K., & Andres, C. (2012). Extreme Programming Explained. Masachusetts: Pearson
Education Inc.
Berndtsson, M., Hansson, J., Olsson, B., & Lundell, B. (2008). Thesis Projects A Guide
for Students in Computer Science. Londres: Springer-Verlag.
Berrospi Ramirez, M. A. (2012). Implantacion de un Sistema de Ventas que emplea una
herramienta de Data Mining (Tesis de Pregrado). Pontificia Universidad Catolica
del Peru, Lima.
Binstock, C., Peterson, D., Smith, M., Wooding, M., Dix, C., & Galtenberg, C. (2012). The
Xml Schema Complete Reference. Boston: Pearson Education.
Companys Pascual, R., & Fonollosa i Guardiet, J. (2007). Nuevas tecnicas de gestion de
stocks: MRP y JIT. Mexico D.F.: AlfaOmega.
Davenport, T. (1998). Putting the Enterprise into the Enterprise System. Harvard Business
Review. Cambridge.
Dizzet Utria, G. (2017). IMPLEMENTACION DE UN SISTEMA ERP COMO SOPORTE
EN LA TOMA DE DECISIONES PARA LA IPS AMESCO (Tesis de grado).
Universidad de Cartagena, Cartagena.
Docplayer. (s.f.). Obtenido de https://docplayer.es/67906121-Creacion-de-un-portal-web-
con-odoo-y-un-servidor-de-correo-electronico-corporativo-para-el-equipo-formula-
student-upv.html
Flanagan, D. (2010). Javascript The Definitive Guide. California: O'Relly.
Fuertes garcia, S. (2013). Seleccion e Implantacion de un Sistema ERP de Codigo
Abierto. Barcelona: Universidad Oberta de Catalunya.
Gauchat, J. D. (2012). El Gran Libro de HTML5, CSS3 y JavaScript. Barcelona - España:
MARCOMBO.
74
Heisig, G. (2002). Planning Stability in Material Requirements Planning Systems. Paris:
Springer.
Hermosa Agius, J. J., Montero Navarro, A., Romo Romero, S. M., De Pablos Heredero,
C., Izquierdo Loyola, V. M., & Najera Sanchez, J. J. (2000). INFORMATICA
APLICADA A LA GESTION DE EMPRESAS. Madrid: ESIC.
initiative, O. s. (1998-2019). About - History: Open Source Initiative. Obtenido de
Opensource.org: https://opensource.org/history
J. M., R. (2008). Estudio para la Implantacion de un ERP para una Empresa de
Transportes (Proyecto fin de Carrera). Universidad Autonoma de Barcelona,
Barcelona.
Kumar Garg, V. (2011). ENTERPRISE RESOURCE PLANNING Concepts and Practice.
Nueva Delhi: PHI Learning.
Lainez Fuentes, J. (2016). Desarrollo de Software Agil Extreme Programming y Scrum.
IT campus academy.
Leon, A. (2008). ENTERPRISE RESOURCE PLANNING . Nueva Delhi: Tata McGraw-
Hill.
Leon, A. (s.f.). SlidePlayer. Obtenido de SlidePlayer Inc:
https://slideplayer.com/slide/7468335/
Llanos Bardales, J. (2017). EFECTIVIDAD EN EL DESEMPEÑO DE LOS PROCESOS
DE NEGOCIO DE LA AGROVETERINARIA LA FORTALEZA SRL DE LA CIUDAD
DE CAJAMARCA UTILIZANDO UN SISTEMA DE PLANIFICACION DE
RECURSOS EMPRESARIALES Odoo BAJO LA METODOLOGIA IPEE (Tesis de
Pregrado). Universidad Nacional de Cajamarca, Cajamarca.
Manuel Esteves, J., & A. Pastor, J. (1999). An ERP Lifecycle-based Research Agenda.
1st International Workshop on Enterprise Managment and Resource Planning:
Methods, Tools and Architectures. Catalunya.
Manufacturing features. (2018). Obtenido de Odoo:
https://www.odoo.com/es_ES/page/manufacturing-features
Martinez, S. (2010). Metodologia de Implantacion del ERP Microsoft Dynamics NAV.
75
Mogrovejo Bucheli, J. A. (2017). IMPLEMENTACION DEL ERP OPEN SOURCE ODOO
EN UNA PYME (Tesis de Postgrado). Escuela Superior politecnica del Litoral,
GUAYAQUIL.
Moss, G. (2015). Working with Odoo. Birmingham: Pack Publishing.
Muñiz, L. (2004). ERP Guia practica para la seleccion e Implantacion ERP: Enterprise
Resource Planning o Sistema de Planificacion de Recursos Empresariales.
Madrid: Gestion 2000.
Navajas Ojeda, A. (s.f.). Guía Completa de CSS3. CC-BY-NC.
Nuñez Burgos, R. (2016). Software ERP Analisis y Consultoria de Software Empresarial.
Madrid: IT Campus Academy.
O Droualliet, P. (2012). La Importancia de la Implementacion de un Sistema ERP en las
PyMES. Veracruz: Universidad Veracruzana.
Oberhofer, C. (07 de Junio de 2017). QuaggaJS. Obtenido de
https://serratus.github.io/quaggaJS/
Object, R. A. (25-29 de Julio de 2011). OSCON. Obtenido de O'Reilly Open Source
Software Conference:
https://conferences.oreilly.com/oscon/oscon2011/public/schedule/detail/18953
P. H., M. (2014). Estado del Arte de los Sistemas ERP. Buenos Aires: Universidad de
San Andres.
Peñas López, A. (2016). Implantacion del ERP Odoo en una PYME dedicada al Comercio
Minorista (Tesis de Pregrado). Universidad de Valladolid, Valladolid.
Prins, K., Gallowey, G., Fassaert, C., & Nilsson, M. (1998). II Taller de Investigación
Participativa Buscando la convergencia. Turrialba: CATIE.
Reis, D. (2016). Odoo 10 Development Essentials. Birmingahm, Mumbai: Packt.
ROHAUT, S. (2017). LINUX Dominar la administracion del sistema. Barcelona: ENI.
Ronda Carracao, M. Á. (2015). UF1883: Instalacion de sistemas ERP-CRM. Madird:
EDITORIAL ELEARNING S.L.
S.A., O. (2015). https://www.odoo.com. Obtenido de
https://www.odoo.com/documentation/10.0/.
Salas, Y. (2018). Aprendiendo Node.JS.
76
Toledo, R. (2010). Servicios de Gestion Empresarial para PYMEs: Un caso Practico de
SaaS (Software as a Service). (Proyecto fin de Carrera). Universidad Politecnica
de Cartagena, Cartagena.
Valle, A., Puerta, A., & Nuñez, R. (2017). Curso de Consultoria TIC. Gestion, Software
ERP y CRM. Vigo: IT Campus Academy.
Vargas Cordero, Z. R. (2009). LA INVESTIGACIÓN APLICADA: UNA FORMA DE
CONOCER LAS REALIDADES CON EVIDENCIA. REVISTA EDUCACIÓN, 155-
165.
Wallace, D., Raggett, I., & Aufgang, J. (2012). Extreme Programming for Web Projects.
Masachusetts: Pearson Education.
Weber, S. (2004). The Success of Open Source. Massachusetts: Harvard University
Press.
77