Tus datos son mejores de lo que crees

00:00:00 Datos mejores de lo que crees
00:03:43 Por qué los datos malos se convierten en un chivo expiatorio
00:07:26 Hechos transaccionales versus basura de parámetros
00:11:09 El “pastel” de la capa de reportes rompe la toma de decisiones
00:14:52 Vista centrada en la decisión de la información útil
00:18:35 Automatizar parámetros: lead times, estacionalidad, novedad
00:22:18 La complejidad del ERP no es sinónimo de datos malos
00:26:01 Los campos de fecha ocultan múltiples significados en el mundo real
00:29:44 La semántica se demuestra con decisiones generadas
00:33:27 Los valores atípicos exponen métodos deficientes, no datos malos
00:37:10 Los data lakes deben copiar, no “mejorar”
00:40:53 La calidad de los datos se mide en dólares
00:44:36 Preparación para IA: transacciones confiables, semántica primero
00:48:19 La ejecución en doble corrida requiere operación completamente sin intervención
00:52:02 Juegos de culpas entre proveedores: la historia de advertencia de Lidl-SAP
00:55:45 La calidad equivale a la aptitud para la toma de decisiones

Resumen

“Los ‘datos malos’ son a menudo un chivo expiatorio. Los registros transaccionales de la mayoría de las empresas—lo que se compró, vendió, envió, devolvió—son lo suficientemente buenos, o de lo contrario no sobrevivirían. El verdadero lío es la montaña de parámetros mantenidos manualmente y la confusión sobre lo que los campos realmente significan (semántica), especialmente en los extensos ERPs. No “limpies” la realidad para salvar métodos débiles: los valores atípicos a menudo representan el negocio. Juzga los datos por los resultados: si las decisiones mejoran la rentabilidad, los datos fueron suficientes; si los resultados son absurdos, corrige la interpretación.”

Resumen Extendido

Una queja común en supply chain es que los “datos malos” bloquean el progreso. Sin embargo, gran parte de lo que se llama datos malos no es ni malo ni siquiera central para el problema. A menudo es una excusa conveniente—a veces por parte de proveedores que necesitan culpar a alguien más cuando su software falla, y a veces por parte de analistas formados con conjuntos de datos ordenados de aula que se sorprenden por la gran extensión de los sistemas empresariales reales. Un ERP con miles de tablas no es evidencia de datos malos; es evidencia de complejidad.

La conversación traza una línea divisoria entre dos tipos de “datos.” Primero está la realidad transaccional: lo que se compró, vendió, envió, devolvió, desechó, pagó—eventos con consecuencias financieras. Esta información suele ser confiable, por una simple razón: las empresas que no pueden mantener la verdad transaccional básica no duran mucho. Los mercados castigan rápidamente ese nivel de confusión. Los errores existen, pero generalmente en bajas proporciones.

Segundo, está la montaña de parámetros mantenidos manualmente—objetivos de nivel de servicio, coeficientes de stock de seguridad, indicadores de estacionalidad y lead times ingresados por empleados. Estos “artefactos numéricos” suelen estar desactualizados, ser inconsistentes y costosos de mantener a gran escala (millones de SKUs multiplicados por múltiples parámetros). Pero el punto importante es que a menudo son innecesarios. Muchos de estos insumos deberían inferirse a partir del historial observado o automatizarse mediante métodos mejores. Tratar estos parámetros como “datos centrales” crea una carga autoimpuesta.

Un problema oculto importante es la semántica: lo que un campo significa. La misma columna puede cambiar de significado con el tiempo, a través de procesos empresariales, o incluso según el signo (venta vs devolución). La documentación suele ser escasa al principio. La única manera fiable de validar la semántica no es mediante interminables talleres, sino poniendo las interpretaciones a prueba: generar decisiones reales—qué comprar, producir, almacenar, fijar precios—y ver si los resultados se vuelven absurdos. Cuando eso ocurre, se hace ingeniería inversa en el proceso para encontrar la suposición errónea.

Esto también replantea el concepto de “datos ruidosos.” Si los clientes a veces ordenan 1 y a veces 100, eso no es datos malos—es el negocio. Los métodos que colapsan ante los valores atípicos son defectuosos; no se deben falsificar los datos para rescatar matemáticas débiles.

Finalmente, en lo que respecta a la “preparación para IA”: el estándar no es la pureza moral de los datos. Es la adecuación al propósito. Si sabes qué compras, fabricas y vendes, puedes comenzar. El verdadero trabajo es mapear la semántica sistema por sistema, y luego iterar rápidamente hasta que las decisiones sean sensatas. Al final, la calidad no es un eslogan; se mide por el desempeño económico de las decisiones.

Transcripción Completa

Conor Doherty: Esto es Supply Chain Breakdown, y hoy vamos a analizar por qué tus datos son, de hecho, mejores de lo que crees. Muchas empresas nos dicen que sus datos son lo que les impide iniciar los proyectos que desean. Bueno, hoy estamos aquí para desafiar esa idea. Estamos siendo constructivos.

¿Quiénes somos? Bueno, yo soy Conor, Director de Marketing aquí en Lokad. A mi izquierda, como siempre, el fundador de Lokad, Joannes Vermorel. Ahora, antes de comenzar, háznoslo saber abajo: primero, ¿desde dónde nos estás viendo? Nosotros estamos en París. Y segundo, ¿estás de acuerdo, o incluso crees, que los datos maestros son de hecho un cuello de botella para los proyectos de transformación digital, del tipo en que las empresas realmente quieren involucrarse en estos días? Deja tus comentarios y preguntas abajo. Nos ocuparemos de ellos un poco más adelante.

Y con eso, Joannes, a la discusión. Ahora, antes de entrar en materia, un poco de contexto: cómo surgió esta discusión. Como sabes, descubre lo que hay detrás: al final de cada episodio, digo, “Hey, si quieres continuar la conversación, contacta a Joannes y a mí de manera privada. Estamos encantados de hablar.” Todo lo cual es cierto. Bueno, algunas personas hacen eso. Quieren hablar.

Y recientemente, de manera colectiva e individual, hemos tenido discusiones, y un tema recurrente entre los profesionales es quejarse del estado de los datos: por ejemplo, “Mis datos maestros son un espagueti,” “Mi ERP es queso suizo,” lo que sea. Pero, ese es el problema. Eso es lo que me impide hacer todas las cosas geniales que quiero hacer. Y así llegamos al tema de hoy.

Entonces, Joannes, ¿por qué los datos tienen tan mala fama en supply chain?

