Implantar software sin convertir el viernes en una prueba

El problema en el servicio

El sistema nuevo parece sencillo en una demostración, pero llega el primer servicio y aparecen los casos que no se probaron: una modificación, un cliente que cambia de dirección o un producto que se agota. El problema no siempre es la herramienta; puede faltar una puesta en marcha que contemple la operativa real.

La propuesta de esta guía es no estrenar todas las decisiones durante una hora punta. Una implantación necesita datos preparados, responsables y pruebas de aceptación, además de instalar o activar el software.

Ordena la información antes de probar

Revisa carta, nombres, tamaños, extras, horarios y zonas. Acuerda quién puede confirmar esos datos y cuál es la versión válida. Si el restaurante utiliza referencias contradictorias, la prueba empezará con un problema que no corresponde resolver al cliente.

Elige también el alcance inicial. Puedes priorizar la parte donde hoy aparecen más incidencias, sin suponer que eso modifica automáticamente las condiciones comerciales contratadas. El alcance técnico y el comercial deben quedar claros antes de activar el servicio.

Prepara casos que puedan fallar

No pruebes solo un pedido sencillo. Incluye dos productos parecidos, una modificación diferente en cada unidad, una dirección incompleta, un agotado y una consulta que necesite una persona. Utiliza datos ficticios, no información de clientes expuesta sin necesidad.

Define qué resultado esperas en cada caso. «Funciona» es demasiado general. Un criterio útil sería que el pedido no entre en producción si falta una confirmación que el restaurante considera obligatoria, y que el equipo sepa quién debe resolverla.

Haz participar a quien prepara y entrega

En un escenario hipotético, recepción completa todas las pruebas, pero cocina descubre después que no distingue dos versiones de un menú. La prueba técnica había pasado por alto a quien ejecuta el trabajo.

Recorre el pedido completo con las personas de cada etapa. Comprueba si entienden la información sin una explicación adicional del instalador. Una formación útil debe permitir que el equipo actúe con autonomía cuando la ayuda no esté junto al mostrador.

Cómo plantea la implantación Zestia

La puesta en marcha pública de Zestia incluye revisar el flujo, configurar atención, ordenar cocina y reparto y ajustar los primeros casos en producción. [1]

El calendario concreto debe acordarse según la información, configuración y validaciones necesarias. No conviene prometer una activación universal en un plazo fijo para cualquier restaurante. La medida útil es que se cumplan los criterios de aceptación del alcance acordado.

Acuerda una contingencia antes del arranque

Define quién atiende si falla la conexión o aparece una incidencia, cómo se conserva la referencia de los pedidos y cómo se reconcilian después. El procedimiento debe probarse con el responsable técnico; no improvisarse durante el servicio.

Tras el arranque, revisa incidencias concretas y prioriza ajustes. La puesta en marcha no termina por haber realizado una formación inicial. Termina cuando el recorrido acordado funciona de manera comprensible para el equipo y los casos pendientes tienen responsable.

Empieza por un recorrido pequeño que puedas cerrar

La primera prueba debería recorrer un pedido desde entrada hasta entrega con una carta representativa y un equipo informado. Elige productos que incluyan alguna variante, una recogida y un domicilio. No necesitas cargar toda la complejidad del restaurante para descubrir si falta una pregunta o si una comanda resulta difícil de leer. Sí necesitas comprobar el final, porque un pedido bien tomado puede atascarse al cobrar o salir.

Define qué parte del servicio se va a probar y qué queda fuera. Mantén un procedimiento de contingencia conocido y una persona que pueda decidir volver a él. Esa vuelta debe evitar pedidos duplicados: registra cuáles ya están aceptados y cómo se continuarán. Cambiar de herramienta no debe crear dos listas activas sin una regla de conciliación.

Una secuencia de implantación por etapas

No conviertas una fecha del calendario en prueba de preparación. Si el ensayo revela un problema crítico, ajusta el alcance antes de ampliar. La tabla no prescribe una duración universal: el tiempo necesario depende de carta, equipo y condiciones de puesta en marcha. La propuesta debe concretar acompañamiento y responsabilidades.

Ensaya excepciones que sí pueden ocurrir

Incluye un producto agotado, una dirección incompleta, una modificación y una llamada que necesita una persona. Comprueba quién detecta cada situación y qué información llega al puesto siguiente. Una demostración de un pedido perfecto solo prueba el recorrido más sencillo. El servicio real exige saber qué hacer cuando falta algo.

Añade una prueba de cambio de turno y de indisponibilidad de un puesto, sin interrumpir una operación real. Documenta el procedimiento de contingencia que se acuerde para esa instalación. No supongas funcionamiento sin conexión, recuperación automática o soporte permanente si no están verificados y recogidos en el alcance contratado.

Formación por tareas, con el puesto real

Recepción debe practicar identificación, confirmación y corrección. Cocina necesita interpretar comanda, notas y estados. Reparto debe localizar datos necesarios y cerrar una entrega o registrar una incidencia. El encargado necesita supervisar y decidir excepciones. Mostrar todas las pantallas a todo el mundo no sustituye esos ejercicios por puesto.

Pide a cada persona que complete un caso sin indicaciones continuas y anota dónde duda. Corrige nombres, disposición o instrucciones antes de atribuirlo a falta de formación. El objetivo es que el flujo sea comprensible en el entorno donde se utiliza, con el ruido, la distancia y la carga propios del local.

Evalúa el arranque con hechos

Registra pedidos aceptados, completados y pendientes; incidencias por tipo; y tareas que todavía requieren intervención. No declares éxito solo porque el sistema abrió o una pantalla respondió. Comprueba que los pedidos llegaron a su final y que el equipo sabe continuar cuando aparece una excepción. Una incidencia resuelta durante el ensayo puede evitar un problema mayor en la primera franja real.

En Zestia, separa puesta en marcha operativa, condiciones comerciales y configuración fiscal aplicable. Una prueba técnica no equivale a aceptación fiscal ni autoriza por sí sola una activación en producción. La guía de qué pedir en una demo ayuda a dejar criterios de aceptación concretos. El viernes debería servir para trabajar con un recorrido conocido, no para descubrir por primera vez quién resuelve cada problema.

Preguntas habituales

¿Es mejor cambiar todo de golpe?

Depende del alcance, pero una prueba controlada permite detectar decisiones pendientes con menos confusión. Evita utilizar la primera hora punta como única prueba del sistema.

¿Quién debe aprobar el resultado?

Quien pueda representar cada parte del trabajo: atención, preparación, entrega y responsabilidad del negocio. La aceptación no debería depender solo de que una persona vea una demostración sin incidencias.