Antipatterns en supply chain

Las iniciativas de supply chain a menudo fracasan. La Supply Chain Quantitativa es nuestra respuesta para reducir drásticamente las tasas de fracaso. Sin embargo, dado que Supply Chain Quantitativa se centra en las prácticas que sabemos que funcionan, pone poco énfasis en aquellas prácticas que también sabemos que no funcionan. Peor aún, resulta que la mayoría de estas prácticas indeseables son precisamente las causas fundamentales detrás de las altas tasas de fracaso asociadas a los métodos tradicionales de supply chain.

A continuación, revisamos las prácticas - o patrones - que hacen fracasar la mayoría de las iniciativas de supply chain. Estos conocimientos han sido obtenidos a pulso, ya que, por cada hallazgo, normalmente no bastó un fracaso, sino varios, para comprender la causa raíz del problema. Nos referimos a esas prácticas nocivas como supply chain antipatterns. Un antipatrón es una “solución” que resulta contraproducente: es un enfoque común, parece una buena idea, y sin embargo, invariablemente falla en entregar la mejora prevista originalmente.

Mal liderazgo

En Lokad, ciertamente no queremos antagonizar a los principales tomadores de decisiones de supply chain, ya que son nuestros prospectos y clientes. Sin embargo, al mismo tiempo, sentimos que es nuestro deber negarnos a cerrar un trato cuando la solución está garantizada a fracasar por diseño. Frecuentemente, el problema se reduce a cómo se gestiona la iniciativa en sí. Dicho esto, reconocemos que la gestión de supply chain no es el único culpable. Ciertos proveedores a veces promueven todos los mensajes equivocados a sus clientes y se salen con la suya sin reparos. Las prácticas heredadas y la política interna también pueden envenenar la vida diaria de la gestión de supply chain, la cual podría incluso usarse como chivo expiatorio cuando las cosas no salen como se esperaba. En esta sección, enumeramos las trampas comunes que podrían abordarse a través de un liderazgo de supply chain revisado.

La RFQ del infierno

Puede haber muchas áreas donde los RFQs (solicitudes de cotización) tengan sentido. Desafortunadamente, el software no es una de ellas. Escribir la especificación de un software es muchísimo más difícil que escribir el software en sí. La tarea es desalentadora. Una vez que se inicia un proceso de RFQ, las empresas logran empeorar la situación al introducir consultores, lo que complica aún más una especificación ya de por sí excesivamente complicada. El RFQ sofoca la mayor parte del pensamiento orientado a la resolución de problemas, porque el proceso de RFQ asume que el cliente ya conoce los detalles mínimos de la solución deseada, mientras que el “problema” está, por definición, en gran parte sin resolver en el momento en que se redacta el RFQ. Además, en la práctica, los RFQs promueven un proceso adversarial de selección de proveedores: los buenos proveedores se retiran mientras que los malos permanecen. Finalmente, la industria del software es acelerada, y para cuando tu empresa termina con su proceso de RFQ, tu competidor ya ha implementado su solución.

El POC frágil

Realizar un POC (prueba de concepto) es bueno si lo que pretendes comprar es un servicio simple casi comoditizado: como, por ejemplo, un servicio de impresión de tarjetas de presentación. Una iniciativa de supply chain es complicada por diseño. El supply chain requiere la coordinación de múltiples entidades. Existen múltiples capas de datos que deberían ser aprovechadas. Hay decenas de flujos de trabajo que hay que tener en cuenta. Los POC o pilotos a pequeña escala hacen más daño que beneficio porque, por su mismo diseño, descuidan una virtud fundamental de una iniciativa de supply chain exitosa: su capacidad para operar a gran escala. La mayoría de la gente está acostumbrada al principio de las economías de escala; sin embargo, cuando se trata de la optimización de supply chain, primordialmente tendemos a enfrentarnos a deseconomías de escala, donde tomar buenas decisiones se vuelve cada vez más difícil a medida que crece la complejidad del problema. Lograr el éxito en un pequeño centro de distribución no garantiza en absoluto que la solución funcione igual de bien al tratar con decenas de centros de distribución diferentes.

