Sahra-Josephine Hjorth

← Blog

IA en la práctica

Tu software debería quitarte trabajo. Este añadió 30 minutos a la semana.

Un cliente quería saber cuánta pintura suya quedaba en las estanterías de sus clientes. Una gran idea. La solución pedía a las tiendas que la contaran gratis cada semana, y ahí es donde van a morir los proyectos informáticos.

Sahra-Josephine Hjorth in an orange blouse and green earrings standing in a neighborhood paint store beside shelves of paint cans and color samples

Este texto es una traducción automática del inglés. Los matices pueden perderse, así que recomendamos leer el original. Leer el original en inglés

Donde van a morir los proyectos de software

Tengo un estudio de IA y, a través de él, trabajo en proyectos de IA para empresas de todo el mundo. En esta serie escribo sobre algunos de los mayores errores que he visto en proyectos de implantación de IA y software, para que puedas evitar cometerlos.

Uno de mis clientes, un fabricante de pintura¹, vende la mayor parte de su producción a través de pequeñas ferreterías independientes. Les hace las entregas siguiendo sus propias rutas, así que siempre sabía exactamente cuánta pintura había enviado a cada una. De lo que no tenía ni idea era de lo que pasaba después: cuánto se había vendido y cuánto seguía en la estantería. Son tiendas pequeñas, a menudo negocios familiares, y es habitual que una misma persona sea propietaria de varias. La empresa partía del supuesto de que eran demasiado pequeñas para utilizar algún tipo de sistema: las ventas se apuntarían a mano o se registrarían en una caja registradora sencilla que no controlaba las existencias. Si eso era cierto, el único registro de lo que quedaba era la propia estantería, y las únicas personas que la veían todos los días eran los propietarios y el personal del mostrador.

La empresa necesitaba desesperadamente ese dato, y no solo para organizar mejor sus rutas de reparto. Sin él, lo planificaba todo a partir de los pedidos de las tiendas, y los pedidos son una versión tardía y distorsionada de lo que realmente compran los clientes. Una tienda que se quedó sin existencias la semana pasada pide el doble esta semana. Otra que tiene demasiado producto no pide nada durante un mes. La fábrica interpreta ambos casos como cambios reales en la demanda. Produce demasiado de unos colores y demasiado poco de otros, compra materias primas basándose en previsiones equivocadas y acaba con pedidos pendientes precisamente de los productos que la gente quiere.

Cada uno de esos errores cuesta dinero: tiradas de producción urgentes para ponerse al día, viajes de reparto adicionales a las tiendas que se han quedado sin producto y pintura acumulada en un almacén porque nadie la quiere. Cada hueco en la estantería es también una venta perdida, porque quien entra a comprar pintura para el fin de semana no espera a tu próxima entrega. Compra otra marca.

Los investigadores de las cadenas de suministro tienen un nombre para el fenómeno por el que pequeños cambios en la estantería se convierten en grandes oscilaciones en la fábrica: el efecto látigo, descrito por Hau Lee, V. Padmanabhan y Seungjin Whang en MIT Sloan Management Review en 1997. Saber qué queda en el punto de venta es la forma de amortiguar ese efecto.

Recuadro informativo: el efecto látigo

Cuando haces restallar un látigo, un pequeño movimiento de muñeca se convierte en una gran oscilación en la punta. En las cadenas de suministro ocurre lo mismo con la demanda. Cada eslabón de la cadena, desde la tienda hasta el distribuidor, la fábrica y los propios proveedores de la fábrica, solo ve los pedidos que recibe del eslabón siguiente, no lo que compran realmente los clientes. Así que cada uno añade un poco de stock por precaución, hace pedidos en lotes más grandes y reacciona de forma exagerada ante una subida o una bajada repentina. Cuando la señal llega a la fábrica, un pequeño cambio en la estantería se ha convertido en una gran oscilación en la producción.

Hau Lee, V. Padmanabhan y Seungjin Whang popularizaron el término en 1997. Su ejemplo más conocido procedía de Procter & Gamble, que observó fuertes altibajos en los pedidos de pañales Pampers, pese a que los bebés los consumen a un ritmo notablemente estable. Cuanto más atrás en la cadena miraba P&G, mayores eran las oscilaciones.

