Notizen zu Produkt, Engineering und Betrieb.
Notas sobre operaciones, producto y tecnología.
Un ERP gestiona el negocio en el pasado. Un software operacional lo gestiona en el presente. Entender la diferencia es clave para elegir las herramientas correctas.
La conexión a internet no debería ser un punto de fallo en una gelatería, un restaurante o una tienda. Así funciona el modo offline-first.
Tres sistemas que aún funcionan desconectados en muchos restaurantes y que pueden coordinarse desde una única plataforma.
Cuatro herramientas que no se comunican entre sí cuestan más de gestionar que una plataforma con cuatro módulos activos. Aquí está el cálculo real.
5 min de lectura
El software operacional es el conjunto de herramientas que sostiene las operaciones en tiempo real: el TPV que usa un cajero en cada transacción, la pantalla de cocina (KDS) que muestra los pedidos activos al chef, el sistema de inventario que descuenta una unidad en el mismo instante en que se produce la venta. Su función es mantener el negocio en marcha durante la jornada, no registrar lo que ocurrió después de que cerró. El ERP, por el contrario, agrega, consolida y reporta. Su valor está en la visión histórica, en la contabilidad, en los cierres de mes y en los informes financieros de fin de día.
La diferencia se hace concreta con dos ejemplos. Un gerente abre su ERP a las 21:00 para revisar las ventas del día: eso es inteligencia de negocio trabajando sobre el pasado. Un chef mira la pantalla de cocina tres segundos después de que el camarero ha introducido el pedido número 42 y ya ve los ítems, el tiempo transcurrido y la mesa de destino: eso es software operacional actuando sobre el presente. Los dos escenarios son necesarios; ninguno reemplaza al otro.
El software operacional tiene requisitos técnicos específicos que no comparte con el ERP. La latencia debe ser de milisegundos: en una pantalla de cocina, un retraso de diez segundos entre el pedido y la visualización es operativamente inaceptable. La disponibilidad offline es imprescindible: un corte de internet no puede detener un restaurante lleno. Y el diseño de pantalla tiene que funcionar con guantes, en condiciones de poco espacio y mucho ruido, algo radicalmente distinto de la interfaz pensada para el contable que trabaja en un escritorio.
Muchas empresas intentan operar desde su ERP o desde un TPV genérico que no fue diseñado para su tipo de negocio. El resultado es predecible: aparecen los parches. Una hoja de cálculo impresa pegada en la pared de la cocina con las recetas del día. Un grupo de WhatsApp entre el encargado y el proveedor para coordinar reposiciones urgentes. Un empleado dedicado cada noche a reconciliar manualmente los datos de tres sistemas distintos. Esos síntomas no indican mala gestión; indican que la herramienta equivocada está intentando resolver el problema correcto.
Los dos sistemas sirven momentos distintos del ciclo del negocio y se complementan cuando están bien conectados. El software operacional es el que alimenta datos al ERP, no al revés. Las ventas registradas en el TPV durante el día deben fluir automáticamente al sistema contable al cierre. El inventario actualizado en tiempo real debe cuadrar con las entradas del ERP sin intervención manual. Una arquitectura bien pensada conecta ambas capas y elimina la duplicación de datos.
Elegir software operacional no es sustituir el ERP. Es añadir una capa de tiempo real entre el trabajo y el reporting. Un negocio que no tiene esa capa opera con información con horas de retraso, coordina mediante procesos manuales y depende de que las personas estén en el lugar correcto para que la información circule. Con la capa operacional activa, el trabajo genera datos automáticamente, la coordinación es digital y los informes del ERP reflejan lo que ocurrió de verdad.
4 min de lectura
Es sábado a las 14:00. El restaurante está lleno, hay lista de espera y acaba de caerse el internet. Si el TPV depende de la nube para funcionar, las operaciones se detienen. La cola de pedidos crece. La cocina pierde visibilidad de los platos en curso. El camarero no puede cobrar. Este no es un escenario hipotético: ocurre con regularidad en locales que dependen de una conexión estable que nadie puede garantizar.
Offline-first significa que los datos se escriben localmente primero, en el dispositivo, y se sincronizan con el servidor en cuanto la conectividad se recupera. El sistema nunca espera una confirmación del servidor para dejar que el operador continúe. El cajero cobra, el pedido llega a la cocina, el inventario se descuenta. Todo ocurre como si hubiera internet, porque la aplicación no lo necesita para tomar decisiones.
Hay una distinción técnica importante que con frecuencia se pasa por alto. Un sistema que 'funciona offline' puede significar simplemente que muestra una versión cacheada de solo lectura: puedes ver el menú pero no procesar una venta. Offline-first implica capacidad completa de lectura y escritura sin conexión, más un mecanismo de resolución de conflictos para cuando se produce la sincronización. Si dos dispositivos han modificado el mismo registro mientras estaban desconectados, el sistema necesita reglas claras para decidir cuál prevalece.
Los escenarios que hacen indispensable el modo offline-first son más comunes de lo que parece. Una gelatería en un mercado callejero con cobertura 4G inestable. Un restaurante en un sótano o un local con sótano de cocina donde el WiFi no llega con fiabilidad. Una tienda en un edificio compartido donde el router está en una planta diferente y la señal cae en horas punta. Una terraza de verano que usa un punto de acceso móvil. En todos estos casos, la conectividad es variable, no garantizada.
Cuando la conexión se recupera, el sistema sincroniza en orden: ventas completadas, movimientos de inventario, entradas de producción, acciones de cliente. Las reglas de resolución de conflictos determinan qué prevalece cuando hay escrituras concurrentes: last-write-wins para registros independientes como una venta o una nota de pedido; autoridad del servidor para recursos compartidos como el stock total de un ingrediente, donde el conteo del servidor es la fuente de verdad.
El estándar debería ser que el internet sea opcional, no requerido. Si el TPV no puede procesar una venta sin conexión, las operaciones del negocio tienen un punto de fallo que está fuera del control del operador. La decisión de qué herramienta usar es también una decisión sobre qué riesgos operativos se asumen. Un sistema offline-first no elimina los problemas de conectividad, pero sí elimina que esos problemas detengan el negocio.
5 min de lectura
En muchos restaurantes el proceso sigue siendo analógico: el camarero anota el pedido en un bloc, camina hasta la ventanilla de cocina, grita los platos o deja el papel en una pinza metálica. El chef transcribe la comanda en una pizarra blanca. Al cerrar el turno, alguien actualiza el Excel de inventario con lo que cree que se ha consumido. Son tres procesos separados, sin datos compartidos, dependientes de que las personas estén en el sitio correcto en el momento exacto.
Cuando los tres sistemas están conectados el funcionamiento cambia por completo. El TPV envía el pedido al KDS (Kitchen Display System) en el instante en que el camarero lo confirma. La cocina lo recibe en la pantalla con el número de mesa, el tiempo transcurrido y la prioridad asignada. Al mismo tiempo, el inventario registra automáticamente los ingredientes consumidos. No hay papel, no hay intermediario, no hay versión de la información que difiera de otra.
El KDS no es simplemente una pantalla que muestra comandas. Es el centro de coordinación de la cocina. Indica qué platos están en preparación, cuáles llevan más tiempo del esperado y cuáles se han marcado como listos para que el camarero los recoja. El jefe de cocina puede reordenar prioridades desde la pantalla, agrupar platos del mismo pase y ver de un vistazo el estado de cada mesa activa. La información que antes vivía en notas pegadas con cinta o en la memoria del jefe de partida ahora es visible y actualizable para todo el equipo.
La conexión con el inventario cierra el ciclo de datos. Cada venta genera una transacción de inventario. Cuando se sirve el plato A, el ingrediente B se descuenta en la cantidad correspondiente a la receta. Cuando el stock de un ingrediente cae por debajo del mínimo configurado, se genera una alerta automática. Ya no es necesario esperar al recuento de cierre para saber si queda materia prima suficiente para el servicio de la noche: el dato está actualizado en cada venta.
Para restaurantes con producción propia, la conexión va un nivel más allá. Si un plato usa una salsa preparada en el turno de mañana, el consumo de esa salsa se descuenta de los lotes de producción registrados. El cocinero sabe antes de empezar el servicio cuánto de cada elaboración hay disponible, sin necesidad de ir a la cámara a contar físicamente. La producción y el servicio comparten la misma fuente de datos.
El beneficio en reporting es proporcional a la calidad de los datos recogidos durante el día. Con los tres sistemas conectados, el informe diario no muestra solo ingresos: muestra el coste real de cada plato servido, la eficiencia de producción por elaboración, los patrones de pedido más frecuentes por franja horaria y las diferencias entre el inventario teórico y el real. Datos que eran imposibles de obtener cuando cada sistema vivía por separado y alguien los unía manualmente al final de la jornada.
La tecnología aquí no es un fin en sí mismo. Conectar cocina, ventas e inventario elimina la fricción entre tomar un pedido y entregarlo correctamente. Reduce los errores de comunicación, acelera los tiempos de servicio y da al equipo información en tiempo real en lugar de datos de ayer. El resultado es operacional antes que tecnológico: el negocio funciona mejor porque la información fluye sin interrupción de un extremo al otro.
4 min de lectura
El escenario es habitual: un TPV para ventas, una herramienta de inventario separada, una hoja de cálculo para la producción y otro sistema distinto para los datos de clientes. Cada uno fue la mejor opción disponible cuando se adoptó. Individualmente son razonables. En conjunto, generan un trabajo invisible que no añade valor: cada día alguien tiene que trasladar datos de un sistema a otro, resolver las diferencias entre los totales de ventas del TPV y los movimientos de inventario del otro sistema, y asegurarse de que la información de clientes refleja las últimas compras.
Los costes ocultos de las herramientas desconectadas se acumulan de formas que rara vez se contabilizan. La entrada duplicada de datos: la misma venta registrada en el TPV y después transcrita manualmente al sistema de inventario. Los informes inconsistentes: las ventas del TPV no cuadran con el inventario del otro sistema porque los dos tienen definiciones distintas de cuándo se produce un descuento de stock. El tiempo de reconciliación al cierre del día, que puede ser de una o dos horas en operaciones medianas, dedicado enteramente a resolver diferencias entre sistemas que deberían hablar entre sí.
Una plataforma modular parte de un modelo de datos único. Una venta en el TPV actualiza automáticamente el inventario, añade la transacción al historial del cliente y aparece en los informes en tiempo real. No hay transferencia manual, no hay reconciliación, no hay versiones distintas del dato en distintos sistemas. La información se genera una sola vez y está disponible para todos los módulos que la necesiten.
Modular no significa todo o nada. Empezar con TPV e Inventario y añadir el módulo de Producción seis meses después, cuando la operación esté lista para ese nivel de detalle, es un camino completamente válido. Los datos acumulados desde el primer día ya estarán ahí cuando se active el nuevo módulo: el histórico de ventas alimentará inmediatamente los análisis de consumo de materia prima sin necesidad de importaciones manuales ni migraciones.
La integración de hardware también se simplifica con una plataforma unificada. En lugar de configurar cada impresora, cada lector de código de barras y cada pantalla de cocina con cada sistema por separado, hay un único punto de integración. Los dispositivos hablan con la plataforma, y la plataforma distribuye la información a los módulos correspondientes. Añadir un nuevo terminal o una nueva pantalla es una operación de minutos, no de horas.
La pregunta correcta no es cuál herramienta es la mejor para cada función por separado. Es qué plataforma puede crecer con la operación sin añadir complejidad en cada paso. Cuatro herramientas excelentes que no se comunican generan más coste de gestión que una plataforma con cuatro módulos activos. El coste de integración de las herramientas aisladas no aparece en ninguna factura, pero está ahí, en horas de trabajo y en datos que nunca son del todo fiables.
¿Quieres saber más sobre Segadev?
Contactar