Descartar la incertidumbre

El futuro es incierto, y la incertidumbre no se puede desear que desaparezca. De manera similar, la optimización numérica de supply chain es un problema difícil que tampoco se puede desear que desaparezca. La optimización de supply chain requiere forecast probabilísticos, que son la consecuencia directa de lidiar con futuros inciertos. La optimización de supply chain también enfrenta comportamientos bastante contraintuitivos generados por las optimizaciones numéricas. Algunos proveedores explotan el deseo de mantener las cosas simples y fáciles para vender una práctica fantasiosa en la que todos los obstáculos están abstraídos. Desafortunadamente, esos obstáculos no son meras tecnicidades: definen lo que tiene la posibilidad de funcionar realmente para tu supply chain. La incertidumbre debe ser abrazada desde una perspectiva numérica profunda. La gestión de supply chain también debe reconocer y abrazar la incertidumbre.

Confiar en el becario

Si mejorar el supply chain es algo importante para tu empresa, entonces la iniciativa requiere la participación directa de la alta dirección. Con demasiada frecuencia, las empresas atesoran la idea de la mejora, pero luego asignan uno o dos becarios al caso. Aunque hemos conocido a algunos becarios muy inteligentes, nunca hemos visto que una iniciativa de supply chain impulsada por becarios llegue a buen puerto. No tenemos nada en contra de los becarios, claro está. Pueden ser inteligentes, motivados y pensadores innovadores; pero están muy lejos de ser lo que tu empresa necesita para impulsar un cambio en su supply chain. El compromiso de la alta dirección de supply chain debería darse por sentado, de lo contrario, los equipos no ejecutarán. Normalmente, los equipos no disponen de mucho tiempo libre, si es que tienen alguno. A menos que la dirección deje claro, mediante su participación directa, que la iniciativa actual es una prioridad, ésta realmente no lo es para nadie, salvo quizás para el pobre becario asignado al caso.

Muerte por planificación

La dirección busca tranquilidad, y cuando se trata de sentirse tranquilo, nada se ve tan bien como una hoja de ruta sólida, con fases, roles y entregables bien definidos. Sin embargo, si la historia del software nos ha enseñado algo, es que los planes predefinidos usualmente no sobreviven la primera semana de la iniciativa. A veces, ni siquiera sobreviven el primer día. Cuando se trata de la optimización de supply chain, seguirán sucediendo cosas inesperadas, y esta es una perspectiva algo aterradora. No obstante, rigidizar la iniciativa mediante una planificación precisa solo empeora las cosas: la iniciativa se vuelve aún más frágil ante imprevistos. En cambio, la iniciativa debería hacerse lo más resiliente posible contra lo desconocido. La capacidad de recuperarse de los problemas es más importante que la capacidad de eliminarlos por adelantado. Por lo tanto, la gestión de supply chain debería centrarse en hacer la iniciativa ágil en lugar de bien planificada.

Desacoplar el forecast de la optimización

La perspectiva tradicional sobre la optimización de supply chain separa el proceso de forecast del proceso de toma de decisiones. Si bien esto puede ser factible desde un punto de vista muy técnico, utilizando dos conjuntos distintos de algoritmos, uno para el forecast y otro para la optimización; desde un punto de vista funcional, el equipo encargado del forecast debe ser también el encargado de la optimización. De hecho, la lógica de toma de decisiones, o en otras palabras la optimización, es numéricamente muy sensible a la lógica del forecast. Aislar ambas perspectivas es una receta para amplificar cualquier falla que ya pueda existir a nivel del forecast, causando estragos en las decisiones resultantes. La lógica de la optimización, en cambio, debería ser numéricamente lo más cooperativa posible con las fortalezas y debilidades de la lógica del forecast.

