Datos maestros de repuestos antes de S/4HANA: dejar, fusionar o completar

El equipo de datos maestros saca el extracto de repuestos de ECC y lo ordena por texto breve. Tres líneas describen el mismo encóder rotativo. Una se creó en la planta cuya cinta transportadora funciona hoy con él. Otra se creó en una planta hermana que compró uno de reserva con su propio número. La tercera pertenece a una planta que cerró hace años, y sus registros siguen en el maestro. Los tres pasan a S/4HANA salvo que alguien decida lo contrario.

La migración a S/4HANA es la primera lectura completa de los repuestos en años

La decisión de pasar de SAP ECC a S/4HANA está tomada y financiada, y el maestro de materiales entra en el alcance. Los repuestos son el rincón de ese maestro que nadie lee de principio a fin en el trabajo diario. Mantenimiento busca el repuesto que necesita, compras pide lo que encuentra, y un registro que nadie busca no vuelve a verse. La migración cambia eso. Cada registro del extracto hay que mapearlo, cargarlo y comprobarlo, así que, por una vez, alguien los mira todos.

Lo que se encuentra es previsible. Hay materiales inactivos que nadie ha tocado en años. Está el mismo repuesto con varios números, creado en plantas distintas por personas que lo describieron bien, cada una con sus propias palabras. Y hay textos breves que dicen «ENCODER» y nada más, que ningún técnico encontrará en una búsqueda. Un caso medido apunta en la misma dirección. Una tesis de máster de 2024 de la Universidad de Lund estudió los repuestos de un OEM a través de sus datos del ERP, y sus autores concluyeron que el sistema necesitaba una limpieza.

Migrar esos registros tal como están lleva sus costes al nuevo sistema: el repuesto comprado dos veces porque el primero estaba con otro número, la reparación que espera un repuesto que nadie encuentra, las horas dedicadas a cuadrar registros a mano. Esos costes se resumen en nuestro artículo sobre los datos maestros de repuestos deficientes. La migración es el momento en que el presupuesto permite a un equipo ocuparse de ellos. No es la última vez que aparecen, y la última sección vuelve sobre ello.

Datos maestros de repuestos antes de S/4HANA: tres decisiones por grupo

Una herramienta de migración mueve registros. No decide qué registros deben existir, y esa decisión corresponde a quienes conocen los repuestos, antes de la carga. Es más fácil tomarla por grupos de registros que línea a línea. Ordena el extracto de repuestos en tres grupos:

• Dejar atrás. Registros sin movimientos, sin stock y sin ningún equipo instalado que los use. No se cargan, una vez que mantenimiento ha firmado que ninguna máquina sigue necesitando el repuesto.
• Fusionar. Registros que describen el mismo repuesto con números distintos. Un registro se queda y asume el stock y los datos de planta de los demás, y el resto se bloquea para que nadie haga pedidos contra ellos.
• Completar. Registros de los que dependen la próxima búsqueda y el próximo pedido, pero a los que les falta el fabricante, el número de pieza del fabricante o los atributos que distinguen una variante de otra. Migran una vez rellenados esos campos.

El encóder rotativo muestra cómo se aplican las tres. El material 300871, de la planta cerrada, dice «ENCODER», no tiene número de pieza y no se ha movido desde que cerró la planta. Se deja atrás, una vez que mantenimiento confirma que el encóder no está instalado en ningún otro sitio. El material 140552, de la planta hermana, dice «DREHGEBER 1024 IMP 10MM», lleva el número de pieza del fabricante escrito con guiones y tiene dos en stock. Es el mismo encóder que el registro propio de la planta de transportadores, así que se fusiona en ese registro, y sus dos encóders pasan a ser stock que ven las dos plantas. Encontrar parejas como esta es donde se van la mayoría de las horas. El material 100917, de la planta de transportadores, es el que queda tras la fusión y migra cuando está completo: el fabricante, el número de pieza del fabricante escrito de una sola forma, la resolución, el diámetro del eje y la señal de salida. Los números de material y los textos son propios del ejemplo.

El orden importa. Dejar atrás primero los registros muertos hace más pequeña la fusión, porque un duplicado en una planta cerrada ya no es algo que fusionar. Fusionar antes de completar significa que el equipo rellena los campos una sola vez, en el registro que queda, en lugar de tres. Cada grupo necesita además una firma distinta. Mantenimiento firma lo que se deja atrás, el almacén de repuestos y compras firman lo que se fusiona, y el equipo de datos maestros es responsable de lo que se completa.

La división tiene que encajar en las fechas de la migración

El extracto de una planta se puede ordenar a mano. El de un grupo empresarial, con decenas de miles de registros de repuestos en varias plantas e idiomas, no, y la migración va con fechas que el equipo de datos maestros no fija. Ordenar por movimientos y stock encuentra la mayor parte del primer grupo en una tarde. El segundo y el tercer grupo necesitan a alguien que lea textos breves, compare números de pieza escritos de tres maneras y decida qué atributos necesita cada tipo de repuesto. Esa lectura es donde una división manual se queda sin tiempo.

Partium Cockpit es donde el equipo hace ese trabajo. La clasificación sitúa cada repuesto de tu catálogo en su clase el mismo día en que lo subes. Todas las funciones de Cockpit parten de ese mapa. En el extracto, el encóder cae en su clase el día en que se carga, y la clase dice qué atributos lleva un registro completo. La deduplicación encuentra el mismo repuesto registrado con números distintos, y evita que un registro nuevo añada otro más. El DREHGEBER de la planta hermana y el encóder de la planta de transportadores llegan como un solo grupo, y la fusión sigue siendo decisión del equipo. En el Enriquecimiento dirigido de atributos, la tabla completa de resultados admite correcciones en línea y en bloque: la IA propone y tu equipo corrige. La propuesta y la decisión van por separado, así que cada campo rellenado en el registro del encóder es uno que el equipo aceptó.

El maestro cambia tras la puesta en marcha, así que los controles continúan

El día en que S/4HANA entra en producción, el maestro de repuestos está lo más limpio que va a estar nunca. A la mañana siguiente, un comprador de una planta hermana crea un registro para un repuesto que no encontró, y llega una máquina nueva con su lista de repuestos. Una limpieza hecha una sola vez, para la migración, empieza a envejecer esa misma semana. Los equipos que ya limpiaron su maestro una vez conocen el patrón: el dinero se gasta de golpe, y el deterioro vuelve a empezar.

Los controles que ordenaron el extracto son los que el nuevo maestro necesita cada día: una clase para cada repuesto nuevo, una comprobación de duplicados antes de guardar un registro nuevo, y los campos de los que depende una búsqueda rellenados antes de pedir el repuesto. Tu ERP sigue siendo el sistema de referencia. Partium Agent lee de él y escribe de vuelta lo que decide tu equipo. Trabajando así, el encóder sigue siendo un solo registro tras la puesta en marcha, y la próxima migración no parte del mismo extracto.

Empieza esta semana con una planta. Saca su extracto de repuestos y ordénalo en tres grupos: sin movimientos y sin stock; el mismo número de pieza del fabricante con dos o más números de material; y repuestos en uso a los que les falta el fabricante o el número de pieza. Cuenta cada grupo y lleva la primera lista a mantenimiento para que la firme. Esos tres recuentos son el tamaño de la decisión que tu migración está a punto de tomar. Para hacer la misma división con ese extracto, reserva una demo y míralo con nuestro catálogo de demostración o con una muestra de tus datos.