Entregables del proyecto

La meta de Supply Chain Quantitativa es entregar decisiones accionables - las cantidades sugeridas para las órdenes de compra son un ejemplo arquetípico. A continuación, aclaramos con mayor detalle la forma específica y el mecanismo de entrega de dichas decisiones. Establecer expectativas claras para los entregables es un paso importante en el trayecto que representa Supply Chain Quantitativa. Además, los resultados numéricos optimizados no son el único output deseable: se deben incluir en el entregable varios otros outputs, siendo los más notables el monitoreo de la salud de los datos y los KPIs de gestión. En la práctica, los entregables de una iniciativa de Supply Chain Quantitativa dependen de la flexibilidad de la solución de software utilizada para soportar la propia iniciativa. Sin embargo, se definen principalmente por su intención, la cual es ajena a la tecnología empleada.

Scripts como entregable

Supply Chain Quantitativa enfatiza la automatización completa de tuberías de datos. Esto no implica que la configuración del software deba funcionar de manera autónoma. Es natural que se desee un alto grado de supervisión cercana siempre que se considere una supply chain a gran escala. Sin embargo, se espera que la tubería de datos esté completamente automatizada en el sentido de que ningún paso dependa de una operación manual. De hecho, como se expone en el manifiesto, siempre que se involucren operaciones manuales en el procesamiento de datos de la supply chain, la solución simplemente no escala en la práctica.

Como consecuencia directa de esta perspectiva, los entregables de una iniciativa de Supply Chain Quantitativa son invariablemente piezas completas de software. Esto no implica que se espere que el equipo a cargo reimplemente todo: una solución de software dedicada a Supply Chain Quantitativa ofrece la posibilidad de centrarse exclusivamente en los aspectos relevantes de los desafíos de supply chain. Se espera que todas las tecnicidades de bajo nivel, como aprovechar recursos de computación distribuidos autoasignados dentro de una plataforma de computación en la nube, sean abstraídas. El equipo no necesita profundizar en tales asuntos, ya que se supone que esos aspectos son gestionados de manera adecuada por las propias herramientas.

Los entregables se materializan como scripts, normalmente escritos en un lenguaje de programación capaz de acomodar los requerimientos de la supply chain, al mismo tiempo que ofrecen un alto nivel de productividad. El término “script” se utiliza aquí en lugar de “código fuente”, pero ambos términos están estrechamente relacionados: un “script” enfatiza la idea de un alto grado de abstracción y un enfoque en la tarea misma, mientras que un “código fuente” enfatiza una perspectiva de menor nivel, destinado a ser un reflejo preciso del hardware de computación. Para Supply Chain Quantitativa, lo que importa es, sin duda, la perspectiva de la supply chain, no el hardware de computación, que es un aspecto técnico de importancia secundaria.

Durante la última década, el éxito de las interfaces de usuario WYSIWYG (what-you-see-is-what-you-get) para aplicaciones destinadas al cliente final ha llevado a muchos proveedores de software de supply chain a intentar emular este enfoque con una solución WYSIWYG para la planificación y optimización de la supply chain. Sin embargo, la lección del casi sistemático fracaso de estos tipos de interfaces es que las supply chains son complejas y no pueden eludir la necesidad de herramientas programáticas. Según nuestra experiencia, esperar que una herramienta de arrastrar y soltar (drag-and-drop) sea capaz de reflejar adecuadamente las complejas no linealidades involucradas en, por ejemplo, la superposición de MOQ (cantidades mínimas de pedido), es, en el mejor de los casos, ilusorio. Se requiere expresividad programática porque, de lo contrario, el desafío de la supply chain ni siquiera puede expresarse dentro de la herramienta.

Naturalmente, desde la perspectiva del usuario final, los scripts no son lo que los profesionales de la supply chain esperarían ver como un output tangible de la iniciativa de Supply Chain Quantitativa. Las personas interactuarán con dashboards que contienen KPIs consolidados y tablas que reúnen las decisiones sugeridas. Sin embargo, esos dashboards son transitorios y desechables. Simplemente se obtienen al ejecutar los scripts nuevamente sobre los datos relevantes de la supply chain. Aunque la distinción es un poco sutil, es importante no confundir el script, que representa el entregable real, con su expresión numérica, que es típicamente lo que se ve como usuario final de la solución.

Dashboards de salud de datos

