Lo que sigue es la reconstrucción de un proceso de implementación real. Los nombres de la empresa y sus clientes son ficticios por acuerdo de confidencialidad, pero los números, los obstáculos y las decisiones son los que efectivamente ocurrieron.
El punto de partida
La empresa: operador de catering corporativo con 45 empleados, tres sedes en el área metropolitana de Buenos Aires (Microcentro, Palermo y Zona Norte), y contratos con 11 empresas cliente que suman alrededor de 1.800 almuerzos diarios.
El problema: cada sede operaba con sus propios criterios. Una usaba planillas de Excel para la planificación; otra tenía un sistema legacy que el encargado había construido en Access hacía ocho años; la tercera, la más nueva, directamente coordinaba por WhatsApp y anotaciones en papel. No había visibilidad cruzada entre sedes. El dueño recibía información de cada sede por separado, en formatos distintos, con datos que a veces no cuadraban entre sí.
Los síntomas concretos que motivaron el cambio:
- Tres o cuatro veces por semana, una sede quedaba sin insumos porque la compra no había contemplado un evento de último momento en otra sede.
- Los reclamos de clientes tardaban entre 24 y 72 horas en llegar al responsable correcto porque no había un canal centralizado.
- Cerrar el mes administrativo llevaba cuatro días de trabajo de la persona de administración para consolidar datos de las tres sedes.
La decisión de implementar
La empresa ya había evaluado herramientas antes. El obstáculo habitual era el mismo: "no podemos parar la operación para implementar un sistema". Con tres sedes, turnos partidos y contratos que penalizan demoras, ese miedo es razonable.
La decisión de avanzar se tomó después de cuantificar el costo del statu quo: los cuatro días de cierre administrativo mensual representaban tiempo de un recurso senior. Los reclamos sin canal centralizado tenían un costo estimado en retención de clientes. Los faltantes de insumos generaban compras de emergencia con sobreprecios.
El objetivo declarado: tener las tres sedes operando en el mismo sistema, con los mismos criterios de carga, en 45 días. Sin interrumpir el servicio.
La implementación semana a semana
Semana 1: Diagnóstico y definición del catálogo
El primer trabajo fue un inventario de los datos existentes en los tres sistemas. El resultado fue predecible: el mismo plato tenía tres nombres distintos según la sede, los mismos proveedores estaban cargados con datos de contacto diferentes, y los códigos de clientes no existían como concepto unificado.
Se dedicaron los primeros cinco días a construir el catálogo maestro unificado: un listado de todos los platos con nomenclatura estándar, un directorio de proveedores consolidado, y un esquema de códigos para los clientes. Esta etapa tomó más tiempo del previsto porque requirió decisiones que nadie había tomado antes: "¿cómo se llama oficialmente este plato?", "¿cuál de los dos contactos del proveedor es el correcto?".
Aprendizaje clave: no subestimar el tiempo de la etapa de datos maestros. Es aburrida y parece burocrática, pero es la que define si la implementación funciona o no.
Semana 2: Configuración y capacitación de la sede piloto
Se eligió la sede de Palermo como piloto por dos razones: era la más estructurada operativamente y tenía el encargado más dispuesto a adoptar herramientas nuevas.
La configuración tomó dos días. La capacitación fue de tres sesiones de una hora cada una, en distintos momentos del día para cubrir los turnos. Se capacitó solo lo necesario para operar: carga de pedidos, registro de producción y consulta de stock. No se capacitó en reportes ni en funciones avanzadas todavía.
Al final de la semana, Palermo operaba en el sistema nuevo en paralelo con sus registros anteriores.
Semana 3: Ajustes en la sede piloto y preparación de las otras dos
Durante la tercera semana, la sede piloto encontró los problemas esperados: algunas presentaciones de platos no estaban cargadas, el flujo de aprobación de pedidos tenía un paso que no tenía sentido para su operación, y un proveedor clave no estaba en el sistema porque había sido omitido en el inventario inicial.
Todos estos problemas se corrigieron antes de extender el sistema a las otras sedes. Ese es exactamente el valor del piloto: fallar en pequeño antes de fallar en grande.
Al mismo tiempo, se preparó la configuración específica de las sedes de Microcentro y Zona Norte, con las particularidades de cada una (distintos horarios de entrega, distintos esquemas de turnos).
Semana 4: Incorporación de Microcentro
La incorporación de Microcentro fue más rápida porque los problemas del catálogo ya estaban resueltos. El mayor obstáculo fue la resistencia del encargado, que llevaba ocho años con su sistema en Access y lo conocía de memoria.
La solución no fue técnica: fue mostrarle que el nuevo sistema podía generar en 30 segundos el reporte que a él le llevaba 45 minutos de consultas en su sistema. Esa demostración cambió la actitud.
Aprendizaje clave: en implementaciones con personal de larga trayectoria, el argumento más efectivo no es "el sistema es mejor" sino "te va a ahorrar este tiempo específico en esta tarea específica".
Semana 5: Incorporación de Zona Norte y primera semana de operación unificada
La sede de Zona Norte era la más caótica en términos de datos previos. No había casi nada que migrar: todo se reconstruyó desde cero en el sistema nuevo.
Al final de la semana 5, las tres sedes estaban operando en el mismo sistema. Todavía en paralelo con sus registros anteriores, pero ya con el sistema nuevo como referencia principal.
Semana 6 y primer cierre de mes
La semana 6 fue la de validación: comparar los datos del sistema nuevo con los registros anteriores de cada sede. Los desvíos encontrados fueron menores (menos del 3 % en todas las métricas) y todos tenían explicación conocida.
El primer cierre mensual con el sistema unificado tomó medio día, en lugar de los cuatro días anteriores.
Los resultados a 45 días
- Tiempo de cierre mensual: de 4 días a 6 horas.
- Reclamos sin resolver a las 24 horas: de un promedio de 3-4 semanales a menos de 1.
- Compras de emergencia por faltante de insumos: de 3-4 por semana a menos de 1 por mes.
- Visibilidad del dueño: por primera vez, podía ver el estado de las tres sedes en tiempo real desde una sola pantalla.
Lo que habría hecho diferente
Consultado al cierre de la implementación, el responsable del proyecto identificó tres cosas que cambiaría:
- Empezar la limpieza de datos maestros dos semanas antes: fue el cuello de botella que más tiempo tomó y que más dependía de decisiones humanas, no de configuración técnica.
- Capacitar a los encargados antes de que el sistema estuviera configurado: la curva de aprendizaje del flujo operativo se puede trabajar antes con demostraciones en un entorno de prueba.
- Definir desde el día 1 qué reportes necesitaba cada perfil: algunos reportes que se configuraron tarde habían sido pedidos desde el principio pero nadie los había especificado con claridad.
La lección central
Estandarizar procesos en múltiples sedes no es un proyecto de tecnología. Es un proyecto de toma de decisiones: cómo se llaman las cosas, quién puede cambiar qué, qué pasa cuando hay un faltante, cómo se escala un reclamo. La tecnología implementa esas decisiones, pero no puede tomarlas. Los equipos que llegan a la implementación con esas decisiones ya tomadas terminan en la mitad del tiempo y con la mitad de los problemas.