El módulo de pedidos de tu programa de gestión no nació para gestionar pedidos

El módulo de pedidos de tu programa de gestión no nació para gestionar pedidos

En resumen

• Un módulo de pedidos incluido en un TPV, en un programa de reservas o en uno de almacén optimiza el flujo para el que ese programa fue diseñado: el pedido al proveedor llegó después, y se nota mientras lo usas.
• El límite real no es cuántas referencias pides, son las reglas que cada proveedor trae consigo: ventana de pedido, formato de la tarifa, frecuencia de reparto.
• WhatsApp no es el desorden: es la compensación manual de un trabajo que ningún sistema está sosteniendo por ti.
• Una herramienta nacida para pedir arranca del proveedor y del calendario, no del maestro de artículos.
• Cambiar de herramienta no mejora la relación con tus proveedores ni baja los precios por sí sola: mueve el trabajo de la memoria de las personas al sistema.

Por qué el módulo de pedidos «incluido» siempre te sabe a medias

El módulo de pedidos de un programa de gestión generalista se diseñó alrededor de otro flujo: cobrar tickets, rotar mesas, cuadrar reservas, descontar almacén. El pedido al proveedor apareció más tarde, como consecuencia del almacén —cuando la existencia baja de un mínimo, alguien tiene que comprar— y esa genealogía se ve por dentro del software.

La señal más clara es dónde vive el proveedor en los datos. En un programa nacido para el almacén, el proveedor es un atributo del artículo: un campo «proveedor habitual» en la ficha del producto. Funciona mientras cada artículo tenga un proveedor y solo uno. Luego llega la semana en la que coges la patata del segundo frutero porque el primero está sin género, y descubres que ese campo no estaba pensado para guardar una decisión, sino un dato maestro.

Los software de compras que hoy aparecen buscando este tema —Procurify, Order.co y similares— no arrastran ese problema, porque nacen de las compras. Arrastran otro: nacen de las compras de una empresa cualquiera, donde se piden folios y licencias de software, no cajas de pescado que tienen que estar en cocina antes de las siete. Un restaurante no necesita un módulo de pedidos genérico ni un procurement genérico: necesita una herramienta que conozca la forma que tienen sus pedidos.

El jueves por la noche en WhatsApp: el flujo que de verdad estás sustituyendo

El flujo real de un restaurante que pide a mano no es desordenado: está repartido. WhatsApp para el fresco, una llamada al carnicero que solo lo coge antes de las once, un PDF por correo para las bebidas, y ninguno de los tres canales sabe qué han hecho los otros dos. Pongamos una escena típica, declarada por lo que es —un ejemplo, no un caso real—: jueves por la noche, cierre, y el segundo de cocina manda tres audios a tres proveedores distintos mientras apaga las freidoras.

Lo que sostiene ese flujo no son los mensajes, es la memoria de las personas. Alguien sabe que el de fruta y verdura cierra pedidos a las seis y que los lunes no reparte. Alguien sabe que la tarifa de proveedor buena del pescado es la que llegó al chat hace dos semanas y no la que está impresa y colgada en el economato. Alguien recuerda que el precio de la mantequilla se había cerrado distinto del que aparece en el albarán. Mientras esa persona esté, el sistema aguanta.

El coste no se ve en un pedido mal puesto, se ve en la recepción de mercancía y a final de mes. El albarán llega, alguien lo firma con prisa porque el repartidor espera, y el cotejo con el precio acordado —si es que ocurre— ocurre semanas después, contra una factura resumen, cuando el género ya se ha consumido. WhatsApp no es la causa de nada: es la prótesis que ese trabajo se ha fabricado solo.

Ventana de pedido, tarifa y frecuencia: los tres límites que tu programa no modela

Cada proveedor trae tres reglas propias, y son esas —no el número de referencias— las que le dan a los pedidos una forma que el almacén no tiene. La primera es la ventana de pedido: el intervalo dentro del cual el pedido se acepta para el siguiente reparto. No es un horario escrito en ningún sitio, es un estado que cambia a lo largo del día: a las cinco ese pedido sale mañana, a las siete sale pasado, y la diferencia la paga el servicio de la noche.

