Preparación de datos en la cadena de suministro

00:00:03 Resumen de la preparación de datos en la ciencia de datos.
00:00:46 Subestimación de 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 Interpretación de la ‘fecha de pedido’ en las cadenas de suministro.
00:09:02 Complicaciones en la interpretación de datos debido a actualizaciones del sistema.
00:10:07 Comprender la semántica de los datos para evitar errores.
00:10:15 Estudio de caso: peculiaridades del sistema de cadena de suministro.
00:14:53 Necesidad de documentación de datos en las operaciones comerciales.
00:16:01 Importancia del seguimiento de datos en las cadenas de suministro.
00:17:24 Ampliar el alcance de los datos en la toma de decisiones automatizada.
00:18:42 Riesgos de depender de individuos para recordar 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 Juzgar la corrección de la interpretación de datos mediante la efectividad en el mundo real.
00:23:02 Consecuencias de la 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 preparación de datos ‘buena’.

Resumen

En este episodio de Lokad TV, el presentador Kieran Chandler y el fundador de Lokad, Joannes Vermorel, discuten las complejidades de la preparación de datos en la ciencia de datos, un proceso que a menudo se subestima pero que actualmente se prioriza debido al cumplimiento del GDPR. Vermorel enfatiza que la preparación de datos, que a menudo consume varios meses y recursos extensos, es vital para evitar el problema de “basura entra, basura sale”. Esto requiere transformar datos inconsistentes o incompletos en un formato comprensible, lo que requiere una documentación exhaustiva. El proceso es complejo, dado la naturaleza multifacética de los problemas comerciales y el contexto histórico de los datos. Vermorel aboga por un enfoque distribuido, que involucre a varios equipos organizativos, y sostiene que la preparación de datos efectiva debe ser accesible y facilitar una toma de decisiones clara.

Resumen Extendido

En el episodio de Lokad TV presentado por Kieran Chandler, él y Joannes Vermorel, el fundador de Lokad, discuten el papel complejo pero fundamental 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 se están convirtiendo en un foco clave para muchos ejecutivos, con una estimación de que las empresas actualmente gastan más de $450 mil millones solo en la preparación de datos. El objetivo de la preparación de datos es convertir datos crudos, frecuentemente inconsistentes o incompletos, en un formato fácil de interpretar y aplicar.

Vermorel aborda la subestimación frecuente de la complejidad de la preparación de datos. A pesar de que las empresas invierten recursos sustanciales en ello, numerosos proyectos se retrasan o superan sus presupuestos. Según Vermorel, la mayoría de los errores del sistema de TI se pueden atribuir a problemas en la etapa de preparación de datos. Explica que la naturaleza multifacética de los problemas comerciales se presenta como pasos de preparación de datos, lo que añade complejidad a la tarea.

En cuanto a los plazos, Vermorel sugiere que los proyectos de preparación de datos a gran escala pueden llevar al menos unos meses, a menudo hasta seis meses. Aunque se asume que las herramientas mejoradas o el software más escalable deberían acelerar el proceso, sugiere que el nivel de madurez general del ecosistema está frenando el progreso. Para evitar realmente el problema de “basura entra, basura sale”, primero es necesario documentar y aclarar los datos. Este proceso, argumenta, contribuye a la prolongación del plazo.

Cuando se le pregunta sobre la viabilidad de acelerar este proceso, Vermorel explica que no es tan simple como agregar más recursos. Los datos con los que se trabaja no fueron producidos originalmente con fines de 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 recopilar datos. Sin embargo, incluso estos sistemas producen datos que pueden ser inconsistentes o defectuosos debido a razones operativas prácticas, como errores de códigos de barras. Estas inconsistencias requieren un trabajo preparatorio extenso para su uso efectivo en optimización de la cadena de suministro.

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 generalmente 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 evitar el problema de que datos de entrada de baja calidad conduzcan a una salida de baja calidad, o “basura entra, basura sale”. Por lo tanto, el plazo de seis meses para la preparación de datos incluye el proceso de crear esta extensa documentación.

