Enamórate del problema, no de la solución
Cada SKU requiere decisiones diarias mundanas, como mover más stock o cambiar el precio subyacente. Naturalmente, seguir un proceso completamente manual para esas decisiones es laborioso, y las empresas han estado adoptando diversas 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 que esencialmente es similar a la práctica “humana” existente.
Este enfoque no es nuevo. Se podría argumentar 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 fines de la década de 1980 y principios de la década de 1990. Sin embargo, aunque la palabra de moda sistemas expertos ya no existe, no creo que haya ningún proveedor de software (significativo) que todavía se autodenomine proveedor de “sistemas expertos” en la actualidad, no puedo evitar notar que la perspectiva subyacente sigue siendo prevalente en la mayoría de los sectores.
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, que a su vez surgió imitando el proceso manual original. El antiguo sistema experto puede haber sido reemplazado por un algoritmo de deep learning más moderno, pero el paradigma general permanece (casi) intacto.
En la cadena de suministro, este patrón es llamativo porque casi toda la práctica sigue atrapada en enfoques que surgieron en un mundo donde simplemente no existían las computadoras. Por ejemplo, muchas, si no la mayoría, de las empresas aún distinguen al equipo de planificación, las personas que establecen el pronóstico de demanda para cada producto, del equipo de suministro, las personas que realizan los pedidos de compra en función del pronóstico de demanda. Este enfoque surgió de una perspectiva taylorista donde los empleados debían ser lo más especializados posible para ser lo más eficientes posible en su trabajo.
Sin embargo, cuando se trata de optimización de la cadena de suministro, el taylorismo está en desacuerdo con la realidad de la cadena de suministro. La realidad dicta que la demanda futura no es independiente de las decisiones presentes. Si se realiza un pedido de compra mucho más grande, lo que conduce a un precio de compra unitario mucho más bajo, el precio de venta también puede reducirse, lo que potencialmente supera al mercado y, por lo tanto, aumenta enormemente la demanda. En un mundo sin computadoras, el taylorismo era la opción menos mala porque, aunque no era muy eficiente, era tremendamente escalable. Sin embargo, en un mundo con computadoras, la situación requiere un enfoque más integrado que tenga en cuenta, aunque sea de manera rudimentaria, tales retroacciones. Como dice el refrán, es mejor estar aproximadamente en lo correcto que exactamente equivocado.
Cuando se investiga a los clientes o prospectos sobre este tema, la situación suele ser confusa. Las soluciones, originalmente diseñadas para replicar un proceso puramente manual, han estado en funcionamiento durante tanto tiempo que las personas han perdido de vista los aspectos más fundamentales del problema que están tratando de 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. Por lo tanto, 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 que vuelven a examinar el problema en profundidad se perciben como “arriesgados”, tanto por la gerencia como por sus equipos. Por el contrario, se considera que la opción de mejorar incrementalmente la solución existente es “segura”; o al menos mucho “más segura”.
Mirando hacia atrás, la historia del software empresarial está desafortunadamente llena de historias de proveedores que imponen su “nueva forma” de hacer las cosas, que resulta ser mucho más tediosa y rígida que los procesos antiguos, sin generar ganancias de productividad. Anecdóticamente, observo que la mayoría de las empresas que operan grandes cadenas de suministro no han reducido sustancialmente su fuerza laboral de cuello blanco, que respalda sus cadenas de suministro, durante las últimas dos décadas, mientras que los trabajadores de cuello azul han sido automatizados de manera agresiva a través de mejores plantas o mejores almacenes. Estos eventos desafortunados inyectaron una buena dosis de escepticismo en el ecosistema contra esas agotadoras “reorganizaciones” con el fin de cumplir con una nueva solución de software.
Sin embargo, también observo que los ejecutivos de la cadena de suministro suelen subestimar en gran medida los riesgos asociados con cualquier software “inteligente”, es decir, cualquier software cuya corrección no se pueda especificar completamente y de manera concisa. De hecho, la mayoría del software empresarial no es más que aplicaciones CRUD, es decir, diligentes contadores de listados mundanos como: facturas, proveedores, productos, pagos, etc.
Lograr el éxito empresarial con un software “tonto” ya es bastante difícil: muchas empresas de comercio electrónico ya tienen dificultades para mantener un buen tiempo de actividad para su frontend web. Pero cuando se involucran componentes de software caprichosos como el aprendizaje automático, lograr el éxito se vuelve mucho más difícil. Pocas empresas comunican abiertamente este tema, pero cuando se involucra el aprendizaje automático, los fracasos dominan el campo. Sin embargo, la situación no es tan sombría como parece, porque las desventajas son limitadas, mientras que las ventajas no lo son.
Por lo tanto, a largo plazo, las empresas que más intentan y fallan también resultan ser las que más éxito tienen.
Sin embargo, los riesgos del software son muy reales y ciertamente no tiene sentido aumentar aún más esos riesgos. Sin embargo, adherirse al paradigma de replicar una práctica manual ahora obsoleta inevitablemente conlleva una serie de complicaciones accidentales. Por ejemplo, dado que el equipo de planificación y el equipo de suministro son distintos, surge toda una clase de problemas con el único propósito de mantener a esos equipos sincronizados. Como regla general en el desarrollo de software, inflar los requisitos en un 25% aumenta los costos en un 200%. La resolución de esas complicaciones aumenta drásticamente los costos y, por lo tanto, en la práctica, el riesgo, ya que las empresas tienden a terminar -una reacción sensata- iniciativas que explotan sus presupuestos o sus plazos.
Por lo tanto, cuando se enfrenta a la pregunta de medio siglo de adaptar el software para que se ajuste a la organización o adaptar la organización para que se ajuste al software, es sabio comenzar intelectualmente desde una hoja en blanco y primero averiguar cuáles son los problemas de alto nivel que necesitan ser resueltos. ¿Se mide el rendimiento en porcentajes o en dólares? ¿Estamos considerando correctamente las implicaciones a largo plazo? Como enseñar a los clientes a comprar solo durante las rebajas. ¿Se aprovechan las aportaciones humanas o simplemente se consumen esas aportaciones? ¿La práctica está impulsada por hábitos o por necesidad imperiosa? Como dos colecciones de moda al año, frente a dos cosechas al año.
La comprensión íntima del problema a resolver, que claramente diferencia el problema en sí de su solución actual, es la clave para determinar si la solución existente merece ser preservada o si debe simplificarse mediante capacidades de software más nuevas que requieren una resolución más simple y directa del problema.