El remedio habitual es la visibilidad. Cuando todos los eslabones de la cadena pueden ver qué se vende realmente en el punto de venta, dejan de hacer conjeturas a partir de los pedidos.

Figura 1

Dos botes más vendidos en la tienda se convirtieron en veinte más fabricados

Cómo interpretar la figura. Cada fila es un eslabón de la cadena, y cada cifra indica los botes de un color de mucha venta correspondientes a una sola tienda a lo largo de tres semanas. Los clientes compraron solo dos botes más de lo habitual durante una semana. La tienda solo ve lo que se ha vendido, así que repuso la estantería y añadió una caja entera por precaución. La fábrica solo ve el pedido de la tienda, así que lo interpretó como un aumento de la demanda e incrementó la producción. La semana siguiente, los clientes volvieron a sus diez botes habituales, la tienda tenía suficientes y no pidió nada, y la fábrica se quedó con pintura que nadie había encargado. Las cifras son ilustrativas, no son datos de mi cliente.

Este patrón se conoce como efecto látigo. Fuente: Hau L. Lee, V. Padmanabhan y Seungjin Whang, "The Bullwhip Effect in Supply Chains," MIT Sloan Management Review, 1997.

Para resolver el problema, mi cliente recurrió a las únicas personas que podían ver las estanterías todos los días: sus distribuidores, las propias tiendas. La idea parecía sencilla. Si cada tienda le comunicaba una vez a la semana lo que le quedaba, la empresa podía ocuparse del resto. Pero lo que quedaba en una tienda nunca era una sola cifra. Una ferretería vende la pintura de la empresa en decenas de colores, varios acabados y distintos tamaños de envase, junto a las imprimaciones, los disolventes, las brochas y los rodillos que la acompañan. En el sector, cada una de esas variantes es un SKU distinto, siglas de stock keeping unit, o unidad de mantenimiento de existencias: cada color, en cada acabado y en cada tamaño de envase, cuenta como un artículo diferente. Informar de las existencias significaba contar todos los SKU de la estantería, uno por uno.

Así que el proyecto no tardó en complicarse. Había un enlace a una aplicación y una hoja de cálculo que el personal de las tiendas debía descargar, rellenar SKU por SKU y devolver. Al cabo de un tiempo, la empresa también les pidió que añadieran los precios que cobraban. La mayoría de las tiendas nunca la rellenó, y algunas lo hicieron al azar solo para quitársela de encima. Cuando eso no funcionó, alguien de atención al cliente empezó a llamar a las tiendas cada semana para preguntar por sus existencias, categoría por categoría. En muchas tiendas, un recuento riguroso llevaba treinta minutos o más, y la persona al otro lado del teléfono a menudo tenía clientes esperando. Era difícil fiarse de las cifras recibidas, y el proyecto se canceló antes de llegar a implantarse por completo.

Empecé a trabajar con la empresa después de aquello, y mi consejo fue mantener el objetivo y abandonar el método. Saber qué queda en las estanterías de tus clientes tiene un valor real. Pero aquella solución estaba condenada desde el primer día, porque pedía a personas que no iban a obtener nada de esos datos que dedicaran media hora cada semana a generarlos para otro. Ahí es donde van a morir los proyectos informáticos.

La aplicación se convirtió en el objetivo y el problema cayó en el olvido

Sobre el papel, el plan de la empresa parecía bueno. Describía una aplicación sencilla con la que las tiendas comunicarían sus existencias, tan fácil de usar que nadie necesitaría formación ni un manual. Pero, como tantas otras empresas antes, mi cliente olvidó que la tecnología es un medio. El software, los datos y la IA son herramientas para resolver un problema. No son el objetivo. En algún momento, la aplicación se convirtió en el proyecto, y toda la energía se volcó en construir la herramienta en vez de resolver el problema para el que estaba pensada, lo que exigía comprender a las personas, los recursos y los incentivos necesarios para que el trabajo se hiciera de verdad.