Vermorel comienza abordando las complejidades y posibles interpretaciones erróneas que pueden surgir a partir de un simple dato: la fecha de un pedido histórico. Explica que ‘fecha’ no es tan sencillo como parece, ya que existen múltiples interpretaciones posibles, como cuando el cliente hizo clic en un producto, cuando validó su cesta, cuando se procesó el pago o cuando los productos estuvieron disponibles 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 comerciales. Por lo tanto, es crucial comprender no solo los datos en sí, sino también el contexto histórico en el que se produjeron. Si no se reconocen estas complejidades, las empresas pueden enfrentar un problema de “basura entra, basura sale” 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 una configuración industrial exigente con tiempos de entrega cortos, donde recibir la cantidad precisa de productos pedidos es esencial. El sistema del cliente tiene una función en la que, si la cantidad entregada no coincide exactamente con el pedido, se rechaza y se devuelve todo el pedido. Esto lleva a un dilema donde, si reciben ligeramente más de lo pedido, deben modificar la orden de compra original en el sistema para que coincida con la cantidad entregada. Esta solución alternativa les permite aceptar la entrega y

evitar interrupciones en sus operaciones industriales.

Sin embargo, este proceso está siendo explotado por proveedores astutos que ahora entregan ligeramente más de lo pedido, 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 cómo los usuarios se enfrentaron a estas limitaciones.

Cambiando el enfoque, Vermorel está discutiendo quién se preocupa por los datos históricos, aparte de Lokad, una empresa que los utiliza para pronósticos probabilísticos. Señala que las empresas supervisan de cerca el dinero que esperan recibir o pagar, y aquellas que no lo hacen desaparecen con el tiempo. Esto es, en sus palabras, una forma de “darwinismo” 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á centrando en la preparación de datos. Vermorel enfatiza que los datos no son inherentemente “limpios” o completamente comprendidos. Propone que la preparación de datos no es solo un problema de TI; se trata de comprender todos los aspectos de los datos comerciales para abordar todos los ángulos comerciales. El departamento de TI, señala, no puede esperarse que domine todos los ángulos comerciales y no debe asumir la responsabilidad exclusiva de la preparación de datos.

Vermorel sugiere un enfoque distribuido, que involucra a diferentes equipos con experiencia distinta en toda la organización. Los datos relevantes para las compras, por ejemplo, deben involucrar a los equipos de compras. De manera similar, los datos requeridos para una tarjeta de puntuación del proveedor deben involucrar a los equipos de abastecimiento. Este enfoque puede aprovechar las ideas necesarias para una preparación de datos efectiva.

Abordando cómo estar seguro de la interpretación de los datos, especialmente cuando la información es incompleta, Vermorel lo relaciona con teorías científicas; no es posible saber si 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 incorrecta de los datos conduce a decisiones absurdas, se puede rastrear la causa, corregirla y reevaluarla.

Luego, Vermorel describe cómo debería ser una buena preparación de datos, especialmente en escenarios de cadena de suministro complejos. Lo compara con un libro bien escrito, que proporciona ideas y perspectivas comerciales relevantes, no solo detalles técnicos. Debe ser accesible y distribuido en toda la organización, fomentando la comprensión compartida. Requiere un esfuerzo continuo para documentar, mantener y comprender los datos.

Por último, Vermorel enfatiza que la preparación de datos debe ser una interpretación de una comprensión válida de los propios datos. Una vez que se establece y mantiene esta comprensión, las operaciones lógicas sobre los datos son bastante sencillas. Una buena preparación de datos, entonces, es tanto un libro de guía bien escrito como una comprensión compartida que permite decisiones claras y efectivas en la cadena de suministro.

Transcripción completa

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 de GDPR, los datos están muy presentes en la mente de muchos ejecutivos. También es un gran negocio, con una encuesta reciente que estima que las empresas gastan más de 450 mil millones de dólares solo en la preparación de datos. La preparación de datos se trata de tomar datos en bruto y transformarlos en un formato fácil de entender para que se puedan utilizar de manera útil. Esto no es tarea fácil si consideramos que los datos provienen de muchas fuentes diferentes y a menudo pueden ser inconsistentes, incompletos y también pueden contener errores. Entonces, Joannes, ¿por qué estamos hablando de la preparación de datos hoy? Quiero decir, si estas empresas están invirtiendo más de 450 mil millones de dólares, debería ser algo que ya entendamos.

