Cuando el Servicio Necesitó un Precio

La empresa operaba una cadena de suministro distribuida y compleja que conectaba demanda, planificación, suministro, plataformas, transporte y puntos finales de servicio. El modelo operativo se había mejorado en un ciclo de transformación anterior, pero el nuevo contexto exigía revisar más a fondo si su estructura organizativa, sus rutinas de planificación, su capa analítica y sus derechos de decisión seguían siendo aptos para el nivel de complejidad que se avecinaba.

La pregunta de liderazgo no era simplemente cómo optimizar la logística. Era si la organización podía seguir protegiendo el servicio haciendo visible el coste, el dueño y la consecuencia de cada decisión, lo suficiente como para aprender de ella. El Diagnosis se convirtió en el punto de partida de un ejercicio más amplio de definición del modelo, centrado en la arquitectura de decisión, el gobierno del dato, la planificación y la gestión operativa.

Surfingvest trabajó como socio de ejecución estratégica dentro de un equipo de entrega más amplio, con un papel central en la estructuración del diagnóstico, el análisis operativo, la síntesis de hallazgos y la definición de una arquitectura de decisión para una operación distribuida y compleja.

La empresa ya había pasado por una transformación organizativa importante años antes. Aquel esfuerzo había mejorado el modelo operativo y había ayudado al negocio a capturar buena parte de las ganancias de eficiencia más inmediatas. Pero el sistema entraba ahora en una fase distinta. El entorno era más incierto, la capacidad operativa era más difícil de ajustar y el coste de proteger el servicio empezaba a ser difícil de absorber sin más disciplina analítica.

El Diagnosis reveló una operación madura, con equipos comprometidos, una cultura de colaboración sólida y una gran capacidad para mantener el servicio en marcha. El problema no era falta de profesionalidad. El problema era que el modelo dependía cada vez más de la coordinación, la negociación informal y el esfuerzo humano para absorber la complejidad. Las responsabilidades estaban demasiado repartidas, algunos departamentos actuaban como bisagras entre otros, y la organización no siempre tenía una forma compartida de decidir quién era dueño de un trade-off, qué costaba y cuándo debía escalarse.

El hallazgo central no fue que el servicio fuera la estrategia equivocada. El servicio puede ser la elección estratégica correcta. Pero el servicio a cualquier coste solo funciona cuando la organización conoce ese coste. El trabajo se centró por tanto en hacer el sistema de decisión más explícito: KPIs compartidos, una fuente única de verdad, umbrales, reglas de escalado, modelos económicos, una lógica de Control Tower y rutinas de planificación capaces de conectar la ambición del negocio con la capacidad operativa.

El proyecto avanzó más allá del diagnóstico hacia la definición del modelo. En lugar de proponer un rediseño ideal que la organización quizá no pudiera absorber, el equipo trabajó desde las restricciones reales del negocio y definió un camino práctico: modelo organizativo, arquitectura de decisión basada en datos y modelo de gestión operativa. El resultado fue un plano operativo estructurado para la toma de decisiones, la planificación y la ejecución, no una afirmación de implementación completada ni de impacto financiero medido.

Momentum: años antes, la empresa había hecho un esfuerzo importante por transformar y optimizar una parte considerable de su modelo operativo. Aquel trabajo había generado progreso, pero el contexto había cambiado. La nueva pregunta de liderazgo era si la estructura vigente seguía siendo la mejor forma de organizar, planificar y decidir.

El Diagnosis se puso en marcha para entender el modelo operativo real, identificar las fricciones estructurales detrás de las tensiones diarias y definir si la siguiente fase requería una nueva capa organizativa, un nuevo sistema de decisión o simplemente más disciplina de ejecución. El trabajo avanzó después hacia la definición del modelo, donde se evaluaron distintos modelos operativos según su encaje cultural, su madurez analítica y su viabilidad organizativa.

Realidad operativa: la operación conectaba demanda, planificación, suministro, plataformas, transporte y puntos de servicio. Cada área entendía su propia realidad y asumía parte de la presión operativa. Pero el sistema no siempre partía de una única versión aceptada de la verdad, un lenguaje de KPI compartido o un protocolo claro para decidir cuándo un problema debía absorberse, automatizarse, escalarse o rediseñarse.

El modelo operativo tenía fortaleza cultural y capacidad técnica, pero la capa analítica y de gobernanza necesitaba pasar a un primer plano. Los datos no podían seguir siendo una capa de reporting. Tenían que convertirse en la capa a través de la cual la organización decidía.

Lectura del diagnóstico: el diagnóstico mostró una organización capaz y comprometida cuyo modelo dependía cada vez más de la coordinación humana, la negociación informal y la resolución reactiva de problemas. El problema principal no era la capacidad operativa. Era la ausencia de una arquitectura de decisión suficientemente explícita.

La empresa no necesitaba preocuparse menos por el servicio. Necesitaba entender qué costaba cada decisión de servicio, quién era dueño del trade-off y cómo debía aprender el sistema de cada excepción.

Camino de acción: el camino recomendado se centró en construir la capa operativa que le faltaba a la organización.

1. Definir un modelo organizativo más claro en torno al control, la optimización y la gobernanza cross-funcional.

2. Construir una lógica de Control Tower capaz de conectar planificación, ejecución, incidencias, reporting y aprendizaje.

3. Establecer KPIs, umbrales y reglas de escalado compartidos para que las decisiones pudieran tomarse más rápido y con menos ambigüedad.

4. Crear modelos económicos que permitieran traducir servicio, capacidad, desviaciones de previsión, roturas de stock, mermas y penalizaciones de proveedores en impacto financiero.

5. Rediseñar rutinas de planificación, estructuras RACI y sesiones operativas para que la organización pudiera pasar de la coordinación reactiva a la ejecución gobernada.

6. Tratar el modelo como progresivo: primero visibilidad y control, después predicción, y por último automatización y soporte prescriptivo a la decisión.

Qué cambió: el trabajo no se detuvo en identificar fricciones. Las tradujo en opciones de modelo y después en una arquitectura operativa más práctica.

El encargo pasó del Diagnosis a la definición del modelo. Aclaró la necesidad de un rol de Control y Optimización, una lógica de Control Tower, estructuras RACI más claras, protocolos de planificación, umbrales de KPI, modelos económicos y una hoja de ruta hacia una gestión operativa más basada en datos.

El proyecto replanteó el reto: de la optimización logística a la arquitectura de decisión. La pregunta ya no era solo cómo mejorar la cadena de suministro. Pasó a ser cómo debía decidir la organización cuando servicio, coste, capacidad y responsabilidad entraban en colisión.