00:00 Introducción
02:31 Causas raíz de fracaso en la práctica
07:20 Entregable: una receta numérica 1/2
09:31 Entregable: una receta numérica 2/2
13:01 Lo que hemos visto hasta ahora
14:57 Haciendo las cosas hoy
15:59 Cronología de la iniciativa
21:48 Alcance: panorama aplicativo 1/2
24:24 Alcance: panorama aplicativo 2/2
27:12 Alcance: efectos del sistema 1/2
29:21 Alcance: efectos del sistema 2/2
32:12 Roles: 1/2
37:31 Roles: 2/2
41:50 Pipeline de datos - Cómo
44:13 Una palabra sobre sistemas transaccionales
49:13 Una palabra sobre el data lake
52:59 Una palabra sobre sistemas analíticos
57:56 Salud de los datos: nivel bajo
01:02:23 Salud de los datos: nivel alto
01:06:24 Inspectores de datos
01:08:53 Conclusión
01:10:32 Próxima clase y preguntas de la audiencia
Descripción
Realizar una optimización predictiva exitosa de una supply chain es una mezcla de problemas blandos y duros. Desafortunadamente, no es posible separar esos aspectos. Las facetas blandas y duras están profundamente entrelazadas. Por lo general, este entrelazamiento choca frontalmente con la división del trabajo definida por el organigrama de la empresa. Observamos que, cuando las iniciativas de supply chain fallan, las causas raíz del fracaso suelen ser errores cometidos en las etapas más tempranas del proyecto. Además, los errores tempranos tienden a dar forma a toda la iniciativa, lo que hace casi imposible corregirlos ex post. Presentamos nuestros principales hallazgos para evitar esos errores.
Transcripción completa
Bienvenido a esta serie de clases sobre supply chain. Soy Joannes Vermorel y hoy presentaré “Iniciando una Iniciativa de Supply Chain Cuantitativa”. La gran mayoría de las iniciativas de supply chain que involucran análisis de datos están fallando. Desde 1990, la mayoría de las empresas que operan grandes supply chains han estado lanzando importantes iniciativas de optimización predictiva cada tres a cinco años con poco o ningún resultado. Hoy en día, la mayoría de los equipos en supply chains o ciencia de datos, que comienzan otra ronda de optimización predictiva, típicamente enmarcada como un proyecto de pronóstico o un proyecto de optimización de inventario, ni siquiera se dan cuenta de que su empresa ya ha estado allí, lo ha hecho y ha fallado posiblemente media docena de veces.
Ir por otra ronda a veces se basa en la creencia de que esta vez será diferente, pero con frecuencia, los equipos ni siquiera son conscientes de los muchos intentos fallidos que ocurrieron antes. La evidencia anecdótica de esta situación es que Microsoft Excel sigue siendo la herramienta número uno para impulsar decisiones de supply chain, mientras que esas iniciativas se suponía que reemplazarían las hojas de cálculo con mejores herramientas. Sin embargo, hoy en día todavía hay muy pocas supply chains que puedan funcionar sin hojas de cálculo.
El objetivo de esta clase es comprender cómo darle una oportunidad de éxito a una iniciativa de supply chain que pretende ofrecer cualquier tipo de optimización predictiva. Revisaremos una serie de ingredientes críticos, que son simples y, sin embargo, son muy frecuentes como contraintuitivos para la mayoría de las organizaciones. Por el contrario, revisaremos una serie de anti-patrones que casi garantizan el fracaso de dicha iniciativa.
Hoy, mi enfoque se centra en la ejecución táctica del comienzo mismo de una iniciativa de supply chain con una mentalidad de “hacer las cosas”. No discutiré las grandes implicaciones estratégicas para la empresa. La estrategia es muy importante, pero discutiré este tema en una clase posterior.
La mayoría de las iniciativas de supply chain fracasan y el problema casi nunca se menciona públicamente. La academia publica decenas de miles de artículos al año presumiendo todo tipo de innovaciones en supply chain, incluyendo marcos de trabajo, algoritmos y modelos. Con frecuencia, los artículos incluso afirman que la innovación se ha implementado en algún lugar. Y sin embargo, mi propia observación casual del mundo de supply chain es que esas innovaciones no se ven por ningún lado. De manera similar, los proveedores de software han estado prometiendo reemplazos superiores para las hojas de cálculo durante las últimas tres décadas y, nuevamente, mi observación casual indica que las hojas de cálculo siguen siendo omnipresentes.
Estamos volviendo a un punto que ya se tocó en el segundo capítulo de esta serie de clases sobre supply chain. En pocas palabras, las personas no tienen ningún incentivo para publicitar el fracaso y, por lo tanto, no lo hacen. Además, como las empresas que operan supply chains tienden a ser grandes, el problema se complica aún más por la pérdida natural de memoria institucional a medida que los empleados rotan de un puesto a otro. Es por eso que ni la academia ni los proveedores reconocen esta situación bastante desalentadora.
Propongo comenzar con una breve encuesta de las causas raíz más frecuentes del fracaso desde una perspectiva de ejecución táctica. De hecho, estas causas raíz se encuentran típicamente en la etapa más temprana de la iniciativa.
La primera causa de fracaso es el intento de resolver problemas incorrectos, problemas que no existen, que son inconsecuentes o que reflejan algún tipo de malentendido sobre el supply chain en sí. Optimizar los porcentajes de precisión de pronóstico es probablemente el arquetipo de un problema incorrecto. Reducir el porcentaje de error de pronóstico no se traduce directamente en euros o dólares adicionales de retorno para la empresa. La misma situación ocurre cuando una empresa persigue niveles de servicio específicos para su inventario. Es muy raro tener euros o dólares de retorno para mostrar por ello.
La segunda causa raíz del fracaso es el uso de tecnología de software y diseño de software inadecuados. Por ejemplo, los proveedores de ERP invariablemente intentan utilizar una base de datos transaccional para respaldar iniciativas de análisis de datos porque es en lo que se basa el ERP. Por otro lado, los equipos de ciencia de datos invariablemente intentan utilizar el kit de herramientas de aprendizaje automático de código abierto de vanguardia del día porque es algo genial de hacer. Desafortunadamente, las piezas de tecnología inadecuadas suelen generar una fricción inmensa y mucha complejidad accidental.
La tercera causa raíz del fracaso es una división incorrecta del trabajo y la organización. En un intento equivocado de asignar especialistas en cada etapa del proceso, las empresas tienden a fragmentar la iniciativa entre demasiadas personas. Por ejemplo, la preparación de datos se realiza con mucha frecuencia por personas que no están a cargo del pronóstico. Como resultado, las situaciones de basura de entrada-basura de salida están por todas partes. Diluir marginalmente la responsabilidad de las decisiones finales de la cadena de suministro es una receta para el fracaso.
Un elemento que no he incluido en esta lista corta como causa raíz es los datos incorrectos. Con frecuencia se culpa a los datos de los fracasos de las iniciativas de la cadena de suministro, lo cual es demasiado conveniente, ya que los datos no pueden responder exactamente a esas acusaciones. Sin embargo, los datos generalmente no son los culpables, al menos no en el sentido de luchar con datos incorrectos. La cadena de suministro de las grandes empresas se digitalizó hace décadas. Cada artículo que se compra, transporta, transforma, produce o vende tiene registros electrónicos. Esos registros pueden no ser perfectos, pero generalmente son muy precisos. Si las personas no logran manejar adecuadamente los datos, no es realmente la transacción la que tiene la culpa.
Para que una iniciativa cuantitativa tenga éxito, debemos luchar la batalla correcta. ¿Qué es lo que estamos tratando de entregar en primer lugar? Uno de los entregables clave para una cadena de suministro cuantitativa es una receta numérica central que calcula las decisiones finales de la cadena de suministro. Este aspecto ya se discutió en la Lección 1.3 en el primer capítulo, “Entrega orientada al producto para la cadena de suministro”. Vamos a revisar las dos propiedades más críticas de este entregable.
Primero, la salida debe ser una decisión. Por ejemplo, decidir cuántas unidades reordenar hoy para un determinado SKU es una decisión. Por el contrario, pronosticar cuántas unidades se solicitarán hoy para un determinado SKU es un artefacto numérico. Para generar una decisión que sea el resultado final, se necesitan muchos resultados intermedios, es decir, muchos artefactos numéricos. Sin embargo, no debemos confundir los medios con el fin.
La segunda propiedad de este entregable es que la salida, que es una decisión, debe estar completamente automatizada como resultado de un proceso de software puramente automatizado. La receta numérica en sí misma, la receta numérica central, no debe implicar ninguna operación manual. Naturalmente, el diseño de la receta numérica en sí probablemente dependa en gran medida de un experto humano en ciencia. Sin embargo, la ejecución no debe depender de la intervención humana directa.
Tener una receta numérica como entregable es esencial para convertir la iniciativa de la cadena de suministro en un emprendimiento capitalista. La receta numérica se convierte en un activo productivo que genera retornos. La receta debe mantenerse, pero esto requiere una o dos órdenes de magnitud menos personas en comparación con enfoques que mantienen a los humanos en el ciclo de decisiones a nivel micro.
Sin embargo, muchas iniciativas de cadena de suministro fracasan porque no enmarcan correctamente las decisiones de la cadena de suministro como el resultado de la iniciativa. En cambio, esas iniciativas se centran en entregar artefactos numéricos. Los artefactos numéricos están destinados a ser ingredientes para llegar a la resolución final del problema, típicamente apoyando las propias decisiones. Los artefactos más comunes encontrados en la cadena de suministro son pronósticos, existencias de seguridad, EOQs, KPIs. Si bien esos números pueden ser de interés, no son reales. Esos números no tienen un contraparte física tangible inmediata en la cadena de suministro y reflejan perspectivas de modelado arbitrarias sobre la cadena de suministro.
Centrarse en los artefactos numéricos conduce al fracaso de la iniciativa porque esos números carecen de un ingrediente crítico: la retroalimentación directa del mundo real. Cuando la decisión es incorrecta, las malas consecuencias se pueden atribuir a la decisión. Sin embargo, la situación es mucho más ambigua en lo que respecta a los artefactos numéricos. De hecho, la responsabilidad se diluye por todas partes, ya que hay muchos artefactos que contribuyen a cada decisión individual. El problema es aún peor cuando hay intervención humana en el medio.
Esta falta de retroalimentación resulta mortal para los artefactos numéricos. Las cadenas de suministro modernas son complejas. Elija cualquier fórmula arbitraria para calcular una existencia de seguridad, una cantidad económica de pedido o un KPI; hay probabilidades abrumadoras de que esta fórmula sea incorrecta de muchas maneras. El problema de la corrección de la fórmula no es un problema matemático; es un problema empresarial. Se trata de responder a la pregunta: “¿Esta calculación refleja verdaderamente la intención estratégica que tengo para mi negocio?” La respuesta varía de una empresa a otra e incluso varía de un año a otro a medida que las empresas evolucionan con el tiempo.
Como los artefactos numéricos carecen de retroalimentación directa del mundo real, carecen del mecanismo mismo que permite iterar desde una implementación inicial ingenua, simplista y muy probablemente incorrecta hacia una versión aproximadamente correcta de la fórmula que podría considerarse de calidad de producción. Sin embargo, los artefactos numéricos son muy tentadores porque dan la ilusión de acercarse a la solución. Dan la ilusión de ser racionales, científicos, incluso emprendedores. Tenemos números, fórmulas, algoritmos, modelos. Incluso es posible hacer comparaciones y comparar esos números con números igualmente inventados. Mejorar en comparación con un punto de referencia inventado también da una ilusión de progreso y es muy reconfortante. Pero al final del día, sigue siendo una ilusión, una cuestión de perspectiva de modelado.
Las empresas no obtienen ganancias pagando a las personas para que miren KPIs o hagan comparaciones. Obtienen ganancias tomando una decisión tras otra y, con suerte, mejorando en la toma de la próxima decisión cada vez.
Esta conferencia es parte de una serie de conferencias sobre la cadena de suministro. Estoy tratando de mantener estas conferencias algo independientes, pero hemos llegado a un punto en el que tiene más sentido ver estas conferencias en secuencia. Esta conferencia es la primera conferencia del séptimo capítulo, que está dedicado a la ejecución de iniciativas de cadena de suministro. Con iniciativas de cadena de suministro, me refiero a iniciativas cuantitativas de cadena de suministro, iniciativas que tienen la intención de ofrecer algo en el orden de la optimización predictiva para la empresa.
El primer capítulo estuvo dedicado a mis puntos de vista sobre la cadena de suministro tanto como campo de estudio como práctica. En el segundo capítulo, presenté una serie de metodologías esenciales para la cadena de suministro, ya que las metodologías ingenuas son derrotadas debido a la naturaleza adversaria de muchas situaciones de cadena de suministro. En el tercer capítulo, presenté una serie de personajes de la cadena de suministro con un enfoque puramente en los problemas; en otras palabras, ¿qué es lo que estamos tratando de resolver?
En el cuarto capítulo, presenté una serie de campos que, aunque no son propiamente de la cadena de suministro, creo que son esenciales para una práctica moderna de la cadena de suministro. En los capítulos quinto y sexto, presenté los elementos inteligentes de una receta numérica destinada a impulsar las decisiones de la cadena de suministro, es decir, la optimización predictiva (la perspectiva generalizada de la previsión) y la toma de decisiones (esencialmente la optimización matemática aplicada a los problemas de la cadena de suministro). En este séptimo capítulo, discutimos cómo juntar esos elementos en una iniciativa real de cadena de suministro que pretende llevar estos métodos y tecnologías a la producción.
Hoy revisaremos lo que se considera como la práctica correcta para llevar a cabo una iniciativa de cadena de suministro. Esto incluye enmarcar la iniciativa con el entregable adecuado, que acabamos de discutir, pero también con el cronograma adecuado, el alcance adecuado y los roles adecuados. Estos elementos representan la primera parte de la conferencia de hoy.
La segunda parte de la conferencia estará dedicada al pipeline de datos, un ingrediente crítico para el éxito de una iniciativa impulsada por datos o dependiente de datos. Si bien el pipeline de datos es un tema bastante técnico, requiere una división adecuada del trabajo y la organización entre TI y cadena de suministro. En particular, veremos que los controles de calidad deben estar principalmente en manos de la cadena de suministro, con el diseño de informes de salud de datos e inspectores de datos.
El proceso de incorporación es la primera fase de la iniciativa, donde se crea la receta numérica central, aquella que genera la decisión junto con solo elementos de apoyo. El proceso de incorporación termina con una implementación progresiva en producción, y durante esta implementación, los procesos anteriores se automatizan gradualmente mediante la propia receta numérica.
Al considerar el cronograma adecuado para la primera iniciativa cuantitativa de la cadena de suministro en una empresa, uno podría pensar que depende del tamaño de la empresa, la complejidad, el tipo de decisiones de la cadena de suministro y el contexto general. Si bien esto es cierto hasta cierto punto, la experiencia que Lokad ha recopilado durante más de una década y docenas de tales iniciativas indica que seis meses es casi invariablemente el cronograma adecuado. Sorprendentemente, este cronograma de seis meses tiene poco que ver con la tecnología o incluso con los detalles de la cadena de suministro; tiene mucho más que ver con las personas y las organizaciones mismas y el tiempo que les lleva sentirse cómodos con lo que generalmente se percibe como una forma muy diferente de llevar a cabo la cadena de suministro.
Los primeros dos meses están dedicados a la configuración del pipeline de datos. Volveremos a este punto en unos minutos, pero este retraso de dos meses se debe a dos factores. En primer lugar, necesitamos que el pipeline de datos sea confiable y eliminar problemas poco frecuentes que pueden tardar semanas en manifestarse. El segundo factor es que necesitamos comprender la semántica de los datos, es decir, entender lo que significan los datos desde una perspectiva de cadena de suministro.
Los meses tres y cuatro están dedicados a la iteración rápida sobre la receta numérica en sí, que impulsará las decisiones de la cadena de suministro. Estas iteraciones son necesarias porque generar decisiones finales reales es generalmente la única forma de evaluar si hay algo mal o no con la receta subyacente o con todas las suposiciones incorporadas en la receta. Estos dos meses también suelen ser el tiempo que lleva a los profesionales de la cadena de suministro acostumbrarse a la perspectiva cuantitativa y financiera que impulsa estas decisiones impulsadas por software.
Por último, los últimos dos meses están dedicados a la estabilización de la receta numérica después de lo que suele ser un período relativamente intenso de rápida iteración. Este período también es una oportunidad para que la receta se ejecute en un entorno similar a la producción, pero aún no conduciendo la producción. Esta fase es importante para que los equipos de la cadena de suministro confíen en esta solución emergente.
Si bien podría ser deseable comprimir aún más este cronograma, resulta que generalmente es muy difícil. La configuración del pipeline de datos se puede acelerar hasta cierto punto si la infraestructura de TI adecuada ya está en su lugar, pero familiarizarse con los datos lleva tiempo para comprender lo que significan los datos desde una perspectiva de cadena de suministro. En la segunda fase, si la iteración sobre la receta numérica converge muy rápidamente, es probable que los equipos de la cadena de suministro comiencen a explorar los matices de la receta numérica, lo que también extenderá el retraso. Por último, los últimos dos meses son típicamente lo que se necesita para ver cómo se desarrolla la estacionalidad y ganar confianza en el software que impulsa decisiones importantes de la cadena de suministro en producción.
En resumen, lleva aproximadamente seis meses, y aunque sería deseable comprimirlo aún más, es un desafío hacerlo. Sin embargo, seis meses ya es un período considerable. Si desde el primer día, el período de incorporación, donde la receta numérica aún no está impulsando las decisiones de la cadena de suministro, se espera que dure más de seis meses, entonces la iniciativa ya está en riesgo. Si el retraso adicional está asociado con la extracción de datos y la configuración del pipeline de datos, entonces hay un problema de TI. Si el retraso adicional está asociado con el diseño o configuración de la solución, posiblemente proporcionada por un proveedor externo, entonces hay un problema con la tecnología en sí. Por último, si después de dos meses de ejecución establecida similar a la producción, no se realiza la implementación en producción, entonces generalmente hay un problema con la gestión de la iniciativa.
Al intentar introducir una novedad, un nuevo proceso o una nueva tecnología en una organización, la sabiduría común sugiere comenzar de manera pequeña, asegurándose de que funcione y construyendo sobre el éxito inicial para expandirse gradualmente. Desafortunadamente, la cadena de suministro no es amigable con la sabiduría común, y esta perspectiva viene con un giro específico en lo que respecta al alcance de la cadena de suministro. En términos de alcance, hay dos fuerzas principales que definen en gran medida qué es y qué no es un alcance elegible en lo que respecta a una iniciativa de cadena de suministro.
El panorama aplicativo es la primera fuerza que impacta en el alcance. Una cadena de suministro en su conjunto no se puede observar directamente; solo se puede observar indirectamente a través de los lentes del software empresarial. Los datos se obtendrán a través de estos programas. La complejidad de la iniciativa depende en gran medida del número y la diversidad de estos programas de software. Cada aplicación es su propia fuente de datos, y extraer y analizar los datos de cualquier aplicación comercial tiende a ser una tarea importante. Lidiar con más aplicaciones generalmente implica lidiar con múltiples tecnologías de bases de datos, terminologías inconsistentes, conceptos inconsistentes y complicar en gran medida la situación.
Por lo tanto, al establecer el alcance, debemos reconocer que las fronteras elegibles generalmente están definidas por las propias aplicaciones comerciales y su estructura de base de datos. En este contexto, comenzar de manera pequeña debe entenderse como mantener la huella inicial de integración de datos lo más pequeña posible mientras se preserva la integridad de la iniciativa de cadena de suministro en su conjunto. Es mejor profundizar en lugar de ampliar en términos de integración de aplicaciones. Una vez que tenga el sistema de TI en su lugar para obtener algunos registros de una tabla en una aplicación determinada, generalmente es sencillo obtener todos los registros de esta tabla y todos los registros de otra tabla en la misma aplicación.
Un error común en el alcance consiste en el muestreo. El muestreo generalmente se logra mediante la selección de una lista corta de categorías de productos, sitios o proveedores. El muestreo es bien intencionado, pero no sigue los límites definidos por el panorama aplicativo. Para implementar el muestreo, se deben aplicar filtros durante la extracción de datos, y este proceso crea una serie de problemas que probablemente pongan en peligro la iniciativa de cadena de suministro.
En primer lugar, una extracción de datos filtrada de un software empresarial requiere más esfuerzo por parte del equipo de TI en comparación con una extracción no filtrada. Los filtros deben ser diseñados en primer lugar, y el proceso de filtrado en sí mismo es propenso a errores. Depurar filtros incorrectos es invariablemente tedioso porque requiere numerosos intercambios con los equipos de TI, lo que ralentizará la iniciativa y, a su vez, la pondrá en peligro.
En segundo lugar, permitir que la iniciativa realice su incorporación en una muestra de datos es una receta para problemas masivos de rendimiento del software a medida que la iniciativa se expande más tarde hacia el alcance completo. La falta de escalabilidad, o la incapacidad para procesar una gran cantidad de datos manteniendo los costos informáticos bajo control, es un defecto muy frecuente en el software. Al permitir que la iniciativa opere sobre una muestra, los problemas de escalabilidad se enmascaran pero volverán con fuerza en una etapa posterior.
Operar sobre una muestra de datos dificulta las estadísticas, no las facilita. De hecho, tener acceso a más datos es probablemente la forma más fácil de mejorar la precisión y estabilidad de casi todos los algoritmos de aprendizaje automático. El muestreo de los datos va en contra de esta idea. Por lo tanto, al usar una pequeña muestra de datos, la iniciativa puede fallar debido a comportamientos numéricos erráticos observados en la muestra. Estos comportamientos se habrían mitigado en gran medida si se hubiera utilizado todo el conjunto de datos en su lugar.
Los efectos del sistema son la segunda fuerza que afecta al alcance. Una cadena de suministro es un sistema y todas sus partes están acopladas en cierta medida. El desafío con los sistemas, cualquier sistema, es que los intentos de mejorar una parte del sistema tienden a desplazar los problemas en lugar de solucionarlos. Por ejemplo, consideremos un problema de asignación de inventario para una red minorista con un centro de distribución y muchas tiendas. Si elegimos una sola tienda como el alcance inicial para nuestro problema de asignación de inventario, es trivial asegurarse de que esta tienda obtendrá una calidad de servicio muy alta del centro de distribución al reservar inventario para ella con anticipación. Al hacer eso, podemos asegurarnos de que el centro de distribución nunca se quede sin stock mientras atiende a esta tienda. Sin embargo, esta reserva de stock se haría a expensas de la calidad de servicio para las otras tiendas de la red.
Por lo tanto, al considerar un alcance para una iniciativa de cadena de suministro, debemos tener en cuenta los efectos del sistema. El alcance debe diseñarse de manera que evite en gran medida realizar una optimización local a expensas de los elementos que están fuera del alcance. Esta parte del ejercicio de alcance es difícil porque todos los alcances tienen fugas en cierta medida. Por ejemplo, todas las partes de la cadena de suministro compiten en última instancia por la misma cantidad de efectivo disponible a nivel de la empresa. Cada dólar asignado en algún lugar es un dólar que no estará disponible para otros fines. Sin embargo, ciertos alcances son mucho más fáciles de manipular que otros. Es importante elegir un alcance que tienda a mitigar los efectos del sistema en lugar de magnificarlos.
Pensar en el alcance de una iniciativa de cadena de suministro en términos de efectos del sistema puede parecer extraño para muchos profesionales de la cadena de suministro. Cuando se trata de alcance, la mayoría de las empresas tienden a proyectar su organización interna en el ejercicio de alcance. Por lo tanto, los límites elegidos para el alcance tienden inevitablemente a imitar los límites de la división del trabajo dentro de la empresa. Este patrón se conoce como la Ley de Conway. Propuesta por Melvin Conway hace medio siglo para sistemas de comunicación, la ley desde entonces se ha encontrado que tiene una aplicabilidad mucho más amplia, incluida una relevancia primordial para la gestión de la cadena de suministro.
Los límites y silos que dominan las cadenas de suministro actuales están impulsados por divisiones del trabajo que son consecuencia de procesos bastante manuales para tomar decisiones de cadena de suministro. Por ejemplo, si una empresa determina que un planificador de oferta y demanda no puede gestionar más de 1,000 SKU y la empresa tiene 50,000 SKU en total para gestionar, la empresa necesitará 50 planificadores de oferta y demanda para hacerlo. Sin embargo, dividir la optimización de la cadena de suministro entre 50 pares de manos está garantizado para introducir muchas ineficiencias a nivel de la empresa.
Por el contrario, una iniciativa que automatiza estas decisiones no necesita adaptarse a esos límites que solo reflejan una división del trabajo obsoleta o próxima a ser obsoleta. Una receta numérica puede optimizar esos 50,000 SKU a la vez y eliminar las ineficiencias que resultan de tener docenas de silos enfrentados entre sí. Por lo tanto, es natural que una iniciativa que pretende automatizar en gran medida estas decisiones se superponga con muchos límites preexistentes en la empresa. La empresa, o en realidad la dirección de la empresa, debe resistir la tentación de imitar los límites organizativos existentes, especialmente a nivel de alcance, ya que tiende a marcar el tono para lo que sigue.
Las cadenas de suministro son complejas en términos de hardware, software y personas. Si bien es desafortunado, iniciar una iniciativa de cadena de suministro cuantitativa aumenta aún más la complejidad de la cadena de suministro, al menos inicialmente. A largo plazo, puede disminuir sustancialmente la complejidad de la cadena de suministro, pero probablemente lo veremos en una conferencia posterior. Además, cuantas más personas estén involucradas en la iniciativa, mayor será la complejidad de la iniciativa en sí. Si esta complejidad adicional no se controla de inmediato, es probable que la iniciativa colapse debido a su propia complejidad.
Por lo tanto, al pensar en los roles de la iniciativa, es decir, quién hará qué, debemos pensar en el conjunto más pequeño posible de roles que hagan viable la iniciativa. Al minimizar el número de roles, minimizamos la complejidad de la iniciativa, lo que a su vez mejora en gran medida las posibilidades de éxito. Esta perspectiva tiende a ser contraintuitiva para las grandes empresas que adoran operar con una división del trabajo extremadamente detallada. Las grandes empresas tienden a favorecer a especialistas extremos que hacen una sola cosa. Sin embargo, una cadena de suministro es un sistema y, como todos los sistemas, es la perspectiva de extremo a extremo la que importa.
Basándonos en la experiencia adquirida en Lokad al llevar a cabo este tipo de iniciativas, hemos identificado cuatro roles que generalmente representan la división mínima de trabajo viable para llevar a cabo la iniciativa: un ejecutivo de cadena de suministro, un oficial de datos, un científico de cadena de suministro y un practicante de cadena de suministro.
El papel del ejecutivo de cadena de suministro es apoyar la iniciativa para que pueda tener lugar en primer lugar. Obtener una receta numérica bien diseñada para impulsar las decisiones de la cadena de suministro en producción representa un impulso masivo tanto en términos de rentabilidad como de productividad. Sin embargo, también es mucho cambio para asimilar. Se requiere mucha energía y apoyo de la alta dirección para que un cambio de este tipo ocurra en una organización grande.
El papel del oficial de datos es configurar y mantener el flujo de datos. La mayor parte de sus contribuciones se espera que ocurran en los primeros dos meses de la iniciativa. Si el flujo de datos está correctamente diseñado, hay muy poco esfuerzo continuo para el oficial de datos después. El oficial de datos generalmente no participa mucho en las etapas posteriores de la iniciativa.
El papel del científico de cadena de suministro es diseñar la receta numérica central. Este papel parte de los datos transaccionales en bruto disponibles por el oficial de datos. No se espera ninguna preparación de datos por parte del oficial de datos, solo extracción de datos. El papel del científico de cadena de suministro termina al hacerse cargo de la decisión de la cadena de suministro generada. No es un software el responsable de la decisión; es el científico de cadena de suministro. Para cada decisión generada, el científico mismo debe poder justificar por qué esta decisión es adecuada.
Finalmente, el papel del practicante de cadena de suministro es desafiar las decisiones generadas por la receta numérica y proporcionar comentarios al científico de cadena de suministro. El practicante no tiene esperanzas de tomar la decisión. Esta persona generalmente ha estado a cargo de esas decisiones hasta ahora, al menos para un subámbito, y generalmente con la ayuda de hojas de cálculo y sistemas establecidos. En una empresa pequeña, es posible que una persona cumpla tanto el papel de ejecutivo de cadena de suministro como el de practicante de cadena de suministro. También es posible evitar la necesidad de un oficial de datos si los datos están fácilmente accesibles. Esto puede suceder en empresas que son muy maduras en cuanto a su infraestructura de datos. Por el contrario, si la empresa es muy grande, es posible que haya algunas, pero solo unas pocas, personas que ocupen cada rol.
La implementación exitosa en producción de la receta numérica central tiene un gran impacto en el mundo del practicante de cadena de suministro. De hecho, en gran medida, el objetivo de la iniciativa es automatizar el trabajo anterior del practicante de cadena de suministro. Sin embargo, esto no implica que la mejor opción sea despedir a esos practicantes una vez que la receta numérica esté en producción. Volveremos a visitar este aspecto específico en la próxima conferencia.
Ser organizado no significa ser eficiente o efectivo. Hay roles que, a pesar de tener buenas intenciones, añaden fricción a las iniciativas de la cadena de suministro, frecuentemente hasta el punto de hacer que fracasen por completo. Hoy en día, el primer rol que contribuye más a hacer que estas iniciativas fracasen tiende a ser el rol del científico de datos, y aún más cuando está involucrado todo un equipo de ciencia de datos. Por cierto, Lokad aprendió esto de la peor manera hace aproximadamente una década.
A pesar de la similitud en el nombre entre científicos de datos y científicos de cadena de suministro, los dos roles son en realidad muy diferentes. El científico de cadena de suministro se preocupa principalmente por ofrecer decisiones de calidad de producción del mundo real. Si esto se puede lograr con una receta numérica semi-trivial, aún mejor; el mantenimiento será pan comido. El científico de cadena de suministro asume toda la responsabilidad de lidiar con los detalles más mínimos de la cadena de suministro. La confiabilidad y la resiliencia al caos ambiental importan más que la sofisticación.
Por el contrario, el científico de datos se enfoca en las partes inteligentes de la receta numérica, los modelos y los algoritmos. El científico de datos, en términos generales, se percibe a sí mismo como un experto en aprendizaje automático y optimización matemática. En cuanto a tecnologías, un científico de datos está dispuesto a aprender el último conjunto de herramientas numéricas de código abierto de vanguardia, pero generalmente no está dispuesto a aprender sobre el ERP de tres décadas de antigüedad que sucede que ejecuta la empresa. Además, el científico de datos no es un experto en cadena de suministro, ni suele estar dispuesto a convertirse en uno. El científico de datos intenta ofrecer los mejores resultados según las métricas acordadas. El científico no tiene ambición de lidiar con los detalles muy mundanos de la cadena de suministro; se espera que otras personas se encarguen de esos elementos.
Involucrar a científicos de datos condena estas iniciativas porque, tan pronto como los científicos de datos están involucrados, la cadena de suministro deja de ser el enfoque principal: los algoritmos y los modelos lo son. Nunca subestimes el poder de distracción que el último modelo o algoritmo representa para una persona inteligente y orientada a la tecnología.
El segundo rol que tiende a añadir fricción a una iniciativa de cadena de suministro es el equipo de inteligencia de negocios (BI, por sus siglas en inglés). Cuando el equipo de BI forma parte de la iniciativa, tiende a ser un obstáculo más que cualquier otra cosa, aunque en menor medida que el equipo de ciencia de datos. El problema con BI es principalmente cultural. BI ofrece informes, no decisiones. El equipo de BI generalmente está dispuesto a producir interminables informes de métricas según lo solicitado por cada división de la empresa. Esta no es la actitud correcta para una iniciativa cuantitativa de cadena de suministro.
Además, la inteligencia de negocios como software es una clase muy específica de análisis de datos orientada a cubos o cubos OLAP que permiten analizar la mayoría de los sistemas en memoria en sistemas empresariales. Este diseño generalmente no es adecuado para impulsar decisiones de cadena de suministro.
Ahora que hemos enmarcado la iniciativa, echemos un vistazo a la arquitectura de TI de alto nivel que requiere la iniciativa.
El esquema en la pantalla ilustra una configuración típica de canalización de datos para una iniciativa de cadena de suministro cuantitativa. En esta conferencia, estoy discutiendo una canalización de datos que no admite requisitos de baja latencia. Queremos poder completar un ciclo completo en aproximadamente una hora, no en un segundo. La mayoría de las decisiones de la cadena de suministro, como las órdenes de compra, no requieren una configuración de baja latencia. Lograr una baja latencia de extremo a extremo requiere un tipo diferente de arquitectura, que está más allá del alcance de la conferencia de hoy.
Los sistemas de transacciones representan la fuente de datos principal y el punto de partida de la canalización de datos. Estos sistemas incluyen el ERP, WMS y EDI. Se ocupan del flujo de bienes como compras, transporte, producción y venta. Estos sistemas contienen casi todos los datos que requiere la receta numérica principal. Para casi cualquier empresa de tamaño considerable, estos sistemas o sus predecesores han estado en funcionamiento durante al menos dos décadas.
Dado que estos sistemas contienen casi todos los datos que necesitamos, sería tentador implementar la receta numérica directamente en estos sistemas. De hecho, ¿por qué no? Al colocar la receta numérica directamente en el ERP, eliminaríamos la necesidad de pasar por el esfuerzo de configurar toda esta canalización de datos. Desafortunadamente, esto no funciona debido al diseño mismo de esos sistemas transaccionales.
Estos sistemas de transacciones están inevitablemente construidos con una base de datos transaccional en su núcleo. Este enfoque para el diseño de software empresarial ha sido extremadamente estable durante las últimas cuatro décadas. Elija una empresa al azar y lo más probable es que todas las aplicaciones comerciales en producción se hayan implementado sobre una base de datos transaccional. Las bases de datos transaccionales ofrecen cuatro propiedades clave que se conocen con el acrónimo ACID, que significa Atomicidad, Consistencia, Aislamiento y Durabilidad. No voy a entrar en los detalles de esas propiedades, pero basta decir que estas propiedades hacen que la base de datos sea muy adecuada para realizar de manera segura y concurrente muchas operaciones de lectura pequeñas y muchas operaciones de escritura pequeñas. También se espera que las cantidades respectivas de operaciones de lectura y operaciones de escritura estén bastante equilibradas.
Sin embargo, el precio a pagar por esas propiedades ACID muy útiles a nivel más granular es que la base de datos transaccional también es muy ineficiente cuando se trata de atender grandes operaciones de lectura. Una operación de lectura que cubre una parte considerable de toda la base de datos, como regla general, si los datos se prestan a través de una base de datos que se centra en una entrega muy granular de esas propiedades ACID, entonces se puede esperar que el costo de los recursos informáticos se inflen en un factor de 100 en comparación con las arquitecturas que no se centran tanto en esas propiedades ACID a nivel tan granular. ACID es bueno, pero tiene un costo muy alto.
Además, cuando alguien intenta leer una parte considerable de toda la base de datos, es probable que la base de datos se vuelva irresponsiva durante un tiempo, ya que dedica la mayor parte de sus recursos a atender esta gran solicitud. Muchas empresas se quejan de que sus sistemas comerciales completos son lentos y que esos sistemas se congelen con frecuencia durante un segundo o más. Por lo general, esta mala calidad de servicio se puede atribuir a consultas SQL pesadas que intentan leer demasiadas líneas a la vez.
Por lo tanto, la receta numérica principal no puede operar en el mismo entorno que los sistemas transaccionales que admiten la producción. De hecho, la receta numérica deberá acceder a la mayoría de los datos cada vez que se ejecute. Por lo tanto, la receta numérica debe mantenerse estrictamente aislada en su propio subsistema, si solo para evitar degradar aún más el rendimiento de esos sistemas transaccionales.
Por cierto, aunque se sabe desde hace décadas que es una idea terrible tener un proceso intensivo en datos que opere dentro de un sistema transaccional, esto no impide que la mayoría de los proveedores de sistemas transaccionales (ERP, MRP, WMS) vendan módulos analíticos integrados, por ejemplo, módulos de optimización de inventario. La integración de estos módulos inevitablemente conduce a problemas de calidad de servicio al tiempo que ofrece capacidades decepcionantes. Todos estos problemas se pueden atribuir a este único problema de diseño: el sistema transaccional y el sistema analítico deben mantenerse en estricto aislamiento.
El data lake es simple. Es un espejo de los datos transaccionales orientado a operaciones de lectura muy grandes. De hecho, hemos visto que los sistemas transaccionales están optimizados para muchas operaciones de lectura pequeñas, no para operaciones muy grandes. Por lo tanto, para preservar la calidad de servicio del sistema transaccional, el diseño correcto consiste en replicar cuidadosamente los datos transaccionales en otro sistema, es decir, el data lake. Esta replicación debe implementarse con cuidado, precisamente para preservar la calidad de servicio del sistema transaccional, lo que generalmente significa leer los datos de manera muy incremental y evitar ejercer presión sobre el sistema transaccional.
Una vez que los datos transaccionales relevantes se reflejan en el data lake, el data lake en sí mismo sirve todas las solicitudes de datos. Un beneficio adicional del data lake es su capacidad para servir a múltiples sistemas analíticos. Si bien estamos discutiendo la cadena de suministro aquí, si el marketing desea sus propios análisis, necesitarán estos mismos datos transaccionales, y lo mismo podría decirse para finanzas, ventas, etc. Por lo tanto, en lugar de que cada departamento de la empresa implemente su propio mecanismo de extracción de datos, tiene sentido consolidar todas esas extracciones en el mismo data lake, el mismo sistema.
A nivel técnico, un data lake se puede implementar con una base de datos relacional, típicamente ajustada para la extracción de big data, adoptando un almacenamiento de datos columnar. Los data lakes también se pueden implementar como un repositorio de archivos planos servidos sobre un sistema de archivos distribuido. En comparación con un sistema transaccional, un data lake renuncia a las propiedades transaccionales de granularidad fina. El objetivo es servir una gran cantidad de datos de la manera más económica y confiable posible, nada más y nada menos.
El data lake debe reflejar los datos transaccionales originales, lo que significa copiar sin modificar nada. Es importante no preparar los datos en el data lake. Desafortunadamente, el equipo de TI a cargo de configurar el data lake puede verse tentado a facilitar y simplificar las cosas para otros equipos y, por lo tanto, preparar un poco los datos. Sin embargo, modificar los datos inevitablemente introduce complicaciones que socavan el análisis en una etapa posterior. Además, ceñirse a una estricta política de reflejo disminuye enormemente la cantidad de esfuerzo necesario para que el equipo de TI configure y mantenga posteriormente el data lake.
En las empresas donde ya existe un equipo de BI, puede ser tentador utilizar los sistemas de BI como un data lake. Sin embargo, recomiendo enfáticamente no hacerlo y nunca utilizar una configuración de BI como un data lake. De hecho, los datos en los sistemas de BI (sistemas de inteligencia empresarial) están inevitablemente muy transformados. Aprovechar los datos de BI para impulsar decisiones automatizadas de la cadena de suministro es una receta para problemas de basura de entrada, basura de salida. El data lake solo debe alimentarse de fuentes de datos primarias como ERP, no de fuentes de datos secundarias como el sistema de BI.
El sistema analítico es aquel que contiene la receta numérica principal. También es el sistema que proporciona todos los informes necesarios para instrumentar las propias decisiones. A nivel técnico, el sistema analítico contiene los “elementos inteligentes”, como los algoritmos de aprendizaje automático y los algoritmos de optimización matemática. Aunque en la práctica, esos elementos inteligentes no dominan el código base de los sistemas analíticos. Por lo general, la preparación de datos y la instrumentación de datos requieren al menos diez veces más líneas de código que las partes que se ocupan del aprendizaje y la optimización.
El sistema analítico debe estar desacoplado del data lake porque estos dos sistemas están completamente en desacuerdo en términos de perspectivas tecnológicas. Como pieza de software, se espera que el data lake sea muy simple, muy estable y extremadamente confiable. Por el contrario, se espera que el sistema analítico sea sofisticado, esté en constante evolución y sea extremadamente eficiente en términos de rendimiento de la cadena de suministro. A diferencia del data lake, que debe ofrecer un tiempo de actividad casi perfecto, el sistema analítico ni siquiera tiene que estar en funcionamiento la mayor parte del tiempo. Por ejemplo, si estamos considerando decisiones diarias de reposición de inventario, entonces el sistema analítico solo tiene que ejecutarse y estar en funcionamiento una vez al día.
Como regla general, es mejor que el sistema analítico falle en la producción de decisiones en lugar de generar decisiones incorrectas y permitir que fluyan hacia la producción. Retrasar las decisiones de la cadena de suministro unas horas, como las órdenes de compra, suele ser mucho menos grave que tomar decisiones incorrectas. Como el diseño del sistema analítico tiende a estar fuertemente influenciado por los elementos inteligentes que contiene, no necesariamente hay mucho que decir en general sobre el diseño del sistema analítico. Sin embargo, hay al menos una propiedad de diseño clave que se debe aplicar al ecosistema: este sistema debe ser sin estado.
El sistema analítico debe evitar tener un estado interno en la mayor medida posible. En otras palabras, todo el ecosistema debe comenzar con los datos tal como se presentan por el data lake y terminar con las decisiones de la cadena de suministro generadas, junto con los informes de apoyo. Lo que a menudo sucede es que cuando hay un componente dentro del sistema analítico que es demasiado lento, como un algoritmo de aprendizaje automático, es tentador introducir un estado, es decir, persistir alguna información de la ejecución anterior para acelerar la siguiente ejecución. Sin embargo, hacerlo, confiar en resultados previamente calculados en lugar de volver a calcular todo desde cero cada vez, es peligroso.
De hecho, tener un estado dentro del sistema analítico pone en riesgo la decisión. Si bien los problemas de datos inevitablemente surgirán y se solucionarán a nivel del data lake, el sistema analítico aún puede devolver decisiones que reflejen un problema que ya se ha solucionado. Por ejemplo, si se entrena un modelo de pronóstico de demanda en un conjunto de datos de ventas corrupto, entonces el modelo de pronóstico seguirá siendo corrupto hasta que se vuelva a entrenar sobre una versión fresca y corregida del conjunto de datos. La única forma de evitar que el sistema analítico sufra ecos de problemas de datos que ya se han solucionado en el data lake es actualizar todo cada vez. Esa es la esencia de ser sin estado.
Como regla general, si una parte del sistema analítico resulta ser demasiado lenta para reemplazarse diariamente, entonces esta parte debe considerarse como sufriendo un problema de rendimiento. Las cadenas de suministro son caóticas y llegará un día en que suceda algo: un incendio, un cierre, un ciberataque, que requerirá una intervención inmediata. La empresa debe ser capaz de actualizar todas sus decisiones de cadena de suministro en una hora. La empresa no debe esperar y quedarse atascada durante 10 horas mientras se lleva a cabo la fase lenta de entrenamiento de aprendizaje automático.
Para operar de manera confiable, el sistema analítico debe estar correctamente instrumentado. Eso es lo que se trata el informe de salud de los datos y los inspectores de datos. Por cierto, todos esos elementos son responsabilidad de la cadena de suministro; no son responsabilidad de TI. El monitoreo de la salud de los datos representa la primera fase de procesamiento de datos, incluso antes de la preparación de los datos en sí, y ocurre dentro del sistema analítico. La salud de los datos es parte de la instrumentación de la receta numérica. El informe de salud de los datos indica si es aceptable o no ejecutar la receta numérica en absoluto. Este informe también señala el origen del problema de los datos, si lo hay, para acelerar la resolución del problema.
El monitoreo de la salud de los datos es una práctica en Lokad. Durante la última década, esta práctica ha demostrado ser invaluable para evitar situaciones de “basura adentro, basura afuera” que parecen ser ubicuas en el mundo del software empresarial. De hecho, cuando una iniciativa de procesamiento de datos falla, a menudo se culpa a los datos incorrectos. Sin embargo, es importante tener en cuenta que generalmente no hay casi ningún esfuerzo de ingeniería para garantizar la calidad de los datos en primer lugar. La calidad de los datos no cae del cielo; requiere esfuerzos de ingeniería.
El pipeline de datos que se ha presentado hasta ahora es bastante minimalista. La replicación de datos es tan simple como puede ser, lo cual es algo bueno en cuanto a la calidad del software se refiere. Sin embargo, a pesar de este minimalismo, todavía hay muchas partes móviles: muchas tablas, muchos sistemas, muchas personas. Por lo tanto, hay errores por todas partes. Este es un software empresarial y lo contrario sería bastante sorprendente. El monitoreo de la salud de los datos está en su lugar para ayudar al sistema analítico a sobrevivir al caos ambiental.
No se debe confundir la salud de los datos con la limpieza de datos. La salud de los datos se trata únicamente de asegurarse de que los datos disponibles para el sistema analítico sean una representación fiel de los datos transaccionales que existen en los sistemas de transacciones. No se intenta corregir los datos; los datos se analizan tal como están.
En Lokad, generalmente distinguimos entre la salud de los datos a nivel bajo y la salud de los datos a nivel alto. La salud de los datos a nivel bajo es un tablero de control que consolida todas las peculiaridades estructurales y volumétricas de los datos, como problemas obvios como entradas que ni siquiera son fechas o números razonables, por ejemplo, o identificadores huérfanos que no tienen sus contrapartes esperadas. Todos estos problemas se pueden ver y son realmente los más fáciles. El problema difícil comienza con los problemas que no se pueden ver porque los datos faltan en primer lugar. Por ejemplo, si algo salió mal con una extracción de datos y los datos de ventas extraídos de ayer solo contienen la mitad de las líneas esperadas, realmente puede poner en peligro la producción. Los datos incompletos son particularmente insidiosos porque generalmente no evitarán que la receta numérica genere decisiones, excepto que esas decisiones serán basura, ya que los datos de entrada están incompletos.
Técnicamente, en Lokad, tratamos de mantener el monitoreo de la salud de los datos en un solo tablero de control, y este tablero de control está destinado típicamente al equipo de TI, ya que la mayoría de los problemas capturados por la salud de los datos a nivel bajo tienden a estar relacionados con el pipeline de datos en sí. Idealmente, el equipo de TI debería poder ver de un vistazo si todo está bien o no y si no se requiere ninguna intervención adicional.
El monitoreo de la salud de los datos a nivel alto considera todas las peculiaridades a nivel empresarial, elementos que parecen incorrectos cuando se observan desde una perspectiva empresarial. La salud de los datos a nivel alto cubre elementos como niveles de stock negativos o cantidades mínimas de pedido anormalmente grandes. También cubre cosas como precios que no tienen sentido porque la empresa estaría operando con pérdidas o con márgenes ridículamente altos. La salud de los datos a nivel alto intenta cubrir todos los elementos donde un profesional de la cadena de suministro miraría los datos y diría: “No puede ser correcto; tenemos un problema”.
A diferencia del informe de salud de datos a nivel bajo, el informe de salud de datos a nivel alto está destinado principalmente al equipo de cadena de suministro. De hecho, problemas como cantidades mínimas de pedido anómalas solo serán percibidos como problemas por un profesional que esté familiarizado con el entorno empresarial. El objetivo de este informe es poder ver de un vistazo que todo está bien y que no se requiere ninguna intervención adicional.
Anteriormente, dije que el sistema analítico debía ser sin estado. Bueno, resulta que la salud de los datos es la excepción que confirma la regla. De hecho, muchos problemas se pueden identificar comparando los indicadores actuales con los mismos indicadores recopilados en los días anteriores. Por lo tanto, el monitoreo de la salud de los datos generalmente persistirá algún tipo de estado, que son básicamente indicadores clave observados en días anteriores, para poder identificar valores atípicos en el estado actual de los datos. Sin embargo, como la salud de los datos es un asunto puramente de monitoreo, lo peor que puede suceder si hay un problema en el nivel del lago de datos que se soluciona, y luego tenemos ecos de problemas pasados en el estado de la salud de los datos, es una serie de falsas alarmas en esos informes. La lógica que genera las decisiones de la cadena de suministro sigue siendo completamente sin estado; el estado solo concierne a una pequeña parte de la instrumentación.
El monitoreo de la salud de los datos, tanto a nivel bajo como alto, es una cuestión de equilibrio entre el riesgo de tomar decisiones incorrectas y el riesgo de no tomar decisiones a tiempo. Al analizar cadenas de suministro grandes, no es razonable esperar que el 100 por ciento de los datos sean correctos: las entradas transaccionales incorrectas ocurren, aunque sean raras. Por lo tanto, debe haber un volumen de problemas que se consideren suficientemente bajos para que la receta numérica funcione. El equilibrio entre estos dos riesgos, ser demasiado sensible a las fallas de los datos o ser demasiado tolerante a los problemas de los datos, depende en gran medida de la estructura económica de la cadena de suministro.
En Lokad, creamos y ajustamos estos informes caso por caso para cada cliente. En lugar de perseguir todos los posibles casos de corrupción de datos, el científico de la cadena de suministro, que es responsable de implementar la salud de los datos a nivel bajo y alto y los inspectores de datos que discutiré en un momento, intenta ajustar el monitoreo de la salud de los datos para que sea sensible a los problemas que realmente son dañinos y que realmente ocurren en la cadena de suministro de interés.
En la jerga de Lokad, un inspector de datos, o simplemente un inspector, es un informe que consolida todos los datos relevantes relacionados con un objeto de interés. Se espera que el objeto de interés sea uno de los ciudadanos de primera clase desde una perspectiva de cadena de suministro: un producto, un proveedor, un cliente o un almacén. Por ejemplo, si estamos considerando un inspector de datos para productos, entonces para cualquier producto vendido por la empresa, deberíamos poder ver a través del inspector en una sola pantalla todos los datos que están asociados con este producto. En el inspector de datos para productos, hay efectivamente tantas vistas como productos, porque cuando digo que vemos todos los datos, me refiero a todos los datos que están asociados con un código de barras o número de parte, no a todos los productos en general.
A diferencia de los informes de salud de datos de bajo nivel y alto nivel, que se espera que sean dos paneles que se puedan inspeccionar de un vistazo, los inspectores se implementan para abordar preguntas y preocupaciones que inevitablemente surgen al diseñar y luego operar la receta numérica principal. De hecho, para tomar una decisión de cadena de suministro, no es infrecuente consolidar datos de una docena de tablas, posiblemente originadas en múltiples sistemas transaccionales. Como los datos están dispersos por todas partes, cuando una decisión parece sospechosa, generalmente es difícil identificar el origen del problema. Puede haber una desconexión entre los datos tal como los ve el sistema analítico y los datos que existen en el sistema transaccional. Puede haber un algoritmo defectuoso que no logra capturar un patrón estadístico en los datos. Puede haber una percepción incorrecta y la decisión que se considera sospechosa podría, de hecho, ser correcta. En todos los casos, el inspector tiene la intención de ofrecer la posibilidad de acercarse al objeto de interés.
Para ser útiles, los inspectores deben reflejar las especificidades tanto de la cadena de suministro como del panorama aplicativo. Como resultado, la creación de inspectores es casi invariablemente un ejercicio a medida. Sin embargo, una vez que se completa el trabajo, el inspector representa uno de los pilares de la instrumentación del propio sistema analítico.
En conclusión, si bien la mayoría de las iniciativas cuantitativas de cadena de suministro están destinadas a fracasar incluso antes de su inicio, no tiene por qué ser así. Es necesario hacer una elección cuidadosa de los entregables, los plazos, el alcance y las reglas para evitar problemas que inevitablemente conducen al fracaso de esas iniciativas. Desafortunadamente, esas elecciones suelen ser algo contraintuitivas, como Lokad aprendió de la manera más difícil a lo largo de sus 14 años de operación hasta ahora.
El comienzo mismo de la iniciativa debe dedicarse a la configuración de un canal de datos. Un canal de datos poco confiable es una de las formas más seguras de garantizar que cualquier iniciativa impulsada por datos fracase. La mayoría de las empresas, incluso la mayoría de los departamentos de TI, subestiman la importancia de un canal de datos altamente confiable que no requiera una lucha constante contra incendios. Si bien la mayor parte de la configuración del canal de datos recae en manos del departamento de TI, la cadena de suministro misma debe ser responsable de la instrumentación del sistema analítico que opera. No espere que TI haga esto por usted; este es trabajo del equipo de cadena de suministro. Hemos visto dos tipos diferentes de instrumentación, a saber, los informes de salud de datos que adoptan una perspectiva de toda la empresa y los inspectores de datos, que admiten diagnósticos en profundidad.
Hoy discutimos cómo comenzar una iniciativa, pero la próxima vez veremos cómo finalizarla o, mejor dicho, con suerte, cómo llevarla a buen término. En la próxima conferencia, que se llevará a cabo el miércoles 14 de septiembre, avanzaremos en nuestro viaje y veremos qué tipo de ejecución se necesita para crear una receta numérica principal y luego llevar gradualmente las decisiones que genera a producción. También analizaremos más de cerca lo que este nuevo enfoque de la cadena de suministro implica para la operación diaria de los profesionales de la cadena de suministro.
Ahora, echemos un vistazo a las preguntas.
Pregunta: ¿Por qué exactamente seis meses como límite de tiempo después del cual una implementación no se realiza correctamente?
Diría que el problema no es realmente tener seis meses como límite de tiempo. Es que, por lo general, las iniciativas están destinadas a fracasar desde el principio. Ese es el problema. Si su iniciativa de optimización predictiva comienza con la perspectiva de que los resultados se entregarán en dos años, es casi garantizado que la iniciativa se disolverá en algún momento y no logrará entregar nada en producción. Si pudiera, preferiría que la iniciativa tuviera éxito en tres meses. Sin embargo, seis meses representa el tiempo mínimo en mi experiencia para llevar una iniciativa de este tipo a producción. Cualquier retraso adicional aumenta el riesgo de que la iniciativa falle. Es muy difícil comprimir aún más este cronograma porque una vez que se han resuelto todos los problemas técnicos, los retrasos restantes reflejan el tiempo que lleva que las personas se pongan en marcha con la iniciativa.
Pregunta: Los profesionales de la cadena de suministro pueden frustrarse con una iniciativa que reemplace la mayoría de su carga de trabajo, como el departamento de compras, en conflicto con la automatización de decisiones. ¿Cómo aconsejaría manejar esto?
Esta es una pregunta muy importante, que se abordará con suerte en la próxima conferencia. Por hoy, lo que puedo decir es que creo que la mayoría de lo que los profesionales de la cadena de suministro están haciendo en las cadenas de suministro actuales no es muy gratificante. En la mayoría de las empresas, las personas recibirán un conjunto de SKU o números de pieza y luego los recorrerán interminablemente, tomando todas las decisiones necesarias. Esto significa que su trabajo consiste esencialmente en mirar una hoja de cálculo y recorrerla una vez a la semana o posiblemente una vez al día. Este no es un trabajo gratificante.
La respuesta breve es que el enfoque de Lokad aborda el problema automatizando todos los aspectos mundanos del trabajo, para que las personas con experiencia genuina en la cadena de suministro puedan comenzar a cuestionar los fundamentos de la cadena de suministro. Esto les permite discutir más con los clientes y proveedores para hacer todo más eficiente. Se trata de recopilar información para poder mejorar la receta numérica. Ejecutar la receta numérica es tedioso, y habrá muy pocas personas que lamenten los viejos tiempos en los que tenían que recorrer hojas de cálculo todos los días.
Pregunta: ¿Se espera que los profesionales de la cadena de suministro trabajen con informes de salud de datos para desafiar las decisiones generadas por los científicos de la cadena de suministro?
Se espera que los profesionales de la cadena de suministro trabajen con inspectores de datos, no con informes de salud de datos. Los informes de salud de datos son como una evaluación de toda la empresa que responde a la pregunta de si los datos en la entrada del sistema analítico son lo suficientemente buenos para que una receta numérica opere sobre el conjunto de datos. El resultado del informe de salud de datos es una decisión binaria: dar luz verde a la ejecución de la receta numérica o oponerse y decir que hay un problema que necesita solución. Los inspectores de datos, que se discutirán más en la próxima conferencia, son el punto de entrada para que los profesionales de la cadena de suministro obtengan información sobre una propuesta de decisión de la cadena de suministro.
Pregunta: ¿Es factible actualizar un modelo analítico, por ejemplo, estableciendo una política de inventario a diario? ¿El sistema de cadena de suministro no puede responder a cambios de política diarios, simplemente generará ruido en el sistema?
Para abordar la primera parte de la pregunta, actualizar un modelo analítico a diario es ciertamente factible. Por ejemplo, cuando Lokad operaba en 2020 con los cierres y reaperturas que tenían lugar en Europa, teníamos países cerrando y abriendo con solo 24 horas de anticipación. Esto creó una situación extremadamente caótica que requería revisiones constantes e inmediatas a diario. Lokad operó bajo esta presión extrema, gestionando cierres y reaperturas que comenzaban o terminaban a diario en toda Europa durante casi 14 meses.
Por lo tanto, actualizar un modelo analítico a diario es factible, pero no necesariamente deseable. Es cierto que los sistemas de cadena de suministro tienen mucha inercia, y lo primero que debe reconocer una receta numérica adecuada es el efecto de trinquete de la mayoría de las decisiones. Una vez que has ordenado que se realice la producción y se consumen las materias primas, no puedes deshacer la producción. Debes tener en cuenta que muchas decisiones ya se han tomado al tomar nuevas decisiones. Sin embargo, cuando te das cuenta de que tu cadena de suministro necesita un cambio drástico en su curso de acción, no tiene sentido retrasar esta corrección solo por el hecho de retrasar la decisión. El mejor momento para implementar el cambio es ahora mismo.
En cuanto al aspecto del ruido de la pregunta, todo se reduce al diseño correcto de las recetas numéricas. Hay muchos diseños incorrectos que son inestables, donde pequeños cambios en los datos generan grandes cambios en las decisiones que representan el resultado de la receta numérica. Una receta numérica no debe ser brusca cada vez que hay una pequeña fluctuación en la cadena de suministro. Es por eso que Lokad adoptó una perspectiva probabilística en la previsión. Al utilizar una perspectiva probabilística, los modelos pueden diseñarse para ser mucho más estables en comparación con los modelos que intentan capturar la media y son bruscos cada vez que ocurre un valor atípico en la cadena de suministro.
Pregunta: Uno de los problemas a los que nos enfrentamos en la cadena de suministro con empresas muy grandes es su dependencia de diferentes sistemas fuente. ¿No es extremadamente difícil reunir todos los datos de estos sistemas fuente en un sistema unificado?
Estoy completamente de acuerdo en que obtener todos los datos es un desafío importante para muchas empresas. Sin embargo, debemos preguntarnos por qué es un desafío en primer lugar. Como mencioné anteriormente, el 99% de las aplicaciones empresariales operadas por grandes empresas en la actualidad se basan en bases de datos transaccionales convencionales y bien diseñadas. Todavía puede haber algunas implementaciones COBOL super antiguas que se ejecutan en almacenamiento binario arcano, pero esto es raro. La gran mayoría de las aplicaciones empresariales, incluso las implementadas en la década de 1990, operan con una base de datos transaccional de producción limpia en el backend.
Una vez que tienes un backend transaccional, ¿por qué debería ser difícil copiar estos datos a un lago de datos? La mayoría de las veces, el problema es que las empresas no solo intentan copiar los datos, sino que intentan hacer mucho más. Intentan preparar y transformar los datos, a menudo complicando en exceso el proceso. La mayoría de las configuraciones de bases de datos modernas tienen capacidades de espejo de datos incorporadas, lo que te permite replicar todos los cambios desde una base de datos transaccional a una base de datos secundaria. Esta es una propiedad incorporada para probablemente los 20 sistemas transaccionales más utilizados en el mercado.
Las empresas tienden a tener dificultades para consolidar los datos porque intentan hacer demasiado y sus iniciativas colapsan debido a su propia complejidad. Una vez que los datos están consolidados, las empresas a menudo cometen el error de pensar que la conexión de los datos debe ser realizada por los equipos de TI, BI o ciencia de datos. El punto que quiero hacer aquí es que la cadena de suministro debe estar a cargo de sus propias recetas numéricas, al igual que el marketing, las ventas y las finanzas. No debería ser una división de soporte transversal que intente hacer esto por la empresa. La conexión de datos de diferentes sistemas generalmente requiere toneladas de conocimientos empresariales. Las grandes empresas a menudo fracasan porque intentan que un experto de los equipos de TI, BI o ciencia de datos haga este trabajo cuando debería ser realizado dentro de la división de interés.
Muchas gracias por su tiempo hoy, su interés y sus preguntas. Nos vemos la próxima vez después del verano, en septiembre.