Antes de considerar la entrega de decisiones optimizadas para la supply chain, debemos asegurarnos de que los datos procesados por el sistema que respalda la iniciativa de Supply Chain Quantitativa sean correctos tanto numérica como semánticamente. El propósito de los dashboards de monitoreo de la salud de los datos, o simplemente dashboards de salud de datos, es garantizar un alto grado de confianza en la corrección de los datos, lo cual es, naturalmente, un requisito esencial para la precisión de todos los resultados numéricos devueltos por la solución. Estos dashboards también ayudan al equipo de supply chain a mejorar la calidad de los datos existentes.

Los errores numéricos son sencillos: el archivo CSV exportado desde el ERP indica que el producto ABC tiene 42 unidades en stock, mientras que la consola web del ERP reporta solo 13 unidades en stock. Es evidente que tenemos cifras divergentes donde deberían ser iguales. Los dashboards de salud de datos abordan esos problemas relativamente obvios al comprobar simplemente que los agregados de datos se mantengan dentro de rangos numéricos esperados.

Los errores semánticos son más sutiles y, en la práctica, mucho más difíciles de identificar. La mayor parte del trabajo realizado durante la preparación de datos consiste en identificar y abordar todos los errores semánticos. Por ejemplo: el campo stockinv en el ERP podría estar documentado como el stock disponible. Así, el equipo de supply chain asume que esta cantidad nunca puede ser negativa, porque, obviamente, si esas unidades están al alcance físico en el estante, tiene que ser una cantidad positiva. Sin embargo, la documentación del ERP también podría resultar algo engañosa, y esta cantidad hubiera sido nombrada más apropiadamente como stock disponible, ya que cada vez que ocurre un faltante de stock y el cliente emite un backorder, la cantidad puede volverse negativa para reflejar que un cierto número de unidades ya se deben a un cliente. Este caso ilustra un error semántico: el número no es incorrecto per se, es la interpretación del mismo lo que resulta aproximada. En la práctica, las aproximaciones semánticas pueden generar muchos comportamientos inconsistentes, que a su vez generan costos de fricción continuos dentro de la supply chain.

Los dashboards de salud de datos consolidan cifras que permiten a la empresa decidir al instante si los datos pueden ser considerados lo suficientemente fiables o no. De hecho, dado que la solución se utilizará a diario para fines de producción, es imperativo que un problema de datos significativo se identifique mediante una inspección casi instantánea. De lo contrario, lo más probable es que la supply chain termine operando durante días, si no semanas, sobre datos defectuosos. En este sentido, el dashboard de salud de datos es similar a un semáforo: en verde pasas, en rojo paras.

Además, al considerar una supply chain de gran tamaño, usualmente existe una cantidad irreducible de datos corruptos o de otro modo incorrectos. Estos datos surgen debido a entradas manuales defectuosas o a casos extremos en los propios sistemas de la empresa. En la práctica, para cualquier supply chain de gran envergadura, es irrazonable esperar que los datos sean 100% precisos. En cambio, debemos asegurarnos de que los datos sean lo suficientemente precisos como para mantener los costos de fricción generados por esos errores casi negligibles.

Por lo tanto, se espera que los dashboards de salud de datos también recolecten estadísticas sobre los errores identificados en los datos. Esas estadísticas son fundamentales para establecer que se puede confiar en los datos. Con ese fin, se recurre frecuentemente a un Supply Chain Scientist para establecer umbrales de alerta bien elegidos, típicamente asociados con una detención total de la solución. Se debe tener precaución al fijar los umbrales porque, si son demasiado bajos, la solución resulta inutilizable, ya que se detiene con demasiada frecuencia debido a “problemas de datos identificados”; sin embargo, si son demasiado altos, los costos de fricción generados por los errores pueden volverse significativos y socavar los beneficios que aporta la iniciativa.

Más allá de la señalización rojo-verde, se pretende que los dashboards de salud de datos ofrezcan también insights priorizados sobre los esfuerzos de mejora de los datos. De hecho, muchos puntos de datos pueden ser incorrectos pero, a la vez, inconsecuentes. Por ejemplo, no importa si el precio de compra de un producto es incorrecto si la demanda de mercado para ese producto desapareció hace años, ya que no habrá más órdenes de compra para él.

