Preparación de datos

Cuando en Lokad iniciamos cualquier iniciativa de Cadena de Suministro Cuantitativa, invertimos aproximadamente el 80 % de nuestros esfuerzos en la preparación de los datos, a veces llamada depuración de datos , limpieza de datos o preprocesamiento de datos. El hecho de que tal esfuerzo sea necesario a menudo es poco comprendido, incluso por profesionales experimentados en cadena de suministro. Sin embargo, nuestras observaciones indican que los problemas que tienen que ver con los datos probablemente sean la causa primordial de las fallas en la optimización de la cadena de suministro en casi todos los sectores, desde el sector de productos frescos hasta la industria aeronáutica. Si bien algunos fracasos de cadena de suministro son lo suficientemente espectaculares como para llegar a los titulares, la mayoría de los fracasos pasan inadvertidos y se ocultan bajo la alfombra. Obtener información estratégica sobre esos fracasos es de gran importancia, precisamente para evitar que se repitan.

Fracasos debidos a los datos

Los proyectos de optimización de la cadena de suministro a menudo fracasan. Según las anécdotas recogidas de la base de clientes de Lokad, las tasas de fracaso de iniciativas de optimización de cadena de suministro impulsadas por software superan probablemente el 80 % en la mayoría de los sectores. Pocos proveedores reconocerían que el fracaso es el resultado normal para sus clientes. Una paradoja de la cadena de suministro moderna es que existen menos riesgos implicados en el movimiento físico de stocks de almacén de un continente a otro que en el traslado de datos de almacén de una computadora a otra que distan 1 metro una de la otra.

Cuando se producen errores, ni el cliente ni el proveedor tienen mucho incentivo para divulgarlo. Por esa razón, la gran mayoría de los fracasos pasan al olvido en silencio, y no se vuelve a hablar del tema. De vez en cuando, los fracasos son tan espectaculares que llegan a los titulares:

• Los últimos días de Target Canada con SAP
• La debacle de Nike con i2
• La quiebra de FoxMeyer Drugs
• El desastre de inventario de Cisco en 2001
  

Si bien estos fracasos no tiene una única explicación, en cada una de estas ocasiones algo falla con los datos y tiene como resultado decisiones de cadena de suministro espectacularmente equivocadas.

Sin embargo, la mayoría de los fracasos son mucho menos espectaculares. Los profesionales de la cadena de suministro tienden a desconfiar de los números elaborados por su proveedor de sistemas (que supuestamente es el mejor): se mantienen fieles a sus planillas de Excel y esto deriva en el cierre del sistema a cabo de unos meses. Así, la empresa no ha sufrido daños significativos, pero se han gastado tiempo y energías, existe un claro costo de oportunidad ..

Darle un sentido a los datos es difícil

Los datos de negocios históricos son profundamente ambiciosos y sutiles. Estos aspectos son bastante contradictorios y, como consecuencia, tienden a malinterpretarse. Nuestra experiencia indica que es ese mismo malentendido el que probablemente representa la causa raíz detrás de los problemas de datos que tan a menudo se encuentran en las iniciativas de optimización de la cadena de suministro.

Veamos un ejemplo simple de historial de ventas: una tabla enumera las cantidades de producto vendidas por día durante los últimos años. Este historial de ventas debería dar un sentido a la dirección de la empresa.

Sin embargo, estos son los motivos por los que no es así:

• El historial podría contener paquetes , con un producto que es en realidad un paquete de otros productos, de modo que las cantidades podrían disminuir a medida que el negocio crece.
• El historial puede contener devoluciones , que tal vez representen una gran porción de las ventas, de modo que podría parecer que el negocio está creciendo, cuando en realidad está sucediendo lo contrario, ya que las devoluciones se están moviendo más rápidamente.
• El historial puede contener promociones en las que el margen se ha sacrificado en pos de liquidar el inventario, y la demanda generada no representa la demanda de los bienes de precio completo.
  

Luego, cuando nos referimos a cantidad por día relacionada a una fecha específica, la fecha sola viene con su propio bagaje de ambigüedades. Puede ser el día en que:

• el cliente realizó un pedido;
• el cliente confirmó un prepedido;
• el producto se envió al cliente;
• la entrada de pedido finalmente llegó al ERP;
• la entrada de pedido fue modificada por última vez en el ERP;
• el pago del cliente fue recibido;
• etc.
  

Todas las variantes son correctas, pero cada una tiene también sus propios giros comerciales. Aún así, y demasiado a menudo, resulta tentador pensar que, bueno, es solo un simple historial de ventas. Cuando están involucradas las ventas históricas, (casi) nada es simple.

Además, esos giros suelen tener un impacto exponencial cuando se combinan. No hay nada maś dañino en la generación de stocks excedentes que un as an sesgo ascendente que infla las ventas combinado con un sesgo descendente que subestima los stocks entrantes.

Como regla general, en Lokad observamos que habitualmente la buena documentación de los datos a menudo implica escribir una descripción de casi una página por columna, para cada columna, en cada tabla. Aún así, nos consideramos afortunados incluso cuando tenemos a disposición solo 1 línea de documentación por columna (por campo de datos) al comienzo de un proyecto.

Y, muchas veces, incluso cuando existe documentación, generalmente carece por completo de sentido. No hay dudas de que una columna llamada OrderDate (FechaPedido) contiene... fechas. Tampoco hay dudas de que otra columna llamada StatusCode (CodigoEstado) contiene una lista breve de códigos. La mayoría de la documentación técnica se concentra en aspectos de TI, dejando de lado por completo las cuestiones de negocios. Sin embargo, son precisamente esas cuestiones las que nos interesan particularmente desde una perspectiva de optimización.

En informática, el dicho dice: Basura entra, basura sale . Si los datos de entrada no tienen sentido, los resultados tampoco lo tendrán. Por lo tanto, desglosar los datos y documentar nuestros hallazgos es un objetivo clave cuando Lokad emprende una iniciativa de optimización de cadena de suministro. A la mayoría de nuestros clientes les sorprende la cantidad de documentación que Lokad elabora mientras revisa sus sistemas, sus datos y sus procesos. Sin embargo, nuestra experiencia demuestra que jamás hemos lamentado haber documentado demasiado.

No hay dos configuraciones iguales

Una pregunta frecuente durante el curso de una iniciativa de Cadena de Suministro Cuantitativa es: ¿Esta optimización es compatible con el sistema XYZ? La respuesta breve es, casi siempre, sí, pero la respuesta completa es sí, pero con algo de esfuerzo. Mover los datos es bastante fácil: El FTP (protocolo de transferencia de archivos) ha estado entre nosotros desde hace décadas, y hasta una conexión a Internet modesta puede mover una cantidad bastante importante de datos. Sin embargo, el verdadero desafío es encontrarle el sentido a los datos que se procesan. Aquí no siempre es fácil para las empresas darse cuenta de la verdadera flexibilidad de sus sistemas informáticos. Si bien los sistemas de la empresa pueden parecer bastante rígidos para los profesionales, en la práctica raramente lo son.

De hecho, los proveedores de software han estado compitiendo por características de flexibilidad durante décadas, y los sistemas que realmente encauzan los flujos de trabajo en un solo modo de hacer las cosas son escasos. La mayoría de los sistemas ofrecen incontables maneras diferentes de lograr el mismo objetivo. Como resultado, incluso cuando los datos se originan desde el mismo software, es raro que la preparación de los datos sea exactamente la misma. De hecho, la preparación de los datos depende en gran medida de las praćticas y los flujos de trabajo implementados en una determinada empresa, y los mismos registros de datos pueden no interpretarse exactamente de la misma manera en dos empresas diferentes. A primera vista, tales discrepancias pueden parecer menores, pero desde la perspectiva de optimización de la cadena de suministro, generalmente causan alineaciones erróneas significativas entre la lógica de optimización y las necesidades de negocios reales.

La estrategia yace en los datos