Joannes Vermorel: Puedo pensar en varias razones, dependiendo del público.

Para software vendors, los datos malos son el chivo expiatorio definitivo. Es una forma de culpar educadamente pero con firmeza a los clientes por cualquier defecto que tenga el producto de software. Así que es extremadamente conveniente, y los buenos vendors, los vendors talentosos, lograrán convencer a los clientes de que todo fue culpa de ellos si todo se vino abajo porque tenían prácticas de datos insuficientes, aseguramiento de calidad y demás.

Pero mi parecer aquí: realmente se trata de echar la culpa a otros. El segundo público son los data scientists, especialmente los data scientists que provienen de esto… que han participado, diría yo, en competiciones de Kaggle. Están acostumbrados, especialmente en la universidad, a conjuntos de datos que son súper ordenados y meticulosos, y piensan que eso es lo normal. Piensan que tener un conjunto de datos donde hay cinco tablas, cada tabla tiene cinco campos, y se cuenta con documentación extensiva para cada campo, y es muy, muy claro—vale. Para mí, eso es un problema de expectativas completamente poco realistas.

En las empresas, quiero decir, si tomamos ERPs de mercado medio, vamos a hablar de 10,000 tablas. Algunas tablas tienen 50 campos. De eso se trata. Entonces, aquí tenemos un problema de data scientists que tienen expectativas completamente irrazonables sobre lo que en realidad son los datos corporativos.

Y hay un tercer segmento, que son los practicantes. La cuestión es: lo que están observando es, típicamente, la parametrización de su sistema de negocio. No están mirando nada real, como por ejemplo: una unidad vendida en esta fecha, a este precio. Normalmente, esa no es la preocupación. No se trata de esos eventos transaccionales clave del pasado.

Lo que están observando es: “Oh, pero mira, las configuraciones de estacionalidad que ingresamos en el APS hace dos años, ahora están completamente fuera de lugar por esto, por aquello.” “Mira, tenemos tantos coeficientes correctivos para la fórmula de safety stock, y también están completamente desfasados,” etc. Así que, en realidad, cuando esos practicantes se quejan de datos malos, se quejan muy específicamente de artefactos numéricos—cosas que no representan el pasado ni el futuro. Representan algún tipo de parametrización de las políticas de la empresa.

Y mi opinión es: si volvemos al primer caso, que fue el software vendor, el problema es que si la solución de software que usaste depende tan fuertemente de esta parametrización que se mantiene manualmente, entonces es seguro que te estás encaminando hacia problemas. Por lo tanto, la única solución es dejar de tratar esas cosas como si fueran lo que son. Ni siquiera deberían formar parte del panorama, para que no tengas que lidiar con ellas.

Conor Doherty: Así que, corrígeme si me equivoco, pero parece que lo que estás diciendo es que existen, en términos generales, dos categorías de datos. Entonces, cuando la gente usa el término “data”, inherentemente está pensando en dos categorías. Una es a lo que llamas los artefactos numéricos—las cosas que se han propuesto a sí mismos, ciertos objetivos—pero la otra es la verdadera data transaccional en bruto, y ves esa como algo mucho, mucho más importante.

Joannes Vermorel: Sí. Quiero decir, la verdadera data transaccional es aquello que ocurrió. De nuevo: vendiste o no vendiste. Pagaste al proveedor, realizaste un pedido, sacaste una unidad del stock, destruiste una unidad que era en realidad perecedera y que ya superó su vida útil, etc., etc. Esos son transaccionales, y usualmente son excelentes.

Sin embargo, lo que también tienes, en muchas soluciones empresariales, es una montaña de parámetros que se supone deben ser mantenidos por empleados administrativos—personas que simplemente operan el sistema. Y la cuestión es: ¿por qué siquiera necesitas tener esa infinidad de parámetros? Porque muy frecuentemente estamos hablando de una enorme cantidad de parámetros.

Solo para tener una idea de la escala: una empresa que tiene un millón de SKUs, lo cual en realidad no es tan grande—si tienes, digamos, 10 parámetros por SKU, y siendo conservador aquí, podría ser mucho más—10 parámetros por SKU, así que estamos hablando de 10 millones de parámetros que deben ser mantenidos más o menos manualmente. Y eso es una locura.

Luego, la gente dice, “Oh, esto es una porquería porque realmente no podemos mantenerlo.” Yo diría: sí, absolutamente. Pero la realidad es que realmente no lo necesitas. Y todas esas cosas, en verdad, no transmiten información porque la forma en que se establecieron esos parámetros fue, de todas formas, al observar el resto de la data.

Cuando las personas establecen, digamos, un objetivo de service level, lo hicieron al observar el historial transaccional. Así que ya ves, esta información es, de hecho, completamente transitoria, y no debería considerarse como parte de tu data principal. Por eso digo: los datos malos son un problema mucho, mucho menor de lo que la gente espera. Es simplemente porque tratan como data una gran porción de cosas que no deberían.

También hay un segundo ángulo, pero ese es un problema separado. Es cuando la gente quiere hacer un análisis adicional basado en datos preprocesados, especialmente aquellos que se obtienen de la capa de informes.

De nuevo, divido el software empresarial en tres clases: sistemas de registro—eso va a ser los ERPs sin la planificación, porque no hay planificación involucrada—, sistemas de informes, que serían business intelligence y todos esos sistemas para dashboarding e informes, y luego sistemas de inteligencia, los que realizan decision-making.

La única fuente de verdad de la data reside en los sistemas de registro. Pero muy frecuentemente, porque las personas a veces están mal orientadas, o ocupadas, o lo que sea, quieren explotar la data tal y como se presenta desde el sistema de informes. Y aquí nos encontramos en una situación que, como analogía, es muy parecida a la de un cocinero.

Te imaginas que tienes una cocina, tienes todos los ingredientes crudos—harina, azúcar, sal—y ese es un sistema de registro, los ingredientes crudos. Y luego el cocinero, a través del sistema de informes, puede preparar un pastel. Tienes un pastel, es agradable, puedes consumirlo. Está destinado para el consumo humano, así que funciona.

Ahora le estás pidiendo al cocinero: “Simplemente toma este pastel y hazle otra cosa.” Y eso es exactamente lo que sucede cuando intentas usar la data que proviene de tu capa de informes para, por ejemplo, impulsar procesos de decision-making. Eso sale muy, muy mal. No es que el cocinero sea malo; es simplemente que si partes del pastel, no puedes hacer nada más. Ya es el producto terminado. Intentar desenmarañar el azúcar, la harina y demás—todo se pierde.