Supply Chain Quantitativa enfatiza que la resolución detallada de los errores de datos, que puede implicar una cantidad considerable de trabajo manual, debe priorizarse en función del impacto financiero estimado del error en sí frente al costo laboral asociado a su corrección. De hecho, dependiendo de la situación, el costo asociado a la corrección de un solo punto de datos defectuoso varía enormemente y debe tenerse en cuenta en la priorización sugerida. Finalmente, cuando se considere que el costo de las correcciones es mayor que los costos de supply chain generados por esos errores, el proceso de mejora de datos puede detenerse.

Dashboards de decisiones priorizadas

Como hemos visto, solo las decisiones de supply chain pueden evaluarse verdaderamente desde una perspectiva cuantitativa. Por lo tanto, no es sorprendente que uno de los entregables operativos clave de una iniciativa de Supply Chain Quantitativa sean los dashboards que consolidan las decisiones obtenidas como resultado numérico final de toda la tubería de datos. Dicho dashboard puede ser tan simple como una tabla que, para cada producto, liste la cantidad exacta en unidades a reordenar de inmediato. Si existen MOQs (cantidades mínimas de pedido) - o cualquier otra restricción de pedido - entonces las cantidades sugeridas podrían ser cero la mayor parte del tiempo, hasta que se cumplan los umbrales adecuados.

Para simplificar, asumimos aquí que esos resultados numéricos se recopilan en un dashboard, que es una forma específica de interfaz de usuario. Sin embargo, el dashboard en sí es solo una opción, que puede o no ser relevante. En la práctica, se espera que el software que impulsa la iniciativa de Supply Chain Quantitativa sea altamente flexible, es decir, programáticamente flexible, ofreciendo muchas maneras de empaquetar esos resultados en varios formatos de datos. Por ejemplo, los resultados numéricos pueden consolidarse en archivos de texto planos, que están destinados a importarse automáticamente en el ERP principal utilizado para gestionar los activos de la empresa.

Si bien el formato de las decisiones depende en gran medida de la tarea de supply chain que se esté abordando, la mayoría de las tareas requieren priorizar dichas decisiones. Por ejemplo, el acto de calcular las cantidades sugeridas para una orden de compra se puede descomponer mediante una lista priorizada de unidades a adquirir. La unidad más rentable se clasifica en primer lugar. Como el stock presenta rendimientos decrecientes, la segunda unidad adquirida para el mismo producto aborda una fracción decreciente de la demanda del mercado. Por lo tanto, la segunda unidad de ese producto puede no ser la segunda entrada en la lista general. En cambio, la segunda unidad más rentable puede estar asociada a otro producto, etc. La lista priorizada de unidades a adquirir es conceptualmente interminable: siempre es posible comprar una unidad adicional. Dado que la demanda del mercado es finita, todas las unidades compradas se convertirán en stock muerto después de cierto punto. Convertir esta lista de prioridades en las cantidades finales para la compra solo requiere introducir un criterio de detención y sumar las cantidades por producto. En la práctica, las restricciones de pedido no lineales complican aún más esta tarea, pero, para simplificar, dejaremos estas restricciones de lado en esta etapa de la discusión.

Priorizar decisiones es una operación muy natural desde el punto de vista de Supply Chain Quantitativa. Dado que cada decisión está asociada a un resultado financiero expresado en dólares, clasificar las decisiones de la más rentable a la menos rentable resulta sencillo. Así, se puede esperar que muchos, si no la mayoría, de los dashboards que recopilan las decisiones sugeridas de supply chain sean, en la práctica, listas priorizadas de decisiones. Estos dashboards contienen listas con decisiones altamente rentables en la parte superior y decisiones muy poco rentables en la parte inferior. Alternativamente, los profesionales de la supply chain pueden decidir truncar las listas cuando las decisiones no sean rentables. Sin embargo, con frecuencia se obtienen insights al poder inspeccionar decisiones que se sitúan justo por debajo del umbral de rentabilidad, incluso si, obviamente, no se espera que la empresa actúe sobre esas entradas no rentables.

Para ofrecer este tipo de dashboards impulsados por decisiones, la solución de software que soporta Supply Chain Quantitativa necesita explorar numéricamente vastas cantidades de posibles decisiones. Por ejemplo, la solución debería ser capaz de considerar el impacto financiero de comprar cada unidad individualmente, unidad por unidad, para cada producto en cada ubicación. No es de extrañar que esta operación pueda requerir recursos de computación sustanciales. Afortunadamente, en la actualidad, el hardware de computación es capaz de manejar incluso las supply chain globales más grandes. Suponiendo que la solución de software subyacente esté debidamente arquitectada para Supply Chain Quantitativa, la escalabilidad del procesamiento de datos debería seguir siendo un aspecto sin inconvenientes para los equipos de supply chain.