Joannes Vermorel: Sí, absolutamente. La preparación de datos es un campo bastante conocido, pero sistemáticamente subestimado en términos de cambios. Es interesante porque la mayoría de los proyectos de preparación de datos terminan incumpliendo sus plazos y excediendo los presupuestos. El problema principal es que muchos de los errores reales que se ven en los sistemas de TI, el software empresarial en general, se remontan a problemas en el nivel de preparación de datos. Es extremadamente complejo. Aunque es un problema conocido, el problema principal es que las complejidades comerciales vuelven a surgir como pasos de preparación de datos, lo que lo convierte en un dominio ilimitado. No hay una receta final para la preparación de datos.

Kieran Chandler: Entonces, ¿cuánto tiempo debería llevar preparar una cantidad considerable de datos?

Joannes Vermorel: Nunca he visto un proyecto de preparación de datos a gran escala que haya llevado menos de unos meses. Por lo general, son más como 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 campeones de datos como Google, primero es necesario documentar y aclarar los datos. Hay tantas cosas que se deben hacer con estos datos para evitar el problema de “basura entra, basura sale”. Así que lleva un par de meses, y seis meses es un objetivo razonable si tienes una cadena de suministro compleja involucrada.

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

Joannes Vermorel: Te encuentras con un problema específico aquí: ¿puedes tener nueve mujeres para tener un bebé en un mes? El problema es entender el tipo de problemas con los que estamos lidiando. En primer lugar, los datos que tienes no se han producido para ser datos en primer lugar. Es un subproducto de tu sistema empresarial que simplemente opera tu empresa. Tomemos como ejemplo un software de punto de venta, algo donde puedes pagar en un supermercado. Su función principal es procesar a los clientes que quieren salir de la tienda mientras pagan lo que deben pagar. Entonces, 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, pagarás el precio correcto, pero en términos de datos, tendrás un producto contado dos veces.

Kieran Chandler: Un producto contado cero veces puede crear problemas en términos de gestión de inventario porque tus registros electrónicos se vuelven incorrectos. Esta no es una buena solución y es recomendable evitarla. Pero la realidad es que, si tienes la opción entre resolver un problema de datos y permitir que tu empresa funcione sin problemas, aquellos en el terreno, las personas que necesitan operar las cadenas de suministro físicamente, siempre favorecerán una solución que no interrumpa el flujo de bienes, clientes, servicios y todo lo demás. Operar la empresa es primordial y los datos son solo un subproducto de segundo orden. Nunca se trata como un ciudadano de primera clase. Es por eso que siempre hay todo este trabajo que debe hacerse porque los datos no se recopilaron solo con el propósito de permitirte optimizar la cadena de suministro. ¿Es ahí donde provienen todos estos desafíos?

Joannes Vermorel: De hecho, es de ahí de donde provienen todos estos desafíos.

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

Joannes Vermorel: Una regla general sería, típicamente, cuando en Lokad comenzamos un proyecto, tenemos menos de una línea de documentación por tabla por campo. Por lo general, ni siquiera tenemos eso. Comenzamos muchos proyectos en los que ni siquiera tenemos una línea de documentación por tabla en el ERP, MRP, WMS o cualquier otro sistema que se utilice para ejecutar tu cadena de suministro. Cuando terminamos, terminamos 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í, lleva seis meses producir esas 400 páginas de documentación.

Kieran Chandler: Eso suena como una gran cantidad de documentación. ¿Realmente se necesita todo?

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: digamos que tengo una tabla llamada ‘pedidos’. Contiene mis pedidos históricos y tiene una fecha. Pero, ¿es simple? ¿Realmente estamos hablando de qué tipo de fecha es? ¿Es la fecha en que el cliente hizo clic en un producto para ponerlo en el carrito en el sitio de comercio electrónico? ¿O cuando el cliente validó el carrito y realizó el pago? ¿O cuando el pago fue validado por el procesador de tarjetas de crédito? ¿O cuando se registró la entrada en el sistema? ¿O cuando la orden de compra se modificó por última vez en el sistema? Hay alrededor de 20 interpretaciones diferentes solo para este campo de ‘fecha’.

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

Tampoco es algo naturalmente homogéneo para toda tu historia. Luego, puedes tener complicaciones adicionales, como casos excepcionales. Por ejemplo, esta fecha se supone que es la fecha en que el cliente validó el carrito, excepto si el pago fue finalmente rechazado como fraude. En este caso, es la fecha y hora en que se rechazó el pedido como fraude.

