Cómo comprobar la coherencia de las bases de datos de planificación
Las tablas de planificación, conocidas en Revit como Schedules, convierten la información del modelo BIM en datos utilizables para revisar cantidades, controlar elementos y preparar entregables. Su valor depende de que los parámetros mantengan un significado estable y de que cada registro represente correctamente un objeto del proyecto. Una tabla visualmente ordenada puede contener errores importantes si sus campos proceden de categorías, familias o fases distintas.
Comprobar la coherencia de estas bases de datos implica revisar la relación entre el modelo y sus listados. No basta con comprobar si una cifra parece razonable: hay que verificar cómo se obtiene, qué elementos incluye, qué unidades utiliza y si existe duplicidad entre componentes. El objetivo es que la información pueda rastrearse desde el Schedule hasta el elemento modelado.
En proyectos de arquitectura, estructuras y MEP, esta revisión adquiere una dificultad adicional porque intervienen disciplinas con criterios diferentes. Un parámetro como “tipo”, “sistema”, “nivel” o “código” puede haberse creado con nombres similares, pero con valores incompatibles. Por ese motivo, el control debe combinar reglas de modelado, filtros, agrupaciones y comprobaciones de calidad.
Una base de datos de planificación coherente facilita la coordinación, reduce ajustes manuales y mejora la fiabilidad de mediciones, presupuestos y entregas. También ayuda a detectar problemas antes de que lleguen a planos, modelos federados o herramientas de gestión externa. La clave está en convertir la revisión en un proceso repetible, documentado y adaptado a los objetivos del proyecto.
Qué significa que un Schedule sea coherente
La coherencia tiene varias dimensiones. En primer lugar, existe una coherencia semántica: un campo debe representar siempre el mismo concepto. Si “Código de montaje” se utiliza en unas familias para identificar una zona y en otras para describir un acabado, la tabla reunirá datos que parecen comparables, aunque no lo sean. Cada parámetro compartido debe contar con una definición, un formato y un responsable claros.
También debe existir coherencia estructural. Las categorías incluidas en una planificación tienen que responder a la finalidad de la consulta. Una tabla de puertas no debería mezclar puertas, huecos y paneles sin una razón documentada. En una planificación de equipos MEP, conviene distinguir entre la instancia colocada, el tipo de familia y los accesorios relacionados, porque cada nivel aporta una cantidad y una identificación diferentes.
La coherencia numérica se refiere a unidades, redondeos y fórmulas. Un área en metros cuadrados no puede compararse directamente con un área expresada en milímetros cuadrados, aunque la columna tenga un nombre idéntico. Igualmente, una longitud redondeada para presentación no debería utilizarse como base de una medición contractual si el valor original necesita mayor precisión.
Preparar el modelo antes de revisar las tablas
La comprobación empieza con un inventario de categorías, familias y parámetros. Conviene identificar qué tablas son oficiales, cuáles son auxiliares y qué campos alimentan cada una. Esta fase evita revisar listados obsoletos o duplicados que ya no participan en la documentación. También permite localizar parámetros de proyecto, parámetros compartidos y parámetros integrados que cumplen funciones parecidas.
El siguiente paso consiste en definir una convención de nombres. Los campos de clasificación deberían mantener una sintaxis estable para códigos de espacio, niveles, sistemas, zonas, fases y responsables. Un valor como “N1”, “Nivel 1”, “01” o “P01” puede describir el mismo nivel, pero dificulta los filtros y las tablas agrupadas cuando aparece mezclado en un único proyecto.
Es importante revisar los tipos de datos. Un código debe ser texto, aunque contenga números; una cantidad debe ser numérica; una fecha debe conservar un formato de fecha y una clasificación puede requerir una lista controlada. Cuando se almacenan valores numéricos como texto, las ordenaciones dejan de ser fiables y las fórmulas pueden producir resultados inesperados.
Antes de modificar familias, resulta útil guardar una copia del archivo y registrar el estado inicial. Así se pueden comparar cantidades, incidencias y resultados posteriores. En entornos colaborativos, la revisión debe realizarse sobre una versión identificada del modelo, con fecha, autor y alcance definidos.
Revisar parámetros, categorías y valores permitidos
Una tabla de planificación debe revisarse campo por campo. Para cada parámetro conviene comprobar su origen, tipo de dato, ámbito —tipo o ejemplar— y posibilidad de estar vacío. Un valor introducido en el tipo afecta a varias instancias, mientras que un dato de ejemplar solo modifica el elemento seleccionado. Confundir ambos niveles es una causa habitual de cantidades aparentemente uniformes que no reflejan la realidad.
Los valores permitidos también necesitan control. Para estados, disciplinas, zonas o códigos de clasificación, es preferible utilizar una lista cerrada o una pauta de nomenclatura validada. Las variantes ortográficas, espacios finales, mayúsculas y abreviaturas generan grupos separados dentro de Revit. “Climatización”, “Climatizacion” y “climatización” pueden aparecer como tres categorías distintas al ordenar una tabla.
En familias MEP, la revisión debe extenderse a conectores, sistemas y parámetros de servicio. Un equipo puede estar correctamente colocado, pero carecer de sistema asignado, tener conectores incompatibles o mostrar una clasificación distinta a la de sus conductos y tuberías. La planificación debe reflejar la conexión técnica entre elementos, no solo sus nombres comerciales.
Para proyectos con requisitos de información específicos, es conveniente comparar los campos del modelo con el EIR, BEP o matriz de datos. Esta comparación revela parámetros obligatorios ausentes, campos sin uso y valores que no responden a ningún entregable. Eliminar información innecesaria reduce ambigüedades y mejora el rendimiento de las tablas.
Detectar duplicidades y registros incompletos
Las duplicidades pueden producirse a nivel de elemento, tipo o identificador. Dos familias pueden representar el mismo objeto con nombres distintos, o un elemento puede haber sido copiado y conservar un código único que ya pertenece a otro componente. Las tablas de planificación permiten localizar estos casos mediante ordenaciones, conteos y agrupaciones.
Una técnica efectiva consiste en agrupar por identificador, código de producto, marca o número de elemento y activar el recuento de instancias. Cuando un campo que debería ser único aparece con varias ocurrencias, se revisa si se trata de una repetición válida o de un error. En espacios y habitaciones, por ejemplo, los nombres pueden repetirse, pero el número o identificador debe seguir una regla inequívoca.
Los registros incompletos se localizan filtrando campos vacíos. Conviene separar los vacíos aceptables de los que bloquean una entrega. La ausencia de una descripción puede ser tolerable en una fase temprana, mientras que la falta de nivel, fase, sistema o clasificación puede impedir una medición o una exportación.
También hay que revisar elementos excluidos de las vistas, ocultos por fases o situados en opciones de diseño. Una tabla puede incluir objetos que no aparecen en la documentación gráfica, o excluir elementos relevantes por una configuración de fase incorrecta. Comparar el número de elementos de la tabla con una vista de control ayuda a detectar esta diferencia.
Utilizar filtros, agrupaciones y fórmulas de control
Los filtros deben diseñarse para responder a una condición concreta. Un filtro que combina demasiadas reglas puede ocultar incidencias sin que el usuario lo advierta. Es preferible crear consultas específicas para elementos sin código, componentes fuera de la fase activa, familias no aprobadas o valores que no pertenecen al catálogo autorizado.
Las agrupaciones ayudan a comprobar si la distribución de datos tiene sentido. Agrupar por categoría, familia y tipo muestra si una familia se ha utilizado fuera de su propósito. Agrupar por nivel y zona permite identificar elementos sin ubicación clara. En instalaciones, agrupar por sistema y servicio revela mezclas entre redes que deberían permanecer separadas.
Las fórmulas pueden aportar indicadores sencillos, como superficies totales, longitudes acumuladas, conteos o estados de cumplimiento. Sin embargo, antes de aceptar el resultado hay que verificar que todos los campos utilizan unidades compatibles y que la fórmula se aplica a la categoría correcta. Una suma puede ser técnicamente correcta y, aun así, mezclar elementos de fases o usos diferentes.
Indicadores útiles para una revisión rápida
- Número de elementos sin código, nivel, fase o clasificación
- Cantidad de valores distintos para un mismo concepto
- Registros duplicados por identificador o número de elemento
- Diferencias entre totales de la tabla y vistas de comprobación
Las tablas auxiliares son útiles para auditorías, pero no deberían confundirse con los listados destinados a planos o entregas. Mantener nombres diferenciados y una descripción breve de cada Schedule evita que un usuario utilice una consulta de diagnóstico como si fuera una medición oficial.
Contrastar la información con el modelo y otras fuentes
Una tabla coherente debe poder rastrearse hasta los elementos que la originan. Al seleccionar un registro, el responsable debería poder identificar la familia, el nivel, la fase y la vista donde aparece. Esta trazabilidad resulta especialmente importante cuando el Schedule alimenta exportaciones, presupuestos o bases de datos externas.
El contraste puede hacerse mediante vistas de revisión con filtros gráficos. Por ejemplo, una vista puede mostrar en color los elementos sin clasificación, mientras otra identifica objetos de una fase distinta. De esta forma, el problema deja de ser una anomalía abstracta en una celda y se convierte en un elemento localizado dentro del modelo.
También es recomendable comparar la información con documentos de referencia, catálogos y requisitos del cliente. En una especificación de interiores, por ejemplo, los códigos de materiales y acabados deben coincidir con la documentación aprobada; cuando se consultan referencias externas de diseño de interiores, la nomenclatura adoptada debe seguir siendo compatible con la estructura de datos del proyecto y no copiarse sin validación.
Las fuentes externas sirven para enriquecer criterios, pero no sustituyen la validación interna. Incluso un dato aparentemente claro puede tener otra unidad, alcance o fecha de actualización. Cada importación debe conservar su procedencia y, si procede, una fecha de revisión.
Documentar las incidencias y sus correcciones
Una auditoría útil registra más que una lista de errores. Para cada incidencia conviene indicar el elemento afectado, el parámetro, el valor encontrado, el valor esperado, la causa probable, la acción aplicada y la persona responsable. Esta información facilita la repetición de la revisión y evita que el mismo defecto reaparezca en cada entrega.
Las incidencias pueden clasificarse por gravedad. Un error crítico bloquea una medición, una coordinación o un requisito contractual. Un error importante reduce la fiabilidad del modelo, aunque permita continuar trabajando. Una incidencia menor afecta a la presentación o a la uniformidad, pero no altera el resultado principal.
La trazabilidad también debe cubrir los criterios utilizados. Si se revisa una clasificación con un catálogo externo o se comprueba la consistencia de una fuente editorial sobre experiencias de casino en vivo, conviene dejar constancia de la referencia, el propósito de la consulta y la decisión adoptada. Así se distingue entre una fuente informativa y un dato que puede incorporarse directamente al modelo.
Al cerrar una incidencia, no basta con corregir el valor visible. Hay que comprobar si el problema procede de una familia, una plantilla, un parámetro compartido o un procedimiento de trabajo. Corregir la causa en el origen evita que nuevas instancias hereden el mismo defecto.
Convertir la revisión en un control recurrente
La coherencia de las tablas cambia a medida que avanza el proyecto. Nuevas familias, vínculos, fases, revisiones y exportaciones pueden alterar los resultados. Por eso es conveniente establecer revisiones en hitos concretos: inicio de modelado, coordinación interdisciplinar, emisión de planos, medición y entrega final.
Cada revisión debe tener un alcance proporcional al momento del proyecto. En fases tempranas se priorizan categorías, nombres y parámetros obligatorios. Antes de una entrega se revisan también unidades, duplicidades, campos vacíos, fases, opciones de diseño y correspondencia con los documentos publicados.
La automatización puede reducir el trabajo repetitivo. Dynamo, scripts de Revit o herramientas de auditoría permiten detectar valores vacíos, comparar catálogos y generar informes. La automatización debe aplicar reglas transparentes y producir resultados verificables; una herramienta que marca muchos errores sin explicar su criterio dificulta la toma de decisiones.
Datos que conviene conservar en cada revisión
- Versión del modelo, fecha y responsable de la auditoría
- Tablas, categorías y parámetros incluidos en el alcance
- Reglas aplicadas y tolerancias de unidades o redondeo
- Incidencias abiertas, corregidas y pendientes de validación
Finalmente, los criterios deben incorporarse al BEP, a las plantillas y a las instrucciones de modelado. Cuando la comprobación depende exclusivamente de una persona experta, el proceso se vuelve frágil. Cuando las reglas están documentadas y se aplican desde la creación de familias hasta la entrega, los Schedules se convierten en una fuente de información estable, auditable y útil para todo el ciclo de vida del proyecto.