Preparación de Datos en Supply Chain

00:00:03 Resumen de la preparación de datos en ciencia de datos.
00:00:46 Subestimar las complejidades de la preparación de datos.
00:02:01 Duración típica de un proyecto de preparación de datos.
00:03:19 Desafíos en la velocidad y precisión de la preparación de datos.
00:06:07 Importancia de la documentación en la preparación de datos.
00:08:00 Interpretar la ‘fecha de orden’ en supply chain.
00:09:02 Complicaciones en la interpretación de datos por actualizaciones de sistemas.
00:10:07 Comprender la semántica de los datos para evitar errores.
00:10:15 Estudio de caso: peculiaridades del sistema de supply chain.
00:14:53 Necesidad de documentación de datos en las operaciones empresariales.
00:16:01 Importancia del seguimiento de datos en supply chain.
00:17:24 Ampliar el alcance de los datos en la toma de decisiones automatizada.
00:18:42 Riesgos de depender de individuos para la recuperación de datos.
00:19:02 Desafíos y expectativas en la preparación de datos.
00:20:13 La preparación de datos como un esfuerzo de toda la empresa.
00:21:56 Evaluar la corrección en la interpretación de datos a través de la efectividad en el mundo real.
00:23:02 Consecuencias de una interpretación incorrecta de datos y la importancia de la trazabilidad.
00:24:37 Dificultades y resultados de una mala preparación de datos.
00:24:49 El concepto de una buena preparación de datos.

Summary

En este episodio de Lokad TV, el presentador Kieran Chandler y el fundador de Lokad, Joannes Vermorel, están discutiendo las complejidades de data preparation en ciencia de datos, un proceso que a menudo se subestima pero que actualmente está siendo priorizado debido al cumplimiento del GDPR. Vermorel enfatiza que la preparación de datos, que frecuentemente consume varios meses y recursos extensos, es vital para evitar el problema de “garbage in, garbage out”. Esto requiere transformar datos inconsistentes o incompletos en un formato comprensible, lo que demanda una documentación minuciosa. El proceso es complejo, moldeado por la naturaleza multifacética de los problemas empresariales y el contexto histórico de los datos. Vermorel aboga por un enfoque distribuido, que involucra a varios equipos organizacionales, y sostiene que una preparación de datos efectiva debe ser accesible y facilitar una decision-making.

Extended Summary

En el episodio de Lokad TV, presentado por Kieran Chandler, él y Joannes Vermorel, el fundador de Lokad, están analizando el papel complejo pero crucial de la preparación de datos en el ámbito de la ciencia de datos. Con el aumento de las leyes de cumplimiento del GDPR, los datos están convirtiéndose en un foco central para muchos ejecutivos, con una estimación de que las empresas están gastando actualmente más de 450 mil millones de dólares únicamente en la preparación de datos. El objetivo de la preparación de datos es convertir datos en bruto, frecuentemente inconsistentes o incompletos, en un formato que sea fácil de interpretar y aplicar.

Vermorel aborda la frecuente subestimación de la complejidad de la preparación de datos. A pesar de que las empresas invierten recursos sustanciales en ella, numerosos proyectos se retrasan o exceden sus presupuestos. Según Vermorel, la mayoría de los errores en los sistemas de TI pueden vincularse a problemas en la etapa de preparación de datos. Explica que la naturaleza multifacética de los problemas empresariales se manifiesta en los pasos de la preparación de datos, lo que añade a la complejidad de la tarea.

En cuanto a los plazos, Vermorel sugiere que los proyectos de preparación de datos a gran escala pueden tomar al menos unos pocos meses, extendiéndose a menudo hasta seis meses. Aunque se asume que mejores herramientas o software más escalable deberían acelerar el proceso, él señala que el nivel de madurez del ecosistema en general está ralentizando el progreso. Para evitar genuinamente el problema de “garbage in, garbage out”, primero es necesario documentar y clarificar los datos. Este proceso, argumenta, contribuye a un plazo más largo.

