Líderes de opinión

La preparación para la IA comienza con datos de producto fiables

mm
Añade Unite.AI a tus fuentes preferidas en Google

Los fabricantes están invirtiendo mucho en IA, iniciativas de hilo digital, automatización y modernización empresarial para mejorar la productividad y la toma de decisiones. Buena parte del debate se centra en los modelos de IA, la infraestructura y la integración. Sin embargo, muchas organizaciones están pasando por alto un requisito fundamental para estos esfuerzos: confiar en los datos de producto subyacentes y en las reglas de negocio que impulsan las decisiones operativas.

El desafío no consiste simplemente en conectar sistemas, sino en garantizar que las definiciones de producto, la lógica de configuración y las reglas de negocio que circulan entre ellos sigan siendo precisas. La preparación para la IA comienza por confiar en los datos de producto de la empresa. La transformación digital no consiste solo en conectar sistemas, sino en preservar el significado y la precisión de la información que circula entre ellos.

A medida que las empresas modernizan sus sistemas empresariales y conectan la gestión del ciclo de vida del producto (PLM), la planificación de recursos empresariales (ERP), la configuración, fijación de precios y cotización (CPQ) y las plataformas de servicio, las incoherencias en la lógica de configuración pueden socavar silenciosamente la precisión de los procesos posteriores y la eficacia de las recomendaciones basadas en IA. Sin una lógica de configuración fiable, la IA acelera los errores en vez de mejorar las decisiones.

Por qué la configuración de productos es el cimiento oculto

Hoy en día, los fabricantes dependen cada vez más de un ecosistema interconectado que abarca PLM, ERP, CPQ, fabricación y servicio. La configuración de productos actúa como tejido conectivo que traduce la intención de ingeniería en requisitos de fabricación, ventas, precios y servicio.

Cada sistema tiene una perspectiva distinta del producto: PLM necesita la información técnica y de diseño; fabricación necesita saber qué se puede producir; y CPQ necesita las reglas de venta y de mercado. La configuración es lo que conecta esas perspectivas. Cuando la lógica subyacente cambia o se vuelve incoherente, el hilo digital se rompe, por muy bien integrados que estén los sistemas.

Las reglas heredadas introducen riesgos invisibles

Los modelos de configuración de productos suelen representar décadas de conocimientos acumulados y estratificados con el tiempo: requisitos normativos, limitaciones de fabricación, excepciones específicas de cada mercado y lógica de precios. Quienes crearon originalmente estos modelos a menudo ya no trabajan en la empresa, y las organizaciones se quedan con reglas que nadie comprende del todo.

Los proyectos de modernización empresarial, como las migraciones a SAP S/4HANA, suelen dar prioridad a las aplicaciones, la infraestructura y el código personalizado, y relegan la lógica de configuración a un segundo plano. El resultado es un riesgo que pasa inadvertido: los sistemas pueden migrarse correctamente mientras el comportamiento de la configuración cambia de formas sutiles, difíciles de detectar con las pruebas tradicionales.

Las migraciones a S/4HANA ilustran bien el problema, porque un nuevo motor de configuración puede interpretar de manera distinta reglas vigentes desde hace mucho tiempo, aunque la sintaxis sea idéntica. Las diferencias en la aplicación de valores predeterminados, el orden en que se evalúan las restricciones y la resolución de conflictos entre reglas pueden cambiar las combinaciones que acepta un modelo, sin que se reescriba una sola línea de las propias reglas.

Esto no es simplemente confuso: una lógica de configuración defectuosa se convierte en un problema de negocio. Hay dos tipos de fallos, y ambos son costosos:

  • Una configuración permite que una empresa venda algo que en realidad no puede fabricar, lo que provoca repetición del trabajo, incumplimiento de compromisos y deterioro de las relaciones con los clientes.
  • Una configuración impide incorrectamente que una empresa venda algo que sí podría fabricar, lo que provoca una pérdida de ingresos y, potencialmente, de ventaja competitiva.

El primer tipo de fallo acaba saliendo a la luz en la planta de producción. El segundo es silencioso: en los pedidos no queda constancia de una venta que el configurador nunca permitió.