El propio plan lo deja ver. Enumeraba las condiciones de las que dependía el éxito del proyecto, y la primera era que la empresa idearía algún tipo de recompensa para conseguir que las tiendas informaran cada semana. Justo al lado había una nota que decía que quizá la dirección tendría que replantearse cómo recompensaba a las tiendas por compartir información. La pregunta más importante de todo el proyecto, por qué alguien de una tienda se tomaría la molestia, quedó aparcada como un supuesto que alguien resolvería más adelante. Nadie lo hizo.

Y ese era el verdadero problema. Las personas de las tiendas no tenían ningún incentivo para asumir ese problema junto con la empresa. Los beneficios eran para el fabricante y el trabajo, para ellas. Además, las tiendas no están casadas con la pintura de mi cliente. Venden muchas otras marcas justo al lado, así que, si se acaban sus botes, el comprador simplemente elige otra marca de la misma estantería y la tienda vende igualmente. Una estantería medio vacía es un problema del fabricante, no de la tienda. Este es uno de los errores que veo con más frecuencia: las empresas confunden sencillo con gratis. Una aplicación preciosa sigue requiriendo tiempo para usarla, y treinta minutos de recuento fácil siguen siendo treinta minutos que le quitas a alguien con clientes esperando y una tienda que atender. Puedes facilitar una tarea, pero no puedes hacer que a alguien le importe una tarea que solo te beneficia a ti.

Casi ninguna tienda contó sus existencias, y los recuentos recibidos no eran fiables

Ante una petición de datos que no les aporta nada, las personas hacen una de dos cosas. La ignoran, y te quedas con lagunas. O la rellenan de la manera más rápida posible, y te quedas con datos ficticios. Lo segundo es mucho peor. Un panel vacío te dice que no sabes. Un panel lleno de recuentos inventados te dice que sí sabes, y entonces planificas tus rutas y tu producción sobre una ficción.

Esto no ocurre solo en las tiendas pequeñas. En una encuesta de Validity de 2024, una empresa que vende herramientas de calidad de datos, más de la mitad de los encuestados de empresas que dependen de los datos dijeron que su personal manipula los registros de clientes del CRM para decirles a los responsables lo que quieren oír, y el 45 por ciento afirmó que el personal simplemente se inventa los datos. Los médicos conviven con lo mismo. Un estudio de 2016 concluyó que, por cada hora que los médicos dedican a los pacientes, pasan casi otras dos con registros electrónicos y tareas de escritorio, y cuando los investigadores de Penn Medicine analizaron más de 100 millones de notas clínicas, aproximadamente la mitad del texto se había duplicado a partir de notas anteriores. Cuando un sistema exige texto, la gente le da texto.

Y los médicos y los comerciales son empleados. Cobran por rellenar esos sistemas y, aun así, los datos se deterioran. Las personas que atendían el mostrador de aquellas tiendas ni siquiera trabajaban para la empresa. Trabajaban para sus clientes. La empresa no tenía autoridad para obligarlas a contar, y ellas tenían motivos de sobra para no hacerlo.

Las cerveceras resolvieron el mismo problema facilitando los pedidos a las tiendas

Las empresas que han dado con la solución no pidieron trabajo adicional. Encontraron algo que el comerciante ya quería hacer e integraron ahí la recogida de datos. La cervecera AB InBev creó una aplicación de pedidos para pequeños comercios llamada BEES. En vez de esperar a que pase un comercial, los propietarios pueden consultar todo el catálogo y los precios, elegir el día de entrega, acumular recompensas y acceder a condiciones de crédito más claras. AB InBev comunica ahora que tiene más de seis millones de clientes en la plataforma y que el 72 por ciento de sus ingresos procede de sus plataformas digitales B2B, y explicó a los inversores en 2023 que, de pronto, disponía de datos que nunca había tenido. Nadie tuvo que suplicar a los comerciantes que se los dieran. Hacían pedidos porque pedir era más fácil.

Mi cliente no puede limitarse a copiar BEES. La cerveza se repone cada semana, y la cervecera suele ser el proveedor más importante de una tienda. La pintura es una línea de productos entre miles en una ferretería, y ninguna tienda va a instalar una aplicación por cada marca que tiene en las estanterías. Lo que sí se puede trasladar es el principio: captar los datos en un momento en el que las personas ya están haciendo algo por sus propios motivos.