Frankensteinización del software

Es difícil lograr consenso en las grandes empresas. Como resultado, mientras que la mayoría de las partes interesadas en supply chain podría decidir optar por un proveedor específico, una minoría podría mantenerse firme en imponer su propia visión o desear optar por ciertas características de un producto completamente diferente. Dado que la personalización del software constituye un negocio rentable para los grandes proveedores de software, el proveedor con demasiada frecuencia se muestra dispuesto a complacer, inflando los costos y el valor percibido en el proceso. Sin embargo, un buen software tarda años en escribirse, y cuando se hace correctamente, el resultado final representa un equilibrio afinado entre objetivos en conflicto. El resultado casi sistemático de la sobrepersonalización del software por parte de las grandes empresas es quitarle las propiedades originales del producto y hacerlo no mejor, sino peor, al agregarle cada vez más capas, convirtiéndolo así en un monstruo. No hay desabastecimiento-stockout de proveedores de software. Si la solución no se ajusta a tu empresa, sigue adelante y elige otro proveedor. Si ningún proveedor se ajusta a tu empresa, entonces o bien tu negocio es realmente único –lo cual es raro– o quizás deberías revisar tus requerimientos.

Iniciativas impulsadas por buzzwords

Alrededor de 2010, estaba muy de moda en el sector minorista descubrir cómo aprovechar los forecast meteorológicos para refinar los forecast de demanda. En 2012, estaba de moda incorporar datos de redes sociales en el forecast de demanda. En 2014, el Big Data dominaba, para ser reemplazado por el machine learning en 2016. Cada año que pasa viene acompañado de una nueva ola de buzzwords. Aunque nunca suele haber mucho daño en revisar un problema antiguo con una perspectiva fresca, en realidad, perder de vista los desafíos centrales casi garantiza poner en peligro cualquier iniciativa ya emprendida. Si algo es demasiado bueno para ser verdad, probablemente lo sea. Las mejoras en el supply chain se consiguen a pulso. Asegúrate de que cualquier novedad que desees incorporar se centre realmente en los desafíos fundamentales que enfrenta tu supply chain.

Mala ejecución de IT

A IT se le culpa con demasiada frecuencia de los fracasos de proyectos. IT es difícil, mucho más difícil de lo que la mayoría de las personas fuera de IT se dan cuenta. Sin embargo, también sucede a veces que los equipos de IT, con buenas intenciones, crean tanta fricción a través de sus procesos que la iniciativa se ralentiza hasta el punto de que el resto de la empresa simplemente se rinde. Los equipos de IT no solo deben aceptar el cambio en sentido general, sino también aceptar el tipo específico de cambio que no compromete futuros cambios positivos. Más fácil decirlo que hacerlo.

Cuidado con los mecanismos de defensa de IT

Dado que los equipos de IT pueden haberse sentido chivos expiatorios en más de una ocasión en el pasado, cuando algunos proyectos de la empresa fracasaron, pueden haber desarrollado ciertos “mecanismos de defensa”. Uno de los mecanismos de defensa más comunes consiste en solicitar especificaciones detalladas por escrito para cada nueva iniciativa. Sin embargo, especificar una solución de software tiende a ser más difícil que implementar la solución de software en sí. En consecuencia, esto equivale a reemplazar un problema complejo por uno aún más complejo. Otros mecanismos de defensa consisten en tener una línea dura de “requerimientos” tales como: el software debe estar ubicado en las instalaciones, el software debe ser compatible con XYZ, el software debe tener características de seguridad específicas, y así sucesivamente. Un buen software tarda años en escribirse. Una vez que se redacta la larga lista de requerimientos, por lo general solo quedan dos tipos de proveedores de software: aquellos que no son compatibles con tus requerimientos, y aquellos que mienten al decir que sí lo son.

Subestimar el esfuerzo en los datos

