POCs no funcionan en la optimización de Supply Chain Quantitativa
Las pruebas de concepto son una de las solicitudes más frecuentes que recibimos de nuestros clientes prospectos que desean probar nuestro servicio de optimización de supply chain. Sin embargo, rechazamos con frecuencia tales solicitudes; primero, porque perjudican a la propia empresa del cliente, y segundo, porque también perjudican a Lokad en el proceso. Dado que los POCs – o pruebas de concepto – están tan difundidos en el software B2B, suele ser difícil comprender por qué pueden ser francamente perjudiciales en el caso específico de la optimización de Supply Chain Quantitativa (1). En este post, recopilamos nuestros hallazgos sobre los POCs, considerándolos un “anti-patrón” en supply chain.
POCs no cuestan menos
Una suposición central detrás de la metodología de POC es que los POCs cuestan menos que lo real. Desafortunadamente, esta suposición casi siempre es incorrecta.
Primero, establecer un alcance reducido dentro de una red completa de supply chain apenas mueve la aguja. En el pasado, los software vendors luchaban con problemas de escalabilidad y los despliegues a gran escala generalmente requerían fuertes inversiones iniciales en hardware, potencialmente empaquetadas con licencias de software como bases de datos. Sin estas inversiones, ni siquiera era posible comenzar a procesar datos. Sin embargo, en la era actual de computación en la nube, esta limitación ya no existe, y si una aplicación está diseñada correctamente, no se requiere nada extra para comenzar a procesar datos. La factura de computación en la nube aumentará solo marginalmente por cada cliente adicional, pero, en conjunto, este costo es insignificante comparado, por ejemplo, con los costos involucrados en entablar una conversación con el prospecto. En segundo lugar, la mayor parte de los esfuerzos iniciales consiste en calificar datos, seguido de una adecuada identificación para establecer una relación comercial B2B con el cliente.
Peor aún, contar con más datos generalmente facilita las cosas, no las complica, siempre que se involucre el forecast estadístico. Por lo tanto, al restringir el alcance de los datos, los POCs tienden a complicar las cosas, y por ende a incrementar los costos, en comparación con abordar el alcance total de los desafíos. Nuestra experiencia indica que, incluso cuando los POCs se centran en solo el 5% de la red completa de supply chain, ese 5% normalmente abarca casi toda la complejidad de la red en su conjunto. De hecho, es precisamente porque los POCs integran casi toda la complejidad de un proyecto a gran escala, que se esperaría que los POCs tuvieran sentido en primer lugar.
Descartar la complejidad no es, de hecho, una opción. Si tu red de supply chain incluye envíos en contenedores y se trabaja con proveedores poco fiables, ¿cómo podría ser convincente un POC si estos elementos no se han tenido en cuenta en la iniciativa? Si se ignora alguna restricción específica, como las MOQs (cantidades mínimas de pedido), los resultados numéricos terminan siendo inutilizables.
Los costos más allá del POC están determinados por los esfuerzos que deben realizarse por ambas partes, tanto por Lokad como por su cliente, en la gestión de la complejidad completa de la supply chain. Esos costos están impulsados por las especificidades del negocio en cuestión, siendo la escala solo un factor marginal en los costos.
POCs incrementan las probabilidades de fracaso
Al optar por un POC, las compañías con frecuencia terminan probando cosas para mejorar su supply chain. Sin embargo, en este caso específico, me gustaría citar a Yoda: Hazlo. O no lo hagas. No existe el intento. A pesar de las afirmaciones de los software vendors, optimizar supply chain es difícil. El problema con los POCs es que otorgan demasiada libertad para que las partes fracasen.
- Extraer el sales history es terriblemente complicado. Lamentablemente, no hay alternativa: nunca se logrará optimizar supply chain sin datos que representen la demanda.
- Los stock levels electrónicos son inexactos. La tecnología puede ayudar a detectar automáticamente las desviaciones más obvias y a priorizar los recuentos. Sin embargo, no es raro que los gerentes de supply chain tengan que lidiar también con phantom inventory.
- Los forecast permanecen pobres sin importar qué. Las empresas deben aprender a abrazar un futuro incierto, en lugar de desear que esa incertidumbre desaparezca. Probabilistic forecasts son especialmente buenos para capturar la incertidumbre futura.
Las complicaciones son tantas excusas para abandonar.
Existen situaciones en las que se espera que las soluciones sean fáciles y sin contratiempos: crear una nueva cuenta de correo para un nuevo empleado, por ejemplo. Sin embargo, optimizar supply chain es casi siempre difícil: si la empresa lleva funcionando más de unos pocos años, la parte “fácil” de la optimización de supply chain ya se realizó hace años. La parte “difícil” es lo que queda.
En nuestra experiencia, la mayoría de los POCs fracasan en las etapas iniciales del proyecto, cuando los equipos aún luchan con problemas de datos. Sin embargo, esto no dice nada acerca de la solución de optimización de inventario en sí, ya que la solución nunca se llega a poner a prueba.
Los POCs desvían las iniciativas de optimización de supply chain
Los POCs enfatizan un punto de vista que no es exactamente el de producción. Los ejecutivos buscan que se establezcan benchmarks o KPIs. Sin embargo, ¿qué sucede si un determinado KPI resulta ser más difícil de calcular que realizar la optimización en sí? ¿Qué pasa si el KPI, aunque instructivo, no ofrece opciones prácticas para mejorar nada?
Nuestra experiencia indica que, habitualmente, los POCs se desvían por consideraciones que simplemente no son requisitos desde una perspectiva de producción. Tratar de abordar esos requisitos generalmente envenena al POC porque, de repente, este se convierte en un desafío incluso mayor que la producción misma.
Además, dado que el objetivo principal de un POC es buscar seguridad, la mayoría de los POCs sufren de anti-patrones de gold plating, donde la empresa cliente presiona al vendor para que sea todo inclusivo en capturar cada aspecto de su negocio, incluso a expensas de la confiabilidad global de la solución. La solución resultante a menudo es demasiado frágil para resultar útil desde una perspectiva de producción.
Hemos visto que muchos POCs fracasan por problemas “imaginarios”. Por ejemplo, si el mejor modelo de forecast, probado empíricamente sobre miles de SKUs, resulta ser no estacional y supera a todos los demás modelos estacionales disponibles, ¿debería considerarse esto un problema? No cabe duda de que el negocio en cuestión es estacional: lo es. Pero, ¿qué pasa si la forma más conocida de anticipar la futura demanda es simplemente ignorar la estacionalidad en este caso? ¿Debería considerarse esto un problema? En nuestra experiencia, este único “problema” se ha considerado un obstáculo para muchos POCs, mientras que los propios profesionales de supply chain admitían que las cantidades finales de pedido sugeridas eran acertadas.
Ir a producción y revisar el proyecto si es necesario
Los POCs suelen y con razón ser percibidos como distracciones por parte de los profesionales que necesitan mantener el negocio en funcionamiento mientras llega la solución de próxima generación. Nuestra experiencia indica que pasar directamente a producción es más económico y menos arriesgado. Sin embargo, esto debe hacerse con la metodología adecuada.
Primero, fracasar debido a la “logística de datos” no es una opción. No se puede optimizar lo que no se mide. Si los datos carecen de significado, entonces todos los intentos de optimización serán igualmente vacíos. El éxito es un requisito, ya que de lo contrario la empresa podría dejar de existir en unos años. Sucede que la gran mayoría de los esfuerzos a invertir están asociados a esta logística de datos, y dicha inversión puede separarse casi por completo de la solución que se considere para producción. ¡Y eso es algo bueno! Si, por alguna razón, la solución de optimización se queda corta, la inversión no se pierde y simplemente debe redirigirse a una solución alternativa superior.
En segundo lugar, aunque el objetivo es ir directamente a producción, eso no significa que las cifras queden sin ser cuestionadas; todo lo contrario. El proceso antiguo y el nuevo deben coexistir, aprovechando la mayor cantidad posible de frutos al alcance del proceso antiguo (2) mientras se perfecciona el nuevo.
Luego, surgen típicamente docenas de problemas. Es importante resolverlos:
- problemas que ya afectaban al proceso antiguo, aunque de una manera más silenciosa. Los buenos procesos y las buenas tecnologías hacen que los problemas sean evidentes; esto no es un defecto, sino una virtud.
- problemas que no pueden solucionarse con el software que se está desplegando. Si la selección de SKUs es poco fiable en el almacén, no esperes que el módulo de forecast de demanda lo haga confiable.
- desajuste entre los problemas reales y las expectativas. El forecast estadístico es profundamente contraintuitivo; no permitas que tus expectativas anulen lo que indican las mediciones cuantitativas.
- problemas de diseño que no se pueden resolver sin rediseñar significativamente la solución, lo que suele ocurrir cuando el software no tiene el ángulo adecuado para abordar el desafío.
El último punto requiere que se considere otra solución. Sin embargo, como se mencionó anteriormente, esto no debe ser el fin de la iniciativa, sino apenas el comienzo de una colaboración con otro vendor.
Abandonar la idea de un POC generalmente significa perder todo el impulso que se ha invertido en la iniciativa. Además, la mayoría de los POCs fracasan por las razones equivocadas, lo que significa que las probabilidades de éxito en futuros intentos apenas mejorarán, ya que los desafíos reales permanecen en gran parte sin abordar.
Ir directamente a producción es, en realidad, menos arriesgado de lo que parece. Ayuda a prevenir una clase entera de fallos que tienden a ser ignorados en el caso de los POCs, cuando en realidad no deberían serlo. Obliga a la iniciativa a adoptar un enfoque estrecho en lo que realmente se necesita para obtener mejoras, dejando de lado los deseos infundados. Ante un fallo grave del vendor, una empresa aún puede capitalizar su impulso interno y cambiar a otro vendor, sin perder dicho impulso como suele ocurrir con los POCs.
(1) Existen muchas formas de optimizar supply chain: mejores procesos, mejores proveedores, mejores transportistas, mejores contrataciones … Este post se centra en la optimización cuantitativa: desafíos de supply chain que pueden abordarse mediante forecast estadísticos y/o solucionadores numéricos.
(2) Corregir el phantom inventory beneficia a todos los procesos de optimización de inventario. Lo mismo ocurre al revisar y mejorar las valoraciones de inventario.