Así que necesitas volver a los ingredientes crudos si quieres hacer otra cosa. Ese es también un error típico que he visto cometer a muchas empresas: miran la data en la capa de informes, que está destinada para el consumo humano, y tratan de extraer esta data y reprocesarla para otros propósitos. Eso es un error. Necesitas volver a los ingredientes crudos.

Conor Doherty: Bueno, de nuevo, en esa línea—la idea de volver a los ingredientes crudos, volver a tu data fundamental—, en realidad tengo un… piensa lo que quieras sobre la fuente. Solo lo estoy utilizando para dar un poco de contexto que demuestre que no solo estamos especulando aquí.

Estoy mirando un informe de Gartner ahora, que encuestó a cientos de empresas muy grandes, y confirmó que la mayoría de las empresas ni siquiera miden la calidad de la data de forma consistente. Lo que realmente ocurre es que simplemente existe la sensación de que nuestra data es mala, pero no es necesariamente un hecho medido.

Entonces, hay dos preguntas aquí. Una: ¿te sorprende en general? Y dos: ¿cómo podría la gente diagnosticar rápidamente la salud de su data?

Joannes Vermorel: Primero, si miramos la data transaccional, la respuesta es simple: ¿genera tu empresa beneficios? Si es así, tu empresa tiene data de alta calidad. ¿Por qué? Porque nunca he conocido a una empresa que no supiera lo que estaba comprando, o vendiendo, o produciendo y que sobreviviera.

Si ni siquiera lo sabes, te declararás en bancarrota a la velocidad de la luz. Si no sabes qué te enviaron tus proveedores, entonces se te cobrará múltiples veces. Si no sabes lo que tus clientes realmente compraron, entonces en realidad no les estás cobrando correctamente. Es muy rápido. Es darwinismo en acción. Los mercados eliminan despiadadamente a esas empresas; desaparecen.

Entonces, como regla general: si estás en una empresa que no está al borde de la bancarrota por mala gestión, el historial transaccional es, lo más probable, de muy alta calidad. Sí, puede colarse un error administrativo, como una por cada mil—típicamente el orden de magnitud que veo en la mayoría de las empresas. Tendrás entre, digamos, 0.1% y a veces hasta 0.5% de errores administrativos, pero es muy, muy bajo. Muchas empresas están incluso por debajo de eso.

Ahora, si hablamos de todos los datos opcionales—por ejemplo, tienes una parametrización en tu sistema que te permite decidir el nivel de servicio objetivo para un SKU—¿qué significa siquiera tener datos de alta calidad aquí? Esto es un sinsentido.

Si estuviera haciendo de abogado del diablo, tendría que analizar qué tan cerca está esta configuración de maximizar la tasa de retorno de la inversión en inventario de la empresa cuando se aplica este parámetro. Nunca vamos a hacer eso. Es demasiado complicado. Si realmente adoptas la idea de que tu supply chain debería maximizar la tasa de retorno, genial, pero entonces muy, muy rápido desecharás todos esos enfoques no económicos.

En resumen: en esta parametrización, sí, tiende a haber mucha basura. La realidad es que las empresas pueden vivir con eso porque, digamos, un planificador de inventario simplemente mirará el reabastecimiento recomendado, y puede que no tenga mucho sentido, pero el mismo planificador revisará el historial reciente, algunas cosas, y en un minuto la persona dirá, “Vale, pide 50 unidades”, y luego pasará a revisar el siguiente SKU.

Así que sí, si quieres robotizar o hacer algo automatizado basado en estos datos de parametrización, la calidad de los datos es muy, muy baja. Pero la única solución es pensar en los sistemas de software como sistemas de inteligencia que no dependen de esta parametrización, la cual es solo una capacidad de soporte para un proceso centrado en el flujo de trabajo.

Conor Doherty: Bueno, solo estoy anotando una idea para profundizar en eso porque, nuevamente, siempre que es posible me gusta amplificar cualquier punto de pensamiento constructivo.

Nuestra perspectiva, como bien sabe cualquiera que nos sigue, es que el propósito de los datos, e incluso el propósito de ir a trabajar en una empresa, es tomar mejores decisiones—decisiones mejores que en realidad produzcan más dinero. Ahora, has señalado que las mejores decisiones no residen en el sistema de reportes; ya están en tus datos transaccionales.

Así que, en esencia, para que las personas tomen mejores decisiones—define “mejores” como quieras, ya que para nosotros significa maximizar la tasa de retorno—pero para todos los que escuchan, si tienes datos transaccionales, ya puedes comenzar a tomar decisiones positivas.

Joannes Vermorel: Lo que noté en casi toda la clientela de Lokad—y estamos hablando de más de 20 mil millones en flujo anual de mercancía que Lokad gestiona—es que el 99% de la información proviene, y en realidad aún más, probablemente el 99.99% de la masa de la información proviene de sistemas transaccionales.

Además, probablemente tendrás unas pocas docenas de meta-parámetros—motores económicos—que deben mantenerse manualmente. Pero aquí tenemos que ser muy conservadores, y en la práctica son solo unas pocas docenas. Así que la calidad de los datos aquí debe ser alta. Es difícil, pero hablamos de un número muy pequeño de parámetros importantes—parámetros que son lo suficientemente relevantes como para justificar varias reuniones por parámetro.

Pero al final tiene que ser un parámetro estratégico, económico y de alto nivel, no algo que esté a nivel de SKU. Todo eso debe ser completamente robotizado, y se puede hacer.

Por eso digo que los datos suelen ser excelentes, porque lo que necesitas es el historial transaccional. Si abordas un problema correctamente, no necesitas tener millones de parámetros que vivan en tu sistema, que deben mantenerse manualmente, y que pueden adoptar tantas formas.

Muchos sistemas piden a los profesionales ingresar el tiempo de entrega. Pero, ¿por qué tienes que ingresar el tiempo de entrega? Observas los tiempos de entrega de tu proveedor. Así que los tiempos de entrega deben ser forecast, no ingresados por el usuario.

Muchos sistemas piden al usuario clasificar y decir, por ejemplo, “¿Es este un artículo estacional?” ¿Por qué deberías hacer manualmente este tipo de cosas que deberían estar completamente automatizadas, incluso si lo único que tienes es la etiqueta del producto? Hoy en día, con los LLMs, nunca ha sido tan fácil automatizar este tipo de detección. “Tengo un new product; ¿mostrará este artículo patrones estacionales?” Es bastante sencillo.