Cuando se le pregunta sobre la viabilidad de acelerar este proceso, Vermorel explica que no es tan simple como simplemente añadir más recursos. Los datos con los que se trabaja no fueron producidos originalmente para la preparación de datos, sino que son un subproducto de los sistemas empresariales. Por ejemplo, describe cómo la función principal de un sistema de punto de venta es procesar los pagos de los clientes, no recolectar datos. Sin embargo, incluso estos sistemas generan datos que pueden ser inconsistentes o defectuosos por razones operativas prácticas, como errores de código de barras. Estas inconsistencias requieren un extenso trabajo preparatorio para su uso efectivo en la optimización de supply chain.

Vermorel también habla sobre la importancia de la documentación en la preparación de datos. En Lokad, un proyecto de preparación de datos típicamente comienza con menos de una línea de documentación por campo por tabla y termina con una página de documentación por campo por tabla. Esta documentación exhaustiva es vital para prevenir el problema de que datos de entrada de mala calidad conduzcan a datos de salida de mala calidad, o “garbage in, garbage out”. Por lo tanto, el plazo de seis meses para la preparación de datos incluye el proceso de creación de esta extensa documentación.

Vermorel comienza abordando las complejidades y posibles malas interpretaciones que pueden surgir de un dato simple: la fecha de un pedido histórico. Explica que “fecha” no es tan directa como puede parecer, ya que existen múltiples interpretaciones posibles, como cuándo el cliente hizo clic en un producto, cuándo validó su cesta, cuándo se procesó el pago o cuándo se pusieron a disposición las mercancías en el almacén.

Señala que la interpretación de dichos datos puede cambiar con el tiempo debido a actualizaciones del sistema o cambios en las prácticas empresariales. Por lo tanto, es crucial entender no solo los datos en sí, sino también el contexto histórico en el que fueron producidos. Si no se reconocen estas complejidades, las empresas pueden enfrentar el problema de “garbage in, garbage out”, donde interpretaciones incorrectas conducen a una toma de decisiones deficiente.

Vermorel destaca un estudio de caso con uno de los clientes de Lokad para ilustrar su punto. Este cliente opera un exigente montaje industrial con cortos lead times, donde recibir la cantidad exacta de mercancías pedidas es esencial. El sistema del cliente cuenta con una función en la que si la cantidad entregada no coincide exactamente con la orden, la orden completa es rechazada y devuelta. Esto conduce a una situación en la que, si reciben un poco más de lo ordenado, deben modificar la orden de compra original en el sistema para que coincida con la cantidad entregada. Este procedimiento les permite aceptar la entrega y

evitar disruptions en sus operaciones industriales.

Sin embargo, este proceso está siendo explotado por proveedores astutos que ahora entregan un poco más de lo ordenado, sabiendo que será aceptado. Esto resulta en órdenes de compra que parecen infladas en comparación con las necesidades reales, creando artefactos de datos que distorsionan el rendimiento del equipo de compras. Vermorel subraya que esta complejidad debe ser documentada para evitar interpretaciones incorrectas. Insiste en que los problemas surgieron no por un mal desempeño del equipo de compras, sino debido a limitaciones en el sistema y a cómo los usuarios afrontaron dichas limitaciones.

Cambiando de enfoque, Vermorel comenta quién se preocupa por los datos históricos, aparte de Lokad, una empresa que los utiliza para probabilistic forecasts. Señala que las empresas monitorean de cerca el dinero que esperan recibir o pagar, y que aquellas que no lo hacen desaparecen con el tiempo. Esto es, en sus palabras, una forma de “Darwinism” empresarial. Sugiere que las empresas que prestan atención a sus transacciones financieras a lo largo del tiempo naturalmente se preocupan por sus datos históricos.

La conversación se está orientando hacia la preparación de datos. Vermorel enfatiza que los datos no son intrínsecamente “limpios” ni completamente comprendidos. Propone que la preparación de datos no es exclusivamente un problema de TI; se trata de entender todos los aspectos de los datos empresariales para abordar todos los ángulos del negocio. El IT department, señala, no se puede esperar que domine todos los ángulos empresariales y no debe asumir la responsabilidad exclusiva de la preparación de datos.