La mayoría de los ejecutivos de negocios confían implícitamente en que su equipo ejecutará la estrategia de negocios, incluso cuando la estrategia no se haya formalizado o ni siquiera escrito. Sin embargo, la optimización cuantitativa no deja espacio para los objetivos implícitos : los números elaborados a partir de los datos de entrada reflejan exactamente el marco numérico que se ha implementado. Como consecuencia, los resultados iniciales elaborados por las soluciones de optimización cuantitativa tienden a ser desorientadores: aciertan en muchos aspectos, pero también se equivocan mucho en otros.

Debido a que los objetivos de negocios precisos raramente se especifican desde el comienzo, a menudo se necesita ver los primeros resultados producidos por la lógica de optimización cuantitativa para ver lo que falta. Podría ser que:

• algunos clientes son VIP y requieren niveles de servicio mucho más altos;
• algunos productos están al borde de la obsolescencia e implican un riesgo de inventario mucho más alto;
• algunos proveedores tienen MOQ tanto por SKU como por pedido;
• algunos almacenes están casi llenos y es preciso restringir los pedidos;
• etc.
  

Abordar tales desafíos requiere datos adicionales, y las empresas generalmente comienzan a darse cuenta de que los datos relevantes no pueden encontrarse en otro lugar más que en planillas de Excel dispersas por la empresa. Las planillas de Excel mismas demasiado a menudo se tratan como si no fueran particularmente importantes, y muchas de ellas tienden a archivarse en buzones de correo electrónico.

Como resultado, no solo es necesario preparar los datos transaccionales, como los datos extraídos de un EPR, sino también todos los datos de alto nivel que informan la estrategia de negocios. Y para complicar aún más el desafío, los datos de alto nivel tienden a ser más difíciles de preparar. De hecho, a diferencia de los datos transaccionales, generalmente es poco el esfuerzo que se invierte en hacer que esos datos sean completamente uniformes en toda la empresa. Como consecuencia, no es raro observar que, a medida se preparan estos datos, la estrategia de negocios de alto nivel de la empresa resulta, en parte, no tener sentido para algunos casos límite.

Para alinear la lógica de optimización con la empresa, el método más directo generalmente consiste en volver a expresar todo en euros o dólares (o cualquier otra moneda que sea relevante). Esto es así no porque haya alguna superioridad intrínseca en ver las cosas desde un punto de vista financiero, sino simplemente porque estas son las únicas unidades de recuento que pueden uniformarse en toda la empresa con poca o ninguna coordinación entre los equipos. En la práctica, este punto de vista financiero tiende a crear roces cuando una empresa ya está acostumbrada a trabajar con métricas no financieras; o, lo que es peor, sin ninguna métrica .

La documentación nunca es suficiente

El ingrediente secreto de toda buena preparación de datos es una buena documentación . Este ingrediente es simple, pero casi siempre se omite, se considera poco urgente o poco importante. Sin embargo, nuestra experiencia en Lokad indica que la buena documentación de los datos es tan urgente como crucial.

En particular, la documentación tiene que responder a la pregunta por qué para cada fuente de datos, e incluso para cada campo de datos. La documentación del propósito de los datos es esencial para asegurarse de que luego esos datos se procesen correctamente. Sin embargo, demasiado a menudo, cuando la documentación existe, simplemente tiende a parafrasear los nombres de los campos.


La documentación de los datos de entrada no debería verse como un elemento de TI, sino como un activo de negocios. No importa cuán motivado y predispuesto esté el departamento de TI, el equipo de TI generalmente no tiene acceso a la información estratégica de negocios necesaria para comprender acabadamente los datos.

Como resultado, cuando en Lokad emprendemos una iniciativa para un nuevo cliente, generalmente tendemos a invertir tiempo en escribir la documentación al principio; generalmente de a poco a la vez después de cada conversación con nuestro cliente (que nos proporciona la información necesaria sobre su conocimiento de negocios). El valor resultante de este proceso generalmente no es evidente desde el principio, ya que hay otras cosas que parecen ser más apremiantes al principio. Sin embargo, a medida que pasan las semanas, algunos detalles sutiles relacionados con los datos se olvidan, y la documentación escrita se vuelve el único modo de evitar tropezar con los mismos inconvenientes una y otra vez.