Herramientas y flujo de trabajo
¿Cuándo se le queda pequeña una hoja de cálculo a un proyecto?
Cinco etapas y lo concreto que se rompe en cada una. Los cuatro límites estructurales detrás de todas, los arreglos baratos primero y qué mover si te mueves.
# Cuándo una hoja de cálculo deja de ser suficiente para gestionar BOMs de hardware
Una hoja de cálculo es una herramienta excelente para una lista de materiales.
Es rápida, flexible, todo el mundo sabe abrirla y prácticamente cualquier fabricante, EMS o proveedor puede trabajar con un XLSX o un CSV. También se utiliza en empresas grandes, porque hay problemas para los que una tabla sigue siendo exactamente la herramienta correcta.
Así que la pregunta útil no es:
¿Deberíamos dejar de usar Excel para nuestras BOM?
La pregunta es:
¿En qué momento empieza a costarnos más mantener las relaciones entre BOM, componentes, revisiones y productos que trabajar con la propia lista?
Ese punto suele aparecer de forma gradual.
Etapa 1 — Una tarjeta, una persona
Tienes una tarjeta y una BOM:
RefDes | Qty | Value | Manufacturer | MPN
R1 | 1 | 10k | Yageo | RC0603FR-0710KL
C1-C4 | 4 | 100nF | Murata | GRM188R71C104KA01D
U1 | 1 | | STMicro | STM32G474RET6Es sencillo, legible y suficiente.
No hay ninguna razón técnica para convertirlo en algo más complejo.
Primera fricción: ninguna que justifique cambiar de herramienta.
Etapa 2 — Empiezan a acumularse revisiones
La tarjeta evoluciona.
Aparecen archivos como:
main_board_BOM_v2.xlsx
main_board_BOM_v2_final.xlsx
main_board_BOM_revC.xlsx
main_board_BOM_revC_final2.xlsxLa hoja sigue funcionando perfectamente como BOM.
Lo que empieza a degradarse es la identificación de la configuración.
Se vuelve más difícil responder con seguridad:
¿Cuál de estos archivos corresponde a la Rev C que enviamos a fabricar?
Cómo alargar esta etapa sin cambiar de herramienta
Haz primero lo sencillo.
Incluye dentro de la propia BOM:
Product: Control Unit
Board: Main Control Board
Hardware revision: C
BOM revision: 3
Release date: 2026-09-14
Status: RELEASEDNo dependas sólo del nombre del archivo.
Y establece una convención estable:
Main_Control_Board_RevA_BOM.xlsx
Main_Control_Board_RevB_BOM.xlsx
Main_Control_Board_RevC_BOM.xlsxCuando una versión se libera, consérvala en un lugar donde no siga editándose accidentalmente.
Con una disciplina razonable, este modelo puede funcionar durante mucho tiempo.
Etapa 3 — Aparece una segunda tarjeta
Ahora tienes:
Main Control Board
Power Boardy ambas utilizan el mismo condensador:
GRM188R71C104KA01DEn una hoja aparece como una fila.
En la otra aparece como otra fila.
Visualmente representan la misma pieza. Desde el punto de vista de los archivos, sin embargo, son dos registros independientes.
Si cambias una BOM, la otra no sabe que ha ocurrido nada.
Ahí aparece uno de los límites importantes del modelo basado exclusivamente en ficheros.
El problema no es que Excel “no pueda” tener componentes
Puedes crear una hoja maestra:
Component_ID | Manufacturer | MPN | Description
CAP-000142 | Murata | GRM188R71C104KA01D | 100nF 16V X7R 0603y hacer que varias BOM busquen datos mediante:
- XLOOKUP;
- INDEX/MATCH;
- Power Query;
- macros;
- scripts;
- conexiones externas.
Eso puede funcionar muy bien.
Pero en ese momento ya has empezado a construir un pequeño sistema de datos encima de la hoja de cálculo.
El problema estructural no es que una hoja sea incapaz de representar una relación.
Es que una fila de una BOM no tiene por sí misma identidad compartida con la misma pieza utilizada en otra BOM.
Esa identidad hay que construirla y mantenerla mediante convenciones adicionales.
Etapa 4 — Más de una persona trabaja sobre los datos
Con varios ingenieros aparece otro problema: coordinación.
En archivos locales es habitual terminar con algo así:
MainBoard_BOM_Carlos.xlsx
MainBoard_BOM_Patricia.xlsx
MainBoard_BOM_FINAL.xlsxDos copias pueden divergir y la reconciliación termina siendo manual.
La nube resuelve buena parte de este problema
Google Sheets, Excel Online y otras herramientas colaborativas han mejorado mucho esta etapa.
Pueden proporcionar:
- edición simultánea;
- historial;
- comentarios;
- identificación de autores;
- recuperación de cambios.
Para muchos equipos pequeños esto es suficiente durante años.
Por eso sería incorrecto decir que las hojas de cálculo no permiten colaboración segura.
Lo que la colaboración en la nube no resuelve por sí sola es otro problema distinto:
¿Qué relación tiene este componente con todas las BOM en las que aparece?
Ese es un problema de modelo de información, no de bloqueo del fichero.
Etapa 5 — Aparecen preguntas que atraviesan varias tarjetas
Un día alguien pregunta:
¿En qué productos utilizamos el TPS62130RGTR?
Con tres BOM, la respuesta puede ser una búsqueda manual.
Con diez, sigue siendo posible.
Con decenas de tarjetas, revisiones antiguas y productos distintos, empieza a resultar incómodo.
La consecuencia importante no es simplemente perder veinte minutos.
Es que algunas preguntas dejan de hacerse con la frecuencia adecuada.
Por ejemplo:
Este componente tiene un PCN. ¿Dónde lo usamos?
o:
Queremos sustituir este regulador. ¿Qué diseños quedarían afectados?
o:
¿Hay alguna otra tarjeta utilizando este mismo conector?
Cuando una pregunta depende de recorrer una colección de archivos y confiar en que todos utilizan exactamente la misma escritura del MPN, el coste de consulta crece rápidamente.
Los límites estructurales de una BOM basada sólo en hojas
No son muchos.
1. Identidad de componente
En una BOM tradicional:
STM32G474RET6es texto dentro de una celda.
En otra BOM puede aparecer:
STM32G474RET6y conceptualmente es el mismo componente.
Pero esa igualdad depende de que ambos valores coincidan exactamente o de que exista alguna capa adicional que los relacione.
Un sistema basado en entidades puede representar algo distinto:
Component #1842
└── Manufacturer: STMicroelectronics
└── MPN: STM32G474RET6
└── Used in:
├── Main Control Board Rev C
├── Interface Board Rev B
└── Test Controller Rev ALa diferencia parece pequeña, pero cambia las consultas que puedes hacer.
2. Relaciones entre objetos
Una hoja puede representar:
Board -> Componentmediante una tabla.
Lo que normalmente no proporciona de forma nativa es un modelo navegable donde puedas recorrer fácilmente las relaciones en ambos sentidos:
Board → uses → Component
Component → used by → BoardsSe puede construir.
Pero cuanto más se construye, menos estás utilizando una hoja como una simple hoja.
3. Versionado del contenido interno
Los sistemas de archivos, SharePoint, Drive o Excel pueden conservar versiones del fichero.
Eso responde a:
¿Cómo era este XLSX ayer?
No necesariamente responde de manera clara a:
¿Qué tres líneas cambiaron entre la BOM de Rev B y la de Rev C?
Puedes resolverlo mediante:
- comparación de archivos;
- scripts;
- Power Query;
- macros;
- Git en formatos apropiados;
- herramientas específicas.
Pero no es una propiedad inherente de una BOM en XLSX.
4. Contexto de configuración
Una BOM puede llamarse:
MainBoard_RevC.xlsxpero el archivo no sabe necesariamente:
- qué esquemático le corresponde;
- qué paquete de fabricación se liberó con ella;
- qué revisión de hardware describe;
- qué documentos pertenecen a esa misma configuración.
Eso puede mantenerse mediante estructura de carpetas y disciplina.
El problema aparece cuando hay suficientes relaciones como para que mantenerlas manualmente empiece a fallar.
Señales de que el modelo empieza a quedarse pequeño
No existe un número universal de tarjetas a partir del cual una hoja deje de funcionar.
Dos diseños muy complejos pueden justificar una herramienta estructurada antes que veinte diseños sencillos.
Es más útil observar comportamientos.
Algunas señales claras son:
- necesitas buscar el mismo componente en múltiples BOM con frecuencia;
- una sustitución debe aplicarse a varios productos y no sabes inmediatamente cuáles;
- distintas personas han utilizado versiones diferentes de una BOM creyendo que eran la vigente;
- tienes una lista maestra de componentes que empieza a requerir macros o automatización para mantenerse;
- resulta difícil determinar qué BOM fue realmente liberada para una revisión;
- los cambios de una tarjeta requieren actualizar información duplicada en otras;
- responder a “¿dónde usamos esta pieza?” exige abrir múltiples archivos;
- empiezas a mantener manualmente relaciones entre productos, tarjetas, revisiones y BOM.
Una señal especialmente importante es ésta:
No puedes identificar con seguridad qué lista de materiales corresponde al hardware que estás fabricando actualmente.
Eso ya no es sólo una cuestión de productividad.
Es un problema de control de configuración.
Antes de migrar, mejora primero las hojas
Cambiar de herramienta tiene coste.
Antes de hacerlo, hay varias mejoras baratas que resuelven gran parte de los problemas iniciales.
1. Identifica la revisión dentro de la BOM
No dependas exclusivamente del nombre del fichero.
Incluye:
- producto;
- tarjeta;
- revisión hardware;
- revisión de BOM;
- estado;
- fecha de liberación.
2. Separa datos con propósitos diferentes
Una BOM de ingeniería no necesita convertirse también en:
- histórico de precios;
- previsión de compras;
- registro de stock;
- listado de pedidos;
- informe de obsolescencia;
- notas de producción.
Se pueden relacionar esos datos sin convertir una sola hoja en la base de datos de toda la empresa.
3. Conserva las releases
Las BOM liberadas deben poder recuperarse después.
Puedes hacerlo mediante:
- permisos;
- snapshots;
- carpetas de release;
- SharePoint;
- Drive;
- un repositorio;
- otro sistema documental.
Lo importante es evitar que una liberación histórica siga mutando.
4. Normaliza la identificación de componentes
Mantén al menos:
Manufacturer
Manufacturer Part Number
Internal Part Number, si existe
DescriptionEvita utilizar únicamente descripciones como:
CAP 100nF 0603si necesitas distinguir componentes aprobados concretos.
5. Define cuál es la fuente de cada dato
Por ejemplo:
MPN aprobado → component master
Cantidad por tarjeta → BOM
Precio actual → purchasing
Stock → ERPEsto evita que cuatro hojas intenten mantener versiones distintas del mismo hecho.
Si migras, no necesitas migrarlo todo a la vez
Cuando un equipo decide adoptar una herramienta más estructurada, es fácil plantear una migración gigantesca:
Vamos a meter todos los productos, todas las BOM, todos los documentos y quince años de histórico.
Suele ser más práctico empezar por el problema que más se repite.
Muchas veces son los componentes.
En lugar de que cada BOM contenga una copia independiente de:
Manufacturer: Texas Instruments
MPN: TPS62130RGTRpuedes tener un registro de componente común al que se relacionan las diferentes tarjetas.
Entonces una pregunta como:
¿Dónde utilizamos este componente?
deja de depender de buscar texto en varios archivos.
A partir de ahí puedes decidir si merece la pena estructurar también:
- BOM;
- revisiones;
- documentación;
- releases;
- cambios.
No es necesario hacer todo el cambio el primer día.
Hay cosas que deberían seguir en una hoja de cálculo
Pasar a datos estructurados no convierte las hojas en obsoletas.
Siguen siendo excelentes para:
- estimaciones rápidas de coste;
- comparativas de proveedores;
- análisis puntuales;
- cálculos;
- importaciones y exportaciones;
- manipulación rápida de datos;
- preparación de información ad hoc.
Intentar convertir cada cálculo temporal en una entidad permanente de un sistema puede empeorar el trabajo.
La cuestión no es sustituir la hoja de cálculo.
Es decidir qué información necesita identidad, relaciones y control de configuración, y qué información sigue siendo simplemente una tabla.
Una regla práctica
Puedes seguir trabajando perfectamente con hojas mientras puedas responder con confianza:
- ¿Cuál es la BOM vigente de esta revisión?
- ¿Dónde más utilizamos este componente?
- ¿Qué cambió entre estas dos revisiones?
- ¿Qué paquete de fabricación corresponde a esta BOM?
- ¿Quién puede modificar la información liberada?
Si las respuestas son rápidas y fiables, quizá no necesitas nada más.
Si empiezan a requerir varias búsquedas, comparaciones manuales y conocimiento tribal, no significa que Excel haya dejado de ser una buena herramienta.
Significa que el problema ha dejado de ser únicamente una tabla.
XKEMA está pensado para ese punto: representar componentes, tarjetas y documentación como información relacionada y mantener el contexto de versiones y baselines de los elementos compatibles, en lugar de depender exclusivamente de archivos aislados y convenciones de nombres.
Eso no convierte a XKEMA en un ERP ni pretende sustituir una hoja de cálculo para análisis ad hoc. La ventaja aparece cuando necesitas conservar relaciones de ingeniería que una colección de ficheros obliga a mantener manualmente.