00:00:07 Culpar a los datos incorrectos en proyectos de cadena de suministro.
00:00:33 Por qué los datos incorrectos son una excusa fácil para el fracaso del proyecto.
00:01:42 Desafíos con los datos incorrectos y conceptos erróneos sobre su calidad.
00:03:16 Dificultades para acceder a los datos de los sistemas ERP y desafíos con los proveedores.
00:06:32 Problemas que surgen durante la migración entre sistemas ERP y corrupción de datos.
00:08:01 Abordar las entradas de datos incorrectas y su impacto en los sistemas ERP.
00:09:48 Previsión y detección de problemas en los datos históricos.
00:11:37 Cómo los cambios semánticos y de definición en evolución pueden generar problemas de datos.
00:12:20 Problemas de escalabilidad y optimización de 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 los tiempos de procesamiento más largos en la resolución de problemas en los 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 de cada campo de datos para garantizar una comprensión adecuada.
00:21:01 Los roles de los profesionales de la cadena de suministro y el 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 incorrectos y la identificación de las causas raíz.
Resumen
En esta entrevista, Kieran Chandler y Joannes Vermorel discuten el papel de los datos en la optimización de la cadena de suministro y los desafíos que enfrentan los proveedores de software y los profesionales de la cadena de suministro. Vermorel destaca que el principal problema no es “datos incorrectos”, sino acceder y utilizarlos de manera efectiva. Los desafíos incluyen sistemas desactualizados, documentación inadecuada y responsabilidad en el acceso a los datos. Los conflictos de interés con los integradores, los problemas de migración del sistema, la previsión y la escalabilidad también plantean problemas. Para optimizar la gestión de la cadena de suministro, las empresas deben comprender y abordar los problemas de datos, invertir en una documentación adecuada, aclarar la semántica de los datos y mantener expectativas realistas, en lugar de culpar a los datos por los fracasos.
Resumen Extendido
En esta entrevista, Kieran Chandler y Joannes Vermorel, el fundador de Lokad, discuten el papel de los datos en proyectos de optimización de la cadena de suministro y los desafíos que enfrentan los proveedores de software y los profesionales de la cadena de suministro. Comienzan abordando la noción de que “datos incorrectos” a menudo se utiliza como chivo expiatorio para el fracaso de los proyectos de cadena de suministro. Vermorel señala que culpar a los datos es una forma conveniente de evitar culpar a las personas que podrían tomarlo personalmente y contraatacar. Sin embargo, también enfatiza que comprender la causa raíz de un problema es crucial.
Vermorel afirma que los problemas relacionados con los datos son probablemente la causa número uno de fracaso en proyectos de optimización de la cadena de suministro, pero la percepción de “datos incorrectos” a menudo es equivocada. Argumenta que la mayoría de las empresas occidentales han tenido datos precisos durante décadas, gracias al uso de códigos de barras, escáneres de códigos de barras y otras tecnologías. Según Vermorel, el verdadero problema no es la calidad de los datos en sí, sino los desafíos para acceder y utilizarlos.
Uno de los desafíos clave para utilizar los datos de manera efectiva es acceder a ellos. Muchas empresas han estado utilizando varios sistemas de planificación de recursos empresariales (ERP), sistemas de gestión de almacenes (WMS), sistemas de gestión de transporte (TMS) y otras soluciones de software durante años, pero estos sistemas pueden ser difíciles de trabajar cuando se trata de exportar datos. Vermorel identifica algunos escenarios en los que acceder a los datos puede ser particularmente problemático:
1 Sistemas antiguos: Algunas empresas todavía utilizan sistemas que tienen 40 años, con backend obsoletos y propietarios que hacen que la extracción de datos sea extremadamente difícil. 2 Falta de documentación: Los proveedores de software pueden no proporcionar documentación adecuada para sus sistemas, lo que dificulta la comprensión y navegación de las numerosas tablas y campos que se encuentran en las bases de datos. 3 Responsabilidad y acceso: Determinar quién es responsable de otorgar acceso a los datos puede ser un desafío, ya que involucra a múltiples partes interesadas dentro de una empresa, incluido el proveedor de software, el departamento de TI y los profesionales de la cadena de suministro.
La entrevista destaca la importancia de comprender y abordar los desafíos relacionados con los datos en proyectos de optimización de la cadena de suministro. Si bien 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 garantizar el éxito de las iniciativas de optimización de la cadena de suministro.
Se adentran en los problemas de datos que pueden surgir de las relaciones con los proveedores, las integraciones de sistemas y la escalabilidad a medida que las empresas crecen.
Uno de los problemas clave que discuten es el potencial de conflictos de interés con los integradores, que pueden estar más interesados en vender sus propias soluciones de optimización de la cadena de suministro en lugar de cooperar con el proveedor elegido por la empresa. Esto puede llevar a que las empresas sean tomadas como rehenes por sus integradores, lo que dificulta el acceso o la utilización efectiva de sus datos.
Otro desafío surge durante la migración de un sistema de planificación de recursos empresariales (ERP) a otro, lo que puede provocar una mala calidad de los datos o una “integración basura”. Si bien las entradas de datos individuales pueden ser precisas, el proceso de migración de datos históricos entre sistemas puede introducir errores, ya que a menudo no hay una correspondencia directa uno a uno entre los datos en los sistemas antiguos y nuevos. Esto puede provocar corrupción de datos, que puede no tener un impacto significativo en las operaciones diarias, pero puede volver a surgir como un problema al intentar proyectos de optimización de la cadena de suministro o análisis de datos.
La entrevista también aborda la previsión basada en datos históricos, lo cual puede ser difícil debido a la incertidumbre inherente del futuro. Detectar problemas dentro de los datos históricos es más fácil cuando los problemas son visibles, como brechas o cambios repentinos en los datos. Sin embargo, cambios sutiles en la semántica o definiciones a lo largo del tiempo pueden llevar 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 empresas más pequeñas, todo el conjunto de datos históricos a menudo puede caber en un teléfono inteligente, lo que hace que la optimización sea menos preocupante. Sin embargo, a medida que las empresas crecen, el volumen de datos puede convertirse en un problema. La discusión enfatiza la importancia de comprender y abordar estos problemas de datos para optimizar la gestión de la cadena de suministro de manera efectiva. L6 Vermorel explica que las empresas a menudo tienen dificultades para extraer datos de sus sistemas de planificación de recursos empresariales (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 llevar mucho tiempo, semanas en lugar de horas, debido a la cantidad de datos involucrados y los tiempos de procesamiento lentos.
A muchas empresas les parece 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 interpretaciones erróneas, Vermorel sugiere que las empresas deben tener documentación detallada para cada campo y tabla en sus sistemas de datos, reflejando la complejidad de su cadena de suministro.
Un problema común en la optimización de la cadena de suministro es que los profesionales pueden no dedicar suficiente tiempo a calificar sus datos, lo que lleva a que los proveedores trabajen con información incompleta o poco clara. Esto puede resultar en una situación de “basura entra, basura sale”, donde los datos no son necesariamente incorrectos, pero se entienden mal 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 personas y estructuras organizativas. Las empresas deben comprender quién es el responsable del fallo y trabajar para solucionar los problemas subyacentes, en lugar de simplemente culpar a los datos. Los proveedores 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 demasiado optimistas para cerrar acuerdos.
Las empresas deben invertir en una documentación adecuada, una semántica de datos clara y expectativas realistas para optimizar su cadena de suministro y evitar fallos derivados de problemas de datos.
Transcripción completa
Kieran Chandler: Hoy en Lokad TV, vamos a entender por qué este es un diagnóstico tan impreciso y también entender cuáles pueden ser algunos de los desafíos de datos que pueden encontrar tanto los proveedores de software como los profesionales de la cadena de suministro. Entonces, Joannes, ¿por qué los malos datos son una excusa tan fácil?
Joannes Vermorel: Primero, porque los datos no pueden quejarse. Nadie va a defenderlos, por lo que culpar a algo inerte es mejor que culpar a un colega que lo tomará personalmente y contraatacará. Pero la realidad es que cuando vas 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 va a contraatacar. 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 la cadena de suministro. Pero hay algunas concepciones erróneas. Cuando las personas dicen “malos datos”, se refieren a números corruptos o incorrectos. Sin embargo, para la mayoría de las empresas occidentales, han tenido datos muy precisos durante décadas. Casi nadie ingresa números de pieza incorrectos o comete errores tipográficos. Utilizan códigos de barras, escáneres de códigos de barras y otros trucos como RFID. Por lo tanto, 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 los datos realmente fracasan.
Kieran Chandler: Si la gran mayoría de las empresas occidentales están recopilando datos bastante buenos, ¿cuáles son algunos de los desafíos que podemos encontrar que nos hagan 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 funcionando con diversas versiones de ERPs, WMS, TMS u otro software empresarial para administrar y operar sus empresas a diario durante décadas. Pero la mayoría de esos sistemas no son muy amigables para el usuario cuando se trata de exportar datos. En algunos casos, tienes sistemas tan antiguos que ni siquiera tienes una base de datos SQL relacional adecuada respaldando el sistema. En este tipo de situaciones, es realmente difícil extraer los datos porque el backend suele ser completamente obsoleto y propietario.
Kieran Chandler: Entonces, ¿quién se encarga de hacer eso?
Joannes Vermorel: Aquí hay múltiples responsabilidades. En primer lugar, puedes tener al proveedor de software que no proporcionó ninguna documentación significativa sobre el sistema. En los peores 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. Incluso si sabes dónde buscar, puedes tener un problema con el integrador. El problema con el integrador es que puede haber un conflicto de intereses. Algunos integradores pueden tener un gran interés en venderte su propia receta para la optimización de la cadena de suministro, para este módulo u otro módulo o algo así. Y cuando les pides que básicamente hagan una extracción de datos para ti, tus equipos internos o cualquier iniciativa que quieras llevar a cabo con otro proveedor, el integrador puede ser - y sucede, lo hemos visto muchas veces - simplemente poco cooperativo. Porque, nuevamente, para ellos, simplemente no es de su interés estratégico ser competitivos. Y aquí, tienes una situación de rehenes donde la empresa es tomada - de hecho, es tomada como rehén por el integrador. La empresa, la empresa de TI responsable de configurar, a veces alojar y, en general, mantener el ERP u otro sistema informático de la empresa. Entonces, ese es otro tipo de problema de datos. Pero como ves, tiene muy poco que ver con los datos.
Kieran Chandler: Sí, definitivamente. No poder acceder a tus datos suena como un obstáculo bastante grande. ¿Y qué hay de algunos de los otros desafíos que pueden ocurrir? 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 con los datos?
Joannes Vermorel: No puede causar problemas. Así que esa es la situación en la que puedes tener otro tipo de datos incorrectos. Pero aquí, realmente los datos que están mal son cuando tienes una integración basura. Así que digo que típicamente las entradas de datos son correctas, pero cuando te mueves de un ERP a otro, lo que puede ser el proveedor o tal vez el integrador, tal vez el departamento de TI interno, lo que van a tratar de hacer es básicamente migrar los datos históricos del sistema antiguo al nuevo sistema. El problema es que no tienes una correspondencia uno a uno entre, ya sabes, lo que era una venta recibida en el sistema antiguo y lo que es una venta recibida en el nuevo sistema. Tal vez las cosas están organizadas de manera diferente, y por lo tanto no hay una forma clara de informar los ingresos por ventas del sistema antiguo al nuevo sistema. Y luego terminas con integraciones tentativas y donde puede llevar a la corrupción de datos, es que si, digamos, haces una reintegración incorrecta de tu historial, no evitará que tu empresa funcione día a día. Verás, si los datos de Oracle East se importan incorrectamente en el nuevo sistema, para la mayoría de las operaciones diarias no tendrá ningún impacto. E incluso si tiene un impacto, por lo general alguien simplemente hará una solución rápida para algo que está incorrecto y continuará. Puede ser una fuente de fricción continua, pero primero, está desapareciendo rápidamente porque si las personas tropiezan, por ejemplo, digamos que tienes códigos de proveedores que se importaron incorrectamente. Quiero decir, es probable que no tengas un millón de proveedores, por lo que tus 100 proveedores más frecuentes probablemente se corregirán en términos de corregir las entradas de datos incorrectas dentro de las dos semanas a partir de la fecha en que comiences a usar el nuevo sistema. Y tal vez, dentro de tres meses, hayas corregido virtualmente cada entrada de proveedor incorrecta. Pero el problema es que el código de historial, la gente no va a volver atrás y corregir los datos históricos. Así que digamos que tenías cinco años de historial, tal vez tres
Kieran Chandler: En el futuro, ¿qué tan fácil es detectar estos problemas que podrían haber ocurrido en el pasado?
Joannes Vermorel: Es fácil detectar estos problemas cuando hay problemas visibles, como datos faltantes durante algunos meses. Sin embargo, puede haber cambios sutiles que son más difíciles de detectar, como diferencias en cómo se cuentan las ventas, si se incluyen o no fraudes o devoluciones. Esto puede llevar a muchos problemas que son difíciles de detectar en los datos históricos porque la propia definición de los datos que estás viendo ha cambiado con el tiempo, y no es obvio a menos que haya un aumento o una disminución notable.
Kieran Chandler: Otro problema común entre 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 puede introducir la escalabilidad?
Joannes Vermorel: Cuando no tienes problemas de escalabilidad, simplemente puedes copiar todos los datos de la empresa todos los días. Para empresas más pequeñas, esto puede ser manejable ya que su historial completo puede ser de menos de 10 gigabytes. Sin embargo, a medida que creces y te conviertes en una empresa más grande, terminas teniendo muchos más datos y necesitas recopilar datos de forma incremental. Esto significa extraer una parte de los datos todos los días, y algunos sistemas no están diseñados para manejar esto de manera eficiente o precisa. Por lo tanto, necesitas hacer cosas complicadas para construir una extracción diaria limpia y, en el proceso, te expones a posibles problemas.
Kieran Chandler: Entonces, al final, terminas teniendo datos incorrectos solo porque quieres hacer una extracción de datos de manera incremental, y es complicado porque es posible que el sistema no haya sido diseñado para esta tarea. Cuando piensas en la depuración, solo quieres copiar datos de un lugar a otro, y puede ser un problema muy mundano. Si el proceso tarda un minuto, alguien en tu departamento de TI puede dedicar 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 donde 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á tardando demasiado y hacer otra cosa. Incluso podrían olvidarse de ello. Al día siguiente, podrían notar un pequeño error que causó un bloqueo después de seis horas. Para reproducir el problema, se necesita otro retraso de seis horas. Como resultado, terminas con problemas que deberían poder solucionarse en solo unas pocas horas, pero debido a la mayor complejidad y los tiempos de procesamiento más largos, se convierte en un proceso muy tedioso donde los retrasos totales se convierten en semanas. No porque sean semanas de esfuerzo, sino porque las personas inician el proceso, se olvidan de él y vuelven al día siguiente. Esto hace que las iteraciones sean muy lentas.
Kieran Chandler: ¿Qué tan extendidos dirías que son estos problemas? ¿Hay muchas empresas que realmente creen que tienen datos muy buenos, pero en realidad, cuando los miras más de cerca, no son tan buenos?
Joannes Vermorel: Sí, hay otro problema que no hemos discutido, que es la semántica en sí misma. Muchas empresas creen que tienen buenos datos, pero en realidad, los datos tienen una semántica desconocida. Lo que quiero decir con eso es que, por ejemplo, cuando hablamos de una fecha de pedido, hay muchas interpretaciones posibles. Podría ser la fecha de pedido del cliente, la hora en que se realizó el pedido en el sitio web, registrada en el sistema o incluso cuando se confirmó el pago como válido. Podría haber 20 interpretaciones diferentes de lo que significa esta fecha de pedido.
Kieran Chandler: Cuando comenzamos a trabajar con clientes, generalmente nos encontramos con tablas y columnas con poca documentación. Pero cuando terminamos de preparar los datos, tenemos casi una página de documentación por campo por tabla. Una situación típica de la cadena de suministro tiene alrededor de 20 tablas con 20 campos, por lo que estamos hablando de 400 páginas de documentación solo para aclarar lo que significan los datos. La gente suele sorprenderse mucho por esto, pero es necesario entender correctamente los datos.
Joannes Vermorel: Joannes, ¿puedes hablar sobre la importancia de comprender correctamente los datos en la optimización de la cadena de suministro?
Joannes Vermorel: Sí, la complejidad de su cadena de suministro se refleja en estos datos, y si no realiza este trabajo, terminará con datos que no comprende correctamente. Por lo tanto, es basura de entrada, basura de salida. No es que los datos sean basura, en el sentido de que los números estén mal, pero no sabe lo que significan los datos. Entonces, si tiene una fecha que no comprende correctamente, cualquier cálculo o modernización que vaya a realizar, 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 de poder comenzar un proyecto.
Kieran Chandler: Entonces, ¿quién es el responsable cuando se trata de la semántica?
Joannes Vermorel: Yo diría que los profesionales de la cadena de suministro deberían estar a cargo. La mayoría de ellos diría que es un problema de TI. Pero, cómo ve la semántica de los datos realmente depende del proceso que tenga. Si tiene el proceso donde está escaneando productos en la entrada del almacén porque tiene este proceso, extrae alrededor del departamento de TI. No están en el terreno en el almacén, por lo que no saben exactamente cómo se configura su proceso. Las únicas personas que saben exactamente porque estos datos son solo el resultado de un proceso que genera, están en primer lugar en el sistema. Entonces, mi punto es que no espere que TI, que solo administra las máquinas, se asegure de que el software tenga suficiente memoria de cómputo, ancho de banda de memoria y disco, tenga las ideas, habilidades y comprensión para entender lo que significan los datos. Lo que significan los datos es típicamente un problema muy específico del negocio. No es un problema de TI en absoluto. Entonces, típicamente, la culpa también recae con frecuencia en el lado de los profesionales. Los profesionales no han dedicado suficiente tiempo a calificar correctamente con sus propias palabras y su propia comprensión. Por lo tanto, cuando hay esta optimización de la cadena de suministro, termina con un proveedor que termina tratando estos datos a medias. Eso termina con basura de entrada, basura de salida.
Kieran Chandler: Entonces, ¿el proveedor también puede ser culpable?
Joannes Vermorel: Sí, obviamente, el proveedor también puede ser culpable. Empresas como Coke Ad que están haciendo optimización de la cadena de suministro, y normalmente cuando el proveedor es culpable, es porque el proveedor está tratando de ser astuto. Por lo general, están tratando de minimizar su desafío porque están tratando de vender un problema. Están discutiendo formas como “Confía en nosotros. Va a ser pan comido. Lo haremos en cuestión de semanas. Boom, lo haremos así y funcionará”. La realidad es que si le dices a un director de cadena de suministro: “Me temo que solo calificar tus datos llevará 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 trato. Entonces, es mucho más fácil ser demasiado optimista, pero luego eso es una receta para el fracaso. Luego el proveedor tiene que asumir la culpa porque deberían saber mejor. Tal vez el cliente no sepa mejor porque es la primera vez que intentan hacer un proyecto de optimización cuantitativa de la cadena de suministro predictiva. Pero luego el proveedor, que por definición, probablemente no sea la primera vez que lo hagan. Deberían saber mejor. Por lo tanto, si la situación de diagnóstico en la que este tipo de datos es inexistente, entonces deberían
Kieran Chandler: Entonces, básicamente deberían advertir al cliente que van a necesitar varios meses de esfuerzo solo para aclarar la semántica de los datos para que los datos puedan ser calificados como buenos. Pero no es que fueran realmente malos al principio. Entonces, bueno no es lo opuesto a malo en esta situación; es más bien lo opuesto a datos oscuros o datos no calificados o datos desordenados.
Joannes Vermorel: De acuerdo, y para concluir hoy, hay una amplia gama de problemas diferentes que realmente entran en esa categoría de datos malos. Yo diría que traten de asegurarse de identificar la causa raíz del problema, y por lo general, son las personas. Quiero decir, obviamente, cuando digo que son las personas, no quiero culpar a James del departamento de TI por ser responsable del desastre. Pero cuando digo que el problema son las personas, necesitas entender exactamente quién tiene la responsabilidad del fracaso, y tal vez esta persona realmente fue puesta en una situación en la que no podía hacer nada más que fracasar.
Kieran Chandler: Ves, puedes llegar a la conclusión de que James del departamento de TI ha fallado, 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 realísticamente. Entonces, es interesante que comiences a ver el problema desde un ángulo que al menos te dé pistas sobre cómo vas a solucionarlo en lugar de decir que los datos eran malos, muy malos, datos malos. Y luego, si fueras a hacer otra iniciativa, simplemente repetirías el mismo problema, los mismos errores y, por lo tanto, terminarías con el mismo fracaso al final del día.
Joannes Vermorel: De acuerdo, y para concluir hoy, hay una amplia gama de problemas diferentes que realmente entran en esa categoría de datos malos. Yo diría que intentes asegurarte de identificar la causa raíz del problema, y por lo general, son las personas. Quiero decir, obviamente, cuando digo que son las personas, no quiero culpar a James del departamento de TI por ser responsable del desastre. Pero cuando digo que el problema son las personas, necesitas entender exactamente quién tiene la responsabilidad del fracaso, y tal vez esta persona fue puesta en una situación en la que no podía hacer nada más que fracasar.
Ves, puedes llegar a la conclusión de que James del departamento de TI ha fallado, 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 realísticamente. Entonces, es interesante que comiences a ver el problema desde un ángulo que al menos te dé pistas sobre cómo vas a solucionarlo en lugar de decir que los datos eran malos, muy malos, datos malos. Y luego, si fueras a hacer otra iniciativa, simplemente repetirías el mismo problema, los mismos errores y, por lo tanto, terminarías con el mismo fracaso al final del día.
Kieran Chandler: Bueno, si el jefe de James está viendo esto, espero que sea comprensivo. De todos modos, eso es todo por esta semana. Muchas gracias por sintonizar, y nos vemos la próxima vez. Hasta luego por ahora.