Vermorel está sugiriendo un enfoque distribuido, que involucre a diferentes equipos con experiencia distinta en toda la organización. Los datos relevantes para las compras, por ejemplo, deberían involucrar a los equipos de compras. De manera similar, los datos requeridos para una scorecard de proveedores deberían involucrar a los equipos de abastecimiento. Este enfoque puede aprovechar las percepciones necesarias para una preparación de datos efectiva.

Abordando cómo estar seguro sobre la interpretación de los datos, especialmente cuando la información es incompleta, Vermorel lo relaciona con las teorías científicas; no es posible saber que una teoría es correcta, pero se puede validar cuando resiste el escrutinio. La corrección de la preparación de datos se establece cuando las decisiones derivadas de la interpretación son correctas. Si una preparación de datos incorrecta conduce a decisiones sin sentido, la causa puede ser rastreada, corregida y reevaluada.

Luego, Vermorel describe cómo debería ser una buena preparación de datos, especialmente en escenarios complejos de supply chain. La compara con un libro bien escrito, que proporciona perspectivas e insights empresariales relevantes, no solo detalles técnicos. Debe ser accesible y estar distribuida en toda la organización, fomentando una comprensión compartida. Requiere un esfuerzo continuo para documentar, mantener y comprender los datos.

Por último, Vermorel subraya que la preparación de datos debe ser una interpretación basada en un entendimiento válido de los propios datos. Una vez que este entendimiento es establecido y mantenido, las operaciones lógicas sobre los datos son bastante sencillas. Una buena preparación de datos, entonces, es tanto un manual bien escrito como una comprensión compartida que permite decisiones claras y efectivas en la supply chain.

Full Transcript

Kieran Chandler: En el episodio de hoy, vamos a hablar sobre la preparación de datos, uno de los fundamentos de la ciencia de datos. Dadas las recientes leyes de cumplimiento del GDPR, los datos están al frente de la mente de muchos ejecutivos. Además, es un gran negocio, ya que una encuesta reciente estima que las empresas están gastando más de 450 mil millones de dólares únicamente en la preparación de datos. La preparación de datos consiste en tomar datos en bruto y transformarlos en un formato fácil de entender para que puedan utilizarse de manera efectiva. Esto no es una tarea menor cuando se considera que los datos provienen de muchas fuentes diferentes y a menudo pueden ser inconsistentes, incompletos y también contener errores. Entonces, Joannes, ¿por qué hablamos de la preparación de datos hoy? Quiero decir, si estas empresas están invirtiendo más de 450 mil millones de dólares, ya debería ser algo que entendamos.

Joannes Vermorel: Sí, absolutamente. La preparación de datos es un campo bastante conocido, pero sistemáticamente subestimado en cuanto a cambios. Es interesante porque la mayoría de los proyectos de preparación de datos terminan incumpliendo sus plazos y con sobrecostos. El problema central es que muchos de los errores reales que se observan en los sistemas de TI, enterprise software en general, se remontan a problemas en el nivel de preparación de datos. Es extremadamente complejo. Aunque es un problema conocido, la cuestión central es que las complejidades empresariales se reemergen como pasos en la preparación de datos, haciendo de este un dominio sin límites. No existe una receta final para la preparación de datos.

Kieran Chandler: ¿Cuánto tiempo debería tomar preparar una cantidad considerable de datos?

Joannes Vermorel: Nunca he visto un proyecto de preparación de datos a gran escala que tome menos de unos pocos meses. Típicamente, es más bien de seis meses. Algunos pueden argumentar que con mejores herramientas y software más escalable debería ser más rápido. Sin embargo, la realidad es que hay tan poca madurez en el ecosistema que, para prácticamente cualquier empresa, excepto algunos data champions como Google, primero se deben documentar y clarificar los datos. Hay tantas cosas que deben hacerse con estos datos para evitar el problema de “garbage in, garbage out”. Así que lleva un par de meses, y seis meses es un objetivo razonable si se involucra una supply chain compleja.

Kieran Chandler: Seis meses suena como un período bastante largo. ¿Hay alguna forma de acelerar este proceso? Si soy una gran organización, ¿no puedo simplemente destinar más personas al problema?

