- Una pieza entra al catálogo cuando deja de depender de la memoria de quien la creó: una ficha única con código, nombre, descripción, referencia maestra, versión, variantes, estado y responsable.
- El código es breve, único y estable, y no se reutiliza nunca. Tampoco intenta codificar cada atributo: los detalles variables viven en sus campos.
- Una versión sustituye; una variante convive. Las variantes van en lista cerrada, con las combinaciones excluidas escritas, para que el silencio no se lea como autorización.
- El estado —disponible, bajo pedido, pausado o retirado— debe ser un valor inequívoco con motivo y fecha. Y estar registrado no significa estar aprobado para vender.
Qué convierte una pieza en una entrada de catálogo
Una pieza se convierte en entrada de catálogo cuando deja de depender de la memoria de quien la creó. Otra persona debe poder identificarla, distinguirla de productos similares y encontrar su definición vigente sin adivinar. Para lograrlo, cada entrada necesita una ficha única vinculada a una referencia maestra. Esa ficha es el punto de acceso; los archivos y notas asociados son evidencias ordenadas alrededor de ella, no fichas alternativas.
Empieza con pocos campos obligatorios y aplícalos siempre. Si un dato no ayuda a identificar, diferenciar o mantener el producto, puede esperar. El registro mínimo funciona en una hoja de cálculo, una base sencilla o un documento estructurado; el medio importa menos que la constancia.
| Campo | Qué registra | Regla práctica |
|---|---|---|
| Código | Identidad única y estable | No se reutiliza |
| Nombre | Forma humana de reconocerlo | Describe, no decora |
| Descripción | Qué es y para qué sirve | Dos frases bastan |
| Referencia maestra | Definición que gobierna la ficha | Solo una vigente |
| Versión | Revisión actual de esa definición | Con fecha y cambios |
| Variantes | Opciones que pueden coexistir | Lista cerrada |
| Estado | Disponibilidad operativa | Un valor inequívoco |
| Responsable | Quién mantiene la entrada | Persona o función |
La descripción debe permitir reconocer el objeto sin convertirse en una promesa. “Soporte mural para dos mandos, versión de esquinas redondeadas” es más útil que “soporte moderno”. Añade dimensiones generales o compatibilidad solo si diferencian la referencia. La ficha organiza un producto que ya pasó por las decisiones previas correspondientes; no las reemplaza ni prueba por sí sola su aptitud.
Límite de la ficha
Estar registrado significa que el producto puede identificarse y mantenerse. No significa que esté aprobado para vender, fabricar o publicar.
Código interno y nombre que el equipo pueda reconocer
El código evita que dos productos terminen tratados como uno. Debe ser breve, único, estable y fácil de copiar. Una estructura como ORG-SOP-014 puede combinar familia, tipo y número consecutivo. No intentes codificar cada atributo: si el código contiene tamaño, material, color, año, categoría y versión, cualquier cambio lo vuelve falso. Los detalles variables pertenecen a sus campos.
Define una regla y escríbela en la primera fila del registro. Usa siempre los mismos separadores, longitud y mayúsculas. Reserva números de forma secuencial y nunca asignes el código de un producto retirado a otro nuevo. Los huecos no dañan el catálogo; una identidad reciclada sí, porque hace que notas y archivos antiguos apunten a una definición distinta.
El nombre cumple otra función: ayuda a las personas a reconocer la entrada. Combina el objeto con el rasgo que lo distingue, por ejemplo “Maceta geométrica alta” o “Organizador de cables de cinco vías”. Evita nombres internos como “pieza final”, “nuevo soporte” o “modelo bueno”. También evita llenar el título con todos los atributos posibles. El código resuelve la precisión; el nombre aporta lectura.
Cuando dos entradas tienen nombres casi idénticos, no añadas “2” por reflejo. Compáralas primero: quizá son versiones del mismo producto, variantes que deberían compartir referencia o un duplicado. Si realmente son productos distintos, incorpora al nombre el rasgo estable que los separa. Esa decisión temprana reduce búsquedas ambiguas y evita crear familias incoherentes.
Versión vigente y registro de cambios
La referencia maestra es la definición autorizada del producto dentro del catálogo. Puede apuntar a una carpeta gestionada o a un conjunto identificado de archivos, pero siempre debe existir un único lugar que responda: “esta es la definición vigente”. Las copias de consulta no deben competir con ella. La ficha enlaza esa referencia, anota su revisión y señala dónde están sus antecedentes.
Usa un sistema de versiones que todo el equipo entienda. La forma más sencilla es v1, v2, v3. Si necesitas distinguir cambios menores, emplea v2.1, pero define antes qué hace avanzar cada número. No llames “final”, “final ahora sí” o “último” a los archivos: esos nombres pierden significado en cuanto aparece otra revisión.
Cada nueva versión necesita una línea de cambios con fecha, responsable, motivo y efecto. “v3 — 2026-07-18 — se amplió la abertura lateral para corregir interferencia; sustituye v2” permite comprender qué ocurrió. “Se mejoró el archivo” no permite decidir nada. Mantén la versión anterior como histórica, marcada claramente como sustituida, y evita que aparezca junto a la vigente sin contexto.
No todo cambio crea un producto nuevo. Si corriges una medida o ajustas una característica manteniendo la identidad y el propósito, normalmente creas una versión. Si el resultado cumple otra función o debe conservarse de manera independiente, puede merecer código y ficha propios. Escribe la decisión en el historial: el catálogo será más consistente cuando el criterio quede visible y pueda repetirse.
La referencia maestra también debe registrar dependencias esenciales: piezas que forman un conjunto, componentes opcionales o archivos que deben mantenerse juntos. No copies esas relaciones en notas sueltas. Si cambia una parte compartida, actualiza las fichas afectadas o deja constancia de que la revisión no modifica su compatibilidad.
Variantes permitidas y combinaciones excluidas
Una variante es una opción válida que convive con otras bajo la misma referencia: tamaño pequeño y grande, orientación izquierda y derecha, o dos configuraciones estructurales previstas. No es una improvisación ni una versión antigua. El catálogo debe mostrar una lista cerrada de variantes permitidas para que “se puede hacer” no termine significando una combinación nunca definida.
Separa los ejes de variación. Por ejemplo, tamaño: S, M y L; configuración: pared o mesa. Después registra qué cruces existen. Una matriz sencilla revela rápidamente que S-pared y M-pared están permitidas, mientras L-mesa queda excluida. No dejes una celda vacía: usa “permitida”, “excluida” o “pendiente de definición”. Así nadie interpreta el silencio como autorización.
| Variante | Código derivado | Relación con la maestra | Estado |
|---|---|---|---|
| Pequeña · pared | ORG-SOP-014-S-P | Permitida | Disponible |
| Mediana · pared | ORG-SOP-014-M-P | Permitida | Bajo pedido |
| Grande · mesa | — | Excluida | No aplica |
Asigna un sufijo cuando la variante deba seleccionarse y rastrearse sin abrir la ficha. Conserva el código base para que su parentesco sea visible. Si una opción modifica tanto la función que requiere su propio ciclo de cambios, sepárala como producto. La prueba útil es preguntar si ambas opciones pueden seguir vigentes al mismo tiempo: si sí, suelen ser variantes; si una reemplaza a la otra, suelen ser versiones.
Documenta también por qué se excluye una combinación cuando no sea evidente. Una frase breve evita que reaparezca meses después como propuesta nueva. Si una combinación todavía no está definida, no la presentes como variante: mantenla fuera del catálogo activo hasta resolverla por el proceso correspondiente.
Es una versión
- Sustituye una definición anterior del mismo producto
- Nace de corregir una medida o ajustar una característica manteniendo identidad y propósito
- Conserva el código y avanza la revisión: v1, v2, v3
- Necesita línea de cambios con fecha, responsable, motivo y efecto
- No convive con la anterior: la anterior queda marcada como sustituida
Es una variante
- Convive con otras opciones válidas bajo la misma referencia maestra
- Va en una lista cerrada, con las combinaciones excluidas declaradas
- Puede llevar sufijo sobre el código base cuando deba seleccionarse sin abrir la ficha
- Cada opción lleva su propio estado: una disponible y otra pausada es normal
- No es una improvisación ni una versión antigua que sigue circulando
Veredicto: pregunta si las dos opciones pueden seguir vigentes al mismo tiempo. Si pueden, son variantes y comparten referencia maestra. Si una deja fuera a la otra, es una versión y solo una queda vigente. Y si la opción exige su propio ciclo de cambios, ya no es ninguna de las dos: es un producto con código y ficha propios.
Disponible, bajo pedido, pausado o retirado
El estado indica qué puede hacerse con una entrada en este momento. Usa pocos valores y define exactamente qué significa cada uno. Disponible señala que la referencia vigente puede seleccionarse de forma habitual. Bajo pedido indica que existe y está activa, pero requiere una decisión previa antes de iniciar. Ninguno de los dos estados sustituye las comprobaciones que correspondan fuera del catálogo.
Pausado significa que la entrada se conserva, aunque temporalmente no debe seleccionarse. Añade motivo, fecha y condición de reapertura: “pausado hasta actualizar la referencia maestra” resulta accionable; “no disponible por ahora” no. Una pausa sin responsable ni siguiente revisión tiende a convertirse en abandono invisible.
Retirado es un estado permanente. La ficha sigue existiendo para conservar la historia, pero queda fuera de las opciones activas. Registra la fecha, el motivo y, si corresponde, el código del producto que lo reemplaza. No cambies automáticamente las referencias antiguas: enlazar un sucesor informa; reescribir el pasado confunde.
Evita mezclar estado con existencia, versión o variante. Un producto puede estar disponible y tener dos variantes, una disponible y otra pausada. También puede mantener una versión histórica aunque solo la última esté vigente. Si cada concepto ocupa su propia columna, los filtros responden preguntas reales y no obligan a interpretar frases libres.
Cómo detectar duplicados y retirar versiones antiguas
Los duplicados aparecen cuando alguien no encuentra una entrada y crea otra, o cuando una variante se registra como producto independiente. Revisa periódicamente código, nombre, descripción, propósito, dimensiones generales y referencia maestra. Dos nombres distintos que apuntan al mismo conjunto de archivos son una señal clara; dos códigos con descripciones casi iguales merecen comparación.
Antes de unir fichas, confirma si se trata de duplicados reales. Podrían ser variantes válidas o productos parecidos con funciones distintas. Elige como ficha principal la que tenga el código más antiguo, el historial más completo o la referencia maestra correcta. Marca la otra como duplicada, enlázala a la principal y migra solo los datos que no contradigan la definición vigente.
No borres inmediatamente la ficha duplicada. Conservar un alias histórico evita que una búsqueda por el nombre antiguo termine sin resultado. Añade “duplicada de ORG-SOP-014” y retírala de las vistas activas. Tampoco fusiones códigos en silencio: registra fecha, responsable y motivo para que cualquier referencia anterior pueda interpretarse.
Para retirar versiones antiguas, mueve su estado documental a “sustituida” y conserva una ruta de solo lectura. La ficha debe mostrar una sola versión vigente en primer plano y un historial separado. Si hay copias locales, nómbralas con el código y la versión, no con adjetivos. La regla es simple: cualquiera que llegue a la ficha debe identificar en pocos segundos qué definición usar y cuáles existen solo como antecedente.
Realiza una revisión breve cuando se añade una entrada, se cambia una versión o se modifica un estado. Busca primero por palabras del nombre, por familia y por rasgos distintivos. Después comprueba que el código no exista, que la referencia maestra sea única y que las variantes no dupliquen productos activos. Este hábito evita una limpieza grande más adelante.
El catálogo forma parte de una ruta más amplia, pero no debe absorberla. Vuelve al hub de negocio de impresión 3D o consulta cómo ganar dinero con impresión 3D para ubicar esta tarea. La preparación visual corresponde a cómo fotografiar piezas 3D para vender; la repetición se trata en producción por lotes y control de calidad; y la protección posterior, en cómo empacar y enviar piezas 3D. Antes de incorporar un diseño ajeno, revisa la guía canónica de modelos y licencias. Esos procesos aportan sus propias decisiones: una ficha completa no las demuestra.
Preguntas frecuentes
¿Qué datos mínimos debe tener la ficha de un producto 3D?
Como mínimo, un código único, un nombre reconocible, una descripción breve, la referencia maestra, la versión vigente, las variantes permitidas y su estado de disponibilidad. Añade responsable y fecha de revisión para saber quién puede aclarar o actualizar la ficha.
¿Una variante necesita un código diferente?
Sí, cuando debe distinguirse sin abrir la ficha, conservar existencia independiente o evitar confusiones al seleccionarla. Puede usar el código base más un sufijo estable. Si la diferencia solo cambia la versión del mismo producto, conserva el código y actualiza la revisión.
¿Cuál es la diferencia entre versión y variante?
Una versión sustituye una definición anterior del mismo producto; una variante convive con otras opciones válidas. Corregir una medida genera una nueva versión. Mantener el mismo objeto en dos tamaños permitidos genera dos variantes vinculadas a una referencia maestra.
¿Qué ocurre con una ficha cuando se retira el producto?
La ficha no se borra: cambia a retirada, deja de aparecer entre las opciones activas y conserva su código, última versión, variantes y motivo de retirada. Si existe un reemplazo, se enlaza de forma explícita sin reutilizar el código anterior.