La verificación se está convirtiendo en una capacidad estratégica

La validación tradicional de las migraciones depende en gran medida de las pruebas manuales y las comprobaciones puntuales, que no pueden evaluar de forma realista la enorme cantidad de combinaciones posibles de productos. La verificación de la configuración desplaza el foco: deja de centrarse en si los datos se transfirieron correctamente y pasa a comprobar si se conserva la intención de negocio.

He visto a fabricantes asignar equipos cuya única tarea consiste en confirmar que un modelo migrado sigue generando las mismas configuraciones válidas y rechazando las mismas configuraciones no válidas, simplemente porque no tienen otra forma de saberlo. Es un trabajo minucioso, costoso y lento que, aun así, solo permite examinar una muestra del problema.

Conviene precisar la magnitud del problema. Un modelo con 30 variables y cinco opciones para cada una permite aproximadamente 10²¹ combinaciones, muchísimas más que la cantidad estimada de granos de arena en la Tierra, y los modelos industriales reales son considerablemente mayores. Por muchas personas que hagan clic en una interfaz de usuario, no se puede abarcar todo ese espacio: las matemáticas no lo permiten.

Por eso son importantes los métodos formales. En lugar de muestrear combinaciones, un modelo de configuración puede compilarse en una forma lógica canónica: una representación matemática compacta de todas las combinaciones válidas que permiten sus reglas. Es posible comparar directamente dos modelos compilados de esta manera. O bien describen exactamente el mismo conjunto de productos válidos, o bien la comparación indica con precisión en qué puntos difieren, con ejemplos concretos de combinaciones que uno acepta y el otro rechaza. La misma representación convierte el comportamiento en tiempo de ejecución en una consulta, en lugar de una búsqueda, lo que permite que un configurador muestre solo opciones válidas y nunca conduzca al usuario a un callejón sin salida. La verificación y la corrección en tiempo de ejecución resultan ser la misma capacidad, abordada desde dos perspectivas.

Las organizaciones necesitan cada vez más este tipo de comparación formal antes de incorporar IA o automatización a sus reglas de producto. El objetivo no es simplemente reducir el riesgo de migración, sino preservar la continuidad operativa en ingeniería, fabricación, ventas y servicio, y adquirir la capacidad de probar, depurar y verificar los modelos de configuración antes de su lanzamiento, en lugar de después.

La IA debe apoyarse en un motor determinista, no sustituirlo

Nada de esto exige que la IA sustituya al motor de configuración. El enfoque más duradero es el contrario: la IA se sitúa entre el usuario y un motor de configuración riguroso, y ofrece una experiencia más natural de venta guiada o recomendación, mientras las reglas subyacentes siguen siendo deterministas. El modelo de lenguaje interpreta lo que pide el cliente; el motor decide qué se puede fabricar realmente. Esta división del trabajo evita que la parte del proceso que debe ser demostrablemente correcta quede en manos de un sistema que, por diseño, es probabilístico.

Los datos fiables son la clave del éxito de los programas de IA

La fiabilidad de las recomendaciones que genera la IA depende de la fiabilidad del conocimiento sobre los productos que recibe. Los datos de configuración sin verificar hacen que la IA propague errores a escala empresarial, lo que socava la orientación comercial, las decisiones de fabricación y los compromisos con los clientes.

Los fabricantes deberían considerar la verificación de datos un requisito previo para implementar la IA, del mismo modo que las pruebas de software se convirtieron en un requisito previo para el desarrollo de aplicaciones. A medida que avanza la transformación digital, la ventaja competitiva dependerá cada vez más, no de ser los primeros en implementar la IA, sino de hacerlo sobre una base de inteligencia de producto fiable.

Jesper Blak Møller es director de arquitectura de sistemas y cofundador de Configit. Como parte del equipo directivo de productos de Configit, cuenta con amplios conocimientos sobre sistemas basados en reglas, configuración de variantes de SAP y precios de SAP. Además de tener un doctorado en informática, su trayectoria incluye su trabajo como arquitecto de soluciones en el departamento de servicios profesionales de Configit, donde ofrece soluciones de software integradas con SAP.