00:00:07 Hacer de los datos malos un chivo expiatorio en proyectos de supply chain.
00:00:33 Por qué los datos malos son una excusa fácil para el fracaso del proyecto.
00:01:42 Desafíos con los datos malos y conceptos erróneos sobre su calidad.
00:03:16 Dificultades para acceder a datos de sistemas ERP y desafíos con proveedores.
00:06:32 Problemas que surgen durante la migración entre sistemas ERP y la corrupción de datos.
00:08:01 Abordar entradas de datos incorrectas y su impacto en los sistemas ERP.
00:09:48 Forecast y detección de problemas en datos históricos.
00:11:37 Cómo la evolución de la semántica y los cambios en las definiciones pueden generar problemas con los datos.
00:12:20 Problemas de escalabilidad y optimizar la recuperación de datos a medida que las empresas crecen.
00:14:45 Desafíos en la creación de extracciones diarias limpias y el potencial de errores en los datos.
00:16:02 El impacto de tiempos de procesamiento más largos en la resolución de problemas en departamentos de TI.
00:17:15 El problema de la semántica de los datos y los malentendidos en la interpretación de los datos.
00:19:22 La importancia de la documentación para cada campo de datos para asegurar una comprensión adecuada.
00:21:01 El rol de los profesionales de supply chain y del departamento de TI en la comprensión de la semántica de los datos.
00:23:59 La variedad de problemas bajo el paraguas de los datos malos e identificar las causas fundamentales.
Resumen
En esta entrevista, Kieran Chandler y Joannes Vermorel discuten el papel de los datos en la optimización de supply chain y los desafíos que enfrentan los software vendors y los profesionales. Vermorel destaca que el problema principal no son los “datos malos”, sino el acceso y la utilización efectiva de los mismos. Los desafíos incluyen sistemas obsoletos, documentación inadecuada y responsabilidades en el acceso a los datos. Los conflictos de interés con integradores, problemas en la migración de sistemas, forecast y escalabilidad también suponen problemas. Para optimizar supply chain la gestión, las empresas deben comprender y abordar los problemas de datos, invertir en una documentación adecuada, clarificar la semántica de los datos y mantener expectativas realistas, en lugar de culpar a los datos por los fracasos.
Resumen Ampliado
En esta entrevista, Kieran Chandler y Joannes Vermorel, el fundador de Lokad, discuten el papel de los datos en proyectos de optimización de supply chain y los desafíos que enfrentan los software vendors y los profesionales de supply chain. Comienzan abordando la noción de que los “datos malos” se usan a menudo como chivo expiatorio para el fracaso de proyectos de supply chain. Vermorel señala que culpar a los datos es una forma conveniente de evitar echar la culpa a las personas, que podrían tomarlo de manera personal y reaccionar. Sin embargo, también enfatiza que es crucial entender la causa raíz del problema.
Vermorel afirma que los problemas relacionados con los datos son probablemente la principal causa de fracaso en proyectos de optimización de supply chain, pero la percepción de los “datos malos” suele estar equivocada. Sostiene que la mayoría de las empresas occidentales han contado con datos precisos durante décadas, gracias al uso de códigos de barras, escáneres de códigos de barras y otras tecnologías. El verdadero problema, según Vermorel, no es la calidad de los datos en sí, sino los desafíos en el acceso y la utilización de los mismos.
Uno de los principales desafíos para utilizar los datos de manera efectiva es acceder a ellos. Muchas empresas han estado utilizando varios sistemas de enterprise resource planning, sistemas de gestión de warehouse (WMS), sistemas de gestión de transporte (TMS) y otras soluciones de software durante años, pero estos sistemas pueden ser difíciles de utilizar a la hora de exportar datos. Vermorel identifica algunos escenarios donde el acceso a los datos puede ser particularmente problemático:
1 Sistemas antiguos: Algunas empresas aún utilizan sistemas de hace 40 años, con backends obsoletos y propietarios que hacen la extracción de datos extremadamente difícil. 2 Falta de documentación: Los software vendors pueden no proporcionar documentación adecuada para sus sistemas, lo que dificulta comprender y navegar entre las numerosas tablas y campos que se encuentran en las bases de datos. 3 Responsabilidad y acceso: Determinar quién es responsable de otorgar el acceso a los datos puede ser un desafío, ya que involucra a múltiples partes interesadas dentro de una empresa, incluyendo al software vendor, IT department, y a los profesionales de supply chain.
La entrevista resalta la importancia de entender y abordar los desafíos relacionados con los datos en proyectos de optimización de supply chain. Aunque la calidad de los datos en sí no suele ser el problema, las dificultades para acceder y utilizarlos pueden contribuir al fracaso de estos proyectos. Identificar y abordar las causas fundamentales de estos desafíos es esencial para asegurar el éxito de las iniciativas de optimización de supply chain.
Se adentran en los problemas de datos que pueden surgir a partir de las relaciones con los software vendors, integraciones de sistemas y la escalabilidad a medida que las empresas crecen.
Un problema clave que discuten es la posibilidad de conflictos de interés con los integradores, quienes pueden estar más interesados en vender sus propias soluciones de optimización de supply chain en lugar de cooperar con el software vendor elegido por la empresa. Esto puede llevar a que las empresas sean tomadas como rehenes por sus integradores, haciendo difícil acceder o utilizar sus datos de manera efectiva.
Otro desafío surge durante la migración de un sistema de Enterprise Resource Planning (ERP) a otro, lo que puede conducir a una pobre calidad de los datos o a una “integración basura.” Aunque las entradas individuales de datos pueden ser precisas, el proceso de migrar datos históricos entre sistemas puede introducir errores, ya que a menudo no existe una correspondencia directa uno a uno entre los datos en el sistema antiguo y el nuevo. Esto puede llevar a la corrupción de datos, que posiblemente no tenga un impacto significativo en las operaciones diarias pero que puede resurgir como un problema al intentar proyectos de optimización de supply chain o de procesamiento de datos.
La entrevista también aborda el forecast basado en datos históricos, lo cual puede ser difícil debido a la incertidumbre inherente del futuro. Detectar problemas en los datos históricos es más sencillo cuando los problemas son evidentes, como brechas o cambios súbitos en los datos. Sin embargo, cambios sutiles en la semántica o en las definiciones a lo largo del tiempo pueden conducir a problemas más difíciles de detectar, especialmente al migrar entre sistemas.
A medida que las empresas crecen, la escalabilidad también puede introducir problemas de datos. Para las empresas más pequeñas, el conjunto completo de datos históricos a menudo cabe en un smartphone, haciendo que la optimización sea una preocupación menor. Sin embargo, a medida que las empresas crecen, el mero volumen de datos puede convertirse en un problema. La discusión enfatiza la importancia de entender y abordar estos problemas de datos para optimizar la gestión de supply chain de manera efectiva.
Vermorel explica que las empresas a menudo tienen dificultades para extraer datos de sus sistemas de Enterprise Resource Planning (ERP), ya que estos sistemas no están diseñados para proporcionar incrementos diarios limpios de datos. Esto resulta en procesos complejos, que pueden llevar a una extracción incorrecta de datos e introducir errores. Depurar y solucionar estos problemas puede volverse una tarea que consume mucho tiempo, llevándose semanas en lugar de horas, debido a la cantidad de datos involucrados y los lentos tiempos de procesamiento.
Muchas empresas creen que tienen buenos datos, pero en realidad, la semántica de los datos a menudo no está clara. Esto puede llevar a malentendidos y cálculos engañosos. Por ejemplo, una “fecha de pedido” puede tener múltiples interpretaciones, como el momento en que el cliente realizó el pedido, el momento en que se registró en el sistema o el momento en que se confirmó el pago. Para evitar malinterpretaciones, Vermorel sugiere que las empresas deben contar con una documentación detallada para cada campo y tabla en sus sistemas de datos, que refleje la complejidad de su supply chain.
Un problema común en la optimización de supply chain es que los profesionales pueden no dedicar suficiente tiempo a calificar sus datos, lo que lleva a que los software vendors trabajen con información incompleta o poco clara. Esto puede resultar en una situación de “garbage in, garbage out”, donde los datos no son necesariamente incorrectos pero se malinterpretan debido a una documentación deficiente.
Para abordar estos problemas, Vermorel enfatiza la importancia de identificar la causa raíz del problema, que generalmente involucra a las personas y las estructuras organizativas. Las empresas deben entender quién es responsable del fallo y trabajar para solucionar los problemas subyacentes, en lugar de simplemente culpar a los datos. Los software vendors también deben ser honestos acerca de los desafíos y el tiempo requerido para aclarar la semántica de los datos, en lugar de ser excesivamente optimistas para cerrar acuerdos.
Las empresas deben invertir en una documentación adecuada, en una semántica de datos clara y en expectativas realistas para optimizar su supply chain y prevenir fracasos derivados de problemas de datos.
Transcripción Completa
Kieran Chandler: Hoy en Lokad TV, vamos a comprender por qué este es un diagnóstico tan impreciso y también a entender cuáles son algunos de los desafíos de datos que pueden enfrentar tanto los software vendors como los profesionales de supply chain. Entonces, Joannes, ¿por qué los datos malos son una excusa tan fácil?
Joannes Vermorel: Primero, porque los datos no pueden quejarse. Nadie va a defenderlos, así que estás culpando a algo inerte, lo cual es mejor que echarle la culpa a un colega que se lo tomaría de manera personal y respondería. Pero la realidad es que, cuando se llega a la causa raíz, siempre son las personas las responsables del problema. Culpar a los datos es como saltarse el paso de identificar la causa raíz del problema.
Kieran Chandler: Definitivamente es fácil atacar algo que no se va a defender. Entonces, ¿cómo podemos ser más precisos? ¿Cuáles son algunos de los desafíos?
Joannes Vermorel: Los problemas relacionados con los datos son probablemente la causa número uno de fracaso en proyectos de optimización de supply chain. Pero existen algunos conceptos erróneos. Cuando la gente dice “datos malos”, se refiere a números corruptos o incorrectos. Sin embargo, la mayoría de las empresas occidentales han tenido datos muy precisos durante décadas. Casi nadie ingresa números de parte incorrectos o comete errores tipográficos. Utilizan códigos de barras, escáneres de códigos de barras y otros trucos como el RFID. Así que la cantidad de datos verdaderamente malos suele ser una fracción muy pequeña, y no es suficiente para explicar por qué la mayoría de las iniciativas que fracasan debido a problemas relacionados con datos en realidad fracasan.
Kieran Chandler: Si la gran mayoría de las empresas occidentales están recolectando datos bastante buenos, ¿cuáles son algunos de los desafíos que podemos encontrar que realmente nos hacen pensar que los datos no son tan buenos?
Joannes Vermorel: El primer problema es acceder a los datos. Te sorprendería. Las empresas han estado operando con diversas versiones de ERPs, WMS, TMS u otro software empresarial para gestionar y operar sus negocios a diario durante décadas. Pero la mayoría de esos sistemas no son muy amigables cuando se trata de exportar datos. En algunos casos, tienes sistemas tan antiguos que ni siquiera cuentan con una base de datos relacional SQL adecuada que respalde el sistema. En este tipo de situación, es realmente difícil extraer los datos porque el backend es típicamente completamente obsoleto y propietario.
Kieran Chandler: Entonces, ¿quién está a cargo de hacer eso?
Joannes Vermorel: Hay múltiples responsabilidades aquí. Primero, puede haber el software vendor que no proporcionó ninguna documentación significativa sobre el sistema. En el peor de los casos, abres tu base de datos y te das cuenta de que tu ERP contiene 2,000 tablas, cada una con 20 a 200 campos, y eso es una pesadilla. Es completamente enorme, y no sabes por dónde empezar. Aunque, donde buscar, puedes tener un problema con el vendor, luego puedes tener un problema con el integrador. El problema con el integrador es que podrías tener un conflicto de intereses. Algunos integradores podrían tener un vivo interés en venderte su propia receta para la optimización de supply chain, para este módulo o aquel módulo o algo similar. Y cuando les pides básicamente hacer una extracción de datos para ti, para tus equipos internos o para cualquier iniciativa que quieras llevar a cabo con otro vendor, el integrador puede – sucede, lo hemos visto muchas veces – ser simplemente poco cooperativo. Porque, de nuevo, para ellos, es simplemente de interés estratégico ser no competitivos. Y aquí, se presenta una situación de rehenes donde la empresa es, de hecho, tomada como rehén por el integrador. La empresa, la compañía de TI responsable de configurar, a veces alojar, y en general, mantener el ERP o el otro sistema informático de la empresa. Así que ese es otro tipo de problema de datos. Pero ves, tiene muy poco que ver con los datos.
Kieran Chandler: Sí, definitivamente. No poder acceder a tus datos suena como un gran obstáculo. ¿Y qué hay de algunos de los otros desafíos que pueden presentarse? Y un gran dolor de cabeza que muchos de nuestros clientes tienen es cuando migran de un sistema ERP a otro sistema ERP. Entonces, ¿qué puede hacer eso a los datos?
Joannes Vermorel: No se puede cerrar de esa manera porque causa problemas. Esa es la clase de situación en la que puedes tener otro tipo de datos malos. Pero aquí, lo que realmente es malo es cuando tienes una integración basura. Así que digo que, típicamente, las entradas de datos son correctas, pero cuando pasas de un ERP a otro, lo que puede ser el proveedor o tal vez el integrador, quizá tu departamento interno de TI, lo que van a intentar hacer es básicamente migrar los datos históricos del sistema antiguo al nuevo. El problema es que no existe una correspondencia uno a uno entre, ya sabes, lo que se registraba como ventas en el sistema antiguo y lo que se registra como ventas en el sistema nuevo. Tal vez las cosas estén organizadas de manera diferente, y por ello no hay una forma clara de reportar AR del sistema antiguo al nuevo. Y luego terminas con integraciones tentativas que pueden llegar a la corrupción de datos, pues si, diría, haces una reintegración incorrecta de tu historial, no se impedirá que tu empresa opere día a día. Verás, si el East Oracle se importa de manera incorrecta al nuevo sistema, para la mayoría de las operaciones diarias no tendrá impacto. E incluso si tiene impacto, normalmente alguien simplemente hará una solución rápida para algo que esté incorrecto y continuará. Así que podría ser una fuente de fricción continua, pero primero, desaparece rápido porque, por ejemplo, si la gente se tropieza, digamos que tienes códigos de proveedor que han sido importados de manera incorrecta. Quiero decir, lo más probable es que no tengas un millón de proveedores, así que tus 100 proveedores más frecuentes probablemente se arreglarán en cuanto a corregir las entradas de datos incorrectas en dos semanas a partir de la fecha en que empieces a usar el nuevo sistema. Y quizá, tres meses después, prácticamente hayas corregido cada única entrada de proveedor incorrecta. Pero el problema es el código histórico; la gente no va a retroceder y arreglar, ya sabes, los datos históricos. Así que, digamos que tenías como cinco años de historial, tal vez tres
Kieran Chandler: En el futuro, ¿qué tan fácil es detectar esos problemas que pudieron haber ocurrido en el pasado?
Joannes Vermorel: Es fácil detectar esos problemas cuando existen fallos visibles, como datos faltantes durante algunos meses. Sin embargo, puede haber cambios sutiles que sean más difíciles de detectar, como las diferencias en cómo se cuentan las ventas, si se incluyen o no el fraude o las devoluciones. Esto puede llevar a muchos problemas que resultan difíciles de identificar en los datos históricos porque la propia definición de los datos que estás observando ha cambiado a lo largo del tiempo, y no es obvio a menos que haya un pico o salto notable.
Kieran Chandler: Otro problema común con los clientes con los que hablamos es la escalabilidad. A medida que una empresa crece, sus datos comienzan a volverse más desordenados. ¿Cuáles son los problemas que la escalabilidad puede introducir?
Joannes Vermorel: Cuando no tienes problemas de escalabilidad, puedes simplemente copiar todos los datos de la compañía cada día. Para las empresas más pequeñas, esto puede ser manejable ya que su historial completo podría ser menor a 10 gigabytes. Sin embargo, al crecer a empresas más grandes, terminas con muchos más datos, y necesitas optar por una extracción incremental de datos. Esto significa extraer una porción de los datos cada día, y algunos sistemas no están diseñados para manejar esto de forma eficiente o precisa. Por lo tanto, necesitas hacer cosas complicadas para construir una extracción diaria limpia, y en ese proceso, te expones a problemas potenciales.
Kieran Chandler: Entonces, al final, terminas con datos malos simplemente porque quieres hacer la extracción de datos de manera incremental, y es complicado porque el sistema podría no haber sido diseñado para esta tarea. Cuando piensas en depurar, solo quieres copiar datos de un lugar a otro, y puede ser un problema muy mundano. Si el proceso toma un minuto, alguien en tu departamento de TI puede invertir cinco minutos, iniciar el proceso y estar seguro de que funciona. Sin embargo, si el proceso tarda seis horas en completarse, se convierte en un proceso más tedioso. ¿Puedes explicar los desafíos en esta situación?
Joannes Vermorel: Claro. Imagina que tienes un sistema en el que el proceso tarda seis horas en completarse. En tu departamento de TI, alguien va a iniciar el proceso, esperar 10 minutos, darse cuenta de que está tomando demasiado tiempo y hacer otra cosa. Incluso podrían olvidarse de ello. Al día siguiente, podrían notar un pequeño error que causó un fallo después de seis horas. Para reproducir el problema, se necesitan otras seis horas de espera. Como resultado, terminas con problemas que deberían poder solucionarse en apenas unas pocas horas, pero debido a la mayor complejidad y a los tiempos de procesamiento más largos, se transforman en un proceso muy tedioso donde los retrasos totales se extienden a semanas. No porque sean semanas de esfuerzo, sino porque la gente lanza el proceso, se olvida de él y regresa al día siguiente. Esto genera iteraciones muy lentas.
Kieran Chandler: ¿Qué tan extendidos dirías que son estos problemas? ¿Hay muchas empresas que realmente creen que tienen muy buenos datos, pero en realidad, cuando se observa por debajo de la superficie, no son tan buenos?
Joannes Vermorel: Sí, existe otro problema que no hemos discutido, que es la semántica en sí. Muchas empresas creen que tienen buenos datos, pero en realidad, los datos tienen una semántica desconocida. A lo que me refiero es, por ejemplo, cuando hablamos de una fecha de pedido, hay muchas interpretaciones potenciales. Podría ser la fecha de pedido del cliente, la hora en que se realizó el pedido en el sitio web, la registrada en el sistema o incluso cuando se confirmó que el pago era válido. Podrían haber 20 interpretaciones diferentes de lo que significa esa fecha de pedido.
When we start working with clients, we typically encounter tables and columns with little documentation. But when we’re done preparing the data, we have nearly one page of documentation per field per table. A typical supply chain situation has about 20 tables with 20 fields, so we’re talking about 400 pages worth of documentation just to clarify what the data means. People are usually very surprised by this, but it’s necessary to understand the data properly.
Kieran Chandler: Joannes, ¿puedes hablar sobre la importancia de entender adecuadamente los datos en la optimización de supply chain?
Joannes Vermorel: Sí, solo la complejidad de tu supply chain que se refleja en estos datos, y si no realizas este trabajo, terminas con datos que no entiendes adecuadamente. Así, es basura entra, basura sale. No es que los datos sean basura, en el sentido de que los números estén equivocados, sino que no sabes lo que significan. Entonces, si tienes una fecha que no entiendes correctamente, cualquier cálculo o modernización que vayas a hacer terminará en algo engañoso. Por lo tanto, la semántica de los datos es la conclusión clave, y la documentación debe estar en su lugar antes siquiera de comenzar un proyecto.
Kieran Chandler: Entonces, ¿de quién es la culpa cuando se trata de semántica?
Joannes Vermorel: Diría que los profesionales de supply chain deberían estar a cargo. La mayoría diría que es un problema de TI. Pero, cómo interpretes la semántica de los datos realmente depende del proceso que tengas. Si cuentas con el proceso en el que escaneas productos en la entrada del almacén porque tienes ese procedimiento, extraído por el departamento de TI, ellos no están en el terreno dentro del almacén, por lo que no saben exactamente cómo está configurado tu proceso. Las únicas personas que saben exactamente son aquellas para quienes estos datos son simplemente el resultado de un proceso que se genera; son las primeras en el sistema. Entonces, mi punto es: no esperes que TI, que solo gestiona las máquinas, asegurándose de que el software tenga suficiente ancho de banda de memoria computacional y disco, tenga los conocimientos, habilidades y entendimiento para captar lo que significan los datos. Lo que significan los datos es, generalmente, un problema muy específico del negocio. No es un problema de TI en absoluto. Así que, típicamente, la culpa también recae frecuentemente en el lado del profesional. Los profesionales no han dedicado suficiente tiempo para calificarlo adecuadamente con sus propias palabras y su propio entendimiento. Por ello, cuando se trata de optimización de supply chain, terminas con un proveedor que finalmente trata estos datos a medio cegas. Eso resulta en basura entra, basura sale.
Kieran Chandler: Entonces, ¿puede también tener la culpa el proveedor?
Joannes Vermorel: Sí, obviamente, el proveedor también puede tener la culpa. Empresas como Coke Ad que están haciendo optimización de supply chain, y típicamente cuando se culpa al proveedor, es porque éste está intentando ser elegante. Usualmente, tratan de minimizar su desafío porque están tratando de vender un problema. Están discutiendo maneras como, “Confía en nosotros. Va a ser pan comido. Lo haremos en cuestión de semanas. Boom, lo haremos de esa manera, y funcionará.” La realidad es que, si le dices a un director de supply chain, “Me temo que solo para calificar tus datos se van a necesitar seis meses, y lo siento, deberías haberlo hecho, pero no lo hiciste, así que tendremos que hacerlo por ti”, obviamente, es difícil cerrar este tipo de acuerdo. Por lo tanto, es mucho más fácil ser demasiado optimista, pero eso es una receta para el fracaso. Entonces, el proveedor tiene que asumir la culpa porque debería saber mejor. Tal vez el cliente no sepa mejor porque es la primera vez que intenta hacer un proyecto de optimización predictivo de Supply Chain Quantitativa. Pero luego, el proveedor, que por definición, probablemente no es su primera vez en esto, debería saber mejor. Por ello, si se diagnostica una situación en la que este tipo de datos es inexistente, entonces ellos deberían
Kieran Chandler: Entonces, básicamente, deberían advertir al cliente que se avecinan quizás múltiples meses de esfuerzo solo para aclarar la semántica de los datos de modo que estos puedan ser calificados como buenos. Pero no es que fueran realmente malos al principio. Así que, bueno no es lo opuesto a malo en esta situación; es simplemente que bueno es más bien lo opuesto a datos oscuros o datos no calificados o datos desordenados.
Joannes Vermorel: Bien, y para concluir hoy, hay una amplia gama de problemas diferentes que en realidad entran en esa categoría de datos malos. Diría que trates de asegurarte de identificar la causa raíz del problema, y usualmente, son las personas. Quiero decir, obviamente, cuando digo que son las personas, no quieres culpar a James del departamento de TI por ser responsable del desorden. Pero cuando digo que el problema son las personas, necesitas entender exactamente quién tiene la responsabilidad del fallo, y tal vez esa persona fue puesta en una situación en la que no pudo hacer otra cosa que fracasar.
Ves, se puede concluir que James del departamento de TI ha fracasado, pero también que la propia organización ha puesto a este pobre James en una posición en la que no tenía otra opción más que fracasar, hablando de manera realista. Es interesante que empieces a ver el problema desde un ángulo que, al menos, te da pistas sobre cómo vas a solucionarlo en lugar de decir que los datos eran malos, simplemente malos, datos malos. Y luego, si realizaras otra iniciativa, repetirías el mismo problema, los mismos errores, y así terminarías con el mismo fracaso al final del día.
Kieran Chandler: Bien, si el jefe de James está viendo, espero que esté siendo comprensivo. De todos modos, eso es todo por esta semana. Muchas gracias por sintonizar, y nos veremos de nuevo la próxima vez. Adiós por ahora.