Joannes Vermorel: Aquí se presenta un problema específico: ¿se pueden tener nueve mujeres para hacer un bebé en un mes? La cuestión es entender el tipo de problemas con los que estamos lidiando. Primero, los datos que tienes no fueron producidos para ser datos en primer lugar. Son un subproducto de tu sistema empresarial que simplemente opera tu compañía. Tomemos como ejemplo un software de punto de venta, algo en lo que se puede pagar en un supermercado. Su función principal es procesar a los clientes que quieren salir de la tienda pagando lo que deben pagar. Así que, si un código de barras no se escanea por cualquier motivo, es probable que el cajero escanee un producto de precio similar dos veces. Al final, vas a pagar el precio correcto, pero en términos de datos, acabarás teniendo un producto contado dos veces.

Kieran Chandler: Un producto no contado puede crear problemas en términos de inventory management porque tus electronic records se desajustan. Esta no es una buena solución, y es recomendable evitarlo. Pero la realidad es que, si tienes la opción entre resolver un problema de datos y hacer que tu compañía opere de manera más fluida, aquellos que están en el terreno, las personas que necesitan operar físicamente las supply chains, siempre favorecerán una solución que no interrumpa el flujo de mercancías, clientes, servicios y todo lo demás. Operar la empresa es primordial y los datos son solo un subproducto secundario. Nunca se tratan como una prioridad. ¿Es de ahí de donde provienen todos estos desafíos?

Joannes Vermorel: De hecho, de ahí provienen todos esos cambios.

Kieran Chandler: Hablemos sobre esa documentación que mencionaste anteriormente. ¿Qué esperas ver en esa documentación y cómo ayuda? Solo para entender, si retrocedemos al período de seis meses, ¿qué tipo de volumen de documentación esperamos?

Joannes Vermorel: Una regla general sería que, típicamente, cuando en Lokad iniciamos un proyecto, tenemos menos de una línea de documentación por tabla por campo. Usualmente, ni siquiera llegamos a eso. Empezamos muchos proyectos en los que ni siquiera hay una línea de documentación por tabla en el ERP, MRP, WMS, o cualquier otro sistema que se utiliza para operar tu supply chain. Cuando terminamos, acabamos con una página de documentación por campo por tabla. Entonces, si tienes 20 tablas con 20 campos, estamos hablando de 400 páginas de documentación. Sí, se requieren seis meses para producir esas 400 páginas de documentación.

Kieran Chandler: Eso suena como una cantidad enorme de documentación. ¿Realmente es toda necesaria?

Joannes Vermorel: Todo es necesario si quieres evitar basura de entrada, basura de salida.

Kieran Chandler: ¿Por qué es eso?

Joannes Vermorel: Considera un caso práctico: supongamos que tengo una tabla llamada ‘orders’. Contiene mis órdenes históricas y tiene una fecha. Pero, ¿es simple? ¿Estamos realmente hablando sobre qué tipo de fecha es? ¿Es la fecha en que el cliente hizo clic en un producto para añadirlo al carrito en el ecommerce? ¿O cuando el cliente validó el carrito e hizo el pago? ¿O cuando el pago fue validado por el procesador de tarjetas de crédito? ¿O cuando la entrada fue registrada en el sistema? ¿O cuando la orden de compra fue modificada por última vez en el sistema? Hay alrededor de 20 interpretaciones diferentes solo para este campo ‘date’.

Además, si tu empresa tiene más de una década de historia, es probable que la fina línea en la interpretación de la ‘order date’ haya cambiado a lo largo de los años. Podrías terminar en una situación donde se haya realizado una actualización de un sistema y la semántica de esta columna cambiara.

Además, no es algo que sea naturalmente completamente homogéneo para toda tu historia. Luego, puedes tener complicaciones adicionales, como casos extremos. Por ejemplo, se supone que esta fecha es la fecha en que el cliente validó el carrito, excepto si el pago fue finalmente rechazado por fraude. En este caso, es la fecha y la hora en que la orden fue rechazada por fraude.

Nuevamente, no es realmente un buen diseño, pero las empresas que operan supply chains complejos tienen sistemas complejos y mucha historia. Así que, el área de IT no se hizo necesariamente de manera perfecta desde el primer día, y tienes que lidiar con todas estas complicaciones históricas. Terminan reflejándose en esta documentación. Si no logras reconocer todas esas complicaciones, enfrentarás problemas cada vez que desees analizar estos datos.

