Domino's

Corrimos dos assessments independientes, cada uno con metodología propia y documentada capítulo por capítulo. El de IA empresarial arrancó con un cuestionario de descubrimiento extenso —cientos de preguntas organizadas en veinte secciones, desde ecosistema tecnológico y uso actual de IA hasta operación, atención al cliente, marketing y capacidad de adopción— seguido de cuatro fases: diagnóstico profundo (cruce de respuestas, validación de datos operativos contra la documentación real, modelado de madurez por dimensión, identificación de brechas), priorización (filtrado de oportunidades por impacto, factibilidad técnica y coherencia con la estrategia del negocio), y arquitectura y roadmap (diseño de la arquitectura de referencia y de un plan de implementación con hitos de decisión explícitos, no un cronograma optimista de una sola vía). Una regla no negociable atravesó todo el ejercicio: cuando una respuesta del cuestionario no fue proporcionada o quedó incompleta, el documento lo declara explícitamente como 'información no proporcionada' en vez de inferirla o inventarla — las recomendaciones se apoyan solo en lo verificable, y lo que depende de un dato faltante queda marcado como tal para refinarse después, no para maquillarse con un supuesto optimista. Cada hallazgo se validó además contra benchmarks públicos de la industria de restaurantes y contra la experiencia de ADM en despliegues análogos, no solo contra lo que el cliente reportó de sí mismo.

El de Web & Apps evaluó, con la misma exigencia metodológica, si construir una plataforma completamente nueva desde cero tenía sentido frente a optimizar la arquitectura actual — comparando ambos escenarios (y un tercero híbrido, explorado como alternativa conceptual) a través de cuatro dimensiones explícitas: financiera, operativa, de riesgos y estratégica, consolidadas al final en un solo marco de decisión ponderado. Antes de dar por buena cualquier conclusión, sometimos esa recomendación a análisis de sensibilidad y a casos extremos deliberados —¿qué pasa si la reconstrucción completa sale perfecta? ¿qué pasa si las condiciones actuales cambian significativamente?— para no quedarnos con la primera respuesta cómoda. Analizamos también, capa por capa —aplicación móvil, sitio web, backend y lógica de negocio, datos de usuario, y conocimiento y procesos internos—, qué tan atada está hoy la operación a la forma en que está construida actualmente, independientemente de qué camino se eligiera, porque esa dependencia real es la que determina qué tan costoso y qué tan riesgoso sería un cambio el día de mañana. La conclusión no fue la que nos hubiera generado más horas de trabajo a nosotros: recomendamos no reconstruir desde cero, sino un programa concreto de optimizaciones estructurales sobre lo que ya existe — formalizar acuerdos de nivel de servicio que hoy no existen, implementar un sistema de gestión de contenido para reducir la dependencia operativa del día a día, y fortalecer la gobernanza y visibilidad del canal digital. A veces la recomendación correcta no es construir algo nuevo — es arreglar, con evidencia, lo que ya existe.