Git, PDM o PLM: elegir por modelo y no por lista de funciones

Las comparativas de herramientas de datos de hardware acaban casi siempre en listas de funciones, que es la forma menos útil de elegir una. Las funciones son fáciles de añadir y difíciles de evaluar. Lo que de verdad determina si un sistema encaja es más antiguo y más simple: ¿cuál es la unidad en la que piensa?

Todo lo demás se deriva de ahí. Un sistema organizado alrededor de ficheros responde bien a preguntas sobre ficheros y mal a preguntas sobre piezas, por muchas funciones con forma de pieza que se le atornillen.

Así que aquí van cuatro modelos, ordenados por su unidad.

Cuatro modelos

Ficheros y carpetas. La unidad es un fichero. Las preguntas sobre ficheros son triviales; las demás son una búsqueda manual. Todos los proyectos empiezan aquí y muchos no necesitan salir nunca.

Git y similares. La unidad sigue siendo un fichero, más un histórico de estados. Añade autoría, recuperación exacta de estados pasados y trabajo en paralelo. Sigue siendo un sistema de ficheros en su modelo del mundo.

PDM — gestión de datos de producto. La unidad es un elemento: una pieza, un conjunto, un documento, cada uno con revisiones y relaciones. Puede responder «¿dónde se usa esta pieza?» y «¿de qué está hecho este conjunto?» porque son preguntas sobre elementos, que es lo que guarda.

PLM — gestión del ciclo de vida. La unidad sigue siendo un elemento, pero el sistema modela además los procesos a su alrededor: peticiones de cambio, aprobaciones, efectividad, a veces fabricación y cadena de suministro. Es PDM más flujo de trabajo, y el flujo de trabajo es casi todo el coste.

La progresión no es un ranking. Es un aumento de lo que el sistema sabe, pagado con configuración, administración y rigidez.

Qué preguntas responde cada uno de forma natural

«De forma natural» significa sin una búsqueda manual ni una convención que alguien tenga que recordar.

La última fila se lee junto con las demás. Un PLM responde a más preguntas que nada en esa tabla, y por eso exactamente es la elección equivocada para un equipo que todavía no tiene esas preguntas.

El coste no es sólo dinero

El coste visible son las licencias. Los invisibles deciden si la cosa sobrevive al contacto con un equipo real.

Puesta en marcha. Numeración de elementos, categorías, permisos, definiciones de flujo. Un sistema basado en elementos exige decisiones antes de servir para nada, y esas decisiones son difíciles de cambiar después.

Administración. Alguien se hace cargo del sistema. En una empresa pequeña ese alguien es un ingeniero que preferiría estar diseñando.

Fricción por cambio. Si registrar un cambio cuesta quince minutos, la gente deja de registrar cambios, y los datos se convierten en ficción silenciosamente. Es el fallo más común de un sistema sobredimensionado, y es peor que no tener sistema, porque la gente se lo cree.

Coste de salida. ¿Cuánto cuesta sacar tus datos en un formato usable? Hay que preguntarlo antes de entrar, no después.

De los cuatro, la fricción es la que decide el resultado, y es la que nadie evalúa durante una prueba. Una prueba la lleva quien eligió la herramienta, sobre un proyecto limpio y sin fecha de entrega. El examen de verdad es si un ingeniero con una tarjeta que sale el viernes sigue registrando bien una sustitución a las seis de la tarde, y eso no lo responde ninguna demostración. Si puedes, pregunta a una empresa de tu tamaño qué dejaron de hacer después del primer año.

Un camino de decisión

En vez de una matriz, una secuencia de preguntas. Párate en la primera en la que te reconozcas.

¿Eres una persona con un producto y entregas poco frecuentes? Carpetas y un procedimiento de entrega escrito. De verdad. Añade Git cuando el histórico empiece a importar.

¿Pierdes trabajo, o discutís sobre qué fichero es el bueno? Git, para la fuente del diseño. Resuelve exactamente eso y cuesta una tarde.

¿Reutilizas componentes entre varias tarjetas, y un cambio de pieza obliga a revisar cada proyecto a mano? Se te han quedado pequeñas las herramientas de ficheros. La pregunta «¿dónde se usa esto?» no la puede responder ningún sistema cuya unidad sea un fichero. Es el momento en que un sistema de componentes y BOM empieza a pagarse solo.

¿Necesitas aprobaciones formales, fechas de efectividad y un proceso de cambio auditable porque lo exige un cliente o un regulador? Eso es terreno de PLM, y lo que estás comprando es el motor de flujo de trabajo.

¿El proceso de cambio abarca compras, planificación de producción y costes? Entonces la pregunta es tanto de ERP como de ingeniería, y la herramienta de ingeniería tiene que convivir en vez de competir.

La mayoría de los equipos que lean esto están en el paso tres y estirando la mano hacia el cuatro, que es el error caro de este campo: comprar maquinaria de proceso para resolver un problema de datos.

Dónde está XKEMA, y dónde no

XKEMA está en la tercera banda: datos de componentes, BOM y configuración con versionado. Ser concreto con los bordes es más útil que una lista de funciones.

Qué hace. Componentes como registros compartidos a los que apuntan las tarjetas que los usan. Tarjetas, BOM, documentos y datos de PCB guardados como versiones con autor, fecha y un enlace explícito a la versión anterior. Un paso de revisión antes de cerrar una revisión, con firma registrada. Comparación entre dos versiones de una BOM o de un paquete de fabricación. Una vez cerrada, una revisión está cerrada: cambiarla significa crear una versión nueva.

Qué no hace. No guarda ficheros nativos de ECAD: tu esquema y tu layout pertenecen a Git o al sistema del propio fabricante de tu ECAD, y este artículo no es un argumento para moverlos. No es un PLM: no hay motor de flujo de peticiones de cambio, ni calendario de efectividad, ni costes, ni módulo de cadena de suministro. No sigue unidades fabricadas individuales: registra qué contenía una revisión, no con qué revisión se fabricó una unidad concreta con número de serie.

Si necesitas lo del segundo párrafo, un PLM es la respuesta honesta, y te servirá mejor que una herramienta más ligera estirada más allá de su diseño.

La pregunta útil no es qué modelo es mejor. Es qué preguntas estás respondiendo ahora mismo a mano, y con qué frecuencia.

ECAD, ERP y XKEMA Git y KiCad: qué versionar Gestión de configuración de hardware ¿Cuándo se le queda pequeña una hoja de cálculo?