Las tiendas ya tenían cajas registradoras y algunas disponían de un sistema de la competencia

En el caso de mi cliente, la respuesta estaba más cerca de lo que nadie imaginaba. Cuestioné el supuesto de que las tiendas no tenían ningún sistema. Mi sugerencia, inspirada en otro de mis clientes, fue darles algo que realmente quisieran: una aplicación sencilla de inventario, o una tableta, que llevara el control de todas las existencias de la tienda, de todas las marcas de todas las estanterías, no solo de la pintura de mi cliente.

Así, la tienda obtiene una herramienta que la ayuda a gestionar su negocio. Mi cliente obtiene una visión de toda la transacción, incluido qué se vende cuando no se vende su propia pintura. Después fuimos a visitar las tiendas. Todas y cada una tenían caja registradora, y algunas ya disponían de un sistema de inventario proporcionado por un competidor de mi cliente. La transacción ya se estaba registrando. Simplemente no se estaba registrando para mi cliente. Lo que eso revela sobre lo mucho que una empresa puede alejarse de sus propios clientes merece un artículo aparte, y volveré a ello en la próxima entrega de esta serie.

Figura 2

La venta ya se registraba, solo que no para mi cliente

Lo registra mi clienteFábricaSabe exactamente qué ha producido
Lo registra mi clienteEntregaSabe exactamente qué ha enviado a cada tienda
No lo registra nadieLa estanteríaLo que se pedía a las tiendas que contaran a mano cada semana
Lo registra la tiendaLa caja registradoraCada venta, cada día, y en algunas tiendas mediante un sistema proporcionado por un competidor de mi cliente

Cómo interpretar la figura. Sigue un bote de pintura desde la fábrica hasta el comprador. Los sistemas de mi cliente registran las dos primeras etapas. La tercera, la estantería, es la laguna que intentó cubrir pidiendo a las tiendas que contaran. La cuarta ya registra cada venta en todas las tiendas que visitamos.

La empresa probó una aplicación, una hoja de cálculo y llamadas telefónicas, pero nunca ofreció nada a las tiendas

Para ser justos, la empresa lo intentó. Pasó de una aplicación a una hoja de cálculo y después a las llamadas telefónicas, y cada versión fue un intento sincero de facilitar lo que pedía. Todas fracasaron, y pararon antes de completar la implantación.

Figura 3

La forma de pedirlo cambió tres veces. El trato nunca cambió.

PrimeroLa aplicaciónUn enlace a una aplicación sencilla en la que las tiendas debían comunicar sus existencias
La tienda aporta30 minutos o más a la semana, contando cada SKU
La tienda recibeNada
DespuésLa hoja de cálculoDescargarla, contar las existencias de la estantería SKU por SKU, introducir las cifras y los precios y devolverla
La tienda aporta30 minutos o más a la semana, contando cada SKU
La tienda recibeNada
Por últimoLas llamadas telefónicasAtención al cliente llama a cada tienda, cada semana, para preguntar por las existencias categoría por categoría
La tienda aporta30 minutos o más a la semana, contando cada SKU
La tienda recibeNada

Cómo interpretar la figura. Cada columna representa una forma en que mi cliente pidió a las tiendas que comunicaran sus existencias, en el orden en que las probó. La parte superior de cada columna cambia. La inferior, lo que la tienda tenía que aportar y lo que recibía a cambio, permanece exactamente igual.

Lo que nunca cambió fue el trato. En todas las versiones, la tienda dedicaba treinta minutos y no recibía nada a cambio. La empresa probó cómo preguntar y nunca probó por qué alguien respondería. Esa prueba habría salido prácticamente gratis. Visitar diez tiendas, mirar qué hay junto a la caja y preguntar a quienes atienden el mostrador qué querrían a cambio de contar la pintura cada semana. La mayoría se habría echado a reír, y algunos habrían señalado el sistema que ya tenían.

Había un posible acuerdo, al menos en teoría. Mi cliente podría haber ofrecido a las tiendas una participación en los ingresos: devolverles un pequeño porcentaje por cada bote vendido si comunicaban sus existencias cada semana. Eso habría dado a las personas del mostrador un motivo para contar. El proyecto no ofrecía nada a las tiendas, así que no recibió nada a cambio. Pero no creo que pagar por los recuentos fuera nunca la mejor respuesta. La pregunta más útil era dónde se estaba registrando ya la transacción.