Aunque esto pueda parecer una paradoja, las iniciativas de supply chain también pueden fracasar porque IT se involucra demasiado en idear la solución y asume la tarea de preparar los datos. De hecho, dado que IT es increíblemente complejo, y por lo tanto puede incluir individuos bastante talentosos, también puede suceder que algunos equipos de IT lleguen a pensar que conocen el negocio mejor que el resto de la empresa. La consecuencia indeseable principal de esta línea de pensamiento es una constante subestimación de los desafíos que implica trabajar con los datos de la empresa. Procesar datos de manera significativa no se trata de mover megabytes de datos de un lado a otro. Más bien, consiste en establecer una comprensión sutil de cómo estos datos reflejan los procesos y flujos de trabajo de la empresa. También se trata de entender los matices, sesgos y límites sutiles de los datos, tal como ocurren en los sistemas de la empresa en cualquier momento. Que los equipos de IT se hagan cargo de la preparación de datos es una receta segura para tener retrasos inesperados, ya que gradualmente se dan cuenta de cuán profundo era el vacío en su visión original. Teniendo todo esto en cuenta, la opción razonable consiste en delegar este rol desde el principio a alguien fuera del departamento de IT.

La tentación de la plataforma extensible

Cuando se trata de software empresarial, hay una cosa en la que los proveedores se han perfeccionado: el arte de ser una plataforma “extensible” que viene con muchos módulos, que representan muchas oportunidades de upsell. Sin embargo, las plataformas no funcionan bien juntas y las superposiciones funcionales –es decir, dos plataformas que compiten internamente por la misma función dentro de tu empresa– aparecen muy pronto. Dos plataformas superpuestas son una pesadilla para IT en cualquier empresa y, por lo general, resultan en mecanismos de sincronización que son difíciles de configurar y aún más difíciles de mantener. Así, aunque es tentador optar por una solución integral, la opción razonable casi siempre radica en elegir aplicaciones específicas que hagan una cosa y la hagan bien. Mantener docenas de aplicaciones específicas es sencillo, mientras que gestionar dos grandes plataformas –con superposiciones funcionales igualmente grandes– es infernal.

Extracciones de datos poco fiables

Los datos son como la sangre para una iniciativa de Supply Chain Quantitativa: si dejas de bombearlos, muere. La iniciativa necesita ser alimentada constantemente con datos frescos. Muy a menudo, IT considera que realizar un par de extracciones de datos puntuales es suficiente para empezar. A fin de cuentas, es probable que esta iniciativa se termine pronto de todas formas - recuerda, la mayoría de las iniciativas de supply chain fracasan - y, por lo tanto, no tiene mucho sentido invertir demasiado esfuerzo durante esta etapa inicial de extracción de datos. Sin embargo, siguiendo esta línea de pensamiento, la implementación de un proceso automatizado para extracciones de datos confiables se retrasa y, como resultado, se convierte en una de las principales causas raíz del fracaso de la iniciativa. Aquí, IT debe ser proactivo y comenzar a automatizar las extracciones de datos desde el primer día. Además, el equipo de IT también tiene un rol de mentoría para convencer al resto de la empresa de que este esfuerzo adicional es un factor clave para el éxito de la iniciativa, y que la opción desechable para la extracción de datos no llevará a ninguna parte.

Malas recetas numéricas

Optimizar supply chain es, ante todo, un juego de números. Naturalmente, la visión de la empresa importa, el liderazgo importa, la disciplina importa, pero nuestra experiencia indica que la mayoría de las empresas ya realiza un trabajo más que aceptable en estas áreas. Sin embargo, cuando se trata de números, parece que todo el sector de supply chain está invadido por malas recetas numéricas. No todos los profesionales de supply chain se dan cuenta de que todas las fórmulas y modelos - a los que nos referimos aquí como recetas numéricas - dependen de supuestos bastante estrictos. Si se rompe cualquiera de estos supuestos, la receta numérica se desmorona. En esta sección, enumeramos los infractores más comunes al respecto. Por economía de palabras, asumimos que el lector ya está familiarizado con las recetas en sí.

