Cómo organizar la documentación de ingeniería hardware

# Cómo organizar la documentación de ingeniería de hardware

Los archivos de un proyecto hardware rara vez se pierden de verdad. El problema habitual es otro: existen, pero nadie sabe con seguridad cuáles describen el producto que se fabricó.

Un esquemático está en Git. La BOM está en una hoja de cálculo. Los Gerbers están en una carpeta compartida. El informe de EMC vive en Drive. La decisión de sustituir un condensador quedó escrita en un mensaje de hace dos años.

Todo está guardado. Lo difícil es reconstruir la relación entre esas piezas de información.

Una buena estructura de documentación debe permitir responder preguntas concretas: qué documentación pertenece a una tarjeta, qué revisión fue liberada, qué cambió respecto a la anterior y qué información se utilizó para fabricar o verificar esa versión.

Qué cuenta como documentación de ingeniería de hardware

Más cosas de las que suelen terminar dentro de la carpeta llamada Documentation.

Los archivos de diseño y fabricación suelen recibir bastante atención porque alguien tiene que utilizarlos o enviarlos a un tercero.

La documentación de decisiones suele recibir mucha menos. Y precisamente esa información es la más difícil de reconstruir unos años después.

El problema no suele ser dónde guardar los archivos

Casi cualquier equipo tiene almacenamiento suficiente: Git, un NAS, un servidor de archivos, Google Drive, SharePoint o una combinación de varios.

Lo que estos sistemas no proporcionan automáticamente es el contexto de ingeniería.

Una carpeta puede contener:

schematic_v3.pdf
bom_rev4.xlsx
gerbers_final.zip

pero el directorio por sí solo no sabe:

• qué revisión física describe cada archivo;
• si esa BOM corresponde al mismo diseño que esos Gerbers;
• si gerbers_final.zip fue realmente el paquete liberado;
• si existe una revisión posterior que nunca llegó a producción;
• ni por qué se sustituyó un componente concreto.

Esa información suele mantenerse mediante convenciones, nombres de archivo y memoria colectiva.

Mientras el proyecto es pequeño puede funcionar perfectamente. El problema aparece cuando aumentan las revisiones, los productos, los ingenieros o los años que hay que mantener el diseño.

Organiza la información alrededor del hardware

Una estructura exclusivamente basada en tipos de archivo parece ordenada:

Schematics/
BOM/
Gerbers/
Test reports/
Datasheets/

pero no responde especialmente bien a una pregunta habitual:

¿Qué documentación corresponde a la revisión C de la tarjeta de control?

Para contestarla hay que recorrer varias carpetas y determinar manualmente qué archivo pertenece a esa revisión.

Una alternativa más útil es organizar primero por aquello que la documentación describe:

Producto
└── Tarjeta de control
    ├── Rev A
    │   ├── diseño
    │   ├── fabricación
    │   └── verificación
    │
    ├── Rev B
    │   ├── diseño
    │   ├── fabricación
    │   └── verificación
    │
    └── Rev C
        ├── diseño
        ├── fabricación
        ├── verificación
        └── decisiones

No tiene por qué ser literalmente este árbol. Un equipo que trabaje principalmente con Git, PDM o PLM puede representar la misma relación de otra manera.

Lo importante es conservar el vínculo:

producto → elemento de hardware → revisión → documentación correspondiente.

Ese modelo responde mucho mejor a la forma en la que se investigan problemas reales.

Cuatro reglas que funcionan incluso si cambias de herramienta

1. La revisión debe poder identificarse sin depender únicamente del nombre del archivo

Cuando el formato lo permita, incluye la identificación de revisión dentro del propio documento: cajetín de un plano, portada de un informe, encabezado de una BOM o metadatos controlados.

main_board_schematic.pdf puede renombrarse.

Un documento que indica claramente:

Main Control Board
Hardware revision: C
Document revision: 2
Released: 2026-09-14

es mucho menos ambiguo.

No todos los formatos de ingeniería permiten representar estos datos de la misma manera, por lo que la solución concreta dependerá de las herramientas utilizadas.

2. Una liberación debe quedar congelada