Kieran Chandler: Para generar una decisión optimizada para tu supply chain, puedes acabar con un problema de “garbage in, garbage out” si interpretas incorrectamente los datos. Entonces, ¿lo que dices es que todo se trata de clarificar la semántica de los datos, verdad?

Joannes Vermorel: Exactamente. Necesitas entender que los datos son más que simples números. Representan varios factores que pueden estar combinados en una sola celda. No se trata solo de comprender el software que produce los datos, sino también cómo las personas interactúan con el software. Tu documentación debe tener en cuenta el ángulo humano de lo que las personas están haciendo.

Kieran Chandler: ¿Tienes un buen ejemplo de cómo uno de tus clientes se ha encontrado con este problema en el pasado y cómo ha afectado a su empresa?

Joannes Vermorel: Sí, puedo dar un ejemplo. Tuvimos un cliente que gestionaba una operación de alta exigencia que requería un alto nivel de disponibilidad. Enviaban órdenes de compra con tiempos de entrega muy cortos a sus proveedores. Su sistema tenía una característica de diseño interesante. Si la cantidad de bienes entregados no coincidía con las cantidades que se habían solicitado originalmente, entonces la orden de compra entera debía ser rechazada y devuelta al proveedor.

Por ejemplo, supongamos que pides 1,000 unidades, pero el proveedor entrega 1,050 unidades, entonces tendrías que rechazarla. El problema con eso es que, si la rechazas, podría provocar serios problemas operativos. El sistema no les permitía modificar la cantidad, así que lo que terminaba sucediendo era que, cuando las cantidades entregadas no coincidían con las ordenadas, modificaban la orden de compra original para reflejar la cantidad entregada.

Kieran Chandler: Entonces, ¿lo que dices es que cambiarían la orden de compra original para que coincidiera con lo entregado?

Joannes Vermorel: Exactamente. Sin embargo, esto abrió otro problema. Los proveedores se dieron cuenta de esta práctica. Se dieron cuenta de que podían entregar más de lo que se había pedido, sabiendo que la empresa necesitaba esos suministros. No entregarían una cantidad desmesurada, sino algo que la empresa consideraría aceptable.

En los datos, parecía como si el pedido inicial fuera para una cantidad mayor. Esto resultó en algunos datos extraños donde las órdenes de compra parecían demasiado grandes en comparación con lo necesario, lo que daba la impresión de que el equipo de compras era malo al elegir las cantidades correctas. Sin embargo, el problema no era del equipo de compras, sino de las limitaciones del sistema y de cómo las personas lidiaban con esas limitaciones.

Todos estos detalles necesitaban estar documentados para evitar llegar a la conclusión equivocada. El equipo de compras no era malo en su trabajo. El problema era que tenían un sistema con limitaciones con las que simplemente estaban tratando de navegar.

Kieran Chandler: El sistema está generando todos esos efectos secundarios extraños. Necesita una página de explicación si quieres entenderlo, pero no hay escapatoria. Es simplemente la complejidad del negocio en sí lo que se refleja en estos datos. Dejemos de lado a esos proveedores astutos. Definitivamente es un ejemplo entretenido. Entonces, mencionaste el aspecto de la persona. Obviamente, en Lokad estamos utilizando datos históricos para hacer forecast probabilístico para el futuro. ¿Quién más se preocupa realmente por los datos históricos, aparte de nosotros?

Joannes Vermorel: Típicamente, todo aquello que realmente afectaba la cantidad de dinero que esperabas recibir o pagar atraía mucha atención. No es que la gente no prestara atención, pero las compañías que no monitoreaban de cerca el dinero que debían recibir tendían a desaparecer con el tiempo. Es como el darwinismo en acción. Si ni siquiera prestas atención a eso, simplemente desapareces. Por eso, hace cinco siglos, la contabilidad de doble entrada fue inventada por unos monjes italianos. Si no prestas atención, tu monasterio simplemente colapsa debido a malas prácticas contables. No es exactamente un problema nuevo, pero hay muchos datos que en el pasado no considerábamos críticos y que ahora se vuelven críticos.

