El problema no es tu ERP: es el choque entre un producto “variable” y un sistema que quiere “fijo”
Cuando una empresa me dice “nuestro ERP no sirve”, suelo responder con una frase que incomoda:
tu ERP no está “mal”; está intentando entender un producto que cambia de forma más rápido de lo que tus datos pueden describir.
En operaciones por proyecto (y especialmente cuando cada diseño trae medidas, herrajes, acabados y combinaciones distintas), aparece un enemigo silencioso:
-
- el producto real vive en configuraciones
-
- pero el producto administrativo vive en artículos y listas de materiales estáticas.
Ese hueco es caro. Y no se paga una vez: se paga cada día.
## Qué es una “lista de materiales variable” y por qué te explota en las manos
Una lista de materiales (BOM) clásica responde a una idea sencilla:
“Para fabricar X, necesito A, B y C, siempre.”
Pero en un negocio por proyecto, lo que ocurre es esto:
“Para fabricar X, necesito A, B y C… según medida, según acabado, según tirador, según bisagra, según electrodoméstico, según instalación, según proveedor disponible.”
Es decir: tu BOM no es una lista. Es un conjunto de reglas.
Y cuando intentas representar reglas complejas con listas fijas, pasan dos cosas:
- o creas miles de variantes (y el dato se vuelve inmanejable)
o lo dejas “manual” (y la operación se vuelve impredecible).
## La señal que lo delata: el producto “se decide” fuera del sistema
Yo sé que hay un problema de BOM variable cuando escucho frases como:
-
- “Esto lo ajusta siempre el técnico.”
-
- “Esto lo revisa producción antes de lanzar.”
-
- “Esto lo confirma compras cuando llega el proveedor.”
-
- “Esto lo decide instalación en obra.”
Traducido: la verdad del producto no está en el sistema.
Y si la verdad no está en el sistema, todo lo que dependa de esa verdad (coste, plazos, compras, stock, kits, calidad) se vuelve frágil.
## Por qué duele tanto: 5 daños típicos que no se ven en una pantalla
El impacto no es “técnico”. Es de margen, reputación y estrés.
### 1) Costes teóricos que no predicen nada
Si el ERP no “entiende” la variabilidad, el escandallo se convierte en decoración.
Resultado:
- presupuestos que parecen rentables
- proyectos que se cierran perdiendo dinero
y discusiones internas de “esto siempre pasa”.
### 2) Compras reactivas (y urgencias disfrazadas de normalidad)
Sin BOM confiable, compras vive en modo apagafuegos:
- faltan herrajes específicos
- cambian acabados a última hora
- llegan piezas incompatibles
se compra “por si acaso”.
Pagas con plazos, portes, y una caja que se evapora sin explicación.
### 3) Producción sin estabilidad
Cuando el “qué” cambia, el “cómo” también:
- se rompe el flujo
- se multiplican micro-paradas
- aumenta el retrabajo por ajustes no previstos
y el plan se reescribe cada mañana.
### 4) Kits incompletos (el coste invisible de la incompletitud)
La incompletitud es letal en proyecto: un kit que sale “casi” completo no sale completo. Y eso dispara:
- expediciones parciales
- visitas extra
- huecos en agenda
y promesas que se deshilachan.
### 5) Cambio sin control (la raíz de la repetición)
Cuando el producto se define fuera del sistema, el cambio no se gobierna: se negocia.
Entonces los cambios aparecen como:
- llamadas
- mensajes
- “solo es un detalle”
y urgencias que no quedan registradas como coste.
Ahí nace el margen que desaparece.
## El error más común: intentar “arreglarlo” creando más artículos
Cuando una empresa sufre con BOM variable, suele intentar dos soluciones rápidas:
- crear artículos para todo
o duplicar listas de materiales por cada variación.
Eso funciona… hasta que deja de funcionar.
¿Por qué?
Porque no estás capturando reglas; estás inflando catálogo.
El resultado típico es una de estas dos escenas:
- catálogo inmenso que nadie confía
o catálogo incompleto que obliga a manualidad.
En ambos casos, el problema no desaparece: se mueve.
## Cómo diagnostico el nivel de “variabilidad peligrosa” sin entrar en implementación
Yo no empiezo preguntando por software. Empiezo por señales.
Aquí tienes mi checklist de diagnóstico (no para resolver, sino para detectar):
A) Señales en ventas y presupuesto
¿Cuántas veces se recalcula un presupuesto antes de cerrar?
¿Cuántas líneas “manuales” hay en el presupuesto (ajustes, extras, “materiales varios”)?
¿Cuántos proyectos requieren “validación técnica” para ser presupuestables?
Si el presupuesto necesita traducción, el sistema ya está roto.
B) Señales en oficina técnica / ingeniería
¿Cuánto del trabajo es “adaptar” en vez de “diseñar”?
¿Cuántas incidencias nacen por una pieza incompatible con otra?
¿Cuántas decisiones de producto dependen de “lo que haya” del proveedor?
Si la compatibilidad es memoria tribal, la variabilidad manda.
C) Señales en compras y stock
¿Cuántas compras urgentes aparecen por semana?
¿Cuánto stock existe para “cubrir incertidumbre”?
¿Cuántas veces un componente llega y “no sirve para este caso”?
Si compras compensa, el ERP no describe el producto real.
D) Señales en producción y logística
¿Cuántas órdenes se paran por falta de un componente “pequeño”?
¿Cuántas expediciones salen parciales?
¿Cuántas rutas de instalación se duplican por segundas visitas?
Si la incompletitud es habitual, la BOM es ficción.
## La métrica que más me gusta: “porcentaje de proyecto explicado por el dato”
Hay una pregunta que uso para cortar discusiones:
¿Qué parte de un proyecto se puede explicar con el dato del sistema sin llamar a nadie?
Si la respuesta es: “poca”, entonces tu operación depende de personas, no de sistema. “mucha”, entonces la tecnología puede escalar sin quemar al equipo.
La industria no escala con esfuerzo. Escala con representación.
## “BOM”, “configuración” y “cambio”: el triángulo que decide si tu margen es defendible
Cuando el producto es variable, estas tres cosas se vuelven inseparables:
-
- Configuración: qué combinación concreta existe para este proyecto.
-
- BOM: qué materiales exactos necesita esa combinación.
-
- Cambio: qué sucede cuando esa combinación se altera después de prometer.
Si uno de los tres vive fuera del sistema, los otros dos se degradan. Y cuando se degradan, aparecen estas frases:
“No sé por qué faltó.” “No sé cuándo cambió.” “No sé quién lo aprobó.” “No sé cuánto costó.”
Ese “no sé” es tu margen perdiéndose.
## Riesgo financiero: el coste que no registras es el coste que repites
Hay un patrón que veo una y otra vez:
- el proyecto se retrasa
- se compra urgente
- se retrabaja
- se hacen visitas extra
y al final… se registra como “gasto general”.
Cuando el coste no se imputa a su causa y a su proyecto, ocurre lo peor:
- no puedes decidir con evidencia
- no puedes corregir
y no puedes defender precio.
La BOM variable mal resuelta convierte el negocio en una ruleta: hay meses buenos y meses malos sin explicación “real”.
## Preguntas que yo haría en una demo de ERP (para detectar humo)
No me interesan los “sí, se puede”. Me interesan las pruebas.
Yo preguntaría:
-
- ¿Cómo representas reglas de compatibilidad sin crear miles de artículos?
-
- ¿Cómo gestionas un “cambio aprobado” para que actualice materiales, compras, coste y promesa?
-
- ¿Cómo aseguras que el dato que usa producción es el mismo que usa compras?
-
- ¿Cómo evitas que la variabilidad termine en Excel?
-
- ¿Cómo calculas coste real por proyecto cuando hay retrabajo y sustituciones?
Si las respuestas son vagas, ya sabes lo que pasará: volverá la manualidad.
## Señales de que estás listo para abordar el problema (y señales de que no)
Estás listo si…
- ya tienes dolor claro (incompletitud, urgencias, desvío de margen)
- tienes voluntad de definir un lenguaje común
y la dirección quiere prometer con evidencia, no con esperanza.
No estás listo si…
- cada área defiende su verdad
- el cambio se negocia sin registro
y nadie quiere tocar el dato porque “si lo tocamos, se cae todo”.
En ese caso, lo primero no es tecnología: es gobernar definiciones y responsabilidades del dato.
## La prueba definitiva: “completitud” como condición, no como deseo
Si tu producto es variable, tu cadena de suministro y tu instalación dependen de una palabra:
completitud.
Yo sé que la BOM está bien representada cuando se puede sostener esto:
- un kit se valida por sistema
- se expide completo
y llega a instalación sin sorpresas.
Cuando esa condición no se puede asegurar, el negocio paga con:
- interrupciones
- reprogramaciones
y un cliente que percibe improvisación aunque el diseño sea excelente.
## Cierre: tu producto no es un SKU, es una promesa con reglas
Si tu operación vive de proyectos, tu producto no es “un mueble”. Es:
- una configuración
- una lista de materiales derivada
- un plan
y una promesa con cambio controlado.
Cuando el ERP no entiende esa realidad, la empresa crece… pero crece sobre fricción.
Si quieres, lo vemos en 15 minutos: identifico dónde se rompe la representación del producto, qué parte es variabilidad legítima y qué parte es desorden, y qué criterios usar para tomar decisiones sin convertir tu operación en un laboratorio.