El conjunto utilizado para fabricar una revisión concreta no debería seguir cambiando silenciosamente.

Puede resolverse mediante:

• permisos de sólo lectura;
• una baseline;
• una release;
• una etiqueta o commit protegido;
• un paquete archivado con control de cambios;
• un sistema PDM o PLM.

El mecanismo es secundario.

La propiedad importante es ésta: meses después debe ser posible recuperar exactamente el conjunto que fue liberado.

3. Evita copias independientes del mismo dato

Supongamos que cuatro proyectos utilizan el mismo componente.

Copiar su datasheet en cuatro carpetas diferentes genera cuatro copias que pueden terminar representando ediciones distintas del documento.

Cuando sea posible, conserva una fuente controlada y referencia esa información desde los proyectos que la utilizan.

Hay una matización importante: los fabricantes actualizan datasheets. Para componentes críticos o productos de vida larga puede interesar conservar también la edición concreta utilizada durante el diseño o la liberación, con su fecha o número de revisión.

Un enlace a la página actual del fabricante no siempre es suficiente para reconstruir una decisión tomada cinco años antes.

4. Registra las decisiones junto al objeto al que afectan

Una nota como:

C37: cambiado de 10 µF X5R Murata a Samsung debido a EOL del MPN original. Alternativa verificada en Rev C.

tiene mucho más valor junto al componente, la BOM o el cambio correspondiente que enterrada en un hilo de chat.

El correo y la mensajería sirven para discutir decisiones.

Son bastante peores como archivo técnico permanente de esas decisiones.

La documentación que suele faltar

Los entregables formales son sólo una parte de la memoria de ingeniería de un proyecto.

Hay otra información que rara vez aparece en una lista oficial de documentos, pero determina si otro ingeniero puede entender el diseño.

Por qué se eligió una pieza

Especialmente cuando existe una alternativa más barata o aparentemente mejor.

No hace falta escribir una memoria de tres páginas. A menudo basta con algo así:

U7 — TPS62130RGTR. Se descartó la alternativa X por comportamiento durante arranque con carga capacitiva.

Qué se probó y no funcionó

Las soluciones descartadas también contienen información.

Si una topología ya produjo oscilaciones o una determinada combinación de valores hizo inestable un convertidor, no registrar el resultado permite que alguien repita exactamente el mismo experimento dos años después.

Dónde están los márgenes pequeños

Una nota como:

Rail 5V_AUX: margen térmico reducido a 60 °C ambiente con carga continua máxima.

puede cambiar completamente la forma de analizar una incidencia.

Es el tipo de conocimiento que fácilmente permanece sólo en la cabeza del diseñador original.

Cómo se realizó una prueba

Un resultado sin condiciones de ensayo puede ser difícil de reproducir.

Además de:

Passed 48 h thermal test.

conviene conservar datos como:

Ambient: 55 °C
Input: 24 V
Load: 3.2 A continuous
Enclosure: closed
Firmware: 1.6.2
Board: Main Control Board Rev C

Qué limitaciones son conocidas y deliberadas

No todo lo pendiente es un error.

Puede haber:

• riesgos aceptados;
• mejoras pospuestas;
• funciones no implementadas;
• condiciones de funcionamiento no verificadas;
• componentes que se sabe que habrá que sustituir.

Documentarlo evita que una limitación conocida se convierta después en una sorpresa.

Un problema realista dieciocho meses después

Una unidad instalada en cliente empieza a fallar de forma intermitente cuando aumenta la temperatura.

La pregunta inicial parece sencilla:

¿Qué hardware llevaba esa unidad?

Pero investigar el problema puede requerir reconstruir una cadena como ésta:

1. determinar qué revisión de tarjeta se montó;
2. localizar la BOM liberada para esa revisión;
3. identificar qué componente estaba previsto en C14;
4. consultar la documentación técnica de esa pieza;
5. comprobar si C14 había cambiado respecto a revisiones anteriores;
6. revisar por qué se aprobó el cambio;
7. localizar las pruebas térmicas realizadas sobre esa revisión.

