UNIVERSIDAD DON BOSCO DIRECCIÓN DE EDUCACIÓN A DISTANCIA TRABAJO DE GRADUACIÓN PARA OPTAR AL GRADO DE: MAESTRO EN ARQUITECTURA DE SOFTWARE PROYECTO: ANÁLISIS Y DISEÑO PARA LA IMPLEMENTACIÓN DE ARQUITECTURA ORIENTADA A MICROSERVICIOS DE UN ERP ON PREMISE, ENFOCADO EN EL PROCESO DE VENTAS DE UNA EMPRESA DE TECNOLOGÍA EN EL SALVADOR. PRESENTADO POR: MARIO STANLEY ESPINOZA CORRALES FRANCISCO ERNESTO MELÉNDEZ GÓMEZ ASESOR: MG. JUAN JOSÉ VENTURA GÓMEZ ANTIGUO CUSCATLÁN, LA LIBERTAD, EL SALVADOR, CENTRO AMÉRICA MAYO 2023 Agradecimientos Agradecimientos Francisco Meléndez Quiero agradecer primeramente a Dios y a María Auxiliadora por haberme guiado en esta aventura, me encuentro eternamente agradecido con mis padres Evelyn y Francisco quienes siempre me exhortaron a seguir adelante con este proyecto que en ocasiones llegó a complicarse pero que se está culminando, también quiero agradecerle a Stanley con quien pudimos hacer el desarrollo de este documento, con quien logramos coincidir en este proceso desde el inicio, con quien me apoyé muchísimo, también agradecerle a Kattya y a Josué con quienes siempre estuvimos trabajando y apoyándonos en todo momento, a pesar que en algún momento no pudimos trabajar juntos, pero siempre nos estuvimos comunicando y ayudando ante cualquier duda o necesidad, por último quiero agradecer a Jackeline por siempre animarme cuando me encontraba desmotivado y a Helguito quien siempre me acompañó todas las noches estudiando y haciéndome compañía. Agradecimientos Stanley Espinoza Doy gracias al Altísimo por permitir llegar a esta instancia en la vida, pudiendo terminar un peldaño más en mi crecimiento profesional y como persona, por permitirme cursar esta maestría y obtener más experiencia, conocimiento y nuevas personas brindan valor agregado educativo, laboral y profesional. Doy gracias a mi familia que con su apoyo incondicional he podido llegar a esta instancia y lograr una nueva meta en mi carrera profesional, a su vez, a cada una de esas personas que estuvieron conmigo durante este proceso de aprendizaje de esta carrera y que brindaron su apoyo inigualable en cualquier circunstancia. Siempre estaré eternamente agradecido y llevan un espacio en mi corazón cada palabra dicha para animarme a seguir adelante. Agradezco a mi compañero de trabajo Francisco Meléndez por el acompañamiento y dedicación en el desarrollo de este trabajo de graduación, así también doy gracias a mis compañeros de asignaturas Kattya Martínez y Josué Castillo por su esmero apoyo y amistad desde el día uno de aprendizaje en el transcurso de esta carrera. Agradezco al personal de la Dirección de Educación a Distancia de la Universidad Don Bosco, catedráticos, dirección, asesor y todas las personas que han hecho posible la culminación de este proceso de formación profesional. Resumen El servicio al cliente en las empresas es fundamental, debido a que las mismas deben de mantener su buena reputación y así los usuarios podrán recomendarse este lugar, es por ello que una compañía se debe de enfocar en poder atender todas las necesidades del mismo de la forma más eficiente, por lo que se debe de brindar apoyo, asesoría y orientación y demás puntos para poder facilitar el proceso. Actualmente se ha identificado que en múltiples empresas es una de las debilidades principales, debido a que en muchas ocasiones no hay sistema, este es muy lento o deja de responder y se tiene que hacer reprocesos donde el cliente llega a enojarse y en algunos casos puede hasta dejar de ir a consumir esos productos, es por ello que se identificó y se encuentra viable una propuesta de mejora de arquitectura en el proceso de ventas. A través de este medio se expone análisis y diseño de procesos actuales y sus posibles mejoras a los mismos, se brinda un prototipo el cual aportará a visualizar las falencias que se encuentran en los sistemas actuales y como estas pueden ser mejoradas o erradicadas si así fuese el caso, con la propuesta se podrá comprender la necesidad de implementaciones de sistemas separados de módulos de seguridad, facturación, orden de trabajo, orden de compra e inventario y como estas se comunican con un sistema legado, mejorando tiempos de respuesta, eliminando errores, mostrando buenas prácticas y respuestas del sistema ante posibles problemas. Se muestra metodología utilizada para poder obtener los requerimientos necesarios para migrar el sistema y sus resultados, cronograma con los entregables del proyecto, se describe el personal necesario y sus roles para poder realizar el mismo, también se podrá visualizar infraestructura y arquitectura propuesta para su correcto funcionamiento. Al implementar cambios en la arquitectura actual se obtendría un sistema más eficiente el cual se adaptará a los cambios de una forma más sencilla, también será más amigable al usuario y tendrá documentación actualizada, repercutiendo en un sistema más fácil de comprender y más organizado a comparación del sistema monolítico actual. Tabla de Contenidos Lista de Abreviaturas y Símbolos .......................................................................................... 1 Introducción ........................................................................................................................... 3 Capítulo 1 Formulación general del proyecto ....................................................................... 5 1.1 Valor pedagógico y/o innovación que presenta el proyecto ................................. 5 1.2 Datos sobre la organización objetivo .......................................................................... 6 1.3 Relevancia social ......................................................................................................... 8 1.4 Objetivos del proyecto ................................................................................................. 8 1.4.1 Objetivo General .................................................................................................. 8 1.4.2 Objetivos específicos ............................................................................................ 8 1.5 Descripción del producto ............................................................................................. 9 Capítulo 2 Fundamentación teórica ..................................................................................... 10 2.1 Patrón de diseño ........................................................................................................ 10 2.2 Arquitectura monolítica ............................................................................................. 12 2.3 Arquitectura orientada a servicios SOA. ................................................................... 14 2.3.1 SOAP (Simple Object Access Protocol) ............................................................ 17 2.3.2 REST ...................................................................................................................... 19 2.3.3 Cola de Mensajes ................................................................................................ 20 2.4 Arquitectura orientada a Microservicios ................................................................... 21 2.4.1 Diferencias entre la arquitectura orientada a los microservicios y los sistemas monolíticos ............................................................................................................................ 25 2.5 Infraestructura On Premise ........................................................................................ 26 2.6 ERP ............................................................................................................................ 28 Capítulo 3 Metodología ....................................................................................................... 29 3.1 Alcance ...................................................................................................................... 29 3.2 Limitaciones .............................................................................................................. 30 3.3 Hoja de ruta para recolección de datos ...................................................................... 31 3.3.1 Datos necesarios por recolectar .......................................................................... 31 3.3.2 Métodos de recolección de datos ........................................................................ 32 3.3.3 Métodos de validación de los datos obtenidos ................................................... 33 3.4 Proceso de recolección de datos ................................................................................ 33 3.4.1 Reuniones Discovery .......................................................................................... 33 3.4.2 Entrevista ................................................................................................................ 34 3.4.3 Estado actual de operaciones .............................................................................. 35 3.4.4 Problemas encontrados ....................................................................................... 38 3.5 Hoja de ruta para propuesta de solución.................................................................... 41 3.5.1 Análisis de la situación actual de la empresa ..................................................... 41 3.5.2 Oportunidades de mejora al implementar la solución propuesta ........................ 41 3.5.3 Análisis de componentes y procedimientos de sistema ...................................... 42 3.5.4 Análisis de recursos para la implementación ..................................................... 43 3.5.5 Refinamiento de lista de requisitos de la empresa .............................................. 44 3.5.6 Diseño de la propuesta de solución .................................................................... 44 Capítulo 4 Propuesta de solución ........................................................................................ 45 4.1 Diagnóstico de proyecto ............................................................................................ 46 4.1.1 Análisis de situación actual ................................................................................ 46 4.1.2 Oportunidades de mejora .................................................................................... 60 4.2 Análisis de recursos para la implementación ............................................................ 76 4.2.1 Tiempo estimado ................................................................................................ 77 4.2.2 Recursos humanos .............................................................................................. 77 4.2.3 Recursos físicos y virtuales ................................................................................ 78 4.2.4 Recursos financieros ........................................................................................... 80 4.3 Levantamiento de requerimientos ............................................................................. 83 4.3.1 Identificación de procesos afectados .................................................................. 83 4.3.2 Personal involucrado actualmente en los procesos ............................................ 84 4.3.3 Análisis de componentes y procedimientos de sistema ...................................... 88 4.3.4 Requerimientos funcionales y no funcionales .................................................. 100 4.4 Planificación de implementación ............................................................................ 103 4.4.1 Descripción de funciones en el proyecto .......................................................... 103 4.4.2 Cronograma de implementación....................................................................... 104 4.4.3 Arquitectura y tecnología de software propuesta ............................................. 105 4.4.4 Infraestructura propuesta .................................................................................. 106 4.5 Prototipo .................................................................................................................. 107 4.5.1 Obtención de Reporte de Venta ........................................................................ 109 4.5.2 Obtención de Reporte de Venta por Id ............................................................. 110 4.5.3 Crear Reporte de Venta .................................................................................... 111 4.5.4 Obtener Productos ............................................................................................ 112 4.5.5 Obtener Productos por Id.................................................................................. 113 4.5.6 Crear Orden de Compra .................................................................................... 114 4.5.7 Obtener Órdenes de Compra ............................................................................ 115 4.5.8 Obtener Órdenes de Compra por Id .................................................................. 116 4.5.9 Crear Ingreso a Bodega .................................................................................... 117 4.5.10 Obtener Ingresos a Bodega ............................................................................. 118 4.5.11 Obtener Ingresos a Bodega por Id .................................................................. 119 4.5.12 Crear Salida de Bodega .................................................................................. 120 4.5.13 Obtener Salidas de Bodega ............................................................................. 121 4.5.14 Obtener Salidas de Bodega por Id .................................................................. 122 4.5.15 Obtención de órdenes de trabajo .................................................................... 123 4.5.16 Obtención de órdenes de trabajo por medio de identificación ....................... 124 4.5.17 Creación de órdenes de trabajo ....................................................................... 125 4.5.18 Obtención de facturas ..................................................................................... 126 4.5.19 Creación de facturas ....................................................................................... 127 4.6 Cierre de proyecto ................................................................................................... 128 4.6.1 Plan de cierre .................................................................................................... 128 4.6.2 Base de Conocimiento a Entregar .................................................................... 128 4.6.3 Carta de aceptación........................................................................................... 130 Conclusiones...................................................................................................................... 131 Recomendaciones .............................................................................................................. 133 Referencias ........................................................................................................................ 136 Anexos ............................................................................................................................... 139 Lista de tablas Tabla 1. Recursos físicos por utilizar en la implementación del proyecto. 78 Tabla 2. Recursos virtuales por utilizar en la implementación del proyecto. 79 Tabla 3. Recursos financieros a utilizar en la implementación del proyecto. 81 Tabla 4. Identificación de procesos 83 Tabla 5. Descripción de roles 85 Tabla 6. Matriz RACI 87 Tabla 7.Tabla de Narrativa de módulo de ventas 89 Tabla 8. Tabla de Narrativa de módulo de inventario 92 Tabla 9. Tabla de Narrativa de módulo de orden de compra 94 Tabla 10. Tabla de Narrativa de módulo de Orden de Trabajo 96 Tabla 11.Tabla de Narrativa de microservicio de Facturación 99 Tabla 12.Base de conocimiento sobre microservicios 128 Lista de figuras Figura 1. Estructura Organizacional de la empresa ........................................................................ 7 Figura 2.Estructura de arquitectura monolítica ............................................................................. 13 Figura 3.Estructura de arquitectura basada en colas de mensajes. ............................................... 21 Figura 4.Diagrama de arquitectura Orientada a Microservicios. .................................................. 23 Figura 5. Inversiones a realizar de CAPEX y OPEX en una infraestructura on premise. ............ 28 Figura 6.Proceso General de Ventas y Facturación de Empresa .................................................. 36 Figura 7. Esquema general de módulos del proceso de ventas de la empresa .............................. 47 Figura 8.Diagrama de casos de uso de sistema de administración de venta de la empresa .......... 49 Figura 9.Diagrama descriptivo del proceso de ventas de la empresa Dada y Dada & Compañía. 52 Figura 10.Diagrama de Secuencia de ventas del Área Comercial. ............................................... 54 Figura 11.Diagrama de Secuencia de ventas del Área Administrativa. ........................................ 55 Figura 12.Diagrama de Secuencia de Orden de Trabajo y Facturación. ...................................... 58 Figura 13.Diagrama de Arquitectura Tecnológica. ....................................................................... 60 Figura 14. Diagrama de Caso de Uso del módulo de ventas ........................................................ 89 Figura 15. Diagrama de proceso de microservicio de reporte de ventas ...................................... 91 Figura 16.Diagrama de Caso de Uso del módulo de inventario ................................................... 92 Figura 17. Diagrama de Caso de Uso del módulo de inventario .................................................. 93 Figura 18.Diagrama de Caso de Uso de Orden de Compra .......................................................... 94 Figura 19.Diagrama de proceso de microservicio de orden de compras ...................................... 95 Figura 20.Diagrama de Caso de Uso de Orden de Trabajo .......................................................... 96 Figura 21.Diagrama de proceso de microservicio de orden de trabajo ......................................... 97 Figura 22. Diagrama de Caso de Uso de Facturación ................................................................... 99 Figura 23. Diagrama de proceso de microservicio de facturación .............................................. 100 Figura 24.Cronograma de actividades para la implementación de proyecto de microservicios de proceso de ventas de la empresa Dada Dada y Cía ............................................................. 104 Figura 25.Diagrama de Arquitectura y tecnología de software propuesta.................................. 105 Figura 26.Diagrama de Arquitectura propuesta .......................................................................... 106 Figura 27. Diagrama de Infraestructura propuesta ..................................................................... 107 Figura 28 Obtención de Reporte de Venta. ................................................................................. 109 Figura 29.Obtener Reporte de Venta por Id................................................................................ 110 Figura 30.Crear Reporte de Venta. ............................................................................................. 111 Figura 31.Obtención de Productos .............................................................................................. 112 Figura 32. Obtención de Productos por Id. ................................................................................. 113 Figura 33.Crear Orden de Compra.............................................................................................. 114 Figura 34.Obtener Órdenes de Compra ...................................................................................... 115 Figura 35.Obtener Órdenes de Compra por Id............................................................................ 116 Figura 36.Crear Ingreso a Bodega .............................................................................................. 117 Figura 37.Obtener Ingresos a Bodega ......................................................................................... 118 Figura 38.Obtener Ingresos a Bodega por Id .............................................................................. 119 Figura 39.Crear Salida de Bodega .............................................................................................. 120 Figura 40.Obtener Salidas de Bodega ......................................................................................... 121 Figura 41.Obtener Salidas de Bodega por Id .............................................................................. 122 Figura 42.Obtención de órdenes de trabajo ................................................................................ 123 Figura 43.Obtención de órdenes de trabajo por Id ...................................................................... 124 Figura 44. Creación de órdenes de trabajo .................................................................................. 125 Figura 45. Obtención de facturas ................................................................................................ 126 Figura 46. Creación de facturas .................................................................................................. 127 Lista de Abreviaturas y Símbolos CRM: Customer Relationship Management (Gestión de relaciones con el cliente). Es una estrategia para gestionar todas las relaciones e interacciones de una empresa con sus clientes potenciales y existentes. Un sistema CRM ayuda a las empresas a mantenerse en contacto con los clientes, agilizar los procesos y mejorar la rentabilidad. DMS: Dada Multi-communication System. Plataforma perteneciente a Dada Dada y Cía. ERP: Enterprise Resource Planning (Sistema de planificación de recursos empresariales). Es un sistema que ayuda a automatizar y administrar los procesos empresariales de distintas áreas: finanzas, fabricación, venta al por menor, cadena de suministro, recursos humanos y operaciones. HTTP: Hypertext Transfer Protocol, es un protocolo que permite la comunicación entre quien posee la información y el solicitante, gracias a este, pueden transmitir la información por la red. HTML:HyperText Markup Language es un lenguaje en el que se hace la definición del contenido de las páginas web. IoT: Internet of Things (Internet de las cosas), consiste en la interconexión digital de los objetos de la vida cotidiana mediante internet. IVR: Interactive Voice Response (Respuesta de voz interactiva). Es una tecnología de telefonía automatizada que interactúa con las personas que llaman, recaba la información requerida y enruta las llamadas al destinatario o bien al sector apropiado dentro de la empresa. Inbound: Son llamadas telefónicas realizadas al servicio al cliente o equipo de soporte de una empresa por parte del cliente. IP-PBX: IP Private Branch Exchange (Central Privada Automática por IP), hace referencia a cualquier central telefónica conectada directamente a la red pública de telefonía por medio de líneas troncales para gestionar además de las llamadas internas, las entrantes y salientes con autonomía sobre cualquier otra central telefónica. JSON: JavaScript Object Notation, consiste en un formato de intercambio de datos el cual es independiente del lenguaje. On Premise: Tipo de instalación de una solución de software, la cual consiste dentro del servidor y la infraestructura de la empresa. Outbound: Son llamadas producidas cuando el representante es quien llama al cliente primero y funcionan como un soporte extra. PHP: Hypertext Preprocessor, es un lenguaje que se utiliza para el desarrollo web, a diferencia de HTML, este maneja la forma en la que funciona un sitio y se ejecuta en el servidor. RPC: Remote Procedure Call, se le conoce a la técnica que sirve para la comunicación entre procesos que están conectados a una red. WS-I: Web Services Interoperability Organization consiste en fomentar la interoperabilidad de los servicios web sobre cualquier aplicación, lenguaje de programación y plataforma. XML: Extensible Markup Language sirve para intercambiar información entre distintas plataformas, permitiendo la compatibilidad entre sistemas XLT: XML representation of Lexicons and Terminologies es una aplicación que se basa en XML con el objetivo de facilitar el intercambio de terminologías. Introducción Las micro y pequeñas empresas en El Salvador llevan varios años operando y optan por mantener las actividades y tecnologías utilizadas sin realizar actualizaciones, ni inversiones en soluciones tecnológicas por muchos años, realizando sus operaciones con equipos y sistemas, antiguos, obsoletos y sin soporte. Esto conlleva a un impacto en la operatividad de las organizaciones, dado que los procesos de negocio dependen de las soluciones tecnológicas y la productividad que estos generan, dando un valor agregado de competitividad en el mercado por la calidad de servicio en respuesta y orden que se brinda. Por lo tanto, las instituciones que no realizan inversiones en modernización de sus plataformas y sistemas quedan rezagadas dentro del mercado e industria en el que se desarrollan. Con esto pierden crecimiento de su cartera de clientes y la atracción de clientes potenciales. A su vez, sus operaciones con el pasar del tiempo se volverán engorrosas y difíciles de controlar automáticamente, necesitando siempre de la intervención humana en el flujo de trabajo y retrasando la agilidad de respuesta con respecto a la calidad del servicio brindado al cliente. Existen muchos diseños de arquitecturas tecnológicas que cumplen las condiciones necesarias, para poder satisfacer los requerimientos de negocio de las organizaciones. Sin embargo, su costo de implementación sobrepasa los presupuestos destinados a tecnología que puedan tener las micro y pequeñas empresas. Es por ello que una alternativa es la adopción de arquitecturas orientadas a microservicios. La implementación de una arquitectura orientada a microservicios permite crecer no solamente en innovación tecnológica, sino en productividad de las operaciones y posicionamiento de mercado. Particularmente para las pequeñas empresas estas innovaciones se convierten en puntos críticos. En el presente documento se realiza una propuesta de análisis y diseño para la implementación de una arquitectura orientada a microservicios, enfocado en el proceso de ventas de la empresa Dada Dada y Compañía en El Salvador tomando en cuenta la evaluación de los procesos pertenecientes al negocio, ajustándose a los requerimientos, costos, tiempo, recursos, alcances y limitaciones. La estructura del documento se organiza en las siguientes secciones: Formulación del proyecto donde se da a conocer la importancia de este, Descripción de la organización y objetivos; Fundamentación teórica, la cual contiene los conceptos necesarios para el entendimiento del objeto de estudio, Metodología con los análisis realizados al proyecto y Presentación de la propuesta de diseño donde se brindará a la empresa la solución de integración a sus sistemas legado y procesos de ventas. Capítulo 1 Formulación general del proyecto 1.1 Valor pedagógico y/o innovación que presenta el proyecto El proceso de desarrollo de aplicaciones presenta varios retos, siendo uno de ellos el mantenimiento a largo plazo del código, dado que implica una inversión en tiempo. En cualquier industria y/o mercado los procesos de negocio cambian constantemente, lo que provoca que las empresas estén más atentas a ellos, para poder adecuar su desarrollo Así mismo, la rapidez en las exigencias de implementación, para poder alinear los cambios a la operación. Con todo esto se debe tener la menor cantidad de impactos negativos al negocio. Las empresas están adoptando el diseño de la arquitectura orientada a microservicios, esta es aceptada por los equipos de desarrollo por ser modular y reutilizable, ahorrando tiempo de trabajo, brindando agilidad y eficiencia a las solicitudes de los clientes; en contraste de un enfoque monolítico el cual es muy complejo de dar mantenimiento. El diseño de una arquitectura orientada a microservicios permitirá a la empresa, ser independiente de desarrollos realizados por proveedores, dado que el personal interno perteneciente al departamento de desarrollo de sistemas se capacitará en la arquitectura mencionada. Posibilitando el enfoque de los desarrollos institucionales de forma ágil. La propuesta de diseño y actualización de los sistemas existentes de la empresa Dada y Dada & compañía a una arquitectura orientada a microservicios, proporcionará los conocimientos necesarios para poder realizar implementaciones en los productos y servicios que esta ofrece y ayudará a sus empresas cliente que utilizan sus servicios a implementar dicho diseño, a su vez tendrán personal capacitado en las tecnologías que están en auge, debido a que únicamente se harían integraciones entre la nueva arquitectura y los sistemas heredados. 1.2 Datos sobre la organización objetivo Dada Dada y Cía. S.A. de C.V. es una empresa dedicada a la venta de soluciones tecnológicas en hardware y software, especializada en las comunicaciones, infraestructura, instalación e implementación de proyectos de TI, soporte a usuarios. La empresa fue fundada en 1925 en el área metropolitana, inició como proveedora de cableado e instalación de servicios de telecomunicaciones, fue evolucionando, agregando más productos y acuerdos con otros proveedores. La empresa cuenta con su propia plataforma de telecomunicaciones basada totalmente en software, denominada DMS (Dada Multicommunications System), el cual contiene diferentes módulos como IP-PBX (Private Branch Exchange) corporativo, Call Center Inbound y Outbound, marcación automática, phonebook interactivo, sistema de IVR (Interactive Voice Response), plataforma para grabación de conversaciones, sistema de tickets para helpdesk, módulos CRM (Customer Relationship Management), entre otros. A su vez realizan soluciones tecnológicas basadas en Inteligencia Artificial y basados en IoT (Internet of Things). Misión: Asegurar el mejor servicio a nuestros clientes en soluciones de tecnología a través de un equipo de personas capaces, honestas y comprometidas Valores 1. Respeto por el individuo y trato justo: Creemos que una pieza fundamental de nuestra empresa es el equipo humano que trabaja con nosotros, por ello entendemos que son una parte fundamental de la organización a la que le debemos respeto y garantizamos un trato de iguales. 2. Trabajo con integridad y honradez: Nuestros clientes y proveedores merecen un trato íntegro y honrado a la hora de trabajar con ellos. 3. Compromiso y cumplimiento de resultados: Buscamos ser aliados estratégicos de nuestros clientes y caminar con ellos en la búsqueda de soluciones en telecomunicaciones que logren sus objetivos de negocios a costos competitivos. En la Figura 1 se presenta la estructura organizacional de Dada Dada y Cía. Figura 1. Estructura Organizacional de la empresa Nota. Elaboración Propia. 1.3 Relevancia social La solución propuesta para el “Análisis y Diseño para la implementación de arquitectura orientada a microservicios de un ERP On Premise, enfocado en el proceso de ventas” permitirá establecer puntos de mejora en la calidad de los servicios brindados por parte de la empresa a sus clientes, a través del rediseño de la arquitectura de módulo de ventas. Con esta propuesta se elaborará un prototipo no funcional que permitirá realizar acciones referentes al módulo de ventas bajo una arquitectura orientada a microservicios, la cual posibilita la comunicación con el sistema legado de la institución, así como la optimización de procesos y la entrega de información íntegra a los usuarios. 1.4 Objetivos del proyecto 1.4.1 Objetivo General − Diseñar una arquitectura orientada a microservicios en la implementación de un ERP On Premise, para el proceso de ventas de una empresa de tecnología en San Salvador, con enfoque a la optimización. 1.4.2 Objetivos específicos − Investigar el flujo operativo del módulo de ventas de Dada Dada y Cía. con el fin de conocer más sobre la problemática a solventar. − Identificar los requerimientos necesarios tanto funcionales como no funcionales, para la realización de la propuesta de arquitectura de integración de un ERP del módulo de ventas. − Analizar los procesos que realiza el ERP de la empresa, enfocándose en el sistema de ventas con el uso de buenas prácticas, para entregar una plataforma que sustituya las aplicaciones desarrolladas previamente. − Presentar una propuesta de diseño de un ERP orientado a microservicios del módulo de ventas de la empresa con base al estudio realizado. − Realizar un prototipo no funcional de arquitectura informática, relacionado a la integración de un ERP orientado a microservicios del módulo de ventas, involucrando los procesos de disponibilidad de producto y proceso de facturación simple, para demostrar el funcionamiento de la aplicación incorporada a los demás sistemas de la empresa. 1.5 Descripción del producto Con el desarrollo del proyecto se tiene la expectativa de implementar nuevas tecnologías orientadas a microservicios en el departamento de tecnología de la información de Dada y Dada & compañía, para ello se va a desarrollar un prototipo no funcional, enfocado en el proceso del módulo de ventas, el cual será la base para que se pueda modernizar cada uno de los procesos ya existentes. Se espera que el departamento adopte este enfoque porque así se tendrán menos errores por procesos legados. Debido a que esta tecnología es muy usada, es un estándar que posee mucha documentación en internet y en libros. Si dado el caso hay personal que dejara de trabajar para la empresa, este conocimiento de la arquitectura, para los nuevos empleados, podrá ser comprendido de una forma rápida, ya que posee una curva de aprendizaje baja. Por medio de este proyecto se determinará si implementar microservicios y nuevas tecnologías, mejoran los tiempos de respuesta por parte del sistema. También, se comprobará si con esta actualización, se tiene un flujo de trabajo más eficiente. Es por ello que a partir de la entrega del prototipo no funcional, se podrá observar las mejoras a obtener y se podrá realizar comparaciones en los tiempos de procesamiento y de respuesta que tiene el sistema propuesto y el que posee la competencia, con el fin de poder ver qué ventajas existen al realizar este tipo de implementaciones. Capítulo 2 Fundamentación teórica 2.1 Patrón de diseño Se le conoce como patrones de diseño a las soluciones a problemas comunes que se poseen en el ámbito del desarrollo de software que permiten obtener procesos de manera más ágil, cabe mencionar que para su correcto funcionamiento, se debe de conocer cada patrón y las bondades que estos presentan en conjunto a un diseño que se haya realizado cuidadosamente, entre algunos beneficios se encuentran la reducción de la complejidad del código y el fácil acoplamiento entre estos. Con base en Larman (2004), se tienen los siguientes patrones. Polimorfismo Se conoce al Polimorfismo como al diseño de clases pertenecientes a un mismo objeto con la característica de comportarse de una forma distinta con base a la necesidad que posea el sistema, esto quiere decir que un objeto podría tener la posibilidad de cambiar su comportamiento según la información que ha recibido de una clase externa. Fábrica Este Patrón permite que una clase se encargue de poder delegar a subclases el proceso de crear objetos, quiere decir que se pueden crear objetos sin la obligación de especificar su clase exacta, así el objeto posee las características de poder intercambiarse sin complejidad ni dificultades. La implementación de este patrón de diseño se especifica por medio de una interfaz o por la clase hijo, luego el método se encarga de ser el constructor de la clase normal, con el fin de poder separar la creación de los objetos con los ya existentes. Observador Consiste en una interfaz que se comunica con los componentes que poseen dependencia entre sí cuando un evento ha ocurrido, con el objetivo que estos reaccionen y realicen cambios internos para que puedan mantenerse sincronizados. Siempre que exista una modificación en un sistema, se va a notificar a los demás elementos y así se ejecutarán las acciones necesarias para que cada objeto cambie si fuese necesario. Singleton Es una sola clase, la cual es la responsable de crear un objeto que debe permitir el acceso directo sin tener que instanciarlo de la clase, un ejemplo de ello y donde más se utiliza es cuando se tiene una sola conexión a la base de datos, esta es compartida por múltiples objetos, si se hicieran múltiples conexiones, se consumiría muchos recursos y se afectaría el rendimiento de la aplicación y del motor de base de datos. 2.2 Arquitectura monolítica En la arquitectura de software existen varios estilos para crear una aplicación, una de ellas es la arquitectura monolítica, esta consiste en la elaboración de un sistema que sea autosuficiente y posea absolutamente toda la funcionalidad necesaria para realizar las operaciones por las cuales fue diseñado. Uno de sus atributos principales es la independencia de complementos externos que aporten a su funcionalidad, por lo que todos los componentes que posee el sistema trabajan en conjunto, compartiendo los mismos recursos de procesamiento y memoria en el dispositivo donde se encuentre alojado. Según Iturralde, B. O. J. (2020), menciona que una arquitectura monolítica en pocas palabras es una unidad cohesiva de código, construido como una sola unidad de software creado a partir de varios módulos o librerías, empaquetado en un todo como una aplicación principal. La arquitectura monolítica tiene como antecedentes los inicios de la informática computacional, dado que todas las aplicaciones que se creaban se realizaban de manera que pudieran ser autosuficientes sin depender de ningún otro software, sino que dicha aplicación contendría todas las propiedades necesarias para funcionar. Recientemente, con la llegada de las tecnologías web y el desarrollo de internet permitieron la oportunidad de realizar nuevas arquitecturas modulares, que daban la posibilidad de separar cada operación en una unidad funcional de software, sencilla, manejable y fácil de administrar. A pesar del auge de nuevos diseños arquitectónicos en software, la arquitectura monolítica es muy utilizada a día de hoy, siendo totalmente indispensable en operaciones de las empresas, en su mayoría compañías pequeñas que desean llevar sus registros de negocio en un sistema. La forma de poder estructurar una arquitectura monolítica conlleva aparte de una serie de paquetes bien organizados, con código limpio que al momento de ser publicados son exportados en un compilado único de salida para su funcionamiento. En la figura 2 de Iturralde (2020) se representa el resultado de una compilación de un software con arquitectura monolítica. Figura 2.Estructura de arquitectura monolítica Nota. Tomado de Iturralde, J. O. B. (2020) El diseño de un aplicativo en arquitectura monolítica es beneficioso para los equipos pequeños de desarrollo, debido a su único componente de publicación, realizando las implementaciones relativamente rápidas. A su vez, permite la realización de pruebas en sus funcionalidades de manera sencilla puesto que todo se realiza en la misma aplicación y no es necesario dependencias externas. Sin embargo, la implementación de este tipo de arquitectura implica una serie de desventajas que a largo plazo afecta al funcionamiento: − Los procesos de negocio de las empresas pueden quedar aferrados a un stack tecnológico con qué trabajar, debido a que el software es una sola unidad. − La complejidad de escalamiento de la aplicación tiende a crecer en proporción al tamaño del software, utilizando muchos recursos en funcionalidades que no se necesitan. − A medida que la aplicación va creciendo, resulta más complicado para los equipos de desarrollo dividir el trabajo y la complejidad de las modificaciones a realizar. − La concentración de todas las funcionalidades en una sola aplicación corre el riesgo que, si falla una funcionalidad, falla todo el sistema. − Si el desarrollo utiliza malas prácticas, es más fácil perder el alcance de las funcionalidades de la aplicación por lo que las modificaciones resultan engorrosas y abrumadoras. 2.3 Arquitectura orientada a servicios SOA. Se conoce a la arquitectura orientada a los servicios como al diseño de software, que posee la característica de reutilizar sus elementos por medio de la comunicación en red con un lenguaje común, a través de interfaces de servicios. Un servicio según IBM (2022), consiste en funciones encapsuladas en un sistema autónomo, modular que tiene como objetivo dar una solución a las necesidades de los clientes, estas se encargan de realizar una tarea específica, por ejemplo, la entrega de datos por medio de una red. También contienen el código necesario para poder realizar procesos empresariales, debe de poder acceder a éste de forma remota y ser independiente de los demás servicios existentes SOA se encarga de realizar la integración de los elementos del software que se encuentran y se mantienen por separado, con el fin que se comuniquen y al unirlos, puedan entregar una aplicación funcional con base a lo solicitado por el cliente. SOA surge como una solución a la necesidad de conectar una aplicación con los servicios de otro sistema, los cuales se hacían con integraciones profundas, la cual consistía en realizar traducciones de los modelos de datos de los otros sistemas, se creaba una configuración engorrosa para poseer conectividad y enrutamiento de los datos, todo este proceso tenía que repetirse cada ocasión que se deseaba integrar sistemas. A este tipo de sistemas se le conoce como monolíticos, los cuales tienen la variante de ser un sólo código para toda la aplicación, si había algún problema en el sistema, se tenía que dar de baja toda la implementación, hasta que se publicara una solución nueva. SOA utiliza protocolos estándar de red, para poder realizar el proceso de acceso a datos (SOAP, colas de mensaje, REST, etc.), por ese motivo no se necesita que los desarrolladores tengan que realizar el complejo proceso de integrar desde cero, sino que se puede utilizar un patrón llamado bus de servicio empresarial, para poder realizar la integración y ponerlos a disposición, de esa manera se pueden reutilizar estos en lugar de estar creando nuevos. Al utilizar este tipo de arquitectura, la información se transmite por medio de una red, se realiza un proceso empresarial, uniendo funciones independientes y así se estaría creando una aplicación. Entre algunas ventajas que se posee frente al enfoque monolítico según lo investigado por Red Hat (2022). se encuentran: − Comercialización más rápida y mayor flexibilidad: la posibilidad de reutilizar los servicios agiliza y simplifica el proceso de ensamblaje de las aplicaciones. Los desarrolladores no tienen que empezar siempre desde cero, tal como sucede con las aplicaciones monolíticas. − Uso de la infraestructura heredada en los mercados nuevos: la SOA permite que los desarrolladores tomen las funciones de una plataforma o un entorno y las ajusten e implementen en otros nuevos. − Reducción de los costos gracias a una mayor agilidad y un desarrollo más eficiente − Mantenimiento sencillo: dado que todos los servicios son autónomos e independientes, se puede modificar y actualizar cada uno cuando sea necesario, sin afectar al resto. − Escalabilidad: la SOA posibilita la ejecución de los servicios en varios lenguajes de programación, servicios y plataformas, lo cual aumenta la escalabilidad de forma considerable. Además, utiliza un protocolo de comunicación estandarizado con el que las empresas pueden disminuir la interacción entre los clientes y los servicios, lo cual permite ajustar las aplicaciones con menos presiones e inconvenientes. − Mayor confiabilidad: la SOA genera aplicaciones más confiables, ya que es más fácil depurar servicios pequeños que un código de gran volumen. − Gran disponibilidad: las instalaciones de la SOA están disponibles para todos. SOA posee tres funciones principales, las cuales consisten en crear servicios web y mantenerlos disponibles a quienes los necesiten, poseer y brindar información de estos a los solicitantes, gestionar si este debe ser privado o si es visible al público, finalmente permitir la búsqueda con base al registro. 2.3.1 SOAP (Simple Object Access Protocol) Se le conoce de esta manera al protocolo utilizado para el intercambio de información en entornos que no se encuentran centralizados, el objetivo de SOAP es transmitir información desde un originador hacia un destinatario, este protocolo puede combinarse y así realizar patrones de petición(request)/respuesta(response). SOAP posee la habilidad de ser independiente del transporte, pero en la mayoría de los casos, este proceso se realiza por medio de HTTP, con el fin de poder utilizar la infraestructura de Internet, SOAP funciona por medio del uso de servicios web y de habilitación del enlace, los servicios web se encargan de direccionar mensajes. SOAP tiene como base XML, los cuales se dividen en tres partes en todos los mensajes, según lo investigado por IBM (2021) se encuentran: − Envelope (Sobre): Este define una infraestructura para describir qué hay en un mensaje y cómo procesarlo. Un mensaje SOAP es un sobre que contiene cero o varias cabeceras (headers) y exactamente un cuerpo (body). Es el elemento superior del documento XML que proporciona un contenedor para la información de control, la dirección de un mensaje y el mensaje en sí. Las cabeceras transportan información de control como por ejemplo atributos de calidad de servicio. El cuerpo contiene la identificación del mensaje y sus parámetros. Tanto las cabeceras como el cuerpo son elementos hijo del sobre. − Reglas de codificación. El conjunto de reglas de codificación expresa instancias de tipos de datos definidos por la aplicación. Las normas de codificación definen un mecanismo de serialización que se puede utilizar para intercambiar instancias de tipos de datos definidos por la aplicación. SOAP define un esquema de tipo de datos independiente del lenguaje de programación basado en XSD y normas de codificación para todos los tipos de datos definidos de acuerdo con este modelo. La codificación SOAP no es compatible con WS-I, por lo tanto, se sugiere el uso Literal (que no está codificado) para servicios Web interoperables y se requiere para la compatibilidad con WS-I, según Microsoft (2022), se conoce a WS-I como una especificación para servicios web junto a ampliaciones e interpretaciones que permiten la interoperabilidad para SOAP. − Estilos de comunicación. Las comunicaciones pueden seguir el formato RPC (llamada a procedimiento remoto) u orientado a mensajes (Documento). Estos se describen a continuación. SOAP posee dos estilos de comunicación, uno consiste en RPC o llamada a procedimiento remoto, el cual según lo investigado por IBM (2022), consiste en la invocación con respuesta de un resultado, donde se incluyen llamadas de procesos por lotes, llamadas de difusión y procedimientos de devolución de llamadas, todas estas se hacen por medio de cifrado SOAP, el otro estilo se conoce como documento u orientado a documento o a mensaje, es más trabajo de programación. SOAP posee estilos de codificación, donde están los procesos de conversión de formatos de protocolos determinados, a esta parte se le conoce como serialización y deserialización, para ello se hace por medio de Codificación SOAP o por XML literal, donde se debe de leer el documento, sin codificación alguna. 2.3.2 REST Se conoce como REST (Representational State Transfer), a una interfaz de programación la cual se ajusta a los límites de arquitectura de este tipo, esta permite la comunicación con los servicios web RESTful. Las API son protocolos usados para la integración de software, se considera como un contrato entre el usuario y el encargado de realizar el proceso de entrega de la información, se define específicamente lo necesario por un consumidor y por el productor. El consumidor es quien hace una petición por medio del servicio web o request y el productor es el encargado de generar una respuesta hacia la solicitud, a este elemento se le conoce como response. Una API realiza el proceso de comunicarse con un sistema con el fin de obtener información o llamar una función que invoque a los procesos necesarios para entender lo solicitado y brindar una respuesta, a nivel empresarial se utiliza REST para compartir recursos y datos conservando seguridad y auditoría sobre quién o qué sistema hizo la solicitud y en qué horarios y fechas se le entregaron los datos. La información que se intercambia se hace por medio de HTTP, cualquiera de los siguientes formatos: JSON, XLT, HTML, PHP o texto sin formato, En este tipo de sistemas el lenguaje más utilizado es JSON, debido a que es comprendido tanto por las personas cómo las máquinas. Otro aspecto muy importante es REST, consiste en la revisión de los encabezados y los parámetros enviados en la información a intercambiar, debido a que esta se utiliza para identificar, autorizar y responder solicitudes generadas por los sistemas. Para que una API sea considerada RESTful, según lo definido por Red Hat (2020) debe de poseer las siguientes características: − Arquitectura cliente-servidor compuesta de clientes, servidores y recursos, con la gestión de solicitudes a través de HTTP. − Comunicación entre el cliente y el servidor sin estado, lo cual implica que no se almacena la información del cliente entre las solicitudes de GET y que cada una de ellas es independiente y está desconectada del resto. − Datos que pueden almacenarse en caché y optimizan las interacciones entre el cliente y el servidor. − Código disponible según se solicite (opcional), es decir, la capacidad para enviar códigos ejecutables del servidor al cliente cuando se requiera, lo cual amplía las funciones del cliente. 2.3.3 Cola de Mensajes Se conoce como cola de mensajes a la comunicación de servicios utilizada por arquitectura de microservicios y sin servidor, la cual a diferencia de REST y SOAP posee la característica de ser asíncrona, los mensajes son almacenados en las colas hasta que pueden ser procesados y eliminados. Otra característica que poseen las colas de mensajes consiste en que estos se procesan sólo una vez y los utiliza un sólo consumidor, estas tienen como funcionalidad poder dividir el trabajo a realizar en pequeños componentes, reduciendo carga de procesamiento de estos, de forma que se ahorran recursos que usualmente son usados en los demás tipos de arquitecturas basados en servicios web. Según lo mencionado por Amazon Web Services (2021) Una cola de mensajes ofrece un búfer ligero que almacena temporalmente los mensajes, y puntos de enlace que permiten a los componentes de software conectarse a la cola para enviar y recibir mensajes. Estos suelen ser pequeños y pueden ser solicitudes, respuestas, mensajes de error o, sencillamente, información. Para enviar un mensaje, un componente llamado productor añade uno nuevo a la cola. Este se almacena, hasta que otro componente llamado consumidor, lo recupera y hace algo con él. Figura 3.Estructura de arquitectura basada en colas de mensajes. Nota. Adaptado de arquitectura basada en colas de mensaje [Imagen], por Amazon Web Services, 2021, AWS (https://aws.amazon.com/es/message-queue/). CC BY 2.0 Muchos consumidores y productores pueden usar la cola de mensajes de forma concurrente, pero cada mensaje sólo puede procesarse una vez, es por ello que este patrón es conocido como punto a punto. 2.4 Arquitectura orientada a Microservicios La arquitectura orientada a microservicios permite el desarrollo de aplicaciones divididas en pequeños servicios independientes, realizando sus operaciones con sus propios recursos de procesamiento y memoria, comunicándose con otros servicios, en la mayoría de los casos, por medio de una API (Application Programming Interface, por sus siglas en inglés) de recursos HTTP. La implementación de este tipo de arquitectura permite la independencia de procesos de negocio a un solo módulo, siendo estos modulares y escritos aún en diferentes lenguajes de programación, tecnologías y forma de implementación. Cada servicio convertido en componente unitario se puede desarrollar, implementar y escalar de manera sencilla, sin afectar el funcionamiento normal de otros servicios dentro de la aplicación. Esta independencia con la que se caracteriza la arquitectura orientada a microservicios permite el enfoque en la resolución de problemas específicos, siendo los desarrollos por implementar fáciles de entender y la complejidad de la aplicación se ha dividido en cada uno de los componentes de esta. Para Ekuan (2022), además de los propios servicios, existen otros componentes que deben de tomarse en cuenta dentro de una arquitectura típica de microservicios: − Administración, orquestación e implementación. Este es un componente responsable de la armonía entre los servicios, la publicación de estos en los nodos y la identificación de fallos y errores dentro de los servicios. − API Gateways. En la mayoría de los casos de implementación de arquitecturas de microservicios los clientes debidamente identificados, tienen una API como punto de entrada para los servicios, donde se realizan los llamados a las funciones que son requeridas para el negocio y donde los servicios responden a las peticiones enviadas. Utilizar API Gateways permite desacoplar los clientes de los servicios, dando lugar a modificaciones, actualizaciones o refactorizaciones de los servicios sin necesidad de actualizar a los clientes que los consumen. Figura 4.Diagrama de arquitectura Orientada a Microservicios. Nota. Tomado de Ekuan (2022). Utilizar un diseño de arquitectura en microservicios puede ser muy beneficioso para las empresas debido a las siguientes características. − Permiten la agilidad, debido a su independencia y su fácil administración de errores y correcciones, se pueden llegar a implementar cambios rápidamente sin afectar el flujo de operaciones de la empresa − Posibilita que los desarrollos en microservicios puedan ser fácilmente administrados por equipos pequeños, para su implementación y pruebas. − Es independiente a la plataforma y tecnología, siendo en su mayoría de los casos desarrollos puntuales con base de código pequeña, lo que resulta fácil posteriormente agregar nuevas características a la misma. − Están diseñados para poder aislar los errores puntuales al momento de un servicio individual falla o no está disponible, sin interrumpir toda la aplicación. − Los servicios pueden escalarse de forma independiente y de forma horizontal a la aplicación para los subsistemas que requieran más recursos, esto es posible mediante un orquestador que permita el manejo de todos los servicios publicados. Sin embargo, según Fowler (2014), la aplicación de un diseño de arquitectura de microservicios puede resultar en consecuencias graves para la operatividad de la empresa si el equipo informático que lo está implementando no poseen las competencias básicas para realizar una instalación de esta índole. Algunos requisitos previos que se pueden mencionar para poder optar por microservicios es que los equipos implementadores de los sistemas puedan realizar de forma óptima las siguientes competencias. − Al momento de realizar cambios físicos en la infraestructura, debe poseer la capacidad de realizar un aprovisionamiento rápido sin que los servicios estén de baja durante mucho tiempo, para ello es necesario que exista un grado alto de automatización en la publicación de los compilados de los servicios. − Debido a la gran cantidad de servicios que puedan estar disponibles para el funcionamiento de la aplicación, es probable que al momento de que suceda un error o fallo sea más difícil de detectar, por lo que el equipo debe de tener poseer un régimen de monitoreo de cada uno de los servicios para poder detectar los problemas de manera ágil, ya sean problemas técnicos o del negocio. − Se debe poseer procesos de implementación rápida, teniendo automatizados los entornos de prueba y la publicación a entornos de producción, por lo que es necesario un cambio organizacional importante colaborando entre desarrolladores y operaciones, a esto se le conoce como la cultura DevOps. La aplicación de esta cultura permite tener mejores reacciones a modificaciones en los servicios y poder tener una mejor gestión de incidentes que involucren a los equipos de desarrollos o de operaciones. Adicional a esto, para poder tener una implementación exitosa de microservicios se debe de tomar en cuenta aspectos como el manejo adecuado de la complejidad del sistema, la correcta gestión de los desarrollos y pruebas de los servicios, la correcta gobernanza en los desarrollos de los servicios, aplicando normas y buenas prácticas en las mismas, planes de contingencia para los fallos, latencias y congestión en red, velar por la integridad de datos, y un correcto uso de los versionados de la aplicación. 2.4.1 Diferencias entre la arquitectura orientada a los microservicios y los sistemas monolíticos Una de las principales diferencias que se puede mencionar es la descentralización de cada una de sus funcionalidades y gobernanza de la aplicación, dado que, en los sistemas monolíticos, todo se rige a través de un mismo componente, procesamiento y recursos para todas las operaciones a realizar. En una arquitectura orientada a microservicios la descentralización le permite tener un enfoque horizontal de cada uno de los componentes que definen a la aplicación, permitiendo su fácil modificación a un servicio en específico, las actualizaciones afectarían solamente al componente deseado. Debido a la estructura de las arquitecturas monolíticas, resulta complejo implementar su escalabilidad, no obstante, en una arquitectura orientada a microservicios la escalabilidad puede ser a uno o varios componentes específicos teniendo en cuenta que quien sufre el cambio es la funcionalidad y no la aplicación como tal. En términos de fallos de disponibilidad una desventaja que poseen los sistemas monolíticos es la caída de un componente, pues debido a esto, la aplicación entera tiende a colapsar. Para los sistemas orientados a microservicios, si un componente falla, este puede ser aislado sin afectar la operatividad de los demás servicios que componen la aplicación por lo que sus funcionalidades pueden seguir disponibles aún con la caída del servicio con errores. 2.5 Infraestructura On Premise Las infraestructuras on premise se refieren al tipo de instalación de una solución de software que es implementada localmente o “in-situ”, es decir dentro de los servidores o infraestructura informática de las empresas, utilizado comúnmente para aplicaciones empresariales. En este tipo de modelo, la compañía es responsable de toda la gestión de la aplicación, incluyendo seguridad, disponibilidad y mantenimiento de este. Esto implica que debe poseer un departamento capacitado para realizar las funciones necesarias para cumplir con el funcionamiento de la infraestructura implementada. En este tipo de instalaciones permite para los equipos de infraestructura informáticas de las empresas mayor control en la gestión de esta, sin embargo, la inversión inicial resulta ser arriesgada pues es muy costoso para la compañía, a su vez en la mayoría de este tipo de infraestructuras no soportan todas las plataformas, por lo que se debe realizar una inversión mayor o recurrir a proveedores de servicios de infraestructura. Al momento de realizar una implementación de software, sobre todo en las infraestructuras on premise, se deben de tomar en cuenta tanto los recursos físicos necesarios como los gastos operativos recurrentes para mantener la solución disponible, por ello, hay que analizar detalladamente la inversión que se requiere. Según European Knowledge Center for Information Technology (2019), existen dos tipos de inversiones que deben ser consideradas para las inversiones de infraestructuras de software: − CAPEX (Capital Expenditures o Inversiones de bienes de capital). Aquí entran todos los activos y bienes que compra la empresa, como servidores, equipos de red, gabinetes, entre otros. − OPEX (Operating Expenses o Costes de funcionamiento). Son todos los gastos continuos para el funcionamiento de la empresa, como electricidad, servicios de internet, licencias, entre otros. En la siguiente figura se muestran ejemplos de los servicios que entran en cada tipo de inversión a infraestructuras on premise realizada por las empresas. Figura 5. Inversiones a realizar de CAPEX y OPEX en una infraestructura on premise. Nota. Tomado de European Knowledge Center for Information Technology (2019). 2.6 ERP Según Microsoft (2018). ERP (Enterprise Resource Planning), es un sistema que permite la automatización y administración de los procesos que realizan las empresas en múltiples áreas: ventas, recursos humanos, operaciones, finanzas, etc. Para poder operar un sistema ERP, es necesario que este tenga accesibilidad a la información de cada departamento, luego la integra, elimina la que no es necesaria ayudando a los altos mandos a realizar la toma de decisiones y optimizando operatividad. ERP proporciona conocimiento de todo el negocio de una forma integral, de esta manera permite poder hacer cambios y mejoras al negocio, para poder hacerlo escalable, adelantarse a posibles problemas y poder superar obstáculos. Entre algunas características y ventajas de los ERP, se encuentran mayor control sobre las áreas, por la automatización y priorización de actividades que ofrece este sistema, reducción de errores y mejoras en productividad y eficiencia a nivel empresarial, se evita la duplicidad de la información, datos más precisos y la coordinación de los equipos, debido a que entre departamentos el flujo y el acceso a los datos es más rápido gracias a estos sistemas que poseen la información general centralizada, evitando estancamientos en los procesos . Capítulo 3 Metodología 3.1 Alcance Para este proyecto se pretende realizar una propuesta de diseño para la implementación de arquitectura orientada a microservicios de un ERP On Premise, enfocado en el proceso de ventas en la empresa de tecnología Dada Dada y Cía, en El Salvador. Dicho proceso se llevará a cabo durante el periodo de noviembre de 2022 a marzo de 2023. La aplicación de este proyecto tendrá como beneficiarios a los empleados de la compañía, específicamente en los departamentos de informática y el departamento de ventas de esta. A su vez la se verán beneficiados indirectamente sus clientes, al momento que la solución sea implementada en la operatividad de la empresa. La identificación de requerimientos del proyecto será tanto los funcionales y no funcionales para poder hacer el ERP, estos se obtendrán por medio de entrevistas realizadas al equipo de desarrollo y al departamento de facturación de la empresa. El Análisis de procesos debe de ser realizado con base en las reuniones discovery a realizar con el equipo de desarrollo de la empresa, así se identificarán por parte del equipo que va a generar la propuesta, las mejoras que se pueden realizar, nuevas implementaciones, si puede realizarse nuevos componentes que sean más robustos y escalables. Para la propuesta de infraestructura, hay que analizar y evaluar los recursos informáticos existentes, de esta manera se puede continuar con la generación de un documento de diseño donde se definirá la infraestructura que proporcionará soporte al sistema, también se tiene que aclarar que será on premise, debido a las políticas informáticas de la empresa. 3.2 Limitaciones La propuesta de diseño de la implementación de este proyecto se limitará solamente al proceso de venta de la empresa, por lo que solo se involucrarán los departamentos de ventas y de informática de esta. La realización de la propuesta de diseño de la implementación de este proyecto se llevará a cabo durante el periodo de noviembre de 2022 a marzo de 2023 y su ejecución será aplicable únicamente para la infraestructura física de la empresa, en la que sus facilidades están ubicadas en la zona metropolitana del país. La propuesta se basará en la definición de procesos que actualmente manejan en la organización, esto debido a que ya se maneja una forma de trabajo armónica con todos los demás departamentos para el flujo de negocio de esta. La recolección de información necesaria para el desarrollo de esta propuesta se realizará con los métodos de recolección mencionados posteriormente en este documento, esto a través de documentación digital y reuniones virtuales que se establezcan con los interesados en la empresa. La propuesta de diseño de la implementación de este proyecto se basará únicamente con los recursos actuales disponibles por la empresa, por lo que a nivel tecnológico no realizan ninguna inversión económica para la ejecución de la propuesta, al mismo tiempo el personal a contar para el desarrollo de la propuesta será el mismo departamento de TI de la compañía, por lo que el presupuesto para este proyecto se basará en el tiempo y costos del esfuerzo ya contemplados en dicho departamento. La propuesta de diseño de la implementación se enfocará en tecnologías de desarrollo conocidas por el departamento de TI de la empresa y que son de uso cotidiano dentro de la misma, con el objetivo de simplificar la capacitación de conocimientos de las personas actuales del departamento, y por circunstancias de rotación de personal de esta. El proyecto intenta poder brindar una propuesta de diseño la cual se enfocará únicamente en los procesos realizados por los sistemas actuales de la empresa Dada & Dada y Compañía, haciendo caso omiso a los procesos fuera de este, con el objetivo de proponer una aplicación que sea más eficiente y tenga mejores tiempos de respuesta a comparación de la actual. 3.3 Hoja de ruta para recolección de datos 3.3.1 Datos necesarios por recolectar Para poder cumplir con los objetivos del proyecto, se debe tener esta información: − Ventajas y desventajas de la Arquitectura Orientada a Microservicios. − Mapeo del proceso a afectar − Aspectos procedimentales − Expectativas por parte del equipo y consultas relacionadas a la implementación de Arquitectura Orientada a Microservicios en la empresa. − Retos que tuvo la empresa para adoptar un sistema ERP. − Mejoras que se podrían implementar en el software actual que se posee en Dada y Dada & Compañía. − Arquitectura actual de la empresa en el proceso de ventas. − Conocimiento que poseen los empleados de la empresa actualmente sobre arquitectura orientada a microservicios. 3.3.2 Métodos de recolección de datos Con el fin de reunir la información necesaria, se utilizarán los siguientes instrumentos: Reuniones de Discovery. Se tendrán reuniones con el coordinador de TI de la empresa, encargado de la administración de recursos informático, mejorar los sistemas informáticos existentes y revisar las capacidades del sistema; a su vez estará incluida la gerente del proceso de ventas de la empresa, jefe del proceso de negocio actual, quien se encarga de colaborar con profesionales de finanzas y ventas para mantener las cuentas por cobrar, con el objetivo de recopilar y analizar información que servirá para establecer las bases de la propuesta a entregar, para ello se debe de comprender los objetivos, alcance y las limitaciones. También debe de definirse un tiempo y un plan para este método, se debe de hacer con base a una agenda para poder revisar en conjunto con el equipo de desarrollo los objetivos del proyecto, este tipo de reuniones permite que los equipos puedan por medio de su perspectiva añadir todo lo necesario y brindar datos que aportarán a la propuesta de solución. Entrevistas. Se hará una entrevista con el jefe de Departamento de Desarrollo de Dada y Dada & Compañía para obtener información sobre cómo se realizó el proceso de adopción de un ERP, la metodología de cambios en los sistemas utilizados en la empresa, los motivos de elección de arquitectura, etc. Esto se realizará de manera virtual en una videollamada. Correos Electrónicos. Se acordó que, por medio de correo electrónico, será la comunicación oficial con la empresa, por este medio se podrá contactar a los empleados sobre consultas que se tengan del proceso. Documentación Utilizada por la Empresa Internamente. Se hará una solicitud a la empresa para que brinden documentación relacionada al manejo de procesos de ventas y la arquitectura implementada en este, esto incluye, manuales técnicos, manuales de usuario, sistemas relacionados al ERP y proceso de ventas, buenas prácticas que han adoptado al diseñar e implementar el software actual, políticas operativas y administrativas que la compañía aplica para su funcionamiento. Documentación sobre Arquitectura Orientada a Microservicios. Se van a buscar medios confiables que proporcionan información sobre los fundamentos de diseño de arquitectura orientada a microservicios, estos podrán ser libros, guías realizadas por empresas que hayan implementado esta arquitectura, revistas, sitios web y personas con experiencia en ese rubro, entre otros. 3.3.3 Métodos de validación de los datos obtenidos Con respecto a la validación de información sobre arquitectura orientada a microservicios, se utilizará como medida de verificación la documentación realizada por personal con amplia experiencia en el área, esta se compone dos libros: Software Architecture: The Hard Parts (múltiples autores) y Software Architecture Patterns (múltiples autores). 3.4 Proceso de recolección de datos La recolección de datos dio inicio en enero de 2023 en las cuales se ha realizado los primeros contactos con los participantes del proyecto de la empresa, estos son: el coordinador de TI de la compañía y la gerencia de administración de ventas de esta y se establecieron las sesiones de reunión indicadas en los siguientes apartados. 3.4.1 Reuniones Discovery Como objetivo de la reunión discovery se tiene que realizar consultas tanto al equipo técnico cómo al funcional, es por ello que, para la parte del negocio, se ha incluido a la jefa del departamento de facturación, quien se encarga de ejecutar y validar procesos con profesionales de finanzas y ventas con el fin de mantener las cuentas por cobrar. Por la parte técnica al coordinador de TI este se encarga de la gestión de recursos y presupuesto tecnológico de la empresa, también se encarga de velar y dar mantenimiento a los sistemas internos de esta, una vez se haya revisado en conjunto y comprendido las expectativas del proyecto, se revisa si ambas partes están de acuerdo. Para estas sesiones, se establecieron las generalidades del proyecto, identificando los responsables de cada área, cada uno de los roles existentes, se revisa el modelo actual de negocio donde se debe de identificar las necesidades del desarrollo, el aporte que tenga el proyecto a la empresa y cuál es el compromiso de los empleados y su apoyo para que esta propuesta se ejecute de la mejor manera. La entrevista con sus preguntas realizadas se encuentra adjunta en el Anexo A. 3.4.2 Entrevista Se identificó al coordinador de TI y a la jefa del departamento de ventas como actores principales para el proceso de realizar análisis y diseño de la implementación de una solución enfocada en el proceso de ventas de la empresa. Es por ese motivo que se realizó la entrevista, para identificar el estado actual del proceso de venta en la empresa y encontrar los problemas operativos actuales (tanto de software como humanos). También, las partes involucradas podrán brindar su opinión sobre si es factible o no la modificación de los procesos existentes. Por lo cual, tendrán el rol colaborador con el equipo investigador sobre dudas y poder asistirlos en lo necesario. Las respuestas de dicha entrevista se encuentran adjuntas en el Anexo B. 3.4.3 Estado actual de operaciones El flujo de trabajo administrativo de la empresa se compone de los siguientes departamentos: − Área Comercial − Administración de Ventas y Facturación Sobre este flujo se desarrollan 5 importantes funcionalidades: − Reporte de ventas. − Compras. − Disponibilidad y reserva de producto. − Movimientos de inventario. − Órdenes de trabajo y facturación. El Reporte de Ventas se encarga del registro de todas las ventas exitosas realizadas por el área comercial, con el fin de iniciar el proceso de concretar el servicio con el cliente. Para este módulo es necesario el registro de los datos generales del cliente, el detalle de producto y/o servicio ofrecido al cliente y se debe adjuntar la documentación que respalde la información digitada en el módulo. Al momento que se registra el detalle de productos y servicios, se activa una funcionalidad que dependiendo del ítem seleccionado, le indica al sistema y al usuario la Disponibilidad Actual en Bodega del Producto, así este conocerá la cantidad de producto a reservar y el cual tiene que ser aprovisionado para poder atender al cliente y satisfacer su venta. Una vez finalizado el ingreso de información del reporte de venta, se envía al departamento de Administración de Ventas para su revisión y aprobación. Si existe alguna irregularidad con la información detallada en el reporte, se regresa al área comercial con las observaciones para su corrección. Posteriormente a su aprobación, se procede con las siguientes fases del flujo de trabajo de venta. Para el caso que la venta no posea la suficiente disponibilidad de producto en bodega, al momento de su aprobación se crea una Orden de Compra con el detalle del producto a adquirir, luego de revisar el documento será enviada al proveedor. Una vez el producto llega a las bodegas de la empresa, se realiza un ingreso al inventario en bodega para suplir la necesidad de la venta. También se ejecuta la creación de Orden de Trabajo que se encarga de registrar las actividades a realizar y realizadas con el cliente, para llevar a cabo lo descrito en el reporte de venta. Este se otorga a un personal técnico para que proceda al llenado de la información, la salida de producto de bodega y la ejecución del trabajo. Cuando ya se haya terminado el trabajo que compete a la venta, se procede a la Facturación de esta con las condiciones que se hayan detallado en el Reporte de Venta, y una vez se finalice la facturación, se puede dar por terminado el proceso de ventas de la empresa. En la Figura 5 se muestra un esquema general de lo antes descrito. Figura 6.Proceso General de Ventas y Facturación de Empresa Nota. Elaboración Propia. Este proceso de venta actualmente se realiza a través del antiguo sistema de ERP que posee la compañía, por lo que los componentes están conectados entre sí en un solo desarrollo. Cada uno de estos módulos se encarga de realizar las operaciones de cada función dependiendo del progreso en el flujo de negocio. Debido a que este se encuentra en un sistema monolítico, donde se depende que cada componente finalice previamente. El procesamiento de este flujo de trabajo ocasiona afectaciones en los tiempos de ejecución en el procesamiento de ventas. Por ejemplo, al momento de ingresar un producto en el Reporte de ventas, se consulta por la disponibilidad de este, pero este proceso no ha sido optimizado, por lo que puede ser muy tardado y engorroso. Aún más, en los proyectos de ventas que son extensos con muchos productos, el tiempo de digitación para el usuario es notorio, sumando a esto escenarios de “timeout” de consultas y bloqueos o cierres inesperados de la aplicación, lo cual implica pérdidas de tiempo para la operatividad de la empresa y para los clientes. 3.4.4 Problemas encontrados Luego de realizar entrevistas y reuniones discovery con el equipo de trabajo de la empresa, se identificaron problemas referentes a los procesos actuales y a la metodología de desarrollo, los cuales se presentan a continuación: − Cuando se realizan reuniones de levantamiento de requerimientos únicamente se hacen con los líderes de equipo y jefaturas. Esto afecta a los analistas tanto técnicos como funcionales, ya que ellos son los que hacen los desarrollos y certifican que el sistema a realizar cumple con las expectativas. Si ellos no están en las reuniones, se tiene como repercusión que se entreguen desarrollos distintos a lo acordado o sistemas que no van a ser aprobados porque los líderes no pudieron describir correctamente los problemas que poseen los analistas en sus jornadas laborales. − No existe metodología formal para poder solicitar el desarrollo de productos nuevos, por ejemplo, migraciones de sistemas o actualizaciones de esto. Actualmente se realiza por medio de comunicación en correos y por llamadas telefónicas. − Se reciben requerimientos contradictorios de los usuarios pertenecientes a la empresa, lo cual impacta negativamente en el ciclo de vida de desarrollo de los sistemas. Por lo tanto, se debe de aclarar los cambios a realizar continuamente, porque si no se hace de esa manera, esta solución no atiende completamente las necesidades del negocio y no se certifica correctamente el producto, provocando que este pida constantes cambios luego de la entrega del sistema. − Debido a que las propuestas de solución no son escuchadas por las altas gerencias, el equipo de desarrollo de software no puede aportar nuevas ideas, bloqueando mejoras y optimizaciones a los sistemas actuales. − El equipo de desarrollo no conoce la lógica de negocio ni los procesos que se van a modificar al iniciar el proyecto, ellos lo van aprendiendo al momento de realizar el diseño y cuando se está implementando el sistema. Esto afecta en la entrega de los requerimientos del sistema, la cual se hace de una forma más tardada y en muchas ocasiones se encuentran mejoras que pudieron ser identificadas previamente si se hubiera conocido el proceso completamente. − No hay planificación formal que permita definir los pasos a seguir cuando se solicita un nuevo producto, afectando en la estimación de tiempos y en la entrega de este. − Actualmente no hay métricas definidas para realizar pruebas relacionadas al sistema a implementar. No se evalúa si estos cambios afectan a otros procesos involucrados, − arriesgándose a cometer errores en un ambiente productivo y poniendo en juego la reputación de la empresa. − Se ha identificado que el ERP actual tiene un problema por el cual los usuarios reportan incidencias, estas suceden al realizar consultas sobre reportes y obtención de datos, debido a que en algunas ocasiones hay desconexiones del sistema o este se tarda demasiado en brindar los resultados, afectando el trabajo del equipo operativo de la empresa. − Al realizar digitación de datos en el sistema, por los problemas previamente mencionados, ocurren inconsistencias en el almacenamiento de estos, por lo que, al continuar con los procesos de negocio, fallan los módulos por obtener datos corruptos e incompletos. − El ERP legado utilizado actualmente, al ser una plataforma obsoleta y sin soporte, posee múltiples problemas de compatibilidad con los sistemas operativos actualizados, afectando en la estabilidad de este. − Una problemática que existe con respecto al ERP consiste que al darle mantenimiento y soporte a este, solamente hay un desarrollador en el equipo que puede hacerlo, creando una dependencia por parte de la empresa hacia él, al buscar perfiles profesionales con el conocimiento necesario para poder laborar en la empresa, estos son casi inexistentes. Por lo que hay que capacitar al personal siempre que ingresa y esto toma mucho tiempo y esfuerzo por parte del equipo. − Debido a que el sistema actual es un sistema de arquitectura monolítica, al hacer un cambio en este, el equipo debe de destinar tanto esfuerzo humano y tiempo para poder evaluar si el nuevo desarrollo no afecta a lo que se tiene implementado actualmente, en la mayoría de los casos si existe impacto en uno o más módulos relacionados. Por lo que además de evaluar, se tiene que adaptar el sistema para que pueda ser utilizado y sin afectar su debido funcionamiento. − Existe poca disposición al cambio de las áreas operativas y las jefaturas del proceso, ya sea por costumbre o intereses propios, por lo que realizar un cambio en las interfaces, o utilizar nuevas herramientas visuales para presentar e ingresar datos son rechazados o son muy difíciles de aceptar. 3.5 Hoja de ruta para propuesta de solución Una vez se haya finalizado con el proceso de recolección de datos, se realizarán los siguientes puntos para diseñar la solución acorde a la necesidad de la empresa: 3.5.1 Análisis de la situación actual de la empresa Con la información recolectada en los métodos anteriores se puede realizar un diagnóstico de la solución de software que está implementada actualmente en la empresa. Con un análisis a profundidad de los procesos de negocio, su estado actual, sus funciones que realiza, la tecnología y arquitectura utilizada en el sistema. Para efectuar un diagnóstico adecuado de la situación actual de la empresa, se desarrollarán los siguientes diagramas para una mejor comprensión de todo el contexto de trabajo actual en la compañía: − Diagramas de casos de usos del negocio − Diagramas del proceso de venta actual − Diagramas de secuencia de las operaciones del flujo de trabajo − Diagrama de la arquitectura de software actual donde se encuentran alojados los módulos a afectar. 3.5.2 Oportunidades de mejora al implementar la solución propuesta En un primer momento, se debe reconocer las mejoras potenciales y la identificación de problemas en los sistemas actuales, se tomará en cuenta las actividades que aumentan los retardos y sus subactividades involucradas, procesos que duplican información, entre otros. Por este motivo es necesario utilizar documentos estandarizados, adopción de nuevas tecnologías que no hagan reproceso, aplicación de buenas prácticas de programación, la identificación de las oportunidades de mejora. Este proceso se realiza de la siguiente manera: − Identificación de obstáculos: con los diagramas realizados en análisis de la situación actual de la empresa, se pueden reconocer estos problemas. − Buenas prácticas: Corroborar si la empresa posee certificaciones de estándares internacionales relacionados a los procesos a intervenir en el proyecto. − Automatización: Considerar eliminar procesos que se realizan manualmente y eliminar los errores que este conlleva, por automatizaciones donde fuese posible. − Optimización de procesos: Evaluar reducir la cantidad de datos que se solicitan actualmente, si hay procesos innecesarios, datos que no se utilizan o que no abonan y en lugar de ellos, colocar únicamente la información necesaria. 3.5.3 Análisis de componentes y procedimientos de sistema Con lo desarrollado en el diagnóstico de la situación actual de los procesos de negocio en la empresa, se pueden realizar los análisis respectivos a cada uno de los componentes y procedimientos que están involucrados dentro del proceso de ventas al que se le realizará la propuesta de implementación. Es necesario describir las funcionalidades de los módulos involucrados en el proceso de ventas con todas sus funciones y actividades a nivel de detalle. Para ello se necesita realizar un diagrama de secuencia granular por cada uno de los procesos que abarca los módulos correspondientes al flujo de ventas. A nivel de datos también tiene que identificarse las entidades involucradas en cada uno de los componentes por ello se realizará un diagrama entidad-relación del esquema actual de la base de datos enfocándose únicamente en los procesos a afectar. Esto se realiza con el objetivo de poder comprender a nivel atómico cada una de sus funcionalidades, sus condicionales para efectuar un flujo exitoso de venta, cuáles son las reglas y normas involucradas dentro de estos y los controles que se manejan ante cualquier escenario dentro de flujo. 3.5.4 Análisis de recursos para la implementación Para la implementación de la solución se debe tener en claro los recursos con los que se cuentan en la empresa para poder realizar un estimado del costo y esfuerzo que se va a invertir en poder ejecutar dicha implementación. A su vez, los recursos se clasifican según su naturaleza para tener mayor objetividad al momento de incluirlos en la implementación. Los tipos de recursos a tomar en cuenta son: − Recurso humano. Son las personas que estarán involucradas en la implementación del proyecto, identificando sus roles y aportes que realizarán para este, tanto físico, intelectual, o experiencia de procesos. − Recursos Físicos y virtuales. Son todos los bienes materiales, equipos y activos de software que estarán disponibles para la implementación de la solución, estos serán proporcionados por la empresa. − Recursos Financieros. Es necesario identificar el detalle de la inversión que está dispuesta a realizar la compañía en la ejecución del proyecto, por lo que se elabora un presupuesto con los estimados financieros que contará el proyecto. 3.5.5 Refinamiento de lista de requisitos de la empresa Esta parte del proceso se realiza luego de haber tenido las reuniones con el equipo multidisciplinario, donde se deben de añadir, modificar, eliminar y priorizar con base a las necesidades de la empresa. Por lo tanto, se procede a listar los requisitos de una forma detallada, estos tienen que comprenderse completamente por los encargados a desarrollarlos. Entre algunos beneficios encontrados con este proceso se encuentran: − El cliente comprende que es lo que ha solicitado y lo comprendido por la parte técnica, así este sabe que espera recibir y lo que va a probar. − Se descubre la necesidad de incorporar nuevos recursos, si dado el caso hay requerimientos que no se habían aclarado correctamente, se identifican las responsabilidades y roles de cada uno y así si no se había estimado este personal, se agrega. − Se evita tener que realizar cambios de última hora, al aclarar, comprender y acordar entre los interesados, cada uno de los requerimientos, se obtiene como resultado un sistema que no tendrá que modificarse constantemente posteriormente a su salida a producción. − Si dado el caso hay muchos requisitos que no son viables, estos se eliminan y de esta manera se obtiene una planificación más certera. 3.5.6 Diseño de la propuesta de solución Una vez se han identificado las problemáticas actuales, los procesos, el sistema y la interacción que este posee con los usuarios y con otros subsistemas, se puede continuar con la fase de propuesta de solución, la cual consiste en desarrollar estrategias de cambios con cada uno de los interesados. Para poder realizar la propuesta de solución de la empresa, es necesario presentar los siguientes: − Diagrama de procesos propuestos − Diagrama de caso de usos propuesto − Diagrama de Secuencia propuesto − Diagrama infraestructura propuesta − Narrativa de los procesos a afectados Se toma en cuenta que las propuestas tienen que crear impactos positivos sobre los sistemas, ayudar a los usuarios, mejorar tiempos de respuesta, entre otros. Es por ello por lo que hay que comprender que los cambios propuestos poseen situaciones con requerimientos desafiantes. A su vez, se prepara al equipo para que esté listo al cambio y que sean resilientes a este. Capítulo 4 Propuesta de solución El desarrollo de la propuesta de implementación de este proyecto se encuentra estructurada en dos apartados: el primero describe el diagnóstico y situación actual de los procesos de venta y el segundo detalla la nueva solución a presentar a la empresa con todas las configuraciones mínimas para la implementación. 4.1 Diagnóstico de proyecto Como parte de la propuesta, se explica el contexto actual de la empresa a nivel operativo del proceso de ventas y facturación, el estatus tecnológico del sistema y se identifican los procesos implementados para cada una de las operaciones en el flujo de trabajo. Por esta razón, para realizar la propuesta de solución, se necesita analizar la situación actual de la empresa, donde se debe aclarar la lógica de negocio que posee el proceso de ventas, en la cual también identificar y describir cada involucrado ya sea directa o indirectamente. Cabe mencionar que la descripción de negocio tiene que ser lo más detallada posible, se clarifica cada uno de los procesos y por ese mismo motivo es necesario que se realice en conjunto a personas que conozcan el comportamiento de la empresa, la forma en la que esta realice su trabajo. 4.1.1 Análisis de situación actual 4.1.1.1 Generalidades del proceso de ventas El negocio de la empresa se puede describir en dos áreas importantes: − Área comercial: se encarga de los ingresos de las ventas en el flujo de trabajo. − Área de administración de ventas y facturación: se encarga de la validación y gestión de todas las ventas ingresadas en sistema para que puedan ser procesadas. Para el flujo de trabajo, entran dos áreas auxiliares que ayudan a la agilización de las ventas. Estas áreas son compras e inventario, las cuales brindan herramientas para poder consultar y realizar la gestión del producto para que posteriormente pueda ser utilizado en el flujo de trabajo de la venta. En el siguiente diagrama se presenta un esquema principal de los módulos involucrados en el flujo de trabajo del proceso de ventas de la empresa. Figura 7. Esquema general de módulos del proceso de ventas de la empresa Nota. Elaboración propia. Se describirán los casos de uso con sus actores, objetos, relaciones y responsables, esto servirá como base para comprender y describir el flujo de cada uno de los módulos y procesos que existen en la empresa, también abonará para identificar el comportamiento de los módulos dentro del sistema. Cabe mencionar que el diagrama está enfocado únicamente en el proceso de ventas. Se identificó como actores al cliente, el cual se encarga de realizar la solicitud de producto, este a su vez interactúa con el asesor comercial, quien digita el reporte de ventas, ingresa documentación de venta y consulta disponibilidad de producto. Posterior, el encargado de compras aprueba, gestiona y recibe las mismas. Por medio del sistema interactúa con el encargado de bodega y con el administrativo de ventas, en el punto medular del ingreso de producto, el administrativo de ventas debe validar que sea un producto de inventario, así lo consulta y reserva. A continuación, crea la orden de compra y genera su ingreso a bodega, en ese instante el encargado de bodega toma el producto y libera una orden de trabajo, si todo se cumple de la forma correcta. El encargado de bodega interactúa con técnico operativo entregando la orden de trabajo y ejecutándolo, este finalmente interactúa con el administrativo de ventas, donde le entrega la facturación, la cual será entregada y enviada al cliente. En el siguiente diagrama se podrá observar las funciones de cada responsable. Figura 8.Diagrama de casos de uso de sistema de administración de venta de la empresa Nota. Elaboración propia. 4.1.1.2 Detalle del proceso de ventas Para un flujo de trabajo en el proceso de ventas de la empresa se inicia desde la prospección del cliente realizado por el asesor comercial, el cual gestiona las necesidades del cliente por medio de las propuestas económicas que le son ofrecidas, posteriormente el cliente evalúa las ofertas presentadas y acepta la que mejor se adecúa a sus necesidades. A nivel sistemático, el proceso comienza desde la aceptación de la oferta económica proporcionada al cliente por el asesor comercial para un negocio específico. Cabe mencionar que para este proceso descrito para la propuesta únicamente se va a tomar en cuenta las acciones realizadas dentro del sistema. Esta oferta tiene que ser ingresada dentro del flujo de trabajo por medio de Reporte de ventas, en el cual el asesor comercial ingresa toda la información relacionada a la venta y las evidencias que lo respaldan. Una vez ingresada la información y que se realice la notificación a los operativos del área de administración de ventas, este procederá a evaluar toda la información ingresada por el asesor. En esta parte se poseen múltiples filtros para realizar este proceso, el primero que existe es la validación del reporte, se hace de forma manual porque las validaciones no pueden ser automatizadas, entre algunos ejemplos se identifican que haya un contrato entre ambas partes el cual contiene sellos impresos del proveedor que únicamente pueden comprobarse actualmente por medio de una verificación visual, por parte de un operador de ventas. Si el reporte es inválido, se vuelve a iniciar el proceso de registro de datos de venta junto a la documentación, pero si este es aceptado, primero los empleados encargados de la administración de ventas se encargan de realizar la aprobación del reporte de ventas, luego se comprueba con el segundo filtro donde se hace la consulta el sistema si es un producto o servicio para relacionar a la entrega de un producto que se espera comprar por el usuario. Si es el caso de un servicio que será consumido por el cliente no se realizarán consultas de inventario al sistema. Por lo que no pasará a ningún módulo relacionado a inventario. Por ejemplo, mantenimiento de redes y servidores, capacitaciones relacionadas al uso de productos que vende la empresa, luego se entrega la orden de trabajo con el administrador de ventas. Si es un producto, se debe de corroborar que haya disponibilidad de este, ante ello también se identifica que si no hubiese, debe de realizarse una orden de compra de productos por medio del sistema de forma automática, luego esta debe ser aprobada por el encargado de compras, se continua con la recepción de esta y el ingreso a bodega de producto, en el otro caso que haya producto disponible se continúa con la creación de orden de trabajo por el departamento de ventas, se sigue con la salida de bodega del producto, donde el encargado de este lugar es quien realiza el proceso. A continuación, el técnico operativo recibe la orden de trabajo y materiales. Una vez tenga todos los componentes, se continúa con la ejecución de trabajo por parte de los técnicos operativos; se hace la finalización de la orden de trabajo y el administrador de ventas se encarga de crear la facturación de la venta. Una vez creada se le entrega al cliente, este la recibe y la revisa, si todo cumple con lo establecido, se finaliza este proceso. En la siguiente figura se describe el flujo de trabajo dentro del proceso de ventas de la compañía: Figura 9.Diagrama descriptivo del proceso de ventas de la empresa Dada y Dada & Compañía. Nota. Elaboración propia. A partir de este flujo de trabajo y a través de la documentación brindada por la empresa, se analizan los pasos que se deben de tomar por los módulos dentro del proceso. Dichos pasos se han clasificado en tres flujos principales, estos son: − Reporte de Ventas de Área Comercial − Reporte de Ventas de Área Administrativa − Orden de Trabajo y Facturación Para el proceso de Reporte de Ventas (RV) de Área Comercial, este es iniciado desde que el cliente acepta la oferta económica propuesta por el asesor comercial asesor comercial, se debe de tener en cuenta que la acción de prospección no se tomará en cuenta para la implementación. Una vez el asesor comercial tenga la oferta firmada por el cliente, procede a ingresar el RV en el módulo respectivo, con la descripción y detalle del trabajo, producto o servicio contratado, los materiales y equipos solicitados que serán utilizados para la ejecución del trabajo, y la debida documentación de la venta que demuestre lo solicitado y firmado por el cliente. Cuando finaliza de cargar toda la información necesaria al RV, se realiza la notificación al Administrativo de ventas para la revisión y aprobación de la venta. Esto se realiza para garantizar que lo ingresado por el asesor comercial, se encuentra debidamente documentado y dentro de las políticas de negocio de la empresa. En el caso que existan excepciones de políticas se debe de contar con las respectivas firmas de las gerencias involucradas y que aceptan la excepción para el caso en cuestión. Cuando existe una irregularidad en la revisión de datos del RV, el administrativo de venta regresa el RV al asesor comercial para que realice las correcciones necesarias para que pueda ser aceptado. Si t