Análisis ABC

El enfoque ABC para el inventario se ideó en una época en la que los ordenadores no eran una opción para gestionar el supply chain. El principal beneficio del análisis ABC es que mantiene el análisis tan simple que se puede hacer a mano. Sin embargo, considerando la asombrosa capacidad de procesamiento de los ordenadores modernos, el uso del análisis ABC ya no tiene sentido hoy en día. No hay ningún beneficio en enmarcar miles de SKUs en 3 o 4 clases arbitrarias. Existe un continuo completo entre el producto que más se vende y la larga cola. La lógica que optimiza el supply chain debería abarcar este continuo, en lugar de negar que este continuo existe desde el principio. En la práctica, también observamos que los efectos negativos del análisis ABC se agravan por cambios en el mercado que conducen a inestabilidades en las clases, con productos que siguen cambiando de clase a lo largo del tiempo.

Existencias de seguridad

No existe algo como “existencias de seguridad” en tu almacén. Existencias de seguridad es un concepto ficticio que divide el stock disponible en dos categorías: el stock operativo y las existencias de seguridad. Desde una perspectiva histórica, las existencias de seguridad se introdujeron como una forma simplista de lidiar con la variabilidad en la demanda y en los tiempos de entrega. Las existencias de seguridad se modelan basándose en distribuciones normales - también conocidas como gaussianas. Sin embargo, incluso un examen rápido de prácticamente cualquier conjunto de datos de supply chain muestra claramente que ni la demanda ni los tiempos de entrega se distribuyen de forma normal. En los primeros años de la década de 1980, cuando los ordenadores aún eran muy lentos, las distribuciones normales podían haber sido un compromiso válido entre complejidad y precisión, pero hoy en día, no tiene sentido aferrarse a algo que fue diseñado como un “hack” para hacer frente a las limitaciones de los ordenadores de aquella época.

Correcciones manuales de forecast

Algunos profesionales pueden enorgullecerse de ser capaces de “batir al sistema” y generar números de forecast mejores de lo que el sistema puede producir. Si este es el caso, el sistema debería considerarse disfuncional y corregirse en consecuencia, aprovechando típicamente la experiencia y las percepciones del profesional. Optimizar un supply chain de cualquier escala significativa implica generar miles, si no millones, de forecast por día. Confiar en las entradas de datos manuales de los equipos de supply chain para suplir las deficiencias del sistema ni siquiera debería considerarse una opción válida para la empresa. Dado el progreso en estadística en los últimos 20 años, no hay ninguna razón para pensar que, al recibir los mismos insumos de datos, un sistema automatizado no pueda superar a un humano que, hablando realisticamente, no tendrá más de unos pocos segundos para dedicar a cada número que necesite ser producido. Si el humano tuviera días para dedicar a cada decisión que la empresa necesita tomar, entonces la situación sería radicalmente diferente. Sin embargo, la gran mayoría de decisiones que el supply chain necesita tomar a diario no encajan en esta categoría.

Alertas y monitoreo de forecasts malos

Los forecast clásicos enfatizan un único futuro - es decir, forecast orientados hacia la media o la mediana - como si ese único futuro fuera a suceder con alguna probabilidad significativa. Sin embargo, el futuro es incierto y los forecast son, en el mejor de los casos, aproximados. En ciertas situaciones, los forecast clásicos están simplemente equivocados. Con frecuencia, la compañía incurre en costos inmensos debido a esos grandes errores de forecast. Como resultado, se implementan alertas para monitorear esos grandes errores. Sin embargo, el principal culpable no son los forecast en sí, sino la perspectiva de forecast clásico que enfatiza un único futuro, cuando en realidad todos los futuros son posibles, aunque no con la misma probabilidad. Desde la perspectiva del forecast probabilístico, los errores de forecast se conocen principalmente de antemano y se representan como distribuciones de probabilidades, que se extienden finamente sobre un amplio rango de valores posibles. Los forecast probabilísticos enfatizan un enfoque mediante el cual la empresa reducirá proactivamente el riesgo en su actividad de supply chain al enfrentarse a un mayor grado de incertidumbre. En contraste, implementar alertas en los forecast clásicos es el síntoma de un enfoque que está roto por diseño, ya que niega toda la incertidumbre.