Los pasos 2 a 7 son fundamentalmente un problema de documentación y control de configuración.

El paso 1 es diferente.

Documentación de diseño no es genealogía de fabricación

Relacionar un número de serie concreto con la revisión exacta de hardware y las piezas realmente instaladas exige información procedente de producción.

Por ejemplo:

Serial 003842
→ Work order 2026-147
→ Main Control Board Rev C
→ assembly configuration XYZ

Eso entra en trazabilidad de fabricación o genealogía de producto.

Un sistema de documentación puede describir perfectamente la Rev C sin saber si el número de serie 003842 fue fabricado con ella.

Conviene mantener esa frontera clara, porque son problemas relacionados pero distintos.

Checklist de documentación para una revisión de hardware

Para un producto que tendrá varias revisiones o permanecerá años en producción, comprobaría al menos lo siguiente:

• [ ] Es posible identificar qué documentación pertenece a cada elemento de hardware.
• [ ] Es posible distinguir claramente una revisión liberada de una revisión todavía en desarrollo.
• [ ] Los documentos relevantes indican su revisión o disponen de metadatos controlados equivalentes.
• [ ] El paquete utilizado para fabricar una revisión liberada puede recuperarse sin modificaciones posteriores.
• [ ] La BOM está vinculada inequívocamente con la revisión de hardware correspondiente.
• [ ] Las referencias DNP y configuraciones especiales están documentadas.
• [ ] Las sustituciones importantes de componentes incluyen su justificación.
• [ ] Las decisiones técnicas relevantes no dependen exclusivamente de correo o mensajería.
• [ ] Las pruebas incluyen las condiciones necesarias para poder interpretarlas o reproducirlas.
• [ ] Las limitaciones conocidas y riesgos aceptados están documentados.
• [ ] Las fichas técnicas críticas pueden recuperarse en la versión utilizada durante el diseño cuando sea necesario.
• [ ] Otro ingeniero puede encontrar la información sin depender del autor original.

Una prueba práctica es pedir a alguien que no haya creado la estructura que localice el paquete de fabricación y la BOM de la última revisión liberada.

Si necesita preguntar cuál de tres archivos llamados final es el correcto, todavía hay trabajo que hacer.

Cuándo basta con carpetas

Muchas veces, las carpetas son suficientes.

Un único producto, uno o dos ingenieros, pocas revisiones y ningún requisito especial de control documental pueden funcionar durante años con:

• un árbol de directorios coherente;
• una convención de nombres;
• Git para los archivos que encajan bien en control de versiones;
• paquetes de release congelados;
• y un pequeño registro de cambios.

Añadir una plataforma más también tiene un coste. Si no elimina ningún problema real, sólo añade administración.

Las limitaciones aparecen cuando la relación entre productos, tarjetas, revisiones, documentos y componentes empieza a ser más compleja que la propia estructura de directorios.

En ese punto conviene dejar de pensar sólo en dónde está el archivo y empezar a controlar qué describe, a qué revisión pertenece y con qué otros datos está relacionado.

En estructura de carpetas para proyectos hardware explicamos cómo llevar una organización basada en carpetas bastante lejos antes de necesitar algo más.

Cuando las relaciones importan más que las carpetas

Una carpeta es buena almacenando archivos. No está diseñada para representar por sí sola relaciones de ingeniería.

No sabe que:

• una BOM corresponde a Main Control Board Rev C;
• un PDF describe el mismo elemento;
• una baseline anterior pertenece a Rev B;
• ni que una revisión experimental nunca fue liberada.

Ese contexto puede mantenerse manualmente, mediante convenciones, o utilizando herramientas que lo representen explícitamente.

XKEMA sigue este segundo enfoque: permite organizar documentación e información de ingeniería alrededor de los elementos de hardware que describen y mantener su contexto de versionado y baseline dentro del proyecto.

No sustituye a Git para controlar código o fuentes donde Git sea la herramienta adecuada, ni a un ERP para gestionar compras y operaciones de producción. Su ámbito es mantener conectado el contexto técnico del producto a medida que aumenta la documentación y aparecen nuevas revisiones.