Cómo un distribuidor de electrónica define un piloto para acabar con las búsquedas manuales de productos en el ERP

¿Puede el software completar el registro de producto en el ERP para el que se espera un presupuesto? En gran medida, sí: puede encontrar los datos del fabricante, asignarlos a los campos del ERP y señalar qué debe seguir comprobando una persona. Esa es la pregunta que nos planteó un distribuidor de electrónica industrial. Su equipo de ventas no puede cotizar una línea de RFQ hasta que el producto exista en el ERP, y para cada artículo nuevo alguien abre el sitio web del fabricante y copia los datos campo por campo. Automa.Net propuso recopilar esos datos automáticamente, mostrando la fuente de cada valor, asignarlos a los campos propios del ERP del distribuidor y entregarlos listos para importar o a través de una API, empezando por los campos que bloquean un presupuesto. El proyecto se encuentra ahora en la fase de acordar el alcance del piloto, por lo que este artículo describe el problema y el plan, no los resultados. Es el segundo caso de nuestra serie sobre proyectos piloto, después de automatizar presupuestos a partir de listas de stock en bruto: Automa.Net no es solo software listo para usar; también construimos en torno al proceso de un cliente, y empezamos con un piloto.

El caso en breve:

• Problema: cada artículo de RFQ que aún no está en el ERP espera una búsqueda manual del producto en el sitio web del fabricante.
• Coste: presupuestos bloqueados hasta que exista un registro de producto, esfuerzo que crece con cada línea de RFQ, sin registro de dónde proceden los valores, y con errores de código o de marca detectados tarde.
• Solución propuesta: enriquecimiento automatizado de datos de producto a partir de fuentes del fabricante primero, asignado a los campos del ERP del distribuidor, con una fuente y un estado de revisión para cada valor.
• Primer paso: un piloto, cuyo alcance se está definiendo ahora: campos, reglas, fabricantes, RFQ de muestra y cómo se mide el éxito.
• Estado actual: sin resultados todavía, por diseño.

¿Qué es el enriquecimiento de datos de producto para un ERP?

El enriquecimiento de datos de producto para un ERP consiste en completar automáticamente un registro de producto a partir de fuentes externas en lugar de teclearlo manualmente: descripciones, categoría, dimensiones, peso, códigos aduaneros y de exportación, EAN, país de origen y datos del ciclo de vida. Para un distribuidor de piezas industriales, la principal fuente es el fabricante, porque solo los datos del fabricante son lo bastante fiables para aduanas, envíos y preguntas de los clientes. Un buen enriquecimiento hace tres cosas además de copiar valores: los convierte a las propias unidades y definiciones de campo del ERP, registra de dónde procede cada valor y marca los valores que entran en conflicto o faltan para que una persona pueda decidir.

El problema: sin registro de producto, no hay presupuesto

El distribuidor dispone de un gran stock de electrónica industrial. Aun así, muchas RFQ solicitan piezas que no ha vendido antes. En su ERP solo se puede dar un precio una vez que existe el registro de producto. Así que cada nueva línea de RFQ pasa por la misma cadena manual:

1. Llega la RFQ con una lista de números de pieza.
2. El producto no está en el ERP.
3. Alguien busca en el sitio web del fabricante la pieza exacta y su variante.
4. Los datos se copian campo por campo en el ERP.
5. Se crea el registro de producto, y solo entonces se puede cotizar la línea.

Esto se hace a mano, un producto a la vez. Antes de que se pueda crear y cotizar un producto, debe completarse un conjunto de campos obligatorios: identificación y descripciones, categoría y fabricante, el código arancelario de mercancías, dimensiones, peso neto y clasificación de control de exportaciones. Otros campos, como códigos alternativos, EAN, país de origen y datos del ciclo de vida, completan el registro y pueden añadirse más adelante. Una guía relacionada sobre superar los silos de datos en las cadenas de suministro de fabricación explica por qué los datos copiados a mano entre sistemas tienden a desviarse.

Lo que cuesta el problema: tiempo y errores

Aún no hemos medido el tiempo de búsqueda del distribuidor; acordar cómo medirlo forma parte del alcance del piloto. El coste sigue siendo fácil de ver en cómo se realiza el trabajo:

• La cotización está bloqueada. Un cliente que espera un precio primero espera un registro de producto. Cuantos más artículos nuevos haya en una RFQ, más tiempo esperará toda la cotización.
• El esfuerzo crece con cada línea. Cada artículo nuevo implica otra búsqueda, otra variante que identificar y otra ronda de copiado. Una RFQ larga lo multiplica.
• No hay registro de dónde provino un valor. Una vez que un peso o un país de origen están en el ERP, nadie puede saber si proceden del fabricante, de un anuncio de un revendedor o de una suposición.
• Los errores se detectan tarde. Las líneas de la RFQ contienen códigos que coinciden con varios productos, errores de escritura u OCR en los números de parte y piezas listadas bajo la marca incorrecta. Detectados a mano, aparecen después de que el registro del producto ya existe, o después de que la cotización ya se ha enviado.
• Las unidades no coinciden. Los fabricantes suelen publicar el peso y las dimensiones del embalaje, mientras que las reglas del distribuidor requieren valores solo del producto y en sus propias unidades. Cada búsqueda también implica una conversión.

Cómo planeamos resolverlo: datos del fabricante, mapeados al ERP

La propuesta sustituye las búsquedas una por una por un lote por cada lista de RFQ: entra toda la lista y cada producto vuelve con sus valores mapeados a los campos del ERP del distribuidor.

Los datos del fabricante van primero. Los valores se toman de tres tipos de fuentes, en un orden fijo:

1. El sitio web del fabricante. Datos extraídos directamente del fabricante y mapeados a los campos del distribuidor. La extracción ya funciona para 21 fabricantes, incluidos Siemens, Allen-Bradley, Schneider Electric, ABB, Omron, Lenze, Phoenix Contact y Pilz, y se pueden añadir más en función del volumen de RFQ.
2. La base de datos de Automa.Net, con datos de producto sobre piezas de más de 9.000 fabricantes, utilizada solo para los campos o productos que la fuente del fabricante no cubre.
3. Fuentes de terceros, utilizadas solo para las lagunas que queden, y solo aquellas que el distribuidor acepte, en el orden en que las acepte.

Cada valor muestra su fuente y su estado. Para cada campo, el resultado indica de dónde provino el valor y si puede utilizarse: confirmado, necesita revisión, conflicto entre fuentes o ausente. Cuando las fuentes discrepan, prevalece el valor del fabricante y el conflicto sigue visible. Las unidades siguen las propias reglas del distribuidor, con una marca cuando el fabricante publica solo valores empaquetados.

Los valores se capturan según las definiciones del distribuidor, no según el formato del fabricante. Los códigos de pedido alternativos se almacenan uno al lado del otro, de modo que cualquiera de los códigos encuentre el producto, y los datos de ciclo de vida incluyen el sucesor y el predecesor vinculados cuando el fabricante los publica. Nuestra guía sobre seguimiento de piezas industriales obsoletas explica por qué esos campos son importantes para un distribuidor.

Cada producto se clasifica según lo que aún necesita antes de cotizar:

• Listo para cotizar: todos los campos de creación del producto, cotización y envío están completos a partir de fuentes aceptadas.
• Necesita revisión: una coincidencia ambigua, un código corregido o valores conflictivos. Una persona confirma antes de crear el registro.
• Datos faltantes: campos obligatorios no encontrados en ninguna fuente acordada. Estos vuelven al tratamiento manual.

La salida se prepara para su importación en el ERP o se entrega a través de una API, según si el equipo quiere consultar productos individuales o enviar listas completas de RFQ. Estos son los mismos datos de producto que están detrás del servicio de enriquecimiento de datos de producto, aquí asignados a las definiciones de campos de una empresa.

El piloto como primer paso

El despliegue comienza con los campos que bloquean la cotización:

• Fase 1, desbloquear la cotización: el sitio web del fabricante como única fuente, los campos de creación del producto, cotización y envío, y la asignación a los campos y categorías del ERP del distribuidor.
• Fase 2, completar el registro: la base de datos de Automa.Net y las fuentes de terceros acordadas, los campos de enriquecimiento restantes y comprobaciones adicionales cuando se agotan los datos del fabricante.

Antes de construir nada, el piloto necesita cinco decisiones, y estas son las que estamos acordando ahora con el distribuidor:

1. La asignación de campos: categorías de producto, unidades y definiciones de ciclo de vida.
2. Reglas para datos incompletos del fabricante, por ejemplo cuando solo se publican el peso o las dimensiones del embalaje.
3. Fabricantes, RFQ de muestra y fechas, con una mezcla deliberada de códigos limpios, códigos alternativos y entradas problemáticas, para que el piloto pruebe los casos difíciles y no solo los fáciles.
4. Fuentes de terceros para las lagunas restantes: cuáles acepta el distribuidor y en qué orden.
5. Cómo se mide el piloto, por ejemplo el tiempo ahorrado por línea de RFQ en la búsqueda.

