mateo contreras castellanos
TRANSCRIPT
Desarrollo de soluciones de analítica de datos para apoyar procesos de toma de
decisiones en las áreas de logística de producción/entrega y diseño de precios
Mateo Contreras Castellanos
Asesora
Haydemar María Núñez Castro
Co-asesor
Felipe Reinoso-Carvalho
Departamento de Ingeniería de Sistemas y Computación
Facultad de Ingeniería
Universidad de los Andes
Noviembre, 2020
1
Resumen
En este proyecto se busca apoyar la gestión de un restaurante que ha adoptado las
plataformas de delivery como canales de relacionamiento y distribución de sus productos al
cliente final (i.e. dark kitchen). En este caso más específico, se plantea el diseño de un sistema
con el que el encargado de la cocina logre visualizar información relevante sobre la operación
de su restaurante, recomendaciones tácticas para optimizar los recursos disponibles, ofreciendo
así mayor calidad en el portafolio de sus productos y servicios. Para esto, se hace uso de
técnicas analíticas sencillas como la estadística, hasta tareas más complejas como minería de
datos con sus respectivas visualizaciones de resultados. Finalmente, se utilizan datos simulados
para probar el sistema construido.
2
Índice
1 INTRODUCCIÓN ....................................................................................................................................... 3
2 OBJETIVOS ............................................................................................................................................... 4
2.1 OBJETIVOS GENERALES ................................................................................................................................ 4 2.2 OBJETIVOS ESPECÍFICOS............................................................................................................................... 4 2.3 ANTECEDENTES .......................................................................................................................................... 4
2.3.1 Plataformas de delivery .................................................................................................................... 4 2.3.2 Caso de estudio ................................................................................................................................. 5
3 DISEÑO Y ESPECIFICACIONES ................................................................................................................... 8
3.1 DEFINICIÓN DEL PROBLEMA .......................................................................................................................... 9 3.2 DISEÑO DE LA SOLUCIÓN .............................................................................................................................. 9
3.2.1 Zona de eventos ................................................................................................................................ 9 3.2.2 Analytics .......................................................................................................................................... 10 3.2.3 Planeador de recursos ..................................................................................................................... 10 3.2.4 Zona de datos ................................................................................................................................. 11 3.2.5 API ................................................................................................................................................... 11
3.3 ESPECIFICACIONES DEL SERVICIO DE ESTIMACIÓN DE TIEMPOS............................................................................ 12 3.3.1 Consideraciones .............................................................................................................................. 12 3.3.2 Parámetros ..................................................................................................................................... 12 3.3.3 Respuesta ........................................................................................................................................ 13
4 DESARROLLO ......................................................................................................................................... 13
4.1 SIMULACIÓN DE LOS DATOS ........................................................................................................................ 13 4.2 EL SISTEMA TRANSACCIONAL ...................................................................................................................... 15 4.3 LA APLICACIÓN WEB ................................................................................................................................. 16 4.4 EL MODELO ............................................................................................................................................. 17
5 RESULTADOS Y VALIDACIÓN .................................................................................................................. 18
5.1 RESULTADOS ........................................................................................................................................... 18 5.2 VALIDACIÓN ............................................................................................................................................ 19
6 CONCLUSIONES ..................................................................................................................................... 19
6.1 DISCUSIÓN .............................................................................................................................................. 19 6.2 TRABAJO FUTURO .................................................................................................................................... 20
7 REFERENCIAS ......................................................................................................................................... 21
8 ANEXOS ................................................................................................................................................. 22
3
1 Introducción
A mediados del siglo XVI tuvo lugar la existencia del que es considerado por muchos como
el primer restaurante moderno, y esto se dio en París, Francia. Monsieur Boulanger fue un
empresario que con su anuncio “Boulanger débite des restaurants divins” (“Boulanger vende
restauradores dignos de los dioses”), vendió unos caldos a los que se le atribuía su don de
“restaurar” la salud de las personas, y de ahí la palabra restaurante que nació del verbo francés
restaurer, que significa "restaurar o refrescar". (Bednarz, C.,2018)
Desde ese entonces, mucho tiempo ha pasado y los restaurantes, aunque no habían cambiado
mucho, se convirtieron en uno de los principales lugares públicos para entablar relaciones
sociales y consumir alimentos preparados (Lang, G., 2020). Sin embargo, desde la segunda
mitad del siglo XX, a través del abrupto cambio que han supuesto las tecnologías de
información y las Comunicaciones (TICs), y especialmente hacia comienzos del siglo XXI, ha
cambiado drásticamente el panorama de los restaurantes, provocando una forma más accesible
y rápida de hacer pedidos, masificando así el delivery.
De hecho, para hablar sobre el delivery hay que remontarse a la antigua Roma. Allí ya se
hablaba de los servicios de entrega. Pero no es hasta los 1950s que este concepto de delivery
se populariza con restaurantes que ofrecían por medio de televisión y otros medios de
publicidad su servicio de entrega en casa de alimentos pedidos por medio telefónico (Logistic,
F.,n.d.). Por más de medio siglo, este modelo funcionó de esta manera, en donde los
restaurantes ofrecían sus alimentos e inclusive lograban cumplir las necesidades de sus nuevos
clientes que deseaban comer desde la comodidad de sus casas, instituciones o lugares de
trabajo. Sin embargo, antes del boom tecnológico mencionado anteriormente, este modelo era
poco escalable. Funcionaba para la época por diversos factores como la baja cantidad de
personas que disponían del dinero para poder tomar estos servicios, de gran oferta de
restaurantes e incluso del reconocimiento de marca que lograse captar la atención para estos
servicios. Ahora bien, con el avance de la tecnología y la incursión de los dispositivos de
computación móvil y web, las modernas aplicaciones de delivery han traído la capacidad de
poder solicitar los alimentos de una forma mucho más directa y rápida.
Las aplicaciones de delivery han permitido que el sistema de solicitud y orden de los pedidos
sea masivo, soportando múltiples órdenes entrantes al tiempo. Con tal ventaja para el cliente y
restaurador, también han aparecido retos como la necesidad de planeación logística de
producción en gran escala, dando así un correcto manejo a la cantidad de pedidos y la
saturación que estos generan en estas cocinas. Esta falencia en la logística hace que la mayor
parte de los restaurantes retrasen sus pedidos mucho más de lo esperado, generando quejas,
inconvenientes y una potencial mala imagen, lo cual se traduce en un decrecimiento en las
ventas. Una primera posible solución a esto es la variación de los precios dependiendo de las
ordenes en proceso, pero dado el bajo nivel de conocimiento del comportamiento de las órdenes
y su logística, es complicado dar un precio razonable sin generar reacciones negativas frente a
los clientes. Es entonces donde este proyecto toma lugar, planteando una solución con la que,
usando los datos que se generan a diario en estos establecimientos, se pueda crear un nuevo
modelo logístico y de pricing.
4
2 Objetivos
A continuación, se definen los objetivos generales y específicos que encaminaran este
proyecto.
2.1 Objetivos generales
• Aplicar los conocimientos de Ingeniería de información para ofrecer una solución que apoye
la planeación logística y de procesos en el sector gastronómico haciendo énfasis en las Dark
Kitchens.
• Aplicar diferentes métodos de investigación de mercados con el fin de conocer la
percepción sobre el negocio, identificar problemas y las respectivas soluciones
tecnológicas.
2.2 Objetivos Específicos
• Identificar y analizar los procesos clave en la industria gastronómica y del delivery con el
fin de proponer soluciones que optimicen dichos procesos e involucren más al cliente.
• Diseño e implementación de una arquitectura de datos que permita representar y utilizar la
información disponible con los fines del proyecto.
• Evaluar las diferentes tecnologías de analítica de datos y almacenamiento con el fin de
ofrecer predicciones confiables y eficientes computacionalmente.
• Implementar un prototipo web para el cliente que simulará una app de delivery y a su vez
ofrecerá los servicios propuestos en el contexto planteado.
• Implementar una API que expone los servicios del proyecto para ser utilizados por la
aplicación web u otras plataformas.
• Evaluar la propuesta final con las personas expertas en el negocio con el fin de conocer la
viabilidad de la solución planteada.
2.3 Antecedentes
En esta sección se habla del contexto y los conceptos necesarios para entender el tema sobre
el que se trata este proyecto, así como su desarrollo.
2.3.1 Plataformas de delivery
Las Dark o Cloud kitchens nacen del sector en el que se mueven las plataformas de delivery,
efectuando un cambio en la forma en que comensales y restaurantes interactúan entre sí,
disminuyendo la necesidad de una sala para consumidores en la que se atiendan a dichos
clientes (Deliverect, n.d).
La propuesta traída por este nuevo modelo sinérgico entre cocinas ocultas y las plataformas
de delivery ha traído también sus puntos en contra para todo el sector. El primero de estos es
el abrupto aumento en las ordenes lo cual rompe con los esquemas y procesos ya establecidos
5
para un restaurante tradicional, y trae la necesidad de adaptarse a la circunstancia, de manera
que el restaurante pueda responder a la demanda que se produce en cada momento del día.
Una de las causas del aumento en las órdenes es la falta de información que tienen los
clientes y el mismo restaurante sobre el contexto del momento. En consecuencia, no se impone
límite alguno para los clientes quienes siguen realizando órdenes y esperando a que sean
atendidas con un tiempo de respuesta constante. Además, generando caos y saturación en la
cocina por la cantidad de pedidos.
Una consecuencia al incremento en la demanda es la creciente necesidad de una mejor
gestión de los recursos del restaurante. Esto se debe a que en circunstancias pasadas podían ser
administrados situacionalmente o a demanda. Ahora bien, estos deben ser gestionados de
manera más estricta y precisa, en tiempo real, de manera que si empiezan a escasear inventarios
el encargado de la cocina sea notificado para poder actuar a tiempo.
Finalmente, la competitividad en el sector aumenta. Mientras que unos restaurantes se
vuelven más aptos que otros para ejecutar los procesos en respuesta al cambio de paradigma
propuesto por las plataformas de delivery y lograr un balance entre precio y tiempos, otros se
ven amenazados por su baja capacidad ante las órdenes y a su nula adaptación frente a los
nuevos procesos por seguir, culminando en muchos casos en contratación de más personal sin
un camino muy claro a seguir, mala reputación del restaurante en las plataformas de delivery e
incluso el final de la empresa.
2.3.2 Caso de estudio
En esta sección se muestra el caso de estudio escogido dado el negocio específico a analizar
y al experto relacionado con este sector.
2.3.2.1 El restaurante en estudio
En el caso particular de este proyecto se trabajó con el dueño de un restaurante de comida
rápida, quién desde su experiencia y tras varias entrevistas, validó la situación planteada en el
sector además de algunas dificultades que encontró frente a este nuevo mundo de las Dark o
Cloud Kitchens.
Arquitectura actual del negocio
En una primera instancia, el experto compartió la situación actual del restaurante (ver anexo
A) y sus procesos clave en la preparación y despacho de órdenes.
Órdenes y pedidos
6
En primera instancia, se encuentra todo lo relacionado a las órdenes y los pedidos a realizar.
Para esto, en la situación actual, el experto indica que el cliente genera una orden y esta entra
directamente al proceso de gestión de órdenes como se ilustra en la Figura 1.
Figura 1, Cliente y su interacción con plataformas de delivery
Seguidamente esta orden es enviada a la cadena de producción en la cocina que tiene como
actividades clave recibir la orden, realizar la planeación, producción, empaquetado y despacho
de dicha orden como se ilustra en la Figura 2. En cada momento se registra cada paso en la
aplicación de delivery.
Figura 2, Plataforma de delivery y su interacción con restaurantes
Proveedores e Inventarios
Una parte fundamental en el funcionamiento del negocio, según el experto, radica en la
administración de los proveedores e inventarios. Para realizar esta administración se tienen dos
subprocesos, la gestión de los inventarios y el aprovisionamiento.
7
La gestión de los inventarios se da cada cierto tiempo definido por el encargado o cuando
un recurso requerido empieza a escasear. Una vez, esta condición de partida se cumple, se
inicia el inventariado, dónde se hace el conteo de los insumos disponibles y se toman en cuenta
fechas de vencimiento. Esto suele consumir un tiempo considerable dado el volumen de los
inventarios.
Una vez se conocen los inventarios disponibles, se proyectan las necesidades estimadas de
los productos para la operación del periodo establecido. Finalmente, se contacta con el
proveedor para solicitar los insumos proyectados. Este proceso se ilustra en la Figura 3.
Figura 3, Procesos de gestión de inventarios y proveedores
Pasado un tiempo que varía dependiendo del proveedor y su producto, el proveedor hace
llegar los productos requeridos al restaurante y empieza el proceso de recibimiento de
inventarios. Tras esto se hace una revisión del recibido y de la calidad del servicio del
proveedor consignándolo en una planilla de calificación de proveedores. Finalmente, los
insumos son almacenados en el lugar correspondiente.
Motivadores de cambio
Tras haber tenido en cuenta la situación actual del negocio, el experto indicó varios puntos
motivadores (ver anexo B) para hacer cambios que mejoren la situación del negocio y de la
empresa.
• Monitorear y calificar mejor a los proveedores
En su restaurante, el experto indicó la necesidad que vio de calificar y clasificar a sus
proveedores con el fin de elegir el mejor proveedor posible dependiendo de la situación. En
8
este caso, el expone como ejemplo una situación en la que se requiere un insumo como carne,
pero el mejor proveedor de este producto tardaría mucho en traerla. Por consiguiente, la mejor
alternativa es aquel proveedor un poco menos bueno, pero que sea efectivo en términos de
velocidad al momento de la entrega.
• Monitorear y gestionar los inventarios en tiempo real
Tras haber comunicado la idea tras este proyecto, el experto confirmó la importancia del
manejo de los inventarios de forma correcta en el más moderno ambiente de delivery en el que
nos encontramos. Esto se da, según comenta él, por la necesidad de disponibilidad de insumos
para despachar las ordenes de forma eficiente frente al gran volumen de pedidos que se generan
a diario.
• Disminución de costos en inventarios
El experto mencionó un problema que es muy frecuente en el sector y está relacionado con
algunos productos que no llegan a gastarse y por consiguiente se vencen o ya no son útiles,
generando gastos innecesarios. Por este motivo, se expresa la necesidad de, no solo tener
conocimiento de estos productos próximos a vencer, sino también de plantear estrategias
dinámica e inteligentemente sobre qué hacer con estos. Para lidiar con esta situación, una
sugerencia planteada fue la dinamización de precios de tal manera que, dependiendo de la
disponibilidad y estado de los insumos, se le pueda ofrecer al cliente promociones y productos
que reduzcan las perdidas por insumos vencidos o no útiles.
• Aumentar el consumo de platillos
Atendiendo al requerimiento de ser competitivos en el ambiente de las plataformas de
delivery, es importante para el experto que el restaurante pueda seguir recibiendo ordenes como
sea posible sin llegar al punto de mala reputación por el no cumplimiento de los tiempos
pactados. Por lo que, en este caso, hay dos factores importantes a tratar:
1. Predecir con un alto grado de precisión los tiempos de preparación para ser claros
y congruentes con los clientes sobre la oferta, evitando disgustos, malentendidos.
2. Conocer los recursos disponibles y utilizarlos de manera óptima para procesar más
órdenes en el menor tiempo posible.
3 Diseño y especificaciones
En esta sección se define el problema abordado en este proyecto y el diseño planteado para
la solución propuesta. Dicho diseño fue construido utilizando la herramienta Archi1 para el
modelado del negocio, motivación y tecnología de alto nivel, dichos modelos fueron validados
con el experto de negocio.
1 https://www.archimatetool.com/
9
3.1 Definición del problema
Tras la obtención y análisis de los motivadores de negocio, se definen cuatro grandes
problemas correspondientes a los motivadores anteriormente mencionados. Sin embargo, a
causa del gran tamaño del problema, en este proyecto se trabajará solo una pequeña parte del
este a nivel de implementación. Es el motivador para aumentar el consumo de platillos en su
subtema “Conocer las situaciones y circunstancias para ser claros y congruentes sobre el
tiempo que se indica para la finalización de una orden evitando disgustos y malentendidos” el
tratado en este proyecto a profundidad de implementación y análisis, mientras que sobre los
otros tres se presentará un diseño general del sistema del cual se podría partir para
implementarlos.
3.2 Diseño de la solución
Tras el entendimiento del negocio y sus procesos, y de las motivaciones indicadas por el
experto, se inició la construcción del último modelo en el cual se propone una arquitectura de
negocio y tecnología capaz de cubrir los intereses del experto (ver anexo C). En este caso, la
zona de aplicaciones se ha ampliado añadiendo nuevas aplicaciones que apoyarán al negocio
en las motivaciones anteriormente planteadas:
3.2.1 Zona de eventos
Figura 4, Zona de eventos
Como se ilustra en la Figura 4, esta contiene todos los componentes y servicios necesarios
para manejar los eventos que se generen y consuman en el sistema.
10
3.2.2 Analytics
Figura 5, Zona de Analytics
Como se ilustra en la Figura 5, esta contiene todos los componentes y servicios encargados
de realizar las predicciones y proyecciones de inventarios. Para esta zona, el proyecto ahondará
en el desarrollo de el “Estimador de tiempos”.
3.2.3 Planeador de recursos
Figura 6, Zona de planeación de recursos
Como se ilustra en la Figura 6, esta zona contiene todos los componentes y servicios
encargados de gestionar los inventarios y para ocasiones futuras, otro tipo de recursos. Se
propone utilizar para este sistema un ERP2.
2 https://www.sciencedirect.com/science/article/abs/pii/0378720686900108?via%3Dihub
11
3.2.4 Zona de datos
Figura 7, Zona de datos
Como se ilustra en la Figura 7, en esta zona se encuentran todos los servicios de persistencia
y almacenamiento que gestionan la información del sistema.
3.2.5 API
Figura 8, Zona de APIs
Finalmente, como se ilustra en la Figura 8, esta zona expone los servicios del sistema para
habilitar la comunicación entre ellos y con sistemas de terceros como las aplicaciones de
delivery para la obtención y gestión de las órdenes.
12
3.3 Especificaciones del servicio de estimación de tiempos
Entrando en detalles sobre el foco de este proyecto, el estimador de tiempos, se quiere
entrenar un modelo apropiado para predecir el tiempo de preparación de una orden antes de
que esta sea solicitada.
3.3.1 Consideraciones
Para construir este modelo se definen los siguientes elementos:
𝑜𝑛: ó𝑟𝑑𝑒𝑛 𝑛 𝑝𝑛: 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑜 𝑛
Ahora bien, sea 𝑂 el conjunto de todas las órdenes y 𝑃 el conjunto de todos los productos
se define:
𝑃𝑆𝑜𝑛
⊆ (𝑂 × 𝑃 × ℕ): 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑜𝑠 𝑑𝑒 𝑢𝑛𝑎 ó𝑟𝑑𝑒𝑛 𝑛 𝑦 𝑠𝑢𝑠 𝑐𝑎𝑛𝑡𝑖𝑑𝑎𝑑𝑒𝑠
𝐶𝑜𝑛⊆ (𝑂 × 𝑃 × ℕ): 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑜𝑠 𝑎𝑐𝑡𝑖𝑣𝑜𝑠 𝑎𝑙 𝑚𝑜𝑚𝑒𝑛𝑡𝑜 𝑑𝑒 𝑙𝑙𝑒𝑔𝑎𝑑𝑎 𝑑𝑒 𝑙𝑎 ó𝑟𝑑𝑒𝑛 𝑛
Y las funciones:
𝑖𝑑(𝑜𝑛): 𝑖𝑑 𝑑𝑒 𝑙𝑎 ó𝑟𝑑𝑒𝑛 𝑛 𝑎ℎ(𝑜𝑛): 𝐻𝑜𝑟𝑎 𝑑𝑒 𝑖𝑛𝑔𝑟𝑒𝑠𝑜 𝑑𝑒 𝑙𝑎 ó𝑟𝑑𝑒𝑛 𝑛
𝑠ℎ(𝑜𝑛): 𝐻𝑜𝑟𝑎 𝑑𝑒 𝑖𝑛𝑖𝑐𝑖𝑜 𝑑𝑒 𝑙𝑎 ó𝑟𝑑𝑒𝑛 𝑛 𝑒ℎ(𝑜𝑛): 𝐻𝑜𝑟𝑎 𝑑𝑒 𝑓𝑖𝑛𝑎𝑙𝑖𝑧𝑎𝑐𝑖ó𝑛 𝑑𝑒 𝑙𝑎 ó𝑟𝑑𝑒𝑛 𝑛
𝑑(𝑜𝑛) = |𝑒ℎ(𝑜𝑛) − 𝑎ℎ(𝑜𝑛)|: 𝐷𝑢𝑟𝑎𝑐𝑖ó𝑛 𝑑𝑒 𝑢𝑛𝑎 ó𝑟𝑑𝑒𝑛 𝑛
Con esto en mente, se propone entrenar un modelo que logre predecir 𝑑(𝑜𝑛) en diferentes
contextos. Para esto se decidió entrenar un modelo regresivo.
3.3.2 Parámetros
Para el entrenamiento del modelo se plantea introducir un conjunto de datos como se ilustra
en la Tabla 1.
13
Tabla 1, Variables requeridas para entrenar el modelo
𝑎ℎ(𝑜𝑛) 𝑑(𝑜𝑛) 𝑃𝑆𝑜𝑛 𝐶𝑜𝑛
Con lo cual el modelo se entrenó basado en la hora de entrada de la orden, la duración
(variable objetivo), los productos ordenados y los productos activos en el momento de entrada
de la orden.
Finalmente, para la predicción, se utilizaron como parámetros los ilustrados en la Tabla 2.
Tabla 2, Variables requeridas para usar el modelo
𝑎ℎ(𝑜𝑛) 𝑃𝑆𝑜𝑛 𝐶𝑜𝑛
3.3.3 Respuesta
Para el entrenamiento del modelo se planteó una función matemática definida como:
𝑓(𝑎ℎ, 𝑃𝑆𝑜𝑛, 𝐶𝑜𝑛
) = 𝑑
Donde 𝑎ℎ es la hora de llegada de la orden, 𝑃𝑆 los productos ordenados en la orden, 𝐶 las
ordenes activas al llegar dicha orden y 𝑑, variable resultante de la predicción, la duración de la
predicha de la orden.
4 Desarrollo
En esta sección se discuten las decisiones de diseño y la implementación realizada además
de los datos utilizados para el entrenamiento del modelo anterior.
4.1 Simulación de los datos
Por la naturaleza del proyecto, no fue posible utilizar datos reales dado que la disponibilidad
de estos estaba atada a confidencialidad y a aun tiempo relativamente largo. Por esta razón, se
optó por simular los datos de productos y órdenes haciendo uso del lenguaje de programación
Python3 y de la librería numpy4 para la generación de datos aleatorios.
En primera instancia, se creó un archivo json5 con productos ficticios que fueron cargados
a la base de datos. Estos tenían los siguientes campos:
3 https://www.python.org/ 4 https://numpy.org/ 5 https://www.json.org/json-en.html
14
category: Indicando la categoría del producto entre las posibilidades del restaurante.
name: Indicando el nombre del producto.
type: Indicando el tipo de comida entre entrada, plato fuerte, bebida, etc.
imageURL: Indicando el URL de la imagen del producto.
time: Indicando un estimado de tiempo independiente de preparación de ese producto.
Seguidamente se escribió un script que generaba combinaciones de estos productos dada
una cantidad aleatoria de personas, de esta manera se generaron ordenes con comida para una
o más personas dependiendo del número generado. Adicionalmente, la orden generó hora de
inicio, hora de finalización, hora de delivery y el campo autogenerado de duración teniendo
en cuenta la hora de llegada y las ordenes en cola para demorar más o menos la distancia de
separación temporal entre los estados de orden.
Finalmente se establecieron una serie de lambdas para su uso en la simulación de los
tiempos entre llegada de órdenes con 𝜆 = 2/3600 para un rango de tiempo entre las 10 y 11
am, 𝜆 = 10/3600 para un rango de tiempo entre las 11 am y 2 pm, 𝜆 = 3/3600 para un rango
entre las 2 y 6 pm, y 𝜆 = 8/3600 para un rango entre las 6 y 11 pm.
Con los anteriores lambdas se utilizó la función np.random.exponential6 de la librería
numpy7 y se ejecutó el script de generación de orden con una diferencia de tiempo aleatoria
generada por el resultado de dicha función. Estas órdenes generadas fueron persistidas
inmediatamente en la base de datos.
Figura 9, Gráfica hora vs minutos de demora
Una posible visualización de los datos simulados ilustra en la Figura 9, con una gráfica de
hora (en segundos desde el inicio del día) vs minutos demorados y se logra apreciar dos picos
esperados en la hora del almuerzo y llegada la noche, mientras que unos valles en el resto del
día.
6 https://numpy.org/doc/stable/reference/random/generated/numpy.random.exponential.html 7 https://numpy.org/
15
4.2 El sistema transaccional
Para implementar el sistema requerido, se planteó la arquitectura ilustrada en la Figura 10.
Figura 10, Arquitectura del software
Para el sistema transaccional se utilizó la tecnología NodeJs 8con express9 como tecnología
del lado del servidor para realizar la lógica transaccional y persistir los recursos en las bases de
datos. Adicionalmente, para la persistencia de utilizó la base de datos PostgreSQL10 de a la
cual se conectó el sistema transaccional y el simulador de datos. La base de datos diseñada fue
la ilustrada en el modelo de la Figura 11.
Figura 11, Modelo de la base de datos
8 https://nodejs.org/en/ 9 https://expressjs.com/ 10 https://www.postgresql.org/
16
4.3 La aplicación Web
Para la aplicación web se construyó un UI simple para simular el ingreso a una plataforma
de delivery como se ilustra en la Figura 12 y la Figura 13.
Figura 12, Vista de inicio del UI con la lista de los productos
Esta fue construida usando la librería ReactJs11 y conectado al componente de servicios
mediante API Rest12. Esta interfaz permitió seleccionar los productos como si de una orden se
tratase, para poder permitir al usuario interactuar con los datos del simulador.
Figura 13, Vista de los productos seleccionados
11 https://reactjs.org/ 12 https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest
17
4.4 El modelo
Finalmente, basados en la información disponible en la base de datos, se realizó un script
que substrajo los datos de dicha fuente de información y los adaptó al formato requerido como
se aprecia en la Tabla 3.
Tabla 3, Variables requeridas para usar el modelo
𝑎ℎ(𝑜𝑛) 𝑑(𝑜𝑛) 𝑃𝑆𝑜𝑛 𝐶𝑜𝑛
Estos datos fueron almacenados de forma local en formato csv13 y llevados a la herramienta
Orange14 donde se realizó la configuración ilustrada en la Figura 14.
Figura 14, Configuración de datos y regresón
Este archivo fue configurado con el atributo duración como variable objetivo duration
como se ilustra en la Figura 15.
Figura 15, Tabla de datos para entrenar
El elemento “Linear Regression” realizó el entrenamiento con los datos correspondientes y
el algoritmo de regresión lineal. Finalmente se evaluó la predicción realizada utilizando un
pequeño archivo de prueba resultando lo ilustrado en la Figura 16.
Figura 16, Resultados de la regresión lineal
13 https://www.ietf.org/rfc/rfc4180.txt#page-1 14 https://orangedatamining.com/
18
5 Resultados y validación
En esta sección se mostrarán los resultados del modelo predictivo y las validaciones
realizadas por el experto de negocio frente a la solución y la propuesta en general.
5.1 Resultados
Para analizar la validez de los resultados de las predicciones del modelo, se continuó
utilizando la herramienta orange15 con la configuración ilustrada en la Figura 17.
Figura 17, Configuración de validación
En este caso, el archivo de datos para entrenar el modelo es utilizado junto con el elemento
“Linear Regression” como entradas del objeto “Test and Score” que se encarga de calcular
resultados estadísticos del análisis de varianza (ANOVA) del modelo. En este caso, se utilizó
el método cross validation como se ilustra en la Figura 18.
Figura 18, Método y resultados de validación
El primero de estos es el error cuadrático medio (MSE) el cual es de 42.076. Adicionalmente
se tiene la raíz del error cuadrático medio (RMSE) con un valor de 6.487.
El segundo es el error absoluto medio (MAE) con un valor de 4.731 indicando un valor
menor que la raíz del error cuadrático medio.
Finalmente, se tiene 𝑅2 con un valor de 0.648 siendo este significativamente alto respecto
a la escala porcentual.
15 https://orangedatamining.com/
19
5.2 Validación
Para hacer la validación de la propuesta de solución planteada, se realizó una entrevista con
el experto revisando tres partes fundamentales para el correcto alineamiento del negocio con
el TI.
El primero de estos fue las motivaciones, dónde se expresó la necesidad de la eficiencia a la
hora de registrar los inventarios y la calificación del cliente, en cuyo caso la importancia de
una aplicación móvil con alta usabilidad se vuelve prioritaria además del problema de
credibilidad sobre los registros de dicho formulario. Por otro lado, el experto de negocio resaltó
la importancia de monitorear en tiempo real el comportamiento de los precios en el mercado
con el fin de ofrecer precios y promociones competitivas. Respecto a los demás motivadores,
el experto expresó estar de acuerdo con la propuesta presentada.
El segundo punto para tratar fue la arquitectura de negocio, dónde se presentó la arquitectura
actual (ver anexo A) y la arquitectura objetivo (ver anexo B). El primero de estos modelos
obtuvo un visto bueno con cambios menores en formato mientras que sobre la arquitectura
objetivo, el experto hizo énfasis en la importancia de utilizar dispositivos móviles para mejorar
la velocidad con la que se gestionan los recursos de la solución.
Finalmente, una vez implementado el modelo, se tuvo una corta entrevista final con el
experto, quién tras analizar los datos resultado de la evaluación del modelo, indicó una
viabilidad parcial de este, indicando que, en el caso de la predicción de tiempo, el error llega a
ser un poco elevado, teniendo en cuenta la raíz del error cuadrático medio (RMSE) y el error
absoluto medio (MAE). Sin embargo, este valor puede llegar a ser manejable añadiéndolo al
resultado que se le entrega al cliente.
6 Conclusiones
Finalmente, esta sección concluye el trabajo realizado en este proyecto y propone
alternativas para un posible trabajo futuro.
6.1 Discusión
Este proyecto empezó por la realización de un análisis de negocio y procesos en el sector de
los restaurantes, más específicamente, referente a las cocinas ocultas. De este estudio, se
construyeron modelos aquí considerados como de gran utilidad para plantear diversas
propuestas de aplicaciones que optimicen la producción ya la logística, además de resaltar la
importancia de digitalizar el manejo de las cocinas tipo dark kitchens de forma más inteligente.
Finalmente construyó un sistema transaccional con una interfaz gráfica muy sencilla con el fin
de simular los posibles sistemas de información que pueden existir para un restaurante de este
20
tipo, se simularon datos correspondientes a ordenes generadas y finalmente se entrenó un
modelo para predecir la duración de una orden dadas las circunstancias del momento.
Tras la realización de las tareas investigativas y la construcción de los prototipos y modelos,
se llegó a la conclusión de que la necesidad de implementar un sistema capaz de gestionar los
recursos en un restaurante existe, sean estos, por ejemplo: insumos, personas, proveedores,
inventarios, etc. Con el fin de utilizar estos datos de forma operativa para ser competitivos e
informar de manera correcta a los clientes, como también usarlos de forma estratégica para una
correcta toma de decisiones.
6.2 Trabajo Futuro
Este proyecto se construyó con un fin en la mente, por lo tanto, es el primero de una serie
de proyectos que buscan impulsar la digitalización del sector. Como trabajo futuro, se parte de
las recomendaciones dadas por el experto del negocio en varias de sus entrevistas para construir
la completitud del ecosistema orientado a apoyar la operación de las Dark o Cloud kitchens.
La primera propuesta radica en el núcleo de este proyecto, sea este el refinamiento del
modelo para la predicción de tiempos. Esto se debe a la baja precisión estadística que este tuvo.
Una buena alternativa a tratar sería tomar un camino por el área del modelado y la simulación
para llegar a predicciones más cercanas a la realidad, teniendo en cuenta más variables y datos
reales.
La segunda propuesta es la implementación de un sistema de Inteligencia de Negocios con
el fin de aprovechar toda la información relacionada a proveedores e inventarios para el
escogimiento estratégico de estos y a su vez para la creación de nuevos productos y
promociones.
Finalmente, en relación con el énfasis que el experto hizo sobre la seguridad y confianza
requerida en el tema del registro de calificaciones en el sistema de proveedores, la
implementación de un sistema que aplique blockchain 16es una alternativa que podría ser
explorada para el registro confiable y seguro de dichas transacciones.
16 http://scet.berkeley.edu/wp-content/uploads/BlockchainPaper.pdf
21
7 Referencias
Bednarz, C. (2018, January 23). Who Invented the First Modern Restaurant? Tomado
de https://www.nationalgeographic.com/culture/food/the-plate/2015/03/13/who-
invented-the-first-modern-restaurant/
Lang, G. (2020, March 21). Restaurant. Tomado de https://www.britannica.com/topic/restaurant
Logistic, F. (n.d.). The History and Modern Revolution of Food Delivery Service: Folo -
Blog. Tomado de https://folo.my/blog/what-is-a-food-delivery-service#:~:text=The
concept of food delivery, their fast food restaurants Thermopolium
Deliverect. (n.d). Dark Kitchens 101: Bringing more customers the food they want with higher
profits and lower costs. [PDF file]. Tomado
de https://cdn2.hubspot.net/hubfs/5256387/Ebooks/Dark%20Kitchens%20101.pdf
Hanet, I. (n.d.). What is a dark kitchen? Tomado de https://www.deliverect.com/blog/dark-
kitchens/what-is-a-dark-kitchen
John ParkinsonFollowGlobal Head of Data Architecture for HSBC RBWM, Follow, &
John ParkinsonGlobal Head of Data Architecture for HSBC RBWM. (n.d.). What is
Data Architecture? Tomado de https://www.linkedin.com/pulse/what-data-architecture-
john-parkinson/
22
8 Anexos
Anexo A: Arquitectura actual del negocio
23
Anexo B: Motivadores de negocio
24
Anexo C: Arquitectura propuesta