No necesitas que un humano intervenga para decir, “Oh sí, una combinación de esquí, oh sí, eso va a ser estacional. Vale, gracias.” Esa es la realidad: esas son preguntas súper básicas, y todos los sistemas pedían a los profesionales que siguieran ingresando tantas cosas que son completamente obvias y que pueden ser automatizadas.

Incluso cosas que a veces resultan súper desconcertantes: los profesionales tienen que ingresar manualmente si se trata de un new product. ¿Por qué necesitas que la gente le diga al sistema que es un new product? Puedes ver que en el historial no hubo transacción. El producto se ha creado recientemente en el sistema, no hay transacciones—¿por qué necesitas configurarlo manualmente como un new product? Eso es un montón de sinsentidos.

Pero nuevamente, mi opinión es que toda la basura en esta área, en esta parametrización para todas esas políticas, refleja una forma obsoleta de ver el supply chain. Así que, sean cuales sean los malos datos que tengas en este aspecto, es irrelevante. Lo que importa es la data transaccional, y estos datos transaccionales son buenos, y lo son porque tu empresa sigue viva.

Conor Doherty: Bueno, sobre eso—y nuevamente, esto es para profundizar un poco más en las causas de la percepción—porque es inútil si solo dices, “Tengo un problema.” Es más como, “Vale, ¿cuáles son las causas de esto? ¿Cuál es la raíz de este asunto?”

Así que, al escucharte, parece que hay… vale, voy a dar un ejemplo concreto y luego puedes opinar al respecto. He escuchado, y sé que tú has escuchado, alguna versión de esto: “Mi ERP es un desastre.” Y ese es el sistema de registros del que se habla, el libro de datos transaccionales: “Tengo tablas duplicadas, columnas mal etiquetadas, es un desastre.”

Ahora, técnicamente, todos los datos transaccionales, los datos transaccionales sin procesar, están allí. El problema—si es que hay un problema, y podemos discutirlo—es: vale, la migración de ERP que hiciste produjo un desastre. Y que conste: no vendemos un ERP, podemos trabajar con cualquier cosa, así que no tenemos conflicto de intereses en ese asunto.

Pero mi pregunta para ti es: ¿qué papel tan importante tiene la selección de software en la producción de la epidemia de malos datos aquí?

Joannes Vermorel: De nuevo, aquí, diría que son expectativas equivocadas. Eso es exactamente lo que pasa cuando mencioné al segundo público: data scientists, competencia de Kaggle. No dije que el ERP, los sistemas de registros, fueran a ser ordenados y pulcros. La complejidad va a estar por las nubes, y eso está perfectamente bien.

Esto no es malos datos. Se trata simplemente de datos muy complejos y muy opacos—problemas diferentes. Ahora, sí, cuando tienes 10,000 tablas, es muy difícil precisar dónde está el nivel de stock. Es difícil, y puede tomar semanas rastrear dónde reside un dato en el sistema. Pero de nuevo, esto no es malos datos.

Luego, de hecho, tienes otro problema: la semántica para cualquier columna dada puede ser heterogénea. ¿Qué quiero decir? Quiero decir que la semántica que puede tener una determinada columna de datos podría variar dependiendo de la línea. Esa es una complicación.

Por ejemplo: algunos proveedores de ERP equivocados hace años decidieron, por ejemplo, que en la tabla de pedidos, si la cantidad era positiva, se trataba de una venta, es decir, le estás vendiendo a un cliente, y la fecha era la fecha de la transacción de la venta. Pero si la cantidad es negativa, se trataba de una devolución, por lo que era la fecha de devolución del artículo. Eso significa que tengo una columna llamada “fecha de pedido”, excepto que no es una fecha de pedido cuando la cantidad es negativa: en realidad, es una fecha de devolución.

Eso es a lo que me refiero: semántica heterogénea—que en la misma columna, dependiendo de la línea, dependiendo de ciertas condiciones, a veces es como si el ERP hubiera tenido una actualización y, a partir del 1 de enero de 2020, la fecha de pedido significara otra cosa. Fue debido a una actualización del sistema, la semántica cambió con el tiempo.

A veces incluso pueden ser los equipos que trabajan en la empresa los que, en algún momento, deciden cambiar el proceso, y vuelven a especificar cuál es la semántica de un determinado campo, por lo que adquiere una nueva semántica. Así que esto es muy complejo, sí, y descubrir esto—sí.

Pero nuevamente, ¿son malos datos? Si conoces a tu proveedor de ERP, tal vez, porque fueron un poco incompetentes en términos de diseño de software, decidieron que “fecha de pedido” podría ser ya sea la fecha de la venta o la fecha de las devoluciones—sí, es equivocada, pero ¿es mala? Yo argumentaría que los datos son simplemente buenos. Es solo una semántica confusa.

Volvemos al hecho de que es mucho trabajo restablecerlo, y eso lo reconozco. Pero cuando la gente me dice “malos datos”, muy frecuentemente digo: no, tus datos están bien. Es solo que necesitamos hacer el trabajo serio de restablecer la semántica real de tus datos, y eso es mucho trabajo.

Como regla general, cuando empezamos con clientes, típicamente ni siquiera tenemos una línea de documentación por campo, por tabla. Cuando terminamos, normalmente tenemos una página de documentación por campo, por tabla, para los campos que son realmente relevantes para la iniciativa de Lokad, que es supply chain optimization.

No obstante, 20 tablas, 20 campos—estamos hablando de 400 páginas de documentación. No es documentación de TI: es documentación de supply chain, porque necesitamos tener la semántica de lo que significa y conlleva este campo desde una perspectiva de supply chain. Así que sí, eso es mucho trabajo.

Creo que, nuevamente, bajo la excusa de los malos datos, muy frecuentemente es simplemente que mucha gente no se ha dado cuenta de la cantidad de esfuerzo que implica esta calificación semántica. Además, tenemos proveedores de software incompetentes que utilizan eso felizmente para echarle la culpa a los datos, lo cual es una manera cortés de decirle al cliente: “Es tu culpa.”

Conor Doherty: Bueno, sobre ese tema, en realidad… no sabías que iba a hacer esto, pero obviamente tu nuevo libro ya está ahí, pero en preparación para esto, en realidad volví a tu libro antiguo.

Y para los OGs que ya han leído ambos libros de Joannes, pueden sacar su copia ahora. Obviamente, el código en las últimas pocas cientos de páginas de este libro puede que no sea tan relevante hoy en día, pero las primeras… diré que las primeras cien páginas siguen siendo muy, muy relevantes.