Analizando en detalle los resultados numéricos

Sistemas a los que se hace referencia de manera despectiva como black boxes en supply chain, y en otros campos también, son sistemas que generan salidas que no pueden ser explicadas por los profesionales que interactúan con dichos sistemas. La Supply Chain Quantitativa, con su enfoque específico en una canalización de datos automatizada, también enfrenta el riesgo de entregar lo que los equipos de supply chain clasificarían como “black boxes”. De hecho, las implicaciones financieras de las decisiones de supply chain son muy importantes para una empresa, y, si bien un sistema más nuevo puede mejorar la situación, también puede potencialmente crear desastres. Si bien la automatización es altamente deseable, no significa que se espere que el equipo de supply chain tenga una comprensión profunda de lo que se está entregando a través de la canalización de datos que respalda la iniciativa de Supply Chain Quantitativa.

El término whiteboxing se refiere al esfuerzo necesario para hacer que la solución sea totalmente transparente en beneficio de los equipos de supply chain. Este enfoque enfatiza que ninguna tecnología es transparente por diseño. La transparencia es el resultado final de un esfuerzo específico, que es parte de la misma iniciativa. Incluso una simple regresión lineal puede generar resultados desconcertantes en la práctica. Dejando de lado a unos pocos individuos excepcionales, la mayoría de las personas no tiene una comprensión intuitiva de cuál es la salida “esperada” del modelo lineal siempre que se involucran 4 dimensiones o más. Sin embargo, los problemas de supply chain a menudo involucran docenas de variables, si no cientos. Así, incluso los modelos estadísticos simplistas son de facto black boxes para los profesionales de supply chain. Naturalmente, cuando se utilizan algoritmos de machine learning, como recomienda Supply Chain Quantitativa, dejan a los profesionales aún más en la oscuridad.

Si bien el efecto black box es un problema real, una solución realista no radica en simplificar el procesamiento de datos en cálculos que sean inmediatamente intuitivos para la mente humana. Este enfoque es una receta para una ineficiencia extrema, que anula por completo todos los beneficios de los recursos informáticos modernos, los cuales se pueden utilizar para abordar la compleja realidad de los supply chain modernos. Simplificar el proceso no es la respuesta. Whiteboxing sí lo es.

Incluso las recomendaciones de supply chain más complejas pueden hacerse en gran medida transparentes para los profesionales de supply chain, simplemente descomponiendo los cálculos internos con indicadores financieros bien elegidos, que representan los impulsores económicos que sustentan la recomendación misma. Por ejemplo, en lugar de mostrar simplemente una tabla básica con dos columnas, producto y cantidad, como un pedido de compra sugerido, la tabla debería incluir un par de columnas que ayuden en la toma de decisiones. Esas columnas adicionales pueden incluir el stock actual, la demanda total del último mes, el lead time esperado, el coste financiero esperado del faltante de stock (si no se realiza ningún pedido), el coste financiero esperado del sobrestock (riesgo asociado con el pedido sugerido), etc. Las columnas están diseñadas para proporcionar al equipo de supply chain comprobaciones rápidas de la coherencia de las cantidades sugeridas. A través de ellas, el equipo puede establecer rápidamente confianza en el resultado numérico y también identificar algunas debilidades de una solución que necesita mayor mejora.

Extender los dashboards para fines de whiteboxing es, en parte, un arte. Generar millones de números es fácil, incluso teniendo acceso a no más recursos informáticos de los que están disponibles en un smartphone. Sin embargo, generar 10 números que valga la pena revisar a diario es muy difícil. Así, el desafío central es identificar una docena o menos de KPIs que sean suficientes para arrojar luz sobre las decisiones de supply chain recomendadas. Los buenos KPIs, por lo general, requieren mucho trabajo; no deben ser definiciones ingenuas, que suelen inducir a error en supply chain. Por ejemplo, incluso una columna tan simple como el “precio de compra unitario” puede resultar sumamente engañosa si el proveedor llega a ofrecer descuentos por volumen, haciendo que el precio de compra dependa de la cantidad que se esté adquiriendo.

Dashboards estratégicos

