«El PLM ha muerto» —lo oigo una y otra vez. Puede que sea cierto. Y puede que no lo sea. Porque todo depende de lo que se entienda por PLM. Desde cierta perspectiva, la afirmación tiene su sentido. No desde la mía, que conste. Porque creo que el PLM está más vivo que nunca. Y con gusto explico por qué.
¿Software PLM o disciplina PLM? La diferencia decisiva
Empecemos por la pregunta de qué quiere ser el PLM en realidad.
Primera lectura
PLM son las grandes suites: Teamcenter, Windchill, ENOVIA. Sistemas monolíticos que prometen representar todo el ciclo de vida del producto. Spoiler: para esta lectura, la frase «el PLM ha muerto» —quizá— tiene cierta razón de ser. No necesariamente, pero sí es defendible.
Segunda lectura
PLM es la disciplina que abarca todo lo que pertenece al ciclo de vida del producto. Gestión de la configuración, gestión de cambios, trazabilidad, integración de sistemas a lo largo de todo el ciclo de vida. Para esta lectura, el PLM está lejos de estar muriendo. Al contrario: apenas ahora se está convirtiendo en lo que siempre quiso ser.
Mi visión del PLM siempre fue la segunda lectura. Para mí describe lo que realmente significa el PLM —y, para quien le suene demasiado particular: Gartner define el PLM como “philosophy, process and discipline supported by software”. Disciplina primero, software como herramienta. Aun así, muchos siguen entendiendo el PLM más bien como una categoría de producto para suites en el contexto de ingeniería.
Lo que muere: las suites PLM monolíticas
Que estas conocidas suites PLM, a menudo monolíticas, sigan siendo el modelo dominante está hoy más en el aire que nunca. Porque la dirección hacia la que va todo esto está clara, aunque el proceso sea lento. Tres reflexiones al respecto:
Primero: la creencia de que un solo sistema puede cubrirlo todo no es sostenible en muchos casos. Los proveedores de PLM heredados han crecido mediante adquisiciones, no (solo) mediante innovación arquitectónica. El resultado son, como lo describe el analista de PLM Oleg Shilovitsky (que, eso sí, vende él mismo un enfoque de PLM descentralizado), “conglomerados de herramientas, mantenidos unidos por integraciones, a veces con modelos de datos incompatibles”. Quien haya tenido que vivir esa experiencia dolorosamente, asiente. Quien no, todavía lo aprenderá.
Segundo: el péndulo de hacer o comprar se inclina hacia el hacer, y la IA lo acelera. No porque los desarrolladores programen ahora diez veces más rápido. Sino porque dominios periféricos de PLM claramente delimitados —plataformas de lanzamiento, flujos de gestión de cambios, soluciones de trazabilidad específicas— de repente son desarrollables de forma realista por cuenta propia. Lo que antes fracasaba por el esfuerzo y el riesgo de mantenimiento, hoy se puede hacer con equipos mucho más pequeños. Esto quizá (todavía) no vale para una arquitectura PLM completa. Pero en los puntos donde las soluciones monolíticas están sobredimensionadas y aun así generan costes de licencia año tras año, el cálculo cambia.
Flashback a un proyecto en el que participé yo mismo hace unos años: un cliente quería construir su propia plataforma de lanzamiento de software. Todo desarrollado internamente. En su momento fui escéptico y recomendé revisar qué soluciones ya existían en el mercado. La programación asistida por IA, que hoy hace mucho más asequibles este tipo de proyectos, todavía no existía entonces. El cliente ya se había decidido, y dado su tamaño era viable, aunque caro, no optar por una solución estándar. Quizá incluso demasiado caro. Avance rápido: con las posibilidades actuales, mi valoración probablemente sería distinta, lo que no significa que hoy rechazara una solución “de fábrica”. Pero las tendencias están cambiando.
Tercero: el PLM como archivo de documentos ya pasó —las exigencias, en realidad, siempre fueron mayores. Que el PLM debe ser algo más que un archivo de documentos glorificado es ya un consenso. Pero el consenso dista mucho de estar operacionalizado, y en la realidad operativa la acción va por detrás de la comprensión. Y eso que la exigencia de lo que un sistema PLM moderno realmente debería lograr no suena nada descabellada: un modelo de datos de producto estructurado que represente piezas, variantes, dependencias e historiales de cambios de forma legible por máquina. Trazabilidad completa desde el requisito, pasando por el código y el CAD, hasta el producto terminado en el campo. Integración de todos los procesos relevantes, de la A de posventa (after sales) a la Z de archivo de planos.
Solo que una herramienta que sirve para todo no sirve bien para nada. Eso vale para las navajas suizas, y vale para las suites PLM monolíticas. El modelo de datos es genérico porque tiene que serlo. No existe la integración total, porque en la empresa siempre hay también otros mundos de sistemas (piénsese en el ERP). Y: quien quiera construir un modelo de datos de producto realmente profundo y específico del dominio —uno que represente con precisión las propias piezas, variantes y procesos— se topa en el monolito con esfuerzos de adaptación que pueden llegar a consumir todo el valor añadido. Las herramientas especializadas con estándares abiertos evitan este problema, al menos en parte, porque desde el principio están diseñadas para la interoperabilidad, no para la exhaustividad.
Lo que no muere: el PLM como disciplina, porque la necesidad crece
Un hecho: los productos son cada vez más complejos. Los límites entre mecánica, electrónica y software se difuminan.
Ejemplo del sector automotriz: según estimaciones, los fabricantes (OEM) pierden entre 500 millones y mil millones de dólares al año por retiradas físicas que técnicamente podrían resolverse con una actualización OTA (eSync Alliance, 2023; ABI Research, 2023). Que las actualizaciones OTA aún no estén generalizadas donde técnicamente podrían estarlo se debe también a la complejidad de los productos. Un coche ya no es la máquina sencilla de antes, que en caso de duda se podía reparar en cualquier taller perdido en el desierto. Para que una actualización OTA funcione —y hablo por experiencia— hace falta una maquinaria bien engrasada que mantenga la visión de conjunto de todos los productos en el campo, su configuración, su versión de software y todas sus dependencias.
Por eso: gestión de la configuración, gestión de cambios, trazabilidad a lo largo de todo el ciclo de vida… la necesidad de profesionalizar estas disciplinas está lejos de disminuir. Al contrario, se vuelve más exigente.
Por supuesto, entiendo a quien dice «el PLM ha muerto» después de un proyecto de PLM que se le quedó a medias y no entregó lo prometido. Solo que esa persona quizá haya confundido el síntoma con la enfermedad. La herramienta tropezó, pero la disciplina, la continuidad y la mentalidad detrás de ella posiblemente nunca se vivieron de verdad, y puede que tampoco se entendieran.
Una frase atribuida al veterano del PLM Rob Ferrone dice más que diez mazos de diapositivas: «Durante mis primeros cinco años ni siquiera sabía que hacíamos PDM o PLM, pero lo hacíamos». Si lo contrario también es cierto —si las empresas compran el software pero nunca implementan la disciplina—, entonces la frustración es comprensible, pero esta apunta a la forma en que se introdujo el PLM, no a la disciplina en sí.
Solo el 13 % cree que no podría trabajar sin el PLM
A esto se suma un dato que llama la atención: solo el 13 % de las empresas que usan PLM dicen que no podrían trabajar sin él. Que sea el 10, el 13 o el 20 % casi no importa. La verdadera conclusión está en el razonamiento inverso: la mayoría de las empresas cree que podría prescindir del PLM. No. No pueden. Toda empresa que desarrolla y fabrica productos hace PLM, de una forma u otra. La única pregunta es si entiende lo que está haciendo…
El verdadero reto: falta de arquitectura y organización insuficiente
El Digital Thread —el hilo de datos continuo y bidireccional desde el requisito hasta la operación— es la visión que siempre ha estado estrechamente ligada al concepto de PLM. “Single Source of Truth”, trazabilidad desde el requisito hasta el campo: los proveedores lo prometían ya en la década de 2000. Lamentablemente, con demasiada frecuencia no se cumplió, por motivos muy diversos:
Y es que, sorprendentemente, pocas veces el motivo del fracaso es el software. Es lo que falta alrededor del software: estructuras de información y de datos. Ontologías. Una organización dispuesta a abordar en serio sus procesos. En resumen: arquitectura. Y esta no surge por sí sola, da igual si se compra o se construye.
Quien compra, compra una casa prefabricada. Y quien compra una casa prefabricada debe estar dispuesto a aceptar las plantas ya definidas. Aunque eso signifique dejar ir hábitos muy queridos y acostumbrarse a nuevos flujos de trabajo. Eso, desde luego, no ocurre solo. Es trabajo. Y es precisamente ese trabajo el que se tiende a evitar: los procesos existentes propios suelen ser una especie de santo grial, y el éxito pasado quizá hasta le dé la razón a uno. Pero: quien al final retuerce el software estándar en lugar de adaptarse, se trae a casa los esfuerzos de personalización que pueden acabar con todo el valor añadido. El fracaso, entonces, no es un problema de software. Es un problema de deberes sin hacer.
Quien construye no tiene el problema de la planta, pero sí otro. Herramientas PLM a las que todavía les falta una u otra función deseada, más la nueva disponibilidad del desarrollo de software asistido por IA: eso lleva rápidamente a la decisión de querer construir algo propio. Ya sea completamente “from scratch”, ya sea como una combinación muy particular de diversas herramientas. Se puede hacer, como se vio antes: el cálculo realmente ha cambiado. Pero: una arquitectura de Digital Thread continua necesita, con más razón aún, una arquitectura. Quien simplemente empieza a construir sin más, levanta un paisaje de herramientas que al principio funciona más o menos, que al poco tiempo apenas se puede mantener y que, tarde o temprano, le explota en la cara. La TI improvisada en Excel vuelve a asomar la cabeza.
Ergo: la inversión en organización y arquitectura de la información no es una opción, es el billete de entrada. En ambos caminos. Solo quien lo ha entendido —y solo ese— encuentra interesante la opción de construir: porque si el trabajo de arquitectura hay que hacerlo de todos modos, la ventaja del monolito es menor de lo que sugiere su etiqueta de precio. Un enfoque descentralizado, alejado de las suites establecidas, vale hoy más que nunca al menos la pena considerarlo. Podría merecer la pena.
Pero volvamos a la pregunta inicial. ¿Ha muerto el PLM?
❤️ El PLM vive
Si por PLM se entiende la disciplina (y en eso me mantengo), entonces la respuesta es clara: el PLM está más vivo que nunca. Las exigencias no disminuyen. Los productos no se simplifican. Y el coste de descuidar esta disciplina aumenta.
¿Van a desaparecer los grandes monolitos de PLM? No lo sé, y prefiero no hacer profecías. Los argumentos a favor son, al menos, plausibles. Pero los proveedores de PLM tampoco son tontos: también ven los cambios que vemos todos. Arquitecturas más abiertas, ofertas más modulares, SaaS: eso ya está llegando, y en algunos proveedores con más fuerza que en otros. Si cuaja o no, lo decidirá el mercado.
¡Viva el PLM! 😉🖖
Preguntas frecuentes
¿Ha muerto el PLM o no?
Depende de la lectura. Como suite monolítica (Teamcenter, Windchill, ENOVIA), la afirmación al menos merece debatirse. Como disciplina —gestión de la configuración, gestión de cambios, trazabilidad, etc.— es sencillamente falsa. Esta disciplina se vuelve más importante, no más superflua.
¿Qué diferencia al software PLM de la disciplina PLM?
El software es la herramienta, la disciplina es el propósito detrás de ella. Gartner define el PLM como “philosophy, process and discipline supported by software”: disciplina primero, herramienta después. Que un proyecto de PLM fracase no significa, por tanto, que la disciplina haya fracasado, sino a menudo solo que nunca se vivió de verdad.
¿Compensa ahora más desarrollar el PLM internamente (make) que comprar una suite PLM (buy)?
El cálculo cambia porque el desarrollo asistido por IA hace realmente viable construir por cuenta propia dominios periféricos de PLM bien delimitados. Para una arquitectura PLM completa, eso en general todavía no se aplica. Y: tampoco el make ahorra el trabajo de arquitectura; quien simplemente empieza a construir sin más acaba con un paisaje de herramientas que pronto deja de ser mantenible.
¿Qué es el Digital Thread y por qué es relevante?
El hilo de datos continuo y bidireccional que va del requisito, pasando por el CAD y el código, hasta el campo: la visión que el PLM promete desde la década de 2000. A menudo no se cumple porque falta la arquitectura detrás, no porque el software no pueda hacerlo.
