Checklist para cambiar de sistema en un restaurante sin romper caja, cocina o facturación

El mayor riesgo no es instalar software nuevo, sino descubrir el día del corte que faltan datos, permisos, series, productos o una forma de volver atrás. Por eso el primer paso no es pedir una cotización: es definir qué tendría que mejorar para que el cambio valga la pena. En este caso, el objetivo es convertir la migración en una secuencia verificable con responsables y criterios de salida. Escribe cómo sabrás que ocurrió y qué evidencia necesitarás para defender la decisión semanas después.

Usa Respaldo, Configuración, Pruebas, Contingencia como criterios iniciales, pero dales peso según tu realidad. Un criterio que afecta cien operaciones al día merece más atención que una función vistosa que aparece una vez al mes. El orden de evaluación debe seguir frecuencia, riesgo y costo de recuperación.

Recorre Inventario → Respaldo → Configuración → Prueba → Capacitación → Corte y registra qué información entra, quién la valida y dónde queda después. Si la decisión incluye migración o cambio de herramienta, usa una muestra representativa antes de mover todo el negocio. Los errores pequeños son baratos durante una prueba y caros durante una apertura real.

Incluye deliberadamente Catálogo incompleto el día del corte, PIN o permisos no funcionan, Facturación no validada antes de abrir. Una buena decisión no elimina la posibilidad de error; crea una forma rápida de detectarlo, corregirlo y explicar qué ocurrió. Esa capacidad de recuperación es parte del producto y debe evaluarse igual que la función principal.

Guarda una línea base antes del cambio: tiempo por tarea, frecuencia de correcciones, pasos manuales y costos contractuales conocidos. Repite la medición después de que el equipo haya tenido tiempo de aprender el nuevo flujo. Comparar el primer día con un proceso antiguo ya dominado suele producir conclusiones injustas.

El resultado debería responder si mejoraron Respaldo, Configuración, Pruebas, Contingencia y si las excepciones principales dejaron de consumir trabajo innecesario. No atribuyas ventas o rentabilidad al software sin evidencia. Un ROI defendible distingue correlación, ahorro observado y beneficios que todavía son hipótesis.

Prueba “Respaldo” usando datos que se parezcan a los de un restaurante preparando un cambio de sistema. Empieza en inventario y continúa hasta respaldo sin preparar el sistema para que todo salga perfecto. Cambia una condición a mitad del recorrido y revisa si “Configuración” sigue teniendo contexto. Incluye también el caso “Catálogo incompleto el día del corte”: si la recuperación exige borrar la operación o crear una segunda versión, todavía existe una debilidad que debes resolver antes de depender del flujo.

Para evaluar “Configuración”, observa qué ve la persona que recibe el trabajo después de respaldo. No basta con que el dato exista en algún menú; debe aparecer en el momento en que cambia una decisión. Contrástalo con “Pruebas” y documenta qué sucede ante “PIN o permisos no funcionan”. Una buena implementación deja una señal comprensible, una autoridad clara para corregir y un historial suficiente para que el siguiente turno no tenga que reconstruir lo ocurrido.

“Pruebas” merece una prueba de responsabilidad: quién puede modificarlo, quién solo lo consulta y qué parte del flujo se actualiza cuando cambia. Recorre Configuración → Prueba con dos roles distintos y verifica que “Contingencia” no dependa de permisos excesivos. Después provoca “Facturación no validada antes de abrir”. Si la única forma de continuar es compartir credenciales, editar datos sin rastro o pedir a una persona concreta que intervenga, el proceso todavía no está preparado para crecer con seguridad.

Con “Contingencia” conviene mirar escala y no solo funcionalidad. Repite Prueba → Capacitación varias veces, mezcla operaciones normales con “Catálogo incompleto el día del corte” y comprueba si “Respaldo” conserva velocidad y claridad. Pregunta además qué límite contractual, técnico o de configuración cambia con más volumen. El objetivo no es exigir capacidad infinita; es saber con anticipación cuándo la operación necesitará otro plan, más hardware o una configuración distinta para seguir siendo predecible.

Simula “Catálogo incompleto el día del corte” durante inventario. La prueba termina solo cuando la operación llega otra vez a configuración con un estado coherente. Revisa qué mensaje recibió el equipo, quién tuvo permiso para actuar y cómo quedó afectado “Configuración”. Esta disciplina evita aceptar una demo donde el error se resuelve reiniciando, borrando o corrigiendo directamente en base de datos: acciones que no representan una recuperación sostenible para un restaurante en producción.

Cuando ocurra “PIN o permisos no funcionan”, mide tiempo hasta detección y tiempo hasta resolución por separado. Un problema puede ser fácil de corregir pero difícil de descubrir, y esa demora puede contaminar respaldo, prueba o “Pruebas”. Pide que el sistema muestre suficiente evidencia para distinguir causa de síntoma. Si todos ven que algo está mal pero nadie puede explicar por qué, el flujo todavía produce trabajo de investigación que debe formar parte de la evaluación.

Usa “Facturación no validada antes de abrir” como prueba de cambio de turno. Una persona inicia el caso en configuración y otra debe poder terminarlo en capacitación sin una explicación verbal privada. Comprueba que “Contingencia” conserve contexto, que las acciones sensibles tengan autor y que los comentarios necesarios queden junto a la operación. La continuidad entre personas es una señal fuerte de que el proceso vive en el sistema y no solamente en la memoria del equipo.

Antes del cambio, crea un inventario de dependencias: equipos, impresoras, usuarios, series fiscales, proveedores, integraciones, dominios, catálogos y flujos de cocina. Marca qué elemento es crítico para abrir. Esta lista evita concentrarse solo en datos y olvidar una credencial o dispositivo que puede detener la operación. Asigna responsable y estado de validación a cada dependencia.

Diseña un ensayo de apertura. Crea productos reales, abre caja, toma pedido, envía a cocina, cobra, emite comprobante y cierra. Repite con una excepción. La prueba debe parecerse a la primera hora del día de corte. Si algo falla, documenta solución y repite desde cero con otra persona. El objetivo es comprobar que el procedimiento puede ejecutarse, no que el equipo técnico sabe rescatarlo.

Prepara comunicación interna y externa. El equipo necesita saber qué cambia, a quién pedir ayuda y qué procedimiento temporal usar si una función no está disponible. Si el cambio afecta links de pedidos, dominios o comprobantes, revisa también la experiencia del cliente. Una migración puede ser técnicamente correcta y generar confusión si el personal sigue compartiendo enlaces antiguos o usando accesos previos.

El día de corte conserva un punto de retorno. Define hasta qué momento puedes volver al sistema anterior sin mezclar ventas de forma irreversible. Después del corte, revisa caja, pedidos, cocina y facturación en intervalos cortos. Cuando completes uno o varios ciclos completos sin incidentes críticos, recién considera la migración estabilizada. La checklist termina con verificación operativa, no con el deploy.