En cuanto se concreta la creación de un pasaporte digital del producto, el departamento de TI plantea una pregunta antes que ninguna otra: ¿A cuáles de nuestros sistemas debe acceder la plataforma? Es la pregunta adecuada, ya que detrás de ella se esconden datos de acceso, autorizaciones del cortafuegos y un concepto de seguridad del que alguien debe hacerse responsable.
Nuestra respuesta es breve: ninguno. Todos los sistemas que aportan datos al pasaporte se encuentran en el lado de origen y permanecen allí. Transpareo es exclusivamente el receptor al final de la cadena; los flujos de datos se dirigen de forma unidireccional hacia la plataforma. Este artículo traza el recorrido de los flujos: lo que aporta cada sistema, qué reglas se aplican a cada flujo y qué se recibe a cambio como acuse de recibo.
Lo que aporta cada sistema al carné
Los datos de un carné rara vez proceden de un único sistema. En la práctica, se distribuyen entre un puñado de clases de sistemas, cada una de las cuales aporta solo unos pocos campos:
- ERP: identidad del artículo, materiales, proveedores y origen, referencia a pedidos y lotes, cantidades. Datos maestros estables que rara vez cambian.
- MES: historial de producción, asignación de series y lotes, certificados de calidad, trazabilidad. Datos de eventos vinculados a un momento concreto.
- APS: momentos de producción y asignación de recursos. Rara vez es directamente relevante para el pasaporte; lo que importa suele proceder del MES.
- PLM: composición, listas de piezas, reparabilidad, piezas de recambio, estados de diseño. A juzgar por lo que exige el Reglamento de diseño ecológico, es la fuente más completa.
- PIM: descripciones, imágenes, instrucciones de mantenimiento y uso, variantes lingüísticas. Los contenidos destinados al consumidor.
- IoT: datos de estado y uso durante la fase de uso. Solo es necesario en determinados grupos de productos, como las baterías.
- CRM: historial de servicio y reparaciones de clientes individuales. En principio, se trata de datos personales y, por lo tanto, no deben figurar en un pasaporte público.
La Asset Administration Shell se sitúa por encima de los sistemas, no junto a ellos
Hay una distinción más importante que todas las demás: la Asset Administration Shell no se sitúa ## junto aERP, MES y PIM, sino por encima de ellos. No genera datos, sino que encapsula los existentes en submodelos interoperables. Para la conexión con Transpareo, esto significa: Un AAS es un formato de entrega cómodo, pero no imprescindible. Quien lo utilice, derivará el paquete de datos de sus submodelos; quien no lo haga, proporcionará los mismos campos por otra vía. Las razones por las que, a pesar de todo, consideramos que la «Asset Administration Shell» constituye una base excelente, se explican en el artículo sobre el AAS.
Cinco reglas que se aplican a cualquier flujo
Dirección. Todas las flechas apuntan hacia la plataforma. Transpareo no consulta ningún sistema fuente, y Transpareo no dispone de datos de acceso a ERP, MES, PIM ni PLM.
No existe ninguna conexión con sus sistemas que deba protegerse, ya que, sencillamente, no existe.
Desencadenante. El envío siempre se activa desde el lado de la fuente: por el propio fabricante, su middleware o un proveedor de servicios contratado. La plataforma espera; no recoge los datos.
Finalidad específica. Solo se transmite el subconjunto necesario para el «Pass», no el conjunto completo de datos del sistema fuente. El «Pass» solo necesita unos pocos campos de cada sistema; todo lo demás permanece donde está.
Autorización. La selección, el alcance y el momento de cada paquete los decide el lado fuente. Transpareo no puede recibir más de lo que se le ha entregado.
Autorizaciones. Lo que se permite hacer con los datos entregados en la plataforma lo regulan credenciales de acceso designadas: derechos mínimos, y lo que no esté expresamente permitido, sigue estando prohibido. Estas reglas se aplican en la plataforma, nunca con carácter retroactivo sobre la fuente.
Solo se devuelven los acuses de recibo
No es posible prescindir por completo de un canal de retorno, pero este no transmite datos, sino respuestas: la URL DPP o el GS1 Digital Link, el ID de versión, el estado de publicación y los mensajes de validación. Para la página de origen, estas respuestas son valiosas, ya que la referencia de la orden se puede almacenar directamente en el artículo del ERP o del PIM. No constituyen un acceso. Son el acuse de recibo de una entrega recibida.
Tres modelos que han demostrado su eficacia en la práctica
- Directamente desde el sistema principal. El ERP o el PLM envía los datos a través de un conector. Es sencillo y lógico cuando una fuente de datos predomina claramente.
- A través de una capa de agregación. El middleware o iPaaS agrupa los campos de ERP, MES y PIM y entrega un paquete. Es el caso habitual cuando intervienen varias fuentes.
- A través de submodelos AAS. La capa de gestión ya está en funcionamiento, y el paquete se deriva de sus submodelos. Resulta ventajoso en entornos de la Industria 4.0.
En la guía práctica sobre la integración con el ERP hemos detallado qué modelo se adapta a cada entorno de sistemas y cómo un proyecto de este tipo puede completarse en dos semanas en lugar de tres meses.
Lo que Transpareo no es, de forma deliberada
No ## esun segundo «sistema de registro». La plataforma almacena el registro de datos del pase y su historial de versiones inalterable, no los datos operativos del fabricante. Lo que se corrige en el ERP llega al Pass a través de una nueva entrega: como una versión nueva y trazable, no como un cambio silencioso en el inventario. En el artículo sobre firmas y certificados se explica cómo se firma esta cadena de versiones y cómo puede ser verificada por cualquiera.
Por lo tanto, en su plan de seguridad queda poco por comprobar, y esa es precisamente la intención. No hay datos de acceso que deba facilitar, ni aberturas en el cortafuegos hacia el interior, ni ningún sistema externo con derechos de lectura en su ERP.
El trabajo real del proyecto se traslada a donde debe estar: decidir qué campos deben figurar en el «pasaporte», y no quién puede iniciar sesión y dónde.
Preguntas sobre esta publicación
¿Necesita Transpareo acceso a nuestro ERP o a algún otro sistema?
No. Cada sistema que aporta datos se encuentra en el lado de origen y permanece allí, y Transpareo no dispone de datos de acceso al ERP, al MES, al PIM ni al PLM. No existe ninguna conexión con sus sistemas que deba protegerse, ya que, sencillamente, no existe. Por lo tanto, en el marco de su estrategia de seguridad, no es necesario facilitar datos de acceso, no hay que configurar ninguna conexión interna ni comprobar ningún sistema externo con derechos de lectura en su ERP.
¿Quién solicita una entrega y con qué frecuencia?
Siempre la parte de origen. La transmisión la inicia el propio fabricante, su middleware o un proveedor de servicios contratado; la plataforma se limita a esperar y nunca realiza ninguna recogida. La parte de origen decide la selección, el alcance y el momento de cada paquete, por lo que Transpareo tampoco puede recibir más de lo que se le ha entregado. Usted mismo determina la frecuencia de las entregas: los datos maestros estables rara vez cambian, mientras que los eventos de producción se producen cuando se producen.
¿Necesitamos una capa administrativa para ello?
No. La capa administrativa no se sitúa junto al ERP, el MES y el PIM, sino por encima de ellos, y no genera datos propios, sino que encapsula los datos existentes en submodelos interoperables. Por lo tanto, se trata de un formato de entrega práctico, pero no imprescindible. Quien la utilice, obtendrá el paquete de datos a partir de sus submodelos. Quien no lo utilice, suministrará los mismos campos por otra vía, directamente desde el sistema principal o a través de una capa de agregación.
¿Por qué sistema empezamos?
Teniendo en cuenta los requisitos del Reglamento sobre diseño ecológico, el PLM es la fuente individual más completa: en él se recogen la composición, las listas de piezas, la reparabilidad, las piezas de recambio y los estados de diseño. El sistema ERP aporta la identidad de los artículos, los materiales, los proveedores y el origen; el PIM, los textos e imágenes destinados a los consumidores; y el MES, los eventos relacionados con la producción y la trazabilidad. La mayoría de los pasaportes de producto solo necesitan unos pocos campos de cada sistema. Empiece por donde se encuentren la mayoría de sus campos obligatorios y vaya completando el resto poco a poco.
¿Se transfieren los datos de los clientes del CRM al carné?
No. El historial de servicio y reparaciones de cada cliente es, por principio, de carácter personal y, por lo tanto, no debe figurar en un pasaporte público. El CRM es la única clase de sistema de esta lista que queda totalmente excluida. No obstante, los eventos relacionados con reparaciones y el ciclo de vida pueden reflejarse, pero como eventos del producto, no de una persona concreta.
¿Qué información se recibe de la plataforma?
Recibos, no datos. El canal de retorno transmite la dirección DPP o el GS1 Digital Link, el identificador de versión, el estado de publicación y los mensajes de validación. Merece la pena archivar estas confirmaciones, ya que la referencia del pase puede gestionarse posteriormente directamente en el artículo dentro del ERP o del PIM. No se trata de un acceso, sino del acuse de recibo de una entrega recibida.
¿Qué ocurre cuando se corrige un valor en el ERP?
La corrección se incorpora al paso mediante una nueva entrega y se convierte en una nueva versión trazable, no en una modificación silenciosa en el inventario. Todas las versiones anteriores siguen estando disponibles y pueden verificarse, y eso es precisamente lo que hace que el historial resulte valioso para una auditoría. En el apartado «Firmas y certificados» del DPP se explica cómo se firma esta cadena de versiones y cómo puede ser verificada por cualquier persona.
¿Se convertirá Transpareo en un segundo «sistema de registro»?
No, y es a propósito. La plataforma almacena el registro del pase y su historial de versiones inalterable, no sus datos operativos; sus sistemas siguen siendo determinantes para todo lo que les pertenece. De este modo, el trabajo del proyecto se centra en lo que debe: en decidir qué campos deben incluirse en el «Pass», en lugar de en la cuestión de quién puede iniciar sesión y dónde.