Y para cualquiera que tenga su copia a la mano: en la página 60, sobre el tema de la semántica—y nuevamente, esto es solo para demostrar que no estás hablando de filosofía abstracta—a punto de dar un ejemplo muy concreto y hacerte una pregunta muy concreta, pero voy a leer un momento de esto porque lo encuentro muy esclarecedor.

Entonces, aquí, en la página 60: cuando nos referimos a la cantidad por día en relación con una fecha específica, la propia fecha viene con su propio conjunto de ambigüedades. Podría ser la fecha en que el cliente realizó un pedido. El cliente ha confirmado un pre-pedido. El producto ha sido enviado al cliente. La entrada del pedido finalmente llegó al ERP. La entrada del pedido fue modificada por última vez en el ERP. El pago del cliente finalmente ha sido recibido. Dijiste, etc. Pero también se podría decir cuando ha expirado la garantía o el período de devolución.

Ahora, esos son todos significados semánticos concretos para una fecha simple.

Joannes Vermorel: Sí. Para una fecha simple.

Conor Doherty: Exactamente. Pero mi punto es: ¿cuál es el daño, por ejemplo, si elijo cualquiera de esos? ¿Es como un árbol de decisiones donde, de repente, las decisiones que puedo tomar difieren enormemente? ¿Es esa la magnitud del daño? Explica por qué, para que lo entiendan.

Joannes Vermorel: Sí. La parte complicada con la semántica es que cuando te equivocas, la única manera confiable de saber que te equivocaste es que, al final de la cadena, generarás decisiones insanas.

Hasta que no tengas una cadena completamente robotizada que genere decisiones finales—asignación de recursos para supply chain: lo que compras, lo que produces, dónde almacenas las cosas, tus puntos de precio para cada artículo que vendes—mientras no tengas un data pipeline completamente sin intervención, una receta numérica que genere esas decisiones, te faltará el instrumento necesario para evaluar, para desafiar tu semántica.

Si, en tu documentación, lo escribes mal—piensas que esta fecha de pedido fue cuando se liquidó el pago; de hecho, no es así. Es cuando estás listo para enviar el artículo al cliente—la documentación está equivocada. No podrás notar eso. Nadie podrá notar eso.

Tal vez, si haces una exploración profunda específica en este campo después de dos días de trabajo, podrás corregir eso. Pero tienes que saber que hubo un error en primer lugar. Estamos hablando de, incluso para una iniciativa pequeña, cientos de campos. ¿Vas a realizar talleres de varios días para cada campo para asegurarte de que tu semántica es correcta? No es razonable.

Así que el enfoque razonable es hacer el mejor esfuerzo, la mejor suposición, y luego dejar que la decisión se genere en base a esta interpretación. Y he aquí, ocasionalmente las decisiones serán insanas. Cuando comenzamos iniciativas, generamos muchas decisiones francamente insanas.

Luego, echamos un vistazo, y la gente dice, “Oh, este número es un sinsentido.” Vale. Hagan una ingeniería inversa de lo que nos llevó a esta decisión sin sentido, y luego, al rastrear hacia atrás, hacemos ingeniería inversa. Necesitas tener la instrumentación para eso.

Terminarás diciendo, “Ah, esta fecha—oh, la malinterpretamos.” De hecho, el tiempo de entrega aplicable en esta situación es completamente diferente porque malinterpretamos la fecha. Vale, perfecto. Regeneremos la decisión con una interpretación corregida para esta fecha. Oh, ahora parece mucho más razonable. Bien. Siguiente.

Fundamentalmente, la única manera de evaluar si tu semántica es correcta es, al fin y al cabo, ponerla a prueba en el mundo real: generar una decisión y dejar que los profesionales digan, “¿Tiene sentido?” Si no, debes volver atrás.

El error que muchas herramientas alternativas cometen es que, cuando los datos generados son un sinsentido, dicen, “Oh, tienes que ajustar los parámetros.” Yo digo: absolutamente no. Solo debes ajustar los parámetros si se considera que son la causa raíz del problema que estás viendo. Si no, esa no es la solución.

Muy, muy frecuentemente, el problema… No puedo enfatizar lo suficiente la importancia de la semántica. Es muy, muy complicada. La única forma de hacerlo es observar las decisiones generadas, lo cual es aún más problemático, ya que muchas herramientas en el ámbito de la planificación ni siquiera generan decisiones finales, y con ello se privan a sí mismas —los proveedores de software que lo hacen— del mismo instrumento que les permitiría evaluar si tienen la semántica correcta.

Conor Doherty: Correcto. Bueno, de nuevo, en cuanto a lo que acabas de señalar: la idea de los datos —usamos datos para tomar decisiones, ya sea que uses probabilistic forecasting o no, eso es lo que un enfoque de Lokad abogaría. Pero, fundamentalmente, los datos se utilizan para facilitar al menos un paso: forecast, y luego llegar a una decisión.

Pero una de las cosas comunes que escuchamos de los profesionales es: “Hay mucho ruido en los datos.” En el contexto del forecast, ¿son problemáticos los datos ruidosos?

Joannes Vermorel: Absolutamente no. Si, por ejemplo, tu negocio es errático —tienes clientes que a veces piden uno, a veces piden 100— esa es la realidad de tu negocio.

Muchos métodos de supply chain, es decir, métodos numéricos, son extremadamente defectuosos. Cuando se enfrentan a algo que calificaría como un valor atípico estadístico, la receta numérica se comporta mal. Así que tienes un valor atípico y el proceso se descarrila, dando como resultado un completo sinsentido.

Luego, la gente dice, “Oh, tenemos que retroceder y modificar este historial, eliminar los valores atípicos.” Dicen, “Esos valores atípicos son malos, son síntomas de algo malo…” Aquí estoy completamente en desacuerdo. Si tus clientes pidieron, de verdad, 100 unidades en el pasado, esto puede ser un valor atípico, pero es la realidad. Sucedió.

Obviamente, si tienes un registro en tu sistema que dice que se ordenaron un millón de unidades pero nunca se creó tal orden, bueno, esos son datos malos. Volvemos a los datos transaccionales: los datos transaccionales son precisos.

Pero si tienes un método numérico que te da resultados absurdos porque se enfrenta a un valor atípico en los datos históricos, el problema no son los datos. El problema es el método numérico, que es simplemente inservible. Te enfrentas a un método defectuoso. Deberías descartar ese método y utilizar algo que se comporte mejor numéricamente. Esa es la esencia.

