Gestione los documentos del proveedor después de la adjudicación: Vendor Data, submittals, VDR, shop drawings, ciclos de revisión, comentarios, aprobación y documentación final.
¡Descúbrelo!
Vendor Data y submittals en Ingeniería son los documentos, datos y registros que proveedores y contratistas deben someter al cliente a lo largo del ciclo de suministro para permitir revisión técnica, continuidad del proyecto, fabricación, instalación, pruebas, operación y cierre documental. El control de estos entregables forma parte del Procurement técnico porque retrasos o fallas documentales pueden bloquear Ingeniería, fabricación, construcción y comisionamiento incluso cuando el equipo físico todavía no está atrasado.
La gestión debe comenzar antes de la adjudicación. La requisición técnica y los documentos de contratación deben definir qué entregables serán exigidos, en qué formato, revisión, plazo y finalidad. Después de la contratación, estos requisitos se transforman en un Vendor Data Register o Submittal Register que permite controlar emisión, revisión, comentarios, reenvío, aprobación e incorporación a la documentación final.
Vendor Data no es sinónimo de documentación técnica en general ni de Document Control. El foco de este proceso es el conjunto de información producida por el proveedor para demostrar, detallar, integrar y registrar el suministro contratado, desde shop drawings y product data hasta procedimientos de prueba, certificados, manuales y documentos de closeout. El control documental corporativo administra revisiones, transmittals y trazabilidad del archivo; la gestión de Vendor Data y submittals gobierna específicamente el ciclo técnico de sometimiento, comentario, reemisión y aceptación de esos entregables del proveedor.
Qué son Vendor Data y submittals
En proyectos industriales y de infraestructura, vendor data es una expresión amplia para los datos y documentos suministrados por fabricantes y proveedores. Submittals es el término utilizado frecuentemente en construcción y contratos para los ítems sometidos formalmente a revisión del contratante o proyectista.
WBDG/SpecsIntact estandariza categorías de submittals como shop drawings, product data, samples, design data, test reports, certificates, manufacturer’s instructions, field reports, O&M data y closeout submittals. Esta clasificación muestra que el control va mucho más allá de planos.
Por qué Vendor Data debe nacer en la contratación
Vendor Data debe contratarse antes de ser necesario. Cuando planos, datasheets e informes críticos solo se negocian después de la adjudicación, el proyecto pierde control sobre los plazos precisamente en la información que alimenta Ingeniería y fabricación.
Si la lista de documentos solo se discute después de la adjudicación, el contratante puede descubrir que determinados planos, modelos, cálculos, certificados o manuales no estaban incluidos en el precio o en el plazo del proveedor.
La definición previa permite:
- valorizar el esfuerzo documental;
- establecer hitos contractuales;
- relacionar documentos con la fabricación;
- prever ciclos de revisión;
- exigir formatos editables o nativos cuando sea necesario;
- definir idioma y codificación;
- estructurar la documentación final desde el inicio;
- evitar negociación tardía de entregables críticos.
En el ciclo de Procurement en proyectos de Ingeniería, la Requisición Técnica en Ingeniería debe, por lo tanto, contener o referenciar la lista inicial de vendor data.
Tipos de Vendor Data
La lista varía según el paquete. Una clasificación práctica puede incluir:
Datos de proyecto e integración
- planos dimensionales;
- cargas estáticas y dinámicas;
- consumo eléctrico;
- heat dissipation;
- puntos de conexión;
- listas de I/O;
- protocolos e interfaces;
- diagramas funcionales;
- requisitos de cimentación y soporte;
- modelos BIM o archivos digitales cuando corresponda.
Datos de producto
- datasheets certificados;
- catálogos;
- curvas de desempeño;
- lista de materiales;
- identificación de componentes;
- información de materiales y acabados.
Calidad y fabricación
- plan de calidad;
- ITP/PIT;
- procedimientos de fabricación;
- certificados de materiales;
- informes de inspección;
- NCR y registros de tratamiento;
- procedimientos e informes de FAT.
Instalación y comisionamiento
- instrucciones de montaje;
- procedimientos de instalación;
- checklists;
- procedimientos de energización;
- requisitos de pruebas de campo;
- SAT o protocolos de comisionamiento.
Operación y cierre
- manuales O&M;
- listas de repuestos;
- documentación de capacitación;
- certificados finales;
- garantías;
- planos As-Built del fabricante;
- archivos de configuración;
- documentación de closeout.
Vendor Data Register: el registro maestro del proveedor
El Vendor Data Register (VDR), Vendor Document Register o Vendor Data Requirements List organiza cada documento esperado y su estado. No existe una nomenclatura universal, pero la función es la misma: transformar obligaciones documentales en ítems trazables.
Los campos útiles incluyen:
| Campo | Finalidad |
| código del documento | identificación única |
| título | contenido esperado |
| tipo/categoría | plano, datasheet, informe, manual, etc. |
| finalidad | aprobación, información, fabricación, operación |
| revisión | versión vigente |
| fecha contractual | plazo de primera emisión |
| fecha forecast | mejor previsión actual |
| estado de revisión | situación técnica |
| responsable del review | disciplina o autoridad |
| fecha de retorno | control del ciclo de revisión |
| requisito de As-Built | define el cierre documental |
El VDR debe integrarse con la Lista Maestra de Documentos del proyecto, sin necesariamente sustituirla.
VDR y MDR no son lo mismo
La MDR — Master Document Register controla el universo documental del proyecto. El VDR es una visión específica de los entregables del proveedor.
| Registro | Alcance |
| MDR | documentos del proyecto como un todo |
| VDR | documentos de un proveedor o paquete |
| Submittal Register | ítems sometidos formalmente a revisión |
| Data Book Index | documentos que compondrán el dossier final |
En proyectos bien estructurados, estos registros se relacionan mediante códigos y metadatos, evitando hojas de cálculo aisladas y duplicidad de control.
Submittal Register y clasificación de sometimientos
No todo documento necesita el mismo tratamiento. El contrato o procedimiento documental debe definir clases de revisión.
Una clasificación posible es:
- Aprobación necesaria: el proveedor no puede avanzar a determinada actividad sin retorno;
- Revisión/comentarios: el documento puede requerir correcciones antes del uso;
- Información: enviado para conocimiento y registro;
- Registro final: entregado para documentación de cierre.
Los códigos exactos varían por organización. Lo importante es que el significado sea explícito y no permita interpretar “aprobado” como transferencia de responsabilidad técnica del proveedor al contratante.
La aprobación no transfiere la responsabilidad del proveedor
Un riesgo recurrente es tratar la aprobación del cliente como aceptación integral del diseño del fabricante. En contratos de Ingeniería, la revisión normalmente verifica compatibilidad con requisitos, interfaces y documentos contractuales; no elimina la responsabilidad del proveedor por dimensionamiento, fabricación o desempeño que permanecen dentro de su alcance.
Este principio debe estar expresamente establecido en el contrato y en el procedimiento de submittals.
Cómo definir plazos de sometimiento
Las fechas de vendor data no deben elegirse solamente en relación con el plazo de entrega del equipo. Algunos documentos son necesarios mucho antes.
Ejemplos:
- cargas y dimensiones pueden alimentar el proyecto civil;
- consumo y protección alimentan el proyecto eléctrico;
- I/O y protocolos alimentan automatización;
- planos de layout influyen en infraestructura;
- procedimientos de FAT deben aprobarse antes de la prueba;
- manuales deben estar disponibles antes de capacitación y operación.
Por eso, el plazo correcto deriva de la fecha en que la información será consumida.
Ciclo de revisión y códigos de estado
El proceso debe registrar cada emisión y retorno. Un flujo típico incluye:
- el proveedor emite la revisión;
- Document Control registra y distribuye;
- las disciplinas técnicas revisan;
- los comentarios se consolidan;
- se emite el estado;
- el proveedor corrige y reenvía cuando es necesario;
- la revisión aceptable se libera para el uso definido;
- la versión final se incorpora al closeout.
El número de ciclos y los plazos de respuesta deben planificarse. Revisiones sucesivas pueden consumir el lead time de fabricación y deben aparecer en el expediting.
Cómo evitar comentarios conflictivos
Vendor data frecuentemente cruza varias disciplinas. Un plano de equipo puede recibir comentarios de civil, eléctrica, automatización, mantenimiento y seguridad.
Sin consolidación, el proveedor recibe orientaciones contradictorias. La gobernanza debe definir una autoridad de coordinación responsable de consolidar comentarios antes del retorno formal.
La Gestión de Interfaces en Proyectos de Ingeniería complementa este control cuando múltiples disciplinas y contratos dependen del mismo dato.
Vendor Data y fabricación
Algunos documentos poseen estado de hold para fabricación. Si el proveedor inicia producción antes de la revisión requerida, puede asumir riesgo de retrabajo; si el contratante demora demasiado en revisar, puede crear un impacto de plazo del lado del cliente.
La relación entre documento y fabricación debe constar en el VDR o en el cronograma del proveedor.
Expediting debe monitorear especialmente estos documentos, porque son predecesores materiales de hitos físicos.
Vendor Data y TBE
Parte de la gestión documental comienza todavía en la propuesta. La TBE puede verificar si el proveedor acepta requisitos de documentación, formatos, plazos, listas de entregables y responsabilidades.
Una propuesta técnicamente buena, pero que excluye vendor data crítico u ofrece solamente documentación genérica de catálogo, puede generar costo y retraso posteriores.
Shop drawings
Shop drawings detallan cómo una parte del suministro será fabricada, montada o integrada. WBDG los diferencia de los planos contractuales y los trata como submittals específicos preparados por el contratista o proveedor.
La revisión debe concentrarse en interfaces, conformidad con requisitos y coordinación, preservando la responsabilidad del autor por el detalle de su suministro.
Product Data y datasheets certificados
Los catálogos generales no sustituyen necesariamente datos específicos del ítem contratado. Para paquetes críticos, puede ser necesario exigir un datasheet certificado o documentación identificada con modelo, tag y revisión del proyecto.
Esto evita utilizar documentación comercial genérica para demostrar parámetros de un ítem configurado específicamente.
Test reports y certificates
Los informes de prueba y certificados deben estar asociados con el ítem real suministrado. La trazabilidad puede involucrar número de serie, lote, tag, orden de fabricación u otra identificación.
Sin esa relación, el documento puede existir, pero no demostrar conformidad del equipo entregado.
O&M Data y documentación de operación
Los manuales de operación y mantenimiento deben planificarse como entregables formales. En muchos proyectos llegan tarde o en formato genérico, cuando ya deberían estar alimentando capacitación, planes de mantenimiento y preparación operacional.
El VDR debe establecer fecha y revisión compatibles con la fase de handover.
Closeout submittals y documentación final
La documentación final no debe reconstruirse al final. El VDR debe marcar desde el inicio qué ítems formarán el Data Book, Quality Dossier, As-Built o handover técnico.
Esto permite que cada documento avance junto con el suministro y reduce la concentración de pendientes en el cierre.
El artículo de Data Book en Ingeniería profundiza la estructura del dossier final sin confundir esa función con el control operacional de vendor data.
Vendor Data y Document Control
Document Control garantiza protocolo, codificación, revisión, distribución y trazabilidad. El área técnica define contenido y estado. Procurement y expediting acompañan obligaciones y plazo.
Estas responsabilidades no deben concentrarse informalmente en una sola persona.
| Rol | Responsabilidad principal |
| proveedor | producir y someter documentos conformes |
| Document Control | registrar, codificar y distribuir |
| Ingeniería | revisar contenido técnico |
| Procurement/Contrato | exigir obligación contractual |
| Expediting | monitorear impacto de plazo |
| QA/QC | revisar registros de calidad aplicables |
| PMO/Project Controls | integrar impactos al proyecto |
Métricas útiles para Vendor Data
Los indicadores pueden incluir:
- documentos previstos vs recibidos;
- sometimientos vencidos;
- documentos críticos atrasados;
- tiempo medio de revisión del cliente;
- número medio de ciclos hasta aceptación;
- documentos bloqueando fabricación;
- documentos bloqueando disciplinas del proyecto;
- pendientes de closeout.
Es importante separar el retraso del proveedor del retraso de revisión del contratante.
Automatización y EDMS
En proyectos con muchos paquetes, las hojas de cálculo aisladas pierden rápidamente la trazabilidad. Un EDMS puede relacionar documento, proveedor, paquete, revisión, transmittal, estado, comentarios, fechas y dependencias.
El sistema debe preservar el historial; sustituir la revisión anterior sin registro destruye evidencia de decisión.
Errores frecuentes
Los problemas recurrentes incluyen:
- lista de vendor data definida después de la adjudicación;
- plazo documental basado solamente en la entrega física;
- catálogos genéricos aceptados como documentación final;
- comentarios técnicos contradictorios;
- estado de aprobación sin significado definido;
- retraso del contratante no separado del retraso del proveedor;
- VDR desconectado de la MDR;
- documentos finales exigidos solamente en el cierre;
- archivos sin codificación o revisión controlada;
- aprobación interpretada como transferencia de responsabilidad.
Consideraciones finales
Vendor Data y submittals son activos de Ingeniería, no anexos administrativos de Procurement. Alimentan proyecto, fabricación, inspección, montaje, comisionamiento, operación y documentación final.
Cuando los requisitos documentales se definen antes de la adjudicación y se controlan mediante un registro integrado con Document Control, expediting y el cronograma, el proyecto reduce retrasos ocultos y preserva trazabilidad desde la propuesta hasta el handover.
El VDR no debe convertirse en una hoja de cálculo paralela desconectada del proyecto. La gobernanza documental es más robusta cuando vendor data, MDR, transmittals, revisiones y documentación final comparten codificación y trazabilidad.
Referencias técnicas
[1] WHOLE BUILDING DESIGN GUIDE. Unified Submittals — SpecsIntact. Disponible en: [https://legacy.wbdg.org/tools/specsintact/Help/Submittals/UnifiedSubmittals.htm](https://legacy.wbdg.org/tools/specsintact/Help/Submittals/UnifiedSubmittals.htm)
[2] U.S. DEPARTMENT OF VETERANS AFFAIRS. Section 01 33 23 — Shop Drawings, Product Data, and Samples. Disponible en: [https://www.wbdg.org/FFC/VA/VAASC/VA%2001%2033%2023.pdf](https://www.wbdg.org/FFC/VA/VAASC/VA%2001%2033%2023.pdf)
[3] ISO. ISO 9001:2015 — Quality management systems — Requirements. Geneva: ISO. Disponible en: [https://www.iso.org/standard/62085.html](https://www.iso.org/standard/62085.html)
[4] ISO. Guidance for implementing documented information using ISO 30301:2019. Geneva, 2021. Disponible en: [https://committee.iso.org/sites/tc46sc11/home/news/content-left-area/news-about-standarization-in-t-1/add-a-post-2.html](https://committee.iso.org/sites/tc46sc11/home/news/content-left-area/news-about-standarization-in-t-1/add-a-post-2.html)
Preguntas frecuentes
Es el conjunto de documentos y datos producidos por el proveedor para detallar, demostrar, integrar y registrar su suministro, como planos, datasheets, cálculos, informes, certificados y manuales.
El VDR controla entregables documentales del proveedor. La MDR controla el universo documental del proyecto. El VDR puede alimentar la MDR, pero posee un alcance más específico.
Es un ítem formalmente sometido por el contratista o proveedor para revisión, aprobación, información o registro, como shop drawings, product data, certificados e informes de prueba.
Normalmente no. La revisión verifica compatibilidad con requisitos e interfaces, pero la responsabilidad técnica del proveedor permanece según el contrato.
Antes de la adjudicación, en la requisición técnica y los documentos de contratación, para que cantidad, formato, plazos y ciclos de revisión formen parte de la obligación contractual.
Porque algunos planos, datasheets o procedimientos deben revisarse antes de que el proveedor avance a fabricación, pruebas o integración.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Documentos de Ingeniería: GED, EDMS, revisiones y trazabilidad
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
Servicios relacionados
- Procurement Técnico: especificación, equalización, proveedores y apoyo a la contratación
- Ingeniería del Propietario (Owner’s Engineering): gobernanza técnica, fiscalización y aceptación
Contenidos principales sobre el tema
- Requisición Técnica en Ingeniería: cómo preparar el paquete técnico para Procurement
- Control de Documentos en Ingeniería: proceso, revisiones, transmittals y trazabilidad