Para darte un ejemplo, para contabilizar correctamente los faltante de stock en el pasado, tenías en cuenta lo que estabas comprando, para saber lo que debías pagar a tus proveedores, y lo que vendías, para saber lo que tus clientes te debían pagar. Pero, ¿qué pasa con el seguimiento de los faltantes de stock históricos? Mientras tengas un supply chain practitioner que decida las cantidades a comprar manualmente y recuerde que hubo algunos períodos extraños con faltantes de stock, entonces no necesitas tener esos registros históricos. Ellos son parte de tu sistema.

El problema es que, tan pronto como deseas pasar a algo más cuantitativo, como lo que hacemos en Lokad con decisiones automatizadas para todas esas tareas mundanas, como decidir cuánto ordenar, tener registros precisos sobre los históricos stock levels se vuelve mucho más importante. De lo contrario, tu automatización interpretará mal cuáles son las ventas y cuál fue la falta de demanda.

Si deseas tener una mayor automatización en tu empresa, entonces necesitas prestar atención a un espectro más amplio de datos, no solo a lo contable en bruto. A tu contador no le importan tus días de faltantes de stock, pero a tu software de optimización de supply chain sí. Necesitas ampliar los círculos de datos que realmente forman parte de tu alcance, que están documentados y donde requieres control y aseguramiento de la calidad.

Kieran Chandler: Entonces, dependemos bastante de esa única persona que recuerda lo que sucedió en el pasado. ¿No deberíamos estar mejor preparados para los datos a medida que llegan? ¿No debería el departamento de IT o alguien más preparar esos datos y asegurarse de que estén limpios desde el principio? Parece una forma más sencilla de hacer las cosas.

Joannes Vermorel: Sí, pero el problema no radica en la competencia de IT. No existe algo como datos limpios. La cuestión es que los datos no se entienden de forma natural con suficiente profundidad y no se cubren adecuadamente todos los ángulos del negocio.

Kieran Chandler: A menudo se dice que las empresas están invirtiendo miles de millones en AI, pero la realidad es que es la complejidad del negocio en sí la que emerge en esta tarea, este desafío de preparar los datos. Y decir, “oh, el departamento de IT debería encargarse de eso”, es como esperar que IT dirija la empresa y tenga conocimientos sobre cada ángulo del negocio.

Joannes Vermorel: Absolutamente, eso de repente crea un problema organizacional porque esperas que IT sea tan experto en Recursos Humanos, marketing, compras, etc. Es decir, esperas un dominio completo de todos los ángulos del negocio por parte del departamento de IT. Pero eso es pedir demasiado. El departamento de IT ya tiene que lidiar con todos los cambios de IT, así que no se les debe esperar que aborden cada problema de negocio en la empresa. Alternativamente, podrías redefinir IT como toda tu empresa, pero eso anula el propósito.

Volviendo al caso en cuestión, la preparación de datos debe ser un esfuerzo bastante distribuido dentro de la empresa porque, en última instancia, las únicas personas que pueden proporcionar el nivel de entendimiento necesario para preparar los datos relevantes para, digamos, compras, son los equipos de compras. De manera similar, si deseas establecer una tarjeta de puntuación de proveedores y tener los datos preparados con suficiente accuracy para que realmente tenga sentido, tendrás que hablar con los equipos responsables de sourcing.

Cada vez que abordas un problema, necesitas involucrar a las personas que son especialistas en ese problema dentro de tu empresa, porque son ellos quienes te darán el entendimiento necesario para que la preparación de los datos tenga sentido. No es estrictamente un problema de IT. Se trata de recopilar todo el conocimiento requerido para que, al procesar los datos, no termines con datos que sean carentes de sentido respecto al problema de negocio que se debe resolver.

Kieran Chandler: Entonces, no estamos del todo allí según todo parece. Algunas empresas lo logran, pero son la excepción, no la regla. ¿Cómo puedes estar seguro, si no tienes toda la información y existen lagunas en tu interpretación, de que tu interpretación es la correcta? Podría haber muchas posibilidades.