Esa es, típicamente, una situación en la que los datos están perfectamente bien, y en la que los proveedores que proponen métodos altamente defectuosos, en realidad, convencerán a sus propios clientes de que necesitan corregir manualmente sus datos malos, cuando en realidad los datos son absolutamente correctos y el defecto reside en la propia receta numérica.

Conor Doherty: Bueno, en realidad esa es una oportunidad perfecta para cambiar de tema… hubo algunos… bueno, han llegado dos por mensaje privado. Disculpa, dame un segundo, organizo y enmarco la pregunta.

Así que, siguiendo esa línea, basado en lo que dicen los profesionales: “Ya hemos construido un data lake y, obviamente, tenemos nuestro catálogo, pero nuestros usuarios, nuestros usuarios finales, dicen que los datos son erróneos. En tu opinión, ¿el cuello de botella es la tecnología o la semántica? ¿Y cómo es que Joannes, o Lokad, evita el etiquetado interminable?”

Porque, de nuevo, hablaste mucho sobre la semántica y su importancia. Depende de cómo construyas tu data lake. ¿Es tu data lake una copia perfecta uno a uno de tus registros en el sistema de registros? Sin preprocesamiento, sin mejoras, sin uniones, sin filtros de ningún tipo. Es literalmente uno a uno. Posiblemente con un pequeño retraso porque los datos pueden no ser copiados en vivo desde el ERP, pero dejando de lado la demora en la copia, es exactamente una copia de los datos tal como existen.

Joannes Vermorel: Cuando la gente se queja de eso, volvemos, de nuevo, al segundo problema con los data scientists: “Oh, los datos no están ordenados ni limpios. Esto no es como los experimentos de Kaggle. Estamos confundidos.” Yo digo: lamentablemente, este es el mundo en el que vives. Vives en un mundo en el que la información que se encuentra en tus sistemas empresariales es muy compleja. No hay escapatoria. No hay alternativa.

Así que puedes quejarte de eso, pero es como quejarse de la gravedad. Es simplemente un hecho del universo. Tienes que vivir con ello.

Muy frecuentemente, lo que ocurre no es el escenario ideal que describí para el data lake, es decir, una réplica pura y sencilla de los diversos sistemas empresariales. Y podrías preguntar: ¿por qué tener un data lake si es sólo una copia? La respuesta corta es porque no quieres generar carga en tu sistema ERP, tu sistema de transacciones. Tu sistema de transacciones debe mantenerse super ágil.

Si tienes personas que consultan, “Quiero todas las órdenes de venta de los últimos cinco años, simplemente volcado todo eso,” esto va a ralentizar el sistema. Significa que alguien que está intentando extraer algo tendrá que esperar varios segundos porque los recursos se verán agotados debido a esta consulta masiva de extracción de datos. Por eso es una buena práctica crear una réplica y dejar que esas consultas masivas se ejecuten en la réplica, no en la instancia primaria del sistema de registros.

Volviendo al punto original: lo que observo en muchos data lakes es que el equipo de TI comete un error muy grave. Reprocesan los datos originales. Quieren mejorarlos.

¿Cuál es el truco? El problema es: no generan las decisiones. Por lo tanto, no conocen la semántica. De esta manera, el tipo de transformación que aplican a los datos está garantizado para estar mal orientado, para ser incorrecto, y, como resultado, terminas con datos que no son lo que esperas, no son lo que necesitas, y no hay solución.

No importa lo competentes o dedicados que sean, les falta el instrumento mismo, que es la ingeniería inversa de las decisiones absurdas. Por definición, ese no es el rol de TI, generar esas decisiones empresariales. Así, TI solo puede ocuparse de la parte técnica: configurar las bases de datos, asegurarse de que las instancias sean seguras, y de que tengan suficiente RAM, ancho de banda en disco, infraestructura—sí.

Pero si quieres semántica, TI no puede ocuparse de la semántica. La semántica es demasiado específica para cada sector. No se puede esperar que sean especialistas en contabilidad, especialistas en marketing, supply chain specialists, especialistas legales, y demás. Por eso, la semántica solo puede estar en manos de los profesionales. Por definición, abrumará a TI si intentas que luche esta batalla por ti.

Conor Doherty: Bueno, de nuevo, hay dos comentarios previos que he recibido, tanto personalmente en llamadas como en reuniones, así que estoy eligiendo cuál sería el mejor seguimiento.

Voy a continuar con la idea del conflicto entre TI y operaciones. Literalmente, el comentario fue: “TI dice que nuestros datos son terribles, pero mis operaciones, los profesionales que los usan, dicen que está bien,” porque, como señalaste anteriormente, si estás tomando decisiones y generando dinero, entonces para el negocio está bien.

Entonces, la pregunta es: ¿cómo ustedes—siendo nosotros—evalúan objetivamente la calidad y deciden qué necesita ser corregido ahora versus después versus simplemente implementar algo?

Joannes Vermorel: Rentabilidad de las decisiones generadas. Si tienes datos que supuestamente son basura, pero las decisiones que generas resultan bien, ¿son basura? Tal vez no. Quizás sean completamente irrelevantes. Ni siquiera nos importa.

Si tienes un dato que es fundamentalmente intrascendente, el hecho de que sea correcto o no es irrelevante. No nos importa. Por eso, para nosotros en Lokad, evaluamos realmente la calidad de los datos en términos de dólares: ¿cuál es el retorno de invertir en mejorar—sea lo que sea que eso signifique, y varía según el caso—este dato?

Si mejorar estos datos significa millones de dólares al año porque obtenemos mejores decisiones, increíble. Esto debería ser una prioridad. Probablemente deberíamos invertir. Si estos datos pudieran ser incluso peores y no hiciera ninguna diferencia, entonces no nos importa.

Por eso digo: la única manera de evaluar la calidad de los datos… por eso TI no puede hacer esta evaluación, porque ésta se basa en las decisiones que finalmente genera tu negocio. ¿Son basura o no? Bueno, depende.

Por ejemplo, puedes tener un campo que, en aviation, —tenemos muchos campos—, un campo que está incompleto en el 99% de los artículos, y, muy frecuentemente, hay una nota que dice algo como, “El número C está en este lugar del componente.” ¿Son buenos o malos los datos?

La realidad es que, para la casi totalidad de las piezas de avión, ubicar el número C es muy obvio. No necesitas una nota que te indique dónde está el número C. Simplemente lo identificas, es obvio, lo lees. Pero, en algunos casos raros, es complicado y se encuentra en un lugar algo difícil de alcanzar, con frecuencia por razones mecánicas. En este caso, puede que tengas una pequeña nota que te indique dónde mirar.