La etapa actual

El proyecto está en la fase de definición del alcance. Hemos mostrado al distribuidor cómo se capturarían, obtendrían y clasificarían los datos, y estamos acordando la asignación de campos, las reglas y la muestra del piloto. No publicaremos cifras hasta que el piloto se haya ejecutado con las RFQ reales del distribuidor y se haya medido de la forma acordada por ambas partes. Informaremos de los resultados en un seguimiento.

Hable con nosotros sobre un piloto con sus propios datos

Un piloto como este tiene sentido cuando los registros de producto son el cuello de botella entre una RFQ y un presupuesto:

• Nuevos artículos llegan con cada RFQ, y cada uno necesita un registro de producto antes de poder presupuestarse.
• Tu ERP tiene sus propias definiciones de campos, unidades y categorías que los datos del fabricante no coinciden uno a uno.
• Necesitas saber de dónde provino cada valor, para aduanas, control de exportaciones o preguntas de clientes.
• Tu proceso de RFQ ya tiene una forma fija. Nuestra guía sobre cómo agilizar el proceso de RFQ para piezas describe los pasos en los que normalmente se atascan los datos.

El primer paso es una conversación, no un contrato. Envíanos una muestra de líneas reales de RFQ y tu lista de campos del ERP, y te mostraremos qué campos pueden completarse a partir de fuentes del fabricante, cuáles necesitan revisión y cuáles faltan, antes de construir nada. Contacta con el equipo de Automa.Net para hablar sobre un piloto.

Preguntas frecuentes

¿Puede el software automatizar las búsquedas de productos para RFQ electrónicas?

En gran medida, sí. El software puede asociar cada línea de RFQ con el producto del fabricante, extraer los datos que necesita el ERP y asignarlos a los campos correctos. Las líneas con códigos ambiguos, errores de escritura o fuentes en conflicto siguen necesitando que una persona confirme, así que una buena configuración clasifica los productos en listos para cotizar, necesitan revisión y datos faltantes en lugar de adivinar.

¿Qué datos de producto necesita un ERP antes de un presupuesto?

Normalmente un código, descripciones, categoría, fabricante y código arancelario de mercancía para crear el artículo, además de dimensiones, peso neto y clasificación de control de exportación para presupuestarlo y enviarlo. EAN, país de origen, fase del ciclo de vida, sucesor y predecesor completan el registro y pueden añadirse más adelante.

¿De dónde provienen los datos enriquecidos del producto?

Primero, del sitio web del fabricante. La base de datos de Automa.Net completa campos o productos que el fabricante no cubre, y las fuentes de terceros acordadas completan solo lo que queda. Cada valor lleva su fuente, y cuando las fuentes discrepan, prevalece el valor del fabricante mientras el conflicto permanece visible.

¿Qué ocurre cuando el fabricante publica datos incompletos?

El piloto acuerda de antemano una regla para ello. Un caso habitual es un fabricante que publica solo el peso y las dimensiones del embalaje mientras el ERP necesita valores del producto sin embalaje: el valor se marca en lugar de introducirse como si fuera correcto. Los campos obligatorios que ninguna fuente acordada tenga vuelven al tratamiento manual.

¿Pueden los datos enriquecidos entrar en el ERP sin doble introducción de datos?

Sí. Los datos se asignan a los propios campos del ERP y se entregan como un archivo de importación o mediante una API, de modo que nadie los vuelve a teclear. Si el equipo envía listas completas de RFQ en un solo lote o busca productos individuales a través de la API es una de las decisiones que se toman durante el piloto.

¿Qué son el ECCN y el número estadístico en un registro de producto?

ECCN, el Número de Clasificación de Control de Exportaciones, indica si un producto está sujeto a controles de exportación y cuáles; se necesita antes de que algunos productos puedan enviarse al extranjero. El número estadístico es el código de mercancía aduanera, basado en el código HS internacional y ampliado por la UE, el Reino Unido o EE. UU. en sus propios códigos nacionales. Ambos son campos de los que puede depender una cotización o un envío, y los fabricantes no siempre los publican, por lo que cada valor lleva su fuente.

¿Cómo se mide un piloto de enriquecimiento de datos?

Ambas partes acuerdan la medida antes de que empiece el piloto, por ejemplo el tiempo de búsqueda ahorrado por línea de RFQ, la proporción de productos que vuelven listos para cotizar y la proporción que necesita revisión. La muestra debe mezclar códigos limpios, códigos alternativos y entradas problemáticas, para que el resultado refleje RFQ reales.