Joannes Vermorel: Absolutamente, y ese es un punto interesante porque es similar a las teorías científicas. Nunca sabes que tu teoría es correcta, solo sabes que es lo suficientemente buena y que, cuando se enfrenta a la realidad, funciona. No tienes nada mejor para hacer que funcione mejor.

Entonces, ¿qué significa eso para la preparación de datos? Significa que sabes que tu preparación de datos es correcta cuando, al final del pipeline de datos, las decisiones que generas automáticamente basadas en esta interpretación son correctas. Si tienes decisiones correctas, significa que tu lógica de optimización es eficiente, tus capas de machine learning son precisas, y muchas otras cosas. Fundamentalmente, simplemente no es posible terminar con decisiones correctas generadas por una interpretación incorrecta. Usualmente, cuando no interpretas y preparas correctamente tus datos, arruinarán tan profundamente tus resultados que no hay posibilidad de que funcione.

En resumen, no hay otra solución que hacer la preparación, tener confianza en ella y luego generar las decisiones. Si las decisiones no tienen sentido, retrocedes, rastreas el problema hasta su causa raíz –frecuentemente es la preparación de datos– y lo solucionas. Si, al final del día, las decisiones que salen de tu sistema tienen sentido para un practitioner que las evalúa con su propia mente humana, entonces sabes que lo has hecho bien.

Kieran Chandler: Podrías decir, creo que están correctamente preparados, pero generalmente, todo se reduce a matices de gris. El supply chain practitioner podría decir: “Es una buena decisión, pero podría mejorar aún más. Por ejemplo, si tuviéramos en cuenta el precio de nuestros competidores, porque eso explica picos o caídas inusuales en la demanda, y aún no tenemos esos datos.” Entonces, no es una situación en blanco y negro.

Joannes Vermorel: Hemos hablado bastante sobre las dificultades con la preparación de datos y sobre cómo se ve una mala preparación de datos. Pero, en resumen, ¿cómo se ve una buena preparación de datos? En una situación de supply chain moderadamente compleja, una buena preparación de datos se vería como un libro bien estructurado. Pensemos en ello como un libro de 400 páginas con una página por tabla o veinte campos en 20 tablas. Pero no basta que sea simplemente un libro, tiene que ser un libro bien escrito.

Si escribes algo increíblemente aburrido, nadie lo leerá y no tendrá ningún efecto en tu organización. Entonces, tiene que estar bien escrito. Y por bien escrito, me refiero a que debe ser legible. También necesita estar escrito desde una perspectiva de negocio. No se trata de una documentación de IT. La preparación de datos realmente no es un problema de IT, es más acerca de tener todos los insights de negocio.

La perspectiva válida en el negocio es siempre algo que cambia. Si el panorama competitivo en tu industria cambia, entonces la perspectiva válida sobre un problema dado también cambia. Así que este libro necesita estar bien escrito y mantenido.

Este es un esfuerzo muy distribuido en tu empresa porque, por ejemplo, solo el equipo de merchandising tiene el insight y la perspectiva adecuados para saber cómo deberían documentarse las tablas de merchandising desde el principio. Esta preparación de datos se asemeja a materiales limpios y bien escritos que están ampliamente distribuidos y son accesibles en tu empresa.

La cosa interesante es que una vez que tienes todas esas perspectivas, la transformación de datos, que es lógica, se convierte en una interpretación directa de la comprensión válida de los propios datos. Necesitas poner un enorme esfuerzo para entender los datos, documentarlos, escribirlos y mantenerlos. Pero una vez que has hecho todo eso, escribir la lógica se vuelve sencillo. Entonces, ¿cómo se ve una buena preparación de datos? Es como un libro bien escrito, un entendimiento compartido, una especie de biblia de supply chain que es interna a tu empresa.

Kieran Chandler: ¡Suena bien! Entonces, ¿los matices grises de los datos serán un nuevo éxito de ventas proveniente de la organización?

Joannes Vermorel: Posiblemente, ¿quién sabe?

Kieran Chandler: Bien, esperamos que hayan disfrutado del episodio de hoy sobre preparación de datos. Como siempre, pónganse en contacto si tienen alguna otra pregunta y nos veremos de nuevo la próxima vez en Lokad TV. Adiós por ahora.