Si lo miras desde la perspectiva de TI, dirías, “Oh, eres tan inconsistente con tus entradas de datos. Mira este campo: apenas en un 0.5% de los artículos se establece este atributo.” Pero la realidad es: sí, pero es en esos pocos casos donde realmente importa.

Así que, de nuevo, estoy diciendo: la única manera de evaluar si los datos son buenos o malos es ponerlos a prueba en el proceso de toma de decisiones.

Conor Doherty: Bueno, eso podría, de hecho, responder al siguiente comentario. De nuevo, esto es muy, muy específico, pero toca un tema que creo que es el elefante en la sala: la gente quiere usar sus datos hoy en día para IA. Quieren proyectos de IA, etc.

Así que esto es de un amigo del canal: “Operamos en más de 40 países. Usamos varios ERPs y WMS’s para gestionar inventario en 40 países. ¿Cuándo son nuestros datos lo suficientemente buenos para empezar con IA, y qué se hace realmente en los primeros 90 días, supongo, esencialmente el primer trimestre?”

Joannes Vermorel: Si tienes un país en el que sabes lo que compras, sabes lo que produces, sabes lo que vendes, estás listo para la IA. Eso es todo. Para nosotros siempre ha sido así. Así que el umbral no es alto. Eso es lo interesante.

El umbral para poder robotizar el proceso de toma de decisiones —con algo a lo que llames IA o no, la etiqueta que quieras ponerle— es suficiente. Eso es lo que estamos haciendo. Por eso, muy frecuentemente, el mantenimiento de parámetros que rigen todos los aspectos sutiles del flujo de trabajo para que las personas realicen el trabajo manualmente —esas cosas son irrelevantes porque no las vamos a usar.

Fundamentalmente, la IA desafía completamente la división del trabajo. Todo el flujo de trabajo en el que tienes pronosticadores seguidos por planificadores seguidos por gestores de presupuesto seguidos por gestores de inventario, seguidos por bla bla bla —ya sabes—, no tiene sentido en la era de la IA.

La IA simplemente procesará, como un monolito, los datos en crudo provenientes del sistema de registros, y producirá directamente las decisiones, con toda la instrumentación que las respalde. Eso serán los economic drivers para explicar por qué se ha tomado esa decisión. Perfecto.

Tu sistema de IA —lo que yo llamo los sistemas de inteligencia— es, fundamentalmente, algo parecido a un monolito que toma registros de entrada y genera decisiones de salida con la instrumentación de soporte, y eso es todo.

Cuando la gente me dice, “Tenemos 40 ERPs,” yo diría: no creo que nadie tenga 40. Eso sería… He visto empresas… He visto una empresa que tenía 17 ERPs en el mismo país. Esa es la que ostenta el récord. No voy a nombrar a esta empresa. Es una empresa muy, muy grande. La misma empresa, el mismo país. Ahí las cosas eran realmente una locura.

En resumen: tendrás que llevar a cabo este esfuerzo de restablecer la semántica ERP por ERP. Eso va a ser un dolor de cabeza. Obviamente.

Él estaba preguntando por los primeros 90 días. Típicamente nos toma dos meses establecer la semántica. Eso es algo que hacemos para un conjunto de sistemas empresariales que operan, por ejemplo, en un país. Pero los límites reales no son necesariamente el país. Están mucho más relacionados con cuáles sistemas de TI necesitamos incluir en el alcance: ERP, WMS, e-commerce platform, y demás.

Nuestro alcance está muy determinado por los límites de los sistemas de TI, muy frecuentemente precisamente porque el esfuerzo se trata de establecer la semántica. Luego, una vez que tenemos la semántica, la primera canalización de datos, comenzaremos a iterar sobre las decisiones, y, típicamente, eso toma alrededor de dos meses.

Entonces: dos meses para establecer la canalización de datos, para obtener una primera opinión informada sobre la semántica de cada campo. Pero luego necesitas dos meses adicionales de iteraciones para eliminar toda la locura, muy frecuentemente identificando la semántica que interpretaste mal en la primera iteración.

Así que, en 90… típicamente no son 90 días; serán, digamos, 120 días. Puedes obtener, sin ninguna locura, decisiones en grado de producción. Esa es una iniciativa típica de Lokad.

Pero la idea es: necesitas ser capaz de iterar muy rápidamente, típicamente varias veces al día, sobre esas decisiones absurdas, porque identificarás tantos problemas con la semántica de los datos.

Conor Doherty: Bueno, de nuevo, y solo lo hago porque lo mencionaste: das el ejemplo explícito de cómo podríamos hacerlo. Un punto fundamental es que esas cosas, lo que estás describiendo, la implementación, se ejecutaría en paralelo con lo que llamamos una ejecución dual. Funciona en paralelo con lo que estás haciendo actualmente, para que puedas ver la diferencia con tus propios ojos.

Joannes Vermorel: Sí. Ahí es donde es completamente crítico tener algo que esté completamente desatendido. ¿Por qué es así? Porque si tu proceso paralelo, tu ejecución dual, si el segundo requiere mucha mano de obra, ¿de dónde viene esa mano de obra?

La empresa, digamos que si tienen 15 planificadores, todos están ocupados al 100% del tiempo. Si no estuvieran ocupados casi al 100%, la empresa tendría sólo 12 o 10 planificadores. Por definición, las empresas no tienen empleados de sobra a menos que se den circunstancias especiales. En general, para la mayoría de los trabajos no hay empleados de sobra sin hacer nada, simplemente allí como respaldo para probar el sistema extra.

Esas personas ya dedican las ocho horas de trabajo solo para hacer su trabajo durante el día. Pueden disponer quizá de media hora al día para echar un vistazo rápido a otro sistema, solo para identificar los valores atípicos, las malas decisiones, las decisiones insanas, pero no pueden pasar ocho horas en su sistema y luego ocho horas en otro sistema donde tengan que recorrer el mismo flujo de trabajo.

Por eso digo que es absolutamente crítico que este nuevo sistema de toma de decisiones deba estar completamente sin supervisión; de lo contrario, operacionalmente, no podrán implementarlo. Eso es algo que Lokad aprendió hace una década.

Conor Doherty: Bien. Bueno, nuevamente, he agotado la lista de comentarios que se plantearon, o se me pidió explícitamente, “Please ask you on the air.”