El verdadero coste no es solo un proyecto fallido. Cuando una solución fracasa de forma tan visible, el objetivo suele quedar enterrado con ella. Después de que el último intento se estrelle, nadie quiere ser quien vuelva a proponer recoger datos de las estanterías, aunque la idea fuera acertada desde el principio.

Pagar una cantidad por cada recuento habría supuesto poner en marcha un segundo negocio

La objeción evidente es: bien, pues paga a las tiendas. A veces funciona. Las empresas de investigación de mercados llevan décadas pagando a hogares para que escaneen lo que compran, y NielsenIQ amplió su panel del Reino Unido a 30.000 hogares en 2024. Pero fíjate en lo que requiere. Captar participantes, diseñar las recompensas, comprobar los datos y expulsar a quienes hacen trampas constituye todo un negocio. Una empresa de pintura que empieza a pagar por recuentos de existencias ha puesto en marcha una segunda empresa sin darse cuenta.

También ha creado un motivo para hacer trampas. El científico social Donald Campbell advirtió en la década de 1970 que, cuanto más se utiliza una cifra para tomar decisiones, mayor es la presión para manipularla, una idea que hoy se conoce como la ley de Campbell. Su ejemplo eran los recuentos militares de enemigos muertos. Paga a una tienda por cada recuento y obtendrás recuentos. Que tengan algo que ver con la estantería es otra cuestión. Por eso funciona mejor una participación en los ingresos que una cantidad fija. Una cantidad fija recompensa el envío de una cifra, mientras que una participación en las ventas recompensa que esa cifra sea cierta.

Mi cliente construyó una herramienta cuando lo que necesitaba eran datos del punto de venta

Visto en retrospectiva, mi cliente cometió cuatro errores, y ninguno era técnico.

  1. Puso la tecnología en el centro. En cuanto se planteó el problema, la conversación pasó a qué herramienta construir: una aplicación, un enlace, una hoja de cálculo. Nadie se detuvo a preguntar qué utilizaban ya las tiendas, qué necesitaban o qué iban a sacar de aquello.
  2. Se quedó atascado en el proceso. Cada vez que las tiendas no informaban, la empresa cambiaba la forma de pedirlo, de la aplicación a la hoja de cálculo y de ahí a las llamadas, en vez de cuestionarse si debía pedirlo siquiera.
  3. Nunca consiguió implicar a las personas de las que dependía. Todo el proyecto se apoyaba en que el personal de las tiendas hiciera trabajo adicional cada semana, pero nadie fue a visitarlo, le preguntó ni le ofreció nada. No tenía ningún motivo para asumir el problema junto con la empresa, y no lo hizo.
  4. Confundió una herramienta con el proyecto. El proyecto nunca consistió en implantar una aplicación o una función de IA. Consistía en obtener datos fiables del punto de venta. Visto así, la pregunta deja de ser cómo conseguir que las tiendas utilicen tu aplicación y pasa a ser dónde se registra ya esa información, y la respuesta estuvo junto a la caja todo el tiempo.

Al principio, la estantería parecía algo que solo podían ver las personas de la tienda, y todo el plan dependía de convencerlas de que contaran su contenido para la empresa. Pero la estantería nunca fue el único registro. Cada bote que salía de ella pasaba por una caja registradora y, en algunas tiendas, por un sistema que había instalado un competidor de mi cliente. La información se registraba todos los días. Mi cliente simplemente nunca salió a comprobarlo. Nadie en aquella tienda había aceptado contar para ti, y un buen software nunca se lo habría pedido.

¹ Todas las historias de esta serie son reales. Para proteger a mis clientes, cambio los detalles que podrían identificarlos, como el sector, los productos, el tamaño y la ubicación de la empresa, y los nombres de las personas y los proveedores. Lo que ocurrió, las decisiones que se tomaron y los motivos por los que salieron mal se mantienen tal como fueron.

Fuentes

Enlace a este ensayo
Sígueme