Enamórate del problema, no de la solución
Cada SKU requiere decisiones diarias mundanas, como ingresar más stock o cambiar la etiqueta de precio subyacente. Naturalmente, adherirse a un proceso manual para esas decisiones es intensivo en mano de obra, y las empresas han estado adoptando variadas soluciones de automatización basadas en software. La estrategia de diseño más común para estas soluciones sigue siendo intentar replicar –a través del software– algo esencialmente similar a la práctica “humana” existente.
Este enfoque no es nuevo. Puede decirse que fue la perspectiva enfatizada por los sistemas expertos, que en su mayoría cayeron en desgracia durante el segundo invierno de la IA a finales de los 80 y principios de los 90. Sin embargo, aunque la palabra de moda sistemas expertos ya no se utiliza –no creo que exista algún proveedor de software (importante) que hoy en día se promocione como un proveedor de “sistemas expertos”– no puedo evitar notar que la perspectiva subyacente sigue siendo prevalente en la mayoría de los verticales.
De hecho, la mayoría de los proveedores de software, y también la mayoría de las iniciativas internas, siguen atrapados en la perspectiva de replicar la práctica existente, la cual surgió imitando el proceso completamente manual original. El antiguo sistema experto pudo haber sido reemplazado por un contraparte de algoritmo más moderno de deep learning, pero el paradigma de la visión global permanece (casi) intacto.
En supply chain, este patrón es sorprendente porque casi toda la práctica sigue basada en enfoques que surgieron en un mundo en el que las computadoras simplemente aún no existían. Por ejemplo, muchas –la mayoría– de las empresas aún distinguen el equipo de planificación, las personas que establecen el forecast de demanda para cada producto, del equipo de supply, las personas que emiten las órdenes de compra basándose en el forecast de demanda. Este enfoque surgió de una perspectiva taylorista en la que los empleados tenían que ser lo más especializados posible para rendir al máximo en su trabajo.
Sin embargo, cuando se trata de supply chain optimization, el taylorismo está en desacuerdo con la realidad de la supply chain. La realidad dicta que la future demand no es independiente de las decisiones presentes. Si se emite una orden de compra mucho mayor –generando un precio de compra unitario mucho más bajo– el precio de venta también se puede reducir, potencialmente superando al mercado, y así incrementando enormemente la demanda. En un mundo sin computadoras, el taylorismo era la opción de lo menos peor porque, aunque no era muy eficiente, era tremendamente escalable. Sin embargo, en un mundo con computadoras, la situación demanda un enfoque más integrado que tenga en cuenta, incluso de forma burda, tales retroacciones. Como dice el refrán, es mejor ser aproximadamente correcto que exactamente equivocado.
Al interrogar a clientes o prospectos sobre este asunto, la situación es frecuentemente incierta. Las soluciones –diseñadas originalmente para replicar un proceso puramente manual– han estado en vigor durante tanto tiempo, que la gente ha perdido de vista los aspectos más fundamentales del problema que intenta resolver. Con demasiada frecuencia, las personas se han convertido en especialistas de la solución existente, en lugar de convertirse en especialistas del problema que enfrenta la empresa. Así, al intentar mejorar la situación, todos los pensamientos están literalmente anclados en lo que se percibe como las fallas de la solución actual. Debido a este sesgo, los enfoques están revisitando el problema en profundidad y, por lo tanto, son percibidos como arriesgados tanto por la dirección como por sus equipos. Por el contrario, la opción de mejorar incrementalmente la solución existente se considera segura; o al menos, mucho más segura.
En retrospectiva, la historia del software empresarial está desafortunadamente llena de historias de proveedores que forzaron su “nueva forma” de hacer las cosas, la cual resultó ser mucho más tediosa y mucho más rígida que los procesos de antes; generando ganancias de productividad nulas o incluso negativas. Anecdóticamente, he observado que la mayoría de las empresas que operan grandes supply chain no han reducido sustancialmente su fuerza laboral de cuello blanco –que apoya sus supply chains– durante las últimas dos décadas, mientras que los trabajadores de cuello azul han sido agresivamente automatizados mediante mejores plantas o mejores warehouses.
Sin embargo, también noto que los supply chain executives usualmente subestiman en gran medida los riesgos asociados con cualquier software “inteligente” –es decir, cualquier software cuya corrección no pueda ser especificada de manera completa y concisa. De hecho, la mayoría del software empresarial no es más que aplicaciones CRUD, es decir, contables diligentes de listados mundanos tales como: facturas, proveedores, productos, pagos, etc.
Lograr el éxito empresarial con software “tonto” ya es bastante difícil –muchas ecommerce ya tienen problemas para mantener un buen tiempo de actividad en su frontend web–, pero cada vez que se involucran piezas de software quisquillosas, tales como componentes de machine learning, lograr el éxito se vuelve mucho más difícil. Pocas empresas comunican abiertamente sobre este asunto, pero cada vez que se involucra machine learning, los fracasos dominan el campo. Sin embargo, la situación no es tan desalentadora como podría parecer, porque las desventajas son limitadas, mientras que las ventajas no lo son.
Así, a la larga, las empresas que más intentan y fracasan son, irónicamente, las que más tienen éxito.
No obstante, los riesgos del software son muy reales, y ciertamente no tiene sentido aumentar esos riesgos aún más. Sin embargo, adherirse al paradigma de replicar una práctica manual hoy en desuso conlleva invariablemente una serie de complicaciones accidentales. Por ejemplo, dado que el equipo de planificación y el equipo de supply son distintos, surge una clase entera de problemas con el único propósito de mantener esos equipos sincronizados. Como regla general en el desarrollo de software, inflar los requerimientos en un 25% aumenta los costos en un 200%. La resolución de esas complicaciones aumenta drásticamente los costos, y en la práctica, el riesgo, ya que las empresas tienden a terminar –una reacción sensata– iniciativas que hacen explotar sus presupuestos o sus plazos.
Así, al enfrentarse a la cuestión centenaria de adaptar el software a la organización versus adaptar la organización al software, es prudente comenzar intelectualmente desde cero, y primero determinar cuáles son los problemas de alto nivel que deben ser resueltos. ¿Se mide el rendimiento en porcentajes? ¿O en dólares? ¿Estamos teniendo en cuenta correctamente las implicaciones a largo plazo? Tal como entrenar a los clientes para que solo compren durante la oferta. ¿El enfoque capitaliza las aportaciones humanas o meramente consume esas aportaciones? ¿La práctica está impulsada por hábitos o por una imperiosa necesidad? Tal como dos colecciones de moda al año, frente a dos cosechas al año.
El entendimiento íntimo del problema a resolver –que diferencia claramente el problema en sí de su solución actual– es la clave para determinar si la solución existente vale la pena conservarla, o si debe simplificarse conforme a las nuevas capacidades de software que requieren una resolución más simple y directa del problema.