La segunda es la tarifa de proveedor, que en hostelería no es un archivo, es una especie con subespecies. Uno te la manda en PDF, otro en Excel, otro como foto de una hoja escrita a mano, otro no te la manda y los precios te los canta por teléfono. Un módulo de pedidos genérico da por hecho un catálogo estable con precios cargados; tu proveedor de pescado tiene precios que se mueven con la lonja, y el documento que los trae cambia de formato cada vez que cambia el comercial.

La tercera es la frecuencia de reparto: quien pasa tres veces por semana, quien martes y viernes, quien solo bajo pedido con dos días de aviso. Por separado son obviedades que cualquiera que trabaje en cocina lleva de memoria. Juntas, multiplicadas por los proveedores que tienes, son un calendario que nadie ha escrito nunca y que vive entero en la cabeza de dos o tres personas. El módulo de pedidos del programa no lo modela porque no sabe que existe: para él hay un punto de reposición y un proveedor habitual.

Qué hace una herramienta nacida para pedir

Una herramienta nacida para pedir arranca del proveedor y del calendario en lugar del maestro de artículos, y eso cambia las decisiones de producto una a una. La cesta no es una: es una por proveedor, porque la unidad de trabajo real es el pedido que sale hacia una contraparte, no la lista de la compra en conjunto. La ventana de pedido no es un recordatorio, es un estado del sistema: si está cerrada lo ves mientras montas el pedido, no después de haberlo mandado.

La tarifa de proveedor deja de ser un adjunto y pasa a ser un dato vivo, con historia: el precio de hoy, el de la última vez que pediste, y la diferencia entre los dos delante de los ojos de alguien antes de confirmar, no a final de mes. Es la misma razón por la que el pedido recurrente no es una plantilla que rellenas otra vez, sino el punto de partida: la semana pasada pediste esto, cambia lo que tenga que cambiar y envía.

Y es también la razón por la que una herramienta así está obsesionada con el móvil. Los pedidos no se hacen sentado a la mesa del despacho a las nueve de la mañana: se hacen de pie, con una mano, entre dos servicios. Un módulo pensado para el back office puede permitirse ser denso; una herramienta de pedidos no, porque su competidor de verdad no es otro software, es un audio de WhatsApp que cuesta diez segundos.

Cómo saber si el módulo que tienes te está costando algo

Las señales se leen en los documentos de esta semana, no en un cuestionario de madurez digital. Coge los últimos siete días y comprueba:

• ¿Dónde está la tarifa actualizada de cada uno de tus proveedores principales? Si para alguno la respuesta es «en un chat» o «eso lo sabe Marta», ese precio no está en ningún sistema.
• ¿Quién se sabe de memoria las ventanas de pedido? Si el número de personas que pueden pedir sin preguntar es uno, tienes un problema de plantilla disfrazado de procedimiento.
• ¿Cuántos albaranes de esta semana se han cotejado con el precio que esperabas antes de firmarlos?
• ¿Cuántos pedidos de esta semana existen solo como mensaje enviado, sin copia en un sitio donde buscarlos dentro de un mes?
• ¿Cuándo fue la última vez que tu módulo de pedidos te impidió equivocarte: un proveedor ya cerrado, un precio que había cambiado, una cantidad fuera de escala?

La última pregunta pesa más que las otras. Una herramienta que registra pedidos hace archivo; una herramienta que te para antes del error está haciendo el trabajo.

Qué no resuelve una herramienta dedicada

Una herramienta dedicada a los pedidos no mejora la relación con tus proveedores, no baja los precios por sí sola y no le quita a nadie la negociación. Si la mantequilla te sale cara porque el volumen que mueves es el que es, sigue saliendo cara dentro de una app bien hecha, con la diferencia —que no es pequeña— de que ahora lo ves mientras pides y no cuando llega la factura resumen.

Y tiene un coste de entrada real, que conviene mirar de frente antes de firmar nada: el maestro de artículos y las tarifas hay que cargarlos una primera vez, y luego mantenerlos cuando cambia un proveedor o cambia un formato. Es el trabajo que ya estás haciendo hoy, pero repartido en cien gestos pequeños que no parecen trabajo porque nadie los ha contado nunca juntos. La pregunta no es si ese trabajo existe: es si prefieres que viva en un sistema o en la cabeza de tu segundo de cocina, el día que tu segundo de cocina esté de vacaciones.