Nuevamente, en realidad no es un diseño muy bueno, pero las empresas que ejecutan cadenas de suministro complejas tienen sistemas complejos y mucha historia. Entonces, la TI no necesariamente se hizo perfectamente desde el primer día y debes lidiar con todas estas complicaciones históricas. Terminan reflejándose en esta documentación. Si no reconoces todas esas complicaciones, tendrás problemas cada vez que quieras analizar estos datos.

Kieran Chandler: Para generar una decisión optimizada para tu cadena de suministro, puedes terminar con un problema de ‘basura de entrada, basura de salida’ si interpretas incorrectamente los datos. Entonces, ¿lo que estás diciendo es que todo se trata de aclarar la semántica de los datos, verdad?

Joannes Vermorel: Exactamente. Necesitas entender que los datos son más que solo números. Representan varios factores que pueden combinarse en una celda. No se trata solo de entender 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 aspecto humano de lo que las personas están haciendo.

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

Joannes Vermorel: Sí, puedo dar un ejemplo. Teníamos un cliente que estaba ejecutando una operación altamente exigente que requería un alto nivel de disponibilidad. Pasaban órdenes de compra con plazos de entrega muy cortos a sus proveedores. Su sistema tenía una característica de diseño interesante. Si la cantidad de mercancías entregadas no coincidía con las cantidades que se solicitaron originalmente, entonces se debía rechazar todo el pedido de compra y devolverlo al proveedor.

Digamos, por ejemplo, que ordenas 1,000 unidades, pero el proveedor entrega 1,050 unidades, entonces tendrías que rechazarlo. El problema con eso es que si lo rechazas, podría generar graves problemas operativos. El sistema no les permitía modificar la cantidad, por lo que lo que terminaba sucediendo era que cuando las cantidades entregadas no coincidían con las cantidades solicitadas, modificaban la orden de compra original para reflejar la cantidad entregada.

Kieran Chandler: Entonces, ¿lo que estás diciendo es que cambiaban la orden de compra original para que coincidiera con lo que se entregó?

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 exagerada, sino algo que la empresa consideraría aceptable.

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

Todos estos detalles debían documentarse para evitar llegar a una conclusión incorrecta. El equipo de compras no era malo en su trabajo. El problema era que tenían un sistema con limitaciones con el que simplemente estaban tratando de lidiar.

Kieran Chandler: El sistema está generando todos esos efectos secundarios extraños. Necesita una página de explicación si quieres darle sentido, pero no hay escapatoria. Es simplemente la complejidad del propio negocio la que se refleja en estos datos. Alejémonos de esos proveedores astutos. Ese es definitivamente un ejemplo entretenido. Entonces, mencionaste el tipo de persona. Obviamente, en Lokad estamos utilizando datos históricos para hacer pronósticos probabilísticos para el futuro. ¿A quién más le importan realmente los datos históricos, aparte de nosotros?

Joannes Vermorel: Típicamente, todo lo que realmente afectaba la cantidad de dinero que se esperaba recibir o pagar recibía mucha atención. No es que la gente no estuviera prestando atención, pero las empresas que no estaban monitoreando 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. Es por eso que, hace unos cinco siglos, algunos monjes italianos inventaron la contabilidad de doble entrada. 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 antes no considerábamos críticos para la misión y que ahora se están volviendo críticos para la misión.

Para darte un ejemplo, para contabilizar adecuadamente los faltantes de stock en el pasado, tenías en cuenta lo que estabas comprando, para saber cuánto deberías pagar a tus proveedores, y lo que estabas vendiendo, para saber cuánto deberían pagarte tus clientes. Pero, ¿qué pasa con el seguimiento de los faltantes de stock históricos? Mientras tengas un profesional de la cadena de suministro 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. Forman parte de tu sistema.

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

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

Kieran Chandler: Entonces, dependemos bastante de esta ú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 TI o alguien más preparar esos datos y asegurarse de que estén limpios desde el principio? Parece una forma más fácil de hacer las cosas.

Joannes Vermorel: Sí, pero el problema no está en la competencia de TI. No existe tal cosa como datos limpios. El punto es que los datos no se entienden naturalmente con suficiente profundidad y no todos los ángulos comerciales están cubiertos adecuadamente.

Kieran Chandler: A menudo se dice que las empresas están invirtiendo miles de millones en IA, pero la realidad es que es la complejidad del propio negocio la que surge en esta tarea, este desafío de preparar los datos. Y decir “oh, el departamento de TI debería encargarse de eso” es como esperar que TI dirija la empresa y tenga conocimiento de todos los ángulos comerciales.

