Tidbits de terminología de supply chain
El surgimiento de una terminología es, en el mejor de los casos, un proceso aleatorio. supply chain no es la excepción y, en retrospectiva, una porción considerable de la terminología de supply chain es inadecuada. La terminología confusa afecta tanto a los recién llegados como a los profesionales experimentados. Los recién llegados se ven enfrentados a una complejidad accidental más de lo que deberían. Los profesionales puede que no se den cuenta de que el fundamento de su campo es más inestable de lo que parece.
Examinemos los mayores infractores, en términos de terminología, en supply chain y propongamos alternativas adecuadas. Aunque es poco probable que tales alternativas sean adoptadas por la comunidad, deben arrojar algo de luz sobre matices pasados por alto. Como regla general, una buena terminología debería ser lo más neutral y factual posible. Incluir calificativos positivos o “geniales” es una señal de alerta.
ABC analysis debió llamarse moving average segmentation. En términos de terminología, el término “ABC” no aporta nada, mientras que “analysis” es tan vago como puede ser. La expresión “moving average segmentation” es más específica. Aclara las fallas inherentes asociadas con este método. De hecho, los moving averages no solo crean inestabilidad en el tiempo, sino que también fallan al reflejar patrones clave, como las ciclicidades. Además, la segmentación es un mecanismo crude que, por diseño, no puede brindar una respuesta granular a nivel de SKU.
APS (Advanced planning and scheduling) debió llamarse planning management. Primero, no hay nada “advanced” en esos productos de software. Este término fue acuñado en los años 90 por analistas de mercado para promocionar a una serie de software vendors. La mayoría de los productos de software que entran en la categoría APS ya no pueden considerarse “advanced” según los estándares de los años 2020. En segundo lugar, planning management enfatiza procesos caracterizados por extensas entradas manuales de datos. Las capacidades estadísticas solo representan una pequeña fracción del software. La mayor parte de las capacidades del software se destina al usuario final, es decir, al supply and demand planner, quien gestiona manualmente el plan.
BI (Business Intelligence) debió llamarse cube reporting. Primero, esta tecnología no tiene nada que ver ni con la inteligencia, en el sentido de “artificial intelligence”, ni con la inteligencia en el sentido de “servicio secreto de inteligencia”. Por lo tanto, el término “intelligence” no pertenece aquí. Segundo, no hay nada intrínsecamente específico de “business” en esta tecnología. Por ejemplo, mostrar las temperaturas diarias pasadas por código postal es un buen caso de uso para un cube report. Cube reporting es una interfaz de usuario superpuesta sobre una tienda de datos en forma de cubo, también conocida como OLAP (online analytical processing) en la jerga de bases de datos. El cubo ofrece operaciones de slice and dice. Aunque se utiliza el término “cube”, el número de dimensiones no necesita ser igual a 3. No obstante, en la práctica sigue siendo un número de un solo dígito debido a la explosión combinatoria asociada con dimensiones superiores.
ERP (Enterprise Resource Planning) debió llamarse ERM por Enterprise Resource Management. Su objetivo principal es, como sugiere el nombre ERM, rastrear los activos de la empresa. Esos productos tienen poco o nada que ver con la planificación. El diseño central de ERM, que se basa en gran medida en una base de datos relacional, está en desacuerdo con cualquier capacidad predictiva. La terminología “ERP” fue impulsada por analistas de mercado en los años 90 para promocionar a una serie de software vendors que intentaban diferenciarse de sus competidores. Sin embargo, nunca ha habido mucha sustancia detrás de la parte de “planning” de las afirmaciones. En cuanto a software, el ámbito transaccional es más distinto que nunca del ámbito predictivo.
MRP (Material Requirements Planning) debió llamarse MRM (Manufacturing Requirement Management). Las razones son esencialmente similares a las dadas en la discusión ERP vs. ERM. Hay poca o ninguna planificación involucrada y, cuando la hay, el diseño se inclina fuertemente hacia un manual process. Además, el término requirements también está pasado de moda, ya que se refiere principalmente a la gestión del BOM (bill of materials), que hoy en día representa solo una pequeña porción de lo que implica la gestión moderna de la manufactura. Por lo tanto, hay pocas razones para enfatizar este término en particular.
Eaches (EA), una unidad de medida, debería llamarse mejor obvious units (OU). Se utilizan eaches cuando se espera que la unidad de medida relevante, al llevar el control del inventario, sea autoevidente, como suele ser el caso con los productos empaquetados. Desafortunadamente, la intención original se pierde en el término “eaches”. Además, “eaches” es gramaticalmente extraño. La forma singular es confusa, es decir, “1 each”, y por ello se evita en la práctica.
EDI (Electronic Data Interchange) se origina en la década de 1970 y se refiere predominantemente al software que transmite órdenes de compra a los proveedores, eliminando intervenciones clericales en el proceso de pedido. Desafortunadamente, con el advenimiento de internet, incluso navegar por la web técnicamente califica como un proceso EDI. La noción de integrated suppliers (o, en cambio, integrated clients), que insinúa una integración de los respectivos sistemas de TI, sería una mejor manera de enmarcar la situación.
EOQ debió llamarse flat bulk order. De hecho, detrás de este término, que parece capturar una intención amplia, se encuentra una fórmula simplista que asume que la future demand es constante (sin seasonality), que el lead time futuro es constante (sin variabilidad), que el costo de pedido es constante (sin descuentos por volumen) y, finalmente, que el carrying cost es constante (sin expiración). La expresión flat bulk order transmite propiamente la naturaleza simplista de la fórmula.
Order es una buena palabra, pero por sí sola, también es profundamente ambigua. Existen client orders, supplier orders, production orders, inventory movement orders, scrap orders, etc. Se necesita un prefijo calificativo para darle sentido a la expresión. El término “level” es bastante similar en este sentido y no debe usarse sin un prefijo calificativo.
Safety stock debió llamarse Gaussian buffer. De hecho, no hay nothing safe en este método. Se basa en que tanto la demanda futura como el lead time futuro se distribuyen según distribuciones normales (Gaussians), lo cual es nunca el caso, ya que las distribuciones de interés no se distribuyen normalmente en el ámbito de supply chain. El término buffer aclara la intención asociada al stock sin implicar ninguna virtud específica para este arreglo.
Seasonality es un buen término, pero por lo general, el término cyclicities sería más apropiado desde una perspectiva de supply chain. De hecho, tiene poco sentido restringir el análisis del patrón de demanda a la ciclicidad anual, es decir, la seasonality. El día de la semana y el día del mes son otras ciclicidades evidentes que invariablemente deben tenerse en cuenta. Así, un director de supply chain rara vez busca un análisis de seasonality, sino más bien un análisis de cyclicity.
Service level debió llamarse service rate, lo cual habría sido más coherente con fill rate. El término level insinúa una cantidad, como en stock level. Sin embargo, el service level es un porcentaje. Probablemente sea uno de los infractores menores en esta lista. No obstante, sería mejor poder transmitir la dualidad service rate vs. fill rate de una manera más directa.
Incluso los recién llegados (relativos) a supply chain se beneficiarían de una mejor terminología.
DDMRP (demand driven material requirements planning) debió llamarse sparse prioritized buffering. De hecho, esta metodología no proporciona nada específico para aislar la “true” demand en contraposición al flujo: el censoring, las cannabilizations o substitutions ni siquiera existen numéricamente en este marco. Igualmente, la mayoría de los enfoques de planning también están ausentes del marco numérico: range planning, phase-in, phase-out, promotions, etc. La palabra clave “sparse” califica acertadamente la intención asociada con la introducción de “decoupling points”.
Los decoupling points debieron llamarse managed SKUs. DDMRP propone un esquema de coloreo de grafos que divide los SKUs en dos grupos: los decoupling points y el resto. Referirse a esos “points” como SKUs es más claro. Además, dado que esos SKUs son los únicos que se supone deben ser inspeccionados por el demand and supply planner, la expresión “managed SKUs” encaja bien, y aclara que todos los demás SKUs están “unmanaged” desde la perspectiva del planner.
En ciertas situaciones, se pueden lograr simplificaciones dramáticas.
Artificial intelligence, autonomous system, blockchain, cognitive system, demand sensing, demand shaping, digital brain, knowledge graph, optimal algorithms pueden esencialmente ser reemplazados por la palabra magic. Aunque existen diversos grados de verdadera ingeniería fuera de los círculos de supply chain para algunas de esas palabras de moda, en el contexto del software empresarial de supply chain, esos son vaporware en su forma más pura.
Finalmente, algunos términos permanecen adecuados incluso si reciben críticas de vez en cuando.
Value Chain es a veces propuesto como un reemplazo de Supply Chain. Tal reemplazo refleja una falta de entendimiento de la ley de Say, nombrada según la obra de Jean Baptiste Say, un economista de finales del siglo XIX. Esta ley se puede resumir como supply is the source of demand. Primero viene el supply, luego la demand y, por último, el value cuando finalmente ocurren las transacciones. La cadena abarca todo el asunto. La value chain es promovida principalmente por consultores que intentan vender ROI a sus prospectos. Sin embargo, el término ‘value’ resulta ser a la vez menos específico y más positivamente sesgado que su contraparte ‘supply’.