Parchear los datos históricos

Cuando se encuentran sesgos, como faltantes de stock o promociones, en los datos históricos, es tentador de alguna manera “arreglar” esos sesgos modificando los datos históricos, de modo que los datos reflejen mejor cómo habría sido la historia sin el sesgo. Nos referimos a este proceso como al “duct taping” de los datos históricos. La idea fundamental detrás del duct taping es que todos los modelos de forecast están diseñados como variantes del promedio móvil. Si lo único que tienes son promedios móviles, entonces, de hecho, es necesario ajustar los datos históricos para tener en cuenta estos promedios móviles. Sin embargo, el duct taping no es la solución. En realidad, la solución radica en ampliar el horizonte y buscar mejores modelos de forecast que no sean tan disfuncionales como el promedio móvil. Se deben utilizar mejores modelos estadísticos para manejar con éxito datos históricos “enriquecidos”, donde los mismos sesgos se tratan como insumos de datos. Aunque esos modelos estadísticos pueden no haber estado disponibles hace décadas, definitivamente ya no es así.

Los tiempos de entrega como ciudadanos de segunda clase

Por algunas razones que no nos quedan completamente claras, los tiempos de entrega son con demasiada frecuencia considerados como una entrada de datos obvia en lugar de algo que necesita su propio forecast. Los tiempos de entrega futuros son inciertos, y casi siempre, la mejor manera de estimarlos de forma confiable es usar los tiempos de entrega observados en el pasado. Por lo tanto, los tiempos de entrega requieren su propio forecast. Además, las implicaciones en el supply chain de estimar correctamente los tiempos de entrega son mucho mayores de lo que muchos profesionales se dan cuenta: las cantidades mantenidas en stock están precisamente para cubrir la demanda durante un determinado tiempo de entrega. Cambia el tiempo de entrega y las cantidades en stock también cambian. Por lo tanto, los forecast de tiempos de entrega no pueden tener el papel de ciudadanos de segunda clase en los esfuerzos de tu supply chain. Casi todos los planes de supply chain enfatizan la necesidad de forecast precisos de la demanda, pero nuestra experiencia indica que, en la práctica, los forecast precisos de los tiempos de entrega son igual de importantes.

Pseudociencia

La pseudociencia tiene todas las características de la ciencia: parece racional, viene acompañada de números, se dice que está probada y personas muy educadas defienden su caso. Sin embargo, la pseudociencia no resiste la prueba de lograr resultados repetibles. Usualmente, ni siquiera se requiere un montaje experimental para detectar la pseudociencia, y los materiales de pseudociencia comienzan a desmoronarse bajo el escrutinio de una revisión por pares imparcial. Los supply chain son costosos de operar y complejos de comprender. Estos dos atributos por sí solos explican por qué las metodologías de supply chain son tan difíciles de cuestionar: no solo los experimentos conllevan mucho riesgo, sino que también es difícil evaluar correctamente qué es lo que realmente contribuye a una mejora percibida.

Casos de negocio fantásticos