Joannes Vermorel: Absolutamente, eso crea de repente un problema organizativo porque esperas que TI sea un experto en Recursos Humanos, marketing, compras, etc. Quiero decir, esperas un dominio completo de todos los ángulos comerciales por parte del departamento de TI. Pero eso es pedir demasiado. El departamento de TI ya tiene que lidiar con todos los cambios de TI, por lo que no se les debería pedir que aborden todos los problemas comerciales de la empresa. Alternativamente, podrías redefinir TI como toda tu empresa, pero eso va en contra del 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 conocimiento necesario para preparar los datos relevantes para, digamos, compras, son los equipos de compras. De manera similar, si quieres establecer una tarjeta de puntuación de proveedores y tener los datos preparados con suficiente precisión para que realmente tenga sentido, tendrás que hablar con tus equipos responsables de abastecimiento.

Cada vez que abordas un problema, necesitas contar con las personas que son especialistas en ese problema dentro de tu empresa, porque son las personas que te darán la perspicacia necesaria para que la preparación de los datos tenga sentido. No es estrictamente un problema de TI. Se trata de recopilar toda la comprensión necesaria para que, cuando proceses los datos, no termines con datos que no tienen sentido con respecto al problema comercial que se necesita resolver.

Kieran Chandler: Entonces, aún no estamos ahí según parece. Algunas empresas están ahí, pero son la excepción, no la norma. ¿Cómo puedes estar seguro, si no tienes toda la información y hay lagunas que estás interpretando, 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 si tu teoría es correcta, solo sabes que es lo suficientemente buena y cuando se desafía en la práctica, 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 flujo de datos, las decisiones que generas automáticamente en función de esta interpretación son correctas. Si tienes decisiones correctas, significa que tu lógica de optimización es eficiente, tus capas de aprendizaje automático son precisas y muchas otras cosas. Fundamentalmente, simplemente no es posible terminar con decisiones correctas generadas por una interpretación incorrecta. Por lo general, cuando no interpretas y preparas correctamente tus datos, tus resultados serán tan malos que no hay posibilidad de que funcione.

En resumen, no hay forma de evitarlo más 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 profesional que está usando su propia mente humana para evaluarlas, entonces sabes que lo has hecho bien.

Kieran Chandler: Podrías decir, creo que están correctamente preparados, pero por lo general, todo se trata de tonos de gris. El profesional de la cadena de suministro podría decir: ‘Es una buena decisión, pero podría mejorarse 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 cómo se ve una mala preparación de datos. Pero para resumir las cosas, ¿cómo se ve una buena preparación de datos? En una situación de cadena de suministro 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 es suficiente que sea solo 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 con bien escrito, me refiero a que debe ser legible. También debe estar escrito desde una perspectiva empresarial. No es una documentación de TI. La preparación de datos realmente no es un problema de TI, se trata más de tener todas las ideas empresariales.

La perspectiva válida en los negocios siempre es algo que cambia. Si el panorama competitivo en tu industria cambia, entonces la perspectiva válida sobre un problema dado también cambia. Por lo tanto, este libro debe estar bien escrito y mantenido.

Este es un esfuerzo muy distribuido en tu empresa porque, por ejemplo, solo el equipo de merchandising tiene la perspectiva e información adecuada para saber cómo se deben documentar las tablas de merchandising en primer lugar. Esta preparación de datos se ve como materiales limpios y bien escritos que se distribuyen ampliamente y son accesibles en tu empresa.

Lo interesante es que una vez que tienes todos esos conocimientos, la transformación de datos, que es la lógica, se convierte en una interpretación sencilla de la comprensión válida de los propios datos. Necesitas poner una gran cantidad de esfuerzo para comprender los datos, documentarlos, escribirlos y mantenerlos. Pero una vez que hayas 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, una comprensión compartida, una especie de biblia de la cadena de suministro que es interna en tu empresa.

Kieran Chandler: ¡Suena bien! Entonces, ¿tonos de gris de datos, será un nuevo éxito de ventas que vendrá de la organización?

Joannes Vermorel: Posiblemente, ¿quién sabe?

Kieran Chandler: Bueno, esperamos que hayas disfrutado del episodio de hoy sobre la preparación de datos. Como siempre, ponte en contacto si tienes más preguntas y nos vemos la próxima vez en Lokad TV. Hasta luego por ahora.