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