Las soluciones de supply chain ciertamente no son la única área del software empresarial en la que los proveedores hacen afirmaciones audaces, pero como dice el viejo refrán: si parece demasiado bueno para ser verdad, probablemente lo sea. Nosotros mismos hemos observado que prácticamente cada enero, en la feria comercial NRF en Nueva York, una de las ferias comerciales minoristas más grandes del mundo, que ha estado operando durante más de un siglo. A menudo, detectamos a un proveedor muy grande que afirma audazmente que los niveles de inventario ahora se pueden reducir a la mitad, con la ayuda de su nueva solución. Si tan solo 1 de cada 10 de esas afirmaciones fuera cierta, toda la industria habría alcanzado niveles de stock casi perfectos hace una década. Hay tantas maneras de manipular los números del caso de negocio que la mayoría de los proveedores ni siquiera están mintiendo realmente. El caso más común es que la compañía anunciada como el “ejemplo a seguir” de la solución tenía un supply chain enormemente disfuncional desde el principio, y por lo tanto era posible obtener cifras de mejora igualmente masivas, una vez que todo volviera a la normalidad un año después.

Confiar en el equipo de Ventas para el forecast

Sigue siendo un misterio si las personas que encargan a sus equipos de Ventas producir números precisos de forecast de demanda, alguna vez han trabajado con un equipo de ventas real. En el mejor de los casos, estos números pueden verse como un mero cálculo aproximado honesto, pero más a menudo de lo que se piensa, simplemente son inventados por el equipo de Ventas intentando manipular cualquier incentivo financiero que se les otorgue. Esto da pie a la práctica generalizada conocida como “sandbagging”, en la que todos fijan sus objetivos lo más bajos posible para luego superar las expectativas. Además, con el tiempo, tenemos equipos de supply chain que a menudo fingen prestar atención a esas cifras, mientras que las operaciones reales permanecen totalmente separadas de los insumos proporcionados por Ventas. Ignorar las cifras sugeridas por el equipo de Ventas es la única opción razonable, ya que el supply chain dejaría de funcionar por completo si realmente tuviera que operar basándose en números tan deficientes.

Soluciones comprobadas

Buscar una solución comprobada que haya logrado ofrecer beneficios tangibles para una empresa muy similar a la tuya podría parecer una perspectiva muy racional. Desde una perspectiva anecdótica, esto es exactamente lo que hizo Nokia, y otras innumerables empresas, hasta que desaparecieron. La mayoría de las grandes empresas no actúan tan rápidamente a la hora de elegir una solución compleja. El proceso de selección de proveedores puede fácilmente tomar hasta 1 año. Luego, alcanzar la velocidad de crucero con la solución elegida podría tomar también otro año. Monitorear y ganar confianza en los resultados puede tomar 1 o 2 años más; especialmente en aquellos supply chain donde no todas las soluciones son sostenibles, y donde el supply chain puede rápidamente volver al estado de desempeño anterior, una vez que el proveedor ya no esté constantemente presente en el sitio para ajustar la solución. Después de esto, puede tomar 1 año más para que el proveedor de la solución finalmente llegue a tu empresa con esta prueba tan ganada con esfuerzo. El fallo fatal en esta línea de pensamiento es que tu empresa puede permitirse llegar a la fiesta con 5 años de retraso. Cuando se trata de software, 5 años es un tiempo muy largo. La mayoría del software se considera obsoleto a los 5 años; ¿por qué sería diferente tu solución de supply chain?

Malas métricas, malos benchmarks

El Supply Chain Quantitativa se trata de números en los que puedes confiar. Como resultado, tendemos a inclinarnos fuertemente hacia las métricas y benchmarks. Sin embargo, observamos que, en el supply chain, la gran mayoría de benchmarks y métricas están tan mal diseñados que, en nuestro caso, generalmente se consideran pseudociencia. Las buenas métricas de supply chain requieren mucho esfuerzo. Los buenos benchmarks de supply chain requieren un esfuerzo casi descomunal. Con demasiada frecuencia, las métricas y benchmarks se simplifican en aras de la simplicidad, pero a expensas de toda relevancia real para el negocio. Como regla general, si operar un benchmark no parece una tarea increíblemente difícil para tus equipos de supply chain, entonces lo más probable es que el desafío esté enormemente subestimado.