Datos de restaurante: modelo, calidad y linaje
Datos de restaurante para analytics: crea una base que pueda auditarse
El POS registra una venta a las 00:18. Reservas la asigna al viernes; contabilidad, al sábado. Delivery conserva el importe bruto; el depósito llega sin una devolución posterior. Inventario usa el nombre actual del platillo, aunque el ticket contiene el nombre anterior. Todos los archivos son “correctos” dentro de su contexto y, aun así, el reporte final puede estar equivocado.
Preparar datos de restaurante para analytics significa documentar esa realidad antes de calcular indicadores. Este artículo cubre fuentes, IDs, eventos, uniones, calidad, linaje y acceso. No desarrolla un catálogo de métricas ni una rutina gerencial; cuando esta base esté lista, consulta cómo convertir datos en decisiones y KPI.
La entrega mínima de una base confiable incluye:
- inventario de fuentes y propietarios;
- modelo canónico de orden, línea, pago y eventos;
- diccionario con definiciones y reglas;
- controles de calidad medibles;
- conciliaciones contra fuentes financieras y operativas;
- linaje desde el reporte hasta el registro origen;
- permisos, retención y respuesta a incidentes.
Inventaría las fuentes antes de unirlas
Empieza con una ficha por sistema:
| Fuente | Grano del dato | ID disponible | Hora y zona | Cambios posteriores | Propietario |
|---|---|---|---|---|---|
| POS | Orden, línea o pago | ID interno de orden | Confirmar | Anulación, descuento, devolución | Operaciones/finanzas |
| Reservas | Reserva y visita | ID de reserva | Confirmar | No-show, cancelación, cambio de mesa | Sala |
| Delivery | Orden y liquidación | ID externo | Confirmar | Ajuste, comisión, reembolso | Canal/finanzas |
| Inventario | Movimiento | ID de movimiento | Confirmar | Ajuste o reversa | Almacén |
| Compras | Documento y línea | Orden/factura | Confirmar | Nota de crédito | Compras |
| Personal | Turno o marcaje | ID de empleado/turno | Confirmar | Corrección aprobada | RR. HH. |
El grano indica qué representa una fila. Si un archivo tiene una fila por orden y otro una por producto, unirlos directamente multiplica ventas y pagos. Documenta también frecuencia de actualización, historial disponible, campos personales y cómo se corrige un dato.
No copies todo “por si acaso”. Extrae lo necesario para las decisiones definidas y conserva el vínculo al origen.
Diseña un modelo canónico de órdenes
Los proveedores llaman de manera distinta al mismo concepto. Un modelo canónico traduce esas diferencias sin borrar el dato original.
Tabla de órdenes
Una orden puede incluir:
- order_id canónico;
- source_system y source_order_id;
- location_id y canal;
- created_at, closed_at y fecha operativa;
- estado;
- moneda;
- subtotal, descuento, impuesto, propina y total;
- versión o momento de última actualización.
Tabla de líneas
Cada producto o modificador necesita su propia identidad:
- order_line_id;
- order_id;
- product_id canónico y código origen;
- cantidad y unidad;
- precio antes de descuentos;
- descuento asignado;
- impuesto;
- importe neto;
- estado de línea.
Pagos, devoluciones y eventos
Pago no es sinónimo de orden. Una orden puede tener varios medios, propina posterior, reembolso parcial o contracargo. Mantén pagos y ajustes como registros relacionados, no como columnas sobrescritas.
Una tabla de eventos ayuda a conservar la secuencia: creada, aceptada, enviada a cocina, cerrada, anulada, reembolsada o corregida. Así el reporte puede reconstruir qué se sabía en un momento determinado.
Usa identificadores persistentes
El nombre de un platillo cambia; el ID no debería hacerlo. Tampoco uses teléfono o correo como llave técnica de cliente: cambian, pueden compartirse y son datos personales.
Define:
- ID canónico interno;
- ID de cada sistema origen;
- regla de correspondencia;
- fecha de vigencia;
- responsable de resolver conflictos;
- procedimiento para dividir o fusionar registros.
Conserva una tabla de equivalencias para productos, sucursales, canales y, si existe fundamento y necesidad, clientes. No “dedupliques” automáticamente dos personas porque comparten nombre. La resolución probabilística requiere umbrales, revisión y trazabilidad.
Trata el tiempo como un dato, no como formato
Guarda el timestamp original, su zona horaria y una representación normalizada. Además, define la fecha operativa. Un restaurante que cierra a las 02:00 puede asignar la orden de las 00:18 al servicio iniciado el viernes, aunque el calendario marque sábado.
El diccionario debe aclarar:
- zona de cada fuente;
- horario de verano, cuando aplique;
- corte del día operativo;
- diferencia entre creación, aceptación, cierre, pago y depósito;
- tratamiento de registros tardíos;
- periodo que puede reabrirse.
No elimines el detalle horario después de calcular la fecha operativa. Lo necesitarás para duración, latencia y auditoría.
Concilia antes de agregar
La misma venta aparece en varios sistemas con propósitos diferentes. Crea puentes explícitos:
- orden del canal → orden canónica;
- orden canónica → orden POS;
- líneas POS → productos canónicos;
- pagos y ajustes → orden;
- órdenes incluidas → liquidación;
- liquidación → depósito.
Separa:
- venta bruta;
- descuentos financiados por cada parte;
- anulaciones;
- reembolsos;
- impuestos;
- propinas;
- comisiones y cargos;
- depósito neto.
Una diferencia no siempre es un error. Puede ser un ajuste posterior o una fecha de liquidación distinta. El modelo necesita un estado de conciliación y un motivo, no una corrección silenciosa para forzar que los totales coincidan.
Escribe un diccionario de datos utilizable
Cada campo importante debe tener:
| Elemento | Pregunta |
|---|---|
| Nombre | ¿Cómo se llama en el modelo canónico? |
| Descripción | ¿Qué representa y qué no? |
| Tipo y unidad | ¿Fecha, entero, decimal, moneda, porcentaje? |
| Fuente | ¿Sistema, tabla y campo originales? |
| Regla | ¿Cómo se transforma o calcula? |
| Valores válidos | ¿Qué estados, rangos o nulos se permiten? |
| Propietario | ¿Quién resuelve dudas? |
| Sensibilidad | ¿Contiene datos personales o restringidos? |
| Vigencia | ¿Desde cuándo aplica la definición? |
Versiona el diccionario. Si cambia la definición de “orden completada”, anota la fecha y evalúa si debes reprocesar el historial. Una fórmula sin versión puede producir dos reportes incompatibles con el mismo nombre.
Evalúa seis dimensiones de calidad
El Government Data Quality Framework del Reino Unido propone evaluar la calidad según el propósito y describe dimensiones útiles:
| Dimensión | Prueba en restaurante |
|---|---|
| Completitud | ¿Todas las órdenes cerradas tienen líneas, sitio, hora y estado? |
| Unicidad | ¿Un ID origen aparece una sola vez dentro de su sistema? |
| Consistencia | ¿La suma de líneas y ajustes corresponde al total según la regla? |
| Puntualidad | ¿La fuente llegó antes del cierre acordado? |
| Validez | ¿Estados, monedas, cantidades y fechas pertenecen al dominio permitido? |
| Exactitud | ¿Una muestra coincide con ticket, liquidación o conteo independiente? |
El marco insiste en que la calidad sea adecuada para el uso y se atienda en la fuente cuando sea posible. Un dato puede ser válido pero no exacto: cantidad = 3 cumple el tipo, aunque en realidad se sirvieron dos.
Define umbral, severidad, propietario y respuesta para cada regla. Un campo opcional vacío puede ser aceptable; una sucursal desconocida en una venta cerrada debería detener el reporte correspondiente.
Conserva linaje y metadatos
El linaje permite recorrer:
reporte → métrica → transformación → tabla canónica → extracción → sistema origen
Registra versión de código o consulta, hora de ejecución, periodo de datos, filas leídas, escritas y rechazadas, además de los controles aplicados. Mantén una zona de cuarentena para registros defectuosos; no los descartes sin conteo ni motivo.
Los metadatos operativos también deben responder:
- cuándo se actualizó;
- qué periodo cubre;
- si la carga fue completa o incremental;
- qué incidente afectó el dato;
- quién aprobó la corrección;
- cuándo puede cambiar de nuevo.
Un dashboard sin esta información puede mostrar un número preciso calculado sobre una carga incompleta.
Diseña privacidad y acceso desde el principio
La LFPDPPP publicada por la Cámara de Diputados es la referencia legal federal que debe consultarse en su versión vigente; la página oficial registra la nueva ley publicada el 20 de marzo de 2025 y sus reformas. No reutilices avisos o citas legales antiguos sin revisión profesional.
En términos de diseño:
- minimiza datos personales;
- documenta finalidad y base aplicable;
- separa identidad de comportamiento cuando sea posible;
- limita accesos por función;
- evita datos reales en ambientes de prueba;
- cifra transferencias y almacenamiento conforme al riesgo;
- define retención y eliminación;
- registra exportaciones;
- prepara respuesta a derechos e incidentes.
El NIST Privacy Framework ofrece una estructura voluntaria para identificar y gobernar riesgos de privacidad. No sustituye obligaciones mexicanas, pero ayuda a inventariar tratamiento, propietarios y controles.
Prueba la base con escenarios conocidos
Antes de publicar un reporte, prepara casos con resultado esperado:
- orden normal con dos líneas y un pago;
- descuento a nivel de orden;
- cortesía de una línea;
- cancelación total;
- reembolso parcial posterior;
- propina modificada;
- orden delivery duplicada;
- cambio de día calendario después de medianoche;
- producto renombrado;
- carga incompleta y recuperación.
Para cada caso valida conteo, importes, estados, fechas y linaje. Añade totales de control por fuente y periodo. Si una transformación cambia, ejecuta regresión sobre estos escenarios.
Asigna propiedad y respuesta
Tecnología puede operar la carga, pero no siempre puede decidir qué significa una cortesía o cuándo se cierra el día. Una matriz ligera ayuda:
- Operaciones: estados y flujo de servicio.
- Finanzas: importes, impuestos, descuentos, liquidaciones y cierre.
- Sala/reservas: visita, no-show y mesa.
- Almacén: movimientos y unidades.
- Privacidad/legal: finalidades, acceso, retención y derechos.
- Datos/tecnología: modelo, transformación, pruebas y monitoreo.
Cada regla de calidad necesita un responsable de resolver, no solo alguien que reciba la alerta.
De la fuente confiable a la decisión
Esta tabla solo muestra el destino; el catálogo completo pertenece al artículo de analytics:
| Base preparada | Decisión que habilita |
|---|---|
| Órdenes, líneas y costos conciliados | Revisar contribución y mezcla de menú |
| Reservas y visitas relacionadas | Ajustar capacidad y política de confirmación |
| Eventos de pedido con timestamps | Investigar tiempos y cuellos de botella |
| Venta, ajustes y depósitos | Evaluar canales con importes comparables |
| Movimientos de inventario | Investigar consumo, diferencia y merma |
Cuando estas relaciones sean trazables, puedes convertir datos en decisiones y KPI sin discutir en cada reunión de dónde salió el número.
Kavasoft puede formar parte del ecosistema operativo de un restaurante, pero ningún proveedor sustituye la definición compartida de datos, responsabilidades y conciliaciones. Conoce el alcance de Kavasoft para restaurantes y valida las integraciones requeridas para tu arquitectura.
