Reckitt es una de esas compañías que probablemente forman parte de su vida sin que usted piense demasiado en ella.
Detrás de marcas como Durex, Finish, Lysol, Dettol, Mucinex o Nurofen hay una operación global que depende de algo mucho menos glamuroso que una campaña de marketing o una gran innovación de producto: conseguir que el artículo correcto esté disponible, bien ubicado y correctamente promocionado en miles de tiendas.
En una empresa de consumo masivo, una decisión tomada en una oficina puede recorrer una larga distancia antes de convertirse en dinero.
Primero se decide qué producto impulsar, a qué precio, en qué mercado y con qué promoción. Luego esa decisión pasa por distribuidores, retailers, equipos comerciales y personal de merchandising. Finalmente llega al estante.
Es en ese último tramo donde una estrategia perfectamente razonable puede deshacerse.
Un producto puede figurar como disponible en inventario y no estar al alcance del comprador. Una promoción puede haber comenzado sin que el display correspondiente esté instalado. Una tienda puede recibir una visita comercial y, aun así, el tiempo disponible puede emplearse en tareas que tienen poco efecto sobre las ventas.
Reckitt conocía bien este problema.
La compañía ya había trabajado en mejorar la forma en que tomaba decisiones comerciales sobre precios, promociones y surtido. Pero una mejor planificación no resolvía por sí sola lo que ocurría dentro de cada tienda.
Ese fue el punto de partida de una colaboración con McKinsey que terminaría convirtiéndose en Smart Execution, un sistema apoyado en analítica avanzada e inteligencia artificial.
Lo interesante del caso no es que terminara utilizando IA.
Lo interesante es cómo llegaron hasta allí.
Una visita de cuarenta minutos
En Estados Unidos, Reckitt depende en buena medida de brokers y equipos de merchandising que visitan tiendas para comprobar que sus productos estén disponibles y correctamente ejecutados.
Una de esas visitas puede durar entre treinta minutos y una hora.
Durante ese tiempo pueden existir decenas de cosas que revisar: inventario, promociones, displays, ubicación de productos, cumplimiento de planogramas, precios o problemas específicos de determinados SKUs.
Visto como una lista de tareas, el problema parece sencillo: hay mucho trabajo y poco tiempo.
Visto como un problema de negocio, es bastante más interesante.
Cada visita cuesta dinero.
Cada minuto dentro de la tienda es un recurso escaso.
Por tanto, no todas las tareas tienen el mismo valor.
La pregunta importante deja de ser si el merchandiser hizo todo lo que tenía asignado. Pasa a ser si hizo aquello que podía producir el mayor efecto sobre el negocio.
Esa diferencia fue crucial.
Reckitt podía ver cuánto gastaba en ejecución en tiendas. Resultaba mucho más difícil saber cuánto valor producía cada visita, cada tarea o cada intervención.
Una reacción convencional ante un coste de ese tamaño habría sido intentar reducirlo.
Menos visitas. Menos personal. Menos gasto.
Pero esa no era necesariamente la mejor pregunta.
Había otra posibilidad: quizá el problema no era cuánto se invertía en ejecución, sino cómo se distribuía esa inversión.
El problema escondido dentro del problema
Cuando una empresa formula mal una pregunta, incluso una respuesta eficiente puede empeorar las cosas.
“¿Cómo reducimos el coste de merchandising?” lleva naturalmente a recortes.
“¿Cómo conseguimos que cada visita produzca más valor?” obliga a mirar el sistema de otra manera.
Para responder a la segunda pregunta había que saber qué tiendas merecían atención, qué productos tenían un problema y qué acción concreta podía modificar el resultado.
Reckitt tenía mucha de la información necesaria.
Datos de ventas.
Inventario.
Promociones.
Históricos.
Características de producto.
Planogramas.
Información procedente de retailers.
Resultados de visitas anteriores.
El problema no era que la empresa estuviera ciega.
Era que transformar toda esa información en una recomendación útil exigía demasiado tiempo.
Un analista podía investigar por qué un producto estaba vendiendo menos de lo esperado en una tienda determinada. Quizá descubriría que había inventario disponible, que una promoción estaba activa y que el producto debería estar en un display especial.
La conclusión podría ser sencilla: el producto probablemente estaba en la tienda, pero no donde debía estar.
Esa conclusión tiene valor porque produce una acción concreta.
Revise ese producto.
Compruebe ese display.
Corrija ese problema.
Pero hacer ese análisis para una tienda es muy diferente de hacerlo continuamente para miles de tiendas y miles de productos.
Ahí apareció el verdadero cuello de botella.
No faltaba inteligencia humana.
Faltaba escala.
Cuando una respuesta correcta llega demasiado tarde
Este detalle del caso merece atención.
Muchos de los análisis que terminaron automatizándose podían ser realizados por personas.
La dificultad era el tiempo.
Un análisis podía tardar días. Para cuando llegaba la conclusión, las condiciones en la tienda ya podían haber cambiado.
En operaciones, la calidad de una decisión no depende únicamente de que sea correcta.
También depende de cuándo llega.
Una recomendación excelente sobre un problema que ya desapareció tiene poco valor.
Vista de esta manera, Smart Execution no nació principalmente como un proyecto de inteligencia artificial. Nació como una forma de reducir la distancia entre una señal y una acción.
La tecnología empezó a evaluar de forma continua grandes cantidades de información y a convertirlas en prioridades más concretas para los equipos de campo.
En lugar de tratar todas las tiendas de la misma manera, podía señalar dónde había una oportunidad.
En lugar de presentar una lista extensa de tareas, podía reducirla a aquellas con mayor probabilidad de producir un impacto.
La IA no sustituyó necesariamente a la persona que visitaba la tienda.
Le quitó parte del trabajo más difícil: decidir, entre demasiadas posibilidades, dónde colocar su atención.
La productividad también consiste en elegir mejor
Hay una idea sencilla detrás de todo esto que suele perderse cuando hablamos de automatización.
Una persona puede trabajar más rápido y seguir haciendo las cosas equivocadas.
Un proceso puede digitalizarse por completo y continuar desperdiciando recursos.
Una compañía puede tener mejores dashboards y seguir tomando decisiones demasiado tarde.
He visto versiones más pequeñas de ese problema en proyectos de software: equipos que piden una nueva pantalla, una integración o un dashboard porque esa parece ser la solución natural, cuando el problema real está un paso antes o un paso después. A veces la información ya existe, pero nadie sabe qué decisión tomar con ella. O el proceso se automatiza sin cuestionar si tenía sentido conservarlo tal como estaba.
Ese tipo de situaciones me ha hecho desconfiar de las soluciones demasiado tempranas.
Digitalizar una ineficiencia sigue dejando una ineficiencia.
La productividad no consiste únicamente en hacer más.
También consiste en escoger mejor.
Ese fue uno de los cambios fundamentales en Reckitt.
La conversación dejó de estar centrada exclusivamente en cuánto costaba ejecutar en las tiendas y empezó a considerar cuánto crecimiento podía producir una mejor ejecución.
Es una transformación conceptual importante.
Un presupuesto que antes parecía un coste que debía controlarse puede empezar a verse como una inversión que debe optimizarse.
Y cuando cambia la pregunta económica, cambian también las decisiones que una empresa está dispuesta a tomar.
Lo que realmente hizo valiosa a la consultoría
El resultado tecnológico del caso es interesante, pero no creo que sea su parte más valiosa.
McKinsey no llegó simplemente con una herramienta para instalar.
El trabajo importante consistió en ayudar a conectar varios niveles del negocio que fácilmente podrían haberse tratado por separado: estrategia comercial, datos, trabajo de campo, comportamiento de las tiendas y retorno económico.
Eso requiere mirar una operación como un sistema.
Una mala ejecución en el estante no es simplemente un problema del merchandiser.
Puede ser consecuencia de una mala prioridad, información fragmentada, análisis demasiado lento o una forma incorrecta de medir el trabajo.
Y si se interviene únicamente en la última parte visible del problema, es posible mejorar el síntoma sin modificar la causa.
Esta es una de las razones por las que encuentro este tipo de proyectos más interesantes que el desarrollo de software por encargo.
El punto de partida no es una especificación.
Es una investigación.
¿Cómo funciona realmente la operación?
¿Dónde se pierde valor?
¿Qué decisiones se repiten?
¿Qué información utilizan las personas para tomarlas?
¿Qué información existe pero llega demasiado tarde?
¿Qué restricciones impiden mejorar el resultado?
En mi experiencia, cuanto antes se hace ese trabajo, mejor suele ser el resultado técnico. Muchos problemas de arquitectura, alcance y retrabajo aparecen porque el equipo empieza a construir antes de haber entendido bien qué parte del negocio necesita cambiar. La ingeniería puede ejecutar una mala hipótesis con una precisión extraordinaria.
Solo después tiene sentido decidir si la respuesta requiere software, integración, automatización, analítica o inteligencia artificial.
Una manera diferente de pensar la tecnología
Durante años, buena parte de la industria tecnológica se ha organizado alrededor de una pregunta bastante cómoda:
¿Qué quiere construir el cliente?
El cliente llega con una idea. El equipo calcula alcance, tiempo y coste. Después comienza el desarrollo.
Ese trabajo sigue siendo necesario.
Pero no siempre es donde se crea más valor.
Una compañía puede pedir exactamente el software equivocado para resolver un problema perfectamente real.
Puede solicitar una aplicación para digitalizar un proceso que debería rediseñarse.
Puede pedir un dashboard cuando lo que necesita es una decisión automática.
Puede pedir inteligencia artificial cuando su verdadero problema es la calidad de sus datos.
O puede asumir que necesita nueva tecnología cuando el cuello de botella es organizacional.
Por eso me interesa especialmente trabajar un paso antes de la solución.
Entender el negocio lo suficiente como para poder discutir qué debería cambiar antes de discutir qué debería construirse.
Mi formación está en tecnología, pero no veo la tecnología como el producto final de este tipo de trabajo.
La veo como una herramienta para modificar la economía de una operación.
Reducir tiempo.
Eliminar desperdicio.
Asignar mejor los recursos.
Aumentar capacidad.
Mejorar una decisión repetida miles de veces.
Convertir información dispersa en una acción útil.
El caso de Reckitt es un buen recordatorio de que algunos de los mejores proyectos tecnológicos no comienzan con una idea de software.
Comienzan cuando alguien observa un negocio con suficiente atención como para encontrar una pregunta mejor.
Fuente: McKinsey & Company — How AI-enabled execution became Reckitt’s tenfold game changer.