Si bien el enfoque en decisiones a pequeña escala es necesario —ya que es uno de los pocos métodos que se presta a evaluaciones cuantitativas del rendimiento— el supply chain también puede necesitar ajustarse de maneras más amplias y disruptivas para elevar el rendimiento a su siguiente nivel. Por ejemplo, la compra de más unidades de stock bien elegidas incrementa marginalmente el service level. Sin embargo, en algún momento, el warehouse está lleno, y no se puede adquirir ninguna unidad adicional. En esta situación, se debería considerar un warehouse más grande. Para evaluar el impacto de eliminar esta limitación, podemos suprimir la restricción de capacidad del warehouse en los cálculos y evaluar la ganancia financiera global de operar con un warehouse grande y arbitrario. La gestión de supply chain puede entonces vigilar el indicador financiero asociado con el coste de fricción impuesto por la capacidad del warehouse, y decidir cuándo es el momento de considerar aumentar la capacidad de warehousing.

Típicamente, los supply chain operan basándose en numerosas restricciones que no pueden revisarse a diario. Esas restricciones pueden incluir capital de trabajo, capacidad de warehousing, retrasos en el transporte, rendimiento de producción, etc. Cada restricción está asociada a un coste de oportunidad implícito para el supply chain, que típicamente se traduce en más stock, más retrasos o más faltantes de stock. El coste de oportunidad puede evaluarse mediante las mejoras en el rendimiento que se obtendrían al eliminar o debilitar la propia restricción. Si bien algunas de esas simulaciones pueden resultar difíciles de implementar, a menudo no son más complejas que optimizar las decisiones rutinarias, es decir, establecer las cantidades de pedido de compra.

La Supply Chain Quantitativa enfatiza que los costes de oportunidad asociados con esas restricciones deberían formar parte de la canalización de datos de producción y, por lo general, materializarse mediante dashboards dedicados, que están específicamente diseñados para ayudar a la gestión de supply chain a decidir cuándo es el momento de implementar cambios mayores en su supply chain. Este tipo de dashboards se denomina dashboards estratégicos. Este enfoque difiere de la práctica tradicional de supply chain que enfatiza iniciativas ad hoc cuando se percibe que el supply chain está a punto de alcanzar un límite operativo. De hecho, los KPIs ofrecidos por los dashboards estratégicos se actualizan a diario, o con mayor frecuencia si es necesario, al igual que el resto de la canalización de datos. No necesitan hacer un esfuerzo de último minuto, ya que están actualizados y listos para capitalizar las ideas derivadas de una iniciativa de larga duración.

Los dashboards estratégicos apoyan el proceso de toma de decisiones de la gestión de supply chain. Al ser parte de la canalización de datos, siempre que el mercado comience a evolucionar a un ritmo más acelerado de lo habitual, los KPIs se mantienen actualizados respecto a la situación actual de la empresa. Este enfoque evita las trampas tradicionales asociadas con investigaciones ad hoc que invariablemente añaden más demoras a problemas ya aplazados. Asimismo, mitiga en gran medida el problema alternativo de tomar decisiones estratégicas apresuradas que resultan ser no rentables —una condición lamentable que se podría haber anticipado desde el principio.

Dashboards de inspector

Los supply chain son tanto complejos como erráticos. Estas características hacen que la depuración de la canalización de datos sea una tarea tremendamente desafiante. Sin embargo, esta canalización de datos es la médula espinal de la iniciativa de Supply Chain Quantitativa. Los errores en el procesamiento de datos, o bugs, pueden ocurrir en cualquier parte de la canalización. Peor aún, el problema más frecuente no es una fórmula incorrecta, sino la ambigüedad semántica. Por ejemplo, al inicio de la canalización, la variable stockinv podría referirse al stock disponible (donde son posibles valores negativos), mientras que más adelante, la misma variable se utiliza con una interpretación de stock en mano (donde se espera que los valores sean positivos). La ambigua interpretación de la variable stockinv puede generar una amplia variedad de comportamientos incorrectos, que van desde fallos del sistema —que son evidentes y, por ende, solo moderadamente perjudiciales— hasta una corrupción silenciosa y generalizada de las decisiones de supply chain.

Como los supply chain casi siempre se construyen a partir de una mezcla única de soluciones de software implementadas a lo largo de los años, no hay esperanza de acceder a una solución de software “probada” que esté libre de bugs. De hecho, la mayoría de los problemas surgen en los límites del sistema, al conciliar datos provenientes de diferentes sistemas, o incluso al conciliar datos originados en distintos módulos dentro del mismo sistema. Por ello, sin importar cuán probada sea la solución de software, las herramientas deben ser capaces de respaldar de manera eficaz el proceso de depuración, ya que ese tipo de problemas está destinado a ocurrir.