En términos de concluir con una nota constructiva: hemos abarcado mucho. ¿Qué ves en la próxima semana—o escoge cualquier horizonte temporal, pero no dices un año—en los próximos 30 días, por ejemplo, cambios lo suficientemente fáciles de implementar que la gente realmente pueda hacer, si no para mejorar la calidad, al menos para mejorar la percepción interna del poder del estado actual de sus datos?

Joannes Vermorel: No estoy seguro de que haya algo que hacer a corto plazo. Para mí, se trata realmente de darse cuenta de lo que se debe tratar como la verdadera fuente primaria de información versus como un artefacto numérico. No es lo mismo.

Una vez que hagas esta segregación y observes fríamente tus datos reales, impulsados por eventos—los datos que representan los verdaderos eventos que tienen una implicación financiera para la empresa—muy probablemente notarás que estos datos son excelentes. Sí, van a estar desordenados, pero son excelentes. Así que este no es el problema.

Ese sería mi mensaje: los datos malos en empresas que han sido digitalizadas durante una década o más nunca son el problema. Lokad ha realizado más de 100 implementaciones en la última década y media.

A veces teníamos problemas con sistemas que eran demasiado lentos para extraer los datos. Eso era a veces un problema. Por cierto, por eso se desea añadir un data lake, porque a veces ejecutábamos, por ejemplo, “SELECT * FROM table X,” y el sistema realmente daba una excepción de out-of-memory cuando hacíamos eso.

Entonces, está bien, tuvimos problemas donde a veces extraer los datos era extremadamente complicado porque el sistema se colapsaba cuando intentábamos sacar los datos del sistema. Esa es una preocupación real. Realmente espero que no se encuentren en tal situación, pero podría suceder. Esa es la razón por la que quieres tener el data lake.

Pero aparte de esos problemas muy técnicos que están relacionados con infraestructuras antiguas, nunca tuvimos datos realmente malos. Lo que teníamos en abundancia era datos extremadamente opacos y oscuros, pero fundamentalmente era algo que debía resolverse del lado de Lokad.

Así que sí, era un gran problema para nosotros, pero fundamentalmente no era un problema del cliente. El cliente simplemente estaba usando su sistema de la manera en que debía hacerlo. El resultado fue: para alguien que desea implementar un sistema automatizado de toma de decisiones sobre eso, es un desafío. Pero nuevamente, el desafío radica en la correcta interpretación de los datos, no en culpar al cliente por haber recopilado estos datos en primer lugar.

Conor Doherty: De nuevo, llevamos una hora, así que creo que estoy justificado para hacer un pequeño comentario en términos de marketing, pero es un punto fundamental a transmitir.

Una de las cosas que he aprendido personalmente de muchas de las conversaciones que he tenido recientemente es que no siempre es claro para la gente que cuando decimos, “Hey, look, your data is good enough as it is,” no se dan cuenta de que, si trabajaran con Lokad, o con cualquier vendor competente, asumirían esa carga.

Entonces: ustedes les entregan los datos, nos entregan los datos. No es que tengan que procesarlos. Y ellos deberían… de nuevo, si el vendor…

Joannes Vermorel: Si el vendor no asume esta carga sobre sus propios hombros, es una receta para buscar chivos expiatorios.

Conor Doherty: Exactamente.

Joannes Vermorel: El vendor simplemente te culpará, y terminarás en una situación en la que la empresa desperdicia medio billón en siete años. Al final, el informe concluye que todo fue culpa de… y el vendor está como: “No, nothing to see here. It’s not my fault. Come on.”

Por cierto, en el caso de Lidl, eso es muy interesante, porque culparon que los datos eran malos por un punto específico. SAP dijo, “Oh, Lidl, they drive their analysis on the purchase price, and we drive all our analysis on the selling price, and that was the cause.”

Para mí, digo: chicos, esto es semantic 101. Primero, es trivial como problema: ¿es el precio de venta o el precio de compra? Sí, hay un desafío semántico aquí: ¿de qué precio estamos hablando? Pero seamos claros: no es una distinción de matices muy sutil. En cuanto a la distinción semántica, es una distinción muy, muy fácil de abordar.

Luego, lo que es aún más desconcertante es que, obviamente, necesitas ambos. Necesitas tanto el precio de compra como el precio de venta para poder conocer el margen.

Así que la idea de que el vendor, después de siete años, logre culpar al cliente diciendo, “Oh, you know what, they are organizing all their supply chain around the purchase price, it’s such a complication for us because we are expecting the selling price,” es exactamente el tipo de travesuras que se producen si el vendor no se compromete a entregar decisiones adecuadas en términos de rendimiento económico.

Ese debería ser el punto de partida; de lo contrario, en el supply chain space, vas a obtener muchas tonterías. Al final del día, después de gastar mucho dinero, el vendor logrará echarte la culpa encontrando datos malos.

De nuevo: si no aceptamos el hecho de que solo las decisions importan, hay tantas piezas de datos que son completamente inconsecuentes. Obviamente, esas piezas de datos inconsecuentes van a ser de muy baja calidad, y está completamente bien.

Un ERP tiene 10,000 tablas. Cada tabla tiene decenas de campos. ¿Todo este dato debería estar ordenado y limpio? Una locura. ¿Por qué querrías eso? Es demasiado costoso.

Así que si juegas este juego de datos malos con el vendor, el vendor siempre será el ganador porque siempre habrá muchas tablas y muchos campos donde, objetivamente, son basura e inconsecuentes. Esa es la clave: inconsecuentes.

Conor Doherty: Bien. Así que para concluir: elige a tu vendor cuidadosamente, si lo sintetizas.

Joannes Vermorel: Sí. Y entiende realmente: cuando dices calidad del ERP, ¿cuál es la intención? ¿Cuál es la intención? No existe la pureza del ERP en un sentido moral para una empresa. Sirve para un propósito.

La calidad es la aptitud para el propósito, y eso es todo.

Conor Doherty: Eso es todo. Muchas gracias. Se me han acabado las preguntas. Llevamos una hora, así que creo que se nos acabó el tiempo.

Como siempre, gracias por tu insight, y gracias a todos por asistir y por sus mensajes privados. Como dije al comienzo, y de donde surgió este tema, si desean continuar la conversación, pónganse en contacto conmigo y con Joannes en privado. Siempre estamos contentos de charlar.

Como dije la semana pasada, y lo diré cada semana, somos lovely people. Look at us. Con esa nota, nos vemos la próxima semana. Tengo un tema especial para la próxima semana, así que lo anunciaremos el lunes. Pero con esa nota, vuelvan al trabajo.