El propósito de los dashboards de inspector es proporcionar vistas detalladas para una minuciosa inspección de los conjuntos de datos de supply chain. Sin embargo, esos dashboards no consisten en simples drill-downs para examinar las tablas de datos de entrada. Dichos drill-downs, o enfoques similares de slice-and-dice en los datos, se perderían el objetivo. Los supply chain se tratan de flujos: flujo de materiales, flujo de pagos, etc. Algunos de los problemas de datos más graves ocurren cuando se pierde “lógicamente” la continuidad del flujo. Por ejemplo, al trasladar mercancías del warehouse A al warehouse B, la base de datos del warehouse B podría carecer de algunas entradas de producto, generando así sutiles corrupciones en los datos, ya que las unidades procedentes del warehouse A se reciben en el warehouse B sin quedar debidamente asociadas a su producto. Cuando los resultados numéricos resultan extraños, esos dashboards de inspector son la opción predilecta para que el Supply Chain Scientist realice una rápida investigación muestral de los datos.

En la práctica, un dashboard de inspector proporciona un punto de entrada a bajo nivel, como un código de producto o un SKU, y consolida todos los datos asociados a ese punto de entrada en una única vista. Cuando las mercancías fluyen a través de muchas ubicaciones, como ocurre, por ejemplo, en los supply chain aeroespaciales, el dashboard de inspector generalmente intenta reconstituir las trayectorias de las mercancías, las cuales pueden haber transitado no solo por múltiples ubicaciones físicas, sino también por distintos sistemas. Al reunir todos estos datos en un solo lugar, se vuelve posible para el Supply Chain Scientist evaluar si los datos tienen sentido: ¿es posible identificar de dónde provienen las mercancías que se están enviando? ¿Están los movimientos de stock alineados con las políticas oficiales de supply chain, etc.? El dashboard de inspector es una herramienta de “debugging” ya que está diseñado para unir aquellos datos que están estrechamente acoplados, no desde un punto de vista informático, sino desde el de supply chain.

Uno de los problemas más extraños que enfrentó Lokad al investigar conjuntos de datos de supply chain fue el caso de las piezas teletransportadas. La empresa —en este caso, una aerolínea— tenía piezas de avión almacenadas tanto en Europa continental como en el sur de Asia. Dado que la seguridad de la aeronave es un requisito absoluto para operar, la empresa mantenía registros impecables de los movimientos de stock de todas sus piezas. Sin embargo, utilizando un dashboard de inspector recientemente ideado, el equipo de Lokad se dio cuenta de que algunas piezas se movían de Asia a Europa, y viceversa, supuestamente en tan solo 2 o 3 minutos. Puesto que las piezas de avión se transportan por avión, se habría esperado que el tiempo de transporte fuese al menos de una corta docena de horas —ciertamente no minutos. Inmediatamente se sospechó de algún problema de zona horaria u otro inconveniente relacionado con el tiempo informático, pero los registros temporales demostraron ser impecables. Luego, al investigar más a fondo los datos, se evidenció que las piezas teletransportadas estaban, de hecho, siendo utilizadas y montadas en las aeronaves en su ubicación de aterrizaje, un hallazgo aún más desconcertante. Al permitir que los equipos de supply chain examinaran por sí mismos los dashboards de inspector, finalmente se descifró el misterio. Las piezas teletransportadas resultaron ser ruedas de avión compuestas de dos medias ruedas más un neumático. La rueda podía desmontarse al separar las dos medias ruedas y el neumático. En el caso más extremo, si se removían las dos medias ruedas y los neumáticos, no quedaba nada físicamente. Por ello, la rueda completamente desmontada podía ser reinstalada en cualquier lugar, sin tener en cuenta en absoluto su ubicación original.

Los dashboards de inspector son la contraparte a bajo nivel del dashboard de health data. Se centran en datos totalmente desagregados, mientras que los dashboards de health data suelen adoptar un enfoque más global de los datos. Además, los dashboards de inspector son, por lo general, parte integral del esfuerzo de whiteboxing. Al enfrentar lo que parece ser una recomendación desconcertante, los profesionales de supply chain deben examinar de cerca un SKU o un producto, para determinar si la decisión recomendada es razonable o no. El dashboard de inspector se ajusta típicamente para este propósito, incluyendo numerosos resultados intermedios que contribuyen al cálculo de la recomendación final.